Augur をコードベースで読み解いてみる

面白いですね、Augur.

※素人がお送りするので誤りを含む可能性があります。ご了承ください。

スポンサーリンク

Augur とは

イーサリアム上に構築される非中央集権型の予測市場のプラットフォームです。

予測市場 (≒賭け) では情報の非対称性により仲介者の利益が大きく、参加者が不利な状況に置かれるケースが容易に発生します。Augur では仲介者の役割をスマートコントラクトに持たせることで公正かつ透明性の高い予測市場を作ることを目的としています。

また、現実世界を反映したオラクルとしても機能させることができます。

Augur の仕組み

マーケット作成者 (∈ユーザー) が予測マーケットを作ります。これに対し、トレーダー (∈ユーザー) は ETH をデポジットして予測に参加することができます。これは群衆の知恵と呼ばれ、大人数での予測は専門家の判断より優れているという考えの下に成り立っています。

トレーダーの参加を締め切った後、レポーター (∈ユーザー) が予測の正誤判定を行います。予測が当たったトレーダーにデポジットされた ETH が分配されます。

マーケット作成からファイナライズまでの流れは以下の図のようになります (出典:ホワイトペーパー)。

この内容について、少し詳しく見ていきましょう。

マーケットの作成

マーケット作成者は以下の内容を設定します。

  • イベント終了日時
  • 指名レポーター
  • 判決ソース (レポートの根拠)

また、二種類の保証金を払う必要があります。

  • 有効性保証金 (validity bond) [ETH]
  • 指名レポート不参保証金 (designated report no-show bond)
    • 不参 gas 保証金 (no-show gas bond) [ETH]
    • 不参 REP 保証金 (no-show REP bond) [REP]

有効性保証金は直近で無効判定となったマーケットの割合、不参 REP 保証金は直前の手数料期間中に報告を怠った指名レポーターの割合によって自動的に変動します。

マーケットへの参加

イベントのアウトカム (想定される結果の選択肢) を予測し、アウトカムのシェアを取引します。

予測の有効性

もしいずれの結果も事実と異なるような予測を作ると、この予測は無効となります。

クリエイターが無効になるような予測市場を生成することを防ぐため、有効性保証金が設けられています。これは有効な予測マーケットを作成すれば返却される保証金です。

正誤判定メカニズム

指名レポーター (クリエイター本人もしくは他の誰か) が正誤判定の期日から 3 日以内に結果の報告をすることで、マーケット作成者は不参保証金を回収することができます (Designated Reporting)。

しかし、期限内に結果が報告されなければ市場に公開され、誰でも報告可能になります (Open Reporting)。不参保証金はマーケット作成者ではなく、この期間中に最初の報告を行ったユーザー (First public reporter) に与えられます。

これはユーザーによる報告を迅速に行うための動機付けとなります。 また、不参 gas 保証金があることで、ファーストパブリックレポーターの負担する gas が高く、損失が出るという事態を防いでいます。

このようにして指名レポーター、もしくはファーストパブリックレポーターによる暫定的アウトカム (イニシャルレポート) が作成されると次の手数料期間までの待機期間に入ります。

待機期間は争議期間の開始時刻を全マーケットで統一するために設けられています。争議期間の開始時刻は毎週一回訪れます。暫定的アウトカムの作成から次の開始時刻までが待機期間となります。また、手数料期間は争議期間と完全に一致します。

報告への異議申し立て

最大 7 日間の待機期間終了後、異議を申し立てることができるようになります (Dispute Round)。争議期間中 (7 日間) に REP をステークして、正誤判定の暫定結果に対する異議を申し立てます。ステークの累計金額が争議保証金額 (< フォーク閾値) を超えると争議成功として新たな暫定的アウトカムが生成され、再び待機期間に入ります。

申し立てが通らない (争議失敗)、もしくは異議が無くなれば最終結果として確定し、マーケットが閉じます。

機能上のフォーク

フォークというと、仕様の分裂による別のブロックチェーン、暗号通貨の誕生を意味することが多いですが、Augur にはこれと別に機能としてのフォークが実装されています。

フォークは争議期間内にステークされた REP が全 REP 発行量の 2.5% に達したときに発生します。フォークが発生すると、ユニバースが分裂します。ユニバースは言わばパラレルワールドのような状態で、それぞれ異なるアウトカムが正しいと信じられている世界です。

REP はユニバースごと別々に存在するため、フォークが発生すると REP 保有者は定められた期間内 (60 日間) にいずれかのユニバースに REP を移行する必要があります。移行は不可逆な操作であり、これによってアウトカムの正しさの確認を市場に委ねる形となります。移行後の各ユニバースにおける REP について、市場でそれぞれの価値が決定されていくためです。

これを実現するためにはユニバース別に分裂するそれぞれの REP が取引所で扱われる必要があるなどの課題もあります。

Participation Token

REP 保有者は手数料期間に一度 PT を購入することができます。手数料期間が終了すると購入の際に支払った REP は各々の手元に戻り、手数料期間中にプールされたレポーティング手数料 (+有効性保証金) が PT 保有者に支払った REP の比率に従って分配されます。

PT はバージョン2で廃止されるとのことです (後述)。

Fee Token

PT 保有者は PT により分配金を受け取る権利を有していますが、アウトカムを作成 (=イニシャルレポートまたは争議を開始) したレポーターは手数料トークンによってこの権利を有しています。

PT はその手数料期間にプールされた手数料が分配の権利の対象になりますが、手数料トークンはステーク中に経過したすべての手数料期間を対象とします。ただし、ステークした暫定的アウトカムが最終結果にならなければ、ステークした REP を失うことになります。

以上より、オラクルと予測市場を維持するために REP トークンが用いられ、レポーターは誠実な態度をとる
(=正しい事実を認定し、誤った事実に異議を唱える) ことが最も有益であるインセンティブ設計となっています。

バージョンアップデート

v2 のアップデート内容は以下の通りです。

  • DAI Integration: DAI を採用し、ボラティリティの減少を図る
  • Use or Lose Forking: +5% のボーナスを提供することでフォーク中の REP 移行を勧めていたが、フォーク期間終了後にこれを許可しない形に
  • Auction-Based REP Price Oracle: 報告の手数料は REP の価格に基づいて決定され、この価格オラクルを手動で一元管理していたが、必要に応じて REP を発行し、ダブルオークションにより価格オラクルを決定する
  • Buy Back & Burn Fee System: PT の廃止
  • ERC-777 Support
  • Variable Validity Bond: 有効性保証金がマーケット作成者により操作可能になり、これを高めに設定することで予測マーケットが有効になると考えていることをアピールできる
  • Invalid as Explicit Outcome
  • Burning Dispute Profits: 予測マーケットのファイナライズを意図的に遅延させることを防止する
  • Accelerated Bond Increses
  • Optional messaging for dispute contributions
  • Designated Report Time reduced to 1 day from 3 day: 指名レポートの期間を短縮する
  • Continuous Dispute Rounds: 異議申し立てが通ると手数料期間なしで次の暫定的アウトカムに対する争議期間が開始される
  • Trading API Changes
  • MailBoxes:Gas & Transaction Optimizations
  • Trading:Gas & Transaction Optimizations

総括して、予測マーケットのファイナライズまでの期間の短縮、gas の削減、考えの発信方法の多様化などが盛り込まれています。

PT の廃止

手数料期間に PT を REP 建てで購入することで分配を行っていましたが、毎度 gas を消費することは非効率であると考えられます。そこで、v2 ではプールした手数料に対してオークションを行い、集まった REP を焼却することで REP の価値を高め、実質的に手数料を分配するという方針が打ち出されました。

スマートコントラクトの構造

Augur Core について、augur-core/contracts 以下のディレクトリの内容は以下のようになっています。

  • factories:Augur のプラットフォーム全体、予測マーケット、トークンなどのコンストラクタ
  • libraries:データ構造を記述したライブラリ群
  • reporting:プラットフォーム、予測マーケット、トークンなどの作成、操作
  • trading:オーダーの作成や取得、シェアの発行や決済、ファイナライズした予測マーケットに対する収益の請求

コード読む前に Augur を知らないと!と思ったら時間が過ぎ去りました。次回、それぞれの内部について詳しく見ていくことにします。

タイトルとURLをコピーしました