lightclients

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.

building open source public goods @a16zcrypto

Is delaying by 1 block enough to break light clients? Isn't this what cosmos does?

A doodler and computerer. I like permissive/permissionless open source, smart contracts, p2p systems, room-scale VR, and NixOS.

Currently: WhatsABI

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.

For 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.

I 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.