撰文：Chakra Research
除了第一輯所提到的原生擴容方案，比特幣的另一類擴容之路採用的是在比特幣之上額外建立一層協議，稱之爲 Layer 2。Layer 2 方案最關鍵的有兩點，安全的雙向橋接與繼承比特幣的共識安全性。
側鏈（Sidechain）
側鏈概念的起源最早可以追溯到 2014 年 blockStream 提交的《Enabling Blockchain Innovations with Pegged Sidechain》，是一種較爲樸素的擴容方案。
工作原理
側鏈是與主鏈完全獨立運行的區塊鏈，有自己的共識協議，可以作爲主鏈創新的實驗場。當側鏈發生惡性事件時，損害完全侷限於側鏈本身，對主鏈不產生任何影響。側鏈可以使用 TPS 更高的共識協議，增加鏈上的編程能力，實現 BTC 的增強。
側鏈可以通過 two-way peg 或 one-way peg 去實現比特幣在不同區塊鏈之間的轉移，當然實際上 BTC 只能停留在 Bitcoin 網絡上，所以我們需要一種錨定機制來使得側鏈中的 BTC 與 Bitcoin 網絡的 BTC 產生聯繫。
one-way peg 要求用戶將主網上的 BTC 發送到不可用的地址進行銷燬，隨後將在側鏈上得到對應數量的 BTC，但是過程無法反轉。two-way peg 是對 one-way peg 的進一步升級，讓 BTC 能夠在主鏈與側鏈之間來回移動。與發送到不可用地址銷燬不同，two-way peg 會將 BTC 通過多籤等控制腳本進行鎖定，在側鏈上鑄造新的 BTC。當用戶想要回到主網，則將側鏈上的 BTC burn 掉，在主網釋放原先鎖定的 B TC。
one-way peg 的實現與 two-way peg 相比，要簡單得多，因爲無需管理 Bitcoin 網絡上的相關狀態，但是通過 one-way peg 生成的側鏈資產，可能一文不值，因爲缺乏反向的錨定機制。
對於主鏈的鎖定交易與側鏈上的銷燬交易的驗證，有不同的方案與不同的安全等級。最簡單的是採用多籤參與者的外部驗證，但是中心化風險較高，更優的選擇是採用 SPV Proof 實現去中心化的驗證。當然，由於比特幣主網缺乏必要的編程能力，無法進行 SPV 驗證，只能選取其他方式，通常是多籤託管。
問題與思路
側鏈爲人所詬病的問題主要有兩點：
資產跨鏈對驗證者的依賴：由於比特幣主網尚且無法實現智能合約，無法通過去信任的合約邏輯來處理資產的跨鏈轉移，從側鏈跨回比特幣時，需要依賴一組驗證人完成操作，存在信任假設，有欺詐風險。
側鏈無法繼承主鏈安全性：側鏈完全獨立於主網運行，無法繼承主網的安全性，可能發生惡意區塊重組等事件。
對此，側鏈的思路包括依賴權威（聯盟型）、依賴經濟安全（PoS）、依賴去中心化的比特幣礦工（Merged Mining）、依賴硬件安全模塊（HSM），Bitcoin 上的資金託管與側鏈的區塊生產可以由不同角色負責，進而引入更復雜的安全機制。
案例介紹
Liquid
最初出現的側鏈形式是聯盟側鏈，由事先選取的多個實體擔任驗證者，同時負責主網資金的託管與側鏈的出塊。
Liquid 是聯盟側鏈的代表，由 15 個參與方擔任驗證者，不公開私鑰管理方式，驗證通過需要 11 個簽名。Liquid 側鏈上的出塊也由 15 個參與方共同維護，低節點數的聯盟鏈能夠實現較高的 TPS，達成擴容目標，主要的應用範圍是 DeFi。
聯盟側鏈的方式具有顯著的中心化安全風險。
Rootstock (RSK)
RSK 也由 15 個節點擔任主網資金託管方，驗證通過僅需 8 個簽名。與 Liquid 的區別在於，多籤密鑰交由硬件安全模塊 HSM 管理，根據 PoW 共識簽署 peg-out 指令，防止持有密鑰的驗證人直接操縱託管資金。
在側鏈共識方面，RSK 採用 Merged Mining，藉助主網算力來保障側鏈上交易的安全性，當合並挖礦算力比例佔主網比例較高時，可以較好地防止側鏈上的雙花攻擊。RSK 對 Merged Mining 做出了改進，以保障低哈希率下側鏈的安全性，採用分叉感知型方法，對分叉行爲進行鏈下共識干預，降低雙花機率。
然而，Merged Mining 使得礦工的激勵發生變化，並且加劇了 MEV 的風險，最終可能動搖系統的穩定性。長遠來看，Merged Mining 可能會增加挖礦的中心化。
Stacks
Stacks 通過將側鏈的區塊哈希提交至比特幣區塊中，將 Stacks 鏈歷史錨定到比特幣，擁有了比特幣相同的 Finality，Stacks 的分叉只能由 Bitcoin 的分叉引起，提升了抗雙花能力。
sBTC 引入了新的代幣 STX 與激勵模型，採用質押橋方式，允許最多 150 個主網驗證者。所謂質押橋，驗證者需要質押 STX 代幣以獲取批准存款與取款的權限。質押橋的安全性嚴重依賴於質押資產的價值，在質押資產價值劇烈波動時，BTC 跨鏈的安全性容易受損。如果質押資產的價值低於跨鏈資產的價值，則驗證者有作惡的動機。
還有一些側鏈提案正在社區中被廣泛討論。
Drivechain
最受關注的是 Paul Sztorc 在 2015 年提出的 Drivechain，方案中的關鍵技術已經被分配 BIP 300（掛鉤機制） 與 BIP 301（盲合併挖礦）。BIP 300 詳細定義了新增一條側鏈的邏輯，激活新側鏈與通過礦工信號激活軟分叉類似。BIP 301 讓比特幣礦工在無需驗證具體交易內容的情況下，成爲側鏈的區塊生產者。
比特幣礦工同時負責取款交易的批准，礦工首先需要在自己所挖出塊的 coinbase 交易中創建一個 OP_RETURN 輸出，來提議一筆提款交易，之後各礦工可以對該提議進行表決，每個塊挖出時都可以對提議提支持或反對票。一旦一筆提款交易超過閾值（13150 個區塊），提款交易正式執行，獲得比特幣主鏈確認。
實際上，礦工完全控制着 Drivechain 上的資金，如果出現資金被盜事件，用戶只能通過 UASF （用戶激活的軟分叉）來自救，但這非常難達成共識。此外，Drivechain 中礦工的獨特地位加劇了 MEV 的風險，這已經在以太坊中驗證過了。
Spacechain
Spacechain 另闢蹊徑，使用 Perpetual 1 way peg（P1WP），用戶燃燒 BTC 以獲得 Spacechain 上的 token，直接跳過了資金安全問題。該 token 只能用於拍賣 spacechain 上的 block space，而不存在任何價值存儲作用。
爲保證側鏈的安全，Spacechain 採用盲合併挖礦，由其他用戶使用 ANYPREVOUT（APO）公開出價競爭構建區塊的權利，比特幣礦工只需在區塊中承諾 Spacechain 的區塊頭，無需驗證側鏈區塊。不過，Spacechain 的啓動需要 Covanent 的支持，現在比特幣社區仍在討論軟分叉添加 Covanent 操作碼的必要性。
總的來講，Spacechain 通過比特幣上競拍出塊的功能，能夠實現一個擁有比特幣相同的去中心化與抗審查屬性，與更多可編程性的側鏈。
Softchain
Softchain 是 Spacechain 作者 Ruben Somsen 提出的 2wp 側鏈提案，使用 PoW FP 共識機制來保障側鏈的安全性。在一般的情況下，比特幣的全節點只需要下載 softchain 的區塊頭，驗證工作量證明。當出現分叉時，下載孤塊與對應的 UTXO 集合承諾，驗證區塊的有效性。
對於 2wp 機制，peg-in 時在主鏈上創建一個存款交易，softchain 上引用該主鏈交易來獲取資金；peg-out 時則在 softchain 創建一個提款交易，主鏈上引用該交易來取回 BTC，而取款過程需要等待一個很長的挑戰期過後，才能夠完成。具體的 peg-in，peg-out 機制需要軟分叉支持，因此該方案被稱爲 Softchain。
Softchain 方案對比特幣主網的全節點造成了額外的驗證成本，Softchain 的共識分裂有可能影響主網共識的達成，成爲比特幣主網的可能攻擊手段。
閃電網絡（Lightning Network）
閃電網絡於 2015 年發佈白皮書，2018 年正式上線，作爲比特幣上的 Layer2 p2p 支付協議，旨在將大量小額、高頻的交易轉移到鏈下處理，長時間內被認爲是比特幣網絡最 promising 的擴容方案。
核心模塊
Lightning Network 的實現，離不開比特幣中幾個重要的模塊，它們共同保障了閃電網絡交易的安全性。
首先是預簽名交易。預簽名交易是在 SegWit 升級之後才變得安全可用的。SegWit 將簽名與其餘交易數據分離，解決了潛在的循環依賴、第三方交易篡改、第二方交易篡改等問題。閃電網絡鏈下計算安全性的保障，是通過對方給出的不可撤銷的承諾保障的，而該承諾是通過預簽名交易來實現的。收到對方給出的預簽名交易後，用戶可以隨時將該交易廣播至鏈上，完成承諾的兌現。
其次是多重簽名。雙方進行鏈下資金的頻繁轉移，需要一個載體，這個載體需要兩方都保有一定的控制權，所以需要多重簽名，一般使用 2/2 多籤，這保證資金的轉移必須在雙方的共同同意下才能進行。
但是 2/2 多重簽名會產生活性問題，即對方不配合的情況下，用戶無法從多籤地址中轉移任何資產，導致原有資金的損失。時間鎖能夠解決活性問題，通過預先簽署一個帶時間鎖的返還資金的合約，能夠保證即使在一方失活的情況下，另一方也能夠收回初始資金。
最後是哈希鎖，能夠爲起到連接多個狀態通道，構建網絡的效果，哈希的原象將作爲溝通媒介，協調多個實體間的正確運行。
運行流程
雙向通道
使用閃電網絡進行交易的雙方首先需要在比特幣上打開一個雙向的支付通道，雙方可以在鏈下進行任意數量的交易，待所有交易完成後，提交最新狀態至比特幣鏈上完成結算，關閉支付通道。
具體來說,支付通道的實現涉及以下幾個關鍵步驟:
創建多籤地址。通道的雙方首先需要創建一個 2-of-2 的多籤地址,作爲通道的資金鎖定地址。雙方各自持有一個簽名私鑰,同時提供自己的公鑰。
初始化通道。雙方在鏈上廣播一筆交易,將一定數量的比特幣鎖定到多籤地址中,作爲通道的初始資金。這筆交易被稱爲通道的「錨點」交易。
更新通道狀態。在通道內進行支付時,雙方通過交換預簽名交易的方式更新通道的狀態。每次更新都會生成一個新的「承諾交易」,代表當前的資金分配狀態。承諾交易有兩個輸出,分別對應雙方的資金份額。
廣播最新狀態。通道的任何一方都可以隨時將最新的承諾交易廣播到區塊鏈上,以提取自己的資金份額。爲了防止對方廣播舊的狀態,每個承諾交易都有一個相應的「懲罰交易」,如果對方作弊,自己就可以獲得對方的全部資金。
關閉通道。當雙方決定關閉通道時,他們可以合作生成一個「結算交易」,將最終的資金分配狀態廣播到區塊鏈上。這樣,鎖定在多籤地址中的資金就被釋放回雙方的個人地址。
鏈上仲裁。如果雙方在關閉通道時無法達成一致,任何一方都可以單方面廣播最新的承諾交易,啓動鏈上仲裁流程。如果在一定時間內 ( 如 1 天 ) 沒有異議,資金就會按照承諾交易的分配發送給雙方。
支付網絡
支付通道之間可以彼此連接成爲網絡，支持多跳路由，通過 HTLC 實現。HTLC 是以哈希鎖作爲直接條件，帶時間鎖的簽名支付作爲後備條件，在時間鎖到期之前用戶間可以圍繞哈希的原像進行交互。
當兩個用戶間沒有直接通道時，可以藉助路由間的 HTLC 完成支付。整個過程中哈希原像 R 起到了關鍵的紐帶作用，確保了支付的原子性。同時，HTLC 的時間鎖設置爲沿途遞減，確保每一跳都有足夠的時間來處理和轉發支付。
存在的問題
從本質上講，閃電網絡通過 p2p 的狀態通道規避了資產橋接的外部信任假設，同時利用時間鎖腳本提供了資產的最終保障，能夠提供故障保護。在對方失去活性不配合的情況下，可以完成單方面的退出。因此，閃電網絡在支付場景有很高的使用價值，但同時也存在許多侷限性，主要包括：
通道容量限制。閃電網絡中的支付通道容量受到初始鎖定資金的限制，無法支持超過通道容量的大額支付。這可能限制了某些應用場景，如大宗商品交易等。
在線與同步。爲了及時接收和轉發支付，閃電網絡的節點需要保持在線狀態。如果節點長時間離線，可能錯過一些通道狀態更新，導致狀態不同步。這對於個人用戶和移動設備來說可能是一個挑戰，也增加了節點運營的成本。
流動性管理。閃電網絡的路由效率依賴於通道的流動性分佈。如果資金分佈不均衡，可能導致一些支付路徑失效，影響用戶體驗。管理通道的流動性平衡需要一定的技術和資金成本。
隱私泄露。爲了找到可用的支付路徑，閃電網絡的路由算法需要一定程度地瞭解通道的容量和連通性信息。這可能泄露一些用戶的隱私，如資金分佈、交易對手等。支付通道的開啓與關閉也可能暴露出相關參與者的信息。
RGB
RGB 協議的最初構想受到 Peter Todd 提出的客戶端驗證與一次性密封概念啓發，於 2016 年由 Giacomo Zucco 提出，是一種可拓展、保護隱私的比特幣二層協議。
核心思想
客戶端驗證
區塊鏈的驗證過程，是將由交易組成的區塊向全體廣播，讓每個節點都計算區塊中的交易，完成驗證。這實際上造就了一種公共物品，即全網的節點幫助每個提交交易的個人完成了驗證，而用戶提供 BTC 作爲手續費作爲幫助驗證的激勵。客戶端驗證更加以個體爲中心，狀態驗證不由全局執行，而是由參與特定狀態轉換的個體作爲驗證，只有在產生交易的各方各自驗證狀態轉換的有效性，這顯著提升了隱私，也減輕了節點的負擔，提高了可拓展性。
一次性密封
點對點的狀態轉換存在一種隱患，用戶收集不到完整的狀態轉換歷史，就可能被欺詐，出現雙重花費的情況。一次性密封是爲了解決該問題所提出的，通過一個特殊的僅能夠被使用一次的對象，確保雙花情況不發生，提高安全性。比特幣的 UTXO 就是最合適的一次性密封對象，由比特幣的共識機制與全網算力保證，因此 RGB 資產能夠繼承比特幣的安全性。
加密承諾
一次性密封需要與加密承諾結合起來，才能夠保證用戶明確狀態轉換的發生，避免雙花攻擊的出現。所謂承諾，就是向他人告知某件事已經發生，且之後無法修改，但是不需要暴露具體的事件，直到需要驗證的時刻，我們可以使用哈希函數來進行承諾。在 RGB 中，承諾的內容就是狀態的轉換，通過 UTXO 的花費，RGB 資產的接受方會收到狀態轉移的信號，進而再通過資產的花費方在鏈下傳送的具體數據對照承諾進行驗證。
工作流程
RGB 利用比特幣的共識保障雙花安全性與抗審查行，而所以狀態轉移的驗證工作都移交至鏈下，僅由接受支付的客戶端進行驗證。
對於 RGB 資產的發行方，需要通過發起一筆交易來創建 RGB 合約，其中的具體信息的承諾會存儲在 Taproot 交易中某個支出條件的 OP_RETURN 腳本中。
當 RGB 資產的持有者想要進行花費時，需要從資產的接收者獲取相關信息，創建一筆 RGB 交易，並將該 RGB 交易的詳情進行承諾，將承諾值放置進資產接收者指定的 UTXO 中，併發出一筆交易，花費原先的 UTXO 並創建接收方指定的 UTXO。當資產的接收者觀察到原先存儲 RGB 資產的 UTXO 被花費，就可以通過比特幣交易中的承諾驗證 RGB 交易的有效性，一旦驗證有效，則認爲自己確實接收到了 RGB 資產。
對於 RGB 資產的接收者，需要由支付方提供合約的初始狀態與狀態轉換規則、每次轉移使用的比特幣交易、每個比特幣交易所承諾的 RGB 交易、以及每個比特幣交易有效性的證據，由接收者的客戶端根據這些數據驗證驗證 RGB 交易的有效性。其中，比特幣的 UTXO 作爲容器，保存着 RGB 合約的狀態，每個 RGB 合約的轉移歷史都可以表示爲一個有向無環圖，RGB 資產的接收者只能獲取與自己持有 RGB 資產有關的歷史，而無法獲取其他的分支。
優勢與不足
輕量化驗證
與區塊鏈的完整驗證相比，RGB 協議大幅降低了驗證的成本，用戶無需遍歷所有的歷史區塊來獲取到最新狀態，而只需同步與自己接收資產相關的歷史記錄，即可驗證交易的有效性。
這種輕量化的驗證使得點對點的交易更加容易，進一步擺脫了對中心化服務提供商的需求，提高了去中心化水平。
可拓展性
RGB 協議僅需通過一個哈希的承諾來繼承比特幣的安全性，通過 Taproot 腳本的方式，幾乎不產生額外比特幣鏈上空間的消耗，這使得資產的複雜編程性成爲可能。由於使用 UTXO 作爲容器，RGB 協議在具備自然的併發性，不同轉移分支上的 RGB 資產不會彼此阻塞，可以同時花費。
隱私性
不同於一般的協議，RGB 資產中只有資產的接收方能夠獲取到 RGB 資產的歷史轉移情況，一旦完成花費也無法獲取未來的轉移情況，這顯著保證了用戶的隱私性。RGB 資產的交易與比特幣 UTXO 的轉移也不存在關聯，旁人無法在比特幣鏈上獲取到 RGB 交易的痕跡。
此外，RGB 還支持盲化支出，支付方也無法明確 RGB 資產會支付到哪個 UTXO 中，進一步提升了隱私性，也增強了抗審查能力。
不足
當 RGB 資產經歷多次轉手後，新接收資產的用戶將被迫驗證冗長的轉移歷史，導致較爲沉重的驗證負擔，驗證的時間可能較長，喪失了快速確認的能力。對於區塊鏈中保持運行的節點而言，由於始終同步最新狀態，每次收到新區快驗證狀態轉移的時間反而是有限的。
社區正在討論複用歷史計算的可能，recursive ZK Proof 有機會實現恆定時間與大小的的狀態驗證。
卷疊（Rollup）
概述
Rollup 是以太坊生態在探索多年後得出的最佳擴容解決方案，從狀態通道到 Plasma 最後演進到 Rollup。
Rollup 是一條獨立的區塊鏈，在比特幣鏈外收集交易，將多筆交易打包成一個批次並執行，並將這個批次的數據與狀態承諾提交到主鏈上，實現了鏈下交易處理和狀態更新。爲了最大程度實現擴容，Rollup 在現階段通常採用中心化的排序器，提升執行效率，但同時不損失安全性，因爲安全性是由主鏈上對 Rollup 狀態轉換的驗證保證的。
隨着以太坊生態 Rollup 方案的成熟，比特幣生態也開始了對於 Rollup 的嘗試。然而，比特幣與以太坊最關鍵性的差異在於編程能力的不足，無法在鏈上進行構建 Rollup 所需的計算，這使得當前人們只能嘗試實現主權 Rollup 與 OP Rollup。
分類
根據狀態轉移的驗證方式不同，Rollup 可以分爲兩大類，Optimistic Rollup 與 Validity Rollup (ZK Rollup)。
Optimistic Rollup 採用樂觀驗證方式，每次交易批次提交後的爭議期內，任何人都可以檢查鏈下數據，對有問題的交易批次提出異議，提交欺詐證明到主鏈上，對 Sequencer 罰沒。爭議期過後如果沒有有效的欺詐證明，則認爲交易批次有效，狀態更新在主鏈上被確認。
Validity Rollup 用 Validity Proof 完成驗證，Sequencer 使用零知識證明算法爲每個交易批次生成一個簡潔的有效性證明，證明該批次的狀態轉移是正確的每次更新需要向主鏈提交交易批次的有效性證明，主鏈對證明進行驗證後理解確認狀態更新。
Optimistic Rollup 的優點是實現相對簡單，對主鏈的修改較少。但它的交易確認時間較長 ( 取決於異議期 )，而且需要較高的數據可用性。Validity Rollup 交易確認快，不依賴異議期，而且交易數據可以保持隱私，但是生成和驗證零知識證明需要較高的計算開銷。
Celestia 還提出了一種主權 Rollup 的概念，Rollup 的交易數據發佈到專門的 DA 層區塊鏈，負責數據可用性，而主權 Rollup 本身負責執行與結算。
探索與討論
比特幣上的 Rollup 尚處於早期階段，由於記賬模型與編程語言上和以太坊的差異，很難直接照搬以太坊的實踐經驗，比特幣社區正在積極探索創新的方案。
主權 Rollup
2023 年 3 月 5 日，Rollkit 宣佈成爲第一個支持比特幣主權 Rollup 的框架，主權 Rollup 的構建者可以通過 Rollkit 在比特幣上發佈可用性數據。
Rollkit 受到 Ordinals 啓發，通過 Taproot 交易來發布數據。一個通過公共內存池標準的 Taproot 交易可以包含最多 390 KB 的數據，由礦工直接發佈的非標準 Taproot 交易可以包含接近 4 MB 的任意數據。
Rollkit 實際的工作是爲主權 Rollup 提供了向比特幣上讀寫數據的接口，爲客戶提供中間件服務，將比特幣變爲 DA 層。
主權 Rollup 的想法遭到了許多質疑，許多反對者聲稱比特幣上的主權 Rollup 不過是將比特幣作爲公告板，完全無法繼承比特幣的安全性。事實上，如果僅向比特幣提交交易數據，只能改善活性，即所有用戶都能通過比特幣獲取到相應數據進行驗證，而安全性只能由主權 Rollup 自己定義，無法繼承。此外，比特幣上的區塊空間非常寶貴，提交全量的交易數據可能不是一個好的決定。
OP Rollup & Validity Rollup
儘管許多比特幣二層項目稱自己爲 ZK Rollup，其本質上更接近一種 OP Rollup，只不過過程中涉及到 Validity Proof 技術，然而比特幣的編程能力尚不足以支持直接的 Validity Proof 驗證。
當前，比特幣的操作碼集合非常有限，甚至無法直接計算乘法，對 Validity Proof 的驗證需要對操作碼的擴充，也很大程度上依賴於遞歸契約的實現，社區正在熱議的包括 OP_CAT, OP_CHECKSIG, OP_TXHASH 等。當然，如果能直接添加一個 OP_VERIFY_ZKP，也許我們不需要其他任何修改，但這顯然不太可能。此外，對於堆棧大小的限制，也阻礙了在比特幣腳本中驗證 Validity Proof 的努力，許多嘗試正在探索中。
所以 Validity Proof 如何工作？多數項目通過將交易批次的 statediff 與 Validity Proof 通過 銘刻的形式發佈到比特幣上，並採用 BitVM 進行樂觀驗證。BitVM 橋在這裏取代傳統的多籤方案，橋的 Operator 會組成一個 N 人的聯盟，對用戶的存款進行調度。用戶進行存款前，會要求聯盟對即將生成的 UTXO 進行預簽名，確保存款只能被其中的 Operator 合法地領取。獲得預簽名後，BTC 會被鎖定到一個 N/N 多籤的 Taproot 地址。
當用戶發出提款請求，Rollup 會將帶有 withdrawl Root 的 Validity Proof 發送到比特幣鏈上，Operator 先自掏腰包滿足用戶的提款需求，之後通過 BitVM 合約驗證有效性。如果每個 Operator 都認爲證明有效，則通過多籤對 Operator 給予報銷；只要有任何人認爲存在欺詐行爲，會進行挑戰流程，錯誤的一方會被 slash。
這個過程實際就與 OP Rollup 同出一轍，信任假設是 1/N，只要有一個驗證者是誠實的，協議就是安全的。
不過，該方案的技術落地層面，可能存在難度。在以太坊的 OP Rollup 項目中，Arbitrum 經過了多年的開發，現在的 Fraud Proof 仍爲許可制節點提交；Optimism 直至近期才宣佈支持 Fraud Proof，實現難度可見一斑。
而對於 BitVM 橋中預簽名的操作，在比特幣 Covanent 的支持下，可以更高效地實現，這塊仍等待社區共識。
從安全屬性來講，通過提交 Rollup 區塊哈希至比特幣獲取了抗重組與抗雙花性，又利用樂觀橋帶來了 1/N 的安全假設，不過橋的抗審查性還可以等待進一步提高。
結語：Layer 2 不是萬能解藥
總覽如此多種 Layer 2 方案，我們很容易發現每種方案能夠完成的任務都是有限的。在特定的信任假設下，Layer 2 能夠實現的效果很大程度上取決於 Layer 1——也就是比特幣原生的能力。
沒有 SegWit 升級與時間鎖，閃電網絡無法順利構建；沒有 Taproot 升級，RGB 的承諾無法順利提交；沒有 OP_CAT 與其他 Covanent，比特幣上的 Validity Rollup 不可能順利構建……
很多 Bitcoin Maxi 認爲比特幣永遠不應該更改，不應該增加新的功能，所有缺陷都讓 Layer 2 去解決，這是辦不到的，Layer 2 不是萬能解藥。我們需要一個功能更加強大的 Layer 1，才能夠構建出更加安全、高效、可拓展的 Layer 2。
下一篇，我們將介紹比特幣上提高可編程性的嘗試，敬請期待。
