新闻开发人员企业区块链解释事件和会议新闻时事通讯
订阅我们的新闻.
电子邮件地址
我们尊重您的隐私
主页博客开发人员
我成为以太坊2.0验证者的旅程，第2部分
选择硬件和软件运行以太坊2.0验证程序客户端时应考虑哪些事项？Coogan Brennan 2020年12月5日发布于2020年12月5日
注意：您仍然可以成为以太坊2.0网络上的验证器！将有一个等待时间将被激活为验证程序-截至2020年12月4日，等待时间大致为 9.9天. 请参阅本系列第1部分中的放样步骤.
- 免责声明
- 介绍
- 验证器配置注意事项
- 未来的证明硬件
- 运行或不运行Eth1客户端?
- 虚拟主机与本地主机
- Eth2客户选择和避免罚款
免责声明
这是我作为ConsenSys的一名员工写的帖子，也是打算在信标链上投入资金的人。前一条声明意味着我会优先考虑ConsenSys产品（ConsenSys产品通常是以太坊中同类产品中最好的，而且我还可以与工程团队联系，他们可以帮助我回答问题和排除故障）。后一种说法意味着我正在针对成本和易用性进行优化：我没有成千上万的ETH来产生丰厚的回报，因此我采取一些捷径。我做出这些决定的目的是使对Ethereum 2.0的赌注尽可能简单明了，并可供个人使用，但要权衡去中心化和隐私权。但是，您可以按照以下教程的主要内容进行选择。实际上，如果您能做到这一点，我鼓励您!
最后，在以太坊2.0中投注是高度实验性的，涉及长期的承诺（我分配了三年）。如果您对仍处于开发阶段的高风险服务员感到不满意，请不要参与。如果您不确定是否应该投资，请加入 ConsenSys不和谐 并在＃teku-public频道中提问.
介绍
在上一篇文章中，我们讨论了以太坊2.0部署的原因，并逐步介绍了在以太坊1.0主网存款合同中加入32 ETH的情况。我们谈到了密钥生成以及如何进行放样过程 发射台 将以太坊1.0链接到2.0.
11月23日，满足了启动以太坊2.0的最低抵押ETH量（约524,288）。人们可以继续参与该合同，截至12月4日，验证人的数量已超过33,000.
成为验证者进入Genesis区块非常令人兴奋，但几秒钟后，我在内部ConsenSys赌注频道中获得了与同事Aaron Davis相似的体验：我签署了什么疯狂的任务？幸运的是，我有足够的才智和才华横溢的技术人员可以为这个卢布提供一些技巧，指示和关于运行立桩基础设施的见解。我希望在这里将宝贵的建议的一小部分传达给任何其他有兴趣的人士.
这就是本文的第一部分：选择运行Ethereum 2.0验证程序客户端的硬件和软件时应考虑哪些事项？第二部分将逐步介绍我为验证器客户端选择的特定硬件/软件组合。您为配置做出的选择将取决于您的资源，个人喜好和技术能力。我会尽力强调个人偏见和环境如何影响我的选择.
最后，在我们开始之前，我想重申一下这些帖子，就像我输入32 ETH的经验所产生的日记条目一样（尽管日记条目具有广泛的技术支持）。因此，随着信标链的发展，我可能会稍微改变自己的方法。例如，我一直认为我肯定会使用AWS。正如您将在下面阅读的那样，我现在正在重新考虑这一点。我还将非常清楚赌注的财务要素。抵押是支持以太坊生态系统的一种方式，但是对于可持续的公共使用，拥有ETH的人们也应该可以使用并有可能.
未来的证明硬件
今天运行验证器的基本要求相对容易满足。玛拉·施密特（Mara Schmiedt）和科林·迈耶斯（Collin Meyers） 验证者指南 对Bankless来说，最低要求很好。随着开发的不断发展，确定以太坊2.0验证器设备的最具挑战性的方面是平衡信标链第0期的当前需求与任何未来当前未知的需求。 （如果您愿意密切注意验证器并能够快速轻松地解决更改，则不必担心）
本·埃丁顿（Ben Edgington），Teku项目经理兼发行人 Eth2.news, 为我提供了一些边缘情况，其中网络可能需要更多的验证器客户端。短期而言，最大的担忧是 Medalla时间服务器事件, 其中，Prysm客户端中的错误和后续修复中止了测试网络上的最终确定（大致而言，网络无法“产生代码块”）。由于网络上没有终结性（没有“已确认的块”），因此验证者必须在RAM中保存比平常更多的交易。.
具有8GB RAM的计算机（在正常情况下本来绰绰有余）开始遇到“内存不足”问题，这可能导致大幅削减。像这样的峰值，尽管不寻常，但对于阶段0主网来说也不是不可能的.
该网络未来的配置歧义是以太坊1.0和2.0的合并以及分片的引入。我们仍然不知道这些合并何时发生或它们究竟需要什么。我想要一个强大的CPU主干进入阶段0（4个虚拟内核，16GB RAM和100GB SSD），然后将精力集中在将来围绕存储空间的调整上（这里留有摆动的空间）。请注意，这可能被认为是过大的，吃掉了赌注的奖励.
这些是未来的“未知未知数”，让我们讨论当今验证器的主要配置决策点.
运行或不运行Eth1客户端?
我尝试让训练营的学生尽可能多地接受培训：同步以太坊1.0客户端。这是一个公开的秘密，实际上托管一个“完整”的以太坊1.0节点是一种爱的举动，而不是强化的囚徒困境解决方案。必须使用“全”作为引号，因为即使以太坊核心开发人员也很难在“全节点”实际含义的定义上达成共识.
我们都可以同意的一件事：同步一个以太坊1.0客户端要花费比您想象的更多的时间和存储空间。我们的验证器需要一种查询以太坊1.0网络数据库的方式（稍后我们将介绍原因）。如果您想节省空间和本地同步的麻烦，可以使用Infura端点, 可免费注册获得.
即使这样可以节省大量的存储和后勤问题，它的确同时牺牲了Eth1和Eth2网络的一定数量的分散性。如果Infura要倒下, 这是极为罕见的，但确实会发生, 它将在以太坊2.0验证器用于其以太坊1.0端点时在整个以太坊2.0验证器上引起连锁反应。需要考虑的事情!
（需要明确的是：同步以太坊完整节点的难度与以太坊世界状态的本质有关，而不是与以太坊1.0核心开发人员合作，他们为解决这一极具挑战性的问题做出了出色的工作。
虚拟主机与本地主机
对我而言，下一个考虑因素是在本地（在我的家中）或虚拟地（在虚拟服务提供商（如Amazon Web Services（AWS），Digital Ocean等）上）托管验证程序节点。正如我在上一篇文章中提到的那样，我不相信自己在家中运行一个一致的验证器节点，即使是将旧笔记本电脑放在某个地方也是如此。笨拙又愚蠢，我要么把它踢过去，要么就忘了它.
我之所以选择在AWS上运行我的节点，是因为这是我最熟悉的（但是，在经历了整个过程之后，我会对此决定进行第二次猜测，稍后再讨论）。这里的权衡又是去中心化：如果AWS出现故障或出现任何问题（就像最近一样），我任由他们摆布。如果有足够多的人在AWS上运行节点，则可能会影响更大的以太坊网络.
人们可能会为此自行选择。本地托管是一种特殊的项目，并非每个人都有时间，资源或承诺。尽管虚拟主机是一种集中力量，但我选择使用虚拟主机是因为其易于使用并且（希望）有保证的正常运行时间.
如果您想在本地运行验证器节点，仍然可以按照本教程的一般指导进行操作。, Somer Esat与不同客户的精彩教程系列 或者 甚至可以将带有8GB RAM的Raspberry Pi Model 4B与ARM上的以太坊同步. （在Raspberry Pi上进行同步仍处于试验阶段，人们应该等到ARM团队的以太坊确认其稳定性之后）
Eth2客户选择和避免罚款
另一个主要选择是现有客户端中的Ethereum 2.0客户端： 灯塔, 乐星, 雨云, 幻影 和 特库. 我对Teku抱有很大的偏见，并且不够聪明，无法辩论客户的优点. 本文 是Medalla客户表现的不错概览。 （请记住，Medalla对处理器的需求比对主网的需求要大得多。）
股权证明包含明确的激励措施，以鼓励网络上的正确行为。这些采取的形式是：使验证器脱机，使验证器脱机；大幅削减行动者，以明知或其他方式对网络采取恶意措施.
最常见的问题是确保您的验证器可用于网络。这意味着确保您的验证器在线。此问题有一个DevOps方法-创建监视和警报系统以在验证程序脱机时向您发出警报-我将不在此处介绍.
但是，还有另一种方法无法使用网络，也就是说，如果您的客户端由于某种原因而开始行为异常。后 时间服务器错误 导致Medalla的网络速度变慢，Eth2核心开发人员聚集在一起进行开发 “ [a]用于传输密钥签名历史记录的标准格式，使验证者可以轻松地在客户端之间进行切换，而无需签名冲突的消息。” 并非所有客户都有此保护，但Teku却有。在这里，您可以了解有关使用Teku的Slash Protection（默认运行）的信息，包括在Teku节点之间或非Teku到Teku节点之间的迁移.
如果您的客户端确实有问题，并且需要重新启动整个网络，则需要注意弱主观性。工作量证明允许任何人回到网络的起源块，并从头开始不信任地建立网络状态。但是，股权证明在这方面有一个问题：如果某个特定点的三分之一的网络验证器仍在出口处继续签名并进行证明，则他们可以更改网络状态并将错误数据提供给与该节点同步的节点。如果恶意行为者在同步节点到达验证者撤回资金的地方之前就抓住了该同步节点，则该网络。您可以在此处了解更多信息，但是简短的答案是您需要具有“弱主观性检查点”或编码状态文件，实质上是网络的存档。 Teku为两者都提供启动标志.
最后一个惩罚问题是最严重的：大幅削减。当涉众违反网络规则时，就会发生削减。这与从离线状态受到惩罚不同。通过提交有冲突的验证者信息，它正在与网络积极合作。有一些非常好的材料可以学习更多有关斜杠以及如何防止斜杠的信息：
要点是不要在多个客户端上运行一个验证密钥。显然，这是造成有史以来第一个大幅削减事件的原因, 发生在12月2日. 自那以来，已经有很多削减了！如果要从一个实例迁移到另一个实例，请进行四重检查，以确保不会有两台计算机使用同一密钥工作：
AWS + Infura + Teku验证程序配置规范
我的创世纪块设置：
操作系统： Ubuntu Server 20.04 LTS（HVM）（亚马逊网络服务）
处理器： 英特尔至强白金8000系列处理器，3.1 GHz。 （亚马逊网络服务）
记忆： 4个虚拟核心，16GB RAM（Amazon Web Service）
贮存： 100GB SSD，300/3000 IOPS（Amazon Web服务）
以太坊1.0客户端： Infura端点（免费套餐）
以太坊2.0客户端： 特库
通过以上所有考虑，我不确定构建验证器设置的最佳方法。对于我自己来说，我想选择一台机器，并且通常不用担心至少要更换两年。这有助于提高验证器的整体成本（我可以通过与虚拟提供商合作几年来获得很大的折扣），而且在拆分服务器方面也不是特别灵活。这种面向未来的方法或“过分规范”的方法有望使我未来两年的生活更加轻松.
最初，我坚信AWS是最好的虚拟平台，这是我将在本文和下一篇文章中使用的服务。但是，在经历了整个过程之后，我意识到对于单个开发人员而言，AWS可能会过大。 AWS的真正优势似乎在于其动态扩展以满足需求的能力，而这需要付出高昂的成本。对于大型企业级项目，但对于单个以太坊2.0，这具有经济意义。 当前的 客户要求不需要如此严格.
我将继续使用AWS，但也可以选择在Digital Ocean上运行实例，这可能更适合于单个开发人员。在以后的更多内容.
设置Infura帐户
我选择将Infura用作我的以太坊1.0端点。目前，信标链正在关注以太坊1.0上的存款合同，以在新的涉众正确地存放32 ETH并提交适当的BLS签名后激活他们.
未来，信标链将开始测试进一步的处理，方法是开始使用以太坊1.0中的状态信息在信标链上创建并行检查点.
如上所述，有两种主要方法可以查看以太坊1.0网络。一种是同步并积极维护以太坊1.0节点，该节点创建本地以太坊1.0状态数据库。另一种是使用像Infura这样的服务，该服务提供了一个简单的以太坊1.0端点，可以通过HTTPS或 Web套接字.
在此处注册帐户. 拥有帐户后，点击左侧的以太坊徽标.
点击右上角的“创建新项目”
命名您的项目（我的为“ Eth 2 Validator”），然后转到“设置”，确保您的网络端点为“ Mainnet”并复制HTTPS端点：
我们稍后将在Teku客户启动命令中使用此命令!
设置AWS实例
在Amazon上设置EC2实例很简单。我们将在这里和那里进行一些调整，以帮助我们的虚拟实例与Teku一起良好地运行.
创建一个AWS账户（不同于Amazon.com账户）并登录到AWS控制台。转到EC2页面，该页面将如下所示：
单击“启动实例”按钮。然后，您会看到以下屏幕：
操作系统
在这里，我们选择要在虚拟实例上使用的机器映像（我认为是操作系统）。我选择的是Ubuntu Server 20.04，这是一个基于Linux的服务器环境。 Ubuntu Server环境与Ubuntu Desktop环境有一些关键的优化差异。就我们而言，主要区别在于Ubuntu Server缺少图形用户界面（GUI）。我们要去的地方只有命令行！让我回到Apple II的日子.
选择操作系统后，我们然后选择实例类型：
我发现此菜单非常庞大，因此我将为您详细介绍一下。在这里，我们为计算机选择计算核心/ RAM功率/ CPU。它是机器的“原始”或“活动内存”，与设备的存储（硬盘驱动器）分开。将其视为我们的虚拟实例的引擎，我们将在其上运行Ubuntu Server操作系统。 AWS将它们分成单独的实例系列，在最左列用字母/数字组合表示.
实例族具有不同的硬件布置，就像不同的汽车发动机具有不同的活塞，塞子和燃料配置以满足不同的需求一样。我们将重点介绍它们的两个“通用计算”实例族，即m5和t3.
我选择的是m5.xlarge实例，该实例提供4个虚拟计算核心（vCPU）和16GB RAM。在运行以太坊2.0主网大约一天后，我的机器使用的可用vCPU的比例不超过4％。如上文“未来验证”部分所述，以太坊2.0网络需求只会增长。但是在接下来的几个月中，如果没有任何长时间的主要网络高峰，我很可能会使用m5.large实例（2个虚拟内核/ vCPU，8GB RAM）很好
比我更精通的技术人员还建议将t3.large实例作为以太坊2.0的合理选择。 t3.large具有2个vCPU和8GB内存，与m5.large相同，但是t3系列的构建目的是为了实现更多的“突发”网络活动（CPU峰值），而不是m5系列为持续的CPU负载而构建.
价钱
在进入存储之前，最后要提到的是价格。与Digital Ocean等其他选择相比，AWS昂贵。您需要根据使用情况分别为CPU（实例系列）和存储（硬盘驱动器）付费。 CPU按小时付费。由于验证者必须24小时在线，因此您可以使用下面的价格表（从2020年12月开始）进行一些粗略的计算：
这些是按需价格。 AWS确实提供了称为 预留实例定价, 如果您承诺拥有一年到三年的虚拟实例，则可以在上述价格表上获得高达50-60％的成本降低。 （感谢Jason Chroman的技巧！）
在EC2主页上，单击左侧菜单上的“保留实例”，如下所示：
点击“购买预留实例”：
在弹出的菜单中，输入实例类型的详细信息和查看价格所需的时间（我选择的是m5.xlarge，期限为36个月）：
点击“搜索”，然后查看价格选项：
价格有很大的折扣，我相信超过50％，但是我被锁定了三年。购买预留实例后，AWS会将其应用到现有的虚拟盒子，或者一旦启动将应用它。请记住，这不包括存储空间（硬盘驱动器）.
注意：我尚未这样做，因为我尚未确信AWS是个人对一到三个Ethereum 2.0验证器节点进行抵押的最佳选择. 我正在按需定价运行实例，以了解提交前的运行情况.
贮存
回到实例启动过程，我们转到“添加存储”标签
我咨询过的杰出技术人员建议存储容量为100GB的通用SSD。存储通常不是Eth2客户端的瓶颈. 但是，这是 没有 运行完整的Eth1客户端. 对于Eth1存储，保守估计约为1TB。如果您不使用Infura，请务必对此进行说明.
我不知道上图中的IOPS列上的单位，但它是硬盘驱动器与CPU通信的输入输出。这是完整的Eth1节点同步的经典瓶颈。如果您希望在此计算机上同步完整的Eth1客户端，但遇到问题，可以在这里查找.
港口
跳过“添加标签”，转到“配置安全组”。这些是为与实例进行不同类型的传入和传出通信而创建的不同开口.
AWS自动打开传统的SSH端口，因为这是我们与实例进行交互的主要方式. 硬币腰果 和 萨默·埃萨特（Somer Esat）的 优秀的指南都建议禁用SSH的密码访问，但是启动实例时，我们会看到它不是AWS的默认选项。但是，最好将SSH端口随机分配为1024-65535之间的数字。这是为了防止恶意行为者通过网络扫描标准SSH端口。大致了解如何保护SSH端口 这里 专门针对AWS 这里.
我们必须添加两个安全规则来容纳Teku客户端，并且它与对等通信有关。区块链网络是去中心化的，即节点之间可以直接对话。与其咨询中央节点，不如通过与许多节点“闲聊”来发展和维持对网络状态的理解。这意味着当一个客户端与另一个客户端握手时，它们交换有关网络的信息。与不同的节点进行足够的时间后，信息会在整个网络中传播。目前，我的Eth2 Validator节点有74个与之聊天的对等节点.
Teku与9000端口上的其他节点通信，因此我们将其打开以支持UDP和TCP, 两种不同的通信协议.
之后，它应该看起来像这样：
SSH密钥和实例启动
最后，转到“审阅并启动”，概述所做的选择。一旦获得批准，将出现一个有关SSH密钥的弹出菜单。我没有显示我的地图，因为它包含敏感信息。即，用于通过SSH（本地命令行）进行身份验证和登录虚拟实例的密钥对。如果您还没有一对，AWS会为您生成一个. 您必须下载该文件并将其像以太坊私钥一样对待！这是连接到您的实例的唯一方法，AWS不会为您保存它.
一切都完成后，将出现以下窗口：
好的！完成后，让我们继续访问和保护我们的实例，然后安装和运行Teku!
存取执行个体
访问AWS实例的主要方法是通过SSH, “用于在不安全的网络上安全地操作网络服务的加密协议。” 如前所述，AWS默认会禁用用于访问实例的密码身份验证。您只能使用实例启动之前生成的密钥对。密钥对应以.pem文件结尾.
AWS提供了一种获取SSH命令的干净方法。在EC2主页面上单击正在运行的实例，右上角有一个按钮显示“连接”：
在下一页中将是一个针对您实例的SSH命令。它的结构如下：
SSH -i "PATH_TO_AWS_KEYPAIR.pem" [受电子邮件保护]_IDENTIFIER.compute-ZONE.amazonaws.com
在终端中输入此命令将开始SSH会话。本地计算机首次询问您是否要信任AWS提供的ECDSA指纹。这是为了防止 中间人攻击 并且，如果有必要，用户可以在以下情况下获取其实例的指纹 这些步骤.
在与当前SSH会话分开的终端中，传输运行Teku所需的验证程序密钥文件。在之前的博客文章中，我们介绍了对32 ETH的赌注，并获取了以太坊2.0的验证器密钥。最后，我们剩下了这个文件结构：
eth2deposit-cli /└──Validator_key_info /├──KEYSTORE-M_123456_789_ABCD.json├──KEYSTORE-M_123456_789_ABCD.txt└──DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json
我们需要将validator_key_info文件传输到我们的虚拟实例。通过安全复制协议（scp），我们可以安全地执行此操作。使用上面目录的路径和上一个SSH命令调整以下通用scp命令：
scp -r -i "PATH_TO_AWS_KEYPAIR.pem" / PATH_TO_KEYS / eth2deposit-cli / validator_key_info / [受电子邮件保护]_IDENTIFIER.compute-ZONE.amazonaws.com：~
（请注意整个命令末尾的“：〜”。）
您应该看到发生了文件传输。如果您导航回SSH会话并输入ls，则应该看到已传输的目录.
安装Teku
现在我们有了所需的验证器文件，我们将安装Teku。首先，我们必须更新现有程序并安装所需的Java系统：
安装Java
sudo apt更新 && 须藤apt install default-jre && 须藤apt install default-jdk
仔细检查Java是否成功安装：
Java版本
安装二进制
在此处找到最新的稳定的Teku版本. 将链接地址复制到tar.gz文件，然后从SSH会话中下载它。这是我的样子，您的版本很可能会有所不同：
curl -JLO https://bintray.com/consensys/pegasys-repo/download_file?file_path=teku-20.11.1.tar.gz
使用以下命令解压缩下载的文件。如果您使用的是其他版本，请将该文件名替换为teku-20.11.1.tar.gz：
tar -zxvf teku-20.11.1.tar.gz
为了清洁起见，请删除tar.gz文件.
完成所有这些步骤后，您的主目录应如下所示（Teku版本号和内容可能有所不同：
ubuntu /└──teku-20.11.1 /├──许可证├──bin /├──lib /├──license-dependency.html├──teku.autocomplete.sh└──验证者_密钥信息/├──KEYSTORE -M_123456_789_ABCD.json├──KEYSTORE-M_123456_789_ABCD.txt└──DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json
创建一个非root用户
此步骤是从Somer Esat的 优秀的Ubuntu / Teku教程
我们将创建一个名为teku的非root用户，该用户可以操作Teku。在下面键入以下内容：
sudo useradd –no-create-home –shell / bin / false teku
我们还将为Teku创建一个自定义数据目录，然后授予teku用户访问权：
须藤mkdir / var / lib / teku && 须藤chown -R teku：teku / var / lib / teku
创建系统服务
此步骤改编自Somer Esat的 优秀的Ubuntu / Teku教程
此步骤将使服务在后台运行Teku。如果由于某种原因停止服务，它还将允许计算机自动重新启动服务。这是确保我们的验证程序运行24-7的必要步骤.
使用nano文本编辑器创建服务文件：
须藤nano /etc/systemd/system/teku.service
在此文件（应该为空）中，我们将放入一系列命令，以在启动服务时使systemd执行。这是下面的代码，您必须将我们在整个旅程中收集的以下项目归为一类：
- Infura Eth1 HTTP端点
- 带两个有效密钥相关文件的validator_key_info目录路径
- 自定义数据路径（lib / var / teku）
将这些值放在下面的粗体代码中，然后将其全部复制到nano文本编辑器中：
[单位]描述= Teku信标节点Wants = network-online.target之后= network-online.target [服务]类型=简单用户= teku组= teku Restart =总是RestartSec = 5 ExecStart = / home / ubuntu / teku-20.11 .1 / bin / teku –network = mainnet –eth1-endpoint = INFURA_ETH1_HTTP_ENDPOINT_GOES_HERE –validator-keys = / home / ubuntu / validator_key_info / KEYSTORE-M_123456_789_ABCD.json：/home/ubuntu/validator_key_info/validator_keys/KEYSTORE-M_123456_789_ABCD.txt –rest-api-enabled = true –rest-api-docs-enabled = true –metrics-enabled –validators-keystore-locking-enabled = false –数据库路径= / var / lib / teku [安装] WantedBy = multi-user.target
输入command-X，然后输入“ Y”以保存您的更改
我们必须重新启动“ systemctl”以对其进行更新：
sudo systemctl守护进程重新加载
启动服务：
sudo systemctl启动teku
检查以确保一切正常：
sudo systemctl状态teku
如果看到任何错误，请通过运行以下命令获取更多详细信息：
sudo journalctl -f -u teku.service
您可以通过运行以下命令停止Teku服务：
须藤systemctl停止teku
检查Teku故障排除页面以查找常见错误或 看看Teku不和谐, 由团队监控.
一旦感觉到一切都已解决，请通过运行以下命令关闭服务，以使其重新启动：
sudo systemctl启用teku
你有它！现在应该正在做饭。检查Teku服务时，您会看到一系列记录同步事件的日志，这是验证器同步信标链的过程。到达记录头后，这些日志将更改为读取“插槽事件”，并且您还将看到证明性能并阻止提议.
发射
在世界标准时间12月1日下午12点，信标链的第一个区块已通过验证。第一个街区来自 验证器19026, 带有神秘的涂鸦，“ F先生在这里。”十二秒后，进入下一个程序段，显示指示验证器可能位于以下位置的涂鸦 瑞士楚格. Eth2信标链稳定增长，每12秒一次。然后是下一个障碍：是否有足够的验证程序在线上来确定第一个纪元？是的！ 82.27％的验证者证明了Epoch 0（信标链众所周知的底层）的有效性。您可以在此处阅读有关信标链发射的更多信息，以及下一步的工作。.
我们现在正在使用纪元760，这意味着信标链已经平稳运行了近一周.
这是我对创世瞬间的看法，并使用了本文中介绍的设置：
在下一部分中，我们将回顾一下进展情况。我将访问Teku的指标，讨论运行AWS的成本，并简要讨论网络状态.
敬请关注!
资源和链接
感谢James Beck，Meredith Baxter，Jason Chroman，Aaron Davis，Chaminda Divitotawela，Ben Edgington，The Dark Jester，Somer Esat，Joseph Lubin，Collin Meyers，Nick Nelson，Mara Schmiedt，Adrian Sutton和Alex Tudorache的支持和技术援助.
以太坊2.0通讯订阅我们的时事通讯以获取最新的以太坊新闻，企业解决方案，开发人员资源等信息。