State Proofs: Making Smart Contracts Smarter

Smart contracts aren’t that smart

When someone purchases a digital asset stored on a blockchain, it may seem like moving it to a different blockchain is a safe and easy process. After all, in the world of traditional finance, moving money or assets from one database to another is a generally straightforward, even trivial process. However, this isn’t the case in web3. Smart contracts are not as smart as many would think. This is because smart contracts can only view the current state of the blockchain they are deployed on. Viewing the state of another blockchain is totally out of the question. To circumvent this issue, developers have created various tools, such as cross-chain messaging protocols, oracles, and bridges. Are these tools the solution to the problem plaguing web3 today, and can they make smart contracts smarter?

To some extent, yes, but most variations of today's tools rely on off-chain systems and/or centralized parties. This creates a risk where trust in the wrong parties could jeopardize the blockchain ecosystem if these pieces of middleware have a security flaw. We have seen this time and time again. 

With the ecosystem progressively moving towards a multichain future to alleviate scalability issues, we must create tools that are increasingly trust-minimized. With a piece of infrastructure called state proofs, smart contracts become smarter and can view the state of any blockchain at any point in time. State proofs are needed to enable the next generation of decentralized applications.

Problems with the current system

Since smart contracts are limited to accessing only the current on-chain data from their respective blockchains, tools have been created to alleviate this issue. These tools are oracles and cross-chain bridges. Oracles serve as a data bridge allowing decentralized applications to access any chain's historical data and even certain off-chain data. While oracles are needed to enable smart contracts to ingest off-chain data, it may not make sense to use an off-chain indexing solution to access on-chain data. This is because an insufficiently decentralized oracle can be manipulated. Many applications have mitigated this risk by using solutions like Chainlink, an example of an oracle that indexes/aggregates with a sufficiently decentralized (albeit off-chain) architecture. Chainlink secures around $9 billion in TVL today, demonstrating developers' trust in it. While this solution works and may be necessary for specific applications, you may want your data to be kept from being relayed off-chain because it further reduces points of failure. For on-chain data, it may make more sense to query using an on-chain solution, such as state proofs. However, trust minimization is just one of many issues present with the current system; in addition to centralization risks, blockchain interoperability remains a large technical challenge.

Blockchain communities are looking for ways to use their favorite decentralized applications without paying outrageous gas fees, pushing them to migrate to more scalable blockchains. However, building on these blockchains causes liquidity to be fragmented across several ecosystems. Smart contracts can’t natively communicate across chains, limiting smart contracts’ access to on-chain data. This pushes developers to trust centralized bridge operators or distributed networks that operate off-chain.  These may not be the safest options, as seen with cross-chain bridges. Cross-chain bridges, in their current implementation, present much bigger risks than most oracles. So far, bridge hacks have resulted in losses topping $2.5 billion, which is around half of all the TVL in bridges today.

These staggering losses and the frequency with which they occur show that we need more robust solutions to communicate across chains. Relying on counterparties can lead to hacks and exploits that may destabilize whole ecosystems. State proofs are potentially the solution many developers have been looking for to make cross-chain applications far safer.

What are State Proofs?

While we have mentioned state proofs as a nearly trustless solution, we have yet to describe what they are and how they work. A state proof is a digital record that provides evidence of a specific state of a blockchain. The goal of state proofs is to enable blockchains to digitally sign messages in a way that is verifiable by everyone. To properly incorporate state proofs into blockchain applications, Merkle trees, zero-knowledge proofs, and light clients must be used. The easiest way to introduce these concepts is an analogy:

Imagine that you have a big book with lots of information written in it. This book represents a blockchain. Each page in the book is called a block, and each block has a unique code, called a hash, that identifies it. When you want to add new information to the book, you write it on a new page and then add the page to the end of the book. You also include the hash of the previous page in the book so that everyone can see that the new page is connected to the rest of the book.

Let's say that you want to prove to someone that a particular piece of information is written in the book. In this hypothetical situation, each book page can not natively view a previous page of the book nor view a page of a different book. This problem can be circumvented by generating a state proof for a page of a given book. 

A state proof is like a picture of the page in the book where the information is written. This could be a picture of a previous page or a picture of a page in a different book. It includes the hash of the page, as well as the hashes of all the previous pages in the book. This proves that the information is written on a specific page in the book and that it is connected to all the other pages in the book. However, verifying a book that has accumulated years worth of pages would take a while. To make the picture useful, state proofs must utilize a Merkle tree.

Merkle Trees

If the book is big, and there are many pages, it might take a long time to show someone all the pages and prove that the information is in the book. That's where a Merkle tree comes into play. A Merkle tree is a special kind of picture that helps us remember all the pages in the book more quickly. It works by dividing the pages into smaller chunks called leaves and then creating a tree-like picture by mixing pairs of leaves and making a new picture (called a node). The top picture in the tree is called the root, representing the entire book. To prove to someone that a particular piece of information is in the book using a Merkle tree, we just need to show them the root picture and the picture of the specific leaf (page) that the information is on. They can then use the pictures to recreate the tree and ensure the root picture matches the one we showed them. This proves that the specific page and the entire book have not been changed because any changes to the pages would result in a different root picture.

A Merkle tree allows for efficient verification of the contents of a large dataset, such as a blockchain, without the need to verify the entire dataset. This can significantly reduce the time and resources needed to verify a state proof. However, sometimes it may be desirable to verify the contents of a specific book page without revealing the page's actual contents. This is where zero-knowledge proofs (ZKPs) can be helpful.

Zero-Knowledge Proofs

What if you wanted to prove to someone that you know a particular piece of information written in the book but want to keep it private? You can do this using zero-knowledge proofs (ZKP). A ZKP is a unique picture of the page in the book where the information is written. It includes the hash of the page and the hashes of all the previous pages in the book. However, unlike a regular state proof, the ZKP does not reveal the actual information written on the page. It only shows that the prover knows the information without revealing it. A ZKP is like proving that you know specific information written in the book (the blockchain) without revealing the actual information itself. It is a digital fingerprint that allows you to prove that you know the information without revealing any additional details. A state proof will usually be packaged as a ZKP and sent to the destination chain. But how exactly is this proof sent to someone else? We will need to see what messaging protocol enables state proofs to have minimal trust assumptions.

Sending the ZK-Proof payload

Up until now, we assumed that state proofs are a nearly trustless solution compared to any other solution available today. This is true; however, it depends on how the ZKP is relayed to the destination chain. Each implementation has pros and cons, and relying on a messaging protocol with more trust assumptions may make sense in certain cases. There are three ways to achieve a messaging protocol: standard messaging, consensus validation, and optimistic MPC relayer. Let's dive into how each works.

Standard Messaging

Standard messaging works by sending a message from layer 2 to layer 1 or vice versa. However, unlike third-party solutions, standard messaging is a built-in messaging protocol between layer 1 and layer 2 blockchains and is a unique property of rollups.  An example of this would be a rollup such as Optimism. Optimism is able to send asynchronous calls between L1 and L2 users or contracts. Essentially, a contract on L1 can make a call to a contract on L2 and vice versa. This is implemented by deploying “bridge” contracts on both Ethereum and Optimism. You can get the block hash by calling the proper opcode. There is no middle-man third-party/network that needs to transfer the message between contracts. While this approach is sufficiently trustless, if you wanted to send a message to Optimism from Ethereum, you would need to sign the message on both chains. This requires interacting on multiple layers, which causes friction and latency issues. This also cannot be easily extended to two different layer 1s, so there is a limit to how cross-chain applications could use this messaging.

Consensus validation

Since Ethereum has migrated its consensus protocol to Proof of Stake (PoS), verifying the underlying consensus protocol is finally doable. Proving hashing functions on Ethereum PoW (Ethash) was nearly impossible before because the process is very memory intensive. It is now finally possible to verify the consensus, as with PoS you only need to verify BLS signatures which is much more memory efficient. However, it is still expensive to do this computation within a smart contract. It makes more sense to do the computation needed to verify the consensus within a ZKP. Since this verifies the consensus directly, there is no trust assumption. The only issue is the computation could take a while, which would lead to major latency issues and limit which applications could be built with this method. Some blockchains, such as Algorand, use this messaging method to power their cross-chain applications. Consensus validation is the method that powers their network’s cross-chain bridge. However, there is a requirement that the network must be a proof of stake network. As such, some blockchains may not message each other this way. There is also a gas cost issue attached to this approach, as you need to verify the ZKP, which is much more expensive than just consuming a message or verifying a signature.

Optimistic MPC relayer

Herodotus, a company producing software to make state proofs more accessible to developers, is taking a different approach. Herodotus uses an optimistic relayer based on multi-party computation (MPC). MPC is a type of secure computation in which multiple parties (in this case, validators/relayers)  attest if a specific commitment is valid. MPC works similarly to a multisig where more participants make the overall system more secure. But, as you add more validators, more people are required to verify each commitment. The more decentralized this gets, the more expensive it is to verify.

One significant advantage this has over sending a message is that you could use an off-chain call to get the latest block hash and relay this directly to the smart contract on the destination chain, which greatly reduces latency. The downside here is that MPS relayers require more trust. However, this is not necessarily a deal-breaker because network participants can dispute whatever data the MPC validators send. Since we know that layer 2s can message layer 1s in a way that is fully trustless, this can be used as a backup source of truth. Even if the validator set lies, the actual layer 1 to layer 2 messaging cannot lie, so it is simple for network participants to check if the validator set is lying, as it only requires two RPC calls to the chain. One call will check the actual commitment on the chain, and the other call will review the claimed commitment. The fraud proving window is short but can take time, as it will take as long as it takes for consensus validation.

Being trust minimized introduces unavoidable latency.

The latency present in trust-minimized solutions may be a challenge for some applications. An example of an application where speed is essential would be a cross-chain exchange. The speed of state proofs would not be able to accommodate that. That said, different messaging methods can be used to optimize for each specific type of application. However, once we have established the best and fastest way to generate and send state proofs, to whom exactly are we sending them to? And how can all of the topics we discussed be used to secure applications such as cross-chain bridges?  A light client is the final missing piece to understanding the tools involved with state proofs. 

Light Clients

Continuing with the analogy from before, a light client would be someone who wants to access the information in the book (the blockchain) without having to carry the entire book around with them all the time. They can ask a full node (someone who has a copy of the whole book) for the specific information they need or ask for a state proof to verify the existence of a particular piece of information in the book. This allows light clients to interact with the blockchain without storing all the data themselves, which can be helpful for devices with limited storage or computing power. 

State proofs can help light clients import data from other chains cost-effectively and securely. Bridges or other applications can query these light clients to validate activity between two blockchains. Therefore, the need to trust third parties is completely eliminated.

Do you enjoy crypto deep-dives? Subscribe for free to receive new posts and stay informed on the latest trends and topics in the industry.

Are state proofs the solution?

Use Cases for State Proofs

Developers can implement state proofs in a variety of applications. While we know the issues plaguing cross-chain bridges, we have not yet explained how state proofs can be used to strengthen a bridge’s security.

Bridges

Algorand is an excellent example of how state proofs could strengthen a bridge. As mentioned before, Algorand is using consensus validation as their form of messaging. Since the Algorand blockchain verifies the consensus directly, this method doesn’t have additional trust assumptions.  In this example, let's imagine that Alice wants to send Bob 10 “AliceCoins” from Algorand to Ethereum. AliceCoins are very sought after, so they want to make sure the tokens arrive quickly, safely, and without permission from or trust in an intermediary. Alice can send these tokens directly to Bob’s Ethereum wallet via a trustless bridge whose code base is open to the public.

Algorand’s state proof powered bridge.

The bridge works by “locking” the AliceCoins in the smart contract on Algorand. The partner smart contract on Ethereum would ask Algroand’s light client (which is kept up to date via state proofs) if Alice has locked the tokens. Once verified, the bridge would mint the same amount of tokens on Ethereum to Bob’s wallet. Developers can model this process backward to enable transfers from Ethereum to Algorand. Bridge operators can create Algorand smart contracts that ask these light clients to validate Ethereum transactions (e.g. depositing ETH in an Ethereum smart contract) via Algorand’s Contract to Contract calls. A pair of light clients on both chains would enable the bridge to work in both directions. There is no reliance on a centralized party to maintain the bridge, and state proofs enable the bridge to be truly trustless.

Account Abstraction

Our previous report talked about how account abstraction will evolve wallets. Account abstraction wallets are programmable smart contract wallets and can utilize state proofs to add to their feature set. By generating a state proof for the wallet at regular intervals, such as every day or every week, wallets could use it to detect the inactivity of a user's account. If the wallet has not undergone any transactions or changes during that period, the state proof will be the same as the previous one. By comparing the current state proof to the previous one, it is possible to determine whether the wallet has been inactive or not. This could be useful for detecting abandoned or dormant wallets or identifying accounts that may have been compromised or otherwise tampered with.

This could be useful for implementing new types of social recovery functionality, which activates when a user loses access to their wallet. If the wallet has been deemed “dormant” by state proofs, the social recovery could start, allowing the user to get back into their account.

Gaming

Web3 game developers currently face a tough dilemma. They want to allow their users to trade their in-game items as NFTs on a thriving marketplace, but they also want to have cheap gas fees so they will not be a friction point for the user. The community typically forces developers to deploy their NFTs onto the Ethereum blockchain because NFT marketplaces on Ethereum have much more volume and liquidity than other chains’ marketplaces. However, this poses an issue for game developers, as if the NFTs are on Ethereum and the developers do not want to have a friction point of bridging, the game will have to deploy there as well.

If the game deploys onto Ethereum, users are stuck paying ridiculous transaction fees. It makes little sense that a gamer should pay a few dollars in fees to interact with a game on-chain. Developers want to deploy their game onto a layer 1 with cheaper gas, or even a layer 2, but still want their in-game items to be sought after.

State proofs could help alleviate this roadblock. As a game developer, you could deploy your NFTs on one chain while using them for a game on a different chain. There would be no bridging of assets and no need to deploy everything to one chain. State proofs would allow you to simply verify a player’s ownership of a given in-game NFT item on say, Ethereum, while conducting the actual in-game interactions on a cheaper layer 1 or layer 2.

Governance

Many decentralized finance applications have embraced the idea of being deployed onto as many chains as possible. While this can be good for reducing fees for the end user, it can make governance a headache. Most of these protocols issue governance tokens across multiple blockchains. With these tokens, participants of the protocol can vote on changes to the protocol. However, this causes a logistical nightmare for the actual governance applications which facilitate the voting. These applications have difficulty aggregating a user’s token balance across multiple chains. Without state proofs, users would have to rely on a trusted oracle or bridge their tokens back to a major chain (such as Ethereum) and then vote there. With state proofs, the governance application could check the state of the user's balances and use the total count of tokens across multiple chains as their voting power.

Closing Thoughts

State proofs make cross-chain applications safer. While applications can benefit from using state proofs, their importance to the application varies on a case-by-case basis. Some applications, such as cross-chain bridges, could utilize state proofs to better protect user funds. For other applications, it may be the case that you truly need a price feed that frequently updates, despite the fact you would be relying on a third-party intermediary for the solution. However, it is wrong to assume that an off-chain price feed is always needed for every application, as state proofs can fill many of those gaps. Account abstraction wallets, gaming, and governance are immediate use cases; however, state proofs are relatively early in their development, so we will eventually see how other applications use state proofs. Builders in the web3 space should push to use solutions that inherit the safety and trust of the protocols they build upon.

Author

Robert McTague is an Investment Associate for Amber Group's Eco Fund, the company's early-stage crypto venture fund. He hopes that as state proofs gain popularity, we will see a rise in safer cross-chain applications.

---

Disclaimer

The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.