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

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

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

以下正文開始。

Part 1: Infrastructure

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

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

坎昆升級大幅降低L2 手續(xù)費

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

Client Diversity 的成功實踐

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

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

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

交易確認效率顯著提升

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

極度嚴謹?shù)墓こ叹衽c長期路線圖

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

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

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

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

Part 2: Usability

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

Smart Wallet (ERC-4337)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Smart Wallet (EIP-7702)

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

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

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

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

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

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

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

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

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

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

跨鏈授權(quán)的安全考量

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

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

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

EIP-7702 與ERC-4337 的互補性

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

Smart Session

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

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

在傳統(tǒng)的EOA 設(shè)計中，DApp 發(fā)送交易通常是通過簡單的eth_sendTransaction 介面向錢包發(fā)送請求。然而，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 確認錢包支持哪些Smart Account 的功能。
ERC-7677：指導(dǎo)DApp 如何生成User Operation 中的paymasterAndData 欄位。
ERC-7679：提供生成完整User Operation 的規(guī)范。

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

Smart Session 的概念與理想體驗

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

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

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

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

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

Passkey 是實現(xiàn)Session Key 安全存儲與簽名的良好選擇，因為它能大幅降低泄漏風(fēng)險。同時，Session Key 的設(shè)計應(yīng)保證丟失后對用戶的影響最小，用戶只需重新授權(quán)即可恢復(fù)使用。

Intent Centric Design

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

ERC-7683：跨鏈意圖的標準化實現(xiàn)

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

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

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

ERC-7683 的操作流程如下：

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

使用者支付的手續(xù)費基本等同于一小時的借貸利息。這種模式比傳統(tǒng)基于訊息的跨鏈協(xié)議效率更高，因為其采用了批次結(jié)算方式，減少了跨鏈訊息傳輸?shù)某杀?，無需每筆交易都傳送一個跨鏈的訊息。

靈活性與挑戰(zhàn)

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

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

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

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

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

CoW Swap 的Intent 解決方案

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

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

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

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

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

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

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

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

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

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

Chain Abstraction

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

Biconomy Modular Execution Environment

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

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

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

其他解決方案

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

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

Part 3: Dev Tools

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

Tenderly Virtual Test Net

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

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

Simbolik

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

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

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

TrustBytes

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

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

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

Ethereum Indexer

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

Index Supply 的Shovel

Shovel 是一款開源工具，允許開發(fā)者透過簡單的config 檔，將鏈上資料轉(zhuǎn)化為指定格式并儲存到PostgreSQL DB。例如，紀錄一個錢包的歷史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 能快速完成資料的提取與存儲，大幅降低開發(fā)成本。

Reth Execution Extension

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

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

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

核心特點與通知機制

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

ChainCommitted：新區(qū)塊被確認（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è)備與用戶端的保護，再到DeFi 合約層面的防御，都需要嚴密的措施來降低風(fēng)險。以下針對開發(fā)、設(shè)備與DeFi 安全三大主題進行探討。

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

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

VS Code 信任機制的潛在風(fēng)險

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

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

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

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

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

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

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

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

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

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

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

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

安全建議

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

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

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

DeFi 安全（DeFi Security）

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

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

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

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

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

Part 5: Fuzz Testing

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

Fuzz Testing 的原理與限制

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

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

案例分析：Vesting 合約漏洞

以下是一個簡化的Vesting智能合約范例，其目的是實現(xiàn)用戶的積分分配與轉(zhuǎn)移，完整程式碼在solidity-fuzzing-comparison Repo 中的09-vesting 。然而，該合約存在一個漏洞：用戶可以通過「自我轉(zhuǎ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)等于總分數(shù)」的Invariant。然而就算我們不細看transferPoints的實作，也能透過對其黑箱的Fuzzing 來找到問題。

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

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

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

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

使用Chimera 框架進行測試

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

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

2、設(shè)定測試環(huán)境：建立一個Setup.sol 文件來初始化測試合約，并追蹤需要檢查的狀態(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、實現(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、定義如何測試目標函數(shù)：指定transferPoints 參數(shù)需滿足的條件，避免因錯誤參數(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 在短時間內(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í)行一次測試即可通過了

Fuzz Testing for ZK Infrastructure

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

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

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

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

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

持續(xù)且多元測試

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

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

Part 6: Formal Verification

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

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

Certora

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

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

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

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

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

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

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

步驟1：撰寫規(guī)格

以下是一個簡單的規(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è)定驗證細節(jié)，包括要驗證的合約與規(guī)范檔案。

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

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

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

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

如果還沒有API Key，可以在官方網(wǎng)站注冊取得。輸出中會有一個Certora Prover 結(jié)果的連結(jié)，點進去即可看到Prover 找到了一個錯誤，并提供詳細的輸入?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：重新驗證

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

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

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

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

此規(guī)則驗證totalVotes 永遠等于贊成與反對票數(shù)的總和。

Part 7: Maximal Extractable Value (MEV)

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

CoW Swap 的MEV 解決方案

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

Coincidence of Wants（需求的巧合）

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

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

Batch Auction（批次拍賣）

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

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

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

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

實際案例：

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

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

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

Unichain 的MEV 解決方案

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

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

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

Part 8: Zero Knowledge Proof (ZKP)

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

ZKPassport

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

技術(shù)特點

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

應(yīng)用場景

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

ZK Email

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

技術(shù)特點

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

應(yīng)用場景

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

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

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

ZKP2P

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

域名交易的核心機制

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

技術(shù)特點與優(yōu)勢

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

Polygon ZisK

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

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

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

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

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

Reclaim Protocol

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

TLS Proxy 機制

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

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

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

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

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

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

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

應(yīng)用場景

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

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

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

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

vLayer

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

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

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

Mopro

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

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

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

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

Part 9: Multi-Party Computation (MPC)

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

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

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

World ID

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

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

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

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

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

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

MPCStats

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

技術(shù)特點

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

展場Demo

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

Public Auditable MPC

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

核心概念與技術(shù)

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

應(yīng)用場景與優(yōu)勢

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

Part 10: Programmable Cryptography

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

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

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

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

最理想的Internet

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

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

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

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

去中心化Facebook

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

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

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

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

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

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

ZuPass

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

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

Devcon 門票驗證

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

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

Frog Crypto

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

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

Meerkat

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

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

ZuPass 的整合方式

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

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

POD 與GPC 技術(shù)

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

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

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

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

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

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

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

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

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

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

POD 2 的誕生與改進

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

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

并且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)生互通性，實現(xiàn)不同系統(tǒng)間的無縫整合。最大的好處在于完全不需修改既有Web2 系統(tǒng)的資料產(chǎn)生邏輯。

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

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

游戲玩法

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

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

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

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

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

未來展望

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

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

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

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

你可能感興趣的文章

幣圈快訊

美SEC發(fā)布證券代幣化聲明
2025-07-10 01:02
ChainCatcher消息，據(jù)美SEC發(fā)布關(guān)于證券代幣化聲明，表示區(qū)塊鏈技術(shù)為以「代幣化」形式發(fā)行和交易證券開辟了新的模式。代幣化有可能促進資本形成，并提升投資者將其資產(chǎn)用作抵押品的能力。受這些可能性的吸引，越來越多的新興參與者和傳統(tǒng)機構(gòu)正在積極擁抱鏈上產(chǎn)品。然而，盡管區(qū)塊鏈技術(shù)極具潛力，它并不具備「魔法」來改變基礎(chǔ)資產(chǎn)的本質(zhì)。被代幣化的證券依然是證券。因此，市場參與者在交易此類工具時，必須認真考量并遵守聯(lián)邦證券法的相關(guān)規(guī)定。有時，發(fā)行方會對自身證券進行代幣化。購買此類第三方代幣的投資者可能面臨一些特有風(fēng)險，例如對手方風(fēng)險。代幣化證券的發(fā)行方還必須考慮在聯(lián)邦證券法下的信息披露義務(wù)，并可參考美國證監(jiān)會公司財務(wù)部近期發(fā)布的相關(guān)員工聲明。同時，那些發(fā)行、購買及交易代幣化證券的市場參與者，也應(yīng)考慮這些證券的屬性及其所引發(fā)的證券法合規(guī)問題。雖然基于區(qū)塊鏈的代幣化是一項新興技術(shù)，但「發(fā)行代表證券權(quán)利的金融工具」這一行為本身并不新穎。無論是在鏈上還是鏈下發(fā)行此類工具，適用的法律要求都是相同的。因此，市場參與者在設(shè)計其代幣化產(chǎn)品方案時，應(yīng)考慮與美國證監(jiān)會（SEC）及其工作人員進行溝通，我們愿意與市場參與者合作，制定合理的豁免機制，并推動規(guī)則現(xiàn)代化。
LondonBTCCompanyLimited正籌集100萬至500萬英鎊，部分將用于增持比特幣
2025-07-10 00:57
ChainCatcher消息，據(jù)市場消息，LondonBTCCompanyLimited（原名VinanzLimited）正在籌集100萬至500萬英鎊（最高約合680萬美元）資金，其中部分將用于增持比特幣。
慢霧：GMX遭攻擊核心原因系GMXv1全局空頭均價可被操控，GLP價格遭惡意抬高套利
2025-07-10 00:54
ChainCatcher消息，據(jù)慢霧CISO@im23pds發(fā)推表示，「GMX被攻擊的根本原因是GMXv1在處理空頭頭寸時會立即更新全局空頭平局價格，而這個全局平局價格將直接影響總資產(chǎn)規(guī)模(AUM)的計算，進而導(dǎo)致GLP代幣價格被操控。攻擊者利用這個設(shè)計缺陷通過Keeper在執(zhí)行訂單時會啟用timelock.enableLeverage的特性(創(chuàng)建大額空單的必要條件)，通過重入的方式成功創(chuàng)建大額空頭頭寸操縱全局平均價格，以在單筆交易中人為抬高GLP價格并通過贖回操作獲利。
分析：特朗普關(guān)于美聯(lián)儲需要降息的觀點是正確的
2025-07-10 00:51
金色財經(jīng)報道，投資銀行PiperSandler表示，美國總統(tǒng)特朗普關(guān)于美聯(lián)儲需要降息的觀點是正確的。
OpenAI開放語言模型即將問世
2025-07-10 00:47
ChainCatcher消息，據(jù)美國科技媒體TheVerge報道，微軟(MSFT.O)與OpenAI的復(fù)雜關(guān)系即將迎來戲劇性轉(zhuǎn)折。就在雙方重新協(xié)商合同以允許OpenAI重組為營利性公司之際，OpenAI正準備發(fā)布一款開放語言模型，這可能進一步加劇兩家公司的裂痕。知情人士透露，薩姆·奧爾特曼領(lǐng)導(dǎo)的這家AI實驗室即將在下周發(fā)布開放權(quán)重模型，該模型不僅會登陸OpenAI和微軟Azure服務(wù)器，還將向其他云服務(wù)商開放。與OpenAI通常采用的封閉權(quán)重模式不同，此次公開的權(quán)重參數(shù)（一種訓(xùn)練參數(shù)）將向公眾開放，這種開放性意味著企業(yè)和政府能夠自主部署該模型。(金十)

亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

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

目錄

Part 1: Infrastructure

坎昆升級大幅降低L2 手續(xù)費

Client Diversity 的成功實踐

交易確認效率顯著提升

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

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

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

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

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

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

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

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

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

極度嚴謹?shù)墓こ叹衽c長期路線圖

Part 2: Usability

Smart Wallet (ERC-4337)

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

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

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

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

Smart Wallet (EIP-7702)

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

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

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

跨鏈授權(quán)的安全考量

EIP-7702 與ERC-4337 的互補性

Smart Session

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

Smart Session 的概念與理想體驗

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

Intent Centric Design

ERC-7683：跨鏈意圖的標準化實現(xiàn)

靈活性與挑戰(zhàn)

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

CoW Swap 的Intent 解決方案

技術(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

核心特點與通知機制

Part 4: Security

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

VS Code 信任機制的潛在風(fēng)險

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

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

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

安全建議

DeFi 安全（DeFi Security）

Part 5: Fuzz Testing

Fuzz Testing 的原理與限制

相關(guān)范例

案例分析：Vesting 合約漏洞

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

使用Chimera 框架進行測試

Fuzz Testing for ZK Infrastructure

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

持續(xù)且多元測試

Part 6: Formal Verification

Certora

進階功能：驗證不變性（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ù)特點

應(yīng)用場景

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

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

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

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

以太坊是什么？以太坊開發(fā)入門指南