議程

問題

1. 定義終態：使加密應用程序“可用”的特徵

2. 爲什麼“鏈抽象”是解決由模塊化區塊鏈的基本拓撲結構引起的用戶體驗問題的解決方案

3. 爲什麼可用的加密應用程序必須建立在鏈抽象基礎設施之上

解決方案空間

1. 意圖驅動的架構如何導致鏈抽象的出現

2. 了解到意圖市場在求解者網路龐大且競爭激烈時表現最佳

3. 引導意圖求解者網路的啓動需要吸引更多能產生意圖的應用程序

提案

1. 爲什麼我們需要一個優先考慮“求解者用戶體驗”的跨鏈意圖標準，以便將求解者和意圖市場發展到足夠大的規模，以實現網路效應

如果沒有鏈抽象，就無法構建可用的加密應用程序

我們最優秀、最聰明的人是否在建造冗餘基礎設施？

許多人對最優秀的加密工程師和最具思想深度的人過度關注爲終端用戶提供更多的區塊空間表示遺憾。這種批評有一定道理；與對其需求相比，現有的L2層對終端用戶來說過多了。

然而，我不認同沒有任何有用的加密應用程序存在的觀點。

去中心化金融爲個人提供了自行托管數字資產的能力，使他們能夠繞過嚴苛的服務提供商，並使用數字資產購買實物世界中的價值物品。自我托管數據的承諾也爲越來越不信任FAANG壟斷企業來保護其數據安全的個人提供了一種烏托邦式的選擇。

在我看來，真正的問題不是缺乏有用的加密應用程序，而是終端用戶嘗試訪問它們時遇到的摩擦。當與加密應用程序交互時，終端用戶應該能夠體驗到以下內容：

速度：應用程序應該感覺像web2應用程序一樣快速。

成本：與web2不同，所有web3交互必須產生一定成本，但“每次點擊”的成本應該可以忽略不計。

抗審查性（“無需許可性”）：任何擁有錢包的人都應該能夠與應用程序交互，如果他們有能力點擊的話。

安全性：點擊應該按照用戶的預期執行，而不應該發生逆轉—所有web3更新應該是永久性的。

這些是“可用”的加密應用程序的特性。

我們已經嘗試構建可用的加密應用程序很長一段時間了

如今的模塊化區塊鏈解決方案向消費者提供了所有這些特性，但它們並不都在同一個地方可用。

在2020年，區塊鏈是單體化的，爲終端用戶提供了三種特性中的兩種：速度、成本或安全性。然後，我們設想了一個以Rollup爲中心或模塊化的未來，可以同時實現這三個特性。

如今，我們已經建立了這種以Rollup爲中心的基礎設施的基礎。L2提供了廉價且快速的區塊空間，其中大多數提供了無需許可的區塊空間。相反，L1提供了WW3抵抗、安全的區塊空間。（您可以閱讀我關於L1和L2提供的安全性與用戶體驗之間的權衡的短期調查文章了解更多）。這些L2通過規範的消息路徑與L1安全連接，爲一個模塊化但可互操作的網路打下了基礎。在過去的四年裏，我們建立了連接區塊鏈的光纖，有一天將支持有用的加密應用程序。但爲什麼模塊化區塊鏈如此難以使用呢？

模塊化區塊鏈網路的必然性在於，資本資產將會積累在最安全的層上，而用戶點擊將會積累在更快速和更便宜的層上。

模塊化區塊鏈拓撲鼓勵安全的區塊空間在不同的層上提供，而廉價和快速的區塊空間則在另一層上提供。用戶自然會更傾向於在最安全的網路上存儲他們的價值，但他們會要求更頻繁地與廉價和快速的網路進行交互。根據設計，L2與L1之間的規範路徑是緩慢和/或昂貴的。這些現象解釋了爲什麼用戶必須通過這些規範路徑使用L1資產來支付L2交互。這導致了“不可用”的加密用戶體驗。

維塔利克對不同類型的L2的看法

鏈抽象的目標是減少將價值發送到協議路徑中的摩擦，遠離用戶。鏈抽象者假設用戶更傾向於將其期望的最終狀態指定給dapp爲“意圖”，而dapp有責任實現他們的意圖。用戶不應該爲了獲得低費用和低延遲而犧牲對其資產的安全托管。

因此，鏈抽象在很大程度上取決於用戶能夠安全、廉價、快速地在網路之間傳輸價值。如今的一個常見用戶流程是，一個在“安全”鏈上（如以太坊）擁有USDC餘額的用戶希望在像Blast或Base這樣的新鏈上鑄造NFT或交換新代幣。在盡可能少的步驟中執行此操作的方法是依次執行一系列橋接→交換→鑄造交易（或交換→橋接→鑄造）。

在這個例子中，用戶的意圖是使用他們在安全鏈上的USDC來在另一個鏈上鑄造NFT。只要他們收到了NFT，並且選擇了托管的地方扣除了他們的USDC餘額，用戶就會感到滿意。

意圖驅動的架構是構建鏈抽象的唯一方式

鏈抽象依賴於跨鏈價值轉移，但通過規範消息路徑發送價值要麼昂貴要麼緩慢。 “快速橋梁” 爲用戶提供了在網路之間發送價值的廉價且快速的替代方案，但它們引入了新的信任假設。消息傳遞是構建快速橋梁的最直觀方式，因爲它是基於TCP/IP架構建模的；它依賴於一個橋協議充當TCP路由器來連接兩個鏈。

來自 ResearchGate 的 TCP/IP 圖表

通過消息傳遞進行價值轉移涉及橋協議在源鏈和目標鏈上的合約之間發送消息。此消息由用戶交易在源端觸發，並在消息的“有效性”驗證後中繼到目標端。

只有在發起消息的源鏈交易已經完成，也就是說，該交易已經永久地包含在源鏈的規範區塊鏈中，消息才能被驗證。此驗證可以完成爲有效性證明，證明了交易在源鏈上的共識包含，作爲一個樂觀的提案，或者在源端已經累積了一定數量的證人籤名來證明其被包含。一旦消息被中繼到目標鏈上的橋合約，代幣就會釋放給用戶。

這種架構存在幾個根本性問題：

驗證機制必須等待完全的最終性才能將消息發送到目標鏈的協議合約。對於具有樂觀最終性週期的L2，這可能需要長達七天的時間。

每個橋交易只發送一個跨鏈消息，或者消息被批量發送，但是批量只能在批次中的最後一個消息被最終化後發送。

橋僅能有限地獲取外部流動性以提供用戶價格改進，因爲它必須對用戶意圖的實現路徑進行聲明。

基於上述見解，消息傳遞快速橋梁將會根據驗證機制的不同而存在不安全、緩慢或昂貴的問題。意圖市場是一種快速橋梁的替代架構，它來源於一個關鍵的洞見：

價值是可替代的，對於接收者來說，價值是如何轉移的並不重要，只要他們收到了資金

一個橋梁可以將價值轉移外包給一個復雜的代理來獲得速度和降低成本嗎？流動性在鏈上和鏈下是動態變化的，如果橋梁機制有靈活性在橋梁轉移時選擇最優執行路徑，那麼價格改進是可以實現的。

意圖機制允許用戶指定在其價值轉移交易執行時的精確條件或契約。

一個最小可行的意圖是從鏈A支付X令牌以在鏈B上接收Y令牌的訂單。

橋梁協議不需要在每次橋交易中在域之間發送消息來執行用戶的跨域意圖。相反，該協議將價值轉移外包給一個從無需許可的求解者網路中選取的代理，並且個別求解者將在稍後向橋梁協議尋求償還。相比之下，消息傳遞機制明確指定了它們的交易應該如何執行，而不需要依賴於代理的可用性。

意圖結算協議

意圖結算協議可以更準確地標記爲意圖結算協議，其負責確保求解者不違反用戶指定的條件。意圖結算協議爲求解者提供了保障，確保他們在履行用戶意圖時能夠獲得償還和獎勵。爲此，意圖結算協議需要向oracle申請驗證意圖履行的真實性。Oracle的安全性可以基於樂觀的挑戰期、見證閾值或者基於零知識有效性證明等方式。

意圖結算協議提供了快速和廉價的價值轉移，因爲個別求解者可以承擔最終性風險並確定最佳執行路徑

消息傳遞橋梁只能在起始鏈達到最終性時進行通信。樂觀Rollups的最終性時間爲七天，ZK Rollups爲一小時。盡管隨着更廣泛地採用ZK輕客戶端技術和共享排序預確認技術的推進，

些最終性時間應該會趨向下降，但所有區塊鏈的最終性時間都不太可能對用戶來說感覺“即時”，這表明了對快速橋接解決方案的持續需求。除非橋梁願意在中繼路徑中添加一個額外的可信代理來彌補由於鏈重組而造成的損失，否則在不承擔最終性風險的前提下，消息傳遞橋梁無法比最終性期限更快地中繼消息。

意圖驅動架構提供的加速是因爲異構求解者網路中的個別求解者可以承擔比消息傳遞協議更多的最終性風險，並在鏈重組風險完全消失之前完成用戶的意圖。求解者隨後會向用戶收取他們爲加速交易時間而承擔的最終性風險。

將跨鏈意圖履行外包給代理也平均會爲用戶帶來價格改進。在意圖驅動的橋梁中，前置用戶訂單到期望的目標鏈上的求解者將在其履行驗證後由系統返還。這些意圖結算可以批量處理以分攤成本。與用戶不同，填充者不會要求即時償還，而會根據前置資本向用戶收取相應的費用。批量結算並不是意圖驅動架構的獨有特性，但是該架構與批量結算更加協同，因爲它將償還步驟與意圖履行步驟分開。

價格改進的更大來源來自於價值可替代的直覺，及時找到最佳路徑通常會優於價值轉移。（然而，有些路徑在即時情況下不可能擊敗成本，比如在跨越CCTP時轉移USDC。）

消息傳遞橋梁必須編碼如何將價值轉移給用戶。一些選擇以預定的匯率從流動性池中發送代幣，而其他人則爲需要隨後交換爲期望的規範代幣資產的接收方鑄造代表性代幣。

在履行用戶意圖時，代理可以從鏈上和鏈下的流動性場所組合提供流動性。競爭激烈的求解者網路理論上爲用戶提供了無限的流動性來源（但是即使這些流動性來源也可能在高波動性的鏈上事件中快速耗盡，比如熱門NFT鑄造、空投和拉盤）。

將跨鏈訂單提交爲意圖使求解者可以內部化訂單產生的MEV作爲價格改進。

意圖驅動架構基本上是設計爲安全的。

基於意圖的橋梁可以建立安全，因爲它們將用戶的緊急需求與結算網路的復雜需求分開。求解者可以等待償還，而不像用戶那樣急切，他們將根據結算協議讓他們等待償還的時間向用戶收費。因此，意圖結算可以使用非常健壯的機制進行驗證，而無需嚴格的時間限制。從安全性的角度來看，這是可取的，因爲驗證意圖履行在直觀上是復雜的。

作爲生產中意圖驗證的一個例子，Across 在一個90分鍾的樂觀挑戰期後批量驗證和償還填充者。當然，結算網路應該努力盡快償還填充者，以減少最終用戶的費用。對樂觀挑戰機制的改進將是ZK有效性證明機制，它將需要將意圖驗證邏輯編碼到一個ZK電路中。在我看來，必然會發生的是，有效性證明機制將取代樂觀挑戰機制，並使意圖結算網路能夠更快地償還用戶。

所以，鏈抽象是如何從基於意圖的架構中產生的呢？

回顧一下，鏈抽象需要快速且廉價的跨鏈價值轉移。同時，它也不應要求用戶在存儲其資產的網路上提交鏈上交易。

如果用戶的意圖包含 Permit2 或 EIP3074 籤名，用戶就不需要在鏈上提交意圖。這對於消息傳遞和基於意圖的橋梁都是適用的。這兩種架構都可以利用 Permit2 模式，允許用戶在鏈下籤署他們願意從原始鏈錢包支付的代幣數量。

意圖市場最能支持鏈抽象，因爲它們提供了廉價且快速的跨鏈價值轉移。想象一下，一個用戶可以請求求解者給他們一個報價，以使用其在 Optimism 上的 USDC 進入 Arbitrum 上的 WETH 抵押頭寸，作爲支付。用戶可以將這個意圖發送到一個 RFQ 拍賣，在那裏求解者可以對其進行競標。拍賣的獲勝求解者隨後可以收到用戶的籤署意圖，其中包含了允許在 Optimism 上花費他們的 USDC、在 Arbitrum 上收到的 WETH 的數量以及用於將此 WETH 存入 Arbitrum 抵押頭寸所需的 calldata。求解者隨後可以在 Optimism 上提交此交易（代表用戶）來啓動跨鏈意圖並從用戶的 Optimism 錢包中提取 USDC。最後，求解者可以通過向用戶發送 WETH 並將 calldata 轉發到用戶的鏈上抵押頭寸，來填充用戶在 Arbitrum 上的意圖。

構建鏈抽象基礎設施意味着使這個用戶流程感覺即時且廉價，而無需他們提交鏈上交易。讓我們通過討論更廣泛採用意圖的障礙來結束這篇文章。

Across 的意圖架構

要實現基於意圖的鏈抽象的最佳用戶體驗，我們需要一個競爭激烈的求解者網路

使用意圖進行橋接取決於求解者網路效應，以表現出比消息傳遞變體更好的性能。這是意圖與消息傳遞架構之間的核心權衡。現實情況是，並非所有產生意圖的應用都需要訪問一個完全競爭的求解者集合，有些可能更傾向於將他們的意圖路由到寡頭求解者網路。然而，當前的求解者網路狀態尚不成熟，遠未達到意圖市場所依賴的求解者網路活躍性的假設。

我們不希望看到每個 DApp 都將意圖路由到孤立的求解者網路的世界。最理想的用戶體驗情況是，許多 DApp 與同一求解者池進行通信，並且所有 DApp 都有自由更改它們發送意圖的求解者池。

我們如何引導求解者網路的啓動？

我們必須優先考慮求解者用戶體驗。

運行意圖求解器是復雜的，需要在構建高性能軟件和管理跨鏈庫存風險方面具有專業知識。自然而然地，只有少數利益相關方願意支付運行此代碼的啓動成本。在最理想的情況下，爲一個DApp編寫的求解器，比如UniswapX求解器，可以被重新利用來解決其他產生意圖的DApp，如Across和CowSwap。

我們真的需要增加所有基於意圖的DApp的求解者網路的總體資本效率。這將需要解決運行求解器的障礙。

爲此，我們需要確保產生意圖的DApp對任何求解者可見，並確保所有求解者都能夠訪問多樣化和競爭激烈的意圖結算網路。這將使求解者有信心選擇將他們的意圖履行路由到他們信任的結算網路。結算網路之間的競爭也會降低求解者的成本。

意圖結算網路的價值主張是爲求解者提供安全性以及影響求解者履行意圖能力的其他功能。

求解者選擇的意圖結算網路將影響他們向用戶提供費用和執行時間保證的能力。一些結算網路可能會提供求解者獨佔期，這將支持在鏈下拍賣中進行開發，求解者和用戶可以在其中進行協商並承諾中繼費用。（這些意圖拍賣可能還提供經濟保證的預確認，進一步增強用戶體驗。要了解更多關於通過拍賣和預確認發現意圖的用戶流程，我推薦觀看 Sorella 的 Karthik 的這個演講。）

一些結算網路可能會提供意圖到期（即，在達到某個履行截止日期後將價值發送回用戶）、意圖擔保（即，如果沒有求解者履行意圖，結算網路將使用自己的資產表來履行用戶的意圖）或靈活的償還鏈（即，允許求解者選擇他們想要償還的鏈）。

最終，結算網路將競相快速、廉價地償還求解者，而不會影響安全性。作爲回報，求解者將把他們的訂單流發送到那些允許他們向用戶提供最便宜費用的結算網路，以便贏得DApp的訂單流。結算和求解者網路的競爭取決於意圖供應鏈中的所有各方協調一致，競爭將爲跨鏈價值轉移帶來最佳用戶體驗。

很明顯，我們需要一個跨鏈意圖的標準

如果求解者可以假設意圖具有共同的要素，那麼他們就可以重用他們的代碼來解決由不同DApp發起的意圖，並隨後降低他們的設置成本。如果不同的DApp創建的意圖符合同一標準，那麼它們都可以將意圖路由到同一求解者池。這將通過爲它們提供將其跨鏈意圖直接插入現有成熟的求解者池的能力，幫助引入下一代DApp。新的DApp不需要單獨引入求解者，而是可以獲得廉價、快速、安全和無權限的價值轉移。

如果它們符合標準，第三方跟蹤軟件也更容易跟蹤任何新DApp的意圖狀態。

這個意圖標準應該允許意圖的委托方或求解者指定他們希望在哪個結算網路上結算他們的意圖

我設想競爭的結算協議，如SUAVE、Across、Anoma和Khalani，爲意圖求解者提供差異化的功能。根據哪個結算網路向求解者償還，求解者可以向意圖所有者提供不同的價格和時間保證。DApp和求解者可以同意將用戶的意圖路由到他們信任的結算網路，以避免審查、保持數據隱私，並且足夠安全，可以信任償還求解者。

通過將結算網路的選擇寫入意圖訂單本身，求解者可以將這種確定性融入他們向用戶展示的報價中。求解者和用戶可以在提交意圖鏈上之前消除有關橋梁定價的前期不確定性，從而降低成本。

在與Uniswap合作，並根據CAKE工作組的反饋，Across和我提議以下跨鏈意圖標準，重點是求解者用戶體驗：

/// @title CrossChainOrder type

/// @notice Standard order struct to be signed by swappers, disseminated to fillers, and submitted to settlement contracts

struct CrossChainOrder {

/// @dev The contract address that the order is meant to be settled by.

/// Fillers send this order to this contract address on the origin chain

address settlementContract;

/// @dev The address of the user who is initiating the swap,

/// whose input tokens will be taken and escrowed

address swapper;

/// @dev Nonce to be used as replay protection for the order

uint256 nonce;

/// @dev The chainId of the origin chain

uint32 originChainId;

/// @dev The timestamp by which the order must be initiated

uint32 initiateDeadline;

/// @dev The timestamp by which the order must be filled on the destination chain

uint32 fillDeadline;

/// @dev Arbitrary implementation-specific data

/// Can be used to define tokens, amounts, destination chains, fees, settlement parameters,

/// or any other order-type specific information

bytes orderData;

}

該標準旨在使求解者的工作更加簡單。它做出的一個有主觀色彩的選擇是，使用 Permit2/EIP3074 本地支持 nonce 和 initiateDeadline，並爲填充器提供一些保證，比如他們將從結算網路獲得的退款金額以及他們可以追蹤的用戶意圖的格式。此外，標準中定義了一個關鍵的 initiate 函數，允許填充器（即將訂單上鏈的人）在鏈上指定額外的“fillerData”，這是用戶在籤署 CrossChainOrder 時不會知道的信息。這使得填充器可以確保他們會因提交用戶的元交易而獲得結算合同的獎勵，並設置還款特定信息，如還款鏈。

該標準還旨在使 DApp 更容易跟蹤意圖履行狀態的整個生命週期。任何實現此標準的結算合約都應創建一個自定義子類型 ResolvedCrossChainOrder，可以從任意的 orderData 字段中解析出來。這可能包括涉及交換的代幣、目標鏈以及其他履行約束的信息。標準中還包含了一個 resolve 函數，使 DApp 能夠了解如何向用戶顯示意圖狀態，並讓求解者知道他們正在處理的確切意圖訂單結構。

/// @title ResolvedCrossChainOrder type

/// @notice An implementation-generic representation of an order

/// @dev Defines all requirements for filling an order by unbundling the implementation-specific orderData.

/// @dev Intended to improve integration generalization by allowing fillers to compute the exact input and output information of any order

struct ResolvedCrossChainOrder {

/// @dev The contract address that the order is meant to be settled by.

address settlementContract;

/// @dev The address of the user who is initiating the swap

address swapper;

/// @dev Nonce to be used as replay protection for the order

uint256 nonce;

/// @dev The chainId of the origin chain

uint32 originChainId;

/// @dev The timestamp by which the order must be initiated

uint32 initiateDeadline;

/// @dev The timestamp by which the order must be filled on the destination chain(s)

uint32 fillDeadline;

/// @dev The inputs to be taken from the swapper as part of order initiation

Input[] swapperInputs;

/// @dev The outputs to be given to the swapper as part of order fulfillment

Output[] swapperOutputs;

/// @dev The outputs to be given to the filler as part of order settlement

Output[] fillerOutputs;

}

/// @notice Tokens sent by the swapper as inputs to the order

struct Input {

/// @dev The address of the ERC20 token on the origin chain

address token;

/// @dev The amount of the token to be sent

uint256 amount;

}

/// @notice Tokens that must be receive for a valid order fulfillment

struct Output {

/// @dev The address of the ERC20 token on the destination chain

/// @dev address(0) used as a sentinel for the native token

address token;

/// @dev The amount of the token to be sent

uint256 amount;

/// @dev The address to receive the output tokens

address recipient;

/// @dev The destination chain for this output

uint32 chainId;

}

A compliant settlement contract implementation MUST implement the ISettlementContract interface:

/// @title ISettlementContract

/// @notice Standard interface for settlement contracts

interface ISettlementContract {

/// @notice Initiates the settlement of a cross-chain order

/// @dev To be called by the filler

/// @param order The CrossChainOrder definition

/// @param signature The swapper's signature over the order

/// @param fillerData Any filler-defined data required by the settler

function initiate(CrossChainOrder order, bytes signature, bytes fillerData) external;

/// @notice Resolves a specific CrossChainOrder into a generic ResolvedCrossChainOrder

/// @dev Intended to improve standardized integration of various order types and settlement contracts

/// @param order The CrossChainOrder definition

/// @param fillerData Any filler-defined data required by the settler

/// @returns ResolvedCrossChainOrder hydrated order data including the inputs and outputs of the order

function resolve(CrossChainOrder order, bytes fillerData) external view returns (ResolvedCrossChainOrder);

}

該標準的設計目標是增強求解者的用戶體驗，使他們更容易支持多個結算網路，並確定性地計算他們的獎勵。我相信這將使他們能夠向用戶提供更準確、更緊密的報價。您可以在這篇 X/Twitter 帖子以及以太坊 Magicians 論壇上關於它的討論中閱讀有關該標準（代號 ERC7683）的更多詳細信息。

結束語

“意圖”這個概念令人困惑，因爲它們沒有明確定義，而這種缺乏定義正在導致真正的用戶體驗缺陷。

每個人都希望其他人使用他們對意圖的標準定義，因此我完全承認制定標準實際上是不可能的。我認爲首先定義意圖結算系統，然後嘗試吸引訂單流是建立行業標準的正確方法。

在我看來，更可行的方法是，已經擁有大量用戶流量並產生許多用戶意圖的 DApp 將同意遵循一些最低標準，他們現有的求解者將採用這些標準。這將形成一個新的、更大的求解者池。通過獲得來自已經知名的場所的合並訂單流，這個新的求解者池將獲得更多的利潤，並能向最終用戶提供更好的價格。最終，新的 DApp 也將要求將它們的意圖路由到這個求解者池，並支持其意圖標準。

爲了讓我們開始行動，Across 和 Uniswap 共同提出了一個標準，供所有意圖供應鏈參與方在處理用戶訂單時使用，以便將 X 代幣從鏈 A 發送並在鏈 B 上接收 Y 代幣。通過 UniswapX（在拍賣設計方面具有比較優勢並產生意圖）和 Across（在解決意圖履行方面具有比較優勢）流動的訂單流可以合並，並啓動培育一個更大、更有競爭力的求解者網路的過程。

本文受到與意圖供應鏈內積極構建的以下人士的現實生活和在線討論的啓發：

來自 frontier.tech 的 Ankit Chiplunkar、Uniswap 的 Mark Toda、Alice Henshaw 和 Emily Williams、Li.Fi 的 Arjun Chand、Sorella 的 Karthik Srinivasan、Khalani 的 Kevin Wang、The Spartan Group 的 tumilet、Across 的 Matt Rice、Ryan Carmen 和 Hart Lambur、Archetype 的 Benjamin Funk 和 Dmitriy Berenzon、Decent 的 Will Kantaros ，以及 Flood 的 Francesco。

最後，我和 Hart Lambur 在 ETH Denver 的演講中總結了本文的觀點：

在哪裏可以了解有關意圖和鏈抽象的更多信息

1. UniswapX
2. Frontier.tech 的 CAKE 框架
3. 關於 Intents 的 Anoma 博客
4. Intents、Suave、AA、XChain 橋接都是同一件事 - Uma Roy
5. 基於意圖的架構及其風險

聲明：

1. 本文轉載自[ Mirror ]，著作權歸屬原作者[Nick Pai]，如對轉載有異議，請聯系Gate Learn團隊，團隊會根據相關流程盡速處理。
2. 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
3. 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得復制、傳播或抄襲經翻譯文章。