超级代表和投票

超级代表, Super Representatives, SR, Witness, 见证人, 一般指的是同个概念。

这里作出严格界定：

Witness, SR, 超级代表

所有通过 CreateWitness API 申请的地址。即最广义的超级代表。

Active Witness, BP

即投票数位于前 27, 具有出块权限的超级代表。

Standby Witness, Witness127

投票数位于前 127, 即具有出块权限的超级代表和之后 100 个超级代表。(= Active Witness + SRP)

SRP, SR Partners

投票数位于 28 ~ 127 的超级代表。

SRC, SR candidates

投票数位于 127 位之后(不含)的超级代表。

超级代表特权一览

• 若票数足够，进入 Active Witness 列表，则可以出块，并获得出块奖励

• 若票数足够，进入 Standby Witness 列表，则可以获得 Standby Witness 奖励

• 任意超级代表都可以发起提案

• 任意超级代表都可以为提案投票。但提案到期计票时候，只计 Active Witness 的票，当 >= 7/10 时，提案通过

成为超级代表

要成为超级代表，只需通过 WitnessCreate 内置合约发起调用，并支付一定费用。

随后即可宣传节点，号召社区为节点投票。

投票

超级代表通过计票的方式决定排名，所有公链用户均可以对超级代表进行投票。

投票的前提条件是获得足够的 TP(Tron Power), 1_TP 可以投 1 票。

TP 可以通过质押(冻结)资源或为他人质押资源的方式获取。每质押 1_TRX 可获得 1_TP ，为他人质押资源只增加自己的 TP。

注意

理论上计票是按照票数由大到小排列。但票数一致的情况下，java-tron 实现有一定的被攻击风险。

java-tron 计票实现是，按票数，地址的 hashCode 依次排序。

风险点：

首先 Java 中没有任何一个第三方库会宣称 hashCode 稳定，且不会有任何第三方库对 hashCode 的稳定性提供测试用例。所以至少需要把该版本的 hashCode 算法迁移到 java-tron 代码库。

其次，hashCode 值域空间缩小，计算量大大减少（2^32)，那么很容易创建出两个 hashCode 一样的地址，加入公链，此时排序算法失效。

合理的实现是，fallback 排序直接按地址的二进制字节比较。

奖励机制

如上所述，超级代表存在两种奖励

• 出块奖励，每产一个区块获得该奖励，稳定

• Standby Witness 奖励，前 127 个超级代表可获得，按票数加权分配奖励

为了激励投票者，超级代表可以设置一个 分红比例 ，将部分自己所得奖励，按票数加权，分配给投票者。

注意

在 AllowChangeDelegation 提案生效前，不存在投票者奖励。