Intent 架構深度技術分析：從 ERC-7683 跨鏈意圖標準到 Solver Network 經濟學的完整解析

身為一個在 Web3 打滾多年的老兵，我必須坦白說：intent-based 的概念剛出來的時候，我看不懂。

「讓用戶表達意圖而不是具體操作」？這不就是把我想要的結果告訴系統，然後讓系統自己去找最佳路徑嗎？聽起來很美好，但實際上呢？

後來我親眼見過 CoW Protocol 怎麼把「我想用 ETH 換 USDC」這個簡單意圖，轉化成多條 DEX 的組合、最佳滑點執行，我才意識到這套玩法的威力有多大。

2024 到 2026 年這段時間，intent-based 的應用範圍從 DEX 擴展到了跨鏈、帳戶抽象、借貸、甚至遊戲道具交易。可以說，intent 正在成為區塊鏈用戶體驗的下一個突破口。

這篇文章我打算把 intent 的底層邏輯、ERC-7683 這個跨鏈意圖標準、Solver Network 的經濟學設計、以及它跟帳戶抽象（EIP-7702）的整合，全部串起來講清楚。看完你應該就能判斷：intent 到底是曇花一現的熱點，還是真正改變遊戲規則的技術方向。

數據截止 2026 年 3 月。

為什麼需要 Intent？

要理解 intent，你得先理解區塊鏈應用的根本矛盾：用戶想要的是結果，但區塊鏈只接受操作。

傳統的區塊鏈交互邏輯是這樣的：

用戶意圖：「我想把 1000 USDC 從 Ethereum 轉到 Arbitrum」

傳統做法（explicit transaction）：
1. 用戶需要知道：哪個橋？哪條路由？手續費多少？
2. 用戶需要操作：在 Arbitrum 上切換網路、授權橋接合約、提交交易、等待確認
3. 用戶需要決策：Gas 設定多少？要不要加速？

問題：
- 跨鏈橋有十幾個，哪個最便宜？
- 這個橋的資金安全嗎？之前有沒有被駭過？
- Optimistic 橋要等 7 天，怎麼辦？
- 這筆交易的最終狀態，區塊鏈只會告訴你「成功」或「失敗」
- 但用戶真正想知道的是：「我的錢到底到帳了沒有？」

intent-based 的做法完全不同：

Intent 做法：
1. 用戶表達意圖：「我想在 Arbitrum 上收到 980 USDC，願意付最多 20 USDC 的費用」
2. Solver 競爭：「我有 985 USDC 可以現在給你，費用 15 USDC，你要不要？」
3. 用戶確認：「成交」
4. 系統結算：Solver 把 985 USDC 打到用戶 Arbitrum 地址，用戶的 1000 USDC 被結算給 Solver

對用戶來說：就是點了一個「轉帳」按鈕，然後等著錢到帳

這個模型的優雅之處在於：複雜性被封裝在 Solver 這一層，用戶只需要表達自己的需求。

ERC-7683：跨鏈意圖的通用標準

2024 年下半年，ENS Labs 和 Cow Protocol 聯合提出了 ERC-7683，這個標準試圖為所有跨鏈意圖建立一個統一的格式。

ERC-7683 的核心概念

// ERC-7683 的核心結構
struct Order {
    // 意圖的約束條件
    // 這些條件決定了 Solver 能做什麼、不能做什麼
    address trader;           // 誰的意圖
    address sellToken;        // 要賣什麼
    address buyToken;         // 要買什麼
    uint256 sellAmount;       // 賣多少
    uint256 buyAmount;        // 最低要買多少
    uint256 feeAmount;        // 願意付多少費用
    uint256 deadline;         // 截止時間
    bytes32 salt;             // 隨機數，防止 replay
}

struct Settlement {
    // Solver 提交的結算資料
    Order order;              // 對應的 order
    address solver;           // 誰來結算
    bytes fillData;           // Solver 自定義的填充資料
    bytes signature;          // Trader 的簽名
}

這個結構的設計哲学是：保留 Trader（用戶）的所有控制權，把執行細節交給 Solver。

為什麼 ERC-7683 重要？

在 ERC-7683 出來之前，每個 intent-based 系統都有自己的訂單格式：

• CoW Protocol 有自己的格式
• UniswapX 有自己的格式
• Across Protocol 又是另一套
• 跨鏈橋的意圖格式更是五花八門

這種碎片化的問題在於：

碎片化的代價：

1. Solver 困境
   - 假設我是個專業的跨鏈 Solver
   - 我想要同時服務 CoW、UniswapX、Across 的用戶
   - 但每個系統的訂單格式都不一樣
   - 我需要寫三套不同的整合程式碼
   - 維護成本極高

2. 用戶困境
   - 用戶在不同平台需要重新表達相同的意圖
   - 「我想把 ETH 換成 USDC」這個意圖
   - 在 CoW 是一種格式，在 UniswapX 是另一種格式
   - 沒有統一的「意圖語言」

3. 橋接困境
   - 跨鏈意圖比單鏈複雜 10 倍
   - 涉及原鏈執行、目的鏈結算、跨鏈消息傳遞
   - 沒有標準簡直是開發者的噩夢

ERC-7683 的出現，解決了這個問題。它定義了一個「共同語言」：

// ERC-7683 的介面定義
interface IERC7683 {
    /// @notice 用戶提交意圖
    /// @param order 用戶的意圖訂單
    /// @param signature 用戶簽名
    /// @return orderHash 訂單的雜湊值
    function fulfillOrder(
        Order calldata order,
        bytes calldata signature
    ) external returns (bytes32 orderHash);
    
    /// @notice 用戶取消意圖
    /// @param orderHash 要取消的訂單雜湊
    function cancelOrder(bytes32 orderHash) external;
    
    /// @notice 查詢 Solver 的報價
    /// @param order 用戶的意圖訂單
    /// @return quote Solver 的報價
    function getQuote(Order calldata order) 
        external 
        view 
        returns (SettlementQuote memory quote);
}

這個介面的意義在於：任何實現了 IERC7683 的系統，都可以相互操作。

ERC-7683 的實際應用案例

讓我用一個具體場景來說明 ERC-7683 是怎麼運作的：

場景：用戶想要把 Ethereum 上的 ETH 跨到 Arbitrum 上換成 USDC

傳統做法：
1. 用戶在 Uniswap 上查詢：ETH -> USDC 的匯率
2. 用戶在 Across Protocol 上查詢：ETH -> Arbitrum USDC 的費用
3. 用戶在Hop Protocol 上查詢：ETH -> Arbitrum USDC 的費用
4. 用戶比較後選擇最優的橋
5. 用戶執行橋接交易
6. 用戶等待確認（可能需要 7 天在 Optimistic 橋上）

ERC-7683 做法：
1. 用戶提交意圖：「在 Arbitrum 收到至少 3,000 USDC，願意付最多 50 USDC 費用」
2. 系統廣播這個意圖
3. 多個 Solver 競爭：
   - Solver A：55 USDC 費用，馬上到帳
   - Solver B：45 USDC 費用，但需要 1 小時
   - Solver C：40 USDC 費用，需要 6 小時
4. 用戶（或系統自動）選擇 Solver A
5. Solver A 在 Arbitrum 直接轉帳 3,000 USDC 給用戶
6. 用戶的 ETH 在 Ethereum 結算給 Solver A

對用戶來說，整個過程就是一個按鈕。背後的複雜邏輯（橋接、匯率、費用計算）全部由 Solver 處理。

Solver Network：Intent 的經濟學引擎

光有標準不夠，還得有激勵機制。Solver Network 就是那個讓整個系統運轉的經濟引擎。

Solver 是什麼？

Solver 的本質是：專業的意圖執行者。

他們的角色有點像傳統金融的「做市商」，但又不完全相同：

傳統做市商 vs Solver：

傳統做市商：
- 庫存：持有大量的股票、債券、貨幣
- 收入：買賣價差（bid-ask spread）
- 風險：庫存價值的波動

Solver：
- 庫存：不一定需要持有資產
- 收入：用戶支付的意圖費用
- 風險：
  - 執行失敗的風險
  - Gas 價格波動的風險
  - 匯率波動的風險
  - 跨鏈延遲的風險

Solver 的工作流程

// Solver 的典型工作流程
contract SolverBot {
    address public owner;
    uint256 public minProfitBps;  // 最小利潤率（basis points）
    uint256 public maxGasPrice;   // 最大願意支付的 Gas 價格
    
    // Solver 的核心邏輯
    function processIntent(
        Order calldata order,
        bytes calldata signature
    ) external {
        // 1. 驗證訂單
        require(order.deadline > block.timestamp, "Expired");
        require(order.trader != address(0), "Invalid trader");
        
        // 2. 計算執行成本
        uint256 gasCost = estimateExecutionGas(order);
        uint256 gasPrice = block.basefee;  // 或者使用 arbitrum 的 L2 Gas Price
        
        // 3. 計算報價
        uint256 myFee = calculateFee(order, gasCost, gasPrice);
        require(myFee <= order.feeAmount, "Fee too high");
        
        // 4. 檢查利潤率
        uint256 profit = order.feeAmount - myFee;
        uint256 profitBps = profit * 10000 / order.sellAmount;
        require(profitBps >= minProfitBps, "Profit too low");
        
        // 5. 執行結算
        // 這裡的邏輯根據不同類型的意圖而不同
        if (order.sellToken == ETH && order.buyToken != ETH) {
            _executeCrossChainSwap(order, signature);
        } else if (order.sellToken != ETH && order.buyToken == ETH) {
            _executeSwapToETH(order, signature);
        } else {
            _executeSameChainSwap(order, signature);
        }
        
        // 6. 提交結算證明
        emit IntentFulfilled(order.trader, order.sellAmount, order.buyAmount);
    }
    
    // 估算 Gas 消耗
    function estimateExecutionGas(Order calldata order) 
        internal 
        view 
        returns (uint256) {
        // 根據訂單類型估算
        if (order.sellToken == NATIVE_TOKEN) {
            return 250000;  // 跨鏈橋的 Gas 估算
        } else {
            return 150000;  // 同鏈 swap 的 Gas 估算
        }
    }
    
    // 計算費用
    function calculateFee(
        Order calldata order,
        uint256 gasCost,
        uint256 gasPrice
    ) internal view returns (uint256) {
        return gasCost * gasPrice + 
               order.sellAmount * protocolFeeBps / 10000;
    }
}

Solver 的風險管理

說實話，Solver 這行不好幹。利潤空間透明，競爭激烈，還要應對各種突發狀況。

Solver 面臨的主要風險：

1. 執行失敗風險
   - 區塊鏈狀態變化導致原本有利可圖的訂單變成虧損
   - 例如：用戶 ETH 餘額不足、授權額度不夠
   - 解決方案：建立嚴格的預檢查機制

2. Gas 價格波動風險
   - 提交訂單時估算的 Gas 價格，可能在執行時大幅上漲
   - 解決方案：
     a) 使用 Flashbots Protect 拍賣 Gas
     b) 在 Gas 價格低時批量執行
     c) 設置最大 Gas 價格限制

3. 跨鏈延遲風險
   - Optimistic 橋有挑戰期，這段時間資金被鎖定
   - 解決方案：
     a) 優先使用快速橋（但費用更高）
     b) 對沖鎖定期間的匯率風險
     c) 接受延遲，在報價中體現

4. 對手方風險
   - 如果用戶簽名是假的，Solver 可能白做工
   - 解決方案：驗證簽名、使用智慧合約托管

Solver 的收益模型

// Solver 收益計算模型
contract SolverEconomics {
    // 收益 = 費用收入 - Gas 成本 - 風險成本
    
    struct ExecutionResult {
        uint256 revenue;      // 收到的費用
        uint256 gasCost;       // 實際 Gas 消耗
        uint256 slippageCost;  // 執行時的滑點損失
        uint256 opportunityCost; // 機會成本（資金鎖定）
    }
    
    // 計算實際收益率
    function calculateROI(
        ExecutionResult memory result,
        uint256 capitalLocked
    ) public pure returns (int256) {
        uint256 netProfit = result.revenue > result.gasCost 
            ? result.revenue - result.gasCost 
            : 0;
        
        // ROI = (淨利潤 / 鎖定資本) * 10000 (basis points)
        return int256(netProfit * 10000 / capitalLocked);
    }
    
    // 實例：計算一筆跨鏈 swap 的收益
    function analyzeSwapProfitability(
        uint256 sellAmount,
        uint256 buyAmount,
        uint256 marketPriceImpact,
        uint256 gasUsed,
        uint256 gasPrice
    ) external pure returns (bool profitable) {
        // 理論收益 = (市場中間價 - 實際成交價) * 數量
        uint256 priceSpread = marketPriceImpact * sellAmount / 1e18;
        
        // 扣除 Gas 成本
        uint256 netRevenue = priceSpread > gasUsed * gasPrice
            ? priceSpread - gasUsed * gasPrice
            : 0;
        
        return netRevenue > 0;
    }
}

Intent 與 EIP-7702 的整合：帳戶模型的下一個十年

現在讓我聊一個我個人覺得最有意思的方向：Intent 跟 EIP-7702 的整合。

EIP-7702 簡介

EIP-7702 是 2025 年初被納入以太坊 Prague 升級的提案。它的核心思想是：讓外部擁有帳戶（EOA）在交易執行期間臨時獲得智能合約的能力。

EIP-7702 的運作原理：

傳統 EOA 的限制：
- 只能用私鑰簽名發送交易
- 沒有自訂邏輯
- 無法實現多簽、延時交易、角色權限等高級功能

EIP-7702 的創新：
- 用戶在交易中附加一段代碼：「這個交易執行期間，把我當作某個合約」
- 例如：把你的 EOA 變成多簽錢包、變成延時控制器、甚至變成一個 Solver

實際意義：
- 用戶不需要先把資產轉移到智慧合約錢包
- 可以在需要時「啟動」智慧合約功能
- 交易完成後自動恢復為普通 EOA

為什麼 Intent 需要 EIP-7702？

這裡有個根本性的用戶體驗問題：

當前 Intent 系統的問題：

1. 資金要先轉移到某個合約
   - 用戶想要 swap，要先把錢轉到 CoW Protocol 的合約
   - 這個「托管」過程有安全疑慮
   - 用戶要信任 CoW 的合約不會被駭

2. 簽名複雜
   - 普通的 EOA 簽名很簡單
   - 但 Intent 系統需要 「乙太坊簽名」（EIP-712）
   - 用戶要在錢包裡看到一堆複雜的數據結構
   - 很多用戶看到就怕了

3. 錢包不支持
   - Ledger、Trezor 等硬體錢包對 Intent 的支持有限
   - 移動錢包（MetaMask、Rainbow）的 Intent 整合不完善

EIP-7702 解決了這個問題：

// EIP-7702 的實現示意
contract IntentWallet {
    // 當交易執行時，這個合約邏輯會「附加」到用戶的 EOA 上
    // 相當於用戶臨時擁有了這個合約的功能
    
    // 用戶表達意圖：用 ETH 換 USDC，最低收到 3000 USDC
    function expressIntent(
        address sellToken,
        address buyToken,
        uint256 sellAmount,
        uint256 minBuyAmount,
        uint256 deadline
    ) external {
        // 1. 這裡會創建一個 Intent 訂單
        // 2. 綁定用戶的意圖到這個合約
        // 3. 等待 Solver 執行
        
        // 關鍵：用戶的資產仍然在用戶自己的地址
        // 只是「意圖」被記錄在這裡
        // 用戶可以隨時取消（因為 EIP-7702 的機制）
    }
    
    // Solver 執行時的鉤子
    function settle(
        Order calldata order,
        bytes calldata fillData
    ) external onlySolver {
        // 1. 驗證 Solver 的資格
        // 2. 執行 swap（原子操作）
        // 3. 如果失敗，資金會退回（不會丟失）
    }
}

實際整合案例：Intent-Based 跨鏈橋

讓我舉個具體例子，展示 Intent + EIP-7702 如何徹底改變跨鏈橋的用戶體驗：

傳統跨鏈橋的使用流程（假設用戶要把 ETH 跨到 Arbitrum）：

1. 用戶打開橋接網站
2. 連接錢包
3. 輸入金額：1 ETH
4. 選擇目標網路：Arbitrum
5. 選擇橋：Hop、Across、Stargate...
6. 比較費用和時間
7. 點擊「Bridge」
8. 錢包彈出：授權（Approve）合約使用 1 ETH
9. 錢包彈出：確認交易
10. 等待：7 天（Optimistic橋）或 10 分鐘（快速橋）

問題：
- 用戶要自己做決策（橋的選擇）
- 需要管理授權額度
- 資金在橋接期間被鎖定
- 如果選錯橋，可能要多付幾十美元的費用


Intent + EIP-7702 的使用流程：

1. 用戶打開錢包（假設內建了 Intent 功能）
2. 點擊「跨鏈轉帳」按鈕
3. 輸入：目標鏈 Arbitrum，目標資產 USDC，目標金額 3000 USDC
4. 系統自動創建意圖：
   「我想在 Arbitrum 收到 3000 USDC，願意付最多 50 USDC 費用，
    希望盡快到帳（< 1 小時）」
5. Solver 競爭，用戶（或錢包自動）選擇最優報價
6. 一鍵確認
7. 資金直接出現在 Arbitrum 的錢包裡

對比：
- 操作步驟：10 步 → 5 步
- 需要決策的資訊量：極多 → 極少
- 資金安全性：需要信任橋合約 → 有智慧合約托管

這個體驗的提升，坦白說，是革命性的。

Intent 的 MEV 問題：一個不可忽視的風險

說了這麼多 Intent 的好處，我必須提一下它的黑暗面：MEV。

Intent 系統中的 MEV 機會：

1. Solver 搶跑
   - 當用戶提交意圖時，意圖的內容在某些階段是公開的
   - Solver 可以看到「有人想用 ETH 買大量 UNI」
   - 搶先在 Uniswap 大筆買入 UNI
   - 等用戶的 swap 執行時，價格已經變高了
   - Solver 從中獲利

2. 訂單重排序
   - 在區塊排序過程中，Validator 可以操縱包含哪些 Solver 的訂單
   - 這影響了 Solver 的執行效率

3. 隱私問題
   - Intent 的設計允許 Solver 看到用戶的意圖
   - 這本身就是一種資訊不對稱
   - 可能被用來歧視某些用戶或操縱市場

目前業界的解決方案有幾種：

MEV 緩解方案：

1. 加密意圖（Encrypted Intents）
   - 用戶的意圖在 Reveal 之前是加密的
   - 只有在執行時才會解密
   - 缺點：犧牲了 Solver 的競爭效率

2. Commit-Reveal 方案
   - 先提交意圖的雜湊值（Commit）
   - 延遲一段時間後再揭示（Reveal）
   - 缺點：增加了延遲

3. Flashbots 等 MEV 保護服務整合
   - 類似於傳統區塊鏈的 MEV 保護
   - 缺點：需要信任第三方

4. Solver 信譽系統
   - 建立 Solver 的歷史記錄和信譽評分
   - 用戶可以選擇「已被驗證不作弊」的 Solver
   - 缺點：可能形成中心化風險

我個人的判斷是：Intent 系統的 MEV 問題會長期存在，但不會阻礙這項技術的發展。隨著加密技術和信任機制的完善，這個問題會逐步緩解。

結語：Intent 的未來

Intent-based 的架構，本質上是把區塊鏈的複雜性從用戶端轉移到了基礎設施端。

Intent 架構的價值主張：

對用戶：
- 簡化了操作：用戶表達意圖，系統負責執行
- 降低了門檻：不需要理解區塊鏈的複雜性
- 提升了體驗：一鍵操作，像 Web2 一樣簡單

對 Solver：
- 專業化：專注於執行效率，不用管用戶介面
- 規模化：統一的介面標準，複用性高
- 利潤機會：激烈的競爭推動效率提升

對整個生態：
- 降低摩擦：統一的標準促進互操作
- 創新加速：新功能可以在 Solver 層快速迭代
- 用戶增長：更好的用戶體驗吸引更多用戶

但我們也要清醒地看到：Intent 架構還處於早期階段。

ERC-7683 的採納需要時間，Solver Network 的經濟模型還需要實戰檢驗，EIP-7702 的全面落地還要等以太坊的升級節奏。更重要的是：隱私、安全、MEV 這些問題，現在還沒有完美的解決方案。

我的建議是：密切關注這個領域，但不要急於下場。等待標準成熟、等待最佳實踐出現、等待第一批「吃螃蟹的人」驗證了安全性之後，再投入資金和精力。

區塊鏈的用戶體驗革命才剛開始。Intent 可能是這場革命的催化劑，也可能只是一個過渡階段。無論如何，這絕對是一個值得關注的方向。

參考資料

• ERC-7683 提案原始文件
• CoW Protocol 技術文檔
• UniswapX 白皮書
• EIP-7702 提案規格
• Flashbots MEV 研究報告
• Across Protocol 文件

本網站內容僅供教育與資訊目的，不構成任何投資建議或技術建議。在部署任何基於 Intent 的系統前，請自行研究並進行完整的安全審計。