共识与 DPoS

TRON 采用委托权益证明（DPoS）。质押者投票选出 27 位超级代表（SR），由这些 SR 轮流每 3 秒生产一个区块；当至少 19 位不同活跃 SR 都已经在某一区块高度或更高高度出过块时，该区块进入“已固化”状态，通常耗时约 1 分钟。网络参数可通过 SR 投票的链上提案调整，因此共识机制也连接着 TRON 的治理流程。

📘

名词说明

本文和中文开发者文档正文中，出块节点统一称为超级代表（Super Representative，简称 SR）。
系统合约类型、API 响应、Protobuf 结构和配置文件仍保留早期协议名称，例如 WitnessCreateContract、witness_address、localwitness 和 --witness。在 API 或配置中看到 witness_* 字段时，可按“超级代表（SR）”理解。

本文说明共识角色、出块时间表、分叉选择、区块固化、异常槽位处理、奖励流向，以及网络参数提案如何生效。

📘

前置阅读

• Token 经济学
• 区块
• 超级代表

概览

以上所有数字均为当前链上参数，部分参数可通过 SR 投票提案修改。请始终通过 wallet/getchainparameters 查询实时值。

术语

以下术语在本页及其他共识文档中保持一致。部分术语与其他链相似，但在 TRON 中含义不同。

角色

三个层级的角色参与共识与提案系统：

任何账户都能通过提交 WitnessCreateContract 成为 SR 候选人。该操作需要支付一次性注册费用 9,999 TRX；账户后续不再担任 SR 时，这笔费用也不会退回。它是进入出块节点候选池的抗女巫攻击门槛。

注册后，SRC 累积投票。在每个维护期，网络按总获票数重新排列所有 SRC，并将前 27 名提升到下一维护周期的活跃集；第 28–127 名成为 SR 合伙人。SR 根据实时投票竞争，在每个维护期在活跃、合伙人和纯候选人层级之间发生切换。

📘

SR 和 Witness

在文档正文中，SR 被称为超级代表，但是在交易类型和存储字段中仍使用遗留名称（WitnessCreateContract、witness_address、localwitness、--witness）；这些名称在代码中为向后兼容而保留。在 API 响应或配置文件中看到 witness_* 时，应理解为“SR”。

选举与活跃集轮换

DPoS 选举是持续进行的——没有单独的“选举日”。投票随着账户投票或撤票实时累积，活跃集在每个维护期根据最新统计结果重新计算。

投票机制

投票是用账户的 TRON Power（TP） 为一个或多个 SR 计票的操作；TP 本身不可转让，始终保留在账户中，投票只是把其对应的投票权重指派给所投的 SR。投票前，账户必须先通过 FreezeBalanceV2Contract 质押 TRX，每质押 1 TRX 获得 1 TP。投票通过提交 VoteWitnessContract 交易完成，交易中列出一个或多个候选人及分配给每人的票数。分配的总票数不得超过账户的质押 TRX 余额。

VoteWitnessContract 采用全量覆盖语义：每次调用都会重写整个候选人列表。要“撤销”对特定 SR 的投票，提交一个不包含该 SR 的新 VoteWitnessContract 即可。

维护期的投票统计

投票持续变化，但由此产生的 SR 集仅在每个维护期重新计算。在该时刻，网络按顺序执行以下操作：

1. 快照每个 SR 的每周期奖励变量 Vi，用于记录该 SR 在刚结束维护周期内的有效投票权重，并作为投票奖励计算依据。
2. 应用自上次边界以来累积的待处理投票变化，更新每个 SR 的累计投票数。
3. 重新排列所有候选人的更新票数。
4. 提升新的前 27 名进入活跃集，降级低于 27 名的候选人，并记录每位候选人的新角色。
5. 快照每个 SR 的分成比例（Brokerage），适用于新维护周期。

维护期内暂停出块（约 6 秒，即维护周期最后两个槽位）以执行上述步骤。暂停后，新活跃集按其新计算的槽位顺序开始出块。

出块期内投票变化的影响

由于活跃集在整个出块期内固定，出块期内的投票变化不会改变本维护周期内的出块节点，只影响下一个维护周期。投票奖励同样附属于上一维护期快照的投票分配——关于出块期内投票变化如何影响奖励资格的快照语义，请参阅为 SR 投票。

区块生产时间表

每 3 秒生产一个新区块。在每轮 27 个槽位内，每个 SR 恰好拥有一个槽位，顺序固定，由维护周期开始时的投票排名决定。每个 SR 按时出块时，一轮需 81 秒。

槽位顺序与轮换

槽位顺序是确定性的。SR 按投票数降序排列；票数最高的 SR 获得该轮的第一个槽位，票数第二的获得第二个槽位，以此类推。顺序在整个出块期内不变，即使投票持续变化。在下一个维护期，计算新的顺序并重新开始循环。

槽位 (Slot) 内部的工作流程

当属于某个超级代表（SR）的 Slot（槽位）到来时，该 SR 会按顺序执行以下操作：

1. 拉取交易 (FIFO)：SR 会按照先进先出（FIFO）的顺序，从其本地的交易内存池（mempool）中接收并拉取交易。
2. 逐笔处理交易：SR 会在独立的会话中逐笔处理交易。交易最终能否成功写入区块，取决于其合约类型：
   • 系统合约（例如：TransferContract 转账、FreezeBalanceV2Contract 质押、VoteWitnessContract 投票、WitnessCreateContract 创建 SR）：
     如果执行器的 validate() 或 execute() 抛出异常（例如：地址无效、余额不足、账户不存在等），该会话会回滚，整笔交易不会写入区块。
   • 智能合约调用（例如：TriggerSmartContract 触发合约、CreateSmartContract 创建合约）：
     无论虚拟机（VM）执行成功还是触发回滚（revert），交易都会被打包进区块。执行失败的合约调用会以 FAILED 状态上链，并且其消耗的能量（以及因能量不足而燃烧的 TRX）不会退还。这与以太坊的设计一致——失败的合约也会记录在链上，因为调用者必须为已经发生的计算工作买单。
   • 通用的“预执行失败”情况：
     对于上述两类合约，如果出现以下基础错误（签名无效、过期的 TAPOS 引用、带宽不足、交易体过大），交易也会被直接丢弃，不会打包进区块。
3. 组装元数据：将区块的元数据添加进去，包括：父区块 ID、该 SR 自己的地址、新区块的高度以及区块时间戳。
4. 区块签名：使用配置的 localwitness 私钥对区块进行签名，签名结果会写入 witness_signature 字段。
5. 广播与共识：将该区块广播给网络中的其他对等节点。其他节点会验证签名、重放区块中包含的每笔交易（重新运行状态校验和 VM 虚拟机执行），验证无误后将该区块追加到其本地链上。

区块内交易打包遵循本地内存池的先到先得原则，而非由发送方支付的优先级决定。

• 没有小费竞价： TRON 未引入优先费机制，fee_limit 是单笔交易的 Energy 预算上限，不能作为“插队”筹码。
• 不采用优先费排序：因此，以太坊上基于优先费竞价的排序模式不适用于 TRON。区块内交易排序仍取决于 SR 本地 Mempool 和打包逻辑。

丢失槽位 (Missed Slots)

如果超级代表（SR）在所属槽位内未能出块（如宕机或网络问题），该槽位将直接留空。网络不会安排备用节点补位，下一个槽位仍按原计划由下一位 SR 轮替。

丢失槽位的两项代价：

• 经济损失：该 SR 失去 8 TRX 产块奖励；同时，该槽位对应的 128 TRX 投票奖励池作废，全网前 127 名 SR 及其投票人会失去该期收益。
• 网络延迟：每丢失一个槽位，下一个区块的等待时间将从 3 秒暂时拉长至 6 秒。

💡 注意： TRON 没有内置直接没收资产的罚没（Slashing）机制。故障节点的惩罚主要体现为奖励减少和得票下滑，进而可能跌出前 27 名。

维护期暂停

每隔 6 小时进入维护期时，边界区块的下一个区块被调度到两个槽位之后（约 6 秒），网络借此初始化新一批活跃 SR——并非网络停摆。

• 期间工作：网络利用这 6 秒结算最新投票、更新前 27 名 SR 名单，并快照节点分成比例（Brokerage）。
• 运维提示：这种暂停是底层正常机制，并非网络卡死。设置区块监控告警阈值时，应为这 6 秒留出余量，避免线上误报。

分叉选择规则 (Fork Choice Rule)

TRON 节点有时会在链顶端遇到两个相互竞争的区块。这通常由短暂网络延迟引起；极少数情况下，也可能来自超级代表（SR）的双签或 Equivocation 行为。节点处理这类分叉时遵循以下规则：

• 最长链原则
  只有当新区块的高度严格大于当前本地区块头的高度时，新区块才会被接受。任何高度相同的备选区块都会被直接丢弃，不作任何横向对比。
• “先到先得”处理
  如果节点已经接受了高度为 H 的区块 A，随后又收到另一个处于同等高度 H 的区块 B，则区块 B 会被直接丢弃。网络不会通过区块 ID、签名或时间戳等其他字段来判定胜负——节点最先处理哪一个区块，哪一个就获胜。
• 槽位级唯一性
  在节点的本地链上，每个 3 秒的槽位最多只能产出一个区块。底层的有效性检查 bSlot > hSlot 会直接拒绝任何时间戳“等于或早于”当前区块头槽位的区块，即使该区块声明了不同的父区块也是如此。

实例解析：两位超级代表（SR）产生“视差”导致分叉

场景起因：网络延迟引发同高度分叉

假设超级代表 SR_A 在槽位 N 生产了 区块 100。由于短暂的网络故障，处于下一个槽位 N+1 的 SR_B 此时还没收到区块 100。于是，SR_B 误以为当前最新的是区块 99，并在槽位 N+1 生产了另一个 区块 100'（其父区块哈希指向区块 99）。此时，市场上同时出现了两个高度均为 100 的竞争区块：

          ┌─ 100  (由 SR_A 在槽位 N 生产)
... 98 ── 99 
          └─ 100' (由 SR_B 在槽位 N+1 生产，此时它未看到区块 100)

先接受 100 的对等节点收到 100' 时：

• bSlot(100') = N+1，hSlot = N → bSlot > hSlot 通过。
• 但 getNum(100') = 100 == headerNumber → Manager.pushBlock 在底层返回。区块 100' 被丢弃。

节点视角的过滤机制

对于一个“先接收并处理了区块 100”的普通节点而言，当它随后又收到迟到的区块 100' 时，会进行以下逻辑判断：

• 槽位有效性检查（通过）：新区块的槽位 bSlot(100') = N+1，而节点本地当前的区块头槽位 hSlot = N。因为 N + 1 > N，验证通过。
• 高度有效性检查（失败并丢弃）：新区块的高度 getNum(100') = 100，等于本地当前高度（100）。不满足“高度必须严格大于本地高度”的规则，区块 100' 被直接丢弃。

分叉消除与固化

• 最长链获胜：后续的 SR_C 会在它“最先收到”的那个分支上继续生产区块（产出区块 101）。随着某一分支高度严格超过本地链头，节点会切换到更长的有效分支；同高度、迟到的竞争区块会被直接丢弃。
• 固化高度推进：节点在每个新区块应用后重新计算固化高度。计算时只看当前活跃 SR 各自的 latestBlockNum；当至少 19 个不同活跃 SR 的最近出块高度达到某个高度或更高时，该高度及之前的区块进入已固化范围。

               ┌── 100 ── 101 ── 102 ── ... (主链，更多 SR 延伸)
  ... 98 → 99 ─┤
               └── 100' (孤块，无后继)

双签防御机制

当某个超级代表（SR_X）恶意在同一槽位 N 签署两个不同的区块 A 和 B 时（两者高度、时间戳相同且签名合法），它们都会通过第一道初审。

• 核心防御：依靠 DposService.validBlock 的槽位唯一性检查。一旦其中一个区块（如 A）先被节点接受为当前链头（hSlot），稍后到达的 B 就会因为满足 bSlot <= hSlot 被直接拒绝。
• 分叉消除：由于“先到先得”，网络会产生短暂分裂（部分节点走 A，部分走 B）。但这种分裂通常在一轮（81 秒）时间内就会平息——最终只有一条分支能获得后续更多 SR 的接力支持，失势的分支则沦为孤块。

此外，关于越权出块防御：如果超级代表企图在属于其他 SR 的槽位强行出块，该区块会被 scheduledWitness != witnessAddress 校验一刀切地拒绝。这种非法区块连进入共识对比的资格都没有，从源头上杜绝了导致分叉的可能。

分叉如何解决

链顶端的分叉通常能在较短时间内被解决，这主要得益于以下三点原因：

• 高效的网络传播：27 个超级代表（SR）之间通常保持较好的网络连接，区块传播延迟较低。
• 快速固化机制：节点会持续统计当前活跃 SR 的最近出块高度。主网 27 个活跃 SR 下，当至少 19 个不同活跃 SR 已在某一高度或更高高度出过块时，该高度及之前的区块被固化（Solidified）。固化高度以下的分叉将不再可能发生。
• 直接的利益驱动：SR 有经济动机留在规范主干链上。如果自己的区块沦为孤块，SR 会损失产块奖励和对应投票奖励份额。

TRON 协议没有内置自动没收质押资产（Slashing）的硬性罚没机制：

• 丢块记录：对于任何空置槽位，底层代码 StatisticManager.applyBlock 仅会增加对应 SR 的 totalMissed（总丢块数）计数。该指标公开，用户可通过 TronScan 浏览器查看。
• 选民驱动的淘汰制：协议本身只负责拒绝错误区块，不没收质押金。真正的惩罚由投票者（持币用户）驱动——表现不佳或有恶意行为的 SR 会流失选票，并在下一个每 6 小时的维护期直接被踢出前 27 名超级代表名单。

最长链规则仅适用于未固化的链顶区块。区块一旦被固化，就彻底脱离了分叉选择规则的约束，成为不可逆转的铁定历史。

区块固化

在 TRON 中，新生成区块不会只因为被打包就立刻成为最终状态。节点会持续统计当前活跃超级代表（SR）各自最近一次成功出块的高度。当 27 位活跃 SR 中至少有 19 位不同 SR 已经在某一区块高度或更高高度出过块时，该高度及之前的区块进入“已固化”状态。

已固化的区块具备强最终性（Finality），在链上不可逆转，且不会被分叉替换。在正常出块情况下，新区块通常需要约 1 分钟达成固化。由于固化高度单向递增，交易所、钱包及跨链桥等场景普遍将“区块已固化”作为交易最终确认的标准。

固化阈值由链上常量 SOLIDIFIED_THRESHOLD = 70（百分比）参与计算。节点先收集活跃 SR 的 latestBlockNum，升序排序后按 70% 阈值计算索引位置。主网 27 个活跃 SR 时，计算结果等价于“至少 19 个不同活跃 SR 已经到达该高度或更高高度”。

在底层源码（DposService.updateSolidBlock）中，节点通过以下逻辑计算全网最新的固化高度：

1. 搜集当前活跃 SR 的最新出块高度（latestBlockNum），并将其按升序（从小到大）排列。
2. 根据以下公式计算目标索引位置（从零开始计数的索引）：
   Java

   int position = (int) (size * (1 - SOLIDIFIED_THRESHOLD * 1.0 / 100));
   long newSolidNum = numbers.get(position);

3. 在主网 27 个活跃 SR 的情况下，提取排序列表中索引为 8（即从左往右第 9 小）的高度值，作为最新的固化高度（newSolidNum）。

在包含 27 个元素的升序列表中，索引 8 到索引 26 之间共有 19 个元素。这表明全网至少有 19 个 SR 的当前出块高度已经等于或超越了索引 8 处的高度值，满足 ≥ 70% 的共识条件。

📘

固化不是显式投票

TRON 没有为区块固化发送单独的确认投票消息。源码中的计数依据是活跃 SR 各自存储的 latestBlockNum：只有当某个 SR 自己成功生产了高度 H 或更高的区块时，它才会计入高度 H 的固化阈值。接收、转发或仅通过 parentHash 连接到某个区块，并不会单独增加固化计数。固化高度保存后只会前进，不会回退。

对于交易所充提对接、跨链桥智能合约等涉及大额资产确认的场景，建议调用 SolidityNode API 接口查询已固化区块的数据，而非调用普通 FullNode，以避免未固化链顶的分叉风险，确保资产状态的确定性。

奖励

每个新区块产生的奖励如下：

两项奖励值均为链上参数，可以通过委员会提议修改。随时可查询当前值：

BASE_URL=https://api.trongrid.io   # 示例 — 替换为任意 TRON 节点（TronGrid、第三方或自建节点）
curl -X POST ${BASE_URL}/wallet/getchainparameters

在返回的 chainParameter 数组中，通过 key 查找条目——切勿按固定数组索引查找，因为数组顺序与提案 ID 编号并不对应。

分成比例 (Brokerage) 与奖励分配

超级代表（SR）可在链上配置分成比例（Brokerage），取值范围为 0–100，默认值为 20。该比例决定 SR 从产块奖励和投票奖励中保留给自身的百分比。以全网每日总投票奖励池约 3,685,376 TRX（128 TRX/区块 × 每天 28,792 个区块）为例，若某 SR 的得票率为 5% 且分成比例设为 20%，其每日奖励分配如下：

SR 每日可获总奖励 = 3,685,376 * 5% = 184,268.8 TRX/天
节点自留份额 = 184,268.8 * 20% = 36,853.76 TRX/天
投票人可分配份额 = 184,268.8 * (100% - 20%) = 147,415.04 TRX/天

节点自留份额直接计入该 SR 的可提现余额，投票人份额按投票权重累计给对应投票人。投票奖励不会自动发放到账，投票人需提交 WithdrawBalanceContract 领取（每 24 小时限执行一次），将累积奖励划转至账户可用余额。

奖励计算基于每 6 小时维护期时的投票权重快照与分成比例（Brokerage）；出块期内发生的选票变动不影响当前维护周期的计算结果。完整机制请参阅为 SR 投票。

前 127 名候选人奖励机制

投票奖励池按得票比例，在前 127 名候选人（包括 27 名超级代表和 100 名超级代表合伙人）之间分配。超级代表合伙人（SRP）不出块，但仍可获得与得票率对应的投票奖励。

该设计旨在：

• 维持梯队运营：使排名非前 27 名的优秀候选节点能够获取收益，以覆盖高标准服务器的长期运营成本。
• 平滑更替：当 SR 因故障或选票变动退出前 27 名时，深度的后备候选池可实现无缝顶替。

单个区块 8 TRX 的产块奖励仅归属于对应槽位内成功生成区块的 SR。超级代表合伙人不参与出块，无法获得该项奖励。

链上治理 (On-chain Governance)

TRON 的网络参数（包括区块奖励、资源定价、TVM 功能特性、治理阈值等）不是写死在客户端里的常量，而是以键值对形式存储在链上。超级代表（SR）可以通过提交提案并投票来修改这些参数。

一项提案的生命周期与网络的维护期紧密绑定，主要经历以下三个阶段：

1. 提案提交

任何 SR、SRP（超级代表合伙人）或 SRC（超级代表候选人）均可通过触发 ProposalCreateContract 系统合约提交提案，合约内包含 {parameter_id: new_value} 的参数映射关系。提案的投票开放时间受链参数 #92 getProposalExpireTime 控制，主网当前通常为 3 天。

2. 提案投票

在提案到期之前，任何 SR、SRP 或 SRC 均可通过 ProposalApproveContract 合约来添加或撤回对该提案的批准，所有投票记录会实时写入链上。需要注意的是，只有在提案到期那一刻的 27 个当前 SR 的批准状态才会被计入最终的有效阈值统计。

3. 统计与应用

在提案到期的维护期，网络会结算投票结果：

• 通过（APPROVED）：若记录到 ≥ 18 个 SR 的批准，提案状态更新为 APPROVED，参数变更将在同一维护期区块中正式写入链状态并立即生效。
• 未通过（DISAPPROVED）：若批准数量不足 18 个，提案状态变更为 DISAPPROVED。无论结果如何，提案的最终状态均可永久供外部查询。

参考资料：完整的提案生命周期、带有撤回机制的投票流程、委员会轮换的影响以及取消规则，请参阅委员会与提案。欲了解可修改的网络参数完整列表及当前生效值，请参阅网络参数。

API

相关资源

• 超级代表 — 如何申请、配置和运营 SR 节点
• 委员会与提案 — 完整的提案生命周期和委员会轮换影响
• 网络参数 — 所有可提案的链参数
• 为 SR 投票 — 投票机制和奖励领取规则
• 区块 — 区块结构、复合区块 ID 和 TAPOS 引用
• 为超级代表投票 — 投票并领取奖励的 TronWeb recipe
• 创建治理提案 — 提交并跟踪提案的 TronWeb recipe