【07】區塊鏈性能

7-1 基礎性能優化

7-1-1 區塊鏈性能瓶頸

總述

區塊鏈性能指標

區塊鏈的性能指標主要包括:

吞吐量:在固定時間內處理的交易數量

延時:對交易的響應和處理時間

主流區塊鏈與中心化平臺TPS對比

區塊鏈與傳統計算的對比

區塊鏈可信且中立,通過賬本方式記錄資產的所有權、合約狀態或原始數據。

具體體現在

  • 可信且中立

區塊鏈沒有中心化的管理員或特殊的網絡權限,任何人都可以提交交易,無需擔心被操控或差別對待

  • 終端用戶進行驗證

任何用戶都可以審核區塊鏈賬本的歷史和當前狀態

  • 計算具有高的確定性

傳統方式的計算沒有確定性要求,而區塊鏈是按照預定義的代碼邏輯嚴格執行,具有確定性要求

正因如此,區塊鏈的性能與傳統計算存在較大差距。差距的來源根本在于區塊鏈節點的擴展性不足。

區塊鏈的鏈式結構限制了交易的執行必須滿足世界狀態的一致性和交易執行的順序性:

三階段的相互依賴阻礙了交易的執行效率,也造成了巨大資源的浪費,嚴重影響了商業場景下的響應時間。

利用機器多核或多機并行,可打破三階段的順序依賴,提升區塊鏈節點的可擴展性。

共識性能

回顧:區塊鏈的共識算法

區塊鏈的不可能三角

根據共識算法的特性,利用不可能三角進行分析:

區塊鏈的共識性能挑戰與嘗試

性能挑戰

POW:比特幣10分鐘出1個區塊,1筆交易確認的時延高達1小時

嘗試探索

POW+BFT算法解決性能問題(學術界)

POW算共識節點,BFT完成共識過程

存儲性能

存儲性能與成本挑戰

聯盟鏈的業務場景對交易吞吐量和響應時間有很高的要求:

存儲性能與成本主要面臨以下挑戰:

規模

性能

成本

易用性

Tips:在聯盟鏈的普及過程中,規模、成本、效率已成為應用場景關心的主要問題,降低區塊鏈存儲成本、提升區塊鏈存儲訪問性和易用性勢在必行。

網絡傳輸性能

網絡是區塊鏈系統正常運行的基礎設施,交易內容、數據的轉發,共識一致性都需要依賴節點間安全可靠的網絡傳輸能力和傳輸效率。

傳統的區塊鏈網絡架構是采用節點間直連的方式實現數據交互,這種網絡架構增加了帶寬成本,增大交易擴散和共識協議的耗時,導致交易吞吐量降低。

建設高性能區塊鏈網絡基礎設施,提升區塊鏈通信效率,突破區塊鏈應用規模瓶頸,提供可靠的網絡質量是區塊鏈網絡未來發展的重要方向。

傳輸性能對共識性能的影響

以PBFT共識算法為例,通信復雜度為O(n^2),節點規模翻倍,為保證相同的共識性能,帶寬需增加4倍。實際應用中,帶寬是有限的,節點規模的增加將增加共識消息的時延,制約了共識的性能。

傳輸性能對業務應用的影響

受公網通信時延及抖動的影響,業務應用會出現不穩定、服務質量差等問題,如何支撐大規模、穩定、高吞吐的商業服務是目前區塊鏈發展所面臨的挑戰。

交易執行性能

在比特幣體系中,在考慮TPS的影響因素時,基本不會考慮比特幣執行腳本的時間。因為比特幣的腳本是非狀態的(UTXO模型),且非圖靈完備,與10分鐘的出塊及網絡同步時間相比,腳本的執行時間很短。在考慮執行性能時,重點說關于智能合約的執行:

以太坊執行智能合約性能

以太坊是圖靈完備的,通過智能合約來執行交易,合約復雜程度可以較高。隨著交易量的增大,以太坊執行合約性能下降較快。

執行性能低的主要因素

  • 交易順序執行

以太坊的智能合約是由發送以太坊交易來驅動的,交易的順序會影響交易的結果,為保證系統的一致性,所有交易必須串行處理,交易需順序發送,節點也需次序處理。

  • 狀態的讀取(世界狀態)

以太坊使用世界狀態記錄以太坊狀態的變遷,隨著交易量的增大,每讀取一個特定的值產生訪問數據庫的次數會以log(n)的次數增加,執行合約的速度會越來越慢。

7-1-2 基礎性能優化

回顧:區塊鏈性能瓶頸

回顧:共識——執行——數據持久化,三段式的相互依賴阻礙了交易的執行效率,需進行區塊鏈擴容

優化策略:共識算法優化、交易并行執行、存儲優化

交易并行執行

什么是執行層?優化什么?

區塊鏈執行層:指執行交易和狀態變更。交易執行包括查看交易的有效性(如:驗證簽名和通證余額),執行鏈上邏輯并計算狀態變更;狀態變更指全節點更新賬本的副本,以反映新的轉賬、合約代碼更新及數據存儲。

區塊鏈交易執行優化:通常解決如何在每秒內,能夠處理更多的計算量(提升每秒處理的交易量TPS),同時無需大幅提升節點驗證交易的硬件要求。

交易執行優化主要方法:

分片與并行執行

螞蟻自研并行執行引擎

支付和狀態通道

Rollup

分片

分片擴容方法:將一條區塊鏈分成很多片,并行執行。每個分片都是一個區塊鏈,另外還存在一個主鏈,去保持所有分片同步。與多鏈生態不同的是,分片之間共享同一節點池,也會共享同樣的安全機制。

分片執行時的節點池:會分散到各個分片上去執行交易,節點會定期隨機輪轉,不會總執行或驗證同一分片上的交易。

分片并行執行

優勢:無需建立新的安全機制,因為共享同一節點池,所以每個執行環境可達到同樣的安全水平。

劣勢:

  1. 由于采用共享安全模式,所有分片都可能會出現同樣的安全漏洞;
  2. 主鏈計算需求越來越大,每個分片上分到的節點數量可能不夠,因此一條區塊鏈可以支持的分片數量會存在上限。
螞蟻自研并行執行引擎

并行共識+執行流水策略

可同時完成多批次的共識提議,而執行階段采用執行——狀態提交——數據持久化流水線模式

并行問題:對于并行處理的方式,區塊鏈交易之間可能存在讀寫數據的相關性會影響并行執行結果的一致性。

螞蟻鏈采用預執行的方式提前獲取交易讀寫集信息,并基于讀寫集信息完成交易分組,去保證并行處理的一致性。

支付和狀態通道

支付和狀態通道實現區塊鏈擴容:用戶將交易鎖定在多簽合約中,發起鏈下交換簽名的信息,消息加密,代表了資產所有權轉讓或狀態變更信息。整個過程無需發起任何鏈上交易。

優勢:低成本、低延遲,交易確認速度快

劣勢:適用于小額支付;對所有權確認不如傳統鏈上交易。

Rollup方法

優化區塊鏈的交易性能,一方面是直接對區塊鏈本身進行優化改造,提升鏈的處理效率;另一方面,是將交易和執行放到鏈下,區塊鏈僅僅做交易有效性驗證。

  • layer2擴容方案,通過鏈下對大量的數據進行處理,極大提高了區塊鏈的整體效率。
  • Rollup是layer2方案中經過多次優化和改進后,現在較為主流的技術方案。

Rollup的本質

將原本分布在區塊中的大量交易數據打包成一筆集合的交易,發布到鏈上。

Rollup方法原理

Rollup通過額外部署一條子鏈的方式,來實現對數據交易的處理和執行。這條子鏈可以和主鏈擁有不同的共識機制,也可以有不同的節點,有著極高的自主性。

Rollup可以理解為是一種側鏈的處理形式。因此它會生成區塊,并且將這些區塊的快照發送到主鏈上。

高性能共識算法

共識層優化不僅為提高速度,還要考慮提升準確性、穩定性及安全性。可考慮以下幾個方面進行優化:

提升執行和存儲能力

減少網絡帶寬使用

降低網絡延遲

設置經濟激勵

對于聯盟鏈來說,更加注重隱私、安全及執行效率,對節點規模要求不高,根據區塊鏈“不可能三角”,聯盟鏈根據節點的準入,賦予了節點更多的信任。聯盟鏈常用的共識算法主要傾向于拜占庭類共識(CFT)。

螞蟻鏈同樣也選擇了兼顧安全和性能的BFT類共識算法,自研了MyBFT和MyTumble共識。

MyBFT共識:

功能:與傳統的PBFT相比,MyBFT增加了共識窗口流水線功能,以及狀態持久化等功能,不僅可容忍不超過三分之一的拜占庭節點,還能容忍任意數量的誠實節點同時宕機后重啟。

適用環境:網絡環境穩定、高性能的場景

性能:可適配4-100共識節點的規模,共識TPS達10w筆/s

MyTumble共識:

功能及優勢:由螞蟻鏈自主研發的高吞吐、低延遲的純異步共識協議,相較于PBFT、Hotstuff等半同步共識協議,純異步共識協議在網絡情況不穩定時表現出更強的魯棒性。

適用場景:更適用于開放網絡和廣域網的部署。

螞蟻鏈的共識優勢:

  • 支持對共識參與方的增加、刪除,修改這里面的修改是指參與方共識身份的切換;
  • 支持對不同共識算法的切換,商業場景中可根據業務節點規模、交易規模等情況的調整實時切換,同時,螞蟻鏈采用服務化的系統架構,在未來共識算法的演進中,可以方便地集成新共識算法,而不涉及到系統結構的變化;
  • 支持共識參數的修改,如共識提議的交易數量、共識超時檢測的時間等,確保可根據交易規模、網絡環境實時調整;

存儲優化

存儲層指全節點維持和存儲賬本副本,區塊鏈的存儲功能通常分為兩類:

  • 歷史數據:包括所有原始交易和區塊數據。歷史數據通常無需快速訪問,只需要至少一個誠實節點就可以下載。
  • 全局狀態:全部數據的快照,智能合約可以對其進行讀寫,比如所有合約的賬戶余額及變量。

區塊鏈存儲層優化:通常解決如何讓區塊鏈既能處理并驗證更多數據,又不用提高對全節點的存儲要求。

數據分片技術

數據分片擴容方法:將賬本數據或重建賬本所使用的數據分成不同分片,降低對每個節點的存儲要求。

優勢:提升區塊鏈的存儲能力并降低存儲成本。

劣勢:區塊鏈承載的分片數量存在上限;數據分片會產生更高的通信成本,當節點輪轉到其他分片時需要相互交換存儲數據。

螞蟻鏈的存儲引擎

螞蟻鏈自研了存儲引擎Letus,Letus主要優勢如下:

1. 大規模&高性能優勢:

4個共識節點下,20億賬戶規模下,轉賬能達到10w,實測為20個worker支持20億賬戶規模,最高TPS為12.2w。

2. 極大地降低區塊鏈節點成本

  • Letus在區塊鏈數據的空間放大在1倍左右,狀態數據在2倍左右,相比于傳統MTP+RocksDB動輒幾十倍的放大而言有了質的提升。

  • 支持數據的冷熱劃分,可以將不常用并且時間相對久遠的區塊保存在低價冷介質中,但是可以支持低頻的訪問。
  • 可以通過裁剪算法后臺將不需要歷史版本的狀態數據刪除,不影響正常出塊的運行。

螞蟻鏈自研了存儲引擎Letus支持冷熱分層能力:

針對歷史區塊的低頻訪問特性,實現熱點區塊數據保存在高性能存儲介質中,滿足業務讀取以及節點數據同步的高頻需求,而歷史區塊存在在廉價介質中降低成本,同時提供可靠訪問能力。

7-2 區塊鏈擴容技術

7-2-1 區塊鏈擴容方案

擴容方案簡介

為什么要擴容

比特幣和以太坊作為區塊鏈1.0和2.0的代表,早期的比特幣區塊大小為1M,每秒大約只能處理7個交易,性能為7TPS。

以太坊每秒只能處理15個交易,性能為15TPS。

緩慢的交易處理速度會造成大量冗余,降低整體網絡性能。

擴容的主要目標是提升交易速度(更快確定交易)和交易吞吐量(提高每秒交易量),而不影響去中心化或安全性。

鏈下擴容

鏈下擴容(off-chain?scaling)也稱Layer2(簡稱L2)擴容,將區塊鏈上的部分運算任務放到鏈下(以太坊之外的第二層網絡)進行,并將計算結果傳回鏈上,從而實現區塊鏈運算能力的提升。

側鏈技術

以太坊側鏈是一個獨立的區塊鏈網絡,與以太坊主鏈并行運行。側鏈通過雙向掛鉤系統與主鏈連接,允許資產在側鏈之間進行交換。

側鏈有兩種基本類型,一種是相互依賴的,另一種是相互獨立的。

側鏈實現的技術基礎是雙向錨定(Two-wayPeg)

通過雙向錨定技術,可以實現將數字資產在主鏈中鎖定,同時將等價的數字資產在側鏈中釋放

將等價的數字資產在側鏈中被鎖定,同時將主鏈的數字資產釋放

雙向錨定實現的最大難點是協議改造需兼容現有主鏈,即不能對現有主鏈的工作造成影響

其具體實現方式可以分為以下幾類:

  • 單一托管模式

通過將數字資產發送到一個主鏈單一托管方,當單一托管方收到相關信息后,就在側鏈上激活相應數字資產。

本方案最大問題是過于中心化

  • 聯盟模式

是使用公證人聯盟來取代單一的保管方

利用公證人聯盟的多重簽名對側鏈數字資產流動進行確認

在這種模式中,如果要想盜竊主鏈上凍結的數字資產就需要突破更多的機構,但是側鏈安全仍然取決于公證人聯盟的誠實度。

  • SPV模式

SPV(Simplified Payment Verification)模式是最初的側鏈白皮書《Enabling Blockchain Innovations with Pegged Sidechains》中的去中心化雙向錨定技術最初設想。

SPV是一種用于證明交易存在的方法,通過少量數據就可以驗證某個特定區塊中交易是否存在。

主要原理:

  1. 用戶在主鏈上將數字資產發送到主鏈的一個特殊地址,鎖定主鏈的數字資產
  2. 創建一個SPV證明并發送到側鏈
  3. 一個對應的帶有SPV證明的交易會出現在側鏈上,同時驗證主鏈上的數字資產是否已經被鎖住
  4. 若已被鎖住,此時可以在側鏈上打開具有相同價值的另一種數字資產

SPV模式存在的問題是需要對主鏈進行軟分叉。

  • 驅動鏈模式

驅動鏈概念是由Bitcoin Hivemind創始人Paul Sztorc提出。

在驅動鏈中,礦工作為“算法代理監護人”,對側鏈當前的狀態進行檢測。

礦工本質上就是資金托管方,驅動鏈將被鎖定數字資產的監管權發放到數字資產礦工手上,并且允許礦工們投票何時解鎖數字資產和將解鎖的數字資產發送到何處。礦工觀察側鏈的狀態,當他們收到來自側鏈的要求時,他們會執行協調協議以確保他們對要求的真實性達成一致。

誠實的礦工在驅動鏈中的參與程度越高,整體系統安全性也就越大。

如同SPV側鏈一樣,驅動鏈也需要對主鏈進行軟分叉。

狀態通道

狀態通道是通過在不同用戶之間或用戶和服務之間建立一個雙向通道,為不同實體之間提供狀態維護服務。

允許把區塊鏈上的許多操作在鏈外進行管理,等完成鏈外操作后多方簽名確認后,才將最終結果上鏈。

舉例說明:

小明經常去自助餐廳吃飯,每次除了支付0.1eth餐費之外,還需要支付一筆小費給處理付款的服務員。

如果小明與餐廳有一個直接的支付通道,可以重復安全地轉移金額,小明就不需要服務員來協助處理付款,從而節省下小費的開支。

利用區塊鏈技術,可以設計如下:

創建一個支付通道智能合約,并存入100元(鏈上)

每次就餐時簽名一條交易信息給老板(鏈下)。交易信息包含:第幾次購買、共要支付多少錢、簽名信息。

餐廳隨時可以把簽名信息發送給鏈上支付通道智能合約,取回資金。

小明不想再去該餐廳就餐,可以取回支付通道的余額。

優點

  • 具有良好的隱私性

不管在狀態通道上發生了多少的瞬時交易,這些交易都是在通道內部發生的,并沒有廣播和記錄在鏈上,其他人不會知道,所以具有非常好的隱私性。

  • 即時終結性

只要狀態雙方都簽署了狀態更新,這個狀態就可以被認為是最終狀態,大家可以隨時退出。

  • 適合長時間多狀態更新

狀態通道特別適合那些需要長時間交換許多狀態更新的參與者,因為在部署合約的時候,創建的狀態通道有一個初始成本,而一旦部署完畢,狀態通道的邊際成本就接近于零。

缺點

  • 不適合低頻操作

每打開和關閉一個狀態通道都需要一個鏈上交易。打開狀態通道如果只給發1筆交易,還需要在鏈上做其他的兩筆交易,支付額外手續費。因此它不適合低頻操作。

  • 雙方隨時保持在線

由于挑戰期的存在,狀態通道的參與者需要一直在線,如果不在線,資產就可能損失掉,需要一直在線對于參與者來說確實是一件不友好的事情。

  • 確定的參與者

因為狀態通道的法官合約始終需要知道作為通道的一部分的實體(地址),當需要添加和刪除成員的時候,每次都需要更改合約,重新建一條通道,過程繁瑣。

Rollup

Rollup工作原理

Rollup方案的核心思想是將打包后的交易數據區塊發布在鏈上,從而降低交易有效性驗證的難度。

操作者收集不同參與者提交的一批鏈下交易,在鏈上執行Rollup智能合約提供的腳本,將打包后的交易數據區塊作為參數提交給合約。

實現鏈上一個交易完成鏈下一批交易。

Rollup兩種主流方案:

  • Optimistic Rollup

Optimistic Rollup假定所有交易從一開始就是有效的。為了確保這些交易的安全,Optimistic Rollup網絡提供了一個挑戰期(challenge period),網絡驗證者可以通過父鏈(比如以太坊)上一個欺詐證明(fraud proof)來質疑某筆交易的合法性。通過僅在懷疑存在欺詐時執行證明,Optimistic Rollup顯著提高了吞吐量并減少了延遲(交易確認時間)。挑戰期通常為7天。

  • ZK-Rollup

ZK-Rollup并不是假設所有交易在被證明有效之前是有效的,而是使用有效性證明(validity proofs)來立即驗證交易。

這些有效性證明和壓縮數據被提交至以太坊L1進行鏈上驗證。

有效性證明是非常復雜和耗時的,因此與Optimistic Rollup相比,ZK-Rollup存在較大延遲。

由于生成密碼證明(有效性證明)需要大量的計算,需要高規格的硬件,從而使得普通用戶難以參與。

Optimistic Rollup對比ZK-Rollup

特性Optimistic RollupZK-Rollup
每batch的固定gas消耗約40,000(輕量交易,主要只是改變狀態根的值)約500,000(驗證ZK-SNARK所需計算量較大)
提款期約一周極快(到下一個批次交易)
技術復雜度高(基于ZK-SNARK,數理復雜)
通用性易達成難達成(使用ZK-SNARK證明的通用EVM計算證明難度大)
每筆鏈上交易的gas消耗較高較低(僅發布引起狀態改變的數據,省略僅用作驗證的數據)
鏈下計算成本較低(需大量全節點計算)高(針對通用計算的ZK-SNARK證明比直接運行計算貴數千倍)

鏈上擴容

鏈上擴容(on-chain scaling)也稱layer1(簡稱L1)擴容,是指為了提高區塊鏈的吞吐量而對以太坊協議進行直接修改。

數據層擴容方案
SegWit(隔離見證)

被打包進區塊的交易數據包括數字簽名(scriptSig)和其他交易信息,數字簽名便占用了全部交易數據60-70%的空間,但是數字簽名僅僅在驗證階段需要。

隔離見證即隔離(segregate)數字簽名(witness)與其他交易數據,提升單個區塊所能容納的交易數量,通過“縮小”交易數據變相擴大了區塊大小,BTC采用了隔離見證的擴容方式。

舉例:客車容量不變的情況下,將乘客的行李全部放到車廂頂部,從而能運載更多的乘客。

擴塊

每一個區塊里面都承載著某一個時間段的數據。以比特幣為例,每個區塊包含著全球十分鐘內所有比特幣交易。當區塊大小設定為1MB時,最多只能包含2000多筆交易。

擴塊基本原理是提升單個區塊內的交易數,每秒打包的交易就會增加,從而提升TPS。

眾多擴塊方案中提及比較多的是2MB區塊擴塊方案,比特幣社區的另外一部分人希望硬分叉直接把區塊大小限制從1M改到2M

舉例:從普通公交車變成雙層公交車,提升了容量,載客量變大。

網絡層擴容方案
網絡層擴容理念及背景

在交易過程中,如果每筆交易都需要網絡中的每個節點進行確定,必然造成交易阻塞。分片即將網絡、交易、狀態進行分片,對節點由隨機序列分配成多個碎片,當網絡中接收到待確定的交易,系統隨機分配給各個碎片,這些碎片呈現獨立狀態,可以完成區塊鏈信息確立。

“分而治之”是分片技術的支撐性設計理念,相當于處理交易數據時,同時開通多個通道同步進行,而僅僅是對節點進行簡單隨機分配,還無法真正實現水平擴容,在運作過程中存在攻擊隱患,所以,需再進一步分片處理,包括網絡分片、交易分片以及交易狀態分片

網絡分片

網絡分片是指將區塊鏈分成不同部分,即多個分片,分片可以并行處理事務,從而提升了單位時間內處理交易的數量。假設網絡存在1000個節點,將網絡劃分成10個分片(每個分片100節點)。若1組分片能在一定時間內驗證400筆交易,那么10組分片便能在同樣時間內驗證4000筆交易。

舉例:超市里有100個收銀員,但只有1個收銀臺,分片后增加9個收銀臺,每個收銀臺分別有10個收銀員負責結賬。

交易分片

將交易按某種規則分配到不同的分片。其思路為,按一定的規則將交易分配到同一個分片處理,則既能夠達到并行處理的目的又能避免雙花問題的出現。

賬戶/余額模式

由于一筆交易只有一個輸入,因此只要將交易按照發送者地址進行分片,就可以保證同一個賬戶的多筆交易在同一個分片處理,有效防止雙花。

UTXO模型

一筆交易可能包括多個輸入和多個輸出,僅僅按照地址分片無法避免雙花問題,分片之間不得不進行通信,如果限制跨分片交易將限制平臺的可用性,而允許跨分片交易則不得不權衡跨分片通信的成本和性能提升帶來的收益。

狀態分片

狀態分片技術的關鍵是將整個存儲區分開,讓不同的碎片存儲不同的部分;

每個節點只負責托管自己的分片數據,而不是存儲完整的區塊鏈狀態。

面臨挑戰
  1. 跨分片交易通訊的效益平衡
  2. 分片動態刷新和節點狀態更新之間的平衡
  3. 全網數據備份與中心化風險之間的平衡
共識層擴容方案
非BFT類共識

通過降低共識算法復雜度和減少傳播節點數量等方式減少驗證時間、傳播時間及形成共識時間,能夠顯著提升處理效率。

PoS(Proof of Stack,權益證明)

相比于PoW(Proof of Work,工作量證明),PoS以權益(持有通證數量*通證持有時間)代替算力決定區塊記賬權,減少了PoW工作量證明過程的能源消耗,在一定程度上解決了可擴展性問題。但是又帶來了馬太效應、記賬激勵、無利害關系攻擊(Nothing-at-stake attack)等新的問題。

DPoS(Delegated Proof of Stack,委托權益證明)

DPoS在PoS的基礎上將記賬人的角色專業化,通證持有人通過權益選出多個授權代表(EOS有21個“超級節點”,Bitshares有101位代表,理論上單數節點均可),授權代表輪流記賬。這種共識下效率得到了明顯提升,但是犧牲了非中心化。

BFT類共識

不同于非BFT共識的間接達成共識(即參與者并非直接決定共識的具體內容),BFT類共識下,參與者通過投票決定共識內容直接達成共識,在參與者數量不是很多的情況下(一般BFT網絡直接參與共識的節點在100個以內),TPS可以達到10000。

非BFT類共識下存在分叉可能,以BTC為例,通常需要6個區塊才能以很高的概率確認某個交易被網絡確認,而在BFT共識下,達成一致的共識不會被丟棄,因此BFT的響應時間(交易從提出到被確認的時間)也明顯優于非BFT類共識。

BFT類共識的主要問題在于網絡規模、容錯率等方面。

混合共識

出現原因:任何單一的共識機制均有各自優勢及缺點。

方案:采取混合共識機制,指結合了多種不同的共識機制,結合各自的優點相互配合達到更好的實際效果

案例:

Casper采用PoW+PoS

EOS采用DPoS+BFT

7-2-2?區塊鏈擴容典型項目

閃電網絡

閃電網絡通過建立狀態通道的方式,將部分頻繁的小額交易放在鏈下完成,從而減輕主鏈的交易壓力。

閃電網絡技術的核心是建立一個安全、可行的鏈下支付通道,同時結合多重簽名地址技術、RSMC序列到期可撤銷合約、HTLC哈希時間鎖定合約等技術完成支付的結算與確認,進而提高用戶支付的效率。

舉例說明

支付通道創建

創建一個序列到期可撤銷合約(RSMC),Alice和Bob是合作方,經常有比特幣往來,所以他們決定各自拿出0.5BTC放入通道中,便于業務往來。

交易更新
  • Alice轉賬0.1BTC給Bob

核心技術
多重簽名地址

原因:比特幣多重簽名地址是為了實現比特幣資產的多方管理的一種技術。最初版本的比特幣簽名機制是單一地址管理的,即地址的持有人單獨管理,只有本人擁有私鑰。如果持有者丟失了私鑰,將直接失去該筆鏈上資產。

方案:為了規避丟失私鑰而丟幣的風險,提出了多重簽名的技術解決方案。即N個用戶分別持有N個私鑰,只要其中M個用戶拿出私鑰就可以動用某個多重簽名地址里的比特幣。這里的M需大于等于2,小于等于N。

RSMC合約

RSMC(Recoverable Sequence Maturity Contract)即“序列到期可撤銷合約”。

假定交易雙方之間存在一個“微支付通道”(資金池)。交易雙方預先存一部分資金到“微支付通道”里,初始情況下雙方的分配方案等于預存的金額。每次交易發生,雙方需對交易后產生資金分配結果共同進行確認,同時簽字作廢舊版本分配方案。任何一方需要提現時,將雙方簽署過的交易結果寫到區塊鏈網絡中,從而被確認。只有在提現時才需要通過區塊鏈。

任何一個版本的方案都需要經過雙方的簽名認證才合法。任何一方在任何時候都可以提出提現。提現時需要提供一個雙方都簽名過的資金分配方案(意味著肯定是某次交易后的結果,被雙方確認過,但未必是最新的結果)。在一定時間內,如果另外一方拿出證明表明這是一個作廢方案(非最新的交易結果),則資金罰沒給質疑方;否則按照提出方的結果進行分配。欺詐驗證消除了任何一方拿舊的交易結果用以提現的風險。

對于雙方確認的某次提現,首先提出一方的資金到賬時間要晚于對方。此設計鼓勵參與者在鏈外完成交易。

通過RSMC,可以實現大量中間交易發生在鏈外。

HTLC合約

Hashed Timelock Contract,哈希時間鎖合約,主要過程如下:

HTLC合約主要由2部分構成:

哈希值鎖定:確保僅獲取到最終接收方生成的密碼方可解鎖,并獲得凍結的資產;

時間鎖定:

確保轉賬方在一定時間內(最終接收方解鎖取走比特幣前)無法取走凍結款項

確保在一段時間后如果最終接收方沒有提現,轉賬方可以取回凍結款項

Plasma

Plasma鏈是一個樹狀區塊鏈結構,用以太坊為例:

以太坊是樹根,稱之為根鏈;

以太坊Plasma鏈是樹干,并有父鏈及子鏈兩種形式:

  • 樹干Plasma鏈可以衍伸出樹枝Plasma鏈
  • 父鏈(Parent Chain)與子鏈(Child chain)是相對的
  • 樹干Plasma鏈是樹枝Plasma鏈的父鏈
  • 樹干Plasma鏈同時是以太坊的子鏈

優點
  • 規模化

具備高可擴展性

根鏈最大延伸一百個Plasma鏈

每個Plasma鏈可延伸一百個Plasma子鏈

以太坊網絡吞吐量增加一萬倍

  • 信任最小化

子鏈定時而非實時上傳區塊哈希至父鏈

父鏈缺省認定子鏈交易無問題

父鏈僅在子鏈主動提出審查請求方介入

子鏈關系人需主動檢查自己的資產,對普通使用者體驗不佳

  • 全新的應用開發方式

每條Plasma鏈均可由去中心化應用開發商或其他項目方開發與維護

項目方可以自行制定該Plasma鏈上應用規范,增加開發靈活性

工作流程
進場機制

將資產從以太坊轉移到Plasma鏈需將資產轉入以太坊相應Plasma智能合約,即可獲得相應的token,用于在該Plasma鏈上進行交易。

退場機制

申請退出Plasma需要接受七天的挑戰期

挑戰期內,挑戰者可向父鏈智能合約提出欺詐證明

欺詐證實,則意味著挑戰者挑戰成功。該退出請求會被取消且挑戰者獲得一筆獎勵。

退出申請在父鏈受理有優先順序。優先度由申請退出時間距離上一筆交易時長決定,時長越長優先度越高。用以防止作弊者采取作弊行為后迅速退出Plasma鏈。

系統角色
用戶(client)

參與Plasma系統的普通用戶,期望通過Plasma子鏈完成高效低成本轉賬

子鏈礦工(operator)

Plasma系統的維護者,負責將子鏈區塊信息打包到主鏈

主鏈智能合約

負責保存子鏈少量數據,驗證子鏈操作的正確性合理性。

局限
難以擁有完整的EVM

存在大量復雜的技術性問題:如智能合約的所有權性質,導致Plasma短期內難以完整實現EVM所具備的功能。如果子鏈上的“狀態”出現混亂,缺乏EVM能力難以復原。

目前大多數研究聚焦于Plasma鏈實現UTXO模型

大規模退出風險

大規模退出會導致以太坊需要在短時間內處理大量交易,導致驗證時間拉長及gas費劇增問題并帶來用戶資金風險。

目前尚無完美的解決方案。

Rollup

工作原理

Rollup方案的核心思想是將打包后的交易數據區塊發布在鏈上,從而降低交易有效性驗證的難度。

操作者收集不同參與者提交的一批鏈下交易,在鏈上執行Rollup智能合約提供的腳本,將打包后的交易數據區塊作為參數提交給合約。實現鏈上一個交易完成鏈下一批交易。

Rollup有多種方案,具體實現不同,均需要解決三個共性的問題:

  1. 如何實現交易壓縮
  2. 如何將二層的狀態轉換同步到一層
  3. 如何保證二層運營者真實提交了二層的全部狀態轉換
如何實現交易壓縮

Rollup壓縮主要是對交易消耗gas數的壓縮,兼顧交易字節數壓縮。

以太坊上的區塊限制以gas為限制,非字節數限制

小的字節數不等同于小的gas消耗

Rollup方案通過壓縮減少交易執行的計算量降低gas消耗

Rollup方案針對交易字節數的壓縮的方式主要包括:

  • 效率更高的編碼方式
  • 縮減交易占用字節數
  • 減少需要上傳的數據

交易發生在以太坊一層與Rollup方案對比:

將二層的狀態轉換同步到一層

批次交易發生前后的狀態轉移示意如下圖所示:

二層交易相關賬戶狀態改變,引起葉子節點信息變動,導致根哈希值的變動

二層運營者在本地維護二層賬戶狀態樹,記錄并上傳批次交易發生前后的根哈希值

防止二層運營者欺詐
Optimistic Rollup

Optimistic Rollup方案承襲閃電網絡及Plasma采用的欺詐證明方式,主要步驟:

  • 運營者提交信息時不做關于狀態轉換合法性的校驗,為交易的提交預留挑戰期。
  • 挑戰期內,無人對其合法性做出挑戰則交易被確認。
  • 挑戰期內,有人對其合法性做出挑戰,則挑戰者需提供欺詐證明。

Optimistic Rollup相對閃電網絡及Plasma方案在欺詐證明方式的改進:

  • 欺詐證明方式的主要缺點是用戶體驗差和資金效率低
  • 閃電網絡及Plasma方案無法保證鏈上數據有效性:
    • 必須依靠用戶活性(一定的在線頻率)來防止欺詐
    • 用戶資金無法及時取出,必須等待挑戰期結束
  • Optimistic Rollup方案保證數據上鏈,欺詐證明可由第三方提交,有效降低對用戶活性的要求
  • Optimistic Rollup方案對資金效率進行如下提升:
    • 對于非欺詐的交易,交易的最終性可提前預期
    • 使用者可自行搭建驗證節點快速驗證交易合法性而不必等到挑戰期結束
    • 交易需等待挑戰期結束后方能被主鏈確認,但最終性可以被快速確認的特性,流動性提供商可以提前為用戶釋放資金
    • 此提升需依賴應用解決方案
ZK Rollup

ZK Rollup采用二層運營者提供有效性證明方式防止欺詐,特點包括:

二層運營者提供有效性證明:即二層運營者需直接證明其提交的狀態轉換正確有效

提交即正確,無挑戰期設置,無欺詐風險,提取資金無凍結期

相比于欺詐證明,此方式技術挑戰性更大。目前僅針對一些特定的操作生成證明,無法通用

隨著密碼學技術理論和實踐的突破(PLONK、多項式承諾等),向通用解決方案方向演進

方案對比
Optimistic RollupZK Rollup
  • 解決方案為欺詐證明(fraud proofs)
  • 追蹤所有歷史狀態根以及每個批次交易提交的哈希值
  • 任何人發現某個batch的后狀態根不正確,均可以向區塊鏈發布一個證明,證明該批次交易計算錯誤。合約會對證明進行驗證,并且對該batch及其之后的批次交易進行回滾
  • 解決方案為有效性證明(validity Proofs)
  • 每個批次交易都包含ZK-SNARK的密碼學證明(例如使用PLONK協議)
  • 可有效證明后狀態根是正確執行批次交易的結果
  • 計算量大但證明能在鏈上得到極速驗證
Layer2技術演進

Rollup方案演進之路
側鏈閃電網絡PlasmaRollup
基于信任基于信任不基于信任不基于信任
無需向主鏈同步狀態需向主鏈同步狀態需向主鏈同步狀態需向主鏈同步狀態
交易發送給運營商交易發送給對手方交易發送給運營商交易發送給運營商
運營商存儲交易用戶自行存儲交易運營商存儲交易,用戶存儲部分數據運營商存儲交易
交易存儲在側鏈交易存儲在鏈下交易存儲在鏈下交易存儲在鏈上和鏈下

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/news/896113.shtml
繁體地址,請注明出處:http://hk.pswp.cn/news/896113.shtml
英文地址,請注明出處:http://en.pswp.cn/news/896113.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

安全面試2

文章目錄 簡單描述一下什么是水平越權,什么是垂直越權,我要發現這兩類漏洞,那我代碼審計要注意什么地方水平越權:垂直越權:水平越權漏洞的審計重點垂直越權漏洞的審計重點 解釋一下ssrf漏洞原理攻擊場景修復方法 橫向移…

【Linux 專欄】echo命令實驗

風123456789~-CSDN博客 最近文章閱讀排行榜 【爬蟲基礎】第一部分 網絡通訊 P1/3-CSDN博客 【爬蟲基礎】第一部分 網絡通訊-Socket套接字 P2/3-CSDN博客 【Linux專欄】find命令同步 實驗-CSDN博客 【Linux運維】非root用戶的單向免密登錄_linux 單向免密-CSDN博客…

RTSP協議全解析

RTSP(Real Time Streaming Protocol)協議全解析 一、協議概述 定位:應用層協議,用于控制流媒體服務器(播放、暫停、錄制),媒體傳輸由 RTP/RTCP 實現。 特點: 基于文本(…

第15屆 藍橋杯 C++編程青少組中/高級選拔賽 202401 真題答案及解析

第 1 題 【 單選題 】 表達式117 % 16 的結果是( )。 A:0 B:5 C:7 D:10 解析: % 是取模運算符,用于計算兩個數相除后的余數。 計算 117 / 16,結果是 7,余數是 5。因此,117 % 16 = 5。答案: B 第 2 題 【 單選題 】 下列選項中,字符數組定義正確的是( …

qt5實現表盤的旋轉效果,通過提升QLabel類

因為工作需要,需要實現溫度的表盤展示效果 實現思路: 通過提示聲QLabel控價類,實現報盤的旋轉和展示效果 1. 編寫一個QLabel的類MyQLabel,實現兩個方法 1. void paintEvent(QPaintEvent *event); //重繪函數 2. void valueChanged(int va…

通信系統中物理層與網絡層聯系與區別

在通信系統中,物理層和網絡層是OSI(開放系統互連)模型中的兩個重要層次,分別位于協議棧的最底層和第三層。它們在功能、職責和實現方式上有顯著的區別,但同時也在某些方面存在聯系。以下是物理層與網絡層的聯系與區別的…

【深度學習】Pytorch的深入理解和研究

一、Pytorch核心理解 PyTorch 是一個靈活且強大的深度學習框架,廣泛應用于研究和工業領域。要深入理解和研究 PyTorch,需要從其核心概念、底層機制以及高級功能入手。以下是對 PyTorch 的深入理解與研究的詳細說明。 1. 概念 動態計算圖(D…

23種設計模式 - 解釋器模式

模式定義 解釋器模式(Interpreter Pattern)是一種行為型設計模式,用于為特定語言(如數控系統的G代碼)定義文法規則,并構建解釋器來解析和執行該語言的語句。它通過將語法規則分解為多個類,實現…

使用 Openpyxl 操作 Excel 文件詳解

文章目錄 安裝安裝Python3安裝 openpyxl 基礎操作1. 引入2. 創建工作簿和工作表3. 寫入數據4. 保存工作簿5. 加載已存在的Excel6. 讀取單元格的值7. 選擇工作表 樣式和格式化1. 引入2. 設置字體3. 設置邊框4. 填充5. 設置數字格式6. 數據驗證7. 公式操作 性能優化1. read_only/…

nigix面試常見問題(2025)

一、Nginx基礎概念 1. 什么是Nginx? Nginx是一款高性能的HTTP/反向代理服務器及IMAP/POP3/SMTP代理服務器,由俄羅斯工程師Igor Sysoev開發。其核心優勢在于事件驅動架構與異步非阻塞處理模型,能夠高效處理高并發請求(如C10K問題),廣泛應用于負載均衡、靜態資源服務、AP…

002 SpringCloudAlibaba整合 - Feign遠程調用、Loadbalancer負載均衡

前文地址: 001 SpringCloudAlibaba整合 - Nacos注冊配置中心、Sentinel流控、Zipkin鏈路追蹤、Admin監控 文章目錄 8.Feign遠程調用、loadbalancer負載均衡整合1.OpenFeign整合1.引入依賴2.啟動類添加EnableFeignClients注解3.yml配置4.日志配置5.遠程調用測試6.服務…

代碼審計入門學習之sql注入

路由規則 入口文件&#xff1a;index.php <?php // ---------------------------------------------------------------------- // | wuzhicms [ 五指互聯網站內容管理系統 ] // | Copyright (c) 2014-2015 http://www.wuzhicms.com All rights reserved. // | Licensed …

React實現自定義圖表(線狀+柱狀)

要使用 React 繪制一個結合線狀圖和柱狀圖的圖表&#xff0c;你可以使用 react-chartjs-2 庫&#xff0c;它是基于 Chart.js 的 React 封裝。以下是一個示例代碼&#xff0c;展示如何實現這個需求&#xff1a; 1. 安裝依賴 首先&#xff0c;你需要安裝 react-chartjs-2 和 ch…

線程與進程的深入解析及 Linux 線程編程

在操作系統中&#xff0c;進程和線程是進行并發執行的兩種基本單位。理解它們的區別和各自的特點&#xff0c;能夠幫助開發者更好地進行多任務編程&#xff0c;提高程序的并發性能。本文將探討進程和線程的基礎概念&#xff0c;及其在 Linux 系統中的實現方式&#xff0c;并介紹…

全面指南:使用JMeter進行性能壓測與性能優化(中間件壓測、數據庫壓測、分布式集群壓測、調優)

目錄 一、性能測試的指標 1、并發量 2、響應時間 3、錯誤率 4、吞吐量 5、資源使用率 二、壓測全流程 三、其他注意點 1、并發和吞吐量的關系 2、并發和線程的關系 四、調優及分布式集群壓測&#xff08;待仔細學習&#xff09; 1.線程數量超過單機承載能力時的解決…

springboot整合mybatis-plus【詳細版】

目錄 一&#xff0c;簡介 1. 什么是mybatis-plus2.mybatis-plus特點 二&#xff0c;搭建基本環境 1. 導入基本依賴&#xff1a;2. 編寫配置文件3. 創建實體類4. 編寫controller層5. 編寫service接口6. 編寫service層7. 編寫mapper層 三&#xff0c;基本知識介紹 1. 基本注解 T…

HTTP 常見狀態碼技術解析(應用層)

引言 HTTP 狀態碼是服務器對客戶端請求的標準化響應標識&#xff0c;屬于應用層協議的核心機制。其采用三位數字編碼&#xff0c;首位數字定義狀態類別&#xff0c;后兩位細化具體場景。 狀態碼不僅是服務端行為的聲明&#xff0c;更是客戶端處理響應的關鍵依據。本文將從協議規…

Unity中的鍵位KeyCode

目錄 主要用途 檢測按鍵事件&#xff1a; 處理鍵盤輸入&#xff1a; 基本鍵位 常用鍵&#xff1a; 字母鍵&#xff1a; 數字鍵&#xff1a; 功能鍵&#xff1a; 方向鍵&#xff1a; 控制鍵&#xff1a; 鼠標鍵&#xff1a; 其他特殊鍵&#xff1a; 代碼示例 按下…

高考或者單招考試需要考物理這科目

問題&#xff1a;幫忙搜索一下以上學校哪些高考或者單招考試需要考物理這科目的 回答&#xff1a; 根據目前獲取的資料&#xff0c;明確提及高考或單招考試需考物理的學校為湖南工業職業技術學院&#xff0c;在部分專業單招時要求選考物理&#xff1b;其他學校暫未發現明確提…

【設計模式】 代理模式(靜態代理、動態代理{JDK動態代理、JDK動態代理與CGLIB動態代理的區別})

代理模式 代理模式是一種結構型設計模式&#xff0c;它提供了一種替代訪問的方法&#xff0c;即通過代理對象來間接訪問目標對象。代理模式可以在不改變原始類代碼的情況下&#xff0c;增加額外的功能&#xff0c;如權限控制、日志記錄等。 靜態代理 靜態代理是指創建的或特…