一站式社交恢复： zk-SNARKs如何实现钱包的交易逻辑与资产分离？ - Techub News

一站式社交恢复： zk-SNARKs如何实现钱包的交易逻辑与资产分离？ - Techub News

一站式社交恢复： zk-SNARKs如何实现钱包的交易逻辑与资产分离？

2023/09/28 17:52

panewslab1491 篇文章

原文作者:@Toni Wahrstätter

发布日期：2023 年 9月 12日

翻译：DeBox研究院

前言

Vitalik 建议使用 zk-SNARKs 将交易逻辑账户与持有资产的账户分开。这样可以改善隐私，用户体验和一键式社交恢复。以太坊研究员 Toni Wahrstätter 对此钱包原型进行详细解析，涵盖工作流和优势。

非常感谢Matt就该主题进行了精彩的讨论，并开发了这个工具来解析每个合约并将其放入稀疏的 Merkle 树中，该树无需在 patricia 树上进行 zk 证明，从而简化了原型设计。另外，感谢Vitalik的大力投入。

由于多种原因，管理多个帐户可能具有挑战性，包括社交恢复、隐私、L2 和整体用户体验问题。使用隐形地址会使事情变得更加复杂，因为每次交互都需要一个新帐户。Vitalik建议使用 zk-SNARKs 将交易逻辑账户与持有资产的账户分开。这可以改善隐私、用户体验和一键社交恢复。

对于以下内容，建议首先查看 Vitalik 的“三个转变”帖子以了解一些背景知识。

简而言之，我们试图实现的目标是：

在不损害隐私的情况下一站式社交恢复。

一、传统的方法

一个简单但会损害隐私的实现如下所示：

一站式社交恢复： zk-SNARKs如何实现钱包的交易逻辑与资产分离？

用户向资产持有账户提供签名和一些意图/命令。

资产持有账户将签名转发给逻辑持有账户。

逻辑持有账户从签名中导出公钥，并将其与它存储的公钥进行比较。

如果验证通过，逻辑账户将通知资产持有账户继续操作。

资产持有账户执行用户的命令。

缺点是，这将逻辑账户和资产持有账户公开联系起来，从而损害了隐私。

二、使用ZK-SNARK

通过使用 zk-SNARK，用户可以证明他们有权支出，而无需透露逻辑持有账户和资产持有账户之间的联系。

一站式社交恢复： zk-SNARKs如何实现钱包的交易逻辑与资产分离？

工作流程如下所示：

1. 用户在本地构建一棵 Merkle 树并识别包含其合约的叶子。

1.1. Merkle 树基本上包含按日期或名称排序的每个现有合约的 slot0 和 slot1 值。

1.2. 每个用户都可以根据最近的状态在本地构建 Merkle 树。

2. 用户构造一个 zk 证明，证明知道逻辑持有帐户中的秘密。稍后再详细证明。

3. 用户将 zk-proof 发送到资产持有账户。

4. 资产持有账户验证证明，确认以下内容：

4.1用户知道逻辑在哪里。

4.2 用户知道一个秘密值，该秘密值在散列后映射到存储在逻辑持有账户中的值。

4.3用户可以重建在规范链中维护的帐户状态默克尔树根（例如预编译）

4.4使用正确的随机数（用于切换逻辑持有账户中的密钥）。

本质上，用户可以说：“我拥有逻辑持有帐户的可证明的权限来执行此操作，并且我知道该逻辑帐户的位置。”

优点

用户体验：一个私钥或一个多重签名设置可以控制多个帐户，即使它们位于不同的 L2 上。

恢复：通过一次合同更新可以更轻松地恢复帐户。

隐私：各个帐户之间没有公共链接。

兼容性：这有助于普及帐户抽象（AA）钱包和其他功能。

此外，通过在逻辑和资产持有合约之间添加另一个（聚合器）合约，可以在一次交易中提供不同资产持有账户的多个证明，从而几乎可以像 UTXO 一样对待账户。聚合器将能够获取多个 zk 证明并将其转发到各自的资产持有账户进行验证。当然，这样的聚合器可以在各个资产持有账户之间创建链接——包括隐私。

值得注意的是，使用 SNARK（因此依赖其安全性）和根本不使用 SNARK（因此错过了良好的隐私属性）之间不一定是二选一。一种折中方案可以是使用 SNARK 证明在逻辑持有合约中打开一个时间窗口，然后短暂延迟，之后逻辑持有合约的所有者可以更改 slot0 值，而不是要求 SNARK 证明来进行支出，从而改变消费逻辑。合约的当前所有者可以使用时间窗口打开之前的延迟来阻止凭证更新。

技术细节

zk-SNARK 设置包括私有元素：

用于验证的密钥。

逻辑持有账户地址为资产持有账户所指向的地址。

Merkle 分支来识别特定的状态值。

允许密钥轮换同时使旧密钥无效的随机数。明文逻辑持有合约地址和秘密等私有元素不公开，而是用于私下链接逻辑持有账户和资产持有账户。通过生成整个状态的证明，不需要中央机构来构建默克尔树来提交证明。

1、逻辑持有账户

逻辑持有账户的原型可能如下所示：

pragma solidity >=0.7.0 <0.9.0;

contract LogicHoldingAccount is Ownable { uint256 public slot0 = 0x1234; // hashed secret uint256 public nonce = 0; // keep track of key changes address public owner;

function updateOwner(uint256 newValue) public onlyOwner { nonce += 1; slot0 = newValue; }}

slot0：最初保存哈希值的公共变量。只有所有者知道哈希的原像。

nonce：跟踪所有者信息更新次数的计数器。这确保旧密钥变得无效。

updateOwner(uint256 newValue)：更新值并增加随机数的函数。

该合约跟踪所有者当前的支出逻辑 (slot0) 并允许通过该updateOwner函数进行更新。

2、账户持有账户

pragma solidity >=0.7.0 <0.9.0;

contract AssetHoldingAccount { uint256 public logicHoldingAccountHash = 1234...;

// Scalar field size, Base field size, Verification Key data, etc. // ...

function verifyProof( uint[2] calldata _pA, uint[2][2] calldata _pB, uint[2] calldata _pC, uint[2] calldata _pubSignals) public view returns (bool val) { // Snarkjs assembly code for proof verification... // ... }

// _pubSignals[0] - the root of the contract-slot0||nonce Merkle tree // _pubSignals[1] - the hased logic-holder address function execute( address payable to, uint256 amount, uint[2] calldata _pA, uint[2][2] calldata _pB, uint[2] calldata _pC, uint[2] calldata _pubSignals) public { contractRootPrecompile.getRoot(block.number) uint256 specifiedLogicHolder = _pubSignals[1]; require(specifiedLogicHolder == logicHoldingAccountHash, "Not allowed");

bool validProof = verifyProof(_pA, _pB, _pC, _pubSignals) == true; if (validProof) { (bool success,) = to.call{value:amount}(""); require(success); } }

receive() external payable {}}

资产持有账户存储ETH等资产，并允许用户提交提款证明。通过验证是否specifiedLogicHolder匹配logicHoldingAccountHash，所有者可以确保资产持有合约仅接受来自授权逻辑持有合约的证明，而不是任何任意合约。

在构造证明时作为私人信号提供的秘密确保只有包含支出逻辑的帐户的所有者才能从资产持有帐户访问资金。

3、电路

以下电路是使用circom开发的，完整的代码可以在这里找到。

pragma circom 2.0.2;

include "./modules/merkleTree.circom";include "./modules/commitmentHasher.circom";

template Main(levels) { signal input root; signal input logicHoldingAddressHash; signal input logicHoldingAddress; signal input secret; signal input nonce; signal input pathElements[levels]; signal input pathIndices[levels]; component secretHasher = SecretHasher(); secretHasher.secret <== secret; component hasher = CommitmentHasher(); hasher.logicHoldingAddress <== logicHoldingAddress; hasher.secret <== secretHasher.hashedSecret; hasher.nonce <== nonce; hasher.logicHoldingAddressHash === logicHoldingAddressHash; component tree = MerkleTreeChecker(levels); tree.leaf <== hasher.commitment; tree.root <== root; for (var i = 0; i < levels; i++) { tree.pathElements[i] <== pathElements[i]; tree.pathIndices[i] <== pathIndices[i]; }}

component main {public [root,logicHoldingAddressHash]} = Main(N);

该电路共有 7 个信号，其中 2 个是公开的，即 Merkle 树根和逻辑持有账户的哈希地址（在编码到资产持有合约之前必须进行哈希处理，以防止观察者对账户进行聚类）基于相同的逻辑持有者帐户）。

结论

在用户必须管理多个帐户的世界中，对一站式社交恢复功能的需求变得越来越重要。Zk-SNARK 可用于实现逻辑/资产分离的钱包，使用户能够使用账户 A 的“逻辑”从账户 B 进行支出，而无需在两者之间创建链接。作为第一步，SNARK 证明可以用于风险低于资产支出的行动。例如，一个好的起点可能是允许用户发起“提款请求”。如果逻辑持有合约的所有者没有提出异议，用户可以在一段时间后最终确定该请求。

这样，逻辑持有合约的所有者仍然可以进行干预，尽管是以破坏隐私的方式，以防出现意外情况。

Techub News文章2023/09/28 17:52

一站式社交恢复： zk-SNARKs如何实现钱包的交易逻辑与资产分离？

2023/09/28 17:52 · 11 分钟阅读

来源：panewslab

原文作者:@Toni Wahrstätter

发布日期：2023 年 9月 12日

翻译：DeBox研究院

前言

Vitalik 建议使用 zk-SNARKs 将交易逻辑账户与持有资产的账户分开。这样可以改善隐私，用户体验和一键式社交恢复。以太坊研究员 Toni Wahrstätter 对此钱包原型进行详细解析，涵盖工作流和优势。

非常感谢Matt就该主题进行了精彩的讨论，并开发了这个工具来解析每个合约并将其放入稀疏的 Merkle 树中，该树无需在 patricia 树上进行 zk 证明，从而简化了原型设计。另外，感谢Vitalik的大力投入。

由于多种原因，管理多个帐户可能具有挑战性，包括社交恢复、隐私、L2 和整体用户体验问题。使用隐形地址会使事情变得更加复杂，因为每次交互都需要一个新帐户。Vitalik建议使用 zk-SNARKs 将交易逻辑账户与持有资产的账户分开。这可以改善隐私、用户体验和一键社交恢复。

对于以下内容，建议首先查看 Vitalik 的“三个转变”帖子以了解一些背景知识。

简而言之，我们试图实现的目标是：

在不损害隐私的情况下一站式社交恢复。

一、传统的方法

一个简单但会损害隐私的实现如下所示：

一站式社交恢复： zk-SNARKs如何实现钱包的交易逻辑与资产分离？

用户向资产持有账户提供签名和一些意图/命令。

资产持有账户将签名转发给逻辑持有账户。

逻辑持有账户从签名中导出公钥，并将其与它存储的公钥进行比较。

如果验证通过，逻辑账户将通知资产持有账户继续操作。

资产持有账户执行用户的命令。

缺点是，这将逻辑账户和资产持有账户公开联系起来，从而损害了隐私。

二、使用ZK-SNARK

通过使用 zk-SNARK，用户可以证明他们有权支出，而无需透露逻辑持有账户和资产持有账户之间的联系。

一站式社交恢复： zk-SNARKs如何实现钱包的交易逻辑与资产分离？

工作流程如下所示：

1. 用户在本地构建一棵 Merkle 树并识别包含其合约的叶子。

1.1. Merkle 树基本上包含按日期或名称排序的每个现有合约的 slot0 和 slot1 值。

1.2. 每个用户都可以根据最近的状态在本地构建 Merkle 树。

2. 用户构造一个 zk 证明，证明知道逻辑持有帐户中的秘密。稍后再详细证明。

3. 用户将 zk-proof 发送到资产持有账户。

4. 资产持有账户验证证明，确认以下内容：

4.1用户知道逻辑在哪里。

4.2 用户知道一个秘密值，该秘密值在散列后映射到存储在逻辑持有账户中的值。

4.3用户可以重建在规范链中维护的帐户状态默克尔树根（例如预编译）

4.4使用正确的随机数（用于切换逻辑持有账户中的密钥）。

本质上，用户可以说：“我拥有逻辑持有帐户的可证明的权限来执行此操作，并且我知道该逻辑帐户的位置。”

优点

用户体验：一个私钥或一个多重签名设置可以控制多个帐户，即使它们位于不同的 L2 上。

恢复：通过一次合同更新可以更轻松地恢复帐户。

隐私：各个帐户之间没有公共链接。

兼容性：这有助于普及帐户抽象（AA）钱包和其他功能。

此外，通过在逻辑和资产持有合约之间添加另一个（聚合器）合约，可以在一次交易中提供不同资产持有账户的多个证明，从而几乎可以像 UTXO 一样对待账户。聚合器将能够获取多个 zk 证明并将其转发到各自的资产持有账户进行验证。当然，这样的聚合器可以在各个资产持有账户之间创建链接——包括隐私。

值得注意的是，使用 SNARK（因此依赖其安全性）和根本不使用 SNARK（因此错过了良好的隐私属性）之间不一定是二选一。一种折中方案可以是使用 SNARK 证明在逻辑持有合约中打开一个时间窗口，然后短暂延迟，之后逻辑持有合约的所有者可以更改 slot0 值，而不是要求 SNARK 证明来进行支出，从而改变消费逻辑。合约的当前所有者可以使用时间窗口打开之前的延迟来阻止凭证更新。

技术细节

zk-SNARK 设置包括私有元素：

用于验证的密钥。

逻辑持有账户地址为资产持有账户所指向的地址。

Merkle 分支来识别特定的状态值。

允许密钥轮换同时使旧密钥无效的随机数。明文逻辑持有合约地址和秘密等私有元素不公开，而是用于私下链接逻辑持有账户和资产持有账户。通过生成整个状态的证明，不需要中央机构来构建默克尔树来提交证明。

1、逻辑持有账户

逻辑持有账户的原型可能如下所示：

pragma solidity >=0.7.0 <0.9.0;

contract LogicHoldingAccount is Ownable { uint256 public slot0 = 0x1234; // hashed secret uint256 public nonce = 0; // keep track of key changes address public owner;

function updateOwner(uint256 newValue) public onlyOwner { nonce += 1; slot0 = newValue; }}

slot0：最初保存哈希值的公共变量。只有所有者知道哈希的原像。

nonce：跟踪所有者信息更新次数的计数器。这确保旧密钥变得无效。

updateOwner(uint256 newValue)：更新值并增加随机数的函数。

该合约跟踪所有者当前的支出逻辑 (slot0) 并允许通过该updateOwner函数进行更新。

2、账户持有账户

pragma solidity >=0.7.0 <0.9.0;

contract AssetHoldingAccount { uint256 public logicHoldingAccountHash = 1234...;

// Scalar field size, Base field size, Verification Key data, etc. // ...

function verifyProof( uint[2] calldata _pA, uint[2][2] calldata _pB, uint[2] calldata _pC, uint[2] calldata _pubSignals) public view returns (bool val) { // Snarkjs assembly code for proof verification... // ... }

// _pubSignals[0] - the root of the contract-slot0||nonce Merkle tree // _pubSignals[1] - the hased logic-holder address function execute( address payable to, uint256 amount, uint[2] calldata _pA, uint[2][2] calldata _pB, uint[2] calldata _pC, uint[2] calldata _pubSignals) public { contractRootPrecompile.getRoot(block.number) uint256 specifiedLogicHolder = _pubSignals[1]; require(specifiedLogicHolder == logicHoldingAccountHash, "Not allowed");

bool validProof = verifyProof(_pA, _pB, _pC, _pubSignals) == true; if (validProof) { (bool success,) = to.call{value:amount}(""); require(success); } }

receive() external payable {}}

资产持有账户存储ETH等资产，并允许用户提交提款证明。通过验证是否specifiedLogicHolder匹配logicHoldingAccountHash，所有者可以确保资产持有合约仅接受来自授权逻辑持有合约的证明，而不是任何任意合约。

在构造证明时作为私人信号提供的秘密确保只有包含支出逻辑的帐户的所有者才能从资产持有帐户访问资金。

3、电路

以下电路是使用circom开发的，完整的代码可以在这里找到。

pragma circom 2.0.2;

include "./modules/merkleTree.circom";include "./modules/commitmentHasher.circom";

template Main(levels) { signal input root; signal input logicHoldingAddressHash; signal input logicHoldingAddress; signal input secret; signal input nonce; signal input pathElements[levels]; signal input pathIndices[levels]; component secretHasher = SecretHasher(); secretHasher.secret <== secret; component hasher = CommitmentHasher(); hasher.logicHoldingAddress <== logicHoldingAddress; hasher.secret <== secretHasher.hashedSecret; hasher.nonce <== nonce; hasher.logicHoldingAddressHash === logicHoldingAddressHash; component tree = MerkleTreeChecker(levels); tree.leaf <== hasher.commitment; tree.root <== root; for (var i = 0; i < levels; i++) { tree.pathElements[i] <== pathElements[i]; tree.pathIndices[i] <== pathIndices[i]; }}

component main {public [root,logicHoldingAddressHash]} = Main(N);

该电路共有 7 个信号，其中 2 个是公开的，即 Merkle 树根和逻辑持有账户的哈希地址（在编码到资产持有合约之前必须进行哈希处理，以防止观察者对账户进行聚类）基于相同的逻辑持有者帐户）。

结论

在用户必须管理多个帐户的世界中，对一站式社交恢复功能的需求变得越来越重要。Zk-SNARK 可用于实现逻辑/资产分离的钱包，使用户能够使用账户 A 的“逻辑”从账户 B 进行支出，而无需在两者之间创建链接。作为第一步，SNARK 证明可以用于风险低于资产支出的行动。例如，一个好的起点可能是允许用户发起“提款请求”。如果逻辑持有合约的所有者没有提出异议，用户可以在一段时间后最终确定该请求。

这样，逻辑持有合约的所有者仍然可以进行干预，尽管是以破坏隐私的方式，以防出现意外情况。