除了Devcon 主场馆的演讲与体验活动，我个人更喜欢参加特定主题的side events。这些活动不仅能深入学习相关领域的知识，还能遇到志同道合的专家进行交流。例如在一场关于zkTLS 的活动中，我有机会直接向项目方请教文件中不太理解的部分，这段经历让我印象深刻。未来若有类似的大型研讨会，我也强烈建议大家多参加与自己兴趣相符的side events。

以下正文开始。

Part 1: Infrastructure

以下将从成就、现况与未来三个面向，详细阐述以太坊如何透过技术创新解决当前挑战，并为未来的扩容与去中心化铺路。

成就：手续费降低与一流的稳定性

坎昆升级大幅降低L2 手续费

今年的坎昆升级带来了前所未有的成本优化。得益于EIP-4844引入的DAS 技术（Data Availability Sampling）与Blob机制，L2 现在可以以更低的成本将更多资料储存到以太坊主网，使每笔交易的费用降至不到$0.01 美金，让L2 的使用更加经济实惠

Client Diversity 的成功实践

以太坊的Client Diversity是其稳定性的重要基石。运行以太坊节点的程式（Client）有多套选择，例如Geth、Nethermind 和Reth，每套程式的开发团队分布于不同地区，程式码基础也完全独立。知名的执行层Client 就有Geth, Nethermind, Reth 等等。

关键价值：即使某个Client 出现Bug，也不会影响整体网路，因为每个Client 的使用比例均低于50%，而以太坊的共识机制是至少需要2/3 的节点同意才能让区块Finalize，因此能够避免单一Bug 导致整条链分岔
历史案例：早期以太坊只有Geth 与Parity 两个Client，在某次Client 发生重大问题时，Client Diversity 帮助以太坊维持了整条链的稳定运行。
理想状况：最理想的分布是所有Client 各自占比低于1/3，这样即便某个Client 出现问题，也不会影响区块的最终确认（Finalization）。

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

交易确认效率显著提升

以太坊的Transaction Inclusion（交易纳入）能力相较两年前有了很大进步。如今，绝大多数交易可在6~30 秒内完成确认，避免了过去常见的交易延迟数分钟甚至被节点丢弃的问题，为用户带来更稳定的交易体验。

现况：Rollup 的挑战与安全性

自2020 年Vitalik 确立了以太坊的Rollup Centric 扩容路线图以来，整个生态系已经诞生了数百条L2 链。在这一架构下，L1 作为基础设施的角色，提供高度稳定、安全且可信中立的保障，而L2 则像GPU 一样，针对特定应用进行加速，显著提升每秒交易次数。然而随着L2 的快速增长，也暴露了一些挑战。

L2 的信任假设与分级安全模型

目前许多L2 项目仍基于强信任假设，某些L2 项目方甚至拥有冻结用户资金或停止整条链运作的权力。为了更清楚地衡量L2 的安全性，业界将其分为三个阶段：

Stage 0：完全中心化的L2。 Stage 0 是最基本的Rollup 实现，只需定期将数据提交到以太坊主网即可运行，但这意味着资金安全性完全依赖项目方。这种设计类似于脚踏车的辅助轮，主要用于帮助项目快速上线运作。
Stage 1：基础的Rollup 证明与治理机制。在Stage 1 中，L2 至少实现了一种Rollup 证明系统，例如Optimistic Rollup 的Fraud Proof或ZK Rollup 的ZK Proof。这些证明由智能合约验证L2 状态的有效性。此外，项目方需引入Security Council作为治理机制，对协议的关键修改需多数成员同意，并确保项目方无法在Security Council 中占据绝对多数。
Stage 2：去中心化与双重证明系统。在Stage 2，L2 不仅需要实现两种独立的证明系统，还需将绝大部分控制权交由智能合约处理。 Security Council 仅在证明系统出现冲突时介入，选择接受哪一种证明系统。这种设计最大程度地限制了项目方的权力，真正实现了去中心化与安全性的平衡。

在这三个阶段中，最大的差异在于「项目方做坏事的难度」。在Stage 0，项目方完全掌控，几乎没有任何限制。 Stage 1 引入了证明系统与治理机制，尽管攻击者可能通过贿赂Security Council 成员等方式发起攻击，但成功的难度已显著提高。而Stage 2 则彻底消除人为干预的可能性，实现了理想的去中心化。

目前的L2 发展现状与挑战

目前，大多数L2 项目仍处于Stage 0 或Stage 1。虽然这些项目标榜去中心化，但实际安全性与项目方的宣传往往存在差距。专注于L2 安全分析的网站l2beat提供了最新且详细的报告，帮助用户了解项目方的真实安全实现是否达标。他们的研究深入程式码层面，揭露了许多项目过于依赖行销术语而忽视技术实现的现象。

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

L2 必须具备一项关键功能，即Escape Hatch（逃生舱）机制，来应对项目方的Operator 或Sequencer 停止运作时的突发情况。这项机制允许用户生成自己在L2 上持有资金的证明，并将该证明提交到L1 的治理智能合约以赎回资金。整个过程必须在没有项目方介入的情况下完成，才能充分体现L2 的安全性。

例如dydx发行的L2 在这方面表现出色。当他们的L2 决定停止营运时，提供了工具让用户自行将资金转回L1，确保了用户资金的安全。

L1 的扩容需求与去中心化的坚守

为了应对未来可能的大量L2 逃生交易，L1 必须持续扩容。然而，Vitalik 多次强调，在扩容过程中，不能为了短期内的大幅扩容而妥协去中心化。一旦去中心化特性被牺牲，将难以挽回。这种坚守是以太坊作为可信中立基础设施的核心价值。

未来：以太坊的进化方向与长期愿景

以太坊在未来将迎来多方面的技术革新，从L2 的进一步去中心化，到L1 的性能优化，乃至于共识层的全面重写，这些计划都旨在推动以太坊迈向更加高效、安全且去中心化的区块链生态。

L2 迈向Stage 2：实现真正的去中心化

L2 的发展方向之一是推动更多项目迈向Stage 2，这是去中心化与安全性的理想平衡点。 Vitalik 明确表示，未来他只会将达到Stage 1的Rollup 称为Rollup，而未能进一步迈向Stage 2 的项目，将难以满足以太坊的长期愿景。在Stage 2，L2 将依赖双重证明系统，并将控制权完全交由智能合约处理，进一步降低对人为干预的依赖。

降低验证门槛：让更多人参与以太坊网路

未来的目标是让更多人能轻松参与以太坊节点的验证。这包括：

开发类似Helios的Light Client，让运算资源有限的设备也能运行以太坊验证程式，实现节点运行的轻量化。
将Stake ETH作为验证者的门槛从32 ETH 降低到1 ETH，让更多用户能参与验证，进一步分散网路风险。
减少对Lido等Liquid Staking Provider 的依赖，避免因过度集中化带来的风险。

这些措施旨在提升以太坊网路的去中心化程度，确保其稳定性与长期可持续发展。

执行层的持续扩容：TPS 迈向十万级别

目前L1 每个区块的Blob数量与大小存在限制，导致L2 在现阶段的理论TPS（每秒交易次数）仅达几千笔。然而，未来希望通过扩展Blob 机制，如引入PeerDAS技术，实现每秒十万笔交易的目标。这将大幅提升以太坊的可扩展性，为高频交易应用场景铺平道路。

共识层的革命性变革：Beam Chain

以太坊的共识层将迎来一项重大改变，即Beam Chain的引入。这是Justin 提出的对现有Beacon Chain 的全面重写，旨在解决当前最棘手的问题，并迈向以太坊的终极目标（End Game）。主要的改进方向包括：

抗量子电脑：随着量子电脑技术的发展，现有的椭圆曲线签章（ECDSA）面临被破解的风险。因此，迁移到后量子密码学签章成为当务之急。
更快的Finality：目前以太坊达到最终共识（Finality）的时间约为15 分钟，而理想目标是12 秒（Single Slot Finality）。更快的最终确认能大幅提升用户体验，特别是在中心化交易所的资金存取等场景中。
ZK Provable：随着验证者数量的增加，如何降低验证者资源需求成为一大挑战。通过结合ZK 技术和签章聚合（Signature Aggregation），验证者能快速验证数万个其他验证者的签章，在四秒内处理完一个Block。然而，现有的BLS 签章基于椭圆曲线密码学，也需进行抗量子攻击的改写，才能满足未来需求。

图中绿色的项目可以透过对共识层渐进式的改动完成，然而红色项目最为棘手，需要重写核心程式码，Beam Chain 因而被提出作为解决方案。

极度严谨的工程精神与长期路线图

Beam Chain 的引入需要对核心程式码进行全面重写，不仅能解决现有技术债，还能从过去的经验中汲取教训。根据初版Beam Chain Roadmap，整个升级计划将分为三个阶段：

一年内完成规格定义。
1~2 年完成实作。
1~2 年进行完善与全面测试。

这体现了以太坊对去中心化的坚守以及对安全性的极高要求，毕竟整个网路承载了数千亿美元的资金，任何小差错都可能导致灾难性后果。然而，也有许多社区成员批评五年的时间表过于冗长，期待能加速进度。 Justin 表示，这其中的确存在优化空间，他也希望更多人参与讨论与实作，共同推动这一计划的实现。

需要注意的是，Beam Chain 并非以太坊未来五年的唯一重点。在共识层进行升级的同时，执行层的改进（例如透过PeerDAS提高TPS）将持续推进，为应用开发者与用户提供更高效能与更流畅的体验。

Part 2: Usability

随着ERC-4337 帐户抽象标准的定案与上线，各式各样的Smart Wallet（智能钱包）应运而生，大幅提升了使用者的体验与易用性。然而，这些创新同时也对钱包和DApp 带来了新的技术挑战。另一方面，随着L2 的蓬勃发展，资产碎片化问题日益显著，许多协议与应用开始朝向Intent Centric Design和Chain Abstraction的方向发展，力求解决这些问题，让使用者能更快速完成复杂的跨链交易，并将相关细节隐藏于背后。以下将逐一探讨这些技术。

Smart Wallet (ERC-4337)

ERC-4337 标准让智能合约钱包日益普及，其中最具特色的一类便是Passkey 钱包。使用者只需透过生物认证即可创建Passkey，并将其作为钱包的私钥进行签名。每次发送交易时，使用者只需再次进行生物认证，完全不需要记忆或保存助记词，这被许多人视为钱包的「终极体验」。

Passkey 签章的技术挑战

Passkey 钱包的核心在于智能合约中如何验证Passkey 的签章。 Passkey 签章使用的是secp256r1椭圆曲线（又称P-256 签章），而以太坊原生支持的是secp256k1。两者虽然只在椭圆曲线的参数上有所差异，但带来了巨大的Gas 成本差距：

secp256k1签章的验证只需使用以太坊内建的precompiled contract，Gas 成本约为3000。
Passkey 签章（P-256）的最佳实作目前需要约30 万Gas，是前者的100 倍。

为了解决这一问题，RIP-7212提案被提出，旨在降低验证Passkey 签章的成本。通过该提案后，Gas 成本有望降至约3000，与secp256k1 签章验证相当，从而显著减轻用户负担。

Passkey 钱包的共同挑战

即使在成本降低的前提下，Passkey 钱包仍面临以下几个技术挑战：

Passkey 与域名唯一绑定：Passkey 是绑定特定域名的。例如，Coinbase Smart Wallet 使用的Passkey 绑定于keys.coinbase.com。这样的设计完全杜绝了钓鱼攻击，但也带来了域名过期或单点故障的风险。
钱包碎片化：每个Passkey Wallet 绑定不同的域名，导致使用者必须在不同应用中创建多个钱包，进一步加剧资产碎片化问题。
互通性问题：由于Passkey 钱包的私钥存储于装置的安全储存空间，不支援汇出，且在Android 和iOS 之间也无法互通，使用者难以在一个地方统一管理资产。
盲签的安全风险：在签名过程中，使用者仅会看到「是否同意此应用使用这把Passkey」的提示，无法查看具体签名内容，导致高资安风险。若钱包前端遭受XSS 攻击，用户资产可能被盗。

这些挑战让部分人质疑Passkey 作为钱包私钥的适用性，认为其设计初衷是用于Web2 登入场景，对于Passkey 丢失风险的影响较小，随时都能透过「忘记密码」功能找回帐号，而且不需展示具体签名内容。但这不代表Passkey 无法成为钱包的一部分，未来的钱包设计或许可以借鉴Web2，提供多种验证与帐号恢复选项，并依需求设置不同权限。

其他钱包验证与恢复机制：ZK Email 的创新

除了Passkey，ZK Email团队提出了一种基于Email 还原钱包控制权的机制。使用者可以将指定Email 地址设为合约钱包的「监护人」（Guardian）。当私钥丢失时，用户只需从该Email 发送一封信，包含合约钱包地址及新控制地址等资讯，即可生成ZK 证明，在链上验证后取回钱包控制权。这一设计基于多年发展的Email 基础设施，安全性高且操作便捷，有效减少了私钥丢失带来的风险。

ERC-4337 的互操作性问题与解决方法

随着Passkey 和ZK Email 等机制的应用，ERC-4337 钱包面临着显著的互操作性挑战。例如，当使用者在A 钱包中建立了ERC-4337 合约钱包，若希望汇出至B 钱包使用，可能因两者使用的Account Factory Contract不同而无法相容。这导致：

B 钱包无法辨识A 钱包所使用的签章方法。
B 钱包无法支援发送A 钱包的交易。

为了解决这一问题，业界提出了模组化合约钱包标准，例如ERC-7579和ERC-6900。这些标准将ERC-4337 的功能进一步模组化，例如：

授权模组：可以用Passkey 或多签验证替换。
交易执行模组：可根据应用需求更改，例如如何批次执行交易。
权限模组：支持灵活的权限配置。

这样的设计允许所有钱包应用共用同一个Account Factory Contract，并能够灵活组合不同模组，极大提升互操作性，减少资产管理的摩擦成本。

Smart Wallet (EIP-7702)

EIP-7702（Set EOA Code）是下一代帐户抽象标准，预计将在下一次以太坊Pectra 硬分岔中被纳入。这项提案的初衷在于解决ERC-4337的一个关键限制：使用者需要创建新的智能合约钱包，无法延续过去的EOA（Externally Owned Account）。 EIP-7702 则提供了一个全新解法，允许任何EOA 地址「升级」为智能合约钱包，带来多样化的灵活功能：

批次执行交易：将DeFi 操作中的多次签名（如Approve + Swap）简化为一次签名即可完成。
Gas 赞助：EOA 不必持有ETH，也可以透过其他地址代为支付交易所需的Gas。
弹性的权限设定：支持Passkey 或多签等验证逻辑，让EOA 具备更多智能化功能。

EIP-7702 的应用案例

Ithaca 团队在EXP-0001中展示了EIP-7702 的Demo，让使用者可以一键创建Passkey 并将EOA 地址的权限代理给该Passkey。此后，所有交易只需Passkey 签名即可完成，且已在测试网中部署了RIP-7212（Passkey 签章优化）的实作，显著降低了Gas 成本。借助这一技术，EOA 可透过单一Passkey 签章执行多笔交易，进一步提升使用者的便利性。

EIP-7702 的技术流程

EIP-7702 的核心在于如何将EOA 地址绑定智能合约逻辑，其具体流程如下：

授权请求：使用者拥有一个EOA 地址（假设为A），希望将其升级为智能合约钱包，并选择一个智能合约实作地址（S）。
生成授权签章：使用A 的私钥签署一个授权讯息，包含链ID、nonce，以及S 的地址等资讯。
提交授权交易：若A 没有ETH，可将授权签章提交给Relayer，由Relayer 代为支付Gas，将授权讯息上链。
存储合约逻辑：交易完成后，A 的Account Code Storage 将储存S 的地址。
执行合约逻辑：未来A 发送交易时，Relayer 可以呼叫A 地址并传入交易参数，A 的Account Code 会在执行过程中改写为S 的逻辑，实现智能化功能。
取消授权：若使用者希望取消授权，可使用A 的私钥签署取消请求，并提交至链上。

安全挑战与潜在风险

虽然EIP-7702 的功能十分强大，但也带来了一些新的安全风险：

授权恶意合约的风险：如果使用者不小心签署了一个恶意EIP-7702 签章，攻击者可借助合约逻辑批次转移使用者的所有资产，包括Token、NFT 和DeFi 仓位。相比现有的Permit Signature，EIP-7702 的潜在风险更高。
跨链授权的风险：签署授权讯息时，若使用chain ID = 0，表示签章对所有EVM 链生效。一个签章可能导致所有链上的资产同时暴露于风险，效果等同于私钥泄漏。

跨链授权的安全考量

EIP-7702 的设计中，签章包含Account Nonce，这代表若不同链上的地址nonce 不同，签章将无效。这一设计可以让钱包App 通过一个签章升级用户的地址至所有链上的合约钱包，提升便利性。然而开发者在设计时需谨慎处理nonce 机制，避免出现不必要的安全漏洞。

至于可能会授权恶意合约的问题，钱包App 可采取以下措施：

引入「白名单」系统，对合约地址进行验证。
透过界面提示用户授权的合约逻辑是否安全。

EIP-7702 与ERC-4337 的互补性

EIP-7702 的核心优势在于支持将现有的EOA 升级为智能合约钱包。然而，这也带来一个限制：EOA 的私钥始终拥有最高权限。如果私钥泄漏，将直接导致钱包的控制权丧失。而ERC-4337可以实现多签钱包等无需依赖单一私钥的设计，提供更高的安全性。因此，EIP-7702 与ERC-4337 之间并非相互替代，而是互补的关系。 EIP-7702 弥补了ERC-4337 在EOA 过渡上的不足，而ERC-4337 则提供更高的安全保障，适用于对安全性有更高需求的场景。

Smart Session

虽然智能钱包（Smart Wallet）带来了许多创新，但它们的出现并不代表DApp 的使用体验会自动变好。钱包与DApp 之间的沟通方式需要进一步的协调和标准化，才能真正实现流畅的使用体验。

DApp 与Smart Wallet 的兼容挑战

在传统的EOA 设计中，DApp 发送交易通常是通过简单的eth_sendTransaction 介面向钱包发送请求。然而，Smart Wallet（如基于ERC-4337 的智能合约钱包）需要一种全新的操作模式。 ERC-4337 引入了User Operation的结构作为核心元件，但问题在于许多现有DApp 并不知道如何生成User Operation 的资讯。这导致Smart Wallet 与当前DApp 生态的兼容性大打折扣。

为了解决这一问题，社群内正在讨论如何统一相关介面，其中一些重要的提案包括：

EIP-5792：帮助DApp 确认钱包支持哪些Smart Account 的功能。
ERC-7677：指导DApp 如何生成User Operation 中的paymasterAndData 栏位。
ERC-7679：提供生成完整User Operation 的规范。

这些提案的目的是让DApp 能更轻松地与Smart Wallet 互动，提升其易用性并加速智能钱包的普及。

Smart Session 的概念与理想体验

除了介面统一外，另一个重要的改进方向是提升钱包与DApp 的交互体验，减少使用者需要反覆操作钱包的次数。Reown（前WalletConnect）的创始人提出了Smart Session的概念，旨在简化操作流程并提供OAuth 式的授权体验。理想中的使用场景如下：

初始授权：使用者登入DApp 时，DApp 向钱包请求授权，并说明需要执行的交易范围（例如Uniswap 请求Approve 与Swap 的权限）。
生成Session Key：使用者在钱包中点击同意后，DApp 获得一个Session Key，该Key 对应于使用者同意的授权范围。
简化交易签署：当使用者操作DApp 并需要发送交易时，DApp 使用Session Key 签署交易并提交到链上，过程中无需用户再次确认。

透过Smart Session，使用者的点击次数可以减少到仅需一次，同时授权流程变得直观，类似Google 或Facebook 的OAuth 体验。这种设计符合钱包与DApp 连接的终极目标：「Less Clicks & More Control」，即在减少用户操作的同时，保持用户对授权的完全掌控。

安全风险与解决方案

Smart Session 虽然优化了使用体验，但也带来了一些安全风险，尤其是Session Key 泄漏的可能性。考虑到浏览器端是前端攻击（如XSS）的高发地点，如何安全地储存与管理Session Key 是必须解决的问题。

Passkey 是实现Session Key 安全存储与签名的良好选择，因为它能大幅降低泄漏风险。同时，Session Key 的设计应保证丢失后对用户的影响最小，用户只需重新授权即可恢复使用。

Intent Centric Design

随着上百条L2 的诞生，使用者的资产逐渐分散到不同链上。这种分散性带来了跨链操作的复杂性，不仅速度慢，体验也相当不友好。在应用层面，越来越多的协议开始采用Intent Centric Design（意图导向设计）来解决这些问题。这种设计理念的核心在于，用户只需表达自己的目标意图（Intent），而不需要关心具体实现方式，将操作的复杂性·交由Solver（解决者）处理。从过去的「自行开车到目的地」到如今「叫Uber 即可」，这正是Intent Centric Design 带来的使用体验转变。

ERC-7683：跨链意图的标准化实现

ERC-7683是由Uniswap 和跨链桥Across 提出的跨链意图标准，它让用户只需签署跨链操作的意图，由Solver 负责完成具体请求，支援以下常见场景：

资产跨链移动：将A 链上的X Token 移动到B 链。
跨链资产兑换：在A 链上的X Token 换成B 链上的Y Token。
跨链后的复合操作：在完成跨链兑换后执行目标链上的合约操作，例如购买NFT。

使用者只需一键操作，即可完成如「将ETH 从以太坊跨链至Arbitrum 并购买NFT」的复杂任务，且整个过程可在三秒内完成。

ERC-7683 的操作流程如下：

记录意图：使用者在A 链将资产存入ERC-7683 合约，并记录其操作意图（Intent）。
Solver 锁定意图： Solver 监听Intent，判断是否符合其能力与利润需求，然后在A 链锁定该Intent。
执行跨链意图： Solver 在B 链垫付资金完成用户的目标操作，例如转移Token 或兑换资产。这种「先垫款后操作」的模式大幅提升操作速度。
结算与支付：协议在A 链上基于B 链的最终状态（finalized state）每小时进行结算，计算Solver 的服务费并支付。

使用者支付的手续费基本等同于一小时的借贷利息。这种模式比传统基于讯息的跨链协议效率更高，因为其采用了批次结算方式，减少了跨链讯息传输的成本，无需每笔交易都传送一个跨链的讯息。

灵活性与挑战

ERC-7683 允许开发者自定义结算逻辑，让合约决定支付Solver 的条件。这样的灵活性也带来以下问题：

流动性碎片化： Solver 可能因不熟悉或信任特定的结算逻辑，而选择不参与某些合约的Intent，导致不同Settlement 合约间的流动性缺乏竞争性。
安全性风险：若结算合约出现问题，Solver 可能无法收回垫付资金，增加了参与风险。

为解决这些问题，可在Settlement 合约采用模组化设计，让结算逻辑简单易懂且易于审计，从而吸引更多Solver 提供流动性。

ERC-7683 与EIP-7702 的结合应用

未来结合EIP-7702，ERC-7683 能实现更高效的跨链操作。例如，透过一个chain ID = 0 的签章升级所有EVM 链的EOA 为智能合约钱包，使用者可将Intent 设定为「在B 链执行某操作」，并以目标链上的身份完成交易。这样，用户可在A 链上管理资产，同时请求Solver 在其他链执行交易并支付对应的Gas。此过程中，Solver 的角色不仅执行交易，还帮助减少Gas 成本，实现完全去中心化的解决方案。

CoW Swap 的Intent 解决方案

CoW Swap 在单链场景中推动了Intent 的应用，专注于优化Swap 体验。其核心特点包括：

聚合多个Intent： Solver 可同时计算多个Intent 的最佳交易路径，例如同时满足A 使用者想用X Token 换Y Token，与B 使用者想用Y Token 换X Token 的需求。
减少手续费：此方法避免了使用者分别与流动池进行交易的成本，带来理论上的最佳价格。

然而，CoW Swap 的解决方案对Solver 提出了极高的技术要求：

流动性获取：必须快速从多个DEX、中心化交易所（CEX）及跨链资源中获取流动性。
演算法优化：如何快速聚合并计算最优交易路径仍是未解的最佳化问题。
精准执行：在链上执行交易时需避免MEV（最大可提取价值）攻击，同时在CEX 执行交易也需确保价格的精准度。

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

在交易场景的Intent 解决方案之外，Daimo 提出了Cross L2 Intent Address的设计，为跨链支付与DeFi 操作带来了更高效的方式。该设计允许使用者在source chain上将USDC 发送到一个指定地址，通过relayer在destination chain执行后续操作，例如将USDC 跨链后进行特定的DeFi 操作。整个过程完全去中心化，适用于跨链支付、一键投资等场景。

技术实现原理

这一设计的核心依赖于Circle 的CCTP 跨链桥和以太坊的CREATE2机制，通过结合这两者实现用户Intent 的自动化执行。

CCTP 的目标地址指定：在使用Circle 的CCTP 跨链桥时，用户可以指定目标链上的接收地址。如果该地址是一个智能合约，relayer 就能在接收USDC 前执行合约中定义的操作。执行完成后，relayer 再通过CCTP 获取跨链的USDC 作为报酬。这种机制使得relayer 能在资金到达前完成用户的Intent，大幅提升交易速度与用户体验。
CREATE2 的地址预计算：在source chain 上，使用者需要事先确定目标链上的Intent 合约地址。这可以通过CREATE2机制实现：CREATE2 允许在合约未部署时就计算其未来地址，只需提供合约的byte code 和一个salt。这样，用户在source chain 上的操作即可预先确定目标链的合约地址。
Relayer 的执行流程：首先在destination chain 部署智能合约，并呼叫智能合约以执行用户的Intent（例如参与DeFi 协议）。最后在同一交易中呼叫selfdestruct，清空合约的code storage并获得gas fee refund。

这种做法相比ERC-7683 更简单，但需要在交易过程中部署合约，导致增加一些gas 费用。不过，由于部署的合约只是小型的proxy contract，指向预先部署好的implementation contract，因此额外成本相对有限。

Chain Abstraction

Chain Abstraction的核心理念是隐藏区块链的存在，让使用者专注于资产本身，而非背后的链。这意味着使用者只需知道自己拥有多少USDC、ETH 等资产，而不用关心它们分散在哪些链上。当使用者发起USDC 的转帐时，系统会自动检测并整合所有链上的USDC，完成转帐所需的跨链操作。同时，使用者不需要为Gas 费烦恼，可以直接用转帐的USDC 支付Gas。

Biconomy Modular Execution Environment

Biconomy 提供了Modular Execution Environment (MEE)解决方案，专为支持Chain Abstraction 而设计。这个系统允许ERC-4337 钱包的开发者轻松定义跨多链的操作，并将其整合为一个Supertransaction。使用者仅需签署一次对Supertransaction 的授权，即可实现以下功能：

在多条链上执行指定的User Operations。
自动完成跨链操作并达成最终目标。

其技术基础在于用户对所有操作生成一个Merkle Root Hash签章，然后透过Modular Execution Environment 自动将这些操作上链执行。

其他解决方案

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

ZeroDev：提供了类似的SDK，让开发者可以方便地批量发送多链交易，简化操作流程。
OneBalance：提供了Credible Account模组，支持整合多链的资产并实现Chain Abstraction。
Particle Network：采用Account-level Chain Abstraction，专注于网页钱包的体验，率先打造具有Chain Abstraction 的应用。
Nekodex：结合Chain Abstraction 以及基于Passkey 的Account Abstraction 统一DEX 上多链的交易体验，降低使用门槛

Part 3: Dev Tools

以太坊的开发生态持续进步，各种工具大幅提升了开发者的效率，无论是在测试网的模拟、智能合约的除错，还是区块链资料的索引，都有显著的创新。以下是几款值得关注的工具与解决方案。

Tenderly Virtual Test Net

Tenderly Virtual Test Net是一个强大的虚拟测试网工具，允许开发者fork 主网，其特色是能与主网保持即时同步状态。同时它支援：

无限制的资源模拟：开发者可以随时取得测试网上的以太坊或任意修改Storage 状态。
CI 整合：通过Github Action，开发者能快速生成干净的测试环境，用于合约部署与自动化测试。

Simbolik

Simbolik是专为Solidity开发设计的除错工具，与VS Code无缝整合，只要在测试上方案下Debug 就能执行。它的功能包括：

完整的EVM 环境可视化：能即时检查每行Solidity 代码执行时的stack、memory和storage状态。
EVM bytecode 分析：直观展示编译后的EVM bytecode 的执行过程。

Simbolik 为开发者提供了高效且细致的除错支持，帮助快速定位并解决合约中的问题。

TrustBytes

TrustBytes是一款将Solidity 程式码转化为图像化呈现的工具，特别适合合约审计。它的核心功能包括：

函数调用关系可视化：清晰显示合约中所有函数之间的调用路径。
变数读写追踪：快速定位变数的读写位置，分析潜在Re-entrancy 风险。
恶意输入分析：标示出哪些函数参数来自使用者输入，帮助预防恶意攻击。

TrustBytes 通过缩短代码追踪的时间以提升审计效率，特别是在分析潜在攻击点方面。可参考其Demo 网站。

Ethereum Indexer

以太坊的资料结构让直接从JSON RPC 获取资料效率低下，因此需要透过Indexer 将资料提取并存储到高效的资料库中。以下是两个值得关注的解决方案。

Index Supply 的Shovel

Shovel 是一款开源工具，允许开发者透过简单的config 档，将链上资料转化为指定格式并储存到PostgreSQL DB。例如，纪录一个钱包的历史ERC20 Token Transfer 可以这样设定：

{
"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 能快速完成资料的提取与存储，大幅降低开发成本。

Reth Execution Extension

Reth Execution Extension提供了一种新颖且高效的设计，针对链上资料索引与Re-org（链重组）处理，解决了传统方法中的诸多痛点。

过去，如果使用geth等节点软体来扩展功能，往往需要直接修改节点内的程式码，这样的做法相当于对节点进行了fork。一旦上游节点有更新，开发者还需要持续合并更新的程式码，这无疑增加了开发与维护的复杂性。

Reth 的创新之处在于其设计为可直接作为library import，开发者不需要fork 或修改节点本身的程式码，就能灵活扩展节点功能。

核心特点与通知机制

Reth 提供了清晰且灵活的通知介面，用于处理区块链的三种状态变化：

ChainCommitted：新区块被确认（Committed）。
ChainReorged：链重组导致出现新旧链切换。
ChainReverted：区块被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

安全问题一直是区块链领域的核心挑战，从开发环境的设置，到设备与用户端的保护，再到DeFi 合约层面的防御，都需要严密的措施来降低风险。以下针对开发、设备与DeFi 安全三大主题进行探讨。

开发环境安全（Dev Security）

在区块链应用的开发过程中，环境的安全性往往容易被忽视，但它可能成为骇客的突破口。

VS Code 信任机制的潜在风险

当开发者在VS Code中开启一个恶意的Repo 并点击「Yes, I trust the authors」后，骇客可能利用.vscode 资料夹内的设定执行任意脚本，包括：

窃取电脑中的secret 或private key。
开启一个reverse shell，让骇客远端控制电脑。

这是因为.vscode 中的Tasks可以设置触发特定条件的自动执行脚本（详见官方文档）。这种漏洞可能导致开发者的整个系统处于被骇客接管的风险中。

防范措施：使用Sandbox 环境

为避免上述风险，开发者应在Sandbox 环境中开启专案。具体来说，可以使用VS Code 的Dev Container 功能，在Docker 容器中执行完整的开发环境。这样即使恶意代码执行，也只会影响隔离的容器，不会危及主机系统。

Github Action Self Hosted Runner 的风险

Self Hosted Runner 是Github 提供开发者自行建置CI 环境所需机器的解决方案。然而如果在Public Repo 启用Self Hosted Runner会带来潜在威胁：

恶意用户可以Fork 该Repo 并修改Github Action 的脚本，执行任意命令。
这可能导致Runner 被入侵，骇客窃取所有Github Token 和Secrets。

这一风险已被详述于Synacktiv 的报告。建议避免在Public Repo 中使用Self Hosted Runner，或采用更严格的权限管理。

设备安全（Device Security）

Ledger 的研究显示iOS 和Android 平台的Syncable Passkey实作并不像预期中那么安全。主要问题在于：

私钥复制到应用程式记忆体：虽然Passkey 本应依赖Secure Enclave 来存储私钥，但实际上私钥可能会被复制到应用程式记忆体（application memory）。这使得私钥暴露于潜在的恶意软体攻击之下，例如透过监听记忆体来窃取私钥。
记忆体快取问题：某些平台的快取机制会在装置解锁之前就将私钥暂存到记忆体中，进一步增加了被恶意软体利用的风险。

安全建议

为了降低使用Passkey 带来的风险，建议采取以下措施：

选择Un-syncable Passkey：在创建Passkey 时，选择「不可同步」（Un-syncable）的选项，避免私钥在不同设备之间同步时的潜在安全问题。
避免存放大量资金：不要将过多资金存放于Passkey 钱包中，仅作为小额支付或日常操作使用。
使用硬体钱包：对于高价值资产，建议继续使用硬体钱包作为主要的存储方式，因为硬体钱包提供了更高的安全保证。

这些建议可以有效降低Passkey 在日常应用中的潜在风险，同时确保资产的安全性。

DeFi 安全（DeFi Security）

区块链应用最核心的DeFi 领域，因其高额资金流动性，成为骇客攻击的主要目标。防范这类风险需要智能合约与基础设施层面的共同努力。例如Forta提供了一种基于AI 模型的链上防火墙，用于过滤潜在攻击交易。其运作机制如下：

交易签名验证：DeFi 合约需要为合约中的关键方法加上Forta 的签章参数
交易模拟与风险评估：Forta 的RPC 节点将模拟交易执行过程，通过AI 模型评估风险分数。 Fora 已经实现99% 以上的准确度
执行控制：只有风险分数低于门槛值的交易才会获得签名并被放行。

因此这个做法必须由DApp 透过Forta 提供的RPC 发送交易才可以，如果使用公开的RPC 则无法取得必要的签章。但这也带来潜在的问题与挑战：

升级与整合困难：DeFi 协议需要修改合约以整合Forta 的系统，这对现有协议的升级是一大挑战，尤其是影响到可组合性，因为其他DeFi 协议就无法轻易呼叫自己的合约。
交易模拟问题：在链下的环境模拟交易执行的结果可能与实际上链的结果不同，有机会被骇客利用
顺序依赖问题：由于L2 链上交易的执行顺序是由Sequencer 决定，骇客有机会透过交易顺序的不一致性来在模拟时产生正常的结果，拿到签章后上链执行恶意交易

至于如何解决第二个问题，知名交易安全检测公司Blowfish 的CTO 提到，可以在模拟交易过程检测该交易是否使用了与EVM 环境参数相关的逻辑，例如block.timestamp 或block.basefee 等等，但也无法保证100% 判断正确，因此精准的交易模拟仍然是安全领域待解决的难题。

Part 5: Fuzz Testing

Fuzz Testing 是一种强大的测试技术，其核心原理是透过大量随机的输入测试智能合约，试图触发意外的逻辑漏洞。这种方法对于捕捉人眼难以察觉的边缘情境（corner cases）尤其有效。

Fuzz Testing 的原理与限制

Fuzzer 的主要作用是持续尝试各种随机输入来检测智能合约是否能满足定义的Invariant（不可变条件）。开发者可以利用这种方法进行黑箱测试，模拟合约的实际使用情境，并验证其逻辑是否能抵抗各种异常操作。

尽管Fuzz Testing 是捕捉逻辑漏洞的有效工具，但找不到漏洞并不代表合约没有问题。 Fuzzer 的效果取决于定义的Invariant 是否完善，以及随机测试的覆盖范围。

案例分析：Vesting 合约漏洞

以下是一个简化的Vesting智能合约范例，其目的是实现用户的积分分配与转移，完整程式码在solidity-fuzzing-comparison Repo 中的09-vesting 。然而，该合约存在一个漏洞：用户可以通过「自我转移」增加自己的积分，进而破坏总积分不变的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;
}
}

用户可以将自己的积分转移给自己（self-transfer），导致总积分超出限制，破坏合约中「所有用户积分总和应等于总分数」的Invariant。然而就算我们不细看transferPoints的实作，也能透过对其黑箱的Fuzzing 来找到问题。

设计Invariant：思考不可变条件

在测试此合约时，可以设计以下两个主要Invariant：

初始化阶段：所有用户的积分总和应等于TOTAL_POINTS。
执行阶段：在任意操作后，所有用户的积分总和仍应保持不变。

这些Invariant 可以被用于多个Fuzzer 的测试过程中。

使用Chimera 框架进行测试

Chimera 是一个功能强大的多工具整合框架，允许开发者一次撰写测试代码，并同时在多个Fuzzer 工具上执行。以下是使用Chimera 的步骤：

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

2、设定测试环境：建立一个Setup.sol 文件来初始化测试合约，并追踪需要检查的状态。

// 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、实现Invariant：定义检查条件，例如所有用户的积分总和应等于总积分。

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、定义如何测试目标函数：指定transferPoints 参数需满足的条件，避免因错误参数导致的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、执行Fuzz Testing

forge test --match-contract VestingCryticToFoundry

可以看到Fuzzer 在短时间内就找到了打破不变量的方法

修复漏洞

漏洞的解法是避免自我转移：

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

修复后再执行一次测试即可通过了

Fuzz Testing for ZK Infrastructure

零知识基础设施（Zero-Knowledge Infrastructure, ZK Infra）涉及编译、执行、生成证明与验证ZK 电路的多个核心软体元件，对其进行漏洞检测至关重要。 Fuzz Testing 是检测这些基础设施漏洞的一项强大工具，尤其适合处理其高复杂性与高安全需求的特性。

基于黑箱测试的随机变换与不变性检测

零知识基础设施的测试需要克服其内部实现的高度复杂性，黑箱测试因此成为检测漏洞的有效方法。在这种测试中，开发者将处理流程视作不可见的黑箱，仅根据输入和输出进行分析。

首先，测试工具会随机生成一个原始电路（C1），这些电路通常以小型DSL（特定领域语言）描述，用于模拟用户操作。接着，应用一系列随机变换来生成新电路（C2）。这些变换包括乘以1、加减随机表达式或其他等价操作，保证电路语义不变。随后将两个电路各自进行ZK 工具的编译处理，若在任何阶段输出或行为不一致，即可定位到处理流程的漏洞。

例如，一个表达式P 转换为P × 1 − 0 时，应保持输出一致，否则可能指向Witness Generator 或编译器中的潜在问题。

持续且多元测试

由于零知识基础设施经常被用于Layer 2 协议，将乘载数亿美金以上的价值，其安全性至关重要，因此持续测试显得尤为必要。这可以通过自动化测试工具来实现，保证每次代码更新后都能迅速发现潜在漏洞。

测试还需要支持多种零知识DSL，如Circum、Gnark 和Noir，确保适用于广泛场景。同时，Fuzz Testing 工具应具备自动化反馈功能，能够持续执行并根据发现的问题进行改进。此外，测试生成的输入应尽量简化，以便开发者快速理解并定位问题。

Part 6: Formal Verification

Formal Verification（形式化验证）是一种透过数学方式验证软体是否符合特定Formal Spec（规格）的技术。对于智能合约而言，这种方法能有效检查合约在所有可能状态下的正确性。与Fuzz Testing（模糊测试）相比，Formal Verification 的验证过程更为系统化，能够覆盖所有可能的状态并「数学证明」合约逻辑的正确性。

然而，Formal Verification 的实施通常需要严谨的规格定义，且计算成本较高。另一方面，Fuzz Testing 则透过随机输入测试合约，具有轻量且能快速发现边界问题的特性，但其测试范围有限，可能无法检测更深层的逻辑漏洞。

Certora

Certora 提供了一套完整的工具来弥补这些不足，帮助开发者在现实环境中应用Formal Verification。其主要产品Certora Prover为智能合约提供了强大的验证框架，允许开发者定义规则并自动化验证合约的逻辑正确性。

Certora 提供的工具旨在简化智能合约的形式化验证过程，核心功能包括：

Certora Prover：一个验证平台，允许开发者使用Certora Verification Language (CVL)定义规格并测试合约逻辑。
整合式框架：透过设定档与脚本执行验证。
详细报告：自动生成验证结果，包含失败的详细原因与对应的测试输入，协助快速定位问题。

使用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：撰写规格

以下是一个简单的规格，检查totalVotes 是否在每次投票后递增：

rule voteIntegrity(env e) {
uint256 votedBefore = totalVotes();
bool isInFavor;
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：执行验证

在专案根目录执行以下指令：

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

如果还没有API Key，可以在官方网站注册取得。输出中会有一个Certora Prover 结果的连结，点进去即可看到Prover 找到了一个错误，并提供详细的输入参数

步骤4：修复问题

修改合约逻辑以修复问题：

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：重新验证

再次执行验证，确认所有规范均已通过，代表此智能合约的正确性可被数学证明。

进阶功能：验证不变性（Inductive Invariants）

Certora 也支援定义不变量规则（Invariant Rules），确保合约在所有状态下的逻辑一致性。例如：

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

此规则验证totalVotes 永远等于赞成与反对票数的总和。

Part 7: Maximal Extractable Value (MEV)

在文章的前半部分中，我们已提到Intent Centric Design，其中介绍了CoW Swap 如何透过设计应用层的逻辑来简化跨链交易并提升用户体验。在这一部分，我将深入探讨CoW Swap 如何解决Maximal Extractable Value (MEV) 问题，以及其主张MEV 应在应用层解决的理念。同时，我们也会介绍Unichain 如何通过可信执行环境（TEE）在基础设施层解决MEV 问题，呈现两种截然不同但互补的解决方式。

CoW Swap 的MEV 解决方案

CoW Swap 的核心主张是，MEV 问题的根源在应用层。目前约99% 的MEV 问题来自交易排序的竞争，而应用层（例如去中心化交易所DEX）的设计是导致这些问题的主因。因此，MEV 问题应该在设计应用时一并考虑，而非依赖基础设施层的迂回解决方案。

Coincidence of Wants（需求的巧合）

CoW Swap 引入需求巧合的概念，通过将多笔交易的需求聚合在一起，使交易者直接匹配需求，避免了流动性池的中间操作，从而减少MEV 攻击的可能性。

案例：假设Alice 想用100 USDC 换取1 ETH，而Bob 刚好想用1 ETH 换取100 USDC。在传统DEX 中，这些交易需要分别通过流动性池进行，可能会被套利者利用滑点进行MEV 攻击。而在CoW Swap 中，这两笔交易可以直接匹配，无需经过流动性池，消除了滑点和MEV 攻击。

Batch Auction（批次拍卖）

CoW Swap 的批次拍卖机制是其解决MEV 问题的核心手段：

收集交易意图：在链下收集并聚合用户的交易意图。
批次处理：将在特定时间段内收集的交易意图组合成一个批次，这些批次通常每隔几秒钟产生一次。
竞价解决方案：通过竞标机制选择最佳的解决方案提供者（solver），这些提供者竞争以提供最优交易执行方案，为用户带来最大的价格盈余。
统一清算价格：所有涉及相同资产的交易都以统一的清算价格结算，使交易顺序变得无关紧要，从而减少MEV 攻击。

批次拍卖的优势：

MEV 保护：批次拍卖透过统一清算价格，使交易顺序的影响被弱化，显著削减MEV 攻击的空间。
资产匹配：直接点对点交换，无需触及链上流动性。
最佳价格保证：确保用户交易的价格不低于在AMM 上直接获得的价格。

实际案例：

假设有三位用户的交易意图：

用户A 希望以100 DAI 购买ETH。
用户B 希望以200 DAI 购买ETH。
用户C 希望出售1 ETH，目标获得300 DAI。

这三笔订单在批次拍卖中被组合在一起。由于A 和B 的购买需求总和（300 DAI）恰好匹配C 的出售需求（1 ETH），因此可以直接在用户之间进行点对点交换，无需触及链上流动性。这不仅提高了交易效率，还降低了交易成本，并消除了MEV 攻击的风险。

Unichain 的MEV 解决方案

与CoW Swap 将MEV 处理集中在应用层的设计不同，Unichain 选择在基础设施层通过可信执行环境（TEE）来解决MEV 问题。 Unichain 是基于OP Stack 的Optimistic Rollup，其核心创新在于加密交易与TEE 排序，保证交易排序的透明与公平。

Unichain 解决MEV 的关键流程：

加密交易：使用者在发送交易时，首先使用TEE 的公钥加密交易内容。因此，在mempool 中，所有节点看到的交易都是加密的，无法直接得知交易的细节，自然也就无法通过交易排序提取MEV。
TEE 排序：只有在TEE 环境内才能解密交易并进行排序。 TEE 会根据预设的规则排序交易并构建区块，最终生成的排序结果带有TEE 的签章，保证排序过程的透明度。
返还MEV 收益：对于普通用户，Unichain 提供接近零成本的Gas 费，同时完全避免了被抢跑（front-run）的风险。而对于MEV Searcher，他们需要支付更高的Gas 费来竞争区块的前位。这些额外的收益会被Unichain 用于回馈给验证者，形成公平的经济激励。

Part 8: Zero Knowledge Proof (ZKP)

Zero Knowledge Proof (ZKP) 技术的应用展示了如何透过密码学方法，实现隐私保护与效能的平衡。以下将介绍几个令我印象深刻的ZK 应用。

ZKPassport

ZKPassport结合了国际电子护照（ePassport）的晶片技术与ZKP，为用户提供一种既安全又隐私的身份验证方式。透过手机感应护照的NFC，用户可以取得护照晶片中由政府签署的资料，例如基本资讯和照片。由于这基于全球标准（IC AO Biometric Passport），超过100 个国家的护照均可支援。基于此签章即可生成护照资料有效性的零知识证明。

技术特点

隐私保护：用户可选择只验证护照资料的部分条件，例如「年龄是否大于18 岁」或「国籍是否为美国」，而不需要公开完整的护照资讯。
效能佳：ZK 电路使用Noir 编写，在手机上生成证明仅需约5 秒钟

应用场景

Sybil Resistance：可用于防止多重身份诈·骗，例如确保一个人只能领取一次空投。
ZK KYC (Know Your Customer)：在不透露完整身份的情况下，证明用户来自合法的国家或符合其他特定条件。

ZK Email

ZK Email是一个基于零知识证明的Email 验证应用，允许用户选择性地验证邮件内容。例如，证明Email 的发信人是否为特定组织、Email 内文是否有特定文字，而无需公开整封邮件的内容。关键是采用每个Email 都会由Mail Server 签署的DKIM Signature，产生一封信是由该域名发出的零知识证明，且无法被伪造。

技术特点

将可信的Email 资料带到链上验证，串连Web2 资料与Web3
新推出的ZK Email Registry：提供可共享的Email template Registry，开发者可快速使用。如有人收到Devcon 的拒绝信后，写了一个让任何人证明自己有收到拒绝信的template。
更方便的SDK：开发者仅需撰写JSON 设定，而不需了解如何实作ZK 电路，并隐藏具体的ZK 电路实作，如Circom, Noir

应用场景

ZKP2P：透过点对点转帐的确认信，打造法币与虚拟货币兑换的平台，且完全去中心化
Email Wallet Guardian： Email 可作为智能合约钱包的备援手段。例如，用户寄出一封Email 即可恢复钱包的控制权。此功能也能兼容ERC-7579 的模组化Smart Account 架构。
Whistleblowing：在保护个人身份隐私的前提下，以特定组织的身份揭发秘密

技术挑战

DKIM public key 的正确性：在智能合约中需验证DKIM Signature 对应的Public Key 是否真正属于该域名，而这目前只能透过Oracle 提供资料。需要透过像Re-staking 的机制来确保该资料足够去中心化，避免单点故障
在处理较长的邮件时，ZKP 的计算效能面临挑战。团队正在研究递回证明（recursive proof）以支援更高效的body hash 验证。
未来可能支援Email 附件（例如PDF）内容的证明，进一步拓展应用场景，如证明银行的转帐纪录
手机用户体验：由于手机端无法像桌面端下载原始邮件，ZK Email 目前仅能透过OAuth 授权读取邮件。虽然这引发一定的隐私顾虑，但ZK Email 的开源性确保了这些操作仅限于客户端，不会回传Email 资料到服务器。

ZKP2P

ZKP2P是一个基于零知识证明技术的域名交易市场，旨在提供快速、安全、去中心化的域名交易体验。该平台支持利用零知识证明验证域名所有权，并使用ETH 进行域名交易。目前ZKP2P 已支援使用者交易Namecheap 上的域名。

域名交易的核心机制

域名所有权验证：平台使用一种基于密码学的Web 认证协议来验证域名的所有权。卖家需使用ZKP2P 提供的浏览器Extension，从Namecheap 网站生成不可篡改的域名所有权证明，并提交到智能合约中。
交易过程中的隐私保护：买家在提交购买申请时，需提供Namecheap 用户名，该资讯会加密处理，仅卖家可见。
资金锁定：买家的ETH 会先被锁定在智能合约的托管中，直到卖家完成域名转让并提供相关的零知识证明后，资金才会释放。
零知识证明的使用：卖家转移域名后会收到Namecheap 的确认信，因此ZKP2P 使用ZK Email 产生这封信的零知识证明，确保域名已转移给买方。

技术特点与优势

隐私与安全性：ZKP2P 通过加密用户敏感资讯（例如Namecheap 用户名）来保护隐私，确保只有域名卖方能看到买方的用户名。
去中心化与透明性：平台所有的交易验证过程均在智能合约中执行，减少对第三方的依赖，并提高整体透明度。
降低交易成本：每笔交易仅收取2.5% 的交易费用，远低于其他域名交易市场（一般超过10%），让买卖双方都能享受更低的交易成本。

Polygon ZisK

Polygon 正在开发新一代的ZKVM 证明系统ZisK，目标是实现即时证明整个EVM 区块中所有交易的计算。 ZisK 的设计核心在于其通用性（Generic ZKVM）和极致的证明生成速度优化，旨在提升零知识证明在区块链应用中的性能。

ZisK 的设计架构

ZisK 的架构受到嵌入式系统（Embedded System）的启发，采用了模组化的设计，主要组件包括：

ROM（只读存储器）：储存ZKVM 的程序逻辑和静态数据。
ZisK Processor（处理器）：负责执行电路的核心计算逻辑。
RAM（随机存取存储器）：用于储存临时数据和中间结果，支援高效的数据访问。
Bus（总线）：负责连接ZisK 系统内部的各模组，协调讯息交换。

目前，ZisK 还处于非常早期的开发阶段，可参考其开发文件。

Reclaim Protocol

Reclaim Protocol 是一个将TLS Proxy 技术与零知识证明（Zero-Knowledge Proof, ZKP）相结合的隐私保护协议，旨在让用户能够在不泄露敏感资讯的前提下，验证HTTPS 通讯内容的真实性。该协议为资料验证与互操作性提供了安全的解决方案，尤其适用于Web2 和Web3 场景的整合。

TLS Proxy 机制

Reclaim Protocol 的核心依赖于TLS Proxy 作为信任中介。过程中HTTPS 请求和回应会经过TLS Proxy，并由Proxy 签署该流量的加密内容，从而为后续的证明生成提供基础。 TLS Proxy 的角色仅限于签署加密流量，无法解密任何资料，这也减少了隐私风险。

TLS Proxy 的一个重要功能是处理使用者和伺服器之间的HTTPS 流量，并保证这些流量来自正确的伺服器。例如，在证明某银行网站的余额资讯时，TLS Proxy 签署的加密流量可以确保数据未被篡改，并提供可信的资料来源。

然而尽管TLS Proxy 提供了关键的信任保障，在极端网路条件下（例如BGP Hijack 攻击），可能会出现Proxy 认证的流量被路由到错误伺服器的风险。这种攻击需要在TLS Handshake 后精准篡改流量，实现难度极高，但这仍是协议中需要特别关注的安全边界。

zkTLS 技术细节

Reclaim Protocol 结合了ZKP 技术，允许用户在不泄露完整TLS 明文的前提下验证其真实性，其ZK 电路的设计旨在处理解密与部分揭露的功能。

协议中的ZK 电路能够解密特定的TLS 流量，并仅揭露其中需要验证的部分资讯。例如，用户可以提供AES 解密金钥作为Private Input，在电路中解密TLS 流量，并公开指定区域的明文资讯。这些操作基于gnark 框架进行，确保了高效的证明生成。

值得注意的是，Reclaim Protocol 提供了透过Regular Expression 或是HTML template 匹配TLS 流量的功能，而这一匹配逻辑被设计为在电路外实作，以避免电路过度复杂。因此客户端需首先自行透过Template 定位哪些AES Block 中有包含所需的明文，再生成ZK 证明来证实匹配结果。这样导致的资安风险是，如果TLS Payload 中在其他部分也出现了类似的字串，客户端则有机会伪造证明。

应用场景

Reclaim Protocol 目前将重点放在Web2 场景的资料互操作性上，解决不同平台间的数据共享问题。例如：

电商优惠：用户可以从A 电商生成消费记录的ZKTLS 证明，并将其提供给B 电商以获取专属优惠，精准吸引新用户。在这一过程中，协议可确保B 电商只能知道消费总金额，而不会接触完整的消费明细。
身份验证：用户可使用协议生成ZKTLS 证明，证明其在特定平台的活动，如在某论坛的参与情况，或在某开发者平台的贡献数据。

技术与信任的挑战

信任TLS Proxy：协议需要用户信任TLS Proxy，因为Proxy 会签署HTTPS 流量，成为证明可信来源的基础。
ZK 证明的链上应用：由于目前ZK 证明的链上验证成本较高，Reclaim Protocol 将应用重点放在Web2 场景，尚未在链上进行完整的ZK 验证。
网路攻击风险：极端情况下，如BGP Hijack，可能导致TLS Proxy 无法正常运作，但这类攻击需要精确的时间和网路控制，实现难度极高。

vLayer

Vlayer是一家专注于开发「可验证资料基础设施」的加密初创公司，称之为「Solidity 2.0」。其目标是使开发者能够将真实世界的资料验证后整合至以太坊智能合约中。具体而言，Vlayer 为Solidity 语言引入了四个新功能：

Time Travel：允许智能合约使用历史链上资料。
Teleport：使合约能在多个EVM 兼容的网络上运行。
Web Proofs（zkTLS）：验证并整合网页内容，包括API 和网站。
Email Proofs（ZK Email）：存取并验证电子邮件内容。

这些功能旨在扩展智能合约的应用范围，特别是在去中心化金融（DeFi）、真实世界资产（RWA）和游戏等领域。目前，Vlayer 正处于Alpha 阶段，邀请开发者在其平台上进行开发，并计划于2025 年推出测试网、主网和代币。

Mopro

Mopro（Mobile Prover）是一个专为Mobile 环境开发的ZK 证明生成工具，以简化客户端的证明过程。 Mopro 的主要特点包括：

易用性：简化了在移动应用中整合ZK 证明的复杂性
高性能：比在浏览器上使用snarkjs 更快，并尝试使用GPU 优化性能
跨平台兼容性：支援iOS、Android 平台

然而，在Mobile 环境下仍存在一些挑战：

GPU 加速的限制：虽然Mopro 尝试利用GPU 提升性能，但由于移动设备使用的Metal API 不如桌面端CUDA 易于优化，开发上面临一定难度。然而，数据显示在处理大型电路时，Mopro 的性能表现有望优于其他传统工具。
记忆体限制：Mobile 设备的记忆体容量有限是主要挑战之一，特别是在运行复杂的ZK 电路（如ZK Email）时，可能会因内存不足导致应用Crash

Part 9: Multi-Party Computation (MPC)

MPC是一种密码学技术，允许多方在不泄露各自输入的情况下，共同计算一个函数的结果。其与ZK 的差别在于：

MPC需要多方参与计算，且所有人都能隐藏输入的内容。
ZK：仅需一方（Prover）生成证明，另一方（Verifier）验证其声明是否正确，无需多方协作。因此Prover 需要知道所有计算过程的资料。 ZK 保障的是Single Player Privacy。

以下介绍几个MPC 的应用与最新研究，展示其在隐私保护与分布式计算中的潜力。

World ID

World ID是Worldcoin的核心技术，旨在为每位用户建立独特的数位身份，用以证明个人的「唯一性」。注册过程中，使用者需透过「虹膜扫描」验证身份，确保每人仅能注册一次。这需要将新扫描的虹膜与已注册的数据库进行比对。然而，大量集中存储的真实虹膜数据可能带来巨大的隐私风险。

为解决此问题，Worldcoin 与Taceo合作，探索基于MPC 的去中心化虹膜比对方案。

技术细节与流程

资料的Secret Sharing：用户的虹膜扫描资料被拆分为三个Secret Share，分发给三个计算方，确保单一计算方无法取得完整的虹膜资料。
Hamming 距离计算：透过内积运算将用户的虹膜资料与资料库中的虹膜逐一比对，计算Hamming 距离并与设定的阈值进行比较。整个过程在MPC 框架下执行，确保数据隐私不被泄露。
结果聚合：将比对结果以逻辑OR 聚合，产生最终的验证结果，判断虹膜的唯一性。

World ID 最大的技术挑战在于计算成本高昂：Worldcoin 的使用者数已超过1,600 万，每次唯一性验证需要针对庞大的数据库进行线性扫描。在GPU 加速环境下，一次验证需要32 台NVIDIA H100 GPU，峰值网络吞吐量达2.5 Tbps。

因此，Worldcoin 正积极探索计算资源需求更低但验证严谨度相对较低的替代方案，例如借鉴ZKPassport的护照唯一性证明机制，以在减少成本的同时保持足够的验证可信度。

MPCStats

MPCStats是一个基于MPC 的开源框架，旨在实现多方参与的统计计算，同时保护数据隐私。该框架允许多个数据提供者匿名参与计算，结果公开但不泄露个人数据细节。

技术特点

隐私保护：数据提供者的资料以秘密共享的方式进行处理，并且在计算过程中保持加密。
整合TLS Notary：使用TLS Notary 确保输入数据来自可信来源，避免「垃圾输入」影响结果。
支持多种统计操作：包括平均值、中位数、吉尼系数等常见统计指标，以及数据筛选和Join Table 操作。

展场Demo

在Devcon 展会中，MPCStats 提供了一个Demo，让参与者私密分享其Binance ETH 余额，计算平均值。数据的完整性由TLS Notary证明，最终生成可信且隐私保护的统计结果。

Public Auditable MPC

Public Auditable MPC（PAMPC）是一种结合MPC 和零知识证明（ZK）的新型协议，旨在解决现有MPC 系统中无法向第三方验证计算正确性的挑战。该协议允许计算方在保护输入隐私的同时，向第三方公开验证计算结果的正确性。

核心概念与技术

引入Collaborative ZK-SNARKs：PAMPC 使用协作式ZK-SNARKs，将每个计算方生成的部分证明（proof）进行线性聚合产生完整证明，确保计算的正确性可被第三方验证。
处理输入一致性问题：在MPC 的预处理和在线阶段中，透过对输入数据进行Commit，确保数据的一致性。
加速位元运算：传统的SPDZ MPC 协议对于加法和乘法支持良好，但在处理位元运算时效率低下。 PAMPC 对SPDZ 进行了优化。

应用场景与优势

电子投票：在保护选民隐私的同时，提供公开验证机制，增强系统透明度同时保护隐私。
去中心化拍卖：确保拍卖结果的公正性，同时保护投标者的隐私。
医疗数据与机器学习：PAMPC 特别适合于需要多方共享敏感数据的场景，例如多机构合作训练机器学习模型。各机构可以保留数据隐私，同时协作完成模型训练或预测。
去中心化游戏：PAMPC 可被应用于去中心化游戏中，如狼人杀（Werewolf/Mafia）游戏，通过MPC 确保角色分配、投票计算的隐私性与正确性，而不需要游戏主持者(GM) 。

Part 10: Programmable Cryptography

0xPARC 提出可程式化密码学（Programmable Cryptography）概念，指出此技术是从「专用型密码学」转向「通用型密码学」的世代革命。

过去，密码学工具为特定用途而设计，如RSA 加密、椭圆曲线签章等等。当人们需要新的功能，就必须发明新的密码学协议来满足需求，如Group Signature 协议可以让个人代表一群人签署资料，而不透露具体身份，这与RSA 加密演算法的设计有显著差异。

相对而言，可程式化密码学将密码学设计的数学问题转化为工程问题，允许开发者写程式来实现任意密码学操作。以下是一些重要技术：

零知识证明（zkSNARKs）：证明程式在私密输入上的正确执行，无需泄露输入。
多方计算（MPC）：在多方私密数据上进行计算，仅揭示最终结果。
完全同态加密（FHE）：允许在加密状态下执行任意运算，运算结果仍为加密状态。
不可区分混淆（iO）：将程式加密，让程式可执行但不可解析内部逻辑，被誉为密码学的「圣杯」，因其能构建所有其他密码学工具。

最理想的Internet

可程式化密码学能帮助实现Internet 的理想状态，包括：

去中心化（P2P）：恢复网路对等性，避免数据和计算集中化。
隐私保护：让数据拥有者控制其数据使用方式。
资料互操作性：不同应用间数据能无缝流转并保持真实性与隐私。
信任最小化与无需许可：用数学保证取代对中央机构的信任，任何人均可参与。

例如，MPC 与FHE 技术让伺服器在完全不了解用户数据的前提下，完成计算任务，同时确保计算结果的可验证性，这代表使用者资料将永远由自己掌控。

以下透过两个例子解释，为何有了可程式化密码学后，能建构理想的社交网路与投票应用。

去中心化Facebook

过去当人们思考去中心化社交网路时，总是想先模仿Twitter，原因是Twitter 的机制较为单纯：每个使用者可以公开发布内容，任何人都能看到其他人的内容。然而相较于去中心化Twitter，去中心化Facebook 的实现更加复杂，因其数据拓扑和隐私要求更高：

隐私设置：用户可能只想让特定好友查看特定内容。
朋友的朋友权限：需动态计算贴文可见性范围。
推荐演算法（News Feed）：需要整合多方数据进行运算。

此外，这些应用需要处理隐私的全域状态（Private Global State），例如推荐演算法的参数可能无任何单一方知晓，但系统仍需保证其正确运行。这些挑战只能透过可程式化密码学解决。

投票系统的技术演进

投票是个很好的案例，因为它需要同时满足许多特性，才能做到公平、隐私且公正。在加入不同的可程式化密码学技术后，能一步步朝向理想的投票系统迈进：

将投票上链：将提供公开可验证的投票结果，以及实现抗审查的投票过程。
加入零知识证明（ZK）：让投票者可隐藏投票内容，保护隐私。
加入MACI (Minimal Anti-Collusion Infrastructure) 机制：可在计票方不泄漏资讯的前提防止贿选，因为投票者将无法证明自己投票给谁。
加入全同态加密（FHE）：进一步将需信任的参与方扩展为M-of-N 模型，只要M 方中有N 个参与方是诚实的，就没有人知道谁投票给谁。另一方面可轻易更换投票系统逻辑（如平方投票法）。
加入不可区分混淆（iO）：将计票程式经过混淆处理，确保就算所有人共谋也都无法知道投票运算细节。

ZuPass

ZuPass是由0xPARC 推出的一个实验性应用，基于可程式化密码学（Programmable Cryptography）的概念设计，旨在帮助使用者实现对自身资料的自主管理与跨平台互操作性。 ZuPass 的核心是Proof-Carrying Data (PCD)，使用者可以在保护隐私的前提下安全储存并证明其数据的有效性。

以下介绍几个在本次Devcon 会场的ZuPass 应用。使用ZuPass 的应用又被称为ZApp

Devcon 门票验证

ZuPass 在Devcon 活动中被用来验证与会者身份，其原理如下：

使用者的Devcon 票券以PCD 的形式存入ZuPass。
当需要进场时，使用者可透过ZuPass 生成零知识证明（Zero-Knowledge Proofs, ZK Proof），证明自己持有有效票券而无需透露身份细节。
此外，还能用于基于身份的Telegram 群组验证，确保只有符合条件的成员可以加入特定群组。

Frog Crypto

Frog Crypto 是一个基于ZuPass 的有趣应用，让参与者在展场中搜集各种类型的青蛙，并生成证明来展示自己拥有的青蛙。其特色在于

资料自主权：参加者完全掌握自己的青蛙数据。
互操作性：开发者可以基于使用者拥有的青蛙资料创建新应用，例如允许使用者将两只青蛙合成为新的青蛙。这与传统Web2 生态的封闭API 截然不同，使用者和开发者不再受限于中心化平台的规则与改动。

Meerkat

Meerkat是促进讲者与听众互动的ZApp，结合了Slido 问答功能与ZK 技术，实现匿名互动。其功能包括：

即时发起问答或投票，讲者和听众能在保护隐私的同时提升互动性。
使用者可透过ZuPass 登入并生成互动所需的证明，而无需暴露个人资讯。

ZuPass 的整合方式

ZuPass 提供方便整合的SDK，达成类似Google OAuth 的方便整合SDK：

用户授权：应用整合ZuPass 后，会跳出ZuPass 弹窗供使用者登入并选择授权哪些资料的读写权限。
资料请求与验证：授权后，应用可向ZuPass 请求特定资料的证明，或对应用程式中记录的数据进行读写操作。

POD 与GPC 技术

ZuPass 建立在两个关键技术之上：Provable Object Data (POD)与General Purpose Circuit (GPC)。这两项技术支撑了像是Meerkat、Frog Crypto 和Devcon 门票验证等应用，实现了数据的隐私验证与互操作性。

POD 是一种以密码学为核心的数据格式，专为零知识证明设计。 GPC 则是一种模组化电路，能根据POD 的结构生成灵活且高效的ZK 证明。

POD 的设计与技术基础

Merkle Tree 结构：每个POD 都是一个扁平的key-value 键值对结构，透过Merkle Tree 压缩成一个唯一的Content ID，用于标识数据的完整性与来源。
签名与验证：POD 的Content ID 由发行者使用ECDSA 签名。
零知识证明友好性：采用ZK-friendly 的Poseidon Hash 函数与模组化数据格式，以加速生产POD 的零知识证明

GPC 的模组化电路设计

GPC 是针对POD 设计的通用电路，只需单一电路即可产生基于POD 灵活的零知识证明。其设计基于模组化架构，包含：

Object Module：验证POD 的Content ID 与签名的一致性。
Entry Module：检查POD 内容的Merkle Proof。
Numeric Value Module：进行数值比较与范围检查。
Membership Module：验证栏位是否在指定列表中。

POD 的不足与挑战

尽管POD 系统具有灵活性与隐私保护能力，但其仍存在以下限制：

单用户技术（Single Player Technology）：POD 的设计限制了其只能由用户本人生成与证明，无法支持隐私保护的多用户协作运算。
无法递回证明：POD 生成的证明仅能被验证，而不能用于生成基于该证明的进一步证明，限制了其应用深度。
与现有系统不兼容：资料生产方需要调整系统来生成具签名的POD，无法直接应用于现有的Web2 资料。

POD 2 的诞生与改进

为了解决POD 1 的缺陷，POD 2 系统应运而生，其引入了「Proof-Carrying Data (PCD)」的概念，使所有数据都带有可验证的证明，并支援多方运算：

支援多用户隐私协作：POD 2 引入了多方计算（Multi-Party Computation, MPC），允许多方基于隐私POD 数据进行联合运算并生成新POD。例如，两位用户可共同计算某条件是否成立，而无需泄露各自的数据细节。
递回证明与计算：POD 2 的证明支持递回计算，允许生成基于现有证明的新证明，构建深度计算图。

并且POD 2 框架支援开发者将任意的Web2 资料转换为POD 格式，以解决POD 与既有系统不兼容的问题，称为「Universal Data Adapter」。例如开发者可将来自ZK Email、TLSNotary 等Web2 系统的资料转换为POD 格式的Proof Carrying Data，让所有系统的资料产生互通性，实现不同系统间的无缝整合。最大的好处在于完全不需修改既有Web2 系统的资料产生逻辑。

POD 2 的技术挑战在于，需依赖于多方全同态加密（Multi-Party Fully Homomorphic Encryption, MP-FHE）实现多个POD 2 之间的共同隐私运算。

PEX 语言

0xPARC 也发明了类似Lisp 的PEX 语言，用于描述POD 2 的数据结构与条件：

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

提供简洁且直观的语法，使开发者能快速建立基于POD 的应用。

Frog Zone 游戏

Frog Zone 是0xPARC 在Devcon 展示的技术游戏，旨在实践最尖端密码学应用，展示全同态加密（Fully Homomorphic Encryption, FHE）和多方计算（Multi-Party Computation, MPC）技术如何结合，创造出具隐私保护和分布式特性的应用环境。这款游戏作为首个多用户MP-FHE 应用，为分布式隐私计算和应用开发提供了重要的技术示范。

游戏玩法

玩家数量：最多支持4 位玩家同时参与。
可见范围：每名玩家只能观察自己周围5x5 方格内的地图，一开始玩家互相看不见。
地图大小：32x32 格子，其中包含怪物、地形障碍以及装备等互动元素。
玩家可选择移动、攻击怪物或捡取装备，提升自己的攻击力与防御力。
游戏中的怪物会随机移动，增加挑战性和游戏趣味性。
玩家需在探索地图的同时攻击怪物，以争取获得最高分数。

技术核心：Multi-Party Fully Homomorphic Encryption

FHE 是一种允许在加密数据上直接进行计算的密码学技术。运算结果仍保持加密状态，只有持有解密密钥的一方可以获取结果。核心特性是「可计算性与隐私性共存」。
将FHE 与MPC 结合可以将FHE 的能力扩展到多方环境，使多名参与者可以在共享的加密状态上进行协作计算。在Frog Zone 游戏中，每名参与者持有部分加密状态的分片，并通过MPC 协议协同完成伺服器功能的模拟。
整个游戏的状态是由四台使用者的机器，加上五台在AWS 云端的机器共同维护与计算，没有任何一台机器能解密出完整的游戏状态。由于是九台机器一起运算游戏状态，就像产生了共同的「幻觉」，也因此这个运算过程被称为Hallucinated Server
每次玩家发出移动或攻击指令时，该指令以加密形式发送至伺服器。伺服器在加密环境中执行状态转换函数，生成新的加密游戏状态。
完成操作后玩家请求可见范围（5x5）的加密数据，并通过多方协作解密获取结果。

技术挑战与限制

运算成本高昂：每个二进制逻辑门的运算耗时约10 毫秒，比传统计算慢10 亿倍，而且每1 bit 明文需要约3,000 bit 的加密资料表示。 Frog Zone 动用5 台AWS 最高规格的192 Core CPU 的机器，每小时花费200 美金，但每个玩家只能每四秒操作一次。
开发模式的转变：MP-FHE 仅支持电路模型，而非传统记忆体模型，开发过程中需要平行模拟所有可能的操作分支。例如，当玩家尝试移动时，伺服器需同时计算所有可能的移动结果并选择正确的分支。若要使用记忆体模型，需使用Oblivious RAM 以确保隐私地存取记忆体内容
多方解密的频宽成本：每次玩家请求5x5 可见范围内容时，需由四台本地客户端协同解密，导致解密过程高度依赖多方同步，对网路频宽要求极高。

未来展望

Frog Zone 展示了利用全同态加密和多方计算技术实现隐私保护和去中心化应用的可能性。虽然当前技术仍面临性能和开发难度的挑战，但这就如同1960 年代的电脑，虽然庞大且效率低下，却是开创现代计算时代的起点。 Frog Zone 的意义在于，它象征了Programmable Cryptography 的雏形，为未来理想化的网际网路铺平了道路。

随着Programmable Cryptography 技术的发展，未来的网际网路将实现去中心化、自主性和隐私保护的目标，建立一个真正属于用户的数位世界。这个世界将带来更安全、透明且自由的数位生活，每个人都将能完全掌控自己的资产、资料与身份。

声明：文章内容不代表本站观点及立场，不构成本平台任何投资建议。本文内容仅供参考，风险自担！

Tag：以太坊 DevCon 技术

你可能感兴趣的文章

币圈快讯

全球年度交易额突破3万亿美元，并购银行家相信特朗普上台的明年会更好
2024-12-18 01:59
并购银行家在2024年重新站稳脚跟，如今正在观望唐纳德·特朗普第二个任期是会推动还是阻碍刚刚起步的复苏。数据显示，随着各央行开始降息，全球交易额今年已增长16%至3.1万亿美元。“2025年的大好形势基本已经板上钉钉，”驻纽约的巴克莱美洲并购业务主管DanGrabos表示，“美国大选已经过去，市场普遍乐观地认为我们将处于一个利好增长、监管放松的环境。我认为我们将继续看到各种类型的交易——从超过100亿美元的重大交易到中等规模的活动。”
彭博分析师：预计明年将出现一波加密ETF，XRP、SOL或在LTC和HBARETF之后
2024-12-18 01:58
彭博高级ETF分析师EricBalchunas在X平台表示：“我们预计明年将出现一波加密货币ETF，尽管不会一下子全部出现。首先出现的可能是BTCETH组合ETF，然后可能是莱特币（因为它是BTC的分叉，即商品），然后是HBAR（因为没有被标记为证券），随后是XRP、Solana（在未决诉讼中被标记为证券）”。
美国众议院议长：”特朗普效应”已经显现，期待其第二个任期及即将到来的好消息
2024-12-18 01:28
美国众议院议长约翰逊表示，"特朗普效应"已经显现。软银将在未来四年内投资1000亿美元，为美国创造10万个新的就业机会，标志着又一个积极信号。我们期待特朗普的第二个任期及即将到来的好消息。
港媒：华强北比特币矿机价格上涨，买家多来自俄罗斯、美国与加拿大
2024-12-18 01:05
ChainCatcher消息，受到比特币暴涨的推动，深圳华强北售卖的矿机价格也是水涨船高。一些商家的蚂蚁矿机价格上涨了数成，一位商家表示，蚂蚁矿机S21335T格是每台5,600美元，折合人民币4.07万元，较去年的2.8万元人民币涨了三成。比特大陆官网显示473T的S21XP水冷矿机折合7.39万元人民币，但是已经售罄。据悉，今年以来尤其是近几个月以来，来自俄罗斯、埃塞俄比亚、美国和加拿大的客户很多，有的是进口数百台新机，有的甚至交易上千台，都是在香港交货付运。（香港文汇报）
顶级交易员Eugene：重新做多SOL、WIF、BONK
2024-12-18 01:02
ChainCatcher消息，头部交易员EugeneNgAhSio在X平台发文展示其合约仓位，涉及币种为SOL、WIF、BONK。根据其图片显示，EugeneNgAhSio做多相关代币，永续合约倍数为两倍。

以太坊Devcon大会精选！十大关键技术全解析，将彻底改变Web3？

目录

Part 1: Infrastructure

坎昆升级大幅降低L2 手续费

Client Diversity 的成功实践

交易确认效率显著提升

L2 的信任假设与分级安全模型

目前的L2 发展现状与挑战

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

L1 的扩容需求与去中心化的坚守

未来：以太坊的进化方向与长期愿景

L2 迈向Stage 2：实现真正的去中心化

降低验证门槛：让更多人参与以太坊网路

执行层的持续扩容：TPS 迈向十万级别

共识层的革命性变革：Beam Chain

极度严谨的工程精神与长期路线图

Part 2: Usability

Smart Wallet (ERC-4337)

Passkey 签章的技术挑战

Passkey 钱包的共同挑战

其他钱包验证与恢复机制：ZK Email 的创新

ERC-4337 的互操作性问题与解决方法

Smart Wallet (EIP-7702)

EIP-7702 的应用案例

EIP-7702 的技术流程

安全挑战与潜在风险

跨链授权的安全考量

EIP-7702 与ERC-4337 的互补性

Smart Session

DApp 与Smart Wallet 的兼容挑战

Smart Session 的概念与理想体验

安全风险与解决方案

Intent Centric Design

ERC-7683：跨链意图的标准化实现

灵活性与挑战

ERC-7683 与EIP-7702 的结合应用

CoW Swap 的Intent 解决方案

技术实现原理

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

开发环境安全（Dev Security）

VS Code 信任机制的潜在风险

防范措施：使用Sandbox 环境

Github Action Self Hosted Runner 的风险

设备安全（Device Security）

安全建议

DeFi 安全（DeFi Security）

Part 5: Fuzz Testing

Fuzz Testing 的原理与限制

相关范例

案例分析：Vesting 合约漏洞

设计Invariant：思考不可变条件

使用Chimera 框架进行测试

Fuzz Testing for ZK Infrastructure

基于黑箱测试的随机变换与不变性检测

持续且多元测试

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 的关键流程：

Part 8: Zero Knowledge Proof (ZKP)

ZKPassport

技术特点

应用场景

技术特点

以太坊区块链中文浏览器让你轻松掌握区块链技术