Appearance
25 · 零知识证明与账户抽象
LESSON 25 / 35 · 证明与体验
本节先回答“如何证明而不泄密”，再回答“如何让钱包和多链体验更可用”。零知识证明（ZKP）把信任与信息解耦；账户抽象（AA）把账户规则变成可编程逻辑；链抽象则把跨链执行细节放到意图求解层之后。
每一次抽象都减少一类用户负担，同时引入新的实现、运营和治理边界。界面更简单，不代表风险消失，而是用户面对的信任对象发生了变化。
学习目标
读完本节，你应能：
- 用一个直觉例子解释零知识证明，并区分 Completeness、Soundness 和 Zero-Knowledge。
- 说明交互式证明如何通过 Fiat–Shamir 变成非交互式证明，并理解 SNARK 与 STARK 的基本权衡。
- 说出 ZK Rollup、隐私应用、身份与合规选择性披露三类应用方向。
- 解释 EIP-4337 中 UserOperation、Bundler、EntryPoint 和 Paymaster 的角色。
- 区分账户抽象与链抽象，并识别抽象后的新信任对象和失败出口。
课程正文
25.1 零知识证明：证明为真但不泄密
25.1.1 核心悖论：证明条件而不是交出全部信息
零知识证明（Zero-Knowledge Proof，ZKP）允许证明者向验证者证明某个命题成立，同时不泄露命题之外的秘密。比如，用户可以证明自己满足某个年龄或资格条件，而不必交出完整身份信息。
这里的重点不是“完全没有信息交换”，而是把验证所需的信息限制在命题本身：验证者知道结论成立，却不因此得到秘密的内容。
25.1.2 阿里巴巴山洞：交互式证明的直觉
一个经典比喻是环形山洞。山洞深处有一扇需要密码才能打开的门，证明者声称自己知道密码，但不愿把密码告诉验证者。
证明者从左侧或右侧进入山洞；验证者随后随机要求她从某一侧出来。知道密码的人无论收到哪一种挑战都能完成要求，不知道密码的人只能依靠最初选中的方向，单轮猜中的概率是二分之一。重复多轮后，骗子连续猜中的概率会快速下降，而验证者始终没有看到密码。
这个故事对应零知识证明的三个直觉：诚实者能完成证明，作弊者难以持续通过随机挑战，验证者不会从过程本身得到秘密。
25.1.3 三项核心性质
一个合格的证明系统通常需要同时讨论三项性质：
- Completeness（完备性）：命题为真时，诚实证明者应该能够让诚实验证者接受证明。
- Soundness（可靠性）：命题为假时，作弊者成功让验证者接受的概率应该足够低。
- Zero-Knowledge（零知识性）：验证过程不应泄露秘密本身，或泄露超出命题所需的额外信息。
三项性质分别回答“真的能证明吗”“假的能不能混过去”“证明过程中泄露了什么”。一个系统使用了 ZK，不等于它自动解决了隐私、安全、合规或数据治理问题；仍需检查它证明的对象、密码学假设和实现边界。
25.1.4 从交互式到非交互式：Fiat–Shamir
交互式证明需要证明者和验证者多轮来回：验证者提出随机挑战，证明者根据挑战回应。这样的形式便于说明原理，但不适合让链上合约或任何陌生验证者反复参与。
Fiat–Shamir 变换使用哈希函数模拟部分随机挑战，把交互过程转换为非交互式证明（NIZK，Non-Interactive Zero-Knowledge）。证明者把承诺等公开内容输入哈希函数，把结果当作挑战，再生成一份任何人都可以独立验证的证明。
它减少了实时互动，却没有消除证明系统的数学假设、哈希函数假设、参数要求和实现风险。具体证明方案是否成立，仍要回到其安全模型和验证规则。
25.1.5 SNARK 与 STARK：一般工程权衡
SNARK 和 STARK 是课程中用来理解 ZK 工程路线的两类代表。它们不是简单的安全等级排名，实际体验还取决于电路、虚拟机、证明生成硬件、验证成本和审计质量。
| 维度 | SNARK | STARK |
|---|---|---|
| 证明体积 | 通常较小 | 通常较大 |
| 验证与链上成本 | 通常较快，适合受 Gas 约束的验证 | 可扩展，但证明传输、带宽和验证成本需要权衡 |
| 设置方式 | 部分方案需要可信初始化 | 强调透明设置，不依赖同类 trusted setup |
| 主要关注 | 证明小、验证快和工程成熟度 | 透明性、可扩展性和哈希假设 |
| 额外讨论 | 可信仪式和参数管理的风险 | 更大的证明体积与工程复杂度 |
SNARK 的小证明和较快验证对链上场景有吸引力，但需要理解部分方案的可信初始化风险，以及多方仪式如何分散这种依赖。STARK 强调透明设置，对大规模计算更可扩展；它的证明通常更大，可能增加 Gas 和带宽成本。基于哈希的密码学假设常被认为具有更强的抗量子叙事，但这不是对任何具体实现的绝对安全承诺。
25.1.6 三个应用战场
扩容：ZK Rollup
ZK Rollup 在链下批量处理交易，并向底层链提交状态转换的有效性证明。验证者可以验证证明，而不必重新执行整批计算。与依赖挑战窗口的 Optimistic Rollup 相比，ZK Rollup 的确认路径和安全假设不同；具体安全边界仍要回到协议、证明系统和数据可用性设计。
隐私：交易、DeFi 与投票
ZK 可以隐藏部分交易关系或输入，同时让网络验证交易满足规则，也可以用于隐私 DeFi 和隐私投票。隐私技术不自动解决滥用、合规、制裁或数据治理问题，应用仍需明确哪些信息被隐藏、哪些元数据仍会暴露。
身份与合规：选择性披露
用户可以证明自己已经满足某个资格条件，例如通过某类审核或拥有某种凭证，而不公开完整身份资料。关键问题是明确“证明了什么”和“仍然暴露了什么”，并核验凭证签发、撤销和验证的责任边界。
25.1.7 从论文到产业：历史与认知地图
课程材料用一条简化时间线帮助理解 ZK 的工程化：20 世纪 80 年代提出相关理论，2016 年前后出现生产环境中的代表性应用，2019–2020 年后 ZK Rollup 和可验证计算进入更强的工程化阶段。这条线索用于建立认知，不替代具体项目的历史核验。
课程中的赛道分类示例包括：
- ZK Rollup / L2：zkSync Era、Starknet、Polygon zkEVM、Scroll、Linea；
- 隐私协议：Zcash、Aztec；
- 证明服务与基础设施：Succinct、RISC Zero、Axiom；
- 硬件加速：Ingonyama 等；
- 身份与合规：World、zkPass、Polygon ID 等。
这些名单只用于建立学习地图，不是项目排名、推荐名单或当前状态判断。主网状态、产品边界、采用情况和公司关系都需要回到项目官方资料核验。
25.1.8 现实瓶颈与可验证计算愿景
ZK 的现实挑战包括：
- Prover 成本：证明生成可能需要专门硬件和持续计算资源；
- zkEVM 兼容性：EVM 中的部分操作对 ZK 电路并不友好，兼容性和性能需要工程权衡；
- 开发与审计难度：电路、编译器、硬件、证明系统和合约之间存在组合风险，漏洞可能影响证明有效性；
- 系统边界：还要分别检查数据可用性、密钥管理、参数、前端和故障恢复，而不能只看“用了 ZK”这一标签。
更广的愿景是可验证计算：复杂计算可以附带证明，让验证者以较低成本核验结果，而不必重做全部计算。它是课程材料中的技术愿景，不是对所有 ZK 项目当前能力的结论。
25.2 账户抽象与链抽象：从底层证明到可用体验
25.2.1 账户抽象要解决的用户门槛
传统钱包流程常要求用户安装钱包、保管助记词、准备原生 Gas、切换网络并确认签名内容。多链环境还会带来资产分散和重复授权等额外负担。课程把它们归纳为三类问题：
- Gas 门槛：用户必须先持有对应链的原生资产才能支付交易费用；
- 密钥恢复：私钥或助记词丢失后，传统账户通常缺少熟悉的恢复路径；
- 多链碎片化：资产、应用和操作分布在不同网络，用户需要手动切换和编排。
账户抽象主要处理前两类账户与交易体验，链抽象进一步处理多链资产和执行的碎片化。
25.2.2 核心思想：把账户规则变成可编程逻辑
EOA（Externally Owned Account，外部拥有账户）主要由私钥控制，验证和支付流程相对固定。合约账户（Contract Account）则由代码控制，可以定义更丰富的验证、恢复和权限规则。
账户抽象的核心思路，是用合约账户的可编程验证逻辑弥补 EOA 的局限，例如多签、社交恢复、会话密钥、时间锁、批量交易和替代签名方式。可编程性带来更好的体验，也把风险带到合约代码、守护人、恢复流程和权限配置中。
25.2.3 EIP-4337：应用层的四件套
EIP-4337 不直接改变底层共识协议，而是在应用层组织一套账户抽象流程。四个核心组件的分工是：
- UserOperation：描述用户希望执行的操作，是一份待处理的操作对象，不是普通链上交易；
- Bundler：收集 UserOperation，打包成真实交易并提交上链，通常需要先承担提交交易的 Gas，再按规则收回成本；
- EntryPoint：入口合约，负责协调 UserOperation 的验证与执行；
- Paymaster：可选的代付合约，可以按规则替用户承担 Gas，或允许用其他资产支付费用。
可以把流程理解为：用户提交操作对象，Bundler 负责打包和提交，EntryPoint 负责验证与执行，Paymaster 在满足条件时参与费用支付。多签、社交恢复、会话密钥、二次验证和批量操作等能力由账户合约自身的规则实现，不是四件套自动提供的保证。
25.2.4 合约钱包与账户抽象的应用
基于 AA 的合约钱包可以自定义“什么样的授权才算有效”，从而组合出：
- 多设备或多方共同签名；
- 守护人参与的社交恢复；
- 限定时间、额度或应用范围的会话密钥；
- 一次授权执行多步操作；
- 由应用或 Paymaster 代付 Gas；
- 通过更熟悉的登录或签名方式进入应用。
课程材料列举 Safe、Biconomy、Alchemy Account Kit 和 Argent 作为认知地图中的例子。它们所处的产品层、支持网络和服务条件会变化，名单不构成推荐；阅读时应优先查看各自官方文档，并确认权限、恢复和费用规则。
25.2.5 链抽象：用户表达 What，系统处理 How
账户抽象主要解决单条链上的账户和交易体验；链抽象进一步尝试处理多链资产和操作的碎片化。理想状态是用户表达“想完成什么”（What），而不必手动编排“在哪条链、用什么资产和 Gas、经过哪条路由”（How）。
在意图架构中，用户先给出目标、约束和可接受结果，Solver 或 Filler 再竞争寻找流动性、报价、路由和执行方式，并从执行中获得费用。隐藏步骤并不等于没有步骤，因此仍要问：
- 谁在求解、报价和执行？
- 谁暂时垫付资产或 Gas？
- 失败、延迟、报价变化或跨链回滚时谁负责？
- 签名授权如何撤销，用户能否限制权限和有效期？
- 求解器网络是否集中，是否存在审查或排序权？
课程中的方向示例包括 Particle Network 的 Universal Account、NEAR 的 Chain Signatures、Socket 的跨链基础设施和 UniswapX 的 Filler 网络。这些名称用于理解不同架构，不代表当前产品状态或使用建议。
25.2.6 AA 与链抽象的分工
| 方向 | 主要解决的问题 | 典型机制 | 新增的信任对象 |
|---|---|---|---|
| 账户抽象 AA | 单链内的签名、Gas、恢复和账户规则 | 合约账户、UserOperation、代付和自定义验证 | 合约账户、EntryPoint、Bundler、Paymaster、守护人 |
| 链抽象 | 多链之间的资产、路由和执行碎片 | 意图、Solver/Filler、统一账户或链签名 | Solver、Filler、跨链路由、报价和临时托管组件 |
两者共同追求更低摩擦的 Web3 体验，但“无感”只描述用户界面，不代表底层机制没有风险。用户只是从直接操作链，转向信任一组更复杂的系统组件。
25.2.7 现实挑战
- Bundler 和 Solver 可能出现集中化，服务中断或审查会影响可用性；
- 合约钱包、恢复逻辑和会话密钥增加代码、权限和审计难度；
- 代付 Gas 会降低成本感知，用户可能忽略真实权限和费用条件；
- 不同账户抽象和链抽象方案的标准碎片化，会影响钱包与应用之间的兼容性；
- 跨链路由、临时流动性和报价机制会产生新的失败、延迟和责任边界。
更简单的 UX 不等于没有风险。判断一个方案时，应把信任关系、权限范围、费用、延迟、可撤销性和故障恢复一起画出来。
概念结构
text
从“证明”到“好用”
├─ ZKP：证明为真，但不泄密
│ ├─ 核心悖论与阿里巴巴山洞
│ ├─ 完备性 / 可靠性 / 零知识性
│ ├─ 交互式 → Fiat-Shamir → NIZK
│ ├─ SNARK：证明小、验证快、部分方案需可信初始化
│ ├─ STARK：透明、可扩展、证明较大
│ ├─ 应用：ZK Rollup / 隐私 / 身份合规
│ └─ 瓶颈：Prover 成本、zkEVM、电路人才与审计
├─ 账户抽象 AA：单链内可编程账户
│ ├─ EOA 局限 → 合约账户逻辑
│ ├─ UserOperation：待处理的操作对象
│ ├─ Bundler：收集与打包
│ ├─ EntryPoint：验证与执行入口
│ └─ Paymaster：代付或替代支付 Gas
└─ 链抽象：多链对用户隐形
├─ 用户说 What，不手动编排 How
├─ Solver / Filler：竞价、路由与执行
├─ Universal Account / Chain Signatures / 跨链意图
└─ 风险：集中化、合约漏洞、标准碎片与责任不清理解重点是：ZKP 解耦“信任与信息”，AA 和链抽象解耦“用户目标与底层执行步骤”。 每次解耦都要继续问：谁生成结果、谁验证结果、谁收取费用、失败时谁能介入。
可验证问题
- 完备性、可靠性和零知识性分别保护什么？阿里巴巴山洞的哪个环节对应随机挑战？
- Fiat–Shamir 为什么能减少交互，但不能消除证明系统的假设？
- SNARK 的小证明与 STARK 的透明设置之间如何权衡？抗量子相关说法依赖哪些假设？
- ZK Rollup 的有效性证明与 Optimistic Rollup 的挑战机制有什么区别？
- UserOperation 与普通交易的角色有什么不同？
- Bundler、EntryPoint 和 Paymaster 各自承担什么工作？
- Paymaster 代付 Gas 后，用户新增了哪些信任依赖？
- 链抽象隐藏了哪些步骤，又把风险转移给了谁？
- 一个“无感”钱包流程如何让用户看见权限、费用和失败出口？
练习与复盘
只阅读一个公开技术方案的架构文档，不连接真实账户。分别画出：
- “证明者 → 验证者”的数据与信任关系；
- “用户 → Bundler / Paymaster 或 Solver → 底层链”的执行关系。
在图上标记数据、权限、费用、延迟和故障责任。最后写下：这个方案减少了用户哪一种复杂度，又把复杂度转移给了谁？
官方资料入口
来源与时效提醒
本页公开整理自课程 25 的 preview、线性笔记和 mindmap，并吸收了筛选后的补充摘注。课程结构按“ZKP 基础 → 非交互式证明 → SNARK/STARK → 应用与挑战 → 账户抽象 → 链抽象”的顺序呈现，以便与学习台的提要、笔记和导图相互对照。
项目主网状态、EIP-4337 采用情况、Bundler/Solver 集中度、证明成本、兼容性、审计质量和监管边界都会变化；课程材料中的历史线索、长期愿景和赛道分类不作为当前结论。
本页不构成对钱包、账户抽象、跨链产品或任何资产的推荐，也不提供真实账户操作步骤。