Smart Contract Design Pattern
はじめに
こんにちは！LayerXの山口(yamarkz)です。
8/30(木)にblockchain.tokyo #11 がGunosyオフィスで開催されました。
登壇する機会をいただき、「Smart Contract Design Pattern」というタイトルで話をさせていただきました。
今回はその登壇で話した内容を本ブログでも紹介します。
目次
- スライド
- GOAL
- デザインパターンとは？
- デザインパターンを学び、理解し、活用する意義
- デザインパターンの5つの分類
- デザインパターンの紹介
- デザインパターンの研究
- まとめ
- 参考資料
- 最後に
スライド
GOAL
デザインパターンとは？
まずはじめに「デザインパターン」とは何なのかという話をしました。
デザインパターンというキーワードを分解すると以下の様になります。
開発実装の設計型を”デザインパターン”と呼びます。
この言語定義だとまだ内容がふわっとしているので厳密に”デザインパターン”を定義します。
その場合、以下の様な定義となりました。
赤字でも記してある様に、
頻出する課題解決のベストプラクティス(最良の解決手段)がデザインパターン
である。
と定義しました。このあたりの定義の表現は様々ありますが、おおよそ考え方の方向性は一致しているのではないのかなと思います。
この「デザインパターン」の定義を踏まえて概念的な理解を深めて行きます。
私自身が考えるデザインパターンの概念を図式化すると上記の図の様になっています。
共通の課題に対して、解決実装がA / B / Cと存在している状況を想定します。
解決実装は解決アプローチが異なるものの、どれも共通の実装課題を解決できています。
この3つの具体的な解決アプローチが存在する状況から、各解決実装を分析し、最良の解決アプローチを抽出(見出)します。
これが上記図でのオレンジの五角形に向かっている矢印の部分です。
ここで定義した最良の解決アプローチとそれが解決する共通の実装課題を整理し、まとめたものを”デザインパターン”と呼んでいます。
デザインパターンを学び、理解し、活用する意義
なぜ、デザインパターンを学ぶのか…?
この辺りの話も人によって様々な理由が存在しますが、個人的に考えた結果、大きく3つの理由に帰着しました。
- 解決策の再利用
- 共通用語・共通認識の確立
- 設計・開発力の向上
それぞれの理由を解説していきます。
解決策の再利用
デザインパターンを学ぶ一番の理由は、”解決策の再利用”であると考えています。
デザインパターンは
頻出する課題解決のベストプラクティス(最良の解決手段)
であると先に定義しました。
ここに”頻出する課題解決”とある様に、デザインパターンはただのベストプラクティスではなく、先人達の経験と実績によって確立されたものがデザインパターンであるということです。
この経験と実績によって見出されたパターンに則って、頻出する課題を素早く解決することで、デザインパターンでは解決できない本質的な課題解決に集中することができます。
また、パターンに則ることで自身でバグを生み出しづらくなります。
この点は多額の資産を扱うことの多いスマートコントラクトにおいては非常に重要なメリットであるといえます。
共通用語・共通認識の確立
頻出課題とその解決策を言語化し、理解することによって開発者間でのコミュニケーションが円滑に進む様になります。その結果、設計と開発の議論が活発になり、開発速度の向上や課題解決に向けた密な議論を行える様になります。
コミュニケーションを取る人間が課題と解決策に対して共通言語と共通認識があることで端的な会話で解決策のおおよその方向性が決まります。
コントラクトの設計・開発力の向上
設計・開発力はデザインパターンを学ぶことで直接的に向上するものではなく、実際に活用する(解決策を再利用して課題解決位取り組む / 共通した用語と認識を持った上で課題解決のディスカッションを行い、最良の解決手段を模索する)ことで得られるものです。
設計・開発力が向上することで、遭遇する実装課題を抽象的(実装構造から最良の解決手段を見出す)に捉えられるようになり、結果的に課題分析 / 課題解決力が向上します。
整理すると
デザインパターンの5つの分類
デザインパターンの分類は調査すると紹介している文献がいくつか見つかりますが、精査すると5つに分けることができます。
Action and Control
コントラクトの処理操作の仕組みを提供するグループ
Authorization
コントラクトの関数呼び出しの認可制御を提供するグループ
Lifecycle
コントラクトの作成と破壊の制御を提供するグループ
Maintenance
コントラクトに変更可能性を提供するグループ
Security
コントラクトの関数実行の安全性を保証する機能を提供するグループ
カテゴリー分類とデザインパターン
Action and Control
- Pull Payment Pattern
- State Machine Pattern
- Commit and Reveal Pattern
- Oracle Pattern
Authorization
- Ownership Pattern
- Access Restriction Pattern
Lifecycle
- Mortal Pattern
- Automatic Deprecation Pattern
Maintenance
- Data Segregation Pattern
- Satellite Pattern
- Contract Register Pattern
- Content Relay Pattern
Security
- Checks Effects Interaction Pattern
- Emergency Stop Pattern
- Speed Bump Pattern
- Rate limit Pattern
- Balance Limit Pattern
現状でも17のパターンが存在します。(ここでは紹介しきれなかったパターンもあります)
- State Machine Pattern
- Commit and Reveal Pattern
- Satellite Pattern
デザインパターンの紹介
State Machine Pattern
Commit and Reveal Pattern
Satellite Pattern
デザインパターンの研究
デザインパターンの研究は2017年ごろから始まり、最近ではいくつか論文やブログポストなどが出始めています。この領域はまだまだ課題が多く、考え方やパターンは言語定義されてきているものの、原理原則などはまだ言語化されてきていません。(SOLID原則の様なもの)
この辺りの研究は大学の卒論, 修論などでやっても面白いと思うので学生のみなさんにはぜひチャレンジしてもらいたいです。
考え方については下記の記事が良いので気になる方は読んでみてください。
Smart contract開発者の考え方
- Safe is better than unsafe.
- Boringness is better than notoriousness.
- Constant is better than inconstant.
- Straightforward is better than intricate.
まとめ
参考資料
- Smart Contracts: Security Patterns in the Ethereum Ecosystem and Solidity
- Design Patterns for Smart Contracts in the Ethereum Ecosystem
- Identification of Programming Patterns in Solidity
- Solidty Smart Contracts Design Patterns
- Learning Solidity Part 2: Commit-Reveal Voting
- Proxy Libraries in Solidity
- yamarkz/solidity-design-patterns
最後に
blockchain.tokyo #11 で話した「Smart Contract Design Pattern」を紹介してきました。
スマートコントラクトは安全性が重要視されているものの、安全性の高い、高品質なコードを作り出すための手段の1つであるデザインパターンはあまり注目されていません。
今後スマートコントラクトが発展していくにつれて重要になってくる研究テーマではあるため、本記事で興味を持たれた方はぜひ研究調査をしてみてください。
宣伝
LayerXでは複雑で変化の激しいブロックチェーン技術の領域で一緒にチャレンジしてくれる方を募集しています。
我こそはという方は下記のリンクよりご応募お待ちしております。
