Solana 技術解析:深入瞭解 Solana 網路的運行原理和特點!

每個區塊鏈網絡,都有網絡層、共識層、應用層的區分。每個區塊鏈網絡的特性不同,也有事因為在不同的分層里的設計思路不一樣。本文中,我們將整理Solana網絡的運行邏輯,可以通過這些資料了解到為什麼Solana會在以太坊2.0還沒上線的時候,會比以太坊好用。

以太坊的總帳本在1.0鏈上,是由礦工維護的,在2.0里,礦工變成驗證者,驗證者用計算設備建立驗證器代替了原來的礦機。Solana也是通過驗證者保護總帳本的,不過驗證者的在形成共識的算法不太一樣。通過下面的順序,可以了解到共識形成的過程。

Solana集群

Solana集群是一組驗證人,共同保持賬本的完整性,存在多個集群。

創建集群

在啟動任何驗證節點之前,首先需要創建一個創世配置。創世配置會配置一個具備引導驗證能力的節點,第二個驗證節點可聯系引導驗證節點來注冊為一個驗證節點。然后,其他驗證節點將在集群的任何已注冊成員中繼續注冊。

驗證節點會收到領導者的所有條目,并提交投票以確認這些條目的有效性。投票后,驗證節點需要存儲這些條目。不過一旦驗證節點發現存在足夠多的副本,它將刪除自身的副本。

加入集群

驗證節點通過發送到控制臺(control plane)的注冊消息進入集群。控制臺使用八卦(gossip)協議實現,這意味著節點可以向任何現有節點注冊,并期望其注冊傳播到集群中的所有節點。一個節點可以確保它最終擁有與每個其他節點相同的信息,但任何一個節點都無法審查該信息。所有節點同步所需的時間與參與群集節點數的平方成正比。

將交易發送到集群

客戶端將交易發送到任何驗證節點的交易處理單元(TPU)端口。如果該節點處于驗證節點角色,則它將交易轉發給指定的領導者。如果處于領導者角色,則該節點將傳入的事務捆綁在一起,對其打上時間戳,來創建一個條目(entry),然后將其推送到集群的數據中心(dataplane)。進入數據中心后,交易將由驗證節點進行驗證,從而將交易有效地添加到賬本中。

確認交易

Solana集群能夠在亞秒級的時間內確認(confirmation)最多150個節點,并要計劃擴展到成千上萬個節點。一旦完全實施,確認時間預計只會隨著驗證節點數量的對數而增加,而對數的基數又很高。網絡增長到一定規模后,就會變得太慢而無法實現亞秒級確認。將消息發送到所有節點所花費的時間與節點數的平方成正比。如果區塊鏈想要獲得低確認率并嘗試使用網絡來做到這一點,它將被迫集中到少數幾個節點上。

所以可以使用以下技術組合來實現可擴展的確認:

使用VDF樣本對交易打上時間戳并簽名。將交易分為幾批,將每筆交易發送到單獨的節點,同時每個節點都與對等節點共享其批次。遞歸地重復上一步,直到所有節點都具有所有批次。

Solana以固定的時間間隔(稱為插槽)輪換領導者。每個領導者只能在其分配的時段內產生條目。領導者因此對交易加上時間戳記,以便驗證節點可以查找指定領導者的公鑰。然后,領導者對時間戳進行簽名,以便驗證節點驗證簽名,證明簽名者是指定領導者公鑰的所有者。

接下來,將交易分成批處理,以便節點可以將交易發送給多方,而無需進行多份復制。例如,如果領導者需要將60筆交易發送到6個節點,則它將把60筆交易的集合分成10筆交易的批次,并向每個節點發送一個交易。這能夠讓領導者將60筆交易放在網絡上,而不是每個節點60筆交易。接著,每個節點都與對等節點共享其批次。一旦節點收集了全部6個批次,它將重建60個交易的原始集合。

這種技術可以被稱為(渦輪區塊傳播)Turbine Block Propogation。

同步

快速、可靠的同步是Solana實現超高吞吐量的最大原因。Solana采取了歷史證明PoH算法。通過帶有加密證明“時間戳”的領導節點證明自上次確認以來,確實已經過了一段時間。以證明所有哈希到證明中的數據肯定都是在證明之前發生的。然后該節點將新區塊分享給驗證節點,它們能夠驗證這些證據。

區塊可以按照任何順序甚至延遲好幾年才傳到驗證節點那里。通過這種可靠的同步保證,Solana能夠將區塊分解成更小的批量交易,稱為條目(entries)。在達成任何共識之前,條目都會實時傳輸給驗證節點。

在技術的角度,Solana從來都沒有發送區塊,但是會使用這個詞語來描述驗證節點對條目進行投票,最終取得確認。這樣,Solana的確認時間就可以達到800毫秒。在這個模式下,如果對某個事件無法達成共識,節點只需要簡單地回滾其狀態。

領導者輪換

每個驗證節點使用同一種算法來選擇預期的領導者。當驗證節點收到一個新的簽名賬本條目時,可以肯定某條目是來自預期的領導者。分配給每位領導者的插槽順序稱為leader schedule(領導者安排表)。

一個驗證節點會拒絕未經過插槽領導者簽名的區塊。所有插槽領導者的身份列表稱為領導者安排表。領導者安排表是通過本地定期重新計算產生的。它指派插槽領導者持續一段稱為epoch(紀元)的時間。安排表必須早于它分配的時間段,這樣它保證了計算計劃的賬本狀態最后能夠確定。該持續時間稱為領導者安排表偏移時間。Solana將偏移時間設置為直到下一個epoch的插槽持續時間。也就是說,一個epoch的領導者計劃通過上一個epoch開始時的賬本狀態來計算得到。一個紀元的偏移量是比較隨意的,并且假定時間足夠長,使所有驗證節點都將在生成下一個計劃之前確定其賬本狀態。集群可以選擇縮短偏移時間,來縮短質押變化與領導者計劃更新之間的時間。

在沒有分區的情況下運行時間比一個epoch長的時候,只有在根分叉的epoch邊界才能生成安排表。由于安排表用于下一個紀元,因此在下一個紀元之前,任何質押給根分叉的新質押都不會被激活。用于生成領導者計劃的區塊是跨過紀元邊界的第一個區塊。

如果分區比一個epoch時間短,集群將按以下方式運作:

驗證節點在投票時不斷更新自己的根分叉。

每次在紀元邊緣的插槽高度的時候,驗證節點將更新其領導者安排表。

寫在最后

正是因為對共識的改動,Solana出世的時候就以一個高性能公鏈的角色面對市場,其使用的類權益證明修改版PoH是在權益證明性能之上再次修訂的,目標就是性能更高,這樣做的目的也是即使以太坊2.0出現之后,網絡仍舊有競爭力。

不過這種共識體現的競爭力是在應用上,而不是在本身技術攻堅上。在某些信仰純粹的技術人員眼中,Solana可能有些過于中心化,只是在龐大的市場里,區塊鏈網絡面對不同受眾,會體現出不同的優劣,也能得到不同的發展。

發文者:鏈站長,轉載請註明出處:https://www.jmb-bio.com/4164.html

讚! (0)
Donate 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
Previous 2023 年 2 月 28 日 下午 6:12
Next 2023 年 2 月 28 日 下午 6:20

相關文章

  • EVM 存儲機制詳解:深入理解乙太坊技術與安全問題!

    前言 EVM 是一個輕量級的虛擬機,其設計初衷就是提供一種可以忽略硬件、操作系統等兼容性的虛擬的執行環境供以太坊網絡運行智能合約。 簡單來說 EVM 是一個完全獨立的沙盒,在 EVM 中運行的代碼是無法訪問網絡、文件系統和其他進程的,以此來避免錯誤的代碼能讓智能合約毀滅或者影響外部環境。 在此基礎上,知道創宇區塊鏈安全實驗室 帶大家一起深入理解 E…

    2023 年 2 月 28 日
  • 未來 Web 應用程式構建展望:探索新的技術方向!

    在未來,我們會怎樣構建 Web 應用程序呢? 如果行業正常發展下去的話,那麼今天我們認為很難、做起來很有價值的事情在明天都會變得很輕松普遍。我想我們會發現很多新的抽象,讓 Google Docs 寫起來也能像今天的普通 Web 應用一樣簡單。 這就引出來一個問題——這些抽象會是什麼樣子?我們今天能發現它們嗎?想要找出答案,一種方法是審視我們在構建 Web 應…

    區塊鏈技術 2023 年 2 月 28 日
  • 函數式程式設計技術解析:使用 Rust 和 Elixir 讀寫乙太坊智慧合約!

    本系列將重點介紹兩種函數式編程語言:Rust&Elixir。本篇分享函數式編程的思想和實踐。 在這篇文章中將展示Elixir&Rust讀取以太坊智能合約的功能。重要的是,該程序不僅在以太坊上工作,而且還在任何支持EVM的區塊鏈上工作,例如,Polkadot上的Moonbeam ! Ethereumex & ExABI 我更喜歡 Eli…

    2023 年 2 月 28 日
  • Vitalik Buterin:乙太坊的設計理念(一)

    盡管以太坊的許多理念在早先的密碼學貨幣(如比特幣)上已經運用并測試了5年之久,但從某些協議功能的處理方法上來說,以太坊與常見方式仍有許多不同。而且,以太坊可用于開發全新的經濟工具,因為它具有其他系統不具備的許多功能。本文會詳細描述以太坊所有的潛在優點,以及在構建以太坊協議過程中某些有爭議的地方。另外,也會指出我們的方案及替代方案的潛在風險。 原則 以太坊協議…

    2023 年 2 月 28 日
  • 不斷進擊的乙太坊:EIP-1559 之後的 EIP-3074

     Ropsten 測試網已于 6 月 24 日上線,區塊高度為 10,499,401。 ▪️ 自部署以來,約有 88,500 個測試網以太坊被燒毀,價值 1.776 億美元。 ▪️ 大約在 Eth3 啟動的同時,價值 2 億美元的 10 萬以太坊已經被存入 Eth3 的質押合約。 備受期待的以太坊改進提案 EIP-1559 最終…

    2023 年 2 月 28 日
每日鏈頭條給你最新幣圈相關資訊!