經(jīng)過十天在Devcon 7 與Side events 的密集學(xué)習(xí)，我想透過這篇文章濃縮我的所學(xué)，并總結(jié)幾個(gè)關(guān)鍵主題，讓更多人了解以太坊生態(tài)在各個(gè)技術(shù)面向上的最前沿發(fā)展、正在解決的問題，以及未來可達(dá)到的理想狀態(tài)。本文章將涵蓋以下主題：

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

除了Devcon 主場(chǎng)館的演講與體驗(yàn)活動(dòng)，我個(gè)人更喜歡參加特定主題的side events。這些活動(dòng)不僅能深入學(xué)習(xí)相關(guān)領(lǐng)域的知識(shí)，還能遇到志同道合的專家進(jìn)行交流。例如在一場(chǎng)關(guān)于zkTLS 的活動(dòng)中，我有機(jī)會(huì)直接向項(xiàng)目方請(qǐng)教文件中不太理解的部分，這段經(jīng)歷讓我印象深刻。未來若有類似的大型研討會(huì)，我也強(qiáng)烈建議大家多參加與自己興趣相符的side events。

以下正文開始。

Part 1: Infrastructure

以下將從成就、現(xiàn)況與未來三個(gè)面向，詳細(xì)闡述以太坊如何透過技術(shù)創(chuàng)新解決當(dāng)前挑戰(zhàn)，并為未來的擴(kuò)容與去中心化鋪路。

成就：手續(xù)費(fèi)降低與一流的穩(wěn)定性

坎昆升級(jí)大幅降低L2 手續(xù)費(fèi)

今年的坎昆升級(jí)帶來了前所未有的成本優(yōu)化。得益于EIP-4844引入的DAS 技術(shù)（Data Availability Sampling）與Blob機(jī)制，L2 現(xiàn)在可以以更低的成本將更多資料儲(chǔ)存到以太坊主網(wǎng)，使每筆交易的費(fèi)用降至不到$0.01 美金，讓L2 的使用更加經(jīng)濟(jì)實(shí)惠

Client Diversity 的成功實(shí)踐

以太坊的Client Diversity是其穩(wěn)定性的重要基石。運(yùn)行以太坊節(jié)點(diǎn)的程式（Client）有多套選擇，例如Geth、Nethermind 和Reth，每套程式的開發(fā)團(tuán)隊(duì)分布于不同地區(qū)，程式碼基礎(chǔ)也完全獨(dú)立。知名的執(zhí)行層Client 就有Geth, Nethermind, Reth 等等。

關(guān)鍵價(jià)值：即使某個(gè)Client 出現(xiàn)Bug，也不會(huì)影響整體網(wǎng)路，因?yàn)槊總€(gè)Client 的使用比例均低于50%，而以太坊的共識(shí)機(jī)制是至少需要2/3 的節(jié)點(diǎn)同意才能讓區(qū)塊Finalize，因此能夠避免單一Bug 導(dǎo)致整條鏈分岔
歷史案例：早期以太坊只有Geth 與Parity 兩個(gè)Client，在某次Client 發(fā)生重大問題時(shí)，Client Diversity 幫助以太坊維持了整條鏈的穩(wěn)定運(yùn)行。
理想狀況：最理想的分布是所有Client 各自占比低于1/3，這樣即便某個(gè)Client 出現(xiàn)問題，也不會(huì)影響區(qū)塊的最終確認(rèn)（Finalization）。

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

交易確認(rèn)效率顯著提升

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

現(xiàn)況：Rollup 的挑戰(zhàn)與安全性

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

L2 的信任假設(shè)與分級(jí)安全模型

目前許多L2 項(xiàng)目仍基于強(qiáng)信任假設(shè)，某些L2 項(xiàng)目方甚至擁有凍結(jié)用戶資金或停止整條鏈運(yùn)作的權(quán)力。為了更清楚地衡量L2 的安全性，業(yè)界將其分為三個(gè)階段：

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

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

目前的L2 發(fā)展現(xiàn)狀與挑戰(zhàn)

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

Escape Hatch：L2 安全性的核心機(jī)制

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

例如dydx發(fā)行的L2 在這方面表現(xiàn)出色。當(dāng)他們的L2 決定停止?fàn)I運(yùn)時(shí)，提供了工具讓用戶自行將資金轉(zhuǎn)回L1，確保了用戶資金的安全。

L1 的擴(kuò)容需求與去中心化的堅(jiān)守

為了應(yīng)對(duì)未來可能的大量L2 逃生交易，L1 必須持續(xù)擴(kuò)容。然而，Vitalik 多次強(qiáng)調(diào)，在擴(kuò)容過程中，不能為了短期內(nèi)的大幅擴(kuò)容而妥協(xié)去中心化。一旦去中心化特性被犧牲，將難以挽回。這種堅(jiān)守是以太坊作為可信中立基礎(chǔ)設(shè)施的核心價(jià)值。

未來：以太坊的進(jìn)化方向與長期愿景

以太坊在未來將迎來多方面的技術(shù)革新，從L2 的進(jìn)一步去中心化，到L1 的性能優(yōu)化，乃至于共識(shí)層的全面重寫，這些計(jì)劃都旨在推動(dòng)以太坊邁向更加高效、安全且去中心化的區(qū)塊鏈生態(tài)。

L2 邁向Stage 2：實(shí)現(xiàn)真正的去中心化

L2 的發(fā)展方向之一是推動(dòng)更多項(xiàng)目邁向Stage 2，這是去中心化與安全性的理想平衡點(diǎn)。 Vitalik 明確表示，未來他只會(huì)將達(dá)到Stage 1的Rollup 稱為Rollup，而未能進(jìn)一步邁向Stage 2 的項(xiàng)目，將難以滿足以太坊的長期愿景。在Stage 2，L2 將依賴雙重證明系統(tǒng)，并將控制權(quán)完全交由智能合約處理，進(jìn)一步降低對(duì)人為干預(yù)的依賴。

降低驗(yàn)證門檻：讓更多人參與以太坊網(wǎng)路

未來的目標(biāo)是讓更多人能輕松參與以太坊節(jié)點(diǎn)的驗(yàn)證。這包括：

開發(fā)類似Helios的Light Client，讓運(yùn)算資源有限的設(shè)備也能運(yùn)行以太坊驗(yàn)證程式，實(shí)現(xiàn)節(jié)點(diǎn)運(yùn)行的輕量化。
將Stake ETH作為驗(yàn)證者的門檻從32 ETH 降低到1 ETH，讓更多用戶能參與驗(yàn)證，進(jìn)一步分散網(wǎng)路風(fēng)險(xiǎn)。
減少對(duì)Lido等Liquid Staking Provider 的依賴，避免因過度集中化帶來的風(fēng)險(xiǎn)。

這些措施旨在提升以太坊網(wǎng)路的去中心化程度，確保其穩(wěn)定性與長期可持續(xù)發(fā)展。

執(zhí)行層的持續(xù)擴(kuò)容：TPS 邁向十萬級(jí)別

目前L1 每個(gè)區(qū)塊的Blob數(shù)量與大小存在限制，導(dǎo)致L2 在現(xiàn)階段的理論TPS（每秒交易次數(shù)）僅達(dá)幾千筆。然而，未來希望通過擴(kuò)展Blob 機(jī)制，如引入PeerDAS技術(shù)，實(shí)現(xiàn)每秒十萬筆交易的目標(biāo)。這將大幅提升以太坊的可擴(kuò)展性，為高頻交易應(yīng)用場(chǎng)景鋪平道路。

共識(shí)層的革命性變革：Beam Chain

以太坊的共識(shí)層將迎來一項(xiàng)重大改變，即Beam Chain的引入。這是Justin 提出的對(duì)現(xiàn)有Beacon Chain 的全面重寫，旨在解決當(dāng)前最棘手的問題，并邁向以太坊的終極目標(biāo)（End Game）。主要的改進(jìn)方向包括：

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

圖中綠色的項(xiàng)目可以透過對(duì)共識(shí)層漸進(jìn)式的改動(dòng)完成，然而紅色項(xiàng)目最為棘手，需要重寫核心程式碼，Beam Chain 因而被提出作為解決方案。

極度嚴(yán)謹(jǐn)?shù)墓こ叹衽c長期路線圖

Beam Chain 的引入需要對(duì)核心程式碼進(jìn)行全面重寫，不僅能解決現(xiàn)有技術(shù)債，還能從過去的經(jīng)驗(yàn)中汲取教訓(xùn)。根據(jù)初版Beam Chain Roadmap，整個(gè)升級(jí)計(jì)劃將分為三個(gè)階段：

一年內(nèi)完成規(guī)格定義。
1~2 年完成實(shí)作。
1~2 年進(jìn)行完善與全面測(cè)試。

這體現(xiàn)了以太坊對(duì)去中心化的堅(jiān)守以及對(duì)安全性的極高要求，畢竟整個(gè)網(wǎng)路承載了數(shù)千億美元的資金，任何小差錯(cuò)都可能導(dǎo)致災(zāi)難性后果。然而，也有許多社區(qū)成員批評(píng)五年的時(shí)間表過于冗長，期待能加速進(jìn)度。 Justin 表示，這其中的確存在優(yōu)化空間，他也希望更多人參與討論與實(shí)作，共同推動(dòng)這一計(jì)劃的實(shí)現(xiàn)。

需要注意的是，Beam Chain 并非以太坊未來五年的唯一重點(diǎn)。在共識(shí)層進(jìn)行升級(jí)的同時(shí)，執(zhí)行層的改進(jìn)（例如透過PeerDAS提高TPS）將持續(xù)推進(jìn)，為應(yīng)用開發(fā)者與用戶提供更高效能與更流暢的體驗(yàn)。

Part 2: Usability

隨著ERC-4337 帳戶抽象標(biāo)準(zhǔn)的定案與上線，各式各樣的Smart Wallet（智能錢包）應(yīng)運(yùn)而生，大幅提升了使用者的體驗(yàn)與易用性。然而，這些創(chuàng)新同時(shí)也對(duì)錢包和DApp 帶來了新的技術(shù)挑戰(zhàn)。另一方面，隨著L2 的蓬勃發(fā)展，資產(chǎn)碎片化問題日益顯著，許多協(xié)議與應(yīng)用開始朝向Intent Centric Design和Chain Abstraction的方向發(fā)展，力求解決這些問題，讓使用者能更快速完成復(fù)雜的跨鏈交易，并將相關(guān)細(xì)節(jié)隱藏于背后。以下將逐一探討這些技術(shù)。

Smart Wallet (ERC-4337)

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

Passkey 簽章的技術(shù)挑戰(zhàn)

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

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

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

Passkey 錢包的共同挑戰(zhàn)

即使在成本降低的前提下，Passkey 錢包仍面臨以下幾個(gè)技術(shù)挑戰(zhàn)：

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

這些挑戰(zhàn)讓部分人質(zhì)疑Passkey 作為錢包私鑰的適用性，認(rèn)為其設(shè)計(jì)初衷是用于Web2 登入場(chǎng)景，對(duì)于Passkey 丟失風(fēng)險(xiǎn)的影響較小，隨時(shí)都能透過「忘記密碼」功能找回帳號(hào)，而且不需展示具體簽名內(nèi)容。但這不代表Passkey 無法成為錢包的一部分，未來的錢包設(shè)計(jì)或許可以借鑒Web2，提供多種驗(yàn)證與帳號(hào)恢復(fù)選項(xiàng)，并依需求設(shè)置不同權(quán)限。

其他錢包驗(yàn)證與恢復(fù)機(jī)制：ZK Email 的創(chuàng)新

除了Passkey，ZK Email團(tuán)隊(duì)提出了一種基于Email 還原錢包控制權(quán)的機(jī)制。使用者可以將指定Email 地址設(shè)為合約錢包的「監(jiān)護(hù)人」（Guardian）。當(dāng)私鑰丟失時(shí)，用戶只需從該Email 發(fā)送一封信，包含合約錢包地址及新控制地址等資訊，即可生成ZK 證明，在鏈上驗(yàn)證后取回錢包控制權(quán)。這一設(shè)計(jì)基于多年發(fā)展的Email 基礎(chǔ)設(shè)施，安全性高且操作便捷，有效減少了私鑰丟失帶來的風(fēng)險(xiǎn)。

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

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

B 錢包無法辨識(shí)A 錢包所使用的簽章方法。
B 錢包無法支援發(fā)送A 錢包的交易。

為了解決這一問題，業(yè)界提出了模組化合約錢包標(biāo)準(zhǔn)，例如ERC-7579和ERC-6900。這些標(biāo)準(zhǔn)將ERC-4337 的功能進(jìn)一步模組化，例如：

授權(quán)模組：可以用Passkey 或多簽驗(yàn)證替換。
交易執(zhí)行模組：可根據(jù)應(yīng)用需求更改，例如如何批次執(zhí)行交易。
權(quán)限模組：支持靈活的權(quán)限配置。

這樣的設(shè)計(jì)允許所有錢包應(yīng)用共用同一個(gè)Account Factory Contract，并能夠靈活組合不同模組，極大提升互操作性，減少資產(chǎn)管理的摩擦成本。

Smart Wallet (EIP-7702)

EIP-7702（Set EOA Code）是下一代帳戶抽象標(biāo)準(zhǔn)，預(yù)計(jì)將在下一次以太坊Pectra 硬分岔中被納入。這項(xiàng)提案的初衷在于解決ERC-4337的一個(gè)關(guān)鍵限制：使用者需要?jiǎng)?chuàng)建新的智能合約錢包，無法延續(xù)過去的EOA（Externally Owned Account）。 EIP-7702 則提供了一個(gè)全新解法，允許任何EOA 地址「升級(jí)」為智能合約錢包，帶來多樣化的靈活功能：

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

EIP-7702 的應(yīng)用案例

Ithaca 團(tuán)隊(duì)在EXP-0001中展示了EIP-7702 的Demo，讓使用者可以一鍵創(chuàng)建Passkey 并將EOA 地址的權(quán)限代理給該P(yáng)asskey。此后，所有交易只需Passkey 簽名即可完成，且已在測(cè)試網(wǎng)中部署了RIP-7212（Passkey 簽章優(yōu)化）的實(shí)作，顯著降低了Gas 成本。借助這一技術(shù)，EOA 可透過單一Passkey 簽章執(zhí)行多筆交易，進(jìn)一步提升使用者的便利性。

EIP-7702 的技術(shù)流程

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

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

安全挑戰(zhàn)與潛在風(fēng)險(xiǎn)

雖然EIP-7702 的功能十分強(qiáng)大，但也帶來了一些新的安全風(fēng)險(xiǎn)：

授權(quán)惡意合約的風(fēng)險(xiǎn)：如果使用者不小心簽署了一個(gè)惡意EIP-7702 簽章，攻擊者可借助合約邏輯批次轉(zhuǎn)移使用者的所有資產(chǎn)，包括Token、NFT 和DeFi 倉位。相比現(xiàn)有的Permit Signature，EIP-7702 的潛在風(fēng)險(xiǎn)更高。
跨鏈?zhǔn)跈?quán)的風(fēng)險(xiǎn)：簽署授權(quán)訊息時(shí)，若使用chain ID = 0，表示簽章對(duì)所有EVM 鏈生效。一個(gè)簽章可能導(dǎo)致所有鏈上的資產(chǎn)同時(shí)暴露于風(fēng)險(xiǎn)，效果等同于私鑰泄漏。

跨鏈?zhǔn)跈?quán)的安全考量

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

至于可能會(huì)授權(quán)惡意合約的問題，錢包App 可采取以下措施：

引入「白名單」系統(tǒng)，對(duì)合約地址進(jìn)行驗(yàn)證。
透過界面提示用戶授權(quán)的合約邏輯是否安全。

EIP-7702 與ERC-4337 的互補(bǔ)性

EIP-7702 的核心優(yōu)勢(shì)在于支持將現(xiàn)有的EOA 升級(jí)為智能合約錢包。然而，這也帶來一個(gè)限制：EOA 的私鑰始終擁有最高權(quán)限。如果私鑰泄漏，將直接導(dǎo)致錢包的控制權(quán)喪失。而ERC-4337可以實(shí)現(xiàn)多簽錢包等無需依賴單一私鑰的設(shè)計(jì)，提供更高的安全性。因此，EIP-7702 與ERC-4337 之間并非相互替代，而是互補(bǔ)的關(guān)系。 EIP-7702 彌補(bǔ)了ERC-4337 在EOA 過渡上的不足，而ERC-4337 則提供更高的安全保障，適用于對(duì)安全性有更高需求的場(chǎng)景。

Smart Session

雖然智能錢包（Smart Wallet）帶來了許多創(chuàng)新，但它們的出現(xiàn)并不代表DApp 的使用體驗(yàn)會(huì)自動(dòng)變好。錢包與DApp 之間的溝通方式需要進(jìn)一步的協(xié)調(diào)和標(biāo)準(zhǔn)化，才能真正實(shí)現(xiàn)流暢的使用體驗(yàn)。

DApp 與Smart Wallet 的兼容挑戰(zhàn)

在傳統(tǒng)的EOA 設(shè)計(jì)中，DApp 發(fā)送交易通常是通過簡單的eth_sendTransaction 介面向錢包發(fā)送請(qǐng)求。然而，Smart Wallet（如基于ERC-4337 的智能合約錢包）需要一種全新的操作模式。 ERC-4337 引入了User Operation的結(jié)構(gòu)作為核心元件，但問題在于許多現(xiàn)有DApp 并不知道如何生成User Operation 的資訊。這導(dǎo)致Smart Wallet 與當(dāng)前DApp 生態(tài)的兼容性大打折扣。

為了解決這一問題，社群內(nèi)正在討論如何統(tǒng)一相關(guān)介面，其中一些重要的提案包括：

EIP-5792：幫助DApp 確認(rèn)錢包支持哪些Smart Account 的功能。
ERC-7677：指導(dǎo)DApp 如何生成User Operation 中的paymasterAndData 欄位。
ERC-7679：提供生成完整User Operation 的規(guī)范。

這些提案的目的是讓DApp 能更輕松地與Smart Wallet 互動(dòng)，提升其易用性并加速智能錢包的普及。

Smart Session 的概念與理想體驗(yàn)

除了介面統(tǒng)一外，另一個(gè)重要的改進(jìn)方向是提升錢包與DApp 的交互體驗(yàn)，減少使用者需要反覆操作錢包的次數(shù)。Reown（前WalletConnect）的創(chuàng)始人提出了Smart Session的概念，旨在簡化操作流程并提供OAuth 式的授權(quán)體驗(yàn)。理想中的使用場(chǎng)景如下：

初始授權(quán)：使用者登入DApp 時(shí)，DApp 向錢包請(qǐng)求授權(quán)，并說明需要執(zhí)行的交易范圍（例如Uniswap 請(qǐng)求Approve 與Swap 的權(quán)限）。
生成Session Key：使用者在錢包中點(diǎn)擊同意后，DApp 獲得一個(gè)Session Key，該Key 對(duì)應(yīng)于使用者同意的授權(quán)范圍。
簡化交易簽署：當(dāng)使用者操作DApp 并需要發(fā)送交易時(shí)，DApp 使用Session Key 簽署交易并提交到鏈上，過程中無需用戶再次確認(rèn)。

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

安全風(fēng)險(xiǎn)與解決方案

Smart Session 雖然優(yōu)化了使用體驗(yàn)，但也帶來了一些安全風(fēng)險(xiǎn)，尤其是Session Key 泄漏的可能性?？紤]到瀏覽器端是前端攻擊（如XSS）的高發(fā)地點(diǎn)，如何安全地儲(chǔ)存與管理Session Key 是必須解決的問題。

Passkey 是實(shí)現(xiàn)Session Key 安全存儲(chǔ)與簽名的良好選擇，因?yàn)樗艽蠓档托孤╋L(fēng)險(xiǎn)。同時(shí)，Session Key 的設(shè)計(jì)應(yīng)保證丟失后對(duì)用戶的影響最小，用戶只需重新授權(quán)即可恢復(fù)使用。

Intent Centric Design

隨著上百條L2 的誕生，使用者的資產(chǎn)逐漸分散到不同鏈上。這種分散性帶來了跨鏈操作的復(fù)雜性，不僅速度慢，體驗(yàn)也相當(dāng)不友好。在應(yīng)用層面，越來越多的協(xié)議開始采用Intent Centric Design（意圖導(dǎo)向設(shè)計(jì)）來解決這些問題。這種設(shè)計(jì)理念的核心在于，用戶只需表達(dá)自己的目標(biāo)意圖（Intent），而不需要關(guān)心具體實(shí)現(xiàn)方式，將操作的復(fù)雜性·交由Solver（解決者）處理。從過去的「自行開車到目的地」到如今「叫Uber 即可」，這正是Intent Centric Design 帶來的使用體驗(yàn)轉(zhuǎn)變。

ERC-7683：跨鏈意圖的標(biāo)準(zhǔn)化實(shí)現(xiàn)

ERC-7683是由Uniswap 和跨鏈橋Across 提出的跨鏈意圖標(biāo)準(zhǔn)，它讓用戶只需簽署跨鏈操作的意圖，由Solver 負(fù)責(zé)完成具體請(qǐng)求，支援以下常見場(chǎng)景：

資產(chǎn)跨鏈移動(dòng)：將A 鏈上的X Token 移動(dòng)到B 鏈。
跨鏈資產(chǎn)兌換：在A 鏈上的X Token 換成B 鏈上的Y Token。
跨鏈后的復(fù)合操作：在完成跨鏈兌換后執(zhí)行目標(biāo)鏈上的合約操作，例如購買NFT。

使用者只需一鍵操作，即可完成如「將ETH 從以太坊跨鏈至Arbitrum 并購買NFT」的復(fù)雜任務(wù)，且整個(gè)過程可在三秒內(nèi)完成。

ERC-7683 的操作流程如下：

記錄意圖：使用者在A 鏈將資產(chǎn)存入ERC-7683 合約，并記錄其操作意圖（Intent）。
Solver 鎖定意圖： Solver 監(jiān)聽Intent，判斷是否符合其能力與利潤需求，然后在A 鏈鎖定該Intent。
執(zhí)行跨鏈意圖： Solver 在B 鏈墊付資金完成用戶的目標(biāo)操作，例如轉(zhuǎn)移Token 或兌換資產(chǎn)。這種「先墊款后操作」的模式大幅提升操作速度。
結(jié)算與支付：協(xié)議在A 鏈上基于B 鏈的最終狀態(tài)（finalized state）每小時(shí)進(jìn)行結(jié)算，計(jì)算Solver 的服務(wù)費(fèi)并支付。

使用者支付的手續(xù)費(fèi)基本等同于一小時(shí)的借貸利息。這種模式比傳統(tǒng)基于訊息的跨鏈協(xié)議效率更高，因?yàn)槠洳捎昧伺谓Y(jié)算方式，減少了跨鏈訊息傳輸?shù)某杀?，無需每筆交易都傳送一個(gè)跨鏈的訊息。

靈活性與挑戰(zhàn)

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

流動(dòng)性碎片化： Solver 可能因不熟悉或信任特定的結(jié)算邏輯，而選擇不參與某些合約的Intent，導(dǎo)致不同Settlement 合約間的流動(dòng)性缺乏競(jìng)爭(zhēng)性。
安全性風(fēng)險(xiǎn)：若結(jié)算合約出現(xiàn)問題，Solver 可能無法收回墊付資金，增加了參與風(fēng)險(xiǎn)。

為解決這些問題，可在Settlement 合約采用模組化設(shè)計(jì)，讓結(jié)算邏輯簡單易懂且易于審計(jì)，從而吸引更多Solver 提供流動(dòng)性。

ERC-7683 與EIP-7702 的結(jié)合應(yīng)用

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

CoW Swap 的Intent 解決方案

CoW Swap 在單鏈場(chǎng)景中推動(dòng)了Intent 的應(yīng)用，專注于優(yōu)化Swap 體驗(yàn)。其核心特點(diǎn)包括：

聚合多個(gè)Intent： Solver 可同時(shí)計(jì)算多個(gè)Intent 的最佳交易路徑，例如同時(shí)滿足A 使用者想用X Token 換Y Token，與B 使用者想用Y Token 換X Token 的需求。
減少手續(xù)費(fèi)：此方法避免了使用者分別與流動(dòng)池進(jìn)行交易的成本，帶來理論上的最佳價(jià)格。

然而，CoW Swap 的解決方案對(duì)Solver 提出了極高的技術(shù)要求：

流動(dòng)性獲取：必須快速從多個(gè)DEX、中心化交易所（CEX）及跨鏈資源中獲取流動(dòng)性。
演算法優(yōu)化：如何快速聚合并計(jì)算最優(yōu)交易路徑仍是未解的最佳化問題。
精準(zhǔn)執(zhí)行：在鏈上執(zhí)行交易時(shí)需避免MEV（最大可提取價(jià)值）攻擊，同時(shí)在CEX 執(zhí)行交易也需確保價(jià)格的精準(zhǔn)度。

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

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

技術(shù)實(shí)現(xiàn)原理

這一設(shè)計(jì)的核心依賴于Circle 的CCTP 跨鏈橋和以太坊的CREATE2機(jī)制，通過結(jié)合這兩者實(shí)現(xiàn)用戶Intent 的自動(dòng)化執(zhí)行。

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

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

Chain Abstraction

Chain Abstraction的核心理念是隱藏區(qū)塊鏈的存在，讓使用者專注于資產(chǎn)本身，而非背后的鏈。這意味著使用者只需知道自己擁有多少USDC、ETH 等資產(chǎn)，而不用關(guān)心它們分散在哪些鏈上。當(dāng)使用者發(fā)起USDC 的轉(zhuǎn)帳時(shí)，系統(tǒng)會(huì)自動(dòng)檢測(cè)并整合所有鏈上的USDC，完成轉(zhuǎn)帳所需的跨鏈操作。同時(shí)，使用者不需要為Gas 費(fèi)煩惱，可以直接用轉(zhuǎn)帳的USDC 支付Gas。

Biconomy Modular Execution Environment

Biconomy 提供了Modular Execution Environment (MEE)解決方案，專為支持Chain Abstraction 而設(shè)計(jì)。這個(gè)系統(tǒng)允許ERC-4337 錢包的開發(fā)者輕松定義跨多鏈的操作，并將其整合為一個(gè)Supertransaction。使用者僅需簽署一次對(duì)Supertransaction 的授權(quán)，即可實(shí)現(xiàn)以下功能：

在多條鏈上執(zhí)行指定的User Operations。
自動(dòng)完成跨鏈操作并達(dá)成最終目標(biāo)。

其技術(shù)基礎(chǔ)在于用戶對(duì)所有操作生成一個(gè)Merkle Root Hash簽章，然后透過Modular Execution Environment 自動(dòng)將這些操作上鏈執(zhí)行。

其他解決方案

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

ZeroDev：提供了類似的SDK，讓開發(fā)者可以方便地批量發(fā)送多鏈交易，簡化操作流程。
OneBalance：提供了Credible Account模組，支持整合多鏈的資產(chǎn)并實(shí)現(xiàn)Chain Abstraction。
Particle Network：采用Account-level Chain Abstraction，專注于網(wǎng)頁錢包的體驗(yàn)，率先打造具有Chain Abstraction 的應(yīng)用。
Nekodex：結(jié)合Chain Abstraction 以及基于Passkey 的Account Abstraction 統(tǒng)一DEX 上多鏈的交易體驗(yàn)，降低使用門檻

Part 3: Dev Tools

以太坊的開發(fā)生態(tài)持續(xù)進(jìn)步，各種工具大幅提升了開發(fā)者的效率，無論是在測(cè)試網(wǎng)的模擬、智能合約的除錯(cuò)，還是區(qū)塊鏈資料的索引，都有顯著的創(chuàng)新。以下是幾款值得關(guān)注的工具與解決方案。

Tenderly Virtual Test Net

Tenderly Virtual Test Net是一個(gè)強(qiáng)大的虛擬測(cè)試網(wǎng)工具，允許開發(fā)者fork 主網(wǎng)，其特色是能與主網(wǎng)保持即時(shí)同步狀態(tài)。同時(shí)它支援：

無限制的資源模擬：開發(fā)者可以隨時(shí)取得測(cè)試網(wǎng)上的以太坊或任意修改Storage 狀態(tài)。
CI 整合：通過Github Action，開發(fā)者能快速生成干凈的測(cè)試環(huán)境，用于合約部署與自動(dòng)化測(cè)試。

Simbolik

Simbolik是專為Solidity開發(fā)設(shè)計(jì)的除錯(cuò)工具，與VS Code無縫整合，只要在測(cè)試上方案下Debug 就能執(zhí)行。它的功能包括：

完整的EVM 環(huán)境可視化：能即時(shí)檢查每行Solidity 代碼執(zhí)行時(shí)的stack、memory和storage狀態(tài)。
EVM bytecode 分析：直觀展示編譯后的EVM bytecode 的執(zhí)行過程。

Simbolik 為開發(fā)者提供了高效且細(xì)致的除錯(cuò)支持，幫助快速定位并解決合約中的問題。

TrustBytes

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

函數(shù)調(diào)用關(guān)系可視化：清晰顯示合約中所有函數(shù)之間的調(diào)用路徑。
變數(shù)讀寫追蹤：快速定位變數(shù)的讀寫位置，分析潛在Re-entrancy 風(fēng)險(xiǎn)。
惡意輸入分析：標(biāo)示出哪些函數(shù)參數(shù)來自使用者輸入，幫助預(yù)防惡意攻擊。

TrustBytes 通過縮短代碼追蹤的時(shí)間以提升審計(jì)效率，特別是在分析潛在攻擊點(diǎn)方面?？蓞⒖计?a href="https://nextjsapp-7dycvtrugq-uc.a.run.app/" rel="nofollow" target="_blank">Demo 網(wǎng)站。

Ethereum Indexer

以太坊的資料結(jié)構(gòu)讓直接從JSON RPC 獲取資料效率低下，因此需要透過Indexer 將資料提取并存儲(chǔ)到高效的資料庫中。以下是兩個(gè)值得關(guān)注的解決方案。

Index Supply 的Shovel

Shovel 是一款開源工具，允許開發(fā)者透過簡單的config 檔，將鏈上資料轉(zhuǎn)化為指定格式并儲(chǔ)存到PostgreSQL DB。例如，紀(jì)錄一個(gè)錢包的歷史ERC20 Token Transfer 可以這樣設(shè)定：

{
"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 能快速完成資料的提取與存儲(chǔ)，大幅降低開發(fā)成本。

Reth Execution Extension

Reth Execution Extension提供了一種新穎且高效的設(shè)計(jì)，針對(duì)鏈上資料索引與Re-org（鏈重組）處理，解決了傳統(tǒng)方法中的諸多痛點(diǎn)。

過去，如果使用geth等節(jié)點(diǎn)軟體來擴(kuò)展功能，往往需要直接修改節(jié)點(diǎn)內(nèi)的程式碼，這樣的做法相當(dāng)于對(duì)節(jié)點(diǎn)進(jìn)行了fork。一旦上游節(jié)點(diǎn)有更新，開發(fā)者還需要持續(xù)合并更新的程式碼，這無疑增加了開發(fā)與維護(hù)的復(fù)雜性。

Reth 的創(chuàng)新之處在于其設(shè)計(jì)為可直接作為library import，開發(fā)者不需要fork 或修改節(jié)點(diǎn)本身的程式碼，就能靈活擴(kuò)展節(jié)點(diǎn)功能。

核心特點(diǎn)與通知機(jī)制

Reth 提供了清晰且靈活的通知介面，用于處理區(qū)塊鏈的三種狀態(tài)變化：

ChainCommitted：新區(qū)塊被確認(rèn)（Committed）。
ChainReorged：鏈重組導(dǎo)致出現(xiàn)新舊鏈切換。
ChainReverted：區(qū)塊被Revert

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

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

Part 4: Security

安全問題一直是區(qū)塊鏈領(lǐng)域的核心挑戰(zhàn)，從開發(fā)環(huán)境的設(shè)置，到設(shè)備與用戶端的保護(hù)，再到DeFi 合約層面的防御，都需要嚴(yán)密的措施來降低風(fēng)險(xiǎn)。以下針對(duì)開發(fā)、設(shè)備與DeFi 安全三大主題進(jìn)行探討。

開發(fā)環(huán)境安全（Dev Security）

在區(qū)塊鏈應(yīng)用的開發(fā)過程中，環(huán)境的安全性往往容易被忽視，但它可能成為駭客的突破口。

VS Code 信任機(jī)制的潛在風(fēng)險(xiǎn)

當(dāng)開發(fā)者在VS Code中開啟一個(gè)惡意的Repo 并點(diǎn)擊「Yes, I trust the authors」后，駭客可能利用.vscode 資料夾內(nèi)的設(shè)定執(zhí)行任意腳本，包括：

竊取電腦中的secret 或private key。
開啟一個(gè)reverse shell，讓駭客遠(yuǎn)端控制電腦。

這是因?yàn)?vscode 中的Tasks可以設(shè)置觸發(fā)特定條件的自動(dòng)執(zhí)行腳本（詳見官方文檔）。這種漏洞可能導(dǎo)致開發(fā)者的整個(gè)系統(tǒng)處于被駭客接管的風(fēng)險(xiǎn)中。

防范措施：使用Sandbox 環(huán)境

為避免上述風(fēng)險(xiǎn)，開發(fā)者應(yīng)在Sandbox 環(huán)境中開啟專案。具體來說，可以使用VS Code 的Dev Container 功能，在Docker 容器中執(zhí)行完整的開發(fā)環(huán)境。這樣即使惡意代碼執(zhí)行，也只會(huì)影響隔離的容器，不會(huì)危及主機(jī)系統(tǒng)。

Github Action Self Hosted Runner 的風(fēng)險(xiǎn)

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

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

這一風(fēng)險(xiǎn)已被詳述于Synacktiv 的報(bào)告。建議避免在Public Repo 中使用Self Hosted Runner，或采用更嚴(yán)格的權(quán)限管理。

設(shè)備安全（Device Security）

Ledger 的研究顯示iOS 和Android 平臺(tái)的Syncable Passkey實(shí)作并不像預(yù)期中那么安全。主要問題在于：

私鑰復(fù)制到應(yīng)用程式記憶體：雖然Passkey 本應(yīng)依賴Secure Enclave 來存儲(chǔ)私鑰，但實(shí)際上私鑰可能會(huì)被復(fù)制到應(yīng)用程式記憶體（application memory）。這使得私鑰暴露于潛在的惡意軟體攻擊之下，例如透過監(jiān)聽記憶體來竊取私鑰。
記憶體快取問題：某些平臺(tái)的快取機(jī)制會(huì)在裝置解鎖之前就將私鑰暫存到記憶體中，進(jìn)一步增加了被惡意軟體利用的風(fēng)險(xiǎn)。

安全建議

為了降低使用Passkey 帶來的風(fēng)險(xiǎn)，建議采取以下措施：

選擇Un-syncable Passkey：在創(chuàng)建Passkey 時(shí)，選擇「不可同步」（Un-syncable）的選項(xiàng)，避免私鑰在不同設(shè)備之間同步時(shí)的潛在安全問題。
避免存放大量資金：不要將過多資金存放于Passkey 錢包中，僅作為小額支付或日常操作使用。
使用硬體錢包：對(duì)于高價(jià)值資產(chǎn)，建議繼續(xù)使用硬體錢包作為主要的存儲(chǔ)方式，因?yàn)橛搀w錢包提供了更高的安全保證。

這些建議可以有效降低Passkey 在日常應(yīng)用中的潛在風(fēng)險(xiǎn)，同時(shí)確保資產(chǎn)的安全性。

DeFi 安全（DeFi Security）

區(qū)塊鏈應(yīng)用最核心的DeFi 領(lǐng)域，因其高額資金流動(dòng)性，成為駭客攻擊的主要目標(biāo)。防范這類風(fēng)險(xiǎn)需要智能合約與基礎(chǔ)設(shè)施層面的共同努力。例如Forta提供了一種基于AI 模型的鏈上防火墻，用于過濾潛在攻擊交易。其運(yùn)作機(jī)制如下：

交易簽名驗(yàn)證：DeFi 合約需要為合約中的關(guān)鍵方法加上Forta 的簽章參數(shù)
交易模擬與風(fēng)險(xiǎn)評(píng)估：Forta 的RPC 節(jié)點(diǎn)將模擬交易執(zhí)行過程，通過AI 模型評(píng)估風(fēng)險(xiǎn)分?jǐn)?shù)。 Fora 已經(jīng)實(shí)現(xiàn)99% 以上的準(zhǔn)確度
執(zhí)行控制：只有風(fēng)險(xiǎn)分?jǐn)?shù)低于門檻值的交易才會(huì)獲得簽名并被放行。

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

升級(jí)與整合困難：DeFi 協(xié)議需要修改合約以整合Forta 的系統(tǒng)，這對(duì)現(xiàn)有協(xié)議的升級(jí)是一大挑戰(zhàn)，尤其是影響到可組合性，因?yàn)槠渌鸇eFi 協(xié)議就無法輕易呼叫自己的合約。
交易模擬問題：在鏈下的環(huán)境模擬交易執(zhí)行的結(jié)果可能與實(shí)際上鏈的結(jié)果不同，有機(jī)會(huì)被駭客利用
順序依賴問題：由于L2 鏈上交易的執(zhí)行順序是由Sequencer 決定，駭客有機(jī)會(huì)透過交易順序的不一致性來在模擬時(shí)產(chǎn)生正常的結(jié)果，拿到簽章后上鏈執(zhí)行惡意交易

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

Part 5: Fuzz Testing

Fuzz Testing 是一種強(qiáng)大的測(cè)試技術(shù)，其核心原理是透過大量隨機(jī)的輸入測(cè)試智能合約，試圖觸發(fā)意外的邏輯漏洞。這種方法對(duì)于捕捉人眼難以察覺的邊緣情境（corner cases）尤其有效。

Fuzz Testing 的原理與限制

Fuzzer 的主要作用是持續(xù)嘗試各種隨機(jī)輸入來檢測(cè)智能合約是否能滿足定義的Invariant（不可變條件）。開發(fā)者可以利用這種方法進(jìn)行黑箱測(cè)試，模擬合約的實(shí)際使用情境，并驗(yàn)證其邏輯是否能抵抗各種異常操作。

盡管Fuzz Testing 是捕捉邏輯漏洞的有效工具，但找不到漏洞并不代表合約沒有問題。 Fuzzer 的效果取決于定義的Invariant 是否完善，以及隨機(jī)測(cè)試的覆蓋范圍。

案例分析：Vesting 合約漏洞

以下是一個(gè)簡化的Vesting智能合約范例，其目的是實(shí)現(xiàn)用戶的積分分配與轉(zhuǎn)移，完整程式碼在solidity-fuzzing-comparison Repo 中的09-vesting 。然而，該合約存在一個(gè)漏洞：用戶可以通過「自我轉(zhuǎn)移」增加自己的積分，進(jìn)而破壞總積分不變的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;
}
}

用戶可以將自己的積分轉(zhuǎn)移給自己（self-transfer），導(dǎo)致總積分超出限制，破壞合約中「所有用戶積分總和應(yīng)等于總分?jǐn)?shù)」的Invariant。然而就算我們不細(xì)看transferPoints的實(shí)作，也能透過對(duì)其黑箱的Fuzzing 來找到問題。

設(shè)計(jì)Invariant：思考不可變條件

在測(cè)試此合約時(shí)，可以設(shè)計(jì)以下兩個(gè)主要Invariant：

初始化階段：所有用戶的積分總和應(yīng)等于TOTAL_POINTS。
執(zhí)行階段：在任意操作后，所有用戶的積分總和仍應(yīng)保持不變。

這些Invariant 可以被用于多個(gè)Fuzzer 的測(cè)試過程中。

使用Chimera 框架進(jìn)行測(cè)試

Chimera 是一個(gè)功能強(qiáng)大的多工具整合框架，允許開發(fā)者一次撰寫測(cè)試代碼，并同時(shí)在多個(gè)Fuzzer 工具上執(zhí)行。以下是使用Chimera 的步驟：

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

2、設(shè)定測(cè)試環(huán)境：建立一個(gè)Setup.sol 文件來初始化測(cè)試合約，并追蹤需要檢查的狀態(tài)。

// 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、實(shí)現(xiàn)Invariant：定義檢查條件，例如所有用戶的積分總和應(yīng)等于總積分。

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、定義如何測(cè)試目標(biāo)函數(shù)：指定transferPoints 參數(shù)需滿足的條件，避免因錯(cuò)誤參數(shù)導(dǎo)致的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、執(zhí)行Fuzz Testing

forge test --match-contract VestingCryticToFoundry

可以看到Fuzzer 在短時(shí)間內(nèi)就找到了打破不變量的方法

修復(fù)漏洞

漏洞的解法是避免自我轉(zhuǎn)移：

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

修復(fù)后再執(zhí)行一次測(cè)試即可通過了

Fuzz Testing for ZK Infrastructure

零知識(shí)基礎(chǔ)設(shè)施（Zero-Knowledge Infrastructure, ZK Infra）涉及編譯、執(zhí)行、生成證明與驗(yàn)證ZK 電路的多個(gè)核心軟體元件，對(duì)其進(jìn)行漏洞檢測(cè)至關(guān)重要。 Fuzz Testing 是檢測(cè)這些基礎(chǔ)設(shè)施漏洞的一項(xiàng)強(qiáng)大工具，尤其適合處理其高復(fù)雜性與高安全需求的特性。

基于黑箱測(cè)試的隨機(jī)變換與不變性檢測(cè)

零知識(shí)基礎(chǔ)設(shè)施的測(cè)試需要克服其內(nèi)部實(shí)現(xiàn)的高度復(fù)雜性，黑箱測(cè)試因此成為檢測(cè)漏洞的有效方法。在這種測(cè)試中，開發(fā)者將處理流程視作不可見的黑箱，僅根據(jù)輸入和輸出進(jìn)行分析。

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

例如，一個(gè)表達(dá)式P 轉(zhuǎn)換為P × 1 − 0 時(shí)，應(yīng)保持輸出一致，否則可能指向Witness Generator 或編譯器中的潛在問題。

持續(xù)且多元測(cè)試

由于零知識(shí)基礎(chǔ)設(shè)施經(jīng)常被用于Layer 2 協(xié)議，將乘載數(shù)億美金以上的價(jià)值，其安全性至關(guān)重要，因此持續(xù)測(cè)試顯得尤為必要。這可以通過自動(dòng)化測(cè)試工具來實(shí)現(xiàn)，保證每次代碼更新后都能迅速發(fā)現(xiàn)潛在漏洞。

測(cè)試還需要支持多種零知識(shí)DSL，如Circum、Gnark 和Noir，確保適用于廣泛場(chǎng)景。同時(shí)，F(xiàn)uzz Testing 工具應(yīng)具備自動(dòng)化反饋功能，能夠持續(xù)執(zhí)行并根據(jù)發(fā)現(xiàn)的問題進(jìn)行改進(jìn)。此外，測(cè)試生成的輸入應(yīng)盡量簡化，以便開發(fā)者快速理解并定位問題。

Part 6: Formal Verification

Formal Verification（形式化驗(yàn)證）是一種透過數(shù)學(xué)方式驗(yàn)證軟體是否符合特定Formal Spec（規(guī)格）的技術(shù)。對(duì)于智能合約而言，這種方法能有效檢查合約在所有可能狀態(tài)下的正確性。與Fuzz Testing（模糊測(cè)試）相比，F(xiàn)ormal Verification 的驗(yàn)證過程更為系統(tǒng)化，能夠覆蓋所有可能的狀態(tài)并「數(shù)學(xué)證明」合約邏輯的正確性。

然而，F(xiàn)ormal Verification 的實(shí)施通常需要嚴(yán)謹(jǐn)?shù)囊?guī)格定義，且計(jì)算成本較高。另一方面，F(xiàn)uzz Testing 則透過隨機(jī)輸入測(cè)試合約，具有輕量且能快速發(fā)現(xiàn)邊界問題的特性，但其測(cè)試范圍有限，可能無法檢測(cè)更深層的邏輯漏洞。

Certora

Certora 提供了一套完整的工具來彌補(bǔ)這些不足，幫助開發(fā)者在現(xiàn)實(shí)環(huán)境中應(yīng)用Formal Verification。其主要產(chǎn)品Certora Prover為智能合約提供了強(qiáng)大的驗(yàn)證框架，允許開發(fā)者定義規(guī)則并自動(dòng)化驗(yàn)證合約的邏輯正確性。

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

Certora Prover：一個(gè)驗(yàn)證平臺(tái)，允許開發(fā)者使用Certora Verification Language (CVL)定義規(guī)格并測(cè)試合約邏輯。
整合式框架：透過設(shè)定檔與腳本執(zhí)行驗(yàn)證。
詳細(xì)報(bào)告：自動(dòng)生成驗(yàn)證結(jié)果，包含失敗的詳細(xì)原因與對(duì)應(yīng)的測(cè)試輸入，協(xié)助快速定位問題。

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

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

// 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：撰寫規(guī)格

以下是一個(gè)簡單的規(guī)格，檢查totalVotes 是否在每次投票后遞增：

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

步驟2：設(shè)定config

使用以下.conf 檔案來設(shè)定驗(yàn)證細(xì)節(jié)，包括要驗(yàn)證的合約與規(guī)范檔案。

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

步驟3：執(zhí)行驗(yàn)證

在專案根目錄執(zhí)行以下指令：

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

如果還沒有API Key，可以在官方網(wǎng)站注冊(cè)取得。輸出中會(huì)有一個(gè)Certora Prover 結(jié)果的連結(jié)，點(diǎn)進(jìn)去即可看到Prover 找到了一個(gè)錯(cuò)誤，并提供詳細(xì)的輸入?yún)?shù)

步驟4：修復(fù)問題

修改合約邏輯以修復(fù)問題：

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：重新驗(yàn)證

再次執(zhí)行驗(yàn)證，確認(rèn)所有規(guī)范均已通過，代表此智能合約的正確性可被數(shù)學(xué)證明。

進(jìn)階功能：驗(yàn)證不變性（Inductive Invariants）

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

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

此規(guī)則驗(yàn)證totalVotes 永遠(yuǎn)等于贊成與反對(duì)票數(shù)的總和。

Part 7: Maximal Extractable Value (MEV)

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

CoW Swap 的MEV 解決方案

CoW Swap 的核心主張是，MEV 問題的根源在應(yīng)用層。目前約99% 的MEV 問題來自交易排序的競(jìng)爭(zhēng)，而應(yīng)用層（例如去中心化交易所DEX）的設(shè)計(jì)是導(dǎo)致這些問題的主因。因此，MEV 問題應(yīng)該在設(shè)計(jì)應(yīng)用時(shí)一并考慮，而非依賴基礎(chǔ)設(shè)施層的迂回解決方案。

Coincidence of Wants（需求的巧合）

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

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

Batch Auction（批次拍賣）

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

收集交易意圖：在鏈下收集并聚合用戶的交易意圖。
批次處理：將在特定時(shí)間段內(nèi)收集的交易意圖組合成一個(gè)批次，這些批次通常每隔幾秒鐘產(chǎn)生一次。
競(jìng)價(jià)解決方案：通過競(jìng)標(biāo)機(jī)制選擇最佳的解決方案提供者（solver），這些提供者競(jìng)爭(zhēng)以提供最優(yōu)交易執(zhí)行方案，為用戶帶來最大的價(jià)格盈余。
統(tǒng)一清算價(jià)格：所有涉及相同資產(chǎn)的交易都以統(tǒng)一的清算價(jià)格結(jié)算，使交易順序變得無關(guān)緊要，從而減少M(fèi)EV 攻擊。

批次拍賣的優(yōu)勢(shì)：

MEV 保護(hù)：批次拍賣透過統(tǒng)一清算價(jià)格，使交易順序的影響被弱化，顯著削減MEV 攻擊的空間。
資產(chǎn)匹配：直接點(diǎn)對(duì)點(diǎn)交換，無需觸及鏈上流動(dòng)性。
最佳價(jià)格保證：確保用戶交易的價(jià)格不低于在AMM 上直接獲得的價(jià)格。

實(shí)際案例：

假設(shè)有三位用戶的交易意圖：

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

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

Unichain 的MEV 解決方案

與CoW Swap 將MEV 處理集中在應(yīng)用層的設(shè)計(jì)不同，Unichain 選擇在基礎(chǔ)設(shè)施層通過可信執(zhí)行環(huán)境（TEE）來解決MEV 問題。 Unichain 是基于OP Stack 的Optimistic Rollup，其核心創(chuàng)新在于加密交易與TEE 排序，保證交易排序的透明與公平。

Unichain 解決MEV 的關(guān)鍵流程：

加密交易：使用者在發(fā)送交易時(shí)，首先使用TEE 的公鑰加密交易內(nèi)容。因此，在mempool 中，所有節(jié)點(diǎn)看到的交易都是加密的，無法直接得知交易的細(xì)節(jié)，自然也就無法通過交易排序提取MEV。
TEE 排序：只有在TEE 環(huán)境內(nèi)才能解密交易并進(jìn)行排序。 TEE 會(huì)根據(jù)預(yù)設(shè)的規(guī)則排序交易并構(gòu)建區(qū)塊，最終生成的排序結(jié)果帶有TEE 的簽章，保證排序過程的透明度。
返還MEV 收益：對(duì)于普通用戶，Unichain 提供接近零成本的Gas 費(fèi)，同時(shí)完全避免了被搶跑（front-run）的風(fēng)險(xiǎn)。而對(duì)于MEV Searcher，他們需要支付更高的Gas 費(fèi)來競(jìng)爭(zhēng)區(qū)塊的前位。這些額外的收益會(huì)被Unichain 用于回饋給驗(yàn)證者，形成公平的經(jīng)濟(jì)激勵(lì)。

Part 8: Zero Knowledge Proof (ZKP)

Zero Knowledge Proof (ZKP) 技術(shù)的應(yīng)用展示了如何透過密碼學(xué)方法，實(shí)現(xiàn)隱私保護(hù)與效能的平衡。以下將介紹幾個(gè)令我印象深刻的ZK 應(yīng)用。

ZKPassport

ZKPassport結(jié)合了國際電子護(hù)照（ePassport）的晶片技術(shù)與ZKP，為用戶提供一種既安全又隱私的身份驗(yàn)證方式。透過手機(jī)感應(yīng)護(hù)照的NFC，用戶可以取得護(hù)照晶片中由政府簽署的資料，例如基本資訊和照片。由于這基于全球標(biāo)準(zhǔn)（IC AO Biometric Passport），超過100 個(gè)國家的護(hù)照均可支援。基于此簽章即可生成護(hù)照資料有效性的零知識(shí)證明。

技術(shù)特點(diǎn)

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

應(yīng)用場(chǎng)景

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

ZK Email

ZK Email是一個(gè)基于零知識(shí)證明的Email 驗(yàn)證應(yīng)用，允許用戶選擇性地驗(yàn)證郵件內(nèi)容。例如，證明Email 的發(fā)信人是否為特定組織、Email 內(nèi)文是否有特定文字，而無需公開整封郵件的內(nèi)容。關(guān)鍵是采用每個(gè)Email 都會(huì)由Mail Server 簽署的DKIM Signature，產(chǎn)生一封信是由該域名發(fā)出的零知識(shí)證明，且無法被偽造。

技術(shù)特點(diǎn)

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

應(yīng)用場(chǎng)景

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

技術(shù)挑戰(zhàn)

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

ZKP2P

ZKP2P是一個(gè)基于零知識(shí)證明技術(shù)的域名交易市場(chǎng)，旨在提供快速、安全、去中心化的域名交易體驗(yàn)。該平臺(tái)支持利用零知識(shí)證明驗(yàn)證域名所有權(quán)，并使用ETH 進(jìn)行域名交易。目前ZKP2P 已支援使用者交易Namecheap 上的域名。

域名交易的核心機(jī)制

域名所有權(quán)驗(yàn)證：平臺(tái)使用一種基于密碼學(xué)的Web 認(rèn)證協(xié)議來驗(yàn)證域名的所有權(quán)。賣家需使用ZKP2P 提供的瀏覽器Extension，從Namecheap 網(wǎng)站生成不可篡改的域名所有權(quán)證明，并提交到智能合約中。
交易過程中的隱私保護(hù)：買家在提交購買申請(qǐng)時(shí)，需提供Namecheap 用戶名，該資訊會(huì)加密處理，僅賣家可見。
資金鎖定：買家的ETH 會(huì)先被鎖定在智能合約的托管中，直到賣家完成域名轉(zhuǎn)讓并提供相關(guān)的零知識(shí)證明后，資金才會(huì)釋放。
零知識(shí)證明的使用：賣家轉(zhuǎn)移域名后會(huì)收到Namecheap 的確認(rèn)信，因此ZKP2P 使用ZK Email 產(chǎn)生這封信的零知識(shí)證明，確保域名已轉(zhuǎn)移給買方。

技術(shù)特點(diǎn)與優(yōu)勢(shì)

隱私與安全性：ZKP2P 通過加密用戶敏感資訊（例如Namecheap 用戶名）來保護(hù)隱私，確保只有域名賣方能看到買方的用戶名。
去中心化與透明性：平臺(tái)所有的交易驗(yàn)證過程均在智能合約中執(zhí)行，減少對(duì)第三方的依賴，并提高整體透明度。
降低交易成本：每筆交易僅收取2.5% 的交易費(fèi)用，遠(yuǎn)低于其他域名交易市場(chǎng)（一般超過10%），讓買賣雙方都能享受更低的交易成本。

Polygon ZisK

Polygon 正在開發(fā)新一代的ZKVM 證明系統(tǒng)ZisK，目標(biāo)是實(shí)現(xiàn)即時(shí)證明整個(gè)EVM 區(qū)塊中所有交易的計(jì)算。 ZisK 的設(shè)計(jì)核心在于其通用性（Generic ZKVM）和極致的證明生成速度優(yōu)化，旨在提升零知識(shí)證明在區(qū)塊鏈應(yīng)用中的性能。

ZisK 的設(shè)計(jì)架構(gòu)

ZisK 的架構(gòu)受到嵌入式系統(tǒng)（Embedded System）的啟發(fā)，采用了模組化的設(shè)計(jì)，主要組件包括：

ROM（只讀存儲(chǔ)器）：儲(chǔ)存ZKVM 的程序邏輯和靜態(tài)數(shù)據(jù)。
ZisK Processor（處理器）：負(fù)責(zé)執(zhí)行電路的核心計(jì)算邏輯。
RAM（隨機(jī)存取存儲(chǔ)器）：用于儲(chǔ)存臨時(shí)數(shù)據(jù)和中間結(jié)果，支援高效的數(shù)據(jù)訪問。
Bus（總線）：負(fù)責(zé)連接ZisK 系統(tǒng)內(nèi)部的各模組，協(xié)調(diào)訊息交換。

目前，ZisK 還處于非常早期的開發(fā)階段，可參考其開發(fā)文件。

Reclaim Protocol

Reclaim Protocol 是一個(gè)將TLS Proxy 技術(shù)與零知識(shí)證明（Zero-Knowledge Proof, ZKP）相結(jié)合的隱私保護(hù)協(xié)議，旨在讓用戶能夠在不泄露敏感資訊的前提下，驗(yàn)證HTTPS 通訊內(nèi)容的真實(shí)性。該協(xié)議為資料驗(yàn)證與互操作性提供了安全的解決方案，尤其適用于Web2 和Web3 場(chǎng)景的整合。

TLS Proxy 機(jī)制

Reclaim Protocol 的核心依賴于TLS Proxy 作為信任中介。過程中HTTPS 請(qǐng)求和回應(yīng)會(huì)經(jīng)過TLS Proxy，并由Proxy 簽署該流量的加密內(nèi)容，從而為后續(xù)的證明生成提供基礎(chǔ)。 TLS Proxy 的角色僅限于簽署加密流量，無法解密任何資料，這也減少了隱私風(fēng)險(xiǎn)。

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

然而盡管TLS Proxy 提供了關(guān)鍵的信任保障，在極端網(wǎng)路條件下（例如BGP Hijack 攻擊），可能會(huì)出現(xiàn)Proxy 認(rèn)證的流量被路由到錯(cuò)誤伺服器的風(fēng)險(xiǎn)。這種攻擊需要在TLS Handshake 后精準(zhǔn)篡改流量，實(shí)現(xiàn)難度極高，但這仍是協(xié)議中需要特別關(guān)注的安全邊界。

zkTLS 技術(shù)細(xì)節(jié)

Reclaim Protocol 結(jié)合了ZKP 技術(shù)，允許用戶在不泄露完整TLS 明文的前提下驗(yàn)證其真實(shí)性，其ZK 電路的設(shè)計(jì)旨在處理解密與部分揭露的功能。

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

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

應(yīng)用場(chǎng)景

Reclaim Protocol 目前將重點(diǎn)放在Web2 場(chǎng)景的資料互操作性上，解決不同平臺(tái)間的數(shù)據(jù)共享問題。例如：

電商優(yōu)惠：用戶可以從A 電商生成消費(fèi)記錄的ZKTLS 證明，并將其提供給B 電商以獲取專屬優(yōu)惠，精準(zhǔn)吸引新用戶。在這一過程中，協(xié)議可確保B 電商只能知道消費(fèi)總金額，而不會(huì)接觸完整的消費(fèi)明細(xì)。
身份驗(yàn)證：用戶可使用協(xié)議生成ZKTLS 證明，證明其在特定平臺(tái)的活動(dòng)，如在某論壇的參與情況，或在某開發(fā)者平臺(tái)的貢獻(xiàn)數(shù)據(jù)。

技術(shù)與信任的挑戰(zhàn)

信任TLS Proxy：協(xié)議需要用戶信任TLS Proxy，因?yàn)镻roxy 會(huì)簽署HTTPS 流量，成為證明可信來源的基礎(chǔ)。
ZK 證明的鏈上應(yīng)用：由于目前ZK 證明的鏈上驗(yàn)證成本較高，Reclaim Protocol 將應(yīng)用重點(diǎn)放在Web2 場(chǎng)景，尚未在鏈上進(jìn)行完整的ZK 驗(yàn)證。
網(wǎng)路攻擊風(fēng)險(xiǎn)：極端情況下，如BGP Hijack，可能導(dǎo)致TLS Proxy 無法正常運(yùn)作，但這類攻擊需要精確的時(shí)間和網(wǎng)路控制，實(shí)現(xiàn)難度極高。

vLayer

Vlayer是一家專注于開發(fā)「可驗(yàn)證資料基礎(chǔ)設(shè)施」的加密初創(chuàng)公司，稱之為「Solidity 2.0」。其目標(biāo)是使開發(fā)者能夠?qū)⒄鎸?shí)世界的資料驗(yàn)證后整合至以太坊智能合約中。具體而言，Vlayer 為Solidity 語言引入了四個(gè)新功能：

Time Travel：允許智能合約使用歷史鏈上資料。
Teleport：使合約能在多個(gè)EVM 兼容的網(wǎng)絡(luò)上運(yùn)行。
Web Proofs（zkTLS）：驗(yàn)證并整合網(wǎng)頁內(nèi)容，包括API 和網(wǎng)站。
Email Proofs（ZK Email）：存取并驗(yàn)證電子郵件內(nèi)容。

這些功能旨在擴(kuò)展智能合約的應(yīng)用范圍，特別是在去中心化金融（DeFi）、真實(shí)世界資產(chǎn)（RWA）和游戲等領(lǐng)域。目前，Vlayer 正處于Alpha 階段，邀請(qǐng)開發(fā)者在其平臺(tái)上進(jìn)行開發(fā)，并計(jì)劃于2025 年推出測(cè)試網(wǎng)、主網(wǎng)和代幣。

Mopro

Mopro（Mobile Prover）是一個(gè)專為Mobile 環(huán)境開發(fā)的ZK 證明生成工具，以簡化客戶端的證明過程。 Mopro 的主要特點(diǎn)包括：

易用性：簡化了在移動(dòng)應(yīng)用中整合ZK 證明的復(fù)雜性
高性能：比在瀏覽器上使用snarkjs 更快，并嘗試使用GPU 優(yōu)化性能
跨平臺(tái)兼容性：支援iOS、Android 平臺(tái)

然而，在Mobile 環(huán)境下仍存在一些挑戰(zhàn)：

GPU 加速的限制：雖然Mopro 嘗試?yán)肎PU 提升性能，但由于移動(dòng)設(shè)備使用的Metal API 不如桌面端CUDA 易于優(yōu)化，開發(fā)上面臨一定難度。然而，數(shù)據(jù)顯示在處理大型電路時(shí)，Mopro 的性能表現(xiàn)有望優(yōu)于其他傳統(tǒng)工具。
記憶體限制：Mobile 設(shè)備的記憶體容量有限是主要挑戰(zhàn)之一，特別是在運(yùn)行復(fù)雜的ZK 電路（如ZK Email）時(shí)，可能會(huì)因內(nèi)存不足導(dǎo)致應(yīng)用Crash

Part 9: Multi-Party Computation (MPC)

MPC是一種密碼學(xué)技術(shù)，允許多方在不泄露各自輸入的情況下，共同計(jì)算一個(gè)函數(shù)的結(jié)果。其與ZK 的差別在于：

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

以下介紹幾個(gè)MPC 的應(yīng)用與最新研究，展示其在隱私保護(hù)與分布式計(jì)算中的潛力。

World ID

World ID是Worldcoin的核心技術(shù)，旨在為每位用戶建立獨(dú)特的數(shù)位身份，用以證明個(gè)人的「唯一性」。注冊(cè)過程中，使用者需透過「虹膜掃描」驗(yàn)證身份，確保每人僅能注冊(cè)一次。這需要將新掃描的虹膜與已注冊(cè)的數(shù)據(jù)庫進(jìn)行比對(duì)。然而，大量集中存儲(chǔ)的真實(shí)虹膜數(shù)據(jù)可能帶來巨大的隱私風(fēng)險(xiǎn)。

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

技術(shù)細(xì)節(jié)與流程

資料的Secret Sharing：用戶的虹膜掃描資料被拆分為三個(gè)Secret Share，分發(fā)給三個(gè)計(jì)算方，確保單一計(jì)算方無法取得完整的虹膜資料。
Hamming 距離計(jì)算：透過內(nèi)積運(yùn)算將用戶的虹膜資料與資料庫中的虹膜逐一比對(duì)，計(jì)算Hamming 距離并與設(shè)定的閾值進(jìn)行比較。整個(gè)過程在MPC 框架下執(zhí)行，確保數(shù)據(jù)隱私不被泄露。
結(jié)果聚合：將比對(duì)結(jié)果以邏輯OR 聚合，產(chǎn)生最終的驗(yàn)證結(jié)果，判斷虹膜的唯一性。

World ID 最大的技術(shù)挑戰(zhàn)在于計(jì)算成本高昂：Worldcoin 的使用者數(shù)已超過1,600 萬，每次唯一性驗(yàn)證需要針對(duì)龐大的數(shù)據(jù)庫進(jìn)行線性掃描。在GPU 加速環(huán)境下，一次驗(yàn)證需要32 臺(tái)NVIDIA H100 GPU，峰值網(wǎng)絡(luò)吞吐量達(dá)2.5 Tbps。

因此，Worldcoin 正積極探索計(jì)算資源需求更低但驗(yàn)證嚴(yán)謹(jǐn)度相對(duì)較低的替代方案，例如借鑒ZKPassport的護(hù)照唯一性證明機(jī)制，以在減少成本的同時(shí)保持足夠的驗(yàn)證可信度。

MPCStats

MPCStats是一個(gè)基于MPC 的開源框架，旨在實(shí)現(xiàn)多方參與的統(tǒng)計(jì)計(jì)算，同時(shí)保護(hù)數(shù)據(jù)隱私。該框架允許多個(gè)數(shù)據(jù)提供者匿名參與計(jì)算，結(jié)果公開但不泄露個(gè)人數(shù)據(jù)細(xì)節(jié)。

技術(shù)特點(diǎn)

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

展場(chǎng)Demo

在Devcon 展會(huì)中，MPCStats 提供了一個(gè)Demo，讓參與者私密分享其Binance ETH 余額，計(jì)算平均值。數(shù)據(jù)的完整性由TLS Notary證明，最終生成可信且隱私保護(hù)的統(tǒng)計(jì)結(jié)果。

Public Auditable MPC

Public Auditable MPC（PAMPC）是一種結(jié)合MPC 和零知識(shí)證明（ZK）的新型協(xié)議，旨在解決現(xiàn)有MPC 系統(tǒng)中無法向第三方驗(yàn)證計(jì)算正確性的挑戰(zhàn)。該協(xié)議允許計(jì)算方在保護(hù)輸入隱私的同時(shí)，向第三方公開驗(yàn)證計(jì)算結(jié)果的正確性。

核心概念與技術(shù)

引入Collaborative ZK-SNARKs：PAMPC 使用協(xié)作式ZK-SNARKs，將每個(gè)計(jì)算方生成的部分證明（proof）進(jìn)行線性聚合產(chǎn)生完整證明，確保計(jì)算的正確性可被第三方驗(yàn)證。
處理輸入一致性問題：在MPC 的預(yù)處理和在線階段中，透過對(duì)輸入數(shù)據(jù)進(jìn)行Commit，確保數(shù)據(jù)的一致性。
加速位元運(yùn)算：傳統(tǒng)的SPDZ MPC 協(xié)議對(duì)于加法和乘法支持良好，但在處理位元運(yùn)算時(shí)效率低下。 PAMPC 對(duì)SPDZ 進(jìn)行了優(yōu)化。

應(yīng)用場(chǎng)景與優(yōu)勢(shì)

電子投票：在保護(hù)選民隱私的同時(shí)，提供公開驗(yàn)證機(jī)制，增強(qiáng)系統(tǒng)透明度同時(shí)保護(hù)隱私。
去中心化拍賣：確保拍賣結(jié)果的公正性，同時(shí)保護(hù)投標(biāo)者的隱私。
醫(yī)療數(shù)據(jù)與機(jī)器學(xué)習(xí)：PAMPC 特別適合于需要多方共享敏感數(shù)據(jù)的場(chǎng)景，例如多機(jī)構(gòu)合作訓(xùn)練機(jī)器學(xué)習(xí)模型。各機(jī)構(gòu)可以保留數(shù)據(jù)隱私，同時(shí)協(xié)作完成模型訓(xùn)練或預(yù)測(cè)。
去中心化游戲：PAMPC 可被應(yīng)用于去中心化游戲中，如狼人殺（Werewolf/Mafia）游戲，通過MPC 確保角色分配、投票計(jì)算的隱私性與正確性，而不需要游戲主持者(GM) 。

Part 10: Programmable Cryptography

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

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

相對(duì)而言，可程式化密碼學(xué)將密碼學(xué)設(shè)計(jì)的數(shù)學(xué)問題轉(zhuǎn)化為工程問題，允許開發(fā)者寫程式來實(shí)現(xiàn)任意密碼學(xué)操作。以下是一些重要技術(shù)：

零知識(shí)證明（zkSNARKs）：證明程式在私密輸入上的正確執(zhí)行，無需泄露輸入。
多方計(jì)算（MPC）：在多方私密數(shù)據(jù)上進(jìn)行計(jì)算，僅揭示最終結(jié)果。
完全同態(tài)加密（FHE）：允許在加密狀態(tài)下執(zhí)行任意運(yùn)算，運(yùn)算結(jié)果仍為加密狀態(tài)。
不可區(qū)分混淆（iO）：將程式加密，讓程式可執(zhí)行但不可解析內(nèi)部邏輯，被譽(yù)為密碼學(xué)的「圣杯」，因其能構(gòu)建所有其他密碼學(xué)工具。

最理想的Internet

可程式化密碼學(xué)能幫助實(shí)現(xiàn)Internet 的理想狀態(tài)，包括：

去中心化（P2P）：恢復(fù)網(wǎng)路對(duì)等性，避免數(shù)據(jù)和計(jì)算集中化。
隱私保護(hù)：讓數(shù)據(jù)擁有者控制其數(shù)據(jù)使用方式。
資料互操作性：不同應(yīng)用間數(shù)據(jù)能無縫流轉(zhuǎn)并保持真實(shí)性與隱私。
信任最小化與無需許可：用數(shù)學(xué)保證取代對(duì)中央機(jī)構(gòu)的信任，任何人均可參與。

例如，MPC 與FHE 技術(shù)讓伺服器在完全不了解用戶數(shù)據(jù)的前提下，完成計(jì)算任務(wù)，同時(shí)確保計(jì)算結(jié)果的可驗(yàn)證性，這代表使用者資料將永遠(yuǎn)由自己掌控。

以下透過兩個(gè)例子解釋，為何有了可程式化密碼學(xué)后，能建構(gòu)理想的社交網(wǎng)路與投票應(yīng)用。

去中心化Facebook

過去當(dāng)人們思考去中心化社交網(wǎng)路時(shí)，總是想先模仿Twitter，原因是Twitter 的機(jī)制較為單純：每個(gè)使用者可以公開發(fā)布內(nèi)容，任何人都能看到其他人的內(nèi)容。然而相較于去中心化Twitter，去中心化Facebook 的實(shí)現(xiàn)更加復(fù)雜，因其數(shù)據(jù)拓?fù)浜碗[私要求更高：

隱私設(shè)置：用戶可能只想讓特定好友查看特定內(nèi)容。
朋友的朋友權(quán)限：需動(dòng)態(tài)計(jì)算貼文可見性范圍。
推薦演算法（News Feed）：需要整合多方數(shù)據(jù)進(jìn)行運(yùn)算。

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

投票系統(tǒng)的技術(shù)演進(jìn)

投票是個(gè)很好的案例，因?yàn)樗枰瑫r(shí)滿足許多特性，才能做到公平、隱私且公正。在加入不同的可程式化密碼學(xué)技術(shù)后，能一步步朝向理想的投票系統(tǒng)邁進(jìn)：

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

ZuPass

ZuPass是由0xPARC 推出的一個(gè)實(shí)驗(yàn)性應(yīng)用，基于可程式化密碼學(xué)（Programmable Cryptography）的概念設(shè)計(jì)，旨在幫助使用者實(shí)現(xiàn)對(duì)自身資料的自主管理與跨平臺(tái)互操作性。 ZuPass 的核心是Proof-Carrying Data (PCD)，使用者可以在保護(hù)隱私的前提下安全儲(chǔ)存并證明其數(shù)據(jù)的有效性。

以下介紹幾個(gè)在本次Devcon 會(huì)場(chǎng)的ZuPass 應(yīng)用。使用ZuPass 的應(yīng)用又被稱為ZApp

Devcon 門票驗(yàn)證

ZuPass 在Devcon 活動(dòng)中被用來驗(yàn)證與會(huì)者身份，其原理如下：

使用者的Devcon 票券以PCD 的形式存入ZuPass。
當(dāng)需要進(jìn)場(chǎng)時(shí)，使用者可透過ZuPass 生成零知識(shí)證明（Zero-Knowledge Proofs, ZK Proof），證明自己持有有效票券而無需透露身份細(xì)節(jié)。
此外，還能用于基于身份的Telegram 群組驗(yàn)證，確保只有符合條件的成員可以加入特定群組。

Frog Crypto

Frog Crypto 是一個(gè)基于ZuPass 的有趣應(yīng)用，讓參與者在展場(chǎng)中搜集各種類型的青蛙，并生成證明來展示自己擁有的青蛙。其特色在于

資料自主權(quán)：參加者完全掌握自己的青蛙數(shù)據(jù)。
互操作性：開發(fā)者可以基于使用者擁有的青蛙資料創(chuàng)建新應(yīng)用，例如允許使用者將兩只青蛙合成為新的青蛙。這與傳統(tǒng)Web2 生態(tài)的封閉API 截然不同，使用者和開發(fā)者不再受限于中心化平臺(tái)的規(guī)則與改動(dòng)。

Meerkat

Meerkat是促進(jìn)講者與聽眾互動(dòng)的ZApp，結(jié)合了Slido 問答功能與ZK 技術(shù)，實(shí)現(xiàn)匿名互動(dòng)。其功能包括：

即時(shí)發(fā)起問答或投票，講者和聽眾能在保護(hù)隱私的同時(shí)提升互動(dòng)性。
使用者可透過ZuPass 登入并生成互動(dòng)所需的證明，而無需暴露個(gè)人資訊。

ZuPass 的整合方式

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

用戶授權(quán)：應(yīng)用整合ZuPass 后，會(huì)跳出ZuPass 彈窗供使用者登入并選擇授權(quán)哪些資料的讀寫權(quán)限。
資料請(qǐng)求與驗(yàn)證：授權(quán)后，應(yīng)用可向ZuPass 請(qǐng)求特定資料的證明，或?qū)?yīng)用程式中記錄的數(shù)據(jù)進(jìn)行讀寫操作。

POD 與GPC 技術(shù)

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

POD 是一種以密碼學(xué)為核心的數(shù)據(jù)格式，專為零知識(shí)證明設(shè)計(jì)。 GPC 則是一種模組化電路，能根據(jù)POD 的結(jié)構(gòu)生成靈活且高效的ZK 證明。

POD 的設(shè)計(jì)與技術(shù)基礎(chǔ)

Merkle Tree 結(jié)構(gòu)：每個(gè)POD 都是一個(gè)扁平的key-value 鍵值對(duì)結(jié)構(gòu)，透過Merkle Tree 壓縮成一個(gè)唯一的Content ID，用于標(biāo)識(shí)數(shù)據(jù)的完整性與來源。
簽名與驗(yàn)證：POD 的Content ID 由發(fā)行者使用ECDSA 簽名。
零知識(shí)證明友好性：采用ZK-friendly 的Poseidon Hash 函數(shù)與模組化數(shù)據(jù)格式，以加速生產(chǎn)POD 的零知識(shí)證明

GPC 的模組化電路設(shè)計(jì)

GPC 是針對(duì)POD 設(shè)計(jì)的通用電路，只需單一電路即可產(chǎn)生基于POD 靈活的零知識(shí)證明。其設(shè)計(jì)基于模組化架構(gòu)，包含：

Object Module：驗(yàn)證POD 的Content ID 與簽名的一致性。
Entry Module：檢查POD 內(nèi)容的Merkle Proof。
Numeric Value Module：進(jìn)行數(shù)值比較與范圍檢查。
Membership Module：驗(yàn)證欄位是否在指定列表中。

POD 的不足與挑戰(zhàn)

盡管POD 系統(tǒng)具有靈活性與隱私保護(hù)能力，但其仍存在以下限制：

單用戶技術(shù)（Single Player Technology）：POD 的設(shè)計(jì)限制了其只能由用戶本人生成與證明，無法支持隱私保護(hù)的多用戶協(xié)作運(yùn)算。
無法遞回證明：POD 生成的證明僅能被驗(yàn)證，而不能用于生成基于該證明的進(jìn)一步證明，限制了其應(yīng)用深度。
與現(xiàn)有系統(tǒng)不兼容：資料生產(chǎn)方需要調(diào)整系統(tǒng)來生成具簽名的POD，無法直接應(yīng)用于現(xiàn)有的Web2 資料。

POD 2 的誕生與改進(jìn)

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

支援多用戶隱私協(xié)作：POD 2 引入了多方計(jì)算（Multi-Party Computation, MPC），允許多方基于隱私POD 數(shù)據(jù)進(jìn)行聯(lián)合運(yùn)算并生成新POD。例如，兩位用戶可共同計(jì)算某條件是否成立，而無需泄露各自的數(shù)據(jù)細(xì)節(jié)。
遞回證明與計(jì)算：POD 2 的證明支持遞回計(jì)算，允許生成基于現(xiàn)有證明的新證明，構(gòu)建深度計(jì)算圖。

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

POD 2 的技術(shù)挑戰(zhàn)在于，需依賴于多方全同態(tài)加密（Multi-Party Fully Homomorphic Encryption, MP-FHE）實(shí)現(xiàn)多個(gè)POD 2 之間的共同隱私運(yùn)算。

PEX 語言

0xPARC 也發(fā)明了類似Lisp 的PEX 語言，用于描述POD 2 的數(shù)據(jù)結(jié)構(gòu)與條件：

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

提供簡潔且直觀的語法，使開發(fā)者能快速建立基于POD 的應(yīng)用。

Frog Zone 游戲

Frog Zone 是0xPARC 在Devcon 展示的技術(shù)游戲，旨在實(shí)踐最尖端密碼學(xué)應(yīng)用，展示全同態(tài)加密（Fully Homomorphic Encryption, FHE）和多方計(jì)算（Multi-Party Computation, MPC）技術(shù)如何結(jié)合，創(chuàng)造出具隱私保護(hù)和分布式特性的應(yīng)用環(huán)境。這款游戲作為首個(gè)多用戶MP-FHE 應(yīng)用，為分布式隱私計(jì)算和應(yīng)用開發(fā)提供了重要的技術(shù)示范。

游戲玩法

玩家數(shù)量：最多支持4 位玩家同時(shí)參與。
可見范圍：每名玩家只能觀察自己周圍5x5 方格內(nèi)的地圖，一開始玩家互相看不見。
地圖大小：32x32 格子，其中包含怪物、地形障礙以及裝備等互動(dòng)元素。
玩家可選擇移動(dòng)、攻擊怪物或撿取裝備，提升自己的攻擊力與防御力。
游戲中的怪物會(huì)隨機(jī)移動(dòng)，增加挑戰(zhàn)性和游戲趣味性。
玩家需在探索地圖的同時(shí)攻擊怪物，以爭(zhēng)取獲得最高分?jǐn)?shù)。

技術(shù)核心：Multi-Party Fully Homomorphic Encryption

FHE 是一種允許在加密數(shù)據(jù)上直接進(jìn)行計(jì)算的密碼學(xué)技術(shù)。運(yùn)算結(jié)果仍保持加密狀態(tài)，只有持有解密密鑰的一方可以獲取結(jié)果。核心特性是「可計(jì)算性與隱私性共存」。
將FHE 與MPC 結(jié)合可以將FHE 的能力擴(kuò)展到多方環(huán)境，使多名參與者可以在共享的加密狀態(tài)上進(jìn)行協(xié)作計(jì)算。在Frog Zone 游戲中，每名參與者持有部分加密狀態(tài)的分片，并通過MPC 協(xié)議協(xié)同完成伺服器功能的模擬。
整個(gè)游戲的狀態(tài)是由四臺(tái)使用者的機(jī)器，加上五臺(tái)在AWS 云端的機(jī)器共同維護(hù)與計(jì)算，沒有任何一臺(tái)機(jī)器能解密出完整的游戲狀態(tài)。由于是九臺(tái)機(jī)器一起運(yùn)算游戲狀態(tài)，就像產(chǎn)生了共同的「幻覺」，也因此這個(gè)運(yùn)算過程被稱為Hallucinated Server
每次玩家發(fā)出移動(dòng)或攻擊指令時(shí)，該指令以加密形式發(fā)送至伺服器。伺服器在加密環(huán)境中執(zhí)行狀態(tài)轉(zhuǎn)換函數(shù)，生成新的加密游戲狀態(tài)。
完成操作后玩家請(qǐng)求可見范圍（5x5）的加密數(shù)據(jù)，并通過多方協(xié)作解密獲取結(jié)果。

技術(shù)挑戰(zhàn)與限制

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

未來展望

Frog Zone 展示了利用全同態(tài)加密和多方計(jì)算技術(shù)實(shí)現(xiàn)隱私保護(hù)和去中心化應(yīng)用的可能性。雖然當(dāng)前技術(shù)仍面臨性能和開發(fā)難度的挑戰(zhàn)，但這就如同1960 年代的電腦，雖然龐大且效率低下，卻是開創(chuàng)現(xiàn)代計(jì)算時(shí)代的起點(diǎn)。 Frog Zone 的意義在于，它象征了Programmable Cryptography 的雛形，為未來理想化的網(wǎng)際網(wǎng)路鋪平了道路。

隨著Programmable Cryptography 技術(shù)的發(fā)展，未來的網(wǎng)際網(wǎng)路將實(shí)現(xiàn)去中心化、自主性和隱私保護(hù)的目標(biāo)，建立一個(gè)真正屬于用戶的數(shù)位世界。這個(gè)世界將帶來更安全、透明且自由的數(shù)位生活，每個(gè)人都將能完全掌控自己的資產(chǎn)、資料與身份。

聲明：文章內(nèi)容不代表本站觀點(diǎn)及立場(chǎng)，不構(gòu)成本平臺(tái)任何投資建議。本文內(nèi)容僅供參考，風(fēng)險(xiǎn)自擔(dān)！

Tag：以太坊 DevCon 技術(shù)

你可能感興趣的文章

幣圈快訊

數(shù)據(jù)：過去24小時(shí)全網(wǎng)爆倉2.09億美元，多單爆倉9329.77萬，空單爆倉1.16億
2025-06-14 16:00
ChainCatcher消息，據(jù)Coinglass數(shù)據(jù)，過去24小時(shí)全網(wǎng)爆倉2.09億美元，多單爆倉9329.77萬，空單爆倉1.16億。其中比特幣多單爆倉1972.19萬美元，比特幣空單爆倉3474.05萬美元，以太坊多單爆倉3787.32萬美元，以太坊空單爆倉3634.63萬美元。此外，最近24小時(shí)，全球共有64525人被爆倉，最大單筆爆倉單發(fā)生在Binance-BTCUSDT價(jià)值626.44萬美元。
彭博分析師：七家SolanaETF發(fā)行方已全部提交納入質(zhì)押內(nèi)容的S-1更新文件
2025-06-14 15:43
金色財(cái)經(jīng)報(bào)道，彭博分析師JamesSeyffart在X平臺(tái)發(fā)文表示，美國證券交易委員會(huì)已聯(lián)系交易所交易基金發(fā)行方，要求他們提交SolanaETF的申請(qǐng)更新文件，并在其中納入質(zhì)押內(nèi)容。截至目前，七家有望發(fā)行SolanaETF的發(fā)行方已經(jīng)全部提交了S-1更新文件，分別是：VanEckSolanaETF、FidelitySolanaFund、21SharesCoreSolanaETF、FranklinSolanaTrust、GrayscaleSolanaTrust、BitwiseSolanaETF和CanaryMarinadeSolanaETF。
某鯨魚將2248.4萬枚HAEDAL轉(zhuǎn)入幣安，價(jià)值233萬美元
2025-06-14 15:31
金色財(cái)經(jīng)報(bào)道，據(jù)Arkham監(jiān)測(cè)數(shù)據(jù)顯示，大約五分鐘前，某鯨魚將2248.4萬枚HAEDAL轉(zhuǎn)入幣安，價(jià)值233萬美元，若出售將獲利231萬美元，投資回報(bào)率達(dá)到99%，目前該鯨魚錢包內(nèi)還持有約2248萬枚HAEDAL。此外，該鯨魚于2分鐘前還將23750枚HUMA轉(zhuǎn)入幣安，價(jià)值近100萬美元。
幣安Alpha空投規(guī)則變動(dòng)：分2階段發(fā)放，第二階段門檻降低
2025-06-14 15:26
ChainCatcher消息，幣安在X上發(fā)文表示，自2025年6月19日起，幣安Alpha空投將分兩階段發(fā)放：第一階段：分?jǐn)?shù)達(dá)標(biāo)（X）用戶可優(yōu)先領(lǐng)取，人人有份；第二階段：門檻降至Y（Y
BTC跌破105000美元
2025-06-14 15:10
金色財(cái)經(jīng)報(bào)道，行情顯示，BTC跌破105000美元，現(xiàn)報(bào)104986.94美元，24小時(shí)漲幅達(dá)到0.57%，行情波動(dòng)較大，請(qǐng)做好風(fēng)險(xiǎn)控制。

欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

以太坊Devcon大會(huì)精選！十大關(guān)鍵技術(shù)全解析，將徹底改變Web3？

目錄

Part 1: Infrastructure

坎昆升級(jí)大幅降低L2 手續(xù)費(fèi)

Client Diversity 的成功實(shí)踐

交易確認(rèn)效率顯著提升

L2 的信任假設(shè)與分級(jí)安全模型

目前的L2 發(fā)展現(xiàn)狀與挑戰(zhàn)

Escape Hatch：L2 安全性的核心機(jī)制

L1 的擴(kuò)容需求與去中心化的堅(jiān)守

未來：以太坊的進(jìn)化方向與長期愿景

L2 邁向Stage 2：實(shí)現(xiàn)真正的去中心化

降低驗(yàn)證門檻：讓更多人參與以太坊網(wǎng)路

執(zhí)行層的持續(xù)擴(kuò)容：TPS 邁向十萬級(jí)別

共識(shí)層的革命性變革：Beam Chain

極度嚴(yán)謹(jǐn)?shù)墓こ叹衽c長期路線圖

Part 2: Usability

Smart Wallet (ERC-4337)

Passkey 簽章的技術(shù)挑戰(zhàn)

Passkey 錢包的共同挑戰(zhàn)

其他錢包驗(yàn)證與恢復(fù)機(jī)制：ZK Email 的創(chuàng)新

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

Smart Wallet (EIP-7702)

EIP-7702 的應(yīng)用案例

EIP-7702 的技術(shù)流程

安全挑戰(zhàn)與潛在風(fēng)險(xiǎn)

跨鏈?zhǔn)跈?quán)的安全考量

EIP-7702 與ERC-4337 的互補(bǔ)性

Smart Session

DApp 與Smart Wallet 的兼容挑戰(zhàn)

Smart Session 的概念與理想體驗(yàn)

安全風(fēng)險(xiǎn)與解決方案

Intent Centric Design

ERC-7683：跨鏈意圖的標(biāo)準(zhǔn)化實(shí)現(xiàn)

靈活性與挑戰(zhàn)

ERC-7683 與EIP-7702 的結(jié)合應(yīng)用

CoW Swap 的Intent 解決方案

技術(shù)實(shí)現(xiàn)原理

Chain Abstraction

Biconomy Modular Execution Environment

其他解決方案

Part 3: Dev Tools

Tenderly Virtual Test Net

Simbolik

TrustBytes

Ethereum Indexer

Index Supply 的Shovel

Reth Execution Extension

核心特點(diǎn)與通知機(jī)制

Part 4: Security

開發(fā)環(huán)境安全（Dev Security）

VS Code 信任機(jī)制的潛在風(fēng)險(xiǎn)

防范措施：使用Sandbox 環(huán)境

Github Action Self Hosted Runner 的風(fēng)險(xiǎn)

設(shè)備安全（Device Security）

安全建議

DeFi 安全（DeFi Security）

Part 5: Fuzz Testing

Fuzz Testing 的原理與限制

相關(guān)范例

案例分析：Vesting 合約漏洞

設(shè)計(jì)Invariant：思考不可變條件

使用Chimera 框架進(jìn)行測(cè)試

Fuzz Testing for ZK Infrastructure

基于黑箱測(cè)試的隨機(jī)變換與不變性檢測(cè)

持續(xù)且多元測(cè)試

Part 6: Formal Verification

Certora

進(jìn)階功能：驗(yàn)證不變性（Inductive Invariants）

Part 7: Maximal Extractable Value (MEV)

CoW Swap 的MEV 解決方案

Coincidence of Wants（需求的巧合）

Batch Auction（批次拍賣）

Unichain 的MEV 解決方案

Unichain 解決MEV 的關(guān)鍵流程：

Part 8: Zero Knowledge Proof (ZKP)

ZKPassport

技術(shù)特點(diǎn)

應(yīng)用場(chǎng)景

以太坊Devcon大會(huì)精選！十大關(guān)鍵技術(shù)全解析，將徹底改變Web3？

以太坊和Solana哪家ZK技術(shù)更強(qiáng)？哪家更值得投資？

以太坊 VS Solana，哪家ZK技術(shù)更強(qiáng)？

技術(shù)科普：以太坊質(zhì)押是什么意思？以太坊質(zhì)押全面介紹

以太坊區(qū)塊鏈中文瀏覽器讓你輕松掌握區(qū)塊鏈技術(shù)