尊龙凯时k88_aelf共识标准设计

2024-12-11 12:01:01

区块链系统共识：去中心化的共识本质上，区块链系统是一个分布式系统，但是与广泛的分布式系统有所不同。广泛的分布式系统，其意义在于：面临快速增长的业务量，用多台机器支撑横向合并或水平合并后的业务场景，减小系统容量；根据业务的关键程度，避免单点故障，强化系统可用性。当一个区块链系统分担的业务场景简单如广泛的分布式系统时，当然也必须做到如上的考虑到。

但是区块链系统之所以应该被人推崇，是因为它需要解决问题不存在害人节点情况下的数据一致性的问题，也就是拜占庭将军问题。区块链世界中，不不存在所谓的中心化服务器，其是由所有爱好者、受益者或其他涉及人联合包含的P2P网络，网络中的任何一个节点都是不能必要信任的，它们中的任何一个都有害人有可能，这是广泛的分布式系统并会考虑到的问题。这一点，与拜占庭将军问题的假设完全一致：没中心化的领导机构，这些将军必须对某个城市发动反击时，所有将军必须对任何将军明确提出的反击时间达成协议共识。那么问题来了，如果将军们自己要求的反击时间不完全一致，甚至于有将军早已沦为叛徒，那么将军们如何达成协议共识呢？同理，在区块链系统这个P2P网络中，所有的节点如何针对某一笔交易达成协议共识呢（也就是基于这一笔交易对节点各自的数据库作出改动）？在1982年的论文The Byzantine Generals Problem中，Leslie Lamport证明，当将军们中的叛徒不多达1/3时，不存在有效地的算法，无论叛徒们如何着急，忠心的将军们总能达成协议完全一致的结果。

而如果叛徒过多，就无法确保一定能超过完全一致。那么我们必要假设区块链P2P网络中，害人节点数量不多达1/3，否则指出区块链系统建构告终。如此，接下来最无以解决问题的问题就是，在一个害人节点不多达1/3的区块链系统中，要自由选择谁的数据作为达成协议最后共识的数据？换一个角度：如果一个节点期望自己获取的数据需要在区块链系统中达成协议共识，他必须做到什么？他必须获取一个Proof。

一个证明。去劝说区块链系统拒绝接受他所获取的数据。据此，我们开始辩论如何在区块链系统中设计一个标准共识模块。标准共识模块设计区块链达成协议共识的流程：1.节点A打算了一个区块，广播给P2P网络；2.P2P网络的其他节点接到区块以后，经过一系列检验，要求否将该区块放到本地的最久链上；3.当区块链系统中的大多数节点（如多达2/3）本地某个区块高度对应的区块哈希值都完全一致的话，我们就可以指出区块链针对这个高度的区块达成协议了完全一致。

如果必须一个服务来协助节点A及区块链其他节点已完成整个共识过程，那么所获取的服务应当大体上有两种：1.面临一无所知的A，必须在A告知的时候，告诉其（在区块链世界中，A用于一个公钥唯一确认身份）当前能无法尝试产生区块，以及如何设法使其产生的区块让其他节点拒绝接受；2.除了A以外的其他节点，面临从网络上接到的一个A广播出来的区块，通过一个开源的所有节点构建代码都完全一致的服务来检验该区块否合法。如果某节点通过对这个区块的检验，获知该区块合法，则称之为该节点对A产生的这个区块达成协议了共识。因为所有节点的检验服务都是某种程度的逻辑，区块链网络中所有节点对该区块的合法性都会具备一样的态度，注定，这一个区块链P2P网络中（在没更长的链经常出现的情况下）对这个区块被加到到最久链这个事件达成协议最后一致性也是可以意识到的。aelf共识标准化接口标准现在开始，我们基于“标准共识模块设计”中统计资料出来的两类服务，展开aelf共识标准化模块的设计。

首先必须具体，这两类和共识涉及的服务（催促区块生产涉及的命令、检验新的区块）都是读入的模块，其调用本身需要改动区块链网络的账本信息。其次，这些模块实质上不会被aelf主链代码调用，因此其设计必须遵循aelf主链代码中关于生产区块和检验区块的逻辑（当然，即便在主链代码中，这些模块也完全一一对应地经常出现在共识的服务Consensus Service中）。

我们分别辩论两种模块：催促共识命令之后前面的例子，还是节点A，这是一个早已实时到当前aelf最久链的节点。当前时间是2020年1月1日下午13：59：56。

A，作为一个真诚的节点（没改动本地主链代码），刚实时了一个区块（也就是拒绝接受到网络上其他节点的区块，检验顺利，改动了本地的区块链账本信息），本地的Best Chain（确保本地区块链的一个数据结构）获得改版后，Event Bus上装载了一个事件。这个事件的起到之一，就是警告节点A去回答一下共识服务（通过涉及事件订阅者和处置机制），接下来他能做到点什么。在展开告知时，A把自己的公钥传授给了共识服务。

共识服务的核心逻辑作为一个智能合约而不存在，因为只有如此才能确保其代码对于区块链世界中每一个节点都是完全一致的（不完全一致意味著这个节点企图害人或者软末端）。经过宽约几毫秒的简单计算出来（或许是非常简单计算出来），共识的智能合约对系统给节点A一个信息。这个信息的分解就因共识机制的挑选而异，但是无论什么共识，都应当不具备以下结构：· A什么时间可以产生区块？· 如果A可以产生区块，那么A应当用什么方式展开下一步的催促：即在当前共识下，A能产生什么区块。

在此称之为这一信息为额外提醒。如果A无法产生区块怎么办？区块链世界中理论上每个人只不过都有可能产生区块，但是由于共识机制的设计有所不同（比如PoS共识），有些区块链并不期望大多数节点有生产区块的权利。这种情况下，只必须将回到给A的时间设置到一百年后就可以（有可能有些滑稽，但是几个月后总没问题）。只要节点A需要坚决挂机，并且区块链没产生任何一个新的区块（任何有效地的新的区块的实时都会使节点A新的取得一个出块时间）。

不难想象基于这个模块构建PoW有多么更容易。只要时间设置为“马上”，额外提醒为空才可。在aelf主链中，共识服务获知共识对系统的时间信息后，不会马上改版共识调度器（如果此前共识调度器非空，则杀掉之前未完的调度信息，用新的时间点来填满，也就是说共识调度器里面不能有一个并未继续执行的共识任务，且共识调度器是单例的对象）。接下来就是漫长的倒计时。

我们返回节点A这个例子。假设A在催促共识命令后，获得了一个时间：2020年1月1日下午14：00：00，也就是4秒钟以后。额外提醒：NextRound（这是AEDPoS共识的一个提醒，意味著A将落幕本轮的出块流程，并改版下一轮的所有代理出块节点的出块顺序）。

这就意味著调度器会马上改版为4秒后继续执行一个生产区块的事件。这4秒中做到什么？如果可以实时到其他节点发过来的区块，而这些区块可以通过检验，那就用于Best Chain改版这一事件的处理器，大大地问共识服务催促共识命令（这一个操作者在代码中称作TriggerConsensus），适当的，共识调度器就不会大大地重置：3.5秒，3秒，2.5秒，2秒，……再一，时间回到了14：00：00。节点A在共识调度器的支配下开始打算生产区块。此时，按照我们之前的设计，除了早已充分发挥了起到的出块时间，关于如何生产区块，它唯一告诉的信息只有之前共识服务给他的额外提醒。

这时，在aelf中，节点A把额外提示信息传送给共识服务。在包交易之余，还不会调用另外两个服务：· 取得共识区块头信息· 取得共识系统交易催促共识命令的模块有一个起到是设法让生产出来的区块通过检验。在aelf中，在区块的一系列检验步骤中，有两个和共识涉及的检验：继续执行前，检验区块头；继续执行后，对共识合约状态的改动信息否和区块头中的信息的一致性展开检验。

非常简单做到个转换，一个.NET程序员去参与DNT线下沙龙，他拿走参与沙龙的邀短信给沙龙主办方展开按规定，这个短信类似于区块头，也就是说如果他找不出邀短信，那主办方会让他参与。接下来，网卓新闻网，主办方还不会拒绝.NET程序员附上手机号，然后在与会人员的花名册中找寻该手机号，这就类似于在区块链节点继续执行完了共识交易后的检验。

只有这一步也检验通过，.NET程序员才能成功参与此次沙龙。综上所述，针对“催促共识命令”这一类服务，我们必须三个模块。用Protobuf必要叙述如下：service ConsensusContract {rpc GetConsensusCommand (google.protobuf.BytesValue)returns (ConsensusCommand) {option (aelf.is_view) = true;}rpc GetConsensusExtraData (google.protobuf.BytesValue)returns (google.protobuf.BytesValue) {option (aelf.is_view) = true;}rpc GenerateConsensusTransactions (google.protobuf.BytesValue)returns (TransactionList) {option (aelf.is_view) = true;}}message ConsensusCommand {int32 limit_milliseconds_of_mining_block = 2;// Time limit of mining next block.bytes hint = 3;// Context of Hint is diverse according to the consensus protocol we choose, so we use bytes.google.protobuf.Timestamp arranged_mining_time = 4;google.protobuf.Timestamp mining_due_time = 5;}message TransactionList {repeated aelf.Transaction transactions = 1;}出于对链的安全性和稳定性考虑到，在ConsensusCommand中，除了下次出块时间（arranged_mining_time）和额外提醒（hint），还包括了出块时间容许（limit_milliseconds_of_mining_block）和最晚广播时间（mining_due_time）。后面两个信息都是给区块生产服务作为参照的，用来构建如果多达了某个时间容许，生产出来的区块就需要广播（或者即便广播别的节点也无法通过检验，当然这个检验是在下面要辩论的接口类型的明确构建中确保的）；多生产出有一个块也比妨碍区块生产秩序要好。

区块检验如果说催促共识命令还有一点精细辩论的话，区块检验涉及的模块就泛善可陈了。因为区块检验逻辑本质上是几乎因共识而异的。模块本身并无新意，一个是在共识交易继续执行前检验区块头，一个是共识交易继续执行后检验共识改动的状态否和区块头中允诺的信息完全一致。而两个检验模块的进参都是二进制数组，意味著该模块拒绝接受任何数据，只必须共识的构建者在检验的明确构建中自行反序列化才可。

service ConsensusContract {rpc ValidateConsensusBeforeExecution (google.protobuf.BytesValue)returns (ValidationResult) {option (aelf.is_view) = true;}rpc ValidateConsensusAfterExecution (google.protobuf.BytesValue)returns (ValidationResult) {option (aelf.。

本文来源：尊龙凯时k88-www.samybenmayor.com