Client improvements for a resilient Ethereum
Our client engineering team is constantly working on improving stability, performance, and user experience.
Our goal is to make it faster and easier to access information within the state tree. In Ethereum, the state is stored in a structure called the Patricia Merkle Trie, which uses account addresses as pathways to find the actual data. To access an account or smart contract, you have to go through several nodes in the tree, which are stored in a database using their content's hash. This process can take time and involves multiple reads.Our team is implementing a flat database design that aims to speed up the accessing of data from the state tree. By using account addresses directly as the keys, we can reduce the number of database reads needed. This improvement will help accelerate transaction processing, virtual machine execution, and API calls and it is a prerequisite for snapshot serving functionality.
The snap syncing method streamlines the process of downloading state information from the network. Instead of downloading every state node, it fetches accounts along with their proofs and uses this information to rebuild the trie locally. This approach is much faster, but it requires network participants to prepare data in a specific way for others to use.
Accounts must be organized by address range, which in turn requires quick access to state information. Currently, only one Ethereum client can serve snap sync data, which can create issues related to network resilience and efficiency. Building this feature in Nethermind will help increase diversity among clients in the execution layer, leading to a more robust and efficient network.
EIP-4844 Shard Blob Transactions
EIP-4844 will bring a novel transaction type to Ethereum. They advance Ethereum’s scaling roadmap by permitting the temporary storage of data "blobs" within the beacon node. Such transactions are ideal for holding proofs of L2 networks, freeing up block space for other participants by adding an extra gas dimension.
At Nethermind we started implementing our blobs during the early stages of integration of the EIP and we actively participate in the discussion around the EIP. The aim is to deliver fast and stable handling of Shard Blob transactions and an efficient transaction pool for them. We are happy to provide technical insights and guiding for those who want to integrate this new transaction type.
Client improvements for a resilient Ethereum
Our client engineering team is constantly working on improving stability, performance, and user experience.

Flat database layout
Our goal is to make it faster and easier to access information within the state tree. In Ethereum, the state is stored in a structure called the Patricia Merkle Trie, which uses account addresses as pathways to find the actual data. To access an account or smart contract, you have to go through several nodes in the tree, which are stored in a database using their content's hash. This process can take time and involves multiple reads.
Our team is implementing a flat database design that aims to speed up the accessing of data from the state tree. By using account addresses directly as the keys, we can reduce the number of database reads needed. This improvement will help accelerate transaction processing, virtual machine execution, and API calls and it is a prerequisite for snapshot serving functionality.
.svg)
Snap serving
The snap syncing method streamlines the process of downloading state information from the network. Instead of downloading every state node, it fetches accounts along with their proofs and uses this information to rebuild the trie locally. This approach is much faster, but it requires network participants to prepare data in a specific way for others to use.
Accounts must be organized by address range, which in turn requires quick access to state information. Currently, only one Ethereum client can serve snap sync data, which can create issues related to network resilience and efficiency. Building this feature in Nethermind will help increase diversity among clients in the execution layer, leading to a more robust and efficient network.
.png)
EIP-4844 Shard Blob Transactions
EIP-4844 will bring a novel transaction type to Ethereum. They advance Ethereum’s scaling roadmap by permitting the temporary storage of data "blobs" within the beacon node. Such transactions are ideal for holding proofs of L2 networks, freeing up block space for other participants by adding an extra gas dimension.
At Nethermind we started implementing our blobs during the early stages of integration of the EIP and we actively participate in the discussion around the EIP. The aim is to deliver fast and stable handling of Shard Blob transactions and an efficient transaction pool for them. We are happy to provide technical insights and guiding for those who want to integrate this new transaction type.