Libraに関する技術的観点で知っておくべきポイント。データ構造・コンセンサスアルゴリズム・パーミションレス化など

目次

  • 前提
  • アカウントベースのブロックチェーン
  • トランザクションの実行モデル
  • データ構造
  • コンセンサスアルゴリズム・LibraBFT
  • ネットワークパフォーマンスとバリデータセット
  • 総論

前提

本レポートではLibraのブロックチェーンの技術仕様について概観します。
Libraの基礎的要素やLibra Coinのおおよその仕組みについては下記で網羅しました。
*レポート:Facebookがイニシアチブを取る独自通貨およびブロックチェーンであるLibraの基本的要件の概観
https://hashhub-research.com/articles/2019-06-27-libra-overview
本レポートでは当該ブロックチェーンのデータ構造やコンセンサスアルゴリズムについて、テクニカルホワイトペーパー( https://developers.libra.org/docs/the-libra-blockchain-paper )を参照してカバーします。

アカウントベースのブロックチェーン

Libraはアカウントベースのデータモデルを採用しています。
Bitcoinなどに代表されるUTXO(Unspent Transaction Output)モデルは、アセットの移転情報をブロックチェーンに書き込みます。これは新しく生成したアドレスにコインを受けとるなどの工夫をすれば、最低限のプライバシーが担保できるというメリットがある一方で、複雑なスマートコントラクトの実行が困難であるというデメリットもあるデータモデルです。
一方、アカウントベースのブロックチェーンと言われるものは、その時点での状態(State)を毎ブロック更新をしていくよりデータベースに近い性質を持ちます。アカウントベースは、EthereumやEOSに代表されるモデルで、Libraもこれを採用します。
Libraはスマートコントラクトも実行出来るブロックチェーンを施行することから、アカウントベースを採用することは筋が通っています。

トランザクションの実行モデル

LibraのブロックチェーンのStateを変更する唯一の方法がトランザクションを実行することです。つまりEthereumなどと同様です。このトランザクションはLibraのブロックチェーンが保持するMove virtual machineが実行します。
トランザクションの実行には手数料としてLibra Coinが必要になります。DDoS攻撃を防ぐためですが、ここで疑問になる点は、Libra Coinをリセーラーから購入する場合、KYCが必要になるだろうということで、Libra Blockchainでのアプリケーション開発には多くの場合、KYCが必要になる可能性があります。Move virtual machineのスタックベースのバイトコードは、他の高級言語よりも命令形式が少なく、コードの脆弱性が発見しやすくなるとされています。
このバーチャルマシンを実行するための言語であるMoveは、Rustに近い形式の言語で実装されています。FacebookはJavaScriptライブラリであるReactなどの開発コミュニティを主導してきた経験もあり、同じような立場でMoveの開発環境を整備するだろうと思われます。

データ構造

Ethereumなどのブロックチェーンと大きく異なる点として、Libraのブロックチェーンは、ブロックのデータ構造を保持していません。なので、技術的観点、データ構造的にはブロックチェーンではないと言えます。Libraのブロックチェーンのデータ構造はマークルツリーからマークルツリーにStsteを更新し続るものです。
各バリデータノードが同じ最新のデータを保持します。タイムスタンプ付きの新しいstateを常に記録しておくだけで、古いデータ構造のブロックチェーンは残していません。
Libra自身はブロックチェーンと自称しているものの、より本質的には分散型データベースであり、ブロックチェーンという呼称はマーケティングの観点で未だ使用していると考えることが正しいでしょう。筆者としては、EOSなども今の形式で4年5年運用していたらフルノード残すことが困難になるであろうことから、実利的であるという印象を持っています。
常に最新のSateは誰が更新をしたか確認できるタイムスタンプが残されることもあり、各ノードからAPIを発行さえすれば、サードパーティーも含む複数のブロックエクスプローラーが立ち上がるはずで、ノード自体にはこれまでの情報が残されていなくても良いのかもしれません。

コンセンサスアルゴリズム・LibraBFT

Libraでは、PBFTに改良を加えたLibraBFTを用いており、ナカモトコンセンサスではなくクラシカルコンセンサスを原型にしています。Hotstuff consensus protocolから着想を得て、PBFTを改良しています。
コンセンサスのプロセスは以下の通りです。
  1. ラウンドは単一の指名されたリーダーとのコミュニケーション段階であり、リーダーの提案は暗号化ハッシュを使用してチェーンにまとめられます。
  2. ラウンドの間に、リーダーが持っている最新のStateを拡張するブロックを提案します。
  3. 提案が有効かつ悪意がない場合は、各ノードがそれに署名し、投票をリーダーに送り返します。
  4. リーダーが3f + 1 の十分な投票を受け取った後、リーダーは投票を同じチェーンを再度拡張する定足数証明書(QC)に集約します。
  5. QCはすべてのノードにブロードキャストされます。
  6. リーダーがQCの組み立てに失敗した場合、参加者はタイムアウトして次のラウンドを構成し直します。
  7. QCが滞りなく認められた場合、新規ブロックが生成され、参加ノードはStateを書き換えます。
  8. この時点で最新のStateがファイナリティを持つことになります。
ブロックを提案するリーダーノードは参加ノードからランダム性がある形で選出され、DDoS攻撃を防ぎます。このコンセンサスへの参加はパーミション型ですが、今後5年以内にパーミションレスへの移行を開始することが目指されています。しかし、その詳細は現段階で明らかではありません。

ネットワークパフォーマンスとバリデータセット

ローンチ時点で、Libraは1000トランザクション/秒、ブロックタイムは10秒が想定されています。
バリデータノードに求められる最低水準のスペックは以下の通りです。
*40 Mbps Internet connection
*1 commodity CPU
*16 TB SSD

総論

本レポートでは、Libraに関する技術的観点で知っておくべきポイントの整理を行いました。おおよそ基本的なポイントは纏められているはずです。基本的にブロックチェーンの形式としては、高速にトランザクションが実行できるパーミション型チェーンであり、EOSなどに近しいものです。そのため、それらのブロックチェーンとは競合する部分があると言えます。
今後テストネットの稼働やスマートコントラクトのデプロイ環境が出来ると明らかになることも多いはずであり、必要であれば、別途レポートを配信します。