Supra (SUPRA)

The idea behind Supra is to have a natively designed, fully vertically integrated blockchain stack composed of a Layer 1, in-protocol oracles, VRFs, Bridges, mutliVM support, and automation.

Basics

• Based in:
• Started in / Announced on:
• Testnet release:
• Mainnet release:

Audits & Exploits

• Bug bounty program can be found [insert here].

Technology

• Whitepaper or docs can be found [insert here].
• Code can be viewed [insert here].
• Consensus mechanism: Moonshot
• Algorithm:
• Virtual Machine: Supra is developing its own approach to this problem with a MultiVM that extends support to a few different VMs to allow different ecosystems to be sufficiently atomic in their operations.
• Development language used:

Transaction Details

• Capacity (TPS):
• Latency:

How it works

• From Delphi Digital (8-4-2024):

"The idea behind Supra is to have a natively designed, fully vertically integrated blockchain stack composed of a Layer 1, in-protocol oracles, VRFs, Bridges, mutliVM support, and automation. These components are run on the same nodes as consensus, simplifying cross-chain liquidity and reducing unnecessary latency.

Supra has developed a node management and coordination mechanism called the Tribe & Clans architecture. Here, a Tribe is a large set of nodes, and Clans are a smaller, randomized subset of nodes within a Tribe. Each of Supra’s components can be run on these Clans, and node resources are dynamically allocated to each component. Nevertheless, node resource requirements for several components in addition to a blockchain would still be high.

Supra expects to reduce the required percentage of honest nodes significantly by allowing transaction delivery and ordering to happen concurrently. Supra utilizes a formally verified consensus protocol called Moonshot.  Supra’s Moonshot assumes a fully connected network; each consensus node forms a direct point-to-point connection with every other consensus node. This allows each consensus message to be broadcast to all peers in one go without hops in between peers, greatly speeding up the time to finality. This is unlike Tendermint, which assumes a gossip protocol where nodes are loosely connected. Supra’s Moonshot consensus protocol leverages optimistic proposals to allow nodes to proceed with their consensus-related operations without waiting for the whole network’s confirmation at every step by assuming a positive outcome. This way, validator idle times are reduced, and the network throughput is maximized as more transactions are finalized in a shorter duration.

Supra’s Moonshot consensus protocol leverages optimistic proposals to allow nodes to proceed with their consensus-related operations without waiting for the whole network’s confirmation at every step by assuming a positive outcome. This way, validator idle times are reduced, and the network throughput is maximized as more transactions are finalized in a shorter duration. Moonshot then uses a mechanism called round pipelining to organize all of these optimistic operations in a continuous workflow, allowing multiple validators to work on multiple blocks simultaneously. A PBFT variant, Moonshot also uses pipelining to work on multiple rounds of consensus concurrently.

This reduces latency and increases throughput by allowing multiple blocks to be concurrently finalized instead of a sequential flow. While Moonshot would still require a 67% super majority, Supra’s components based on Supra Chain only need a simple majority of 51%, reducing the number of total honest nodes required across the whole Supra stack. Supra’s tech stack:

1)  DORA-backed Oracle Network with increased liveness, safety guarantees, and scalability

2) A distributed VRF solution with unbiased on-chain randomness

3) Hypernova, a Light client-based bridge and HyperLoop with its rational bridge design

4) MultiVM support

5) Supra’s Cross-chain Automation service

Let’s look at how Supra’s MultiVM design could manage the state across different VMs. The state of different VMs can be partitioned into their respective segments across Tribes and Clans of Supra nodes. Nodes maintain each VM’s state within Merkelized state trees or sub-trees. This makes it easier for Supra to make cross-VM calls with state proofs without worrying about dealing with the entire state of different VMs, which can lead to computational overheads. With different states partitioned, Supra can independently run different VMs without transactions needlessly interfering with each other’s state and enabling multiple VMs to work in parallel. With Supra’s Tribe-Clan architecture, all MultiVM nodes do not have to run all VMs and maintain the state of several VMs. Instead, MultiVM nodes can be sharded into smaller networks of Clans that can each run different VMs that process and execute transactions in parallel. With execution sharded across multiple Clans (that require 51% agreement), transactions targeting different VMs can be processed simultaneously rather than sequentially, leading to lower latency for smart contract execution."

Interoperability

Has its own HyperLoop bridge with Bridge Nodes, Whistleblower Nodes and an AuditDAO (8-4-2024):

"The idea with HyperLoop is that it allows all collusion and operates on a simple majority threshold compared to a supermajority threshold. Fewer nodes must be honest/live for the bridge to continue operating. This also means that fewer nodes get paid out bridge rewards, so the fee users are required to pay is also lower, and the total stake required by all the bridge nodes is cumulatively low. Users’ bridging fees can also be lowered when many bridge requests are batched together, resulting in a latency trade-off. There is a Sliding Window mechanism that limits how much value can be transferred through HyperLoop during a given time. This sliding window limit is capped at 51% of the total bridge stake. So, with each sliding window period, like an hour, they are capped at 51% of the total stake owned by bridge nodes. This means that over a 24-hour span, the aggregate transfer volume is limited to 24 times the 51% sliding window threshold. On the other hand, you have bridge nodes that need to stake to be a part of the network. The stake of each node is set to be greater than the fractional value of the total value being transferred through the bridge.

1. Bridge Nodes – These are staked nodes that run clients of both the source and destination chain to follow events. These nodes are responsible for conveying bridge requests and delivering bridge responses. Bridge Nodes can batch multiple requests together for economic efficiencies and revert transactions based on user requests.
2. Whistleblower Nodes – They run clients of source and destination chains to monitor and vet the actions of the bridge nodes. In cases where the Whistleblower nodes find discrepancies in the operation of the bridge nodes, the whistleblower nodes highlight them and raise complaints with the AuditDAO. If any dishonesty on behalf of the bridge nodes is found, the bridge nodes are slashed, and a portion of the slashed stake is rewarded to the whistleblower nodes. Whistleblower nodes have to put up collateral in case they want to raise a complaint with the AuditDAO as a safeguard against false complaints. To incentivize Whistleblower nodes to monitor for any dishonesty or collusion constantly, they are also periodically rewarded for continuing to keep an eye out.
3. AuditDAO – This is a trusted governing entity whose role is to validate and resolve disputes reported by the Whistleblower nodes, which can pause the bridge. The AuditDAO consists of multiple audit firms that have access to the state of both the source and destination chain. When a discrepancy is detected by a Whistleblower Node and is reported to the AuditDAO, the DAO can ask the Bridge Nodes to respond to it with proof. Their stake is slashed if the Bridge Nodes do not respond within a set duration."

Oracle Method

• From Delphi Digital (8-4-2024):

"Supra’s Oracles runs based on their DORA (Decentralized Oracle Agreement) protocol designed to improve data accuracy and latency. Let’s walk through how DORA is structured. DORA, or Distributed Oracle Agreement, dictates how Oracle nodes gather and aggregate off-chain data from several first-party and third-party sources to produce a single representative value (S-value) arrived at through statistical computations. This final value can then be directly sent to other chains or protocols.

Supra’s Tribes and Clans run the DORA protocol. The protocol helps Supra’s Oracle network manage high volumes of data requests and data sources. Each Clan is responsible for calculating and reaching a consensus on S-values (Single Representative Value or a final value) used by smart contracts. If the oracle network had to work on 1000 different S-Values with a setup of 4 Clans per Tribe, each Clan could work on 250 S values each. This is similar to a sharding mechanism where the whole Oracle network is not made responsible for sourcing, aggregating, and propagating all data, but Clans work on different data sets in parallel and in the capacity to take up more workload.

To ensure that all data sources are being used by all the nodes in a clan effectively and that no single data source is being ignored or used unfairly, a randomness cryptographic function called VRF (Verifiable Random Function) is used to assign data sources to nodes. The VRF mechanism adds an extra layer of randomness and fairness to the distribution of data sources so that the Oracle network can withstand potential adversarial scenarios and still continue to push out reliable data. Other Oracle service providers like Chainlink and Pyth have no randomization or shuffling mechanisms of their nodes or committees. Once all the nodes in a Clan gather price values from various sources, they calculate a median of those values.

Once a node sends its median value to an aggregator, it keeps track of whether or not an Aggregator has posted the S-value and a Quorum certificate to the SMR or Supra’s blockchain. If, within a certain duration, no Aggregator has been posted to the SMR, the nodes propose a vote to run the Fall Back Protocol. When more than half the nodes in a clan also vote for Fall Back, the Aggregator posts the Fall Back message to Supra’s blockchain, where all the other nodes can see it. This effectively moves the responsibility of calculating the S-value from the clan to the whole Tribe. Each tribe node gathers data, computes its median, and sends it to the aggregators. The aggregators then wait for values from at least 2/3rd of the tribe nodes and calculate the median of these values, ensuring that the single representative value (S-value) is still reliable even in unusual conditions. This broader participation of nodes helps anchor the price during extreme market fluctuations. With such instances, there is an inherent trade-off between latency and security/accuracy.

Speed is key for oracles. The faster a set of oracle nodes gather, aggregate, and reach a consensus that a certain value is accurate, the faster protocols can use the value. To this end, SupraChain uses the BFT Moonshot consensus. Given that price feed data is posted to and verified by Supra’s consensus mechanism, smart contracts on Supra can directly use this data for free without relying on external pull-based oracles. "

Roadmap

• Can be found [Insert link here].

Team, Funding and Partners

Team

• Full team can be found [here].

(:

Knowledge empowers all and will help us get closer to the decentralized world we all want to live in!

Making these free wiki pages is fun but takes a lot of effort and time.

If you have enjoyed reading, tips are appreciated :) This will help us to keep expanding this archive of information.

ETH tip address: 0x83460bE5F218b1520B69D702cE60A1DE37dD8E31