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

从Devcon 7回来后，我一直在整理这些天的笔记。不管是主场馆的演讲，还是那些藏在角落里的Side Events，信息密度都非常大。这篇文章算是一个阶段性的梳理，把大家最关心的几个技术方向——从底层基础设施到最前沿的密码学实验——好好盘一盘。

说实话，相比主会场，我更喜欢去那些特定主题的Side Events。这些活动不仅能让人一头扎进某个领域的细节里，还能遇到真正在做事的专家，直接交流。比如在一场关于zkTLS的活动里，我有机会直接向项目方请教文档里没看懂的部分，这种体验在主会场是很难得的。以后大家参加这类大型研讨会，真的建议多花时间在Side Events上，收获往往会更大。

好，正文开始。

Part 1: Infrastructure

这部分我们从一个比较高的视角来聊聊以太坊的基础设施：过去两年达成了什么，现在面临哪些挑战，以及未来会走向哪里。

坎昆升级带来的变化，最直观的感受就是——L2 的手续费，真的被打下来了。核心功臣是

引入的 （Data A vailability Sampling）和 机制。现在 L2 可以把更多数据以更低成本“塞”进以太坊主网，每笔交易的费用甚至不到 0.01 美元。这不再是“未来可期”，而是已经发生在你我身边的事实。

除了降费，以太坊的

（客户端多样性）也经受住了考验，并且做得越来越好。简单来说，运行以太坊节点的客户端不止一套（比如 Geth、Nethermind、Reth），它们由不同的团队开发，代码库完全独立。

• 关键价值在哪里？
  假如某个客户端突然出了 Bug，只要它的使用比例低于 33%（以太坊的共识需要 2/3 节点同意才能 Finalize），那这条链就不会因为一个 Bug 而分叉或停摆。

• 历史已经证明过
  ：早期以太坊只有 Geth 和 Parity 两个客户端，那次重大的客户端问题之后，Client Diversity 的价值才被整个行业深刻理解。

• 理想状况是
  ：每个客户端的占比都低于 1/3，这样任意一个出问题，都不会影响区块的最终确认。

可以说，在整个公链世界里，以太坊在客户端多样性这件事上，走得最远，也做得最扎实。

另外，

的提升也肉眼可见。现在绝大多数交易在 6-30 秒内就能完成确认，过去那种交易延迟几分钟甚至被节点丢弃的情况，已经很少见了。这为上层应用的用户体验打下了很好的基础。

自从 2020 年 Vitalik 确定了

，数百条 L2 链如雨后春笋般冒了出来。在这个架构里，L1 是底层基础设施，提供最高的安全性和可信中立性；L2 则像显卡一样，针对特定应用场景做加速，大幅提升吞吐量。不过，L2 的快速增长也暴露了一些问题。

目前，很多 L2 项目仍然建立在“强信任假设”之上。为了更清晰地衡量一个 L2 到底有多“去中心化”，行业里把它们分成了三个安全阶段：

• Stage 0：完全中心化的 L2。
  说白了，就是项目方说了算。它只要能把数据定期提交到以太坊主网就算过关，但资金安全完全依赖项目方的良心。这相当于“辅助轮”，目的是让项目能快速跑起来。

• Stage 1：有了基础的证明和治理。
  在这个阶段，L2 至少实现了 Fraud Proof 或 ZK Proof 中的一种，证明由智能合约来验证。项目方还得组建一个

  Security Council
  ，对关键修改进行投票，并且项目方自己不能在委员会里占绝对多数。

• Stage 2：双重证明与去中心化。
  这是理想的终局。L2 不仅要有两套独立的证明系统，而且绝大部分控制权得交给智能合约。Security Council 只会在两套证明结果冲突时介入，选择接受哪一个。这样一来，项目方想作恶的难度指数级上升。

这三个阶段的核心差异，其实就一句话：

Stage 0 几乎没有任何限制；Stage 1 已经很难了；而 Stage 2，则彻底把人为干预的可能性降到了最低。

现实中，大多数 L2 项目还处在

的早期阶段。虽然宣传上都说自己去中心化，但实际情况往往有差距。专门研究 L2 安全的网站 提供了很详细的报告，他们的分析深入到代码层面，揭开了很多营销话术背后的技术现实，值得关注。

这里必须强调一个 L2 安全性的核心机制——

。如果 L2 的 Operator 或 Sequencer 突然停摆，用户必须能在不依赖项目方的情况下，生成自己在 L2 上持有资金的证明，提交到 L1 的治理合约里，把资金赎回来。比如 的 L2，在决定停止运营时，就提供了工具让用户自己把资金转回 L1，这才是真正负责任的做法。

随着未来可能有大量 L2 触发逃生交易，L1 必须持续扩容。但 Vitalik 反复强调：

。一旦去中心化被妥协，就很难再挽回。这是以太坊作为可信中立基础设施的底线。

以太坊的进化不会停下脚步。从 L2 的去中心化到 L1 的性能优化，再到共识层的全面重写，都在计划之中。

首先，推动更多 L2 迈向

是明确的方向。Vitalik 甚至明确说过，未来他只会把达到 Stage 1 的 Rollup 称为 Rollup。Stage 2 才是长期愿景。

其次，降低验证门槛的目标也很明确。包括开发像

这样的 ，让算力有限的设备也能参与验证；以及将验证者的质押门槛从 32 ETH 降低到 1 ETH，让更多人能参与进来，进一步分散网络风险，减少对 等单一流动性质押提供商的依赖。

在执行层，通过扩展

（比如引入 技术），理论 TPS 有望从现在的几千笔提升到十万级别，为高频交易场景铺平道路。

而最令人关注的，是共识层的革新——

的提出。这是对现有 Beacon Chain 的一次全面重写，主要目标指向几个最棘手的问题：

• 抗量子计算
  ：现有的 ECDSA 签名面临被量子计算机破解的风险，迁移到后量子密码学签名是当务之急。

• 更快的最终确认
  ：目前 15 分钟的 Finality 时间显得太长了，理想目标是

  12 秒
  （Single Slot Finality），这对用户体验（比如交易所存取款）的提升是巨大的。

• ZK 可验证
  ：通过结合 ZK 技术和签名聚合，让验证者在处理超大验证者集时也能保持高效。

图中绿色的项目可以通过渐进式改动完成，但红色部分最为棘手，需要重写核心代码。Beam Chain 正是为此而生。

整个 Beam Chain 的路线图体现了一种极度严谨的工程精神：一年内完成规格定义，一到两年完成实现，再花一到两年进行全面测试。毕竟，这个网络承载着数千亿美元的资金，任何一个小差错都可能导致灾难性后果。当然，社区里也有声音认为五年的时间表太长，Justin 则表示这其中确实有优化空间，希望能有更多人参与讨论和实现。

需要强调的是，Beam Chain 不是未来五年的唯一重点。执行层的改进（比如通过 PeerDAS 提高 TPS）会持续推进，为应用开发者提供更好的性能体验。

Part 2: Usability

随着

标准的上线，各种 开始普及，用户体验有了质的飞跃。但与此同时，也带来了新的技术挑战，比如钱&包与 DApp 的互操作性问题，以及随着 L2 增多带来的资产碎片化问题。业界正在朝着 和 的方向寻找答案，让用户能更简单地完成复杂的跨链操作。

ERC-4337 最引人注目的应用之一就是

。用户通过生物识别就能创建 Passkey 作为钱&包私钥，每次交易也只需生物识别，再也不用记那些复杂的助记词了。很多人把这视为钱&包的“终极体验”。

但 Passkey 的签名面临一个技术挑战：它使用的是

椭圆曲线（P-256），而以太坊原生支持的是 。两者参数不同，导致 Gas 成本差异巨大——验证 secp256k1 签名只需约 3000 Gas，而验证 P-256 签名目前需要约 30 万 Gas，是前者的 100 倍。好在 提案正在推进，目标是把 Passkey 验证的 Gas 成本降到与 secp256k1 相当的水平。

即便如此，Passkey Wallet 仍面临几个共同挑战：

• 与域名唯一绑定
  ：Passkey 绑定特定域名（如 Coinbase Smart Wallet 的 keys.coinbase.com），这杜绝了钓鱼攻击，但也带来了域名过期或单点故障的风险。

• 钱&包碎片化
  ：不同域名会创建不同的 Passkey Wallet，导致用户资产进一步分散。

• 互通性问题
  ：Passkey 私钥存储在设备的安全区域，无法导出，也无法在 Android 和 iOS 间互通。

• 盲签安全风险
  ：签名时用户只能看到“是否同意使用这把 Passkey”，看不到具体签名内容，如果钱&包前端被 XSS 攻击，资产可能被盗。

这些挑战让一些人质疑 Passkey 作为钱&包私钥的适用性。但未来的钱&包设计或许可以借鉴 Web2，提供多种验证和账户恢复选项，并根据需求设置不同权限。

除了 Passkey，

团队提出了一种通过 Email 恢复钱&包控制权的方案。用户可以将指定 Email 设为钱&包的“监护人”。私钥丢失时，只需从该 Email 发送一封包含合约地址和新控制地址的信件，就能生成 ZK 证明，在链上验证后取回控制权。这基于成熟的 Email 基础设施，安全又便捷。

随着 Passkey 和 ZK Email 等机制的应用，ERC-4337 钱&包的互操作性挑战愈发明显。比如，用户在 A 钱&包创建的合约钱&包，可能因为使用的

不同，而无法在 B 钱&包中使用。为此，业界提出了 （如 和 ），将功能模块化，允许所有钱&包共用一个 Factory Contract，灵活组合不同模块，极大提升互操作性。

（Set EOA Code）是下一代账户抽象标准，预计将在下一次 中纳入。它解决了 ERC-4337 的一个关键限制：用户必须创建新的合约钱&包，无法延续旧的 EOA。EIP-7702 允许任何 EOA 地址“升级”为智能合约钱&包，实现批量交易、Gas 赞助、弹性权限设定等功能。

Ithaca 团队在 EXP-0001 中展示了 Demo：用户一键创建 Passkey，将 EOA 地址的权限袋里给该 Passkey，后续所有交易只需 Passkey 签名即可完成。借助 RIP-7212 的优化，Gas 成本大幅降低。

其技术流程大致是：用户用 EOA 私钥签署一个授权信息，包含链 ID、nonce 和智能合约实现地址等。然后通过 Relayer 将授权信息上链，之后该 EOA 的账户代码就会指向那个智能合约逻辑，实现升级。想取消授权也很简单，签署一个取消请求上链即可。

不过，这么强大的功能也带来了新的安全风险。比如，用户如果签署了恶意合约的授权，攻击者可以批量转移所有资产，风险比现有的 Permit Signature 更高。另外，如果签章使用

，表示对所有 EVM 链生效，一个签章可能导致所有链上的资产同时暴露，效果等同于私钥泄露。

好在开发者和钱&包应用可以通过引入“白名单”系统、在界面提示用户授权安全性等方式来降低风险。

。EIP-7702 的优势在于支持将现有 EOA 升级为智能合约钱&包，但 EOA 私钥始终拥有最高权限。ERC-4337 则可以实现多签等无需依赖单一私钥的设计，安全性更高。两者相互补充，适用于不同的安全需求场景。

虽然有 Smart Wallet，但 DApp 的使用体验不会自动变好。两者的沟通方式需要统一。传统的 EOA 模式下，DApp 通过 eth_sendTransaction 接口发送请求；而 ERC-4337 的 Smart Wallet 需要

结构。为了解决兼容问题，社区正在讨论 EIP-5792、ERC-7677、ERC-7679 等提案，帮助 DApp 确认钱&包支持的账户功能，并指导如何生成 User Operation。

除了接口统一，

概念的出现，则旨在提供类似 OAuth 的授权体验。理想场景是：用户登录 DApp 时，DApp 请求授权并说明交易范围（比如 Uniswap 需要 Approve 和 Swap 的权限）。用户同意后，DApp 获得一个 ，后续操作中 DApp 直接使用 Session Key 签名并提交交易，无需用户再次确认。这能把用户点击次数降到最低，同时保持对授权的掌控——核心就是“”。

当然，Session Key 的安全存储是必须考虑的问题。Passkey 是一个很好的选择，能大幅降低泄露风险。同时，Session Key 的设计应保证丢失后影响最小，用户只需重新授权即可恢复。

随着上百条 L2 的出现，用户资产分散在不同链上，跨链操作变得异常复杂。越来越多协议开始采用

，用户只需表达“想干什么”，具体怎么实现交给 去处理。就像以前自己开车到目的地，现在叫个 Uber 就行。

是由 Uniswap 和 Across 提出的跨链意图标准。用户签署一个跨链操作意图（比如把 A 链的 USDC 换成 B 链的 ETH），Solver 会负责完成。整个流程可能是这样：用户将资产存入 ERC-7683 合约并记录意图，Solver 监听并锁定该意图，然后 Solver 在目标链上“垫付”资金完成用户的目标操作，最后协议在源链上每小时进行一次批次结算。这种方式比传统基于消息的跨链协议效率更高，因为使用了批次结算，减少了跨链消息传递的成本。

ERC-7683 也允许开发者自定义结算逻辑，这带来了一些灵活性挑战：比如 Solver 可能因不熟悉某种结算逻辑而不参与，导致流动性碎片化；或者结算合约如果出问题，Solver 可能收不回垫付资金。采用模组化设计可以让结算逻辑更简单易懂，从而吸引更多 Solver。

则在单链场景中应用了 Intent 理念。它通过聚合多个用户的交易意图，实现点对点匹配，避免了流动性池的中间操作，从而显著减少 MEV 攻击的可能性和交易成本。这对 Solver 的技术要求很高，需要快速从多个来源获取流动性，并精确计算最优路径。

此外，

设计也很有意思。用户可以在源链上发送 USDC 到一个指定地址，通过 在目标链上执行后续的 DeFi 操作。它利用了 Circle 的 和以太坊的 机制，实现了完全去中心化的跨链操作。

的理念更进一步：它试图隐藏区块链的存在，让用户只关注资产本身。用户只需要知道自己有多少 USDC、多少 ETH，而不用关心它们具体在哪个链上。发起转账时，系统会自动完成跨链整合。

是一个支持 Chain Abstraction 的方案。它允许 ERC-4337 钱&包的开发者定义跨多链的操作，整合成一个 ，用户只需签署一次授权即可完成复杂任务。

其他如

、、、 等团队，也都在从不同角度推动 Chain Abstraction 的发展。

Part 3: Dev Tools

以太坊的开发工具生态也在持续进步，从测试、调试到数据索引，都有不少值得关注的创新。

是一个强大的虚拟测试网工具，可以 fork 主网并与主网保持实时同步，还提供无限资源模拟和无缝 CI 整合。

是为 Solidity 开发的调试工具，与 VS Code 深度整合，可以直观地检查每行代码执行时的 EVM 状态（stack、memory、storage），甚至分析编译后的 EVM bytecode。

则能将 Solidity 代码转化为图像化呈现，对于合约审计特别有用，可以清晰显示函数调用关系、变量读写追踪和恶意输入分析。

由于直接从 JSON RPC 查询区块链数据效率低下，

工具变得不可或缺。

是一个开源工具，开发者只需通过简单的 ，就可以把链上数据转换成指定格式并存入 PostgreSQL 数据库。比如，要记录一个钱&包的 ERC-20 Token 转账历史，只需在配置文件中定义好要提取的事件和字段，Shovel 就能完成所有繁重工作。

则提供了一种更优雅的方案。过去用 Geth 等节点软件扩展功能时，常常需要修改节点代码（相当于 fork），一旦上游更新，维护起来很麻烦。Reth 的设计是作为 ，开发者不需要 fork 或修改节点代码，就能灵活扩展节点功能。它提供了清晰的通知接口，用于处理新区块确认、链重组和区块回滚等状态变化。

Part 4: Security

安全永远是区块链领域的第一要务。从开发环境到用户设备，再到 DeFi 合约，每个环节都不能掉以轻心。

开发者常忽略开发环境本身的安全。比如，在 VS Code 中打开一个恶意仓库并点击“信任作者”后，攻击者可能利用 .vscode 文件夹中的配置执行任意脚本，窃取私钥甚至打开后门。所以，强烈建议在

（比如 VS Code 的 Dev Container）中打开项目，把风险隔离在 Docker 容器内。

另外，在公开仓库中使用

也有风险。恶意用户可以 Fork 仓库并修改 Action 脚本，从而入侵 Runner 并窃取所有 Token 和 Secrets。最好避免在公开仓库中使用 Self Hosted Runner，或者设置更严格的权限。

根据 Ledger 的研究，iOS 和 Android 上的

并不如预期那么安全。主要问题在于：私钥可能被复制到应用内存中，而且某些平台的快取机制会在设备解锁前就将私钥暂存到内存中，增加了被恶意软件利用的风险。所以建议：选择不可同步的 Passkey，不要存放大量资金，对于高价值资产还是继续使用硬件钱&包。

DeFi 领域由于资金体量巨大，成为黑客攻击的主要目标。像

这样的链上防火墙开始发挥作用。它基于 AI 模型，对每笔交易进行模拟和风险评估，只有风险分数低于阈值的交易才会被放行。不过，这种方式要求 DeFi 协议修改合约来整合 Forta 系统，这面临升级和可组合性的挑战。而且链下模拟和实际上链执行的结果可能不同，有被黑客利用的机会。目前，精准的交易模拟仍然是安全领域待解决的难题。

Part 5: Fuzz Testing

Fuzz Testing（模糊测试）是通过大量随机输入来测试智能合约、试图触发意外的逻辑漏洞的一种强大技术。它对发现人眼难以察觉的边缘情况特别有效。

Fuzzer 的核心是持续尝试各种随机输入，检测合约是否满足定义的

（不可变条件）。但必须记住：。Fuzzer 的效果取决于定义的 Invariant 是否完善以及测试的覆盖范围。

经典的例子包括：测试排序算法时，用随机打乱后再排序的结果与原始排序结果对比；测试编译器时，在代码中加入死代码后编译，看行为是否一致。

我们来看一个简化的 Vesting 合约，它实现用户积分的分配与转移。但存在一个漏洞：用户可以通过“自我转移”来增加自己的积分，从而破坏“总积分不变”这个 Invariant。

要测试这个合约，我们可以定义两个 Invariant：一是初始化时所有用户积分总和等于 TOTAL_POINTS；二是任意操作后，积分总和保持不变。

使用

框架，我们可以将测试代码同时运行在 Echidna、Medusa 和 Foundry 等多个 Fuzzer 工具上。编写一个 Setup.sol 文件初始化测试合约，定义检查条件的 property 函数，然后指定被测试函数和参数范围，最后执行测试。你会发现，Fuzzer 很快就能找到这个漏洞。

修复方法也很简单：在 transferPoints 函数中加入 require(msg.sender != to) 即可避免自我转移。

零知识基础设施涉及编译、执行、生成证明和验证 ZK 电路等多个核心组件，对安全要求极高。Fuzz Testing 同样适用于检测这些基础设施的漏洞。

测试方法可以基于黑箱随机变换。比如，随机生成一个原始电路 C1，然后应用一系列随机变换（如乘以 1、加减随机表达式等）生成语义等价的电路 C2。将两个电路分别进行 ZK 工具处理，如果输出或行为不一致，就能定位到处理流程的漏洞。

由于 ZK 基础设施经常用于承载数亿美金价值的 Layer 2 协议，持续且多元的测试非常必要。自动化测试工具可以保证每次代码更新后迅速发现潜在漏洞。测试还应支持多种 ZK DSL（如 Circum、Gnark、Noir），并具备自动反馈功能，同时生成的输入应尽量简化，方便开发者快速定位问题。

Part 6: Formal Verification

（形式化验证）是一种用数学方法验证软件是否符合特定规格的技术。对于智能合约而言，它能系统地检查合约在所有可能状态下的正确性。与 Fuzz Testing 相比，它能够覆盖所有可能的状态，并“数学证明”合约逻辑的正确性。当然，这通常需要严谨的规格定义和较高的计算成本。

提供了一整套工具来帮助开发者在实践中应用 Formal Verification。它的核心产品 允许开发者使用 定义规则并自动化验证合约逻辑。

我们用一个有漏洞的投票合约来演示：在 vote 函数中，totalVotes 被错误地重置为 1，而不是累加。使用 Certora Prover 验证的步骤是：

1. 撰写一个规格，检查 totalVotes 在每次投票后是否递增。
2. 在 configure 文件中设置要验证的合约和规格文件。
3. 执行验证命令。Certora Prover 会找出错误并提供详细的输入参数。
4. 修复合约中的 Bug（将 totalVotes = 1 改为 totalVotes += 1）。
5. 重新验证，一旦所有规范通过，就意味着此智能合约的正确性已经被数学证明。

Certora 还支持定义不变量规则（Inductive Invariants），比如验证 totalVotes 永远等于赞成票与反对票的总和。

Part 7: Maximal Extractable Value (MEV)

关于 MEV，这里有两种不同但互补的解决思路。

CoW Swap 的核心主张是，约 99% 的 MEV 问题来自应用层（尤其是 DEX）的交易排序竞争。所以应该在设计应用时就考虑到 MEV。

他们通过

（需求巧合）和 （批次拍卖）来实现。把多笔交易聚合起来，让有匹配需求的用户直接点对点交换，避免了流动性池的中间操作。所有涉及相同资产的交易都以统一的清算价格结算，让交易顺序变得无关紧要，从而削弱 MEV 攻击的空间。

举个例子：用户 A 想用 100 DAI 买 ETH，用户 B 想用 200 DAI 买 ETH，用户 C 想出 1 ETH 换 300 DAI。这三笔订单在批次拍卖中组合在一起，A 和 B 的需求（300 DAI）与 C 的供给（1 ETH）完美匹配，就可以直接点对点交换，无需触及链上流动性，既高效又安全。

Unichain 则选择在基础设施层，通过可信执行环境（TEE）来解决 MEV。它的核心创新在于

。用户发送交易时，先用 TEE 的公钥加密，所以内存池中的所有节点看到的都是加密内容，无法通过交易排序来提取 MEV。只有在 TEE 环境内才能解密并排序，排序结果带有 TEE 的签名，保证了透明度。

对于普通用户，Unichain 提供接近零成本的 Gas 费，同时完全避免被抢跑的风险；而 MEV Searcher 需要支付更高 Gas 费来竞争区块前位，这些额外收益则用于回馈验证者，形成公平的经济激励。

Part 8: Zero Knowledge Proof (ZKP)

ZKP 技术展示了如何通过密码学方法实现隐私保护与性能的平衡。下面聊几个令人印象深刻的 ZK 应用。

这个项目结合了国际电子护照（ePassport）的芯片技术与 ZKP。用户通过手机 NFC 感应护照，获取芯片中由政府签署的数据，并基于此生成护照资料有效性的零知识证明。用户可以只证明“年龄大于 18 岁”或“国籍是美国”，而无需公开完整护照信息。证明使用 Noir 编写，在手机上生成只需约 5 秒钟。应用场景包括 Sybil Resistance（防女巫攻击）和 ZK KYC。

这是一个基于 ZKP 的 Email 验证应用。用户可以选择性地验证邮件内容，比如证明发信人是否来自某个特定组织、邮件里是否有特定文字，而无需公开整封邮件。它利用的是每个 Email 都有的

，可以生成一封信是由该域名发出的零知识证明，且无法伪造。应用场景包括：去中心化的法币-加密货币兑换平台（ZKP2P）、作为智能合约钱&包的备份恢复手段（Email Wallet Guardian），以及匿名告密等。

当然，它也有一些技术挑战，比如 DKIM 公钥的正确性需要通过去中心化的 Oracle 机制来保证，以及处理较长的邮件时性能面临挑战。

Polygon 正在开发新一代的 ZKVM 证明系统 ZisK，目标是实现即时证明整个 EVM 区块中所有交易的计算。它的设计受到嵌入式系统启发，采用模块化架构（ROM、处理器、RAM、总线），目前还处于非常早期的开发阶段，但方向很明确：提升 ZK 证明在区块链应用中的性能。

这个协议结合了 TLS Proxy 技术和 ZKP，旨在让用户在不泄露敏感信息的前提下，验证 HTTPS 内容的真实性。它的核心是

，作为信任中介签署加密流量，然后用户通过 ZK 电路解密其中特定部分的明文，并提供证明。应用场景包括：从 A 电商生成消费记录的证明，提供给 B 电商获取优惠，而 B 只能知道消费总金额，看不到明细。

它的技术挑战在于，TLS Proxy 本身需要用户信任，因为极端网络条件下（如 BGP Hijack）可能存在风险；另外，由于 ZK 证明的链上验证成本较高，目前应用重点放在 Web2 场景。

Vlayer 将自己定位为“可验证数据基础设施”，为 Solidity 语言引入了四个新功能：Time Tra vel（使用历史链上数据）、Teleport（合约跨 EVM 兼容链运行）、Web Proofs（验证网页内容）、Email Proofs（验证电子邮件内容）。目前正处于 Alpha 阶段。

Mopro（Mobile Prover）是一个专为移动端环境开发的 ZK 证明生成工具，旨在简化在手机应用中集成 ZK 证明的复杂性。它比浏览器上的 snarkjs 更快，并尝试利用 GPU 优化性能。当然，移动端的内存限制和 GPU 加速优化（相比桌面端的 CUDA）仍是需要克服的挑战。

Part 9: Multi-Party Computation (MPC)

是一种允许多方在不泄露各自输入的情况下，共同计算函数结果的技术。它与 ZK 的区别在于：MPC 需要多方共同参与计算，所有人都能隐藏输入；而 ZK 只需要一方（Prover）生成证明，另一方（Verifier）验证。

World ID 是为全球用户建立数字身份的技术，确保“一人一票”。注册时需通过虹膜扫描，验证新扫描的虹膜是否已存在于数据库中。为了不泄露这些敏感的虹膜数据，Worldcoin 与

合作，探索基于 MPC 的去中心化虹膜比对方案。

技术细节是：用户的虹膜数据被拆分为 3 个 Secret Share，分发给 3 个计算方，然后在 MPC 框架下计算 Hamming 距离，并与阈值进行比较。整个过程数据隐私不被泄露。不过，由于使用者数已超过 1600 万，每次唯一性验证需要庞大的计算资源（32 台 H100 GPU，峰值网络吞吐量 2.5 Tbps）。Worldcoin 正在探索计算成本更低的替代方案，比如借鉴 ZKPassport 的护照唯一性证明机制。

这是一个基于 MPC 的开源框架，用于实现多方参与的统计计算，同时保护数据隐私。数据提供者的资料以秘密共享的方式处理，并整合了 TLS Notary 来确保输入数据来自可信来源。支持平均值、中位数、吉尼系数等常见统计操作。

这是一种将 MPC 与 ZK 相结合的新型协议，它允许计算方在保护输入隐私的同时，向第三方公开验证计算结果的正确性。它通过协作式 ZK-SNARKs 生成可验证的完整证明，并对传统的 SPDZ 协议进行了优化，加速了位元运算。应用场景包括电子投票、去中心化拍卖、医疗数据与机器学习，以及去中心化游戏等。

Part 10: Programmable Cryptography

，这个概念由 0xPARC 提出。它标志着从“专用型密码学”到“通用型密码学”的转变。过去，我们针对特定需求（如 RSA 加密、椭圆曲线签名）发明专门的密码学协议。而可程式化密码学则把密码学设计的数学问题转化为工程问题，开发者可以写程序来实现任意密码学操作。核心的代表技术包括：ZK、MPC、FHE 和 iO。

它能帮助实现互联网的理想状态：真正的去中心化、隐私保护、数据互操作性，以及用数学保证取代对中央机构的信任。

是一个很好的例子。简单的上链实现了公开可验证和抗审查；加入 ZK 可以隐藏投票内容；加入 MACI 机制可以防止贿选（投票者无法证明自己投给谁）；加入 FHE 可以将信任模型扩展为 M-of-N；而加入 iO，即使所有人都共谋也无法知道投票运算细节。

ZuPass 是 0xPARC 推出的一个实验性应用，基于 Proof-Carrying Data 的概念，让用户能自主管理数据并实现跨平台互操作。它的核心技术是

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

在 Devcon 现场，ZuPass 被用于门票验证、基于身份的 Telegram 群组验证，还有像 Frog Crypto（搜集青蛙并生成证明）和 Meerkat（匿名问答）这样的有趣应用。

POD 也存在一些限制，比如它是单用户技术、无法递归证明、与现有 Web2 系统不兼容。因此，

应运而生。它引入了 Proof-Carrying Data 的概念，支持多用户隐私协作（通过 MPC）和递归证明。最关键的是，POD 2 提供了一个 Universal Data Adapter，可以把来自 ZK Email、TLSNotary 等 Web2 系统的数据转换为 POD 格式，实现不同系统间的无缝整合，完全不需要修改现有的 Web2 数据生成逻辑。当然，POD 2 的技术挑战在于依赖 MP-FHE。

Frog Zone 是 0xPARC 在 Devcon 展示的技术游戏，被认为是首个多用户 MP-FHE（Multi-Party Fully Homomorphic Encryption）应用。最多 4 位玩家在 32x32 的地图上探索、移动、攻击怪物。每名玩家只能看到自己周围 5x5 范围内的地图。整个游戏状态由 4 台玩家机器和 5 台 AWS 云端机器共同维护和计算，没有任何一台机器能解密出完整状态，就像产生了共同的“幻觉”（所以被称为

）。

这背后的技术挑战巨大：每个二进制逻辑门运算耗时约 10 毫秒，比传统计算慢 10 亿倍；动用 5 台最高规格的 AWS 机器，每小时花费 200 美元，但每个玩家每 4 秒才能操作一次。尽管如此，Frog Zone 的意义在于，它就像 1960 年代的大型计算机——虽然庞大而低效，却是开创现代计算时代的起点。它象征了 Programmable Cryptography 的雏形，为未来理想化的互联网铺平了道路。