使用区块链的非阻塞两阶段提交

Non-Blocking Two Phase Commit Using Blockchain
Paul Ezhilchelvan, Amjad Aldweesh, Aad van Moorsel
Newcastle University
Newcastle upon Tyne, UK

摘要：尽管 2 阶段提交协议 (2PC) 仍然是分布式数据库管理的核心，但即使分布式系统保证了最苛刻的同步或与时间相关的要求，它也有一个可证明不可避免的阻塞漏洞。本文研究了通过使用支持执行用户定义的智能合约的区块链协调 2PC 来消除该漏洞。它表明，如果区块链也满足同步要求，则可以以适度的事务成本消除 2PC 阻塞。否则，尽管区块链是一个可靠的状态机，但消除 2PC 阻塞很可能是不可能的，这取决于托管数据库的集群是否同步。在不可能的情况下，实际后果并不那么严重：不必要的中止发生的概率很小。
关键词：原子提交、阻塞协议、区块链、智能合约、延迟界限、同步系统。

1 介绍

自 2009 年比特币问世 [1] 以来，加密货币引起了相当大的兴趣。随后，人们对比特币的底层技术区块链以及以太坊开发的智能合约产生了更大的兴趣，这些智能合约使用户能够在区块链上执行定制程序。加密货币领域之外的各种应用程序，例如金融 [13]、银行和能源贸易 [15]，一直在利用区块链和智能合约技术来增强其核心流程的问责制、可审计性和信任度。

本文研究使用这些技术来提高分布式数据库管理系统的可用性 [6]。准确地说，我们重新审视了一个众所周知的与原子提交相关的不可能结果 [7, 8]，并证明这些新技术在某些条件下可以帮助完成原本不可能的事情，并且新兴的区块链系统满足了所确定的条件。如果给定的区块链系统不能满足这些条件，我们断言不能完全排除这种可能性，即使区块链的许多理想特性可能会诱使人们做出更乐观的结论。因此，本文具有双重目的，即提出渴望的可能性和需要注意的陷阱。

当分布式系统中的多个进程执行数据库事务时，提交协议可确保在所有进程中提交或中止该事务执行的基本要求。 2 阶段提交协议（简称 2PC）由于其概念简单和易于实现而被广泛使用。然而，它很容易受到无进展或阻塞时期的影响。这个漏洞被证明 [7] 是不可避免的，即使是可以可靠估计延迟界限（例如，消息传输延迟）的异步系统，并且唯一可能发生的不良事件类型是进程崩溃。

我们定义了区块链系统同步的含义，并使用这样的区块链在 2PC 的执行中扮演特定的角色。由此产生的协议，称为带区块链的 2PC，被证明是非阻塞的。它还保留了 2PC 的原生结构，这使得提议的扩展很容易在遗留系统中采用。我们的贡献还包括基于以太坊的实施，以评估智能合约执行的成本，结果证明该成本很小。

我们接下来观察到一些区块链系统，通常是矿工可以自由选择组成区块的公共系统，可能不符合同步的条件。当使用的区块链是异步的时，我们证明如果托管数据库进程的分布式系统也是异步的，那么消除 2PC 阻塞是不可能的；如果后一个系统是同步的，它仍然是一个悬而未决的问题。

论文的结构和贡献如下。下一节定义了 2PC 解决的原子提交问题，阻塞和同步与异步系统。假设一个同步系统，第 3 节详细描述了传统版本的 2PC 协议，然后解释了 2PC 阻塞的原因。因此，它为第 4 节提供了基本背景，其中包含我们三个贡献中的两个：（i）详细介绍具有同步区块链的非阻塞 2PC，以及（ii）成本和正确性分析。最后的贡献在第 5 节，它证明了当区块链和分布式系统都是异步的时，非阻塞 2PC 是不可能的，然后从实际的角度讨论了这个结果。最后，第 6 节总结了本文。

2 原子提交问题

该问题是在一组分布式进程的上下文中指定的 Π = {P1, P2, . . . , Pn}, n > 1。一个进程Pi，1 ≤ i ≤ n，可以随时崩溃，并在任意时间后恢复。崩溃前记录在磁盘中的信息在崩溃中仍然存在。在任何给定的情况下，都有两个互补的 Π 子集，崩溃的和操作的。对于讨论，我们假设前者很小并且是 Π 的严格子集。

每个操作过程自主评估可以是或否的投票。问题是让进程决定是提交还是中止，但要遵守以下四个要求 [9]：

• Agreement：没有两个进程做出不同的决定；
• Termination：所有运行的进程都做出决定；
• Abort-Validity：如果某个进程投反对票或根本不投，中止是唯一可能的决定。并且；
• Commit-Validity：如果每个流程都可操作并且投票赞成，则提交是唯一可能的决定。

Agreement 要求任何两个已决定的过程，无论是崩溃的还是运行的，都必须做出相同的决定。比如说，Pk 决定提交并立即崩溃；然后没有其他进程可以决定中止，即使除了 Pk 之外的所有进程都在运行并推断 Pk 已经崩溃。通过 Termination，任何解决方案都保证在实践中是有意义的。

Abort-Validity 允许没有投票的过程，不行使投票权。提交有效性排除了琐碎的解决方案，例如所有进程都强制决定中止，而不管他们的投票。正如我们将在第 5 节中看到的，这两个要求一起使得即使在基于区块链的解决方案中，当使用的最坏情况延迟估计不能保证成立时，也无法保证原子提交。

观察到原子提交的任何重要解决方案都需要 Π 的操作进程在它们之间进行交互——导致去中心化协议，或协议协调器 C——导致集中版本。广泛使用的 2-Phase Commit (2PC) 协议是一种集中式协议，将成为我们的重点。 （在实践中，C 的角色通常由 Π 中的指定进程扮演。）

定义：如果可能存在进程无法决定直到崩溃进程的子集应该恢复的执行，则原子提交协议被称为阻塞。因此，阻塞是不可取的，因为通常数量较大的操作进程的进度由崩溃进程的恢复时间决定。如果保证永远不会阻塞，则协议是非阻塞的。是否可以有一个非阻塞的原子提交协议取决于分布式系统是同步的还是异步的 [8, 9]。

2.1 同步与异步系统

定义：如果可以可靠地估计处理延迟和进程间通信延迟的界限，则称分布式系统是同步的；否则，它被称为异步 [8, 9]。

通常，延迟可以任意波动并因此具有很大差异的分布式系统被归类为异步。请注意，同步系统中的边界估计可能很大（通常是最坏情况估计），但必须是有限的。

众所周知，非阻塞原子提交在异步系统 [8] 中是不可能的，除非后者通过以某些可取的方式表现来强制每次执行（参见 [9]）。但是，可以在同步系统中进行非阻塞原子提交；直觉上，原因如下。同步系统中可靠的边界估计可以使用超时实现完美的崩溃检测：始终检测到崩溃并且永远不会错误检测到操作过程（没有误报/误报）。尽管如此，即使在同步系统 [7] 中，2PC 也是一个阻塞协议，即，即使托管 Π 的集群支持可靠估计延迟边界，从而完美的崩溃检测！

2.2 同步与异步区块链

我们观察到这种同步与异步分类对于基于区块链的系统与传统分布式系统一样适用。 （定义在第 4.2 节中。）在公共分类账系统中，例如以太坊，有效事务被确认或不可逆转地置于区块链中所花费的时间由各种容易延迟的因素决定 - 人类和系统有关的。例如，矿工（不）愿意在其区块中包含事务 [12] 属于前一类，而确保区块链线性度和传入事务率所需的后续块数量等因素属于后者。

根据 [12]，交易的以太坊区块链确认时间可能是无限的，这表明区块链基础设施内的端到端处理延迟存在很大差异。另一方面，许可的账本系统（例如，HyperLedger [14]），以及在专用机器上对共识协议（例如，[10]）的强化模块化实现，似乎承诺交易确认的延迟具有较小的平均值（在毫秒的数量级）并且方差也很小，因此可以可靠地限制，从而使此类系统成为同步分类帐的候选者。

本文的一个重要贡献是表明，如果正在使用的分类帐系统和 Π 的集群托管过程是同步的，则 2PC 可以成为非阻塞的。

3 同步系统中的 2PC

2-Phase Commit 协议，简称 2PC，在下面的数据库事务上下文中解释 [6]。数据库的分片分布在 Π 中的进程上。我们假设一个容易崩溃的进程（称为协调器并表示为 C）启动一个多分片事务，该事务要求 Π 中的每个进程在各自的分片上执行一组可序列化的操作。我们指的是 Cas 的启动，Π 中的每个进程都从 C 中获取工作。

令 ω 和 δ 分别表示任何操作 Pi ∈ Π 完成其工作所需的时间和任何两个操作过程之间的消息传输延迟的上限估计。由于假定系统是同步的，ω 和 δ 始终成立。

C 传播工作并等待 (ω+δ) 持续时间的超时，这足以让任何操作 Pi 接收并完成分配给它的工作。在超时到期时，它通过向所有进程广播投票来启动 2PC 的执行——如图 1 的第 1 阶段第 1 行所示。然后设置 Δ = 2δ 的计时器并进入第 2 阶段的工作。在做这项工作时，Pi 要么完成它并将其投票设置为 Vi = 1，要么决定无法以可序列化的方式完成工作并将 Vi = 0。在后一种情况下，通过 Abort-Validity 属性，Pi 可以推断出决定或裁决中止，即事务将在系统范围内中止；因此，它退出执行 2PC，如图 1 中 Pi 的 Phase 1 的第 1 行所示。

如果 Pi 已设置 Vi = 1，它会等待接收投票。如果直到 Ti 才收到投票消息，Pi 假设 C 已经崩溃，决定中止并退出其 2PC 的执行。另一方面，如果投票由 Ti 到达，Pi 通过记录其投票 Vi = 1 继续在 2PC 中，将 Vi 发送到 C 并继续进行阶段 2。

请注意，虽然给定的 Pi 可能会或可能不会进入阶段 2，但 C 总是如此。当它的 Δ-timeout 到期时，C 将任何 Pk 的缺席投票计数为 Vk = 0；它决定提交判决，如果 Vi = 1, ∀i : 1 ≤ i ≤ n，中止判决，否则。决定的判决被记录并广播给所有 Pi。 （参见图 1 的第 2 阶段）。

执行阶段 2 的任何 Pi 等待来自 C 的判决并定期请求 C（根据计时器值），如果判决未到来。这个周期性请求将提示崩溃的 C 在其恢复后通过引用它在崩溃之前记录的判断来响应。如果没有记录任何判决，则 C 是在计算判决之前崩溃的；在这种情况下，C 的响应将中止。

同样，如果 Pi 在向 C 发送 Vi = 1 后崩溃，它会在恢复后观察 Vi = 1 的日志条目并请求 C 发送判决。因此，所有可操作的进程，包括那些在执行期间崩溃和恢复的进程，都决定 - 确保终止。不难看出，原子提交的其他三个要求在 2PC 中也得到了满足。

图 2 描绘了任何 Pi 的状态转换图，其中圆圈表示状态，双圆圈表示终止状态；状态转换由带有标签 I O 的单向箭头表示，其中 I 表示 Pi 接收的导致转换的输入，O 表示转换后 Pi 产生的任何输出。 （‘-’ 表示空输出。）WG,W1 和 W2 表示 Pi 正在执行给定工作的状态，等待投票（见图 1 中的第 1 行，第 1 阶段）和判决（图 1 中的第 1 行，第 2 阶段） 1 分别表示；a 和 c 分别表示 Pi 中止和提交的状态。

3.1 2PC 阻塞的必然性

虽然 Skeen [7] 正式证明了这种必然性，但我们通过展示 2PC 的三种不同执行场景来直观地理解其原因。

场景1：在2PC的这次执行中，C在广播 cast 投票后立即崩溃，所有 Pi 投票V = 1。每个 Pi 都被阻塞，直到 C 恢复。假设通过使用恢复协议来避免阻塞，该协议使操作进程能够在它们之间进行交互并在不等待崩溃恢复的情况下做出裁决。接下来的两个场景证明不存在正确的恢复。

场景 2：与场景 1 一样，除了一个 Pk 无法完成其工作，决定中止然后崩溃。如果存在正确的恢复，所有可操作的 Pi，i ≠ k，必须在不等待 Pk 和 C 恢复的情况下决定中止。

场景 3：在这个执行中，C 广播投票，allPi 投票 V = 1 并且 C 崩溃发送verdict = commit 只给 Pk，在 logging 收到的判决后很快崩溃。如果存在正确的恢复，所有可操作的 Pi，i ≠ k，必须在不等待 Pk 和 C 恢复的情况下决定提交。请注意，所有可操作 Pi 的执行环境都是相同的，i ≠ k 在两种情况下，但达到的判决应该不同；因此，无法设计正确的恢复。

4 区块链非阻塞

4.1 方法

我们可以观察到，如果 C 在 2PC 执行期间永远不会崩溃，那么阻塞就不会发生。我们通过让 C 通过将工作委托给所有 Pi 来启动事务，然后将 2PC 协调职责委托给区块链基础设施（简称 BC），作为复制状态机，将在崩溃时协调 2PC 执行，以此来建立这一无崩溃的方式。为了实现这一点，将利用 BC 的几个方面，它们在下面列出。

事件排序。针对 BC 的事件也称为事务。 BC 对这些事件进行总排序并按该顺序记录它们；事件记录是不可变的，记录的事件对所有相关方都是永久可见的。 BC 中的事件排序也可用于确保仅执行一次操作，例如，当多个源（例如 Π 中的进程）可以请求 A 执行时：A 可以对 BC 进行编程（参见下面的智能合约）以仅接受第一个按总顺序请求并忽略重复项。

Wall Clock。有序事务首先排列在固定大小的块中，然后按照块时间戳的递增顺序排列在 BC 中。假设事务不断向 BC 提交，正在添加的区块的时间戳增加构成了一个公开可见的实时挂钟（可能带有不规则的滴答声）； Π 的进程可以将其用作公共时间服务。

Smart Contract。它是存储在 BC 中并由 BC 运行的计算机程序，以响应嵌入在有序事务中的函数调用。保证执行正确且可公开验证。智能合约具有唯一的地址，并被构造为确定性函数的集合。合约代码是用 Serpent、LLL 或 Solidity 等语言编写的（我们在第 4.5 节中选择）。该代码被编译成字节码，该字节码将由 BC 组件（例如以太坊虚拟机）进行解释。

Ethereum [2]。它是支持智能合约技术的最流行平台，并在我们的实施中使用（第 4.5 节）。用户进程（例如 C）可以通过启动事务来在 BC 中部署智能合约，该事务的数据字段包含智能合约的字节码，并带有适当初始化的参数。一旦该事务在 BC 中被接受，任何命名进程（例如 Pi）都可以通过提交事务来调用合约函数。调用事务由 (i) 指向合约地址的接收者地址和 (ii) 函数调用的参数值构成。此外，在以太坊中，一个事务还包括两个字段；GAS 和 GAS PRICE [2]。将区块添加到 BC 的矿工将使用 GAS PRICE 将消耗的 GAS 数量转换为以太坊的本地货币 Ether。因此，调用事务的发送者需要为执行合约付费。

4.2 同步区块链

类似于 ω 和 δ 的定义，令 β 是在用户进程 U 启动有效（区块链）事务 T XU 时的实例与包含 T XU 的块（不可逆）时的实例之间可能经过的延迟上的块构造界限在 BC 中添加；令 α 是 T XU 不可逆转地进入 BC 的实例与任何相关方在 BC 中知道 T XU 的实例之间可能经过的延迟的意识界限。如果 BC 基础设施（连同矿工/共识节点）支持对有限 β 和 α 的可靠估计，我们将其称为同步的；否则，就说它是异步的。

同步 BC 的假设意味着满足了几个要求：提交给 BC 的有效事务永远不会丢失，但总是被考虑及时进入 BC，对给定 T XU 感兴趣的一方定期扫描 B​​C，等等.（就像 δ 边界的有效性要求没有消息丢失，但每条消息都被及时排队、传输、接收和传递——所有这些都是及时的。）请注意，同步 BC 要求底层分布式系统是同步的。

4.3 2PC 与同步区块链

我们在这里解释 (i) C 如何将 2PC 执行的协调责任移交给 BC 基础设施，以及 (ii) Pi 如何与 BC 交互以执行 2PC，即登记其投票然后接收verdict。

与传统的 2PC 一样，C 将工作分发给每个 Pi ∈ Π；然后它通过启动 (BC) 事务 T XC 将责任移交给 BC 基础设施，该事务在 BC 中设置 2PC 协调智能合约，初始状态 = VOTING。 （智能合约代码在 § 4.4 中解释。）C 的角色以启动 T XC 结束。注意，C 可能会在工作传播后和启动前崩溃 T XC ;在这种情况下，所有可操作的 Pi 都必须检测到这一点并最终决定中止，就像传统的 2PC 执行一样。

当 Pi 收到来自 C 的工作时，它计算 Ti 作为本地时间，当最大持续时间为 {ω, δ + β + α} 时，将在收到工作后过去。如果 C 已启动 T XC ，Ti 是 Pi 可以完成其工作并意识到 T XC 被添加到 BC 的最早本地时间。

因此，如果 T XC 直到添加了一个时间戳 > Ti 的块才出现在 BC 中，即，直到 BC 挂钟超过 Ti，然后，通过同步假设，Pi 可以推断出 C 崩溃 没有启动 T XC ；它可以随后中止，如图 3 中从 W1 到 a 的状态转换所示，其中 WC 表示 BC 的 Wall Clock。图 3 中状态 W G 的转换与图 2 中所示的相同。它们在这里已成为链下活动 [11]。

如果一个 Pi 完成了它的工作（图 3 中的 WG → W1），在本地时间 Ti 之前知道 T XC，它在本地记录 Vi = 1（如图 1 的阶段 1）通过启动 T Xito BC 注册它的投票.当 T Xi 在 BC 中被接受时，它以 Vi = 1 作为输入调用智能合约的 V OT ER 函数。 （Pi 的状态现在从图 3 中的 W1 过渡到 W2）。

令 T XC .BlkTime 为包含 T XC 的区块的时间戳。任何可操作的 Pi 不迟于 W C = T XC .BlkTime + α 和它的 T Xi 知道 T XC 作为响应，将通过 W C ≤ T XC .BlkTime + α + β 添加到 BC。 （注意：α 和 β 是上限，实际延迟可以小于它们。）

如果所有 Pi 投票 Vi = 1，则智能合约将计算 verdict = commit 并显示 state = COMMITin BC。 （详见第 4.5 节。）所有 Pi 通过 W C ≤ T XC .BlkT ime + 2α + β 观察到这个状态。

令 Δ = 2α + β。当 W C 超过 T XC .BlkTime + Δ 时，如果发送 T Xi 的操作 Pi 在 BC 中看不到状态 =COM M IT ，则某些 Pk 没有启动 T Xk 。在这种情况下，Pi 可以安全地决定 verdict = abort。但是，我们这里的描述假设 Pi 仅响应 BC 中指示的内容来决定 verdict = commit 或 abort，以与传统的 2PC 描述保持一致。

当 W C > T XC .BlkT ime+Δ 且状态 ≠ COM M IT 时，Pi 启动 T XVi 调用智能合约的 VERDICT 函数，从而计算并显示在 BC 中的裁决。在图 3 中，Pi 在启动 T XVi 后执行 W2 → W3，然后在 BC 指示 state = ABORT 时执行 W3 → a。如果启动了几个 T XV，则只有一个将有效执行 V ERDICT（如第 4.1 节中的 A）。

4.4 智能合约伪代码

表 1 显示了 2PC 协调智能合约的伪代码及其三个函数，分别称为 (i) REQU EST () 由 T XC 调用以初始化合约，(ii) V OT ER() 由 T Xi 进入Pi 在 BC 中的投票，以及 (iii) VERDICT () 由 T XVi 请求计算判决。

这里的描述假设如下。合同已经部署在具有唯一地址的区块链上。它有一个初始状态 IN IT ，具有三个参数 Timeout（初始化为零），一个初始空集 A 的命名参与者和一个空集 V 的投票参与者；其函数有以下接口：REQU EST (A, Timeout)、V OT ER(boolean)和V ERDICT()。

C 提交的 T XC 调用具有 (A = Π, Timeout = Δ) 的 REQU EST 函数，其中 Δ = 2α + β。如果 C 被断言拥有调用此函数的所有权并且代码处于初始状态 INIT - 如 Assert 语句中所示，则此初始化成功。如果此断言成功，则 T XC 被接受，合约状态更改为 V OT IN G，这在 BC 中是公开可见的；否则，忽略 T XC。 （情况总是如此：如果调用前断言失败，T X 将被拒绝；在整个描述中，假定断言成功，但对 VERDICT 函数的重复调用除外。）

W1 中的每个 Pi 检查 BC 是否有 T Xc；当 state = VOTING, Vi = Y ES 通过提交调用 VOTER 函数的 T Xi 发送。收到 T Xi 后，合约断言 Pi 是否合法投票。当 Pi 合法时，Pi 被记录为在集合 V 中投票。如果 V = Π，则合约状态更改为 COMMIT。

在 W C = T XC .BlkTime + Δ 之后，W2 中仍然发现状态 = VOTING 的任何 Pi 通过提交 T XVi 调用 VERDICT 函数。仅当 (i) Pi ∈ Π，(ii) Δ = 2α + β 的足够时间自 T XC 被添加到 BC 和 (iii) state = VOTING 时，调用才会成功。如果成功，它会设置 state = ABORT。当 state = COMMIT 或 state = ABORT 时调用 VERDICT 的尝试将不满足 (iii) 且不会成功。

4.5 实施

我们在 Solidity 0.4.10 [4] 中实现了 2PC-Blockchain 合约，并使用 Geth [3] 在以太坊私有网络上对其进行了测试。实验在配备 2.8 GHz Intel i5 CPU 和 8 GB RAM 的 MacBook Pro 上运行。

用一个 C 和两个 Pi 完成了两个实验。首先，两个 Pi 都投了票。结果是状态被设置为COMMIT。在第二个中，只有一个 Pi 投票，并且在 W C =T XC .BlkT ime+Δ 之后，投票的 Pi 发起了一个事务，该事务调用 VERDICT 函数来获得判决，从而将状态设置为 ABORT。

在表 2 中，我们展示了创建和执行 2PC-Blockchain 合约的成本。成本以 2PC-Blockchain 合约中每个函数消耗的 GAS 数额换算成美元。我们在所有事务中使用最便宜的 GAS PRICE（即 2 × 10−9 以太币），汇率为 1 以太币 = 830.61 美元。可以看出，使用智能合约实现非阻塞 2PC 的财务成本很低。

4.6 同步BC的2PC是非阻塞的

之所以如此，有以下三个原因：(i) 包括 Π 和 BC 的整个系统是同步的，即从未违反边界 ω、δ、β 和 α (ii) BC 没有崩溃，以及 (iii) BC随着新交易（包括 2PC 执行之外的交易）被假定为不断提交给 BC，挂钟继续滴答作响。因此，如果 C 启动 T XC ，则永远不会出现某些 Pi 在 Ti 之前在 BC 中看到 T XC 而另一个 Pj 在 Tj 之后看到它的情况。

从（非）阻塞的角度来看，只存在两种情况：Cdoes 或 does not launch T XC 。考虑前者；图 3 中以蓝色显示的所有转换都是由于 Pi 在及时环境中与 BC 交互，并且必须在有限时间内发生，除非 Pi 本身崩溃。另一方面，如果 C 在启动 T XC 之前崩溃，则即使在 W C > Ti 之后，所有已完成工作的操作员 Pi 也会检测到 T XCin BC 不存在。因此，他们都单方面地，也同样地，决定中止，即从图3中的W1转移到a，而无法完成工作的则从WG转移到a。因此，有效的 Pi 不能阻塞。

5 异步区块链

当边界 α 和 β 无法可靠估计时，BC 变为异步的。这可以使基于 BC 的 2PC 的正确性的两个关键特征无效：（i）对于所有操作 Pi：如果 BC 不添加 T XC 最新 W C = Ti，则 C 崩溃，以及（ii）提交有效性：verdict = commit 当所有 Pi 在 V ote = 1 的情况下启动 T Xi。当 T XC 进入 BC 所需的时间比估计的边界长得多时，(i) 就会失效；类似地，(ii) 当 T Xj 从 Pj 进入 BC 的时间如此延迟以至于 state = VOTING 甚至在 W C > T XC .BlkT ime + Δ 和来自 somePi 的 T XVi 之后，(ii) 不满足，i 6 = j，同时使 BC 计算判决作为中止。

请注意，即使底层分布式系统是同步的，公共 BC 也可以是异步的。例如，如果矿工在 T XC 启动时还遇到其他几项与 T XC 相比在财务上更具吸引力的交易，那么 T XC 可能需要更长的时间才能进入 BC，如果有的话，比任何 β 估计的在更有利的环境中 [12]。这提出了两个有趣的问题：如果使用的 BC 是异步的并且托管 Π 的集群是 (1) 同步的，我们能否有一个非阻塞的 2PC 和（2）异步？ (1) 的答案是开放的，尽管我们相信它可以是肯定的，而 (2) 的答案是肯定的。

不可能。当 BC 和集群都托管时，不可能有一个非阻塞 2PC 协议，其中协调器 C 将其协调职责卸载到 BC ，当 BC 和集群托管 Π = {P1, P2, . . . , Pn} 是异步的。

证明（通过矛盾）。让我们首先观察一下，由于集群是异步的，操作 Pi 无法完美检测到 Pk 的崩溃。为了简化证明，让我们假设 C 永远不会崩溃并且总是将 2PC 协调职责卸载给 BC。因此，如果无限期等待，任何 Pi 肯定会在 BC 中观察到 T XC。 （注意：如果通过有效的简化证明不可能成立，那么当后者不适用时，它也必须成立。）

相反，让我们假设不可能的声明是不正确的，并且存在一个非阻塞 2PC 协议 P。考虑 P 的两次执行，其中 (i) 除了第一次执行中的 Pk 之外，每个进程都是可操作的并且想要提交，以及 (ii) 如果给定的 Pi 在执行中有效，则它会及时观察到 BC 中的 T XC，即在其本地时间 Ti 之前，并启动 T Xi。

执行 1：Pk 执行 W G → a 然后崩溃。此外，在 Pi 的本地时间超过 Ti + D 之前，Pk 不会在此执行中恢复。根据 P 的假设，Pi 必须在此处决定中止，尽管 Pk 在 Ti + D 之前仍然崩溃。

执行 2：Pk 不崩溃并启动其 T Xkat 本地时间 Tk 。 T Xk 直到 Pi 的时钟读取 Ti + D 后才进入 BC；这是可能的，因为 BC 是异步的。此外，Pk 发送的任何消息直到 Pi 的时钟读取 Ti + D 后才会到达其目的地；这也是可能的，因为数据库集群也是异步的。

对于任何 Pi，i 6 = k，执行 2 与执行 1 直到其时钟时间 Ti + D 都无法区分。因此，与执行 1 一样，Pi 必须在 Ti + D 之前决定中止。这违反了上面的 (ii)，这也是提交有效性要求。 （见第 2 节。）因此，关于 P 的假设是矛盾的，并且证明了不可能性。

5.1 实践中的不可能

仔细研究证明表明，异步只能防止提交有效性得到保证。当违反延迟界限估计时，满足其他三个要求。在实践中，可以以合理的准确度估计边界 α 和 β，它们具有很高的概率，例如 p。因此，在概率 (1 - p) 的情况下，T Xk 将如此延迟，以至于在 T Xk 进入 BC 之前，判定被计算为中止；如果所有其他 Pi 也投了赞成票，则该判决应该已经提交。类似地，如果 T Xc 被过度延迟，将在同步可能导致提交的地方决定中止。因此，如果 T Xcan 和 n T Xi 是及时的，则不能不必要地决定中止，这以概率 p(n+1) 发生；因此，假设 n = 4 且 p = 99%，则 1 - p(n+1) = 5% 是事务被不必要地中止的概率。

6 结束语

避免 2PC 阻塞的流行选择是使用 3 阶段提交。我们在这里展示了不需要额外的阶段，并且可以通过同步区块链来协调同步集群中的阻塞 2PC执行。如果区块链和集群都是异步的，前者的无崩溃不足以消除阻塞。我们认为 eVoting（即使没有隐私问题）比非阻塞提交更难，并且其区块链实现（例如 [16]）必须需要一些同步保证才能正确。