The goal of Beyond Protocol is to develop a blockchain centric protocol to enable devices to communicate and exchange value in a trusted network through a universal protocol on top of TCP/IP.
Next, let's install the testnet's version of the Beyond Protocol SDK. Here we'll use the develop branch, which contains the latest release.
That will install the beyondd and beyondcli binaries. Verify that everything is OK:
A Master node is running a full node, maintaining the entire blockchain.
First, initialize a full node by running the following command:
$ beyondd init --name < your_custom_node_name>
If the operation completed successfully, a node ID will be produced. Mark this information as you will need it later to complete the configuration.
This operation created a folder named '$HOME/.beyondd' with two subfolders: 'config' and 'data'. Inside the 'config' sub-folder there is a file named 'priv-validator.json' containing the validator private and public key. Also, there is the auto-generated genesis.json, containing validator information and initial account setup.
If you want to join the master node to the Beyond Protocol public testnet, replace the genesis.json file with
the one from
https://raw.githubusercontent.com/beyondprotocol/testnets/master/latest/genesis.json
In order for your node to be able to find peers on the testnet, you should adjust the '$HOME/.beyondd/config/config.toml' file. The template for this configuration file can be found at
https://raw.githubusercontent.com/beyondprotocol/testnets/master/latest/config.toml
At the moment, the easiest way to find peers is to populate the 'persistent_peers' setting in the configuration file using the value provided in the template.
If you are establishing a new network, you need to replace the genesis.json on each master node with your own template. First, you need to collect all the validator configurations (the 'priv-validator.json' files) from all Master nodes that you have initialized and insert their public keys into the genesis.json template file.
For example, if you have initialized four nodes, all of them being validators, the resulting section in the genesis.json file might look like the following snippet:
"validators": [
{
"pub_key": {
"type": "bynd/PubKeyEd25519",
"value": "ELtz5SZV6erWDQJdzfxzRDSSvYOfNVf3v3mq+P6sakU="
},
"power": "10",
"name": ""
},
{
"pub_key": {
"type": "bynd/PubKeyEd25519",
"value": "+DcGYN+mMIfCzT+wcwfLN6k4ToS3/6zZkr96uDJPGk4="
},
"power": "10",
"name": ""
},
{
"pub_key": {
"type": "bynd/PubKeyEd25519",
"value": "EYfOhuprfy6iuuTPQfzrj/O8bltrzDDPDW2brZ1u/hc="
},
"power": "10",
"name": ""
},
{
"pub_key": {
"type": "bynd/PubKeyEd25519",
"value": "gLctQ102Y6Hfo+WtIkhDogHjaTjebDfvvJ4AFDJ0LcM="
},
"power": "10",
"name": ""
}
]
Once you have the genesis.json file ready on your development machine, it is time to upload it to all validator nodes.
Whether you are joining an existing testnet or building up a new one, additional configuration needs to be taken care of on each new Master node. You can specify the node configuration in the .beyondd/config/config.toml file that has been automatically generated when you ran the 'beyondd init' command.
The following settings need to be adjusted:
Once the configuration is complete, you can start the full node with the following command:
After at least three validators are running you should see blocks being periodically created and committed.
Accounts with their private keys are stored in "$HOME/.beyondcli". Private keys are stored armored (encrypted using a user-provided password) in database and are unarmored by beyondcli each time we sign a transaction.
Besides generic accounts we support mobility accounts used in scenarios related to wireless charging of vehicles. We use special DeepCover Secure Authenticator chip, which stores encrypted keys in EEPROM. Once the key is generated and stored, the EEPROM address is made write protected. When using this type of account, the transaction payload is signed by the chip. Transaction is verified on MasterNode with ECDSA algorithm using correct parameters such as Curve equation, X and Y part of public key, message digest and R,S parts of the signature.
The following command creates a new account on the client node:
NAME:
car
TYPE:
local
ADDRESS:
byndaddr1c4r7cgdyzpkdnnet8h8lgwf5n7zq3ctddggfx3
PUBKEY:
byndpub1addwnpepqfqjy2rh27cmvxx0m0h84j4z6kzxvr6m4ad40hrltqu6wl8cp4frxz4mjhy
Use the following command of beyondcli to list existing accounts, registered locally:
NAME:
car
fastcar
station
tesla
TYPE:
local
local
local
local
ADDRESS:
byndaddr1c4r7cgdyzpkdnnet8h8lgwf5n7zq3ctddggfx3
byndaddr19vvpsyqrfx8mha8kh229d3g23k4f6mcyfffr5e
byndaddr1mv2e82j0sxrg5c7dr7t5nc8cc6zvhgyqs9phrd
byndaddr12jltzqm663qt0rz5y354d06fgtv5mtndsq3t23
PUBKEY:
byndpub1addwnpepqfqjy2rh27cmvxx0m0h84j4z6kzxvr6m4ad40hrltqu6wl8cp4frxz4mjhy
byndpub1addwnpepqtduxppjugzdgwslw9en929pc8eqxz0yffs4qlqawc257f0gs0y3uxmvn5p
byndpub1addwnpepqdw295n2flsgzeldl4hggpkeunlpaqhwv03mwpxz62uelhc0k6ny7au7g56
byndpub1addwnpepqwze7u7ef0jfs3ehxfl6ghs6tzvyqlsez8ahg2dxkalquxn7ha345euhnsq
By default the configuration is taken from "$HOME/.beyondcli". We can override this by specifying --home parameter.
Here we query a charging station account, which shows among other fields:
Every client communicates with a designated Master node that we choose using the --node parameter. The parameter specifies the RCP endpoint of the Master node, which is by default exposed on port 26657.
If the communication succeeds, JSON output of the above command will be:
{
"type": "beyond/Account",
"value": {
"BaseAccount": {
"address": "byndaddr1mv2e82j0sxrg5c7dr7t5nc8cc6zvhgyqs9phrd",
"coins": [
{
"denom": "byndcoin",
"amount": "500000"
}
],
"public_key": {
"type": "tendermint/PubKeySecp256k1",
"value": "byndpub1addwnpepqdw295n2flsgzeldl4hggpkeunlpaqhwv03mwpxz62uelhc0k6ny7au7g56"
},
"account_number": "1",
"sequence": "100"
},
"name": "station",
"macAddress": "00-05-9A-3C-7A-00",
"price": "10"
}
}
InitOrder initializes new order and deterministically increments orderNumber for buyer of energy. OrderNumber is kept in application state on Master nodes for each beyond account.
beyondcli initOrder --from=car --amount=2 --to=byndaddr1j6j0f6kvs92zazh3tmjvvu8ga8x4h9hf5jxum9 --sequence=0 --chain-id=beyond-chain --node=beyond.link:26657
Password to sign with 'car':
Committed at block 43 (tx hash: 378EA8577E67DF99AB4E159A35E9E439CEBC9023)
FinalizeOrder performs actual transfer of coins which is calculated by provided charge in kWh multiplied by current price of the seller specified in "--to" address. FinalizeOrder checks correct InitOrder and links it via OrderNumber. Transaction details (inputs, outputs) and orderNumber are appended to transaction tags. Those can be queried later for analytics.
beyondcli finalizeOrder --from car --charge=2 --to=byndaddr1svf6jrfvfed33avtza9y9h8ckmcylpqsseeysn --sequence=0 --chain-id=beyond-chain --node=beyond.link:26657
Password to sign with 'station':
Committed at block 83 (tx hash: 5D2219CE78657A2A6D462B3DCA79E47601FFFE80)
Blockchain data can be queried via the light client (beyondcli) using its CLI interface or the REST API.
For instance, to query a committed transaction using an attached tag, the following CLI command could be used:
The same query could be made using the exposed REST API. For this, the client should first be initialized with a REST server running. Here, the ID of the blockchain must also be supplied.
Now we can issue a request against the endpoint.
If we wanted to list all transactions committed in a block at a given height, this is the command we would issue:
By default, the light client verifies the query results obtained from the blockchain (using the validator public keys, latest block hash and the Merkle proofs provided together with the query results). Also, the REST server establishes a secure SSL channel with the connecting client using a self-signed certificate.
Query response verification can be disabled when starting a REST server:
The SSL/TLS layer can also be skipped during initialization of the REST server:
