From 009bd85db34b1783b2f9f8372348b8d6c7b223e9 Mon Sep 17 00:00:00 2001 From: TAKAMI Torao Date: Thu, 25 Aug 2022 18:02:12 +0900 Subject: [PATCH] change doc links to the collect ones within this site --- .github/workflows/coverage.yml | 2 +- README.md | 8 ++++++-- docs/en/01-overview.md | 19 +++++++++---------- docs/en/02-consensus.md | 17 ++++++++--------- docs/en/03-signature-aggregation.md | 5 ++--- docs/ja/01-overview.md | 9 ++++----- docs/ja/02-consensus.md | 17 ++++++++--------- docs/ja/03-signature-aggregation.md | 13 ++++++------- 8 files changed, 44 insertions(+), 46 deletions(-) diff --git a/.github/workflows/coverage.yml b/.github/workflows/coverage.yml index d88d9f8f1..a8503e390 100644 --- 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 index c18b634ef..99489e4e3 100644 --- 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 index 0e3655dcc..22e250cfd 100644 --- 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 index fec20af55..2836c483b 100644 --- a/docs/en/02-consensus.md +++ b/docs/en/02-consensus.md @@ -1,5 +1,4 @@ --- -id: consensus title: Consensus --- @@ -15,7 +14,7 @@ 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 @@ -23,7 +22,7 @@ VRF is an algorithm for generating a hash value $t$ that can be used as a crypto 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,18 +54,18 @@ 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) @@ -74,7 +73,7 @@ During the verification phase, the following VRF-related verifications are perfo 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 index 5bf63852d..0b13e7fbe 100644 --- 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 index 0e9825cc4..71d39d62e 100644 --- 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 index 713832e9a..37c989dd4 100644 --- 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,7 +87,7 @@ 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) @@ -96,7 +95,7 @@ prevote, precommit, commit を経て複製され、定足数以上の有効票 この一連のラウンドを繰り返すことによって無作為なランダムサンプリングをすべてのブロック生成に渡って連鎖させることができます。 -![BFT-based Block Generation](/img/about-lbm/ostracon/consensus/bft_round.png) +![BFT-based Block Generation](../static/consensus/bft_round.png) ここで、ブロックを受信したノードは次の Proposer と Voter がどのノードなのかを決定論的に算出できることを思い出してください。あるラウンドで ブロックの生成や検証の責任を持つノードを明らかにすることによって、選出されながら実際にはその作業を行わなかったり、Eclipse 攻撃のような悪意の diff --git a/docs/ja/03-signature-aggregation.md b/docs/ja/03-signature-aggregation.md index 2ab224d6e..da5a48156 100644 --- a/docs/ja/03-signature-aggregation.md +++ b/docs/ja/03-signature-aggregation.md @@ -1,5 +1,4 @@ --- -id: signature-aggregation title: Signature Aggregation --- @@ -15,7 +14,7 @@ BLS 署名は双線形写像を使用した署名集約が可能な署名アル Ostracon でも BLS 署名によって収集した署名を単一の署名に集約することで 1) ブロックサイズの削減と 2) 検証回数の削減でパフォーマンスの向上を 図っています。 -![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 @@ -34,11 +33,11 @@ BFT 仮定に基づいて全 Voter 数の 2/3+1 個の投票の検証が成功 性能の観点では、単一の署名生成/検証においては BLS 署名よりも Ed25519 署名の方が高速という事実があります。その遅さをブロックサイズ削減や 検証回数削減による改善が上回る分水嶺がどこなのかを注意深く調査しています。 -| アルゴリズム | 秘密鍵 | 公開鍵 | 署名 | 署名作成 | 署名検証 | -| :---------------- | -----: | -----: | ---: | -------: | -------: | -| 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 | +| アルゴリズム | 秘密鍵 | 公開鍵 | 署名 | 署名作成 | 署名検証 | +|:------------------|----:|----:|----:|------:|--------:| +| 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 | Table: 署名アルゴリズムの空間効率と処理時間効率。署名作成/検証のメッセージ長は 1024 バイト。