# 超级代表和投票

超级代表, 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。

{% hint style="warning" %}
注意

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

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

风险点：

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

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

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

### 奖励机制

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

* 出块奖励，每产一个区块获得该奖励，稳定
* Standby Witness 奖励，前 127 个超级代表可获得，按票数加权分配奖励

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

{% hint style="info" %}
注意

在 `AllowChangeDelegation` 提案生效前，不存在投票者奖励。
{% endhint %}