Technical Guide: A Complete Guide to Supra’s Blockchain Technology Stack

Abstract

Supra integrates many years of innovation into a powerful and high-performance architecture that fully vertically integrates MultiVM smart contract support and native services, including price oracles, on-chain random numbers, cross-chain communication, and automation capabilities.

Based on this, this paper details the end-to-end transaction flow of the Supra blockchain and shows how to effectively mitigate the threat of censorship risk and maximum extractable value (MEV) attacks.

The Supra network provides a wide range of services and features based on a shared security platform. These include innovative technologies: Distributed Oracle Protocol (DORA), Distributed Verifiable Random Function (DVRF), automated networking with zero block latency, container architecture inspired by AppChain, multi-VM support, and optimized block execution through parallel transaction processing. In addition, Supra's cross-chain design - HyperLoop and HyperNova - makes Supra the world's first "IntraLayer" to achieve multi-chain interconnection through smart contract platform logic.

1. Native full vertical integration of blockchain services

Supra is committed to promoting blockchain technology change through pioneering research and outstanding engineering capabilities. The goal is to build an efficient Layer 1 blockchain that fully integrates various blockchain-related services to provide integrated solutions and smooth user experience for individual users, institutional clients and developers.

In this article, we will show how Supra technology interprets the famous saying of the ancient Greek philosopher Aristotle: "The whole is greater than the sum of its parts." Adhering to the concept of full vertical integration, Supra provides a comprehensive set of blockchain functions and services to support rich ecosystem development and diverse application scenarios.

Core Function Overview

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

· Layer 1 blockchain

Supports multiple asset types, including native tokens, programmable homogeneous and non-homogeneous tokens, and standardized cross-chain tokens.

· Smart Contract Execution Environment

Provides a variety of on-chain Turing-complete smart contract platforms suitable for various public blockchain applications such as DeFi protocols, blockchain games, lotteries, supply chain tracking, etc.

· Off-chain Data Services

Provide 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 other blockchain networks.

Figure 1 Full vertical integration

· Push and pull on-chain random number services

Provide distributed verifiable random functions (dVRF) in streaming and on-demand formats, suitable for Web 2.0 and Web 3.0 users, for generating and distributing random number services.

· Automated Network

Used to schedule trade executions based on specific time nodes, on-chain events, or off-chain events provided through DORA. For example, a client might make a request: "On June 1, 2025, at 12:00 Eastern Standard Time, if the price of ETH is above $4,000, then sell my DOGE."

· Application-Specific Chain (AppChain)

Containers on Supra provide the flexibility and autonomy of AppChain, 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

While Supra provides a range of native services, we deeply recognize the reality and value of a multi-chain ecosystem. To improve interoperability, we designed a star topology (see Figure 2), in which Supra's 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 strives to play a key role in the multi-chain ecosystem. This role is reflected in the exchange of value between networks or "within the network", achieving secure and efficient communication through native smart contracts, automated functions and oracle services.

HyperLoop

Based on the traditional multi-signature cross-chain protocol, HyperLoop is a security solution that has been rigorously analyzed and verified by game theory. It is the first innovative design of its kind in the industry to ensure the reliability of cross-chain transactions.

HyperNova

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

Through HyperLoop and HyperNova, Supra has achieved extensive inter-chain interconnection, provided users and developers with powerful tools, and promoted the deep integration and development of the multi-chain ecosystem.

         

Figure 2 Supra’s IntraLayer

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

· HyperLoop

We found that the HyperLoop cross-chain solution is particularly suitable for connecting Optimistic Rollup to Supra because it eliminates the fraud proof challenge period required to achieve finality.

· HyperNova

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

Our plans include leveraging HyperNova to cross-chain Bitcoin to Supra, while enabling reverse connectivity via HyperLoop. Additionally, we are exploring how to implement atomic swaps in this environment to further enhance cross-chain interoperability.

Here are some of the core features powered by the Supra IntraLayer technology stack:

· DeFi IntraLayer

As a "platform on top of a platform", Supra encapsulates a variety of mainstream DeFi protocols (such as 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 improving user experience and operational efficiency.

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

At the same time, as the IntraLayer architecture is widely used in different ecosystems, more and more developers will be attracted by our native services and excellent performance, and then 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 its excellent performance and one-stop, diversified services, Supra will bring the next wave of Web 3.0 technology popularization to the developer community and help the rapid development of the entire ecosystem.

3. The core of Supra - the "Tribe and Clan" node model

Supra's basic philosophy is to be fully vertically integrated and provide almost all blockchain-related services on a single platform. This solution ensures that users and developers have a unified and smooth user experience.

Fully vertically integrated vs. modular Layer 2

Supra adopts a vertically integrated architecture, which is different from traditional modular L 2 solutions:

In L2, core functions (such as consensus, execution, and data availability) are scattered across independent networks. Although this design is called the "modular advantage", it brings many problems:

· Increased latency: cross-network communication causes time delays;

· Decentralized economic security: different networks have their own tokens and cannot share security;

· High complexity: the overall architecture is more difficult to maintain and coordinate.

In contrast, Supra's fully vertically integrated design unifies all components into one blockchain:

· Shared economic security and a unified token economy;

· Significantly reduce communication latency and improve system performance;

· Unified incentive mechanism enhances network security;

· Reduce overall operating costs.

Breakthrough in Byzantine Fault Tolerance

Distributed system research shows that in asynchronous or partially synchronous networks, traditional Byzantine Fault Tolerance (BFT) protocols can only tolerate up to one-third of nodes as malicious nodes. But Supra's innovative breakthrough increases 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 about transaction batches (such as summaries and data availability proofs), but not specific transaction data;

· This makes the blocks of the Supra blockchain very small, greatly improving operational efficiency.

Since the sorting service is the core foundation of all other services, we call the Supra blockchain the "chain of integrity".

Why is it important to tolerate more Byzantine nodes?

The direct advantages of tolerating more Byzantine nodes are:

· Smaller committees: For example, to tolerate 50 malicious nodes, the traditional method requires 151 members, while Supra only requires 101 members;

· Reduced costs: Reducing the number of consensus nodes means fewer nodes that need to be compensated, thereby reducing user fees;

· Improved 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 efficient and complete vertical integration of multiple services on the Supra blockchain. Supra proposes a new network framework that supports the execution of a variety of different 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, provides support for the sorting 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 full Supra state. Instead, a smaller subset - called a "clan" - manages the state, executes transactions, calculates the post-state of the block, and signs the state commitment. Therefore, the propagation of transaction data initially occurs only at the clan level and then further broadcast.

This architecture is well suited for efficient state sharding, where different clans manage different state shards and may use independent virtual machines. This design improves scalability and allows us to adjust throughput by adding more clans (or shards). Therefore, all protocols other than consensus, such as data dissemination, shard execution, oracle services, and distributed random number services, run in small committees (clans) that only require a simple majority of correct nodes.

We organize the sorting tribe and multiple service clans together by assigning nodes to clans by random selection, so that these clans actually constitute a partition of the tribe. Consensus or global sorting runs on the tribe, while various verifiable computation services are performed in the clan. This random selection of nodes allows us to perform at the clan level and introduce a probabilistic element to the system. For example, suppose the tribe consists of 625 nodes, of which there are at most 208 Byzantine nodes. If the tribe is divided into 5 clans, each with 125 nodes, the probability that more than half (i.e. 62) of the nodes in any clan are Byzantine nodes is about 35 × 10⁻⁶. In other words, when the Byzantine nodes account for 33% of the tribe, the probability of 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, and show that they are almost negligible in practice.

4. Transaction Process

The transaction process on the Supra chain is roughly as follows, and the specific steps will be described in detail in subsequent chapters:

  Figure 4 shows the end-to-end transaction flow in the Supra blockchain

· The user submits a transaction ttt through Supra’s Starkey wallet [3] or dApp. The wallet connects to the gateway RPC node, and the transaction ttt is sent to the node.

· The gateway RPC node sends the transaction ttt to the primary bucket of a specific batch proposer based on basic verification and classification, and sends the transaction to the secondary bucket of some other batch proposers.

· The batch proposer packs the transactions from the primary bucket and adds the timed-out transactions in the secondary bucket to the batch. See Section 5 for details.

· Batches are propagated to the corresponding executing clan nodes via the xRBC protocol, and Data Availability Arbitration Certificates (DAQCs) must be formed before the batch can be included in a block. These certificates are propagated throughout the tribe, and the batches are also propagated to the Gateway RPC nodes.

· Tribe nodes run Supra's Moonshot consensus protocol. Block proposers build blocks by packaging these DAQCs with metadata about the associated batches.

· The consensus protocol orders blocks, and thus indirectly orders transactions across batches. When blocks are finalized, they are visible to all tribe nodes running the consensus protocol, as well as nodes from all clans. Finalized blocks are also propagated to the Gateway RPC nodes.

· Clan nodes execute the corresponding batches of transactions from the finalized block and update the blockchain state at the end of the current blockchain. They then compute the post-state, merkleize, and compute a new merkle root. Note that different clans execute different batches in parallel. The clan node signs the Merkle root and propagates it throughout the clan as well as to the Gateway RPC nodes.

· The Gateway RPC node executes the block, computes the post-state and its Merkle root, verifies that it is consistent with the received signed Merkle root, and notifies the wallet when the transaction is complete.

Finality Phase

In our workflow, transaction ttt undergoes the following three different finality phases, each providing a stronger guarantee for the transaction’s status on the blockchain:

· Pre-confirmation Phase

When batch bbb containing transaction ttt obtains a Data Availability Arbitration Certificate (DAQC), it is guaranteed that transaction ttt will be included in the blockchain. At this stage, while the inclusion of the transaction is guaranteed, its specific location and execution outcome are not yet determined.

· Ordering Finality

When the consensus protocol finalizes the block containing batch bbb, the position of transaction ttt in the blockchain becomes fixed and unchangeable, thus determining its execution order relative to other transactions.

· Execution Finality

This is the end of the finality phase. The clan node executes batch bbb, updates the blockchain state with the result of the execution of transaction ttt, creates a Merkle-ized version of the new state, signs the resulting Merkle root and broadcasts it to form a state commitment. Once this phase is complete, the execution result of the transaction is final and irreversible.

Supra L1 supports fast finality times. In our experiments, the observed times for these different finality phases are reported in Section 7.

The important steps in the transaction flow described above will be expanded in detail in the subsequent sections.

Figure 5 Bucketing without memory pool

5. Bucketing without memory pool

We first discuss the existing memory pool protocols of Ethereum and Solana, and then show how Supra improves on them.

Ethereum memory pool scheme

The traditional Ethereum memory pool protocol process is as follows:

· The client (wallet) sends a transaction to the RPC node, which broadcasts the transaction through the Gossip protocol so that it reaches all consensus validators.

· When a validator becomes a block proposer, it will try to package the received transactions.

· A block proposer may try to censor by not including transactions in the block, but since all consensus validators hold these transactions, the next validator who becomes a block proposer will include the omitted or censored transactions. Therefore, this protocol is censorship-resistant.

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

Next, block builders extract transactions from the memory pool, package them into blocks, and process them through the consensus protocol. Once a block reaches finality, all transactions contained in it are also considered finalized transactions.

Due to the large backlog of unprocessed transactions in the memory pools of Bitcoin and Ethereum, on average, transactions stay in the memory pool for a long time before being selected by block builders. In addition, the peer-to-peer gossip protocol will further increase latency when propagating transactions.

Solana No Memory Pool Solution

To reduce memory pool latency, Solana uses a no memory pool protocol that works as follows:

· Block generation is carried out according to a fixed schedule, which is determined in advance by the block proposer.

· The client (such as a wallet) sends the transaction to the RPC node, which attaches auxiliary data such as read and write access information to the transaction and sends it to some proposers who are about to propose the block. If a proposer misses the transaction, other proposers will include the transaction in a later block.

It is important to note that the Solana network requires 32 block confirmations to achieve full finality. Although Solana is designed to optimize end-to-end latency, transaction duplication issues still occur occasionally and may cause network outages. Compared to Ethereum's memory pool protocol, Solana uses targeted communication to the intended block proposer, which effectively reduces the latency of transaction propagation.

Supra No-Memory Pool Protocol Solution

Similar to Solana, Supra also uses a no-memory pool protocol, but we replace the traditional network-wide Gossip protocol with targeted communication. However, Supra’s approach differs in two key ways:

1. Instant Finality

Unlike Solana’s time-slot-based system, Supra uses a classic Byzantine Fault Tolerant (BFT) PBFT-style consensus protocol called Moonshot (see below for details). In the Moonshot protocol, instant finality is achieved when a block receives a submission arbitration certificate (QC), without having to wait for 32 block confirmations like Solana. This greatly shortens the final confirmation time of transactions and improves system performance.

2. Batch metadata storage

In Supra's consensus design, blocks do not directly contain transaction data, but store DAQC and metadata of transaction batches (see Section 6 for details). In our memory pool-free protocol, transactions from client wallets are placed in buckets managed by designated batch proposers, as shown in Figure 5.

The characteristics of our bucketing scheme are as follows:

1) Deduplication mechanism

Each transaction is assigned a unique primary batch proposer, who is responsible for including the transaction in a batch. This single responsibility model naturally avoids duplicate transactions from being packaged into the blockchain.

2) Redundancy and censorship resistance

To ensure that transactions are not missed, we introduce secondary batch proposers as backups. If the primary batch proposer fails to include a transaction in time, the secondary batch proposer will include the transaction in the batch after a timeout.

· Although multiple secondary proposers processing transactions at the same time may result in duplicate packaging, the Supra system will maintain consistency through the first appearance of the transaction.

· Duplicate transactions will be automatically terminated during the execution phase due to invalid transaction sequence numbers, without affecting the on-chain status.

3) Unchangeable record of responsibility

If the secondary proposer successfully includes the transaction into the block, it will generate an unchangeable record proving that the primary proposer has failed to fulfill his duties. This record can be used for subsequent network analysis to punish batch proposers who censor transactions or cause unnecessary delays, ensuring the fairness and reliability of the system.

The specific process of the bucketing scheme without a memory pool is as follows:

· Each batch proposer maintains two buckets: the primary bucket and the secondary bucket.

· For each transaction ttt, the system assigns it to a specific batch proposer family based on its unique and unpredictable identifier (hash value). In this family, one node is designated as the primary batch proposer of transaction ttt, and the rest are secondary batch proposers.

· When the RPC node receives a transaction ttt from a 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 secondary batch proposers store transaction ttt in their respective secondary buckets.

· When building a new batch, a batch proposer must include all transactions in its primary bucket. To prevent Byzantine behavior (such as censoring specific transactions by excluding transactions from the primary bucket), secondary batch proposers act as a backup mechanism.

· When a batch is finalized and observed by a batch proposer, the proposer removes the transactions that were included in the batch from its primary and secondary buckets.

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

 Figure 6 Conceptual comparison with existing solutions

This two-layer design strikes a clever balance between efficient deduplication and strong censorship resistance. In addition, when a secondary batch proposer successfully includes a transaction in a batch, an immutable record is generated, proving that the primary proposer failed to fulfill its responsibilities. This record can be used for subsequent analysis and to impose corresponding penalties on batch proposers that censor transactions or cause unnecessary delays.

6. No-memory pool architecture: efficient decoupling of transaction data propagation and transaction ordering

Next, we describe how Supra achieves efficient decoupling of transaction data propagation and transaction ordering through a 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 to decouple data transmission from transaction ordering. This design implements data transmission and ordering respectively through two sub-protocols running in parallel:

· In the absence of ordering requirements, data transmission is simplified to reliable broadcast (RBC), which is a widely studied basic operation in distributed systems.

· Specifically, nodes continuously propose and propagate new data blocks through the RBC subprotocol; these data blocks are then determined and output through the sorting subprotocol.

This design effectively optimizes the utilization of bandwidth resources, significantly improving system throughput compared to traditional methods. Supra also follows this principle and decouples data transmission and transaction sorting. However, we observe that even in the most advanced consensus protocols, the focus of optimization is still mainly on the sorting subprotocol, which is actually contrary to the actual bottleneck of the system.

For example, the main advantage of Tusk [11] and Bullshark [20] is the so-called zero-message ordering, which completely eliminates the communication overhead in the ordering phase. However, as we pointed out before, the main source of communication cost is not ordering, but data transmission.

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

Supra's xRBC Protocol

We significantly reduce the communication cost of data transmission through the following innovation: adopting an independent ordering service run by the same set of nodes.

In traditional methods, data transmission is usually performed via a reliable broadcast (RBC) protocol. RBC requires more than 2/3 of the honest nodes in the system to prevent the broadcaster from sending different batches of data to different nodes (i.e., the sender ambiguity problem).

However, we found that we can use an independent sorting service to improve the data transmission into a relaxed RBC operation called xRBC. In xRBC, only more than 1/2 of the honest nodes are required to complete the data transmission, which greatly reduces the communication cost.

Design advantages of xRBC

In xRBC, relying solely on participating nodes is not enough to completely prevent sender ambiguity. To solve this problem, the sorting service certifies the broadcaster's batches and ensures consensus among honest nodes, thereby eliminating disagreements. Although the sorting service still requires a supermajority (more than 2/3 of the honest nodes) guarantee, xRBC has significant advantages over traditional RBC in the following aspects:

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

Improved performance: xRBC is designed to handle data transmission more efficiently while maintaining security comparable to traditional RBC.

Utilizing clan-distributed data propagation

Since transactions are only executed within a clan (a random subcommittee of the tribe), transaction data only needs to be initially transmitted to the nodes executing the 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 some nodes as batch proposers, responsible for building transaction batches from their respective buckets and transmitting them to all nodes in the clan.

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

In addition, in order to achieve state synchronization (to facilitate node redistribution across cycles, see Section 9 for details), transaction data may be further propagated to the entire tribe in subsequent stages. This phased data propagation design ensures the consistency and flexibility of the system while ensuring network performance.

Figure 7 xRBC protocol

Specific process (Figure 7 description)

· The batch proposer is responsible for building transaction batches and sending them to all nodes within the clan.

· When a clan node receives a valid batch, it votes on the data availability of the batch and broadcasts the voting results to all nodes in 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) to ensure that at least one honest node has 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 DAQC guarantees that this request will be satisfied.

· For batches that exceed the size threshold, or when not all clan nodes serve as batch proposers, we introduce erasure coding to ensure that data is evenly distributed within the clan and optimize bandwidth efficiency.

Block Content and Finality

Blocks only contain batch certificates. When the validator (tribe node) of the consensus protocol acts as a block proposer, it will pack all the batches of DAQC it receives into the block. Once the block reaches finality and is confirmed by the validator, the validator will remove the included DAQC from the cache because they have been recorded in the finalized block and no longer need to be retained.

Since the block only contains batch certificates and does not directly store transaction data, the Supra blockchain is actually an extremely lightweight blockchain. This design greatly reduces the size of the block and improves data transmission efficiency.

7. Consensus Protocol

Byzantine Fault Tolerant (BFT) Consensus Protocol: The Heart of Blockchain

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

As mentioned above, the consensus protocol is executed in tribes, while transaction execution is limited to clans. Therefore, Moonshot adopts a resilient design that can flexibly adapt to actual transaction throughput requirements. It is worth noting that blocks do not directly contain transaction data, only batch certificates, which makes the system more efficient and lightweight.

Performance of Moonshot

Moonshot achieves the following key performance metrics:

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

· Commit latency: 3 md.

· Cumulative latency of batch propagation and data availability certificate generation: 2 md.

· Since blocks are proposed on every network hop, data availability certificates need to queue for the next block proposal, with an average queuing delay of 0.5 md.

Thus, the overall end-to-end latency of the system is 5.5 md.

Formal Verification: Ensuring Protocol Security

Distributed protocols often have complex behaviors and unbounded state spaces, which makes it extremely challenging to prove their correctness. Formal verification is the gold standard for ensuring protocol security because it can mathematically prove that the protocol does not have errors.

To this end, we used Microsoft's IvY verifier to formally verify the security properties of the Moonshot consensus protocol, strictly proving its property of never forking, providing mathematical guarantees for the correctness and security of the protocol.

Experimental Evaluation

We conducted an extensive evaluation on Google Cloud Platform (GCP), evenly distributing nodes in 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 are co-located with consensus nodes

· Each transaction consists of 512 bytes of random data and the batch size is set to 500KB

· Each experiment runs for 180 seconds

· Latency measurement: The average time from transaction generation to being committed by all non-faulty nodes is calculated to determine the end-to-end latency

· Throughput measurement: Evaluation is based on the number of finalized transactions per second

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

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

Hardware Configuration:

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

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

 Figure 8 Throughput and End-to-End Latency

We observed the relationship between the throughput and end-to-end latency of the system, as shown in Figure 8:

· When the throughput reaches 500,000 TPS, the end-to-end latency remains within 1 second.

· At 300,000 TPS, the latency is about 650 milliseconds, which is close to the theoretical limit of our architecture design.

In addition, we measured the generation time of the **Data Availability Certificate (DAQC), which is about 160 milliseconds.

To summarize:

· The pre-confirmation latency of transactions is about 160 milliseconds;

· The ordering finality latency is less than 1 second.

DAG Consensus Protocol

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

In addition, we developed a variant of Sailfish and combined it with the tribe-clan architecture to further improve system throughput. We are currently conducting extensive experimental tests on this design. If Sailfish outperforms the existing Moonshot protocol in a large-scale network environment, we plan to switch the core consensus protocol to Sailfish to achieve a more efficient consensus process.

Figure 9 Parallel execution method of Supra

 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 a finalized block transaction, it is necessary to load the relevant state parts, update the state according to the order of transactions in the block, and persist the modified state.

In modern blockchains, with the continuous improvement of transaction processing capabilities, execution time has become an important factor that cannot be ignored in the end-to-end latency of transaction finalization. This trend is particularly evident in chains such as Solana, Sui, Aptos, and Monad, which effectively reduce latency by parallelizing execution.

Our tribe-clan architecture also achieves parallel execution of transactions, but optimizes it at the network level. Specifically, the execution of transactions is limited to the clan, and different clans process their own batches of transactions in parallel, which significantly improves the execution efficiency of the system (see Figure 9).

8.1 Parallel Execution of Transactions

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

· Optimistic/speculative execution techniques

· Predetermined 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' BlockSTM introduces STM technology to blockchain transaction execution. Its core idea is:

· Optimistically execute transactions in parallel on all available cores;

· Then verify whether there are dependency conflicts between transactions;

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

Supra Innovation

We propose an innovative parallel execution algorithm for STM that, unlike Aptos’ BlockSTM, efficiently resolves conflicts without a scheduler. This approach is comparable to BlockSTM in performance and architecture, and we are currently conducting in-depth evaluation of this design to verify its advantages in real-world applications.

Parallelization based on access specifications

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

· Solana’s Sealevel requires transactions to explicitly declare the accounts that need to be read and written.

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

·  The approach is different, the block proposer uses BlockSTM technology to execute blocks, pre-calculate the dependencies between transactions, and include this dependency information in the block, so that other validators can execute independent transactions in parallel.

However, it is important to note that both explicitly declaring access modes in transactions and including dependency information in blocks will significantly increase block size. This may lead to faster bandwidth saturation, which in turn limits the maximum throughput that the system can achieve.

Learning from these approaches, we are developing a deterministic parallel execution algorithm that statically analyzes smart contracts, automatically infers their access specifications when they are deployed, and stores these specifications in the blockchain state without requiring RPC nodes or wallets to explicitly provide access patterns. These specifications allow us to optimize the linear transaction order in the finalized block into a partial (relaxed) order, thereby enabling parallel execution of independent transactions. This approach not only reduces bandwidth usage, but also improves overall system throughput and efficiency.

Hybrid Approach

We believe that the hybrid approach of improving the STM algorithm by leveraging statically derived access specifications is the ultimate form of optimized execution technology (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 design a two-step process:

· Initial Random Ordering: The consensus protocol first generates an initial random seed ordering of transactions.

· Final Ordering: The finalized transaction order is derived through the on-chain random number protocol generated by the block-based BLS threshold signature, which determines the actual execution order of transactions.

This additional layer of randomization can effectively mitigate the Maximum Extractable Value (MEV) attack, because the batch proposer or block proposer can neither predict nor manipulate the final randomized transaction execution order.

To address the spam problem, we introduced a local fee market. In a disputed state, the cost of transactions will increase exponentially, thereby improving the system's anti-interference ability while ensuring the efficiency and fairness of transaction ordering.

8.3 Multi-VM

Ethereum introduced EVM, a Turing-complete on-chain programming environment that greatly unleashed the creativity of dApp development, especially providing strong support for DeFi applications. EVM borrowed from the experience of Web 2.0 programming languages and gave birth to Solidity. However, as blockchain technology developed, the community gradually realized that a programming language designed specifically for asset transfer and on-chain asset management was needed. Therefore, Meta's Diem team developed the Move language, which later spawned variants such as Aptos Move and Sui Move.

Supra deeply understands the importance of customized on-chain transaction programming languages, so it chose the Move language as the first choice for our smart contract platform and will launch our L1 blockchain with the support of Move.

At the same time, we also see great potential in a multi-VM ecosystem. Developers under different VMs can complement each other and jointly promote 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, and different clans can host different VMs.

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) to support developers to build smart contracts using widely used programming languages ​​such as Rust, C, and C++.

Finally, Supra will also support CosmWasm to achieve seamless connection with the active Cosmos ecosystem.

Cross-VM Communication

In a multi-VM environment, users may have multiple accounts on different VMs and want to transfer assets across VMs. In addition, Supra's native token $SUPRA must be managed uniformly across all VMs. To solve this problem, 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:

The source VM's deduction transaction tdt_dtd​

The target VM's credit transaction tct_ctc​.

Transaction ttt is first executed on the source VM, 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 (the family contains at least one honest node), which monitors the deduction event and is responsible for submitting the entry transaction tct_ctc​.

· Execute the target virtual machine entry

The clan of the target virtual machine receives and executes tct_ctc​ to complete the asset entry, and the cross-virtual machine transfer process is completed.

9. Epochs and cycles

In Supra's architecture, adding new nodes to the tribe or removing existing nodes is allowed only at the boundary of the Epoch. The duration of the Epoch is configurable and is usually defined in terms of the number of blocks or actual time. We plan to set the duration of the Epoch to about one week. During each Epoch, all nodes in the tribe perform sorting services by running the consensus protocol.

As shown in Figure 10, an epoch is further divided into multiple cycles, each of which typically lasts about one day. 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 (e1c2) of epoch 1, a node may serve as a DORA validator;

· In cycle 3 (e1c3) of epoch 1, the same node may be responsible for executing EVM transactions.

This mechanism of randomly reassigning node roles per cycle significantly improves the security of the system and can effectively defend against attacks by malicious actors attempting to target specific roles or functions.

Figure 10 Epochs and Weeks

An attacker attacking a specific service (e.g., service SSS) may try to disrupt the service by failing some nodes of the clan that provides service SSS.

To counter this threat, a distributed key generation (DKG) protocol is run every cycle to perform clan reorganization. We are able to achieve this frequent reorganization thanks to our innovation in the field of DKG - we have developed a high-performance class-group based DKG protocol.

Probability of Bad Clan Emergence

As described in Section 3, we analyze the security impact of partitioning a tribe of 625 nodes into 5 clans of 125 nodes each:

· Definition of a Bad Clan: A simple majority of Byzantine nodes in a clan.

· Probability of Bad Clan Formation: The probability of a bad clan forming randomly is about 35 in a million.

Assume that each cycle is one day and that clans reassign nodes every day through reorganization. This means that even in the most extreme case (33% of the nodes in the tribe are controlled by Byzantine actors), the probability of a bad clan emerging is extremely low and is expected to occur only once every 78 years.

This extremely low probability is almost negligible, which fully proves the reliability of our clan formation mechanism in providing strong security.

10. Containers

Supra Container is an important feature designed for the developer community, inspired by the popular concept of Appchain.

We fully recognize the advantages of Appchains, especially their unique value in providing sovereign capabilities to dApp developers and their communities. In addition, Appchains can also support application-based business models. Currently, Layer 2, Sidechains, Polkadot Parachains, Cosmos Zones, and Avalanche Subnets are the leading solutions in the field of Appchains.

However, we also realize that these solutions are not ideal in the context of high-throughput blockchains such as Supra L1. Application chains typically need to provide the following key features:

· Restricted deployment of smart contracts

· Custom Gas tokens

· Custom Gas pricing

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

With the Supra container, we aim to combine the advantages of these application chains with the capabilities of high-performance L1 blockchains to create a more flexible and stable ecosystem for developers and users.

Figure 11 Container

Supra Container is a new concept in the blockchain space. We define it as a collection or bundle of smart contracts that serve a single or a group of related dApps. With Supra Container, we have optimized the Supra runtime framework to provide dApp developers with an Appchain-like experience, with the following notable features:

· 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 tedious process of launching a whole new secondary network (such as a validator network that requires staking incentives).

Solving the problem of liquidity fragmentation

More importantly, we overcome a major problem that application chains usually 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 independent storage space. After 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 transactions within a container and reduces conflicts between different containers.

Based on this feature, we built a simple and efficient work-sharing queue to optimize parallel execution. With this design, Supra containers significantly improve the execution efficiency of blockchains, simplifying the developer experience and driving performance improvements for the entire ecosystem.

11. Conclusion

Supra, as a fully vertically integrated IntraLayer, is gradually taking shape after years of rigorous research. We have published a large number of research results in multiple top academic conferences, such as IEEE Security Privacy, Network and Distributed Security Symposium (NDSS), ACM Conference on Computer and Communications Security (CCS), etc. In addition, we have released a series of white papers on core components, including:

· Moonshot and Sailfish Consensus Protocol

· Distributed Oracle Protocol (DORA)

· Distributed Verifiable Random Function (DVRF)

· Efficient Group-Based Distributed Key Generation (DKG)

· Supra Container

· HyperLoop

· HyperNova

This is the first time that Supra has fully presented our vision for a fully vertically integrated blockchain infrastructure stack. This system combines many innovative protocols developed over the years to create an extremely high-performance, all-in-one blockchain.