在2023年11月30日,quorum 推出了 2.0 的 release 版本。這一版最大的改動就是剔除了 quorumchain的共識方式,只支援 raft-based consensus。相比較以太坊的pow,raft-based 提供了更快更高效的區塊生成方式。相比 quorumchain,raft-based 不會產生空的區塊,而且在區塊的生成上比前者更有效率。
在這一章節,我們重點關注 raft 是如何被運用到 quorum 上的。想要了解 raft 演算法的技術細節,可以參考 raft.github.io 或者 raft 動態演示。
quorum 的 raft **主要沿用了 etcd』s raft implementation。
以太坊和 raft 都有節點這一概念。在 raft 中,節點可以有 leader, follower, condidate 三種身份。leader 負責生產區塊。follower 監聽 leader 的心跳並收取 leader 傳遞過來的區塊。follower 一段時間沒有收到來自 leader 的心跳後,就轉變身份為 candidate,同時整個 raft 進入下乙個週期。然後 candidate 向所有節點傳送投票的請求,其他節點(leader 收到訊息後 leader 身份就被收回)收到請求後給予應答。如果 candidate 收到超過半數的應答,則晉公升為 leader。乙個節點乙個週期只能投一次票。
在以太坊中,任意節點都可以作為區塊的打包者,只要其在一輪 pow 中勝出。我們知道 quorum 的節點沿用了以太坊的設計和**。所以為了連線以太坊節點和 raft 共識,quorum 採用了網路節點和 raft 節點一對一的方式來實現 raft-based 共識。當一筆 tx 誕生後,tx 會在以太坊的 p2p 網路中傳輸。同時,raft 的 leader 競選一直在同步進行。當前 leader 節點對應的以太坊節點收到 tx 時,以太坊節點就會將 tx 打包成區塊並將區塊通過 raft 節點傳送給 raft 網路上的 follower。follower 節點收到區塊後將區塊交給對應的以太坊節點。然後以太坊節點將區塊記錄到鏈上。
與以太坊不同的是,當乙個節點收到區塊後並不會馬上記錄到鏈上。而是等 raft 網路中的 leader 收到所有 follower 的確認回執後,廣播乙個執行的訊息。然後所有收到執行訊息的 follower 才會將區塊記錄在本地的鏈上。
讓我們來看看乙個完整的 tx 流是怎樣的:
客戶端發起一筆 tx 並通過 rpc 來呼叫節點。
節點通過以太坊的 p2p 協議將節點廣播給網路。
當前的 raft leader 對應的以太坊節點收到了 tx 後將 tx 打包成區塊。
區塊被 rlp 編碼後傳遞給對應的 raft leader。
follower 收到這個包含區塊資訊的指令後,返回確認回執給 leader。
raft 節點將區塊傳遞給對應的 quorum 節點。quorum 節點校驗區塊的合法性,如果合法則記錄到本地鏈上。
具體流程如下:
node1
作為 leader 產生乙個新的區塊:[0x002, parent: 0x001]
。這個區塊的父塊是編號為 0x001 的區塊。node1
通過 raft 將這個區塊進行共識。
0x002 區塊共識成功後網路出現了問題,node1
無法與大部分的 follower 進行通訊。
於此同時,那些無法與node1
通訊的 follower 因為長時間沒收到 leader 的心跳,所以推選出了新的 leader:node2
。
node2
繼續生成區塊[0x005, parent: 0x004]
。
最後整個流程下來,follower 的 raft log 內容大致會長這樣:
得到區塊[0x002, parent: 0x001, sender: node1]
- 執行
得到區塊[0x004, parent: 0x002, sender: node2]
- 執行
得到區塊[0x003, parent: 0x002, sender: node1]
- 不執行
得到區塊[0x005, parent: 0x004, sender: node2]
- 執行
乙個區塊從被建立,到經過 raft 同步,到最後記錄到鏈上多多少少會經歷一段時間(儘管非常短)。如果等上乙個區塊寫入到鏈上以後下乙個區塊才能生成,那麼就會使得 tx 的確認時間增長。為了解決這個問題,同時為了能更有效率的處理區塊生成,quorum 推出了speculative minting
機制。在這種機制下,新區塊可以在其父區塊沒有完全上鏈的情況下被建立。如果這個場景重複出現,那麼就會出現一串未被上鏈的區塊,這些區塊都會有指向其父區塊的索引,我們將這類區塊串稱為speculative chain
。
在維護 speculative chain 的同時,系統還會維護乙份被稱作proposedtxes
的陣列。這份陣列包含了所有 speculative chain 中的 tx。主要是為了記錄已經被傳輸到 raft 中但是還沒被正式上鏈的交易。防止同一條交易被重複打包。
與以太坊的共識機制相比較,raft-based consensus 除了效率上的不同外,最大的差異是前者保證的是最終一致性,而 raft 保證的是強一致性。既每次產生的區塊都要求全網保持共識。在這裡我們只是粗粗的了解 raft-based,還需要更多對原始碼的研究來撥開 quorum 的面紗。
區塊鏈 基於Rails開發以太坊
基於ruby on rails開發以太坊的應用 一 理解以太坊的網路架構 其中node執行 geth 或者eth 彼此通過 30303 埠進行p2p的連線,其上執行的協議即俗稱挖礦協議,也即共識協議,包括幾個部分,廣播交易或訊息,同步區塊等。node即節點,經常也稱 geth client 或get...
以太坊區塊鏈
由私鑰控制.與 無關聯 可以建立發起交易給另外乙個賬戶.外部賬號之間的交易是轉賬 外部賬戶轉賬到合約賬戶可以啟用合約賬戶 被合約 控制,有關聯的 可以響應外部賬戶發起的交易 這裡需要注意的是這裡的merkle樹並不是位元幣的merkle樹,以太坊使用的是mpt樹.merkle樹的變種,功能更強大.可...
以太坊私鏈搭建
搭建私有鏈官方文件 network id 隔離網路 ethereum options networkid value network identifier integer,1 frontier,2 morden disused 3 ropsten,4 rinkeby default 1 networ...