Can performance be expanded 10 times without sharding? A brief introduction to Ethereum Turbo-Geth client

Turbo-Geth started in 2017 (yes, during the crazy CryptoKitties-induced congestion) as a purely curious project. It started out as an exploration of alternatives to trie-based database schemas. In March 2018, the Turbo-Geth project received a small bonus ($25,000) from the Ethereum Foundation. In the first and second quarters of 2019, Turbo-Geth was used as a state analysis platform for State Rent research. By the third and fourth quarters of 2019, Turbo-Geth was also used to perform back testing of stateless Ethereum. Before Devcon5, I thought it was already solid in concept.

At Devcon5, I proposed to stop accepting EIPs within a year so that all implementations can be converted to similar data models. However, due to doubts and lack of enthusiasm from the "core developers" group, my proposal was not adopted.

The skepticism was mainly around ways to efficiently compute and update the state root hash. At EthCC 2020 in March 2020, we proposed a solution: an additional data structure called “Intermediate Hashes”. We fully implemented this solution in the following months.

The idea for staged sync came from observing per-table write churn measurements. The solution to data churn is to insert data in a pre-ordered sequence. We observed these phenomena carefully in late 2019, but our first experimental implementation showed significant performance benefits in February 2020.

Phased synchronization was a very significant change at the architectural level (but without major changes to the data model), and we implemented this feature from March to July 2020. Thanks to it, we were able to significantly (10 times) reduce the synchronization time.

In August 2020, we found a way to reduce the state representation data from 50 GB to 10 GB.

In September 2020, the “intermediate hash value” feature was made more granular, increasing the speed of calculating the state root hash by 4 times (from 200 ms to 50 ms) while reducing its data size from 7 GB to 2.5 GB.

We are currently developing a proper indexing of logs.

So what does all this mean?

In fact, this doesn't mean anything, because the current implementation has not yet reached the efficiency limit.

There are still a few "unsolved mysteries":

1. Merkle proofs for states in the distant past cannot be generated efficiently (there is no problem with the efficiency of generating Merkle proofs for recent history. This can be alleviated by introducing snapshots of intermediate hash values ​​(these data are relatively small)

2. Some consensus calculations do not work well with phased synchronization, and ideally, the two should be designed together.

Silkworm

The idea of ​​creating a modular Ethereum implementation written in C++ under the Apache 2.0 protocol began in early 2019, as we saw that the "Aleth" project had been largely abandoned.

But it wasn't a good time.

In May-June 2020, the time finally came. There were four major turning points:

1. We switched from BoltDB to LMDB (a database implemented in C) to ensure database compatibility between Turbo-Geth and Silkworm.

2. The phased synchronization pattern naturally breaks the implementation into relatively independent components, which basically interact through records in the database (or through pages in memory, if the interaction occurs within a database transaction). This means that we can create the C++ implementation component by component.

3. Earlier experiments with the EVM (using the EVMC interface) revealed the significant overhead of using a cross-language interface, which was exacerbated by the EVMC's dual interface.

4. We feel that we have enough experience to accomplish this in a foreseeable time (within 1 year, not 5 to 10 years) with the help of some experts.

future

Starting the Silkworm project also opened up our minds, for example, we can migrate the implementation piece by piece to other programming languages ​​(such as Rust).

I believe that Ethereum 1.0 can expand throughput by at least 10 times even without the introduction of sharding. We are facing three main challenges:

1. A higher gas limit for a block is more susceptible to DOS attacks. Turbe-geth's security limit may be 10 times higher than other implementations; and Silkworm may be even higher.

2. A higher gas limit will result in larger blocks. This in turn will cause two problems:

• Block transmission problem. This can be handled through pre-consensus (essentially sacrificing transaction latency in exchange for transaction throughput)

• Block download and storage issues. This can be solved by using specialized storage networks such as BitTorrent (such work is already in progress).

Link to this article: https://www.8btc.com/article/649566
Please indicate the source of the article when reprinting