パンダでもわかる miyabi（１）データの扱い方

2019年10月29日 15:53

　ブロックチェーンは難解だ。そう思われていると思う。そもそも何に使えばいいかよくわかんないし、その動作原理ともなると技術者に放り投げてしまいたくなる。

　それもそのはずだ。ブロックチェーンという言葉はビットコインから HyperLedger や miyabi などのプライベートチェーンまで、非常に幅広いものを指している。これはジェット機とモーターボートと車をすべて「内燃機関」でまとめているのと同じで、個々の動作原理はだいぶ違うのだ。

　というわけで、今回は miyabi の動作原理とデータの取り扱い方について紹介しよう。

ブロックチェーンは分散ステートマシン

　そもそもブロックチェーンとは分散ステートマシーンだ。ステートマシーンというのは「コマンド（トランザクション）」に応じて「状態」を変化させるもの、と定義できる。そしてそれが分散されているから分散ステートマシンというわけだ。
　状態を変えるためにはトランザクションを実行する必要があり、トランザクションなしに状態が勝手に変わったりしない。

　ステートマシンというものは驚くべき特性を持っている。
　「同じ初期状態から同じトランザクションを適用し続ければ最終状態も同じになる」
　あたりまえだろう、と思ったかもしれない。しかしこの特性は、分散環境で同期させる、特に同期しなければならない情報が巨大な場合、に最も優れた方法となるのである。ブロックチェーンの本気がここにある。
　なお「トランザクションの実行は決定論的でなければならない」ということは重要である。決定論的というのはランダム要素がなく何回やっても同じ結果をもたらす、ということだ。この制約なくしては結果が同じにならない。
　２つのルービックキューブを同じ手順で操作すれば、同じ絵柄になるということだ。

　ところで「状態」には２つある。
１、過去のトランザクション
２、現在の状態
　過去のトランザクションが「状態」というのはいささか奇妙な気もするだろうが、「過去にXというトランザクションが存在したらYをする」というようなこともできるので、これも状態と考える必要がある。
　別の例でいえば「同じトランザクションは2度実行できない」というのもある。こっちのほうがわかりやすいか。

　ビットコインの例を見てみよう。ビットコインでは明示的に２番目の意味の状態を扱わない。ビットコインのトランザクションはブロックにまとめられて、これが１番目の意味の状態を形成する。しかしアドレスごとの残高「状態」については明示的なデータ構造を持っていない。
　もちろん自分が所有するアドレスの残高は bitcoind によりトラッキングされているが、自分が所有してないアドレスについては、残高を表示させるコマンドをたたいてもエラーが表示されるだけだ。

　しかしながら chainFlyer という我々のサービスではあらゆるアドレスの残高を表示できるようにしている。実はこれは大変なことで、独自にインデックスを作成しすべてのアドレスの残高や履歴をトラッキングしているから可能なのである。

キャプチャ

　イーサリウムは２番目の意味の状態を明示的に扱った最初の仮想通貨である。イーサリウムではステートと呼ばれるデータ構造が明示的に定義され、トランザクションと同じように実体がある。そして miyabi もこのタイプだ。miyabi には明示的な現在の状態、つまりステートがある。

miyabi はテーブルという単位でデータを扱う

　miyabi では状態をテーブルという単位で扱う。テーブルは基本的には Key-Value である。だからどんなデータでもぶち込める。Key はユニークでなくてはならないので（だから Key だ）ハッシュ値などがよく使われる。
　Value のほうは本当に何でも入れられる。よく使われるのは JSON データでこれなら扱いに便利だ。何でも入れられるので画像データなども入れることができるが、ブロックチェーンでは各ノードがすべてのデータを持ち合う、ということを忘れてはいけない。画像データをそのまま保持するのはあまり得策ではないだろう。

　イーサリウムでも同じように Key-Value のデータを保持できるのだが、イーサリウムではデータは特定のスマートコントラクトに付属したローカルデータという扱いである。つまりそのデータの管理権利はオーナーであるところのスマートコントラクトに与えられ、それ以外の方法でアクセスすることはできない。

　しかし miyabi では違う。miyabi のテーブルは基本的に誰からでもアクセスすることができる。あとで説明するがもちろん適切なアクセスコントロールをすることも可能だ。miyabi ではテーブルはスマートコントラクトに従属するものではない。つまりスマートコントラクトから独立したテーブルを作成することができる。
　当たりまえのことをさも凄そうに・・・と思われたかもしれないが、RDBの世界から見れば当たり前かもしれない。しかしブロックチェーンとしてはなかなかに珍しいのだ。

　素のテーブルは Key-Value という単純なものであるが、miyabi ではそれに制約をつけることで様々な便利な機能を使うことができる。制約をつけるにはいくつかの方法があるのだが、まずは最も基本的なのは「テーブルの型」を使う方法だ。
　miyabi ではテーブルの作成時に型を指定する。多くの型があるが、最も重要な Permission Table と Asset Table を紹介しよう。

Permission Table

　Permission Table テーブルを使えばデータの挿入や更新といった行為に対し、テーブル全体や行単位で権限を制御することができる。アクセス権限のことを ACL と呼び ACL そのものを変更する権限も設定できる。またテーブルオーナーという特別な権限も設定可能だ。

　ここでちょっと立ち止まろう。権限？　ブロックチェーンにおいて権限とは何だろうか？　普通のデータベースにおいて権限とはアカウントに紐付けられた権限のことだろう。しかし miyabi にはアカウントという考え方はない。この点はイーサリウムや Hyper Ledger と大きく違う点だ。

　もったいぶってもしょうがないので答えを言おう。miyabi では権限は公開鍵と紐ついている。権限の設定先はアカウントではなく公開鍵なのだ。さてこれはどういうことか？

　miyabi は最初に書いたようにステートマシンだ。だからテーブル（状態）を更新するためにはトランザクションの実行が必要になる。つまりテーブルの更新には必ず起点となったトランザクションが存在する、それもただ一つだけ存在する。
　そしてトランザクションには署名がある。署名とは改ざんされないようにつけるだけではなく、権限の表明ととることもできるのだ。

　つまりこういうことだ。テーブルの更新時に ACL により更新に必要な権限（公開鍵）が決まる。そしてその起点となったトランザクションまでさかのぼり、署名を見る。必要とする公開鍵の署名があれば、晴れて更新は許可され、なければ却下される。テーブルの更新だけでなく挿入や ACL の変更など、すべての操作において同じプロセスが走る。

　これが、 miyabi における権限の働き方である。

　この仕組みスマートコントラクトの場合でも同様に適用される。スマートコントラクトを呼びだすトランザクションにも署名がある。そしてそのスマートコントラクトが最終的にテーブルを更新しようとするならば、それに応じた公開鍵の署名が（最初のスマコン呼び出しトランザクションに）必要となる。
　だからスマートコントラクトにどんな悪意があろうとも、どんなバグが潜んでいようとも、あなたが署名しない限り、あなたの資産が減らされることはない。契約書にサインしない限り悪徳商法にかかることはない、ということだ。

Asset Table

　さて、もう一つ重要なテーブル型を紹介しよう。それは Asset Table と呼ばれる。コインを表現するために特化したテーブルである。ブロックチェーンにおいて相性のいいアプリケーションの一つがコインを扱うアプリケーションである。miyabi ではこの頻発するユースケースのために Asset Table が用意されている。

　Asset Table も Key-Value であることには変わりがない。ただし Key には公開鍵（通常アドレスと呼ばれる）が入り、Value には数値が入る。そしてAsset Table を使うだけでいとも簡単にイーサリウムにおける ETH やビットコインにおける BTC と同じような安全な組み込みのコイン型が使える。

　具体的には以下のような制約がかけらている

１、Value の数値はマイナスにならない
２、数値を移動することができるが、移動の前後で収支を合わせなくてはならない
３、数値を移動するときに、減る側のアドレス（公開鍵）に対応した署名が必要である

　ただこの制約のままだと最初のコインを生成（マイニング）することができない。そこでマイニングのルールが存在する。

４、特殊なアドレスのみマイナスが許される（Voidと呼ばれる）。このアドレスをマイナスにし、任意のアドレスに送金することでマイニングと同等の行為を行う

　miyabi でコインを実装するのはは驚くほど簡単だ。Asset Table を作成する。以上。ほんとに何もいらない。Asset Table を作ってしまえばあとは ETH や BTC を扱っているかの如くコインを送金できる（マイニングが最初に必要なのは言うまでもないが・・・）。

　Asset Table の制約は作成時に外すこともできるのでアナーキーなコインを実装したくなったとしても大丈夫だ。マイナスの数値を許すようにすれば無限に借金ができるようなコインも作成できる。しかし逆にもっとカスタマイズしたコインが必要になったらどうすればいいのだろうか？

　これについても miyabi には道が用意されている。スマートコントラクトを使う方法だ。

　先に述べたようにテーブルのアクセス権限は制限することができる。先ほどは複雑になりすぎると思い省略したのだが、実はこの権限に設定できるのは公開鍵だけではない。実はスマートコントラクトの ID も指定できるのだ。

　通常 Asset Table はコインを移動させるために持ち主の署名が必要であるが、ACL にスマートコントラクト ID を指定した場合はそれに加えてそのスマートコントラクト経由でないとコインを動かせなくなる。

　だからスマートコントラクト内に Send メソッドを実装し、その中で独自の処理を行ってから実際にコインを移動させれば、カスタムコインを作成することが可能だ。このテクニックを使えば有効期限付きのコインだとか、KYC 済みのアカウントにしか送ることのできないコインだとかを簡単に実装できる。
　忘れてはならないが、その場合でもテーブルはあくまでも Asset Table である。だから Asset Table の制約はきっちり守られる。マイナスになったり収支が合わないようなコインの移動は失敗する。だから Dao のようにバグってコインが2倍になってしまうことは起きないのだ。
　ちょっと厨二っぽいが miyabi ではこのチェック機能のことを「理（ことわり）」と呼んでいる。ちなみにこの「制約されたデータ構造」という考え方は Libra でも採用されている、ちょっとうれしい。

miyabi がめざすもの

　ブロックチェーンは新種のデータベースであり、改ざん不能性や電子署名、ビザンチン障害耐性などを備えた「超信頼できる」データベースだ。

　データベースとしての側面を考えれば Oracle や SQL Server といった製品と同じように簡単にデータを扱えるべきだろう。その視点に基づき miyabi の権限システムは設計された。またテーブルはスマートコントラクトに従属するものではなく、独立したものとして設計された。

　ブロックチェーンは一度起きたことをなかったことにできないイミュータブルなデータベースでもある。バグがあったからと言って簡単にデータ修正を行うことは許されていない。だからデータレイヤには厳しい制約が必要なのだ。その観点から理（ことわり）やテーブルの型システムは設計された。

　だいぶ長くなったので今回はここまでにしよう。次はトランザクションについて説明しようと思う。