はじめに

初めまして。
CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！
スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。

代表的なゲームはクリプトスペルズというブロックチェーンゲームです。

今回は、ENS（イーサリアム・ネーム・サービス）のコントラクトに関する提案している規格であるERC162についてまとめていきます！

以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。

他にも様々なERCについてまとめています。

概要

この文章は、イーサリアム・ネーム・サービス（ENS）のためのコントラクトに関するものです。
ENSは、イーサリアムブロックチェーン上でドメイン名を管理するシステムで、2017年5月4日にメインネットワークに導入されました。

対応するソースコードは以下に格納されています。

背景情報に関しては、EIP137を参照してください。

Registrars are responsible for allocating domain names to users of the system, and are the only entities capable of updating the ENS; the owner of a node in the ENS registry is its registrar. Registrars may be contracts or externally owned accounts, though it is expected that the root and top-level registrars, at a minimum, will be implemented as contracts.

EIP 137

レジストラーは、システムのユーザーにドメイン名を割り当てる責任を持っており、ENSを更新することができる唯一のエンティティです。ENSレジストリ内のノードのオーナーはそのレジストラーとなります。レジストラーはコントラクトや外部所有のアカウントであることができますが、少なくともルートとトップレベルのレジストラーはコントラクトとして実装されることが期待されています。

ERC137については以下を参考にしてください。

ENSの中心的な要素は「レジストラー」というエンティティです。
レジストラーは、ユーザーにドメイン名を割り当てるロールを持ち、ENS内でのみ変更や更新を行うことができます。
レジストラーは、コントラクト（スマートコントラクト）または外部所有のアカウントで運営されますが、主要なレジストラー（例えばルートやトップレベル）はコントラクトとして実装されることが多いです。

ENSの効果的な運用のためには、適切に設計されたレジストラーが必要です。
このレジストラーはENSの核となるプロトコルからは別の要素であり、ドメイン名の割り当て方法に関するさまざまな考え方があります。
特に、ドメイン名の「占拠」や無意味な投機を防ぐための戦略が重要です。
そのため、最初の期間には「初期レジストラー」と呼ばれるシンプルな割り当て方法が提案されています。
この初期段階では、.ethドメインに限定され、7文字未満のサブドメインは使用できません。

初期レジストラーの実装は、主に@alexvandesandeと@arachnidによって行われており、これはより広い議論を促進するためのものです。
この初期レジストラーは、将来的に「永続的なレジストラー」に置き換えられる予定です。
永続的なレジストラーでは、より多くのドメインが利用可能になり、初期レジストラーから学んだ教訓が取り入れられます。
この変更は、最初の導入から約2年以内に行われると予定されています。

動機

ENS の採用、および初期レジストラのネームスペースの適切なガバナンスを最適化するためには、以下の要素を考慮する必要があります。

アップグレード可能性

初期レジストラーは、経験から得た知識を基にして、より良い永続的なレジストラーに安全にアップグレードできるようにする必要があります。
つまり、初期のシステムは将来的に改善されることを前提として設計されるべきです。

効果的な割り当て

新しいネームスペースが公開されると、「名前の争奪戦」が起こりがちです。
これにより、多くの価値ある名前が買われても使われずに放置され、後で高値で売ることを目論むことがあります。
これは、最も有用な名前が利用しにくくなり、結果的にENSのユーザーにとっての便益を減少させる可能性があります。
初期レジストラーは、このような誤った割り当ての長期的なコストを限定することに重点を置くべきです。

セキュリティ

レジストラーはイーサリアムの通貨、イーサを上限なく保持することになるので、セキュリティ面で非常に強固に設計される必要があります。

シンプルさ

ENSの設計はシンプルであることが強調されています。
したがって、中間的なレジストラーも、他の設計目標を達成しつつ、可能な限りシンプルであることが望まれます。

採用

成功した基準や標準は、ネットワーク効果によってさらに成功します。
レジストラーは、一般的にENSがより広く採用されるための戦略を考える必要があります。
特に、自分たちが管理するネームスペースが広く使われるようにするための戦略が重要です。

これらが、ENSとその初期レジストラーを効果的に管理し、普及させるための重要な考慮点です。

仕様

特定の制限

イーサリアム・ネーム・サービス（ENS）の「初期レジストラー」には、特定の制限が設けられています。
これらの制限の目的は、ENSが安定して動作し、将来の改善に必要な知見を収集することです。
ここでの主な制限点を簡単に説明します。

運用期間

初期レジストラーは約2年間運用される予定です。
この期間は、ENSシステムを観察し、学習し、次のバージョンのシステムを設計するのに十分な時間とされています。

ネームスペースの制限

初期の2年間、利用可能なネームスペースは.ethというトップレベルドメイン（TLD）に限定されます。
これは、ENSのルートノードのオーナーによって強制される制限です。
このルートノードのオーナーは、.eth以外のどのノードも初期レジストラーに割り当てるべきではありません。

マルチシグコントラクトによるコントロール

ENSのルートノードは、マルチシグコントラクトを使用して複数の当事者によって管理されるべきです。
これにより、より安全で分散化された管理が可能となります。

名前の長さに関する制限

初期レジストラーでは、6文字以下の名前の登録が禁止されます。
これにより、短すぎる名前による混乱や不便を防ぎ、より実用的な名前の使用を促進することが狙いです。

これらの制限は、ENSの将来に向けた基盤を固め、より良いシステムへの移行をスムーズにするために設けられています。

ハッシュ登録の名前形式

イーサリアム・ネーム・サービス（ENS）の初期レジストラーに名前を登録する際のハッシュ形式について説明します。

初期レジストラーに提出される名前は、イーサリアムのsha3関数を使ってハッシュ化する必要があります。
重要なのは、レジストラーに提出されるハッシュは、EIP137で定義されている「namehash」ではなく、登録されるサブドメインラベルのハッシュであることです。

例えば、「abcdefg.eth」というドメインを登録する場合、sha3('abcdefg')を提出する必要があります。
これは、sha3(sha3(0, 'eth'), 'abcdefg')という形式ではありません。

この方法は、ENSの初期レジストラーでドメイン名を登録する際の標準的なプロセスであり、システムのセキュリティと一貫性を確保するために使用されます。

名前のオークション

ENS（イーサリアム・ネーム・サービス）の初期レジストラーでのドメイン名のオークションについて説明します。

ENSでドメイン名を割り当てる際には、ヴィックリー・オークション（封印入札オークション）という方法が用いられます。

A Vickrey auction is a type of sealed-bid auction. Bidders submit written bids without knowing the bid of the other people in the auction. The highest bidder wins but the price paid is the second-highest bid. This type of auction… gives bidders an incentive to bid their true value.

Vickrey Auction, Wikipedia

このオークションでは、入札者は他の人の入札額を知らずに自分の入札を行い、最高入札者が勝ちますが支払う金額は二番目に高い入札額になります。
これは、入札者が自分の本当の評価額を入札するよう促す仕組みです。

このオークションには以下の5つの段階があります。

まだ利用できない
- 多くの名前は最初はオークションできませんが、開始から8週間以内に徐々に利用可能になります。
オープン
- 各名前の利用可能な時期は、そのsha3ハッシュの重要なバイトによって決まります。
- 例えば、0x00はすぐに利用可能、0xFFは8週間後になります。
オークション
- オークションが始まると、72時間の入札期間があります。
- 入札者はイーサリアムと封印された入札（sha3(bytes32 hash, address owner, uint value, bytes32 salt)のハッシュ）を提出します。
- 実際の入札額を隠すために、より多くのイーサリアムを送ることができます。
公開
- 入札期間後の48時間は公開期間です。
- この間に入札者は、封印された入札の本当の内容を明らかにする必要があります。
- 公開された後、イーサリアムは返金されます。
- もし公開されなければ、その名前は再びオープン状態に戻ります。
所有
- 公開期間後、勝者はオークションを完了するためのトランザクションを提出し、ENSのsetSubnodeOwner関数を使って、その名前のハッシュの所有者として自身のアドレスを記録します。

このように、ENSのオークションは複数の段階を経て進行し、ドメイン名の公平な割り当てを目指しています。

レジストら・パラメータ

ENSの初期レジストラーにおけるオークションのパラメーターについて説明します。

名称	説明	値
totalAuctionLength	オークション開始から公開期間終了までの全期間。	5日
revealPeriod	入札が許されず、入札の公開が必要な期間の長さ。	48時間
launchLength	全ての名前がオークションに利用可能になる期間。	8週間
minPrice	名前の所有権と引き換えにロックアップする必要がある最低イーサリアムの額。	0.01イーサ

totalAuctionLength（オークション全体の期間）

これはオークションの開始から入札の公開が終了するまでの全期間を指し、合計で5日間です。

revealPeriod（公開期間）

オークションの最後の48時間は、入札者が自分の入札を公開する期間です。
この間は新しい入札は受け付けられません。

launchLength（開始期間）

この8週間は、全てのドメイン名がオークションで入札可能になるまでの期間です。

minPrice（最低価格）

ドメイン名を所有するために必要な最低イーサリアム額で、0.01ETHと設定されています。

これらのパラメーターは、ENSのオークションがどのように機能するかを理解するのに役立ちます。
オークションは5日間続き、最後の2日間は入札の公開期間となります。
全ての名前がオークションに出されるまでには8週間かかり、ドメイン名を手に入れるためには少なくとも0.01ETHを支払う必要があります。

証書

ENS（イーサリアム・ネーム・サービス）の初期レジストラーコントラクトにおける「ディード（Deed）」とは、オークションに関連する特定の機能を持つコントラクトのことを指します。
これについて簡単に説明します。

ディードコントラクトの役割

初期レジストラーコントラクト自体はイーサリアムを保持しませんが、オークションで使われるイーサリアムは全て別のディードコントラクトで管理されます。
このディードコントラクトは、入札が行われるときに初めて作成され、その入札額で資金供給されます。

オークション後の処理

オークションが終了し、特定のハッシュが登録された後、勝利した入札のディードは、そのハッシュの所有権と引き換えに保持されます。
勝利しなかった入札は返金されます。

所有権の転送

所有されている名前のディードは、所有者によって他のアカウントに転送することができます。
これにより、名前の所有権と管理権が新しいアカウントに移ります。

所有権の放棄と返還

登録から1年後、ハッシュの所有者は所有権を放棄し、ディードの価値を自分に返還することを選択できます。

非勝利入札のディードの閉鎖

勝利しなかった入札のディードは、いくつかの方法で閉鎖できます。
閉鎖時には、保持されているイーサリアムが入札者に返還されるか、burnされるか、またはレジストラーを助ける行動の報酬として他者に送られます。

このディードシステムは、ENSのオークションが公正かつ透明に行われるための重要な仕組みの一つです。

返金スケジュール

ENS（イーサリアム・ネーム・サービス）の初期レジストラーコントラクトでのディード（Deed）閉鎖時の返金スケジュールを、以下の表でより分かりやすく説明します。

ディード閉鎖の理由	返金の受取人	返金率
有効な非勝利入札が公開された場合	入札者	99.5%
オークション期間後に提出された入札が公開された場合	入札者	99.5%
既に所有されている名前に対する有効な入札が公開された場合	入札者	0.5%
期限切れの封印入札がキャンセルされた場合	キャンセラー	0.5%
登録されたハッシュが無効と報告された場合（報告者）	報告者	50%
登録されたハッシュが無効と報告された場合（所有者）	所有者	50%

注釈

期限内に全ての入札が公開されるように促すために設けられています。遅れて公開すると、最高入札者に対する脅迫の可能性があります。
2週間5日を超えて封印されたままの入札は、誰でもキャンセルし、小さな報酬を受け取ることができます。
名前はオークションや登録前にハッシュ化されるため、初期レジストラーは文字長の制限を独立して強制することができません。無効な名前を報告するための報酬が提供されます。

デプロイメントとアップグレードプロセス

ENS（イーサリアム・ネーム・サービス）の初期レジストラーコントラクトの導入とアップグレードプロセスについて説明します。

初期レジストラーコントラクトの導入

初期レジストラーコントラクトは、ENS自体が展開された後に導入されます。
このコントラクトには、ENSのアドレスがコンストラクタ（構築時に必要なパラメータ）として必要です。
導入後、ENSのルートノードを管理するマルチシグアカウントが、.ethノードのオーナーとして初期レジストラーコントラクトのアドレスを設定します。

アップグレードプロセス

初期レジストラーコントラクトは、導入から約2年後に永続的なレジストラーコントラクトに置き換えられる予定です。
永続的なレジストラーコントラクトが導入された後、ENSのルートノードを管理するマルチシグアカウントは.ethノードの所有権を新しいレジストラーに移転します。
初期レジストラーにおけるハッシュの所有者は、自分のディード（ドメイン名の所有権証書）を新しいレジストラーに移転する責任があります。
移転方法としては、特定の期限までに移転を完了するか、新しいレジストラーが必要に応じて初期レジストラーから所有情報を参照することが考えられます。

このアップグレードプロセスは、ENSが進化し続けることを可能にし、より効率的で機能的なシステムを提供するために重要です。

計画的な活動停止

ENSの初期レジストラーコントラクトの段階的な非活性化について説明します。

初期レジストラーコントラクトは、導入から4年後に新しいオークションの受付を停止します。
これは、ENSシステムが初期のコントラクトから永続的なコントラクトへスムーズに移行するための措置です。

さらに、導入から8年後には、ディード（ドメイン名の所有権証書）に保管されている全てのイーサリアムがアクセス不可能になります。
これは、ENSが新しい技術や要件に柔軟に対応できるようにするための重要なステップです。

この計画的な非活性化は、ENSが進化し続け、持続可能な運用を確保するための鍵となります。

レジスターインターフェース

ENS（イーサリアム・ネーム・サービス）の初期レジストラーコントラクトには、以下のような重要なインターフェース機能が含まれています。

`state(bytes32 _hash)`

特定の名前（ハッシュ）の現在の状態（例えばオークション中、所有されているなど）を返す関数。

`entries(bytes32 _hash)`

登録された名前に関する詳細な情報を返す関数。
これには、その状態、ディード（所有権証書）のアドレス、登録日、ディードの残高、オークションでの最高入札額が含まれます。

`getAllowedTime(bytes32 _hash)`

特定のハッシュが「まだ利用できない」状態から移行する時刻を返す関数。

`isAllowed(bytes32 _hash, uint _timestamp)`

与えられたハッシュと時刻に基づいて、そのハッシュが初期の「まだ利用できない」状態を終えているか判断する関数。

`startAuction(bytes32 _hash)`

特定のハッシュの状態を「オープン」から「オークション」に移行する関数。
ただし、状態が「オープン」でなければエラーが発生します。

`startAuctions(bytes32[] _hashes)`

複数のハッシュに対してオークションを開始する関数。
これにより、実際に興味がある1つの名前のために、複数のダミーハッシュのオークションを開始することができます。

`shaBid(bytes32 hash, address owner, uint value, bytes32 salt)`

入札の詳細（ハッシュ、オーナー、価値、塩）を取り、オークションに参加するために必要な封印された入札ハッシュ値を生成する関数。

`newBid(bytes32 sealedBid)`

入札者は、封印された入札ハッシュと一定額のイーサリアムをメインコントラクトに送ります。
このハッシュには、入札されたドメイン名のハッシュ、入札額、ランダムなソルトが含まれています。
入札は公開されるまで特定のオークションには結びついていません。
実際の入札額より多くのイーサリアムを送ることで、入札額を隠すことができます。
公開期間は48時間で、この期間後に公開された入札は無効になり、イーサリアムは回収不可能です。

`startAuctionsAndBid(bytes32[] hashes, bytes32 sealedBid)`

複数のドメイン名に対してオークションを開始し、同時に新しい入札を行うことができるユーティリティ関数。

`unsealBid(bytes32 _hash, address _owner, uint _value, bytes32 _salt)`

入札期間終了後、入札の詳細を公開する関数。
レジストラーはこれらの情報をshaBid()関数でハッシュ化し、既存の封印された入札と一致するか確認します。
新しい最高入札が出た場合、以前の最高入札は入札者に返却されます。

`cancelBid(bytes32 seal)`

公開されていない入札を、返金スケジュールのルールに基づいてキャンセルする関数。

`finalizeAuction(bytes32 _hash)`

オークションが終了し、登録日を過ぎた後にオークションを最終化し、勝利した入札者をドメイン名の新しい所有者として設定する関数。

`transfer(bytes32 _hash, address newOwner)`

特定のドメイン名（ハッシュ）の所有者を新しい所有者に変更する関数。
この関数は、現在の所有者のみが呼び出すことができます。

`releaseDeed(bytes32 _hash)`

所有者がドメイン名の所有権を放棄し、保管していたイーサリアムを取り戻す関数。
これは、一定期間が経過した後に行うことができます。

`invalidateName(string unhashedName)`

名前が6文字以下の場合に、その名前を無効として報告する関数。
この報告が受理されると、報告者はそのドメイン名のディード価値の10%を報酬として受け取ります。
この機能は、レジストラーコントラクトを数年以内に再構築するために設計されています。

`eraseNode(bytes32[] labels)`

現在所有されていないドメイン名のサブドメインに関する所有者とリゾルバーのレコードを削除する関数。
例として、.ethのサブドメインfoo.bar.ethを削除するためには、[sha3('foo'), sha3('bar')]という配列を渡します。

`transferRegistrars(bytes32 _hash) onlyOwner(_hash)`

永続的なレジストラーへのアップグレードプロセス中に使用される関数。
このコントラクトがENSのルートノードの所有者でなくなった場合、ディードを現在の所有者（新しいレジストラー）に渡します。
もしまだルートノードの所有者である場合、エラーが発生します。

補足

ENS（イーサリアム・ネーム・サービス）の初期レジストラーコントラクトの導入について、もっとシンプルに説明します。

完璧なドメイン名割り当ての難しさ

ドメイン名割り当てに関する全ての問題を事前に予測して完璧な設計をするのは非現実的です。
そのため、ENSでは完璧を求めるのではなく、実際に運用しながら学び改善を加えるアプローチを採用しています。

7文字以上の名前の制限

最も短くて価値のあるドメイン名は、後にアップグレードされるレジストラーで使用するために保留されています。
これにより、将来的には紛争解決のプロセスを実装する機会があります。

名前の遅延リリース

ドメイン名のリリースをゆっくりと行うことで、開始後に発生する問題を特定し対応するための余裕を持てます。

TLDを`.eth`に限定

.ethという単一のTLDに焦点を当てることで、ネットワーク効果を最大化し、ユーザーの関心を集中させます。

3文字のTLDの利点

一般的なインターネットドメイン名における3文字のTLDのパターンを採用することで、ENSを既存のDNSシステムに統合しやすくし、特別な使用目的のドメイン名として予約する可能性を高めます。

イーサリアムを担保として保持するメリット

ドメイン名の所有権を維持するために定期的な支払いを要求する従来のモデルと異なり、イーサリアムを担保として保持することで、初期レジストラーを収益中立のサービスにしています。

このようなアプローチにより、ENSは進化し続けるブロックチェーン技術に柔軟に適応し、長期的な運用を目指しています。

先行研究

この文書は、ENS（イーサリアム・ネーム・サービス）についての知識を深めるために、複数の重要な情報源からの内容を集約しています。

EIP137

ENSの基本的な構造と機能、特にレジストリコントラクト（ENS.sol）とそれに関連するリゾルバーコントラクトの初期実装について説明しています。

ERC26

コントラクト層で動作するネームサービスを提案した最初の提案書です。
これは、ENSの基盤となるアイデアや概念を提供しています。

@alexvandesandeのハッシュレジストラー実装

ENSのドメイン名割り当てや管理に関する具体的な実装の例を提供しています。
この実装は、ENSの動作や使い方に関する実践的な理解を深めるのに役立ちます。

編集履歴

2016-10-26
- アレックスのデザインに関するリンクを文書の概要に追加しました。
2016-11-01
- 「計画的な非活性化」セクションの見出しを変更しました。
2017-03-13
- 入札と公開期間のタイムラインに関する情報を更新しました。

これらの情報源によって、ENSの全体的な設計や動作原理、さらには具体的な実装方法に関する包括的な理解が可能になります。

引用

Maurelian, Nick Johnson nick@ethereum.org, Alex Van de Sande avsa@ethereum.org, "ERC-162: Initial ENS Hash Registrar," Ethereum Improvement Proposals, no. 162, October 2016. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-162.

最後に

今回は「ENS（イーサリアム・ネーム・サービス）のコントラクトに関する提案している規格であるERC162」についてまとめてきました！
いかがだったでしょうか？

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

Twitter @cardene777

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

[ERC162] ENSのコントラクトの仕組みを理解しよう！