Supra HyperNova Introduces Bridgeless, Cross-Chain Consensus

Traditional Bridge Designs Have Big Problems

Blockchain technology is quickly manifesting itself as a critical step in the evolution of society in areas including decentralized finance, asset management, supply chains, healthcare, and much, much more. As of August 2023 per DefiLlama, approximately $40 billion in TVL is secured by smart contracts in dApps across all blockchains. Combined with smart contracts, DeFi is providing alternative financial rails in the form of automated and distributed-protocol-driven, cryptography-enabled-trustless services. This stands in stark contrast to the status quo of centralized, human-driven services, requiring a great deal of trust. 

By design, most blockchains are limited in their information, knowledge, and assets by their set of validators. A blockchain’s validators are the decision makers in terms of the ordering of blockchain transactions, as well as forming the source of ground truth for the blockchain’s state. Hence, they are the authorities who validate as to which users control what assets on their blockchain. 

Each blockchain offers its own set of unique qualities, and many offer a suite of varied and distinctive services. That being said, it’s becoming ever clearer that DeFi is headed for a multi-chain future. Hence, we see a large number of users using multiple services – sometimes the same, sometimes different – across multiple ecosystems. Blockchain interoperability, mainly in the form of transference of assets and information from one chain to another, has thus become a necessity – and is naturally garnering the focus of researchers and builders alike.

The challenge of facilitating blockchain interoperability has led to the development of blockchain bridges. Most bridges are currently designed as what are called multi-sig bridges. These bridges generally consist of a set of staked bridge nodes, each of which individually sign the events happening on a source chain (e.g., locked funds in the source-chain’s currency), aggregate those signed events, and relay them with the signatures/seals of their agreement – a “multi-sig” – to a destination chain. This facilitates a corresponding action (e.g., release of funds in the destination-chain’s native asset or currency). Here, as you can see, the source chain’s L1’s security guarantee no longer persists, instead the security guarantee is reduced to that of the staked bridge nodes.

Generally, the coefficient of “decentralized trust” is a function of the number of independent validators in the network and the stake amount involved in the network.

The number of validators and the staked value of multi-sig bridges are generally much lower than the staked value or the number of validators of L1 blockchains. As the expression goes – “a chain is only as strong as its weakest link”, in the long path of the circulation of assets, multi-sig bridges have shown themselves to be the weakest link as their coefficient of “decentralized trust” is generally lower.

Consequently, bridges have become the target of both large and small scale attacks. An August 2022 report from Chainanalysis estimated that $2 billion has been stolen from bridge hacks alone. Therefore, to be effective and safe, bridges must NOT dilute the “decentralized trust” of the L1 and L2 blockchains they transfer assets between.

The Solution: Go Bridgeless

The solution is simple once you see it: verify the consensus of the source chain directly. However, verifying the consensus of one chain on another chain is no simple task. For example, Ethereum has a large set of active validators (more than 700K as of 6th August 2023). Verifying consensus entails aggregating the public keys that participated in the attestation of a block and then validating the aggregate signature. Since a large number of  public keys must be aggregated, this mechanism requires long verification times, and is inefficient in terms of gas consumption on the destination chain. This was precisely the motivation of introducing a ‘Sync-committee’ in the Altair Fork of Ethereum.

A Sync-committee is a sub-committee of a fixed size of 512 nodes drawn randomly from the full validator set of Ethereum, and is updated only once every 27 hours. The blocks of Ethereum are attested by Sync-committee validators on top of the regular attestation by the full set of validators. Accordingly, a Sync-committee attestation offers a cheaper way of verifying Ethereum consensus on other chains, thus facilitating the Relay model of bridging.

However, the Sync-committee consensus has been criticized (James Prestwich, Polytope Labs Research) mainly for NOT having slashing as part of its protocol. The main argument is that a dishonest Sync-committee can get away with a collusion attack targeting a specific trustless bridge.

On the contrary, studies from Succinct, Snowfork and T3rn show that the probabilities of such dishonest Sync committees are extremely low. For instance, the verification threshold could require that more than 90% of the Sync committee validators have signed off on a block to be considered valid. Then, even assuming that ⅓ of the full validators of Ethereum are dishonest to begin with, the probability of having a dishonest Sync-committee (not having at least 10% honest Sync-committee validators) is once in \(10^{31}\) years. That is a very, very long time. 

These studies also remark that, apart from protocol-based slashing, there are other practical security mechanisms owing to practical pseudonymity and reputation damage that are in place to deter such a dishonest Sync-committee act. We find that these probabilities and practical security aspects are more than sufficient to leverage the trustless bridging model, and as a result, we have built HyperNova — a trustless bridge design, along with a prototype showing asset movement from Ethereum to Supra and to multiplicate ecosystems.

Towards Supra’s HyperNova: A Bridgeless Protocol

As long as Supra has awareness of the active validator set of Ethereum, Supra itself can verify Ethereum’s majority consensus agreement. In order to get this information from Ethereum to Supra, however, the addition of a relay node is required, which simply relays the events of a source chain (Ethereum), while requiring Supra’s validators to verify the validity of these events explicitly. This is in stark contrast to using a traditional ‘multi-sig’ majority agreement protocol for the bridges. In short, Supra verifies Ethereum’s L1 consensus cryptographically. 

How does Supra gain awareness of the active validator set? For proof-of-stake networks like Ethereum, consensus is required for validators to know the public addresses of the current active node operators. The previous active validators vote on inducting new nodes to join the network and there is cryptographic proof of this shift in the new active operator set. This information is verifiable through a virtual hand-off from the previous active set cryptographically signing off on the new set of operator nodes.  

In Supra’s HyperNova, relay nodes simply share the source chain’s cryptographic consensus information, while the verification is processed on Supra itself. Since no one can forge Ethereum’s consensus information, anyone in the world can play the relay role. It is pertinent to emphasize that a relayer cannot cause any safety issues, as the validity of events of the source chain is verified independently on the destination chain. In short, no relay node can tamper with the information provided from the source chain. Therefore, attacks that use false information in order to release or mint assets on the destination chain without locking the corresponding assets on the source chain are just not possible.

Again, at least one honest node is required so that the relevant events are not missed when being relayed. Since we do not need to trust any intermediary bridge nodes for the correctness of the passed information, this Relay model, which only requires a single honest node to be active for liveness, is popularly referred to as a trustless bridge. In the HyperNova bridgeless model, we only rely on a relay node for forwarding the data and not for verifying the correctness of the data. Therefore, large stakes are not needed by bridge nodes. A single honest node simply needs to be present in order to ensure liveness and censorship resistance. Moreover, multiple rounds of consensus can be avoided, thereby enabling faster execution.

Interestingly, this idea naturally extends to many other chains. We are building similar research prototypes for other chains too, including Aptos and Sui. Just like the process for Ethereum, we can gather the validator set information of these chains as well. Then we have a relay node transmitting the relevant events on these chains to Supra SMR where these events are validated on Supra SMR.

Another important aspect is that Supra’s Layer 1 consensus protocol uses threshold signatures to attest blocks. Consequently, verifying Supra’s blocks on any other chain is as simple, easy, and efficient as verifying a single BLS signature. We are also investigating Zero Knowledge-based approaches (ScalingX, Web3 Foundation) for trustless bridging.

Supra as Web3’s Interoperability Hub

Supra’s unique value proposition is that it facilitates the vertical integration of multiple services like Oracles, Random Beacons and Verifiable Random Functions. It also enables the upcoming Platinum Automation Network on top of a native Layer 1 Smart Contract platform. This integrated approach makes Supra’s blockchain a self-containing one where users do not necessarily have to leave the system for most of their blockchain-based activities, nor for reading or applying data from the off-chain world via oracles.

Due to its trustless nature of bridging the information and assets across chains, the Supra HyperNova protocol carries the level of “decentralized trust” of the source blockchains rather than vulnerable multi-sig bridges. What’s more, with HyperNova the reach of Supra’s existing services can now more easily extend across an increasing number of chains and networks. In addition, because of the vertical integration of Supra’s architecture, workflows are optimized and enriched with value-added services. This positions Supra as a powerful hub for interoperability capable of easily connecting multiple blockchains in a secure and decentralized manner. 

From the perspective of a client, Supra offers a simple single-shot trigger mechanism. That means just the very first transaction at the source chain guarantees the execution of all the subsequent actions and transactions across multiple chains. This initial transaction can include all the necessary logic including acceptable asset conversion rates, timing, and predicates for scheduling tasks on Supra, consuming verifiable random functions, and even function calls to multiple other chains, etc.

Demonstration

As a proof of concept demonstration of this idea, we showcase the following workflow: we use the HyperNova protocol to transfer 1 ETH from an Ethereum account and deposit to accounts in native currencies on two different chains – Aptos and Sui. Though we have hardcoded the conversion rates in this demo, we plan to integrate our oracle services to enable on-the-fly conversion in subsequent updates.

Supra as the IntraLayer

In conclusion, though the blockchain space is segregated into L1s and L2s, we work towards a view that the entire space is actually one unified layer of multiple blockchains offering various services. We then posit Supra as a component that offers integrated services on its own as well as seamlessly connects and blends all the services across multiple chains. Thus we refer to Supra as an IntraLayer, a specialized layer that cryptographically merges all chains into one.

References

1. Sync Committee and Consensus Light Client in Ethereum https://github.com/ethereum/annotated-spec/blob/master/altair/sync-protocol.md 
2. Accountable Light Clients for PoS blockchains https://eprint.iacr.org/2022/1205
3. Investigation into introducing slashing for Sync-Committee by Nimbus https://github.com/ethereum/consensus-specs/issues/3321