ENS関連の一連のコントラクトを公式にデプロイする
Opened this issue · 10 comments
ENSはDiscordの#dev_tasklistチャンネルにて中断中とのことですが、お手伝いできることはあるでしょうか？
ENSのデプロイはできると思いますが、使用可能にするにはENSの運用仕様を決める必要があるの頓挫しています。
決めなければいけないルールを挙げると、以下のようなものがあります。
①ENSの登録ルールをどうするのか（オークション？先願制？）
②当面のドメイン管理をだれが行うのか？（不具合）
③名前空間の大量取得問題にどう対処するのか。
先願性ならばFIFSレジスタというものが使えますが、これだと大量取得に対する耐性がありません。FIFSレジスタを使うならば、ドメインの有効期限を設ける方式を組み合わせる必要があるかと思います。
今の状況で実装できるのは、以下のような複合的なドメインシステムだと思います。
root 所有者管理、手作業登録
+dev 所有者管理、手作業登録。開発専用
+fifs001 無期限先願性。コントラクト。一般向け。
+nuko 期間付き コントラクト登録。一般向け。
rootの所有権を放棄しないのは、ルートドメイン下にサブドメインを作れるようにするためです。
dev,fifs1については、現状でも実装ができると思います。サブドメインに機械的な名前を作ることで、ドメインの価値を落としているのがポイントです。しかし、大量取得に対する十分な耐性があるわけではありません。
nukoは所有期間をNUKOを対価に得る方式ですが、新たな仕様とコントラクトの実装が不可欠です。期間に対する価格を操作することで大量取得耐性を狙いますが、有効期限が切れたドメインの扱いにセキュリティの問題があります。
ENSの構造上、親ドメインを無効にしても下位のサブドメインは即時に無効にならないようです。
親ドメインの上の親ドメインがサブドメインを上書きするまでは有効性が保たれます。
期限付きのドメインを導入した場合、アプリケーション側で対処しないと期限を超過した名前を引けてしまう問題が発生します。その辺も考慮してサービス全体を作る必要があります。
root 手動管理、一般登録不可、オーナーはアカウント
+ dev 期限付き、一般登録自由、オーナーはコントラクトTestRegistrar
+ fifs 先願性登録、一般登録自由、オーナーはコントラクトFIFSRegistraar
+ nuko 手動管理、一般登録募集、オーナーはアカウント
nukoは大量取得問題が解決できるまで手動で登録します。管理は私がします。
fifsの代わりにkarikarigohanとかどうでしょう、長いので人気でなさそうです
最近になってENSについて詳しく調べてみたのですが、てばさきさんのおっしゃったように
親ドメインが無効化されても、子ドメインはいつまでも名前解決できてしまうという"仕様"
はひどいですね。分散化を気にしているためか、ある程度登録ドメインが増えると管理がほぼ不可能になるようなシステムなので
言い出しっぺで悪いのですが、このシステムはあまり真面目に受け取らずEthereumのまねをしたかったということで、大手Nekoniumサービス用にnukoドメインのサブドメインを受け渡してそのまま放置でもいいかと思いました。
万が一失敗してもNekonium自体が実験用途なので、ENSRegistryを新しくデプロイしてそれに移行してしまえばいいですし。
そんなこんなで、てばさきさんのnukoドメインのように新しくRegistrarを作るなら、ドメインの親子関係が保存される仕様のNNS(Nekonium Naming Service)として一から新しいシステムを作ったほうがいいかと思います。
了解しました。
rootの管理はお任せします。ただし、期限つきは管理が煩雑になりそうなので、とりあえずはすべて期限なしFIFSにすることを希望します。また、以前提案していただいた、一般登録可能な任意名サブドメイン多数用意することで、サブドメインの価値を低下させるようにお願いします。
ドメインツリーは以下のようになるとおもいます。
+root 管理者所有/手動管理/管理者がサブドメインを登録する。
|+dev 管理者所有/手動管理/管理者が開発者名を手動登録する。
|+任意名サブドメイン(hokahokagohan他) コントラクト管理 無期限FIFS/一般向け/登録はコントラクト任せ
任意名サブドメインに登録できる文字数は制御できると理想的です。
まずはdevを登録して、開発チーム数名のENS参照が可能な状態を作ってみてはいかがでしょうか。
具体的にこんな感じですね
- root
- dev
- kabayaki
- ...
- hokahokagohan
- (自由に登録可能...)
- retorutogohan
- (自由に登録可能...)
- (その他FIFS)
- dev
- reverse
- addr
- (コントラクトReverseRegistrar)
- addr
とりあえずテストで開発者用のドメイン登録の募集を開始したいと思います。
addr.reverseがあることを忘れていました。これはmist用です。
アドレスの所有をclaimでき、そのアドレスとリゾルバをつなげることで、リゾルバからそのアドレスのドメイン名が取得できるコントラクトが紐付けられています。
逆引きができるようになる仕組みのようです。
これも公開したいと思っています。
任意名のサブドメインの文字数を規制するのはなぜでしょうか？
内部ではどの文字列でもハッシュを取られて一定のサイズになるので、比例したストレージサイズを必要とすることはありません。
ドメインを利用する際に悪い影響が出るのは、取得者とその利用者が扱いづらい、ということのみだと思います。
文字数を規制する必要はないのではないでしょうか？
文字列長制限を提案した理由は、以下の２つからです。
１．登録文字列をそのままレジストラに送信した場合、トランザクションサイズが無限に大きくなる可能性がある。
２．長すぎる文字列は、ユーザーインタフェイスで表示するのが難しい。
１については、ご指摘通り、文字列をそのまま送信しないFIFSレジストラでは問題ありません。
FIFSレジスタで影響が出ると思ったのは私の勘違いでした。
うろ覚えで申し訳ないのですが、Hashレジストラの場合は文字列を送信してコストを計算するような処理があったと思うので、この問題が発生すると思います。
２については、コントラクト側の問題ではなく、フロントエンドの実装で問題になる部分です。
視認性と安全性から、文字列長のガイドラインを設けるべきだと考えています。
ガイドラインとして次の二つがあると、ユーザーインタフェイスが実装しやすくなります。
１．ENS検索で扱えなければならない最低文字数。
２．ユーザーインタフェイスは、その最低値を超えるENS文字列を取り扱えなくてよい。
最低文字数は、サブドメイン単位ではなく、ドメイン文字列全体の長さの方が簡単だとおもいます。
結論として、以下の２点を再提案します。
１．FIFSコントラクトでの文字列制限は必要なし（できない）。
２．登録、参照インタフェイス向けのガイドラインを設ける。
最後に、ドメインツリーは良いと思います。
募集要項などをこのリポジトリで公開したい場合は、/pr配下に記事を作る場所があります。そこを使ってください。
ブロックにはガス上限があるので、どれだけ長い文字列のハッシュ計算を行おうとしても途中でガス欠になりトランザクションの実行は失敗します。
更に文字列が大きくなるとトランザクション自体のサイズが大きくなり、それによってもガスが必要になります。
これらによりトランザクションが無限に大きくなることはないのでHashレジストラでも問題ないと思います。
調べたところDNSは最大で253文字、一般に利用されているTLDでは63文字となっているようです。
どちらかを採用するのがいいかもしれません。
PRの方了解しました。開発者の方がもっと集まって欲しいですね。
なるほど。ブロックのガス上限を忘れてました。
個人的には、送信されるトランザクションは短いほうが好ましいと考えています。そのため、出来るだけ規格外（標準的な使途に使われないような）に大きなトランザクションを送信したくなるような制約を予め入れたいです。
とりあえずは、（実際の意味がないのは承知で）63文字を推します。
ENSの構造
- root
- dev
- (一般登録募集、デベロッパーである必要有り)
- karikarigohan
- (一般FIFS登録)
- retorutogohan
- (一般FIFS登録)
- (その他長い名前は一般FIFS登録)
- reverse
- addr
- (アドレスの所有権を主張できる)
- addr
- dev
注
ENSを利用するアプリケーションは、ドメイン全体のASCII文字列の長さが63以下で動作を保証する必要がある
こんな感じで行こうと思います。
上記がDiscordの方でてばさきさんの了解が得られたため、このissueをクローズします。
以下引用です。
#dev
かばやき - 昨日 午後5時8分
ENSはissueにあるような感じでいいでしょうか？
てばさき - 昨日 午後11時21分
はい。ばっちりです。ただ、いつからうぉれっとにくみこんでゆくかはまた相談でお願いします。
ENSRegistryはすでにメインネットワークにデプロイしてありますので、以下にそのアドレスを公開します。
0x331414dc3f6af20c74433db88ca76e2bfe5240f7
Ethereumの方では円周率の日にデプロイされているからか、0x31415...のようなアドレスにデプロイされていますが、
最初の何桁かで正式なアドレスと見られてしまうのは、アドレスは違うのに、最初の数桁で本物だと利用者が勘違いしてしまう、不正なコントラクトを公式のように偽装できてしまう可能性があると考えたので、通常のアドレスにデプロイしました。
(最初の数桁がちょっと円周率っぽいのは偶然です。)
ネットワークにデプロイしたアドレスを取り違えていました。
上記のアドレス0x331414dc3f6af20c74433db88ca76e2bfe5240f7はネコニウムネットワーク上に存在しません。（Ropstenには存在します）
正しいアドレスは現在調査中です。