区块链 > 区块链技术 > 十大关键技术解析

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

2024-12-01 12:05:54 佚名
简介本文总结Devcon 7 的学习心得，涵盖以太坊基础设施、易用性、开发工具、安全性与ZKP 等技术主题

经过十天在Devcon 7 与Side events 的密集学习，我想透过这篇文章浓缩我的所学，并总结几个关键主题，让更多人了解以太坊生态在各个技术面向上的最前沿发展、正在解决的问题，以及未来可达到的理想状态。本文章将涵盖以下主题：

除了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 Diversity 上做得最好的公链。

交易确认效率显著提升

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

现况：Rollup 的挑战与安全性

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

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

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

在这三个阶段中，最大的差异在于「项目方做坏事的难度」。在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 将依赖双重证明系统，并将控制权完全交由智能合约处理，进一步降低对人为干预的依赖。

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

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

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

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

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

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

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

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

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

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

这体现了以太坊对去中心化的坚守以及对安全性的极高要求，毕竟整个网路承载了数千亿美元的资金，任何小差错都可能导致灾难性后果。然而，也有许多社区成员批评五年的时间表过于冗长，期待能加速进度。 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 成本差距：

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

Passkey 钱包的共同挑战

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

这些挑战让部分人质疑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不同而无法相容。这导致：

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

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

Smart Wallet (EIP-7702)

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

EIP-7702 的应用案例

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

EIP-7702 的技术流程

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

安全挑战与潜在风险

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

跨链授权的安全考量

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 生态的兼容性大打折扣。

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

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

Smart Session 的概念与理想体验

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

透过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 负责完成具体请求，支援以下常见场景：

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

ERC-7683 的操作流程如下：

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

灵活性与挑战

ERC-7683 允许开发者自定义结算逻辑，让合约决定支付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 体验。其核心特点包括：

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

其他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 的自动化执行。

这种做法相比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 的授权，即可实现以下功能：

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

其他解决方案

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

Part 3: Dev Tools

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

Tenderly Virtual Test Net

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

Simbolik

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

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

TrustBytes

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

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 提供了清晰且灵活的通知介面，用于处理区块链的三种状态变化：

以下是范例程式码展示如何处理这些通知：

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 资料夹内的设定执行任意脚本，包括：

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

防范措施：使用Sandbox 环境

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

Github Action Self Hosted Runner 的风险

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

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

设备安全（Device Security）

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

安全建议

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

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

DeFi 安全（DeFi Security）

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

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

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

Part 5: Fuzz Testing

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

Fuzz Testing 的原理与限制

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

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

相关范例

以下是三个经典例子，说明如何使用黑箱的Fuzz Testing 方法来检测系统的正确性：

使用Chimera 撰写Fuzz Test

以下介绍如何使用Chimera框架来整合多种Fuzzer 工具（如Echidna、Medusa 和Foundry）进行智能合约的Fuzz 测试。

案例分析：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：

这些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 于有漏洞的投票合约

以下是一个简单的投票合约，完整的程式码可以在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 问题的核心手段：

批次拍卖的优势：

实际案例：

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

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

Unichain 的MEV 解决方案

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

Unichain 解决MEV 的关键流程：

Part 8: Zero Knowledge Proof (ZKP)

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

ZKPassport

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

技术特点

应用场景

ZK Email

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

技术特点

应用场景

技术挑战

ZKP2P

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

域名交易的核心机制

技术特点与优势

Polygon ZisK

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

ZisK 的设计架构

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

目前，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 场景的资料互操作性上，解决不同平台间的数据共享问题。例如：

技术与信任的挑战

vLayer

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

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

Mopro

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

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

Part 9: Multi-Party Computation (MPC)

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

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

World ID

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

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

技术细节与流程

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

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

MPCStats

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

技术特点

展场Demo

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

Public Auditable MPC

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

核心概念与技术

应用场景与优势

Part 10: Programmable Cryptography

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

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

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

最理想的Internet

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

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

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

去中心化Facebook

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

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

投票系统的技术演进

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

ZuPass

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

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

Devcon 门票验证

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

Frog Crypto

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

Meerkat

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

ZuPass 的整合方式

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

POD 与GPC 技术

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

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

POD 的设计与技术基础

GPC 的模组化电路设计

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

POD 的不足与挑战

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

POD 2 的诞生与改进

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

并且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 应用，为分布式隐私计算和应用开发提供了重要的技术示范。

游戏玩法

技术核心：Multi-Party Fully Homomorphic Encryption

技术挑战与限制

未来展望

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

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

本站提醒：投资有风险，入市须谨慎，本内容不作为投资理财建议。

相关文章