不排算力也不数 stake 的共识
Stellar 官方文档介绍 SCP（Stellar Consensus Protocol）时开门见山：工作量证明共识排算力，多数权益证明共识排 stake，SCP 走第三条路——联邦拜占庭协议（FBA），投票权重来自每个节点自己书写的信任关系。每个参与的 Stellar Core 节点自由决定愿意听谁的意见，文档强调这套安排带来两个后果：任何人都能运行 Core 节点（开放准入），且没有任何中心权威能规定谁的投票是达成共识的必需品（去中心化控制）。文档还明确写道，Stellar 网络不给验证者货币奖励，参与验证更多是对网络安全与韧性的贡献。
信任图是一刀一刀手动切出来的
每个 Core 节点维护一个 quorum set 并设一个阈值：比如节点 B 的集合是 A、C、D，阈值为 2，那么 (A,C)、(C,D)、(A,D) 中任何一对达成一致就足以让 B 推进——这些”够用的子集”叫 quorum slice。反过来，任何能阻止某节点达成一致的节点组合构成它的阻塞集。当各节点的信任图交叠到存在一组节点、其中每个成员都落在自己 quorum set 内某个 slice 覆盖之下，全网就形成一个 quorum。于是 Stellar 的安全问题不是”多少 stake 在使坏”，而是拓扑问题：slice 必须重叠到什么程度才不可能分裂成互不相交的两半。官方文档给共识三属性排了明确次序：容错与安全（不会有两个节点确认互相矛盾的结果）优先于活性，并明说——正因为安全优先，区块可能卡住等待而非强行推进。
投票的三级状态与一轮两阶段
同一条声明在协议内经历三级表态：vote（认为有效但还不敢行动）、accept（有 slice 的背书但尚不安全）、confirm（可以行动——即便 quorum 里其他成员还没确认，它们也无法再确认与它矛盾的内容）。状态跃迁有硬规则：accept 要么整个 slice 都已 vote 或 accept，要么阻塞集整体 accept；confirm 需要看到一个完整 slice 的 accept。
阻塞集规则值得单独停下来看：官方文档写明，当阻塞集整体 accept 了 A，节点即便此前投票支持过与 A 矛盾的内容，也要忘掉旧票、跟随接受。这条”被迫改口”看似违反直觉，作用是给收敛装上棘轮——它保证分歧一旦在某个 slice 上沉淀，节点不会无限期抱持互斥立场，共识才可能推进。反过来，它也是活性与安全的交换阀：文档明确说明安全优先，节点宁可搁置也不抢先行动，所以 Stellar 网络偶尔表现出宁可暂停也不冒险的行为。
一轮共识分两段：先跑提名协议（nomination），让候选交易集收敛——节点确认第一个候选后就停止提名新的交易集，只继续确认已有候选，最终全网收敛到同一候选列表；再进入选票协议（ballot），对候选逐轮投票，一轮一轮走向 confirm。节点确认第一个候选之后即可启动选票协议，提名与选票两段因此是接力关系而非并列关系。
这套模型改变了什么评价标准
评价一条 FBA 链的安全性，看节点总数与 stake 集中度都不对症，真正的问题是 slice 的交错结构：一旦 slice 能被分裂成互不相交的两组，安全就受损；而失活的表现是停摆，不是出账错。这也解释了为什么 Stellar 的验证者更多由有现实身份的机构担任——官方文档就提到，验证者之间往往因为现实身份自带的信任而互相信任，这本身就是安全模型的一部分。验证者名单、默认信任路径与节点软件的演进，应以 Stellar 官方开发者文档和 stellar-protocol 仓库记录的提案为准。对普通用户，理解”FBA 拒绝在信息不全时猜结论”有助于解释为什么 Stellar 网络偶尔表现出宁可暂停也不冒险的行为；看一条链是否健康，除了节点数量，更该看它信任图里主要 slice 的重叠面最近有没有收窄。
以上为机制说明，不构成投资建议；网络停摆与代币市场风险并存，请独立核验后自行判断。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。