Rosetta Node

Deploying a Rosetta specification compliant node

Overview

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.

Environment Setup

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

Node Deployment

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

Configuration

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.

Rosetta Node API

Integrating using the Construction API

Integrating Ontology using the Rosetta node construction API involves the following procedure:

1. Create an account

You can create an Ontology wallet account using the Node CLI or the Ontology SDKs.

2. Derive an account from the public key

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.

3. Construct a transfer transaction

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.

4. Signing the payload

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"
        	}
        ]
}

5. Constructing a signed transaction

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.

6. Sending a transaction

A signed_transaction can be submitted to the node using the construction/submit API method.

7. Fetching a transaction hash

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.