Rosetta Node
Deploying a Rosetta specification compliant node
Here we lay out the procedure one needs to follow to deploy an Ontology node that adheres to Rosetta's blockchain standards. By complying to the Rosetta blockchain specifications, we at Ontology aim to streamline the development process for blockchain developers by ensuring certain aspects of the system are structured in a manner such that basic operations such as the deployment process, communication, and certain data formats are standardized, thus increasing the overall flexibility of the system.
Before running any of the commands specified below, please ensure that you are running the latest version of Docker. If you don't have it installed on your system already, please follow this link to download Docker.
Next, clone the Ontology Rosetta node source code library using the following command:
git clone https://github.com/ontio/ontology-rosetta.git
We will be building the node directly from the source code.
The
Dockerfile already contains all the necessary dependencies. Within the directory, please run the following command to build the docker image:make docker
First, we create a new directory where all the node details will be stored.
Please ensure that you have enough disk space (at least 100GB free) available to store the chain and operation data. This establishes the smoothness of node operation and lowers the need for maintenance over time.
mkdir Chain
Next, run the
ont-rosetta image using the command specified below. Note that we mount three volumes into the container. The three volumes store log data, block data, and allow access to the host configuration file.# you are using the default config in this repo
docker run --name ont-rosetta -d -v $(realpath Log):/data/Log -v $(realpath Chain):/data/Chain -v $(realpath rosetta-config.json):/data/rosetta-config.json -p 9090:8080 ontology-rosetta:latest
In case you wish to connect to the TestNet, set the
NETWORK_ID to 2 as such:docker run --name ont-rosetta -d --env NETWORK_ID=2 -v $(realpath Log):/data/Log -v $(realpath Chain):/data/Chain -v $(realpath rosetta-config.json):/data/rosetta-config.json -p 9090:8080 ontology-rosetta:latest
The default configuration in the
rosetta-config.json file is as follows:{
"rosetta": {
"version": "1.3.1",
"port": 8080,
"block_wait_time": 1
},
"monitorOEP4ScriptHash": []
}
Field | Description |
version | Rosetta SDK version |
port | Rosetta restful API port |
block_wait_time | Time between subsequent block scans (in seconds) |
monitorOEP4ScriptHash | OEP4 token contract hash to be monitored |
Please follow the link below for Rosetta node API reference.
The public key of a wallet account can be used to invoke the
construction/derive API method to fetch the corresponding account address in hex or base58 format.The
construction/payload API method can be invoked to create an unsigned transaction and the signing payload.The
construction/preprocess and construction/metadata API methods can be called to create a request and fetch transaction metadata respectively. The construction/parse method can be used to parse transaction details and to check and verify the transaction parameters.The signing payload from the previous step needs to be signed. This can be done using Ontology's SDKs or the signing server.
A signing payload looks something like:
{
"unsigned_transaction": "00d1fb2f5b77204e000000000000c409000000000000ffe723aefd01bac311d8b16ff8bfd594d77f31ee7100c66b14092118e0112274581b60dfb6fedcbfdcfc044be76a7cc814ffe723aefd01bac311d8b16ff8bfd594d77f31ee6a7cc8516a7cc86c51c1087472616e736665721400000000000000000000000000000000000000010068164f6e746f6c6f67792e4e61746976652e496e766f6b650000",
"payloads": [
{
"hex_bytes": "732b2e24ac4966f4b43ab565499f09b676eca1c96d6d039d21cf9c8338ee008e",
"address": "AGc9NrdF5MuMJpkFfZ3MWKa67ds6H2fzud",
"signature_type": "ecdsa"
},
{
"hex_bytes": "732b2e24ac4966f4b43ab565499f09b676eca1c96d6d039d21cf9c8338ee008e",
"address": "Af6xrG7WB9wUKQ3aRDXnfba2G5DXjqejMS",
"signature_type": "ecdsa"
}
]
}
The content in the
hex_bytes field is signed using the address and based on the the signature_type specified. You can create a request as follows:{
"network_identifier": {
"blockchain": "ont",
"network": "testnet"
},
"unsigned_transaction":"00d12981cfeec409000000000000204e000000000000ffe723aefd01bac311d8b16ff8bfd594d77f31ee7100c66b14092118e0112274581b60dfb6fedcbfdcfc044be76a7cc814ffe723aefd01bac311d8b16ff8bfd594d77f31ee6a7cc8516a7cc86c51c1087472616e736665721400000000000000000000000000000000000000010068164f6e746f6c6f67792e4e61746976652e496e766f6b650000",
"signatures":[
{
"signing_payload":{
"address":"Af6xrG7WB9wUKQ3aRDXnfba2G5DXjqejMS",
"hex_bytes":"14d840eb85340de4d7bcdc4b66d66c716a228e4c5ec5189c5ebfbd003b0528bb",
"signature_type":"ecdsa"
},
"public_key":{
"hex_bytes":"02263e2e1eecf7a45f21e9e0f865510966d4e93551d95876ecb3c42acf2b68aaae",
"curve_type":"secp256k1"
},
"signature_type":"ecdsa",
"hex_bytes":"0d92482c51240b7b8497ec8c1efb41d1d94e434433fb0b3642e4483ecd2083c672b9e73ff4194d84cc84012db78c2d283a4bb1dbec5dc66015a42dac0042f8d7"
},
{
"signing_payload":{
"address":"AGc9NrdF5MuMJpkFfZ3MWKa67ds6H2fzud",
"hex_bytes":"14d840eb85340de4d7bcdc4b66d66c716a228e4c5ec5189c5ebfbd003b0528bb",
"signature_type":"ecdsa"
},
"public_key":{
"hex_bytes":"03944e3ff777b14add03a76fd6767aaf4a65c227ec201375d9118d4e6b272494c7",
"curve_type":"secp256k1"
},
"signature_type":"ecdsa",
"hex_bytes":"637fdd1ac4b0cc5f36334b48b5fcd9494531ba88b5ec3e6ceb0fc49461e0e856f8a3aa4394be2c4a15a0358767a66d1acbf9a2ac9a12e4c628c9f8762db353db"
}
]
}
The
construction/combine method can be invoked with a request such as the one illustrated in the previous step in order to obtain a signed transaction.The
construction/hash method can be used to fetch the transaction hash for a signed transaction. The transaction status can can then be checked by invoking the block/transaction or mempool/transaction API methods with the obtained hash.Last modified 10mo ago