doc: [ja] Add ostracon-specific VRF+BLS feature documents (Finschia#294)

doc: [ja] add ostracon-specific VRF+BLS feature documents
torao · Aug 18, 2021 · 92e2b95 · 92e2b95
1 parent f53ee28
commit 92e2b95
Show file tree

Hide file tree

Showing 21 changed files with 3,313 additions and 3,766 deletions.
diff --git a/Makefile b/Makefile
@@ -233,14 +233,16 @@ DESTINATION = ./index.html.md
 ###                           Documentation                                 ###
 ###############################################################################
 
+BRANCH := $(shell git branch --show-current)
+BRANCH_URI := $(shell git branch --show-current | sed 's/[\#]/%23/g')
 build-docs:
 	cd docs && \
-	while read p; do \
-		(git checkout $${p} . && npm install && VUEPRESS_BASE="/$${p}/" npm run build) ; \
-		mkdir -p ~/output/$${p} ; \
-		cp -r .vuepress/dist/* ~/output/$${p}/ ; \
-		cp ~/output/$${p}/index.html ~/output ; \
-	done < versions ;
+	npm install && \
+	VUEPRESS_BASE="/$(BRANCH_URI)/" npm run build && \
+	mkdir -p ~/output/$(BRANCH) && \
+	cp -r .vuepress/dist/* ~/output/$(BRANCH)/ && \
+	for f in `find . -name '*.png' | grep -v '/node_modules/'`; do if [ ! -e `dirname $$f` ]; then mkdir `dirname $$f`; fi; cp $$f ~/output/$(BRANCH)/`dirname $$f`; done && \
+	echo '<html><head><meta http-equiv="refresh" content="0;/$(BRANCH_URI)/index.html"/></head></html>' > ~/output/index.html
 .PHONY: build-docs
 
 sync-docs:

diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js
@@ -1,6 +1,11 @@
 module.exports = {
   title: 'Ostracon',
   base: process.env.VUEPRESS_BASE,
+  head: [
+    ['script', { src: 'https://polyfill.io/v3/polyfill.min.js?features=es6' }],
+    ['script', { id: 'MathJax-script', src: 'https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js', async: "async"}],
+    ['script', { }, 'window.MathJax = { tex: { inlineMath: [[\'$\',\'$\'], [\'\\\\(\',\'\\\\)\']] } };']
+  ],
   themeConfig: {
     repo: 'line/ostracon',
     docsRepo: 'line/ostracon',

diff --git a/docs/.vuepress/public/.gitkeep b/docs/.vuepress/public/.gitkeep
@@ -0,0 +1 @@
+🏺
diff --git a/docs/drafts/features/bft_round.png b/docs/drafts/features/bft_round.png
diff --git a/docs/drafts/features/bls_signature_aggregation.png b/docs/drafts/features/bls_signature_aggregation.png
diff --git a/docs/drafts/features/consensus_ja.md b/docs/drafts/features/consensus_ja.md
@@ -0,0 +1,121 @@
+# Extending Tendermint-BFT with VRF-based Election
+
+## Consensus Overview
+
+Tendermint-BFT に基づく Ostracon のブロック生成メカニズムは以下の 3 つのフェーズで構成されています。
+ここで、ブロックの世代を*高さ*、この 3 つのブロック承認プロセスを*ラウンド*と呼んでいます。
+
+**選出フェーズ**. 候補ノードの中から １ つの Proposer と複数の Voter を選出します。これは一般的な分散システムにおけるリーダー選挙と同じ
+ですが、ブロックチェーンでは悪意を持った妨害によってシステム全体の性能を低下させないために作為的な選出ができないように設計する必要があります。
+また公平性を保証するために Ostracon の選挙には中央集権的な機関が介在していないことにも注意してください。選挙結果はすべてのノードで決定論的に
+算出できるため、各ノードは「自分が Proposer または Voter に当選しているか」を自律的に判断することができます。
+
+**ブロック作成フェーズ**. ブロックの提案は選挙で選出された Proposer によって行われます。ブロックチェーンに取り込まれていない未承認の
+トランザクションは P2P でネットワーク上のノードに共有され、各ノードの mempool と呼ばれる領域に保管されます。Proposer に選ばれたノードは
+自分の mempool に残っている未承認のトランザクションからブロックを生成して Voter に*提案*します。
+
+**ブロック検証フェーズ**. Proposer の提案したブロックは選挙で選出された Voter によって正当性が検証されます。各 Voter はブロックの内容が
+正しいかどうかを投票し、票は Tendermint-BFT によって他の Voter に複製され、すべての Voter 数の 2/3+1 以上の賛成票が集まればそのブロックは
+正式に*承認*されます。反対に、定足数の賛成票が集まらなければ提案されたブロックは拒否され新しいラウンドで選挙または投票からやり直しとなります
+(Tendermint-BFT には拒否の理由によってショートカットする経路がいくつかあります)。
+
+![VRF-based Block Generation Round](vrf_based_round.png)
+
+## VRF-based Consensus Group Election
+
+VRF は暗号論的疑似乱数として使用できるハッシュ値 $t$ を生成するアルゴリズムです。VRF が一般的なハッシュ関数や疑似乱数生成器と異なるのは、
+秘密鍵の所有者のみがハッシュ値 $t$ を算出でき、対応する公開鍵を持つ人であれば誰でもそのハッシュ値の正当性を検証できる点です。
+
+乱数の生成者 $k$ は式 (1) のように自身の秘密鍵 $S_k$ を使ってメッセージ $m$ から証明 (VRF Proof) $\pi$ を生成します。ここでハッシュ値
+$t$ は式 (2) を使って証明 $pi$ から生成することができます。一方、検証者はハッシュ値 $t$ が秘密鍵 $S_k$ の所有者によってメッセージ $m$ に
+基づいて生成されたものであることを検証するために、$S_k$ に対する公開鍵 $P_k$ と $m$, $\pi$ を式 (3) に適用して同一のハッシュ値 $t$ が
+生成されることを確認します。
+
+![VRF Expression](math_expression.png)
+
+```math
+\begin{eqnarray}
+\pi & = & {\rm vrf\_prove}(S_k, m) \\
+t & = & {\rm vrf\_proof\_to\_hash}(\pi)
+\end{eqnarray}
+\begin{equation}
+{\rm vrf\_proof\_to\_hash}(\pi) \overset{\text{?}}{=} {\rm vrf\_verify}(P_k, m, \pi)
+\end{equation}
+```
+
+Ostracon では、あるブロックを作成した Proposer による*無作為で検証可能な乱数*によって次の Proposer と Voter を決定します。そして
+ブロックにはそのための VRF Proof フィールド $\pi$ が追加されています。
+
+新しいブロックを受信したノードは選出フェーズを開始します。選出フェーズではブロックに含まれている VRF Proof $\pi$ を検証し、「公正な
+疑似乱数」である VRF ハッシュ $t$ を算出し、その値に基づいてこのラウンドの Proposer と Voter を選択します。これは Stake 保有量に
+応じた選出確率に基づく (つまり PoS に基づく) シンプルで高速な加重ランダムサンプリングによって行われます。
+
+![VRF-based Proposer/Voter Election](vrf_election.png)
+
+この判定によって選ばれた Proposer が自分自身であれば、そのノードは mempool から未承認のトランザクションを取り出して proposal ブロックを
+作成します (この時点ではまだブロックは確定していません)。このとき、自分を選択した VRF ハッシュ $t$ とブロックの高さ $h$、現在のラウンド
+$r$ に基づいて算出した新しい VRF Proof $\pi'$ をブロックに設定します。
+
+![VRF Prove](math_prove.png)
+
+```math
+\begin{eqnarray*}
+m_h & = & {\rm SHA256}(h \,\|\, r \,\|\, t_{h-1}) \\
+\pi_h & = & {\rm vrf\_prove}(S_i, m_h) \\
+t_h & = & {\rm vrf\_proof\_to\_hash}(\pi_h)
+\end{eqnarray*}
+```
+
+VRF Proof $\pi$ を算出するためのメッセージ $m$ にはブロックそのもののハッシュ値は関与しないことに注意してください。ブロックのハッシュ値は
+ブロックを生成する Proposer が試行錯誤によって有利な値を導出できることから本質的に安全ではないと考えています。
+
+![VRF-based Block Generation](vrf_block_generation.png)
+
+選出フェーズで自分自身が Voter に選ばれたノードは、受信した Proposal ブロックを検証して投票します。票は Tendermint-BFT により
+prevote, precommit, commit を経て複製され、定足数以上の有効票が集まればブロックが承認されます。
+
+![VRF-based Block Validation](vrf_block_validation.png)
+
+検証フェーズではブロックの検証に加えて VRF に関連する以下の検証も行われます。
+
+1. ブロックを生成した Proposer がその直前のブロックの VRF Proof に基づいて選ばれたノードであること。これは実際に VRF ハッシュ $t$ を
+   使って加重ランダムサンプリングで Proposer を選んでブロックを生成したノードと一致しているかで判断できます。
+2. ブロックに含まれている $\pi$ が本当にその Proposer の秘密鍵を使って生成された VRF Proof であること。VRF Proof $\pi$ から算出した
+   $t$ と、vrf_verify() 関数を使って算出した $t$ が一致していれば $\pi$ が偽造されたものでないと判断できます。
+
+![VRF Verify](math_verify.png)
+
+```math
+{\rm vrf\_verify}(P_i, m_h, \pi_h) \overset{\text{?}}{=} {\rm vrf\_proof\_to\_hash}(\pi_h)
+```
+
+この一連のラウンドを繰り返すことによって無作為なランダムサンプリングをすべてのブロック生成に渡って連鎖させることができます。
+
+![BFT-based Block Generation](bft_round.png)
+
+ここで、ブロックを受信したノードは次の Proposer と Voter がどのノードなのかを決定論的に算出できることを思い出してください。あるラウンドで
+ブロックの生成や検証の責任を持つノードを明らかにすることによって、選出されながら実際にはその作業を行わなかったり、Eclipse 攻撃のような悪意の
+ある行動を行ったノードに対して懲罰を与えることができます。一方で、それらが明らかになるのは必要最小限の期間のみであり、1 ブロックより先の
+Proposer や Voter を予測することは依然として困難です。
+
+VRF は現在のところ Ed25519 鍵を使用して実装されています。BLS 署名を選択したとしても VRF の算出を行うために Ed25519 鍵がセットで生成
+されます。
+
+## Voters
+
+Ostracon のネットワークでは Stake を保有して Proposer または Voter に選出される可能性のある候補ノードを Validator としています。
+Voter は 2 つの理由で Ostracon に新しく導入された概念です; 一つ目は Voter に選出されたノードへの報酬配当を調整するため、もう一つは
+参加可能なノードの信頼ポリシーが異なるネットワークでビザンチンとして想定する比率を調整可能にするためです (Voter 数が Validator 数と
+一致する設定では Tendermint と完全に一致します)。
+
+Voter 選出では、一つの VRF ハッシュ $t$ から複数のノードをランダムに選択するために、疑似乱数関数 $r$ を使って $t$ に基づいた乱数列を
+生成します。$t$ が既に暗号論的疑似乱数の性質を持つことから、この $r$ は実装がシンプルで変種が発生しづらく、高速で省メモリであることが
+より重要です。Ostracon ではこの Voter 選出にシフトレジスタ型と呼ばれる非常に高速な疑似乱数生成アルゴリズムである
+SplitMix64 を使用しています。
+
+## Disciplinary Scheme for Failures
+
+Ostracon の合意スキームは少数のノードが故障していても正しく機能しますが、ネットワークや CPU 資源を無駄に消費しないためには故障したノードが
+コンセンサスグループに選ばれないことが理想的です。とりわけ一般的な非同期メッセージングの問題が原因ではないケース、つまり意図的に行ったと
+思われる不正な行為に対しては (悪意の有無に関わらず) その挙動の evidence が共有されて Stake の没収によって選出候補から排除する措置が
+取られます。
diff --git a/docs/drafts/features/index.md b/docs/drafts/features/index.md
@@ -0,0 +1,5 @@
+# Ostracon: A Fast, Secure Consensus Layer for The Blockchain of New Token Economy
+
+[日本語](index_ja.md)
+
+(WIP)
diff --git a/docs/drafts/features/index_ja.md b/docs/drafts/features/index_ja.md
@@ -0,0 +1,89 @@
+# Ostracon: A Fast, Secure Consensus Layer for The Blockchain of New Token Economy
+
+Version 1.0 :: [English](index.md)
+
+## Ostracon Overview
+
+Ostracon は LINE Blockchain エコシステムにビザンチン障害耐性を持つ分散合意メカニズムを提供するコアコンポーネントです。アプリケーションが
+実行するトランザクションの順序を確定し、トランザクションのコンテナであるブロックの生成、検証を行います。
+
+LINE Blockchain はインターネット上の電子サービスのみならず、金融や産業にも適用可能な合意メカニズムをもたらすために技術選定について達成
+すべきいくつかの方針を設定しています。
+
+1. **セキュリティ**: 暗号理論に基づいた実用に十分な完全性と健全性を持つ。
+2. **整合性**: 強い整合性 (ファイナリティ) の合意アルゴリズムを持つ。
+3. **障害耐性**: ビザンチン障害を含むシステム障害に対して Safety と Liveness を持つ。
+4. **パフォーマンスとスケーラビリティ**: 2 秒に 1 つのブロックを生成し、1000TPS+ の速度性能を持つ。
+5. **チェーン間接続**: LINE Blockchain 以外のブロックチェーンとの相互接続性を持つ。
+
+ファイナリティとパフォーマンスの観点から Bitcoin のような Proof of Work よりも BFT (Byzantine Fault-Tolerance) に基づく P2P
+合意アルゴリズムの方が適しています。中でもブロックチェーンに最適化された近代的な設計が行われている Tendermint-BFT は我々の方針に最も
+近い実装でした (さらに良いことに Cosmos Hub とも接続できます)。
+
+我々は我々のブロックチェーンをさらに改善するために Tendermint-BFT に二つの新しい暗号技術を導入しています。その一つである**検証可能な
+疑似乱数** (VRF) は、ブロックを生成する Proposer ノードの選出にランダム性をもたせて未来の選出を予測困難にすることを目的に導入されました。
+このランダム性の導入により、悪意を持つ攻撃者に攻撃の猶予を与えたり、将来のある時点を狙って参加者どうしで共謀することを困難にする効果が期待
+できます。
+
+もう一つの機能は **BLS 署名**です。双線形写像に基づく BLS 署名は複数の電子署名をたった一つの電子署名に集約できる特徴を持ちます。多くの
+ブロックチェーンプロトコルでは、ブロックを承認するために多数の署名を保存しなければなりませんが、BLS 署名集約を有効にすることでそのフット
+プリントを削減し、通信速度やストレージ消費量を大きく改善する効果が期待できます。
+
+## Layered Structure
+
+LINE Blockchain ノードを構成する Application, Consensus および Networking の 3 つのレイヤーのうち、Ostracon には Consensus と
+Networking レイヤーが含まれています。
+
+![Layered Structure](layered_structure.png)
+
+まだブロックに取り込まれていないトランザクションは mempool と呼ばれる Network レイヤーのアンチエントロピー機構 (ゴシッピング) によって
+各ノード間で共有されます。ここで、Network および Consensus レイヤーではトランザクションを単純なバイナリとして扱い、そのデータの内容には
+関与しません。
+
+## Specifications and Technology Stack
+
+| Specifications        | Policy / Algorithms           | Methods / Implementations                       |
+|:----------------------|:------------------------------|:------------------------------------------------|
+| Participation         | Permissioned                  | Consortium or Private                           |
+| Election              | Proof of Stake                | VRF-based Weighted Sampling without Replacement + SplitMix64 |
+| Agreement             | Strong Consistency w/Finality | Tendermint-BFT                                  |
+| Signature             | Elliptic Curve Cryptography   | Ed25519, *BLS12-381*<sup>*1</sup>               |
+| Hash                  | SHA2                          | SHA-256, SHA-512                                |
+| HSM                   | *N/A*                         | *No support for VRF or signature aggregation*   |
+| Key Auth Protocol     | Station-to-Station            | |
+| Tx Sharing Protocol   | Gossiping                     | mempool |
+| Application Protocol  | ABCI                          | |
+| Interchain Protocol   | IBC (Cosmos Hub)              | |
+| Storage               | Embedded KVS                  | LevelDB |
+| Message Recovery      | WAL | |
+| Block Generation Time | 2 seconds | |
+
+<sup>*1</sup> experimental implementation.
+
+## Ostracon Features
+
+* [Extending Tendermint-BFT with VRF-based Election](consensus_ja.md)
+* [BLS Signature Aggregation](signature_aggregation_ja.md)
+
+## Consideration with Other Consensus Schemes
+
+他のブロックチェーンではどのようなコンセンサス機構を採用しているのでしょうか? Ostracon の方向性を決定するために多くの比較と検討を行いました。
+
+**Bitcoin** や **Ethereum** で採用している PoW は最も有名なブロックチェーン向けコンセンサス機構です。これらはパブリックチェーンとして
+運用している実績がありますが、十分な時間が経過しないと結果が覆る可能性があるという機能的な制約を持ちます。これは、短期には lost update 問題を
+引き起こし、長期には必要なパフォーマンスが確保できないという問題が顕著に現れることから、PoW は検討初期の段階で選択肢から外れました。
+
+**Tendermint** が合意アルゴリズムに採用している Tendermint-BFT はブロックチェーン向けによく考慮された設計です。短時間でファイナリティを
+保証できる点も我々の方針に適していました。一方で、選出アルゴリズムに採用している加重ラウンドロビンは決定論的に動作するため、誰でも将来の
+Proposer を知り得ることから標的を見つけて攻撃を準備しやすい点があります。このため Ostracon では攻撃の可能性を軽減する目的で VRF を使って
+予測不可能なアルゴリズムに置き換えています。
+
+**Algorand** は我々とは大きく異なる方法で VRF を使用しています。Algorand では選挙が始まるとそれぞれのノードが VRF 乱数を生成して次の
+Validator に当選しているかをノード自身が判断します (すべてのノードが一斉にコイントスするのと似ています)。これは PoW のハッシュ計算で
+当選を引き当てる方法と比較して、大量の計算時間と電力消費を省略しつつ暗号論的な安全性を保証している優れた方法です。一方で、選出される
+Validator 数が決定的ではなく二項分布に従うランダムな振る舞い含むことや、当選ノード間の相互認識でプロトコルが複雑性が上がること、当選した
+にもかかわらず役割をサボタージュしたノードを見つけることができないこと、といったいくつかの理由により適用は難しいと判断しました。
+
+他にいくつものコンセンサス機構について考慮しましたが、役割選出と合意アルゴリズムに関しては現在の選択が現実的に最良に近い選択と考えています。
+しかし、Ostracon は特定の研究理論に対しての実験的証明や実証実験をゴールとしていないため、将来的により良いアルゴリズムの提案があればそれを
+採用する準備があります。
diff --git a/docs/drafts/features/layered_structure.png b/docs/drafts/features/layered_structure.png
diff --git a/docs/drafts/features/math_expression.png b/docs/drafts/features/math_expression.png
diff --git a/docs/drafts/features/math_prove.png b/docs/drafts/features/math_prove.png
diff --git a/docs/drafts/features/math_verify.png b/docs/drafts/features/math_verify.png