2018.12.12

ステーブルコイン3種（USDC, PAX, GUSD）の実装比較

こんにちは。F.S.です。

2018年はステーブルコインが大流行でした。
今回は2018年9月に続々とローンチした新たな3種の法定通貨担保型ステーブルコイン（USDC, PAX, GUSD）の実装にフォーカスしてみます。これら3種のステーブルコインはすべてEthereumプラットフォームにおいてERC20互換トークンとして発行されています。
文末にて比較表を載せていますので、取り急ぎ結論を知りたい方はまとめを参照ください。

こちらは2018年12月7日時点でのトークン時価総額です。ステーブルコインにおいて価格はほぼ $1 なので、時価総額は供給量に依存します。

出典：CoinMarketCap

それでは市場供給量の多い順にみていきます。

USD//Coin（USDC）


https://www.centre.io/usdc

USDCはアメリカに拠点を置くFintech企業Circle社（Poloniex取引所）とCoinbase取引所によって発行されたステーブルコインです。Circle社を母体に設立されたステーブルコイン発行プロジェクトCENTREを利用して作成されています。担保にしているドルの積立金は大手会計事務所のグラントソントン・インターナショナルが監査を行っているとのことです。

USDCの実装

前述の通り、USDCはCENTREコントラクトを使って作成されています。つまり、CENTREトークンのインスタンスのひとつがUSDCトークンということになります。

CENTREトークンは ZeppelinOS（zOS）を利用してコントラクトのアップグレードを可能にしています。この仕組みは、以前 T.M.メンバーのブログ（ZeppelinOS におけるコントラクトのバージョンアップの仕組みについて）で紹介されいます。

コントラクトの構成は下図のようなイメージになります。

CENTREトークンのプロキシである FiatTokenProxy は、zOS の AdminUpgradeabilityProxy そのものです

トークンのコントラクトはFiatTokenV1 に実装されています。
実装はシンプルで、次のコントラクトを継承しています。

  • ERC20（外部依存）
    • ERC20のインターフェースに沿ったインターフェースを定義するもの
    • OpenZeppelinトークンコントラクトのERC20（v1系）に依存
  • Ownable
    • コントラクトのオーナーアドレスを変更できるようにするもの
    • OpenZeppelinオーナーシップコントラクトのOwnableと同等の機能
      （ソースコード中にはZeppelinOS Labのupgradeability_ownershipから拝借して改変したと記載あり）
  • Pausable
    • 鋳造・送金などの関数利用を一時停止できるようにフラグを制御するもの
    • OpenZeppelinライフサイクルコントラクトのPausableと同等の機能
  • Blacklistable
    • 特定アドレス（ブラックリスト）に鋳造・送金などの関数を利用させないようにするもの

その他、FiatTokenV1 内の実装においては、鋳造者（minter）の管理機能がありますが、ERC20および mint / burn の実装においては特筆すべきものはありませんでした。

USDCの権限モデル

CENTREトークンの権限には以下のものがあります。

  • admin（AdminUpgradeabilityProxy）
    • トークンコントラクトをアップグレードできる権限
  • owner
    • トークンコントラクトのオーナー権限
    • owner, masterMinter, pauser, blacklisterのアドレスを変更できる
  • masterMinter
    • minterを登録・削除する権限
    • masterMinter自身がmintすることはできない
  • minter
    • mint可能な権限で、複数人存在することができる
    • minterごとにmintできる上限額が定められている
  • pauser
    • 一時停止フラグをオン・オフする権限
  • blacklister
    • ブラックリストにアドレスを登録・削除する権限

USDCのソースコード

Paxos Standard（PAX）

https://www.paxos.com/

ニューヨーク州規制当局より認可を受けたステーブルコインです。米連邦預金保険公社（FDIC）に認可された米国国内の銀行の複数口座に発行するPAXと同額の準備金を保有しており、withumという税務・経理に関する企業の監査を受けているとのことです。

PAXの実装

CENTREトークン同様に zOS を利用しています。

トークンのコントラクトは PAXImplementation に実装されています。このコントラクトにすべての実装があります。

機能的にはCENTREトークンとほぼ同等です。

  • ERC20の実装
  • 変更可能なオーナー
  • 一時停止フラグ
  • 凍結アドレス管理（CENTREトークンのブラックリスト相当）
  • 供給量の増減管理（mint / burnに相当するもの）

PAXの mint / burn はOpenZeppelinなどで標準的な mint / burn の実装とは違い、供給管理者（supplyController）の残高を更新するだけの実装になっています。したがって、中央のsupplyControllerを介してトークンを mint / burn する方式になっています。

PAXの権限モデル

PAXトークンの権限には以下のものがあります。

  • admin（AdminUpgradeabilityProxy）
    • トークンコントラクトをアップグレードできる権限
  • owner
    • トークンコントラクトのオーナー権限
    • 一時停止フラグのオン・オフができる
    • owner、lawEnforcementRole、supplyControllerのアドレスを変更ができる
  • lawEnforcementRole
    • 凍結アドレスの管理権限
    • アドレスの管理と凍結アドレスがもつ残高を消し去る（wipe）ことができる
    • lawEnforcementRoleのアドレスを変更することができる。
  • supplyController
    • トークンの供給権限
    • 供給トークンを増減させることができる
    • supplyControllerのアドレスを変更することができる。

PAXのソースコード

  • ソースコードレポジトリ（GitHub）
    https://github.com/paxosglobal/pax-contracts
    執筆時のコミットバージョン：9090650238e9576f1284764f132d72af9b0d267a
    ※レポジトリには3社のコントラクト監査報告書（audit-reports）も格納されています

Gemini Dollar（GUSD）

https://gemini.com/dollar/

ウィンクルボス兄弟によるGemini取引所のインハウスステーブルコインです。
ニューヨーク州規制当局より認可を受けています。トークンを裏付けるドルは、米国の銀行で保管されるだけでなく、連邦預金保険公社（FDIC）からの適格資格を持っているとのこと。また、独立した公認会計士事務所により毎月の報告書を公表しているようです。

GUSDの実装

GUSDはOpenZeppelinなど外部のライブラリに依存せず、すべて独自に実装されています。USDC, PAXと同様にコントラクトをアップグレードする機構を入れていますが、他とは違って独自のプロキシを実装しています。
ちなみにUSDC(CENTRE)は7月に、PAXは8月に独自プロキシからzOSに差し替えているのがGitのコミットログ（USDC, PAX）からわかります。GUSDは2018年6月にはコントラクトの監査まで終わっていたようですので、変更の余地はなかったのでしょう。

GUSDの実装に戻ります。

プロキシ－インプリーストアの三層コントラクト構造で、トークンのコントラクトアドレスになるプロキシとステートを保持するストアを維持してインプリのみをバージョンアップさせる（差し替える）ことができるようにしています。これはZ.com Cloud ブロックチェーンの CNS と近い手法です。

出典：The Gemini Dollar: A Regulated Stable Value Coin

また、制限されたコントラクトの関数（特定のリスクの高いアクション）を実行するためにオフライン署名を得るカストディアンという仕組みを入れています。

出典：The Gemini Dollar: A Regulated Stable Value Coin

簡単に言うと、カストディアンコントラクトに登録されている2人以上のアカウントのオフライン署名（コールドストレージにあるオフラインのキーセットによる署名）によってのみリスクの高いアクションを実行することができるというものです。いわゆるマルチシグ機構です。また、アクションを実行できるようになるまでの時間がタイムロックとしてカストディアンごとに設定されています。

リスクの高いアクションは即時に実行されず、リクエストを投げ、承認を得てはじめて実行されるようになっています。リクエストのステートチャートは下記のようになっています。

GUSDにおけるリスクの高い（リクエストを必要とする）アクションは下記のものがあります。

  • インプリを変更する
  • カストディアンを変更する
  • トークンを発行する（GUSDではMintではなくPrintと表現している）
  • トークン供給量上限を引き上げる

これらはリクエストを投げる関数（requestXXX）とコールバック関数（confirmXXX）がセットで実装されています。
ただし、トークン発行についてはPrintLimiterコントラクトのPrint権限保有者（limitedPrinter）にて即時に実行できるようになっています（ホワイトペーパーでオンラインキーの承認と言われるもの）。カストディアンの承認を得る実装（リクエスト＆コールバック）はあるものの、実際にはカストディアンのアドレスにPrintLimiterコントラクトが割り当てられていて、オフライン承認は不要になっていました。

出典：The Gemini Dollar: A Regulated Stable Value Coin

全体を図にまとめるとこんな感じです。

参考までに、各カストディアンに実際に設定されているタイムロックは次の通りです。
[table id=5 /]タイムロックの補足

  • デフォルトタイムロック
    • カストディアンのPrimary権限保有者がアンロックする場合のタイムロック
  • 拡張タイムロック
    • Primary以外（1ETH保有者）がアンロックする場合のタイムロック

その他、特徴的な実装としては下記のものがあります。

  • 一括送金（batchTransfer）
    • 複数の送金先アドレス、送金額を一括で処理する実装
  • 複数アカウントからの残高移行（sweep）
    • 複数アカウントの残高を指定の1アカウントに一括移行する実装

batchTransferというとBeautyChainの事件を思い出しますが、さすがに同じ脆弱性はありませんでした。ただしGUSDは一切SafeMathを使っておらず加減算の演算子をそのまま使っています。本当に大丈夫なのだろうかという気はしますが、コントラクトは外部監査を受けているということなので大丈夫なのでしょう。

GUSDの権限モデル

GUSDトークンの権限には以下のものがあります。

  • custodian
    • primary
      • カストディアンの主要な権限保有者
      • コールバック関数のリクエストをアンロックできる
      • primaryがアンロックしたリクエストのタイムロックを拡張タイムロックに変更できる
    • signer
      • リクエストのオフライン承認者
      • タイムロック時間経過したアンロックリクエストのコールバック関数を実行できる
        ※custodianインスタンスごとの権限は上表を参照
  • sweeper
    • 指定アカウントの残高を移行することができる
  • limitedPrinter
    • トークンを発行することができる

GUSDのソースコード

  • ソースコードレポジトリ（GitHub）
    https://github.com/gemini/dollar
    執筆時のコミットバージョン：2049880c0eff5222ee426cf759ed4972a5f7095c

まとめ

それぞれの実装を比較表にまとめました。
[table id=6 /]
USDC(CENTRE), PAXは権限設定に若干の違いはあるもののかなり似通っていて、一般的なERC20トークンにブラックリスト機能を付けた程度の非常にシンプルな実装でした。開発途中でプロキシをzOSに切り替えるなど、極力標準的なものを利用してリスクを回避するスタンスのように思えます。2018年10月に正式リリースされたOpenZeppelin v2.0.0におけるERC20の実装もシンプルで分かりやすいものに整理されましたね。
一方、GUSDは重要なアクションにタイムロックやオフラインマルチシグ承認機構をいれており、厳格な運用を前提としていることがわかりました。
どのように実装すべきかは何を重視するかで様々かとは思いますが、比較的シンプルな実装が目立ったのはちょっと意外でした。

また、ホワイトペーパー、ソース公開、コントラクト監査は大きな資産を扱うコントラクトには必須ですね。
事例としてとても参考になりました。

それでは、また。

次世代システム研究室では、アプリケーション開発や設計を行うリードエンジニアを募集しています。アプリケーション開発者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。

  • Twitter
  • Facebook
  • はてなブックマークに追加

グループ研究開発本部の最新情報をTwitterで配信中です。ぜひフォローください。

 
  • AI研究開発室
  • 大阪研究開発グループ

関連記事