Discussion on the optimization scheme of the lower chain in Ethernet square

Because of its own characteristics, the etheric square with the number of blocks only increase does not decrease. This causes the size of the etheric square blocks to become more and more bloated as the transaction progresses. More and more bloated will lead to query and read data from the ether (also known as "the next chain") more difficult, time-consuming, very inconvenient. Therefore, it is necessary and valuable to design a lower chain method with a short time consuming.
This article mainly discusses three kinds of down-chain methods based on Python. These three kinds of down-chain methods can only be used in the last one, because there are different problems and drawbacks in the first two kinds. But in the perspective of technology-sharing and communication, here is a separate discussion. first, explore the jsonrpc of the underlying call mode and Geth source

(i), explore the jsonrpc of the underlying call mode

The way Python uses the etheric square is through a ETHJSONRPC package. The rationale is that Python uses the Curl command in RPC to tune the interface to the Tai Fong. For example, use the Eth_blocknumber () method to get the total number of blocks currently in the entire Etheric square. Its operating principle is as follows:
After Python uses the Eth_blocknumber () method, the method internally executes the following request via RPC

Curl–x POST--data ' {jsonrpc ': ' 2.0 ', ' method ': ' Eth_blocknumber ', ' params ': [], ' ID ': 83} '

After performing the above curl request, get the returned JSON data element, extract the desired result and convert//decimal, which is the outcome of the Eth_blocknumber () method eventually returned.

{
  "id": "
  Jsonrpc": "2.0", "Result
  ": "0x4b7"//1207
}

After understanding the operating principle of JSONRPC, we can consider whether there is a fast query retrieval method in the Jsonrpc methods Library, which can be used to find the hash table based on the inherent attributes of the block chain. Detailed details are as follows:
Https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_newblockfilter
After looking, unfortunately we only found the Eth_gettransactioncount () this one can only get the number of all transactions issued by an account, not find a way to query the number of transactions issued or received, transaction hash code and other important information.
So this approach does not work, you need to consider a more low-level approach, that is, from the Geth source code to find the number of transactions issued or received, transaction hash code and other important information methods.

(ii), explore the source code of Geth

Because to use the current operation of the ether, we can not modify the source of the way we create a fast query retrieval function, only in the actual operation of the ether version of the corresponding source code found and used. It is still regrettable that the source code does not provide the means to achieve the functions we need. The source link is as follows:
Https://github.com/ethereum/go-ethereum/blob/master/ethclient/ethclient.go
Therefore, we need to change the direction of thinking. second, use other storage mode to store the chain information temporarily

This is a relatively easy way to think. We can use local files, local databases, and so on each of our chain of information such as the transaction issued by the account, the transaction recipient account and the transaction hash code these three information to save. The chain is then not traversed from the entire etheric square, but is read from the local storage that holds the information and is traversed.
This can save a lot of unnecessary time overhead, but it goes against the purpose of using the etheric square-to avoid the immutable nature of the information on the chain. Because the information stored locally can allow users to change at will.
Therefore, this plan does not work in the realization of the purpose. third, set a reasonable block query interval

Since neither of the first two approaches works, we need to consider another approach in other ways. Through the actual chain operation, we find that the total block number of the whole Ethernet square is not growing fast. Therefore, we can fully consider not traversing the entire etheric square from beginning to end, but starting from a certain position, which can reduce the time consumption to some extent.
Although this plan also has the imperfect place, but it is the present three most feasible, moreover is also easiest to realize. This approach can temporarily alleviate the problem, but not the long-term.

Finally, we welcome the vast number of Ethernet players and enthusiasts to put forward better, innovative and efficient methods, we progress together to grow.