比特幣Layer 2擴展技術分析:有效性證明與欺詐證明

1 引言

對於一個算法 f,兩個互不信任的參與者,Alice 和 Bob,可以通過以下方式建立信任:

  1. Alice 輸入 x,運行算法 f,得到結果 y。Bob 也用相同的輸入 x 運行算法 f,得到 y′。如果 y 和 y′ 相等,Bob 就認可 Alice 提供的輸入 x 和輸出 y。這是一種常見的有效性證明機制,通常應用於區塊鏈共識中,其中 Alice 是打包區塊的節點,而 Bob 是參與共識的節點。
  2. Alice 輸入 x,運行 zk.prove 程序,得到結果 y 和證明 proof。Bob 根據 f、y 和 proof 運行 zk.verify 程序。如果結果為真,Bob 就認可 Alice 的結果 y;如果結果為假,Bob 就不認可 Alice 的結果 y。這是一種有效性證明,Bob 可以是鏈上的合約。
  3. Alice 輸入 x,運行算法 f,得到結果 y。Bob 也用相同的輸入 x 運行算法 f,得到 y′。如果 y 和 y′ 相等,就不做任何事情;如果 y 和 y′ 不相等,Bob 就會挑戰 Alice,挑戰的程序是 f。Alice 和 Bob 之間的互動次數可以是一輪或多輪。通過挑戰-響應機制實現仲裁。這是一種欺詐證明,Bob 是挑戰者,在線下監聽並在線上發起挑戰。
  4. Alice 輸入 x,運行 zk.prove 程序,得到結果 y 和證明 proof。Bob 根據 f、y 和 proof 運行 zk.verify 程序。如果結果為真,就不做任何事情;如果結果為假,Bob 就會挑戰 Alice,挑戰的程序是 zk.verify。Alice 和 Bob 之間的互動次數可以是一輪或多輪。通過挑戰-響應機制實現仲裁。這是一種欺詐證明,Bob 是挑戰者,在線下監聽並在線上發起挑戰。

對於上述 2、3 和 4,設 x 為 Layer2 交易和初始狀態,f 為 Layer2 共識程序,y 為交易的最終狀態,這與區塊鏈的 Layer2 擴展解決方案相對應。

  • 有效性證明:基於悲觀假設,必須在接受之前證明其有效性,並立即生效。在有效性證明中,必須提供正確的 L2 狀態轉換的證據,體現出對世界的悲觀看法——只有在狀態被證明正確時,才會被接受。
  • 欺詐證明:基於樂觀假設,默認情況下是被接受的,除非有人證明其不正確。它有一個挑戰窗口期,只有在挑戰窗口期結束後才生效。在欺詐證明中,必須提供不正確的 L2 狀態轉換的證據,體現出對世界的樂觀看法——狀態轉換被認為是正確的,除非有相反的證明。

表 1:建立信任的方法

另外,需要特別注意的是:

  • 區分欺詐證明和有效性證明的關鍵不在於是否使用像 SNARK 或 STARK 這樣的 ZK 證明系統。ZK 證明系統只是表達了所採用的證明方法,而欺詐或有效性則代表了證明的內容。因此,表 1 中的場景 1 被稱為有效性證明。
  • 有效性證明的時效性更好,但鏈上驗證的複雜性較高;而欺詐證明的鏈上驗證複雜性較低,但時效性較差。
  • 對於表 1 中的案例 2 和 4,通過使用 ZK 遞歸和組合技術,可以計算和壓縮多個 f,從而顯著降低鏈上對鏈下計算的驗證成本。

目前,得益於 Solidity 的圖靈完備智能合約,欺詐證明和有效性證明技術在以太坊的 Layer2 擴展中得到了廣泛應用。然而,在比特幣的框架下,由於比特幣的操作碼功能有限、棧元素數量僅為 1000 以及其他限制,這些技術的應用仍處於探索階段。本文總結了比特幣框架下的侷限性和突破性技術,研究了有效性證明和欺詐證明技術,並概述了比特幣框架下獨特的腳本分段技術。

2 比特幣範式下的侷限與突破

在比特幣的框架下存在許多侷限性,但可以通過各種巧妙的方法或技術來克服這些侷限性。例如,使用比特承諾可以突破 UTXO 的無狀態限制,Taproot 可以解決腳本空間的限制,連接器輸出可以克服 UTXO 消費方式的限制,而智能合約則可以突破預簽名的限制。

2.1 UTXO模型和腳本限制

比特幣採用 UTXO 模型,其中每個 UTXO 都被鎖定在一個鎖定腳本中,該腳本定義了消費該 UTXO 所需滿足的條件。比特幣腳本存在以下限制:

  1. 比特幣腳本是無狀態的;
  2. 對於 P2TR 輸出類型,單個交易中最多可以容納約 400 萬個操作碼,填滿整個區塊,而對於其他輸出類型,僅能使用 10,000 個操作碼;
  3. 單個 UTXO 的消費方式有限,缺乏對組合消費方式的探索;
  4. 不支持靈活的合約功能;
  5. 棧的大小限制為最多 1000 個元素(包括 altstack 和 stack),單個元素的最大大小為 520 字節;
  6. 算術操作(如加法和減法)限制為 4 字節元素,無法擴展為 20 字節或更大的長元素,這在加密操作中是必需的;
  7. 像 OPMUL 和 OPCAT 這樣的操作碼已被禁用,使用現有操作碼來模擬它們的成本極高,例如模擬一次 BLAKE3 哈希,腳本大小約為 75K。

2.2 比特承諾:突破UTXO無狀態限制

當前,比特幣腳本是完全無狀態的。在執行比特幣腳本時,每個腳本的執行環境在完成後會被重置。這使得比特幣腳本無法原生支持約束腳本 1 和 2 共享相同的 x 值。不過,這個問題可以通過一些方法來解決,核心思想是以某種方式對一個值進行簽名。如果能夠為一個值生成簽名,就能夠實現有狀態的比特幣腳本。換句話說,通過檢查腳本 1 和 2 中 x 值的簽名,可以確保在這兩個腳本中使用相同的 x 值。如果存在衝突的簽名,即對同一個變量 x 簽署了兩個不同的值,則可以施加懲罰。這種方法被稱為比特承諾。

比特承諾的原理相對簡單。每個比特都對應兩個不同的哈希值,hash0 和 hash1。如果待簽名的比特值為 0,則揭示 hash0 的前像;如果比特值為 1,則揭示 hash1 的前像。

以單個比特消息 m ∈ {0,1} 為例,相應的比特承諾解鎖腳本僅由一些前像構成:如果比特值為 0,則解鎖腳本為 preimage0——“0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140”;如果比特值為 1,則解鎖腳本為 preimage1——“0x47c31e611a3bd2f3a7a42207613046703fa27496”。因此,通過比特承諾,可以突破 UTXO 的無狀態限制,實現有狀態的比特幣腳本,進而使得各種有趣的新特性成為可能。

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // 這是hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // 這是hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// 現在比特承諾的值在棧上。可以是 "0" 或 "1"。

目前,比特承諾有兩種實現方式:

  • Lamport一次性簽名:Lamport 一次性簽名:Lamport 一次性簽名的原理相對簡單,僅需使用哈希函數,適合與比特幣兼容。對於消息中的每個比特,需要承諾兩個哈希值,這導致簽名數據相對較大。具體來說,對於長度為 v 比特的消息,公鑰長度為 2v 比特,而簽名長度為 v 比特。
  • Winternitz 一次性簽名:與 Lamport 簽名相比,Winternitz 簽名顯著減少了簽名和公鑰的長度,但增加了簽名和驗證的複雜性。該方案允許根據需要靈活設置不同的哈希鏈長度 d,從而在長度和複雜性之間取得平衡。例如,設置 d = 15 可以使公鑰和簽名長度縮短約 4 倍,但驗證的複雜性會增加 4 倍。這實際上是在比特幣的棧空間和腳本大小之間的權衡。當 d = 1 時,Lamport 簽名可以被視為 Winternitz 簽名的特例。

目前,BitVM2 庫實現了基於 Blake3 哈希函數的 Winternitz 簽名。對應於單個比特的簽名長度約為 26 字節。因此,可以看出,通過比特承諾引入狀態是有成本的。因此,在 BitVM2 的實現中,消息首先被哈希以獲得 256 位的哈希值,然後對該哈希值進行比特承諾,以節省開銷,而不是直接對原始較長消息的每個比特進行承諾。

2.3 Taproot:突破腳本空間限制

比特幣的 Taproot 軟分叉升級於 2021 年 11 月激活,包含三個提案:Schnorr 簽名(BIP 340)、Taproot(BIP 341)和 TapScript(BIP 342)。該升級引入了一種新的交易類型——Pay-to-Taproot(P2TR)交易。通過結合 Taproot、MAST(Merkel 抽象語法樹)和 Schnorr 簽名的優勢,P2TR 交易能夠創建更私密、更靈活且可擴展的交易格式。

P2TR 支持兩種支出方式:通過密鑰路徑或腳本路徑進行支出。根據 Taproot(BIP 341)的規定,當通過腳本路徑支出時,相應的 Merkle 路徑長度不能超過 128。這意味著 taptree 中的 tapleaf 數量不能超過 2^128。自 2017 年 SegWit 升級以來,比特幣網絡以權重單位衡量區塊大小,最大支持 400 萬權重單位(約 4MB)。當 P2TR 輸出通過腳本路徑支出時,僅需揭示一個單一的 tapleaf 腳本,這意味著區塊中只包含一個 tapleaf 腳本。因此,對於 P2TR 交易,每個 tapleaf 對應的腳本大小最大可達約 4MB。然而,根據比特幣的默認政策,許多節點只轉發小於 400K 的交易;更大的交易需要與礦工合作進行打包。

Taproot 帶來的腳本空間溢價使得使用現有操作碼模擬諸如乘法和哈希等密碼學操作變得更加有價值。在基於 P2TR 構建可驗證計算時,腳本大小不再受 4MB 限制,而可以拆分為多個子功能,分佈在多個 tapleaf 中,從而突破 4MB 的腳本空間限制。實際上,當前 BitVM2 中實現的 Groth16 驗證器算法的大小高達 2GB。然而,它可以被拆分並分佈在大約 1000 個 tapleaf 中,並通過與比特承諾相結合,約束每個子功能的輸入和輸出之間的一致性,從而確保整個計算的完整性和正確性。

2.4 連接器輸出:突破 UTXO 支出方式限制

目前,比特幣為單個未花費交易輸出(UTXO)提供兩種原生支出方式:通過腳本或公鑰支出。因此,只要滿足正確的公鑰簽名或腳本條件,UTXO 就可以被支出。兩個 UTXO 可以獨立支出,且不能添加限制來約束這兩個 UTXO,這意味著必須滿足額外條件才能支出它們。

然而,Ark 協議的創始人 Burak 聰明地利用 SIGHASH 標誌實現了連接器輸出。具體來說,Alice 可以創建一個簽名將她的 BTC 發送給 Bob。由於簽名可以承諾多個輸入,Alice 可以將她的簽名設為條件:只有在第二個輸入被消耗時,Taketx 交易的簽名才是有效的。第二個輸入被稱為連接器,它將 UTXO A 和 UTXO B 連接起來。換句話說,Taketx 交易只有在 UTXO B 沒有被 Challengetx 消耗時才是有效的。因此,通過銷燬連接器輸出,可以阻止 Taketx 交易的有效性。

圖 1:連接器輸出示意圖

在 BitVM2 協議中,連接器輸出起到 if…else 函數的作用。一旦連接器輸出被某個交易支出,它就無法被其他交易再次支出,從而確保其獨佔性。在實際部署中,為了允許挑戰-響應週期,引入了帶時間鎖的額外 UTXO。此外,連接器輸出還可以根據需要設置不同的支出策略,例如在挑戰交易的情況下允許任何一方支出,而在響應交易的情況下僅允許操作員支出或在超時後允許任何人支出。

2.5 合約:突破預簽名限制

目前,比特幣腳本主要限制解鎖條件,而不限制未花費交易輸出(UTXO)如何進一步支出。這是因為比特幣腳本無法讀取交易本身的內容,無法實現對交易的自省。如果比特幣腳本能夠檢查交易的任何內容(包括輸出),那麼就能實現合約功能。

當前的合約實現可以分為兩類:

  • 預簽名:基於現有的比特幣腳本能力,通過預簽名構建有限功能的預定合約。這意味著參與者需要提前設計並簽署所有可能的未來交易,從而將其鎖定在特定的私鑰和費用率上。一些方案甚至要求參與者為所有預簽名交易生成短期私鑰。一旦預簽名完成,這些短期私鑰會被安全刪除,以防止攻擊者獲取並盜取資金。然而,每當添加新參與者或更新操作時,這一過程需要重複,導致高維護成本。例如,閃電網絡通過預簽名實現雙方合約,並使用哈希時間鎖合約(HTLC)技術實現多個雙方合約的路由功能,從而實現信任最小化的擴展策略。然而,閃電網絡需要預簽名多個交易,並且僅限於兩方,這使得其使用起來顯得繁瑣;在 BitVM1 中,每次初始化需要預簽名數百個交易,而在優化後的 BitVM2 中,每次初始化需要預簽名的交易數量也達到幾十個。在 BitVM1 和 BitVM2 中,只有參與預簽名的操作員有資格獲得報銷。如果有 n 個參與者參與預簽名,每個參與者需要預簽名 m 個交易,那麼每個參與者的預簽名複雜度將是 n * m。
  • 引入合約操作碼:引入新的合約功能操作碼可以顯著降低合約參與者之間的通信複雜性和維護成本,從而為比特幣提供一種更靈活的合約實現方式。例如,OPCAT 操作碼用於連接字節字符串。儘管其功能簡單,但卻非常強大,能夠顯著降低 BitVM 的複雜性;OPTXHASH 操作碼則允許對合約內的操作進行更細緻的控制。如果在 BitVM 中使用,可以支持更大範圍的操作符,從而顯著提高 BitVM 的安全性並最小化信任。此外,預簽名方法本質上意味著 BitVM 中的操作員只能採用報銷流程,這導致資本利用效率較低;而通過新的合約操作碼,可能可以直接從 peg-in 資金池支付給輸出用戶,進一步提高資本效率。因此,靈活的合約模型將有效突破傳統的預簽名限制。

3 比特幣 Layer2 擴容:有效性證明和欺詐證明

有效性證明和欺詐證明都可以用於比特幣的 Layer2 擴展,其主要區別見表 2。

表 2:有效性證明與欺詐證明

基於比特承諾、Taproot、預簽名和連接器輸出,可以構建基於比特幣的欺詐證明。同時,通過引入合約操作碼(例如 OP_CAT),也可以基於 Taproot 構建比特幣的有效性證明。此外,欺詐證明還可以根據 Bob 是否有入場系統分為許可欺詐證明和無許可欺詐證明。在許可欺詐證明中,只有特定群體能夠作為 Bob 發起挑戰,而在無許可欺詐證明中,任何第三方都可以作為 Bob 發起挑戰。無許可欺詐證明的安全性優於許可欺詐證明,因為它降低了參與者之間勾結的風險。

根據 Alice 和 Bob 之間的挑戰-響應交互次數,欺詐證明可以分為單輪欺詐證明和多輪欺詐證明,如圖 2 所示。

圖 2:單輪欺詐證明與多輪欺詐證明

如表 3 所示,欺詐證明可以通過不同的交互模型實現,包括單輪交互模型和多輪交互模型。

表 3:單輪交互與多輪交互

在比特幣的 Layer2 擴展範式中,BitVM1 採用多輪欺詐證明機制,而 BitVM2 則採用單輪欺詐證明機制,bitcoin-circle stark 則利用有效性證明。在這幾種機制中,BitVM1 和 BitVM2 可以在不修改比特幣協議的情況下實現,而 bitcoin-circle stark 則需要引入新的操作碼 OP_CAT。

對於大多數計算任務,比特幣的 signet、testnet 和 mainnet 無法完全支持 4MB 的腳本,因此需要使用腳本拆分技術,即將完整的計算腳本拆分為小於 4MB 的塊,並分佈在不同的 Tapleaf 中。

3.1 比特幣多輪欺詐證明

如表 3 所示,多輪欺詐證明適合那些希望減少鏈上仲裁計算,或無法一步定位問題計算段的情況。多輪欺詐證明顧名思義,需要證明者和驗證者之間進行多輪交互,以找到問題計算段,然後根據這些段進行仲裁。

Robin Linus 的早期 BitVM 白皮書(通常稱為 BitVM1)採用了多輪欺詐證明。假設每個挑戰期持續一週,並使用二分搜索方法來定位問題計算段,Groth16 驗證器的鏈上挑戰響應期可能會延長至 30 周,導致時效性差。雖然目前有團隊在研究比二分搜索更高效的 n-ary 搜索方法,但其時效性仍顯著低於單輪欺詐證明的 2 週週期。

目前,比特幣中的多輪欺詐證明使用許可挑戰,而單輪欺詐證明則實現了無許可挑戰方法,從而降低了參與者之間勾結的風險,增強了安全性。為此,Robin Linus 充分利用了 Taproot 的優勢來優化 BitVM1,不僅將交互輪數減少到一輪,還將挑戰方法擴展為無許可方式,儘管這增加了鏈上仲裁計算的成本。

3.2 比特幣的一輪欺詐證明

在這種模型中,欺詐證明的驗證只需證明者和驗證者之間進行一次交互。驗證者只需發起一次挑戰,而證明者只需迴應一次。在迴應中,證明者必須提供證據,證明他們的計算是正確的。如果驗證者在證據中發現不一致之處,則挑戰成功;否則,挑戰失敗。單輪交互欺詐證明的特徵如表 3 所示。

圖 3:單輪欺詐證明

2024年8月15日,Robin Linus 發佈了《BitVM2:將比特幣連接到第二層》的技術白皮書,其中實現了一種跨鏈橋,採用了類似於圖 3 所示的單輪欺詐證明方法。

3.3 使用 OP_CAT 的比特幣有效性證明

OP_CAT 是比特幣發佈時腳本語言的一部分,但因安全漏洞在2010年被禁用。儘管如此,比特幣社區多年來一直在討論重新啟用 OP_CAT 的可能性。目前,OP_CAT 被分配了編號 347,並已在比特幣的 signet 網絡上啟用。

OP_CAT 的主要功能是將堆棧中的兩個元素合併,並將結果推回堆棧。這一功能為比特幣上的合約和 STARK 驗證器提供了新的可能性:

  • 合約:Andrew Poelstra 提出了 CAT 和 Schnorr Tricks I,利用 OP_CAT 和 Schnorr 技術在比特幣上實現合約。Schnorr 算法是一種適用於 P2TR 輸出類型的數字簽名;對於其他輸出類型,可以使用類似的 ECDSA 技術,例如在使用 CAT 和 ECDSA 的契約中所示。藉助 OP_CAT 合約,STARK 驗證器算法可以分解成多個交易,逐步驗證整個 STARK 證明。
  • STARK 驗證器:STARK 驗證器的主要功能是將數據連接在一起並進行哈希。與代數運算不同,哈希是比特幣腳本中的一種原生操作,可以顯著減少開銷。例如,OPSHA256 在原生形式中是一個單獨的操作碼,而模擬版本則需要數百個操作碼。STARK 中的主要哈希操作包括驗證 Merkle 路徑和 Fiat-Shamir 轉換。因此,OP_CAT 對 STARK 驗證器算法非常友好。

3.4 比特幣腳本拆分技術

儘管在 SNARK/STARK 證明後,驗證證明所需的計算負載遠低於直接運行原始計算 f 的負載,但在將其轉換為比特幣腳本以實現驗證器算法時所需的腳本量依然龐大。目前,基於現有的比特幣操作碼,優化後的 Groth16 和 Fflonk 驗證器腳本的大小均超過 2GB,而單個比特幣區塊的大小僅為 4MB,因此無法在單個區塊內運行整個驗證器腳本。然而,自 Taproot 升級以來,比特幣支持通過 tapleaf 執行腳本,這使得驗證器腳本可以拆分為多個塊,每個塊作為一個 tapleaf 來構建 taptree。塊之間的一致性可以通過位承諾來保證。

在 OP_CAT 合約的情況下,STARK 驗證器可以拆分為多個小於 400KB 的標準交易,從而使整個 STARK 有效性證明的驗證可以在不需要與礦工合作的情況下完成。

本節將重點介紹在現有條件下比特幣腳本的拆分技術,而不引入或激活任何新的操作碼。

在進行腳本拆分時,需要平衡以下幾個方面的信息:

  • 單個塊的腳本大小不得超過 4MB,並應包括輸入位承諾腳本、交易簽名等其他內容。
  • 單個塊的最大棧大小不得超過 1000。因此,每個塊的棧應僅保留必要的元素,以確保有足夠的棧空間進行腳本大小優化,因為比特幣的交易費用與棧大小無關。
  • 在比特幣上,位承諾的成本較高。因此,應儘量減少兩個相鄰塊之間的輸入和輸出位數,目前 1 位對應 26 字節。
  • 為了方便審計,每個塊的功能應儘可能清晰。

目前,腳本拆分的方法可以分為以下三類:

  • 自動拆分:該方法尋求一種拆分方式,使腳本大小約為 3MB,並在棧大小和腳本大小的基礎上最小化棧大小。其優點是獨立於特定的驗證器算法,能夠擴展到任何計算的腳本拆分。缺點包括:(1) 整個邏輯塊必須單獨標記,例如不能拆分的 OP_IF 代碼塊;否則,拆分腳本的執行結果可能會錯誤;(2) 塊的執行結果可能對應於棧上的多個元素,需要根據實際計算邏輯標記需要應用位承諾的棧元素數量;(3) 每個塊腳本的邏輯功能可讀性差,審計困難;(4) 棧中可能包含下一個塊不需要的元素,浪費棧空間。
  • 功能拆分:該方法根據計算中的功能子函數進行拆分,明確子函數的輸入和輸出。在拆分腳本的同時,為每個塊實現必要的位承諾腳本,確保最終塊的總腳本大小小於 4MB,棧大小小於 1000。優點是功能明確、邏輯清晰、可讀性好,便於審計。缺點是原始計算邏輯可能與腳本級邏輯不匹配,原始子函數可能是最佳的,但不一定代表腳本級的最佳性。
  • 手動拆分:該方法的拆分點不是基於功能子函數,而是手動設置。這種方法特別適合單個子函數大小超過 4MB 的情況。優點是允許手動拆分大型腳本子函數,如與 Fq12 計算相關的子函數;每個塊邏輯清晰、可讀性強,便於審計。缺點是受限於手動調優能力,整體腳本優化後,之前設置的手動拆分點可能不再最佳,需要重新調整。

例如,經過多輪優化,Groth16 驗證器的腳本大小已從約 7GB 降低至大約 1.26GB。除了整體的計算優化外,每個塊也可以進行單獨優化,以充分利用棧空間。例如,通過引入更高效的查找表算法,並動態加載和卸載查找表,可以進一步減小每個塊的腳本大小。

由於 Web2 編程語言的計算成本和運行環境與比特幣腳本截然不同,因此簡單地將現有算法實現轉換為比特幣腳本並不可行。因此,需要考慮針對比特幣場景的特定優化:

  • 尋找能夠優化內存局部性的算法,即使這可能會增加一些計算負擔,以減少塊之間的輸入/輸出位數,從而降低 BitVM2 的 assertTx 交易設計中對承諾所需的數據量。
  • 利用相關操作的交換性(例如,邏輯運算),如 x&y = y&x,來節省近一半的查找表空間。
  • 目前,Fq12 操作的腳本大小較大;可以考慮使用 Fiat-Shamir、Schwartz-Zipple 和多項式承諾方案,以顯著降低 Fq12 擴展操作的計算複雜性。

4 總結

本文首先探討了比特幣腳本的侷限性,並討論了幾種解決方案:利用比特幣承諾克服 UTXO 的無狀態限制,使用 Taproot 以突破腳本空間的限制,通過連接輸出繞過 UTXO 支出方法的限制,以及通過合約來解決預簽名的限制。接著,文章對欺詐證明和有效性證明的特徵進行了全面的概述,包括許可與無許可欺詐證明的特點、一輪與多輪欺詐證明的區別,以及比特幣腳本拆分技術的相關內容。

聲明:

  1. 本文轉載自[aicoin],著作權歸屬原作者[mutourend & lynndell, Bitlayer Labs],如對轉載有異議,請聯繫Gate Learn團隊,團隊會根據相關流程儘速處理。
  2. 免責聲明:本文所表達的觀點和意見僅代表作者個人觀點,不構成任何投資建議。
  3. 文章其他語言版本由Gate Learn團隊翻譯, 在未提及Gate.io的情況下不得複製、傳播或抄襲經翻譯文章。
查看原文
本頁面內容僅供參考,非招攬或要約,也不提供投資、稅務或法律諮詢。詳見聲明了解更多風險披露。
  • 讚賞
  • 留言
  • 分享
留言
0/400
暫無留言
交易,隨時隨地
qrCode
掃碼下載 Gate APP
社群列表
繁體中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)