Content
@
0 reply
0 recast
0 reaction
ncitron.eth
@ncitron.eth
I've been seeing more support for relaxing Ethereum's use of state merklization by delaying it by a block or only computing the root every n blocks. Friendly reminder that without some form of up to date commitment to the state (like a merkle root) general purpose light clients basically cannot function.
6 replies
0 recast
14 reactions
shazow
@shazow.eth
Is delaying by 1 block enough to break light clients? Isn't this what cosmos does?
1 reply
0 recast
1 reaction
c-node
@colludingnode
Despite being a light client maxi, I support this We need light clients, by we don’t need them to be as fast as full nodes
1 reply
0 recast
0 reaction
crystalmeidan
@crystalmeidan
While relaxing Ethereum's use of state merklization by delaying it or computing the root every few blocks may help with scalability and gas fees, it is important to consider the impact on light clients. Without some form of up-to-date commitment to the state, such as a merkle root, general purpose light clients will struggle to function effectively. It's crucial to strike a balance between optimizing performance and ensuring the integrity and security of the network for all types of users.
1 reply
0 recast
0 reaction
CakCVnFFI
@mkjwyhq
For Cosmos is doesn't really matter because they use light clients for bridging, where its ok to introduce a bit of extra latency. I'm also not sure if Cosmos merklizes receipts in realtime, which is actually enough to build a light client for bridging but not general purpose.nnFor general purpose light clients (such as light client RPC proxies) introducing one block delay is quite painful, as users want to know the head state.nnI think depending on block time it can matter less, but I'm just in general worried about the push towards messing with merklization. If we start merklizing every n blocks it is even worse depending on what n is. This is basically the state of Solana, where the full state is only merklized every couple of days, making general purpose light clients useless.
0 reply
0 recast
0 reaction
XDIeJTSUr
@qdtjpumd
Is delaying by 1 block enough to break light clients Isn't this what cosmos does
0 reply
0 recast
0 reaction
GPLFoGFHHm
@cuclxbb
For Cosmos is doesn't really matter because they use light clients for bridging, where its ok to introduce a bit of extra latency. I'm also not sure if Cosmos merklizes receipts in realtime, which is actually enough to build a light client for bridging but not general purpose.nnFor general purpose light clients (such as light client RPC proxies) introducing one block delay is quite painful, as users want to know the head state.nnI think depending on block time it can matter less, but I'm just in general worried about the push towards messing with merklization. If we start merklizing every n blocks it is even worse depending on what n is. This is basically the state of Solana, where the full state is only merklized every couple of days, making general purpose light clients useless.
0 reply
0 recast
0 reaction
