一句话总结
Plasma 将验证者节点（负责提议和最终化区块）与非验证者节点（提供 RPC 并跟随链，但不影响共识）分离。这样 Plasma 可以让验证者集合保持精简且安全，让 RPC 提供商独立扩展，避免增加共识或网络风险。高层架构
每个验证者运行一个共识节点和一个执行节点，直接相连。除了各自的搭档之外，节点不会与其所属层级以外的同类节点通信（CL 之间、EL 之间）。这种分离让系统可预测、安全且易于推理。
扩展挑战
随着使用量增加，越来越多的应用和用户需要通过 RPC 访问以查询链上数据或发送交易。但如果每个新的执行节点都 必须 与一个新的共识节点配对，扩展就会变得低效，并可能膨胀验证者集合。 允许 RPC 提供商仅为满足读取需求而运行额外的验证者，既不实际，也不符合 Plasma 的性能目标。解决方案：非验证者节点
非验证者节点的行为像共识节点，但不参与共识。相反，它们 “跟随” 一个受信任的验证者来获取最终化的区块和分叉选择更新。 关键行为：- 它们订阅一个验证者的共识节点以保持同步。
- 它们暴露与真实验证者相同的分叉选择视图。
- 它们只读，因此不会增加负载或引入安全风险。
这种设计的好处
概要对比
渐进式去中心化
Plasma 遵循渐进式去中心化模型。它不会从第一天就开放验证者集合，而是先专注于稳定性、性能与开发者可用性。这种方式在核心协议组件仍在演进时优先保障网络可靠性。 去中心化仍是长期目标，但将逐步分阶段引入。验证者集合将通过三个阶段扩展：1
集中运营
在测试网期间，所有共识节点由 Plasma 团队运营，以便快速迭代并将运营风险降到最低。
2
受信验证者集合
主网启动后，会加入一小批外部验证者，依据可靠性、运营就绪度和地理分布进行筛选。
3
无许可参与
随着时间推移，验证者准入将向公众开放，并配有协议层面的安全性、活性和经济对齐保障。
对等发现
Plasma 节点通过两个独立的机制（每个机制对应栈的一个层级）发现并连接对等节点。执行层 (Reth)
执行客户端使用 Ethereum 标准的 devp2p 协议进行对等发现。启动时，你的 Reth 节点会连接到一组在enodes.txt 中定义的可信执行对等节点。这些是 enode URL，编码了每个对等节点的公钥、IP 地址和端口。
每个网络的 enodes.txt 已在 non-validator-templates 仓库中预先配置好。连接到初始集合后，Reth 内置的发现协议（discv4/discv5）会自动找到更多对等节点。
执行层 P2P 运行在端口 30303（TCP/UDP）。
共识层 (PlasmaBFT)
共识观察者客户端通过在non-validator.toml 中定义的引导节点发现对等节点。每个引导节点条目包含 API 主机、P2P 端口以及 libp2p peer ID：
discovery.enabled = true) 的情况下自动找到网络上的其他对等节点。
共识层 P2P 运行在端口 34070（TCP）。
NAT 之后的节点
如果你的节点位于 NAT 网关或防火墙之后，其他对等节点可能无法通过其内部地址访问它。你可以配置一个外部地址，以便对等节点可以发现并连接到你的节点：p2p_port 的值。请确保外部地址可达，并且相关端口通过防火墙做了端口转发。
概要
关于端口与防火墙详情，请参阅非验证者节点部署指南。
快速开始
节点类型
了解验证者、非验证者和 RPC 提供商角色
非验证者节点部署
使用 Docker Compose 部署节点
硬件要求
节点最低与推荐规格
运营者接入
开始进行无许可节点运营