🫂

DID DHT(did:dht) レビュー

2024/01/18に公開

Bitcoin

did

tech

昨年11月に発表されたWeb5の新しいDIDメソッドDHTについてざっとウォークスルーする。

位置付け

DHTとは"Data Hash Table"のイニシャル
DHTを利用した分散DNSに、DIDを載せるものである。
Web5はBitcoinにアンカリングしIPFSにDID Documentを永続するdid:ionが主だったが、did:dhtはBitTorrentを永続層にする。ただし、did:dhtもBitcoinを利用するにはする（後述）
スペック策定者(decentralgabe)によると、95%のユースケースはdid:dhtでカバーでき、残り5%がdid:ionになるとのこと。

DID DHTの概要

DIDメソッドは多種多様である。公開鍵をそのままidentifierにするdid:keyのようなもの、webのドメインをラップするdid:webのようなもの、伝播をP2Pに行うことを企図したdid:peer系のものなどある。一方で、もっとも多そうなタイプがなにかしらのデータレジストリを持ちエンドポイントを解決して各種メソッドを実行するサーバを立てる形式である。

did:dhtもdid:ionもそのようなサーバを持つ型だが、データレジストリが変わることにより、did:dhtはスケーリングを最重要にしてdid:ionは一貫性を取っている（*1）という特徴に分かれる。これが上記の95%のユースケースはdid:dhtでカバーでき、残り5%がdid:ionになる背景である。

did:dhtは、DNSをP2Pネットワークに載せることを企図してBitTorrentのMainline DHTを使用するPkarrをDID仕様に合わせたものと言ってよさそうである。Mainline DHTのwikipediaによると2013年時点で同時ユーザー数が2,700万人という実績らしい。またdid:dhtスペックにはノード数が1,000万台と書かれている。

(*1)そのわりに一貫性についてもIPFS側を突くことで破られうるという指摘もあるが、アンカリングの頻度およびWebサービス側でのバリデーションも手が取れるなどの理由をもって実用上は問題ないという話もある。けっきょくのところこの手の話は最終的には確率論になることもありここではいったん脇におく。

Pkarrとは

Pkarrは以下を目的としてrustで書かれた分散DNSの概念実証である。

DNSとP2Pネットワーク間の最もシンプルで合理的な統合により、自己発行した公開鍵が主権のあるパブリックでアドレス指定可能なドメインとして機能できるようになります。このシステムは、秘密鍵を管理できる人であれば誰でも利用できます。

要は、公開鍵をドメインネームにして、そのアドレス解決をBitTorrentが供給する（DNSサーバ）という話である。

READMEではデモとしてhttps://o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy/のURLが示されている。o4以下が公開鍵である。しかし、これは単にmarkdownの表記テキストであることに注意で、ハイパーリンクされている実際のURLはhttps://app.pkarr.org/?pk=o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyyになる。目指している姿がそうだということだろう（PkarrのリレーサーバをDNS proxyにすることで名前解決できるしネットワークの機器たちが対応すれば可能になる）。

そのURLにアクセスしたレスポンスが下記の画面である。

o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyyの公開鍵に紐づいているDNSレコードが表示されている。DNSレコードはmatrixのユーザーIDが値となっている。matrixも分散SNSの位置付けになるのでこのデモが何を示したいのかいまいちピンとこないのだが(*2)、nameとvalueをDNSのTXTレコードに置き換えると腹落ちする。ドメインの所有者情報を権威DNSサーバー抜きに、また、SSL証明書をCA（証明局）抜きに、できるようになるのである。

現状はここまでだが、もっと頑張れば上記のhttps://o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy/もできるようになるよというイメージだと思う。そして、did:o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyyのURIで解決できるようにするのがdid:dhtということになる。

このようなDNSを分散化させるものはGNU Name SystemやBitcoin上のnamecoinのように先例はあるが、Pkarrはシンプルな仕様やBitTorrentを用いた同時アクセス数のスケーリングが売りになるだろうか。

(*2)Mastdonのようにインスタンスを超えたアカウントの連携なり引越しのためのmatrixの各鯖間のユニバーサルレジストリが作れるよと示しているのかもしれない。

DID DHTの詳細

2024/1/9更新の「The DID DHT Method Specification 1.0」からPkarrの拡張箇所を中心にピックアップする。DID core仕様に沿った定義箇所は割愛する。（identifier形式や、鍵生成や署名方式、DID Documentのプロパティなどなど）

DIDをDNSレコードにする

DID DocumentをDNSレコードにマッピングしている。

これをBitTorrentのBEP-44に則ったデータにエンコーディングしてBitTorrentに書き込む。did:dht→Pkarrの方向は互換があり、Pkarrリレーサーバにも書き込める。

ゲートウェイ

did:dhtはBitTorrentとdid層の二階建てとなる。BitTorrentのMainline DHTをSSOT（Single Source of Truth）と静的データのREAD先（did層を通さずに直接読み取るルート）として解釈して良いと思うが、didは署名などの各種メソッドの実行なども用意されるし、DHTはデータ永続を保証するわけでないのでキャッシングの場所を用意しさらなるスケーリングを可能にするため、did:dht側でもネットワークを形成する。

このゲートウェイサーバはAPIこそ定義されているがその構成は自由である。Mainline DHTがSSOTのためゲートウェイサーバ間の同期も必須ではない。むしろWeb側で更なるスケーリングを行うために、ネットワークベンダーやクラウドベンダーなどに開かれた領域と考えるのが妥当と考える。

なお、did:ionはこのゲートウェイサーバに該当するところも内部の仕様設計が相当な範囲で定められていて、ゲートウェイサーバ間の同期が行われるものとなっている。

スパム対策

ゲートウェイは大量のリクエストにさらされる可能性があるので、クライアントからのWriteアクションにはクライアントの一定のリソース消費を要求する"Proof Of Work"の仕組みがオプションで定められている。Bitcoinのマイニングというか、その元となっているアダム・バックのeメールの"Proof Of Work"のアイディアとほぼほぼ同じハッシュ値の計算となる。つまり、競争や報酬はなく、ただただクライアントにリソース消費を強いているだけである。Readアクションの対策は特に定められていないが、一般的なSRE(Site Reliability Engineering)を自由にやれということだと解釈する。

ゲートウェイレジストリにBitcoinを利用する

ゲートウェイレジストリは、クライアントがゲートウェイを発見するためのアドレス帳である。BitcoinにおけるDNSシードの役割と解釈して良いと思う。

「The DID DHT Method Specification 1.0」ではどんなストアを使うかは抽象化されているが、レジストリの仕様書にBitcoinを使用するパターンが記載されている。

登録されたゲートウェイであり続けたいなら、"proof-of-legitimacy"と呼んでいる、Bitcoinにkeep-aliveとしてのtxを前回期限後の10ブロック以内に発行し続けることになる。クライアントはBitcoinをクエリすることで、現在「アクティブ」なゲートウェイリストを入手できる。登録されたゲートウェイになるインセンティブが不明であるが、Web5はこれで実装しているとのことである。

結論

いかがでしたか？did:dhtとは、ブラウザのアドレスバーやネイティブアプリのIP通信でDIDが動作できるようにする第一歩として、DIDを分散DNSにフュージョンしたものです。この記事はけっきょくのところ私自身が理解を深める動機が第一なのでよくわからなかったかもしれません。そのため、ぱっと見でわかる図表を最後に用意しました。

did:dhtはゴテンクスです。