Newer
Older
Eris DB allows remote access to its functionality over http and websocket. It currently supports JSON-RPC, and REST-like http. There is also javascript bindings available in the [erisdb-js](TODO) library.
## TOC
- [JSON-RPC 2.0](#json-rpc)
- [REST-like HTTP](#rest-like)
- [Common objects and formatting](#formatting-conventions)
- [Event-system](#event-system)
- [Methods](#methods)
The default endpoints for JSON-RPC (2.0) is `/rpc` for http based, and `/socketrpc` for websocket. The namespace for the JSON-RPC service is `erisdb`.
### Objects
##### Errors
```
PARSE_ERROR = -32700
INVALID_REQUEST = -32600
METHOD_NOT_FOUND = -32601
INVALID_PARAMS = -32602
INTERNAL_ERROR = -32603
```
#####Request
```
{
jsonrpc: <string>
method: <string>
params: <Object>
id: <string>
}
```
#####Response
```
{
jsonrpc: <string>
id: <string>
result: <Object>
error: <Error>
}
```
#####Error
Id can be any string value. Parameters are named, and wrapped in objects. Also, params, result and error params may be `null`.
#####Example
```
{
jsonrpc: "2.0",
method: "erisdb.getAccount",
params: {address: "37236DF251AB70022B1DA351F08A20FB52443E37"},
id="25"
}
```
Response:
```
{
address: "37236DF251AB70022B1DA351F08A20FB52443E37",
pub_key: null,
sequence: 0,
balance: 110000000000,
code: "",
storage_root: ""
}
```
<a name="rest-like"></a>
The REST-like API provides the typical endpoint structure i.e. endpoints are named as resources, parameters can be put in the path, and queries are used for filtering and such. It is not fully compatible with REST; partly because some GET requests can contain sizable input so POST is used instead. There are also some modeling issues but those will most likely be resolved before version 1.0.
<a name="formatting-conventions"></a>
##Common objects and formatting
This section contains some common objects and explanations of how they work.
###Numbers and strings
Numbers are always numbers, and never strings. This is different from Ethereum where currency values are so high they need string representations. The only thing hex strings are used for is to represent byte arrays.
#####Examples
```
"some_number_field" : 5892,
"another_number_field" : 0x52
"hex_string" : "37236DF251AB70022B1DA351F08A20FB52443E37"
```
###Keys and addresses
Public and Private keys in JSON data are either null, or on the form: `[type, hex]`, where `type` is the [public](https://github.com/tendermint/tendermint/blob/master/account/pub_key.go), or [private](https://github.com/tendermint/tendermint/blob/master/account/pub_key.go) key type, and `hex` is the hex-string representation of the key bytes.
- A `public address` is a 20 byte hex string.
- A `public key` is a 32 byte hex string.
- A `private key` is a 64 byte hex string.
#####WARNING
**When using a client-server setup, do NOT send public keys over non-secure connections. The only time this is fine is during development when the keys are nothing but test data and does not protect anything of value. Normally they should either be kept locally and used to sign transactions locally, held on the server where the blockchain client is running, or be passed over secure channels.**
#####Examples
A public address: `"37236DF251AB70022B1DA351F08A20FB52443E37"`
The corresponding Ed25519 public key: `[1, "CB3688B7561D488A2A4834E1AEE9398BEF94844D8BDBBCA980C11E3654A45906"]`
The corresponding Ed25519 private key: `[1, "6B72D45EB65F619F11CE580C8CAED9E0BADC774E9C9C334687A65DCBAD2C4151CB3688B7561D488A2A4834E1AEE9398BEF94844D8BDBBCA980C11E3654A45906"]`
<a name="the-transaction-types"></a>
###The transaction types
These are the types of transactions:
####SendTx
```
{
inputs: [<TxInput>]
outputs: [<TxOutput>]
}
```
####CallTx
```
{
input: <TxInput>
address: <string>
gas_limit: <number>
fee: <number>
data: <string>
}
```
####NameTx
```
{
input: <TxInput>
name: <string>
data: <string>
fee: <number>
}
```
####BondTx
```
{
pub_key: <PubKey>
signature: <string>
inputs: [<TxInput>]
unbond_to: [<TxOutput>]
}
```
####UnbondTx
```
{
address: <string>
height: <number>
signature: <string>
}
```
####RebondTx
```
{
address: <string>
height: <number>
signature: <string>
}
```
####DupeoutTx
```
{
address: <string>
vote_a: <Vote>
vote_b: <Vote>
}
```
These are the support types that are referenced in the transactions:
####TxInput
```
{
address: <string>
amount: <number>
sequence: <number>
signature: <string>
pub_key: <string>
}
```
####TxOutput
```
{
address: <string>
amount: <number>
}
```
####Vote
```
{
height: <number>
type: <number>
block_hash: <string>
block_parts: {
total: <number>
hash: <string>
}
signature: <string>
}
```
<a name="event-system"></a>
##Event system
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
Tendermint events can be subscribed to regardless of what connection type is used. There are three methods for this:
- [EventSubscribe](#event-subscribe) is used to subscribe to a given event, using an event-id string as argument. The response will contain a `subscription ID`, which can be used to close down the subscription later, or poll for new events if using HTTP. More on event-ids below.
- [EventUnsubscribe](#event-unsubscribe) is used to unsubscribe to an event. It requires you to pass the `subscription ID` as an argument.
- [EventPoll](#event-poll) is used to get all the events that has accumulated since the last time the subscription was polled. It takes the `subscription ID` as a parameter. NOTE: This only works over HTTP. Websocket connections will automatically receive events as they happen. They are sent as regular JSON-RPC 2.0 responses with the `subscriber ID` as response id.
There is another slight difference between polling and websocket, and that is the data you receive. If using sockets, it will always be one event at a time, whereas polling will give you an array of events.
### Event types
These are the type of events you can subscribe to.
The "Account" events are triggered when someone transacts with the given account, and can be used to keep track of account activity.
NewBlock and Fork happens when a new block is committed or a fork happens, respectively.
The other events are directly related to consensus. You can find out more about the Tendermint consensus system in the Tendermint [white paper](http://tendermint.com/docs/tendermint.pdf). There is also information in the consensus [sources](https://github.com/tendermint/tendermint/blob/master/consensus/state.go), although a normal user would not be concerned with the consensus mechanisms, but would mostly just listen to account- and perhaps block-events.
#### Account Input
This notifies you when an account is receiving input.
Event ID: `Acc/<address>/Input`
Example: `Acc/B4F9DA82738D37A1D83AD2CDD0C0D3CBA76EA4E7/Input` will subscribe to input events from the account with address: B4F9DA82738D37A1D83AD2CDD0C0D3CBA76EA4E7.
Event object:
```
{
tx: <Tx>
return: <string>
exception: <string>
}
```
#### Account Output
This notifies you when an account is yielding output.
Event ID: `Acc/<address>/Output`
Example: `Acc/B4F9DA82738D37A1D83AD2CDD0C0D3CBA76EA4E7/Output` will subscribe to output events from the account with address: B4F9DA82738D37A1D83AD2CDD0C0D3CBA76EA4E7.
Event object:
```
<Tx>
```
#### Account Receive
This notifies you when an account is the target of a call, like when calling an accessor function.
Event ID: `Acc/<address>/Receive`
Example: `Acc/B4F9DA82738D37A1D83AD2CDD0C0D3CBA76EA4E7/Input` will subscribe to call receive events from the account with address: B4F9DA82738D37A1D83AD2CDD0C0D3CBA76EA4E7.
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
```
{
call_data: {
caller: <string>
callee: <string>
data: <string>
value: <number>
gas: <number>
}
origin: <string>
tx_id: <string>
return: <string>
exception: <string>
}
```
#### New Block
This notifies you when a new block is committed.
Event ID: `NewBlock`
Event object:
```
<Block>
```
#### Fork
This notifies you when a fork event happens.
Event ID: `Fork`
Event object:
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
```
<Block>
```
#### Bond
This notifies you when a bond event happens.
Event ID: `Bond`
Event object:
```
<Tx>
```
#### Unbond
This notifies you when an unbond event happens.
Event ID: `Unbond`
Event object:
```
<Tx>
```
#### Rebond
This notifies you when a rebond event happens.
Event ID: `Rebond`
Event object:
```
<Tx>
```
#### Dupeout
This notifies you when a dupeout event happens.
Event ID: `Dupeout`
Event object:
```
<Tx>
```
| :--- | :-------------- | :---------: | :------------ |
| [GetAccounts](#get-accounts) | erisdb.getAccounts | GET | `/accounts` |
| [GetAccount](#get-account) | erisdb.getAccount | GET | `/accounts/:address` |
| [GetStorage](#get-storage) | erisdb.getStorage | GET | `/accounts/:address/storage` |
| [GetStorageAt](#get-storage-at) | erisdb.getStorageAt | GET | `/accounts/:address/storage/:key` |
###Blockchain
| :--- | :-------------- | :---------: | :------------ |
| [GetBlockchainInfo](#get-blockchain-info) | erisdb.getBlockchainInfo | GET | `/blockchain` |
| [GetChainId](#get-chain-id) | erisdb.getChainId | GET | `/blockchain/chain_id` |
| [GetGenesisHash](#get-genesis-hash) | erisdb.getGenesisHash | GET | `/blockchain/genesis_hash` |
| [GetLatestBlockHeight](#get-latest-block-height) | erisdb.getLatestBlockHeight | GET | `/blockchain/latest_block/height` |
| [GetLatestBlock](#get-latest-block) | erisdb.getLatestBlock | GET | `/blockchain/latest_block` |
| [GetBlocks](#get-blocks) | erisdb.getBlocks | GET | `/blockchain/blocks` |
| [GetBlock](#get-block) | erisdb.getBlock | GET | `/blockchain/blocks/:height` |
###Consensus
| :--- | :-------------- | :---------: | :------------ |
| [GetConsensusState](#get-consensus-state) | erisdb.getConsensusState | GET | `/consensus` |
| [GetValidators](#get-validators) | erisdb.getValidators | GET | `/consensus/validators` |
###Events
| :--- | :-------------- | :---------: | :------------ |
| [EventSubscribe](#event-subscribe) | erisdb.eventSubscribe | POST | `/event_subs` |
| [EventUnsubscribe](#event-unsubscribe) | erisdb.eventUnsubscribe | DELETE | `/event_subs/:id` |
| [EventPoll](#event-poll) | erisdb.eventPoll | GET | `/event_subs/:id` |
###Network
| :--- | :-------------- | :---------: | :------------ |
| [GetNetworkInfo](#get-network-info) | erisdb.getNetworkInfo | GET | `/network` |
| [GetClientVersion](#get-client-version) | erisdb.getClientVersion | GET | `/network/client_version` |
| [GetMoniker](#get-moniker) | erisdb.getMoniker | GET | `/network/moniker` |
| [GetChainId](#get-chain-id) | erisdb.getChainId | GET | `/network/chain_id` |
| [IsListening](#is-listening) | erisdb.isListening | GET | `/network/listening` |
| [GetListeners](#get-listeners) | erisdb.getListeners | GET | `/network/listeners` |
| [GetPeers](#get-peers) | erisdb.getPeers | GET | `/network/peers` |
| [GetPeer](#get-peer) | erisdb.getPeer | GET | `/network/peer/:address` |
###Transactions
| :--- | :-------------- | :---------: | :------------ |
| [BroadcastTx](#broadcast-tx) | erisdb.broadcastTx | POST | `/txpool` |
| [GetUnconfirmedTxs](#get-unconfirmed-txs) | erisdb.getUnconfirmedTxs | GET | `/txpool` |
| :--- | :-------------- | :---------: | :------------ |
| [Call](#call) | erisdb.call | POST | `/calls` |
| [CallCode](#call-code) | erisdb.callCode | POST | `/codecalls` |
| :--- | :-------------- | :---------: | :------------ |
| [SignTx](#sign-tx) | erisdb.signTx | POST | `/unsafe/tx_signer` |
| [Transact](#transact) | erisdb.transact | POST | `/unsafe/txpool` |
| [GenPrivAccount](#gen-priv-account) | erisdb.genPrivAccount | GET | `/unsafe/pa_generator` |
Here are the catagories.
* [Accounts](#accounts)
* [BlockChain](#blockchain)
* [Consensus](#consensus)
* [Events](#events)
* [Network](#network)
* [Transactions](#transactions)
* [Code Execution (calls)](#calls)
* [Unsafe](#unsafe)
In the case of **JSON-RPC**, the parameters are wrapped in a request object, and the return value is wrapped in a response object.
In the case of **REST-like HTTP** GET requests, the params (and query) is provided in the url. If it's a POST, PATCH or PUT request, the parameter object should be written to the body of the request as JSON. It is normally the same params object as in JSON-RPC.
**Unsafe** is methods that require a private key to be sent either to or from the client, and should therefore be used only during development/testing, or with extreme care. They may be phased out entirely.
<a name="accounts"></a>
###Accounts
***
<a name="get-accounts"></a>
####GetAccounts
Get accounts will return a list of accounts. If no filtering is used, it will return all existing accounts.
#####HTTP
Endpoint: `/accounts`
#####JSON-RPC
Method: `erisdb.getAccounts`
Parameter:
```
{
filters: [<FilterData>]
}
```
##### Filters
| Field | Underlying type | Ops | Example Queries |
| :---- | :-------------- | :-- | :-------------- |
| `balance` | uint64 | `<`, `>`, `<=`, `>=`, `==` | `q=balance:<=11` |
| `code` | byte[] | `==`, `!=` | `q=code:1FA872` |
{
accounts: [<Account>]
}
```
#####Additional info
See GetAccount below for more info on the `Account` object.
See the section on [Filters](#queries-filters) for info on the `FilterData` object.
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
***
<a name="get-account"></a>
####GetAccount
Get an account by its address.
#####HTTP
Method: GET
Endpoint: `/accounts/:address`
Params: The public `address` as a hex string.
#####JSON-RPC
Method: `erisdb.getAccount`
Parameter:
```
{
address: <string>
}
```
#####Return value
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
{
address: <string>
pub_key: <PubKey>
sequence: <number>
balance: <number>
code: <string>
storage_root: <string>
}
```
`address` is a public address.
`pub_key` is a public key.
#####Additional info
Sequence is sometimes referred to as the "nonce".
There are two types of objects used to represent accounts, one is public accounts (like the one here), the other is private accounts, which only holds information about an accounts address, public and private key.
***
<a name="get-storage"></a>
####GetStorage
Get the complete storage of a contract account. Non-contract accounts has no storage.
NOTE: This is mainly used for debugging. In most cases the storage of an account would be accessed via public accessor functions defined in the contracts ABI.
#####HTTP
Method: GET
Endpoint: `/accounts/:address/storage`
Params: The public `address` as a hex string.
#####JSON-RPC
Method: `erisdb.getStorage`
Parameter:
```
{
address: <string>
}
```
#####Return value
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
{
storage_root: <string>
storage_items: [<StorageItem>]
}
```
`storage_root` is a public address.
See `GetStorageAt` below for more info on the `StorageItem` object.
***
<a name="get-storage-at"></a>
####GetStorageAt
Get a particular entry in the storage of a contract account. Non-contract accounts has no storage.
NOTE: This is mainly used for debugging. In most cases the storage of an account would be accessed via public accessor functions defined in the contracts ABI.
#####HTTP
Method: GET
Endpoint: `/accounts/:address/storage/:key`
Params: The public `address` as a hex string, and the `key` as a hex string.
#####JSON-RPC
Method: `erisdb.getStorageAt`
Parameter:
```
{
address: <string>
key: <string>
}
```
#####Return value
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
{
key: <string>
value: <string>
}
```
Both `key` and `value` are hex strings.
***
<a name="blockchain"></a>
###Blockchain
***
<a name="get-blockchain-info"></a>
####GetBlockchainInfo
Get the current state of the blockchain. This includes things like chain-id and latest block height. There are individual getters for all fields as well.
#####HTTP
Method: GET
Endpoint: `/blockchain`
#####JSON-RPC
Method: `erisdb.getBlockchainInfo`
Parameter: -
#####Return value
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
{
chain_id: <string>
genesis_hash: <string>
latest_block: <BlockMeta>
latest_block_height: <number>
}
```
#####Additional info
`chain_id` is the name of the chain.
`genesis_hash` is a 32 byte hex-string. It is the hash of the genesis block, which is the first block on the chain.
`latest_block` contains block metadata for the latest block. See the [GetBlock](#get-block) method for more info.
`latest_block_height` is the height of the latest block, and thus also the height of the entire chain.
The block *height* is sometimes referred to as the block *number*.
See [GetBlock](#get-block) for more info on the `BlockMeta` type.
***
<a name="get-chain-id"></a>
####GetChainId
Get the chain id.
#####HTTP
Method: GET
Endpoint: `/blockchain/chain_id`
#####JSON-RPC
Method: `erisdb.getChainId`
Parameter: -
#####Return value
{
chain_id: <string>
}
```
***
<a name="get-genesis-hash"></a>
####GetGenesisHash
Get the genesis hash. This is a 32 byte hex-string representation of the hash of the genesis block. The genesis block is the first block on the chain.
#####HTTP
Method: GET
Endpoint: `/blockchain/genesis_hash`
#####JSON-RPC
Method: `erisdb.getGenesisHash`
Parameter: -
#####Return value
{
genesis_hash: <string>
}
```
***
<a name="get-latest-block-height"></a>
####GetLatestBlockHeight
Get the height of the latest block. This would also be the height of the entire chain.
#####HTTP
Method: GET
Endpoint: `/blockchain/latest_block/height`
#####JSON-RPC
Method: `erisdb.getLatestBlockHeight`
Parameter: -
#####Return value
{
latest_block_height: <number>
}
```
***
<a name="get-latest-block"></a>
####GetLatestBlock
Gets the block that was added to the chain most recently.
#####HTTP
Method: GET
Endpoint: `/blockchain/latest_block`
#####JSON-RPC
Method: `erisdb.getLatestBlock`
Parameter: -
#####Return value
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
{
latest_block: <BlockMeta>
}
```
#####Additional info
See [GetBlock](#get-block) for more info on the `BlockMeta` type.
***
<a name="get-blocks"></a>
####GetBlocks
Get a series of blocks from the chain.
#####HTTP
Method: GET
Endpoint: `/blockchain/blocks`
#####JSON-RPC
Method: `erisdb.getBlocks`
Parameter:
```
{
filters: [<FilterData>]
}
```
##### Filters
| Field | Underlying type | Ops | Example Queries |
| :---- | :-------------- | :-- | :-------------- |
| `height` | uint | `<`, `>`, `<=`, `>=`, `==` | `q=height:>4`, `q=height:10..*` |
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
{
min_height: <number>
max_height: <number>
block_metas: [<BlockMeta>]
}
```
The `BlockMeta` object:
```
{
hash: <string>
header: {
chain_id: <string>
height: <number>
time: <string>
fees: <number>
num_txs: <number>
last_block_hash: <string>
last_block_parts: {
total: <number>
hash: <string>
}
state_hash: <string>
}
parts: {
total: <number>
hash: <string>
}
}
```
#####Additional info
TODO
See the section on [Filters](#queries-filters) for info on the `FilterData` object.
`min_height` and `max_height` is the two actual values used for min and max height when fetching the blocks. The reason they are included is because the heights might have been modified, like for example when the blockchain height is lower then the max height provided in the query.
See [GetBlock](#get-block) for more info on the `BlockMeta` type.
***
<a name="get-block"></a>
####GetBlock
Get the block at the given height.
#####HTTP
Method: GET
Endpoint: `/blockchain/block/:number`
#####JSON-RPC
Method: `erisdb.getBlock`
Parameter:
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
{
header: {
chain_id: <string>
height: <number>
time: <string>
fees: <number>
num_txs: <number>
last_block_hash: <string>
last_block_parts: {
total: <number>
hash: <string>
}
state_hash: <string>
}
validation: {
commits: [<Commit>]
TODO those other two.
}
data: {
txs: [<Tx>]
TODO that other field.
}
}
```
The `Commit` object:
```
{
address: <string>
round: <number>
signature: <string>
}
```
#####Additional info
TODO
See [The transaction types](#the-transaction-types) for more info on the `Tx` types.
***
<a name="consensus"></a>
###Consensus
***
<a name="get-consensus-state"></a>
####GetConsensusState
Get the current consensus state.
#####HTTP
Method: GET
Endpoint: `/consensus`
#####JSON-RPC
Method: `erisdb.getConsensusState`
Parameter: -
#####Return value