2024-12-01 12:05:54 | 來(lái)源： | 作者：佚名

本文總結(jié)Devcon 7 的學(xué)習(xí)心得，涵蓋以太坊基礎(chǔ)設(shè)施、易用性、開(kāi)發(fā)工具、安全性與ZKP 等技術(shù)主題

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

• Infrastructure：以太坊一切的基礎(chǔ)
• Usability：如何提升錢(qián)包與DApp 的易用性
• Dev Tools：開(kāi)發(fā)流程中可使用的工具
• Security：個(gè)人與協(xié)議如何保護(hù)自己的安全
• Fuzz Testing：如何快速發(fā)現(xiàn)智能合約的深層問(wèn)題
• Formal Verification：透過(guò)數(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í)，還能遇到志同道合的專(zhuān)家進(jìn)行交流。例如在一場(chǎng)關(guān)于zkTLS 的活動(dòng)中，我有機(jī)會(huì)直接向項(xiàng)目方請(qǐng)教文件中不太理解的部分，這段經(jīng)歷讓我印象深刻。未來(lái)若有類(lèi)似的大型研討會(huì)，我也強(qiáng)烈建議大家多參加與自己興趣相符的side events。

以下正文開(kāi)始。

Part 1: Infrastructure

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

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

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

今年的坎昆升級(jí)帶來(lái)了前所未有的成本優(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，每套程式的開(kāi)發(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ā)生重大問(wèn)題時(shí)，Client Diversity 幫助以太坊維持了整條鏈的穩(wěn)定運(yùn)行。
• 理想狀況：最理想的分布是所有Client 各自占比低于1/3，這樣即便某個(gè)Client 出現(xiàn)問(wèn)題，也不會(huì)影響區(qū)塊的最終確認(rèn)（Finalization）。

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

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

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

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

自2020 年Vitalik 確立了以太坊的Rollup Centric 擴(kuò)容路線圖以來(lái)，整個(gè)生態(tài)系已經(jīng)誕生了數(shù)百條L2 鏈。在這一架構(gòu)下，L1 作為基礎(chǔ)設(shè)施的角色，提供高度穩(wěn)定、安全且可信中立的保障，而L2 則像GPU 一樣，針對(duì)特定應(yīng)用進(jìn)行加速，顯著提升每秒交易次數(shù)。然而隨著L2 的快速增長(zhǎng)，也暴露了一些挑戰(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)行，但這意味著資金安全性完全依賴(lài)項(xiàng)目方。這種設(shè)計(jì)類(lèi)似于腳踏車(chē)的輔助輪，主要用于幫助項(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)目方無(wú)法在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)目方完全掌控，幾乎沒(méi)有任何限制。 Stage 1 引入了證明系統(tǒng)與治理機(jī)制，盡管攻擊者可能通過(guò)賄賂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)目方的宣傳往往存在差距。專(zhuān)注于L2 安全分析的網(wǎng)站l2beat提供了最新且詳細(xì)的報(bào)告，幫助用戶了解項(xiàng)目方的真實(shí)安全實(shí)現(xiàn)是否達(dá)標(biāo)。他們的研究深入程式碼層面，揭露了許多項(xiàng)目過(guò)于依賴(lài)行銷(xiāo)術(shù)語(yǔ)而忽視技術(shù)實(shí)現(xiàn)的現(xiàn)象。

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

L2 必須具備一項(xiàng)關(guān)鍵功能，即Escape Hatch（逃生艙）機(jī)制，來(lái)應(yīng)對(duì)項(xiàng)目方的Operator 或Sequencer 停止運(yùn)作時(shí)的突發(fā)情況。這項(xiàng)機(jī)制允許用戶生成自己在L2 上持有資金的證明，并將該證明提交到L1 的治理智能合約以贖回資金。整個(gè)過(guò)程必須在沒(méi)有項(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ì)未來(lái)可能的大量L2 逃生交易，L1 必須持續(xù)擴(kuò)容。然而，Vitalik 多次強(qiáng)調(diào)，在擴(kuò)容過(guò)程中，不能為了短期內(nèi)的大幅擴(kuò)容而妥協(xié)去中心化。一旦去中心化特性被犧牲，將難以挽回。這種堅(jiān)守是以太坊作為可信中立基礎(chǔ)設(shè)施的核心價(jià)值。

未來(lái)：以太坊的進(jìn)化方向與長(zhǎng)期愿景

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

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

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

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

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

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

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

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

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

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

以太坊的共識(shí)層將迎來(lái)一項(xiàng)重大改變，即Beam Chain的引入。這是Justin 提出的對(duì)現(xiàn)有Beacon Chain 的全面重寫(xiě)，旨在解決當(dāng)前最棘手的問(wèn)題，并邁向以太坊的終極目標(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)。通過(guò)結(jié)合ZK 技術(shù)和簽章聚合（Signature Aggregation），驗(yàn)證者能快速驗(yàn)證數(shù)萬(wàn)個(gè)其他驗(yàn)證者的簽章，在四秒內(nèi)處理完一個(gè)Block。然而，現(xiàn)有的BLS 簽章基于橢圓曲線密碼學(xué)，也需進(jìn)行抗量子攻擊的改寫(xiě)，才能滿足未來(lái)需求。

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

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

Beam Chain 的引入需要對(duì)核心程式碼進(jìn)行全面重寫(xiě)，不僅能解決現(xiàn)有技術(shù)債，還能從過(guò)去的經(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í)間表過(guò)于冗長(zhǎng)，期待能加速進(jìn)度。 Justin 表示，這其中的確存在優(yōu)化空間，他也希望更多人參與討論與實(shí)作，共同推動(dòng)這一計(jì)劃的實(shí)現(xiàn)。

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

Part 2: Usability

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

Smart Wallet (ERC-4337)

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

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

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

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

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

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

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

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

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

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

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

ERC-4337 的互操作性問(wèn)題與解決方法

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

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

為了解決這一問(wèn)題，業(yè)界提出了模組化合約錢(qián)包標(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ì)允許所有錢(qián)包應(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)建新的智能合約錢(qián)包，無(wú)法延續(xù)過(guò)去的EOA（Externally Owned Account）。 EIP-7702 則提供了一個(gè)全新解法，允許任何EOA 地址「升級(jí)」為智能合約錢(qián)包，帶來(lái)多樣化的靈活功能：

• 批次執(zhí)行交易：將DeFi 操作中的多次簽名（如Approve + Swap）簡(jiǎn)化為一次簽名即可完成。
• Gas 贊助：EOA 不必持有ETH，也可以透過(guò)其他地址代為支付交易所需的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 可透過(guò)單一Passkey 簽章執(zhí)行多筆交易，進(jìn)一步提升使用者的便利性。

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

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

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

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

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

• 授權(quán)惡意合約的風(fēng)險(xiǎn)：如果使用者不小心簽署了一個(gè)惡意EIP-7702 簽章，攻擊者可借助合約邏輯批次轉(zhuǎn)移使用者的所有資產(chǎn)，包括Token、NFT 和DeFi 倉(cāng)位。相比現(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 不同，簽章將無(wú)效。這一設(shè)計(jì)可以讓錢(qián)包App 通過(guò)一個(gè)簽章升級(jí)用戶的地址至所有鏈上的合約錢(qián)包，提升便利性。然而開(kāi)發(fā)者在設(shè)計(jì)時(shí)需謹(jǐn)慎處理nonce 機(jī)制，避免出現(xiàn)不必要的安全漏洞。

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

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

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

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

Smart Session

雖然智能錢(qián)包（Smart Wallet）帶來(lái)了許多創(chuàng)新，但它們的出現(xiàn)并不代表DApp 的使用體驗(yàn)會(huì)自動(dòng)變好。錢(qián)包與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ā)送交易通常是通過(guò)簡(jiǎn)單的eth_sendTransaction 介面向錢(qián)包發(fā)送請(qǐng)求。然而，Smart Wallet（如基于ERC-4337 的智能合約錢(qián)包）需要一種全新的操作模式。 ERC-4337 引入了User Operation的結(jié)構(gòu)作為核心元件，但問(wèn)題在于許多現(xiàn)有DApp 并不知道如何生成User Operation 的資訊。這導(dǎo)致Smart Wallet 與當(dāng)前DApp 生態(tài)的兼容性大打折扣。

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

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

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

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

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

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

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

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

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

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)逐漸分散到不同鏈上。這種分散性帶來(lái)了跨鏈操作的復(fù)雜性，不僅速度慢，體驗(yàn)也相當(dāng)不友好。在應(yīng)用層面，越來(lái)越多的協(xié)議開(kāi)始采用Intent Centric Design（意圖導(dǎo)向設(shè)計(jì)）來(lái)解決這些問(wèn)題。這種設(shè)計(jì)理念的核心在于，用戶只需表達(dá)自己的目標(biāo)意圖（Intent），而不需要關(guān)心具體實(shí)現(xiàn)方式，將操作的復(fù)雜性·交由Solver（解決者）處理。從過(guò)去的「自行開(kāi)車(chē)到目的地」到如今「叫Uber 即可」，這正是Intent Centric Design 帶來(lái)的使用體驗(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)求，支援以下常見(jiàn)場(chǎng)景：

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

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

ERC-7683 的操作流程如下：

• 記錄意圖：使用者在A 鏈將資產(chǎn)存入ERC-7683 合約，并記錄其操作意圖（Intent）。
• Solver 鎖定意圖： Solver 監(jiān)聽(tīng)I(yíng)ntent，判斷是否符合其能力與利潤(rùn)需求，然后在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ù)某杀?，無(wú)需每筆交易都傳送一個(gè)跨鏈的訊息。

靈活性與挑戰(zhàn)

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

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

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

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

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

CoW Swap 的Intent 解決方案

CoW Swap 在單鏈場(chǎng)景中推動(dòng)了Intent 的應(yīng)用，專(zhuān)注于優(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)行交易的成本，帶來(lái)理論上的最佳價(jià)格。

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

• 流動(dòng)性獲取：必須快速?gòu)亩鄠€(gè)DEX、中心化交易所（CEX）及跨鏈資源中獲取流動(dòng)性。
• 演算法優(yōu)化：如何快速聚合并計(jì)算最優(yōu)交易路徑仍是未解的最佳化問(wèn)題。
• 精準(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 操作帶來(lái)了更高效的方式。該設(shè)計(jì)允許使用者在source chain上將USDC 發(fā)送到一個(gè)指定地址，通過(guò)relayer在destination chain執(zhí)行后續(xù)操作，例如將USDC 跨鏈后進(jìn)行特定的DeFi 操作。整個(gè)過(guò)程完全去中心化，適用于跨鏈支付、一鍵投資等場(chǎng)景。

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

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

• CCTP 的目標(biāo)地址指定：在使用Circle 的CCTP 跨鏈橋時(shí)，用戶可以指定目標(biāo)鏈上的接收地址。如果該地址是一個(gè)智能合約，relayer 就能在接收USDC 前執(zhí)行合約中定義的操作。執(zhí)行完成后，relayer 再通過(guò)CCTP 獲取跨鏈的USDC 作為報(bào)酬。這種機(jī)制使得relayer 能在資金到達(dá)前完成用戶的Intent，大幅提升交易速度與用戶體驗(yàn)。
• CREATE2 的地址預(yù)計(jì)算：在source chain 上，使用者需要事先確定目標(biāo)鏈上的Intent 合約地址。這可以通過(guò)CREATE2機(jī)制實(shí)現(xiàn)：CREATE2 允許在合約未部署時(shí)就計(jì)算其未來(lái)地址，只需提供合約的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 更簡(jiǎn)單，但需要在交易過(guò)程中部署合約，導(dǎo)致增加一些gas 費(fèi)用。不過(guò)，由于部署的合約只是小型的proxy contract，指向預(yù)先部署好的implementation contract，因此額外成本相對(duì)有限。

Chain Abstraction

Chain Abstraction的核心理念是隱藏區(qū)塊鏈的存在，讓使用者專(zhuān)注于資產(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)解決方案，專(zhuān)為支持Chain Abstraction 而設(shè)計(jì)。這個(gè)系統(tǒng)允許ERC-4337 錢(qián)包的開(kāi)發(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簽章，然后透過(guò)Modular Execution Environment 自動(dòng)將這些操作上鏈執(zhí)行。

其他解決方案

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

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

Part 3: Dev Tools

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

Tenderly Virtual Test Net

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

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

Simbolik

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

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

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

TrustBytes

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

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

TrustBytes 通過(guò)縮短代碼追蹤的時(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 獲取資料效率低下，因此需要透過(guò)Indexer 將資料提取并存儲(chǔ)到高效的資料庫(kù)中。以下是兩個(gè)值得關(guān)注的解決方案。

Index Supply 的Shovel

Shovel 是一款開(kāi)源工具，允許開(kāi)發(fā)者透過(guò)簡(jiǎn)單的config 檔，將鏈上資料轉(zhuǎn)化為指定格式并儲(chǔ)存到PostgreSQL DB。例如，紀(jì)錄一個(gè)錢(qián)包的歷史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"}
      ]
    }
  }

透過(guò)簡(jiǎn)單的配置，Shovel 能快速完成資料的提取與存儲(chǔ)，大幅降低開(kāi)發(fā)成本。

Reth Execution Extension

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

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

Reth 的創(chuàng)新之處在于其設(shè)計(jì)為可直接作為library import，開(kāi)發(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

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

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

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

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

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

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

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

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

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

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

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

• 惡意用戶可以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ù)期中那么安全。主要問(wèn)題在于：

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

安全建議

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

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

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

DeFi 安全（DeFi Security）

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

• 交易簽名驗(yàn)證：DeFi 合約需要為合約中的關(guān)鍵方法加上Forta 的簽章參數(shù)
• 交易模擬與風(fēng)險(xiǎn)評(píng)估：Forta 的RPC 節(jié)點(diǎn)將模擬交易執(zhí)行過(guò)程，通過(guò)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ù)低于門(mén)檻值的交易才會(huì)獲得簽名并被放行。

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

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

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

Part 5: Fuzz Testing

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

Fuzz Testing 的原理與限制

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

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

相關(guān)范例

以下是三個(gè)經(jīng)典例子，說(shuō)明如何使用黑箱的Fuzz Testing 方法來(lái)檢測(cè)系統(tǒng)的正確性：

• 排序演算法測(cè)試：原始輸入：未排序的數(shù)字陣列A。
  隨機(jī)調(diào)整：對(duì)A 隨機(jī)打亂（Shuffle）后再排序，結(jié)果應(yīng)與原始輸入排序結(jié)果相同。
  驗(yàn)證：比較兩次排序的結(jié)果是否一致。
• 最短路徑演算法測(cè)試：原始輸入：圖G 和兩個(gè)節(jié)點(diǎn)n1 與n2。
  隨機(jī)調(diào)整：從圖G 移除某條邊后，n1 到n2 的最短路徑應(yīng)該變長(zhǎng)或保持不變。
  驗(yàn)證：比較移除邊前后的最短路徑。
• 編譯器測(cè)試：原始輸入：程式P。
  隨機(jī)調(diào)整：在P 中加入Dead Code 后編譯，結(jié)果執(zhí)行的行為應(yīng)與原始程式一致。
  驗(yàn)證：比較兩次執(zhí)行結(jié)果。

使用Chimera 撰寫(xiě)Fuzz Test

以下介紹如何使用Chimera框架來(lái)整合多種Fuzzer 工具（如Echidna、Medusa 和Foundry）進(jìn)行智能合約的Fuzz 測(cè)試。

案例分析：Vesting 合約漏洞

以下是一個(gè)簡(jiǎn)化的Vesting智能合約范例，其目的是實(shí)現(xiàn)用戶的積分分配與轉(zhuǎn)移，完整程式碼在solidity-fuzzing-comparison Repo 中的09-vesting 。然而，該合約存在一個(gè)漏洞：用戶可以通過(guò)「自我轉(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í)作，也能透過(guò)對(duì)其黑箱的Fuzzing 來(lái)找到問(wèn)題。

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

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

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

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

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

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

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

2、設(shè)定測(cè)試環(huán)境：建立一個(gè)Setup.sol 文件來(lái)初始化測(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è)試即可通過(guò)了

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è)試中，開(kāi)發(fā)者將處理流程視作不可見(jiàn)的黑箱，僅根據(jù)輸入和輸出進(jìn)行分析。

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

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

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

由于零知識(shí)基礎(chǔ)設(shè)施經(jīng)常被用于Layer 2 協(xié)議，將乘載數(shù)億美金以上的價(jià)值，其安全性至關(guān)重要，因此持續(xù)測(cè)試顯得尤為必要。這可以通過(guò)自動(dòng)化測(cè)試工具來(lái)實(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)的問(wèn)題進(jìn)行改進(jìn)。此外，測(cè)試生成的輸入應(yīng)盡量簡(jiǎn)化，以便開(kāi)發(fā)者快速理解并定位問(wèn)題。

Part 6: Formal Verification

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

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

Certora

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

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

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

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

以下是一個(gè)簡(jiǎn)單的投票合約，完整的程式碼可以在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：撰寫(xiě)規(guī)格

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

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

步驟2：設(shè)定config

使用以下.conf 檔案來(lái)設(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)證

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

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

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

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

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

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

CoW Swap 的MEV 解決方案

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

Coincidence of Wants（需求的巧合）

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

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

Batch Auction（批次拍賣(mài)）

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

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

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

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

實(shí)際案例：

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

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

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

Unichain 的MEV 解決方案

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

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

• 加密交易：使用者在發(fā)送交易時(shí)，首先使用TEE 的公鑰加密交易內(nèi)容。因此，在mempool 中，所有節(jié)點(diǎn)看到的交易都是加密的，無(wú)法直接得知交易的細(xì)節(jié)，自然也就無(wú)法通過(guò)交易排序提取MEV。
• TEE 排序：只有在TEE 環(huán)境內(nèi)才能解密交易并進(jìn)行排序。 TEE 會(huì)根據(jù)預(yù)設(shè)的規(guī)則排序交易并構(gòu)建區(qū)塊，最終生成的排序結(jié)果帶有TEE 的簽章，保證排序過(guò)程的透明度。
• 返還MEV 收益：對(duì)于普通用戶，Unichain 提供接近零成本的Gas 費(fèi)，同時(shí)完全避免了被搶跑（front-run）的風(fēng)險(xiǎn)。而對(duì)于MEV Searcher，他們需要支付更高的Gas 費(fèi)來(lá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)用展示了如何透過(guò)密碼學(xué)方法，實(shí)現(xiàn)隱私保護(hù)與效能的平衡。以下將介紹幾個(gè)令我印象深刻的ZK 應(yīng)用。

ZKPassport

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

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

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

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

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

ZK Email

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

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

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

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

• ZKP2P：透過(guò)點(diǎn)對(duì)點(diǎn)轉(zhuǎn)帳的確認(rèn)信，打造法幣與虛擬貨幣兌換的平臺(tái)，且完全去中心化
• Email Wallet Guardian： Email 可作為智能合約錢(qián)包的備援手段。例如，用戶寄出一封Email 即可恢復(fù)錢(qián)包的控制權(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 是否真正屬于該域名，而這目前只能透過(guò)Oracle 提供資料。需要透過(guò)像Re-staking 的機(jī)制來(lái)確保該資料足夠去中心化，避免單點(diǎn)故障
• 在處理較長(zhǎng)的郵件時(shí)，ZKP 的計(jì)算效能面臨挑戰(zhàn)。團(tuán)隊(duì)正在研究遞回證明（recursive proof）以支援更高效的body hash 驗(yàn)證。
• 未來(lái)可能支援Email 附件（例如PDF）內(nèi)容的證明，進(jìn)一步拓展應(yīng)用場(chǎng)景，如證明銀行的轉(zhuǎn)帳紀(jì)錄
• 手機(jī)用戶體驗(yàn)：由于手機(jī)端無(wú)法像桌面端下載原始郵件，ZK Email 目前僅能透過(guò)OAuth 授權(quán)讀取郵件。雖然這引發(fā)一定的隱私顧慮，但ZK Email 的開(kāi)源性確保了這些操作僅限于客戶端，不會(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é)議來(lái)驗(yàn)證域名的所有權(quán)。賣(mài)家需使用ZKP2P 提供的瀏覽器Extension，從Namecheap 網(wǎng)站生成不可篡改的域名所有權(quán)證明，并提交到智能合約中。
• 交易過(guò)程中的隱私保護(hù)：買(mǎi)家在提交購(gòu)買(mǎi)申請(qǐng)時(shí)，需提供Namecheap 用戶名，該資訊會(huì)加密處理，僅賣(mài)家可見(jiàn)。
• 資金鎖定：買(mǎi)家的ETH 會(huì)先被鎖定在智能合約的托管中，直到賣(mài)家完成域名轉(zhuǎn)讓并提供相關(guān)的零知識(shí)證明后，資金才會(huì)釋放。
• 零知識(shí)證明的使用：賣(mài)家轉(zhuǎn)移域名后會(huì)收到Namecheap 的確認(rèn)信，因此ZKP2P 使用ZK Email 產(chǎn)生這封信的零知識(shí)證明，確保域名已轉(zhuǎn)移給買(mǎi)方。

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

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

Polygon ZisK

Polygon 正在開(kāi)發(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ù)訪問(wèn)。
• Bus（總線）：負(fù)責(zé)連接ZisK 系統(tǒng)內(nèi)部的各模組，協(xié)調(diào)訊息交換。

目前，ZisK 還處于非常早期的開(kāi)發(fā)階段，可參考其開(kāi)發(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 的核心依賴(lài)于TLS Proxy 作為信任中介。過(guò)程中HTTPS 請(qǐng)求和回應(yīng)會(huì)經(jīng)過(guò)TLS Proxy，并由Proxy 簽署該流量的加密內(nèi)容，從而為后續(xù)的證明生成提供基礎(chǔ)。 TLS Proxy 的角色僅限于簽署加密流量，無(wú)法解密任何資料，這也減少了隱私風(fēng)險(xiǎn)。

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

然而盡管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 流量，并公開(kāi)指定區(qū)域的明文資訊。這些操作基于gnark 框架進(jìn)行，確保了高效的證明生成。

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

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

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

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

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

• 信任TLS Proxy：協(xié)議需要用戶信任TLS Proxy，因?yàn)镻roxy 會(huì)簽署HTTPS 流量，成為證明可信來(lái)源的基礎(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 無(wú)法正常運(yùn)作，但這類(lèi)攻擊需要精確的時(shí)間和網(wǎng)路控制，實(shí)現(xiàn)難度極高。

vLayer

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

• Time Travel：允許智能合約使用歷史鏈上資料。
• Teleport：使合約能在多個(gè)EVM 兼容的網(wǎng)絡(luò)上運(yùn)行。
• Web Proofs（zkTLS）：驗(yàn)證并整合網(wǎng)頁(yè)內(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)開(kāi)發(fā)者在其平臺(tái)上進(jìn)行開(kāi)發(fā)，并計(jì)劃于2025 年推出測(cè)試網(wǎng)、主網(wǎng)和代幣。

Mopro

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

• 易用性：簡(jiǎ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)化，開(kāi)發(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)證其聲明是否正確，無(wú)需多方協(xié)作。因此Prover 需要知道所有計(jì)算過(guò)程的資料。 ZK 保障的是Single Player Privacy。

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

World ID

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

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

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

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

World ID 最大的技術(shù)挑戰(zhàn)在于計(jì)算成本高昂：Worldcoin 的使用者數(shù)已超過(guò)1,600 萬(wàn)，每次唯一性驗(yàn)證需要針對(duì)龐大的數(shù)據(jù)庫(kù)進(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 的開(kāi)源框架，旨在實(shí)現(xiàn)多方參與的統(tǒng)計(jì)計(jì)算，同時(shí)保護(hù)數(shù)據(jù)隱私。該框架允許多個(gè)數(shù)據(jù)提供者匿名參與計(jì)算，結(jié)果公開(kāi)但不泄露個(gè)人數(shù)據(jù)細(xì)節(jié)。

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

• 隱私保護(hù)：數(shù)據(jù)提供者的資料以秘密共享的方式進(jìn)行處理，并且在計(jì)算過(guò)程中保持加密。
• 整合TLS Notary：使用TLS Notary 確保輸入數(shù)據(jù)來(lái)自可信來(lái)源，避免「垃圾輸入」影響結(jié)果。
• 支持多種統(tǒng)計(jì)操作：包括平均值、中位數(shù)、吉尼系數(shù)等常見(jiàn)統(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)中無(wú)法向第三方驗(yàn)證計(jì)算正確性的挑戰(zhàn)。該協(xié)議允許計(jì)算方在保護(hù)輸入隱私的同時(shí)，向第三方公開(kāi)驗(yàn)證計(jì)算結(jié)果的正確性。

核心概念與技術(shù)

• 引入Collaborative ZK-SNARKs：PAMPC 使用協(xié)作式ZK-SNARKs，將每個(gè)計(jì)算方生成的部分證明（proof）進(jìn)行線性聚合產(chǎn)生完整證明，確保計(jì)算的正確性可被第三方驗(yàn)證。
• 處理輸入一致性問(wèn)題：在MPC 的預(yù)處理和在線階段中，透過(guò)對(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í)，提供公開(kāi)驗(yàn)證機(jī)制，增強(qiáng)系統(tǒng)透明度同時(shí)保護(hù)隱私。
• 去中心化拍賣(mài)：確保拍賣(mài)結(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）游戲，通過(guò)MPC 確保角色分配、投票計(jì)算的隱私性與正確性，而不需要游戲主持者(GM) 。

Part 10: Programmable Cryptography

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

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

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

• 零知識(shí)證明（zkSNARKs）：證明程式在私密輸入上的正確執(zhí)行，無(wú)需泄露輸入。
• 多方計(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ù)能無(wú)縫流轉(zhuǎn)并保持真實(shí)性與隱私。
• 信任最小化與無(wú)需許可：用數(shù)學(xué)保證取代對(duì)中央機(jī)構(gòu)的信任，任何人均可參與。

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

以下透過(guò)兩個(gè)例子解釋?zhuān)瑸楹斡辛丝沙淌交艽a學(xué)后，能建構(gòu)理想的社交網(wǎng)路與投票應(yīng)用。

去中心化Facebook

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

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

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

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

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

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

Devcon 門(mén)票驗(yàn)證

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

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

Frog Crypto

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

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

Meerkat

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

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

ZuPass 的整合方式

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

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

POD 與GPC 技術(shù)

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

POD 是一種以密碼學(xué)為核心的數(shù)據(jù)格式，專(zhuān)為零知識(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)，透過(guò)Merkle Tree 壓縮成一個(gè)唯一的Content ID，用于標(biāo)識(shí)數(shù)據(jù)的完整性與來(lái)源。
• 簽名與驗(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ì)限制了其只能由用戶本人生成與證明，無(wú)法支持隱私保護(hù)的多用戶協(xié)作運(yùn)算。
• 無(wú)法遞回證明：POD 生成的證明僅能被驗(yàn)證，而不能用于生成基于該證明的進(jìn)一步證明，限制了其應(yīng)用深度。
• 與現(xiàn)有系統(tǒng)不兼容：資料生產(chǎn)方需要調(diào)整系統(tǒng)來(lái)生成具簽名的POD，無(wú)法直接應(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ì)算某條件是否成立，而無(wú)需泄露各自的數(shù)據(jù)細(xì)節(jié)。
• 遞回證明與計(jì)算：POD 2 的證明支持遞回計(jì)算，允許生成基于現(xiàn)有證明的新證明，構(gòu)建深度計(jì)算圖。

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

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

PEX 語(yǔ)言

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

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

提供簡(jiǎn)潔且直觀的語(yǔ)法，使開(kāi)發(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)用開(kāi)發(fā)提供了重要的技術(shù)示范。

游戲玩法

• 玩家數(shù)量：最多支持4 位玩家同時(shí)參與。
• 可見(jiàn)范圍：每名玩家只能觀察自己周?chē)?x5 方格內(nèi)的地圖，一開(kāi)始玩家互相看不見(jiàn)。
• 地圖大?。?2x32 格子，其中包含怪物、地形障礙以及裝備等互動(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)的分片，并通過(guò)MPC 協(xié)議協(xié)同完成伺服器功能的模擬。
• 整個(gè)游戲的狀態(tài)是由四臺(tái)使用者的機(jī)器，加上五臺(tái)在AWS 云端的機(jī)器共同維護(hù)與計(jì)算，沒(méi)有任何一臺(tái)機(jī)器能解密出完整的游戲狀態(tài)。由于是九臺(tái)機(jī)器一起運(yùn)算游戲狀態(tài)，就像產(chǎn)生了共同的「幻覺(jué)」，也因此這個(gè)運(yùn)算過(guò)程被稱(chēng)為Hallucinated Server
• 每次玩家發(fā)出移動(dòng)或攻擊指令時(shí)，該指令以加密形式發(fā)送至伺服器。伺服器在加密環(huán)境中執(zhí)行狀態(tài)轉(zhuǎn)換函數(shù)，生成新的加密游戲狀態(tài)。
• 完成操作后玩家請(qǐng)求可見(jiàn)范圍（5x5）的加密數(shù)據(jù)，并通過(guò)多方協(xié)作解密獲取結(jié)果。

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

• 運(yùn)算成本高昂：每個(gè)二進(jìn)制邏輯門(mé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è)玩家只能每四秒操作一次。
• 開(kāi)發(fā)模式的轉(zhuǎn)變：MP-FHE 僅支持電路模型，而非傳統(tǒng)記憶體模型，開(kāi)發(fā)過(guò)程中需要平行模擬所有可能的操作分支。例如，當(dāng)玩家嘗試移動(dòng)時(shí)，伺服器需同時(shí)計(jì)算所有可能的移動(dòng)結(jié)果并選擇正確的分支。若要使用記憶體模型，需使用Oblivious RAM 以確保隱私地存取記憶體內(nèi)容
• 多方解密的頻寬成本：每次玩家請(qǐng)求5x5 可見(jiàn)范圍內(nèi)容時(shí)，需由四臺(tái)本地客戶端協(xié)同解密，導(dǎo)致解密過(guò)程高度依賴(lài)多方同步，對(duì)網(wǎng)路頻寬要求極高。

未來(lái)展望

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

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

你可能感興趣的文章

• 

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

  我們將探討不同網(wǎng)絡(luò)如何應(yīng)對(duì)這些挑戰(zhàn)，特別是比較以太坊上的 zk Rollups 和 Solana 上的 zk Compression,這兩種技術(shù)都旨在提升可擴(kuò)展性，但它們通過(guò)不同的方式實(shí)現(xiàn)這一目標(biāo)…

  2024-07-02
• 

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

  區(qū)塊鏈技術(shù)的可擴(kuò)展性和效率問(wèn)題得以通過(guò)引入zk Rollups和zk Compression等擴(kuò)展解決方案得到顯著改善,以太坊的zk Rollups技術(shù)和Solana的zk Compression技術(shù)哪個(gè)更強(qiáng)呢？下…

  2025-04-23
• 

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

  持有一定數(shù)量的ETH參與到網(wǎng)絡(luò)活動(dòng)中并獲得回報(bào)叫做以太坊質(zhì)押，那么究竟以太坊質(zhì)押是什么意思？以太坊為什么要實(shí)施PoS？以太坊如何進(jìn)行質(zhì)押？以太坊質(zhì)押挖礦有風(fēng)險(xiǎn)嗎？本文…

  2024-03-26
• 

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

  區(qū)塊鏈技術(shù)是近年來(lái)備受矚目的新興技術(shù)，而以太坊區(qū)塊鏈作為其中的之一，更是備受關(guān)注,但對(duì)于普通人來(lái)說(shuō)，了解和掌握這項(xiàng)技術(shù)并不容易,好在現(xiàn)在有了以太坊區(qū)塊鏈中文瀏覽器…

  2023-08-11
• 

  個(gè)人電腦怎么挖以太坊?以太坊電腦挖礦詳細(xì)圖解教程

  這篇文章主要介紹了個(gè)人電腦怎么挖以太坊?以太坊電腦挖礦詳細(xì)圖解教程，以太坊在幣圈是僅次比特幣的數(shù)字貨幣，以太坊的獲取方式除了直接市面上購(gòu)買(mǎi)之外，就是挖礦獲得，下…

  2021-05-12
• 

  比特幣以太坊哪個(gè)更適合投資?礦工為何要挖礦?

  這篇文章主要介紹了比特幣以太坊哪個(gè)更適合投資?礦工為何要挖礦?本文通過(guò)對(duì)以太坊的意思理解，分析以太坊的行情，并結(jié)合以太坊和比特幣的優(yōu)缺點(diǎn)比較，相信投資者看完內(nèi)容后…

  2021-04-27
• 

  2021最具潛力百倍數(shù)字貨幣DCR幣種前十匯總

  這篇文章主要介紹了2021最具潛力百倍數(shù)字貨幣DCR幣種前十匯總，對(duì)于投資者來(lái)說(shuō)，找到具有潛力的百倍數(shù)字貨幣就非常重要了，那么，2021最具潛力百倍數(shù)字貨幣前十有哪些呢？…

  2021-04-25
• 

  以太坊/ETH永續(xù)合約一般做多少倍杠桿?

  這篇文章主要介紹了以太坊/ETH永續(xù)合約一般做多少倍杠桿?說(shuō)到杠桿有哪些，投資者聽(tīng)的最多的應(yīng)該就是5倍和100倍，其實(shí)除了這兩種之外，還有很多其他倍數(shù)，那么，以太坊/ETH…

  2021-04-09
• 

  以太坊是什么？以太坊開(kāi)發(fā)入門(mén)指南

  這篇文章主要介紹了以太坊是什么？以太坊開(kāi)發(fā)入門(mén)指南，很多同學(xué)已經(jīng)躍躍欲試投入到區(qū)塊鏈開(kāi)發(fā)隊(duì)伍當(dāng)中來(lái)，可是又感覺(jué)無(wú)從下手，本文將基于以太坊平臺(tái)，以通俗的方式介紹以…

  2021-03-31
• 

  以太坊(ETH)測(cè)試網(wǎng)絡(luò)郵費(fèi)Rinkeby網(wǎng)絡(luò)領(lǐng)取教程

  這篇文章主要介紹了以太坊(ETH)測(cè)試網(wǎng)絡(luò)郵費(fèi)Rinkeby網(wǎng)絡(luò)領(lǐng)取教程，ETH上測(cè)試教程比較多，很多測(cè)試活動(dòng)一個(gè)郵費(fèi)門(mén)檻把很多人拒絕在門(mén)外。這里小編整理了些領(lǐng)取渠道，讓大家…

  2021-03-30