> ## Documentation Index
> Fetch the complete documentation index at: https://docs.monad.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# 全节点如何接收区块

<Note>
  关于如何搭建全节点的说明,请参阅[此处](/zh/node-ops/full-node-installation)。
</Note>

[RaptorCast](/zh/monad-arch/consensus/raptorcast) 协议是一种新颖的一对多区块传播方法,它使用擦除编码的两级广播树将大区块从消息发起者传播给众多监听者。

RaptorCast 在 Monad 网络中有两种用途:主要用途和次要用途:

* 在其**主要**用途中,RaptorCast 被每位领导者用于将其区块提案分享给激活集(active set)中的所有其他验证者。存在一个主要的 RaptorCast 组,由激活集中的所有验证者组成,其领导者会轮换。

* 在其**次要**用途中,激活集中的一个验证者支撑一定数量的下游全节点,将其(通过主要 RaptorCast 收到的)每个区块提案传播给下游监听者。次要 RaptorCast 组有很多——激活集中每个验证者对应一个——对每个组而言,领导者是固定的。

次要 RaptorCast 使网络能够支持庞大的全节点集合。在推荐配置下,每个验证者拥有一个大小为 150 的次要 RaptorCast 组。假设网络中有 200 个激活集验证者,即便考虑冗余系数 2(全节点可注册加入多个次要 RaptorCast 组),仍能容纳 150 \* 200 / 2 = 15,000 个全节点。

本页其余部分记录次要 RaptorCast 的行为,以及全节点运维人员如何配置它。验证者也可能觉得这些配置有用,因为验证者通常从全节点开始。

## 主要 RaptorCast 与次要 RaptorCast 的差异

次要 RaptorCast 遵循与主要 RaptorCast 相同的机制。

但存在一些差异。

在主要 RaptorCast 中:

* 参与者全部为验证者
* 由于领导者可能变化(因领导者选举),发起者也会变化
* 其他节点上的"权重"基于质押量

在次要 RaptorCast 中:

* 组的发起者是固定的且始终是验证者
* 除上述外,其他参与者为全节点
* 所有节点权重相等

## 全节点如何注册次要 RaptorCast

1. 全节点开始时会与一部分验证者进行对等连接。它们通过与 `node.toml` 中指定的引导对等节点(即其他全节点)进行对等连接来做到这一点(详情见本文档后续内容),然后向它们询问其对等节点,如此反复,直至获得完整验证者集合的名称记录。

2. 如果某个验证者在其 `node.toml` 中设置了 `enable_publisher = true`,它会定期向其路由表中的全节点发送邀请(数量不超过 `max_group_size`)。这些邀请会请求全节点加入该验证者的次要 RaptorCast 组。

3. 全节点可以选择接受或拒绝。如果全节点已加入过多组,它将拒绝。这由 `max_num_group` 参数控制。

4. 验证者将收集这些接受/拒绝响应并确认一个组。

5. 组将持续验证者 `node.toml` 中指定的 `round_span`(默认:240 轮)。当组的存在时长接近 `round_span` 时,验证者将开始为下一个次要 RaptorCast 组发送邀请。

6. 出于冗余考虑,全节点可以(且应当)加入多个次要 RaptorCast 组。

<Note>
  即使全节点尚未完成状态同步,它也可以加入一个组。加入组是全节点感知当前轮次的方式。该信息反过来可用于调整状态同步(statesync)的目标。
</Note>

## 配置 RaptorCast

### 一般建议

强烈建议验证者运维人员将节点:

* 先作为设置 `enable_client = true` 的全节点运行
* 并同时在 `node.toml` 中配置验证者特有的设置
* 然后通过质押转换为验证者

### 重要考虑事项

* 下述若干设置仅适用于以验证者身份运行的节点
* 另一些仅适用于以全节点身份运行的节点
* 尽管如此,推荐**同时**将两组设置均写入 `node.toml`

为什么推荐这样做?

因为一个节点可能"生命之初"作为全节点,然后(通过质押)成为验证者,再(如果撤回质押)重新成为全节点。同时具有两种模式(验证者和全节点)的设置可以确保节点始终跟上链的最新高度。

例如,如果验证者退回全节点身份并且没有加入次要 RaptorCast 组(即 `enable_client = true`),它将错过区块更新并落后于账本最新高度。

### `node.toml`

以下是 `node.toml` 中与 RaptorCast 相关的片段。

我们将设置分组为"仅全节点"、"仅验证者"或"两者兼有"。

我们还添加了注释以解释每个设置的作用。

`node.toml` 包含以下设置:

```
[fullnode_raptorcast]

# VALIDATOR ONLY
# "enable_publisher = true" means that if the full node becomes a validator, it will participate
# as a secondary RaptorCast originator.
enable_publisher = true

# maximum number of rounds that a validator will wait for invite response from the full node
max_invite_wait = 10

# number of rounds that a group lasts for
round_span = 240

# how far ahead (in rounds) validator sends invites to full nodes before the start of the round
# e.g. if the round_span is 240, the invites will go out at round 220
invite_lookahead = 20

# FULL NODE ONLY
# this needs to be "true" for full nodes to participate in secondary RaptorCast
enable_client = true

# upper limit on how many groups the full node will join
max_num_group = 3

# indicates the time range (in rounds) that the full node will accept group invites
invite_future_dist_min = 1
invite_future_dist_max = 600

# a heartbeat which is used to determine whether the full node is receiving proposals
invite_accept_heartbeat_ms = 10000

# BOTH MODES
# maximum number of nodes in a group
max_group_size = 150

raptor10_fullnode_redundancy_factor = 2.0
deadline_round_dist = 10
init_empty_round_span = 23

[fullnode_raptorcast.full_nodes_prioritized]
identities = []
```

## 其他选项

### 优先加入次要 RaptorCast

全节点可以与验证者协调,以显式且稳定地被邀请加入该验证者的次要 RaptorCast 组。

要做到这一点,全节点向验证者提供一些信息,以便加入其 `[fullnode_raptorcast.full_nodes_prioritized.identities]` 部分。有关需要提供的具体内容,请参阅[验证者安装](/zh/node-ops/validator-installation#configure-node-toml)。请注意,这意味着全节点无需依赖对等发现即可与该验证者建立对等连接。

### 专用上游

验证者也可以选择指定某些全节点,直接向它们转发所有主要 RaptorCast 数据块。

这会占用验证者大量带宽,因为每一个已注册的下游都需要发送一份所有数据块的副本。相比通过次要 RaptorCast 订阅,该方式对下游节点而言可能更为可靠,尽管在实际使用中次要 RaptorCast 的可靠性已相当高。

请注意,如果一个全节点被一个或多个验证者指定进行专用数据块转发,则可以将其配置为 `enable_client = false`。这将关闭其尝试参与次要 RaptorCast 的行为。

### 对比

| 配置                  | 需要验证者将全节点列入白名单 | RaptorCast 模式           | 数据源           |
| ------------------- | -------------- | ----------------------- | ------------- |
| **普通**              | 否              | `enable_client = true`  | 次要 RaptorCast |
| **优先次要 RaptorCast** | 是              | `enable_client = true`  | 次要 RaptorCast |
| **数据块转发**           | 是              | `enable_client = false` | 主要 RaptorCast |

请注意,这些配置是全节点与验证者之间**关系**的属性,而非全节点自身的属性。

一个全节点可以与多个验证者协调以获得特殊对待,同时也可以与其自动建立对等连接的其他验证者以普通方式参与次要 RaptorCast。

## 验证者的 RaptorCast 配置

验证者可以通过设置 `enable_publisher = false` 来关闭自己对次要 RaptorCast 的参与。

尽管关闭次要 RaptorCast 会降低带宽使用量,但请注意,次要 RaptorCast 的带宽成本相对较低;例如,即使在每秒 10,000 笔交易的情况下,预计使用量约为每秒 6 MB(3 MB 的区块数据,加上 2 倍冗余)。因此,建议保持 `enable_publisher = true`。

<Tip title="RaptorCast">
  有关 RaptorCast 的更多技术细节,请参阅 [RaptorCast 文档](/zh/monad-arch/consensus/raptorcast)。
</Tip>