From ef03be4f9c6c89fd06e7ca27ac46066d693e336c Mon Sep 17 00:00:00 2001 From: junshin Date: Thu, 2 Aug 2018 16:39:09 +0900 Subject: [PATCH 1/4] Add Japanese Technical white paper --- README.md | 4 ++-- ja-JP/TechnicalWhitePaper.md | 0 2 files changed, 2 insertions(+), 2 deletions(-) create mode 100644 ja-JP/TechnicalWhitePaper.md diff --git a/README.md b/README.md index 5911f8a8..25fa2979 100644 --- a/README.md +++ b/README.md @@ -3,9 +3,9 @@ - [English](TechnicalWhitePaper.md) - [Russian](ru-RU/TechnicalWhitePaper.md) translated by [@blockchained](https://steemit.com/@blockchained) - [Chinese](zh-CN/TechnicalWhitePaper.md) translated by [@dayzh](https://steemit.com/@dayzh) -- [Korean](ko-KR/TechnicalWhitePaper.md) translated by [@clayop](https://steemit.com/@clayop) +- [Korean](ko-KR/TechnicalWhitePaper.md) translated by [@clayop](https://steemit.com/@clayop +- [Korean](ja-JP/TechnicalWhitePaper.md) translated by [@clayop](https://github.com/jun784) -# EOS Wiki - [English](https://github.com/EOSIO/eos/wiki) diff --git a/ja-JP/TechnicalWhitePaper.md b/ja-JP/TechnicalWhitePaper.md new file mode 100644 index 00000000..e69de29b From eab65feb6ba2d80e3a6caf5432587731201e91e6 Mon Sep 17 00:00:00 2001 From: junshin Date: Thu, 2 Aug 2018 16:42:07 +0900 Subject: [PATCH 2/4] add my account name --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 25fa2979..86b68dff 100644 --- a/README.md +++ b/README.md @@ -4,7 +4,7 @@ - [Russian](ru-RU/TechnicalWhitePaper.md) translated by [@blockchained](https://steemit.com/@blockchained) - [Chinese](zh-CN/TechnicalWhitePaper.md) translated by [@dayzh](https://steemit.com/@dayzh) - [Korean](ko-KR/TechnicalWhitePaper.md) translated by [@clayop](https://steemit.com/@clayop -- [Korean](ja-JP/TechnicalWhitePaper.md) translated by [@clayop](https://github.com/jun784) +- [Japanese](ja-JP/TechnicalWhitePaper.md) translated by [@junshin](https://github.com/@junshin) - [English](https://github.com/EOSIO/eos/wiki) From 6becaf4d28e4f745e1a1e42938bf0be60bd9c23c Mon Sep 17 00:00:00 2001 From: junshin Date: Thu, 2 Aug 2018 16:42:57 +0900 Subject: [PATCH 3/4] fixed readme --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 86b68dff..20a21910 100644 --- a/README.md +++ b/README.md @@ -3,7 +3,7 @@ - [English](TechnicalWhitePaper.md) - [Russian](ru-RU/TechnicalWhitePaper.md) translated by [@blockchained](https://steemit.com/@blockchained) - [Chinese](zh-CN/TechnicalWhitePaper.md) translated by [@dayzh](https://steemit.com/@dayzh) -- [Korean](ko-KR/TechnicalWhitePaper.md) translated by [@clayop](https://steemit.com/@clayop +- [Korean](ko-KR/TechnicalWhitePaper.md) translated by [@clayop](https://steemit.com/@clayop) - [Japanese](ja-JP/TechnicalWhitePaper.md) translated by [@junshin](https://github.com/@junshin) From 9369eae21a59129ad7d0302950c3c33113f04f10 Mon Sep 17 00:00:00 2001 From: junshin Date: Thu, 2 Aug 2018 16:43:38 +0900 Subject: [PATCH 4/4] Add Text --- ja-JP/TechnicalWhitePaper.md | 467 +++++++++++++++++++++++++++++++++++ 1 file changed, 467 insertions(+) diff --git a/ja-JP/TechnicalWhitePaper.md b/ja-JP/TechnicalWhitePaper.md index e69de29b..079636b5 100644 --- a/ja-JP/TechnicalWhitePaper.md +++ b/ja-JP/TechnicalWhitePaper.md @@ -0,0 +1,467 @@ +# EOS.IO テクニカルホワイトペーパー v2 + +**2018年3月16日** + +**要旨：** EOS.IOソフトウェアは分散アプリケーションを垂直/水平スケーリングを可能にするため設計された新しいブロックチェーンアーキテクチャを導入します。このアーキテクチャは、その上にアプリケーションを構築できるオペレーティングシステムのような構造を作ることにより完成しました。本ソフトウェアは、アプリケーションのアカウント、認証、データベース、非同期通信、スケジューリングを多数のCPUコアやクラスタ全体に提供します。その結果得られたテクノロジーは、管理されたブロックチェーンのコンテクストで、毎秒数100万トランザクションまで最終的にスケールし、ユーザ手数料がなく、分散アプリケーションの迅速かつ簡単なデプロイとメンテナンスが可能なブロックチェーンアーキテクチャです。 + +**注意： 本ホワイトペーパーで言う暗号トークンとは、EOS.IOソフトウェアを採用するローンチされたブロックチェーン上の暗号トークンのことを指します。この暗号トークンは、EOSトークンの配布に関係してETHEREUMブロックチェーン上で配布されているERC-20互換トークンを意味しません。** + +Copyright © 2018 block.one + +本ホワイトペーパーの資料は、原典および該当する著作権の引用を条件に、非商用、教育用(つまり手数料または商用目的以外のために)に限り許可を得ずに誰でも使用、複製、配布することができます。 + + +**免責:** 本EOS.IO テクニカルホワイトペーパーv2は情報目的専用です。block.one は、本ホワイトペーパーおよび到達した結論の正確性を保証しません。　本ホワイトペーパーは「AS IS」で提供されます。block.one は、明示暗黙、法律その他を問わず、(i) 商品性、特定目的への適合性、適切性、利用、権原もしくは非侵害性の保証、(ii) 本ホワイトペーパーの内容に誤りがないこと、および(iii) そのようなコンテンツが第三者の権利を侵害していないことを含みこれに限定されない、一切の表明保証を行わず、明示的に放棄します。block.oneおよびその関係会社は、本ホワイトペーパーもしくはそれに含まれる内容の利用、参照または信頼から生じた一切の損害賠償に対して、損害賠償の可能性が知らされた場合でも、責任を負いません。block.oneおよびその関係会社は、個人または法人に対し、本ホワイトペーパーまたはそれに含まれる内容の利用、参照または信頼に対する直接/間接を問わず、結果的、補償的、付随的、実質的、懲罰的、刑罰的または特殊一切の種類の損害賠償、損失、債務、費用または経費で、事業、収益、利益、データ、利用、営業権または他の無形物の損失を含みこれに限らないものに法的責任を負いません。 + + + +- [背景](#background) +- [ブロックチェーンアプリケーションに対する要求事項](#requirements-for-blockchain-applications) + * [大量ユーザ対応](#support-millions-of-users) + * [無料利用](#free-usage) + * [簡単なアップグレードとバグ修復](#easy-upgrades-and-bug-recovery) + * [低レイテンシー](#low-latency) + * [シーケンシャル性能](#sequential-performance) + * [パラレル性能](#parallel-performance) +- [コンセンサスアルゴリズム \(BFT-DPOS\)](#consensus-algorithm-bft-dpos) + * [トランザクションの確認](#transaction-confirmation) + * [プルーフ・オブ・ステークとしてのトランザクション \(TaPoS\)](#transaction-as-proof-of-stake-tapos) +- [アカウント](#accounts) + * [アクションとハンドラ](#actions--handlers) + * [ロールベースのパーミション管理](#role-based-permission-management) + + [名前付きパーミションレベル](#named-permission-levels) + + [パーミションマッピング](#permission-mapping) + + [パーミションの評価](#evaluating-permissions) + - [デフォールトパーミショングループ](#default-permission-groups) + - [パーミションのパラレル評価](#parallel-evaluation-of-permissions) + * [強制遅延付きアクション](#actions-with-mandatory-delay) + * [盗難された鍵からの修復](#recovery-from-stolen-keys) +- [アプリケーションの決定的な並列実行](#deterministic-parallel-execution-of-applications) + * [通信レイテンシーの最小化](#minimizing-communication-latency) + * [リードオンリーのアクションハンドラ](#read-only -action-handlers) + * [複数アカウントに関するアトミックトランザクション](#atomic-transactions-with-multiple-accounts) + * [ブロックチェーン状態の部分評価](#partial-evaluation-of-blockchain-state) + * [主観的ベストエフォットスケジューリング](#subjective-best-effort-scheduling) + * [遅延トランザクション](#deferred-transactions) + * [コンテクストフリーなアクション](#context-free-actions) +- [トークンモデルとリソース使用](#token-model-and-resource-usage) + * [客観/主観測定](#objective-and-subjective-measurements) + * [受信者払](#receiver-pays) + * [キャパシティの委任](#delegating-capacity) + * [トークンバリューからのトランザクション費用の分離](#separating-transaction-costs-from-token-value) + * [状態ストレージの費用](#state-storage-costs) + * [ブロックリワード](#block-rewards) + * [ワーカープロポーザルシステム](#worker-proposal-system) +- [ガバナンス](#governance) + * [アカウントの凍結](#freezing-accounts) + * [アカウントコードの変更](#changing-account-code) + * [憲法](#constitution) + * [プロトコルと憲法のアップグレード](#upgrading-the-protocol--constitution) + + [緊急時の変更](#emergency-changes) +- [スクリプトと仮想マシン](#scripts--virtual-machines) + * [スキーマ定義されたアクション](#schema-defined-actions) + * [スキーマ定義されたデータベース](#schema-defined-database) + * [汎用マルチインデックスデータベースAPI](#generic-multi-index-database-api) + * [アプリケーションからの認証の分離](#separating-authentication-from-application) +- [ブロックチェーン間通信](#inter-ブロックチェーン-communication) + * [軽量クライアント検証 \(LCV\)のための用のマークル・プルーフ](#merkle-proofs-for-light-client-validation-lcv) + * [チェーン間通信のレイテンシー](#latency-of-interchain-communication) + * [完全性の証明](#proof-of-completeness) + * [分離された署名情報 ](#segregated-witness) +- [結論](#conclusion) + + + +# 背景 + +ブロックチェーン技術は、2008年、Bitcoin通貨のローンチと共に導入されました。それ以降、起業家と開発者は、一つのブロックチェーンプラットフォーム上で幅広いアプリケーションに対応するため、本技術を一般化しようとしています。 + +多くのブロックチェーンプラットフォームは機能分散したアプリケーションに対応しようとしていますが、BItshares分散取引所(2014)やSteemソーシャルメディアプラットフォーム(2016)などのアプリケーション専用ブロックチェーンは、毎日アクティブユーザ数万人に使用されるブロックチェーンになりました。これは、毎秒数千トランザクションまで性能を向上させ、レイテンシーを1.5秒に短縮し、トランザクション毎の手数料をなくし、既存集中型サービスが現在提供しているのと同様のユーザエクスペリエンスを提供することによって達成されました。 + +既存ブロックチェーンプラットフォームは多額の手数料と限られた計算キャパシティが負担となり、ブロックチェーン採用の普及を妨げています。 + +#ブロックチェーンアプリケーションに対する要求事項 + +普及のためにはブロックチェーン上のアプリケーションには次の要求を満たす十分柔軟なプラットフォームが必要です。 + +## 大量ユーザ対応 + +eBay、Uber、AirBnB、Facebookなどの企業と競争するには、毎日のアクティブユーザ数千万人を処理できるブロックチェーン技術が必要です。ユーザがクリティカルマスに到達しなければ、アプリケーションは機能しないかも知れません。従って、非常に大量のユーザを扱えるプラットフォームが最重要です。 + +## 無料利用 + +ユーザに無料サービスを提供する柔軟性がアプリケーション開発者には必要です。ユーザはプラットフォーム利用やサービスから恩恵を得るために支払いが必要であるべきではありません。ユーザが無料で利用可能はブロックチェーンプラットフォームは普及する可能性があります。その後、開発者と企業は効果的なマネタイゼーション戦略を創出できます。 + +## 簡単なアップグレードとバグ修復 + +ブロックチェーンベースのアプリケーションを構築する企業は、新機能でアプリケーションを改善する柔軟性が必要です。プラットフォームはソフトウェアとスマートコントラクトのアップグレードに対応しなければなりません。 + +自明でないソフトウェアは最も厳密に正式の検証を行ってもバグに影響されます。プラットフォームは、バグ発生が避けられないので、バグ修正するため十分頑丈でなければなりません。 + +## 低レイテンシー + +優れたユーザエクスペリエンスには、信頼できる遅延1秒以下の反応が求められます。遅延が大きいとユーザは苛立ち、ブロックチェーン上に構築されるアプリケーションは非ブロックチェーンの代替既存アプリケーションに対しての競争力が無くなります。プラットフォームは低レイテンシーのトランザクションに対応すべきです。 + +## シーケンシャル性能 + +アプリケーションの中には、シーケンシャルに依存した手順のため、並列アルゴリズムで実装できないものがあります。取引所のようなアプリケーションでは、大量処理のために十分なシーケンシャル性能が必要です。従って、プラットフォームは高速シーケンシャル性能に対応しなければなりません。 + +## パラレル性能 + +大規模アプリケーションでは、複数のCPUとコンピュータ全体にワークロードを分ける必要があります。 + +# コンセンサスアルゴリズム (BFT-DPOS) + +EOS.IOソフトウェアはブロックチェーン上のアプリケーションの性能要件を満たせることが証明された既知の分散型コンセンサスアルゴリズム [委任されたプルーフ・オブ・ステーク (DPOS)](https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper)だけを利用します。このアルゴリズムに基づいて、EOS.IOソフトウェアを採用したブロックチェーン上のトークンホルダーは継続的承認投票システムを使ってブロック生成者を選出できます。誰でもブロック生成への参加を選択でき、ブロックを生成するチャンスが与えられます。ただし、トークンホルダーに対し自分に投票するよう説得できます。 + +EOS.IOソフトウェアでは、ブロックが正確に0.5秒毎に生成され、いつの時点でも生成者がちょうど1人だけブロック1つを生成する権限を与えられます。ブロックが予定時刻に生成されないと、そのタイムスロットのブロックはスキップされます。1つ以上のブロックがスキップされたら、ブロックチェーンには0.5秒以上のギャップがあります。 + +EOS.IOソフトウェアを使えば、ブロックは126単位で生成されます(各6ブロック×生成者21人)。各ラウンドの開始時点で、トークンホルダーによる投票の選択により21の重複しないブロック生成者が選ばれます。選出された生成者は15人以上の生成者により合意された順にスケジュールされます。 + +生成者がブロックを逃し、過去24時間以内にブロックを生成していない場合、ブロックを再び生成を開始する意図をブロックチェーンに通知するまで、検討から外されます。こうすることで、信頼できないと分かった生成者をスケジューリングしないことにより逃がしたブロック数を最小にして、ネットワークのスムーズな運用を保証します。 + +ブロック生成者はブロック生成のため競争するより協力するので、正常な条件ではDPOS ブロックチェーンにフォークは発生しません。フォークする場合、コンセンサスは自動的に長い方のチェーンにスイッチします。ブロックがブロックチェーンフォークに追加される割合は、同一コンセンサスを共有するブロック生成者の割合に直接的相互関連するので、この方法は有効です。別の言い方をすれば、生成者が多いブロックチェーンのフォークでは失われるブロックに遭遇することが少ないので、生成者が少ないフォークより速く長さが成長します。 + +またブロック生成者は同時に2つのフォーク上でブロックを生成してはなりません。このような行為を見つかったブロック生成者は投票で追放されるでしょう。そのような二重生成の暗号的証拠も乱用者を自動的に除去するため使用できます。 + +同一タイムスタンプまたはブロックの高さを持つ２つのブロックに署名する生成者が存在しない限り、全生成者に全ブロックへの署名を許すことによって、ビザンチンフォールトトレラント性が従来のDPOSに追加されます。生成者15人がブロックに署名すれば、そのブロックは取消不可能とみなされます。ビザンチン生成者は同一タイムスタンプまたはブロックの高さを持つ2ブロックに署名することによって、自らの反逆の暗号的証拠を生成する必要があります。このモデルでは、取消不可能なコンセンサスは1秒以内に到達可能であるはずです。 + +## トランザクションの確認 + +典型的なDPOSブロックチェーンにはブロック生成者が100％参加します。トランザクションは、ブロードキャストから平均0.25秒後に99.9%の確度で確認されたとみなせます。 + +DPOSに加え、取消不可能性を高速に達成するため、EOS.IOは非同期ビザンチンフォールトトレラント性 (aBFT)を追加します。aBFTアルゴリズムは1秒以内に取消不可能性の確認を100%行います。 + +## プルーフ・オブ・ステークとしてのトランザクション (TaPoS) + +EOS.IOソフトウェアでは全トランザクションに最近のブロックヘッダのハッシュの一部を含むことを要求します。このハッシュは二つの役に立ちます。 + +1. 参照されたブロックを含まないフォーク上でトランザクションのリプレイ防止、および +2. 特定ユーザとそのステークが特定フォーク上に存在することのネットワークへの通知。 + +偽造チェーンは正規チェーンからトランザクションを移行できないので、偽造チェーン作成を困難にするブロックチェーンをいずれ全ユーザは直接確認することになります。 + +# アカウント + +EOS.IOソフトウェアでは、全アカウントは最長12文字の人間可読なユニークな名前で参照できます。この名前はアカウント作成者により選ばれます。アカウント作成者は、新規アカウントが自身のRAMを予約するためトークンをステークするまで、新アカウントを格納するRAMを確保しなければなりません。 + +分散されたコンテクストでは、アプリケーション開発者は新規ユーザを参加させるためアカウント作成の僅かな費用を支払います。従来の企業では、広告、無料サービスなどという形で獲得顧客毎に相当な金額を既に費やしています。新規ブロックチェーンアカウントに資金提供するコストは、それと比較すれば大したことはありません。幸いなことに、別のアプリケーションで既に参加済みのユーザはアカウント作成は不要です。 + +## アクションとハンドラ + +各アカウントは他アカウントに構造化アクションを送信でき、受信された時にアクションを処理するスクリプトを定義できます。EOS.IOソフトウェアは各アカウントに自身のアクションハンドラだけがアクセスできる独自のプライベートデータベースを与えます。アクション処理スクリプトはアクションを他のアカウントに送信することもできます。アクションと自動アクションハンドラの組合せが、EOS.IOがスマートコントラクトを定義する方法です。 + +並列実行に対応するため、各アカウントはデータベース内にスコープをいくつでも定義できます。ブロック生成者は、スコープへのメモリアクセスで競合しないようトランザクションをスケジュールするので、並列実行が可能です。 + +## ロールベースのパーミション管理 + +パーミション管理はアクションが適切な権限を与えられているかの判断に関係します。パーミション管理の一番簡単な形式は、トランザクションが必須の署名を持つことの確認ですが、これは要求された署名が既知であることを意味します。一般に、オーソリティは個人または個人のグループに制限され、よくコンパートメント化されます。EOS.IOソフトウェアは宣言的なパーミション管理システムを提供し、誰がいつ何を実行できるかを細かく高レベルの制御をアカウントに与えることができます。 + +認証とパーミションの管理を標準化しアプリケーションのビジネスロジックから分離することが重要です。こうすることで、汎用目的のパーミッション管理を行うツール開発が可能になり、性能を最適化する十分なチャンスがあります。 + +全アカウントは他のアカウントと秘密鍵の重み付けられた組合せで制御できます。これによりパーミッションが現実にどのように構成されているか反映し、今まで以上にアカウントのマルチユーザ制御を簡単にする階層的なオーソリティ構造が作成されます。マルチユーザ制御は単独でセキュリティに最も寄与し、適切に使えばハッキングによる盗難の恐れを激減できます。 + +EOS.IOソフトウェアではアカウントが鍵および/またはアカウントのどのような組合せがあるアクションタイプを別アカウントに送信できるか定義できます。例えば、ある鍵をユーザのソーシャルメディアアカウント用に、別の鍵を取引所のアクセス用に持てます。さらに他のアカウントにパーミッションを与え、鍵を割り当てないでユーザアカウントを代理することさえ可能です。 + +### 名前付きパーミションレベル + + + +EOS.IOソフトウェアを使用して、アカウントに名前付きパーミッションレベルを定義でき、そのそれぞれは高レベルな名前付きパーミションから導かれます。名前付きパーミッションレベルには、オーソリティが定義されます。 オーソリティは他のアカウントの鍵および/または名前付きパーミションレベルからなる閾値のある複数署名の確認です。例えば、アカウントの「友達」パーミッションレベルは、アカウントの友達の誰でも平等に制御されるアカウントに関するアクションに設定できます。 + +別の例はSteem ブロックチェーンで、オーナー、アクティブ、ポスティングの3種類のハードコーディングされた名前付きパーミッションレベルがあります。ポスティングパーミッションは投票と投稿などのソーシャルアクションしか実行できず、 アクティブパーミッションではオーナー変更以外の全てを実行できます。オーナーパーミッションはコールドストレージ用で全てを実行できます。EOS.IOソフトウェアは、各アカウントホルダーにアクションの独自の階層とグルーピングを定義させ、この概念を一般化しています。 + +### パーミションマッピング + +EOS.IOソフトウェアでは、各アカウントがコントラクト/アクションもしくは他のアカウントのコントラクトと自分自身の名前付きパーミッションレベルとの間のマッピングを定義できます。例えば、アカウントホルダーはアカウントホルダーのソーシャルメディアアプリケーションをアカウントホルダーの「友達」パーミッショングループにマッピングできます。このマッピングを使えば、友達はソーシャルメディアにアカウントホルダーとして投稿できます。アカウントホルダーとして投稿しますが、このアクションの署名には自分の鍵を使用します。これは、どの友達がアカウントをどのように使ったか、常に識別できることを意味します。 + +### パーミションの評価 + +「**アクション**」タイプのアクションを**@alice**から **@bob**へ配信する場合、EOS.IOソフトウェアは最初に **@alice** が**@bob.groupa.subgroup.アクション**に対するパーミッションマッピングを定義しているかどうかを確認します。何も見つからなかった場合、**@bob.groupa.subgroup** に対するマッピング、次に **@bob.groupa**、そして最後に **@bob** が確認されます。さらにマッチが見つからなかった場合、仮定するマッピングは名前付きパーミッショングループ **@alice.active**になります。 + +マッピングが特定されたら、署名するオーソリティは閾値複数署名プロセスと名前付きパーミションと関連するオーソリティで検証されます。これに失敗した場合、親のパーミッションへ移動し、最終的にはオーナーパーミッション **@alice.owner**まで移動します。 + + + +#### デフォールトパーミショングループ + +EOS.IO テクノロジーでも、全アカウントが全てを実行できる「オーナー」グループ、オーナーグループの変更以外の全てを実行できる「アクティブ」グループを持てます。他のパーミッショングループは全て「アクティブ」から導かれます。 + +#### パーミションのパラレル評価 + +パーミッション評価プロセスは「リードオンリー」で、トランザクションにより行われるパーミション変更はブロックの終了まで効果はありません。これは、全トランザクションに対する全ての鍵とパーミッション評価を並列実行できることを意味します。また ロールバックする必要があるコストの高いアプリケーションロジックを開始せずにパーミションを素早く検証可能であることも意味します。最後に、トランザクションパーミッションは保留トランザクションを受信しながら評価でき、適用時に再評価する必要がないことも意味します。 + +全てを考慮すると、パーミッション検証はトランザクションの検証に必要な計算能力の相当な割合となります。これをリードオンリーにすれば、自明に並列化可能なプロセスの性能が劇的に増加できます。 + +アクションのログから決定性状態を再生するためブロックチェーンをリプレイする場合、パーミッションの再評価は不要です。トランザクションが既知の正しいブロックに含まれている事実があれば、このステップはスキップできます。これにより、成長し続けるブロックチェーンのリプレイに関連した計算能力の負荷を激減します。 + +## 強制遅延付きアクション + +時間はセキュリティの重要な要素です。多くの場合、秘密鍵が盗まれたかどうかは使用されるまでわかりません。タイムベースのセキュリティは、日常の使用のためにインターネット接続されたコンピュータに鍵の保存が必要なアプリケーションがある場合は更に重要です。EOS.IOソフトウェアでは、あるアクションは、ブロックに含まれた後、適用前に最低一定時間待つ必要があることをアプリケーション開発者が示すことができます。この時間中ならアクションは取り消せます。 + +その後、ユーザはこのアクションの一つがブロードキャストされた時に、メールまたはショートメッセージで通知を受け取ることができます。アクションが権限を与えない場合、アカウントリカバリープロセスを使って、アカウントを修復し、アクションを撤回することが可能です。 + +必要な遅延は操作のデリケートさに依存します。コーヒーの支払いなら遅延なく数秒後には取消不可能ですが、家を買う場合には72時間の清算時間が必要かもしれません。全アカウントを新しい管理に移動するには30日かかるかもしれません。正確な遅延はアプリケーション開発者とユーザにより選ばれます。 + +## 盗難された鍵からの修復 + +EOS.IOソフトウェアは、鍵の盗難時にユーザがアカウントを修復する方法を提供します。アカウントオーナーは、過去30日内にアクティブだったオーナー鍵と指定されたアカウント修復パートナーの承諾を使って、自分のアカウントのオーナー鍵をリセットできます。アカウント修復パートナーはオーナーの手助けなしにはアカウントの管理をリセットできません。 + +既にアカウントを「管理」しているので、ハッカーが修復プロセスを調べても何も得るものはありません。さらにこのプロセスを通り抜けても、修復パートナーは身分証明や多要素認証(電話とメール)を求めるでしょう。これにより、ハッカーをコンプロマイズするか、ハッカーはプロセスで何も得ないでしょう。 + +このプロセスは単純な複数署名の仕組みとは大きく異なります。複数署名トランザクションでは、別の実体が実行されるトランザクション全てに関係させられます。これとは対照的に修復プロセスに関しては修復パートナーは修復プロセスだけに関係し、日常のトランザクションには権限がありません。これによって、関係者全員のコストと法的責任は激減します。 + + +# アプリケーションの決定的な並列実行 + +ブロックチェーンのコンセンサスは決定的(再生可能) な振舞いに依存します。これは、全ての並列実行で排他制御や他のロックプリミティブがあってはならないことを意味します。ロックを使わない場合、並列実行される可能性があるトランザクションが非決定的な結果とならないことを保証する何らかの方法が必要です。 + +EOS.IOソフトウェアの2018年6月リリースはシングルスレッド実行ですが、将来のマルチスレッド並列実行に必要なデータ構造を含んでいます。 + +EOS.IOソフトウェアベースのブロックチェーンでは、並列操作が有効になれば、並列に評価できるよう独立したシャードへのアクション配信を構成するのはブロック生成者の仕事になります。このスケジュールはブロック生成者が出力し、決定的に実行されますが、スケジュール生成プロセスは決定的である必要はありません。これはブロック生成者は並列アルゴリズムを活用してトランザクションをスケジュールできることを意味します。 + +並列実行の一部とは、スクリプトが新しいアクションを生成する時、即座に配信されず代わりに次サイクルで配信されるようスケジュールされることを意味します。即座に配信できない理由は、受信者が別のシャードで自分自身の状態を実際に変更している可能性があるからです。 + + +## 通知遅延の最小化 + +レイテンシーはあるアカウントが別のアカウントにアクションを送信し、応答を受け取るのに要する時間です。目標は、２アカウントがアクション間で0.5秒待たずにアクションを1ブロック以内で相互に交換できることです。これを可能にするため、EOS.IOソフトウェアは各ブロックをサイクルに分割します。各サイクルはシャードに分割され、各シャードはトランザクションのリストを含みます。各トランザクションには配信予定のアクションの集合が含まれます。この構造は、交互のレイヤがシーケンシャルおよびパラレルに処理されるツリーとして視覚化できます。 + + ブロック + + リージョン + + サイクル (シーケンシャル) + + シャード (パラレル) + + トランザクション (シーケンシャル) + + アクション (シーケンシャル) + + 受信者と通知されたアカウント(パラレル) + +1サイクルで生成されたトランザクションは、その後のサイクルまたはブロック内で配信可能です。ブロック生成者は、最大実時間が経過する、または配信すべき新規生成されたトランザクションがなくなるまで、ブロックにサイクルを追加し続けます。 + +ブロックの静的分析を使って、２つのシャードに同じアカウントを修正するトランザクションがあるサイクル内に含まれないことを検証できます。これが不変として維持される限り、ブロックは全シャードを並列実行させ処理できます。 + + +## リードオンリー アクションハンドラ + +内部状態を修正せずに成功/失敗ベースでアクションを処理できるアカウントがあります。このような場合、このハンドラは特定アカウントのリードオンリー アクションハンドラ―が特定サイクル内の1つ以上のシャードに含まれている限り、並列実行できます。 + +## 複数アカウントに関するアトミックトランザクション + +アクションが複数アカウントへ配信され、それらによる自動的な受信を保証することが要求される場合があります。この場合、両方のアクションが１トランザクションに入り、両アカウントは同じシャードに割り当てられ、アクションがシーケンシャルに適用されます。 + +## ブロックチェーン状態の部分評価 + +ブロックチェーン技術をスケールするには、コンポーネントのモジュール化が必須です。特にアプリケーションのごく一部しか使う必要がない場合、全員が全てを実行する必要がないようにすべきです。 + +取引所アプリケーションの開発者は、取引所の状態をユーザに表示する目的でフルノードを実行します。この取引所アプリケーションにはソーシャルメディアアプリケーションに関連した状態は不要です。EOS.IOソフトウェアでは、フルノードが実行予定アプリケーションのサブセットを選ぶことができます。他のアプリケーションに配信されたアクションは、アプリケーションが他のコントラクトの状態に依存することがなければ、安全に無視できます。 + + +## 主観的ベストエフォットスケジューリング + +EOS.IOソフトウェアではブロック生成者が他のアカウントにアクション送信を義務付けることはできません。各ブロック生成者はトランザクションを処理するため必要な計算の複雑さと時間を独自に主観的に測定します。これは、トランザクションがユーザにより生成されたか、スマートコントラクトにより自動生成されたかによらず当てはまります。 + +EOS.IOソフトウェアを採用するローンチされたブロックチェーンに関して、ネットワークレベルでは実行WASM命令数ベースの計算能力の帯域コストを全トランザクションは請求されます。一方、本ソフトウェアを使用している個々のブロック生成者は、独自のアルゴリズムまたは測定を使ってリソース使用を計算できます。あるトランザクション又はアカウントが計算キャパシティの不相応な量を消費したとブロック生成者が判断した場合、自分のブロックを生成する時にそのトランザクションを単純に拒否します。 しかし、他のブロック生成者が有効とみなす場合、そのトランザクションはさらに処理します。 + +一般に、ブロック生成者が一人でもトランザクションを有効でリソース使用制限以下であるとみなす限り、他のブロック生成者全員もそれを受け入れますが、そのトランザクションが生成者を見つけるには最大1分かかるかも知れません。 + +生成者は許容範囲の10倍を超えるトランザクションを含むブロックを生成する場合もあります。この場合、次のブロック生成者はそのブロックの拒否を選択することができ、この問題は三番目の生成者が解決することになります。大きなブロックがネットワークの伝搬遅延の原因となった場合に起こることと違いはありません。コミュニティは乱用パターンに気付き、最終的には不良生成者からの投票を取り除きます。 + +この 計算コストの主観的評価は、何かの実行にどれだけ時間がかかるのか正確かつ決定的にブロックチェーンが測定することを不要にします。この設計を使えば、コンセンサスを裏切ることなく、最適化のチャンスを劇的に増やす命令の正確なカウントは不要です。 + +## 遅延トランザクション + +EOS.IOソフトウェアでは、将来実行がスケジュールされる遅延トランザクションに対応しています。これによって、計算能力の別のシャードへの移動および/または連続トランザクションを継続的にスケジュールする長時間実行するプロセスの作成が可能になります。 + +## コンテクストフリーなアクション + +コンテクストフリーなアクションはトランザクションデータにだけ依存し、ブロックチェーン状態には依存しない計算能力が関係します。例えば、署名検証は、トランザクションを署名した公開鍵を決定するためにトランザクションデータと署名だけが必要な計算です。これはブロックチェーンが実行しなければならない最も重い個別計算の一つですが、この計算はコンテクストフリーであるので並列実行が可能です。 + +コンテクストフリーなアクションは、検証を行うためにブロックチェーン状態へのアクセスがないことを除き、他のユーザアクションと似ています。これによりEOS.IOは並列に署名検証など、全てのコンテクストフリーなアクションを処理できるだけではなく、更に重要なことですが、一般化された署名検証も可能です。 + +コンテクストフリーなアクション対応により、Sharding、Raiden、Plasma、State Channelsや他のスケーラビリティ技術が更に並列可能で実用的になりました。この結果、効率的なブロックチェーン間通信と無制限の可能性があるスケーラビリティが可能になります。 + +# トークンモデルとリソース使用 + +**注意： 本ホワイトペーパーで言う暗号トークンとは、EOS.IOソフトウェアを採用するローンチされたブロックチェーン上の暗号トークンのことを指します。この暗号トークンは、EOSトークンの配布に関係してETHEREUMブロックチェーン上で配布されているERC-20互換トークンを意味しません。** + +全てのブロックチェーンにはリソース制約があり、乱用を防止するシステムが必要です。EOS.IOソフトウェアを使用するブロックチェーンには、アプリケーションにより消費される範囲が広いリソースクラスが3つあります。 + +1. 帯域幅とログ用ストレージ (ディスク)、 +2. 計算能力と計算バックログ (CPU)、および +3. 状態ストレージ (RAM)。 + +帯域幅と計算能力には、即時利用と長期利用の２つの部分があります。ブロックチェーンは全アクションのログを維持し、このログは最終的に全てのフルノードにより格納されダウンロードされます。アクションのログを使って、全アプリケーションの状態を再構築できます。 + +計算の負債(computational debt)とは、状態を再生するため、アクションログから実行する必要がある計算のことです。計算の負債が大きくなりすぎると、ブロックチェーン状態のスナップショットを取り、ブロックチェーンの履歴を破棄する必要があります。計算の負債が急激に大きくなると、1年相当のトランザクションのリプレイに6ヵ月かかるかも知れません。従って、計算の負債は慎重な管理が不可欠です。 + +ブロックチェーンの状態ストレージはアプリケーションロジックからアクセス可能な情報です。それには注文控えや口座残高などの情報が含まれます。この状態がアプリケーションにより読み取られることがなければ、格納すべきではありません。例えば、ブログ投稿コンテンツとコメントはアプリケーションロジックで読み込まれないので、ブロックチェーン状態に格納すべきではありません。一方、記事/コメントの存在、投票数および他の属性はブロックチェーンの状態の一部として格納されます。 + +ブロック生成者は帯域幅、計算能力、状態の利用可能なキャパシティを公開します。EOS.IOソフトウェアでは、各アカウントが利用可能なキャパシティのある割合を3日のステーキングコントラクトで所持されたトークン量に比例して消費できます。例えば、EOS.IOソフトウェアベースのブロックチェーンがローンチされ、そのブロックチェーンに従った分配可能な全トークンの1％をアカウントが所有する場合、そのアカウントは状態ストレージキャパシティの1％を利用する可能性があります。 + +ローンチされたブロックチェーン上でのEOS.IOソフトウェアの採用は、帯域幅と計算能力のキャパシティは一時的なので、部分準備ベースで割り当てられることを意味します(未使用キャパシティは将来使うために保存できません)。EOS.IOソフトウェアで使用されるアルゴリズムは、Steemにより使用されるアルゴリズムと類似しており、帯域使用をレート制限します。 + +## 客観/主観測定 + +前に検討した通り、計算の利用の計測は性能と最適化に大きな影響があります。 従って、全てのリソース使用の制約は最終的には主観的で、ブロック生成者により個々のアルゴリズムと推定に従って実施されます。通常、これはブロック生成者がカスタムプラグインを作成して実装します。 + +そうは言っても、客観測定が自明なものがあります。配信されたアクション数、内部データベースに格納されるデータサイズは客観的な測定は簡単です。EOS.IOソフトウェアでは、ブロック生成者が同一アルゴリズムをこの客観測定全体に適用できますが、主観測定全体には厳密な主観的アルゴリズムの適用を選択できます。 + +## 受信者払 + +従来より、オフィススペース、計算パワー、事業運営のために必要な他の費用は企業が支払っています。顧客は個別の製品を企業から購入し、その製品販売からの収益は運営の事業コストをまかなうため使用されます。同様に、ホスティング費をまかなうためにウェブサイト訪問に対して訪問者にマイクロペイメントを義務付けるウェブサイトは存在しません。従って、分散型アプリケーションはブロックチェーン使用に対して直接ブロックチェーンに支払うよう顧客に強制すべきではありません。 + +EOS.IOソフトウェアを使用するローンチされたブロックチェーンでは、その利用に対してユーザは直接ブロックチェーンに支払う必要がありません。従って、製品の独自マネタイゼーション戦略の決定することから企業を制限したり妨げることはありません + +確かに受信者は支払えますが、EOS.IOでは送信者が帯域幅、計算能力、ストレージを支払うことができます。これにより、アプリケーション開発者は自らのアプリケーションに最適な方法を選ぶことができます。多くの場合、送信者払は、独自の割当システムを実現したくないアプリケーション開発者の複雑さを大幅に減少させます。アプリケーション開発者は帯域幅と計算能力をユーザに委任でき、「送信者払」モデルに使用を強制させます。これはエンドユーザ観点からは無料ですが、ブロックチェーンの観点からは送信者払です。 + +## キャパシティの委任 + +EOS.IOソフトウェアを採用してローンチされたブロックチェーン上のトークンホルダーで、利用可能な帯域幅の全部または一部をすぐに消費する必要がない可能性がある者は、消費しない帯域幅を他人に委任または貸与できます。そのようなブロックチェーンでEOS.IOソフトウェアを実行するブロック生成者はキャパシティのこの委任を認識し、帯域幅を割り当てます。 + +## トークンバリューからのトランザクション費用の分離 + +EOS.IOソフトウェアの主要なメリットの一つは、アプリケーションで利用可能な帯域幅の量はトークン価格から完全に独立していることです。アプリケーションオーナーがEOS.IOソフトウェアを採用するブロックチェーン上に関連する数のトークンを保持する場合、アプリケーションは固定された状態と帯域利用の範囲内でいつまでも実行できます。この場合、開発者とユーザはトークン市場価格の不安定さに影響されず、従って価格フィードに依存しません。言い換えれば、EOS.IOソフトウェアを採用するブロックチェーンでは、ブロック生成者がトークンの価値とは独立にトークンあたり利用可能な帯域幅、計算能力、ストレージを自然に増やせます。 + + EOS.IOソフトウェアを使用するブロックチェーンもブロック生成者がブロック作成するたびにトークンを付与します。トークンのバリューは生成者が購入可能な帯域幅、ストレージ、計算能力の量に影響を与えます。 このモデルはネットワーク性能を拡大するため当然トークンバリューの上昇を活用します。 + +## 状態ストレージの費用 + +帯域幅と計算能力は委任できますが、アプリケーション状態のストレージ は状態が削除されるまでアプリケーション開発者がトークンを保持しなければなりません。状態が削除されることがなければ、そのトークンは流通から実質的に取り除かれます。 + +## ブロックリワード + +EOS.IOソフトウェアを採用するブロックチェーンは、ブロックが生成されるたびに新しいトークンをブロック生成者に付与します。このような状況では、作成されるトークン数はブロック生成者により公開される希望報酬の中央値により決定されます。EOS.IOソフトウェアは、トークン供給の年間全体増加が5％を超えないよう、生成者の付与に上限を強制するよう構成できます。 + +## ワーカープロポーザルシステム + +ブロック生成者の選出に加え、EOS.IOソフトウェアベースのブロックチェーンに従って、トークンホルダーはコミュニティの利益になるよう設計された多数のワーカープロポーザルを選出できます。当選したプロポーザルには、トークンインフレーションの構成された割合までのトークンからブロック生成者に支払われたトークンを引いたものを受け取ります。これらのプロポーザルは、各応募がトークンホルダーから受け取った投票に比例するトークンで、ワークを行うため要求する量までを受け取ります。選出されたプロポーザルはトークンホルダーによって新たに選出されたプロポーザルで置き換えることができます。 + +ワーカープロポーザルを実装するシステムコントラクトは2018年6月の初回ローンチでは実施されないかもしれませんが、資金調達機構は実施されます。ブロック生成者の付与開始と同時に、資金の蓄積を開始します。ワーカープロポーザルシステムはWASMに実装する予定で、後日フォークなしに追加できます。 + + +# ガバナンス + +ガバナンスとはコミュニティの人々による次のプロセスのことです。 + +1. ソフトウェアアルゴリズムで完全に捕捉できない集団行動の主観的事項に関するコンセンサスを得ること、 +2. 決定を実行すること、そして +3. 憲法修正を通じてガバナンス規則自体を変更すること。 + +EOS.IOソフトウェアベースのブロックチェーンはブロック生成者の既存の影響を効率的に導くガバナンスプロセスを実現しています。明確なガバナンスプロセスがなかったため、以前のブロックチェーンは、予測できない結果となるその場しのぎで、規定によらず、論争が多いガバナンスプロセスに依存しました。 + +EOS.IOソフトウェアベースのブロックチェーンでは、権限はブロック生成者に権限を委任したトークンホルダーにあることを認識しています。ブロック生成者には、アカウントの凍結、欠陥アプリケーションの更新、基本プロトコルへのハードフォークの変更の提案を行う制限され監視されたオーソリティが与えられます。 + +EOS.IOソフトウェアにはブロック生成者の選出が組み込まれています。ブロックチェーンを変更する前に、ブロック生成者が承認する必要があります。ブロック生成者がトークンホルダーが希望する変更を行うことを拒否した場合、投票により追放できます。ブロック生成者がトークンホルダーの許可を得ずに変更を加えた場合、他の生成者でないフルノード検証者 (取引所など)が変更を拒絶します。 + +## アカウントの凍結 + +スマートコントラクトは逸脱したまたは予測不可能な方法で振舞い、意図した通りに履行されない場合があります。 アプリケーションまたはアカウントが不適切な量のリソースの消費が可能な悪用を発見する場合もあります。そんな事態が必然的に発生した場合、ブロック生成者には状況を修正する権限があります。 + +全ブロックチェーンのブロック生成者は、アカウントを凍結する能力を与えるブロックにどのトランザクションを含めるかを選択する権限があります。EOS.IOソフトウェアを使用するブロックチェーンは、アカウント凍結プロセスをアクティブな生成者の15/21投票を条件にすることでこのオーソリティを正式に承認しています。生成者が権限を乱用した場合は投票で追放でき、アカウント凍結は解除されます。 + +## アカウントコードの変更 + +その他全てが失敗し、「停止不可能なアプリケーション」が予測不可能な方法で動作する場合、 EOS.IOソフトウェアを使用するブロックチェーンでは、ブロック生成者がブロックチェーン全体をハードフォークせずにアカウントコードを更新できます。アカウント凍結のプロセスと同様に、このコード更新は選出されたブロック生成者の15/21投票が必要です。 + +## 憲法 + +EOS.IOソフトウェアでは、ブロックチェーンがピアツーピアのサービス契約条項契約または署名したユーザ間で拘束力のある契約を定めることができ、これを「憲法」と呼びます。この憲法の内容は、コードが完全に強制できないユーザ間の義務を定義し、他の相互に承諾された規則と一緒に裁判権と法の選択を規定することにより紛争解決を容易にします。ネットワークでブロードキャストされた全トランザクションは署名の一部として憲法のハッシュを組み込む必要があり、それによって署名者を明示的に契約に拘束します。 + + 憲法はソースコードプロトコルの人間可読可能な意図も定義します。この意図は、エラー発生時にバグと機能の差を区別するために使用され、どのフィックスが適切または不適切か、コミュニティをガイドします。 + +## プロトコルと憲法のアップグレード + +EOS.IOソフトウェアは、正規ソースコードとその憲法によって定義された通り、アップデート可能なプルトコルによって次のプロセスを定義します。 + +1. ブロック生成者は憲法の変更を提案し、15/21の賛同を獲得します。 +2. ブロック生成者は新**憲法**の15/21の賛同を連続30日間維持します。 +3. 全ユーザは、将来のトランザクションが処理される条件として、新憲法の受入を示す必要があります。 +4. ブロック生成者は憲法の変更を反映するためソースコードの変更を採用し、新憲法のハッシュを使ってブロックチェーンに提案します。 +5. ブロック生成者は新**コード**の15/21の賛同を連続30日間維持します。 +6. コード変更は7日後に施行され、生成者でない全フルノードにはソースコード承認後にアップグレードのために1週間与えます。 +7. 新コードにアップグレードしない全ノードは自動的に停止されます。 + +標準では、EOS.IOソフトウェアの構成、新機能追加のためのブロックチェーンの更新プロセスには2～3ヵ月かかり、クリティカルでないバグ修正の更新で憲法の変更を必要としないものは1～2ヵ月かかることがあります。 + +### 緊急時の変更 + +ユーザに実際に害を与える有害なバグやセキュリティ悪用の修正のためにソフトウェア変更が必要な場合、ブロック生成者はプロセスを加速することができます。通常、新機能の導入や有害なバグの修正のための加速されたアップデートは憲法に違反する場合があります。 + +# スクリプトと仮想マシン + +EOS.IOソフトウェアは、アカウントへの承認されたメッセージ(アクションと呼ぶ)の配信を調整する最初かつ一流のプラットフォームです。スクリプト言語と仮想マシンの詳細は、EOS.IO技術の設計からは大半が独立した実装固有の詳細情報です。決定的で適切にサンドボックスされた十分な性能がある言語または仮想マシンはEOS.IOソフトウェア APと統合可能です。 + +## スキーマ定義されたアクション + +アカウント間で送信される全アクションは、ブロックチェーンのコンセンサス状態の一部であるスキーマによって定義されます。このスキーマはアクションのバイナリーとJSON表現間でシームレスな変換が可能です。 + +## スキーマ定義されたデータベース + +データベース状態も同様なスキーマを使って定義されます。これにより全アプリケーションで格納されたデータは人間可読なJSONとして解釈できる形式ですが、効率の良いバイナリーで格納操作できることが保証されます。 + +## 汎用マルチインデックスデータベースAPI + +スマートコントラクト開発には、データの追跡、格納、発見のために定義されたデータベーススキーマが必要です。開発者は複数フィールドでソートまたはインデックスされ、全インデックスで一貫性を保つため同一データが通常必要です。 + +## アプリケーションからの認証の分離 + +並列化の機会を最大化し、トランザクションログからアプリケーション状態の再生に関連する計算の負債を最小化するため、EOS.IOソフトウェアは検証ロジックを3セクションに分離しています。 + +1. アクションに内部一貫性があることの検証、 +2. 事前条件が全て有効であることの検証、および +3. アプリケーション状態の修正。 + +アクションの内部一貫性の検証はリードオンリーで、ブロックチェーン状態へのアクセスは不要です。これは、最大の並列性を用いて実行可能であることを意味します。必要な残高などの事前条件の検証はリードオンリーで、そのためこれも並列性の恩恵があります。アプリケーション状態の修正だけがライトアクセスが必要で、各アプリケーションをシーケンシャルに処理する必要があります。 + +認証はアクションが適用可能なことを確認するリードオンリーのプロセスです。アプリケーションが実際に仕事を行います。リアルタイムでは、両方の計算を実行する必要がありますが、トランザクションがブロックチェーンに含まれてしまえば、もはや認証を行うには不要です。 + +# ブロックチェーン間通信 + +EOS.IOソフトウェアはブロックチェーン間通信を楽にするよう設計されています。これはアクションの存在証明とアクションシーケンスの証明の生成を容易にすることによって実行されます。アクションパッシングを中心に設計されたアプリケーションアーキテクチャと組み合わせたこの証明では、ブロックチェーン間通信と証明検証の詳細をアプリケーション開発者から隠蔽でき、開発者に高度な抽象性を提供できます。 + + + +## 軽量クライアント検証 (LCV)のためのマークル・プルーフ + +他のブロックチェーンとの統合は、クライアントが全トランザクションを処理する必要がない場合、非常に簡単です。結局、取引所だけが取引所を出入りするトランザクションだけで注意し、それ以上は注意していません。また、交換チェーンがそれ自身のブロック生成者を完全に信頼しなければならないことより、入金の軽量マークル・プロ―フを利用できれば、理想的です。少なくとも、チェーンのブロック生成者は、別のブロックチェーンと同期する場合、オーバーヘッドをできるだけ小さくしたいのです。 + +LCVのゴールは、比較的軽量なデータセットを追跡する者により検証できる相対的軽量な存在証明の生成を可能にすることです。この場合、目的は特定のトランザクションが特定ブロック内に含まれること、そのブロックが特定ブロックチェーン内の検証された履歴に含まれることの証明です。 + +Bitcoinは、全ノードが1年あたり4MBのブロックヘッダーになるブロックヘッダーの全履歴にアクセスすることを仮定して、トランザクションの検証に対応します。毎秒10トランザクションでは、有効性の証明に約512バイト必要です。これは、10分のブロック間隔のブロックチェーンではうまく機能しますが、0.5秒のブロック間隔のブロックチェーンではもはや「軽量」ではありません。 + +EOS.IOソフトウェアでは、トランザクションが加わった時点以降の取消不可能なブロックヘッダを持つ者に対して軽量な証明が可能になります。示されたハッシュリンクされた構造を使用することで、サイズ1024バイト未満の証明付きのトランザクションの存在を証明できます。 + +ブロックチェーン内ブロックに対するブロックidで、ヘッダが信頼された取消不可能なブロックである場合、そのブロックがブロックチェーン内に含まれることを証明できます。チェーン内ブロック数をNとした場合、この証明にはそのパスに対してceil(log2(N))個のダイジェストを要します。SHA256のダイジェスト方式で、864バイトに1億ブロックを含むチェーン内ブロックの存在を証明できます。 + +これらの証明を可能にするため適切なハッシュリンクを持ったブロック生成に関連したオーバーヘッドはほとんど増えず、このような方法でブロックを生成しない理由はありません。 + +他のチェーン上で証明を検証する場合、実行可能な時間/空間/帯域幅のさまざまな最適化が存在します。全ブロックヘッダ(420MB/年)を追跡しても証明サイズは小さいままです。最近のヘッダだけを追跡する場合には、最小の長期ストレージと証明サイズ間をトレードオフできます。その代わり、ブロックチェーンは過去の証明の中間ハッシュを記憶している場合、遅延評価の手法が使用できます。新しい証明は既知のスパースツリーへのリンクを含むことがだけが必要です。使用された正確なアプローチでは必然的にマークル・プルーフにより参照されたトランザクションを含む外部ブロックの割合に依存します。 + +相互接続がある程度の密度になった後、あるチェーンに別のチェーンの全ブロック履歴を単純に持たせ、証明の必要性をまとめて除去することがもっと効率的です。性能上の理由で、チェーン間の証明の頻度は最小化することが理想的です。 + + +## チェーン間通信のレイテンシー + +別の外部ブロックチェーンと通信する場合、ブロック生成者は、トランザクションを有効な入力として受け入れる前に他のブロックチェーンにより取消不可能で確認されたことが100％確実になるまで待つ必要があります。EOS.IOソフトウェアベースのブロックチェーンと0.5秒ブロックのDPOSとビザンチンフォールトトレラント性の取消不可能性を追加すれば、約0.5秒かかります。チェーンのブロック生成者が取消不可能性を待たなければ、後で取り消される入金を信用する取引所のようになり、ブロックチェーンのコンセンサスの有効性に影響を与える可能性があります。EOS.IOソフトウェアではDPOSとaBFTの両方を使い、取消不可能性を素早く求めます。 + +## 完全性の証明 + +外部ブロックチェーンからマークル・プルーフを使用する場合、処理されたトランザクション全てが有効である事を知ることと、どのトランザクションもスキップまたは省かれていないことを知ることの間に大きな違いがあります。直近のトランザクション全てが知られていることを証明は不可能ですが、トランザクション履歴にギャップがないことを証明は可能です。EOS.IOソフトウェアは、全アカウントへ配信された各アクションにシーケンス番号を割り当てることでこれを容易にしています。ユーザはこのシーケンス番号を使って、特定アカウントに意図された全アクションが処理され、順番に処理されたことを証明できます。 + + +## 分離された署名情報 + +分離された署名情報(SegWit)の考え方は、トランザクション署名はブロックチェーンに変更不可能に含まれた後は関連しないということです。変更不可能になれば、署名データを刈り取り、他の全員は現在の状態を導くことが可能です。署名は大半のトランザクションの大きな割合なので、SegWitはディスク使用と同期時間を大幅に節約できます。 + +これと同じコンセプトはブロック間通信に使用されるマークル・プルーフにも適用できます。証明が受け入れられブロックチェーンに取消不可能で記録されたら、証明により使用されたsha256ハッシュの2KBはもはや適切なブロックチェーン状態を導くためには不要です。ブロックチェーン間通信の場合、通常の署名での節約より32倍節約されます。 + +SegWitの別の例は、Steemのブログ投稿に対するものです。このモデルでは、投稿にはsha256(ブログ内容)しか含まれず、ブログの内容は分離された証明データの中にあります。ブロック生成者はコンテンツが存在し与えられたハッシュがあることを検証しますが、ブログの内容はブロックチェーンログから現在の状態を回復するために蓄積する必要はありません。これによりコンテンツを永久保存することなく、そのコンテンツが既知であったことを証明できます。 + +# 結論 + +EOS.IOソフトウェアは定評あるコンセプトとベストプラクティスを使った経験から設計され、ブロックチェーン技術における重要な進歩です。ソフトウェアは地球規模にスケールする、 分散型アプリケーションを容易にデプロイ/管理できるブロックチェーン社会の全体の青写真の一部です。