一文看懂迅雷鏈技術棧和架構設計思路

隨著區塊鏈 3.0的技術革新，在保證區塊鏈本身公開、透明、防篡改特性的基礎上，還需要能夠支持商業級別應用的高性能底層平台。迅雷鏈就是這樣的一個底層平台，企業和個人開發者可以按需上鏈，打造可大規模使用的區塊鏈應用。

在迅雷建立的「區塊鏈 +共享計算」的模式中，迅雷通過多年積累的無限節點調度和使用等創新技術，將用戶的閑置存儲、計算、帶寬等資源轉化為雲計算服務，輸送給需要這些資源的企業客戶，而區塊鏈技術在其中幫助量化用戶的貢獻，激勵用戶儘早加入共享計算的建設。

據了解，迅雷目前已經有 150多萬個共享計算節點，而且還在快速增加，不斷擴大的用戶規模也對迅雷區塊鏈技術提出了挑戰，為了應對這一難題，迅雷鏈提出同構多鏈框架，每秒處理的並發請求量可達百萬，使得迅雷鏈具備了可以作為區塊鏈 3.0時代主鏈的條件。下面來看看迅雷鏈系統架構和同構多連框架的設計思路。

1

迅雷鏈的技術棧與重點模塊介紹

下圖為迅雷區塊鏈的技術棧，可以直觀的看出各模塊的分工和協作。

最上層的應用層，是 C端用戶直接接觸到產品和服務，包括賬戶客戶端、第三方客戶端和合約應用。

其中，合約應用是指基於迅雷鏈開發的 DAPP。應用中使用的合約通過服務層的「合約部署」服務部署到區塊鏈上。DAPP中的合約調用通過服務層的「合約調用」模塊進行校驗，合法的才會轉到鏈上處理。

中間的服務層作為應用和鏈之間的橋樑，提供應用層需要的介面和服務。包括安全控制、合約部署、合約請求和數據請求服務。

其中，合約部署的觸發主要是迅雷鏈內部的審核系統觸發，只有企業資質審核通過並且產品內容合法合規，才會被部署到迅雷鏈上。同時，迅雷鏈是同構多鏈框架（下文會詳細介紹），合約會有自己所屬的鏈，並在該鏈上完成合約創建。而普通鏈上的用戶發起合約調用時，用戶所在鏈請求入塊後，需要知道將該請求和區塊路由到哪個鏈上，所以合約部署時還需將合約的路由信息通知到所有鏈。

而數據請求服務模塊，包含鏈克相關的所有請求，包括查詢餘額、查詢兌換記錄、執行兌換等。對於餘額、兌換記錄這類請求量很大的模塊，會在所有接入節點上做緩存，每個節點通過基礎層的「訂閱及通知服務」訂閱區塊信息。當收到區塊產生的通知後，可以立即解析區塊內信息，並修改緩存中的餘額和兌換記錄。對於執行兌換的請求先校驗合法性，再將合法請求轉到基礎層。

最底層也叫基礎層，是構成迅雷鏈最核心的組成部分，由 11個模塊組成。

其中，共識模塊包括共識演算法和校驗。這是區塊鏈與分散式存儲服務共同的核心模塊，區塊鏈的共識比普通的分散式存儲服務多了一些安全上的校驗，比如日誌。所有參與共識的節點需要對區塊校驗其內部數據的合法性。至於如何達成共識就跟共識演算法有關了，迅雷鏈採用的共識演算法是 pbft，具體演算法的原理和選擇理由下一次分享會繼續介紹。

智能合約模塊：迅雷鏈上有越來越多的應用在接入，這些應用的業務邏輯代碼其實就是智能合約。而智能合約代碼是獨立於區塊鏈程序的，所以需要在區塊鏈程序中運行虛擬機來解釋和執行。再者，智能合約裡面需要讀取和修改區塊鏈上的數據，所以虛擬機還要提供方法來與區塊鏈交互。

數據存儲部分：包括區塊、原始請求和用戶數據。相比於以比特幣為代表的 UTXO模型，迅雷鏈選擇了基於賬戶模型，方便支持智能合約。迅雷鏈的本地存儲系統選擇的是 leveldb，在數據存儲的結構上借鑒了以太坊的精髓，包括交易樹、賬戶樹、事件樹。每種樹都是一個 merkletree，在區塊頭部只存儲樹的 root的 hash。

密碼學模塊：包括簽名和加密。這也是區塊鏈非常核心和獨特的模塊，區塊鏈的不可篡改、隱私保護等特點都是源於此，涉及簽名、摘要計算、公私鑰對的生成等。

網路通信模塊：包括 P2P和 RPC。區塊鏈中所有參與的記賬節點都是對等的，記賬節點之間包括請求、區塊等信息都需要網路送達，當然要做一個健壯的區塊鏈網路，在網路通信模塊還需要不斷優化。

通用模塊：包括壓縮和事件機制。因為賬戶模型里要存儲的數據信息相對較多，而且隨著時間推移，鏈的長度也越來越大，所以數據落盤前需要壓縮。事件機制主要是為外圍系統提供鏈上執行合約、鏈上區塊產生等底層支持。

2

案例：上鏈請求的執行過程

以用戶在客戶端應用中發起鏈克兌換為例。

鏈克口袋將請求發到鏈的服務層——從架構角度看的最外層就是接入層；

接入層會根據 from（發起方）地址將請求路由到對應鏈的鏈，接入層也會判斷請求的合法性，針對非法的請求直接返回失敗；

外層驗證 ok後，會進入服務層——從架構角度看的內層，會驗證請求是否為重放、餘額是否不足等；

服務層驗證通過的請求到達基礎層——從架構角度看就是我們的記賬節點，也叫驗證人；

記賬節點之間轉發請求，記賬節點中本輪的 proposer負責發起區塊，區塊數據在幾個記賬節點之間也相互轉發，收到區塊的節點進行投票，並把投票信息廣播，根據我們的 pbft共識演算法記賬節點達成共識，區塊入鏈；

新區塊產生後，記賬節點中鏈間通信的模塊會針對新區塊中涉及跨鏈的請求，依次根據請求的目的鏈，將跟該目的鏈有關的請求原始數據、本鏈的區塊頭信息、本鏈的交易證明信息等轉發給目的鏈的記賬節點；

目的鏈的記賬節點將收到的信息轉發，並達成共識，將請求寫入目的鏈區塊的同時也完成了目的鏈對應地址的餘額增加。

3

同構多鏈框架的設計思路

所謂同構多鏈框架，顧名思義就是有多條鏈，每條鏈上都運行相同的程序。不同用戶的請求會發到不同的鏈上進行處理。

當 A、B、C、D同時發起請求，比如有 A->B，A->C，A->D , 同時有 B->C, C->D，D->E。A、B、C、D根據路由規則落到不同的鏈上，四條鏈可以並行進行處理，如果一條鏈每秒的打包請求並落區塊的速度是 1000，那麼上千條鏈，就可以達到百萬 TPS。

對於普通請求，消耗的鏈克 gas是固定的，這種鏈間的處理是相對容易的，而支持智能合約，需要一些額外的處理。因為要防止惡意的合約或者合約本身的 bug導致佔用大量資源，所以需要根據合約執行情況扣除相應的鏈克 gas。

消耗的鏈克 gas是需要從請求發起方的賬戶里扣除的，而真正執行合約的是在合約所在的另一條鏈，所以最終需要的具體數量，在發起請求方所在鏈入鏈這筆請求的時候尚未可知，這怎麼辦呢？

解決辦法是在發起方所在鏈扣除請求中傳入的 gasLimit值，也就是用戶指定的上限值，這個請求入塊後同步到合約所在鏈，合約執行後請求入塊能知道這筆請求真正扣掉的通證數量，再通過鏈間通信將鏈裡面入塊的合約調用請求同步到發起方所在鏈，發起方確認合約鏈的區塊數據，並把多扣掉的通證退回給發起方。這些對賬戶餘額的操作在鏈上都有相應的操作記錄寫入，方便對賬。

前文介紹了整體吞吐的提升主要通過增加新鏈的方式，那怎麼能做到輕量地增加新鏈呢？

迅雷鏈的路由規則選擇的是最簡單直接的針對地址取模，比如針對 1024取模，因為地址是根據公鑰經過 hash運算出來的，整體隨機分布，所以基本上所有用戶會平均分布到這些鏈上。

以當前有 1024條鏈舉例，其編號從 0到 1023，地址取模結果是 1、1025、2049、3073、……會落到 1號鏈。 那麼當我們想擴容到 2048條鏈的時候，實際上是原來每條鏈上的一半用戶遷移到新鏈。新鏈啟動時區塊數據來自原來的鏈，比如 1025號鏈的數據來自原來的 1 號鏈，原來在 1號鏈上地址取模為 1025、3073、……的用戶數據之後會都落在 1025這條鏈；而原來在 1號鏈上地址取模為 1、2049、……的用戶數據之後還在 1號這條鏈上。

通過這樣的方式，可以讓擴鏈的整體變動最小化。

4

結語

介紹了這麼多，大家對迅雷鏈的整體設計已經了解，那麼下一步可以基於迅雷鏈來搭建自己的應用啦。

同時，極客邦科技聯合迅雷舉辦了「迅雷全球區塊鏈應用大賽」！

本次大賽由大賽由迅雷集團與極客邦科技共同主辦，由中國通信工業協會區塊鏈專委會作為指導單位，36kr、旗點諮詢、品玩、DoraHacks 等機構單位作為大賽協辦支持單位。大賽立足全國，放眼世界，並設置百萬獎金，致力於尋找國內外區塊鏈領域具備創新能力的優秀人才以及項目。

大賽面向高校組織、研究機構、企業團隊等以 3-5人團隊為單位進行招募，同時也為個人開發者提供組隊平台。大賽不限開發平台、不限技術背景。賽題涉及區塊鏈 +公益、醫療、教育、遊戲、社交、交通出行、商品鑒偽、版權等領域。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！