3つのステーブルコインから学ぶWeb3システム設計のコツ Part1 導入編
今回は全4部の連載記事となり、Turingumのリサーチャーが他のWeb3システムの設計を見る際にどんなことを読み取るのかということについて記載します。
主に見るのは「設計者がどんなことを想定していてこの仕組みを作ったのか？」と「実際の実務運用においてどうシステムを維持しているか？」の2つです。
この2つを知ることで、実際にWeb3システムをゼロから設計したり、運営の補助をしたり、あるいはすでに稼働しているプロジェクトをより強化するといったTuringumのコンサルティング能力向上に直結するからです。 この記事見てプロジェクト設計などに興味持ってくださった方々、お気軽にお問い合わせください。
記載した内容を列挙すると、下記の様になります。
設計者の意図
何が譲れなくて何が諦めたところ?
どうしてそっちの設計を選択した? (Pros/Cons)
どうやって儲けポイント作った?
どうしてそのパラメーターや追加機能を設置した?
どういう登場人物たちを想定していて、それに対してどう対処している?
実運用のカバーの仕方
今回の全4回の連載では、3つの仮想通貨担保型ステーブルコインの実例をもとに考えていこうかと思います。
第2回は旧MakerDAO / Sai、第3回は現MakerDAO / Dai、第4回はLiquityと考察まとめについて書いていきます。
更新については毎回Twitterにてお知らせしますのでフォロー&通知オンにしてお待ちいただければと思います！
チューリンガムTwitterアカウント
前提知識編
イーサリアム/Ethereum
仮想通貨の時価総額2位(2023/1/13時点)のブロックチェーンです。チューリング完全なスマートコントラクトが動かせるものとしては最大です。
ネイティブの仮想通貨はEther (ETH)です
スマートコントラクト
DBを変更する際のルールをあらかじめ定めておける仕組みです。
例えばトークン(ERC20など)というスマートコントラクトでは、「今の残高はAというアドレスが20、Bというアドレスが10である」「Aというアカウントが署名した取引情報では、Transferという関数 (プログラムの動作)を叩くことができます。そこでは送る数量と送付先を一緒に指定する」といったプログラムが稼働しています。
ブロックチェーンの取引の不可逆性を利用し、プログラムの実行した結果を書き換えたり、そもそも取引が無かったことにするなどができません。
DeFi
スマートコントラクトを利用した金融アプリケーションです。基本Trustが必要な部分もその権限もスマートコントラクトで最小化されるよう設計されているものを指します。
Stablecoin
とある資産(多くの場合米ドル)に対して、「あらゆる仕組みを利用して」同じように価格変動するよう設計されたトークンのことです。
例えばUSDCやUSDTは「このトークンをウチに持ってきたら同じ数量の米ドルを引き換えてあげるよ。」「逆にウチに米ドルを持ってきたら同じ数量のトークンを発行して渡すよ」といった方法でステーブルコインの米ドル同価値性を保証しています。いわゆる法定通貨担保型と呼ばれるようなものです。
そしてもしこのトークンの市場価値が1ドル以下になった場合、市場でそのトークンを買ってきて発行体に持っていけば、1ドル(実運用の場合手数料が発生しますが)から市場で取得した価格を引いた金額が儲かります。
逆にトークンの市場価値が1ドル以上になった場合、発行体に米ドルを持っていってトークンを発行してもらい、市場でトークンを売れば差額が儲かります。
担保ローン
何かを担保にお金を借りるものです。基本的に担保にする資産の評価額より低い金額を貸出します。
例えば、Max LTV(Loan to Value) が50%、清算ラインが80%だとします。1000万円の株があったら50%の500万円まで借りることができます。清算ラインは80%なので、株式の評価額が500*100/80=625万円になったら株が売却されます。
実例 : https://web.jsfnet.com/goods/exp/clw41310.html
仮想通貨が背景にあるステーブルコイン
先ほど述べたUSDC, USDTとは違い、いわゆる仮想通貨を担保に入れてステーブルコインと言われているものを生成するOver-CollateralizedなタイプのStablecoinです。
Luna/USTみたいなものは今回扱いません(というかあれをStablecoinというのは違いますし、なんならこの間崩壊しましたし…)
今回取り扱うものは、同じようなものを作ってる3つのシステム実装から考えていきます
Sai(Maker DAOの最初のバージョン)
Dai (今のMaker DAOのバージョン)
LUSD (ETHオンリー担保のステーブルコイン)
共通でやりたいこと
これは仮想通貨担保のステーブルコイン発行プロトコルの設計をする際に達成したい基本的な項目です。
仮想通貨 (多くの場合Ethereumの通貨であるEther) を特定のスマートコントラクトにロックしたら、その評価額をStablecoinの基準資産(今回の場合全てドル建て)で評価し、それより十分に低い (過剰担保の)量のトークン (Stablecoin)を鋳造する。
随時担保資産をドル建てで評価を行い、担保資産が規定の清算ラインに達した場合、担保を売却する(担保をシステムのStablecoinへと交換する。)
作成されたStablecoinはドルになるべく近い価格で推移してほしい (1トークンあたり10ドルとか0.1ドルとかになったら、”Stablecoin”とは??? ETHのボラティリティーより高いのでは!??となるので。)
どっかしらでお金儲けポイントを作成したい (無償労働はつらいので...)
共通で気をつけないといけないこと
これはプロトコル設計をする上で念頭におかなくてはならない基本的な項目です
人間は合理的な行動ができない。そういった行動をされてもシステムが壊れないようにしないといけない。
めんどくさくて清算される/損をするとわかっていても自分で返済をしない
そもそも、ある人にとっては合理的でもある人にとっては合理的じゃなかったりする
悪意ある攻撃に対しても耐性がないといけない
担保資産やステーブルコインの価格操縦、急な変動
開発者やコイン保有者に対する物理的な攻撃(5ドルレンチ攻撃)
(ガバナンスの仕組みがあるなら)それに対する嫌がらせ
オペレーションでカバーできる範囲とその労力の推定 (どんな人が関わるのか?の意識)
次回は、仮想通貨を担保に発行するステーブルコインの元祖である旧MakerDAO versionのSaiについて、設計や実運用、歴史を踏まえつつ解説していきます。
Part2はこちら：
Turingumではこうしたリサーチや、たくさんのWeb3プロダクト開発、運営に一貫して携わる中で得られた知見をたくさん貯めて顧客の方々に還元していくサイクルを回しています。是非お気軽に下のフォームからお問合せください！
この記事が気に入ったらサポートをしてみませんか？