本記事では、Scalar社が開発している分散台帳ソフトウェアScalar DLTのアーキテクチャについて、Design Document等のWeb上の情報と開発者へのヒアリングを通じて調査し、オープンソースのブロックチェーン基盤Hyperledger Fabricとの比較の観点から考察したいと思います。間違っている点があるかもしれませんので、正確な情報が必要な場合は開発者やScalar社の方へお問い合せください。
Scalar DLTについて
Scalar DLTについて公式ページの記載を引用します。
Scalar DLTは、分散データベースソフトウェアであるScalar DBと分散型台帳ソフトウェアであるScalar DLから構成され、電子署名が付与されたスマートコントラクトを分散トランザクションの形式で実行し、その実行結果を複数の独立したコンポーネントで連鎖的に管理することにより、高い耐改ざん性を有しつつ、従来のブロックチェーンにでは実現が困難であった高いスケーラビリティ、強い一貫性、確定性を実現します。
Scalar DLTのSandboxの使い方やスマートコントラクトの書き方に関しては下記のように既に記事がありましたのでそちらを参照していただければと思います。
設計思想
Fabricが複数の企業の間で台帳を共有するコンソーシアム型の構成にフォーカスしているのに対して、Scalar DLTは基本的には1つ(または少数)の企業のノード群と、その監査ノード群という構成にフォーカスしているとのことです。そのため、後述するように、一見似ているようでアーキテクチャは根本的に異なるという印象を受けました。
アーキテクチャ概要
Scalar DLTは以下の3つの層に分かれています。
- Client SDK
- Ordering
- Ledger
最下層に位置するLedgerは、スマートコントラクトを実行し、台帳データを管理するコンポーネントです。内部のトランザクション処理には、オープンソースとして一般に利用可能になっているScalar DBを使用しています。複数のノードがLedgerクラスタを構成し、必要に応じてスケールさせることができます。また、Scalar DB上に複数のハッシュチェーン構造を構築しており、単一台帳だけでもある程度の改ざん検知性をもっているようです。
中間層に位置するOrderingは、スマートコントラクト(署名のついたビジネスロジック)の実行要求を複数の独立した各組織のLedgerクラスタが同じ順序で受領できるよう、決定的な順序で並べる役割を担っています。FabricにおけるOrdererと似ていますが、所謂ブロックチェーンではないので、Fabricのようにブロックの生成を行ったりすることはなく、あくまでも順序付けのみのようです。
最上位にClient SDKは、OrderingやLedgerとやりとりするインタフェースを備えたJavaのライブラリです。
各コンポーネントを図示してみました。
ポイントは、複数のLedger(クラスタ)が相互に独立していて、コミュニケーションをしていないというところであり、複数のLedgerの状態を比較することにより、改ざんを検知する仕組みです。また、各Ledgerがメインの処理クラスタとその他の監査ノード（クラスタ）というように役割が別れているところも特徴のようです。通常のノード構成は、メインのクラスタが3〜100以上で監査ノードのクラスタは1〜3台のようです。
改ざんに対する合意形成の考え方
Scalar DLTは、Decoupled Consensusという方式（特許出願中とのこと）を採用しています。コントラクトの実行フェーズと、改ざんの検証フェーズが分離されている(Decoupledである)という点が特徴だそうです。Hyperledger Fabricが、コントラクト(トランザクション)の仮実行とそのEndorsementにより、コミットの前に改ざんされていないことの合意（改ざん検知）を行うのに対し、Scalar DLTは、コミットの後に複数のLedgerの結果を比較することにより改ざん検知を行うということのようです。この点は、設計思想の違いに由来するアーキテクチャ上の大きな違いであると思います。Scalar DLTはこの方式により特徴の一つである性能スケーラビリティを実現しているようです。つまり、コミットの事後に改ざんを検証するということは、検証まではそれぞれのLedgerが独立してコントラクトの実行を行えるということです。例えば、コントラクト実行は、メインのLedgerクラスタのノード数を増やして高速に行い、改ざんの検証は、監査用の小規模なLedgerクラスタを含めた全Ledgerが、実行完了時点のデータを用いて行うといった運用が可能なようです。ただ、その分、Fabricのようにリアルタイムに改ざんの検知ができないところがデメリットになると思います。
一方、Fabricでは、クライアントがEndorsement Policyに基づいて各組織のPeerからEndorsementを集めなければならないため、性能をスケールさせるためには各組織内のPeer数を増やしていかなければなりません。Endorsement Policy次第ではありますが、全組織のEndorsementが必要ならば、全組織が一律にスケールしていかなければならないので、運用やコスト面で大変です。その反面、データに改ざんがあれば、それを次に処理する際に検知できるというブロックチェーンならではの即時の改ざん検知性を持っています。
Ordering
Scalar DLTのOrderingコンポーネントは、信頼性と性能の観点からKafkaを採用しており、クラッシュ故障耐性(CFT)を想定しています。ただ、Orderingコンポーネントは電子署名がついたコントラクトの実行リクエストの並び順の合意をとっているだけであり、実際にできる不正は要求をドロップさせることくらいのようで、それもクライアントで検知できるとのことです。
一方、Fabricでは、将来的にOrdererでビザンチン故障耐性(BFT)を有する合意形成アルゴリズムを導入しようとしています。その前段階としてv1.4.1でRaftをサポートしました。RaftもCFTではありますが、プラガブルだと謳っていた割にKafkaに密結合してしまっていたOrdererを、リアーキする狙いがあったようです1。また、Raftサポートにより、基本的にある組織が集中運用するしかなかったOrdererを、複数組織で非中央集権的にできるようになりました。
こうしたOrderingサービスを、ビザンチン故障を想定して非中央集権的に運用すべきかどうかは、どういう(ブロックチェーン)ネットワークを想定するかにもよりますし、議論の余地のあるところだと思います。ただ、個人的には、処理の並び順に関する合意は、まっとうな企業同士が運営するコンソーシアム型のネットワークであればCFTで十分で、改ざんや不正を監視、監査し検知できるのであればそれで良いように思います。
コントラクト実行処理
Scalar DLTでは、コントラクト実行(トランザクション)処理の高性能化のため、Partial-order-aware Executionという技術（こちらも特許出願中とのこと）を採用しているそうです。コントラクト間の依存関係を動的に検知して、並列実行をしているようです。
Fabricは、v1.0においてEndorsement-Ordering-Validationモデルを導入し、コントラクトの仮実行/シミュレーションを並列に行うことで高性能化を図っています。ただ、以前執筆した記事でも触れたように、Validationフェーズで直列になってしまい完全には並列実行ができていないため、結局そこがボトルネックになりうるという課題があります。