change doc links to the collect ones within this site

Finschia · Aug 25, 2022 · 009bd85 · 009bd85
1 parent a26c7e6
commit 009bd85
Show file tree

Hide file tree

Showing 8 changed files with 44 additions and 46 deletions.
diff --git a/.github/workflows/coverage.yml b/.github/workflows/coverage.yml
@@ -1,4 +1,4 @@
-name: Test Coverage
+name: Test
 on:
   pull_request:
   push:

diff --git a/README.md b/README.md
@@ -1,13 +1,17 @@
 # Ostracon
 
-[![codecov](https://codecov.io/gh/line/ostracon/branch/main/graph/badge.svg?token=JFFuUevpzJ)](https://codecov.io/gh/line/ostracon)
+![example workflow](https://github.com/line/ostracon/actions/workflows/build.yml/badge.svg)
+![example workflow](https://github.com/line/ostracon/actions/workflows/coverage.yml/badge.svg)
 
-Ostracon is forked from Tendermint Core at 2021-03-15.
+[Ostracon](docs/en/01-overview.md "Ostracon: A Fast, Secure Consensus Layer for The Blockchain of New Token Economy")
+is forked from Tendermint Core at 2021-03-15.
 
 **Node**: Requires [Go 1.18+](https://golang.org/dl/)
 
 **Warnings**: Initial development is in progress, but there has not yet been a stable.
 
+[](docs/en/01-overview.md)
+
 # Quick Start
 
 ## git clone

diff --git a/docs/en/01-overview.md b/docs/en/01-overview.md
@@ -1,5 +1,4 @@
 ---
-id: overview
 title: Overview
 ---
 
@@ -11,11 +10,11 @@ Ostracon is a core-component that provides a Byzantine fault-tolerant (BFT) cons
 
 LINE Blockchain sets out a number of principles to be archived in selecting the technology in order to make the consensus mechanism applicable not only to services on the internet, but also to finance and industry.
 
-**Security**: Completeness and soundness sufficient for practical use, based on cryptographic theory.
-**Consistency**: A consensus algorithm with strong integrity (finality).
-**Fault-Tolerance**: Safety and liveness against system failures, including Byzantine failures.
-**Performance and Scalability**: One block every two seconds with a capability of 1000 TPS or above.
-**Inter-chain Connectivity**: interoperability with other blockchains besides LINE Blockchain.
+1. **Security**: Completeness and soundness sufficient for practical use, based on cryptographic theory.
+2. **Consistency**: A consensus algorithm with strong integrity (finality).
+3. **Fault-Tolerance**: Safety and liveness against system failures, including Byzantine failures.
+4. **Performance and Scalability**: One block every two seconds with a capability of 1000 TPS or above.
+5. **Inter-chain Connectivity**: interoperability with other blockchains besides LINE Blockchain.
 
 P2P consensus algorithms based on BFT are more suitable than Bitcoin-like proof of work (PoW) in terms of functionality and performance. Among them, Tendermint-BFT, with its modern blockchain-optimized design, was the closest implementation in our direction (and even better, it can be connected to Cosmos Hub).
 
@@ -27,14 +26,14 @@ Another feature is the Boneh–Lynn–Shacham (BLS) signature. BLS signature sch
 
 Ostracon includes the Consensus and Networking layers of the three layers that construct a LINE BLockchain node: Application, Consensus, and Networking.
 
-![Layered Structure](/img/about-lbm/ostracon/layered_structure.png)
+![Layered Structure](../static/layered_structure.png)
 
 Transactions that have not yet been incorporated into a block are shared among nodes by an anti-entropy mechanism (gossipping) in the Network layer called mempool. Here, the Network and Consensus layers consider transactions as simple binaries and don't care about the contents of the data.
 
 ## 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                                               |
@@ -53,8 +52,8 @@ Transactions that have not yet been incorporated into a block are shared among n
 
 ## Ostracon Features
 
-* [Extending Tendermint-BFT with VRF-based Election](consensus)
-* [BLS Signature Aggregation](signature-aggregation)
+* [Extending Tendermint-BFT with VRF-based Election](02-consensus.md)
+* [BLS Signature Aggregation](03-signature-aggregation.md)
 
 ## Consideration with Other Consensus Schemes
 

diff --git a/docs/en/02-consensus.md b/docs/en/02-consensus.md
@@ -1,5 +1,4 @@
 ---
-id: consensus
 title: Consensus
 ---
 
@@ -15,15 +14,15 @@ Ostracon's block generation mechanism based on Tendermint-BFT consists of the fo
 
 **Block Verification**. The block proposed by the Proposer is verified by elected Voters. Each Voter votes on whether the block is correct or not, and the votes are replicated by Tendermint-BFT to the other Voters, and if more than 2/3+1 of all Voters vote in favor of the block, the block is officially approved. On the other hand, if a quorum is not reached, the proposed block is rejected and a new round of elections or voting is started over (Tendermint-BFT has several shortcuts depending on the reason for rejection).
 
-![VRF-based Block Generation Round](/img/about-lbm/ostracon/consensus/vrf_based_round.png)
+![VRF-based Block Generation Round](../static/consensus/vrf_based_round.png)
 
 ## VRF-based Consensus Group Election
 
 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.
 
-![VRF Expression](/img/about-lbm/ostracon/consensus/math_expression.png)
+![VRF Expression](../static/consensus/math_expression.png)
 
 ```math
 \begin{eqnarray}
@@ -39,11 +38,11 @@ With Ostracon, the Proposer and Voters of the next block are selected randomly b
 
 The node that receives the new block initiates the election phase. In this phase, it verifies the VRF Proof $\pi$ contained in the block, calculates the VRF hash $t$, which is a "fair pseudo-random number," and selects the Proposer and Voters for this round based on that value. This is done by a simple and fast weighted random sampling based on the probability of selection according to Stake holdings (in other words, based on PoS).
 
-![VRF-based Proposer/Voter Election](/img/about-lbm/ostracon/consensus/vrf_election.png)
+![VRF-based Proposer/Voter Election](../static/consensus/vrf_election.png)
 
 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](/img/about-lbm/ostracon/consensus/math_prove.png)
+![VRF Prove](../static/consensus/math_prove.png)
 
 ```math
 \begin{eqnarray*}
@@ -55,26 +54,26 @@ t_h & = & {\rm vrf\_proof\_to\_hash}(\pi_h)
 
 Note that the message $m$ used to calculate the new VRF Proof $\pi$ doesn't involve the hash value of the block itself. We consider that the hash value of the block is inherently insecure because the Proposer who generates the block can obtain a favorable value by trial and error.
 
-![VRF-based Block Generation](/img/about-lbm/ostracon/consensus/vrf_block_generation.png)
+![VRF-based Block Generation](../static/consensus/vrf_block_generation.png)
 
 A node that is selected as a Voter in the election phase verifies the received Proposal block and votes on it. The votes are replicated by Tendermint-BFT through prevote, precommit, and commit. The block is confirmed if more than a quorum of valid votes are collected.
 
-![VRF-based Block Validation](/img/about-lbm/ostracon/consensus/vrf_block_validation.png)
+![VRF-based Block Validation](../static/consensus/vrf_block_validation.png)
 
 During the verification phase, the following VRF-related verifications are performed in addition to block verification:
 
 * 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](/img/about-lbm/ostracon/consensus/math_verify.png)
+![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)
 ```
 
 By repeating this sequence of rounds, fair random sampling can be chained across all block generation.
 
-![BFT-based Block Generation](/img/about-lbm/ostracon/consensus/bft_round.png)
+![BFT-based Block Generation](../static/consensus/bft_round.png)
 
 Recall here that the node that receives the block can deterministically calculate which nodes are the next Proposer and Voters. By revealing the nodes that are responsible for generating and verifying blocks in a given round, we can penalize nodes that are elected but don't actually perform their responsibility or that behave malicious actions such as Eclipse attacks. On the other hand, it's still difficult to predict the Proposer and Voters beyond one block, as they are only revealed for the minimum necessary time.
 

diff --git a/docs/en/03-signature-aggregation.md b/docs/en/03-signature-aggregation.md
@@ -1,5 +1,4 @@
 ---
-id: signature-aggregation
 title: Signature Aggregation
 ---
 
@@ -11,7 +10,7 @@ Blockchains with a decentralized consensus mechanism need to collect a sufficien
 
 The first paper on BLS signatures was published as a digital signature that could be implemented in a very small size. This technique that was called "pairing" has led to several other interesting features, such as threshold signatures and blind signatures. Ostracon also aggregates the multiple signatures into a single one by BLS to improve performance by reducing block size and reducing the number of verifications.
 
-![BLS Signature Aggregation](/img/about-lbm/ostracon/signature-aggregation/bls_signature_aggregation.png)
+![BLS Signature Aggregation](../static/signature-aggregation/bls_signature_aggregation.png)
 
 ## Public Key Abstraction
 
@@ -24,7 +23,7 @@ In introducing BLS, we have unfortunately found that the BLS signature aggregati
 In terms of performance, Ed25519 signatures are faster than BLS signatures for generating/verifying a single signature. We consider the point where the block size reduction and the verification frequency reduction outweigh the slowness as a watershed point and are carefully investigating to find it.
 
 | Algorithm         | Private Key | Public Key | Signature | Sig Generation | Sig Verification |
-| :---------------- | ----------: | ---------: | --------: | -------------: | ---------------: |
+|:------------------|------------:|-----------:|----------:|---------------:|-----------------:|
 | ECDSA (secp256k1) |         96B |        64B |       64B |           92μs |            124μs |
 | Ed25519           |         64B |        32B |       64B |           49μs |            130μs |
 | BLS12-381         |         32B |        96B |       48B |          233μs |          1,149μs |

diff --git a/docs/ja/01-overview.md b/docs/ja/01-overview.md
@@ -1,5 +1,4 @@
 ---
-id: overview
 title: Overview
 ---
 
@@ -37,7 +36,7 @@ LINE Blockchain はインターネット上の電子サービスのみならず
 LINE Blockchain ノードを構成する Application, Consensus および Networking の 3 つのレイヤーのうち、Ostracon には Consensus と
 Networking レイヤーが含まれています。
 
-![Layered Structure](/img/about-lbm/ostracon/layered_structure.png)
+![Layered Structure](../static/layered_structure.png)
 
 まだブロックに取り込まれていないトランザクションは mempool と呼ばれる Network レイヤーのアンチエントロピー機構 (ゴシッピング) によって
 各ノード間で共有されます。ここで、Network および Consensus レイヤーではトランザクションを単純なバイナリとして扱い、そのデータの内容には
@@ -46,7 +45,7 @@ Networking レイヤーが含まれています。
 ## 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                                               |
@@ -65,8 +64,8 @@ Networking レイヤーが含まれています。
 
 ## Ostracon Features
 
-* [Extending Tendermint-BFT with VRF-based Election](consensus)
-* [BLS Signature Aggregation](signature-aggregation)
+* [Extending Tendermint-BFT with VRF-based Election](02-consensus.md)
+* [BLS Signature Aggregation](03-signature-aggregation.md)
 
 ## Consideration with Other Consensus Schemes
 

diff --git a/docs/ja/02-consensus.md b/docs/ja/02-consensus.md
@@ -1,5 +1,4 @@
 ---
-id: consensus
 title: Consensus
 ---
 
@@ -24,7 +23,7 @@ Tendermint-BFT に基づく Ostracon のブロック生成メカニズムは以
 正式に*承認*されます。反対に、定足数の賛成票が集まらなければ提案されたブロックは拒否され新しいラウンドで選挙または投票からやり直しとなります
 (Tendermint-BFT には拒否の理由によってショートカットする経路がいくつかあります)。
 
-![VRF-based Block Generation Round](/img/about-lbm/ostracon/consensus/vrf_based_round.png)
+![VRF-based Block Generation Round](../static/consensus/vrf_based_round.png)
 
 ## VRF-based Consensus Group Election
 
@@ -36,7 +35,7 @@ $t$ は式 (2) を使って証明 $pi$ から生成することができます
 基づいて生成されたものであることを検証するために、$S_k$ に対する公開鍵 $P_k$ と $m$, $\pi$ を式 (3) に適用して同一のハッシュ値 $t$ が
 生成されることを確認します。
 
-![VRF Expression](/img/about-lbm/ostracon/consensus/math_expression.png)
+![VRF Expression](../static/consensus/math_expression.png)
 
 ```math
 \begin{eqnarray}
@@ -55,13 +54,13 @@ Ostracon では、あるブロックを作成した Proposer による*無作為
 疑似乱数」である VRF ハッシュ $t$ を算出し、その値に基づいてこのラウンドの Proposer と Voter を選択します。これは Stake 保有量に
 応じた選出確率に基づく (つまり PoS に基づく) シンプルで高速な加重ランダムサンプリングによって行われます。
 
-![VRF-based Proposer/Voter Election](/img/about-lbm/ostracon/consensus/vrf_election.png)
+![VRF-based Proposer/Voter Election](../static/consensus/vrf_election.png)
 
 この判定によって選ばれた Proposer が自分自身であれば、そのノードは mempool から未承認のトランザクションを取り出して proposal ブロックを
 作成します (この時点ではまだブロックは確定していません)。このとき、自分を選択した VRF ハッシュ $t$ とブロックの高さ $h$、現在のラウンド
 $r$ に基づいて算出した新しい VRF Proof $\pi'$ をブロックに設定します。
 
-![VRF Prove](/img/about-lbm/ostracon/consensus/math_prove.png)
+![VRF Prove](../static/consensus/math_prove.png)
 
 ```math
 \begin{eqnarray*}
@@ -74,12 +73,12 @@ t_h & = & {\rm vrf\_proof\_to\_hash}(\pi_h)
 VRF Proof $\pi$ を算出するためのメッセージ $m$ にはブロックそのもののハッシュ値は関与しないことに注意してください。ブロックのハッシュ値は
 ブロックを生成する Proposer が試行錯誤によって有利な値を導出できることから本質的に安全ではないと考えています。
 
-![VRF-based Block Generation](/img/about-lbm/ostracon/consensus/vrf_block_generation.png)
+![VRF-based Block Generation](../static/consensus/vrf_block_generation.png)
 
 選出フェーズで自分自身が Voter に選ばれたノードは、受信した Proposal ブロックを検証して投票します。票は Tendermint-BFT により
 prevote, precommit, commit を経て複製され、定足数以上の有効票が集まればブロックが承認されます。
 
-![VRF-based Block Validation](/img/about-lbm/ostracon/consensus/vrf_block_validation.png)
+![VRF-based Block Validation](../static/consensus/vrf_block_validation.png)
 
 検証フェーズではブロックの検証に加えて VRF に関連する以下の検証も行われます。
 
@@ -88,15 +87,15 @@ prevote, precommit, commit を経て複製され、定足数以上の有効票
 2. ブロックに含まれている $\pi$ が本当にその Proposer の秘密鍵を使って生成された VRF Proof であること。VRF Proof $\pi$ から算出した
    $t$ と、vrf_verify() 関数を使って算出した $t$ が一致していれば $\pi$ が偽造されたものでないと判断できます。
 
-![VRF Verify](/img/about-lbm/ostracon/consensus/math_verify.png)
+![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)
 ```
 
 この一連のラウンドを繰り返すことによって無作為なランダムサンプリングをすべてのブロック生成に渡って連鎖させることができます。
 
-![BFT-based Block Generation](/img/about-lbm/ostracon/consensus/bft_round.png)
+![BFT-based Block Generation](../static/consensus/bft_round.png)
 
 ここで、ブロックを受信したノードは次の Proposer と Voter がどのノードなのかを決定論的に算出できることを思い出してください。あるラウンドで
 ブロックの生成や検証の責任を持つノードを明らかにすることによって、選出されながら実際にはその作業を行わなかったり、Eclipse 攻撃のような悪意の