隐私账户的智能合约或EOA花费授权

免责声明： 这个想法和撰写都是与 @DamianStraszak 合作完成的。

总体思路

目标。 让一个标准的 EVM 账户，无论是 EOA 还是智能合约，成为批准从 ZK 私有账户支出的唯一授权者。

机制。 控制者签署一个 EIP-712（类型化的结构化数据）SpendAuthorization（支出授权），而单独的 proving_key（证明密钥）推导出 note 秘密并生成 ZK 证明。该证明必须与链上的授权承诺相匹配。

保证。 托管权保留在用户已经信任的相同 EVM 控制之下（硬件钱包、多重签名、治理），而证明和秘密存储可以在不赋予支出权力或泄露明文的情况下进行委托。

这使得：

• 使用现有的加密标准对私有账户进行多重签名或智能合约控制，

• 硬件钱包保护（控制者密钥存在于设备上；查看和证明秘密不存储在钱包上），

• 将秘密存储和证明委托给外部服务，而无需赋予其托管权（当然，即使使用 TEE，这确实在一定程度上损害了隐私保证），

• 直接的钱包集成 - 钱包将 EIP-712 数据附加到交易并与专用 RPC 通信，而无需处理秘密或证明，

• 可选的私下转账给从未系统用户，通过他们常用的EVM账户地址即可。收件人的秘密可以通过可信的中继器共享或使用 Waku/Whisper 加密，后者需要知道收件人的公钥。

局限性

• 一些信息泄露是不可避免的，但当按预期使用时，唯一可见的信号是“此地址控制的账户执行了某些操作”。在实践中：

  • 该系统是可选的；用户仍然可以在没有分离支出授权的经典模式下操作，

  • 授权和证明可以单独提交，允许基于时间的混合进行延迟证明。

核心概念

control_account（控制账户）- EOA 或智能合约。它仅用于授权操作，可以是具有硬件密钥的多重签名。在某些有限的能力下（尽管仍然合理），它甚至可以是 DAO 或任何其他没有独特签名能力的智能合约（即，不需要 EIP-1271 支持）。

proving_key（证明密钥）- 用于 (a) 解密 SpendAuthorization 和状态快照以及 (b) 推导新的 note 秘密的密钥对。泄露会损害隐私，而不是托管权。轮换由 control_account 授权。

SpendAuthorization（支出授权）- 由 control_account 发送的类型化指令，用于绑定待证明的操作（转账或提款，存款不需要 SpendAuthorization）。SpendAuthorizations 存储在专用的 Merkle 树中。支出证明必须包括匹配 SpendAuthorization 的 Merkle 成员资格证明。

Rotation（轮换）— control_account 和 proving_key 都可以轮换，而无需在链上泄露轮换（使用来自 control_account 的授权轮换注册的 proving_key）。

交易期间的操作顺序：

Controller（控制者）（持有 control_account）通过创建 SpendAuthorization 来授权操作。

Prover（证明者）（持有 proving_key）存储秘密并生成证明。

当以下情况发生时，交易成功：

1. SpendAuthorization 由控制者插入到 SpendAuthorization Merkle 树中

2. 证明者提交一个 ZK 证明，该证明消耗了授权的 note 并匹配 SpendAuthorization。（这可以通过外部证明者在另一个交易中完成，或者可选择 - 与 SpendAuthorisation 一起提交以进行 gas 优化）

一个重要的例子：control_account 是一个多重签名，例如 SAFE 账户，其中一个签名者存储 ZK 秘密并运行证明者。所有签名者都已经看到账户状态，因此由于证明委托，不会丢失额外的隐私。

详情：

我们假设读者熟悉基于 ZK 的隐私在 EVM 系统中如何工作，因此不定义 note、trapdoor 和 nullifier 等术语，也不解释需要验证哪些约束才能执行常规的私有交易。具体实施在一些技术细节上有所不同（包括处理 nullifier），但这些差异与所提出的内容无关。特定的描述可以在这里找到：https://docs.blanksquare.io/protocol-details/shielder 或这里：https://docs.railgun.org/wiki/learn/privacy-system。

Note 结构：

每个 note 都包含通常的字段和一个可选字段：

• control_account: address | 0 - 如果非零，则支出必须与此地址授权的 SpendAuthorization 匹配。

新的 note 秘密（trapdoor 和稍后将生成 nullifier 的秘密）是从由 proving_key 密钥控制的 PRF 派生的，允许在丢失其他秘密的情况下进行恢复。

如果 control_account 字段设置为 0，则隐私系统的工作方式与没有此修改相同，即 SpendAuthorisation 的证明被简单地接受，允许不需要 SpendAuthorisations 的交易与确实需要 SpendAuthorisations 的交易混合在一起，但选择延迟执行（即，不在与 SpendAuthorisation 相同的交易中发送证明）。

SpendAuthorization Merkle 树

创建了一个额外的 Merkle 树，其中 SpendAuthorizations 存储为 pairs (control_account, enc_ck(SpendAuthorization))，其中 enc_ck 是对称加密，密钥由 proving_key 通过 snark 友好的对称加密方案（例如，这个）派生。SpendAuthorization 本身包含以下字段：

opType,               // TRANSFER | WITHDRAW
invalidatedNotesHash, // 输入 note 承诺的排序列表的哈希值
newNotesHash,         // 输出 note 承诺的排序列表的哈希值
value,                // WITHDRAW value（TRANSFER 为 0）
recipient,            // EVM 地址（TRANSFER 为 0）
expiry,               // 在此授权失效后的区块/时间
control_account,      // 地址
privacySystemId       // EIP-712 中的域分离

为了将 SpendAuthorization 插入到 Merkle 树中，控制器调用：

• AddSpendAuthorization：control_account 提交 ciphertext（密文）。合约添加 (control_account, ciphertext) 并附加它。

对 SpendAuthorization 创建的评论：

一般来说，用户有两种方式使用这个系统 - 通过在本地存储所有秘密，或将它们委托给一些外部系统。在第一种情况下，SpendAuthorization 可以很容易地基于所有拥有的数据创建。在后一种情况下，它有点棘手，控制器确实需要在构建授权之前启动与 Prover 的通信，以便了解：

• 当前的 note

• 应用于创建新 note 的密码（从 proving_key 派生，可能不在控制器的控制范围内）

隐私模型：

乍一看，直接从 control_account 提交 SpendAuthorizations 似乎完全破坏了系统的目的，因为它泄露了与控制器的关系。但事实并非如此：

• 在私有交易的上下文中，实际泄露的唯一信息是 control_account 执行了某些操作。可以说，这是一种相当高的隐私程度，特别是 control_account 可以随意私下轮换，而新的 control_account 只需要用于提交交易的 gas 成本。

• 即使在提款的上下文中，也并非所有隐私都需要泄露 - 通过延迟执行（即，使用 AddSpendAuthorization 并通过中继器延迟发送证明），用户可以有效地降低将特定提款与提交 SpendAuthorization 这一事实联系起来的可能性。

• 总的来说，当提交带有证明的 SpendAuthorization 时，即使对于通常不使用该系统的接收者，也建议使用私有交易。接收者可能会延迟认领收到的转账这一事实增加了隐私性。

威胁模型

• proving_key 泄露：攻击者可以读取轮换期之间的余额/历史记录，但无法支出。

• 对 control_account 的访问泄露：托管权丢失

• prover/relayer 是恶意的：他们不能在没有 SpendAuthorization 的情况下支出；他们可以扣留证明，但切换 relayer 可以解决它

为了简洁起见，省略了合理的扩展：

• 应该将查看标签添加到 SpendAuthorizations，以简化对拥有的 SpendAuthorizations 的扫描

• 原文链接： ethresear.ch/t/smart-con...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～