LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 行情分析 > HBA公链 | 参与以太坊2.0验证节点应该知道些什么?

HBA公链 | 参与以太坊2.0验证节点应该知道些什么?

2020-08-05 财经小方 来源:火星财经
一言以蔽之,为了安全。签名密钥必需保证随时可用。因此,签名密钥需要保持在线。由于保持联网的东西很容易遭到攻击,让签名密钥兼具取款功能是不明智的。

节点验证工作不是一定赚钱的

简介

1. 到底什么是「验证者(validator)」?

验证者是参与 ETH 2.0 协议共识机制的实体。

用大白话来说,就是持续运行特定的一段计算机程序的人。这个程序会提议并证明新的区块,使之能添加到区块链上。

换言之,你可以将验证者看作新区块的投票者。一个区块获得的票数越多,被添加到区块链上的可能性就越大。

重要的是,验证者的投票权重由其权益数量(the amount it has at stake)决定。

2. 保证金合约(deposit contract)是什么?

你可以将保证金合约理解为以太坊账户和 ETH 2.0 验证者之间的资金转移通道。

保证金合约的状态指明了谁存储了保证金、由谁来参与验证、保证金数量有多少,以及谁能取出这些资金。

3. 为什么验证者需要先存入保证金?

系统需要扣押验证者的资金,以便在某个验证者被证明行为不轨之时对其进行惩罚。

换句话来说,为保证这些验证者都遵守协议,要让这些验证者的行为都会产生经济后果。

4. 验证者需要质押多少 ETH?

在验证者可以开始保护网络之前,ta 需要质押 32 ETH。这 32 ETH 就是验证者的初始余额。

5. 质押量超过 32 ETH 有什么好处吗?

没有。单个验证者存入超过 32 ETH 不会获得任何优势。

将有效质押量设定在 32 ETH 有助于推动权力的去中心化,因为这样可以防止某个验证者的投票权重过大。

请记住,验证者的投票权重取决于其权益数量。

(译者注:实际上,验证者的投票权重取决于其「有效余额(effect balance)」。有效余额并不是账户的表面余额,有效余额有个上限是「32」,假设一个验证者一直勤勤恳恳地赚钱,其有效余额也不会超过「32」,同理,其被罚没时,也不会一次性被罚没超过 32 ETH。原文此处用语是「the amount it has at stake」,虽然也嫌太模糊,但显然不能直译成「验证者已存入的数额」。汉语中缺乏与「at stake」对应又不显累赘的说法,故此处译为「权益数量」,实属无可奈何)

验证者职责

1. 经济激励机制是如何帮助用户保持活跃和诚实的?

除了会因为离线而遭受惩罚之外,验证者还会因为作恶而遭受惩罚——例如,投票给无效或有冲突的区块。

另一方面,如果验证者 所提议/所见证 的区块被添加到了区块链上,验证者就会获得奖励。

基本概念是:

帮助网络达成共识的行为会获得奖励

妨碍共识的无意行为(或不作为)会招致轻微惩罚

恶意行为会招致严重惩罚(或称罚没)

换言之,验证者在努力获得奖励的同时也在为整个网络做贡献。

2. 奖励/惩罚 是如何发放的?

请记住,每个验证者都有自己的余额——初始余额则可在保证金合约中看到。以太坊网络规则会基于验证者的履职情况定期更新其余额。

换言之,验证者所获得的奖惩都会在余额中反映出来。

3. 奖励/惩罚 多久发放?

大约每 6.5 分钟(即,一个 epoch)发放一次。每个 epoch 期间,网络都会评估每个验证者的表现,并相应给予奖励或惩罚。

4. 奖励/惩罚 金额有多大?

这个问题很难回答,因为在计算时需要考虑很多因素。

验证交易所获得的奖励主要受网络总权益量(即,验证者总数)的影响。根据总权益量,验证者的最高年化收益率可能在 2% 至 20% 之间。

在验证者总数固定的情况下,奖励/惩罚主要取决于验证者的余额规模——如果提供证明的验证者的余额越高,ta 所受到的奖励/惩罚就越高;余额越低,奖励/惩罚就越低。

请注意,这种动态机制是以不那么明显的方式运作的。要想了解其具体原理,你先要理解有效余额(effective balance)这个概念。如果你对这个概念还不熟悉,我们建议你阅读这篇文章(编者注:见文末超链接)。

5. 为什么奖励取决于网络中的验证者总数?

区块奖励是根据网络中的 ETH 总权益量按比例计算的。

简单来说,如果 ETH 总权益量很少,奖励(利率)就很高,但是随着权益量增加,每个验证者所获得的奖励(利率)就会降低。

为什么会有这种动态调整?虽然本文不会揭开其中的真相,但是直觉告诉我们,为了确保网络良好运转,验证者总数不能低于某个下限(ETH 总质押量也是)。因此,为了激励更多验证者参与进来,利率需要维持在较高水平,直到验证者总数达到下限为止。

6. 如果离线,验证者会遭到什么惩罚?

视情况而定。除了实际余额的影响之外,还需要注意两个重要情况:

如果绝大多数(2/3)验证者都在线,那么离线所造成的惩罚较低,因为有足够多的验证者在线,可以实现区块的终局性。这是预料之中的情况。

如果有超过 1/3 的验证者同时离线,离线惩罚就会较高,因为网络无法继续实现区块的确定性。这种属于不太可能发生的极端情况。

请注意,如果是第二种情况,离线验证者会在 21 天内逐渐损失高达 50%(16 ETH)的权益量。21 天之后,这批验证者就会被逐出验证者池。这样一来,网络就可以恢复正常,开始达成区块的终局性。

7. 正常运行时间占到多大比例,诚实的验证者才能实现盈利?

总的来说,只要验证者的正常运行时间超过 50%,就能实现盈利。

这就意味着,验证者不需要备份客户端或冗余的网络连接,因为离线的后果并没有那么严重。

8. 作恶的验证者会遭受什么惩罚?

同样视情况而定。恶意行为(例如,投票给无效或有冲突的区块)会让验证者遭到罚没。

最低罚没金额是 1 ETH,但是如果其他验证者在同一时间遭到罚没,这一金额还会增加。

其目的是尽可能减少验证者因无心之失而蒙受的损失,同时抑制协同攻击。

9. 罚没是什么?

罚没有两个目的:(1)大幅提高攻击 ETH 2.0 的成本,使攻击无利可图;(2)通过检查验证者是否履行其职责来防止他们偷懒。所谓的罚没,指的就是如果有验证者被证明作恶,ta 的权益(中的一部分)就会被销毁。

遭到罚没的验证者无法继续参与网络的共识机制,会被强制退出。

(译者注:在这几个问题的答案中没有显明的信息是:对一名验证者来说,每一个 epoch(6.4 分钟)就要发出一条见证消息(attestation,包含投票内容),而且需要发出消息的时间在一个 epoch 中的位置不是固定的。显然,上述验证者职责的履行不可能由人手动操作程序来执行,必定是自动化的。因此,验证者会不会被罚没,高度依赖于所用的客户端软件。因此,有意自己运行验证者的用户,首先要关心自己所用的客户端性能好不好,保护措施到不到位。)

密钥

1. 如果签名密钥(signing key)丢了会怎么样?

如果签名密钥丢失,验证者就无法继续提议及见证区块。

随着时间的流逝,验证者的余额就会逐渐减少,因为 ta 会因为无法参与共识流程而遭到惩罚。一旦验证者的余额只剩下 16 ETH,系统就会自动将 ta 逐出验证者池。

不过,这件事并非完全没有转机。如果验证者的签名密钥是使用 EIP2334(根据默认引导流程)生成的,就可以随时根据取款密钥重新计算签名密钥。

在取回保证金时,用户也需要用到取款密钥,而且取款时要等待大概一天才能到帐。

请注意,如果同一时间段内退出或被踢出验证者池的人很多,延迟期可能会延长。

(译者注:在 Phase 0 阶段,不会开启验证者取回保证金的功能。)

2. 如果取款密钥(withdrawel key)丢了会怎么样?

如果弄丢了取款密钥,验证者就再也拿不回属于自己的资金了。

因此,你最好使用助记词(mnemonics)来创建取款密钥以便备份。如果验证者是通过 Medalla 测试网的引导流程加入的,则取款密钥是默认通过助记词创建的。

3. 如果取款密钥被偷了会怎么样?

如果取款密钥被盗,盗窃者可以转走验证者的余额,但是必须在验证者退出之后。

如果盗窃者没有该验证者的签名密钥,就无法让验证者退出。

验证者可以先使用签名密钥退出验证者池,然后在盗窃者之前使用取款密钥将资金转走。

(译者注:我认为这个回答没有提示大家真实的风险。根据问题一的回答,如果用户的签名密钥是用取款密钥生成出来的,则偷盗了一把取款密钥的人,是有可能计算出验证者所用的取款密钥的,因此验证者的取款密钥也将变得不再安全,尽管取款密钥生成签名密钥的方法可以提高取款密钥的安全性,但这个风险并不是不存在。应该提醒大家的是,取款密钥始终是重中之重,一定要保护好这把密钥。回答里面提供的逃离方法仅在取款功能正常时才能使用,但 Phase 0 阶段不会开启取款功能,偷盗了取款密钥的人有充分长的时间可以埋伏。)

4. 为什么不能将这两个密钥合二为一?

一言以蔽之,为了安全。签名密钥必需保证随时可用。因此,签名密钥需要保持在线。由于保持联网的东西很容易遭到攻击,让签名密钥兼具取款功能是不明智的。

(译者注:签名密钥是验证者用来对见证消息签上数字签名的,需要经常被客户端调用以履行验证者职责。所以说签名密钥是联网的。)

本文来源:财经小方
原文标题:HBA公链 | 参与以太坊2.0验证节点应该知道些什么?

—-

编译者/作者:财经小方

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...