跳转到主要内容
mip.watch
⌘K

MIP-10

Deterministic RaptorCast

草案 标准轨道 核心 GitHub ↗ 论坛 ↗
构想 草案 审核中 最终审核 最终 持续更新

Introduces a canonical encoding scheme for RaptorCast that closes asymmetric liveness and equivocation attack surfaces and reduces dissemination latency

作者
Category Labs
创建时间
2026-04-28
更新时间
2026年6月15日

利益相关方影响

此 MIP 为各受众群体带来的变化。严重度和操作标记由模型推导得出,并按 MIP 类型/分类设定确定性下限值。

要点速览

本提案提出了确定性RaptorCast(v1),旨在通过公开可推导的种子修复Raptor编码,并通过记录每轮的第一个有效(Merkle根,领导者签名)对来加强每轮的矛盾检测,从而减少传播延迟。

变更内容

  • 引入确定性编码:通过公开种子修复Raptor编码,消除不确定性。
  • 增强矛盾检测:每轮记录第一个有效的编码承诺,防止攻击。
  • 提高投票效率:验证者可以在接收到有效数据块后立即投票,减少延迟。
⌘

开发者

智能合约与 dapp 构建者、RPC 使用者、工具开发者

此MIP引入了确定性RaptorCast,改变了编码方案和Merkle根的计算方式,可能影响现有合约的行为,开发者需要关注与Merkle根相关的验证逻辑。

中
◉

用户

钱包用户、EOA 持有者、dapp 访问者

此变更将提高交易确认速度和安全性,用户在使用钱包或DApp时可能会体验到更快的交易确认。

高
◆

验证者

节点运营者、RPC 运营者、委托者

此MIP引入了确定性RaptorCast,可能会影响验证者的收入和盈利能力,特别是在投票延迟和攻击防范方面。虽然没有直接的经济收益变化,但改进的协议可能会提高网络的整体效率和安全性,间接影响验证者的收益。

中
✦

基金会

Monad 基金会与 Category Labs 核心开发者

该提案涉及对RaptorCast协议的重大修改,需要协调多个利益相关者以确保共识和实施。

高 需要采取行动

2026年9月21日 10:25 生成 · 模型:gpt-4o-mini

规范

机器翻译
引用

为方便阅读的 AI 翻译,可能不准确或已过时。在治理、投票和争议中,英文原文是唯一权威文本。准确表述请参阅 GitHub 原文。

GitHub 英文原文 ↗
## 摘要

本提案提出了确定性 RaptorCast (v1),这是 RaptorCast 传播层的一种新广播模式,通过一个公开可推导的种子修复 Raptor 编码,并通过记录每轮看到的第一个有效 (Merkle 根,领导者签名) 对来强制执行每轮的矛盾检测,称为 ``EncodingCommitment``。

这一变化带来了三大好处:(1) 它可以使验证者在收到经过验证的区块时直接对 Merkle 根承诺进行投票,而无需解码,从而节省了关键路径上的一条消息延迟;(2) 它关闭了不对称活性攻击,其中一个拜占庭领导者选择性地向目标验证者隐瞒单例编码符号标识符 (ESI),导致重构延迟几百毫秒;(3) 它关闭了混合承诺矛盾,其中一个领导者从编码多个不同有效载荷的区块中构建一个单一的 Merkle 根。请注意,利益 (3) 取决于共识协议的修订,以便对 Merkle 根承诺进行投票,而不是对解码的有效载荷进行投票;如果没有这一变化,矛盾攻击面根本不会出现。

## 动机

MonadBFT 使用 RaptorCast 在验证者集之间传播区块提案。当前协议 (v0) (参见 [RaptorCast: Designing a Messaging Layer](https://www.category.xyz/blogs/raptorcast-designing-a-messaging-layer)) 对领导者将哪个 ESI 分配到 Merkle 树的哪个位置,以及哪些 ESI 被交付给哪些验证者没有任何限制。这种交付自由带来了三个后果,而确定性 RaptorCast 解决了这些问题。

- **延迟** 一种自然的优化是将区块传播与共识投票重叠。验证者在收到一个区块并能够验证其与区块的 Merkle 根一致时,可以立即投票,而不是等待完全重构一个区块——从而节省了共识关键路径上的一条消息延迟。然而,在 v0 下,这并不安全。由于领导者对 ESI 分配的自由,同一个 Merkle 根可以与多个不同的有效载荷一致;因此,对根的投票并不能明确认证单个区块。规范的(确定性)编码消除了这种模糊性:由于 Merkle 根现在承诺确切的一个可能有效载荷,验证者可以在收到经过验证的区块时立即对根进行投票。

- **攻击 1:不对称活性** 当解码器至少接收到一些度为 1 的 ([单例](https://www.category.xyz/blogs/raptorcast-designing-a-messaging-layer#2-encoding-system)) ESI 时,Raptor 代码的解码效率最高,因为这些是信念传播剥皮解码器的入口点。如果没有任何单例,解码器会立即停滞,并必须回退到高斯消元,这要昂贵得多。拜占庭领导者可以利用 v0 的交付自由,选择性地剥夺目标验证者的单例,同时提供对抗性选择的高阶修复区块,从而最大化高斯消元的成本。结果是,目标验证者的重构时间比其他验证者晚几百毫秒(具体取决于源符号的数量),这足以在当前视图中使他们无法获得投票。这使得领导者有权强制未来的视图失败。

- **攻击 2:混合承诺矛盾** 通过对编码区块的 Merkle 根进行投票来降低延迟涉及解码-重新编码一致性检查,以确保编码有效。没有固定的 ESI 到位置的映射,解码-重新编码一致性检查无法为无率代码正确定义。领导者可以构建一个单一的 Merkle 根,其叶子来自多个不同有效载荷的编码。每个区块都通过了 Merkle 验证,但收集不同子集的验证者解码到不同的有效载荷。如果验证者在不解码的情况下对根进行投票,他们会认为自己在认证同一个区块,而实际上认证的是不同的区块。

## 规范

### 种子派生

规范种子(也称为编码种子)由领导者在提案时计算。它由(轮次号、领导者身份和提案时间)的哈希值组成。区块头包含所有必要的数据,以便验证者在接收到区块后可以确定性地重新计算该种子。验证者还会检查提案时间是否在其本地时钟的可接受范围内,然后才接受该种子为有效。

### 编码

领导者将有效载荷 `B` 编码为:

```
(c_1, ..., c_n) = RaptorEnc(B, seed)
R               = MerkleRoot(c_1, ..., c_n)
```

在 v0 中,区块被组织成多个每个包含 `32` 个区块的 Merkle 树,每棵树由领导者独立签名。v1 用一个全局 Merkle 根 `R` 替代,`R` 是在所有 `n` 个区块上计算得出的,提供了一个统一的承诺,将每个区块绑定到提案的单一规范编码。Merkle 树的深度根据区块的数量动态计算,最大深度为 15。每个 Merkle 证明为 `20 × (merkle_tree_depth - 1)` 字节,最坏情况下证明大小为 `280` 字节,而 v0 中为 `100` 字节。

位置 `i` 必须包含在种子下生成的 `ESI = i` 的区块。对该提案的 ``EncodingCommitment`` 是对 `(R, σ)` 的配对,其中 `σ = Sign(round, timestamp, R)`。

### 区块验证

验证者接受 v1 区块包 `(round, timestamp, R, σ, i, π_i, c_i)`。验证者仅在以下所有条件成立时接受该区块:

- **及时性** 包的轮次在接受的轮次窗口内,时间戳在验证者本地时钟的可接受范围内。

- **领导者真实性** `σ` 是对轮次、时间戳和 `R` 的有效领导者签名(`σ = Sign(round, timestamp, R)`)。

- **编码承诺一致性** `(R, σ)` 与该轮次已记录的编码承诺匹配。如果尚未记录任何承诺,验证者将记录此承诺。

- **区块完整性** Merkle 证明 `π_i` 验证 `c_i` 在索引 `i` 处与 `R` 的一致性。

任何检查失败的区块将被静默丢弃。冲突的承诺(相同轮次,不同的 `R` 或 `σ`)将被记录为矛盾证据,携带冲突承诺的区块将被丢弃。

### 编码验证(解码-重新编码检查)

在收集到足够的区块并解码有效载荷 B 后,验证者必须验证:

```
MerkleRoot(RaptorEnc(B, seed)) == R
```

种子是根据区块头中给出的值确定性地重新计算的。如果上述检查失败,则拒绝该有效载荷。由于种子固定了 ESI 到位置的映射,因此在 v1 下此检查是明确定义的:重新编码 `B` 始终产生可以根据记录的 ``EncodingCommitment`` 进行验证的相同区块集。在 v0 下,此检查无法可靠地应用。

## 理由

确定性 RaptorCast 对现有 RaptorCast 基础设施的更改最小。编码方案、Merkle 承诺、块交付和重播均保持不变。新增内容包括:从现有提案元数据派生的规范种子,以及每个验证者的每轮矛盾检测。这些更改足以关闭两个攻击面,并在解码之前使对 Merkle 根承诺的投票安全,而无需更改共识投票协议、法定证书格式或执行层。最终的协议满足以下属性。

### 属性

确定性 RaptorCast 满足以下三个属性。

- **可用性** 如果存在 Merkle 根 `R` 的法定证书,每个正确的验证者最终都会终止。

- **完整性** 如果领导者是正确的,每个解码有效负载的正确验证者将准确恢复领导者最初分发的有效负载。

- **一致性** 任何两个从与 `R` 一致的块解码有效负载的正确验证者恢复相同的有效负载。如果没有有效的有效负载与 `R` 一致,每个正确的验证者返回 `⊥`。

一致性使得在解码之前对 `R` 的投票是安全的。对 `R` 投票的验证者隐含地为唯一有效负载担保:一致性保证每个随后解码的验证者都能得到相同的有效负载。如果没有这个属性,两个验证者可能会对同一个 `R` 投票,同时持有解码为不同有效负载的块,从而违反共识安全。

规范种子还在执行层解锁了一个之前不适用的后共识有效性门。由于解码-重新编码检查在每个正确的验证者处产生相同的结果,因此可以在共识决定一个区块后应用:任何解码有效负载未通过检查的区块将被每个正确的验证者独立拒绝,且没有分裂的风险。在 v0 下,没有规范种子无法使用此门;不同的验证者重新编码相同的有效负载可能会产生不同的根,并对同一个区块得出不同的结论。

这通过两个互补机制得以强制执行。首先,每轮矛盾检测:在接收到某轮的第一个有效 v1 块后,每个验证者记录一个 ``EncodingCommitment`` — 对 (global_merkle_root, signature) — 并拒绝该轮中具有不同字段的任何后续块。其次,规范种子固定了 ESI 到位置的映射,使得解码-重新编码检查明确定义:在公共种子下重新编码任何解码的有效负载始终产生可以根据相同的 ``EncodingCommitment`` 进行验证的相同块集。

## 安全考虑

促使此 MIP 的攻击,即不对称活跃性和混合承诺矛盾,通过规范种子和每轮矛盾检测如属性部分所述得以关闭。

- **种子磨损** 种子构造将拜占庭领导者的有效负载磨损优势限制在可用窗口内的微不足道:领导者在选择产生有利度分布的种子时,无法比随机机会做得更好。

- **轮窗口** 超出接受轮窗口的块将被静默丢弃。这防止了无限缓冲,但意味着一个显著落后于当前轮的节点在赶上之前不会接收到超出其窗口的轮的块。

## 参考实现
参考实现可以在 [https://github.com/category-labs/monad-bft/pull/2811](https://github.com/category-labs/monad-bft/pull/2811) 找到。

论坛讨论

3 个帖子 · 7 个点赞 · 5个月前
在论坛上阅读更多 ↗
  1. @mjalalzai #1 2026年4月29日 18:19

    MIP-10 - Deterministic RaptorCast Deterministic RaptorCast anchors the Raptor encoding to a publicly derivable seed, making it safe to vote directly on the Merkle root upon receiving a single verified chunk without decoding and saving one message delay on the critical path. It also closes two attack surfaces: asymmetric liveness, where a Byzantine leader deprives targeted validators of efficient decoding inputs causing reconstruction delays of several hundred milliseconds, and mixed-commitment equivocation, where a single Merkle root decodes to different payloads at different validators.

  2. @Vladimir Understanding #2 2026年5月2日 20:46

    mjalalzai: Deterministic RaptorCast anchors the Raptor encoding to a publicly derivable seed, making it safe to vote directly on the Merkle root upon receiving a single verified chunk without decoding and saving one message delay on the critical path. It also closes two attack surfaces: asymmetric liveness, where a Byzantine leader deprives targeted validators of efficient decoding inputs causing reconstruction delays of several hundred milliseconds, and mixed-commitment equivocation, where a single Merkle root decodes to different payloads at different validators. Regarding the proposal to vote on the Merkle root after receiving a single verified chunk: How does this impact the guarantee of data availability? While it certainly reduces latency, I’m curious if this change introduces a window where a validator might vote on a root for which the full payload hasn’t yet been fully prop...

  3. @mjalalzai #3 2026年5月3日 23:52

    This is intentional pipelining. Dissemination and the first round of consensus voting proceed in parallel rather than sequentially. If QC forms from 2f+1 such votes, it guarantees that at least f+1 correct validators hold valid chunks, which is sufficient for any correct validator to reconstruct the full payload.