後量子以太坊的選擇：框架交易與架構化交易的對比分析
本文主張架構化交易是實現以太坊抗量子安全性最便宜且最簡單的路徑，透過原生支持 Falcon-512 等簽名方案，其 Gas 效率遠優於目前討論中的框架交易或智能錢包方案。
在 Hegota 中，方案敏捷的原生交易是實現抗量子以太坊最便宜、最簡單路徑的論據
問題所在
以太坊的交易認證依賴於 secp256k1 上的 ECDSA。Shor 演算法可以破解它。社群廣泛認為基於晶格（lattice-based）的簽名，特別是 Falcon (FN-DSA) 和 Dilithium (ML-DSA)，是最可行的替代方案。爭論的焦點已從「使用哪種演算法」轉向「哪種交易架構能實現它」。
SchemedTransactions (EIP-XXX)： 一種新的 EIP-2718 交易類型 (0x05)，它將傳統的 v, r, s 簽名字段替換為 scheme_id 字節和 signature_data 大對象（blob）。啟動時定義了三種方案：secp256k1 (ECDSA)、P256 (passkeys/WebAuthn) 和 Falcon-512 (後量子)。發送者地址是從公鑰確定性地推導出來的，與現在完全一樣。沒有智能錢包，沒有帳戶抽象機制。
本文認為，SchemedTransactions 產生的 Gas 經濟效益優於目前提出的任何路徑（包括框架交易 Frame Transactions），同時避免了不必要的協議複雜性，並能獨立於帳戶抽象爭論之外交付後量子安全性。
Gas 數據
以下基準測試假設 Glamsterdam 後的 Gas 重新定價（降低原生 ETH 轉帳的基礎成本）。所有數據均針對轉帳至不同地址的簡單 ETH 交易。數據取自 Erigon 客戶端中 SchemedTransaction 和框架交易 / 預編譯規範的現有實現。
估算方法
Gas 成本使用 SchemedTransaction 固有 Gas 公式估算：
固有 Gas = 基礎成本 + 方案 Gas 附加費
對於沒有調用數據（calldata）且沒有訪問列表的簡單 ETH 轉帳，成本簡化為基礎固有成本加上涵蓋額外簽名/公鑰大小和驗證成本的固定附加費。基礎成本在最佳情況下（Glamsterdam 重新定價後）約為 4,500 Gas，或在目前的平均情況下約為 21,000 Gas（當前固有成本）。
對於智能錢包路徑 (EIP-8141 / ERC-4337)，Gas 估算如下：
Gas = 基礎成本 + (簽名大小 + 公鑰大小) × 16 + 預編譯成本 + 智能錢包開銷
× 16 因子是以太坊對非零字節的每字節調用數據成本。NIST 後量子方案不支持從簽名中恢復公鑰（不同於 ECDSA 的 ecrecover），因此每筆交易都必須包含完整的簽名和完整的公鑰。預編譯成本：Falcon 為 3,000 Gas (EIP-8052)，Dilithium 為 4,500 Gas (EIP-8051)。智能錢包開銷涵蓋合約調度、存儲讀取和 EVM 執行上下文（約 30,000 至 48,000 Gas）。
相關大小：Falcon-512 產生約 666 字節的簽名和 897 字節的公鑰（總計 1,563 字節）。Dilithium-2 (ML-DSA-65) 產生約 2,420 字節的簽名和 1,312 字節的公鑰（總計 3,732 字節）。
SchemedTransaction 附加費
SchemedTransaction EIP 為每種方案定義了固定 Gas 附加費，根據每種演算法帶來的額外帶寬、傳播和驗證成本進行校準：
| 方案 | 附加費 | 理由 |
|---|---|---|
| secp256k1 (0x00) | 0 | 與現在相同，無額外成本 |
| P256 (0x01) | 0 | 驗證成本與 secp256k1 相當 |
| Falcon-512 (0x02) | 25,000 | 簽名比 ECDSA 大約 24 倍；涵蓋大小與驗證 |
Falcon (FN-DSA-512)
| 路徑 | Glamsterdam 最佳情況 (Gas) | 目前平均情況 (Gas) |
|---|---|---|
| 直接預編譯 + 智能錢包 | ~63,000 | ~82,880 |
| NTT 預編譯 + 智能錢包 | ~63,600 | ~83,580 |
| SchemedTransaction (原生) | ~29,500 | ~46,000 |
Dilithium (ML-DSA-65)
| 路徑 | Glamsterdam 最佳情況 (Gas) | 目前平均情況 (Gas) |
|---|---|---|
| 直接預編譯 + 智能錢包 | ~111,500 | ~133,000 |
| NTT 預編譯 + 智能錢包 | ~223,900 | ~243,900 |
| 假設的 SchemedTransaction (原生) | ~69,000 | ~85,000 |
註：目前的 SchemedTransaction EIP 僅將 Falcon-512 定義為後量子方案。Dilithium 數據是假設性的，假設未來通過 EIP 增加 Dilithium scheme_id 並收取比例附加費（約 63,000 Gas）。選擇 Falcon 而非 Dilithium 是深思熟慮的：Falcon 的簽名 + 公鑰總大小（1,563 字節）不到 Dilithium（3,732 字節）的一半，使其成為每字節都需要 Gas 的鏈上交易中最務實的選擇。
數據告訴我們什麼
Falcon + SchemedTransaction 是明顯的贏家。 在 Glamsterdam 最佳情況下約為 29,500 Gas，經 Falcon 認證的原生 SchemedTransaction 成本約為當前 ECDSA EOA 轉帳（約 21,000 Gas）的 1.4 倍。沒有其他後量子路徑能接近這個比例。
NTT 預編譯對 Dilithium 產生了反效果。 通用 NTT 預編譯 (EIP-7885) 是為加密敏捷性設計的：一個構建塊，多種方案。在實踐中，Dilithium 驗證需要的 NTT 輪次遠多於 Falcon，而 EVM 的內存模型將其轉化為成本爆炸。通過 NTT 實現的 Dilithium（約 223k 至 244k）成本大約是直接 Dilithium 預編譯（約 111k 至 133k）的兩倍。通用化懲罰是真實存在的，並體現在內存操作中。
NTT「共享構建塊」的前提在深入檢查後進一步瓦解。 EIP-7885 承諾單個 NTT 預編譯可以作為所有基於晶格方案的共同基礎。實際上，每種方案都帶有自己的非 NTT 操作，這些操作對驗證同樣關鍵，且在沒有專用預編譯支持的情況下同樣昂貴。Falcon 需要 HashToPoint（將消息哈希為多項式），而 Dilithium 不使用。Dilithium 需要矩陣擴展（將種子擴展為完整的多項式矩陣），而 Falcon 不使用。Hawk（一種較新的基於晶格的方案）需要定點算術運算，而 Falcon 和 Dilithium 都不需要。這些操作中的每一項最終都需要自己的預編譯才能在 Gas 上可行，因此 NTT 預編譯實際上並沒有整合預編譯的覆蓋面。它只是成為不斷增加的方案特定預編譯集合中的又一個成員。將 NTT 作為共享原語的加密敏捷性論點崩潰了：對於非 NTT 的所有內容，你仍然需要針對每個方案的預編譯，而 NTT 本身反而是最初最便宜的部分。
智能錢包稅非常沉重。 每條通過智能錢包（ERC-4337 或 EIP-8141 框架驗證）的路徑，都要為合約調度、存儲讀取和 EVM 執行上下文支付額外的 30,000 至 48,000 Gas 開銷。SchemedTransactions 通過將 PQ 簽名驗證視為一等協議操作，完全消除了這一點。客戶端在交易信封層級驗證 Falcon 簽名，就像今天驗證 ECDSA 一樣。
為什麼 EVM 內存模型才是真正的瓶頸
鏈上 PQ 驗證的關鍵瓶頸不是 NTT 算術本身，而是 EVM 中的內存操作。
EVM 沒有 memcopy 操作碼。要將內存的一個區域複製到另一個區域，你必須將一個 32 字節的字（word）MLOAD 到棧上，然後逐字 MSTORE 回去。身份預編譯（地址 0x04）提供批量複製，但它仍然需要 CALL 及其相關開銷。對於涉及在大型工作緩衝區中重組多項式係數的基於晶格的簽名驗證來說，這非常昂貴。
Gas 定價模型使情況變得更糟。EVM Gas 成本並不總是與實際計算成本相關。Keccak-256 哈希花費 36 Gas。256 位整數上的 MULMOD 花費 8 Gas。五次乘法比一次哈希更貴，儘管哈希函數通常計算強度更高。基於晶格的方案在小域上進行大量算術運算（而非 EVM 設計針對的 256 位域），正好撞上了這種不匹配最嚴重的地方。
這就是為什麼直接預編譯優於 NTT 構建塊預編譯。直接預編譯以原生速度執行整個驗證演算法，完全繞過 EVM 內存管理。NTT 預編譯仍需要 EVM 來編排高層驗證邏輯，在預編譯中進出調度數據，並在 EVM 內存中管理中間狀態。這種編排正是 Gas 成本累積的地方。
對於 Falcon，差異微乎其微（約 700 Gas），因為 Falcon 的驗證是「輕 NTT」的：一次正向 NTT 和一次逆向 NTT，且公鑰 NTT 可在鏈下預計算。對於需要顯著更多 NTT 操作和更大工作內存的 Dilithium，開銷使成本翻倍。
SchemedTransactions 完全避開了這個問題。簽名驗證發生在協議層級，在客戶端內部，而不是在 EVM 內部。沒有 EVM 內存操作，沒有預編譯調用，沒有對單個 NTT 步驟的 Gas 計量。客戶端只需原生運行 Falcon 驗證並收取固定附加費。這與以太坊今天對 ECDSA 使用的模型相同：ecrecover 並非你從智能錢包調用的預編譯，它是嵌入在交易驗證中的協議層級操作。
為什麼通用的「靈活操作碼」無法解決此問題
人們可以想像一種靈活的 SIMD 風格操作碼（本著從未被採納的 EIP-616 精神），讓 EVM 執行向量化算術，本質上是在操作碼層級編寫類似 numpy 的操作。但這無法逃避根本問題：EVM Gas 模型按操作收費，且內存擴展成本依然存在。靈活的操作碼仍在 EVM 的內存和棧架構內執行。它可能會減少指令數量，但無法消除主導 PQ 驗證成本的內存管理開銷。將驗證移出 EVM，無論是通過預編譯還是通過像 SchemedTransactions 這樣的協議層級驗證，是避免這種稅收的唯一方法。
框架交易並未解鎖 EIP-7702 之外的新用例
EIP-8141 闡述的動機有兩個：後量子準備和完全帳戶抽象。後量子論點是，框架交易允許帳戶定義任意驗證邏輯，因此任何未來的簽名方案都可以在不進行硬分叉的情況下被採納。
但這混淆了兩個獨立的問題。
專門針對 PQ 簽名，你需要的是一種能攜帶 PQ 簽名的交易格式，以及一個能原生驗證它的協議。驗證邏輯本身並不複雜，即「根據此公鑰檢查此 Falcon 簽名」。問題在於在 EVM 內部執行此操作過於昂貴，而要通過框架交易使其可行，意味著需要重新設計 EVM 本身的關鍵方面，如內存成本甚至預編譯輸入/輸出的工作方式。這是一項比框架交易 EIP 所承認的要大得多的工程。SchemedTransactions 通過單個 scheme_id 字節且在驗證期間不執行 EVM，完全避免了這一點。
對於一般的帳戶抽象，EIP-7702 已經允許 EOA 委託給合約代碼，從而實現自定義驗證、批量處理和 Gas 贊助。EIP-8141 支持者引用的用例（passkey 認證、會話密鑰、ERC-20 Gas 支付）已經可以通過 EIP-7702 委託結合 ERC-4337 基礎設施來實現。SchemedTransactions 還通過 scheme_id = 0x01 (P256) 原生處理 passkey/WebAuthn 案例，這是框架交易引用的主要動機之一。框架交易為其餘案例提供了一個更簡潔的協議層級原語，但它們並未啟用根本性的新功能。
框架交易真正引入的是顯著的協議複雜性：
- 內存池（mempool）中的 DoS 向量。 任意 EVM 驗證意味著節點在知道交易是否可以安全傳播之前必須對其進行追蹤（trace）。追蹤後驗證失敗是未付費的計算，這是一個拒絕服務（DoS）向量，需要聲譽系統或追蹤限制來緩解。這是導致 2026 年 3 月 ACD 決定推遲的核心擔憂。
- 新操作碼。 EIP-8141 引入了 APPROVE, TXPARAMLOAD, TXPARAMSIZE, 和 TXPARAMCOPY。這是 EVM 中新的覆蓋面，必須在所有客戶端（Geth, Nethermind, Besu, Erigon）中一致實現，否則有共識失敗的風險。
- 語義變更。 ORIGIN 操作碼在框架交易下的行為發生變化，返回框架的調用者而非交易發起者。依賴於 ORIGIN == CALLER 的合約（一種不被鼓勵但存在的模式）可能會損壞。
抽象是幻覺：你永遠需要預編譯
框架交易承諾任何簽名方案都可以在 VERIFY 框架中實現而無需協議更改。理論上，這是通過抽象實現的加密敏捷性。實際上，每個有意義的驗證方案最終無論如何都需要預編譯。
用於 WebAuthn passkey 的 P256 驗證？那需要一個專用的預編譯 (RIP-7212)，因為在 EVM 中執行 P256 的成本高得令人望而卻步。用於下一代 WebAuthn 標準的 ML-DSA？那也需要一個預編譯 (EIP-8051)。Falcon？它已經有了自己的預編譯提案 (EIP-8052)。模式是一致的：EVM 不是為具有 Gas 競爭力的加密驗證而構建的，因此進入生產使用的每個真實方案都要求預編譯使其可行。
這意味著框架交易在沒有硬分叉的情況下實際上並未交付加密敏捷性。它們交付的是從 VERIFY 框架中調用預編譯的能力，但預編譯本身仍需要通過協議升級來部署，這需要與任何其他 EVM 更改相同的社群共識和硬分叉過程。EIP-8141 啟用的「任意驗證邏輯」，對於加密驗證而言，只是對無論如何都需要預編譯的一層抽象。
這在後量子問題周圍創造了一種尷尬的局面，而後量子本應是框架交易的核心用例。要在框架內實際驗證 Falcon 或 Dilithium 簽名，你需要相應的預編譯。但如果你已經有了預編譯，你就可以在協議層級驗證簽名，無需框架，無需 EVM 執行，無需智能錢包開銷。框架變成了一種不必要的間接：它在原本可以由交易驗證邏輯直接調用的預編譯之上，增加了 Gas 成本（智能錢包調度、框架編排）。框架交易承諾通過抽象解決 PQ 問題，但抽象卻依賴於那些使抽象變得不必要的預編譯。
結果是，這條路徑成本更高，且無法靠自身完全解決量子問題。框架交易允許單個帳戶選擇加入 PQ 驗證，但它們對網絡上保持活躍的傳統交易類型無能為力。只要協議接受 type-0（傳統）和其他 ECDSA 簽名的交易，以太坊就不是抗量子的。它是「量子可選」的。最終實現完全抗量子需要從協議層級棄用並禁止僅限 ECDSA 的交易類型，這本身就是一次硬分叉。框架交易沒有為這種過渡提供機制；它們假設無限期共存。相比之下，SchemedTransaction 路徑將 PQ 簽名交易作為與傳統類型並列的一等交易類型引入，使得最終棄用 ECDSA 類型成為一個乾淨的協議層級決定：在第 N 個區塊後停止接受 type-0 交易。沒有智能錢包遷移，沒有逐個帳戶的選擇加入，只需像以太坊之前每次交易格式升級一樣，讓舊交易類型退役即可。
SchemedTransactions 避免了上述所有複雜性。簽名驗證是在交易信封層級進行的一次簡單、廉價、無狀態的檢查，與今天的 ECDSA 完全一樣。驗證期間沒有 EVM 執行，沒有新操作碼，沒有語義變更，沒有內存池追蹤。節點驗證 SchemedTransaction 的方式與驗證傳統交易相同：解碼、驗證簽名、推導地址、檢查 nonce 和餘額、執行。
SchemedTransaction 架構
SchemedTransaction 的設計刻意保持極簡。它是一個帶有兩項更改的 EIP-1559 交易：傳統的 v, r, s 字段被 scheme_id（1 字節）和 signature_data（可變長度）取代。
工作原理
- 方案選擇。 發送者選擇一個 scheme_id（0x00 代表 secp256k1，0x01 代表 P256，0x02 代表 Falcon-512），並使用相應的演算法簽署交易。
- 簽名驗證。 客戶端根據 scheme_id 進行調度並運行適當的驗證程序。對於 secp256k1，這是現有的 ecrecover。對於 P256，它使用 EIP-7951 預編譯邏輯。對於 Falcon，它運行原生 Falcon-512 驗證。所有這些都發生在協議層級，在 EVM 執行之前。
- 地址推導。 對於 secp256k1 (0x00)，地址是 keccak256(pubkey)[12:]，與傳統以太坊相同，保持完全向後兼容。對於所有其他方案，地址是 keccak256(scheme_id || pubkey)[12:]，提供域隔離，以便不同演算法的密鑰不會在同一個地址上發生碰撞。
- Gas 計量。 固有 Gas 為 基礎成本 + 方案附加費。在 Glamsterdam，簡單 ETH 轉帳的基礎成本降至約 4,500 Gas；今天的平均值約為 21,000 Gas。Falcon 的 25,000 Gas 附加費涵蓋了其約 1.5 KB 簽名 + 公鑰的帶寬和驗證成本。secp256k1 和 P256 的附加費為零。
這能帶來什麼
| 交易類型 | Glamsterdam 最佳情況 (Gas) |
|---|---|
| SchemedTransaction, Falcon-512 | ~29,500 |
| SchemedTransaction, P256 (passkey) | ~4,500 |
| Falcon + 智能錢包 (EIP-8141 路徑) | ~63,000 |
| Dilithium + 智能錢包 | ~111,500 |
| Dilithium 通過 NTT + 智能錢包 | ~223,900 |
在 Glamsterdam 最佳情況下，Falcon SchemedTransaction 的成本約為 29,500 Gas。這大約是簡單 P256 或 secp256k1 轉帳基礎成本（約 4,500 Gas）的 6.5 倍，但增量幾乎完全是 Falcon 簽名和公鑰產生的調用數據成本。通過智能錢包 / 框架交易路徑，開銷約為 63,000 至 224,000 Gas，對於相同的加密操作，這比 SchemedTransaction 路徑高出 2 倍到 7.5 倍。
為什麼選擇 Falcon-512 而不是 Dilithium？
SchemedTransaction EIP 選擇 Falcon-512 (NIST FIPS 206) 作為其後量子方案，因為在 128 位安全級別的 NIST 標準化基於晶格的方案中，它具有最小的簽名 + 公鑰組合大小。Falcon 總計 1,563 字節，不到 Dilithium-2（3,732 字節）的一半。在每字節都有 Gas 成本的區塊鏈上，這是決定性的。包括 Dilithium 在內的額外方案可以通過未來註冊新的 scheme_id 值的 EIP 來添加。
以太坊可以兩者兼得，但 SchemedTransactions 現在更有用
這並不是反對框架交易存在的論據。以太坊可以兩者都採納。沒有什麼能阻止框架交易稍後構建在 SchemedTransactions 之上，繼承其原生 PQ 驗證和 Gas 效率，同時為真正需要的用例添加可編程驗證。Vitalik 本人也承認，受限的交易原語和完全帳戶抽象服務於不同的目的。這兩個提案在協議層級並非互斥。
但現在，以太坊社群面臨一個具體且具時效性的問題：在量子對手變得實際可行之前，部署後量子交易認證。問題不在於「抽象上哪種架構更優雅？」，而在於「哪種架構能最快、最便宜且對網絡風險最小地交付 PQ 安全性？」
在這個問題上，SchemedTransactions 具有壓倒性優勢：
- 更便宜： 根據比較對象的不同，便宜約 2 倍到 7 倍。
- 更簡單： 沒有新操作碼，沒有內存池追蹤，沒有 DoS 緩解複雜性。交易驗證模型與今天完全相同：解碼、驗證簽名、推導地址、執行。
- 交付更快： 一個帶有 scheme_id 調度的單一新交易類型，是比完整的執行框架大修更小、更易審計的更改。2026 年 3 月關於 EIP-8141 的 ACD 決定已經推遲，因為客戶端團隊希望有更清晰的內存池規則。SchemedTransactions 沒有這個問題，因為它們完全沒有引入新的內存池驗證複雜性。
- 足夠使用： PQ 簽名驗證不需要圖靈完備的驗證邏輯。它只需要客戶端根據一個 1 字節字段調用不同的驗證函數。
- 額外獎勵：原生 passkey 支持。 SchemedTransactions 還以零額外 Gas 成本解決了 P256/WebAuthn 用例 (scheme_id = 0x01)，這是框架交易被引用的首要動機之一。
框架交易解決了一個真實問題：具有完全可編程性的廣義帳戶抽象。但那個問題並不像 PQ 安全那樣緊迫，且 EIP-7702 已經涵蓋了用戶今天需要的實際 AA 用例（會話密鑰、批量處理、 Gas 贊助）。只有框架交易才能啟用的用例（任意鏈上驗證、奇特的多元身份驗證流程）雖然重要，但並未阻礙目前的任何採用。
SchemedTransactions 具有立竿見影的效用。它們為 PQ 簽名和 passkey 錢包提供了一條乾淨的原生路徑，將 Gas 成本保持在接近 ECDSA 的水平，並且可以在不等待 AA 爭論解決的情況下交付。一旦它們上線且 PQ 安全部署完成，社群可以從容地完善框架交易，制定適當的內存池規則，進行徹底的客戶端測試，而不會受到量子威脅時間線的壓力。
務實的順序是：SchemedTransactions 在前，框架交易準備好後在後。而不是相反。
總結
| 準則 | 框架交易 (EIP-8141) | SchemedTransaction |
|---|---|---|
| Glamsterdam 最佳情況 (Falcon ETH 轉帳) | ~63,000 | ~29,500 |
| 目前平均情況 (Falcon ETH 轉帳) | ~82,880 | ~46,000 |
| 原生 passkey (P256) 支持 | 通過 EVM 驗證框架 | 是，零附加費 |
| 需要新操作碼 | 是 (4 個) | 否 |
| 內存池 DoS 複雜性 | 高 (需要追蹤) | 無 (無狀態簽名檢查) |
| 相對於 EIP-7702 的新用例 | 邊際 | 不適用 (目標為 PQ + passkeys) |
| 地址格式更改 | 智能帳戶遷移 | **無 (`hash(scheme_id |
| 協議複雜性 | 高 | 低 |
| 獨立於 AA 爭論交付 PQ | 否 | 是 |
| 框架交易後續可構建在其之上？ | 不適用 | 是 |
Gas 估算源自 Erigon 客戶端中兩種規範的現有實現。SchemedTransaction 成本使用 EIP 的固有 Gas 公式：基礎成本 + 方案附加費 (Falcon 附加費：25,000 Gas)。基礎成本：Glamsterdam 最佳情況下約 4,500 Gas / 目前平均情況下約 21,000 Gas。智能錢包路徑估算使用：基礎成本 + (簽名字節 + 公鑰字節) x 16 + 預編譯成本 + 錢包開銷。Falcon-512 大小：666 字節簽名，897 字節公鑰。Dilithium-2 大小：2,420 字節簽名，1,312 字節公鑰。預編譯成本依據 EIP-8052 (Falcon: 3,000 Gas) 和 EIP-8051 (Dilithium: 4,500 Gas)。NIST PQ 規範中不提供公鑰恢復，因此每筆交易必須傳輸完整公鑰。