時間が早いものです。昨年は、一人で「イーサリアム・スマートコントラクト」 Advent Calendar 2017 を頑張りました。今年は EOS でした。
今回は1人じゃないですが、一応無事に最後まで出来て良かったです。
個人の意見になりますが、イーサリアムをやっている開発者の視点からEOS
を触って感じたことをまとめたいところです。
EOS が優れているところ
触ってみて、感じた良いところです。
- TPS がやはり速い
- 記録された最大値は、メインネットで 3,990、テストネットで 9,179 になっています
- ちょうど今週、BlockBase, Inc. さんがE-Channel - EOSのエアドロ質問箱 -サービスをリリースしました。触って見ればお分かりと思いますが、すべてのデータが
EOS
上に保持しているにも関わらず、普通のウェブサービスと変わらないレスポンスになっています
- エンドーユーザが無料でトランザクション発行できるので、やはり最初の利用ハードルが低くなる
- イーサリアムはトランザクション発行するために
GAS
が必要ですが、EOS
の場合エンドーユーザが無料でトランザクションを発行することができるので、トークンをもらったけど、友達に送金できない
というケースがなくなる
- イーサリアムはトランザクション発行するために
- RDB のテーブルと同じ感じで使えるマルチインデックステーブル仕組みが便利
- イーサリアムの場合、データベースの概念がなく、全部ステートデータとしてブロックチェーンに乗っているので、保存したいデータは、全部
mapping
や配列などのデータ型で保持する - 対して、
EOS
のマルチインデックステーブルは、普通の RDB テーブルと同じく、行と列があり、普通にfind
で検索できたりするので、理解しやすい
- イーサリアムの場合、データベースの概念がなく、全部ステートデータとしてブロックチェーンに乗っているので、保存したいデータは、全部
困ったこと
実際自分のサービスを作ろうとする時、困ったこと
- 日本語の開発資料が少ない
- 公式サイト http://eos.io はまだ英語だけ
- EOS ブロックチェーンのデータ構成などは書かれていない
- BP が各自の開発をやっていて、何をやっているのか、どれを見る必要があるのか、などは分からない
- たとえブロックエクスプローラだけでもいくつあるので、どれが一番信頼できるかは分かりません
- c++ はやはりハードルが高い
- 個人的にやはり慣れてない。。。
- CPU / NET / RAM リソースがややこしい
- 開発者に対して、どう確保するのか、利用制限に引っかかった時どう対応すべきか、いろいろ対応しないと行けない
- 特に CPU と NET は、自分ではなく、EOS 全体のリソース利用状況と関係しているので、予測が難しい
課題
ホワイトペーパーに書いているがまだ実装できてない箇所とか、実際問題が発生した箇所とか、まだ課題がいろいろあります。
セキュリティ周り
EOS はパフォーマンス重視するため、いろいろ工夫していますが、その中、いくつの対策がセキュリティ面で攻撃しやすい箇所があります。
-
ガバナンスについて、実際の遂行はブロックチェーンに乗っていない
- たとえブラックリスト機能がありますが、BP によって対応していなかったり、データ追加が遅かったりする
-
BP のブロック生成順番が固定になっていると、予測できるため、攻撃しやすい
- ブロック生成時間を 0.5 秒まで短縮するために、現状の BP 順番は固定になっています
- 前項のブラックリストと合わせて、1つ被害がありました
- ハッカーのアカウントがブラックリストに入っていましたが、ある BP の対応が遅かったので、その BP だけブラックリストに追加していない
- ハッカーがその事実を把握できた上で、BP の順番が固定になっているので、その BP ブロック生成している 6 秒の間、持っている残高を他のアカウントに送金できてしまいました
-
ステートデータがブロックチェーンに含まれていない
- イーサリアムはブロックチェーンデータにステートツリーも設けられていますが、EOS の場合、パフォーマンスのため、ステートがブロックチェーンデータに含まれていません
- そもそも理論上、異なるノードでブロックチェーンデータに従って実行した後のステートデータは、ソフトウェアのバグやネットワークの状況によって異なる可能性がなくはないです
- そして、先週まさにこの問題が悪用されてハッキング事件が起こってしまいました ⇒ EOS dapp ハッキング事件と解説
- なので、根本的な設計を変えるか、ノードの実装を修正するかになると思いますが、対策を取らないとちょっと危ない感じがあります
スケーラビリティ
- まずリソース周りは、トップレベルの DApp は既に CPU の制限に引っかかっているので、サイドチェーンや layer 2などを検討しているようです
- DApp がどんどん出ているので、この問題を解決しないと、単に
TPS が 4000 までできる
と言っても意味がありません
- DApp がどんどん出ているので、この問題を解決しないと、単に
- ホワイトペーパーには、百万程度の TPS と書かれていますが、2018 年 12 月現在、EOS まだシングルスレッドで稼働していて、マルチスレッドになっていません。
- リソースの課題が解決出来たら、次は恐らくこの課題になるでしょう
- イーサリアムのシャーディングが難航していて、サイドチェーンや layer 2などいろいろ検討しているようになっていますが、EOS の場合、結局マルチスレッドを実現できるかどうかを少し心配しているのは本音です
告知
困ったことで書いた通り、開発ドキュメントが英語しかなかったり、ブロックチェーンの構成がなかったり、DApp 開発する時結局どこを調査すればよいかは分からないので、苦労していました。
なので、基本のデータ構成から、DApp の開発まで、一連の流れができたら良いなと思い、電子書籍にまとめました。
EOS の基本知識から DApp 開発方法、更にパブリックチェーンへの接続方法まで解説しているので、この一冊で EOS の dapp を開発できるようになると思います。
興味がある方はどうぞ〜
ではでは、メリークリスマス〜