Dapps 開発者がマネタイズするためのブロック生成報酬とは
Problem
Ethereum の誕生以後、Decentralized Applications(DApps) は世界に革新的なアプリケーションのあり方を示しました。DApps により今まで信頼出来る大三機関が信用を担保していたシステムをスマートコントラクトを用いることで Trustless に置き換えることができるようになりました。
しかしながら、Dapps 開発者のマネタイズ方法は ICO による資金調達がメインでした。 そして、ICO が法的に行いづらい中では結局トランザクション手数料を取るしかなかったのが現状だと思います。
このように Dapps 開発のマネタイズ方法は非常に難しいため、世に所望されるアプリケーションも開発者がマネタイズが出来ないため運用されづらい現状にあります。そこで、私達はブロックチェーン上のアプリケーション開発者に対する報酬設計を考えました。
Idea
ブロック生成報酬の 50% をその Chain の価値を向上させたアプリケーション製作者に当てます。残りの報酬はブロック生成者に与えます。従来のブロックチェーンではブロックの生成報酬を手に入れることができるのはブロックの生成者（いわゆるマイナー）だけでした。このアイディアはブロック生成報酬のルールを書き換えることでそのチェーンの貢献者に対して報酬を支払おうという仕組みです。具体的には Application の Operator に対して Application の Nominator が Stake した量に応じて下図のように報酬の配分が決定します。ここで Application の Operator を App Operator と呼ぶことにします。これは Application の開発者・管理者・開発団体などと等価であると考えてください。また、Application の Nominator を App Nominator と呼ぶことにします。
次の変数を定義します。
● BlockReward : ブロック生成報酬
● n : App Operator の数
● m_i : i 番目の App Operator に対する App Nominator の数
● AppNominator_{i,j} : i 番目の App Operator に対する j 番目の App Nominator
● stake_{i,j} : i 番目の App Operator に対する j 番目の App Nominator の Stake したトークンの量
この時、この Stake について AppNominator_{i,j} はブロック生成時に以下の報酬が得られます。ここで AppNominator_{i,j} = AppNominator_{k,l} (i≠k) があり得ることに注意してください。
次に Stake を受けた App Operator はブロック生成時に以下の報酬が得られます。
App Nominator は選んだ App Operator に関わらず Stake 量に比例した報酬を得ることができます。一方、App Operator は Stake された量に比例し、エコシステム内で Stake された総量に反比例した報酬を得ることができます。これにより、App Nominator は単純にトークンの価値を向上させると思われる Application に対して Stake するインセンティブが発生します。また、Operator は Stake を受けることで半永続的にチェーンのブロック生成報酬を受取ることができます。これはチェーン上のアプリケーション開発者のマネタイズが難しい問題に対する革新的な解決策となることを期待しています。
しかしながら、Operator はいくつかの不正ができます。App Operator が Plasma の文脈の Operator であることを仮定します。すると Plasma は Operator の不正を申告する機構が既に存在しています。Operator が不正を行った場合、この Plasma の Faild Proof を転用することで Operator に対するブロック生成報酬を Slash し、またその App Nominator の Stake しているトークンも一定量 Slash されます。つまり、App Nominator は Operator が不正をしたときに Stake したトークンを失うリスクを負います。さらに、大口の StakeHolder が自作自演で Operator を運営して Stake する可能性があります。このような極めて悪質なケースは Governance による判断で Stakeした全てのトークンが Slash されることになるでしょう。
このような Slash による罰則を加えると未熟な Operator に対して Stake するインセンティブが少なくなります。そのため多くのユーザーが既に安定して稼働しているアプリケーションに対して Stake することになるでしょう。そこで Operator のローンチ後、k(k≤3)ヶ月未満の Opeartor に対する Stake には別途でボーナス報酬を得る権利を加えます。これは l(≥12)ヶ月後以降に以下の権利をtヶ月間行使できます。ここで x^{old} は Stake した時点での x の状態を表す。
のブロック生成報酬を得ます。つまり、lヶ月後の App Operator が得ている報酬に比例した額の報酬を得る権利があります。この権利を行使された際は App Operator が貰える報酬はその分だけ減少します。故に App Operator は Nominate を受けることを拒絶する権利があります。k, l, t について App Operator が最初に指定することができます。
Operator Trading
Operator Trading はブロックチェーン上のアプリケーションのオペレータを売買する仕組みです。上記の仕組みにより、Operator は恒常的に利益を得ることができます。よりよく Operator の運営を行えるならばその Operator を別の相手に譲ることも一つの案でしょう。当然、Operator は常時売買されるわけではありません。Operator は自身に対してついた値に対して妥当だと思われる値をつけた相手に対してその権利を譲るでしょう。Operator の権利を譲り受けた対象は Operator としての報酬を受け取ることができます。この時、実際に運用を交替する必要はありません。しかし、Operator を売り渡した側は既にその Oeprator を誠実に運用するインセンティブを失うため必然的に譲渡先の新しい Operator の保有者が Operator の運用を行うことになるでしょう。
How to implement
この実装を行うにあたり Substrate や Proskenion などのコンセンサス・アルゴリズムや報酬設計を独自に定義できるブロックチェーンを用いる必要があるでしょう。
Question
以上の特殊な仕組みを導入することでブロックチェーン Application の開発者に報酬を与える仕組み作ることができると考えられます。
また以下の点を考察すべきでしょう。
- 悪質な Operator の自作自演を排除する Governance をどのように設計するか。
- ブロック生成報酬の配分は適当か。
- 一度に多くのユーザーに対して報酬を配分するとブロック生成時の計算コストが肥大化しないか。この問題は、報酬の取得権利を持っているユーザーがトランザクションを投げることをトリガーに報酬を取得する形式にすることで解決できるかもしれません。
- この報酬配分システムは応用して今まで適切に報酬を与えられていなかったものに報酬を与える仕組みを作ることは出来ないか。
最後に
弊社では Substrate を用いたブロックチェーン開発を一緒に行うエンジニアを募集しています！！また、弊社では Polkadot or Substrate にまつわる共同開発や研修等も行っています。興味ある方はぜひ私の Twitter DM や以下メールアドレスに連絡ください！
mail: info@stake.co.jp
