經過十天在 Devcon 7 與 Side events 的密集學習，我想透過這篇文章濃縮我的所學，並總結幾個關鍵主題，讓更多人了解以太坊生態在各個技術面向上的最前沿發展、正在解決的問題，以及未來可達到的理想狀態。本文章將涵蓋以下主題：

Infrastructure：以太坊一切的基礎
Usability：如何提升錢包與 DApp 的易用性
Dev Tools：開發流程中可使用的工具
Security：個人與協議如何保護自己的安全
Fuzz Testing：如何快速發現智能合約的深層問題
Formal Verification：透過數學證明智能合約的正確性
Maximal Extractable Value (MEV)：如何讓使用者避免 MEV 攻擊
Zero Knowledge Proof (ZKP)：應用與基礎設施的最新進展
Multi Party Computation (MPC)：保護隱私的最新研究與挑戰
Programmable Cryptography：下一世代密碼學的研究與展望

除了 Devcon 主場館的演講與體驗活動，我個人更喜歡參加特定主題的 side events。這些活動不僅能深入學習相關領域的知識，還能遇到志同道合的專家進行交流。例如在一場關於 zkTLS 的活動中，我有機會直接向項目方請教文件中不太理解的部分，這段經歷讓我印象深刻。未來若有類似的大型研討會，我也強烈建議大家多參加與自己興趣相符的 side events。

以下正文開始。

Part 1: Infrastructure

以下將從成就、現況與未來三個面向，詳細闡述以太坊如何透過技術創新解決當前挑戰，並為未來的擴容與去中心化鋪路。

成就：手續費降低與一流的穩定性

坎昆升級大幅降低 L2 手續費

今年的坎昆升級帶來了前所未有的成本優化。得益於 EIP-4844 引入的 DAS 技術（Data Availability Sampling）與 Blob 機制，L2 現在可以以更低的成本將更多資料儲存到以太坊主網，使每筆交易的費用降至不到 $0.01 美金，讓 L2 的使用更加經濟實惠

Client Diversity 的成功實踐

以太坊的 Client Diversity 是其穩定性的重要基石。運行以太坊節點的程式（Client）有多套選擇，例如 Geth、Nethermind 和 Reth，每套程式的開發團隊分布於不同地區，程式碼基礎也完全獨立。知名的執行層 Client 就有 Geth, Nethermind, Reth 等等。

關鍵價值：即使某個 Client 出現 Bug，也不會影響整體網路，因為每個 Client 的使用比例均低於 50%，而以太坊的共識機制是至少需要 2/3 的節點同意才能讓區塊 Finalize，因此能夠避免單一 Bug 導致整條鏈分岔
歷史案例：早期以太坊只有 Geth 與 Parity 兩個 Client，在某次 Client 發生重大問題時，Client Diversity 幫助以太坊維持了整條鏈的穩定運行。
理想狀況：最理想的分佈是所有 Client 各自佔比低於 1/3，這樣即便某個 Client 出現問題，也不會影響區塊的最終確認（Finalization）。

以太坊算是目前在 Client Diversity 上做得最好的公鏈。

交易確認效率顯著提升

以太坊的 Transaction Inclusion（交易納入）能力相較兩年前有了很大進步。如今，絕大多數交易可在 6~30 秒內完成確認，避免了過去常見的交易延遲數分鐘甚至被節點丟棄的問題，為用戶帶來更穩定的交易體驗。

現況：Rollup 的挑戰與安全性

自 2020 年 Vitalik 確立了以太坊的 Rollup Centric 擴容路線圖 以來，整個生態系已經誕生了數百條 L2 鏈。在這一架構下，L1 作為基礎設施的角色，提供高度穩定、安全且可信中立的保障，而 L2 則像 GPU 一樣，針對特定應用進行加速，顯著提升每秒交易次數。然而隨著 L2 的快速增長，也暴露了一些挑戰。

L2 的信任假設與分級安全模型

目前許多 L2 項目仍基於強信任假設，某些 L2 項目方甚至擁有凍結用戶資金或停止整條鏈運作的權力。為了更清楚地衡量 L2 的安全性，業界將其分為三個階段：

Stage 0：完全中心化的 L2。Stage 0 是最基本的 Rollup 實現，只需定期將數據提交到以太坊主網即可運行，但這意味著資金安全性完全依賴項目方。這種設計類似於腳踏車的輔助輪，主要用於幫助項目快速上線運作。
Stage 1：基礎的 Rollup 證明與治理機制。在 Stage 1 中，L2 至少實現了一種 Rollup 證明系統，例如 Optimistic Rollup 的 Fraud Proof 或 ZK Rollup 的 ZK Proof。這些證明由智能合約驗證 L2 狀態的有效性。此外，項目方需引入 Security Council 作為治理機制，對協議的關鍵修改需多數成員同意，並確保項目方無法在 Security Council 中占據絕對多數。
Stage 2：去中心化與雙重證明系統。在 Stage 2，L2 不僅需要實現兩種獨立的證明系統，還需將絕大部分控制權交由智能合約處理。Security Council 僅在證明系統出現衝突時介入，選擇接受哪一種證明系統。這種設計最大程度地限制了項目方的權力，真正實現了去中心化與安全性的平衡。

在這三個階段中，最大的差異在於「項目方做壞事的難度」。在 Stage 0，項目方完全掌控，幾乎沒有任何限制。Stage 1 引入了證明系統與治理機制，儘管攻擊者可能通過賄賂 Security Council 成員等方式發起攻擊，但成功的難度已顯著提高。而 Stage 2 則徹底消除人為干預的可能性，實現了理想的去中心化。

目前的 L2 發展現狀與挑戰

目前，大多數 L2 項目仍處於 Stage 0 或 Stage 1。雖然這些項目標榜去中心化，但實際安全性與項目方的宣傳往往存在差距。專注於 L2 安全分析的網站 l2beat 提供了最新且詳細的報告，幫助用戶了解項目方的真實安全實現是否達標。他們的研究深入程式碼層面，揭露了許多項目過於依賴行銷術語而忽視技術實現的現象。

Escape Hatch：L2 安全性的核心機制

L2 必須具備一項關鍵功能，即 Escape Hatch（逃生艙） 機制，來應對項目方的 Operator 或 Sequencer 停止運作時的突發情況。這項機制允許用戶生成自己在 L2 上持有資金的證明，並將該證明提交到 L1 的治理智能合約以贖回資金。整個過程必須在沒有項目方介入的情況下完成，才能充分體現 L2 的安全性。

例如 dydx 發行的 L2 在這方面表現出色。當他們的 L2 決定停止營運時，提供了工具讓用戶自行將資金轉回 L1，確保了用戶資金的安全。

L1 的擴容需求與去中心化的堅守

為了應對未來可能的大量 L2 逃生交易，L1 必須持續擴容。然而，Vitalik 多次強調，在擴容過程中，不能為了短期內的大幅擴容而妥協去中心化。一旦去中心化特性被犧牲，將難以挽回。這種堅守是以太坊作為可信中立基礎設施的核心價值。

未來：以太坊的進化方向與長期願景

以太坊在未來將迎來多方面的技術革新，從 L2 的進一步去中心化，到 L1 的性能優化，乃至於共識層的全面重寫，這些計劃都旨在推動以太坊邁向更加高效、安全且去中心化的區塊鏈生態。

L2 邁向 Stage 2：實現真正的去中心化

L2 的發展方向之一是推動更多項目邁向 Stage 2，這是去中心化與安全性的理想平衡點。Vitalik 明確表示，未來他只會將達到 Stage 1 的 Rollup 稱為 Rollup，而未能進一步邁向 Stage 2 的項目，將難以滿足以太坊的長期願景。在 Stage 2，L2 將依賴雙重證明系統，並將控制權完全交由智能合約處理，進一步降低對人為干預的依賴。

降低驗證門檻：讓更多人參與以太坊網路

未來的目標是讓更多人能輕鬆參與以太坊節點的驗證。這包括：

開發類似 Helios 的 Light Client，讓運算資源有限的設備也能運行以太坊驗證程式，實現節點運行的輕量化。
將 Stake ETH 作為驗證者的門檻從 32 ETH 降低到 1 ETH，讓更多用戶能參與驗證，進一步分散網路風險。
減少對 Lido 等 Liquid Staking Provider 的依賴，避免因過度集中化帶來的風險。

這些措施旨在提升以太坊網路的去中心化程度，確保其穩定性與長期可持續發展。

執行層的持續擴容：TPS 邁向十萬級別

目前 L1 每個區塊的 Blob 數量與大小存在限制，導致 L2 在現階段的理論 TPS（每秒交易次數）僅達幾千筆。然而，未來希望通過擴展 Blob 機制，如引入 PeerDAS 技術，實現每秒十萬筆交易的目標。這將大幅提升以太坊的可擴展性，為高頻交易應用場景鋪平道路。

共識層的革命性變革：Beam Chain

以太坊的共識層將迎來一項重大改變，即 Beam Chain 的引入。這是 Justin 提出的對現有 Beacon Chain 的全面重寫，旨在解決當前最棘手的問題，並邁向以太坊的終極目標（End Game）。主要的改進方向包括：

抗量子電腦：隨著量子電腦技術的發展，現有的橢圓曲線簽章（ECDSA）面臨被破解的風險。因此，遷移到後量子密碼學簽章成為當務之急。
更快的 Finality：目前以太坊達到最終共識（Finality）的時間約為 15 分鐘，而理想目標是 12 秒（Single Slot Finality）。更快的最終確認能大幅提升用戶體驗，特別是在中心化交易所的資金存取等場景中。
ZK Provable：隨著驗證者數量的增加，如何降低驗證者資源需求成為一大挑戰。通過結合 ZK 技術 和 簽章聚合（Signature Aggregation），驗證者能快速驗證數萬個其他驗證者的簽章，在四秒內處理完一個 Block。然而，現有的 BLS 簽章 基於橢圓曲線密碼學，也需進行抗量子攻擊的改寫，才能滿足未來需求。

圖中綠色的項目可以透過對共識層漸進式的改動完成，然而紅色項目最為棘手，需要重寫核心程式碼，Beam Chain 因而被提出作為解決方案。

極度嚴謹的工程精神與長期路線圖

Beam Chain 的引入需要對核心程式碼進行全面重寫，不僅能解決現有技術債，還能從過去的經驗中汲取教訓。根據初版 Beam Chain Roadmap，整個升級計劃將分為三個階段：

一年內完成規格定義。
1~2 年完成實作。
1~2 年進行完善與全面測試。

這體現了以太坊對去中心化的堅守以及對安全性的極高要求，畢竟整個網路承載了數千億美元的資金，任何小差錯都可能導致災難性後果。然而，也有許多社區成員批評五年的時間表過於冗長，期待能加速進度。Justin 表示，這其中的確存在優化空間，他也希望更多人參與討論與實作，共同推動這一計劃的實現。

需要注意的是，Beam Chain 並非以太坊未來五年的唯一重點。在共識層進行升級的同時，執行層的改進（例如透過 PeerDAS 提高 TPS）將持續推進，為應用開發者與用戶提供更高效能與更流暢的體驗。

參考連結

Part 2: Usability

隨著 ERC-4337 帳戶抽象 標準的定案與上線，各式各樣的 Smart Wallet（智能錢包）應運而生，大幅提升了使用者的體驗與易用性。然而，這些創新同時也對錢包和 DApp 帶來了新的技術挑戰。另一方面，隨著 L2 的蓬勃發展，資產碎片化問題日益顯著，許多協議與應用開始朝向 Intent Centric Design 和 Chain Abstraction 的方向發展，力求解決這些問題，讓使用者能更快速完成複雜的跨鏈交易，並將相關細節隱藏於背後。以下將逐一探討這些技術。

Smart Wallet (ERC-4337)

ERC-4337 標準讓智能合約錢包日益普及，其中最具特色的一類便是 Passkey 錢包。使用者只需透過生物認證即可創建 Passkey，並將其作為錢包的私鑰進行簽名。每次發送交易時，使用者只需再次進行生物認證，完全不需要記憶或保存助記詞，這被許多人視為錢包的「終極體驗」。

Passkey 簽章的技術挑戰

Passkey 錢包的核心在於智能合約中如何驗證 Passkey 的簽章。Passkey 簽章使用的是 secp256r1 橢圓曲線（又稱 P-256 簽章），而以太坊原生支持的是 secp256k1。兩者雖然只在橢圓曲線的參數上有所差異，但帶來了巨大的 Gas 成本差距：

secp256k1 簽章的驗證只需使用以太坊內建的 precompiled contract，Gas 成本約為 3000。
Passkey 簽章（P-256） 的最佳實作目前需要約 30 萬 Gas，是前者的 100 倍。

為了解決這一問題，RIP-7212 提案被提出，旨在降低驗證 Passkey 簽章的成本。通過該提案後，Gas 成本有望降至約 3000，與 secp256k1 簽章驗證相當，從而顯著減輕用戶負擔。

Passkey 錢包的共同挑戰

即使在成本降低的前提下，Passkey 錢包仍面臨以下幾個技術挑戰：

Passkey 與域名唯一綁定：Passkey 是綁定特定域名的。例如，Coinbase Smart Wallet 使用的 Passkey 綁定於 keys.coinbase.com。這樣的設計完全杜絕了釣魚攻擊，但也帶來了域名過期或單點故障的風險。
錢包碎片化：每個 Passkey Wallet 綁定不同的域名，導致使用者必須在不同應用中創建多個錢包，進一步加劇資產碎片化問題。
互通性問題：由於 Passkey 錢包的私鑰存儲於裝置的安全儲存空間，不支援匯出，且在 Android 和 iOS 之間也無法互通，使用者難以在一個地方統一管理資產。
盲簽的安全風險：在簽名過程中，使用者僅會看到「是否同意此應用使用這把 Passkey」的提示，無法查看具體簽名內容，導致高資安風險。若錢包前端遭受 XSS 攻擊，用戶資產可能被盜。

這些挑戰讓部分人質疑 Passkey 作為錢包私鑰的適用性，認為其設計初衷是用於 Web2 登入場景，對於 Passkey 丟失風險的影響較小，隨時都能透過「忘記密碼」功能找回帳號，而且不需展示具體簽名內容。但這不代表 Passkey 無法成為錢包的一部分，未來的錢包設計或許可以借鑒 Web2，提供多種驗證與帳號恢復選項，並依需求設置不同權限。

其他錢包驗證與恢復機制：ZK Email 的創新

除了 Passkey，ZK Email 團隊提出了一種基於 Email 還原錢包控制權的機制。使用者可以將指定 Email 地址設為合約錢包的「監護人」（Guardian）。當私鑰丟失時，用戶只需從該 Email 發送一封信，包含合約錢包地址及新控制地址等資訊，即可生成 ZK 證明，在鏈上驗證後取回錢包控制權。這一設計基於多年發展的 Email 基礎設施，安全性高且操作便捷，有效減少了私鑰丟失帶來的風險。

ERC-4337 的互操作性問題與解決方法

隨著 Passkey 和 ZK Email 等機制的應用，ERC-4337 錢包面臨著顯著的互操作性挑戰。例如，當使用者在 A 錢包中建立了 ERC-4337 合約錢包，若希望匯出至 B 錢包使用，可能因兩者使用的 Account Factory Contract 不同而無法相容。這導致：

B 錢包無法辨識 A 錢包所使用的簽章方法。
B 錢包無法支援發送 A 錢包的交易。

為了解決這一問題，業界提出了 模組化合約錢包標準，例如 ERC-7579 和 ERC-6900。這些標準將 ERC-4337 的功能進一步模組化，例如：

授權模組：可以用 Passkey 或多簽驗證替換。
交易執行模組：可根據應用需求更改，例如如何批次執行交易。
權限模組：支持靈活的權限配置。

這樣的設計允許所有錢包應用共用同一個 Account Factory Contract，並能夠靈活組合不同模組，極大提升互操作性，減少資產管理的摩擦成本。

Smart Wallet (EIP-7702)

EIP-7702（Set EOA Code）是下一代帳戶抽象標準，預計將在下一次以太坊 Pectra 硬分岔 中被納入。這項提案的初衷在於解決 ERC-4337 的一個關鍵限制：使用者需要創建新的智能合約錢包，無法延續過去的 EOA（Externally Owned Account）。EIP-7702 則提供了一個全新解法，允許任何 EOA 地址「升級」為智能合約錢包，帶來多樣化的靈活功能：

批次執行交易：將 DeFi 操作中的多次簽名（如 Approve + Swap）簡化為一次簽名即可完成。
Gas 贊助：EOA 不必持有 ETH，也可以透過其他地址代為支付交易所需的 Gas。
彈性的權限設定：支持 Passkey 或多簽等驗證邏輯，讓 EOA 具備更多智能化功能。

EIP-7702 的應用案例

Ithaca 團隊在 EXP-0001 中展示了 EIP-7702 的 Demo，讓使用者可以一鍵創建 Passkey 並將 EOA 地址的權限代理給該 Passkey。此後，所有交易只需 Passkey 簽名即可完成，且已在測試網中部署了 RIP-7212（Passkey 簽章優化）的實作，顯著降低了 Gas 成本。借助這一技術，EOA 可透過單一 Passkey 簽章執行多筆交易，進一步提升使用者的便利性。

EIP-7702 的技術流程

EIP-7702 的核心在於如何將 EOA 地址綁定智能合約邏輯，其具體流程如下：

授權請求：使用者擁有一個 EOA 地址（假設為 A），希望將其升級為智能合約錢包，並選擇一個智能合約實作地址（S）。
生成授權簽章：使用 A 的私鑰簽署一個授權訊息，包含鏈 ID、nonce，以及 S 的地址等資訊。
提交授權交易：若 A 沒有 ETH，可將授權簽章提交給 Relayer，由 Relayer 代為支付 Gas，將授權訊息上鏈。
存儲合約邏輯：交易完成後，A 的 Account Code Storage 將儲存 S 的地址。
執行合約邏輯：未來 A 發送交易時，Relayer 可以呼叫 A 地址並傳入交易參數，A 的 Account Code 會在執行過程中改寫為 S 的邏輯，實現智能化功能。
取消授權：若使用者希望取消授權，可使用 A 的私鑰簽署取消請求，並提交至鏈上。

安全挑戰與潛在風險

雖然 EIP-7702 的功能十分強大，但也帶來了一些新的安全風險：

授權惡意合約的風險：如果使用者不小心簽署了一個惡意 EIP-7702 簽章，攻擊者可藉助合約邏輯批次轉移使用者的所有資產，包括 Token、NFT 和 DeFi 倉位。相比現有的 Permit Signature，EIP-7702 的潛在風險更高。
跨鏈授權的風險：簽署授權訊息時，若使用 chain ID = 0，表示簽章對 所有 EVM 鏈 生效。一個簽章可能導致所有鏈上的資產同時暴露於風險，效果等同於私鑰洩漏。

跨鏈授權的安全考量

EIP-7702 的設計中，簽章包含 Account Nonce，這代表若不同鏈上的地址 nonce 不同，簽章將無效。這一設計可以讓錢包 App 通過一個簽章升級用戶的地址至所有鏈上的合約錢包，提升便利性。然而開發者在設計時需謹慎處理 nonce 機制，避免出現不必要的安全漏洞。

至於可能會授權惡意合約的問題，錢包 App 可採取以下措施：

引入「白名單」系統，對合約地址進行驗證。
透過界面提示用戶授權的合約邏輯是否安全。

EIP-7702 與 ERC-4337 的互補性

EIP-7702 的核心優勢在於支持將現有的 EOA 升級為智能合約錢包。然而，這也帶來一個限制：EOA 的私鑰始終擁有最高權限。如果私鑰洩漏，將直接導致錢包的控制權喪失。而 ERC-4337 可以實現多簽錢包等無需依賴單一私鑰的設計，提供更高的安全性。因此，EIP-7702 與 ERC-4337 之間並非相互替代，而是互補的關係。EIP-7702 彌補了 ERC-4337 在 EOA 過渡上的不足，而 ERC-4337 則提供更高的安全保障，適用於對安全性有更高需求的場景。

Smart Session

雖然智能錢包（Smart Wallet）帶來了許多創新，但它們的出現並不代表 DApp 的使用體驗會自動變好。錢包與 DApp 之間的溝通方式需要進一步的協調和標準化，才能真正實現流暢的使用體驗。

DApp 與 Smart Wallet 的兼容挑戰

在傳統的 EOA 設計中，DApp 發送交易通常是通過簡單的 eth_sendTransaction 介面向錢包發送請求。然而，Smart Wallet（如基於 ERC-4337 的智能合約錢包）需要一種全新的操作模式。ERC-4337 引入了 User Operation 的結構作為核心元件，但問題在於許多現有 DApp 並不知道如何生成 User Operation 的資訊。這導致 Smart Wallet 與當前 DApp 生態的兼容性大打折扣。

為了解決這一問題，社群內正在討論如何統一相關介面，其中一些重要的提案包括：

EIP-5792：幫助 DApp 確認錢包支持哪些 Smart Account 的功能。
ERC-7677：指導 DApp 如何生成 User Operation 中的 paymasterAndData 欄位。
ERC-7679：提供生成完整 User Operation 的規範。

這些提案的目的是讓 DApp 能更輕鬆地與 Smart Wallet 互動，提升其易用性並加速智能錢包的普及。

Smart Session 的概念與理想體驗

除了介面統一外，另一個重要的改進方向是提升錢包與 DApp 的交互體驗，減少使用者需要反覆操作錢包的次數。Reown（前 WalletConnect）的創始人提出了 Smart Session 的概念，旨在簡化操作流程並提供 OAuth 式的授權體驗。理想中的使用場景如下：

初始授權：使用者登入 DApp 時，DApp 向錢包請求授權，並說明需要執行的交易範圍（例如 Uniswap 請求 Approve 與 Swap 的權限）。
生成 Session Key：使用者在錢包中點擊同意後，DApp 獲得一個 Session Key，該 Key 對應於使用者同意的授權範圍。
簡化交易簽署：當使用者操作 DApp 並需要發送交易時，DApp 使用 Session Key 簽署交易並提交到鏈上，過程中無需用戶再次確認。

透過 Smart Session，使用者的點擊次數可以減少到僅需一次，同時授權流程變得直觀，類似 Google 或 Facebook 的 OAuth 體驗。這種設計符合錢包與 DApp 連接的終極目標：「Less Clicks & More Control」，即在減少用戶操作的同時，保持用戶對授權的完全掌控。

安全風險與解決方案

Smart Session 雖然優化了使用體驗，但也帶來了一些安全風險，尤其是 Session Key 洩漏的可能性。考慮到瀏覽器端是前端攻擊（如 XSS）的高發地點，如何安全地儲存與管理 Session Key 是必須解決的問題。

Passkey 是實現 Session Key 安全存儲與簽名的良好選擇，因為它能大幅降低洩漏風險。同時，Session Key 的設計應保證丟失後對用戶的影響最小，用戶只需重新授權即可恢復使用。

Intent Centric Design

隨著上百條 L2 的誕生，使用者的資產逐漸分散到不同鏈上。這種分散性帶來了跨鏈操作的複雜性，不僅速度慢，體驗也相當不友好。在應用層面，越來越多的協議開始採用 Intent Centric Design（意圖導向設計）來解決這些問題。這種設計理念的核心在於，用戶只需表達自己的目標意圖（Intent），而不需要關心具體實現方式，將操作的複雜性交由 Solver（解決者）處理。從過去的「自行開車到目的地」到如今「叫 Uber 即可」，這正是 Intent Centric Design 帶來的使用體驗轉變。

ERC-7683：跨鏈意圖的標準化實現

ERC-7683 是由 Uniswap 和跨鏈橋 Across 提出的跨鏈意圖標準，它讓用戶只需簽署跨鏈操作的意圖，由 Solver 負責完成具體請求，支援以下常見場景：

資產跨鏈移動：將 A 鏈上的 X Token 移動到 B 鏈。
跨鏈資產兌換：在 A 鏈上的 X Token 換成 B 鏈上的 Y Token。
跨鏈後的複合操作：在完成跨鏈兌換後執行目標鏈上的合約操作，例如購買 NFT。

使用者只需一鍵操作，即可完成如「將 ETH 從以太坊跨鏈至 Arbitrum 並購買 NFT」的複雜任務，且整個過程可在三秒內完成。

ERC-7683 的操作流程如下：

記錄意圖：使用者在 A 鏈將資產存入 ERC-7683 合約，並記錄其操作意圖（Intent）。
Solver 鎖定意圖：Solver 監聽 Intent，判斷是否符合其能力與利潤需求，然後在 A 鏈鎖定該 Intent。
執行跨鏈意圖：Solver 在 B 鏈墊付資金完成用戶的目標操作，例如轉移 Token 或兌換資產。這種「先墊款後操作」的模式大幅提升操作速度。
結算與支付：協議在 A 鏈上基於 B 鏈的最終狀態（finalized state）每小時進行結算，計算 Solver 的服務費並支付。

使用者支付的手續費基本等同於一小時的借貸利息。這種模式比傳統基於訊息的跨鏈協議效率更高，因為其採用了批次結算方式，減少了跨鏈訊息傳輸的成本，無需每筆交易都傳送一個跨鏈的訊息。

靈活性與挑戰

ERC-7683 允許開發者自定義結算邏輯，讓合約決定支付 Solver 的條件。這樣的靈活性也帶來以下問題：

流動性碎片化：Solver 可能因不熟悉或信任特定的結算邏輯，而選擇不參與某些合約的 Intent，導致不同 Settlement 合約間的流動性缺乏競爭性。
安全性風險：若結算合約出現問題，Solver 可能無法收回墊付資金，增加了參與風險。

為解決這些問題，可在 Settlement 合約採用模組化設計，讓結算邏輯簡單易懂且易於審計，從而吸引更多 Solver 提供流動性。

ERC-7683 與 EIP-7702 的結合應用

未來結合 EIP-7702，ERC-7683 能實現更高效的跨鏈操作。例如，透過一個 chain ID = 0 的簽章升級所有 EVM 鏈的 EOA 為智能合約錢包，使用者可將 Intent 設定為「在 B 鏈執行某操作」，並以目標鏈上的身份完成交易。這樣，用戶可在 A 鏈上管理資產，同時請求 Solver 在其他鏈執行交易並支付對應的 Gas。此過程中，Solver 的角色不僅執行交易，還幫助減少 Gas 成本，實現完全去中心化的解決方案。

CoW Swap 的 Intent 解決方案

CoW Swap 在單鏈場景中推動了 Intent 的應用，專注於優化 Swap 體驗。其核心特點包括：

聚合多個 Intent：Solver 可同時計算多個 Intent 的最佳交易路徑，例如同時滿足 A 使用者想用 X Token 換 Y Token，與 B 使用者想用 Y Token 換 X Token 的需求。
減少手續費：此方法避免了使用者分別與流動池進行交易的成本，帶來理論上的最佳價格。

然而，CoW Swap 的解決方案對 Solver 提出了極高的技術要求：

流動性獲取：必須快速從多個 DEX、中心化交易所（CEX）及跨鏈資源中獲取流動性。
演算法優化：如何快速聚合並計算最優交易路徑仍是未解的最佳化問題。
精準執行：在鏈上執行交易時需避免 MEV（最大可提取價值）攻擊，同時在 CEX 執行交易也需確保價格的精準度。

其他 Intent 案例：Daimo 的 Cross L2 Intent Address

在交易場景的 Intent 解決方案之外，Daimo 提出了 Cross L2 Intent Address 的設計，為跨鏈支付與 DeFi 操作帶來了更高效的方式。該設計允許使用者在 source chain 上將 USDC 發送到一個指定地址，通過 relayer 在 destination chain 執行後續操作，例如將 USDC 跨鏈後進行特定的 DeFi 操作。整個過程完全去中心化，適用於跨鏈支付、一鍵投資等場景。

技術實現原理

這一設計的核心依賴於 Circle 的 CCTP 跨鏈橋 和以太坊的 CREATE2 機制，通過結合這兩者實現用戶 Intent 的自動化執行。

CCTP 的目標地址指定：在使用 Circle 的 CCTP 跨鏈橋時，用戶可以指定目標鏈上的接收地址。如果該地址是一個智能合約，relayer 就能在接收 USDC 前執行合約中定義的操作。執行完成後，relayer 再通過 CCTP 獲取跨鏈的 USDC 作為報酬。這種機制使得 relayer 能在資金到達前完成用戶的 Intent，大幅提升交易速度與用戶體驗。
CREATE2 的地址預計算：在 source chain 上，使用者需要事先確定目標鏈上的 Intent 合約地址。這可以通過 CREATE2 機制實現：CREATE2 允許在合約未部署時就計算其未來地址，只需提供合約的 byte code 和一個 salt。這樣，用戶在 source chain 上的操作即可預先確定目標鏈的合約地址。
Relayer 的執行流程：首先在 destination chain 部署智能合約，並呼叫智能合約以執行用戶的 Intent（例如參與 DeFi 協議）。最後在同一交易中呼叫 selfdestruct，清空合約的 code storage 並獲得 gas fee refund。

這種做法相比 ERC-7683 更簡單，但需要在交易過程中部署合約，導致增加一些 gas 費用。不過，由於部署的合約只是小型的 proxy contract，指向預先部署好的 implementation contract，因此額外成本相對有限。

Chain Abstraction

Chain Abstraction 的核心理念是隱藏區塊鏈的存在，讓使用者專注於資產本身，而非背後的鏈。這意味著使用者只需知道自己擁有多少 USDC、ETH 等資產，而不用關心它們分散在哪些鏈上。當使用者發起 USDC 的轉帳時，系統會自動檢測並整合所有鏈上的 USDC，完成轉帳所需的跨鏈操作。同時，使用者不需要為 Gas 費煩惱，可以直接用轉帳的 USDC 支付 Gas。

Biconomy Modular Execution Environment

Biconomy 提供了 Modular Execution Environment (MEE) 解決方案，專為支持 Chain Abstraction 而設計。這個系統允許 ERC-4337 錢包的開發者輕鬆定義跨多鏈的操作，並將其整合為一個 Supertransaction。使用者僅需簽署一次對 Supertransaction 的授權，即可實現以下功能：

在多條鏈上執行指定的 User Operations。
自動完成跨鏈操作並達成最終目標。

其技術基礎在於用戶對所有操作生成一個 Merkle Root Hash 簽章，然後透過 Modular Execution Environment 自動將這些操作上鏈執行。

其他解決方案

多家公司也提出了不同形式的 Chain Abstraction 解決方案：

ZeroDev：提供了類似的 SDK，讓開發者可以方便地批量發送多鏈交易，簡化操作流程。
OneBalance：提供了 Credible Account 模組，支持整合多鏈的資產並實現 Chain Abstraction。
Particle Network：採用 Account-level Chain Abstraction，專注於網頁錢包的體驗，率先打造具有 Chain Abstraction 的應用。
Nekodex：結合 Chain Abstraction 以及基於 Passkey 的 Account Abstraction 統一 DEX 上多鏈的交易體驗，降低使用門檻

參考資料

Part 3: Dev Tools

以太坊的開發生態持續進步，各種工具大幅提升了開發者的效率，無論是在測試網的模擬、智能合約的除錯，還是區塊鏈資料的索引，都有顯著的創新。以下是幾款值得關注的工具與解決方案。

Tenderly Virtual Test Net

Tenderly Virtual Test Net 是一個強大的虛擬測試網工具，允許開發者 fork 主網，其特色是能與主網保持即時同步狀態。同時它支援：

無限制的資源模擬：開發者可以隨時取得測試網上的以太坊或任意修改 Storage 狀態。
CI 整合：通過 Github Action，開發者能快速生成乾淨的測試環境，用於合約部署與自動化測試。

Simbolik

Simbolik 是專為 Solidity 開發設計的除錯工具，與 VS Code 無縫整合，只要在測試上方案下 Debug 就能執行。它的功能包括：

完整的 EVM 環境可視化：能即時檢查每行 Solidity 代碼執行時的 stack、memory 和 storage 狀態。
EVM bytecode 分析：直觀展示編譯後的 EVM bytecode 的執行過程。

Simbolik 為開發者提供了高效且細緻的除錯支持，幫助快速定位並解決合約中的問題。

TrustBytes

TrustBytes 是一款將 Solidity 程式碼轉化為 圖像化呈現 的工具，特別適合合約審計。它的核心功能包括：

函數調用關係可視化：清晰顯示合約中所有函數之間的調用路徑。
變數讀寫追蹤：快速定位變數的讀寫位置，分析潛在 Re-entrancy 風險。
惡意輸入分析：標示出哪些函數參數來自使用者輸入，幫助預防惡意攻擊。

TrustBytes 通過縮短代碼追蹤的時間以提升審計效率，特別是在分析潛在攻擊點方面。可參考其 Demo 網站。

Ethereum Indexer

以太坊的資料結構讓直接從 JSON RPC 獲取資料效率低下，因此需要透過 Indexer 將資料提取並存儲到高效的資料庫中。以下是兩個值得關注的解決方案。

Index Supply 的 Shovel

Shovel 是一款開源工具，允許開發者透過簡單的 config 檔，將鏈上資料轉化為指定格式並儲存到 PostgreSQL DB。例如，紀錄一個錢包的歷史 ERC20 Token Transfer 可以這樣設定：

{
"name": "erc20_transfers",
"enabled": true,
"sources": [{"name": "mainnet"}],
"table": {
"name": "erc20_transfers",
"columns": [
{"name": "block_num", "type": "numeric"},
{"name": "tx_hash", "type": "bytea"},
{"name": "from", "type": "bytea"},
{"name": "to", "type": "bytea"},
{"name": "value", "type": "bytea"},
]
},
"block": [
{"name": "block_num", "column": "block_num"},
{"name": "tx_hash", "column": "tx_hash"}
],
"event": {
"name": "Transfer",
"type": "event",
"anonymous": false,
"inputs": [
{"indexed": true, "name": "from", "type": "address", "column": "from"},
{"indexed": true, "name": "to", "type": "address", "column": "to"},
{"name": "value", "type": "uint256", "column": "value"}
]
}
}

透過簡單的配置，Shovel 能快速完成資料的提取與存儲，大幅降低開發成本。

Reth Execution Extension

Reth Execution Extension 提供了一種新穎且高效的設計，針對鏈上資料索引與 Re-org（鏈重組）處理，解決了傳統方法中的諸多痛點。

過去，如果使用 geth 等節點軟體來擴展功能，往往需要直接修改節點內的程式碼，這樣的做法相當於對節點進行了 fork。一旦上游節點有更新，開發者還需要持續合併更新的程式碼，這無疑增加了開發與維護的複雜性。

Reth 的創新之處在於其設計為可直接作為 library import，開發者不需要 fork 或修改節點本身的程式碼，就能靈活擴展節點功能。

核心特點與通知機制

Reth 提供了清晰且靈活的通知介面，用於處理區塊鏈的三種狀態變化：

ChainCommitted：新區塊被確認（Committed）。
ChainReorged：鏈重組導致出現新舊鏈切換。
ChainReverted：區塊被 Revert

以下是範例程式碼展示如何處理這些通知：

async fn exex<Node: FullNodeComponents>(mut ctx: ExExContext<Node>) -> eyre::Result<()> {
while let Some(notification) = ctx.notifications.recv().await {
match &notification {
ExExNotification::ChainCommitted { new } => {
// do something
}
ExExNotification::ChainReorged { old, new } => {
// do something
}
ExExNotification::ChainReverted { old } => {
// do something
}
};
}
Ok(())
}

參考資料

Part 4: Security

安全問題一直是區塊鏈領域的核心挑戰，從開發環境的設置，到設備與用戶端的保護，再到 DeFi 合約層面的防禦，都需要嚴密的措施來降低風險。以下針對開發、設備與 DeFi 安全三大主題進行探討。

開發環境安全（Dev Security）

在區塊鏈應用的開發過程中，環境的安全性往往容易被忽視，但它可能成為駭客的突破口。

VS Code 信任機制的潛在風險

當開發者在 VS Code 中開啟一個惡意的 Repo 並點擊「Yes, I trust the authors」後，駭客可能利用 .vscode 資料夾內的設定執行任意腳本，包括：

竊取電腦中的 secret 或 private key。
開啟一個 reverse shell，讓駭客遠端控制電腦。

這是因為 .vscode 中的 Tasks 可以設置觸發特定條件的自動執行腳本（詳見官方文檔）。這種漏洞可能導致開發者的整個系統處於被駭客接管的風險中。

防範措施：使用 Sandbox 環境

為避免上述風險，開發者應在 Sandbox 環境 中開啟專案。具體來說，可以使用 VS Code 的 Dev Container 功能，在 Docker 容器中執行完整的開發環境。這樣即使惡意代碼執行，也只會影響隔離的容器，不會危及主機系統。

Github Action Self Hosted Runner 的風險

Self Hosted Runner 是 Github 提供開發者自行建置 CI 環境所需機器的解決方案。然而如果在 Public Repo 啟用 Self Hosted Runner 會帶來潛在威脅：

惡意用戶可以 Fork 該 Repo 並修改 Github Action 的腳本，執行任意命令。
這可能導致 Runner 被入侵，駭客竊取所有 Github Token 和 Secrets。

這一風險已被詳述於 Synacktiv 的報告。建議避免在 Public Repo 中使用 Self Hosted Runner，或採用更嚴格的權限管理。

設備安全（Device Security）

Ledger 的研究顯示 iOS 和 Android 平台的 Syncable Passkey 實作並不像預期中那麼安全。主要問題在於：

私鑰複製到應用程式記憶體：雖然 Passkey 本應依賴 Secure Enclave 來存儲私鑰，但實際上私鑰可能會被複製到應用程式記憶體（application memory）。這使得私鑰暴露於潛在的惡意軟體攻擊之下，例如透過監聽記憶體來竊取私鑰。
記憶體快取問題：某些平台的快取機制會在裝置解鎖之前就將私鑰暫存到記憶體中，進一步增加了被惡意軟體利用的風險。

安全建議

為了降低使用 Passkey 帶來的風險，建議採取以下措施：

選擇 Un-syncable Passkey：在創建 Passkey 時，選擇「不可同步」（Un-syncable）的選項，避免私鑰在不同設備之間同步時的潛在安全問題。
避免存放大量資金：不要將過多資金存放於 Passkey 錢包中，僅作為小額支付或日常操作使用。
使用硬體錢包：對於高價值資產，建議繼續使用硬體錢包作為主要的存儲方式，因為硬體錢包提供了更高的安全保證。

這些建議可以有效降低 Passkey 在日常應用中的潛在風險，同時確保資產的安全性。

DeFi 安全（DeFi Security）

區塊鏈應用最核心的 DeFi 領域，因其高額資金流動性，成為駭客攻擊的主要目標。防範這類風險需要智能合約與基礎設施層面的共同努力。例如 Forta 提供了一種基於 AI 模型 的鏈上防火牆，用於過濾潛在攻擊交易。其運作機制如下：

交易簽名驗證：DeFi 合約需要為合約中的關鍵方法加上 Forta 的簽章參數
交易模擬與風險評估：Forta 的 RPC 節點將模擬交易執行過程，通過 AI 模型評估風險分數。Fora 已經實現 99% 以上的準確度
執行控制：只有風險分數低於門檻值的交易才會獲得簽名並被放行。

因此這個做法必須由 DApp 透過 Forta 提供的 RPC 發送交易才可以，如果使用公開的 RPC 則無法取得必要的簽章。但這也帶來潛在的問題與挑戰：

升級與整合困難：DeFi 協議需要修改合約以整合 Forta 的系統，這對現有協議的升級是一大挑戰，尤其是影響到可組合性，因為其他 DeFi 協議就無法輕易呼叫自己的合約。
交易模擬問題：在鏈下的環境模擬交易執行的結果可能與實際上鏈的結果不同，有機會被駭客利用
順序依賴問題：由於 L2 鏈上交易的執行順序是由 Sequencer 決定，駭客有機會透過交易順序的不一致性來在模擬時產生正常的結果，拿到簽章後上鏈執行惡意交易

至於如何解決第二個問題，知名交易安全檢測公司 Blowfish 的 CTO 提到，可以在模擬交易過程檢測該交易是否使用了與 EVM 環境參數相關的邏輯，例如 block.timestamp 或 block.basefee 等等，但也無法保證 100% 判斷正確，因此精準的交易模擬仍然是安全領域待解決的難題。

參考資料

Passkeys : the good, the bad, the ugly

Part 5: Fuzz Testing

Fuzz Testing 是一種強大的測試技術，其核心原理是透過大量隨機的輸入測試智能合約，試圖觸發意外的邏輯漏洞。這種方法對於捕捉人眼難以察覺的邊緣情境（corner cases）尤其有效。

Fuzz Testing 的原理與限制

Fuzzer 的主要作用是持續嘗試各種隨機輸入來檢測智能合約是否能滿足定義的 Invariant（不可變條件）。開發者可以利用這種方法進行黑箱測試，模擬合約的實際使用情境，並驗證其邏輯是否能抵抗各種異常操作。

儘管 Fuzz Testing 是捕捉邏輯漏洞的有效工具，但找不到漏洞並不代表合約沒有問題。Fuzzer 的效果取決於定義的 Invariant 是否完善，以及隨機測試的覆蓋範圍。

相關範例

以下是三個經典例子，說明如何使用黑箱的 Fuzz Testing 方法來檢測系統的正確性：

排序演算法測試：
原始輸入： 未排序的數字陣列 A。
隨機調整： 對 A 隨機打亂（Shuffle）後再排序，結果應與原始輸入排序結果相同。
驗證： 比較兩次排序的結果是否一致。
最短路徑演算法測試：
原始輸入： 圖 G 和兩個節點 n1 與 n2。
隨機調整： 從圖 G 移除某條邊後，n1 到 n2 的最短路徑應該變長或保持不變。
驗證： 比較移除邊前後的最短路徑。
編譯器測試：
原始輸入： 程式 P。
隨機調整： 在 P 中加入 Dead Code 後編譯，結果執行的行為應與原始程式一致。
驗證： 比較兩次執行結果。

使用 Chimera 撰寫 Fuzz Test

以下介紹如何使用 Chimera 框架來整合多種 Fuzzer 工具（如 Echidna、Medusa 和 Foundry）進行智能合約的 Fuzz 測試。

案例分析：Vesting 合約漏洞

以下是一個簡化的 Vesting 智能合約範例，其目的是實現用戶的積分分配與轉移，完整程式碼在 solidity-fuzzing-comparison Repo 中的 09-vesting 。然而，該合約存在一個漏洞：用戶可以通過「自我轉移」增加自己的積分，進而破壞總積分不變的 Invariant。

Vesting.sol 合約部分代碼：

// users entitled to an allocation can transfer their points to
// another address if they haven't claimed
function transferPoints(address to, uint24 points) external {
require(points != 0, "Zero points invalid");

AllocationData memory fromAllocation = allocations[msg.sender];
require(fromAllocation.points >= points, "Insufficient points");
require(!fromAllocation.claimed, "Already claimed");
AllocationData memory toAllocation = allocations[to];
require(!toAllocation.claimed, "Already claimed");
// enforce identical vesting periods if `to` has an active vesting period
if(toAllocation.vestingWeeks != 0) {
require(fromAllocation.vestingWeeks == toAllocation.vestingWeeks, "Vesting mismatch");
}
allocations[msg.sender].points = fromAllocation.points - points;
allocations[to].points = toAllocation.points + points;
// if `to` had no active vesting period, copy from `from`
if (toAllocation.vestingWeeks == 0) {
allocations[to].vestingWeeks = fromAllocation.vestingWeeks;
}
}

用戶可以將自己的積分轉移給自己（self-transfer），導致總積分超出限制，破壞合約中「所有用戶積分總和應等於總分數」的 Invariant。然而就算我們不細看 transferPoints 的實作，也能透過對其黑箱的 Fuzzing 來找到問題。

設計 Invariant：思考不可變條件

在測試此合約時，可以設計以下兩個主要 Invariant：

初始化階段：所有用戶的積分總和應等於 TOTAL_POINTS。
執行階段：在任意操作後，所有用戶的積分總和仍應保持不變。

這些 Invariant 可以被用於多個 Fuzzer 的測試過程中。

使用 Chimera 框架進行測試

Chimera 是一個功能強大的多工具整合框架，允許開發者一次撰寫測試代碼，並同時在多個 Fuzzer 工具上執行。以下是使用 Chimera 的步驟：

1、安裝 Chimera：forge install Recon-Fuzz/chimera

2、設定測試環境：建立一個 Setup.sol 文件來初始化測試合約，並追蹤需要檢查的狀態。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.23;

import { Vesting } from "./Vesting.sol";
import { BaseSetup } from "@chimera/BaseSetup.sol";

abstract contract Setup is BaseSetup {
Vesting vesting;

function setup() internal override {
address;
recipients[0] = address(0x1111);
recipients[1] = address(0x2222);
uint24;
points[0] = 50_000;
points[1] = 50_000;
uint8;
vestingWeeks[0] = 10;
vestingWeeks[1] = 10;

vesting = new Vesting(recipients, points, vestingWeeks);
}
}

3、實現 Invariant：定義檢查條件，例如所有用戶的積分總和應等於總積分。

function property_users_points_sum_eq_total_points() public view returns(bool result) {
uint24 totalPoints;

// sum up all user points
for(uint256 i; i<recipients.length; i++) {
(uint24 points, , ) = vesting.allocations(recipients[i]);

totalPoints += points;
}

// true if invariant held, false otherwise
if(totalPoints == TOTAL_POINTS) result = true;
}

4、定義如何測試目標函數：指定 transferPoints 參數需滿足的條件，避免因錯誤參數導致的 Revert

function handler_transferPoints(uint256 fromIndex, uint256 toIndex, uint24 points) external {
fromIndex = bound(fromIndex, 0, recipients.length - 1);
toIndex = bound(toIndex, 0, recipients.length - 1);

address from = recipients[fromIndex];
address to = recipients[toIndex];

points = uint24(bound(points, 1, vesting.allocations(from).points));

vesting.transferPoints(to, points);
}

5、執行 Fuzz Testing

forge test --match-contract VestingCryticToFoundry

可以看到 Fuzzer 在短時間內就找到了打破不變量的方法

修復漏洞

漏洞的解法是避免自我轉移：

function transferPoints(address to, uint24 points) external {
require(points != 0, "Zero points invalid");
require(msg.sender != to, "Self transfer invalid");
// ...
}

修復後再執行一次測試即可通過了

Fuzz Testing for ZK Infrastructure

零知識基礎設施（Zero-Knowledge Infrastructure, ZK Infra）涉及編譯、執行、生成證明與驗證 ZK 電路的多個核心軟體元件，對其進行漏洞檢測至關重要。Fuzz Testing 是檢測這些基礎設施漏洞的一項強大工具，尤其適合處理其高複雜性與高安全需求的特性。

基於黑箱測試的隨機變換與不變性檢測

零知識基礎設施的測試需要克服其內部實現的高度複雜性，黑箱測試因此成為檢測漏洞的有效方法。在這種測試中，開發者將處理流程視作不可見的黑箱，僅根據輸入和輸出進行分析。

首先，測試工具會隨機生成一個原始電路（C1），這些電路通常以小型 DSL（特定領域語言）描述，用於模擬用戶操作。接著，應用一系列隨機變換來生成新電路（C2）。這些變換包括乘以 1、加減隨機表達式或其他等價操作，保證電路語義不變。隨後將兩個電路各自進行 ZK 工具的編譯處理，若在任何階段輸出或行為不一致，即可定位到處理流程的漏洞。

例如，一個表達式 P 轉換為 P × 1 − 0 時，應保持輸出一致，否則可能指向 Witness Generator 或編譯器中的潛在問題。

持續且多元測試

由於零知識基礎設施經常被用於 Layer 2 協議，將乘載數億美金以上的價值，其安全性至關重要，因此持續測試顯得尤為必要。這可以通過自動化測試工具來實現，保證每次代碼更新後都能迅速發現潛在漏洞。

測試還需要支持多種零知識 DSL，如 Circum、Gnark 和 Noir，確保適用於廣泛場景。同時，Fuzz Testing 工具應具備自動化反饋功能，能夠持續執行並根據發現的問題進行改進。此外，測試生成的輸入應盡量簡化，以便開發者快速理解並定位問題。

參考連結

Part 6: Formal Verification

Formal Verification（形式化驗證）是一種透過數學方式驗證軟體是否符合特定 Formal Spec （規格）的技術。對於智能合約而言，這種方法能有效檢查合約在所有可能狀態下的正確性。與 Fuzz Testing（模糊測試）相比，Formal Verification 的驗證過程更為系統化，能夠覆蓋所有可能的狀態並「數學證明」合約邏輯的正確性。

然而，Formal Verification 的實施通常需要嚴謹的規格定義，且計算成本較高。另一方面，Fuzz Testing 則透過隨機輸入測試合約，具有輕量且能快速發現邊界問題的特性，但其測試範圍有限，可能無法檢測更深層的邏輯漏洞。

Certora

Certora 提供了一套完整的工具來彌補這些不足，幫助開發者在現實環境中應用 Formal Verification。其主要產品 Certora Prover 為智能合約提供了強大的驗證框架，允許開發者定義規則並自動化驗證合約的邏輯正確性。

Certora 提供的工具旨在簡化智能合約的形式化驗證過程，核心功能包括：

Certora Prover：一個驗證平臺，允許開發者使用 Certora Verification Language (CVL) 定義規格並測試合約邏輯。
整合式框架：透過設定檔與腳本執行驗證。
詳細報告：自動生成驗證結果，包含失敗的詳細原因與對應的測試輸入，協助快速定位問題。

使用 Certora Prover 於有漏洞的投票合約

以下是一個簡單的投票合約，完整的程式碼可以在 basic-presentation Repo 中找到。其中 totalVotes 在每次投票後會被重置為 1，這是一個邏輯錯誤：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Voting {
mapping(address => bool) public hasVoted;
uint256 public votesInFavor;
uint256 public votesAgainst;
uint256 public totalVotes;
function vote(bool isInFavor) external {
require(!hasVoted[msg.sender]);
hasVoted[msg.sender] = true;
totalVotes = 1; // BUG: 每次投票後重置 totalVotes
if (isInFavor) {
votesInFavor += 1;
} else {
votesAgainst += 1;
}
}
}

步驟 1：撰寫規格

以下是一個簡單的規格，檢查 totalVotes 是否在每次投票後遞增：

rule voteIntegrity(env e) {
uint256 votedBefore = totalVotes();
bool isInFavor;
vote(e, isInFavor);
assert (
totalVotes() > votedBefore,
"totalVotes 應該在每次投票後遞增"
);
}

步驟 2：設定 config

使用以下 .conf 檔案來設定驗證細節，包括要驗證的合約與規範檔案。

{
"files": ["src/VotingBug.sol:Voting"],
"verify": "Voting:certora/specs/VotingBug.spec",
"msg": "驗證 totalVotes 遞增",
"server": "production"
}

步驟 3：執行驗證

在專案根目錄執行以下指令：

export CERTORAKEY=xxx
certoraRun certora/confs/VotingBug.conf

如果還沒有 API Key，可以在官方網站註冊取得。輸出中會有一個 Certora Prover 結果的連結，點進去即可看到 Prover 找到了一個錯誤，並提供詳細的輸入參數

步驟 4：修復問題

修改合約邏輯以修復問題：

function vote(bool isInFavor) external {
require(!hasVoted[msg.sender]);
hasVoted[msg.sender] = true;

totalVotes += 1; // FIXED: 正確地累加 totalVotes
if (isInFavor) {
votesInFavor += 1;
} else {
votesAgainst += 1;
}
}

步驟 5：重新驗證

再次執行驗證，確認所有規範均已通過，代表此智能合約的正確性可被數學證明。

進階功能：驗證不變性（Inductive Invariants）

Certora 也支援定義不變量規則（Invariant Rules），確保合約在所有狀態下的邏輯一致性。例如：

invariant totalVotesIsSumInvariant()
votesInFavor() + votesAgainst() == to_mathint(totalVotes());

此規則驗證 totalVotes 永遠等於贊成與反對票數的總和。

Part 7: Maximal Extractable Value (MEV)

在文章的前半部分中，我們已提到 Intent Centric Design，其中介紹了 CoW Swap 如何透過設計應用層的邏輯來簡化跨鏈交易並提升用戶體驗。在這一部分，我將深入探討 CoW Swap 如何解決 Maximal Extractable Value (MEV) 問題，以及其主張 MEV 應在應用層解決的理念。同時，我們也會介紹 Unichain 如何通過可信執行環境（TEE）在基礎設施層解決 MEV 問題，呈現兩種截然不同但互補的解決方式。

CoW Swap 的 MEV 解決方案

CoW Swap 的核心主張是，MEV 問題的根源在應用層。目前約 99% 的 MEV 問題來自交易排序的競爭，而應用層（例如去中心化交易所 DEX）的設計是導致這些問題的主因。因此，MEV 問題應該在設計應用時一併考慮，而非依賴基礎設施層的迂迴解決方案。

Coincidence of Wants（需求的巧合）

CoW Swap 引入需求巧合的概念，通過將多筆交易的需求聚合在一起，使交易者直接匹配需求，避免了流動性池的中間操作，從而減少 MEV 攻擊的可能性。

案例： 假設 Alice 想用 100 USDC 換取 1 ETH，而 Bob 剛好想用 1 ETH 換取 100 USDC。在傳統 DEX 中，這些交易需要分別通過流動性池進行，可能會被套利者利用滑點進行 MEV 攻擊。而在 CoW Swap 中，這兩筆交易可以直接匹配，無需經過流動性池，消除了滑點和 MEV 攻擊。

Batch Auction（批次拍賣）

CoW Swap 的批次拍賣機制是其解決 MEV 問題的核心手段：

收集交易意圖： 在鏈下收集並聚合用戶的交易意圖。
批次處理： 將在特定時間段內收集的交易意圖組合成一個批次，這些批次通常每隔幾秒鐘產生一次。
競價解決方案： 通過競標機制選擇最佳的解決方案提供者（solver），這些提供者競爭以提供最優交易執行方案，為用戶帶來最大的價格盈餘。
統一清算價格： 所有涉及相同資產的交易都以統一的清算價格結算，使交易順序變得無關緊要，從而減少 MEV 攻擊。

批次拍賣的優勢：

MEV 保護： 批次拍賣透過統一清算價格，使交易順序的影響被弱化，顯著削減 MEV 攻擊的空間。
資產匹配： 直接點對點交換，無需觸及鏈上流動性。
最佳價格保證： 確保用戶交易的價格不低於在 AMM 上直接獲得的價格。

實際案例：

假設有三位用戶的交易意圖：

用戶 A 希望以 100 DAI 購買 ETH。
用戶 B 希望以 200 DAI 購買 ETH。
用戶 C 希望出售 1 ETH，目標獲得 300 DAI。

這三筆訂單在批次拍賣中被組合在一起。由於 A 和 B 的購買需求總和（300 DAI）恰好匹配 C 的出售需求（1 ETH），因此可以直接在用戶之間進行點對點交換，無需觸及鏈上流動性。這不僅提高了交易效率，還降低了交易成本，並消除了 MEV 攻擊的風險。

Unichain 的 MEV 解決方案

與 CoW Swap 將 MEV 處理集中在應用層的設計不同，Unichain 選擇在基礎設施層通過可信執行環境（TEE）來解決 MEV 問題。Unichain 是基於 OP Stack 的 Optimistic Rollup，其核心創新在於 加密交易與 TEE 排序，保證交易排序的透明與公平。

Unichain 解決 MEV 的關鍵流程：

加密交易：使用者在發送交易時，首先使用 TEE 的公鑰加密交易內容。因此，在 mempool 中，所有節點看到的交易都是加密的，無法直接得知交易的細節，自然也就無法通過交易排序提取 MEV。
TEE 排序：只有在 TEE 環境內才能解密交易並進行排序。TEE 會根據預設的規則排序交易並構建區塊，最終生成的排序結果帶有 TEE 的簽章，保證排序過程的透明度。
返還 MEV 收益：對於普通用戶，Unichain 提供接近零成本的 Gas 費，同時完全避免了被搶跑（front-run）的風險。而對於 MEV Searcher，他們需要支付更高的 Gas 費來競爭區塊的前位。這些額外的收益會被 Unichain 用於回饋給驗證者，形成公平的經濟激勵。

Part 8: Zero Knowledge Proof (ZKP)

Zero Knowledge Proof (ZKP) 技術的應用展示了如何透過密碼學方法，實現隱私保護與效能的平衡。以下將介紹幾個令我印象深刻的 ZK 應用。

ZKPassport

ZKPassport 結合了國際電子護照（ePassport）的晶片技術與 ZKP，為用戶提供一種既安全又隱私的身份驗證方式。透過手機感應護照的 NFC，用戶可以取得護照晶片中由政府簽署的資料，例如基本資訊和照片。由於這基於全球標準（ICAO Biometric Passport），超過 100 個國家的護照均可支援。基於此簽章即可生成護照資料有效性的零知識證明。

技術特點

隱私保護：用戶可選擇只驗證護照資料的部分條件，例如「年齡是否大於 18 歲」或「國籍是否為美國」，而不需要公開完整的護照資訊。
效能佳：ZK 電路使用 Noir 編寫，在手機上生成證明僅需約 5 秒鐘

應用場景

Sybil Resistance： 可用於防止多重身份詐騙，例如確保一個人只能領取一次空投。
ZK KYC (Know Your Customer)： 在不透露完整身份的情況下，證明用戶來自合法的國家或符合其他特定條件。

ZK Email

ZK Email 是一個基於零知識證明的 Email 驗證應用，允許用戶選擇性地驗證郵件內容。例如，證明 Email 的發信人是否為特定組織、Email 內文是否有特定文字，而無需公開整封郵件的內容。關鍵是採用每個 Email 都會由 Mail Server 簽署的 DKIM Signature，產生一封信是由該域名發出的零知識證明，且無法被偽造。

技術特點

將可信的 Email 資料帶到鏈上驗證，串連 Web2 資料與 Web3
新推出的 ZK Email Registry：提供可共享的 Email template Registry，開發者可快速使用。如有人收到 Devcon 的拒絕信後，寫了一個讓任何人證明自己有收到拒絕信的 template。
更方便的 SDK：開發者僅需撰寫 JSON 設定，而不需了解如何實作 ZK 電路，並隱藏具體的 ZK 電路實作，如 Circom, Noir

應用場景

ZKP2P：透過點對點轉帳的確認信，打造法幣與虛擬貨幣兌換的平台，且完全去中心化
Email Wallet Guardian： Email 可作為智能合約錢包的備援手段。例如，用戶寄出一封 Email 即可恢復錢包的控制權。此功能也能兼容 ERC-7579 的模組化 Smart Account 架構。
Whistleblowing：在保護個人身份隱私的前提下，以特定組織的身份揭發秘密

技術挑戰

DKIM public key 的正確性：在智能合約中需驗證 DKIM Signature 對應的 Public Key 是否真正屬於該域名，而這目前只能透過 Oracle 提供資料。需要透過像 Re-staking 的機制來確保該資料足夠去中心化，避免單點故障
在處理較長的郵件時，ZKP 的計算效能面臨挑戰。團隊正在研究遞迴證明（recursive proof）以支援更高效的 body hash 驗證。
未來可能支援 Email 附件（例如 PDF）內容的證明，進一步拓展應用場景，如證明銀行的轉帳紀錄
手機用戶體驗：由於手機端無法像桌面端下載原始郵件，ZK Email 目前僅能透過 OAuth 授權讀取郵件。雖然這引發一定的隱私顧慮，但 ZK Email 的開源性確保了這些操作僅限於客戶端，不會回傳 Email 資料到服務器。

ZKP2P

ZKP2P 是一個基於零知識證明技術的域名交易市場，旨在提供快速、安全、去中心化的域名交易體驗。該平台支持利用零知識證明驗證域名所有權，並使用 ETH 進行域名交易。目前 ZKP2P 已支援使用者交易 Namecheap 上的域名。

域名交易的核心機制

域名所有權驗證：平台使用一種基於密碼學的 Web 認證協議來驗證域名的所有權。賣家需使用 ZKP2P 提供的瀏覽器 Extension，從 Namecheap 網站生成不可篡改的域名所有權證明，並提交到智能合約中。
交易過程中的隱私保護：買家在提交購買申請時，需提供 Namecheap 用戶名，該資訊會加密處理，僅賣家可見。
資金鎖定：買家的 ETH 會先被鎖定在智能合約的托管中，直到賣家完成域名轉讓並提供相關的零知識證明後，資金才會釋放。
零知識證明的使用：賣家轉移域名後會收到 Namecheap 的確認信，因此 ZKP2P 使用 ZK Email 產生這封信的零知識證明，確保域名已轉移給買方。

技術特點與優勢

隱私與安全性：ZKP2P 通過加密用戶敏感資訊（例如 Namecheap 用戶名）來保護隱私，確保只有域名賣方能看到買方的用戶名。
去中心化與透明性：平台所有的交易驗證過程均在智能合約中執行，減少對第三方的依賴，並提高整體透明度。
降低交易成本：每筆交易僅收取 2.5% 的交易費用，遠低於其他域名交易市場（一般超過 10%），讓買賣雙方都能享受更低的交易成本。

Polygon ZisK

Polygon 正在開發新一代的 ZKVM 證明系統 ZisK，目標是實現即時證明整個 EVM 區塊中所有交易的計算。ZisK 的設計核心在於其通用性（Generic ZKVM）和極致的證明生成速度優化，旨在提升零知識證明在區塊鏈應用中的性能。

ZisK 的設計架構

ZisK 的架構受到嵌入式系統（Embedded System）的啟發，採用了模組化的設計，主要組件包括：

ROM（只讀存儲器）： 儲存 ZKVM 的程序邏輯和靜態數據。
ZisK Processor（處理器）： 負責執行電路的核心計算邏輯。
RAM（隨機存取存儲器）： 用於儲存臨時數據和中間結果，支援高效的數據訪問。
Bus（總線）： 負責連接 ZisK 系統內部的各模組，協調訊息交換。

目前，ZisK 還處於非常早期的開發階段，可參考其開發文件。

Reclaim Protocol

Reclaim Protocol 是一個將 TLS Proxy 技術與零知識證明（Zero-Knowledge Proof, ZKP）相結合的隱私保護協議，旨在讓用戶能夠在不洩露敏感資訊的前提下，驗證 HTTPS 通訊內容的真實性。該協議為資料驗證與互操作性提供了安全的解決方案，尤其適用於 Web2 和 Web3 場景的整合。

TLS Proxy 機制

Reclaim Protocol 的核心依賴於 TLS Proxy 作為信任中介。過程中 HTTPS 請求和回應會經過 TLS Proxy，並由 Proxy 簽署該流量的加密內容，從而為後續的證明生成提供基礎。TLS Proxy 的角色僅限於簽署加密流量，無法解密任何資料，這也減少了隱私風險。

TLS Proxy 的一個重要功能是處理使用者和伺服器之間的 HTTPS 流量，並保證這些流量來自正確的伺服器。例如，在證明某銀行網站的餘額資訊時，TLS Proxy 簽署的加密流量可以確保數據未被篡改，並提供可信的資料來源。

然而儘管 TLS Proxy 提供了關鍵的信任保障，在極端網路條件下（例如 BGP Hijack 攻擊），可能會出現 Proxy 認證的流量被路由到錯誤伺服器的風險。這種攻擊需要在 TLS Handshake 後精準篡改流量，實現難度極高，但這仍是協議中需要特別關注的安全邊界。

zkTLS 技術細節

Reclaim Protocol 結合了 ZKP 技術，允許用戶在不洩露完整 TLS 明文的前提下驗證其真實性，其 ZK 電路的設計旨在處理解密與部分揭露的功能。

協議中的 ZK 電路能夠解密特定的 TLS 流量，並僅揭露其中需要驗證的部分資訊。例如，用戶可以提供 AES 解密金鑰作為 Private Input，在電路中解密 TLS 流量，並公開指定區域的明文資訊。這些操作基於 gnark 框架進行，確保了高效的證明生成。

值得注意的是，Reclaim Protocol 提供了透過 Regular Expression 或是 HTML template 匹配 TLS 流量的功能，而這一匹配邏輯被設計為在電路外實作，以避免電路過度複雜。因此客戶端需首先自行透過 Template 定位哪些 AES Block 中有包含所需的明文，再生成 ZK 證明來證實匹配結果。這樣導致的資安風險是，如果 TLS Payload 中在其他部分也出現了類似的字串，客戶端則有機會偽造證明。

應用場景

Reclaim Protocol 目前將重點放在 Web2 場景的資料互操作性上，解決不同平台間的數據共享問題。例如：

電商優惠：用戶可以從 A 電商生成消費記錄的 ZKTLS 證明，並將其提供給 B 電商以獲取專屬優惠，精準吸引新用戶。在這一過程中，協議可確保 B 電商只能知道消費總金額，而不會接觸完整的消費明細。
身份驗證：用戶可使用協議生成 ZKTLS 證明，證明其在特定平台的活動，如在某論壇的參與情況，或在某開發者平台的貢獻數據。

技術與信任的挑戰

信任 TLS Proxy：協議需要用戶信任 TLS Proxy，因為 Proxy 會簽署 HTTPS 流量，成為證明可信來源的基礎。
ZK 證明的鏈上應用：由於目前 ZK 證明的鏈上驗證成本較高，Reclaim Protocol 將應用重點放在 Web2 場景，尚未在鏈上進行完整的 ZK 驗證。
網路攻擊風險：極端情況下，如 BGP Hijack，可能導致 TLS Proxy 無法正常運作，但這類攻擊需要精確的時間和網路控制，實現難度極高。

vLayer

Vlayer 是一家專注於開發「可驗證資料基礎設施」的加密初創公司，稱之為「Solidity 2.0」。其目標是使開發者能夠將真實世界的資料驗證後整合至以太坊智能合約中。具體而言，Vlayer 為 Solidity 語言引入了四個新功能：

Time Travel：允許智能合約使用歷史鏈上資料。
Teleport：使合約能在多個 EVM 兼容的網絡上運行。
Web Proofs（zkTLS）：驗證並整合網頁內容，包括 API 和網站。
Email Proofs（ZK Email）：存取並驗證電子郵件內容。

這些功能旨在擴展智能合約的應用範圍，特別是在去中心化金融（DeFi）、真實世界資產（RWA）和遊戲等領域。目前，Vlayer 正處於 Alpha 階段，邀請開發者在其平台上進行開發，並計劃於 2025 年推出測試網、主網和代幣。

Mopro

Mopro（Mobile Prover）是一個專為 Mobile 環境開發的 ZK 證明生成工具，以簡化客戶端的證明過程。Mopro 的主要特點包括：

易用性：簡化了在移動應用中整合 ZK 證明的複雜性
高性能：比在瀏覽器上使用 snarkjs 更快，並嘗試使用 GPU 優化性能
跨平台兼容性：支援 iOS、Android 平台

然而，在 Mobile 環境下仍存在一些挑戰：

GPU 加速的限制：雖然 Mopro 嘗試利用 GPU 提升性能，但由於移動設備使用的 Metal API 不如桌面端 CUDA 易於優化，開發上面臨一定難度。然而，數據顯示在處理大型電路時，Mopro 的性能表現有望優於其他傳統工具。
記憶體限制：Mobile 設備的記憶體容量有限是主要挑戰之一，特別是在運行複雜的 ZK 電路（如 ZK Email）時，可能會因內存不足導致應用 Crash

參考資料

Part 9: Multi-Party Computation (MPC)

MPC 是一種密碼學技術，允許多方在不洩露各自輸入的情況下，共同計算一個函數的結果。其與 ZK 的差別在於：

MPC 需要多方參與計算，且所有人都能隱藏輸入的內容。
ZK：僅需一方（Prover）生成證明，另一方（Verifier）驗證其聲明是否正確，無需多方協作。因此 Prover 需要知道所有計算過程的資料。ZK 保障的是 Single Player Privacy。

以下介紹幾個 MPC 的應用與最新研究，展示其在隱私保護與分布式計算中的潛力。

World ID

World ID 是 Worldcoin 的核心技術，旨在為每位用戶建立獨特的數位身份，用以證明個人的「唯一性」。註冊過程中，使用者需透過「虹膜掃描」驗證身份，確保每人僅能註冊一次。這需要將新掃描的虹膜與已註冊的數據庫進行比對。然而，大量集中存儲的真實虹膜數據可能帶來巨大的隱私風險。

為解決此問題，Worldcoin 與 Taceo 合作，探索基於 MPC 的去中心化虹膜比對方案。

技術細節與流程

資料的 Secret Sharing：用戶的虹膜掃描資料被拆分為三個 Secret Share，分發給三個計算方，確保單一計算方無法取得完整的虹膜資料。
Hamming 距離計算：透過內積運算將用戶的虹膜資料與資料庫中的虹膜逐一比對，計算 Hamming 距離並與設定的閾值進行比較。整個過程在 MPC 框架下執行，確保數據隱私不被泄露。
結果聚合：將比對結果以邏輯 OR 聚合，產生最終的驗證結果，判斷虹膜的唯一性。

World ID 最大的技術挑戰在於計算成本高昂：Worldcoin 的使用者數已超過 1,600 萬，每次唯一性驗證需要針對龐大的數據庫進行線性掃描。在 GPU 加速環境下，一次驗證需要 32 台 NVIDIA H100 GPU，峰值網絡吞吐量達 2.5 Tbps。

因此，Worldcoin 正積極探索計算資源需求更低但驗證嚴謹度相對較低的替代方案，例如借鑒 ZKPassport 的護照唯一性證明機制，以在減少成本的同時保持足夠的驗證可信度。

MPCStats

MPCStats 是一個基於 MPC 的開源框架，旨在實現多方參與的統計計算，同時保護數據隱私。該框架允許多個數據提供者匿名參與計算，結果公開但不洩露個人數據細節。

技術特點

隱私保護：數據提供者的資料以秘密共享的方式進行處理，並且在計算過程中保持加密。
整合 TLS Notary：使用 TLS Notary 確保輸入數據來自可信來源，避免「垃圾輸入」影響結果。
支持多種統計操作：包括平均值、中位數、吉尼係數等常見統計指標，以及數據篩選和 Join Table 操作。

展場 Demo

在 Devcon 展會中，MPCStats 提供了一個 Demo，讓參與者私密分享其 Binance ETH 餘額，計算平均值。數據的完整性由 TLS Notary 證明，最終生成可信且隱私保護的統計結果。

Public Auditable MPC

Public Auditable MPC（PAMPC） 是一種結合 MPC 和零知識證明（ZK）的新型協議，旨在解決現有 MPC 系統中無法向第三方驗證計算正確性的挑戰。該協議允許計算方在保護輸入隱私的同時，向第三方公開驗證計算結果的正確性。

核心概念與技術

引入 Collaborative ZK-SNARKs：PAMPC 使用協作式 ZK-SNARKs，將每個計算方生成的部分證明（proof）進行線性聚合產生完整證明，確保計算的正確性可被第三方驗證。
處理輸入一致性問題：在 MPC 的預處理和在線階段中，透過對輸入數據進行 Commit，確保數據的一致性。
加速位元運算：傳統的 SPDZ MPC 協議對於加法和乘法支持良好，但在處理位元運算時效率低下。PAMPC 對 SPDZ 進行了優化。

應用場景與優勢

電子投票：在保護選民隱私的同時，提供公開驗證機制，增強系統透明度同時保護隱私。
去中心化拍賣：確保拍賣結果的公正性，同時保護投標者的隱私。
醫療數據與機器學習：PAMPC 特別適合於需要多方共享敏感數據的場景，例如多機構合作訓練機器學習模型。各機構可以保留數據隱私，同時協作完成模型訓練或預測。
去中心化遊戲：PAMPC 可被應用於去中心化遊戲中，如狼人殺（Werewolf/Mafia）遊戲，通過 MPC 確保角色分配、投票計算的隱私性與正確性，而不需要遊戲主持者 (GM)。

參考資料

Part 10: Programmable Cryptography

0xPARC 提出可程式化密碼學（Programmable Cryptography）概念，指出此技術是從「專用型密碼學」轉向「通用型密碼學」的世代革命。

過去，密碼學工具為特定用途而設計，如 RSA 加密、橢圓曲線簽章等等。當人們需要新的功能，就必須發明新的密碼學協議來滿足需求，如 Group Signature 協議可以讓個人代表一群人簽署資料，而不透露具體身份，這與 RSA 加密演算法的設計有顯著差異。

相對而言，可程式化密碼學將密碼學設計的數學問題轉化為工程問題，允許開發者寫程式來實現任意密碼學操作。以下是一些重要技術：

零知識證明（zkSNARKs）：證明程式在私密輸入上的正確執行，無需洩露輸入。
多方計算（MPC）：在多方私密數據上進行計算，僅揭示最終結果。
完全同態加密（FHE）：允許在加密狀態下執行任意運算，運算結果仍為加密狀態。
不可區分混淆（iO）：將程式加密，讓程式可執行但不可解析內部邏輯，被譽為密碼學的「聖杯」，因其能構建所有其他密碼學工具。

最理想的 Internet

可程式化密碼學能幫助實現 Internet 的理想狀態，包括：

去中心化（P2P）：恢復網路對等性，避免數據和計算集中化。
隱私保護：讓數據擁有者控制其數據使用方式。
資料互操作性：不同應用間數據能無縫流轉並保持真實性與隱私。
信任最小化與無需許可：用數學保證取代對中央機構的信任，任何人均可參與。

例如，MPC 與 FHE 技術讓伺服器在完全不了解用戶數據的前提下，完成計算任務，同時確保計算結果的可驗證性，這代表使用者資料將永遠由自己掌控。

以下透過兩個例子解釋，為何有了可程式化密碼學後，能建構理想的社交網路與投票應用。

去中心化 Facebook

過去當人們思考去中心化社交網路時，總是想先模仿 Twitter，原因是 Twitter 的機制較為單純：每個使用者可以公開發佈內容，任何人都能看到其他人的內容。然而相較於去中心化 Twitter，去中心化 Facebook 的實現更加複雜，因其數據拓撲和隱私要求更高：

隱私設置：用戶可能只想讓特定好友查看特定內容。
朋友的朋友權限：需動態計算貼文可見性範圍。
推薦演算法（News Feed）：需要整合多方數據進行運算。

此外，這些應用需要處理隱私的全域狀態（Private Global State），例如推薦演算法的參數可能無任何單一方知曉，但系統仍需保證其正確運行。這些挑戰只能透過可程式化密碼學解決。

投票系統的技術演進

投票是個很好的案例，因為它需要同時滿足許多特性，才能做到公平、隱私且公正。在加入不同的可程式化密碼學技術後，能一步步朝向理想的投票系統邁進：

將投票上鏈：將提供公開可驗證的投票結果，以及實現抗審查的投票過程。
加入零知識證明（ZK）：讓投票者可隱藏投票內容，保護隱私。
加入 MACI (Minimal Anti-Collusion Infrastructure) 機制：可在計票方不洩漏資訊的前提防止賄選，因為投票者將無法證明自己投票給誰。
加入全同態加密（FHE）：進一步將需信任的參與方擴展為 M-of-N 模型，只要 M 方中有 N 個參與方是誠實的，就沒有人知道誰投票給誰。另一方面可輕易更換投票系統邏輯（如平方投票法）。
加入不可區分混淆（iO）：將計票程式經過混淆處理，確保就算所有人共謀也都無法知道投票運算細節。

ZuPass

ZuPass 是由 0xPARC 推出的一個實驗性應用，基於可程式化密碼學（Programmable Cryptography）的概念設計，旨在幫助使用者實現對自身資料的自主管理與跨平台互操作性。ZuPass 的核心是 Proof-Carrying Data (PCD)，使用者可以在保護隱私的前提下安全儲存並證明其數據的有效性。

以下介紹幾個在本次 Devcon 會場的 ZuPass 應用。使用 ZuPass 的應用又被稱為 ZApp

Devcon 門票驗證

ZuPass 在 Devcon 活動中被用來驗證與會者身份，其原理如下：

使用者的 Devcon 票券以 PCD 的形式存入 ZuPass。
當需要進場時，使用者可透過 ZuPass 生成零知識證明（Zero-Knowledge Proofs, ZK Proof），證明自己持有有效票券而無需透露身份細節。
此外，還能用於基於身份的 Telegram 群組驗證，確保只有符合條件的成員可以加入特定群組。

Frog Crypto

Frog Crypto 是一個基於 ZuPass 的有趣應用，讓參與者在展場中搜集各種類型的青蛙，並生成證明來展示自己擁有的青蛙。其特色在於

資料自主權：參加者完全掌握自己的青蛙數據。
互操作性：開發者可以基於使用者擁有的青蛙資料創建新應用，例如允許使用者將兩隻青蛙合成為新的青蛙。這與傳統 Web2 生態的封閉 API 截然不同，使用者和開發者不再受限於中心化平台的規則與改動。

Meerkat

Meerkat 是促進講者與聽眾互動的 ZApp，結合了 Slido 問答功能與 ZK 技術，實現匿名互動。其功能包括：

即時發起問答或投票，講者和聽眾能在保護隱私的同時提升互動性。
使用者可透過 ZuPass 登入並生成互動所需的證明，而無需暴露個人資訊。

ZuPass 的整合方式

ZuPass 提供方便整合的 SDK，達成類似 Google OAuth 的方便整合 SDK：

用戶授權：應用整合 ZuPass 後，會跳出 ZuPass 彈窗供使用者登入並選擇授權哪些資料的讀寫權限。
資料請求與驗證：授權後，應用可向 ZuPass 請求特定資料的證明，或對應用程式中記錄的數據進行讀寫操作。

POD 與 GPC 技術

ZuPass 建立在兩個關鍵技術之上：Provable Object Data (POD) 與 General Purpose Circuit (GPC)。這兩項技術支撐了像是 Meerkat、Frog Crypto 和 Devcon 門票驗證等應用，實現了數據的隱私驗證與互操作性。

POD 是一種以密碼學為核心的數據格式，專為零知識證明設計。GPC 則是一種模組化電路，能根據 POD 的結構生成靈活且高效的 ZK 證明。

POD 的設計與技術基礎

Merkle Tree 結構：每個 POD 都是一個扁平的 key-value 鍵值對結構，透過 Merkle Tree 壓縮成一個唯一的 Content ID，用於標識數據的完整性與來源。
簽名與驗證：POD 的 Content ID 由發行者使用 ECDSA 簽名。
零知識證明友好性：採用 ZK-friendly 的 Poseidon Hash 函數與模組化數據格式，以加速生產 POD 的零知識證明

GPC 的模組化電路設計

GPC 是針對 POD 設計的通用電路，只需單一電路即可產生基於 POD 靈活的零知識證明。其設計基於模組化架構，包含：

Object Module：驗證 POD 的 Content ID 與簽名的一致性。
Entry Module：檢查 POD 內容的 Merkle Proof。
Numeric Value Module：進行數值比較與範圍檢查。
Membership Module：驗證欄位是否在指定列表中。

POD 的不足與挑戰

儘管 POD 系統具有靈活性與隱私保護能力，但其仍存在以下限制：

單用戶技術（Single Player Technology）：POD 的設計限制了其只能由用戶本人生成與證明，無法支持隱私保護的多用戶協作運算。
無法遞迴證明：POD 生成的證明僅能被驗證，而不能用於生成基於該證明的進一步證明，限制了其應用深度。
與現有系統不兼容：資料生產方需要調整系統來生成具簽名的 POD，無法直接應用於現有的 Web2 資料。

POD 2 的誕生與改進

為了解決 POD 1 的缺陷，POD 2 系統應運而生，其引入了「Proof-Carrying Data (PCD)」的概念，使所有數據都帶有可驗證的證明，並支援多方運算：

支援多用戶隱私協作：POD 2 引入了多方計算（Multi-Party Computation, MPC），允許多方基於隱私 POD 數據進行聯合運算並生成新 POD。例如，兩位用戶可共同計算某條件是否成立，而無需洩露各自的數據細節。
遞迴證明與計算：POD 2 的證明支持遞迴計算，允許生成基於現有證明的新證明，構建深度計算圖。

並且 POD 2 框架支援開發者將任意的 Web2 資料轉換為 POD 格式，以解決 POD 與既有系統不兼容的問題，稱為「Universal Data Adapter」。例如開發者可將來自 ZK Email、TLSNotary 等 Web2 系統的資料轉換為 POD 格式的 Proof Carrying Data，讓所有系統的資料產生互通性，實現不同系統間的無縫整合。最大的好處在於完全不需修改既有 Web2 系統的資料產生邏輯。

POD 2 的技術挑戰在於，需依賴於多方全同態加密（Multi-Party Fully Homomorphic Encryption, MP-FHE）實現多個 POD 2 之間的共同隱私運算。

PEX 語言

0xPARC 也發明了類似 Lisp 的 PEX 語言，用於描述 POD 2 的數據結構與條件：

[createpod id-card
age 26
zip-code 12001
id 1847202750
]
[> age 18]

提供簡潔且直觀的語法，使開發者能快速建立基於 POD 的應用。

Frog Zone 遊戲

Frog Zone 是 0xPARC 在 Devcon 展示的技術遊戲，旨在實踐最尖端密碼學應用，展示全同態加密（Fully Homomorphic Encryption, FHE）和多方計算（Multi-Party Computation, MPC）技術如何結合，創造出具隱私保護和分布式特性的應用環境。這款遊戲作為首個多用戶 MP-FHE 應用，為分布式隱私計算和應用開發提供了重要的技術示範。

遊戲玩法

玩家數量：最多支持 4 位玩家同時參與。
可見範圍：每名玩家只能觀察自己周圍 5x5 方格內的地圖，一開始玩家互相看不見。
地圖大小：32x32 格子，其中包含怪物、地形障礙以及裝備等互動元素。
玩家可選擇移動、攻擊怪物或撿取裝備，提升自己的攻擊力與防禦力。
遊戲中的怪物會隨機移動，增加挑戰性和遊戲趣味性。
玩家需在探索地圖的同時攻擊怪物，以爭取獲得最高分數。

技術核心：Multi-Party Fully Homomorphic Encryption

FHE 是一種允許在加密數據上直接進行計算的密碼學技術。運算結果仍保持加密狀態，只有持有解密密鑰的一方可以獲取結果。核心特性是「可計算性與隱私性共存」。
將 FHE 與 MPC 結合可以將 FHE 的能力擴展到多方環境，使多名參與者可以在共享的加密狀態上進行協作計算。在 Frog Zone 遊戲中，每名參與者持有部分加密狀態的分片，並通過 MPC 協議協同完成伺服器功能的模擬。
整個遊戲的狀態是由四台使用者的機器，加上五台在 AWS 雲端的機器共同維護與計算，沒有任何一台機器能解密出完整的遊戲狀態。由於是九台機器一起運算遊戲狀態，就像產生了共同的「幻覺」，也因此這個運算過程被稱為 Hallucinated Server
每次玩家發出移動或攻擊指令時，該指令以加密形式發送至伺服器。伺服器在加密環境中執行狀態轉換函數，生成新的加密遊戲狀態。
完成操作後玩家請求可見範圍（5x5）的加密數據，並通過多方協作解密獲取結果。

技術挑戰與限制

運算成本高昂：每個二進制邏輯門的運算耗時約 10 毫秒，比傳統計算慢 10 億倍，而且每 1 bit 明文需要約 3,000 bit 的加密資料表示。Frog Zone 動用 5 台 AWS 最高規格的 192 Core CPU 的機器，每小時花費 200 美金，但每個玩家只能每四秒操作一次。
開發模式的轉變：MP-FHE 僅支持電路模型，而非傳統記憶體模型，開發過程中需要平行模擬所有可能的操作分支。例如，當玩家嘗試移動時，伺服器需同時計算所有可能的移動結果並選擇正確的分支。若要使用記憶體模型，需使用 Oblivious RAM 以確保隱私地存取記憶體內容
多方解密的頻寬成本：每次玩家請求 5x5 可見範圍內容時，需由四台本地客戶端協同解密，導致解密過程高度依賴多方同步，對網路頻寬要求極高。

未來展望

Frog Zone 展示了利用全同態加密和多方計算技術實現隱私保護和去中心化應用的可能性。雖然當前技術仍面臨性能和開發難度的挑戰，但這就如同 1960 年代的電腦，雖然龐大且效率低下，卻是開創現代計算時代的起點。Frog Zone 的意義在於，它象徵了 Programmable Cryptography 的雛形，為未來理想化的網際網路鋪平了道路。

隨著 Programmable Cryptography 技術的發展，未來的網際網路將實現去中心化、自主性和隱私保護的目標，建立一個真正屬於用戶的數位世界。這個世界將帶來更安全、透明且自由的數位生活，每個人都將能完全掌控自己的資產、資料與身份。

參考資料

【免責聲明】市場有風險，投資需謹慎。本文不構成投資建議，使用者應考慮本文的任何意見、觀點或結論是否符合其特定狀況。據此投資，責任自負。

本文經授權轉載自：Harry Chen 陳柏叡, KryptoGO

以太坊Devcon大會精選！十大關鍵技術全解析，將徹底改變Web3？