区块链 101：并行化执行
- Frank Mangone
- 发布于 7小时前
- 阅读 80
本文主要探讨了区块链中的并行化执行问题，并介绍了Aptos和Sui两个新兴区块链项目。Aptos通过乐观并行执行和Block-STM来处理冲突，而Sui则采用对象模型，通过区分owned object和shared object使用不同的共识机制，以实现更高的并行度和性能。这两种方案分别代表了在现有账户模型上优化和完全重新设计区块链架构的不同思路。
这是关于区块链的系列文章的一部分。 如果这是你第一次看到这篇文章，我强烈建议从本系列的开头开始阅读。
感谢上一期，我们对区块链系统设计中现有范式的了解增加了一倍以上。 我们的想法和概念的储备正在缓慢但肯定地增长——随之而来的是我们评估每种架构优缺点的能力。
当从如此广泛的可能性中选择要使用的区块链时，最重要的因素之一是速度。 我们希望我们的交易能够被快速处理——有时，我们愿意牺牲其他方面，例如去中心化，以换取更好的处理时间。
但理想情况下，我们希望尽可能少地牺牲。 因此，今天，我们将讨论一些现代方法，这些方法为这个老问题提出了新的替代方案。
系好安全带，让我们直奔主题！
并行化
在我们深入探讨之前，我认为有必要了解并行化的概念。 我们已经提到过几次了，但并没有非常精确地说明。 我相信现在是时候了。
每个区块链都经过多个阶段来推进全局状态：交易验证、共识、执行，以及可能还有最终性。
今天，我们将讨论在执行阶段中的并行化：交易运行时发生的实际计算。
重要的是要注意，系统中的其他过程也可以并行化，但我们将把这个讨论留到以后的文章中。
通过状态转换函数 (STF) 修改状态的交易。
本质上有两种方法可以执行：我们可以逐个处理交易，或者尝试同时执行多个交易。
顺序（逐个）处理有一个明显的好处：我们确保不存在冲突。 这很棒，因为我们不会最终得到一个混乱的不一致状态。
例如，我无法将 NFT 转移到账户 A，然后将同一个 NFT 转移到账户 B。 这没有意义，因为在第一次交易后，我不再拥有该资产了！ 这是旧的双重支付问题，我们需要不惜一切代价避免它——但可能存在其他类似的情况。
但有时，两个或多个交易可以是完全独立的，因为即使同时执行，它们也不会相互冲突。 这就是并行化的思想：通过一次执行多个交易来计算区块链的这种新状态。
像这样
在这一点上，我想重要的是要问自己：并行化到底有多重要？ 我们应该关心它吗？
性能瓶颈
嗯，正如我在介绍中简要提到的那样，高处理速度对于区块链的实现非常重要。
我们执行交易的速度直接影响网络的速度。 当然，这只是构成网络整体“速度”的组成部分之一（因为共识和验证仍然是必要的），但这是一个重要的组成部分，因为每个节点都需要执行交易才能确定它们是否是有效的状态转换。
尽管如此，由于整体共识有多个步骤，理想情况下，我们希望确定瓶颈在哪里，并尝试将我们的努力集中在优化所述步骤上。 例如，在以太坊中，共识最关键的部分是 attestation aggregation。 始终关注大局非常重要！
如果我们只允许顺序执行交易，那么实现高处理速度是具有挑战性的——那么为什么不并行执行所有内容呢？
问题是，要确定多个交易是否真正彼此独立并不总是那么容易。
如果我们看一下我们已经探索过的范式，那么像大多数基于 EVM 的帐户型区块链更难弄清楚这种独立性，因此它们选择不并行执行交易，而是采用顺序方法。 即使是 Solana，由于逻辑和状态的分离，它具有一定程度的并行化，但它也有其局限性。
在频谱的另一端，我们有 UTXO，它们更适合并行化。 每个 UTXO 都是一个完全独立和不可变的状态片段，它只会被消耗。 这很棒，但使得在混合中添加逻辑变得复杂——虽然像 Cardano 这样的一些解决方案提出了改进，但它们仍然有自己的其他限制。
因此，今天的问题是：还有什么可做的呢？ 这就是一些前 Meta 工程师进入我们故事的地方。
Diem 项目
早在 2019 年，Meta（当时的 Facebook）宣布了一个雄心勃勃的项目：一种名为 Diem（最初是 Libra）的全球数字货币。
不是几个月前 Twitter 丑闻 中的那个 Libra！
他们着手创建一个可以处理数十亿用户的区块链，其速度和可靠性与传统支付系统一样。
当时，这真的是一个挑战：现有的区块链架构根本无法处理如此规模。 即使是当时最快的区块链（可能是 EOS 和 Ripple，每秒处理数千个交易）也会在这些 Meta 工程师试图满足的负载下崩溃 —— Facebook 用户群的负载。
因此，他们决定从头开始。 在这样做时，他们不仅仅构建了一个新的区块链——他们构建了一种新的编程语言，专门为数字资产和并行执行而设计。 这种语言被称为 Move。
你可以使用非常详细的 Move Book 学习 Move。
比起语言本身，我们需要关注的是它如何提出一种关于区块链状态的新思考方式：数字资产被视为资源而不是账户中的数据。 实际上，你拥有可以四处移动和修改的独特数字对象。
你问，为什么这很重要？ 好吧，如果每个资产都是一个具有明确所有权的独特的对象，那么涉及不同对象的交易可以并行处理而不会发生冲突！
这是一个非常充满希望的前景…… 直到 2022 年不幸的事情发生，Diem 项目 在监管压力下崩溃 并被关闭。
从灰烬中
它可能在那里结束了，而且我今天可能不会写关于这篇文章。
幸运的是，这些想法背后的工程师确信他们有所发现，并决定克服困难。 他们没有默默地消失在夜晚，而是分散开来并组建了新的项目，并将他们的知识带走了。
这些项目现在被称为 Aptos 和 Sui，它们将成为我们今天的主角。
Aptos
让我们从最早推出的一个开始：Aptos。
第一个团队并没有偏离我们迄今为止探索过的想法太远：Aptos 是一个考虑到熟悉的帐户模型的区块链。
是的，我们值得信赖的老朋友！
但是等等…… 我们不是在 2 分钟前说过帐户模型不适合并行化吗？ Move 的全部意义不就是用资源替换帐户吗？ 有什么问题？
嗯...... Aptos 使用帐户，这是一个事实。 它确实利用 Move 的类型系统来实现更好的状态管理，但这更多的是开发人员体验细节。
话虽如此，我们知道一个基于帐户的系统在并行化方面会存在问题。 冲突将会发生，而丰富的类型系统对于缓解这种情况无济于事。
想一想：如果 Alice 和 Bob 同时尝试向 Charlie 的帐户汇款，那么肯定会发生冲突。 如果我们称 Charlie 的余额为“资源”或简单地称为“数据”都没关系 —— 两个交易仍在尝试同时修改同一件事。
那么 Aptos 是如何实现并行执行的呢？
乐观并行
Aptos 的解决方案在概念上很简单：它不是试图阻止冲突，而是拥抱它们。
当一组新的交易到达时，Aptos 不会仔细分析哪些交易可能发生冲突并按顺序处理它们。 相反，它采用了一种乐观的方法：它只是同时执行所有交易，并假设大多数交易不会相互干扰。 这是一个小小的信仰飞跃。
Weee~
现在，我敢打赌你的蜘蛛感官会刺痛：当冲突确实发生时会发生什么？
Aptos 使用他们称为 Block-STM（软件事务内存）的执行引擎。 该系统不断监控这些冲突情况。 当它检测到两个交易试图修改同一个帐户时，它所做的只是回滚它们，并以正确的顺序重新执行它们。
有点像拥有一个智能撤消功能。 就这么简单！
当一个块中的大多数交易真正独立时（这种执行策略的最佳情况），Aptos 可以实现惊人的处理速度改进，因为执行是真正并行的。 但是，也会存在许多交易冲突的最坏情况。 在这种情况下，由于所有的回滚和重新执行，系统以更接近顺序处理的方式运行。
有趣的结果是这种方法是自适应的。 在正确的情况下，网络将会快如闪电。
我发现从以乐观的方式执行交易的简单选择中出现这种属性非常棒！
Sui
现在让我们转换方向，谈谈 Sui，另一个从 Diem 的灰烬中诞生的项目。
虽然 Aptos 决定保留熟悉的帐户模型并使其与并行化一起工作，但 Sui 团队采取了一种完全不同的方法。 他们决定从头开始重新设计一切，以实现最大的并行化。
他们的设计非常激进：Sui 根本不使用帐户。
对象来救援
在 Sui 中，一切都是 对象。 你的代币？ 对象。 你的 NFT？ 对象。 智能合约状态？ 是的，对象。
Sui 的对象本质上是 Move 最初设想的完全实现的资源模型！
使用对象对于并行化具有很酷的好处 —— 但首先，我们需要粗略地了解它们是什么。 为此，让我们将它们与我们已经知道的模型进行比较：基于帐户和 UTXO。
- 一个帐户可能拥有多个对象，这些对象共同代表其整体状态。 因此，这是一种比帐户模型更精细或更细粒度的表示类型，并且更容易确定两个对象何时彼此独立。
- 与 UTXO 相比，区别主要在于可变性。 UTXO 可以被认为是一种不可变对象（只能创建或销毁），而 Sui 对象通常是可变的（除了本地 不可变对象）。
因此，在某种程度上，对象代表了这两种其他模型之间的最佳点！
UTXO 提供几乎完美的并行化（在执行方面），但过于僵化 —— 你只能使用它们，永远不能修改它们。 帐户是灵活的，但会产生瓶颈，因为多种类型的资产共享相同的帐户空间。 对象为你提供了两全其美：它们像帐户一样灵活，但像 UTXO 一样独立。
最重要的是：Sui 中的交易 提前声明了它们需要哪些对象 —— 并且由于它们的粒度，系统立即知道这些交易是否可以并行运行！
如果 Alice 的交易使用对象 A，而 Bob 的交易使用对象 B，那么它们可以同时运行而没有任何冲突！
令人印象深刻
在所有权方面，对象可以是：
更多关于此的信息，请参阅官方 Sui 文档。
Sui 中的大多数对象都是拥有的对象。 如果我们所说的一切还不够酷，那么这还有另一个强大的结果：涉及拥有的对象的交易可以比涉及共享对象的交易执行得更快！
Sui 实际上使用两种不同的共识类型，具体取决于你的交易触及的内容。 对于拥有的对象，Sui 只需要检查你的交易是否有效 —— 也就是说，你拥有这些对象，并且你没有进行双重支付。 一旦足够多的验证者同意你的交易有效，那么繁荣 —— 立即执行！ 无需等待并查看它应该相对于其他交易的顺序。
共享对象需要更仔细的处理，因为多人可能尝试同时修改同一个对象。 Sui 首先需要通过其 Mysticeti 共识机制确定交易的顺序。
因此，简单的转账和支付会在 不到半秒的时间内 完成，而更复杂的共享状态操作可能需要更长的时间，但仍然可以有效地工作。 大多数简单的区块链操作（如发送代币）在 Sui 中会感觉几乎是即时的。
当然 —— 在 Sui 中设计应用程序时，你需要考虑稍微不同的方式，但如果你愿意投入时间和精力，它确实是一个快速的区块链！
这两种方法代表了不同的理念。 Aptos 提出了使熟悉的模型更快，而 Sui 完全重新思考了该模型。 没有哪个是普遍更好的 —— 这取决于具体的用例。
对于简单的转账和支付，它们都很出色。 但是对于更复杂的协议和逻辑定义，其中使用了大量的共享状态，那么事情可能会变得复杂。 在 Aptos 中，性能可能会受到严重影响。 在 Sui 中，设计这些应用程序可能会变得过于复杂，并且更容易出错。
再说一次，没有完美的解决方案！
总结
Diem 项目的残余物无疑为区块链生态系统留下了一些有趣的东西：两种非常不同且丰富的并行执行方法。
特别是，这种面向对象的架构是我们设计模式集中一个有价值的补充，因为它恰好是现有范式（UTXO 和基于帐户）之间的绝佳中间点。
Aptos 和 Sui 都代表了在提高执行速度方面的重大进步，但它们并不是城里唯一的孩子。 区块链领域充满了创新方法，每种方法都采用了不同的哲学和技术路径。
一些项目侧重于单个链中的并行化，就像我们今天看到的那样。 其他人会问完全不同的问题。
因此，在我们的下次相遇中，提出这些棘手的问题，这将导致一些非常奇异的解决方案。
干杯!
- 原文链接： medium.com/@francomangon...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
