Hyperproofs
Hyperproofs are succinct, crypto-economic and cheaply verifiable aggregated proofs produced by the Hyperbridge network for facilitating interoperability between multiple state machines concurrently.
Written by
Published on
Do not index
Do not index
Introduction
The Internet sets a standard for secure interoperability, and blockchain networks, which are an evolution of the Internet, must establish similar standards. As deploying a web application without TLS is unthinkable, deploying an interoperability protocol without cryptographic guarantees is even more alarming. In a previous article, we discussed how interoperability is essential to achieve scalability in blockchains. Like the internet, secure interoperability must be built around robust cryptographic guarantees that are extremely difficult to break. Cryptography offers foundational primitives that must be combined to make the entire system exponentially harder to compromise than any of its parts.
The anatomy of secure interoperability
One must understand several key concepts to grasp the anatomy of secure interoperability fully.
Consensus zones:
A consensus zone is a network that provides finality for a state machine or a group of state machines (Rollups). It guarantees the correctness of state transitions, and this guarantee is accessible as a verifiable consensus proof. Interestingly, the computation required to verify this proof is much less than that needed to execute the state transitions.
Interoperability fundamentally involves sharing state between state machines in different consensus zones. Since the consensus layers govern the correctness of these machines' states, the interoperability protocol must verify the consensus proofs before transferring state information. Light clients must verify these proofs, forming the first step in ensuring secure interoperability. Safety guarantees are maintained only if the protocol correctly verifies the consensus proofs of the zones it bridges.
State machines in the same consensus zone:
You might ask, "What about state machines (rollups) in the same consensus zone? Are they securely interoperable by default?". The answer depends on the following:
- Does the base layer have an auditing protocol that ensures the correctness of the state transitions of its rollups?
Suppose a base layer does not verify the state transitions of its rollups. In that case, it cannot know what each rollup's correct state commitment should be and cannot, as such, facilitate secure interoperability between them.
- Does the base layer make the finalized state commitments of all rollups securely available to each rollup?
For a base layer to facilitate secure interoperability between its rollups, it has to make the finalized state commitments of all rollups accessible to each rollup. This way, the rollups can verify cross-rollup messages using these finalized commitments.
In architectures where the base layer provides only data availability, each state machine is unaware of the finalized state of its sibling state machines. To achieve secure interoperability between these state machines, each roll-up must run a light client of the base layer to access the finalized state commitments of the sibling state machines required for secure cross-rollup messaging.
State verification:
Consensus proofs provide valid state commitments, which are cryptographic snapshots of the entire state of a state machine (all the keys and values in the database). When sharing messages through an interoperability protocol, the protocol passes around fragments of the state (some keys and values in the database). With a commitment to the entire state, we can verify the correctness of these fragments. This verification process is called state-proof verification. A secure interoperability protocol ensures the correctness of messages by sending a state proof to back each message. Successful verification of a state proof is the only authorization required to execute a message.
In summary, light clients verify consensus proofs that determine the finalized state commitment of a state machine. This state commitment then allows us to verify the existence or non-existence of keys and values in the database through state proofs. These are the two fundamental components of secure interoperability protocols.
It is also important to note that secure and trustless state proof verification is fully dependent on consensus proof verification, it is impossible to achieve secure interoperability without incorporating both.
Contemplating the possibilities
Secure interoperability opens the door to applications that were previously impossible. One reason blockchain interoperability has been limited to simple asset transfers is the insecure architecture of current protocols. Developers are hesitant to authorize more complex actions due to the risk of hacks, which could devastate the application and potentially impact multiple applications.
With secure interoperability, developers can now enable more complex cross-chain actions. For instance, instead of relying on liquidity providers, they can use a secure interoperability protocol to mint and burn assets, facilitating capital efficient cross-chain asset transfers.
Another benefit of secure interoperability is cross-chain call execution. Since a secure interoperability protocol minimizes the risk of exploits, applications can confidently authorize cross-chain call execution. This even extends to enabling the composition of multiple calls in a single cross-chain transaction.
Secure interoperability also enables asynchronous database reads, allowing applications to access specific keys and values stored in a counterparty chain's state. This capability facilitates the creation of trustless oracles.
Non-custodial cross-chain asset transfers: Using light clients for interoperability enables a fully non-custodial asset bridging experience, allowing users to maintain full control of their assets throughout the entire bridging process.
Onto the next stone: scaling secure interoperability with Proof Aggregation.
Hyperscaling secure interoperability
As mentioned earlier, secure interoperability requires a light client for each consensus zone. For a state machine that needs to connect to multiple state machines across various consensus zones, the number of light clients increases linearly with the number of zones to be bridged. The development and infrastructure requirements for these point-to-point connections becomes unsustainable as the network of chains expands.
Aggregating the various consensus proofs into a succinct and easily verifiable proof that confirms the finality of all connected state machines would be a practical solution.
There are a few approaches to proof aggregation. One method is using a zk proof to aggregate all consensus proofs through a zk Coprocessor. While this sounds elegant, the computational and time complexity of aggregating consensus proofs using zk is extremely high. In most cases, generating aggregated zkProofs for secure and accountable light clients is much more expensive than maintaining each light client independently. The lengthy proof generation times significantly increase message delivery latency. The major issues with zk proof aggregation are detailed below:
Unaccountability:
A secure light client must be accountable. This means it should identify all validator set members who signed a consensus proof through their signatures. This is crucial when a malicious consensus proof is submitted, as it allows reporting this equivocation to the parent chain and slashing the malicious validators. If these validators are unidentifiable, they cannot be punished, giving them the opportunity to continually compromise the light client with malicious proofs.
In zk light clients, accountability is achieved by ensuring validator signatures are part of the public inputs to the circuit. However for zk circuits, having the signatures in the public inputs would linearly increase the memory requirements of the circuit with the number of signatures that need to be verified because each signature has to be represented as a field element, this makes accountable light clients not feasible in cases where the validator set is large or accessible memory in the execution environment is constrained. This issue becomes more noticeable when aggregating consensus proofs from multiple light client circuits. The goal of proof aggregation is to produce proofs that are succinct and cheap to verify. Achieving this with zk circuits requires removing the signatures from the public inputs, which compromises the accountability of the light client.
Centralization:
zk proof generation requires very powerful machines. The capital cost of building or renting such machines is very high. This situation leads to only a few parties having the resources to run proof generation at scale, creating a heavily centralized proof generation cabal. This centralization has a major negative effect on the resilience of the protocol.
Finality Latency:
zk circuits are static and not dynamic. As a result, when aggregating consensus proofs from multiple light clients, all consensus proofs must be available simultaneously. This means proof generation is bottlenecked by the chain with the slowest finality. Coupled with the lengthy proof generation times of current zk systems, this significantly increases message delivery latency.
Hyperproofs
We need a proof aggregation system that provides the benefits of aggregated proofs while remaining accountable, cost-effective, quick to generate and accessible to all interested parties. For this we Introduce Hyperproofs.
We can use a specialized blockchain with high crypto-economic security to achieve proof aggregation. Hyperbridge, a fast and highly scalable crypto-economic coprocessor secured by the Polkadot consensus, is specifically designed for this task. Hyperbridge manages the light clients for all connected consensus zones, ensuring both their accountability and the decentralization of the protocol.
Hyperproofs are succinct, crypto-economic and cheaply verifiable aggregated proofs produced by the Hyperbridge network for facilitating interoperability between multiple state machines concurrently. This is possible because the Polkadot consensus has a highly secure auditing protocol (ELVES) backed by strong crypto-economic guarantees. This protocol ensures every computation on Hyperbridge is executed correctly, allowing it to run multiple light clients for an unlimited number of consensus zones hosting various state machines.
For a more detailed comparison between the economics of a zk coprocessor and a crypto-economic one, check out this article by Robert Habermeier
Hyperbridge becomes the nexus for cross-chain messaging. It verifies messages from multiple state machines across various consensus zones and aggregates them. A state machine from any integrated consensus zone only needs to run the Polkadot light client to receive aggregated messages from other consensus zones. State machines using hyperbridge as an interoperability coprocessor only need to verify Hyperproofs for cross-chain message validation.
With Hyperproofs, Hyperbridge is the most efficient aggregation layer for cryptographically secure interoperability.
Hyper-scalability
The keen eye will notice that message delivery can be bottlenecked by the coprocessor's throughput—this is where Hyper-scalability comes in. Hyper-scalability ensures that Hyperbridge will automatically scale its throughput to meet increasing demand for its blockspace.
Polkadot provides on-demand cores, allowing parachains to purchase additional compute resources to boost throughput. Hyperbridge leverages this by utilizing as many cores as needed to meet demand. The workload of message validation is distributed across these cores, and valid messages from all cores are aggregated by the Polkadot network without negatively impacting message delivery latency.
This ensures Hyperbridge is never a bottleneck for message delivery.
Written by
