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

1. 節(jié)點啟動

一切從main開始：

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

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

2. Agreement

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

2.1 service

這一個模塊中分為兩大部分：

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

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

這兩個大模塊之間通過三個chan來進(jìn)行互相驅(qū)動：

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

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

這幾個chan促成了模塊A與模塊B之間的互動：

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

模塊B正好反過來，是input的消費者，是output與ready的生產(chǎn)者。

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

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

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

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

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

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

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

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

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

2.3. Action

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

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

2.4. 外部消息

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

3. MakeProposals與MakeVotes

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

pseudonode里MakeProposals，會經(jīng)過pseudonodeVerifier這個service里的這個對象做一個異步隊列：

s.voteVerifier = MakeAsyncVoteVerifier（s.BacklogPool）

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

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

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

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

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

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

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

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