The Turbo-Geth client Beta version plans to introduce mining functions, consensus engine components, and simplify block downloads.
Original title: “Introduction | Turbo-Geth Client: Beta Version Goals”
Written by: ledgerwatch
Translation: Ajian
We have not fixed the time point for the transition from the Alpha stage to the Beata stage. We, in turn, determined some prerequisites for moving to the Beta version; fulfilling these conditions means that turbo-geth is ready. Here is the list we want to achieve:
Mining function
The difficulty for turbo-geth to support efficient mining is that at any point in time, there is only one state that is “recognized as the latest” state. Mining requires nodes to generate “speculative” blocks and “speculative” states to calculate the state root hash value required in the block header of the new block. The current thinking is that the “speculative” state is a cache in memory, and it can be “copied”. “Copy” means to create a lazy-shallow copy of the cache, so that changes to the copy will not affect the recognized latest state saved by the node.
However, facts have also proved that the current data model consisting of hashed state ( HashedState ) and intermediate hashes ( IntermediateHashes ) is not suitable for maintaining such a cache. So we are working on correcting the data pattern, hoping to realize a state cache that can be replicated, and then realize the mining function.
Simplify block header and block body download
In the current staged synchronization, the block header and block body download are arranged in stage 1 and stage 3 respectively. Regardless of how they look or are used, these two stages are very different from other stages, because they are developed on the basis of the block header/block body/receipt/status download implementation inherited from the go-ethereum client. These codes have more functions than turbo-geth’s phased synchronization needs, and can (and should) be replaced with simplified versions. This simplified version has a proof of concept available, and can now be tested and documented.
Consensus engine components
There is a concept called “pluggable consensus”, which means that the client should be able to easily migrate from proof of work to proof of authority (PoS), including the ability to switch from one variant of proof of work to another. One variant, switching from one variant of PoA to another. In fact, some people used interfaces to implement plug-and-play consensus mechanisms, but because they still run in the same process, they are usually closely intertwined with other codes. We are already designing an interface that allows the consensus engine to run in a separate process.
With such an interface, although it can still run in the same process, this interface can more directly separate the consensus engine from the transaction execution. We have implemented a proof-of-concept for EtHash PoW and Clique POA, and are now preparing to integrate, test and write documentation.
Migrate from LMDB to MDBX
The turbo-geth client started from the BoltDB database backend and is now adding support for BadgerDB. Finally, we will fully migrate to LMDB. Sometimes the way we use LMDB will have some stability problems, which even the creator of LMDB did not expect. Therefore, we have been investigating a more supportive variant of LMDB called MDBX, hoping to take advantage of its stability improvement and make all functions more closely integrated in the future. The integration of MDBX has been completed, and now it is necessary to test and write documentation.
Source link: github.com
Disclaimer: As a blockchain information platform, the articles published on this site only represent the author’s personal views and have nothing to do with ChainNews’ position. The information, opinions, etc. in the article are for reference only, and are not intended as or regarded as actual investment advice.
