以太坊Devcon大會(huì)精選!十大關(guān)鍵技術(shù)全解析,將徹底改變Web3?
經(jīng)過十天在Devcon 7 與Side events 的密集學(xué)習(xí),我想透過這篇文章濃縮我的所學(xué),并總結(jié)幾個(gè)關(guān)鍵主題,讓更多人了解以太坊生態(tài)在各個(gè)技術(shù)面向上的最前沿發(fā)展、正在解決的問題,以及未來可達(dá)到的理想狀態(tài)。本文章將涵蓋以下主題:
- Infrastructure:以太坊一切的基礎(chǔ)
- Usability:如何提升錢包與DApp 的易用性
- Dev Tools:開發(fā)流程中可使用的工具
- Security:個(gè)人與協(xié)議如何保護(hù)自己的安全
- Fuzz Testing:如何快速發(fā)現(xiàn)智能合約的深層問題
- Formal Verification:透過數(shù)學(xué)證明智能合約的正確性
- Maximal Extractable Value (MEV):如何讓使用者避免MEV 攻擊
- Zero Knowledge Proof (ZKP):應(yīng)用與基礎(chǔ)設(shè)施的最新進(jìn)展
- Multi Party Computation (MPC):保護(hù)隱私的最新研究與挑戰(zhàn)
- Programmable Cryptography:下一世代密碼學(xué)的研究與展望
除了Devcon 主場(chǎng)館的演講與體驗(yàn)活動(dòng),我個(gè)人更喜歡參加特定主題的side events。這些活動(dòng)不僅能深入學(xué)習(xí)相關(guān)領(lǐng)域的知識(shí),還能遇到志同道合的專家進(jìn)行交流。例如在一場(chǎng)關(guān)于zkTLS 的活動(dòng)中,我有機(jī)會(huì)直接向項(xiàng)目方請(qǐng)教文件中不太理解的部分,這段經(jīng)歷讓我印象深刻。未來若有類似的大型研討會(huì),我也強(qiáng)烈建議大家多參加與自己興趣相符的side events。
以下正文開始。
Part 1: Infrastructure
以下將從成就、現(xiàn)況與未來三個(gè)面向,詳細(xì)闡述以太坊如何透過技術(shù)創(chuàng)新解決當(dāng)前挑戰(zhàn),并為未來的擴(kuò)容與去中心化鋪路。
成就:手續(xù)費(fèi)降低與一流的穩(wěn)定性
坎昆升級(jí)大幅降低L2 手續(xù)費(fèi)
今年的坎昆升級(jí)帶來了前所未有的成本優(yōu)化。得益于EIP-4844引入的DAS 技術(shù)(Data Availability Sampling)與Blob機(jī)制,L2 現(xiàn)在可以以更低的成本將更多資料儲(chǔ)存到以太坊主網(wǎng),使每筆交易的費(fèi)用降至不到$0.01 美金,讓L2 的使用更加經(jīng)濟(jì)實(shí)惠
Client Diversity 的成功實(shí)踐
以太坊的Client Diversity是其穩(wěn)定性的重要基石。運(yùn)行以太坊節(jié)點(diǎn)的程式(Client)有多套選擇,例如Geth、Nethermind 和Reth,每套程式的開發(fā)團(tuán)隊(duì)分布于不同地區(qū),程式碼基礎(chǔ)也完全獨(dú)立。知名的執(zhí)行層Client 就有Geth, Nethermind, Reth 等等。
- 關(guān)鍵價(jià)值:即使某個(gè)Client 出現(xiàn)Bug,也不會(huì)影響整體網(wǎng)路,因?yàn)槊總€(gè)Client 的使用比例均低于50%,而以太坊的共識(shí)機(jī)制是至少需要2/3 的節(jié)點(diǎn)同意才能讓區(qū)塊Finalize,因此能夠避免單一Bug 導(dǎo)致整條鏈分岔
- 歷史案例:早期以太坊只有Geth 與Parity 兩個(gè)Client,在某次Client 發(fā)生重大問題時(shí),Client Diversity 幫助以太坊維持了整條鏈的穩(wěn)定運(yùn)行。
- 理想狀況:最理想的分布是所有Client 各自占比低于1/3,這樣即便某個(gè)Client 出現(xiàn)問題,也不會(huì)影響區(qū)塊的最終確認(rèn)(Finalization)。
以太坊算是目前在Client Diversity 上做得最好的公鏈。
交易確認(rèn)效率顯著提升
以太坊的Transaction Inclusion(交易納入)能力相較兩年前有了很大進(jìn)步。如今,絕大多數(shù)交易可在6~30 秒內(nèi)完成確認(rèn),避免了過去常見的交易延遲數(shù)分鐘甚至被節(jié)點(diǎn)丟棄的問題,為用戶帶來更穩(wěn)定的交易體驗(yàn)。
現(xiàn)況:Rollup 的挑戰(zhàn)與安全性
自2020 年Vitalik 確立了以太坊的Rollup Centric 擴(kuò)容路線圖以來,整個(gè)生態(tài)系已經(jīng)誕生了數(shù)百條L2 鏈。在這一架構(gòu)下,L1 作為基礎(chǔ)設(shè)施的角色,提供高度穩(wěn)定、安全且可信中立的保障,而L2 則像GPU 一樣,針對(duì)特定應(yīng)用進(jìn)行加速,顯著提升每秒交易次數(shù)。然而隨著L2 的快速增長,也暴露了一些挑戰(zhàn)。
L2 的信任假設(shè)與分級(jí)安全模型
目前許多L2 項(xiàng)目仍基于強(qiáng)信任假設(shè),某些L2 項(xiàng)目方甚至擁有凍結(jié)用戶資金或停止整條鏈運(yùn)作的權(quán)力。為了更清楚地衡量L2 的安全性,業(yè)界將其分為三個(gè)階段:
- Stage 0:完全中心化的L2。 Stage 0 是最基本的Rollup 實(shí)現(xiàn),只需定期將數(shù)據(jù)提交到以太坊主網(wǎng)即可運(yùn)行,但這意味著資金安全性完全依賴項(xiàng)目方。這種設(shè)計(jì)類似于腳踏車的輔助輪,主要用于幫助項(xiàng)目快速上線運(yùn)作。
- Stage 1:基礎(chǔ)的Rollup 證明與治理機(jī)制。在Stage 1 中,L2 至少實(shí)現(xiàn)了一種Rollup 證明系統(tǒng),例如Optimistic Rollup 的Fraud Proof或ZK Rollup 的ZK Proof。這些證明由智能合約驗(yàn)證L2 狀態(tài)的有效性。此外,項(xiàng)目方需引入Security Council作為治理機(jī)制,對(duì)協(xié)議的關(guān)鍵修改需多數(shù)成員同意,并確保項(xiàng)目方無法在Security Council 中占據(jù)絕對(duì)多數(shù)。
- Stage 2:去中心化與雙重證明系統(tǒng)。在Stage 2,L2 不僅需要實(shí)現(xiàn)兩種獨(dú)立的證明系統(tǒng),還需將絕大部分控制權(quán)交由智能合約處理。 Security Council 僅在證明系統(tǒng)出現(xiàn)沖突時(shí)介入,選擇接受哪一種證明系統(tǒng)。這種設(shè)計(jì)最大程度地限制了項(xiàng)目方的權(quán)力,真正實(shí)現(xiàn)了去中心化與安全性的平衡。
在這三個(gè)階段中,最大的差異在于「項(xiàng)目方做壞事的難度」。在Stage 0,項(xiàng)目方完全掌控,幾乎沒有任何限制。 Stage 1 引入了證明系統(tǒng)與治理機(jī)制,盡管攻擊者可能通過賄賂Security Council 成員等方式發(fā)起攻擊,但成功的難度已顯著提高。而Stage 2 則徹底消除人為干預(yù)的可能性,實(shí)現(xiàn)了理想的去中心化。
目前的L2 發(fā)展現(xiàn)狀與挑戰(zhàn)
目前,大多數(shù)L2 項(xiàng)目仍處于Stage 0 或Stage 1。雖然這些項(xiàng)目標(biāo)榜去中心化,但實(shí)際安全性與項(xiàng)目方的宣傳往往存在差距。專注于L2 安全分析的網(wǎng)站l2beat提供了最新且詳細(xì)的報(bào)告,幫助用戶了解項(xiàng)目方的真實(shí)安全實(shí)現(xiàn)是否達(dá)標(biāo)。他們的研究深入程式碼層面,揭露了許多項(xiàng)目過于依賴行銷術(shù)語而忽視技術(shù)實(shí)現(xiàn)的現(xiàn)象。
Escape Hatch:L2 安全性的核心機(jī)制
L2 必須具備一項(xiàng)關(guān)鍵功能,即Escape Hatch(逃生艙)機(jī)制,來應(yīng)對(duì)項(xiàng)目方的Operator 或Sequencer 停止運(yùn)作時(shí)的突發(fā)情況。這項(xiàng)機(jī)制允許用戶生成自己在L2 上持有資金的證明,并將該證明提交到L1 的治理智能合約以贖回資金。整個(gè)過程必須在沒有項(xiàng)目方介入的情況下完成,才能充分體現(xiàn)L2 的安全性。
例如dydx發(fā)行的L2 在這方面表現(xiàn)出色。當(dāng)他們的L2 決定停止?fàn)I運(yùn)時(shí),提供了工具讓用戶自行將資金轉(zhuǎn)回L1,確保了用戶資金的安全。
L1 的擴(kuò)容需求與去中心化的堅(jiān)守
為了應(yīng)對(duì)未來可能的大量L2 逃生交易,L1 必須持續(xù)擴(kuò)容。然而,Vitalik 多次強(qiáng)調(diào),在擴(kuò)容過程中,不能為了短期內(nèi)的大幅擴(kuò)容而妥協(xié)去中心化。一旦去中心化特性被犧牲,將難以挽回。這種堅(jiān)守是以太坊作為可信中立基礎(chǔ)設(shè)施的核心價(jià)值。
未來:以太坊的進(jìn)化方向與長期愿景
以太坊在未來將迎來多方面的技術(shù)革新,從L2 的進(jìn)一步去中心化,到L1 的性能優(yōu)化,乃至于共識(shí)層的全面重寫,這些計(jì)劃都旨在推動(dòng)以太坊邁向更加高效、安全且去中心化的區(qū)塊鏈生態(tài)。
L2 邁向Stage 2:實(shí)現(xiàn)真正的去中心化
L2 的發(fā)展方向之一是推動(dòng)更多項(xiàng)目邁向Stage 2,這是去中心化與安全性的理想平衡點(diǎn)。 Vitalik 明確表示,未來他只會(huì)將達(dá)到Stage 1的Rollup 稱為Rollup,而未能進(jìn)一步邁向Stage 2 的項(xiàng)目,將難以滿足以太坊的長期愿景。在Stage 2,L2 將依賴雙重證明系統(tǒng),并將控制權(quán)完全交由智能合約處理,進(jìn)一步降低對(duì)人為干預(yù)的依賴。
降低驗(yàn)證門檻:讓更多人參與以太坊網(wǎng)路
未來的目標(biāo)是讓更多人能輕松參與以太坊節(jié)點(diǎn)的驗(yàn)證。這包括:
- 開發(fā)類似Helios的Light Client,讓運(yùn)算資源有限的設(shè)備也能運(yùn)行以太坊驗(yàn)證程式,實(shí)現(xiàn)節(jié)點(diǎn)運(yùn)行的輕量化。
- 將Stake ETH作為驗(yàn)證者的門檻從32 ETH 降低到1 ETH,讓更多用戶能參與驗(yàn)證,進(jìn)一步分散網(wǎng)路風(fēng)險(xiǎn)。
- 減少對(duì)Lido等Liquid Staking Provider 的依賴,避免因過度集中化帶來的風(fēng)險(xiǎn)。
這些措施旨在提升以太坊網(wǎng)路的去中心化程度,確保其穩(wěn)定性與長期可持續(xù)發(fā)展。
執(zhí)行層的持續(xù)擴(kuò)容:TPS 邁向十萬級(jí)別
目前L1 每個(gè)區(qū)塊的Blob數(shù)量與大小存在限制,導(dǎo)致L2 在現(xiàn)階段的理論TPS(每秒交易次數(shù))僅達(dá)幾千筆。然而,未來希望通過擴(kuò)展Blob 機(jī)制,如引入PeerDAS技術(shù),實(shí)現(xiàn)每秒十萬筆交易的目標(biāo)。這將大幅提升以太坊的可擴(kuò)展性,為高頻交易應(yīng)用場(chǎng)景鋪平道路。
共識(shí)層的革命性變革:Beam Chain
以太坊的共識(shí)層將迎來一項(xiàng)重大改變,即Beam Chain的引入。這是Justin 提出的對(duì)現(xiàn)有Beacon Chain 的全面重寫,旨在解決當(dāng)前最棘手的問題,并邁向以太坊的終極目標(biāo)(End Game)。主要的改進(jìn)方向包括:
- 抗量子電腦:隨著量子電腦技術(shù)的發(fā)展,現(xiàn)有的橢圓曲線簽章(ECDSA)面臨被破解的風(fēng)險(xiǎn)。因此,遷移到后量子密碼學(xué)簽章成為當(dāng)務(wù)之急。
- 更快的Finality:目前以太坊達(dá)到最終共識(shí)(Finality)的時(shí)間約為15 分鐘,而理想目標(biāo)是12 秒(Single Slot Finality)。更快的最終確認(rèn)能大幅提升用戶體驗(yàn),特別是在中心化交易所的資金存取等場(chǎng)景中。
- ZK Provable:隨著驗(yàn)證者數(shù)量的增加,如何降低驗(yàn)證者資源需求成為一大挑戰(zhàn)。通過結(jié)合ZK 技術(shù)和簽章聚合(Signature Aggregation),驗(yàn)證者能快速驗(yàn)證數(shù)萬個(gè)其他驗(yàn)證者的簽章,在四秒內(nèi)處理完一個(gè)Block。然而,現(xiàn)有的BLS 簽章基于橢圓曲線密碼學(xué),也需進(jìn)行抗量子攻擊的改寫,才能滿足未來需求。
圖中綠色的項(xiàng)目可以透過對(duì)共識(shí)層漸進(jìn)式的改動(dòng)完成,然而紅色項(xiàng)目最為棘手,需要重寫核心程式碼,Beam Chain 因而被提出作為解決方案。
極度嚴(yán)謹(jǐn)?shù)墓こ叹衽c長期路線圖
Beam Chain 的引入需要對(duì)核心程式碼進(jìn)行全面重寫,不僅能解決現(xiàn)有技術(shù)債,還能從過去的經(jīng)驗(yàn)中汲取教訓(xùn)。根據(jù)初版Beam Chain Roadmap,整個(gè)升級(jí)計(jì)劃將分為三個(gè)階段:
- 一年內(nèi)完成規(guī)格定義。
- 1~2 年完成實(shí)作。
- 1~2 年進(jìn)行完善與全面測(cè)試。
這體現(xiàn)了以太坊對(duì)去中心化的堅(jiān)守以及對(duì)安全性的極高要求,畢竟整個(gè)網(wǎng)路承載了數(shù)千億美元的資金,任何小差錯(cuò)都可能導(dǎo)致災(zāi)難性后果。然而,也有許多社區(qū)成員批評(píng)五年的時(shí)間表過于冗長,期待能加速進(jìn)度。 Justin 表示,這其中的確存在優(yōu)化空間,他也希望更多人參與討論與實(shí)作,共同推動(dòng)這一計(jì)劃的實(shí)現(xiàn)。
需要注意的是,Beam Chain 并非以太坊未來五年的唯一重點(diǎn)。在共識(shí)層進(jìn)行升級(jí)的同時(shí),執(zhí)行層的改進(jìn)(例如透過PeerDAS提高TPS)將持續(xù)推進(jìn),為應(yīng)用開發(fā)者與用戶提供更高效能與更流暢的體驗(yàn)。
Part 2: Usability
隨著ERC-4337 帳戶抽象標(biāo)準(zhǔn)的定案與上線,各式各樣的Smart Wallet(智能錢包)應(yīng)運(yùn)而生,大幅提升了使用者的體驗(yàn)與易用性。然而,這些創(chuàng)新同時(shí)也對(duì)錢包和DApp 帶來了新的技術(shù)挑戰(zhàn)。另一方面,隨著L2 的蓬勃發(fā)展,資產(chǎn)碎片化問題日益顯著,許多協(xié)議與應(yīng)用開始朝向Intent Centric Design和Chain Abstraction的方向發(fā)展,力求解決這些問題,讓使用者能更快速完成復(fù)雜的跨鏈交易,并將相關(guān)細(xì)節(jié)隱藏于背后。以下將逐一探討這些技術(shù)。
Smart Wallet (ERC-4337)
ERC-4337 標(biāo)準(zhǔn)讓智能合約錢包日益普及,其中最具特色的一類便是Passkey 錢包。使用者只需透過生物認(rèn)證即可創(chuàng)建Passkey,并將其作為錢包的私鑰進(jìn)行簽名。每次發(fā)送交易時(shí),使用者只需再次進(jìn)行生物認(rèn)證,完全不需要記憶或保存助記詞,這被許多人視為錢包的「終極體驗(yàn)」。
Passkey 簽章的技術(shù)挑戰(zhàn)
Passkey 錢包的核心在于智能合約中如何驗(yàn)證Passkey 的簽章。 Passkey 簽章使用的是secp256r1橢圓曲線(又稱P-256 簽章),而以太坊原生支持的是secp256k1。兩者雖然只在橢圓曲線的參數(shù)上有所差異,但帶來了巨大的Gas 成本差距:
- secp256k1簽章的驗(yàn)證只需使用以太坊內(nèi)建的precompiled contract,Gas 成本約為3000。
- Passkey 簽章(P-256)的最佳實(shí)作目前需要約30 萬Gas,是前者的100 倍。
為了解決這一問題,RIP-7212提案被提出,旨在降低驗(yàn)證Passkey 簽章的成本。通過該提案后,Gas 成本有望降至約3000,與secp256k1 簽章驗(yàn)證相當(dāng),從而顯著減輕用戶負(fù)擔(dān)。
Passkey 錢包的共同挑戰(zhàn)
即使在成本降低的前提下,Passkey 錢包仍面臨以下幾個(gè)技術(shù)挑戰(zhàn):
- Passkey 與域名唯一綁定:Passkey 是綁定特定域名的。例如,Coinbase Smart Wallet 使用的Passkey 綁定于keys.coinbase.com。這樣的設(shè)計(jì)完全杜絕了釣魚攻擊,但也帶來了域名過期或單點(diǎn)故障的風(fēng)險(xiǎn)。
- 錢包碎片化:每個(gè)Passkey Wallet 綁定不同的域名,導(dǎo)致使用者必須在不同應(yīng)用中創(chuàng)建多個(gè)錢包,進(jìn)一步加劇資產(chǎn)碎片化問題。
- 互通性問題:由于Passkey 錢包的私鑰存儲(chǔ)于裝置的安全儲(chǔ)存空間,不支援匯出,且在Android 和iOS 之間也無法互通,使用者難以在一個(gè)地方統(tǒng)一管理資產(chǎn)。
- 盲簽的安全風(fēng)險(xiǎn):在簽名過程中,使用者僅會(huì)看到「是否同意此應(yīng)用使用這把Passkey」的提示,無法查看具體簽名內(nèi)容,導(dǎo)致高資安風(fēng)險(xiǎn)。若錢包前端遭受XSS 攻擊,用戶資產(chǎn)可能被盜。
這些挑戰(zhàn)讓部分人質(zhì)疑Passkey 作為錢包私鑰的適用性,認(rèn)為其設(shè)計(jì)初衷是用于Web2 登入場(chǎng)景,對(duì)于Passkey 丟失風(fēng)險(xiǎn)的影響較小,隨時(shí)都能透過「忘記密碼」功能找回帳號(hào),而且不需展示具體簽名內(nèi)容。但這不代表Passkey 無法成為錢包的一部分,未來的錢包設(shè)計(jì)或許可以借鑒Web2,提供多種驗(yàn)證與帳號(hào)恢復(fù)選項(xiàng),并依需求設(shè)置不同權(quán)限。
其他錢包驗(yàn)證與恢復(fù)機(jī)制:ZK Email 的創(chuàng)新
除了Passkey,ZK Email團(tuán)隊(duì)提出了一種基于Email 還原錢包控制權(quán)的機(jī)制。使用者可以將指定Email 地址設(shè)為合約錢包的「監(jiān)護(hù)人」(Guardian)。當(dāng)私鑰丟失時(shí),用戶只需從該Email 發(fā)送一封信,包含合約錢包地址及新控制地址等資訊,即可生成ZK 證明,在鏈上驗(yàn)證后取回錢包控制權(quán)。這一設(shè)計(jì)基于多年發(fā)展的Email 基礎(chǔ)設(shè)施,安全性高且操作便捷,有效減少了私鑰丟失帶來的風(fēng)險(xiǎn)。
ERC-4337 的互操作性問題與解決方法
隨著Passkey 和ZK Email 等機(jī)制的應(yīng)用,ERC-4337 錢包面臨著顯著的互操作性挑戰(zhàn)。例如,當(dāng)使用者在A 錢包中建立了ERC-4337 合約錢包,若希望匯出至B 錢包使用,可能因兩者使用的Account Factory Contract不同而無法相容。這導(dǎo)致:
- B 錢包無法辨識(shí)A 錢包所使用的簽章方法。
- B 錢包無法支援發(fā)送A 錢包的交易。
為了解決這一問題,業(yè)界提出了模組化合約錢包標(biāo)準(zhǔn),例如ERC-7579和ERC-6900。這些標(biāo)準(zhǔn)將ERC-4337 的功能進(jìn)一步模組化,例如:
- 授權(quán)模組:可以用Passkey 或多簽驗(yàn)證替換。
- 交易執(zhí)行模組:可根據(jù)應(yīng)用需求更改,例如如何批次執(zhí)行交易。
- 權(quán)限模組:支持靈活的權(quán)限配置。
這樣的設(shè)計(jì)允許所有錢包應(yīng)用共用同一個(gè)Account Factory Contract,并能夠靈活組合不同模組,極大提升互操作性,減少資產(chǎn)管理的摩擦成本。
Smart Wallet (EIP-7702)
EIP-7702(Set EOA Code)是下一代帳戶抽象標(biāo)準(zhǔn),預(yù)計(jì)將在下一次以太坊Pectra 硬分岔中被納入。這項(xiàng)提案的初衷在于解決ERC-4337的一個(gè)關(guān)鍵限制:使用者需要?jiǎng)?chuàng)建新的智能合約錢包,無法延續(xù)過去的EOA(Externally Owned Account)。 EIP-7702 則提供了一個(gè)全新解法,允許任何EOA 地址「升級(jí)」為智能合約錢包,帶來多樣化的靈活功能:
- 批次執(zhí)行交易:將DeFi 操作中的多次簽名(如Approve + Swap)簡化為一次簽名即可完成。
- Gas 贊助:EOA 不必持有ETH,也可以透過其他地址代為支付交易所需的Gas。
- 彈性的權(quán)限設(shè)定:支持Passkey 或多簽等驗(yàn)證邏輯,讓EOA 具備更多智能化功能。
EIP-7702 的應(yīng)用案例
Ithaca 團(tuán)隊(duì)在EXP-0001中展示了EIP-7702 的Demo,讓使用者可以一鍵創(chuàng)建Passkey 并將EOA 地址的權(quán)限代理給該P(yáng)asskey。此后,所有交易只需Passkey 簽名即可完成,且已在測(cè)試網(wǎng)中部署了RIP-7212(Passkey 簽章優(yōu)化)的實(shí)作,顯著降低了Gas 成本。借助這一技術(shù),EOA 可透過單一Passkey 簽章執(zhí)行多筆交易,進(jìn)一步提升使用者的便利性。
EIP-7702 的技術(shù)流程
EIP-7702 的核心在于如何將EOA 地址綁定智能合約邏輯,其具體流程如下:
- 授權(quán)請(qǐng)求:使用者擁有一個(gè)EOA 地址(假設(shè)為A),希望將其升級(jí)為智能合約錢包,并選擇一個(gè)智能合約實(shí)作地址(S)。
- 生成授權(quán)簽章:使用A 的私鑰簽署一個(gè)授權(quán)訊息,包含鏈ID、nonce,以及S 的地址等資訊。
- 提交授權(quán)交易:若A 沒有ETH,可將授權(quán)簽章提交給Relayer,由Relayer 代為支付Gas,將授權(quán)訊息上鏈。
- 存儲(chǔ)合約邏輯:交易完成后,A 的Account Code Storage 將儲(chǔ)存S 的地址。
- 執(zhí)行合約邏輯:未來A 發(fā)送交易時(shí),Relayer 可以呼叫A 地址并傳入交易參數(shù),A 的Account Code 會(huì)在執(zhí)行過程中改寫為S 的邏輯,實(shí)現(xiàn)智能化功能。
- 取消授權(quán):若使用者希望取消授權(quán),可使用A 的私鑰簽署取消請(qǐng)求,并提交至鏈上。
安全挑戰(zhàn)與潛在風(fēng)險(xiǎn)
雖然EIP-7702 的功能十分強(qiáng)大,但也帶來了一些新的安全風(fēng)險(xiǎn):
- 授權(quán)惡意合約的風(fēng)險(xiǎn):如果使用者不小心簽署了一個(gè)惡意EIP-7702 簽章,攻擊者可借助合約邏輯批次轉(zhuǎn)移使用者的所有資產(chǎn),包括Token、NFT 和DeFi 倉位。相比現(xiàn)有的Permit Signature,EIP-7702 的潛在風(fēng)險(xiǎn)更高。
- 跨鏈?zhǔn)跈?quán)的風(fēng)險(xiǎn):簽署授權(quán)訊息時(shí),若使用chain ID = 0,表示簽章對(duì)所有EVM 鏈生效。一個(gè)簽章可能導(dǎo)致所有鏈上的資產(chǎn)同時(shí)暴露于風(fēng)險(xiǎn),效果等同于私鑰泄漏。
跨鏈?zhǔn)跈?quán)的安全考量
EIP-7702 的設(shè)計(jì)中,簽章包含Account Nonce,這代表若不同鏈上的地址nonce 不同,簽章將無效。這一設(shè)計(jì)可以讓錢包App 通過一個(gè)簽章升級(jí)用戶的地址至所有鏈上的合約錢包,提升便利性。然而開發(fā)者在設(shè)計(jì)時(shí)需謹(jǐn)慎處理nonce 機(jī)制,避免出現(xiàn)不必要的安全漏洞。
至于可能會(huì)授權(quán)惡意合約的問題,錢包App 可采取以下措施:
- 引入「白名單」系統(tǒng),對(duì)合約地址進(jìn)行驗(yàn)證。
- 透過界面提示用戶授權(quán)的合約邏輯是否安全。
EIP-7702 與ERC-4337 的互補(bǔ)性
EIP-7702 的核心優(yōu)勢(shì)在于支持將現(xiàn)有的EOA 升級(jí)為智能合約錢包。然而,這也帶來一個(gè)限制:EOA 的私鑰始終擁有最高權(quán)限。如果私鑰泄漏,將直接導(dǎo)致錢包的控制權(quán)喪失。而ERC-4337可以實(shí)現(xiàn)多簽錢包等無需依賴單一私鑰的設(shè)計(jì),提供更高的安全性。因此,EIP-7702 與ERC-4337 之間并非相互替代,而是互補(bǔ)的關(guān)系。 EIP-7702 彌補(bǔ)了ERC-4337 在EOA 過渡上的不足,而ERC-4337 則提供更高的安全保障,適用于對(duì)安全性有更高需求的場(chǎng)景。
Smart Session
雖然智能錢包(Smart Wallet)帶來了許多創(chuàng)新,但它們的出現(xiàn)并不代表DApp 的使用體驗(yàn)會(huì)自動(dòng)變好。錢包與DApp 之間的溝通方式需要進(jìn)一步的協(xié)調(diào)和標(biāo)準(zhǔn)化,才能真正實(shí)現(xiàn)流暢的使用體驗(yàn)。
DApp 與Smart Wallet 的兼容挑戰(zhàn)
在傳統(tǒng)的EOA 設(shè)計(jì)中,DApp 發(fā)送交易通常是通過簡單的eth_sendTransaction 介面向錢包發(fā)送請(qǐng)求。然而,Smart Wallet(如基于ERC-4337 的智能合約錢包)需要一種全新的操作模式。 ERC-4337 引入了User Operation的結(jié)構(gòu)作為核心元件,但問題在于許多現(xiàn)有DApp 并不知道如何生成User Operation 的資訊。這導(dǎo)致Smart Wallet 與當(dāng)前DApp 生態(tài)的兼容性大打折扣。
為了解決這一問題,社群內(nèi)正在討論如何統(tǒng)一相關(guān)介面,其中一些重要的提案包括:
- EIP-5792:幫助DApp 確認(rèn)錢包支持哪些Smart Account 的功能。
- ERC-7677:指導(dǎo)DApp 如何生成User Operation 中的paymasterAndData 欄位。
- ERC-7679:提供生成完整User Operation 的規(guī)范。
這些提案的目的是讓DApp 能更輕松地與Smart Wallet 互動(dòng),提升其易用性并加速智能錢包的普及。
Smart Session 的概念與理想體驗(yàn)
除了介面統(tǒng)一外,另一個(gè)重要的改進(jìn)方向是提升錢包與DApp 的交互體驗(yàn),減少使用者需要反覆操作錢包的次數(shù)。Reown(前WalletConnect)的創(chuàng)始人提出了Smart Session的概念,旨在簡化操作流程并提供OAuth 式的授權(quán)體驗(yàn)。理想中的使用場(chǎng)景如下:
- 初始授權(quán):使用者登入DApp 時(shí),DApp 向錢包請(qǐng)求授權(quán),并說明需要執(zhí)行的交易范圍(例如Uniswap 請(qǐng)求Approve 與Swap 的權(quán)限)。
- 生成Session Key:使用者在錢包中點(diǎn)擊同意后,DApp 獲得一個(gè)Session Key,該Key 對(duì)應(yīng)于使用者同意的授權(quán)范圍。
- 簡化交易簽署:當(dāng)使用者操作DApp 并需要發(fā)送交易時(shí),DApp 使用Session Key 簽署交易并提交到鏈上,過程中無需用戶再次確認(rèn)。
透過Smart Session,使用者的點(diǎn)擊次數(shù)可以減少到僅需一次,同時(shí)授權(quán)流程變得直觀,類似Google 或Facebook 的OAuth 體驗(yàn)。這種設(shè)計(jì)符合錢包與DApp 連接的終極目標(biāo):「Less Clicks & More Control」,即在減少用戶操作的同時(shí),保持用戶對(duì)授權(quán)的完全掌控。
安全風(fēng)險(xiǎn)與解決方案
Smart Session 雖然優(yōu)化了使用體驗(yàn),但也帶來了一些安全風(fēng)險(xiǎn),尤其是Session Key 泄漏的可能性??紤]到瀏覽器端是前端攻擊(如XSS)的高發(fā)地點(diǎn),如何安全地儲(chǔ)存與管理Session Key 是必須解決的問題。
Passkey 是實(shí)現(xiàn)Session Key 安全存儲(chǔ)與簽名的良好選擇,因?yàn)樗艽蠓档托孤╋L(fēng)險(xiǎn)。同時(shí),Session Key 的設(shè)計(jì)應(yīng)保證丟失后對(duì)用戶的影響最小,用戶只需重新授權(quán)即可恢復(fù)使用。
Intent Centric Design
隨著上百條L2 的誕生,使用者的資產(chǎn)逐漸分散到不同鏈上。這種分散性帶來了跨鏈操作的復(fù)雜性,不僅速度慢,體驗(yàn)也相當(dāng)不友好。在應(yīng)用層面,越來越多的協(xié)議開始采用Intent Centric Design(意圖導(dǎo)向設(shè)計(jì))來解決這些問題。這種設(shè)計(jì)理念的核心在于,用戶只需表達(dá)自己的目標(biāo)意圖(Intent),而不需要關(guān)心具體實(shí)現(xiàn)方式,將操作的復(fù)雜性·交由Solver(解決者)處理。從過去的「自行開車到目的地」到如今「叫Uber 即可」,這正是Intent Centric Design 帶來的使用體驗(yàn)轉(zhuǎn)變。
ERC-7683:跨鏈意圖的標(biāo)準(zhǔn)化實(shí)現(xiàn)
ERC-7683是由Uniswap 和跨鏈橋Across 提出的跨鏈意圖標(biāo)準(zhǔn),它讓用戶只需簽署跨鏈操作的意圖,由Solver 負(fù)責(zé)完成具體請(qǐng)求,支援以下常見場(chǎng)景:
- 資產(chǎn)跨鏈移動(dòng):將A 鏈上的X Token 移動(dòng)到B 鏈。
- 跨鏈資產(chǎn)兌換:在A 鏈上的X Token 換成B 鏈上的Y Token。
- 跨鏈后的復(fù)合操作:在完成跨鏈兌換后執(zhí)行目標(biāo)鏈上的合約操作,例如購買NFT。
使用者只需一鍵操作,即可完成如「將ETH 從以太坊跨鏈至Arbitrum 并購買NFT」的復(fù)雜任務(wù),且整個(gè)過程可在三秒內(nèi)完成。
ERC-7683 的操作流程如下:
- 記錄意圖:使用者在A 鏈將資產(chǎn)存入ERC-7683 合約,并記錄其操作意圖(Intent)。
- Solver 鎖定意圖: Solver 監(jiān)聽Intent,判斷是否符合其能力與利潤需求,然后在A 鏈鎖定該Intent。
- 執(zhí)行跨鏈意圖: Solver 在B 鏈墊付資金完成用戶的目標(biāo)操作,例如轉(zhuǎn)移Token 或兌換資產(chǎn)。這種「先墊款后操作」的模式大幅提升操作速度。
- 結(jié)算與支付:協(xié)議在A 鏈上基于B 鏈的最終狀態(tài)(finalized state)每小時(shí)進(jìn)行結(jié)算,計(jì)算Solver 的服務(wù)費(fèi)并支付。
使用者支付的手續(xù)費(fèi)基本等同于一小時(shí)的借貸利息。這種模式比傳統(tǒng)基于訊息的跨鏈協(xié)議效率更高,因?yàn)槠洳捎昧伺谓Y(jié)算方式,減少了跨鏈訊息傳輸?shù)某杀?,無需每筆交易都傳送一個(gè)跨鏈的訊息。
靈活性與挑戰(zhàn)
ERC-7683 允許開發(fā)者自定義結(jié)算邏輯,讓合約決定支付Solver 的條件。這樣的靈活性也帶來以下問題:
- 流動(dòng)性碎片化: Solver 可能因不熟悉或信任特定的結(jié)算邏輯,而選擇不參與某些合約的Intent,導(dǎo)致不同Settlement 合約間的流動(dòng)性缺乏競(jìng)爭(zhēng)性。
- 安全性風(fēng)險(xiǎn):若結(jié)算合約出現(xiàn)問題,Solver 可能無法收回墊付資金,增加了參與風(fēng)險(xiǎn)。
為解決這些問題,可在Settlement 合約采用模組化設(shè)計(jì),讓結(jié)算邏輯簡單易懂且易于審計(jì),從而吸引更多Solver 提供流動(dòng)性。
ERC-7683 與EIP-7702 的結(jié)合應(yīng)用
未來結(jié)合EIP-7702,ERC-7683 能實(shí)現(xiàn)更高效的跨鏈操作。例如,透過一個(gè)chain ID = 0 的簽章升級(jí)所有EVM 鏈的EOA 為智能合約錢包,使用者可將Intent 設(shè)定為「在B 鏈執(zhí)行某操作」,并以目標(biāo)鏈上的身份完成交易。這樣,用戶可在A 鏈上管理資產(chǎn),同時(shí)請(qǐng)求Solver 在其他鏈執(zhí)行交易并支付對(duì)應(yīng)的Gas。此過程中,Solver 的角色不僅執(zhí)行交易,還幫助減少Gas 成本,實(shí)現(xiàn)完全去中心化的解決方案。
CoW Swap 的Intent 解決方案
CoW Swap 在單鏈場(chǎng)景中推動(dòng)了Intent 的應(yīng)用,專注于優(yōu)化Swap 體驗(yàn)。其核心特點(diǎn)包括:
- 聚合多個(gè)Intent: Solver 可同時(shí)計(jì)算多個(gè)Intent 的最佳交易路徑,例如同時(shí)滿足A 使用者想用X Token 換Y Token,與B 使用者想用Y Token 換X Token 的需求。
- 減少手續(xù)費(fèi):此方法避免了使用者分別與流動(dòng)池進(jìn)行交易的成本,帶來理論上的最佳價(jià)格。
然而,CoW Swap 的解決方案對(duì)Solver 提出了極高的技術(shù)要求:
- 流動(dòng)性獲取:必須快速從多個(gè)DEX、中心化交易所(CEX)及跨鏈資源中獲取流動(dòng)性。
- 演算法優(yōu)化:如何快速聚合并計(jì)算最優(yōu)交易路徑仍是未解的最佳化問題。
- 精準(zhǔn)執(zhí)行:在鏈上執(zhí)行交易時(shí)需避免MEV(最大可提取價(jià)值)攻擊,同時(shí)在CEX 執(zhí)行交易也需確保價(jià)格的精準(zhǔn)度。
其他Intent 案例:Daimo 的Cross L2 Intent Address
在交易場(chǎng)景的Intent 解決方案之外,Daimo 提出了Cross L2 Intent Address的設(shè)計(jì),為跨鏈支付與DeFi 操作帶來了更高效的方式。該設(shè)計(jì)允許使用者在source chain上將USDC 發(fā)送到一個(gè)指定地址,通過relayer在destination chain執(zhí)行后續(xù)操作,例如將USDC 跨鏈后進(jìn)行特定的DeFi 操作。整個(gè)過程完全去中心化,適用于跨鏈支付、一鍵投資等場(chǎng)景。
技術(shù)實(shí)現(xiàn)原理
這一設(shè)計(jì)的核心依賴于Circle 的CCTP 跨鏈橋和以太坊的CREATE2機(jī)制,通過結(jié)合這兩者實(shí)現(xiàn)用戶Intent 的自動(dòng)化執(zhí)行。
- CCTP 的目標(biāo)地址指定:在使用Circle 的CCTP 跨鏈橋時(shí),用戶可以指定目標(biāo)鏈上的接收地址。如果該地址是一個(gè)智能合約,relayer 就能在接收USDC 前執(zhí)行合約中定義的操作。執(zhí)行完成后,relayer 再通過CCTP 獲取跨鏈的USDC 作為報(bào)酬。這種機(jī)制使得relayer 能在資金到達(dá)前完成用戶的Intent,大幅提升交易速度與用戶體驗(yàn)。
- CREATE2 的地址預(yù)計(jì)算:在source chain 上,使用者需要事先確定目標(biāo)鏈上的Intent 合約地址。這可以通過CREATE2機(jī)制實(shí)現(xiàn):CREATE2 允許在合約未部署時(shí)就計(jì)算其未來地址,只需提供合約的byte code 和一個(gè)salt。這樣,用戶在source chain 上的操作即可預(yù)先確定目標(biāo)鏈的合約地址。
- Relayer 的執(zhí)行流程:首先在destination chain 部署智能合約,并呼叫智能合約以執(zhí)行用戶的Intent(例如參與DeFi 協(xié)議)。最后在同一交易中呼叫selfdestruct,清空合約的code storage并獲得gas fee refund。
這種做法相比ERC-7683 更簡單,但需要在交易過程中部署合約,導(dǎo)致增加一些gas 費(fèi)用。不過,由于部署的合約只是小型的proxy contract,指向預(yù)先部署好的implementation contract,因此額外成本相對(duì)有限。
Chain Abstraction
Chain Abstraction的核心理念是隱藏區(qū)塊鏈的存在,讓使用者專注于資產(chǎn)本身,而非背后的鏈。這意味著使用者只需知道自己擁有多少USDC、ETH 等資產(chǎn),而不用關(guān)心它們分散在哪些鏈上。當(dāng)使用者發(fā)起USDC 的轉(zhuǎn)帳時(shí),系統(tǒng)會(huì)自動(dòng)檢測(cè)并整合所有鏈上的USDC,完成轉(zhuǎn)帳所需的跨鏈操作。同時(shí),使用者不需要為Gas 費(fèi)煩惱,可以直接用轉(zhuǎn)帳的USDC 支付Gas。
Biconomy Modular Execution Environment
Biconomy 提供了Modular Execution Environment (MEE)解決方案,專為支持Chain Abstraction 而設(shè)計(jì)。這個(gè)系統(tǒng)允許ERC-4337 錢包的開發(fā)者輕松定義跨多鏈的操作,并將其整合為一個(gè)Supertransaction。使用者僅需簽署一次對(duì)Supertransaction 的授權(quán),即可實(shí)現(xiàn)以下功能:
- 在多條鏈上執(zhí)行指定的User Operations。
- 自動(dòng)完成跨鏈操作并達(dá)成最終目標(biāo)。
其技術(shù)基礎(chǔ)在于用戶對(duì)所有操作生成一個(gè)Merkle Root Hash簽章,然后透過Modular Execution Environment 自動(dòng)將這些操作上鏈執(zhí)行。
其他解決方案
多家公司也提出了不同形式的Chain Abstraction 解決方案:
- ZeroDev:提供了類似的SDK,讓開發(fā)者可以方便地批量發(fā)送多鏈交易,簡化操作流程。
- OneBalance:提供了Credible Account模組,支持整合多鏈的資產(chǎn)并實(shí)現(xiàn)Chain Abstraction。
- Particle Network:采用Account-level Chain Abstraction,專注于網(wǎng)頁錢包的體驗(yàn),率先打造具有Chain Abstraction 的應(yīng)用。
- Nekodex:結(jié)合Chain Abstraction 以及基于Passkey 的Account Abstraction 統(tǒng)一DEX 上多鏈的交易體驗(yàn),降低使用門檻
Part 3: Dev Tools
以太坊的開發(fā)生態(tài)持續(xù)進(jìn)步,各種工具大幅提升了開發(fā)者的效率,無論是在測(cè)試網(wǎng)的模擬、智能合約的除錯(cuò),還是區(qū)塊鏈資料的索引,都有顯著的創(chuàng)新。以下是幾款值得關(guān)注的工具與解決方案。
Tenderly Virtual Test Net
Tenderly Virtual Test Net是一個(gè)強(qiáng)大的虛擬測(cè)試網(wǎng)工具,允許開發(fā)者fork 主網(wǎng),其特色是能與主網(wǎng)保持即時(shí)同步狀態(tài)。同時(shí)它支援:
- 無限制的資源模擬:開發(fā)者可以隨時(shí)取得測(cè)試網(wǎng)上的以太坊或任意修改Storage 狀態(tài)。
- CI 整合:通過Github Action,開發(fā)者能快速生成干凈的測(cè)試環(huán)境,用于合約部署與自動(dòng)化測(cè)試。
Simbolik
Simbolik是專為Solidity開發(fā)設(shè)計(jì)的除錯(cuò)工具,與VS Code無縫整合,只要在測(cè)試上方案下Debug 就能執(zhí)行。它的功能包括:
- 完整的EVM 環(huán)境可視化:能即時(shí)檢查每行Solidity 代碼執(zhí)行時(shí)的stack、memory和storage狀態(tài)。
- EVM bytecode 分析:直觀展示編譯后的EVM bytecode 的執(zhí)行過程。
Simbolik 為開發(fā)者提供了高效且細(xì)致的除錯(cuò)支持,幫助快速定位并解決合約中的問題。
TrustBytes
TrustBytes是一款將Solidity 程式碼轉(zhuǎn)化為圖像化呈現(xiàn)的工具,特別適合合約審計(jì)。它的核心功能包括:
- 函數(shù)調(diào)用關(guān)系可視化:清晰顯示合約中所有函數(shù)之間的調(diào)用路徑。
- 變數(shù)讀寫追蹤:快速定位變數(shù)的讀寫位置,分析潛在Re-entrancy 風(fēng)險(xiǎn)。
- 惡意輸入分析:標(biāo)示出哪些函數(shù)參數(shù)來自使用者輸入,幫助預(yù)防惡意攻擊。
TrustBytes 通過縮短代碼追蹤的時(shí)間以提升審計(jì)效率,特別是在分析潛在攻擊點(diǎn)方面??蓞⒖计?a href="https://nextjsapp-7dycvtrugq-uc.a.run.app/" rel="nofollow" target="_blank">Demo 網(wǎng)站。
Ethereum Indexer
以太坊的資料結(jié)構(gòu)讓直接從JSON RPC 獲取資料效率低下,因此需要透過Indexer 將資料提取并存儲(chǔ)到高效的資料庫中。以下是兩個(gè)值得關(guān)注的解決方案。
Index Supply 的Shovel
Shovel 是一款開源工具,允許開發(fā)者透過簡單的config 檔,將鏈上資料轉(zhuǎn)化為指定格式并儲(chǔ)存到PostgreSQL DB。例如,紀(jì)錄一個(gè)錢包的歷史ERC20 Token Transfer 可以這樣設(shè)定:
{
"name": "erc20_transfers",
"enabled": true,
"sources": [{"name": "mainnet"}],
"table": {
"name": "erc20_transfers",
"columns": [
{ "name": "block_num", "type": "numeric"}, {"name"
: "tx_hash", "type
": "bytea"}, {"name": "from", "type": "bytea "},
{"name": "to", "type": "bytea"},
{"name": "value", "type": "bytea"},
]
},
"block": [
{"name ": "block_num", "column": "block_num"},
{"name": "tx_hash", "column": "tx_hash"}
],
"event": {
"name": "Transfer",
"type" : "event",
"anonymous": false,
"inputs": [
{"indexed": true, "name": "from", "type": "address", "column": "from"},
{" indexed": true, "name": "to", "type": "address", "column": "to"},
{"name": "value", "type": "uint256", "column" : "value"}
]
}
}
透過簡單的配置,Shovel 能快速完成資料的提取與存儲(chǔ),大幅降低開發(fā)成本。
Reth Execution Extension
Reth Execution Extension提供了一種新穎且高效的設(shè)計(jì),針對(duì)鏈上資料索引與Re-org(鏈重組)處理,解決了傳統(tǒng)方法中的諸多痛點(diǎn)。
過去,如果使用geth等節(jié)點(diǎn)軟體來擴(kuò)展功能,往往需要直接修改節(jié)點(diǎn)內(nèi)的程式碼,這樣的做法相當(dāng)于對(duì)節(jié)點(diǎn)進(jìn)行了fork。一旦上游節(jié)點(diǎn)有更新,開發(fā)者還需要持續(xù)合并更新的程式碼,這無疑增加了開發(fā)與維護(hù)的復(fù)雜性。
Reth 的創(chuàng)新之處在于其設(shè)計(jì)為可直接作為library import,開發(fā)者不需要fork 或修改節(jié)點(diǎn)本身的程式碼,就能靈活擴(kuò)展節(jié)點(diǎn)功能。
核心特點(diǎn)與通知機(jī)制
Reth 提供了清晰且靈活的通知介面,用于處理區(qū)塊鏈的三種狀態(tài)變化:
- ChainCommitted:新區(qū)塊被確認(rèn)(Committed)。
- ChainReorged:鏈重組導(dǎo)致出現(xiàn)新舊鏈切換。
- ChainReverted:區(qū)塊被Revert
以下是范例程式碼展示如何處理這些通知:
async fn exex<Node: FullNodeComponents>(mut ctx: ExExContext<Node>) -> eyre::Result<()> {
while let Some(notification) = ctx.notifications.recv().await {
match ¬ification {
ExExNotification: :ChainCommitted { new } => {
// do something
}
ExExNotification::ChainReorged { old, new } => {
// do something
}
ExExNotification::ChainReverted { old } => {
// do something
}
};
}
Ok( ())
}
Part 4: Security
安全問題一直是區(qū)塊鏈領(lǐng)域的核心挑戰(zhàn),從開發(fā)環(huán)境的設(shè)置,到設(shè)備與用戶端的保護(hù),再到DeFi 合約層面的防御,都需要嚴(yán)密的措施來降低風(fēng)險(xiǎn)。以下針對(duì)開發(fā)、設(shè)備與DeFi 安全三大主題進(jìn)行探討。
開發(fā)環(huán)境安全(Dev Security)
在區(qū)塊鏈應(yīng)用的開發(fā)過程中,環(huán)境的安全性往往容易被忽視,但它可能成為駭客的突破口。
VS Code 信任機(jī)制的潛在風(fēng)險(xiǎn)
當(dāng)開發(fā)者在VS Code中開啟一個(gè)惡意的Repo 并點(diǎn)擊「Yes, I trust the authors」后,駭客可能利用.vscode 資料夾內(nèi)的設(shè)定執(zhí)行任意腳本,包括:
- 竊取電腦中的secret 或private key。
- 開啟一個(gè)reverse shell,讓駭客遠(yuǎn)端控制電腦。
這是因?yàn)?vscode 中的Tasks可以設(shè)置觸發(fā)特定條件的自動(dòng)執(zhí)行腳本(詳見官方文檔)。這種漏洞可能導(dǎo)致開發(fā)者的整個(gè)系統(tǒng)處于被駭客接管的風(fēng)險(xiǎn)中。
防范措施:使用Sandbox 環(huán)境
為避免上述風(fēng)險(xiǎn),開發(fā)者應(yīng)在Sandbox 環(huán)境中開啟專案。具體來說,可以使用VS Code 的Dev Container 功能,在Docker 容器中執(zhí)行完整的開發(fā)環(huán)境。這樣即使惡意代碼執(zhí)行,也只會(huì)影響隔離的容器,不會(huì)危及主機(jī)系統(tǒng)。
Github Action Self Hosted Runner 的風(fēng)險(xiǎn)
Self Hosted Runner 是Github 提供開發(fā)者自行建置CI 環(huán)境所需機(jī)器的解決方案。然而如果在Public Repo 啟用Self Hosted Runner會(huì)帶來潛在威脅:
- 惡意用戶可以Fork 該Repo 并修改Github Action 的腳本,執(zhí)行任意命令。
- 這可能導(dǎo)致Runner 被入侵,駭客竊取所有Github Token 和Secrets。
這一風(fēng)險(xiǎn)已被詳述于Synacktiv 的報(bào)告。建議避免在Public Repo 中使用Self Hosted Runner,或采用更嚴(yán)格的權(quán)限管理。
設(shè)備安全(Device Security)
Ledger 的研究顯示iOS 和Android 平臺(tái)的Syncable Passkey實(shí)作并不像預(yù)期中那么安全。主要問題在于:
- 私鑰復(fù)制到應(yīng)用程式記憶體:雖然Passkey 本應(yīng)依賴Secure Enclave 來存儲(chǔ)私鑰,但實(shí)際上私鑰可能會(huì)被復(fù)制到應(yīng)用程式記憶體(application memory)。這使得私鑰暴露于潛在的惡意軟體攻擊之下,例如透過監(jiān)聽記憶體來竊取私鑰。
- 記憶體快取問題:某些平臺(tái)的快取機(jī)制會(huì)在裝置解鎖之前就將私鑰暫存到記憶體中,進(jìn)一步增加了被惡意軟體利用的風(fēng)險(xiǎn)。
安全建議
為了降低使用Passkey 帶來的風(fēng)險(xiǎn),建議采取以下措施:
- 選擇Un-syncable Passkey:在創(chuàng)建Passkey 時(shí),選擇「不可同步」(Un-syncable)的選項(xiàng),避免私鑰在不同設(shè)備之間同步時(shí)的潛在安全問題。
- 避免存放大量資金:不要將過多資金存放于Passkey 錢包中,僅作為小額支付或日常操作使用。
- 使用硬體錢包:對(duì)于高價(jià)值資產(chǎn),建議繼續(xù)使用硬體錢包作為主要的存儲(chǔ)方式,因?yàn)橛搀w錢包提供了更高的安全保證。
這些建議可以有效降低Passkey 在日常應(yīng)用中的潛在風(fēng)險(xiǎn),同時(shí)確保資產(chǎn)的安全性。
DeFi 安全(DeFi Security)
區(qū)塊鏈應(yīng)用最核心的DeFi 領(lǐng)域,因其高額資金流動(dòng)性,成為駭客攻擊的主要目標(biāo)。防范這類風(fēng)險(xiǎn)需要智能合約與基礎(chǔ)設(shè)施層面的共同努力。例如Forta提供了一種基于AI 模型的鏈上防火墻,用于過濾潛在攻擊交易。其運(yùn)作機(jī)制如下:
- 交易簽名驗(yàn)證:DeFi 合約需要為合約中的關(guān)鍵方法加上Forta 的簽章參數(shù)
- 交易模擬與風(fēng)險(xiǎn)評(píng)估:Forta 的RPC 節(jié)點(diǎn)將模擬交易執(zhí)行過程,通過AI 模型評(píng)估風(fēng)險(xiǎn)分?jǐn)?shù)。 Fora 已經(jīng)實(shí)現(xiàn)99% 以上的準(zhǔn)確度
- 執(zhí)行控制:只有風(fēng)險(xiǎn)分?jǐn)?shù)低于門檻值的交易才會(huì)獲得簽名并被放行。
因此這個(gè)做法必須由DApp 透過Forta 提供的RPC 發(fā)送交易才可以,如果使用公開的RPC 則無法取得必要的簽章。但這也帶來潛在的問題與挑戰(zhàn):
- 升級(jí)與整合困難:DeFi 協(xié)議需要修改合約以整合Forta 的系統(tǒng),這對(duì)現(xiàn)有協(xié)議的升級(jí)是一大挑戰(zhàn),尤其是影響到可組合性,因?yàn)槠渌鸇eFi 協(xié)議就無法輕易呼叫自己的合約。
- 交易模擬問題:在鏈下的環(huán)境模擬交易執(zhí)行的結(jié)果可能與實(shí)際上鏈的結(jié)果不同,有機(jī)會(huì)被駭客利用
- 順序依賴問題:由于L2 鏈上交易的執(zhí)行順序是由Sequencer 決定,駭客有機(jī)會(huì)透過交易順序的不一致性來在模擬時(shí)產(chǎn)生正常的結(jié)果,拿到簽章后上鏈執(zhí)行惡意交易
至于如何解決第二個(gè)問題,知名交易安全檢測(cè)公司Blowfish 的CTO 提到,可以在模擬交易過程檢測(cè)該交易是否使用了與EVM 環(huán)境參數(shù)相關(guān)的邏輯,例如block.timestamp 或block.basefee 等等,但也無法保證100% 判斷正確,因此精準(zhǔn)的交易模擬仍然是安全領(lǐng)域待解決的難題。
Part 5: Fuzz Testing
Fuzz Testing 是一種強(qiáng)大的測(cè)試技術(shù),其核心原理是透過大量隨機(jī)的輸入測(cè)試智能合約,試圖觸發(fā)意外的邏輯漏洞。這種方法對(duì)于捕捉人眼難以察覺的邊緣情境(corner cases)尤其有效。
Fuzz Testing 的原理與限制
Fuzzer 的主要作用是持續(xù)嘗試各種隨機(jī)輸入來檢測(cè)智能合約是否能滿足定義的Invariant(不可變條件)。開發(fā)者可以利用這種方法進(jìn)行黑箱測(cè)試,模擬合約的實(shí)際使用情境,并驗(yàn)證其邏輯是否能抵抗各種異常操作。
盡管Fuzz Testing 是捕捉邏輯漏洞的有效工具,但找不到漏洞并不代表合約沒有問題。 Fuzzer 的效果取決于定義的Invariant 是否完善,以及隨機(jī)測(cè)試的覆蓋范圍。
相關(guān)范例
以下是三個(gè)經(jīng)典例子,說明如何使用黑箱的Fuzz Testing 方法來檢測(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)該變長或保持不變。
驗(yàn)證:比較移除邊前后的最短路徑。 - 編譯器測(cè)試:原始輸入:程式P。
隨機(jī)調(diào)整:在P 中加入Dead Code 后編譯,結(jié)果執(zhí)行的行為應(yīng)與原始程式一致。
驗(yàn)證:比較兩次執(zhí)行結(jié)果。
使用Chimera 撰寫Fuzz Test
以下介紹如何使用Chimera框架來整合多種Fuzzer 工具(如Echidna、Medusa 和Foundry)進(jìn)行智能合約的Fuzz 測(cè)試。
案例分析:Vesting 合約漏洞
以下是一個(gè)簡化的Vesting智能合約范例,其目的是實(shí)現(xiàn)用戶的積分分配與轉(zhuǎn)移,完整程式碼在solidity-fuzzing-comparison Repo 中的09-vesting 。然而,該合約存在一個(gè)漏洞:用戶可以通過「自我轉(zhuǎn)移」增加自己的積分,進(jìn)而破壞總積分不變的Invariant。
Vesting.sol 合約部分代碼:
// users entitled to an allocation can transfer their points to
// another address if they haven't claimed
function transferPoints(address to, uint24 points) external {
require(points != 0, "Zero points invalid");
AllocationData memory fromAllocation = allocations[msg.sender];
require(fromAllocation.points >= points, "Insufficient points");
require(!fromAllocation.claimed, "Already claimed");
AllocationData memory toAllocation = allocations[to];
require(!toAllocation. claimed, "Already claimed");
// enforce identical vesting periods if `to` has an active vesting period
if(toAllocation.vestingWeeks != 0) {
require(fromAllocation.vestingWeeks == toAllocation.vestingWeeks, "Vesting mismatch");
}
allocations[msg.sender].points = fromAllocation.points - points;
allocations[to].points = toAllocation.points + points;
// if `to` had no active vesting period, copy from `from`
if (toAllocation. vestingWeeks == 0) {
allocations[to].vestingWeeks = fromAllocation.vestingWeeks;
}
}
用戶可以將自己的積分轉(zhuǎn)移給自己(self-transfer),導(dǎo)致總積分超出限制,破壞合約中「所有用戶積分總和應(yīng)等于總分?jǐn)?shù)」的Invariant。然而就算我們不細(xì)看transferPoints的實(shí)作,也能透過對(duì)其黑箱的Fuzzing 來找到問題。
設(shè)計(jì)Invariant:思考不可變條件
在測(cè)試此合約時(shí),可以設(shè)計(jì)以下兩個(gè)主要Invariant:
- 初始化階段:所有用戶的積分總和應(yīng)等于TOTAL_POINTS。
- 執(zhí)行階段:在任意操作后,所有用戶的積分總和仍應(yīng)保持不變。
這些Invariant 可以被用于多個(gè)Fuzzer 的測(cè)試過程中。
使用Chimera 框架進(jìn)行測(cè)試
Chimera 是一個(gè)功能強(qiáng)大的多工具整合框架,允許開發(fā)者一次撰寫測(cè)試代碼,并同時(shí)在多個(gè)Fuzzer 工具上執(zhí)行。以下是使用Chimera 的步驟:
1、安裝Chimera:forge install Recon-Fuzz/chimera
2、設(shè)定測(cè)試環(huán)境:建立一個(gè)Setup.sol 文件來初始化測(cè)試合約,并追蹤需要檢查的狀態(tài)。
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.23;
import { Vesting } from "./Vesting.sol";
import { BaseSetup } from "@chimera/BaseSetup.sol";
abstract contract Setup is BaseSetup {
Vesting vesting;
function setup() internal override {
address;
recipients[0] = address(0x1111);
recipients[1] = address(0x2222);
uint24;
points[0] = 50_000;
points[1] = 50_000;
uint8;
vestingWeeks [0] = 10;
vestingWeeks[1] = 10;
vesting = new Vesting(recipients, points, vestingWeeks);
}
}
3、實(shí)現(xiàn)Invariant:定義檢查條件,例如所有用戶的積分總和應(yīng)等于總積分。
function property_users_points_sum_eq_total_points() public view returns(bool result) {
uint24 totalPoints;
// sum up all user points
for(uint256 i; i<recipients.length; i++) {
(uint24 points, , ) = vesting.allocations(recipients[i ]);
totalPoints += points;
}
// true if invariant held, false otherwise
if(totalPoints == TOTAL_POINTS) result = true;
}
4、定義如何測(cè)試目標(biāo)函數(shù):指定transferPoints 參數(shù)需滿足的條件,避免因錯(cuò)誤參數(shù)導(dǎo)致的Revert
function handler_transferPoints(uint256 fromIndex, uint256 toIndex, uint24 points) external {
fromIndex = bound(fromIndex, 0, recipients.length - 1);
toIndex = bound(toIndex, 0, recipients.length - 1);
address from = recipients[fromIndex ];
address to = recipients[toIndex];
points = uint24(bound(points, 1, vesting.allocations(from).points));
vesting.transferPoints(to, points);
}
5、執(zhí)行Fuzz Testing
forge test --match-contract VestingCryticToFoundry
可以看到Fuzzer 在短時(shí)間內(nèi)就找到了打破不變量的方法
修復(fù)漏洞
漏洞的解法是避免自我轉(zhuǎn)移:
function transferPoints(address to, uint24 points) external {
require(points != 0, "Zero points invalid");
require(msg.sender != to, "Self transfer invalid");
// ...
}
修復(fù)后再執(zhí)行一次測(cè)試即可通過了
Fuzz Testing for ZK Infrastructure
零知識(shí)基礎(chǔ)設(shè)施(Zero-Knowledge Infrastructure, ZK Infra)涉及編譯、執(zhí)行、生成證明與驗(yàn)證ZK 電路的多個(gè)核心軟體元件,對(duì)其進(jìn)行漏洞檢測(cè)至關(guān)重要。 Fuzz Testing 是檢測(cè)這些基礎(chǔ)設(shè)施漏洞的一項(xiàng)強(qiáng)大工具,尤其適合處理其高復(fù)雜性與高安全需求的特性。
基于黑箱測(cè)試的隨機(jī)變換與不變性檢測(cè)
零知識(shí)基礎(chǔ)設(shè)施的測(cè)試需要克服其內(nèi)部實(shí)現(xiàn)的高度復(fù)雜性,黑箱測(cè)試因此成為檢測(cè)漏洞的有效方法。在這種測(cè)試中,開發(fā)者將處理流程視作不可見的黑箱,僅根據(jù)輸入和輸出進(jìn)行分析。
首先,測(cè)試工具會(huì)隨機(jī)生成一個(gè)原始電路(C1),這些電路通常以小型DSL(特定領(lǐng)域語言)描述,用于模擬用戶操作。接著,應(yīng)用一系列隨機(jī)變換來生成新電路(C2)。這些變換包括乘以1、加減隨機(jī)表達(dá)式或其他等價(jià)操作,保證電路語義不變。隨后將兩個(gè)電路各自進(jìn)行ZK 工具的編譯處理,若在任何階段輸出或行為不一致,即可定位到處理流程的漏洞。
例如,一個(gè)表達(dá)式P 轉(zhuǎn)換為P × 1 − 0 時(shí),應(yīng)保持輸出一致,否則可能指向Witness Generator 或編譯器中的潛在問題。
持續(xù)且多元測(cè)試
由于零知識(shí)基礎(chǔ)設(shè)施經(jīng)常被用于Layer 2 協(xié)議,將乘載數(shù)億美金以上的價(jià)值,其安全性至關(guān)重要,因此持續(xù)測(cè)試顯得尤為必要。這可以通過自動(dòng)化測(cè)試工具來實(shí)現(xiàn),保證每次代碼更新后都能迅速發(fā)現(xiàn)潛在漏洞。
測(cè)試還需要支持多種零知識(shí)DSL,如Circum、Gnark 和Noir,確保適用于廣泛場(chǎng)景。同時(shí),F(xiàn)uzz Testing 工具應(yīng)具備自動(dòng)化反饋功能,能夠持續(xù)執(zhí)行并根據(jù)發(fā)現(xiàn)的問題進(jìn)行改進(jìn)。此外,測(cè)試生成的輸入應(yīng)盡量簡化,以便開發(fā)者快速理解并定位問題。
Part 6: Formal Verification
Formal Verification(形式化驗(yàn)證)是一種透過數(shù)學(xué)方式驗(yàn)證軟體是否符合特定Formal Spec(規(guī)格)的技術(shù)。對(duì)于智能合約而言,這種方法能有效檢查合約在所有可能狀態(tài)下的正確性。與Fuzz Testing(模糊測(cè)試)相比,F(xiàn)ormal Verification 的驗(yàn)證過程更為系統(tǒng)化,能夠覆蓋所有可能的狀態(tài)并「數(shù)學(xué)證明」合約邏輯的正確性。
然而,F(xiàn)ormal Verification 的實(shí)施通常需要嚴(yán)謹(jǐn)?shù)囊?guī)格定義,且計(jì)算成本較高。另一方面,F(xiàn)uzz Testing 則透過隨機(jī)輸入測(cè)試合約,具有輕量且能快速發(fā)現(xiàn)邊界問題的特性,但其測(cè)試范圍有限,可能無法檢測(cè)更深層的邏輯漏洞。
Certora
Certora 提供了一套完整的工具來彌補(bǔ)這些不足,幫助開發(fā)者在現(xiàn)實(shí)環(huán)境中應(yīng)用Formal Verification。其主要產(chǎn)品Certora Prover為智能合約提供了強(qiáng)大的驗(yàn)證框架,允許開發(fā)者定義規(guī)則并自動(dòng)化驗(yàn)證合約的邏輯正確性。
Certora 提供的工具旨在簡化智能合約的形式化驗(yàn)證過程,核心功能包括:
- Certora Prover:一個(gè)驗(yàn)證平臺(tái),允許開發(fā)者使用Certora Verification Language (CVL)定義規(guī)格并測(cè)試合約邏輯。
- 整合式框架:透過設(shè)定檔與腳本執(zhí)行驗(yàn)證。
- 詳細(xì)報(bào)告:自動(dòng)生成驗(yàn)證結(jié)果,包含失敗的詳細(xì)原因與對(duì)應(yīng)的測(cè)試輸入,協(xié)助快速定位問題。
使用Certora Prover 于有漏洞的投票合約
以下是一個(gè)簡單的投票合約,完整的程式碼可以在basic-presentation Repo 中找到。其中totalVotes 在每次投票后會(huì)被重置為1,這是一個(gè)邏輯錯(cuò)誤:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract Voting {
mapping(address => bool) public hasVoted;
uint256 public votesInFavor;
uint256 public votesAgainst;
uint256 public totalVotes;
function vote(bool isInFavor) external {
require (!hasVoted[msg.sender]);
hasVoted[msg.sender] = true;
totalVotes = 1; // BUG:每次投票后重置totalVotes
if (isInFavor) {
votesInFavor += 1;
} else {
votesAgainst += 1;
}
}
}
步驟1:撰寫規(guī)格
以下是一個(gè)簡單的規(guī)格,檢查totalVotes 是否在每次投票后遞增:
rule voteIntegrity(env e) {
uint256 votedBefore = totalVotes();
bool isInFavor;
vote(e, isInFavor);
assert (
totalVotes() > votedBefore,
"totalVotes 應(yīng)該在每次投票后遞增"
);
}
步驟2:設(shè)定config
使用以下.conf 檔案來設(shè)定驗(yàn)證細(xì)節(jié),包括要驗(yàn)證的合約與規(guī)范檔案。
{
"files": ["src/VotingBug.sol:Voting"],
"verify": "Voting:certora/specs/VotingBug.spec",
"msg": "驗(yàn)證totalVotes 遞增",
"server": "production"
}
步驟3:執(zhí)行驗(yàn)證
在專案根目錄執(zhí)行以下指令:
export CERTORAKEY=xxx
certoraRun certora/confs/VotingBug.conf
如果還沒有API Key,可以在官方網(wǎng)站注冊(cè)取得。輸出中會(huì)有一個(gè)Certora Prover 結(jié)果的連結(jié),點(diǎn)進(jìn)去即可看到Prover 找到了一個(gè)錯(cuò)誤,并提供詳細(xì)的輸入?yún)?shù)
步驟4:修復(fù)問題
修改合約邏輯以修復(fù)問題:
function vote(bool isInFavor) external {
require(!hasVoted[msg.sender]);
hasVoted[msg.sender] = true;
totalVotes += 1; // FIXED: 正確地累加totalVotes
if (isInFavor) {
votesInFavor += 1;
} else {
votesAgainst += 1;
}
}
步驟5:重新驗(yàn)證
再次執(zhí)行驗(yàn)證,確認(rèn)所有規(guī)范均已通過,代表此智能合約的正確性可被數(shù)學(xué)證明。
進(jìn)階功能:驗(yàn)證不變性(Inductive Invariants)
Certora 也支援定義不變量規(guī)則(Invariant Rules),確保合約在所有狀態(tài)下的邏輯一致性。例如:
invariant totalVotesIsSumInvariant()
votesInFavor() + votesAgainst() == to_mathint(totalVotes());
此規(guī)則驗(yàn)證totalVotes 永遠(yuǎn)等于贊成與反對(duì)票數(shù)的總和。
Part 7: Maximal Extractable Value (MEV)
在文章的前半部分中,我們已提到Intent Centric Design,其中介紹了CoW Swap 如何透過設(shè)計(jì)應(yīng)用層的邏輯來簡化跨鏈交易并提升用戶體驗(yàn)。在這一部分,我將深入探討CoW Swap 如何解決Maximal Extractable Value (MEV) 問題,以及其主張MEV 應(yīng)在應(yīng)用層解決的理念。同時(shí),我們也會(huì)介紹Unichain 如何通過可信執(zhí)行環(huán)境(TEE)在基礎(chǔ)設(shè)施層解決MEV 問題,呈現(xiàn)兩種截然不同但互補(bǔ)的解決方式。
CoW Swap 的MEV 解決方案
CoW Swap 的核心主張是,MEV 問題的根源在應(yīng)用層。目前約99% 的MEV 問題來自交易排序的競(jìng)爭(zhēng),而應(yīng)用層(例如去中心化交易所DEX)的設(shè)計(jì)是導(dǎo)致這些問題的主因。因此,MEV 問題應(yīng)該在設(shè)計(jì)應(yīng)用時(shí)一并考慮,而非依賴基礎(chǔ)設(shè)施層的迂回解決方案。
Coincidence of Wants(需求的巧合)
CoW Swap 引入需求巧合的概念,通過將多筆交易的需求聚合在一起,使交易者直接匹配需求,避免了流動(dòng)性池的中間操作,從而減少M(fèi)EV 攻擊的可能性。
案例:假設(shè)Alice 想用100 USDC 換取1 ETH,而Bob 剛好想用1 ETH 換取100 USDC。在傳統(tǒng)DEX 中,這些交易需要分別通過流動(dòng)性池進(jìn)行,可能會(huì)被套利者利用滑點(diǎn)進(jìn)行MEV 攻擊。而在CoW Swap 中,這兩筆交易可以直接匹配,無需經(jīng)過流動(dòng)性池,消除了滑點(diǎn)和MEV 攻擊。
Batch Auction(批次拍賣)
CoW Swap 的批次拍賣機(jī)制是其解決MEV 問題的核心手段:
- 收集交易意圖:在鏈下收集并聚合用戶的交易意圖。
- 批次處理:將在特定時(shí)間段內(nèi)收集的交易意圖組合成一個(gè)批次,這些批次通常每隔幾秒鐘產(chǎn)生一次。
- 競(jìng)價(jià)解決方案:通過競(jìng)標(biāo)機(jī)制選擇最佳的解決方案提供者(solver),這些提供者競(jìng)爭(zhēng)以提供最優(yōu)交易執(zhí)行方案,為用戶帶來最大的價(jià)格盈余。
- 統(tǒng)一清算價(jià)格:所有涉及相同資產(chǎn)的交易都以統(tǒng)一的清算價(jià)格結(jié)算,使交易順序變得無關(guān)緊要,從而減少M(fèi)EV 攻擊。
批次拍賣的優(yōu)勢(shì):
- MEV 保護(hù):批次拍賣透過統(tǒng)一清算價(jià)格,使交易順序的影響被弱化,顯著削減MEV 攻擊的空間。
- 資產(chǎn)匹配:直接點(diǎn)對(duì)點(diǎn)交換,無需觸及鏈上流動(dòng)性。
- 最佳價(jià)格保證:確保用戶交易的價(jià)格不低于在AMM 上直接獲得的價(jià)格。
實(shí)際案例:
假設(shè)有三位用戶的交易意圖:
- 用戶A 希望以100 DAI 購買ETH。
- 用戶B 希望以200 DAI 購買ETH。
- 用戶C 希望出售1 ETH,目標(biāo)獲得300 DAI。
這三筆訂單在批次拍賣中被組合在一起。由于A 和B 的購買需求總和(300 DAI)恰好匹配C 的出售需求(1 ETH),因此可以直接在用戶之間進(jìn)行點(diǎn)對(duì)點(diǎn)交換,無需觸及鏈上流動(dòng)性。這不僅提高了交易效率,還降低了交易成本,并消除了MEV 攻擊的風(fēng)險(xiǎn)。
Unichain 的MEV 解決方案
與CoW Swap 將MEV 處理集中在應(yīng)用層的設(shè)計(jì)不同,Unichain 選擇在基礎(chǔ)設(shè)施層通過可信執(zhí)行環(huán)境(TEE)來解決MEV 問題。 Unichain 是基于OP Stack 的Optimistic Rollup,其核心創(chuàng)新在于加密交易與TEE 排序,保證交易排序的透明與公平。
Unichain 解決MEV 的關(guān)鍵流程:
- 加密交易:使用者在發(fā)送交易時(shí),首先使用TEE 的公鑰加密交易內(nèi)容。因此,在mempool 中,所有節(jié)點(diǎn)看到的交易都是加密的,無法直接得知交易的細(xì)節(jié),自然也就無法通過交易排序提取MEV。
- TEE 排序:只有在TEE 環(huán)境內(nèi)才能解密交易并進(jìn)行排序。 TEE 會(huì)根據(jù)預(yù)設(shè)的規(guī)則排序交易并構(gòu)建區(qū)塊,最終生成的排序結(jié)果帶有TEE 的簽章,保證排序過程的透明度。
- 返還MEV 收益:對(duì)于普通用戶,Unichain 提供接近零成本的Gas 費(fèi),同時(shí)完全避免了被搶跑(front-run)的風(fēng)險(xiǎn)。而對(duì)于MEV Searcher,他們需要支付更高的Gas 費(fèi)來競(jìng)爭(zhēng)區(qū)塊的前位。這些額外的收益會(huì)被Unichain 用于回饋給驗(yàn)證者,形成公平的經(jīng)濟(jì)激勵(lì)。
Part 8: Zero Knowledge Proof (ZKP)
Zero Knowledge Proof (ZKP) 技術(shù)的應(yīng)用展示了如何透過密碼學(xué)方法,實(shí)現(xiàn)隱私保護(hù)與效能的平衡。以下將介紹幾個(gè)令我印象深刻的ZK 應(yīng)用。
ZKPassport
ZKPassport結(jié)合了國際電子護(hù)照(ePassport)的晶片技術(shù)與ZKP,為用戶提供一種既安全又隱私的身份驗(yàn)證方式。透過手機(jī)感應(yīng)護(hù)照的NFC,用戶可以取得護(hù)照晶片中由政府簽署的資料,例如基本資訊和照片。由于這基于全球標(biāo)準(zhǔn)(IC AO Biometric Passport),超過100 個(gè)國家的護(hù)照均可支援。基于此簽章即可生成護(hù)照資料有效性的零知識(shí)證明。
技術(shù)特點(diǎn)
- 隱私保護(hù):用戶可選擇只驗(yàn)證護(hù)照資料的部分條件,例如「年齡是否大于18 歲」或「國籍是否為美國」,而不需要公開完整的護(hù)照資訊。
- 效能佳:ZK 電路使用Noir 編寫,在手機(jī)上生成證明僅需約5 秒鐘
應(yīng)用場(chǎng)景
- Sybil Resistance:可用于防止多重身份詐·騙,例如確保一個(gè)人只能領(lǐng)取一次空投。
- ZK KYC (Know Your Customer):在不透露完整身份的情況下,證明用戶來自合法的國家或符合其他特定條件。
ZK Email
ZK Email是一個(gè)基于零知識(shí)證明的Email 驗(yàn)證應(yīng)用,允許用戶選擇性地驗(yàn)證郵件內(nèi)容。例如,證明Email 的發(fā)信人是否為特定組織、Email 內(nèi)文是否有特定文字,而無需公開整封郵件的內(nèi)容。關(guān)鍵是采用每個(gè)Email 都會(huì)由Mail Server 簽署的DKIM Signature,產(chǎn)生一封信是由該域名發(fā)出的零知識(shí)證明,且無法被偽造。
技術(shù)特點(diǎn)
- 將可信的Email 資料帶到鏈上驗(yàn)證,串連Web2 資料與Web3
- 新推出的ZK Email Registry:提供可共享的Email template Registry,開發(fā)者可快速使用。如有人收到Devcon 的拒絕信后,寫了一個(gè)讓任何人證明自己有收到拒絕信的template。
- 更方便的SDK:開發(fā)者僅需撰寫JSON 設(shè)定,而不需了解如何實(shí)作ZK 電路,并隱藏具體的ZK 電路實(shí)作,如Circom, Noir
應(yīng)用場(chǎng)景
- ZKP2P:透過點(diǎn)對(duì)點(diǎn)轉(zhuǎn)帳的確認(rèn)信,打造法幣與虛擬貨幣兌換的平臺(tái),且完全去中心化
- Email Wallet Guardian: Email 可作為智能合約錢包的備援手段。例如,用戶寄出一封Email 即可恢復(fù)錢包的控制權(quán)。此功能也能兼容ERC-7579 的模組化Smart Account 架構(gòu)。
- Whistleblowing:在保護(hù)個(gè)人身份隱私的前提下,以特定組織的身份揭發(fā)秘密
技術(shù)挑戰(zhàn)
- DKIM public key 的正確性:在智能合約中需驗(yàn)證DKIM Signature 對(duì)應(yīng)的Public Key 是否真正屬于該域名,而這目前只能透過Oracle 提供資料。需要透過像Re-staking 的機(jī)制來確保該資料足夠去中心化,避免單點(diǎn)故障
- 在處理較長的郵件時(shí),ZKP 的計(jì)算效能面臨挑戰(zhàn)。團(tuán)隊(duì)正在研究遞回證明(recursive proof)以支援更高效的body hash 驗(yàn)證。
- 未來可能支援Email 附件(例如PDF)內(nèi)容的證明,進(jìn)一步拓展應(yīng)用場(chǎng)景,如證明銀行的轉(zhuǎn)帳紀(jì)錄
- 手機(jī)用戶體驗(yàn):由于手機(jī)端無法像桌面端下載原始郵件,ZK Email 目前僅能透過OAuth 授權(quán)讀取郵件。雖然這引發(fā)一定的隱私顧慮,但ZK Email 的開源性確保了這些操作僅限于客戶端,不會(huì)回傳Email 資料到服務(wù)器。
ZKP2P
ZKP2P是一個(gè)基于零知識(shí)證明技術(shù)的域名交易市場(chǎng),旨在提供快速、安全、去中心化的域名交易體驗(yàn)。該平臺(tái)支持利用零知識(shí)證明驗(yàn)證域名所有權(quán),并使用ETH 進(jìn)行域名交易。目前ZKP2P 已支援使用者交易Namecheap 上的域名。
域名交易的核心機(jī)制
- 域名所有權(quán)驗(yàn)證:平臺(tái)使用一種基于密碼學(xué)的Web 認(rèn)證協(xié)議來驗(yàn)證域名的所有權(quán)。賣家需使用ZKP2P 提供的瀏覽器Extension,從Namecheap 網(wǎng)站生成不可篡改的域名所有權(quán)證明,并提交到智能合約中。
- 交易過程中的隱私保護(hù):買家在提交購買申請(qǐng)時(shí),需提供Namecheap 用戶名,該資訊會(huì)加密處理,僅賣家可見。
- 資金鎖定:買家的ETH 會(huì)先被鎖定在智能合約的托管中,直到賣家完成域名轉(zhuǎn)讓并提供相關(guān)的零知識(shí)證明后,資金才會(huì)釋放。
- 零知識(shí)證明的使用:賣家轉(zhuǎn)移域名后會(huì)收到Namecheap 的確認(rèn)信,因此ZKP2P 使用ZK Email 產(chǎn)生這封信的零知識(shí)證明,確保域名已轉(zhuǎn)移給買方。
技術(shù)特點(diǎn)與優(yōu)勢(shì)
- 隱私與安全性:ZKP2P 通過加密用戶敏感資訊(例如Namecheap 用戶名)來保護(hù)隱私,確保只有域名賣方能看到買方的用戶名。
- 去中心化與透明性:平臺(tái)所有的交易驗(yàn)證過程均在智能合約中執(zhí)行,減少對(duì)第三方的依賴,并提高整體透明度。
- 降低交易成本:每筆交易僅收取2.5% 的交易費(fèi)用,遠(yuǎn)低于其他域名交易市場(chǎng)(一般超過10%),讓買賣雙方都能享受更低的交易成本。
Polygon ZisK
Polygon 正在開發(fā)新一代的ZKVM 證明系統(tǒng)ZisK,目標(biāo)是實(shí)現(xiàn)即時(shí)證明整個(gè)EVM 區(qū)塊中所有交易的計(jì)算。 ZisK 的設(shè)計(jì)核心在于其通用性(Generic ZKVM)和極致的證明生成速度優(yōu)化,旨在提升零知識(shí)證明在區(qū)塊鏈應(yīng)用中的性能。
ZisK 的設(shè)計(jì)架構(gòu)
ZisK 的架構(gòu)受到嵌入式系統(tǒng)(Embedded System)的啟發(fā),采用了模組化的設(shè)計(jì),主要組件包括:
- ROM(只讀存儲(chǔ)器):儲(chǔ)存ZKVM 的程序邏輯和靜態(tài)數(shù)據(jù)。
- ZisK Processor(處理器):負(fù)責(zé)執(zhí)行電路的核心計(jì)算邏輯。
- RAM(隨機(jī)存取存儲(chǔ)器):用于儲(chǔ)存臨時(shí)數(shù)據(jù)和中間結(jié)果,支援高效的數(shù)據(jù)訪問。
- Bus(總線):負(fù)責(zé)連接ZisK 系統(tǒng)內(nèi)部的各模組,協(xié)調(diào)訊息交換。
目前,ZisK 還處于非常早期的開發(fā)階段,可參考其開發(fā)文件。
Reclaim Protocol
Reclaim Protocol 是一個(gè)將TLS Proxy 技術(shù)與零知識(shí)證明(Zero-Knowledge Proof, ZKP)相結(jié)合的隱私保護(hù)協(xié)議,旨在讓用戶能夠在不泄露敏感資訊的前提下,驗(yàn)證HTTPS 通訊內(nèi)容的真實(shí)性。該協(xié)議為資料驗(yàn)證與互操作性提供了安全的解決方案,尤其適用于Web2 和Web3 場(chǎng)景的整合。
TLS Proxy 機(jī)制
Reclaim Protocol 的核心依賴于TLS Proxy 作為信任中介。過程中HTTPS 請(qǐng)求和回應(yīng)會(huì)經(jīng)過TLS Proxy,并由Proxy 簽署該流量的加密內(nèi)容,從而為后續(xù)的證明生成提供基礎(chǔ)。 TLS Proxy 的角色僅限于簽署加密流量,無法解密任何資料,這也減少了隱私風(fēng)險(xiǎn)。
TLS Proxy 的一個(gè)重要功能是處理使用者和伺服器之間的HTTPS 流量,并保證這些流量來自正確的伺服器。例如,在證明某銀行網(wǎng)站的余額資訊時(shí),TLS Proxy 簽署的加密流量可以確保數(shù)據(jù)未被篡改,并提供可信的資料來源。
然而盡管TLS Proxy 提供了關(guān)鍵的信任保障,在極端網(wǎng)路條件下(例如BGP Hijack 攻擊),可能會(huì)出現(xiàn)Proxy 認(rèn)證的流量被路由到錯(cuò)誤伺服器的風(fēng)險(xiǎn)。這種攻擊需要在TLS Handshake 后精準(zhǔn)篡改流量,實(shí)現(xiàn)難度極高,但這仍是協(xié)議中需要特別關(guān)注的安全邊界。
zkTLS 技術(shù)細(xì)節(jié)
Reclaim Protocol 結(jié)合了ZKP 技術(shù),允許用戶在不泄露完整TLS 明文的前提下驗(yàn)證其真實(shí)性,其ZK 電路的設(shè)計(jì)旨在處理解密與部分揭露的功能。
協(xié)議中的ZK 電路能夠解密特定的TLS 流量,并僅揭露其中需要驗(yàn)證的部分資訊。例如,用戶可以提供AES 解密金鑰作為Private Input,在電路中解密TLS 流量,并公開指定區(qū)域的明文資訊。這些操作基于gnark 框架進(jìn)行,確保了高效的證明生成。
值得注意的是,Reclaim Protocol 提供了透過Regular Expression 或是HTML template 匹配TLS 流量的功能,而這一匹配邏輯被設(shè)計(jì)為在電路外實(shí)作,以避免電路過度復(fù)雜。因此客戶端需首先自行透過Template 定位哪些AES Block 中有包含所需的明文,再生成ZK 證明來證實(shí)匹配結(jié)果。這樣導(dǎo)致的資安風(fēng)險(xiǎn)是,如果TLS Payload 中在其他部分也出現(xiàn)了類似的字串,客戶端則有機(jī)會(huì)偽造證明。
應(yīng)用場(chǎng)景
Reclaim Protocol 目前將重點(diǎn)放在Web2 場(chǎng)景的資料互操作性上,解決不同平臺(tái)間的數(shù)據(jù)共享問題。例如:
- 電商優(yōu)惠:用戶可以從A 電商生成消費(fèi)記錄的ZKTLS 證明,并將其提供給B 電商以獲取專屬優(yōu)惠,精準(zhǔn)吸引新用戶。在這一過程中,協(xié)議可確保B 電商只能知道消費(fèi)總金額,而不會(huì)接觸完整的消費(fèi)明細(xì)。
- 身份驗(yàn)證:用戶可使用協(xié)議生成ZKTLS 證明,證明其在特定平臺(tái)的活動(dòng),如在某論壇的參與情況,或在某開發(fā)者平臺(tái)的貢獻(xiàn)數(shù)據(jù)。
技術(shù)與信任的挑戰(zhàn)
- 信任TLS Proxy:協(xié)議需要用戶信任TLS Proxy,因?yàn)镻roxy 會(huì)簽署HTTPS 流量,成為證明可信來源的基礎(chǔ)。
- ZK 證明的鏈上應(yīng)用:由于目前ZK 證明的鏈上驗(yàn)證成本較高,Reclaim Protocol 將應(yīng)用重點(diǎn)放在Web2 場(chǎng)景,尚未在鏈上進(jìn)行完整的ZK 驗(yàn)證。
- 網(wǎng)路攻擊風(fēng)險(xiǎn):極端情況下,如BGP Hijack,可能導(dǎo)致TLS Proxy 無法正常運(yùn)作,但這類攻擊需要精確的時(shí)間和網(wǎng)路控制,實(shí)現(xiàn)難度極高。
vLayer
Vlayer是一家專注于開發(fā)「可驗(yàn)證資料基礎(chǔ)設(shè)施」的加密初創(chuàng)公司,稱之為「Solidity 2.0」。其目標(biāo)是使開發(fā)者能夠?qū)⒄鎸?shí)世界的資料驗(yàn)證后整合至以太坊智能合約中。具體而言,Vlayer 為Solidity 語言引入了四個(gè)新功能:
- Time Travel:允許智能合約使用歷史鏈上資料。
- Teleport:使合約能在多個(gè)EVM 兼容的網(wǎng)絡(luò)上運(yùn)行。
- Web Proofs(zkTLS):驗(yàn)證并整合網(wǎng)頁內(nèi)容,包括API 和網(wǎng)站。
- Email Proofs(ZK Email):存取并驗(yàn)證電子郵件內(nèi)容。
這些功能旨在擴(kuò)展智能合約的應(yīng)用范圍,特別是在去中心化金融(DeFi)、真實(shí)世界資產(chǎn)(RWA)和游戲等領(lǐng)域。目前,Vlayer 正處于Alpha 階段,邀請(qǐng)開發(fā)者在其平臺(tái)上進(jìn)行開發(fā),并計(jì)劃于2025 年推出測(cè)試網(wǎng)、主網(wǎng)和代幣。
Mopro
Mopro(Mobile Prover)是一個(gè)專為Mobile 環(huán)境開發(fā)的ZK 證明生成工具,以簡化客戶端的證明過程。 Mopro 的主要特點(diǎn)包括:
- 易用性:簡化了在移動(dòng)應(yīng)用中整合ZK 證明的復(fù)雜性
- 高性能:比在瀏覽器上使用snarkjs 更快,并嘗試使用GPU 優(yōu)化性能
- 跨平臺(tái)兼容性:支援iOS、Android 平臺(tái)
然而,在Mobile 環(huán)境下仍存在一些挑戰(zhàn):
- GPU 加速的限制:雖然Mopro 嘗試?yán)肎PU 提升性能,但由于移動(dòng)設(shè)備使用的Metal API 不如桌面端CUDA 易于優(yōu)化,開發(fā)上面臨一定難度。然而,數(shù)據(jù)顯示在處理大型電路時(shí),Mopro 的性能表現(xiàn)有望優(yōu)于其他傳統(tǒng)工具。
- 記憶體限制:Mobile 設(shè)備的記憶體容量有限是主要挑戰(zhàn)之一,特別是在運(yùn)行復(fù)雜的ZK 電路(如ZK Email)時(shí),可能會(huì)因內(nèi)存不足導(dǎo)致應(yīng)用Crash
Part 9: Multi-Party Computation (MPC)
MPC是一種密碼學(xué)技術(shù),允許多方在不泄露各自輸入的情況下,共同計(jì)算一個(gè)函數(shù)的結(jié)果。其與ZK 的差別在于:
- MPC需要多方參與計(jì)算,且所有人都能隱藏輸入的內(nèi)容。
- ZK:僅需一方(Prover)生成證明,另一方(Verifier)驗(yàn)證其聲明是否正確,無需多方協(xié)作。因此Prover 需要知道所有計(jì)算過程的資料。 ZK 保障的是Single Player Privacy。
以下介紹幾個(gè)MPC 的應(yīng)用與最新研究,展示其在隱私保護(hù)與分布式計(jì)算中的潛力。
World ID
World ID是Worldcoin的核心技術(shù),旨在為每位用戶建立獨(dú)特的數(shù)位身份,用以證明個(gè)人的「唯一性」。注冊(cè)過程中,使用者需透過「虹膜掃描」驗(yàn)證身份,確保每人僅能注冊(cè)一次。這需要將新掃描的虹膜與已注冊(cè)的數(shù)據(jù)庫進(jìn)行比對(duì)。然而,大量集中存儲(chǔ)的真實(shí)虹膜數(shù)據(jù)可能帶來巨大的隱私風(fēng)險(xiǎn)。
為解決此問題,Worldcoin 與Taceo合作,探索基于MPC 的去中心化虹膜比對(duì)方案。
技術(shù)細(xì)節(jié)與流程
- 資料的Secret Sharing:用戶的虹膜掃描資料被拆分為三個(gè)Secret Share,分發(fā)給三個(gè)計(jì)算方,確保單一計(jì)算方無法取得完整的虹膜資料。
- Hamming 距離計(jì)算:透過內(nèi)積運(yùn)算將用戶的虹膜資料與資料庫中的虹膜逐一比對(duì),計(jì)算Hamming 距離并與設(shè)定的閾值進(jìn)行比較。整個(gè)過程在MPC 框架下執(zhí)行,確保數(shù)據(jù)隱私不被泄露。
- 結(jié)果聚合:將比對(duì)結(jié)果以邏輯OR 聚合,產(chǎn)生最終的驗(yàn)證結(jié)果,判斷虹膜的唯一性。
World ID 最大的技術(shù)挑戰(zhàn)在于計(jì)算成本高昂:Worldcoin 的使用者數(shù)已超過1,600 萬,每次唯一性驗(yàn)證需要針對(duì)龐大的數(shù)據(jù)庫進(jìn)行線性掃描。在GPU 加速環(huán)境下,一次驗(yàn)證需要32 臺(tái)NVIDIA H100 GPU,峰值網(wǎng)絡(luò)吞吐量達(dá)2.5 Tbps。
因此,Worldcoin 正積極探索計(jì)算資源需求更低但驗(yàn)證嚴(yán)謹(jǐn)度相對(duì)較低的替代方案,例如借鑒ZKPassport的護(hù)照唯一性證明機(jī)制,以在減少成本的同時(shí)保持足夠的驗(yàn)證可信度。
MPCStats
MPCStats是一個(gè)基于MPC 的開源框架,旨在實(shí)現(xiàn)多方參與的統(tǒng)計(jì)計(jì)算,同時(shí)保護(hù)數(shù)據(jù)隱私。該框架允許多個(gè)數(shù)據(jù)提供者匿名參與計(jì)算,結(jié)果公開但不泄露個(gè)人數(shù)據(jù)細(xì)節(jié)。
技術(shù)特點(diǎn)
- 隱私保護(hù):數(shù)據(jù)提供者的資料以秘密共享的方式進(jìn)行處理,并且在計(jì)算過程中保持加密。
- 整合TLS Notary:使用TLS Notary 確保輸入數(shù)據(jù)來自可信來源,避免「垃圾輸入」影響結(jié)果。
- 支持多種統(tǒng)計(jì)操作:包括平均值、中位數(shù)、吉尼系數(shù)等常見統(tǒng)計(jì)指標(biāo),以及數(shù)據(jù)篩選和Join Table 操作。
展場(chǎng)Demo
在Devcon 展會(huì)中,MPCStats 提供了一個(gè)Demo,讓參與者私密分享其Binance ETH 余額,計(jì)算平均值。數(shù)據(jù)的完整性由TLS Notary證明,最終生成可信且隱私保護(hù)的統(tǒng)計(jì)結(jié)果。
Public Auditable MPC
Public Auditable MPC(PAMPC)是一種結(jié)合MPC 和零知識(shí)證明(ZK)的新型協(xié)議,旨在解決現(xiàn)有MPC 系統(tǒng)中無法向第三方驗(yàn)證計(jì)算正確性的挑戰(zhàn)。該協(xié)議允許計(jì)算方在保護(hù)輸入隱私的同時(shí),向第三方公開驗(yàn)證計(jì)算結(jié)果的正確性。
核心概念與技術(shù)
- 引入Collaborative ZK-SNARKs:PAMPC 使用協(xié)作式ZK-SNARKs,將每個(gè)計(jì)算方生成的部分證明(proof)進(jìn)行線性聚合產(chǎn)生完整證明,確保計(jì)算的正確性可被第三方驗(yàn)證。
- 處理輸入一致性問題:在MPC 的預(yù)處理和在線階段中,透過對(duì)輸入數(shù)據(jù)進(jìn)行Commit,確保數(shù)據(jù)的一致性。
- 加速位元運(yùn)算:傳統(tǒng)的SPDZ MPC 協(xié)議對(duì)于加法和乘法支持良好,但在處理位元運(yùn)算時(shí)效率低下。 PAMPC 對(duì)SPDZ 進(jìn)行了優(yōu)化。
應(yīng)用場(chǎng)景與優(yōu)勢(shì)
- 電子投票:在保護(hù)選民隱私的同時(shí),提供公開驗(yàn)證機(jī)制,增強(qiáng)系統(tǒng)透明度同時(shí)保護(hù)隱私。
- 去中心化拍賣:確保拍賣結(jié)果的公正性,同時(shí)保護(hù)投標(biāo)者的隱私。
- 醫(yī)療數(shù)據(jù)與機(jī)器學(xué)習(xí):PAMPC 特別適合于需要多方共享敏感數(shù)據(jù)的場(chǎng)景,例如多機(jī)構(gòu)合作訓(xùn)練機(jī)器學(xué)習(xí)模型。各機(jī)構(gòu)可以保留數(shù)據(jù)隱私,同時(shí)協(xié)作完成模型訓(xùn)練或預(yù)測(cè)。
- 去中心化游戲:PAMPC 可被應(yīng)用于去中心化游戲中,如狼人殺(Werewolf/Mafia)游戲,通過MPC 確保角色分配、投票計(jì)算的隱私性與正確性,而不需要游戲主持者(GM) 。
Part 10: Programmable Cryptography
0xPARC 提出可程式化密碼學(xué)(Programmable Cryptography)概念,指出此技術(shù)是從「專用型密碼學(xué)」轉(zhuǎn)向「通用型密碼學(xué)」的世代革命。
過去,密碼學(xué)工具為特定用途而設(shè)計(jì),如RSA 加密、橢圓曲線簽章等等。當(dāng)人們需要新的功能,就必須發(fā)明新的密碼學(xué)協(xié)議來滿足需求,如Group Signature 協(xié)議可以讓個(gè)人代表一群人簽署資料,而不透露具體身份,這與RSA 加密演算法的設(shè)計(jì)有顯著差異。
相對(duì)而言,可程式化密碼學(xué)將密碼學(xué)設(shè)計(jì)的數(shù)學(xué)問題轉(zhuǎn)化為工程問題,允許開發(fā)者寫程式來實(shí)現(xiàn)任意密碼學(xué)操作。以下是一些重要技術(shù):
- 零知識(shí)證明(zkSNARKs):證明程式在私密輸入上的正確執(zhí)行,無需泄露輸入。
- 多方計(jì)算(MPC):在多方私密數(shù)據(jù)上進(jìn)行計(jì)算,僅揭示最終結(jié)果。
- 完全同態(tài)加密(FHE):允許在加密狀態(tài)下執(zhí)行任意運(yùn)算,運(yùn)算結(jié)果仍為加密狀態(tài)。
- 不可區(qū)分混淆(iO):將程式加密,讓程式可執(zhí)行但不可解析內(nèi)部邏輯,被譽(yù)為密碼學(xué)的「圣杯」,因其能構(gòu)建所有其他密碼學(xué)工具。
最理想的Internet
可程式化密碼學(xué)能幫助實(shí)現(xiàn)Internet 的理想狀態(tài),包括:
- 去中心化(P2P):恢復(fù)網(wǎng)路對(duì)等性,避免數(shù)據(jù)和計(jì)算集中化。
- 隱私保護(hù):讓數(shù)據(jù)擁有者控制其數(shù)據(jù)使用方式。
- 資料互操作性:不同應(yīng)用間數(shù)據(jù)能無縫流轉(zhuǎn)并保持真實(shí)性與隱私。
- 信任最小化與無需許可:用數(shù)學(xué)保證取代對(duì)中央機(jī)構(gòu)的信任,任何人均可參與。
例如,MPC 與FHE 技術(shù)讓伺服器在完全不了解用戶數(shù)據(jù)的前提下,完成計(jì)算任務(wù),同時(shí)確保計(jì)算結(jié)果的可驗(yàn)證性,這代表使用者資料將永遠(yuǎn)由自己掌控。
以下透過兩個(gè)例子解釋,為何有了可程式化密碼學(xué)后,能建構(gòu)理想的社交網(wǎng)路與投票應(yīng)用。
去中心化Facebook
過去當(dāng)人們思考去中心化社交網(wǎng)路時(shí),總是想先模仿Twitter,原因是Twitter 的機(jī)制較為單純:每個(gè)使用者可以公開發(fā)布內(nèi)容,任何人都能看到其他人的內(nèi)容。然而相較于去中心化Twitter,去中心化Facebook 的實(shí)現(xiàn)更加復(fù)雜,因其數(shù)據(jù)拓?fù)浜碗[私要求更高:
- 隱私設(shè)置:用戶可能只想讓特定好友查看特定內(nèi)容。
- 朋友的朋友權(quán)限:需動(dòng)態(tài)計(jì)算貼文可見性范圍。
- 推薦演算法(News Feed):需要整合多方數(shù)據(jù)進(jìn)行運(yùn)算。
此外,這些應(yīng)用需要處理隱私的全域狀態(tài)(Private Global State),例如推薦演算法的參數(shù)可能無任何單一方知曉,但系統(tǒng)仍需保證其正確運(yùn)行。這些挑戰(zhàn)只能透過可程式化密碼學(xué)解決。
投票系統(tǒng)的技術(shù)演進(jìn)
投票是個(gè)很好的案例,因?yàn)樗枰瑫r(shí)滿足許多特性,才能做到公平、隱私且公正。在加入不同的可程式化密碼學(xué)技術(shù)后,能一步步朝向理想的投票系統(tǒng)邁進(jìn):
- 將投票上鏈:將提供公開可驗(yàn)證的投票結(jié)果,以及實(shí)現(xiàn)抗審查的投票過程。
- 加入零知識(shí)證明(ZK):讓投票者可隱藏投票內(nèi)容,保護(hù)隱私。
- 加入MACI (Minimal Anti-Collusion Infrastructure) 機(jī)制:可在計(jì)票方不泄漏資訊的前提防止賄選,因?yàn)橥镀闭邔o法證明自己投票給誰。
- 加入全同態(tài)加密(FHE):進(jìn)一步將需信任的參與方擴(kuò)展為M-of-N 模型,只要M 方中有N 個(gè)參與方是誠實(shí)的,就沒有人知道誰投票給誰。另一方面可輕易更換投票系統(tǒng)邏輯(如平方投票法)。
- 加入不可區(qū)分混淆(iO):將計(jì)票程式經(jīng)過混淆處理,確保就算所有人共謀也都無法知道投票運(yùn)算細(xì)節(jié)。
ZuPass
ZuPass是由0xPARC 推出的一個(gè)實(shí)驗(yàn)性應(yīng)用,基于可程式化密碼學(xué)(Programmable Cryptography)的概念設(shè)計(jì),旨在幫助使用者實(shí)現(xiàn)對(duì)自身資料的自主管理與跨平臺(tái)互操作性。 ZuPass 的核心是Proof-Carrying Data (PCD),使用者可以在保護(hù)隱私的前提下安全儲(chǔ)存并證明其數(shù)據(jù)的有效性。
以下介紹幾個(gè)在本次Devcon 會(huì)場(chǎng)的ZuPass 應(yīng)用。使用ZuPass 的應(yīng)用又被稱為ZApp
Devcon 門票驗(yàn)證
ZuPass 在Devcon 活動(dòng)中被用來驗(yàn)證與會(huì)者身份,其原理如下:
- 使用者的Devcon 票券以PCD 的形式存入ZuPass。
- 當(dāng)需要進(jìn)場(chǎng)時(shí),使用者可透過ZuPass 生成零知識(shí)證明(Zero-Knowledge Proofs, ZK Proof),證明自己持有有效票券而無需透露身份細(xì)節(jié)。
- 此外,還能用于基于身份的Telegram 群組驗(yàn)證,確保只有符合條件的成員可以加入特定群組。
Frog Crypto
Frog Crypto 是一個(gè)基于ZuPass 的有趣應(yīng)用,讓參與者在展場(chǎng)中搜集各種類型的青蛙,并生成證明來展示自己擁有的青蛙。其特色在于
- 資料自主 權(quán):參加者完全掌握自己的青蛙數(shù)據(jù)。
- 互操作性:開發(fā)者可以基于使用者擁有的青蛙資料創(chuàng)建新應(yīng)用,例如允許使用者將兩只青蛙合成為新的青蛙。這與傳統(tǒng)Web2 生態(tài)的封閉API 截然不同,使用者和開發(fā)者不再受限于中心化平臺(tái)的規(guī)則與改動(dòng)。
Meerkat
Meerkat是促進(jìn)講者與聽眾互動(dòng)的ZApp,結(jié)合了Slido 問答功能與ZK 技術(shù),實(shí)現(xiàn)匿名互動(dòng)。其功能包括:
- 即時(shí)發(fā)起問答或投票,講者和聽眾能在保護(hù)隱私的同時(shí)提升互動(dòng)性。
- 使用者可透過ZuPass 登入并生成互動(dòng)所需的證明,而無需暴露個(gè)人資訊。
ZuPass 的整合方式
ZuPass 提供方便整合的SDK,達(dá)成類似Google OAuth 的方便整合SDK:
- 用戶授權(quán):應(yīng)用整合ZuPass 后,會(huì)跳出ZuPass 彈窗供使用者登入并選擇授權(quán)哪些資料的讀寫權(quán)限。
- 資料請(qǐng)求與驗(yàn)證:授權(quán)后,應(yīng)用可向ZuPass 請(qǐng)求特定資料的證明,或?qū)?yīng)用程式中記錄的數(shù)據(jù)進(jìn)行讀寫操作。
POD 與GPC 技術(shù)
ZuPass 建立在兩個(gè)關(guān)鍵技術(shù)之上:Provable Object Data (POD)與General Purpose Circuit (GPC)。這兩項(xiàng)技術(shù)支撐了像是Meerkat、Frog Crypto 和Devcon 門票驗(yàn)證等應(yīng)用,實(shí)現(xiàn)了數(shù)據(jù)的隱私驗(yàn)證與互操作性。
POD 是一種以密碼學(xué)為核心的數(shù)據(jù)格式,專為零知識(shí)證明設(shè)計(jì)。 GPC 則是一種模組化電路,能根據(jù)POD 的結(jié)構(gòu)生成靈活且高效的ZK 證明。
POD 的設(shè)計(jì)與技術(shù)基礎(chǔ)
- Merkle Tree 結(jié)構(gòu):每個(gè)POD 都是一個(gè)扁平的key-value 鍵值對(duì)結(jié)構(gòu),透過Merkle Tree 壓縮成一個(gè)唯一的Content ID,用于標(biāo)識(shí)數(shù)據(jù)的完整性與來源。
- 簽名與驗(yàn)證:POD 的Content ID 由發(fā)行者使用ECDSA 簽名。
- 零知識(shí)證明友好性:采用ZK-friendly 的Poseidon Hash 函數(shù)與模組化數(shù)據(jù)格式,以加速生產(chǎn)POD 的零知識(shí)證明
GPC 的模組化電路設(shè)計(jì)
GPC 是針對(duì)POD 設(shè)計(jì)的通用電路,只需單一電路即可產(chǎn)生基于POD 靈活的零知識(shí)證明。其設(shè)計(jì)基于模組化架構(gòu),包含:
- Object Module:驗(yàn)證POD 的Content ID 與簽名的一致性。
- Entry Module:檢查POD 內(nèi)容的Merkle Proof。
- Numeric Value Module:進(jìn)行數(shù)值比較與范圍檢查。
- Membership Module:驗(yàn)證欄位是否在指定列表中。
POD 的不足與挑戰(zhàn)
盡管POD 系統(tǒng)具有靈活性與隱私保護(hù)能力,但其仍存在以下限制:
- 單用戶技術(shù)(Single Player Technology):POD 的設(shè)計(jì)限制了其只能由用戶本人生成與證明,無法支持隱私保護(hù)的多用戶協(xié)作運(yùn)算。
- 無法遞回證明:POD 生成的證明僅能被驗(yàn)證,而不能用于生成基于該證明的進(jìn)一步證明,限制了其應(yīng)用深度。
- 與現(xiàn)有系統(tǒng)不兼容:資料生產(chǎn)方需要調(diào)整系統(tǒng)來生成具簽名的POD,無法直接應(yīng)用于現(xiàn)有的Web2 資料。
POD 2 的誕生與改進(jìn)
為了解決POD 1 的缺陷,POD 2 系統(tǒng)應(yīng)運(yùn)而生,其引入了「Proof-Carrying Data (PCD)」的概念,使所有數(shù)據(jù)都帶有可驗(yàn)證的證明,并支援多方運(yùn)算:
- 支援多用戶隱私協(xié)作:POD 2 引入了多方計(jì)算(Multi-Party Computation, MPC),允許多方基于隱私POD 數(shù)據(jù)進(jìn)行聯(lián)合運(yùn)算并生成新POD。例如,兩位用戶可共同計(jì)算某條件是否成立,而無需泄露各自的數(shù)據(jù)細(xì)節(jié)。
- 遞回證明與計(jì)算:POD 2 的證明支持遞回計(jì)算,允許生成基于現(xiàn)有證明的新證明,構(gòu)建深度計(jì)算圖。
并且POD 2 框架支援開發(fā)者將任意的Web2 資料轉(zhuǎn)換為POD 格式,以解決POD 與既有系統(tǒng)不兼容的問題,稱為「Universal Data Adapter」。例如開發(fā)者可將來自ZK Email、TLSNotary 等Web2 系統(tǒng)的資料轉(zhuǎn)換為POD 格式的Proof Carrying Data,讓所有系統(tǒng)的資料產(chǎn)生互通性,實(shí)現(xiàn)不同系統(tǒng)間的無縫整合。最大的好處在于完全不需修改既有Web2 系統(tǒng)的資料產(chǎn)生邏輯。
POD 2 的技術(shù)挑戰(zhàn)在于,需依賴于多方全同態(tài)加密(Multi-Party Fully Homomorphic Encryption, MP-FHE)實(shí)現(xiàn)多個(gè)POD 2 之間的共同隱私運(yùn)算。
PEX 語言
0xPARC 也發(fā)明了類似Lisp 的PEX 語言,用于描述POD 2 的數(shù)據(jù)結(jié)構(gòu)與條件:
[createpod id-card
age 26
zip-code 12001
id 1847202750
]
[> age 18]
提供簡潔且直觀的語法,使開發(fā)者能快速建立基于POD 的應(yīng)用。
Frog Zone 游戲
Frog Zone 是0xPARC 在Devcon 展示的技術(shù)游戲,旨在實(shí)踐最尖端密碼學(xué)應(yīng)用,展示全同態(tài)加密(Fully Homomorphic Encryption, FHE)和多方計(jì)算(Multi-Party Computation, MPC)技術(shù)如何結(jié)合,創(chuàng)造出具隱私保護(hù)和分布式特性的應(yīng)用環(huán)境。這款游戲作為首個(gè)多用戶MP-FHE 應(yīng)用,為分布式隱私計(jì)算和應(yīng)用開發(fā)提供了重要的技術(shù)示范。
游戲玩法
- 玩家數(shù)量:最多支持4 位玩家同時(shí)參與。
- 可見范圍:每名玩家只能觀察自己周圍5x5 方格內(nèi)的地圖,一開始玩家互相看不見。
- 地圖大小:32x32 格子,其中包含怪物、地形障礙以及裝備等互動(dòng)元素。
- 玩家可選擇移動(dòng)、攻擊怪物或撿取裝備,提升自己的攻擊力與防御力。
- 游戲中的怪物會(huì)隨機(jī)移動(dòng),增加挑戰(zhàn)性和游戲趣味性。
- 玩家需在探索地圖的同時(shí)攻擊怪物,以爭(zhēng)取獲得最高分?jǐn)?shù)。
技術(shù)核心:Multi-Party Fully Homomorphic Encryption
- FHE 是一種允許在加密數(shù)據(jù)上直接進(jìn)行計(jì)算的密碼學(xué)技術(shù)。運(yùn)算結(jié)果仍保持加密狀態(tài),只有持有解密密鑰的一方可以獲取結(jié)果。核心特性是「可計(jì)算性與隱私性共存」。
- 將FHE 與MPC 結(jié)合可以將FHE 的能力擴(kuò)展到多方環(huán)境,使多名參與者可以在共享的加密狀態(tài)上進(jìn)行協(xié)作計(jì)算。在Frog Zone 游戲中,每名參與者持有部分加密狀態(tài)的分片,并通過MPC 協(xié)議協(xié)同完成伺服器功能的模擬。
- 整個(gè)游戲的狀態(tài)是由四臺(tái)使用者的機(jī)器,加上五臺(tái)在AWS 云端的機(jī)器共同維護(hù)與計(jì)算,沒有任何一臺(tái)機(jī)器能解密出完整的游戲狀態(tài)。由于是九臺(tái)機(jī)器一起運(yùn)算游戲狀態(tài),就像產(chǎn)生了共同的「幻覺」,也因此這個(gè)運(yùn)算過程被稱為Hallucinated Server
- 每次玩家發(fā)出移動(dòng)或攻擊指令時(shí),該指令以加密形式發(fā)送至伺服器。伺服器在加密環(huán)境中執(zhí)行狀態(tài)轉(zhuǎn)換函數(shù),生成新的加密游戲狀態(tài)。
- 完成操作后玩家請(qǐng)求可見范圍(5x5)的加密數(shù)據(jù),并通過多方協(xié)作解密獲取結(jié)果。
技術(shù)挑戰(zhàn)與限制
- 運(yùn)算成本高昂:每個(gè)二進(jìn)制邏輯門的運(yùn)算耗時(shí)約10 毫秒,比傳統(tǒng)計(jì)算慢10 億倍,而且每1 bit 明文需要約3,000 bit 的加密資料表示。 Frog Zone 動(dòng)用5 臺(tái)AWS 最高規(guī)格的192 Core CPU 的機(jī)器,每小時(shí)花費(fèi)200 美金,但每個(gè)玩家只能每四秒操作一次。
- 開發(fā)模式的轉(zhuǎn)變:MP-FHE 僅支持電路模型,而非傳統(tǒng)記憶體模型,開發(fā)過程中需要平行模擬所有可能的操作分支。例如,當(dāng)玩家嘗試移動(dòng)時(shí),伺服器需同時(shí)計(jì)算所有可能的移動(dòng)結(jié)果并選擇正確的分支。若要使用記憶體模型,需使用Oblivious RAM 以確保隱私地存取記憶體內(nèi)容
- 多方解密的頻寬成本:每次玩家請(qǐng)求5x5 可見范圍內(nèi)容時(shí),需由四臺(tái)本地客戶端協(xié)同解密,導(dǎo)致解密過程高度依賴多方同步,對(duì)網(wǎng)路頻寬要求極高。
未來展望
Frog Zone 展示了利用全同態(tài)加密和多方計(jì)算技術(shù)實(shí)現(xiàn)隱私保護(hù)和去中心化應(yīng)用的可能性。雖然當(dāng)前技術(shù)仍面臨性能和開發(fā)難度的挑戰(zhàn),但這就如同1960 年代的電腦,雖然龐大且效率低下,卻是開創(chuàng)現(xiàn)代計(jì)算時(shí)代的起點(diǎn)。 Frog Zone 的意義在于,它象征了Programmable Cryptography 的雛形,為未來理想化的網(wǎng)際網(wǎng)路鋪平了道路。
隨著Programmable Cryptography 技術(shù)的發(fā)展,未來的網(wǎng)際網(wǎng)路將實(shí)現(xiàn)去中心化、自主性和隱私保護(hù)的目標(biāo),建立一個(gè)真正屬于用戶的數(shù)位世界。這個(gè)世界將帶來更安全、透明且自由的數(shù)位生活,每個(gè)人都將能完全掌控自己的資產(chǎn)、資料與身份。
你可能感興趣的文章
-
以太坊和Solana哪家ZK技術(shù)更強(qiáng)?哪家更值得投資?
我們將探討不同網(wǎng)絡(luò)如何應(yīng)對(duì)這些挑戰(zhàn),特別是比較以太坊上的 zk Rollups 和 Solana 上的 zk Compression,這兩種技術(shù)都旨在提升可擴(kuò)展性,但它們通過不同的方式實(shí)現(xiàn)這一目標(biāo)…
2024-07-02 -
以太坊 VS Solana,哪家ZK技術(shù)更強(qiáng)?
區(qū)塊鏈技術(shù)的可擴(kuò)展性和效率問題得以通過引入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ù)是近年來備受矚目的新興技術(shù),而以太坊區(qū)塊鏈作為其中的之一,更是備受關(guān)注,但對(duì)于普通人來說,了解和掌握這項(xiàng)技術(shù)并不容易,好在現(xiàn)在有了以太坊區(qū)塊鏈中文瀏覽器…
2023-08-11 -
個(gè)人電腦怎么挖以太坊?以太坊電腦挖礦詳細(xì)圖解教程
這篇文章主要介紹了個(gè)人電腦怎么挖以太坊?以太坊電腦挖礦詳細(xì)圖解教程,以太坊在幣圈是僅次比特幣的數(shù)字貨幣,以太坊的獲取方式除了直接市面上購買之外,就是挖礦獲得,下…
2021-05-12 -
比特幣以太坊哪個(gè)更適合投資?礦工為何要挖礦?
這篇文章主要介紹了比特幣以太坊哪個(gè)更適合投資?礦工為何要挖礦?本文通過對(duì)以太坊的意思理解,分析以太坊的行情,并結(jié)合以太坊和比特幣的優(yōu)缺點(diǎn)比較,相信投資者看完內(nèi)容后…
2021-04-27 -
2021最具潛力百倍數(shù)字貨幣DCR幣種前十匯總
這篇文章主要介紹了2021最具潛力百倍數(shù)字貨幣DCR幣種前十匯總,對(duì)于投資者來說,找到具有潛力的百倍數(shù)字貨幣就非常重要了,那么,2021最具潛力百倍數(shù)字貨幣前十有哪些呢?…
2021-04-25 -
以太坊/ETH永續(xù)合約一般做多少倍杠桿?
這篇文章主要介紹了以太坊/ETH永續(xù)合約一般做多少倍杠桿?說到杠桿有哪些,投資者聽的最多的應(yīng)該就是5倍和100倍,其實(shí)除了這兩種之外,還有很多其他倍數(shù),那么,以太坊/ETH…
2021-04-09 -
以太坊是什么?以太坊開發(fā)入門指南
這篇文章主要介紹了以太坊是什么?以太坊開發(fā)入門指南,很多同學(xué)已經(jīng)躍躍欲試投入到區(qū)塊鏈開發(fā)隊(duì)伍當(dāng)中來,可是又感覺無從下手,本文將基于以太坊平臺(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)門檻把很多人拒絕在門外。這里小編整理了些領(lǐng)取渠道,讓大家…
2021-03-30