The TezEdge node — A deep dive into the mempool, part 2
The blockchain sandbox
The blockchain is a high stakes environment. Once smart contracts are deployed on the live network, there is no turning back, and faulty code or errors may cause enormous financial damage or other serious real world consequences.
It is useful for developers to work in an environment which they can fully control. One in which they can set the parameters, create funds for testing purposes and try out the features of the node’s various modules, for example the mempool.
For this reason, we are creating the Tezos sandbox, an offline tool that simulates the Tezos blockchain. This allows you to safely develop, test and deploy your and smart contracts without needing to connect to the Tezos network, or even the internet itself.
We made use of the sandbox while developing the TezEdge node’s mempool.
When an operation is injected into the node’s mempool, there are two possible points of origin:
- From other nodes in the network
- Via RPCs from the node itself
Since there currently is no client for sending custom messages to the node via the P2P network, we make use of remote procedure calls (RPCs) that allow us to inject operations that are created locally into the node’s mempool.
Using CI tests to demonstrate operation injection via RPCs
The objective here is to demonstrate that operations are injected into the TezEdge node’s mempool via RPCs and are then broadcasted to other nodes (including OCaml nodes) across the Tezos network. We utilize continuous integration (CI) tests as proof of this mechanism.
CI is a practice in software development used to continuously check the quality of new changes made to a project. CI tests ensure the changes proposed by each pull request will not cause errors or otherwise endanger the software.
By using CI, we can easily track the exact moment where development goes wrong, meaning that we can quickly find out which pull request contained the faulty code and thus avoid merging it with the main branch.
Testing operation injection into the mempool and broadcasting between nodes
When we run the sandbox, the genesis block already exists, which means we now have to activate the protocol. The Tezos client creates the first block and injects it into the Rust node, where it activates the protocol. From there, the block is broadcasted to the OCaml node where it also activates the protocol. Once the protocol is activated, we test the injection of operations.
Here you can see the aforementioned CI tests:
https://github.com/tezedge/tezedge/blob/master/.drone.yml#L99
This test is similar to the one we described in our previous article. The difference is that now we can demonstrate the injection of the first block and an operation into the TezEdge node.
1.First, we run two nodes; the TezEdge node (tezedge-node-sandbox-run) and the OCaml node(ocaml-node-sandbox-run) , both are run in sandbox mode. This is done in the first four steps in the CI pipeline. After each run step there is a so-called wait-for step which ensures that the pipeline is held until each node has started successfully.
2. Using the Tezos-admin-client, we create a connection between the two nodes. You can see this in the connect-ocaml-and-rust step
3. In the next step, we prepare the tezos-client. This means including the accounts used in the protocol activation and the transfer operation. Then, using the Tezos-client, we activate a protocol inside the TezEdge node, thus creating the first block. This is a distinct block that contains a block header and the field “content” in which there are subfields such as “command”, “hash”, “fitness” and “protocol_parameters”.
In step wait-for-sync-on-level-1 we wait until the OCaml node synchronizes with the TezEdge node which has the newly injected block on level 1.
4. The next step is a check to ensure that both nodes have an empty mempool. We call each node with the pending_operations RPC and compare the return values. We want both return values to be empty, which means their mempools are empty.
5. Using the Tezos client, we inject a valid transaction into the TezEdge node. This is demonstrated in step do-transfer-with-tezos_client.
To help you understand how RPCs are used to ‘inject’ operations into the mempool, we will explain through a hypothetical Inject Operation.
This is done by the tezos-client (via RPCs)
5.1 Collecting data from the node
5.2 Simulating the operation
5.3 Running the pre-apply operation
5.4 Injecting the transaction
5.5 After injection, inside the node:
5.5.1 Messaging the shell channel
5.5.2 Inserting into pending operations
5.5.3 Moving the operation towards validation
5.5.4 Broadcasting the new mempool state
6. In the step check-mempool-after-transfer, we call each node with the pending_operations RPC again and compare the return values. Again, we should see the same value from calling both nodes, but this time it will not be empty. We can see the operation in the applied field. This means that the transaction has been successfully propagated from the TezEdge node into the OCaml node.
You can see the results of the entire process here:
http://ci.tezedge.com/tezedge/tezedge/955/2/1
We appreciate your interest in learning more about Tezos and thank you for the time spent reading this article. If you have any questions, feedback or comments, you are welcome to send me an email. To read more about Tezos and the TezEdge node, please subscribe to our Medium, view our documentation or visit our GitHub.
