lovemoney.top

当前位置：主页 > 列表页 > 正文

建模分析 Altair 升级的影响

2021-09-18 22:38 | 出处： ECN以太坊中文社区

来源 | pintail.xyz

作者 | pintail


从 Brandenburg an der Havel 向西看的夜空，箭头指向的是 Altair (牵牛星)


概要


  • Altair 升级为轻客户端功能引入同步委员会，并对验证者奖励和惩罚进行了改革，这将对验证者的收益情况产生影响

  • 总奖励的变化幅度变大；这对个人验证者的影响尤为明显

  • Altair 引入了对滞后证明更严厉的惩罚，这将导致奖励轻微减少

  • 在主网上导致滞后打包证明的事件，对奖励的影响将比现在更大

  • 我们建议验证者密切关注证明的滞后情况；在 Altair 升级之后，对于那些证明打包经常滞后的验证者，他们的收益可能会大大减少


介绍


在上一篇文章，我们分析了以太坊信标链 (现在一般被称为“共识层”) 上的验证者在现实中的表现。信标链自 2020 年 12 月创世以来一直运行顺利 (只发生过几次小插曲)，很多人都将注意力放在伦敦硬分叉 (包括得到广泛讨论的 EIP-1559 费用市场变更) 和即将到来的 eth1＋eth2 合并上，届时以太坊的执行层将转为使用信标链来达成共识，这意味着 PoW 挖矿时代的结束。


同时，尽管关注度没那么高，共识层客户端的开发者一直专注于信标链的第一次升级——Altair 升级。这次分叉将引入轻客户端功能，并将作为以太坊权益证明共识机制协调过程的第一次排练。Altair 升级规范吸取了自信标链创世以来的一些经验教训，改善了它的激励结构和性能，部分通过改变奖励和惩罚的分配方式来实现，因此将对验证者奖励造成一定程度的影响。


在这篇文章，我们将主要研究 Altair 升级将带来的经济上的变更。我们将尝试了解对验证者可能产生的影响，通过使用主网的数据 (和一些假设)，看看假如 Altair 升级在信标链创世时就启动了，验证者奖励会有什么不同。这将有助于验证者了解，继 Pymont 和 Prater 测试网升级后，主网进行 Altair 升级后可以有哪些期待。自从发现了在 Prater 测试网上的问题后，主网升级预计将在 10 月中旬左右启动。


奖励方案变更


第一个需要了解的变更是，在 Altair 升级下，基础奖励 (basic reward) 的含义略有不同。基础奖励指的是每个 epoch 分配到的奖励的基本单位。之前，每履行了四项验证者职责 (来源检查点投票、目标检查点投票、区块链头投票和打包区块提议) 中的一项就可以最多获得一整份基础奖励。但是，在 Altair 升级下，我们重新定义了基础奖励，它变成了一个完美验证者在履行所有职责时，每个 epoch 所获得的长期平均奖励。我们保持最高发放量不变，但验证者不是收到几倍的基础奖励，而是他们每个职责在基础奖励的比例。


奖励权重

除了重新定义“基础奖励”外，分配给多个职责的比例，和职责本身也有变化。下面的图表显示了在假设完美验证者表现的情况下，“之前”和“之后”的分配权重。


奖励分配图 [以下为代码]


import matplotlib.pyplot as plt

head ＝ 1
source ＝ 1
target ＝ 1
delay ＝ 7/8
proposer ＝ 1/8

fig, (ax1,ax2) ＝ plt.subplots(1,2,figsize＝(16,10))

ax1.pie(
    [head, source, target, delay, proposer],
    labels＝[‘head‘, ‘source‘, ‘target‘, ‘delay‘, ‘proposer‘],
    autopct＝‘％1.1f％％‘
)
ax1.set_title(
    "Pre-Altair Reward Weights for Validator Duties"
)

HEAD_WEIGHT ＝ 14
SOURCE_WEIGHT ＝ 14
TARGET_WEIGHT ＝ 26
SYNC_WEIGHT ＝ 2
PROPOSER_WEIGHT ＝ 8
WEIGHT_DENOMINATOR ＝ 64

ax2.pie(
    [HEAD_WEIGHT, SOURCE_WEIGHT, TARGET_WEIGHT, SYNC_WEIGHT, PROPOSER_WEIGHT],
    labels＝[‘head‘, ‘source‘, ‘target‘, ‘sync‘, ‘proposer‘],
    autopct＝‘％1.1f％％‘
)
ax2.set_title(
    "Altair Reward Weights for Validator Duties"
)
plt.show()




提议者和滞后奖励

在上面的图表中，要注意的第一项变化是提议者奖励提升至原来的 4 倍。你可能还记得，在 Altair 之前的规范中，我们有四项相等的证明奖励，但第四项奖励是在证明验证者和区块提议者间分的，其中证明验证者会得到奖励的 7/8，与滞后的打包时间成反比增减，而区块提议者会获得奖励的 1/8。如 Danny Ryan 在信标链创世后不久指出，区块提议者分到如此低比例的验证者奖励从来都不是研究者的本意，它明显是该规范的一个漏洞。这个错误在 Altair 规范里得到了修正，区块提议者将如一开始计划般分得总奖励的 1/8，而不是在 Altair 前的规范里的 1/4 总奖励的 1/8。


同时，“滞后”奖励 (delay reward) 会被完全移除。相反，其他证明奖励 (区块链头、来源检查点和目标检查点) 被赋予了不同的打包期限：


  • 正确的区块链头投票只有在下一个 slot 里被打包才会获得奖励


  • 正确的来源检查点投票只有在 5 个 slot 内被打包才会获得奖励 (即 integer_squareroot(EPOCH_LENGTH))

  • 正确的目标检查点只有在 32 个 slot 内被打包才会获得奖励 (即 EPOCH_LENGTH)


这很好地以合乎逻辑的方式奖励及时的证明投票。特别是，区块链头的投票只有在快速收到的情况下才能帮助网路在链头达成共识。目标检查点的投票只有在一个 epoch 内被打包才对网络有意义，因此验证者只有在它在 32 个 slot 内被打包才能因对目标检查点正确投票而得到奖励。来源检查点投票本身实际上并不有助于区块链达成共识 (而只有当有正确来源检查点投票的证明被打包了才起作用)。因此，来源检查点投票的奖励要在证明在 5 个 slot 内被打包才会被支付出去。这个期限—— integer_squareroot(EPOCH_LENGTH) ——选的是其他两项奖励在几何学上一半的时间。所以之前用于正确区块链头、目标检查点和来源检查点投票的分级奖励方案在某种程度上类似于了上一版本规范中的“滞后奖励”，即给证明更快被打包的验证者支付更多奖励。


最后，证明奖励的权重已经被改变了，与来源检查点和区块链头奖励一并从 16/64 变成 14/64，而目标检查点奖励从 16/64 上调至 26/64。这样的调整反应的是这样的一个现实——正确的目标检查点投票是证明过程中最重要的部分。只要网络能在每个 epoch 的目标检查点上达成共识，这条链就仍然可以做最终敲定。


同步委员会

奖励方案的最后一个不同点在于给同步委员会新增了一项奖励。这实现了 Altair 升级引入的关键新功能，轻客户端就是通过它与网络同步数据的。同步委员由一组 512 名的验证者组成，它对每个信标链头签名。为了确保轻客户端能够在不保存整个信标链状态的情况下了解同步委员会的参与者有谁，同步委员会的轮换相对没那么频繁——周期为每 256 个 epoch 或大概 1 天 。


与区块提议的机制一样，同步委员会的成员是在验证者中随机选择的，他们在每个同步委员里的时长为 256 个 epoch。在这个过程中，那些验证者可以在他们所参与同步委员会的每个 slot 获得同步委员会的奖励。


计算同步委员会数量和预计每个验证者被选进委员会的次数 [以下为代码]


SECONDS_PER_SLOT ＝ 12
SLOTS_PER_EPOCH ＝ 32
EPOCHS_PER_COMMITTEE ＝ 256
COMMITTEE_SIZE ＝ 512
SECONDS_PER_YEAR ＝ 31556952

seconds_per_committee ＝ SECONDS_PER_SLOT ＊ SLOTS_PER_EPOCH ＊ EPOCHS_PER_COMMITTEE
committees_per_year ＝ SECONDS_PER_YEAR / seconds_per_committee

print(f"{committees_per_year:.1f} sync committees are selected each year")

NUM_VALIDATORS ＝ 200000

expected_committee_selections_per_year ＝ committees_per_year ＊ COMMITTEE_SIZE / NUM_VALIDATORS

print(f"with a validator set of {NUM_VALIDATORS} validators, on average each validator will be assigned "
      f"to a sync committee {expected_committee_selections_per_year:.2f} times per year")


输出：每年会选出 321.0 个同步委员会     在一个有 200,000 个验证者的验证者集里，平均每个验证者每年被分配到一个同步委员会的次数是 0.82


与我们在之前关于信标链奖励的文章中分析提议职责变化的方法类似，我们可以用二项分布来分析一个验证者预计可以被选中参与同步委员会次数的变化差异。在下面的计算里，我们将假设验证者总人数为 200,000。


[以下为代码]

from scipy.stats import binom

SECONDS_PER_YEAR ＝ 31556952
SECONDS_PER_SLOT ＝ 12
SLOTS_PER_EPOCH ＝ 32
COMMITTEE_EPOCHS ＝ 256
NUM_VALIDATORS ＝ 200000
COMMITTEE_VALIDATORS ＝ 512
epochs_per_year ＝ SECONDS_PER_YEAR / (SECONDS_PER_SLOT ＊ SLOTS_PER_EPOCH)

x ＝ [el for el in range(7)]
p_selection ＝ COMMITTEE_VALIDATORS / NUM_VALIDATORS
committees_per_year ＝ epochs_per_year / COMMITTEE_EPOCHS
y ＝ binom.pmf(x, committees_per_year, p_selection)

fig, ax ＝ plt.subplots(figsize＝(12, 8))
ax.bar(x, y)
ax.set_xlim(xmin＝-0.5)
ax.set_ylim(ymin＝0)
ax.set_title(‘Probability mass function (200,000 validators) — number of sync committees per year‘)
ax.set_xlabel(‘Number of sync committee selections in a year‘)
ax.set_ylabel(‘Proportion of validators‘)

print(y[0])


输出：0.4391785090173583



因此，在 200,000 个活跃验证者中，几乎有一半的验证者在一年中不会被选入一个信标委员会。如果验证者集的容量增加，被选中进入验证者委员会的概率将下降到更低。


给完美参与者建模


记住这点后，现在开始为假设所有验证者都完美履行他们职责的情况下，可能的年度可得奖励分布建模。回顾一下，在 Altair 升级前，即使在完美参与的情况下，也会因为提议者职责是随机分配的而在验证者间存在差异。在 Altair 升级后，区块提议的奖励值翻了 4 倍（从总奖励的 3.1％ 上升到 12.5％），因此验证者奖励的差异也会相应扩大。同步委员会的引入是导致验证者奖励差异的一个新来源。


由于同步委员会奖励的获得是随机的，且独立于提议者奖励，我们可以通过以下方法计算年度总奖励的分布：计算一年中num_proposer_duties (履行提议区块的次数) 和 num_sync_committees (参与同步委员会的次数) 的每种可能组合，与每种分布的概率相乘，然后把奖励加起来。然后，我们可以把这个分布与描述 Altair 升级前验证者奖励差异的简单的二项分布进行对比。


给完美参与的年度奖励建模 [以下为代码]


import math
import pandas as pd

def get_quantile(pmf, quantile):
    cumulative ＝ 0
    for x, prob in sorted(pmf.items()):
        cumulative ＋＝ prob

您可能感兴趣的文章:

相关文章