THEMIS：スマートコントラクトとサイドチェーンによる段階的な分散化（第２弾）

本記事では、リサーチエンジニアのGonçalo Pestana氏、暗号技術者のIñigo Querejeta-Azurmendi氏、セキュリティ研究員のPanagiotis Papadopoulos博士、チーフ・サイエンティストのBen Livshits博士による成果をご紹介しています。Brave Adsを段階的に分散化する取り組みをご紹介する特集シリーズの第2弾です。

注：THEMISは現在研究段階のものであり、Brave Rewardsのサービス開発への適用を意図したものではありません。

本特集シリーズの第１弾では、THEMIS暫定版をご紹介しました。THEMISはBraveの研究チームが設計した分散型広告プラットフォームです。そこでは（1）ユーザーが広告接触に応じて報酬を得る仕組みと、（２)広告主が広告キャンペーンの課金とパフォーマンスに関する報告の完全性を検証する仕組みについて説明しました。本特集シリーズの詳細版は、ArxivからPDFでご覧いただけます。

しかし、THEMIS暫定版では達成すべき特性の全ては実現できていません。特にトラストが課題でした。THEMIS暫定版の設計では、基本的なプロトコルの実行を調整する中央機関（キャンペーン・マネージャー：CM）が必要です。さらにCMによるプロトコル処理の完全性や妥当性を、担保・検証するメカニズムはありませんでした。そのため、ユーザーと広告主は支払金額が計算される際に、広告ポリシー（出稿条件）が正しく履行されていることを信頼する必要があります。「段階的な分散」を次のレベルに進めていくにあたっては、この問題を解決する必要があります。

本記事では、THEMISの完全版をご紹介します。上記の問題をどのように解決し、BATをTHEMISでどう利用するかをご説明します。まず、プロトコルを理解するために必要な技術的概念をご紹介します。次に、THEMIS完全版のプロトコルと処理段階ごとに概要をご説明します。その後、BATを使用することで、参加者がネットワークに有用なタスクを行うようなインセンティブを提供しつつ、有害な行為を行う参加者を制限する方法について議論します。さらに、クライアントとスマートコントラクトの両方をTHEMISにオープンソースで実装したものをご紹介します。最後に、本番に近い環境におけるクライアントサイドとエンドツーエンド双方の測定を行い、プロトコルのスケーラビリティとパフォーマンスについて議論します。

技術的な背景　

アカウントベースのブロックチェーン上の「コンフィデンシャル・ペイメント」

「アカウントベース」モデルを採用しているブロックチェーン上で実現されるコンフィデンシャル・ペイメントとは、送金額や口座の残高を開示することなく口座間の資金転送を可能にするものです。さらに、送金者が支払いの正確性（二重支払いがないこと、送金の実行に十分な資産を持っていること）を証明します。コンフィデンシャル・ペイメントは、最近、学界 [1]、[2] と業界 [3] の両方で多くの関心を集めています。

THEMISでは、コンフィデンシャル・ペイメントを実現することができるAZTECプロトコル[4]を利用しています。さらに、支払いの正確性をバッチで証明する機能があり、単一のエンティティが複数の支払いを行う場合にコストが分散できます。またAZTECプロトコルには、Ethereum仮想マシン上にコンフィデンシャルアセットを載せるためのツールキットとスマートコントラクトが含まれています。金額を開示せずに取引を確認や検証するために必要なコミットメント方式とゼロ知識証明も定義されています。

注：コンフィデンシャル・ペイメントを行うためにAZTECを使用していますが、THEMISは他のペイメントプロトコルにも対応可能です。

PoAベースのブロックチェーン上のトランザクション情報の秘匿化（入力）

Poof-of-Authority （PoA）ベースのブロックチェーンにはスマートコントラクトの入力情報の秘匿化（バリデータ・ノードのみがトランザクションのペイロードを知る）を特徴とするものがあります（例: Quorumのプライバシートランザクション[6]）。トランザクション情報の秘匿化のためには、スマートコントラクトの入出力が各バリデータの公開鍵で暗号化される必要があります。これによりパラメータが秘匿化された状態で、バリデータ・ノードはスマートコントラクトを正しく実行しコンセンサスをとることが可能です。本記事では、説明を簡単にするためにPoAの各バリデータの各公開鍵を1つの公開鍵として[[\valikey]]と表すことにします。

コンセンサスプールの構成員の選択と検証可能擬似乱数関数（VRF）

本特集シリーズの第1弾でも、検証可能擬似乱数関数（VRF）[7]を簡単に紹介しました。ここでは、コンセンサスプールの構成員を無作為に選択するにあたり、こうした関数をどのように使用しているかについて簡単にご説明します。アプローチは、Volt [8]に説明されているものと同様です。簡単に言えば、抽選への参加を希望するユーザーは、暫定的な公開鍵・秘密鍵ペア([[\VRFsk, \VRFpk]])を生成します。次に、ユーザーはこの鍵ペアを使用して乱数と正確性の証明([[\vrfrandom, \vrfproof]])を生成します。この証明は、その数値が VRFによって正しく生成されたものであることを単純に保証するものです。この数値が事前に設定された範囲内に（コンセンサスプールの大きさに応じて決定）ある場合、ユーザーはそのプールの一員として選択されます。この証明[[\vrfproof]]は、選択プロセスの完全性を証明するのに十分であり、悪意のあるユーザーがプールの構成員であると主張して不正な行動をすることはできません。コンセンサスプールが選択されると、スマートコントラクト[9]によって規定された分散鍵生成スキームが実行されます。

構成員が足りなくなる状況を避けるために、コンセンサスプールへの参加にはインセンティブが提供されます。プールの構成員を募集するプロセス、構成員への支払い、インセンティブ付与についての説明は本記事には含まれていません。

図 1. THEMISの段階的な分散化のステップの概要を表した図。THEMIS暫定版（左）がキャンペーンマネージャーに依存してキャンペーンを進行させるのに対し、THEMIS（右）ではサイドチェーンがプロトコルを進行します。THEMISでは、プライバシーを保護した広告と接触したBraveブラウザユーザーが、サイドチェーン上のスマートコントラクトに報酬を請求します。

THEMISプロトコル

THEMIS暫定版で未解決だったトラストの問題を解決するために、PoA（proof-of-authority）ベースのブロックチェーンを採用しています。これにより、プロトコルのロジックと支払いがスマートコントラクトによって処理されます。すべてのネットワーク参加者が独立してプロトコルの処理の正しさを検証できるため、ゼロトラストで運用が可能です。

まず、以下のように2つのスマートコントラクトを定義します。

ポリシー・スマートコントラクト（PSC）：ユーザーへの報酬を計算し支払い請求を検証するコントラクトです。特集記事の第１弾で紹介した[[\encpolicy]]はこのスマートコントラクトに格納されています。
ファンド・スマートコントラクト（FSC）：広告キャンペーンの運営に必要な資金の受領やエスクローを行うコントラクトです。FSCは、（1）ユーザーの報酬支払いに必要な資金、（2）広告主への返金、（3）キャンペーン管理者の処理手数料などを支払う役割を担います。

THEMISでは、信頼された中央機関を使わず、トラストレスなキャンペーンファシリテーター（CF）という役割を使用します。例えば、BAT AdsではBraveがCFになります。Braveは、広告主とのやりとりをし、Brave ブラウザを介したユーザーへの広告配信手段も提供しているため、CFになることは自然です。そして、THEMISプロトコルは、1つのサイドチェーンで複数のキャンペーンを実行する複数のCFをサポートします。

CFの責任範囲は以下の通りです。

広告主とポリシー（広告別、インプレッション別の報酬など）の交渉
PoA台帳へのスマートコントラクトの展開
オンチェーン上の支払い処理

THEMISでは、CFはブロックチェーンのPoAコンソーシアムによって認可されたエンティティです。このエンティティは、電子フロンティア財団（EFF）[10]のような独立した第三者や、BATアプリケーションの非営利の取引管理者と開発者のグループの場合もあります。また、 CF としてネットワークを開発し参加できるようにするツールやAPI を、BAT SDK [21]で開発者に提供することも可能です。独立したCFは、PoAコンソーシアムの審査を通れば、CFとしてネットワークに参加することができます。ボランティアネットワークの成功事例（例：Tor [11] ノード、Gnutella [12] ピアなど）にあるように、THEMIS では「誰でも」が CF として機能することを可能にします。

Braveは、広告主と広告施策を交渉する手段を持っているため、CFの役割を果たすことになります。さらにBraveブラウザは、Brave Ads で実証済みのように、THEMIS上で提供される広告配信を実現できる仕組みをもっています。なお、Braveがこの役割を担うことで、Braveやその他の事業体が「特別な権限」をもつことは一切ないことを明記しておきます。

THEMISでは、だれでもが任意のCFの行動を監査し検証できるため、広告主は、CFの評判を確認して提携したいCFを選ぶことができます。CFは広告カタログを管理するために必要なタスクを実行し、広告主から「処理手数料」を受け取ります。

実際のTHEMISには複数の CFがいますが、本記事では分かり易くするために、CFは１つとしてTHEMISのプロトコルのご説明をしていきます。

図1. THEMISにおけるユーザーの報酬獲得手順の概要。THEMISのこの手順は、4つの段階で構成されています。（1）広告報酬の定義とポリシーの設定、（2）広告報酬の計算、（3）支払いリクエスト、（4）ユーザーと広告主への決済です。

第一段階：広告報酬の定義

図 1 に THEMIS の手順の概要を示しています。THEMIS暫定版のときと同様に、広告主は提携したいCFと広告カタログを選び、そこに広告を掲載するために、広告ポリシー（広告の報酬等の出稿条件）をCFに送信します（図 1 のステップ 1a）。そのために、まず各広告主は広告キャンペーンiごとの対称鍵[[\seckey_i]]をCFと交換します（脚注：この鍵の生成には，認証済みのディフィー・ヘルマン鍵交換プロトコルを利用することも可能です）。次に、広告主は、対応する広告キャンペーンを暗号化し、適切な広告クリエイティブと共にCF に送信します。

その後CFは以下のように処理をすすめます。

ポリシーを復号化し合意内容を確認
複数の広告主からの暗号化されたポリシーをベクタ[[\encpolicy]]に統合
この広告カタログ版に2つの公開スマートコントラクトを展開（図1のステップ1b）。

さらに、CF は、広告主の秘密鍵[[\seckey_i]]を全て含むベクタ[[\seckey]]を生成します。

$$ \seckey = \left[\seckey_1, \seckey_2 , \ldots, \seckey_{\nrads} \right] $$

その後、[[\seckey]]の各要素をPoAのバリデータ・ノードの公開鍵[[\valikey]]で暗号化しベクタ[[\encseckey]]を生成します。

$$ \encseckey = \left[ \enc(\valikey, \seckey_1), \ldots, \code{Enc}(\valikey, \seckey_{\nrads}) \right] $$

これは、「ハイブリッド暗号方式」[13]といえます。次に、CFが[[\encseckey]]をPSCにを格納し、PoAのバリデータはそれを復号化し、ユーザーの広告接触ベクタにポリシーを適用します。

PSCが設定されたら、広告主は[[\encpolicy]]にCFと合意したポリシーがエンコードされているかを検証します（図１のステップ１ｃ）。具体的には、以下の通りです。

まず、広告主は、PSCの公開ストレージから[[\encpolicy]]ベクタを取得し、対応する対称鍵を用いてポリシーを復号化し、合意した値であることを確認します。
次に、FSCからエスクロー口座のアドレスを取得し、エスクロー口座に資金を送金します。必要な額は、1広告あたりのインプレッション数（ポリシー[[\policyvector[i]]]で合意済み）とCFに支払う処理手数料によって決定されます。キャンペーンが終了すると、最終的にユーザーが閲覧/クリックしたインプレッション数から残った資金が返金されます。キャンペーン資金をエスクローするプロセスで、広告主は暗に実施されている広告ポリシーを検証することができます。

FSCが広告主がエスクロー口座に振り込んだ金額が正しいことを確認し、キャンペーンは初期化され、検証されます。

ポリシーの合意

キャンペーン・ファシリテータ（CF）と広告主は、各キャンペーンごとにポリシーベクタ[[\policyvector]]を合意します（図１のステップ１）。CFと広告主は、プライベートで安全なチャネルを介してポリシーを議論し合意します。ここでは話を簡単にするために、広告ポリシーを「広告をクリックすることでユーザーが受け取るトークン数」と定義します。もちろん実際には、複雑なユーザーの広告接触をポリシー上に定義することも可能です。キャンペーン・ファシリテーターは、本特集記事の第１弾での説明と同様に、それぞれの広告主と合意した広告ポリシーをまとめて暗号化します。

第二段階：広告報酬の計算

THEMIS暫定版のときと同様に、各ユーザーは広告報酬を計算するために、暫定的な鍵ペア([[\pk, \sk]]）を生成します。次に、ブロックチェーン上で公開されているコンセンサスプールが生成したしきい値公開鍵を取得します（コンセンサスプールの生成方法は、上述の「コンセンサスプールの参加者の選択」のセクションを参照）。ユーザはこの2つの鍵を使用して広告接触ベクタを暗号化し、以下の2つの暗号文を生成します。

広告報酬の計算用[[\encryptedvector]]
広告主へのレポーティング用[[\encvecpublic]]

THEMIS暫定版では、報酬などの集計は中央機関が実施しますが、THEMISでは、PSCが実行します（図1のステップ2b）。ユーザは、上記の２つの暗号文を持つPSC上のパブリックエンドポイントを呼び出します。暗号化された状態の報酬額の計算のため、ユーザはスマートコントラクト（PoAコンソーシアムバリデータによって運営される）を呼び出すことができます（図1のステップ2b）。このスマートコントラクトは以下の計算を行います。

[[\encseckey]]を使用して各ポリシー[[\policyvector[i]]]を復号化（「PoAベースのブロックチェーンにおけるトランザクション情報の秘匿化（入力）」セクションを参照）。
[[\encryptedvector]]が使用している暗号化スキームの準同型性（加法型）を利用しポリシーの適用（暫定THEMISで説明されているステップに従って計算）
計算結果[[\encryptedaggregatedresult]]をPSCのネイティブストレージに格納。なお、ユーザーの公開鍵をつかって[[\encryptedvector]]を暗号化しているため、ユーザーだけが[[\encryptedaggregatedresult]]を復号化して集計を取得できる点が重要です

第三段階：支払いリクエスト

PSCが報酬総額を計算すると、ユーザは支払いリクエスト[[\payreq]]を生成し、これが有効であればファンド・スマートコントラクト（FSC）に送信します（図１のステップ３）。具体的には、以下のステップを実行します。

暫定的なブロックチェーンアカウントとアドレス[[\addr]]を生成（１リクエストにつき1 回のみ使用されるもの）
暗号化された報酬結果[[\encryptedaggregatedresult]]を取得、復号化し[[\decryptedaggr]]、復号化の正しさの証明を[[\aggrproofdec]]生成
3セットからなる支払いリクエストを以下のように生成

$$ \payreq = \left[\decryptedaggr,\aggrproofdec, \addr \right] $$

最後に、ユーザーは、PSCのパブリックエンドポイントを呼び出し[[\payreq]]をバリデータの鍵で暗号化した[[\enc(\valikey, \payreq)]]を入力します。PSCは、ユーザーの報酬[[\encryptedaggregatedresult]]を取得し、支払リクエストを復号化し、ゼロ知識証明[[\aggrproofdec]]を検証します。この証明が有効であれば、PSCは[[\addr]]をFSCに格納し、FSCは支払済みとマークされるまでユーザへの支払いを保持します

第四段階：決済

プロトコルの最後のステップは、ユーザーへの支払いと広告主への返金に関する決済です。

特に、ユーザーへの報酬決済は、獲得報酬の合計額についてプライバシーを守るために、秘匿性の高い方法で行う必要があります。そのためにCFは、FSCから未払いの決済リクエストを取得し、全未払い分の決済に必要な資金の総額を算出します。

次に、CF は FSC のパブリック関数を呼び出し、支払いに必要なトークンの送金（CF が所有する口座宛）をリクエストします（図１のステップ4a）。もし、CF が不正行為を行った場合（トークンのリクエスト量が不正だった場合など）は検出され、広告主やユーザーはその不正行為を証明することができます。

最終的に、CFはコンフィデンシャル・ペイメント方式で未払いの報酬をそれぞれ決済します。正しく決済が完了した後（ユーザーや広告主からの苦情がなければ）、CFはFSCから処理手数料を受け取ります。

エスクローされた資金が残っている場合は、広告主に返金する必要があります（図１のステップ4c）。そのためにFSCは、広告主へのレポートの際にコンセンサスプールが計算した１広告あたりのクリック数の集計ベクタを利用します。このベクタと合意済みの報酬に基づいて、FSCは、広告主に未使用の資金を返金します。なお（1）広告予算を使い切った場合、または（２）広告キャンペーン期限を過ぎた場合に、キャンペーンは終了します。PSCもFSCも、広告キャンペーンの期限をタイマーで管理しています。

実装、性能、スケーラビリティについて

このセクションでは、本プロトコルの全体的な性能とスケーラビリティに焦点を当てたTHEMISのエンドツーエンドの測定について説明します。クライアントと、報酬計算と証明検証を実装するスマートコントラクトを用意しました。測定や実験を行うために、AWS上の本番環境に似た環境をつくりQuorum （クォーラム）のサイドチェーンを搭載しました。

このセクションでは、クライアント側のパフォーマンスとプロトコルのスケーラビリティ検証に焦点をあてています。また、クライアント側でのプロトコルを実行に必要な暗号化、復号化、平文回復を実行する時のリソース負荷が大きすぎないかどうかも確認しています。

測定対象は、（１）クライアント側のリソース消費、（２）プロトコルのエンドツーエンド性能とスケーラビリティ、（３）THEMIS が使用する匿名性を維持した決済プロトコルのスケーラビリティの３つです。具体的には、以下の点を検証します。

報酬計算リクエストと証明の生成の実行に、クライアントが消費する時間とリソースはどれくらいか
256件の広告を搭載した広告カタログを想定した場合、サイドチェーンは1日に何件の支払いリクエストを処理できるか
サイドチェーン上で月に何件の匿名性を維持した決済を実行できるか
最後に、THEMISはBrave Adsが想定するユーザー数やリワードリクエストの数に対応できるか

実装内容と測定設定

THEMISのクライアントをRustで、ポリシー・スマートコントラクト（PSC）をSolidityで実装しました。すべてのコードはgithub上にあり、ドキュメント化されていますので、ご興味のある方は会話に参加してプロジェクトへの貢献をお願いいたします。

さて、クライアントサイドの実装では、サイドチェーンと対話するためにweb3-rust クレートを使用しています。THEMISで必要とされる鍵ペアの生成や暗号化・復号化を実行する公開鍵暗号の実装には、curve25519-dalek[15] とelgamal_ristretto[16] クレートを利用しました。ポリシー・スマートコントラクト（PSC）には、alt_bn128曲線の加算とスカラー乗算を実行できるプリコンパイルされたスマートコントラクト[17]を使用しました。

Mjolnir[18]を使用して、AWS EC2 t.2xlarge インスタンス（8 vCPU、32 GB）上で動作する4台のQuorumノードを、同じリージョン（us-east-2）の同じサブネット上に設置しました。測定の目的上、ネットワーク通信は無視できるものとします。この設定は、バリデータ組織間でごとにAWS仮想プライベートクラウドをピアリング接続することで、本番環境に簡単に再現できます。

このサイドチェーンで、ユーザーが何人まで同時利用が可能かをテストするために、複数のAWS EC2 t2.largeインスタンス（2 vCPU、8 GB RAM）を使用し、クライアントのロジックを実行しました。同時に利用するクライアント数を10、30、60、100で設定し、エンドツーエンドのパフォーマンスを測定しました。

システム性能

クライアント側がロースペックのデバイスやブラウザであっても、良好なユーザー・エクスペリエンスを提供するために重要なのは、レイテンシ（待ち時間）とリソース消費です。THEMISの目標は、大規模な広告システムに向けて実用的でスケーラブルなソリューションになることです。そこで、THEMISのコアプロトコル[22]のプロトタイプを実装し、本番さながらの環境で性能とスケーラビリティを測定しました。本セクションでは、これらの測定結果の概要をご説明します。

A：エンドツーエンドのパフォーマンスとスケーラビリティ

プライバシーを保護した広告プラットフォームが抱えている最も重要な課題の１つはスケーラビリティです。THEMISの場合スケーラビリティとは、一定の時間内にサイドチェーンがどれだけ多くの報酬支払リクエストを処理できるかということになります。

今回は、クライアントが発行するリクエスト（例えば報酬計算（第二段階）や支払いリクエスト（第三段階））をTEHMISが実行する時間と、サイドチェーンがリクエストを処理するのにかかる時間を調査しました。サイドチェーンを通して報酬計算を同時にリクエストする複数のクライアントを起動し、プロトコルの各段階別に完了までの時間を測定しました（図2）。

図2では、256件の広告を含む広告カタログにおいて、100人のユーザーが同時に支払いリクエストを実行した場合、支払いリクエスト100件を完了するのに約5秒かかることがわかります。これは、このサイドチェーンが1日あたり約170万件、1ヶ月あたり合計5100万件の報酬支払いリクエストを処理できることを意味します。

図2. 64（黄色）、128（青）、256件（緑）の広告数の広告カタログでTHEMISプロトコルを実行した場合の合計時間（秒）。復号化の正しさの証明と検証よる負荷が赤色で示されています。支払い計算を同時にリクエストするクライアントの数別の表示となっています。

100人のユーザーが同時に（１）報酬支払リクエストを生成し、（２）サイドチェーンを通して報酬計算をリクエストした場合、報酬計算にかかる時間は１クライアントにつき約5秒でした。毎月の支払いを想定した場合（つまり、ユーザーが毎月報酬をリクエストし決済される）、THEMISは1ヶ月あたり5100万人のユーザーに対応できることになります。

スケールアウト（水平スケール）：サイドチェーン上でスマートコントラクトが実行する計算は、大規模な並列化が可能です。しかし、Ethereum Virtual Machine（EVM）の１スレッド・イベントループは、並列・同時計算に対応していません。そのため、100以上のユーザーリクエストを同時に処理しなければならない場合、EVMのランタイムがスケーラビリティのボトルネックになってしまいます。これを克服するために、複数の並列サイドチェーンをつくりTHEMISをテストしました。各サイドチェーンはそれぞれ1つ以上の広告カタログを担当します。こうすると調整が複雑になる可能性がありますが、サイドチェーンの数に比例して報酬リクエストの処理数が増加するため、スケーラビリティはかなり向上しました。このように、THEMISは1日に数千万人のユーザーの同時使用をサポート可能な水準までスケールアップすることが可能です。

B.：クライアント側のパフォーマンスとリソース消費

クライアントでTHEMISルーチンを実行した場合のパフォーマンスとリソースへの影響を測定するために、3つの異なる広告カタログサイズ（広告64、128、256件）について、クライアントがローカルで報酬計算リクエストを生成する時間を測定しました。図3で示した測定結果は以下になります。

広告接触の暗号化：ユーザーの広告接触（インタラクション）配列の暗号化
リクエスト生成：報酬合計の復号化、復号化の正しさの証明の生成、平文回復

図3に示すように、256件の広告を含む広告カタログに対して、ユーザーが広告接触（インタラクション）を暗号化するための実行時間は0.1秒と短い物でした。また、同じ広告カタログサイズの場合、報酬計算リクエスト生成にかかる時間は約0.7秒でした。つまり、クライアント側で行う報酬計算リクエストは、ユーザーエクスペリエンスに大きな影響を与えることなく、汎用ラップトップやモバイルデバイス上で実行できることが証明されました。

報酬計算リクエストの発行とは別に、クライアントは定期的に支払いリクエストも行います。しかし、支払いリクエストは比較的頻度が少ない（例えば、毎月）ため、ユーザー側のレイテンシ（待ち時間）とリソース消費は実質的に無視できる程度と言えます。

図3: 異なる広告カタログサイズ別のクライアント側の報酬計算リクエストの実行時間。広告数は64、128、256件。256件の広告が掲載されている広告カタログでは、広告接触（インタラクション）の暗号化に0.1秒かかるのに対し、リクエスト生成に約0.7秒かかります。

こうした結果から、256件の広告を含む広告カタログを想定した場合、クライアント側での報酬計算リクエスト生成に必要なリソース消費は無視できる程度小さいことがわかりました。この結果は、ユーザーエクスペリエンスやエネルギー消費に影響を与えることなく、リソースに制約のあるデバイス（例えば、モバイルデバイス）上でも、実行する必要がある事を考えると非常に良い結果です。

パフォーマンスとスケーラビリティの考察

以上の結果をもとに、セクションの最初で述べた検証ポイントを確認します。

報酬計算リクエストと証明の生成の実行に、クライアントが消費する時間とリソースはどれくらいか

検証の結果を考えると、クライアント側の負荷はごくわずかであると結論づけられます。これは、ユーザーエクスペリエンスやエネルギー消費に影響を与えることなく、リソースに制約のあるデバイス（モバイルデバイスなど）でクライアントを実行したいと考えているため、重要な結果です。

256件の広告を搭載した広告カタログを想定した場合、サイドチェーンは1日に何件の支払いリクエストを処理できるか

図2の結果によると、100人のクライアントが同時に報酬リクエストを実行した場合、エンドツーエンドの報酬リクエストの処理には最終的に約5秒かかります。ネットワーク上で報酬リクエストを分散して実施すると仮定すると、THEMISは1日あたり約170万件の報酬リクエスト（エンドツーエンド）をサポート可能であり、1ヶ月あたりでは約5100万件となります。この数は、サイドチェーンを複数並列化してTHEMISを実行すれば、さらに増やすことができます。

サイドチェーン上で月に何件の匿名性を維持した決済を実行できるか

THEMISプロトコルは、報酬リクエストの決済に使用されるプライバシーを保護した支払い方式からは独立しています。たとえばAZTECを使用して、プライバシーを保護したトランザクションと証明のバッチ検証を行う場合、決済実行に必要な時間とリソースはTHEMISのスケーラビリティとパフォーマンスのボトルネックにはなりません。

最後に、THEMISはBrave Adsが想定するユーザー数やリワードリクエストの数に対応できるか

現在、Brave Adsは平均で約200件の広告を掲載しており、毎月約250万人のユーザーに支払いを行っています。したがって、THEMISは現在のBrave Adsの負荷をサポートすることが可能です。

脅威分析

本解析では、（１）スヌーピング、（２）リプレイ攻撃、（３）プロトコルに正直に従わないことによる不正行為が可能な計算量に制限のある攻撃者を想定しました。

ある攻撃者がCFとして行動し、ユーザーへの報酬支払や広告主への返金の業務について合意された処理手数料以上の金額を獲得しようとすることがあります。このような攻撃者はシステムの任意のノードを制御することが可能ですが（ PoAの限界）、バリデータ・ノードのマジョリティを制御することは不可能です。
または、ユーザーのプライバシーを侵害し、ユーザーの広告接触を盗み見（スヌーピング）しようとする攻撃者も想定されます。広告接触からは、ユーザーの関心や政治的/宗教的嗜好を明らかにすることができ、それをユーザーの手の届かないところで販売・使用する可能性があります。実際、こうした攻撃者は、システム内の任意のノードを乗っ取れますが、全てのユーザーを乗っ取ることはできません。つまりコンセンサスプールにランダムに選択されたn人の構成員のうち、最大でもk人しかコントロールできません（コンセンサスプールの構成員は、特集シリーズ第１弾で説明したように、しきい値公開鍵を共有しています）
また、広告主が合意した広告ポリシーの機密性を破り、広告報酬戦略を開示することで競合他社を有利にしようとする攻撃者もいるかもしれません。

ネットワーク参加者へのインセンティブ

分散型ネットワーク上の参加者が協力して正しくプロトコルを実行するよう促すためにインセンティブは重要です。THEMISプロトコルの参加者は、タスクを正常に実行するようにインセンティブが支払われます。BATトークンをそのために使用することができます。

キャンペーン・ファシリテーター（CF）は、キャンペーンを成功させるため正しく行動するよう、処理手数料という形でインセンティブが支払われます。重要なのは、プロトコルが正しく実行された場合にのみ処理手数料を支払うことです。キャンペーン終了時までにCFの行動に問題がなかった場合（チャレンジを受けても否決された場合）、FSCによって手数料が払われます。一方、行動に問題があるCFは広告主やユーザーからの信頼を失い、将来的に手数料を得る機会を失うことになります。さらに、コンセンサスプールの構成員とバリデータ・ノードには、システムの稼働を維持するために必要な作業を実行するために、暗号トークン（BATなど）でインセンティブが支払われます。

要約

本記事では、本特集シリーズの第１弾で紹介したTHEMISプロトコルの完全版をご紹介しました。THEMISは、サイドチェーンとスマートコントラクトを活用し、アドネットワークの中央機関を排除したプライバシー保護を徹底した広告プラットフォームです。

THEMISはどのアドネットワークでも利用可能ですが、今回はBATのエコシステムを段階的に分散化するアプローチを想定しました。Brave AdsとTHEMISは、現在のオンライン広告エコシステムの根本的な欠陥である「トラスト」と「ユーザーのプライバシーの侵害」を解決することで、既存のオンライン広告エコシステムの代わりになることを目指しています。また、BATを利用して、参加者の誰もが、ネットワークに有益なタスクを実施できるようにインセンティブを支払うことが可能です。

また、BraveはTHEMISを実行するために必要なライアント側とスマートコントラクトのコアなプロセスを実装し、公開しました。またこれを用いて、クライアントのリソース消費とエンドツーエンドのスケーラビリティを測定し、THEMISは本番においても、現在のBrave Adsの負荷に耐えられると結論しました。実験による評価では、プロトコルに参加するクライアント側のパフォーマンスへの影響は無視できる程小さいことが示されました。さらに、1つのサイドチェーン上で256件の広告を含む広告カタログを提供する場合に、THEMISは5100万人以上のユーザーが同時に利用できるだけの処理能力があることが示されました。

注釈

[1] Zerocash Paper

[2] Bulletproofs: Short Proofs for Confidential Transactions and More

[3] Monero

[4] Aztec Protocol

[5] Zether: Towards Privacy in a Smart Contract World

[6] Overview of Private Transactions in Quorum

[7] Verifiable Random Functions

[8] Vault: Fast Bootstrapping for the Algorand Cryptocurrency

[9] ETHDKG: Distributed Key Generation with Ethereum Smart Contracts

[10] Electronic Frontier Foundation

[11] The Tor project