THEMIS: レポートの完全性を担保した分散型広告プラットフォーム (第１弾)

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

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

2017年半ばに、BAT（Basic Attention Token）を紹介するホワイトペーパー[1]を公開して以降、何百万人ものユーザー、広告主、パブリッシャーの方々にBraveブラウザを介してBATを利用・獲得いただいています。 2017年から長い道のりではありましたが、現在分散台帳を使用したユーティリティートークンの最も成功したユースケースの1つとしてBATが認知されていることを大変誇りに思っております。

このBATトークンを「基盤」にして運営されるのがBATベースの広告エコシステムです。BATベースの広告エコシステムが目標としているのは、ユーザーのデータとプライバシーを守りながらユーザーのアテンション(関心)を価値化する手段を提供することです。そのために必要なことは、プライバシー保護を標準機能とすること、ユーザーが個人データの権限を取り戻すこと、Braveブラウザのユーザーが広告を視聴したりクリエイターに貢献することが可能な分散型マーケットを提供することになります。この基本方針を通して、オンライン広告業界の現状を変え[1]、広くはびこる不正行為[3] [3.1], [4]を排除し、市場の複雑化の問題[5] [6]やプライバシーの問題 [7] [8]を解決することがBraveのビジョンであります。

この目標の実現にむけて、Braveの研究チームではBATベースの広告エコシステムの更なる改良を目指し、プライバシー保護を徹底した分散プロトコルの開発に取り組んできました。本日は、その取り組みを紹介する特集シリーズの第１弾としてTHEMISをご紹介します。THEMISは、ユーザーや広告主からの信頼（トラスト）を一切必要としない、プライバシー保護を徹底した全く新しいタイプの広告プラットフォームです。THEMISを使うことで、以下の3つが可能になります。１）全ての参加者に可監査性を提供し、２）ユーザーに広告接触に応じた報酬を支払い、３）広告主には広告キャンペーンのパフォーマンスと課金の正確性の検証手段を提供することです。本記事では、THEMISのプロトコルとその基本構成についてご説明します。次の第２弾では、THEMISのスケーラビリティについて開発環境下での予備評価をご紹介する予定です。

図1. Brave Adsのユーザーにブラウザ上に配信される広告通知の例

デジタル広告のエコシステムの現状

ウェブサイトをデジタル広告を使って収益化にすることは最も一般的でしょう。しかしデジタル広告の世界には、市場の複雑化、不正の横行、過去最大のプライバシー侵害などの根本的な欠陥があります。さらに、ネット広告をオプトアウトするユーザーが増えており、パブリッシャーは毎年数百万ドルの広告収入を失っています。実際に広告ブロッカーを使用するユーザー数は増加しています（現在、世界のネットユーザーの47% [13]）。

こういった問題を解決しようと、学会や業界では新しい収益化システムの設計がされています。多くの場合、ユーザーへの選択肢の提供、プライバシー保護、不正防止、パフォーマンスの向上などを重視した設計になっています。例えばPrivad [11]やAdnostic [12]は、プライバシーに配慮した広告に焦点を当てた学術的なプロジェクトです。ただ、こうしたシステムが普及していない大きな理由としては、１）拡張性がないこと、２）広告取引を処理するにあたり、ユーザーがシステムの中央機関を信頼する必要があること、３）広告主がキャンペーンのパフォーマンスを正確に測定できないこと、といった問題があげられます。

他にも問題があります。適切な「可監査性」の不在です。広告主への課金とパブリッシャーへの収益配分は、広告ネットワークが独占的に決定しています。つまり悪意のある広告ネットワークであれば、広告主に過大に課金したり、パブリッシャーに過少に配分することが可能だということです。もう一つの問題は「否認不可性」です。報告の内容が実際の広告閲覧やクリックと一致しているかどうかの証明を広告ネットワークは行わないからです。

図１．THEMISの大まかな概要を示した図。広告配信と広告接触に関するレポーティングの仕組み。ユーザーは広告接触により報酬を得ます。THEMIS内で、キャンペーンマネージャーと広告主が広告キャンペーンに合意し、その内容がサイドチェーン上でスマートコントラクトにエンコードされます。ユーザーはBraveブラウザを介してスマートコントラクトに報酬を要求し、スマートコントラクトは暗号化されたプロトコルを実行します。こうして、分散化、透明性、プライバシー保護の実現を目指しています。

Braveのアプローチ： THEMIS

この特集シリーズでは、THEMIS（図１）をご紹介します。THEMISはプライバシー保護を徹底した広告プラットフォームです。サイドチェーン上のスマートコントラクトを活用することで、広告ネットワークの中央集権的管理を不要にしており、分散型広告システムの実現にむけて大きく前進したものとなっています。

なお、Braveは段階的に分散化を進める予定です。つまり本日の記事でご紹介するシステムでは完全な分散化は実現されていません。更なる分散化への手順は今後の記事で議論していきます。

Brave Adsは現在、プライバシー保護のための暗号プロトコル、クライアントデバイス上での広告マッチング、その他の匿名化技術を使用することで、ユーザーのプライバシーと匿名性を保護しています。たとえば、Braveのサーバーは、ユーザーがどの広告と接触したかを知ることはできず、ユーザー個別の興味や閲覧習慣に関するデータを受け取ることはありません。THEMISのプロトコルは、Brave Adsと同じ水準の強固な匿名性を維持しつつ、Brave Adsのエコシステムから分散化を一歩押し進めたものになっています。なお、THEMISはBATアポロミッション[14]とも深く関係しています。BAT Community-run AMA [15]でお伝えしているように、BATアポロミッションの主な目標は、透明性の向上、取引コストの削減、Brave Adsのさらなる分散化となっているからです。

強固なプライバシー保護機能に分散型システムを組み合わせたことで、THEMISでは以下のことが実現します。

「可監査性」と「否認不可性」の問題の解決。そのために、全ての参加者が各自の行動の正当性を証明する暗号を生成する仕組みとし、各メンバが―プロトコルを遵守しているかを全員が確認することを可能としています。
エンドユーザーのプライバシーを侵害せずに、広告主に広告キャンペーンのパフォーマンスに関する必要な情報を提供。このレポートの計算上の「完全性（データが正確で改ざんされていないこと）」を保証することで、広告主は個別のユーザーを把握することなく、広告を視聴・接触したユーザーの数を正確に把握することが可能です。

技術的な背景

このセクションでは、THEMIS の仕組みと基本構成に関する技術的な背景の概要とTHEMIS がそのような技術を活用する理由や手法について説明します。

パーミッション型ブロックチェーン

THEMISの分散型広告プラットフォームは、スマートコントラクト機能を備えたブロックチェーンを必要とします。スマートコントラクトを使うことで、中央機関を通さずに契約や支払いの履行が可能になるためです。例えばEthereumのメインネット（本番ネットワーク）上でもTHEMISを動作させることはできます。しかし、Ethereumには、スループットが低い、ガスコストが高い、スケーラビリティが低いといった問題があります。そのためTHEMISはパーミッション型ブロックチェーン、具体的にはPoA（Proof-of-Authority）ベースのブロックチェーンを使用します。

PoAベースのブロックチェーンの分散台帳は、許可された複数のバリデータ・ノードによるコンセンサスで運用されています。PoAでは、バリデータがIBFT/IBFT2.0やCliqueといった高速のコンセンサスプロトコルを使用できるためブロック生成が速くなり、従来のPoW（ProofｰofｰWork）ベースのブロックチェーンよりもスループットが高くなります。

従来のパーミッションレス型ブロックチェーン（BitcoinやEthereumなど）と比べて、コンセンサスを取るノードは少なく、全てのノードが認証済みとなります。Braveの場合は、パブリッシャーなどの企業がバリデータグループの候補となると考えています。

暗号ツール

機密性

THEMISでは準同型暗号化方式(加法型)を使用し、ユーザーの行動（広告クリックなど）に関してプライバシーを保護したまま、ユーザー別の広告報酬を計算します。この暗号化方式は、任意の公開鍵・秘密鍵([[\sk, \pk]])のペアごとに4つのアリゴリズムで決定されます。

暗号化：暗号化関数は、公開鍵(pk)とメッセージ(M)から暗号文(C)を生成します。[[\ctxt = \enc(\pk, \message)]];
復号化：復号化関数は、暗号文(C)と秘密鍵(sk)から復号したメッセージを生成します。[[\message = \dec(\sk, \ctxt)]];
署名：署名関数は、メッセージ(M)と秘密鍵(sk)からメッセージに署名(S)を生成します。[[\signature = \sign(\sk, \message)]];

検証：最後に署名検証関数は、署名(S)と公開鍵(pk)が入力されると、署名の正誤([[\bot, \top]])を出力します。[[\signverify(\signature, \pk)\in\{\bot, \top\}]];

同じ鍵をつかった暗号文が2つある場合、

$$ \ctxt_{1} = \enc(\pk, \message_{1}), \ctxt_{2} = \enc(\pk, \message_{2}) $$

準同型性（加法型）があるため、この暗号文を２つ足したものと、メッセージを２つ足してから暗号化したものとでは、同じ結果が得られます。

$$ \ctxt_{1} + \ctxt_{2} = \enc(\pk, \message_{1} + \message_{2}) $$

こうした準同型性をもつ暗号としてElGamal [9] や Paillier [10] 等の例があります。

完全性

THEMIS は、復号文の正しさの証明にゼロ知識証明（ZKP）を利用しています。ZKPはある人（証明者）が他の人（検証者）に対し、ある入力された秘密情報が「真である」ことを「証明」する方法です。その過程で、証明者は「この情報は真である」以外の情報を検証者に一切開示する必要がありません。Braveは、これらの証明を$\Pi$, と表示し、その検証結果を$\verify(\Pi)\in\{\bot, \top\}$と表示します。

トラストの分散

THEMISは、機密情報を暗号化する公開鍵・秘密鍵ペアを広告キャンペーンごと生成しますが、その際にトラストの分散を行います。そのためには、分散鍵生成（DKG）プロトコルを使用し、任意のグループ内で、公開鍵・秘密鍵のペア[[(\sk_T, \pk_T)]]を分散させます。グループ内の各プレイヤーは分散された秘密鍵の一部[[\sk_{T_{i}}]]を保有するため、どのプレイヤーも秘密鍵の全体像[[\sk_{T}]]を知ることはありません。

さらに、この結果で得られる鍵ペアにはしきい値がセットされており、鍵を分散生成したプレイヤーのうち一定数以上が参加しないと復号または署名などが実施できません。

Braveは、Schindler氏ら[11]が公表したDKGプロコルに近いものを使用しています。

分散鍵を生成するグループを選定するために、THEMIS は「検証可能擬似乱数関数（VRF）」を使用しています。一般的に VRF は、乱数の生成と、その乱数が正しいことの証明を行うものです。THEMISでは、VRFを利用してランダムにユーザーグループを選択し、分散鍵を生成します。VRFは、任意の公開鍵と秘密鍵のペア[[(\VRFsk, \VRFpk)]]に対し、乱数の出力と乱数生成の正しさに関するゼロ知識証明の出力を行います

システムの特性と保証

THEMISを設計する際に重視した主な特性には、プライバシー、説明責任、報告の完全性、分散化などがあります。

プライバシー

広告エコシステムを持続可能なものにするために、Braveはプライバシーを「ユーザーや広告主が、それぞれ重要な個人情報やビジネス情報を開示することなく本システムを使用できること」と定義づけました。

ユーザーにとってのプライバシーとは、広告主や他の関係者や盗聴者に自分の興味や好みを開示せずに広告に接触できることを意味します。THEMISは、広告と接触する際だけでなく、広告報酬を請求する際もユーザーのプライバシーを保護します。
Brave Adsでは、今でも広告主のプライバシーを保護しています。広告主にとってのプライバシーとは、競合他社に広告出稿条件（例：各広告視聴の報酬金額など）を詮索されることなく広告キャンペーンを設定できることです。THEMISでは、全てのプロセスで広告出稿条件の機密性が守られています。一方、ユーザーはこの条件にそって報酬を請求可能です。

分散化と可監査性

既存のシステムでは、ユーザーのプライバシー保護の観点であれ、広告課金の観点からであれ、適切なプロトコルの実行を管理・調整するために中央機関が必要です。もしこの機関（信頼できると考えられている）が、恣意的にユーザーに対する報酬の振り込みを拒否したり違う金額を振り込んだりしたらどうなるでしょうか。もし、ユーザーの広告接触に応じて支払うべき金額以上の金額を広告主に請求したら？また、広告キャンペーンを設定する際に、広告主が設定した通りの広告出稿条件が適用されないとしたら？

分散化と透明性の確保は、Braveの広告エコシステムの主要な目的です。これを実現するために、THEMISはスマートコントラクト機能を備えたパーミッション型ブロックチェーンを利用しています。

スケーラビリティ

広告プラットフォームは、シームレスに拡張し何百万人ものユーザーにサービスを提供できる必要があります。しかし、今、出てきている主要なシステムでは実現できません。Braveは、システムが実用的であるためにはスケーラビリティが重要であると考えています。THEMISでは、数百万人のユーザーに対し広告を配信でプライバシー保護をするだけではなく、広告報酬の支払いを可能な限りタイムリーに完了させる必要があります。

完全性

既存のシステムとは違い、THEMIS は「信頼できる中央機関」を持ちません。そのため、ユーザーと広告主の両方に、実行すべき演算内容とその演算結果の真正性を検証する仕組みを提供する必要があります。この完全性を保証するために、ゼロ知識証明を使用する必要があります。すべての参加者が広告の課金とレポートの正確性や妥当性を証明・検証できるようにする必要があります。

システムの概要：暫定アプローチ

本記事の後半では、THEMISの基本的な原理と手順を暫定アプローチに基づいてご説明したいと思います。次回の記事では暫定アプローチから進んで、システムの分散化についてご説明をする予定です。

この暫定アプローチは、プライバシーを保護した分散型広告システム実現にむけた初期的なものです。現時点の目標は、広告キャンペーンを設定し実際のユーザー接触に基づいて正しく課金が行われる仕組みを作ることです。さらに、視聴された広告をトラッキングすることで１）広告主がキャンペーンのフィードバックを得られ、２）ユーザーが広告接触により報酬を得られることも目標とします。また、広告出稿条件とユーザー行動のプライバシーは保護される必要があります。

暫定アプローチでは3つの「役割」を想定します。１）ユーザー、２）広告主、３）キャンペーンマネージャー（CM）です。ユーザーは広告主が出稿した広告を視聴し接触することで報酬を得られます。CMはa）プロトコルを調整し、b）広告視聴のレポートを作成し、c）広告主が設定した出稿条件に基づきユーザーに支払う報酬を計算します。

注：この暫定アプローチでは、完全には信頼できない（semi-trusted）キャンペーンマネージャーを想定しています。次の記事でご説明する完全なTHEMISプロトコルでは、この役割はなくなります。今回は初めてのご紹介のため、THEMISの説明をわかりやすくするためにCMを登場させています。

プライバシーを保護した広告マッチング

THEMISでは、Brave Rewardsの現行のアーキテクチャと同様に、ユーザーが最新の「広告カタログ」をダウンロードします。このカタログには、配信中の広告キャンペーンの広告とそのメタデータが含まれています。CMはユーザーが定期的にダウンロードするこの広告カタログを管理・提供します。

広告のマッチングは、ローカル環境で行われます。Brave Rewardsと同様の方法で、プレトレーニングモデルと、ウェブ閲覧履歴から出力されたユーザーの興味に基づいて実施されます。ユーザーの興味に合わせた広告配信やマッチングのために、ユーザーのデバイスからデータが送信されることは一切ありません。ウェブ閲覧データのウォールドガーデンを構築することで、ユーザーのプライバシーを保護しながら最適な広告マッチングを実現します。

広告閲覧のインセンティブ

広告接触に対しユーザーに報酬を発生させる仕組みはTHEMISの中核機能です。広告の閲覧、クリックごとにBATの報酬が発生します。ユーザーへの報酬金額は、広告によって異なります。この金額は、広告クリエイター（広告主など）とキャンペーンマネージャー（CM）との間できまります。ユーザーは定期的に報酬を請求します（毎週または毎月など）。図４では暫定アプローチにおける支払い手続きと報酬請求のステップを示しています。

暫定アプロ―チ

ここからTHEMISの暫定版における３つのプロセスをご説明します。

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

広告主が、広告カタログに広告キャンペーンを掲載するためには、まずキャンペーンの出稿条件（広告別の報酬、ユーザー別のインプレッション数など）をポリシーとしてCMと合意する必要があります（図４のステップ1）。

広告キャンペーン内で使用する広告とその報酬条件について広告主とCMがオフバンドで合意すると、CMは合意されたポリシーをベクタ [[\policyvector]]にエンコードします。各インデックスは、閲覧/クリック毎の報酬量を表します（例：Ad1: 0.4 BAT、Ad2: 2 BAT、Ad3: 1.2 BAT）。CM はこのベクタを非公開で保存し、広告主はこのポリシーが適切に履行されることを信頼します（この問題については、THEMIS プロトコル改良版で対応します。次回の記事をご参照下さい）。このポリシーベクタ内のインデックスの並びは、広告カタログ内の広告インデックスの順序と同じになります。

図４．暫定アプローチにおけるユーザーへの報酬支払プロセスの大まかな概要。広告主は、広告別のクリック報酬を競合他社に知られることなく設定可能です。ユーザーは、接触した広告を知られることなく、報酬請求が可能です。

広告主は、キャンペーンの広告条件をCMと合意したうえで、キャンペーンに必要な資金をエスクロー口座に振り込みます。キャンペーンの終了時に、未使用の資金（すなわち、クリックなどの接触が想定より少なくエスクローされた資金をすべて使い切らなかった場合）は、リリースされて広告主に戻ります。

話を分かりやすくするために、本セクションでは、複数の広告キャンペーンを実行している1人の広告主を想定しています。現実世界では、多くの広告主が同時に多くの広告キャンペーンを実行することができます。また、広告ポリシー（出稿条件）も、ユーザーへの報酬トークン数のみであるとしています。

第二段階: 広告報酬の請求

ユーザーはローカル環境に「接触ベクタ」を生成し、そこにカタログ内の広告毎の閲覧/クリック数を記録します（例：広告1：3回閲覧、広告2：0回閲覧、広告3：2回閲覧）。

支払いのタイミングに合わせて、「接触ベクタ」の情報を暗号化します。技術的には、広告別のユーザーの閲覧/クリック数情報をもつ「接触ベクタ」として[[\adclicks]] （図４のac）を生成します。[[\adclicks]]の要素である[[i]]が[[\ad_i]]の閲覧/クリック数を表しています。

支払いのタイミングに合わせて、ユーザーは暫定的な鍵ペア[[\sk, \pk]]を生成し、請求の匿名性を確保します。その後、ユーザーは、この公開鍵を用いて、[[\adclicks]]を暗号化します。

$$ \encryptedvector = \left[\enc(\pk, \nrinteractions_1)\ldots, \enc(\pk, \nrinteractions_{\nrads})\right] $$

[[\nrinteractions_i]]が、広告iとの接触回数を表し[[\nrads]]が広告総数を表します。次にキャンペーンマネージャー（CM）に[[\encryptedvector]]を送信します（図４のステップ2a）

重要な点は、キャンペーンマネージャー（CM）は、受信したベクタを復号化できないため、ユーザーの広告接触（とその興味）については知る余地がないことです。代わりに、この暗号スキームの基本的な性質である準同型性（加法型）を利用し（「技術の背景」で先述している通り）、暗号化されたベクタ[[\encryptedvector]]にエンコードされている接触回数に基づいて支払金額の合計を計算します（図４のステップ2b）。

より具体的には、CMは以下の手順で支払い金額の合計を計算します。

$$ \aggrresult = \sum_{i=1}^{\nrads} \policyvector[i]\cdot\encryptedvector[i] $$

[[\policyvector[i]]]はベクタ内にある広告の広告条件となります。CMは計算結果に署名をします。

$$ \signreward = \sign(\aggrresult, \sk_{CM}) $$

そして、この2組の結果[[(\aggrresult, \signreward)]]をユーザーに返します。

この2組の情報を受け取ると（図４のステップ2c）、ユーザーは署名を確認します。

$$ \signverify(\aggrresult, \signreward) $$

そして、計算結果を復号化します。

$$ \decryptedaggr = \dec(\sk, \aggrresult) $$

最後に、復号化の正しさに関するゼロ知識証明を生成し、復号化の正しさを確認します。[[\proofresult]]（例えば、復号化したものと暗号の総和が一致するなど）。

第三段階: 支払い手続き

最後に、ユーザーは支払いのためのリクエストを生成し、CMに以下の4組のデータを送信します（図４のステップ3a）

$$ (\decryptedaggr, \aggrresult, \signreward,\proofresult) $$

次に、CMは支払い請求が有効であることを証明します（図4のステップ3b）。具体的には、支払い請求が以下のいずれかの場合に拒否をします。

$$ \signverify(\pk_{CM}, \signreward, \aggrresult) = \bot $$

$$ \verify(\proofresult) = \bot $$

上記いずれでもなかった場合、CMはユーザーに正しいと証明された金額（[[\decryptedaggr]]に等しい金額）を送信します。

広告主へのレポート

広告主に広告キャンペーンに関するフィードバックを提供することもTHEMISの目的です。広告主は課金手続きの中で、CMが報告する広告がユーザーの閲覧/クリック回数が正しいかどうかを検証できる必要があります。

これを実現するために、更新された広告カタログがダウンロードされるたびに新しい鍵ペア[[\pk_{T}]]を生成します。この鍵は、adclicksベクタの暗号コピーをCMに送付するためのものです。（図４のステップ2aを思い出してください）。

このステップで使用される鍵[[\pk_{T}]]は、分散的に生成したしきい値公開鍵です。しきい値公開鍵の生成には、複数のユーザーによるグループ（ユーザはこのグループに参加するようにインセンティブを与えられます。このインセンティブの調整方法の詳細は本記事では割愛します）、つまり「コンセンサスプール」の形成が必要です（コンセンサスプールの形成方法の詳細については、次回の記事でご説明します）。「コンセンサスプール」は分散鍵生成アルゴリズムを実行します。これにより、分散公開鍵[[\pk_{T}]]が生成され、各コンセンサスプールの構成員は秘密鍵の一部[[\sk_{T,i}]]を持つことになります。公開鍵[[\pk_{T}]]は CM に送信され全ユーザーに共有されます。

そのため、各ユーザーは[[\encryptedvector]]以外に、[[\encryptedvector’]]もCMに送信します。

$$ \encryptedvector’ = \left[\enc(\pk_{T}, \nrinteractions_{1}), \ldots, \enc(\pk_{T}, \nrinteractions_{\nrads})\right] $$

広告キャンペーン終了時には、ユーザーが生成した全ての[[\encryptedvector’]]を処理して、広告主ごとに支払い完了した報酬金額を計算します。ユーザーへの支払いを計算した際の準同型性（加法型）がここでも使えます。CMは広告主ごとの支払額を[[\encryptedvector’]]を合計することで計算できます。このように、あるキャンペーンの[[\encryptedvector’]]が全数揃っているとして、キャンペーンiの支払金額の暗号化された合計は、CMによって以下の方法で計算されます

$$ \encadspayout_i = \sum_{i=1}^{\nrads}\encryptedvector’_{0}[i] + \cdots + \encryptedvector’_{\nrusers}[i] $$

[[\nrusers]]はユーザーの人数を表します。個別の[[\encadspayout_{i}]]はしきい値鍵ベアを使って復号化されます。それには、コンセンサスプールから決められた数の構成員が揃う必要があります。復号化された数字は広告主に共有され、CMが広告接触に基づいてユーザーに支払うために使った金額が正しいかを検証できます。

まとめ

本日の記事ではシリーズの第一弾として、Braveの研究チームがプライバシー保護を徹底した広告プラットフォームTHEMISを設計・開発した理由と目的についてお伝えしました。Brave Adsと同様に、THEMISはユーザーの匿名性を徹底的に守ります。さらに、分散化されておりユーザーと広告主からの信頼（トラスト）を一切必要としません。THEMISのコアプロトコルは、１）全ての参加者に可監査性を提供し、２）ユーザーに広告接触に応じた報酬を支払い、３）広告主には広告キャンペーンのパフォーマンスと課金の正確性の検証手段を提供することです。

さらに、THEMISのコアプロトコルの単純化された暫定アプローチをご説明しました。このアプローチで実現したことは以下の通りです。

ユーザーは、広告接触によって発生した報酬を受け取ります。Brave Adsと同じですが、THEMISはユーザーがどの広告と接触したかをBraveや広告主に開示しません。
キャンペーンマネージャーは、ユーザーや広告主の潜在的な競合他社に情報を開示することなく、各広告の価格条件（ポリシー）を正しく履行することができます。

しかし、この暫定アプローチでは、THEMISが実現すべき特性の全ては実現できていません。特にトラストに問題があります。この暫定アプローチでは、キャンペーンマネージャーがプロトコルの調整を行います。つまり、ユーザーからの支払い要求を処理し、報酬を計算します。さらに、CMは広告出稿条件（ポリシー）を非公開で保存しており、ユーザーと広告主は、支払金額が計算される際に出稿条件が正しく履行されていることを信頼する必要があります。最後に、この暫定システムでは報酬支払い時のプライバシーを保証した仕組みになっていません。

次回の記事では、単純化された暫定アプローチを改良したTHEMISプロトコルの全体像をご紹介します。また、スケーラビリティに関する評価も行い、THEMISの拡張時の対応をお伝えする予定です。