Thank you for taking the time to read my stuff 😄 [Twitter](https://twitter.com/brechy_)
Share Dialog
Share Dialog
Thank you for taking the time to read my stuff 😄 [Twitter](https://twitter.com/brechy_)
Subscribe to Brechy
Subscribe to Brechy
<100 subscribers
<100 subscribers
One of the fundamental properties of the blockchain protocols that we use is trustlessness, we don’t need to know or trust each other for the system to function as expected. However, the majority of users that interact with them do so trusting a third party and what they claim to be the true state of the network.
Running a blockchain client is not so straightforward, one should be able to afford the required resources and have the time to maintain it. In this post, I’ll talk about light clients, a solution to enable end users to access the network in a similar way as with a standard node, but without incurring in all the effort.
A light client (or light node) is a lightweight implementation of a node, designed to run in constrained environments such as web browsers or embedded systems.
The low resource requirement nature of light clients will allow them to be implemented in mobile phones, wallets, browsers, and any other application or hardware that needs connection with the blockchain. The requirements for storage, memory and networking are minimal compared to a regular node instance.
Light clients are a key part of a decentralized protocol. Without them, the only way that low resource environments or users that are not running a node are able to interact with the blockchain is through providers.
A provider is a centralized entity that facilitates the infrastructure to easily communicate with Ethereum, making it super convenient for DApps and Wallets.
The main reasons of why to avoid providers are:
Data: They handle (and some collect) a lot of user data such as IPs, wallet addresses, contracts interactions, and state data queries.
Censorship: Requests could be blocked by country of origin, destination or origin addresses, or any other imposed or arbitrary restriction.
Trust: Submitted transactions could be economically exploited and received data it’s not verified.
There are two challenges for light client implementations that I’d like to go through:
Verify the state of the blockchain without storing it’s history.
Keep track of the head of the chain inexpensively.
The state of Ethereum is stored using a Merkle Patricia Tree. This wonderful data structure allows us to verify specific data with a small amount of hashes (merkle proofs) including the root one. The state root is stored on every block, so we need to be certain that the block is valid and belongs to the canonical chain, and also a way to request the necessary proofs.
In PoW Ethereum, without block finality, the second one was a real issue. In PoS there had to be a way to do it inexpensively, without counting the votes of the entire validator set to know which is the header block. This is why in the Altair hard fork, sync committees were introduced.
A sync committee is a subset of randomly selected validators that have the responsibility of verifying and signing the submitted blocks. It consists of 512 validators, which are shuffled using RANDAO every 8192 slots (~27 hours).
Once a new block is submitted, each of these validators will verify the state transition and sign the block if it’s valid. All of these signatures are submitted to the chain and aggregated by the block builder using BLS, including this aggregated signature in the next block. At least 2/3 of the committee should sign to deem a block as valid.
This can then be verified with the public keys of every validator in the sync committee, but how can we be certain that the received sync committee is valid and is the current one selected by the protocol? To verify this we rely on a trusted past state root, the weak subjectivity checkpoint.
A weak subjectivity checkpoint is a block that the entire network agrees on as always being part of the canonical chain. This provides us with a trusted past state root, and there is a limit of how far in the past this point could be. The “subjective” comes from not having the set of all blocks to reach the current state of the network, but instead relying on a state that is agreed or known to be valid.
But since we need the current block header, we need a way to get from this point in history to the current state.
To get from our checkpoint to the latest sync committee, we bootstrap the process by requesting the sync committee for our trusted root and the next selected sync committee (for that period). This process repeats until we reach the committee that signs the current finalized header.
We can now be sure (on a good enough level) that the sync committee is valid. We keep observing finality updates and tracking the state roots, this will allow us to verify the chain state, once we get the required proofs.
For this we rely on the EIP-1186 (eth_getProof), which is a RPC-Method to request Merkle Proofs for the state of an account. This method returns the merkle proofs to validate the necessary data for the specified account.
A light client still needs access to:
Consensus - Beacon API
Execution - Execution RPC
Progress is being made to access both through a p2p layer, but in the meantime even if we use a centralized provider we don’t have to trust the data they’re sending to us.
There is good work going on in exposing the execution RPC by Portal Network, it will be comprised of multiple decentralized peer-to-peer networks, each with a specific subset of functionality, and every participant can contribute to the network. This is a major difference with LES, a project that provides support to light clients based in a client/server architecture.
I hope to have brought some light into this great technology. The overall benefit that this brings to the end users is huge, even for those that are not aware of how much they’re trusting third parties right now. There’s no doubt that there is plenty of work ahead, but every effort in light client support and the multiple implementations is worthwhile.
https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/
https://notes.ethereum.org/@vbuterin/extended_light_client_protocol
https://blog.chainsafe.io/the-road-ahead-for-ethereum-light-clients-b6fdb7c3b603
https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity
https://mycelium.xyz/research/world-of-light-clients-ethereum
https://a16zcrypto.com/building-helios-ethereum-light-client/
One of the fundamental properties of the blockchain protocols that we use is trustlessness, we don’t need to know or trust each other for the system to function as expected. However, the majority of users that interact with them do so trusting a third party and what they claim to be the true state of the network.
Running a blockchain client is not so straightforward, one should be able to afford the required resources and have the time to maintain it. In this post, I’ll talk about light clients, a solution to enable end users to access the network in a similar way as with a standard node, but without incurring in all the effort.
A light client (or light node) is a lightweight implementation of a node, designed to run in constrained environments such as web browsers or embedded systems.
The low resource requirement nature of light clients will allow them to be implemented in mobile phones, wallets, browsers, and any other application or hardware that needs connection with the blockchain. The requirements for storage, memory and networking are minimal compared to a regular node instance.
Light clients are a key part of a decentralized protocol. Without them, the only way that low resource environments or users that are not running a node are able to interact with the blockchain is through providers.
A provider is a centralized entity that facilitates the infrastructure to easily communicate with Ethereum, making it super convenient for DApps and Wallets.
The main reasons of why to avoid providers are:
Data: They handle (and some collect) a lot of user data such as IPs, wallet addresses, contracts interactions, and state data queries.
Censorship: Requests could be blocked by country of origin, destination or origin addresses, or any other imposed or arbitrary restriction.
Trust: Submitted transactions could be economically exploited and received data it’s not verified.
There are two challenges for light client implementations that I’d like to go through:
Verify the state of the blockchain without storing it’s history.
Keep track of the head of the chain inexpensively.
The state of Ethereum is stored using a Merkle Patricia Tree. This wonderful data structure allows us to verify specific data with a small amount of hashes (merkle proofs) including the root one. The state root is stored on every block, so we need to be certain that the block is valid and belongs to the canonical chain, and also a way to request the necessary proofs.
In PoW Ethereum, without block finality, the second one was a real issue. In PoS there had to be a way to do it inexpensively, without counting the votes of the entire validator set to know which is the header block. This is why in the Altair hard fork, sync committees were introduced.
A sync committee is a subset of randomly selected validators that have the responsibility of verifying and signing the submitted blocks. It consists of 512 validators, which are shuffled using RANDAO every 8192 slots (~27 hours).
Once a new block is submitted, each of these validators will verify the state transition and sign the block if it’s valid. All of these signatures are submitted to the chain and aggregated by the block builder using BLS, including this aggregated signature in the next block. At least 2/3 of the committee should sign to deem a block as valid.
This can then be verified with the public keys of every validator in the sync committee, but how can we be certain that the received sync committee is valid and is the current one selected by the protocol? To verify this we rely on a trusted past state root, the weak subjectivity checkpoint.
A weak subjectivity checkpoint is a block that the entire network agrees on as always being part of the canonical chain. This provides us with a trusted past state root, and there is a limit of how far in the past this point could be. The “subjective” comes from not having the set of all blocks to reach the current state of the network, but instead relying on a state that is agreed or known to be valid.
But since we need the current block header, we need a way to get from this point in history to the current state.
To get from our checkpoint to the latest sync committee, we bootstrap the process by requesting the sync committee for our trusted root and the next selected sync committee (for that period). This process repeats until we reach the committee that signs the current finalized header.
We can now be sure (on a good enough level) that the sync committee is valid. We keep observing finality updates and tracking the state roots, this will allow us to verify the chain state, once we get the required proofs.
For this we rely on the EIP-1186 (eth_getProof), which is a RPC-Method to request Merkle Proofs for the state of an account. This method returns the merkle proofs to validate the necessary data for the specified account.
A light client still needs access to:
Consensus - Beacon API
Execution - Execution RPC
Progress is being made to access both through a p2p layer, but in the meantime even if we use a centralized provider we don’t have to trust the data they’re sending to us.
There is good work going on in exposing the execution RPC by Portal Network, it will be comprised of multiple decentralized peer-to-peer networks, each with a specific subset of functionality, and every participant can contribute to the network. This is a major difference with LES, a project that provides support to light clients based in a client/server architecture.
I hope to have brought some light into this great technology. The overall benefit that this brings to the end users is huge, even for those that are not aware of how much they’re trusting third parties right now. There’s no doubt that there is plenty of work ahead, but every effort in light client support and the multiple implementations is worthwhile.
https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/
https://notes.ethereum.org/@vbuterin/extended_light_client_protocol
https://blog.chainsafe.io/the-road-ahead-for-ethereum-light-clients-b6fdb7c3b603
https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity
https://mycelium.xyz/research/world-of-light-clients-ethereum
https://a16zcrypto.com/building-helios-ethereum-light-client/
No activity yet