经过十天在Devcon7与Sideevents的密集学习，我想透过这篇文章浓缩我的所学，并总结几个关键主题，让更多人了解以太坊生态在各个技术面向上的最前沿发展、正在解决的问题，以及未来可达到的理想状态。本文章将涵盖以下主题：
除了Devcon主场馆的演讲与体验活动，我个人更喜欢参加特定主题的sideevents。这些活动不仅能深入学习相关领域的知识，还能遇到志同道合的专家进行交流。例如在一场关于zkTLS的活动中，我有机会直接向项目方请教文件中不太理解的部分，这段经历让我印象深刻。未来若有类似的大型研讨会，我也强烈建议大家多参加与自己兴趣相符的sideevents。
以下正文开始。
以下将从成就、现况与未来三个面向，详细阐述以太坊如何透过技术创新解决当前挑战，并为未来的扩容与去中心化铺路。
成就：手续费降低与一流的稳定性
今年的坎昆升级带来了前所未有的成本优化。得益于EIP-4844引入的DAS技术（DataAvailabilitySampling）与Blob机制，L2现在可以以更低的成本将更多资料储存到以太坊主网，使每笔交易的费用降至不到$0.01美金，让L2的使用更加经济实惠
以太坊的ClientDiversity是其稳定性的重要基石。运行以太坊节点的程式（Client）有多套选择，例如Geth、Nethermind和Reth，每套程式的开发团队分布于不同地区，程式码基础也完全独立。知名的执行层Client就有Geth,Nethermind,Reth等等。
以太坊算是目前在ClientDiversity上做得最好的公链。
以太坊的TransactionInclusion（交易纳入）能力相较两年前有了很大进步。如今，绝大多数交易可在6~30秒内完成确认，避免了过去常见的交易延迟数分钟甚至被节点丢弃的问题，为用户带来更稳定的交易体验。
现况：Rollup的挑战与安全性
自2020年Vitalik确立了以太坊的RollupCentric扩容路线图以来，整个生态系已经诞生了数百条L2链。在这一架构下，L1作为基础设施的角色，提供高度稳定、安全且可信中立的保障，而L2则像GPU一样，针对特定应用进行加速，显著提升每秒交易次数。然而随着L2的快速增长，也暴露了一些挑战。
目前许多L2项目仍基于强信任假设，某些L2项目方甚至拥有冻结用户资金或停止整条链运作的权力。为了更清楚地衡量L2的安全性，业界将其分为三个阶段：
在这三个阶段中，最大的差异在于「项目方做坏事的难度」。在Stage0，项目方完全掌控，几乎没有任何限制。Stage1引入了证明系统与治理机制，尽管攻击者可能通过贿赂SecurityCouncil成员等方式发起攻击，但成功的难度已显著提高。而Stage2则彻底消除人为干预的可能性，实现了理想的去中心化。
目前，大多数L2项目仍处于Stage0或Stage1。虽然这些项目标榜去中心化，但实际安全性与项目方的宣传往往存在差距。专注于L2安全分析的网站l2beat提供了最新且详细的报告，帮助用户了解项目方的真实安全实现是否达标。他们的研究深入程式码层面，揭露了许多项目过于依赖行销术语而忽视技术实现的现象。
L2必须具备一项关键功能，即EscapeHatch（逃生舱）机制，来应对项目方的Operator或Sequencer停止运作时的突发情况。这项机制允许用户生成自己在L2上持有资金的证明，并将该证明提交到L1的治理智能合约以赎回资金。整个过程必须在没有项目方介入的情况下完成，才能充分体现L2的安全性。
例如dydx发行的L2在这方面表现出色。当他们的L2决定停止营运时，提供了工具让用户自行将资金转回L1，确保了用户资金的安全。
为了应对未来可能的大量L2逃生交易，L1必须持续扩容。然而，Vitalik多次强调，在扩容过程中，不能为了短期内的大幅扩容而妥协去中心化。一旦去中心化特性被牺牲，将难以挽回。这种坚守是以太坊作为可信中立基础设施的核心价值。
以太坊在未来将迎来多方面的技术革新，从L2的进一步去中心化，到L1的性能优化，乃至于共识层的全面重写，这些计划都旨在推动以太坊迈向更加高效、安全且去中心化的区块链生态。
L2的发展方向之一是推动更多项目迈向Stage2，这是去中心化与安全性的理想平衡点。Vitalik明确表示，未来他只会将达到Stage1的Rollup称为Rollup，而未能进一步迈向Stage2的项目，将难以满足以太坊的长期愿景。在Stage2，L2将依赖双重证明系统，并将控制权完全交由智能合约处理，进一步降低对人为干预的依赖。
未来的目标是让更多人能轻松参与以太坊节点的验证。这包括：
这些措施旨在提升以太坊网路的去中心化程度，确保其稳定性与长期可持续发展。
目前L1每个区块的Blob数量与大小存在限制，导致L2在现阶段的理论TPS（每秒交易次数）仅达几千笔。然而，未来希望通过扩展Blob机制，如引入PeerDAS技术，实现每秒十万笔交易的目标。这将大幅提升以太坊的可扩展性，为高频交易应用场景铺平道路。
以太坊的共识层将迎来一项重大改变，即BeamChain的引入。这是Justin提出的对现有BeaconChain的全面重写，旨在解决当前最棘手的问题，并迈向以太坊的终极目标（EndGame）。主要的改进方向包括：
图中绿色的项目可以透过对共识层渐进式的改动完成，然而红色项目最为棘手，需要重写核心程式码，BeamChain因而被提出作为解决方案。
BeamChain的引入需要对核心程式码进行全面重写，不仅能解决现有技术债，还能从过去的经验中汲取教训。根据初版BeamChainRoadmap，整个升级计划将分为三个阶段：
这体现了以太坊对去中心化的坚守以及对安全性的极高要求，毕竟整个网路承载了数千亿美元的资金，任何小差错都可能导致灾难性后果。然而，也有许多社区成员批评五年的时间表过于冗长，期待能加速进度。Justin表示，这其中的确存在优化空间，他也希望更多人参与讨论与实作，共同推动这一计划的实现。
需要注意的是，BeamChain并非以太坊未来五年的唯一重点。在共识层进行升级的同时，执行层的改进（例如透过PeerDAS提高TPS）将持续推进，为应用开发者与用户提供更高效能与更流畅的体验。
随着ERC-4337帐户抽象标准的定案与上线，各式各样的SmartWallet（智能钱包）应运而生，大幅提升了使用者的体验与易用性。然而，这些创新同时也对钱包和DApp带来了新的技术挑战。另一方面，随着L2的蓬勃发展，资产碎片化问题日益显著，许多协议与应用开始朝向IntentCentricDesign和ChainAbstraction的方向发展，力求解决这些问题，让使用者能更快速完成复杂的跨链交易，并将相关细节隐藏于背后。以下将逐一探讨这些技术。
ERC-4337标准让智能合约钱包日益普及，其中最具特色的一类便是Passkey钱包。使用者只需透过生物认证即可创建Passkey，并将其作为钱包的私钥进行签名。每次发送交易时，使用者只需再次进行生物认证，完全不需要记忆或保存助记词，这被许多人视为钱包的「终极体验」。
Passkey钱包的核心在于智能合约中如何验证Passkey的签章。Passkey签章使用的是secp256r1椭圆曲线（又称P-256签章），而以太坊原生支持的是secp256k1。两者虽然只在椭圆曲线的参数上有所差异，但带来了巨大的Gas成本差距：
为了解决这一问题，RIP-7212提案被提出，旨在降低验证Passkey签章的成本。通过该提案后，Gas成本有望降至约3000，与secp256k1签章验证相当，从而显著减轻用户负担。
即使在成本降低的前提下，Passkey钱包仍面临以下几个技术挑战：
这些挑战让部分人质疑Passkey作为钱包私钥的适用性，认为其设计初衷是用于Web2登入场景，对于Passkey丢失风险的影响较小，随时都能透过「忘记密码」功能找回帐号，而且不需展示具体签名内容。但这不代表Passkey无法成为钱包的一部分，未来的钱包设计或许可以借鉴Web2，提供多种验证与帐号恢复选项，并依需求设置不同权限。
除了Passkey，ZKEmail团队提出了一种基于Email还原钱包控制权的机制。使用者可以将指定Email地址设为合约钱包的「监护人」（Guardian）。当私钥丢失时，用户只需从该Email发送一封信，包含合约钱包地址及新控制地址等资讯，即可生成ZK证明，在链上验证后取回钱包控制权。这一设计基于多年发展的Email基础设施，安全性高且操作便捷，有效减少了私钥丢失带来的风险。
随着Passkey和ZKEmail等机制的应用，ERC-4337钱包面临着显著的互操作性挑战。例如，当使用者在A钱包中建立了ERC-4337合约钱包，若希望汇出至B钱包使用，可能因两者使用的AccountFactoryContract不同而无法相容。这导致：
为了解决这一问题，业界提出了模组化合约钱包标准，例如ERC-7579和ERC-6900。这些标准将ERC-4337的功能进一步模组化，例如：
这样的设计允许所有钱包应用共用同一个AccountFactoryContract，并能够灵活组合不同模组，极大提升互操作性，减少资产管理的摩擦成本。
EIP-7702（SetEOACode）是下一代帐户抽象标准，预计将在下一次以太坊Pectra硬分岔中被纳入。这项提案的初衷在于解决ERC-4337的一个关键限制：使用者需要创建新的智能合约钱包，无法延续过去的EOA（ExternallyOwnedAccount）。EIP-7702则提供了一个全新解法，允许任何EOA地址「升级」为智能合约钱包，带来多样化的灵活功能：
Ithaca团队在EXP-0001中展示了EIP-7702的Demo，让使用者可以一键创建Passkey并将EOA地址的权限代理给该Passkey。此后，所有交易只需Passkey签名即可完成，且已在测试网中部署了RIP-7212（Passkey签章优化）的实作，显著降低了Gas成本。借助这一技术，EOA可透过单一Passkey签章执行多笔交易，进一步提升使用者的便利性。
EIP-7702的核心在于如何将EOA地址绑定智能合约逻辑，其具体流程如下：
虽然EIP-7702的功能十分强大，但也带来了一些新的安全风险：
EIP-7702的设计中，签章包含AccountNonce，这代表若不同链上的地址nonce不同，签章将无效。这一设计可以让钱包App通过一个签章升级用户的地址至所有链上的合约钱包，提升便利性。然而开发者在设计时需谨慎处理nonce机制，避免出现不必要的安全漏洞。
至于可能会授权恶意合约的问题，钱包App可采取以下措施：
EIP-7702的核心优势在于支持将现有的EOA升级为智能合约钱包。然而，这也带来一个限制：EOA的私钥始终拥有最高权限。如果私钥泄漏，将直接导致钱包的控制权丧失。而ERC-4337可以实现多签钱包等无需依赖单一私钥的设计，提供更高的安全性。因此，EIP-7702与ERC-4337之间并非相互替代，而是互补的关系。EIP-7702弥补了ERC-4337在EOA过渡上的不足，而ERC-4337则提供更高的安全保障，适用于对安全性有更高需求的场景。
虽然智能钱包（SmartWallet）带来了许多创新，但它们的出现并不代表DApp的使用体验会自动变好。钱包与DApp之间的沟通方式需要进一步的协调和标准化，才能真正实现流畅的使用体验。
在传统的EOA设计中，DApp发送交易通常是通过简单的eth_sendTransaction介面向钱包发送请求。然而，SmartWallet（如基于ERC-4337的智能合约钱包）需要一种全新的操作模式。ERC-4337引入了UserOperation的结构作为核心元件，但问题在于许多现有DApp并不知道如何生成UserOperation的资讯。这导致SmartWallet与当前DApp生态的兼容性大打折扣。
为了解决这一问题，社群内正在讨论如何统一相关介面，其中一些重要的提案包括：
这些提案的目的是让DApp能更轻松地与SmartWallet互动，提升其易用性并加速智能钱包的普及。
除了介面统一外，另一个重要的改进方向是提升钱包与DApp的交互体验，减少使用者需要反覆操作钱包的次数。Reown（前WalletConnect）的创始人提出了SmartSession的概念，旨在简化操作流程并提供OAuth式的授权体验。理想中的使用场景如下：
透过SmartSession，使用者的点击次数可以减少到仅需一次，同时授权流程变得直观，类似Google或Facebook的OAuth体验。这种设计符合钱包与DApp连接的终极目标：「LessClicks&MoreControl」，即在减少用户操作的同时，保持用户对授权的完全掌控。
SmartSession虽然优化了使用体验，但也带来了一些安全风险，尤其是SessionKey泄漏的可能性。考虑到浏览器端是前端攻击（如XSS）的高发地点，如何安全地储存与管理SessionKey是必须解决的问题。
Passkey是实现SessionKey安全存储与签名的良好选择，因为它能大幅降低泄漏风险。同时，SessionKey的设计应保证丢失后对用户的影响最小，用户只需重新授权即可恢复使用。
随着上百条L2的诞生，使用者的资产逐渐分散到不同链上。这种分散性带来了跨链操作的复杂性，不仅速度慢，体验也相当不友好。在应用层面，越来越多的协议开始采用IntentCentricDesign（意图导向设计）来解决这些问题。这种设计理念的核心在于，用户只需表达自己的目标意图（Intent），而不需要关心具体实现方式，将操作的复杂性交由Solver（解决者）处理。从过去的「自行开车到目的地」到如今「叫Uber即可」，这正是IntentCentricDesign带来的使用体验转变。
ERC-7683是由Uniswap和跨链桥Across提出的跨链意图标准，它让用户只需签署跨链操作的意图，由Solver负责完成具体请求，支援以下常见场景：
使用者只需一键操作，即可完成如「将ETH从以太坊跨链至Arbitrum并购买NFT」的复杂任务，且整个过程可在三秒内完成。
ERC-7683的操作流程如下：
使用者支付的手续费基本等同于一小时的借贷利息。这种模式比传统基于讯息的跨链协议效率更高，因为其采用了批次结算方式，减少了跨链讯息传输的成本，无需每笔交易都传送一个跨链的讯息。
ERC-7683允许开发者自定义结算逻辑，让合约决定支付Solver的条件。这样的灵活性也带来以下问题：
为解决这些问题，可在Settlement合约采用模组化设计，让结算逻辑简单易懂且易于审计，从而吸引更多Solver提供流动性。
未来结合EIP-7702，ERC-7683能实现更高效的跨链操作。例如，透过一个chainID=0的签章升级所有EVM链的EOA为智能合约钱包，使用者可将Intent设定为「在B链执行某操作」，并以目标链上的身份完成交易。这样，用户可在A链上管理资产，同时请求Solver在其他链执行交易并支付对应的Gas。此过程中，Solver的角色不仅执行交易，还帮助减少Gas成本，实现完全去中心化的解决方案。
CoWSwap在单链场景中推动了Intent的应用，专注于优化Swap体验。其核心特点包括：
然而，CoWSwap的解决方案对Solver提出了极高的技术要求：
其他Intent案例：Daimo的CrossL2IntentAddress
在交易场景的Intent解决方案之外，Daimo提出了CrossL2IntentAddress的设计，为跨链支付与DeFi操作带来了更高效的方式。该设计允许使用者在sourcechain上将USDC发送到一个指定地址，通过relayer在destinationchain执行后续操作，例如将USDC跨链后进行特定的DeFi操作。整个过程完全去中心化，适用于跨链支付、一键投资等场景。
这一设计的核心依赖于Circle的CCTP跨链桥和以太坊的CREATE2机制，通过结合这两者实现用户Intent的自动化执行。
这种做法相比ERC-7683更简单，但需要在交易过程中部署合约，导致增加一些gas费用。不过，由于部署的合约只是小型的proxycontract，指向预先部署好的implementationcontract，因此额外成本相对有限。
ChainAbstraction的核心理念是隐藏区块链的存在，让使用者专注于资产本身，而非背后的链。这意味着使用者只需知道自己拥有多少USDC、ETH等资产，而不用关心它们分散在哪些链上。当使用者发起USDC的转帐时，系统会自动检测并整合所有链上的USDC，完成转帐所需的跨链操作。同时，使用者不需要为Gas费烦恼，可以直接用转帐的USDC支付Gas。
Biconomy提供了ModularExecutionEnvironment(MEE)解决方案，专为支持ChainAbstraction而设计。这个系统允许ERC-4337钱包的开发者轻松定义跨多链的操作，并将其整合为一个Supertransaction。使用者仅需签署一次对Supertransaction的授权，即可实现以下功能：
其技术基础在于用户对所有操作生成一个MerkleRootHash签章，然后透过ModularExecutionEnvironment自动将这些操作上链执行。
多家公司也提出了不同形式的ChainAbstraction解决方案：
以太坊的开发生态持续进步，各种工具大幅提升了开发者的效率，无论是在测试网的模拟、智能合约的除错，还是区块链资料的索引，都有显著的创新。以下是几款值得关注的工具与解决方案。
TenderlyVirtualTestNet是一个强大的虚拟测试网工具，允许开发者fork主网，其特色是能与主网保持即时同步状态。同时它支援：
Simbolik是专为Solidity开发设计的除错工具，与VSCode无缝整合，只要在测试上方案下Debug就能执行。它的功能包括：
Simbolik为开发者提供了高效且细致的除错支持，帮助快速定位并解决合约中的问题。
TrustBytes是一款将Solidity程式码转化为图像化呈现的工具，特别适合合约审计。它的核心功能包括：
TrustBytes通过缩短代码追踪的时间以提升审计效率，特别是在分析潜在攻击点方面。可参考其Demo网站。
以太坊的资料结构让直接从JSONRPC获取资料效率低下，因此需要透过Indexer将资料提取并存储到高效的资料库中。以下是两个值得关注的解决方案。
Shovel是一款开源工具，允许开发者透过简单的config档，将链上资料转化为指定格式并储存到PostgreSQLDB。例如，纪录一个钱包的历史ERC20TokenTransfer可以这样设定：
{ 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能快速完成资料的提取与存储，大幅降低开发成本。
RethExecutionExtension提供了一种新颖且高效的设计，针对链上资料索引与Re-org（链重组）处理，解决了传统方法中的诸多痛点。
过去，如果使用geth等节点软体来扩展功能，往往需要直接修改节点内的程式码，这样的做法相当于对节点进行了fork。一旦上游节点有更新，开发者还需要持续合并更新的程式码，这无疑增加了开发与维护的复杂性。
Reth的创新之处在于其设计为可直接作为libraryimport，开发者不需要fork或修改节点本身的程式码，就能灵活扩展节点功能。
Reth提供了清晰且灵活的通知介面，用于处理区块链的三种状态变化：
以下是范例程式码展示如何处理这些通知：
asyncfnexex<Node:FullNodeComponents>(mutctx:ExExContext<Node>)->eyre::Result<()>{ whileletSome(notification)=ctx.notifications.recv().await{ match¬ification{ ExExNotification::ChainCommitted{new}=>{ //dosomething } ExExNotification::ChainReorged{old,new}=>{ //dosomething } ExExNotification::ChainReverted{old}=>{ //dosomething } }; } Ok(())}
安全问题一直是区块链领域的核心挑战，从开发环境的设置，到设备与用户端的保护，再到DeFi合约层面的防御，都需要严密的措施来降低风险。以下针对开发、设备与DeFi安全三大主题进行探讨。
在区块链应用的开发过程中，环境的安全性往往容易被忽视，但它可能成为骇客的突破口。
当开发者在VSCode中开启一个恶意的Repo并点击「Yes,Itrusttheauthors」后，骇客可能利用.vscode资料夹内的设定执行任意脚本，包括：
这是因为.vscode中的Tasks可以设置触发特定条件的自动执行脚本（详见官方文档）。这种漏洞可能导致开发者的整个系统处于被骇客接管的风险中。
为避免上述风险，开发者应在Sandbox环境中开启专案。具体来说，可以使用VSCode的DevContainer功能，在Docker容器中执行完整的开发环境。这样即使恶意代码执行，也只会影响隔离的容器，不会危及主机系统。
SelfHostedRunner是Github提供开发者自行建置CI环境所需机器的解决方案。然而如果在PublicRepo启用SelfHostedRunner会带来潜在威胁：
这一风险已被详述于Synacktiv的报告。建议避免在PublicRepo中使用SelfHostedRunner，或采用更严格的权限管理。
Ledger的研究显示iOS和Android平台的SyncablePasskey实作并不像预期中那么安全。主要问题在于：
为了降低使用Passkey带来的风险，建议采取以下措施：
这些建议可以有效降低Passkey在日常应用中的潜在风险，同时确保资产的安全性。
区块链应用最核心的DeFi领域，因其高额资金流动性，成为骇客攻击的主要目标。防范这类风险需要智能合约与基础设施层面的共同努力。例如Forta提供了一种基于AI模型的链上防火墙，用于过滤潜在攻击交易。其运作机制如下：
因此这个做法必须由DApp透过Forta提供的RPC发送交易才可以，如果使用公开的RPC则无法取得必要的签章。但这也带来潜在的问题与挑战：
至于如何解决第二个问题，知名交易安全检测公司Blowfish的CTO提到，可以在模拟交易过程检测该交易是否使用了与EVM环境参数相关的逻辑，例如block.timestamp或block.basefee等等，但也无法保证100%判断正确，因此精准的交易模拟仍然是安全领域待解决的难题。
FuzzTesting是一种强大的测试技术，其核心原理是透过大量随机的输入测试智能合约，试图触发意外的逻辑漏洞。这种方法对于捕捉人眼难以察觉的边缘情境（cornercases）尤其有效。
Fuzzer的主要作用是持续尝试各种随机输入来检测智能合约是否能满足定义的Invariant（不可变条件）。开发者可以利用这种方法进行黑箱测试，模拟合约的实际使用情境，并验证其逻辑是否能抵抗各种异常操作。
尽管FuzzTesting是捕捉逻辑漏洞的有效工具，但找不到漏洞并不代表合约没有问题。Fuzzer的效果取决于定义的Invariant是否完善，以及随机测试的覆盖范围。
以下是三个经典例子，说明如何使用黑箱的FuzzTesting方法来检测系统的正确性：
使用Chimera撰写FuzzTest
以下介绍如何使用Chimera框架来整合多种Fuzzer工具（如Echidna、Medusa和Foundry）进行智能合约的Fuzz测试。
以下是一个简化的Vesting智能合约范例，其目的是实现用户的积分分配与转移，完整程式码在solidity-fuzzing-comparison Repo中的09-vesting。然而，该合约存在一个漏洞：用户可以通过「自我转移」增加自己的积分，进而破坏总积分不变的Invariant。
Vesting.sol合约部分代码：
//usersentitledtoanallocationcantransfertheirpointsto//anotheraddressiftheyhaven'tclaimedfunctiontransferPoints(addressto,uint24points)external{ require(points!=0,Zeropointsinvalid); AllocationDatamemoryfromAllocation=allocations[msg.sender]; require(fromAllocation.points>=points,Insufficientpoints); require(!fromAllocation.claimed,Alreadyclaimed); AllocationDatamemorytoAllocation=allocations[to]; require(!toAllocation.claimed,Alreadyclaimed); //enforceidenticalvestingperiodsif`to`hasanactivevestingperiod if(toAllocation.vestingWeeks!=0){ require(fromAllocation.vestingWeeks==toAllocation.vestingWeeks,Vestingmismatch); } allocations[msg.sender].points=fromAllocation.points-points; allocations[to].points=toAllocation.points+points; //if`to`hadnoactivevestingperiod,copyfrom`from` if(toAllocation.vestingWeeks==0){ allocations[to].vestingWeeks=fromAllocation.vestingWeeks; }}
用户可以将自己的积分转移给自己（self-transfer），导致总积分超出限制，破坏合约中「所有用户积分总和应等于总分数」的Invariant。然而就算我们不细看transferPoints的实作，也能透过对其黑箱的Fuzzing来找到问题。
在测试此合约时，可以设计以下两个主要Invariant：
这些Invariant可以被用于多个Fuzzer的测试过程中。
Chimera是一个功能强大的多工具整合框架，允许开发者一次撰写测试代码，并同时在多个Fuzzer工具上执行。以下是使用Chimera的步骤：
1、安装Chimera：forgeinstallRecon-Fuzz/chimera
2、设定测试环境：建立一个Setup.sol文件来初始化测试合约，并追踪需要检查的状态。
//SPDX-License-Identifier:MITpragmasolidity^0.8.23;import{Vesting}from./Vesting.sol;import{BaseSetup}from@chimera/BaseSetup.sol;abstractcontractSetupisBaseSetup{ Vestingvesting; functionsetup()internaloverride{ 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=newVesting(recipients,points,vestingWeeks); }}
3、实现Invariant：定义检查条件，例如所有用户的积分总和应等于总积分。
functionproperty_users_points_sum_eq_total_points()publicviewreturns(boolresult){ uint24totalPoints; //sumupalluserpoints for(uint256i;i<recipients.length;i++){ (uint24points,,)=vesting.allocations(recipients[i]); totalPoints+=points; } //trueifinvariantheld,falseotherwise if(totalPoints==TOTAL_POINTS)result=true;}
4、定义如何测试目标函数：指定transferPoints参数需满足的条件，避免因错误参数导致的Revert
functionhandler_transferPoints(uint256fromIndex,uint256toIndex,uint24points)external{ fromIndex=bound(fromIndex,0,recipients.length-1); toIndex=bound(toIndex,0,recipients.length-1); addressfrom=recipients[fromIndex]; addressto=recipients[toIndex]; points=uint24(bound(points,1,vesting.allocations(from).points)); vesting.transferPoints(to,points);}
5、执行FuzzTesting
forgetest--match-contractVestingCryticToFoundry
可以看到Fuzzer在短时间内就找到了打破不变量的方法
修复漏洞
漏洞的解法是避免自我转移：
functiontransferPoints(addressto,uint24points)external{ require(points!=0,Zeropointsinvalid); require(msg.sender!=to,Selftransferinvalid); //...}
修复后再执行一次测试即可通过了
零知识基础设施（Zero-KnowledgeInfrastructure,ZKInfra）涉及编译、执行、生成证明与验证ZK电路的多个核心软体元件，对其进行漏洞检测至关重要。FuzzTesting是检测这些基础设施漏洞的一项强大工具，尤其适合处理其高复杂性与高安全需求的特性。
零知识基础设施的测试需要克服其内部实现的高度复杂性，黑箱测试因此成为检测漏洞的有效方法。在这种测试中，开发者将处理流程视作不可见的黑箱，仅根据输入和输出进行分析。
首先，测试工具会随机生成一个原始电路（C1），这些电路通常以小型DSL（特定领域语言）描述，用于模拟用户操作。接着，应用一系列随机变换来生成新电路（C2）。这些变换包括乘以1、加减随机表达式或其他等价操作，保证电路语义不变。随后将两个电路各自进行ZK工具的编译处理，若在任何阶段输出或行为不一致，即可定位到处理流程的漏洞。
例如，一个表达式P转换为P×1−0时，应保持输出一致，否则可能指向WitnessGenerator或编译器中的潜在问题。
由于零知识基础设施经常被用于Layer2协议，将乘载数亿美金以上的价值，其安全性至关重要，因此持续测试显得尤为必要。这可以通过自动化测试工具来实现，保证每次代码更新后都能迅速发现潜在漏洞。
测试还需要支持多种零知识DSL，如Circum、Gnark和Noir，确保适用于广泛场景。同时，FuzzTesting工具应具备自动化反馈功能，能够持续执行并根据发现的问题进行改进。此外，测试生成的输入应尽量简化，以便开发者快速理解并定位问题。
FormalVerification（形式化验证）是一种透过数学方式验证软体是否符合特定FormalSpec（规格）的技术。对于智能合约而言，这种方法能有效检查合约在所有可能状态下的正确性。与FuzzTesting（模糊测试）相比，FormalVerification的验证过程更为系统化，能够覆盖所有可能的状态并「数学证明」合约逻辑的正确性。
然而，FormalVerification的实施通常需要严谨的规格定义，且计算成本较高。另一方面，FuzzTesting则透过随机输入测试合约，具有轻量且能快速发现边界问题的特性，但其测试范围有限，可能无法检测更深层的逻辑漏洞。
Certora提供了一套完整的工具来弥补这些不足，帮助开发者在现实环境中应用FormalVerification。其主要产品CertoraProver为智能合约提供了强大的验证框架，允许开发者定义规则并自动化验证合约的逻辑正确性。
Certora提供的工具旨在简化智能合约的形式化验证过程，核心功能包括：
使用CertoraProver于有漏洞的投票合约
以下是一个简单的投票合约，完整的程式码可以在basic-presentation Repo中找到。其中totalVotes在每次投票后会被重置为1，这是一个逻辑错误：
//SPDX-License-Identifier:MITpragmasolidity^0.8.0;contractVoting{ mapping(address=>bool)publichasVoted; uint256publicvotesInFavor; uint256publicvotesAgainst; uint256publictotalVotes; functionvote(boolisInFavor)external{ require(!hasVoted[msg.sender]); hasVoted[msg.sender]=true; totalVotes=1;// BUG:每次投票后重置totalVotes if(isInFavor){ votesInFavor+=1; }else{ votesAgainst+=1; } }}
步骤1：撰写规格
以下是一个简单的规格，检查totalVotes是否在每次投票后递增：
rulevoteIntegrity(enve){ uint256votedBefore=totalVotes(); boolisInFavor; vote(e,isInFavor); assert( totalVotes()>votedBefore, totalVotes应该在每次投票后递增 );}
步骤2：设定config
使用以下.conf档案来设定验证细节，包括要验证的合约与规范档案。
{ files:[src/VotingBug.sol:Voting], verify:Voting:certora/specs/VotingBug.spec, msg:验证totalVotes递增, server:production}
步骤3：执行验证
在专案根目录执行以下指令：
exportCERTORAKEY=xxxcertoraRuncertora/confs/VotingBug.conf
如果还没有APIKey，可以在官方网站注册取得。输出中会有一个CertoraProver结果的连结，点进去即可看到Prover找到了一个错误，并提供详细的输入参数
步骤4：修复问题
修改合约逻辑以修复问题：
functionvote(boolisInFavor)external{ require(!hasVoted[msg.sender]); hasVoted[msg.sender]=true;
totalVotes+=1;//FIXED:正确地累加totalVotes if(isInFavor){ votesInFavor+=1; }else{ votesAgainst+=1; }}
步骤5：重新验证
再次执行验证，确认所有规范均已通过，代表此智能合约的正确性可被数学证明。
Certora也支援定义不变量规则（InvariantRules），确保合约在所有状态下的逻辑一致性。例如：
invarianttotalVotesIsSumInvariant() votesInFavor()+votesAgainst()==to_mathint(totalVotes());
此规则验证totalVotes永远等于赞成与反对票数的总和。
在文章的前半部分中，我们已提到IntentCentricDesign，其中介绍了CoWSwap如何透过设计应用层的逻辑来简化跨链交易并提升用户体验。在这一部分，我将深入探讨CoWSwap如何解决MaximalExtractableValue(MEV)问题，以及其主张MEV应在应用层解决的理念。同时，我们也会介绍Unichain如何通过可信执行环境（TEE）在基础设施层解决MEV问题，呈现两种截然不同但互补的解决方式。
CoWSwap的核心主张是，MEV问题的根源在应用层。目前约99%的MEV问题来自交易排序的竞争，而应用层（例如去中心化交易所DEX）的设计是导致这些问题的主因。因此，MEV问题应该在设计应用时一并考虑，而非依赖基础设施层的迂回解决方案。
CoWSwap引入需求巧合的概念，通过将多笔交易的需求聚合在一起，使交易者直接匹配需求，避免了流动性池的中间操作，从而减少MEV攻击的可能性。
案例：假设Alice想用100USDC换取1ETH，而Bob刚好想用1ETH换取100USDC。在传统DEX中，这些交易需要分别通过流动性池进行，可能会被套利者利用滑点进行MEV攻击。而在CoWSwap中，这两笔交易可以直接匹配，无需经过流动性池，消除了滑点和MEV攻击。
CoWSwap的批次拍卖机制是其解决MEV问题的核心手段：
批次拍卖的优势：
实际案例：
假设有三位用户的交易意图：
这三笔订单在批次拍卖中被组合在一起。由于A和B的购买需求总和（300DAI）恰好匹配C的出售需求（1ETH），因此可以直接在用户之间进行点对点交换，无需触及链上流动性。这不仅提高了交易效率，还降低了交易成本，并消除了MEV攻击的风险。
与CoWSwap将MEV处理集中在应用层的设计不同，Unichain选择在基础设施层通过可信执行环境（TEE）来解决MEV问题。Unichain是基于OPStack的OptimisticRollup，其核心创新在于加密交易与TEE排序，保证交易排序的透明与公平。
ZeroKnowledgeProof(ZKP)技术的应用展示了如何透过密码学方法，实现隐私保护与效能的平衡。以下将介绍几个令我印象深刻的ZK应用。
ZKPassport结合了国际电子护照（ePassport）的晶片技术与ZKP，为用户提供一种既安全又隐私的身份验证方式。透过手机感应护照的NFC，用户可以取得护照晶片中由政府签署的资料，例如基本资讯和照片。由于这基于全球标准（ICAOBiometricPassport），超过100个国家的护照均可支援。基于此签章即可生成护照资料有效性的零知识证明。
ZKEmail
ZKEmail是一个基于零知识证明的Email验证应用，允许用户选择性地验证邮件内容。例如，证明Email的发信人是否为特定组织、Email内文是否有特定文字，而无需公开整封邮件的内容。关键是采用每个Email都会由MailServer签署的DKIMSignature，产生一封信是由该域名发出的零知识证明，且无法被伪造。
ZKP2P是一个基于零知识证明技术的域名交易市场，旨在提供快速、安全、去中心化的域名交易体验。该平台支持利用零知识证明验证域名所有权，并使用ETH进行域名交易。目前ZKP2P已支援使用者交易Namecheap上的域名。
Polygon正在开发新一代的ZKVM证明系统ZisK，目标是实现即时证明整个EVM区块中所有交易的计算。ZisK的设计核心在于其通用性（GenericZKVM）和极致的证明生成速度优化，旨在提升零知识证明在区块链应用中的性能。
ZisK的架构受到嵌入式系统（EmbeddedSystem）的启发，采用了模组化的设计，主要组件包括：
目前，ZisK还处于非常早期的开发阶段，可参考其开发文件。
ReclaimProtocol是一个将TLSProxy技术与零知识证明（Zero-KnowledgeProof,ZKP）相结合的隐私保护协议，旨在让用户能够在不泄露敏感资讯的前提下，验证HTTPS通讯内容的真实性。该协议为资料验证与互操作性提供了安全的解决方案，尤其适用于Web2和Web3场景的整合。
ReclaimProtocol的核心依赖于TLSProxy作为信任中介。过程中HTTPS请求和回应会经过TLSProxy，并由Proxy签署该流量的加密内容，从而为后续的证明生成提供基础。TLSProxy的角色仅限于签署加密流量，无法解密任何资料，这也减少了隐私风险。
TLSProxy的一个重要功能是处理使用者和伺服器之间的HTTPS流量，并保证这些流量来自正确的伺服器。例如，在证明某银行网站的余额资讯时，TLSProxy签署的加密流量可以确保数据未被篡改，并提供可信的资料来源。
然而尽管TLSProxy提供了关键的信任保障，在极端网路条件下（例如BGPHijack攻击），可能会出现Proxy认证的流量被路由到错误伺服器的风险。这种攻击需要在TLSHandshake后精准篡改流量，实现难度极高，但这仍是协议中需要特别关注的安全边界。
ReclaimProtocol结合了ZKP技术，允许用户在不泄露完整TLS明文的前提下验证其真实性，其ZK电路的设计旨在处理解密与部分揭露的功能。
协议中的ZK电路能够解密特定的TLS流量，并仅揭露其中需要验证的部分资讯。例如，用户可以提供AES解密金钥作为PrivateInput，在电路中解密TLS流量，并公开指定区域的明文资讯。这些操作基于gnark框架进行，确保了高效的证明生成。
值得注意的是，ReclaimProtocol提供了透过RegularExpression或是HTMLtemplate匹配TLS流量的功能，而这一匹配逻辑被设计为在电路外实作，以避免电路过度复杂。因此客户端需首先自行透过Template定位哪些AESBlock中有包含所需的明文，再生成ZK证明来证实匹配结果。这样导致的资安风险是，如果TLSPayload中在其他部分也出现了类似的字串，客户端则有机会伪造证明。
ReclaimProtocol目前将重点放在Web2场景的资料互操作性上，解决不同平台间的数据共享问题。例如：
Vlayer是一家专注于开发「可验证资料基础设施」的加密初创公司，称之为「Solidity2.0」。其目标是使开发者能够将真实世界的资料验证后整合至以太坊智能合约中。具体而言，Vlayer为Solidity语言引入了四个新功能：
这些功能旨在扩展智能合约的应用范围，特别是在去中心化金融（DeFi）、真实世界资产（RWA）和游戏等领域。目前，Vlayer正处于Alpha阶段，邀请开发者在其平台上进行开发，并计划于2025年推出测试网、主网和代币。
Mopro（MobileProver）是一个专为Mobile环境开发的ZK证明生成工具，以简化客户端的证明过程。Mopro的主要特点包括：
然而，在Mobile环境下仍存在一些挑战：
MPC是一种密码学技术，允许多方在不泄露各自输入的情况下，共同计算一个函数的结果。其与ZK的差别在于：
以下介绍几个MPC的应用与最新研究，展示其在隐私保护与分布式计算中的潜力。
WorldID是Worldcoin的核心技术，旨在为每位用户建立独特的数位身份，用以证明个人的「唯一性」。注册过程中，使用者需透过「虹膜扫描」验证身份，确保每人仅能注册一次。这需要将新扫描的虹膜与已注册的数据库进行比对。然而，大量集中存储的真实虹膜数据可能带来巨大的隐私风险。
为解决此问题，Worldcoin与Taceo合作，探索基于MPC的去中心化虹膜比对方案。
WorldID最大的技术挑战在于计算成本高昂：Worldcoin的使用者数已超过1,600万，每次唯一性验证需要针对庞大的数据库进行线性扫描。在GPU加速环境下，一次验证需要32台NVIDIAH100GPU，峰值网络吞吐量达2.5Tbps。
因此，Worldcoin正积极探索计算资源需求更低但验证严谨度相对较低的替代方案，例如借鉴ZKPassport的护照唯一性证明机制，以在减少成本的同时保持足够的验证可信度。
MPCStats是一个基于MPC的开源框架，旨在实现多方参与的统计计算，同时保护数据隐私。该框架允许多个数据提供者匿名参与计算，结果公开但不泄露个人数据细节。
在Devcon展会中，MPCStats提供了一个Demo，让参与者私密分享其BinanceETH余额，计算平均值。数据的完整性由TLSNotary证明，最终生成可信且隐私保护的统计结果。
PublicAuditableMPC（PAMPC）是一种结合MPC和零知识证明（ZK）的新型协议，旨在解决现有MPC系统中无法向第三方验证计算正确性的挑战。该协议允许计算方在保护输入隐私的同时，向第三方公开验证计算结果的正确性。
0xPARC提出可程式化密码学（ProgrammableCryptography）概念，指出此技术是从「专用型密码学」转向「通用型密码学」的世代革命。
过去，密码学工具为特定用途而设计，如RSA加密、椭圆曲线签章等等。当人们需要新的功能，就必须发明新的密码学协议来满足需求，如GroupSignature协议可以让个人代表一群人签署资料，而不透露具体身份，这与RSA加密演算法的设计有显著差异。
相对而言，可程式化密码学将密码学设计的数学问题转化为工程问题，允许开发者写程式来实现任意密码学操作。以下是一些重要技术：
可程式化密码学能帮助实现Internet的理想状态，包括：
例如，MPC与FHE技术让伺服器在完全不了解用户数据的前提下，完成计算任务，同时确保计算结果的可验证性，这代表使用者资料将永远由自己掌控。
以下透过两个例子解释，为何有了可程式化密码学后，能建构理想的社交网路与投票应用。
过去当人们思考去中心化社交网路时，总是想先模仿Twitter，原因是Twitter的机制较为单纯：每个使用者可以公开发布内容，任何人都能看到其他人的内容。然而相较于去中心化Twitter，去中心化Facebook的实现更加复杂，因其数据拓扑和隐私要求更高：
此外，这些应用需要处理隐私的全域状态（PrivateGlobalState），例如推荐演算法的参数可能无任何单一方知晓，但系统仍需保证其正确运行。这些挑战只能透过可程式化密码学解决。
投票是个很好的案例，因为它需要同时满足许多特性，才能做到公平、隐私且公正。在加入不同的可程式化密码学技术后，能一步步朝向理想的投票系统迈进：
ZuPass是由0xPARC推出的一个实验性应用，基于可程式化密码学（ProgrammableCryptography）的概念设计，旨在帮助使用者实现对自身资料的自主管理与跨平台互操作性。ZuPass的核心是Proof-CarryingData(PCD)，使用者可以在保护隐私的前提下安全储存并证明其数据的有效性。
以下介绍几个在本次Devcon会场的ZuPass应用。使用ZuPass的应用又被称为ZApp
ZuPass在Devcon活动中被用来验证与会者身份，其原理如下：
FrogCrypto是一个基于ZuPass的有趣应用，让参与者在展场中搜集各种类型的青蛙，并生成证明来展示自己拥有的青蛙。其特色在于
Meerkat是促进讲者与听众互动的ZApp，结合了Slido问答功能与ZK技术，实现匿名互动。其功能包括：
ZuPass提供方便整合的SDK，达成类似GoogleOAuth的方便整合SDK：
ZuPass建立在两个关键技术之上：ProvableObjectData(POD)与GeneralPurposeCircuit(GPC)。这两项技术支撑了像是Meerkat、FrogCrypto和Devcon门票验证等应用，实现了数据的隐私验证与互操作性。
POD是一种以密码学为核心的数据格式，专为零知识证明设计。GPC则是一种模组化电路，能根据POD的结构生成灵活且高效的ZK证明。
GPC是针对POD设计的通用电路，只需单一电路即可产生基于POD灵活的零知识证明。其设计基于模组化架构，包含：
尽管POD系统具有灵活性与隐私保护能力，但其仍存在以下限制：
为了解决POD1的缺陷，POD2系统应运而生，其引入了「Proof-CarryingData(PCD)」的概念，使所有数据都带有可验证的证明，并支援多方运算：
并且POD2框架支援开发者将任意的Web2资料转换为POD格式，以解决POD与既有系统不兼容的问题，称为「UniversalDataAdapter」。例如开发者可将来自ZKEmail、TLSNotary等Web2系统的资料转换为POD格式的ProofCarryingData，让所有系统的资料产生互通性，实现不同系统间的无缝整合。最大的好处在于完全不需修改既有Web2系统的资料产生逻辑。
POD2的技术挑战在于，需依赖于多方全同态加密（Multi-PartyFullyHomomorphicEncryption,MP-FHE）实现多个POD2之间的共同隐私运算。
0xPARC也发明了类似Lisp的PEX语言，用于描述POD2的数据结构与条件：
[createpodid-card age26 zip-code12001 id1847202750][>age18]
提供简洁且直观的语法，使开发者能快速建立基于POD的应用。
FrogZone是0xPARC在Devcon展示的技术游戏，旨在实践最尖端密码学应用，展示全同态加密（FullyHomomorphicEncryption,FHE）和多方计算（Multi-PartyComputation,MPC）技术如何结合，创造出具隐私保护和分布式特性的应用环境。这款游戏作为首个多用户MP-FHE应用，为分布式隐私计算和应用开发提供了重要的技术示范。
FrogZone展示了利用全同态加密和多方计算技术实现隐私保护和去中心化应用的可能性。虽然当前技术仍面临性能和开发难度的挑战，但这就如同1960年代的电脑，虽然庞大且效率低下，却是开创现代计算时代的起点。FrogZone的意义在于，它象征了ProgrammableCryptography的雏形，为未来理想化的网际网路铺平了道路。
随着ProgrammableCryptography技术的发展，未来的网际网路将实现去中心化、自主性和隐私保护的目标，建立一个真正属于用户的数位世界。这个世界将带来更安全、透明且自由的数位生活，每个人都将能完全掌控自己的资产、资料与身份。
非常好学习网(www.veryok.net)工作总结，工作计划，活动方案，申请书范文，满分作文，读后感，观后感，祝福语等！
Copyright (C) 2010-2026 veryok.net, All Rights Reserved 版权所有
非常好学习网版权所有 客服联系QQ:671102 
