以太坊 2.0：信标链

106 阅读 0 评论 70 点赞

我是靠谱客的博主隐形鸡，最近开发中收集的这篇文章主要介绍以太坊 2.0：信标链，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

本文是 “以太坊 2.0” 系列的一部分。在本文中，我们将解释信标链。

阅读本文需要一些背景知识，不过不多，都在这篇 Explaining Validators 里面了。话说回来，你大概已经知道了，以太坊的终极目标是通过权益证明来达成共识。如果你不太熟悉 PoS（权益证明），强烈推荐你阅读这篇科普文，了解工作量证明与权益证明之间的区别。

那么老铁，保温杯泡起来，二郎腿翘起来，看我来给你们解释信标链。

-保温杯准备好了吗？-

信标链简介

The beacon chain is a new blockchain（我们要谈到的信标链是一条全新的区块链），并且在新的以太坊中占据核心位置。

这条链承担的其中一个职能是让验证者可以参与质押系统、替代矿工的角色而成为链的构建者。另一个职能是存储分片状态的索引。

职能 1：质押系统网关

首先，我们会在当前的以太坊区块链上部署一个 注册器合约（registration contract），这样做的目的是在现有的链与信标链在可预见的未来里共生（大概是两年左右）。

你要先在注册器合约中质押 32ETH，就可以获得一张收据（也就是区块链客户端可以读取的一个事件（event）），这张收据即是你的“会员卡”，表明 committer（即质押者）具有担任验证者的资格。注意，因为这个过程是单向的，所以无法从这个系统中撤离回到现有的 PoW 链上。一旦你提交了 32ETH 到质押系统里，押金只能退回到某个具体的分片上（在分片部署之后），但不能回到 EVM 上（译者注：意即回到 PoW 链上，因为到时候分片上的虚拟机是 EWASM）。如果你敏锐地察觉到好像产生了两种平行的 ETH，那么——其实你是对的 : )。详情请看 Two Point Oh: The Tale of Two Ethers。

在完全转变为 PoS 系统之后，PoW 链会退化为一个分片或者一个 master archive contract（主存储合约）（更多详细内容请看 Two Point Oh: The Legacy Shard），而上述质押过程将完全发生在信标链及其连结的分片上，整个过程会更加自然且流畅。

在信标链上注册之后，验证者会被随机分配去为一到两个分片做验证（有关这一部分，请看我写的有关验证者的文章）。验证者会将他们所在分片上的数据和信标链上的数据相结合，用来形成新的区块；在还没轮到他们提议区块的时候，同意/拒绝其他验证者提议的区块。

-生产区块-

重申一遍，信标链上没有我们通常用到的数据——它不存储现行以太坊区块链上存储的任何信息，包括账户的余额、跟代币相关的合约、dApp 的状态等等。它只存储两样东西：验证者列表和 Attestation（证明信息）。

职能 2：存储 Attestation

Attestation 即是经过确认并且由验证者签过名的哈希值，它们实时记录着一个特定分片的状态。听起来很烧脑对不对？让我来详细解释一下。

任意数据经过哈希之后会转换成一串字母和数字组成的字符串；一旦原始数据改变了一丢丢，输出的字符串就会完全不同。举个例子，打开这个生成器，输一个 Hell 进去，你可以看到输入框下面会出现一串输出值；你只要加一个 o 变成 Hello ，输出值就会完全不一样。

如果将一副高清图片进行哈希，哪怕只改变一个像素点，产生的哈希值也会完全不同。这意味着，即便改变再怎么细微，产生的哈希值也会截然不同，因此非常容易被察觉。

因此，我们不需要深入一个分片，我们完全可以认为哈希值代表了执行操作的数据（比如代币转账或者转移非同质代币的所有权）。分片好比是区块链的硬盘。每隔一段时间，只要某个分片上的数据发生了变化（哪怕 100 万个账户中有一个账户的余额变了），就会有一个新的哈希值从这个新的状态中产生出来，然后被认证到信标链上作为检查点（Checkpoint）。换句话来说，无论什么时候，只要某个分片上的数据改变了，验证者就会立即把这种变更报告给信标链。因此，分片间可以通过信标链来跟踪彼此的变化、实现分片间异步（即非实时）通信。至于这一点的重要性，我会在文章 Two Point Oh: Sharding 中解释。

“信标链”由此得名。信标链就像是灯塔，可以帮助我们在大雾弥漫的海域中互相定位——所有的分片通信都会通过信标链来完成，节点也会借此相互沟通，并合作打造一个区块链系统。

信标链节点与验证者客户端

现在你可能会疑惑，验证者节点和挖矿节点怎么适应新的系统，它们会不会改名换姓。答案是：当然会变化了。?

你现在需要了解两大类“节点”（每个大类下面还分不同的子类，本文不会涉及）。

信标链节点 负责验证 验证者 的身份、批量处理签名（aggregating signature，因为会有很多验证者发送自己的签名，逐个处理太费时间了，所以我们希望能够一次处理许多个签名）、抓取出块所必需的数据并传递给验证者验证。信标链节点就相当于现行以太坊系统上的矿工，它们需要投入更多资源，要运行在更高级的硬件上。

验证者客户端（在理论上）可以是非常轻量级的，我们在 Nimbus 的开发中就是这样做的。客户端就是一些程序，唯一的功能就是保持网络连接并在系统中质押 ETH（当然还是需要稳定的网络连接，因为验证者需要签署他们的 attestation 并在需要的时候将它发回网络）。验证者客户端会使用信标链节点提供的数据构造区块并将这些区块发回网络。若是验证者客户端作恶或是离线，他们自己也要承担后果——也就是所谓的罚没（即削减权益）。你也许期盼智能手机之类的设备也可以用于验证，但估计不太可能实现——考虑到（保持网络通信不间断）所需的网络带宽以及频繁的硬盘读写操作，手机的电量很快就会耗光。

当然也会有其它类型的节点——轻客户端、极轻客户端、无状态节点、完全归档节点（可以帮助检索那些租金已经到期的数据）（详情请见 Two Point Oh: Paying Data Rent）、部分归档节点，以及其它。最后我们会一一详解。

Nimbus

现在 Nimbus 团队正致力于完成信标链技术规范的多个部分。

关于信标链的搭建，我们做的主要工作放在一个独立的代码库中，名为 nim-beacon-chain。这些工作与 Nimbus 本身是独立的，因为我们的工作目标是将其作为一个组件，在需要时加入到 Nimbus 的开发周期中。换句话来说，当我们使用 Nimbus 作为极轻节点时，是不需要使用信标模式的（信标模式也不能在旧款的智能手机上运行）。也就是说，这个独立的代码库会在 12 月的某些时候合并到 Nimbus 中，以保证 Nimbus 可以满足所有的需要。

虽然我们力求能在 2019 年 3 月发布具有标志性意义的概念验证——连接其它客户端、验证、混洗验证者、构造区块——从目前来看，最大的难关在于技术规范中尚未定义的领域。所有正在搭建客户端的团队都迫切希望客户端之间能够达成良好的合作和顺畅的沟通；但如果没有指明沟通方式，大家就很难达成一致，在这一点上我们需要投入更多精力。同样，RANDAO 随机数生成器的提交/公布方案（详情请见：Two Point Oh: Randomness）在技术规范中仍未确定，所以我们尚未确定是否将它给客户端来实现。最后，同样重要的是，分叉选择规则——即客户端在选择跟随哪条分叉链时依据的规则——同样仍在讨论中，尚未得到定义。

上述即是我们正在开发的东西。

结论

在验证者和信标链这两篇文章中，我们讲了许多与以太坊 2.0 核心相关的内容；充分吸收和理解这些内容是很重要的。

接下来，本系列的新文章将会变得更简短具体，但这个新系统在大方向上不太可能改变，你可以在此基础上向其他人讲解什么是以太坊 2.0 。为了完全理解以太坊 2.0，请读多几遍，如果有什么地方不能理解，不要客气，来我的推特留言。

本文总结：信标链是一条新的链，是以太坊 2.0 的核心，所有分片都连接到信标链上并与之通信。信标链一方面是验证者参与质押系统并根据所押权益获得收益的渠道（请看 Two Point Oh: Economy），另一方面是实现分片通信的渠道，因为各分片都将自己的最新状态的哈希存到信标链的区块上。信标节点是信标链的建设者，他们处理大量的数据，并将数据发送给验证者用于验证；验证者会构造区块并发回给信标节点。验证者质押 ETH 来获得出块机会，如果他们提议的区块获得了其它验证者的同意，就能获得奖励。