Optimistic Execution (OE) 是一种在 Cosmos SDK 链中提前处理区块的技术,旨在减少区块时间和提高效率。通过在共识层请求之前处理区块,OE 可以在 Sei Network 的负载测试中将区块时间缩短约 300 毫秒。OE 的实现现已在 Cosmos SDK 中提供,并将在 v0.50 版本中可用。
乐观执行使得 Cosmos SDK 链能够以突破性的速度构建区块,从而突破区块时间和效率的限制。
乐观执行(OE)指的是提前处理区块,以便在共识层请求时可以准备好响应的能力。 它是乐观的,因为我们甚至在区块可能在稍后阶段被拒绝的情况下就开始执行区块(但在大多数情况下,这被认为是罕见的)。
在 Sei Network 的负载测试中,乐观执行将区块时间缩短了约 300 毫秒。在像 Injective 这样快速生成区块的网络上,OE 可以帮助网络生成亚秒级的区块,而无需任何额外的努力。
OE 实现现在已在 Cosmos SDK 中提供,并且将在 v0.50(下一个版本)中提供。请查看 Cosmos SDK 的 RFC005 以获取更多信息。
在乐观执行之前,Cosmos SDK 应用程序会在 ABCI FinalizeBlock 的最后一步执行区块及其交易。这意味着调用 FinalizeBlock 的持续时间与区块的执行时间相同,导致应用程序仅在所有投票发生后的最后一步接收完整的区块提议。
Cosmos SDK - 没有乐观执行的 ABCI++ 流程。
随着 ABCI++ 的引入,应用层现在在投票期开始之前接收到区块提议。这可以用于与投票过程并行地乐观地执行区块提议,从而减少区块时间。
Cosmos SDK - 具有乐观执行的 ABCI++ 流程。
假设平均投票周期为 P,平均区块执行时间为 Q,这将使平均区块时间减少 P + Q - max(P, Q)。
Sei Network 在负载测试中报告 P=~600ms 和 Q=~300ms,这意味着乐观执行可以将区块时间缩短约 300ms。
我们希望随着更多链开始使用乐观执行,能够获得更好的统计数据。
CometBFT v0.38 引入了 [ABCI++](https://github.com/cometbft/cometbft/tree/v0.38.0/spec/abci),其中包括共识层和应用层之间的一些新调用。这带来了一整套应用程序可以利用的新功能。
其中一项新调用是 ProcessProposal,它允许我们对提议的区块执行依赖于应用程序的工作。这意味着我们可以提前访问提议区块的完整内容。
现在我们有了区块,我们可以继续乐观地执行它。我们通过在 ProcessProposal 中启动一个 goroutine 来提前执行 FinalizeBlock 来做到这一点。
现在 CometBFT 启动预提交轮次。这可能需要一些时间,具体取决于验证器集的大小、链是否启用了投票扩展以及节点的网络延迟。
一旦 CometBFT 在我们的应用程序上调用 FinalizeBlock,我们就等待 goroutine 完成并返回结果。在最佳情况下,goroutine 已经完成,我们可以立即返回其结果,在此函数调用中几乎不花费任何时间。
如果区块被多数人拒绝,而我们仍然运行了乐观执行,我们将中止并丢弃结果,然后重新开始。
我们在两个地方调用中止:
在这两种情况下,应用程序都将继续按预期运行,而不会出现错误或 panic。
当中止事件发生时,可能会给调用它的函数增加一些延迟。考虑到我们等待它完成(更多信息请参见“未来改进”部分),并且如果中止发生在 FinalizeBlock 上,我们将像在实现 OE 之前一样同步处理该区块。
注意:这些应被视为特殊情况,我们预计这种情况不会经常发生。
最坏的情况是节点在执行错误的区块时到达 FinalizeBlock。在这种情况下,应用程序将中止正在运行的 OE 并使用收到的区块重新开始。导致处理时间比以前的区块显着增加。
该团队正在积极探索改进乐观执行实施的途径。主要重点之一包括减少中止运行执行所需的时间以及其他潜在改进。
正如前几节中所解释的那样,在启动新的 OE goroutine 之前,我们需要中止前一个 goroutine 并等待完成。该团队将研究几种概念,以尽可能缩短此等待时间:
在 Cosmos SDK 中,为围绕乐观执行的改进展开讨论 做贡献。
- 原文链接: medium.com/the-interchai...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!