Supra is building a blockchain platform that integrates oracles, VRF, cross-chain, and automation services, aiming to solve the problem of fragmented liquidity.
Author: Delphi Digital
Modular blockchain has achieved permissionless innovation above the base layer, and its ability to separate settlement and execution allows many products to be developed without being constrained by the base layer. However, this has brought us a serious problem of fragmented liquidity.
Users need to continuously perform cross-chain operations to explore more assets, enjoy a better user experience, and obtain a higher level of security. As rollapps/appchains (Zora, Fraxchain, Base) and other applications gradually become mainstream, this demand will become more urgent. Our goal is not only to maintain liquidity, but also to achieve unimpeded circulation of information between different blockchains. In promoting wallet transactions and balance information exchange, security and cross-chain oracles play a crucial role. Popular oracles and cross-chain protocols such as Chainlink and LayerZero, although operating outside the protocol, operate on a network independent of the chain consensus network, which not only increases additional costs but also cannot provide the same level of security as the underlying chain. The phenomenon of liquidity dispersion is not limited to the EVM ecosystem. Platforms such as Solana, Cosmos, and recently emerging ecosystems such as Sui and Aptos based on the Move language have also accumulated considerable liquidity. The chains in these ecosystems have their own advantages in virtual machines (VM), domain-specific languages (DSL), and chain state management.
Supra is committed to building a natively designed, fully vertically integrated blockchain platform, the core of which includes Layer 1 solutions, native oracle services, verifiable random functions (VRFs), cross-chain interoperability protocols, multi-virtual machines (Multi-VM), and automation features. These innovative components work together on consensus nodes, optimizing cross-chain liquidity and significantly reducing transaction latency. By integrating these key features into the base layer, Supra aims to facilitate data exchange between different blockchains and achieve unimpeded interaction between protocols. Thanks to multi-VM support, Supra can achieve efficient parallel transaction processing on different virtual machines, thereby achieving efficient execution sharding.
When building a vertically integrated service system, carefully designing service components is crucial. Improper design may cause network nodes to bear additional pressure, affecting network throughput and system response speed. Although increasing nodes or using efficient hardware can alleviate these problems, the optimization effect of this method is limited. Increasing the number of nodes can indeed improve performance, but after exceeding a certain threshold, further increasing nodes may become a new obstacle to performance improvement and network coordination. In addition, relying on high-end hardware will increase the initial investment of the network. Therefore, when designing service architecture, it is necessary to balance performance, cost, and scalability to achieve the optimal network operating efficiency.
Tribe - Clan Architecture
To effectively address this issue, Supra has carefully designed and implemented an innovative node management and coordination system, named "Tribe - Clan Architecture." In this architecture, a tribe represents a collective of numerous large nodes, while a clan specifically refers to a randomly selected small node set within the tribe. All of Supra's components can operate efficiently on these clans, and node resources will be dynamically allocated to various components according to demand. However, despite this, there are still several components that require a large amount of node resources in addition to blockchain technology. Therefore, ensuring that these components can obtain sufficient resources to maintain their performance is a key focus for us.
Using Moonshot for Simple Consensus, Not Supermajority
In blockchain technology, systems that apply traditional Byzantine Fault Tolerance (BFT) consensus mechanisms typically require more than two-thirds of nodes to operate honestly to ensure system stability. These systems sort transactions before validation, but the transmission, sorting, and execution of transactions do not necessarily have to occur in the same order. The important thing is to ensure that all transactions can eventually be executed to prevent inconsistent blockchain states.
The Supra project proposes a new approach that effectively reduces the required proportion of honest nodes by allowing parallel transmission and sorting of transactions. The Moonshot consensus protocol adopted by Supra has undergone rigorous formal verification. It is based on an idealized network model in which each node has direct point-to-point connections with all other nodes, allowing consensus messages to be instantly broadcast to all nodes without intermediate nodes, thereby speeding up the final confirmation of transactions. This is in contrast to Tendermint's looser node connections and propagation mechanisms.
Supra's Moonshot consensus protocol uses an optimistic proposal mechanism, allowing nodes to continue executing consensus operations without waiting for network confirmation when expecting positive results, reducing validator idle time and increasing network throughput. In addition, through a round-robin mechanism, optimistic operations are organized in order to efficiently process multiple blocks by multiple validators simultaneously. As a variant of PBFT, Moonshot also introduces a pipeline workflow to support parallel consensus rounds, reducing latency and further increasing throughput. Although consensus requires support from 67% of the supermajority, Supra's Supra components only require a simple majority of 51%, effectively reducing the number of honest nodes required in the ecosystem.
Through its unique approach, Supra is committed to bringing significant differentiation advantages to application developers and programmers, thereby triggering a power structure revolution in the current crypto infrastructure, including oracles, cross-chain technology, and other key components. This report will delve into the technical architecture of Supra and explain the intricacies of its various components one by one.
- DORA-based oracle network with enhanced activity, security guarantees, and scalability
- Distributed VRF solution with unbiased on-chain randomness
- Hypernova based on light clients for cross-chain and HyperLoop with a reasonable cross-chain design
- Multi-VM support
- Supra's cross-chain automation service
- We will also explore how the Tribe - Clan architecture achieves Supra's vertical integration
DORA – Distributed Oracle Protocol
Blockchain and smart contracts cannot directly access off-chain or cross-chain data, and oracles play a crucial role in enabling smart contracts to access external information, such as Web2 data, price information, or on-chain events. This external data is crucial to the logic of smart contracts, and oracles ensure the accurate transmission of data. In the decentralized finance (DeFi) field, especially in lending and derivatives protocols, the reliance on oracles is particularly prominent. Lending protocols rely on accurate price data to assess the value of collateral, execute loan issuance, liquidation, and determine interest rates. Derivatives protocols also require oracles to assess asset values, respond to market changes, and calculate funding rates. This dependency increases reliance on third-party intermediaries. According to DefiLlama data, the total locked value (TVL) of cross-chain DeFi protocols has reached $150 billion, of which approximately $48 billion relies on oracle services, demonstrating the core role of oracles in the DeFi ecosystem and their significant importance for market stability and efficiency.
As the leader in the oracle market, Chainlink occupies more than half of the market share. At the same time, new competitors such as Pyth, API3, UMA, and Supra are also emerging. Although Supra is a newcomer, its positioning as a full-stack vertically integrated infrastructure platform enhances service security and significantly reduces response time.
The oracle architecture of Supra adopts the innovative DORA protocol, which collects and integrates first-party and third-party data, uses statistical methods to calculate a unified representative value (S value), and this value can be directly used for other blockchains or protocols. Next, we will explore how Supra uses its technical advantages to address key challenges in the field and provide innovative solutions to the market.
Tribe - Clan Architecture
Supra's oracle network adopts the Tribe - Clan architecture, where a tribe is composed of multiple nodes that collectively run multiple components of the network. Even if one-third of the nodes in the tribe exhibit Byzantine behavior, such as malicious operations or being offline, the tribe can still operate normally. To enhance the network's resilience, the tribe is further divided into smaller clan units, and members are effectively at reduced risk of having more than half of the Byzantine nodes through random selection. This design allows the Supra network to demonstrate high robustness when facing potential collusion and liveness issues.
Supra's tribes and clans use the DORA protocol, which is crucial for managing a large number of data requests and sources in the oracle network. Clans play a central role in the protocol, responsible for calculating the S value on which smart contracts depend, i.e., the final single representative value. For example, when the network needs to process 1000 S values and each tribe has 4 clans, each clan will process 250 values. This division of labor is similar to sharding technology, allowing the network to efficiently process data sets in parallel, enhancing its ability to handle large volumes of data.
Data Collection
Oracles collect information from multiple data sources at different time points to find a reliable S value, ensuring the consistency and accuracy of smart contract execution. The DORA protocol aggregates information from centralized exchanges, decentralized exchanges, market makers, and data providers to form a trusted single value. Even if some data sources are unavailable or provide incorrect data, this mechanism ensures that smart contracts are executed based on accurate data, ensuring the accuracy and reliability of execution.
Shuffling
To ensure that all nodes within a clan use all data sources equally and efficiently, we have introduced Verifiable Random Function (VRF) technology to randomly allocate data sources to nodes. This mechanism increases the randomness and fairness of the allocation process, ensuring the stability of the oracle network and the quality of data services in the face of challenges. Compared to other service providers such as Chainlink and Pyth, Supra's VRF has a clear advantage in node randomization. More detailed information about Supra's VRF will be discussed in the future.
Aggregation
In the clan network, nodes extensively collect information and calculate a median value to ensure that it falls between the highest and lowest values reported by all honest nodes. This median value is then transmitted to aggregator nodes in the oracle network, and the selection of aggregators is random to ensure the inclusion of at least one honest node.
The aggregator's responsibility is to integrate all inputs to form a unified value. Once consensus is reached within the clan on the median value and it is sent to the aggregator, the aggregator begins working to aggregate the values, creating a "Coherent Cluster" (CC).
The CC is a collection of multiple values, where the difference between any two values in the collection does not exceed D units, which is crucial for the success of the oracle integration protocol. For example, on September 20, 2021, on the Pyth platform, two out of 11 publishers made decimal errors in the BTC/USD price. Due to an aggregation logic error that gave excessive weight, the price of Bitcoin significantly dropped below the market price, plummeting to $5402, leading to a significant number of unwarranted liquidations.
In preventing the spread of incorrect prices, Byzantine fault-tolerant nodes and Coherent Clusters play a crucial role. The DORA protocol provides an effective solution. Taking a system with five nodes A, B, C, D, and E as an example, the BTC prices reported by these nodes are as follows, with a maximum price difference of $200 as specified by the protocol:
- A - $43800
- B - $43850
- C - $43700
- D - $45000
- E - $43900
If the price difference between nodes A, B, C, and E does not exceed $200, they form a stable cluster. This ensures that even if four nodes are abnormal, a single honest node can stabilize the price and prevent fluctuations. Node D is excluded due to price deviation to prevent overall impact. Once the cluster is formed, the aggregator calculates the average price of the nodes to obtain the S value, enhancing system robustness and ensuring stability. The maximum price difference specified by the protocol effectively limits the impact of abnormal nodes.
After calculating the S value, it and the cluster information are verified among clan nodes through voting. The information is sent to all nodes to collect support votes. Once more than half of the nodes approve the S value and the cluster, a legal certificate is generated. The aggregator then carries the S value and certificate and directly transmits them to the target chain. Supra's DORA protocol supports direct data transmission to the target chain, improving real-time performance and making information delivery more efficient.
Backup Protocol
In certain cases, the data provided by honest nodes may not form a logically consistent group, which may be due to market volatility, market manipulation, data source failures, Byzantine node anomalies, or network issues causing values to exceed the protocol threshold.
After the nodes transmit the calculated median value (S value) to the aggregator, they continue to monitor whether the aggregator publishes the S value and the proof of the legal certificate to the SMR or Supra blockchain. If the aggregator does not publish the information within the specified time, the nodes will propose to initiate a vote to select an alternative protocol. Once more than half of the nodes support it, the aggregator will publish the alternative information on the Supra blockchain, making it visible to all nodes. This extends the responsibility for calculating the S value to the entire tribe. Tribe nodes will collect the data, calculate the median, and send the result to the aggregator. After receiving data from at least 2/3 of the tribe nodes, the aggregator calculates the median to ensure the reliability of the S value in unconventional situations. This helps stabilize prices during market fluctuations but requires a balance between processing speed and security/accuracy.
Anomaly Detection
We have noticed that oracles have provided price information as expected, but in some cases, they have reported abnormal prices, which may have a negative impact on protocols and users. For example, in the Pyth BTC/USD event, timely cessation of the use of incorrect data could have avoided unwarranted liquidations. To ensure the stability of price inputs, applications should use confidence intervals rather than a single median price.
When a DeFi protocol faces abnormal events, it can use the circuit breaker mechanism of DORA to temporarily suspend borrowing and margin trading to prevent a chain reaction. The circuit breaker mechanism monitors the current and historical data of the S value, and is activated when the change in the S value exceeds a preset threshold. Once the S value sequence is recorded on the Supra blockchain, circuit breaker conditions can be set based on historical records to evaluate abnormal fluctuations. The anomaly detection mechanism can be customized to assess specific price deviations, such as BTC/USD and ETH/USD. Additionally, the anomaly detection algorithm needs to be continuously optimized to more accurately distinguish market fluctuations from potential manipulation or collusion.
When an S value is successfully recorded on the Supra blockchain, it represents the successful completion of a cycle. However, not all S values can be discovered and reach consensus smoothly. If an S value is not published as scheduled, it may be due to the formation of clusters taking too long, or interference from Byzantine nodes and data sources. In this case, a new cycle can be initiated to determine an independent S value. If the new cycle reaches consensus faster, the old cycle will be terminated to save computing resources. The initiation mechanism of DORA ensures that even if the first-round price protocol is delayed, price publication can proceed smoothly.
Final Determinism
The efficiency of oracles is their core value. SupraChain adopts the BFT Moonshot consensus mechanism to quickly confirm data accuracy and improve protocol response speed.
The Moonshot consensus achieves parallel finalization of multiple blocks through optimistic proposals and pipeline processing, surpassing traditional sequential processing. It also improves the finality speed of the SupraChain oracle by broadcasting transactions to all nodes, replacing the BFT gossip mechanism. With the arrival of the DORA update, the SupraChain oracle is expected to achieve data freshness of 600-900 milliseconds, significantly ahead of its competitors. The optimization of DORA allows for direct data transmission, eliminating the step of first publishing on the blockchain and then transmitting through Wormhole, reducing latency, and is particularly suitable for applications with high data timeliness requirements.
The Supra platform adopts two oracle modes: on-demand pull and real-time push. The pull oracle only works when smart contracts request data, suitable for scenarios with infrequent data updates, effectively saving costs. The push oracle consumes more resources due to frequent data updates or transactions. For blockchains like Sui and Aptos, cost-effective scaling is achieved through single threshold signature verification and a strategy of 500 data pairs. The consensus mechanism of the Supra platform is responsible for the publication and verification of price information, allowing smart contracts to directly and freely access data, improving efficiency, reducing reliance on external data services, and providing stable and economical data support for contract execution.
Determinism and Randomness - DVRF
Blockchain technology is known for its transparency and determinism, aiming to achieve consensus among participants. However, generating true randomness in this environment poses challenges, mainly in preventing the manipulation of randomness. To address this, we have adopted Verifiable Random Function (VRF), which not only generates random numbers but also ensures the public verifiability of the generation process, thereby ensuring the fairness of randomness.
Verifiable Random Function (VRF) helps generate these random numbers and provides them to smart contracts and protocols on the chain. Randomness can be used for various use cases.
VRF plays a crucial role in the blockchain field, especially in on-chain games and NFTs, ensuring the random allocation of loot boxes and the unpredictability of NFT attributes, providing players with a fair gaming experience. Additionally, VRF is responsible for random events in games, such as critical hit judgments, to ensure their randomness. In proof-of-stake blockchains such as Polkadot, Secret Network, Algorand, and Cardano, VRF selects block proposers by generating random values, combining the stake and reputation of validators, enhancing the decentralization and security of the blockchain.
In the implementation of random functions (VRF) on platforms like Chainlink, users submit VRF requests through smart contracts. The request is sent to a node with a secret key, which calculates the VRF, generates an off-chain random number and the corresponding cryptographic proof, and then feeds them back to the smart contract for on-chain verification. While this mechanism ensures the reliability of random values, the way nodes use their keys may become a single point of failure for system stability.
Supra's distributed Verifiable Random Function (dVRF) technology provides a new approach to solving the problem of random number generation. In the Supra system, VRF requests are distributed to multiple nodes, each managing a portion of the keys. When users interact with smart contracts, the system generates a unique "input" (INP) and sends it to an aggregator node, which then forwards the INP to a clan of VRF nodes. Even if some nodes fail, the clan can continue to operate based on the majority principle, even if 50% of the nodes are malicious. Using Shamir's secret sharing mechanism, nodes collectively maintain complete keys, independently calculate a portion of the random number and correctness proof, ensuring that no single node has access to all the information. After the calculation is completed, the nodes aggregate the results to the aggregator, forming the final random number output.
The practicality of public Verifiable Random Function (VRF) has certain limitations. Since the output of VRF is public, participants need to frequently query VRF to obtain new random values to avoid players gaining unfair advantages by adjusting strategies. To address this issue, Private VRF (PVRF) has emerged.
Private VRF and Batch Processing
PVRF technology effectively enhances privacy protection by introducing a masking factor. This factor can hide user input, ensuring that only entities with the corresponding masking factor can decrypt it. After VRF nodes calculate the masked input, they generate partially masked outputs, which are then sent to aggregator nodes for integration to form complete masked outputs. The verification process is completed without revealing specific values, while the masked outputs and proofs are made public for verification. Users can publish their unmasked random numbers at the appropriate time and compare them with previously published masked random numbers to complete verification.
Batch verification of VRF significantly reduces costs and provides efficient services for applications with high demands for randomness and sensitivity to latency, such as GameFi or online casinos. A single private VRF can act as the source of thousands of VRFs. By arranging PVRF to simplify the verification process, batch verification of all derived VRFs can be ensured with a single verification, greatly improving efficiency.
Supra HyperNova - Cross-Chain Solution with Star Topology
In decentralized systems, trust is not established by centralized institutions but by consensus nodes staking tokens. Ethereum's consensus protocol involves millions of validators making collective decisions to achieve consensus on the system state. L1 protocols like Ethereum and Solana use the Proof of Stake (PoS) mechanism, with security guaranteed by a large amount of staked assets. Validators are rewarded for honest behavior, while misconduct may lead to loss of staked assets.
Here is the translated text:
One useful solution here is to use L1 validators for cross-chain (e.g., IBC). While exploring this cross-chain technology, we discovered an innovative solution that effectively improves the efficiency of the Ethereum network. Faced with the challenge of the traditional Ethereum validation mechanism handling the signatures and proof data of over a million nodes, the core contributors proposed an efficient solution: the introduction of a sync committee. This group, consisting of 512 randomly selected validation nodes, simplifies the consensus validation process and reduces resource consumption. Light clients can use the committee's signatures on the main chain block headers to verify the chain state without downloading all the data. To ensure fairness and security, the members of the sync committee are reorganized every 27 hours to prevent any collusion among fixed sets of validators. As compensation for the additional responsibility of the members, the sync committee members will receive higher rewards.
HyperNova Architecture
In the Ethereum network, relay nodes and light clients play crucial roles. They not only take on the responsibilities of full nodes but also run the Beacon chain. Approximately every 27 hours, the relay nodes hand over the sync committee, which is an important mechanism for light clients to obtain the latest on-chain state. In addition, the relay nodes monitor cross-chain requests on the source chain to ensure accurate cross-chain responses are delivered to the target chain. When specific events occur, the relay nodes integrate event details, proofs, and Beacon block headers into transactions, submit them to the Supra chain to ensure accurate information and smooth operations.
Supra Chain: Supra plays a central role in cross-chain communication, responsible for receiving and verifying cross-chain requests initiated by relay nodes. These requests include various events on the source chain and sync committee changes. The Supra chain independently verifies the consensus mechanism of the source chain and generates unique supermajority L1 proofs, which are then sent to the target chain for further verification, laying the foundation for cross-chain interactions for smart contract execution or fund transfers. Additionally, the Supra chain efficiently verifies blocks on the target chain using BLS signature technology. To ensure security, it continuously monitors the active set of validators on other chains to ensure broad consensus. With the dynamic changes in the validator set, former members need to sign and confirm the new set to maintain system stability and reliability.
Delay and Security Considerations
The block generation time of the Supra chain is approximately 2.5 seconds. To achieve cross-chain operations from Ethereum through HyperNova, the Ethereum block generation time (12 seconds), the 2.5 seconds of the Supra chain, and the potential block generation delay of the target chain must be considered. Additionally, the Ethereum sync committee will provide additional security, although the reliability of its security will be further discussed below.
Using light client technology on Ethereum is not a new concept. We have already witnessed the application of light client technology in the Cosmos Hub's IBC protocol, the Beefy mechanism in the Polkadot ecosystem, and the upcoming Tinydancer project in the Solana ecosystem.
For light clients on Ethereum, their security not only inherits from Ethereum's PoS mechanism but also benefits from its large validator community—1 million validators and a sync committee consisting of 512 members. However, this setup is not without trade-offs and security considerations, which will be analyzed in detail in the subsequent discussions.
When designing the penalty mechanism for the Ethereum sync committee, we took a cautious approach to avoid unnecessary complexity for the protocol. Considering Ethereum's economic model, even with 32 ETH as the validator's stake, multiplied by the scale of 512 validators, the economic security threshold is still relatively low, which helps to resist potential corrupt behavior. For large entities like Chorus One or Figment, their holdings may be more significant. It is worth noting that if validators engage in collusion, they may not only face legal sanctions but also suffer social and reputational losses. Although they may not be directly penalized by the protocol, the resulting loss of future income and reduction in delegated stakes undoubtedly serve as a strong constraint.
Furthermore, to enhance the consensus stability of the sync committee, we have adopted an innovative approach. Compared to traditional Byzantine Fault Tolerance (BFT) protocols, the Supra protocol ensures higher decision consistency by raising the consensus threshold from the usual 67% to 75% or higher, thereby ensuring a higher level of decision consistency. This strategy not only enhances the security of the system but also provides additional guarantees for the stable operation of the entire network.
Collusion - Sync Committee and Relay Nodes
On the Supra chain, there is a possibility of collusion between the sync committee and relay nodes, attempting to publish an erroneous block. However, given that the block generation cycle of Ethereum is approximately 12 minutes, this provides an opportunity for honest relayers to submit an error-free block within this time. Once the Supra chain detects two conflicting blocks within the same time window, it will pause processing for further verification. During this pause, Supra's DAO or relevant governing body will intervene to verify the correct block, ensuring that the Supra chain can continue to smoothly process valid cross-chain requests.
While the sync committee cannot fully replicate all the security features of Ethereum's Proof of Stake (PoS) mechanism, its proposed solution appears practical in operation, and Ethereum has set corresponding standards for these parameters. Currently, Supra, Polyhedera, and some other teams are actively advancing, aiming to develop a trustless cross-chain solution based on Zero-Knowledge Proofs (ZK SNARKs) to verify the complete Ethereum consensus process.
Supra HyperLoop - A "Game Theory Secure" Bridge Design
Supra's HyperLoop technology, as an innovative multi-signature bridge, adopts a 51% signature threshold mechanism. Its core concept is derived from profound insights of game theory, aiming to build a system where rational nodes will not gain additional profits from collusion. This design ensures that for any potential misconduct, the potential penalties and losses will far exceed the benefits they may gain. Therefore, HyperLoop is not only a bridge design but also an anti-collusion security mechanism validated by game theory. Now, let's delve into how HyperLoop achieves this goal through its unique design.
HyperLoop Architecture
Bridge Nodes: These nodes play a crucial role as stakers, running clients for both the source and target chains to track and record events in real-time. Their core responsibility is to efficiently process bridge requests and promptly provide corresponding bridge responses. To achieve cost-effectiveness, bridge nodes can batch multiple requests, and they also have the ability to cancel transactions based on user needs.
Whistleblower Nodes: These nodes also have the capability to run clients for both the source and target chains, and their main task is to supervise and review the operations of bridge nodes. Upon detecting abnormal operations by bridge nodes, whistleblower nodes will immediately expose their behavior and submit formal complaints to the auditing DAO. If the misconduct of bridge nodes is confirmed, a portion of their stake will be reduced, and the whistleblower nodes will receive corresponding rewards. To prevent false complaints, whistleblower nodes must provide a certain amount of collateral. Additionally, to encourage whistleblower nodes to remain vigilant, they will receive regular rewards to incentivize continuous monitoring of any potential dishonest or collusive behavior.
Audit DAO: This is a trusted governance entity composed of multiple auditing companies, responsible for verifying and resolving disputes reported by whistleblower nodes. These auditing companies have access to the state information of the source and target chains. When issues are discovered and reported by whistleblower nodes, the Audit DAO will require bridge nodes to provide necessary evidence for a response. If bridge nodes fail to provide a satisfactory response within the specified time, their staked assets will face reduction.
In many bridge security models, there is often an assumption that bridge nodes may act with integrity or maliciously. However, when these nodes engage in malicious behavior and collude, users' funds within the bridge are at risk of loss, flowing to arbitrary addresses designated by colluding nodes. LayerZero assumes that Oracle and Relayer will not collude, while Wormhole adopts a 13/19 multi-signature mechanism to enhance security. In contrast, HyperLoop adopts a more open strategy, allowing for any form of collusion but executing operations using a simple majority threshold instead of a supermajority threshold. The advantage of this approach is that it reduces the requirement for the number of honest or online nodes, allowing the bridge to continue operating with fewer participating nodes. Consequently, this also reduces the number of nodes receiving bridge rewards, thereby lowering the fees users need to pay and reducing the total staked amount required by all bridge nodes.
Furthermore, when multiple bridge requests are processed collectively, users' bridge fees are reduced, achieving a trade-off in latency.
Through the design of its economic incentive structure, HyperLoop ensures that even if malicious nodes choose to collude, their behavior will not bring economic benefits. The bridge employs a sliding window mechanism to limit the value that can be transferred through HyperLoop within a specific time. This limit is set to not exceed 51% of the total staked amount in the bridge. In other words, within each sliding window period (e.g., one hour), the aggregated transfer amount will not exceed 24 times the 51% threshold. For participating bridge nodes, this design not only enhances security but also optimizes economic efficiency. Whistleblower nodes have the right to submit complaints to the Audit DAO if they find that bridge nodes' forwarded bridge requests do not match what they observe at the HyperLoop smart contract endpoint on the source chain. Based on the evaluation results, the Audit DAO has the authority to withhold the staked assets of malicious nodes. How does this mechanism ensure that collusive behavior does not bring profits?
The staked assets of each node are carefully designed to ensure their value is higher than a certain proportion of the total value transferred through the bridge. Therefore, for bridge nodes, maintaining integrity and not engaging in collusion is a rational choice induced by the Nash equilibrium state during the operation of the HyperLoop protocol.
Although HyperLoop theoretically constructs a secure game environment, the possibility of collusion between whistleblower nodes and bridge nodes still exists. In this potential collusion scenario, attackers may choose not to report any anomalies to the Audit DAO while assuming the absence of honest whistleblower nodes. However, this assumption overlooks the supervisory capabilities of the Audit DAO and the credibility of other nodes in the HyperLoop protocol, underestimating the overall system's resilience to risk.
As a Multi-VM Smart Contract Platform - Supra
EVM technology has been widely adopted across many blockchains, with a survey indicating that up to 87% of multi-chain developers are developing on at least one EVM-based chain. Ethereum still holds a central position in the innovation of smart contracts. According to the Electric Capital Developer Report, over 71% of new contract logic is initially deployed on Ethereum before being migrated to other EVM-compatible chains such as Arbitrum, Polygon, Optimism, BNB, Base, and Avalanche. Additionally, EVM chains account for 75% of on-chain liquidity, highlighting their significant position in the cryptocurrency ecosystem.
Since 2020, blockchain networks based on the Move language have emerged, with projects such as Sui and Aptos adopting the Move VM, with a total locked value exceeding $900 million. In 2023, these platforms welcomed over 1700 new developers who actively engaged in coding work. Compared to EVM, Move has specialized advantages in handling on-chain smart contracts for asset transfers and is more efficient in memory usage. We will delve into a deeper comparison of Move and EVM in their execution environments in subsequent reports.
We observe a divergence of liquidity across different ecosystems. Each virtual machine (VM) may adopt unique state management mechanisms, transaction execution processes, and asset management methods.
Supra is actively developing innovative solutions to address this challenge. The MultiVM platform launched by the company is compatible with various virtual machines, ensuring a high level of consistency and integrity in the operation of various ecosystems. Through this technology, we can promote seamless collaboration between different ecosystems, thereby driving the healthy development of the entire industry.
State Management
Exploring Supra's MultiVM design, we find that it cleverly manages the states between different virtual machines (VMs). States are carefully partitioned and stored in segments of the tribes and clans of Supra nodes. The current state of each virtual machine is meticulously maintained by nodes in a Merkleized state tree or its subtree. This design not only simplifies the process of cross-VM calls but also avoids the computational burden of handling the entire VM state through state proofs.
Through this partitioning strategy of states, Supra is able to independently operate each virtual machine, effectively avoiding unnecessary interference between transactions. Additionally, it allows multiple virtual machines to operate in parallel, thereby enhancing overall operational efficiency.
Sufficiently Atomic Execution
In the general composability between virtual machines (VMs), applications can seamlessly interact and make function calls across different VMs as if they coexisted within the same VM. However, this idealized design may pose optimization challenges in resource allocation, thereby affecting the experience of developers and users. To address this issue, Supra adopts a MultiVM strategy that employs an atomic cross-VM execution method, allowing for smooth asset transfers.
Let's understand how this strategy works through a specific scenario:
Suppose Alice wants to transfer $100 worth of USDC from her Ethereum virtual machine (EVM) account to Bob's Move virtual machine (Move VM) account. The first step of the transaction is explicit: Alice's account will decrease by $100 worth of USDC (step T1), and the pending transfer to Bob's Move VM will be recorded. The second step of the transaction (step T2) is implicit and will be executed in a deterministic environment, such as at the end of a block. This means that the credit transaction to Bob's account will not be initiated and executed through the memory pool. Instead, the pending transfer will be triggered when specific conditions are met, such as after step T1 is completed or at a scheduled time. Once the conditions are met, the Supra node running the Move VM will directly execute the second step of the transaction and update the state without going through the memory pool.
In the Supra architecture of tribes and clans, MultiVM nodes do not need to bear the responsibility of running all virtual machines (VMs) or maintaining their entire states. MultiVM nodes can be divided into smaller clan networks, with each clan network responsible for running specific VMs, enabling parallel processing and execution of transactions. This sharded execution strategy requires 51% consensus, allowing transactions for different VMs to be processed simultaneously rather than in a single sequential order, effectively reducing the latency of smart contract execution.
Execution Sharding
Furthermore, the execution sharding method promotes horizontal scalability by dispersing virtual machines across different clans. MultiVM nodes can also adopt a vertical scaling strategy, running multiple VMs within a single clan. Nodes within a clan can monitor transaction traffic for each VM and dynamically optimize hardware resources based on the traffic, ensuring the rational allocation of computing resources. When the transaction volume of a particular VM significantly exceeds that of other VMs, nodes can dynamically adjust their computing resources to adapt to the traffic changes. In cases of sustained growth in the transaction volume of a VM, the execution sharding strategy can facilitate its migration to the corresponding clan, enhancing efficiency.
MultiVM will initially consist of a series of independent virtual machines, each equipped with its own database. To achieve efficient resource management, a carefully designed and efficient resource allocation mechanism is needed. Additionally, communication between virtual machines is not straightforward, involving the handling of different constraints during VM execution and the issue of finality time in specific network environments. The Supra project is dedicated to developing a more efficient database layer that can comprehensively consider and serve the needs of multiple virtual machines. Now that we have gained a preliminary understanding of the core functions of MultiVM, let's explore how Supra's automated network cleverly leverages these functions to enhance overall performance and efficiency.
Supra Automated Network
In the discussion of the DORA oracle section, we learned that smart contracts cannot independently access external data and rely on price information provided by oracles for their triggering and execution. However, the triggering conditions of smart contracts are not limited to price data; they can also be based on other types of data, such as time, or implemented through combined triggers, for example, triggering when the price of asset X rises and the price of asset Y falls within a specific block time.
Currently, solutions such as Chainlink, Clockworks, and Gelato run network nodes to record automated requests and continuously monitor Ethereum, Solana, and other blockchain networks for relevant transaction activities. Additionally, Supra has also introduced its smart contract automation service - the Platinum Automation Network (PAN). Leveraging multiple integrated services of Supra, including oracles, verifiable random functions (VRF), and cross-chain bridges, PAN can directly access blockchain states, obtain oracle data, and facilitate cross-chain communication. This direct data and communication access enables PAN to provide more efficient on-chain functionality without relying on middleware services protected by third-party trust.
Let's explore the mystery of how PAN cleverly handles automated requests. Imagine that Alice has a specific investment strategy: she plans to convert 100 tokens of X into 50 tokens of Y if the market price of token Z falls below 0.5 in 15 days. This strategic transaction is first registered on nodes providing automated services. The Supra platform carefully records these conditions in its automation registry, allowing decentralized applications (dApps) using its automation services to register automated requests for users on this contract.
Subsequently, Supra nodes closely monitor transaction dynamics on the blockchain, continuously evaluating whether Alice's set conditions are met in real-time. Once the market conditions align with Alice's expectations - i.e., the price of token Z does indeed fall below 0.5 in 15 days - Supra seamlessly executes the transaction automatically, converting 100 tokens of X into 50 tokens of Y without direct intervention from Alice.
What's even more commendable is that even if Alice's X tokens are on the Ethereum network and the Y tokens are on the Sui network, Platinum Automation can still smoothly execute this cross-chain transaction. This is made possible by the deep utilization of PAN for Supra's cross-chain solutions, especially the application of Hypernova and HyperLoop technologies, which provide strong support for token exchanges between different blockchains for Alice. Through this innovative cross-chain interaction, PAN not only enhances transaction flexibility but also greatly improves the investment experience for users.
IntraLayer: Vertically Integrating All Supra Functions
The vision of building the Supra blockchain stack aims to address the fragmentation of liquidity between different L1 and L2 levels. This goal will be achieved through the one-time deployment of smart contracts, enabling cross-chain operations while maintaining compatibility with traditional chains. Next, we will delve into the unique advantages of each technical component and how they work together to promote the realization of Supra's IntraLayer, ensuring efficient collaboration among Supra's various components.
The services provided by Supra, including oracles, verifiable random functions (VRF), and bridges, can all run on a node cluster supported by the Moonshot consensus mechanism. These nodes can asynchronously facilitate collaboration between different components, effectively reducing latency and computational costs.
The excellence of Supra's services lies in its flexibility in message propagation time, being able to adapt to the block generation cycle of the target blockchain. This feature demonstrates its efficiency in asynchronous blockchain environments, such as Sui. Additionally, Supra's adaptability is equally noteworthy, as it can seamlessly integrate with partially synchronous blockchains, such as Aptos. In these blockchain systems, although message propagation is guaranteed within a scheduled time, occasional delays may occur, and Supra can flexibly adapt to them.
Through the use of DVRF technology by Supra, nodes are randomly selected and rearranged to serve the core of the DORA Oracle Network, HyperNova, HyperLoop, VRF, and consensus protocols. The application of the DKG (distributed key generation) protocol enables the frequent reorganization and randomization of these network nodes, thereby enhancing the security and reliability of the entire system.
The randomization and selection mechanism of nodes effectively prevent collusion among oracle nodes while ensuring that different nodes handle different price data sets at different times. This design not only promotes the activity of the oracle network but also achieves continuous and frequent updates of price information. The Moonshot consensus mechanism adopted by SupraChain, coupled with its optimistic execution strategy, enables oracles to efficiently collect, integrate, and publish price information, significantly improving processing speed and reducing update latency. In an advanced version of the DORA protocol, an option will be provided to directly push data to smart contracts, further shortening processing time.
HyperNova performs well in L1 to L1 communication, mainly due to its inheritance of security from the underlying L1. Meanwhile, HyperLoop is more suitable for communication needs between L2 to L2. SupraChain and its Moonshot consensus protocol are compatible with both communication protocols. Considering the complexity of future multi-chain environments, Supra nodes need to run complete clients for over 20 L1/L2, undoubtedly posing a challenge to the performance of the nodes.
As Supra integrates numerous infrastructure services into one, it is committed to providing automated solutions for smart contracts. This solution relies on its technical architecture, including oracles, verifiable random functions (VRF), and cross-chain bridges, all of which run on unified nodes. Because these nodes can execute automated tasks and the triggering mechanism is based on price information from oracles, it effectively reduces latency and avoids the need to individually schedule transactions from the memory pool to execute tasks.
Thanks to Supra's vertically integrated technology stack, cross-chain automation is achieved. Supra's automated network can submit cross-chain transactions to the target blockchain and verify proofs on SupraChain through HyperNova. Smart contracts deployed on the target chain are responsible for verifying these proofs and executing cross-chain logic based on them. The single-trigger mechanism adopted by Supra allows a single transaction initiated on the source chain to trigger and complete all subsequent operations on the target chain, providing a seamless experience for users. These subsequent operations can include asset conversion, scheduled task execution, decision-making using verifiable random functions, and even invoking services on multiple other blockchains.
Multi-VM adopts Supra's tribal clan architecture, implementing execution sharding, allowing multiple virtual machines to run in parallel, even though they are not fully compatible. HyperNova and HyperLoop technologies, based on the Multi-VM architecture, support cross-chain asset transfers, covering both L1 and L2 layers. Additionally, Multi-VM obtains real-time price data through the push and pull mechanism of the DORA oracle and provides private and verifiable random functions for smart contracts running on Multi-VM.
With the assistance of HyperNova and HyperLoop, the Platinum Automation Network can efficiently manage various automation requests, including cross-chain operations.
It is worth noting that all Supra services run and distribute on equity-supported nodes. While some nodes may run multiple Supra services, not all nodes do. These nodes are divided into tribes and clans, operating based on the Moonshot consensus mechanism, requiring at least 67% of nodes to remain honest in a tribe, and services running in a clan require honesty from over half of the 51% nodes. There can be clans dedicated to the DORA oracle, as well as clans dedicated to VRF or bridges. In the context of Multi-VM, each dedicated clan can independently run a virtual machine. As the number of clans increases, the size of the tribe also expands, which may affect the speed of reaching Moonshot consensus. Additionally, since multiple Supra components run on each node, the hardware requirements for the nodes are correspondingly increased.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
