fix: Update the dead links (#491)

* fix: Update the dead links * (fixup) missing a dead link * (fixup) Modify math with LaTex to embedded form * (fixup) remove the image link of the formula
Finschia · Nov 14, 2022 · a00b7c1 · a00b7c1
1 parent 0681636
commit a00b7c1
Show file tree

Hide file tree

Showing 6 changed files with 19 additions and 39 deletions.
diff --git a/docs/README.md b/docs/README.md
@@ -9,3 +9,7 @@ Welcome to the Ostracon documentation!
 Therefore, sorry for under construction.
 
 Basically, you can find the information on [Tendermint v0.34.8 docs/README.md](https://github.com/tendermint/tendermint/blob/v0.34.8/docs/README.md)
+
+In addition, we have prepared a simple document here.
+* [English](en)
+* [Japanese](ja)
diff --git a/docs/en/01-overview.md b/docs/en/01-overview.md
@@ -56,7 +56,7 @@ Ostracon's consensus state and generated blocks are stored in the State DB and B
 
 * [Extending Tendermint-BFT with VRF-based Election](02-consensus.md)
 * [Transaction Sharing](03-tx-sharing.md)
-* [BLS Signature Aggregation](03-signature-aggregation.md)
+* [BLS Signature Aggregation](04-signature-aggregation.md)
 
 ## Consideration with Other Consensus Schemes
 

diff --git a/docs/en/02-consensus.md b/docs/en/02-consensus.md
@@ -20,19 +20,11 @@ Ostracon's block generation mechanism based on Tendermint-BFT consists of the fo
 
 VRF is an algorithm for generating a hash value $t$ that can be used as a cryptographic pseudo-random number. The differences between VRF and typical hash functions or pseudo-random number generators are that only the owner of the private key can generate the hash value $t$, and anyone with the corresponding public key can verify the correctness of the hash value.
 
-A VRF hash generator $k$ generates a proof $\pi$ (VRF Proof) from the message $m$ using its private key $S_k$ as in Equation (1). Here, the hash value $t$ can be acquired from the proof $pi$ using Equation. (2). On the other hand, to verify that the hash value $t$ was generated by the owner of the private key $S_k$ based on the message $m$, the verifier applies the public key $P_k$ for $S_k$, $m$, and $\pi$ to Equation (3) to verify that both hash values are identical.
+A VRF hash generator $k$ generates a proof $\pi$ (VRF Proof) from the message $m$ using its private key $S_k$ as in Equation `1.`. Here, the hash value $t$ can be acquired from the proof $pi$ using Equation. `2.` On the other hand, to verify that the hash value $t$ was generated by the owner of the private key $S_k$ based on the message $m$, the verifier applies the public key $P_k$ for $S_k$, $m$, and $\pi$ to Equation `3.` to verify that both hash values are identical.
 
-![VRF Expression](../static/consensus/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}
-```
+1. $\pi = {\rm vrf\\_prove}(S_k, m)$
+2. $t = {\rm vrf\\_proof\\_to\\_hash}(\pi)$
+3. ${\rm vrf\\_proof\\_to\\_hash}(\pi) \overset{\text{?}}{=} {\rm vrf\\_verify}(P_k, m, \pi)$
 
 With Ostracon, the Proposer and Voters of the next block are selected randomly by a verifiable random number from the Proposer that created the previous block. A VRF Proof field $pi$ is added to the block for this purpose.
 
@@ -42,8 +34,6 @@ The node that receives the new block initiates the election phase. In this phase
 
 The node selected as the Proposer by this phase picks up the unapproved transactions from its own mempool and generates a proposal block (at this point, the block is not confirmed yet). Then, the Proposer calculates VRF Proof $\pi'$ using the previous VRF Hash $t$ that selected itself, the new block height $h$, and the current round $r$ and sets it to the block.
 
-![VRF Prove](../static/consensus/math_prove.png)
-
 ```math
 \begin{eqnarray*}
 m_h & = & {\rm SHA256}(h \,\|\, r \,\|\, t_{h-1}) \\
@@ -65,8 +55,6 @@ During the verification phase, the following VRF-related verifications are perfo
 * The Proposer that generated the block must be a node selected based on the VRF hash of its previous block. This can be determined by matching the node that actually generated the block with the Proposer selected by weighted random sampling using the VRF hash $t$.
 * The $\pi$ contained in the block must be a VRF Proof generated using the private key of the Proposer. If the $t$ calculated from the VRF Proof $\pi$ matches the $t$ calculated using the `vrf_verify()` function, we can conclude that $\pi$ is not forged.
 
-![VRF Verify](../static/consensus/math_verify.png)
-
 ```math
 {\rm vrf\_verify}(P_i, m_h, \pi_h) \overset{\text{?}}{=} {\rm vrf\_proof\_to\_hash}(\pi_h)
 ```

diff --git a/docs/en/03-tx-sharing.md b/docs/en/03-tx-sharing.md
@@ -24,8 +24,8 @@ With this asynchronization of the mempool, multiple transactions will have a *va
 
 ## Tx Validation via ABCI
 
-ABCI (Application Blockchain Interface) is a specification for applications to communicate with Ostracon and other tools remotely (via gRPC, ABCI-Socket) or in-process (via in-process). For more information, see [Tendermint Specifications](https://github.com/tendermint/tendermint/tree/main/spec/abci).
+ABCI (Application Blockchain Interface) is a specification for applications to communicate with Ostracon and other tools remotely (via gRPC, ABCI-Socket) or in-process (via in-process). For more information, see [Tendermint Specifications](https://github.com/tendermint/tendermint/blob/v0.34.x/spec/abci).
 
-The process of validating unconfirmed transactions also queries the application layer via ABCI. This behavior allows the application to avoid including transactions in the block that are essentially unnecessary (although correct from a data point of view). Here, Ostracon has modified the [CheckTx request](https://github.com/tendermint/tendermint/blob/main/spec/abci/abci.md#mempool-connection) to be asynchronous, so that the validation process for the next transaction can be started without waiting for the result of the ABCI-side validation. This improvement improves performance in environments where applications are allocated separate CPU cores.
+The process of validating unconfirmed transactions also queries the application layer via ABCI. This behavior allows the application to avoid including transactions in the block that are essentially unnecessary (although correct from a data point of view). Here, Ostracon has modified the [CheckTx request](https://github.com/tendermint/tendermint/blob/v0.34.x/spec/abci/abci.md#mempool-connection) to be asynchronous, so that the validation process for the next transaction can be started without waiting for the result of the ABCI-side validation. This improvement improves performance in environments where applications are allocated separate CPU cores.
 
 On the other hand, a side effect of this asynchronization is that the application may receive another CheckTx request while it's processing one ABCI request. For example, a check state internally maintained by the LBM SDK's ABCI application interface ([BaseApp](https://github.com/line/lbm-sdk/blob/main/baseapp/baseapp.go)) must have appropriate exclusive control over this concurrency. To allow such locking scope to be properly configured at the application layer, Ostracon's ABCI has added an API that notifies when RecheckTx starts and ends.
diff --git a/docs/ja/02-consensus.md b/docs/ja/02-consensus.md
@@ -30,22 +30,14 @@ Tendermint-BFT に基づく Ostracon のブロック生成メカニズムは以
 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$ が
+乱数の生成者 $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](../static/consensus/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}
-```
+1. $\pi = {\rm vrf\\_prove}(S_k, m)$
+2. $t = {\rm vrf\\_proof\\_to\\_hash}(\pi)$
+3. ${\rm vrf\\_proof\\_to\\_hash}(\pi) \overset{\text{?}}{=} {\rm vrf\\_verify}(P_k, m, \pi)$
 
 Ostracon では、あるブロックを作成した Proposer による*無作為で検証可能な乱数*によって次の Proposer と Voter を決定します。そして
 ブロックにはそのための VRF Proof フィールド $\pi$ が追加されています。
@@ -60,8 +52,6 @@ Ostracon では、あるブロックを作成した Proposer による*無作為
 作成します (この時点ではまだブロックは確定していません)。このとき、自分を選択した VRF ハッシュ $t$ とブロックの高さ $h$、現在のラウンド
 $r$ に基づいて算出した新しい VRF Proof $\pi'$ をブロックに設定します。
 
-![VRF Prove](../static/consensus/math_prove.png)
-
 ```math
 \begin{eqnarray*}
 m_h & = & {\rm SHA256}(h \,\|\, r \,\|\, t_{h-1}) \\
@@ -87,8 +77,6 @@ prevote, precommit, commit を経て複製され、定足数以上の有効票
 2. ブロックに含まれている $\pi$ が本当にその Proposer の秘密鍵を使って生成された VRF Proof であること。VRF Proof $\pi$ から算出した
    $t$ と、vrf_verify() 関数を使って算出した $t$ が一致していれば $\pi$ が偽造されたものでないと判断できます。
 
-![VRF Verify](../static/consensus/math_verify.png)
-
 ```math
 {\rm vrf\_verify}(P_i, m_h, \pi_h) \overset{\text{?}}{=} {\rm vrf\_proof\_to\_hash}(\pi_h)
 ```

diff --git a/docs/ja/03-tx-sharing.md b/docs/ja/03-tx-sharing.md
@@ -24,8 +24,8 @@ Ostracon は Tendermint の Reactor 実装にキューを追加してトラン
 
 ## Tx Validation via ABCI
 
-ABCI (Application Blockchain Interface) はアプリケーションが Ostracon やその他のツールとリモート (gRPC, ABCI-Socket 経由) またはプロセス内 (in-process 経由) で通信するための仕様です。ABCI の詳細については [Tendermint 仕様](https://github.com/tendermint/tendermint/tree/main/spec/abci)を参照してください。
+ABCI (Application Blockchain Interface) はアプリケーションが Ostracon やその他のツールとリモート (gRPC, ABCI-Socket 経由) またはプロセス内 (in-process 経由) で通信するための仕様です。ABCI の詳細については [Tendermint 仕様](https://github.com/tendermint/tendermint/blob/v0.34.x/spec/abci)を参照してください。
 
-未確定トランザクションの検証過程では ABCI 経由でアプリケーションにも問い合わせを行います。この動作により (データの観点では正しいが) 本質的に不要なトランザクションをブロックに含めないようにアプリケーションが判断することができます。Ostracon ではこのための [CheckTx リクエスト](https://github.com/tendermint/tendermint/blob/main/spec/abci/abci.md#mempool-connection)を非同期化する変更を行い ABCI 側の検証結果を待つことなく次のトランザクションの検証処理を開始できるようにしています。この変更は別のサーバで動作するアプリケーションや、個別の CPU コアが割り当てられているアプリケーション環境でのノードのパフォーマンスを向上させます。
+未確定トランザクションの検証過程では ABCI 経由でアプリケーションにも問い合わせを行います。この動作により (データの観点では正しいが) 本質的に不要なトランザクションをブロックに含めないようにアプリケーションが判断することができます。Ostracon ではこのための [CheckTx リクエスト](https://github.com/tendermint/tendermint/blob/v0.34.x/spec/abci/abci.md#mempool-connection)を非同期化する変更を行い ABCI 側の検証結果を待つことなく次のトランザクションの検証処理を開始できるようにしています。この変更は別のサーバで動作するアプリケーションや、個別の CPU コアが割り当てられているアプリケーション環境でのノードのパフォーマンスを向上させます。
 
 一方この非同期化の副作用として、アプリケーションがある ABCI リクエストの処理を行っている最中に別の CheckTx リクエストを受け付けることになります。例えば LBM SDK の ABCI アプリケーションインターフェース ([BaseApp](https://github.com/line/lbm-sdk/blob/main/baseapp/baseapp.go)) が内部的に保持しているチェック状態はこの並行実行を適切に排他制御する必要があります。このようなロックスコープをアプリケーションレイヤーで適切に設定できるように Ostracon の ABCI は RecheckTx の開始と終了時を通知する API を追加しています。