本文作者：DankradFeist、谢翔
来源：Unitimes
编者注：本文作了不改变作者原意的删减。
以太坊2.0
以太坊是当前世界上使用最为广泛的区块链系统之一。经过约五年的发展，目前已进入第四个阶段——『宁静』，也就是广为所知的以太坊2.0，通常简称为ETH2.0。
以太坊2.0将会成为迄今为止最具雄心的一次升级，其设计目的涉及到改善去中心化系统的各个方面。一旦升级成功，目前以太坊网络的两大难题将会被解决，它们分别是可扩展性和可持续性。
01?可扩展性
当前以太坊网络的能力大约为20TPS，这远无法满足成百上千个应用程序的使用需求。以太坊社区提出了许多解决扩展性的方案，Eth2.0最终决定采用分片的方式来实现Layer1层的扩展。
简而言之，通过分片的方式可将系统分为可管理的较小部分，并且每一分片各自独立并行处理。最后，每个分片的结果将通过交联到信标链连接在一起。
举一个简单的例子，假设一个区块包含三笔交易。在当前的以太坊网络中，每个节点必须验证所有交易。若算力最差的节点需3秒来验证该块，则系统的吞吐量为1TPS。显然，系统的可扩展性取决于单个节点的处理能力。
在分片中，交易可被分配给不同的分片链，每一个节点仅需验证其中一个分片即可。交易也被分成三部分，每一部分在单独的分片中分别进行验证。假设每笔交易可以在1秒内完成验证，那么整个系统的吞吐量将变为3TPS！此外，每个节点不需要存储链中的所有数据，它们仅需负责在某些时期对于一些特定分片数据的存储。
当然，在实际情况中，每一分片可被多个验证人节点验证。若对此感兴趣，可进一步参考ShardingFAQ。ETH2.0目标是打造1024个分片，其吞吐量相比当前网络预期将提高1000倍，加上layer2层的扩展机制，其性能将会进一步提高。
TRON数字钱包科普资料《波场钱包的现在过去与未来》已上线:据最新消息显示，由TokenPocket联合波场TRON官方，以及 TokenPocket 社区志愿者共同撰写的《波场钱包的现在过去与未来》已正式上线。《波场钱包的现在过去与未来》又称为波场钱包小白书，详细介绍了当前TRON钱包与TRON生态密切结合的实例，是目前市面上最为详细的TRON数字钱包科普资料。波场钱包作为波场公链生态中极为重要的入口，是波场生态的重要构成要素。波场钱包从一开始只提供权限管理、转账收款、节点投票等基础功能，到如今不仅可以为用户提供法币交易、闪兑和去中心化交易所等方便快捷的交易服务，还能让用户直接在钱包上体验波场上DApp，挖矿、DeFi、Staking等资产增值服务。详情见原文链接。[2020/8/20]
02?ProofofStake
当前的以太坊和比特币一样，依赖于工作量证明来保证系统的共识。在PoW系统中，“矿工”通过消耗电力资源来解决密码学难题，并且会因为解决难题而获得奖励。安全性源于计算问题的难度，由于“挖矿”所存在的巨额收益，因此造成一些矿池的中心化和垄断，使得系统的安全性大大折扣。不仅仅是中心化，挖矿/工作量证明还存在许多其它的问题。譬如，由于计算所消耗的电力资源引起的极大浪费，而消耗能源本身是用来保证系统安全性的，所以这在PoW范式中很难解决。另外，系统只有奖励机制，却不会因为恶意行为而受到惩罚。因此实际上，安全性的开销要比所需的远高的多。
为了解决这些问题，以太坊2.0将会切换到ProofofStake，该协议称为Casper。在PoS系统中，“挖矿”过程替换为一个投票系统，验证人节点需要质押32个以太币才能参与系统并进行投票。为了达成共识，验证人节点轮流对下一个区块进行提议和投票。如EthereumProofofStakeFAQ所述：
?此区块链系统维护一组验证人节点列表，任何持有其基础密码货币的用户，都可通过发送特定类型的交易进行“锁仓”来成为验证人节点。生成并就新区块达成一致的的过程通过共识算法来完成，共识过程所有节点都可参与。
人大附中物理老师李永乐科普拜占庭将军问题和区块链:5月14日，人大附中物理老师、科普视频网红李永乐在其公众号发布视频《拜占庭将军问题是什么？区块链如何防范恶意节点？》。李永乐老师在视频中对拜占庭将军问题和区块链进行了讲解，他表示，拜占庭将军问题本质上指的是，在分布式计算机网络中，如果存在故障和恶意节点，是否能够保持正常节点的网络一致性问题。在近40年的时间里，人们提出了许多方案解决这一问题，称为拜占庭容错法。例如兰波特自己提出了口头协议、书面协议法，后来有人提出了实用拜占庭容错PBFT算法，在2008年，中本聪发明比特币后，人们又设想了通过区块链的方法解决这一问题。区块链通过算力证明来保持账本的一致性，也就是必须计算数学题，才能得到记账的权力，其他人对这个记账结果进行验证，如果是对的，就认可你的结果。与拜占庭问题比起来，就增加了叛徒的成本。[2020/5/14]
信标链将成为以太坊2.0的核心，它存储并维护所有验证人节点的注册，处理跨分片通讯以及最终一致性的确认。所有的分片始终遵循信标链，持有32个ETH的用户可成为验证人节点。在一个周期中的每一时段，系统从信标链中随机选择委员会指派给不同的分片。验证人节点最终被划分为多个不同的委员会，每个委员会至少由128位验证人节点组成。该委员会负责在特定的分片上生成区块。
另一方面，验证人节点也会因出现不良行为或不诚实行为而受到惩罚，最严重的的一种惩罚，将会销毁节点所有质押的以太币。其他一些情节轻微的惩罚行为包括：不在规定时间正常运行，证明尚未最终确定的区块等。对于双签或者对错误的计算进行签名都会施以最严厉的处罚
数据可用性问题
数据可用性问题与欺诈证明高度相关，简要说明如下。更多详细信息请参见这篇。
01?欺诈证明
在上面对区块链中的节点的描述中，我们实际上指的是全节点。全节点产生链的区块，下载每个节点中的所有数据，并验证所有交易和状态的有效性。一个全节点要求机器配置大量的内存，强大的计算能力以及非常高的带宽。而像手机这样的受限设备很难满足这样的配置要求。轻节点或者轻客户端是全节点的一种低成本替代方案。它们至少连接到一个全节点上，并且仅下载区块头和想要的区块数据。他们信任全节点来检查数据的有效性，并假定恶意全节点无法创建一条有效的分叉链。欺诈证明是针对轻节点的一种机制，它用于降低被非法链的安全风险。每当诚实的全节点发现某种不一致的状态时，全节点就会生成一个欺诈证明，并为轻节点发出“警报”。此欺诈证明很小，并且可快速在网络进行分发，而且可以肯定地证明某些链的确存在故障。这样，轻节点就可以完全忽略此非法的链，并避免其可能导致的系统状态不一致。
人民数字FINTECH推出区块链科普动画:人民日报数字传播发布微博称，人民数字FINTECH出品《趣味科普|区块链动画》。[2020/3/31]
例如，若全节点发现一笔交易t是错误的，此交易的前后状态分别为S_in和S_out。那么全节点构造出此笔交易对应的欺诈证明为以及相应的Merkle根。证明本身非常小，很容易广播以及验证。轻节点可通过验证Merkle根和交易三元组确定交易的非法性。
数据可用性证明指的是，若某些恶意的全节点对区块头进行了签名，但却不发布区块中的某些数据，该怎么办？特别是如果数据里包含了一笔无效交易该如何？在这种情况下，诚实的全节点无法生成欺诈证明，这是由于缺乏生成欺诈证明所必需要的数据。
02?分片中的数据可用性
数据可用性问题在分片中也尤其重要。如前所述，ETH2.0中的验证人节点不会验证所有区块，也不会去下载所有数据。这是为了让分片机制充分发挥效用，并减轻单个验证人节点的负担。分片区块将由委员会验证，并且只有承诺值会存储在信标链中。从这个角度来看，验证人除了需要一直持续性的参与网络获得之外，它们实际上可看做是大多数分片上的轻节点。分片中的数据可用性问题描述如下图所示：
整体过程可用以下步骤说明：
分片数据以Merkle结构存储得到Merkle根。事实上这是交联数据根，为简便起见，将其称为Merkle根；
提议人节点生产新区块并对Merkle根进行签名；
其他验证人节点对此区块进行投票并签名。其中，BLS签名可聚合成一个签名；
当签名的数量超出门限时，签名的Merkle根就会被添加到信标链上。
声音 | 浪潮集团云南分公司总经理：云南区块链产业发展需从“科普”到“专精”不断深化:据昆明日报消息，浪潮集团云南分公司总经理郑昕表示，云南区块链产业发展需从“科普”到“专精”不断深化。下一步，浪潮将继续加大云南农业产业高质量发展体系建设力度，重点以普洱茶等云南优势产业为切入点，打造云南“绿色、有机农产品高地”的品牌形象，并在此基础上，开展基于区块链的供应链金融服务，解决中小企业贷款难、贷款贵问题。[2019/11/11]
在其它分片上发挥作用的分片无法获知完整的区块链数据，并且也不会去下载，否则，这会直接消除分片所带来的优势。这种情况下的数据可用性问题指的是，如何能够验证分片1中的数据确实可被任何想要下载或验证此数据的全节点所获取。
托管策略
Eth2.0假定2/3的验证人节点是诚实的，并且以这样一种方式将验证人节点分配给对应的分片：若满足2/3的验证节点诚实，则永远不会将不可用或者不正确的区块包含在一个交联中。但是，这里的“诚实”意味着什么呢？可能有一些验证人节点“诚实但懒惰”：鉴于在大多数情况下，没有人试图作弊，因此节点可能永远都需要真正验证任何内容，而只是对任何传入的区块头进行签名。或者，为了更加安全一些，可先等待该区块头积攒了一些签名之后，然后再继续签名。这种方式仍然可以获得奖励，但却几乎不需要做任何工作。如果发生这种情况，攻击者可以依靠这些验证人节点促进无效区块的传播。这对于系统的整体运行状况将会带来灾难性的影响。因此，我们希望尽可能避免使用“诚实但懒惰”的验证人节点，这也正是采用CustodyGame的目的。
CustodyGame本身不能完全解决数据可用性问题。因此，需要额外进行数据可用性检查。但是，它可以确保至少在分片1中对此区块进行签名的验证人节点都拥有数据。
粗略来说，在CustodyGame中，每一个验证人节点必须计算出另外的一个托管比特。此托管比特仅可由持有“秘密”密钥和数据的验证人节点计算出来。在公布托管密钥后，任何人都可使用数据来验证这一托管比特。若发现一个无效的托管比特，可在链上对此进行挑战。如果挑战者是正确的，那么他们将得到奖励，并且托管比特生成方将会被处罚。
科普时报：区块链与云计算长期发展目标不谋而合:据《科普时报》今日报道，区块链与云计算两项技术的结合，从宏观上来说，一方面，利用云计算已有的基础服务设施或根据实际需求做相应改变，实现开发应用流程加速，满足未来区块链生态系统中初创企业、学术机构、开源机构、联盟和金融等机构对区块链应用的需求。另一方面，对于云计算来说，“可信、可靠、可控制”被认为是云计算发展必须要翻越的“三座山”，而区块链技术以去中心化、匿名性，以及数据不可篡改为主要特征，与云计算长期发展目标不谋而合。[2018/5/4]
托管证明存在以下几个关键点：
托管密钥是从验证人节点密钥中确定性地计算出来，以避免采用新的密钥增加系统复杂性。托管密钥会周期性地生成，并且在托管周期结束时公布出来。任何人都可验证托管密钥的有效性。它也被称为临时密钥，因为它仅在一个托管周期阶段有效。
若没有托管密钥和数据，那么生成托管比特的方式与随机猜测并无太大区别。
任何人都可以使用托管密钥和数据来检验托管比特的有效性。
在Eth2.0中，验证人节点的公钥将是BLS签名系统的公钥。一旦质押以太币成为验证人节点，对应的运营者将生成一个公私钥对。对于每一个托管周期，验证人节点都能够生成临时托管密钥ek。临时密钥实际上是对计数器的BLS签名。由于BLS的签名过程是确定性的，因此所有的临时密钥都可预先由公钥完全决定。除了验证人节点本身之外，任何人都无法计算出临时密钥。
托管比特是通过某一类mix函数计算而来，尽管函数的具体形式仍在讨论中，但其规范倾向于使用MPC友好的构造，详见eth2.0-specs。总的来说，托管比特的生成方式为b=mix(ek,D)，其中D为区块数据。
目前，mix函数的构造使用了通用哈希函数和勒让德伪随机函数。这些函数均为带密钥的函数并且是确定性的。因此，给定一个密钥ek，将其表示成两个元素ek0,ek1。然后，验证人节点可计算出托管比特b=Leg_PRF(ek0,UHF(ek0,ek1,D))，如下图中的流程所示：
简而言之，UHF用于扩展输入数据空间，同时避免外包计算。采用LegendrePRF的缘由主要有两点：其一，它在MPC的计算中非常高效；其二，其可确保托管比特具备更好的随机性。可参考这篇文章获取更多细节，并且，我们将会在后续的文章中给出更加深入的解释。MPC友好性Eth2.0的设计目标之一是使其对MPC友好。其中包含了两个原因：其一，通过允许运营节点在多个计算机甚至不同的数据中心之间分布其验证人节点，从而避免单点故障，这可以带来额外的安全性；其二，通过一个无需信任的验证人节点池，能够使资金较少的人可以参与Eth2.0验证。因此，托管证明也应该对MPC友好，这也是使用LegendrePRF的主要原因。由此，这或许会开启一种全新的业务模式，并产生许多其它有趣的应用。请参见此处获取更多细节。
文中链接：
https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html
https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase1/custody-game.md#misc
https://ethresear.ch/t/using-the-legendre-symbol-as-a-prf-for-the-proof-of-custody/5169
https://slideslive.com/38920085/ethereum-20-trustless-staking-pools
https://github.com/PlatONnetwork/proof_of_custody
参考文献：
TheBeaconChainEthereum2.0explaineryouneedtoreadfirst.https://ethos.dev/beacon-chain/
Ethereum2.0:ACompleteGuide.https://medium.com/chainsafe-systems/ethereum-2-0-acomplete-guide-d46d8ac914ce
Ethereum2.0:ACompleteGuide.Scaling,PartOne.https://medium.com/chainsafesystems/ethereum-2-0-a-complete-guide-3739a74be61a
Ethereum2.0:ACompleteGuide.ScalingEthereum—PartTwo:Sharding.https://medium.com/chainsafe-systems/ethereum-2-0-a-complete-guide-scaling-ethereum-parttwo-sharding-902370ac3be
ProofofStakeFAQ.https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
Dataavailabilitychecks.https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html
Anoteondataavailabilityanderasurecoding.https://github.com/ethereum/research/wiki/Anote-on-data-availability-and-erasure-coding
1-bitaggregation-friendlycustodybonds.https://ethresear.ch/t/1-bit-aggregation-friendlycustody-bonds/2236
UsingtheLegendresymbolasaPRFfortheProofofCustody.https://ethresear.ch/t/using-thelegendre-symbol-as-a-prf-for-the-proof-of-custody/5169
Proofofcustodygamedesign.https://github.com/ethereum/eth2.0-specs/issues/568
Theproofofcustodygame.https://notes.ethereum.org/@vbuterin/rkhCgQteN#The-proof-ofcustody-game
Ethereum2.0TrustlessStakingPools.https://slideslive.com/38920085/ethereum-20-trustlessstaking-pools
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。