# State Proofs and Their Applications | Seun Lanlege - Polytope Labs

- Speakers: [Seun Lanlege](https://streameth.org/speakers/seun-lanlege)
- Channel: [Ethereum Denver](https://streameth.org/ethereum-denver)
- Date: 2026-03-09
- Duration: 11:31
- Topics: ETHDenver, Crypto, Web3, Blockchain, Event, Conference, ETHDenver 2025, ETHDenver 2024, Bitcoin, Ethereum
- Watch: https://streameth.org/watch/yt-qp-aar9Wl0s
- YouTube: https://www.youtube.com/watch?v=qp-aar9Wl0s

## Description

🚀 Get Ready for ETHDenver 2026! 🚀

We're already hard at work preparing for next year's biggest Web3 event!

Keep your eyes peeled for more info on ETHDenver 2026—it’s going to be epic! 🌟

## Transcript

Hello everyone. It's really great to be here. My name is Shawn and I'm going to be discussing state proofs and their lesser-known applications. So state proofs are actually this very critical piece of blockchain technology that power quite a lot of things including trustless bridges, light clients, modular chains that allow you to have these L2 L3 architecture. But I guess not a lot of people knew how they work and why they work and in this talk I'll be trying to demystify state proofs and their mechanism of operation. So first off, I think it's very important to understand blockchains as state machines, right? So every block holds some state. We will just think of this state as some object data formats and every time a transaction is applied in a new block, you end up with a new state. And a blockchain really is this state transition function that takes the previous state, applies some transactions. These transactions encode how the state should be modified and you end up with a new state, right? And so you know, there are some issues with this because if you need to execute a block then you essentially have to execute all the transactions. This is something that Yisun just also recently discussed in his talk about ZK proofs of blockchains. And so you know, we'll actually look at what the format of this state is and what what these state what the state is essentially is a Merkle tree. Merkle trees essentially allow us to cryptographically commit to some information. In this case, you could just think of this as a flat list of data and you just recursively hash pairs of this data up up until you get to a single root element. Um some beautiful properties about this is that you get these log n proofs. So, if you needed to prove that any single item in the list uh existed in the root in the commitment, then you could just get a log n size proof of this. Um you could partially reveal this this list without having to reveal the entire list. Uh and it's entirely tamper resistant, you know, depending on the security of your hash function. And uh because of the way hash functions work, uh you have up to 128 bits of security. So, we'll actually look at what the Ethereum and most popular blockchains use, which is the Merkle Patricia tree. And in this kind of Merkle tree, the keys are encoded in the path to the data. So, instead of having uh a flat list, you actually have this map structure. And then you have keys that point to a leaf, so the actual data. And then each uh key or nibbles, as it as as they're called, uh is encoded in the path to to the data. And so, in the Merkle Patricia tree, you actually have 16 branches. Uh that's why it's called a hexary tree. Um and you have different kinds of nodes. You have essentially the root node, you have the branch nodes, you have the leaf nodes, you have the extension nodes, right? And you know, if you go on if you go on um Etherscan today and you pull up any Ethereum block, you're always going to find this thing called the state root. Um it's basically the commitment to all of Ethereum's state, so all the accounts, all the smart contract storage. You know, there's so many of them. Uh and every node essentially has to create this commitment for every block, right? Um and so, this is essentially all the different kinds of proofs you can you can obtain today from I would say most popular EVM chains. Not a lot of EVM chains have state proofs, I would say that. But, you know, the the more the most popular ones, Polygon, BNB chain, Ethereum L1, all the L2s. In fact, the L2s have to have state proofs, otherwise they would not be L2s, right? And I'll get into that later. But essentially, you can you can get proofs for each account in the state, right? So, you know, account has this property of the nonce, the code hash, the balance, I think the storage roots if it's a contract. And you can get storage proofs of independent or individual slot hashes in a smart contract storage layout. Or you could just get the full state proof, right? You want to prove that some data exists in some smart contract slot hash, and you need to prove that all the way up to the state root. So, you know, let's look at what are the applications for this. Like, why do we have state proofs? So, primarily, it's for interoperability. Because blockchains are essentially committing to the state of all the smart contract storage data, then we can actually tell other blockchains what's happening on chain on a different blockchain, right? Because we can we can acquire these proofs, and if the receiving blockchain is able to verify these proofs, if the maybe verification algorithm is not too complex, then this blockchain can actually learn trustlessly what is happening on chain. And there's different, you know, applications for interoperability, right? You can have token bridging, you can have lending, you can have all kinds of applications that require interoperability. And there's already a few examples of protocols today, interoperability protocols, that require state proofs. One of them is of course Hyper Bridge, but then you also have things like IBC, which comes from the Cosmos ecosystem. And you also have L2 bridges. And, you know, L2 bridges primarily work by having a state commitment that is posted to Ethereum, and you can then prove things about that state roots to maybe exit, you know, bridges exit assets from the L2 or or to actually communicate between the L1 and L2. Another application of state proofs is actually privacy. And now, this goes over a lot of people's heads, but you see, the way that the future privacy protocols are going to work is that we're going to build privacy protocols on top of public blockchains. And the way that this is going to work is that you're going to be able to generate proofs of people making transactions on their personal chain. This This notion of a personal roll-up where you essentially actually create this transaction chain that's off-chain, but you use ZK proofs to update the state of your transaction chain, and then you're constantly posting state roots on chain about, you know, what is the latest state of your of your personal chain. But if someone wanted to receive assets from your personal chain, then they would have to prove that in your personal roll-up, you've paid them, right? But then they would be essentially revealing who paid them because they would have to point to your personal state root on chain. But because we we're actually living in this, you know, Merkle tree, then we don't actually have to reveal which individual state roots this payment is coming from. We can actually just point to the global state root and say, well, in the global state root, there's some account state root that hasn't paid me, and I can just prove that Merkle path all the way down to the payment transaction. So, this is one of the ways in which I personally see privacy protocols essentially scaling through this personal roll-up architecture. And finally, I would say you know, state roots allow for scalability. You know, previously, consensus layers would bundle a single execution layer, which is where you now need to generate state proofs and and and state commitments about the execution layer. Now, we're seeing the rise of consensus layers that are purely agnostic to execution. One of them, of course, being Ethereum, Polkadot, and and of course, more more more and more of these kinds of architectures are showing up. But how they work is still goes back to using state roots, right? So essentially, you want to have a way to verify that what what each execution shard is doing. And the way that you do this is you would typically have to a re-execute the entire blocks of each shard. And to actually do this, you need to have the state proof of all the elements that are accessed in the state tree and a proof for them so that you can compute what is the post state roots. Um and this is the way in which like optimistic rollups work, even ZK rollups today. Each ZK rollup is essentially going to take what is the pre-state of the block that they're operating on, all of the Merkle proofs of all the items that are accessed by that block. They're going to execute the block and they're going to essentially arrive at what is the post state roots. Um so this is more of a graphical representation of of what ZK rollups are essentially doing. You have your pre-state, all the elements that are accessed in the pre-state, Merkle proofs for them. This will have to be verified, and then the ZK rollup essentially just computes what is the post state roots for that block. Um and then there's of course, you know, an an upcoming improvement proposal for our Merkle Patricia tree. They're called Verkle trees. And previously, we used to use hash-based uh cryptography. Um Verkle trees use polynomial schemes and polynomial commitment schemes, which can also be post-quantum if you're using um things like FRI. You don't necessarily have to use KZG. Um and this is This could potentially make state proofs much more efficient uh and much more cheap to verify. Um so finally, we come to light clients. So, you know, I think a lot of us uh when we got into decentralization and we got into like this whole meta was that, okay, how exactly are people going to use blockchains, right? Is everyone going to have to run their own node? Cuz that's the only way in which we can actually trust the information that we're getting about the chain. Um and this is of course very expensive, right? Like, you know, I think Solana requires like a whole data center. Ethereum maybe not so much, but still cumbersome to run. The way in which we can actually scale, you know, blockchain data access to everyday people is through the use of these light clients, right? So, rather than having to execute every block, you would instead have a light client that is able to follow the consensus of the chain. And if they need to basically query on-chain data, they would have to query this data with storage proofs, right? So, remember in the consensus metadata, we have the state roots, right? The header we have the state roots, and then we can ask a full node, "Okay, what is my balance?" or "You know, what is happening on this application?" But we don't want full nodes to be able to lie to us, so we will ask the full node to present a Merkle proof, a state proof, to essentially authenticate what they're claiming, right? And so, this is how most people will be able to use blockchains without having to essentially run data centers to keep up with the chains that they all know and love. So, just want to basically summarize my talk. State proofs essentially allow for cryptographic verification of on-chain data. There's different schemes for this. You have your classic, you know, binary Merkle trees. You have the Merkle Patricia trees, and we have the upcoming vertical trees. And they power trustless bridges and trustless interoperability protocols that don't rely on centralized multi-sig or middlemen. They also enable privacy. You know, for instance, Tornado Cash actually builds a Merkle tree on chain. And that's a kind of Merkle proof that enables privacy. And they are also the foundation for future modular blockchain rollups. If you have any questions, I'm I'm happy to answer now. If not, thank you for coming to my talk. Bye, everyone.