How to use the Yandev RPC server for Nyzo Nyzo Follow Feb 25 · 5 min read

The repository we will be using to run our RPC server will be the one from Yandev, as it is up-to-date with the current version of the nyzoVerifier.

The installation of the Yandev RPC server is similar to that of a verifier, it is recommended that this is an in-cycle verifier, but it is not necessary for the verifier to be in the cycle to work.

The Yandev RPC server is a common choice for interfacing with the Nyzo network. It provides a json/rpc API that allows for tracking the network, transactions, chain state and balances. This RPC server uses a specific set of commands, not to be confused with bitcoin-like json/rpc implementations.

This article will consist out of three elements:

Installing our nyzoVerifier — which has the necessary modifications made so it supports RPC communications (optionally: migrate existing in-cycle verifier into an RPC server)

Understanding how the RPC works and how to interact with it

Python integration script

Installing the nyzoVerifier with RPC Server

If you want to install using an existing private key, use the following commands, replace VERIFIER_NICKNAME and VERIFIER_PRIVATE_SEED with your details.

If you would like to start off fresh, use the following commands, replace VERIFIER_NICKNAME with your desired Nyzo nickname:

Once the installation has finished, your verifier is up and running and the RPC is ready to accept commands. No additional configuration is needed.

Understanding how the RPC works and how to interact with it

The RPC server accepts methods and parameters using the JSON-RPC interface.

In the next chapter you will find a script which you can use to integrate the RPC with Python.

The script handles requests to be made to the RPC server. Which uses the following format:

The RPC server provides us with the following methods and parameters:

Method: info

Params: none

Response: {

"retention_edge": "...",

"identifier": "...",

"voting_pool_size": 2262,

"trailing_edge": -1,

"nickname": "ff18...a3ec",

"block_creation_information": "0\/0",

"cycle_length": 1881,

"transaction_pool_size": 0,

"version": 569,

"frozen_edge": 6550327,

"nyzo_string": "id__(..)"

}

The info method above is used to gain insight into the chain state, cycle length and some node configurations.

The balance method below accepts either an identifier or a nyzo_string as parameter. The balance in micronyzos is returned, and the amount of addresses on the balance list.

Method: balance

Params: accepts either identifier or nyzo_string

{

"identifier": "1848a3c5e0085bd9-15cc4dbc103e66fe-f8d3472f1b74c0e1-d0a3c23789072653"

}

OR

{

"nyzo_string": "id__81y8F-ox25Mq5tPdM10~qMZWSStM6Vj0Wu2ANAv91QqjDpD2jHc-"

} Response: {

"balance": 46500462,

"list_length": 3875

}

To convert the micronyzos balance to nyzo’s, divide the balance by 1,000,000.

The alltransactions method below returns the transaction pool of the verifier.

Method: alltransactions

Params: none

Response: {

"all_transactions":[],

"transactions_pool_size":0

}

The next method, gettransaction, accepts the block height parameter to fetch the transactions from. Note that this method fetches these transactions from the transaction pool only.

Method: gettransaction

Params: {

"height": 6500000

}

Response: {

"transaction":[]

}

The broadcast method allows for the broadcasting of a transaction for inclusion in a block. It accepts a signed transaction and replies with the target_height for inclusion.

Method: broadcast

Params: {

"tx": "signature hex transaction"

}

Response: {

"target_height": 6500000

}

The next method, rawtransaction, will allow you to get a signature for a transaction. This signature can, for example, be used in the broadcast method above.

It accepts either the sender and receiver in raw format or nyzo_string format.

The inclusion of the timestamp parameter is optional, if omitted, the RPC server will use the current timestamp.

So is the inclusion of previous_hash_height and previous_block_hash.

If a private_seed or private_nyzo_string has been provided for signing the transaction and the signature parameter has been omitted (as it is optional), the signature will be generated and returned in the response by the RPC server.

Depending on the mechanism of action chosen during integration, you may or may not want to broadcast the transaction at this stage. Use the broadcast boolean parameter to indicate this.

In the response body, if valid is True, an additional response value will be added, scheduled_block, which indicates for which block the transaction is scheduled.

Method: rawtransaction

Params:

{

"receiver_identifier": "",

"sender_identifier": "",

"sender_data": "",

"timestamp": optional,

"signature": optional,

"private_seed": "",

"broadcast": True/False

}

OR

{

"receiver_nyzo_string": "",

"sender_nyzo_string": "",

"sender_data": "",

"timestamp": optional,

"signature": optional,

"private_nyzo_string": "",

"broadcast": True/False

} Response: {

"valid_signature": True/False,

"valid": True/False,

"scheduled_block": 6500000,

"validation_error": "",

"validation_warning": "",

"id": "",

"amount": 20000000,

"receiver_identifier": "",

"sender_identifier": "",

"receiver_nyzo_string": "",

"sender_nyzo_string": "",

"timestamp": "",

"sign_data": "",

"sender_data": "",

"previous_hash_height": "",

"previous_block_hash": "",

"raw": ""

}

The next method, transactionconfirmed, accepts the hex signature as a parameter, tx. The RPC server checks if the transaction was included in the block and responds accordingly.

Method: transactionconfirmed

Params: {

"tx": ""

}

Response: {

"message": "unable to determine whether transaction was incorporated into the chain OR transaction is proceed in chain! OR transaction is not proceed in chain!",

"status": "unknown OR proceed OR not_proceed",

"block": -1 OR block height,

"signature": "" }

The next method, cycleinfo, does not accept any parameters but provides information about the cycle and its nodes.

Method: cycleinfo

Params: none

Response: {

"nodes": {

"address": "87.34.56.78",

"queue_timestamp": 1582655721,

"port_tcp": "",

"is_active": True,

"identifier": "",

"nyzo_string": "",

"nickname": "verifier123"

}

}

The last method, block, takes a block height as a parameter and provides information about said block.

Method: block

Params: {

"height": 6500000

}

Response: {

"height": 6500000,

"start_timestamp": 1582655721,

"verification_timestamp": 1582655721,

"transactions": {

"type_enum": "seed OR coin_generation OR standard OR unknown",

"timestamp": 1582655721,

"amount": 10000000,

"fee": 250000,

"sender": "",

"receiver": "",

"sender_nyzo_string": "",

"receiver_nyzo_string": "",

"id": "",

"sender_data": "",

"previous_block_hash": "",

"signature": "",

"previous_hash_height": ""

},

"hash": "",

"balance_list_hash": "",

"previous_block_hash": ""

}

Python integration script

As for integrating the RPC server into your exchange process flows, I will include a script below which has some basic functionalities you may want, they’re all based on the methods above and speak for themselves.

View the script on Github →

After changing the IP address for your RPC server’s, it’s time to try out some of the functions, good luck!