sVc区块链数字货币资讯|
当前位置:首页 > 币圈学院

币圈学院

Algorand源码架构分析

时间:2019-09-06 06:22:23   作者:VcKing   来源:VcKing   阅读:199   评论:0
内容摘要: 本篇主要介绍Algorand源码中关于agreement的模块结构及业务逻辑架构,也是源码中比较难以理解的地方,其它诸如节点、区块、密码、P2P网络的结构与其它区块链项目都是大同小异,很容易理解,这里就不再赘述。1. 节点启动一切从main开始:Node模块中还提供了各种poo......
本篇主要介绍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的每个细节知识进行深入的阐述,而是从代码的大框架上做一个简单说明,希望可以帮助大家理清数据流的走向,把握源码架构。


标签:模块  状态  一个  区块  proposal  

相关文章

相关评论