[EIP7503] 送付元を隠してETHを送付できる仕組みを理解しよう！

はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

https://amzn.asia/d/gxvJ0Pw

今回は、ゼロ知識証明を使用してETHを誰もアクセスできないアドレスに送信し、後から再ミントできるようにすることで、Ethereumにネイティブなプライバシーソリューションを提供するEIP7503についてまとめていきます！

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

概要

EIP7503とは、「Zero-Knowledge Wormholes」（ゼロ知識ワームホール）と呼ばれる技術を使用して、ETHを誰もアクセスできないアドレスに送信してBurnし、後からそのBurnしたETHをゼロ知識証明で再ミントできるようにする提案のことです。 これにより、送信者のプライバシーを強力に保護しながら、資金を新しいアドレスに移動できます。

主要な特徴

動機

TornadoCashのような暗号通貨ミキサーはEthereumのトランザクションを効果的に難読化できますが、政府による使用禁止が容易です。 ミキサーコントラクトとやり取りする人は、送信者であれ受信者であれ、マークされる可能性があります。

EIP7503は、資金を送信するためにスマートコントラクトとのやり取りを必要とせず、プレーンなEOA間の転送のみを使用することで、送信者のプライバシー漏洩を最小化しようとしています。

以下の図は、TornadoCashのようなミキサーとEIP7503のアプローチの違いを示しています。

sequenceDiagram
    participant U as ユーザー
    participant M as ミキサーコントラクト
    participant C as ブロックチェーン

    Note over U,C: TornadoCash（既存ミキサー）
    U->>M: ETHを入金（コントラクト呼び出し）
    Note right of M: ミキサーとのやり取りが<br/>オンチェーンで記録される
    M->>U: ETHを出金（コントラクト呼び出し）
    Note right of U: 送受信者がマーク可能

    Note over U,C: EIP7503（この提案）
    U->>C: ETHを通常送金（EOA→EOA）
    Note right of C: 友人への送金と区別不可能
    U->>C: Wormholeトランザクションで再ミント
    Note right of U: プライバシープロトコルへの<br/>参加を証明不可能

ミキサーではコントラクトとのやり取りが記録されるため追跡可能ですが、EIP7503では通常のEOA間送金のみを使用するため、プライバシープロトコルへの参加を第三者が証明できません。

既存ミキサーの問題点

EIP7503のアプローチ

この提案では、ETHを一旦Burnして別のアドレスで再ミントする仕組みを実現するために、すべてのEthereumアドレスを2つのグループに分割します。

通常のアドレスと誰もアクセスできないアドレスは外見上区別できないため、この事実を利用して、誰もアクセスできないアドレスに送られた資金に対する新たなルールを定義できます。

仕様

パラメータ

以下の図は、secretから各パラメータがどのように導出されるかを示しています。

flowchart LR
    S[secret] --> A["sha256(MAGIC_ADDRESS + secret)[12:]<br/>→ 送金先アドレス"]
    S --> B["sha256(MAGIC_NULLIFIER + secret)<br/>→ ナリファイア（二重ミント防止）"]
    S --> C["sha256(MAGIC_POW + secret)<br/>→ PoW検証（衝突攻撃防止）"]

1つのsecretから、送金先アドレス、ナリファイア、PoW検証値の3つが導出されます。 送金先アドレスはETHの送信先として使用され、ナリファイアは同じ入金からの二重ミントを防ぎ、PoW検証はハッシュ衝突攻撃の難易度を引き上げます。

トランザクションタイプ

新しいEIP2718トランザクションタイプを定義します。 TransactionTypeはWormholeTxTypeで、TransactionPayloadの形式は以下の通りです。

このトランザクションペイロードには、標準的なトランザクションフィールドに加えて、root_beacon_block_numberとproofが含まれます。 root_beacon_block_numberは証明で使用するビーコンブロックの番号を指定し、proofはゼロ知識証明を含みます。

ゼロ知識証明の検証

このタイプのトランザクションを検証するには、以下を確認する必要があります。

証明の入力

以下の図は、private入力とpublic入力の関係を示しています。

flowchart TD
    subgraph private["private入力（秘密）"]
        S[secret]
        MI[main_index / main_branch]
        PI[privacy_pool_index / privacy_pool_branch]
        DV[deposit_value / deposit_sender]
        CV[change_value / change_value_salt]
    end

    subgraph public["public入力（公開）"]
        BR[beacon_block_root]
        NF[nullifier]
        PR[privacy_pool_root]
        WV[withdraw_value]
        CH[change_value_hash]
    end

    S -->|"sha256(MAGIC_NULLIFIER + secret)"| NF
    CV -->|"sha256(salt, value)"| CH
    DV -->|"deposit - change"| WV
    MI -->|マークル検証| BR
    PI -->|マークル検証| PR

private入力からpublic入力が正しく導出されていることをゼロ知識証明で検証します。 検証者はpublic入力のみを確認し、private入力の中身は知ることができません。

検証条件

証明は以下のすべての条件を検証する必要があります。

以下の図は、検証条件の全体像を示しています。

flowchart TD
    A[Wormholeトランザクション受信] --> B{入金がビーコンチェーンに<br/>存在するか？}
    B -->|No| X[拒否]
    B -->|Yes| C{入金がプライバシープールに<br/>含まれるか？}
    C -->|No| X
    C -->|Yes| D{ナリファイアが<br/>正しいか？}
    D -->|No| X
    D -->|Yes| E{PoW条件を<br/>満たすか？}
    E -->|No| X
    E -->|Yes| F{お釣り額のハッシュが<br/>正しいか？}
    F -->|No| X
    F -->|Yes| G{お釣り額 + 出金額<br/>= 入金額か？}
    G -->|No| X
    G -->|Yes| H{入金額が<br/>32 ETH以下か？}
    H -->|No| X
    H -->|Yes| I[ZK証明の検証通過]
    I --> J{追加の検証}

ZK証明の検証を通過した後、さらにオンチェーンで以下の追加検証が行われます。

追加の検証

make_receipt_hash関数

この関数は、入金のレシートハッシュを生成します。 以下の図は、deposit_senderの値に応じた処理の分岐を示しています。

flowchart TD
    A[make_receipt_hash呼び出し] --> B{deposit_sender != 0 ?}
    B -->|Yes: 通常入金| C[secretから送金先アドレスを導出]
    C --> D[EIP7708のETH転送ログ形式で<br/>topics と logdata を設定]
    B -->|No: お釣り入金| E[お釣り額のハッシュを計算]
    E --> F[MAGIC_CHANGE をtopicに設定<br/>logdata は空]
    D --> G[SSZルートハッシュを返す]
    F --> G

通常の入金では、secretから誰もアクセスできないアドレスを導出し、EIP7708のETH転送ログ形式でハッシュを生成します。 お釣り入金では、MAGIC_CHANGEをトピックに設定し、お釣り額のハッシュ値のみを記録します。

トランザクション実行

トランザクションが確認された場合、以下の処理が実行されます。

sequenceDiagram
    participant TX as Wormholeトランザクション
    participant WN as WORMHOLE_NULLIFIER_ADDRESS
    participant TO as 送金先アドレス

    TX->>WN: 1. withdraw_value分のETHを生成
    TX->>WN: 2. ナリファイアを記録<br/>SSTORE(nullifier, 1)
    WN->>TO: 3. 生成したETHで通常のコールを実行
    TX->>TX: 4. お釣りのログイベントを発行<br/>topics=[MAGIC_CHANGE, change_value_hash]

1. WORMHOLE_NULLIFIER_ADDRESSにproof.withdraw_value分のETHを生成
2. コールの前にSSTORE(WORMHOLE_NULLIFIER_ADDRESS, proof.nullifier, 1)を設定し、同じナリファイアの再使用を防止
3. その値を使用してこのアドレスから送金先への通常のコールを実行
4. topics = [MAGIC_CHANGE, proof.change_value_hash]、logdata = bytes([])のログイベントを発行

補足

アドレスの使用可能性

楕円曲線ベースのデジタル署名では、通常、秘密の値 $s$（秘密鍵）が存在し、そこから公開鍵が計算されます（基準点 $G$ との乗算: $s \times G$）。 EthereumのEOAアドレスは公開鍵のkeccakハッシュです。

ハッシュ関数の原像耐性（preimage resistance）により、$r$ がランダムな値の場合、$keccak(x)=r$ となる $x$ を見つけることはできません。

したがって、ランダムなEthereumアドレス $r$ に送られた資金は誰も引き出せませんが、他の人々は $r$ が本当にランダムで $s \times G$ の計算結果ではないことをどうやって確認できるでしょうか？

ランダムな値を生成する手段としてハッシュ関数があります。 アドレスが秘密の値 $s$ のハッシュと等しい場合、$keccak(x)=h(s)$ となる $x$ を見つけることは計算上不可能なため、そのアドレスからは誰も資金を引き出せないと結論付けられます。

入金と出金の仕組み

以下のフロー図は、入金から出金までのプロセスを示しています。

flowchart TD
    A[ユーザー] --> B[秘密を生成]
    B --> C[誰もアクセスできないアドレスを計算<br/>sha256 MAGIC_ADDRESS + secret の下位20バイト]
    C --> D[ETHを誰もアクセスできないアドレスに送信]
    D --> E[ゼロ知識証明を生成]
    E --> F[Wormholeトランザクションを送信]
    F --> G[証明の検証]
    G --> H[新しいアドレスにETHをミント]

入金は2つの場所から行われます。

入金全額を出金する必要はありません。 以下の図は、お釣り入金が発生する具体的な例を示しています。

flowchart LR
    A[元の入金<br/>20 ETH] --> B[Wormhole<br/>トランザクション]
    B --> C[出金<br/>12 ETH]
    B --> D[お釣り入金<br/>8 ETH<br/>値はハッシュ化]
    D --> E[次回の出金に<br/>使用可能]

20 ETHを入金して12 ETHのみを出金する場合、システムは8 ETHの新しいお釣り入金を作成します。 このお釣り入金の値はハッシュ化されるため、チェーンを見ている人は「お釣り入金値 + 出金値 = 元の入金値」を計算して元の入金を特定することができません。

プライバシープール機構

この提案にはプライバシープール機構が含まれており、入金のリストに対応するプライバシープールルートを提供する必要があります。 以下の図は、プライバシープールの検証の仕組みを示しています。

flowchart TD
    A[プライバシープール<br/>許可された入金のリスト] --> B[マークルツリーを構築]
    B --> C[プライバシープールルート]
    D[自分の入金] --> E{入金がプール内に<br/>存在するか？}
    C --> E
    E -->|Yes| F[ZK証明でプール内の<br/>入金であることを証明<br/>どの入金かは明かさない]
    E -->|No| G[出金不可]

自分の入金がそのリスト内の入金の1つであることを、どの入金かを明かさずに証明します。

プライバシープールの論文では、このメカニズムの価値と、ほぼすべての合法的なユーザーがそれを使用するエコシステムの利点について詳しく説明されています。

PoWと32 ETH制限

組み込みのProof of Workと32 ETH制限は、ハッシュ衝突攻撃を防ぎます。

攻撃者がこのような衝突を見つけた場合、ETHを2回引き出すことができます（ただし2回のみ）。 しかし、攻撃に必要な計算能力を持つ者にとっては、Bitcoinマイニングの方がはるかに収益性の高い機会です。

スケーラビリティへの影響

回路が単一の証明で複数のBurnの合計を同時に再ミントできる場合、店舗や中央集権型取引所（CEX）は誰もアクセスできないアドレスで支払いを受け取り、単一の証明（と複数のナリファイア）をブロックチェーンに保存することで、資金を単一のアドレスに集約できます。 これにより、ブロックチェーン上のトランザクション数が大幅に削減されます。

この提案をスケーラビリティソリューションとして使用する人々は、プロトコルのプライバシー保証も向上させます。

後方互換性

ミント機能を使用して生成されたETHは、元のETHと何ら変わりがないはずです。 ミントされたETHはガス代の支払いにも使用できる必要があります。

この提案はEIP7708と、レシートをSSZ形式に変更するEIPが必要です。 これにより、証明はログを検証する通常のSHA256マークル分岐のみを検証すればよく、VerkleやRLPなどの複雑なロジックを証明内で行う必要がなくなります。

セキュリティ

この提案の実装に欠陥がある場合、人々は無限の量のETHをミントする可能性があり、Ethereumの価格が崩壊します。

参考実装

ZK-SNARK実装要件

実装は以下の条件を満たす必要があります。

引用

https://ethereum-magicians.org/t/eip-7503-zero-knowledge-wormholes-private-proof-of-burn-ppob/15456

最後に

今回は「EIP7503によるゼロ知識ワームホールを使用したプライバシーソリューション」についてまとめてきました！ いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

Twitter @cardene777

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58