Aragon OS
AragonOSについて
AragonOSはDAOが使うブロックチェーン上のOSを目指している。オープンソースのスマートコントラクトライブラリーである。Dappsを制御するためのカーネルであると定義される。 Once you understand the robustness of the architecture and the Access Control List that powers aragonOS, your vision for smart contract development will change radically.
aragonOS-based apps follow the UNIX philosophy to do one simple thing exceedingly well. They expose permissions for other apps to consume their functionality and build upon them.
-Aragon
lucaban.icon < AragonOS曰く、「アーキテクチャー」と「アクセスコントロールリスト」を理解できれば、スマートコントラクト開発においての考え方が根本的に変化すると、、、、本当に?(笑)と思ってDocumentationとコードを調べてみた。
単純なスマートコントラクトのライブラリーを超えて、UNIX哲学に則ったカーネルに近づいてきてると理解し、唖然した。 ブロックチェーンでは本来デプロイしたら二度と変えれないコントラクトが、普通のアプリみたいに更新できること。
ブロックチェーンにデプロイする時のガスコストが大きくなるため、コントラクトを分割する必要性があったりすることが、AragonOSのモジュラーの考え方ではそもそも問題ない。
それで簡単に紹介する:
AragonOSの特徴
アップグレーダビリティ
モジュラー
アップグレーダビリティ
AragonOSの「アップグレーダビリティ」という特徴は、スマートコントラクトを同じアドレスで保有しながら、そのコントラクトのfunctionを入れ替えたり更新できる。
これを現実するアプローチとして、2つのコントラクトを用意する
Base Contract : ビジネスロジック(functionなど)のみをこのコントラクトに書く。
Proxy : ビジネスロジックが書かれたコントラクトへのAddressのみを保存する。 decouple the instance of a smart contract with the location of its business logic.
Proxyにはビジネスロジックを含めず、base contractへのアドレスを更新できる。
code:Kernel.sol
function setApp(bytes32 _namespace, bytes32 _name, address _app)
モジュラー
UNIX哲学は「各プログラムが小さく、一つのことをうまくやるように」というもの。AragonOSも同じように「モジュラー」を目指している。そのため、できるだけ、ビジネスロジックと認証ロジック(authentication)を切り離す必要がある。
decouple business logic from its authentication logic.
AragonOSはそれを下記の「Forwarder」と「ACL」で現実化している。 Forwarderについて
Forwarderコントラクトは、条件に従ってfunction callを別のコントラクトへパスできる。function callをForwarderコントラクトを通すことで様々な条件確認や認識ロジックを別のレイヤーで定義することが可能。
例えば、様々なfunction callを実行しても、全てが一つの「投票コントラクト」を通る。
投票が成功したら、そのfunction callが別のコントラクトで実行される。
実行したいfunction callをforwardingコントラクトにて格納し、後で別のコントラクトに送信して実行できるよう、Aragonは「EVMScript」独自のスクリプト形式を設計。
Access Control List (ACL)の仕組み
ACLは、スマートコントラクトを実行する際の権限を一覧で保存・管理するための機能である。
ACLの機能のおかげで、独自のAragonアプリにてアドレスの「役割」に基づいたmodifierをfunctionに付けることができる。このmodifierはAragonOSのACLを確認し、アドレスの権限を確認する。役割の作成や、役割にアドレスの追加/削除はAragonOSにて簡単にできる。
code:FundManager.sol
// 例えば FundManager というAragonOSを取り組むAppがある。
contract FundManager is AragonApp {
// 最初に「役割」を定義する。
bytes32 constant public FUND_MANAGER = keccak256("FUND_MANAGER");
// そのあと役割をmodifierとして使用できる。
function makePayment(uint _amount, address _address)
auth(FUND_MANAGER) public
{
// ...
}
}
上記のコードはACLの使い方の例。カスタムな役割に基づいた認証ロジックを簡単に設定できる。AragonOSのACLのコントラクトにて、役割の作成や特定したアドレスに役割を与えるロジックが下記ACL.solにて確認できる。
AragonOSを取り入れるDAO
AragonOSを取り入れるDAOは2つの種類のスマートコントラクトから作られる。
Kernel
DAOのコア。各DAO一つのKernelコントラクトをデプロイする。
DAOのKernelがAragonOSの一部をinheritする。
DAOのコアビジネスロジックのbase contractのmapping
DAOが使うその他のアプリのbase contractアドレスのmapping
DAOが使う認証ロジックのmapping
Apps
DAOが使う様々なアプリは全てKernelのを通して、モジュラーとアップグレード可能になっている。
AragonOSのコントラクトのコミュニケーションの例
https://gyazo.com/0a21b4b3b1b6b244925b8b5f9de9dca5
AragonOS documentationからのイメージ図
流れ
1. Aragon Tech Lead(左)がAragon DAO Vault contract(真ん中)に対して、「transfer」をしたい
2. Aragon DAO Vault contractがACL(右上)に確認をし、Aragon Tech Leadのアドレスは許可がないと判断
3. Aragon Tech LeadがACLに「transfer」をする時の正しいパスを確認
Voting contract(下)を経由する必要性がある
Votinc contractがForwardingコントラクトである
4. Aragon Tech Leadが「transfer」のfunction callをEVMScriptでラップし、Voting contractへ出す
5. 投票が成功し、Vote contractがAragon DAO Vault contractに対して「transfer」をする
6. Aragon DAO Vault contractがACLに確認をし、Voting contractのアドレスは許可があると判断
7. Aragon DAO Vault contractの「transfer」が実行される
参考