GoAT-X 論文閱讀分析：很多跨鏈稽核真正缺的，不是再多一個 scanner，而是先把模型關進可驗證的推理路徑裡

本文由 AI 產生、整理與撰寫。

論文基本資訊

• 論文標題：GoAT-X: A Graph of Auditing Thoughts for Securing Token Transactions in Cross-Chain Contracts
• 作者：Zijun Feng、Yuming Feng、Yu Wang、Weizhe Zhang、Yuhong Nan、Yuang Liu、Zibin Zheng
• 年份：2026
• 來源：arXiv:2604.24341
• 論文連結：https://arxiv.org/abs/2604.24341
• DOI：10.48550/arXiv.2604.24341
• 主題：Web3 Security、Smart Contract Security、LLM Agents、Automated Auditing、Cross-Chain Security、Program Analysis

現在很多人一看到「LLM 做 smart contract audit」，第一反應不是期待，而是先皺眉：你真的要把幾十億美元的橋接資產，交給一個會幻覺的模型嗎？

這篇 GoAT-X 有意思的地方，就在它沒有假裝這個問題不存在。作者反而直接承認：跨鏈合約稽核最麻煩的，不只是 codebase 大、依賴多、邏輯繞，而是傳統靜態分析看得到語法卻看不懂跨鏈語意，LLM 看得懂語意卻又很容易在多合約依賴裡開始腦補。

所以這篇真正想補的，不是「再給稽核模型更多上下文」，而是先把它的推理路徑鎖進一張可驗證、可約束、可回溯的審計圖裡。

這也是它名字裡 Graph of Auditing Thoughts 的重點：不是讓模型自由發揮，而是把稽核拆成一串有邊界的 thought node，讓每一步都只在該看的結構和狀態空間裡做判斷。

這篇在解什麼問題？

作者鎖定的是 cross-chain token transaction。這類系統之所以容易出事，不只是因為 Solidity 難寫，而是整個橋接流程本來就天然破碎：

• 來源鏈上鎖幣 / 燒幣
• 事件被 off-chain relayer 監聽與驗證
• 目的鏈再解鎖 / 鑄造資產

控制流程不是一條線，狀態也散在不同鏈、不同合約、甚至不同信任邊界裡。這會帶來三大類風險：

• Integrity violation：參數本身就不合理，例如零金額、目的鏈資訊衝突、收款地址異常。
• Authenticity violation：訊息被偽造、重播，或授權驗證不完整。
• Safety violation：即便訊息表面合法，後續 external call、slippage 或執行路徑仍可能被操弄。

作者引用的背景數字也很兇：跨鏈橋相關攻擊累積損失已超過 28 億美元。而這正是很多工具卡住的地方：bytecode analysis 能抓 pattern，卻很難驗證「這個跨鏈流程本來應該成立的安全前提到底有沒有真的被 enforce」。

GoAT-X 的核心觀點：把漏洞檢測改寫成 first-principles verification

我覺得這篇最值得記住的，不是 Graph of Thoughts 這個名字，而是它把整個任務重新定義了。

GoAT-X 不把問題想成：

• 這段 code 看起來像不像某個已知漏洞 pattern？
• 模型能不能直接從原始碼猜出 suspicious function？

它改問的是：

• 這個跨鏈交易必須滿足哪些基本安全性質？
• 這些性質在來源鏈、目的鏈、外部呼叫與狀態轉換上，有沒有被落成具體 constraint？
• 如果 constraint 有寫，攻擊者能不能繞過？

換句話說，它不是在做 pattern matching，而是在做性質導向的驗證。作者把 cross-chain transaction 抽象成一組標準化 property schema，然後再定義對應的驗證 predicate，去檢查：

• 收件地址是否為零
• 金額是否大於零
• chain ID 是否合理
• nonce 是否唯一
• 簽章或 proof 是否有效
• 外部呼叫目標 / 函式是否落在白名單
• slippage 與價格保護是否有界

這一步非常重要，因為它等於先回答了「模型到底應該找什麼」。很多 LLM 稽核工具的問題不是模型不夠強，而是根本沒有被給出一個足夠嚴格的驗證空間。

五層 Graph of Auditing Thoughts 是怎麼運作的？

GoAT-X 把整個稽核流程拆成五層，每一層只做一件比較清楚的事。

1. 先定位交易相關程式碼

第一層先從 cross-chain event 與靜態分析下手，抓出和某筆跨鏈交易真正有關的程式碼片段。這一步的目的很務實：不要一開始就把整份大型 codebase 丟給模型硬讀。

2. 把安全性質對到具體參數

第二層把抽象的 property 映射到實際參數與交易欄位，例如來源鏈、目的鏈、token、amount、nonce、signature 等。這讓後面的推理不是在空中談風險，而是開始有結構化對象。

3. 沿資料流切出真正相關的 execution slice

第三層透過靜態分析與 context-aware slicing，把和這些安全性質有關的 data flow 挖出來。這一步其實就是在幫 LLM 消噪：把應該看的狀態流與約束路徑整理好，再把模型放進來。

4. 驗證 predicate 是否真的被實作

第四層開始檢查那些 integrity / authenticity / safety predicate 是否真有被 enforce。作者還加了 encoder aggregation 與 self-correction 機制，避免模型在多個 thought path 上重複、漂移或互相打架。

5. 從「有檢查」繼續追到「能不能繞過」

第五層是這篇最像實戰的地方。GoAT-X 不停在「有沒有 if statement」這種表層，而是進一步分析bypass path：攻擊者能不能靠特定狀態條件、訊息組合或外部互動，把看似存在的驗證邏輯實際上繞過去。

而且這層還用了帶狀態上下文的 RAG 與歷史 exploit knowledge，讓模型不是閉門猜測，而是把過往攻擊經驗當作旁證。

這篇厲害的不是多 agent，而是 privilege boundary 比較清楚

現在很多 agent 論文只是在一個大模型外面再套幾個角色名，實際上大家還是在同一團 prompt 湯裡游泳。GoAT-X 比較不一樣，它的多階段設計至少有兩個實際價值：

• 推理責任切割：不同層只負責 extraction、mapping、slicing、verification 或 bypass analysis，不是所有判斷都混成一句最終結論。
• 語意邊界收斂：LLM 的活動空間是被 static analysis、predicate schema 與 graph state 夾住的，不是讓它任意聯想。

這意味著它真正想做的是：把 LLM 從自由書寫型 auditor，變成被證據結構牽著走的 reasoning component。

實驗結果最值得記住哪些數字？

作者自己建了一個跨鏈漏洞 benchmark，把公開資料集與 incident report 整理後，得到：

• 673 份 smart contracts
• 20 個 cross-chain project
• 294 個人工標註的 fine-grained audit points

在這個 benchmark 上，GoAT-X 的結果是：

• 92% recall：代表它對細粒度稽核點的覆蓋率很高
• 95% vulnerable project coverage：代表它能抓到大多數有問題的專案
• 野外識別 117 個 confirmed risks

如果只看數字，這篇想講的是：它不只是比 baseline 多抓一些 pattern，而是做出一個能對應完整跨鏈交易邏輯、而且有實際發現能力的框架。

我怎麼看這篇？

我覺得 GoAT-X 最有價值的，不是它把 LLM 搬進 Web3 稽核，而是它清楚示範了一件事：

很多高風險領域真正需要的，不是一個更會講話的模型，而是一個更不容易亂講話的推理結構。

這句話放在跨鏈橋尤其成立。因為這類系統真正難的從來不是 syntax，而是跨狀態、跨合約、跨信任域的語意一致性。你如果只靠 rule-based scanner，會看不到 intent；你如果只靠原始 LLM，又很容易在複雜依賴裡 hallucinate。GoAT-X 的做法，本質上是在兩者之間搭一座橋：

• 用 static analysis 提供結構與 grounding
• 用 formalized predicates 提供驗證目標
• 用 graph-based reasoning 控制多步審計流程

這個設計思路不只對 Web3 有用。放大來看，它其實很像所有 agentic security 系統都該學的一課：別再讓模型直接對世界做大結論，先把它放進明確的中間表示、證據鏈與限制條件裡。

當然，這篇也不是沒有風險。它的品質仍然依賴：

• 靜態分析切片是否足夠準
• predicate schema 是否覆蓋新型橋接設計
• RAG / 歷史 exploit 知識是否引入偏誤
• benchmark 是否能代表真實世界那些更髒、更客製的專案

但至少方向是對的，而且比「把整份 repo 塞給模型後問它哪裡怪怪的」成熟得多。

結語

GoAT-X 這篇論文最值得記住的，不是它又做了一個新的 LLM auditor，而是它把 automated auditing 從「猜漏洞」往前推到「驗證性質、追資料流、檢查繞過路徑」這種比較像真正安全工程的流程。

如果你在看的是 agentic security、LLM-assisted code auditing、smart contract analysis，或任何需要在高風險系統裡讓模型參與判斷的場景，這篇都很值得讀。因為它提醒了一件很根本的事：

很多自動稽核真正缺的，不是更多 token，而是先把模型能說的話，限制在證據真的撐得住的地方。