知財求人 - 知財ポータルサイト「IP Force」
特表2023-544518オペレーティングシステムを公開するためのブロックチェーンベースのシステムおよび方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-10-24
(54)【発明の名称】オペレーティングシステムを公開するためのブロックチェーンベースのシステムおよび方法
(51)【国際特許分類】
G06F 9/445 20180101AFI20231017BHJP
G06F 16/28 20190101ALI20231017BHJP
【ＦＩ】
G06F9/445
G06F16/28
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023518285
(86)(22)【出願日】2021-08-23
(85)【翻訳文提出日】2023-05-19
(86)【国際出願番号】 EP2021073219
(87)【国際公開番号】W WO2022058124
(87)【国際公開日】2022-03-24
(31)【優先権主張番号】2014825.0
(32)【優先日】2020-09-21
(33)【優先権主張国・地域又は機関】GB
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＰＹＴＨＯＮ
２．ＢＬＵＥＴＯＯＴＨ
３．ＺＩＧＢＥＥ
(71)【出願人】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】アレッシオ・パガーニ
【テーマコード（参考）】
5B175
5B376
【Ｆターム（参考）】
5B175AA01
5B175AA02
5B376AC23
5B376AE42
(57)【要約】
クライアントデバイスによって、ブロックチェーンに記録された、1つまたは複数の標的トランザクションを識別するステップであって、1つまたは複数の標的トランザクションが、1つまたは複数の標的トランザクションのペイロードに記憶されたオペレーティングシステムソフトウェアを含み、オペレーティングシステムソフトウェアが、少なくともオペレーティングシステムの何らかの実行可能コードを含む、オペレーティングシステムの少なくとも一部を含む、識別するステップと、ブロックチェーンに記憶された1つまたは複数の標的トランザクションのペイロードからオペレーティングシステムソフトウェアにアクセスするステップと、クライアントデバイス上で、1つまたは複数の標的トランザクションからアクセスされるオペレーティングシステムソフトウェアを実行するステップであって、オペレーティングシステムの実行可能コードを実行することを含む、実行するステップとを含む、方法。
【特許請求の範囲】
【請求項1】
クライアントデバイスによって、ブロックチェーンに記録された、1つまたは複数の標的トランザクションを識別するステップであって、前記1つまたは複数の標的トランザクションが、前記1つまたは複数の標的トランザクションのペイロードに記憶されたオペレーティングシステムソフトウェアを含み、前記オペレーティングシステムソフトウェアが、少なくともオペレーティングシステムの何らかの実行可能コードを含む、前記オペレーティングシステムの少なくとも一部を含む、識別するステップと、
前記ブロックチェーンに記憶された前記1つまたは複数の標的トランザクションの前記ペイロードから前記オペレーティングシステムソフトウェアにアクセスするステップと、
前記クライアントデバイス上で、前記1つまたは複数の標的トランザクションからアクセスされる前記オペレーティングシステムソフトウェアを実行するステップであって、前記オペレーティングシステムの前記実行可能コードを実行することを含む、実行するステップと
を含む、方法。
【請求項2】
前記オペレーティングシステムソフトウェアが、前記オペレーティングシステムの全体である、請求項1に記載の方法。
【請求項3】
前記実行するステップが、前記クライアントデバイスにインストールすることなく前記クライアントデバイスのRAMを介して前記オペレーティングシステムソフトウェアをストリーミングすることによって前記ブロックチェーンからライブで前記オペレーティングシステムソフトウェアを実行するステップを含む、請求項1または2に記載の方法。
【請求項4】
前記実行するステップが、前記オペレーティングシステムソフトウェアのコピーをクライアントデバイスにインストールするステップと、前記インストールされたコピーを実行するステップとを含む、請求項1または2に記載の方法。
【請求項5】
前記オペレーティングシステムソフトウェアに関する前記アクセスするステップおよび前記実行するステップが、前記クライアントデバイスのブート時に行われる、請求項1から4のいずれか一項に記載の方法。
【請求項6】
前記クライアントデバイスによって、前記ブロックチェーンで公開されるように、前記クライアントデバイスが前記オペレーティングシステムソフトウェアにアクセスしたという確認応答を送るステップをさらに含む、請求項1から5のいずれか一項に記載の方法。
【請求項7】
前記クライアントデバイスによって、前記ブロックチェーンで公開されるように、前記クライアントデバイスが前記オペレーティングシステムソフトウェアを実行したという確認応答を送るステップをさらに含む、請求項1から6のいずれか一項に記載の方法。
【請求項8】
前記1つまたは複数の標的トランザクションが、複数の標的トランザクションである、請求項1から7のいずれか一項に記載の方法。
【請求項9】
木構造が、前記ブロックチェーンにオーバーレイされ、前記木構造が、複数のノードと、ノード間のエッジとを含み、各ノードが前記ブロックチェーンに記録された異なるトランザクションであり、各エッジがそれぞれの子ノードからそれぞれの親ノードに接続し、各子ノードが前記それぞれの子ノードのペイロードに各子ノードのそれぞれの親ノードのトランザクションIDを指定することによって前記エッジが形成され、前記親ノードの1つが前記木構造の根ノードであり、前記オペレーティングシステムソフトウェアを記憶する前記1つまたは複数の標的トランザクションが、前記木構造の子ノードである、請求項1から8のいずれか一項に記載の方法。
【請求項10】
前記木構造がMetanet木を含む、請求項9に記載の方法。
【請求項11】
前記オペレーティングシステムソフトウェアが、階層的なファイルおよびフォルダ構造で配置された異なるフォルダに複数のファイルを含み、前記標的トランザクションの各々が、前記ファイルの少なくともそれぞれの1つを記憶し、前記標的トランザクションの1つまたは複数の親ノードが、フォルダを表すようにタグ付けされ、前記ノードの前記木構造の少なくとも一部が前記オペレーティングシステムソフトウェアの前記ファイルおよびフォルダ構造の少なくとも一部に従うようにする、請求項9または10に記載の方法。
【請求項12】
前記識別するステップが、前記根ノードの前記トランザクションIDに基づいて、前記根ノードから前記エッジのパスに従って前記木構造を下って葉ノードを見つけるステップを含み、前記葉ノードが、他の子ノードの親ノードではない子ノードであり、前記1つまたは複数の標的トンラザクションの各々が葉ノードである、請求項9から11のいずれか一項に記載の方法。
【請求項13】
前記クライアントデバイスが、前記標的トランザクション、および標的トランザクションと前記根ノードとの間のパス上のいずれかの中間の親ノードの各々が、前記木構造に関連する木プロトコルの1つまたは複数のルールを満たすことをチェックし、前記実行が、前記1つまたは複数のルールを前記満たすことを条件とする、請求項12に記載の方法。
【請求項14】
前記ルールのセットが、少なくとも、根ノードから標的トランザクションまでのパス沿いの各子について、前記子が前記それぞれの親ノードの鍵によって署名される、ことを含む、請求項13に記載の方法。
【請求項15】
前記1つまたは複数のルールが、葉ノードのみが前記オペレーティングシステムの有効な部分を形成することができることを含む、請求項13または14に記載の方法。
【請求項16】
前記クライアントデバイスによって、前記実行に続く後続時間において、前記標的トランザクションのそれぞれの1つにその後加えられた新しい葉ノードをチェックするステップをさらに含み、それにより、前記それぞれの標的トランザクションはもはや葉ではなく、前記新しい葉ノードが、前記それぞれの標的トランザクションの更新または削除を表す、請求項15に記載の方法。
【請求項17】
前記それぞれの標的トランザクションの1つが、更新を含み、前記方法が、前記クライアントデバイスが前記更新を実行するステップをさらに含む、請求項16に記載の方法。
【請求項18】
前記クライアントデバイスによって、前記クライアントデバイスからリモートにあるリモート管理者システムによって、さらなるトランザクションのペイロードに記録されたリモートコマンドまたはスクリプトを含む、前記ブロックチェーン上の前記さらなるトランザクションを識別するステップと、
前記さらなるトランザクションからアクセスされる前記コマンドまたはスクリプトを実行するステップと
をさらに含む、請求項1から17のいずれか一項に記載の方法。
【請求項19】
前記クライアントデバイスによって、前記ブロックチェーンで公開されるように、前記クライアントデバイスが前記コマンドまたはスクリプトにアクセスしたという確認応答を送るステップをさらに含む、請求項18に記載の方法。
【請求項20】
前記クライアントデバイスによって、前記ブロックチェーンで公開されるように、前記クライアントデバイスが前記コマンドまたはスクリプトを実行したという確認応答を送るステップをさらに含む、請求項18または19に記載の方法。
【請求項21】
前記デバイスがモノのインターネット、すなわちIoTデバイスである、請求項1から20のいずれか一項に記載の方法。
【請求項22】
前記クライアントデバイスが、ネットワークの1つまたは複数の他のデバイスと接続され、前記ネットワークを介して前記他のデバイスの少なくとも1つと前記オペレーティングシステムソフトウェアを共有する、請求項1から21のいずれか一項に記載の方法。
【請求項23】
前記ネットワークがメッシュネットワークである、請求項22に記載の方法。
【請求項24】
前記ネットワークがワイヤレスローカルエリアネットワークである、請求項22または23に記載の方法。
【請求項25】
前記他のデバイスのすべてが前記ブロックチェーンにアクセスできるとは限らない、請求項22、23、または24に記載の方法。
【請求項26】
前記ブロックチェーンが出力ベースのモデルを使用し、各トランザクションが、少なくとも1つのそれぞれの入力と、それぞれの1つまたは複数の出力とを含み、各トランザクションの前記ペイロードが、前記それぞれの出力の1つまたは複数に含まれる、請求項1から25のいずれか一項に記載の方法。
【請求項27】
1つまたは複数の処理ユニットを備える処理装置と、1つまたは複数のメモリユニットを備えるメモリと
を備える、クライアントデバイスであって、
前記メモリが、前記処理装置上で動作するように配置されたコードを記憶し、前記コードが、前記処理装置上で動作するとき、請求項1から26のいずれか一項に記載の動作を行うように構成された、クライアントデバイス。
【請求項28】
コンピュータ可読記憶媒体上で具体化されたコンピュータプログラムであって、クライアントデバイス上で動作するとき、請求項1から26のいずれか一項に記載の動作を行うように構成されたコードを含む、コンピュータプログラム。
【請求項29】
オペレーティングシステムの制作者のコンピュータ機器によって、ブロックチェーン上のトランザクションのペイロードで公開されるようにオペレーティングシステムソフトウェアを送信するステップを含み、前記オペレーティングシステムソフトウェアが、少なくとも前記オペレーティングシステムの何らかの実行可能コードを含む、前記オペレーティングシステムの少なくとも一部を含む、方法。
【請求項30】
ブロックチェーンにオーバーレイされた木構造を更新する方法であって、前記木構造が、複数のノードと、ノード間のエッジとを含み、各ノードが前記ブロックチェーンに記録された異なるトランザクションであり、各エッジがそれぞれの子ノードからそれぞれの親ノードに接続し、各子ノードが前記それぞれの子ノードのペイロードに各子ノードのそれぞれの親ノードのトランザクションIDを指定することによって、前記エッジが形成され、前記木構造が、前記木構造の根ノードとして前記親ノードの1つを含み、複数の葉ノードが、他の子ノードの親ノードではない子ノードであり、前記葉ノードの1つまたは複数が、前記1つまたは複数の葉ノードのペイロードにオペレーティングシステムソフトウェアを記憶し、前記オペレーティングシステムソフトウェアが、少なくとも前記オペレーティングシステムの何らかの実行可能コードを含む、前記オペレーティングシステムの少なくとも一部を含み、
前記木構造が、プロトコルによって支配され、それにより葉ノードのみが前記オペレーティングシステムの有効な部分を形成すると考えられ、
前記方法が、管理者システムによって、
前記1つまたは複数の葉ノードのそれぞれの1つに新しい葉ノードを加えるステップを含み、それにより、前記それぞれの標的トランザクションがもはや葉ではなく、前記新しい葉ノードは、前記それぞれの標的トランザクションの更新または削除を表す、方法。
【請求項31】
1つまたは複数の処理ユニットを備える処理装置と、1つまたは複数のメモリユニットを備えるメモリと
を備える、管理者システムであって、
前記メモリが、前記処理装置上で動作するように配置されたコードを記憶し、前記コードが、前記処理装置上で動作するとき、請求項30に記載の方法を行うように構成された、
管理者システム。
【請求項32】
コンピュータ可読記憶媒体上で具体化されたコンピュータプログラムであって、管理者システム上で動作するとき、請求項30に記載の方法を行うように構成されたコードを含む、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ソフトウェアを含むデータコンテンツをブロックチェーン上のトランザクションのペイロードに記憶することができるブロックチェーンの使用に関する。
【背景技術】
【0002】
ブロックチェーンとは、ある形式の分散型データ構造を指し、ブロックチェーンの複製は、分散型ピアツーピア(P2P)ネットワーク(以下では「ブロックチェーンネットワーク」と呼ばれる)の中の複数のノードの各々において維持され、広く公開される。ブロックチェーンは、データのブロックのチェーンを備え、各ブロックは、1つまたは複数のトランザクションを備える。いわゆる「コインベーストランザクション」以外の各トランザクションは、1つまたは複数のコインベーストランザクションまでの1つまたは複数のブロックにまたがり得るシーケンスの中の先行するトランザクションを指し示す。コインベーストランザクションについて、以下でさらに説明する。ブロックチェーンネットワークに出されるトランザクションは、新しいブロックに含まれる。新しいブロックは「マイニング」と呼ばれることが多い処理により作成され、これは、複数のノードの各々が競争して「プルーフオブワーク」を実行すること、すなわち、ブロックチェーンの新しいブロックに含められることを待機している、順序付けられ妥当性確認された未処理のトランザクションのプールに基づいて、暗号パズルを解くことを伴う。ブロックチェーンはいくつかのノードにおいて枝刈りされてもよく、ブロックの公開はブロックヘッダだけの公開により達成され得ることに留意されたい。
【0003】
ブロックチェーンにおけるトランザクションは、以下の目的、すなわちデジタル資産(すなわち、ある数のデジタルトークン)を運ぶこと、仮想化された台帳もしくは登録簿のエントリのセットを順序付けること、タイムスタンプエントリを受け取り処理すること、および/またはインデックスポインタを時間的に順序付けることのうちの、1つまたは複数のために使用され得る。ブロックチェーンは、ブロックチェーンに追加の機能を重ねるためにも利用され得る。たとえば、ブロックチェーンプロトコルは、トランザクションにおける追加のユーザデータまたはデータに対するインデックスの記憶を可能にし得る。単一のトランザクションに記憶され得る最大のデータ容量にはあらかじめ指定された限界はないので、ますます複雑になるデータを組み込むことができる。たとえば、これは、ブロックチェーンの中の電子文書、またはオーディオデータもしくはビデオデータを記憶するために使用され得る。
【0004】
ブロックチェーンネットワークのノード(「マイナー」と呼ばれることが多い)は、後でより詳しく説明される、分散型のトランザクションの登録および検証のプロセスを実行する。要約すると、この処理の間に、ノードはトランザクションを妥当性確認し、それらをブロックテンプレートに挿入し、ノードはそのブロックテンプレートについて有効なプルーフオブワークの解を特定することを試みる。有効な解が見つかると、新しいブロックがネットワークの他のノードに広められるので、各ノードがブロックチェーンに新しいブロックを記録することを可能にする。トランザクションがブロックチェーンに記録されるようにするために、ユーザ(たとえば、ブロックチェーンクライアントアプリケーション)は、トランザクションが広められるように、それをネットワークのノードのうちの1つに送信する。トランザクションを受信するノードは競って、妥当性確認されたトランザクションを新しいブロックへ組み込むプルーフオブワークの解を見つけることができる。各ノードは同じノードプロトコルを実施するように構成され、これは、トランザクションが有効になるための1つまたは複数の条件を含む。無効なトランザクションは、広められることも、ブロックに組み込まれることもない。トランザクションが妥当性確認され、それによりブロックチェーン上で受け入れられると仮定すると、トランザクション(あらゆるユーザデータを含む)は、イミュータブルな公開記録としてブロックチェーンネットワークの中のノードの各々において登録されインデクシングされたままになる。
【0005】
最新のブロックを作成するためにプルーフオブワークパズルを解くことに成功したノードは通常、ある額のデジタル資産、すなわちある数のトークンを分配する「コインベーストランザクション」と呼ばれる新しいトランザクションにより報酬を受ける。無効なトランザクションの検出および拒絶は、ネットワークのエージェントとして活動し不正を報告して阻止する動機のある、競合するノードの活動によって実施される。情報を広く公開することで、ユーザはノードの実績を継続的に監査することが可能になる。ブロックヘッダのみの公開により、参加者はブロックチェーンの完全性が継続中であることを確実にすることが可能になる。
【0006】
「出力ベース」モデル(UTXOベースのモデルと呼ばれることがある)では、所与のトランザクションのデータ構造は、1つまたは複数の入力および1つまたは複数の出力を備える。あらゆる消費可能な出力は、トランザクションの先行するシーケンスから導出可能であるデジタル資産の額を指定する要素を備える。消費可能な出力は、UTXO(「未消費トランザクション出力」)と呼ばれることがある。出力はさらに、出力のさらなる引き換えのための条件を指定するロッキングスクリプトを備え得る。ロッキングスクリプトは、デジタルトークンまたは資産を妥当性確認して移すために必要な条件を定義する述部である。トランザクション(コインベーストランザクション以外)の各入力は、先行するトランザクションにおけるそのような出力へのポインタ(すなわち、参照)を備え、指し示された出力のロッキングスクリプトをアンロックするためのアンロッキングスクリプトをさらに備え得る。よって、トランザクションのペアを考え、それらを第1のトランザクションおよび第2のトランザクション(または「標的」トランザクション)と呼ぶ。第1のトランザクションは、デジタル資産の額を指定し、出力をアンロッキンングする1つまたは複数の条件を定義するロッキングスクリプトを備える、少なくとも1つの出力を備える。第2の標的トランザクションは、第1のトランザクションの出力へのポインタと、第1のトランザクションの出力をアンロックするためのアンロッキングスクリプトとを備える、少なくとも1つの入力を備える。
【0007】
そのようなモデルでは、第2の標的トランザクションが、ブロックチェーンにおいて広められて記録されるようにブロックチェーンネットワークに送信されるとき、各ノードにおいて適用される有効性の基準の1つは、アンロッキングスクリプトが第1のトランザクションのロッキングスクリプトにおいて定義される1つまたは複数の条件のすべてを満たすというものである。別の基準は、第1のトランザクションの出力が別のより前の有効なトランザクションによってまだ引き換えられていないということである。これらの条件のいずれかに従って標的トランザクションが無効であることを見出したいずれのノードも、トランザクションを広めず(場合によっては無効なトランザクションを登録するために有効なトランザクションとして広めない)、またブロックチェーンに記録されるべき新しいブロックにトランザクションを含めない。
【0008】
代替的なタイプのトランザクションモデルは、アカウントベースモデルである。この場合、各トランザクションは、過去のトランザクションのシーケンスの中の先行するトランザクションのUTXOを参照することによってではなく、絶対的なアカウント残高を参照することによって、移されるべき額を定義する。すべてのアカウントの現在の状態が、ブロックチェーンとは別のノードによって記憶され、定期的に更新される。
【0009】
ブロックチェーンネットワークはすでに、インターネットなどの下にあるネットワーク上にオーバーレイされたオーバーレイネットワークの一タイプである。しかしながら、ブロックチェーン上にオーバーレイネットワークのさらなるレイヤをオーバーレイすることも可能である。この一例が、Metanetとして知られている。Metanetの各ノードは、ブロックチェーン上の異なるトランザクションである(「ノード」は今異なる意味で使用されており、ブロックチェーンネットワークのノードを指すのではなく、Metanetのノードを指すことに留意する)。データコンテンツおよびMetanetメタデータは、そのような各トランザクションのペイロードに、OP_RETURNを用いてトランザクションの支出不可(unspendable)出力において、記憶される。データコンテンツは、Metanetがたとえばテキスト、画像、ビデオ、または音声コンテンツなどを記憶するために使用されている実際のユーザコンテンツであるが、メタデータは、Metanetノード間のリンクを定義する。Metanetノード間のリンクまたはエッジは、必ずしもブロックチェーンレイヤにおいて支出エッジ(spending edge)に対応するとは限らない。すなわち、所与のMetanetトランザクションの入力が、ブロックチェーンレイヤにおいて別の、資金提供トランザクション(funding transaction)の出力を指し示す場合、その同じトランザクションの親またはMetanetレイヤにおけるMetanetノードは、必ずしも資金提供トランザクションと同じトランザクションとは限らない。代わりにMetanetレイヤにおけるリンクまたはエッジは、Metanetのデータコンテンツ間のリンクを定義する。
【発明の概要】
【課題を解決するための手段】
【0010】
本開示は、ライブディストリビューション(live distribution)としてまたはクライアントデバイスにインストールするために、ブロックチェーン上でオペレーティングシステムソフトウェアを公開することを可能にする新しい技術を提供する。
【0011】
本開示の一態様によれば、クライアントデバイスによって、ブロックチェーンに記録された、1つまたは複数の標的トランザクションを識別するステップを含む方法が提供され、1つまたは複数の標的トランザクションが、1つまたは複数の標的トランザクションのペイロードに記憶されたオペレーティングシステムソフトウェアを含み、オペレーティングシステムソフトウェアが、少なくともオペレーティングシステムの何らかの実行可能コードを含む、オペレーティングシステムの少なくとも一部を含む。この方法はさらに、ブロックチェーンに記憶された1つまたは複数の標的トランザクションのペイロードからオペレーティングシステムソフトウェアにアクセスするステップと、クライアントデバイス上で、1つまたは複数の標的トランザクションからアクセスされるオペレーティングシステムソフトウェアを実行するステップとを含み、上記の実行するステップが、オペレーティングシステムの実行可能コードを実行することを含む。
【0012】
いくつかのデバイスは、標準的な、常に利用可能なオペレーティングシステムから恩恵を受けることができ、このオペレーティングシステムは、ブロックチェーン上に記憶され、チェーンからライブで実行されるか、またはデバイスにインストールされるように、要求時にダウンロードされてもよい。更新もまた、チェーンで公開されてもよい。たとえば、これは特に、小型のオペレーティングシステムを使用し、限られた量のリソースを有するモノのインターネット(IoT)デバイスに適用可能である。IoTデバイスは、数千のコピーで生成され、広域にわたって散在していることがある。したがって、IoTデバイスは、非集中的ブロックチェーンソリューションから恩恵を受けることができる。それらは、オンチェーンで不変に記憶された真正のデータにアクセスできるいずれかの利用可能なブロックチェーンノードに接続することができる(それらは他のノードを用いてダブルチェックするためにSPV、すなわちSimplified Payment Verification、または同様の方法を使用することもできる)からである。たとえば、IoTデバイスが、オンチェーンで利用可能なオペレーティングシステムのライブディストリビューションをダウンロードし、実行してもよく、実施形態ではIoTデバイスは、それらの管理者によって(たとえば、実行されるデバイス固有のコマンドまたはコードに送信するためにビットコインネットワークを使用して)遠隔制御されることもある。
【0013】
実施形態では、Metanetなどのオーバーレイネットワーク木構造が、オペレーティングシステムのファイルを構築するために使用されてもよい。そのような実施形態では、クライアントデバイスが、ブロックチェーンからいずれかの互換性があるオペレーティングシステムをダウンロードする、または実行する、または直接ブートすることができ、必要とされる唯一の情報は、固有のOSを記憶するために使用されるMetanet木の根である。同じ木は、1つまたは複数のデバイスによって実行されるコマンドおよびコード(たとえば、スマートコントラクト)を公開するために使用され得る。
【0014】
たとえばIoTデバイスは、(たとえば、ROMに記憶された)埋め込まれた木根で生成されてもよく、このIoTデバイスは、同じ木に常にリンクされることになり、IoTデバイスはオペレーティングシステムの正しいバージョンおよび公開された更新を常にダウンロードすることになり、IoTデバイスはその木で公開されるどんなコード(たとえば、スマートコントラクト)も実行することになる。その木を作成および管理するために使用される秘密鍵が漏洩しない限り、IoTデバイスは安全であり、立証可能(evidencable)さらには証明可能な方法で、かつ、指定されたライブラリおよびモジュールを使用して、任意のコードを実行することができる。
【0015】
本開示の実施形態の理解を助けるために、およびそのような実施形態がどのように実行に移され得るかを示すために、単に例として、添付の図面を参照する。
【図面の簡単な説明】
【0016】
【図1】ブロックチェーンを実装するためのシステムの概略ブロック図である。
【図2】ブロックチェーンに記録され得るトランザクションのいくつかの例を概略的に示す図である。
【図3】ブロックチェーンにオーバーレイされたネットワークの概略図である。
【図4】ブロックチェーンにMetanetなどのネットワークをオーバーレイするための例示的なプロトコルを示す概略トランザクション図である。
【図5】オーバーレイ木構造に記憶されているオペレーティングシステム(図示の例では、Metanet木に記憶されたPuppy Linux BionicPup32のライブLinux（登録商標）ディストリビューション)を概略的に示す図である。
【図6】OSを構築するために使用される、Metanet木などのオーバーレイネットワーク木構造の一例を概略的に示す図である。
【図7】Metanet木などのオーバーレイネットワーク木構造のファイルを更新するプロセスを概略的に示し、古いバージョンから新しいバージョンへのリンクを作成することによって、現在のバージョンが新しいバージョンに置き換えられた(新しいバージョンが古いバージョンの子である)図である。
【図8】コマンドを実行する、またはいくつかのコードを実行する一例を概略的に示し、コマンドおよびコードがオペレーティングシステムの同じ木上で公開される、図である。
【図9】本明細書で開示する実施形態による、クライアントデバイスによって実行される例示的な方法の概略フローチャートである。
【発明を実施するための形態】
【0017】
例示的なシステムの概要
図1は、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、通常はインターネットなどのワイドエリアインターネットワークである、パケット交換ネットワーク101を備え得る。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピアツーピア(P2P)ネットワーク106を形成するように並べられ得る複数のブロックチェーンノード104を備える。示されていないが、ブロックチェーンノード104は準完全グラフとして並べられ得る。したがって、各ブロックチェーンノード104は、他のブロックチェーンノード104に高度に接続される。
図1は、ブロックチェーン150を実装するための例示的なシステム100を示す。システム100は、通常はインターネットなどのワイドエリアインターネットワークである、パケット交換ネットワーク101を備え得る。パケット交換ネットワーク101は、パケット交換ネットワーク101内でピアツーピア(P2P)ネットワーク106を形成するように並べられ得る複数のブロックチェーンノード104を備える。示されていないが、ブロックチェーンノード104は準完全グラフとして並べられ得る。したがって、各ブロックチェーンノード104は、他のブロックチェーンノード104に高度に接続される。
【0018】
各ブロックチェーンノード104は、ピアのコンピュータ機器を備え、異なるノード104は異なるピアに属する。各ブロックチェーンノード104は、1つまたは複数のプロセッサ、たとえば1つまたは複数の中央処理装置(CPU)、アクセラレータプロセッサ、特定用途向けプロセッサおよび/またはフィールドプログラマブルゲートアレイ(FPGA)、ならびに特定用途向け集積回路(ASIC)などの他の機器を備える、処理装置を備える。各ノードはまた、メモリ、すなわち、非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備える。メモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、ソリッドステートドライブ(SSD)、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または高額ディスクドライブなどの光学媒体を利用する、1つまたは複数のメモリユニットを備え得る。
【0019】
ブロックチェーン150はデータのブロック151のチェーンを備え、ブロックチェーン150のそれぞれのコピーが、分散ネットワークまたはブロックチェーンネットワーク106の中の複数のブロックチェーンノード104の各々において維持される。上で言及されたように、ブロックチェーン150のコピーを維持することは、ブロックチェーン150を完全に記憶することを必ずしも意味しない。代わりに、ブロックチェーン150は、各ブロックチェーンノード150が各ブロック151のブロックヘッダ(以下で論じられる)を記憶する限り、データを枝刈りされ得る。チェーンの中の各ブロック151は1つまたは複数のトランザクション152を備え、この文脈においてトランザクションはある種のデータ構造を指す。データ構造の性質は、トランザクションモデルまたはスキームの一部として使用されるトランザクションプロトコルのタイプに依存する。所与のブロックチェーンは、1つの特定のトランザクションプロトコルを全体で使用する。ある一般的なタイプのトランザクションプロトコルにおいて、各トランザクション152のデータ構造は、少なくとも1つの入力および少なくとも1つの出力を備える。各出力は、ある数量のデジタル資産を表す額を財産として指定し、その例は、出力が暗号によりにロックされる対象であるユーザ103である(アンロック、および引き換えまたは消費のために、そのユーザの署名または他のソリューションを必要とする)。各入力は、先行するトランザクション152の出力を指し示し、それによりそれらのトランザクションをつなぐ。
【0020】
各ブロック151はまた、ブロック151に対する逐次的な順序を定義するために、チェーンの中の以前に作成されたブロック151を指し示すブロックポインタ155を備える。各トランザクション152(コインベーストランザクション以外)は、トランザクションのシーケンスに対する順序を定義するために、以前のトランザクションへのポインタを備える(トランザクション152のシーケンスは分岐することが許容されることに留意されたい)。ブロック151のチェーンは、チェーンにおいて最初のブロックであったジェネシスブロック(Gb)153まで戻る。チェーン150の初期の1つまたは複数の元のトランザクション152は、先行するトランザクションではなくジェネシスブロック153を指し示していた。
【0021】
ブロックチェーンノード104の各々は、トランザクション152を他のブロックチェーンノード104に転送し、それにより、トランザクション152がネットワーク106全体に広められるようにするように構成される。各ブロックチェーンノード104は、ブロック151を作成し、同じブロックチェーン150のそれぞれのコピーをそれぞれのメモリに記憶するように構成される。各ブロックチェーンノード104はまた、ブロック151へと組み込まれるのを待機しているトランザクション152の順序付けられたプール154を維持する。順序付けられたプール154は、「メモリプール」と呼ばれることが多い。本明細書におけるこの用語は、任意の特定のブロックチェーン、プロトコル、またはモデルに限定することを意図しない。それは、ノード104が有効であるものとして受け入れた、かつ同じ出力を消費することを試みる他のトランザクションをノード104が受け入れることが義務付けられない、トランザクションの順序付けられたセットを指す。
【0022】
所与の現在のトランザクション152jにおいて、入力(または各入力)は、トランザクションのシーケンスの中の先行するトランザクション152iの出力を参照するポインタを備え、これは、この出力が現在のトランザクション152jにおいて引き換えられる、または「消費される」ことになることを指定する。一般に、先行するトランザクションは、順序付けられたセット154または任意のブロック151における任意のトランザクションであり得る。先行するトランザクション152iは、現在のトランザクション152iが作成される時点で、またはネットワーク106に送信される時点ですら、必ずしも存在する必要はないが、現在のトランザクションが有効になるためには、先行するトランザクション152iが存在して妥当性確認される必要がある。したがって、本明細書における「先行する」は、ポインタにより連結される論理シーケンスにおいて先行するものを指し、時間的な順序における作成または送信の時間を必ずしも指さず、したがって、トランザクション152i、152jが順不同で作成または送信されることを必ずしも排除しない(オーファントランザクションについての以下の議論を参照)。先行するトランザクション152iは同様に、祖先トランザクションまたは先行者トランザクションと呼ばれ得る。
【0023】
現在のトランザクション152jの入力はまた、入力承認、たとえば、先行するトランザクション152iの出力がロックされる対象であるユーザ103aの署名を備える。そして、現在のトランザクション152jの出力は、新しいユーザまたはエンティティ103bに暗号によりロックされ得る。したがって、現在のトランザクション152jは、現在のトランザクション152jの出力において定義されるような新しいユーザまたはエンティティ103bに、先行するトランザクション152iの入力において定義される額を移すことができる。いくつかの場合、トランザクション152は、複数のユーザまたはエンティティ(そのうちの1つは、残金を与えるために元のユーザまたはエンティティ103aであり得る)の間で入力の額を分割するために、複数の出力を有し得る。いくつかの場合、トランザクションはまた、1つまたは複数の先行するトランザクションの複数の出力からの額を一緒に集めて、現在のトランザクションの1つまたは複数の出力を再分配するために、複数の入力を有し得る。
【0024】
ビットコインなどの出力ベースのトランザクションプロトコルによれば、個人ユーザまたは団体などの関係者103が、(手動でまたは関係者によって使用される自動プロセスによって)新しいトランザクション152jを実施することを望むとき、実施する関係者は、関係者のコンピュータ端末102から受信者に新しいトランザクションを送信する。実施する関係者または受信者は最終的に、このトランザクションをネットワーク106のブロックチェーンノード104(これは今日では通常はサーバまたはデータセンターであるが、原理的には他のユーザ端末であってもよい)のうちの1つまたは複数に直接送信する。新しいトランザクション152jを実施する関係者103がトランザクションをブロックチェーンノード104のうちの1つまたは複数に送信でき、いくつかの例では受信者に送信できないことも、排除されない。トランザクションを受信するブロックチェーンノード104は、ブロックチェーンノード104の各々において適用されるブロックチェーンノードプロトコルに従って、トランザクションが有効であるかどうかを確認する。ブロックチェーンノードプロトコルは通常、新しいトランザクション152jの中の暗号署名が予想される署名と一致することをブロックチェーンノード104が確かめることを必要とし、予想される署名は、トランザクション152の順序付けられたシーケンスの中の以前のトランザクション152iに依存する。そのような出力ベースのトランザクションプロトコルでは、これは、新しいトランザクション152jの入力に含まれる関係者103の暗号署名または他の承認が、新しいトランザクションが割り当てる先行するトランザクション152iの出力において定義される条件と一致することを確かめることを備えることがあり、この条件は通常、新しいトランザクション152jの入力の中の暗号署名または他の承認が、新しいトランザクションの入力がつなげられる以前のトランザクション152iの出力をアンロックすることを、少なくとも確かめることを備える。この条件は、先行するトランザクション152iの出力に含まれるスクリプトによって少なくとも部分的に定義され得る。代替として、それは単純にブロックチェーンノードプロトコルだけによって固定されてもよく、または、それはこれらの組合せによるものであってもよい。いずれにしても、新しいトランザクション152jが有効である場合、ブロックチェーンノード104は、それをブロックチェーンネットワーク106の中の1つまたは複数の他のブロックチェーンノード104に転送する。これらの他のブロックチェーンノード104は、同じブロックチェーンノードプロトコルに従って同じ試験を適用し、新しいトランザクション152jを1つまたは複数のさらなるノード104に転送するなどする。このようにして、新しいトランザクションが、ブロックチェーンノード104のネットワーク全体に広められる。
【0025】
出力ベースのモデルにおいて、所与の出力(たとえば、UXTO)が割り当てられる(たとえば、消費される)かどうかの定義は、それがブロックチェーンノードプロトコルに従って別の前方のトランザクション152jの入力によりすでに有効に引き換えられているかどうかである。トランザクションが有効になるための別の条件は、そのトランザクションが引き換えることを試みる先行するトランザクション152iの出力が、別のトランザクションによってまだ引き換えられていないことである。やはり、有効ではない場合、トランザクション152jは、ブロックチェーン150において広められず(無効であるものとしてフラグを立てられて警告のために広められない限り)、または記録されない。これは、取引者が同じトランザクションの出力を一度より多く割り当てることを試みるような、二重消費から守る。一方、アカウントベースのモデルは、アカウント残高を維持することによって二重消費から守る。やはり、トランザクションの定められた順序があるので、アカウント残高は任意のある時間において単一の定められた状態を有する。
【0026】
トランザクションを検証することに加えて、ブロックチェーンノード104はまた、マイニングと一般に呼ばれるプロセスにおいて、トランザクションのブロックを最初に作成するのを競い、これは「プルーフオブワーク」により支援される。ブロックチェーンノード104において、新しいトランザクションは、ブロックチェーン150に記録されているブロック151にまだ表れていない有効なトランザクションの順序付けられたプール154に追加される。そして、ブロックチェーンノードは、暗号パズルを解こうとすることによって、トランザクションの順序付けられたセット154からトランザクション152の新しい有効なブロック151を競って組み立てる。通常、これは、「ノンス」が未処理のトランザクション154の順序付けられたプールの表現と連結されてハッシュされると、ハッシュの出力が所定の条件を満たすような、ノンス値を探すことを備える。たとえば、所定の条件は、ハッシュの出力がある定められた数の先頭の0を有するということであり得る。これは、プルーフオブワークパズルの1つの具体的なタイプにすぎず、他のタイプが排除されないことに留意されたい。ハッシュ関数の性質は、それがその入力に関して予測不可能な出力を有するというものである。したがって、この探索は、ブルートフォースによってのみ実行することができるので、パズルを解こうとしている各ブロックチェーンノード104において大量の処理リソースを消費する。
【0027】
パズルを解こうとする第1のブロックチェーンノード104は、これをネットワーク106に告知し、ネットワークの中の他のブロックチェーンノード104によって容易に確かめられ得る証明として解を提供する(ハッシュへの解が与えられると、それによりハッシュの出力が条件を満たすようになることを確かめるのは単純である)。第1のブロックチェーンノード104は、ブロックを受け入れしたがってプロトコルルールを実施する、他のノードの閾値コンセンサスにブロックを広める。トランザクションの順序付けられたセット154は次いで、ブロックチェーンノード104の各々によってブロックチェーン150の中の新しいブロック151として記録されるようになる。ブロックポインタ155はまた、チェーンの中の以前に作成されたブロック151n-1を指し示す新しいブロック151nに割り当てられる。プルーフオブワークの解を作成するために必要とされる、たとえばハッシュの形式の大量の労力は、ブロックチェーンプロトコルのルールに従うという第1のノードの104の意図を示すものである。そのようなルールは、以前に妥当性確認されたトランザクションと同じ出力を割り当てる場合(これは別様に二重消費として知られている)、有効であるものとしてトランザクションを受け入れないことを含む。作成されると、ブロック151を改変することはできず、それは、ブロック151が、ブロックチェーンネットワーク106の中のブロックチェーンノード104の各々において認識され維持されるからである。ブロックポインタ155はまた、逐次的な順序をブロック151に課す。トランザクション152は、ネットワーク106の中の各ブロックチェーンノード104において順序付けられるブロックに記録されるので、これはトランザクションのイミュータブルな公開台帳を提供する。
【0028】
任意の所与の時間において競ってパズルを解く異なるブロックチェーンノード104は、それらのブロックチェーンノードがいつ解の探索を始めたか、またはトランザクションが受信された順序に応じて、任意の所与の時間におけるまだ公開されていないトランザクション154のプールの異なるスナップショットに基づいて、競ってパズルを解いていることがあることに留意されたい。それぞれのパズルを最初に解いた者が、どのトランザクション152が次の新しいブロック151nに含まれるか、およびどの順序で含まれるかを定義し、公開されていないトランザクションの現在のプール154は更新される。ブロックチェーンノード104は次いで、公開されていないトランザクション154の新しく定義された順序付けられたプールからブロックを競って作成し続け、以下同様である。生じ得るあらゆる「フォーク」を解決するためのプロトコルも存在し、これは、2つのブロックチェーンノード104が互いに非常に短い時間内にパズルを解き、その結果、ブロックチェーンの矛盾する景色がノード104間で広められるようになる状況である。つまり、フォークの先端がより長く成長した方が、最終的なブロックチェーン150になる。同じトランザクションが両方のフォークに現れるので、これはネットワークのユーザまたはエージェントに影響しないはずであることに留意されたい。
【0029】
ビットコインブロックチェーン(および大部分の他のブロックチェーン)によれば、新しいブロックを構築することに成功するノード104は、(あるエージェントまたはユーザから別のエージェントまたはユーザにある額のデジタル資産を移す、エージェント間またはユーザ間のトランザクションとは対照的に)追加の、定められた数量のデジタル資産を分配する新しい特別な種類のトランザクションにおいて、追加の、許容される額のデジタル資産を新たに割り当てる能力を与えられる。この特別なタイプのトランザクションは普通、「コインベーストランザクション」と呼ばれるが、「開始トランザクション」または「生成トランザクション」とも呼ばれ得る。それは通常、新しいブロック151nの最初のトランザクションを形成する。プルーフオブワークは、この特別なトランザクションが後で引き換えられることを可能にするプロトコルルールに従うという、新しいブロックを構築するノードの意図を示すものである。ブロックチェーンプロトコルルールは、この特別なトランザクションを引き換えられるようになるまで、成熟期間、たとえば100ブロックを必要とし得る。しばしば、通常の(非生成)トランザクション152はまた、そのトランザクションが公開されたブロック151nを作成したブロックチェーンノード104にさらに報酬を与えるために、その出力の1つにおいて追加のトランザクションフィーを指定する。この料金は普通は「マイニングフィー」と呼ばれ、以下で論じられる。
【0030】
トランザクションの妥当性確認および公開に関与するリソースにより、典型的にはブロックチェーンノード104の少なくとも各々が、1つまたは複数の物理サーバユニットを備えるサーバという形態をとり、またはデータセンター全体という形態すらとる。しかしながら、原理的には、あらゆる所与のブロックチェーンノード104は、一緒にネットワーク接続されたユーザ端末またはユーザ端末のグループという形態をとり得る。
【0031】
各ブロックチェーンノード104のメモリは、それぞれの役割を実行し、ブロックチェーンノードプロトコルに従ってトランザクション152を扱うように、ブロックチェーンノード104の処理装置上で実行するように構成される、ソフトウェアを記憶する。ブロックチェーンノード104に対する本明細書に起因するあらゆる活動が、それぞれのコンピュータ機器の処理装置で実行されるソフトウェアによって実施され得ることが理解されるだろう。ノードソフトウェアは、アプリケーション層における1つまたは複数のアプリケーションで、またはオペレーティングシステム層もしくはプロトコル層などのより低次の層で、またはこれらの任意の組合せで実装され得る。
【0032】
その各々が個人ユーザまたは団体である場合がある、消費するユーザの役割において複数の関係者103の各々のコンピュータ機器102もまた、ネットワーク101に接続される。これらのユーザは、ブロックチェーンネットワーク106と対話し得るが、トランザクションの検証、またはブロックの構築には参加しない。これらのユーザまたはエージェント103の一部は、トランザクションにおいて送信者または受信者として活動し得る。他のユーザは、必ずしも送信者または受信者として活動することなく、ブロックチェーン150と対話し得る。たとえば、一部の関係者は、ブロックチェーン150のコピーを記憶する(たとえば、ブロックチェーンノード104からブロックチェーンのコピーを取得した)ストレージエンティティとして活動し得る。
【0033】
関係者103の一部またはすべてが、異なるネットワーク、たとえばブロックチェーンネットワーク106に重畳されるネットワークの一部として接続され得る。ブロックチェーンネットワークのユーザ(「クライアント」と呼ばれることが多い)は、ブロックチェーンネットワーク106を含むシステムの一部であると言われることがある。しかしながら、これらのユーザはブロックチェーンノード104ではなく、それは、ブロックチェーンノードに必要とされる役割を実行しないからである。代わりに、各関係者103は、ブロックチェーンネットワーク106と対話し、それにより、ブロックチェーンノード106に接続する(すなわち、それと通信する)ことによって、ブロックチェーン150を利用し得る。第1の関係者103aおよびそのそれぞれのコンピュータ機器102a、ならびに第2の関係者103bおよびそのそれぞれのコンピュータ機器102bという、2名の関係者103および彼らのそれぞれの機器102が例示を目的に示されている。より多くのそのような関係者103およびそれぞれのコンピュータ機器102が、システム100において存在して参加していてもよいが、便宜的にそれらは示されていないことが理解されるだろう。各関係者103は、個人または組織であり得る。純粋に例示として、第1の関係者103aはAliceと本明細書では呼ばれ、第2の関係者103bはBobと呼ばれるが、これは限定するものではなく、本明細書でのAliceまたはBobへのあらゆる言及は、それぞれ「第1の関係者」および「第2の関係者」で置き換えられ得ることが理解されるだろう。
【0034】
各関係者103のコンピュータ機器102は、1つまたは複数のプロセッサ、たとえば1つまたは複数のCPU、GPU、他のアクセラレータプロセッサ、特定用途向けプロセッサ、および/またはFPGAを備える、それぞれの処理装置を備える。各関係者103のコンピュータ機器102はさらに、非一時的コンピュータ可読媒体の形式のメモリ、すなわちコンピュータ可読ストレージを備える。このメモリは、1つまたは複数のメモリ媒体、たとえばハードディスクなどの磁気媒体、SSD、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光学ディスクドライブなどの光学媒体を利用する、1つまたは複数のメモリユニットを備え得る。各関係者103のコンピュータ機器102のメモリは、処理装置上で実行するようになされる少なくとも1つのクライアントアプリケーション105のそれぞれのインスタンスを備えるソフトウェアを記憶する。所与の関係者103に対する本明細書に起因するあらゆる活動は、それぞれのコンピュータ機器102の処理装置上で実行されるソフトウェアを使用して実行され得ることが理解されるだろう。各関係者103のコンピュータ機器102は、少なくとも1つのユーザ端末、たとえばデスクトップもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを備える。所与の関係者103のコンピュータ機器102はまた、ユーザ端末を介してアクセスされるクラウドコンピューティングリソースなどの、1つまたは複数の他のネットワーク接続されたリソースを備え得る。
【0035】
クライアントアプリケーション105は最初に、たとえばサーバからダウンロードされる、あるいは、リムーバブルSSD、フラッシュメモリキー、リムーバブルEEPROM、リムーバブル磁気ディスクドライブ、磁気フロッピーディスクもしくはテープ、CDもしくはDVD ROMなどの光学ディスク、またはリムーバブル光学ドライブなどの、リムーバブルストレージデバイス上で提供される、適切なコンピュータ可読記憶媒体上の任意の所与の関係者103のコンピュータ機器102に提供され得る。
【0036】
クライアントアプリケーション105は、少なくとも「ウォレット」機能を備える。これには2つの主要な機能がある。これらのうちの1つは、それぞれの関係者103がトランザクション152を作成し、承認(たとえば署名)し、1つまたは複数のビットコインノード104に送信して、トランザクション152がブロックチェーンノード104のネットワーク全体に広められてブロックチェーン150に含まれるようにすることを可能にすることである。もう1つは、それぞれの関係者が現在所有するデジタル資産の額をそれぞれの関係者に報告することである。出力ベースのシステムでは、この第2の機能は、対象の関係者に属するブロックチェーン150全体に散在する様々な152トランザクションの出力において定義される額を照合することを備える。
【0037】
注意:様々なクライアント機能は所与のクライアントアプリケーション105へと統合されるものとして説明されることがあるが、これは必ずしも限定するものではなく、代わりに、本明細書において説明されるあらゆるクライアント機能は、一連の2つ以上の別個の適用例、たとえばAPIを介してインターフェースすること、または一方が他方へのプラグインであることにおいて実装され得る。より一般的には、クライアント機能は、アプリケーション層、またはオペレーティングシステムなどのより低次の層、またはこれらの任意の組合せにおいて実装され得る。以下は、クライアントアプリケーション105に関して説明されるが、それは限定するものではないことが理解されるだろう。
【0038】
各コンピュータ機器102上のクライアントアプリケーションまたはソフトウェア105のインスタンスは、ネットワーク106のブロックチェーンノード104のうちの少なくとも1つに動作可能に結合される。これは、クライアント105のウォレット機能がトランザクション152をネットワーク106に送信することを可能にする。クライアント105はまた、それぞれの関係者103が受信者であるあらゆるトランザクションについてブロックチェーン150にクエリするために、ブロックチェーンノード104に連絡することも可能である(または、実施形態では、ブロックチェーン150が、公的な存在であることにより一部トランザクションに信用をもたらす公的機関であるので、実際にブロックチェーン150における他の関係者のトランザクションを調査する)。各コンピュータ機器102のウォレット機能は、トランザクションプロトコルに従ってトランザクション152を編成して送信するように構成される。上で述べられたように、各ブロックチェーンノード104は、ブロックチェーンノードプロトコルに従ってトランザクション152を妥当性確認し、ブロックチェーンネットワーク106全体にトランザクション152を広めるためにそれらを転送するように構成される、ソフトウェアを実行する。トランザクションプロトコルおよびノードプロトコルは互いに対応し、所与のトランザクションプロトコルは所与のノードプロトコルを伴い、一緒に所与のトランザクションモデルを実装する。ブロックチェーン150の中のすべてのトランザクション152に対して、同じトランザクションプロトコルが使用される。同じノードプロトコルが、ネットワーク106の中のすべてのノード104によって使用される。
【0039】
所与の関係者103、たとえばAliceが、新しいトランザクション152jをブロックチェーン150に含まれるように送信することを望むとき、彼女は関連するトランザクションプロトコルに従って(彼女のクライアントアプリケーション105のウォレット機能を使用して)新しいトランザクションを編成する。彼女は次いで、クライアントアプリケーション105から、彼女が接続されている1つまたは複数のブロックチェーンノード104に、トランザクション152を送信する。たとえば、これは、Aliceのコンピュータ102に最善に接続されるブロックチェーンノード104であり得る。任意の所与のブロックチェーンノード104が新しいトランザクション152jを受信するとき、ブロックチェーンノード104は、ブロックチェーンノードプロトコルおよびそのそれぞれの役割に従って、新しいトランザクション152jを扱う。これは、新しく受信されたトランザクション152jが「有効」であるための何らかの条件を満たすかどうかをまず確かめることを備え、その例がまもなくより詳しく論じられる。一部のトランザクションプロトコルでは、妥当性確認のための条件は、トランザクション152に含まれるスクリプトによってトランザクションごとに構成可能であり得る。代替として、この条件は単に、ノードプロトコルの内蔵機能であってもよく、またはスクリプトとノードプロトコルの組合せによって定義されてもよい。
【0040】
新しく受信されるトランザクション152jが有効であるものとして見なされるように試験に合格する条件(すなわち、それが「妥当性確認される」条件)のもとで、トランザクション152jを受信する任意のブロックチェーンノード104が、新しい妥当性確認されたトランザクション152をそのブロックチェーンノード104に維持されているトランザクションの順序付けられたセット154に追加する。さらに、トランザクション152jを受信するあらゆるブロックチェーンノード104は、妥当性確認されたトランザクション152以降をネットワーク106の中の1つまたは複数の他のブロックチェーンノード104に広める。各ブロックチェーンノード104は同じプロトコルを適用するので、トランザクション152jが有効であると仮定すると、これは、それがまもなくネットワーク106全体に広められることを意味する。
【0041】
所与のブロックチェーンノード104において維持される保留中のトランザクションの順序付けられたプール154の利用を認められると、そのブロックチェーンノード104は、新しいトランザクション152を含むトランザクションのそれぞれのプール154の最新のバージョンについてのプルーフオブワークパズルを競って解き始める(他のブロックチェーンノード104が、トランザクションの異なるプール154に基づいてパズルを解こうとしていることがあるが、最初にたどり着いた者が最新のブロック151に含まれるトランザクションのセットを定義することを思い出されたい。最終的に、ブロックチェーンノード104は、Aliceのトランザクション152jを含む順序付けられたプール154の一部のためのパズルを解く)。プルーフオブワークが、新しいトランザクション152jを含むプール154に対して行われると、それはイミュータブルに、ブロックチェーン150の中のブロック151のうちの1つの一部になる。各トランザクション152は、より前のトランザクションへのポインタを備えるので、トランザクションの順序もイミュータブルに記録される。
【0042】
異なるブロックチェーンノード104は、所与のトランザクションの異なるインスタンスをまず受信するので、あるインスタンスが新しいブロック151において公開される前は、どのインスタンスが「有効」であるかについて矛盾した見方を有することがあり、それが公開される時点では、公開されるインスタンスが唯一の有効なインスタンスであることにすべてのブロックチェーンノード104が合意している。ブロックチェーンノード104があるインスタンスを有効であるものとして受け入れ、第2のインスタンスがブロックチェーン150に記録されていることを発見する場合、そのブロックチェーンノード104は、これを受け入れ、最初に受け入れたインスタンス(すなわち、ブロック151において公開されていないインスタンス)を廃棄する(すなわち、無効であるものとして扱う)。
【0043】
一部のブロックチェーンネットワークによって運用される代替のタイプのトランザクションプロトコルは、アカウントベースのトランザクションモデルの一部として、「アカウントベース」プロトコルと呼ばれることがある。アカウントベースの場合、各トランザクションは、過去のトランザクションのシーケンスの中の先行するトランザクションのUTXOを参照することによってではなく、絶対的なアカウント残高を参照することによって、移されるべき額を定義する。すべてのアカウントの現在の状態が、ブロックチェーンとは別に、そのネットワークのノードによって記憶され、定期的に更新される。そのようなシステムでは、トランザクションは、アカウントの実行中のトランザクションタリー(「ポジション」とも呼ばれる)を使用して順序付けられる。この値は、暗号署名の一部として送信者により署名され、トランザクション参照計算の一部としてハッシュされる。加えて、任意選択のデータフィールドはまた、署名されたトランザクションであってもよい。このデータフィールドは、たとえば以前のトランザクションIDがデータフィールドに含まれる場合、以前のトランザクションを指し示し得る。
【0044】
UTXOベースのモデル
図2は、例示的なトランザクションプロトコルを示す。これは、UTXOベースのプロトコルの例である。トランザクション152(「Tx」と省略される)は、ブロックチェーン150の基本データ構造である(各ブロック151は1つまたは複数のトランザクション152を備える)。以下は、出力ベースまたは「UTXO」ベースのプロトコルに言及して説明される。しかしながら、これはすべての可能な実施形態への限定ではない。例示的なUTXOベースのプロトコルはビットコインに言及して説明されるが、それは他の例示的なブロックチェーンネットワーク上で等しく実装され得ることに留意されたい。
図2は、例示的なトランザクションプロトコルを示す。これは、UTXOベースのプロトコルの例である。トランザクション152(「Tx」と省略される)は、ブロックチェーン150の基本データ構造である(各ブロック151は1つまたは複数のトランザクション152を備える)。以下は、出力ベースまたは「UTXO」ベースのプロトコルに言及して説明される。しかしながら、これはすべての可能な実施形態への限定ではない。例示的なUTXOベースのプロトコルはビットコインに言及して説明されるが、それは他の例示的なブロックチェーンネットワーク上で等しく実装され得ることに留意されたい。
【0045】
UTXOベースのモデルでは、各トランザクション(「Tx」)152は、1つまたは複数の入力202および1つまたは複数の出力203を備えるデータ構造を備える。各出力203は、未消費のトランザクション出力(UTXO)を備えてもよく、これは、別の新しいトランザクションの入力202のソースとして使用され得る(UTXOがまだ引き換えられていない場合)。UTXOは、デジタル資産の額を指定する値を含む。これは、分散型台帳上のある設定された数のトークンを表す。UTXOはまた、情報の中でもとりわけ、UTXOの由来であるトランザクションのトランザクションIDを含み得る。トランザクションデータ構造はヘッダ201も備えることがあり、これは入力フィールド202および出力フィールド203のサイズのインジケータを備えることがある。ヘッダ201はまた、トランザクションのIDを含むことがある。実施形態では、トランザクションIDは、トランザクションデータ(トランザクションID自体を除く)のハッシュであり、ノード104に出される生のトランザクション152のヘッダ201に記憶される。
【0046】
Alice 103aが、対象のある額のデジタル資産をBob 103bに移すトランザクション152jを作成することを望んでいるとする。図2において、Aliceの新しいトランザクション152jは「Tx1」とラベリングされる。Tx1は、シーケンスの中の先行するトランザクション152iの出力203においてAliceにロックされるデジタル資産の額をとり、その少なくとも一部をBobに移す。先行するトランザクション152iは、図2では「Tx0」とラベリングされる。Tx0およびTx1は任意のラベルにすぎない。それらは、Tx0がブロックチェーン151の最初のトランザクションであることを必ずしも意味せず、Tx1がプール154の中のすぐ次のトランザクションであることも意味しない。Tx1は、Aliceにロックされている未消費の出力203をまだ有するあらゆる先行する(すなわち、祖先)トランザクションを指し示し得る。
【0047】
先行するトランザクションTx0は、Aliceが新しいトランザクションTx1を作成するとき、または少なくとも彼女がそれをネットワーク106に送信するときにはすでに、ブロックチェーン150のブロック151において妥当性確認されそれに含まれていることがある。それは、その時点ですでにブロック151のうちの1つに含まれていることがあり、または、順序付けられたセット154においてまだ待機していることがあり、その場合、それは新しいブロック151にまもなく含められる。代替として、Tx0およびTx1は、一緒に作成されてネットワーク106に送信されてもよく、または、ノードプロトコルが「オーファン」トランザクションのバッファリングを許容する場合、Tx0がTx1の後に送信されることすらあってもよい。トランザクションのシーケンスの文脈で本明細書において使用される「先行する」および「後続の」という用語は、トランザクションにおいて指定されるトランザクションポインタによって定義されるようなシーケンスにおけるトランザクションの順序を指す(どのトランザクションがどの他のトランザクションを指し示すか、など)。それらは、「先行者」および「後継者」、または「祖先」および「子孫」、「親」および「子」などにより等しく置き換えられ得る。これは、それらが作成される順序、ネットワーク106に送信される順序、または任意の所与のブロックチェーンノード104に到達する順序を必ずしも示唆しない。それでも、先行するトランザクション(祖先トランザクションまたは「親」)を指し示す後続のトランザクション(子孫トランザクションまたは「子」)は、親トランザクションが妥当性確認されるまでは、かつ妥当性確認されない限り、妥当性確認されない。親より前にブロックチェーンノード104に到達する子は、オーファンであると見なされる。それは、ノードプロトコルおよび/またはノード挙動に応じて、廃棄され、または親を待機するためにある時間の間バッファリングされ得る。
【0048】
先行するトランザクションTx0の1つまたは複数の出力203のうちの1つは、ここでUTXO0とラベリングされる特定のUTXOを備える。各UTXOは、UTXOによって表されるデジタル資産の額を指定する値と、後続のトランザクションが妥当性確認されるようにするために、したがってUTXOの引き換えが成功するために、後続のトランザクションの入力202におけるアンロッキングスクリプトによって満たされなければならない条件を定義するロッキンスクリプトとを備える。通常、ロッキングスクリプトは、額を特定の関係者(ロッキングスクリプトが含まれるトランザクションの受益者)にロックする。すなわち、ロッキングスクリプトはアンロッキング条件を定義し、その条件は通常、後続のトランザクションの入力におけるアンロッキングスクリプトが、先行するトランザクションがロックされる対象である関係者の暗号署名を備えるという条件を備える。
【0049】
ロッキングスクリプト(scriptPubKeyとしても知られている)は、ノードプロトコルによって認識される分野特有の言語で書かれるコードである。そのような言語の具体的な例は、ブロックチェーンネットワークによって使用される「Script」(大文字のS)と呼ばれる。ロッキングスクリプトは、トランザクション出力203を消費するためにどの情報が必要とされるか、たとえば、Aliceの署名の要件を指定する。アンロッキングスクリプトは、トランザクションの出力に現れる。アンロッキングスクリプト(scriptSigとしても知られている)は、ロッキングスクリプト基準を満たすために必要とされる情報を提供する分野特有の言語で書かれるコードである。たとえば、それはBobの署名を含み得る。アンロッキングスクリプトはトランザクションの入力202に現れる。
【0050】
よって、示される例では、Tx0の出力203におけるUTXO0は、UXTO0が引き換えられるようにするために(厳密には、UTXO0を引き換えようとする後続のトランザクションが有効になるために)Aliceの署名SIG PAを必要とするロッキングスクリプト[Checksig PA]を備える。[Checksig PA]は、Aliceの公開-秘密鍵のペアからの公開鍵PAの表現(すなわち、ハッシュ)を含む。Tx1の入力202は、Tx1を指し示す(たとえば、そのトランザクションIDであるTxID0によって指し示す、TxID0は実施形態ではトランザクション全体Tx0のハッシュである)ポインタを備える。Tx1の入力202は、Tx0のあらゆる他のあり得る出力の中からUTXO0を特定するために、Tx0内でUTXO0を特定するインデックスを備える。Tx1の入力202はさらに、Aliceが鍵のペアからの自身の秘密鍵をデータのあらかじめ定められた部分(暗号学では「メッセージ」と呼ばれることがある)に適用することによって作成される、Aliceの暗号署名を備えるアンロッキングスクリプト<Sig PA>を備える。Aliceにより有効な署名を提供するために署名される必要のあるデータ(または「メッセージ」)は、ロッキングスクリプトによって、またはノードプロトコルによって、またはこれらの組合せによって定義され得る。
【0051】
新しいトランザクションTx1がブロックチェーンノード104に到達すると、ノードはノードプロトコルを適用する。これは、アンロッキングスクリプトがロッキングスクリプトにおいて定義される条件(この条件は1つまたは複数の基準を備え得る)を満たすかどうかを確かめるために、ロッキングスクリプトおよびアンロッキングスクリプトを一緒に実行することを備える。実施形態では、これは2つのスクリプトを連結することを伴う。
<Sig PA><PA>||[Checksig PA]
ここで、「||」は連結を表し、「<...>」はスタックにデータを置くことを意味し、「[...]」はロッキングスクリプト(この例では、スタックベース言語)に含まれる関数である。等価的に、スクリプトを連結するのではなく、スクリプトは共通のスタックを用いて次々に実行されてもよい。いずれにしても、一緒に実行されると、スクリプトは、Tx0の出力の中のロッキングスクリプトに含まれるような、Aliceの公開鍵PAを使用して、Tx1の入力の中のアンロッキングスクリプトがデータの予想される部分に署名するAliceの署名を含むことを認証する。データ自体(「メッセージ」)の予想される部分も、この認証を実行するために含まれる必要がある。実施形態では、署名されたデータはTx1の全体を備える(よって、平文でデータの署名された部分を指定する別個の要素が含まれる必要がなく、それは、もともと存在していたからである)。
<Sig PA><PA>||[Checksig PA]
ここで、「||」は連結を表し、「<...>」はスタックにデータを置くことを意味し、「[...]」はロッキングスクリプト(この例では、スタックベース言語)に含まれる関数である。等価的に、スクリプトを連結するのではなく、スクリプトは共通のスタックを用いて次々に実行されてもよい。いずれにしても、一緒に実行されると、スクリプトは、Tx0の出力の中のロッキングスクリプトに含まれるような、Aliceの公開鍵PAを使用して、Tx1の入力の中のアンロッキングスクリプトがデータの予想される部分に署名するAliceの署名を含むことを認証する。データ自体(「メッセージ」)の予想される部分も、この認証を実行するために含まれる必要がある。実施形態では、署名されたデータはTx1の全体を備える(よって、平文でデータの署名された部分を指定する別個の要素が含まれる必要がなく、それは、もともと存在していたからである)。
【0052】
公開-秘密暗号による認証の詳細は、当業者には馴染みがある。基本的に、Aliceが自身の秘密鍵を使用してメッセージに署名した場合、平文のAliceの公開鍵およびメッセージを与えられると、ノード104などの別のエンティティは、メッセージがAliceによって署名されたに違いないことを認証することが可能である。署名することは通常、メッセージをハッシュし、ハッシュに署名し、これを署名としてメッセージへとタグ付けすることで、公開鍵のあらゆる保有者が署名を認証することを可能にすることを備える。したがって、本明細書における、特定のデータまたはトランザクションの一部に署名することなどへのあらゆる言及は、実施形態では、そのデータまたはトランザクション一部のハッシュに署名することを意味することに留意されたい。
【0053】
Tx1におけるアンロッキングスクリプトがTx0のロッキングスクリプトにおいて指定される1つまたは複数の条件を満たす場合(よって示される例では、Aliceの署名がTx1において提供されて認証される場合)、ブロックチェーンノード104はTx1を有効であると見なす。これは、ブロックチェーンノード104がTx1を未処理のトランザクションの順序付けられたプール154に追加することを意味する。ブロックチェーンノード104はまた、ネットワーク106の中の1つまたは複数の他のブロックチェーンノード104にトランザクションTx1を転送するので、それは、ネットワーク106全体に広められる。Tx1がブロックチェーン150において妥当性確認され含められると、これは消費されるものとしてTx0からのUTXO0を定義する。Tx1は、未消費のトランザクション出力203を消費する場合にのみ、有効であり得ることに留意されたい。別のトランザクション152によってすでに消費されている出力を消費しようとする場合、Tx1は、すべての他の条件が満たされている場合でも無効になる。したがって、ブロックチェーンノード104は、先行するトランザクションTx0の中の参照されるUTXOがすでに消費されているかどうか(すなわち、すでに有効な入力を別の有効なトランザクションへと形成したかどうか)を確かめる必要もある。これは、トランザクション152に定められた順序を課すことがブロックチェーン150にとって重要である1つの理由である。実際には、所与のブロックチェーンノード104は、トランザクション152がその中で消費されたどのUTXO203をマークする別個のデータベースを維持してもよいが、究極的には、UTXOが消費されたかどうかを定義するものは、UTXOが有効な入力をブロックチェーン150の中の別の有効なトランザクションへとすでに形成したかどうかである。
【0054】
所与のトランザクション152のすべての出力203において指定される総額が、すべてのその入力202によって指し示される総額より大きい場合、これもまた、大半のトランザクションモデルにおいて、無効であることの根拠になる。したがって、そのようなトランザクションは、広められず、ブロック151にも含められない。
【0055】
UTXOベースのトランザクションモデルにおいて、所与のUTXOは全体として消費される必要があることに留意されたい。それは、消費されるものとしてUTXOにおいて定義される額の一部を、別の一部が消費されながら「置き去りにする」ことができない。しかしながら、UTXOからの額は、次のトランザクションの複数の出力の間で分割され得る。たとえば、Tx0の中のUTXO0において定義される額は、Tx1の中の複数のUTXO間で分割され得る。したがって、AliceがUTXO0において定義される額のすべてをBobに与えることを望まない場合、彼女はリマインダーを使用してTx1の第2の出力の残金を自分に与え、または別の関係者に支払うことができる。
【0056】
実際には、Aliceはまた通常、ブロック151に自分のトランザクション104を含むことに成功するビットコインノード104に対する料金を含める必要がある。Aliceがそのような料金を含めない場合、Tx0はブロックチェーンノード104によって拒絶されてもよく、したがって、技術的には有効であっても、広められず、ブロックチェーン150に含められなくてもよい(ノードプロトコルは、ブロックチェーンノード104がトランザクション152を受け入れることを望まない場合、それを強いることはない)。一部のプロトコルでは、トランザクションフィーは、固有の別々の出力203を必要としない(すなわち、別個のUTXOを必要としない)。代わりに、入力202によって指し示される総額と所与のトランザクション152の出力203において指定される総額とのあらゆる差が、トランザクションを公開するブロックチェーンノード104に自動的に与えられる。たとえば、UTXO0へのポインタがTx1への唯一の入力であり、Tx1が唯一の出力UTXO1を有するとする。UTXO0において指定されるデジタル資産の額が、UTXO1において指定される額よりも大きい場合、その差は、UTXO1を含むブロックを作成するためにプルーフオブワークのレースに勝つノード104によって割り当てられ得る。しかしながら、代替または追加として、トランザクションフィーが、トランザクション152のUTXO203のうちの自身固有のUTXOにおいて明示的に指定され得ることは、必ずしも排除されない。
【0057】
AliceおよびBobのデジタル資産は、ブロックチェーン150のどこかにある任意のトランザクション152において彼らにロックされるUTXOからなる。したがって、通常は、所与の関係者103の資産は、ブロックチェーン150全体の、様々なトランザクション152のUTXO全体に分散している。所与の関係者103の総残高を定義する1つの数字が、ブロックチェーン150のどこかに保管されているということはない。それぞれの関係者にロックされており、別のその先のトランザクションにおいてまだ消費されていないすべての様々なUTXOの値を一緒に照合することが、クライアントアプリケーション150のウォレット機能の役割である。そのウォレット機能は、ビットコインノード104のいずれかに記憶されているようなブロックチェーン150のコピーをクエリすることによって、これを行うことができる。
【0058】
スクリプトコードはしばしば、概略的(すなわち、厳密な言語を使用せずに)に表現されることに留意されたい。たとえば、特定の関数を表すためにオペレーションコード(オペコード)を使用することがある。「OP_...」は、Script言語の特定のオペコードを指す。例として、OP_RETURNは、ロッキングスクリプトの最初おいてOP_FALSEが前にあるとトランザクション内のデータを記憶できるトランザクションの消費不可能な出力を生み出し、それによりブロックチェーン150にデータをイミュータブルに記録するような、Script言語のオペコードである。たとえば、データは、ブロックチェーンに記憶することが望まれる文書を備え得る。
【0059】
通常、トランザクションの入力は、公開鍵PAに対応するデジタル署名を含む。実施形態では、これは、楕円曲線secp256k1を使用するECDSAに基づく。デジタル署名は特定のデータに署名する。いくつかの実施形態では、所与のトランザクションに対して、署名はトランザクション入力の一部、およびトランザクション出力の一部またはすべてに署名する。署名する出力の具体的な部分は、SIGHASHフラグに依存する。SIGHASHフラグは普通は、どの出力が署名されるかを選択するために署名の最後に含まれる(したがって署名の時点で固定される)4バイトのコードである。
【0060】
ロッキングスクリプトは時々「scriptPubKey」と呼ばれ、それぞれのトランザクションがロックされる対象である関係者の公開鍵をロッキングスクリプトが通常は備えるという事実を指している。アンロッキングスクリプトは時々「scriptSig」と呼ばれ、アンロッキングスクリプトが対応する署名を通常は供給するという事実を指している。しかしながら、より一般的には、UTXOが引き換えられるようにするための条件が署名を認証することを備えることは、ブロックチェーン150のすべての適用例において必須ではない。より一般的には、スクリプト言語は、任意の1つまたは複数の条件を定義するために使用され得る。したがって、より一般的な用語「ロッキングスクリプト」および「アンロッキングスクリプト」が好まれることがある。
【0061】
レイヤ2オーバーレイネットワーク
ブロックチェーンネットワーク106はすでに、インターネット101などのネットワーク上にオーバーレイされたオーバーレイネットワークの形態である。しかしながら、ブロックチェーンにオーバーレイネットワークの別のレイヤを層状に重ねることも可能である。これは、図3に例として示されている。一例がMetanetである。そのようなネットワークは、それが、下にあるネットワークインフラストラクチャとしてのベースネットワーク101(たとえば、インターネット)、およびベースネットワーク上にオーバーレイされたオーバーレイネットワークの第1のレイヤとしてのブロックチェーンネットワーク106に対して、オーバーレイネットワークの第2のレイヤであるという意味において、「レイヤ2」ネットワークと呼ばれることもある。
ブロックチェーンネットワーク106はすでに、インターネット101などのネットワーク上にオーバーレイされたオーバーレイネットワークの形態である。しかしながら、ブロックチェーンにオーバーレイネットワークの別のレイヤを層状に重ねることも可能である。これは、図3に例として示されている。一例がMetanetである。そのようなネットワークは、それが、下にあるネットワークインフラストラクチャとしてのベースネットワーク101(たとえば、インターネット)、およびベースネットワーク上にオーバーレイされたオーバーレイネットワークの第1のレイヤとしてのブロックチェーンネットワーク106に対して、オーバーレイネットワークの第2のレイヤであるという意味において、「レイヤ2」ネットワークと呼ばれることもある。
【0062】
オーバーレイネットワーク300のこの第2の層は、ノード301およびエッジ302のネットワークを含む。ノード301は今、Metanet(またはブロックチェーンにオーバーレイされた他のそのようなネットワーク)のレイヤのノードを指し、図1および図2に関して前に説明したブロックチェーンネットワーク106のレイヤにおけるノード104ではないことに留意されたい。Metanetネットワーク(または同様のもの)の各ノード301は、ブロックチェーン150上の異なるそれぞれのトランザクション152であり、その各々が、それぞれのトランザクションのペイロードにデータを記憶する。したがって、Metanetネットワーク300(または同様のもの)のノード301は、本明細書ではデータ記憶ノードまたはデータ記憶トランザクションと呼ばれることもある。そこに記憶されたデータは、データコンテンツおよび/またはメタデータを含み、一般的には両方を含み得る。出力ベースのモデルでは、データは、それぞれのトランザクションの支出不可出力203に記憶され得る。出力は、実行時にスクリプトを終了する、ロッキングスクリプト内の1つまたは複数のオペコードによって支出不可にされてもよい。たとえば、スクリプト言語を使用するシステムでは、これは、使用されるプロトコルに応じて、OP_RETURNオペコードであってもよく、またはOP_FALSE続いてOP_RETURNであってもよい。しかしながらこれは限定ではなく、他のブロックチェーンシステムにおいて、たとえばアカウントベースのモデルを使用するシステムにおいて、トランザクションに任意のペイロードデータを記憶するための他の技法を当業者は承知であろう。以下は、出力ベースのモデルに関して例示される場合があるが、これは限定ではない。
【0063】
レイヤ2オーバーレイネットワーク300は、純粋にデータからなり、完全に仮想的であり得ることに留意されたい。すなわち、ブロックチェーン150のトランザクション152にオーバーレイされたオーバーレイネットワークとしての、Metanetなどのノード301およびエッジ32は、必ずしも下にあるブロックチェーンネットワーク106または下にあるネットワークインフラストラクチャ101のいずれか特定の物理的アクタ(actor)またはエンティティに対応しない。
【0064】
データコンテンツは、たとえばテキスト、音声、静止画もしくは動画、または他のドキュメントを記憶するためにMetanet(または同様のもの)が使用されている実際のデータである。データコンテンツは、ユーザコンテンツまたはユーザデータと呼ばれることもある。メタデータは、ブロックチェーン150にネットワークを層状に重ねるためのプロトコルを実装する。トランザクション152の少なくとも一部では、メタデータは、データコンテンツ間のリンクを定義する。これらは、ノード301間のエッジ302として説明されることもある。リンクまたはポインタは、たとえば、親ノードのトランザクションID、TxIDparentを含んでもよい。本明細書で言及する「リンク」は必ずしもハイパーテキストリンクを意味するとは限らないが、それは1つの可能性であることに留意されたい。より一般的にはリンクは、Metatnetレイヤ(またはブロックチェーン150に層状に重ねられた他のそのようなオーバーレイレイヤ)において現在のノード301が関連している別のノード301を指し示すどんな形態のポインタも指すことができる。
【0065】
便宜上、以下は、Metanetに関して例として説明することになるが、これは限定ではなく、より一般的には、Metanetに言及する本明細書のどこでも、これはブロックチェーン上にオーバーレイされたどんなオーバーレイネットワークに置き換えられてもよいことが諒解されよう。同様に、Metanetノードへのいずれの言及も、いずれのオーバーレイネットワークノード、またはオーバーレイネットワークのデータストレージノードへの言及に置き換えられてもよく、Metanetリンクまたはエッジへのいずれの言及も、当該のオーバーレイネットワークのレイヤにおけるいずれのオーバーレイネットワークエッジまたはリンクへの言及に置き換えられてもよい。
【0066】
Metanetプロトコルは、パブリックブロックチェーンに記憶され、多くの使用事例に様々なアプリケーションにおいて使用され得るオンチェーンデータを構築するための方式および規格を定義する。プロトコルは、ノードおよびエッジを含む、グラフ構造が、ブロックチェーントランザクションのセットから構成できること、ならびにこれらの構造が、どんな性質のデータ(「コンテンツ」)も記憶、搬送、表現、および配信するために使用され得ることを指定する。トランザクションをノードとして、および署名をトランザクション間で作成されたエッジとして扱うことによって、Metanetプロトコルは、図3に示すオンチェーングラフ構造の作成を可能にする。
【0067】
図からわかるように、Metanet300のノード301およびエッジ302は、木構造を形成する。すなわち、親ノード301は、1つまたは複数の子ノード301にリンクされ、任意の所与の子301はそれ自体が、それ自体の1つまたは複数の子にリンクされた親であるなどであってもよい。目下の目的のための当該の木構造は、より広い木またはグラフのサブセットであるにすぎない場合があることに留意されたい。
【0068】
図3はまた、ノード301およびそれの関連するエッジ302がどのように更新され得るかを示す。トランザクションはブロックチェーン152に不変に記録されるので、Metanetノード301への更新は、新しいトランザクション152によって、新しいインスタンス301'および対応するエッジ302'を作成することを必要とする。
【0069】
図3の構造は、入れ子になった領域、たとえばウェブサイトおよびそれのページの構造を含んでもよく、ここで「トップレベル領域」がそれの下のサブ領域などを封入する。1つの機能的鍵領域(後で説明する、たとえば、書込み鍵、資金提供鍵(funding key)、または暗号化鍵の領域)は、これらの構造領域の多くに及ぶことができる。
【0070】
図3の円はノードを表し、ノードは単に、Metanetプロトコルのルールセットに従って作成されたトランザクションである。そのルールセットに従って作成され、形式を定められたトランザクション152Nの一例を、図4に示す。
【0071】
図4の右側のトランザクション152Cは、Metanetの所与のノード301C(子)を実装するブロックチェーン150のトランザクション152を表す。図4の左上のトランザクション152Pは、Metanetレイヤにおいて子ノード152Cの親を実装するブロックチェーン150のトランザクションを表す。子ノードトランザクション152Cは、アンロッキングスクリプトを含み、ブロックチェーン150の資金提供トランザクション152Fの出力203を指し示す入力202を有する。言い換えれば、資金提供トランザクション152Fの出力は、Metanetノード152Cの入力によって消費される。資金提供トランザクション152FおよびMetanet親トランザクション152Pは必ずしも同じトランザクションではない(しかしそれは除外もされない)ことに留意されたい。
【0072】
子トランザクション152Cは、たとえば、OP_RETURNによって支出不可にされた、ペイロード(ブロックチェーンレイヤの観点からのペイロード)を維持する、支出不可出力203を含む。このペイロードは、ハッシュ化および/または暗号化された、Metanetのデータコンテンツ(「Data」)を含んでもよく、または単に(「平文の」)生データであってもよい。
【0073】
子トランザクション152Cのペイロードはまた、Metanetネットワークレイヤのメタデータを含む。このメタデータは、少なくとも親トランザクション152Pのトランザクション識別子を含む。これは、Metanetレイヤにおいてリンク(エッジ)302を作成する。子ノード301Cに関連する鍵Pnodeを含むことが、Metanetプロトコルによって必要とされる場合もある。
【0074】
資金提供トランザクション152Fの出力203のロッキングスクリプトはまた、子ノード152Cの入力202のアンロッキングスクリプトに含まれる署名を必要とする。詳細には、この署名は、Metanet親に関連する鍵Pparentを使用して署名された署名(すなわち、その鍵によって署名されたメッセージ)であることが必要とされる。これは、ブロックチェーンレイヤにおいてエッジ402(支出エッジと呼ばれることがある)を作成する。子トランザクション152Cの入力202のアンロッキングスクリプトに、必要な署名が含まれていない場合、子トランザクション152Cは、ブロックチェーンネットワーク106のノード104によって有効にされないことになり、したがってブロックチェーンネットワーク106を通して伝搬されず、ブロックチェーン150に記録もされないことになる。しかしながらこの場合も、資金提供トランザクション152Fは必ずしもMetanet親トランザクション152Pと同じブロックチェーントランザクション152ではなく、したがってブロックチェーンレイヤ支出エッジ402は、必ずしもMetanetレイヤエッジ302と同じではないことに留意されたい。
【0075】
図4は、Metanetトランザクションの単にいくつかの関連する構成要素を、全体としてトランザクションの抽象化として概説する。これらの構成要素は、プロトコル識別子フラグに加えて、
・ 公開鍵Pnodeと、
・ 親公開鍵PParentの署名SigPParentと、
・ ノード自体のトランザクションID TxIDnodeと、
・ ノードの親のトランザクションID TxIDParentと
を含む。
・ 公開鍵Pnodeと、
・ 親公開鍵PParentの署名SigPParentと、
・ ノード自体のトランザクションID TxIDnodeと、
・ ノードの親のトランザクションID TxIDParentと
を含む。
【0076】
プレースホルダ<Data>は一般に、Metanetノードトランザクションに含まれ得る任意のコンテンツデータを指す。いくつかの適用例では、暗号化鍵ekでデータを暗号化したいであろうことも考えられるが、その場合、トランザクションに含まれるデータは、<e(Data,ek)>とされ、ここでe( )は好適な暗号化関数である。
【0077】
各Metanetノード301は、ペア(Pnode,TxIDnode)によって一意に識別でき、これは強力なバージョニングおよびパーミッショニング制御がMetanetグラフによって受け継がれることを可能にするインデックスである。各Metanetノードが、それ自体(Pnode,TxIDnode)およびそれの親(Pparent,TxIDparent)を識別するのに十分な情報を含むことも諒解されたい。
【0078】
Metanet子ノード301Cトランザクションが、親ノード301Pからの正しい入力署名SigPparentを含むことを保証するために、多くの場合、1つまたは複数の資金提供トランザクション152Fを作成してこれを容易にすることが望ましい場合があり、これを図4の左下に示している。
【0079】
親鍵Pparentおよび/または子ノード鍵Pnodeは、子ノード301Cのデータをブロックチェーン150に書き込む権限を与える書込み鍵として見ることができる。
【0080】
Metanetはしたがって、ブロックチェーン自体の下にある技術のみを使用して、そのようなデータに対するパーミッショニングおよび書込みアクセス制御を符号化するようにして、オンチェーンデータが構築されることを可能にするプロトコル提供する。Metanetプロトコルは、したがって、ユーザがユーザのオンチェーンコンテンツを証明可能な方法で所有することを可能にするソリューションである。
【0081】
Metanetプロトコルは、Metanet有向非巡回グラフ(Metanet Direct Acyclic Graph: Metanet DAG)の作成を可能にするルールのセットを定義する。Metanet DAGの単一の事例は、Metanet木と呼ばれる。各Metanet木は、根ノード(最上レベルのノード)を有し、根ノードを含む各Metanetノードは、1つまたは複数の子ノード(たとえば、再び図3参照)を有することができる。
【0082】
したがって、Metanet DAGは、木の大域集合になり、ここで各木は、それ自体の根ノードから始まり、それ自体の局所化されたパーミッショニング構造を有することができる。
【0083】
Metanetノード301は単に、Metanetプロトコルのルールセットに従うトランザクションである。2つのタイプのノード、すなわち親のない根ノードと、子ノードとがあり、所与の子ノードは、厳密に1つの親を有する。1つの実装形態によれば、Metanetノードの最も基本的なアウトライン構造は、以下の基準を満たすトランザクションを必要とする。
・ トランザクションは少なくとも1つのOP_RETURN出力を有する。
・ OP_RETURNペイロードは、以下を含む。
○ Metanetフラグ。
○ ノードアドレスPnode。
○ 親トランザクションID TxIDparent。
・ 根ノードを除く、各トランザクションが、親ノードによって署名された入力を含む。
上述のように、Metanetノードは、以下の4つの要素を含むトランザクション152である。
・ Pnode -ノードのアドレス。
・ TxIDnode -ノードのバージョン。
・ Pparent -ノードの親のアドレス。
・ TxIDparent -ノードの親のバージョン。
・ トランザクションは少なくとも1つのOP_RETURN出力を有する。
・ OP_RETURNペイロードは、以下を含む。
○ Metanetフラグ。
○ ノードアドレスPnode。
○ 親トランザクションID TxIDparent。
・ 根ノードを除く、各トランザクションが、親ノードによって署名された入力を含む。
上述のように、Metanetノードは、以下の4つの要素を含むトランザクション152である。
・ Pnode -ノードのアドレス。
・ TxIDnode -ノードのバージョン。
・ Pparent -ノードの親のアドレス。
・ TxIDparent -ノードの親のバージョン。
【0084】
Metanetエッジ302が、署名によって作成される。親ノードから子ノードへのエッジを作成するために、子ノードは、それの親に関連する鍵ペアを使用して署名されなければならず、Sig Pparentが子ノードの入力に見られなければならない。
【0085】
ブロックチェーンベースのオペレーティングシステム
オペレーティングシステム(OS)が、コンピュータ上で動作するソフトウェア(たとえば、プログラム、タスク、またはスレッド)をスケジュールし、コンピュータのハードウェアリソースへのそれらのアクセスを調整するソフトウェアとして定義される。たとえば、オペレーティングシステムは、プロセッサ時間、メモリ割振り、ならびに、コンピュータの入力および出力(たとえば、ポートまたは周辺デバイス)へのアクセスを与える。一般に、OSは、ユーザまたはシステム管理者によってインストールされ、専有の集中型サーバを使用して製作者によって更新される。さらに、システム管理者が、OSおよび他のコンピュータプログラムを管理し、更新およびバグ修正をインストールし、それらの完全性を検証する。
オペレーティングシステム(OS)が、コンピュータ上で動作するソフトウェア(たとえば、プログラム、タスク、またはスレッド)をスケジュールし、コンピュータのハードウェアリソースへのそれらのアクセスを調整するソフトウェアとして定義される。たとえば、オペレーティングシステムは、プロセッサ時間、メモリ割振り、ならびに、コンピュータの入力および出力(たとえば、ポートまたは周辺デバイス)へのアクセスを与える。一般に、OSは、ユーザまたはシステム管理者によってインストールされ、専有の集中型サーバを使用して製作者によって更新される。さらに、システム管理者が、OSおよび他のコンピュータプログラムを管理し、更新およびバグ修正をインストールし、それらの完全性を検証する。
【0086】
このソリューションは、大きいサーバおよびアドホックな複合機には最適な選択であるが、たとえば標準化されたソフトウェアを使用するより小さいデバイスおよびシステムには非効率的であることがある。これらのデバイスは、ブロックチェーンに記憶され、要求時にダウンロードされ得る、標準的な、小さいサイズの、常に利用可能で更新されたオペレーティングシステムから恩恵を受けることができる。これは特に、小さいオペレーティングシステムを使用し、限られた量のリソースを有するIoTデバイスに適用可能である。IoTデバイスは、数千のコピーにおいて生成され、広域にわたって散在していることがある。したがって、IoTデバイスは、非集中的ブロックチェーンソリューションから恩恵を受けることができる。それらのソリューションは、オンチェーンで不変に記憶された真正のデータにアクセスできるいずれかの利用可能なブロックチェーンノードに接続することができる(それらは他のノードを用いてダブルチェックするためにSPVまたは同様の方法を使用することもできる)からである。IoTデバイスは、オンチェーンで利用可能なオペレーティングシステムのライブディストリビューションをダウンロードし、実行してもよく、それらはそれらの管理者によって(たとえば、実行されるデバイス固有のコマンドまたはコードに送信するためにビットコインネットワークを使用して)遠隔制御されることがある。
【0087】
本開示は、オペレーティングシステムの一部または全部がオンチェーンで公開されること、およびしたがって任意の(互換性がある)デバイス上で実行されるようにアクセスされることを可能にする、新しい技法を提供する。実施形態は、オペレーティングシステムのファイルを構築するためにMetanetなどのオーバーレイ木構造を使用してもよい。さらなる実施形態では、任意のデバイスは、任意の(互換性がある)オペレーティングシステムをダウンロードし、実行することができ、必要とされる唯一の情報は固有のOSを記憶するために使用されるMetanet木の根である。同じ木は、1つまたは複数のデバイスによって実行されるコマンドおよびコード(たとえば、スマートコントラクト)を公開するために使用され得る。
【0088】
オペレーティングシステム(OS)、ドライバ、ならびに何らかの必要とされるファイルおよびプログラムは、オンチェーンで記憶されるか、または第三者サーバに記憶され、コミットされたオンチェーンでハッシュされることがある。MetanetベースのOSは、OSの検証可能なバージョンが必要とされる適用例、および/またはプログラム一式が証明可能な方法でインストールされなければならない適用例において使用され得る。加えて、MetanetベースのOSは、ソフトウェア更新およびバグ修正プロセスを改善するために使用され得る。
【0089】
より一般的には、オペレーティングシステム(OS)ソフトウェアが、オーバーレイ木構造で配置されているか否かにかかわらず、ブロックチェーン150上のいずれか1つまたは複数のブロックチェーントランザクションのペイロードに記憶され得る。オペレーティングシステムソフトウェアは、ブロックチェーンのクライアントであるいずれか1つまたは複数のクライアントデバイス102によって、クライアントデバイス102上で実行されるように、ブロックチェーン150からアクセスされもよい。オンチェーンのオペレーティングシステムソフトウェアは、クライアントデバイス102によって必要とされるオペレーティングシステム全体を含むことがあり、またはクライアントデバイス102にすでにインストールされた既存のオペレーティングソフトウェアを補うために使用される一部のみであることもある。
【0090】
当該のクライアントデバイス102の各々は、デスクトップコンピュータ、ラップトップ、タブレット、スマートフォンなどの任意のコンピュータデバイス、またはスマートウォッチもしくはスマートメガネなどのウェアラブルデバイスであってもよい。実施形態では、オンチェーンOSソフトウェアにアクセスする1つまたは複数のクライアントデバイス102は、1つまたは複数のモノのインターネット(IoT)デバイス、たとえば専用センサデバイスを含んでもよい。そのようなIoTデバイスは、それ自体の筐体に画面および/またはキーボードもしくはキーパッドが含まれていない場合がある。実施形態では、IoTデバイス102は、それ自体の筐体にユーザ入力および/または出力手段がまったく組み込まれていない場合がある。
【0091】
好ましくは、オペレーティングシステムソフトウェアは、ブロックチェーン150上にオーバーレイされたオーバーレイネットワークの木構造において記憶される。実施形態ではこれは、Metanetプロトコルに従って構成されたMetanet木であってもよい。
【0092】
図5に一例を示す。図示のように、根ノード301Rと、複数の葉ノード301Lとを含む、木構造が作成される。木構造は、たとえば、1人または複数のユーザ103のそれぞれのコンピュータ機器(クライアントデバイス)102が使用するための中心的リソースとしてオペレーティングシステムの製作者のコンピュータ機器によって作成されてもよい。
【0093】
根ノード301Rは、少なくとも1つの子ノード301Cの親ノード301Pである。根301R以外の各ノードは、少なくとも子ノード301Cであり、別の子301Cの親ノード301Pである場合もある。子ノード301Cと別の子の親ノード301Pの両方であるノードは、本明細書では木の中間ノード301Iと呼ばれることがある。
【0094】
根301R以外の各ノード301I、301L(すなわち、各子ノード301C)は、1つのエッジ302によってそれぞれの親ノード301Pに接続され、親ノード301Pは、根ノード301Rであるか、またはそれ自体が別の親の子である中間の親ノード301Iであることがある。すなわち、木には2つ以上のレベルがあり得る。各葉ノード301Lは、単に子ノード302Cである。いくつかの場合、根ノード301Rは、葉ノード301Lの1つまたは複数の親ノード301Pであってもよい。および/または、木に2つ以上のレベルがある場合には、中間レベルノード301Iが、1つまたは複数の葉ノード301Lの親301Pであり、各中間レベルノード301Iの親は、木のレベル数に応じて、それ自体が別の、より高いレベルの中間ノード301Iであるか、または根ノード301Rである場合がある。
【0095】
各ノード301は、たとえば図3および図4に関して本明細書で説明するように、ブロックチェーン150の異なるトランザクション152である。各エッジ302は、ノード301のペア間のリンクである。エッジ302は、親の対応する公開鍵を使用して認証され得る、それぞれの親ノードに関連する秘密鍵で子ノードを暗号的に署名することによって作成される。実施形態では、これらのエッジ302は、図3および図4に関して説明したように作成される。すなわち、各ノード152は、少なくとも1つの入力202と、少なくとも1つの出力203とを含む出力ベースのモデル(たとえば、UTXOベースのモデル)のトランザクションであり、エッジ302は、親ノード301Pの秘密鍵で子ノード301Cの入力202を署名することによって作成される。子301Cをチェーンに記録するために、子301Cの入力は、そのロッキングスクリプトがアンロックのために、したがって子ノードトランザクション301C/152Cがブロックチェーンへの記録のためにブロックチェーンネットワーク106によって有効にされるために、親の署名を必要とする資金提供トランザクション152Fの出力203を指し示す。親ノードの鍵は、親ノード301Pの出力203のペイロードに含まれることによって、それぞれの親ノード301Pに関連付けられてもよい。また親301PのトランザクションIDは、子301Cの出力のペイロードに含まれてもよい。再び例として図4を参照する。ペイロードは、たとえば、使用されるプロトコルに応じて、OP_RETURNまたはOP_FALSEおよびOP_RETURNによって支出不可にされた、それぞれのトランザクションの支出不可出力に含まれてもよい。実施形態では、オーバーレイプロトコルは、Metanetプロトコルであってもよく、したがって木構造は、Metanetグラフまたはそれの一部の形態をとってもよい。
【0096】
しかしながら、他のオーバーレイプロトコルでは、トランザクション152間にオーバーレイエッジを作成し、したがってそれらのトランザクションが木のノードを形成する木構造を形成するために、他の方法が使用され得ることは排除されない。また、木構造は、アカウントベースのモデルでスマートコントラクトを用いるなど、他のタイプのトランザクションモデルを使用して形成され得る。以下および本明細書の他の場所で開示する技法は、明示的に記述がない限り、出力ベースのトランザクションモデルに限定されない。
【0097】
本明細書で開示する実施形態によれば、オペレーティングシステムの少なくとも一部を含むオペレーティングシステムソフトウェアは、図5に示すオーバーレイ木構造のようなオーバーレイ木構造の1つまたは複数の子ノード301Cに記憶されてもよい。実施形態では、オペレーティングシステムソフトウェアは、1つまたは複数の葉ノード301Lに記憶される。当該の一部は、オペレーティングシステムの少なくとも何らかの実行可能コードを含む。オペレーティングシステムソフトウェアはまた、他の要素、たとえば設定ファイルなどの1つまたは複数のデータファイルを含んでもよい。実施形態では、OS全体は、チェーン上に記憶される。
【0098】
OS(または実施形態ではコマンド-後で参照)を記憶する1つまたは複数の子ノード301C(たとえば、葉ノード301L)のトランザクションは、本明細書では標的トランザクションと呼ばれることがあり、そこに記憶されたオペレーティングシステムソフトウェア(またはコマンド)にアクセスするための標的である。OSソフトウェアは、標的トランザクションのペイロードに、いくつかの場合、複数の標的トランザクションのペイロードにわたって、記憶されてもよい。出力ベースの(たとえば、UTXOベースの)トランザクションモデルでは、各標的トランザクションのそれぞれのペイロードは、それぞれの標的トランザクションの1つまたは複数のそれぞれの出力203(たとえば、UTXO)に含まれてもよい。これらは、たとえば、使用されるプロトコルに応じて、OP_RETURNオペコードまたはOP_FALSEおよびOP_RETUTNによって支出不可にされた、1つまたは複数の支出不可出力であってもよい。オペレーティングシステムソフトウェアは、親ノード(図4参照)のIDを記録するために使用される出力と同じ出力203に、または異なる出力203に記憶されてもよい。他の変形態では、ペイロードは、たとえば、アカウントベースのモデルのスマートコントラクトに含まれ得る。
【0099】
図9は、IoTデバイスなどのクライアントデバイス102が、ブロックチェーン150からオペレーティングシステムソフトウェアにアクセスし、これを実行することができる方法を示す。この方法は、クライアントデバイス102上で実行されるクライアントソフトウェアもしくはファームウェアによって、またはさらにはデバイスの専用ハードウェアによって、実施されてもよい。実施形態では、方法は、ブート時にクライアントデバイス102のROMから実行されるブートスタブ(初期ブートコード(initial piece of boot code))によって実施されてもよい。
【0100】
ステップ901において、クライアントデバイス102は、ブロックチェーン150上に記録された、1つまたは複数の標的トランザクションであって、それらのペイロードに記憶されたオペレーティングシステムソフトウェアを含む、1つまたは複数の標的トランザクションを識別する。実施形態では、このステップは、根ノード301RのトランザクションID(略して「根ID」)に基づいてもよい。この場合、クライアントデバイス102は、木の根IDを知っていることに基づいて根ノードから開始し、次いでエッジ302から形成されたパスに従って、根ノード301Rから木を下って、OSソフトウェアが記憶された葉ノード301Lを見つける。たとえば、根IDは、たとえば製造または配備時に、クライアントデバイス102に事前に記憶されてもよい。したがって、クライアントデバイス102に必要なのは、根IDおよびチェーン150への接続だけであり、クライアントデバイス102は、木の葉301Lにおいて現在のOSソフトウェアすべてを見つけることができる。
【0101】
ステップ920において、クライアントデバイス102は、ブロックチェーン150に記憶されたような1つまたは複数の識別された標的トランザクションのペイロードからオペレーティングシステムソフトウェアにアクセスする。これは、永続的または一時的(すなわち、ストリーミングされる(streamed))に、クライアントデバイス102にソフトウェアをダウンロードすることを含む。ソフトウェアは、当該の標的トランザクションを含むブロックチェーン150の少なくとも一部のコピーを記憶しているブロックチェーンネットワーク106のノード104の1つまたは複数からダウンロードされる。
【0102】
ステップ930において、クライアントデバイス102は、それがブロックチェーン150の標的トランザクションからアクセスしたオペレーティングシステムソフトウェアを実行する。これは、ブロックチェーンからOS全体を実行すること、またはすでにクライアントデバイス102にローカルに記憶された補間部分と併せてブロックチェーン150からOSの一部を実行することを含んでもよい。どちらにしても、チェーン150からアクセスされるOSソフトウェアは、ライブで実行されるか、またはクライアントデバイス102にインストールされる場合がある。前者の場合、ダウンロードすることは、ブロックチェーン150からクライアントデバイス102のRAM(ランダムアクセスメモリ)、すなわち揮発性メモリにOSソフトウェアをストリーミングすることを含み、OSソフトウェアはクライアントデバイス102に一時的に保持される。ソフトウェアは、ストリーミングされる方法でRAMから実行される。一方インストールの場合、OSソフトウェアは、クライアントデバイス102の不揮発性ストレージにダウンロードされる。インストールはまた、OSがインストールされている特定のクライアントデバイス102のハードウェアの1つまたは複数の固有の特性に合わせてオペレーティングシステムの1つまたは複数のファイルを構成するステップを含む(インストールされるソフトウェアは、それがインストールされる特定のデバイスに適するように構成されるので、必ずしも別のデバイスに単純にコピーできるとは限らない)。クライアントデバイス102は次いで、OSのインストールされたバージョンを実行する。ステップ960またはステップ970の後、方法は、ステップ940にループして戻り、さらなる更新のために監視を続けてもよい。
【0103】
実施形態では、オンチェーンで記憶されたオペレーティングシステムソフトウェアは、ファイルおよびフォルダ構造で配置されてもよく、すなわちソフトウェアは、複数のファイルを含み、それらの各々が、あるフォルダに記憶されるとして表される。異なるファイルが、異なるフォルダに記憶されてもよい。フォルダは、親フォルダおよびサブフォルダ(親フォルダの子)の階層的な配置を含んでもよい。ファイルは、親またはサブフォルダに記憶されてもよい。
【0104】
そのような実施形態では、オーバーレイネットワークの木構造、または少なくともそれの一部は、オペレーティングシステムの階層的なファイルおよびフォルダ構造の一部または全部をミラーリングするように配置されてもよい。これは、オペレーティングシステムが自然に、それのファイルの編成に合わせて階層構造を有し、オーバーレイネットワーク(たとえば、Metanet)の木構造はこれを反映するように使用され得るので好都合である。
【0105】
一例を図5に示し、別の例を図6に示す。そのような実施形態では、各ノード301は、それがフォルダノードであるか、ファイルノードであるかを示すために、(たとえばそれのペイロードに)タグを付けられてもよい。異なるタグが、根301Rを示すために使用されてもよいが、根がそれのIDによって根であることがわかる可能性があるとき、これは必須ではない。葉ノード301Lの1つは、根ノード301Rの子であってもよい(ここで子は直近の子孫を意味する)。これは、ファイルおよびフォルダ構造のルートディレクトリにあるとしてファイルを表すために使用され得る。根301Rの別の子は、フォルダノードとしてタグ付けされてもよい。これは、ファイルもしくはサブフォルダまたはそれの組合せを表すことがある、それ自体の1つまたは複数の子を有することになるので、中間ノード301Iである。図6に示す例では、フォルダノードは、葉301Lであって、ファイルを保持するために使用される1つの子を有する。当然、より複雑なファイルおよびフォルダ構造が考えられる。
【0106】
本開示により具体化されるさらなる代替または追加の特徴では、クライアントデバイス102は、ステップ910において木をウォークして(walk)葉ノードを見つけるとき、それが各パスに沿って遭遇する各ノード301の妥当性をチェックするように構成されてもよい。ここでは妥当性は、少なくとも木構造のオーバーレイネットワークプロトコル、たとえばMetanetプロトコルによる妥当性を意味する。このプロトコルは、1つまたは複数のプロトコルルールを含み得る。
【0107】
たとえば、実施形態では、ルールは、図3および図4に関して説明したように、各子ノード301Cがそれぞれの親ノード301Pの鍵によって署名されるという要件を含む。任意のノード301がクライアント102によってこの要件を満たさないとわかる場合、ノード301およびそれの子のいずれも、無効として無視されることになる。これは、そのノードまたはそのノードの子に記憶されたどのOSソフトウェアも、クライアントデバイス102によって実行されるOSソフトウェアに含まれないことを意味する。
【0108】
いくつかの実施形態では、別のルールは、葉ノード301Lのみが、クライアントデバイス102のためのOSソフトウェア(またはコマンド)を有効に含んでいると考えられることである。この場合、クライアントデバイス102は単に、パスの端部において葉ノード301Lに見つけられるOSソフトウェアを実行することになる。これの1つの利点は、より詳細に手短に説明するように、それがOSソフトウェアを削除または更新するための機構を提供することである。
【0109】
本明細書で開示するブロックチェーンベースのOSディストリビューション方式へのオプションの追加として、同様の機構が、ブロックチェーンベースのOSを実行するクライアントデバイス102の遠隔制御を可能にするために使用されてもよい。そのような実施形態では、クライアントデバイス102はまた、コマンドならびにOSソフトウェアを含んでいるノード301を検索する。たとえば、これは、同じ根ノード301Rから開始すること、およびエッジのパスに従って葉301Lまで下りることを含んでもよい。クライアントデバイス102が、葉ノード301に有効に記憶されたOSソフトウェアを見つける場合、それはクライアントデバイス上にあるように実行されるOSソフトウェアにそれを含む。一方、クライアントデバイス102がコマンドを見つける場合、クライアントデバイス102はコマンドを実行する。コマンドは、たとえば、シェルスクリプトまたはPythonスクリプトなど、OSによって認識される汎用スクリプト言語のコマンドであることがある。いくつかの実施形態では、複数のそのようなコマンドのスクリプトが、トランザクションに含まれることがある。別の例として、コマンドは、read a temperature and publish it on chain、またはopen a gate、またはchange the update frequency to Xなど、デバイスまたはアプリケーション固有のコマンドであることがある(OSがそれを解釈する能力を有すると仮定する)。ノード301がソフトウェアまたはコマンドを保持しているかどうかを記録するために、ファイルおよびフォルダと同様に、タグ(たとえば、同じくペイロードに記憶される)の方式が使用されてもよい(または、いくつかの実装形態では、同じノード内で両方が許容され得ることは排除されない)。
【0110】
クライアントデバイス102からリモートにある、たとえば異なる地理的位置にあるリモート管理者システムによって、葉ノード301Lにコマンドが含まれる場合がある。管理者システムとクライアントデバイス102の両方が、たとえば、インターネットを介してブロックチェーンネットワーク106に接続される。管理者システム自体も、ブロックチェーンネットワーク106のクライアントであってもよく、またはブロックチェーンノード104の1つでもあり得る。管理者システムは、たとえば、図1のAliceまたはBobのように、新しいトランザクションをブロックチェーン150に記録し、新しいトランザクションを木の葉301Lにすることができる。様々な使用事例では、これは、クライアントデバイスが最初にチェーンからOSを実行した後により遅い段階(たとえば、後日)において行われてもよい。コマンドは、オペレーティングシステムの実行可能コード(機械コード命令)よりも高いレベルの命令であり、コマンドは、オペレーティングシステム、または、機械コードレベルにおいて実行されるのではなく、クライアント上で実行されるより高いレベルのアプリケーションソフトウェアによって解釈される。説明する技法はまた、複数のコマンドのスクリプトに拡張し得る。
【0111】
いくつかの実施形態では、特定のノード301に保持されるOSソフトウェア(またはコマンド)は、そのノードに別のノードを追加することによって更新または削除され得る。これは、葉ノード301Lのみが有効なコンテンツを含むと考えられる実施形態において適用される。これを行うために、管理者システムは、削除または更新されることになる現在の葉ノード301Lに新しいノード301を追加する。追加手段は、たとえば、図3または図4に関して説明した意味において、オーバーレイネットワークエッジ302と接続する。すなわち、新しいノードは、それが追加されるノードの子301Cにされ、このノードは今では新しいノードの親301Pである。したがって古い葉は今では中間ノード301Iであり、新しいノードは新しい葉301Lである。
【0112】
【0113】
図9は、更新および/もしくは削除を実施するために、かつ/またはリモート管理者からの我々のコマンドを運ぶために、クライアントデバイス102によって実施され得るオプションのステップを示す。ステップ940において、ステップ910から930で最初にアクセスされたOSソフトウェアの実行を開始した後、クライアントデバイス102は、OSソフトウェア(および/またはいくつかの場合、コマンド)を含む新しい標的トランザクションのためにブロックチェーン150を監視し続ける。実施形態ではこれは、任意の新しいノードが(以前の)葉に追加されるかどうかをチェックするために、現在の葉ノード301Lを監視することを含む。代替または追加として、監視することは、新しい葉につながる新しいパスをチェックするために、それの根301Rから葉301Lまでの木のパスをリウォークする(re-walk)ことを含んでもよい。ステップ950において、クライアントデバイスは、監視することが任意の新しい標的ノード301を発見したかどうかを決定する。そうでない場合、クライアントデバイスはステップ940にループして戻り、ここでこのクライアントデバイスは監視することを続ける。しかしながらそうである場合、方法はステップ960に進み、ここでこのクライアントデバイスは新しい標的ノードがOSソフトウェアまたはコマンドを含んでいるかどうかを決定する。新しい標的ノードがOSソフトウェアを含んでいる場合、これは更新と考えられ、方法はストップ960に分岐し、ここでクライアントデバイス102は更新を実施する。一方、新しい標的ノードがコマンドである場合、方法はステップ970に分岐し、ここでクライアントデバイス102はコマンドを実行する。別の可能性は、ノードがOSソフトウェアへの更新も、コマンドも含まないことである。この場合(フォルダノードとしてタグ付けされていないと仮定する)、新しく追加されたノードは、それの親の削除を表すと考えられ、クライアント102は、OSソフトウェアの実行をやめる、または削除された親に含まれていたコマンドの実行をやめる。
【0114】
新しいノードの性質がどんなものであっても、クライアントデバイス102は次いでステップ940にループして戻り、ここでまたさらなる新しいノードの監視を続ける。
【0115】
別のオプション機能として、クライアントデバイス102は、ノード301の1つからOSソフトウェアにアクセスまたはこれを実行したとき、および/またはそのようなノードからコマンドを実行したとき、ブロックチェーン150に確認応答を記録するように構成されてもよい。これは、クライアントデバイス301が、ブロックチェーン150で公開されるようにブロックチェーンネットワーク106にトランザクションを送ること(または、管理者システムもしくは第三者がブロックチェーン150において公開されるようにブロックチェーンネットワークに転送するために、管理者または第三者にトランザクションを送ること)を意味する。このトランザクションは、たとえば、支出不可出力(たとえば、使用されるプロトコルに応じて、OP_RETURN、またはOP_FALSE、OP_RETURNを用いて支出不可にされる)において、トランザクションのペイロードに確認応答を含む。この確認応答はその場合、クライアントがOSソフトウェアにアクセスした、もしくはこれを実行した、またはコマンドを実行した証拠として、オンチェーンで不変に残っている。
【0116】
確認応答は、クライアントデバイスが単にコマンドまたはスクリプトを受け取ったことを認定するために使用されてもよい。代替または追加として、確認応答は、クライアントデバイス102がOSソフトウェアまたはコマンドを実際に実行すると、クライアントデバイス102によって記録されてもよい。この場合、確認応答は、クライアントデバイス102がソフトウェアまたはコマンドを実行したと報告されたことを、単に記録してもよく、これは、反論できない証拠ではないが、なんらかの証拠を与える(デバイスが、不正をはたらき(cheat)、コマンドを実行したと言うことがあるが、デバイスは実行しなかった)。たとえば、デバイスが、ゲートを開けるためにコマンドを受け取ったと確認応答することがあるが、デバイスが実際にゲートを開けたことを証明するのは困難である。代替的に、確認応答は、ソフトウェアまたはコマンドが実行されたより強力な証拠を与えるために証明可能なコンピューティング技法を使用することができる。コードの実行を証明するための既存の技法は、それら自体、当技術分野で知られている。
【0117】
また別のオプション機能として、クライアントデバイス102は、ネットワーク、たとえばWi-Fiネットワーク、Bluetoothネットワーク、ZigBeeネットワーク、または同様のものなどのワイヤレスローカルエリアネットワークにおいて1つまたは複数の他のクライアントデバイスと接続されてもよい。実施形態では、このネットワークは、メッシュネットワークの形態をとってもよい。これは、ブロックチェーンネットワークに接続するためにクライアントデバイス102(および実施形態では管理者システム)によって使用されるワイドエリアネットワーク101以外のネットワークであってもよい。このようなネットワーク内で他のクライアントデバイスと接続されるとき、クライアントデバイスは、クライアントデバイスがブロックチェーン150から取得したオペレーティングシステムソフトウェアおよび/またはコマンドの一部または全部を共有してもよい。これは、他のデバイスの1つまたは複数が、ブロックチェーンネットワーク106に接続されない場合、さらにはそれらが、ネットワーク内のすべてのデバイスの帯域幅を節約するために、ブロックチェーンに別々に問い合わせなければならない場合に有利であり得る。メッシュネットワーク配置では、他のデバイスのいくつかは、さらにネットワーク内のそれらのピアなどとOSソフトウェアおよび/またはコマンドを以後共有してもよい。すべてのデバイスがブロックチェーンに接続されなければならないとは限らないことに留意されたい。1つで十分であるが、2つ以上はセキュリティを上げる。異なるデバイスが、異なるブロックチェーンノード104に接続することができ、したがってそれらは、ブロックチェーンノードが不正をはたらいて、ブロックチェーンの偽のバージョンを送信しているかどうかを検出することになるので、2つ以上はセキュリティを上げる。また単一のデバイスが、セキュリティを上げるために同様に複数のノード104に接続されてもよいが、それは単一の障害点となるであろう(たとえば、攻撃者がそのデバイスを脅かし、他のデバイスすべてを制御する可能性がある)。
【0118】
次にいくつかの考えられる実装形態のいくつかのさらなる例示的な詳細について、ただし単に例として、説明する。
【0119】
オンチェーンでのライブOS
ライブオペレーティングシステム(ライブOS)は、実行される前にシステム上にインストールされる必要がないOSである。ライブOSは、コンピュータのメモリ内にストレージデバイス(たとえば、USBキー)から直接実行する、完全なブート可能なシステムである。オンチェーンで公開される場合、これらのOSは、インストールされる必要なしに、ブロックチェーンからダウンロードされると自動的に実行され得る。代替として、ブロックチェーンは、メイン永続ストレージとして使用でき、必要とされる部分のみがデバイスのメモリ(たとえば、RAM)にダウンロードされる。これは、たとえば、Linuxシステムで可能である。それはブート時間にそれらのドライバをすべてロードするからである。
ライブオペレーティングシステム(ライブOS)は、実行される前にシステム上にインストールされる必要がないOSである。ライブOSは、コンピュータのメモリ内にストレージデバイス(たとえば、USBキー)から直接実行する、完全なブート可能なシステムである。オンチェーンで公開される場合、これらのOSは、インストールされる必要なしに、ブロックチェーンからダウンロードされると自動的に実行され得る。代替として、ブロックチェーンは、メイン永続ストレージとして使用でき、必要とされる部分のみがデバイスのメモリ(たとえば、RAM)にダウンロードされる。これは、たとえば、Linuxシステムで可能である。それはブート時間にそれらのドライバをすべてロードするからである。
【0120】
軽量Linux Operating Systemのライブディストリビューションは、50～500MBのディスクスペースを必要とし、0.5sat/byte(執筆時点で標準的な最低BSVトランザクションフィー)のトランザクションフィーと考えると、オペレーティングシステムをオンチェーンで公開するコストは、0.25～2.5BSV(執筆時点で50～500USD)と推定され得る。ライブOSは、一度公開され、再利用され得る。このために、オペレーティングシステムをオンチェーンでアップロードするコストは、特にビジネスには、手ごろな価格であると考えられ得る。
【0121】
ライブOS実行全体が実現可能ではないまたは望ましくないとき、OSおよびソフトウェアの全部または一部を、システムハードドライブにインストールすることができ、ブロックチェーンを使用して維持および更新することができる。たとえば、経済的または著作権の理由で、OS全体をオンチェーンで公開することが実現可能ではない状況では、OSの一部または全部を、1つまたは複数の第三者サーバに記憶することができ、それのハッシュのみが公開されてもよい。これらのサーバの1つからダウンロードされると、オンチェーンで公開されたハッシュを使用して、OSの真正性(authenticity)を検証することができる。
【0122】
実施形態では、ライブOSは、OS構造を複製するためにMetanetプロトコルを使用してオンチェーンで公開される。これは、以下のいくつかの利点を有する。
・ オンチェーンでのOSおよびプログラム認定および完全性管理。
・ 自動的オンチェーン更新を容易にする(デバイスがMetanet木を更新すると、デバイスが自動的に更新を受信する)。
・ コード実行を容易にする(コードをデバイスMetanet木にリンクすることができる)。
・ 証明可能なコード実行(実行されるデータおよびコードがオンチェーンで記憶される)。
・ デバイスへの安全なアクセス(PKIを使用する)。
・ すべてのデバイスの遠隔制御(コマンドをオンチェーンで公開する)。
・ デバイスからのデータ収集および公開を容易にする。
・ オンチェーンでのOSおよびプログラム認定および完全性管理。
・ 自動的オンチェーン更新を容易にする(デバイスがMetanet木を更新すると、デバイスが自動的に更新を受信する)。
・ コード実行を容易にする(コードをデバイスMetanet木にリンクすることができる)。
・ 証明可能なコード実行(実行されるデータおよびコードがオンチェーンで記憶される)。
・ デバイスへの安全なアクセス(PKIを使用する)。
・ すべてのデバイスの遠隔制御(コマンドをオンチェーンで公開する)。
・ デバイスからのデータ収集および公開を容易にする。
【0123】
OSを記憶するためにMetanet木を使用する
Metanetは、木のような構造を使用して、オンチェーンでデータを構築するために使用され得る。木のすべての葉がそれらの木根に関連付けられるので、常に木根から始まる木全体を検索し、ダウンロードすることが可能である。葉と根との間の関連付けは、直接的である(すなわち、根と葉との間に直接の親子のリンクがある)、または間接的である(すなわち、根と葉との間に中間ノードがある)ことがある。Metanetルールに従ってMetanetの根を表すビットコイントランザクションのIDを与えられると、木全体を追跡およびダウンロードすること、ならびに秘密鍵がわかっている場合、新しいノードを木に追加することが容易である。Metanetプロトコルを使用してデータを構築することは、ノードを有効および無効にするために、ならびにファイルを更新するためにデータをリンクおよび検索する効率的な方法がもたらされるので有利である。
Metanetは、木のような構造を使用して、オンチェーンでデータを構築するために使用され得る。木のすべての葉がそれらの木根に関連付けられるので、常に木根から始まる木全体を検索し、ダウンロードすることが可能である。葉と根との間の関連付けは、直接的である(すなわち、根と葉との間に直接の親子のリンクがある)、または間接的である(すなわち、根と葉との間に中間ノードがある)ことがある。Metanetルールに従ってMetanetの根を表すビットコイントランザクションのIDを与えられると、木全体を追跡およびダウンロードすること、ならびに秘密鍵がわかっている場合、新しいノードを木に追加することが容易である。Metanetプロトコルを使用してデータを構築することは、ノードを有効および無効にするために、ならびにファイルを更新するためにデータをリンクおよび検索する効率的な方法がもたらされるので有利である。
【0124】
一般的なシステム(たとえば、ラップトップまたはIoTデバイス)は、その木根を与えられるとオンチェーンでMetanet木に記憶されたオペレーティングシステムをダウンロードおよび実行することができる。これは、木根が安全な方法で与えられ、記憶される場合、システムは常に、検証可能な方法で同じOSをダウンロードし、実行することができることを意味する。さらに、システムは、新しい情報が新しいMetanetノードに含まれ、同じ木にリンクされるとき、新しく公開されたコードを自動的に更新し、実行することになる。たとえばIoTデバイスは、埋め込まれた木根(たとえば、ROMに記憶される)で生成され得る。このIoTデバイスは、常に同じ木にリンクされ、オペレーティングシステムの正しいバージョンおよび公開された更新を常にダウンロードし、その木で公開されるどんなコード(たとえば、スマートコントラクト)も実行することになる(考えられる実装形態について後で説明する)。その木を作成および管理するために使用される秘密鍵が漏洩しない限り、IoTデバイスは安全であり、証明可能な方法で、かつ、指定されたライブラリおよびモジュールを使用して、任意のコードを実行することができる。
【0125】
一例として、図5に、Linuxのライブディストリビューション、すなわちPuppy Linux BionicPup32を記憶するために使用される木構造を表し、スリー根IDを与えられると、すべてのファイルおよびフォルダをダウンロードすることができる。本例では、2つのフォルダ「uui」(Universal USB Installer)および「help」がある。フォルダ「uui」は、FATファイルシステムで作動するLinuxのブートローダーである「syslinux.cfg」ファイルを含んでいる。「help」フォルダは、ブートローディングプロセス中にテキストメッセージを示すいくつかのファイルを含んでいる。他のファイルは、たとえば、Puppyディストリビューションの固有の、1つのファイル内の複数のアプリケーションの「コンボパック」である「ubuntu_10.03.sfs」ファイルとして、直接木根にリンクされる。「*.c32」ファイルは、ブートプロセス中のハードウェアの検出およびセットアップなどの低レベルの関数を実行するためにsyslinuxによって使用される32ビットのモジュールを記憶する。モジュール、ライブラリ、ドライバ、プログラムなどを含む他のファイル(図には表していない)は、直接的または間接的に、同じ木根にリンクされる。
【0126】
オンチェーンでOSを公開する
OSは、ソフトウェア配布者によって、または(OSライセンスがそうすることを許可する場合)いずれかのシステム管理者によって、オンチェーンで公開され得る。第1の場合、平易なOSが公開されることになり、第2の場合、追加のソフトウェア、構成ファイル、およびスクリプトがOSとともに公開され得る。OSは、「OSルートディレクトリ」に含まれ、OSルートディレクトリは、階層の最初または最上位のディレクトリである。OSは、異なるファイルを含むすべての枝が生じる起点として、木の幹にたとえられ得る。OSルートディレクトリに含まれる任意のライブOSディストリビューションを与えられると、それは以下のステップに従って、オンチェーンで公開され得る。
1. OSルートディレクトリを表すMetanetノードを作成する。ここでは追加情報(たとえば、ディストリビューション名およびバージョン)を加えることができる。
2. 実際のOSルートディレクトリの各ファイルおよびフォルダ(すなわち、デバイスの根またはOSを含むフォルダ)について、そのファイルまたはフォルダを表す新しいMetanetノードを作成する(さらなる詳細は後で)。これらのノードを(子として)OS根ノードにリンクさせる。
3. まだ処理されていないフォルダを選択し、それの中に含まれる各ファイルおよびフォルダに対して新しいMetanetノードを作成する。これらのノードを(子として)選択されたフォルダにリンクさせる。
4. 各フォルダおよびサブフォルダに対してポイント3を繰り返す。
OSは、ソフトウェア配布者によって、または(OSライセンスがそうすることを許可する場合)いずれかのシステム管理者によって、オンチェーンで公開され得る。第1の場合、平易なOSが公開されることになり、第2の場合、追加のソフトウェア、構成ファイル、およびスクリプトがOSとともに公開され得る。OSは、「OSルートディレクトリ」に含まれ、OSルートディレクトリは、階層の最初または最上位のディレクトリである。OSは、異なるファイルを含むすべての枝が生じる起点として、木の幹にたとえられ得る。OSルートディレクトリに含まれる任意のライブOSディストリビューションを与えられると、それは以下のステップに従って、オンチェーンで公開され得る。
1. OSルートディレクトリを表すMetanetノードを作成する。ここでは追加情報(たとえば、ディストリビューション名およびバージョン)を加えることができる。
2. 実際のOSルートディレクトリの各ファイルおよびフォルダ(すなわち、デバイスの根またはOSを含むフォルダ)について、そのファイルまたはフォルダを表す新しいMetanetノードを作成する(さらなる詳細は後で)。これらのノードを(子として)OS根ノードにリンクさせる。
3. まだ処理されていないフォルダを選択し、それの中に含まれる各ファイルおよびフォルダに対して新しいMetanetノードを作成する。これらのノードを(子として)選択されたフォルダにリンクさせる。
4. 各フォルダおよびサブフォルダに対してポイント3を繰り返す。
【0127】
この例示的な実施形態では、OS(またはより良くはOSルートディレクトリ)を表す各木は、以下のルールを守る必要がある。
1. すべてのファイルおよびフォルが、有効なMetanetノードでなければならず、ノードは、そのノードがファイルを含むか、それともフォルダを表すかを特定するための特殊なタグを含むことができる。ファイルまたはフォルダを表すトランザクションの一例を、図6に示す。
○ Metanetノードがファイルを含む場合、ファイルはOP_RETURNの後に記憶されなければならない(場合によっては暗号化される)。
○ Metanetノードがフォルダを表す場合、フォルダの名前はOP_RETURNの後に記憶されなければならない(場合によっては暗号化される)。
2. OSルートディレクトリに記憶されたすべてのファイルおよびフォルダは、木根の子でなければならない。
3. オペレーティングシステムの根に記憶されないすべてのファイルおよびフォルダ(すなわちそれらはフォルダに含まれている)は、Metanet木内のそのフォルダを表すノードの子でなければならない。
以下のTable 1(表1)は、ファイルまたはフォルダを含んでいるMetanetノードの例示的な構造を示す。ファイルまたはフォルダ名の後に、より多くのタグまたはメタデータをリストに追加することができる。
1. すべてのファイルおよびフォルが、有効なMetanetノードでなければならず、ノードは、そのノードがファイルを含むか、それともフォルダを表すかを特定するための特殊なタグを含むことができる。ファイルまたはフォルダを表すトランザクションの一例を、図6に示す。
○ Metanetノードがファイルを含む場合、ファイルはOP_RETURNの後に記憶されなければならない(場合によっては暗号化される)。
○ Metanetノードがフォルダを表す場合、フォルダの名前はOP_RETURNの後に記憶されなければならない(場合によっては暗号化される)。
2. OSルートディレクトリに記憶されたすべてのファイルおよびフォルダは、木根の子でなければならない。
3. オペレーティングシステムの根に記憶されないすべてのファイルおよびフォルダ(すなわちそれらはフォルダに含まれている)は、Metanet木内のそのフォルダを表すノードの子でなければならない。
以下のTable 1(表1)は、ファイルまたはフォルダを含んでいるMetanetノードの例示的な構造を示す。ファイルまたはフォルダ名の後に、より多くのタグまたはメタデータをリストに追加することができる。
【0128】
【表1】
【0129】
4つのノード(各ノードは図5に示すノードと同様である)が1つの木根(Tx1)と、1つのフォルダ(Tx2)と、2つのファイル(Tx3、Tx4)とを表すMetanet木の単純な例を図6に示す。第1のレベル(OS根)には、1つのファイルと、1つのフォルダとがある。第2のファイルは、レベル1におけるフォルダ内に記憶される。
【0130】
4つのノードは、以下のようにオンチェーンで公開されることになる。
・ 根 - Tx1: OP_RETURN META P1 None root
・ フォルダ - Tx2: SigP1 P1 | OP_RETURN META P2 Tx1 folder encrypted_folder_name
・ ファイル1 - Tx3: SigP1 P1 | OP_RETURN META P3 Tx1 file encrypted_file1
・ ファイル2 - Tx4: SigP2 P2 | OP_RETURN META P4 Tx2 file encrypted_file2
ここでPxは、それぞれのノードの公開鍵(すべて異なる)である。
・ 根 - Tx1: OP_RETURN META P1 None root
・ フォルダ - Tx2: SigP1 P1 | OP_RETURN META P2 Tx1 folder encrypted_folder_name
・ ファイル1 - Tx3: SigP1 P1 | OP_RETURN META P3 Tx1 file encrypted_file1
・ ファイル2 - Tx4: SigP2 P2 | OP_RETURN META P4 Tx2 file encrypted_file2
ここでPxは、それぞれのノードの公開鍵(すべて異なる)である。
【0131】
オンチェーンで2つのタイプのOS、すなわち汎用システムとアドホックシステムを公開することが可能である。一方の、汎用OSは、基本的なインストールおよび構成を有し、いずれかの互換性があるデバイスにリンクされ得る。他方のアドホックシステムは、詳細にはデバイスまたはデバイスのセットに公開され、それらは通常、特定の構成およびプログラムがインストールされ、デバイスを制御するために使用される。同じアドホックシステムの複数のコピーが公開され、異なるデバイスとリンクされることがあり、これは異なるデバイスの挙動の制御を(それらが異なる木にリンクされるとき)各木で異なるコマンドを公開することによって可能にする。
【0132】
オンチェーンOSをダウンロードする
オンチェーンで公開されたOSをダウンロードおよびインストールしようとする新しいデバイスは、ここで概説する要件を有すること、および以下で説明する命令に従うことを必要とされ得る。
・ 新しいデバイスは、木根のトランザクションIDを記憶する(知っている)。
・ 新しいデバイスは、ブロックチェーンに直接的(たとえば、イーサネット、wi-fi)または間接的(たとえば、ZigBee)にアクセスできる。
・ 新しいデバイスは、(データが暗号化される場合)暗号化鍵を知っている。
・ 新しいデバイスは、(デバイスがオンチェーンでデータを書き込む必要がある場合)秘密鍵を有する。
オンチェーンで公開されたOSをダウンロードおよびインストールしようとする新しいデバイスは、ここで概説する要件を有すること、および以下で説明する命令に従うことを必要とされ得る。
・ 新しいデバイスは、木根のトランザクションIDを記憶する(知っている)。
・ 新しいデバイスは、ブロックチェーンに直接的(たとえば、イーサネット、wi-fi)または間接的(たとえば、ZigBee)にアクセスできる。
・ 新しいデバイスは、(データが暗号化される場合)暗号化鍵を知っている。
・ 新しいデバイスは、(デバイスがオンチェーンでデータを書き込む必要がある場合)秘密鍵を有する。
【0133】
デバイスが初めてオンにされるとき、最小限のプレインストールされたソフトウェアが、(軽量クライアントがするように)1つまたは複数のビットコインノードに接続し、以下のステップを実行する。
1. 提供されたトランザクションID(すなわち、木根)から始めて、木の最新バージョンをダウンロードする。データの最も新しいバージョンが使用されることを保証するために、同じMetanetノード公開鍵を用いる任意の2つのトランザクションが利用可能である場合、最も高いブロックの高さを持つトランザクションが使用される。
2. 根を検証する。
3. 子の署名を検証する。アンロッキングスクリプトに親の署名があることは、子の妥当性を証明するのに十分ではないので、明示的署名検証プロセスが推奨され、たとえば、各ノードに対して、(アンロッキングスクリプトで使用される)それを作成するトランザクション全体およびそれを開始するトランザクション(ロッキングスクリプトを含んでいるもの)が、それらのMerkleプルーフとともに提供されなければならない)。
4. 各ノードに対して、必要に応じてデータを復号する。
・ ノードがファイルを含んでいる場合、ファイルはシステムハードドライブルートに、または指定されたフォルダに、復号および記憶される。
・ ノードがフォルダを含んでいる場合、同じ名前をもつフォルダが、指定されたパスに作成される。
最終的に、システムは、ブロックチェーンを、それの木の変化について監視し、新しい更新が見つけられる場合、新しい更新は(ステップ1、2、3で説明したように)自動的にダウンロードされ、インストールされる(ステップ4)。
1. 提供されたトランザクションID(すなわち、木根)から始めて、木の最新バージョンをダウンロードする。データの最も新しいバージョンが使用されることを保証するために、同じMetanetノード公開鍵を用いる任意の2つのトランザクションが利用可能である場合、最も高いブロックの高さを持つトランザクションが使用される。
2. 根を検証する。
3. 子の署名を検証する。アンロッキングスクリプトに親の署名があることは、子の妥当性を証明するのに十分ではないので、明示的署名検証プロセスが推奨され、たとえば、各ノードに対して、(アンロッキングスクリプトで使用される)それを作成するトランザクション全体およびそれを開始するトランザクション(ロッキングスクリプトを含んでいるもの)が、それらのMerkleプルーフとともに提供されなければならない)。
4. 各ノードに対して、必要に応じてデータを復号する。
・ ノードがファイルを含んでいる場合、ファイルはシステムハードドライブルートに、または指定されたフォルダに、復号および記憶される。
・ ノードがフォルダを含んでいる場合、同じ名前をもつフォルダが、指定されたパスに作成される。
最終的に、システムは、ブロックチェーンを、それの木の変化について監視し、新しい更新が見つけられる場合、新しい更新は(ステップ1、2、3で説明したように)自動的にダウンロードされ、インストールされる(ステップ4)。
【0134】
OSを更新する
オンチェーンのOSを使用するデバイスは、好ましくはそれらのMetanet木の状態の定期チェックを実行し、更新を探すことになる。このプロセスは、木発見と呼ばれることがあり、3つのステップを含むことがある。
1. ブロックチェーンは、OSの木根およびそれの子を含んでいるトランザクションを探して、パースされる。
2. オンチェーンでの木の最新のコピーは、ローカルで現在使用中のものと比較される。
・ 新しいノードが識別される。新しいノードは、以前に存在しなかった公開鍵Pnodeを有するノードである。
・ 古いノードが識別される。古いノードは、オンチェーンで複製ノードを有するノード(同じ公開鍵Pnodeを有するノード)である。この場合、最新バージョンのみが検索され、競合するバージョンのブロックの高さが比較され、最も高い高さを有するノードが選択される(最も新しく公開されたもの)。
3. 新しいノードおよびより新しいバージョンが利用可能なノードがダウンロードされ、修正または更新がシステムに適用される(たとえば、古いファイルがそれの最新バージョンと置き換えられる)。デバイスは、このステップを完了するために、リブートされるまたはオフにされる必要がある場合がある。
オンチェーンのOSを使用するデバイスは、好ましくはそれらのMetanet木の状態の定期チェックを実行し、更新を探すことになる。このプロセスは、木発見と呼ばれることがあり、3つのステップを含むことがある。
1. ブロックチェーンは、OSの木根およびそれの子を含んでいるトランザクションを探して、パースされる。
2. オンチェーンでの木の最新のコピーは、ローカルで現在使用中のものと比較される。
・ 新しいノードが識別される。新しいノードは、以前に存在しなかった公開鍵Pnodeを有するノードである。
・ 古いノードが識別される。古いノードは、オンチェーンで複製ノードを有するノード(同じ公開鍵Pnodeを有するノード)である。この場合、最新バージョンのみが検索され、競合するバージョンのブロックの高さが比較され、最も高い高さを有するノードが選択される(最も新しく公開されたもの)。
3. 新しいノードおよびより新しいバージョンが利用可能なノードがダウンロードされ、修正または更新がシステムに適用される(たとえば、古いファイルがそれの最新バージョンと置き換えられる)。デバイスは、このステップを完了するために、リブートされるまたはオフにされる必要がある場合がある。
【0135】
OS更新は、ソフトウェア配布者によって(たとえば、MicrosoftがWindowsのライブバージョンを公開し、維持することができる)、またはシステム管理者によって、オンチェーンで公開され得る。システム管理者が、構成および特定のソフトウェアに関する更新を公開する(たとえば、Pythonモジュールを更新する)こともできる。配布者またはシステム管理者が、オペレーティングシステム、プログラム、ドライバ、または同様のものの新しいバージョンを提供したいとき、配布者またはシステム管理者は、新しいMetanetノードで新しいファイルを公開し、それらをOS木にリンクさせることができる。ファイルの新しいバージョンは、同じファイルの前のバージョンの子として、木に追加することができる。
【0136】
木発見プロセスの間、システムは、新しい子が付加されたノードを自動的に検出することになり、相対ファイルは、利用可能な最新の(木の最深の)バージョンと置き換えられることになる。この技法は、任意の第三者サーバを使用することなく、任意のソフトウェアの自動更新を可能にする(したがって、維持費を削減し、多くの安全性および利用可能性の懸念を取り除く)が、それぞれのOS木に関連付けられて、最新バージョンをオンチェーンで公開するだけである。この木に関連付けられたデバイスは、木発見プロセス中に自動的に更新されることになる。
【0137】
一例として、図7において、Metanet木のファイルは更新され、ファイルの最新バージョンは常に、同じファイルの前のバージョンの子であり、同じ公開鍵Pnodeを使用する。有効と見なされたバージョンは、常に葉ノードであり、その特定の枝の最深のノードである。同様に、ノードは、同じPnodeおよび空のコンテンツを有する新しい兄弟または子ノードを作成することによって削除する(すなわち、Metanet木から取り除く)ことができる。代替または追加として、ノードは、ノードを含むトランザクションに存在するUTXOを支出することによって削除することができる。
【0138】
オンチェーンでコマンドおよびコードを公開する
Metanet木は、オペレーティングシステムを記憶するためだけではなく、その木に関連するデバイスによって実行されるべきコマンドまたは何らかのコード/スクリプト(たとえば、スマートコントラクト)を公開するためにも使用することができる。OSファイルおよびソフトウェアと同様に、これらのコマンド、コード、およびスクリプトは、木根に(直接的または間接的に)リンクされ、特殊なタグを使用して分類されたMetanetノードとして公開される。
Metanet木は、オペレーティングシステムを記憶するためだけではなく、その木に関連するデバイスによって実行されるべきコマンドまたは何らかのコード/スクリプト(たとえば、スマートコントラクト)を公開するためにも使用することができる。OSファイルおよびソフトウェアと同様に、これらのコマンド、コード、およびスクリプトは、木根に(直接的または間接的に)リンクされ、特殊なタグを使用して分類されたMetanetノードとして公開される。
【0139】
この技法を使用すると、オペレーティングシステム木の所有者(たとえば、システム管理者)は、1つまたは複数の特定のデバイス上で実行される新しいコード、スクリプト、またはコマンドを公開して、デバイスを制御することができる。オンチェーンでコードを公開すると、デバイスに送られた正確なコード、およびそれがオンチェーンで公開された特定の時間を証明することが可能になり、コードを暗号化することができ、復号鍵は、プライバシーを高めるために関係者にのみ利用可能とすることができる。加えて、デバイスは、コードが受け取られ、実行されたことを証明するために、オンチェーンで確認応答を公開することができる。
【0140】
いくつかのコマンドノードを有するMetanet木の一例を図8に示す。コマンドおよびコードは、オペレーティングシステムの同じ木で公開されてもよい。実施形態では、コマンドの正確なシーケンスは、ブロックチェーンにプルーフとして記憶される。
【0141】
コマンドおよびコードは、OSおよびソフトウェア更新の場合と同様に、オンチェーンで新しいバージョンを公開することによって更新され得る。木発見プロセスの間、これらのノードは処理され、それらのコンテンツが実行され、より古いバージョンを取り替える。更新プロセスは、前に説明した同じものであり、ここで、より新しいバージョンが利用可能であるとき、新しいコマンドまたはコードがダウンロードされ、既存のコマンドまたはコードがすでに置き換えられている(同じ公開鍵であるがブロックの高さがより高いノード)。このシナリオでは、木は、リポジトリとしてだけでなくロガーとしても機能し、事実上常に、どのコマンドまたはコードがデバイスに、どの順序で、またどの特定の時間において送られたか(また確認応答メッセージが使用される場合は、実行ステータスおよび時間)を確証することが可能である。
【0142】
OSが立ち上がり作動すると、コマンドおよびコード実行は、以下のように実施される。
1. コマンドまたはコード/スクリプトを含んでいるノードが、ダウンロードされ、処理され、いくつかのファイルを実行する、またはいくつかのセンサを読み取るなどの必要とされる動作が実行される。
2. デバイス秘密鍵で署名されたトランザクションを公開して、出力データ(たとえば、測定値、アラート、計算結果)をブロックチェーンに書き込むことができる。
1. コマンドまたはコード/スクリプトを含んでいるノードが、ダウンロードされ、処理され、いくつかのファイルを実行する、またはいくつかのセンサを読み取るなどの必要とされる動作が実行される。
2. デバイス秘密鍵で署名されたトランザクションを公開して、出力データ(たとえば、測定値、アラート、計算結果)をブロックチェーンに書き込むことができる。
【0143】
スクリプトは、1度実行することができる(たとえば、ゲートを開く)か、または新しいコマンド/スクリプトが受け取られるまで繰り返されるタスクとすることができる(たとえば、温度を読み取り、それをオンチェーンで公開する)。
【0144】
最終的に、システムは、木発見プロセスを使用して、その木における変化についてブロックチェーンを監視し、新しいコマンドまたはコードが見つけられる場合、それらは自動的にそれぞれのより古いバージョンに取って代わる。
【0145】
例示的な適用例
以下は、MetanetベースのOSの2つの考えられる適用例、すなわちスマートコントラクトの決定論的実行(deterministic execution)に対する一方の適用例と、IoTデバイスの遠隔制御に対する他方の適用例を説明する。
以下は、MetanetベースのOSの2つの考えられる適用例、すなわちスマートコントラクトの決定論的実行(deterministic execution)に対する一方の適用例と、IoTデバイスの遠隔制御に対する他方の適用例を説明する。
【0146】
スマートコントラクトの決定論的実行
スマートコントラクトは、それらの実行を他のブロックチェーンノードが複製し、検証することができるように、決定論的結果をもたらすべきである。スマートコントラクトを含んでいるトランザクションは、したがって、使用されるMetanetベースのOSをリンクしているMetanet根ノードも含み、要求に応じて、OSおよび提供されるソフトウェアを実行する環境においてのみ、スマートコントラクトが実行されることを追加することができる。そのトランザクションを公開しようとするノードは、相対的OSをダウンロードし、提供されたコードを実行すべきである。所与のスマートコントラクトを検証したい他のノードまたはエンティティは、同じOSをダウンロードし、そのマシン内でスマートコントラクトを実行しなければならない。代替的に、スマートコントラクトは、木の一部でもあり得る(すなわち、それは同じ木のコードを含んでいるノードである)。しかしながら、計算の理由のために、スマートコントラクトの検証は、(公開されたトランザクションの検証に反して)すべてのノードに対する要求であるべきではなく、オプションのチェックにすぎない。
スマートコントラクトは、それらの実行を他のブロックチェーンノードが複製し、検証することができるように、決定論的結果をもたらすべきである。スマートコントラクトを含んでいるトランザクションは、したがって、使用されるMetanetベースのOSをリンクしているMetanet根ノードも含み、要求に応じて、OSおよび提供されるソフトウェアを実行する環境においてのみ、スマートコントラクトが実行されることを追加することができる。そのトランザクションを公開しようとするノードは、相対的OSをダウンロードし、提供されたコードを実行すべきである。所与のスマートコントラクトを検証したい他のノードまたはエンティティは、同じOSをダウンロードし、そのマシン内でスマートコントラクトを実行しなければならない。代替的に、スマートコントラクトは、木の一部でもあり得る(すなわち、それは同じ木のコードを含んでいるノードである)。しかしながら、計算の理由のために、スマートコントラクトの検証は、(公開されたトランザクションの検証に反して)すべてのノードに対する要求であるべきではなく、オプションのチェックにすぎない。
【0147】
「スマートコントラクト」という表現で、ここでは、(Ethereumスマートコントラクトのような)オンチェーンでの分散的実行および検証のプロセス全体ではなく、ブロックチェーン技法を使用して証明および記録され得るコードの実行を指すことは言及に値する。
【0148】
OSにリンクされたスマートコントラクトを含んでいるMetanetトランザクションの一例を、以下のTable 2 (表2)に示し、スマートコントラクトおよびOSへの参照がOP_RETURNおよび他のパラメータの後に記憶されている。
【0149】
【表2】
【0150】
全ノードが、OSおよびOSがすでにサポートしているソフトウェアのリストを提供することができ、それらはコードの実行に対してユーザに請求する場合がある。そのようにしてユーザは、それらのコードを、ビットコインエコシステムにおいて低コストですでに広く利用可能なOSで実行されるように適応させることができ、またはユーザは、特定のOSでコードを実行するために、または新しいOS木根を提供することによって特定のソフトウェアを使用して、ノードに追加料金を支払ってもよい。
【0151】
この手法の利点は、以下を含む。
・ 標準的な、認定された、検証可能な環境。
・ 決定論的および証明可能なコード実行。
・ ノードが計算能力を販売することができる市場の生成。
・ 標準的な、認定された、検証可能な環境。
・ 決定論的および証明可能なコード実行。
・ ノードが計算能力を販売することができる市場の生成。
【0152】
オンチェーンで制御されるIoTデバイス
証明可能なコード実行機能を用いてモノのインターネット(IoT)デバイスを実行または販売したい企業は、プリインストールされたIoTのOSをオンチェーンのOSに置き換えることができる。MetanetベースのOSを使用するIoTデバイスは、1つまたは複数のブロックチェーンノードに接続する能力およびオンチェーンでの特定のOS(根ノード)への参照を必要とするだけである。IoTデバイスがオンチェーンでデータを公開すべきである場合(たとえば、測定値または計算結果)、秘密鍵もまた必要とされる。OSの最新バージョンは、その場合(前の章で説明したように)ブロックチェーンからダウンロードされる。インターネットに直接接続されないデバイスは、他のIoTデバイスと通信し、ワイヤレスメッシュネットワークプロトコル(たとえば、ZigBee)を使用してビットコインノードから更新を受け取ることができる。
証明可能なコード実行機能を用いてモノのインターネット(IoT)デバイスを実行または販売したい企業は、プリインストールされたIoTのOSをオンチェーンのOSに置き換えることができる。MetanetベースのOSを使用するIoTデバイスは、1つまたは複数のブロックチェーンノードに接続する能力およびオンチェーンでの特定のOS(根ノード)への参照を必要とするだけである。IoTデバイスがオンチェーンでデータを公開すべきである場合(たとえば、測定値または計算結果)、秘密鍵もまた必要とされる。OSの最新バージョンは、その場合(前の章で説明したように)ブロックチェーンからダウンロードされる。インターネットに直接接続されないデバイスは、他のIoTデバイスと通信し、ワイヤレスメッシュネットワークプロトコル(たとえば、ZigBee)を使用してビットコインノードから更新を受け取ることができる。
【0153】
デバイスは、ただノードをOS木に加えて、アップグレードされ、遠隔で制御され得る。IoTデバイスがオンチェーンで制御されることは、システム完全性、非集中的管理、およびデバイスに送られるアクション(たとえば、コマンド)すべてのロギングを保証する。第三者サーバを構成し、管理する必要がない。
【0154】
結論
上記の実施形態は単に例として説明されたことが諒解されよう。
上記の実施形態は単に例として説明されたことが諒解されよう。
【0155】
たとえば、上のいくつかの実施形態は、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104に関して説明されている。しかしながら、ビットコインブロックチェーンはブロックチェーン150の1つの特定の例であり、上の説明はあらゆるブロックチェーンに一般に当てはまり得ることが理解されるだろう。すなわち、本発明は、決してビットコインブロックチェーンに限定されない。より一般的には、ビットコインネットワーク106、ビットコインブロックチェーン150、およびビットコインノード104への上記のあらゆる言及は、それぞれ、ブロックチェーンネットワーク106、ブロックチェーン150、およびブロックチェーンノード104に関して置き換えられ得る。ブロックチェーン、ブロックチェーンネットワーク、および/またはブロックチェーンノードは、上で説明されたような、ビットコインブロックチェーン150、ビットコインネットワーク106、およびビットコインノード104の説明された性質の一部またはすべてを共有し得る。
【0156】
実施形態では、ブロックチェーンネットワーク106はビットコインネットワークであり、ビットコインノード104は、ブロックチェーン150のブロック151を作成し、公開し、広め、記憶するという説明された機能の少なくともすべてを実行する。これらの機能のすべてではなく1つまたは一部だけを実行する他のネットワークエンティティ(またはネットワーク要素)があり得ることは排除されない。すなわち、ネットワークエンティティは、ブロックを作成して公開することなく、ブロックを広めるおよび/または記憶する機能を実行し得る(これらのエンティティは好ましいビットコインネットワーク106のノードであるとは考えられないことを思い出されない)。
【0157】
他の実施形態では、ブロックチェーンネットワーク106はビットコインネットワークではないことがある。これらの実施形態では、ノードが、ブロックチェーン150のブロック151を作成し、公開し、広め、記憶する機能のすべてではなく、少なくとも1つまたは一部を実行し得ることは排除されない。たとえば、それらの他のブロックチェーンネットワークでは、「ノード」は、ブロック151を作成して公開するが、それらのブロック151を記憶せず、かつ/または他のノードに広めないように構成される、ネットワークエンティティを指すために使用されることがある。
【0158】
またさらに一般的には、上記の「ビットコインノード」104という用語へのあらゆる言及は、「ネットワークエンティティ」または「ネットワーク要素」という用語で置き換えられてもよく、そのようなエンティティ/要素は、ブロックを作成し、公開し、広め、記憶する役割の一部またはすべてを実行するように構成される。そのようなネットワークエンティティ/要素の機能は、ブロックチェーンノード104に関して上で説明されたのと同じ方法でハードウェアにおいて実装され得る。
【0159】
よりさらに一般的には、以下の陳述のうちのいずれか1つまたは複数による方法、装置、またはプログラムが提供され得る。
【0160】
陳述1: クライアントデバイスによって、ブロックチェーンに記録された、1つまたは複数の標的トランザクションを識別するステップであって、1つまたは複数の標的トランザクションが、1つまたは複数の標的トランザクションのペイロードに記憶されたオペレーティングシステムソフトウェアを含み、オペレーティングシステムソフトウェアが、少なくともオペレーティングシステムの何らかの実行可能コードを含む、オペレーティングシステムの少なくとも一部を含む、識別するステップと、ブロックチェーンに記憶された1つまたは複数の標的トランザクションのペイロードからオペレーティングシステムソフトウェアにアクセスするステップと、クライアントデバイス上で、1つまたは複数の標的トランザクションからアクセスされるオペレーティングシステムソフトウェアを実行するステップであって、オペレーティングシステムの実行可能コードを実行することを含む、実行するステップとを含む、方法。
【0161】
陳述2: 上記のオペレーティングシステムソフトウェアが、オペレーティングシステムの全体である、陳述1に記載の方法。
【0162】
陳述3: 上記の実行するステップが、クライアントデバイスにインストールすることなくクライアントデバイスのRAMを介して上記のオペレーティングシステムソフトウェアをストリーミングすることによってブロックチェーンからライブで上記のオペレーティングシステムソフトウェアを実行するステップを含む、陳述1または2に記載の方法。
【0163】
陳述4: 上記の実行するステップが、オペレーティングシステムソフトウェアのコピーをクライアントデバイスにインストールするステップと、インストールされたコピーを実行するステップとを含む、陳述1または2に記載の方法。
【0164】
陳述5: 上記のオペレーティングシステムソフトウェアに関するアクセスするステップおよび実行するステップが、クライアントデバイスのブート時に行われる、陳述1から4のいずれか1つに記載の方法。
【0165】
陳述6: クライアントデバイスによって、ブロックチェーンで公開されるように、クライアントデバイスがオペレーティングシステムソフトウェアにアクセスしたという確認応答を送るステップをさらに含む、陳述1から5のいずれか1つに記載の方法。
【0166】
陳述7: クライアントデバイスによって、ブロックチェーンで公開されるように、クライアントデバイスがオペレーティングシステムソフトウェアを実行したという確認応答を送るステップをさらに含む、陳述1から6のいずれか1つに記載の方法。
【0167】
陳述8: 上記の1つまたは複数の標的トランザクションが、複数の標的トランザクションである、陳述1から7のいずれか1つに記載の方法。
【0168】
陳述9: 木構造が、ブロックチェーンにオーバーレイされ、木構造が、複数のノードと、ノード間のエッジとを含み、各ノードがブロックチェーンに記録された異なるトランザクションであり、各エッジがそれぞれの子ノードからそれぞれの親ノードに接続し、各子ノードがそれぞれの子ノードのペイロードに各子ノードのそれぞれの親ノードのトランザクションIDを指定することによってエッジが形成され、親ノードの1つが木構造の根ノードであり、上記のオペレーティングシステムソフトウェアを記憶する1つまたは複数の標的トランザクションが、上記の木構造の子ノードである、陳述1から8のいずれか1つに記載の方法。
【0169】
陳述10: 木構造がMetanet木を含む、陳述9に記載の方法。
【0170】
陳述11: 上記のオペレーティングシステムソフトウェアが、階層的なファイルおよびフォルダ構造で配置された異なるフォルダに複数のファイルを含み、標的トランザクションの各々が、ファイルの少なくともそれぞれの1つを記憶し、標的トランザクションの1つまたは複数の親ノードが、フォルダを表すようにタグ付けされ、ノードの木構造の少なくとも一部がオペレーティングシステムソフトウェアのファイルおよびフォルダ構造の少なくとも一部に従うようにする、陳述9または10に記載の方法。
【0171】
陳述12: 上記の識別するステップが、根ノードのトランザクションIDに基づいて、根ノードからエッジのパスに従って木構造を下って葉ノードを見つけるステップを含み、葉ノードが、他の子ノードの親ノードではない子ノードであり、1つまたは複数の標的トンラザクションの各々が葉ノードである、陳述9から11のいずれか1つに記載の方法。
【0172】
陳述13: クライアントデバイスが、標的トランザクション、および標的トランザクションと根ノードとの間のパス上のいずれかの中間の親ノードの各々が、木構造に関連する木プロトコルの1つまたは複数のルールを満たすことをチェックし、上記の実行が、上記の1つまたは複数のルールを満たすことを条件とする、陳述12に記載の方法。
【0173】
陳述14: ルールのセットが、少なくとも、根ノードから標的トランザクションまでのパス沿いの各子について、子がそれぞれの親ノードの鍵によって署名される、ことを含む、陳述13に記載の方法。
【0174】
陳述15: 1つまたは複数のルールが、葉ノードのみがオペレーティングシステムの有効な部分を形成することができることを含む、陳述13または14に記載の方法。
【0175】
陳述16: クライアントデバイスによって、上記の実行に続く後続時間において、標的トランザクションのそれぞれの1つにその後加えられた新しい葉ノードをチェックするステップをさらに含み、それにより、それぞれの標的トランザクションはもはや葉ではなく、新しい葉ノードが、それぞれの標的トランザクションの更新または削除を表す、陳述15のいずれかに記載の方法。
【0176】
陳述17: それぞれの標的トランザクションの1つが、更新を含み、方法が、クライアントデバイスが更新を実行するステップをさらに含む、陳述16に記載の方法。
【0177】
陳述18: クライアントデバイスによって、クライアントデバイスからリモートにあるリモート管理者システムによってさらなるトランザクションのペイロードに記録されたリモートコマンドまたはスクリプトを含む、ブロックチェーン上のさらなるトランザクションを識別するステップと、さらなるトランザクションからアクセスされるコマンドまたはスクリプトを実行するステップとをさらに含む、陳述1から17のいずれか1つに記載の方法。
【0178】
陳述19: クライアントデバイスによって、ブロックチェーンで公開されるように、クライアントデバイスがコマンドまたはスクリプトにアクセスしたという確認応答を送るステップをさらに含む、陳述18に記載の方法。
【0179】
陳述20: クライアントデバイスによって、ブロックチェーンで公開されるように、クライアントデバイスがコマンドまたはスクリプトを実行したという確認応答を送るステップをさらに含む、陳述18または19に記載の方法。
【0180】
陳述21: デバイスがモノのインターネット、すなわちIoTデバイスである、陳述1から20のいずれか1つに記載の方法。
【0181】
陳述22: クライアントデバイスが、ネットワークの1つまたは複数の他のデバイスと接続され、上記のネットワークを介して他のデバイスの少なくとも1つとオペレーティングシステムソフトウェアを共有する、陳述1から21のいずれか1つに記載の方法。
【0182】
陳述23: ネットワークがメッシュネットワークである、陳述22に記載の方法。
【0183】
陳述24: ネットワークがワイヤレスローカルエリアネットワークである、陳述22または23に記載の方法。
【0184】
陳述25: 他のデバイスのすべてがブロックチェーンにアクセスできるとは限らない、陳述22、23、または24に記載の方法。
【0185】
陳述26: ブロックチェーンが出力ベースのモデルを使用し、各トランザクションが、少なくとも1つのそれぞれの入力と、それぞれの1つまたは複数の出力とを含み、各トランザクションのペイロードが、それぞれの出力の1つまたは複数に含まれる、陳述1から25のいずれか1つに記載の方法。
【0186】
陳述27: 1つまたは複数の処理ユニットを備える処理装置と、1つまたは複数のメモリユニットを備えるメモリとを備える、クライアントデバイスであって、メモリが、処理装置上で動作するように配置されたコードを記憶し、コードが、処理装置上で動作するとき、陳述1から26のいずれか1つによる動作を行うように構成された、クライアントデバイス。
【0187】
陳述28: コンピュータ可読記憶媒体上で具体化されたコンピュータプログラムであって、クライアントデバイス上で動作するとき、陳述1から26のいずれかに記載の動作を行うように構成されたコードを含む、コンピュータプログラム。
【0188】
陳述29: オペレーティングシステムの製作者のコンピュータ機器によって、ブロックチェーン上のトランザクションのペイロードで公開されるようにオペレーティングシステムソフトウェアを送信するステップを含み、オペレーティングシステムソフトウェアが、少なくともオペレーティングシステムの何らかの実行可能コードを含む、オペレーティングシステムの少なくとも一部を含む、方法。
【0189】
陳述30: ブロックチェーンにオーバーレイされた木構造を更新する方法であって、木構造が、複数のノードと、ノード間のエッジとを含み、各ノードが、ブロックチェーンに記録された異なるトランザクションであり、各エッジが、それぞれの子ノードからそれぞれの親ノードに接続し、各子ノードがそれぞれの子ノードのペイロードに各子ノードのそれぞれの親ノードのトランザクションIDを指定することによってエッジが形成され、木構造が、親ノードの1つを木構造の根ノードとして含み、複数の葉ノードが、他の子ノードの親ノードではない子ノードであり、葉ノードの1つまたは複数が、1つまたは複数の葉ノードのペイロードにオペレーティングシステムソフトウェアを記憶し、オペレーティングシステムソフトウェアが、少なくともオペレーティングシステムの何らかの実行可能コードを含む、オペレーティングシステムの少なくとも一部を含み、木構造が、プロトコルによって支配され、それにより葉ノードのみがオペレーティングシステムの有効な部分を形成すると考えられ、この方法は、管理者システムによって、1つまたは複数の葉ノードのそれぞれの1つに新しい葉ノードを加えるステップを含み、それにより、それぞれの標的トランザクションがもはや葉ではなく、新しい葉ノードは、それぞれの標的トランザクションの更新または削除を表す、方法。
【0190】
陳述31: 1つまたは複数の処理ユニットを備える処理装置と、1つまたは複数のメモリユニットを備えるメモリとを備える管理者システムであって、メモリが、処理装置上で動作するように配置されたコードを記憶し、コードが、処理装置上で動作するとき、陳述30に記載の方法を行うように構成された、管理者システム。
【0191】
陳述32: コンピュータ可読記憶媒体上で具体化されたコンピュータプログラムであって、管理者システム上で動作するとき、陳述30に記載の方法を行うように構成されたコードを含む、コンピュータプログラム。
【0192】
開示される技術の他の変形態または適用例は、本明細書の開示を与えられれば当業者に明らかになる可能性がある。本開示の範囲は、上記で説明した実施形態によって限定されず、添付の特許請求の範囲によってのみ限定される。
【符号の説明】
【0193】
101 ネットワーク
102 コンピュータ端末/コンピュータ機器/クライアントデバイス
103 ユーザ/関係者
104 ノード
105 クライアントアプリケーション
106 ブロックチェーンネットワーク
150 ブロックチェーン
151 ブロック
152 トランザクション
154 プール
201 ヘッダ
202 入力
203 支出不可出力/出力
300 システム
300 オーバーレイネットワーク/Metanetネットワーク/Metanet
301 ノード/親ノード/子/標的ノード/Metanetノード/葉ノード/子ノード/クライアントデバイス/サイドチャネル
302 エッジ
102 コンピュータ端末/コンピュータ機器/クライアントデバイス
103 ユーザ/関係者
104 ノード
105 クライアントアプリケーション
106 ブロックチェーンネットワーク
150 ブロックチェーン
151 ブロック
152 トランザクション
154 プール
201 ヘッダ
202 入力
203 支出不可出力/出力
300 システム
300 オーバーレイネットワーク/Metanetネットワーク/Metanet
301 ノード/親ノード/子/標的ノード/Metanetノード/葉ノード/子ノード/クライアントデバイス/サイドチャネル
302 エッジ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【国際調査報告】