超级代表和投票

超级代表, 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 提案生效前,不存在投票者奖励。