Release Blockhash Opcode Restrictions with zk-SNARKs for Optimistic Bridges

Repost from Ethresearch by tomo_tagami : “Release Blockhash Opcode Restrictions with zk-SNARKs for Optimistic Bridges” The full report and all related findings are available on the official website of Ethresearch.

This post is a proposed solution to release the restrictions that exist in Ethereum opcode by using zk-SNARKs. Furthermore, I hope to use this idea to solve the challenges of the optimistic bridges.

TLDR

Review of the optimistic bridge

If you already know about the optimistic bridge, please skip this part.

Optimistic bridges rather than requiring Ethereum to validate every bridge transaction, the protocol inspects only those that might be fraudulent. Suspicious activity can lead to a dispute, triggering a verification process settled by Layer 1.

Optimistic bridge consists of three participants - User, Relayer and Disputer. Relayer’s actions are constantly monitored by disupters and thrashed if fraud is discovered. See  this post  for more details.

Blockhash opcode

Ethereum has a blockhash opcode restriction commonly known as the “256 block problem”. The maximum number of blocks that can be referenced by Ethereum’s blockhash opcode is 256 blocks, and older blocks cannot be referenced.

This restriction means that at optimistic bridge, the time available for transaction verification by blockhash is only about 51 minutes (= 12 sec x 256 blocks). Consequently, the window for raising disputes is limited to approximately 51 minutes (12-second block time *256 blocks). In practical terms, this means that if disputers wish to challenge a relayer’s action, they have only about 51 minutes to do so, as the dispute process requires them to present the block hash of the contested transaction block as evidence. This tight timeframe could compromise system security and diminish the overall user experience.

Potential solution using zk-SNARKs

To address this restriction, I propose a solution leveraging zk-SNARKs.

Every block hash inherently embeds information from its predecessor. Given this property, it’s possible to create a cryptographic circuit that verifies the chain of block hashes, even beyond the most recent 256. This is done by anchoring the sequence with a block hash currently accessible via the blockhash opcode and tracing back to an older target hash.

In technical terms, if n1 represents the block number with the opcode-accessible block hash and n2 represents the block number of our target hash, the circuit would be designed to take three primary inputs:

These operations will utilize RLP encoding and the Keccak256 hash function. This circuit proves that there is a hash connection up to the target block hash.

The following image provides a visual representation of this chain of hashes. However, in practice, the circuit computes this in reverse order. While this graphic specifically illustrates a block hash chain on Ethereum, the principle could also extend to Layer 2 networks.

circuit1721×1080 137 KB

Although this approach is in the research phase and awaits full implementation—primarily because of its intricate nature—it seems almost inevitable that such zk circuits will find integration within the bridge dispute mechanism. This is especially true considering some Layer 2 networks impose even tighter restrictions on block hash access than the 256-block restriction.