達成一致
交易在 Sumeragi 在一個區塊中提出之前進入隊列.驗證者獨立驗證和執行該提案,然後只簽署他們可以複製的狀態過渡.要求驗證人數組同意該結果後,區塊承諾並提供匹配的有效載荷.
所有 Iroha 3 網絡都使用數據可用性和可靠的廣播路徑. 這些是共識要求,而不是可選部署功能.
Sumeragi
Sumeragi 是 Iroha 的拜占庭錯誤耐受共識引擎.它從隊列中取出交易,讓驗證者同行同意同一條訂單的塊,並在足夠的驗證者複製相同結果並簽署承諾證書後才完成該塊.
提議和承諾途徑
Sumeragi 一次運行本書一塊高度.每一個高度,一個驗證者作爲當前視圖的提議者.提議者從隊列中取消符合條件的交易,構建一個候選區塊,並向活躍的驗證器集合宣佈該提案.
同一個 Sumeragi 管道用於授權和指名證據 (NPoS) 的部署:
- 一個驗證者提出了排隊交易的阻止.
- 驗證者通過對同一個世界國家進行交易來驗證該提案.
- 驗證者對當前的高度和視圖交換了投票和定製證書.
- 一旦達成合同定數, 同齡人會阻止和更新他們的世界狀況.
驗證器只簽署他們可以本地複製的數據. 在投票之前,驗證者檢查該提案是否屬於預期鏈路,高度和視圖;交易簽名和限制是否有效;軌道路由和執行者的驗證是否確定性;如果本地結果不同,驗證者將拒絕該提案,而不是投票支持.
投票是小簽名的共識信息.它們指的是擬議的塊,高度,視圖和驗證器身份.收藏者將這些投票集成到一個定數證書或提交證書. 證書是足夠的驗證者對同一塊觀察到同樣的結果的持久證明.
團隊,收集者和觀察員
投票驗證人數量 n 對於至少有4個驗證器的網絡,預算爲 f = floor((n - 1) / 3) 委託人數是: 2f + 1. 一到三個驗證器,所有驗證者都需要承擔,這對開發有用,但沒有實際的離線寬鬆性.
而不是每一個驗證器向其他驗證器發送每個投票, Sumeragi 可以選擇一個或多個收集器爲高度.收藏者收集投票,公佈定數進展和減少重複投票流量.通過 GET /v1/sumeragi/collectors暴露有效收藏器設置; CLI 的 ops sumeragi telemetry快照報告了當前收藏器計數.
觀察員同行可以同步承諾的區塊,但它們不會提出,投票,收集票數或計入提交定製組.在部署需要本地查詢能力,索引,監測或區域區塊複製的情況下使用觀察員,而不會增加投票驗證者的數量.
查看變化和恢復
一個視圖是 Sumeragi 試圖通過特定的提議者和時間計劃完成一個高度.如果提案,有效載荷,投票或執行進步攤位,心臟計時器可以將高度轉移到更晚的視圖.視圖改變不會重寫承諾的塊.它改變了驗證者試圖完成未承諾的高度的方式,將已知的最高數量推進或提交證據,以便同齡人不會最終完成矛盾的塊.
一個同行可能在獲得完整的區塊實用負載之前收到定數或承諾證書.同行使用可靠的廣播 (RBC) 或區塊同步來恢復有效載荷,對廣告的哈希進行驗證,然後纔將區塊應用到世界狀態和 Kura.
共識方式
選擇的模式控制了驗證器集是如何形成和運行的.它通過 consensus_mode在基因中被聲明,並通過 sumeragi.consensus_mode在同等配置中被宣佈.視爲整個網絡狀態:驗證器需要相同的簽署基因,拓學,可靠的同行數據和有效的 Sumeragi 參數.
| 模式 | 最適合的 | 驗證器設置 | 運營重點 |
|---|---|---|---|
| 允許 | 私人,聯盟和運營商管理的網絡 | 驗證器來自部署同意的可靠同行拓學 | 保持所有驗證器相同的簽名基因,可信的同行,同行鍵和 Sumeragi 參數. |
| 公共服務局 | 公共或 Nexus- 覈准後的指名和股權政策 | 驗證器是根據NPoS資料選擇的,通常在各個時代之間,並且需要 BLS 鍵加上擁有證明. | 在整個網絡中保持分局快照,時代參數,驗證器 PoPs 和NPoS階段時間排列 |
允許的模式
在驗證器名單是明確的操作選擇時使用允許模式.這是自主託管 Iroha 網絡的通常起點,因爲會員變更是故意的治理或管理者行動.重要操作規則是,每個驗證器必須以相同的基因觀,可信任同行,BLS 所有權證明和 Sumeragi 參數運行.具有不同的拓或簽名基因的單個同行可以防止網絡進行承諾.
NPOS模式
使用NPoS模式,當部署配置預計驗證者的參與由提名和投資狀態驅動時. SORA Nexus 部署使用NPoS,其生成的資料包括: BLS 驗證人身份,擁有權證明,時代設置,以及 Sumeragi 在啓動時需要的NPoS參數. 年代變化可以取代在定義高度設置的活躍驗證器,因此,運營商需要監測共識的健康狀況以及接下來的名單的參與或提名狀態.
多邊共識
Iroha 的多行共識路徑通過 Nexus 車道和數據空間配置實現.它不會爲每個車道啓動一個單獨的共識實例.Sumeragi 仍然完成一個訂單的區塊流; 軌道描述了交易如何在該流中路由,計劃,計量和存儲.
運行時間配置構建了三個車道狀態:
lane_catalog:配置的行徑,每個行列都有一個數字的LaneId,別名,數據空間,可見性,存儲資料,證明方案和元數據.dataspace_catalog:配置的數據空間,每個區域都有一個數值DataSpaceId和用於繼電委員會尺寸的故障耐受值.routing_policy:默認行徑/數據空間對和可匹配賬戶或指令路徑的順序路由規則.
當一個交易進入隊列時,車道路由器將其解決爲 RoutingDecision { lane_id, dataspace_id }.在單車道模式下,這總是車道 0 和通用數據空間.在 Nexus 模式下,配置的路由器應用數據空間範圍規則,結算路由,賬戶規則,明確路由規則,最後是默認路線.已解決的行徑和數據空間必須存在於它們的目錄中,並且該行徑必須與已解決的數據空間聯繫在一起;否則交易在排隊之前被拒絕.
排隊將這個路由決定與交易哈希保持在一起,以便後期階段不需要再推斷它.後者以兩種方式使用車道元數據:
- 它將交易分隔一條車道,所以一個車道不佔據區塊,僅因爲其交易是排隊的.
- 它適用於每條車道交易執行單元 (TEU) 的限制.超越車道配置容量的交易會被推遲和排隊,除了可以允許第一個車道過度權重交易以避免活.
在可靠的廣播中, Sumeragi 按車道和數據空間整合了擬議的有效載荷.記錄的總數包括交易計數,廣播塊,有效載荷字節和 TEU.提交後,這些總數成爲通過 Sumeragi 狀態曝光的軌道和數據區域承諾快照.如果區塊包含車道結算收據,則區塊處理還會創建車道結賬承諾和連接包裹,綁定區塊標題,提交證書,數據可用性承諾哈希,結賬證明以及車道有效載荷大小.
可靠的廣播 (RBC)
可靠的廣播 (RBC) 是 Sumeragi 的有效載荷傳播和恢復路徑. 它幫助驗證者和觀察員獲取屬於提案的塊體或承諾證書,特別是當一個 BlockCreated消息,區塊同步更新或直接的有效載荷轉移延遲或丟失時.
RBC 在有效載荷級別上運行. 提出者宣佈 RBC 會議爲區塊高度,視圖和有效載荷哈希,然後將有效載荷塊發送到提交拓度中.同行追蹤部分收件,驗證恢復的有效載荷與廣告的哈希和交換 READY 和 DELIVER信號一旦有足夠的驗證者會議被限制在 TTL,零件, fanout,懸而未決的存儲和持久的存儲限制,因此恢復流量不能無限增長.
RBC 不是單獨的共識決定,也不取代承諾證書.當同行有有效的承諾證書和本地相匹配的實用負載時,一個區塊仍然會完成.RBC 提供強制性可用性證據和有效載荷回收,而承諾進展是由提交證書加上本地有效載荷驅動的.如果證書在有效載荷之前抵達,同行可以通過 RBC 或區塊同步恢復有效載荷,然後承擔.
在操作上, RBC 對於診斷缺失有效載荷和數據可用性瓶有用:
iroha --output-format text ops sumeragi telemetry顯示總可用性投票,當前收藏人數和正在進行的 RBC 會議.GET /v1/sumeragi/rbc和GET /v1/sumeragi/rbc/sessions披露詳細的綜合數據和活動會議數據 Torii, 包括零件進展,準備性,交付狀態以及車道或數據空間後載;見 Torii 終點.- 預測信號如:
sumeragi_rbc_store_pressure,sumeragi_rbc_backpressure_deferrals_total, 和每條路線或每條數據空間 RBC 後載量度儀有助於分離網絡損失,零件恢復和存儲壓力;見 績效和指標.
Kura 用於存儲佈局的衍生車道配置.每條車道都獲得blocks/lane_000_core和merge_ledger/lane_000_core_merge.log等確定性存儲名稱;車道生命週期變化可以在不改變全球區塊順序的情況下提供,退休或重新標籤這些段落.