For Dapp ETH programmers, it would not be strange for the web3.js library to communicate with ethereum nodes, web3 gives us a relatively standard set of interfaces for RPC methods.

Usually, Dapp applications with ETH or chains forked from ETH can use web3, which is all the functions needed, but recently I have developed some applications that require a fairly fast response. had to fumble directly into RPC to speed up data retrieval.

What is RPC?

So what is RPC?

Most of us are more familiar with the REST architecture as it is mostly applied in client / server applications – where clients are interested in retrieving information and manipulating them based on managed resources. managed by a server.

On the RPC side, this technology is often seen when building decentralized systems, as the name implies RPC – Remote Procedure Call . RPC can roughly understand that we call a procedure (procedure) from another machine that does not share the same process with the machine that executes the procedure and then communicates by message. Can be temporarily understood as A gives B a function and asks B to execute because that function is implemented on B, after the implementation is completed, nothing will be left for A.

JSON RPC API

Above is the basic knowledge, if you want to learn more about the definitions of RPC or REST , you can search very easily on Google. In this article, I want to introduce JSON RPC to the blockchain fork network from ETH, so I will only mention the simple knowledge.

Prepare

Regarding preparation, we will make a small project and will need something like

• Remix editor: Used to deploy contracts as well as create transactions – https://remix.ethereum.org/
• Ganache-clie: Simulate a blockchain network – https://github.com/trufflesuite/ganache-cli

This article I mostly introduce a different direction instead of using the existing API of web3 that will crash directly into RPC so it will be most of the operations on the console screen.

Deployment

The first is to design a simple Smart contract :

The above smart contract simply contains 2 variables owner and count and an Event Increase , after deploying, we can use RPC to get the information from the node deploying the transaction.

You can deploy directly on the JavaScript VM environment and create transactions, but to interact via RPC we must initialize a node to simulate the chain, to initialize, we will use the Ganache library -cli .

Deploy contract by remixing on the JavaScript VM

To initialize a simulation node, we will use the ganache-cli library with the command in the terminal:

The parameters are added with the purpose:

• host : the address of the host running the node
• blockTime : The time a new block was created
• networkId : ChainId of network

In addition to these parameters, you can customize the ganache network according to your purposes, to see the types of parameters, you can run the command to see:

After that, the network will run:

Next we will use remix to connect to the ganache network we just created

In the Environment section, to interact with the newly created network, we will select the Web3 Provider (As you can see, chainId will become 12345678 but we pass param –networkId)

And we will try deploying the contract on this network:

The initial owner value will be the deploy contract address and the count value is still 0 as the initial value.

Create a transaction increase and see the transaction log as:

Transaction increase will emit an Event and will generate logs, change storage:

• The value of count 0 -> 1
• log generates sender and count

RPC call

If you follow the steps above, the RPC call will look like the following

And I will explain these parts as follows:

• method : the procedure name you want to call VD: web3_clientVersion, web3_sha3, ….
• params : These are the params in the requests that make the filters, they act as filter condition values
• id : This value will be very useful when you use technologies like websocket – where a response stream is received, it works to map between request and response, in case of simply using HTTP POST to If you send a message, it won’t have much effect.

NOTE

With the value passed in JSON will need to pay attention to two types that we must convert to HEX before making the request:

• QUANTITIES (integer, number values): These values ​​must be opposite to HEX and prefixed by 0x
  • 0x41 (65 in decimal)
  • 0x400 (1024 in decimal)
  • WRONG: 0x (must always have at least 1 digit “0x0”)
  • WRONG: 0x0400 (don’t allow first letter as 0)
  • WRONG: ff (prefix must always be 0x)
• UNFORMATTED DATA (wallet address value, array of bytes, hash, bytecode array): Encode to hex, prefix with 0x, 2 hex digits for each byte.
  • 0x41 (size 1, “A”)
  • 0x004200 (size 3, ” 0B 0″)
  • 0x (size 0, “”)
  • WRONG: 0xf0f0f (the number of digits must be even)
  • WRONG: 004200 (prefix 0x)

List of JSON APIs you can find here: https://github.com/ethereum/wiki/wiki/JSON-RPC#json-rpc-api-reference

First, you can call a simple request as follows to get the blocknumber at the present time:

The return value is 0x839 (2105 in decimal) which is the current block value when calling the request.

The above request simply gets the data back, followed by a function that requires input parameters

eth_getStorageAt

Returns the value stored in the contract’s storage

contract that we deployed:

The address of my contract is 0x1Afc3fdC7884c6a2064c2f39c60d62a7a042703A There are 3 params to pass:

• DATA, 20 Bytes – contract address.
• QUANTITY – location of the variable you want to get, which has been converted to hex.
• QUANTITY | TAG – blockNumber wants to read eg: latest to see the value by the latest block

The second value in the params array is the position of the slot that I want to get from the contract, as you can see, that value is 0x0 similar to the first slot is the value of the owner variable – the address of the deployed contract. : 0x9bda73b2b006e2ffbe76a352018e8587f98700ca

eth_getLogs

Used to filter the log value that the event was emit during the creation of the transaction. In this function you will encounter a type of params that receives an object to filter events by that object value

Example:

Where these parameters will be:

• fromBlock: block start filter
• toBlock: block ending filter (default leaves latest)
• address: Address of contract filter
• topic: filtered value – there will usually be an initial value of hash256 of the event (in this case, hash256 of Increase (address, uint256)), followed by an indexed value to filter.

In this case our query to retrieve the Event log was fired after running the Increase transaction.

The data section has the result:

That is the event that we emit and convert it to decimal is the value 1 – the value of count

value 0x12007e72f6f07d1e7dd33219d5187184ceba138e79459b6c241cec9a9399fe0c in the topic section is the sha256 code of the event we want to filter

Conclude

The above are the most basic examples that I would like to introduce to you about the RPC of chains forked from ETH. You can do a little test to test the speed of RPC by trying subcribe Event and polling Logs continuously to compare the speed.

My article is also just done on the simulation environment, the ability to run the actual response time will be different when the nodes are far apart as well as the custom of each network.

Currently I am building an application that requires high speed but only experiment on the emulator node, when putting on the mainet, maybe I will continue to write an article to review whether this method is really useful. Useful when building dapps that require high real time or not.

Refer

• JSON RPC