Solidityの複数コントラク ト連携を⾊々試してる話 blockchain.tokyo #7 LT 2018-04-10 ゆで卵 1

⾃⼰紹介 名前: ゆで卵 Twitter: @takayukib Github: yudetamago 所属: フリーランス • blockchain.tokyo #6 でもLTしてた⼈ • ブロックチェーン界隈に来たのはわりと最近(2ヶ⽉前ぐらい) • 業務でDapps作ってます 2

複数Contract連携の経緯 • 複数のトークンを扱うような処理が出てきたので必然 的に複数のContractになった • しかも、複数のContractでアトミックな処理が必要に なった • トークンのContract同⼠だけで頑張って解決しようと したら難しくなったので他のContractを導⼊して⾒通 しを良くしようとした • そもそもContractの役割ってロジックとストレージの 管理で2種類あるよね？ ←イマココ 3

• publicやexternalを付けた関数はどこからでも呼べてしまう • contractAの関数AとcontractBの関数Bを必ず同時に実⾏したい 場合は？ 4 複数Contract間のアトミックな処理 Contract A Contract B function A() public function B() public User Account User Account アトミックに 実⾏したい

アクセス制御の⽅法 • 呼び出し元(msg.sender)を制限するには、アドレスで判断する 5

例: Zeppelin-SolidityのOwnable • Ownableを継承してContractを作るとonlyOwnerという modifierが使えるようになる • onlyOwnerが付けられた関数はContractの作成者（デプロイし た⼈）しか呼べなくなる 6 https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/ownership/Ownable.sol

解決⽅法 7 Frontend Contract Backend Contract A Backend Contract B function A() public onlyAcceptable function B() public onlyAcceptable function useAB() Owner setAcceptable(Frontend.address) setAcceptable(Frontend.address) https://github.com/yudetamago/solidity-example/blob/master/contracts/AtomicProcess.sol

(1Dapps開発者から⾒た)Contractの役割 • ロジック • アプリケーションの要件に応じて作るところ • ストレージの管理 • (ERC20のような)トークンの実装が特化してい るところ •トークン以外の追加の情報の保存 8 これら2つの処理が混在しているので例えば…

例: 変数への代⼊とストレージ書き込み 9 オンメモリな変数への代⼊とストレージ書き込みがぱっと⾒では同じ

⽅針 • Contractではロジックとストレージへの書き込みが混 在している • ロジック⽤のContractとストレージ⽤のContractを分 けると⾒通しがよくなるのでは？ • すでに考えている⼈がいた • ref. https://medium.com/rocket-pool/upgradable- solidity-contract-design-54789205276d 10

利点/⽋点 • 利点: 柔軟性 • ロジック⽤のContractをいつでも変えられる（アップグレー ド可能） • ⽋点: gasコスト上昇 • Contractのサイズが⼤きくなるのでデプロイ時のgasが上が る • 外部Contract呼び出し(DELEGATECALL)のコストが⾼い 11

Contractを分けた時の図 12 Logic Contract Token A Token B Storage Contract

まとめ • Contractの数を少なくする(≒継承して作る)か多くする かはgasとの戦い • アクセス制御がアドレスベースでしか出来ないのは地 味につらい • (誰か良い⽅法知っていたら教えてください) 13 スライド中のコード: https://github.com/yudetamago/solidity-example