比特幣擴展概念驗證：在支持 OP_CAT 的比特幣上實現橋契約

來源：Starknet 中文社區

精選速覽

• 深入探討在比特幣上構建 demo 橋契約，爲 Starknet 的生產級橋奠定基礎

• 實施存取款聚合器、橋和取款擴展器四種智能合約

• 利用遞歸契約和默克爾樹有效地批量處理存款和取款請求，同時保持用戶账戶的完整性和安全性

引言

本文，我們深入探討了 sCrypt 如何在比特幣上構建一個 demo 橋契約。該概念驗證實現旨在爲 Starknet 二層（L2）網絡的生產級橋奠定基礎。該橋的設計允許將多個存款或取款請求交易合並爲一個根交易，並將其並入主橋契約中，更新其狀態，該狀態由一組以默克爾樹組織的账戶組成。

由於橋契約腳本非常復雜，我們在 sCrypt 利用了 sCrypt 專屬領域語言（DSL）來編寫其實現方式。

概覽

該橋由一個遞歸契約比特幣腳本構成。在這裏，「契約」意味着鎖定腳本能夠對支出交易施加條件，而「遞歸」則意味着上述規則足夠強大，可以在鏈上實現持久的邏輯和狀態（這是任何鏈上智能合約的基本要求）。

該腳本存在於一系列交易中，每筆交易都對後續交易結構施加約束，而後續交易解鎖當前交易的輸出。每當一筆新交易添加到這條鏈中時，就代表了橋狀態的更新。因此，這條鏈的末端保存着當前的橋狀態。

契約狀態 — 具體來說，就是其哈希值 — 存儲在一個不可消耗的 OP_RETURN 輸出中。雖然我們不會花費這個 UTXO，但在執行契約腳本時可以檢查其數據。具體來說，狀態保存了包含账戶數據的默克爾樹的根哈希值，如下所示：

該默克爾樹保存了一組固定账戶槽的數據。葉節點包含各自账戶數據的哈希值，其中包括地址和余額。爲了表示空的账戶槽，這些槽被標記爲零字節。

每次橋的更新都會導致账戶樹發生變化。爲了方便這種更新，我們依賴於默克爾證明，其驗證在比特幣腳本中非常高效。更新主要包含兩個步驟。首先，我們驗證一個默克爾證明，以證明證明默克爾樹包含了特定账戶的當前狀態。然後，在計算該账戶的新狀態後，我們使用前述默克爾證明中的相同輔助節點來推導出新的根哈希值。

更新可以是存款，也可以是取款。橋可在單筆交易中執行這些更新的批量操作。

存款

我們的目標是讓用戶能夠獨立提交存款或取款請求。爲此，用戶分別創建交易，分別支付給存款或取款聚合契約。該契約將這些請求匯總成一棵默克爾樹。該樹的根哈希值可以合並到主橋契約中，主橋契約隨後處理每筆存款或取款。

在存款交易中，除了對存款數據進行哈希並構建默克爾樹之外，契約還確保鎖定在契約輸出中的存款 satoshis 按正確的方式累積至樹的根節點。聚合契約確保只有正確的鏈上智能合約才能使用這些資金。(當然，在生產環境中，我們也會允許用戶取消其存款交易）。

這種樹形結構的設計源於契約腳本構建的限制，即不允許包含過多輸入和輸出的交易。樹形結構使我們能夠擴展到潛在的任意吞吐量。

取款請求

取款請求的聚合與存款類似，但有幾處不同。首先，我們需要一種認證方法，以便用戶可以從自己的账戶取款。這與存款不同，存款是任何人可以向任何账戶存款，這與比特幣地址的使用方式類似。認證在聚合樹的葉節點層完成。取款請求聚合契約會檢查提款地址是否與葉交易中第一個輸入的 P2WPKH 地址匹配。

這確保了地址的所有者批准取款，因爲他們已經籤署了請求取款的交易。與存款聚合相比，另一個細微的不同之處在於，我們還會將中間的累計金額進行哈希，向上傳遞到樹結構中。這是因爲在擴展取款時，我們需要這些數據，稍後會詳細說明。

敏銳的讀者可能會注意到這種取款請求認證模型的潛在問題。假如操作員決定作弊，創建一個聚合樹的根交易，而聚合樹的數據是通過未經認證的虛假取款請求在本地僞造的，那該怎么辦？我們需要一種有效的方法來驗證根交易是否來自有效的葉交易。

爲了解決這個問題，我們執行了所謂的「創世檢查（genesis check）」。本質上，我們讓聚合契約檢查其前一筆交易以及前兩筆交易，即其「祖先交易」。契約驗證這些交易是否包含相同的契約腳本，並執行相同的檢查。通過這種方式，我們實現了一個歸納式的交易歷史檢查。由於前兩筆交易與當前契約一樣，執行了相同的檢查，我們可以確認這些交易的「祖先」也執行了相同的檢查，一直追溯到葉節點（即創世交易）。

當然，我們對樹的兩個分支都執行了驗證。因此，每個聚合節點交易總共檢查最多六筆交易。

取款擴展

現在讓我們進入解決方案的最後部分：取款擴展。在處理一批取款請求後，主橋契約會強制執行一個輸出，將總取款金額支付給擴展契約。我們可以將這個契約視爲執行取款請求聚合契約所做操作的逆向過程。其從取款樹的根節點开始，將其擴展爲兩個分支，每個分支包含應支付到該分支的相應取款金額。這個過程一直延續到取款樹的葉節點。葉交易強制執行一個簡單的支付輸出，向账戶所有者的地址支付他們要求提取的金額。

實現方式

爲了實現我們的橋契約，我們开發了四個 sCrypt 智能合約，分別處理系統的不同方面。本節，我們將簡要概述每個合約的功能。

存款聚合器合約

存款聚合器（DepositAggregator）合約將單個存款聚合成一棵默克爾樹，然後將其合並到主橋契約中。這種聚合可實現批量存款處理，減少需要由橋單獨處理的交易數量。此外，它還允許用戶獨立提交存款，稍後由操作員進行處理。

合約構建函數有兩個參數：

• operator：橋操作員的公鑰，該操作員有權聚合存款。

• bridgeSPK：主橋契約的腳本公鑰（SPK），確保聚合存款正確合並。

存款聚合器的核心功能封裝在「聚合（aggregate）」方法中。該方法執行以下步驟：

驗證 Sighash 原像和操作員籤名：確保交易經過橋操作員授權，並且 sighash 原像格式正確且屬於正在執行的交易。通過這篇文章了解關於 sighash 原像驗證的更多信息。

構建和驗證前置交易 ID：檢查已聚合的前置交易是否有效並正確引用。

默克爾樹聚合：驗證作爲見證哈希值傳遞的存款數據是否與前置交易中存儲的狀態匹配。

金額驗證：確認前置輸出中的金額與指定的存款金額匹配，確保資金在聚合中正確計算。

狀態更新：通過連接前置交易的哈希值計算新的哈希值，並更新 OP_RETURN 輸出中的狀態。

重入攻擊防範：強制執行嚴格的輸出腳本和金額，以防止未經授權的修改或雙花。

一旦存款被聚合，它們必須合並到主橋契約中。這一過程由「最終確認（finalize）」方法處理，其步驟包括：

驗證前置交易：與「聚合（aggregate）」方法類似，驗證前置交易，以確保合並數據的完整性。

與橋契約的集成：通過引用橋的交易 ID 和腳本公鑰，檢查聚合後的存款是否正確地合並至主橋契約中。

存款聚合合約的完整源代碼可查看 GitHub。

取款聚合器合約

取款聚合器（WithdrawalAggregator）合約旨在將單個取款請求聚合成一棵默克爾樹，與存款聚合器處理存款的方式類似。不過，取款操作需要額外的認證，以確保只有合法的账戶所有者才能從其账戶中提取資金。

取款聚合器的核心功能封裝在 「聚合（aggregate）」方法中，該方法執行以下步驟：

構建和驗證前置交易 ID：該過程驗證已聚合的前置交易是否有效並正確引用。

所有權證明驗證：驗證所有權證明交易確保只有合法的所有者才能從账戶中提取資金。

• 所有權證明交易：一種證明控制取款地址的交易。合約檢查取款請求中的地址是否與所有權證明交易中的地址匹配。

通過「祖先交易」進行創世檢查：與存款聚合器類似，合約通過驗證祖先交易執行歸納檢查。這確保了交易歷史的完整性，並防止操作員插入未經授權的取款請求。

金額驗證和總金額計算：該方法通過將取款請求或之前的聚合進行金額相加，計算出要提取的總金額。

狀態更新：計算一個新的哈希值，其中包含前置交易的哈希值和取款金額的總和。這個哈希值存儲在 OP_RETURN 輸出中，以更新狀態。

重入攻擊防範和輸出強制：確保嚴格定義輸出，以防止未經授權的修改或重入攻擊。

取款聚合合約的完整源代碼可查看 GitHub。

橋合約

橋（Bridge）合約是我們系統的核心組件，是維護橋狀態的主要契約，包括以默克爾樹組織的账戶及其余額。其通過與我們之前討論的聚合器合約集成，處理存款和取款操作。

合約構建函數有兩個參數：

• operator：橋操作員的公鑰，該操作員有權更新橋狀態。

• expanderSPK：取款擴展器（WithdrawalExpander）合約的腳本公鑰（SPK），在取款過程中使用。

存款方法負責處理聚合的存款交易，並相應更新账戶余額。

存款方法執行的步驟包括：

處理存款並更新账戶：

• 遍歷存款，並使用「應用存款（applyDeposit）」方法將每筆存款應用到相應的账戶。

更新橋狀態和輸出：

• 處理存款後，計算新的账戶默克爾根。

• 創建新的狀態哈希值，表示更新後的橋狀態。

• 構建合約輸出，將總存款金額添加至橋余額中。

• 保證輸出符合預期格式，以維護數據完整性。

取款方法處理聚合的取款交易，更新账戶余額，並通過取款擴展器准備分配的資金。

取款方法執行的步驟包括：

處理取款請求並更新账戶：

• 遍歷取款請求，並使用「應用存款（applyDeposit）」方法將每筆取款應用到相應的账戶。

更新橋狀態和輸出：

• 處理取款後，計算新的账戶默克爾根。

• 創建新的狀態哈希值，表示更新後的橋狀態。

• 構建合約輸出，將總取款金額從橋余額中扣除。

• 爲取款擴展器合約創建一個擴展輸出，其中包含總取款金額。

• 保證輸出符合預期格式，以維護數據完整性。

完整源代碼可查看 GitHub。

取款擴展器合約

取款擴展器（WithdrawalExpander）是我們橋系統的最終組件，負責根據用戶的取款請求將聚合的取款金額分發回各個用戶。它逆轉了取款聚合器執行的聚合過程，將聚合的取款數據擴展回單個用戶的支付。

取款擴展器的核心功能封裝在「擴展（expand）」方法中。該方法接受聚合的取款數據，並通過遞歸的方式將其擴展爲單獨的取款交易，向用戶支付相應的金額。

擴展到葉節點：如果方法擴展到葉節點（單個取款），它會驗證取款數據，並構建直接支付到用戶地址的輸出。

進一步擴展： 如果該方法尚未達到葉節點層，則會繼續擴展，將聚合數據分成兩個分支，並創建輸出，以供進一步擴展的交易消費。

結語

在這個概念驗證實現中，我們使用 sCrypt 嵌入式領域專屬語言（DSL）开發了一個基於 OP_CAT 支持的比特幣的橋契約。該橋利用遞歸契約和默克爾樹有效地批量處理存款和取款請求，同時保持用戶账戶的完整性和安全性。通過設計和實施存款聚合器（DepositAggregator）、取款聚合器（WithdrawalAggregator）、橋（Bridge）和取款擴展器（WithdrawalExpander）這四種智能合約，我們提供了一種在比特幣上管理有狀態交互的方法，促進了與像 Starknet 這樣的二層網絡的互操作性。這項工作爲構建生產級橋提供了技術基礎，可能增強比特幣生態系統中的可擴展性和功能性。

所有代碼實現以及端到端測試均可在 GitHub 上獲取。

[全文完]

原文鏈接：https://starkware.co/blog/implementing-a-bridge-covenant-on-op-cat-bitcoin/

Mirror: https://mirror.xyz/starknet-zh.eth/zFbhQB7gfmSTV4CcTv5MRqJBUnKuwMLTNOgZ6jUgDK8

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。

---

標題：比特幣擴展概念驗證：在支持 OP_CAT 的比特幣上實現橋契約

地址：https://www.torrentbusiness.com/article/137549.html

標籤：