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

Ethereum 上でプライバシーを保護しながら転送を行うためのメカニズムを導入する Ethereum Improvement Proposal (EIP) です。Tornado Cash などの暗号通貨ミキサーを含め、オンチェーン転送を非公開にする取り組みは数多く行われてきましたが、EIP-7503 は、Ethereum を にするプロトコル レイヤー ソリューションです。 EIP-7503: Zero-Knowledge Wormholes は、 デフォルトで非公開 これは重要な考慮事項です。Tornado Cash のようなアプリケーション層のプライバシーへのアプローチは「オプトイン」であり、多くの場合、ユーザーにマイナスの影響を与えます。プライバシー重視のアプリケーションは検閲の影響を受けやすく、たとえば、 以来、多くのユーザー (特に米国市民) は Tornado Cash を操作できなくなっています。 2022 年に米国外国資産管理局 (OFAC) がプロトコルのコントラクト アドレスをブラックリストに登録して OFAC の制裁にもかかわらず、Tornado Cash がまだ稼働しているのは、いくつかの理由によるものです。 Tornado Cashの資産混合機能を実装するコアコントラクトは不変であり、チェーン上に永久に保存されます。 ウェブサイトがオフラインになった後、独立したプロジェクトが元のTornado Cash実装の契約コードを再利用して、次のような新しいバリアントを作成しました。 。 トルネードキャッシュ トルネードキャッシュノヴァ トルネードキャッシュプロトコルは、ほとんど「管理不能」です。トルネードキャッシュの創設チームは、 攻撃者が偽造預金の有効な証明を作成し、（合法的に預金された）資金を流出させる可能性のあるバグを修正するために、創設チームは、一方的にキルスイッチをアクティブにして、彼らの意志にもかかわらずプロトコルを「オフにする」ように圧力をかけることはできませんでした。 。 緊急アップグレードの実行 2023年に逮捕 前述の要因は、分析によりイーサリアムのブロックプロデューサーが が正当であったわけではありません。たとえば、 によると、2023年の少なくとも2つの注目を集めた攻撃（Euler Financeの1億9,700万ドルのエクスプロイトとAnubis DAOの6,000万ドルのラグプル）は、Tornado Cashから引き出された資金で賄われていたか、ミキサーを使用して盗まれた資金をロンダリングし、送金を隠蔽していたことが示唆されています。 プロトコルの契約とやり取りするトランザクションをドロップしていることが示唆されているとしても、人々が今日でもTornado Cashを使用できることを意味します。ただし、OFACの制裁を受ける前の日々と同様に、Tornado Cashミキサープロトコルを経由したすべてのトランザクション Arkham Intelligenceの記事 Tornado Cash は、悪意のある人物がオンチェーンのプライバシーを悪用する問題を解決していないのに、なぜプロトコル レベルでプライベート転送を実行する機能を実装する必要があるのでしょうか。それは はないのでしょうか。そもそも、なぜプライベート トランザクションが必要なのでしょうか。Ethereum などのブロックチェーンは、すでに匿名で「追跡不可能」ではないのでしょうか。 危険で これらはすべて正当な疑問であり、この記事ではそれらすべてについて説明します。金融プライバシーの重要性について概要を説明し、Ethereum のようなパブリック ブロックチェーンが変更を加えずにプライバシーを保証できない理由を探ります。次に、Ethereum でプライベート支払いを可能にする EIP-7503 のアプローチを分析し、EIP-7503 を採用することの潜在的な利点と欠点について説明します。 さあ、始めましょう！ 舞台設定: オンチェーンのプライバシーをなぜ気にする必要があるのでしょうか? 電子ピアツーピア（P2P）決済の文脈で「プライベートトランザクション」または「匿名トランザクション」について話すとき、 と 2つの特性について説明しています。この2つの特性は、Nicolas van Saberhagen氏が で説明しています。 追跡不可能性 リンク不可能性の CryptoNoteのホワイトペーパー : 送信者が外部の観察者によって確実に識別できない場合、トランザクションは追跡不可能です。アリスがボブとキャロルと友達で、アリスが転送によって 2 つのトークンを受け取ったとします。追跡不可能とは、アリスにトークンを送信したのが誰 (ボブまたはキャロル) か誰もわからないことを意味します。 追跡不可能 : 受信者が外部の観察者によって確実に識別できない場合、トランザクションはリンク不可です。ボブとキャロルが別々のトランザクションでアリスにトークンを送信した場合、リンク不可とは、ボブとキャロルが同じ人物にトークンを送信したかどうかを誰も知ることができないことを意味します。 リンク不可 ほとんど（すべてではないにしても）のオンチェーン プライバシー ソリューションは、前述の要件のどれを満たすかに基づいて分類できます。 、 、 、主に送信アドレスに関する情報を隠し、資金を追跡不可能にすることに取り組んでいます。送信者の身元はさまざまなメカニズムを使用して保護されますが、資金を受け取った人は誰でも確認できます。 暗号通貨ミキサー CoinJoin リング署名は 比較すると、 、 、 、 などのプライバシー重視のプロトコルは、「シールド」または「機密」トランザクションのバリエーションを提供し、トランザクションのリンク不可性を保証します。シールドまたは機密トランザクションは、受信者のアドレスの詳細 (および転送されたトークンの量とタイプ) が秘密にされているため、特定の受信者にリンクすることが困難です。 、リンク不可性を維持するための別のアプローチです。ユーザーはデポジットに対して一時的な (短命の) アドレスを生成し、2 つの転送を同じアドレスにリンクしようとする試みをブロックします。 Monero Zcash Liquid Network Aztec v1 ステルス アドレスは トランザクションのプライバシーを向上させる前述のアプローチには、それぞれ独自の長所と短所がありますが、これについては後ほど簡単に説明します。しかし、今は、根本的な疑問、「金融プライバシーはなぜ重要なのか」に注目したいと思います。私たちは、プライベートで匿名のトランザクションを Ethereum に導入するという提案を分析するために時間と労力を費やしているので、Ethereum でトランザクションのプライバシーを有効にする根拠についても説明しておくべきでしょう。 金融プライバシーは ため重要です。プライバシーの権利は、すべての個人に、公開したい情報を決定する権限と、個人を特定できる情報 (PII) の共有方法、時期、場所を管理する権限を与えます。「個人を特定できる情報」は、個人の身元を明らかにするために使用できるあらゆる情報 (金融活動の詳細 (購入履歴、電子送金、収益など) を含む) を含む広範なカテゴリです。 、プライバシーが基本的人権である 以下は、個人が（金融）プライバシーの権利を行使する方法の例です。 銀行がオンライン取引に関する情報を公開し、ベスおばあちゃんがシェリルが孫を奪っていることを知ったとしたら、どんなに気まずいことになるでしょうか。 来年の感謝祭で人員を増やさない理由を家族に聞かれることなく、オンラインで避妊薬を購入する。 これは、特定の界隈で眉をひそめられるような慈善活動に寄付する場合、またはパフォーマンスをして慈善活動に（不必要な）注目を集めたくない場合に重要です。 寄付額の詳細や寄付の有無を明かさずに慈善団体に寄付すること。 例えば、ロシア出身のヴィタリック・ブテリンは、ロシアの侵攻と戦うウクライナ軍に寄付したが、ヴィタリックの国籍を考えると、公に寄付をするとおそらく不必要なPR危機を引き起こしただろうため、 。 公に関わりたくない政治活動に寄付すること。 代わりにトルネード・キャッシュを通じて資金が送られた 昨年の総収入が X ドルだったことを誰かに知られたくないでしょう。そのことが、お金を盗む計画を立てるのに十分な情報を与えてしまうからです (例: 詐欺やその他のソーシャル エンジニアリングの戦術を使用)。 悪意のある人物に財務状況の詳細を明かすことなく支払いを行います。 会社の財務活動の詳細を非公開にしておきたい場合や、従業員がその情報を非公開にしておきたい場合があります。 従業員の収入に関する情報を公開せずに従業員に支払いを行う。 これらの例は金融プライバシーの実際的な使用例を示していますが、プライバシー権の批判者がしばしば認めない詳細も浮き彫りにしています。つまり、プライバシーは手遅れになるまで必要だと思わないものであるということです。よくある「何を隠しているのですか?」という反論は、金融取引に関する情報をほとんど、あるいはまったく漏らしたくない関係者がいる特定の状況を認識していません。また、たとえ人々が恣意的な理由で物事を隠し としても、その秘密保持の欲求が公衆衛生と安全を危険にさらさない限り、なぜ彼らを煩わせるのでしょうか? たい 必要としているのに持っていないより、必要としていないのに持っているほうがよい。 ― フランツ・カフカ EIP-7503 で Ethereum のプライバシー問題を解決する 支持者や批評家による初期の説明とは反対に、イーサリアムやビットコインなどのパブリック ブロックチェーンは匿名性やプライベート性からは程遠いものです。これら 2 つの用語は混同されることが多いですが、それぞれ異なる意味を持っています。 プライバシーとは、 行動は公開された身元に追跡可能だが、行動の詳細は隠されていることを意味します。PGP ( ) ツールを使用して暗号化されたメールを送信するとします。メール サーバーは、メールが別の (識別可能な) 相手に送信されたことを認識しますが、メールの内容を読むことはできません。受信者以外は誰もメールを送信したことがわからないため、これは秘密の行動です。 秘密の Pretty Good Privacy 匿名性とは、 アクションが公開 ID から切り離されていることを意味します。前の例を使用すると、仮想のピアツーピア匿名メール サービスは、暗号化されたメールの送信元と送信先を難読化しながら、ネットワークを介してルーティングされるすべてのメールの公開記録を維持することができます。これは、誰かがメールを送信した記録がネットワーク上のすべての参加者に見えるため、公開アクションですが、メール アドレスはハッシュ文字列 ( ) であり、名前 ( ) ではありません。 公開 0xdeadbeef alice@gmail.com イーサリアムはプライベートではありません。なぜなら、ブロックチェーンは各トランザクションの記録を保持しており、転送された金額やトランザクションが実行したオンチェーンアクションなどが記録されているからです。また、ブロックチェーン上で取引するアカウントの情報（ で識別）が公開されているため、イーサリアムは匿名でもありません。イーサリアムのアカウントに「アリス・ホプキンス」のような実名を使用することはできませんが、すべてのトランザクションに同じアドレスを使用すると、ブロックチェーンフォレンジックが、 、 、 などの技術を使用して、トランザクションを現実世界のIDと関連付けることができます。 アドレス IPアドレス監視 アドレスクラスタリング グラフ分析 したがって、イーサリアムは正確には があり、匿名性やプライバシーを保証することはできません。これは、将来の価値のインターネットの決済レイヤーになることが期待されているプラットフォームにとっては良くありません。背景として、銀行はすでに、不正アクセスを防ぐために厳格なアクセス制御メカニズムを備えた集中データベースに金融データを保存することで、ユーザーに一定レベルのプライバシーを提供しています。 仮名性 これは「疑似プライバシー」です。銀行とデータベース インフラストラクチャ プロバイダーは、この情報にアクセスでき、それを使って何でもできるからです (たとえば、送金先の分析に基づいて制裁に従うために特定の国への支払いを凍結するなど)。しかし、「悪魔と深い海の間で選択する」という典型的なケースでは、平均的な個人は、プライバシーがまったくないよりも、 プライバシーを選択する可能性が高く、Ethereum アカウントを開設して、すべてのオンチェーン アクションを世界に公開することは不可能になります。 ある程度の 多くの人がこの問題を認識しています。特に、この問題が、ユーザーをイーサリアムのような分散型テクノロジーから、検閲や透明性への耐性を犠牲にしてわずかに優れたプライバシー保証を提供する集中型ソリューションへと移行させているためです。たとえば、Vitalik の イーサリアムの大量採用の見通しに対するプライバシーの重要性について優れた議論を提供しています。 The Three Transitions は、 3 つ目の [プライバシー保護転送への移行] がなければ、イーサリアムは失敗します。なぜなら、すべてのトランザクション (および POAP など) を公開して文字通り誰でも見ることができるようにすることは、多くのユーザーにとってプライバシーを犠牲にしすぎるため、誰もが少なくともある程度はデータを隠す集中型ソリューションに移行するからです。 — Vitalik Buterin 前述の問題の一部、特にトランザクション送信者の匿名性の欠如を改善するための取り組みです。この提案では、アドレスが資金を使用 に送信することで Ether (ETH) を意図的に破壊し、使用不可のアドレスへの入金を認証するための ZK-SNARK 証明を生成する手段が導入されています。この証明が検証に合格すると、一定量の ETH トークン (使用不可のアドレスの残高に等しい) がユーザーが選択した新しいアドレスに発行され、資金の転送に関与する送信アドレスと受信アドレス間のリンクが切断されます。 EIP-7503 は、 不可のアドレス EIP-7503 は、既存のプライバシー プロトコルからアイデアを借用して、Ethereum 上でプライバシー保護トランザクションを強化します。たとえば、この提案では、ETH 残高があり、送信トランザクションがゼロである Ethereum アドレスのセット全体を に変換することで、ミント トランザクションで受け取った資金を特定のソースに追跡することを困難にします。アドレス 次のトランザクションで再ミントした ETH をバーンしたアドレス を簡単に特定することはできません。アドレス は、残高がゼロではないが、Ethereum トランザクションを開始していない何百万ものアドレスの 1 つである可能性があります。 匿名セット B が A A これは、さまざまなソースからの資金を 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 万ドル以上のトークンを保有する、イーサリアムで最も裕福なアカウントです。ゼロ アドレスに誤って資金を送金する不運なユーザーを除けば、ゼロ アドレスにトークンを送信するユーザーの大多数は、 か (ゼロ アドレスを受信者として設定する必要があります)、意図的にそれらのトークンを流通から外しています。 契約を作成する オリジナルの トークンの供給量を減らすための関数は指定されていません。つまり、WETH (ラップされた Ether) などの古いトークンでは、ユーザーが元の預金を引き出す前にラップされた資産を流通から外すようにする方法がありません。ただし、WETH トークンをゼロ アドレスに送信すると、使用できなくなり、WETH ラッパー コントラクトから ETH が引き出されるたびに、WETH の流通供給量が減少するのをシミュレートします。WETH がネイティブ ETH と 1:1 の比率を維持する方法がわからない場合は、これが答えです。 ERC-20 トークン標準では、 EIP-7503 は、同様のメカニズムを使用して、ユーザーが ETH をバーンし、少し工夫して Ethereum 上の別のアドレスにトークンを発行できるようにします。EIP-7503 では、ユーザーに単一のバーン アドレスに資金を送信するよう求めるのではなく、別のアドレスに ETH を発行する前に、すべてのトランザクションに対して一意のバーン アドレスを生成することをユーザーに要求します。 2. ユーザーは、以前の取引で一定量のETHをバーンしたことを証明するプライベートなバーン証明または「バーンレシート」を作成し、バーンアドレスに送信します。 バーン アドレス (EIP-7503 仕様に従って作成) に資金を送信することは、ワームホールに現金を投げ込むのと同じであり、決して取り戻すことはできません。ただし、ZK-SNARK ( の ) を使用して、ワームホールに送信されたものに関する知識を証明する 。そのため、「ゼロ知識ワームホール」と呼ばれます。 ゼロ 知識 簡潔 な 議論 ことができます プルーフ・オブ・バーンは非公開です。なぜなら、ユーザーはトークンを使用不可のアドレス に送信したことを証明するだけでよく、 をプレーンテキストで公開する必要がないからです。プルーフ・オブ・バーンを生成するには、バーン アドレスが実際に使用不可であることを証明する必要があります。なぜでしょうか? ユーザーに、受信者アドレスに新しい ETH トークンを発行する前にネイティブ ETH をバーンするよう求めることで、両方の種類の資産のパリティ (価値と代替可能性) が確保されます。ユーザーが後でバーン アドレスから資金を引き出すことができる場合、ネイティブ ETH と発行された ETH トークン間の 1:1 ペグは存在しなくなります。 A A 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: 楕円曲線署名 公開鍵は、秘密鍵 (シークレットまたは略して と呼ばれる) に特別な「ジェネレータ」値 を掛けて 形式の新しい値を生成することによって生成されます。 、公開鍵を Keccak256 ハッシュ関数に通してハッシュ文字列の最初の 20 バイトを取得することによって生成されます。疑似数学表記では、この操作は のようになります。ここで、 はアドレス、 はシークレットまたは秘密鍵、 は楕円曲線上のジェネレータ ポイントです。 s G pubKey = privKey * G アドレスは A = K(s * G) A s G アドレス、公開鍵、秘密鍵はそれぞれまったく異なる目的で使用されます。 アドレスは公開され、取引で送金される資金を受け取るアカウントを識別します。 秘密鍵は、アドレスの残高からトークンを転送するようにネットワークに指示するメッセージに署名するために使用され、秘密にしておく必要があります。 公開鍵を使用すると、トランザクションの署名が対応する秘密鍵によって生成されたことを確認できます。 リストの最後の項目は、微妙な詳細を示しています。アドレスに送信された資金を使うことができるのは、秘密鍵を管理している場合のみです。つまり、アドレスの元となった公開鍵を生成するために使用された秘密鍵を知っている必要があります。アドレスの秘密鍵を知らない場合、または秘密鍵が他の誰かによって管理されている場合は、そのアドレスから資金を使うことはできません。 アドレス の残高が使用不可かどうかはどうすればわかるのでしょうか。まず、 の 20 バイトの値をランダムに選択し、暗号ハッシュ関数の特殊な特性である原像 を利用します。簡単に言えば、原像抵抗とは、 がランダムに選択された場合に ( のハッシュ) が と同じになるような値 見つからないことを意味します。疑似数学的表記では、この主張は という形式になります。 A A 抵抗 A H(x) x A x H(x) ≠ A ハッシュの (ハッシュ関数の出力) であり、 ハッシュ関数の原イメージ (ハッシュ関数への入力) です。H の の値を見つけることは、(a) 可能な整数の数が非常に多いこと、(b) ハッシュ関数が入力を操作して出力を生成する方法により困難です。したがって、 になる の値を「推測」できる唯一の方法は、膨大な計算能力と、 見つけるために膨大な数の計算を実行するのに十分な時間がある場合です。 A イメージ x H(x) = A x A x H(x) = A これは暗号化入門クラスではありませんが、これまでの説明は現代の暗号化システムの重要な特性を捉えています。ハッシュ関数の原像耐性特性は、EIP-7503 でも重要な役割を果たします。つまり、 がランダムな 20 バイトの値である場合、ユーザーは秘密鍵を導出できず はアドレスから資金を使う方法がないと確信できます。つまり、 を計算することは不可能です。ここで、 はバーン アドレス、 は秘密鍵またはシークレット、 はジェネレータ ポイントです (小さな注意: は前の段落の に相当します)。 A 、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/2 = 2 (「B」はアルファベットの 2 番目の文字)、30/2 = 15 (「O」はアルファベットの 15 番目の文字)、50/2 は 25 (「Y」はアルファベットの 25 番目の文字) です。 4-30-50 レッド パーティーの「トリプル レター」コードでは、各数字を 3 で割り、その結果の数字 (n) を使用してアルファベットの n 番目の位置にある文字を見つけます。たとえば、「BOY」は と暗号化できます。6/3 = 2 (「B」はアルファベットの 2 番目の文字)、45/3 = 15 (「O」はアルファベットの 15 番目の文字)、75/3 = 25 (「Y」はアルファベットの 25 番目の文字)。 6-45-=75 この例では同じメッセージに暗号化を使用していますが、実際には青党と赤党の人々が別のメッセージを交換することが予想されます (例: 「マックスは嫌な奴だ」(アリス → ボブ) と「青党のメンバーは負け犬だ」(シェリル → マックス) など)。それでも、同じメッセージを異なるコードで暗号化することは、暗号ハッシュ関数の衝突耐性を説明するのに役立ちます。 「BOY」を青党の「ダブルレター」アルゴリズムと赤党の「トリプルレター」アルゴリズムを使用して暗号化すると、結果は非常に異なります（それぞれ と ）。青党のメンバーは、赤党の暗号化アルゴリズムを使用しない限り、 生成することはできません。また、赤党のメンバーは、青党の暗号化アルゴリズムを使用しない限り、メッセージ文字列として 生成することはできません。各党は暗号化アルゴリズムの詳細を守っているため、ライバル党のメンバーは、自分宛てではないメッセージを解読できないことがわかります。 4-30-50 6-45-75 6-45-75 4-30-50 暗号ハッシュ関数は暗号化アルゴリズムとは異なります。ハッシュ関数は であり、出力から入力を導き出す方法がありませんが、例のような暗号化アルゴリズムには暗号化関数への入力を復号化するための があります。ただし、ハッシュ関数と暗号化アルゴリズムには、特に衝突耐性の領域で類似点があります。異なる暗号化アルゴリズムを使用して単一の入力に対して同じ出力 (暗号化されたメッセージ) を見つけることができなかったのと同様に、異なるハッシュ関数を使用して単一の入力に対して同じ出力 (ハッシュ) を見つけることはできません。 一方向 キー ハッシュ関数の衝突耐性を利用して、EIP-7503 で要求されているように、資産をバーンするための 未使用アドレスを生成できます。まず、ユーザーに秘密値 (Ethereum アカウントの秘密鍵) を選択してもらい、 の Keccak256 ハッシュを計算して公開鍵を導出し、公開鍵をハッシュしてアドレス を導出します。次に、秘密値 で示される別のハッシュ関数でハッシュし、出力の最初の 20 バイトをアドレスとして取得して、新しいアドレス 依頼します。 証明可能な s s * G A s を H B を生成するようにユーザーに 私たちの目標は、最終的に となることです。ここで、 Keccak256 ハッシュ関数を表し、 別のハッシュ関数ファミリーのハッシュ関数を表します。パフォーマンス上の理由から、 「ZK フレンドリー」である必要があります (つまり、回路内で の結果を確認するのが安価で高速である必要があります)。 K(x) ≠ H(x) K は H は H は H(x) アドレスは (秘密鍵×ジェネレータ) の Keccak256 ハッシュを計算する代わりにランダムに生成されたため、 の公開鍵を知ることはできません。つまり、 の秘密鍵も知ることはできません。 の秘密鍵がわからない場合、 の残高を使用するメッセージに有効な署名を生成することはできません。使用不可のアドレスを生成するための証明可能なランダムなプロセスにより、ユーザーは資産を再発行する前に ETH をバーンできるようになりました。 s * G B B B B プライベートプルーフオブバーンの生成 特定のユーザーが ETH を使用不可のアドレスに送信し その使用不可のアドレスがそのユーザーによって作成されたことをどのように証明するのでしょうか。最初のチェックは、ETH の不正な鋳造を防ぐために必要です (ユーザーが以前に ETH をバーンしたという証拠がない限り、新しい ETH トークンは鋳造されません)。ただし、2 番目のチェックも重要です。アドレスがユーザーによって作成されたことを知る必要があります。そうでない場合、ユーザーが他の人の預金を請求しようとしていないことを確認するための情報 (バーン トランザクションのハッシュなど) が必要になります。 、 プライバシー プロトコルへのユーザーの参加に関する情報が漏洩することを避けたいため、代わりにユーザーが (バーン アドレスを導出するためにハッシュされた秘密の値) を知っていることを証明する 、 公開せずに作成できるようにします。ゼロ知識証明は の結果から導出されたアドレス に関するユーザーの知識を主張します。s 秘密裏に選択されたため、他の人は となる異なる値 を計算することはできません。これは、前述のハッシュ関数の衝突耐性特性によるものです。 s ゼロ知識証明を s を H(s) B は H(s) = H(s) H(x) 隠すことで、悪意のある人物が EIP-7503 検証者に秘密 (使用不可アドレスの生成に使用) を知っていることを確認する証明を送信して、ユーザーのデポジットを償還するのを防ぐことができます。このセクションでは、検証者が 個別に計算する必要なく、H 証明するゼロ知識証明を作成できる理由について簡単に説明します。ただし、入力を明らかにせずに計算の有効性を証明するために ZK-SNARK を使用する背景については、Vitalik の と をお読みください。 s を s H(s) H(s) = A Quadratic Arithmetic Programs: Zero To Hero 私の ZK-EVM に関する記事 使用不可アドレス（ とも呼ばれる）へのユーザーの資金の送金を検証するゼロ知識証明を「プルーフ・オブ・バーン」または「バーンレシート」と呼びます。プルーフ・オブ・バーンは、以下のことを証明します。 バーンアドレス ユーザーは、アドレス と、 を導出するためにハッシュされた秘密の値 知っています (つまり、 )。これは、 が、使用可能な Ethereum アドレスを生成するために使用される Keccak256 ハッシュ関数とは異なる (ZK 対応の) ハッシュ関数で ハッシュした結果であることを確認することで、アドレスが使用不可であることを確認します。 A A s を H(s) = A A s を アドレス の ETH 残高は 以上 ( ) です。これは、ユーザーが受信アドレスに発行しようとしている金額が、使用不可アドレスに預け入れられている金額と同じであるかどうかをチェックしています。 A b b ≥ b' 1 番を証明するのは比較的簡単ですが、2 番を証明するには、イーサリアムの状態について特定のことを主張する必要があります。具体的には、(a) 使用不可アドレスが標準的なイーサリアム に存在すること、および (b) 使用不可アドレスの要求された残高が状態トライ内のアドレスに関連付けられた残高と一致することを証明する必要があります。これには、バーン証明を生成する回路への入力として、アドレス の 渡す必要があります。 状態トライ A Merkle 証明を Merkle 証明は、証明しようとしているリーフ (アドレス ) から Merkle トライのルート (トライのルートも Merkle 証明の一部) までのパスを計算するために必要な Merkle Patricia Trie (MPT) のリーフで構成されます。Merkle 証明の検証に使用される状態ルートも標準的であるという証拠が必要なため、ユーザーは回路への追加入力としてブロック ヘッダー を渡す必要があります。この情報セットにより、リソースが制限された検証者は、状態トライにアドレス が含まれていることを効率的に検証し、 のバランス 検証できます。 A B A A b を *: EIP-7503 仕様では、バーン アドレスが状態トライに含まれていることを証明するために必要な Merkle 証明を導出し、EIP-1186 で導入された を使用してアドレスの残高を検証することが推奨されています 注 eth_getProof JSON-RPC メソッド 。 アドレスのヌル文字の生成 使用不可アドレスへの預託証明を生成する ZK-SNARK 回路へのもう 1 つの入力は です。ヌルファイアは、ユーザーが同じプルーフ オブ バーンを使用して ETH を 発行することを防ぐ値です。ヌルファイアがなければ、賢いユーザーがプルーフ オブ バーンを再利用して ETH を複数回引き出すことを止めるものは何もありません。EIP-7503 プライベート転送を処理するノードの観点からは、使用不可アドレスの残高が減ることはなく (増えることしかできないため)、これらの引き出しは有効です。 、ヌルファイア 2 回 ヌルファイアは 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 プライベートな焼き付け証明の検証 プルーフ・オブ・バーンが証明しようとしているステートメントがわかったので、証明検証がどのように機能するかについて、ある程度の見当がつきました。最初のステートメント ( ) の場合、検証者はアドレス 生成するために使用されたハッシュ関数のロジックを「理解」する必要があります。つまり、 実際に 等しいことがわかります。検証回路でハッシュ関数のロジックをエンコードすると、 Keccak256 ハッシュ関数では 生成できないという要件も強制されます。 h(s) = A A を H(s) A に A を 2 番目のステートメント ( には ETH の正の残高 がある) については、検証者は、 が Ethereum の状態に含まれていることを証明し、アカウントのデータを検証する Merkle 証明を検証する必要があります。回路検証者は、状態ルートを抽出する前に、入力 で オペコードを呼び出して、ブロック ヘッダー 正規チェーンからのものであることも確認します。ここで、 ブロック ヘッダー を指します。 正規の Ethereum チェーンの一部である場合、 オペコードによって返される 、ブロック ヘッダー のハッシュと一致する必要があります。 A b A block.blockHash(blockNumber) BLOCKHASH B が blockNumber B B が BLOCKHASH hash B さらに、検証回路は、ユーザーの ZK-SNARK 証明に含まれるヌルファイアを認証し、ヌルファイアが以前に使用されていないことを確認します。ハッシュ関数の衝突耐性は、同じ 組み合わせに対して 2 つの異なるヌルファイア ハッシュ と を生成する試みを防ぐことで、ここで補助的な役割を果たします。ユーザーが同じアドレスに対して異なるヌルファイアを生成できる場合、Sparse Merkle Tree がそのアドレスのヌルファイアを保存しているかどうかに関係なく、ETH を二重に発行できます。 burn address <> secret value N1 N2 ブロック提案者がプルーフ オブ バーンを検証できるようにするため、EIP-7503 では、ZK-SNARK プルーフの検証サポートを実装するための EVM の変更を提案しています。EIP-7503 の作者は、 フレームワークを使用して EVM の EIP7503 対応バージョンを作成し、バーン プルーフの EVM 内検証の実装の実現可能性をテストしました。プロトコルの設計の詳細については、プロジェクト専用の をご覧ください。 Polaris EVM GitHub リポジトリ 受取人アドレスにETHを発行する EIP-7503 では、指定された金額を未使用のアドレスに入金したことを証明したユーザーに対して ETH を発行する新しいトランザクション タイプが導入されています。トランザクションの送信者は ZK-SNARK 証明 (ヌルファイアとともに) を送信し、ネットワークは (プルーフ オブ バーンを検証した後) 出金アドレスの残高を更新する状態遷移を実行します。 EIP-7503 はもっともらしい否認を提供しますが、ユーザーは、バーン アドレスに ETH を送信した同じアドレスからの資金でトランザクションの鋳造の支払いを避けることが推奨されます。アリスが ETH を使用不可のアドレス に送信し、後で別のアカウントに鋳造される同じ量の ETH を支払うトランザクションを送信した場合、ボブはジミー ニュートロンでなくてもアリスを元のバーン トランザクションにリンクできます。 0xm00la 前のセクションでは触れていませんが、ユーザーは 2 番目のアドレス (ミントトランザクションから ETH を受け取る) を ZK-SNARK 証明回路への公開入力として含める必要があります。これにより、ミントトランザクションがメモリプールで待機している間に、正直なユーザーがフロントランを取得する潜在的なエッジケースを防止できます。 B 検証者は送信アドレスの身元を確認せず、ETH をバーンした同じアドレスが、ミントトランザクションで ETH を償還しているかどうかを知る必要性を意図的に回避していることを思い出してください。これは、ユーザーが新しく生成されたアドレスで ETH を再ミントできることを意味するため、プライバシーの観点からは素晴らしいことですが、フロントランニング攻撃のリスクが高まります。証明は検証を通過するために必要なすべての情報 (秘密値 の知識を含む) をエンコードするため、誰でも同じ証明を持つ模倣ミントトランザクションを送信できますが、ミントされた ETH を受け取るためのアドレスは異なります。 s 幸いなことに、プルーフ・オブ・バーンに出金アドレス を参照することを要求し、「ミントトランザクションは、プルーフ・オブ・バーンから抽出されたアドレスにのみ ETH をミントできる」という形式のルールを適用することができます。ZK-SNARK 回路への公開入力として渡されたアドレスとミントトランザクションで指定されたアドレスの等価性は、検証者によってチェックされます。こうすることで、すべてのユーザーは、誰もメモリプールからプルーフ・キャリング・トランザクションを取得して出金を盗むことができないことを確信できます。 B なぜ 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 では、バーン アドレスへの資金の転送に関する情報 (転送額を含む) がオンチェーンに記録されるため、完全な匿名性とプライバシーは提供されません。ただし、トランザクション内の送信アドレスと受信アドレス間のリンクを解除する機能は非常に強力であり、アドレスの再利用に関する懸念を軽減します。 支払いを受け取るために同じアドレスを使用する代わりに、ユーザーは新しいバーン アドレスを生成し、このアドレスに資金を送信するように要求できます。ユーザーは秘密値 を知っているため、オンチェーン検証者にバーン アドレスの作成に対する制御を証明する有効なプルーフ オブ バーンを生成し、別のアドレスに ETH を発行して預金を「引き出す」ことができます。これは、転送を受け取るためにステルス アドレスを生成するという概念と非常によく似ており、異なるトランザクションを同じエンティティに関連付ける可能性を減らします。 s 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 ( のように) を構築したくないが、ユーザーに基本的な追跡不可能性とリンク不可能性を提供したいプロトコル チームにとって重要な利点となります。Nethermind チームの Ethereum L2 で EIP-7503 を実装する方法を理解するために読む価値があります。 Aztec v2 Taiko への EIP-7503 の実装の提案は、 EIP-7503 はプライバシーの必要性と規制遵守のバランスも取っており、これは Ethereum の「プライバシー 2.0」運動の目的と一致しています。つまり、ユーザーのプライバシーを保護しながら、悪意のある人物がプライバシー インフラストラクチャを悪用して不正な目的に使用することができないようにすることです。Ethereum Research で説明されている によると、EIP-7503 を採用したロールアップは、既知のハッカーや詐欺師がプライベート転送を使用して資金をロンダリングするのを選択的に禁止することで、Tornado Cash 問題の再発を防ぐことができます。 EIP-7503 の実装 この特性を実現するために、ZK-SNARK バーントランザクションの証明を生成する回路への入力として、ブラックリストに登録されたアドレスのリスト ( ) をユーザーに渡す必要があります。回路は、バーン証明を生成する際に、ETH を受け取るユーザーのアドレスがブラックリストに保存されているアドレスに含まれていないことを確認します。入力がすべての有効性条件を満たさない場合、回路は証明を生成できないため、ブラックリストに登録されたアドレスへの転送は自動的に失敗します。 blacklist[] ブラックリストに登録されたアドレスのレジストリを維持すると、ある程度の中央集権化と潜在的な検閲ベクトルが導入されます。しかし、コミュニティ主導の地道な自己規制が中央集権的なトップダウンの規制よりも優れていると認めるなら、規制の遵守を確実にするためのこのようなガジェットが必要になるかもしれません。 オンチェーン組織向けのプライベート給与管理 透明性は、DAO (分散型自律組織) の基礎の 1 つです。投資家や利害関係者から金銭報酬の詳細が隠されている従来の組織とは異なり、DAO の貢献者の支払いはチェーン上で公開記録されます。このチェーン上の監査証跡により、かなりの説明責任が確保され、DAO 管理者による金銭管理の誤りにつながる可能性のある情報の非対称性が大幅に軽減されます。 しかし、DAO は必然的に成熟し、企業のように運営されるようになります (良くも悪くも)。その時点で、貢献者の報酬の詳細を非公開にするなどの対策が望まれるようになるかもしれません。EIP-7503 は、DAO がコア貢献者、開発者、独立請負業者に非公開の支払いを開始するために必要なインフラストラクチャを提供します。いずれの場合も、受取人は支払いを受け取り、選択したアドレスに引き出すためにバーン アドレスを生成するだけで済みます。 プライベートな貢献者/請負業者の支払いが実装された場合、DAO メンバーは管理者の責任をどのように維持するのでしょうか? これは、DAO が求めるプライバシーのレベルと、DAO メンバーが許容できる隠蔽のレベルによって異なります。たとえば、AliceDAO が DAO の作業に対して Alice に 20 ETH を支払い、そのお金が他の目的に使用されなかったことを証明するには、Alice は使用不可のアドレスを生成したことを示す証拠を提供できます。 たとえば、アリスは未使用アドレスを作成するために使用した秘密鍵 公開する場合があります。未使用アドレスは鋳造操作後に無効になるため、アリスはリスクを負うことなく 公開できます。サードパーティの検証者は、アリスが最初に使用したのと同じ暗号化ハッシュ関数を使用して ハッシュし、両方のアドレスを比較することで未使用アドレスを導出します。それらが一致した場合、検証者は、トランザクションが送信された時点でアリスがバーン アドレスにアクセスできたことを把握します。ただし、アリスが鋳造された ETH トークンを受け取るために使用したアドレスはわかりません (アリスのプライバシーはある程度保護されます)。 s を s を s を 暗号通貨ミキサーへの依存を減らす Tornado Cash のようなミキサーを使用してウォレット アドレス間のリンクを切断することは 制を生み出すため問題があります。ミキサーは、さまざまなユーザーが預けた資金を 1 つの資金に混ぜて匿名性を提供し、過去の預け入れを認証する証拠以外の情報を提供せ 誰でも引き出すことができることを覚えておいてください。 、一種の連座 ずに プライバシー プールに投入される資金が増えるほど、外部の観察者が誰が何を所有しているかを推測することが難しくなります。悪意のある人物がプールに参加した場合、正直な参加者は、プロトコルの匿名セットに貢献することで、無意識のうちに犯罪者の資金洗浄を手助けしている可能性があります。これが、 、既知の悪意のある人物 (フィッシング ギャング、国家支援のハッカー、ブラックハット エクスプロイトなど) と関連付けられていない場合でも、Tornado Cash とやり取りしたアドレスにまで拡大された (そして現在も拡大されている) 理由でしょう。 OFAC の制裁が Tornado Cash のようなミキサーは、代替可能性の問題も引き起こします。ミキシング プールから引き出されたトークンは「汚染」され、使用したり、ミキサーを通過していない「クリーン」なトークンと 1:1 で交換したりできなくなります。Reddit がありますので、ぜひ読んでみてください。そのスレッドから、より啓発的なコメントをいくつか紹介します。 には汚染された資金の問題について詳しく議論している素晴らしいスレッド これは現実世界に影響を与える可能性があります。たとえば、イーサリアム コミュニティの著名人の多くは、ウォレットに Tornado Cash プールから要求されていない量の ETH が送信された後、 。EIP-7503 は「コントラクトレス ミキサー」と呼ばれ、通常の EOA 間転送を使用して ETH をバーンし、直接の鋳造を導入して匿名プールからの引き出しを容易にすることで (スマート コントラクトを使用するのではなく)、前述の問題を回避します。 一部の dapp フロントエンドとやり取りできなくなりました 契約のないミキサーのもう 1 つの利点は、匿名セットのサイズです。Tornado Cash (および などの類似プロトコル) では、匿名セットは小さく (参加者の数と相関関係にあります)、時間の経過とともに縮小します。対照的に、EIP-7503 は、Ethereum 上の および アドレスのセット全体を匿名セットに変換します。アドレス空間が大きいことを考えると、プライベート転送の受信者に送信された ETH がどこから来たのかを知りたいオンチェーンの探偵にとって、困難な仕事が待ち受けていると言っても過言ではありません。 Railgun 使用可能 使用不可の 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 上で誰が非公開で取引できるかを決定するリスクを負うのでしょうか? バリデーターのグループが レジストリに登録された 1 つ以上のアカウントからの送金を検閲することを拒否した場合、物議を醸すフォークを引き起こすリスクがあるのでしょうか? blacklistedAddresses EIP-7503 がロールアップによって実装される場合、DAO は レジストリの維持管理を担当するのでしょうか? または、創設チームは Chainalysis、Elliptic、TRM Labs などのフォレンジック企業と契約して、どのアドレスがプライベート転送の受信を制限すべきかに関する情報を提供するのでしょうか? 営利企業がロールアップのベース レイヤーで何が起こるかを決定すると、どのような問題が発生する可能性がありますか? blacklistedAddresses ロールアップで管理者権限を削除し、検証者/ミンターの契約をアップグレード不可にする場合、悪意のある人物がプロトコルを介して資金を移動しないようにするにはどうすればよいでしょうか? 既知の悪用者からのトランザクションを選択的にフィルタリングすることは、スタックの上位層 (シーケンサーまたはバリデーター レベルなど) で対処できますか? どのようなロジスティクスが必要ですか? これらは、Ethereum (または Ethereum L2) が EIP-7503 を採用する前に答えなければならないいくつかの質問です。暗号はまだ未知の領域にありますが、プロトコルの長期的な存続に大きな影響を与える決定を下すときは、事前に潜在的なエッジケースを考えるという たくさん実行することが役立ちます。 マーフィー術を 不幸は、幸運だけを期待する人に最も重くのしかかる。— セネカ ERC-20トークンに関連する潜在的な中央集権化 EIP-7503 を実装するには、バーン レシートを受け入れ、前回のトランザクションでバーンされた ETH を受信者の残高にクレジットする新しいトランザクション タイプをサポートするために EVM をアップグレードする必要があります。実行クライアントもアップグレードして、ヌルファイアを格納するための Sparse Merkle Tree (SMT) をサポートし、ユーザーに代わってバーンの証明を生成および検証するためのオフチェーン回路を実装する必要があります。 アップグレードが実行不可能な場合があることを認識して、EIP-7503 の作者は、 しています。ユーザーは、前のセクションで説明したのと同じワークフロー (資金を使用不可のアドレスに送信し、無効化を生成する) を維持しますが、ETH トークンを受け取る代わりに、プルーフ オブ バーンを送信した後に ERC-20 トークンをミントします。ERC-20 コントラクトは、チェーン上でバーン プルーフを検証する特別な EIP-7503 検証コントラクトと統合されます (ERC-20 コントラクトは検証回路も実装できます)。 ERC-20 トークン コントラクトを使用して EIP-7503 を実装するという代替案を提示 ERC-20 契約は EIP-7503 の実装を簡素化しますが、このアプローチでは中央集権化と検閲の問題が再び発生します。ERC-20 トークンを のようにアップグレード不可かつ管理不可にして中央集権化ベクトルを排除することはできますが、取引所がトークンを上場廃止するなどの問題には役立ちません。 Wrapped Ether (WETH) また、規制当局がイーサリアムで流通しているプライバシー重視の暗号通貨を追及することに決めた場合、オンチェーンフォレンジックで ERC-20 契約とやり取りするアカウントを特定し、それらのアドレスをブラックリストに追加することが容易になることにも留意する必要があります。これは EIP-7503 が解決するように設計された問題であるため、「プライベート ERC-20 トークン」を作成するという提案がどのように改善されるのか理解するのは難しいかもしれません。 逆に、ERC-20 トークンを使用すると、ブラックリストに登録されたアドレスへの転送をブロックする転送スクリーニング機能の実装が容易になります。開発者は、 コントラクトに保存し、 を変更して、トランザクションでトークンを受け取るアドレスの ID チェックを含めるだけで済みます。ただし、これは、非常に強力な信頼の仮定を導入しなければ、プロトコル レベルで実装できない機能です。 blacklist[] transfer() 研究開発費の増加 EIP-7503 には、匿名およびプライベートなトランザクションをサポートするために必要な、複雑で最先端の暗号化インフラストラクチャを構築、テスト、監査、および維持する要件が伴います。少なくとも、Nethermind に と Nobitex Labs の どちらも、EIP-7503 証明を生成および検証するための ZK-SNARK 回路の作成にかなりの量のエンジニアリング努力が費やされることを示唆しています。 よる EIP-7503 の L2 実装の説明 EIP-7503 Chain 概念実証は また、ZK-SNARK のような暗号プリミティブは、プロトコル開発者が絶対的な自信を持って実装できるほど十分に実戦テストされていないことにも留意する必要があります。たとえば、Zcash は 2018 年に、不正なユーザーが資産所有権の偽の証明を提供して できるバグを修正しました。また、2019 年に Tornado Cash チームが も説明しました。 無制限の量のトークンを発行 潜在的なエクスプロイトからかろうじて逃れたことについて Ethereum の EIP-7503 実装におけるバグは、重大な影響を及ぼします。たとえば、プルーフ オブ バーンを検証する回路によって実行される重要なチェック (バーン アドレスの残高やヌルファイアの使用など) をバイパスできる欠陥を偶然発見したユーザーは、その知識を利用して無限の量の Ether を鋳造し、ETH の市場価値を暴落させる可能性があります。 もう一つの複雑な領域は、EIP-7503 検証者が、ユーザー生成の証明に含まれるブロック ヘッダー 検証する必要があることです。EVM は最後の 128 ～ 256 ブロックのハッシュを保存するため、オンチェーン検証者はより長い範囲のブロック ヘッダーを信頼性を持って検証することはできません。 B を 古いブロックの状態ルートを検証するには、 を実装する必要があります。EIP-210 では、履歴ブロック ハッシュを保存するシステム レベルのスマート コントラクトを作成し、 オペコードをリファクタリングしてクライアントがコントラクトを読み取れるようにすることを提案しています。 EIP-210 BLOCKHASH EIP-210 は、EVM で検証できる証明を生成して提出するためにユーザーに少なくとも 1 時間 ( ) の猶予があるため、厳密には必要ではありません。それでも、バーン アドレスに送信されたデポジットの償還を遅らせる自由をユーザーに与えることで、UX が向上し、アドレス クラスタリングや同様の分析手法に対する引き出しプロセスの耐性が高まります。 14 seconds * 256 blocks 代替案としては、（インセンティブを与えられた）アクターがオンチェーン コントラクトに過去のブロック ヘッダーを送信することを要求するオラクル コントラクトを統合する方法があります。これは、システム レベルのスマート コントラクトを作成してオペコードをリファクタリングするよりも実装が簡単ですが、オラクル オペレーターを信頼して (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 のプライバシー ソリューションに引き続き注力し、 (ステルス アドレスを生成し、Ethereum でステルス アドレス トランザクションを送信するための標準) についての詳細を公開する予定です。 ERC-5564 乞うご期待！ 著者注: この記事はここ 公開されています。 でも