「沒有對手?我有話說!」Gate廣場挑戰賽——秀操作贏$2,000,百萬流量加持!
你是下一個明星交易員嗎?
想讓自己的名字閃耀廣場熱搜?想吸引數萬追隨者?百萬流量已就位,就等你來承接!
🎉 雙重豪禮,贏家通喫!
1️⃣ 曬單排行榜獎勵
收益率排名前10的用戶,瓜分 $1,500合約體驗券!巔峯對決等你來戰!
2️⃣ 曬單幸運獎
隨機抽取10位用戶,每人贈送 $50跟單包賠券!即使不是大神,也有機會躺贏!
🎮 參與方式超簡單!
✅ 在 Gate廣場 曬出你的交易戰績,並成爲帶單員!
✨ 發帖要求:
內容必須原創,並帶上 #CopyTrading# 或 #跟单# 標籤
附上 收益率截圖 或 交易卡片,並分享你的 獨家交易心得
嚴禁AI生成虛假交易,一經發現取消資格
觀點犀利、邏輯清晰,乾貨越多越吸粉!
⏰ 活動截止:8月15日 10:00(UTC+8)
【立即發帖】 展現你的王者操作,承接百萬流量,成爲下一個交易傳奇!
💬 還在等什麼?Gate廣場,等你來戰! 💪
鏈下擴容方案詳解:從State Channels到Layer2解決方案
鏈下擴容深度解析
1. 擴容的必要性
區塊鏈的未來願景是實現去中心化、安全性和可擴展性。但通常只能實現其中兩個,這被稱爲區塊鏈的不可能三角問題。多年來,人們一直在探索如何在保證去中心化和安全性的前提下,提高區塊鏈的吞吐量和交易速度,即解決擴容問題。
區塊鏈的去中心化、安全性和可擴展性定義如下:
去中心化:任何人都可以成爲節點參與區塊鏈系統的生產和驗證,節點數量越多,去中心化程度越高。
安全性:爲了獲取區塊鏈系統控制權所付出的成本越高,則安全性越高,鏈就可以抵抗較大比例的參與者攻擊。
可擴展性:區塊鏈處理大量交易的能力。
比特幣網路的第一次重大硬分叉就是源於擴容問題。隨着用戶數量和交易量增多,每個區塊上限爲1MB的比特幣網路開始面臨擁堵。2015年開始,比特幣社區就擴容問題存在分歧,一方支持擴大區塊,另一方認爲應使用隔離見證Segwit方案優化主鏈結構。2017年8月1日,支持擴大區塊的一方自行開發至8MB的客戶端系統開始運行,導致比特幣歷史上第一次重大硬分叉,同時誕生了新幣種BCH。
以太坊網路也選擇犧牲了一部分可擴展性,來保障網路的安全性和去中心化。雖然以太坊未像比特幣通過限制區塊大小來限定交易量,而是變相對單一區塊可容納的燃料費設置上限,但目的都是爲了實現Trustless Consensus並確保節點的廣泛分布。
從2017年的CryptoKitties,DeFi summer、再到後來GameFi和NFT等鏈上應用興起,市場對吞吐量需求不斷增加,但即使是圖靈完備的以太坊每秒也只能處理15~45筆交易(TPS)。這導致交易成本不斷增加,結算時間變長,大部分Dapps難以承受運行成本,整個網路對用戶而言變得又慢又貴,區塊鏈擴容問題亟待解決。理想的擴容方案是:在不犧牲去中心化和安全性的前提下,還能盡可能提高區塊鏈網路的交易速度和吞吐量。
2. 擴容方案的類別
我們按照"是否改變一層主網"作爲標準,把擴容方案分爲鏈上擴容和鏈下擴容兩大類。
2.1 鏈上擴容
核心概念:通過改變一層主網協議達到擴容效果的解決方案,目前的主要方案是分片。
鏈上擴容有多種方案,此篇文章不展開,簡要列舉兩種:
方案一是擴大區塊空間,增加每個區塊打包的交易數量,但這會提高對高性能節點設備的要求,提高節點加入門檻,降低了"去中心化"程度。
方案二是分片,將區塊鏈帳本分成若幹部分,由不同分片即不同節點負責不同記帳,並行計算可以同時處理多個交易;這可降低節點計算壓力和加入門檻,提高交易處理速度和去中心化程度;但意味着全網算力被分散,會降低整個網路的"安全性"。
改變一層主網協議的代碼可能會產生難以預料的負面影響,因爲底層任何細微的安全漏洞都會嚴重威脅整個網路的安全性,網路可能會被迫進行分叉或中斷修復升級。
2.2 鏈下擴容
核心概念:不改變現有一層主網協議的擴容解決方案。
鏈下擴容方案又可以細分爲Layer2和其他方案:
Layer2:State Channels、Plasma、Rollups(Optimistic Rollups和ZK Rollups)
其他:Sidechains、Validium
3. 鏈下擴容的方案
3.1 State Channels
3.1.1 概要
狀態通道規定只有在通道打開、關閉或解決糾紛時,用戶才需要與主網交互,並把用戶之間的交互放在鏈下進行,以此來降低用戶交易的時間和成本,並且實現交易次數不受限制。
狀態通道是簡單的P2P協議,適合"基於回合的應用程序",例如兩人國際象棋遊戲。每個通道都由主網上運行的多籤智能合約管理,該合約控制存入通道的資產,驗證狀態更新,並仲裁參與者之間的爭議。參與者在區塊鏈網路部署合約後,存入資金並鎖定,雙方籤名確認後,通道正式開通。通道允許參與者之間進行不限次數的鏈下免費交易(只要轉帳淨值不超過存入的代幣總額)。參與者輪流發送狀態更新給對方,等待對方籤名確認。一旦對方籤名確認,這筆狀態更新就算完成。正常情況下,雙方同意的狀態更新不會上傳主網,只有在出現爭議或關閉通道時,才會依賴主網確認。需要關閉通道時,任一參與者可在主網提出交易請求,如果退出請求獲得全員一致籤名批準,則鏈上立即執行,即智能合約根據通道最終狀態下每個參與者的餘額,分發剩餘的鎖定資金;如果其他參與者沒有籤名批準,則所有人需等待"挑戰期"結束才能收到剩餘資金。
綜上,狀態通道方案可以大大減少主網計算量,提升交易速度,降低交易成本。
3.1.2 時間線
2015/02,Joseph Poon和Thaddeus Dryja發布閃電網絡白皮書草案。
2015/11,Jeff Coleman首次系統性總結了State Channel的概念,提出比特幣的Payment Channel是State Channel概念中的子案例。
2016/01,Joseph Poon和Thaddeus Dryja正式發表白皮書《The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments》提出比特幣閃電網絡的擴容方案Payment Channel(支付通道),該方案僅用於處理比特幣網路上的轉帳支付。
2017/11,第一個基於Payment Channel框架下的State Channel設計規範Sprites被提出。
2018/06,Counterfactual提出了一個詳細的Generalized State Channels設計,這是第一個完全與狀態通道相關的設計。
2018/10,文章Generalised State Channel Networks提出State Channel Networks和Virtual Channels的概念。
2019/02,狀態通道的概念擴展到N-Party Channels,Nitro是首個基於該想法建立的協議。
2019/10,Pisa爲了解決所有參與者需要持續在線的問題,拓展了Watchtowers的概念。
2020/03,Hydra提出Fast Isomorphic Channels。
3.1.3 技術原理
傳統鏈上的工作流程:Alice和Bob與部署在主網上的智能合約進行交互,用戶通過向鏈上發送交易來改變智能合約的狀態。缺點是會帶來時間和成本問題。
大多數狀態通道協議遵循的一般工作流程:
Alice和Bob通過從個人EOA存入資金到鏈上合約地址,這些資金被鎖定在合約中,直到通道關閉時才返回給用戶;二人籤名確認後,之間的狀態通道正式開通。
Alice和Bob通過該通道理論上可在鏈下開展不限次數的交易,參與者通過加密的籤名消息相互通信。雙方用戶都需要對每筆交易進行籤名,以防止雙花作惡。通過這些消息,他們提出自己帳戶的狀態更新,並接受對方提出的狀態更新。
如果Alice想關閉通道結束和Bob之間的交易,Alice需要向合約提交自己帳戶的最終狀態,如果Bob籤名批準,合約則會根據最終狀態將鎖定的資金釋放返回對應用戶。如果Bob未響應籤名,合約則會在挑戰期結束後將鎖定的資金釋放返回對應用戶。
悲觀情況下狀態通道的工作流程:起初,兩個參與者存入資金,然後開始交換狀態更新。假設在某個時間點,Bob在他的輪次中不響應Alice發送來的狀態更新籤名,此時,Alice可以通過向合約提交自己最後一次的有效狀態來發起挑戰,這個有效狀態也包含了Bob之前的籤名,從而證明最後一筆交易已經收到Bob的批準,最後狀態已經收到Bob的確認。然後,合約允許Bob在一段時間內通過將下一個狀態提交給合約進行響應;如果Bob響應,則二人可以繼續在狀態通道內進行交易;如果Bob在該時間段內沒有響應,則合約自動關閉狀態通道並將資金返回給Alice。
3.1.4 優缺點
優點:
缺點:
3.1.5 應用
比特幣閃電網絡:
概述:閃電網絡是比特幣網路的小額支付通道,其整體技術演變經歷:2/2多籤構建單向支付通道,增加RSMC後可構建雙向支付通道,再增加HTLC後可連接支付通道拓展到多人支付,最終構建支付網絡即閃電網絡。通過鏈下小額支付通道,然後借助中間人構成交易網路,可以解決比特幣網路擴容問題。閃電網絡的整體使用遵循着"存款(建立通道)→閃電網絡交易(更新通道狀態)→退款/結算(結束通道)"的流程;理論上閃電網絡每秒可以處理一百萬筆交易。
時間線:
生態發展: BTC閃電網絡生態從下到上依次爲:底層的BTC網路---核心基礎設施---各種Dapps。
核心基礎設施包括:
核心基礎設施之上是各種支付和金融服務以及應用程序,例如,Strike建立在LND解決方案之上允許用戶買賣BTC,在Twitter上使用BTC打賞創作者和允許Shopify商家接受BTC等。
截止2022年11月,