最近在Cardano上启用的智能合约导致了用户活动的大幅增加。同时，由于代码携带的脚本交易，平均交易规模也在增长。随着第一批去中心化金融（DeFi）应用程序现在部署在 Cardano 生态系统上，以及更多的应用程序在路上，我们预计这一趋势将继续下去。为了跟上这种高涨的需求，系统目前的交易吞吐量必须增加。
增加交易吞吐量的一个明显方法是增加区块大小的限制，以适应每个区块更多的交易。今年，区块大小已经增加了25%–从64kB到目前的80kB，而且我们预计还会进一步增加。然而，如果要将区块生产速度保持在目前的水平，分类账-共识协议能够安全地维护多大的区块是有限制的。为了在不影响系统安全的情况下实现高吞吐量，需要采取额外的措施。为了了解原因，我们需要仔细看看分类账共识的一般工作方式。
账本共识协议的特点是有两个时间参数。
Δp，一个新区块到达（例如）95%的网络的最大网络延迟，和
Δb，生成两个新区块之间的（预期）时间。
在典型的协议中，为了论证共识的一致性，先前区块的传播必须在下一个区块产生之前完成–至少在大多数时候。因此，Δb被选择为比Δp大一些。在Cardano，我们有Δp=5s（秒）和Δb=20s。
现在，在这些条件下，一个区块可以传输多少数据？要看到这一点，我们需要更详细地研究在Δp内到底要实现什么。
图1. 在Δp=5s预算内的块状网络扩散和验证
考虑到上面的图1，以简化的方式描述了区块传播在网络中的运作。区块生产者将他们的新区块头发送给对等者1（白色h型框），在白色h型框所示的时间跨度内占据了两个节点的网络链接。对等者1然后验证头（在灰色hv-box所示的时间跨度内涉及本地计算）。如果头是有效的，即头证明了合格的区块领导，等等，区块主体由对等者1下载（白色b-box），再次占用两个节点的网络链接。最后，对等体1验证区块主体（灰色bv-box），只有在区块主体也有效的情况下，对等体1才准备按照刚才描述的思路将区块传播给其他对等体。
这种操作模式的一个不幸的副作用是，单个节点的CPU和网络链接只在Δp=5s的一小部分时间内被利用，而在（预期的）Δb=20s的其余时间内保持（大部分）闲置。
具体来说，我们能装入一个区块的数据量由区块的点对点网络延迟和所需的验证时间决定。这两点在区块的大小上大致呈线性增长–乘以到达95%的所有节点所需的最大跳数。测量表明，为了保证在Δp=5s内的网络传播，块的大小不应超过2MB。考虑到计算量大的脚本，验证时间甚至可能强加一个更低的限制。
好消息是，在这些约束条件下，交易吞吐量可以通过应用点对点网络和/或共识层的变化而被超过。我们在下面解释这些技术。
扩散管道化
重新考虑图1，我们看到所有节点的行动都是严格按照顺序进行的，因此Δp需要适合单个节点所需的时间乘以对等路径中的跳数。我们观察到，虽然这对网络传输是必要的，但对区块验证却不是。
考虑一下图2。通过允许区块在完全验证之前被传播，我们可以从传播路径中排除（重复的）主体验证。只要对等体1收到块体（b-box），它就可以开始传播块，同时验证块体，等等。
与图1中的方案相比，现在的Δp预算只需要考虑一次主体验证。这导致对等网络传输和/或主体验证的时间预算增加，从而允许更高的交易吞吐量（为了便于与图1比较，这一收益由更大的主体验证（‘bv’）预算来说明）。
由于下面解释的原因，以下两个验证检查在传播路径中保持完全复制是至关重要的。
头部正确性，即区块正确引用其前身，以及正确的区块领导（可验证随机函数（VRF）和区块签名验证）。
块的完整性，即收到的（但尚未验证的）主体确实被头的主体哈希所引用。
扩散管道（如上所述）会如何影响共识层和网络层的安全？
首先，请注意，共识层仍然不受这种变化的影响。
诚实的区块总是有效的，因为区块领导完全验证了将被新区块追加的链以及新区块本身，而且。
不完整的区块不会被传播（由于上述第2点），并且。
无效的（完整的）区块，尽管可能通过网络传播，但总是被诚实的节点在主体验证后丢弃。
第二，关于网络层的拒绝服务（DoS）攻击，请注意，对手可以通过传播无效区块来试图使系统拥挤。然而，正确的区块领导权仍然被验证（由于第1点），意味着这样的区块只有在对手预定的情况下才会被传播，也就是说，不会比这个区块领导权是诚实的情况下产生更多的负载（除了区块对系统的吞吐量没有贡献）。此外，产生无效区块的赌注池操作员（SPO）可以很容易地被识别和惩罚，事实上，目前正在开发一个违规管理系统，正是为了执行这一功能。
总而言之，扩散流水线在Δp限制内增加了区块传播和验证时间的预算，允许更大的区块，从而提高交易吞吐量–同时保持共识规则不变。它有望大幅提高吞吐量，同时可以通过对系统进行最小的侵入性修改来实现，因此是短期内实施的最佳候选方案。尽管如此，流水线（单独）的影响是有限的，而且我们的雄心并没有就此停止。
接下来我们将总结一种更强大的技术，它可以实现更高的交易吞吐量，但也需要一些更引人注目的协议变化。
异步验证
扩散流水线背后的想法–延迟的主体验证–可以发挥到极致：一个新的区块仍然需要在Δp内到达，但是我们不要求它的主体验证在Δp内完成。我们把这称为异步验证（AV）。
考虑一下图3。身体验证被允许基本上消耗剩余的（预期的）Δb预算（除了块传输和头验证），从而实际上使节点的CPU处于永久负载状态。然而，请注意，网络链接和CPU也被分配给其他任务（如mempool同步），这意味着我们不希望将Δb的全部剩余部分用于身体验证，而是留下几秒钟分配给这些其他任务。
这有一个显著的副作用。与扩散流水线相比，账本验证通常会滞后于链头。特别是，即使是诚实的区块负责人现在也可能创建（部分）无效的区块，因为他们可能还没有完成对新区块之前的交易历史的验证。
为了应对这种副作用，需要对账本规则进行调整：为了保证诚实的区块总是有助于共识的安全，携带无效交易的区块仍然必须被视为有效的链上扩展。然后，无效的交易可以在分类账验证期间简单地被丢弃。
尽管比起扩散管道，AV有很大的改进，但还可以进一步改进。原因是，一般来说，在Δp期间，没有足够的数据可以被扩散，以产生足够的验证工作，在Δb期间的全部剩余时间内，CPU会达到最大。为了充分发挥AV的优势，我们将把它与输入代言人的机制结合起来，我们将在接下来的博文中描述这个机制。
影响
我们可以预期流水线和AV对吞吐量有什么影响？找到这个问题的精确答案仍然是我们的网络和研究团队正在进行的工作，因为在恶意对手（试图最大限度地破坏协议）的情况下给出一个严格的分析是相当复杂的。不过，为了提供一个初步的估计，我们在下面给出了所有SPO行为诚实的乐观情况下的吞吐量分析–期望恶意情况下的结果不会有很大的偏差（考虑到违规管理系统的存在）。不过，请注意，系统的实际吞吐量可能会与给定的估计值有所不同。
在表1中，我们列出了这些吞吐量的估计值（以每秒交易量为单位，TPS）。回顾一下，吞吐量既取决于交易规模，也取决于验证时间。对于选定的交易规模/验证时间对，我们假设所有的交易具有相同的特性，并给出各自的吞吐量数字。我们比较了四个不同的协议。
Praos。Cardano目前部署的协议（区块大小为80 kB）。
Praos Max: Praos的最大可能的区块大小，可以安全地保持（在上述假设下）。
扩散流水线
AV（将20%的Δb预算打折，并保留给不同的任务）
我们考虑四种不同的交易类型，其规模和所需的验证时间各不相同。一个简单的支付交易接近0.5 kB / 0.5 ms的范畴，而脚本交易可能属于其他类型中的任何一种，这需要更大的尺寸和更多的努力来验证。请注意最后一栏(2 kB / 32 ms)，与网络延迟相比，验证时间变得相当长。增加块的大小（从Praos到Praos Max）无助于提高吞吐量，因为验证已经达到了时间预算的最大值。因此，流水线和AV正是在这些情况下提供了强大的相对收益，因为它们增加了验证时间预算。
Cardano的前景
增加无权限区块链的吞吐量是安全的关键，因为向系统接纳更多的负载可能会引入DoS攻击的机会。因此，在仔细观察对系统的影响的同时，最好以一连串的小步骤进行这种改变。
去年12月和今年2月，我们采取了第一批这样的措施，将块大小的限制（和Plutus脚本的内存单元）从64kB提高到80kB（参见John Woods最近写的博客）。
在未来几个月里，我们将继续密切关注并根据网络需求和容量限制来调整这些参数。随着扩散流水线的实施，将会有进一步的改进。其他的共识优化，包括输入赞同者，仍在开发中，关于如何执行这些的更多细节将在适当的时候宣布。
请注意，Cardano Basho时代的优化努力超出了网络和共识层，并包括Plutus脚本的增强以及链外处理–见Tim Harrison最近的博客。特别是Hydra，一个正在开发的第二层协议套件，通过允许在链外执行交易，为总交易吞吐量的大幅改善提供了另一种途径。