基于Algorand源碼中agreement的模塊結(jié)構(gòu)介紹

本篇主要介紹Algorand源碼中關(guān)于agreement的模塊結(jié)構(gòu)及業(yè)務(wù)邏輯架構(gòu)，也是源碼中比較難以理解的地方，其它諸如節(jié)點(diǎn)、區(qū)塊、密碼、P2P網(wǎng)絡(luò)的結(jié)構(gòu)與其它區(qū)塊鏈項(xiàng)目都是大同小異，很容易理解，這里就不再贅述。

1. 節(jié)點(diǎn)啟動(dòng)

一切從main開(kāi)始：

Node模塊中還提供了各種pool，這些pool用于對(duì)網(wǎng)絡(luò)中的proposal與vote進(jìn)行驗(yàn)證時(shí)的任務(wù)隊(duì)列。

下面這句開(kāi)啟我們的agreement協(xié)議：

2. Agreement

協(xié)議是Algorand最重要的一個(gè)模塊，在其中用service做一個(gè)總的任務(wù)調(diào)試，狀態(tài)機(jī)負(fù)責(zé)對(duì)投票進(jìn)行統(tǒng)計(jì)，demux負(fù)責(zé)具體action的執(zhí)行，從網(wǎng)絡(luò)上收集proposal與vote，是Algorand的二元拜占庭（BBA）實(shí)現(xiàn)的部分。

2.1 service

這一個(gè)模塊中分為兩大部分：

模塊A：具體的proposal、vote驗(yàn)證，及轉(zhuǎn)發(fā)

模塊B：狀態(tài)機(jī)機(jī)制：處理針對(duì)每個(gè)區(qū)塊共識(shí)周期內(nèi)的投票統(tǒng)計(jì)

這兩個(gè)大模塊之間通過(guò)三個(gè)chan來(lái)進(jìn)行互相驅(qū)動(dòng)：

模塊A做完自己的具體工作，會(huì)給externalEvent通道寫入event，模塊B從這些通道讀數(shù)據(jù)，進(jìn)行對(duì)應(yīng)的統(tǒng)計(jì)處理；

模塊B做完自己的統(tǒng)計(jì)處理工作，會(huì)給action通道寫入對(duì)應(yīng)的action，給externalDemuxSignals通道寫入對(duì)應(yīng)的signal

這幾個(gè)chan促成了模塊A與模塊B之間的互動(dòng)：

模塊A是input的生產(chǎn)者，是output與ready的消費(fèi)者；

模塊B正好反過(guò)來(lái)，是input的消費(fèi)者，是output與ready的生產(chǎn)者。

2.2 狀態(tài)機(jī)

這里的代碼主要是對(duì)vote與proposal進(jìn)行統(tǒng)計(jì)，一個(gè)區(qū)塊共識(shí)周期內(nèi)的兩輪多步投票的統(tǒng)計(jì)都是在這里完成的，分為5層狀態(tài)機(jī)，每層只負(fù)責(zé)處理與自己有關(guān)的，上層處理不了的，移交給下層狀態(tài)機(jī)，下層狀態(tài)機(jī)將處理結(jié)果返回給上層狀態(tài)機(jī)，最終發(fā)出對(duì)應(yīng)的action。

Player即playmachine實(shí)現(xiàn)了整個(gè)狀態(tài)機(jī)的最頂層功能，負(fù)責(zé)記錄當(dāng)前哪個(gè)區(qū)塊第幾個(gè)階段第幾步的共識(shí)環(huán)節(jié)，以及超時(shí)等基礎(chǔ)信息。

proposalManager是proposal的管理類，在這里監(jiān)測(cè)proposal是否已經(jīng)超過(guò)閾值，如果超過(guò)，向上層發(fā)出proposalCommittable的事件。

voteAggregator是vote的管理類，也是用來(lái)監(jiān)測(cè)是否vote已經(jīng)超過(guò)閾值，向上層發(fā)出threshhold。

proposalStore是round層的主類，主要用來(lái)存儲(chǔ)proposal，以存儲(chǔ)的權(quán)重來(lái)最終判定proposal是否達(dá)到一定數(shù)量。

voteTracker是step層的主類，用來(lái)存儲(chǔ)vote，是最初發(fā)出vote超過(guò)閾值的地方。

各個(gè)類的具體功能，仔細(xì)查看代碼并不難理解。

在這一模塊中定義有兩個(gè)類，一個(gè)是router接口，一個(gè)是routerHandle結(jié)構(gòu)體。前者用于真正的event處理，而后者只是為了構(gòu)造一個(gè)新的結(jié)構(gòu)，加入寫日志功能及標(biāo)明狀態(tài)機(jī)類型，起輔助功能。routerHandle的dispatch最終其實(shí)是轉(zhuǎn)到了對(duì)應(yīng)的router的dispatch中去執(zhí)行的。

2.3. Action

狀態(tài)機(jī)針對(duì)vote與proposal進(jìn)行統(tǒng)計(jì)后，會(huì)發(fā)出一系統(tǒng)的action，這些都由各個(gè)對(duì)應(yīng)的類去處理。

在actions.go里會(huì)看到不同種類的action，我們只要在對(duì)應(yīng)的類里去查就知道如何處理各個(gè)action，action就是對(duì)應(yīng)我們實(shí)際要處理的各個(gè)動(dòng)作。

2.4. 外部消息

在demux.go文件里，next函數(shù)負(fù)責(zé)從消息通道里獲取消息，轉(zhuǎn)化成對(duì)應(yīng)的事件傳給狀態(tài)機(jī)

3. MakeProposals與MakeVotes

MakeProposals發(fā)出一個(gè)proposal，其實(shí)就是提議一個(gè)區(qū)塊，同時(shí)自己對(duì)這個(gè)區(qū)塊進(jìn)行投票。MakeVotes就是對(duì)proposal直接進(jìn)行投票。

pseudonode里MakeProposals，會(huì)經(jīng)過(guò)pseudonodeVerifier這個(gè)service里的這個(gè)對(duì)象做一個(gè)異步隊(duì)列：

s.voteVerifier = MakeAsyncVoteVerifier（s.BacklogPool）

verificationPool，是基于backlogpool與POOL來(lái)實(shí)現(xiàn)的，最后每個(gè)任務(wù)的實(shí)際執(zhí)行又回到了pseudonode里的execute。兜兜轉(zhuǎn)轉(zhuǎn)一圈，其它都只是工具，主類還是這個(gè)pseudonode，在這里makeproposal與makeVote，異步調(diào)用的真正執(zhí)行也是在這個(gè)類文件里，對(duì)應(yīng)類的execute。。在這個(gè)execute里才去做的makeProposal與makeVote.

4. 如何選出領(lǐng)導(dǎo)者

我們知道是對(duì)credential，也就是憑證做排序，最小的就是領(lǐng)導(dǎo)者。這些其實(shí)發(fā)生在每一個(gè)節(jié)點(diǎn)上，在每一個(gè)節(jié)點(diǎn)上對(duì)所有voteVerified的事件做處理，比較大小得到。

看代碼，在狀態(tài)機(jī)proposalMachinePeriod對(duì)應(yīng)的主類proposalTracker中，handle處理消息的主函數(shù)

這里的freezer就是proposalSeeker的一個(gè)對(duì)象，這個(gè)類負(fù)責(zé)記錄credential值最小的那一個(gè)，那停止時(shí)間是什么呢，就是說(shuō)這個(gè)時(shí)間段的結(jié)束時(shí)間是什么呢？

proposalFrozenEvent這個(gè)消息發(fā)出來(lái)后，在狀態(tài)機(jī)里

這樣freeze就對(duì)leader完成了選定，我們?cè)俨槭裁磿r(shí)候發(fā)出這個(gè)事件。這個(gè)是由超時(shí)函數(shù)來(lái)控制的，在主狀態(tài)機(jī)里，timeout事件，當(dāng)step是soft步驟時(shí)，超時(shí)，就進(jìn)入cert階段，這時(shí)就得終止這個(gè)credential最小值的選擇了。

本篇并未對(duì)Algorand的每個(gè)細(xì)節(jié)知識(shí)進(jìn)行深入的闡述，而是從代碼的大框架上做一個(gè)簡(jiǎn)單說(shuō)明，希望可以幫助大家理清數(shù)據(jù)流的走向，把握源碼架構(gòu)。
來(lái)源；眾享比特?