vitalik.eth: Keyed nonces as Ethereum's first specialized state scaling strategy

Submit
vitalik.eth@vitalik.eth

Keyed nonces are not just a way to add stronger in-protocol support for privacy solutions. They are also a potential first foray into a new state scaling strategy for Ethereum: create new types of storage that are more optimized for handling categories of use cases that we care about, with restrictions on their use that make them usable at extreme scale while preserving the protocol's decentralization. Let's zoom in on this case (in-protocol nullifiers). Let's say we get to 2000 TPS of privacy-preserving transactions onchain, for eight years. Then we get 2^11 tx/sec * 2^25 sec/year * 2^3 years = 2^39 [ie. 500 billion] nullifiers stored onchain (the challenge with nullifiers is that they are fundamentally not possible to prune). It's actually far easier to keep Ethereum decentralized if we have 500 billion nullifiers onchain in a dedicated nullifier store, than if we just let them grow in the current state. The reason is that the more restrictive structure of nullifiers (only used to check validity, and we can require the nullifier ID to be explicitly specified in the tx) enables more decentralized ways of handling them. This includes: * Sharding: each node (incl builders) can hold a small percentage of nullifiers, and make sure to have a connection to an honest peer in each other shard * Bloom filters: see this somewhat wacky idea here for reducing the VOPS requirement for nullifiers to ~8 bits per nullifier: https://docs.fileverse.io/d/020001fc0012… Both techniques are not possible to use for dynamically accessible state. And so builders would have to download the full 16 TB to become viable (not just optimal, viable!), and privacy protocol users would not be able to use FOCIL without providing a Merkle branch proving that their nullifier is unspent, and there would be very few nodes capable of providing such a branch... Zooming back out, the moral of the story is that fully dynamic state is much harder to handle at extreme scale (tens to hundreds of TB) than state that is more controlled and restricted in how it can be used. And so if we can move the majority of usage into these more specialized forms of state (which we can make much cheaper in terms of gas), then we can keep Ethereum decentralized, and highly scalable, and keep the fully dynamic state available for applications (eg. defi) that really need its full functionality. https://firefly.social/post/x/2051632978…

farcaster.xyz

vitalik.eth: Keyed nonces as Ethereum's first specialized state scaling strategy

AI summary of the linked article

Vitalik Buterin argues that keyed nonces could be Ethereum's first specialized state scaling strategy, creating storage types optimized for specific use cases and restricted so they remain usable at extreme scale. Using in-protocol nullifiers as the example, he calculates that 2000 transactions per second of privacy-preserving activity for eight years would produce about 500 billion nullifiers, which cannot be pruned. He states that a dedicated nullifier store is easier to keep decentralized than growth in the current state, because nullifiers can be sharded across nodes and checked with Bloom filters that reduce the requirement to about 8 bits per nullifier. Without these techniques, builders would need to download the full 16 TB, so the article proposes moving most usage into specialized state while keeping fully dynamic state for applications such as DeFi.

No comments yetWhat caught your eye? Start the discussion.