作者 | Dankrad Feist(Ethereum Foundation)、谢翔(PlatON)

来源 | Unitimes

以太坊是当前世界上使用最为广泛的区块链系统之一。经过约五年的发展,目前已进入第四个阶段——『宁静』(Serenity),也就是广为所知的以太坊2.0,通常简称为ETH 2.0。

以太坊2.0 将会成为迄今为止最具雄心的一次升级,其设计目的涉及到改善去中心化系统的各个方面。一旦升级成功,目前以太坊网络的两大难题将会被解决,它们分别是可扩展性和可持续性。

以太坊 2.0

1、可扩展性

当前以太坊网络的能力大约为20 TPS,这远无法满足成百上千个应用程序的使用需求。以太坊社区提出了许多解决扩展性的方案,Eth 2.0最终决定采用分片的方式来实现Layer 1 层的扩展。

简而言之,通过分片的方式可将系统分为可管理的较小部分(分片链),并且每一分片各自独立并行处理。最后,每个分片的结果将通过交联(crosslink)到信标链连接在一起。

举一个简单的例子,假设一个区块包含三笔交易。在当前的以太坊网络中,每个节点(例如节点A、B、C)必须验证所有交易。若算力最差的节点需3 秒来验证该块,则系统的吞吐量为1TPS。显然,系统的可扩展性取决于单个节点的处理能力。

在分片中,交易可被分配给不同的分片链,每一个节点仅需验证其中一个分片即可。交易也被分成三部分,每一部分在单独的分片中分别进行验证。假设每笔交易可以在1 秒内完成验证,那么整个系统的吞吐量将变为3TPS!此外,每个节点不需要存储链中的所有数据,它们仅需负责在某些时期对于一些特定分片数据的存储。

当然,在实际情况中,每一分片可被多个验证人节点验证。若对此感兴趣,可进一步参考Sharding FAQ(https://github.com/ethereum/wiki/wiki/Sharding-FAQ)。ETH 2.0 目标是打造1024 个分片(现阶段开启64 个),其吞吐量相比当前网络预期将提高1000 倍。加上layer 2 层的扩展机制,其性能将会进一步提高。

2、Proof of Stake

当前的以太坊和比特币一样,依赖于工作量证明(PoW)来保证系统的共识。在PoW系统中,“矿工”通过消耗电力资源来解决密码学难题,并且会因为解决难题而获得奖励。安全性源于计算问题的难度,由于“挖矿”所存在的巨额收益,因此造成一些矿池的中心化和垄断,使得系统的安全性大大折扣。

不仅仅是中心化,挖矿/工作量证明还存在许多其它的问题。譬如,由于计算所消耗的电力资源引起的极大浪费,而消耗能源本身是用来保证系统安全性的,所以这在PoW 范式中很难解决。另外,系统只有奖励机制,却不会因为恶意行为而受到惩罚。因此实际上,安全性的开销要比所需的远高的多。

为了解决这些问题,以太坊2.0 将会切换到Proof of Stake(PoS),该协议称为Casper。在PoS 系统中,“挖矿”过程替换为一个投票系统,验证人节点需要质押32 个以太币才能参与系统并进行投票。为了达成共识,验证人节点轮流对下一个区块进行提议和投票。如Ethereum Proof of Stake FAQ[1]所述:

此区块链系统维护一组验证人节点列表,任何持有其基础密码货币(以太坊中为以太币)的用户,都可通过发送特定类型的交易进行“锁仓”来成为验证人节点。生成并就新区块达成一致的的过程通过共识算法来完成,共识过程所有节点都可参与。

信标链将成为以太坊2.0 的核心,它存储并维护所有验证人节点的注册,处理跨分片通讯以及最终一致性的确认。所有的分片始终遵循信标链,持有32 个ETH(固定值)的用户可成为验证人节点。在一个周期中的每一时段,系统从信标链中随机选择委员会指派给不同的分片。验证人节点最终被划分为多个不同的委员会,每个委员会至少由128 位验证人节点组成。该委员会负责在特定的分片上生成区块。

另一方面,验证人节点也会因出现不良行为或不诚实行为而受到惩罚,最严重的的一种惩罚(Slashing),将会销毁节点所有质押的以太币。其他一些情节轻微的惩罚行为包括:不在规定时间正常运行,证明尚未最终确定的区块等。对于双签或者对错误的计算进行签名都会施以最严厉的处罚。

数据可用性问题

数据可用性问题与欺诈证明高度相关,简要说明如下。更多详细信息请参见这篇[2]

1、欺诈证明

在上面对区块链中的节点(不考虑分片)的描述中,我们实际上指的是全节点。全节点产生链的区块,下载每个节点中的所有数据,并验证所有交易和状态的有效性。一个全节点要求机器配置大量的内存,强大的计算能力以及非常高的带宽。而像手机这样的受限设备很难满足这样的配置要求。

轻节点或者轻客户端是全节点的一种低成本替代方案。它们至少连接到一个全节点上,并且仅下载区块头和想要的区块数据。他们信任全节点来检查数据的有效性,并假定恶意全节点无法创建一条有效的分叉链。

欺诈证明是针对轻节点的一种机制,它用于降低被非法链欺骗的安全风险。每当诚实的全节点发现某种不一致的状态时,全节点就会生成一个欺诈证明,并为轻节点发出“警报”。此欺诈证明很小,并且可快速在网络进行分发,而且可以肯定地证明某些链的确存在故障。这样,轻节点就可以完全忽略此非法的链,并避免其可能导致的系统状态不一致。

例如,若全节点发现一笔交易t是错误的,此交易的前后状态分别为S_inS_out。那么全节点构造出此笔交易对应的欺诈证明为(S_in, t, S_out)以及相应的Merkle根(Merkle root)。证明本身非常小,很容易广播以及验证。轻节点可通过验证Merkle根和交易三元组确定交易的非法性。

数据可用性证明指的是,若某些恶意的全节点对区块头进行了签名,但却不发布区块中的某些数据,该怎么办?特别是如果数据里包含了一笔无效交易(例如,一笔窃取转账金额,并转移至另一账户的交易)该如何?在这种情况下,诚实的全节点无法生成欺诈证明,这是由于缺乏生成欺诈证明所必需要的数据。

2、分片中的数据可用性

数据可用性问题在分片中也尤其重要。如前所述,ETH 2.0 中的验证人节点不会验证所有区块,也不会去下载所有数据。这是为了让分片机制充分发挥效用,并减轻单个验证人节点的负担。分片区块将由委员会验证,并且只有承诺值会存储在信标链中。从这个角度来看,验证人除了需要一直持续性的参与网络获得之外,它们实际上可看做是大多数分片上的轻节点。

分片中的数据可用性问题描述如下图所示:

整体过程可用以下步骤说明:

  1. 分片数据以Merkle 结构存储得到Merkle 根。事实上这是交联(crosslink)数据根,为简便起见,将其称为Merkle 根;

  2. 提议人节点生产新区块并对Merkle 根进行签名;

  3. 其他验证人节点对此区块进行投票并签名。其中,BLS 签名可聚合成一个签名;

  4. 当签名的数量超出门限时,签名的Merkle 根就会被添加到信标链上。

在其它分片上发挥作用的分片无法获知完整的区块链数据,并且也不会去下载,否则,这会直接消除分片所带来的优势。这种情况下的数据可用性问题指的是,如何能够验证分片1 中的数据确实可被任何想要下载或验证此数据的全节点所获取。

托管策略(Custody Game)

Eth 2.0 假定2/3的验证人节点是诚实的,并且以这样一种方式将验证人节点分配给对应的分片:若满足2/3的验证节点诚实,则永远不会将不可用或者不正确的区块包含在一个交联中。但是,这里的“诚实”意味着什么呢?可能有一些验证人节点“诚实但懒惰”:鉴于在大多数情况下,没有人试图作弊,因此节点可能永远都需要真正验证任何内容,而只是对任何传入的区块头进行签名。或者,为了更加安全一些,可先等待该区块头积攒了一些签名之后,然后再继续签名。这种方式仍然可以获得奖励,但却几乎不需要做任何工作。

如果发生这种情况,攻击者可以依靠这些验证人节点促进无效区块的传播。这对于系统的整体运行状况将会带来灾难性的影响。因此,我们希望尽可能避免使用“诚实但懒惰”的验证人节点,这也正是采用Custody Game的目的。

Custody Game本身不能完全解决数据可用性问题。因此,需要额外进行数据可用性检查。但是,它可以确保至少在分片1 中对此区块进行签名的验证人节点都拥有数据。

粗略来说,在Custody Game中,每一个验证人节点必须计算出另外的一个托管比特(custody bit)。此托管比特仅可由持有“秘密”密钥(托管密钥,custody key)和数据的验证人节点计算出来。在公布托管密钥后,任何人都可使用数据来验证这一托管比特。若发现一个无效的托管比特,可在链上对此进行挑战。如果挑战者是正确的,那么他们将得到奖励,并且托管比特生成方将会被处罚。

托管证明(proof of custody)存在以下几个关键点:

  1. 托管密钥是从验证人节点密钥中确定性地计算出来,以避免采用新的密钥增加系统复杂性。托管密钥会周期性地生成,并且在托管周期结束时公布出来。任何人都可验证托管密钥的有效性。它也被称为临时密钥(ephermeral key),因为它仅在一个托管周期阶段有效(Eth 2.0 中,托管周期大约为9 天)。

  2. 若没有托管密钥和数据,那么生成托管比特的方式与随机猜测并无太大区别。

  3. 任何人都可以使用托管密钥和数据来检验托管比特的有效性。

在Eth 2.0 中,验证人节点的公钥将是BLS签名系统的公钥。一旦质押以太币成为验证人节点,对应的运营者将生成一个公私钥对。对于每一个托管周期(9 天),验证人节点都能够生成临时托管密钥ek。临时密钥实际上是对计数器(当前周期的计数)的BLS 签名。由于BLS 的签名过程是确定性的,因此所有的临时密钥都可预先由公钥完全决定。除了验证人节点本身之外,任何人都无法计算出临时密钥。

托管比特是通过某一类mix函数计算而来,尽管函数的具体形式仍在讨论中,但其规范倾向于使用MPC 友好的构造,详见eth2.0-specs[3]。总的来说,托管比特的生成方式为b=mix(ek,D),其中D为区块数据。

目前,mix函数的构造使用了通用哈希函数(Universal Hash Function,UHF)和勒让德伪随机函数(Legendre PRF)。这些函数均为带密钥的函数并且是确定性的。因此,给定一个密钥ek,将其表示成两个元素ek0, ek1。然后,验证人节点可计算出托管比特b=Leg_PRF(ek0, UHF(ek0,ek1,D)),如下图中的流程所示:

简而言之,UHF 用于扩展输入数据空间(密码学中的常用的技术),同时避免外包计算(只有密钥和数据所有者才能计算UHF 函数)。采用Legendre PRF 的缘由主要有两点:其一,它在MPC的计算中非常高效;其二,其可确保托管比特具备更好的随机性。可参考这篇文章[4]获取更多细节,并且,我们将会在后续的文章中给出更加深入的解释。

MPC友好性

Eth 2.0 的设计目标之一是使其对MPC友好。其中包含了两个原因:其一,通过允许运营节点在多个计算机甚至不同的数据中心之间分布其验证人节点,从而避免单点故障,这可以带来额外的安全性;其二,通过一个无需信任(trustless)的验证人节点池,能够使资金较少的人可以参与Eth 2.0验证。因此,托管证明也应该对MPC 友好,这也是使用Legendre PRF 的主要原因。由此,这或许会开启一种全新的业务模式,并产生许多其它有趣的应用。请参见此处[5]获取更多细节。

PlatON 发起了一个由以太坊基金会资助的项目,以实现和优化MPC 中的托管证明,当前代码已在GitHub[6]上开源。后续会公布更多细节,请持续保持关注!

文中链接:

[1] https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ

[2]https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html

[3]https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase1/custody-game.md#misc

[4]https://ethresear.ch/t/using-the-legendre-symbol-as-a-prf-for-the-proof-of-custody/5169

[5]https://slideslive.com/38920085/ethereum-20-trustless-staking-pools

[6]https://github.com/PlatONnetwork/proof_of_custody

同时,欢迎所有开发者扫描下方二维码填写《开发者与AI大调研》,只需2分钟,便可收获价值299元的「AI开发者万人大会」在线直播门票!

推荐阅读:

  • 详解以太坊虚拟机(EVM)的数据存储机制

  • 比特币当赎金,WannaRen 勒索病毒二度来袭!

  • 平台抗住日访问量 7 亿次,研发品控流程全公开

  • “手把手撕LeetCode题目,扒各种算法套路的裤子”

  • 北京四环堵车引发的智能交通大构想

  • 从Ngin到Pandownload,程序员如何避免面向监狱编程?

  • 从 Web 1.0到Web 3.0:详析这些年互联网的发展及未来方向

老铁们求在看!????

以太坊2.0中的Custody Game及MPC实现相关推荐

  1. 【转】以太坊 2.0 中的验证者经济模型

    自从 11 月在 DevCon4 上正式宣布 Serenity 以来,我们见证了自我组织的思想者团体聚集在一起讨论,定义与规划以太坊 2.0.尤其对网络膨胀.经济激励措施.罚没机制.取款周期.攻击媒介 ...

  2. 以太坊 2.0 中的验证者经济模型,Part-1

    自从 11 月在 DevCon4 上正式宣布 Serenity 以来,我们见证了自我组织的思想者团体聚集在一起讨论,定义与规划以太坊 2.0.尤其对网络膨胀.经济激励措施.罚没机制.取款周期.攻击媒介 ...

  3. 简介 以太坊 2.0 核心 之 共识机制的改变

    作者:林冠宏 / 指尖下的幽灵 博客:http://www.cnblogs.com/linguanh/ GitHub : https://github.com/af913337456/ 掘金:http ...

  4. 分析波卡与以太坊2.0有什么不一样的地方?

    转载原文链接:http://www.btcwbo.com/5372.html 自2016年波卡白皮书正式发布以来,经过几年的低调测试和开发,波卡的核心功能开发和生态开发取得了显著进展,平行链插槽Auc ...

  5. 以太坊后合并时代 15个概念带你深入了解以太坊2.0

    北京时间9月15日14时42分左右,以太坊正式完成合并.以太坊在区块高度15537393触发合并机制,并产出首个PoS区块,高度为15537394,以太坊共识正式从PoW转为PoS机制. 以太坊进入后 ...

  6. 探究以太坊 2.0 的分叉选择规则

    时至今日,许多关于以太坊 2.0 的工作细节已经公诸于众,同时还有许多团队在着手实现.但是 以太坊 2.0 还有一大块空白的部分还未规范,也没有披露什么讯息,那就是分片链技术.基本上所有关于规范的部分 ...

  7. 信标链:以太坊2.0的新起点

    原创:市后诸葛 虽然以太坊2.0依旧用"以太坊"命名,但以太坊1.0和以太坊2.0其实是完全不同的两种架构.以太坊1.0和2.0的差别,远不是POW和POS的区别.在以太坊2.0里 ...

  8. 以太坊 2.0:如何实现最终性

    首先,我们试着来理解什么是finality (最终性).[备注:也有译文将 finality 译为「确定性」] 你一定已经注意到,加密货币平台和 Dapps (去中心化应用) 通常都会等待几个区块被敲 ...

  9. V神说,解释以太坊2.0最好的文章就是这篇了

    翻译 | 王国玺 编辑 | 波波 今天,V 神在 Twitter 上表示,君士坦丁堡升级的再度延迟完全不会影响以太坊 2.0 的 Casper/分片/宁静 的研发团队和研发进度: V 神是在转推以太坊 ...

最新文章

  1. vue从入门到进阶:Vuex状态管理(十)
  2. 个人信息安全亟需划定法律红线
  3. [JS] - onmusewheel事件(兼容IE,FF,opera,safari,chrome)
  4. EntityFramework和EntityFramework.Extended使用说明——性能,语法和产生的sql
  5. Java正则表达式中的反向引用
  6. 因离职,3人拟终止人才项目!
  7. Echarts自定义折线图例,增加选中功能
  8. 中文文本相似度计算工具集
  9. php高德地图坐标在多边形,多边形的绘制和编辑
  10. python数据对比找不同_利用Python读取文件的四种不同方法比对
  11. 营销、销售和运营的区别?
  12. mysql CASE WHEN的基础和多种用法
  13. C语言 符号配对 (20分)
  14. Java自己编名字的百家姓罗列
  15. Android Paint,Canvas api 详解
  16. 深度卷积神经网络(AlexNet)
  17. idea实现打包springboot项目并且运行在cmd中
  18. html下拉框背景怎么设透明度,css怎么设置背景图片半透明 css设置图片作为背景的透明度...
  19. 德国外交部为何放弃Linux而改用XP?
  20. 2023年天津仁爱学院专升本化学工程与工艺对口专业限制目录

热门文章

  1. 最明白的Unity3D手机平台分辨率自动匹配教程-适合新手
  2. 遗传算法matlab_科学与艺术的融合:遗传算法绘制蒙娜丽莎
  3. SRC任意账号密码重置的6种方法
  4. 六部门联合发文:近视目前不可治愈!
  5. nginx安装配置总结
  6. 保留小数时有效位数设置—Python
  7. 第一章 Linux操作系统概述
  8. 陈诺:国外LEAD赚钱教程-EMU篇(二)Affiliate怎么赚钱
  9. 毫无争议的github顶级有用的开源项目排行榜
  10. R语言多因素有交互方差分析(Two-Way ANOVA):检测和理解两个因素之间的交互作用的最简单的方法是使用交互作用图、双因素交互作用图可视化(interaction plot)