Ethereum Smat Contract Best Practice #1

Junki Yuasa

Published in

Acompany

7 min readJul 1, 2019

はじめに

こんにちは. Acompanyの湯浅です. 今回からEthereum Smart Contract Best Practiceを日本語訳していきます. 今回は以下のページを訳します.

General Philosophy

 Ethereum and complex blockchain programs are new and highly experimental. Therefore, you should expect constant…

consensys.github.io

哲学

Ethereumと複雑なブロックチェーンのプログラムは新しく, かなり実験的です. したがって, 新しいバグやセキュリティリスクが発見され, 新しいベストプラクティスが開発されるにつれて, セキュリティの概観には絶え間ない変化が生じると予想されます. このドキュメントのセキュリティプラクティスに従うことは, スマートコントラクト開発者として行う必要のあるセキュリティワークの始まりにすぎません.

スマートコントラクトプログラミングには, 慣れ親しんだものとは異なるエンジニアリングのマインドが必要です. 失敗が起こりやすく, 変更は困難になる可能性があるため, Webまたはモバイル開発よりもハードウェアプログラミングまたは金融サービスプログラミングに似ています. したがって, 既知の脆弱性から防御するだけでは不十分です. 代わりに, 開発の新しい哲学を学ぶ必要があります.

失敗に備える

簡単でないコントラクトには誤りがあります. あなたのコードはバグや脆弱性に適切に対応できなければなりません.

・問題が発生したときにコントラクトを一時停止する（ ‘サーキットブレーカー’）
・リスクのある資産を管理する(レートの制限, 最大使用量)
・バグ修正と改善のための効果的なアップグレードの方法を持つ

慎重にロールアウトする

本番リリースの前にバグを見つけられるのがいいでしょう.

・コントラクトを徹底的にテストし, 新しい攻撃方法が見つかった時はテストを追加する
・α版テストネットリリースからバグ発見に対する報奨金を提供する
・段階的にロールアウトし, 各段階でのテストを増やす

コントラクトをシンプルにする

複雑さはエラーの可能性を高めます.

・コントラクトのロジックが単純であることを確認する
・コントラクトと機能を小さく保つためにコードをモジュール化する
・できる限り, すでに書かれたツールやコードを使用する(例えば, 自分で乱数ジェネレータを書かない)
・可能な限りパフォーマンスを明確にする
・必要な部分にのみにブロックチェーンを使用する

ブロックチェーンの性質に注意する

Ethereumプログラミングには注意すべき落とし穴がいくつかあります.

・悪意のあるコードを実行したり, 制御フローを変更したりする可能性がある外部のコントラクト呼び出しには細心の注意を払ってください.
・publicなfunctionは公開されており, 悪意を持って任意の順序で呼び出される可能性があることを理解してください. スマートコントラクトのprivateなデータは誰でも見ることができます.
・ガスコストとガスリミットを意識しましょう.
・ブロックチェーン上のタイムスタンプは不正確であることに注意してください. マイナーは数秒の範囲内でトランザクションの実行時間に影響を及ぼす可能性があります.
・乱数性はブロックチェーンでは自明ではなく, 乱数生成へのほとんどのアプローチは覆されることが起こり得ます。

基本的なトレードオフ

スマートコントラクトシステムの構造とセキュリティを評価するときに考慮する必要がある複数の基本的なトレードオフがあります.スマートコントラクトの開発にはこれらのトレードオフに対する適切なバランスをつかむことが重要です.

ソフトウェアエンジニアリングの観点から見た理想的なスマートコントラクトシステムはモジュール式で, コードは複製するのではなく再利用し, アップグレード可能なコンポーネントをサポートすることです. 安全な設計の観点から見た理想的なスマートコントラクトシステムは, 特により複雑なシステムの場合には, この考え方を共有するかもしれません.

ただし, セキュリティとソフトウェアエンジニアリングのベストプラクティスが一致しない例外があります. いずれの場合も, 適切なバランスは, 次のようなトレードオフに沿ってプロパティの最適な組み合わせを識別することによって得られます.

・堅牢さ vs アップグレード可能
・一枚岩式 vs モジュール式
・複製 vs 再利用

堅牢さ vs アップグレード可能
複数のリソースがKillable, UpgradeableまたはModifiableパターンなどの可鍛性の特性を強調している一方で, 可鍛性とセキュリティの間にはトレードオフがあります.

可鍛性のパターンは複雑さと攻撃される可能性を含む面を伴います. 例えば, トークンセールスコントラクトなどのように事前に時間が定められ, 限られた機能を提供するスマートコントラクトシステムの場合, 単純さは複雑さよりも効果的です.

一枚岩式 vs モジュール式
一枚岩な(全体が1つのモジュールでできている)自己完結型のコントラクトは, 全てのことを識別可能かつ読み取り可能に保ちます. 一枚岩であることを尊重して保持されているスマートコントラクトシステムはほとんどありませんが, 例えば, コードレビュー効率を最適化する場合などに望まれます.

他のトレードオフと同様に, セキュリティのベストプラクティスは短期間のコントラクトではソフトウェアエンジニアリングのベストプラクティスから離れ, より永続的なコントラクトの場合はソフトウェアエンジニアリングのベストプラクティスに向かう傾向があります.

複製 vs 再利用
ソフトウェアエンジニアリングの観点から見たスマートコントラクトシステムは, 最大限の再利用を望んでいます. Solidityでコントラクトコードを再利用する方法はたくさんあります. あなたが所有している, 以前にデプロイされたコントラクトを使用するのが一般的にコードの再利用を達成するための最も安全な方法です.

複製は、以前にデプロイした自らが所有するコントラクトが利用できない場合に頻繁に利用されます. OpenZeppelin Solidityのようなライブラリは, 安全なコードが重複することなく再利用できるようなパターンを提供しようとします. コントラクトのセキュリティ分析には, 対象となるスマートコントラクトシステムで危険にさらされている資金に見合った信頼水準をこれまでに確立していない再利用コードを含める必要があります.

まとめ

スマートコントラクトを作成する時に大切なのは以下です.

・出来るだけシンプルに
・テスト済みのコードを使用する
・必要に応じてテストを追加していく
・コントラクトのprivateなデータは誰でも見ることができる

今後も，Acompanyからブロックチェーンに関する記事を投稿していきますので，ぜひfollowしていただけると嬉しいです．