Elrond Network runs on a sharded architecture - transaction, data and network sharding are leveraged.
In the Rosetta implementation, we've decided to provide a single-shard perspective to the API consumer. That is, one Rosetta instance would observe a single regular shard of the network - the shard is selected by the owner of the instance.
Currently, the Rosetta implementation only supports the native currency (EGLD), while custom currencies (ESDTs) will be supported in the near future. At that point, Rosetta would observe the metachain, as well.
Follow the official documentation to setup an observer:
Before starting the observer, make sure to edit the config/prefs.toml
and set the target shard (for example, shard 0):
[Preferences]
DestinationShardAsObserver = "0"
Furthermore, enable the database lookup extensions in config/config.toml
, as follows:
[DbLookupExtensions]
Enabled = true
Clone the repository:
cd $HOME
git clone https://github.com/ElrondNetwork/rosetta.git
Build the application:
cd rosetta/cmd/rosetta
go build .
Then, start rosetta
as follows:
./rosetta --observer-http-url=http://localhost:8080 --observer-actual-shard=0 \
--chain-id=D --native-currency=XeGLD \
--port=9091
Or, in order to start using the offline
mode:
./rosetta --observer-actual-shard=0 \
--chain-id=D --native-currency=XeGLD \
--port=9092 --offline
- We do not support the
related_transactions
property, since it's not feasible to properly filter the related transactions of a given transaction by source / destination shard (with respect to the observed shard). - The endpoint
/block/transaction
is not implemented, since all transactions are returned by the endpoint/block
. - We chose not to support the optional property
Operation.related_operations
. Although the smart contract results (also known as unsigned transactions) form a DAG (directed acyclic graph) at the protocol level, operations within a transaction are in a simple sequence. - Only successful operations are listed in our Rosetta API implementation. For invalid transactions, we only list the fee operation.
- Balance-changing operations that affect Smart Contract accounts are not emitted by our Rosetta implementation (thus are not available on the Rosetta API).
- Make sure to set
"pruning_disabled": true
in the configuration file of the checker. Otherwise, the information gathered frombootstrap/*.rosetta.json
will be lost at some point due to pruning, and balance reconciliations will start to fail.
- Make sure to set a large enough
"stale_depth"
, since the implementation only returns final blocks (notarized by the Metachain and built upon), by default. There is a delay between the broadcast of the transaction and the moment at which the container block is marked as final. For example, use"stale_depth": 10
. - In the construction DSL,
generate_account()
cannot be used, since it cannot be constrained to create accounts in the observed shard, at the moment. As a workaround, the accounts involved in a transfer (sender, recipient) should be explicitly specified in the*.ros
file.