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

torao · 2021-07-29T04:02:56Z

Description

These documents focus on Ostracon-specific policies and features and omit contents that haven't changed since the original Tendermint. This PR includes the following components:

Overview … our policies and specification
VRF-based election
Signature aggregation

Current make build-docs tries to overwrite local updates by git checkout with main branch (specified in docs/versions). It's dangerous behavior, so I modify it to generate the contents of the current git branch.

The documentation as HTML can be generated in ~/output by installing Node.js and running make build-docs. This includes an extension to MathJax to use formulas in these documents. However, we don't yet have a way to distribute this official documentation. If you view these documents in Markdown, the formulas will be displayed in LaTeX notation.

All illustrations are contained in figures.drawio and can be edited with the draw.io app (win/mac/linux).

The English and other languages version will be written after these have been approved.

This PR is an update related to the content for native Japanese speakers, so comments on grammar and wording can be made in Japanese. / このPRは日本語ネイティブ向けの内容に関連する修正ですので、文法や表現方法に関するコメントは日本語でも構いません。

Closes: #286

CLAassistant · 2021-07-29T04:03:00Z

All committers have signed the CLA.

tnasu · 2021-08-02T02:58:47Z

docs/drafts/features/consensus_ja.md

+ここで、ブロックの世代を*高さ*、この 3 つのブロック承認プロセスを*ラウンド*と呼んでいます。
+
+**選出フェーズ**. 候補ノードの中から １ つの Proposer と複数の Voter を選出します。これは一般的な分散システムにおけるリーダー選挙と同じ
+ですが、ブロックチェーンではアイク的な妨害によってシステム全体の性能を低下させないために作為的な選出ができないように設計する必要があります。


"アイク的"は馴染みが薄い日本語だと思います。"IKE的"のほうがベターだと思います。ベストは略語を使わずに丁寧に説明したほうがよいです。

すみません、これは誤字です。IKE ではなく「悪意的」と書いたつもりでした。修正します。

Kynea0b · 2021-08-02T10:25:29Z

docs/drafts/features/consensus_ja.md

+VRF は暗号論的疑似乱数として使用できるハッシュ値 $t$ を生成するアルゴリズムです。VRF が一般的なハッシュ関数や疑似乱数生成器と異なる点は、
+公開鍵を使用して 「本当にその乱数がメッセージ $m$ に基づいて生成されたものか」を第三者が検証できる点です。乱数の生成者はメッセージ $m$ と
+秘密鍵 $S_k$ を使って証明 $\pi$ (VRF Proof; ハッシュ値 $t$ の元となる値) を生成します。他方、検証者は入手した証明 $\pi$ が偽造された
+ものでないことを $S_k$ に対応する公開鍵 $P_k$ とメッセージ $m$ を使って同じハッシュ値 $t$ が生成されるかを検証します。


「他方、検証者は入手した証明 $\pi$ が偽造されたものでないことを $S_k$ に対応する公開鍵 $P_k$ とメッセージ $m$ を使って同じハッシュ値 $t$ が生成されるかを検証」

証明が偽造されたものでないことのチェックではなくて，証明piを使ってハッシュ値を生成し，これが公開鍵とメッセージで作成された値で検証できるどうかのチェックですかね？例えば，「ハッシュ生成時の秘密鍵に対応していない公開鍵」である場合も検証失敗に含まれますが，失敗の結果から，piの偽造なのか，公開鍵のなりすましなのかどうやって区別するのだろうと言う疑問なんですけれど．

VRF の verify 結果は true/false ではなく同じハッシュ値が生成されるかになります。

はい，piで生成されるハッシュ値 == 公開鍵とメッセージで生成されるハッシュ値
で検証するのだと思います．（~~wikiに載っている検証式はこの等式ではなく，piと(公開鍵，メッセージ)の二つの入力でペアリングしてましたけれど~~）（ここを訂正します🙇‍♀️．等式は使ってます．ペアリングのため生成元チェックもしてます．すみません）
この検証失敗が返す結論は
「公開鍵に対する正しいハッシュ値ではない」
と言うことで，これは「piが不正な場合」はもちろん失敗しますが，「公開鍵が不正な場合」「メッセージが改ざんされている場合」も失敗しますので，検証結果からは必ずしも前者の失敗であることを保証しないのではないかと言うことです．

提案ですが，ここの検証で示したいのは，「この公開鍵のもとで，メッセージに関する正しいハッシュ値」と言うことなので，「他方，検証者は〜」からは「検証者は証明piを用いて，そのメッセージと公開鍵に対する正しいハッシュ値かどうかを検証できる」などと正しいハッシュ値に焦点を当てた書き方の方が，後ろの文の「「公正な疑似乱数」であるvrfハッシュ〜」に繋がるのではないかと思いました．

理解しました。表現を変更します。

Kynea0b · 2021-08-03T06:47:52Z

docs/drafts/features/consensus_ja.md

+VRF は暗号論的疑似乱数として使用できるハッシュ値 $t$ を生成するアルゴリズムです。VRF が一般的なハッシュ関数や疑似乱数生成器と異なる点は、
+公開鍵を使用して 「本当にその乱数がメッセージ $m$ に基づいて生成されたものか」を第三者が検証できる点です。乱数の生成者はメッセージ $m$ と
+秘密鍵 $S_k$ を使って証明 $\pi$ (VRF Proof; ハッシュ値 $t$ の元となる値) を生成します。他方、検証者は入手した証明 $\pi$ が偽造された
+ものでないことを $S_k$ に対応する公開鍵 $P_k$ とメッセージ $m$ を使って同じハッシュ値 $t$ が生成されるかを検証します。


提案ですが，ここの検証で示したいのは，「この公開鍵のもとで，メッセージに関する正しいハッシュ値」と言うことなので，「他方，検証者は〜」からは「検証者は証明piを用いて，そのメッセージと公開鍵に対する正しいハッシュ値かどうかを検証できる」などと正しいハッシュ値に焦点を当てた書き方の方が，後ろの文の「「公正な疑似乱数」であるvrfハッシュ〜」に繋がるのではないかと思いました．

Kynea0b · 2021-08-04T02:56:53Z

docs/drafts/features/consensus_ja.md

+## VRF-based Consensus Group Election
+
+VRF は暗号論的疑似乱数として使用できるハッシュ値 $t$ を生成するアルゴリズムです。VRF が一般的なハッシュ関数や疑似乱数生成器と異なる点は、
+公開鍵を使用して 「本当にその乱数がメッセージ $m$ に基づいて生成されたものか」を第三者が検証できる点です。乱数の生成者はメッセージ $m$ と


ここですが，「本当にその乱数がメッセージ $m$ に基づいて生成されたものか」→「本当にその乱数がメッセージ $m$ に基づいてその生成者が生成したものか」などとして，「秘密鍵の持ち主のみがハッシュ値を算出でき，それを検証者が検証できる」vrfの性質も伝えた方が良いと思います．

うーん、それがより正確な表現ですが、冒頭に置く言い回しとして見るとかなりくどくなるので (元の表現からくどい言い回しと思っていましたので) 「作為的な乱数でないことを検証する」というゴールをはっきりさせる表現に変更しました。

異なる点として挙げているポイントが，
＞「本当にその乱数がメッセージ $m$ に基づいて生成されたものか」
カギカッコで強調してる分，ここが一般的はハッシュ関数と同じに見えてしまうのです．
鷹見さんのブログの冒頭のこの文の方が良いのではないかと．
「秘密鍵の所有者のみがハッシュを算出できるが、公開鍵を持つ人であれば誰でもハッシュの正当性を検証できる。」

確かに「異なる点は〜」とつなげることを考えれば指摘の特徴を言及するようにしたほうが自然になりそうなので修正しました。

Kynea0b · 2021-08-04T04:56:43Z

docs/drafts/features/signature_aggregation_ja.md

+
+BLS 署名の導入に伴い、Ostracon ではノードごとにスキームの異なる署名鍵を同一のブロックチェーンインスタンス上で利用できるように設計を抽象化
+しました。つまり Ostracon ノードの運営者はノードを構築するときに、高速で実績のある Ed25519 署名と署名集約が可能な BLS 署名を選択できる
+ようになります。この柔軟性によって、将来にもっと良い署名アルゴリズムを試験/採用する場合や、特定の公開鍵アルゴリズムに脆弱性が発見された場合に


公開鍵アルゴリズム→署名アルゴリズムでは？

アルゴリズムに脆弱性が発見されるより実装に脆弱性が発見される方が現実的なので「特定の公開鍵アルゴリズム」の部分は置き換えました。

公開鍵暗号アルゴリズムおよびその実装は署名方式に用いることができるものもありますが，それは一般的なものではなく，それぞれ必要な要件が異なる別の技術なので，区別して記載する必要があると思います．公開鍵アルゴリズムは関係がないのではないかと．

最新版を参照してください。

tnasu · 2021-08-11T03:46:20Z

docs/.vuepress/public/.gitkeep

@@ -0,0 +1 @@
+🏺


nit: What's this? Please teach me.

We need the public directory when we run VuePress, but git won't let me commit an empty directory. So I'm putting a temporary file .gitkeep. The contents of it can be anything we like, but I've chosen the emoji used in ostracon.

tnasu · 2021-08-11T10:05:03Z

docs/drafts/features/consensus_ja.md

+思われる不正な行為に対しては (悪意の有無に関わらず) その挙動の evidence が共有されて Stake の没収によって選出候補から排除する措置が
+取られます。
+
+<!-- Related Work として他の手段との比較の話を追加する?


以下はRelated Workだとは思いませんが、以下ようなIssueとSolutionの説明はindex.mdなのか、Backgroundとして書いても良いと思います

この Makdown に残したコメントについては、index_ja.md で「他のコンセンサススキームの検討」という形で経緯として記述しました。

Kynea0b · 2021-08-04T05:25:28Z

docs/drafts/features/signature_aggregation_ja.md

+では署名集約を取り入れてパフォーマンスを改善しようと取り組んでいます。
+
+BLS 署名は双線形写像を使用した署名集約が可能な署名アルゴリズムの一種です。BLS 署名に関する最初の論文は非常に小さなサイズで実現できる電子署名
+として出版されましたが、ペアリング暗号とよばれるその技術からは他にもしきい値署名やブラインド署名のようないくつかの興味深い特徴が考案されました。


「ペアリング暗号とよばれるその技術からは他にもしきい値署名やブラインド署名の」

ここは「ペアリングと呼ばれる技術」とした方が無難だと思います．「ペアリング暗号」と言ったら，公開鍵暗号（IDベース暗号など）を指示してしまう場合があります．今は署名の話をしていますので，「ペアリング」とすれば良いと思います．（「cryptography」の訳が日本語だと暗号となるのが良くなくて訳す場合はたんに「ペアリングを使った署名」と表現することが多いようです．）

修正しました。

Kynea0b · 2021-08-12T07:36:24Z

docs/drafts/features/signature_aggregation_ja.md

+
+BLS 署名の導入に伴い、Ostracon ではノードごとにスキームの異なる署名鍵を同一のブロックチェーンインスタンス上で利用できるように設計を抽象化
+しました。つまり Ostracon ノードの運営者はノードを構築するときに、高速で実績のある Ed25519 署名と署名集約が可能な BLS 署名を選択できる
+ようになります。この柔軟性によって、将来にもっと良い署名アルゴリズムを試験/採用する場合や、特定の公開鍵アルゴリズムに脆弱性が発見された場合に


公開鍵暗号アルゴリズムおよびその実装は署名方式に用いることができるものもありますが，それは一般的なものではなく，それぞれ必要な要件が異なる別の技術なので，区別して記載する必要があると思います．公開鍵アルゴリズムは関係がないのではないかと．

Kynea0b · 2021-08-12T07:50:51Z

docs/drafts/features/consensus_ja.md

+## VRF-based Consensus Group Election
+
+VRF は暗号論的疑似乱数として使用できるハッシュ値 $t$ を生成するアルゴリズムです。VRF が一般的なハッシュ関数や疑似乱数生成器と異なる点は、
+公開鍵を使用して 「本当にその乱数がメッセージ $m$ に基づいて生成されたものか」を第三者が検証できる点です。乱数の生成者はメッセージ $m$ と


異なる点として挙げているポイントが，
＞「本当にその乱数がメッセージ $m$ に基づいて生成されたものか」
カギカッコで強調してる分，ここが一般的はハッシュ関数と同じに見えてしまうのです．
鷹見さんのブログの冒頭のこの文の方が良いのではないかと．
「秘密鍵の所有者のみがハッシュを算出できるが、公開鍵を持つ人であれば誰でもハッシュの正当性を検証できる。」

Kynea0b · 2021-08-17T04:24:59Z

docs/drafts/features/consensus_ja.md

+
+乱数の生成者 $k$ は自身の秘密鍵 $S_k$ を使ってメッセージ $m$ から証明 (VRF Proof) $\pi$ を生成します:式(1)。ここでハッシュ値 $t$
+は証明 $pi$ から生成することができます:式(2)。一方、検証者は入手した証明 $\pi$ が本当にその生成者によってメッセージ $m$ に対して
+生成されたことを検証するために、$S_k$ に対応する公開鍵 $P_k$ と $m$、$pi$ を使って同一のハッシュ値 $t$ が生成されるかを確認します:式(3)。


一方、検証者は入手した証明 $\pi$ が本当にその生成者によってメッセージ $m$ に対して
生成された

検証対象は入手したpiというより，ハッシュ値なので，結果的には同じにはなるですが，言葉で説明する場合は「piを使って，本当にその生成者がメッセージに対して作成したハッシュ値なのかを検証」と書いた方が良いのではと思います．piは秘密鍵を漏洩させたくないから，予めメッセージとひとまとめにして取っておくだけの値だと思います．

ハッシュ値を検証する意図にするために、"証明 $\pi$" を "ハッシュ値 $t$" に変更しました。

Kynea0b · 2021-08-17T04:33:47Z

docs/drafts/features/index_ja.md

+
+まだブロックに取り込まれていないトランザクションは mempool と呼ばれる Network レイヤーのアンチエントロピー機構 (ゴシッピング) によって
+各ノード間で共有されます。ここで、Network および Consensus レイヤーではトランザクションを単純なバイナリとして扱い、そのデータの内容には
+関与しません。


Kynea0b · 2021-08-17T04:34:50Z

docs/drafts/features/index_ja.md

+
+我々は我々のブロックチェーンをさらに改善するために Tendermint-BFT に二つの新しい暗号技術を導入しています。その一つである**検証可能な
+疑似乱数** (VRF) は、ブロックを生成する Proposer ノードの選出にランダム性をもたせて未来の選出を予測困難にすることを目的に導入されました。
+このランダム性の導入により、悪意を持つ攻撃者に攻撃の猶予を与えたり、将来のある時点を狙って参加者どうしで共謀することを困難にする効果が期待


Kynea0b · 2021-08-17T04:35:01Z

docs/drafts/features/index_ja.md

+
+もう一つの機能は **BLS 署名**です。双線形写像に基づく BLS 署名は複数の電子署名をたった一つの電子署名に集約できる特徴を持ちます。多くの
+ブロックチェーンプロトコルでは、ブロックを承認するために多数の署名を保存しなければなりませんが、BLS 署名集約を有効にすることでそのフット
+プリントを削減し、通信速度やストレージ消費量を大きく改善する効果が期待できます。


Kynea0b · 2021-08-17T04:35:33Z

docs/drafts/features/index_ja.md

+近い実装でした (さらに良いことに Cosmos Hub とも接続できます)。
+
+我々は我々のブロックチェーンをさらに改善するために Tendermint-BFT に二つの新しい暗号技術を導入しています。その一つである**検証可能な
+疑似乱数** (VRF) は、ブロックを生成する Proposer ノードの選出にランダム性をもたせて未来の選出を予測困難にすることを目的に導入されました。


文の途中で改行しているのは意味があるのでしょうか？？

git や diff の差分管理は行が基本単位です。文章とはいえ適時改行しないとパラグラフ全体が巨大な差分として表示されたり広範囲の衝突が発生しやすくなるためです (github などは行内の違いを強調表示しますが、すべての差分管理がそうではありません)。

なるほど，解説頂きありがとうございます．

Kynea0b · 2021-08-17T06:42:18Z

docs/drafts/features/consensus_ja.md

+秘密鍵の所有者のみがハッシュ値 $t$ を算出でき、対応する公開鍵を持つ人であれば誰でもそのハッシュ値の正当性を検証できる点です。
+
+乱数の生成者 $k$ は式 (1) のように自身の秘密鍵 $S_k$ を使ってメッセージ $m$ から証明 (VRF Proof) $\pi$ を生成します。ここでハッシュ値
+$t$ は式 (2) を使って証明 $pi$ から生成することができます。一方、検証者は証明 $\pi$ が秘密鍵 $S_k$ の所有者によってメッセージ $m$ に


一方、検証者は証明 $\pi$ が

の記述ですが，この証明は秘密鍵でハッシュ値が作成されたものであることを秘密鍵の持ち主以外に秘密鍵を知られたくないように，予め秘密鍵をメッセージを使ってハッシュ値作成用に作る値ですから，検証したいのはあくまでハッシュ値であることが伝わる書き方がベターではないかと思います．

* doc: [en] Add ostracon-specific VRF+BLS feature documents (#294) * remove draft, split each topic, change index to README Co-authored-by: leejungho86 <leejungho86@linecorp.com>

torao requested review from tnasu and Kynea0b July 29, 2021 04:08

torao self-assigned this Jul 29, 2021

torao added the C: documentation Classification: Improvements or additions to documentation label Jul 29, 2021

doc: add ostracon VRF+BLS feature document

dfff3ba

torao force-pushed the feature/#286/add_v1.0_documents branch from 2357491 to dfff3ba Compare July 29, 2021 04:11

tnasu requested changes Aug 2, 2021

View reviewed changes

fix a typo

f0963d3

Kynea0b reviewed Aug 2, 2021

View reviewed changes

fix wording of VRF-validation

ff97def

torao force-pushed the feature/#286/add_v1.0_documents branch from cf64fec to ff97def Compare August 3, 2021 12:54

Kynea0b suggested changes Aug 4, 2021

View reviewed changes

Kynea0b reviewed Aug 4, 2021

View reviewed changes

torao requested review from Kynea0b and tnasu August 10, 2021 10:26

tnasu reviewed Aug 11, 2021

View reviewed changes

torao force-pushed the feature/#286/add_v1.0_documents branch from ad1367c to be705de Compare August 13, 2021 11:22

torao requested a review from tnasu August 13, 2021 11:25

tnasu previously approved these changes Aug 13, 2021

View reviewed changes

Kynea0b suggested changes Aug 17, 2021

View reviewed changes

squash

24d7cd1

torao dismissed tnasu’s stale review via 24d7cd1 August 17, 2021 06:33

torao force-pushed the feature/#286/add_v1.0_documents branch from be705de to 24d7cd1 Compare August 17, 2021 06:33

Kynea0b reviewed Aug 17, 2021

View reviewed changes

fix some pointeds

2c5159e

torao requested a review from Kynea0b August 17, 2021 07:30

Kynea0b approved these changes Aug 17, 2021

View reviewed changes

tnasu approved these changes Aug 18, 2021

View reviewed changes

torao merged commit 92e2b95 into Finschia:main Aug 18, 2021

torao changed the title ~~doc: Add ostracon-specific VRF+BLS feature documents~~ doc: [ja] Add ostracon-specific VRF+BLS feature documents Aug 18, 2021

torao added a commit to torao/ostracon that referenced this pull request Aug 18, 2021

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

bee7a2f

torao added a commit to torao/ostracon that referenced this pull request Aug 18, 2021

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

e18d97d

torao added a commit to torao/ostracon that referenced this pull request Aug 18, 2021

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

42ab458

torao mentioned this pull request Aug 18, 2021

doc: [en] Add ostracon-specific VRF+BLS feature documents #304

Merged

torao linked an issue Aug 20, 2021 that may be closed by this pull request

Ostracon Features Document #306

Closed

4 tasks

		@@ -0,0 +1 @@
		🏺

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

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

Conversation

torao commented Jul 29, 2021 • edited Loading

Description

CLAassistant commented Jul 29, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kynea0b Aug 2, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kynea0b Aug 3, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

torao Aug 10, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kynea0b Aug 17, 2021 • edited Loading

Choose a reason for hiding this comment

torao commented Jul 29, 2021 •

edited

Loading

CLAassistant commented Jul 29, 2021 •

edited

Loading

Kynea0b Aug 2, 2021 •

edited

Loading

Kynea0b Aug 3, 2021 •

edited

Loading

torao Aug 10, 2021 •

edited

Loading

Kynea0b Aug 17, 2021 •

edited

Loading