1. 首页 > 自媒体

V神亲述Serenity设计原理,带你了解这项宏伟工程背后的独具匠心!

V神亲述Serenity设计原理,带你了解这项宏伟工程背后的独具匠心!

Eth1.0 链的设计原理文档见:

https://github/ethereum/wiki/wiki/Design-Rationale

Serenity 设计原则

▲简洁性:特别是由于加密经济 PoS 和二次分片 (quadratic sharding) 在本质上很复杂,因此协议应该在其决策中尽可能地追求最大的简洁性。这是非常重要的,因为这将能够:(i) 最大限度地减少开发成本,

(ii) 减少发生意外安全问题的风险,且

(iii) 使得协议设计人员更容易让用户确信参数选择的合法性。

通过此链接[1]了解相关的背景信息。当我们为了实现特定级别的功能时,是无法避免一定的复杂性的。复杂性的优先级别是:Layer2 协议的复杂性 > 客户端实现的复杂性 > 协议规范的复杂性。

▲长期稳定性:理想情况下,应该构建较低级别的协议,这样就不需要在10年或更长时间内更改协议,并且任何需要的创新都可以在更高的级别 (客户端实现或 Layer2 协议) 上进行。

▲充裕性:在协议之上应能够构建尽可能多的应用程序类别。

▲深度防御性:协议应能够在各种可能的安全性假设 (例如有关网络延迟、故障数量、用户动机的假设) 的情况下继续运行。

▲轻客户端的可验证性:鉴于一些安全性假设 (例如网络延迟,攻击者预算界限,只存在1/n或少数诚实的验证者),验证 O© 数据 (理想情况是只验证信标链) 的客户端应该能够获得间接的保证,即整个系统的所有数据是可用且有效的,即使在受到51%攻击的情况下 (备注:这是“深度防御性”方面的其中一个目标)。

Layer1 与 Layer2 的折衷

读者可以先阅读我之前的两篇文章:Layer 1 Should Be Innovative in the Short Term but Less in the Long Term [2]和 Sidechains vs Plasma vs Sharding [3]。在任何区块链协议设计中,在 Layer1 (即共识层) 引入更多的特性,与构建一个更为简洁的 Layer1 协议并在 Layer2 (即应用层) 上允许构建这些特性,这两者之间各有折衷之处:

支持 Layer2 的论据:

减少共识层的复杂性 (参见上方提到的“简洁性”);

减少修改协议层的必要性 (参见上方提到的“长期稳定性”):

–降低无法达成共识的风险;–减少协议治理和政治风险方面的工作量

随着时间的推移,拥有更多的灵活性和实现新想法的能力

支持 Layer1的论据:

减少由于缺乏强制每个人升级到新协议 (即硬分叉) 的机制而导致进展停滞的风险;

可能会降低整个系统的复杂度;

如果 Layer1 不够强大,那么就不可能在 Layer1 上搭建具有所需性能的 Layer2 系统 (参见上方提到的“充裕性”)

以太坊2.0的设计在很大程度上都是要致力于谨慎地在 Layer1 和 Layer2 之间保持平衡。这包括 (i) 类似图灵完备的、包含丰富状态的代码执行,(ii) 在数据有效性和计算方面的扩展性,以及 (iii) 更快的区块确认时间,这对于协议实现【充裕性】都是非常必要的,因为:

如果不实现 (i),那就无法具有稳健的信任模型来搭建 Layer2 应用程序。

如果不实现 (ii),那扩展性将仅限于借助状态通道或者 Plasma 等技术实现,而这些技术在推广以及资金锁定和/或大规模退出方面存在挑战。

如果不实现 (iii),那就无法在不使用通道技术的情况下进行快速交易,而通道技术在推广以及资金锁定和/或大规模退出方面存在挑战。

但以太坊2.0也将一些其他的特性有意地留给了 Layer2 来实现:(i) 隐私性,(ii) 高级编程语言,(iii) 可扩展的状态存储,以及 (iv) 签名方案。这些特性留给 Layer2 来实现,是因为这些方面都是快速创新的领域,现有的许多方案具有不同的特性,并且不可避免地要进行权衡,以获得更好、更新的方案。比如:

隐私性:环签名 (Ring Signature) + 机密性值 (confidential values) vs. ZK-SNARKs 和 ZK-STARKs,Rollup vs. ZEXE 等等。

高级编程语言:声明式编程 vs. 命令式编程,语法,形式化验证特性,类型系统,保护性特征 (比如禁止在算术表达式中使用非纯函数),本地支持的隐私特征等等;

可扩展的状态存储:账户模型 vs. UTXO (未使用交易输出)模型、不同的租金方案、原始默克尔分支见证 (raw Merkle branch witnesses) vs. SNARK/STARK 压缩 vs. RSA 累加器,稀疏的默克尔树 vs. AVL树 vs. 基于使用情况的不平衡数等等 (除此之外,还有针对验证状态转换的不同方案)。

签名方案:Schnorr 签名、BLS 签名、Lamport 签名等等

为何使用权益证明?

参见:

https://github/ethereum/wiki/wiki/Proof-of-Stake-FAQ

https:[email protected]/a-proof-of-stake-design-philosophy-506585978d51

为何使用 Casper?

当前权益证明 (PoS) 共识算法主要要三个阵营:

受到中本聪启发的权益证明算法 (比如 Peercoin (点点币)、NXT (未来币)、Ouroboros (Cardano 的共识算法) 等实用的算法)

受到 PBFT (实用拜占庭容错) 启发的权益证明算法 (比如 Tendermint、Casper FFG、Hotstuff 等算法)

CBC Casper (讲解详见 [4] 和 [5])

在后两个阵营存在一个问题,即是否使用以及如何使用保证金存款 (质押金) 和 Slashing (质押金罚没)。这三种权益证明机制都优于工作量证明 (PoW),但我们想在本文捍卫一下以太坊2.0使用的方法。

质押金罚没 (Slashing)

以太坊2.0 使用一种 Slashing (质押金罚没) 机制,即被检测到行为不端的验证者将会被惩罚,最轻微的惩罚是销毁~1%的质押金,最严重的惩罚是销毁验证者的所有质押金。我们通过以下几个方面来为 Slashing 机制的使用进行辩护:

增加攻击成本:我们想要确保的是,任何对 PoS 链发起的51%攻击都将导致攻击者消耗一笔非常大的费用 (比如价值数亿美元的加密货币),且系统能够快速地从任何攻击中恢复。这使得攻击/防御演算对于攻击者来说非常不利,并实际上可能使攻击适得其反。

克服验证者带来的困境:节点开始偏离“诚实”行为的最现实直接的方法就是疏忽职守 (比如验证者本该参与验证,但却不参与验证;或者在不该签名时进行签名等等)。验证者带来的困境详见[6],比特币 SPV 挖矿 [7] 就是这种情况发生的例子,这将导致非常严重的后果。对非诚实的验证者进行验证惩罚有助于缓解这些困境。

上方第2点的一个更为微妙的例子就是,在2019年7月 Cosmos 链上的一名验证者因对两个相互矛盾的区块进行签名而被罚没了 [8]。对此事件的调查结果显示,该验证者同时运行了一个主节点 (primary node) 和一个备份节点 (backup node),该验证者的目的是为了确保当其中一个节点下线时,该验证者依旧能够获得奖励,而这两个节点恰好同时启动了,导致这两个节点对两个相互矛盾的区块进行了签名。

如果同时拥有一个主节点和备份节点成为常态,那么攻击者就可以对区块链网络进行分区,并使所有验证者的主节点和备份节点提交不同的区块,从而导致两个相互矛盾的区块被敲定。slashing 惩罚有助于在很大程度上抑制这种操作,降低发生这种情况的风险。

共识算法的选择

在上述文章提及的 PoS 共识算法的三个阵营中,只有后两个阵营 (即受 PBFT 启发的共识算法和 CBC Casper) 这两种算法中存在 finality (确定性) 的概念,即某个区块是通过这种方式得以确认的:只有当很大一部分验证者 (受 PBFT 启发的算法要求至少有1/3的验证者,CBC Casper 算法要求至少有1/4的验证者) 行为不当并因此被罚没时,该区块才会被逆转;而第一个阵营–受中本聪启发的 (最长链规则) 共识算法无法实现这种意义上的确定性 (finality)。

需要注意的是,确定性要求大多数验证者在线,而这已经是 Sharding (分片) 机制中已经存在的要求,即 Sharding 机制要求每个由随机验证者组成的委员会中的2/3验证者对交联 (crosslink) 进行签名,只有这样,该交联才将被信标链接受。

我们选择 Casper FFG 只是因为它是协议在实现确定性时可用的最简单的算法。当前我们正在积极探索在以太坊2.0的阶段3将之切换为 CBC Casper。

Sharding,或者说我们为何讨厌超级节点?

对于 Layer1 扩展而言,sharding (分片) 方式的一个主要替代方法就是使用超级节点 (supernodes),超级节点要求每个共识节点都拥有一个强大的服务器,这样该节点就能单独地处理每一笔交易。基于超级节点的扩展方式很方便,因为很容易实现:这与当前很多区块链采取的方式一样,除了需要进行更多的软件设计工作来以一种更加并行化的方式进行构建。

我们不选择这种使用超级节点的方式,主要理由如下:

验证池中心化风险:在一个基于超级节点的系统中,运行一个节点将需要消耗一笔高昂的固定成本,这使得能够参与进来的用户数量受到限制。虽然有些人会反驳道“在大多数 PoW 和 PoS 加密货币中,共识是由 5-20 个池子 (矿池或验证池) 控制的,而这些池子可以很好地运行节点。”但这种观点的问题在于忽视了其中存在的中心化压力风险,即便是财力雄厚的池子之间也存在这种风险。如果运行验证者的固定成本相对于回报来说是非常高的,那更大的验证池就能够提供比小型验证池更低廉的手续费,这将可能导致那些小型的验证池被排挤并感受到进行合并的压力。而在分片系统中,质押更多 ETH 的验证者将需要验证更多的交易,因此成本并不是固定的。

云端中心化风险:在一个基于超级节点的系统中,用户在家里进行 staking 就变得不可行了,因此大多数 staking 更有可能发生在云计算环境中。这将创建一个单点故障。

抗审查性降低:如果没有达到高计算+带宽要求,用户就不可能参与共识,这使得检测和审查验证者变得更加容易。

扩展性:在一个基于超级节点的系统中,随着交易吞吐量的增加,上述文章提及的风险也会相应地增加,而分片系统能够更加轻松地处理交易量的增长。

上述这些中心化风险也是我们为何不会试图实现以太坊的超低延迟性 (低于1秒) 的原因,而是选择 (相对) 保守的延迟时间。在以太坊2.0系统中,使用尽可能少或尽可能多的 ETH 以及使用尽可能少或尽可能多的计算能力来参与是可能的 (尽管你需要在 ETH 和计算能力方面相一致,即你无法在仅拥有很少计算能力的情况下质押大量的 ETH,反之亦然),且固定成本是最小化的,尽管这种成本会随着你质押的 ETH 的数量的增长而增加 (一旦你质押的 ETH 数量超过了 32,768 ETH,那么大部分时间你将在验证所有的分片链 (备注:共计1024条分片链,每个验证者身份需要质押 32 ETH,因此 1024*32=32,768))。

安全模型

人们通常认为区块链的安全性依赖于“大多数参与者是诚实的”这一假设,即≥50%的参与者将会诚实地遵循既定的协议,会为了个人的利益放弃叛变的机会。事实上,(i) “大多数参与者是诚实的”这种假设并不切实际,因为参与者可能会“懒惰 (lazy)”,在不验证区块的情况下签署区块 (参见验证者带来的困境 [9] 和比特币SPV挖矿导致的分叉 [10]),这都是非常普遍的叛变情况;但幸运的是,(ii) 区块链通常会通过一些安全模型 (而非假定大多数参与者将保持诚实) 来维护自身的安全特性。

一种常见的较为严苛的安全模型就是非协同的理性多数模式 (uncoordinated rational majority),即参与者会按照自己的利益行事,但相互协同的参与者数量不会超过一定的比重 (在简单的 PoW 链中,这一比重为23.2% [11])。

另一个更为严苛的安全模式是应对最糟情况的模式,即当单个参与者控制了超过50%的算力或质押金时,此时的问题就变成了:

(1)在这种情况下,我们能保证验证者在试图破坏整条链时将付出非常高昂的成本吗?

(2)我们可以无条件地保持哪些保证?

在 PoS 链中,slashing (对质押金的罚没) 可以提供上方第一个问题的保证,即当攻击者试图破坏整条链时,将需要成大非常高昂的成本。在不存在分片的区块链 (比如当前的以太坊1.0链) 中,每个验证所有区块的节点都会通过提供以下两个保证来完成上方第二个问题的要求:(i) 最长的链是有效的,且 (ii) 最长的链也是可用的 (通过此链接 [12] 查看“数据可用性”的重要性的理论依据)。

在以太坊2.0中,我们通过 sharding (分片) 的方式来实现深度防御,即通过将随机选择的验证者委员会组合起来,基于大多数验证者将保持诚实的安全模式,以实现有效性和可用性保证,且通过托管证明 (proof of custody) 来防止懒惰的验证者(即如果验证者“懒惰”不参与验证将会面临惩罚),通过欺诈证明 (fraud proofs)和数据可用性证明 (data availability proofs) [9] 在无需下载和验证所有数据的情况下检测无效和不可用的链。这将允许客户端拒绝无效和不可用的链,即便当这条链是由大多数 PoS 验证者支持的链。

客户端可以通过某种保留共识的方式来检测交易的审查性 (详见 [13]),但这方面的研究还没有整合到以太坊路线图之中。

下表中展示了预计的安全特征:

Casper 设置的激励机制

基本奖励 (Basic rewards)在每个 epoch 期间 (在以太坊2.0中,每生成64个区块 (大约6.4分钟) 称为一个 epoch),每个验证者都要进行“证明(attestation)”,也即对链头 (head) 进行投票签名 (链头也就是顶端区块)。如果验证者的“证明”被包含在了链头中,那该验证者将获得奖励,这个奖励由五个部分组成:

本文采摘于网络,不代表本站立场,转载联系作者并注明出处:http://www.fjxmta.com/zmt/64066.html

联系我们

在线咨询:点击这里给我发消息

微信号:wx123456