『オーブス』（Orbs）

ポジション ペーパー

V1.6

orbs.com

公開ブロックチェーンインフラストラクチャ、確立された 消費者向けアプリケーション向け

確立された消費者アプリケーション向けの公開ブロック

チェーン・インフラストラクチャ

ポジションペーパー

V.1.6

orbs.com

1

モチベーション ............................................................................................................................ 5

『オーブス』（Orbs）の展望 ............................................................................................... 5

このペーパーの目的............................................................................................................... 6

導入 .............................................................................................................................................. 7

分散化のコンセンサス ........................................................................................................... 7

ブロックチェーンをすべて支配するブロック・チェーン .................................................... 8

ニーズ主導アプローチ ........................................................................................................... 8

分散化消費者アプリの時代.................................................................................................... 9

消費者向けアプリはなぜ分散化するのか............................................................................ 10

Kin by Kik Interactive - 事例研究 ......................................................................................... 11

『オーブス』（Orbs）の広告ターゲット ........................................................................... 14

設計パートナーによる構築............................................................................................ 14

分散化 アプリ の インフラストラクチャ .................................................................................. 16

第一世代(Bitcoin) ................................................................................................................. 16

第 2世代(Ethereum) ............................................................................................................ 16

第 3世代(『オーブス』（Orbs）) ....................................................................................... 17

サービスとしての集中インフラストラクチャー................................................................. 17

実用的なシステムズデザインの教訓 ................................................................................... 18

『オーブス』（Orbs）プラットフォーム ................................................................................. 20

概要 ...................................................................................................................................... 20

分散コンセンサスによるコンピューティング .............................................................. 20

分散的コンセンサス ストレージ ................................................................................... 20

サービスとしてのコンセンサス .................................................................................... 21

設計原則 ............................................................................................................................... 21

サービスレベル契約(SLA) ............................................................................................. 21

消費者の規模.................................................................................................................. 22

消費者保護と規制 .......................................................................................................... 22

最新の配備パラダイム ................................................................................................... 22

ネットワーク組織 ................................................................................................................ 24

2

消費者............................................................................................................................. 24

アプリ............................................................................................................................. 25

コンセンサスノード....................................................................................................... 25

監査ノード ..................................................................................................................... 26

『オーブス』（Orbs）エコシステム ........................................................................................ 27

中核インフラストラクチャー .............................................................................................. 27

専門インフラストラクチャ.................................................................................................. 27

インフラストラクチャ・マーケットプレイス .............................................................. 28

ORBS トークン ......................................................................................................................... 29

概要 ...................................................................................................................................... 29

徴収サブシステム ................................................................................................................ 29

プログラム可能な料金モデル .............................................................................................. 30

経済インセンティブ............................................................................................................. 30

トークン実装........................................................................................................................ 32

アーキテクチャ .......................................................................................................................... 33

分岐の有無 ........................................................................................................................... 33

多言語マイクロサービス ..................................................................................................... 33

コードとしての仕様............................................................................................................. 34

メタプログラミング............................................................................................................. 35

ユニバーサル・アドレシング .............................................................................................. 36

ネットワークは秘密を所有.................................................................................................. 36

『オーブス』（Orbs）アーキテクチャー ........................................................................... 38

インフラストラクチャー層およびサービス .................................................................. 38

リソースプール対仮想チェーン .................................................................................... 40

コンセンサス.............................................................................................................................. 42

実用的な集中排除および信頼 .............................................................................................. 42

力の健全な分配 .................................................................................................................... 43

リアルタイム確認権....................................................................................................... 43

統制決定権 ..................................................................................................................... 43

プルーフ・オブ・ワーク ..................................................................................................... 45

プルーフ・オブ・ステーク.................................................................................................. 46

3

許可モデル ........................................................................................................................... 47

階層状 アプローチ ............................................................................................................... 48

ヘリックス コンセンサスアルゴリズム .............................................................................. 49

コンセンサス結果の最終段階 ........................................................................................ 49

不透明な処理の注文....................................................................................................... 50

確認からの注文の分離 ................................................................................................... 50

受託者による速いコンセンサス .................................................................................... 50

無作為化ソートによる効率的なリーダー選挙 .............................................................. 50

ノード・レピュテーション・システム ......................................................................... 51

サービスレベル契約(SLA) ......................................................................................................... 52

業界標準 ............................................................................................................................... 52

CryptoKitties - 事例 研究 ...................................................................................................... 52

分散的なコンテキスト中の SLA .......................................................................................... 54

予測可能な料金モデル ......................................................................................................... 55

専用資源、予約資源およびオン・デマンド資源................................................................. 56

仮想チェーンおよびブロック・チェーン・バーチャリゼーション ................................... 56

設計原則 ......................................................................................................................... 58

消費者規模 ................................................................................................................................. 59

処理能力とレイテンシー ..................................................................................................... 59

計量可能な料金モデル ......................................................................................................... 60

常に成長するストレージ ..................................................................................................... 61

軽い クライアント ............................................................................................................... 62

注文と確認の分離 ................................................................................................................ 62

コミッティによる効率的なコンセンサス............................................................................ 64

ブロック・チェーン・バーチャリゼーションによるシャーディング................................ 65

弾性キャパシティー............................................................................................................. 66

消費者保護と規則 ...................................................................................................................... 67

規制の発展 ........................................................................................................................... 67

確立された消費者ブランド.................................................................................................. 67

消費者保護 ........................................................................................................................... 68

分散化元帳セキュリティ ..................................................................................................... 68

4

検閲とフロント・ランニング .............................................................................................. 70

コンプライアンスプロトコル .............................................................................................. 71

プライバシーと AML ........................................................................................................... 71

ホワイトチェーン ................................................................................................................ 72

現代の展開パラダイム ............................................................................................................... 73

ネットワーク統制 ................................................................................................................ 73

エバーグリーンノード ......................................................................................................... 74

漸次移行 ............................................................................................................................... 75

アップグレード可能な契約.................................................................................................. 76

マルチ・チェーン・ハイブリッド....................................................................................... 76

多言語クロス・チェーン契約 .............................................................................................. 78

消費者のために設計する ........................................................................................................... 79

ブランドと信頼 .................................................................................................................... 79

モバイルとウェブのクライアント....................................................................................... 79

ネットワーク・アクセスの消費者パターン ........................................................................ 80

解約率のインフラストラクチャー含意 ............................................................................... 81

消費者アプリおよびオープン・ソース ............................................................................... 81

秘密鍵の問題........................................................................................................................ 82

分散化秘密保存 .................................................................................................................... 83

『オーブス』（Orbs）フェデレーション ................................................................................. 84

事前公開設計パートナー ..................................................................................................... 84

統制 ...................................................................................................................................... 85

定義 ............................................................................................................................................ 86

法的な免責 ................................................................................................................................. 87

5

モチベーション

『オーブス』（Orbs）の展望

2020 年までに、大規模な消費者アプリケーションはブロック・チェーンに移行し、世界で数十億の

ユーザーに、分散化サービスをもたらすことが期待されています。コダック、Kik、テレグラムなどの

確立された消費者向けブランドでは、次々と新たな分散化事業を開始し、このスペースで自社事業の

徹底的な再構築が進んでいます。現在私たちは、このトレンドの最初期にあります。

メインストリームの多くの消費者が、汎用ブロック・チェーン・ソリューションでは満たすことがで

きないさまざまな独自の課題を持っています。弊社では、こうした移行を実現させるための多くの要

件に対応する、これらの分散化消費者向けアプリ向けインフラストラクチャ・ソリューションへのニ

ーズを見いだしています。

これまで、確立された消費者ブランドでは、ブロック・チェーン技術を全面的に回避せざるを得ませ

んでした。組織内で非集中化された自前カスタムインフラを開発するか、あるいはスケーラビリティ

を持たない既製ソリューションで、ビジネスモデルを破壊する料金体系を受け入れ、現実のビジネス

では許容できない責任を負うかのいずれかの選択を強いられていました。

『オーブス』（Orbs）プロジェクトでは、大規模な消費者アプリケーション向けに、ブロック・チェ

ーン・インフラストラクチャを商品化する構想を描いています。弊社で構想しているのは、完全に分

散化された公開プラットフォームです。消費者ブランドは、快適にノードを操作し、分散的で均衡が

保たれたエコシステムに参加します。これは産業全体として移行をより円滑にするものでもあります。

このプラットフォームは、アマゾン Web サービス(AWS)のような確立されたインフラストラクチャ

ー・ソリューションから着想を得た、中核的な製品体験で補完し、サービスレベル契約(SLA)や専用リ

ソースなどの、すでによく知られている用語によって解説されます。

6

このペーパーの目的

弊社では、ホワイトペーパーとポジションペーパーを明確に区別しています。ホワイトペーパーは、

複雑な問題を取り上げ、問題の解決策を中心に扱うものです。ポジションペーパーは問題そのものを

中心に扱っています。ポジションペーパーは、問題について議論し、可能性のあるアプローチを検討

の段階として記述します。この文書は、『オーブス』（Orbs）のポジションペーパーとして作成され、

消費者志向のブロック・チェーン・インフラストラクチャーの問題と、弊社がどのようにそれに接近

するかについて議論します。

ブロック・チェーン・スペースでは、記念の意味を持つ技術ホワイトペーパーでプロジェクトの参入

を始める傾向があります。弊社では、複雑な問題には、長期にわたり複数の解決策を組み合わせるこ

とが求められ、こうした解決策は進化すると考えています。従って、『オーブス』（Orbs）プロジェ

クトは、さまざまな解決策に対応するホワイトペーパーのセットが公開されます。これらのホワイト

ペーパーは進化することが期待されています。弊社が直面する問題への理解を深めることで、これら

の一部は不要となるか、置換されることも予測されます。

しかしながら、弊社は、ホワイトペーパーをパズルの最初のピースであるとはみなしていません。最

初のピースは、弊社が解決しようとする問題を正確に説明して、その問題と理由を明確に表現するこ

とです。これは、めまぐるしいイノベーションの混乱した水域で、安定してガイドすることを目指し

ます。このポジションペーパーは、『オーブス』（Orbs）プラットフォームが集中する、ブロック・

チェーン・インフラストラクチャの中で、独自の地位を開拓するものとなることが期待されています。

その後、最適化を進めている主な要件と、見込まれる様々なトレードオフの詳細が解説されています。

このペーパーでは、さらに弊社のソリューションの一部を紹介します。これらは、別途公開される専

門技術ホワイトペーパーでそれぞれ詳説されます。

7

導入

分散化のコンセンサス

暗号通貨が、日常生活の中核を変革する可能性を持ち、決定的変化をもたらす刺激的な外観を持つ

ことに議論の余地はありません。こうした変化とはプログラム可能な経済を作り出すなどです。決定

的変化を客観的に測定することは困難ですが、深遠な技術革新に伴う歴史上な指標を検証することは

可能です。

現代の最大の変化の 1 つが、世界を、デジタルで相互に、数ミリ秒でつなぐインターネットの誕生で

あることに疑いはありません。この事象に一致する経済指標は、1997-2001 のドット・コム・バブル、

市場投機の過熱と大きな成長でした。今日の暗号通貨バブルと、こうした期間には類似点があります。

さらに暗号通貨バブルは、より大規模になると考える根拠があります 1。バブルには、慎重な姿勢を

取るべきです。これらは、短期間での極端な成長が要求されるものです。多くの会社が、ドットコム

バブルで破綻しましたが、そのがれきの中から、今日のデジタル界の巨人であるアマゾンおよびグー

グルのような会社が出現しました。弊社では、こうした巨人企業と同じく成功するために重要な要素

となるものは、正しく確立された価値のうえに会社の基礎を置き、一般に誇大広告を退けることであ

ると考えています。これらは『オーブス』（Orbs）の原則となり、このペーパーの全体にわたって、

より深く取り上げられています。

ドット・コム時代を推進する技術的な突破口はインターネットでしたが、今日の暗号通貨時代を推進

する根本的な技術は何でしょうか。暗号通貨それ自体は、技術ではなく技術の応用の形式です。その

技術は分散化コンセンサスです。

分散化システムは、分配システムであり、独立した、かつ等しい特権を持つノードのグループが、全

体的な目標のためにローカルな情報に基づいて運営されます。これらのシステムは、システムに対す

る統制、監督およびコントロールを行うセントラル・コントローラーがありません。これにより、ネ

ットワーク上で、権力のより一定で、より公平な分配を可能にします。分配システムは、新しいもの

ではありません。すでに 2000 年の初めのピア・ツー・ピア・ブームを起こしたナップスターのよう

なアプリケーションでも使用されています。

1 http://cnbc.com/2017/08/31/bitcons-nearly-five-fold-climb-in-2017-looks-similar-to-tech-bubble-surge

8

コンセンサスは、現実についての見方の共有であり、システムの異なる部分で合意が形成されること

です。消費者アプリケーションの最も小さな例を考えてみてください-ユーザーが閑談するインスタ

ント・メッセンジャーなどです。このシステムでは、すべてのユーザーは認証を行い、本人のみがア

カウントで会話できるようにシステムが作動する、というコンセンサスが要求されています。全ての

メンバーは、ユーザーを見分け、ユーザー名などを所有していると考える、「現実についての見方」

を持っている必要があります。コンセンサスの特性は、集中システムでは非常に簡単に達成されます。

ここで単一の統制組織がこの共有された見方定義し、すべてのメンバーに信頼されています。

分散システムでは、コンセンサスなしでも簡単に構築できます。一方で集中システムでは、コンセン

サス達成が容易となりますが、一つのシステムで、両方の特性を維持することは困難です。そして、

分散化コンセンサス分野の根底に、一つのイノベーションがあります。独立しており、かつ等しい特

権を与えられたノードのグループによって、見方の共有を達成できる分散システムを構築することで

す。暗号通貨は、統制組織なしで残高と取引元帳を照合できるため、こうしたシステムが必要なアプ

リケーションの好例です。

ブロックチェーンをすべて支配するブロック・チェーン ブロックチェーンという用語は Bitcoin のような暗号通貨の中核的な実装構造が語源となっています。

これは、連続的に増え続けるブロックと呼ばれるレコードのリストで、リンクされ暗号化によってセ

キュリティが維持されています。このブロックチェーンでは、すべての取引履歴が、ネットワーク内

で保持され、分配された元帳が形成されます。ブロックチェーンの用語は、こうしたアプリケーショ

ンのインフラとなる中核技術と同義となりました。

次世代のブロックチェーン・インフラストラクチャーの構築はイノベーションの土壌となり、さまざ

まな多数のチームがトップを争っています。これらのプロジェクトの多くは、ブロック・チェーンの

すべてを規定するブロック・チェーンとなることを目指し、こうした明言を行っていることもありま

す。しかし弊社では、この発想は欠陥があると考えています。

歴史的に「特効薬」はほぼ存在しないことが示されています:複雑な問題は、単一の単純なソリュー

ションで解決することはできません。弊社は、「ブロックチェーンをすべて規定するブロックチェー

ン」は存在しないと考えています。汎用ブロック・チェーンは、最小公約数としてのみ最適化されま

す。したがって、実際的なブロック・チェーン構築への第一歩は、使用例を明確に表現することです。

実体経済のニーズ必要を定義し、このブロック・チェーン・インフラストラクチャーが解決を試みる

ことで、この市場が実際に必要かどうかを判断することです。

ニーズ主導アプローチ 新しいブロック・チェーン・インフラストラクチャーの最初の問いは、「重要な差別化要素は何か」

です。通常、この質問に対する答えは、長年の学術研究に基づいたブレークスルーとなる、草分け的

な新しいアルゴリズムです。これは、問題のなかの狭い部分をとらえ革新的に対処し、産業に革新を

もたらします。しかし、これは、『オーブス』（Orbs）の目指す目的ではありません。

9

弊社は、早い段階で、より謙虚なアプローチをとることを決定しました。弊社はソリューションを始

めるのではなく、問題から始めます。弊社の第一歩は、現在のブロック・チェーン・インフラストラ

クチャー・ソリューションが十分には満たせない明瞭なニーズを概説することです。次に、実体経済

で、インフラストラクチャーを必要とする実際の顧客を見つけます。理想的には、次のステップはこ

れらのビジネスと協業することです。最初には、生産で既存のブロックチェーン・ソリューションの

利用を促します。弊社では、このプロセスを通じて、現実の課題が生まれる、ソリューションの実際

的な制約を理解し、実際の問題を解決しニーズを理解する必要があります。

弊社の使命は、当然設計パートナーを見つけることです。

これによって『オーブス』（Orbs）はニーズ主導のブロック・チェーンとなるでしょう。これが重要

な差別化要因となります。初期設計は、弊社の設計パートナーの最も緊急のニーズを解決することの

みを目的として、反復的に投入されます。ブロック・チェーン以前の時代のプロダクション・システ

ム構築での経験から、弊社はこのアプローチが優れて実用的なソリューションをもたらす可能性が高

いと考えています。これは、ソリューションを最初に作り上げて、その周囲のシステムを設計したあ

とで、市場での適合を見つけて争うよりも、明らかに効率的です。

好例は、現代のクラウドの出現です。これは、今日の「サービスとしてのインフラストラクチャ」の

デファクト・スタンダードとなりました。その最初であり主導的な地位を占める AWS は、2 アマゾン

の急激な成長に対応するための、電子商取引社内システムへの緊急のニーズから生まれました。

分散化消費者アプリの時代 暗号通貨スペースは急激に成長し、日々エコシステムを連結する多くのビジネスが登場しています。

ビジネスの最初の波は、アーリーアダプターのみでした。ほとんどが、新規暗号通貨を主とするビジ

ネスあるいは小さな既存のビジネスで技術的な実験を求めていました。その中で Steemit, Gnosis、

Augur といったの消費者アプリは、一定の成功を達成しました。3 これは驚くべきことではありませ

ん。消費市場への浸透は難しいことで知られ、特に複雑な技術で技術通さえマスターが困難です。

弊社では、ビジネスの次の波は、この成熟するエコシステムの連結であるとみています。この波は、

確立されたビジネスのブロック・チェーンへの移行からなります。確立されたベンチャー投資会社が、

暗号通貨の調達に加わる、あるいは既存企業がトークン化を求めるなどです。これらの中で最も興味

深いものは成熟した消費者ブランドです。テレグラム、LINE あるいは Kik Interactive のような会社で、

これらはすでにブロック・チェーンの外部で、数百万ものエンドユーザーをかかえ、正常に消費市場

に食い込んでいます。食い込んでいます。これらの会社のための移行は遅く、直線的ではありません。

これは、もしこの技術が自社ニーズにあっていないことがわかった場合の損害は莫大なためです。

2 https://techcrunch.com/2016/07/02/andy-jassys-brief-history-of-the-genesis-of-aws/ 3 https://steemit.com/statistics/@arcange/steemit-statistics-20171117-en

4 https://jbs.cam.ac.uk/faculty-research/centres/alternative-finance/publications/global-cryptocurrency 5 https://coinmarketcap.com/charts/

10

世界で活動する暗号通貨エンドユーザーの総数は 2017 年の時点で 600 万と推測されています 4 この

数字は、2017 年の時点で暗号通貨の時価総額の合計である 6000 億 USD 超と比較し、驚くべき要素で

す。5 暗号通貨および分散化技術の次の大きな飛躍と、大衆への不朽は、確立された消費者ブランド

にかかっています。

消費者向けアプリはなぜ分散化するのか これまで、確立された消費者ブランドは非常に厳格な集中モデルを利用してきました。これらの企業

では、こうしたアプリケーションの介入が増加し、ブロック・チェーン上で分散化されるにつれ、動

機の面で疑問が浮かびます。批評家であれば、資金を調達する機会が、これらのブランドにとってこ

のスペースを連結する十分な誘因となると主張できるでしょう。にもかかわらず、弊社では、多くの

さまざまな理由からより皮肉でない展望を持っています。

トークンは、デジタル世界で、価値の移行の標準となっています。これらは、不換通貨がデジタル決

済で直面する欠点の多くを解決します。トークンは、地域ごとの個別の決済ソリューションの必要を

なくし、境界を横断し瞬間的に共有することができます。ビジネスは、トークンを直接受け取ること

ができます。決済手段統合の必要は最小であり、支払いサービス供給者と、その高額の料金のような

中間要素を排除します。トークンは、保護が比較的容易でアリ、チャージバックやと不正行為を相殺

するための高い料金をより簡単に縮小できますす。さらに、トークンはマイクロ取り引きのような柔

軟な支払いモデルにも適し、プログラム可能なインターフェースで、より大きなシステムにシームレ

スに統合できます。

さらにトークン化は、あらかじめ定められた規則セットに従って、手作りのマイクロ経済の手段を提

供します。これは、消費者アプリにとって、マネタイズを効果的に行える統制環境を有効に設計する

ことが可能になります。消費者アプリにとって、これまでマネタイズは難しい問題でした。多くの場

合、消費者の興味やデータを、広告主や販売業者に売らない限り収益はありませんでした。広告に基

づいたアプローチなら、少数の手に富と力を集中させ、最大のアプリケーションのみがほとんど排他

的に利点を得ていました。

今日のトークンエコノミーは、数十億ドルの価値を保持しています。集中インフラストラクチャーで

これほど多くの価値を安全に守るには巨額の費用がかかります。犯罪者にとって巨大な誘因を持つた

めです。分散化元帳は、単一の組織が元帳を操作できないため安全をより簡単に守れます。また、会

社のサーバーへのアクセスできても、消費者の金銭を盗むことはできません。さらに、多数の当事者

が、絶えず元帳の完全性を監査し、プロトコルの合意されたコンセンサスとの不一致を識別すること

ができます。

11

またトークン化により、消費者アプリが作成した経済的価値を特にアプリユーザーに分配することが

可能になります。これは、ユーザーが、アプリ内で作成した価値に対して適正に報酬を得ることを保

証します。このモデルでは、マネタイズが通常消費者の最大の利益とならない環境で効果的です。

消費者アプリの集中化排除のもう一つの恩恵は、企業を平等に結べる能力です。消費者スペースは、

ゆっくりと、Facebook やグーグルのような巨大企業に統合されていきます。集中化排除は、こうした

巨大企業ではない数多くの企業が、ともに協力し、単一の組織が勢力均衡をゆがめない、結合された

エコシステムを作成する手段を提供します。他のサービスに依存せずに、消費者が保持する価値を直

接所有することを可能にし、個々の会社の一部が廃業しても、これらのエコシステムでは運営を続け

ることができます。

Kin by Kik Interactive - 事例研究

Kik Interactive Ltd.6 はカナダと米国に本拠を置く確立された消費者ブランドで、チャットで世界を接続

するという目標をかかげています。Kik Interactive は世界中に 4つのオフィスで 150人以上の従業員が

勤務しており、10 億ドル以上の評価額を持つ、フォーチュンユニコーン・リストのメンバーです。

その主なコンシューマ製品は、Kik Messenger7 です。これは人気のモバイルチャットアプリで、iOS

App Store で 5番目に多く検索されたキーワードでした。8Kik は 9年間事業を続けており、個人のベン

チャー・キャピタルから現在まで 1億 2000万ドルを調達してきました。

Kik は、ドット・コムとモバイル時代の技術的な飛躍がもたらした、完全に接続された世界に対する

楽観的な見通しに基づいて作成されたコンシューマ製品の典型例です。現在では、この場合ワーテル

ロー大学での友達のグループが、ガレージでアプリを作成し、究極的には 1 億のユーザーを見つける

ことができるようになったのです。

この数年にわたって、Kik は、ユーザー体験あるいはプライバシーを危険にさらすことのない持続可

能なマネタイズモデルを模索しています。しかしながら現在は、デジタル・サービスの大部分が広告

宣伝を引きつけることに基づく経済およびマネタイズで組織された世界で運営されています。問題は、

オンライン広告市場に非常な不公平が存在することです:より大規模なプレーヤーがより多くのユー

ザーのデータを持っており、したがって、広告を高価で売ることができます。これは、小さなアプリ

がそれらのサイズに比例した収益を得られないことを意味します。現在の収益は、指数関数的成長の

パターンに似ています:

6 https://www.kik.com/ 7 https://en.wikipedia.org/wiki/Kik_Messenger 8 https://www.kinecosystem.org/static/files/Kin_Whitepaper_V1_English.pdf

12

市場がこのように組み立てられている場合、広告市場の大部分のシェアが、最も高い利潤差額を得る

わずかの大規模プラットフォームに吸収されています。それらは、市場統制でより小さなプラットフ

ォームが利益を得られず、より大きなプラットフォームのみが利益を得るレベルに市価を設定します。

これによって、数多くの小型製品は維持できず、少数の非常に有益な巨人のみが残ります。

この収益グラフは、Kik が将来収益で困難に直面することを意味します。見込みおよびユーザーイン

プレッション数が多いにもかかわらず、Kik は資金で難儀していました。この問題は Kik だけではあり

ません。ほとんどすべてのデジタル・サービスは、指数グラフの特性上、指数の「間違った」側にき

てしまい、不運にもほとんどすべてがマネタイズで困難を経験します。通常力の 99%を 1%が持って

いることは、驚くことではありません。世界はこのように動いています。

この問題は毎年悪化しています。指数グラフはより険しくなっていると言えるでしょう。世界の統合

は進み、巨人との競争はより困難になり、世界を変えようとする大学友達のグループにとっては成功

が難しくなるでしょう。合併で市場競争が縮小され、イノベーションを阻む結果となるため、これは

消費者にとって不利です。

Kik Interactive は、この状況を変えるべく挑戦しました。最近の十年間で多くが、消費者アプリのマネ

タイズ問題を解決しようと努めました。しかし、Kik は、インターネットの広まりと同じような画期

的な変革のみが必要であると考えています。この変革がついにもたらされるかもしれません:暗号通

貨、あるいは正確には分散化コンセンサスの技術です。

この使命を念頭におい、Kik Interactive では、Kin という新しいトークンに基づく日常生活無エ k デジ

タル・サービスの分散的エコシステムを立ち上げました。

13

このトークンはデジタル・サービスを、広告宣伝に直接頼らずにマネタイズできる新たなエコノミー

を実現します。Kin のホワイトペーパー9 は、Kin エコシステム用のビジョンを、Kin リワードエンジン

(KRE)によってデベロッパーと消費者の誘因を調整することとして設定しています。10Kik のトークン

分配イベント(TDE)は、2017年 9 月に開催され、1億ドル近い KIN トークンが販売されました。

弊社はグラフの例を使用して、Kin の背後の一般的なモティベーションを実証することができます。

上記のグラフ中の赤い線は現在の経済行動です。青の線は公平な経済が目指すものです。Facebook と

比較して 1000 分の１の規模のサービスのデジタル・サービス・デベロッパーなら、Facebook の収益

の 1/1000 を得るでしょう。これは、この会社がさらに Facebook 社の 1/1000 の規模も企業を維持で

きることを意味するでしょう。通常力の 99%を 1%が持つことのは真実ですが、この場合、99%が、

青の線のように作用する世界へ移動することを支持するでしょう。

Kin リワードエンジンを通じて、デジタル・サービス・デベロッパーは、Kin の全面的な導入への貢献

に応じた報奨を受け取ります。Kin は、経済の自然な振る舞いを変更する、強力なツールを構成しま

す。生じたユーザーと収益数の間の線形関係を目指すものです。

これは、さらに、消費者アプリが集中化排除に賛成する理由でもあります。Kin トークン経済は大き

な価値を生成することができました。窃盗、ハッキングあるいは横領から集中元帳を保護することは、

困難で高価です。分散元帳なら、会社のサーバーにアクセスされても、元帳を操作することはできま

せん。これはユーザーに、より大きな保護を提供します。さらに、Kin エコシステムの成功は、デジ

タルサービスの結合の数に依存します。これまでは競合するデジタル・サービス間の協業は、分散的

平衡で当事者すべてが平等にならない限り、不可能だったのです。

9 https://www.kinecosystem.org/static/files/Kin_Whitepaper_V1_English.pdf 10 https://kinecosystem.org/static/files/Kin_Rewards_Engine_RFC.pdf

14

『オーブス』（Orbs）の広告ターゲット

『オーブス』（Orbs）プラットフォームは、大規模な消費者アプリケーション向けに、ブロック・チ

ェーン・インフラストラクチャを提供することに重点を当てます。消費者スペースで成功を収めたデ

ジタル・ブランドでは、通常ウェブサイトとモバイルアプリを通じ、数百万ものエンドユーザーにア

プローチしています。これらの消費者ブランドの大多数は既に確立されており、ブロック・チェーン

時代の前にユーザー・ベースを蓄積してきました。『オーブス』（Orbs）プラットフォームは、これ

らの消費者ブランドに、ユーザー向けの新興の分散化ビジネスを構築するための、ブロック・チェー

ン技術、トークン化、スマート契約および統合などのインフラストラクチャーを提供します。

明確で十分に定義された広告ターゲットと協業することは、さらに必要条件と目的が明らかであるこ

とをを意味します。『オーブス』（Orbs）は、汎用ブロック・チェーンを目指さず、最初から最後ま

で消費者アプリ市場および非常に個別化された必要条件セットのために構築されています。

設計パートナーによる構築 『オーブス』（Orbs）は厳格な必要条件主導アプローチで設計されています。設立チームは、ブロッ

ク・チェーンに移行する過程で主要な消費者ブランドのいくつかと緊密に協業しており、これらのブ

ランドを設計パートナーとして信頼しています。パートナーとしてさまざまな事業分野を選ぶことに

よって、弊社は現実的な解決の要点を必要条件としてカバーするよう保証しています。

ソーシャル/メッセージ分野では、弊社は Kik Interactive による Kik と協業しました。『オーブス』

（Orbs）チームは、当初 Kin TDE に助言しています。また、主要メンバーの数人は Kin エンジニアリ

ングチームに雇用され、既存のインフラストラクチャー・ソリューションを使用して、Kin を実装し

ました。Kik は『オーブス』（Orbs）設計の基礎になったプロセス 11 で識別された課題を明言してい

ます。『オーブス』（Orbs）は、アーキテクチャーと開発の両方で Kin 技術チームとの緊密な協力関

係を維持しています。

支払い/決済の分野では、弊社は Zooz Labs と PumaPay と協業しています。2010 年に設立された Zooz

は、Wix.com、バーバリーおよび Gett などの顧客と、国境を越えた主要な支払いソリューションプロ

バイダーです。Zooz Lab は、ブロック・チェーンに基づく国境を越えた支払いプロトコルを、普及し

ている消費者志向モバイルのウォレットアプリに導入しています。PumaPay はブロック・チェーンに

基づいプル支払いプロトコルを提案しています。これはペイパルの分散技術による代替です。創立時

点からの協業企業には、数億ものユーザーおよび何十億ドルもの価値の支払いを処理するビジネスで

あり、ライフスタイル・メディア会社 FashionTV および成人コンテンツメディアの巨人 Vivid

Entertainment などがあります。

11 https://medium.com/kin-contributors/kins-blockchain-considerations-ebd0b60aebd5

15

オンライン広告分野では、弊社は Zinc と協業しています。この企業は、利用者データの透明性を拡大

し、よりよいユーザー体験を提供し、不正ユーザーの影響を取り除き、広告業界中の効率を改善する

ことを目指す、ブロック・チェーンに基づいた広告プロトコルです。Zinc は、設計パートナーとして、

世界最大の広告宣伝技術供給者の 1 つである IronSource と協業しています。2011 年に設立された

IronSource は世界的に月間 10 億以上のユーザー勢力があり、Zinc が指数関数的に拡大し、次の広告す

るプロトコル標準となる可能性があります。

もう一つの重要な分野はビジネス・インテリジェンスです。弊社チームは、コカ・コーラ、ウォルマ

ートおよびマスターカードなどの顧客を持つ、ビジネス・インテリジェンス技術ベンダー、Endor と

緊密に協力しています。伝統的に、消費者志向ではなかった分野でありながら、Endor はエンドユー

ザーへの予測的ビジネス分析を提供し、AI クエリでグーグルのようなインターフェースを持つ分散的

プラットフォームを開発しています。

ともに、これらの会社とパートナーは、数百万の消費者、数十億ものアプリ・インストールおよび数

十億 USD の年間収入を持つネットワークを形作っていいます。弊社のチームは、構想段階からこれ

らのプロジェクトと緊密に協力し、『オーブス』（Orbs）ネットワークの内外でのソリューション設

計を支援しています。

16

分散化アプリのインフラストラクチャ

第一世代(Bitcoin)

Bitcoin は第一世代のブロック・チェーン技術とみなされています。Bitcoin を作成するために使用され

るビルディングブロックは、たとえばプルーフ・オブ・ワークの概念などは、Bitcoin より数年前にあ

られていました。しかしながら、Bitcoin は、これらのエレメントを組み合わせオープンで、合理化さ

れて、洗練された、安全な方法で分散元帳のコンセンサス問題を解決した点で独特でした。Bitcoin の

公開の成功の要因は、その根本的な技術に起因するものではありません。技術も興味深い物ですが、

成功の要因はその製品にあります。というのも、Bitcoin は第 1 にアプリケーションであり、インフラ

ストラクチャーではありません。このアプリケーションは実際非常にうまくいっていました。暗号通

貨はブロック・チェーン技術のキラー・アプリとなりました。

Bitcoin の最も大きな功績のうちの 1 つは、ブロック・チェーン技術が、実際に利用でき、大きな価値

を有する資産を保持できる安全な技術化銅貨についての疑いを緩和したことです。12 更に、以前に権

威によって提示されていたインフラストラクチャー・ソリューションよりかなりのより信頼できるも

のでした。集中統制がない驚くべき環境を築くことにより、ノードはすべて等しく、かつそれらすべ

て正直であると仮定する必要がありません。また、これは、数十億の価値の金融制度を正常に管理し

ています。

しかし Bitcoin は、当然第一世代技術としての欠点を持っています。高額の料金、多くの確認回数お

よびアップグレードの仕組みの困難さといった問題から、このシステムを、実際の金にかわる電子的

な選択肢以外に、プロダクションで使用することはできませんでした。

第 2 世代(Ethereum)

Ethereum はブロック・チェーン技術の第 2 世代と考えられています。第一次の革新はアプリケーシ

ョンととインフラストラクチャ層の間の分離でした。Ethereum はほとんどは単独では応用できませ

んが、ブロック・チェーン上で独自の分散化アプリケーションを作成する場合の、アプリケーション

開発に強固な基礎を提供します。これはスマートコントラクトによって行われます。13 これは、規定

の執行に十分なコンセンサスの見込みを持たせた上で、ネットワーク中のすべてのノード上で分散的

な方法で不変の数片の管理ソフトウエアを実行するものです。

12 https://coinmarketcap.com/currencies/bitcoin/

17

Bitcoin のような、Ethereum の時代の前の分散化アプリケーションは、モノリスとして実装されてい

ましたが、これは、アプリケーションとカスタムフィットインフラを、特定のアプリケーションの運

用で混合して使用していました。実装のための障壁が大幅に縮小され、近年の分散化アプリケーショ

ン開発のブームは、大部分はインフラストラクチャーとアプリケーションの分離によるものです。

当然、この巨大な飛躍を推進する最初のプロジェクトとして、Ethereum の重要な部分は、概念の稼

働中の実証として残っていますが、究極的には、実体経済では使用できませんでした。14

第 3 世代(『オーブス』（Orbs）)

技術の基礎がしっかりと確立され、現実世界のビジネスの分散化を可能にする次世代ブロック・チェ

ーン・インフラストラクチャー作成競争が起きています。ブロック・チェーン・インフラ計画の第 3

世代は、スマート契約技術実証の概念を越えて、実体経済の生産環境の実際的なビジネス・アプリケ

ーションに参入すると考えられます。その可能性に疑問はありません、しかし最も効率的な方法が模

索されています。

弊社では、Kin 技術チームとの Ethereum 協業の際に、概念の実証とプロダクション対応の間の差がど

れくらい広いかを通関しました。15第 3 世代プロジェクトへ発展させるために、Ethereum 自身も変化

しています。主な変化は、プルーフ・オブ・ステーク(PoS)への漸次切り替えです。これ以外に、第 3

世代候補の数は多く、EOS16 や Cardano17のようにさまざまな課題に注目した優れたプロジェクトが存

在します。

ブロック・チェーンをすべて支配する単一のブロック・チェーンはありません。弊社では、これらの

プロジェクトの多くが結実し、各々が、別個のシナリオでクラス内で最高のソリューションを提供す

るようになることを期待しています。

サービスとしての集中インフラストラクチャー 集中アプリのサービス(IaaS)としてのインフラストラクチャー向けのソリューションは、過去 10 年に

わたって著しく成熟してきました。主要なクラウド供給者は、アマゾン Web サービス(AWS)18、

Microsoft Azure あるいはグーグルクラウドプラットフォームなどがあり、産業のデファクト・スタン

ダードになりました。弊社の IaaS ソリューションを分散化アプリ向けに設計する場合、これらのサー

ビスから多くを学ぶことができるでしょう。

13 https://en.wikipedia.org/wiki/Smart_contract 14 https://medium.com/kin-contributors/kins-blockchain-considerations-ebd0b60aebd5 15 https://medium.com/kin-contributors/ethereum-challenges-while-launching-iplv2-8a33e1ba5a64 16 https://eos.io/ 17 https://whycardano.com/ 18 https://aws.amazon.com/

18

確立された消費者アプリはほとんどすべてが、インフラストラクチャーに、集中 IT サービスとして

のクラウドサービスを使用します。Airbnb19、Netflix20、Lyft21 のような会社が集中ビジネスにインフラ

ストラクチャーで AWS を利用しています。弊社は、分散化アプリケーションを持つ会社が分散ビジ

ネスにインフラストラクチャーを供給する、『オーブス』（Orbs）プラットフォームを使用すること

を期待しています。

また、観察事項として、優良製品の強調は、既存のブロック・チェーン・インフラストラクチャー・

ソリューションが不足していることを意味します。ではブロック・チェーンの優良製品とは何でしょ

うか。この問いは、まだ具体的なビジネス・アプリケーションがない新興分野でしばしば行われます。

例えば、料金体系の問題を考えてみます。ブロック・チェーン料金は、取引の送金人あるいはその受

取人が払われうべきでしょうか。あるいは第三者によって?料金は 1 つの処理ごと、あるいは 1 か月

当たりで支払われるべきでしょうか。料金は予測可能で一定あるいは市場決定されるべきでしょうか。

これらはすべて製品に対して強い影響力がある問いです-インフラストラクチャのユーザー体験を設

計するうえで重要となります。

これまでのところ、既存のソリューションで、これらの質問に対する答えのほとんどは製品について

の議論からではなく、セキュリティ、公平さあるいはゲーム理論的な考察から始まったように見えま

す。このインフラストラクチャーを使用する実際のビジネスはどのような形態を好むでしょうか。消

費者アプリがユーザーのインフラ費用を負担したいと思うかもしれません。さらに、恐らく事前に費

用の予算を計画的に決定したいと思うかもしれません。

わかり切ったことを最初からやり直す必要はありません:分散化インフラストラクチャーの製品は、

AWS のような集中インフラストラクチャーと大きく異なるわけではありません。AWS のような成熟し

たプラットフォームは、実体経済の必要に適合した数年間にわたり証明される慣習の例を提供します。

実用的なシステムズデザインの教訓

弊社は、拡張する分散システム設計について弊社の設計パートナーとの協業を通じ、実用的な見地か

ら重要ないくつかの観察を行いました。最初に、エンドツーエンド間で、分散システムを分散化する

必要はありません。目的に応じ、システムの重要な部分を集中化することができます。通常集中イン

フラストラクチャーは、分散インフラより著しく速くより廉価なため、これは効率に大きな効果があ

ります。

明白な例が、ブロック・チェーン上で動画内容を安全に処理するシステムです。従来のアプローチで

は、ブロック・チェーンのストレージに動画データを保存しますが、これは非能率的で、極めて高価

です。システムは動画の生データがより安い、より安く、より速い集中化ストレージに保存され、ま

た CDN によって配信され、ブロック・チェーンはハッシュ・コードおよびキー分配のみに使用され

る場合、システムを大幅に廉価に運用できます。

19 https://aws.amazon.com/solutions/case-studies/airbnb/ 20 https://media.netflix.com/en/company-blog/completing-the-netflix-cloud-migration 21 https://aws.amazon.com/solutions/case-studies/lyft/

19

もう一つの重要な観察は、現実のシステムでは複数のブロック・チェーンがしばしば利用されるとい

うことです。弊社は、ブロック・チェーンをすべて規定するブロック・チェーンはないと説明してい

ます。同じアプリケーションでも、異なるブロック・チェーン実装は、異なる目的に適します。

Kin は TDE 後に、Ethereum の ERC20 トークンとして開始されました。Ethereum は 1 日当たりの何百

万もの取り引きが行われる消費者アプリに必要な処理処理能力および料金効率を保持できないことが

判明したため、プロジェクトは、『オーブス』（Orbs）プラットフォームのような最適化されたイン

フラストラクチャー・ソリューションへの移行を検討しました。ERC20 は、現在交換、ウォレットな

ど(ハードウェアウォレットの可用度を含む)のエコシステムに一層統合が進められており、この移行

は既存のユーザーの上に負の影響を及ぼすことが考えられます。『オーブス』（Orbs）は大規模な消

費者プラットフォームですが、Ethereum は現在専門化された資産管理および交換により適していま

す。理想的な解決としては、2 ウェイのポータビリティでアトミックスワップを使用して、トークン

を両方のプラットフォームで利用可能にすることにより、両方の利点を享受できます。22

22 アトミックスワップの交換メカニズムの例:https://en.bitcoin.it/wiki/Atomic_cross-chain_trading

20

『オーブス』（Orbs）プラットフォーム

概要

『オーブス』（Orbs）プラットフォームは、分散的で、開かれた、透明なネットワークで、大規模な消費

者アプリケーション向けにサービス(IaaS)としての公開ブロック・チェーン・インフラストラクチャーを供

給します。弊社では、分散化ビジネスの傾向が強まり、確立された消費者ブランドが、分散化が始める新

たな機会を利用し、ブロック・チェーンへの移行が進むことを期待しています。『オーブス』（Orbs）は、

これらの分散化アプリケーションを実行し、この移行を促進するためのクラウド・インフラストラクチャ

を提供します。

『オーブス』（Orbs）プラットフォームの 3 つの主要なインフラストラクチャー提供物は、コンセンサス

に基づく分散コンピューティングサービス、コンセンサスに基づく分散化ストレージサービスと、サービ

スとしてのコンセンサス(CaaS)を含んでいます。

分散コンセンサスによるコンピューティング

コンピューティングサービスは、分散化アプリケーションのデベロッパーがネットワーク上でアプリを実

行し、かつ様々なノードでコードを実行することを可能にします。アプリケーションは、多数の独立ノー

ド上で完全に分散化され安全な方法で実行されます。実行の結果は、単一の一貫した結果を確認するのコ

ンセンサスが行われます。コンピューティングサービスは、AWS EC2 や AWS ラムダのような集中 IaaS サ

ービスに類似していますが、ブロック・チェーン技術を使用するものです。ブロック・チェーンの世界で

は、コンピューティングサービスは、原則としては Ethereum のスマート契約の執行に似ています。

分散的コンセンサス ストレージ

分散化アプリケーションの開発元は、ストレージサービスによってネットワーク上でデータを保存できま

す。データは多数の独立したノード間でレプリケート、シャーディングされ、完全に分散化された方法で、

安全に保存されます。

23 https://aws.amazon.com/ec2/ 24 https://aws.amazon.com/lambda/ 25 https://en.wikipedia.org/wiki/Shard_(database_architecture)

21

ストレージは、データにコンセンサスを施行し、ノード間に矛盾がないことを確認します。ストレー

ジサービスは AWS S326 や AWS DynamoDB27といった集中 IaaSサービスに類似しています。ブロック・

チェーンの視点からストレージサービスは、原則としては Ethereum、あるいは IPFSでブロック・チェ

ーン自体のデータを保存することに似ています。28

サービスとしてのコンセンサス 『オーブス』（Orbs）プラットフォームは完全に分散化され、異なる組織によって所有、操作される

独立したノードから構成されているため、これらのノード間のコンセンサス能力はネットワークの中

核の根本です。『オーブス』（Orbs）のコンセンサスレイヤーは、モジュール方式で、コンピューテ

ィングやストレージのように、上部にインフラストラクチャレイヤーを追加できるように設計されて

います。さらに、ユーザーが他のサービスと無関係にコンセンサスに達することを可能にします。例

えば、ドキュメントを証明する CaaS、あるいは分散化オラクルからのインプットを使用できます。

『オーブス』（Orbs）の固有のクロスチェーンコネクターを使用することで、CaaS は、他のブロッ

ク・チェーン・プラットフォームの状態の証明や、さらにはプラットフォーム間のアトミックスワッ

プ実行に使用することができます。

設計原則 『オーブス』（Orbs）は厳格な必要条件主導アプローチで設計されています。現在数億ものユーザー

が利用するマスマーケット・アプリケーションの設計パートナーとの協業によって、弊社は次の 4 つ

のエリアを焦点としました:

サービスレベル契約(SLA)

SLA はサービス・プロバイダーとサービス利用者の間の契約です。品質、可用性、応答性のレベルの

ようなサービスの特定の様相について、事前に詳細なメカニズムによってユーザーと合意し、SLA を

保証し、あるいは SLA を満たさない場合はユーザーに賠償が行われます。SLA は従来の消費者インフ

ラストラクチャ・スペースの業界基準で、AWS のような集中 IaaS プラットフォームで広く使用され

ています。29『オーブス』（Orbs）では、SLA は従来の当事者間の書面契約を越えるものです。プロ

トコルの直接の一部として実装され、ネットワーク設計に不可欠であるためです。

SLA は消費者アプリにとってサービス水準の予測可能性を向上するために重要です。消費者の期待は、

アプリの可用度が高く、ユーザー離れを招くような混乱がないようにすることです。ブロック・チェ

ーン・プラットフォームは、優れた性能と極めて低い料金を提供しても、利用状況が混雑した場合ア

プリケーションにほとんど価値をもたらさないでしょう。

26 https://aws.amazon.com/s3/ 27 https://aws.amazon.com/dynamodb/ 28 https://github.com/ipfs/ipfs/blob/master/papers/ipfs-cap2pfs/ipfs-p2p-file-system.pdf 29 https://cloudiqtech.com/aws-sla-summary/

22

消費者の規模 通常数百万ものエンドユーザーが利用する消費者アプリには激しいスケール要求圧力があります。こ

れは主としてメッセージ処理能力、メッセージレイテンシーおよびサポートされるユーザーの数など

の点です。参考として、Lyft は、30 日当たり 100 万以上の配車を処理します。30 ブロック・チェーン

技術で処理した場合、これらの配車の各々は複数の処理から成ります。配車の注文、ドライバーの配

車、支払い、確認などです。これらの処理の各々を、利用者とドライバーの間の効率的な処理を提供

するため、ほとんど即時に処理する必要があります。ブロック・チェーンの用語では、メッセージ処

理能力およびレイテンシーは処理能力および確認時間となります。

消費者の規模は、処理能力やレイテンシーのような生のネットワーク特性に影響を及ぼすだけではあ

りません。規模は、プラットフォーム設計のほぼあらゆる面に影響を及ぼします。例えば料金モデル

のスケーラビリティを考えてみましょう。1 回の処理当たりの固定費用が徴収されるインフラストラ

クチャー料金では、処理の数にあわせて直線的に料金が拡大し、特にマイクロトランザクションのよ

うな多量使用パターンでは、消費者アプリが成長するためのフレームワークとしては貧弱となります。

消費者保護と規制 分散化ネットワークは取り締まれないという共通の誤解があります。実際上、ペースの速い技術革新

より規制が後手に回ることはあっても、そのユーザーは、究極的には規制に従い、必要な場合その保

護を求めることができます。分散化されても、消費者アプリは通常明確な法的な同一性を持つ、十分

に定義された組織あるいは会社によって開発されています。これらは、政府、および産業体(例えば、

アプリストア)の両方の規則に従い、法的・契約上の制限内で営業します。確立された消費者ブラン

ドについては、規制上の不安定さは機会というよりむしろ危険です。規制を順守しない場合に多くが

失われるためです。

設計パートナーとの経験から、弊社は規制遵守がしばしばロードマップのクリティカル・パスになる

ことを示しています。技術インフラストラクチャの選択は、政府の許認可およびアプリストア規則遵

守のための要件に影響を与える可能性があります。

最新の配備パラダイム

Bitcoin SegWit2X31 のような歴史の手痛い学びから、分散システムおよび改善を続ける能力の実際の成

功には、内部規制が重大な役割を果たすことが示されました。弊社は、内部統制、およびプロトコル

の連続的な発展での整備されたプロセスを『オーブス』（Orbs）のデザインの最重要事項とみなして

います。エバーグリーンノードのインセンティブは ORBS トークン経済のまさに基礎に組み込まれて

います。

30 https://blog.lyft.com/posts/one-million-rides-a-day 31 https://www.coindesk.com/2x-called-off-bitcoin-hard-fork-suspended-lack-consensus/

23

スマート契約の不変性の問題も、Ethereum のパリティマルチシグバグの余波のような事件から重要

となりました。32 スマート契約では、一定のローカル統制を使用し、統制機関(あるいは管理 DAO)の

仲裁を要求せずに、緊急の状況に対応できるようになりました。

さらに、現実世界の大規模生産での経験から、プロダクション・システムが、スイッチひとつで 0%

から 100%までといったような、ネットワークにフォークとしての大規模な変更を適用することが非

現実的なことが示されました。現代の展開戦略では、一定のモニタリングの下で変更を徐々に(5%、

その後 20%～50%など)展開させること、またロールバック能力も要求されます。システムでは、独立

した実験としてこうした多数の垂直的変更を展開できる必要があります。これができない場合開発は

著しく長期化し、遅れが発生するでしょう。

32 https://blog.comae.io/the-280m-ethereums-bug-f28e5de43513

24

ネットワーク組織

『オーブス』（Orbs）は大規模な消費者アプリ向けのブロック・チェーン・インフラストラクチャで

す。ネットワークに参加する組織は、いくつかに分類されます:

消費者

消費者は、アプリを使用する、ネットワーク中のエンドユーザーです。消費者は、通貨に基づく製品

について、ウォレットホルダーの大部分を占めます。一般に、弊社は、消費者は数億となると考える

ことができます。消費者は、モバイルアプリあるいはウェブサイトの使用によりネットワークへのア

クセスを行うでしょう。消費者は『オーブス』（Orbs）ネットワークに直接アクセスせず、Bitcoin の

ような代替ブロック・チェーン実装のようにノードを操作することはありません。消費者の『オーブ

ス』（Orbs）ネットワークへのアクセスは、常にアプリによって提供されます。

モバイルアプリおよびウェブサイト上の使用プロファイルは、リソースの可用度が極めて低い特徴が

あります。低い計算能力、低いメモリおよび低いパーシステントディスクストレージです。ネットワ

ーク接続は、非常に断続的です。消費者がどれくらい多く、およびどれくらい長く接続するかについ

ての保証はありません。さらに一般に消費者アプリは、高い解約率に苦しんでいます。ユーザーはア

プリの利用を続けないことが多いのです。アクティブユーザーの数は、登録ユーザーの数より通常著

しく低いものです(この数は多くの場合 5%しかありません)。規制の視点からは、規制のほとんどは、

消費者の利益の保護に向けられます。

『オーブス』ネットワーク

25

アプリ アプリは、ブロック・チェーン・インフラストラクチャで実行され消費者のために処理を行なう製品

です。数百の分野で、ネットワーク内のポピュラーな消費者アプリはわずかであると仮定することが

できます。これはほとんどの消費者アプリが非常に競争率が高く、消費者の関心を引くことは非常に

難しいためです。数百万ものアプリがアプリストアに存在しますが、平均的なモバイルの消費者が使

用するモバイルアプリの数は 1 ダースを超えません。『オーブス』（Orbs）プラットフォームは、当

然高ボリュームおよびポピュラーなアプリに最適化されています。

消費者アプリは通常明確な法的な同一性を持つ、十分に定義された組織あるいは会社によって開発さ

れています。これらは法的規制対象であり、法律の限度内で運用することが求められます。『オーブ

ス』（Orbs）プロジェクトがターゲットとする大多数の消費者ブランドは十分に確立され、ブロッ

ク・チェーン時代の前から集中組織として存在していました。これらは、現在消費者との連絡は集中

チャンネルに依存しています。ブランドドメインのウェブサイトもアプリストアのモバイルアプリも、

完全に集中化されています。

消費者アプリにとってリソースは豊富あることが必要です。ブロック・チェーン界の外部では、消費

者は、ネットワーク規模および反応性への期待が高いことが知られています。弊社は、アプリによっ

て操作されたノードがより高い計算能力、より多くのメモリおよびパーシステント・ディスク・スペ

ースを持つと仮定できます。ネットワーク接続も安定した性能を仮定することができます。

コンセンサスノード これらは、コンセンサスプロセスに参加し、実際の計算、またブロック・チェーン・インフラストラ

クチャーで分散アプリを実行するストレージを提供するサーバーです。ノードは様々な会社および組

織によって所有および操作されます。各組織で複数のノードを展開することもあります。

ノードは、プロトコルに従って、例えば『オーブス』（Orbs）ソフトウェアスタックの実行によりネ

ットワークに参加します 33 -これは『オーブス』（Orbs）プロジェクトで開始され、オープン・ソー

ス・コミュニティで維持され、無料で分配されるオープン・ソース参照の実装です。ネットワーク中

のノードの収集は、統制の集中ポイントを持たず、『オーブス』（Orbs）プロジェクトで所有やコン

トロールは行われていません。ネットワーク中のノード数は、アプリの数と同じスケールとなること

が予想されます。実際、アプリ・デベロッパーはネットワーク中でノードを運用するよう推奨されて

います。また、2 つのグループ間には、大きな類似が予想されます。ノード冗長(強健さのためのいく

つかのノードを大量に産む単純組織)および Kin のようなエコシステムアプリを考慮する場合(組織の

エコシステムが、全体でアプリを操作する)、ノードの数が 1 つあるいは 2 桁大きくなると予測でき

ます。

33 https://github.com/orbs-network

26

監査ノード さらに、ネットワーク中には主目的がブロック・チェーンの公開監査によるセキュリティ層を加える

ためのサーバーもあります。監査ノードは、コンセンサスプロセス自体には積極的に参加せず、スト

レージにデータを書くかあるいはブロックを閉じる能力を持っていません。このため、監査ノードの

断続的なネットワーク接続や休止時間のような信頼性の低い振る舞いは、ネットワークの総合的性能

には、直接の負の影響を及ぼしません。

監査ノードは、さらにコンセンサスノードと同じソフトウェア・スタックの実行によって、ネットワ

ークに参加します。実際、コンセンサスノードは、追加の責任と平行してそれ自身についての同様の

監査プロセスを行ないます。これらは、コンセンサスノードのように、集中統制ポイントを持ちませ

ん。また、監査ノードの収集は、『オーブス』（Orbs）プロジェクトによって所有やコントロールさ

れていません。

『オーブス』（Orbs）プラットフォームは、公開で検査できるように設計されています。組織および

個人は、ネットワークに一般的なセキュリティ維持を支援する監査ノードを運用するよう推奨されま

す。ノード運用もトークン経済モデルによって奨励されます。弊社は、必ずしもコンセンサスノード

の数とは相互に関連しないネットワークで多くの監査ノードを提供することができます。

27

『オーブス』（Orbs）エコシステム

中核インフラストラクチャー

『オーブス』（Orbs）のソフトウェア・スタックのプロトコルを実行するネットワークのノードは、

消費者志向の分散化アプリデベロッパーのインフラストラクチャー層として、『オーブス』（Orbs）

プラットフォームのコア・コンピタンスを提供しします。中核となる提供物は、コンセンサスに基づ

くコンピューティング、コンセンサスに基づく保存サービスおよび CaaS です。Ethereum のようなプ

ロジェクトで重要な、チューリング完全 34 言語は、アプリケーションの基礎としての信頼性が証明さ

れました。弊社はインフラストラクチャー層が、アプリケーションの能力を制限することは開始濃い

ことではないと考えます。これらがこの分野でのイノベーションの主な推進力となり、前もって正確

な必要条件を完全には予想することができないためです。

専門インフラストラクチャ

プラットフォームのコア・コンピタンスは分散化アプリのビルディングブロックの最も基礎的な部分

となります。これらのブロックは極めて柔軟なものですが、経験から、しばしばサードパーティによ

って構築される複雑なアプリケーションが専門インフラストラクチャが同様に要求されることが示さ

れています。

分散化分析は、Kin 使用例での専門インフラストラクチャの具体的な例です。Kin エコシステムのほと

んどのパートナーで、データとビジネス・インテリジェンスの層(BI)を必要としますが、自前のソリ

ューションを開発または維持する資源を持っていません。集中化 BI ソリューションで、確立された

ソフトウェアベンダー(Sisense35 や Tableau36など)によって提示されたものを利用することには、問題

があります: パートナーのほとんどの戦略的意思決定はこのデータに基づいて行われますが、集中ア

カウントをコントロールする当事者によってデータが操作を受けないと保証することはできないため

です。分散的なソリューションはよりよい選択肢ですが、現在、Kin ではゼロから開発する必要があ

ります。この場合最良のオプションは確立された BI ソフトウェア・ベンダーが分析プラットフォー

ムの分散バージョンを開発することです。

34 https://en.wikipedia.org/wiki/Turing_completeness 35 https://www.sisense.com/ 36 https://www.tableau.com/

28

ただしベンダーが分野で完全な専門知識を有することが前提となります。ベンダーは『オーブス』

（Orbs）プラットフォームと接続し、『オーブス』（Orbs）スマート契約から直接アクセスできる

API によって Kin デベロッパーにインフラストラクチャーを供給することができます。

もちろん、専門インフラストラクチャーの使用例は BI に制限されず、さらに、バックオフィス・ソ

フトウェア、オラクル、統合 ERP/CRM プラットフォーム、ネイティブキーバリューストアを越える

他のタイプのストレージおよびデータベースなどのツールや統合ポイントが含まれることもあります。

インフラストラクチャ・マーケットプレイス 『オーブス』（Orbs）は、専門の第三者ソリューションの開かれたインフラストラクチャーエコシス

テムの構成を促進しています。その参加者は分散化アプリケーション開発者にワンストップ・ショッ

プを提供します。こうしたプラットフォームは分散化技術一般を促進し、専門の補足インフラストラ

クチャー供給者を支援します。このエコシステムでは、作成したインフラストラクチャ・ソリューシ

ョンにトークンを使用して、サードパーティが支払いを受け取ることができる、ORBS トークンに基

づいたサービスの経済が確立されるでしょう。

分散化アプリケーション開発者のための利点は明らかです-それは、分散技術ニーズのすべてに単一

の統合チャンネルおよび共通言語が利用できることです。このモデルは AWS Marketplace37 のような

集中インフラストラクチャー・プラットフォームで、サードパーティが AWS 顧客に対するアップセ

リング専門のサービスを行う場合に成功が証明されました。

37 https://aws.amazon.com/mp/

29

ORBS トークン

概要

ネットワークの在来のトークンとして、『オーブス』（Orbs）プラットフォームは、ネットワーク・オ

ペレーション促進で ORBS トークンを利用し、またコンセンサス層のオペレーション、スマート契約お

よびコンセンサスに基づくストレージの執行と関連した料金を支払う手段を提供します。これらはプラ

ットフォームによる 3 つの主要な提供したサービスであるためです。この料金モデルは、ノードにとっ

ては、ノード運用に必要な資源を割り当てる誘因となり、また予測可能で安定したサービス、可用性、

性能およびセキュリティレベルへの消費者の期待とのコンセンサスである SLA を保証します。言いかえ

れば、ノードのサービス料金は、ノードを利用する消費者アプリケーションから支払われます。

ORBS トークンは、単に『オーブス』（Orbs）中核インフラストラクチャーであるだけではなく、

『オーブス』（Orbs）プラットフォームの周辺で構築されたエコシステム全体のための推進要因です。

これはインフラストラクチャー市場を推進し、プラットフォーム上で、アップセルに特化した、分散

化インフラストラクチャー・ソリューションとして、第三者インフラストラクチャー供給者の支払手

段となります。第三者の分散化インフラストラクチャー・ソリューションの徴収モデルは、インフラ

ストラクチャー自体とあわせて発展することが見込まれます。さらにこれらは、新しいトークン経済

に適合する必要があり、徴収に新しい次元の柔軟性と、提供するプログラム可能性を活用することが

求められます。

徴収サブシステム

『オーブス』（Orbs）プラットフォームは、徴収とと会計を明瞭に区別します。毎月の間隔で徴収し、

会計でローカルの不換通貨を使用する、AWS のような集中インフラストラクチャから着想を得て、こ

のプラットフォームでは、分野に特有のメトリクス(計算で CPU 分、あるいはストレージと帯域幅用

では GB)に基づき、使用およびオンデマンドにつき別々に計算されます。発電ブロック・チェーン・

プラットフォームは、Ethereum のように、これらを区別せず、取り引きと料金支払いを一組として、

料金それ自体が、すべての処理に明示的に紐付けられていることを要求します。

30

『オーブス』（Orbs）徴収サブシステムは、ORBS トークンに基づき、毎月の間隔で徴収を行なう柔

軟性を提供します。会計は『オーブス』（Orbs）プラットフォーム上で、分野に特有のメトリクス

(取引処理能力あるいはチェーンで使用されるストレージ)で、取り引きごとにオンデマンドで個別に

行なわれます。この分離により、今日、ほとんどのブロック・チェーン・ソリューションで使用され

る処理ごとの硬直した徴収および料金モデルと比較して、柔軟性が高まります。

プログラム可能な料金モデル 『オーブス』（Orbs）徴収サブシステムはインフラストラクチャー料金モデルをさらに先に進めます。

設計パートナーとの提携の経験から、インフラ費用に対する料金を集める場合、さまざまに異なるア

プリケーションが好まれることがわかりました。デジタル・サービス上でホストされたマイクロトラ

ンザクション指向のピア・ツー・ピア市場では、デジタル・サービスがインフラストラクチャーに対

する料金徴収を代行しそれらのエンドユーザに見せないことが好まれます。例えば Tinder のようなデ

ートアプリを想像してください。ユーザー獲得には無料モデルが重要となります。これらのシナリオ

内で、エンドユーザがインフラ費用を事前に支払うと期待することは、インスタント・メッセンジャ

ーのエンドユーザーにメッセージ配信コストの支払いを求めることと同じく適切です。

これは、有料登録方式の導入を通じて『オーブス』（Orbs）で達成されます。有料登録は、多くの場

合インフラストラクチャー・サービスに対する支払いを行う、分散化消費者アプリケーションのデベ

ロッパーのために設計されています。エンドユーザーがインフラ費用の代価を独力で支払う点で、こ

の料金モデルは、Ethereum のよりも AWSの料金体系に近くなっています。

『オーブス』（Orbs）プラットフォーム設計では代替モデルもサポートします。消費者アプリケーシ

ョンでは、高額の支払いが直接行われることはあまり頻繁にはありません。分散的な Airbnb のよう

に、こうした処理を始めた当事者が料金を支払うことを好む可能性があります。さらに 1 歩進み、イ

ンフラストラクチャーの実際の費用が一定であっても、支払高に比例した料金体型が作られる可能性

もあります。他の製品では、受取人が料金を支払うことはより適切となります。

これらのさまざまな要求に対処する方法として、この決定のエレメントをインフラストラクチャー層

からアプリケーション層に移動させることがあります。一定のプログラム可能性を料金モデルに加え

ることによって、スマート契約で、料金がどのように払われるか明示し、アプリケーションは、いわ

ばそれらのニーズに料金モデルを適合させる自由を維持できるでしょう。これは、さらにこうしたシ

ステム上ではもう一つ共通の課題が解決できます。ここで料金は 1 つのトークンで払われ、また、処

理は別のトークンで行なわれ、両方のトークンの残高を保持することをユーザーに要求します。

経済インセンティブ 従来の不換貨幣ではない、トークンに基づいた経済の主な利点の 1 つは、システムを管理し、あらか

じめ定めた包括目標セットに向けて、固有の奨励報酬システムを設計できることです。例えば、

Bitcoin では、ネットワークのセキュリティを強化するために、ネイティブトークンを利用し、セキュ

リティクロージングブロックのプルーフ・オブ・ワークを持つノードに報酬を提供します。

31

2018 年 1 月時点で、およそ 150,000 ドルの価値の Bitcoin が存在し、この目的で平均で 10 分ごとに分

配が行われています。38 供給であらかじめインフレターゲットが定められた場合、このメカニズムは

Bitcoin の経済を作り出し、ユーザーが支払う手数料に加えて、自前でグローバルな目標のための資金

を調達できます。報酬は、ほとんどのマイニングの奨励報酬が吸収されるまで徐々に減少することが

予定されています。

『オーブス』（Orbs）プラットフォームでは、検証者(コンセンサスノード)への報酬が、当初から完

全に手数料に基づく計画となっており、トークン供給へのインフレはありません。弊社は、Bitcoin と

対立するものとして、ブロック・チェーン産業が十分に成熟しているため、処理と確認の料金設定が、

ブロック報酬という「補助」がなくても成立すると考えています。さらに、手数料により、確認サー

ビスが実際に行われた量に応じて間接費用の負担が分配されますが、インフレによる報酬を生成する

ことは、トークンのホルダーにとっては、保有高に応じた報酬コストが課されます。不動産税から、

補助金取引により市場を歪曲するように、インフレを使用して確認に対する補助を行うことは、結果

的にアプリ・デベロッパーにとっては非経済的な選択となります。

『オーブス』（Orbs）プラットフォームの手数料はいくつかの目的で設計されています:

● 高い SLA を維持のためのノードへの奨励

○ 休止時間のない高いサーバー可用度の確保

○ ハッキングからサーバーを守り、秘密鍵を保護

○ 高速ネットワーク接続と高速サーバー・ハードウェア

○ 他のノード(リソース提供など)に対する関与を支持

○ 定期的なサーバー・メンテナンス

● 公式 ORBS トークンを分岐させないためのノードへの奨励

○ 公式エコシステムに参加し、分離させない

○ 他のネットワーク・メンバーとのコンセンサスプロセスへの参加

○ 新しい消費者ブランドおよび組織にネットワークとの連結を奨励

● プロトコル更新の定期的な評価と採用をノードに奨励

○ オープン・ソース・コミュニティ、他のフェデレーションメンバーおよび『オーブ

ス』（Orbs）プロジェクトで提案されたプロトコル変更の検証に参加

○ 他のすべての人と同じプロトコルを実行

○ 旧式バージョンのための寿命サイクルを早め、維持費を下げる

● ネットワークの公開監査を奨励

○ ネットワークの公開安全確認

○ リアル・タイムでのプロトコルへのコンセンサスを確認する監査ノードの運用

○ セキュリティ研究者に脆弱性の悪用ではなく報告を奨励

38 https://www.anythingcrypto.com/guides/bitcoin-mining-block-rewards-2018

32

経済でのもう一つの目標、余剰需要を十分に処理し、またこのシナリオ中で誰がサービスを得るかを

決定することです。これにより、アプリケーションでは、処理能力あるいはストレージのような専用

リソースの代価を支払い、またアプリケーションとユーザーがネットワークにスパムを送り、実際の

ノード・サーバー・コストの代価を支払うことを防ぐために必要な障壁を提供します。

徴収した料金がネットワークを介してサービスを提供したノード・オペレーターにどのように支払わ

れるか決定する、徴収サブシステムの特定の実装の詳細に加えて、『オーブス』（Orbs）プラットフ

ォームでは、他に 2 つの中核的要素が経済誘因の実装で使用されます。その 1 番目は、ノードのレピ

ュテーション・システム です。コンセンサスプロセスで計算され、ヘリックス・コンセンサス・ア

ルゴリズムのようなプラットフォーム・コンセンサス・アルゴリズムによって円滑化されます。第 2

番目は、消費者アプリケーションに、エコシステムを連結し、コンセンサスノードを維持するための

奨励です。これは、プラットフォームのユーザーの誘因と、それを運用するノードを調整します。

さらに、プラットフォームのブートストラップのために、『オーブス』（Orbs）プロジェクトでは、

エコシステムを連結する際に、信用ある消費者ブランドの参入コストを相殺するトークンの予算を立

てています。

トークン実装 『オーブス』（Orbs）プラットフォームの最初の公開においては、弊社では、Ethereum ブロック・

チェーン上の徴収サブシステムの実装を開始することを計画しています。弊社は、Ethereum を、今

日ほとんどの産業で ERC20 トークンで利用できる広範囲な第三者統合が行われている、実用的な分散

化徴収システムとして有望な最初の選択肢と考えています。これらのエコシステム統合では、第三者

ウォレットおよびハードウェアウォレットは、徴収サブシステムの対象とするオーディエンスと企業、

専門家にとっては、暗号通貨の形で多額の通貨を管理することがしばしば要求されるため重要となり

ます。Ethereum の現在の規模の制約から、この徴収製品には問題とならないでしょう。取引の徴収

率が月一度と低く、取引額が巨額のため、Ethereum の手数料は、ほぼ無視できるからです。これら

のパラメーターは、AWS のような集中インフラストラクチャー・ソリューションの共通の支払手段で

ある電信送金とほぼ同一です。

着手時に ORBS トークンを ERC20 トークンとして実装することは、さらに多国語クロス・チェーン契

約（Polyglot Cross-Chain Contracts）のような『オーブス』（Orbs）の中核プラットフォーム機能に、

生産での使用例を提供します。『オーブス』（Orbs）プラットフォームで有料登録されるスマート契

約では、Ethereum ブロック・チェーン上の徴収情報にアクセスします。その相対的な利点に注目し

て、2 つのブロック・チェーンを並用することができる場合、これは、マルチ・チェーン・ハイブリ

ッドが実用として意味をなす重要な例となるでしょう。売り出しと運用開始に向けた、『オーブス』

（Orbs）プロジェクトのリソースは、消費者の規模およびブロック・チェーン・バーチャリゼーショ

ンのようなプラットフォームの主要な差別化要因に一層重点的に割り当てられます。交換、第三者ウ

ォレットおよびハードウェアウォレットを統合するエコシステムを作り出すことは、即時の優先事項

ではありません。しかしながら、『オーブス』（Orbs）プロジェクトは、これらにも究極的には同様

の資源を投入することを計画しています。

33

アーキテクチャ

分岐の有無

新しいブロック・チェーン・インフラストラクチャーを設計する場合、構築の出発点での最初の疑問

の一つが、既存のシステムを分岐すべきかどうかです。産業での占有率を高める手段として、弊社で

は Bitcoin と Ethereum 以外に、CoinMarketCap39の上のトップ 20 のトークンを調査し、これらのトー

クンの半分以上が 他のポピュラーなトークンの分岐であることを明らかにしています。分岐は、こ

の分野での知的財産の寛容さから、新たなシステムを迅速にブートストラップする一般的な方法とな

っています。

弊社の結論としては、この判断は、システムが究極的に何を達成しようとするかによるというもので

す。弊社が十分にスペースをマッピングし、既存のブロック・チェーン・ソリューションを見つけた

場合を仮定します。このソリューションは弊社の構想を緊密に実装し、したがって、弊社はこの構築

手法を分岐と考えます。前述のシステムで、最終的な結果が 30%異なると想定する場合、分岐が正解

となります。最終的な結果が 70%において異なると想定する場合、弊社は分岐をするべきではありま

せん。これを原則として、一般ブロック・チェーン上の消費者アプリケーション・セクターで成熟度

が低いことから(最近、最初の 10 億ドル規模の消費者ブランドがブロック・チェーンに移行を始めま

した)弊社では、分岐をしないことを決定しました。弊社では、システムをゼロから弊社の独自の使

用例にあわせて設計し、高機能アーキテクチャの開発を行うため、プロダクションの時期は短期的に

は遅延します。弊社は、さまざまなセットの必要条件から出現するアーキテクチャーを使用すること

による潜在的な間接費を節約することを追求します。

多言語マイクロサービス

ソフトウェア・システム・アーキテクチャーの発展の中で、従来型のシステムは、当初の単一のプロ

グラムから完全システムへと徐々に成長をとげてきました。当初、システムは、単一のプログラムに

すべての機能を含めた、非常に単純なモノリスと呼ばれる方式でした。システムに機能が追加される

につれて、そのコードベースと寄与するデベロッパーグループの両方が成長しました。

39 https://coinmarketcap.com/

34

こうした成長により、プロジェクトでは、懸念事項の分離原則に従い、モジュールを分離することが

行われました。40 この数年にわたって、モジュール方式は、機能および開発チームののスケーラビリ

ティの面で成功することが分かりました。

インターネット革命はシステムズデザインに新しい挑戦をもたらしました-最新のシステムでは、通

常大規模で運営され、他のシステムおよび素百万ものエンドユーザーに対応することが求められる様

になりました。これはエンジニアリング・プロセスの両側の変化に結びつきました。開発側において

は、こうしたシステムの複雑さから、リファクタリングのような新しい開発パラダイム、迅速な開発、

連続的な展開と、構築、測定、学習サイクルが要求されます。運用側においては、複雑なインフラス

トラクチャーに依存し、大量のインターフェースを処理する能力を確保することに結びつきます。両

側の変化によって、繊細なモジュール相互依存性から、モジュール方式の適用が困難となりました。

こうした困難から、サービス指向アーキテクチャーとマイクロサービス 41 の設計手法で、機能コンポ

ーネントがそれぞれ個別の、単純な、集中化製品として実装されことになりました

ほとんどの発電ブロック・チェーン・プラットフォームはモノリスとして構築されると結論づけるこ

とは簡単です。これは開発の状態が未熟であることを示すだけでなく、これらのプラットフォームに

基づいたシステムの機能を発展させ、拡張する能力を妨げます。さらに、複雑なオープン・ソース・

プロジェクトでは、定評あるライブラリーおよびフレームワークに対する依存から、モノリスが機能

の一部にのみ最適な選択として設計されていることで、制約がもたらされます。高度暗号を開発する

ための最適な環境は、分散化ストレージや、高機能ネットワーキングなどとは異なります。マイクロ

サービスアーキテクチャーによってシステムは多言語となります。これは、異なるプログラミング言

語およびフレームワークを異なるサービスに使用することです。こうしたアプローチはより質の高い

サービスを実現し、さらに適切な分野の専門知識を備えたオープン・ソース・ソリューションおよび

エンジニアリング人材のようなよりよいリソース活用を可能にします。

コードとしての仕様 多くのソフトウェア・エンジニアが、仕様書は公開時点から陳腐化することを実感しています。とき

には公開前に陳腐化することもあり得ます。したがって、弊社では、実行可能な 仕様書を作成し、

進捗の遅れがあった場合に把握できるよう努力しています。実行可能な仕様書によって、弊社は、コ

ードベースが仕様から外れず、後方互換性と正確さを持つことを保証しています。

ブロック・チェーン・ネットワークの分配・分散的性質から、実行可能な仕様書がさらに重要となり

ます。デベロッパーでは、サービスの展開ライフ・サイクルに対するコントロールをほとんど行うこ

とができないためです。したがって、API が壊れたり、バグにより、展開をロールバックすることは

現実的なオプションではありません。したがって、弊社のワークフローでは、実行可能な仕様書を広

範囲に利用しています。これは 2 つの大カテゴリーに分かれます: プロトコルバッファの仕様で、42

弊社の API スキームを生成することと、テスト主導開発(TDD)で詳細なテストが可能なコードを作成

することです。

40 https://en.wikipedia.org/wiki/Separation_of_concerns 41 https://martinfowler.com/articles/microservices.html 42 https://developers.google.com/protocol-buffers/

35

プロトコル・バッファー(あるいはプロトバフ)は、するグーグルで開発されたインターフェース定義

言語(IDL)です。プログラミング言語については無関係の立場で、前後方の互換性を備えた API を定義

することを可能にします。これは、API 仕様を定義するコードと、言語と実装コードを明確に区別し

ます。デベロッパーが API の静的な型検査を破壊するような実装を変更すれば、構築自体が失敗し、

デベロッパーへ直ちにアラートが送られます。各多言語のマイクロサービス間の API は特定の言語で

も定義されていないため、言語によらない IDL を使用する付加価値は多言語マイクロサービスのイネ

ブラーとなります。

テスト主導開発(TDD)は、挙動のコード化の前に、ユニットテストで必要な挙動がそれぞれコード化

される方法論です。実際としては、デベロッパーが見当たらない行動を定義し、テストの結果を失敗

させることで、失敗が予想通りであることを確かめることを意味します。次にそのテストが成功する

コードを実装します。この方法の追求は、試験されていないコードがソース・コード・リポジトリに

入らないことを保証します。次に、コードを調査しますが、定期的なコード調査と異なり、コード自

体(どのように)ではなくテスト(コードの行動)の正確さを確認することに注目します。このテストは、

特定の実装ではなくビジネス分野(例えば、2 つのアドレスで資金を転送)について記述するセマンテ

ィック言語で書かれています;実装の変更はテストに影響しません。実線では、TDD ではより短く、

より簡潔なコードが達成され、コーディング・プロセスが、技術的な負債を縮小し、より多くのリフ

ァクタリングサイクルから構成されることを示します。

メタプログラミング ブロック・チェーン・ネットワークの分配・分散化性質が従来の展開ではないエンジニアリングに課

題となるにつれ、これらの制約のうちのいくつかを回避する創造的なソリューションのニーズが発生

します。『オーブス』（Orbs）プラットフォームはオーバーザエア(OTA)展開をサポートする重大な

コンポーネントで広範囲にメタプログラミングを使用します。Ethereum のような他のブロック・チ

ェーン・ネットワークは、ユーザー展開可能なコードを実行する方法として、スマート契約の概念を

提案します。『オーブス』（Orbs）プラットフォームはこれらの考えを借用し、展開とプロビジョニ

ングのようなエンジニアリングの問題にこれを拡張しています。

弊社がメタプログラミングを利用する 1 つの興味深いエリアは資源管理とプロビジョニングです。こ

れはネットワーク自体(メタネットワークと見なすことができる)の実例上で作動し、スマート契約と

同じホットで展開可能なコードとして実装されます。これはリソース供給方法をコントロールします。

例えば、新しいバーチャル・マシンは新メンバーがエコシステムに参加する場合に、ネットワークの

キャパシティを増加させるため、特にこのメンバーが専用リソースの代価を払っている場合は自動的

にインスタンス化が行われます。エコシステムに新メンバーを参加させる場合制約のタイプ、また課

題予知するのが難しいため、このエリアで管理コードの OTA 展開可能な形にすることは非常に大きな

意味を持ちます。このアプローチの付加価値は、デベロッパーが「自分のドッグフードを食べる」、

自らプラットフォームのユーザーになることで、プラットフォームのランタイムへ即時の可視化が行

われることです。

36

もう一つの例は、よりユーザー・フレンドリーなフォーマット(あるいは、多数のアドレス間に混ぜ

て使用)での公開アドレスの解決を可能にする公開 DNS のようなサービスです。スマート契約のよう

なアドレス・リゾリューション・メカニズムの実装は、プラットフォームの在来の芯の一部にするよ

り維持がより簡単です-ちょうど Ethereum がスマート契約として ENSを実装するのと同様です。

ユニバーサル・アドレシング アドレシングは、様々な資源がシステムを横断してどのようにラベルを付け、引用されるかのスキー

ムをコントロールするブロック・チェーン・インフラストラクチャー中の重要なトピックです。論理

的な組織で、別個のアドレスがあるものは、トークン・アカウント、スマート契約およびそれらの保

存された変数を含んでいます。

ブロック・チェーン実装はそれぞれ異なるアドレス方式を採用しました。弊社は、異なるアドレス方

式は異なる特質を持っており、異なるアプリケーションに適しており、単一のスキームがすべての他

のものに関して優れていることはないと認識しています。例えば、Schnorr 公開鍵のようないくつか

のアドレス方式は、マルチシグのネイティブ・サポートを可能にします。他のアドレス方式はより広

いエコシステムの存在感を持っており、より多くのハードウェア機器および HSM でサポートされま

す。さらに、別のブロック・チェーン実装で使用されるものと互換性をもつアドレス方式は、多数の

プラットフォームにまたがって同じ公開アドレスを使用する利便性をエンドユーザにもたらします。

ブロック・チェーン実装の相互運用性を促進し、かつプラットフォーム上でより容易な移行を行うた

めに、『オーブス』（Orbs）はユニバーサル署名およびアドレス方式をサポートします。この方法は、

アドレス自体の隣のアドレスのタイプの指定により、アプリケーションとユーザーは、一連のポピュ

ラーなアドレス方式を並列で使用することが可能になります。アーキテクチャの視点から、アドレス

方式は、それらが産業を横断してポピュラーになるとともに、将来の追加スキームを支援するために

改良できる専用モジュールによって管理されます。

ネットワークは秘密を所有 集中システムでは、安全なオペレーションは、管理サービスによって機密を管理し、一般にデータに

署名する、暗号化する、解読する方式によって維持されいます。分散化ネットワークは、こうした仕

組みのない独立したノードで構成され、同様の方法の適用は簡単ではありません。秘密は個々のノー

ドによってのみ保持されます。システムの開かれた分散化性質により、この秘密は容易に漏れてしま

うため、ネットワークでは通常、全体として安全なオペレーションに使用するための共有の秘密を保

持できません。

37

この制限から、しばしばブロック・チェーン実装は、信頼が通常必要ない場合でも、シナリオについ

ての信頼に依存します。一つの好例は、エンドユーザのクライアントがネットワークとどのように通

信するか、ユーザーのバランスをチェックするなどの、ステートでクエリを行なうことです。クライ

アントがネットワークと同期し、資源集約的な確認の完全なスイートを行なう十分なノードを実行で

きないとすると、いくつかの妥協が見込まれます。よく利用される代替手段は、クライアントが特定

の通路ノードによってネットワークと通信し、確認のうちのいくつかを委任することです。これは、

正直なレスポンスを提供するために、ネットワーク状態のクライアントクエリが通路ノードを信頼す

る必要があることを意味します。このアプローチでの改良は、直ちに多数の通路ノードにクエリを行

う、通路ノードを無作為に選び、不正行為プルーフ 43などの追加的戦術を含んでいます。43

ネットワークが秘密を所有することは、『オーブス』（Orbs）プラットフォームが導入した暗号通貨

プロトコルです。これは分散的なネットワークの中に共有される秘密を安全に保持する能力を提供し

ます。コンセンサスノードのいずれも、この秘密についての直接の知識を持っていません。また、こ

の秘密をデータに署名する、暗号化する、解読するなどで安全なオペレーションを促進できるのは、

指定された大多数の協力による場合のみです。メカニズムはしきい値暗号化と呼ばれる暗号通貨プリ

ミティブに依存し、ヘリックスコンセンサスアルゴリズムの技術的なホワイトペーパーに詳細に記述

されています。この方法の利点は、他のノードが知らない自分の個人秘密を各々使用して個々のノー

ドによる署名のしきい値量に達した後で、結合した署名が生産されるということです。したがって、

弊社は、全ネットワークの有効な署名と見なすことができる、結合署名を作成しました。ネットワー

ク全体として個人および公開鍵が平行して存在する場合、多くの有用な安全なオペレーションの実装

が簡単になります。

ネットワーク所有の秘密は、特定のノードを信頼する必要のないネットワークで、安全な相互作用の

ための能力を提供できます。スマート契約計算を行ないたくても、十分なノードを実行することがで

きないクライアントを例に取ります。通路としてネットワーク・ノードのうちの 1 つにクエリを送り、

かつその応答を信頼するのではなく、ネットワーク秘密を使用し、多数のノードの結合したレスポン

スに署名することによって、クライアントは署名のチェックによる応答を確認することができます。

秘密を所有するネットワークでは、さらに興味深い能力として、ネットワーク・レベルで資産または

アカウントを保持しています。Ethereum のような異なるブロック・チェーンのアカウントをコント

ロールするプラットフォーム上でスマート契約を実行する要件を例に取ります。通常は、スマート契

約が秘密を保持することができないので、この要求は実装できません。しかしながら、ネットワーク

に所有された秘密を使用すると、秘密鍵は、コンセンサスの後にノードの集合体によって生成されま

す。この秘密鍵は個々のノードには知られておらず、外部 Ethereum ウォレットに安全にアクセスす

るために使用することができます。さらに、スマート契約はキー管理、DRM などのような重要なサ

ービスを提供するために使用されます。

43 https://gist.github.com/justusranvier/451616fa4697b5f25f60

38

『オーブス』（Orbs）アーキテクチャー 『オーブス』（Orbs）プラットフォームの詳細なアーキテクチャーは、一連の技術アーキテクチャホ

ワイトペーパーで概説されます。一般に、『オーブス』（Orbs）アーキテクチャーは多層(システム

で異なる機能を担うもの)から成ります。層とサービスは異なるマシンおよび規模で独立して作動で

きるように構築されています。設計の目標として、アーキテクチャーは、柔軟性、機能向上および相

互運用性を可能にするため、できるだけ層内でサービス、およびモジュールを分離するようにしてい

ます。

アーキテクチャーの重要なコンポーネントは仮想ブロック・チェーンのサポートであり、 コンセン

サス、状態および記憶層の多数のパラレルインスタンスが、共有される物理的なノード環境に関する

個別の専用ブロック・チェーンのイリュージョンを提供します。ブロック・チェーン・バーチャリゼ

ーションの概念は、次のセクションで詳しく議論されます。

インフラストラクチャー層およびサービス

クライアント SDK - ネットワークにエンドユーザを接続する、モバイルとウェブのアプリ用のクライ

アント側ライブラリ。SDK はリクエストに署名し暗号化し、信頼されたノードに依存せずに、応答を

確認することができます。

39

公開 API - クライアント(REST あるいは JSON-RPCのような)に公開ウェブ API をすべて開示するマイク

ロサービス。エンドポイントがエンドユーザ処理およびクエリをすべて処理します。

ゴシップ-マイクロサービスで、効率的、一対多向け、およびネットワーク中のノード間の 1 対 1 の

通信を提供します。『オーブス』（Orbs）プラットフォームの新しいコミュニケーション・スキーム

は、ヘリックスホワイトペーパーで詳細に議論されます。

暗号通貨サービス - 低レベルの暗号通貨ルーチンを提供するサービス、および署名、ハッシュおよび

暗号化のようなサービスを提供するライブラリとサービス。ネイティブとノンネイティブフォールバ

ックの両方を持っています。

安全なストレージ - 安全に秘密鍵のような秘密を保存するライブラリおよびサービス。HSM44 を可能

な場合使用し、専用ハードウェアおよび不正防止エンクロージャに依存しています

システムパラメーターおよび統制 - インフラストラクチャー配置パラメーターを保持し、更新とプロ

ビジョニングを処理します。

バーチャル・マシン(計算) - 仮想チェーンすべてで、処理およびスマート契約の執行を所有するマイ

クロサービスです。計算層は、非最終執行とクロスチェーンのデータの過渡的状態を保持します。

プロセッサー - 様々な言語(EVM、パイソン、Java、JavaScript など)のスマート契約の執行に必要な実

際のランタイム環境を提供するマイクロサービスのセットです。

ロウストレージ - ローカルマシンに生データを保存し検索する層です。

クロスチェーン・コネクター - Ethereum のような第三者ブロック・チェーンとのクロスチェーンの相

互運用性を供給するマイクロサービスのセットです。第三者のコンセンサス下でのアクセスを提供し

ます。

時計同期-異なるマシンとノードおよびサービスの間の時計を同期させるマイクロサービスです。絶

対時に一貫した評価基準系を提供します。グローバルな時計同期はヘリックスコンセンサスアルゴリ

ズムの要件ではありません。しかし、他のシステム・サービスはこの能力を鰹湯できる可能性があり

ます。

コンセンサス - 処理とその有効性の命令のノード中で達成する合意を担う仮想チェーンでインスタン

ス化されたマイクロサービス。コンセンサスアルゴリズムを実装します。次のサブ層から成っていま

す:注文、確認、取引、プール

ステートストレージ-コンセンサスの下にあるミュータブル・非ミュータブルの状態を保持する仮想

チェーンでインスタンス化されたマイクロサービス。ステートデータで効率的なキャッシング、シャ

ーディングおよび冗長性を管理します。バーチャル・マシンおよび公開 API によってアクセスします。

ブロックストレージ - すべての以前に閉じられたブロックのインクリメントの長期的なジャーナルを

保持する、仮想チェーンにつきインスタンス化されたマイクロサービス。ブロックのデータで、シャ

ーディングおよび冗長性を管理します。ステートを生成し確認するために使用されます。

44 https://en.wikipedia.org/wiki/Hardware_security_module

40

仮想チェーン・パラメーターおよび統制-仮想チェーンでインスタンス化され、また仮想チェーンの

特定の配置パラメーターを保持し、更新とプロビジョニングを処理します。

リソースプール対仮想チェーン

『オーブス』（Orbs）アーキテクチャーは、ネットワークにさまざまなタイプの資源を供給する 1 セ

ットのマイクロサービスで構成されます。各タイプのリソースは、ネットワークの実需によって別々

にスケールができます。公開 API のようなサービスは、仮想チェーンの数に基づいたノードにつきイ

ンスタンス化されるコンセンサスサービスと比較して、より多くのエンドユーザーが同時ネットワー

クに接続し、多数のインスタンス化を始めることにより積極的なスケール拡大が可能となります。

『オーブス』（Orbs）プラットフォームの上に作動するアプリケーションにはさまざまなリソースで

異なる必要条件があります。例えば、計算集約的なアプリケーションは大容量の分散化計算リソース

を要求し、データベース・アプリケーションは、大容量分散化ストレージを要求します。さらに、新

しいアプリケーションの導入およびそれらのニーズの発展とともにリソースの量が変化すると予想さ

れます。

41

これらは、効率的に各ノードで利用可能な資源およびマイクロサービスを利用するために、SLA 必要

条件に基づいてさまざまな仮想チェーンに割り付けられる、共有リソースプールと見なされます。一

部はの資源は仮想チェーン専用となり、一部はダイナミックに基づいたオンデマンドを割り付けられ

ます。資源プールに有効に基づいたアーキテクチャーは、異種混合ノードの能力変化を利用し、資源

能力に弾力性をもたらします。ノードはそれぞれ、ネットワークに提供したサービスの合計について

報酬が肢払われます。また、それがコミットメントにいたらなかった場合、ペナリティが課せられま

す。これは、ノード・オペレーターに求められるような資源を追加し、かつサービスの質を維持する

誘因を与えます。

42

コンセンサス

実用的な集中排除および信頼

コンセンサスは、ブロック・チェーン・インフラストラクチャーに必要な中核サブシステムのうちの

1 つです。また、コンセンサスモデルの選択は、最初の決定です。コンセンサスの問題は、先入観お

よび強い意見が乱立しています。プルーフ・オブ・ワーク(PoW)の証拠のキャンププルーフ・オブ・

ステート(PoS)の間では、多くの場合境界的な哲学についての議論があります。45 弊社のポジションは

常に、弊社の必要条件の注意深い分析に基づいています。

コンセンサスは、分散システム中の合意の問題を解決し、ここで、さまざまな合意間の選択によって、

さまざまな当事者にとって利益あるいは損失がもたらされます。集中システムでは、他の当事者はな

いため、合意の選択における矛盾はありません。議論の前に、弊社では、ネットワークの一部がそれ

ぞれ、実際にどの程度分散的か調べることが必要です。

ネットワーク組織図を見ていきましょう。弊社の最初のアンカーであるエンドユーザから始めます。

消費者(インスタント・メッセンジャーのようなアプリのユーザー)は、一般に Bitcoin の初期採用者と

異なり、集中化排除の利点に気づいていません。近い将来も、消費者の大部分は分散システムと集中

システムの間の差を理解しないでしょう。Bitcoin の背後にある、「信頼システムを使用しない」とい

う理想に反して、エンドユーザは製品のソース・コードで自前のコンパイルを行うことはなく、真正

コピーをダウンロードしたことを確かめるためにシグネチャを確認することもありません。消費者は

常に、ブランドを信用しています。

ブランドはほとんど常に集中組織であり 1 つのリーダーシップおよび 1 つの方針があります。消費者

は、通常 Apple Store やグーグル・アプリストアのように、消費者に連絡する、集中配信チャンネル、

および集中管理サーバー上でホストされたブランドのドメイン名を持つ集中ウェブサイトに依存しま

す。モバイルアプリウォレットに秘密のパスフレーズを入力する消費者を想像してみてください。消

費者は、このモバイルアプリのデベロッパーが秘密鍵を盗んだり乱用していない、外部で送信してい

ない、と信頼する必要があります。ブロック・チェーンと相互作用が行われる場合、これは、分散化

アプリでユーザーを代表して、究極的には接続するブランドによって作成され署名されたコードにな

ると考えられます。

45 https://download.wpsoftware.net/bitcoin/old-pos.pdf

43

この観察から、弊社がどのように開かれたコンセンサスモデルを評価するかが根本的に変わります:

それは、任意のユーザーの議決権が、コードを使用しているブランドに本質的に委任されることを意

味します。委任されたプルーフ・オブ・ステークののようなモデルでさえ、委任選挙での議決権は、

ブランドに暗黙に委任されます。

力の健全な分配 分散ネットワーク中の権力について議論する前に、弊社はこの力が有用なことを明らかにする必要が

あります。ほとんどの分散化ネットワークでは、権力は 2 つのタイプの決定に使用されます:処理の

リアルタイム確認、およびネットワーク自体(プロトコル・アップグレードおよびパラメーター変更、

ブロック・チェーンなどへのフォークでのコンセンサス)の統制です。

リアルタイム確認権 基本的ルールがネットワークのオペレーションに自明であるため、プロトコルが十分に定義されてい

る場合、リアル・タイム確認中の政治権力の影響は限定的です。例えば、立証者が強力であっても、

分散的な元帳によって支払人によって署名されない処理を承認することはできません。これはプロト

コルの規則を破るため、申し立てによる処理は、ネットワークによって無視される、あるいは、コン

センサスが壊れ、ネットワークは停止するでしょう。これは力の平等の分配と、攻撃を行なうことを

より難しくする、より強健でより持続可能なプラットフォームに通じます。

プロトコルを壊さない市場操作は、プロトコルで検出できない妨害に制限されています;ブロック、

利己的なマイニングなどの内の処理の順序を操作して、例えば意図的に処理を広めないことなどです。

46 ある程度まで、プロトコルがそのような市場操作を適用する検証者の能力を制限するよう設計され

ている場合、このリアルタイム確認の乱用をさらに制限することができます。

統制決定権 ネットワーク統制問題でコンセンサスするための効率的なメカニズムは長期的な関連性にとって重要

です。暗号、分布システム、ネットワークおよびソフトウェア・インフラストラクチャー中の最新テ

クノロジーに依存する産業として、弊社は、ブロック・チェーン・プラットフォームの能力をさらに

高めて拡張する安定したイノベーションの潮流を期待できます。更に、ブロック・チェーン・ソリュ

ーションが主流産業に導入されるにつれ新しい用途および新しいコンテキストがこれらのプラットフ

ォームによって提供されることが予想されます。順応性はどれにとっても重要であり、よいブロッ

ク・チェーン・プラットフォームおよびネットワーク統制の力学への障害となるべきではありません。

46 https://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf

44

ほとんどの技術的な進歩は容易にコンセンサスされますが、利益が整合していない場合、矛盾は発生

します。健全な分配パターンを分析するために、弊社は、どの利益が働いているか、また、アクター

が誰かを初めに理解しなければなりません。

ブロック・チェーン統制に関する俯瞰から、弊社は、ステークホルダーの 3 つの原型を見ることがで

きます:

● エンドユーザ

● 分散化アプリ・デベロッパーは、エンドユーザの要求に応じています。

● ネットワークインフラ・オペレーター(例えばマイナー)

消費者アプリケーションに役立つことを目標とするプラットフォームのデザイナーとして、弊社のア

プローチはユーザーのユーティリティを最大限にしようと努めることです。

インフラストラクチャー・オペレーター(Bitcoin のマイナーのような)の利益が、通常エンドユーザの

利益に反して調整されていることを理解することは簡単です。この結果、至急に必要な場合であって

も、ネットワークへの変更は遅延します。このような矛盾の損害の顕著な例は、プロトコル中の技術

的な問題を解決することを目指しつつ、マイナーにとっては不利益が予想された SegWit (BIP14147) へ

の切り替えについての Bitcoin コミュニティーでの 20 か月の討論です。ユーザーおよびアプリ・デベ

ロッパーに、大規模な不安定が数か月にわたってもたらされ、2017 年 8 月にネットワークが分岐し

ました。

デベロッパーのインフラストラクチャー選択に対する関心は通常はエンドユーザと合致します。ただ

し、競争を避けるために現在の制度による変更案が採用される場合を除きます。アプリ・ベンダーで

も、より新しく実績のある技術の選択に関して分裂があります。成熟した確立されたアプリのベンダ

ーは、現在の制度を分裂させるよりも、危険を回避し、かつ技術が熟すのを待ち、新興アプリは素晴

らしい可能性がある最先端技術の採用に積極的に価値を見出す傾向があります。プラットフォーム・

バーチャリゼーションはアプリケーションがそれぞれそれ自身のインフラストラクチャーの多くの様

相を他から独立して管理することが可能になるため、これらの矛盾の多くを緩和する際に大きな可能

性を持っています。

エンドユーザに関しては、弊社は決定の実際的な含意に関する限り、投票がユーティリティに整合す

ると考えています。しかしながら、統制決定にエンドユーザを巻き込むことは分散制において非常に

困難です:ユーザー同一性は、現実世界の同一性とは通常接続されません。また、デジタル同一性は

容易に偽造できます。この問題は、数人の裕福なユーザーの手に力が集中する危険を冒して、システ

ムの通貨中のそれらのステークを備えたユーザー投票に重みを加えることにより通常緩和されます。

47 https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

45

プルーフ・オブ・ワーク ほとんどの人々が正直ならば、公開元帳の完全上の多数決は分散化される真直ぐなコンセンサスで、

許可が必要なく開かれています。しかし、新しい同一性を生成するコストは無視できるため、デジタ

ル同一性に依存する場合、大多数は概念として成立しませんす。(Sybil Attack48).この問題の洗練され

た解決策は、199249 の Dwork および Naor(投票はその中で暗号通貨難問の解決についての支出コンピ

ューター資源およびエネルギーに従う)によって提案された、PoW です。PoW は、今日、許可がない

分配元帳の中で広く使用されます。

一般に、PoW 元帳は、コンセンサスに時間をかけて到達します:PoW 難問を最初に解決する場合、誰

でも、1 セットの処理(通常「ブロック」)の公開立証者となりえます;それらの努力は暗号通貨報酬に

よって償われます。将来のブロックは、弊社のブロックをそれらの前任者を参照し、ブロックの有効

性についてのコンセンサスは徐々に構築されます。犯人は、彼の(無効)ブロックが将来のブロックに

よって参照されなければ PoW の上の彼の消費が償われないので、公に無効のブロックを有効にしよ

うとすることができません。

PoW 元帳は分散的で、許可がなく、開かれたコンセンサスのユートピアの理想を達成しますが、アプ

リケーションはユートピアを作れません。PoW が十分に安全なために、難問を解決するコストは、原

資産の価値に比例しなければなりません;このグローバルなインパクトは大量市場の元帳上では非常

に大きな驚異です。2018 年 1 月時点で説明すると、Bitcoin 採掘は世界電気消費のほぼ 1/5000 を占め

ると推測されます。50 暗号通貨が大衆市場で著しく価値と売買数量が成長するとともに、予定され

ているオペレーションに関連した発行量が莫大となり、弊社では PoW 元帳を支援できなくなると考

えています。当然、これらのコストは料金インフレとしてインフラストラクチャーのユーザーに課さ

れます;PoW ネットワークを使用するコストは、代替のシステムのよりも高価です。消費者アプリに

必要な大規模に到達するために、インフラ費用を低下させることも『オーブス』（Orbs）プラットフ

ォームの中核的な要件です。

近いうちに、PoW は、大量市場採用でいくつかの即時・実際的な障害となるでしょう。その 1 つは

ネットワークの統制の問題です。分散的な移動を管理する固有の複雑さに加えて、PoW の増殖の弊害

は、マイニング、ユーザーあるいはアプリ・ベンダー(上に議論されたとおり)と利益が整合しないシ

ステムで、もう一人の強力で、極度に多額の投資がなされたステークホルダーが加わり、専門のビジ

ネスになってしまうことです。消費者アプリのデベロッパーは、ネットワークへの関与がその目的よ

り優先されるため、『オーブス』（Orbs）プラットフォームで最適化された政治団体ですが、Kik の

ような会社には競争率の高い PoW マイナーになることは期待されていません。

大量市場のアプリケーションの中で PoW を使用するうえでのもう一つの大きな障害は最終的なコン

センサスに関連した固有のレイテンシーです。ブロックの引受けは深さまたはそのブロックを参照す

る他のブロックの重量で決定されます。この重量はゆっくり蓄積されます。

48 https://www.microsoft.com/en-us/research/wp-content/uploads/2002/01/IPTPS2002.pdf 49 http://www.wisdom.weizmann.ac.il/~naor/PAPERS/pvp.ps 50 https://digiconomist.net/bitcoin-energy-consumption

46

ブロックが速く作成されれば、矛盾の可能性が必然的に高まり、ブロック・チェーン・システムでチ

ェーンへの分岐となるためです。より新しいプロトコルでは、ブロックの構成の有効な状態としてフ

ォークを包含するデータ構造の使用により、このレイテンシーを著しく縮小することができます。従

来のブロック・チェーンに代わるブロック-DAG(有向非巡回グラフ)を実装する SPECTRE protocol51 のデ

ザインおよび確認を含め、Sompolinsky、Lewenberg および Zohar によってこの分野で重要な仕事が行

われました。このような仕事は、PoW を進める中での多くの展望が現在の制約を超えて支払い元帳を

分散化し、その使用によって、システム状態を計算では非常に高度に複雑さが要するため、今のとこ

ろスマート契約のような、より多くの抽象システムに対するよいソリューションを提供していないこ

とを示します。

『オーブス』（Orbs）研究グループは、オリジナルの SPECTRE 研究に基づいた著しい投資を行い、プ

ロトコルの実際的な生産実装を開発する試みについて、ゾハール教授との議論を行ってきました。結

局、DAG に基づいたシステムでのスマート契約の効率的な執行に必要な最終段階に到達し、一般に

PoW の固有の制限際の困難さにより、弊社は、『オーブス』（Orbs）プラットフォームコンセンサス

戦略用の基礎として SPECTRE 研究から手を引くことに決めました。この研究は PHANTOM52 のような

進歩で成熟することが期待され、弊社はこの有望な概念を支持し、引き続き注意していきます。52

プルーフ・オブ・ステーク シビル攻撃への代替的対策として、デジタル資産、通常暗号通貨の所有権に投票を通常結び付けるこ

とがあります。ここにおいては、PoS がコストとエネルギー浪費なしで、PoW に洗練された選択肢を

供給します。しかし、PoS スキームが一般大衆向きの資源を危うくすることを立証者に要求しないと

いう事実から、全く新しい課題セットへの対応が要求されます。

主な課題の一つは、確認プロセスへの参加がプラットフォームのほとんどのユーザーに直接関係しな

いということです。ブロック・チェーンを使用した価値の移転、あるいはアプリケーションのユーザ

ーがスマート契約を利用する場合、通常ユーザーは分散的な元帳の力学に気づかず、またプロセスに

参加するモティベーションをほとんど持ちません。これは、処理(検証者が絶えずオンラインで、か

つノンストップでネットワークと処理の資源を割り当てる処理することが要求される)のリアルタイ

ム確認には特に問題です。

いくつかのプラットフォームは、PoW システムにおいてよく見られる、専門マイナーのエコシステ

ムを模倣しようとしています。これは、ステークホルダーが専門家に議決権を任せ、代表団のような

自称立証者が、正直であることの証明としてトークンを消滅させるまたは焼く必要がある、純粋に許

可のないモデルから半許可モデルまで、種々様々なモデルを含んでいます。モデルは非常に異なりま

すが、すべては同じ基本の課題に直面します。検証者が正直に作用する誘因の不足、および不正直な

大多数による危険の増加です。

51 https://eprint.iacr.org/2016/1159.pdf 52 https://eprint.iacr.org/2018/104.pdf

47

PoS を直接に認証する全員参加システムの作成の試みがあります。顕著な 1 つの例は、ある種類の陪

審員業務として所定のモーメントでも確認に参加することをユーザーの小標本のみに要求し、このよ

うにユーザーステークによって非常に巧妙に任意のソーティションを秤る、Chen および Micali によ

る AlgoRand です。53 弊社は、このモデルに対する大きな期待を持っています。しかし、それらの実

装への著しい実際的な障害が主流アプリケーションにあることに注目することは重要です。大量市場

のユーザーは、処理確認のテクニカル・プロセスにおいて活動的であると予想できません。このよう

な確認に使用しているソフトウェアを確認するためにアプリストアからアプリをダウンロードするも

みです。実際上、これは、損失にもかかわらず委任された PoS システムと同じようにシステムを整合

させ、アプリ・デベロッパーにユーザーの議決権に対する完全なコントロールを与えます。弊社の期

待する暗号の証明のより新しい進歩および他のイノベーションは、これらのシステムを主流アプリケ

ーションにとって実用的なコード化を実現することができます。

許可モデル ブロック・チェーン・コミュニティーの理想主義の性質は、分散化され、許可がなく、開かれた、透

明なコンセンサス設計の方を伝統的に向いてきました。許可がないことの上の制約が緩められたこと

によって、シビル攻撃はもはや関係はありません。また、より速く、より効率的なコンセンサスアル

ゴリズムを使用することができます。更に、許可を確認した検証者の同一性はすべてに知られていま

す。匿名のベールの後ろに隠れることなく、検証者はプロトコルの規則に従うコミットメントを公開

するように要求され、この場合、技術的な手段を使用して執行できない規則も、商業分野の訴訟にお

いては可能となることもあります。

分散化コンテキスト中の公開の許可ネットワークを設定には 2 つの形式があります。最初は、コンソ

ーシアムで、中心体がこのようにして確認許可を分配するネットワークを管理します。リアルタイム

確認許可は、ネットワークの操作で統治機関が責任を持つかどうかという問題は残りますが、分散化

と考えられます。第 2 は、フェデレーションで、統制が分散化され許可はネットワークに共通ではあ

りませんが、各ユーザーあるいはアプリ・デベロッパーによって指定されます。許可された検証者の

同じセットを共有しない場合、ユーザーが異なれば元帳の異なるプロジェクションが表示されます。

いくつかのアーキテクチャーでは、これは大規模な複雑さをコンセンサスプロトコルおよび元帳構造

に加えます。しかしながら、ブロック・チェーン・バーチャリゼーションを提供するプラットフォー

ムにおいては非常に単純です。

公開ブロック・チェーンのフェデレーションモデルは、Ripple54や Stellar55のようなプロジェクト産業

において確立されています。また着実に進歩しています。これらのプロジェクトは高い程度の集中排

除、開放および透明制を維持します。誰でもノードをセット・アップすることができ、処理保全用の

歴史を確認することができるます。モデルの許可段階は、チェーン上に書かれている新しい処理の確

認の中で作用し始めます。すべてのノードは、その処理の確認の中で期待するノードのリストを指定

し、それにより、異なるコンセンサス定足数を備えたグループのコンビネーションを作成することが

できます。

53 https://arxiv.org/pdf/1607.01341.pdf 54 https://ripple.com/ 55 https://www.stellar.org/

48

階層状 アプローチ 弊社は、どのように大規模な消費者アプリの使用の場合に最も適したコンセンサス戦略を選ばなけれ

ばならないでしょうか。最初の質問は、万一、政治権力がネットワークの中で分配されればどのよう

に対処するかと言うことです。消費者アプリは既に主なステークホルダーです。ネットワークに取引

とユーザー・ベースをもたらすからです。弊社は、消費者が、分散化アプリの中で処理をする消費者

ブランドを信頼すると革新しています。許可なし検証者としてステークホルダーを加えることは消費

者のために有益でしょうか。

弊社は、今日、大衆市場消費者アプリケーションに、性能および消費者の利益を備えた整列でフェデ

レーションしたブロック・チェーンが最良のソリューションを提供すると考えています。弊社は、消

費者がすぐに直接いつでもブロック・チェーンの統制に関係するとは予想していません;消費者の長

期的な関心と提携したい実際的なシステムは、アプリ・デベロッパーあるいは鉱夫のような興味を持

った 3 番目のパーティーに力を与えることができます。アプリ・デベロッパーはこの力に任せて、既

にアプリ市場の信頼され統制的なステークホルダーであり、消費者のための利益を最大限にします。

デベロッパー間の力の分配は各々によって別々に保持された個々の力を制限するべきです。これらの

必要条件はすべて、フェデレーションしたコンセンサスモデルによって最もよく満たされます。

フェデレーションモデルは十分に開かれていますか。弊社は、いくつかの方法でこの質問に答えるこ

とができます。実際的な展望から、答えは明らかに「イエス」です。それは、プラットフォームの成

功において明瞭な利害関係を持つパーティーに対する信用をもたらします。また、これは、ほとんど

のシナリオ(ブロッキングの競争は例外となります)を満たします。戦略の展望から、これらのモデル

が特に非常に強健であると考えられる PoW モデルと比較して、長期安定しているかどうかは不明瞭

です。法律や規定面から、現在統制はありません。 弊社の分析 (分散化元帳セキュリティを参照)、お

よび今日の主要なブロック・チェーン・プラットフォーム中のフェデレーションモデルの事実上の主

導権は、これらのモデルが十分に分散化されると見なされるという示唆を提供します。

市場が成熟するとともに、新しい分析あるいは新しい規定アプローチはフェデレーション統制に規模

もたらすでしょう。このような状況では、弊社は、委任された PoS(EOS56 または TON57 の管理モデル

に原則としては似ている)のような許可がないモデルにフェデレーション自体(フェデレーション会員

受け入れまたは拒絶 フェデレーションメンバーの許可への変更; フェデレーション規則への変更)の統

制が移行するだろうと予想します。この構造は、純粋なフェデレーションしたモデルのほとんどの利

点を保っていますが、フェデレーションしたモデルの単純性および洗練を欠くので、弊社の選択肢と

しては二番手です。

56 https://eos.io/ 57 https://techcrunch.com/2018/01/08/telegram-open-network/

49

ヘリックス コンセンサスアルゴリズム ブロック・チェーン技術が大量市場のアプリに達するとともに、弊社は分散化コンセンサスの古典的

形式がもはや不適切であることを理解します。PoW コンセンサスを大量市場での取引高は大きいた

め、費用が高価で処理が遅すぎ、あまりにも多くの環境損害を引き起すでしょう。大量市場のユーザ

ーではなく、アプリがそれ自体でそのようなプラットフォームに対するユーザーの議決権形 PoS 選択

をコントロールしているという事実は危険すぎるものです。さらに、典型的なパターンでは、アプリ

の人気は極端に不平等です:どの時点でも、またほとんど任意のセグメントで、一握りのポピュラー

なアプリが、それほどポピュラーでないアプリの無限のロングテールを圧倒しています。理想的な分

配は、力の著しい不平等を回避するものとなることが必要です。弊社は任意の 1 つのステークホルダ

ーの力に上限を保証するシステムを作成することを目指しています。

『オーブス』（Orbs）プラットフォームの誕生で、弊社はヘリックス(大量市場アプリの理想に適合

した分散的で、開かれた、透明なコンセンサスアルゴリズム)を導入するでしょう。弊社の基本の仮

定は、アプリ・ベンダーがアプリに提供するプラットフォームでほとんどの力を有し、互いおよびそ

れらのユーザーの利益とベンダーの利益が整合することを保証するためにゼロからコンセンサスプロ

トコルを設計しなければならないということです。ネットワーク統制については、これは各アプリの

統制が他のアプリとは離れていることを可能にするため、プロトコルがチェーン・バーチャリゼーシ

ョンで生得的に作動しなければならないことを意味します。これを越えて、議決権は、フェデレーシ

ョンのメンバーである既知の立証者間で分配され、それにより、一人の投票者によって保持される力

を制限します。リアルタイム確認については、弊社は、検証者の選択や処理の不正操作が直ちに、最

終化され、迅速に、非実用的とされるようなプロトコルを要求します。

アルゴリズムの全詳細は個別のピア・レビューが行われた技術的なホワイトペーパーで公開されます。

アルゴリズムの設計の主要な必要条件は、次のものを含んでいます:

コンセンサス結果の最終段階 ヘリックスコンセンサスアルゴリズムは即時に取引の最終化を提供します。ビジネス・アプリケーシ

ョンでは、取引最終化は非常に望ましい特性です-一旦処理が実行されれば、意図したサービスを直

ちにステークホルダーに許可を提供するためです。Bitcoin のようなシステムでの処理の蓋然的最終化

と異なり、ステークホルダーは、多数のブロックが処理がくつがえされないという十分な信頼を獲得

するのを待つことは要求されません。

最終化特性は、さらにステートデータベースの効率的な使用を可能にします。ステートデータベース

は各ブロックの終結でコンセンサスの下で更新することができます。また、その確実性は容易にその

ルートハッシュによって確認できます。常にコンセンサスの下にあるステートデータベースの維持大

きなトランザクション・ジャーナルへの高帯域アクセスの必要および追加のチェックポイント・メカ

ニズムの必要をなくします。

50

不透明な処理の注文 コンセンサスアルゴリズムの重要な特性は、公平さですが、この部分には正当な関心が集まっていま

せん。新しい処理がブロックに挿入される順序を公平に決定するために、多くのアルゴリズムが規則

あるいは公平性を強化する方法を定義しておらず、すべてフルノードまたはマイナーに依存していま

す。更に、いくつかのネットワークはマイナーに、ブロックにどの処理を含むか決める自由を提供し

ます。高い料金の処理に対する指向性および検閲のためです。

ヘリックスコンセンサスアルゴリズムは、不透明な処理の公平な取引注文および検閲への抵抗性を保

証します。処理は、送信の前にエンドユーザによって暗号化され、取引のコンセンサスに到達するま

では解読されません。このメカニズムは、クライアントがノードを信頼する、あるいはそれらに直接

の誘因を供給する必要のない、公平なサービスを受けることを保証します。

確認からの注文の分離 未決の暗号化された処理は最初に注文され、一度だけ、注文についてのコンセンサスは達成され、そ

れらの確認についてのコンセンサスを達成して、実行され、処理が解読されます。確認からの注文の

分離はより高いスケーラビリティおよびより高いトランザクション速度を可能にします。さらに、シ

ステムが受託者サイズのような各段階の特性あるいは暗号化されたデータの使用を最適化することを

可能にします。

受託者による速いコンセンサス コンセンサスプロトコル中のコミュニケーションの量は、コンセンサスに参加するノードの数に大き

く依存します。一方では、弊社は、集中排除とセキュリティを増加させるためにノードの数を増加さ

せることを望みます。他方では、弊社は、確認時間を縮小し、かつ処理能力を増加させるためにノー

ド間コミュニケーションの量をコントロールしたいと考えています。各ブロックの生成で活発な役割

をとる、任意に選ばれた予測不能の受託者の使用は、コミュニケーション・オーバーヘッド上で上界

を維持しつつ、システムがノードの全体の数を増加させることを可能にします。

無作為化ソートによる効率的なリーダー選挙

PBFT58 のような多くのビザンチン式フォルトトレランス・アルゴリズムが予備選挙あるいはリーダ

ー・ノードのローテーションに基づきます。有効性を保証するために、これらのアルゴリズムは、不

完全なリーダーを識別し、かつそのデポジションの代理をメカニズムに要求します。これらのメカニ

ズムは典型的に複雑で、タイムアウトに依存し、新たなリーダー選挙がある時は結果的に必要な移行

への遅延をもたらします。移行オーバーヘッドはインバランスおよび次善的な公平性のみとなり、頻

繁なリーダー・ローテーションを妨げます。

58 http://pmg.csail.mit.edu/papers/osdi99.pdf

51

各コンセンサスラウンドで任意に異なるリーダーを効率的に選ぶために、ヘリックスは受託者および

リーダー選挙でソーティションを使用します。各ブロックについては、コンセンサスノードは、以前

に規律正しいブロックの解読されたデータのハッシュに基づいて、ソートされ、ランダムおよび一貫

した選択を提供します。前のブロックがコンセンサスに達した後でのみ利用可能な解読の使用は、リ

ーダーが次のブロックコミッティをコントロールするためにブロック・データの不正操作しないよう

妨げます。コミッティのソートされたリストの可用性は効率的なフォールトトレラントの通信プロト

コルを可能にします。これらは、ネットワーク取引および最大の伝搬時間、より良い取引速度につな

がり、スケーラビリティの量を減らすことができます。

ノード・レピュテーション・システム コンセンサスアルゴリズムはビザンチン式環境の中で作動します。ここでノードのうちのいくつかは不

完全あるいは悪意を持って作用するおそれがあります。さらに、すべてのコンセンサスノードは均質と

は限りません。また、それらの性能や反応も均質後は限りません。迅速に不完全なノードを識別し、資

源の平衡を保ち、プロトコルに従って作動するノードを奨励するために、ヘリックス・アルゴリズムで

は、すべてのノードがピアによって得点される、分散的なレピュテーション・システムを維持していま

す。ノード評判は、受託者に含まれている見込みのようなノードの政治権力に影響します。評判は、さ

らにオペレーターへの料金の支払いのような経済誘因化を支援します。例えば、プロトコルに作用が芳

しくないノードは、これに従って評判スコアが縮小され、ノードは報酬を受け取りません。

52

サービスレベル契約(SLA)

業界標準

サービスレベル契約(SLA)は、サービス・プロバイダーとクライアントの間の公式コミットメントにつ

いて記述する契約です。またコンセンサスしたサービス水準が達成されなかった場合のサービスの予

想水準と、それを測定するために使用される指標およびペナリティについても記述します。SLA は、

組織間の、あるいは組織内で提供されるサービスに広く使用されます。これはテレコミュニケーショ

ン、インターネット・プロバイダー、オンライン・サービス、そしてさらに-サービス(IaaS)としての

クラウドインフラストラクチャー、AWSのようなプロバイダーの業界基準です。

個別の SLA は、提供されるサービスの各々で典型的に定義されます。例えば、IaaS プラットフォーム

では、中核サービス(計算、ストレージ、ネットワーキング)が各々SLA を持ちます。ユーザーは、異

なる SLA の間の選択権を持つこともでき、顧客がそれぞれのニーズに応じて計画することも可能とな

ります。例えば、オンライン消費者アプリケーションでは、可用性および一貫した性能に注目するで

しょう。また、オフライン・アプリケーションは、一貫性より平均性能を優先するでしょう。

SLA は顧客とサービス・プロバイダーの両方を保護します。これは設定の見込みを明示的に設定する

ことによって誤解と誤解を防ぎます。さらに、SLA は、顧客が受けるサービスのレベルを進歩と予算

に従って予測できるようにします。サービス・プロバイダーについては、SLA は、必要な資源および

計画を事前に評価する手段を提供します。

SLA が集中 IaaS プラットフォーム上で作動するアプリケーションでは普及していますが、それらは分

散化要素を欠いています。実行とコストを予測する無力は、消費者ブランドが分散化ビジネスに移行

するうえで課題となります。

CryptoKitties - 事例 研究

CryptoKitties は、プレーヤーが仮想猫を引き取り、増やし、交換することを可能にする Ethereum プラ

ットフォームで作動するソーシャルゲームです。Kitties のキャラクターはそれ自体で魅力的であり、

ゲームの人気の急増およびそれが生成した取引量は、Ethereum ネットワークをそのキャパシティー

を超過する、大幅な混雑をもたらしました。

53

CryptoKitties は 2017 年１１月に公開され、これをきっかけに、Ethereum ネットワークへのゲーム関

連の処理が行われるようになりました。公開後の時期で、ゲームに関連した処理は Ethereum の総取

引量のほぼ 20%を占めていました。その結果、未処理量が 6倍に上昇しました。59 また、取引手数料

も従って上昇しました。

Ethereum で結果として生じた混雑は、暗号通貨コミュニティーおよびメディアから注意を集めまし

た。この現象をとりあげた記事の多くは、ブロック・チェーン技術の一般的なスケーラビリティに関

する問題を提起しました。60.高度にスケーラブルなソリューションが望まれるということに議論はあ

りませんが、規模のみに注目することは大きな問題を見逃すことになります。

ブロック・チェーン・インフラストラクチャー上で作動する、分散化アプリケーションの性能と料金

の評価はポピュラーなゲームの出現に基づかせることはできません。CryptoKitties のような人気アプ

リを潜在的な問題として見なすべきではありません;人気アプリケーションは、ブロック・チェーン

技術の可能性、および日常生活への影響をわかりやすく示しています。

Kik Interactive の Kin は、CryptoKitties の熱狂が頂点二達したなかで、KinIPLv2 のプロダクションを開始

しました。その結果、CryptoKitties による Ethereum の影響の著しい弊害に苦しみました。61この時点

で主な結論は、SLA がどうしても必要であるということでした。

59 https://www.theatlas.com/charts/rkt8jKMZz 60 http://www.bbc.com/news/technology-42237162 61 https://medium.com/kinfoundation/insights-from-kin-initial-product-launch-441c458a4ece#479b

CryptoKitties

54

消費者アプリケーションは、予測可能な実行、トランザクション速度、確認時間および料金コスト環

境を要求します。取引の 20%の急増は、集中化とは無関係にどんなインフラストラクチャーによるも

のでも処理が困難です。しかしながら、アプリケーション中で SLA 規則および隔離を適用するインフ

ラストラクチャー・ソリューションでは、既存のアプリケーションに及ぼす影響が小さく、コンセン

サスを行った境界内で、このインパクトを吸収できる可能性があります。例えば、隔離は、

CryptoKitties 取引の急増が他のアプリケーションに混雑を引き起こさないよう保証します。

分散的なコンテキスト中の SLA 開かれた分散化プラットフォームの SLA 提供における 1 つの課題は、プラットフォーム・ユーザーが

インフラストラクチャー供給者との直接の契約を行っておらず、こうした契約を結ぶ相手方がありま

せん。

『オーブス』（Orbs）プラットフォーム上の基本サービスは共有資源によって提供されますが、共有

資源に過負荷がかけられれば、サービス水準は保証することができません。プラットフォームはプラ

ットフォームを使用して、アプリケーション開発者が専用資源を持てるようにすることで、サービス

水準メカニズムが開始されます。

デフォルトで、『オーブス』（Orbs）プラットフォームは、スマート契約コードによりサービスの最

小の質を維持する専用資源を、興味を持ったユーザーに提供することができます。提供したサービス

が、要求されたサービス水準を下回った場合、ユーザーは、それらから期待された処理実行を寄与し

なかったネットワーク・ノードを犠牲にして、自動的に補償されます。スマート契約に基づいたスキ

ームは、ほとんどの消費者アプリケーションにとって当事者間の直接の法的に拘束力のある契約の必

要を緩和するに十分であることが必要です。

プラットフォームの一部ユーザーは、法的に拘束力のある合意を要求できます。例えば自分のユーザ

ーに SLA を供給する必要のあるアプリケーションなどです。こうした要求が発生した場合、『オーブ

ス』（Orbs）プラットフォームは、アプリケーション開発者がネットワーク・ノードのオペレーター

から専用資源を直接購入するメカニズムを提供できるでしょう。アプリケーションのオペレーション

に必要な処理能力を支援するために十分な資源を得ることによって、デベロッパーは利用者規定に支

持され、ユーザーのために最小のサービス水準を保証することができます。これは、アプリ・デベロ

ッパーおよびノード・オペレーターが直接取り引きすることができる市場で導くことができます。こ

のような外部協定は、署名の側の処理についての使用の合意がかつては認可されたことを示すプロト

コルで促進されます。

もちろん、専用資源の獲得は、集中排除ではタイミング良く起こりません。獲得されたキャパシティ

ーは、購入者に直接提供されず、むしろ共有資源プールに加えられるでしょう。したがって、実際上、

資源を得ることは、共有されるプールと購入者の間の SLA で、ノード・オペレーターと共有されるプ

ールに後部の間の SLA を確立します。システムが負荷下にある場合、ノード・オペレーターが必要な

キャパシティーを提供できなかった場合、補償額はそれらの料金から自動的に控除されます。これと

は関係なく、まだ共有されるプール上の他の供給者が空のリソースを持っていることはありえます。

また、購入者とのサービスの質は維持されます。

55

予測可能な料金モデル

CryptoKitties 事例研究で議論されるように、Ethereum の上に Kik Interactive による Kin の着手の主な課

題の 1 つは、料金の予測不可能性です。Kin は、最小の摩擦でトークンを採用し、エンドユーザを奨

励するために Kik パワーユーザのインフラ費用をまかなうためのものです。主な問題は、結局のとこ

ろ、料金が高いことではなく、前もって予算を計画し立てるのが不可能だったということでした。

予算設定は消費者アプリケーションの成功には重大です:製品開発は高価で、起業家または会社はア

プリが成功すれば、それらは、投資に対する収益を得るか前もって知りたいと思っています。これを

知るために、運転費用の評価は重要です。

Kin 着手の最初の数か月に、Ethereum 料金は大きく変わりました。最初に、揮発性で悪名高いエーテ

ルの USD 価格は着手期間に 200%増加しました。料金がエーテル支払いであったため、この為替レー

ト変動はコストの増加に直接はねかえりました。次に、より高い料金を提示する処理が最初に処理さ

れた場合、Ethereum 料金は市場のさまざまな力によって決定されます。Kin 着手中に、Ethereum ネッ

トワークは、ネットワークを介したユーザーからの需要が増加しました。その処理を行うために、

Kik アプリは著しく料金を引き上げなければなりませんでした。

『オーブス』（Orbs）プラットフォームは、1 つの価格、および予測可能で、前もって計算すること

ができる料金モデルを提供できるように設計されています。弊社は、そのような確実性がプラットフ

ォームからの基本の要求であると考えています。AWS のような集中インフラストラクチャー・ソリ

ューションからの業界基準は正確な値つけ計算を提供することです。62 オン・デマンドのサービスお

よび応募の価格は ORBSトークンにリストされます。

サービスが ORBS にリストされるという事実(変動為替相場のトークン)は、サービス売り手およびバ

イヤーの両方に危険を引き起こします。為替レート変動の場合には、ORBS トークンが『オーブス』

（Orbs）プラットフォーム・ユーザーに有効にインフラ費用を吸収させ、料金を増加させるか、ある

いは有効にするノードのオペレーションを恐らく非経済的にして、価値を減少させます。さらに、オ

ペレーションコストは、根本的な IT インフラストラクチャー(ストレージ、処理、ネットワーク・ア

クセスなど)の価格変動にはねかえりますが、これらの価格は徐々に下がる傾向がありました。為替

レート変動に関しては、弊社ではそのペースが遅いことを期待します。経済モデルは、暗号通貨の中

の経済活動の高い割合から、為替レートは低減すると予言します。63 これは、着手パートナーに期待

された活動の量から、ORBSトークンにもあてはまると期待されます。

62 https://calculator.s3.amazonaws.com/index.html 63 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2842557

56

潜在的な価格変動を提供し、かつユーザーに用役原価の安定を提供するために、オンデマンドのサー

ビス価格は IT 用役原価の変化にあわせて定期的に標準化されるでしょう。これは、ストレージのイ

ンデックスにオン・デマンドの料金表を確定することにより行われます。また AWS のような主な第

三者クラウドサービス・プロバイダーによって公表されているように、単価を計算します。今後、こ

れらが自由市場需給によって決定されるため、クラウドサービス・インデックスを専用キャパシティ

ー価格のインデックスで置換することが可能になるかもしれません。このようなソリューションは事

実上ノード・オペレーターのコストに直接つながりを持つため、時間とともに、クラウドサービス・

インデックスよりも持続可能となるでしょう。しかし、実装では、専用キャパシティー用の市場がど

のように作用するかの点から、十分な経験が要求されます。

専用資源、予約資源およびオン・デマンド資源 動的な資源管理中の問題のうちの 1 つは、資源を共有する能力とそれらの可用性を保証する能力の間

の固有のトレード・オフです。一般に、弊社は資源配分の 3つのメイン・スキームを区別します:

専用資源 - 物理資源は最大の隔離、高い予見性および可視性を提供し、アプリケーション専用です。

専用資源は常に顧客に利用可能なことが保証されます。これらの資源の料金が必要であり、このスキ

ームは、未使用の場合は、3つの中で最も高価な配分となります。

予約資源 - リソースは事前に配分供給されます。予約資源は、いくつかの制限下で保証されるか、あ

るいはオン・デマンドの資源に関して優先的に行われます。予約の資源が前もって供給され、その資

源が、サービス・プロバイダーがよりよく計画することを可能にし、オン・デマンドの資源に関する

大幅な割引が典型的に提供されています。

オンデマンドの資源-資源はアプリケーション間で共有され至急度と可用度に応じ割り当てられます。

支払いは、通常実際の使用に基づきます。オンデマンドの資源は低コスト・アプリケーションあるい

は予測不能の業務量のアプリケーションに推薦されます。

最適化されたアプリケーション用の共通の戦略は資源のミックスを割り付けることです。例えば、ア

プリケーションは、基本操作、典型的な仕事量に見合う予約資源およびピーク使用に必要なオンデマ

ンドの資源、最小の性能を保証するために専用資源を割り当てるでしょう。

仮想チェーンおよびブロック・チェーン・バーチャリゼーション 『オーブス』（Orbs）プラットフォームで実装された、ブロック・チェーン・バーチャリゼーション

は、共有される物理的なノード・インフラストラクチャーで作動する専用ブロック・チェーンのイリ

ュージョンを提供し、したがって、同じセキュリティおよび集中排除が可能な、共有される環境によ

って提供されます。バーチャリゼーションは根本的な物理的アプリケーションに利用可能な資源を分

離します。ブロック・チェーン・バーチャリゼーションの特性は、サービス、SLA の隔離および品質、

コントロール、統制および弾性的な資源能力を含んでいます。

57

大多数の今日のブロック・チェーン実装は、Ethereum のように、共有されています。ここで多数の

分散化アプリケーションが、隔離(予測不能の実行からのダメージ)なしで並んで作動します。ブロッ

ク・チェーン・バーチャリゼーションは、弊社が集中または個人のインフラストラクチャーの危険に

ついて妥協せずに、これらの制限を克服することを可能にします。

およそ 20 年前に、産業はサーバー・バーチャリゼーションの方へ変わり始めました。今日、ほとん

どすべての消費者アプリケーションはバーチャル・マシン上で作動します。同様の変更は 10 年前に

ネットワーキングの中でスタートしました。ここで柔軟な位相を備えた大規模なネットワークは専用

プライベート・ネットワークのルック・アンド・フィールを提供して、根本的な共有インフラストラ

クチャー上で仮想ネットワークとしてバーチャリゼーションによって実行されます。弊社は、同じ産

業変更がブロック・チェーンの分野で起こることを期待します。

「バーチャリゼーション」の用語は、その機能の根本的な現実取引の論理的な資源の分離を提供する

抽象層について広く記述します。ブロック・チェーン・バーチャリゼーションで、コンセンサス、状

態およびブロックストレージのようなブロック・チェーン・インフラストラクチャーのコンポーネン

トおよびバーチャル・マシン(計算)層はそれぞれ仮想化されます。これは、仮想チェーンを横切って

異なった希望の処理の確認に応じて仮想コンセンサス実例が割り付けられることを可能にします。さ

らに、異なる仮想コンセンサス実例が同時に作動し、洗練された計算、資源のよりよい利用を提供す

ることができます。個人のブロック・チェーンと異なり、仮想コンセンサスのインスタンス化はセキ

ュリティ、根本的な共有されるインフラストラクチャーの回復力、集中排除およびコンプライアンス

の利点があります。

専用の物理的なインフラストラクチャー - 第一世代(Bitcoin)。アプリケーションはそれぞれ専用インフラス

トラクチャー上で作動し、それ自身の個別のブロック・チェーンがあります。

58

共有インフラストラクチャー - 第二世代(Ethereum)。多数のアプリケーションは共有インフラストラ

クチャー上で作動します。コンセンサス、 ストレージ、また計算サービスは、隔離または SLA のコ

ミットメントのないアプリケーションを横断して共有されます。

ブロック・チェーン・バーチャリゼーション - 第三世代(『オーブス』（Orbs）)。統制的なアプリケ

ーションはそれぞれコンセンサス、ストレージ、また計算サービスの仮想実例に依存して、個別の仮

想ブロック・チェーン上で作動しますが同じ物理的なインフラストラクチャーを共有します。

設計原則 ブロック・チェーン・バーチャリゼーションは、分散化アプリケーションが直面している課題のいく

つかに取り組み、集中 IaaS やクラウドプラットフォームの上のよく知られているオペレーションに似

た特性を提供します。十分なアーキテクチャー詳細は個別の技術的なホワイトペーパーの中で公表さ

れます。ソリューションの設計原則は次のものを含んでいます:

サービスレベル契約(SLA) - 仮想チェーンはそれぞれ、そのニーズを満たすためにサービス水準を保証

します。SLA は、同じ物理的なインフラストラクチャーを共有する他のアプリケーションの実行イン

パクトを縮小するコミットメントです。

隔離 - ブロックストレージおよび個々の仮想チェーンの状態の分離は、他のチェーンに生じる欠点お

よびエラーからの隔離を作成します。例えば、アプリケーションのスマート契約でのバグは、仮想チ

ェーンを分岐させるかもしれませんが、ネットワーク上の他の仮想チェーンには影響しません。

シャーディングおよびスケーラビリティ-バーチャリゼーションは、コンセンサスの固有のシャーデ

ィングおよびシャーディングの最初のレベルを可能にするために、サービスおよびステートストレー

ジを計算します。そこでは同じように様々な仮想チェーン、それらのコンセンサスおよびストレージ

が、同期されず、別々に扱うことができ、同時に実行ができます。

統制 - いくつかの配置パラメーターはすべての仮想チェーンを横切って整合させることが必要となり

ますが、多数は独立してコントロールすることができます。これは、すべての仮想チェーンが各アプ

リケーションのニーズを最適化し提供することを可能にし、ステークホルダーの統制の利益対立を縮

小します。

弾性キャパシティー - 物理的・事実上の資源間の分離は、仮想チェーンが発展する使用法パターンに

あわせたオンデマンド資源を加えることを可能にします。さらに、弾性キャパシティーは予期しない

爆発でも、一時的な資源配分を行います。

セキュリティおよび集中排除 - 単一のアプリケーションで専用仮想チェーンを提供しますが、第三者

機関とアプリケーションによって操作された多くの物理的なノードは、実際上集中排除のセキュリテ

ィを利用して、そのコンセンサスを処理するために使用されます。

反対仮想チェーンスマート契約-隔離はアプリケーションか仮想チェーン内の処理にとって重要です

が、単純なクロスチェーン相互運用性は有用です。これは、すべての同期がチェーンを含むことを必

要とします。このようなオペレーションはより遅く、標準作業より多くの資源を要求します。

59

消費者規模

処理能力とレイテンシー

消費者規模用のブロック・チェーン・インフラストラクチャーを設計する場合の最初の課題は、処理

能力とレイテンシーに関する消費者の期待をみたすことです。成功した消費者ブランドには何十億も

の相互作用を行なう何百万ものエンドユーザと連結される可能性があります。この大きな規模により、

コンセンサスに基づく分散化インフラストラクチャーの課題も大幅に拡大し、従来の集中インフラス

トラクチャーは定期的に限界がおしよせるでしょう。

処理能力はネットワークが提供することができる毎秒メッセージの数として定義されます。ブロッ

ク・チェーンの分野で、考慮される数はネットワークが確認することができるトランザクション/秒

の数です。Ethereum の現在の生産バージョンのような従来のブロック・チェーン実装は、トランザ

クション/秒について約 1 ダースの処理を確認することができます。64 ギャップは重要ですが、集中

排除が比較的高値のため、これは驚くべきではありません。例えば、1 つの処理の結果が別のものに

依存するかもしれないため、ブロック・チェーン上の処理は対応させるのが悪評高く困難です。処理

を行なうことは同期に大きな制約を加え、実装スケールをはるかに困難にします。さらに、集権制に

反して、コンセンサスプロセスは、すべての処理に関する合意に達する必要がある多くの独立したノ

ードを含んでいます。このプロセスは、集権制で処理が要求されない重要なオーバーヘッドを引き起

こします。

レイテンシーは、ネットワーク上の単一のメッセージを処理するために必要な時間量として定義され

ます。ブロック・チェーンの分野で、ユーザーによってしばしば認識される数は確認回数です。例え

ば、Netflix がブロック・チェーンのコンシューマ製品である場合、ユーザーが動画再生を待つ必要が

ないように、動画再生リクエストは直ちに確認されることが必要です。Ethereum の現在の生産バー

ジョンのような従来のブロック・チェーン実装は、取引確認に数秒間かかります。65 ネットワークが

混雑する場合、この数は数分どころかしばしば数時間に増大します。このギャップお驚くべきではあ

りません。最初に、同期処理を行なうことは、処理の並列待機を意味します。

64 https://blog.ethereum.org/2018/01/02/q4-roundup/ 65 https://etherscan.io/chart/blocktime

60

そして、一旦すべての前の処理が処理されてからはじめて処理されるのです。次に、独立したノード

のグループ間のコンセンサスプロセスは通常いくつかの往復トリップを要求し、より多くのノードが

参加するとともに増加するネットワークの伝搬時間によって抑制されます。第 3 に、長いブロック間

隔はいくつかのコンセンサスアルゴリズム中のセキュリティに不可欠です。最終的なコンセンサスに

依存するモデルでは、後のブロックの任意の数が生成される場合のみ、実際の確認に到達しています。

これらの両方の中で消費者の期待をみたさないことは、製品の成功を脅かします。消費者は劣悪なユ

ーザー体験に対する低い寛容性で悪名高いものです。設定の見込みは、消費者が慣れている体験によ

って決定されます、現在の、集中アプリケーションから得られるものです。ほとんどの消費者が、使

用するアプリケーションが分散化されるかどうかに気づかないだろうと期待することは合理的です。

計量可能な料金モデル システムのスケーラビリティは処理能力と潜在のような生のネットワーク・パラメーターを越えます。

Kik Interactive による Kin によって Ethereum に乗り出す場合の規模への主な障害はインフラストラク

チャー料金でした。66 CAC(顧客取得価額)は取引手数料のみで 10 ドルを超えました。67 成功した消費

者アプリがこの環境の中で繁栄できない場合があることは全く明らかです。1000 万のユーザーに達

することは、1億ドル以上かかるでしょう-プロジェクト合計に資金を越えてしまいます。

明白なソリューションはインフラストラクチャー料金を劇的に縮小することです。Ethereum の原価

高は、PoW コンセンサスに対するその信頼に緊密にリンクされます;PoW では、作業費は、ネットワ

ーク上の財産の総価格に比例して成長します。価格が増えた場合、プロセスは割合を維持するうえで

より不経済になります。さらに、すべての処理を有効にする Ethereum ネットワーク中のノードの数

は、20000 以上で、分布システムで要求された以上の桁です。68これらの費用要因は両方が PoW をや

め、コミッティでコンセンサスの参加者の数を減らすためにすることにより除去することができます。

縮小される絶対量よりスケーラビリティ料金で多くの利点があります。ネットワークの使用のピーク

は料金をコントロールできずに螺旋状になるかもしれません。一般に、市場価格は外見は料金を決定

するうえで最も効率的なものですが、市場が過度に不安定な場合は問題です。例えば、全アプリにシ

ャットダウンが起きるおそれがあります。平行する何百万ものユーザーとの 2 つのポピュラーな消費

者アプリで要求がネットワークのキャパシティを超過する場合を考えてみてください。一旦最初のア

プリがクライアントを修正し、他方に関して取引手数料を増加させれば、1 つの瞬間に、数百万もの

ユーザーが別のアプリを優先し、その結果圧倒的な不足が引き起こされるでしょう。

66 https://medium.com/kin-contributors/kins-blockchain-considerations-ebd0b60aebd5#2340 67 https://medium.com/kinfoundation/insights-from-kin-initial-product-launch-441c458a4ece 68 https://www.ethernodes.org/network/1

61

『オーブス』（Orbs）では、アプリ・デベロッパーは価格変動からそれら自身を保護して、前もって

予備力を購入することができます;ピーク要求からそれら自身を分離して、専用資源を獲得すること

ができます;また、月間料金制度を使用し、価格ボラティリティーへの全面的な曝露を縮小できます。

スケーラビリティに大きな打撃を与えるもう一つの料金関連の決定は、1 つの処理当たりの料金を徴

収することです-Ethereum のような汎用のブロック・チェーンによる共通のアプローチです。これは

ネットワーク・オペレーションに大きなオーバーヘッドを課します。各処理の処理はネイティブトー

クンの元帳に書くことを要求し処理のシャード化がより困難に(無関係な契約でも同期する必要があ

るため)なります。さらに、大量の徴収と比較している場合、処理ごとの徴収は処理とストレージで

オーバーヘッドを加えます。

産業での 1 つの取引コスト当たりの削減に使用される別の料金モデルは、1 つのウォレット当たりの

最低残高です。このモデルは、ブロック・チェーン・プラットフォームの中で、例えば Stellar で使用

されます。システムは、スパムおよび不正売買の乱用を防ぐために必要な摩擦を提供することを目指

しています。一旦ウォレットが確かに「シンジである」ことをユーザーがプラットフォームへ証明し

た場合、このウォレットには、一定の量のトークンを置くことによって、プラットフォームは使用の

制限を上げ、このウォレットからユーザーが無視できる少額の料金で多くの処理を可能にします。

このアプローチの問題は、消費者が、確かでないサービスに事前に費用を支払わないことです。エン

ドユーザが最低残高料金を払う仕組みでは、恐らく消費者ブランドが受けいれられるより低いレベル

でコンバージョンが停止するでしょう。通常起こるのは、消費者向けデジタル・サービス(分散的な

アプリの供給者)が顧客を引きつけるためにこれらの料金に補助を試みるということです。第三者に

よってこれらの料金に補助が交付されれば、シビルの攻撃に優位性を失います。さらに悪いことに、

攻撃者が他の収益に加えて補助金を得ることが可能になるため、シビルの攻撃の新しい標的となって

しまいます。取引ごとの手数料の代わりとしての登録支払いによって、『オーブス』（Orbs）プラッ

トフォームは助成金を制限し、またコストでも、シビル攻撃対策でも、できるだけ、デジタル・サー

ビスへの攻撃を緩和する力を持たせなければなりません。

常に成長するストレージ 現在のブロック・チェーン・プラットフォーム生成の大きな費用要因は、しばしば必要な資源が実

際の技術的要求事項とは相関を持たずに拡大するという事実です。Ethereum においては、例えば、

ブロック・チェーンストレージの十分なノードの数と同数の、そしてスマート契約コードのすべて

の部分を実行する同数のプロセッサーに関して十分なコピーがあります。分配分散制は、執行とス

トレージの両方での一定レベルの冗長を要求します、それらの適切な冗長は恐らく一定で、ほとん

どの場合高々1 ダース、あるいは 2 ダースです。料金は PoW 難問の解決者にのみ払われますが、マ

イナーはみなマイニング・オペレーションがキャッシュ・フローであることを期待します、したが

って、平衡では、料金はすべてのマイナーのコストの合計を相殺するでしょう。『オーブス』

（Orbs）プラットフォームのアーキテクチャーは、任意のコンポーネントの冗長が断固とした境界

内にあると保証します。

62

ストレージは、もう一つのコスト・ジェネレーターです。『オーブス』（Orbs）記憶 API は、明示的

なブロック・チェーン履歴終了とネイティブデータの明示的な終了を定義します。これは、データが

定義された(無限大ではなく)時間を持ち、クラウドサービスの中で期待された大きさまで、ストレー

ジの経費を大幅に縮小することを保証します。さらに、最終段階を提供するコンセンサスに依存する

ことは、『オーブス』（Orbs）プラットフォームがコンセンサスの下の状態を維持することを可能に

し、ブロックストレージへの高帯域アクセスの必要を除きます。

軽い クライアント ネットワーク組織に関する弊社の議論で示されるように、消費者は主としてモバイルアプリおよびウ

ェブサイトの使用によりネットワークにアクセスするでしょう。これらの使用パターンは、資源の非

常に低い可用性が特徴で、それにより、産業で一般に軽いクライアントと呼ばれるシン・クライアン

ト実装を要求します。.これらのクライアントは十分な成熟したノードのようにブロック・チェーン

履歴全体の間で同期せず、通路ノードと信頼のある関係を通常維持することが見込まれます。

通路ノードを信頼する必要は、ノードの正直な振る舞いでクライアントの依存性を作り、中間者攻撃

のような脆弱性を可能にします。危険を緩和するために、いくつかのクライアントは、ブロック・ヘ

ッダーを有効にすることにより状態の部分的な確認を行ないます。別の共通の戦略は多数のノードク

エリによるデータ確認ですが、スケールはもちろんありません。代わりにこのスマート契約を実行す

るノードを信頼することをクライアントに要求するため、クライアントがスマート契約を尋ねる必要

がある場合、その問題はさらに重要です。

弊社は、通路ノードに対する低レベルの信用で作動できるライトクライアントの提供に価値を見出し

ます。この能力はネットワークに所有された秘密を使用して、『オーブス』（Orbs）プラットフォー

ム上に提供されます。スマート契約の例に戻って、クライアントは通路ノードに契約アドレスおよび

議論を提供し、クエリを行ない、署名されたレスポンスを返すでしょう。軽いクライアントは、全体

としてネットワークの署名を有効にすることができ、それにより、特定の通路から必要とされる信頼

のレベルを下げることができるでしょう。軽いクライアントがノードを信頼する必要を縮小する『オ

ーブス』（Orbs）プラットフォームのさらなる利点は、プロトコルが処理注文で公平を保証するとい

うことです。コンセンサスノードに不透明な暗号化された前コンセンサス処理の送信によって、弊社

は、処理が検閲またはバイアスのない執行を注文することを保証することができます。

注文と確認の分離 大衆市場消費者アプリの必要条件を満たすために数桁スケーラビリティを増加させるために、『オー

ブス』（Orbs）プラットフォームは多数の戦略に依存します。コンセンサス戦略の注意深い選択を越

えて、専門のノードを優先し、接続速度、アップタイムと処理能力に関する高い SLA 維持を奨励する、

他のいくつかの戦略がプラットフォームと合併されます。最初の戦略はコンセンサス注文および確認

を分離しています。

63

処理およびスマート契約の確認プロセスは高価で、多数のノード上に走らなければならないので、複

製の計算上のコストを負担します。確認と注文が連続して行なわれる場合、処理処理能力は両方の完

成に必要な所要時間までに制限されています。2 つの分離はパイプ・ラインを作成し、それにより、

全面的な処理能力を増加させます。

処理能力における改良に加えて、規律正しい処理の確認は同時計算のより単純な計画よりも容易な問

題です。さらに、ネットワークが確認に必要なコンセンサスノードの量を減らすことを可能にし、そ

れにより、よりよい資源活用を全体として促進します。

多くの既存のブロック・チェーン実装が確認および連続して注文を行ないます。ノードは、アウトプ

ットを有効にし、次に、完全に有効な処理で構成されたブロックを単に提案するために通常最初に処

理をすべて実行します。処理が実行され、提案されたレスポンスを返す裏書人のグループのもとへ最

初に送られる場合、69分離技術は Hyperledger-fabric のようなわずかの最先端技術の実装によって使用

されます。十分な裏書人応答が集められる場合、処理はコンセンサス発注サービスへ転送されます。

いくつかのアプリケーションのために発注の前に確認を行なうことが有効です。しかしながら、弊社

が見る消費者アプリケーションでは、暗号化された処理を最初に発注し、公平を保証することが利点

となるでしょう。

69 http://hyperledger-fabric.readthedocs.io/en/release/arch-deep-dive.html

64

コミッティによる効率的なコンセンサス スケーラビリティを増加させるために『オーブス』（Orbs）プラットフォームによって使用される第

2 の戦略はコンセンサスプロセスに直接参加するノードの数を減らすことを含んでいます。ほとんど

のコンセンサスアルゴリズムでは、メッセージ複雑さがノードの数で 2 次的に成長するため、これは

重要です。弊社が多くの検証者、セキュリティ用の重点目標および集中排除へのネットワークを計る

ことを計画すれば、実行が合理的な境界内に残るであろうことは確かに望ましいものです。

ノードの総数に対する属領を縮小する効率的な方法は、コンセンサスのより小さなコミッティに依存

しています。弊社がコンセンサス巡回間のコミッティを無作為化する場合、すべての新しいブロック

上で例えば、攻撃者がどのノードを攻撃するべきか知るのを妨げることができます。ランダム化プロ

セスは、会員を前もって操作することができないことようにするためにいくつかの特性を完了しなけ

ればなりません。さもないと、弊社は、危険を冒して全モデルのセキュリティを危険にさらしてす。

このプロセスは、ヘリックスコンセンサスアルゴリズム用の技術的なホワイトペーパーで詳細に議論

されます。

65

ブロック・チェーン・バーチャリゼーションによるシャーディング システム・エンジニアリングでは、拡大縮小システムは、容易に成長できないボトル・ネックにより、

必ずしもより多くの資源を加えることによって達成することができません。シャーディングはスケー

リング用の技術で、シャード（破片）と呼ばれる、より小さく、ほとんど独立した半製品に分割する

ことにより、ボトル・ネックを十分に小さくし、システムをスケールアウトさせます。分散化コンセ

ンサスは避けられないボトル・ネックです;『オーブス』（Orbs）プラットフォームは、新しいテナン

ト・アプリが加えられるとともにネットワークが外に水平にスケールを可能にするため、破片にテナ

ントを分断します。AWS のような集中インフラストラクチャー・ソリューションに反して、単に資源

を加えることは、キャパシティーを増加させるのには通常十分ではありません。AWS を使用する製品

の数が増大し、サーバーおよびネットワーク接続のようにハードウェアを加えることによりインフラ

ストラクチャー・キャパシティーを増加させる場合、個別の製品が完全に別々作動し、通常要求を満

たします。

これは通常のブロック・チェーンの場合ではありません。例えば Ethereum の上の処理は、異なる契

約によってさえ、互いに影響するため、順に行なわれることが必要です。さらに悪いことに、PoW ブ

ロック・チェーンの中の立証者の数はブロック・チェーンが楽しむセキュリティのレベルと関係があ

ります;シャーディングによってユニット・サイズを縮小することは同じ比率でセキュリティのレベ

ルを下げることです。Ethereum の中の有効なシャーディング技術の研究開発は大きく投資されてい

ます。見たところでは、『オーブス』（Orbs）のための提案されたアーキテクチャーの中でこの問題

を解決することははるかに簡単です。特にコンセンサス受託者を雇用する場合、コンセンサスモデル

を許可し、そのセキュリティ特性を弱めないシャーディングです。異なる分散化消費者アプリは独立

して、異なる無関係な資産で作用します。払い込みの料金が多く、1 つの処理当たりが少ない場合、

これは特に真実です。デフォルトで分散化アプリをシャーディングすることによって、アーキテクチ

ャーは並列化を中心とすることができます。

インフラストラクチャーが設計されている『オーブス』（Orbs）は、作動する多くの独立した消費者

アプリケーションを支援します。それらが利点を享受する共有されるインフラストラクチャーで作動

する場合、アプリケーションが設計によって互いから独立し、資源を共有し、かつシステムが仮想チ

ェーンの自然なシャーディングでスケールすることを可能にします。

ブロック・チェーン・アプリケーションの 3 つの原価計算区分要因はステートストレージのコンセン

サス巡回、読み取りおよび書き込みで、オペレーションを計算します。注文を命じることができない

限り、異なる仮想チェーンの処理についてのコンセンサスは独立して運用ができます。したがって、

異なる仮想チェーンのコンセンサスは、個別の資源上で同時にシャーディングし実行することができ

ます。同じように発注がない場合、仮想チェーンの元帳も独立して維持することができます。ここで

は日程計画を計算し、依存する処理が順番に実行されるだろうということを要求します。仮想チェー

ンが独立した注文を行い、平行で計算ができます。さらに、個々の仮想チェーンの状態の隔離は、そ

のバーチャル・マシンのメモリ必要条件を縮小します。

66

弾性キャパシティー 消費者アプリケーションは、トランザクション速度、アカウントおよびストレージで常に増加が要求

されます。さらに、インフラストラクチャー使用が拡大するとともに、より高い資源能力の必要があ

ります。トランザクション速度、計算速度は、大規模な記憶資源リソース(最初に割り当てられる)は

将来の必要条件を満たすことができません。将来のキャパシティー・リクルートのために、弾性のキ

ャパシティーの必要があります。

弾性キャパシティーは、ブロック・チェーン・コンポーネント(コンセンサスのような、計算する、

あるいはストレージ)が資源の追加でアーキテクチャーによってスケールできることを必要とします。

さらに、資源配分中の迅速な更新は分散化アプリケーションのオペレーションへの中断なしで行なわ

れるべきです。

アプリケーションが集権制中の追加の資源を要求する場合、事実上か物理的である追加資源の提供に

より、システム管理者はそれらのキャパシティーを調節することができます。分散的インフラについ

ては、資源配分のための分散的なメカニズムの必要があります。さらに、ノードがアプリケーション

によって要求される資源を提供する、刺激的なメカニズムの必要があります。

67

消費者保護と規則

規制の発展

2006 年の著書、コード v270では、Lawrence Lessig は、自由で、無秩序で、無政府状態の状態へ出現し

た社会が、それらを規定する機関、構造、および制約を生成するようになるパターンを観察します。

Lessig は、このパターンがインターネットの発展にどのように当てはまるか、また、目に見えない力

がどのようにこれらの機関を形作るか示します;これらの力は、存在しうる自由および進行を抑える

ことがあります。

Lessig がコード v2 を出版した 3 年後、Bitcoin が導入されました。また、暗号通貨状態は、彼の予測

に続きました。初めは、ブロック・チェーンは自由のアーキテクチャーとして現われました:取り締

まれない、自己を命じること、コントロールがないものです。これらは成熟するとともに、新しい構

造が常に成長しているブロック・チェーン社会のアーキテクチャーを形成して出現します。しかし、

このアーキテクチャーの形成における見えざる手は、中立ではありません。暗号通貨コミュニティー

の既存企業および有名で重要なメンバーは、産業で多くのイノベーションを推進します;これにより

市場の独占的な管理を可能にする組織が作られることが考えられます。政府はしばしば、ユーザーを

保護するため、ブロック・チェーンのインターフェースに、法律の「昔の」力を使用します;これは、

プラットフォームのより多くの管理を可能にする組織を促進するかもしれません。弊社が形成してい

るアーキテクチャーが、自由と進歩の一つであるかどうかは、ブロック・チェーン・プロトコルのデ

ザイナーにかかっています。

確立された消費者ブランド

ブロック・チェーン分野の外部でブランドを確立した設計パートナーとの弊社の仕事を通じて、弊社

は、完全な内部経営会社の指向性との間で、硬直的な違いを観察しました。典型的には、維持が想定

される何百万もの既存のユーザーおよび進行中の事業活動が存在しています。その結果、これらは、

ブロック・チェーン・オペレーションに関連した規制の不安定さの危険を特に懸念し、規制機関が既

存のビジネスへの危険をもたらすことを心配しています。ブロック・チェーン会社は、他方では、こ

の不安定を新産業を自然な状態と見なし、かつ産業への危険としては無視する傾向があります (破壊

的なビジネス・パラダイム導入はいうまでもありません) 。

70 http://codev2.cc/download+remix/Lessig-Codev2.pdf

68

純粋なブロック・チェーン会社の重要性およびそれらのエコシステムへの著しい貢献を損なわないよ

う、弊社は、プラットフォームがこの場合で新参者のこうした関心事を無視することは問題があると

考えています。ブロック・チェーン技術が主流になるためには、既存企業が既存のユーザー基礎を備

えたフィールドに入ることが重要です。これらの会社は法的な不安定を受け入れることはできません。

また、既存の規則で必要な条件に従うプロトコルが可能になるかどうかは、各プラットフォームにか

かっています。

消費者保護 アプリ・デベロッパーのアプリで、ユーザーが価値のある財産を保存または譲渡することを可能にす

ると仮定してください。これは、ピア・ツー・ピアの報酬、仮想物品の取引、サービスに対する報酬

などです。製品エンジニアリングでは、問題は小さいモノです:デベロッパーはありあまるほどの産

業等級から業務処理のデータベースを選び、元帳のシンプルな実装を組み立てることができます。し

かし、転送された資産が現金に変わると、新しいタイプの問題が生じます:この元帳は広くマッドス

テーク、クラッカーおよび横領者からの標的になります。また、これらの不正アクセスがあった場合

の補償または刑事告発に対する責任が及ぶ危険性があります。これらの危険からの保護は捉えがたい

ゴールです。一部のコンテキストでは、元帳をコントロールする当事者が、処理を遅らせるあるいは

処理を削除するような、微妙で間接的な不正操作ができます。

コアコンピタンスが消費者アプリケーションであるビジネスについては、適切にユーザーを保護する

ことは大きな負担です。多くの場合で、企業は、やむを得ず通常のビジネスの手続きと構造を大幅に

変更しました。大部分は、主製品が焦点でない場合機能を回避するか、あるいはそのような危険なサ

ービスを提供する第三者ソリューションを統合します。

ある程度まで、ブロック・チェーン技術は、危険を緩和するか完全に中和する、安全な暗号通貨プロ

トコルおよび集中排除に対する信頼により、こうした危険なサービスを提供する障壁を低下させる可

能性を持っています。

分散化元帳セキュリティ 元帳のセキュリティ費用負担が多数の独立した組織間で共有されるため、元帳の分散化の実装は安全

維持がより簡単です。集中所有または集中統制がない場合、単一の組織で元帳をコントロールするこ

とができず、それがリスクにより、危険にさらされることはありません。すまわち誰も元帳をコント

ロールしていなければ、誰も元帳を盗むことができません。さらに、多数の当事者が、絶えず元帳の

完全性を監査し、プロトコルの合意されたコンセンサスとの不一致を識別することができます。

69

Bitcoin または Ethereum のような確立された PoW プラットフォームでは、典型的な処理では、アリス

は、移転を反映するために共有される元帳上で一定量のトークンの所有権登録が修正される処理(ア

リスの秘密鍵で署名された)の送信により、ボブのもとへある価値を送ります。署名された処理は、

ピアツーピア・ネットワークを横切って広められ、その有効性を確認し、有効な場合ブロック候補に

含むマイナーに届きます。その後、マイナーはそれぞれ、ブロック候補の PoW 難問の解決策を捜し

ます。結局、1 人のマイナーが難問を解決し、閉じたブロックを公表するでしょう。他のマイナーは

閉じたブロックを受け取り、その有効性をチェックし、有効な場合、彼らの将来のブロック候補のた

めに前のブロックとしてそれを使用します。

検証者が仮想通貨(検証者が十分な信任状あるいは作成権限を一方的に持っているか無期限にユーザ

ーの処理を防ぐことを意味する)をコントロールしているかどうか確かめましょう。71 マロリー(悪意

のあるマイナ)は、ブロック候補にそれらの処理を含めないことによってのみユーザーのための処理

を防ぐことができます;しかしながら、他のマイナーがブロックに結局それを含めるため、彼女はそ

れを無期限に閉じたチェーンにすることができません。彼女は処理を一方的に実行することができま

したか？アリスの秘密鍵なしでは、マロリーは、彼女にはボブに価値を移動させる権限があるという

有効な証明を作成することができません。しかし、マロリーは、自分にアリスの資金を移動させる無

効な処理を含めて、いくらかの仕事で PoW 難問を解決することができ、そのブロックを閉じて、公

表できるブロック候補を作ることができます。将来のブロックのマイナーは、マロリーのブロックを

有効にし、それが無効の処理を含んでいるので、ブロック・チェーンに含まれていることからそれを

失格させることになります。両方の場合では、悪事からマロリーを制限するものが将来のマイナーの

不確定の任意のグループで、彼女のブロックの有効性を確認できないことを知っていることに注意し

てください。

Bitcoin と Ethereum の場合には、弊社が、検証者が元帳をコントロールしていないとともに保証する

2 つの特性を見いだしています:暗号通貨プロトコルは、検証者が処理を一方的に送ることを不可能に

します。また、ネットワークの開放は、検証者が無期限に処理を防ぐことを不可能にします。

暗号通貨プロトコルは、どの有効な処理が決定論的で、普遍的に受理された方法であるか定義します。

これは、無効な処理がブロックに含まれており、ネットワークコンセンサスがブロックを受理する場

合、このコンセンサスがプロトコルに従っておらず、本質的には、それが Bitcoin か Ethereum ネット

ワークのコンセンサスではないことを意味します。弊社自身がある循環的なロジックを使用すること

を認めれば、弊社は Bitcoin が無効のブロックを受理する場合もはや Bitcoin ではないとするかもしれ

ません。

ネットワークの開放は誰もが検証者としてネットワークに参加する能力によって提供されます。処理

がネットワークの検証者によって検閲されるのではないかとアリスが考えれば、検証者としてネット

ワークに参加し、自分の処理を承認するかもしれません。彼女のブロックが有効であるので、将来の

ブロック検証者は、それらのチェーン(以前に言われていたように、それらがプロトコルに従ってい

ない場合、それは同じネットワークではありません)にそれを含めるべきです。

71 https://coincenter.org/entry/when-does-a-company-actually-control-customer-bitcoins

70

検閲とフロント・ランニング 処理の検閲と格闘するためのプロトコルの開放に依存することは、いくつかの現実世界の用途におい

て理想的ではありません。マイナーはユーザーが処理するのを無期限に妨げることができませんが、

ブロックを閉じる鉱夫はもう一人の鉱夫によって閉じた将来のブロックで遅らせて、処理を省略する

ことに任意に決めることができます。この力は大きなマイニング・プール・リーダーの手において重

要です。

さらに、マイナーは、処理がブロックに置かれるオーダー、および金融利得のためにそれらを操作す

る不正処理すら選ぶことができます。例えば、弊社は、あるクラスの財産が通貨と交換される、両側

の流通市場を実装するスマート契約を持っています。ある時に、アリスは 100 のトークンの最高価格

のために、資産に「偽装」を配置します。ボブは「クエリ」90 のトークンの最低値段用を同じ資産

に記録します。公平な取引契約は普及を分割し、ボブとアリスの両方に 5 つのトークンの冗長を残し

て、95 のトークンのた取引を委託するでしょう。しかし、その後、マロリー(ブロックを閉じるマイ

ナー)はもう 2 つの処理を加えることができます:ボブの処理を「ビッド」90 のトークンの最高価格で

プリペンドし、処理で追加し、「クエリ」100 のトークンの最低価格を含めます。処理の新しいシー

ケンスはスマート売買契約を引き起こし、ボブの 90 のトークンのマロリーの財産、そして次に、彼

女の手の中に 10 のトークンの全余剰を残して、100 でアリスにそれを売ります。同様のシナリオで、

より複雑な設定の中でとはいえ、バンコール・スマート契約 72 に対する理論的な攻撃が Emine Gun

Sirer によって提案されました。72

しかしながら、弊社は、開放より適切なツールでマイナーが市場操作の課題に取り組むことができる

と主張します。検証者がそれらの内容を知らずに、処理の命令でコンセンサスするコンセンサスプロ

トコルは、検証者が、それらが検閲とフロント・ランニングのような市場操作に使用することができ

る知識を持っていないと保証することができます。このような HoneyBadger BFT73 のようなプロトコ

ルが提案されました。同様のスキームはヘリックス・プロトコルの中で使用されます。

72 http://hackingdistributed.com/2017/06/19/bancor-is-flawed/#front-running

73 https://eprint.iacr.org/2016/199.pdf

71

コンプライアンスプロトコル ブロック・チェーン財産への対処における共通の問題は、所有権、管理人の仕事および資産譲渡に関

する規制要求事項への適合性です。

現在の暗号通貨設備の 1 クラスの直面する国際規制は、反マネーローンダリング規則(AML)です。

AML 規則は、過去 20 年間に全体的に採用されており、刑事訴訟用の財政的刺激およびテロリズムの

長期債化の除去により、犯罪とテロリズムと戦う手段と見なされています。金融機関に適用される

AML 規則は、長期、大規模、移転ホルダーが識別され、それらの同一性、資金源、移転が記録され、

確認され、金銭授受が実施官庁などへ報告されます。暗号通貨プラットフォーム上の価値移転は金融

機関の AML 基準に合致せず、往々にして処理を登録する金融機関の能力をさまたげます。例えば、

いくつかの機関は、預金が支払いおよび有効であると証明される支払い源を要求します。支払人が匿

名の仮想通貨では、処理の合法性を証明するのは困難、あるいはできないかもしれません。

管理が規則上必要な条件を要する別の資産クラスは証券です。多くの法域では、証券法は、適切な登

録を証券の所有権に要求します;一人の個人による長所の所有権がしきい値を越える場合は報告を必

要とするかもしれません。いくつかの財産は、少数の信任されない投資者によってのみその証券を共

有ができる私会社のような個人によって所有される能力の中で制限されていることもあります。

弊社は、法的枠組みがそれを考慮に入れる場合に地点間の財産の取引を許可するプロトコルを含む、

地方条例に対応させるため、インターフェースおよびブロック・チェーン上で共通のアセット・クラ

スを表わすことを可能にするスマート契約のフレームワークを開発することを目指しています。

プライバシーと AML 従来の金融機関と正常な状況およびインターフェースの中で使用することができる支払い元帳の新し

いプロトコルを設計する場合、興味深い課題が提起されます。一方では、消費者は金融プラットフォ

ームからハイ・レベルのプライバシーを期待します;ユーザーのための主な支払い方法であることを

目標とするブロック・チェーン・プラットフォームでは、これは、プライバシーの高レベルを要求す

るでしょう。多くの国々では、この遺産相続の見込みはプライバシー保護法則によって義務づけられ

ています。他方では、既存の AML 規則は、ユーザー・プライバシーに関する著しい妥協を要求しま

す。従来の金融機関では、記録は慎重に行われ、官庁に情報をすべて提出し、ユーザーの公衆の目へ

のプライバシーを維持することができます。

72

現行規則および長期的な施行戦略を区別することは重要です。多くの官庁が、共有されるグローバル

な元帳の透明性は、変則的で、疑わしい処理および問題のある口座を識別する強力なツールであると

認識しています。仮想通貨が従来の銀行業務の中の手続きに従うことを強いる規則では、商業と新技

術の施行上の利点の両方が縮小されるでしょう。弊社は、調整組織と実施官庁が仮想通貨およびブロ

ック・チェーンの性質にもっと適し、プロトコルの方がユーザーのプライバシーの保護でよりよいプ

ロトコルを好むと期待します。

弊社の意図は両面で努力をすることです:適用されるあらゆる現行規則にできるだけ従うように弊社

の支払いプロトコルを設計します;また、新しく前向きなプロトコルを設計するために、ユーザーに

犯罪と格闘する十分なツールを備えた優れたプライバシーおよび法則機関を提供することができます。

ホワイトチェーン ユーザーがすべての処理およびすべての使用例でプロトコルへの適合に価値を見出すとは限らないで

しょう。例えば、少額支払いのみが使用されるアプリ、あるいはそのようなプロトコルのリリースに

先行するアプリでは、これらを採用しないでしょう。支払い元帳は両方のタイプの口座、および適合

および被適合の処理の混合を含むことがあります。また、当然、一部のビジネスは、厳密に準拠のア

カウントの「ホワイトのチェーン」に限定するため、それらの処理を制限するでしょう。

73

現代の展開パラダイム

ネットワーク統制

過去 20 年間で、ソフトウェアエンジニアリングは、常に長いサイクルの設計、実装から、より短い

サイクルのテストおよび高頻度のきめの細かいリリースにへ移行し、これは大量市場のアプリ用のバ

ックエンド・サーバの開発での業界基準となりました。Google74, Facebook75, Amazon76 ソフトウェアの

発売、特に AWS は、ほぼ一致した合意の最も顕著な例であり、展開したソフトウェアでより高品質、

より少数の展開上の問題、生産でのバグに対するより速い反応を可能にし、より速い開発を可能にし

ます。

分散化アプリについては、後方サーバーはブロック・チェーンと置換されるでしょう。しかしながら、

現在の世代のブロック・チェーン・プラットフォームの統制モデルは、頻繁できめの細かいソフトウ

ェアの発売サイクルに依存する方法とは互換性がありません。大量市場のアプリケーションはそれら

の開発方法にあわせて発展しました。あるいは、分散化アーキテクチャーへ移動することは、それら

の集中相手とそれらの競争において不利のポジションへそれらを強要して、方法について妥協するこ

とが見込まれます。

弊社は、アプリケーションバックエンド上の連続的な統合および連続的な配信を目指して『オーブ

ス』（Orbs）プラットフォームを設計しています。これは、バックエンドのエンドポイント、スマー

ト契約およびプラットフォームコアの両方に適用されます。当然、集中排除は、変化の迅速な引受け

への障害を作成します。弊社のアプローチは、変更を急速にテストし展開させることについての定足

数メンバーの経済的誘因および不注意と行動抑制要因と各コンポーネントの展開手続きでのファイン

グレイン定義を組み合わせます。手続きのファイングレイン定義は、手続き(例えば、エンドポイン

トへの実装最適化は、すべての定足数メンバーによって別々にテストされ展開されます;実装を展開

する前に、プロトコルへの変更が合意される必要があります;)および参加者の形式の両方を指します。

異なる統制手続きに関与する参加者は、手続きの性質も異なるでしょう。

74 http://eclipsecon.org/2013/sites/eclipsecon.org.2013/files/2013-03-24 CI at Google Scale.pdf 75 https://code.facebook.com/posts/270314900139291/rapid-release-at-massive-scale/ 76 https://www.youtube.com/watch?v=dxk8b9rSKOo

74

いくつかの変更は『オーブス』（Orbs）フェデレーションメンバーによって受理され、一部は、興味

が仮想チェーンによって受理されることが必要です。一部の変更は、ほとんど分散化アプリケーショ

ンに関係するスマート契約で、影響を受けたユーザーの投票等が要求されるかもしれません。財政困

難の経済的誘因はノードの評判スコアの変更により適用され、サービスで徴収する価格を決定します。

エバーグリーンノード 変更がそれぞれそれがプロダクションの中で行われた後、変更が十分に小さく、強健さに対する十

分な自信を持てるかどうか、高頻度の展開の重要な段階が迅速に調査されテストされるでしょう。

変更はリスクを取るノードから比較的リスクを回避するノードまでのネットワークを介して迅速に

適用され、旧式コードを早期に破棄し、危険人物およびシステム複雑さを減らして、阻止すること

ができます。

第三者機関によってノードが操作されるコンセンサスに基づく分散制の中では、この挙動を実装する

ことは簡単ではありません。Bitcoin のようなシステムの歴史的な振る舞いの検討は有望ではありませ

ん。SegWit2X77 のようないくつかの変更案は、参加者の間のコンセンサスを達成することは、必ずし

も簡単とは限らないことが示されました。コンセンサスの不足の危険は、この場合、いくつかのノー

ドが提案されたプロトコル変更を拒絶し、他のノードが外部分岐を採用する場合、ネットワークが分

断される可能性があるということです。

たとえば Tezos78 のようなプロジェクトは、統制の問題について広範囲に議論し、コンセンサスのプ

ロセスをより合理化するためにいくつかのメカニズムを提案しています。弊社は、これらのメカニズ

ムが重要であると考えています。しかし、ネットワークの基本の結合が脆弱な場合、それらは十分で

はありません。ネットワーク政治が誘因への反対により、利益が誤って調整されガイドされる、異な

る圧力団体を作る場合などです。例に手数料をとりましょう。手数料は補償の手段を提供するので、

マイナーは料金を高く守ることを通常当然支持します。ユーザーは他方では、同質サービスを保持す

る限り、できるだけ料金を縮小することを通常支持しています。コンセンサスプロセスの緩和に向け

た最も重要な設計上の決定は、世界の同じ一般的なモティベーションおよび視点を共有する同様のプ

レーヤーのネットワークを組み立てることにより、反対の利益を除去してしまいます。『オーブス』

（Orbs）の場合には、プラットフォームが、これらの同じ消費者アプリケーションが効率的なマイナ

ーになることを可能にするコンセンサスアルゴリズムを選び、ネットワークの広告ターゲットが消費

者アプリケーションであるためには、長い道のりが予想されます。

統制問題の速い解決への一層の誘因化も経済手段によって適用することができます。評判スコアがコ

ンセンサスプロセスでのノードの議決権をコントロールするので、ヘリックスコンセンサスアルゴリ

ズムによって維持されたノード・レピュテーション・システムは、単純な誘因の実装を可能にします。

またその後価格料金のシェアを徴収できます。弊社は、新しいプロトコル・バージョン公開について

迅速に投票するようにノードを奨励します。これは、とどまる人々の評判の縮小により行うことがで

きます。

77 https://www.coindesk.com/2x-called-off-bitcoin-hard-fork-suspended-lack-consensus/ 78 https://www.tezos.com/static/papers/white_paper.pdf

75

弊社はコンセンサスの下にあるプロトコルの最新のバージョンへのアップグレードへのノードを奨励

したいと考えています。これはそうでない人々の評判の縮小により行うことができます-これは新し

いプロトコル・バージョンが後方互換性をもつ場合、初めはゆっくり、古いバージョンが期限切れに

近づいた場合、より迅速になるようにします。『オーブス』（Orbs）プラットフォームの統制目的の

投票メカニズムは、スマート契約として実装されます。

摩擦を縮小するもう一つの重要なメカニズムは、ネットワークの小部分にとってのみ重要な変更に方

法を供給することです。エコシステムに参加する消費者ブランドの 1 つによって要求される修正を考

えてください。この変更が誰か他の人にとって重要でない、さらにそれを必要としない人々に否定的

方法でインパクトを与えるものだった場合、寄与者は、それをコンセンサスにもたらすことは困難で

あると感じるかもしれません。この問題は、プロトコル修正が特定の仮想チェーンのみに当てはまる

ことを可能にすることにより、『オーブス』（Orbs）プラットフォーム上で解決されます。この場合、

修正を要求する消費者アプリは、他のノードから借りている専用仮想チェーンの中でのみ効果を持つ

任意の配置に制限されるでしょう。これは、変更に反対する他の参加者からほとんどの理由を除去す

るでしょう。

漸次移行 中核プロトコル変更が合意された後も展開の方法に問題が存在します。直ちに全ネットワークを移行

させることは、Bitcoin プロトコル修正でしばしば見られたプロセス上の大きなリスクが残ります。プ

ロダクションへの展開の後に予期されない問題が生じる場合、何が起こるでしょうか？すべてをテス

トとシミュレーションにより前もって不具合を識別することを保証することはほとんどできません。

変更はほとんどすべて、徐々に展開され、デベロッパーとチェーンの管理者が評価(調査、シミュレ

ーション、テストなど)ではなく実績に基づいてその正確さに対する自信を獲得します。変更の場合

に、青/緑の配備 79 の方法を使用し、プロダクション・システムへの変更では、ネットワーク全体が

クローンされ、また取引指図で、不変コード(青)または変更コード(緑)の両方に分配します。その後、

処理された取引をライブまたは試験中として考慮します。本質的に、すべての処理は両方の環境で処

理されます。しかし、「実際の」処理は永久記録媒体に委ねられます。また、「テスト」処理は正確

で、実際の環境と比較して、前もって定義したキー業績指標(KPI)セットを維持することが確認された

場合のみテストされます。展開プロセスでは、「緑の」取引全体が試験され、次に 90%-10%、50%-

50%および 0%-100%の分離した期間で始まります。両方のシステムの実行 KPI をチェックした後、デ

ベロッパーまたはコンセンサスは変更をそれぞれ承認することができます。主な不具合が発見された

場合、この方法論のもう一つの利点はブルーのシステムへのロールバックができる能力です。

この徐々の移行プロセスも、信用リスクのない方法で『オーブス』（Orbs）への Ethereum のような

以前のブロック・チェーン・ソリューションから移行するために使用することができます。第 2 のト

ークンを考慮してください、TOK で、Ethereum ブロック・チェーンの上にもとは始められたもので

す。TOK で、Ethereum から『オーブス』（Orbs）まで移行する準備ができた、と仮定しましょう。

79 https://martinfowler.com/bliki/BlueGreenDeployment.html

76

当然、直ちに全面移行を行なうことは危険です。代わりに、弊社はより柔軟で、信用リスクがない移

行を提案します。トークンを支援する消費者アプリによって使用される TOK クライアント SDK は、

Ethereum と平行して『オーブス』（Orbs）へのエンドユーザによって行なわれた処理すべてでミラ

ーリングを始めるでしょう。書き込みはすべて、『オーブス』（Orbs）プラットフォームの上に TOK

のための複製の元帳を作成して、両方のブロック・チェーンに起こるでしょう。この元帳は絶えず監

査され、真実の源と考えられる Ethereum 元帳と比較することができます。最初に、TOK クライアン

トは、Ethereum 読み取りに基づいた経営的意思決定を行ないます。しかし、これはランタイム機能

トグルと 1 つのユーザーごとに交換することができます。移行を始めるために、この機能トグルはユ

ーザーの 5%で切り替えられます。すべてが完了した場合 50%、そして最後に 100%に移行します。問

題が発見された場合、機能トグルを後方に切り替えることができます。また、すべてのユーザーは

Ethereum に経営的意思決定を基づかせる方式に戻るでしょう。書き込みがすべて複写されるので、

ロールバック能力を失う危険はありません。

アップグレード可能な契約 一旦展開したスマート契約は本来不変で、更新することができません。署名された後、当事者の 1 人

がそれを独力で変更することができれば、契約の意味はありません。この挙動はスマート契約の機能

ですが、不変性には多くの実際的な懸念があります。デベロッパーは誤りを犯すことが知られていま

す。また、ソフトウェアのすべての部分は、常にバグを持っています。このようなバグが不変のスマ

ート契約で発見された場合、何が起こるでしょうか？

この問題は、ノードコードベースのプロトコル・バージョンを更新する統制の問題に類似しています。

弊社は、コンセンサスを使用して、プロトコル更新の問題を解決しました。大多数のパーティーがプ

ロトコルを新バージョンにアップグレードすることに合意すれば、弊社はネットワークの全体にわた

ってアップグレードを始めることができます。同様の方法でスマート契約のアップグレードを解決す

ることは意味をなします。『オーブス』（Orbs）プラットフォーム上のスマート契約は、アップグレ

ード戦略を使用するように促進されます。この戦略は別のスマート契約として実践され、契約が改良

することができるプロセスをコントロールします。第 2 のトークンの契約は、トークンのすべてのホ

ルダーの重みがステークに加えられ投票に基づいてアップグレードを選ぶことができます。

マルチ・チェーン・ハイブリッド 現実世界の分散化アプリケーションの実際的な設計関係は、弊社の完全なソリューションが平行する

多数のブロック・チェーン・インフラストラクチャーに基づくことをしばしば必要とします。Kik

Interactive の Kin を共同研究する間に、弊社が対応した次の課題を考えてください。Kin トークンは

Ethereum ブロック・チェーン上で始められ、立ち上げのデファクト・スタンダードが ICO(最初のコ

イン提供)の一部として資金提供する時に起こりました。Ethereum は大きなエコシステムを持ってい

ます。また、その ERC20 標準に基づいた第 2 のトークンは、交換、第三者ウォレット、および Trezor

のようなハードウェアウォレットと容易に統合されます。他方では、Ethereum は、さらに高い料金

によって処理規模への厳しい制限と、ネットワーク混雑、そして低い処理能力を引き起こします。

Ethereum で Kin をスケールできないことで、プロジェクトでは、別のブロック・チェーン・インフラ

ストラクチャーへのトークンの移行が考慮されました。

77

この計画に伴う難点は、Ethereum の代わりと見なされたスケール可能なブロック・チェーン・ソリ

ューションに同程度に統合されたエコシステムがなかったということでした。一方向の移行を行なう

ことは、一部の当事者がトークンに統合する能力を危険にさらすでしょう。よりよい戦略は、Kin ト

ークンが 2 つのブロック・チェーンのハイブリッド解決策に基づくことです。最初のブロック・チェ

ーンは主としてその広範囲なエコシステムの統合に使用された Ethereum でしす。第 2 のブロック・

チェーンは『オーブス』（Orbs）プラットフォームのようなスケール可能なソリューションです。こ

れは 同じトークンでの 2つの異なる実装が行われるでしょう。ユーザーは、2つの実装間のトークン

の 1:1 交換を行なうことができるでしょう。また、両方の実装中のトークンを循環させる金額は、常

に親類 Kin ICOに作成されたトークンのオリジナルの数と等しくなります。

78

多言語クロス・チェーン契約 多くの場合、トークン実装間の一方向の移住へのよりよい戦略は、平行への新しい実装の追加である

ように見えます。これは、多数の異なるブロック・チェーンに同時に依存するハイブリッド・ソリュ

ーションを弊社に提供するでしょう。このような戦略では重要な技術的な課題が発生します。弊社は、

どのように 1 つのソリューションへ多数の異なるブロック・チェーンを組み合わせるでしょうか。こ

れらはどのように通信するでしょうか。

伝統的に、スマート契約は、外部ソースアクセス能力が制限されて、ブロック・チェーン自体上での

み既存のデータを土台とすることができます。Ethereum 契約もその例です。スマート契約がトラス

トの封チェーン体系内に作動するので、この制限は驚くべきではありません。オラクルとしばしば分

類された組織によって提供される外部データは、チェーン上で保存されたデータのようには信頼する

ことができません。

『オーブス』（Orbs）プラットフォームは、クロスチェーンの契約の導入によりスマート契約のこ

の固有の制限を克服します。『オーブス』（Orbs）で稼働するこれらのスマート契約は、安全で信

頼された方法で他のブロック・チェーンからデータを読むことができます。ちょうどスマート契約

が安全なオンチェーン『オーブス』（Orbs）ストレージから変数を読むことができるように、スマ

ート契約はさらに Ethereum から変数を読むことができます。この拡張は刺激的な新しいクラスの分

散化アプリケーションを開きます。多くブロック・チェーンにまたがることができ、そのデータの

すべての部分を保持するために最も適切なものを選ぶことができるアプリケーションです。この技

術で可能になった別の興味深い部分は、『オーブス』（Orbs）プラットフォームに他のブロック・

チェーンのためにもとは直接発展させられたスマート契約をシームレスにインポートすることです。

Ethereum のために元来設計されたスマート契約のシステムを考えてみてください。通常は、別のブ

ロック・チェーン・インフラストラクチャーに移行させることで完全な書き直しを要求するでしょ

う。『オーブス』（Orbs）プラットフォームはほとんどそのままこれらの既存のスマート契約を実

行することができます。

従って、プラットフォームが設計されている『オーブス』（Orbs）は、スマート契約の多数の言語の

執行を支援します。最もポピュラーなスマート契約言語は今日、スマート契約の Ethereum Solidity で

す。80 分散化アプリケーションが主流になるとともに、スマート契約開発用の専門言語に移行するこ

とをエンジニアに強いることは明白な摩擦を生み出します。『オーブス』（Orbs）の設計は、Python、

Java および JavaScript のような共通・広範囲の言語を使用して、スマート契約の開発をサポートし、

それにより、確立されたブランドにとっての開発の障壁をさらに低下させます。『オーブス』

（Orbs）にスマート契約執行の冗長性はより低いため、会計が Ethereum のようなプラットフォーム

と比較し、緩くても問題ありません。これは、Solidity や EVM のようなカスタムバイトコードにコン

パイルする、徴収がオプトコードレベルの正確なコード執行の言語に限定されないことを意味します。

80 https://solidity.readthedocs.io/en/develop/

79

消費者のために設計する

ブランドと信頼

コンセンサス観察に関する弊社の議論では、弊社は、実際に完全に信頼のない消費者のための分散シ

ステムを設計することはできません。使用するクライアント・ソフトウェアがソース・コードを調査

し独力でコンパイルすることにより、理論上プロトコル適合をエンドユーザが確認すると予想される

場合、これは Bitcoin のようなシステムの背後の分散的な理想とは異なります。エンドユーザがダウ

ンロードしても、2 進法でプリコンパイルをダウンロードしても、少なくとも理論上、この署名は 2

進法のマッチ、コミュニティーコンセンサスで確認すると予想されます。

弊社は、典型的な消費者は、暗号通貨およびこれらの極端な保全措置に関して知識がないと仮定する

ことができます。分散化消費者ブランドを集中排除および信頼のない性質が備えている理想の利点も

恐らく知られていません。集中排除はアプリケーションによってなされた設計の選択です。アプリケ

ーションが分散化されても分散化されなくても、アプリケーションを使用している消費者は通常知り

ません。

したがって、弊社は、消費者と、消費者が使用している製品を提供するブランドの関係が信頼を含ん

でいると仮定することができます。ブランドがそのユーザーの信頼を乱用すれば、例えばユーザーが

クライアント・アプリに供給しなければならない秘密鍵のような秘密を漏らした場合は、イメージと

評判は任意の分枝に加えて法的な制裁を受けるでしょう。

モバイルとウェブのクライアント

今日、コンシューマ製品を何百万ものエンドユーザの手にもたらすことができる配信メカニズムは、

この製品が分散化されるかどうかに関して不可知です。消費者は、モバイルとウェブのクライアント

をほとんど排他的に使用しています。これは Bitcoin のようなシステムの主要な媒体で、エンドユー

ザがさらにフルノードであるクライアントを実行すると理論上予想されるものとは異なります。ブロ

ック履歴全体を同期させた後でのみ、クライアントは、状態のその認識が正確であると期待すること

ができます。

80

モバイルとウェブのクライアントはこの特権を持っていません。ブロック履歴全体の保存は重要な集

積スペースを必要とします。また、同期プロセスは長い時間および広い帯域幅をとります。81 モバイ

ルとウェブのクライアントの資源制約は厳しすぎるので、これを実際的に可能ではありません。した

がって、消費者のためのブロック・チェーン・システムを設計する場合、弊社は産業がライトクライ

アントと呼ぶものに頼ることができます。このようなクライアントは、1 つ以上のフルノードに接続

し、ブロック・チェーン・データをクエリで読み、あるいは処理を送信します。得ているデータの有

効性のいくつかのヒューリスティックな証拠を使用しますが、接続するノードにある程度のトラスト

を予期します。不透明な処理注文 や ネットワークの所有する秘密ような『オーブス』（Orbs）メカ

ニズムは、ライトクライアント・プロトコルを単純化し、トラストの必要なレベルを著しく下げるこ

とがあります。

ネットワーク・アクセスの消費者パターン 消費者は、さらにインフラストラクチャー設計に影響を及ぼす典型的なパターンのネットワーク・ア

クセスを持っています。消費者は、複合の機器から単一のアカウントに同時にアクセスするでしょう。

例えばアプリにアクセスするためにオフィスでは携帯電話やラップトップが使用され、自宅では同じ

アプリにタブレットでアクセスします。

インフラストラクチャー層に関する設計決定では、プラットフォームのそのようなパターンとの互換

性がなくなることがあります。Ethereum の上の処理での使い捨てのランダムな値（ナンス） 使用を

考えてください。目下の目的は、処理の独自性を保証し、ネットワークが 2 度同じ処理を行わないこ

とを確かめることです。Ethereum クライアントは、連続する、ノンスフィールドで番号付けられた、

アカウントから送られたすべての処理中のインクリメントが必要です。Ethereum は番号を付けるこ

とに依存し、その前任者が承認されるまで、処理をしないでしょう。機器を横切って番号付けするシ

ーケンスを同期する必要があるため、このメカニズムは複合の機器によって同時の使用には適してい

ません。弊社は完全に独自性を処理に加えるために非逐次機構を使用することにより、この複雑を回

避するために働いています。処理されるか廃棄される前に、取引がどれくらいの時間待つことができ

るかにエンドユーザに境界を与えて、クライアント取引を執行の明示的な時間ウィンドウに制限する

コストを与えます。これは単独で作用する重要な機能です。

消費者による別の共通のアクセス・パターンは交互ではなく平行した多数のリクエストの送信です。

グループチャットユーザーが全グループと広告を共有する、ピア・ツー・ピアを広告するプラットフ

ォームを考えてください。すべてのユーザーニーズがコンテンツを受け取るメンバーをグループ化す

れば、それらは恐らく平行した多数の処理を送信するでしょう。Ethereum では、各処理の確認時間

は 15 秒です。82 この場合どのように計算されるでしょうか。標準実装は、クライアント側の目下を

インクリメントし、連続する目下番号と平行に処理をすべて送ることでしょう。さて、処理のうちの

1 つがある理由で失敗したと仮定します。プラットフォームは、最初の未使用の処理が確認されてい

ない場合、後の処理を処理しないでしょう。このエンド条件は、非逐次機構の使用により『オーブ

ス』（Orbs）プラットフォーム上でもう一度裏書きされます。

81 https://ethereum.stackexchange.com/questions/143/what-are-the-ethereum-disk-space-needs 82 https://etherscan.io/chart/blocktime

81

解約率のインフラストラクチャー含意 解約率は、特定の期間にわたる集合的なグループから退会するアイテムや個人数の指標です。消費者

アプリケーションに適用される場合、解約率は与えられた期間に製品を使用することをやめるエンド

ユーザの割合を指します。顧客不満足のような様々な理由、競争のよりよい選択肢、ノイズ中の消失

および一般に関心喪失により起こります。

解約率は消費者スペースの生の事実です。消費者ブランドがユーザー・ベースの大部分を失うことは

珍しくありません。すべての登録ユーザで活動的な、ノルマ内のユーザーは 5%ですが、これは現象

がどれくらい厳しいかを示します。

開発される分散的なアプリが、消費者が使用するトークンを含んでいる場合、解約率は分配がどのよ

うに時間にわたって作用するかを左右するでしょう。ユーザーの解約率が単調増加し、トークンの数

が減少すれば、それらが所有したウォレットの内部でアクセス不能になります。このようなトークン

の供給がしばしば制限されているため、弊社は大多数のトークンが循環から永久にロックされること

を見いだしました。このようなトークン経済のブートストラップが通常報酬の形の奨励に依存するの

で、これは別の様相からも問題です-大量のトークンがインセンティブとしてグループの消費者に配

布される場合などです。弊社は、補助金に使用された量の大部分が使用しないユーザーの手の中で終

了するかもしれません。

トークン・プロトコル層の注意深い設計では、解約率に適切に対処することに向けた長い道のりがあ

ります。弊社は単純化された例でこれを示すでしょう。トークンのスマート契約が、導入の代理主体

のリサイクルが可能で、ウォレットでが代理後 12 か月に使用されなかったと仮定してください。こ

の挙動は、雑ですが解約率の問題を有効に解消します。通常は、ユーザーのアカウントから資金を取

り戻す許可を与えることは、横領の危険を引き起こします。しかし、この場合、還流の規則は明らか

であり、したがって、誰もユーザーの資金をコントロールしておらず、透明です。また、分散的なス

マート契約によって執行されます。

消費者アプリおよびオープン・ソース 『オーブス』（Orbs）プラットフォームのようなブロック・チェーン・ソリューションは通常オープ

ン・ソースで、寛大な知的財産方針を持っています。しかしながら、多数の異なるオープン・ソー

ス・ライセンスがあります。また、ライセンスの特定の選択肢が、消費者アプリ使用の場合のための

適用範囲に影響するかもしれません。

消費者ブランドは、オープン・ソース・ライセンスの使用に関して非常に敏感です。これらのブラン

ドによって使用されるオープン・ソース技術は、財産を保護することを可能にするように注意するこ

とが期待されます。

82

特に、オープン・ソース・ライセンスの GPL83 ファミリーに対する信頼から、これを組込むブランド

の能力をモバイルアプリのような閉じた資産でコード化することが求められることもあります。ライ

センスのこうしたファミリーは Ethereum のような多くのブロック・チェーン・プロジェクトにおい

て一般的です。GPL ライセンスは、GPL に許可されたコードに由来するソフトウェアが同じライセン

スを採用するように要求されることを意味する、コピーレフトです。閉じたソースのアプリが例えば、

GPL に許可されたライブラリーを使用している場合、オープン・ソース自体にほとんどのブランドが

受理しない法的責任が要求される危険があります。

『オーブス』（Orbs）プラットフォームは明瞭なオープン・ソース方針を持っており、MIT ライセン

スのエコシステム内のみに依存します。84 これは、消費者アプリおよびそれらの商業資産に明示的に

影響を与えない、利用可能な最も寛大なオープン・ソース・ライセンスの 1 つです。GPL と異なり、

MIT に許可されたソフトウェアは、制限のない商用閉じた出所アプリケーションの中で使用すること

ができます。

秘密鍵の問題 暗号通貨はまだ主流消費市場に食い込んでいません。比較のために、Facebook、トップの消費者ブラ

ンドのうちの 1つは、今日世界で、20億以上のユーザーを持っています。85 かつて暗号通貨ウォレッ

トを操作したユーザーの総数は、世界的に 2000 万と評価されます。86 このギャップは多くの理由か

ら生じます。そのうちの 1つはエントリーの厳しい技術的な障壁です。

暗号通貨ウォレットへのアクセスは単一の秘密を知ることと同義です-ウォレットの秘密鍵です。こ

のキーは不変で、もし失われれば回復することができません。ランダムにキーを推測する試みから、

ウォレットを保護するために、高度のエントロピーは一般に使用されます;Bitcoin ウォレットは例え

ば 256 ビットのキーを使用します。

盗難、紛失から秘密鍵を保護することは容易なタスクではありません。消費者は、大きな組織が管理

するような強い暗号化キーを管理し保護し、かつパスワード、PIN コード、回復の質問、生物測定な

どのような単純な認証方法で必要な手続きを維持することができません。独力で単純な認証は認証情

報あるいは大きな資金のような価値のある財産の保護に安全でなく、遅れや、さまざまな認証の問題

(例えば、PIN コード、あるいはセキュリティ質問へのフォールバック機能を試みる)が蓄積されてお

り、多重要因認証、アクセス通知、時間錠、その他のような「実体経済」内の操作を含む認証プロト

コルの一部として通常使用されます。現在の技術によってこのようなプロトコルは集中リポジトリの

みで実行することができます (つまり、銀行のコンピュータ・システムは、失敗した PIN コード・エ

ントリーの試みの間の遅延を発生させることができますが、分散化されたブロック・チェーンではで

きません) 。

83 https://en.wikipedia.org/wiki/GNU_General_Public_License 84 https://en.wikipedia.org/wiki/MIT_License 85 https://newsroom.fb.com/company-info/ 86 http://jbs.cam.ac.uk/faculty-research/centres/alternative-finance/publications/global-cryptocurrency

83

分散化秘密保存 『オーブス』（Orbs）プラットフォームのユニークな斬新さのうちの 1 つは、プラットフォームその

ものが秘密(特に秘密の暗号化キー)を保存し使用することができるということです。これは、秘密共

有およびしきい値暗号を利用する新たなプロトコルを使用し、署名のようなオペレーションを可能に

するか、分散して保存されたキーを備えたドキュメントを解読して行われます。この機能性はありあ

まるほどの興味深い機能に門戸を開きます:ブロック・チェーンの単一の正統の署名を持った状態へ

の署名、他のブロック・チェーン上で実行された署名する処理、他の(接続された)ブロック・チェー

ンの状態の証明、第三者インフラストラクチャーの API 署名要請、またさらに多くが考えられます。

分散化秘密キーの興味深い使用例は分散的な方法で暗号的に強い秘密鍵を保存し、遅延、多重要因認

証、および消費者に人気のある他の方法を含む安全な認証プロトコルを実行することです-これは分

散的なプラットフォーム上で行われます。

このメカニズムに関する全ての詳細は個別の技術ホワイトペーパーの中で公表されます。

84

『オーブス』（Orbs）フェデレーション

『オーブス』（Orbs）プラットフォームの周辺で構築されたネットワークは、『オーブス』（Orbs）

の広告ターゲットを作る組織で主として構成されて、エコシステム参加者のコミュニティーとして構

想を描かれます。確立した消費者ブランドの消費者ビジネスを分散化されたブロック・チェーンへ移

行することを目指しています。例えば PumaPay、Zinc あるいは Kin のような組織、および ironSource

および Kik Interactive のような会社です。組織と会社グループはフェデレーションの独立した平等な

メンバーです。

『オーブス』（Orbs）フェデレーションにおけるメンバーの主要な役割は次のものを含んでいます:

● ネットワーク中のコンセンサスノードを操作しコンセンサスプロセスに積極的に参加する

こと。

● 『オーブス』（Orbs）のオープン・ソース開発に寄与し自分の必要条件として時間にわたる

プラットフォームを発展させること。

● プロトコルへの中核最新版上のコンセンサスに達するようなプラットフォームのために分散

化統制を提供すること。

事前公開設計パートナー

Orbs プラットフォームは、当初ニーズ主導アプローチで設計され、設計パートナーとの緊密な協力

が行われますこれらの設計パートナーの要件は、システムが設計されている反復プロセスを形作りま

す。イニシャルデザイン・パートナーは、さらに『オーブス』（Orbs）フェデレーションの設立メン

バーを務めて、コンセンサスノードの最初のセットを操作します。この最初のセットが、さらにプラ

ットフォームの最初の顧客、およびその上に作動する最初の分散化アプリケーションのデベロッパー

として働きます。

設計パートナーとの共同プロセスは、完全に開かれ透明に設計されています。プロセスで学習された

事項はすべて、『オーブス』（Orbs）コミュニティーのために公開チャンネル上で公表されます。

『オーブス』（Orbs）参照実装コードベースは GitHub 上で公開されたオープン・ソース・プロジェ

クトです。87 コードには MIT の自由ライセンスが提供されています。

87 https://github.com/orbs-network

85

自由な公共のために。『オーブス』（Orbs）エコシステムの新メンバーは、コードベースに寄与し、

かつノードの実行により『オーブス』（Orbs）フェデレーションの活動的なメンバーになるよう奨励

されます。

『オーブス』（Orbs）プロジェクトの役割はこの新しいエコシステムを開始することです。当初設計

は、このポジションペーパーおよび 1 セットの技術的なホワイトペーパーの公表による『オーブス』

（Orbs）コミュニティーに、およびコミュニティーが上に構築するために最初の参照オープン・ソー

ス実装を提供することにより提案されています。プロトコルが十分定義された場合、プラットフォー

ムを開始することができます。このイニシャルデザインは、さらに一旦フェデレーションが組織され

れば、プラットフォームを操縦する分散化統制に足場を供給します。分散的な性質に忠実に、プラッ

トフォームは『オーブス』（Orbs）など単一の組織によって管理されないでしょう。着手前の初期の

時期の指導的役割を越えて、『オーブス』（Orbs）プロジェクトは進行中の統制に関係しませんが、

他の参加者のように、分野での研究開発を継続し、フェデレーションが評価するためにプロトコル修

正を提案するでしょう。

統制 フェデレーションのモデルは産業で確立されており、Stellar や Ripple などのプロジェクトで原則とし

ては実証されました。集中統治機関が選ばれたメンバーを集合体に加えるコンソーシアムと異なり、

フェデレーションは集中統制のポイントを持っていません。機構と会社は、既存のメンバーのうちの

いくつかに接近し後援を求めることにより、集合体に参加することができます。新メンバーが他のメ

ンバーによって明示されれば、それらは最初のステータスを獲得します。

フェデレーションメンバーの主要な役割のうちの 1 つはコンセンサスノードの操作です。コンセンサ

スノードは仮想チェーンでアトランダムにコンセンサスプロセスに参加するために選ばれます。1 つ

のコンセンサスノードは、それ自体が様々な仮想チェーンのコンセンサスに参加できます。ノードの

コンセンサスに対する影響力および処理を有効にする能力の基準は、プロトコルによって管理されま

す。プロトコルは、高い SLA を維持するノードのためのいくつかの挙動を奨励します。それはノード

の評判としてコンセンサスプロセスの間に明示し、ネットワークにノードのコンセンサスによって分

散的に定義されています。評判は、さらに各ノードのプロトコル・アップグレードを評価しコンセン

サスすることへの参加も考慮します。『オーブス』（Orbs）プラットフォームはこれによって発展し

続けることができ、ユーザーに最先端技術のブロック・チェーン技術を提供し続けることができます。

86

注:このポジションペーパーは、ORB の基礎となるビジネスと技術の要点の最初の要約およびプラッ

トフォームを提供します。プロジェクト、および ORB プラットフォームの開発開始、ならびに ORB

プロジェクトが、修正、修正および(または)最新のドラフトとして、このドキュメントが以後変更さ

れることが予想されます。

定義

このポジションペーパーは以下のように定義された用語を使用します。-

● 「『オーブス』（Orbs）エコシステム」 - インフラストラクチャー市場上の第三者インフラ

ストラクチャー・デベロッパー提供サービスと一緒に、中核サービスを提供する『オーブ

ス』（Orbs）プラットフォームのコンビネーションを指す一般用語;「『オーブス』（Orbs）

エコシステム」セクションに述べられています。

● 「『オーブス』（Orbs）フェデレーション」 - プラットフォームに分散化統制を供給し、コ

ンセンサスノードを操作するエコシステム参加者の集合;「『オーブス』（Orbs）フェデレー

ション」セクションに述べられています。

● 「『オーブス』（Orbs）プラットフォーム」/「『オーブス』（Orbs）」 - サービスとしてア

プリケーションにインフラストラクチャーを供給する『オーブス』（Orbs）フェデレーショ

ンによって管理された分散的なネットワーク;「『オーブス』（Orbs）プラットフォーム」と

ラベルを付けられたセクションに述べられています。

● 「『オーブス』（Orbs）プロジェクト」/「弊社」-オーブズ株式会社およびその株主、オフ

ィサー、従業員およびコンサルタント、組織と、企業としてグループ文書、このペーパーを

作成し、またプロトコルのイニシャルデザインを公表し、分散化統制用の足場、一旦フェデ

レーションが組織されれば、プラットフォームを運営します。

● 「ORBS トークン」/「『オーブス』（Orbs）トークン」-インフラストラクチャー料金に払う

ために主としてアプリケーション開発者によって使用されるプラットフォーム費用を供給す

るトークン;「ORBSトークン」セクションに述べられています。

87

法的な免責

このポジションペーパーは情報のみを目的とし、変更の対象となります。弊社は、ステートメントあ

るいはこのポジションペーパーの中で達した結論の正確さを保証することができません。また、弊社

は次を含め表明保証条項(明示黙示、あるいは制定法によって、あるいはその他)をすべて放棄します:

● 市場性、特定目的に対する適合性、適応性、タイトルあるいは非侵犯に関係のある任意の表

現あるいは担保;

● このドキュメントの内容が正確で誤謬がないこと;そして

● 内容が第三者の権利を侵害しないこと。

弊社は、発生している損害の可能性を知らせられたとしても使用(このポジションペーパーの内容へ

の言及か信頼)から発生する損失あるいはダメージ(直接でも、間接、必然、あるいは他の種類の滅失

毀損)の義務を負わないものとします。

このポジションペーパーは、第三者データおよび産業出版物への言及を含んでいることがありまう。

弊社が知る限り、このポジションペーパーの中で再生された情報は正確であり、含まれていた評価と

仮定は合理的です。しかしながら、弊社はこのデータの正確さの完全性に関して保証しません。この

ポジションペーパーの中の情報とデータは、確かな情報源で得られたと考えられますが、弊社は、情

報を独立して確認していません。あるいは、このポジションペーパーの中で、第三者ソースからのデ

ータを参照した場合、基礎的前提が依存するとの確認は行われていません。

このポジションペーパーに含まれる「情報は、有益な目的だけのために意図され、任意の管轄権の中

で、アメリカまたはイスラエルを含み、任意の提示あるいはコミットメントの基礎を形成しないもの

とします。ここに含まれている任意の情報は、間接発行あるいは申し出、あるいはトークンを購入か

寄付する任意の勧誘、オーブズ株式会社あるいは任意の製品によって出された、あるいはオーブズ株

式会社によって提示されたサービス、または ORBS トークン取得の勧誘の部分を構成しないか形成し

ないものとまた解釈されるべきではありません。また、顧客は、もっぱらオーブズ株式会社と適格の

トークン購入者の間で作られた適用可能な協定に含まれる情報に基づいて、購入決定を下すべきです。

ORBS トークンが評価する『オーブス』（Orbs）に関しては、将来の業績あるいは価値の保証、ある

いはプラットフォームおよび(または)固有の価値の保証、支払いの保証および『オーブス』（Orbs）

プラットフォームおよび(または)ORBS トークンがなんらかの価値を特別に保持するだろうという保証

はなされません。予期される参加者が『オーブス』（Orbs）プラットフォーム、および『オーブス』

（Orbs）プラットフォームおよび獲得(ストレージ)の使用に関連した潜在的リスクの性質を完全に理

解せず受理せず、ORBS トークンに移行する場合、『オーブス』（Orbs）プラットフォームや購入を

使用、ORBSトークンを取得、購入、使用するべきではありません。

任意の法域で、このポジションペーパーは趣意書または開示のドキュメントを構成せず、売り出し、

投資あるいは金融手段の勧誘の申し出ではありません。0ORBS トークンは、インベストメント・リタ

ーンの見込みの目論見あるいは投資目的で購入すべきではありません。

88

このポジションペーパーは監督機関で検査を行っておらず、情報集合を承認していません。任意の管

轄権の法則、規則上必要な条件あるいは規則の下でこうした検査は規定されていません。このポジシ

ョンペーパーの公開、分配あるいは普及は、準拠法または規則上必要な条件が満たされたことを示唆

しません。

このようなトークンの所有権、使用あるいは所有に対する潜在的な制限を含む規制措置が『オーブ

ス』（Orbs）プラットフォームおよび(または)ORBS トークンに適用される場合があります。規制者あ

るいは他の主務官庁は、規則上必要な条件、他の政府の義務あるいはビジネス義務に応じるために弊

社がトークン配分の力学および(または)『オーブス』（Orbs）プラットフォームの機能を改訂するこ

とを要求する場合があります。しかしながら、弊社は、『オーブス』（Orbs）プラットフォームおよ

びトークン配分のオペレーションが適用法令を破らないことを保証するために、営利上適正措置をと

っていると考えています。

このポジションペーパーは、将来のイベントの弊社の現在の見込みに関係する、将来の予測について

のステートメントあるいは情報(集団的に「予測ステートメント」)を含んでいます。一部の場合には、

これらの予測ステートメントは「予測する」「でしょう」「期待する」、「予想する」「目指す」、

「評価」、「計画」「意図」、「求める」「考える」「潜在的な」、「継続する」、「可能性があ

る」、「予期する」などの用語によって識別することができますが、これらの用語の否定、あるいは

他の同様の表現も予測ステートメントとして識別されます。弊社のこれらの予測ステートメントは

『オーブス』（Orbs）プラットフォームのオペレーションに適切であると弊社が信じる、将来のイベ

ントおよび金融傾向に関する現在の見通しに基づきます。

ここで設定された問題に関係のあるステートメントに加えて、このポジションペーパーでは、『オー

ブス』（Orbs）プラットフォームの提案された運営モデルと関係する予測のステートメントを含んで

います。このモデルは弊社の目的のみとし、予算、将来の営業成績の見通しあるいは予測ではありま

せん。プラットフォーム・オペレーションおよび開発は『オーブス』（Orbs）フェデレーションの構

成に依存します。弊社は、その全体の中で意図した設計を支援し実現するために、十分なメンバーが

フェデレーションに加わることを保証することができません。

予測ステートメントは、ヒストリカル・トレンド(現在の状況)の経験および知覚に照らして『オーブ

ス』（Orbs）プロジェクト・チームによる仮定および分析に基づき、将来の開発、および適切で、危

険と不安定を蒙りやすいと弊社が信じる他の要因を予測しています。このポジションペーパーは予測

ステートメントを含みますが、弊社が合理的な仮定であると信じるものに基づく予測ステートメント

で明示、黙示、認識された見込みと弊社の実際の業績、実行、業績および(または)体験は危険、不安

定、仮定および他の要因で大きく場合があります。このようなリスクから、こうした予測ステートメ

ントを不適切な水準で信頼するべきではありません。