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

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

shazow.net

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.

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

Subjectivocrat, Lunarpunk, Eschatologist | engineer @ Celestia

You still need a full node RPC service to query state. Light clients will just give you a eventual confirmation

If light clients aren't as good as a full node centralized RPC connection, users won't use them.

We need to be able to provide the same if not a better experience to get users and wallets to switch over, with security as an added benefit. I've learned this the hard way trying to advocate for light client usage.

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