本篇主要介紹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的每個細節知識進行深入的闡述，而是從代碼的大框架上做一個簡單說明，希望可以幫助大家理清數據流的走向，把握源碼架構。
來源；眾享比特?