无需更改底层协议的以太坊的私人账户模块引介

介绍

以太坊生态系统拥有最多的开发人员和用户活动，但默认情况下，公众是更多现实世界用例和采用的障碍。用户可以使用一个公共地址管理多个一次性地址的私人帐户模块可能是一种解决方案。每个一次性地址可以用于不同的用例，使用户活动不可链接，同时只需要一个私钥来管理所有这些地址并使其用户友好。从本质上讲，这为以太坊及其相应的L2s增加了一层隐私，而不需要共识或协议层更改。从用户的角度来看，不需要改变用户的行为，因为用户仍然像现在一样用单个账户签署交易，因为一次性地址大多是从最终用户抽象出来的。这样一个模块的动机是方便地在EVM链上启用隐私。隐形地址管理多个地址与元密钥对，但不保护发件人的隐私。

体系结构

有几个组件可以实现这一点。首先，一个多资产屏蔽池，可以支持任何ERC20, ERC721, ERC1155代币，同时共享相同的匿名集。多资产屏蔽池使用增量默克尔树，其叶子是对用户交易输出的UTXO式的承诺。用户必须生成零知识证明来证明屏蔽池内资产的所有权(ZK证明它拥有相应的承诺说明私钥)，然后允许他们与他们的资产进行交互。一旦发布了承诺说明，就会在链上发布无效者。通过使用多资产屏蔽池，它打开了设计空间，因为包括长尾资产在内的任何代币现在都可以存入屏蔽池，并且仍然可以在屏蔽池内执行交换，从而更容易引导隐私集。(UTXO承诺设计改编自Tornado Nova，而对多资产的支持则受到Anoma的启发。)

第二个组件是生成一次性帐户。每个一次性账户都是一个兼容ERC4337的智能合约账户。用户通过使用确定性签名(RFC6979)为这些一次性帐户生成熵，其中熵被工厂合约用于创建智能合约帐户。由于签名是确定的，因此可以计算出这些一次性帐户的反事实地址。然后，用户将能够使用中继网络从多资产屏蔽池中为这些一次性地址提供资金。然而，为了完全兼容ERC4337，我们使用paymaster模块来为屏蔽池提取的gas费用提供资金，同时从提取的资产中获得费用。因此，它提高了审查阻力，因为中继网络本质上是账户抽象系统的捆绑网络。

上图显示了生成一次性帐户的流程。从本质上讲，用户将通过一个多资产保护池来分配他们的资金，并最初依靠paymaster模块来为这些一次性账户提供资金。

第三个组件是客户端SDK，它允许用户使用其公共和永久帐户的密钥对来证明其一次性帐户的所有权(从而花费资产)。这需要生成零知识证明，以证明用户知道用于创建一次性帐户的熵的秘密。生成ZK证明还需要将一次性帐户的nonce作为公共输入，以防止身份验证流程的重放攻击。秘密是通过确定性签名生成的，因此用户不需要将秘密存储在任何地方。

把这些部分放在一起，用户流看起来是这样的：

1.用户有一个现有的公共EOA帐户。

2.用户将能够将一些资金(任何资产)存入多资产屏蔽池。

3.每次用户想为任何用例私下进行交易时，都会通过paymaster生成一个新的一次性地址并为其提供资金，然后用户将能够从一次性地址进行交易。所有这些都由客户端SDK管理，因此为用户抽象出来。

4.从用户的角度来看，它仍然只是使用其公共帐户签署交易。用户只需要管理一个密钥对，即公共帐户的密钥对。

为了展示私人帐户模块的使用，我们认为最好以钱包界面的形式呈现它。用户能够在一个界面内管理多个一次性帐户。使用一次性帐户来实现隐私的原因是为了确保与现有dApp的轻松集成和完全可组合性，因为它不需要维护单独的寻址系统。

未来的工作

可以嵌入一个可选的合规机制。一直存在不良行为者利用隐私协议进行非法活动的风险，包括臭名昭著的Tornado Cash。我们定义了一个模块，在这个模块中，治理将能够将特定的存款添加到区块列表中。使用稀疏的默克尔树，用户必须生成一个零知识证明，以证明他们每次想要与他们的存款资产进行交互时，他们不是这个黑名单的成员。这是一个模块化组件，因为应用程序可以决定是否包含此功能。现有的实现包括Chainway的无罪证明和Ameen的隐私池。

寻求反馈和合作

我们相信隐私是以太坊区块链在现实世界中被更多采用的基本组成部分。我们的思维模式是，要真正采用隐私，它必须作为主流消费产品的默认层来采用，这就是为什么我们在帐户级别构建这个开源模块，而不是构建另一个私有DeFi协议，要求用户明确选择隐私。我们相信私人账户模块可以成为钱包集成的中间件，因为它不需要终端用户的太多行为改变。

私人账户模块目前在GitHub上开源- eerkaijun/private-accounts 3(改编自ZrcLib，这是我们在一个月的黑客之家建立的一个屏蔽池开源库，向Rudi和ZP致敬)。我们希望获得社区对架构设计和任何相关方面的反馈，因此很乐意听到您对改进的想法和建议。如果你有兴趣贡献，请在Telegram上联系我@kaijuneer。

我们建议将上述架构作为管理私人帐户的基准。以下是一些开放式问题：

• 使用单个密钥对来管理所有一次性帐户，本质上存在密钥丢失/泄露的风险。但我们不能使用智能合约账户作为主账户，因为智能合约不能签名，而签名是证明一次性账户所有权所必需的。另一种选择是使用Vitalik建议的密钥存储库合约。
• 用户要证明自己的一次性账户的所有权，智能合约账户需要进行链上零知识证明验证。这本质上大大增加了交易成本，即使在L2上也是如此。证明聚合可能是一个值得进一步探索的设计领域。

用户如何证明一次性帐户所有权的流程