僕らのブロックチェーン開発のやり方

こんにちは！bitFlyer Blockchainで開発チームのマネージャーをしている越智です。

今日はブロックチェーン開発についてご紹介したいと思います。

メンバー構成

開発チームはブロックチェーン開発、モバイル開発、QAで構成されています。

国際色豊かなチームで、チーム内の公用語も英語・・・もといプログラミング言語です。伝えたい思いがあれば大丈夫、むしろ仕事をしながら英語も勉強できてお得というポジティブシンキングで日々業務にいそしんでいます。

開発体制

スクラムにのっとって開発しており、2週間のスプリントでイテレーションを回しています。スタンドアップミーティング、スプリントプランニング、スプリントレトロスペクティブ等のセレモニーをもれなく開催しています。

多くのエンジニアは10:00前後に出社し、10:30から15分程度のスタンドアップミーティングに参加します（現状はWork From Homeの影響でGoogle Hangoutsでミーティングしています）。昨日したこと、今日すること、問題点について簡潔にまとめて話すことで自分の脳内も整理され、一気に仕事モード！

新機能などについてはエンジニア全員で議論し、どのような方針にするかなどを決めています。ここでは遠慮はいりません。入りたてのエンジニアも積極的に意見を述べています。方針が決まれば、実装は100%担当エンジニアの裁量です。最高のコードを書いて、大量のレビューコメントを浴びて、リリースまで走り抜けます。

技術

miyabiは主にC#を使って開発しています。ただし、特に速度が求められる暗号モジュールなどはC/C++で記述されたネイティブコードを使用しています。結合テストにはPythonを利用しています。

C#に関しては常に最新を追い求め、今は.NET Core 3.1で開発を行っています。新しい言語機能等も積極的に取り入れて開発を効率化させています。.NET CoreなのでWindowsでもLinuxでも問題なく動作します。また、Dockerイメージもあるので簡単にデプロイできます。

miyabiを使ったブロックチェーンソリューション開発（miyabiをDBとして使用するWebサービス開発）も行っており、そこではASP.NET Core, Azure App Service, Azure SQL Databse等を利用しています。

ブロックチェーン開発？？

ところで、ブロックチェーン開発って何？という疑問がそろそろ頭をもたげてきた頃かと思います。

私たちが開発しているmiyabiはブロックチェーンそのものです。Ethereumのサイドチェーンでもなければスマートコントラクトでもありません。独自のBFT型コンセンサスアルゴリズム「BFK2」を実装したノードがコンセンサスをとる、100%ピュアなブロックチェーンです。

すなわち、弊社における「ブロックチェーン開発」とは「ブロックチェーンのすべてに携わる開発」という事になります。

ネットワークレイヤーを効率化したい？ストレージをチューンしたい？新しい言語をスマートコントラクト向けに開発したい？もっと早いブロックチェーンを作りたい？やりましょう、miyabi開発で！

ブロックチェーンを使ったシステム設計をしたい？スマートコントラクトを書きたい？そしてブロックチェーンで世界を簡単にしたい？できます、miyabiのアプリケーション開発で！

※写真は「ブロックチェーン」が2019年の小学館DIMEトレンド大賞 IT部門賞を受賞した際に展示した「miyabi」（モニター表示されているのがmiyabi）

開発秘話

ここではTokyo Otaku Modeさん、イードさんとの共同プロジェクト「Tokyo Honyaku Quest (実証実験)」でどのようにmiyabiを使った開発を行ったかについて簡単にご紹介いたします。(Tokyo Honyaku Quest についてはこちらの記事をご参照ください)

ブロックチェーンを使うとき、まず考えなけばならないのは「ブロックチェーンに入れてまで守りたいデータは何なのか」という事です。miyabiがいくら高性能とはいえ、単位バイト当たりの計算機コストはRDBに比較して高いです。そのため、データの取捨選択が重要になります。

Tokyo Honyaku Questでは以下のデータをブロックチェーンで管理することにしました。

1.  翻訳・校正文書のハッシュ値
2.  HON（報酬コイン）
3. 現在のステート

1. 2. は比較的わかりやすいと思います。1. はRDB側に保存されている翻訳・校正文書が改ざんされていないことを証明するため、2. は報酬があらかじめ約束されたとおりに配布されることを保証するためです。

それに対し、3. はビジネスロジックをブロックチェーンで管理することを目的としています。これにより、サーバー（Web、RDB等従来型のシステム）とブロックチェーンの位置付けが完全に入れ替わります。つまり、1.2.ではブロックチェーンはデータを保証するという意味でサーバーの補佐でしたが、3.により常にブロックチェーンがビジネスロジックの根幹を握るメインコンポーネントとなります。（もちろん、2. には配布ロジックが含まれるのでビジネスロジックはあるのですが3. のインパクトのほうが大です。）

保存するデータを決めたら、鍵管理方法を決めます。今回の実証実験ではユーザーの負担を減らす目的で秘密鍵の管理をサーバー側で行っています。つまり、運営がユーザーの代わりにトランザクションに署名しています。しかし、ブロックチェーンの世界では本来ユーザーが秘密鍵を管理すべきです。なぜなら、自分が行う行動に対して自分で署名をし、それがチェーンに刻まれるのがブロックチェーンの世界観だからです！そうする事で、たとえサービスの運営であってもユーザーの許可なしにデータを操作することができなくなります。そう、データはユーザーの手の中にあるのです。

さて、ここまでくればあと一歩。サーバー側の設計となります。Tokyo Honyaku Questではここの設計は私たちの管轄範囲外でしたので割愛させていただきます。

設計が終われば開発です。私たちのメインの開発案件はスマートコントラクトの実装でした。スマートコントラクト実装に当たりmiyabi側の拡張がいくつか必要になりました。例えば、スマートコントラクト内部で署名を検証する方法の追加、デバッグのためにログを出力するモジュールの追加（最新のmiyabiではデバッガをアタッチしてデバッグできます）等です。このような変更も、Merge Request 一本で即完了というスピード感で行えます。まさに自分たちでブロックチェーンを開発しているからこそできる芸当ですね！

まとめ

さて、いかがだったでしょうか？ブロックチェーン開発に興味お持ちいただけましたか？

「ああ、ブロックチェーン開発してぇ…」そう思った方はこちら↓

そうじゃない方はこちらでmiyabiを体験してみてください↓

miyabi プレイグラウンド申込