Current status of Silkworm and SilkRPC projects (Ethereum C++)

In one of the previous posts, a short history of Silkworm project was introduced: LINK. Silkworm is an implementation of Ethereum, written in C++ from scratch (meaning that it did not inherit code from any previously written implementations, like Aleth), starting from wrapping evmone EVM implementation. Two diagrams introduced in the previous posts, will be used to describe roughly the current status of Silkworm (and SilkRPC).

Firstly, the architecture diagram:

In the diagram above, and also in the one below, a somewhat traditional colour coding is used - red for things that have not been started yet, amber (orange) - for things that are in progress but not finished yet, and green - for things that are done (but will be improved over time, of course).

The amber box with “ETH core” corresponds to the bulk of the silkworm project in this repository. Another amber box, “ETH RPC api(s)” corresponds to the silkrpc project in this repository. SilkRPC project uses Silkworm as a library, in order to run EVM inside such RPC methods as eth_call.

Broadly, silkworm, as being developed, is currently compatible with Erigon’s ETH Sentry component, and silkRPC is compatible with Erigon’s ETH core and Erigon’s TxPool components. Also, silkworm maintains database-level compatibility with Erigon beta (the version which will only work on Ethereum main net until Ethereum POS transition, and then superseded by Erigon alpha).

SilkRPC has a lot of functionality that Erigon’s RPC daemon has, but in comparison has many more tests, including performance benchmarks.

Below is the second diagram which zooms specifically into silkworm:

Initially, the development of silkworm was focused on creating and testing individual stages in separation. Erigon was used to prepare the database state for these stages. Later, the work started on implementing two stages that depend on interaction with peers (via Sentry component provided by Erigon), as well as on assembly of the Silkworm StageLoop and converting disparate binaries (one per stage) into a useable product with all stages integrated into one binary.

As shown above, work is currently being done on the stages responsible for downloading block bodies and maintaining the state root hash.

The two most challenging stages

It has become a somewhat surprising, but now recognised experience that the two stages from the diagram above, which turned out to be most challenging in Erigon, then Silkworm (and also Akula, Rust implementation) are “Headers” stage (downloading header chain) and “Trie” stage (computing state root hash).

However, it appears that we are gaining better conceptual understanding of why these stages are challenging, and, as a result, simpler constructions appear iteratively. In Erigon, the simplification of “Headers” stage is ongoing. For Erigon 2 Upgrade 3, a new algorithm of calculating and updating state root hash has been created, and this algorithm promised to be much more tractable.

Performance

Silkworm uses evmone as its EVM interpreter, which is already known to be the fastest fully compatible EVM implementation. In addition to that, Silkworm uses MDBX, which is the fastest embedded key-value store with fully ACID transactions and MVCC (Multi-Version Concurrency Control). And on top of that, Silkworm has been written with performance being one of the highest priorities. In all stages it currently implements, silkworm beats Erigon in processing speed.

As mentioned above, silkRPC includes performance benchmarks, comparing it to Erigon’s RPC Daemon. On these benchmarks, it shows improvements over Erigon’s RPC Daemon especially under highly concurrent load. SilkRPC uses C++ co-routines, a relatively new feature introduced in C++20, to orchestrate such highly concurrent operations efficiently.

Software licence

Silkworm and silkRPC are both licences under Apache 2.0. Not sure how important this will turn out to be, but this may be a benefit for some users.