Rapidblocks：最大限度地减少The Block建构管道中的“合并冲突”

rapidblocks 背后的主要思想是，如果我们能够以某种方式构建没有块间依赖关系的块，我们就可以加快时隙时间，减少交易包含时间，并大幅扩大块生产规模。

这主要是因为：

• 我们可以让“重组”变得更便宜：我们可以简单地跳过一些快速区块，而不需要昂贵的重组。（至于它是否真的便宜很多，或者只是便宜一点点，还有待观察。）
• 我们可以允许几乎并行地构建这些独立的块。几乎是，因为我们确实需要对构建器进行排序，并且信息流量很小。

当然，这样做是有代价的，因为区块之间确实需要某种方式相互依赖。我们会在最后讨论这个问题。

请将这篇文章视为一个想法倾泻和讨论的起点，而非最终的设计方案。描述过于笼统，忽略了许多细节，这可能会导致整个想法在实践中不可行。

该想法的基本概念首先出现在对BAL帖子的回复中。

如何构建“独立”积木

修改状态

假设区块 i+1 的构建者知道区块 i 修改状态的所有地址（或 <address,storagekey> 对）。

现在，它可以构建一个仅基于未被区块 i 修改的部分状态的区块。换句话说，它可以在区块 i-1 的“旧”后状态之上构建这个区块，这也意味着：

• 可以从链中“跳过”The Blocki，而无需丢弃区块 i+1
• 区块 i+1 的建造者不需要在建造之前执行区块 i
• 它甚至不需要知道块 i 的状态变化

访问状态

现在假设块 i+1 的构建器知道块 i 访问（读取或写入）的所有地址（或 <addresses,storagekey> 对）。有了这些信息，它可以构建一个更强大的块，使其在逻辑上与块 i 并行。

• 块 i+1 不依赖于块 i
• 块 i 不依赖于块 i+1

由于执行顺序并不重要，这使我们能够进一步廉价地重组“链”。

当然，读者注意到了，假设 1 和假设 2 如今都已经成立。我们的区块构建器知道所有这些地址。那么，我们究竟在说什么呢？

这里有两个要点需要注意：

• a，虽然下一个区块构建者拥有这些知识，但我们无法有效地传递它，从而导致更长的时隙时间
• b，虽然下一个区块构建者拥有这些知识，但我们不会强制执行区块独立性，如果我们减少时隙时间，这将导致更频繁和更昂贵的重组。

但这太疯狂了，区块确实（现在）依赖于前一个区块，对吗？

是的，但这只是一小部分。有趣的是，一个典型区块中超过 90% 的交易似乎包含不依赖于前一个区块的交易。有关区块间依赖关系的当前状态的更多详细信息，请参阅这篇关于“预热”的文章。

在这个前提下，让我们看看可以使用哪些潜在工具来实现 repidblocks。

工具

BAI和BMI

这些想法的主要灵感来自于Toni 在优秀作品中对各种形式的块级状态变化和访问列表（也称为BAL）的探索。

很容易看出，我们的条件 1 是BAL的块后状态变化的地址列表部分。我们将其称为 BMI，The Block级状态修改索引。

我们的条件二映射的是没有前状态或后状态信息的BAL 。我们称之为BAI，The Block级访问索引。

注意：也许我们应该称这些为存储位置/写入位置，但 Locataion 中的 L 已经被 Lists 中的 L 占用

因此，如果我们可以将其中一个快速转发给下一个构建者，并利用区块独立性带来的更低成本的重组，就能缩短时隙时间。在以太坊中，我们不能直接将其快速转发给下一个构建者，而是需要将其发送到整个网络。即使我们知道下一个验证者，我们也不知道它在网络中的位置，而且由于显而易见的原因，我们没有基于验证者 ID 的路由。

不过，我们可以考虑优先考虑网络上的 BAI（较大）或 BMI（较小），从而减少时隙时间。

BAF和BMF

如果我们能以某种方式将 BAI 或 BMI 压缩成单个 IP 数据包，并在网络中快速转发，那就更好了。这可能使我们能够在最短 300 毫秒内将信息传播到整个网络。我们可以尝试使用布隆过滤器来实现这一点。更多详情，请参阅我的 BAF 文章。

rapidblock“链”结构

我们的最终工具是新的“链”结构。实际上，底层结构并非真正的链，而是一个受限的 DAG，但如果有人真的需要，我们可以轻松地将其“线性化”为链式视图。（我认为这对于兼容性以及最终对这些理念的演进式引入至关重要）。

当然，块应该有依赖关系。但它们不必依赖于先前构建的块。如果我们能够缩短 slot 时间，强制其与前一个块独立，并允许其与前一个块独立，实际上可能会产生相同的效果。

我们上面创建的是一个区块生产流水线，可以构建

• 相互独立的块
  • 其中任何一个都可以独立地从“链”中删除，而不会影响其他区块的有效性。
• 严格排序但不依赖于状态的块
  • 如果区块b基于区块a的 BAF 或 BMF，仍然可以低成本地从链中移除其中任何一个，但它们不能以相反的顺序或并行执行，因为a可能会访问由b修改的状态

显然，至少表面上看起来是这样，共识机制变得更加复杂。证明机制并不会因为我们更频繁地生成区块而神奇地变得更快。但重组的成本要低得多，而且区块的生成频率也可以更高。需要说明的是，我目前还没有清晰地理解这应该如何运作，但我认为我们可以创建一个流水线式的共识机制，可以选择性地将独立的子链“合并”到一个虚拟的安全链层级中。

我们的收获

加快时隙时间

我们可以通过这种设计来加快时隙时间，原因有二。

主要原因是重组成本低廉。由于区块可以从规范链中选择性地跳过，我们实际上拥有非常低廉的重组成本，这意味着我们可以对那些因各种原因无法成功构建的区块更加宽容。

第二个原因是我们需要更少的信息来构建一个区块，并且我们可以在网络中更快地分发少量的信息。

减少交易纳入时间

随着时隙时间的缩短，交易的打包时间也随之缩短。虽然这并非对所有人来说都重要，但这显然是用户体验的一部分。

扩大区块生产规模

由于我们只需要一个非常小的过滤器就能到达下一个构建器，我们也可以考虑并行化区块构建。这是一种无需预先进行状态空间划分的动态分片。同样，这里的设计目前尚不明确，但我认为我们可以朝着基于BAF或BMF快速扩散的分布式区块构建并行化和流水线化的方向发展。

与其他想法的关系

这个想法也可以从一个新的角度看待BAL和气候变暖。与其试图快速引发大规模的状态变化，不如努力确保不会发生大规模的变化。

还有一些想法正在朝着允许在发生冲突时“跳过”交易级别的方向发展。我认为有空间尝试结合这些想法，尽量减少（但不一定消除）区块间的依赖关系。我们甚至可以尝试为独立的更改设计一条“快速路径”，为依赖性更改设计一条“慢速路径”（但速度不会比现在慢），从而实现一种设计，使整体链容量可以提升，而不会受到特定“最坏情况”交易的限制。