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#k=UT7Btd6tyqHgOj47t-TX06F8D6OpcpM_2PKdf7s4tGE 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.

All resolved now: https://x.com/eth_limo/status/2045552916157563148

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#k=UT7Btd6tyqHgOj47t-TX06F8D6OpcpM_2PKdf7s4tGE 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.

All resolved now: https://x.com/eth_limo/status/2045552916157563148