Abstract

---

Supra integrates multiple innovative achievements from recent years into a powerful and high-performance architecture that fully vertically integrates MultiVM smart contract support and native services, including price oracles, on-chain randomness, cross-chain communication, and automation features.

On this basis, this article details the end-to-end transaction process of the Supra blockchain and demonstrates how to effectively mitigate the threats of censorship risk and maximum extractable value (MEV) attacks.

The Supra network relies on a shared security platform to provide a wide range of services and functionalities. These include innovative technologies: Distributed Oracle Protocol (DORA), Distributed Verifiable Random Function (DVRF), zero-block delay automation network, AppChain-inspired container architecture, multi-VM support, and block execution optimized through parallel transaction processing. Additionally, Supra's cross-chain design—HyperLoop and HyperNova—makes Supra the world's first "IntraLayer" that achieves multi-chain interconnectivity through smart contract platform logic.

1. Native Fully Vertical Integration of Blockchain Services

Supra is committed to driving blockchain technology transformation through pioneering research and exceptional engineering capabilities, aiming to build an efficient Layer 1 blockchain that fully integrates various blockchain-related services, providing integrated solutions and a seamless user experience for individual users, institutional clients, and developers.

In this article, we will demonstrate how Supra technology interprets the famous quote by the ancient Greek philosopher Aristotle: "The whole is greater than the sum of its parts." Upholding the concept of complete vertical integration, Supra offers a comprehensive set of blockchain functionalities and services that support rich ecosystem development and diverse application scenarios.

Overview of Core Functions

The native services provided by the Supra blockchain for dApps (as shown in Figure 1) cover the following core functions:

• Layer 1 Blockchain

• Supports various asset types, including native tokens, programmable fungible and non-fungible tokens, and standardized cross-chain tokens.

• Smart Contract Execution Environment

• Provides multiple on-chain Turing-complete smart contract platforms suitable for various public blockchain applications such as DeFi protocols, blockchain games, lotteries, and supply chain tracking.

• Off-chain Data Services

• Offers demand-based (pull) and streaming (push) data services, including cryptocurrency price oracles, foreign exchange rates, stock indices, and weather data. This data is transmitted through Supra's Distributed Oracle Protocol (DORA), serving not only the Supra blockchain but also supporting other blockchain networks.

Figure 1 Complete Vertical Integration

• Push and Pull On-chain Randomness Services
  Provides streaming and on-demand formats of Distributed Verifiable Random Functions (dVRF), suitable for Web 2.0 and Web 3.0 users for generating and distributing random number services.

• Automation Network
  Used to schedule transaction execution based on specific time points, on-chain events, or off-chain events provided by DORA. For example, a client might request: "On June 1, 2025, at 12:00 PM Eastern Standard Time, if the ETH price is above $4000, sell my DOGE."

• Application-Specific Chains (AppChain)
  The containers on Supra provide the flexibility and autonomy of AppChains while significantly reducing deployment costs and benefiting from the high performance, shared security, and unified liquidity of the Supra network.

2. IntraLayer: Connecting Supra and Other Blockchains

Although Supra offers a range of native services, we deeply recognize the reality and value of a multi-chain ecosystem. To enhance interoperability, we designed a star topology (see Figure 2), in which the Supra L1 blockchain and its integrated services serve as the core of the IntraLayer network, connecting other L1 and L2 blockchains through our interoperability solutions HyperLoop and HyperNova.

As an independent MultiVM smart contract platform, Supra not only provides its own services but also aims to play a key role in the multi-chain ecosystem. This role is reflected in the value exchange between networks or "within networks," achieving secure and efficient communication through native smart contracts, automation features, and oracle services.

HyperLoop

Based on traditional multi-signature cross-chain protocols, HyperLoop is a security solution that has been rigorously analyzed and game-theoretically validated, being the industry's first such innovative design that ensures the reliability of cross-chain transactions.

HyperNova

As a trustless interoperability solution, HyperNova provides high security for cross-chain communication, laying a solid foundation for the exchange of information and value in the multi-chain ecosystem.

Through HyperLoop and HyperNova, Supra achieves extensive interconnectivity between chains, providing users and developers with powerful tools that promote the deep integration and development of the multi-chain ecosystem.

Figure 2 Supra’s IntraLayer

The security of connecting chains does not rely on traditional cross-chain or relay node security assumptions. Here we outline the specific scenarios where HyperLoop and HyperNova are most applicable.

• HyperLoop
  We find that the HyperLoop cross-chain solution is particularly suitable for connecting Optimistic Rollups to Supra, as it eliminates the challenge period for fraud proofs required to achieve finality.

• HyperNova
  Suitable for connecting any Proof of Stake (PoS) L1 blockchain to Supra, as it maintains the security of the connecting chain by recalculating the consensus of the Supra interchain, thus preserving L1 to L1 security. Supra's L1 blockchain is specifically designed to facilitate secure and efficient cross-chain communication.

Our plans include using HyperNova to cross-chain Bitcoin to Supra while achieving a reverse connection through HyperLoop. Additionally, we are exploring how to implement atomic swaps in this environment to further enhance cross-chain interoperability.

Here are some core functionalities supported by the Supra IntraLayer technology stack:

• DeFi IntraLayer
  As a "platform on top of a platform," Supra encapsulates various mainstream DeFi protocols (e.g., AMM). dApp developers can easily access assets and information from multiple blockchains, simplifying the cross-chain development process.

• Cross-chain Automation Services
  We allow users to set up automated tasks based on events and data from multiple blockchains, greatly enhancing user experience and operational efficiency.

We firmly believe that fully vertically integrating various native services into a high-performance L1 blockchain aligns closely with our vision of building the world's first cross-chain IntraLayer. As the demand for our services from other blockchains continues to grow, the utility of the Supra network (including our tokens and on-chain assets) will bring about natural fluctuations in value, further incentivizing users and clients to adopt our infrastructure.

At the same time, as the IntraLayer architecture is widely applied across different ecosystems, more and more developers will be attracted by our native services and exceptional performance, leading them to choose to develop and build applications directly on the Supra blockchain. This will not only enhance our DeFi layer, including our internally developed protocols and third-party protocols, but also drive the overall adoption and attractiveness of the network.

We believe that with outstanding performance and a one-stop, diversified service, Supra will bring the next wave of Web 3.0 technology proliferation to the developer community, facilitating the rapid development of the entire ecosystem.

3. The Core of Supra—"Tribe and Clan" Node Model

The fundamental philosophy of Supra is complete vertical integration, providing almost all blockchain-related services on a single platform. This approach ensures that users and developers receive a unified and seamless experience.

Complete Vertical Integration vs. Modular Layer 2

Supra adopts a vertically integrated architecture, unlike traditional modular L2 solutions:

In L2, core functionalities (such as consensus, execution, and data availability) are dispersed across independent networks. Although this design is referred to as "modular advantages," it brings several issues:

• Increased Latency: Cross-network communication leads to time delays;

• Economic Security Dispersion: Different networks have their own tokens, unable to share security;

• High Complexity: The overall architecture is more difficult to maintain and coordinate.

In contrast, Supra's complete vertical integration design unifies all components into a single blockchain:

• Shared economic security and unified token economics;

• Significantly reduced communication latency, enhancing system performance;

• A unified incentive mechanism enhances network security;

• Reduced overall operational costs.

Breakthrough in Byzantine Fault Tolerance

Research in distributed systems shows that in asynchronous or partially synchronous networks, traditional Byzantine Fault Tolerance (BFT) protocols can only tolerate up to one-third of nodes being malicious. However, Supra's innovative breakthrough raises this tolerance to half, achieving unprecedented security and efficiency.

Ordering Service and Integrity Chain

The core of the Supra L1 blockchain is the ordering service, whose consensus protocol is responsible for transaction ordering, while the propagation of transaction data is separated from the ordering service. Therefore:

• Blocks only contain metadata of transaction batches (such as summaries and data availability proofs), without including specific transaction data;

• This makes the blocks of the Supra blockchain very small, greatly enhancing operational efficiency.

Since the ordering service is the core foundation of all other services, we refer to the Supra blockchain as “Integrity Chain.”

Why is Tolerating More Byzantine Nodes Important?

The direct advantages of tolerating more Byzantine nodes include:

• Smaller committees: For example, tolerating 50 malicious nodes would require 151 members using traditional methods, while Supra only needs 101 members;

• Reduced costs: Fewer consensus nodes mean fewer nodes that need to be compensated, thereby lowering user fees;

• Increased execution speed: With fewer consensus nodes, the process is faster while still maintaining strong security.

Figure 3 Tribes, Clans, and Families

Tribes, Clans, and Families

This core facilitates the efficient complete vertical integration of multiple services on the Supra blockchain. Supra proposes a new network framework that supports the execution of various algorithms at the tribe, clan, or family level.

As shown in Figure 3:

• Tribe is a node committee that tolerates up to one-third of Byzantine nodes;

• Clan is a node committee that tolerates up to one-half of Byzantine nodes;

• Family is a node committee that requires at least one correct node.

To achieve optimal performance and strong security, our network architecture is as follows: active nodes are organized into a tribe that runs the consensus protocol to support the ordering service and tolerates up to one-third of Byzantine nodes.

A key point in our design is that the entire Supra tribe does not need to participate in transaction execution or maintain the complete Supra state. Instead, a smaller subset—referred to as the "clan"—can manage the state, execute transactions, compute the post-state of blocks, and sign state commitments. Therefore, the propagation of transaction data initially occurs only at the clan level before being further broadcasted.

This architecture is well-suited for efficient state sharding, where different clans manage different state shards and may use independent virtual machines. This design enhances scalability, allowing us to adjust throughput by adding more clans (or shards). Thus, all protocols outside of consensus (such as data propagation, shard execution, oracle services, and distributed randomness services) run in small committees (clans) that only require a simple majority of correct nodes.

We assign nodes to clans through random selection, organizing the ordering tribe and multiple service clans together, making these clans effectively form a partition of the tribe. Consensus or global ordering runs on the tribe, while various verifiable computational services are executed within the clans. This random selection of nodes allows us to execute at the clan level and introduces a probabilistic factor into the system. For example, suppose the tribe consists of 625 nodes, with at most 208 Byzantine nodes. If the tribe is divided into 5 clans, each with 125 nodes, the probability of having more than half (i.e., 62) nodes in any clan being Byzantine is approximately 35 × 10⁻⁶. In other words, when Byzantine nodes constitute 33% of the tribe, the probability of encountering a "bad clan" is only 35 in a million. In practice, these probabilities are extremely low. We will further analyze these probabilities when discussing cycles and time periods, demonstrating that they are virtually negligible in practice.

4. Transaction Process

The transaction process on the Supra chain is roughly as follows, with specific steps detailed in subsequent sections:

Figure 4 Illustrates the End-to-End Transaction Process in the Supra Blockchain

• Users submit transaction ttt through Supra's Starkey wallet [3] or dApp. The wallet connects to the gateway RPC node, and transaction ttt is sent to that node.

• The gateway RPC node sends transaction ttt to the primary bucket of a specific batch proposer after performing basic validation and classification.

• The batch proposer packages transactions from the primary bucket and includes timed-out transactions from the secondary bucket. For details, see Section 5.

• The batch is propagated to the corresponding execution clan nodes via the xRBC protocol, and the batch must form a Data Availability Arbitration Certificate (DAQC) before it can be included in a block. These certificates are propagated throughout the tribe, and the batch is also propagated to the gateway RPC node.

• Tribe nodes run Supra's Moonshot consensus protocol. The block proposer constructs a block by packaging these DAQCs and the metadata of the related batches.

• The consensus protocol orders the block, thereby indirectly ordering transactions across batches. When the block is finalized, all tribe nodes running the consensus protocol and all clan nodes can see these blocks. The finalized block is also propagated to the gateway RPC node.

• Clan nodes execute the transactions of the corresponding batches from the finalized block and update the blockchain state at the current blockchain end. They then compute the post-state, perform Merkle operations, and calculate the new Merkle root. Note that different clans execute different batches in parallel. Clan nodes sign the Merkle root and propagate it throughout the tribe and to the gateway RPC node.

• The gateway RPC node executes the block, computes the post-state and its Merkle root, verifies its consistency with the received signed Merkle root, and notifies the wallet upon transaction completion.

Final Confirmation Stages

In our workflow, transaction ttt undergoes the following three different finality stages, each providing stronger guarantees for the transaction's status on the blockchain:

• Pre-confirmation Stage
  When the batch bbb containing transaction ttt obtains a Data Availability Arbitration Certificate (DAQC), it guarantees that transaction ttt will be included in the blockchain. At this stage, while the inclusion of the transaction is guaranteed, its specific position and execution result have yet to be determined.

• Ordering Finality
  When the consensus protocol completes the final confirmation of the block containing batch bbb, the position of transaction ttt in the blockchain becomes fixed and unchangeable, thereby determining its execution order relative to other transactions.

• Execution Finality
  This is the endpoint of the finality stages. Clan nodes execute batch bbb, update the blockchain state with the execution result of transaction ttt, create a Merkleized version of the new state, sign the generated Merkle root, and broadcast it to form a state commitment. Once this stage is completed, the execution result of the transaction is final and irreversible.

Supra L1 supports rapid finality times. In our experiments, the observation times for these different finality stages will be reported in Section 7.

Subsequent sections will elaborate on the important steps in the transaction process outlined above.

Figure 5 Bucket Scheme Without Mempool

5. Bucket Scheme Without Mempool

We first discuss the existing mempool protocols of Ethereum and Solana, then demonstrate how Supra improves upon this foundation.

Ethereum Mempool Scheme

The traditional Ethereum mempool protocol process is as follows:

• The client (wallet) sends a transaction to the RPC node, which broadcasts the transaction to all consensus validators via the Gossip protocol.

• When a validator becomes a block proposer, it attempts to package the received transactions.

• The block proposer may attempt to censor by not including transactions in the block, but since all consensus validators hold these transactions, the next validator to become a block proposer will include the omitted or censored transactions. Therefore, this protocol has anti-censorship properties.

In a typical blockchain architecture, the client (Web3 wallet) sends transactions to a public RPC node. The RPC node then propagates the transaction throughout the RPC node network and the consensus validator network via a peer-to-peer Gossip protocol. These nodes maintain a data structure known as a "mempool" to temporarily store transactions sent by clients.

Next, block builders extract transactions from the mempool, package them into blocks, and process them through the consensus protocol. Once the block reaches finality, all included transactions are also considered finalized.

Due to the backlog of unprocessed transactions in the mempool of Bitcoin and Ethereum, on average, transactions remain in the mempool for a long time before being selected by block builders. Additionally, the peer-to-peer Gossip protocol further increases latency when propagating transactions.

Solana No Mempool Scheme

To reduce mempool latency, Solana adopts a no-mempool protocol, which proceeds as follows:

• Block generation occurs according to a fixed schedule, and the block proposer is determined in advance.

• The client (such as a wallet) sends transactions to the RPC node, which attaches auxiliary data such as read/write access information to the transaction and sends it to some proposers of the upcoming block. If a proposer misses the transaction, other proposers will include it in subsequent blocks.

It is important to note that the Solana network requires 32 block confirmations to achieve complete finality. Although Solana is designed to optimize end-to-end latency, transaction duplication issues still occasionally occur, which may lead to network interruptions. Compared to Ethereum's mempool protocol, Solana employs targeted communication for expected block proposers, effectively reducing transaction propagation latency.

Supra No Mempool Protocol Scheme

Similar to Solana, Supra also adopts a no-mempool protocol, but we replace the traditional network-wide Gossip protocol with targeted communication. However, Supra's approach differs in two key aspects:

1. Instant Finality

Unlike Solana's time-slot-based system, Supra uses a classic Byzantine Fault Tolerance (BFT) PBFT-style consensus protocol called Moonshot (detailed later). In the Moonshot protocol, instant finality is achieved when a block receives a Commit Arbitration Certificate (QC), without needing to wait for 32 block confirmations as in Solana. This significantly shortens the final confirmation time for transactions and enhances system performance.

2. Batch Metadata Storage

In Supra's consensus design, transaction data is not directly included in the block; instead, the DAQC and metadata of transaction batches are stored (see Section 6). In our no-mempool protocol, transactions from client wallets are placed into buckets managed by designated batch proposers, as shown in Figure 5.

Our bucket scheme features the following:

**1) Deduplication Mechanism
**A unique primary batch proposer is assigned to each transaction, responsible for including the transaction in a batch. This single-responsibility model naturally avoids duplicate transactions being packaged into the blockchain.

**2) Redundancy and Anti-Censorship
**To ensure that transactions are not missed, we introduce secondary batch proposers as backups. If the primary batch proposer fails to include the transaction in a timely manner, the secondary batch proposer will include the transaction in the batch after a timeout.

• Although multiple secondary proposers processing transactions simultaneously may lead to duplicate packaging, the Supra system maintains consistency through the first appearance of the transaction.

• Duplicate transactions will be automatically aborted during the execution phase due to invalid transaction sequence numbers, without affecting the on-chain state.

**3) Immutable Responsibility Record
**If a secondary proposer successfully includes a transaction in a block, it will generate an immutable record proving that the primary proposer failed to fulfill its duty. This record can be used for subsequent network analysis to penalize batch proposers who censor transactions or cause unnecessary delays, ensuring fairness and reliability in the system.

The specific process of the no-mempool bucket scheme is as follows:

• Each batch proposer maintains two buckets: a primary bucket and a secondary bucket.

• For each transaction ttt, based on its unique and unpredictable identifier (hash), the system assigns it to a specific batch proposer family. Within that family, one node is designated as the primary batch proposer for transaction ttt, while the remaining nodes serve as secondary batch proposers.

• When the RPC node receives transaction ttt from the wallet or dApp frontend, it forwards it to the corresponding batch proposer family based on the transaction's identifier. The primary batch proposer stores transaction ttt in its primary bucket, while the secondary batch proposers store transaction ttt in their respective secondary buckets.

• When constructing a new batch, the batch proposer must include all transactions from its primary bucket. To guard against Byzantine behavior (e.g., censoring specific transactions by excluding them from the primary bucket), secondary batch proposers act as a backup mechanism.

• Once the batch is finalized and observed by the batch proposer, the proposer will remove the transactions included in the batch from both its primary and secondary buckets.

• Additionally, each transaction ttt has a configurable timeout. If ttt is not included in a finalized batch before the timeout, the secondary batch proposers in its family must include ttt from their secondary buckets when constructing the next batch. This mechanism ensures that transactions are not missed and enhances the system's resistance to censorship.

Figure 6 Conceptual Comparison with Existing Solutions

This dual-layer design strikes a clever balance between efficient deduplication and strong anti-censorship capabilities. Furthermore, when a secondary batch proposer successfully includes a transaction in a batch, it generates an immutable record proving that the primary proposer failed to fulfill its duty. This record can be used for subsequent analysis and to impose penalties on batch proposers who censor transactions or cause unnecessary delays.

6. No Mempool Architecture: Achieving Efficient Decoupling of Transaction Data Propagation and Transaction Ordering

Next, we introduce how Supra achieves efficient decoupling of transaction data propagation and transaction ordering through the tribe-clan architecture.

In recent years, some protocols (such as Narwhal/Tusk [11] and Bullshark [20]) have recognized the importance of transaction data transmission and adopted a new design paradigm that decouples data transmission from transaction ordering. This design implements data transmission and ordering through two parallel-running sub-protocols:

• In the absence of ordering requirements, data transmission simplifies to Reliable Broadcast (RBC), a widely studied foundational operation in distributed systems.

• Specifically, nodes continuously propose and propagate new data blocks through the RBC sub-protocol; subsequently, these data blocks are determined and output through the ordering sub-protocol.

This design effectively optimizes the utilization of bandwidth resources, significantly improving system throughput compared to traditional methods. Supra also follows this principle, decoupling data transmission from transaction ordering. However, we observe that even in the current state-of-the-art consensus protocols, the optimization focus remains primarily on the ordering sub-protocol, which contradicts the actual bottleneck of the system.

For example, the main advantages of Tusk [11] and Bullshark [20] are the so-called zero-message ordering, which completely eliminates communication overhead during the ordering phase. But as we pointed out earlier, the main source of communication costs is not ordering but data transmission.

Figure 6 compares our approach with existing solutions. Our goal is to reduce the transmission volume per node during the data transmission phase, particularly to minimize the maximum transmission load of any single node. In practical applications, network bandwidth is often the primary limiting factor for system throughput. Therefore, by optimizing the data transmission process, we can further enhance the overall performance and efficiency of the system.

Supra's xRBC Protocol

We significantly reduce the communication costs of data transmission through the following innovations: adopting an independent ordering service operated by the same set of nodes.

In traditional methods, data transmission is typically executed through the Reliable Broadcast (RBC) protocol. RBC requires more than 2/3 of honest nodes in the system to prevent the broadcaster from sending different data batches to different nodes (i.e., the sender ambiguity problem).

However, we found that we could utilize an independent ordering service to improve data transmission into a relaxed RBC operation called xRBC. In xRBC, only more than 1/2 of honest nodes are needed to complete data transmission, significantly reducing communication costs.

Advantages of xRBC Design

In xRBC, relying solely on participating nodes is insufficient to completely prevent sender ambiguity. To address this issue, the ordering service authenticates the batches of the broadcaster, ensuring consensus among honest nodes and eliminating discrepancies. Although the ordering service still requires a supermajority (more than 2/3 of honest nodes) for assurance, xRBC has significant advantages over traditional RBC in the following aspects:

• Lower communication overhead: By reducing reliance on a supermajority of honest nodes, the communication complexity of the protocol operation is lowered.

• Enhanced performance: The design of xRBC can handle data transmission more efficiently while maintaining security comparable to traditional RBC.

Utilizing Clan Distributed Data Propagation

Since transactions are executed only within clans (random subcommittees of the tribe), transaction data initially only needs to be transmitted to the nodes executing that clan. This greatly reduces the network bandwidth load and is more efficient than propagating data to the entire tribe. Within each executing clan, we designate a portion of nodes as batch proposers, responsible for constructing transaction batches from their respective buckets and transmitting them to all nodes within the clan.

It is worth mentioning that batch proposers from different clans can independently and in parallel propagate transaction batches without needing to synchronize or wait for protocol steps. This parallel asynchronous propagation mechanism maximizes the utilization efficiency of network bandwidth when pushing data.

Additionally, to achieve state synchronization (for node reassignment across cycles, see Section 9), transaction data may be further propagated to the entire tribe in subsequent stages. This phased data propagation design ensures network performance while also maintaining system consistency and flexibility.

Figure 7 xRBC Protocol

Specific Process (as illustrated in Figure 7)

• Batch proposers are responsible for constructing transaction batches and sending them to all nodes within the clan.

• When clan nodes receive valid batches, they vote on the data availability of the batches and broadcast the voting results to all nodes within the clan, other nodes in the tribe, and the designated gateway RPC node.

• Once a simple majority vote is passed, the system generates a Data Availability Certificate (DAQC), ensuring that at least one honest node possesses the complete transaction data.

• If a node is missing part of the batch data, it can request data from a simple majority of clan nodes, and the DAQC guarantees that this request will be fulfilled.

• For batches exceeding size thresholds, or when not all clan nodes serve as batch proposers, we introduce erasure coding to ensure uniform distribution of data within the clan, optimizing bandwidth usage efficiency.

Block Content and Finality

Blocks only contain batch certificates. When the consensus protocol validators (tribe nodes) serve as block proposers, they will package all received DAQCs of the batches into the block. Once the block reaches finality and is confirmed by the validators, the validators will remove these included DAQCs from the cache, as they have been recorded in the finalized block and no longer need to be retained.

Since blocks only contain batch certificates and do not directly store transaction data, the Supra blockchain is, in fact, a highly lightweight blockchain. This design significantly reduces the size of blocks and improves data transmission efficiency.

7. Consensus Protocol

Byzantine Fault Tolerance (BFT) Consensus Protocol: The Core of Blockchain

The BFT consensus protocol is a core component of the blockchain, responsible for providing standard ordering for blocks, thereby ensuring that transactions within the block also have a standard order. We have innovatively designed a new type of BFT consensus protocol called Moonshot SMR, inspired by the classic Practical Byzantine Fault Tolerance (PBFT) protocol, and optimized for performance.

As mentioned earlier, the consensus protocol operates within the tribe, while transaction execution is limited to the clan. Therefore, Moonshot adopts a flexible design that can adapt to actual transaction throughput demands. Notably, blocks do not directly contain transaction data; they only include batch certificates, making the system more efficient and lightweight.

Performance of Moonshot

Moonshot achieves the following key performance metrics:

• Continuous proposal delay (minimum delay between two block proposals): 1 message delay (md).

• Submission delay: 3 md.

• Cumulative delay for batch propagation and data availability certificate generation: 2 md.

• Since blocks are proposed at each network hop, data availability certificates need to queue for the next block proposal, with an average queue delay of 0.5 md.

Therefore, the overall end-to-end delay of the system is 5.5 md.

Formal Verification: Ensuring Protocol Security

Distributed protocols often exhibit complex behaviors and infinite state spaces, making it extremely challenging to prove their correctness. Formal verification is the gold standard for ensuring protocol security, as it can mathematically prove that the protocol is free from errors.

To this end, we employed Microsoft's IvY verifier to formally verify the security properties of the Moonshot consensus protocol, rigorously proving its non-forking characteristics and providing mathematical assurance of the protocol's correctness and security.

Experimental Evaluation

We conducted extensive evaluations on Google Cloud Platform (GCP), evenly distributing nodes across five different regions:

• us-east1-b (South Carolina)

• us-west1-a (Oregon)

• europe-north1-a (Hamina, Finland)

• asia-northeast1-a (Tokyo)

• australia-southeast1-a (Sydney)

The experimental setup is as follows:

• Clients co-located with consensus nodes

• Each transaction consists of 512 bytes of random data, with a batch size set to 500KB

• Each experiment runs for 180 seconds

• Delay measurement: Calculate the average time from transaction generation to submission by all non-faulty nodes to determine end-to-end delay

• Throughput measurement: Evaluated based on the number of transactions finalized per second

The architecture we tested consists of 300 nodes divided into 5 clans, with each clan containing 60 nodes (12 nodes deployed in each GCP region). In this configuration, the probability of a clan (60 nodes) failing due to an internal dishonest majority in the 300-node network is 0.0107.

Nevertheless, our goal is not only to demonstrate the high performance of this architecture but also to prove that it can maintain high throughput and low latency even in larger-scale systems.

Hardware Configuration:

• We used e2-standard-32 machines, each equipped with 32 vCPUs, 128 GB of memory, and an outbound bandwidth of up to 16 Gbps.

Through these experiments, we validated the strong capabilities of the Supra architecture in terms of performance and scalability.

Figure 8 Throughput vs. End-to-End Delay

We observed the relationship between the system's throughput and end-to-end delay, as shown in Figure 8:

• When throughput reaches 500,000 TPS, the end-to-end delay remains under 1 second.

• At 300,000 TPS, the delay is approximately 650 milliseconds, which is close to the theoretical limit of our architectural design.

Additionally, we measured the Data Availability Certificate (DAQC) generation time, which is about 160 milliseconds.

In summary:

• The pre-confirmation delay for transactions is approximately 160 milliseconds;

• The ordering finality delay is less than 1 second.

DAG Consensus Protocol

Inspired by the research on DAG (Directed Acyclic Graph) consensus protocols, we designed a brand-new DAG consensus protocol called Sailfish. This protocol optimizes submission delay to 1 reliable broadcast + 1 message delay (md) without sacrificing system throughput, surpassing the performance of current state-of-the-art DAG consensus protocols.

Furthermore, we developed a variant of Sailfish that combines it with the tribe-clan architecture to further enhance system throughput. We are currently conducting extensive experimental testing on this design. If Sailfish performs better than the existing Moonshot protocol in large-scale network environments, we plan to switch the core consensus protocol to Sailfish for a more efficient consensus process.

Figure 9 Supra's Parallel Execution Method

8. Execution

The current state of the blockchain contains all assets and their ownership information, as well as the latest data of all smart contracts. When executing finalized block transactions, the relevant state portions need to be loaded, the state updated in the order of transactions within the block, and the modified state persisted.

In modern blockchains, as transaction processing capabilities continue to improve, execution time has become a significant factor in the end-to-end delay of transaction final confirmation. This trend is particularly evident in chains like Solana, Sui, Aptos, and Monad, which effectively reduce latency through parallel execution.

Our tribe-clan architecture also implements parallel execution of transactions, but optimizes it at the network level. Specifically, transaction execution is limited to within clans, with different clans processing their respective transaction batches in parallel, significantly enhancing the system's execution efficiency (see Figure 9).

8.1 Parallel Execution of Transactions

In addition to achieving parallelism at the network level, we also explored how to efficiently execute transactions in parallel by fully utilizing multi-core processors within a single node. The common parallel execution methods in the literature and industry can be broadly categorized into two types:

• Optimistic/speculative execution techniques

• Pre-determined techniques based on deterministic dependencies

Software Transactional Memory (STM)

STM technology is widely used in traditional computing for parallel execution of multi-core programs. Aptos's BlockSTM introduces STM technology into blockchain transaction execution, with the core idea being:

• Optimistically execute transactions in parallel on all available cores;

• Subsequently verify whether there are dependency conflicts between transactions;

• If conflicts are found, re-execute the conflicting transactions through a cooperative scheduler.

Supra's Innovative Solution

We propose an innovative STM parallel execution algorithm that, unlike Aptos's BlockSTM, efficiently resolves conflicts without the need for a scheduler. This method is comparable to BlockSTM in terms of performance and architecture, and we are currently conducting in-depth evaluations of this design to verify its advantages in practical applications.

Access Pattern-Based Parallelization

Some blockchains achieve parallelization by specifying the access patterns of transactions:

• Solana's Sealevel requires transactions to explicitly declare the accounts they need to read and write.

• Sui requires transactions to specify the objects to read and write (via object identifiers) and declare whether these objects are exclusive or shared.

• Polygon's approach differs, as block proposers execute blocks using BlockSTM technology, pre-computing the dependencies between transactions and including this dependency information in the block, allowing other validators to execute independent transactions in parallel.

However, it is important to note that whether explicitly declaring access patterns in transactions or including dependency information in blocks significantly increases block size. This may lead to faster saturation of bandwidth, thereby limiting the maximum throughput the system can achieve.

Drawing on these methods, we are developing a deterministic parallel execution algorithm that automatically derives access patterns through static analysis of smart contracts at the time of contract deployment, storing these patterns in the blockchain state without requiring RPC nodes or wallets to explicitly provide access patterns. These patterns allow us to optimize the linear transaction order in finalized blocks into a partial (relaxed) order, enabling independent transactions to be executed in parallel. This approach not only reduces bandwidth consumption but also enhances the overall throughput and efficiency of the system.

Hybrid Approach

We believe that utilizing a hybrid approach that improves the STM algorithm through statically derived access patterns is the ultimate form of optimizing execution techniques (see Figure 9). We are currently conducting a comprehensive evaluation of this design.

8.2 Fairness of Execution Order

To ensure fairness in transaction ordering, we designed a two-step process:

• Initial random ordering: The consensus protocol first generates an initial random seed ordering of transactions.

• Final ordering: The final determined transaction ordering is derived through an on-chain random number protocol generated by BLS threshold signatures based on the block, determining the actual execution order of transactions.

This additional layer of randomization effectively mitigates Maximum Extractable Value (MEV) attacks, as batch proposers or block proposers cannot predict or manipulate the final randomized transaction execution order.

To address the issue of spam transactions, we introduced a local fee market. Under contentious conditions, the cost of transactions will increase exponentially, thereby enhancing the system's resistance to interference while ensuring the efficiency and fairness of transaction ordering.

8.3 Multi-VM

Ethereum introduced the EVM, a Turing-complete on-chain programming environment that greatly unleashed creativity in dApp development, especially providing strong support for DeFi applications. The EVM drew on the experiences of Web 2.0 programming languages, giving rise to Solidity. However, as blockchain technology has evolved, the community has gradually recognized the need for a programming language specifically designed for asset transfer and on-chain asset management. Consequently, Meta's Diem team developed the Move language, which has since spawned variants like Aptos Move and Sui Move.

Supra deeply understands the importance of a customized on-chain transaction programming language, thus choosing the Move language as our preferred choice for our smart contract platform, and we will launch our L1 blockchain with support for Move.

At the same time, we also see the tremendous potential of a multi-VM ecosystem. Developers under different virtual machines can complement each other, jointly driving innovation and development in the blockchain industry. Therefore, we designed an efficient multi-VM architecture.

Based on the natural sharding characteristics of the tribe-clan architecture, each clan hosts a state shard, while different clans can host different virtual machines.

After integrating the Move smart contract platform, Supra will further expand to the Ethereum Virtual Machine (EVM) to achieve compatibility with the vast Ethereum ecosystem. Next, we will integrate the Solana Virtual Machine (SVM), supporting developers to build smart contracts using widely used programming languages such as Rust, C, and C++.

Ultimately, Supra will also support CosmWasm, enabling seamless connection with the active Cosmos ecosystem.

Cross-Virtual Machine Communication

In a multi-VM environment, users may have multiple accounts across different virtual machines and wish to achieve cross-VM asset transfers. Additionally, Supra's native token $SUPRA must be uniformly managed across all virtual machines. To address this issue, we propose a simple and efficient three-step workflow:

• Submit cross-VM transfer transaction
  The user initiates a cross-VM asset transfer transaction ttt, which consists of two parts:

• Deduction transaction tdt_dtd from the source virtual machine

• Credit transaction tct_ctc to the target virtual machine.
  The transaction ttt is first executed on the source virtual machine, completing the deduction and triggering the corresponding event.

• Event Monitoring and Submission
  A family is randomly selected from the clan of the source virtual machine (this family must contain at least one honest node), and these nodes monitor the deduction event and are responsible for submitting the credit transaction tct_ctc.

• Execute Credit on Target Virtual Machine
  The clan of the target virtual machine receives and executes tct_ctc, completing the asset credit, thus finishing the cross-VM transfer process.

9. Epochs and Cycles

In the Supra architecture, new nodes can only be added to or existing nodes removed from the tribe at the boundaries of an Epoch. The duration of an epoch is configurable, typically defined by the number of blocks or actual time. We plan to set the duration of an epoch to approximately one week. During each epoch, all nodes in the tribe execute the ordering service by running the consensus protocol.

As shown in Figure 10, an epoch is further divided into multiple cycles, with a typical duration of about one day for each cycle. In each cycle, nodes in the tribe are randomly assigned to different clans through Supra's VRF (Verifiable Random Function). For example:

• In Cycle 2 of Epoch 1 (e1c2), a node may serve as a DORA validator;

• While in Cycle 3 of Epoch 1 (e1c3), the same node may be responsible for executing EVM transactions.

This mechanism of randomly reassigning node roles each cycle significantly enhances the system's security, effectively defending against malicious actors attempting to target specific roles or functions.

Figure 10 Epochs and Cycles

Attackers targeting specific services (e.g., service SSS) may attempt to disrupt that service by incapacitating some nodes in the clan providing service SSS.

To address this threat, a Distributed Key Generation (DKG) protocol is run in each cycle for clan reorganization. We are able to achieve this frequent reorganization thanks to our innovations in the DKG field—developing a high-performance DKG protocol based on class groups.

Probability of Bad Clans

As discussed in Section 3, we analyzed the security implications of dividing a tribe containing 625 nodes into 5 clans (125 nodes each):

• Definition of a bad clan: A simple majority of Byzantine nodes occupying a clan.

• Probability of forming a bad clan: The probability of randomly forming a bad clan is approximately 35 in a million.

Assuming each cycle lasts one day and clans reorganize daily, this means that even in the most extreme case (where 33% of the nodes in the tribe are controlled by Byzantine actors), the probability of a bad clan appearing is extremely low, expected to occur only once every 78 years.

This extremely low probability is negligible, providing strong evidence of the reliability of our clan formation mechanism in providing robust security guarantees.

10. Containers

Supra Containers are an important feature designed for the developer community, inspired by the currently popular Appchain concept.

We fully recognize the advantages of Appchains, particularly their unique value in providing sovereign capabilities for dApp developers and their communities. Additionally, Appchains can support application-based business models. Currently, Layer 2, sidechains, Polkadot parachains, Cosmos zones, and Avalanche subnets are leading solutions in the Appchain space.

However, we also realize that these solutions are not ideal in high-throughput blockchain environments (such as Supra L1). Appchains typically need to provide the following key functionalities:

• Restricted deployment of smart contracts

• Custom gas tokens

• Custom gas pricing

When these Appchains are hosted on secondary chains (such as parachains, zones, subnets, etc.), their gas prices do not compete with the gas prices of the corresponding main chains (e.g., Polkadot relay chain, Cosmos Hub, or Avalanche C-Chain) and do not fluctuate with main chain prices. This localized fee market provides users with a more predictable transaction fee experience, which is highly desirable in practical applications.

Through Supra Containers, we aim to combine the advantages of these Appchains with the capabilities of a high-performance L1 blockchain, creating a more flexible and stable ecosystem for developers and users.

Figure 11 Containers

Supra Containers represent a new concept in the blockchain space. We define them as a collection or bundle of smart contracts serving a single or a group of related dApps. Through Supra Containers, we have optimized the runtime framework of Supra to provide dApp developers with an Appchain-like experience while featuring the following significant characteristics:

• Custom gas tokens

• Custom gas pricing

• Restricted deployment of smart contracts

All of this can be achieved at a very low cost, completely eliminating the cumbersome process of launching an entirely new secondary network (such as a validator network requiring collateral incentives).

Addressing Liquidity Fragmentation Issues

More importantly, we overcome a significant issue that Appchains typically face—liquidity fragmentation—by supporting atomic composability of cross-container method calls. This design ensures efficient interaction between containers while retaining the centralization of liquidity.

Promoting Parallel Execution

In the Ethereum EVM model, each smart contract has its own storage space. By introducing Supra Containers into the EVM model, the blockchain state can be divided into multiple partitions:

• Intra-container transactions only access the state of the target container without affecting the state of other containers.

• This state isolation optimizes the execution time of intra-container transactions and reduces conflicts between different containers.

Based on this feature, we have built a simple and efficient work-sharing queue to optimize parallel execution. Through this design, Supra Containers significantly enhance the execution efficiency of the blockchain, simplifying the developer experience and driving performance improvements across the entire ecosystem.

11. Conclusion

Supra, as a fully vertically integrated IntraLayer, has an ambitious vision that has been gradually taking shape after years of rigorous research. We have published numerous research results at top academic conferences, such as IEEE Security & Privacy, the Network and Distributed System Security Symposium (NDSS), and the ACM Conference on Computer and Communications Security (CCS). Additionally, we have released a series of white papers on core components, including:

• Moonshot and Sailfish consensus protocols

• Distributed Oracle Protocol (DORA)

• Distributed Verifiable Random Function (DVRF)

• Efficient Class Group Distributed Key Generation (DKG)

• Supra Containers

• HyperLoop

• HyperNova

This time, Supra presents for the first time a comprehensive vision of our fully vertically integrated blockchain infrastructure stack. This system combines numerous innovative protocols developed over the years, aiming to create an extremely high-performance, all-in-one integrated blockchain.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。