「安全交易驗證與授權」（Secure Transaction Verification and Authorization，STVA）是一項新興的以太坊標準草案，旨在消除盲簽名與多重簽名 UI 攻擊——這是使用者批准其實際上無法讀取之交易時最持久的兩種攻擊途徑。該提案建立了兩階段控制結構：先驗證交易實際執行的內容，再於通過人類可讀的確認步驟後才進行授權。

STVA 的意義

STVA 的核心在於將大多數錢包介面合而為一的兩項功能分開。驗證回答的是交易參數——收款地址、代幣金額、目標合約與網路 ID——是否與使用者所見一致。授權回答的是適當的簽名者在廣播前是否已明確批准該經驗證的承載資料。

這個區別至關重要，因為現今標準錢包彈出視窗往往呈現使用者無法解碼的原始十六進位 calldata。多重簽名攻擊者或惡意前端可以在呈現看似無害的確認畫面的同時，將底層 calldata 路由到不同的合約或不同的受益人——而由於已廣播的交易無法召回，畫面所隱藏的內容實際上已在鏈上結算。STVA 透過在使用者介面顯示與鏈上執行之間強制執行政策檢查來縮小該攻擊面——這一做法也關聯到關於硬體錢包威脅面，以及在缺乏協議層強化的情況下設備級安全能延伸多遠的更廣泛討論。

這份在 Ethereum Research 上討論的 ERC 草案，其適用範圍涵蓋 EOA 發起的交易與智慧合約多重簽名流程，使其與協議金庫、DAO 營運以及一般散戶簽名者皆息息相關。作為草案，在錢包與多重簽名前端實作之前，它不具約束力——這使得採用程度成為規格與實際保護之間的關鍵。

STVA 如何建構批准流程

步驟 1：交易承載資料綁定

在請求任何簽名之前，STVA 會將交易承載資料綁定到結構化、人類可讀的呈現形式。該綁定內容包括收款地址、確切的代幣或 ETH 金額、目標鏈 ID，以及所呼叫合約方法的描述。這能防止 UI 欺騙，因為被簽署的摘要包含渲染後的顯示內容，而不只是原始 calldata。

步驟 2：政策與角色檢查

在承載資料綁定之後，授權層會評估請求的簽名者是否持有執行該特定操作所需的角色或門檻。單一簽名者錢包檢查其金鑰；多重簽名金庫則檢查提案是否已達到所需的批准數。實作可以為每個操作編碼限制——例如對超過一定金額的轉帳要求更高的門檻——而無需更改底層合約邏輯。

步驟 3：人類可讀的確認關卡

廣播前的最後一步是確認，以自然語言呈現經綁定、經驗證的承載資料。簽名者看到的是由步驟 1 綁定所衍生的確切收款人、金額與方法名稱，而非前端的重新詮釋。只有在此關卡通過後，授權簽名才會被附加並提交交易。

在以太坊上構建的協議團隊，包括管理多重簽名控制的升級金鑰與金庫合約的團隊，是主要的實作對象。此模式也與在 Ethereum Magicians ERC 草案討論串 中討論的帳戶抽象化工作交會，社群辯論涵蓋技術規格細節以及對重度依賴多重簽名的 DeFi 協議的治理影響。在錢包層推動更智慧的交易驗證，也與以太坊短暫性 rollup 架構中正在探索的執行層變更相呼應——在那裡最終性假設與主網不同，驗證工具的重要性更為突出。

STVA 的主要效益與限制

• 承載資料綁定縮小了顯示與執行之間的落差，而這正是使盲簽名攻擊得以對散戶錢包與協議多重簽名奏效的關鍵。
• 授權政策檢查可按操作配置，讓團隊能對高價值或不可逆的操作設定更高的批准門檻，而無需部署新合約。
• STVA 並未消除憑證遭入侵或政策配置錯誤所帶來的風險；它必須與存取衛生、監控及事件回應流程搭配才能發揮效用。

STVA 提供的最明確效益是可審計性。由於綁定的承載資料是結構化的產物，每一次授權事件都會產生可驗證的紀錄，記載簽名者所見、所批准的內容與時間。DAO 治理操作、協議參數變更與金庫撥款都會產生鏈上日誌單獨無法提供的審計軌跡。

次要效益是減少錯誤。當確認關卡呈現來自綁定步驟的確切收款人與金額時，手滑錯誤、地址投毒與剪貼簿劫持攻擊都會在人工審核層被攔截，而非在廣播後才被發現。

其限制同樣具體。如果簽名者的私鑰遭入侵，STVA 的授權檢查仍會代表攻擊者通過。如果政策設定的門檻不夠高，共謀攻擊仍可達到法定批准數。ERC 草案明確指出，STVA 是一個驗證與授權框架，而非金鑰管理系統，其安全保證受限於其所運作的憑證與政策的完整性。

評估 STVA 的協議團隊應將其視為縱深防禦體系中的一層。互補的控制措施包括硬體簽名者強制執行、執行時間鎖、對簽名者活動的異常監控，以及經過充分測試的事件回應手冊。STVA 提高了成功攻擊的成本；但它並未將該成本降為零。由於 STVA 仍處於草案階段，其所針對的盲簽名與顯示欺騙攻擊途徑在現今的簽名工具中仍然存在；研究與 Magicians 討論串如何塑造其需求，以及錢包與多重簽名實作是否採納「先驗證、後授權」模式，是後續值得關注的重點。

來源：DefiLiban