Question 1

Gas Price Oracle 為什麼重要？

Accepted Answer

**Gas Price Oracle 有哪些主要的數據來源？它們的準確性和延遲怎麼樣？**

Gas Price Oracle 的數據來源主要有三類，各有不同的準確性和延遲特性：

**類型一：鏈上 RPC 查詢（`eth_gasPrice` / `eth_feeHistory`）**
Ethereum JSON-RPC 標準提供了查詢當前 Gas 費的原生方法。`eth_gasPrice` 返回一個網絡建議的 Gas 費估算；`eth_feeHistory` 返回過去幾個區塊的 Gas 費歷史數據，讓你能基於趨勢做預測。優點：直接從鏈上讀取，最原始；缺點：只告訴你「現在」的費用，不能預測「未來 10 分鐘」的費用。

**類型二：第三方 Gas Oracle API**
Blocknative Gas Estimator、Etherscan Gas Tracker、Alchemy Gas Manager 等服務收集大量的 mempool 數據和歷史費用模式，生成更精細的預測——包括「未來 60 分鐘的 Gas 費預測」和「按時間的 Gas 費分佈」。準確性高於純鏈上查詢，因為它們使用了更多的數據維度（mempool 堆積情況、歷史模式）。延遲：通常有 5-30 秒的更新頻率，不是實時。

**類型三：在協議層自帶 Gas Oracle 的機制（EIP-1559）**
EIP-1559（2021 年 8 月以太坊升級）引入了鏈上 Base Fee 機制——每個區塊的 Base Fee 由協議根據前一個區塊的使用率自動調整（前一個區塊超過目標使用率則 Base Fee 上漲，低於則下降）。這意味著 Base Fee 是可預測的（下一個區塊的 Base Fee 最多漲/跌 12.5%），給 Gas Oracle 的預測提供了更穩定的基礎。

**對 Onchain Agent 的實際建議**：在需要實時性不高的場景（每小時一次的利率套利），用 Blocknative 或 Etherscan 的 Gas API，每次執行前查詢一次；在需要實時性高的場景（套利 Agent），直接用 `eth_feeHistory` 做鏈上計算，避免 API 調用延遲。

Question 2

Gas Price Oracle 如何運作？

Accepted Answer

**EIP-1559 之後 Gas 費的結構發生了什麼變化？Base Fee 和 Priority Fee 有什麼區別？**

EIP-1559 是以太坊 Gas 費機制的重大改革，讓 Gas 費的結構從「單一競拍費用」變成了「Base Fee + Priority Fee（小費）」的雙組成結構：

**Base Fee（基礎費用）**：
- 由協議自動計算，每個區塊所有人看到的 Base Fee 相同
- 根據前一個區塊的使用率動態調整（區塊超過目標使用率的 50% → Base Fee 上漲；低於 50% → Base Fee 下降），每個區塊最多變動 12.5%
- Base Fee 全部被銷毀（Burn），不進入礦工口袋
- 你的交易要進入區塊，必須支付至少 Base Fee，低於 Base Fee 的交易會被忽略

**Priority Fee（小費 / maxPriorityFeePerGas）**：
- 你額外給礦工的「小費」，礦工根據小費高低決定優先打包哪些交易
- 如果你的小費高，礦工更傾向於優先打包你的交易（即使 Base Fee 相同）
- 默認設定：Metamask 等錢包通常建議 1-2 Gwei；對非緊急的 Agent 操作，可以設置 0.1-0.5 Gwei 降低成本

**對 Onchain Agent 的影響**：
- Gas Oracle 現在需要同時預測 Base Fee（相對可預測，最多 12.5% 變動）和建議的 Priority Fee（更多受市場情緒影響）
- Agent 設置 `maxFeePerGas`（= Base Fee + Priority Fee）時，Base Fee 設得比當前高一些（留 buffer）；Priority Fee 按操作緊急程度設定（不緊急的操作設 0.1 Gwei，讓交易自然在 Gas 費低時被打包）
- EIP-1559 讓 Gas 費更可預測，Agent 更容易設計「等 Gas 費降到閾值後再執行」的策略

Question 3

Gas Price Oracle 如何實際應用？

Accepted Answer

**Agent 應該在什麼時候查詢 Gas Price Oracle？每次工具調用前都要查嗎？**

Gas Price Oracle 的查詢本身也消耗時間（API 請求的延遲）和成本（如果是付費的第三方 API），所以不需要也不應該在每個工具調用前都查詢。合理的查詢策略：

**查詢時機一：在計劃執行寫入操作之前**
只有在 Agent 計劃執行鏈上寫入操作（廣播交易）前，才需要查詢 Gas 費。讀取操作（查詢 API 數據、讀取鏈上狀態）不消耗 Gas，不需要在前面做 Gas 費查詢。

**查詢時機二：定期緩存更新（非實時場景）**
對不需要精確實時 Gas 費的 Agent（每小時執行一次的利率套利 Agent），可以設計一個「每 5 分鐘更新一次的 Gas 費緩存」，每次執行前讀取緩存而不是每次都發一次 API 請求。5 分鐘的緩存對每小時執行的 Agent 已足夠精確（Gas 費在 5 分鐘內變動通常不超過 10-15%）。

**查詢時機三：觸發式查詢（Gas 費敏感策略）**
對 Gas 費非常敏感的策略（利差很小、只有在 Gas 費極低時才有利可圖），可以設計一個「Gas 費監控器」Sub-agent，持續監控 Gas 費，當 Gas 費低於閾值時才通知 Orchestrator 執行策略。這讓主策略 Agent 不需要主動查詢 Gas 費，而是等待「Gas 費條件滿足」的通知。

**不需要查詢 Gas Price Oracle 的場景**：讀取操作（任何不廣播交易的工具調用）；部署在 L2（Base / Arbitrum）上的 Agent（L2 的 Gas 費極低且波動小，通常不影響策略盈虧）；已知 Gas 費窗口（在固定的低 Gas 費時間段執行，不需要實時查詢）。