JP2022521915A - 分散型台帳技術（ｄｌｔ）を使用したリレーショナルデータの管理と編成 - Google Patents

分散型台帳技術（ｄｌｔ）を使用したリレーショナルデータの管理と編成 Download PDF

Info

Publication number
JP2022521915A
JP2022521915A JP2021549147A JP2021549147A JP2022521915A JP 2022521915 A JP2022521915 A JP 2022521915A JP 2021549147 A JP2021549147 A JP 2021549147A JP 2021549147 A JP2021549147 A JP 2021549147A JP 2022521915 A JP2022521915 A JP 2022521915A
Authority
JP
Japan
Prior art keywords
distributed ledger
database
sql
query
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2021549147A
Other languages
English (en)
Other versions
JP7500589B2 (ja
Inventor
スリバスタバ、ニーラジ
Original Assignee
ディーエルティー グローバル インク．
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ディーエルティー グローバル インク． filed Critical ディーエルティー グローバル インク．
Publication of JP2022521915A publication Critical patent/JP2022521915A/ja
Application granted granted Critical
Publication of JP7500589B2 publication Critical patent/JP7500589B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G06F16/1834—Distributed file systems implemented based on peer-to-peer networks, e.g. gnutella
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Computational Linguistics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

【要約】【解決手段】リレーショナルデータベースの原則に従って分散型台帳にデータを保存できるように、データの管理と編成を可能にするスマートコントラクトツールとオフチェーンツールの両方のセットについて説明する。相互分散型台帳プラットフォームの仕様と再利用可能なコアコンポーネントを組み合わせることで、分散型台帳プラットフォームに実装できるシステムが作成され、リレーショナル原則に準拠した分散型台帳との間のデータの保存と取得が可能になる。このシステムを実現すると、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）Ｆａｂｒｉｃにシステムチェーンコードを追加でき、ＪＳＯＮとして表されるスキーマとデータを使用できる。使用中、ユーザーは、コード、コンソール、またはすべての更新が分散型台帳トランザクションであるスマートコントラクトからデータを作成、更新、およびクエリを行うことができる。【選択図】 図１

Description

本出願は、リレーショナルデータベースの原則に従って、分散型台帳との間でデータを保存および取得できるようにするデータの管理と整理を対象とする。
最初のリレーショナルデータベースシステムは、１９６０年代後半のコンピューティングにおける主要な新しい開発に対応して開発された。システムがより大きく、より複雑になるにつれて、新しくまた更新されたプログラムが、古いプログラムによって作成されたデータを処理する必要があることが明らかになった。プログラムはデータをそれぞれ独自の方法で保存することが多いため、既存のシステムではこれが困難であった。リレーショナルモデルは、ストレージと検索の重要な側面を標準化し、それを採用した人々は、より安価なアップグレードやベンダー固定化の削減など、さまざまなメリットを享受した。
逆に、コンピューターベンダーによってプログラム固有のストレージアプローチに導かれた人々は、特にリレーショナルデータベース管理システム（ＲＤＢＭＳ）プラットフォームに移行するという大幅に遅れた意思決定が最終的になされたときに、より高いメンテナンスコストとより大きな労力に持ちこたえた。１９７０年代に、非リレーショナルのＨｏｎｅｙｗｅｌｌ ＦＡＣＴ言語を最終的に廃止するという、長年にわたるオーストラリア国防省のプロジェクトは、これらのコストの証である。
それ以来、コンピューティングの他の分野の進歩は、既存のリレーショナルデータベースツールに互換性がなくしたり、不便にしたりすることがある。同様に、オブジェクト指向プログラミングの台頭は、プログラマーがリレーショナルデータモデルを使用してデータを表現することを一時的に自然でなくした。オブジェクトにカプセル化されたデータは、ＲＤＢＭＳテーブルに分割することは困難であった。ただし、リレーショナル表現の利点は、十分に重要であったため、オブジェクトリレーショナルマッピング（ＯＲＭ）は、オブジェクト指向プログラミングが引き続き使用される場合には一般的なアプローチである。
一方、分散型台帳技術（ＤＬＴ）は、今世紀の情報技術革命に相当するものに火をつけ、可能にする可能性を秘めている。分散型台帳技術は、インターネットの最大かつ最も厄介な課題の1つである信頼の欠如に取り組み、解決している。分散型台帳技術は、初期のしかし強力な分散コンピューティングパラダイムであり、実用的な目的でデータを変更不可能にすることでインターネットに信頼をもたらす可能性がある、これまでで唯一のテクノロジーである。残念ながら、既存のＲＤＢＭＳプラットフォームとツールは、分散型台帳技術の制約と互換性がない。その結果、データがプログラムに密接にリンクされているプログラム/データの固定化は、１９６０年代のリレーショナルデータベース以前のプログラムよりも、分散型台帳のスマートコントラクトの方がさらに大きくなる。分散型台帳のデータが、開発者の特定の意図である場合にのみ、展開されたスマートコントラクトの詳細に固定されるシステムと方法が望まれる。
本明細書に記載のシステムおよび方法は、分散型台帳に保存する前にリレーショナルデータの管理と統合を可能にするスマートコントラクトツールとオフチェーンツールの両方のセットを提供し、前記分散型台帳の利点を損なうことなくリレーショナルデータベースに関する既存の開発者の知識を活用することを可能とすることによって、当技術分野の前記ニーズに対応するものである。サンプルの実施形態では、データは、リレーショナル原理に従って管理および統合され、選択された分散型台帳プラットフォームに格納され、開発者にすでに馴染みのある構造化照会言語（ＳＱＬ）などのプログラミング言語を使用してアクセスされる。その結果、分散型台帳に高度にセキュアで監査可能なリレーショナルデータベースが作成される。また、本明細書に記載のシステムおよび方法は、スマートコントラクトとともに使用することで、それらのスマートコントラクトのデータストレージの側面をより扱いやすくすることができる。
サンプルの実施形態では、相互分散型台帳プラットフォーム仕様と再利用可能なコアコンポーネントが一緒になって、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）などの一般的な分散型台帳技術プラットフォームに実装され、Ｎｏｄｅ．ｊｓ（登録商標）などの一般的なプログラミングプラットフォームからアクセスできるリレーショナルデータ管理および編成システムを作成する。前記リレーショナルデータ管理および編成システムにより、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）Ｆａｂｒｉｃで使用するシステムチェーンコードを追加し、ＪａｖａＳｃｒｉｐｔＯｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）として表されるスキーマとデータを使用できる。また、Ｆａｂｒｉｃのワールドステートデータベースは、データストレージに使用され、ＦａｂｒｉｃのＩＤプロバイダーは、たとえば、データベースの作成、データベースアクセスのユーザーの承認、テーブルの追加とスキーマの変更、データの書き込み、およびクエリのみを含む５つのレベルのデータアクセス制御に使用される。使用にあたって、前記ユーザーは、コード、コンソール、またはすべての更新が分散型台帳トランザクションであるスマートコントラクトからテーブルを作成、更新、およびクエリできる。
サンプルの実施形態では、システムおよび方法が、リレーショナルデータベース管理クエリを用いて前記分散型台帳のトランザクションデータを含む分散型台帳を実装する分散型台帳プラットフォームをクエリするために提供される。前記方法は、データベースを作成し、前記分散型台帳のデータベースに関する情報を記録し、受信したリレーショナルデータベース管理クエリを前記分散型台帳プラットフォームによって処理できるクエリ操作に変換することを含む。前記クエリ操作は、前記分散型台帳プラットフォームで実行され、クエリ結果が生成され、前記クエリ結果は、前記分散型台帳に含めるために前記分散型台帳のデータベースによって処理される形式で前記分散型台帳のデータベースに記録される。サンプルの実施形態では、前記リレーショナルデータベース管理クエリは、（１）ユーザインターフェースを介してユーザから構造化照会言語（ＳＱＬ）クエリを受信する、（２）アプリケーションプログラムインターフェイスを介してユーザーアプリケーションからＳＱＬクエリを受信する、 または（３）ＳＱＬクエリを実行するスマートコントラクトによって、生成される。
サンプルの実施形態では、リレーショナルデータ管理および編成システムは、ＳＱＬクエリを、データ操作言語（ＤＭＬ）書き込み操作、ＤＭＬ読み取り操作、またはデータ定義言語（ＤＤＬ）操作のいずれか１つであるＳＱＬ操作に解析するように適合されている。前記ＳＱＬ操作のＪａｖａＳｃｒｉｐｔＯｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）表現と、前記ＳＱＬ操作に含まれるすべてのリレーショナルデータは、前記分散型台帳プラットフォームによって処理するために作成される。
他のサンプルの実施形態では、前記ＳＱＬ操作の実行から生じるトランザクションが、プラットフォーム関連の範囲で分散型台帳への受け入れに向かって進行したかどうかは、例えば、対応するトランザクションのより明確なステータスをフェッチするためにＤＭＬ書き込み操作の最後にｏｐｅｒａｔｉｏｎ ｂｒｏａｄｃａｓｔ ｓｔａｔｕｓ（ＯＰＳＴＡＴ）命令を追加することによって判断する。前記分散型台帳プラットフォームで前記クエリ操作を実行することには、さらに、前記ＳＱＬクエリを呼び出すエンティティが前記要求されたＳＱＬ操作を実行する権限を持っていることを確認することを含めることができる。前記分散型台帳プラットフォームで前記クエリ操作を実行することには、前記クエリ操作とその結果のＪＳＯＮ表現として前記分散型台帳プラットフォームによって処理および保存できるクエリ操作を作成することを含めることができる。
前記ＳＱＬ操作がＳＱＬ ＤＭＬ書き込み操作である場合、前記方法には、前記ＳＱＬ ＤＭＬ書き込み操作を実行するために必要に応じて前記分散型台帳プラットフォームからデータを取得すること、前記取得したデータを含むＳＱＬ ＤＭＬ書き込み操作を実行する、前記クエリ結果にすべての新規または更新されたレコードのＪＳＯＮ表現を準備すること、および前記ＳＱＬ ＤＭＬ書き込み操作と更新されたレコードを、前記分散型台帳に含めるために前記分散型台帳プラットフォームによって処理されることができる前記形式で前記分散型台帳プラットフォームに収容すること含めることができる。前記方法はまた、前記分散型台帳への前記ＳＱＬ ＤＭＬ書き込み操作の受け入れについて前記分散型台帳を監視し、前記ＳＱＬ ＤＭＬ書き込み操作が成功したかどうかを前記ＳＱＬクエリを呼び出すエンティティに通知することを含めることができる。
一方、前記ＳＱＬ操作がＳＱＬ ＤＭＬ読み取り操作である場合、前記方法は、前記ＳＱＬ ＤＭＬ読み取り操作を実行するために必要に応じて前記分散型台帳プラットフォームからデータを取得すること、前記取得したデータを含む前記ＳＱＬ ＤＭＬ読み取り操作を実行すること、前記クエリ結果のＪＳＯＮ表現を準備すること、および前記クエリ結果の前記ＪＳＯＮ表現を前記分散型台帳に含めるために前記分散型台帳プラットフォームによって処理されることができる前記形式で前記分散型台帳プラットフォームに記録することを含めることができる。前記方法には、前記クエリ結果のＪＳＯＮ表現を前記ＳＱＬクエリを呼び出すエンティティに返すことも含めることができる。
サンプルの実施形態では、前記分散型台帳プラットフォームは、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）Ｆａｂｒｉｃプラットフォームである。このような実施形態では、前記データベースは、チャネルを作成し、前記データベースのコピーを維持するピアコンピュータと前記リレーショナルデータベースに関するメタデータを書き込む通常のトランザクションを定義する構成トランザクションを実行することにより、前記Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）Ｆａｂｒｉｃプラットフォームの前記分散型台帳のワールドステートデータベースとして作成できる。また、前記分散型台帳のトランザクションデータと前記トランザクションデータを変更するためのトランザクション命令を定義するチェーンコードを作成することもできる。前記サンプルの実施形態では、前記チェーンコードは、前記分散元帳プラットフォームのトランザクションデータとして、ＪａｖａＳｃｒｉｐｔＯｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）でリレーショナルデータベース属性を定義することができる。前記操作の終了時に、前記ワールドステートデータベースは、前記リレーショナルデータベース属性で更新される。また、前記方法は、前記分散型台帳に含めるために前記分散型台帳プラットフォームによって処理されることができる前記形式を説明する、解析および翻訳された構構造化照会言語（ＳＱＬ）クエリを作成することを含めることができる。例えば、前記ＳＱＬクエリは、前記Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）Ｆａｂｒｉｃプラットフォームの前記リレーショナル管理および編成システム仕様のＪＳＯＮ要素を構成することができる。
他のサンプルの実施形態では、トランザクションデータ、およびデータベースの作成や前記分散型台帳への前記データベースに関する情報の記録を含む操作を実行するリレーショナルデータ管理および編成システムを実装するための命令を実行する少なくとも１つのプロセッサを含み、受信したリレーショナルデータベース管理クエリを前記分散型台帳プラットフォームによって処理できるクエリ操作に変換し、クエリ結果を生成するために前記分散型台帳プラットフォームで前記クエリ操作を実行し、および前記分散型台帳に含めるために前記分散型台帳プラットフォームによって処理されることができる形式で前記分散型台帳プラットフォームに記録する、分散型台帳を実装する分散型台帳プラットフォームを含むシステムが提供される。前記システムは、さらに、（１）ユーザーが、構造化照会言語（ＳＱＬ）クエリを提供するための前記リレーショナルデータ管理および編成システムへのユーザーインターフェース、（２）ＳＱＬクエリを前記リレーショナルデータ管理および編成システムへのアプリケーションプログラムインターフェイスを介して前記リレーショナルデータ管理および編成システムに渡すユーザーアプリケーション、または（３）ＳＱＬクエリを実行するスマートコントラクトを、含む前記リレーショナルデータベース管理クエリを生成するための手段を含めることができる。
前記システムのサンプルの実施形態では、前記少なくとも１つのプロセッサが、さらに、前記ＳＱＬクエリを代替としてデータ操作言語（ＤＭＬ）書き込み操作、ＤＭＬ読み取り操作、またはデータ定義言語（ＤＤＬ）操作を含むＳＱＬ操作に解析する、および前記ＳＱＬ操作および前記ＳＱＬ操作に含まれるすべてのリレーショナルデータのＪａｖａＳｃｒｉｐｔＯｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）表現を作成する、命令を実行する。前記少なくとも１つのプロセッサは、さらに、前記ＳＱＬ操作の実行から生じるトランザクションがプラットフォームに関連する範囲まで前記分散型台帳への受け入れに向かって進行したかどうかを決定するために命令を実行することができる。例えば、ＯＰＳＴＡＴ命令は、対応するトランザクションのより明確なステータスをフェッチするために、前記ＤＭＬ書き込み操作の最後に追加されることができる。
さらなるサンプル実施形態では、前記分散型台帳プラットフォームは、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）Ｆａｂｒｉｃプラットフォームであり、前記少なくとも１つのプロセッサは、チャネルを作成し、どのピアコンピューターが、前記データベースのコピーおよび前記リレーショナルデータベースに関するメタデータを書き込む通常のトランザクションを維持するかを定義する構成トランザクションを実行することによって、および前記分散型台帳のトランザクションデータを定義するチェーンコードと、前記トランザクションデータを変更するためのトランザクション命令を作成することによって、前記Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）Ｆａｂｒｉｃプラットフォームの前記分散型台帳のためのワールドステートデータベースとして前記データベースを作成する命令を実行する。前記少なくとも１つのプロセッサは、さらに、ＪａｖａＳｃｒｉｐｔＯｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）のリレーショナルデータベース属性を前記分散型台帳プラットフォーム上の前記分散型台帳の前記トランザクションデータとして定義するチェーンコードおよび前記リレーショナルデータベース属性で前記ワールドステートデータベースの更新情報に対応する命令を実行することができる。前記少なくとも１つのプロセッサはまた、前記分散型台帳に含めるために前記分散型台帳プラットフォームによって処理されることができる前記形式を説明する解析および変換された構造化照会言語（ＳＱＬ）クエリを作成するための命令を実行することができる。
本明細書で説明される実施形態はまた、本開示全体を通して説明される前記方法を実装するための命令でコード化されたコンピュータシステムおよびコンピュータ可読媒体を包含する。例えば、本明細書に記載の前記システムおよび方法は、本明細書に記載の分散型台帳プラットフォームに実装されたデータベースにデータにアクセスして格納するための機能を提供するために、前記クラウド内のコンピューティングプラットフォームに実装されることができる。
前記本開示は、添付の図面の図に限定ではなく例として示され、同様の参照は類似の要素を示し、以下のようなものである。
図１は、サンプル実施形態における前記リレーショナルデータ管理および編成システムのブロック図である。 図２は、Ｎｏｄｅ．ｊｓ（登録商標）がプログラミング言語であり、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）Ｆａｂｒｉｃがサンプル実施形態で使用される前記分散型台帳プラットフォームである具現化における前記リレーショナルデータ管理および編成システムの実装のブロック図である。 図３は、サンプル実施形態における前記リレーショナルデータ管理および編成システムのためのデータベース作成に関与するアクティビティ、コンポーネント、およびデータを示すブロック図である。 図４は、サンプル実施形態における、前記リレーショナルデータ管理および編成システムの既存のデータベースにリレーショナルデータを書き込むための動作を示すブロック図である。 図５は、サンプル実施形態における、前記リレーショナルデータ管理および編成システムの前記ユーザインターフェースによって、または前記リレーショナルデータ管理および編成システムの言語固有ＳＫＤおよびアプリケーションプログラムインターフェースを介してユーザのアプリケーションによって要求されたデータ操作言語（ＤＭＬ）読み取りクエリの前記実行を示すブロック図である。 図６は、サンプル実施形態における、スーパーアドミニストレータレベルより下のアクセスのためのユーザを追加するためのリレーショナルデータアクセス制御の第１の部分に含まれるコンポーネントおよびデータを示すブロック図である。 図７は、サンプル実施形態において、ユーザアプリケーションノードとしてモデル化されている、ＥＬＥＭＥＮＴ Ｆａｒｂｉｃ－Ｎｏｄ．ｊｓ（登録商標）ＳＫＤとユーザのアプリケーションとの相互作用およびそれらが両方ともホストされる実行環境を示すブロック図である。 図８は、サンプル実施形態において、前記リレーショナルデータ管理および編成システムを使用して、分散型台帳への成功したＳＱＬ ＤＭＬ書き込み操作の例の論理フロー図である。 図９は、サンプルの実施形態における、前記リレーショナルデータ管理および編成システムを使用して、分散型台帳から成功したＳＱｌ ＤＭＬ読み取り操作の例の論理フロー図である。 図１０は、サンプルの実施形態における、データ定義言語（ＤＤＬ）書き込みの正常な実行を示すブロック図である。 図１１は、本明細書に開示される前記リレーショナルデータ管理および組織の１つまたは複数の実施形態を実装するために適した専用コンピュータにプログラムされることができる典型的な汎用コンピュータのブロック図である。 図１２は、「最初に実行し、次に注文する」設計を示している。 図１３は、ピアノードで構成されるブロックチェーンネットワークを示しており、各ノードは、台帳のコピーおよびスマートコントラクトのコピーを保持することができる。 図１４は、台帳のインスタンスおよびチェーンコードのインスタンスをホストしているピアを示している。 図１５は、複数の台帳をホストしているピアを示している。 図１６は、複数のチェーンコードをホストするピアの例を示している。 図１７は、前記台帳がすべてのピアで最新に保たれることを保証する、注文者と連携したピアを示している。 図１８は、特定のピアおよびアプリケーションのセットが、ブロックチェーンネットワーク内で互いに通信することを可能にするチャネルを示している。 図１９は、複数の組織を有するブロックチェーンネットワーク内のピアを示している。 図２０は、ピアがチャネルに接続するとき、そのデジタル証明書がチャネルＭＳＰを介してそれ自身の組織を識別することを示している。 図２１は、承認された提案応答を返すピアによって独立して実行されるトランザクション提案を示している。 図２２は、ブロックをピアに配布することである、注文ノードの第２の役割を示している。 図２３は、２つの状態を含む台帳ワールドステイトを示している。 図２４は、有効なクレジットカードを持っているだけでは不十分であることを示している－それはまた店によって受け入れられなければならない。 図２５は、公開鍵インフラストラクチャ（ＰＫＩ）の要素を示している。 図２６は、Ｍａｒｙ Ｍｏｒｒｉｓと呼ばれる当事者を説明するデジタル証明書を示している。 図２７は、Ｍａｒｙが、自分の秘密鍵を使用してメッセージに署名する例を示している。 図２８は、異なるアクターに証明書を分配する証明機関（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ：ＣＡ）を示している。 図２９は、これらの各中間ＣＡの証明書の発行ＣＡがルートＣＡ自体であるか、またはルートＣＡへの信頼の鎖を有する限り、ルートＣＡと一連の中間ＣＡとの間に信頼の鎖が確立されることを示す。 図３０は、ＣＲＬを使用して、証明書がまだ有効であることを確認することを示している。 図３１は、アクセスレベルおよびパーミッションの決定を示している。 図３２は、データおよび操作オブジェクトの概要を示している。
図１～図３２に関する以下の説明は、当業者がそれらを実践できるようにするための特定の実施形態を十分に示している。他の実施形態は、構造的、論理的、プロセス、および他の変更を組み込むことができる。いくつかの実施形態の部分および特徴は、他の実施形態のものに含まれるか、またはそれらの代わりになることができる。請求項に記載の実施形態は、それらの請求項の利用可能なすべての同等物を包含する。
分散型台帳技術（ＤＬＴ）：ネットワークに参加している複数のコンピューター間で複製、共有、および同期されたデジタルデータを可能にする多数の技術のいずれか。分散型台帳技術は、同期されると「分散型台帳」と総称される前記デジタルデータの変更に対して本質的に耐性があるように設計されている。分散型台帳は通常、新しい情報を検証するためのプロトコルに集合的に準拠するピアツーピアネットワークによって管理される。分散型台帳を作成および保守できるシステムは、分散型台帳プラットフォームと呼ばれる。「分散型台帳プラットフォーム」には、Ａｉｏｎ、ＡｒｃＢｌｏｃｋ、Ｃａｒｄａｎｏ（商標）、Ｅｎｉｇｍａ、ＥＯＳ、Ｅｔｈｅｒｅｕｍ、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）Ｆａｂｒｉｃ、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）Ｉｒｏｈａ、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）Ｓａｗｔｏｏｔｈ、ＩＣＯＮ、ＩＯＴＡ、Ｋｏｍｏｄｏ、Ｌｉｓｋ（商標）、ＭｕｌｔｉＣｈａｉｎ、Ｎｅｂｉｌｏ、ＮＥＭ、ＮＥＯ、ＮｘＴ、Ｑｔｕｍ、Ｓｍｉｌｏ、Ｓｔｅｌｌａ、Ｓｔｒａｉｔｉｓ、Ｔｅｚｏｓ、Ｗａｎｃｈａｉｎ、Ｗａｖｅｓ、およびＺｉｌｌｉｑａ、に加えて前述の派生物その他などの既知のプラットフォームが含まれる。これらのプラットフォームの多くは、分散型台帳技術プラットフォームのサブセットである「ブロックチェーン技術」または「ブロックチェーン」プラットフォームでもある。
スマートコントラクト：前記分散型台帳プラットフォームで行われる汎用計算を提供するコンピュータープロトコル。スマートコントラクトトランザクションは、単純な場合もあれば、高度なロジックを実装する場合もある。結果として生じるトランザクションは、通常、台帳の参加者に対して透過的であり、追跡可能で不可逆的である。
ＪＳＯＮ：ＪａｖａＳｃｒｉｐｔＯｂｊｅｃｔ Ｎｏｔａｔｉｏｎは、軽量でテキストベースの人間が読めるデータ交換形式である。
ＳＱＬ：構造化照会言語は、リレーショナルデータベース管理システムにアクセスして操作するための標準言語である。
Ｎｏｄｅ．ｊｓ（登録商標）：ブラウザの外部でＪａｖａＳｃｒｉｐｔコードを実行する無料のオープンソースサーバー環境。Ｎｏｄｅ．ｊｓ（登録商標）は、ＣｈｒｏｍｅブラウザのＪａｖａＳｃｒｉｐｔランタイム上に構築された非同期プログラミングプラットフォームである。Ｎｏｄｅ．ｊｓ（登録商標）の詳細については、「Ｎｏｄｅ．ｊｓ（登録商標）について」 Ｎｏｄｅ．ｊｓ、Ｎｏｄｅ．ｊｓ Ｆｏｕｎｄａｔｉｏｎ、ｈｔｔｐｓ：／／ｎｏｄｅｊｓ．ｏｒｇ／ｅｎ／ａｂｏｕｔ／を参照可能。
Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）Ｆａｂｒｉｃ：幅広い業界のユースケースにモジュール性と汎用性を提供する、エンタープライズグレードの許諾された分散型台帳プラットフォーム。ファブリックのアーキテクチャには、ＩＤプロバイダー、チャネル、ワールドスケールデータベース、およびユーザーとシステムのチェーンコードが含まれる。Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）Ｆａｂｒｉｃの詳細については、添付の付録Ａを参照のこと。
チェーンコード：ファブリックでは、ソフトウェアは、次のいずれかを行う。（ａ）１つまたは複数の資産、および前記資産を変更するためのトランザクション命令、 言い換えると、ビジネスロジックを定義する。（ｂ）前者の実行を管理するルールとアクティビティを含むプラットフォームを拡張または変更する。チェーンコードは、キーと値のペアまたはその他の状態データベース情報を読み取ったり変更したりするためのルールを適用する。チェーンコード関数は、前記台帳の現在の状態データベースに対して実行され、トランザクション提案を通じて開始される。チェーンコードを実行すると、ネットワークに送信され、すべてのピアの前記台帳に適用される一連のｋｅｙーｖａｌｕｅ書き込み（書き込みセット）が発生する。チェーンコードは、プラットフォームに依存しないスマートコントラクトの概念と同等と見なすことができる。
Ａｐａｃｈｅ ＣｏｕｃｈＤＢ（登録商標）：Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）Ｆａｂｒｉｃに組み込まれているワールドステートデータベースのオプション。Ａｐａｃｈｅ ＣｏｕｃｈＤＢ（登録商標）は、チェーンコードデータ値がＪＳＯＮとしてモデル化されている場合、リッチクエリをサポートする。ＣｏｕｃｈＤＢ（登録商標）のインデックス作成とクエリは、ここで説明する前記リレーショナルデータ管理および編成システムのサンプルの実施形態で使用するためのオプションである。ＣｏｕｃｈＤＢ（登録商標）の詳細については、添付の付録Ａを参照のこと。
リレーショナルモデルの価値は、データの表現とそれを読み書きするプログラムとの間に独立性を確立することから生まれる。データ管理のための再利用可能なフレームワークを奨励することに加えて、リレーショナルデータベース管理システム（ＲＤＢＭＳｓ）は、前記データの書き込みに関するルールを適用し、あるプログラムのデータ操作が他のプログラムのそのデータを見つけてアクセスする能力を壊すことを不可能にする。これらの原則の第１番目は、「順序依存」の非合法化である。あるプログラムが、特定の順序で物理的に維持されているデータに依存している場合、この要件を知らない別のプログラムが最初のプログラムを壊す可能性がある。第２番目の原則は、「インデックス依存」の防止である。インデックス作成は、おそらく他の操作を犠牲にして、一部の操作のパフォーマンスを向上させるためのデータの冗長ストレージである。すべてのプログラムのパフォーマンス設定に対応することは不可能であるが、前記リレーショナルモデルは、少なくとも、データセットのインデックスが変更された場合にプログラムが破損しないことを保証する。第３番目の原則は、「アクセスパスの依存」を防ぐことである。前記リレーショナルモデルでは、プログラムは読み取りと書き込みを行うデータを知るだけでよく、前記データがストレージ内でどのように編成されているかについての追加情報は必要ない。ＲＤＢＭＳｓが登場する前は、データが階層構造に編成されていたため、後で再配置され、そのデータを見つけて操作するプログラムの機能が不必要に損なわれることがよくあった。
ここで説明する前記リレーショナルデータ管理および編成システムは、これら３つの原則を実現する。ただし、これら３つの原則を実現する、分散型台帳で使用するリレーショナルデータ管理および編成システムの作成に伴う課題を理解するには、分散型台帳プラットフォームに固有の考慮事項をまず初めに理解する必要がある。
分散型台帳技術は、２００９年に発明された用途である暗号通貨と一般の人々の心の中で密接に関連している。しかし、ピアツーピアマネーの作成は、他の目的のための分散型計算方式へのまったく新しいアプローチの発明でもあった。保証されたデータの可用性、集中制御からの解放、または暗号化された改ざん防止などの機能を活用するために、さまざまな用途が検討されている。
分散型台帳の採用に関する現在の取り組みは、インターネットの早期採用を彷彿とさせる。Ｗｅｂサイトが成熟するにつれて、Ｗｅｂサイトを圧迫したデータ管理に関する同じ失敗を再現するか、回避する可能性がある。初期のＷｅｂサイトと同様に、分散型台帳の暗号通貨使用は、比較的単純なデータ構造とそれらを管理するためのハードコードされたビジネスロジックを特徴としていた。しかし、その後のスマートコントラクトの発明により、任意の複雑さのデータとルールへの扉が開かれた。
サプライチェーンロジスティクスのような企業の使用事例は、分散型台帳に情報とロジックを競争相手の量で加えており、すぐに従来のソリューションを大幅に上回るだろうが、既存の標準化されたデータ管理ツールの利点はない。すべてのプログラマーが独自のストレージを設計すると、その結果、データは、それを書き込むプログラム（スマートコントラクト）と緊密に結合される。この結合を減らすには、ここで説明するようなリレーショナルデータ管理および編成システムが必要である。
残念ながら、分散型台帳でその接続を切断することは、リレーショナルデータベースを実装するときに直面する状況よりも複雑である。元の完全に分散化された形式において、分散型台帳は、実際には、参加者間のコンセンサスと信頼を形成するために、ロジックとデータ間の緊密な接続に依存している。すべての参加者は、まったく同じロジックを実行し、まったく同じ結果を受け取ることを確認する。これは、これらの分散型台帳プラットフォームでのデータ管理にいくつかの大きな影響をもたらす。たとえば、分散型台帳へのデータの書き込みに影響を与えるデータ管理システムの任意の部分は、前記データを管理する前記スマートコントラクト内およびその制御下に配置され、本質的に前記スマートコントラクト自体の一部になる。また、前記スマートコントラクトの一部として、前記データは前記ネットワーク内のすべての参加者に伝播されるため、前記参加者は同じデータ作成ロジックを実行できる。
ただし、ロジックとデータ間のこの結合により、制約のある分散型台帳プラットフォームの場合であっても、前記リレーショナルモデルの利点が無関係になることはない。まず、団体協約によってデータを更新できるようにする同じコンセンサスメカニズムを構成して、参加者が既存のスマートコントラクトのアップグレードまたは追加に同意できるようにすることができる。ただし、これらの契約が既存の分散型台帳データを読み取って使用できない場合、それらは役に立たない。スマートコントラクトは、一般的に今日それを行うことができず、その結果、そのようなアップグレードは、その有用性にもかかわらず、製作物としての分散型台帳システムでは一般的に見られない。
個々のスマートコントラクトプログラム内でさえ、前記契約の範囲と複雑さが増すにつれて、ストレージへの一貫したアプローチがますます重要になってきている。今日の電子通貨と取引可能な資産の比較的単純なルールは、多くの開発者、再利用可能なコンポーネント、および進化する要件を含む、完全に分散された台帳ベースのサプライチェーンとソーシャルプラットフォームに取って代わられている。これらの開発者は、大規模な従来のプログラムの場合と同様に、データストレージへの予測可能なアプローチを望んでおり、前記リレーショナルモデルはその予測可能なアプローチを提供する。
前記リレーショナルモデルの有用性は、一部のプラットフォームでのデータ自体へのアクセス許可を除いて、コンセンサスによって管理されていないため、純粋な読み取り操作の場合にさらに大きくなる。これにより、新しい理由で既存のデータを使用する価値がある状況が増える。前記分散型台帳のデータがリレーショナルルールに従って保存されている場合、前記元のスマートコントラクトプログラマーが想定していた以上の目的で、前記分散型台帳の内部または外部で実行されているＲＤＢＭＳシステムによって効率的に読み取られて処理される可能性がある。
分散型台帳技術のすべての実装がすべての分散型台帳技術機能を利用しているわけではなく、暗号通貨のようなパブリックネットワークで見られる相互不信のレベルを想定することを余儀なくされている。特に企業環境では、さまざまな理由から、部分的な採用が実際に一般的である。一般的な状況には、暗号化された改ざん防止やデータ複製などの機能を実現するための便利な方法として、分散型台帳プラットフォームを使用することが含まれる。企業はまた、おそらく将来のより分散されたアプリケーションへの第一歩として、緩和されたコンセンサスルールまたは一元化されたフロントエンドを使用して、完全な制御下で分散型台帳ネットワークを実装する。また、信頼度の高いコンソーシアムは、サポートスタッフに対する厳格なスマートコントラクトの実施とともに分散型台帳ネットワークを設定するが、管理者と内部監査人は、分散型台帳データを自分の権限で直接更新できる。いずれの場合も、分散型台帳データは、読み取り専用操作の場合と同様に、読み取りと書き込みの両方で従来のデータベースとまったく同じように管理されることができる。
サンプル実施形態
本明細書に記載されるリレーショナルデータ管理及び編成システムは、上述した利点を届け、異なる分散型台帳プラットフォーム及びプログラミング言語にわたるリレーショナルデータ管理及び編成システムの実装を標準化する１組の仕様を提供する。本明細書に記載されるリレーショナルデータ管理及び編成は、分散型台帳に向けてのリレーショナルデータの管理及び編成を指示するに当たり使用されるＳＱＬ（ストラクチャード・クエリ・ランゲージ）の標準ダイアレクトのサブセットも提供する。本明細書に記載されるリレーショナルデータ管理及び編成システムは、多種多様なプラットフォーム及び言語にわたる実装に向けて更に設計されてきた。サンプル実施形態では、リレーショナルデータ管理及び編成システムは、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリック分散型台帳ネットワーク及びＮｏｄｅ．ｊｓ（登録商標）プログラミング言語で実装され、Ｎｏｄｅ．ｊｓ（登録商標）で書かれたユーザプログラムをサポートするメカニズムを有する。しかしながら、他の分散型台帳プラットフォーム及びプログラミング言語が、そのようなプラットフォーム及び言語の付随する利点及び欠点と共に使用されてもよいことが理解されよう。
リレーショナルデータ管理及び編成システムの説明は、全ての実装をガイドすることが意図される１組の仕様、インターフェース、及びコアコンポーネントから始まる。図１は、サンプル実施形態のリレーショナルデータ管理及び編成システム１００のブロック図である。図１に図示されるリレーショナルデータ管理及び編成システム１００の部分は、全ての実装で共通であり、一方、他の部分はカスタマイズされるが、１組の共通仕様に従う。図１は、これらのコンポーネント及び仕様を示すのに適合されたコンポーネント図である。この説明全体を通して、リレーショナルデータ管理及び編成システム１００は、説明のために「ＥＬＥＭＥＮＴ」とも呼ばれる。
共通仕様は、概念要件を示す＜＜仕様＞＞ステレオタイプのオブジェクト要素として表される。仕様は、リレーショナルデータ管理及び編成システムの全ての実装の中で共通の方法で実装されることが予期される態様である。＜＜抽象＞＞ステレオタイプは、提示される必要があるが、各実現で別様に実装される実際のソフトウェアコンポーネントを表す。示されるインターフェースもまた、全ての実装に共通する仕様である。
言語固有ソフトウェア開発キット（Ｌａｎｇｕａｇｅ Ｓｐｅｃｉｆｉｃ Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ：ＳＤＫ）コンポーネント１０２は、ユーザアプリケーションと統合し、コマンドをリレーショナルデータ管理及び編成システム（ＥＬＥＭＥＮＴ）ＡＰＩ１０４に中継する。言語固有ＳＤＫ仕様１０２は、異なるユーザプログラミング言語にわたり共通の経験を生み出すことを目的とする。サポートされるコマンドの中には、ＳＱＬのサブセットがあり、これはＥＬＥＭＥＮＴ ＳＱＬ１０５として本明細書では指定される。言語固有ＳＤＫ１０２からの他の全ての呼び出し及びＥＬＥＭＥＮＴユーザインターフェース（ＵＩ）１０６からの入力と共に、受信したコマンドは、ＥＬＥＭＥＮＴコンソール１０８によりパーズ、妥当性確認、且つ対処され、ＥＬＥＭＥＮＴコンソール１０８はＥＬＥＭＥＮＴデータ定義言語（Ｄａｔａ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ：ＤＤＬ）パーサ１１０への依存性を有する。ＥＬＥＭＥＮＴ ＵＩ１０６は、管理タスク及び報告タスクについての直接人間対話に対処する。ＥＬＥＭＥＮＴ ＵＩ１０６は、有効な入力クエリを構築するのにユーザを支援し、システムレスポンスを編成フォーマットで表すグラフィカル・ウェブ・プラットフォームである。
サンプル実施形態では、ＤＤＬ演算のみが、ＥＬＥＭＥＮＴ ＤＤＬパーサ１１０を介してＥＬＥＭＥＮＴコンソール１０８により扱われる。データ操作言語（Ｄａｔａ Ｍａｎｉｐｕｌａｔｉｏｎ Ｌａｎｇｕａｇｅ：ＤＭＬ）演算は、サービス・レイヤ・インターフェース１１４を経由して分散型台帳プラットフォーム固有コンポーネント１１２に沿って渡され、分散型台帳プラットフォーム固有コンポーネント１１２による対処に向けてＥＬＥＭＥＮＴ ＳＱＬ ＤＭＬパーサ１１６によりパーズされる。上述されていない機能は、一連の分散型台帳プラットフォーム固有コンポーネント１１２により実現される。サービス・レイヤ・インターフェース１１４は、ＥＬＥＭＥＮＴコンソール１０８と、これらのコンポーネント及びそれらの機能のエントリポイントである分散型台帳プラットフォーム固有サービスレイヤ１１８との間のリンクとして働く。サービス・レイヤ・インターフェース１１４は、恐らくはユーザのスマートコントラクトにより開始される演算を除き、全てのアクションで呼び出される。
分散型台帳プラットフォーム固有サービスレイヤ１１８は、リレーショナルデータ管理及び編成システム１００の主要演算論理を形成し、全てのユーザ及びデータ管理演算の達成を担当する。そのような演算は、分散型台帳プラットフォーム固有サービスレイヤ１１８自体とＥＬＥＭＥＮＴ特徴１２０が追加された分散型台帳プラットフォームとの間で分割される。作業の厳密な分割は、分散型台帳プラットフォームの性能に依存する。機能は３つのサブ仕様により提供される。
１．リレーショナル・データ・アクセス制御仕様１２２は、リレーショナルデータ管理及び編成システム１００の全ての実装が続く５つのレベルの粒度の粗いアクセス制御モデルを指定する。この仕様は、ユーザの役割及びユーザが、データへのアクセスを含め、リレーショナルデータ管理及び編成システム１００のシステム機能へのアクセスにいかに影響するかを文書化する。アクセス制御は、異なるプラットフォームで大きく異なる手法を使用する。仕様は付録Ｂは共通の態様を文書化する。
２．分散型台帳仕様上のリレーショナルデータ１２４は、データ表現の要件（ＪＳＯＮスキーマ）及びサポートされるデータ演算を定義する。この仕様は、付録Ｃにおいてリレーショナル・データ・ストレージについての要件を文書化する。
３．スマートコントラクト統合仕様１２６は、どのリレーショナルデータ特徴がスマートコントラクトからアクセス可能かを示す。
言語固有ＳＤＫ１０２はそれぞれ、分散型台帳アプリケーション実装で人気のあるプログラミング言語からＥＬＥＭＥＮＴ ＡＰＩ１０４の全機能にアクセスするインターフェースを提供する。これらのＳＤＫの仕様は、関数名、パラメータの順序及び意味、戻り値、及びエラー等に関して一貫性を最大化する。ファブリック及びＮｏｄｅ．ｊｓ（登録商標）を使用して実装される実現について以下説明する。
サンプル実施形態では、ＥＬＥＭＥＮＴ ＡＰＩ１０４は、データベース演算を呼び出す共通のエントリポイントとしてリレーショナルデータ管理及び編成システム１００内で使用されるインターフェースである。ＥＬＥＭＥＮＴ ＵＩ１０６及び言語固有ＳＤＫ１０２が何であれ、使用中の実現に存在する言語固有ＳＤＫ１０２の両方により呼び出される。「ＲＥＳＴ ＡＰＩ」と呼ばれることもあるウェブインターフェースの形態で指定される。ＥＬＥＭＥＮＴ ＡＰＩ１０４は、ＥＬＥＭＥＮＴＤＢ＿コンソール１０８により実装され、リレーショナルデータ管理及び編成システム１００の全ての実現で再使用される。ＥＬＥＭＥＮＴ ＡＰＩ１０４の更なる詳細は付録Ｄに提供される。
ＥＬＥＭＥＮＴ ＵＩ１０６は、ユーザが、リレーショナルデータ管理及び編成システム１００により実装されるデータベースを用いて手動で作用できるようにするユーザ・インターフェース・コンポーネントである。ＥＬＥＭＥＮＴ ＵＩ１０６は、ユーザを追加し、ユーザ・アクセス・レベルを調整し、内蔵テキストエディタを使用してＳＱＬクエリを利用可能なデータベースに対して実行し、クエリ例及びＥＬＥＭＥＮＴ固有ＳＱＬ言語拡張のシンタックスを含むユーザドキュメントにアクセスし、提出されたクエリのステータス情報を閲覧し、実行が首尾よく完了したクエリからの戻り値を閲覧する能力をユーザに提供する。
ＥＬＥＭＥＮＴコンソール１０８及びＥＬＥＭＥＮＴ ＳＱＬ ＤＤＬパーサ１１０は、リレーショナルデータ管理及び編成システム１００の全ての実現に存在するコアコンポーネントである。ＥＬＥＭＥＮＴコンソール１０８は、言語固有ＳＤＫ１０２を発端とするデータベースコマンドをＥＬＥＭＥＮＴ ＡＰＩ１０４（代表的状態転送（ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ ｓｔａｔｅ ｔｒａｎｓｆｅｒ：ＲＥＳＴ）ＡＰＩである）を介して又はこれもまたＥＬＥＭＥＮＴコンソール１０８がサービングするユーザからＥＬＥＭＥＮＴ ＵＩ１０６を介して直接、受け入れる。ＥＬＥＭＥＮＴコンソール１０８は、それらのコマンドを、リレーショナルデータ管理及び編成システム１００の分散型台帳プラットフォーム固有コンポーネント１１２にリンクするサービス・レイヤ・インターフェース１１４に渡すことができる形態に変換する。
サンプル実施形態では、リレーショナルデータ管理及び編成システム１００の共通の構成要素（１０４、１０６、１０８、１１０）は、Ｎｏｄｅ．ｊｓ（登録商標）ではウェブサービスとして実装され、デプロイ柔軟性及び必要であれば水平スケーリングを可能にする。
ＥＬＥＭＥＮＴ ＳＱＬ１０５は、典型的なＳＱＬ演算を幾つかのＥＬＥＭＥＮＴ固有拡張と共に含み、開発者に最も馴染みがあるＲＤＢＭＳ演算を記述するためのグラマーである。サンプル実施形態では、リレーショナルデータ管理及び編成システム１００のＳＱＬシンタックスは、ＩＳＯ／ＩＥＣ９０７５（現在はＳＱＬ：２０１６）のサブセットと互換性があるように設計された。アクセス管理及び実装のために、ＥＬＥＭＥＮＴ ＳＱＬでの演算は、ＤＤＬクエリ、ＤＭＬ書き込みクエリ、及びＤＭＬ読み出しクエリに分類されてきた。
ＳＱＬへのＥＬＥＭＥＮＴ拡張は、分散型台帳データ環境で作業するための適合及び簡易関数を含む。これらの拡張は、ＳＱＬシンタックスと併せて使用されて、ＥＬＥＭＥＮＴシステムに有意なクエリを形成するＥＬＥＭＥＮＴ固有キーワードである。サンプル実施形態における拡張キーワードは、以下を含む：
１．ＯＰＳＴＡＴ（Ｏｐｅｒａｔｉｏｎ Ｂｒｏａｄｃａｓｔ Ｓｔａｔｕｓ：演算ブロードキャストステータス）－この演算は、特定の演算のトランザクションが、利用される特定の分散型台帳プラットフォームに関連する程度まで分散型台帳に進入したか否かをチェックする。ＤＤＬ演算のＯＰＳＴＡＴは、リレーショナルデータ管理及び編成システム１００に向けてデフォルトにより設定されるが、ＯＰＳＴＡＴは、ＤＭＬ書き込み演算の終わりに追加して、そのトランザクションのより確定的なステータスをフェッチすることができる。ＯＰＳＴＡＴが使用されている間、予期される可能な３つのレスポンスがある－成功、失敗、又は時間切れ。
２．クエリレベル－クエリレベル特徴は、ＤＭＬ読み出し演算（例えば、ＳＥＬＥＣＴ）と共に専ら機能して、リレーショナルデータ管理及び編成システム１００の特定のレコードについてのメタデータ情報をフェッチする。クエリレベルを使用することにより得られる２つのレベルの情報がある－第１のレベルの情報はレコードについての基本情報であり、第２のレベルの情報は、レコード作成日、最終変更日、ユーザによる変更、及び他の詳細等の粒度の細かい情報を提供するより深いクエリである。
３．ブックマーク－この特徴は、リレーショナルデータ管理及び編成システム１００におけるレコードカウントにより定義されるページにおけるテーブルデータの検索に関連する。デフォルトにより、ローカウントに限度を有して実行されるあらゆるクエリは、同じ基準に基づいてデータの次の等サイズページへのリファレンスとして働くブックマーク値により達成される。ブックマークキーワードが提供される場合（ＳＥＬＥＣＴクエリのみが該当する）、クエリ結果と共に含まれることになる。
４．ＥＬＥＭＥＮＴカラムデフォルト（ＥＬＥＭＥＮＴ＿ＣＯＬＵＭＮ＿ＤＥＦＡＵＬＴ）－このキーワードは、更新又は挿入ＳＱＬ演算と併用されて、リレーショナルデータ管理及び編成システム１００におけるテーブルカラムにデフォルト値が使用されるべきであることを示す。デフォルト値は、テーブル作成中、カラムに割り当てることができる。デフォルト値なしで構成されたカラムは、このキーワードにより影響されない。
付録ＥにおけるＥＬＥＭＥＮＴ ＳＱＬ仕様は、リレーショナルデータ管理及び編成システム１００による処理のためのクエリ及びコマンドを表すのに使用することができるＳＱＬシンタックスの変形を形成するために、ＳＱＬシンタックスと組み合わせてこれらの各キーワードの追加詳細を提供する。
サービス・レイヤ・インターフェース１１４は、分散型台帳プラットフォームに向けてリレーショナルデータ管理及び編成システム１００のあらゆる実現でサポートされるべき機能を含む。サービス・レイヤ・インターフェース１１４の仕様は、インターフェース全体に、このサービスレイヤ又は分散型台帳プラットフォーム自体の何れかで実現される機能のサブセットを加えたものを包含する。これらの機能は、
データベースの作成及びドロップ、
テーブルの作成、変更、及びドロップ、
データベース・オブジェクト・メタデータの検索、
ＤＭＬ演算、例えば、レコードの挿入及び選択、
インデックスの作成、変更、及びドロップ等の更なるＤＤＬ演算、
ユーザ特権管理
を含む。
なお、分散型台帳コンテキストでの変更及び削除は常に、分散型台帳データ履歴の不変性により、変更又は削除インジケータの添付により行われる。リレーショナルデータ管理及び編成システム１００は、バルク・トランザクション・サポートを提供し、少なくともレコードレベル変更を包含することも求められる。
サンプル実施形態では、サービス・レイヤ・インターフェース１１４は、Ｎｏｄｅ．ｊｓ（登録商標）で実装され、標的とされるＳＤＫ言語又は分散型台帳プラットフォームに関係なく再使用される。インターフェースを介して受け取ったリクエストのサービスは、分散型台帳固有コンポーネント１１２により実行され、幾つかの関数は、スマートコントラクト統合の達成に必要とされるため、分散型台帳プラットフォーム自体でのみ実現可能である。
ＥＬＥＭＥＮＴ特徴仕様１２０が追加された分散型台帳プラットフォームは、リレーショナル機能がそのプラットフォームのスマートコントラクトにより使用可能であるために、分散型台帳プラットフォームで直接実装されるべき機能を記述する。プラットフォーム自体のように、これらの実装の手法は大きく異なることになる。これらの仕様は、リレーショナルデータ及びスキーマの共通ＪＳＯＮベスデータフォーマットを含め、何がなお共通であるかを記載する。仕様は３つのカテゴリに分割される：分散型台帳でのリレーショナルデータ、アクセス制御、及びスマートコントラクト統合。
１．分散型台帳でのリレーショナルデータ（Ｒｅｌａｔｉｏｎａｌ Ｄａｔａ Ｏｎ Ｄｉｓｔｒｉｂｕｔｅｄ Ｌｅｄｇｅｒ：ＲＤＯＤＬ）仕様
５つの馴染みのある抽象化が、リレーショナルデータ管理及び編成システム１００でのリレーショナルデータ及び関連する機能の指定に使用される。それらはデータベース、テーブル、フィールド、インデックス、及びレコードである。これらの概念が異なる分散型台帳プラットフォームで実装される方法には大きな違いがあるが、以下はあらゆるプラットフォームで該当する：
１．５つの各要素タイプの各インスタンスは、標準ＥＬＥＭＥＮＴフォーマットでスタンドアロンＪＳＯＮドキュメントにより表され、
２．これらのドキュメントは、他の分散型台帳トランザクションと同じ方法及びコンセンサスを使用して分散型台帳に書き込まれ、
３．これらの要素の１つへの状態の各変更又は変化は、ＪＳＯＮドキュメントの完全な更新されたバージョンを分散型台帳に添付することにより表される。
５つのオブジェクトのＪＳＯＮスキーマ定義及び索引付けの最小要件は、リレーショナルデータ管理及び編成システム１００の設計において正式に指定される。
２．リレーショナル・データ・アクセス制御仕様
リレーショナルデータ管理及び編成システム１００の実装は、データベースレベルで個々の分散型台帳アイデンティティに定義される粒度の粗いアクセス制御をサポートする。５つのアクセスレベルに認められた特権は以下である：
－ＳｕｐｅｒＡｄｉｍｎ－作成及びドロップ等のデータベース管理に、Ａｄｉｍｎアクセスレベルの全ての特権を加えたもの。
－Ａｄｍｉｎ－特権管理機能へのアクセスに、ＤＤＬアクセスレベルの全ての特権を加えたもの。
－ＤＤＬ－テーブル及びインデックスのスキーマを変える関数を含む（例えば）ＤＤＬ等として分類される機能へのアクセスに、ＤＭＬ書き込みアクセスレベルの全ての特権を加えたもの。
－ＤＭＬ書き込み－挿入等のデータ書き込みを含むＤＭＬ書き込みとして分類される機能へのアクセスに、ＤＭＬ読み出しアクセスレベルの特権を加えたもの。
－ＤＭＬ読み出し－ＤＭＬ読み出しとして分類される機能へのアクセス。リレーショナルデータの選択クエリ、スキーマ検索、統計の閲覧等を含む。
データ定義言語（Ｄａｔａ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ：ＤＤＬ）は、リレーショナルデータの構造、編成、又は記述を変える演算を指す。データ操作言語（Ｄａｔａ Ｍａｎｉｐｕｌａｔｉｏｎ Ｌａｎｇｕａｇｅ：ＤＭＬ）は、リレーショナルデータ自体が関わる演算を指す。
リレーショナルデータ管理及び編成システム１００の実装では、及びリレーショナルデータが分散型台帳に格納された他のデータと同等の分散型台帳特性を有するという要件のために、アクセスは、分散型台帳演算に使用されるものと同じアイデンティティに基づき、スマートコントラクトの統合を可能にする。
３．スマートコントラクト統合仕様
述べたように、リレーショナルデータ管理及び編成システム１００の主要態様は、スマートコントラクトから直接、リレーショナルデータ機能の大半にアクセスする能力である。スマートコントラクト統合では、スマートコントラクトは、ＤＤＬデータベース演算を除き、言語固有ＳＤＫ１０２に指定された関数と同等の関数を実行する能力を有する。これらの呼び出しの分散型台帳考慮事項は、例えば、コンセンサス並びに入力及び結果の不変記録は、ネイティブのスマートコントラクト実行と同等である。また、これらの関数の呼び出しは、リレーショナルデータ管理及び編成システム１００が実現されている分散型台帳プラットフォームで可能な程度まで、言語固有ＳＤＫ１０２で記述される形態、ネーミング、及びセマンティクスに準拠すべきである。スキーマ変更等のＤＤＬ動作は、１つの分散型台帳トランザクション内での実行がサポート可能ではないような、リレーショナルストレージへの広範囲の更新を含むことが多いため、スマートコントラクト統合から除外される。
ＥＬＥＭＥＮＴ特徴仕様１２０が追加された分散型台帳プラットフォームは、実装に関係なく、非分散型台帳プログラマにとって既に馴染みがあるシンタックス及びセマンティクスを使用して分散型台帳でのリレーショナル・データ・ストレージ及び演算を可能にし、分散型台帳プラットフォームにわたり同一である１組の共通インターフェース、シンタックス、及び要件、特に、リレーショナルデータ管理及び編成システム１００の全ての実装で共通であるＳＱＬシンタックスを使用する能力を記述することが理解されよう。ストレージは、分散型台帳プラットフォーム実装にわたる将来のデータ可搬性を容易にする標準化ＪＳＯＮデータフォーマットを使用して実装される。１組の必要とされる機能はプラットフォームにわたり標準化され、したがって、分散型台帳プラットフォームの選択は、リレーショナルデータ管理及び編成システム１００のようなＲＤＯＤＬプラットフォームを使用する判断とは別個の考慮事項であることができる。そのような機能は、言語固有ＳＤＫ１０２、ユーザコンソール及びＡＰＩ、又はスマートコントラクトを介した一貫するリレーショナル・データ・ストレージ・アクセスを可能にする。
Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックでのリレーショナルデータ管理及び編成システム１００
サンプル実施形態では、分散型台帳プラットフォームにＨｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックを使用するＮｏｄｅ．ｊｓ（登録商標）アプリケーションのソフトウェア開発キットが提供される。
図２は、ファブリック実装がいかに、本明細書に記載されるリレーショナルデータ管理及び編成システム１００の仕様及び追加の機能を実現するかの視覚的概説を提供する。サンプル実施形態では、ファブリックでのリレーショナルデータ管理及び編成システム１００のＲＤＯＤＬ実現は以下の態様を含む。リレーショナルデータ管理及び編成システム１００のデータベースは、ファブリックの「チャネル」概念を利用する。リレーショナルデータ管理及び編成システム１００のファブリック・サービス・レイヤは、新しいデータベースが要求される都度、ファブリックＳＤＫ（分散型台帳プラットフォームと共に含まれる）を使用して、ファブリックチャネルを作成する。システムチェーンコードは、リレーショナルデータ管理及び編成システム１００の機能を含み、ピアノードに既に存在し、新たに作成されたチャネルにアクセス可能になる。チャネル作成はまた、新しい分散型台帳及び「ワールドステート」データベースを参加している全てのピアノードに自動的にセットアップする。また、スクリプトは、リレーショナルデータ管理及び編成システム１００のシステムチェーンコードを呼び出すトランザクションを開始して、分散型台帳にデータベースについての高レベル情報を記録する。続く全てのデータベース書き込み演算は、同様のトランザクションと、ＲＤＯＤＬ仕様に準拠するＪＳＯＮフォーマットでデータオブジェクトを分散型台帳に添付することとを含む。台帳へのデータベース情報のそのような各添付は、ワールド・ステート・データベースにおける各ピアによっても反映される。これは、各データオブジェクトの現在バージョンを読み出し演算に利用できるようにする。
リレーショナルデータ管理及び編成システム１００のコアコンポーネント及び仕様に加えて、図２は、Ｎｏｄｅ．ｊｓ（登録商標）がプログラミング言語であり、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックが使用される分散型台帳プラットフォームである実現でのリレーショナルデータ管理及び編成システムの実装のブロック図である。図２は、ファブリック／Ｎｏｄｅ．ｊｓ（登録商標）実装がいかに、図１に概説された仕様を幾つかの追加の機能と共に実現するかにフォーカスしている。
図２に示されるように、Ｎｏｄｅ．ｊｓ（登録商標）ＳＤＫコンポーネント２００は、言語固有ＳＤＫ１０２のユーザ言語固有機能を実現し、開発者が、開発者のアプリケーションコードから直接、リレーショナルデータ管理及び編成システム１００と対話できるようにする。Ｎｏｄｅ．ｊｓ（登録商標）アプリケーションと併用されるように開発されたＮｏｄｅ．ｊｓ（登録商標）ＳＤＫコンポーネント２００のバージョンの詳細は付録Ｆに提供される。ＥＬＥＭＥＮＴＤＢコンソール１０８、ＥＬＥＭＥＮＴ ＡＰＩ１０４、ＥＬＥＭＥＮＴ ＵＩ１０６、及びサービス・レイヤ・インターフェース１１４は、全ての実装に共通であり、図１と同一である。それらの下で、ＥＬＥＭＥＮＴファブリックサービス２０２は、全てのプラットフォーム演算への間口を実現する。ＥＬＥＭＥＮＴファブリックサービス２０２は、ＡＰＩレイヤと分散型台帳との間の対話の仲介者として働くサービス・レイヤ・インターフェース１１４を実装する。そのサービスは、付録Ｇにより詳細に説明されるように、ＲＤＢＭＳ関連演算の実行に役立つ。ＥＬＥＭＥＮＴ ＳＱＬパーズの実現は、ファブリック実現に２回出現するＥｌｅｍｅｎｔパーサ２０４と呼ばれるコンポーネントにより実現される。まず、Ｅｌｅｍｅｎｔパーサ２０４は、ＥＬＥＭＥＮＴＤＢコンソール１０８に依存するものとして出現し、ＤＤＬパーサを実現する。これは全ての実現にとって共通する。次に、Ｅｌｅｍｅｎｔパーサ２０４は、Ｅｌｅｍｅｎｔチェーンコード２０６に依存するものとして出現し、ＤＭＬパーズを提供し、ＤＭＬ ＳＱＬをユーザ・チェーンコード・スマート・コントラクトでサポート可能にする。Ｅｌｅｍｅｎｔパーサ２０４の仕様は付録Ｈに提供される。
分散型台帳プラットフォーム＋ＥＬＥＭＥＮＴ特徴仕様への依存性を通して直接、ファブリックサービス２０２をサポートするのは、ユーザが登録し、アクセス特権が記録されたアイデンティティプロバイダ（例えば、ファブリック証明機関２０８）、特定の索引付け機能のために直接アクセスされるワールド・ステート・データベース（例えば、ファブリック・ワールド・ステート・データベース２１０）、及びリレーショナルデータ管理及び編成システム１００に向けてカスタマイズされたＨｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリック２１４のコアコンポーネントであるＥＬＥＭＥＮＴファブリック・ピア・イメージ２１２である。
Ｅｌｅｍｅｎｔチェーンコード２０６は、ファブリックに対して全てのデータベース関連演算を実行し、アイデンティティプロバイダ（例えば証明機関２０８）及びワールド・ステート・データベース（例えば、ファブリック・ワールド・ステート・データベース２１０）への依存性も有するＥＬＥＭＥＮＴファブリック・ピア・イメージ２１２に追加される更に作成されたシステムチェーンコードである。ピア自体内の台帳ストレージと組み合わせて、これらは、ＥＬＥＭＥＮＴファブリックピア２１４がアクセス制御を有するリレーショナルデータを実現できるようにする。また、ユーザのスマートコントラクトはシステムチェーンコードを呼び出すこともあるため、これはスマートコントラクト統合も同様に実現する。Ｅｌｅｍｅｎｔチェーンコード２０６の仕様は付録Ｉに提供される。
図３は、リレーショナルデータ管理及び編成システム１００でのデータベース作成に関わるアクティビティ、コンポーネント、及びデータを示すブロック図である。データ毎のデータベース作成は２つのファブリックトランザクションを含む。第１のものは、チャネルを作成し、どのピアがデータベースのコピーを維持するかを定義する「構成トランザクション」である。第２のものは、リレーショナルデータベース自体についてのメタデータを書き込む通常のトランザクションである。
図３は、左に図示される統合モデリング言語（ｕｎｉｆｉｅｄ ｍｏｄｅｌｉｎｇ ｌａｎｇｕａｇｅ：ＵＭＬ）アクティビティモデルと、ＥＬＥＭＥＮＴファブリック・サービス・レイヤ２０２（右側）のトポロジに重ねられたＵＭＬオブジェクト図及びこれらのオブジェクトをホストする、デプロイされたファブリックネットワークとの組合せである。図３は、一連の演算を左側に図示し、システムがファブリックにおけるリレーショナルデータ管理及び編成システム１００で新しいデータベースを作成するように求められている間又は求められた直後に存在する関連データを右側に図示する。データベースの作成は、ファブリックのチャネル（分散型台帳データ分離）作成メカニズムに追加の機能を加えたものを利用する。
図３の左半分のブロックは、データベース作成に関連するコンポーネント、すなわち、ファブリックサービス２０２及びファブリックピア２１４である。データベース作成リクエストを最初に処理するとき、３つのデータオブジェクトがサービスレイヤにより作成される。示されるように、ファブリックチャネル構成ファイル準備アクティビティ３００は、ネットワークにより使用される＜＜チャネル構成ファイル＞＞チャネル．ｔｘ３０２を作成する。ジェネシスブロックアクティビティ３０４との生成構成トランザクションは、ジェネシスブロックを含み、チャネルを開始する特別なファブリックトランザクション＜＜ファブリック構成ｔｘ＞＞３０６を作成する。ジェネシスブロックは、初期構成を含む、分散型台帳に記録されるべき提案される第１のデータである。＜データベース名＞ブロックはジェネシスブロックそれ自体である。それとチャネルの両方には、リレーショナルデータ管理及び編成システム１００のデータベースの名前と一貫する名前が与えられる。チャネル作成及び承認ピアノードのチャネルアクティビティへの参加３０８は、＜＜ファブリック構成ｔｘ＞＞３０６からチャネル構成データ３１０を作成する。チャネル作成及び承認ピアノードのチャネルアクティビティへの参加３０８は、ジェネシスブロック３１４及び対応する空のワールド・ステート・データベース３２２を含む台帳３１３も作成する。リレーショナルデータ管理及び編成システム１００のデータベース属性のデータ表現を含むファブリックトランザクション準備アクティビティ３１２は、リレーショナルスキーマと、リレーショナルデータ管理及び編成システム１００のこのデータベースに格納されるデータを支配する他の属性とを表すＪＳＯＮオブジェクトを含むファブリック分散型台帳トランザクション＜＜ファブリックｔｘ＞＞３１６を作成する。初期データベーススキーマと共にファブリックトランザクション提出３１８は、ファブリック分散型台帳トランザクション＜＜ファブリックｔｘ＞＞３１６をファブリックブロック３２０に組み込む。最後に、ファブリックピア２１４は、３２４において、リレーショナルデータ管理及び編成システム１００のデータベースの属性でワールド・ステート・データベース３２２を自動的に更新する。
チャネルは、内部でデータがファブリック分散型台帳ネットワークで共有される境界である。エリア３２６外のピアノードは、スキーマ情報又はデータを受け取らない。ノード間のネットワーク接続も示される。それらは、ファブリックノード間の通常の相互接続と、ファブリック・サービス・レイヤ内のファブリックＳＤＫライブラリ（図示せず）がピアノードと交信するＨＴＴＰパス３２８とを含む。なお、ファブリックＳＤＫは、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックにより供給されるコンポーネントであり、クライアントプログラムが基本分散型台帳演算をファブリックプラットフォームに対して開始できるようにする、リレーショナルデータ管理及び編成システム１００のファブリックサービスに依存するものとして含まれる。
ファブリックネットワークにおいてチャネルが作成され、トランザクションが処理される全プロセスはモデリングされず、上記オブジェクトは、それらのステップ中、ネットワークに通信され、残りのオブジェクトは作成される。まず、チャネル作成時、そのプロセスではファブリックで普通の３つの項目が取得される：
１．構成ｔｘからのチャネル構成－順序付けサービスは、チャネル構成ファイルからの情報を保持し、特に、チャネルデータが参加ノードに制限されることを保証するのにそれを使用する。
２．＜＜台帳＞＞＜データベース名＞－チャネル／データベースの添付のみデータストレージが作成され、あらゆる参加ピアノードに複製される。
３．＜＜ワールドステート＞＞＜データベース名＞－台帳における各項目の最新値のみを含む台帳へのコンパニオンストレージ（ｃｏｍｐａｎｉｏｎ ｓｔｏｒａｇｅ）が、はるかに効率的にクエリされる形態で提供される。リレーショナルデータ管理及び編成システム１００では、このデータベースはＣｏｕｃｈＤＢ（登録商標）インスタンスであることができ、これは、ファブリックへの標準選択の１つである。
チャネルが作成された後、データベーススキーマ（リレーショナルデータ属性）のＪＳＯＮ表現を含む通常のファブリックトランザクションが処理される。
続くリレーショナルデータベース演算は、更なる添付ファブリックトランザクション（台帳へのコミットが明示的に除外される読み出しクエリを除く）ではＪＳＯＮオブジェクトとして表される。図４は、ＤＭＬ書き込み演算の実行を示す。このプロセスは、ワールド・ステート・データベースに入ると、クエリ及び他のリクエストへ応答するためにリレーショナル・データ・レイヤ１００のシステムチェーンコードにより使用されるＪＳＯＮリレーショナル・データ・オブジェクトを作成する。図５はこれを示し、ＥＬＥＭＥＮＴ ＵＩ１０６又はユーザのアプリケーションにより言語固有ＳＤＫ１０２及びＥＬＥＭＥＮＴ ＡＰＩ１０４を介して要求されたＤＭＬ読み出しクエリの実行を示す。
図４は、リレーショナルデータ管理及び編成システム１００の既存のデータベースにリレーショナルデータを書き込む演算を示すブロック図である。左側のスイムレーンは２つの参加コンポーネントであるファブリックサービス及びリレーショナルデータ管理及び編成システム１００システムチェーンコードを表す。各スイムレーン内部のＵＭＬアクティビティは、コンポーネントが実行する主要アクティビティを表す。太字の矢印はアクティビティを順に結び、追加の矢印は、アクティビティによる影響を受けるデータオブジェクトに接続する。
更新演算に向き合うと、定義されたチャネルにおけるファブリック・ピア・ノード４０２内の＜＜台帳＞＞＜データベース名＞オブジェクト４００は、各ピアノードで複製される図３で作成されたものと同じ台帳である。追加の＜＜ファブリックブロック＞＞４０４は内部に添付されており、リレーショナルデータベース演算を指定する＜＜ファブリックトランザクション＞＞４０６を含む。この特定の演算は、図４の左半分に配置されたアクティビティセクション下で図示されるように、＜＜ファブリックｔｘ＞＞を作成する所望の演算を含むファブリックトランザクションの準備４０８を含む上流プロセスにおいてユーザから受け取られ、４１２において、演算を含むファブリックトランザクションをピアノードに提出し、４１４において、トランザクションが実行され、結果データが生成される。トランザクションは、トランザクションがブロックに処理された場合、リレーショナルデータ管理及び編成システム１００のシステムチェーンコードにより実行されたであろうその演算の結果も含む。幾つかの場合、この実行は、ワールド・ステート・データベースからデータを読み出すチェーンコードも含む。このフローは示されていないが、図５におけるＤＭＬ読み出し演算から理解することができる。
その結果生成されたＥＬＥＭＥＮＴリレーショナルデータＪＳＯＮ４１６は、新しい又は変更されたテーブル、レコード、ユーザ、及びデータベース属性を表すオブジェクトを含む。これらのそれぞれは、影響を受けるデータを識別する一意のキーを有する。ファブリックネットワークは、４１８において、トランザクション及び結果データを処理して、ファブリックブロックにし、ファブリックブロックを台帳４００に添付する。トランザクションの一環として台帳４００に永続的に記録されることに加えて、システムチェーンコードは、４２２において、現在のリレーショナルデータでワールド・ステート・データベース４２０を更新し、ここで、データは、図３において作成されたのと同じワールド・ステート・データベースである＜＜ワールドステート＞＞データベース４２０に流れる。ここで、ワールド・ステート・データベースはリレーショナルデータ管理及び編成システム１００のデータベースの現在状態のみを含むため、同じキーを有するより古いエントリはリレーショナルデータで上書きされ、一方、台帳４００はその履歴を保持する。１つのそのようなオブジェクト４２４がワールド・ステート・データベース４２０内に示されるが、実際には、多くのキー及びオブジェクトがある。
図５は図４と同様の前提であり、全てのコンポーネント及びデータオブジェクトは変わらないままである。唯一の違いは、ＤＭＬ読み出し演算を処理している間にデータオブジェクトが経るアクティビティ及びプロセスである。ファブリック・サービス・コンポーネントにおけるアクティビティセクションは図４にかなり類似するが、ＤＭＬ読み出し演算の実行に成功した後、サービスレイヤは、５００においてクエリレスポンスを受け取る。
サンプル実施形態では、システムチェーンコードは、５０２において、ワールド・ステート・インスタンス５０４と突き合わせてクエリを実行し、それと引き換えに、関連するＥＬＥＭＥＮＴデータＪＳＯＮが流れる。システムチェーンコードはこのデータを更に処理して、クエリ結果５００を生成し、クエリの開始者に返す。読み出しはワールド・ステート・データに対して行われ、したがって、続けて、更新シナリオのようにワールドステートへの変更は行われない。ＤＭＬ読み出しはピア台帳４００にアクセスしない。しかしながら、ファブリックトランザクションは、デフォルト「ＯＰＳＴＡＴ」選択肢がオーバーライドされない限り、トランザクションが行われたピアノードの台帳にログされて、演算の記録を保持する。５０６において「ＯＰＳＴＡＴ」選択肢が選択された場合、ファブリックネットワークはトランザクションを処理してブロックにし、ブロックを台帳４００に添付する。記録されたトランザクションは入力を含み、入力は、クエリを表すＪＳＯＮであるが、結果レコードではない。
ユーザチェーンコード（スマートコントラクト）から開始されるＤＭＬ読み出し演算は図５と同様に動作するが、クエリ結果は、更なる処理に向けてスマートコントラクトに直接返される。
５つの必要とされるデータベースアクセス許可レベルを実現するために、２つのファブリックメカニズムが再使用される。第１に、データベース作成はファブリックチャネルの作成に前提要件を必要とするため、ファブリックネットワーク管理者のみがその許可にふさわしい。残りの４つのアクセスレベルでは、ＥＬＥＭＥＮＴファブリックは、ファブリックの既存のアイデンティティプロバイダ機能の上に乗る。したがって、ファブリックでのＥＬＥＭＥＮＴファブリック・リレーショナル・データ・アクセス制御実現は、アイデンティティプロバイダに登録している間、あらゆるユーザに添付されるデータベース固有の属性を含む。また、ユーザの登録に付加される属性は、そのデータベースへのユーザの特定のアクセスに関する。続けて、ＥＬＥＭＥＮＴシステムチェーンコードへのトランザクションが開始されて、ユーザをデータベースメタデータに追加する。
図６は、ＳｕｐｅｒＡｄｍｉｎレベルよりも低いアクセスにユーザを追加するリレーショナル・データ・アクセス制御の第１の部分に関わるコンポーネント及びデータを図示するブロック図である。制御プロセスは２つのプロセスを含む。第１のプロセスは、６００において、ユーザ追加演算を記録するファブリックトランザクションを準備し、ユーザ追加演算６０２を作成することにより、ファブリック証明機関等のアイデンティティプロバイダに、データベース固有属性を有するユーザを参加登録することである。第２のプロセスは、６０８において、要求側エンティティの機関を使用して、新しいユーザ・アクセス・レベルのＪＳＯＮ表現６０４をアイデンティティプロバイダ６０６におけるユーザのアイデンティティカードに添付することにより、ユーザをデータベース自体に追加する通常のトランザクションである。
図３のように、図６は、ＥＬＥＭＥＮＴファブリック・サービス・レイヤ及び関連するファブリックネットワークを実行するトポロジに重ねられたＵＭＬオブジェクトモデルである。ＵＭＬオブジェクトは、ユーザをリレーショナルデータ管理及び編成システム１００に追加することについて、ファブリック・サービス・コンポーネント、モデルの左セクションで述べられる関連するシーケンシャルアクティビティ、及び右側の関連付けられたデータの表現をモデリングする。図３からのモデルの説明及び演算前提はここでも該当し、特に、ファブリック証明機関ノード６０６等のアイデンティティプロバイダが追加されるが、影響を受けるセクションのみがモデルに表示されている。ＵＭＬモデルは、サービスレイヤ、ファブリック・ピア・ノード、及び順序付けサービスノードと接続し、分散型台帳アイデンティティについての情報をそれらに供する。順序付けサービス及びその接続は、ファブリックトランザクション処理において普通であることを超えた特別な役割をこのプロセスで持たないため、このモデルに示されていない。なお、順序付けサービスノード及びアイデンティティプロバイダ（例えば証明機関）は同時に、他のピアノード、チャネル、及び恐らくはリレーショナルデータ管理及び編成システム１００のデータベースにサービングしている可能性が高い。
図６のデータオブジェクトは、新しいユーザを１つのＥＬＥＭＥＮＴデータベースに追加する間に作成される。ユーザの追加は、データベース自体がいかにファブリックチャネル及びその台帳上に構築されるかと同様に、ファブリックの既存のアイデンティティ管理の上に構築される。実際には、最高レベルのアクセスであるＳｕｐｅｒＡｄｍｉｎはまさに、ファブリックの管理者役割の再使用である。図６は、４つのより低いＥＬＥＭＥＮＴアクセスレベルの１つを有するユーザを追加することに関連する。モデルは、プロセスへの大まかな関与順に３つの部分に分けられる：
１．ＥＬＥＭＥＮＴファブリック・サービス・レイヤ・ノード、
２．アイデンティティ・プロバイダ・ノード、例えば証明書プロバイダ（ＣＡ）、
３．Ｅｌｅｍｅｎｔファブリック・ピア・ノード及び順序付けサービスノード。
プロセスの初期部分は３つのうちの最初の２つを含む：ＥＬＥＭＥＮＴファブリック・サービス・レイヤは、アイデンティティプロバイダ（例えばファブリック証明機関６０６）がユーザアイデンティティを参加登録し、又は既に存在する場合、関連するアイデンティティを見つけ、ＥＬＥＭＥＮＴ特権属性をそのアイデンティティに追加するようにアレンジする。なお、複数のアイデンティティ・プロバイダ・ノードが所与のチャネル及びそのＥＬＥＭＥＮＴデータベースをサポートすることが可能であるが、それは示されていない。この場合、プロセスは、どの機関が関わるかを指定することを除き、基本的に同じである。
＜＜ユーザ＞＞オブジェクト６０４は、「身分証明書」と呼ばれることがあるアイデンティティプロバイダ（例えば証明機関６０６）におけるそのアイデンティティの表現である。カスタム属性で拡張可能であり、リレーショナルデータ管理及び編成システム１００は、ＥＬＥＭＥＮＴデータベースへのアイデンティティのアクセス特権レベルを表す属性を追加することによりこれを利用する。属性は、モデルにおいてユーザ・アクセス・レベル属性６０４と記されるＪＳＯＮオブジェクトの形態をとる。
プロセスの他の部分は、アクセスレベル変更を分散型台帳６１２にログする、対応するファブリックトランザクション６１０である。このトランザクション６１０は、サービスレイヤ（ユーザ演算ＪＳＯＮを含む＜＜ファブリックｔｘ＞＞６１４）で準備され、６１６において、まず、台帳６１２に添付されるブロックの一部として、１つのピアノードに渡し、次に、順序付けサービスに渡し、そして最後に全てのピアノードに渡すプロセスで＜＜台帳＞＞６１２に追加される。
台帳６１２は、図３～図５に図示されたものと同じである。モデルは、ユーザ追加演算ＪＳＯＮ６１４を含む新しい＜＜ファブリックブロック＞＞にフォーカスするが、そのブロック６１４は実際には、図３のジェネシスブロック及び構成ブロック（このモデルで除外される）並びに図４及び図５に図示される関連演算の任意の数のブロック後に添付される。
ユーザ・アクセス・レベルが定義された後、分散型台帳固有コンポーネントは、各リレーショナルデータベース演算中、ユーザ・アクセス・レベルを読み出して、演算が承認されているか否かを判断する。リレーショナルデータベース演算は２つのステップで行われる。アイデンティティがアイデンティティプロバイダにより確認され、アクセスレベルがチェックされる。呼び出したユーザのアクセスレベルがその関数の呼び出しに適切であることが分かった場合のみ、対応する関数へのアクセスが認められ、それに続き、実際の関数が、図３に関して上述したように実行される。
必要とされるユーザ・スマート・コントラクトとの統合の達成は、ファブリック実現では簡単である。ユーザチェーンコードは、ＥＬＥＭＥＮＴシステムチェーンコードを直接呼び出すことが可能であり、バルク演算を除く全てのＤＭＬ特徴へのアクセスを与える。
しかしながら、デフォルト・ファブリック・セットアップは常にシステム・チェーンコード・プラグインであるわけではない。プライマリ変更は、ＥＬＥＭＥＮＴシステムチェーンコードをデプロイできるようにするビルドタグを用いてファブリックピアを再構築することを含む。この後、ピアのベース構成ファイルは、コンパイルされたＥＬＥＭＥＮＴシステム・チェーンコード・バイナリへのパスの変更を必要とする。これにより、ファブリックピアは、再開時にＥＬＥＭＥＮＴシステムチェーンコードを読み出し開始することができる。
ファブリック固有サービスレイヤは、共通コンソール／パーサ／ＡＰＩコンポーネントからのデータベースコマンドを受け入れ、上述したようにＥＬＥＭＥＮＴシステムチェーンコード、ファブリック証明機関等のアイデンティティプロバイダ、及びワールド・ステート・データベースの組合せを呼び出すことにより、それらをアクションに変換する。
ＥＬＥＭＥＮＴ Ｎｏｄｅ．ｊｓ（登録商標）ＳＤＫは主に、共通コンソール／パーサ／ＡＰＩコンポーネントを開発者のＮｏｄｅ．ｊｓ（登録商標）アプリケーションから呼び出すラッパー関数を含む。特に、ＥＬＥＭＥＮＴ Ｎｏｄｅ．ｊｓ（登録商標）ＳＤＫは、リレーショナルデータ管理及び編成システム１００との接続を作成し、ＤＤＬ演算を実行してテーブル及びインデックスを定義し、ＤＭＬ演算を実行してデータを書き込みクエリし、カスタム・スマート・コントラクトをチャネルに追加するラッパー関数を提供する。
図７は、ユーザのアプリケーション７０２とのＥＬＥＭＥＮＴファブリックＮｏｄｅ．ｊｓ（登録商標）ＳＤＫの対話と、ユーザ・アプリケーション・ノード７００としてモデリングされる、それらが両方ともホストされる実行環境とを図示するブロック図である。このノード７００は、示されるように、Ｎｏｄｅ．ｊｓ（登録商標）に必要とされるサポートによる制約される広範囲の潜在的な実装及び残りのＥＬＥＭＥＮＴ ＡＰＩ１０４を介してＥＬＥＭＥＮＴコンソール１０８の実行中のインスタンスとのＨＴＴＰＳを経由して通信するように構成される能力をカバーする。
図７のユーザ・アプリケーション・ノード７００を掘り下げると、Ｎｏｄｅ．ｊｓ（登録商標）におけるユーザアプリケーション７０２は、これもまたインストールされるファブリック／Ｎｏｄｅ．ｊｓ（登録商標）ＥＬＥＭＥＮＴ ＳＤＫ７０４に依存するコンポーネントとしてモデリングされる。Ｎｏｄｅ．ｊｓ（登録商標）ラッパー関数インターフェース７０６は、ユーザのアプリケーションコード７０２に直接提供される関数を定義する。これらのインターフェース７０６は、ｔ、図１に関して説明された言語固有ＳＤＫ＜＜仕様＞＞１０２に準拠する。しかしながら、追加のファブリック固有特徴をサポートする少数の方法で仕様を超える。これは、ＳＤＫの名前に「ファブリック」が含まれることによりモデリングに反映される。ＥＬＥＭＥＮＴ＿ＳＤＫ７０４におけるコードはそのインターフェースを実装し、ＳＤＫ関数呼び出しをＥＬＥＭＥＮＴ ＡＰＩ１０４への呼び出しに翻訳する。
ＥＬＥＭＥＮＴ仕様により必要とされる関数を超えて、ファブリック／Ｎｏｄｅ．ｊｓ（登録商標）実現は、ＥＬＥＭＥＮＴＤＢコンソール１０８又は言語固有ＳＤＫ１０２を介してスマートコントラクト（ユーザチェーンコード）をデプロイし、作成されたデータベース間の物理的分離（物理的意味ｖｓ論理的意味で）を維持する能力も含む。
ファブリック／Ｎｏｄｅ．ｊｓ（登録商標）実施形態が、データベース間に物理的な分離を有した状態で、分散型台帳上にリレーショナルデータを提供するとともに、ファブリックプラットフォームの内蔵プロパティの再使用を最大にするファブリックへのリレーショナルデータ実装を提供し、したがって、性能を改善し、プラットフォーム変更が互換性を破る変更を導入する危険性を低減することが理解されよう。プログラマフレンドリＳＤＫはまた、分散型台帳上のリレーショナルデータの構造化を、そのデータを使用するスマートコントラクトのデプロイと統合する。
全てのＡＮＳＩ ＳＱＬ言語仕様がサポートされるわけではなく、それ自体がストアドプロシージャでもないことが当業者には理解されよう。しかしながら、ユーザチェーンコードは、所望であれば）、論理及びリレーショナルデータを結合する同様の能力を提供する。例として、図８及び図９は、ＳＱＬ ＤＭＬ書き込み及び読み出し演算を実装するためのリレーショナルデータ管理及び編成システム１００の使用を図示する。本明細書に記載された技法が、本明細書に記載される分散型台帳で実装されるデータベースに格納されたデータと対話する他のＳＱＬアクティビティを実装するのに使用することも可能なことを当業者は理解しよう。
図８は、サンプル実施形態におけるリレーショナルデータ管理及び編成システムを使用した分散型台帳へのＳＱＬ ＤＭＬ書き込み演算の成功の一例の論理流れ図である。図示のように、ＳＱＬクエリは、少なくとも３つの方法でリレーショナルデータ管理及び編成システム１００により受け取られる：８００において、ユーザがＳＱＬクエリをＥＬＥＭＥＮＴ ＵＩ１０６に入力する；８０２において、ユーザアプリケーションがＥＬＥＭＥＮＴ ＳＤＫ２００を介してＳＱＬクエリを渡す；又は８０４において、スマートコントラクトがＳＱＬクエリを実行する。８０６において、受け取られたＳＱＬクエリはＤＭＬ書き込み演算にパーズされる。リレーショナルデータ管理及び編成システム１００は次に、８０８において、ＳＱＬ演算のＪＳＯＮ表現を作成し、任意の包含されるリレーショナルデータのＪＳＯＮ表現を組み込む。次に、ＪＳＯＮ表現（ＥＬＥＭＥＮＴ ＳＱＬ）は、分散型台帳のアイデンティティ、プライバシー、及びコンセンサスプロビジョンを保存するファブリック／Ｎｏｄｅ．ｊｓ（登録商標）演算により処理される。そのような演算は、８１０において、呼び出し側アイデンティティが少なくともＤＭＬ書き込み承認を有することを確認することを含む。リレーショナルデータ管理及び編成システム１００は次に、８１２において、リレーショナル演算を実行するのに必要なデータを分散型台帳プラットフォームから検索し、８１４において、演算を実行し、その結果生成される新しいレコード又は変更されたレコードのＪＳＯＮ表現を準備する。８１６において、演算及び更新されたレコードは、任意の変更のレコードを保存するために、分散型台帳プラットフォームに適切な形態で分散型台帳プラットフォームにコミットされる。次に、８１８において、分散型台帳プラットフォームは、演算及びデータを分散型台帳に組み込む。また、要求される場合、リレーショナルデータ管理及び編成システム１００は、８２０において、分散型台帳による受け入れへの演算の進行について分散型台帳ネットワークをモニタする。最後に、リレーショナルデータ管理及び編成システム１００は、８２２において、呼び出し側（ＵＩ１０６、ユーザアプリケーション２００、又はユーザ・スマート・コントラクト）に演算の成功を通知する。このプロセスは、新しい各ＳＱＬ ＤＭＬ書き込み演算に対して繰り返すことができる。
他方、図９は、サンプル実施形態におけるリレーショナルデータ管理及び編成システム１００を使用した分散型台帳へのＳＱＬ ＤＭＬ読み出し演算の成功の一例の論理流れ図である。図示のように、ＳＱＬクエリは、少なくとも３つの方法でリレーショナルデータ管理及び編成システム１００により受け取られる：９００において、ユーザがＳＱＬクエリをＥＬＥＭＥＮＴ ＵＩ１０６に入力する；９０２において、ユーザアプリケーションがＥＬＥＭＥＮＴ ＳＤＫ２００を介してＳＱＬクエリを渡す；又は９０４において、スマートコントラクトがＳＱＬクエリを実行する。９０６において、受け取られたＳＱＬクエリはＤＭＬ読み出し演算にパーズされる。リレーショナルデータ管理及び編成システム１００は次に、９０８において、ＳＱＬ演算のＪＳＯＮ表現を作成する。次に、ＪＳＯＮ表現（ＥＬＥＭＥＮＴ ＳＱＬ）は、分散型台帳のアイデンティティ、プライバシー、及びコンセンサスプロビジョンを保存するファブリック／Ｎｏｄｅ．ｊｓ（登録商標）演算により処理される。そのような演算は、９１０において、呼び出し側アイデンティティが少なくともＤＭＬ読み出し承認を有することを確認することを含む。リレーショナルデータ管理及び編成システム１００は次に、９１２において、読み出し演算を実行するのに必要なデータを分散型台帳プラットフォームから検索し、９１４において、要求された演算を実行し、クエリ結果のＪＳＯＮ表現を作成する。意図的に抑圧されない限り、９１６において、リレーショナルデータ管理及び編成システム１００は、レコードを保存するために、分散型台帳プラットフォームに適切な形態で演算のＪＳＯＮ表現を分散型台帳プラットフォームにログする。次に、９１８において、分散型台帳プラットフォームは、演算のログを分散型台帳に組み込む。最後に、９２０において、リレーショナルデータ管理及び編成システム１００は、クエリ結果のＪＳＯＮ表現を呼び出し側（ＵＩ１０６、ユーザアプリケーション２００、又はユーザ・スマート・コントラクト）に返す。このプロセスは、新しい各ＳＱＬ ＤＭＬ読み出し演算に繰り返すことができる。
図１０は、ファブリック実現におけるデータ定義言語（ＤＤＬ）書き込みの実行成功を図示するブロック図である。そのような演算は、既存のリレーショナルデータ管理及び編成システムデータベースのスキーマを変更又は拡張する。図の左部のスイムレーンは、ＤＤＬ演算を担当するコンポーネントを表す。各レーン内のアクティビティは、記されたコンポーネントに固有であり、プロセスへのコンポーネントの可能な寄与を記述する。前の図のように、プロセスの流れは、因果的に接続されたステップ間の太字の矢印で示される。さらに、通常の矢印は、アクティビティを、右側のオブジェクトモデル（データにより示される）で示される、アクティビティが作成又は変更するデータオブジェクトに結び付ける。
ＤＭＬ書き込み演算は、ＥＬＥＭＥＮＴＤＢコンソール１０８により識別され対処される。例えば、１０００において、ＥＬＥＭＥＮＴＤＢコンソール１０８は、ＳＱＬコマンドを受け取り、それをＤＤＬとして識別する。ＳＱＬコマンドの対処は、１００２において、Ｅｌｅｍｅｎｔ ＳＱＬ ＤＤＬパーサ１１０によりパーズして、演算のＳＱＬ記述を、分散型台帳プラットフォームで処理し表すことができる形態に変換することを含む。１００４において、変換された形態は、ファブリック・サービス・コンポーネントにより更に処理されて、デプロイされるファブリック・サービス・レイヤ内のデータとして存在することができるデータベース属性（スキーマ）の更新されたＪＳＯＮ表現１００５を含む所望の演算を含むファブリックトランザクションになる。１００６において、ファブリック・サービス・コンポーネントはまた、ネットワーク接続を介して、生成されたファブリックトランザクションをリレーショナルデータ管理及び編成システムデータベースに関連付けられたチャネルにおけるファブリック・ピア・ノードに提出させもする。次に、ファブリックネットワークによる通常処理が、そのトランザクションをブロックに組み込み、そのブロックをそのチャネルの台帳１０２０における前のもの１００７に添付する。そのような添付において、ブロックがチャネルにおける他のピアノードにも同一に添付されることが暗示される。変更されたリレーショナルデータ属性は、キー値対（ｐｉｅｃｅ ｋｅｙ－ｖａｌｕｅ－ｐａｉｒ）分散型台帳データとして表されるため、１００８において、ファブリック・システム・チェーンコードは続けて、ワールド・ステート・データベースを更新し、ここではより最近のリレーショナルデータベース属性で、同じキー下に格納されていたであろう前の属性を上書きする。ＤＤＬ演算により示されるインデックス変更がある場合、１０１０において、リレーショナル管理及び編成システムは実際に、ワールド・ステート・データベースの索引付け、例えば、ＣｏｕｃｈＤＢ（登録商標）インスタンスのインデックスコレクション１０３０の直接変更によりインデックスに影響を及ぼすことができる。インデックスコレクション１０３０は、演算が実行中であるリレーショナルデータ管理及び編成システムデータベースに定義されたインデックスを含む。１０１２において、これらの変更は、ファブリックサービスにより要求され、ワールド・ステート・データベースの索引付け実装により受け取られ、続けて＜＜ワールドステート＞＞データベースに適用され、更新された索引付けを、ワールド・ステート・データベースを含む続くクエリ演算に適用させる。
コンピュータ実施形態
図１１は、本明細書に開示されるリレーショナルデータ管理及び編成システム１００の１若しくはそれ以上の実施形態の実装に適した専用コンピュータにプログラムすることができる典型的な汎用コンピュータ１１００のブロック図である。上述したリレーショナルデータ管理及び編成システム１００は、課される必要な作業負荷に対処するのに十分な処理能力、メモリリソース、及び通信スループット能力を有するコンピュータ等の任意の汎用処理コンポーネントに実装することができる。コンピュータ１１００は、セカンダリストレージ１１０４、読み取り専用メモリ（ＲＯＭ）１１０６、ランダム・アクセス・メモリ（ＲＡＭ）１１０８を含むメモリと通信するプロセッサ１１０２（中央演算処理装置又はＣＰＵと呼ばれることもある）、入出力（Ｉ／Ｏ）デバイス１１１０、及びネットワーク接続デバイス１１１２を含む。プロセッサ１１０２は、１若しくはそれ以上のＣＰＵチップとして実装されてもよく、又は１若しくはそれ以上の特定用途向け集積回路（ＡＳＩＣ）の一部であってもよい。
セカンダリストレージ１１０４は通常、１若しくはそれ以上のディスクドライブ又はテープドライブで構成され、データの不揮発性記憶及びＲＡＭ１１０８が全ての作業データを保持するのに十分な大きさを有さない場合、オーバーフローデータ記憶装置として使用される。セカンダリストレージ１１０４は、実行に選択された場合、ＲＡＭ１１０８にロードされるプログラムの記憶に使用することもできる。ＲＯＭ１１０６は、命令及び恐らくプログラム実行中に読み出されるデータを記憶するのに使用される。ＲＯＭ１１０６は、通常、セカンダリストレージ１１０４のより大きなメモリ容量と比較して小さなメモリ容量を有する不揮発性メモリデバイスである。ＲＡＭ１１０８は、揮発性データの記憶及び恐らくは命令の記憶に使用される。ＲＯＭ１１０６及びＲＡＭ１１０８への両方のアクセスは通常、セカンダリストレージ１１０４へのアクセスよりも高速である。
本明細書に記載されるデバイスは、コンピュータ可読命令を記憶するコンピュータ可読非一時的媒体と、メモリに結合され、コンピュータ可読命令を実行すると、図１～図１０を参照して上述した方法ステップ及び演算を実行するようにコンピュータ１１００を構成する１若しくはそれ以上のプロセッサとを含むように構成される。コンピュータ可読非一時的媒体は、磁気記憶媒体、光学記憶媒体、フラッシュメディア、及び固体状態記憶媒体を含め、全てのタイプのコンピュータ可読媒体を含む。
本開示のステップの何れか１つ又は全てを参照して上述した処理及び演算を促進する１若しくはそれ以上のコンピュータ実行可能命令を含むソフトウェアが、本開示と一貫して、１若しくはそれ以上のサーバ、及び／又は１若しくはそれ以上のルータ、及び／又は消費者及び／又は生産者ドメイン内の１若しくはそれ以上のデバイスにインストールすることができ、それ（ら）と共に販売することができることを更に理解されたい。代替的には、本開示と一貫して、ソフトウェアは、例えば、ソフトウェア作成者により所有されるサーバから又はソフトウェア作成者により所有されないが使用されるサーバからを含めて物理媒体又は配信システムを通してソフトウェアを取得することを含め、取得され、１若しくはそれ以上のサーバ、及び／又は１若しくはそれ以上のルータ、及び／又は消費者及び／又は生産者ドメイン内の１若しくはそれ以上のデバイスにロードすることができる。ソフトウェアは、例えば、インターネットを経由した配信に向けてサーバに記憶されることもある。
また、本開示の適用用途が、説明が記載され、又は図面に図示されるコンポーネントの構築及び配置の詳細に限定されないことが当業者により理解されよう。本明細書における実施形態は、他の実施形態が可能であり、種々の方法で実施又は実行することが可能である。また、本明細書で使用される表現及び用語が説明を目的としており、限定として見なされるべきではないことが理解されよう。本明細書における「含む（ｉｎｃｌｕｄｉｎｇ）」、「含む（ｃｏｍｐｒｉｓｉｎｇ）」、又は「有する」、及びそれらの変形の使用は、後に列記される項目及びそれらの均等物並びに追加の項目の包含を意味する。限定される場合を除き、本明細書における「接続される」、「結合される」、及び「搭載される」という用語並びのそれらの変形は、広義で使用され、直接及び間接的な接続、結合、及び搭載を包含する。加えて、「接続される」及び「結合される」という用語並びにそれらの変形は、物理的又は機械的な接続又は結合に制限されない。さらに、上、下、ボトム、及びトップ等の用語は相対的であり、例示を目的として利用されており、限定ではない。
図示の実施形態により利用される例示的なデバイス、システム、及び方法のコンポーネントは、少なくとも部分的にデジタル電子回路、アナログ電子回路、又はコンピュータハードウェア、ファームウェア、ソフトウェア、又はそれらの組合せで実装することができる。これらのコンポーネントは、例えば、コンピュータプログラム、プログラムコード、又は情報キャリア若しくは機械可読記憶装置で有形に実施されるコンピュータ命令等のコンピュータプログラム製品として実装することができ、プログラマブルプロセッサ、コンピュータ、又は複数のコンピュータ等のデータ処理装置により実行され、又はデータ処理装置の動作を制御する。
コンピュータプログラムは、コンパイル型又はインタープリタ型言語を含め、任意の形態のプログラミング言語で書くことができ、スタンドアロンプログラム又はモジュール、コンポーネント、サブルーチン、若しくは計算環境での使用に適した他のユニットを含め、任意の形態でデプロイすることができる。コンピュータプログラムは、１台のコンピュータで、一箇所にある複数のコンピュータで、又は複数の場所にわたり分散し、通信ネットワークにより相互接続された複数のコンピュータで実行されるようにデプロイされる。また、本明細書に記載される技法を達成する機能プログラム、コード、及びコードセグメントは、当技術分野の当業者であるプログラマにより本開示の範囲内として容易に解釈される。例示的な実施形態に関連付けられた方法ステップは、コンピュータプログラム、コード、又は命令を実行して、機能を実行する（例えば、入力データに対して動作し、及び／又は出力を生成することにより）１若しくはそれ以上のプログラマブルプロセッサにより実行することができる。方法ステップはまた、専用論理回路、例えば、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ：フィールド・プログラマブル・ゲート・アレイ）又はＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ－ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ：特定用途向け集積回路）により実行されてもよく、装置は専用論理回路として実装されてもよい。
本明細書に開示される実施形態に関連して説明された種々の例示的な論理ブロック、モジュール、及び回路は、汎用プロセッサ、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ：ＤＳＰ）、ＡＳＩＣ、ＦＰＧＡ、又は他のプログラマブル論理デバイス、離散ゲート若しくはトランジスタ論理、離散ハードウェアコンポーネント、又は本明細書に記載された機能を実行するように設計されたそれらの任意の組合せを用いて実装又は実行することができる。汎用プロセッサはマイクロプロセッサであってもよく、代替では、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、又は状態機械であってもよい。プロセッサはまた、計算デバイスの組合せとして、例えば、ＤＳＰとマイクロプロセッサとの組合せ、複数のマイクロプロセッサの組合せ、ＤＳＰコアと併せた１若しくはそれ以上のマイクロプロセッサの組合せ、又は任意の他のそのような構成で実装されてもよい。
コンピュータプログラムの実行に適したプロセッサには、例として、汎用及び専用マイクロプロセッサの両方並びに任意の種類のデジタルコンピュータの任意の１若しくはそれ以上のプロセッサがある。一般に、プロセッサは、読み取り専用メモリ、ランダム・アクセス・メモリ、又は両方から命令及びデータを受け取る。コンピュータの基本要素は、命令を実行するプロセッサと、命令及びデータを記憶する１若しくはそれ以上のメモリデバイスとである。一般に、コンピュータはまた、データを記憶する１若しくはそれ以上の大容量記憶装置、例えば、磁気ディスク、磁気光学ディスク、又は光ディスクも含み、又はそれ（ら）と動作可能に結合されて、データを受け取り又はデータを転送もする。コンピュータプログラム命令及びデータの実施に適した情報キャリアには、例として、半導体メモリデバイス、例えば、電子的プログラマブル読み取り専用メモリ若しくはＲＯＭ（ＥＰＲＯＭ）、電子的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリデバイス、及びデータ記憶ディスク（例えば、磁気ディスク、内部ハードディスク、又はリムーバブルディスク、磁気光学ディスク、及びＣＤ－ＲＯＭ及びＤＶＤーＲＯＭディスク）を含め、全ての形態の不揮発性メモリがある。プロセッサ及びメモリは、専用論理回路により補足し、又は専用論理回路に組み込むことができる。
情報及び信号を多種多様な異なる技術及び技法の何れかを使用して表すことができることを当業者は理解する。例えば、上記説明全体を通して言及したデータ、命令、コマンド、情報、信号、ビット、記号、及びチップは、電圧、電流、電磁波、磁場若しくは磁粒子、光場若しくは光粒子、又はそれらの任意の組合せにより表すことができる。
本明細書に開示される実施形態に関連して説明された種々の例示的な論理ブロック、モジュール、回路、及びアルゴリズムステップが、電子ハードウェア、コンピュータソフトウェア、又は両方の組合せとして実装することができることを当業者は更に理解する。ハードウェア及びソフトウェアのこの相互交換性を明確に示すために、種々の例示的なコンポーネント、ブロック、モジュール、回路、及びステップは一般に、機能に関して上述されてきた。そのような機能がハードウェアとして又はソフトウェアとして実装されるかは、特定の用途及びシステム全体に課される設計制約に依存する。当業者は、記載された機能を特定の各用途に向けて様々な方法で実装することができるが、そのような実装判断は、本開示の範囲からの逸脱を生じさせるものとして解釈されるべきではない。ソフトウェアモジュールは、ランダム・アクセス・メモリ（ＲＡＭ）、フラッシュメモリ、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ－ＲＯＭ、又は当技術分野で既知の任意の他の形態の記憶媒体に常駐することができる。例示的な記憶媒体は、プロセッサに結合され、そのようなプロセッサは、記憶媒体から情報を読み取り、及び記憶媒体に情報を書き込むことができる。代替では、記憶媒体はプロセッサに統合することができる。換言すれば、プロセッサ及び記憶媒体は、集積回路に常駐してもよく、又は離散コンポーネントとして実装されてもよい。
本明細書で使用される場合、「機械可読媒体」は、命令及びデータを一時的又は永続的に記憶することが可能なデバイスを意味し、これに限定されるものではないが、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、バッファメモリ、フラッシュメモリ、光学媒体、磁気媒体、キャッシュメモリ、他のタイプのストレージ（例えば、消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ））、及び／又はそれらの任意の適した組合せを含む。「機械可読媒体」という用語は、１つの媒体又は複数の媒体（例えば、プロセッサ命令を記憶することが可能な中央若しくは分散データベース又は関連付けられたキャッシュ及びサーバ）を含むものと解釈されるべきである。「機械可読媒体」という用語はまた、命令が、１若しくはそれ以上のプロセッサにより実行されると、１若しくはそれ以上のプロセッサに本明細書に記載される方法論の任意の１若しくはそれ以上を実行させるように、１若しくはそれ以上のプロセッサによる実行に向けて命令を記憶することが可能な任意の媒体又は複数の媒体の組合せを含むものとしても解釈されるものとする。したがって、「機械可読媒体」は、１つの記憶装置又はデバイス及び複数の記憶装置又はデバイスを含む「クラウドベース」の記憶システム又は記憶ネットワークを指す。「機械可読媒体」という用語は、本明細書では信号それ自体を除外する。
上記例示した説明及び図は、単なる例として意図され、添付の特許請求の範囲への記載を除き、例示的な実施形態の限定を決して意図しない。なお、上述した種々の例示的な実施形態の種々の要素の種々の技術的態様は、多くの他の方法で組み合わせることが可能であり、その全ては本開示の範囲内であると見なされる。
したがって、例示的な実施形態が例示を目的として開示されたが、種々の変更、追加、及び置換が可能なことを当業者は理解しよう。したがって、本開示は上記実施形態に限定されず、添付の特許請求の範囲及びそれらの全範囲の均等物内で変更が可能である。
付録Ａ
ＨＹＰＥＲＬＥＤＧＥＲ（登録商標）ファブリック概説
Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックモデル
包括的でありながらカスタマイズ可能な企業分散型台帳解決策の約束を満たす、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックに織り込まれた主要な設計特徴は以下を含む：
・アセット－アセット定義は、自然食品からアンティークカー、通貨先物まで略あらゆるものを、ネットワークを経由して金銭価値と交換できるようにする。
・チェーンコード－チェーンコード実行は、トランザクション順序付けから分割され、ノードタイプにわたり必要とされる信頼レベル及び確認を制限し、ネットワークのスケーラビリティ及び性能を最適化する。
・台帳特徴－不変の共有台帳は、各チャネルのトランザクション履歴全体を符号化し、効率的な監査及び紛争解決のためのＳＱＬのようなクエリ機能を含む。
・プライバシー－チャネル及びプライベートデータ収集は、通常、競合するビジネス及びアセットを共通ネットワーク上で交換する規制産業により求められるプライベート及び機密マルチラテラルトランザクションを可能にする。
・セキュリティ&メンバーシップサービス－許可されたメンバーシップは、承認された規制者及び監査人により全てのトランザクションを検出しトレースすることができることを参加者が知る高信頼性分散型台帳ネットワークを提供する。
・コンセンサス－コンセンサスへの独自の手法は、企業に必要とされる柔軟性及びスケーラビリティを可能にする。
アセット
アセットは、有形（不動産及びハードウェア）から無形（契約及び知的財産）まで及ぶことができる。Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックは、チェーンコードトランザクションを使用してアセットを変更する能力を提供する。
アセットは、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックでは、キー値対の集まりとして表され、状態変化は、チャネル台帳上のトランザクションとして記録される。アセットはバイナリ及び／又はＪＳＯＮ形態で表すことができる。
アセットは、Ｈｙｐｅｒｌｅｄｇｅｒコンポーザツールを使用してＨｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックアプリケーションにおいて定義され使用することができる。
チェーンコード
チェーンコードは、スマートコントラクトにおいて、１若しくはそれ以上のアセット及びアセットを変更するトランザクション命令を定義するソフトウェアであり、換言すれば、ビジネス論理である。チェーンコードは、キー値対又は他の状態データベース情報の読み出し又は変更についてのルールを施行する。チェーンコード関数は、台帳の現在状態データベースと突き合わせて実行され、トランザクション提案を通して開始される。チェーンコードが実行されると、１組のキー値書き込み（書き込みセット）が生成され、これはネットワークに提出され、全てのピアにおける台帳に適用することができる。
チェーンコードはアイデンティティから完全に自由である。チェーンコードはまた、別のチェーンコードを呼び出すこともできるが、トランザクションアイデンティティは、呼び出しチェイン全体を通してトランザクションを提出したトランザクション署名者として常に一定に保たれる。したがって、ファブリックネットワークでは、エスクローアカウントのセットアップは外部当事者の追加を含む。その結果として、エスクローを担当する外部アカウントは、中立性を残りの参加者に提供しなければならない。
チェーンコードのデプロイは２ステッププロセスである。チェーンコードの実行可能バイナリは実際には台帳に生き続けないため、まず、サポートを選択したあらゆる是認ピアにインストールされなければならない。次に、チャネル全体が、「チェーンコードインスタンス化」と呼ばれるステップにより、実行するチェーンコードの正確なバージョン及びトランザクションの是認ポリシーに同意しなければならない。インスタンス化トランザクションを提出しているユーザは、コンソーシアムが確立されたときに予め決定されたルールに従って、それを行うことが承認されていることを保証するために、「インスタンス化ポリシー」と突き合わせた妥当性確認に合格しなければならない。
チェーンコードはアップグレード可能である。チェーンコードには名前及びバージョンが割り当てられる。アップグレード時、新しいバージョンが割り当てられ、全ての既存の状態は自動的に継承される。
台帳特徴
台帳は、ファブリックにおける全ての状態遷移の順序付き耐改竄性レコードである。状態遷移は、参加当事者により提出されたチェーンコード呼び出し（「トランザクション）の結果である。各トランザクションは１組のアセットキー値対を生成し、これは、作成、更新、又は削除として台帳にコミットされる。
台帳は、不変性の順序付きレコードをブロックに格納するブロックチェーン（「チェイン」）及び現在のファブリック状態を維持する状態データベースで構成される。チャネル毎に１つの台帳がある。各ピアは、ピアがメンバである各チャネルの台帳のコピーを維持する。
ファブリック台帳の幾つかの特徴は以下である：
・キーベースの参照、範囲クエリ、及び合成キークエリを使用したクエリ及び更新台帳、
・リッチクエリ言語を使用した読み取り専用クエリ（ＣｏｕｃｈＤＢ（登録商標）を状態データベースとして使用する場合）、
・読み取り専用履歴クエリ－キーのクエリ台帳履歴であり、データ出所シナリオを可能にする、
・トランザクションは、チェーンコードにおいて読み出されたキー／値のバージョン（読み出しセット）及びチェーンコードに書き込まれたキー／値（書き込みセット）から成り、
・トランザクションは、あらゆる是認ピアの署名を含み、順序付けサービスに提出され、
・トランザクションはブロックに並べられ、順序付けサービスからチャネル上のピアに「送られ」、
・ピアは、是認ポリシーと突き合わせてトランザクションを妥当性確認し、ポリシーを施行し、
・ブロックの添付に先立って、バージョンチェックが実行されて、チェーンコード実行時から、読み出されたアセットの状態が変わっていないことを保証し、
・トランザクションが妥当性確認されコミットされると、不変性があり、
・チャネルの台帳は、構成ブロック定義ポリシー、アクセス制御リスト、及び他の関連情報を含み、
・チャネルはメンバーシップ・サービス・プロバイダインスタンスを含み、暗号資料（ｃｒｙｐｔｏ ｍａｔｅｒｉａｌ）を異なる証明機関から送れるようにする。
データベース、ストレージ構造、及び「クエリ能力」についてのより深い洞察については台帳トピック参照のこと。
プライバシー
Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックは、チャネル毎の不変台帳と、アセットの現在状態を操作、変更（すなわち、キー値対を更新）することができるチェーンコードとを利用する。台帳はチャネルの範囲に存在し－ネットワーク全体にわたり共有することができる（あらゆる参加者が１つの共通チャネルで動作していると仮定して）－又は特定の組の参加者のみを含むようにプライベート化することができる。
後者のシナリオでは、これらの参加者は別個のチャネルを作成し、それにより、トランザクション及び台帳を分離／隔離する。完全透明性とプライバシーとの間のギャップを橋渡ししたいシナリオを解決するために、チェーンコードは、読み出し及び書き込みを実行するためにアセット状態にアクセスする必要があるピアのみにインストールすることができる（換言すれば、チェーンコードがピアにインストールされない場合、台帳と適宜インターフェースすることはできない）。
そのチャネル上の組織のサブセットが、トランザクションデータを機密に保つ必要がある場合、プライベート・データ・コレクション（コレクション）が使用されて、プライベートデータベースにこのデータを隔離し、チャネル台帳から論理的に分け、組織の承認されたサブセットのみがアクセス可能である。
したがって、チャネルは、より広いネットワークからトランザクションをプライベートに保ち、一方、コレクションは、チャネル上の組織のサブセット間でデータをプライベートに保つ。
データを更に難読化するために、チェーンコード内の値は、トランザクションを順序付けサービスに送り、ブロックを台帳に添付する前、ＡＥＳ等の一般的な暗号化アルゴリズムを使用して暗号化することができる（部分的に又は全体的に）。暗号化されたデータが台帳に書き込まれると、暗号文の生成に使用された対応するキーを保有するユーザしか復号化することができない。チェーンコード暗号化についての更なる詳細については、開発者用チェーンコードトピックを参照のこと。
ファブリックでは、プライベート状態は、ピアの実行による是認フェーズ中、プライベートトランザクション、計算され、生成されたプライベート状態は、入力とともにハッシュで表される。その結果、コンセンサス後の全てのノードでの一貫したハッシュは、プライベートトランザクションの参加ノードが常に、プライベート状態に一致することを保証する。
ファブリックはまた、「チャネル」の概念を用いて別のプライバシー技法として完全なデータ分離も提供する。ファブリックチャネルは、各チャネルが、そのチャネルの参加ノードにより共有される、台帳の完全に別個のインスタンスを維持するため、別個のブロックチェーンと考えることができる。大半の金融機関での場合のように、コンソーシアムが主にバイラテラルトランザクションを考慮する場合、チャネル数はかなり大きくなる：Ｏ（Ｎ∧２）、Ｎはコンソーシアムへの参加者数である。
ブロックチェーンネットワークでプライバシーをいかに達成するかについてのより詳細については、プライベート・データトピックを参照のこと。
セキュリティ&メンバーシップサービス
Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックは、全ての参加者がアイデンティティを知っているトランザクションネットワークを支える。公開鍵基盤を使用して、組織、ネットワークコンポーネント、及びエンドユーザ又はクライアントアプリケーションに結ばれた暗号証明書を生成する。その結果、データアクセス制御をより広いネットワーク及びチャネルレベルで維持し、支配することができる。チャネルの存在及び機能と併せたＨｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックの「許可された」という表記は、プライバシー及び機密性が最高の考慮事項であるシナリオへの対処に役立つ。
暗号実装並びにＨｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックで使用される符号、確認、認証手法をよりよく理解するには、メンバーシップ・サービス・プロバイダ（Ｍｅｍｂｅｒｓｈｉｐ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒｓ：ＭＰＳ）トピックを参照のこと。
コンセンサス
分散型台帳技術では、コンセンサスは近年、１つの関数内の特定のアルゴリズムと同義になっている。しかしながら、コンセンサスは、トランザクションの順序への単なる合意よりも多くを包含し、この区別は、提案及び是認から順序付け、妥当性確認、及びコミットメントまでの全体トランザクションフローにおけるその基本的な役割を通してＨｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックにおいて強調されている。極めて簡潔に言えば、コンセンサスは、ブロックを含む１組のトランザクションの正確性の全周（ｆｕｌｌ－ｃｉｒｃｌｅ）確認として定義される。
ファブリックは、コンセンサスモデルにおいて非決定性をなくす代わりに非決定性に耐える。ファブリックは、設計原理としてスマートコントラクトに上位水準言語を提供する。ファブリックチェーンコードは、３つの上位水準言語ランタイムで書くことができる：Ｇｏ言語、Ｎｏｄｅ．ｊｓ（登録商標）、及びＪａｖａ（登録商標）。これは、実行－順序付け－妥当性確認コンセンサス設計を利用することにより可能になり、したがって、ブロックチェーンシステムは、非決定性チェーンコードにより生じる不良トランザクションに耐えることができ、その間、開発者は論理及び実装を完全なものにし続ける。
１２に図示される「最初に実行し、次に順序付ける」設計は、何らかの種類の同時バージョン制御が必要であり、同時バージョン制御がない場合、複数のトランザクションが同じ状態値を並列して変更しようとしているとき、後のトランザクションが先のトランザクションを上書きし、先のトランザクションの結果の上に構築する代わりに、先のトランザクションからの状態遷移を拭い去ることを暗示する。ファブリックは、データベース設計から借りたマルチバージョン同時制御（ｍｕｌｔｉｖｅｒｓｉｏｎ ｃｏｎｃｕｒｒｅｎｃｙ ｃｏｎｔｒｏｌ：ＭＶＣＣ）技法を利用する。チェーンコードエンジンは、スマートコントラクトが実行されるとき、どの状態値が閲覧されているか（読み取りセットにおいて）及びその値が更新されているか（書き込みセットにおいて）を追跡する。妥当性確認フェーズ中、ブロック内部に含まれる各トランザクションが妥当性確認され、状態遷移が適用される場合、通常、ブロック中の先のトランザクションにより更新されたため、その読み出しセット内のトランザクションの状態値バージョンが現在バージョンに一致しないとき、トランザクションは無効とマークされる。
意味合いは、一連のトランザクションが同じ状態値を変更する必要がある場合、２つ以上のトランザクションが１つのブロック内部にないように調整されなければならないことである。そうしなければ、アプリケーションは、同時変更に起因して多くの無効トランザクションを見ることになる。
基礎となる同じ状態変数を標的としたキーを一緒にグループ化する能力を有しながら、各トランザクションに一意のキーを組み立てる複合キー機能を利用する等のこの制限を迂回してプログラムする技法が存在する。
コンセンサスは最終的に、ブロックのトランザクションの順序及び結果が明示的なポリシー基準チェックに合致した場合、達成される。これらのチェック及びバランスは、トランザクションのライフサイクル中に行われ、是認ポリシーを使用して、どの特定のメンバが特定のトランザクションクラスを是認しなければならないかを指定し、システムチェーンコードを使用して、これらのポリシーが施行され展開されることを保証することを含む。コミットメントに先立ち、ピアはこれらのシステムチェーンコードを利用して、十分な是認が存在すること及び是認が適切なエンティティから導出されたことを確かめる。さらに、トランザクションを含むいかなるブロックも台帳に添付される前、バージョニングチェックが行われ、その間、台帳の正確な状態は一致又は同意される。この最終チェックは、演算の二重消費及びデータ保全性を損なう恐れがある他の脅威からの保護を提供し、関数を非静的変数に対して実行できるようにする。
行われる多数の是認、有効性チェック、及びバージョニングチェックに加えて、トランザクションフローの全方向に行われている進行中のアイデンティティ妥当性確認もある。アクセス制御リストは、ネットワークの階層レイヤで実装され（順序付けサービスからチャネルまで）、トランザクション提案が異なるアーキテクチャコンポーネントを通る際、ペイロードは繰り返し署名され、確認され、認証される。結論として、コンセンサスは、単にトランザクションのバッチの順序への同意に限定されず、むしろ、提案からコミットメントまでのトランザクションの旅程中に行われる進行中の妥当性確認の副産物として達成される包括的な特徴付けである。
運営ガバナンス
ガバナンスは、コンソーシアムメンバ組織が意思決定プロセスに適切に参加していることを保証する、プロトコル実行時前後のプロセス及びポリシーである。
ファブリックは、アーキテクチャのあらゆるレイヤに内蔵された許可ガバナンスを有する。新しいコンソーシアムの開始、メンバの追加又は退去、新しいチャネルの定義、チャネルの参加者の追加及び退去のような動作は全て、適切な組織からの承認署名を収集する必要がある。包括的なポリシーモデルはシステム全体を通して施行される。
ファブリックは、２つのレベルの許可及びガバナンスサポートを有する：コンソーシアム及びチャネル。オーダラーは、ポリシー及び構成をコンソーシアムレベルで管理する。あらゆるファブリックブロックチェーンネットワークは、組織及びコンソーシアムを定義するジェネシスブロック構成からのオーダラーブートストラップで開始される。ピアは、ポリシー及び構成をチャネルレベルで管理する。新しいメンバ組織をコンソーシアム又はチャネルに追加する等の構成変更は、変更ポリシーに従って署名の収集を必要とする：既存のメンバのいずれか、全て、又は過半数。
ファブリックアーキテクチャ自体は、分散オーダラー実装を可能にする。実際に、バージョン１．４におけるＲａｆｔベースのオーダラー実装の導入に伴い、オーダラーノードを中央順序付けエンジンと対にする必要はもはやない。各オーダラーノード自体がＲａｆｔピアであり、現在の台帳がクラッシュ又は到達不可能になった場合、台帳選挙に参加することができる。これにより、２つ以上の組織がオーダラーノードを運営し、コンセンサス及び提案ブロックに参加することができるより分散したデプロイが可能になる。
ピア
ブロックチェーンネットワークは主に、１組のピアノード（又は単にピア）で構成される。ピアは、台帳及びスマートコントラクトをホストするため、ネットワークの基本要素である。台帳は、スマートコントラクト（Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックでは、チェーンコードに含まれる）により生成される全てのトランザクションを不変に記録する。スマートコントラクト及び台帳は、ネットワークにおいて共有プロセス及び共有情報をそれぞれカプセル化するのに使用される。ピアのこれらの態様は、ピアを、ファブリックネットワークを理解する良好な開始点にする。
ブロックチェーンネットワークの他の要素も当然ながら重要である：台帳及びスマートコントラクト、オーダラー、ポリシー、チャネル、アプリケーション、組織、アイデンティティ、及びメンバーシップ。このセクションは、ピア及びファブリックネットワークにおけるそれらの他の要素へのピアの関係にフォーカスする。
図１３は、それぞれが台帳のコピー及びスマートコントラクトのコピーを保持することができるピアノードで構成されるブロックチェーンネットワークを示す。この例では、ネットワークＮはピアＰ１、Ｐ２、及びＰ３から成り、各ピアは分散型台帳Ｌ１のそれ自体のインスタンスを維持する。Ｐ１、Ｐ２、及びＰ３は同じチェーンコードＳ１を使用して、その分散型台帳の各自コピーにアクセスする。
ピアは、作成、開始、停止、再構成、更には削除することができる。ピアは、管理者及びアプリケーションが、ピアが提供するサービスと対話できるようにする１組のＡＰＩを露出する。
専門用語における単語
ファブリックは、チェーンコード－サポートされるプログラミング言語の１つで書かれた、台帳にアクセスする単なるコード片－を用いてスマートコントラクトを実装する。
台帳及びチェーンコード
台帳及びチェーンコードの両方をホストするのはピアである。より正確には、ピアは実際には、台帳のインスタンス及びチェーンコードのインスタンスをホストする。なお、これは、ファブリックネットワークに意図的な冗長を提供する－これは単一障害点を回避する。
図１４は、台帳のインスタンス及びチェーンコードのインスタンスをホストするピアを図示する。この例では、Ｐ１は、台帳Ｌ１のインスタンス及びチェーンコードのＳ１のインスタンスをホストする。個々のピアにホストされる多くの台帳及びチェーンコードがあることができる。
ピアは台帳及びチェーンコードのホストであるため、アプリケーション及び管理者は、これらのリソースと対話したい場合、ピアと対話しなければならない。これは、ピアがファブリックネットワークの最も基本的な構築ブロックと見なされることの理由である。ピアが最初に作成されたとき、ピアは台帳もチェーンコードも有さない。
複数の台帳
ピアは２つ以上の台帳をホストすることが可能であり、これは、柔軟なシステム設計を可能にするため、有用である。最も単純な構成は、ピアが１つの台帳を管理することであるが、必要な場合、ピアが２つ以上の台帳をホストすることは極めて適切である。
図１５は、複数の台帳をホストするピアを図示する。ピアは１若しくはそれ以上の台帳をホストし、各台帳は、台帳に適用されるゼロ若しくはそれ以上のチェーンコードを有する。この例では、ピアＰ１が台帳Ｌ１及びＬ２をホストすることを見て取ることができる。台帳Ｌ１はチェーンコードＳ１を使用してアクセスされる。他方、台帳Ｌ２はチェーンコードＳ１及びＳ２を使用してアクセスすることができる。
ピアが、台帳にアクセスするいかなるチェーンコードもホストせずにその台帳インスタンスをホストすることは完全に可能であるが、ピアがこのように構成されることは稀である。ピアの圧倒的多数は、ピアの台帳インスタンスをクエリ又は更新することができる少なくとも１つのチェーンコードがインストールされることになる。ついでながら、ユーザが外部アプリケーションによる使用に向けてチェーンコードをインストールしているか否かに関係なく、ピアが、常に存在する特殊なシステムチェーンコードも有することを言及する価値がある。
複数のチェーンコード
ピアが有する台帳数と、その台帳にアクセスすることができるチェーンコード数との間に一定の関係はない。ピアは、多くのチェーンコードを有してもよく、多くの台帳がピアに提供されてもよい。
図１６は、複数のチェーンコードをホストするピアの一例を図示する。各台帳は、台帳にアクセスする多くのチェーンコードを有することができる。この例では、ピアＰ１が台帳Ｌ１及びＬ２をホストし、Ｌ１がチェーンコードＳ１及びＳ２によりアクセスされ、Ｌ２がＳ１及びＳ３によりアクセスされることを見て取ることができる。Ｓ１はＬ１及びＬ２の両方にアクセスすることができる。
アプリケーション及びピア
台帳－クエリ対話は、アプリケーションとピアとの間の単純な３ステップ会話を含み、台帳更新対話はわずかに関わる度合いが深く、２つの追加ステップを必要とする。
アプリケーションは、台帳及びチェーンコードにアクセスする必要がある場合、常にピアに接続する。ファブリックソフトウェア開発キット（Ｆａｂｒｉｃ Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ：ＳＤＫ）は、プログラマにとってこれを容易にする－ＡＰＩは、アプリケーションがピアに接続すること、チェーンコードを呼び出してトランザクションを生成すること、トランザクションをネットワークに提出することであって、トランザクションは順序付けられて分散型台帳にコミットされる、提出すること、及びこのプロセスが完了したとき、イベントを受け取ることを行えるようにする。
ピア接続を通して、アプリケーションは、台帳をクエリ又は更新するチェーンコードを実行することができる。台帳クエリトランザクションの結果は即座に返され、一方、台帳更新は、アプリケーション、ピア、及びオーダラーの間でのより複雑な対話を含む。
図１７は、台帳があらゆるピアで最新に保たれることを保証するピアをオーダラーと併せて図示する。この例では、アプリケーションＡはＰ１に接続し、チェーンコードＳ１を呼び出して台帳Ｌ１をクエリ又は更新する。Ｐ１はＳ１を呼び出して、クエリ結果又は提案された台帳更新を含む提案レスポンスを生成する。アプリケーションＡは提案レスポンスを受け取り、クエリの場合、プロセスはここで完了する。更新の場合、Ａは全てのレスポンスからトランザクションを構築し、トランザクションを順序付けのためにＯ１に送る。Ｏ１はネットワーク中からトランザクションを収集してブロックにし、Ｐ１を含む全てのピアにこれらを配信する。Ｐ１はトランザクションを妥当性確認してから、Ｌ１に適用する。Ｌ１が更新されると、Ｐ１は、完了を示すイベントを生成し、イベントはＡにより受け取られる。
ピアは、クエリを満たすのに必要とされる全ての情報が、ピアの台帳のローカルコピーに集まると即座に、クエリの結果をアプリケーションに返すことができる。ピアは、アプリケーションからのクエリに応答するために他のピアと決して協議しない。しかしながら、アプリケーションは、１若しくはそれ以上のピアに接続して、クエリを発行することができ、例えば、情報が古いとの疑いがある場合、複数のピア間で結果を裏付け、又はより最新の結果を異なるピアから検索することができる。図中、台帳クエリが単純な３ステッププロセスであることを見て取ることができる。
更新トランザクションは、クエリトランザクションと同じように始まるが、２の追加ステップを有する。台帳更新アプリケーションもピアに接続して、チェーンコードを呼び出すが、台帳クエリアプリケーションと異なり、個々のピアはこのとき、台帳更新を実行することができず、その理由は、他のピアがまず変更に合意しなければならない－コンセンサスと呼ばれるプロセス－ためである。したがって、ピアはアプリケーションに更新提案－このピアが対象を他のピアの先の合意に適用するもの－を返す。第１の追加ステップ－ステップ４－では、アプリケーションは、各台帳へのコミットメントについてのトランザクションとして、ピアのネットワーク全体に適切な組の一致する更新提案を送る必要がある。これは、オーダラーを使用してトランザクションをブロックにパッケージングし、ピアのネットワーク全体に配信することによりアプリケーションにより達成され、ピアにおいて妥当性確認することができ、それから、各ピアの台帳のローカルコピーに適用される。この順序付け処理全体は完了までに幾らか時間が掛かる（数秒）ため、ステップ５に示されるように、アプリケーションには非同期で通知される。
ピア及びチャネル
ピアは、チャネル－ブロックチェーンネットワーク内の１組のコンポーネントがプライベートで通信し、取引できるようにするメカニズム－を介して互いと及びアプリケーションと対話する。
これらのコンポーネントは通常、ピアノード、オーダラーノード、及びアプリケーションであり、チャネルに参加することにより、協働して、そのチャネルに関連付けられた台帳の同一コピーをまとめて共有し管理することに合意する。概念上、チャネルは友人グループと同様のものとして考えることができる。１人は幾つかの友人グループを有することができ、各グループは、友人が一緒に行うアクティビティを有する。これらのグループは完全に別個であってもよく（趣味の友人グループと比較した職場の友人のグループ）、又はグループ間に幾らかの交差があってもよい。それにもかかわらず、各グループは、一種の「ルール」を有するそれ自体のエンティティである。
図１８は、特定の組のピア及びアプリケーションがブロックチェーンネットワーク内で互いと通信できるようにするチャネルを図示する。この例では、アプリケーションＡは、チャネルＣを使用してピアＰ１及びＰ２と直接通信することができる。チャネルは、特定のアプリケーションとピアとの間の通信のパスウェイとして考えることができる。（簡潔にするために、オーダラーはこの図に図示されていないが、機能的なネットワークには存在しなければならない）。
チャネルは、ピアのようには存在しない－物理的なピアの集まりにより形成される論理構造としてチャネルを考えることがより適切である。ピアは、チャネルへのアクセス及びチャネルの管理の制御ポイントを提供する。
ピア及び組織
ブロックチェーンネットワークは、１つの組織ではなくむしろ組織の集まりにより管理される。ピアは、この種の分散ネットワークがいかに構築されるかの中心であり、その理由は、ピアがこれらの組織により所有される－且つこれらの組織のネットワークへの接続点である－ためである。
図１９は、複数の組織を有するブロックチェーンネットワークにおけるピアを図示する。ブロックチェーンネットワークは、様々な組織により所有され寄与されるピアから構築される。この例では、ネットワークを形成する８つのピアに寄与する４つの組織が見られる。チャネルＣは、ネットワークＮにおけるこれらのピアのうちの５つ－Ｐ１、Ｐ３、Ｐ５、Ｐ７、及びＰ８－を接続する。これらの組織により所有されるその他のピアは、このチャネルに参加していないが、通常、少なくとも１つの他のチャネルに参加している。特定の組織により開発されたアプリケーションは、それ自体の組織のピア及び異なる組織のピアに接続する。ここでも、簡潔にするために、オーダラーノードはこの図に示されていない。
ネットワークは、リソースをネットワークに寄与する複数の組織により形成且つ管理される。ピアは、このトピックで考察しているリソースであるが、組織が提供するリソースはピアだけではない。ここで作用している原理がある－ネットワークは文字通り、集合的ネットワークに個々のリソースを寄与する組織なしでは存在しない。さらに、ネットワークは、これらの協働組織により提供されるリソースに伴って拡大縮小する。
順序付けサービス以外に、集中リソースはない－上記例では、組織がピアに寄与しなければ、ネットワークＮは存在しない。これは、組織が、ネットワーク形成するリソースに寄与しなければ、及び寄与するまで、ネットワークがいかなる有意な意味でも存在しないことを反映する。さらに、ネットワークはいかなる個々の組織にも依存しない－１つの組織が残っている限り、他のどの組織が行き来しようが関係なく、存在し続ける。これは、ネットワークが分散されることが何を意味するのかの核心である。
上記例と同様に、異なる組織におけるアプリケーションは同じであってもよく、又は同じでなくてもよい。それは、アプリケーションがピアの台帳コピーをいかに処理するかについては全体的に組織次第であるためである。これは、各ピアが厳密に同じ台帳データをホストするにもかかわらず、アプリケーション及び提示論理の両方が組織毎に様々であることを意味する。
アプリケーションは、必要とされる台帳対話の性質に応じて、組織におけるピア又は別の組織におけるピアの何れかに接続する。台帳クエリ対話では、アプリケーションは通常、それら自体の組織のピアに接続する。台帳更新対話では、アプリケーションは、台帳更新を是認することが求められるあらゆる組織を表すピアに接続する必要がある。
ピア及びアイデンティティ
ピアは、特定の証明機関からデジタル証明書を介して割り当てられたアイデンティティを有する。デジタル証明書は、ピアについての多くの確認情報を提供するＩＤカードのようなものである。ネットワークにおけるありとあらゆるピアには、その所有組織からの管理者によりデジタル証明書が割り当てられる。
図２０は、ピアがチャネルに接続する場合、そのデジタル証明書がチャネルＭＳＰを介して所有組織を識別することを図示する。この例では、Ｐ１及びＰ２はＣＡ１により発行されたアイデンティティを有する。チャネルＣは、チャネル構成におけるポリシーから、ＣＡ１からのアイデンティティがＯＲＧ１．ＭＳＰを使用してＯｒｇ１が関連付けられるべきであると決定する。同様に、Ｐ３及びＰ４は、Ｏｒｇ２の一部としてＯＲＧ２．ＭＳＰにより識別される。
ピアがチャネルを使用してブロックチェーンネットワークに接続するときは常に、チャネル構成におけるポリシーはピアのアイデンティティを使用してピアの権利を決定する。組織へのアイデンティティのマッピングは、メンバーシップ・サービス・プロバイダ（Ｍｅｍｂｅｒｓｈｉｐ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ：ＭＳＰ）と呼ばれるコンポーネントにより提供される－これは、ピアに特定の組織における特定の役割がいかに割り当てられるか及びそれに従ってピアがいかに、ブロックチェーンリソースへの適切なアクセスを獲得するかを決定する。さらに、ピアは１つの組織によってのみ所有することができ、したがって、１つのＭＳＰが割り当てられる。ＭＳＰは、個々のアイデンティティと、ブロックチェーンネットワークにおける特定の組織的役割との間のリンクを提供する。
ピア及びブロックチェーンネットワークと対話するあらゆるものは、デジタル証明書及びＭＳＰから組織アイデンティティを取得する。ピア、アプリケーション、エンドユーザ、管理者、及びオーダラーは、ブロックチェーンネットワークと対話したい場合、アイデンティティ及び関連付けられたＭＳＰを有さなければならない。名前が、アイデンティティ－プリンシパルを使用して、ブロックチェーンネットワークと対話するあらゆるエンティティに与えられる。
ピアが物理的にどこに配置されるかはあまり重要ではない－ピアはクラウドに常駐してもよく、組織の１つにより所有されるデータセンタに常駐してもよく、又はローカルマシンに常駐してもよい－特定の組織により所有されているものとしてピアを識別するのは、ピアに関連付けられたアイデンティティである。上記例では、Ｐ３は、Ｏｒｇ１のデータセンタにおいてホストすることができるが、関連付けられたデジタル証明書がＣＡ２により発行される限り、Ｏｒｇ２により所有される。
ピア及びオーダラー
アプリケーション及びピアが互いと対話して、あらゆるピアの台帳が一貫して保たれることを保証するメカニズムは、オーダラーと呼ばれる特別なノードにより仲介される。
更新トランザクションは、１つのピアがそれ自体で台帳を更新することができない－更新では、ネットワークにおける他のピアの同意が必要とされる－ため、クエリトランザクションとかなり異なる。ピアは、台帳更新をピアのローカル台帳に適用できるようにするには、先に、ネットワークにおける他のピアに台帳更新を承認するように求める。このプロセスはコンセンサスと呼ばれ、単純なクエリよりも完了までにはるかに長い時間が掛かる。しかし、トランザクションの承認が求められた全てのピアが承認し、トランザクションが台帳にコミットされる場合、ピアは、接続されたアプリケーションに、台帳が更新されたことを通知する。
特に、台帳を更新したいアプリケーションは、ブロックチェーンネットワークにおける全てのピアが、台帳を互いと一貫した状態を保つことを保証する３フェーズプロセスに関わる。第１のフェーズでは、アプリケーションは、それぞれが、アプリケーションへの台帳更新提案の是認を提供するが、台帳の各自のコピーへの更新提案を適用しない是認ピアのサブセットと共に作業する。第２のフェーズでは、これらの別個の是認は、トランザクションとして一緒に収集され、ブロックにパッケージされる。最終フェーズでは、これらのブロックはあらゆるピアに配信され、ピアにおいて、各トランザクションは、台帳のピアのコピーに適用される前、妥当性確認される。
オーダラーノードは、このプロセスの中心である。アプリケーション及びピアはオーダラーを使用して、分散した複製台帳に一貫して適用することができる台帳更新を生成する。
フェーズ１：
トランザクションワークフローのフェーズ１は、アプリケーションと１組のピアとの間の対話を含む－オーダラーを含まない。フェーズ１は、異なる組織の是認ピアに、提案されたチェーンコード呼び出しの結果への合意を求めているアプリケーションのみに関わる。
フェーズ１を開始するために、アプリケーションはトランザクション提案を生成し、トランザクション提案は、是認のために必要とされる組のピアのそれぞれに送られる。これらの是認ピアのそれぞれは次に、トランザクション提案を使用してチェーンコードを独立して実行して、トランザクション提案レスポンスを生成する。ピアはこの更新を台帳に適用せず、むしろ単に更新に署名し、アプリケーションに返す。アプリケーションが十分な数の署名付き提案レスポンスを受け取ると、トランザクションフローの第１のフェーズは完了する。
図２１は、是認された提案レスポンスを返すピアにより独立して実行されるトランザクション提案を図示する。この例では、アプリケーションＡ１はトランザクションＴ１の提案Ｐを生成し、チャネルＣでピアＰ１及びピアＰ２の両方に送る。Ｐ１は、トランザクションＴ１の提案Ｐを使用してＳ１を実行して、Ｅ１を有する、是認するトランザクションＴ１のレスポンスＲ１を生成する。独立して、Ｐ２はトランザクションＴ１の提案Ｐを使用してＳ１を実行して、Ｅ２を有する、是認するトランザクションＴ１のレスポンスＲ２を生成する。アプリケーションＡ１は、トランザクションＴ１の２つの是認レスポンス、すなわち、Ｅ１及びＥ２を受け取る。
最初に、１組のピアがアプリケーションにより選ばれて、１組の台帳更新提案が生成される。アプリケーションにより選ばれるピアは、ネットワークによる受け入れが可能になるには、先に、提案された台帳変更を是認する必要がある１組の組織を定義する是認ポリシー（チェーンコードに定義される）に依存する。これは文字通り、コンセンサスの達成が意味するものである－提案された台帳変更が任意のピアの台帳に受け入れられるには、先に、該当するあらゆる組織が提案された台帳変更を是認しなければならない。
ピアは、デジタル署名を追加し、秘密鍵を使用してペイロード全体に署名することにより提案レスポンスを是認する。この是認は続けて、この組織のピアが特定のレスポンスを生成したことを証明するのに使用することができる。上記例では、ピアＰ１が組織Ｏｒｇ１により所有される場合、是認Ｅ１は、「台帳Ｌ１についてのトランザクションＴ１のレスポンスＲ１がＯｒｇ１のピアＰ１により提供された」ことのデジタル証明に対応する。
フェーズ１は、アプリケーションが署名付き提案レスポンスを十分なピアから受け取ったとき、終わる。異なるピアは、同じトランザクション提案に対してアプリケーションに異なるトランザクションレスポンス、ひいては一貫しないトランザクションレスポンスを返すことができる。単に、結果が、台帳が異なる状態である異なるピアで異なるときに生成されたかもしれず、その場合、アプリケーションは単により最新の提案レスポンスを要求することができる。可能性は低いが、はるかに深刻なことに、チェーンコードが非決定的であるため、結果が異なることもある。非決定性は、チェーンコード及び台帳の敵であり、非決定性が生じる場合、明らかなことに、矛盾した結果を台帳に適用することはできないため、提案されたトランザクションに伴う深刻な問題を示す。個々のピアは、各自のトランザクション結果が非決定的であることを知ることができない－トランザクションレスポンスは、非決定性を検出することができる前、比較のために一緒に収集されなければならない。
フェーズ１の終了時、アプリケーションは、一貫しないトランザクションレスポンスを破棄したい場合、自由にそうすることができ、トランザクションワークフローを早期に終わらせる。アプリケーションが一貫しない組のトランザクションレスポンスを使用して、台帳を更新しようとする場合、拒絶される。
フェーズ２：トランザクションの順序付け及びブロックへのパッケージング
トランザクションワークフローの第２のフェーズは、パッケージングフェーズである。オーダラーはこのプロセスの中心である－多くのアプリケーションから是認されたトランザクション提案レスポンスを含むトランザクションを受け取り、トランザクションを順序付けてブロックにする。順序付け及びパッケージングフェーズについての更なる詳細については、順序付けフェーズについての概念情報をチェックされたい。
フェーズ３：妥当性確認及びコミット
フェーズ２の終了時、オーダラーは、トランザクション更新提案を収集し、それらを順序付け、ブロックにパッケージングし、ピアに配信できる状態にするという単純であるが重要なプロセスを受け持つ。
トランザクションワークフローの最終フェーズは、オーダラーから、台帳に適用することができるピアへのブロックの配信及び続く妥当性確認を含む。特に、各ピアにおいて、ブロック内のあらゆるトランザクションは妥当性確認されて、台帳に適用される前、全ての関連する組織により一貫して是認されたことを保証する。失敗したトランザクションは、監査のために保持されるが、台帳に適用されない。
図２２は、ブロックをピアに配信することであるオーダラーノードの第２の役割を図示する。この例では、オーダラーＯ１はブロックＢ２をピアＰ１及びピアＰ２に配信する。ピアＰ１はブロックＢ２を処理し、その結果、新しいブロックがＰ１における台帳Ｌ１に追加される。平行して、ピアＰ２はブロックＢ２を処理し、その結果、新しいブロックがＰ２における台帳Ｌ１に追加される。このプロセスが完了すると、台帳Ｌ１はピアＰ１及びＰ２で一貫して更新されており、各ピアは、接続されたアプリケーションに、トランザクションが処理されたことを通知する。
フェーズ３は、オーダラーが、接続された全てのピアにブロックを配信することで始まる。ピアは、新しいブロックが生成された場合、オーダラーに接続された全てのピアに新しいブロックのコピーが送られるように、チャネル上でオーダラーに接続される。各ピアはこのブロックを独立して、しかしチャネル上の他のあらゆるピアと厳密に同じ方法で処理する。このようにして、台帳を一貫した状態に保つことができる。また、あらゆるピアノードがオーダラーに接続される必要があるわけではない－ピアは、ゴシッププロトコルを使用して、独立して処理することもできる他のピアにブロックを転送することができる。
ブロックを受信すると、ピアは、ブロックに出現する順に各トランザクションを処理する。あらゆるトランザクションについて、各ピアは、トランザクションが、トランザクションを生成したチェーンコードの是認ポリシーに従って求められる組織により是認されたことを確認する。例えば、トランザクションによっては、有効であると見なされるには、１つの組織によって是認されるだけでよいものもあれば、複数の是認が必要なものもある。妥当性確認のこのプロセスは、全ての関連組織が同じ成果又は結果を生成したことを確認する。また、この妥当性確認が、是認ピアからレスポンスを受け取り、提案トランザクションを送る判断を行うのがアプリケーションであるフェーズ１での是認チェックと異なることに留意する。アプリケーションが、誤ったトランザクションを送ることにより是認ポリシーに違反する場合、ピアはなお、フェーズ３の妥当性確認プロセスでトランザクションを拒絶することが可能である。
トランザクションが正しく是認された場合、ピアはトランザクションを台帳に適用しようとする。これを行うために、ピアは台帳一貫性チェックを実行して、台帳の現在状態が、提案された更新が生成されたときの台帳の状態と互換性を有するか否かを確認する。トランザクションが完全に是認された場合であっても、これは常に可能であるわけではない。例えば、別のトランザクションが、トランザクション更新がもはや有効ではなく、したがって、もはや適用することができないように台帳における同じアセットを更新したかもしれない。このようにして、各ピアの台帳コピーは、それぞれ妥当性確認に同じルールに従うため、ネットワークにわたり一貫した状態に保たれる。
ピアは、個々の各トランザクションの妥当性確認に成功した後、台帳を更新する。失敗したトランザクションは台帳に適用されず、成功したトランザクションと同様に監査目的で保持される。これは、ピアブロックが、ブロック内の各トランザクションでの有効又は無効インジケータを除き、オーダラーから受け取ったブロックと略同じであることを意味する。
フェーズ３は、チェーンコードの実行を必要としない－これはフェーズ１中のみ行われ、それは重要である。チェーンコードは、ブロックチェーンネットワーク全体を通してではなく、是認ノードのみで利用可能であるだけでよいことを意味する。チェーンコードの論理を是認組織に対して機密に保つため、これは多くの場合、有用である。これは、トランザクションを是認するか否かに関係なく、チャネルにおけるあらゆるピアと共有されるチェーンコードの出力（トランザクション提案レスポンス）とは対照的である。是認ピアのこの特化はスケーラビリティに役立つように設計される。
最後に、ブロックがピアの台帳にコミットされる都度、そのピアは適切なイベントを生成する。ブロックイベントは全ブロック内容を含み、一方、ブロックトランザクションイベントは、ブロックにおける各トランザクションが有効化されたか、それとも無効化されたか等の概要情報のみを含む。チェーンコード実行が生成されたチェーンコードイベントもこのときに公開することができる。アプリケーションは、発生時に通知することができるように、これらのイベントタイプを記録することができる。これらの通知は、トランザクションワークフローの第３の最終フェーズを完結する。
まとめると、フェーズ３は、オーダラーにより生成され、台帳に一貫して適用されるブロックを見る。ブロックへのトランザクションの厳密な順序付けにより、各ピアは、トランザクション更新がブロックチェーンネットワーク全体にわたり一貫して適用されることの妥当性確認を行うことができる。
オーダラー及びコンセンサス
この全体トランザクション・ワークフロー・プロセスは、全てのピアが、オーダラーにより仲介されるプロセスにおいて、トランザクションの順序及び内容について合意に達したため、コンセンサスと呼ばれる。コンセンサスはマルチステッププロセスであり、アプリケーションには、プロセス完了時－異なるピアでわずかに異なる時間に生じる、台帳更新のみが通知される。
したがって、オーダラーは、ピアが妥当性確認し台帳に含めるために、提案された台帳更新をアプリケーションから収集し、配信するノードであると見なすことができる。他方、ネットワークからのピア、ホストチェーンコード、及び台帳は、トランザクション提案に対処して応答し、トランザクション更新を一貫して台帳に適用することにより台帳を最新に保つ。
ワールドステート
ワールドステートは、１組の台帳状態の現在値のキャッシュを保持するデータベースである。ワールドステートは、プログラムが、トランザクションログ全体を巡回することにより状態の現在値を計算する必要があるのではなく、状態の現在値に直接アクセスするのを容易にする。台帳状態は、デフォルトにより、キー値対として表される。状態が作成、更新、且つ削除されることができるため、ワールド状態は頻繁に変わることができる。
ワールドステートは、一意の台帳状態としてビジネスオブジェクトの属性の現在値を保持する。プログラムは通常、オブジェクトの現在値を必要とするため、これは有用である；ブロックチェーン全体を巡回して、オブジェクトの現在値を計算するのは面倒である－現在値はただ、ワールドステートから直接取得される。
図２３は、２つの状態を含む台帳ワールドステートを図示する。第１の状態は：キー＝ＣＡＲ１及び値＝アウディである。第２の状態はより複雑な値を有する：キー＝ＣＡＲ２及び値＝｛モデル：ＢＭＷ，色＝赤，所有者＝ジェーン｝。両状態ともバージョン０である。
台帳状態は、特定のビジネスオブジェクトについての１組の事実を記録する。上記例は、それぞれキー及び値を有する２台の車ＣＡＲ１及びＣＡＲ２の台帳状態を示す。アプリケーションプログラムは、単純な台帳ＡＰＩを使用して状態を取得し、配置し、削除するスマートコントラクトを呼び出すことができる。状態値がいかに単純（アウディ・・・）又は複合（タイプ：ＢＭＷ・・・）であることができるかに留意する。ワールドステートは多くの場合、特定の属性を有するオブジェクトを検索し、例えば、赤いＢＭＷを全て見つけるのにクエリされる。
ワールドステートはデータベースとして実装される。データベースは、状態の効率的な格納及び検索に演算子の豊富なセットを提供する。Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックは、異なるワールド・ステート・データベースを使用して、例えば複雑なクエリでアプリケーションにより必要とされる異なるタイプの状態値及びアクセスパターンの必要性に対処するように構成することができる。
アプリケーションは、ワールドステートへの変更を捕捉するトランザクションを提出し、これらのトランザクションは、台帳ブロックチェーンにコミットされることになる。アプリケーションは、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックＳＤＫによりこのコンセンサスメカニズムの詳細から絶縁され、単にスマートコントラクトを呼び出し、トランザクションがブロックチェーンに含まれたとき（有効又は無効に関係なく）、通知されるだけである。主要な設計ポイントは、必要とされる組の是認組織によって署名されたトランザクションのみが、ワールドステートへの更新になることである。トランザクションが十分な是認者により署名されない場合、ワールドステートの変更にはならない。
状態はバージョン番号を有し、上記図では、状態ＣＡＲ１及びＣＡＲ２は開始バージョン０である。バージョン番号は、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックによる内部使用のためであり、状態が変更される都度、インクリメントされる。状態が更新されるときは常にバージョンがチェックされて、現在の状態が是認時のバージョンに一致することを確かめる。これは、ワールドステートが予期されるように変更されており、同時更新が行われなかったことを保証する。
最後に、台帳が最初に作成されたとき、ワールドステートは空である。ワールドステートへの有効な変更を表すいかなるトランザクションもブロックチェーンに記録されるため、ワールドステートを随時、ブロックチェーンから再生成することができることを意味する。これは非常に好都合であることができる－例えば、ワールドステートは、ピア作成時、自動的に生成される。さらに、ピアが異常に機能停止（ｆａｉｌ）した場合、トランザクションが受け入れられる前、ピア再開時にワールドステートを再生成することができる。
ワールドステートは物理的にデータベースとして実装されて、台帳状態の単純で効率的な格納及び検索を提供する。台帳状態は単純値又は複合値を有することができ、これに対応するために、ワールド・ステート・データベース実装は様々であることができ、これらの値を効率的に実装できるようにする。ワールド・ステート・データベースの選択肢には現在、ＬｅｖｅｌＤＢ及びＣｏｕｃｈＤＢ（登録商標）がある。
ＬｅｖｅｌＤＢはデフォルトであり、台帳状態が単純なキー値対である場合、特に適切である。ＬｅｖｅｌＤＢデータベースは、ネットワークノードと接近して同じ場所に配置される－同じオペレーティング・システム・プロセス内に組み込まれる。
ＣｏｕｃｈＤＢ（登録商標）は、台帳状態がＪＳＯＮドキュメントとして構造化される場合、特に適切な選択肢であり、その理由は、ＣｏｕｃｈＤＢ（登録商標）がビジネストランザクションで見られることが多いよりリッチなデータ型のリッチクエリ及び更新をサポートするためである。実装毎に、ＣｏｕｃｈＤＢ（登録商標）は別個のオペレーティング・システム・プロセスで実行されるが、それでもなお、ピアノードとＣｏｕｃｈＤＢ（登録商標）インスタンスとの間には１：１関係がある。この全てはスマートコントラクトからは不可視である。
ＬｅｖｅｌＤＢ及びＣｏｕｃｈＤＢ（登録商標）では、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックの重要な態様が見られる－それはプラガブルである。ワールド・ステート・データベースは、リレーショナル・データ・ストア、グラフストア、又は一時的データベースであることができる。これは、効率的にアクセスすることができる台帳状態のタイプに大きな柔軟性を提供し、Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックが多くの異なるタイプの問題に対処できるようにする。
Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックでは、各チャネルは完全に別個の台帳を有する。これは完全に別個のブロックチェーン及び名前空間を含めて完全に別個のワールドステートを意味する。チャネル間で台帳情報にアクセスすることができるように、アプリケーション及びスマートコントラクトがチャネル間で通信することが可能である。
状態データベースとしてのＣｏｕｃｈＤＢ（登録商標）
ＣｏｕｃｈＤＢ（登録商標）は、任意選択の代替の外部状態データベースである。ＣｏｕｃｈＤＢ（登録商標）は、チェーンコードでモデリングされた任意のバイナリデータを格納することができる（ＣｏｕｃｈＤＢ（登録商標）付属機能は、非ＪＳＯＮバイナリデータに内部で使用される）。しかし、ＪＳＯＮドキュメントストアとして、ＣｏｕｃｈＤＢ（登録商標）はさらに、チェーンコード値（例えばアセット）がＪＳＯＮデータとしてモデリングされる場合、チェーンコードデータと突き合わせたリッチクエリを可能にする。
ＣｏｕｃｈＤＢ（登録商標）は、キー（アセット）の取得及び設定並びにキーに基づくクエリ等のコアチェーンコード演算をサポートする。キーは範囲によりクエリすることができ、複合キーをモデリングして、複数のパラメータと突き合わせた等価性クエリを可能にすることができる。例えば、所有者、アセットＩＤの複合キーを使用して、特定のエンティティにより所有される全てのアセットをクエリすることができる。これらのキーベースのクエリは、台帳と突き合わせた読み取り専用クエリ及び台帳を更新するトランザクションに使用することができる。
アセットをＪＳＯＮとしてモデリングし、ＣｏｕｃｈＤＢ（登録商標）を使用する場合、チェーンコード内のＣｏｕｃｈＤＢ（登録商標）ＪＳＯＮクエリ言語を使用して、チェーンコードデータ値と突き合わせて複雑なリッチクエリを実行することもできる。これらのタイプのクエリは、台帳に何かがあるかの理解に優れている。これらのタイプのクエリの提案レスポンスは通常、クライアントアプリケーションにとって有用であるが、通常、トランザクションとして順序付けサービスに提出されない。実際には、結果セットがチェーンコード実行とリッチクエリのコミット時間との間で安定している保証はなく、したがって、リッチクエリは、結果セットがチェーンコード実行とコミット時間との間で安定していることをアプリケーションが保証することができる場合又はアプリケーションが続くトランザクションにおける潜在的な変更に対処することができる場合を除き、更新トランザクションでの使用には適切ではない。例えば、アリスにより所有される全てのアセットについてのリッチクエリを実行し、ボブに転送する場合、チェーンコード実行時間とコミット時間との間に別のトランザクションにより新しいアセットがアリスに割り当てられることがあり、この「幻の」項目を見逃すであろう。
ＣｏｕｃｈＤＢ（登録商標）は、ピアと共に別個のデータベースプロセスとして実行され、したがって、セットアップ、管理、及び動作に関して追加の考慮事項がある。将来必要な場合、複雑なリッチクエリを実行する選択肢を有するように、チェーンコード・アセット・データをＪＳＯＮとしてモデリングすることは優れた実施である。
チェーンコードからのＣｏｕｃｈＤＢ（登録商標）の使用
チェーンコードクエリ
チェーンコードシムＡＰＩの大半、例えば、ＧｅｔＳｔａｔｅ、ＰｕｔＳｔａｔｅ、ＧｅｔＳｔａｔｅＢｙＲａｎｇｅ、ＧｅｔＳｔａｔｅＢｙＰａｒｔｉａｌＣｏｍｐｏｓｉｔｅＫｅｙは、ＣｏｕｃｈＤＢ（登録商標）状態データベースと共に利用することができる。さらに、ＣｏｕｃｈＤＢ（登録商標）を状態データベースとして利用し、モデルアセットをチェーンコードにおけるＪＳＯＮとして利用する場合、ＧｅｔＱｕｅｒｙＲｅｓｕｌｔ ＡＰＩを使用し、ＣｏｕｃｈＤＢ（登録商標）クエリ文字列を渡すことにより、リッチクエリを状態データベース中のＪＳＯＮと突き合わせて実行することができる。クエリ文字列はＣｏｕｃｈＤＢ ＪＳＯＮクエリシンタックスに従う。
ｍａｒｂｌｅｓ０２ファブリックサンプルは、チェーンコードからのＣｏｕｃｈＤＢ（登録商標）クエリの使用を示す。所有者ＩＤをチェーンコードに渡すことによりパラメータ化されたクエリを示すｑｕｅｒｙＭａｒｂｌｅｓＢｙＯｗｎｅｒ（）関数を含む。次に、ＪＳＯＮクエリシンタックス：
{"selector":{"docType":"marble","owner":}}
を使用して、ドキュメントタイプ「ｍａｒｂｌｅ」及び所有者ＩＤに一致するＪＳＯＮドキュメントについて状態データをクエリする。
ＣｏｕｃｈＤＢ（登録商標）ページネーション
ファブリックは、リッチクエリ及び範囲ベースクエリのクエリ結果のページングをサポートする。ページネーションをサポートするＡＰＩは、範囲クエリ及びリッチクエリの両方でページサイズの使用を可能にするとともに、ブックマークを使用できるようにする。効率的なページネーションをサポートするためには、ファブリックページネーションＡＰＩを使用しなければならない。特に、ファブリック自体がクエリ結果のページネーションを管理し、ＣｏｕｃｈＤＢ（登録商標）に渡されたページサイズ限度を暗黙的に設定するため、ＣｏｕｃｈＤＢ（登録商標）のｌｉｍｉｔキーワードは、ＣｏｕｃｈＤＢ（登録商標）クエリでは尊重されない。
ページサイズがページネーションクエリＡＰＩ（ＧｅｔＳｔａｔｅＢｙＲａｎｇｅＷｉｔｈＰａｇｉｎａｔｉｏｎ（）、ＧｅｔＳｔａｔｅＢｙＰａｒｔｉａｌＣｏｍｐｏｓｉｔｅＫｅｙＷｉｔｈＰａｇｉｎａｔｉｏｎ（）、及びＧｅｔＱｕｅｒｙＲｅｓｕｌｔＷｉｔｈＰａｇｉｎａｔｉｏｎ（））を使用して指定される場合、１組の結果（ページサイズによって区切られる）は、ブックマークと共にチェーンコードに返される。ブックマークは、チェーンコードから呼び出し側クライアントに返すことができ、呼び出し側クライアントは、続くクエリでブックマークを使用して、結果の次の「ページ」を受け取ることができる。
ページネーションＡＰＩは、読み取りトランザクションでの使用のみであり、クエリ結果はクライアントのページング要件をサポートすることが意図される。読み出し及び書き込みが必要なトランザクションの場合、非ページネーション・チェーンコード・クエリＡＰＩを使用する。チェーンコード内で、結果セットを通して所望の深さまで反復する。
ページネーションＡＰＩが利用されるか否かに関係なく、全てのチェーンコードクエリは、ｃｏｒｅ．ｙａｍｌからのｔｏｔａｌＱｕｅｒｙＬｉｍｉｔ（デフォルト１０００００）によって区切られる。これは、非意図的又は悪意のある長期実行クエリを回避するために、チェーンコードが反復し、クライアントに返す悔過の最大数である。
ＣｏｕｃｈＤＢ（登録商標）インデックス
ＣｏｕｃｈＤＢ（登録商標）におけるインデックスは、ＪＳＯＮクエリを効率的にするために必要であり、ソートを有する任意のＪＳＯＮクエリに必要とされる。インデックスは、／ＭＥＴＡ－ＩＮＦ／ｓｔａｔｅｄｂ／ｃｏｕｃｈｄｂ／ｉｎｄｅｘｅｓディレクトリでチェーンコードと共にパッケージングすることができる。各インデックスは、それ自体のテキストファイルにおいて、ＣｏｕｃｈＤＢインデックスＪＳＯＮシンタックスに従ってＪＳＯＮでフォーマットされたインデックス定義を用いて拡張＊．ｊｓｏｎを用いて定義されなければならない。例えば、上記ｍａｒｂｌｅクエリをサポートするために、ドキュメントタイプ及び所有者フィールドでのサンプルインデックスが提供される：
{"index":{"fields":["docType","owner"]},"ddoc":"indexOwnerDoc","name":"indexOwner","type":"json"}
チェーンコードのＭＥＴＡ－ＩＮＦ／ｓｔａｔｅｄｂ／ｃｏｕｃｈｄｂ／ｉｎｄｅｘｅｓディレクトにおける任意のインデックスは、デプロイ用のチェーンコードと共にパッケージされる。チェーンコードがピアにインストールされ、且つピアのチャネルの１つでインスタンス化される場合、インデックスはピアのチャネル及びチェーンコード固有状態データベース（ＣｏｕｃｈＤＢ（登録商標）を使用するように構成されていた場合）に自動的にデプロイされる。まずチェーンコードをインストールし、次にチャネルでチェーンコードをインスタンス化する場合、インデックスはチェーンコードインスタンス化時にデプロイされる。チェーンコードがチャネルで既にインスタンス化されており、後にチェーンコードをピアにインストールする場合、インデックスはチェーンコードインストール時にデプロイされる。
デプロイされると、インデックスはチェーンコードクエリにより自動的に利用される。ＣｏｕｃｈＤＢ（登録商標）は、クエリで使用されているフィールドに基づいてどのインデックスを使用するか自動的に決定することができる。代替的には、セレクタクエリにおいて、インデックスはｕｓｅ＿ｉｎｄｅｘキーワードを使用して指定することができる。
同じインデックスが、インストールされたチェーンコードの続くバージョンに存在することができる。インデックスを変更するには、同じインデックス名を使用するが、インデックス定義を変更する。インストール／インスタンス化されると、インデックス定義はピアの状態データベースに再デプロイされる。
大量のデータを既に有し、後にチェーンコードをインストールする場合、インスタンス化時のインデックス作成は幾らか時間が掛かることがある。同様に、大量のデータを既に有し、チェーンコードの後続バージョンをインスタンス化する場合、インデックス作成は幾らかの時間が掛かることがある。インデックスが初期化されている間、チェーンコードクエリが時間切れする可能性があるため、状態データベースにこの時間クエリするチェーンコード関数を呼び出すことを回避する。トランザクション処理中、ブロックが台帳にコミットされる場合、インデックスは自動的にリフレッシュされる。
ＣｏｕｃｈＤＢ（登録商標）構成
ＣｏｕｃｈＤＢ（登録商標）は、ｇｏｌｅｖｅｌｄｂからＣｏｕｃｈＤＢ（登録商標）に状態データベース構成選択肢を変えることにより状態データベースとしてイネーブルされる。さらに、ｃｏｕｃｈＤＢＡｄｄｒｅｓｓは、ピアにより使用されるＣｏｕｃｈＤＢ（登録商標）を指すように構成される必要がある。ＣｏｕｃｈＤＢ（登録商標）にユーザ名及びパスワードが構成されている場合、ユーザ名及びパスワードプロパティには、ａｄｍｉｎユーザ名及びパスワードが記入されるべきである。追加の選択肢がｃｏｕｃｈＤＢＣｏｎｆｉｇセクションに提供され、適所に文書化される。ｃｏｒｅ．ｙａｍｌへの変更は、ピアの再開後、即座に有効になる。
ｃｏｒｅ．ｙａｍｌ値をオーバーライドするドッカー環境変数、例えば、ＣＯＲＥ＿ＬＥＤＧＥＲ＿ＳＴＡＴＥ＿ＳＴＡＴＥＤＡＴＡＢＡＳＥ、及びＣＯＲＥ＿ＬＥＤＧＥＲ＿ＳＴＡＴＥ＿ＣＯＵＣＨＤＢＣＯＮＦＩＧ＿ＣＯＵＣＨＤＢＡＤＤＲＥＳＳを渡すこともできる。
以下はｃｏｒｅ．ｙａｍｌからのステート・データベース・セクションである：
状態：
# stateDatabase－選択肢は"goleveldb"、"CouchDB"
# goleveldb-goleveldbに格納されるデフォルト状態データベース。
# CouchDB-CouchDBに状態データベースを格納する
stateDatabase: goleveldb
# クエリ毎に返すレコード数への限度
totalQueryLimit: 10000
couchDBConfig:
# ピアと同じサーバでCouchDBを実行することが推奨され、
# ドッカーコンポーズにおいてCouchDBコンテナポートをサーバポートにマッピングせず、
# その他の場合、適切なセキュリティをCouchDBクライアント（ピア上）とサーバとの間に提供しなければならず、
couchDBAddress: couchdb:5984
# このユーザ名は、CouchDBユーザ名で読み出し及び書き込み権限を有さなければならず、
# スタートアップ中、パスワードは、環境変数として渡されることが推奨され（例えば、ＬＥＤＧＥＲ＿ＣＯＵＣＨＤＢＣＯＮＦＩＧ＿ＰＡＳＳＷＯＲＤ）、
# ここに格納される場合、意図されないユーザがパスワードを発見するのを阻止するために、ファイルにはアクセス制御保護付きでアクセスしなければならない。
パスワード：
# CouchDBエラーの場合の再試行数
最大再試行：３
# ピアスタートアップ中のCouchDBエラーお場合の再試行数
スタートアップ時の最大再試行：１０
# CouchDBリクエスト時間切れ（単位：持続時間、例えば２０秒）
リクエスト時間切れ：３５秒
# 各CouchDBクエリ当たりのレコード数の限度
# なお、チェーンコードクエリはtotalQueryLimitによってのみ制限される。
# 内部的にチェーンコードは複数のCouchDBクエリを実行することができる
# サイズのinternalQueryLimitのそれぞれ
internalQueryLimit: 1000
# CouchDBバルク更新バッチ当たりのレコード数限度
maxBatchUpdateSize: 1000
# あらゆるＮブロック後にウォームインデックス。
# この選択肢は、あらゆるＮブロック後にCouchDBにデプロイされた任意のインデックスをウォームする。
# 高速セレクタクエリを保証するために、あらゆるブロックコミット後、値１がインデックスをウォームする。
# 値の増大は、ピア及びCouchDBの書き込み効率を改善する可能性があるが、クエリレスポンス時間を低下させる恐れがある。
warmIndexesAfterNBlocks: 1
Ｈｙｐｅｒｌｅｄｇｅｒ（登録商標）ファブリックを用いて供給されるドッカーコンテナにおいてホストされるＣｏｕｃｈＤＢ（登録商標）は、ドッカー・コンポーズ・スクリプトを使用してＣＯＵＣＨＤＢ＿ＵＳＥＲ及びＣＯＵＣＨＤＢ＿ＰＡＳＳＷＯＲＤ環境変数を用いて渡される環境変数を用いてＣｏｕｃｈＤＢ（登録商標）ユーザ名及びパスワードを設定する能力を有する。
ファブリックを用いて供給されるドッカーイメージ外部のＣｏｕｃｈＤＢ（登録商標）インストールの場合、そのインストールのｌｏｃａｌ．ｉｎｉファイルは、ａｄｍｉｎユーザ名及びパスワードを設定するように編集されなければならない。
ドッカー・コンポーズ・スクリプトは、コンテナ作成時のみ、ユーザ名及びパスワードを設定する。コンテナ作成後、ユーザ名又はパスワードが変更されるべき場合、ｌｏｃａｌ．ｉｎｉファイルは編集されなければならない。
ＣｏｕｃｈＤＢ（登録商標）ピア選択肢は、各ピアスタートアップ時に読み出される。
アイデンティティ
ブロックチェーンネットワークにおける異なるアクターは、ピア、オーダラー、クライアントアプリケーション、管理者等を含む。これらのアクターのそれぞれ－サービスを消費することができるネットワーク内又は外の能動要素－は、Ｘ．５０９デジタル証明書にカプセル化されたデジタルアイデンティティを有する。これらのアイデンティティは、アクターがブロックチェーンネットワークにおいて有するリソースにわたる厳密な許可及び情報へのアクセスを決めるため、実に重要である。
デジタルアイデンティティは、ファブリックが許可を決定するのに使用する幾つかの追加の属性を更に有し、アイデンティティと関連付けられた属性との結合体に特別な名前－プリンシパルを与える。プリンシパルはまるでユーザＩＤ又はグループＩＤのようであるが、アクターの組織、組織ユニット、役割、又はアクターの特定のアイデンティティ等の広範囲のプロパティのアクターアイデンティティを含むことができるため、わずかにより柔軟性が高い。プリンシパルを語る場合、プリンシパルは、許可を決めるプロパティである。
アイデンティティが確認可能であるためには、アイデンティティは高信頼性機関からのものでなければならない。メンバーシップ・サービス・プロバイダ（ＭＳＰ）は、これがファブリックでいかに達成されるかである。より具体的には、ＭＳＰは、この組織の有効アイデンティティを支配するルールを定義するコンポーネントである。ファブリックにおけるデフォルトＭＳＰ実装は、Ｘ．５０９証明書をアイデンティティとして使用し、従来の公開鍵基盤（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ：ＰＫＩ）階層モデルを採用する（ＰＫＩについては更に後述する）。
アイデンティティの使用を説明するための単純なシナリオ
スーパーマーケットに行き、幾つかの食料品を購入すると想像する。チェックアウト時、Ｖｉｓａ、Ｍａｓｔｅｒｃａｒｄ、及びＡＭＥＸカードのみが許容されるという貼り紙を見る。別のカードで支払おうとする場合－これを「イマジンカード」と呼ぶことにする－そのカードが真正であるか否か及び口座に十分な資金があるか否かは重要ではない。そのカードが許容されることはない。
図２４は、有効なクレジットカードを有することが十分ではない－カードはまた、店により許容されなければならない－ことを図示する。ＰＫＩ及びＭＳＰは同じように一緒に機能する－ＰＫＩはアイデンティティのリストを提供し、ＭＳＰはこれらのアイデンティティのどれが、ネットワークに参加する所与の組織のメンバであるかを語る。
ＰＫＩ証明機関及びＭＳＰは、機能の同様の組合せを提供する。ＰＫＩはカードプロバイダのようなものである－多くの異なるタイプの確認可能なアイデンティティを分配する。他方、ＭＳＰは、店により許容されるカードプロバイダのリストのようなものであり、どのアイデンティティが、店の支払いネットワークの高信頼性メンバ（アクター）であるかを特定する。ＭＳＰは、確認可能なアイデンティティをブロックチェーンネットワークのメンバに変える。
ＰＫＩ
公開鍵基板（ＰＫＩ）は、ネットワークにおいて安全な通信を提供するインターネット技術の集まりである。
図２５は、公開鍵基盤（ＰＫＩ）の要素を図示する。ＰＫＩは、デジタル証明書を当事者（例えば、サービスのユーザ、サービスプロバイダ）に発行する証明機関で構成され、当事者は次に、デジタル証明書を使用して、当事者の環境と交換するメッセージにおいて自身を認証する。ＣＡの証明書失効リスト（Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ：ＣＲＬ）は、もはや有効ではない証明書のリファレンスを構成する。証明書の失効は幾つかの理由で発生することがある。例えば、証明書は、証明書に関連付けられた暗号プライベート資料が露出されたため、失効することがある。
ブロックチェーンネットワークは通信ネットワークを超えるものであるが、種々のネットワーク参加者間の安全な通信を保証し、ブロックチェーンに掲示されたメッセージが適宜認証されることを保証するのにＰＫＩ規格に頼る。したがって、ＰＫＩの基本を理解し、そしてＭＳＰが何故それ程重要であるかを理解することが重要である。
ＰＫＩには４つの主要要素がある：
・デジタル証明書、
・公開鍵及び秘密鍵、
・証明機関、
・証明書失効リスト。
デジタル証明書
デジタル証明書は、証明書の所持人に関連する１組の属性を保持するドキュメントである。最も一般的なタイプの証明書は、Ｘ．５０９規格に準拠するものであり、当事者の識別情報詳細をその構造に符号化できるようにする。
例えば、ミシガン州デトロイトにおけるＭｉｔｃｈｅｌｌ Ｃａｒｓの製造部門のＭａｒｙ Ｍｏｒｒｉｓは、Ｃ＝ＵＳ、ＳＴ＝ミシガン、Ｌ＝デトロイト、Ｏ＝Ｍｉｔｃｈｅｌｌ Ｃａｒｓ、ＯＵ＝製造、ＣＮ＝Ｍａｒｙ Ｍｏｒｒｉｓ／ＵＩＤ＝１２３４５６というサブジェクト属性を有するデジタル証明書を有する。Ｍａｒｙの証明書は、政府識別カードと同様である－自身についての鍵となる事実を証明するのに使用することができる、Ｍａｒｙについての情報を提供する。
図２６は、Ｍａｒｙ Ｍｏｒｒｉｓと呼ばれる当事者を記述するデジタル証明書を示す。Ｍａｒｙは証明書のサブジェクトであり、強調表示されたサブジェクトテキストは、Ｍａｒｙについての鍵となる事実を示す。証明書は、見て取ることができるように、より多くの情報も保持する。最も重要なことには、Ｍａｒｙの公開鍵はＭａｒｙの証明書内で分配され、一方、Ｍａｒｙの秘密署名鍵はＭａｒｙの証明書内で分配されない。この署名鍵はプライベートに保たれなければならない。
重要なことは、暗号法（文字取り「シークレットライティング」）と呼ばれる数学的技法を使用して、改竄が証明書を無効化するようにＭａｒｙの全ての属性を記録することができることである。暗号法により、他の当事者が証明機関（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ：ＣＡ）として知られる証明書発行者を信頼する限り、Ｍａｒｙは自身の証明書を他人に提示して、自身の身元を証明することができる。ＣＡが特定の暗号情報（それ自体の秘密署名鍵を意味する）を秘密に保つ限り、証明書を読んだ誰であっても、Ｍａｒｙについての情報が改竄されていない－Ｍａｒｙ Ｍｏｒｒｉｓについての特定の属性を常に有する－ことを信じることができる。ＭａｒｙのＸ．５０９証明書を、変更不可能なデジタルＩＤカードとして考える。
認証、公開鍵、及び秘密鍵
認証及びメッセージ保全性は、安全な通信において重要な概念である。認証は、メッセージを交換する当事者が、特定のメッセージを作成したことのアイデンティティが保証されることを要求する。メッセージが「保全性」を有することは、伝送中に変更されたはずがないことを意味する。例えば、あなたが、なりすましではなく実際のＭａｒｙ Ｍｏｒｒｉｓと通信していることを確かめたいことがある。又はＭａｒｙがあなたにメッセージを送信した場合、送信中、そのメッセージが誰によっても改竄されなかったことを確かめたいことがある。
従来の認証メカニズムは、名前が示唆するように、当事者がメッセージにデジタル署名することができるデジタル署名に頼っている。デジタル署名は、署名されたメッセージの保全性についての保証も提供する。
技術的に言えば、デジタル署名メカニズムでは、各当事者が２つの暗号的に結ばれた鍵を保持する必要がある：広範囲で利用可能であり、認証の頼みの綱として働く公開鍵及びメッセージのデジタル署名を生成するのに使用される秘密鍵。デジタル署名されたメッセージの受信者は、添付された署名が、予期された送信者の公開鍵下で有効であることをチェックすることにより、受信したメッセージの出所及び保全性を確認することができる。
秘密鍵と各公開鍵との間の一意の関係は、安全な通信を可能にする暗号魔法である。鍵間の一意の数学的関係は、秘密鍵を使用して、対応する公開鍵のみが、同じメッセージでのみ一致することができるメッセージ上の署名を生成することができるようなものである。
図２７に図示される例では、Ｍａｒｙは秘密鍵を使用してメッセージに署名する。署名は、Ｍａｒｙの公開鍵を使用して署名付きメッセージを見る誰によっても確認することができる。
証明機関
アクター又はノードは、システムにより信頼される機関により発行されたデジタルアイデンティティの手段により、ブロックチェーンネットワークに参加することが可能である。最も一般的な事例では、デジタルアイデンティティ（又は単にアイデンティティ）は、Ｘ．５０９規格に準拠する暗号的に妥当性確認されたデジタル証明書の形態を有し、証明機関（ＣＡ）により発行される。
ＣＡは、特に、Ｓｙｍａｎｔｅｃ（元々はＶｅｒｉｓｉｇｎ）、ＧｅｏＴｒｕｓｔ、ＤｉｇｉＣｅｒｔ、ＧｏＤａｄｄｙ、及びＣｏｍｏｄｏ等のインターネット・セキュリティ・プロトコルの共通部分である。
図２８は、異なるアクターに証明書を分配する証明機関を図示する。これらの証明書は、ＣＡによりデジタル署名され、アクターをアクターの公開鍵（及び任意選択でプロパティの包括的リスト）に一緒にバインドする。その結果、ＣＡを信頼する（そしてその公開鍵を知る）場合、アクターの証明書のＣＡの署名を妥当性確認することにより、特定のアクターが、証明書に含まれる公開鍵にバインドされ、証明書に含まれる属性を所有することを信用することができる。
証明書は、アクターの秘密鍵もＣＡの秘密鍵も含まないため、広く広めることができる。したがって、証明書は、異なるアクターから来たメッセージを認証する信用の頼みの綱として使用することができる。
ＣＡは証明書も有し、これは広く利用可能である。これにより、所与のＣＡにより発行されたアイデンティティの消費者は、証明書が対応する秘密鍵（ＣＡ）の保有者によってのみ生成されたはずであることをチェックすることにより確認することができる。
ブロックチェーン設定では、ネットワークとの対話を望むあらゆるアクターは、アイデンティティを必要とする。この設定では、１若しくはそれ以上のＣＡを使用して、デジタルの観点から組織のメンバを定義することができると言える。組織のアクターが確認可能なデジタルアイデンティティを有することの基本を提供するのは、ＣＡである。
ルートＣＡ、中間ＣＡ、及び信頼チェイン
ＣＡには２つの特色がある：ルートＣＡ及び中間ＣＡ。ルートＣＡ（Ｓｙｍａｎｔｅｃ、Ｇｅｏｔｒｕｓｔ等）は、何億もの証明書をインターネットユーザに安全に分配する必要があるため、このプロセスを中間ＣＡと呼ばれるものにわたり拡散させることは道理に適う。これらの中間ＣＡは、ルートＣＡ又は別の中間期間により発行された証明書を有し、チェイン中の任意のＣＡにより発行された任意の証明書に「信頼チェイン」を確立できるようにする。ルートＣＡまで追跡して遡るこの能力は、セキュリティをなお提供しながらＣＡの機能をスケーリングできるようにするのみならず－証明書を消費する組織が、自信を持って中間ＣＡを使用できるようにする－、損なわれた場合、信頼チェイン全体が危険に曝されるルートＣＡの露出を制限もする。他方、中間ＣＡが損なわれた場合、露出ははるかに少ない。
図２９は、１組の中間ＣＡのそれぞれの証明書を発行するＣＡがルートＣＡ自体であるか、又はルートＣＡへの信頼チェインを有する限り、ルートＣＡとこれらの中間ＣＡとの間に確立される信頼チェインを図示する。
中間ＣＡは、複数の組織にわたり証明書を発行することになった場合、膨大な量の柔軟性を提供し、それは許可されたブロックチェーンシステム（ファブリックのように）において非常に有用である。例えば、異なる組織は異なるルートＣＡを使用してもよく、又は異なる中間ＣＡを有する同じルートＣＡを使用してもよい－実際にはネットワークのニーズに依存する。
ファブリックＣＡ
ファブリックは、ユーザが、形成されたブロックチェーンネットワークでＣＡを作成できるようにする内蔵ＣＡコンポーネントを提供する。このコンポーネント－ファブリックＣＡとして知られるのは、Ｘ．５０９証明書の形態を有するファブリック参加者のデジタルアイデンティティを管理可能なプライベートルートＣＡプロバイダである。ファブリックＣＡはファブリックのルートＣＡニーズに的を絞ったカスタムＣＡであるため、本質的に、ブラウザで一般的／自動的に使用されるＳＳＬ証明書を提供することができない。しかしながら、何らかのＣＡはアイデンティティの管理に使用しなければならない（テスト環境であってさえも）ため、ファブリックＣＡは、証明書の提供及び管理に使用される。公開／商用ルート又は中間ＣＡを使用して識別を提供することも可能である－そして完全に適切である。
証明書失効リスト
証明書失効リスト（ＣＲＬ）は、ＣＡが何らかの理由で失効したことが分かっている証明書への参照のリストである。店のシナリオでは、ＣＲＬは、盗まれたクレジットカードのリストのようなものである。
第三者が別の当事者の身元を確認したい場合、まず、発行ＣＡのＣＲＬをチェックして、証明書が施行していないことを確かめる。確認者はＣＲＬをチェックする必要はないが、チェックしない場合には、損なわれたアイデンティティを受け入れるリスクを負う。
図３０は、ＣＲＬを使用して、証明書がなお有効であることをチェックすることを図示する。なりすましが、損なわれたデジタル証明書を妥当性確認当事者に渡そうとする場合、まず、発行ＣＡのＣＲＬと突き合わせてチェックされて、もはや有効ではないものとして列記されていないことを確かめることができる。
なお、失効中の証明書は、証明書の期限切れとはかなり異なる。失効した証明書は期限切れしていない－他のあらゆる基準では完全に有効な証明書である。
リファレンス：
ファブリック及びＣｏｕｃｈＤＢ（登録商標）に関する上記情報は、以下のリンクで入手可能なソースから公に採用された。
https://hyperledger-fabric.readthedocs.io/en/release-1.4/fabric_model.html#
https://kaleido.io/enterprise-blockchain-protocols-ethereum-vs-fa
https://hyperledger-fabric.readthedocs.io/en/release-1.4/peers/peers.html#applications-and-peers
https://hyperledger-fabric.readthedocs.io/en/release-1.4/ledger/ledger.html#world-state-database-options
https://hyperledger-fabric.readthedocs.io/en/release-1.4/couchdb_as_state_database.html
https://hyperledger-fabric.readthedocs.io/en/release-1.4/identity/identity.html#identity
https://hyperledger-fabric.readthedocs.io/en/release-1.4/identity/identity.html#fabric-ca
付録Ｂ
リレーショナル・データ・アクセス制御
Ｓｕｐｅｒ Ａｄｍｉｎ：ルート許可
ＥＬＥＭＥＮＴにおける他の全てのアクティビティの前提条件は、データベースの作成及びそのデータベースに対して演算を実行する少なくとも１つのアイデンティティの承認である。「Ｓｕｐｅｒ Ａｄｍｉｎ」アクセスレベルは、これを行う許可を認める。
データベースの実装は高度にプラットフォーム固有であるため、その存在以外のこの許可レベルについてのプラットフォーム独立仕様はない。
エレメント・アクセス・レベル
ＥＬＥＭＥＮＴシステムにおける残りのユーザ・アクセス・レベルは、データベース毎に認められる。
リレーショナル・データ・アクセス制御管理は、ＥＬＥＭＥＮＴへの登録成功時に分散型台帳アイデンティティに有り当てられる特定の一意の属性に基づく。ＥＬＥＭＥＮＴを使用する全ての分散型台帳アイデンティティは、これらの属性に基づいてカテゴライズされ確認される。特定のデータベースでのアイデンティティに基づくユーザの分類により、ＥＬＥＭＥＮＴにより認められる演算範囲が決まる。
図３１は、アクセスレベル及び許可決定を図示する。
ＥＬＥＭＥＮＴには５つのアクセスレベルがあり、それらのレベルの各特権について以下説明する。
Ｓｕｐｅｒ Ａｄｍｉｎ
考察したように、Ｓｕｐｅｒ ＡｄｍｉｎはＥＬＥＭＥＮＴのルート許可レベルであり、データベースの作成を含む全ての演算の許可を有する：
－ データベースの作成／ドロップ
－ 特定／複数のデータベースへのＡｄｍｉｎユーザの選任／選任解除
－ 特定／複数のデータベースからのユーザの追加／除去
－ ネットワークにわたる全てのユーザ及びユーザ情報の閲覧
－ ＤＤＬ演算の実行
－ ＤＭＬ読み出し／書き込み演算の実行
Ａｄｍｉｎ
Ａｄｍｉｎアクセスレベルは、指定されたデータベース内で最高特権を有するユーザである。Ａｄｍｉｎは、Ｓｕｐｅｒ ＡｄｍｉｎユーザによりＥＬＥＭＥＮＴデータベースに選任／登録される。Ａｄｍｉｎアクセスレベルの特権は：
－ 割り当てられたデータベースでのユーザの追加／除去
－ 割り当てられたデータベースにわたる全てのユーザ及びユーザ情報の閲覧
－ ＤＤＬ演算の実行
－ ＤＭＬ読み出し／書き込み演算の実行
備考： Ａｄｍｉｎユーザは、指定されたデータベースにより多くのＡｄｍｉｎを追加／除去することができる。
ＤＤＬ
このアクセスレベルは、ユーザがＤＭＬ演算と共に特定のＤＤＬ演算を実行できるようにする（より詳細についてはＥＬＥＭＥＮＴ ＳＱＬ仕様参照）。しかし、このアクセスレベルからのユーザの追加は許可されない及び以下。
－ 指定されたデータベース内のＥＬＥＭＥＮＴテーブル、スキーマ、及びカラム（インデックス）の作成／変更／ドロップ等のＤＤＬ演算の実行
－ ＤＭＬ読み出し／書き込み演算の実行
ＤＭＬ Ｗｒｉｔｅ
このアクセスレベルのユーザは、以下等の特定のＤＭＬ機能を実行することができる：
－ ＥＬＥＭＥＮＴテーブルでのレコードの挿入／更新／削除
－ ＬＩＭＩＴ及びＯＰＳＴＡＴ等のＥＬＥＭＥＮＴ ＳＱＬ拡張は、ＤＭＬ Ｗｒｉｔｅ演算と併せて使用することができる（ＥＬＥＭＥＮＴ ＳＱＬ仕様参照）。
ＤＭＬ Ｒｅａｄ
ＤＭＬ Ｒｅａｄアクセスレベルは、ユーザがデータを読み出せるようにする最もベーシックなアクセスである。このレベルのユーザは、データベースのいかなるデータも変更するアクセスを有さない。このアクセスレベルにおいて以下の演算を行うことができる：
－ 指定されたデータベースから種々のレコードを選択し、昇順又は降順にデータを配置する
－ ＢＯＯＫＭＡＲＫ、ＱＵＥＲＹＬＥＶＥＬ、及びＬＩＭＩＴ等のＥＬＥＭＥＮＴ ＳＱＬ拡張は、ＤＭＬ Ｒｅａｄ演算と併せて使用することができる（ＥＬＥＭＥＮＴ ＳＱＬ仕様参照）
－ 指定されたデータベース内のテーブル及びテーブル詳細の閲覧。
備考：ＣＲＥＡＴＥ及びＤＲＯＰデータベースＤＤＬ演算は、Ａｄｍｉｎアクセスレベル及びＡｄｍｉｎよりも下の全てのアクセスレベルではディセーブルされる。ユーザがこれらの演算の何れかを実行しようとする場合、ＥＬＥＭＥＮＴシステムはエラーを返すべきである－４０３：Ａｃｃｅｓｓ Ｄｅｎｉｅｄ
ユーザ登録
ＥＬＥＭＥＮＴシステム（ｖ１．０）は、招待者限定参加登録システムを有する。登録プロセスは公開されない：Ｓｕｐｅｒ Ａｄｍｉｎのみが、ＥＬＥＭＥＮＴデータベースを使用する新しいユーザを追加する特権を有する。続けて、ｓｕｐｅｒ ａｄｍｉｎはデータベースオーナー（Ａｄｍｉｎ）を割り当てることができ、データベースオーナーはその特定のデータベースに他のユーザを更に追加することができる。ＥＬＥＭＥＮＴ演算は分散型台帳ネットワーク機能を基礎とするため、ＥＬＥＭＥＮＴユーザは必ず、分散型台帳ネットワークにおけるアイデンティティの既存のプールから構築される。
ユーザ登録は、これもまたＥＬＥＭＥＮＴユーザインターフェースを介してアクセス可能であることが指定される＊Ｒｅｇｉｓｔｅｒ Ｕｓｅｒ ＥＬＥＭＥＮＴ ＡＰＩにより対処され、Ｓｕｐｅｒ Ａｄｍｉｎ及びＡｄｍｉｎアクセスレベルは、データベースへの手動アクセスを認めることができる。
Endpoint: http://:3000/api/user/register
ＡＰＩへのリクエストボディは３つの必須パラメータを含む：
１．ｕｓｅｒｎａｍｅ：メンバの一意／非既存の名前
２．ｄａｔａｂａｓｅ＿ｉｄ：既存のデータベースの名前
３．ａｃｃｅｓｓ＿ｌｅｖｅｌ：メンバのアクセス特権、このフィールドは以下の許された値を有することができる－"ＤＤＬ"、"ＤＭＬ＿ＷＲＩＴＥ"、"ＤＭＬ＿ＲＥＡＤ"、"ＡＤＭＩＮ"
ユーザ登録リクエストボディのサンプル：
｛
"username": "Matthew",
"database_id": "Customer",
"access_level": "DDL"
｝
登録に成功すると（成功レスポンス及び生じ得るエラーについてはＥＬＥＭＥＮＴ（商標）ＡＰＩ仕様ドキュメント参照）、演算を分散型台帳に記録するには、ＥＬＥＭＥＮＴ実現が必要とされる。このアクションは、ユーザ情報を指定されたデータベースのメタデータに追加する。（データベース内のユーザ名は「Ｕｓｅｒｓ」と呼ばれるアレイに保存される）。
ユーザの無効化
Ｓｕｐｅｒ Ａｄｍｉｎ及びＡｄｍｉｎアクセスレベルは、特定のユーザを特定のデータベース／複数のデータベースからディセーブルすることを選ぶことができる。これは、ネットワーク上の複数のデータベースへの選択的ユーザアクセスを可能にする。
適切な特権を有するアクセスレベルは、Ｒｅｖｏｋｅ Ｕｓｅｒ ＥＬＥＭＥＮＴ ＡＰＩを使用することによりユーザをディセーブルすることができる。
Endpoint: http://:3000/api/user/revoke
ＡＰＩへのリクエストボディは２つの必須パラメータを含む：
１．ｕｓｅｒｎａｍｅ：メンバの正確な名前
２．ｄａｔａｂａｓｅ＿ｉｄ：メンバが属する既存のデータベースの名前
ユーザ無効化リクエスト・ボディ・サンプル：
{
"username": "Matthew",
"database_id": "Customer",
}
無効化リクエストが実行されると、ｒｅｖｏｋｅＵｓｅｒ（）関数がｉｎｖｏｋｅＴｒａｎｓａｃｔｉｏｎ（）関数を通して呼び出される。ｒｅｖｏｋｅＵｓｅｒ（）関数は標的データベースから該当ユーザのメタデータを除去する。（ユーザはデータベースの「Ｕｓｅｒｓ」アレイから除去される）。
ユーザの削除
Ｓｕｐｅｒ Ａｄｍｉｎアクセスレベルは、ユーザをネットワークから完全に除去する特権を有する。これは、Ｄｅｌｅｔｅ Ｕｓｅｒ ＥＬＥＭＥＮＴ ＡＰＩを使用することにより達成することができる。
ユーザが削除された場合、関連するメタデータは、アイデンティティが属した全てのデータベースから除去される。メタデータの他に、ネットワーク上のユーザのデジタルアイデンティティも完全にクリアされる。
Endpoint: http://:3000/api/user/delete
ＡＰＩへのリクエストボディは１つの必須パラメータを含む：
１．ｕｓｅｒｎａｍｅ：メンバの正確な名前
ユーザ削除リクエスト・ボディ・サンプル
{
"username":"Matthew",
}
付録Ｃ
分散型台帳におけるリレーショナルデータ－高レベル要件
分散型台帳得及びコンセンサス
リレーショナルデータは、スマートコントラクトにアクセス可能でなければならない。
リレーショナルデータに付加された更新は、通常の分散型台帳データに付加された更新に使用されるものと同等のコンセンサスメカニズムにより支配される。
データを変更するリレーショナルデータベース演算は、分散型台帳にログされなければならない。スキーマを変更するリレーショナル演算も分散型台帳にログされなければならない。
リレーショナルデータは、可能な場合、分散型台帳内に格納されるべきであり、分散型台帳データと同レベルの不変性及びタンパーエビデンスを達成しなければならない。
リレーショナルスキーマ情報は、可能な場合、分散型台帳内に格納されるべきである。
リレーショナルインデックスは、ローカル代替が利用可能な場合、分散型台帳内に格納されるべきではない。
スキーマ及び索引付け
テーブルスキーマは、シングルフィールド一意プライマリキーをサポートする。テーブルの現在状態のプライマリキーの非クラスタリング索引付けがサポートされるべきである。
データ可視性
データ、スキーマ、及びログされた演算は、静止時又はトランスポート中、仕様「リレーショナル・データ・アクセス制御」において承認されるアイデンティティを除き、非暗号化形態では可視ではない。
データ及び演算の表現
リレーショナルデータ及びログされたリレーショナルデータ演算は、指定されたフォーマットでＪＳＯＮとして分散型台帳（又は上記と同等）で表される。
図３２は、データ及び演算オブジェクトの概説を図示する。
ＥＬＥＭＥＮＴリレーショナル・データ・オブジェクト
付録Ｄ
Figure 2022521915000002
Figure 2022521915000003
Figure 2022521915000004
Figure 2022521915000005
Figure 2022521915000006
Figure 2022521915000007
Figure 2022521915000008
Figure 2022521915000009
Figure 2022521915000010
Figure 2022521915000011
Figure 2022521915000012
Figure 2022521915000013
Figure 2022521915000014
Figure 2022521915000015
Figure 2022521915000016
Figure 2022521915000017
Figure 2022521915000018
Figure 2022521915000019
Figure 2022521915000020
Figure 2022521915000021
Figure 2022521915000022
Figure 2022521915000023
Figure 2022521915000024
Figure 2022521915000025
Figure 2022521915000026
Figure 2022521915000027
Figure 2022521915000028
Figure 2022521915000029
Figure 2022521915000030
Figure 2022521915000031
Figure 2022521915000032
Figure 2022521915000033
Figure 2022521915000034
Figure 2022521915000035
Figure 2022521915000036
Figure 2022521915000037
Figure 2022521915000038
Figure 2022521915000039
Figure 2022521915000040
Figure 2022521915000041
Figure 2022521915000042
Figure 2022521915000043
Figure 2022521915000044
Figure 2022521915000045
Figure 2022521915000046
Figure 2022521915000047
付録Ｅ
ＥＬＥＭＥＮＴ ＳＱＬ：高レベル要件
ＳＱＬクエリ入力パスウェイ
ＥＬＥＭＥＮＴ１．０実現は、以下のテーブルに概説される３つのソースからのＥＬＥＭＥＮＴ ＳＱＬを受け入れる：
Figure 2022521915000048
ＥＬＥＭＥＮＴでサポートされるＳＱＬ概念
この仕様の残りにおける暗示は、ＥＬＥＭＥＮＴ実装が、以下を含む幾つかの一般的なＳＱＬコンストラクトの均等物をサポートすることである：
カラム
データ型
識別子
ヌル値
ロー（ここではレコードとも呼ばれる）
スキーマ定義
ＳＱＬスキーマステートメント
ＳＱＬステートメント
テーブル
データ型
ＥＬＥＭＥＮにおけるデータ型－背景
ＥＬＥＭＥＮＴシステムにおけるレコードには、特定のテーブルが関連付けられる。あらゆるセル値は、ＥＬＥＭＥＮＴテーブルにおいて定義されるカラムによって決まるデータ型に属する。
ＥＬＥＭＥＮＴ ＳＱＬでは、予め定義されるデータ型の名前は予約キーワードである。データ型は既存のＳＱＬタイプから生じるが、ＥＬＥＭＥＮＴシステムは、先のＳＱＬ実装と異なるネイティブの精度及び範囲尺度で構成される。
全てのＥＬＥＭＥＮＴの予め定義されるデータ型は、原子的な性質のものであり、すなわち、値が他のデータ型の値で構成されないデータ型である。
ＥＬＥＭＥＮＴシステムは現在、３つの予め定義されるデータ型をサポートしている：
１．Ｎｕｍｂｅｒ
ＥＬＥＭＥＮＴシステムの'Ｎｕｍｂｅｒ'データ型は、全ての演算数タイプをサポートする。これは、十進値の精度もサポートするＮＵＭＥＲＩＣ型、ＩＮＴＥＧＥＲ型、及びＤＥＣＩＭＡＬ型等の馴染みのあるＳＱＬデータ型の組合せである。
'ＮＵＭＢＥＲ'はデータ型であるとともに、ＳＱＬクエリを消費している間、任意の数値を示すキーワードでもある。Ｎｕｍｂｅｒの最大長又は精度は厳密に、十進数小数のスケール又は桁を含む１６桁である。
範囲：
－９９９９９９９９９９９９９９９８～９９９９９９９９９９９９９９９８
以下の例を考慮して、Ｎｕｍｂｅｒデータ型の許容可能な範囲を決める。
Figure 2022521915000049
２．Ｓｔｒｉｎｇ
ＥＬＥＭＥＮＴシステムのＳｔｒｉｎｇデータ型は、全てのｓｔｒｉｎｇ関連値をサポートする。これは、可変長文字列型の組合せであり、ＳＱＬにおけるＴＥＸＴデータ型に類似する。
ｓｔｒｉｎｇデータ型は、全ての可変長文字列を許容する'ＳＴＲＩＮＧ'キーワードにより示される。ＥＬＥＭＥＮＴｖ１．０は固定長ｓｔｒｉｎｇをサポートしない。ＳＴＲＩＮＧデータ型のＥＬＥＭＥＮＴ実装定義範囲は、設定されたハードリミットを有さず、動作ハードウェア、接続、及び分散型台帳プラットフォーム構成等の種々の要因により定義される物理的限度がある。
ＥＬＥＭＥＮＴクエリの入力ＳＴＲＩＮＧ値はＵＴＦ－８エンコードである。ＣＥＳＵ－８及び修正ＵＴＦ－８のような代替の符号化は有効なＵＴＦ－８として扱われない。
３．Ｂｏｏｌｅａｎ
Ｂｏｏｌｅａｎデータ型の値はｔｒｕｅ又はｆａｌｓｅである。
未知のｔｒｕｔｈ値は、ヌル値で表されることもある。
ｂｏｏｌｅａｎカラムが、イネーブルされたヌル値を有する場合、ヌルは未知のｔｒｕｔｈ値を表す。
表記上の規定
このドキュメンテーションは、以下の表記及びシンタックス規定を含むバッカスナウア記法（Ｂａｃｋｕｓ－Ｎａｕｒ Ｆｏｒｍ：ＢＮＦ）の単純な変形のテキスト記述から成る：
Figure 2022521915000050
ＥＬＥＭＥＮＴのＳＱＬシンタックス用語集
標準ＳＱＬからのキーワード
ＥＬＥＭＥＮＴ１．０は、以下の標準キーワードを含むＳＱＬ言語のサブセットに、本明細書において後述する少数のＥＬＥＭＥＮＴ固有のキーワードを加えたものをサポートする：
Figure 2022521915000051
ヌルキーワード
ヌルは、キーワード及び値として使用される。
ヌルは、以下の点で他の値と異なる：
ヌル値は、レコードにデータ型'ｎｕｌｌ'を使用することにより特定のフィールドが空白又は値がないことを示すのに使用される。キーワードとしてのヌルは、空のレコードをチェックする妥当性確認としてＮＯＴ演算子と共に使用されることがある。ヌルは、カラムのデフォルト値をヌルとして設定するのにも使用される。
ヌルの値はいかなる他の値にも'等しく'なく、同様に、いかなる他の値にも'等しくない'－ヌルが任意の他の所与の値に等しいか否かは未知である。いかなる有意なデータ値もないことは、ヌルとして表すことができる。
識別子
ＥＬＥＭＥＮＴｖ１．０は、ローカル言語として英語のみをサポートし、国際化（ｉ１８ｎ）のサポートは将来のリリースで利用可能になる。２つのタイプの識別子がＥＬＥＭＥＮＴにおいて定義される：
database_name identifiers match this regular expression:
/^(?=.{1,50}$)([a-zA-Z0-9]+(-[a-zA-Z0-9]+)*)$/
識別子は、以下の正規表現に合致するｓｔｒｉｎｇである：
/^(?=.{1,50}$)([a-zA-Z0-9]+((-|_)[a-zA-Z0-9]+)*)$/
全ての識別子は最大長５０文字を有する。
識別子は以下のコンテキストで使用される：
table_name ::= identifier
column_name ::= identifier
old_column_name ::= identifier
new_column_name ::= identifier
ＥＬＥＭＥＮＴシステムは、デフォルトの名前を含む、キーワードを保有するように識別子を制限する。
データ型及び値
ＥＬＥＭＥＮＴｖ１．０は３つの予め定義されるデータ型をサポートする：上述したＳｔｒｉｎｇ、Ｎｕｍｂｅｒ、及びＢｏｏｌｅａｎ。
データ型：：＝［ＮＵＭＢＥＲ｜ＳＴＲＩＮＧ｜ＢＯＯＬＥＡＮ］
ｖａｌｕｅ：：＝
＜ｖａｌｕｅ＞（選択されたデータ型に対応）－Ｅｌｅｍｅｎｔセクションでのデータ型を参照
比較演算子
ＥＬＥＭＥＮＴ ＳＱＬにおける比較演算子は、名前が示唆するように、２つの値を比較できるようにする。等式、大なり、又は小なり等の関係式のｓｔｒｉｎｇ又はｎｕｍｂｅｒに等しい。
比較演算子のリスト：
Figure 2022521915000052
比較演算子：：＝
［＜｜＞｜＜＞｜！＝｜＞＝｜＜＝｜＝］
組合せ表現
ＥＬＥＭＥＮＴ ＳＱＬは、一般にＷＨＥＲＥ節と併用される条件キーワードを使用して２つ以上の状況データ又は選択の評価をサポートする。論理は幾つかの比較演算子と一緒に、ＥＬＥＭＥＮＴシステムにおける組合せ演算子を形成する。サポートされる組合せ演算子を以下に述べる。
ＡＬＬ
ＡＬＬ演算子は、値をサブクエリにより返された値のリスト又は１組の値と比較することによりデータをクエリする。
all_expression::=
column_name comparision_operator ALL({subquery|,,...})
ＡＮＹ
ＡＮＹ演算子は、値をサブクエリにより返された値のリスト又は１組の値と比較する。
any_expression::=
column_name comparision_operator ANY({subquery|,,...})
ＩＮ
ＩＮ演算子は、ＷＨＥＲＥ節内で使用されて、値が値のリスト中の任意の値と一致するか否かをチェックする。
in_expression::=
column_name IN ({subquery|,,...})
ＡＮＤ、ＯＲ、及びＮＯＴキーワードは、ＥＬＥＭＥＮＴ ＳＱＬの論理演算子である。これらのキーワードは大方、ＳＱＬステートメント、特にＷＨＥＲＥ節において条件を結合又は反転させるのに使用される。論理演算子のシンタックスは、他のＳＱＬコマンドの組合せを用いて更に説明される。
パターンマッチング
ＥＬＥＭＥＮＴ ＳＱＬは、正規表現ベースのｓｔｒｉｎｇパターンマッチングをサポートする。パターンは、ＬＩＫＥ演算子を使用してテーブルカラムに存在するレコード値について照合される。ＬＩＫＥ演算子は、ｓｔｒｉｎｇパターンを一致させる'等号'（＝）演算子のように働く。ＬＩＫＥ演算子と併せて使用されることが多い２つのワイルドカードがある：
％－パーセント符号はゼロ、１、又は複数の文字を表す。
＿－下線は一文字を表す。
備考：アスターリスク（＊）及びクエスチョンマーク（？）もサポートされる。
like_clause::=
column_name LIKE''
pattern::=
{|}[|][|}...
wildcard::=
{%|_|$|*|?}
サブクエリ
サブクエリは、より大きなＳＱＬクエリの内部に入れ子され、通常はＷＨＥＲＥ節内に組み込まれるＳＱＬクエリである。
サブクエリは、ＳＥＬＥＣＴ、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、若しくはＤＥＬＥＴＥステートメント内又は別のサブクエリ内に入れ子することができる。通常、別のＳＱＬ ＳＥＬＥＣＴステートメントのＷＨＥＲＥ節内に追加される。＞、＜、又は＝等の比較演算子は、ＩＮ、ＡＮＹ、又はＡＬＬ等の組合せ演算子と共にサブクエリと併用することができる。
サブクエリは内部クエリ又は内部セレクトとも呼ばれ、一方、サブクエリを含むステートメントは外部クエリ又は外部セレクトとも呼ばれる。
サブクエリのルール
－サブクエリは、メインクエリの実行前に実行される。
－サブクエリ結果は、メインクエリの入力として処理される。
－サブクエリは括弧で囲まれるが、 ＩＮＳＥＲＴの場合、サブクエリは通常のＳＥＬＥＣＴステートメントとして扱われる。
－サブクエリは、比較演算子の右側に配置される。
－サブクエリは、対応する結果を内部で操作することができず、したがって、ＯＲＤＥＲ ＢＹ節はサブクエリに追加することができない。ＯＲＤＥＲ ＢＹ節は、最後の節になるメインＳＥＬＥＣＴステートメントで使用することができる。
－ＳＱＬ演算子は、サブクエリによる影響を受けるローの数に基づいて使用されるべきである。
－サブクエリがヌル値をメインクエリに返す場合、メインクエリは、ＷＨＥＲＥ節において特定の組合せ演算子を使用している間、いかなるローも返さない。
－ＥＬＥＭＥＮＴ固有のキーワード及び拡張は、サブクエリで使用できないことがある。
サブクエリのタイプ
－シングル・ロー・サブクエリ：ゼロ又は１つのローを返す
－マルチ・ロー・サブクエリ：１若しくはそれ以上のローを返す
－マルチ・カラム・サブクエリ：１若しくはそれ以上のローを返す
－入れ子サブクエリ：サブクエリは別のサブクエリ内に配置される

サブクエリ::=
SELECT { * | | , , ... }
FROM
WHERE search_condition
[ LIMIT ]

search_condition ::=
search_clause [{ AND | OR } search_clause [ { AND | OR }
search_clause ] ... ]
search_clause::=
[ NOT ]{ comparison_clause | combination_clause | between_clause | like_clause }
comparison_clause ::=
comparision_operator { | NULL }
combination_clause ::=
{ all_expression | any_expression | in_expression }
between_clause ::=
{ ( [ NOT ] BETWEEN AND ) }
ＤＤＬコマンド
データ定義言語（ＤＤＬ）は、データベースにおいてデータベースオブジェクトの構造を作成及び変更するのに使用されるコンピュータ言語である。ＥＬＥＭＥＮＴ ＳＱＬでサポートされるデータベースオブジェクトには、スキーマ、テーブル、及びインデックスがある。以下のＤＤＬ ＳＱＬステートメントは、記載されたシンタックスを使用してＥＬＥＭＥＮＴ実装によりサポートされる。
高レベル要件で述べたように、ＤＤＬ ＳＱＬステートメントは、スマートコントラクトによる呼び出しについてサポートすることができる。
データベース作成
システムにおいて新しいデータベースを作成する
create_database_statement ::=
CREATE DATABASE database_name [ ; ]

database_name ::= Identifier
作成するデータベースの名前
テーブル作成
現在尾データベースに新しいテーブルを作成する。テーブルは複数のカラムを有することができ、各カラム定義は、名前、データ型、及び任意選択のカラム定義から成る。
create_table_statement ::=
CREATE TABLE table_name
( {column_definition}, ... )[ ; ]

column_definition ::=
column_name [ DEFAULT | NULL | NOT NULL | PRIMARY KEY ] [ ; ]

table_name ::= identifier
作成するテーブルの名前

column_name ::= identifier
カラムの名前
テーブル変更
既存のテーブルのプロパティ、カラム、又は制約を変更する。
備考：テーブル変更についてのＥＬＥＭＥＮＴ ＳＱＬグラマーは、一度に２つ以上の演算をサポートしない。このシンタックスでは、アクションキーワードは、ユーザが利用可能なテーブル変更クエリのＥＬＥＭＥＮＴによりサポートされる全ての変形を示す。
alter_table_statement ::=
ALTER TABLE table_name { action }

action ::=
{
ADD column_name [DEFAULT] |
DROP column_name |
ALTER column_name TYPE (Only applicable when table has no records) |
RENAME COLUMN old_column_name TO new_column_name
} [ ; ]

table_name ::= identifier
変更するテーブルの名前

column_name ::= identifier
変更するカラムの名前

old_column_name ::= identifier
名前変更するカラムの名前

new_column_name ::= identifier
変更後のカラムの新しい名前
テーブルドロップ
現在のデータベースからテーブルを除去する。
drop_table_statement ::=
DROP TABLE table_name [ ; ]

table_name ::= identifier
除去されるテーブルの名前
データベースドロップ
ＥＬＥＭＥＮＴシステムからデータベースを除去する。
＊備考：データベース上のデータはクリアされるが、データベースはネットワークから物理的に削除されない。データベース名は、データベースドロップ演算を使用した後であっても、一意であり、再使用することはできない。
drop_database_statement ::=
DROP DATABASE database_name [ ; ]

database_name ::= identifier
クリアするデータベースの名前
テーブル表示
ユーザがアクセス特権を有するテーブルを列挙する。コマンドは、現在／指定されたデータベースのテーブルを列挙するのに使用される。
出力は、テーブル名により辞書順に並べられたデータベースのリストを返す。
show_tables_statement ::=
SHOW TABLES [ ; ]
データベース表示
分散型台帳プラットフォームで可視であるドロップされたデータベースを含め、ユーザがアカウント全体にわたりアクセス特権を有するデータベースを列挙する。
出力は、データベース名により辞書順に並べられたデータベースのリストを返す。
show_databases_statement ::=
SHOW DATABASES [ ; ]
テーブル記述
テーブル中のカラム又は現在の値の何れか一方を記述する。クエリ記述は、選択されたテーブルの全ての詳細及びメタデータを返す。
describe_table_statement ::=
DESC [ RIBE ] [ TABLE ] table_name [ ; ]

table_name ::= identifier
記述が消されるテーブルの名前
ＤＭＬ（書き込み）コマンド
データ管理言語（ＤＭＬ）は、データベースにおいてデータを追加（挿入）、削除、及び変更（更新）するのに使用されるコンピュータプログラミング言語である。ＤＭＬは多くの場合、ＳＱＬ等のより広いデータベース言語のサブ言語であり、ＤＭＬは、ここでの場合のように、言語に演算子の幾つかを含む。以下は、データの現在状態を変更することができ、ＥＬＥＭＥＮＴ実現によりサポートされるＤＭＬ ＳＱＬ書き込みコマンドである。
レコード挿入
１若しくはそれ以上のローをテーブルに挿入することによりテーブルを更新する。テーブルの各カラムに挿入された値は明示的に指定することができる。

insert_statement ::=
INSERT INTO table_name [ column_name, column_name, ... ]
[ select_statement | subquery ]
VALUES { DEFAULT | NULL | , , ... }
[OPSTAT][ ; ]

table_name ::= identifier
データが追加されるテーブルの名前

column_name ::= identifier
データが追加されるカラムの名前
備考：ＩＮＳＥＲＴの値は必須であり、少なくとも１つのフィールド（プライマリ・キー・フィールド）は確定値を有する。残りの値は、記入されないままである場合、ＥＬＥＭＥＮＴシステムによりヌルとして見なされる。
レコード削除
データをテーブルから除去する。特定のデータはＷＨＥＲＥ節を使用して除去される。
delete_statement ::=
DELETE FROM table_name
WHERE search_condition
[ LIMIT | OPSTAT ] [ ; ]

table_name ::= identifier
レコードが除去されるテーブルの名前
レコード更新
標的テーブル中の指定されたローを新しい値で更新する。
update_statement ::=
UPDATE table_name
SET assignment
[ WHERE search_condition] [ ; ]
[ LIMIT | OPSTAT ] [ ; ]

assignment ::=
{ ( column_name = | NULL ,
[ column_name = | NULL ], ... ) }
table_name ::= identifier
変更されるテーブルの名前

column_name ::= identifier
特定のデータの比較又はサーチに使用されるカラムの名前
ＤＭＬ（読み出し）コマンド
データの読み取りのみの選択は時に、別個のデータクエリ言語（ＤＱＬ）の一環として区別されることがあるが、密に関連しており、ＤＭＬのコンポーネントと見なされることもある。以下のＱＬ ＤＭＬ読み出しコマンドは、ＥＬＥＭＥＮＴ実装によりサポートされており、シンタックスについては説明した。
ＳＥＬＥＣＴ

select_statement ::=
SELECT [ * | column_name | column_name , column_name ... ]
FROM table_name
WHERE search_condition
[ ORDER BY column_name ASC | DSC ]
[ LIMIT ]
[ QUERYLEVEL {INFO | SYSTEM }] | [ BOOKMARK ][ ; ]

table_name ::= identifier
データが読み出されるテーブルの名前

column_name ::= identifier
データが取り出されるカラム又は結果を並べるのに使用されるカラムの名前
備考：ＯＲＤＥＲ ＢＹ演算は索引付きカラムに対してのみ行うことができる。
ＳＱＬへのＥｌｅｍｅｎｔ拡張
ＥＬＥＭＥＮＴ１．０実現は、標準ＳＱＬへの拡張として以下のキーワードもサポートする。
１．ＯＰＳＴＡＴ
ＯＰＳＴＡＴは、演算が台帳に組み込まれたことの指示を追跡するリクエストである。
ＯＰＳＴＡＴが、コンソール又はＳＤＫから呼び出されたＳＱＬ ＤＭＬ書き込みクエリの末尾に追加される場合、呼び出し側は、予め構成された時間切れまでに３つのレスポンスのそれぞれ１つを受け取ることになる。３つの可能なレスポンスは以下である：

Ｉ．成功：成功レスポンスは、ＳＱＬ演算の更新が成功し、データがプラットフォームに適切な程度まで分散型台帳に組み込まれたことを意味する。
ＩＩ．失敗：失敗ステータスは、ＳＱＬコマンドが実行に成功せず、データが台帳で決して更新されなかったことを表す。
ＩＩＩ．時間切れ：ＳＱＬコマンドが予め定義された時間切れ期間を過ぎた場合、ユーザには時間切れレスポンスが返される。その時点で、クエリ結果が台帳に組み込まれたことの確認はない。
ＯＰＳＴＡＴはまた、クエリに追加されるか否かに関係なく、全てのＤＤＬ演算で仮定される。スマートコントラクトから直接実行されるクエリの場合、ＯＰＳＴＡＴは、含まれる場合、無視され、正規クエリレスポンスが代わりに返される。これは、ＥＬＥＭＥＮＴ演算がより大きなトランザクション（スマートコントラクトの呼び出し）内の１ステップであり、そのため、演算の成功又は失敗が、スマート・コントラクト・トランザクション全体の実行成功の一環としてを除き、定義されないためである。
ＯＰＳＴＡＴのシンタックスルール：
ＯＰＳＴＡＴは、有効クエリの末尾で使用され、これは、演算又は節がＯＰＳＴＡＴキーワード後に出現しないことを意味する。
ＯＰＳＴＡＴキーワードは、ＳＥＬＥＣＴ、ＵＰＤＡＴＥ、ＩＮＳＥＲＴ、及びＤＥＬＥＴＥ演算とのみ併用される。
例：
INSERT INTO sample_table[(`ABC`,`DEF`,123,false)] OPSTAT

DELETE FROM Task WHERE status = `Rejected LIMIT 50 OPSTAT
２．ＬＩＭＩＴ
ＬＩＭＩＴキーワードは、幾つかのＥＬＥＭＥＮＴ仕様ルールと併せて、従来のＳＱＬ ＬＩＭＩＴ演算と同様である。限度は、クエリにより返されるローの最大数を制約する。
ＬＩＭＩＴのシンタックスルール：
ＬＩＭＩＴは、ＳＥＬＥＣＴ、ＵＰＤＡＴＥ、及びＤＥＬＥＴＥ演算と併用される。
ＬＩＭＩＴは、更新及び削除クエリの場合、ＯＰＳＴＡＴキーワードの前に使用される。
選択クエリの場合、ＬＩＭＩＴは、ブックマーク又はクエリレベルキーワードの前に使用される。
例：
SELECT contact_id, last_name, first_name FROM contacts WHERE city = `Vienna` ORDER BY last_name ASC LIMIT 400 QUERYLEVEL SYSTEM BOOKMARK tldg213sd45sa7fd

DELETE FROM Task WHERE status = `Rejected` LIMIT 50 OPSTAT
３．クエリレベル
クエリレベル特徴は、選択されたレコードについてのメタデータ情報を提供する。ユーザは、選択クエリを用いてクエリレベルコマンドを実行した後、クエリレスポンスにおいて情報を受け取る。
この機能には２つの情報レベルがある：
１．ＩＮＦＯ：これは、ＥＬＥＭＥＮＴにより設定されるデフォルト情報レベルである。このレベルでは、ユーザにはカラム名及びそれらの各値が提供される。
２．ＳＹＳＴＥＭ：ＳＹＳ又はシステムクエリレベルは、選択されたレコードについての詳細情報を提供する。詳細なメタデータは以下等のフィールドを含む：
ａ．作成日
ｂ．最後の変更日
ｃ．作成者
ｄ．一意のｉｄ：レコードｉｄ、テーブルｉｄ
ｅ．バージョン詳細
クエリレベルのシンタックスルール：
－クエリレベルは、読み出し演算で使用され、すなわち、選択クエリとのみ使用される。
－限度キーワードの前で使用され、クエリの末尾に位置決めされる。
－クエリレベルの一はブックマークキーワードと相互交換することができる。
例：
SELECT * FROM data WHERE city = `LA` LIMIT 70 BOOKMARK nw1e83ge6ds43uia QUERYLEVEL INFO

SELECT id FROM data WHERE city = `Newark` QUERYLEVEL SYSTEM BOOKMARK erttnkel63ze9fs02vfe
４．ブックマーク
ブックマーククエリは、ＥＬＥＭＥＮＴテーブルデータのページネーションに使用される。テーブルのページサイズは、ブックマークと共に限度キーワードを使用して設定される。デフォルトにより、全てのページは、ユーザがブックマーククエリを使用することによりアクセスすることができる指定された一意のマーカを有する。クエリは、ブックマーク及びクエリレスポンスを含むオブジェクトを返す。得られたブックマークを使用して、ユーザは続くページ上のデータを閲覧／アクセスすることができる。
ブックマークのシンタックスルール：
－ブックマークキーワードは、選択クエリとのみ使用される。
－ブックマークはクエリの末尾で使用され、したがって、限度キーワードの後で使用される。
－ブックマークの位置は、クエリレベルキーワードと相互交換することができる。
例：
SELECT * FROM data WHERE id = `j3` LIMIT 70 BOOKMARK nw1e83ge6ds43uia

SELECT * FROM data WHERE city = `LA` LIMIT 70 BOOKMARK nw1e83ge6ds43uia QUERYLEVEL INFO
Figure 2022521915000053
ブックマークを用いたクエリレスポンス
５．レコードのバルク挿入
ＥＬＥＭＥＮＴは、バルク挿入特徴を使用してＥＬＥＭＥＮＴへのレコードの複数
バルク挿入演算は、複数のローが影響受ける／変更される削除及び更新クエリと非常によく似たように機能する。したがって、これらの演算での続くクエリレスポンスにおける`影響を受けるローの数'（ＥＬＥＭＥＮＴ ＡＰＩ使用－付録Ｄにおけるより詳細）フィールドは任意の数'ｎ'であることができる。
これとは対照的に、挿入コマンドは１つのローのみに対処し、したがって、挿入クエリレスポンスにおける'影響を受けるローの数'値は１に固定される。
例：
BULK INSERT INTO EventLogs
[(799021, "saf89efuew099j", 78123.912341, "MINED", null), (235235, "wqknt32il23knafs", 43534.43523, "PENDING", true), (764654, "podn4bfjs24o45sa", null, "MINED", true),
(235354, "sdglmd49wtw32r3wq", 3554.34654, "MINED", false), (533246, "235oijasfsnsafioi", 457.47334, "FAILED", false)]
Figure 2022521915000054
 バルク挿入でのクエリレスポンス
付録Ｆ
ＥＬＥＭＥＮＴ Ｎｏｄｅ．ｊｓ（登録商標）ＳＤＫ関数ドキュメンテーション
序文
Ｅｌｅｍｅｎｔの言語固有ＳＤＫは、開発者がアプリケーションコードから直接ＥＬＥＭＥＮＴ（商標）システムと対話できるようにするツールである。このドキュメントは、Ｎｏｄｅ．ｊｓ（登録商標）アプリケーションと併用されるのに開発されたＳＤＫのバージョンを詳述する。
Ｎｏｄｅ．ｊｓ（登録商標）ＳＤＫ（「ＥＬＥＭＥＮＴ＿ＳＤＫ」と呼ばれる）は、非常に単純であり、特定のユーザ及びＥＬＥＭＥＮＴデータベースでの使用に向けて構成するコンストラクタと、ＳＱＬステートメントパラメータを受け入れる関数とを含む。データベース演算自体は、ＳＱＬパラメータのシンタックスを使用して呼び出される。詳細については付録Ｅ．を参照のこと。
Ｅｌｅｍｅｎｔ＿Ｃｈａｉｎｃｏｄｅでの再使用
ファブリック実現では、Ｎｏｄｅ．ｊｓ（登録商標）はまた、分散型台帳プラットフォームを拡張するために許容される言語でもある（「システムチェーンコード」を介して）。このため、ファブリックプラットフォームでデプロイされるＥｌｅｍｅｎｔ＿ＣｈａｉｎｃｏｄｅにおいてＮｏｄｅ．ｊｓ（登録商標）ＥＬＥＭＥＮＴ＿ＳＤＫへの作業を再使用する機会があった。その結果、ＥＬＥＭＥＮＴ＿ＳＤＫは２つの類似するパッケージになった。第１のパッケージは、ＥＬＥＭＥＮＴ仕様に図示されるようにＳＤＫとして使用される。パッケージの第２のバージョンは、ＥＬＥＭＥＮＴ特徴をファブリック・ピア・ノードに追加するＥｌｅｍｅｎｔ＿Ｃｈａｉｎｃｏｄｅコンポーネントの一環としてデプロイされる。これは、ｅｘｅｃｕｔｅＱｕｅｒｙ（）関数を「ユーザチェーンコード」スマートコントラクトに提供し、ＥＬＥＭＥＮＴ仕様により求められるようなＳＱＬの使用を可能にする。
Figure 2022521915000055
Figure 2022521915000056
Figure 2022521915000057
付録Ｇ
ファブリック・サービス・レイヤ・インターフェース仕様
序文
ファブリックサービスは、ＥＬＥＭＥＮＴ１．０仕様においてプラットフォーム固有のサービスレイヤ抽象コンポーネントを実現し、ＡＰＩレイヤと分散型台帳プラットフォームとの間の対話の仲介者として働くサービス・レイヤ・インターフェースを実装する。そのサービスは、ＲＤＢＭＳ関連演算の実行に役立つ。
この付録はファブリックサービスについて詳述し、その関数シグネチャ（バルク更新等の少数のファブリック固有関数を除く）は、サービス・レイヤ・インターフェースの仕様として解釈することができる。
前提条件
Ｅｌｅｍｅｎｔ（商標）コンソールを用いてファブリックサービスをデプロイするには、以下の前提条件が要求される：
Ｎｏｄｅ８．ｘがインストールされるべきである。
ファブリックセットアップが適宜構成されるべきである。
サービス及びメソッド
Figure 2022521915000058
Figure 2022521915000059
Figure 2022521915000060
Figure 2022521915000061
Figure 2022521915000062
Figure 2022521915000063
Figure 2022521915000064
Figure 2022521915000065
Figure 2022521915000066
Figure 2022521915000067
ファブリックサービス
これらのサービスは、ファブリック分散型台帳プラットフォーム固有のサービスである。以下はサービス及びサービスのメソッドである。
Figure 2022521915000068
Figure 2022521915000069
Figure 2022521915000070
Figure 2022521915000071
付録Ｈ
ＥＬＥＭＥＮＴ（商標）パーサ：序文
Ｅｌｅｍｅｎｔパーサは、以下の方法でクエリ文字列に対処するＥＬＥＭＥＮＴ（商標）のコンポーネントである：
・有効シンタックスについてクエリをチェックする
・パーズされた抽象シンタックスツリーを返す
・クエリが無効である場合、エラーを返す
・データベースＩＤ、テーブルＩＤ、及びカラム名等の識別子が、Ｅｌｅｍｅｎｔ ＳＱＬ仕様で言及される指定されたシンタックスに従っているか否かをチェックする
・ＥＬＥＭＥＮＴ ＳＱＬ（商標）として既知のＥｌｅｍｅｎｔ固有キーワードと組み合わせて種々の既存のＳＱＬキーワードに対処
パーサは、実際のＰｏｓｔｇｒｅＳＱＬサーバソースを使用してＳＱＬクエリをパーズし、内部ＰｏｓｔｇｒｅＳＱＬパーズツリーを返す'ｐｇ－ｐａｒｓｅｒ－ｎａｔｉｖｅ'の上に実装される。
パーサは、ＳＱＬクエリをパーズして、ＥＬＥＭＥＮＴによりネイティブ分散型台帳データとしてコミットすることができるオブジェクトにすることによりリレーショナルデータに対処する好都合な方法を提供する。ＳＱＬをパーズするＥＬＥＭＥＮＴの能力により、開発者は、既に一般に理解されているシンタックスを仕様して分散型台帳においてリレーショナルデータを操作することができる。
ＥＬＥＭＥＮＴ（商標）パーサ：高レベル要件
ＥＬＥＭＥＮＴファブリック実現においてパーサの首尾よい消費を保証するには、以下の要件を満たす必要がある：
・Ｅｌｅｍｅｎｔシステムチェーンコードがアップされ、実行中であるべきである。
・Ｅｌｅｍｅｎｔコンソールをデプロイする必要がある。
・パーサはＥｌｅｍｅｎｔコンソールにＮｏｄｅ．ｊｓ（登録商標）モジュールとしてインストールされるべきである。
・システムチェーンコードがインストールされる全てのファブリックピアに存在すべきでもある。これは、システムチェーンコードがパーサにローカルにアクセスすることが可能なことを保証する。
パーサ機能の分離
実装されるＥＬＥＭＥＮＴパーサは１つの統合されたコンポーネントである。しかしながら、パーサ機能は、履行中のＥＬＥＭＥＮＴ仕様の部分に基づいて２つの部分に分割される。具体的には、ＤＤＬ及びＤＭＬコンポーネント。
ユーザクエリ／入力のＤＤＬパーズは、ＤＤＬパーサが構成要素であるＥＬＥＭＥＮＴコンソール内で実行される。コンソールは、ＤＤＬパーサの助けにより、全てのデータベース構造変更リクエストを管理する。ＤＤＬ関数をファブリックネットワーク自体内全体で利用可能することは、相当な変更なしでは可能ではなく、したがって、これらの関数はファブリックノードＪＳ実現ではアクセス可能ではない。
入力クエリのＤＭＬパーズは、ＥＬＥＭＥＮＴ特徴が追加された分散型台帳プラットフォーム内で要求される。このノードＪＳ／ファブリック実現のために、ＤＭＬパーサはＥＬＥＭＥＮＴシステムチェーンコードから機能し、したがって、しマートコントラクト（ユーザチェーンコード）にアクセス可能である。
入力タイプ
Ｅｌｅｍｅｎｔパーサは、文字列フォーマットのクエリ入力をとり、「ｐａｒｓｅＱｕｅｒｙ」と呼ばれるパーサに存在する関数を使用して呼び出される。クエリはＰｏｓｔｇｒｅｓ ＳＱＬのクエリ仕様に従う。仕様は、ＥＬＥＭＥＮＴ（商標）１．０ＥＬＥＭＥＮＴ ＳＱＬ（商標）ドキュメントに詳細に見出すことができる。クエリは、追加されたＥｌｅｍｅｎｔ固有キーワードを有し、データのよりよいハンドリングを提供する。
ＥＬＥＭＥＮＴ（商標）パーサの組成
パーサは、ユーザ・アクセス・レベルと同じラインに沿って分類される４つの関数カテゴリから成る。以下の表はこれらの関数をまとめたものである：
Figure 2022521915000072
Figure 2022521915000073
Figure 2022521915000074
Figure 2022521915000075
Figure 2022521915000076
Figure 2022521915000077
Figure 2022521915000078
Figure 2022521915000079
ＥＬＥＭＥＮＴ（商標）システムチェーンコードでのパーズ
Ｅｌｅｍｅｎｔ（商標）システムチェーンコードでのパーズは以下のステップを含む：
１．パーサはシステムチェーンコードに存在する'クエリ実行'関数により消費される。システムチェーンコード。関数がＤＭＬクエリを用いて呼び出された後、パーサはクエリをパーズしてＡＳＴオブジェクトにする。
２．オブジェクトは、Ｅｌｅｍｅｎｔ（商標）ＤＭＬ演算のビジネスルールに従って妥当性確認される。無効オブジェクトはエラーに繋がる。
３．次に、妥当性確認されたＡＳＴオブジェクトは、クエリが意図される演算に基づいてＥｌｅｍｅｎｔ（商標）システムチェーンコードに存在する関数に固有のキーを含むオブジェクトに変換される。
４．これにより、Ｅｌｅｍｅｎｔ（商標）システムチェーンコードは、入力データを更に処理し、全てのＤＭＬ演算に対処できるようになる。
ＥＬＥＭＥＮＴ（商標）コンソールでのパーズ
Ｅｌｅｍｅｎｔ（商標）コンソールでのパーズは以下のプロセスに従う：
１．Ｅｌｅｍｅｎｔ（商標）コンソールに存在する'クエリ実行'関数は、呼び出された場合、パーサを利用して入力クエリをパーズする。
２．パーサがＥｌｅｍｅｎｔ（商標）ＤＤＬ及びＤＭＬ演算のビジネスルールに従って妥当性確認すると、コンソール自体に存在する関数に固有のキーを含むオブジェクトをコンソールに返す。
３．次に、コンソールはクエリ関数に基づいてクエリを処理する。ＤＤＬの場合、コンソールの関数が呼び出され、ＤＭＬの場合、システムチェーンコードが呼び出される。
エラーへの対処
パーサは、それ自体の目的で入力クエリを妥当性確認することにより、不必要なＥＬＥＭＥＮＴ（商標）関数呼び出しを回避する。ＥＬＥＭＥＮＴ（商標）のビジネスルールを守らないデータはエラーを生じさせる。エラーは、エラーメッセージと、妥当性確認されたルールに関連するエラーコードとを含む。これは、クエリのデバッグの容易さを提供するとともに、システムがエラーに対処する方法も同様にクライアントに提供する。
Ｅｌｅｍｅｎｔパーサにおけるエラー：
Figure 2022521915000080
Figure 2022521915000081
Figure 2022521915000082
リファレンス
[1] https://www.npmjs.com/package/pg-query-native
[2] https://github.com/lfittl/libpg_query
付録Ｉ
序文
エレメントチェーンコードは、ファブリックに対して全てのデータベース関連演算を実行するためのＥＬＥＭＥＮＴ（商標）の基本コンポーネントである。クエリの形態のユーザ入力は、エレメントチェーンコードを使用して分散型台帳で処理される。エレメントチェーンコードは、特定の機能を達成するために、アイデンティティプロバイダ及びワールド・ステート・データベースに依存する。
エレメントチェーンコードは、システムチェーンコードとしてデプロイされ、ピアプロセスの一環として実行される。ユーザチェーンコードと異なり、システムチェーンコードは、ＳＤＫ又はＣＬＩからの提案を使用してインストール及びインスタンス化されず、むしろ、スタートアップ時にピアにより登録されデプロイされる。この機能は、デフォルトによってイネーブルされず、その代わり、ピアが別個に構築されることがリクエストされる。
システムチェーンコードは、Ｇｏプラグインを使用してピアに静的又は動的にリンクすることができる。しかしながら、よりよい手法は、システムチェーンコードをプラグインとしてロードして、変更がシステムチェーンコードに対して行われるときは常に、再構築が必要になるといった状況を回避することである。プラグインのロードを可能にするためには、ピアを１回だけ構築するだけでよい。
チェーンコードへのあらゆる演算はトランザクションとして処理され、一方、幾つかの演算は１組のトランザクションとして処理される必要がある。．チェーンコードは、１つのトランザクションとして演算を処理し、バッチで処理される場合、ロールバックのメカニズムを使用してトランザクションをシミュレートする。
チェーンコードへのあらゆる演算は同様のフローを辿り、一方、その実装は異なることができる。初期ステップとして、一般チェックが入力に対して実行され、任意の不一致がある場合、リクエストは返され、その影響は台帳に示されない。次に、呼び出しエンティティが、その演算を処理するのに適切なアクセスを有する（アイデンティティプロバイダにより対処される）場合のみ、リクエストは転送される。
各呼び出しエンティティへのアクセスは、その証明書を使用してチェックされる。登録時、そのデータベースに関する適切な属性が証明書に追加される。続く各リクエスト時、チェックが実行される。エンティティがその演算へのアクセス特権を有する場合のみ、該当リクエストは処理され、エンティティにその演算を実行する許可が認められる。
大まかに、チェーンコードへの演算はデータ定義言語（Ｄａｔａ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ：ＤＤＬ）及びデータ操作言語（Ｄａｔａ Ｍａｎｉｐｕｌａｔｉｏｎ Ｌａｎｇｕａｇｅ：ＤＭＬ）として分類することができる。ＤＤＬ演算はチェーンコードでパーズされないため、チェーンコードは別のチェーンコードを介してＤＤＬ演算アクセスを制限する。したがって、あらゆるリクエストの開始時、ＥＬＥＭＥＮＴシステムは、トランザクション提案を使用して、チェーンコードに対して直接呼び出しが行われるか否かをチェックする。トランザクションが別のソースからのものである場合、任意のチェーンコード演算（ＤＤＬ）へのアクセスは阻止される。
ＤＭＬ演算では、クエリは入力として直接送ることができる。次に、あらゆるクエリはパーサに送られ、対応する演算はパーサからの応答に基づいて呼び出される。チェーンコードの各態様の実装についての更なる詳細情報は以下のセクションで与えられる。
前提条件
以下の前提条件が、エレメントチェーンコードの登録及びデプロイに必須である：
ファブリックネットワークが実行中であるべきである。
ピアは、「ｐｌｕｇｉｎｓｅｎａｂｌｅｄ」という名前のビルドタグを使用して構築される必要がある。
デプロイ
ユーザチェーンコードと異なり、システムチェーンコードは、ＳＤＫ又はＣＬＩの提案を使用してインストール及びインスタンス化されない。システムチェーンコードは、スタートアップ時にピアにより登録されデプロイされる。この機能は、デフォルトによりイネーブルされず、代わりに、ピアが「ｐｌｕｇｉｎｓｅｎａｂｌｅｄ」という名前のビルドタグを使用して構築されることがリクエストされる。
システムチェーンコードは、２つの方法でピアにリンクすることができる。
静的に－静的の場合、チェーンコードをピアプロセスの一環として構築するために、手法は、チェーンコードに｀ＳｅｌｆＤｅｓｃｒｉｂｉｎｇＳｙｓＣＣ｀インターフェース［１］を実装させ、そのインスタンスをピア・スタートアップ・ファイルに登録する［２］。それに続き、ピアは、この変更されたコードを使用して構築される必要がある。
動的に－システムチェーンコードをプラグインとしてロードするほうがよい。この方法では、変更がチェーンコードに対して行われる津度、ピアを再構築する必要がない。プラグインをイネーブルするために、ピアは１回構築されるだけでよい。
デプロイステップ－
システムチェーンコードをｇｏに書き込む
－ｂｕｉｌｄｍｏｄｅ＝ｐｌｕｇｉｎビルドフラグを使用してこのｇｏプラグインをコンパイルして、共有オブジェクト（．ｓｏ）ライブラリファイルを生成する。
go build-buildmode=plugin-o.so.go
ピアを構築して、ＧＯをロードできるようにする：
ＤＯＣＫＥＲ＿ＤＹＮＡＭＩＣ＿ＬＩＮＫ＝ｔｒｕｅ ＧＯ＿ＴＡＧＳ＋＝"ｐｌｕｇｉｎｓｅｎａｂｌｅｄ"はピアドッカーを作成する
備考－ｇｏプラグインをファブリックバージョンのｇｏバージョンと同じｇｏバージョンに構築することを想起する。
形成されたドッカーイメージを使用してネットワークを開始する。
プラグインファイル及び．ｓｏファイルをドッカーピアにコピーする。
システムチェーンコード及びその情報をピアの構成ファイル（ｃｏｒｅ．ｙａｍｌ）に追加する。
ピアを再起動する。
ＲＥＦＥＲＥＮＣＥＳ
https://github.com/hyperledger/fabric/blob/release-1.3/core/scc/sysccapi.go#L78
https://github.com/hyperledger/fabric/blob/release-1.3/peer/node/start.go#L549
メソッド
Ｉｎｉｔ（）
Ｉｎｉｔは、チェーンコード登録中に呼び出される。このメソッドは、ｃｏｎｆｉｇをロードし、他の全てのメソッドで使用されるグローバル変数を初期化するのに使用される。
Ｎｅｗ（）
このメソッドは、チェーンコードインターフェースの実装を返すため、動的にリンクされたあらゆるチェーンコードに存在しなければならない。チェーンコードインターフェースは、全てのメソッドをカプセル化し、ピアプロセスの一環として実行されるようにそれらを転送する。
Ｉｎｖｏｋｅ（）
このメソッドは、チェーンコードにおいてトランザクションを実行するのに使用される。これは、チェーンコードのＡＰＩとファブリックピアとの間の交信ポイントとして働く。呼び出しエンティティはｉｎｖｏｋｅメソッドを呼び出して、チェーンコードの任意の他のメソッドを処理する。呼び出しエンティティが適切なアクセスを有し、入力が文字列化ＪＳＯＮとして正しく形成されているか否かをチェックした後。リクエストは、ｉｎｖｏｋｅが呼び出すことが意図される対応するメソッドに中継される。
ＣｒｅａｔｅＤａｔａｂａｓｅ（）
このメソッドは、データベース作成開始時に呼び出される。リクエストは、その特定のデータベースに適切なメタデータを生成することにより処理される。このメタデータは、チェーンコードの他の全てのメソッドにより消費される。
ＤｒｏｐＤａｔａｂａｓｅＭｅｔａ（）
このメソッドは、ユーザのバッチ演算として処理されるデータベースの削除を開始するのに呼び出される。このメソッドは、プロセスの開始をマークし、そのデータベースに存在する全てのテーブルのリストを返す。これに続き、テーブルのメタデータ及び全てのそのレコードを削除する特定の呼び出しが行われる。
ＤｒｏｐＤａｔａｂａｓｅＣｏｍｍｉｔ（）
このメソッドは、バッチ中の全てのリクエストの処理に成功した後、データベース削除の仕上げの呼び出しとして働く。
ＲｅｇｉｓｔｅｒＵｓｅｒ（）
このメソッドは、新しいユーザをデータベースに追加するのに使用され、属性の証明書への追加に続く。
管理者特権を有するユーザのみが他のユーザを追加することができ、したがって、呼び出しエンティティの適切なアクセスをチェックした後、リクエストにおいて与えられたユーザアイデンティティはデータベースメタデータに追加される。
ＤｅｌｅｔｅＵｓｅｒ（）
このメソッドはデータベースからユーザを削除するのに使用され、証明書からの属性の除去に続く。
管理者特権を有するユーザのみが他のユーザを削除することができ、したがって、呼び出しエンティティの適切なアクセスをチェックした後。リクエストにおいて与えられるユーザはデータベースメタデータから削除される。
ＣｒｅａｔｅＴａｂｌｅ（）
このメソッドは、新しいテーブルを作成し、既存のデータベースに追加するのに使用される。まず、チェックが実行されて、現在のデータベースがアイドル状態ではないことを確認する。それに続き、ＥＬＥＭＥＮＴシステムは、テーブルがデータベースに既に存在するか否かをチェックする。これらの確認と共に、入力データが一貫している場合、テーブルメタデータが形成され、台帳に追加される。テーブル情報もデータベースメタデータに追加される。テーブルメタデータは、そのテーブルで実行された全ての演算の確認に使用される。
ＤｒｏｐＴａｂｌｅＭｅｔａ（）
このメソッドは、ユーザのバッチ演算として処理されるテーブルの削除を開始するのに呼び出される。このメソッドは、プロセスの開始をマークし、そのテーブルへの他の演算を制限するようにＤＤＬフラグを設定する。
ＤｒｏｐＴａｂｌｅＲｅｃｏｒｄｓ（）
このメソッドは、そのテーブルのレコードを削除するのに使用される。これは、指定されたテーブルレコードに対して削除演算を再帰的に実行する。削除はレコードのバッチに対して実行され、一方、バッチのサイズは構成可能である。これは、トランザクションの時間限度を超えるのを避けるために行われる。
ＤｒｏｐＴａｂｌｅＣｏｍｍｉｔ（）
このメソッドは、バッチ中の全てのリクエストの処理に成功した後、テーブル削除の仕上げの呼び出しとして働く。呼び出しエンティティからのコールは、このプロセスの完了を示すために行われる。全ての中間トランザクションＩＤは、ユーザに１つのトランザクションＩＤを返すことができるように台帳に格納される。それに続き、そのテーブルのメタデータは削除され、テーブル名は、将来の演算での新しいテーブルの作成に再使用することができる。
ＡｌｔｅｒＴａｂｌｅＭｅｔａ（）
このメソッドは、テーブルの構造の変更を開始するのに呼び出される。これはバッチ演算として処理される。このメソッドは、プロセスの開始をマークし、そのテーブルへの他の演算を制限するようにＤＤＬフラグを設定する。リクエストにおいて与えられる入力を使用して、Ｅｌｅｍｅｎｔシステムは、そのテーブルの全てのレコードの更新に使用されることになる更新テンプレートを形成する。その更新テンプレートは応答において返される。
ＡｌｔｅｒＴａｂｌｅＲｅｃｏｒｄｓ（）
このメソッドは、そのテーブルのレコードを変更するのに使用される。これは、テーブルに存在する全てのレコードを変更する。Ａｌｔｅｒはレコードのバッチに対して実行され、一方、バッチのサイズは構成可能である。これは、トランザクションの時間限度を超えるのを避けるために行われる。
ＡｌｔｅｒＴａｂｌｅＣｏｍｍｉｔ（）
このメソッドは、バッチ中の全てのリクエストの処理に成功した後、テーブル変更の仕上げの呼び出しとして働く。呼び出しエンティティからのコールは、このプロセスの完了を示すために行われる。全ての中間トランザクションＩＤは、ユーザに１つのトランザクションＩＤを返すことができるように台帳に格納される。それに続き、そのテーブルについてのリクエストを再び行うことができる。
ＩｎｓｅｒｔＲｅｃｏｒｄ（）
このメソッドは、レコードをテーブルに追加するのに使用される。テーブルに追加されるあらゆるレコードは、そのテーブルを作成したときに設定されたルールに準拠しなければならない。したがって、各リクエスト時、まず、テーブルメタデータ中の制約に基づいてカラム値を追加することができるか否かがチェックされる。このメソッドには、呼び出しエンティティがカラムを渡す変形及びカラム名が省かれる変形という２つの変形がある。両変形の処理は同様であり、カラム名が省かれる場合のみ、カラム名がテーブルメタデータから取り出される。レコードが全てのチェック及び確認に合格した場合、レコードは台帳に追加され、プライマリキー値はレコードＩＤとして設定される。
ＵｐｄａｔｅＲｅｃｏｒｄ（）
このメソッドは、テーブルの既存のカラムの値を更新するのに使用される。レコードに対して行われたあらゆる更新はなお、テーブルメタデータにおいて設定された制約に準拠しなければならない。したがって、各リクエスト時、前のレコードデータが台帳から取り出され、意図される変更がレコードに対して行われる。レコードが全てのチェック及び妥当性確認に合格した場合、レコードＩＤは変わらないままで台帳において更新される。
備考－レコードを更新している間、プライマリキー値を更新することはできない。
ＤｅｌｅｔｅＲｅｃｏｒｄ（）
このメソッドは、テーブルから先に存在していたレコードを削除するのに使用される。レコードが存在し、テーブルがいかなるＤＤＬプロセス下でもない場合、レコードは台帳から削除される。その効果は、トランザクションがコミットされるとすぐに見られる。
ＣｒｅａｔｅＩｎｄｅｘ（）
このメソッドは、呼び出しエンティティが、インデックスを既存のカラムに追加したい場合、使用される。まず、リクエストが、索引付けを所与のカラムに対して実行することができるか否かについてチェックされる。それに続き、インデックスは状態データベースに追加される必要がある。この機能はファブリックには元々は存在せず、したがって、状態データベースにおいて、所与のカラムのインデックスを追加する別個のリクエストが行われる必要がある。
ＤｅｌｅｔｅＩｎｄｅｘ（）
このメソッドは、呼び出しエンティティが既存のカラムにおけるインデックスを削除したい場合、使用される。まず、リクエストが、索引付けを所与のカラムに対して実行することができるか否かについてチェックされる。それに続き、前に作成されたインデックスは状態データベースから削除される。
ＳｅｌｅｃｔＱｕｅｒｙＷｉｔｈＰａｇｉｎａｔｉｏｎ（）
このメソッドは、状態データベースで所与のクエリを実行するのに使用される。結果は、意図されるクエリレベルに基づいて呼び出しエンティティに返される。このメソッドは読み出し演算のみを実行し、したがって、台帳に影響しない。呼び出しエンティティが限度を指定しない場合、デフォルト限度が採用されて、トランザクションが時間を超えて実行されるのを回避する。
ＢｕｌｋＩｎｓｅｒｔＲｅｃｏｒｄ（）
このメソッドは、挿入演算をバッチに対して実行するのに使用される。挿入演算は全てのレコードに対して実行され、それらの何れか１つが失敗する場合、台帳に影響することなくバッチは返される。挿入された全てのレコードは、カラム値がテーブルメタデータにおいて設定された制約を満たす場合のみ、追加されるべきである。
ＢｕｌｋＵｐｄａｔｅＲｅｃｏｒｄ（）
このメソッドは、更新演算をバッチで実行するのに使用される。更新演算は、クエリを状態データベースに対して実行した後で取得されるバッチ中の全てのレコードに対して実行される。それらの何れか１つが失敗する場合、台帳に影響することなくバッチは返される。更新された全てのレコードは、テーブルメタデータにおいて設定される制約に準拠すべきである。
ＢｕｌｋＤｅｌｅｔｅＲｅｃｏｒｄ（）
このメソッドは、削除演算をバッチで実行するのに使用される。再帰的に、削除演算は、クエリを状態データベースに対して実行した後で取得されるバッチ中の全てのレコードに対して実行される。それらの何れか１つが失敗する場合、台帳に影響はない。
ＲｏｌｌｂａｃｋＴｒａｎｓａｃｔｉｏｎ（）
幾つかの演算は、呼び出しエンティティには１つのトランザクションとして見える１組のトランザクションとして処理される必要がある。それらの何れか１つが処理されない場合、先の全てのトランザクションは元に戻る必要がある。したがって、各メソッドにおいて、ロールバックのメタデータがキュレートされ、このメソッドは、所与のトランザクションＩＤを有する先のあらゆるトランザクションを元に戻すのに使用される。
ＤｅｌｅｔｅＴｒａｎｓａｃｔｉｏｎＭｅｔａ（）
幾つかの演算は、呼び出しエンティティには１つのトランザクションとして見える１組のトランザクションとして処理される必要がある。それらの何れか１つが処理されない場合、先の全てのトランザクションは元に戻る必要がある。したがって、各メソッドにおいて、ロールバックのメタデータがキュレートされる。全てのトランザクションの処理に成功した場合、このメソッドは、所与のトランザクションＩＤについてのメタデータを削除するのに使用される。
ＥｘｅｃｕｔｅＱｕｅｒｙ（）
このメソッドは、チェーンコードでＤＭＬクエリを実行するのに使用される。リクエスト中のクエリはパーサに送られ、パーサからの出力は、対応するメソッドの処理に使用される。そのメソッドへの呼び出しエンティティのアクセスをチェックした後。リクエストは適切なメソッドに中継される。
ＳｈｏｗＤａｔａｂａｓｅｓ（）
このメソッドは、任意の呼び出しエンティティがアクセスすることができる全てのデータベースを列挙するのに使用される。全てのデータベースは、呼び出しエンティティの証明書において言及され、したがって、呼び出しエンティティの証明書を使用して、全てのデータベースの名前をフェッチして返す。
ＳｈｏｗＴａｂｌｅｓ（）
このメソッドは、データベース中の全てのテーブルを列挙するのに使用される。全てのテーブルはデータベースメタデータにおいて言及され、したがって、データベースメタデータをフェッチし、全てのテーブルのリストを返す。
ＤｅｓｃＴａｂｌｅ（）
このメソッドは、テーブル作成時、全ての制約を取得するのに使用される。テーブルメタデータは、全てのカラムの制約を含む。したがって、リクエストが作成される場合、テーブルメタデータは、内部情報を削除した後、返される。
一方、分散型台帳技術（ＤＬＴ）は、今世紀の情報技術革命に相当するものに火をつけ、可能にする可能性を秘めている。分散型台帳技術は、インターネットの最大かつ最も厄介な課題の1つである信頼の欠如に取り組み、解決している。分散型台帳技術は、初期のしかし強力な分散コンピューティングパラダイムであり、実用的な目的でデータを変更不可能にすることでインターネットに信頼をもたらす可能性がある、これまでで唯一のテクノロジーである。残念ながら、既存のＲＤＢＭＳプラットフォームとツールは、分散型台帳技術の制約と互換性がない。その結果、データがプログラムに密接にリンクされているプログラム/データの固定化は、１９６０年代のリレーショナルデータベース以前のプログラムよりも、分散型台帳のスマートコントラクトの方がさらに大きくなる。分散型台帳のデータが、開発者の特定の意図である場合にのみ、展開されたスマートコントラクトの詳細に固定されるシステムと方法が望まれる。
この出願の発明に関連する先行技術文献情報としては、以下のものがある（国際出願日以降国際段階で引用された文献及び他国に国内移行した際に引用された文献を含む）。
（先行技術文献）
（特許文献）
（特許文献１） 米国特許出願公開第２０ｌ９／０２３８５２５号明細書
（特許文献２） 米国特許出願公開第２０ｌ９／０１７９９３９号明細書
（特許文献３） 米国特許出願公開第２０ｌ９／０１５８５９４号明細書
（特許文献４） 米国特許出願公開第２０ｌ９／０２３６０８１号明細書

Claims (43)

  1. リレーショナルデータベース管理クエリを使用して、トランザクションデータを含む分散型台帳を実装する分散型台帳プラットフォームをクエリする方法であって、
    前記分散型台帳プラットフォームの少なくとも１つのプロセッサにより、前記分散型台帳にデータベースを作成し、前記分散型台帳に前記データベースに関する情報を記録する工程と、
    前記少なくとも１つのプロセッサにより、受信したリレーショナルデータベース管理クエリを、前記分散型台帳のデータベースで処理可能なクエリ操作に変換する工程と、
    前記少なくとも１つのプロセッサにより、クエリ結果を生成するために、前記分散型台帳のデータベースに対して前記クエリ操作を実行する工程と、
    前記少なくとも１つのプロセッサにより、前記クエリ結果を、前記分散型台帳に含めるために前記分散型台帳のデータベースによって処理可能な形式で当該データベースにログする工程と
    を有する方法。
  2. 請求項１記載の方法において、さらに、
    前記少なくとも１つのプロセッサにより、前記リレーショナルデータベース管理クエリを、（１）ユーザインターフェースを介したユーザ、（２）アプリケーションプログラムインターフェイスを介したユーザーアプリケーション、および（３）スマートコントラクトのうちの１つからの構造化照会言語（ＳＱＬ）として生成する工程を有するものである方法。
  3. 請求項２記載の方法において、前記スマートコントラクトが、前記分散型台帳の前記データベースのリレーショナルデータベース管理クエリの少なくともサブセットのＳＱＬクエリを実行するものである方法。
  4. 請求項２記載の方法において、さらに、
    前記少なくとも１つのプロセッサにより、ＳＱＬデータ操作言語（ＳＱＬ ＤＭＬ）書き込み操作、ＳＱＬＤＭＬ読み取り操作、およびＳＱＬデータ定義言語（ＳＱＬ ＤＤＬ）操作のうちの１つを有するＳＱＬ操作に前記ＳＱＬクエリを解析する工程と、前記ＳＱＬ操作および前記ＳＱＬ操作に含まれる任意のリレーショナルデータのＪａｖａ（登録商標）ＳｃｒｉｐｔＯｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）表現を作成する工程とを有するものである方法。
  5. 請求項４記載の方法において、さらに、
    前記少なくとも１つのプロセッサにより、前記ＳＱＬ操作の実行から生じるトランザクションが、プラットフォームに関連する範囲で前記分散型台帳への受け入れに向かって進行したかどうかを決定する工程を有するものである方法。
  6. 請求項５記載の方法において、さらに、
    前記少なくとも１つのプロセッサにより、対応するトランザクションのより明確なステータスをフェッチするために、前記ＤＭＬ書き込み操作の最後にｏｐｅｒａｔｉｏｎ ｂｒｏａｄｃａｓｔ ｓｔａｔｕｓ（ＯＰＳＴＡＴ）命令を追加する工程を有するものである方法。
  7. 請求項４記載の方法において、前記分散型台帳で前記クエリ操作を実行する工程は、前記少なくとも１つのプロセッサにより、前記ＳＱＬクエリを呼び出すエンティティが前記ＳＱＬ操作を実行する権限を有することを確認する工程を有するものである方法。
  8. 請求項４記載の方法において、前記分散型台帳で前記ＳＱＬクエリ操作を実行する工程は、前記少なくとも１つのプロセッサにより、前記クエリ操作のＪＳＯＮ表現、および前記分散型台帳で処理および格納することができるクエリ操作の結果を作成する工程を有するものである方法。
  9. 請求項８記載の方法において、前記ＳＱＬ操作はＳＱＬ ＤＭＬ書き込み操作であり、当該ＳＱＬ操作は、さらに、
    前記少なくとも１つのプロセッサにより、前記ＳＱＬ ＤＭＬ書き込み操作を実行するために必要に応じて前記分散型台帳からデータを取得する工程と、
    前記少なくとも１つのプロセッサにより、前記取得したデータを含む前記ＳＱＬ ＤＭＬ書き込み操作を実行する工程と、
    前記少なくとも１つのプロセッサにより、前記クエリ結果における新規または更新された任意の記録のＪＳＯＮ表現を準備する工程と、
    前記少なくとも１つのプロセッサにより、前記ＳＱＬ ＤＭＬ書き込み操作および前記任意の更新された記録を、前記分散型台帳に含めるために前記分散型台帳のデータベースによって処理可能な形式で前記分散型台帳にコミットする工程と
    を有するものである方法。
  10. 請求項９記載の方法において、さらに、
    前記少なくとも１つのプロセッサにより、前記分散型台帳への受け入れに向けた前記ＳＱＬ ＤＭＬ書き込み操作の進行状況に関して、前記分散型台帳を監視する工程と、
    前記少なくとも１つのプロセッサにより、前記ＳＱＬクエリを呼び出すエンティティに対して、前記ＳＱＬ ＤＭＬ書き込み操作がプラットフォームに関連する範囲で前記分散型台帳への受け入れに向けて進行したかどうかを通知する工程と
    を有するものである方法。
  11. 請求項８記載の方法において、前記ＳＱＬ操作はＳＱＬ ＤＭＬ読み取り操作であり、当該ＳＱＬ操作は、さらに、
    前記少なくとも１つのプロセッサにより、前記ＳＱＬ ＤＭＬ読み取り操作を実行するために必要に応じて前記分散型台帳からデータを取得する工程と、
    前記少なくとも１つのプロセッサにより、前記取得したデータを含む前記ＳＱＬ ＤＭＬ読み取り操作を実行する工程と、
    前記少なくとも１つのプロセッサにより、前記クエリ結果のＪＳＯＮ表現を準備する工程と、
    前記少なくとも１つのプロセッサにより、前記クエリ結果の前記ＪＳＯＮ表現を、前記分散型台帳に含めるために前記分散型台帳のデータベースによって処理可能な形式で前記分散型台帳にログする工程と
    を有するものである方法。
  12. 請求項１１記載の方法において、さらに、
    前記少なくとも１つのプロセッサにより、前記クエリ結果のＪＳＯＮ表現を前記ＳＱＬクエリを呼び出すエンティティに返す工程を有するものである方法。
  13. 請求項１記載の方法において、さらに、
    前記少なくとも１つのプロセッサにより、チャネルを作成し、前記データベースのコピーおよび前記データベースに関するメタデータを書き込む通常のトランザクションを維持するピアコンピューターを定義する構成トランザクションを実行して、前記分散型台帳内に前記データベースを作成する工程と、
    前記少なくとも１つのプロセッサにより、前記分散型台帳のトランザクションデータを定義するコードと、前記トランザクションデータを変更するためのトランザクション命令を作成する工程と
    を有するものである方法。
  14. 請求項１３記載の方法において、さらに、
    前記少なくとも１つのプロセッサにより、前記分散型台帳の前記トランザクションデータとしてＪａｖａ（登録商標）ＳｃｒｉｐｔＯｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）で前記データベースの属性を定義するコードを作成する工程と、
    前記少なくとも１つのプロセッサにより、前記データベースを前記データベースの属性で更新する工程と
    を有するものである方法。
  15. 請求項１記載の方法において、さらに、
    前記少なくとも１つのプロセッサにより、前記分散型台帳に含めるために、前記分散型台帳上のデータベースによって処理可能な形式を説明する、解析および変換された構造化照会言語（ＳＱＬ）クエリを作成する工程を有するものである方法。
  16. 請求項１記載の方法において、前記リレーショナルデータベース管理クエリはスマートコントラクトから受信され、前記受信したリレーショナルデータベース管理クエリは、前記分散型台帳の前記データベースによって処理されることができる分散型台帳トランザクションに変換され、および前記分散型台帳の前記分散型台帳トランザクションがトランザクション結果を生成するために実行されるものであり、さらに、
    少なくとも１つのプロセッサにより、前記トランザクション結果を前記スマートコントラクトに返す工程を有するものである方法。
  17. 請求項１６記載の方法において、さらに、前記スマートコントラクトは、ＤＤＬデータベース操作およびスキーマ変更を除く前記分散型台帳のデータ定義言語（ＤＤＬ）操作を実行することにより前記スマートコントラクトを前記分散型台帳の前記データベースと統合するものである工程を有するものである方法。
  18. 請求項１７記載の方法において、さらに、チェーンコードで前記分散型台帳の前記データベース、前記スマートコントラクトの少なくとも１つの資産を定義する前記チェーンコード、および少なくとも１つの資産を変更するための少なくとも１つのトランザクション命令、のデータベース関連操作を実装する工程を有するものである方法。
  19. 請求項１８記載の方法において、前記スマートコントラクトを前記分散型台帳の前記データベースと統合することは、前記チェーンコードを呼び出す前記スマートコントラクトを有するものである方法。
  20. 請求項１８記載の方法において、さらに、前記チェーンコードからデータ操作言語（ＤＭＬ）読み取り操作を開始する前記スマートコントラクトを有するものである方法。
  21. 請求項１６記載の方法において、さらに、データ操作言語（ＤＭＬ）クエリの実行、前記分散型台帳への前記データベースの作成、前記分散型台帳の前記データベースへのアクセス権の更新、またはデータ定義言語（ＤＤＬ）クエリの実行を含む少なくとも１つの操作を実行する前記スマートコントラクトを有するものである方法。
  22. システムであって、
    トランザクションデータを含む分散型台帳を実装する分散型台帳プラットフォームと、
    前記分散型台帳のデータベースと、
    リレーショナルデータ管理および編成システムを実装するための命令を実行する少なくとも１つのプロセッサであって、このリレーショナルデータ管理および編成システムは、
    前記分散型台帳のデータベースに関する情報を記録する工程と、
    受信したリレーショナルデータベース管理クエリを、前記分散型台帳のデータベースによって処理可能なクエリ操作に変換する工程と、
    クエリ結果を生成するために、前記分散型台帳のデータベースに対して前記クエリ操作を実行する工程と、
    前記クエリ結果を、前記分散型台帳に含めるために前記分散型台帳のデータベースによって処理可能な形式で当該データベースにログする工程と
    を実行するものである、
    前記少なくとも１つのプロセッサと
    を有するシステム。
  23. 請求項２２記載のシステムにおいて、さらに、
    構造化照会言語（ＳＱＬ）クエリとして前記リレーショナルデータベース管理クエリを生成する手段を有し、この手段は、（１）ユーザーが前記ＳＱＬクエリを提供するための前記リレーショナルデータ管理および前記編成システムに対するユーザーインターフェイス、（２）前記リレーショナルデータ管理および前記編成システムのアプリケーションプログラムインターフェイスを介して前記リレーショナルデータ管理および前記編成システムに前記ＳＱＬクエリを渡すユーザーアプリケーション、および（３）スマートコントラクトのうちの１つを有するものであるシステム。
  24. 請求項２３記載のシステムにおいて、前記スマートコントラクトは、前記分散型台帳の前記データベースのリレーショナルデータベース管理クエリのＳＱＬクエリの少なくともサブセットを実行するものであるシステム。
  25. 請求項２３記載のシステムにおいて、前記少なくとも１つのプロセッサは、さらに、
    ＳＱＬデータ操作言語（ＳＱＬ ＤＭＬ）書き込み操作、ＳＱＬＤＭＬ読み込み操作、およびデータ定義言語（ＳＱＬ ＤＤＬ）操作のうちの１つを有する前記ＳＱＬクエリをＳＱＬ操作に解析し、
    前記ＳＱＬ操作および前記ＳＱＬ操作に含まれる任意のリレーショナルデータのＪａｖａ（登録商標）ＳｃｒｉｐｔＯｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）表現を作成するための、命令を実行するものであるシステム。
  26. 請求項２５記載のシステムにおいて、さらに、前記少なくとも１つのプロセッサは、前記ＳＱＬ操作の実行から生じるトランザクションがプラットフォームに関連する範囲で前記分散型台帳への受け入れに向かって進行したかどうかを決定するための命令を実行するものであるシステム。
  27. 請求項２６記載のシステムにおいて、さらに、前記少なくとも１つのプロセッサは、対応するトランザクションのより明確なステータスをフェッチするために、前記ＤＭＬ書き込み操作の最後にｏｐｅｒａｔｉｏｎ ｂｒｏａｄｃａｓｔ ｓｔａｔｕｓ（ＯＰＳＴＡＴ）命令を追加する命令を実行するものであるシステム。
  28. 請求項２５記載のシステムにおいて、前記少なくとも１つのプロセッサは、前記ＳＱＬクエリを呼び出すエンティティが前記ＳＱＬ操作を実行する権限を持っていることを確認する命令を実行することによって、前記分散型台帳で前記クエリ操作を実行するものであるシステム。
  29. 請求項２５記載のシステムにおいて、前記少なくとも１つのプロセッサは、さらに、前記クエリ操作のＪＳＯＮ表現と、前記分散型台帳に処理および格納することができる前記クエリ操作の結果を作成するための命令を実行するものであるシステム。
  30. 請求項２９記載のシステムにおいて、
    前記ＳＱＬ操作はＳＱＬ ＤＭＬ書き込み操作であり、
    前記少なくとも１つのプロセッサは、さらに、
    前記ＳＱＬ ＤＭＬ書き込み操作を実行するために必要に応じて前記分散型台帳からデータを取得し、
    前記取得したデータを含む前記ＳＱＬ ＤＭＬ書き込み操作を実行し、
    前記クエリ結果における新規または更新された任意の記録のＪＳＯＮ表現を準備し、
    前記ＳＱＬ ＤＭＬ書き込み操作および前記更新された任意の記録を前記分散型台帳に含めるために前記分散型台帳のデータベースによって処理可能な形式で前記分散型台帳にコミットするための、命令を実行するものであるシステム。
  31. 請求項３０記載のシステムにおいて、前記少なくとも１つのプロセッサは、さらに、
    前記分散型台帳への受け入れに向けた前記ＳＱＬ ＤＭＬ書き込み操作の進行に関して前記分散型台帳を監視し、
    前記ＳＱＬクエリを呼び出すエンティティに対して、前記ＳＱＬ ＤＭＬ書き込み操作がプラットフォームに関連する範囲で前記分散型台帳への受け入れに向けて進行したかどうかを通知するための、命令を実行するものであるシステム。
  32. 請求項２９記載のシステムにおいて、
    前記ＳＱＬ操作はＳＱＬ ＤＭＬ読み取り操作であり、
    前記少なくとも１つのプロセッサは、さらに、
    前記ＳＱＬ ＤＭＬ読み取り操作を実行するために必要に応じて前記分散型台帳からデータを取得し、
    前記取得したデータを含む前記ＳＱＬ ＤＭＬ読み取り操作を実行し、
    前記クエリ結果のＪＳＯＮ表現を準備し、
    前記分散型台帳への前記クエリ結果の前記ＪＳＯＮ表現を、前記分散型台帳に含めるために前記分散型台帳のデータベースによって処理可能な形式でログするための、命令を実行するものであるシステム。
  33. 請求項３２記載のシステムにおいて、前記少なくとも１つのプロセッサは、さらに、前記ＳＱＬクエリを呼び出すエンティティに前記クエリ結果の前記ＪＳＯＮ表現を返すための命令を実行するものであるシステム。
  34. 請求項２２記載のシステムにおいて、前記少なくとも１つのプロセッサは、
    チャネルを作成し、前記データベースのコピーおよび前記データベースに関するメタデータを書き込む通常のトランザクションを維持するピアコンピュータを定義する構成トランザクションを実行することにより前記分散型台帳内に前記データベースを作成し、
    前記分散型台帳にトランザクションデータおよび前記トランザクションデータを変更するためのトランザクション命令を定義するコード作成するための、命令を実行するものであるシステム。
  35. 請求項３４記載のシステムにおいて、前記少なくとも１つのプロセッサは、さらに、
    前記分散型台帳の前記トランザクションデータとしてＪａｖａ（登録商標）ＳｃｒｉｐｔＯｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）で前記データベースの属性を定義するコードに対応する命令、および前記データベースを前記データベースの属性で更新するための命令を実行するものであるシステム。
  36. 請求項２２記載のシステムにおいて、さらに、前記少なくとも１つのプロセッサは、前記分散型台帳に含めるために、前記分散型台帳のデータベースによって処理可能な形式を説明する、解析および変換された構造化照会言語（ＳＱＬ）クエリを作成するための命令を実行するものであるシステム。
  37. 請求項２２記載のシステムにおいて、前記リレーショナルデータベース管理クエリはスマートコントラクトから受信され、前記受信したリレーショナルデータベース管理クエリは、前記分散型台帳の前記データベースによって処理されることができる分散型台帳トランザクションに変換され、および前記分散型台帳の前記分散型台帳トランザクションは、トランザクション結果を生成するために実行されるものであり、さらに前記トランザクション結果を前記スマートコントラクトに返すための命令を実行する少なくとも１つのプロセッサを有するものであるシステム。
  38. 請求項３７記載のシステムにおいて、前記スマートコントラクトは、ＤＤＬデータベース操作とスキーマ変更を除く前記分散型台帳のデータ定義言語（ＤＤＬ）操作を実行するものであるシステム。
  39. 請求項３８記載のシステムにおいて、前記データベースのデータベース関連操作は、チェーンコードの前記分散型台帳、前記スマートコントラクトの少なくとも１つの資産および前記少なくとも１つの資産を変更するための少なくとも1つのトランザクション命令を定義する前記チェーンコード、を実装するものであるシステム。
  40. 請求項３９記載のシステムにおいて、前記スマートコントラクトが実行のために前記チェーンコードを呼び出すものであるシステム。
  41. 請求項３９記載のシステムにおいて、前記スマートコントラクトは、前記チェーンコードからデータ操作言語（ＤＭＬ）読み取り操作を開始するものであるシステム。
  42. 請求項３７記載のシステムにおいて、前記スマートコントラクトは、データ操作言語（ＤＭＬ）クエリの実行、前記分散型台帳への前記データベースの作成、またはデータ定義言語（ＤＤＬ）クエリの実行を含む少なくとも１つの操作を実行するものであるシステム。
  43. 請求項４２記載のシステムにおいて、前記スマートコントラクトは、前記分散型台帳のデータ分離を作成する構成トランザクションを実行することによって前記分散型台帳に前記データベースを作成し、前記データベースのコピーを維持するピアコンピュータと前記データベースに関するメタデータを書き込む通常のトランザクションの実行を定義するものであり、前記少なくとも１つのプロセッサは、さらに、前記分散型台帳のトランザクションデータと、前記トランザクションデータを変更するためのトランザクション命令を定義するコードの作成を有する動作を実行するために命令を実行するものであるシステム。
JP2021549147A 2019-08-19 2020-08-19 分散型台帳技術（ｄｌｔ）を使用したリレーショナルデータの管理と編成 Active JP7500589B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US16/544,538 2019-08-19
US16/544,538 US10726002B1 (en) 2019-08-19 2019-08-19 Relational data management and organization using DLT
US16/899,400 US11657039B2 (en) 2019-08-19 2020-06-11 Relational data management and organization using DLT
US16/899,400 2020-06-11
PCT/CA2020/051131 WO2021030910A1 (en) 2019-08-19 2020-08-19 Relational data management and organization using dlt

Publications (2)

Publication Number Publication Date
JP2022521915A true JP2022521915A (ja) 2022-04-13
JP7500589B2 JP7500589B2 (ja) 2024-06-17

Family

ID=71783562

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021549147A Active JP7500589B2 (ja) 2019-08-19 2020-08-19 分散型台帳技術（ｄｌｔ）を使用したリレーショナルデータの管理と編成

Country Status (9)

Country Link
US (2) US10726002B1 (ja)
EP (1) EP3884397A4 (ja)
JP (1) JP7500589B2 (ja)
KR (2) KR102579802B1 (ja)
CN (1) CN113454619A (ja)
CA (1) CA3125065C (ja)
MX (1) MX2021009969A (ja)
SG (1) SG11202106858TA (ja)
WO (1) WO2021030910A1 (ja)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11436039B2 (en) * 2019-05-04 2022-09-06 Prasaga Foundation Systemic extensible blockchain object model comprising a first-class object model and a distributed ledger technology
US11606442B2 (en) 2019-06-07 2023-03-14 Microsoft Technology Licensing, Llc Subscription to edits of blockchain transaction
US20210042737A1 (en) * 2019-08-07 2021-02-11 Seatig Inc. Distributed computing architecture with settlement mechanism to enable traceability of credit tokenization, disbursement and repayment
US11461324B2 (en) * 2019-08-29 2022-10-04 Oracle International Corporation First futamura projection in the context of SQL expression evaluation
US11442957B2 (en) * 2019-09-03 2022-09-13 Sap Se Cloud-based fiscal year variant conversion
US11115804B2 (en) * 2019-10-04 2021-09-07 Microsoft Technology Licensing, Llc Subscription to dependencies in smart contracts
US11641364B2 (en) * 2020-03-03 2023-05-02 International Business Machines Corporation Cross-domain state synchronization
US20210279690A1 (en) * 2020-05-29 2021-09-09 II Darrell Thompson Pathfinder
US11630649B2 (en) * 2020-06-02 2023-04-18 International Business Machines Corporation Intelligent application library management
US20210406876A1 (en) * 2020-06-30 2021-12-30 International Business Machines Corporation Permissioned eventing in a decentralized database
US20220075877A1 (en) 2020-09-09 2022-03-10 Self Financial, Inc. Interface and system for updating isolated repositories
US11641665B2 (en) 2020-09-09 2023-05-02 Self Financial, Inc. Resource utilization retrieval and modification
US11470037B2 (en) 2020-09-09 2022-10-11 Self Financial, Inc. Navigation pathway generation
US11475010B2 (en) * 2020-09-09 2022-10-18 Self Financial, Inc. Asynchronous database caching
US11386053B2 (en) * 2020-10-15 2022-07-12 Google Llc Automatic generation of a data model from a structured query language (SQL) statement
US11960469B2 (en) 2020-12-07 2024-04-16 Deixis, PBC Heterogeneous integration with distributed ledger blockchain services
US20220368533A1 (en) * 2021-05-16 2022-11-17 CodeNotary Inc. System and method to cryptographically validate rich query results
US11599532B1 (en) * 2021-08-11 2023-03-07 Amdocs Development Limited System, method, and computer program for preventing user mistakes when making database changes
US11704312B2 (en) * 2021-08-19 2023-07-18 Microsoft Technology Licensing, Llc Conjunctive filtering with embedding models
US11972012B2 (en) * 2021-08-31 2024-04-30 Sap Se Authorization check for nested queries in database systems
US20230076875A1 (en) * 2021-09-03 2023-03-09 International Business Machines Corporation Avoiding data page updates after an insertion operation
CN113626850B (zh) * 2021-10-13 2022-03-11 北京百度网讯科技有限公司 基于联盟链的请求处理方法、装置、设备和存储介质
CN113918996B (zh) * 2021-11-24 2024-03-26 企查查科技股份有限公司 分布式数据处理方法、装置、计算机设备和存储介质
US20230283488A1 (en) * 2022-03-01 2023-09-07 DLT Global, Inc. Blockchain rules engine
US11641280B1 (en) * 2022-06-21 2023-05-02 Northern Trust Corporation Computing technologies for enabling blockchain-based digital tokens with asset-specific attributes
US12019642B2 (en) 2022-11-11 2024-06-25 Microsoft Technology Licensing, Llc Distributed query technique to efficiently retrieve and merge data from multiple shards

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005141280A (ja) * 2003-11-04 2005-06-02 Kureo:Kk データベース移行装置及びそのプログラム
WO2019152750A1 (en) * 2018-01-31 2019-08-08 Salesforce.Com.Inc. Systems, methods, and apparatuses for implementing super community and community sidechains with consent management for distributed ledger technologies in a cloud based computing environment

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10169439B2 (en) * 2015-06-19 2019-01-01 Sap Se Multi-source asynchronous table replication
US11042560B2 (en) * 2016-06-19 2021-06-22 data. world, Inc. Extended computerized query language syntax for analyzing multiple tabular data arrangements in data-driven collaborative projects
US10621233B2 (en) * 2016-11-09 2020-04-14 Cognitive Scale, Inc. Cognitive session graphs including blockchains
US10868865B2 (en) * 2017-11-20 2020-12-15 Moshe Shadmon System and apparatus to manage data using a peer-to-peer network and the blockchain
US10831764B2 (en) * 2017-12-02 2020-11-10 International Business Machines Corporation Query processing and access control in a blockchain network
US11243945B2 (en) * 2017-12-11 2022-02-08 International Business Machines Corporation Distributed database having blockchain attributes
US11257073B2 (en) * 2018-01-31 2022-02-22 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing machine learning models for smart contracts using distributed ledger technologies in a cloud based computing environment
US20190236606A1 (en) * 2018-01-31 2019-08-01 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing a virtual chain model for distributed ledger technologies in a cloud based computing environment
CN108616578A (zh) * 2018-04-09 2018-10-02 上海点融信息科技有限责任公司 跨区块链平台的业务处理方法、设备及计算机可读存储介质
CN108563796A (zh) * 2018-05-04 2018-09-21 蔷薇信息技术有限公司 区块链的数据压缩处理方法、装置及电子设备
CN109614823B (zh) * 2018-10-26 2022-05-13 蚂蚁双链科技(上海)有限公司 一种数据的处理方法、装置及设备
CN109492053B (zh) * 2018-11-08 2023-07-18 北京百度网讯科技有限公司 用于访问数据的方法和装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005141280A (ja) * 2003-11-04 2005-06-02 Kureo:Kk データベース移行装置及びそのプログラム
WO2019152750A1 (en) * 2018-01-31 2019-08-08 Salesforce.Com.Inc. Systems, methods, and apparatuses for implementing super community and community sidechains with consent management for distributed ledger technologies in a cloud based computing environment

Also Published As

Publication number Publication date
KR102579802B1 (ko) 2023-09-19
KR20220025243A (ko) 2022-03-03
KR102364877B1 (ko) 2022-02-17
EP3884397A4 (en) 2022-01-19
JP7500589B2 (ja) 2024-06-17
CA3125065C (en) 2023-11-28
US11657039B2 (en) 2023-05-23
MX2021009969A (es) 2021-09-21
WO2021030910A1 (en) 2021-02-25
CN113454619A (zh) 2021-09-28
EP3884397A1 (en) 2021-09-29
US20210056095A1 (en) 2021-02-25
KR20210146890A (ko) 2021-12-06
US10726002B1 (en) 2020-07-28
SG11202106858TA (en) 2021-07-29
CA3125065A1 (en) 2021-02-25

Similar Documents

Publication Publication Date Title
JP7500589B2 (ja) 分散型台帳技術（ｄｌｔ）を使用したリレーショナルデータの管理と編成
US11824970B2 (en) Systems, methods, and apparatuses for implementing user access controls in a metadata driven blockchain operating via distributed ledger technology (DLT) using granular access objects and ALFA/XACML visibility rules
US11899817B2 (en) Systems, methods, and apparatuses for storing PII information via a metadata driven blockchain using distributed and decentralized storage for sensitive user information
US11764950B2 (en) System or method to implement right to be forgotten on metadata driven blockchain using shared secrets and consensus on read
US11811769B2 (en) Systems, methods, and apparatuses for implementing a declarative, metadata driven, cryptographically verifiable multi-network (multi-tenant) shared ledger
US11824864B2 (en) Systems, methods, and apparatuses for implementing a declarative and metadata driven blockchain platform using distributed ledger technology (DLT)
US11743137B2 (en) Systems, methods, and apparatuses for implementing a metadata driven rules engine on blockchain using distributed ledger technology (DLT)
US11886421B2 (en) Systems, methods, and apparatuses for distributing a metadata driven application to customers and non-customers of a host organization using distributed ledger technology (DLT)
US11803537B2 (en) Systems, methods, and apparatuses for implementing an SQL query and filter mechanism for blockchain stored data using distributed ledger technology (DLT)
US11783024B2 (en) Systems, methods, and apparatuses for protecting consumer data privacy using solid, blockchain and IPFS integration
US11169985B2 (en) System and method for supporting SQL-based rich queries in hyperledger fabric blockchains
US11917066B1 (en) System for interacting objects as tokens on a blockchain using a class-based language
EP4071646A1 (en) Scalable, secure, efficient, and adaptable distributed digital ledger transaction network
US20230097203A1 (en) System and method for generating blockchain token support from a set of declarations

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210819

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210819

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20220921

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20221011

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20230111

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230131

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20230418

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240605

R150 Certificate of patent or registration of utility model

Ref document number: 7500589

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150