この記事の由来はCointelegraph & ethereum.org、原作者：Felix NG

日常翻訳者 |

日常翻訳者 |

実際、この新しいイーサリアム ドメイン名標準の正式名は「Web3 URL to EVM Call Message Translation」で、2022 年 2 月 14 日に最初に提案されました。この提案は、ETHStorage の創設者 Qi Zhou、イーサリアム研究者のサム ウィルソン、およびChao Pi. 1 年以上の評価を経て、「Web3 ドメイン名」を、分散型アプリケーション (DApps) フロントエンドや NFT などのオンチェーン Web3 コンテンツへの直接アクセスを提供する「HTTP スタイル」URL として記述します。投票、最終的に承認され、メインネット上で最終決定されました。

副題

ERC-4804 はどのような問題を解決できますか?

「現時点では、Uniswap などすべて […] DNS や GoDaddy を経由する必要がありますが、これらはすべて集中サーバーです。」

画像の説明

率直に言って、その理由は、今日でもほとんどのユーザーが HTTP として知られる「ハイパーテキスト転送プロトコル」を介してインターネットにアクセスすることを選択しているためです。インターネット ユーザーがリンクをクリックするか Web サイトのアドレスを入力すると、コンピュータは HTTP を使用して別のコンピュータに Web サイトや画像などの情報を取得するように要求します。つまり、Web3 からのデータの読み取りは通常、Web2 エージェントから Web3 ブロックチェーンへの変換に依存しますが、この「変換」作業は基本的に dApp Web サイト/ノード サービス プロバイダー/etherscan などのエージェントによって行われ、ユーザーが制御することはできません。

文章

Web3 URL標準とUniswap連携のワークフロー図。出典: w 3 eth.io

副題

ERC-4804 規格とは正確には何ですか?

• 次に、この ERC-4804 規格の具体的な内容を詳しく見ていきますが、この規格で定められている Web3 URL の形式は次のとおりです。

• web3 Schema は URL のスキーマを示し、web3:// の略称は w 3:// です。

• userinfo は、どのユーザーが EVM を呼び出しているか、EVM 呼び出しメッセージの「From」フィールドを示します。指定しない場合、プロトコルは送信者アドレスとして 0x 0 を使用します。

• ContractName は、呼び出すコントラクトを示します。これは、EVM 呼び出しメッセージの「To」フィールドです。 ContractName がアドレス、つまり 0x + 20 バイトの 16 進データの場合、「To」がアドレスになります。それ以外の場合、名前はネーム サービスから取得されます。 2 番目のケースでは、nsProviderSuffix は「eth」などのネーム サービス プロバイダーのサフィックスになります。名前がネーム サービスからアドレスに変換される方法については、EIP で後述します。

• chainid は、どのチェーンがcontractNameを解決し、メッセージを呼び出したかを示します。指定しない場合、プロトコルはネーム サービス プロバイダーと同じチェーンを使用します (例: eth の場合は 1)。ネームサービスプロバイダーが利用できない場合、デフォルトのchainidは1です。

query は、「&」で区切られた一連の属性と値のペアを含むオプションのコンポーネントです。

"To" アドレスとチェーン ID が決定されると、ERC-4804 プロトコルは "resolveMode" メソッドを呼び出してコントラクトのリゾルバー モードをチェックします。現在、手動モードと自動モードの 2 つの解決モードがサポートされています。

2. 自動モード: 自動モードはデフォルトの解決モードです (ターゲット コントラクトの "resolveMode" メソッドが使用できない場合にも適用されます)。自動モードでは、パスが空の場合、プロトコルは空のデータでターゲット コントラクトを呼び出します。それ以外の場合、EVM メッセージの通話データは、標準の Solidity コントラクト ABI を使用してエンコードおよびデコードされます。

副題

ERC-4804 標準にはどのような問題がありますか?

実際、Web サイトのコンテンツがイーサリアム ブロックチェーンまたは互換性のあるレイヤー 2 プロトコルに保存されている限り、Web3 ドメイン名を介して Web サイト全体にアクセスすることは理論的には可能ですが、そうするためのコストは非常に高くなります (少なくとも今のところは）。

先月のETHDenverカンファレンスで、ETHStorageの創設者Qi Zhou氏はこの問題を次のように分析した。

「ERC-4804の主な問題は、イーサリアムのストレージコストがメインネット上で非常に高価であることです。たとえば、1 GBのオンチェーンデータには約1,000万ドルの費用がかかります...多くのWeb2アプリケーション、さらには多くのNFTにとって、これは容認できないことです」ただし、レイヤー 2 ストレージ ソリューションはコストの一部を削減できます。」

コストの問題を考慮して、ETHStorage の広報担当者 Anthurine Xiang 氏は、まず ERC-4804 URL 標準をいくつかの特定のアプリケーションで使用できることを提案し、さらに次のように説明しました。

「すべてを分散化する必要があるわけではありません。まともな Web2 ビジネスを運営していて、集中化された検閲についてあまり心配する必要がない場合は、今のところ ERC-4804 を使用しないという選択もできます。」

もう 1 つの懸念は、ERC-4804 標準が Tornado Cash などの検閲の危険にさらされているサイトによって悪用される可能性があることです。これは、この標準が不正行為に悪用される可能性があることを意味します。この問題について、アンスリン・シャン氏は率直に次のように述べた。「ビットコインの元々の目的が悪のために生まれたわけではないのと同じように、言うのは非常に難しいですが、最初はシルクロードなど、一部の人々が不適切なことを行いました。 」

実際、ERC-4804 標準は最初の分散型 Web ホスティング ソリューションではありません。たとえば、惑星間ファイル システム (IPFS) も分散型アプローチに基づいてネットワークを作成するためのソリューションです。ただし、IPFS URL は静的なものにのみリンクできます。内容を修正または変更することはできません。対照的に、ERC-4804 は、ユーザーが「いいね！」やコメントを残して、Web サイト上のコンテンツと対話できるようにするなど、「移動中のデータ」を可能にします。また、ERC-4804 は、イーサリアムのネイティブ標準として、より簡単に利用できるようになると予想されています。他のブロックチェーンと統合され、ブロックチェーンと対話します。