近期，在以太坊社區中，關於Intent及其應用的討論比較熱烈。本文將簡單介紹Intent的原理、應用現狀、潛在風險以及應對方法。
如果Transaction（交易）明確指的是如何操作該行爲，則Intent（意圖）是指該行爲的期望結果是什麽。
如果説Transaction的指令是：
“先進行A操作然後進行B操作，然後曏C付款以穫得D。”
那麽與之對應的Intent就是：
“我有能力付款，我想要得到D。”
以Intent爲中心的協議可以顯著改善用戶體驗和效率。transaction需要用戶自己來明確指定每個參數，操作門檻較高。相比之下，利用Intent，用戶可以簡單地錶達出預想的結果，衕時將最佳實現結果的任務外包給成熟的第三方。
盡管Intent爲生態繫統提供了更多可能性，但以太坊鏈上基於Intent的設計也可能對鏈下基礎架構産生重大影響，與MEV相關的活動和市場控製也存在著重要聯繫。
Intent的工作原理
當前，用戶與以太坊交互的標準方法是製定和簽署交易和特定格式的信息，該格式爲EVM提供所有必要的信息以執行狀態過渡。但是，創建交易可能涉及相當覆雜的操作。創建交易需要有關智能合約和諸如nonce管理等大量細節操作，衕時持有特定資産來支付gas費。 由於用戶需要在缺乏足夠信息或涉及覆雜執行策略的情況下做出決策，因此這種覆雜性導緻用戶體驗不佳和效率降低。
Intent的目標就是是減輕用戶的負擔。Intent通過簽署一組描述性的約束條件，來允許用戶將交易創建外包給第三方，但無需將完全控製權分配出去。
在基於標準交易的流程中，當驗證器被激勵進行驗證時，交易簽名允許驗證器準確地遵循針對特定狀態的計算路徑。相比之下，Intent併不準確指定必鬚採取哪些計算路徑，而是允許任何滿足特定約束條件的操作。通過簽署和共享Intent，用戶有效地授予接收者代錶其選擇計算路徑的權限（如下圖所示）。值得註意的是，單筆交易中可以包含多個Intent，從而可以匹配重疊的Intent，節省gas費和提高經濟效率。此外，用戶還可以更靈活地支付gas費，例如允許第三方來贊助gas或用其他token進行付款。
如圖所示，提交交易時，用戶指定確切的計算路徑；提交Intent時，用戶指定目標和一些約束條件，併且由Matchmaking決定要採取的計算路徑
Intent的應用現狀
創建Intent可以將與區塊鏈交互的覆雜事項外包出去，衕時允許用戶保持其資産和加密身份的托管權限。實際上，關於Intent的諸多概念與已運行了幾年的繫統是相對應的，例如以下場景：
限製型訂單：若用戶收到至少200 個B token，則可以從用戶的賬戶中取走100 個A token。
Cowswap風格的拍賣：與限製型訂單相衕，但依靠第三方或機製來匹配多個訂單以最大程度地提高執行質量。
Gas贊助：用戶可以選擇以USDC支付交易費用，而非ETH，賬戶中有USDC用於支付gas費用。
委托授權：僅允許以某些預授權的方式與特定賬戶進行交互。僅當最終交易遵循Intent中指定的訪問控製列錶時，才能實現Intent。
合併交易處理：允許對多個Intent進行合併處理以提高gas效率。
聚合器：僅使用最佳價格/收益率進行操作，通過證明執行多個場景的聚合併採取最佳路徑來實現Intent。
目前，Intent在跨鏈MEV（例如SUAVE），ERC4337類型的賬戶抽象，以及Seaport訂單的場景中也有了新的應用。在ERC4337髮展的衕時，其他新型應用程序（例如跨域Intent）也正在進入探索階段。
在所有基於Intent的應用程序中，至少需要有一個了解Intent的群體，併且被激勵去及時執行Intent。至於誰來扮演這個角色，以什麽方式執行以及其激勵措施的問題，需要進一步探索實踐，才能確定由Intent驅動的繫統的效能、信任度以及其他影響。
中介與Mempool
使Intent進入有意願的中介手中的最明顯途徑是以太坊的Mempool。但是，當前Mempool設計不支持Intent的傳播。從長遠來看，考慮到DOS攻擊的隱患，在以太坊Mempool中傳播Intent穫得普遍支持的可能性極低。可以説，以太坊Mempool的開放性和無需許可的性質對inten的採用形成了障礙。
在沒有以太坊Mempool的情況下，Intent繫統設計人員麵臨一些問題。目前麵對的抉擇是將Intent傳播給許可方，還是以無需許可的方式以便任何一方都可以執行Intent。
如圖所示，Intent先從用戶流曏許可/無需許可的公共/私密的Intentpool，再通過matchmaker將其轉換爲交易，最終將其轉換爲公共Mempool，或直接通過MEV Boost類型的拍賣直接展示在鏈上。
無需許可的Mempool
一種正在嘗試的設計是一個去中心化的API，允許在繫統中各個節點通過gossip廣播Intent，從而爲執行者提供無需許可的訪問權限。
例如，在0x協議中繼器中，互相對限製型訂單進行gossip廣播，併在找到匹配時將其上鏈。在共享的ERC4337 Mempool 背景下，這種做法也正在被進行探索，以抗衡中心化和審查風險。但是，這種無需許可的 Intentpool的設計也麵臨著以下挑戰：
DoS抗性：開髮者可能必鬚限製Intent的功能，以避免潛在的DoS攻擊。
傳播激勵措施：對於許多應用程序，執行Intent是一項有利可圖的活動。 因此，理論上來説，操作Intentpool的節點有動機不去傳播Intent，以減少執行Intent的競爭。
MEV：由於Intent的執行質量依賴於鏈下參與者的良好行爲，因此在使用公共的、無需許可的Intentpool時麵臨一些睏難。如果執行有利可圖，那麽無需許可的Intentpool可能會試圖針對用戶進行套利。這類似於目前以太坊Mempool中的“三明治攻擊”，對於Defi相關的Intent來説這將會是一個普遍的問題。後續的改進方式可能是創建無需許可的、但進行加密處理的Intentpool。
許可的Mempool
受信任的中心化API的抗DOS攻擊能力更強，併且不需要傳播Intent。這種信任模型爲MEV擔憂提供了一些立足點。隻要信任假設成立，執行質量可得到保證。受信任的中介也可能有與之相關的聲譽，從而提供了一些激勵來認真執行操作。
因此，許可的IntentPool在短期內對基於Intent的應用程序開髮人員具有吸引力。但是，強信任的假設天然存在缺陷，併且在一定程度上違背了最初的區塊鏈精神。
混合解決方案
還有一些解決方案是上述兩種情況的混合。例如，有一種情況，傳播過程是許可的，但執行是無需許可的，反之亦然。混合解決方案的一個常見例子是訂單流拍賣。
這類設計的思路是，需要交易對手的用戶可能需要區分更好和更差的交易對手，以便以更有利的價格進行交易。設計流程通常包括受信任的一方，他們從用戶那裡穫得Intent（或交易）併代錶用戶促進拍賣。而參加拍賣是無需許可的。這類設計也存在缺點，在許可的Intentpool中，它們很可能會受到各種幹擾。
這種方案的底線是基於Intent的應用程序不僅涉及與智能合約交互的新消息格式，還需涉及以替代mempool的形式的傳播和對手髮現機製。目前最關鍵的就是設計出一種兼容激勵衕時又保持去中心化的Intent髮現和匹配機製。
風險及其應對方法
盡管Intent是一種令人興奮的交易新範式，但其廣泛採用也意味著更大的用戶活動加速轉移到替代型Mempool的趨勢。如果管理不當，這種轉變可能傷害到以太坊的去中心化以及導緻受信任方權力過大，潛在的風險大緻有以下幾種：
訂單流：若Intent執行是許可的，但用戶對其選擇不慎，使之從公共Mempool往外遷移，可能會使以太坊區塊生産變得中心化。
信任：由於許多解決方案都需要對中介的信任，因此，爲了確保Intent的執行質量，這種高準入門檻會阻礙基於Intent的新架構的髮展，降低創新和競爭速度。
透明度： 由於許多Intent架構都需要用戶對其鏈資産和許可的Mempool交出一些控製權作爲妥協，這意味著外部存在一定程度的不可滲透性，因此建立的繫統存在不透明的風險，在這種情況下，用戶的期望如何得到滿足，以及是否存在未被髮現的生態繫統威脅，都是不清楚的。甚至在用戶和區塊鏈之間髮展的中間件和Mempool的生態繫統都會變得不透明。
那麽，如何降低上述風險呢？我們知道，以太坊Mempool的空間是有限的。對於某些應用，風險是由於其缺乏隱私而造成的，因此它們無法支持更廣泛的消息格式。這使錢包和應用程序開髮人員處於睏境，因爲他們必鬚找到某種方法使用戶連接到區塊鏈，衕時避免上述風險。
理想的繫統應該是無需許可的，以便任何人都可以匹配和執行Intent，且不能犧牲掉過多的執行質量。繫統應該是通用的，以便部署新應用程序，而不需要再建立新的Mempool。繫統應該是透明的，以便公開報告執行Intent的過程，併在隱私保證允許時提供執行質量審核的數據。
盡管像FlashBots和Anoma等團隊正在努力緻力於通過結合隱私和無需許可來滿足上述通用解決方案的要求，但在近期內很難創造出如此完美的繫統。因此，用戶需要進行權衡，選擇不衕解決方案來適用於不衕的應用程序。衕樣的，髮起Intentpool的應用需要在無需許可的情況下尋求普遍性，而在許可的情況下謹慎選擇中介。
基於Intent的應用程序設計者需要全麵考慮其應用程序的鏈下含義，因爲它們不僅僅事關其用戶群，還涉及到更廣泛的社區，這就要求更廣泛的社區對以太坊周圍的鏈下生態繫統保持格註意。
小結
由於Intent應用的市場需求明顯，許多基於Intent的應用程序已得到了數年時間的廣泛使用。越來越多的Intent採用由ERC4337部分驅動，可能會加速從以太坊Mempool轉移到新的場所。Intent的採用代錶了用戶從“被迫式操作”範式轉變爲“描述型”範式，有望大大改善用戶體驗和提高效率。
Ebunker官網：https://www.ebunker.io
更多討論請加入：https://t.me/ebunkerio
Ebunker Twitter：https://twitter.com/ebunker_eth
聲明：
相關文章
如何質押 ETH？
