本文标题Algorand源码架构分析，作者：知世，本文有1249个文字，大小约为5KB，预计阅读时间4分钟，请您欣赏。知世金融网众多优秀文章，如果想要浏览更多相关文章，请使用网站导航的搜索进行搜索。本站虽然不乏优秀之作，但仅作为投资者学习参考。

本篇主要介绍Algorand源码中关于agreement的模块结构及业务逻辑架构，也是源码中比较难以理解的地方，其它诸如节点、区块、密码、P2P网络的结构与其它区块链项目都是大同小异，很容易理解，这里就不再赘述。

1. 节点启动

一切从main开始：

Node模块中还提供了各种pool，这些pool用于对网络中的proposal与vote进行验证时的任务队列。

下面这句开启我们的agreement协议：

2. Agreement

协议是Algorand最重要的一个模块，在其中用service做一个总的任务调试，状态机负责对投票进行统计，demux负责具体action的执行，从网络上收集proposal与vote，是Algorand的二元拜占庭（BBA）实现的部分。

2.1 service

这一个模块中分为两大部分：

模块A：具体的proposal、vote验证，及转发
模块B：状态机机制：处理针对每个区块共识周期内的投票统计

这两个大模块之间通过三个chan来进行互相驱动：

模块A做完自己的具体工作，会给externalEvent通道写入event，模块B从这些通道读数据，进行对应的统计处理；

模块B做完自己的统计处理工作，会给action通道写入对应的action，给externalDemuxSignals通道写入对应的signal

这几个chan促成了模块A与模块B之间的互动：

模块A是input的生产者，是output与ready的消费者；

模块B正好反过来，是input的消费者，是output与ready的生产者。

2.2 状态机

这里的代码主要是对vote与proposal进行统计，一个区块共识周期内的两轮多步投票的统计都是在这里完成的，分为5层状态机，每层只负责处理与自己有关的，上层处理不了的，移交给下层状态机，下层状态机将处理结果返回给上层状态机，最终发出对应的action。

Player即playmachine实现了整个状态机的最顶层功能，负责记录当前哪个区块第几个阶段第几步的共识环节，以及超时等基础信息。

proposalManager是proposal的管理类，在这里监测proposal是否已经超过阈值，如果超过，向上层发出proposalCommittable的事件。

voteAggregator是vote的管理类，也是用来监测是否vote已经超过阈值，向上层发出threshhold。

proposalStore是round层的主类，主要用来存储proposal，以存储的权重来最终判定proposal是否达到一定数量。

voteTracker是step层的主类，用来存储vote，是最初发出vote超过阈值的地方。

各个类的具体功能，仔细查看代码并不难理解。

在这一模块中定义有两个类，一个是router接口，一个是routerHandle结构体。前者用于真正的event处理，而后者只是为了构造一个新的结构，加入写日志功能及标明状态机类型，起辅助功能。routerHandle的dispatch最终其实是转到了对应的router的dispatch中去执行的。

2.3. Action

状态机针对vote与proposal进行统计后，会发出一系统的action，这些都由各个对应的类去处理。

在actions.go里会看到不同种类的action，我们只要在对应的类里去查就知道如何处理各个action，action就是对应我们实际要处理的各个动作。

2.4. 外部消息

在demux.go文件里，next函数负责从消息通道里获取消息，转化成对应的事件传给状态机

3. MakeProposals与MakeVotes

MakeProposals发出一个proposal，其实就是提议一个区块，同时自己对这个区块进行投票。MakeVotes就是对proposal直接进行投票。

pseudonode里MakeProposals，会经过pseudonodeVerifier这个service里的这个对象做一个异步队列：

s.voteVerifier = MakeAsyncVoteVerifier(s.BacklogPool)

verificationPool,是基于backlogpool与POOL来实现的，最后每个任务的实际执行又回到了pseudonode里的execute。兜兜转转一圈，其它都只是工具，主类还是这个pseudonode，在这里makeproposal与makeVote,异步调用的真正执行也是在这个类文件里，对应类的execute。.在这个execute里才去做的makeProposal与makeVote.

4. 如何选出领导者

我们知道是对credential，也就是凭证做排序，最小的就是领导者。这些其实发生在每一个节点上，在每一个节点上对所有voteVerified的事件做处理，比较大小得到。

看代码，在状态机proposalMachinePeriod对应的主类proposalTracker中，handle处理消息的主函数

这里的freezer就是proposalSeeker的一个对象，这个类负责记录credential值最小的那一个，那停止时间是什么呢，就是说这个时间段的结束时间是什么呢？

proposalFrozenEvent这个消息发出来后，在状态机里

这样freeze就对leader完成了选定，我们再查什么时候发出这个事件。这个是由超时函数来控制的，在主状态机里，timeout事件，当step是soft步骤时，超时，就进入cert阶段，这时就得终止这个credential最小值的选择了。

本篇并未对Algorand的每个细节知识进行深入的阐述，而是从代码的大框架上做一个简单说明，希望可以帮助大家理清数据流的走向，把握源码架构。

本文相关推荐： 既增资又发债 阳光人寿偿付能力“补血”忙 新一轮寿险组织架构调整已基本到位

以上便是知世金融网给大家分享的关于Algorand源码架构分析/qkl/27256.html的相关信息了，希望能帮助到大家，更多金融相关信息，敬请关注知世金融网！

网站内容均来自互联网，如侵害您的利益联系客服进行删除！