大型的分布式多客户端区块链启动事件并不常见。昨天(7 月 30 日)是 ETH 1.0 诞生 5 周年:由此可见,如此重大的诞辰盛事更是少之又少。

ETH 2.0 测试网 Medalla 于 8 月 4 日上线,这可能是今年晚些时候信标链正式推出前的唯一一次预演。

ETH 2.0 创世机制有一点(也就是我们所说的区块链自引导流程)复杂。我打算详细解释一下。对于实际的技术规范,你可以参见我在 “ETH 2.0 规范注解” 中的评论。

在下文中,“创世” 指的是信标链上线并开始处理见证消息(attestation)和区块的起始时刻,也就是 epoch 0 的 slot 0 的开始。

(如果你不想看长文,可以直接跳转到“场景”一节开始阅读。)

验证者保证金

这里先介绍一下背景。只要向 ETH 1.0 的合约发送 32 ETH 的保证金以及其它一些数据,任何人都可以成为 ETH 2.0 的验证者。例如,你可以通过 Lanchpad 门户成为 Medalla 测试网的验证者。要注意的是,在 Medalla 测试网上,我们使用的是 Goerli 测试网 ETH !不要尝试将主网 ETH 发送至合约。当然了,等到信标链正式上线时,我们将使用真正的主网 ETH 。

保证金合约只会对 有效 保证金作出反应,即金额达 32 ETH 及以上的单笔保证金、总计金额达 32 ETH 及以上的多笔保证金(需要检查额外的数据,例如,密码学签名)。任何无效或不足的保证金都会忽略不计。

信标链节点

在预创世阶段,只有信标链节点会参与 ETH 2.0 网络;一旦创世之后,验证者就可以立即参与共识机制。信标链节点维护系统状态,并在点对点网络上互相通信。

因此,在创世之前,会有一些信标链节点监听 ETH 1.0 ,并监控保证金合约中的有效保证金。实际上,信标链节点不需要一直监控 ETH 1.0 :ETH 1.0 上的区块是有时间戳的,因此在创世之前,节点随时都能赶上进程。

众所周知,ETH 1.0 链是可以回滚的,原本已经在链上的交易也可能因为区块链改变而失效。这就是为什么你将 ETH 转入交易所时,需要等待 30 个区块才能确保交易确认。回滚的范围通常很小——只有 1 至 2 个区块 —— 但是当网络遭受攻击时,回滚的范围会大得多。为了避免 ETH 2.0 发生回滚,我们在同步 ETH 1.0 时非常谨慎地保持 14*1024 秒(约合 4 个小时)的延迟。我称之为对 ETH 1.0 的 “跟随距离(follow distance)”。

何时?何人?

对于创世来说,最重要的两个问题是 “何时” 与 “何人” ?具体来说,就是 “创世会在何时发生?”以及 “谁会成为创世验证者?” 这两个问题决定了信标链的创世状态,其它状态都源自创世状态。

大致过程如下:

监控 ETH 1.0 上的保证金流入情况。等过了足够长的时间,有了足够的保证金,创建创世状态。两天之后,通过触发创世事件来启动 ETH 2.0。

具体来说,在步骤 2 ,我们要找到第一个满足以下两个条件的 ETH 1.0 区块:(a)锁定了足够多的保证金;(b)区块中的时间戳没有过早。创世状态由这个区块决定。

影响 “何时” 和 “何人” 的三大主要参数设置如下:

MIN_GENESIS_TIME,指的是创世事件最早发生的时间。就 Medalla 而言,就是 Unix 时间 1596546000 ,即, 北京时间 8 月 4 日晚 9 点(周二)。GENESIS_DELAY 是 172800 秒,约合 48 小时。这是从创建创世状态到触发创世事件之间的时间间隔。客户端团队可以利用这段时间将创世状态刻录到他们的信标链节点软件中。这样一来,那些不运行验证者节点的信标链节点就不需要继续监控 ETH 1.0 链了。我们也有时间来组织创世直播和派对MIN_GENESIS_ACTIVE_VALIDATOR_COUNT 指的是在创建创世状态之前,我们需要在 ETH 1.0 保证金合约中锁定的有效保证金的最低笔数。就 Medalla(以及主网)而言,最少需要 16384 名验证者。

从 Medalla 测试网启动中学到的教训:虽然我们有时间组织派对了,但 44 个小时对确保启动节点状态良好、升级后的客户端软件能包含所有必要信息、终端用户易于使用来说,还是有点赶。我们有可能会提高主网的 GENESIS_DELEY。

场景

创世状态是在首个满足以下两个条件的 ETH 1.0 区块的基础上生成的:

这个区块创建时,验证者人数不得低于 16384 (MIN_GENESIS_ACTIVE_VALIDATOR_COUNT)。时间戳没有过早(不早于 MIN_GENESIS_TIME - GENESIS_DELAY)。

根据上述两个条件的满足顺序,创世流程可以通过以下两种方式完成:

1. 先达到最低保证金要求

在这种情况下,条件 1 先得到满足。在最早创世时间之前,我们已经获得了足够多的保证金。

根据 MIN_GENESIS_TIME - GENESIS_DELAY(最早创世时间减去创世时延)可知,Medalla 的条件 2 时间点是北京时间 8 月 2 日晚 9:00(周日)。

我们用来触发创世事件的 ETH 1.0 区块必须在这个时间点之后挖出。假设这个区块在北京时间 8 月 2 日晚 9:00:05 (9 点过后 5 秒)挖出。

如果保证金合约收到了至少 16384 笔有效保证金(包括这个区块里面的所有保证金交易),那么保证金合约中收到的所有保证金也都包含在创世状态中。因此,ETH 2.0 链上有超过 16384 名创世验证者。(在 Altona 测试网上,我们将 MIN_GENESIS_ACTIVE_VALIDATOR_COUNT 设置为 640 ,但是最后的创世验证者有 685 位。)

这个 ETH 1.0 区块会触发创世状态的计算。Medalla 创世事件将在这个区块的时间戳的 48 小时后准时发生。接着上文的例子,就是北京时间 8 月 4 日晚 9:00:05 。

- 红色区块就是首个满足上述两个条件的 ETH 1.0 区块 -

要注意的一点是,考虑到 ETH 1.0 跟随距离,我们实际上要等待 4 小时之后才能获得创世状态。也就是说,在当前场景下,我们要等到北京时间 8 月 2 日下午 5 : 00 才能获得创世状态。

总结

如果先达到最低保证金要求,创世事件将在最早创世时间的几秒后触发。在创世事件触发的 48 个小时之前完成注册的验证者都将包含在创世状态中。

2. 后达到最低保证金要求

在这种情况下,条件 2 先得到满足。由于保证金流入速度较慢,没有在指定时间达到最低要求。

在这种情况下,我们用来触发创世事件的 ETH 1.0 区块必须包含第 16384 笔有效保证金。假设这个区块在北京时间 8 月 5 日晚 8:34:56 挖出。

现在,信标链状态将包含 16384 名验证者以及这个区块中其它有效保证金。因此,如果这个区块包含多笔保证金,那么信标链状态中包含的保证金将略高于最低要求。

创世时间是该区块的时间戳的 48 小时后。接着上文的例子,就是北京时间 8 月 7 日晚 8:34:56。

- 红色区块就是首个满足上述条件的 ETH 1.0 区块 -

再强调一遍,考虑到 ETH 1.0 跟随距离,我们要等到这个 ETH 1.0 区块挖出 4 小时后才能获得创世状态。

总结

如果保证金流入速度较慢,创世事件将在包含第 16384 笔有效保证金的 ETH 1.0 区块挖出后的第 48 小时触发。创世状态将包含至少 16834 名验证者,还可能因为这个 ETH1.0 区块中包含的保证金交易数量(使验证者总数超过 16834 个)而稍有增加。

结论

本文已经介绍了 ETH 2.0 创世机制的基本内容。

如果你想成为 Medalla 测试网上的创世验证者,请务必在北京时间 8 月 2 日晚 9:00 将保证金发送至保证金合约!

如果你没有在创世状态确定前提交保证金,你就只能按照质押时间排队等待,等到创世后才能加入验证者集合。排队时间可能需要几小时或几天。