スマートコントラクトの更新可能性

AragonOSのUpgradabilityはもう少し

AragonOSの提供する更新可能性 (Upgradability)に興味を以ていろいろ調べていたのですが、スマートコントラクト自体の更新可能性については、あまりきめ細やかに管理していないようです。

AragonOSのドキュメント

AragonOSではアプリケーションコードのアドレスとパッケージの中身のバージョン管理しています。更新タイプは以下の3つがサポートされています。

  • Patch: フロントエンドの更新。ユーザーは意識しなくてよい
  • Minor: パッケージの中身が大きく変わり、ユーザーが通知される。スマートコントラクト自体に変更はない
  • Major: スマートコントラクトも含む、パッケージの更新

スマートコントラクト自体の、更新可能性 (Upgradability)についてはあまりきめ細やかに考慮されていないようです。AragonOSの目的がDAO (Decentralized Autonomos Organization)にあるので、ENSやIPFSを用いて全てイーサリアムブロックチェーン上のDAOとしての機能を提供する、という意味ではいろいろな機能を提供してくれています。一方で、お金を扱い、脆弱性などが懸念されるスマートコントラクト自体にも、更新可能性を考慮する必要があると考えています。別途スマートコントラクトの更新可能性については、検討する必要がありそうです。

自分がやったこと

UdacityのプロジェクトではdAppのフロントエンドやOracleとインタフェースするFlightSuretyApp.solとブロックチェーン上のアカウントに紐付いた送金やM-of-Nコンセンサス、権限管理などを担うFlightSuretyData.solに機能を分離することで、変更の影響範囲を狭めるという狭い意味での更新可能性を実現しました。FlightSuretyDataのインスタンスはFlightSuretyAppのインスタンスの中で実体化され、呼び出しの際にはonlyOwner()などのmodifierにより、呼び出し元を制限しています。

OpenZeppelinのよく考えられた実装

真っ先にこっちを参照しろと言われそうですが、OpenZeppelinでスマートコントラクトの更新可能性について、パターンが提要されていました。
以下を参照しました

コントラクトのアドレスを保持するProxyコントラクトを仲介者として、実際の機能提供するコントラクト(上記の参照YouTubeの中では"Logic Contract"と言っています)を間接的に呼び出す。ただ、これは値を返すところまでProxyが面倒を見るので、機能提供するコントラクトの機能べったりなProxyコントラクトを提供することになります。更新可能性を求める場合には、更新可能な部分と、更新が難しい部分との独立性を保ちたいのが普通だと考えられますが、このパターンだと独立性が低いと言えます。この点は、Inherited Storageというパターンでも同様です。Eternal Storageというパターンでは、状態を管理するスマートコントラクトを前提として、機能提供するコントラクトを書かねばなりません。

上記の検討を経て、Unstructured Storageというパターンが提示されています。スマートコントラクトの関係は上述のYouTubeの8:19あたりにあります。

実装例については、OpenZeppelin LabのGitHubで提供されています。ただ、ここは更新可能性のコア機能というか、ヘルパー機能の提供なので、実装例を試してみないといけません。

コメント

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