はじめに

今回は、BGP にブロックチェーンを組み合わせたプロトコル、BGPChain について紹介します。

論文はこちら：https://www.sciencedirect.com/science/article/pii/S2405959520304938

BGPChain は「QoS ベースルーティング」と「リソース認証」という 2 つの要素で構成されています。QoS ベースルーティングは低コストでエンドユーザのルーティング QoS を向上させることを目的としています。リソース認証はリソースのハイジャックを防ぐために使用されます。

QoSベースルーティング・ブロックチェーン

ブロックチェーンはパブリックチェーンであり、２種類の参加者（エンドユーザとルーター）がいます。ルーティングでは必要なエネルギーを消費します。ブロックチェーンには、元のプレフィックスと各ルーターのフォワーディングポリシーを元にして作られた RouteContract が保存されます。

上図のように、End-User1 が End-User2 とのセッションを確立するとき、End-User1 は RouteContract を発行する必要があります。RouteContract には、セッションの QoS 必要条件や消費されるエネルギーが含まれています。このコントラクトを受け入れたルーターは宛先への経路をスケジュールし、経路上の全てのルーターはローカルにこのコントラクトを満たすために署名を行います。すべてのパケットが宛先に到達した後、いずれかのホップが約束を満たしていないか、そしてホップは関連するエネルギーを得られないのは明らかです。ここで、エネルギーはパケットルーティングのために BGP ネットワークで消費される「コイン」として機能し、より良いサービスを提供するルーターはそれに応じてより多くのエネルギーを取得します。

上図のモデルにはセッション確立、データ通信、エネルギー決済の 3 つの手順が含まれています。 

1. セッション確立
   セッションは、送信元アドレス、送信先アドレス、ポート番号などのパラメタで一意に識別される必要があります。そして、このセッションには、例えば、遅延、損失率、スループット、ジッターなど、必要な QoS が付加されます。さらに、送信元エンドユーザ（End-user1）は、このセッションのデータ送信を実行するルーターに、関連する報酬であるこのセッションへの約束されたエネルギーを公表します。次に、送付元エンドユーザは、ルーターによって構成される P2P ネットワークにトランザクションを（特定の RouteContract として）送信します。
   BGPChain 内のルーターは、ネットワーク内の保留中の RouteContract をすべて同期させることができます。ルーティングテーブルとポリシーをもとに、QoS 要件と提供されるエネルギーの評価に基づいて、いくつかの RouteContract を選択的に受け入れることができます。次に、ルーターは、宛先エンドユーザ（End-User2）が同じ AS 内にあるかどうかに従って行動します。同じ AS 内にいない場合、ルーターはこのセッションを確立するために次のホップを追跡する必要があります。そして、ルーターはエネルギーと QoS の条件を変更した RouteContract をネクストホップに送信します（上図のステップ2およびステップ3）。このルータと同じ AS にいる場合、セッションが正常に確立されたことを意味します。上図のように、確立されたセッションは、コンタクトを複数のトランザクションに分割します。ルーターは元のコントラクトに追加して修正したコントラクトを発行します。例えば、TX2におけるレイテンシ要件とエネルギーは以下のようになります。
   
   Latency(TX2) = Latency(TX1) − Latency(Router1)
   Energy(TX2) = Energy(TX1) − Energy(Router1)
   
   事前に定義された時間内にコントラクトが成立しなかった場合、エンドユーザとルーターはコントラクトを撤回し、変更されたパラメタ（例えば、QoS 要件を減少させる、または提供されるエネルギーを増加させる）でコントラクトを再公開することができます。このセッションのデータ通信が完全に終了し、エンドユーザによって承認されるまでは、ルーターにエネルギーが支払われることはありません。ルーターがセッションの確立を遅らせたり、悪意を持って不当なコントラクトを送信した場合、例えばルーティングの優先度を下げるなどの罰則が与えられます。

2. データ通信
   セッションが確立されると、この指定された経路でデータが送信されます。データが各ホップを通過すると、ルーティングの品質が記録されます。これは、最終的に担保となるエネルギーを決済するために使用されます。

3. エネルギー決済
   このセッションでデータ通信が完全に終了すると、RouteContract はコントラクトアカウントの関連エネルギーをアンロックし、各ルータにエネルギーが支払われます。このように、エンドユーザが専用の通信回線を借りることなく、QoS の保証を実現することができます。

リソース認証ブロックチェーン

このブロックチェーン には、フォワーディングポリシー、IP プレフィックス、AS パスをすべて関連する署名とともにブロックチェーンに格納することができます。そして、このブロックチェーンは IANA（Internet Assigned Numbers Authority）アーキテクチャと連携し、BGP におけるプレフィックスハイジャックやポリシーの不正を回避するための数値リソースの所有権告知を検証することができるのです。これはコンソーシアムブロックチェーンであり、IANA、RIR、NIR、ISP、その他のリソースホルダーが参加します。IANA -> RIR -> NIR -> ISP へ数値リソースが割り当てられると、関連する証明書がリソースに添付されます。この情報と参加者の公開鍵はブロックチェーンに公開されています。そして、BGP ルーターはブロックチェーンのデータ更新を聞くと、すぐにデータを同期させることができます。現在の RPKI アーキテクチャと比較して、BGP ルーターは受動的に ROA データを取得する必要がなく、その後、BGP ルーターは受信した BGP Update メッセージをより効率的に検証することができます。

リソース認証ブロックチェーンのコンセンサスプロセスは、マイナー選択、ブロック生成、ブロック確認の 3 つのステップで構成されています。

• マイナー選択
  リソース保有者である各ピアは、各エポックの開始時に投票スマートコントラクトを呼び出して、N 個のマイナーの中からランダムに 1 個を選択します（N は現在のシステムにおけるリソース保有者の数）。投票フェーズが終了すると、投票リストの上位 21 人のマイナー候補が、そのエポックにおいて選ばれたマイナーとなり、ブロック生成フェーズの準備をします。

• ブロック生成
  21 人のマイナーは、擬似乱数によってランダムにソートされ、1 人ずつ証人となります。一人の証人は一度にレコードプールから有効なレコードを集め、新しいブロックに詰め込み、署名された後に他のマイナーにブロードキャストされます。各証人は 15 秒以内に新しいブロックを生成する必要があります。そうでない場合、この証人はスキップされ、次のマイナーが証人となり、レコードの収集と新しいブロックの生成を継続します。

• ブロック確認
  リソース認証ブロックチェーンは、DPoA コンセンサスをベースに、ブロック確認の過程で BFT コンセンサスを加えることで、耐障害性と安全性を向上させ、確認速度を加速させます。新しいブロックはすぐに他のノードによって確認される必要はなく、しばらく確認を遅らせることができます。リソース認証ブロックチェーンは、DPoA コンセンサスをベースに、ブロック確認の過程で BFT コンセンサスを加えることで、耐障害性と安全性を向上させ、確認速度を加速させます。新しいブロックはすぐに他のノードによって確認される必要はなく、しばらく確認を遅らせることができます。例えば、現在の証人 $$X$$ が新しいブロック $$A$$ を他のマイナーにブロードキャストした後、次のマイナー $$Y$$ が証人になるとします。$$Y$$ はブロック $$A$$ を元に新しいブロック $$B$$ をパックし、$$B$$ を他のノードにブロードキャストします。その後、$$X$$ はブロック $$B$$ を受け取るが、これは $$X$$ が生成したブロック $$A$$ が $$Y$$ によって 1 回確認されたことに相当します。$$X$$ が $$15 [(2/3 of 21)+1]$$ ブロックの確認を蓄積すると、ブロック $$A$$ は最終的に確認されて非ロールバック状態となります。

DPoA の仕組みでは、各マイナーが競争するのではなく、協力してブロックを生成します。フォークが発生した場合、コンセンサスは自動的に長い方のチェーンに切り替わります。また、マイナーのノードの順番はエポックの開始時にあらかじめ決まっているため、リソース認証ブロックチェーンはフォークの問題がほとんどありません。