原作者: @Toni Wahrstätter
発売日：2023年9月12日
翻訳：デボックス研究所
Vitalik は、zk-SNARK を使用して、資産を保有するアカウントから取引ロジック アカウントを分離することを推奨しています。これにより、プライバシー、ユーザー エクスペリエンス、ワンクリックのソーシャル リカバリが向上します。イーサリアム研究者の Toni Wahrstätter が、このウォレットのプロトタイプの詳細な分析を提供し、ワークフローと利点をカバーしています。
このトピックに関する素晴らしい議論と、各コントラクトを解析し、パトリシア ツリーでの zk 証明の必要性を排除してプロトタイピングを簡素化するスパース マークル ツリーに入れるこのツールを開発してくれた Matt に感謝します。また、素晴らしい意見を提供してくれた Vitalik にも感謝します。
複数のアカウントの管理は、ソーシャル リカバリ、プライバシー、L2、全体的なユーザー エクスペリエンスの問題など、さまざまな理由から困難になる場合があります。ステルス アドレスを使用すると、やり取りのたびに新しいアカウントが必要になるため、事態はさらに複雑になります。 Vitalik は、zk-SNARK を使用して、資産を保有するアカウントから取引ロジック アカウントを分離することを推奨しています。これにより、プライバシー、ユーザー エクスペリエンス、ワンクリックのソーシャル リカバリが向上します。
以下については、まず Vitalik の「Three Transformations」の投稿を参照して背景を確認することをお勧めします。
一言で言えば、私たちが達成しようとしていることは次のとおりです。
**プライバシーを損なうことなく、ワンストップで社会的回復を実現します。 **
シンプルだがプライバシーを損なう実装は次のようになります。
!【ワンストップで社会回復：zk-SNARKsはウォレット取引ロジックと資産の分離をどのように実現するのか？ ](https://img-cdn.gateio.im/resize-social/moments-69a80767fe-2033ef09fa-dd1a6f-6d2ef1)
欠点は、これにより論理アカウントと資産保有アカウントが公的にリンクされるため、プライバシーが侵害されることです。
zk-SNARK を使用することにより、ユーザーは、論理保有口座と資産保有口座の間の関係を明らかにすることなく、支出が許可されていることを証明できます。
!【ワンストップで社会回復：zk-SNARKsはウォレット取引ロジックと資産の分離をどのように実現するのか？ ](https://img-cdn.gateio.im/resize-social/moments-69a80767fe-83b0e0f625-dd1a6f-6d2ef1)
ワークフローは次のとおりです。
1.1. マークル ツリーには基本的に、日付または名前で並べ替えられた既存の各契約のスロット 0 およびスロット 1 の値が含まれています。
1.2. 各ユーザーは、最新の状態に基づいてマークル ツリーをローカルに構築できます。
ユーザーは、論理保有口座の秘密を知っていることを証明するために zk 証明を構築します。詳しくは後ほど証明します。
ユーザーは、zk-proof を資産保有口座に送信します。
資産保有口座検証証明書。以下を確認します。
4.1 ユーザーはロジックがどこにあるかを知っています。
4.2 ユーザーは、ハッシュ化され、論理保有口座に保存されている値にマッピングされる秘密の値を知っています。
4.3 ユーザーは、正規チェーン (プリコンパイルなど) で維持されるアカウント状態のマークル ツリー ルートを再構築できます。
4.4 正しい乱数を使用します (論理保有口座のキーを切り替えるために使用されます)。
基本的に、ユーザーは、「私はこのアクションを実行するための論理保有口座から証明可能な権限を持っており、その論理口座の場所を知っています」と言うことができます。
アドバンテージ
さらに、ロジックと資産保有コントラクトの間に別の (アグリゲーター) コントラクトを追加することで、異なる資産保有アカウントの複数の証明を 1 つのトランザクションで提供でき、アカウントをほぼ UTXO のように扱うことができます。アグリゲーターは複数の zk 証明書を取得し、検証のためにそれぞれの資産保有口座に転送することができます。もちろん、そのようなアグリゲーターは、個々の資産保有口座間にプライバシーを含むリンクを作成する可能性があります。
SNARK を使用する (したがってそのセキュリティに依存する) か、SNARK をまったく使用しない (したがって優れたプライバシー特性を逃す) か、必ずしも二者択一ではないことは注目に値します。妥協策としては、SNARK プルーフを使用して論理保持コントラクトの時間枠を開き、その後少し待ってから、論理保持コントラクトの所有者がスロット 0 の値を変更できるようにするという方法があります。SNARK プルーフを費やす必要はなく、したがって、消費ロジックを変更します。契約の現在の所有者は、時間枠が開く前に遅延を使用して、資格情報の更新を防ぐことができます。
zk-SNARK 設定にはプライベート要素が含まれます。
※認証に使用するキーです。
1. 論理保有口座
論理保有口座のプロトタイプは次のようになります。
プラグマ ソリッドティ >=0.7.0 <0.9.0;
コントラクト LogicHoldingAccount は所有可能です { uint256 public slot0 = 0x1234; // ハッシュ化されたシークレット uint256 public nonce = 0; // キーの変更アドレスのパブリック所有者を追跡します。
関数 updateOwner(uint256 newValue) publiconlyOwner { nonce += 1;スロット0 = 新しい値;
このコントラクトは、所有者の現在の支出ロジック (slot0) を追跡し、updateOwner 関数による更新を許可します。
2. 口座保有口座
コントラクト AssetHoldingAccount { uint256 publiclogicHoldingAccountHash = 1234...;
// スカラー フィールド サイズ、ベース フィールド サイズ、検証キー データなど // ...
関数 verifyProof( uint [2] calldata _pA、単位 [2] [2] calldata _pB、単位 [2] calldata _pC、単位 [2] calldata _pubSignals) public view returns (bool val) { // 証明検証用の Snarkjs アセンブリ コード... // ... }
// _pubSignals [0] - Contract-slot0||ノンス マークル ツリーのルート // _pubSignals [1] - hased ロジックホルダー アドレス関数 ute( address payable to, uint256 amount, uint [2] calldata _pA、単位 [2] [2] calldata _pB、単位 [2] calldata _pC、単位 [2] calldata _pubSignals) public {contractRootPrecompile.getRoot(block.number) uint256 指定されたLogicHolder = _pubSignals [1] ; require(specifiedLogicHolder ==logicHoldingAccountHash, "許可されていません");
bool validProof = verifyProof(_pA, _pB, _pC, _pubSignals) == true; if (validProof) { (bool success,) = to.call{value:amount}("");必要(成功); } }
accept() 外部買掛金 {
資産保有アカウントにはETHなどの資産が保管されており、ユーザーは引き出しの証拠を提出できます。指定されたLogicHolderがlogicHoldingAccountHashと一致することを検証することにより、所有者は、資産保持契約が任意の契約ではなく、承認された論理保持契約からの証明のみを受け入れることを保証できます。
プルーフを構築するときにプライベート信号として提供されるシークレットにより、支出ロジックを含むアカウントの所有者のみが資産保有アカウントの資金にアクセスできることが保証されます。
3. 回路
次の回路は circom を使用して開発されました。完全なコードはここにあります。
プラグマ circom 2.0.2;
"./modules/merkleTree.circom" を含む; "./modules/commitmentHasher.circom" を含む;
template Main(levels) { 信号入力ルート;信号入力ロジックHoldingAddressHash;信号入力ロジック保持アドレス;信号入力の秘密。信号入力ノンス。信号入力パス要素 [levels] ;信号入力パスインデックス [levels] ;コンポーネント SecretHasher = SecretHasher(); SecretHasher.secret <== シークレット;コンポーネントハッシュ = CommitmentHasher(); hasher.logicHoldingAddress <==logicHoldingAddress; hasher.secret <== SecretHasher.hashedSecret; hasher.nonce <== nonce; hasher.logicHoldingAddressHash ===logicHoldingAddressHash;コンポーネント ツリー = MerkleTreeChecker(レベル); Tree.leaf <== hasher.commitment;ツリー.ルート <== ルート; for ( i = 0; i < レベル; i++) {tree.pathElements [i] <== パス要素 [i] ;ツリー.パスインデックス [i] <== パスインデックス [i] ;
コンポーネント main {public [root,logicHoldingAddressHash]} = Main(N);
この回路には合計 7 つの信号があり、そのうちの 2 つは公開されています。つまり、マークル ツリー ルートと論理保有口座のハッシュ アドレスです (オブザーバーが口座を集計できないように、資産保有契約にエンコードされる前にハッシュ化する必要があります)。クラス) は保有者口座と同じロジックに基づいています)。
＃＃＃ 結論は
ユーザーが複数のアカウントを管理する必要がある世界では、ワンストップのソーシャル リカバリ機能の必要性がますます重要になっています。 Zk-SNARKはロジック/資産分離を実装したウォレットで使用でき、ユーザーはアカウントAの「ロジック」を使用して、2つの間のリンクを作成せずにアカウントBから支出できるようになります。最初のステップとして、資産支出よりもリスクの低いアクションに SNARK プルーフを使用できます。たとえば、ユーザーが「引き出しリクエスト」を開始できるようにするのが良い出発点かもしれません。ロジック保持契約の所有者が異議を唱えない場合、ユーザーは一定期間後にリクエストを完了できます。
こうすることで、論理保有契約の所有者は、予期せぬことが起こった場合に備えて、たとえプライバシーを侵害する方法であっても介入することができます。
43k 人気度
46k 人気度
22k 人気度
18k 人気度
ワンストップの社会的回復: zk-SNARKs はウォレットのトランザクションロジックと資産の分離をどのように実現していますか?
原作者: @Toni Wahrstätter
発売日：2023年9月12日
翻訳：デボックス研究所
序文
Vitalik は、zk-SNARK を使用して、資産を保有するアカウントから取引ロジック アカウントを分離することを推奨しています。これにより、プライバシー、ユーザー エクスペリエンス、ワンクリックのソーシャル リカバリが向上します。イーサリアム研究者の Toni Wahrstätter が、このウォレットのプロトタイプの詳細な分析を提供し、ワークフローと利点をカバーしています。
複数のアカウントの管理は、ソーシャル リカバリ、プライバシー、L2、全体的なユーザー エクスペリエンスの問題など、さまざまな理由から困難になる場合があります。ステルス アドレスを使用すると、やり取りのたびに新しいアカウントが必要になるため、事態はさらに複雑になります。 Vitalik は、zk-SNARK を使用して、資産を保有するアカウントから取引ロジック アカウントを分離することを推奨しています。これにより、プライバシー、ユーザー エクスペリエンス、ワンクリックのソーシャル リカバリが向上します。
一言で言えば、私たちが達成しようとしていることは次のとおりです。
**プライバシーを損なうことなく、ワンストップで社会的回復を実現します。 **
1. 従来の方法
シンプルだがプライバシーを損なう実装は次のようになります。
!【ワンストップで社会回復：zk-SNARKsはウォレット取引ロジックと資産の分離をどのように実現するのか？ ](https://img-cdn.gateio.im/resize-social/moments-69a80767fe-2033ef09fa-dd1a6f-6d2ef1)
欠点は、これにより論理アカウントと資産保有アカウントが公的にリンクされるため、プライバシーが侵害されることです。
2. ZK-SNARKを使用する
zk-SNARK を使用することにより、ユーザーは、論理保有口座と資産保有口座の間の関係を明らかにすることなく、支出が許可されていることを証明できます。
!【ワンストップで社会回復：zk-SNARKsはウォレット取引ロジックと資産の分離をどのように実現するのか？ ](https://img-cdn.gateio.im/resize-social/moments-69a80767fe-83b0e0f625-dd1a6f-6d2ef1)
ワークフローは次のとおりです。
1.1. マークル ツリーには基本的に、日付または名前で並べ替えられた既存の各契約のスロット 0 およびスロット 1 の値が含まれています。
1.2. 各ユーザーは、最新の状態に基づいてマークル ツリーをローカルに構築できます。
ユーザーは、論理保有口座の秘密を知っていることを証明するために zk 証明を構築します。詳しくは後ほど証明します。
ユーザーは、zk-proof を資産保有口座に送信します。
資産保有口座検証証明書。以下を確認します。
4.1 ユーザーはロジックがどこにあるかを知っています。
4.2 ユーザーは、ハッシュ化され、論理保有口座に保存されている値にマッピングされる秘密の値を知っています。
4.3 ユーザーは、正規チェーン (プリコンパイルなど) で維持されるアカウント状態のマークル ツリー ルートを再構築できます。
4.4 正しい乱数を使用します (論理保有口座のキーを切り替えるために使用されます)。
基本的に、ユーザーは、「私はこのアクションを実行するための論理保有口座から証明可能な権限を持っており、その論理口座の場所を知っています」と言うことができます。
アドバンテージ
さらに、ロジックと資産保有コントラクトの間に別の (アグリゲーター) コントラクトを追加することで、異なる資産保有アカウントの複数の証明を 1 つのトランザクションで提供でき、アカウントをほぼ UTXO のように扱うことができます。アグリゲーターは複数の zk 証明書を取得し、検証のためにそれぞれの資産保有口座に転送することができます。もちろん、そのようなアグリゲーターは、個々の資産保有口座間にプライバシーを含むリンクを作成する可能性があります。
技術的な詳細
zk-SNARK 設定にはプライベート要素が含まれます。
※認証に使用するキーです。
1. 論理保有口座
論理保有口座のプロトタイプは次のようになります。
プラグマ ソリッドティ >=0.7.0 <0.9.0;
コントラクト LogicHoldingAccount は所有可能です { uint256 public slot0 = 0x1234; // ハッシュ化されたシークレット uint256 public nonce = 0; // キーの変更アドレスのパブリック所有者を追跡します。
関数 updateOwner(uint256 newValue) publiconlyOwner { nonce += 1;スロット0 = 新しい値;
このコントラクトは、所有者の現在の支出ロジック (slot0) を追跡し、updateOwner 関数による更新を許可します。
2. 口座保有口座
プラグマ ソリッドティ >=0.7.0 <0.9.0;
コントラクト AssetHoldingAccount { uint256 publiclogicHoldingAccountHash = 1234...;
// スカラー フィールド サイズ、ベース フィールド サイズ、検証キー データなど // ...
関数 verifyProof( uint [2] calldata _pA、単位 [2] [2] calldata _pB、単位 [2] calldata _pC、単位 [2] calldata _pubSignals) public view returns (bool val) { // 証明検証用の Snarkjs アセンブリ コード... // ... }
// _pubSignals [0] - Contract-slot0||ノンス マークル ツリーのルート // _pubSignals [1] - hased ロジックホルダー アドレス関数 ute( address payable to, uint256 amount, uint [2] calldata _pA、単位 [2] [2] calldata _pB、単位 [2] calldata _pC、単位 [2] calldata _pubSignals) public {contractRootPrecompile.getRoot(block.number) uint256 指定されたLogicHolder = _pubSignals [1] ; require(specifiedLogicHolder ==logicHoldingAccountHash, "許可されていません");
bool validProof = verifyProof(_pA, _pB, _pC, _pubSignals) == true; if (validProof) { (bool success,) = to.call{value:amount}("");必要(成功); } }
accept() 外部買掛金 {
資産保有アカウントにはETHなどの資産が保管されており、ユーザーは引き出しの証拠を提出できます。指定されたLogicHolderがlogicHoldingAccountHashと一致することを検証することにより、所有者は、資産保持契約が任意の契約ではなく、承認された論理保持契約からの証明のみを受け入れることを保証できます。
プルーフを構築するときにプライベート信号として提供されるシークレットにより、支出ロジックを含むアカウントの所有者のみが資産保有アカウントの資金にアクセスできることが保証されます。
3. 回路
次の回路は circom を使用して開発されました。完全なコードはここにあります。
プラグマ circom 2.0.2;
"./modules/merkleTree.circom" を含む; "./modules/commitmentHasher.circom" を含む;
template Main(levels) { 信号入力ルート;信号入力ロジックHoldingAddressHash;信号入力ロジック保持アドレス;信号入力の秘密。信号入力ノンス。信号入力パス要素 [levels] ;信号入力パスインデックス [levels] ;コンポーネント SecretHasher = SecretHasher(); SecretHasher.secret <== シークレット;コンポーネントハッシュ = CommitmentHasher(); hasher.logicHoldingAddress <==logicHoldingAddress; hasher.secret <== SecretHasher.hashedSecret; hasher.nonce <== nonce; hasher.logicHoldingAddressHash ===logicHoldingAddressHash;コンポーネント ツリー = MerkleTreeChecker(レベル); Tree.leaf <== hasher.commitment;ツリー.ルート <== ルート; for ( i = 0; i < レベル; i++) {tree.pathElements [i] <== パス要素 [i] ;ツリー.パスインデックス [i] <== パスインデックス [i] ;
コンポーネント main {public [root,logicHoldingAddressHash]} = Main(N);
この回路には合計 7 つの信号があり、そのうちの 2 つは公開されています。つまり、マークル ツリー ルートと論理保有口座のハッシュ アドレスです (オブザーバーが口座を集計できないように、資産保有契約にエンコードされる前にハッシュ化する必要があります)。クラス) は保有者口座と同じロジックに基づいています)。
＃＃＃ 結論は
ユーザーが複数のアカウントを管理する必要がある世界では、ワンストップのソーシャル リカバリ機能の必要性がますます重要になっています。 Zk-SNARKはロジック/資産分離を実装したウォレットで使用でき、ユーザーはアカウントAの「ロジック」を使用して、2つの間のリンクを作成せずにアカウントBから支出できるようになります。最初のステップとして、資産支出よりもリスクの低いアクションに SNARK プルーフを使用できます。たとえば、ユーザーが「引き出しリクエスト」を開始できるようにするのが良い出発点かもしれません。ロジック保持契約の所有者が異議を唱えない場合、ユーザーは一定期間後にリクエストを完了できます。
こうすることで、論理保有契約の所有者は、予期せぬことが起こった場合に備えて、たとえプライバシーを侵害する方法であっても介入することができます。