异步程序执行：Solana APE新时代的曙光

29分钟阅读

2024年11月25日

引言

在今年热闹的Breakpoint大会上，Solana联合创始人Anatoly Yakovenko抽出时间进行了一场即兴的、未经记录的技术研讨会。他手持白板和马克笔，深入探讨了一个他热情倡导的话题，这也是本文的核心——异步执行（Asynchronous Execution）。

作为对异步执行（以下简称AE）雄心勃勃愿景的入门，首先我们将高层次地解释AE的核心概念和目标。接着，我们将审视Solana现有的执行和共识机制，以奠定未来提议架构的比较分析基础。然后，我们将深入探讨围绕AE的各种提案，首先是Bankless Leaders，这是这一转变所必须的垫脚石。我们还将探讨2022年早期的设计提案，并按时间顺序继续到最近的“终局架构”（Endgame Architecture）提案，这些提案超越了AE，包括多个并发区块生产者的设计实现。

AE： 概述

这样想有点奇怪。一个验证者所做的就是制作区块并投票。他从来不需要执行任何这些区块。在创造区块时，他并不知道自己在创造什么样的区块……你关心的只是达成共识的顺序。它并不关心值是什么。 - Anatoly Yakovenko(Solana联合创始人)

在Solana的核心协议背景下，AE指的是将执行与共识分开，使它们能够独立运作的架构方法。网络通过对交易顺序达成共识而不实际执行它们来实现这一点。一旦达成了顺序，同样任何人都可以执行交易以揭示真相。

在这种方法下，领导者在不执行非投票交易的情况下构建区块，并通过Turbine在网络中传播它们。验证者也可以在不执行非投票交易的情况下对区块进行投票。共识仅限于交易的排序和可用性，极大地减少了达成共识所需的时间和步骤。用DBA的Jon Charbonneau的总结来概括——排序决定真实性，而执行揭示真实性。

这种方法与当前共识的作用截然不同，当前的共识中，领导者在将交易打包成区块之前执行交易，且所有验证者在对此区块进行投票之前都会重播该区块中的交易。

AE之所以可能，是因为：

1. 分叉选择不依赖于程序执行
2. 给定一个确定性的状态转移函数，可以计算出唯一的正确状态。最终，每个人将计算出相同的最终状态
3. 无效交易可以被丢弃。失败交易垃圾邮件对网络的成本相对较低，仅包括在网络传播交易时所需的Turbine带宽和交易在账本中的额外存储
4. 需要进行实时、低延迟全状态计算的机器（例如专门的RPC服务提供商所操作的机器）可以专门配置以完成此任务

AE的潜在优势是显而易见的。

Yakovenko甚至表示异步执行是极少数几乎没有权衡的情况之一。“

1. 更快的区块时间（200毫秒）
2. 更可靠的区块时间
3. 更低的验证者要求
4. 改进的用户体验（更快的最终性）
5. 增强的审查抵抗能力
6. 减少重新排序交易的窗口
7. 在区块之间的未使用容量的滚存
8. 为多个并发区块生产者提供通路（稍后将详细讨论）

我们将在本文中探讨AE如何提供这些优势。

另一种理解AE的方法是，它允许投票程序独立于所有其他程序运行。投票程序和系统程序（始终需要）是任何一个时代内达成共识所需的唯一程序。

关于Solana上AE的讨论已经进行多年。Anatoly Yakovenko的初步正式提案，最初名为APEX（异步程序执行），可以追溯到2022年4月。关于AE在Solana上如何实际实现的具体细节分散在多个SIMD和文章中，本文几乎按时间顺序覆盖了这些内容。Yakovenko无疑是Solana社区中AE最强有力的公共支持者和倡导者，他很少错过在采访和播客中讨论这一话题的机会。

术语

简要定义将出现在我们AE讨论中的两个关键术语——Bankless Leaders和多个并发区块生产者（Multiple Concurrent Block Producers，MCBP）。总结如下：

• Bankless Leader：能够在不执行交易的情况下创建区块的领导者
• 异步执行（AE）：共识与执行的完全分离
• 多个并发区块生产者（MCBP）：顾名思义，同一时间段内产生多个区块

Bankless Leaders是实现完整AE的必要步骤。同样，AE的成功实施对于随后引入多个并发区块生产者（MCBP，也称为多个并发领导者（Multiple Concurrent Leaders，MCL））至关重要。AE的讨论通常与MCBP的讨论密切相关。Yakovenko倡导二者作为Solana的“终局架构”的关键组成部分。

Solana并不是唯一一个研究这些架构增强的区块链。Monad计划通过将共识与执行解耦到独立线程来实施AE。同样，以太坊研究社区也探讨了引入多个并发提议者的可能性已有一段时间。

Yakovenko的提案仍然是社区内不断争论的话题，因为实施它们将需要对Solana核心协议进行重大修改。并不是每个人都认同AE是向前的最佳路径。毫不夸张地说，全面实施Yakovenko提议的终局架构将彻底改变Solana的运作，增加协议的整体复杂性。

在深入研究AE之前，我们必须刷新对Solana当前执行和共识运作方式的认识，特别关注本文后期提到的方面。我们还将分析投票及非投票交易的数据，以揭示更多见解，为后面的讨论提供信息。已经熟悉并对这些功能有信心的读者可能希望跳过下一部分。

同步执行（当前的Solana）

执行

Solana采用连续区块构建，这涉及在400毫秒的分配时间段内动态组装和流式传输区块。在旋转之前，领导者被分配四个连续的插槽（1.6秒）。为了使一个区块被网络接受，领导者必须验证并执行区块内的每个交易。 此外，所有其他参与共识的活跃验证者都会重新验证和重新执行区块中的每个交易。

领导者通过Gulfstream接收交易数据包，使用的是QUIC，进入事务处理单元（TPU），TPU是领导者生成区块的核心逻辑。TPU通过三个开放端口接收数据包：

• tpu: 处理常规交易，如代币转移、NFT铸造和程序指令
• tpu_vote: 专门处理投票交易
• tpu_forwards: 如果当前领导者无法处理所有交易，它通过这个端口将未处理的数据包转发到下一个领导者

在任何排序或执行开始之前，所有交易数据包都经过严格的验证和合理性检测，包括签名验证、签名数量检查和重复交易删除。请注意，投票交易和非投票交易有各自的签名验证过程。

区块构建发生在Bank阶段。Bank是在给定区块的状态。交易并行处理并被打包入账本条目中——一批64个不冲突的交易。所有交易都包括将要读取和写入的完整账户列表。这种设计允许验证者仅选择非冲突的交易在每个条目中执行。当两个交易写入同一账户（两个写入）或读取和写入同一账户（读取+写入）时，它们冲突。冲突交易进入不同的条目并按照顺序执行，而不冲突的交易则并行执行。

六个线程并行处理交易，其中四个专门处理非投票交易，两个专门处理投票交易。共识投票在Bank阶段被视为特权交易——统一定价为0.000005 SOL，消耗2100个计算单位（CUs），并由投票程序执行。

一旦交易被分组到条目中，它们将由Solana虚拟机（SVM）执行。所需的交易账户被锁定；检查确认交易是最新的但尚未处理。账户被加载，交易逻辑被执行，更新账户状态。条目的哈希被发送到历史证明（PoH）服务进行记录。一旦成功，所有更改将被提交到Bank，并解除对每个账户的锁定。

协议不强制要求区块内有效交易的顺序。链的最终状态是所有已确认交易的结果。此状态可以始终从区块链的历史中确定性地重新创建（即，从Genesis或快照重放账本）。

每个Bank都有一个对应的BankHash，是以下内容的SHA256哈希：

• 父BankHash - 即时父区块的BankHash
• 账户DeltaHash - 当前区块中所有经历了状态改变的账户的16元 Merkle树根
• 签名数量 - 当前区块中的全部交易签名的总数
• 最后区块哈希

代码

hashv(&[\
    parent_bankhash,\
    accounts_delta_hash,\
    num_sigs,\
    blockhash,\
])

BankHash是验证者针对每个插槽投票的加密承诺。

共识

验证者需要三个账户以促进投票过程：

身份账户

该系统账户是所有投票交易的签署者和费用支付者——一个直接存储在服务器硬件上的热密钥对。顾名思义，该账户的公钥作为验证者的网络身份。创建投票账户时需要身份账户。

投票账户

这是委托者将其SOL委托到的账户。地址用于账户查找，而非签署交易。

提现账户

该账户用于从投票账户中提现。它可以更换身份账户。此账户的私钥通常存储在安全的多重签名或冷钱包中，且必须与验证者身份和投票权限密钥对是唯一的。

每次投票（示例）由验证者签名时，都包括验证者的公钥以及一个哈希，标识他们正在投票的区块。当验证者提交正确且成功的投票时，他们会获得积分。

网络不等待所有验证者就新生成的区块达成一致再生成下一个区块。因此，两个不同的区块链接到同一父区块的情况并不少见，这生成了分叉。验证者必须对这些分叉进行投票，并使用Tower BFT，一种原始实际拜占庭容错（pBFT）变体，来确定采用哪一个。

当存在竞争的分叉时，网络会最终确认单个分叉，而验证者会放弃被丢弃分叉中的区块。每个插槽都有一个预先确定的领导者，只有该领导者制作的区块会被接受。在单个插槽中不能有两个提议的区块。因此，可能的分叉数量受到一种“有/没有”跳跃列表的限制，这种分叉可以在领导者轮换插槽的边界出现。

一旦验证者选择了一个分叉，他们就会在锁定时间到期前承诺该分叉，也就意味着他们必须在最短时间内坚持自己的选择。这种机制激励验证者仔细地在他们认为最有可能被纳入，亦即“最重”的分叉上投票。

当有超过三分之二的超大多数投票支持某个区块时，该区块被认为是乐观确认。一旦在其上构建31个区块，则视为最终确认。在Solana的历史上，从未有过乐观确认的区块没有最终确认。

当分叉被确认时，该区块与账户的更新从Bank根植，其祖先被冲洗到磁盘。此外，来自较早Bank的、不构成最终确认Bank祖先的任何账户更新将被修剪。

投票与非投票交易

正如我们在Solana上所见，交易执行过程与通过Tower BFT达成共识是密切相连的。投票交易和非投票交易遵循相同的路径：它们被打包成条目，由SVM执行，标记在历史证明（PoH）流中，并通过Turbine传播给网络。这种统一的过程确保了验证者对共识状态的视图一致，因为仅通过gossip服务进行传播的投票可能导致验证者之间的差异。这种差异可能使验证者对哪个分叉更可能正确有不同的看法。持续的区块构建需要持续的投票，特别是在之前的区块确认期间。

这种打包的副作用是，关于Solana的每秒交易数（TPS）指标产生了争议。其原始形式包括投票和非投票交易，而大多数行业同类网络并非如此。这导致采用一种“真实TPS”指标，排除投票交易，以更精确地衡量交易容量。

检查最近的Solana活动，我们看到投票交易数量超过非投票交易，平均每个区块略低于1000个。

投票交易在每个区块的计算单位仅占很小的比例，平均略超过每个区块200万个CU，并保持在210万到230万CU之间。这仅占Solana区块4800万个CU计算限额的4.5%。

相较于非投票交易，投票交易在所需时间和计算上非常可靠。这是我们在后文中将回到的关键点。非投票交易的CU不一致，导致硬件消耗效率低下。 ‍

在运行时保证精确的执行时机具有挑战性，因为它更像是一种近似测量。平均而言，区块力争保持在400毫秒内，但偶尔会出现峰值。这些峰值可以被视为错误，且持续有努力去识别和修复这些问题，导致持续改进。

一个纪元由432,000个插槽组成。如果每个插槽正好400毫秒，这将导致一个精确48小时的纪元。然而，正如我们从历史数据中观察到的，纪元很少（如果有的话）达到这个目标。在过去的一年中，纪元通常需要2.1到2.3天的时间。

同步执行要求所有质押的共识参与验证者们都超额配置，以防任何区块中的最坏执行时间。因此，Solana的验证者硬件要求相对较高。

这就是我们对Solana当前共识和执行运作方式的综述，主要关注与后期讨论相关的部分。我们建议阅读我们之前的Helius博客文章，涵盖共识、PoH、Turbine以及Solana是如何工作的的更全面概述。在接下来的部分，我们将探讨Solana协议设计的未来变化。

APEX，2022

Yakovenko对AE的最早正式提案可以追溯到2022年4月，标题为APEX（异步程序执行）。这个相对简短的提案提出了如何将共识与执行分开，介绍了将状态分为两个孤立域的概念——默认的“域0”和投票程序的“域1”。这种设置将投票程序与Bank的其余部分分开。‍

所有账户都属于单个域；交易不能读或写多个域中的账户。任何这样做的交易都将立即失败并被忽略。系统程序同时存在于两个域中，投票程序是域1中唯一的其他程序。

一个特殊的系统指令（SystemInstruction::MoveDomains）提供机制，让账户在纪元期间每个纪元移动一次，以便于将SOL转移到投票账户或从投票账户中转移出来。

该提案还引入了ForkHash的概念，是BankHash的工作。“ForkHash”的计算仅评估来自领域1的投票程序指令，而“BankHash”计算所有来自领域0的非投票程序指令。投票指令引用ForkHash。BankHash的计算是在共识验证者投票的根外进行的。之前，选择一个分叉并投票于此需要对Bank中的所有交易进行完全评估和执行。现在，分叉选择中仅评估与投票程序相关的交易。

这个早期设计留有许多未解答的问题，但奠定了孤立域的基础概念，这个概念后面将会再次提到。

Bankless Leaders

Bankless领导者是指可以在不执行非投票交易的情况下自由制作区块的领导者，这是实施AE的关键前提。在一篇题为Bankless之路的博文中，Anza工程师Andrew Fitzgerald在早期的Bankless领导者提案（SIMD-005，2022年12月，已关闭）基础上进行扩展，该提案也是Anza的Tao Zhu提出的。Fitzgerald列出了在Solana上引入Bankless领导者所需的一些必要改动，具体识别出了协议施加的三类关键约束，这些约束限制了AE的实施：区块约束、条目约束和交易约束。

目前打破任何上述约束都会使整个区块无效。通过消除这些限制，Solana协议将为AE开辟前进的道路，并增强协议在区块生产和验证方面的灵活性。以下是不同约束形式的总结：

区块约束

这些是对整个区块施加的约束，包括：

• 区块必须包括64个tick
• 最后一个区块条目必须是一个tick
• 所有区块条目内的交易必须在区块限制内

条目约束

这一类别的主要约束是条目不能包含冲突交易。Fitzgerald在去年11月提交了SIMD 0083: 放松条目约束，专门解决这个问题。该SIMD已被接受。

交易层级约束

这一类是最大的，可以分为三个子类：

静态约束

无需了解任何附加状态即可验证的约束。这些包括签名验证、交易大小、读取/写入地址列表中的账户数量、交易数据格式合规（即，交易必须反序列化） ‍

这一交易层约束的子类别不需要调整。

Bank状态约束

这些包括检查交易签名的唯一性，以确保它未在最近的区块中包含，以及时间验证（即交易必须包括一个最近的区块哈希）

此子类需要对Bank的最近状态有所了解。

账户状态交易约束

最具限制性的子类别，包括地址查找表（ALT）分辨率、nonce检查、费用支付者检查和可执行性检查

该子类需要对先前交易有所了解。

Fitzgerald正式提议对这一约束类别进行变更，形式为SIMD 0082: 放松交易约束，该提案目前处于开放状态。

正如Fitzgerald所指出的，AE的主要要求是区块验证不能依赖于账户状态。如果区块的验证需要先前交易的结果，则该区块便无法异步执行。因此，需要消除对区块验证的账户状态的依赖。此外，这些约束的许多部分被认为是不必要的限制。

注意：

放宽这些约束不会改变当前执行交易的要求。这仅意味着如果其中一个放宽的约束被打破，则区块验证不会拒绝整个区块。

例如，一个签名者的账户没有足够的lamports来支付费用的交易在当前协议或拟议的变更中都不应被执行。但在建议的变更下，包含这样一个交易不会使其余的区块标记为无效。

总体而言，Fitzgerald的工作提供了一个务实的框架，用于对Bank阶段进行更改，以铺平AE的道路，概述了使AE成为现实所需的许多共识更改步骤。

APExB 2023：AE与MCBP的结合

异步程序执行将把整个Solana状态转变为一个rollup。- Anatoly Yakovenko Solana联合创始人

在2023年3月，即最初APEX设计几乎一年之后，Yakovenko提出了一项更全面且详细的提案，标题为异步程序执行和广播（APExB），此提案不仅包括AE的实施，还呈现了更广泛的愿景，包括多个并发区块生产者（MCBP）的集成。

该提案引入了“构建者”（builders）的概念，这与领导者是不同的实体。构建者是建立的节点，仅创建由非投票交易组成的UserBlocks。这些UserBlocks通过Turbine树传播，并有其自己的“UserBlockSlots”。默认情况下，每个常规插槽有两个UserBlockSlots。

构建者有一个独立于领导者日程的时间表。多个构建者可以被安排同时构建UserBlocks。计算单位在构建者与UserBlock插槽之间平均分配。例如，一个有两个构建者、两个UserBlock插槽和4800万个CU限额的区块将有一个UserBlock插槽CU限额为1200万（48/4）。

领导者仍然按照领导者安排创建共识投票的区块，同时构建者并发地生成和传输用户交易的UserBlocks。UserBlocks指定其插槽编号，并由构建者签名，以防止领导者操控或排除区块的某一部分。一旦领导者通过Turbine接收到UserBlock，它将使用UserBlock的哈希生成一个UserBlockEntry，并将此UserBlockEntry添加到历史证明（PoH）中。

验证者不能对他们尚未接收到的附随UserBlocks进行投票；否则，无法保证每个人都能执行数据，因为这些数据可能会被压制。但是，他们可以对领导者区块进行投票，仅通过执行投票交易，随后再执行UserBlock交易。验证者仅在最重的分叉上执行UserBlocks，并且仅需提交他们最新的BankHash进行投票，该投票可能是针对较旧的父插槽的。验证者投票时采用VoteHashes，其作用与APEX 2022提案中的ForkHashes相同——本质上是仅针对投票交易的BankHash。

构建者日程

如果每个网络区块有十个UserBlock构建者，每个构建者将被分配10% 的Turbine碎片和10%的可用计算资源。构建者通过两种方式进行调度：随机化和持续性。

在每个纪元的边界，随机构建者根据按权重的选择过程进行分配。持续性UserBlock插槽是通过荷兰拍卖系统分配给准备烧掉最多SOL的最高出价者。

交易优先排序

每个UserBlock假定在领导者编码它的UserBlockSlot中同时创建。在UserBlockSlot内的每个UserBlock中，交易在执行之前按优先费用排序。如果来自两个不同区块的交易具有相同的优先级，则按哪个UserBlock在领导者的PoH中出现先后排序。这意味着优先费用隐含了执行优先级。重复或无效的UserBlock交易在没有状态更改的情况下被跳过。如果多个UserBlockEntries包含相同的交易，第二个将被跳过。

上图：在场景1中，尽管B交易在PoH流中到达较晚，但它将被优先处理。在场景2中，C交易将被优先处理，因为其持有和D交易相同的优先费用，但其出现在PoH流中的区块较早。

在这一设计下，构建者将捕获所有的MEV。提案对构建者和领导者如何分配用户交易费用的问题仍然留有疑问。

构建者还可以创建BundleTransactions，这是一组设计用来在同一有序批次中执行的交易。这些交易也可以增加优先费用，以使整个批量被优先执行，类似于当前Jito bundles的实现。

纪元边界

质押权重影响分叉选择，在每个纪元边界更新。这在设计上有重要的影响。验证者必须在继续投票到达该纪元边界之前完成对非投票交易的执行。

然而，Yakovenko指出在这种情况下，“[n]odes不能落后太多，因为总体CU限制是为同步执行设定的。但是通过异步执行的选项，更易于追赶。原始账本处理在不处理网络的情况下要快20-30倍。”

考虑因素

多个构建者意味着资源管理变得更加复杂。客户端可以选择离他们最近的构建者，但每个UserBlock的优先费用可能会不同，用户将可能不知道在发送交易时哪些区块可能变得饱和。

优点包括调度的可预测性。应用程序可以竞标它们所需的区块带宽百分比，以进行操作，并创建专用排序器，保证最终结算到链上。包括随机的UserBlock构建者是关键，因为这样可防止持续构建区块的构建者审查交易，并在交易最终落地时阻止它们。

2024年的APE在Solana

在一篇题为异步程序执行（APE） 的X文章中，今年6月，Yakovenko进一步阐述了最初在2022年APEX提案中描述的执行领域概念。

执行领域，最初为域0和域1，现在被重新命名为投票执行领域（Vote Execution Domain，VED）和用户执行领域（User Execution Domain，UED）。它们的目的是相同的——完整地将共识投票与交易执行隔离。

执行领域被定义为一组独立于其他集合的程序，以及它们交互的键和值，可以独立执行：

• 执行领域可以在不同的线程和内核上运行，并且可以在物理分开的机器上不同时间完成
• 执行领域A不能读取或写入执行领域B中的任何值
• 领域可以共享在执行期间保持一致的状态
• 费用支付者决定执行交易的域
• 需要一个协议来同步领域之间的状态，并促进键和值的转移

投票执行领域（VED）组件

• SystemProgram: 用于转账
• VoteProgram: 投票的核心程序。此程序是静态的，必须同时存在于UED和VED中
• VoteProgram Sysvars: 用于投票的变量
• 投票授权: 被授权投票的账户
• 投票费用支付者: 支付与投票相关费用的账户
• 费用支付者资金: 可更新的账户，可以用于将SOL移动到VED中

不在VED中的账户被视为UED的一部分。

投票账户必须被激活。在下一个纪元中激活的投票账户会被包含在VED中。一旦被停用，它们将在下一个纪元中被移除出VED。已针对资金的进出文件形成正式的流程。

账户跟踪它们被映射到哪个执行领域，遵循类似于Linux文件权限的约定（_R_读取，_W_写入和_X_执行）。有四个有效映射：

只有投票程序和系统程序账户可以在VED和UED之间移动。系统程序提供一个接口，可以将系统账户和投票程序账户在VED之间动态迁移。这种方式消除了明确的FeePayerFunding账户的需求。任何系统账户都可以在VED和UED之间重新映射，以将资金在两个领域之间移动。

领导者仅在他们创建的区块上执行VED域，这意味着他们可能对UED费用支付者的状态有部分或不完整的信息。在接收区块之后，验证者首先执行VED交易。得到的VED状态用于计算VED哈希，随后验证者使用此哈希投票。

UED回放跳过具有无效费用支付者的交易。UED状态更新计算Bankhash，称为UED哈希。如果三分之一或更多的验证者提交不同的UED哈希，所有节点必须停止并警告操作员。

新特性激活

随着共识现在解耦于执行，投票程序必须设计为处理VED投票可能跨越纪元边界的情形，这将导致新特性激活发生在与在UED中与投票程序交互的交易不同的时间。

终级架构2024

考虑到应用程序和核心开发者的多样性，每年计划一次单一的重要协议变更是值得的。如果要选择一个，我会投票支持异步执行。 - Anatoly Yakovenko

在2024年初，Yakovenko发布了终局架构，一份断言Solana未来宏伟愿景的文档，设想创建一个10,000节点的网络，区块时间为120毫秒。这份文档重新确认并扩展了早先的设计提案，同时强调采用AE作为实现这一雄心目标的路径。

Bankless领导者

总结如下：

• 领导者维护费用支付账户余额的缓存
• 如果费用支付者作为可写账户被用作系统转账源，或作为可写账户与系统程序一起传递给另一个程序，则费用支付账户余额设置为0
• 区块根据声明的CU填充，直到区块基于本地费用优先级排序被填满，且从费用支付者余额缓存中减去交易费用
• 费用支付账户余额缓存通过BankHash计算进行补充

领导者可以最初通过查询多个全节点或RPC获取费用支付者的账户余额。在节点提供错误数据的罕见情况下，结果可能是失败的交易，而不是共识失败。如果费用支付者余额过时，可能会导致区块内的垃圾交易，而不会影响共识。失败交易垃圾邮件的成本相对较低，主要涉及在传播交易时所需的Turbine带宽和它们在账本中所占用的额外存储空间。此外，Temporal和Firedancer团队正在积极开发工具，通过实施过滤无效交易和去重的机制，防止那些由于读/写锁定冲突而必然失败的交易在到达区块之前产生垃圾信息。

这个问题很容易被检测和监控。运营商可以跟踪领导者的表现和评估区块中的垃圾级别，允许他们快速解决问题并在必要时切换到其他数据源。由于验证者有动力最大化他们的收益，它们也被激励去维持一个准确的费用支付账户余额缓存。

固定大小子委员会

在一个庞大的10,000节点网络中实施AE必然需要引入固定大小的轮换投票委员会，这代表着共识机制上的重大转变。这种变化通过不论质押节点的总数量，都稳定了共识投票的资源成本。Yakovenko建议，200或400个节点的轮换委员会将是足够的。这种设置使验证者能够以最小状态要求参与共识投票——仅限于法定人数、质押权重和投票账户余额。内存占用小，相应的快照文件可以在重启时轻松分发和重新初始化。

真正的讽刺在于，经过异步执行，Solana共识验证者可以在FPGA上运行。对于10,000个投票账户，Turbine + tower可以轻盈放置在一个FPGA上。也许大约4MB的状态用于跟踪。 - Anatoly Yakovenko

在拜占庭容错 (BFT) 协议中使用固定大小的轮换子委员会是一个 既定概念，已经由像 Tron 这样的对等网络在 生产中实现。它基于委员会抽样方法，该方法选择一个较小的委员会来处理共识，并将结果转发给整个副本网络。

Solana 的初步方法可以简单地分配一定数量的 CUs 来进行投票，在每个纪元中，由持有权益的验证者进入这些 CUs 进行分叉选择跟踪。其他验证者仍然可以投票并获得奖励，但他们的投票不会被纳入分叉选择。

投票账户

● 投票账户必须有足够的 SOL 来覆盖两个纪元的投票

● 投票交易必须是简单的投票

● 如果余额超过一个纪元的投票，允许从投票账户中提取 SOL

● 要提取所有 lamports，投票 CLOSE 指令必须要求经过整个纪元才能实现。投票账户在第一个纪元标记为 CLOSE，但只能在第二个纪元执行 CLOSE

CLOSE 允许提取所有的 SOL 并删除投票账户。一旦账户标记为 CLOSE，它只能被删除，不能重新打开

● 投票包含一个 VoteBankHash 而不是常规的 BankHash

Bank哈希

验证者使用与当前的 BankHash 相同的格式为简单投票交易计算 VoteBankHash，并忽略所有其他交易。这些 VoteBankHashes 包含之前的 VoteBankHash 而不是完整的 BankHash。

对于通过三分之二的超级多数乐观确认的区块，验证者还开始计算 UserBankHash，该哈希包括所有状态转换，除了那些已经在 VoteBankHash 中考虑的状态转换。

每个插槽都通过将 VoteBankHash、UserBankHash 和之前的 BankHash 组合来计算 BankHash。99.5% 的顶级验证者在每个第 100 个插槽中作为他们投票的一部分提交此 BankHash。另外，一些节点可以通过八卦网络广播 BankHash，以发出没有检测到非确定性因素的信号。

如果少于三分之二的验证者提交完整的 BankHash，那么领导者可能会将用户交易和可写账户的区块空间减少 50%，以防止可能会过度增加重放时间的利用。

为了建立下一个法定人数，状态只需每个纪元计算一次，确保共识节点和领导者保持同步。执行可以在与共识节点分开的机器上进行聚合和批处理。需要同步执行的用户（大多数应用和 RPC）可以专用硬件资源实时处理每个状态转换，而无需等待更广泛的网络。

考虑因素

提供实时状态数据的 RPC 提供者没有签名来验证他们本地计算的状态是否与更广泛网络计算的状态匹配。然而，一旦分叉被最终确认，网络将收敛到一个单一的、正确的规范状态，该状态可以以确定性的方式计算。为了尽量减少运行时错误或数据损坏的风险，旨在提供准确状态数据的节点应运行多个节点。如果检测到任何状态执行差异，应立即停止操作。

此外，用户可以提交主张 BankHash 或触发中止的交易。只有在计算的 BankHash 与用户通过其 RPC 提供者提供的 BankHash 匹配时，网络才会处理这些交易。

结论

Yakovenko 设想了 Solana 的一个大胆未来，区块时间降低到 120 毫秒，并且节点数量剧增，这得益于采用 AE。然而，实现这一未来需要将不同的客户端团队和更广泛的 Solana 开发者社区团结在这个愿景周围，并解决实施此类变更所面临的重大工程挑战。

社区中一些知名成员对这些提议的许多更改表达了担忧。Firedancer团队的 Richard Patel 警告说：“为区块生产者实施异步执行是相当复杂的，并且存在重大风险。”

虽然 支持 AE，但 Jito Labs 的 Zano Sherwani 批评了 MCBP，称：“多个并发提议者是一个糟糕的解决方案，它在寻找一个待解决的问题。它给协议带来的复杂性与其正在（即使是）试图解决的问题并不成比例。”

在 最近的一期播客 中，当被问及多个区块构建者时，Helius 的 Mert Mumtaz 回复：“我并不是完全相信。”

AE 无疑具有带来显著性能收益的潜力。缩短的区块时间将导致更快的确认和更好的用户体验，同时增强抵制审查的能力并减少交易重排的窗口。

然而，我们还必须仔细评估缺点，包括潜在的协议复杂性增加和对 RPC 提供者的更大依赖。在特定场景中，这些提供者可能是对链状态拥有最新、实时视图的唯一参与者。

AE 代表了 Solana 的一次重大升级。通过这篇文章，我们旨在提高 Solana 开发者社区对 AE 将带来的令人兴奋的变化的意识，并鼓励在这一重要主题上进行更有根据的讨论。

特别感谢 0xIchigo 和 Anatoly Yakovenko 对以前版本的审阅。

额外资源

• Solana 的共识 - Helius 博客
• Solana 执行总结 - Helius 博客
• 通往Bankless的道路 - A. Fitzgerald
• 异步程序执行 (APE) - A.Yakovenko
• 终局架构 - A.Yakovenko
• 异步程序执行和广播 (APExB) SIMD 0023

• 原文链接： helius.dev/blog/asynchro...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～