今日、インターネットは世界中を覆い、数十億のデバイスを接続する巨大なネットワークに発展し、生産生活にとって非常に重要な通信タスクを担っています。遠く離れた、互いに知らない 2 つのノードが信頼でき、確実に通信できるようにするために、インターネットは相応のインフラを提供しています。ネットワーク層からアプリケーション層まで、最も重要なインフラは 3 つあり、図 1に示されています。
・ボーダーゲートウェイプロトコル（BGP）は、IP アドレスプレフィックスを自律システムおよびドメイン間トポロジに関連付け、ドメイン間ルーティングを計算することにより、グローバルインターネットの基本的な接続性を実現しています。
・ドメインネームシステム（DNS）は、ドメイン名を IP アドレスにマッピングすることにより、アプリケーション層のサービス名とネットワーク層のアドレスを関連付け、サービスがネットワーク内でアクセスできるようにします。
・公開鍵基盤（PKI）は、企業のアイデンティティ情報やその他の情報を公開鍵に関連付けることにより、ネットワーク通信エンティティと現実世界の実際のアイデンティティを関連付け、通信を信頼できるものにします。
現在、これらのインフラやその背後に依存する安全で信頼できるシステムは、（a）に示されるような中央集権的な設計を採用しています。この設計の基本原理は、単一の信頼できるルートノードがシステム全体の信頼のアンカーポイントであり、中間層の信頼できるノードを「背書」し、中間層ノードがさらに葉ノードを「背書」することで、信頼関係がルートから葉に伝達されるというものです。BGP を例にとると、BGP 自体は分散型プロトコルですが、その信頼の基盤はリソース公開鍵基盤（RPKI）であり、BGP アドレスプレフィックスの宣言の合法性を検証し、BGP の安全性を確保します。RPKI は中央集権的で階層的な機関を採用しており、RPKI のシステム設計の具体的な紹介は（b）に示されています。RPKI は IANA をルートノードとし、世界の 5 つの地域の RIR を第 2 層ノードとし、下には国の NIR ノードが含まれる可能性があり、各オペレーターが葉ノードとなります。RPKI のトップダウンの信頼関係は、段階的に発行されるリソース証明書（RC）によって支えられ、RC は特定のノードが特定の IP アドレスプレフィックスの所有権を宣言するために使用されます。最終的に、リソース証明書を持つ葉ノードは、ルートオリジン認証（ROA）を発行することにより、特定の自律システム（AS）番号を許可し、その AS が発信する BGP メッセージ内でそのノードが保持する IP アドレスプレフィックスを宣言できるようにします。それに応じて、BGP ルーターは BGP メッセージを受信した後、PRKI によって形成された証明書チェーンを利用して BGP プレフィックス宣言の合法性を検証できます。同様に、DNS システムもルートサーバーを中心とした階層型システムであり、各レベルのトップレベルドメインサーバーが中間ノード、権威あるドメインサーバーが葉ノードとなります。DNS システムの安全拡張である DNSSEC も、DNS のシステム構造に依存しており、上から下への段階的な公開鍵の背書と署名を行い、その基本的な安全原理は依然として中央集権的です。また、PKI システムも同様に中央ルートノードを持つ階層構造を採用しています。
このような中央集権的なシステムにはいくつかの根本的な問題があります。このようなシステムでは、中央集権的な権威ノードがシステムの信頼のアンカーポイントであり、その権限が過大であり、単独で証明書やデジタル署名を取り消すことにより、後続ノードに対する信頼の背書を取り消したり、虚偽のノードに信任を与えたりすることができ、実際のノードの利益を損なう可能性があります。これらのインフラはグローバルなものであるため、中央ノードの悪意のある操作がもたらす悪影響は全世界的なものです。たとえば、中央ノードは他国のノードに対して信頼の背書を行ったり、信任を取り消したり、虚偽のノードに信任を与えたりすることができ、他国の信頼できるサービスに破壊的な影響を与える可能性があります。これらの中央権威ノードには、ハッカーに制御されたり、管理者の誤設定によってさまざまな理由でそのような操作を行う可能性があります。中央ノードは完全に中立であることができない場合もあり、利益相反、政治的または法的理由から偏見が存在する可能性があります。以下に、現実において前述の中央集権的な構造によって引き起こされたセキュリティ事件のいくつかを示します。
分散型台帳層は、名前空間管理層に去中心化の基盤能力を提供し、主に去中心化の基盤プラットフォームの構築に焦点を当てています。名前空間管理層は、分散型台帳層が提供する基盤プラットフォーム上で、インターネットの名前空間の去中心化を実現します。同時に、これらの名前空間に依存するアプリケーション層のアプリに信頼できる基盤を提供し、ユーザーのビジネスにより近いアプリ開発を実現します。
近年、ブロックチェーンを代表とする分散型台帳技術が急速に発展しています。しかし、分散型台帳のより重要な価値は、去中心化のプラットフォームとして、去中心化のネットワークアプリケーションをサポートすることです。D は分散型台帳の以下の能力を利用して、去中心化のインターネット基盤インフラを構築します。
(1) 去中心化のシステム構造 システム内に恒常的な特権ノードは存在せず（特定の期間内に一部のノードがより大きな権限を持つことがあっても、そのノードが特権を悪用した場合は他のノードに置き換えられる）、長期的にはすべてのノードの地位は平等です。これは去中心化インターネット基盤インフラの信頼モデルに合致します。
(2) 分散型合意メカニズム これは分散型台帳技術の核心であり、すべてのノードが去中心化のメカニズムを用いて合意に達します。D は合意メカニズムを必要とし、インターネットの名前空間などのネットワークリソースのすべての権利の唯一性および関連アプリケーションの一貫性を実現します。
(3) スマートコントラクト 分散型台帳上で動作する計算環境であり、高度なスマートコントラクトはチューリング完全な計算モデルをサポートし、理論的には任意のアプリケーションをサポートします。D はインターネットの名前空間の管理に複雑なロジックを必要とし、オープンなアプリケーション層は任意のアプリケーションプログラムを支える必要があるため、スマートコントラクト技術が必要です。
(4) 信頼できる取引の能力 各アカウント間で取引を通じて相互に送金でき、これにより分散型台帳の内在的な価値伝達能力が与えられます。この能力を利用することで、第三者の開発者に技術プラットフォームを提供するだけでなく、技術の現金化能力も提供できます。
3.1 D 川の分散型台帳に対する技術的要求 現在の分散型台帳は主に 2 つのカテゴリに分かれます：パブリックチェーンとコンソーシアムチェーンですが、これら 2 つの分散型台帳にはそれぞれ問題があり、D システムに直接使用することはできません。パブリックチェーンはビットコインやイーサリアムを代表とし、パブリックインターネット上で動作し、任意のノードが参加できるように開放されていますが、参加ノードに対する制限がないため、ノードの数が非常に多く、システムが過度に露出し、結果としてシステムの合意効率が低下し、悪意のある攻撃が頻発します。
インターネットの核心リソース（IP アドレス、ASN、ドメイン名など）の管理プラットフォームとして、安全の観点から、誰もが無制限に参加できることは望ましくありません。また、ニーズの観点からも、誰もが核心リソースを申請する必要があるわけではありません（たとえば、SP や大規模な組織のみが大きなアドレスの申請を必要とします）。
パブリックチェーンは上記の要件を満たしていません。コンソーシアムチェーンはハイパーレッジャーを代表とし、一般的にローカルネットワークで動作し、認証されたノードのみが参加でき、ノードの数は少なくなります。パブリックチェーンと比較して、コンソーシアムチェーンはより高いパフォーマンスとより良いセキュリティを持ち、問題が発生した場合でも認証チャネルを通じて責任を追及し、解決することができます。しかし、コンソーシアムチェーン技術は D に直接適用することが難しいです。これは、D がグローバルインターネットの基盤インフラであるため、参加するノードの数が非常に多いからです。また、現在のコンソーシアムチェーンは静的に構成された参加リストに依存しており、大規模なシステムの動的性に適応することが難しいです。たとえば、ハイパーレッジャーは手動で静的にノードリストを構成する必要があり、リストの更新にはシステムの再起動が必要であり、中央集権的な管理構成を引き起こす可能性があります。
3.2 アクセス制御メカニズム 現在のパブリックチェーンにはアクセスメカニズムがありませんが、非常に良い動的性を持ち、ノードは動的に参加およびオフラインできます。一方、コンソーシアムチェーンにはアクセスメカニズムがありますが、システムの拡張性は一般的に低く、収容できるノード数は限られています。資格のある組織（たとえば、オペレーター、企業、大学など）のみが動的にシステムに参加し、リソースを申請できるようにするために、背書アクセスメカニズムと動的ノード管理を同時に実現するメカニズムを簡単に示します。このメカニズムは、D 川システム内の既存の背書ノードが新しいノードを背書したり、背書を停止したりすることを許可し、ノードの参加と離脱を実現します。
このメカニズムの基本原理は図 4 に示されています。D 川システムの初期化時には、背書者（endorser）リストがあり、このリストには D システム内で背書能力を持つノードの情報が記録されています。すべての参加ノードは、1 つ以上の背書者の背書を通じてのみシステムに参加することが許可されます。図 4 では、各地域のインターネット登録センター RIR（AFRINIC、APNIC、ARIN、LACNIC、RIPE NCC）および各国の登録センター NIR（CNNIC、JPNIC など）が背書機関として機能し、少なくとも 1 つの背書機関に認証された組織のみが D 川に参加する資格を持ち、そのアカウント情報がスマートコントラクトによって管理される参加ノードリストに書き込まれます。実際の使用において、このリストの初期化はオフラインでのコミュニケーションと協議を通じて決定されます。背書機関のリストも増減可能であり、背書機関同士の投票によって決定されます。具体的な参加プロセスは以下の通りです。
(1) ある NSPX が D システムに参加したい場合、X はまずローカルで D システムのブロックチェーンクライアントをダウンロードし、自分のアカウント（account）とノード識別子（node ID）を生成する必要があります。
(2) X はオフラインの方法である背書者に背書を申請し、自分の情報（D デバイスの IP アドレス情報、X のアカウントおよびノード識別子）を背書者 A に送信します。同時に、X はオフラインの方法で背書者 A の関連情報（そのアイデンティティを証明できる公開鍵など）を取得する必要があります。
(3) 背書者 A は D1 システム内で背書取引を開始し、X のノード識別子情報をブロックチェーンの背書リスト（endorsement list）に書き込みます。背書リストには、現在のシステム内のすべてのノードの背書情報が保存されます。
(4) 背書者 A は X に提供された IP アドレスにノード問い合わせ（ping node）メッセージを送信し、その背書申請が確かに X によって発起されたことを確認します。ノード問い合わせメッセージには、A の署名も含まれており、X は A のアイデンティティを検証するために使用します。ノード問い合わせメッセージは、イーサリアムシステム内のノード間のハンドシェイクメッセージを基準とし、ここではこのメッセージを例として使用しますが、異なるシステムでは異なるメッセージがあるかもしれませんが、機能は大体似ています。
(6) X は背書リストと関連ノード発見アルゴリズムに基づいてノードを発見し、D 川システムに接続します。D システム内には依然として RIR や NR などが背書者として存在しますが、彼らの機能は既存の RPKI などの中央集権的システムとは異なります。まず、D において、これらの背書者は申請組織のアイデンティティの背書と認証を行うだけであり、リソースの配分を主導することはありません。組織が一度認証されると、独立して関連リソースを申請し、所有することができ、リソースの所有権は背書者に依存しません。次に、組織は複数の背書機関から背書を受けることができるため、背書機関が一方的に背書を取り消しても、その組織は依然として参加条件を満たします。
したがって、D はこれらの組織の中央集権的な権限を大幅に排除しました。以上はアクセス制御の基本原理を示したものであり、具体的な実装プロセスでは、上記の原理に従って既存の分散型台帳技術（イーサリアムなど）を改造および強化することができ、実際のニーズに応じてカスタマイズされた分散型台帳を実現することもできます。また、異なるアプリケーションニーズに応じて複数の背書者リストを設計し、異なる背書者リストに基づいて相応のアクセス制御のインスタンスを実現することができます。
これらの背書者リストなどの情報およびその後のすべての D システムの維持情報は、スマートコントラクトまたは類似の方法で実現できます。要するに、上記の問題は今後の研究と具体的な実装の中でさらに詳細に設計し、深く解決する必要があり、本文では詳細に展開しません。
4 名前空間管理層 インターネットの名前空間は TCPP プロトコルの核心であり、インターネット基盤インフラの核心でもあります。インターネットで最も重要な 2 つの基盤インフラ、すなわち BGP と DNS は、名前空間を中心に展開されています。その中で BGP は IP アドレスプレフィックスを ASN（AS 番号）および AS パス（AS 経路）にマッピングし、IP アドレス空間のドメイン間ルーティングを計算します。信頼できる IP アドレスプレフィックスの所有権とマッピング関係は非常に重要であり、そうでなければ BGP プレフィックスのハイジャックやパスのハイジャックなどのネットワーク攻撃が存在します。DNS はドメイン名空間を IP アドレス空間にマッピングし、サービスがネットワーク層でアクセスできるようにします。信頼できるドメイン名の所有権とマッピング関係も非常に重要であり、そうでなければドメイン名キャッシュの汚染などの脆弱性が存在します。
信頼できる名前の所有権と名前のマッピングは、インフラの信頼性の基礎です。このため、名前空間管理層を D アーキテクチャの中間層として位置付け、去中心化された信頼できる名前の帰属とマッピングを通じて、インターネット基盤インフラの安全性と信頼性を保障し、さらに信頼できる上層アプリケーションをサポートします。
4.1 IP アドレスと AS 番号の管理 現在の IP アドレスと ASN の信頼できる基盤インフラは RPKI です。RPKI は、グローバル IP アドレス配分システムの中央集権的なツリー構造を踏襲し、一方で中央権威機関を通じて IP アドレスと ASN の所有権の唯一性を保障し、他方で申請者の合理的な使用ニーズを評価し、配分プロセスで名前空間の枯渇を防ぎ、ルーティングの断片化を防止します。以下に、去中心化の方法でグローバル IP アドレス配分を実現する可行性を分析します。
もし IP アドレスの初期所有権が確定すれば、IP アドレスの移転は取引の形で分散型台帳上で完了でき、そのプロセスは比較的簡単であり、詳細には述べません。ここでは主にアドレスの初期配分プロセスを紹介します。IPv4 アドレス空間はすでに配分が完了しているため、ここでは IPv6 アドレスに焦点を当てます。D1 システムでは、IPv6 アドレス配分の基本単位は / 32 とし、32 ビット ASN の可分配数に近いものとします。
以下に、去中心化の方法でグローバル IP アドレス配分を実現する可行性を分析します。もし IP アドレスの初期所有権が確定すれば、IP アドレスの移転は取引の形で分散型台帳上で完了でき、そのプロセスは比較的簡単であり、詳細には述べません。ここでは主にアドレスの初期配分プロセスを紹介します。IPv4 アドレス空間はすでに配分が完了しているため、ここでは IPv6 アドレスに焦点を当てます。D1 システムでは、IPv6 アドレス配分の基本単位は / 32 とし、32 ビット ASN の可分配数に近いものとします。
IPv6 アドレス配分のシステムは図 5 に示されています。認証された組織は IPv6 アドレスの申請を開始できます。ISP が例として、まず分散型台帳取引を開始し、内容は 32 ビット IPv6 アドレスの 1 年間の使用権を申請し、アドレス使用年費を支払います。他のノードはその取引を受け取り、スマートコントラクトを通じて申請者の合法性と年費を確認し、疎な委任（sparse delegation）アルゴリズムを用いて ISP に適したアドレスプレフィックスを計算します。このアルゴリズムの基本機能は、各申請者に連続したアドレス空間を計算することであり、アドレスの断片化やルーティングの膨張を防ぎます。アルゴリズムは決定的であるため、ネットワーク全体でのアドレス配分は一貫性があり、唯一のものとなります。使用権が期限切れになる前に、申請者は更新取引を開始し、年費を再度支払う必要があります。そうしないと、そのプレフィックスはスマートコントラクトによってアドレスプールに再放出されます。
ドメイン名の管理は IP アドレスとは異なります。まず、ドメイン名は階層的であり、IP アドレス空間はフラットです。次に、ドメイン名空間は現実には枯渇することがなく、IP アドレス空間は有限です。D 川にとって最も関心があるのは、人類の共同資産であるドメイン名空間であり、特定の国や機関に帰属するドメイン名空間ではありません。本論文では、一般的なセカンドレベルドメイン（例：example.com、example.net など）に重点を置いています。これは、.com、.net などの一般的なトップレベルドメインが人類の共同資産であり、自由に申請できるセカンドレベルドメインが存在するからです。
・セカンドレベルドメインの所有権が確定した後、対応するサードレベルドメインは同じ管理ドメイン内で管理され、私有資産となり、去中心化管理の範囲には含まれません。さらに、国コードトップレベルドメイン（.cn、.jp など）はオフラインでの協議が必要であり、スペースの制約から本論文では議論しません。
ドメイン名管理のロジックは、単独のスマートコントラクト内で実現できます。IP アドレスの申請者（主に大規模な組織構造）とは異なり、ドメイン名の申請者には多くの個人や小規模な組織が含まれ、分散型台帳を展開し、維持費用を負担する意欲は低いです。したがって、現在のドメイン管理システム内のドメイン仲介者を利用して申請者が去中心化ドメイン申請プロセスに参加することを代替し、権力の集中を避ける必要があります。
去中心化のドメイン申請と移転は図 6 に示されています。セカンドレベルドメイン（SLD）の申請者は、まず公私鍵のペアを生成する必要があります（公開鍵は pkX、秘密鍵は skX）。彼は自分の公開鍵 pkX と申請するドメイン名 example.com をあるドメイン代理 A に提出します。A はそのドメイン名がまだ空いているかどうかを確認し、空いている場合は分散型台帳で取引を開始します。内容は「pkX がドメイン example.com を申請する」というものです。他のノードが取引を受け取った後、同様にドメインの可用性を確認し、利用可能であれば「example.com の所有者は pkX である」と書き込みます。ドメインの申請は IP アドレスとは異なり、前者は先着順の方法を採用し、後者はアルゴリズムを用いてアドレスの断片化を防ぎます。ドメイン使用年費および更新と期限切れの処理方法は IP アドレスと類似しており、ここでは再度述べません。
D が分散型台帳上で申請者の管理を仲介者に代替させたとしても、ドメインの所有権は依然として申請者自身が制御しており、中央集権の問題は存在しません。これは、分散型台帳に書き込まれるのが「ドメイン名は kX に帰属する」であり、対応する秘密鍵 skX を持つ申請者のみがドメインの所有権を証明できるからです。たとえドメイン代理がその申請者にサービスを提供しなくても、申請者は他の仲介者を通じてドメイン管理を行うことができ、仲介者に束縛されたり、脅迫されたりすることはありません。図 6 のドメイン移転の例では、ドメインの所有者は秘密鍵で署名する必要があり、関連するドメインの移転を操作できます。申請時には仲介者 A を通じて、移転時には仲介者 B を通じて行うことができ、ドメインの制御権を独立して保持します。
ドメイン解析データの量は膨大であり、動的性が非常に高いため、すべての解析データ（たとえば、ドメイン名 ww.example.com を特定の IP アドレスにマッピングするなど）を分散型台帳にすべて保存することは現実的ではありません。したがって、D は安全なドメイン解析に最も重要な情報のみを分散型台帳に保存します。ドメイン example.com の所有者は、自分の公開鍵とドメインの権威あるネームサーバーのアドレスを分散型台帳に保存します（図 7 参照）。これらの情報の特徴は、占有するストレージ量が小さく、動的性が小さいため、分散型台帳の性能や拡張性に大きな挑戦をもたらすことはありません。一方、ストレージ量が大きく、動的性が高い情報は権威あるサーバーに保存されます。
5.2 BGP パス改ざん検出 悪意のある AS が虚偽の AS パスを発表してルーティングをハイジャックする場合、既存の BGP 自体では AS パスが改ざんされたことを発見するのが非常に難しく、ルーティングが悪意のある AS にハイジャックされ、巨大な危害をもたらすことになります。図 9 は BGP パス改ざんの例を示しています。AS400 はプレフィックス 20.20.0.0/16 を偽造し、虚偽の AS パス（400,200）を発表します。AS600 は 20.20.0.0/16 に到達する 2 つの AS パス（400,200）と（500,100,200）を受け取り、AS600 は最短パスの原則に基づいて AS400 を優先して 20.20.0.0/16 に到達します。その結果、AS600 内の目的アドレスが 20.20.0.0/16 のトラフィックが AS400 にハイジャックされます。DI システムに基づいて、以下の BGP パス検証方法を用いて BGP パス改ざんを検出できます。AS の所有者は取引の形で DI 上で他の AS との隣接関係を発表し、他のノードは発表者がその AS の真の所有者であるかどうかを検証します。検証が通過した後、その AS の隣接関係が他のノードによって D 川システムに書き込まれます。虚偽の情報を発表すると、特定の AS のトラフィックがハイジャックされたり、ブラックホールに入ったりする可能性があるため、被害者はその AS だけです。したがって、AS の真の所有者は虚偽の情報を発表する動機を持たないため、DI システムが維持する AS 隣接関係表は安全で信頼できます。
引き続き図 9 を例にとります。AS200 が発表した隣接関係は表 1 に示されています。AS600 が AS400 から発表された AS パス（400,200）を受け取ったとき、表 1 を通じて AS200 と AS400 の間の隣接関係の信頼性を検証できます。明らかに AS200 は AS400 との間の隣接関係を発表しておらず、これは AS200 が AS400 との間に隣接関係を確立していないことを示しています。
5.3 BGP ルーティング漏洩検出 インターネットエンジニアリングタスクフォース（IETF）の標準 RFC7908 は BGP ルーティング漏洩を分類しており、本節では RFC で定義された最初の 4 種類のルーティング漏洩タイプを検出する方法を提供します。具体的なルーティング漏洩タイプは以下の通りです。
AS がプロバイダーから受け取ったルーティング通知を他のプロバイダーに渡す；
AS がピアから受け取ったルーティング通知を他のピアに渡す；
AS がプロバイダーから受け取ったルーティング通知をそのピアに渡す；
AS がピアから受け取ったルーティング通知をそのプロバイダーに渡す。
AS200 はプロバイダー AS100 からプレフィックス 30.30.0.0/16 を受け取り、それをそのピア AS300 に通知します。この行動は上記の BGP ルーティング漏洩タイプ 3 に該当します（図 10 参照）。AS300 は既存の BGP では AS200 がプレフィックス 30.30.0.0/16 を漏洩したことを識別できず、AS300 が 30.30.0.0/16 へのトラフィックを AS200 に転送することを優先すると、トラフィックが誤って AS200 に引き寄せられ、AS200 の負荷能力が不足している場合、トラフィック転送の遅延や破棄が発生する可能性があります。
従来のウェブサイトの信頼性は主に PKI 証明書を通じて 2 種類の情報の実現を保障します：ドメイン名の所有権と運営者の真のアイデンティティ。ドメイン名の所有権を証明する証明書は DV 証明書と呼ばれ、これら 2 種類の情報を同時に保障する証明書は EV 証明書と呼ばれ、後者の信頼性がより高いと見なされています。第 4 節で紹介したドメイン管理に基づき、D はスマートコントラクトが提供する情報を利用して、ウェブサイト運営者がそのドメインの所有権を証明できるようにします。つまり、DV 証明書はもはや第三者のデジタル証明書認証機関（CA）に依存せず、ウェブサイト運営者は自らのユーザーにスマートコントラクトに関連する情報を提供してそのドメインの所有権を証明できます。
この基盤の上に、D に CA の役割を参加ノードとして導入することができます。CA ノードはスマートコントラクトを通じて他のノードアカウントのアイデンティティ背書情報を発表できます。論理的には、このアイデンティティ背書情報はドメイン管理システムの情報とは完全に独立しています。もしあるノードが既にアイデンティティの背書を持っている場合、同時にいくつかのドメインを所有していると、そのノードはウェブサイトのユーザーに関連するドメイン所有権情報とアイデンティティ背書情報の両方を提供できます。
ユーザーは D に基づいてこれら 2 種類の情報を検証し、V 証明書レベルの認証を実現できます。なお、ウェブサイトが通信中に使用する公開鍵は、ドメイン名の所有権にのみ結びついており、アイデンティティ背書には結びついていません。なぜなら、ドメイン名の所有権の証明は完全に去中心化されており、安全性が高いのに対し、後者は依然として CA に依存しているからです。D 川では、1 つのウェブサイトが複数の CA からアイデンティティの背書を受け取ることができ、現在の PK 証明書システムの下で単一の CA が一方的に証明書を取り消すことによってウェブサイトの信頼のアンカーポイントが失われる状況を回避できます。最悪のシナリオでは、すべての CA が同時にあるノードアカウントのアイデンティティの背書を取り消しても、そのドメインの所有権を剥奪することはできず、せいぜいそのアカウントが運営するウェブサイトの信頼性が EV レベルから DV レベルに低下するだけであり、中央集権的な CA の一方的な操作による影響を軽減します。
既存のインターネットの核心リソース（IP アドレス、ASN、ドメインなど）の配分と管理は事実となり広く使用されているため、一度にすべてを D 川システムに移行することは不可能です。本節では、現在の集中型リソース管理方式から進化することができる提案を提供し、リソースの使用に影響を与えずに、核心リソースの去中心化管理を徐々に実現します。
6.1 IP アドレス管理と ROA 能力 D 川システムは、既存の IP アドレス配分システムを変更することなく、現ネットワークの BGP プレフィックス情報を収集し、IP アドレスの所有権と ASN のマッピング関係を取得することによって、D システム内で維持し、後続のアプリケーションに信頼できる情報を提供します。具体的な提案は図に示されています。
ステップ 1 ISP は既存の IPv6 アドレス配分メカニズムを通じてアドレス 2001:da8:32 を取得します。ISP は他の AS に BGP メッセージを発表し、このメッセージにはアドレスプレフィックス 2001:da8:32、AS パス 100、および所有者の公開鍵情報 pkA が含まれています。このメッセージは実際には 2 つの機能を実現しています。1 つは IP アドレス 2001:da8:32 と公開鍵 pkA を結び付け、ステップ 3 で他のノードがこの IP アドレスの D システム内での所有権を検証するために使用します。もう 1 つは、IP アドレス 2001:da8:32 と AS100 を結び付け、ステップ 3 で他のノードが ROA の詳細な合法性を検証するために使用します。公開鍵情報 pkA は、既存の BGP 更新（update）メッセージを拡張して持ち運ぶことができます。具体的なメッセージ形式は本文では述べません。
ステップ 2 SPA は D 川システム内で IP アドレスの所有権と ASN のマッピング関係の取引を開始します。取引内容は「公開鍵 PkA に対応する秘密鍵の所有者（すなわち ISP）は IPv6 アドレス 2001:da8:32 の所有者であり、AS100 を通じて相応のプレフィックスを発表する」というものです。悪意を防ぐために、ルーティングが一時的にハイジャックされる必要があり、そのルーティングはネットワーク内で一定期間安定して存在する必要があります。たとえば、10 日間のうち 5 日以上安定して存在する必要があり、他のノードは ISP がそのアドレスの真の所有者であると見なします。ISP はルーティングが上記の規則を満たした後、取引を開始し、ネットワーク内のノードがそのプレフィックスに関連する情報の信頼性を認めることを確保し、取引の失敗を避けます。
ステップ 3 検証ノードは取引を受け取った後、IP アドレスプレフィックス、所有者の公開鍵情報、および BGP 宣言を行うための ASN を取得します。その後、検証ノードはルーターからそのアドレスプレフィックスに関連するルーティング情報を取得し、ローカルに保存されたルーティングの生存時間、ASN、アドレス所有者の公開鍵などの情報を確認し、取引の情報を検証します。
ルーター上のメッセージと取引メッセージが一致すれば、検証が通過します。検証ノードが合意に達した後、IP アドレスの所有情報と ROA 情報が分散型台帳に書き込まれます。上記の方法を通じて、ルーティングの ROA が分散型台帳に保存されます。各ネットワークは ROA を読み取り、ルーティングの検証リストを生成し、BGP ルーターに書き込んで BGP ソースアドレスの検証を行い、ルーティングの安全性を向上させます。
アドレスの所有者は ROA に対して完全な制御権を持ち、いかなる第三者の権威にも依存せず、中央ノードが一方的に信任を取り消したり、虚偽のノードに信任を与えたりすることによって信頼できるサービスに破壊的な影響を与えることを避けます。
6.2 ASN 管理とドメイン間隣接関係 DI システムは、既存の ASN 配分システムを変更することなく、現ネットワークの BGP 情報を収集することによって、ASN の所有情報を分散型台帳に保存し、AS 所有者が分散型台帳に信頼できる AS ドメイン間隣接関係を保存できるようにし、去中心化の AS ドメイン間隣接関係管理を実現します。ASN の管理は IP アドレス管理方式に類似しており、具体的な提案は図 12 に示されています。
(1) ISP は既存の ASN 配分メカニズムを通じて ASN200 を取得します。ISP が他の AS にプレフィックス情報を発表する際、ASN:200 とその ASN 所有者の公開鍵情報 pkB を持ち運びます。この提案では、BGP 更新メッセージを拡張し、ASN 所有者の公開鍵情報を持ち運ぶ必要があり、ASN と所有者の関係を結び付けます。具体的なメッセージ形式は本文では述べません。
(2) ISP は ASN:200 を所有する取引を開始し、取引内容は「公開鍵 kB に対応する秘密鍵の所有者（すなわち ISP）は AS200 の所有者である」というものです。悪意を防ぐために、ASN 情報はネットワーク内で安定して存在する必要があり、その後取引を開始し、ネットワーク内のノードが ASN 所有者情報の信頼性を認めることを確保し、取引の失敗を避けます。
(3) 検証ノードは取引を受け取った後、ASN を取得し、ASN 所有者の公開鍵情報を確認し、検証が通過した後にその取引を受け入れます。検証ノードが合意に達した後、ASN 所有者の情報が分散型台帳に保存されます。
ASN の所有権が明確になった後、ASN の所有者はその AS ドメイン間隣接関係の取引を開始できます。検証ノードはその取引を受け取った後、まず ASN の所有権を検証し、ASN の所有者のみが ASN に関連する取引を開始できます。検証ノードが合意に達した後、AS ドメイン間隣接関係が分散型台帳に保存されます（表 1 参照）。信頼できるドメイン間隣接関係は BGP パス改ざんやルーティング漏洩検出に応用でき、その方法は第 5 節で詳述します。
6.3 ドメイン名管理 D 川は、既存のドメイン配分システムに基づいて、既成事実のドメイン所有権状態に基づいて D 川システム内のドメイン所有権の初期化を実現できます。基本原理は図 13 に示されています。
(1) あるユーザー A が既存のドメイン管理システムを通じてドメイン example.com を取得していると仮定します。 ユーザー A はこのドメインを有効にし、そのドメインに対応するウェブサイトの IP アドレスを既存の DNS システムに維持する必要があります。対応するウェブサイト（www.example.com を例にとる）は、検証情報を提供する能力を持っている必要があります。
(2) ユーザー A は D システム上で取引を開始し、example.com の所有権を宣言し、そのドメイン名とある公開鍵 PK を結び付け、すなわち公開鍵 PK に対応する秘密鍵の保持者がそのドメインの所有者であることを宣言します。
(3) 検証ノード（C など）は取引を受け取った後、現在の DNS システムから対象ウェブサイトに対応する IP アドレスを取得します。
(4) 検証者 C はそのウェブサイトと接続を確立し、検証を実行します。検証が通過した後、C はその取引が合法であると見なします。
(5) 大多数のノードが検証を通過した後、そのドメインの所有権情報が D システムに書き込まれます。
検証の方法はウェブサイト自身に依存し、D は何の制限も設けません。本論文では、読者の参考のために 2 つのアイデアを提供します。第一の方法では、ウェブサイト上で特定のランダム数と関連する秘密鍵 sk に対応する署名を公開し、検証者は D システム上で取得した公開鍵 k を用いて署名を検証します。検証が通過すれば、そのドメインの所有者が保持する秘密鍵 sk と D 上で公開された公開鍵 pk が一対の鍵ペアであることが示され、すなわち秘密鍵 sk の保持者がドメインの所有者であることが証明されます。第二の方法では、ウェブサイトが何らかのインタラクティブな能力を持たせ、検証者がランダム数を生成し、公開鍵 k で暗号化してそのウェブサイトに送信し、ウェブサイトが秘密鍵 sk で復号化したランダム数を返すことを要求します。復号化されたランダム数が正しければ、そのウェブサイトが D システム上の公開鍵 PK に対応する秘密鍵 sk を保持していることが示されます。ドメインの所有権が明確になった後、ドメインの所有者は既存の DNS システム内の公開情報を撤回し、その情報を D システムに維持し、図 7 に示す方法で DNS サービスを提供できます。
以上の 3 つの移行案は、既成のリソース所有権の事実を D システムに同期させる方法を示したものに過ぎません。一度リソース所有権情報が D システムに同期されれば、D 川システム上で新しいリソース回収能力を追加することができ、リソースが期限切れになるとスマートコントラクトによって D リソースプールに回収されます。リソースプール内のリソースは、第 4 節で述べた完全な去中心化管理方式を可能にします。リソースの回収と再配分は国際機関間の戦略やゲームの影響を受けるため、技術的な範疇を超えており、本論文では詳細に議論しません。
インターネット基盤インフラの去中心化の問題はますます注目を集めています。国際インターネットエンジニアリングタスクフォース（IETF）は去中心化インターネット基盤インフラ研究グループ（DINRG）を設立しました。DINRG では、スタンフォード大学のチームがインターネット基盤インフラに適した去中心化合意プロトコル SCP を提案しました [9]；バークレー大学は去中心化のマッピングシステムを提案しました [10]；去中心化アイデンティティ財団は去中心化アイデンティティシステムを推進し [11]、学術界や産業界から広く注目を集めています。
RPKI の中央集権的な問題に対処するために、Cloud Flare は RPKI Transparency 技術と製品を発表しました [12] が、これは単に事後監査の方法を用いて中央ノードの悪意のある行動をチェックするものであり、事前の予防はできません。単一の問題の本質は中央ノードの権威とデータにあります。DII は分散型合意によって中央権威ノードを置き換え、分散型台帳によって中央データベースを置き換え、根本的に中央集権の問題を解決します。スペインのカタルーニャ工科大学（UPC）は、IP アドレス空間を管理するために Proof of Stake アルゴリズムを採用することを分析しています [13]。スペインのマドリード・カルロス 3 世大学（UC3M）は、イーサリアムに基づいて IP アドレス空間を管理するためのブロックチェーンの実験を行っています [14]。
ドメインシステムの中央集権的な問題に対処するために、業界にはすでに複数の去中心化ドメインプロジェクトがあります。たとえば、Namecoin [15]、BNS（Blockstack Naming System）[16]、ENS（Ethereum Naming Service）[17] などです。これらの提案は中央集権の問題を解決することに焦点を当てていますが、ドメイン解析プロセスにおいて他の問題も引き起こしています。Namecoin や BNS では、DNS クライアントは依然として特定のローカルドメイン解析器を無条件に信頼する必要があり、解析結果を検証することができません。これらのローカルドメイン解析器は、一方的な情報の改ざんを通じてクライアントやドメイン所有者に対して悪意を持つことができます。ENS では、クライアントは解析結果を検証できますが、各リクエストには巨額の検証コストがかかります。
PKI の中央集権的な問題に対処するために、Google は証明書透明性（certificate transparency、CT）方案を提案しました [18]。この方案は、証明書発行のすべての履歴を記録するための追加のログシステムを利用し、各ウェブサイトの合法的な運営者はモニターを通じて関連する証明書の発行行為をリアルタイムで監視します。CA が悪意を持つ状況が発生した場合、モニターは合法的なウェブサイト運営者に警告を発します。CT はある程度 PKI 体系の中央集権的な問題を緩和できますが、これは受動的な防御策であり、事後的に補うことしかできず、根本的に中央集権的な問題から生じる悪意のある行動を阻止することはできません。