昨天算完 OFA 的帳,結論卡在一句話:5–6 bps 的價格改善裡只有 1–2 bps 真的來自拍賣,而「哪一段是拍賣人自己說了算」沒有鏈上答案。今天要說的是,這件事在 2025–2026 年確實有人正面攻擊,而且方向分成兩條完全不同的路:一條是把執行搬進硬體隔離區,用遠端證明讓外人檢查跑的是哪一版程式碼(TEE);另一條是乾脆讓拍賣人看不到內容,等順序定了再解密(加密記憶池)。兩條路都不是「消滅信任」,而是「把信任換成另一種形狀」——差別在於新的那個形狀能不能被檢驗、能不能被追責。這篇要把兩條路各自保證什麼、明確不保證什麼講清楚,最後給一組可以直接拿去問服務商的問題。
📖 學
先把信任缺口攤開來看。一筆交易從錢包送出到上鏈,中間至少經過六個交接點,每一個交接點今天都有一個「相信對方照規則做」的假設:
| 步驟 | 現況信任假設 | 可能的作弊方式 | 有沒有救 |
|---|---|---|---|
| 錢包 → 私有 RPC / OFA 端點 | 端點不外洩、不自營搜尋者 | 偷看內容、把資訊賣給關聯方、選擇性延遲 | 有:TEE 內執行 + 遠端證明;或加密送出 |
| 拍賣撮合 | 拍賣人照公告規則(密封競價、無 last look) | 看到最高價後自己以 +1 wei 出手;偽造競價者;對特定訂單開後門 | 部分:TEE 內撮合 + 可重現建置;規則本身仍要人相信 |
| 退款計算 | builder 誠實申報區塊價值與退款比例 | 少報區塊價值、把價值挪到 coinbase 以外的路徑 | 部分:TEE 內計算 + 鏈上退款憑證 |
| builder 排序 | 不插單、不拆包(unbundling) | 把 bundle 拆開自己 backrun、把使用者交易前後夾住 | 有:TEE builder;但輸入端仍可被觀察 |
| relay → proposer | relay 不提前外洩 payload | 把 payload 先給關聯 builder;選擇性審查 | 部分:ePBS 之後可望移除 relay 這一層 |
| proposer 出塊 | proposer 不 equivocate、照承諾納入 | 收了預確認費用卻不履行 | 部分:proposer commitments + 罰沒;ePBS 協定內化 |
看得出來一個規律:能被「救」的,幾乎都是可以被搬進某種可驗證容器的計算步驟;救不了的,是規則本身的設計與輸入端的觀察權。
TEE 路線到底保證了什麼。 Intel TDX 的遠端證明產出一份 quote,裡面有 MRTD(啟動時整個 TD 映像的測量值)、四個 RTMR(執行期可延伸的測量暫存器),由 Quoting Enclave 用一條追溯到 Intel 的憑證鏈簽名。驗證者拿到這份 quote,能確認的事情只有兩件:這段測量值對應的程式碼,正在一顆真實的、微碼版本為某某的 TDX CPU 上,以這個啟動狀態執行。這叫「程式碼身分 + 執行完整性」。
它明確不保證的東西比保證的多。第一,它不保證那段程式碼是對的——測量值只是雜湊,你得自己有能力把雜湊對回原始碼,這需要 reproducible build。BuilderNet 在 2025 年 2 月的 v1.2 才做到完整可重現的 TDX 映像建置,在那之前你只能相信 Flashbots 貼出來的映像跟 GitHub 上的原始碼是同一回事。第二,它不保證輸入是對的:TEE 裡的程式碼如果拿到被竄改的價格資料,一樣忠實地算出錯的結果。第三,也是 2025 年之後最刺眼的一點——它不保證那顆 CPU 在哪裡。Flashbots 在 2026 年 4 月的〈Mind the Gap〉裡把這叫做 physical-access gap:證明報告在資料中心和在某人家地下室產生時,長得一模一樣。
這個缺口在 2025 年被幾篇論文捅穿。WireTap(喬治亞理工 + 普渡)用被動介入器讀取 DDR4 密文記憶體,對低熵資料建立密文—明文字典;Battering RAM(KU Leuven + 伯明翰)做了主動別名的介入器,拿到 SGX 保護記憶體的任意讀寫;2025 年 10 月 28 日公開的 TEE.fail 把同一套方法推到 DDR5,重建出簽章私鑰,進而偽造 SGX/TDX quote。論文明白示範了在 BuilderNet 上偽造 TDX 證明、取得機密交易資料的攻擊。
Flashbots 的回應值得逐字看清楚:攻擊示範跑在實驗室裡的非生產 BuilderNet 實例上;這類攻擊需要實體存取;而生產系統要求所有 operator 只能部署在核可的雲環境,加上 IP allowlist,所以「不適用」。兩邊講的都是真的,但意義完全不同。研究者說的是「密碼學保證失效了」,Flashbots 說的是「營運控制還在」。**這正是重點:TEE 的保證一旦遇到有實體存取的對手,就從密碼學保證降級成營運信任。**而營運信任,恰恰是我們一開始想從拍賣人身上拿走的那個東西。
所以才有 Proof of Cloud 這一整條後續。Flashbots 提出的 DCEA(arXiv 2510.12469)建立兩個平行信任根——晶片廠的 TDX 證明鏈,加上資料中心的 (v)TPM——利用 vTPM 的 PCR 與 TD 的 RTMR 有重疊測量集,交叉比對;不一致就代表兩份證據來自不同機器,這能擋掉把 TD 跑在自家硬體、把 TPM 互動轉發到雲端伺服器的 proxy attack。Intel 另外提出 POE(Platform Ownership Endorsement),用永久不變的 PRID 與可重置的 PIID,由雲商簽發 CoRIM 格式的 token 宣告「這台機器是我家的」。POE 比較輕、但保證比較窄:它證明誰擁有這台機器,不證明host 跑了什麼軟體——因為 PIID 設計上跨 TCB recovery 保持不變,不含 host 的 measured launch。一個被內鬼改過的 hypervisor 跑在合法背書的硬體上,POE 看不出來。
而且 Proof of Cloud 本質上是一張供應鏈快照:它信任雲商的資產資料庫與維運紀律。機器被偷走、沒做 factory reset,舊 PIID 在 token 過期或被撤銷前照樣簽得出「雲端」證明。誠實的說法是:TEE 路線把「相信拍賣人」換成了「相信 Intel 的信任根 + 相信雲商的實體安全與庫存紀律 + 相信映像可重現」。這是搬家,不是消滅。但搬家不是沒有價值——新房客是有名有姓、可稽核、法律上可追責、賽局上作弊代價極高的實體,而且證明本身可以放上鏈公開驗證(Flashtestations 在做的就是這件事)。這比「相信一個不揭露內部規則的拍賣人」嚴格更好,只是別把它說成 trustless。
**加密記憶池是另一條路。**它不試圖證明拍賣人有守規矩,而是讓拍賣人根本看不到內容。門檻加密(threshold encryption)是目前唯一有真實部署的方案:Shutter 自 2024 年 7 月起在 Gnosis Chain 主網運行,由一組 keypers 透過 DKG 產生公鑰,alpha keyper set 只有 7 個節點。使用者拿門檻公鑰加密,區塊生產者把密文放進區塊、承諾了順序,keypers 才釋出解密金鑰份額,湊到 k 份就能解密執行。Shutter 對以太坊 L1 的路線圖分三步:先在 MEV Blocker 上開 eth_sendEncryptedTransaction(這一步的加解密流程還是中心化的),再用 proposer commitments / Commit-Boost 接進 PBS,最後才是協定內化。2025 年 2 月的白皮書宣布主網目標落在 2025 年底到 2026 年初——但我查不到確認 L1 主網已經上線的資料,只查到當初的時程宣告,這點請自己再確認。
門檻加密的根本張力就在那個 k。k 設得低,少數 keypers 串通就能提前解密,保密性歸零;k 設得高,少數 keypers 離線就沒人解得開,交易永久卡住,活性歸零。這是同一個參數的兩端,不可能同時最佳化。Shutter 文件寫「把門檻設在總數一半以下就能保證及時解密」,翻譯成白話是:他們選擇把天平壓向活性——代價是共謀所需的人數也隨之下降。
其他方案的取捨各有各的難。Time-lock / VDF 不需要委員會,但專用硬體讓有 ASIC 的人提前解出來;難度參數怎麼設才能「剛好在納入區塊時解開」沒有好答案;更糟的是交易若最後沒被納入區塊,內容照樣曝光,反而變成免費的搶跑素材。Commit-reveal 最簡單,但活性最差,而且使用者「不 reveal」等於握有一個免費選擇權(free option),對做市方是純虧。
還有一個常被混為一談的區分:「排序後才解密」跟「解密後才排序」不是同一件事。Shutter 屬於前者(commit-then-decrypt):builder 先對密文承諾順序,再拿到金鑰。搶跑在資訊上不可能,但要處理「強制 reveal」與「解密後發現是無效交易,佔位的 gas 誰付」。BuilderNet 這類 TEE builder 屬於後者:明文在 TEE 內部是看得見的,只是排序規則被硬體與證明約束住。後者效率高得多,還能做 backrun 分潤(因為要知道內容才知道怎麼分),但保密性上限就等於 TEE 的保證上限。真正的問題永遠是同一個:明文在哪一刻、在誰手上。
最後,加密不等於公平。即使內容完全加密,metadata 仍然洩漏:發送者位址、gas limit、calldata 大小、送達時間、來源端點。這幾項就足以對大額或可識別的交易做推論攻擊——你在某個 DEX 上有固定行為模式,對手看密文大小加時間戳就能猜個八九不離十。更根本的是,加密記憶池會把 MEV 轉型而不是消滅。三明治這種依賴受害者資訊的攻擊確實會被打掉,因為攻擊者需要看到你的交易;但攻擊者可以轉成盲猜:對已知流動性池的統計分佈下注,只要期望值為正就一直做,成本轉嫁回使用者身上只是變得比較隱晦。而 CEX-DEX 套利根本不受影響——它的資訊優勢來自中心化交易所的價格,不是來自你的 mempool。所以加密記憶池打得到 victim-dependent MEV,打不到 statistical MEV 與 externally-informed MEV。另外別忘了 coverage gap:解密之後的排序仍然是公開狀態上的競爭,以及 pairing-based 門檻加密有 harvest-now-decrypt-later 的後量子曝險。
順帶一提時程:FOCIL(EIP-7805)原本是 Glamsterdam 的候選,後來被移出以控制範圍,現在排在 2027 年上半的 Hegotá。Vitalik 論證過 inclusion list 與多重併發提議者要真的發揮作用,幾乎必須配一個加密記憶池——否則你只是強迫 builder 納入一筆它看得見的交易。這代表兩條路最後很可能不是二選一,而是必須同時到位。
🧠 記
- 遠端證明只回答「什麼程式碼在哪種 CPU 上以什麼狀態跑」,不回答「這程式碼對不對、輸入對不對、機器在哪裡」。
- 沒有 reproducible build,MRTD 就只是一串你無法核對的雜湊。BuilderNet v1.2(2025-02)才補上這塊。
- TEE.fail(2025-10-28)在 DDR5 上偽造 SGX/TDX quote;Flashbots 說生產環境靠「只准部署在核可雲 + IP allowlist」擋住。密碼學保證退化成營運信任,就是這個瞬間。
- Proof of Cloud 兩種做法:Intel POE 證明機器歸誰(輕、窄),DCEA 額外綁定 host 的 measured launch(重、廣)。兩者都是供應鏈快照,依賴雲商的庫存紀律。
- 門檻加密的 k 同時控制保密性與活性,方向相反,不能同時最佳化。Shutter 選了活性優先。
- 「排序後解密」(Shutter)vs「解密後排序」(TEE builder):差別是明文在哪一刻落到誰手上。
- 加密後 metadata 仍洩漏(sender / gas limit / size / timing);MEV 從搶跑轉成盲猜與統計套利,CEX-DEX 套利完全不受影響。
- 2026 年 builder 市佔觀測大致是 BuilderNet 約 23–26%、與 Titan 合計約八成——TEE 建塊已經是主流基礎設施,不是實驗。
✍️ 實踐
挑一個你自己真的在用的「防 MEV」端點(Flashbots Protect、MEV Blocker、某錢包內建的 private RPC 都行),做一份信任盤點,20–30 分鐘。
第一步,五分鐘:打開它的文件,找「attestation」「TEE」「measurement」「reproducible」這幾個關鍵字。找得到就抄下 MRTD / RTMR 或映像雜湊公布在哪;找不到就在表上直接標記「未公布」。
第二步,十分鐘:把本文那張六列的信任盤點表複製一份,針對這個端點逐格填。重點不是填滿,而是誠實標出哪幾格你填不出來——那些格子就是你目前在無條件相信對方的地方。
第三步,十分鐘:對照下面四個問題,逐題在文件裡找答案,找不到就記下「文件未回答」。做完你會發現,四題全部答得出來的服務極少,而答不出來本身就是最有用的資訊。行有餘力,把問題丟到該專案的 Discord 或論壇,看回覆速度與具體程度。
判斷一個宣稱「防 MEV」的方案有沒有真的降級信任,問這四題:
- 明文在哪一刻、在誰手上?(如果答案是「在我們的伺服器上」,那它跟一般私有 RPC 沒有本質差別。)
- 你的保證失效時,我能不能事後查出來?(可驗證 ≠ 可偵測。有些設計只在事前擋,一旦被繞過就完全無痕。)
- 如果用 TEE:映像是不是可重現建置?證明貼在哪裡、誰在驗?有沒有 Proof of Cloud 或等價的實體位置保證?
- 如果用門檻加密:k 和 n 是多少、keypers 是誰、怎麼輪替?k 個人串通的成本,跟他們能偷到的價值比起來如何?
🔗 延伸學習
- Mind the Gap — Where TEE Attestations Fall Short and Why Do TEEs Need Proof of Cloud — Flashbots 2026-04,DCEA 與 Intel POE 的完整對照,physical-access gap 講得最清楚的一篇。
- Why TEE.fail is bullish for BuilderNet — 廠商面對攻擊論文的實際回應,值得跟論文對讀。
- The Road Towards an Encrypted Mempool On Ethereum — Shutter 對 VDF / FHE / TEE / witness encryption / 門檻加密的取捨比較,以及三步路線圖。
- TEE.fail — DDR5 記憶體匯流排攻擊的原始網站,含論文與示範。
💬 問 AI
我在評估一個宣稱「防 MEV」的交易提交方案,想確認它到底把信任搬到了哪裡。
方案資訊:
- 名稱 / 類型:<例如 TEE builder、門檻加密記憶池、私有 RPC>
- 我查到的公開文件:<貼連結或重點>
請幫我做四件事:
1. 用一張表回答:使用者交易的明文,在整條路徑上依序經過哪些主體、在哪一刻變成明文、每一段的信任假設是什麼、對應的作弊方式是什麼。
2. 分別列出這個方案「密碼學上保證」的事情,和「只是營運政策保證」的事情。如果某項保證在對手取得實體存取或內部權限時會降級,請明確標出降級後剩下什麼。
3. 如果是 TEE 方案:檢查是否有 reproducible build、證明報告是否公開可驗、有沒有 Proof of Cloud(POE / DCEA / 雲商 provenance)。如果是門檻加密方案:找出 k 與 n、keypers 身分與輪替機制,並估算共謀成本相對於可竊取價值的量級。
4. 誠實告訴我這個方案「打不到」哪些 MEV:特別是 CEX-DEX 套利、統計型盲猜、解密後的排序競爭,以及 metadata 洩漏可能造成的推論攻擊。
不確定的地方請直說不確定,不要用推測填空。