この記事は武田信玄@孤高の城主さんに寄稿していただいたものです
Handshakeは現状Internetを利用する上で大きく依存しているDNSに対して、非中央集権的な構造を組み込もうとするプロジェクトです。
彼等は既存DNSを置き換える訳ではなく共存を目指しているのですが、具体的にはどういう形で共存していくのでしょうか？
とは言ってもDNSの世界は広大です。ですので今回の議題は主にドメインの扱いについて考察します。
現時点では公開されている情報も少なく目的達成の為の手法も不明ではあるのですが、私が得られた範囲で理解に必要なDNSの仕組みを解説しながら書いて行きます。
もしも認識の誤り等を見つけた際にはご指摘いただけると幸いです。
尚、Crypto的な視点で既存DNSとの差別化を捉えるのであればHandshakeの特徴は下記の通りとなります。詳細な説明は追って進めていきます。
- Top Level Domainを自由に登録出来る上に、第三者の意思で勝手に抹消される事がない
- 端末側から直接Handshake Root Server (Full Node)を参照する事により間に余計なResolverを挟まない。これによりPoisoningのリスクや、第三者によるブロックを回避する
ドメインネームの種類と構造
ドメインネームとはIPアドレスを人間が理解しやすい文字列に変換したものです。ですので例えばGoogle.comの代わりにドメインネームが指すIPを入力しても機能します(ドメイン以外のフォルダ、ファイル的な指定はまた別ですが)
そしてドメインは階層的な構造で管理や用途が区別されています。
具体例を上げればGmailは “mail.google.com”で、Google Calendarは“calendar.google.com”といった形です。
ドメインネームを簡単に図解すると下記の様になります。
大きく分けてドメインは三段階になっています。
Top Level Domain (TLD)
ドメインネームの末尾に来る箇所です。上記であれば.comがそれにあたります。
他には.orgや.io、各国に対応した.jpや.us等様々なTLDがあります。
Second Level Domain (SLD)
基本的には組織を表しますが、そういった区分もTLDによりけりです。
例えば.jpのTLD配下であれば.coは日本に所在地を置く会社を表す等です。
またSLD以下の管理はTLDの保持者が行います。
Subdomain
SLDと同様、これも用途は様々です。Googleの例で言えばサービスを表しています。
Root ServerとTop Level Domain(TLD)について
TLDがドメインの肝になり、それを管理するのがRoot Serverです。またRoot Server達をまとめてRoot Zoneと呼びます。
Root Serverは下記の通り現在13に分かれており“そこそこ”分散されています。※実は過半数がUnited Statesで日本は何とか一つだけ入っている様な状態です
TLDを管理するのはRoot Server達ですので、仮に未使用のTLDを使いたくてもRoot Serverがそれを載せてくれなければ参照されないという事になります。
また不適切だと判定されたドメインが特定の箇所でブロックされたり、Root側から抹消される事もあります。
通常、端末(PCやスマフォ等)からはRoot Serverを毎度直接参照せず、基本的には中継役となるResolverへ問い合わせを行います。詳細は後述しますが、ここの仕組みについては通常の流れとHandshake配下のTLDへの問い合わせは少し違った形になるでしょう。
Handshakeは将来的にICANNのRoot Serverに互換性をもった存在になる事を目指しており、Handshakeが管理する事になるTLDをNamebaseというプラットフォームで販売する予定です。この目標については詳細が明言されていないものの、既存のICANNが直接管理するRoot Serverを置き換えるという事は流石に無いと思います。よって、既存のRoot Serverが持つ機能を併せ持つという様な意味合いで捉えた方が良いでしょう。
下の図で左側は既存の形、右側はHandshakeをイメージして管理するドメインの違いを表しています。
左側：既存のTLDを全体統括するのはICANNという非営利団体であり、.comのTLDを管理するのはVerisignです。
右側：HandshakeがRoot ServerとなりNamebaseがTLDの売買を管理します。
ちなみにHandshake側もAlexa RankingのTop100000ドメインまでは予約した状態にしています。では”予約”とはどういう意味でしょうか？
予約されたドメインの保持者はNamebaseのオークションというプロセスを行う事無く、一定条件を満たせばBlockchain上で登録する事が出来るとの事です。なのでもしも大半のドメインがHandshake側にも登録してくれれば便利なものになります。
Namebaseとは
NamebaseはHandshake上で稼働するドメインを売買するサービスです。
HandshakeのWPによればTLDの売買はスマートコントラクト上で行われる為、Namebaseは専用DEXの様なものになるのではないでしょうか。現状判明している事は下記の通りです。
- Handshake Coin (HNS)の売買を行う
- TLDの売買を行う(Vickrey Auction形式)
- TLD保持者はSLDの売買と管理を行う
それぞれについて簡単に説明します。
Handshake Coin (HNS)は開発報酬や配布、マイニング報酬やドメインの売買に使われるものです。
ICOは無く、大半はOpen Source Communityへ配布されます。
ちなみに出資しているVCや個人は錚々たる面々でした。DNSやCAの重要性と問題を認識している界隈の人達が多いという事でしょう。
Namebaseでのネーミングマーケットはオークション形式で売買されます。
ここではVickrey Auctionと呼ばれる二位価格封印入札方式が採用されており、互いに入札価格が見えない中で入札し、落札するのは勿論一番高い価格を提示した参加者ですが、実際の落札価格は二番目の価格になるというものです。
余談ですがこれをスマートコントラクトで実現するのは結構難しいらしく、実装に苦労したとWPに書いてありました。
TLDの管理者はSLDの売買を行い収益を得る事が出来るそうです。
これについてはENSの売買をイメージすると良いでしょう。つまりENS運営＝.ethのTLD保持者というイメージですね。
ENSを例えに出すと混乱しやすいところですが、.ethは現状Root Server上に存在しません。あくまでもETHネットワーク上のものなのです。
それでもTLDとSLD的な仕組みはほぼ同じです。紐付けられるのがIPアドレスでなくETHアドレスであるという違いです。
ENSを見ると想像に難くありませんが、人気のあるTLDを取得すればそれだけで大きな収入源になる可能性を持つという事でしょう。
DNSの処理や中継を行う "Resolver"とは
Root ZoneのRoot Server達は実際のところ13台しかないという事はなく冗長化、分散化されています。
しかしそれでも世界中からの要求をRoot Serverだけでは捌き切れない上に性能的な問題もあります。
そこで登場するのがFull ResolverもしくはRecurcive Resolverです。各所からDNSの情報を集めて保存(Cache)しながら要求に応じて回答します。
インターネットサービスプロバイダが持つ物もありますし、Google Public DNS(8.8.8.8 / 8.8.4.4) やCloudflare DNS Resolver(1.1.1.1 / 1.0.0.1)の物もあります。
もう少し踏み込んで説明をすると、端末側が内蔵する内部のDNS処理を行うのがStub Resolver、参照する中継先がRecursive ResolverもしくはFull Resolverとなります。
下の図では既存のDNS利用と、Handshakeのものを並べたものです。左側が既存の方で右側がHandshakeになります。もう一度整理すると
- Stub Resolverは端末が内蔵するDNSの処理を行うシステム
- Full ResolverもしくはRecursive Resolverは中継役としてDNS情報をキャッシュしつつ問い合わせを行ったり回答するシステム
- 大本のドメインネーム達を管理しているのがRoot Server
上の図を見た通りHandshakeを使う為には既存の外部Resolverを使えません。何故なら彼らはHandshakeのRoot Serverを見に行かないからです。よって、端末側で直接HandshakeのRoot Serverを見に行く様に設定する必要が出てくる訳です。
これは利便性を損なう仕組みではありますが、同時にセキュリティが高い仕組みとも言えます。
HandshakeのRoot Serverは普及するのか？
実はここが一番の難問だと考えられます。HandshakeのWPによるとICANNのRoot Serverと互換性をもたせる事が出来ると書いてありますし、ICANNは非営利団体なので賛同を得られる可能性も無くはないですが実際はどうなんだろうというところです。
記載も曖昧なのでHandshakeが独立したRoot Serverになるという意味なのか、ICANNが動かしているRoot Serverと置き換わるつもりなのかも解りません。
基本的に後者はほぼありえないと考えられる為、前者の独立したRoot Serverとなる線が濃厚だと思っています。
HandshakeのWPではMac OSを含むUnix baseのOSに対して、HandshakeのRoot ServerからDNS情報を引き出す様に出来る設定方法が書いてあります。
もう一つの方法はBrowserでNamebase Handshake Extensionを使う方法です(ただし2018年9月14日現在はまだTestnetです)
とは言えどちらにしろ一般に向けて普及する様な方法とは言えないところです。
単純な利便性が低いとしたらHandshakeが普及するか否かは強い需要次第では無いでしょうか。例えば社会からCryptoが排除される方向に向かうとか、もしくはMEWの偽サイト誘導事件の様なケースが増える等です。
利用者が自分の資産を守るためにHandshakeを利用する、というのが正しい需要と供給の姿だと言えるかもしれません。
DNSを対象にした類似プロジェクト
Handshakeの注目度から考えれば、同じ事を目指すプロジェクトが他にも無い筈がありません。
実際には2つのプロジェクトがある程度類似した機能を提供しています。
Namecoin
かなり古くからあるプロジェクトで現在はあまり名前を聞きませんが、開発は一応続いている様です。
(実は最初にBitcoinからForkしたコインだそうで、古参の人には有名でした)
Namecoinが提供するのは .bit というTLDですので、利用可能なのは.bit配下のSLDが使えるという事になります。
Full nodeがResolverとして機能し、Client側は専用ソフトを入れる事で利用が可能です。
Emercoin
知名度はそこまで高くないのですが、実はパートナーにMicrosoftやDeloitte等かなり豪華です。
様々な機能を提供しており、DNSはあくまでも機能の一部として”EmerDNS"という名前で提供されています。
提供するTLDは .coin .emc .lib .bazar です。
利用側はBrowser ExtensionやOpenNIC、専用Proxy等色々な手段があります。結構悪くない様に見えました。
次にBlockchain上でのみ機能するドメインとしては下記の2つを確認しました。
ENS
こちらは非常に有名だと思います。これはEthereum上でのみ動作する .ethのTLD配下SLDを売買するプラットフォームです。
EOS
実はEOSにもドメインオークションが存在します。プレミアムアカウントという物で、サブドメインを作る事が出来るそうです。
現在のオークションはこちらから確認できます
余談ですがHandshake側でも将来的にPlasmaと繋いでBlockchain側にもDNSの機能を提供する計画があるそうです。
