Full Node Configurations
Monad supports several ways for full nodes to receive block proposals via the RaptorCast protocol.
1. As dedicated full node
Dedicated full nodes are whitelisted by validators in their [fullnode.identities] section.
These nodes receive forwarded chunks directly from their upstream validators via primary RaptorCast.
Key characteristics:
- Receive chunks forwarded from upstream validators via primary RaptorCast
- Can run with RaptorCast
mode = "None"without participating in secondary RaptorCast - Depends only on upstream validator availability
- Utilizes a lot of bandwidth from the upstream validator, who must forward all received chunks to each downstream dedicated full node
- Provide the highest reliability level
2. Via secondary RaptorCast
Nodes conduct secondary RaptorCast, which follows the same mechanism as primary RaptorCast, except with one particular validator serving as originator for every block, and full nodes serving as the other participants.
Each secondary RaptorCast group is rooted in a single validator.
There are two ways that full nodes may participate in secondary RaptorCast: as a prioritized full node or as a public full node.
2a. Prioritized full node
A prioritized full node is whitelisted by a validator in its
[fullnode_raptorcast.full_nodes_prioritized.identities] section. This means that the node
will receive guaranteed inclusion in the secondary RaptorCast group rooted in that
validator.
Key characteristics:
- Receive chunks via secondary RaptorCast
- Must run with RaptorCast
mode = "Client"to participate in secondary RaptorCast - Depends on upstream validator availability and group functionality
- Provides moderate reliability level
2b. Public full node
A public full node is not explicitly whitelisted by any validator. This node competes for available space in secondary RaptorCast groups from validators.
Key characteristics:
- Receive chunks via secondary RaptorCast (if part of a secondary RaptorCast group)
- Must run with RaptorCast
mode = "Client"to participate in secondary RaptorCast - Depends on validator availability, group functionality, and slot availability
- Provide the lowest reliability level
Configuration comparison
| Node Type | Whitelisted | RaptorCast Mode | Data Source | Reliability | Dependencies |
|---|---|---|---|---|---|
| Dedicated | Yes | "None"( "Client" optional) | Primary RaptorCast | High | Validator only |
| Prioritized | Yes | "Client" | Secondary RaptorCast | Moderate | Validator + RaptorCast group |
| Public | No | "Client" | Secondary RaptorCast | Low | Validator + RaptorCast Group + Slot availability |
Secondary RaptorCast group formation
The secondary RaptorCast system operates through a group invitation process:
- Group Invites: When a validator runs with
mode = "Publisher", it sends group invites to full nodes in its routing table based on the configured limits - Accept/Reject: Full nodes can accept or reject invites based on their current group participation and configuration
- Group Confirmation: Validators collect responses and create groups that last for a defined period
- Prioritized Selection: Validators always send invites to nodes listed in
full_nodes_prioritizedduring each group formation
RaptorCast configurations for validators
None
- Disables secondary RaptorCast participation
- Reduces bandwidth usage as node doesn't rebroadcast chunks
Client
- Enables secondary RaptorCast participation
- Increases bandwidth usage due to chunk rebroadcasting
- Required for Prioritized and Public full nodes
For more technical details about the RaptorCast, see the RaptorCast documentation.