When someone buys a digital asset stored on a blockchain, it may seem that shifting it to another blockchain is a simple and secure operation. After all, in traditional finance, moving money or assets from one database to another is a relatively simple, if not trivial, process. In web3, however, this is not the case. Smart contracts are not as intelligent as many people believe. This is because smart contracts can only see the present state of the blockchain on which they are implemented. Viewing the status of another blockchain is not an option. To address this problem, developers have devised several tools, including cross-chain communications protocols, oracles, and bridges. Are these technologies the answer to the current web3 challenge, and can they make smart contracts smarter?

Yes, to some extent, but the majority of today's tools rely on off-chain systems and/or centralized parties. If these pieces of middleware contain a security weakness, confidence in the wrong people might damage the blockchain ecosystem. This has happened several times.

As the ecosystem moves toward a multichain future to address scalability challenges, we must develop tools that are less reliant on trust. Smart contracts become smarter and can examine the status of any blockchain at any moment in time thanks to a piece of infrastructure known as state proofs. To allow the next generation of decentralized apps, state proofs are required.

The current problems with smart contracts

Because smart contracts can only access the most recent on-chain data from their blockchains, solutions have been developed to address this limitation. Oracles and cross-chain bridges are examples of these tools. Oracles act as a data bridge, enabling decentralized applications to access historical data from any chain as well as some off-chain data. While oracles are required to allow smart contracts to consume off-chain data, using an off-chain indexing solution to access on-chain data may be counterproductive. This is because an oracle that is not sufficiently decentralized may be exploited. Many applications have mitigated this risk by implementing solutions such as Chainlink, an example of an oracle with a sufficiently decentralized (albeit off-chain) architecture. Today, Chainlink secured around $9 billion in TVL, proving developers' confidence in it. While this solution works and may be required for specific applications, you may want to keep your data from being relayed off-chain to reduce points of failure. It may make more sense to query on-chain data using an on-chain solution, such as state proofs. However, trust reduction is just one of several concerns with the existing system; in addition to the hazards of centralization, blockchain interoperability remains a significant technological difficulty.

Blockchain communities are seeking methods to utilize their favorite decentralized apps without paying exorbitant gas fees, which is driving them to transfer to more scalable blockchains. However, building on these blockchains fragments liquidity over several ecosystems. Smart contracts cannot interact natively across chains, restricting their access to on-chain data. This forces developers to rely on centralized bridge operators or off-chain distributed networks. As demonstrated with cross-chain bridges, they may not be the safest solutions. Cross-chain bridges provide much more hazards than most oracles in their current implementation. Bridge hacking has resulted in losses of $2.5 billion, or half of all TVL, in bridges today.

These astounding losses, as well as their regularity, demonstrate the need for more robust methods to communicate across chains. Depending on counterparties may result in hacks and vulnerabilities that disrupt whole ecosystems. State proofs might be the answer that many developers have been seeking to make cross-chain apps significantly more secure.

What exactly are state proofs?

state proofs models

Source: Medium

While state proofs have been offered as a virtually trustless option, we have yet to clarify what they are and how they operate. A state proof is a digital record that proves a certain state on a blockchain. The purpose of state proofs is to allow blockchains to digitally sign communications in a form that everyone can verify. Merkle trees, zero-knowledge proofs, and light clients must be employed to correctly integrate state proofs into blockchain applications. An analogy is the simplest approach to illustrate these concepts:

Assume you have a large book with a lot of information written in it. This book is an example of a blockchain. Each page in the book is referred to as a block, and each block is identified by a unique code known as a hash. When you wish to add new information to the book, just write it on a new page and place it at the end. You also provide the hash of the previous page in the book to show that the new page is linked to the remainder of the book.
Assume you want to show someone that a specific piece of information is written in the book. In this hypothetical scenario, no book page can natively see a previous page of the book or a page from another book. This issue may be avoided by establishing a state proof for a specific page of a book.

A state proof is similar to a photograph of the page in the book on which the information is written. This might be a picture of a previous page or a page from another book. It contains the page's hash as well as the hashes of all preceding pages in the book. This demonstrates that the information is written on a certain page of the book and is linked to all of the other pages in the book. However, verifying a book with thousands of pages would take some time. State proofs must employ a Merkle tree to make the image usable.

Merkel tree

If the book is large and has many pages, it may take some time to show someone all of the pages and demonstrate that the information is in the book. This is where a Merkle tree comes in. A Merkle tree is a kind of graphic that helps us recall all of the pages in the book faster. It works by splitting the pages into smaller pieces called leaves and then combining pairs of leaves to create a tree-like image (called a node). The uppermost image in the tree is known as the root, and it represents the whole book. To demonstrate to someone that a certain piece of information is in the book, we just show them the root picture and the image of the precise leaf (page) that the information is on. They may then use the images to reconstruct the tree, making sure the root image matches the one we gave them. This demonstrates that neither the individual page nor the whole book has been altered since any modifications to the pages would result in a different root image.

A Merkle tree enables fast verification of the contents of a big dataset, such as a blockchain, without requiring the full dataset to be verified. This may drastically minimize the amount of time and resources required to validate a state proof. However, it may be desirable from time to time to verify the contents of a specific book page without revealing the page's actual contents. Zero-knowledge proofs (ZKPs) may be useful in this situation.

Zero-knowledge proofs

What if you wanted to prove to someone that you knew something mentioned in the book but wanted to keep it private? This is possible using zero-knowledge proofs (ZKP). A ZKP is a one-of-a-kind image of the page in the book on which the information is written. It contains the hash of the page as well as the hashes of all preceding pages in the book. The ZKP, however, does not expose the actual information displayed on the page, unlike a standard state proof. It just demonstrates that the prover is aware of the knowledge without exposing it. A ZKP is like confirming that you understand certain information published in a book (the blockchain) without exposing the real material. It is a digital fingerprint that enables you to confirm your knowledge of the material without disclosing any more information. A state proof is typically packed as a ZKP and sent to the target chain. But how is this proof delivered to someone else? We'll need to figure out which communications protocol allows state proofs to have low trust assumptions.

The ZK-Proof payload

We previously thought that state proofs are a practically trustless solution when compared to any other solution available today. This is correct; however, it is contingent on how the ZKP is routed to the target chain. Each implementation has advantages and disadvantages, and depending on a message protocol with higher trust assumptions may make sense in certain instances. A messaging protocol may be implemented in three ways: regular messaging, consensus validation, and optimistic MPC relayer. Let's have a look at how each operates.

Standard messaging

Sending a message from layer 2 to layer 1 or vice versa is how standard messaging works. Standard messaging, on the other hand, is a built-in communications protocol between layer 1 and layer 2 blockchains and is a unique attribute of rollups, as opposed to third-party solutions. A rollup-like Optimism is an example of this. Asynchronous calls between L1 and L2 users or contracts are possible using Optimism. In essence, a contract on L1 may call a contract on L2, and vice versa. This is accomplished via the use of "bridge" contracts on both Ethereum and Optimism. You may get the block hash by using the appropriate opcode. There is no requirement for a third-party network to send the message across contracts. While this approach is sufficiently trustless, if you wanted to send a message from Ethereum to Optimism, you would have to sign the message on both chains. This necessitates interaction across numerous levels, resulting in friction and latency concerns. This communication also cannot be readily extended to two separate layer 1s, limiting how cross-chain apps may leverage it.

Consensus Validation

Since Ethereum's consensus protocol has been converted to Proof of Stake (PoS), it is now possible to validate the underlying consensus protocol. Proving hashing functions on Ethereum PoW (Ethash) was previously virtually hard due to the process's high memory requirements. It is now feasible to verify the consensus since, with PoS you just need to check BLS signatures, which use considerably less memory. However, performing this computation within a smart contract is still costly. It is more logical to do the calculation required to validate the consensus inside a ZKP. There is no trust assumption since this directly validates the consensus. The main difficulty is that the calculation may take some time, resulting in significant latency difficulties and limiting the types of apps that may be constructed using this approach. This messaging technique is used by certain blockchains, such as Algorand, to power cross-chain applications. The mechanism that drives their network's cross-chain bridge is consensus validation. There is, however, a need for the network to be a proof of stake network. As a result, certain blockchains may not communicate in this manner. This solution also has a gas cost problem since you need to validate the ZKP, which is far more costly than just consuming a message or confirming a signature.

Optimistic MPC relayer

Herodotus, a software startup that makes state proofs more available to developers, takes a different method. Herodotus employs a multi-party computation (MPC) optimistic relayer. MPC is a sort of secure computation in which many parties (in this example, validators/relayers) testify to the validity of a particular commitment. MPC functions similarly to multisig, in that more participants increase the total security of the system. However, as more validators are added, more people are required to verify each commitment. The more decentralized something becomes, the more costly validation becomes.

One important benefit of this over-sending a message is that you may utilize an off-chain call to get the most recent block hash and transfer it straight to the smart contract on the destination chain, reducing latency significantly. The disadvantage here is that MPS relayers need greater confidence. However, this is not necessarily a deal breaker because network participants can contest any data sent by the MPC validators. Because we know that layer 2s can message layer 1s in a completely trustless manner, this can be used as a backup source of truth. Even if the validator set lies, the actual layer 1 to layer 2 messages cannot lie; therefore, network participants may easily verify whether the validator set is lying by making just two RPC calls to the chain. The first call will verify the chain's real commitment, while the second call will verify the claimed commitment. The fraud proving window is brief, yet it might take time since consensus validation takes time.

messaging method comparison

Source: Medium

Some applications may struggle with the latency present in trust-minimized solutions. A cross-chain exchange is an example of an application where speed is critical. The speed of state proofs would be insufficient to allow this. Having stated that numerous messaging techniques may be employed to optimize for different types of applications. However, once we've determined the best and quickest way to generate and send state proofs, who are we sending them to? And how can we apply what we've spoken about to secure applications like cross-chain bridges? The last needed ingredient to understanding the techniques associated with state proofs is a light client.

Light clients

Continuing with the example, a light client is someone who wants to access the information in the book (the blockchain) without carrying the complete book around with them all the time. They may request specific information from a complete node (someone who has a copy of the whole book) or request state proof to validate the presence of a specific piece of information in the book. This enables light clients to communicate with the blockchain without having to store all of the data themselves, which is useful for devices with limited storage or computing capacity.

State proofs may assist light customers in importing data from other chains cost-effectively and safely. These light clients may be queried by bridges or other applications to verify activity between two blockchains. As a result, the necessity to rely on third parties is removed.

State proofs' use cases

State proofs may be used in several applications by developers. While we are aware of the problems that plague cross-chain bridges, we have yet to explain how state proofs can be used to improve a bridge's security.

Bridge

Algorand is a great illustration of how state proofs may help to improve a bridge. As previously stated, Algorand's message is based on consensus validation. Because the Algorand blockchain directly verifies consensus, this method does not require any additional trust assumptions. Assume Alice wants to send Bob 10 "AliceCoins" from Algorand to Ethereum in this example. Because AliceCoins are highly sought after, they want to ensure that the tokens arrive quickly, safely, and without the need for permission from or trust in an intermediary. Alice may transmit these tokens straight to Bob's Ethereum wallet via a trustless bridge with a public code base.

algorand design

Source: Algorand

The bridge operates by "locking" the AliceCoins in the Algorand smart contract. The Ethereum partner smart contract would query Algroand's light client (which is maintained up to date through state proofs) to see whether Alice had locked the tokens. Once verified, the bridge would generate the same number of tokens on Ethereum and send them to Bob's wallet. Developers may reverse design this mechanism to allow transfers from Ethereum to Algorand. Bridge operators may write Algorand smart contracts that ask these light clients to verify Ethereum transactions (for example, putting ETH into an Ethereum smart contract) using Algorand's Contract to Contract calls. The bridge may operate in both directions with a pair of light clients on each chain. The bridge is not reliant on a single entity for maintenance, and state proofs allow it to be genuinely trustless.

Account Abstraction

Account abstraction wallets are programmable smart contract wallets that can be enhanced with state proofs. Wallets might identify the inactivity of a user's account by creating a state proof for the wallet at regular intervals, such as every day or every week. If there have been no transactions or changes to the wallet during that time, the state proof will be the same as the prior one. It is possible to establish if the wallet has been inactive or not by comparing the current status proof to the prior one. This might be beneficial for discovering inactive or abandoned wallets, as well as identifying accounts that have been hacked or otherwise manipulated.

This might be beneficial for developing new sorts of social recovery features, such as those that trigger when a person loses access to their wallet. If the wallet is deemed "dormant" by state proofs, the social recovery process may begin, allowing the user to regain access to their account.

Gaming

Web3 game creators are now in a difficult situation. They want their customers to be able to exchange their in-game things as NFTs on a thriving marketplace, but they also want to have minimal gas prices so that they are not a source of friction for the user. The community often compels developers to deploy their NFTs on the Ethereum blockchain since NFT markets on Ethereum have much more volume and liquidity than marketplaces on other chains. However, this creates a problem for game developers because if the NFTs are on Ethereum and the developers do not want to have a friction point of bridging, the game must also be deployed there.

Users will be forced to pay exorbitant transaction costs if the game is deployed on Ethereum. It makes no sense for a player to spend a few dollars in fees to engage with an on-chain game. Developers want to put their game on a layer 1 with lower gas, or perhaps a layer 2, but they still want their in-game goods to be desirable.

State proof might assist in eliminating this stumbling barrier. As a game producer, you may deploy your NFTs on one chain while utilizing them in another. There would be no asset bridging and no need to deploy everything on a single chain. State proofs would enable you to merely certify a player's ownership of a certain in-game NFT item on, say, Ethereum while carrying out the actual in-game interactions on a less expensive layer 1 or layer 2.

Governance

Many decentralized finance applications have embraced the concept of being distributed across as many chains as possible. While this might help to reduce rates for end users, it can also make governance more difficult. The majority of these protocols generate governance tokens that are distributed across various blockchains. Participants in the protocol may vote on protocol changes using these tokens. This, however, creates a logistical issue for the government programs that support voting. These apps struggle to aggregate a user's token balance across various chains. Users would have to depend on a trusted oracle or bridge their tokens back to a major chain (such as Ethereum) and vote there in the absence of state evidence. The governance application might utilize state proofs to examine the state of the user's balances and use the overall amount of tokens across several chains as their voting power.

Conclusion

State proofs improve the security of cross-chain applications. While state proofs can help applications, their importance to the application varies from case to case. State proofs might be used in certain applications, such as cross-chain bridges, to better secure user funds. Other applications may require a price feed that updates frequently, even though you would be relying on a third-party intermediary for the solution. However, assuming that an off-chain price feed is always required for every application is incorrect since state proofs may cover many of those gaps. Account abstraction wallets, gaming, and governance are immediate use cases; however, state proofs are still in their early stages of development, so we shall see how additional applications employ state proofs in the future. Web3 developers should fight for solutions that inherit the safety and trust of the protocols on which they are based.

Disclaimer:
This article is intended for and only to be used for reference purposes only. No such information provided constitutes advice or a recommendation that any investment or trading strategy is suitable for any specific name.

State proofs: The holy grail for smart contracts