Hi-Con2018に参加&協賛してきました!【前編】

by 曽和 修平

先日、Hi-ConというEthereum開発者向けのカンファレンスが 慶應義塾大学日吉キャンパスにて行われました!

主催はHi-Ether(Ethereum 開発者向けコミュニティ)さんで、CyberAgent ブロックチェーンスタジオもシルバースポンサーとして協賛させて頂きました。

今回はそちらの参加レポートをお届けしたいと思います!

Hi-Con2018について

Hi-Con2018はHi-Etherコミュニティが主催する「日本初の大規模イーサリアム技術者会議」で、2018年11月10日に開催されました。

初回にして参加者は300人超え!日本でも熱量高いEthereumの技術者がたくさんいるんですね!

セッションも午後からは複数トラックで行われたりと、1回目のカンファレンスにしてかなりの盛り上がりを感じました。

また、カンファレンスの学生チケットの配布にuPortを使用(学生証明書を発行しuPortで管理)したり、パネルディスカッションで質問が採用された方にEtherを配布したりなど、Ethereum技術者向けカンファレンスということで Ethereum技術を活用した運営例が見られたのも面白い点でした。

(1) Mythril & Security development lifecycle (SDLC)

前編では午前中に開催された2セッションについて、簡単に振り返ってみたいと思います。
Hi-Con最初のセッションはConsenSys Diligenceのco-founderであるTom Lindemanさんによる「Mythril & Security development lifecycle」です。

Mythrilというスマートコントラクト のセキュリティツールプラットフォームを活用し、どのようにスマートコントラクト 開発のライフサイクルがまわっていくかについてのトークでした。

Mythrilは複数のコンポーネントを組み合わせた多層構造により成り立っています。
「Maru」と呼ばれるコードの静的解析を提供する部分、「Harvey」という動的解析を提供する部分、「Mythril++」というシンボリック実行を提供する部分の3つから成ります。
また、これら3つのコンポーネントとオーケストレーションを担い、より優れた結果を生成するためのコンポーネントを「Maestro」と呼ぶようです。

ConsenSysが提案しているSmart Contract Secure SDLC(Systems Development Life Cycle)の紹介です。

デザイン、シミュレート→開発→テスト→デプロイ→監査→監視→シグナルのサイクルで開発しようというお話でした。
スマートコントラクト開発においては、セキュリティに問題があると即賠償問題に発展するのでテスト、監査、監視がとても重要になってきます。
最後のシグナルですが、これはPanvalaを使用して監査の完了を証明し、そのことを周知するということのようです。(Panvalaマークを取得する)

Mythrilサービスの利用フローの紹介もありました。
サービスの利用には「MYTH」というトークンが必要で、これを保持していれば24時間利用可能になるようです。

最後に、ロードマップの紹介です。v1リリースが2019/3/1の予定になっています。

ConsenSys Diligenceではスマートコントラクトのセキュリティ担保に対して非常に力を入れていることが伝わってくる内容でした。今後も動向を追っていきたいと思います。

(2) Smart contract vulnerabilities & other auditing tools

2つ目のセッションはNRIのTeruhiro Tagomoriさんによるスマートコントラクトの脆弱性に関するトークでした。

簡単にまとめると、このような内容でした。

  • スマートコントラクト の脆弱性は「実装に起因するもの」と「ビジネスロジックに起因するもの」の二通り存在する
  • ビジネスロジックに起因する問題は、Mythirilなどのツールによって発見することはできない
  • Ethereum Smart Contract Security Best Practicesはスマートコントラクト 開発者は全て読んでおくべき
  • 専門家の監査を受けてリリースすることを強く推奨

また、Solidityは多重継承可能なことから特にZeppelinなどのライブラリに任せている部分は実装が追いにくくなります。
そこで、Teruhiro Tagomoriさんが作成した sca2t といった依存関係をビジュアライズするツールの紹介がありました。
これにより、関数のアクセス修飾子やonly owner modifierなどを確認し、ビジネスロジックの観点からこれで問題がないかなどが調査しやすくなります。

スマートコントラクト の公開には大きな責任を伴うことを改めて認識させられるトークでした。
例えOpenZeppelinなどのライブラリ自体の脆弱性であっても、最終的に責任を負わなければならないのは自分たちですので、慎重にレビューをし監査に出すことが大切ですね。

まとめ

午前中のセッションはどちらもセキュリティについての話で、スマートコントラクト においてこの点がいかに大切な要素であるかを再認識させられる内容でした。

参加人数もとても多く、来年以降も開催されると良いですね。その際は登壇者として参加できるよう、今後も頑張っていきたいです。

また、午後以降も(ランチ中も)たくさんの興味深いセッションが行われていました!
そちらは次回公開します!

中編はこちら

Contact

お問い合わせ

Contact