RICO version 0.9.1をリリース！
ダッチオークション機能を改善、ICOで調達した資金のコントラクトによる出金制限などを追加
この文章は、ICOフレームワーク RICO Framework の version 0.9.1 のリリースノートです。このバージョンはアルファ版です。ご利用に際して損失を被った場合でも、このバージョンでは一切保証されません。
新たな機能
- コントラクトによる資金分配機能の追加
- Raiden-NetworkのDutch Auction形式の価格決定アルゴリズムを追加
いくつかの修正
- external functionのバグfix
- AddMarketMakerの削除
- より安全なエスクロー設計に変更
- RICOのリファクタリングとLauncherの変更
RICOはここ２週間で大きく前進しました。コードテストを強化し、多くのシナリオテストを実施しています。予定では、あと２週間でコードの完全な監査を終え、実証実験を行う段階に移行できます。
1. コントラクトによる資金分配機能
RICOの以前のバージョンにおいて、寄贈されたすべてのETHは直接Gnosis-Multisig-Wallet（以下 、GMW)に転送されていました。この場合、多くの資金が一度にプロジェクトオーナーに渡ってしまうことになります。これでは大規模な資金を得たオーナーが開発モチベーションを維持できず、成果物を出すまでプロジェクトを継続できないといった問題を引き起こす可能性がありました。
この問題に対し、RICOの初期の構想ではMultisig Walletのみでもモチベーションを維持するガバナンス体制が構築可能ではないかと予測していました。しかしその後、
Tezosプロジェクトにおいて大規模な内紛が発生します。この状況を鑑み併せた結果、GMWの実装のみでは、プロジェクトオーナーの権限を縛りプロジェクトを維持することは難しいとの結論に至りました。（Breitman夫妻は、全資金を動かす権利はプロジェクトオーナー側にあると考えており、勝訴することができれば資金の分配を強制できる可能性が高いと目論んでいる可能性があります。）
そこで今回のアップデートでは、寄贈されたETHのうち、引き出し可能なETHのスケジュールを明確に定義することで、任意のタイムスケジュールで資金をRICO ContractからGMWに移動させる機能を追加しました。
これにより資金は一時的にContractにロックされた後、徐々にプロジェクトオーナー側に移って行くという動作が実現します。プロジェクトオーナーは仕組み上、一度に資金を移動させることができず、プロジェクトの成功に対して明確な意思を持つことを強制されることになるため、内紛リスクを抑え、プロジェクトオーナーのモチベーションを維持できるようになり、チームの生産性の向上に繋がる可能性もあります。
function AddWithdrawalRoundはコントラクトから資金を引き出す予約を行うためのメソッドです。コードは以下の通りです。
ここでcalcTotalWithdrawalWeiはTOB時の最大ETH量、またはProof of DonationのETH総量を最大値に設定できます。また、予約した引き出し命令を実行するメソッドがfunction execWithdrawalRoundです。コードは以下の通りです。
この機能はVersion 0.9.1 で実装されています。また、今まで別途定義していた function AddMarketMaker を統合することで、シンプルなロジックにリファクタリングされました。
加えて、マーケットメイカーへの分配についてはプロジェクトオーナーが実行するため、今まで通りマーケットメイカーはプロジェクトオーナーと適切なコミュニケーションを取る必要があります。
2. Raiden-Dutch Auction方式の価格決定アルゴリズムを変更
RICOフレームワークでは、Gnosis-ProjectのDutch Auction方式から、Raiden-NetworkのDutch Auction方式に変更する修正を実施しました。Raiden-NetworkのDutch Auction型のICOは現在進行中です。いまのところ、以下の理由からRaiden-NetworkのDutch AuctionではFOMOの問題をクリアしているように見えます。
Gnosis-ProjectのDutch Auctionは、価格決定が経過時間のみに偏っているのに対し、Raiden-Networkでは寄贈されたETHの総量に比例した決定方式を採っています。
また、Gnosisでは期限を定義してあったことに対し、Raidenでは期限の制約がなく、目標金額に到達するまで無期限です。長期的な価格決定を行えるRaidenの方が、よりプロジェクトの評価がしやすい（プレディクションマーケット作用が大きい）と判断しました。
Raiden方式の問題は、寄贈されたETHの量があまりに少ない場合、永遠にDucth Auctionが終了しないことです。この問題を解決するためには、価格減少関数を適切に設定すること、具体的にはStartPriceを適切に設定することが必要です。
また、function claimToken を追加しました。これにより、RICO Contract側からTokenを生成可能にし、Tokenを予約する機能を追加しています。
Dutch Auctionのコードはこちらから確認できます。
次回のアップデートに向けて
RICOフレームワークの次回のアップデートでは、より品質を向上させた状態に移行します。また、以下のような機能を実装予定です。
- 参加者のWhiteList追加機能
- ERC223 Token Standardの追加または置き換え
RICOの開発を進めていくにつれ、RICOは現状のSolidityアプリケーションの中でも大型のアプリケーションとなって行くことを懸念としてきました。
Etheruemのマシンスペックは、マイナーのコンセンサスでターゲットされるBlock Gas Limitによって指定されます。１ブロックあたりの処理能力（ブロックサイズ）はGasとBlock Gas Limitに依存します。
たとえば、Ethereumの大規模なテストネットワークの一つであるRopsten-Testnetでは、MetropolisハードフォークによってBlock Gas Limitを4,700,000 Gasとする仕様変更がありました。そのため、Ropsten-Testnetでテストする場合、Solidityで一度のTxで実行可能な処理は4,700,000 Gasを超えることはできません (GasLimitを超えたアプリケーションのfunctionは永遠に実行できません)。このような制限は、今後のHF時に脆弱性を産む可能性があります。今後、Ethereumのハードフォークに合わせた適切なアプリケーションの設計を心がけ、各機能をできるかぎり低コストで実行可能になるよう慎重に設計する必要があります。
— —
DRIは、RICOフレームワークを通して分散型技術を広く利用する社会の実現に向けて活動を進めてまいります。
RICOのリポジトリは以下からご覧ください。
