squash

Finschia · Aug 17, 2021 · 24d7cd1 · 24d7cd1
1 parent ff97def
commit 24d7cd1
Show file tree

Hide file tree

Showing 3 changed files with 37 additions and 21 deletions.
diff --git a/docs/drafts/features/consensus_ja.md b/docs/drafts/features/consensus_ja.md
@@ -23,12 +23,13 @@ Tendermint-BFT に基づく Ostracon のブロック生成メカニズムは以
 
 ## VRF-based Consensus Group Election
 
-VRF は暗号論的疑似乱数として使用できるハッシュ値 $t$ を生成するアルゴリズムです。VRF が一般的なハッシュ関数や疑似乱数生成器と異なる点は、
-公開鍵を使用して 「本当にその乱数がメッセージ $m$ に基づいて生成されたものか」を第三者が検証できる点です。
+VRF は暗号論的疑似乱数として使用できるハッシュ値 $t$ を生成するアルゴリズムです。VRF が一般的なハッシュ関数や疑似乱数生成器と異なるのは、
+秘密鍵の所有者のみがハッシュ値 $t$ を算出でき、対応する公開鍵を持つ人であれば誰でもそのハッシュ値の正当性を検証できる点です。
 
-乱数の生成者 $k$ は自身の秘密鍵 $S_k$ を使ってメッセージ $m$ から証明 (VRF Proof) $\pi$ を生成します:式(1)。ここでハッシュ値 $t$
-は証明 $pi$ から生成することができます:式(2)。一方、検証者は入手した証明 $\pi$ が本当にその生成者によってメッセージ $m$ に対して
-生成されたことを検証するために、$S_k$ に対応する公開鍵 $P_k$ と $m$、$pi$ を使って同一のハッシュ値 $t$ が生成されるかを確認します:式(3)。
+乱数の生成者 $k$ は式 (1) のように自身の秘密鍵 $S_k$ を使ってメッセージ $m$ から証明 (VRF Proof) $\pi$ を生成します。ここでハッシュ値
+$t$ は式 (2) を使って証明 $pi$ から生成することができます。一方、検証者は証明 $\pi$ が秘密鍵 $S_k$ の所有者によってメッセージ $m$ に
+対して生成されたものであることを検証するために、$S_k$ に対する公開鍵 $P_k$, $m$, $\pi$ を式 (3) に適用して同一のハッシュ値 $t$ が
+生成されることを確認します。
 
 ![VRF Expression](math_expression.png)
 
@@ -97,7 +98,7 @@ prevote, precommit, commit を経て複製され、定足数以上の有効票
 ある行動を行ったノードに対して懲罰を与えることができます。一方で、それらが明らかになるのは必要最小限の期間のみであり、1 ブロックより先の
 Proposer や Voter を予測することは依然として困難です。
 
-VRF は現在のところ ed25519 鍵を使用して実装されています。BLS 署名を選択したとしても VRF の算出を行うために Ed25519 鍵がセットで生成
+VRF は現在のところ Ed25519 鍵を使用して実装されています。BLS 署名を選択したとしても VRF の算出を行うために Ed25519 鍵がセットで生成
 されます。
 
 ## Voters
@@ -118,12 +119,3 @@ Ostracon の合意スキームは少数のノードが故障していても正
 コンセンサスグループに選ばれないことが理想的です。とりわけ一般的な非同期メッセージングの問題が原因ではないケース、つまり意図的に行ったと
 思われる不正な行為に対しては (悪意の有無に関わらず) その挙動の evidence が共有されて Stake の没収によって選出候補から排除する措置が
 取られます。
-
-<!-- Related Work として他の手段との比較の話を追加する?
-## Related Work
-
-Tendermint は加重ラウンドロビンでした。
-Algorand のように PoW の代替手段として VRF を利用する方法もありますが、Tendermint-BFT に適用するにはプロトコル設計を大幅に変更する
-必要があること、十分に安全な数の Voter が選出される保証がないこと、Bitcoin の PoW と同様に当選を自己申告で公表するためサブマリンノードが
-出そうなこと、選出されたのに何もしなかったノードへの罰則のために「当選者は誰か」が分かる必要がある、など。
--->
diff --git a/docs/drafts/features/index_ja.md b/docs/drafts/features/index_ja.md
@@ -13,7 +13,7 @@ LINE Blockchain はインターネット上の電子サービスのみならず
 1. **セキュリティ**: 暗号理論に基づいた実用に十分な完全性と健全性を持つ。
 2. **整合性**: 強い整合性 (ファイナリティ) の合意アルゴリズムを持つ。
 3. **障害耐性**: ビザンチン障害を含むシステム障害に対して Safety と Liveness を持つ。
-4. **パフォーマンスとスケーラビリティ**: 1000TPS+ の速度性能を持つ。
+4. **パフォーマンスとスケーラビリティ**: 2 秒に 1 つのブロックを生成し、1000TPS+ の速度性能を持つ。
 5. **チェーン間接続**: LINE Blockchain 以外のブロックチェーンとの相互接続性を持つ。
 
 ファイナリティとパフォーマンスの観点から Bitcoin のような Proof of Work よりも BFT (Byzantine Fault-Tolerance) に基づく P2P
@@ -56,10 +56,34 @@ Networking レイヤーが含まれています。
 | 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/signature_aggregation_ja.md b/docs/drafts/features/signature_aggregation_ja.md
@@ -8,18 +8,18 @@
 では署名集約を取り入れてパフォーマンスを改善しようと取り組んでいます。
 
 BLS 署名は双線形写像を使用した署名集約が可能な署名アルゴリズムの一種です。BLS 署名に関する最初の論文は非常に小さなサイズで実現できる電子署名
-として出版されましたが、ペアリング暗号とよばれるその技術からは他にもしきい値署名やブラインド署名のようないくつかの興味深い特徴が考案されました。
+として出版されましたが、ペアリングとよばれるその技術からは他にもしきい値署名やブラインド署名のようないくつかの興味深い特徴が考案されました。
 Ostracon でも BLS 署名によって収集した署名を単一の署名に集約することで 1) ブロックサイズの削減と 2) 検証回数の削減でパフォーマンスの向上を
 図っています。
 
 ![BLS Signature Aggregation](bls_signature_aggregation.png)
 
 ## Public Key Abstraction
 
-BLS 署名の導入に伴い、Ostracon ではノードごとにスキームの異なる署名鍵を同一のブロックチェーンインスタンス上で利用できるように設計を抽象化
-しました。つまり Ostracon ノードの運営者はノードを構築するときに、高速で実績のある Ed25519 署名と署名集約が可能な BLS 署名を選択できる
-ようになります。この柔軟性によって、将来にもっと良い署名アルゴリズムを試験/採用する場合や、特定の公開鍵アルゴリズムに脆弱性が発見された場合に
-柔軟に対処することができます。
+BLS 署名の導入に伴い、Ostracon ではノードごとにスキームの異なる署名鍵を同一のブロックチェーンインスタンス上で利用できるように設計を見直し
+ました。つまり Ostracon ノードの運営者はノードを構築するときに、高速で実績のある Ed25519 署名と署名集約が可能な BLS 署名を選択できる
+ようになります。この柔軟性によって、将来にもっと良い署名アルゴリズムを試験/採用する場合や、実装に脆弱性が発見された場合に柔軟に対処することが
+できます。
 
 ## Why is this an experimental status?