HomeGuidesAPI Reference

Orb DLT アーキテクチャ

Suggest Edits

Orb DLT は、Core と Apollo の 2 つの主要コンポーネントで構成されています。

321

Core

Core 層は、許可型の構成可能なエコノミーを実装するために使用できる耐改ざん機能付き台帳を提供します。これは、Coin、Account および Audit の 3 つの主要コンポーネントに分けられます。

612

Core アプリケーションは単一のバイナリとして提供されます。正しいパラメータで実行すると、3 つのコンポーネントのうちの 1 つが提供されます。

Coin

Coin は、構成可能なトランザクションイベントを実行し、tamper-evident な台帳へ書き込むための機能を提供します。このコンポーネントは、API、データおよびトランザクションエンジンの 3 つの主要なパッケージで構成されています。

321

API パッケージは、トランザクションの作成、tamper-evidence 検証情報の要求、アカウント残高の照会に必要な RESTful インターフェイスをクライアントに提供します。
データパッケージは、トランザクションの永続化と Orb DLT 台帳の作成に必要なデータ構造を提供します。
トランザクションエンジンは、トランザクション イベントを実行する目的で構築された専用のルールエンジンです。これは API パッケージから呼び出され、データパッケージを使用して、Apollo Transaction Manager により永続化されるレコードを準備します。

Account

Accountはアカウントとアカウントの階層を作成するための機能を提供します。このコンポーネントから作成された基本アカウントには特別な機能はありません。別の Core コンポーネントによって使用することができる ID を確立するために使用されます。このコンポーネントは、API とデータの 2 つの主要パッケージで構成されています。

321

API パッケージは、クライアントが他のコンポーネントで使用するアカウントを作成するための RESTful インターフェイスを提供します。
データパッケージは、Apollo Transaction Manager を使用してアカウントを作成するために必要なデータ構造を提供します。

Audit

Audit は tamper-evidence を提供するために coin によって実行されるトランザクションイベントの暗号化された証明を作成する機能を提供します。 これらの証明は、メインの台帳データから離れた個別のキースペースに永続化することができます。これにより、audit は分離された環境で実行するか、またはサードパーティのサービスプロバイダによって実行させることができます。audit 機能の使用は必須ではありませんが、使用することを強く推奨します。このコンポーネントは、API、データ、および暗号の 3つの主要パッケージで構成されています。

321

API パッケージは、クライアントが台帳エントリの tamper-evidence の証拠を作成するための RESTful インターフェイスを提供します。
データパッケージは、Apollo Transaction Manager を使用して証拠を永続化するために必要なデータ構造を提供します。
暗号パッケージは NaCl 互換のライブラリを使用して、台帳データの暗号テキストを生成します。セキュリティ上の懸念から、各証拠に対して 1 回のみ使用可能な鍵ペアが生成されます。新しい公開鍵は暗号文とともに格納されますが、秘密鍵は破棄されます。秘密鍵がなくてもクライアントは暗号文のペイロードを検証すること自体は十分可能です。Orb DLT が提供する tamper-evidence の詳細については、tamper-evidenceを参照してください。

Apollo

Apollo は、OLAP と OLTP の両方のユースケースに対応したストレージシステムに対する標準化されたプログラミングインターフェースを提供するミドルウェアコンポーネントです。Apollo は高可用性、線形なスケーラビリティ、柔軟なデータモデル、コンポーネント間の疎結合を考慮して設計されています。現在サポートされているのは Cassandra のみですが、コンポーネントはモジュール方式で構築されているため、他のデータベースおよびストレージエンジンを使用することが可能です。Apollo は、thrift、storage、および transaction の 3 つの主要コンポーネントで構成されています。

321

Thrift

Thrift パッケージは、他のコンポーネントと対話するために使用される自動生成された RPC 層です。Orb は現在サポート対象である Java と Go についてクライアントを提供してますが、他のプログラミング言語については、thrift コンパイラを使用して利用できるようになります。現在、Orb は v0.9.3 をサポートします。
##Storage
Storage は、キーベースのパーティショニングによってノードに分散された多次元マップです。これは、基礎となるストレージに対する簡単な CRUD インターフェイスを介して使用されます。現在 storage では、基礎となるストレージ実装には、既存のレコードがある場合のみ条件付きで更新するなどの条件付き更新機能があることを想定しています。

Data Model

マップの各レコードは次のように構成され、マップの各値は未解釈のバイト配列です。

(row-key, clustering-key, column-name) -> column-value

特性

  • レコードは row-key によってパーティショニングされます。
  • 同じ row-key を持つレコードは clustering-key によって整列されます(clustering-key 機能がストレージエンジンで実装されている場合)。
  • Google BigTable に似ていますが、より汎用的です。(Cassandra ほど汎用的ではありません)
    • clustering-key のタイムスタンプを使用して格納することで、データモデルは Google BigTable に似たものになります。
512

Transaction

Transaction は非集中型の分散トランザクションマネージャです。SI (Snapshot Isolation)、またはシリアライズ可能な方法で複数のトランザクションを実行します。transaction は現在、内部的に ECG (Enhanced Cherry Garcia) と呼ばれる独自のトランザクションマネージャをサポートしています。ECG は、「Scalable Distributed Transactions Across Heterogeneous Stores」[1] で説明するクライアント協調プロトコルを強化および修正し、分散型ストレージによるクライアント協調特性を利用して分散トランザクションを実行します。これにより、スケーラブルで高可用性のトランザクションだけでなく、複数の同等の機関によって所有されるシステムが実現します。
もともと ECG は SI (Snapshot Isolation) のみを保証していましたが、現在は、レコードの読み取り時に常にデータを書き込むことで、Serializable アイソレーションが保証されています。スナップショットアイソレーションをシリアライズ可能にするという理論的な背景については、「Making Snapshot Isolation Serializable [TODS'05]」[2] を参照してください。

参考文献
[1] https://ieeexplore.ieee.org/document/7113278/
[2] https://dl.acm.org/citation.cfm?id=1071615

Updated over 5 years ago