Thread by @GuthL

As promised, a thread on data availability, or: How I Learned to Stop Worrying and Love Ethereum

Let start with a definition. We call the State, the current set of elements stored on the chain. It can be UTXO, ETH balance in an account, or active storage of a contract. 1/7

On StarkNet, the state is compressed using a Merkle Root and every state transition must update the state Merkle root on Ethereum, making it final.

Therefore, to continue pushing the chain forward, users must know all the current elements to recompute the Merkle tree. 2/7

This is called the Data Availability Problem.
StarkNet solves it by being a ZkRollup, publishing for each modified storage the last value on-chain. Think of this data broadcast as a snapshot of the chain done every once in a while. 3/7

This methodology, while clunky, slow, and expensive, is essential to provide full security.
As a side note, being able to reconstruct the state does not necessarily guarantee that one can move the chain forward. 4/7

They must have adequate equipment and software (a prover in this case), the right to push an update, and the ability to read what the state contains. I won't dive into this topic as it relates to implementation, not with theory. 5/7

To conclude, on-chain data must only be understood from the security perspective.
If you will want live data, YOU WON'T GET IT FROM L1!

This leads us to node participation on StarkNet (notably to access real-time data). It will be the topic of my next thread. 6/7

For more details on data availability, costs, programming patterns, and others, join StarkNet Discord: discord.gg/JUHtQQnK7H 7/7