Blockchain Research Engineer
Share Dialog
Share Dialog
Blockchain Research Engineer
Subscribe to Rabia Fatima
Subscribe to Rabia Fatima
<100 subscribers
<100 subscribers
Ever wonder why the Ethereum community is challenging the incomprehensible ideas for scalability? Why the researchers are persistently experimenting with scalable solutions to set foot on the highest transaction throughput without compromising the blockchain trilemma. Well, we have an answer to this. This is because the high demand for the layer1 network is creating a bottleneck for both the finality and gas fees.
To solve this stumble block many layer2 scalable solutions have been proposed but even on layer1 we have been provided with few possibilities such as sharding, rollups, and stateless clients to increase the network's overall health[1].
For now, In this particular article, we will be focusing on "The Stateless Clients."
Ethereum is a state machine that moves forward with each new block. At any instance, it provides a complete state of Ethereum consisting of the data related to all accounts and smart contracts running on the EVM. The state of Ethereum modifies whenever a transaction is added to the block by changing the balances of accounts. However, we know that the massive adoption is potentially increasing the global state size of Ethereum and hence arising few given problems.
Extensive syncing time for nodes.
High block verification time as reading and updating state from the storage root requires O(klog(n)) time(where n=state size and k=object access in a block). So as the state size increases the block verification will also increase.
Now, before getting into the depth of stateless clients, let's first get the idea of what state is and how it works in the context of Ethereum 1.0.
The state is the record status of all account balances and the collective memories of all smart contracts deployed and running on EVM. We know that the state is different for both UTXO and account-based systems. In this article, we will only focus on the account-based model such as Ethereum.
The state root of the hexary patricia tree or(merkle patricia tree)[1] can have upto 16 branches. In the case below there are only four branches attached to the state root. Each leaf node consists of the hash of the key value pair where the key corresponds to the account address and the value for externally owned accounts or contract accounts. In case of EOA, nonce and balance is stored, for smart contracts there is the addition of code hash(byte code of contract) and storage root.
Below is the graphical analysis of growing state size with respect to blocks. At the time of writing this, the total state size is 40GB. There are approximately 47M total accounts that have been listed on Ethereum out which 40M are of External type. Also there are a total of about 160M storage locations on Ethereum[2].
Getting back to our main focus, let's understand thoroughly why we need stateless clients and what they really are.
In 2017, Vitalik proposed the concept of stateless clients[2]. The purpose of stateless clients is to introduce a full type of node which does not require storing the state of the entire blockchain to verify a block. The term stateless clients are also important in terms of sharding in Eth 2.0, where validators will be shuffled around different shards, and quickly they will need to be synced to access the state of the shard. Note here that the beacon chain is not responsible for providing the global state to the validators. Instead, it is only accustomed to periodically shuffle the validators to different shards. In a nutshell, we can conclude that stateless clients will be a prominent breakthrough for block verification and cross sharding communication in ETH 2.0.
What comes to your mind when you think of stateless clients? Well, the stateless client is nothing but a concept that enables nodes to validate a block without storing the Ethereum state. The state which is required to validate a block of transactions is delivered to nodes as a witness. If you have any prior knowledge about how Zero Knowledge works, it is just like that. Proving a state without revealing the state of the blockchain. In our case, not revealing means not storing.
The stateless client has also introduced a concept of "Block Witness," which will validate a given state change against the previous state. The witness is the portion of the state which is to be read and modified along with the proof.
Block witnesses will allow stateless nodes to store only the state root instead of the entire merkle patricia trie[3]. This is to note here that we want to achieve weak statelessness, which states that only the validators are not required to store the state. The block proposers still need to keep the full state of Ethereum.
Note that, Stateless clients are for the validation process, not for the block proposition process.
The state transition function explains how the state machine, or simply Ethereum, changes its state in response to an event.
State Transition Function= STF(Block, State)= State'
** **We can modify the above formula for stateless clients using witness:
STF'(Block,State, Witness)= State'
STF is a function that takes the block, state, and witness as an input and uses the witness as a database (holding the details of all the accounts, storage keys, or other state data) for the execution of a new state.
The state root is the 32-byte root hash of the Merkle Patricia tree containing the balances of all accounts and contracts, while the witness is a set of Merkle branches proving the values of all data that the execution of block accesses. To simply say, rather than computing a complete state with each new block, clients can simply compute the changes to state for the new block while proving that those changes are consistent for the previous block.
The block validation will use the state commitment instead of the entire blockchain state. To validate a block there are three parameters required:
Block with transactions.
Data required to execute them.
A proof which verifies that the data is not tempered.
So the witness = (Data, Proof).
To explain more about point 3, it means that the previous root does contain data which verifies the credibility of the new data to be executed. Think of it in terms of double spending. But in this world nothing comes easy. With witness include the data, and proof at each level of the state trie the average size of the witness will drastically increase. To visualize this, see the picture below.
The green lines in the graph is the witness which is exceptionally huge. This shows that only using witness without optimizing its size can be a potential disaster for stateless clients. To alleviate the size of witness in stateless clients Dankrad Feist has suggested a method called “Polynomial Commitments”.
Stateless clients is an approach which appeared as the pinnacle of scalability and potential benefits. It is a disruptive technology which is creating groundbreaking updates in ETH 2.0. We are leaving the deeper dive into stateless clients for another post. If you have caught up till here, you are definitely going to get a deep understanding of its working process too.
Ever wonder why the Ethereum community is challenging the incomprehensible ideas for scalability? Why the researchers are persistently experimenting with scalable solutions to set foot on the highest transaction throughput without compromising the blockchain trilemma. Well, we have an answer to this. This is because the high demand for the layer1 network is creating a bottleneck for both the finality and gas fees.
To solve this stumble block many layer2 scalable solutions have been proposed but even on layer1 we have been provided with few possibilities such as sharding, rollups, and stateless clients to increase the network's overall health[1].
For now, In this particular article, we will be focusing on "The Stateless Clients."
Ethereum is a state machine that moves forward with each new block. At any instance, it provides a complete state of Ethereum consisting of the data related to all accounts and smart contracts running on the EVM. The state of Ethereum modifies whenever a transaction is added to the block by changing the balances of accounts. However, we know that the massive adoption is potentially increasing the global state size of Ethereum and hence arising few given problems.
Extensive syncing time for nodes.
High block verification time as reading and updating state from the storage root requires O(klog(n)) time(where n=state size and k=object access in a block). So as the state size increases the block verification will also increase.
Now, before getting into the depth of stateless clients, let's first get the idea of what state is and how it works in the context of Ethereum 1.0.
The state is the record status of all account balances and the collective memories of all smart contracts deployed and running on EVM. We know that the state is different for both UTXO and account-based systems. In this article, we will only focus on the account-based model such as Ethereum.
The state root of the hexary patricia tree or(merkle patricia tree)[1] can have upto 16 branches. In the case below there are only four branches attached to the state root. Each leaf node consists of the hash of the key value pair where the key corresponds to the account address and the value for externally owned accounts or contract accounts. In case of EOA, nonce and balance is stored, for smart contracts there is the addition of code hash(byte code of contract) and storage root.
Below is the graphical analysis of growing state size with respect to blocks. At the time of writing this, the total state size is 40GB. There are approximately 47M total accounts that have been listed on Ethereum out which 40M are of External type. Also there are a total of about 160M storage locations on Ethereum[2].
Getting back to our main focus, let's understand thoroughly why we need stateless clients and what they really are.
In 2017, Vitalik proposed the concept of stateless clients[2]. The purpose of stateless clients is to introduce a full type of node which does not require storing the state of the entire blockchain to verify a block. The term stateless clients are also important in terms of sharding in Eth 2.0, where validators will be shuffled around different shards, and quickly they will need to be synced to access the state of the shard. Note here that the beacon chain is not responsible for providing the global state to the validators. Instead, it is only accustomed to periodically shuffle the validators to different shards. In a nutshell, we can conclude that stateless clients will be a prominent breakthrough for block verification and cross sharding communication in ETH 2.0.
What comes to your mind when you think of stateless clients? Well, the stateless client is nothing but a concept that enables nodes to validate a block without storing the Ethereum state. The state which is required to validate a block of transactions is delivered to nodes as a witness. If you have any prior knowledge about how Zero Knowledge works, it is just like that. Proving a state without revealing the state of the blockchain. In our case, not revealing means not storing.
The stateless client has also introduced a concept of "Block Witness," which will validate a given state change against the previous state. The witness is the portion of the state which is to be read and modified along with the proof.
Block witnesses will allow stateless nodes to store only the state root instead of the entire merkle patricia trie[3]. This is to note here that we want to achieve weak statelessness, which states that only the validators are not required to store the state. The block proposers still need to keep the full state of Ethereum.
Note that, Stateless clients are for the validation process, not for the block proposition process.
The state transition function explains how the state machine, or simply Ethereum, changes its state in response to an event.
State Transition Function= STF(Block, State)= State'
** **We can modify the above formula for stateless clients using witness:
STF'(Block,State, Witness)= State'
STF is a function that takes the block, state, and witness as an input and uses the witness as a database (holding the details of all the accounts, storage keys, or other state data) for the execution of a new state.
The state root is the 32-byte root hash of the Merkle Patricia tree containing the balances of all accounts and contracts, while the witness is a set of Merkle branches proving the values of all data that the execution of block accesses. To simply say, rather than computing a complete state with each new block, clients can simply compute the changes to state for the new block while proving that those changes are consistent for the previous block.
The block validation will use the state commitment instead of the entire blockchain state. To validate a block there are three parameters required:
Block with transactions.
Data required to execute them.
A proof which verifies that the data is not tempered.
So the witness = (Data, Proof).
To explain more about point 3, it means that the previous root does contain data which verifies the credibility of the new data to be executed. Think of it in terms of double spending. But in this world nothing comes easy. With witness include the data, and proof at each level of the state trie the average size of the witness will drastically increase. To visualize this, see the picture below.
The green lines in the graph is the witness which is exceptionally huge. This shows that only using witness without optimizing its size can be a potential disaster for stateless clients. To alleviate the size of witness in stateless clients Dankrad Feist has suggested a method called “Polynomial Commitments”.
Stateless clients is an approach which appeared as the pinnacle of scalability and potential benefits. It is a disruptive technology which is creating groundbreaking updates in ETH 2.0. We are leaving the deeper dive into stateless clients for another post. If you have caught up till here, you are definitely going to get a deep understanding of its working process too.
No activity yet