Supra 将多年来的多项创新成果集成到一个强大且高性能的架构中，该架构完全垂直集成了 MultiVM 智能合约支持和原生服务，包括价格预言机、链上随机数、跨链通信以及自动化功能。
在此基础上，该文详细介绍了 Supra 区块链的端到端交易流程，并展示了如何有效缓解审查风险和最大可提取价值（MEV）攻击的威胁。
Supra 网络依托共享安全平台，提供了一系列广泛的服务与功能。其中包括创新技术：分布式预言机协议（DORA）、分布式可验证随机函数（DVRF）、零区块延迟的自动化网络、受 AppChain 启发的容器架构、多 VM 支持，以及通过并行交易处理优化的区块执行。此外，Supra 的跨链设计——HyperLoop 和 HyperNova——使 Supra 成为全球首个通过智能合约平台逻辑实现多链互联的“IntraLayer”。
Supra 致力于通过开创性的研究和卓越的工程能力推动区块链技术变革，目标是构建一款高效的 Layer 1 区块链，全面集成各种区块链相关服务，为个人用户、机构客户以及开发者提供一体化解决方案和流畅的使用体验。
本文中，我们将展示 Supra 技术如何诠释古希腊哲学家亚里士多德的名言：“整体大于部分之和。” 秉承完全垂直集成的理念，Supra 提供了一套全面的区块链功能和服务，支持丰富的生态系统开发和多样化的应用场景。
Supra 区块链为 dApp 提供的原生服务（如图 1 所示）涵盖以下核心功能：
Layer 1 区块链
支持多种资产类型，包括原生代币、可编程的同质化和非同质化代币，以及标准化的跨链代币。
智能合约执行环境
提供多种链上图灵完备的智能合约平台，适用于 DeFi 协议、区块链游戏、彩票、供应链追踪等各种公共区块链应用。
链下数据服务
提供基于需求（拉取式）和流式（推送式）的数据服务，包括加密货币价格预言机、外汇汇率、股票指数和天气数据等。这些数据通过 Supra 的分布式预言机协议（DORA）传输，不仅服务于 Supra 区块链，也支持其他区块链网络。
图 1 完全垂直集成
推送与拉取式链上随机数服务
提供流式和按需格式的分布式可验证随机函数（dVRF），适用于 Web 2.0 和 Web 3.0 用户，用于生成和分发随机数服务。
自动化网络
用于根据特定的时间节点、链上事件或通过 DORA 提供的链下事件安排交易执行。例如，客户可能会提出请求：“在 2025 年 6 月 1 日，东部标准时间 12: 00 整，如果 ETH 价格高于 4000 美元，则出售我的 DOGE。”
应用专用链（AppChain）
Supra 上的容器提供了 AppChain 的灵活性和自主性，同时部署成本显著降低，并受益于 Supra 网络的高性能、共享安全性和统一流动性。
尽管 Supra 提供了一系列原生服务，我们深刻认识到多链生态的现实和价值。为提升互操作性，我们设计了一种星型拓扑结构（见图 2），在这一结构中，Supra 的 L1 区块链及其集成服务作为 IntraLayer 网络的核心，通过我们的互操作性解决方案 HyperLoop 和 HyperNova 连接其他 L1 和 L 2 区块链。
作为一个独立的 MultiVM 智能合约平台，Supra 不仅提供自身服务，还致力于在多链生态中扮演关键角色。这种角色体现在网络之间或“网络之内”的价值交换上，通过原生智能合约、自动化功能和预言机服务实现安全、高效的通信。
基于传统的多签名跨链协议，HyperLoop 是经过严格分析和博弈论验证的安全解决方案，是业内首个此类创新设计，确保跨链交易的可靠性。
作为一种无需信任的互操作性方案，HyperNova 提供跨链通信的高度安全性，为多链生态中的信息和价值交换奠定了坚实基础。
通过 HyperLoop 和 HyperNova，Supra 实现了广泛的链间互联，为用户和开发者提供了强大的工具，推动了多链生态的深度融合与发展。
图 2 Supra’s IntraLayer
连接链的安全性不依赖传统跨链或中继节点的安全假设。在此我们概述了 HyperLoop 和 HyperNova 最适用的具体场景。
HyperLoop
我们发现，HyperLoop 跨链解决方案特别适合将 Optimistic Rollup 连接到 Supra，因为它消除了实现最终确定性所需的欺诈证明挑战期。
HyperNova
适用于将任何权益证明（PoS）L1区块链连接到 Supra，因为它通过重新计算 Supra 交互链的共识来维护连接链的安全性，从而保持L1到L1的安全性。Supra 的L1区块链专门设计用于促进安全高效的跨链通信。
我们的计划包括利用 HyperNova 将比特币跨链到 Supra，同时通过 HyperLoop 实现反向连接。此外，我们正在探索如何在这个环境中实现原子交换，以进一步提升跨链互操作性。
以下是由 Supra IntraLayer 技术栈 支持的一些核心功能：
DeFi IntraLayer
作为“平台之上的平台”，Supra 封装了多种主流的 DeFi 协议（例如 AMM）。dApp 开发者可以轻松访问来自多个区块链的资产和信息，简化跨链开发流程。
跨链自动化服务
我们允许用户基于多个区块链的事件和数据设置自动化任务，从而极大提升用户体验和操作效率。
我们坚信，将多种原生服务完全垂直集成到一个高性能的L1区块链中，与我们打造全球首个跨链 IntraLayer 的愿景高度契合。随着其他区块链对我们服务的需求不断增长，Supra 网络的实用性（包括我们的代币和链上资产）将会带来价值的自然波动，进一步激励用户和客户采用我们的基础设施。
同时，随着 IntraLayer 架构在不同生态系统中的广泛应用，越来越多的开发者将被我们的原生服务和卓越性能所吸引，进而选择直接在 Supra 区块链上开发和构建应用。这不仅会增强我们的 DeFi 层，包括我们内部开发的协议和第三方协议，也将推动网络的整体采用率和吸引力。
我们相信，凭借卓越的性能和一站式、多元化的服务，Supra 将为开发者社区带来下一波 Web 3.0 技术普及浪潮，助力整个生态的快速发展。
Supra 的基本哲学是完全垂直集成，在单一平台上提供几乎所有与区块链相关的服务。这一方案能确保用户和开发者获得统一、流畅的使用体验。
Supra 采用的是垂直集成架构，不同于传统的模块化 L 2 解决方案：
在 L2 中，核心功能（如共识、执行和数据可用性）分散在独立网络中，虽然这种设计被称为“模块化优势”，但却带来了不少问题：
延迟增加：跨网络通信导致时间延迟；
经济安全分散：不同网络拥有各自的代币，无法共享安全性；
复杂性高：整体架构更难维护和协调。
与之相比，Supra 的完全垂直集成设计将所有组件统一到一个区块链中：
共享经济安全性和统一的代币经济；
大幅减少通信延迟，提升系统性能；
统一的激励机制增强网络安全；
降低了整体运营成本。
分布式系统研究表明，在异步或部分同步的网络中，传统的拜占庭容错（BFT）协议只能容忍最多三分之一的节点为恶意节点。但 Supra 的创新突破将这一容忍度提升至一半，实现了前所未有的安全性和效率。
Supra L1 区块链的核心是排序服务，其共识协议负责交易排序，而交易数据的传播与排序服务相分离。因此：
区块只包含交易批次的元数据（如摘要和数据可用性证明），而不包括具体的交易数据；
这使 Supra 区块链的区块非常小，极大提升了运行效率。
由于排序服务是所有其他服务的核心基础，我们将 Supra 区块链称为**“诚信链”**。
容忍更多拜占庭节点的直接优势在于：
更小的委员会：例如，容忍 50 个恶意节点，传统方法需要 151 名成员，而 Supra 只需 101 名成员；
降低成本：减少共识节点数量意味着需要补偿的节点更少，从而降低用户费用；
提高执行速度：共识节点数量更少，流程更快，同时仍保持强大的安全性。
图 3 部落、氏族与家庭
这一核心促进了 Supra 区块链上多个服务的高效完全垂直集成。Supra 提出了一种全新的网络框架，支持在部落、氏族或家庭层面执行各种不同的算法。
如图 3 所示：
部落（Tribe） 是一个节点委员会，最多容忍三分之一的拜占庭节点；
氏族（Clan） 是一个节点委员会，最多容忍二分之一的拜占庭节点；
家庭（Family） 是一个节点委员会，至少需要一个正确节点。
为了实现最佳性能和强大的安全性，我们的网络架构如下：活跃节点被组织成一个运行共识协议的部落，为排序服务提供支持，并容忍最多三分之一的拜占庭节点。
我们设计中的一个关键点是，整个 Supra 部落并不需要参与交易执行或维护完整的 Supra 状态。相反，一个更小的子集——称为“氏族”——即可管理状态、执行交易、计算区块的后状态并签署状态承诺。因此，交易数据的传播最初仅在氏族层面发生，然后再进一步广播。
这种架构非常适合高效的状态分片（state sharding），其中不同的氏族管理不同的状态分片，并可能使用独立的虚拟机。这种设计提高了可扩展性，允许我们通过增加更多氏族（或分片）来调整吞吐量。因此，除了共识之外的所有协议（如数据传播、分片执行、预言机服务和分布式随机数服务）都运行在只需要简单多数正确节点的小型委员会（氏族）中。
我们通过随机选择将节点分配到氏族中，将排序部落和多个服务氏族组织在一起，使这些氏族实际构成了部落的一个分区。共识或全局排序运行在部落上，而各种可验证的计算服务则在氏族中执行。这种节点的随机选择允许我们在氏族层面执行，并为系统引入了概率因素。例如，假设部落由 625 个节点组成，其中最多有 208 个拜占庭节点。如果将部落分成 5 个氏族，每个氏族 125 个节点，则任一氏族中超过半数（即 62 个）节点为拜占庭节点的概率约为 35 × 10 ⁻⁶。换句话说，当部落中拜占庭节点占 33% 时，出现“坏氏族”的概率仅为百万分之 35 。在实践中，这些概率极低。我们将在讨论周期和时间段时进一步分析这些概率，并展示它们在实践中几乎可以忽略不计。
Supra 链上交易流程大致如下，具体步骤将在后续章节详细描述：
图 4 展示了 Supra 区块链中端到端的交易流程
用户通过 Supra 的 Starkey 钱包 [ 3 ] 或 dApp 提交交易 ttt。钱包连接到网关 RPC 节点，交易 ttt 被发送至该节点。
网关 RPC 节点根据对交易 ttt 的基本验证和分类，将其发送到特定批次提议者的主存储(Primary Bucket），并将交易发送至一些其他批次提议者的次存储桶（Secondary Bucket）。
批次提议者从主存储桶中打包交易，并将次存储桶中超时的交易加入到批次中。有关详情请参见第 5 节。
批次通过 xRBC 协议传播到相应的执行氏族节点，必须形成数据可用性仲裁证书（DAQC）后，批次才能被包含到区块中。这些证书会传播到整个部落，批次也会传播到网关 RPC 节点。
部落节点运行 Supra 的 Moonshot 共识协议。区块提议者通过打包这些 DAQC 及相关批次的元数据来构建区块。
共识协议对区块进行排序，从而间接对跨批次的交易进行排序。当区块被最终确定时，所有运行共识协议的部落节点以及所有氏族的节点都能看到这些区块。最终确定的区块也会传播到网关 RPC 节点。
氏族节点从最终区块中执行相应批次的交易，并在当前区块链末端更新区块链状态。随后，它们计算后状态、进行默克尔化操作并计算新的默克尔根。注意，不同的氏族会并行执行不同的批次。氏族节点签署该默克尔根，并将其传播到整个部落以及网关 RPC 节点。
网关 RPC 节点执行区块，计算后状态及其默克尔根，验证其与接收到的签名默克尔根一致，并在交易完成后通知钱包。
在我们的工作流程中，交易 ttt 经历以下三个不同的最终性阶段，每个阶段都为交易在区块链上的状态提供更强的保证：
预确认阶段
当包含交易 ttt 的批次 bbb 获得数据可用性仲裁证书（DAQC）时，保证交易 ttt 将被包含在区块链中。在这一阶段，虽然交易的包含性得以保证，但其具体位置和执行结果尚未确定。
排序最终性
当共识协议对包含批次 bbb 的区块完成最终确认时，交易 ttt 在区块链中的位置变得固定且不可更改，从而确定了其相对于其他交易的执行顺序。
执行最终性
这是最终性阶段的终点。氏族节点执行批次 bbb，用交易 ttt 的执行结果更新区块链状态，创建新状态的默克尔化版本，签署生成的默克尔根并广播以形成状态承诺。一旦此阶段完成，交易的执行结果即为最终且不可逆转。
Supra L1支持快速的最终性时间。在我们的实验中，这些不同最终性阶段的观察时间将在第 7 节中报告。
后续章节将详细展开上述交易流程中的重要步骤。
图 5 无内存池的分桶方案
我们先讨论以太坊和 Solana 现有的内存池协议，然后展示 Supra 如何在此基础上实现改进。
传统的以太坊内存池协议流程如下：
客户端（钱包）向 RPC 节点发送交易，该节点通过 Gossip 协议广播交易，使其到达所有共识验证者。
当某个验证者成为区块提议者时，会尝试打包已接收到的交易。
区块提议者可能尝试通过不将交易包含在区块中进行审查，但由于所有共识验证者都持有这些交易，下一轮成为区块提议者的验证者将包含被遗漏或审查的交易。因此，此协议具有抗审查性。
在典型的区块链架构中，客户端（Web3 钱包）将交易发送到公开的 RPC 节点。RPC 节点随后通过点对点的 Gossip 协议，将交易传播到整个 RPC 节点网络和共识验证者网络。这些节点会维护一个称为“内存池”（mempool）的数据结构，用于暂存由客户端发送的交易。
接下来，区块构建者会从内存池中提取交易，将其打包到区块中，并通过共识协议进行处理。一旦区块达到最终性，包含的所有交易也会被视为最终确认的交易。
由于比特币和以太坊的内存池中积压了大量未处理的交易，平均来看，交易在被区块构建者选中之前会在内存池中停留较长时间。此外，点对点的 Gossip 协议在传播交易时也会进一步增加延迟。
为减少内存池延迟，Solana 采用了一种无内存池协议，其流程如下：
区块的生成按照固定的时间表进行，区块提议者会提前确定。
客户端（如钱包）将交易发送到 RPC 节点，RPC 节点会为交易附加读写访问信息等辅助数据，并将其发送给即将提议区块的部分提议者。如果某个提议者错过了该交易，其他提议者会在之后的区块中将该交易包含进去。
需要注意的是，Solana 网络需要 32 个区块确认才能实现完全最终性。尽管 Solana 在设计上对端到端的延迟进行了优化，但交易重复的问题仍然偶尔发生，可能会导致网络中断。与以太坊的内存池协议相比，Solana 采用针对预期区块提议者的定向通信，这种方法有效减少了交易传播的延迟。
与 Solana 类似，Supra 也采用了无内存池协议，但我们通过针对性通信替代了传统的网络范围 Gossip 协议。然而，Supra 的方法在两个关键方面有所不同：
1. 即时最终性
与 Solana 基于时间槽的系统不同，Supra 使用经典的拜占庭容错（BFT） PBFT 风格的共识协议，称为 Moonshot（详见后文）。在 Moonshot 协议中，当区块收到提交仲裁证书（QC）后，即可实现即时最终性，无需像 Solana 那样等待 32 个区块确认。这大大缩短了交易的最终确认时间，提升了系统性能。
2. 批次元数据存储
在 Supra 的共识设计中，区块中不直接包含交易数据，而是存储交易批次的 DAQC 和元数据（详见第 6 节）。在我们的无内存池协议中，来自客户端钱包的交易会被放入由指定批次提议者管理的分桶中，流程如图 5 所示。
我们的分桶方案特点如下：
1）去重机制
为每笔交易分配一个唯一的主批次提议者，该提议者负责将交易包含到一个批次中。这种单一责任模型天然避免了重复交易被打包进区块链。
2）冗余与抗审查性
为确保交易不会被遗漏，我们引入了次级批次提议者作为备份。如果主批次提议者未能及时包含交易，次级批次提议者会在超时后将该交易纳入批次中。
尽管多个次级提议者同时处理交易可能导致重复打包，但 Supra 系统会通过交易的首次出现来保持一致性。
重复的交易会因无效的交易序列号在执行阶段被自动中止，不影响链上状态。
3）不可更改的责任记录
如果次级提议者成功将交易包含进区块，它将生成一份不可更改的记录，证明主提议者未履行职责。这份记录可用于后续的网络分析，对那些审查交易或导致不必要延迟的批次提提议者进行处罚，确保系统的公平性和可靠性。
每个批次提议者维护两个分桶：主分桶和次分桶。
对于每笔交易 ttt，根据其唯一且不可预测的标识符（哈希值），系统会将其分配到一个特定的批次提议者家庭（family）。在该家庭中，一个节点被指定为交易 ttt 的主批次提议者，其余节点为次级批次提议者。
当 RPC 节点从钱包或 dApp 前端接收到交易 ttt 时，会根据交易的标识符，将其转发至对应的批次提议者家庭。主批次提议者将交易 ttt 存储在其主分桶中，而次级批次提议者则将交易 ttt 存储在各自的次分桶中。
在构建新批次时，批次提议者必须包含其主分桶中的所有交易。为了防范拜占庭行为（例如通过从主分桶中排除交易来审查特定交易），次级批次提议者作为备用机制发挥作用。
当批次被最终确定并由批次提议者观察到后，该提议者会从其主分桶和次分桶中移除已包含在批次中的交易。
此外，每笔交易 ttt 都有一个可配置的超时时间。如果 ttt 在超时之前未被纳入最终确定的批次，则其家庭中的次级批次提议者在构建下一批次时，必须从其次分桶中将 ttt 包含进批次中。这一机制确保交易不会被遗漏，并增强了系统的抗审查能力。
图 6 与现有解决方案的概念性比较
这种双层设计在高效去重和强大抗审查能力之间达成了巧妙的平衡。此外，当次级批次提议者成功将某笔交易纳入批次时，会生成一份不可更改的记录，证明主提议者未能履行其职责。这份记录可用于后续分析，并对那些审查交易或造成不必要延迟的批次提议者施加相应惩罚。
我们接下来介绍 Supra 是如何通过部落-氏族架构实现交易数据传播与交易排序的高效解耦的。
近年来，一些协议（如 Narwhal/Tusk [ 11 ] 和 Bullshark [ 20 ]）已经认识到交易数据传输的重要性，并采用了一种全新的设计范式，将数据传输与交易排序进行解耦。这一设计通过两个并行运行的子协议分别实现数据传输和排序：
在没有排序需求的情况下，数据传输简化为可靠广播（RBC），这是分布式系统中一个被广泛研究的基础操作。
具体来说，节点通过 RBC 子协议不断提议并传播新数据块；随后，这些数据块通过排序子协议被确定并输出。
这种设计有效地优化了带宽资源的利用率，使系统吞吐量相比传统方法有了显著提升。Supra 也遵循这一原则，解耦了数据传输与交易排序。然而，我们观察到，即使在当前最先进的共识协议中，优化的重心依然主要放在排序子协议上，这其实与系统的实际瓶颈相悖。
例如，Tusk [ 11 ] 和 Bullshark [ 20 ] 的主要优势是所谓的零消息排序，即在排序阶段完全消除通信开销。但正如我们之前所指出的，通信成本的主要来源并非排序，而是数据传输。
图 6 对比了我们的方法与现有解决方案。我们的目标是在数据传输阶段降低每个节点的传输量，特别是减少任意单个节点的最大传输负载。在实际应用中，网络带宽往往是系统吞吐量的主要限制因素。因此，通过优化数据传输过程，我们可以进一步提升系统整体的性能和效率。
我们通过以下创新显著降低了数据传输的通信成本：采用一个由同一节点集运行的独立排序服务。
在传统方法中，数据传输通常通过可靠广播（RBC）协议执行。RBC 需要系统中超过 2/3 的诚实节点，以防止广播者向不同节点发送不同的数据批次（即发送者歧义问题）。
然而，我们发现可以利用独立的排序服务，将数据传输改进为一种放宽的 RBC 操作，称为 xRBC。在 xRBC 中，仅需要超过 1/2 的诚实节点即可完成数据传输，这大幅降低了通信成本。
在 xRBC 中，仅依靠参与节点不足以完全防止发送者歧义。为解决这一问题，排序服务会对广播者的批次进行认证，确保诚实节点之间的共识，从而消除分歧。尽管排序服务仍需要超多数（超过 2/3 的诚实节点）的保障，但 xRBC 相较于传统 RBC 在以下方面具有显著优势：
更低的通信开销：通过减少对超多数诚实节点的依赖，降低了协议运行中的通信复杂度。
提升性能：xRBC 的设计能够更高效地处理数据传输，同时保持与传统 RBC 相当的安全性。
由于交易仅在氏族（部落的随机子委员会）内部执行，交易数据最初只需传输到执行该氏族的节点。这大大降低了网络带宽负载，相比将数据传播到整个部落而言更为高效。在每个执行氏族内，我们指定部分节点作为批次提议者，负责从各自的分桶中构建交易批次，并将其传输给氏族内的所有节点。
值得一提的是，不同氏族的批次提提议者能够独立并行地传播交易批次，无需同步或等待协议步骤。这种并行的异步传播机制在推送数据时最大化了网络带宽的利用效率。
此外，为了实现状态同步（以便跨周期进行节点重新分配，详见第 9 节），交易数据可能会在后续阶段进一步传播到整个部落。这种分阶段的数据传播设计在保证网络性能的同时，也确保了系统的一致性和灵活性。
图 7 xRBC protocol
批次提议者负责构建交易批次并将其发送到氏族内的所有节点。
当氏族节点接收到有效的批次后，会对批次的数据可用性进行投票，并将投票结果广播至氏族内的所有节点、部落的其他节点，以及指定的网关 RPC 节点。
一旦简单多数投票通过，系统会生成一个数据可用性证书（DAQC），确保至少有一个诚实节点拥有完整的交易数据。
如果某个节点缺失部分批次数据，它可以向简单多数的氏族节点请求数据，而 DAQC 保证了这一请求必定能够被满足。
对于超过大小阈值的批次，或者在并非所有氏族节点都担任批次提议者的情况下，我们引入纠删编码（erasure coding），以确保数据在氏族内部的均匀分布，优化带宽使用效率。
区块中仅包含批次证书。当共识协议的验证者（部落节点）担任区块提议者时，会将其接收到的所有批次的 DAQC 打包进区块中。一旦区块达到最终性并被验证者确认，验证者会将这些已包含的 DAQC 从缓存中移除，因为它们已被记录在最终确定的区块中，不再需要保留。
由于区块只包含批次证书，而不直接存储交易数据，Supra 区块链实际上是一条极为轻量化的区块链。这种设计大大减少了区块的大小，提高了数据传输效率。
BFT 共识协议是区块链的核心组件，负责为区块提供标准的排序，从而确保区块内的交易也具有标准顺序。我们创新性地设计了一种新型 BFT 共识协议，名为 Moonshot SMR，其灵感来源于经典的实用拜占庭容错 (PBFT) 协议，并在此基础上进行了性能优化。
正如前文所述，共识协议在部落中执行，而交易执行仅限于氏族内。因此，Moonshot 采用了弹性设计，能够根据实际交易吞吐量需求进行灵活适配。值得注意的是，区块中不直接包含交易数据，仅包含批次证书，这使得系统更为高效和轻量。
Moonshot 实现了以下关键性能指标：
连续提议延迟（两次区块提议之间的最小延迟）： 1 个消息延迟 (md)。
提交延迟： 3 md。
批次传播和数据可用性证书生成的累计延迟： 2 md。
由于区块每次网络跳跃（network hop）都会被提议，数据可用性证书需要排队等待下一个区块提议，平均排队延迟为 0.5 md。
因此，系统的整体端到端延迟为 5.5 md。
分布式协议往往具有复杂的行为和无限的状态空间，这使得证明其正确性变得极具挑战性。而形式化验证是确保协议安全性的黄金标准，因为它能够通过数学手段证明协议不存在错误。
为此，我们采用微软的 IvY 验证器对 Moonshot 共识协议的安全属性进行了形式化验证，严格证明了其永不分叉的特性，为协议的正确性和安全性提供了数学保障。
我们在谷歌云平台 (GCP) 上进行了广泛评估，将节点均匀分布在五个不同区域：
us-east 1-b（南卡罗来纳州）
us-west 1-a（俄勒冈州）
europe-north 1-a（芬兰哈米纳）
asia-northeast 1-a（东京）
australia-southeast 1-a（悉尼）
实验设置如下：
客户端与共识节点共置
每笔交易由 512 字节随机数据组成，批次大小设为 500 KB
每次实验运行 180 秒
延迟测量：计算从交易生成到被所有非故障节点提交的平均时间，以确定端到端延迟
吞吐量测量：基于每秒最终确定的交易数量进行评估
我们测试的架构由 300 个节点组成，划分为 5 个氏族，每个氏族包含 60 个节点（每个 GCP 区域部署 12 个节点）。在这一配置下， 300 节点网络中某个氏族（60 个节点）因内部不诚实多数而失败的概率为 0.0107 。
尽管如此，我们的目标不仅是展示该架构的高性能，还希望证明它即使在更大规模的系统中，依然能够维持高吞吐量和低延迟。
我们使用了 e 2-standard-32 机器，每台配备 32 个 vCPU、 128 GB 内存，出口带宽最高达 16 Gbps。
通过这些实验，我们验证了 Supra 架构在性能和扩展性方面的强大能力。
图 8 吞吐量与端到端延迟
我们观察了系统的吞吐量与端到端延迟之间的关系，具体如图 8 所示：
当吞吐量达到 500, 000 TPS 时，端到端延迟仍保持在 1 秒以内。
在 300, 000 TPS 时，延迟约为 650 毫秒，这一表现已接近我们架构设计的理论极限。
此外，我们测量了**数据可用性证书（DAQC）**的生成时间，约为 160 毫秒。
综上所述：
交易的预确认延迟约为 160 毫秒；
排序最终性延迟低于 1 秒。
受 DAG（有向无环图）共识协议 研究的启发，我们设计了一种全新的 DAG 共识协议，称为 Sailfish。该协议在不牺牲系统吞吐量的前提下，将提交延迟优化至 1 次可靠广播 1 消息延迟（md），超越了目前最先进的 DAG 共识协议的性能。
此外，我们开发了 Sailfish 的一个变体，将其与 部落-氏族架构 相结合，以进一步提升系统吞吐量。目前，我们正在对这一设计进行广泛的实验测试。如果 Sailfish 在大规模网络环境下的性能表现优于现有的 Moonshot 协议，我们计划将核心共识协议切换为 Sailfish，以实现更高效的共识流程。
图 9 Supra 的并行执行方法
区块链的当前状态包含所有资产及其所有权信息，以及所有智能合约的最新数据。执行已最终确定的区块交易时，需要加载相关的状态部分，按照区块内交易的顺序更新状态，并将修改后的状态持久化存储。
在现代区块链中，随着交易处理能力的不断提高，执行时间已成为交易最终确认端到端延迟中不可忽略的重要因素。这一趋势在 Solana、Sui、Aptos 和 Monad 等链中尤为明显，它们通过并行化执行有效地缩短了延迟时间。
我们的部落-氏族架构同样实现了交易的并行执行，但是在网络层面进行优化。具体来说，交易的执行仅限于氏族内部，不同的氏族分别并行处理各自的交易批次，从而显著提升了系统的执行效率（见图 9）。
除了在网络层面实现并行性之外，我们还深入研究了如何通过充分利用单个节点内的多核处理器，高效地并行执行交易。目前文献和行业中常见的并行执行方法主要分为两类：
乐观/推测性执行技术
基于确定性依赖关系的预先确定技术
STM 技术 在传统计算领域广泛应用于多核程序的并行执行。Aptos 的 BlockSTM 将 STM 技术引入到区块链交易执行中，其核心思想是：
乐观地在所有可用的核心上并行执行交易；
随后验证交易之间是否存在依赖关系冲突；
若发现冲突，则通过一个协作调度器重新执行冲突的交易。
我们提出了一种创新的 STM 并行执行算法，不同于 Aptos 的 BlockSTM，我们的设计无需调度器即可高效解决冲突。这种方法在性能和架构上与 BlockSTM 具有可比性，目前我们正在对该设计进行深入评估，以验证其在实际应用中的优势。
一些区块链通过指定交易的访问模式实现并行化：
Solana 的 Sealevel 要求交易明确声明需要读取和写入的账户。
Sui 要求交易指定读取和写入的对象（通过对象标识符），并声明这些对象是独占的还是共享的。
Polygon 的方法则不同，区块提议者使用 BlockSTM 技术执行区块，预先计算交易之间的依赖关系，并将这些依赖信息包含在区块中，从而使其他验证者能够并行执行互不依赖的交易。
然而，需要注意的是，无论是在交易中显式声明访问模式，还是在区块中包含依赖信息，都会显著增加区块大小。这可能导致带宽更快饱和，进而限制系统所能达到的最大吞吐量。
借鉴这些方法，我们正在开发一种确定性并行执行算法，通过静态分析智能合约，在合约部署时自动推导其访问规范，并将这些规范存储在区块链状态中，而无需 RPC 节点或钱包显式提供访问模式。这些规范允许我们将最终确定区块中的线性交易顺序优化为部分（放宽的）顺序，从而实现独立交易的并行执行。这种方法不仅减少了对带宽的占用，还提升了整体系统的吞吐量和效率。
我们认为，通过利用静态推导的访问规范改进 STM 算法的混合方法是优化执行技术的最终形式（见图 9）。我们目前正在对此设计进行全面评估。
为确保交易排序的公平性，我们设计了一个两步流程：
初始随机排序：共识协议首先生成一个交易的初始随机种子排序。
最终排序：通过基于区块的 BLS 门限签名生成的链上随机数协议，推导出最终确定的交易排序，决定交易的实际执行顺序。
这一额外的随机化层能够有效缓解最大可提取价值（MEV）攻击，因为批次提议者或区块提议者既无法预测，也无法操控最终的随机化交易执行顺序。
为应对垃圾交易（Spam）问题，我们引入了局部费用市场。在争议状态下，交易的成本将呈指数级增长，从而提高系统的抗干扰能力，同时确保交易排序的效率和公平性。
以太坊引入了 EVM，这是一种图灵完备的链上编程环境，极大地释放了 dApp 开发的创造力，尤其是为 DeFi 应用提供了强大支持。EVM 借鉴了 Web 2.0 编程语言的经验，催生了 Solidity。然而，随着区块链技术的发展，社区逐渐意识到，需要一种专为资产转移和链上资产管理设计的编程语言。因此，Meta 的 Diem 团队开发了 Move 语言，其后也衍生出 Aptos Move 和 Sui Move 等变体。
Supra 深刻认识到定制化链上交易编程语言的重要性，因此选择 Move 语言 作为我们智能合约平台的首选，并将在 Move 的支持下推出我们的 L1 区块链。
同时，我们也看到多虚拟机生态系统的巨大潜力。不同虚拟机下的开发者可以相辅相成，共同推动区块链行业的创新与发展。因此，我们设计了一个高效的多虚拟机架构。
基于部落-氏族架构的天然分片特性，每个氏族托管一个状态分片，而不同的氏族可以托管不同的虚拟机。
在集成 Move 智能合约平台 后，Supra 将进一步扩展至 以太坊虚拟机（EVM），实现与庞大的以太坊生态系统的兼容性。接下来，我们将集成 Solana 虚拟机（SVM），支持开发者使用 Rust、C 和 C 等广泛应用的编程语言来构建智能合约。
最终，Supra 还将支持 CosmWasm，实现与活跃的 Cosmos 生态系统的无缝连接。
在多虚拟机环境中，用户可能在不同虚拟机上拥有多个账户，并希望实现跨虚拟机资产转移。此外，Supra 的原生代币 $SUPRA 必须在所有虚拟机中实现统一管理。为解决这一问题，我们提出了一个简单高效的三步工作流：
提交跨虚拟机转移交易
用户发起跨虚拟机的资产转移交易 ttt，该交易由两部分组成：
源虚拟机的扣款交易 tdt_dtd
目标虚拟机的入账交易 tct_ctc。
交易 ttt 首先在源虚拟机上执行，完成扣款并触发相应事件。
事件监控与提交
从源虚拟机的氏族中随机选出一个家庭（该家庭至少包含一个诚实节点），这些节点监控扣款事件并负责提交入账交易 tct_ctc。
执行目标虚拟机入账
目标虚拟机的氏族接收并执行 tct_ctc，完成资产入账，至此跨虚拟机的转移流程完成。
在 Supra 的架构中，只有在 纪元（Epoch） 的边界时，才允许向部落中添加新节点或移除现有节点。纪元的持续时间是可配置的，通常根据区块数量或实际时间来定义。我们计划将纪元的时长设置为约一周。在每个纪元期间，部落中的所有节点都会通过运行共识协议来执行排序服务。
如图 10 所示，一个纪元进一步划分为多个 周期（Cycle），每个周期的典型持续时间为 约一天。在每个周期中，部落中的节点会通过 Supra 的 VRF（可验证随机函数） 被随机分配到不同的氏族。例如：
在纪元 1 的周期 2 （e 1 c 2），某节点可能担任 DORA 验证者的角色；
而在纪元 1 的周期 3 （e 1 c 3），同一节点可能负责执行 EVM 交易的任务。
这种每周期随机重新分配节点角色的机制显著提升了系统的安全性，能够有效防御恶意行为者试图针对特定角色或功能进行的攻击。
图 10 纪元与周
攻击特定服务（例如服务 SSS）的攻击者可能会尝试通过使提供服务 SSS 的氏族的一些节点失效来破坏该服务。
为了应对这一威胁，每个周期都会运行一个分布式密钥生成（DKG）协议进行氏族重组。我们能够实现这种频繁重组，得益于我们在 DKG 领域的创新——开发了一种基于类群（class-group）的高性能 DKG 协议。
如第 3 节所述，我们分析了在一个包含 625 个节点的部落中，将其划分为 5 个氏族（每个氏族 125 个节点）时的安全性影响：
坏氏族的定义：拜占庭节点占据某氏族的简单多数。
坏氏族形成的概率：随机形成坏氏族的概率约为 百万分之 35 。
假设每个周期为一天，并且氏族每天通过重组重新分配节点。这意味着即使在最极端的情况下（部落中 33% 的节点由拜占庭行为者控制），坏氏族的出现概率也极低，预计每 78 年才会发生一次。
这一极低的概率几乎可以忽略不计，充分证明了我们氏族形成机制在提供强大安全保障方面的可靠性。
Supra 容器（Container） 是为开发者社区设计的一项重要功能，其灵感来源于当前流行的 应用链（Appchain） 概念。
我们充分认可应用链的优势，尤其是它们在为 dApp 开发者及其社区提供主权能力方面的独特价值。此外，应用链还能够支持基于应用的商业模式。目前，Layer 2、侧链、Polkadot 平行链、Cosmos 区域链（Zones）和 Avalanche 子网（Subnets）是应用链领域的领先解决方案。
然而，我们也意识到，这些解决方案在高吞吐量区块链（如 Supra L1）的环境下并不理想。应用链通常需要提供以下关键功能：
智能合约的受限部署
自定义 Gas 代币
自定义 Gas 定价
当这些应用链托管在次级链（如平行链、区域链、子网等）上时，它们的 Gas 价格不会与对应主链（例如 Polkadot 中继链、Cosmos Hub 或 Avalanche C-Chain）的 Gas 价格产生竞争，也不会随主链价格波动。这种本地化的费用市场为用户提供了一种更加可预测的交易费用体验，这一特性在实际应用中非常理想。
通过 Supra 容器，我们旨在将这些应用链的优势与高性能 L1 区块链的能力相结合，为开发者和用户创造更加灵活、稳定的生态环境。
图 11 容器
Supra 容器（Supra Container）是区块链领域的一种全新概念。我们将其定义为服务于单个或一组相关 dApp 的智能合约集合或捆绑包。通过 Supra 容器，我们对 Supra 的运行时框架进行了优化，为 dApp 开发者提供类似应用链（Appchain）的体验，同时具备以下显著特点：
自定义 Gas 代币
自定义 Gas 定价
智能合约的受限部署
这一切都能以极低的成本实现，完全省去了启动一个全新的次级网络（例如需要抵押激励的验证者网络）的繁琐过程。
更重要的是，我们通过支持跨容器方法调用的原子可组合性，克服了应用链通常面临的一个重大问题——流动性碎片化。这一设计确保了容器间的高效交互，同时保留了流动性的集中性。
在以太坊 EVM 模型中，每个智能合约拥有独立的存储空间。将 Supra 容器引入 EVM 模型后，可以将区块链状态划分为多个分区：
容器内交易（intra-container transactions） 只访问目标容器的状态，而不会影响其他容器的状态。
这种状态隔离优化了容器内交易的执行时间，并减少了不同容器间的冲突。
基于这一特性，我们构建了一个简单而高效的工作共享队列，用于优化并行执行。通过这一设计，Supra 容器显著提升了区块链的执行效率，既简化了开发者体验，又推动了整个生态系统的性能提升。
Supra 作为一个完全垂直集成的 IntraLayer，其雄心勃勃的愿景历经多年的严谨研究，正在逐步成形。我们在多个顶级学术会议上发表了大量研究成果，例如 IEEE Security & Privacy、网络与分布式安全研讨会（NDSS）、ACM 计算机与通信安全会议（CCS）等。此外，我们还发布了一系列核心组件的白皮书，包括：
Moonshot 和 Sailfish 共识协议
分布式预言机协议（DORA）
分布式可验证随机函数（DVRF）
高效类群分布式密钥生成（DKG）
Supra 容器
HyperLoop
HyperNova
此次，Supra 首次全面呈现了我们关于完全垂直集成区块链基础设施栈的愿景。这一体系结合了多年来开发的众多创新协议，旨在打造一个极致高性能的全方位一体化区块链。
| 正加财富网内容推荐 | ||
| OK交易所下载 | USDT钱包下载 | 比特币平台下载 |
| 新手交易教程 | 平台提币指南 | 挖矿方法讲解 |
