新しい歴史

EIP-7503: プライベート Ethereum トランザクションのためのゼロ知識ワームホール

に 2077 Research44m2024/12/16

長すぎる; 読むには

EIP-7503 は、Ethereum ネットワーク上のオンチェーン転送を非公開にするプロトコル層ソリューションです。EIP-7503 は、Tornado Cash などのアプリケーション層プライバシーソリューションとは異なり、より優れた否認可能性、検閲耐性、および Ethereum ユーザーに真のプライバシーを提供します。

featured image - EIP-7503: プライベート Ethereum トランザクションのためのゼロ知識ワームホール

EIP-7503: Zero-Knowledge Wormholes は、 Ethereum 上でプライバシーを保護しながら転送を行うためのメカニズムを導入する Ethereum Improvement Proposal (EIP) です。Tornado Cash などの暗号通貨ミキサーを含め、オンチェーン転送を非公開にする取り組みは数多く行われてきましたが、EIP-7503 は、Ethereum をデフォルトで非公開にするプロトコルレイヤーソリューションです。

これは重要な考慮事項です。Tornado Cash のようなアプリケーション層のプライバシーへのアプローチは「オプトイン」であり、多くの場合、ユーザーにマイナスの影響を与えます。プライバシー重視のアプリケーションは検閲の影響を受けやすく、たとえば、 2022 年に米国外国資産管理局 (OFAC) がプロトコルのコントラクトアドレスをブラックリストに登録して以来、多くのユーザー (特に米国市民) は Tornado Cash を操作できなくなっています。

OFAC の制裁にもかかわらず、Tornado Cash がまだ稼働しているのは、いくつかの理由によるものです。

Tornado Cashの資産混合機能を実装するコアコントラクトは不変であり、チェーン上に永久に保存されます。トルネードキャッシュウェブサイトがオフラインになった後、独立したプロジェクトが元のTornado Cash実装の契約コードを再利用して、次のような新しいバリアントを作成しました。トルネードキャッシュノヴァ。
トルネードキャッシュプロトコルは、ほとんど「管理不能」です。トルネードキャッシュの創設チームは、緊急アップグレードの実行攻撃者が偽造預金の有効な証明を作成し、（合法的に預金された）資金を流出させる可能性のあるバグを修正するために、創設チームは、一方的にキルスイッチをアクティブにして、彼らの意志にもかかわらずプロトコルを「オフにする」ように圧力をかけることはできませんでした。 2023年に逮捕。

前述の要因は、分析によりイーサリアムのブロックプロデューサーがプロトコルの契約とやり取りするトランザクションをドロップしていることが示唆されているとしても、人々が今日でもTornado Cashを使用できることを意味します。ただし、OFACの制裁を受ける前の日々と同様に、Tornado Cashミキサープロトコルを経由したすべてのトランザクションが正当であったわけではありません。たとえば、 Arkham Intelligenceの記事によると、2023年の少なくとも2つの注目を集めた攻撃（Euler Financeの1億9,700万ドルのエクスプロイトとAnubis DAOの6,000万ドルのラグプル）は、Tornado Cashから引き出された資金で賄われていたか、ミキサーを使用して盗まれた資金をロンダリングし、送金を隠蔽していたことが示唆されています。

Tornado Cash は、悪意のある人物がオンチェーンのプライバシーを悪用する問題を解決していないのに、なぜプロトコルレベルでプライベート転送を実行する機能を実装する必要があるのでしょうか。それは危険ではないのでしょうか。そもそも、なぜプライベートトランザクションが必要なのでしょうか。Ethereum などのブロックチェーンは、すでに匿名で「追跡不可能」ではないのでしょうか。

これらはすべて正当な疑問であり、この記事ではそれらすべてについて説明します。金融プライバシーの重要性について概要を説明し、Ethereum のようなパブリックブロックチェーンが変更を加えずにプライバシーを保証できない理由を探ります。次に、Ethereum でプライベート支払いを可能にする EIP-7503 のアプローチを分析し、EIP-7503 を採用することの潜在的な利点と欠点について説明します。

さあ、始めましょう！

舞台設定: オンチェーンのプライバシーをなぜ気にする必要があるのでしょうか?

電子ピアツーピア（P2P）決済の文脈で「プライベートトランザクション」または「匿名トランザクション」について話すとき、追跡不可能性とリンク不可能性の2つの特性について説明しています。この2つの特性は、Nicolas van Saberhagen氏がCryptoNoteのホワイトペーパーで説明しています。

追跡不可能: 送信者が外部の観察者によって確実に識別できない場合、トランザクションは追跡不可能です。アリスがボブとキャロルと友達で、アリスが転送によって 2 つのトークンを受け取ったとします。追跡不可能とは、アリスにトークンを送信したのが誰 (ボブまたはキャロル) か誰もわからないことを意味します。
リンク不可: 受信者が外部の観察者によって確実に識別できない場合、トランザクションはリンク不可です。ボブとキャロルが別々のトランザクションでアリスにトークンを送信した場合、リンク不可とは、ボブとキャロルが同じ人物にトークンを送信したかどうかを誰も知ることができないことを意味します。

ほとんど（すべてではないにしても）のオンチェーンプライバシーソリューションは、前述の要件のどれを満たすかに基づいて分類できます。暗号通貨ミキサー、 CoinJoin 、リング署名は、主に送信アドレスに関する情報を隠し、資金を追跡不可能にすることに取り組んでいます。送信者の身元はさまざまなメカニズムを使用して保護されますが、資金を受け取った人は誰でも確認できます。

比較すると、 Monero 、 Zcash 、 Liquid Network 、 Aztec v1などのプライバシー重視のプロトコルは、「シールド」または「機密」トランザクションのバリエーションを提供し、トランザクションのリンク不可性を保証します。シールドまたは機密トランザクションは、受信者のアドレスの詳細 (および転送されたトークンの量とタイプ) が秘密にされているため、特定の受信者にリンクすることが困難です。ステルスアドレスは、リンク不可性を維持するための別のアプローチです。ユーザーはデポジットに対して一時的な (短命の) アドレスを生成し、2 つの転送を同じアドレスにリンクしようとする試みをブロックします。

トランザクションのプライバシーを向上させる前述のアプローチには、それぞれ独自の長所と短所がありますが、これについては後ほど簡単に説明します。しかし、今は、根本的な疑問、「金融プライバシーはなぜ重要なのか」に注目したいと思います。私たちは、プライベートで匿名のトランザクションを Ethereum に導入するという提案を分析するために時間と労力を費やしているので、Ethereum でトランザクションのプライバシーを有効にする根拠についても説明しておくべきでしょう。

金融プライバシーは、プライバシーが基本的人権であるため重要です。プライバシーの権利は、すべての個人に、公開したい情報を決定する権限と、個人を特定できる情報 (PII) の共有方法、時期、場所を管理する権限を与えます。「個人を特定できる情報」は、個人の身元を明らかにするために使用できるあらゆる情報 (金融活動の詳細 (購入履歴、電子送金、収益など) を含む) を含む広範なカテゴリです。

以下は、個人が（金融）プライバシーの権利を行使する方法の例です。

来年の感謝祭で人員を増やさない理由を家族に聞かれることなく、オンラインで避妊薬を購入する。銀行がオンライン取引に関する情報を公開し、ベスおばあちゃんがシェリルが孫を奪っていることを知ったとしたら、どんなに気まずいことになるでしょうか。
寄付額の詳細や寄付の有無を明かさずに慈善団体に寄付すること。これは、特定の界隈で眉をひそめられるような慈善活動に寄付する場合、またはパフォーマンスをして慈善活動に（不必要な）注目を集めたくない場合に重要です。
公に関わりたくない政治活動に寄付すること。例えば、ロシア出身のヴィタリック・ブテリンは、ロシアの侵攻と戦うウクライナ軍に寄付したが、ヴィタリックの国籍を考えると、公に寄付をするとおそらく不必要なPR危機を引き起こしただろうため、代わりにトルネード・キャッシュを通じて資金が送られた。
悪意のある人物に財務状況の詳細を明かすことなく支払いを行います。昨年の総収入が X ドルだったことを誰かに知られたくないでしょう。そのことが、お金を盗む計画を立てるのに十分な情報を与えてしまうからです (例: 詐欺やその他のソーシャルエンジニアリングの戦術を使用)。
従業員の収入に関する情報を公開せずに従業員に支払いを行う。会社の財務活動の詳細を非公開にしておきたい場合や、従業員がその情報を非公開にしておきたい場合があります。

これらの例は金融プライバシーの実際的な使用例を示していますが、プライバシー権の批判者がしばしば認めない詳細も浮き彫りにしています。つまり、プライバシーは手遅れになるまで必要だと思わないものであるということです。よくある「何を隠しているのですか?」という反論は、金融取引に関する情報をほとんど、あるいはまったく漏らしたくない関係者がいる特定の状況を認識していません。また、たとえ人々が恣意的な理由で物事を隠したいとしても、その秘密保持の欲求が公衆衛生と安全を危険にさらさない限り、なぜ彼らを煩わせるのでしょうか?

必要としているのに持っていないより、必要としていないのに持っているほうがよい。 ― フランツ・カフカ

EIP-7503 で Ethereum のプライバシー問題を解決する

支持者や批評家による初期の説明とは反対に、イーサリアムやビットコインなどのパブリックブロックチェーンは匿名性やプライベート性からは程遠いものです。これら 2 つの用語は混同されることが多いですが、それぞれ異なる意味を持っています。

プライバシーとは、秘密の行動は公開された身元に追跡可能だが、行動の詳細は隠されていることを意味します。PGP ( Pretty Good Privacy ) ツールを使用して暗号化されたメールを送信するとします。メールサーバーは、メールが別の (識別可能な) 相手に送信されたことを認識しますが、メールの内容を読むことはできません。受信者以外は誰もメールを送信したことがわからないため、これは秘密の行動です。
匿名性とは、公開アクションが公開 ID から切り離されていることを意味します。前の例を使用すると、仮想のピアツーピア匿名メールサービスは、暗号化されたメールの送信元と送信先を難読化しながら、ネットワークを介してルーティングされるすべてのメールの公開記録を維持することができます。これは、誰かがメールを送信した記録がネットワーク上のすべての参加者に見えるため、公開アクションですが、メールアドレスはハッシュ文字列 ( 0xdeadbeef ) であり、名前 ( [email protected] ) ではありません。

イーサリアムはプライベートではありません。なぜなら、ブロックチェーンは各トランザクションの記録を保持しており、転送された金額やトランザクションが実行したオンチェーンアクションなどが記録されているからです。また、ブロックチェーン上で取引するアカウントの情報（アドレスで識別）が公開されているため、イーサリアムは匿名でもありません。イーサリアムのアカウントに「アリス・ホプキンス」のような実名を使用することはできませんが、すべてのトランザクションに同じアドレスを使用すると、ブロックチェーンフォレンジックが、 IPアドレス監視、アドレスクラスタリング、グラフ分析などの技術を使用して、トランザクションを現実世界のIDと関連付けることができます。

したがって、イーサリアムは正確には仮名性があり、匿名性やプライバシーを保証することはできません。これは、将来の価値のインターネットの決済レイヤーになることが期待されているプラットフォームにとっては良くありません。背景として、銀行はすでに、不正アクセスを防ぐために厳格なアクセス制御メカニズムを備えた集中データベースに金融データを保存することで、ユーザーに一定レベルのプライバシーを提供しています。

これは「疑似プライバシー」です。銀行とデータベースインフラストラクチャプロバイダーは、この情報にアクセスでき、それを使って何でもできるからです (たとえば、送金先の分析に基づいて制裁に従うために特定の国への支払いを凍結するなど)。しかし、「悪魔と深い海の間で選択する」という典型的なケースでは、平均的な個人は、プライバシーがまったくないよりも、ある程度のプライバシーを選択する可能性が高く、Ethereum アカウントを開設して、すべてのオンチェーンアクションを世界に公開することは不可能になります。

多くの人がこの問題を認識しています。特に、この問題が、ユーザーをイーサリアムのような分散型テクノロジーから、検閲や透明性への耐性を犠牲にしてわずかに優れたプライバシー保証を提供する集中型ソリューションへと移行させているためです。たとえば、Vitalik のThe Three Transitions は、イーサリアムの大量採用の見通しに対するプライバシーの重要性について優れた議論を提供しています。

3 つ目の [プライバシー保護転送への移行] がなければ、イーサリアムは失敗します。なぜなら、すべてのトランザクション (および POAP など) を公開して文字通り誰でも見ることができるようにすることは、多くのユーザーにとってプライバシーを犠牲にしすぎるため、誰もが少なくともある程度はデータを隠す集中型ソリューションに移行するからです。 — Vitalik Buterin

EIP-7503 は、前述の問題の一部、特にトランザクション送信者の匿名性の欠如を改善するための取り組みです。この提案では、アドレスが資金を使用不可のアドレスに送信することで Ether (ETH) を意図的に破壊し、使用不可のアドレスへの入金を認証するための ZK-SNARK 証明を生成する手段が導入されています。この証明が検証に合格すると、一定量の ETH トークン (使用不可のアドレスの残高に等しい) がユーザーが選択した新しいアドレスに発行され、資金の転送に関与する送信アドレスと受信アドレス間のリンクが切断されます。

EIP-7503 は、既存のプライバシープロトコルからアイデアを借用して、Ethereum 上でプライバシー保護トランザクションを強化します。たとえば、この提案では、ETH 残高があり、送信トランザクションがゼロである Ethereum アドレスのセット全体を匿名セットに変換することで、ミントトランザクションで受け取った資金を特定のソースに追跡することを困難にします。アドレスB が次のトランザクションで再ミントした ETH をバーンしたアドレスAを簡単に特定することはできません。アドレスAは、残高がゼロではないが、Ethereum トランザクションを開始していない何百万ものアドレスの 1 つである可能性があります。

これは、さまざまなソースからの資金を 1 つのプールに混ぜて、預金者が別のアドレスを使用してプールから資金を引き出せるようにするというアイデアに似ています。ただし、EIP-7503 は、もっともらしい否認可能性を提供するため、Tornado Cash などの暗号通貨ミキサーよりも優れています。もっともらしい否認可能性は後で説明する概念ですが、現時点で知っておく必要があるのは、(EIP-7503 プライベート転送を実行するユーザーが) プライベートトランザクションを実行したことを否定できることだけです。

もっともらしい否認可能性は、EIP-7503 の重要な機能であり、外部の観察者がプライベートトランザクションの送信者の匿名性を解除するのを防ぎます。これにより、オンチェーンフォレンジックによって Tornado Cash との過去のやり取りが明らかになったために特定のアドレスがブラックリストに登録され、dapp、取引所、DeFi プロトコルへのアクセスが制限された Tornado Cash の大失敗の繰り返しを防ぐことができます。たとえ、それらのアカウントの一部が無害な理由 (たとえば、個人的な寄付を行うなど) で Tornado Cash とやり取りしていたとしてもです。

EIP-7503 は、暗号化証明を使用してトランザクションの詳細を公開せずにトランザクションを検証することで、Zcash や Aztec v1 などの他のプライバシー中心のプロトコルからも借用しています。プライバシーを保護する方法でトランザクションを検証することで、各トランザクションを再実行して正確性を確認するノードの分散ネットワークに依存する既存のセキュリティモデルを損なうことなく、Ethereum が安全にプライベート転送をサポートできるようになります。以降のセクションでは、EIP-7503 が内部で ZK-SNARK を使用して Ethereum でのプライベート転送の安全な実行をサポートする方法について詳しく説明します (他の項目も含みます)。

注意*: プライバシーと匿名性は区別されていますが、この記事では「プライベート」と「匿名」を同じ意味で使用して、2 つの概念を同じものとして考えてきた読者の混乱を避け、内容を簡潔にします。さらに、EIP-7503 には、匿名性 (送信者と受信者のリンクを切断) とプライバシー (現在の提案に対する提案された拡張により、ユーザーは入出金金額を隠すことができます) の要素が含まれています。*

EIP-7503: ゼロ知識ワームホールの概要

大まかに言えば、EIP-7503 は次のように動作します。

1. ユーザーは、残高が使えないアドレスにETHを送信することでETHを「燃やす」

残高から支出する（有効な）トランザクションに署名するために必要な秘密鍵に誰もアクセスできない場合、アドレスは支出不可となります。これは、ゼロアドレスに資金を送信する場合と同様です。アカウントには秘密鍵がないため、受け取った資産は取り消し不能、つまり「焼却」されます。

ゼロアドレスは、2 億 8,000 万ドル以上のトークンを保有する、イーサリアムで最も裕福なアカウントです。ゼロアドレスに誤って資金を送金する不運なユーザーを除けば、ゼロアドレスにトークンを送信するユーザーの大多数は、契約を作成するか (ゼロアドレスを受信者として設定する必要があります)、意図的にそれらのトークンを流通から外しています。

オリジナルのERC-20 トークン標準では、トークンの供給量を減らすための関数は指定されていません。つまり、WETH (ラップされた Ether) などの古いトークンでは、ユーザーが元の預金を引き出す前にラップされた資産を流通から外すようにする方法がありません。ただし、WETH トークンをゼロアドレスに送信すると、使用できなくなり、WETH ラッパーコントラクトから ETH が引き出されるたびに、WETH の流通供給量が減少するのをシミュレートします。WETH がネイティブ ETH と 1:1 の比率を維持する方法がわからない場合は、これが答えです。

EIP-7503 は、同様のメカニズムを使用して、ユーザーが ETH をバーンし、少し工夫して Ethereum 上の別のアドレスにトークンを発行できるようにします。EIP-7503 では、ユーザーに単一のバーンアドレスに資金を送信するよう求めるのではなく、別のアドレスに ETH を発行する前に、すべてのトランザクションに対して一意のバーンアドレスを生成することをユーザーに要求します。

2. ユーザーは、以前の取引で一定量のETHをバーンしたことを証明するプライベートなバーン証明または「バーンレシート」を作成し、バーンアドレスに送信します。

バーンアドレス (EIP-7503 仕様に従って作成) に資金を送信することは、ワームホールに現金を投げ込むのと同じであり、決して取り戻すことはできません。ただし、ZK-SNARK (ゼロ知識の簡潔な議論) を使用して、ワームホールに送信されたものに関する知識を証明することができます。そのため、「ゼロ知識ワームホール」と呼ばれます。

プルーフ・オブ・バーンは非公開です。なぜなら、ユーザーはトークンを使用不可のアドレスAに送信したことを証明するだけでよく、 Aをプレーンテキストで公開する必要がないからです。プルーフ・オブ・バーンを生成するには、バーンアドレスが実際に使用不可であることを証明する必要があります。なぜでしょうか? ユーザーに、受信者アドレスに新しい ETH トークンを発行する前にネイティブ ETH をバーンするよう求めることで、両方の種類の資産のパリティ (価値と代替可能性) が確保されます。ユーザーが後でバーンアドレスから資金を引き出すことができる場合、ネイティブ ETH と発行された ETH トークン間の 1:1 ペグは存在しなくなります。

3. ユーザーは、フルノードにプライベートのプルーフオブバーンを提出することでETHトークンを発行し、バーンアドレスに転送されたデポジットに相当する金額をユーザーにクレジットします。

EIP-7503 は、EVM (Ethereum Virtual Machine) に新しいトランザクションタイプを導入します。このトランザクションタイプは、プルーフオブバーンと受信者を入力として受け入れ、プルーフが正常に検証された場合に送信元アドレスに新しい ETH トークンを発行します。同じバーントランザクションで ETH が 2 回発行されるのを防ぐため、アドレスの使用状況を追跡するために、すべてのプルーフオブバーンに特別な「nullifier」値が付加されます。

使用不可のアドレスに送信された ETH が正常に再発行された場合、無効化機能は、不正なユーザーがそのアドレスに以前送信された資金に対して新しい有効なプルーフオブバーンを生成すること (つまり、二重発行攻撃) を防止します。重要なのは、無効化機能は、使用済みのアドレスを、そのアドレスに関する情報をプレーンテキストで漏らすことなく識別することです。

この概要の説明で、EIP-7503 の実装の低レベルの詳細に進むことができます。次のセクションでは、次のような EIP-7503 の実装の重要な詳細について説明します。

使用不可アドレスの生成
プライベートな焼却証明の生成
プライベートな焼却証明の検証
プライベート送金の受取人のためのETHの発行

使用不可アドレスの生成

通常の Ethereum アドレスは、アカウントの秘密鍵から生成された公開鍵の Keccak256 ハッシュの最初の 20 バイトです (秘密鍵は、ニーモニックまたはシードフレーズから生成された整数です)。秘密鍵と公開鍵は両方とも、楕円曲線デジタル署名アルゴリズム(ECDSA) を使用して生成されます。ECDSA は複雑なトピックです (「複雑」は「数学がたくさんある」という意味の婉曲表現です)。ここでは、初心者からエキスパートまでランク付けされたリソースをいくつか紹介します。

楕円曲線暗号の（比較的わかりやすい）入門(Cloudflare ブログ)
楕円曲線デジタル署名アルゴリズム（ウィキペディア）
楕円曲線デジタル署名アルゴリズム(ビットコインウィキ)
ECDSA: 楕円曲線署名(開発者のための実践的な暗号化)

公開鍵は、秘密鍵 (シークレットまたは略してsと呼ばれる) に特別な「ジェネレータ」値Gを掛けてpubKey = privKey * G形式の新しい値を生成することによって生成されます。アドレスは、公開鍵を Keccak256 ハッシュ関数に通してハッシュ文字列の最初の 20 バイトを取得することによって生成されます。疑似数学表記では、この操作はA = K(s * G)のようになります。ここで、 Aはアドレス、 sはシークレットまたは秘密鍵、 Gは楕円曲線上のジェネレータポイントです。

アドレス、公開鍵、秘密鍵はそれぞれまったく異なる目的で使用されます。

アドレスは公開され、取引で送金される資金を受け取るアカウントを識別します。
秘密鍵は、アドレスの残高からトークンを転送するようにネットワークに指示するメッセージに署名するために使用され、秘密にしておく必要があります。
公開鍵を使用すると、トランザクションの署名が対応する秘密鍵によって生成されたことを確認できます。

リストの最後の項目は、微妙な詳細を示しています。アドレスに送信された資金を使うことができるのは、秘密鍵を管理している場合のみです。つまり、アドレスの元となった公開鍵を生成するために使用された秘密鍵を知っている必要があります。アドレスの秘密鍵を知らない場合、または秘密鍵が他の誰かによって管理されている場合は、そのアドレスから資金を使うことはできません。

アドレスAの残高が使用不可かどうかはどうすればわかるのでしょうか。まず、 Aの 20 バイトの値をランダムに選択し、暗号ハッシュ関数の特殊な特性である原像抵抗を利用します。簡単に言えば、原像抵抗とは、 Aがランダムに選択された場合にH(x) ( xのハッシュ) がAと同じになるような値x見つからないことを意味します。疑似数学的表記では、この主張はH(x) ≠ Aという形式になります。

Aハッシュのイメージ(ハッシュ関数の出力) であり、 xハッシュ関数の原イメージ (ハッシュ関数への入力) です。H H(x) = Aのxの値を見つけることは、(a) 可能な整数の数が非常に多いこと、(b) ハッシュ関数が入力を操作して出力を生成する方法により困難です。したがって、 Aになるxの値を「推測」できる唯一の方法は、膨大な計算能力と、 H(x) = A見つけるために膨大な数の計算を実行するのに十分な時間がある場合です。

これは暗号化入門クラスではありませんが、これまでの説明は現代の暗号化システムの重要な特性を捉えています。ハッシュ関数の原像耐性特性は、EIP-7503 でも重要な役割を果たします。つまり、 Aがランダムな 20 バイトの値である場合、ユーザーは秘密鍵を導出できず、s にはアドレスから資金を使う方法がないと確信できます。つまり、 A = H(h(s * G)を計算することは不可能です。ここで、 Aはバーンアドレス、 sは秘密鍵またはシークレット、 Gはジェネレータポイントです (小さな注意: k(s * G)は前の段落のxに相当します)。

しかし、この戦略は完全に確実というわけではありません。たとえば、 Aが本当にランダムであり、 s * Gの計算結果ではないことをどうやって判断できるでしょうか。ユーザーがA独立して選択している場合、ユーザーを信頼するか、 Aがランダムに選択されたことを確認するための複雑な手順を構築する必要があります。 Aを選択する場合、ユーザーを信頼する必要はありませんが、誰かが運よくx正しく推測する可能性は無視できません。 x = s * Gなので、この知識により、ユーザーは秘密鍵s導出し、使用できないはずのアドレスから使用できるようになります。

これは明らかに最適とは言えず、使用不可アドレスを生成するためのより安全なメカニズムが必要であることを浮き彫りにしています。幸いにも、暗号ハッシュ関数には、衝突耐性という、利用できる別の特性があります。簡単に言えば、衝突耐性とは、 xとy異なる入力である場合にH(x) = H(y)が見つからないことを意味します。つまり、異なる入力値のハッシュの計算が「衝突」して同じ結果が生成されないということです。

衝突耐性は、偽造を防止するために重要です (他の目的の中でも)。2 人が 2 つの異なる入力をハッシュすると、ハッシュ文字列は常に異なり、一方が他方だけが知っている入力を所有していると主張することはできません。衝突耐性の別のバージョンは、 H1(x) = H2(x)を見つけることができないことです。ここで、 H1とH2は異なるハッシュ関数ファミリーに属します。言い換えると、異なるハッシュアルゴリズムを使用してxのハッシュを計算しても、「衝突」して同じ出力に到達することはありません。

なぜこれが可能なのかを理解するために、次にハッシュ関数がどのように機能するかを説明する架空の例を作成します。

幕間: 初心者のための暗号ハッシュ関数

ここでは、暗号ハッシュ関数がどのように機能し、衝突耐性やプリイメージ攻撃耐性などの重要な特性がどのように保証されるかを説明するために、架空の例を使用します。ただし、この説明では、簡潔さとわかりやすさのために、特定の概念を過度に単純化しています (暗号学者を目指す場合は、ハッシュ関数に関する論文を読んでください)。

アリス、ボブ、シェリル、マックスはライバル政党に属しています。アリスとボブは青党のメンバーで、シェリルとマックスは赤党のメンバーです。青党の支持者と赤党の支持者は、ライバル党のメンバーに機密情報を漏らすことなく、自分たちの間で情報を共有したいと考えており、メッセージを暗号化するためのさまざまなコードを独自に考案しています。

ブルーパーティーのコードはダブルレターアルゴリズムとして知られていますが、レッドパーティーはトリプルレターアルゴリズムと呼ばれる変種を使用しています。コードは非常に単純です。メッセージを書くときにアルファベットを数字に置き換えます。メッセージ文字列内の各数字は、アルファベットの特定の位置にある文字を指します。「暗号化」ビットは、アルファベットを表す数字を選択する方法から来ています。

ブルーパーティーの「ダブルレター」コードでは、各数字を 2 で割り、その結果の数字 (n) を使用してアルファベットの n 番目の位置にある文字を見つけます。たとえば、「BOY」は4-30-50として暗号化できます。4/2 = 2 (「B」はアルファベットの 2 番目の文字)、30/2 = 15 (「O」はアルファベットの 15 番目の文字)、50/2 は 25 (「Y」はアルファベットの 25 番目の文字) です。
レッドパーティーの「トリプルレター」コードでは、各数字を 3 で割り、その結果の数字 (n) を使用してアルファベットの n 番目の位置にある文字を見つけます。たとえば、「BOY」は6-45-=75と暗号化できます。6/3 = 2 (「B」はアルファベットの 2 番目の文字)、45/3 = 15 (「O」はアルファベットの 15 番目の文字)、75/3 = 25 (「Y」はアルファベットの 25 番目の文字)。

この例では同じメッセージに暗号化を使用していますが、実際には青党と赤党の人々が別のメッセージを交換することが予想されます (例: 「マックスは嫌な奴だ」(アリス → ボブ) と「青党のメンバーは負け犬だ」(シェリル → マックス) など)。それでも、同じメッセージを異なるコードで暗号化することは、暗号ハッシュ関数の衝突耐性を説明するのに役立ちます。

「BOY」を青党の「ダブルレター」アルゴリズムと赤党の「トリプルレター」アルゴリズムを使用して暗号化すると、結果は非常に異なります（それぞれ4-30-50と6-45-75 ）。青党のメンバーは、赤党の暗号化アルゴリズムを使用しない限り、 6-45-75生成することはできません。また、赤党のメンバーは、青党の暗号化アルゴリズムを使用しない限り、メッセージ文字列として4-30-50生成することはできません。各党は暗号化アルゴリズムの詳細を守っているため、ライバル党のメンバーは、自分宛てではないメッセージを解読できないことがわかります。

暗号ハッシュ関数は暗号化アルゴリズムとは異なります。ハッシュ関数は一方向であり、出力から入力を導き出す方法がありませんが、例のような暗号化アルゴリズムには暗号化関数への入力を復号化するためのキーがあります。ただし、ハッシュ関数と暗号化アルゴリズムには、特に衝突耐性の領域で類似点があります。異なる暗号化アルゴリズムを使用して単一の入力に対して同じ出力 (暗号化されたメッセージ) を見つけることができなかったのと同様に、異なるハッシュ関数を使用して単一の入力に対して同じ出力 (ハッシュ) を見つけることはできません。

ハッシュ関数の衝突耐性を利用して、EIP-7503 で要求されているように、資産をバーンするための証明可能な未使用アドレスを生成できます。まず、ユーザーに秘密値s (Ethereum アカウントの秘密鍵) を選択してもらい、 s * Gの Keccak256 ハッシュを計算して公開鍵を導出し、公開鍵をハッシュしてアドレスAを導出します。次に、秘密値s をHで示される別のハッシュ関数でハッシュし、出力の最初の 20 バイトをアドレスとして取得して、新しいアドレスB を生成するようにユーザーに依頼します。

私たちの目標は、最終的にK(x) ≠ H(x)となることです。ここで、 K はKeccak256 ハッシュ関数を表し、 H は別のハッシュ関数ファミリーのハッシュ関数を表します。パフォーマンス上の理由から、 H は「ZK フレンドリー」である必要があります (つまり、回路内でH(x)の結果を確認するのが安価で高速である必要があります)。

アドレスはs * G (秘密鍵×ジェネレータ) の Keccak256 ハッシュを計算する代わりにランダムに生成されたため、 Bの公開鍵を知ることはできません。つまり、 Bの秘密鍵も知ることはできません。 Bの秘密鍵がわからない場合、 Bの残高を使用するメッセージに有効な署名を生成することはできません。使用不可のアドレスを生成するための証明可能なランダムなプロセスにより、ユーザーは資産を再発行する前に ETH をバーンできるようになりました。

プライベートプルーフオブバーンの生成

特定のユーザーが ETH を使用不可のアドレスに送信し、その使用不可のアドレスがそのユーザーによって作成されたことをどのように証明するのでしょうか。最初のチェックは、ETH の不正な鋳造を防ぐために必要です (ユーザーが以前に ETH をバーンしたという証拠がない限り、新しい ETH トークンは鋳造されません)。ただし、2 番目のチェックも重要です。アドレスがユーザーによって作成されたことを知る必要があります。そうでない場合、ユーザーが他の人の預金を請求しようとしていないことを確認するための情報 (バーントランザクションのハッシュなど) が必要になります。

プライバシープロトコルへのユーザーの参加に関する情報が漏洩することを避けたいため、代わりにユーザーがs (バーンアドレスを導出するためにハッシュされた秘密の値) を知っていることを証明するゼロ知識証明を、 s を公開せずに作成できるようにします。ゼロ知識証明はH(s)の結果から導出されたアドレスBに関するユーザーの知識を主張します。sは秘密裏に選択されたため、他の人はH(s) = H(s)となる異なる値H(x)を計算することはできません。これは、前述のハッシュ関数の衝突耐性特性によるものです。

s を隠すことで、悪意のある人物が EIP-7503 検証者に秘密s (使用不可アドレスの生成に使用) を知っていることを確認する証明を送信して、ユーザーのデポジットを償還するのを防ぐことができます。このセクションでは、検証者がH(s)個別に計算する必要なく、H H(s) = A証明するゼロ知識証明を作成できる理由について簡単に説明します。ただし、入力を明らかにせずに計算の有効性を証明するために ZK-SNARK を使用する背景については、Vitalik のQuadratic Arithmetic Programs: Zero To Heroと私の ZK-EVM に関する記事をお読みください。

使用不可アドレス（バーンアドレスとも呼ばれる）へのユーザーの資金の送金を検証するゼロ知識証明を「プルーフ・オブ・バーン」または「バーンレシート」と呼びます。プルーフ・オブ・バーンは、以下のことを証明します。

ユーザーは、アドレスAと、 Aを導出するためにハッシュされた秘密の値s を知っています (つまり、 H(s) = A )。これは、 Aが、使用可能な Ethereum アドレスを生成するために使用される Keccak256 ハッシュ関数とは異なる (ZK 対応の) ハッシュ関数でs をハッシュした結果であることを確認することで、アドレスが使用不可であることを確認します。
アドレスAの ETH 残高はb以上 ( b ≥ b' ) です。これは、ユーザーが受信アドレスに発行しようとしている金額が、使用不可アドレスに預け入れられている金額と同じであるかどうかをチェックしています。

1 番を証明するのは比較的簡単ですが、2 番を証明するには、イーサリアムの状態について特定のことを主張する必要があります。具体的には、(a) 使用不可アドレスが標準的なイーサリアム状態トライに存在すること、および (b) 使用不可アドレスの要求された残高が状態トライ内のアドレスに関連付けられた残高と一致することを証明する必要があります。これには、バーン証明を生成する回路への入力として、アドレスAのMerkle 証明を渡す必要があります。

Merkle 証明は、証明しようとしているリーフ (アドレスA ) から Merkle トライのルート (トライのルートも Merkle 証明の一部) までのパスを計算するために必要な Merkle Patricia Trie (MPT) のリーフで構成されます。Merkle 証明の検証に使用される状態ルートも標準的であるという証拠が必要なため、ユーザーは回路への追加入力としてブロックヘッダーBを渡す必要があります。この情報セットにより、リソースが制限された検証者は、状態トライにアドレスAが含まれていることを効率的に検証し、 Aのバランスb を検証できます。

注*: EIP-7503 仕様では、バーンアドレスが状態トライに含まれていることを証明するために必要な Merkle 証明を導出し、EIP-1186 で導入されたeth_getProof JSON-RPC メソッドを使用してアドレスの残高を検証することが推奨されています。

アドレスのヌル文字の生成

使用不可アドレスへの預託証明を生成する ZK-SNARK 回路へのもう 1 つの入力は、ヌルファイアです。ヌルファイアは、ユーザーが同じプルーフオブバーンを使用して ETH を2 回発行することを防ぐ値です。ヌルファイアがなければ、賢いユーザーがプルーフオブバーンを再利用して ETH を複数回引き出すことを止めるものは何もありません。EIP-7503 プライベート転送を処理するノードの観点からは、使用不可アドレスの残高が減ることはなく (増えることしかできないため)、これらの引き出しは有効です。

ヌルファイアは ZK-SNARK 証明回路への入力として渡されるため、検証に成功するとプルーフオブバーンは無効になります。この特性は、証明から (使用された) ヌルファイアを抽出し、それをスパースマークルツリー(SMT) に格納することで実現します。要素の包含を効率的に証明できる通常のマークルツリーとは異なり、スパースマークルツリーは要素の非包含を証明するのに効率的です。SMT に関する議論は範囲外ですが、前述のリンク先の記事は、興味のある読者にとって優れた概要を提供します。

この場合、SMT が便利です。ZK-SNARK 検証手順では、SMT が新しく送信された証明に添付されたヌルファイアを除外しているかどうかを確認するだけでよいためです。スパースマークルツリーにヌルファイアが存在しない場合は、ユーザーが以前にこのプルーフオブバーンを使用しておらず、証明可能な新しいデポジットを引き出していることがわかります。使用されたヌルファイアを SMT に追加して、バーンアドレスを公開せずに ETH を再発行するために使用されたバーンアドレスを追跡します。

バーンアドレスを Merkle ツリーに保存し、新しい引き出しを処理するときに、新しいバーンプルーフのアドレスがツリーの一部ではないことを確認した場合はどうなるでしょうか。

プレーンなバーンアドレスをヌルファイアとして使用すると、外部の観察者がアドレスのトランザクション履歴をオンチェーンに保存されているバーンアドレスのリストと照合することで、バーントランザクションの送信者を潜在的に暴露する可能性があります。バーンアドレスが (必然的に) 送信者が開始したトランザクションの 1 つで受信者として表示されると、アカウントを管理している人が ETH をバーンして再発行したことを誰でも証明できます。

バーン（使用不可）アドレスのハッシュを使用すると、送金された資金を個人的に知ることは困難ですが、不可能ではありません。これには、ハッシュの 1 つが SMT に保存されているヌルファイアと一致するまで、現在存在するすべての Ethereum アドレスのハッシュを計算するブルートフォース攻撃が必要です。ヌルファイアハッシュの原像（つまり、使用不可アドレス）が見つかると、前述の手順を実行して、問題のヌルファイアアドレスに資金を送金したアカウントを追跡できます。

この問題は、ヌルファイアを生成するためのより安全なメカニズムを見つけることで解決できます。現在の EIP-7503 仕様で採用されている戦略は、同じ (ZK 対応) ハッシュ関数を使用して、バーンアドレスを秘密値sでハッシュすることにより、ヌルファイアN を生成することです。疑似数学表記では、これはN = H(A,s)のようになります。ここで、 Aは使用不可アドレス、 s はA を最初に生成した秘密値です。

この例では、秘密値sはソルトとして記述されています。このソルト値は、本質的に、ヌルファイアからバーンアドレスに関する情報を抽出することの難しさを増大させます。sが既知であれば、オブザーバーはブルートフォース攻撃を実行し、オンチェーンに保存されるヌルファイアNを生成するhash(burnaddress,secret)のすべての可能な組み合わせを実行できます。ただし、 sはユーザーによって秘密に保持されるため、使用されたヌルファイアに対応するバーンアドレスを見つける可能性は事実上排除されます。

プライベートな焼き付け証明の検証

プルーフ・オブ・バーンが証明しようとしているステートメントがわかったので、証明検証がどのように機能するかについて、ある程度の見当がつきました。最初のステートメント ( h(s) = A ) の場合、検証者はアドレスA を生成するために使用されたハッシュ関数のロジックを「理解」する必要があります。つまり、 H(s)実際にA に等しいことがわかります。検証回路でハッシュ関数のロジックをエンコードすると、 Keccak256 ハッシュ関数ではA を生成できないという要件も強制されます。

2 番目のステートメント ( Aには ETH の正の残高bがある) については、検証者は、 Aが Ethereum の状態に含まれていることを証明し、アカウントのデータを検証する Merkle 証明を検証する必要があります。回路検証者は、状態ルートを抽出する前に、入力block.blockHash(blockNumber)でBLOCKHASHオペコードを呼び出して、ブロックヘッダーB が正規チェーンからのものであることも確認します。ここで、 blockNumberブロックヘッダーBを指します。 B が正規の Ethereum チェーンの一部である場合、 BLOCKHASHオペコードによって返されるhash 、ブロックヘッダーBのハッシュと一致する必要があります。

さらに、検証回路は、ユーザーの ZK-SNARK 証明に含まれるヌルファイアを認証し、ヌルファイアが以前に使用されていないことを確認します。ハッシュ関数の衝突耐性は、同じburn address <> secret value組み合わせに対して 2 つの異なるヌルファイアハッシュN1とN2を生成する試みを防ぐことで、ここで補助的な役割を果たします。ユーザーが同じアドレスに対して異なるヌルファイアを生成できる場合、Sparse Merkle Tree がそのアドレスのヌルファイアを保存しているかどうかに関係なく、ETH を二重に発行できます。

ブロック提案者がプルーフオブバーンを検証できるようにするため、EIP-7503 では、ZK-SNARK プルーフの検証サポートを実装するための EVM の変更を提案しています。EIP-7503 の作者は、 Polaris EVMフレームワークを使用して EVM の EIP7503 対応バージョンを作成し、バーンプルーフの EVM 内検証の実装の実現可能性をテストしました。プロトコルの設計の詳細については、プロジェクト専用のGitHub リポジトリをご覧ください。

受取人アドレスにETHを発行する

EIP-7503 では、指定された金額を未使用のアドレスに入金したことを証明したユーザーに対して ETH を発行する新しいトランザクションタイプが導入されています。トランザクションの送信者は ZK-SNARK 証明 (ヌルファイアとともに) を送信し、ネットワークは (プルーフオブバーンを検証した後) 出金アドレスの残高を更新する状態遷移を実行します。

EIP-7503 はもっともらしい否認を提供しますが、ユーザーは、バーンアドレスに ETH を送信した同じアドレスからの資金でトランザクションの鋳造の支払いを避けることが推奨されます。アリスが ETH を使用不可のアドレス0xm00laに送信し、後で別のアカウントに鋳造される同じ量の ETH を支払うトランザクションを送信した場合、ボブはジミーニュートロンでなくてもアリスを元のバーントランザクションにリンクできます。

前のセクションでは触れていませんが、ユーザーは 2 番目のアドレスB (ミントトランザクションから ETH を受け取る) を ZK-SNARK 証明回路への公開入力として含める必要があります。これにより、ミントトランザクションがメモリプールで待機している間に、正直なユーザーがフロントランを取得する潜在的なエッジケースを防止できます。

検証者は送信アドレスの身元を確認せず、ETH をバーンした同じアドレスが、ミントトランザクションで ETH を償還しているかどうかを知る必要性を意図的に回避していることを思い出してください。これは、ユーザーが新しく生成されたアドレスで ETH を再ミントできることを意味するため、プライバシーの観点からは素晴らしいことですが、フロントランニング攻撃のリスクが高まります。証明は検証を通過するために必要なすべての情報 (秘密値sの知識を含む) をエンコードするため、誰でも同じ証明を持つ模倣ミントトランザクションを送信できますが、ミントされた ETH を受け取るためのアドレスは異なります。

幸いなことに、プルーフ・オブ・バーンに出金アドレスBを参照することを要求し、「ミントトランザクションは、プルーフ・オブ・バーンから抽出されたアドレスにのみ ETH をミントできる」という形式のルールを適用することができます。ZK-SNARK 回路への公開入力として渡されたアドレスとミントトランザクションで指定されたアドレスの等価性は、検証者によってチェックされます。こうすることで、すべてのユーザーは、誰もメモリプールからプルーフ・キャリング・トランザクションを取得して出金を盗むことができないことを確信できます。

なぜ EIP-7503 なのか? Ethereum でのプライベート転送のケース

プライベート送金と支払い

EIP-7503 は、送信アドレスと受信アドレスの間にリンクを（誤って）作成することなく、Ethereum ユーザーが資金を移動するための簡単な方法を提供します。検証目的でプルーフオブバーンとヌルファイアを提供することで、あるウォレットから新しく生成された使用不可アドレスに ETH を送信し、別のウォレットに引き出すことができます。外部の観察者にとって、ETH をバーンするアカウントと ETH を生成するアカウントの間にはまったく相関関係がありません。

ユーザーが 1 つのトランザクションで ETH をバーンし、すぐに新しいアドレスに ETH を鋳造する場合、エッジケースが発生する可能性があります。オンチェーン分析の専門家は、両方のアドレスを同じ人物が管理しているに違いないとすぐに判断する可能性があります。ただし、EIP-7503 には、匿名化の解除を防ぐ強力な機能があります。それは、もっともらしい否認可能性です。政治辞典によるもっともらしい否認可能性の定義は次のとおりです。

もっともらしい否認とは、関与を証明する明確な証拠がないため、違法または非倫理的な活動への関与を否定できる能力です。証拠がないため、否認は信憑性があり、もっともらしいものになります。— 政治辞典

もっともらしい否認は、CIA の活動の曖昧な世界から生まれた。そこでは、職員は部下が実行した行動を事前に知っていたことを否定する。公的にアクセス可能な出来事の記録である文書記録がないため、高官は現場の工作員を否認し、工作員の行動の結果に対する責任を回避する (大規模な PR 災害を回避する) ことができた。

もっともらしい否認可能性は、EIP-7503 を使用してプライベート転送を実行するという文脈でも同様の意味を持ちます。「メインウォレット」が 1.365 ETH をバーンし、「セカンダリウォレット」がその後すぐに 1.365 ETH をミントしたとします。この操作が熱心なオンチェーンスルースの注目を集めた場合、プライベート転送を完了したように見せるために、他の誰かが 1.365 ETH をミントしたと主張するだけで済みます。

そして、「秘密裏に送金する意図がないのに、なぜバーンアドレスに ETH を送信するのですか?」と尋ねられたらどうしますか? トランザクションが誤って発生したと主張できます。結局のところ、受信者のアドレスをタイプミスした人々によって膨大な量の ETH が失われたことを否定できる人は誰もいません (私もそのミスを犯しました)。これは会話全体をひっくり返します。なぜなら、大量の ETH の損失に共感しない人は、冷酷な人以外にはいないからです。

これは、EIP-7503 の重要性を捉えた、いくぶん些細な例です。もっともらしい否認可能性により、通常の Ethereum ユーザーは、プライバシープロトコルへの関与を示唆する具体的な情報を開示することなく、プライベートな転送を行うことができます。アプリケーションレイヤーのプライバシープロトコルとは異なり、EIP-7503 はトランザクショントレースをオンチェーンに保存することを回避し、バーントランザクションとミントトランザクションを現実世界の ID に関連付けることを困難にします。

EIP-7503 では、バーンアドレスへの資金の転送に関する情報 (転送額を含む) がオンチェーンに記録されるため、完全な匿名性とプライバシーは提供されません。ただし、トランザクション内の送信アドレスと受信アドレス間のリンクを解除する機能は非常に強力であり、アドレスの再利用に関する懸念を軽減します。

支払いを受け取るために同じアドレスを使用する代わりに、ユーザーは新しいバーンアドレスを生成し、このアドレスに資金を送信するように要求できます。ユーザーは秘密値sを知っているため、オンチェーン検証者にバーンアドレスの作成に対する制御を証明する有効なプルーフオブバーンを生成し、別のアドレスに ETH を発行して預金を「引き出す」ことができます。これは、転送を受け取るためにステルスアドレスを生成するという概念と非常によく似ており、異なるトランザクションを同じエンティティに関連付ける可能性を減らします。

EIP7503 スタイルのプライベート転送が他のシナリオでどのように役立つかがわかります。

商人: バーンアドレスで支払いを受け入れ、後でリンク不可能な引き出しアドレスに ETH を発行することで、商人は財務情報の漏洩を回避できます。EIP-7503 のプライベートトランザクション機能により、商人が商品に対して受け取る金額や商人の顧客ベースの規模などの詳細が外部の監視者に漏れるのをさらに防ぎます。
購入者: 販売者が公開しているアドレスに送金するのではなく、販売者が提供するバーンアドレスに支払いを行うことで、購入者は購入履歴に関する情報の漏洩を回避できます。バーンアドレスは販売者の「実際の」アカウントと関連付けることができないため、何を誰から購入したかを知ることが困難になります。
慈善活動: 慈善団体や政治組織は、送金者の身元がチェーン上に永久に記録されることなく資金を受け取ることができます。個人は、社会的評判を損なうことなく、特定の目的のために寄付することができます。

EIP-7503 はプライバシー以外の目的にも使用できます。

現在、中央集権型取引所 (CEX) は、ユーザーからの入金を受け取るために一意のアドレスを生成する必要があり、運用上のセキュリティプロセスの一環として、各アドレスの残高を 1 つ以上のコールドウォレットに転送するトランザクションを送信する必要があります。EIP-7503 を使用すると、CEX オペレーターは、一連のユーザーから入金を受け取る単一のバーンアドレスを作成し、バーンアドレスに蓄積されたすべての入金を単一のトランザクションでコールドウォレットに引き出すプルーフオブバーンを生成できます。コールドウォレットに CEX 入金を統合するために必要なトランザクション数が減ると、CEX オペレーター (運用コストの削減) とネットワーク (オンチェーントランザクション数の削減) の両方にメリットがあります。
大量の支払いをオンチェーンで処理する組織であれば、EIP-7503 を活用して運用効率を向上させることができます。したがって、CEX だけが恩恵を受けるわけではありません。マーチャント、慈善団体、暗号通貨ネイティブの支払いレールは、バーンアドレスに預金を集約し、複数の預金に取引コストを分散することで、EIP-7503 を使用して運用オーバーヘッドを削減する組織の例です。EIP-7503 のこの側面には、匿名セットに参加するための金銭的インセンティブを生み出すという望ましい副作用があり、プライベート転送を実行するアカウントの全体的なプライバシーが向上します。

プライバシーと実用性、規制遵守のバランスをとる

EIP-7503 は、プロトコルに大幅な変更を加えることなく、イーサリアム上でトランザクションのプライバシーを保障するためのシンプルな方法を提供します。特に、EIP-7503 により、イーサリアムは、Zcash や Monero などの他のプライバシー重視のブロックチェーンが直面している問題に直面することなく、トランザクションのプライバシーを提供できるようになります。

以前にもプライバシーコインを擁護する記事を書いたことがありますが、ZEC (Zcash) や MNR (Monero) などのプライバシーコインでは、分散型でプライベートで使用可能な通貨を世界経済に導入するという目標を達成できないことはすぐにわかります。規制圧力により取引所はプライバシーコインを上場廃止せざるを得なくなり、所有者は現実世界の状況で取引情報を隠すために明示的に設計された Zcash、Monero、その他のプロトコルが提供するプライバシーを活用することがますます難しくなるでしょう。Haseeb Qureshi の「プライバシーコインが普及しない理由」からの次の抜粋は、今日の「ハードコア」プライバシープロジェクトが直面している課題をよく理解するのに役立ちます。

プライバシーコインは常に、規制当局の調査の第一のターゲットとなってきました。規制当局が「ただ立っているのではなく、何か行動を起こす」よう求められたとき、最も簡単に悪者とされるのが、影の薄いプライバシーコインです。規制の面では、韓国、日本、英国、米国でプライバシーコインの上場廃止が相次いでいます。政府はプライバシーコインの締め付けを強めようとし続けています ( こちら、こちら、こちらを参照)。

暗号通貨ロビーは拡大しており、現在では小売業者や多くの機関が BTC と ETH を保有しています。しかし、プライバシーコインの擁護に加わろうとする機関はほとんどありません。業界全体が汚されるのを許すよりも、プライバシーコインが犠牲になるのを許す機関は多いのです。—ハシーブクレシ (プライバシーコインが普及しない理由)

EIP-7503 は、Ethereum の進化においてちょうど良いタイミングで登場したように感じます。どのブロックチェーンよりも多くのユーザーと多額の機関投資により、Ethereum は、過去にプライベート決済機能を提供しようとした他のプロジェクトと同じ運命をたどる可能性は低いでしょう。プライベートに発行された ETH トークンが流通し始めたら、いくつかの取引所が Ether の取引を制限するでしょうか? おそらくそうでしょう。しかし、他の 12 の取引所は喜んでその責任を引き受けるでしょう。これが強力なネットワーク効果を持つということです。

なぜ EIP-7503 が適切なタイミングで登場したと言えるのでしょうか。Ethereum の歴史上、ベースレイヤーでプライバシーをサポートすることは誰もがすぐに行うべきだと感じていた時期がありました。しかし、コミュニティの他のメンバーは (正しく)、Ethereum を「プライバシーテクノロジー」として推進することに関連する潜在的なエッジケースを指摘しました。以下は、 Ethereum Magicians フォーラムで Ethereum のプライバシー強化の必要性について議論した古いスレッドからの抜粋です。

グリフィスの直感はその後の数年間、ほぼ正しく、デフォルトでプライバシーが確保されている多くの暗号通貨は、強硬派のサイファーパンク（世界人口の 0.00001% 未満を占めるグループ）だけが使用する非主流通貨になる可能性に直面しています。それに比べて、イーサ（ETH）の価値と普及度は、EIP-7503 を採用して「プライバシー技術への推進」を行うことが 5 年前よりもリスクが低くなる程度までしか増加していません。

プライベート転送をサポートするためにアップグレードを実装する場合、おそらく逆規制キャプチャを回避したり、ベースレイヤーの複雑さを最小限に抑えたりするためです。適切な代替案は、EIP-7503 の実装の責任を Ethereum L2 および L3 に渡すことです。Ethereum のロールアップ中心のロードマップを考えると、ロールアップに EIP-7503 を実装することは理にかなっており、Ethereum にプライバシーを尊重するという目標を維持します (たとえば、ネイティブアカウント抽象化のために ERC-4337 を実装するロールアップと同様)。

EIP-7503 を実装するこのアプローチは、各 L2 チェーンに L2 のユーザー用に ETH をミントするブリッジコントラクトがすでにあるため、簡単です。ETH トークンをミントするメカニズムが備わっているため、ロールアップでは、EIP7503 スタイルのプライベート転送をサポートするために、チェーン上でヌルファイアを保存し、プルーフオブバーンを生成/検証するためのコンポーネントを追加するだけで済みます。EIP-7503 をインフラストラクチャに統合する予定のレイヤー 2 (L2) チェーンの例としては、この Request for Comment (RFC) で説明されているTaikoがあります。

ここで、Taiko のようなプロトコルは、EIP-7503 を採用することで、インフラストラクチャへの大規模な交換を行わずにトランザクションのプライバシーを提供できることがわかります。これは、本格的なプライバシー重視の L2 ( Aztec v2のように) を構築したくないが、ユーザーに基本的な追跡不可能性とリンク不可能性を提供したいプロトコルチームにとって重要な利点となります。Nethermind チームのTaiko への EIP-7503 の実装の提案は、 Ethereum L2 で EIP-7503 を実装する方法を理解するために読む価値があります。

EIP-7503 はプライバシーの必要性と規制遵守のバランスも取っており、これは Ethereum の「プライバシー 2.0」運動の目的と一致しています。つまり、ユーザーのプライバシーを保護しながら、悪意のある人物がプライバシーインフラストラクチャを悪用して不正な目的に使用することができないようにすることです。Ethereum Research で説明されているEIP-7503 の実装によると、EIP-7503 を採用したロールアップは、既知のハッカーや詐欺師がプライベート転送を使用して資金をロンダリングするのを選択的に禁止することで、Tornado Cash 問題の再発を防ぐことができます。

この特性を実現するために、ZK-SNARK バーントランザクションの証明を生成する回路への入力として、ブラックリストに登録されたアドレスのリスト ( blacklist[] ) をユーザーに渡す必要があります。回路は、バーン証明を生成する際に、ETH を受け取るユーザーのアドレスがブラックリストに保存されているアドレスに含まれていないことを確認します。入力がすべての有効性条件を満たさない場合、回路は証明を生成できないため、ブラックリストに登録されたアドレスへの転送は自動的に失敗します。

ブラックリストに登録されたアドレスのレジストリを維持すると、ある程度の中央集権化と潜在的な検閲ベクトルが導入されます。しかし、コミュニティ主導の地道な自己規制が中央集権的なトップダウンの規制よりも優れていると認めるなら、規制の遵守を確実にするためのこのようなガジェットが必要になるかもしれません。

オンチェーン組織向けのプライベート給与管理

透明性は、DAO (分散型自律組織) の基礎の 1 つです。投資家や利害関係者から金銭報酬の詳細が隠されている従来の組織とは異なり、DAO の貢献者の支払いはチェーン上で公開記録されます。このチェーン上の監査証跡により、かなりの説明責任が確保され、DAO 管理者による金銭管理の誤りにつながる可能性のある情報の非対称性が大幅に軽減されます。

しかし、DAO は必然的に成熟し、企業のように運営されるようになります (良くも悪くも)。その時点で、貢献者の報酬の詳細を非公開にするなどの対策が望まれるようになるかもしれません。EIP-7503 は、DAO がコア貢献者、開発者、独立請負業者に非公開の支払いを開始するために必要なインフラストラクチャを提供します。いずれの場合も、受取人は支払いを受け取り、選択したアドレスに引き出すためにバーンアドレスを生成するだけで済みます。

プライベートな貢献者/請負業者の支払いが実装された場合、DAO メンバーは管理者の責任をどのように維持するのでしょうか? これは、DAO が求めるプライバシーのレベルと、DAO メンバーが許容できる隠蔽のレベルによって異なります。たとえば、AliceDAO が DAO の作業に対して Alice に 20 ETH を支払い、そのお金が他の目的に使用されなかったことを証明するには、Alice は使用不可のアドレスを生成したことを示す証拠を提供できます。

たとえば、アリスは未使用アドレスを作成するために使用した秘密鍵s を公開する場合があります。未使用アドレスは鋳造操作後に無効になるため、アリスはリスクを負うことなくs を公開できます。サードパーティの検証者は、アリスが最初に使用したのと同じ暗号化ハッシュ関数を使用してs をハッシュし、両方のアドレスを比較することで未使用アドレスを導出します。それらが一致した場合、検証者は、トランザクションが送信された時点でアリスがバーンアドレスにアクセスできたことを把握します。ただし、アリスが鋳造された ETH トークンを受け取るために使用したアドレスはわかりません (アリスのプライバシーはある程度保護されます)。

暗号通貨ミキサーへの依存を減らす

Tornado Cash のようなミキサーを使用してウォレットアドレス間のリンクを切断することは、一種の連座制を生み出すため問題があります。ミキサーは、さまざまなユーザーが預けた資金を 1 つの資金に混ぜて匿名性を提供し、過去の預け入れを認証する証拠以外の情報を提供せずに誰でも引き出すことができることを覚えておいてください。

プライバシープールに投入される資金が増えるほど、外部の観察者が誰が何を所有しているかを推測することが難しくなります。悪意のある人物がプールに参加した場合、正直な参加者は、プロトコルの匿名セットに貢献することで、無意識のうちに犯罪者の資金洗浄を手助けしている可能性があります。これが、 OFAC の制裁が、既知の悪意のある人物 (フィッシングギャング、国家支援のハッカー、ブラックハットエクスプロイトなど) と関連付けられていない場合でも、Tornado Cash とやり取りしたアドレスにまで拡大された (そして現在も拡大されている) 理由でしょう。

Tornado Cash のようなミキサーは、代替可能性の問題も引き起こします。ミキシングプールから引き出されたトークンは「汚染」され、使用したり、ミキサーを通過していない「クリーン」なトークンと 1:1 で交換したりできなくなります。Reddit には汚染された資金の問題について詳しく議論している素晴らしいスレッドがありますので、ぜひ読んでみてください。そのスレッドから、より啓発的なコメントをいくつか紹介します。

これは現実世界に影響を与える可能性があります。たとえば、イーサリアムコミュニティの著名人の多くは、ウォレットに Tornado Cash プールから要求されていない量の ETH が送信された後、一部の dapp フロントエンドとやり取りできなくなりました。EIP-7503 は「コントラクトレスミキサー」と呼ばれ、通常の EOA 間転送を使用して ETH をバーンし、直接の鋳造を導入して匿名プールからの引き出しを容易にすることで (スマートコントラクトを使用するのではなく)、前述の問題を回避します。

契約のないミキサーのもう 1 つの利点は、匿名セットのサイズです。Tornado Cash (およびRailgunなどの類似プロトコル) では、匿名セットは小さく (参加者の数と相関関係にあります)、時間の経過とともに縮小します。対照的に、EIP-7503 は、Ethereum 上の使用可能および使用不可のアドレスのセット全体を匿名セットに変換します。アドレス空間が大きいことを考えると、プライベート転送の受信者に送信された ETH がどこから来たのかを知りたいオンチェーンの探偵にとって、困難な仕事が待ち受けていると言っても過言ではありません。

EIP-7503 を実装することには欠点がありますか?

EIP-7503 を実装した場合の潜在的な欠点は次のとおりです。

規制遵守の問題

これまでの分析では、イーサリアムがプライベート送金のサポートを開始しても、モネロやジーキャッシュと同じ運命をたどる可能性は低いと示唆されているが、EIP-7503 が有効化された場合に何が起こるかを実際に予測することは不可能である。以下は、規制当局への影響について議論している Ethereum Magicians スレッドの参加者からのコメントである。

Ethereum のネイティブなプライバシーソリューションである一方、コミュニティは、Tornado Cash を対象とした制裁の影響を受けて、プライバシー/匿名性と規制遵守の間の綱渡りをすることの重要性を認識し始めています。このアイデアは、 Privacy PoolsやNocturneなどの新世代のプライバシープロトコルの設計に特に影響を与えています。

プライバシープールを使用すると、ユーザーは、自分の預金が悪質な人物による預金を保管するプールから除外されていることを証明する「無実の証明」を生成できます。言い換えれば、ユーザーはミキサーとやり取りして、「私は犯罪者やテロリストの資金洗浄を手助けしていません」と言うことができます。
Nocturne は無実証明プロトコルへの移行を計画していますが、現在はコンプライアンスを保証するためにいくつかのガードレールを実装しています。これには、預金のフィルタリング、預金処理の遅延、アドレスごとのレート制限、プロトコルが 1 日に処理できる預金の合計額を制限するグローバルレート制限が含まれます。

Nocturne や Privacy Pools などのスマートコントラクトベースのプライバシーソリューションは、きめ細かな制御を実装し、違法行為に関与していると思われるユーザーを選択的に除外することができます。EIP-7503 などのプロトコル内プライバシーソリューションは無差別であり、望ましい機能ですが、問題が発生し、悪意のあるユーザーがプライベートトランザクション機能を悪用する可能性もあります。

前述のブラックリストガジェットを追加することで EIP-7503 を改善することは (理論的には) 可能ですが、これにより問題がパンドラの箱に詰まってしまう可能性があります。

ブラックリストに登録されたアドレスのリストは誰が管理するのでしょうか? OFAC にブラックリストに登録されたアドレスのリストを提供するよう依頼し、政府が Ethereum 上で誰が非公開で取引できるかを決定するリスクを負うのでしょうか? バリデーターのグループがblacklistedAddressesレジストリに登録された 1 つ以上のアカウントからの送金を検閲することを拒否した場合、物議を醸すフォークを引き起こすリスクがあるのでしょうか?
EIP-7503 がロールアップによって実装される場合、DAO はblacklistedAddressesレジストリの維持管理を担当するのでしょうか? または、創設チームは Chainalysis、Elliptic、TRM Labs などのフォレンジック企業と契約して、どのアドレスがプライベート転送の受信を制限すべきかに関する情報を提供するのでしょうか? 営利企業がロールアップのベースレイヤーで何が起こるかを決定すると、どのような問題が発生する可能性がありますか?
ロールアップで管理者権限を削除し、検証者/ミンターの契約をアップグレード不可にする場合、悪意のある人物がプロトコルを介して資金を移動しないようにするにはどうすればよいでしょうか? 既知の悪用者からのトランザクションを選択的にフィルタリングすることは、スタックの上位層 (シーケンサーまたはバリデーターレベルなど) で対処できますか? どのようなロジスティクスが必要ですか?

これらは、Ethereum (または Ethereum L2) が EIP-7503 を採用する前に答えなければならないいくつかの質問です。暗号はまだ未知の領域にありますが、プロトコルの長期的な存続に大きな影響を与える決定を下すときは、事前に潜在的なエッジケースを考えるというマーフィー術をたくさん実行することが役立ちます。

不幸は、幸運だけを期待する人に最も重くのしかかる。— セネカ

ERC-20トークンに関連する潜在的な中央集権化

EIP-7503 を実装するには、バーンレシートを受け入れ、前回のトランザクションでバーンされた ETH を受信者の残高にクレジットする新しいトランザクションタイプをサポートするために EVM をアップグレードする必要があります。実行クライアントもアップグレードして、ヌルファイアを格納するための Sparse Merkle Tree (SMT) をサポートし、ユーザーに代わってバーンの証明を生成および検証するためのオフチェーン回路を実装する必要があります。

アップグレードが実行不可能な場合があることを認識して、EIP-7503 の作者は、 ERC-20 トークンコントラクトを使用して EIP-7503 を実装するという代替案を提示しています。ユーザーは、前のセクションで説明したのと同じワークフロー (資金を使用不可のアドレスに送信し、無効化を生成する) を維持しますが、ETH トークンを受け取る代わりに、プルーフオブバーンを送信した後に ERC-20 トークンをミントします。ERC-20 コントラクトは、チェーン上でバーンプルーフを検証する特別な EIP-7503 検証コントラクトと統合されます (ERC-20 コントラクトは検証回路も実装できます)。

ERC-20 契約は EIP-7503 の実装を簡素化しますが、このアプローチでは中央集権化と検閲の問題が再び発生します。ERC-20 トークンをWrapped Ether (WETH)のようにアップグレード不可かつ管理不可にして中央集権化ベクトルを排除することはできますが、取引所がトークンを上場廃止するなどの問題には役立ちません。

また、規制当局がイーサリアムで流通しているプライバシー重視の暗号通貨を追及することに決めた場合、オンチェーンフォレンジックで ERC-20 契約とやり取りするアカウントを特定し、それらのアドレスをブラックリストに追加することが容易になることにも留意する必要があります。これは EIP-7503 が解決するように設計された問題であるため、「プライベート ERC-20 トークン」を作成するという提案がどのように改善されるのか理解するのは難しいかもしれません。

逆に、ERC-20 トークンを使用すると、ブラックリストに登録されたアドレスへの転送をブロックする転送スクリーニング機能の実装が容易になります。開発者は、 blacklist[]コントラクトに保存し、 transfer()を変更して、トランザクションでトークンを受け取るアドレスの ID チェックを含めるだけで済みます。ただし、これは、非常に強力な信頼の仮定を導入しなければ、プロトコルレベルで実装できない機能です。

研究開発費の増加

EIP-7503 には、匿名およびプライベートなトランザクションをサポートするために必要な、複雑で最先端の暗号化インフラストラクチャを構築、テスト、監査、および維持する要件が伴います。少なくとも、Nethermind による EIP-7503 の L2 実装の説明と Nobitex Labs のEIP-7503 Chain 概念実証はどちらも、EIP-7503 証明を生成および検証するための ZK-SNARK 回路の作成にかなりの量のエンジニアリング努力が費やされることを示唆しています。

また、ZK-SNARK のような暗号プリミティブは、プロトコル開発者が絶対的な自信を持って実装できるほど十分に実戦テストされていないことにも留意する必要があります。たとえば、Zcash は 2018 年に、不正なユーザーが資産所有権の偽の証明を提供して無制限の量のトークンを発行できるバグを修正しました。また、2019 年に Tornado Cash チームが潜在的なエクスプロイトからかろうじて逃れたことについても説明しました。

Ethereum の EIP-7503 実装におけるバグは、重大な影響を及ぼします。たとえば、プルーフオブバーンを検証する回路によって実行される重要なチェック (バーンアドレスの残高やヌルファイアの使用など) をバイパスできる欠陥を偶然発見したユーザーは、その知識を利用して無限の量の Ether を鋳造し、ETH の市場価値を暴落させる可能性があります。

もう一つの複雑な領域は、EIP-7503 検証者が、ユーザー生成の証明に含まれるブロックヘッダーB を検証する必要があることです。EVM は最後の 128 ～ 256 ブロックのハッシュを保存するため、オンチェーン検証者はより長い範囲のブロックヘッダーを信頼性を持って検証することはできません。

古いブロックの状態ルートを検証するには、 EIP-210を実装する必要があります。EIP-210 では、履歴ブロックハッシュを保存するシステムレベルのスマートコントラクトを作成し、 BLOCKHASHオペコードをリファクタリングしてクライアントがコントラクトを読み取れるようにすることを提案しています。

EIP-210 は、EVM で検証できる証明を生成して提出するためにユーザーに少なくとも 1 時間 ( 14 seconds * 256 blocks ) の猶予があるため、厳密には必要ではありません。それでも、バーンアドレスに送信されたデポジットの償還を遅らせる自由をユーザーに与えることで、UX が向上し、アドレスクラスタリングや同様の分析手法に対する引き出しプロセスの耐性が高まります。

代替案としては、（インセンティブを与えられた）アクターがオンチェーンコントラクトに過去のブロックヘッダーを送信することを要求するオラクルコントラクトを統合する方法があります。これは、システムレベルのスマートコントラクトを作成してオペコードをリファクタリングするよりも実装が簡単ですが、オラクルオペレーターを信頼して (a) 正しいブロックヘッダーを公開し、(b) ブロックヘッダーを速やかに送信する必要があります。これらの仮定が両方とも成立しない場合、誠実なユーザーは預金を償還できず、悪意のあるアクターは存在しないバーントランザクションのマークル証明を検証するために誤ったブロックヘッダーを公開する可能性があります。

匿名セットの削減

EIP-7503 が有効化されると、ブロック #11000 で ETH を発行するユーザーの匿名設定には、ETH 残高がプラスで送信トランザクションがゼロであるすべての Ethereum EOA が含まれます。これは匿名トランザクションの追跡不可能性にとって重要です。トランザクションが ETH をバーンする場合、使用不可アドレスは通常の Ethereum アドレスのように見えるため、バーントランザクションとして認識することは不可能です。

ただし、アカウント残高が静的のままでトランザクションが送信されないアドレスの数は、バーンアドレスのみが匿名セットを構成する点まで減少します。したがって、匿名セットは、Tornado Cash などの契約ベースのミキサーや、Privacy Pools や Railgun などの新世代のプライバシーツールの匿名セットのように見え始めます (EIP-7503 のプライバシー保証が徐々に減少することを意味します)。

唯一の例外は、送信者が誤って存在しないアドレスに資金を送金したために ETH を受け取ったアカウントです。このようなアカウントは、EIP-7503 匿名セットに永久に残ります。所有者が秘密鍵を紛失したアドレスを匿名プールの一部として考慮する必要があるかもしれませんが、これは (幸か不幸か) まれにしか起こらず、通常、これらのアカウントには少なくとも 1 つ以上の送信トランザクションがあります。(初心者のユーザーがトランザクションを行う前に秘密鍵を紛失することは想像しにくいです。)

匿名セットの縮小にもかかわらず、EIP-7503 はそれが提供するもっともらしい否認可能性のために依然として有用です。誰かが暗号通貨の Twitter で嵐を起こし、アリスが ETH を故意に燃やし (使用できないアドレスに送信することにより)、後で新しいアドレスに資金を引き出す意図で燃やしたと非難したとします。アリスはもっともらしい否認可能性を持っているため、次のように主張することでその申し立てに反論できます。

「ETHを誤ってアドレスに送信しました。MetaMaskにアドレスを入力する際に間違いがなかったことを証明できますか？」
「私はそのアドレスの秘密鍵を持っていますが、共有することはできません。今、私の秘密鍵を尋ねるつもりはないですよね？」
「アドレスの秘密鍵を持っているのですが、紛失してしまいました。秘密鍵を紛失していないことを証明できますか？」

これらの主張は説得力に欠けるかもしれないが、現実世界の文脈では、もっともらしい否認とはそういうものである。法律辞典では次のように説明されている。

「もっともらしいというのは、信頼できる、あり得る、あるいは可能性が高いという意味ではありません。もっともらしいというのは、何かが起こり得る、あるいは起こり得ないかもしれないと結論づけられるという意味です。しかし、通常は理論的、表面的、あるいは疑わしいものです。必ずしも「合理的な」結論である必要もありません。最も広い意味では、この用語は通常、証拠の欠如を指します。結局のところ、有罪が証明されるまで無罪というのは、私たちの法制度の根幹なのです。

だから、証拠がなければ、彼らがそれを否定するのはもっともらしい。本質的に、無実で蓋然性がある口実で言い逃れられる違法または非倫理的なことはすべて、それが真実かどうかにかかわらず、もっともらしい否認に該当する。たとえ否認のもっともらしさが疑わしい場合であっても。」

ユーザーが EIP-7503 プライベート転送に決定的に関連付けることができるのは、受取人アドレスへの転送を処理する瞬間のみです。ただし、ユーザーは、外部の観察者が引き出しトランザクションをバーントランザクションに関連付ける可能性を減らすか完全に排除するための手順を実行できます。

アリスは、使用可能なアドレスに引き出す代わりに、別のバーンアドレスに ETH を鋳造して、資金を匿名セット内に保持します。バーン → 鋳造 → バーン → 鋳造 → 繰り返しのプロセスを複数回繰り返すと、最終アドレスがアリスが管理するアカウントであるかどうかを検出することが難しくなります。
全額を引き出す代わりに、アリスは引き出しを 2 つ以上のトランザクションに分割します。引き出しを遅らせたりランダム化したりすると「ノイズ」が発生し、トランザクションアクティビティの分析が妨げられ、バーントランザクションとミントトランザクションを同じユーザーに関連付けることが難しくなります。

注: 2 番目の手法は EIP-7503 の提案された拡張であり、現在の設計では実現可能ではないようです。ユーザーが引き出しを分割するには、 nullifier 1バーンアドレスの残高の一部を鋳造する権利を付与し、 nullifier 2残高の別の一部を鋳造する権利を付与するなど、ヌルファイアを分割する機能が必要です。

結論

EIP-7503 は、イーサリアムの最も過小評価されている問題の 1 つである金融プライバシーの欠如に対する解決策です。イーサリアムが将来銀行に取って代わるのであれば、現状でユーザーが享受しているのと同等のレベルのプライバシーを提供する必要があります。それ以下では、イーサリアムは広く普及しません。なぜなら、たとえ検閲を回避するというメリットのためであっても、プライバシーを放棄することはほとんどの個人が払えない犠牲だからです。

EIP-7503 はまだレビュー段階であり、変更やパフォーマンスの改善が行われる可能性があります。部分的な金額の引き出しに対する将来のサポートに加えて、ユーザーが複数のバーンプルーフを単一の SNARK に再帰的に結合し、1 つの検証トランザクションで異なるバーンアドレスへの入金を検証できるようにする便利な機能があります。この機能により、(数百または数千の) バーンアドレスごとに個別にバーンプルーフを送信する必要がなく、ユーザーの入金ごとに 1 つのアドレスを維持したい CEX や販売者にとって、EIP-7503 の魅力がさらに高まります。

一般ユーザーも、トークンを複数のバーンアドレスに送信し (単一の使用不可アドレスに送信するのではなく)、集約された証明と無効化のセットを送信してプライベート転送を完了することでメリットを得ることができます。複数のバーンアドレスを使用することで、送信者はトランザクションアクティビティをさらにランダム化し、バーントランザクションを 1 人の人物にバックトラックする試みを阻止できます。これは、プライベートな自己転送、プライベートなピアツーピアの寄付/支払い、オンチェーン DAO のプライベートな給与管理など、EIP-7503 がすでに提供している主なメリットを補完するものです。

この記事を読んで楽しんでいただけたなら、有益と思われる人と共有することを検討し、EIP エコシステムから出てくる提案についてさらに詳しく知るために 2077 Research ニュースレターを購読してください。私たちは Ethereum のプライバシーソリューションに引き続き注力し、 ERC-5564 (ステルスアドレスを生成し、Ethereum でステルスアドレストランザクションを送信するための標準) についての詳細を公開する予定です。

乞うご期待！

著者注: この記事はここでも公開されています。