Read on Twitter
there's been a lot of development on state size mgmt in Ethereum.
it doesn't get a ton of attention, but it's
a vital problem to solve for mass adoption (thinking 10 years, 1B users forward)
in the following thread, I'll unpack the problem and current solution space
it doesn't get a ton of attention, but it's
a vital problem to solve for mass adoption (thinking 10 years, 1B users forward)
in the following thread, I'll unpack the problem and current solution space
first, what's the problem?
the Ethereum 'state' consists of all of the data necessary to process a new transaction. you can think of it
as the application state of all smart contracts and all account balances
each node needs to store this data to verify the chain
the Ethereum 'state' consists of all of the data necessary to process a new transaction. you can think of it
as the application state of all smart contracts and all account balances
each node needs to store this data to verify the chain
as NFTs and DeFi explode, the size of this data is growing at an increasingly rapid pace:
https://etherscan.io/chartsync/chaindefault
if this continues, it'll become unfeasible for most to participate in verifying the network. this isn't the
decentralized future we want!
https://etherscan.io/chartsync/chaindefault
if this continues, it'll become unfeasible for most to participate in verifying the network. this isn't the
decentralized future we want!
the key insight that motivates solutions to the problem is that ethereum doesn't charge users of its
storage 'rent'.
it only charges them once
storage 'rent'.
it only charges them once
storage on ethereum today costs (via gas) one STORE instruction in the evm.
this is economically broken.
it costs nodes an infinite amount to store (assuming ethereum lasts forever), but the user only pays once
this is economically broken.
it costs nodes an infinite amount to store (assuming ethereum lasts forever), but the user only pays once
there is currently a two-pronged approach to addressing the state problem:
1. state expiry
2. weak statelessness
1. state expiry
2. weak statelessness
state expiry is the classic database cache approach socialized
if a piece of state hasn't been touched for some amount of time, nodes don't have to store it anymore. if a user wants to access an old piece of state, he/she must provide a 'witness' or proof that the state is valid
if a piece of state hasn't been touched for some amount of time, nodes don't have to store it anymore. if a user wants to access an old piece of state, he/she must provide a 'witness' or proof that the state is valid
if you squint, this sorta feels like user state rent!
because generating a witness requires the user to store the data they're proving the validity of, the user is now paying the cost of storing this data instead of the node provider
because generating a witness requires the user to store the data they're proving the validity of, the user is now paying the cost of storing this data instead of the node provider
it's an elegant, indirect way to redirect who pays for storage
'regenesis' is a specific variant of this that creates fixed-time windows during which all state in that
window is considered legitimate.
accessing a piece of state generated in window N during window N+1 requires a user to provide a witness
window is considered legitimate.
accessing a piece of state generated in window N during window N+1 requires a user to provide a witness
this creates an upper bound on the state size at any point in time! (block gas limit * storage/STORE gas
cost * blocks in period)
stated differently, the sync graph i shared earlier ( https://etherscan.io/chartsync/chaindefault) will have an upper bound
cost * blocks in period)
stated differently, the sync graph i shared earlier ( https://etherscan.io/chartsync/chaindefault) will have an upper bound
weak statelessness the 'light client' approach to solving the problem.
in a weakly stateless ethereum, only block producers (miners, validators) need to store all state. for other nodes to verify state they don't store, they need to be provided a witness
in a weakly stateless ethereum, only block producers (miners, validators) need to store all state. for other nodes to verify state they don't store, they need to be provided a witness
for example, to check with a non-producer node that your account's balance has a certain value, you'd have to provide it with the witness for your account's state
you might've realized that this approach feels similar to the state expiry one!
this duality isn't coincidental. weak statelessness is also a road to state rent
this duality isn't coincidental. weak statelessness is also a road to state rent
in this case, rent is partially paid by block producers (who have to store all state) in addition to users (who have to store state for any witnesses they need to provide)
considering that block producers are the ones 'paid' by the protocol, this feels like it could an economically viable way forward as well
one important piece of new tech here is a data structure called a verkle trie.
these can be used to create small, constant size witnesses. this reduces the 'bandwidth' of the ethereum computer massively relative to log(N) size merkle branch witnesses
these can be used to create small, constant size witnesses. this reduces the 'bandwidth' of the ethereum computer massively relative to log(N) size merkle branch witnesses
for those familiar with kzg commitments and merkle tries, these are basically a trie with a kzg commitment at each node
read more here: https://notes.ethereum.org/_N1mutVERDKtqGIEYc-Flw
read more here: https://notes.ethereum.org/_N1mutVERDKtqGIEYc-Flw
so what's the path forward?
there's recently been some soft consensus around pushing towards option 3 here: https://hackmd.io/@HWeNw8hNRimMm2m2GH56Cw/state_expiry_paths
there's recently been some soft consensus around pushing towards option 3 here: https://hackmd.io/@HWeNw8hNRimMm2m2GH56Cw/state_expiry_paths
this requires working on two pieces of technology in parallel (verkle tries, state expiry), but in the best case, both areas develop fast enough to adopt both in one step
one important note is that the ideas and research here can (and likely will) be transferred to L2.
so they won't get 'dated' as/if value moves up the stack!
so they won't get 'dated' as/if value moves up the stack!
interested in following along and/or contributing?
check out the #regenesis, #state-availability, and #witnesses channels in the Eth R&D discord ( https://discord.gg/3cN4zZAU )
check out the #regenesis, #state-availability, and #witnesses channels in the Eth R&D discord ( https://discord.gg/3cN4zZAU )
