系统共鸣：去中心化的共鸣
我们别离接头两种接口：
returns (TransactionList) {
假如说请求共鸣呼吁还值得细致接头的话，区块验证相关的接口就泛善可陈了。因为区块验证逻辑本质上是完全因共鸣而异的。
这时，在aelf中，节点A把特别提示信息通报给共鸣处事。在打包生意业务之余，还会挪用别的两个处事：
出于对链的安详和不变性思量，在ConsensusCommand中，除了下次出块时间（arranged_mining_time）和特别提示（hint），还包罗了出块时间限制（limit_milliseconds_of_mining_block）和最晚广播时间（mining_due_time）。后头两个信息都是给区块出产处事作为参考的，用来实现假如高出了某个时间限制，出产出来的区块就无需广播（可能即便广播此外节点也不能通过验证，虽然这个验证是在下面要接头的接口范例的详细实现中担保的）；多出产出一个块也比扰乱区块出产秩序要好。
· 得到共鸣系统生意业务
本质上，区块链系统是一个漫衍式系统，可是与普遍的漫衍式系统差异。普遍的漫衍式系统，其意义在于：面临增长的业务量，用多台呆板承载垂直拆分或程度拆分后的业务场景，增大系统容量；按照业务的要害水平，消除单点妨碍，增强系统可用性。当一个区块链系统包袱的业务场景巨大如普遍的漫衍式系统时，虽然也需要做如上的思量。可是区块链系统之所以该当被人重视，是因为它可以或许办理存在作恶节点环境下的数据一致性的问题，也就是拜占庭将军问题。
service ConsensusContract {
    bytes hint = 3;
此刻开始，我们基于“尺度共鸣接口设计”中统计出来的两类处事，举办aelf共鸣通用接口的设计。
    rpc ValidateConsensusAfterExecution (google.protobuf.BytesValue) 
        option (aelf.is_view) = true;
returns (google.protobuf.BytesValue) {
}
        option (aelf.is_view) = true;
请求共鸣呼吁的接口有一个浸染是设法让出产出来的区块通过验证。在aelf中，在区块的一系列验证步调中，有两个和共鸣相关的验证：执行前，验证区块头；执行后，对共鸣合约状态的修改信息是否和区块头中的信息的一致性举办验证。
}
· 假如A可以发生区块，那么A应该用什么方法举办下一步的请求：即在当前共鸣下，，A能发生什么区块。在此称这一信息为特别提示。
据此，我们开始接头如安在区块链系统中设计一个尺度共鸣接口。
· 得到共鸣区块头信息
假如某节点通过对这个区块的验证，得知该区块正当，则称该节点对A发生的这个区块告竣了共鸣。因为所有节点的验证处事都是同样的逻辑，区块链网络中所有节点对该区块的正当性城市具有一样的立场，终究，这一个区块链P2P网络中（在没有更长的链呈现的环境下）对这个区块被添加到最长链这个事件告竣最终一致性也是可以预见的。
    rpc GetConsensusExtraData (google.protobuf.BytesValue) 
    // Time limit of mining next block.
    bool success = 1;
区块链世界中，不存在所谓的中心化处事器，其是由所有喜好者、受益者或其他相关人配合组成的P2P网络，网络中的任何一个节点都是不行直接信任的，它们中的任何一个都有作恶大概，这是普遍的漫衍式系统并不会思量的问题。这一点，与拜占庭将军问题的假设一致：没有中心化的率领机构，这些将军需要对某个都市提倡进攻时，所有将军需要对任何将军提出的进攻时间告竣共鸣。那么问题来了，假如将军们本身抉择的进攻时间纷歧致，甚至于有将军已经成为叛徒，那么将军们如何告竣共鸣呢？
    google.protobuf.Timestamp arranged_mining_time = 4;
我们回到节点A这个例子。假设A在请求共鸣呼吁后，获得了一个时间：2020年1月1日下午14：00：00，也就是4秒钟今后。特别提示：NextRound（这是AEDPoS共鸣的一个提示，意味着A将终结本轮的出块流程，并更新下一轮的所有署理出块节点的出块顺序）。这就意味着调治器会立即更新为4秒后执行一个出产区块的事件。这4秒中做什么？假如可以同步到其他节点发过来的区块，而这些区块可以通过验证，那就利用Best Chain更新这一事件的处理惩罚器，不绝地问共鸣处事请求共鸣呼吁（这一个操纵在代码中称为TriggerConsensus），相应的，共鸣调治器就会不绝地重置：3.5秒，3秒，2.5秒，2秒，……
    int32 limit_milliseconds_of_mining_block = 2;
    }
    bool is_re_trigger = 3;
首先需要明晰，这两类和共鸣相关的处事（请求区块出产相关的指示、验证新区块）都是只读的接口，其挪用自己无需修改区块链网络的账本信息。
继承前面的例子，照旧节点A，这是一个已经同步到当前aelf最长链的节点。当前时间是2020年1月1日下午13：59：56。A，作为一个厚道的节点（没有修改当田主链代码），方才同步了一个区块（也就是接管到网络上其他节点的区块，验证乐成，修改了当地的区块链账本信息），当地的Best Chain（维护当地域块链的一个数据布局）获得更新后，Event Bus上装载了一个事件。这个事件的浸染之一，就是提醒节点A去问一下共鸣处事（通过相关事件订阅和处理惩罚机制），接下来他能做点什么。在举办询问时，A把本身的公钥传给了共鸣处事。

假如需要一个处事来辅佐节点A及区块链其他节点完成整个共鸣进程，那么所提供的处事应该概略上有两种：
        option (aelf.is_view) = true;
请求共鸣呼吁
不难想象基于这个接话柄现PoW有何等容易。只要时间配置为“立即”，特别提示为空即可。
    string message = 2;
aelf共鸣通用接口尺度
service ConsensusContract {
区块链告竣共鸣的流程：
1.面临一无所知的A，需要在A询问的时候，奉告其（在区块链世界中，A利用一个公钥独一确定身份）当前能不能实验发生区块，以及如何设法使其发生的区块让其他节点接管；
· A什么时间可以发生区块？
综上所述，针对“请求共鸣呼吁”这一类处事，我们需要三个接口。用Protobuf直接描写如下：
returns (ValidationResult) {
    rpc GenerateConsensusTransactions (google.protobuf.BytesValue) 
简朴做个类比，一个.NET措施员去介入DNT线下沙龙，他拿出介入沙龙的邀请短信给沙龙主办方举办磨练，这个短信雷同于区块头，也就是说假如他拿不出邀请短信，那主办方不会让他介入。接下来，主办方还会要求.NET措施员报脱手机号，然后在参会人员的混名册中寻找该手机号，这就雷同于在区块链节点执行完共鸣生意业务后的验证。只有这一步也验证通过，.NET措施员才气顺利介入此次沙龙。
尺度共鸣接口设计
区块验证
    }
    repeated aelf.Transaction transactions = 1;

3.当区块链系统中的大大都节点（如高出2/3）当地某个区块高度对应的区块哈希值都一致的话，我们就可以认为区块链针对这个高度的区块告竣了一致。