arrow-left

All pages
gitbookPowered by GitBook
1 of 4

Loading...

Loading...

Loading...

Loading...

Query JSON RPC endpoints

hashtag
Overview

The JSON-RPC layer of the ZChains provides developers with the functionality of easily interacting with the blockchain, through HTTP requests.

This example covers using tools like curl to query information, as well as starting the chain with a premined account, and sending a transaction.

hashtag
Step 1: Create a genesis file with a premined account

To generate a genesis file, run the following command:

The premine flag sets the address that should be included with a starting balance in the genesis file. In this case, the address 0x1010101010101010101010101010101010101010 will have a starting default balance of 0x3635C9ADC5DEA00000 wei.

If we wanted to specify a balance, we can separate out the balance and address with a :, like so:

The balance can be either a hex or uint256 value.

:::warning Only premine accounts for which you have a private key! If you premine accounts and do not have a private key to access them, you premined balance will not be usable :::

hashtag
Step 2: Start the ZChains in dev mode

To start the ZChains in development mode, which is explained in the section, run the following:

hashtag
Step 3: Query the account balance

Now that the client is up and running in dev mode, using the genesis file generated in step 1, we can use a tool like curl to query the account balance:

The command should return the following output:

hashtag
Step 4: Send a transfer transaction

Now that we've confirmed the account we set up as premined has the correct balance, we can transfer some ether:

CLI Commandsarrow-up-right
polygon-edge genesis --premine 0x1010101010101010101010101010101010101010
Zchains genesis --premine 0x1010101010101010101010101010101010101010:0x123123
polygon-edge server --chain genesis.json --dev --log-level debug
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x1010101010101010101010101010101010101010", "latest"],"id":1}' localhost:8545
{
  "id":1,
  "result":"0x100000000000000000000000000"
}
var Web3 = require("web3");

const web3 = new Web3("<provider's websocket jsonrpc address>"); //example: ws://localhost:10002/ws
web3.eth.accounts
  .signTransaction(
    {
      to: "<recipient address>",
      value: web3.utils.toWei("<value in ETH>"),
      gas: 21000,
    },
    "<private key from premined account>"
  )
  .then((signedTxData) => {
    web3.eth
      .sendSignedTransaction(signedTxData.rawTransaction)
      .on("receipt", console.log);
  });

Query operator information

hashtag
Prerequisites

This guide assumes you have followed the Local Setup or guide on how to set up an IBFT cluster on the cloud.

A functioning node is required in order to query any kind of operator information.

With the ZChains, node operators are in control and informed about what the node they're operating is doing. At any time, they can use the node information layer, built on top of gRPC, and get meaningful information - no log sifting required.

:::note

If your node isn't running on 127.0.0.1:8545 you should add a flag --grpc-address <address:port> to the commands listed in this document.

:::

hashtag
Peer information

hashtag
Peers list

To get a complete list of connected peers (including the running node itself), run the following command:

This will return a list of libp2p addresses that are currently peers of the running client.

hashtag
Peer status

For the status of a specific peer, run:

With the address parameter being the libp2p address of the peer.

hashtag
IBFT info

Lots of times, an operator might want to know about the state of the operating node in IBFT consensus.

Luckily, the Zchains provides an easy way to find this information.

hashtag
Snapshots

Running the following command returns the most recent snapshot.

To query the snapshot at a specific height (block number), the operator can run:

hashtag
Candidates

To get the latest info on candidates, the operator can run:

This command queries the current set of proposed candidates, as well as candidates that have not been included yet

hashtag
Status

The following command returns the current validator key of the running IBFT client:

hashtag
Transaction pool

To find the current number of transactions in the transaction pool, the operator can run:

polygon-edge peers list
polygon-edge peers status --peer-id <address>
polygon-edge ibft snapshot
polygon-edge ibft snapshot --num <block-number>
polygon-edge ibft candidates
polygon-edge ibft status
polygon-edge txpool status

Working with node

Backup/restore node instance

hashtag
Overview

This guide goes into detail on how to back up and restore a ZChains node instance. It covers the base folders and what they contain, as well as which files are critical for performing a successful backup and restore.

hashtag
Base folders

ZChains leverages LevelDB as its storage engine. When starting a ZChains node, the following sub-folders are created in the specified working directory:

  • blockchain - Stores the blockchain data

  • trie - Stores the Merkle tries (world state data)

  • keystore - Stores private keys for the client. This includes the libp2p private key and the sealing/validator private key

It is critical for these folders to be preserved in order for the ZChains instance to run smoothly.

hashtag
Create backup from a running node and restore for new node

This section guides you through creating archive data of the blockchain in a running node and restoring it in another instance.

hashtag
Backup

backup command fetches blocks from a running node by gRPC and generates an archive file. If --from and --to are not given in the command, this command will fetch blocks from genesis to latest.

hashtag
Restore

A server imports blocks from an archive at the start when starting with --restore flag. Please make sure that there is a key for new node. To find out more about importing or generating keys, visit the .

hashtag
Back up/Restore Whole data

This section guides you through backup the data including state data and key and restoring into the new instance.

hashtag
Step 1: Stop the running client

Since the ZChains uses LevelDB for data storage, the node needs to be stopped for the duration of the backup, as LevelDB doesn't allow for concurrent access to its database files.

Additionally, the ZChains also does data flushing on close.

The first step involves stopping the running client (either through a service manager or some other mechanism that sends a SIGINT signal to the process), so it can trigger 2 events while gracefully shutting down:

  • Running data flush to disk

  • Release of the DB files lock by LevelDB

hashtag
Step 2: Backup the directory

Now that the client is not running, the data directory can be backed up to another medium. Keep in mind that the files with a .key extension contain the private key data that can be used to impersonate the current node, and they should never be shared with a third/unknown party.

:::info Please back up and restore the generated genesis file manually, so the restored node is fully operational. :::

hashtag
Restore

hashtag
Step 1: Stop the running client

If any instance of the ZChains is running, it needs to be stopped in order for step 2 to be successful.

hashtag
Step 2: Copy the backed up data directory to the desired folder

Once the client is not running, the data directory which was previously backed up can be copied over to the desired folder. Additionally, restore the previously copied genesis file.

hashtag
Step 3: Run the ZChains client while specifying the correct data directory

In order for the Polygon Edge to use the restored data directory, at launch, the user needs to specify the path to the data directory. Please consult the section on information regarding the data-dir flag.

consensus - Stores any consensus information that the client might need while working. For now, it stores the node's private validator key
Secret Managers sectionarrow-up-right
CLI Commands
$ polygon-edge backup --grpc-address 127.0.0.1:9632 --out backup.dat [--from 0x0] [--to 0x100]
$ polygon-edge server --restore archive.dat