Finschia · torao · Aug 18, 2021 · Jul 13, 2021 · Aug 2, 2021 · Aug 3, 2021
@@ -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:

@@ -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',

@@ -0,0 +1 @@
+🏺
@@ -0,0 +1,115 @@
+# 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 が一般的なハッシュ関数や疑似乱数生成器と異なる点は、
+公開鍵を使用して 「本当にその乱数がメッセージ $m$ に基づいて生成されたものか」を第三者が検証できる点です。乱数の生成者はメッセージ $m$ と
+秘密鍵 $S_k$ を使って証明 $\pi$ (VRF Proof; ハッシュ値 $t$ の元となる値) を生成します。他方、検証者は入手した証明 $\pi$ が偽造された
+ものでないことを $S_k$ に対応する公開鍵 $P_k$ とメッセージ $m$ を使って同じハッシュ値 $t$ が生成されるかを検証します。
+
+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 prove}(S_i, m_h) \\
+t_h & = & {\rm prove\_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 verify}(P_i, m_h, \pi_h) \overset{\text{?}}{=} {\rm 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 の没収によって選出候補から排除する措置が
+取られます。
+
+<!-- Related Work として他の手段との比較の話を追加する?
+## Related Work
+
+Tendermint は加重ラウンドロビンでした。
+Algorand のように PoW の代替手段として VRF を利用する方法もありますが、Tendermint-BFT に適用するにはプロトコル設計を大幅に変更する
+必要があること、十分に安全な数の Voter が選出される保証がないこと、Bitcoin の PoW と同様に当選を自己申告で公表するためサブマリンノードが
+出そうなこと、選出されたのに何もしなかったノードへの罰則のために「当選者は誰か」が分かる必要がある、など。
+-->
@@ -0,0 +1,5 @@
+# Ostracon: A Fast, Secure Consensus Layer for The Blockchain of New Token Economy
+
+[日本語](index_ja.md)
+
+(WIP)
@@ -0,0 +1,65 @@
+# 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. **パフォーマンスとスケーラビリティ**: 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 | |
+
+<sup>*1</sup> experimental implementation.
+
+## Ostracon Features
+
+* [Extending Tendermint-BFT with VRF-based Election](consensus_ja.md)
+* [BLS Signature Aggregation](signature_aggregation_ja.md)