diff --git a/CIP/README.md b/CIP/README.md deleted file mode 100644 index 6e25c2b21..000000000 --- a/CIP/README.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -CIP: TBD -Title: Implement Ouroboros Leios to increase Cardano throughput -Authors: Duncan Coutts -Status: Draft -Type: Core -Created: 2022-11-18 -License: CC-BY-4.0 ---- - -Included documents: [*Ouroboros Leios: design goals and concepts*](leios-design.pdf) - -## Abstract - -As Cardano evolves, there will be increasing demand for greater network -capacity to support new and existing users and applications. The long term -solution is to rebase Cardano on the new Ouroboros Leios protocol. -Ouroboros Leios is a new member of the Ouroboros family that is designed -specifically for high throughput, without compromising security. This will -meet expected future demands, providing a basis for continuing Cardano growth -and scalability. - -## Motivation - -Cardano's current throughput (measured both in data rate and available script -execution time) is adequate for the current demand. There is also some -opportunity to increase the block sizes and script execution limits to meet -emerging future demands for increased network capacity. There are however -fundamental limits to how far the block size and the script execution budget -can be pushed, while maintaining system security. - -Under Ouroboros Praos, in order to ensure the security of the overall system, -blocks must be distributed across the network reliably in "$\Delta$" time slots. -This is set to be 5 seconds on the Cardano mainnet. The block relaying process -is an essentially serial process: blocks must be relayed between consecutive -block producer nodes through a series of intermediate relay nodes. The overall -time that this takes is proportional to the number of network hops between one -block producer and the next, and the network latency of each of those hops -(which must in general span the whole globe). Given that this must always -happen within 5 seconds, this puts a hard upper limit on how large each block -can be and also on how much time can be spent validating transactions and -scripts. - -In order to substantially scale beyond this requires changes to the underlying -blockchain algorithm. There are significant opportunities to scale: the -network and CPU resources on most nodes are almost idle much of the time. With -a different algorithm, these resources can be used to increase the total chain -bandwidth. - -## Specification - -Ouroboros Leios is a substantial new design. To do it justice, we do not -include it in full in this README. Instead, as part of this CIP we include a -larger document that describes Ouroboros Leios in much more detail: - -[*Ouroboros Leios: design goals and concepts*](leios-design.pdf) - -There may be further updates to this design document over time. The latest -published version will be available in the -[IOG research library](https://iohk.io/en/research/library/papers/ouroboros-leios-design-goals-and-concepts/). - -## Rationale - -The included document sets out in more detail the limitations of the existing -design, the goals for the new design, and a design strategy that lead to the -proposed Ouroboros Leios design. It explains how the new design relates to -existing features. It sets out a very high level development strategy for how -Ouroboros Leios can be developed and integrated into Cardano. - -## Path to Active - -The path to the implementation of Ouroboros Leios within Cardano will be a long -one, as it will require substantial research, development and integration -effort. The proposed high level development strategy is set out in the linked -document. - -## Copyright - -This CIP is licensed under [CC-BY-4.0][]. - -[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode -[Apache-2.0]: http://www.apache.org/licenses/LICENSE-2.0 - diff --git a/Logbook.md b/Logbook.md index fdf7eb5c1..c85db1ea2 100644 --- a/Logbook.md +++ b/Logbook.md @@ -13,6 +13,10 @@ - renamed `short-leios` command to `leios` since it covers full variant too. - `short-leios` is kept as alias for compatibility. +### Revisions to cost dashboard + +The [cost dashboard](https://leios.cardano-scaling.org/cost-estimator/) was updated with lower and more realistic IO estimates. + ### Analysis of transaction lifecycle The Jupyter notebook [Analysis of transaction lifecycle](analysis/tx-to-block.ipynb) estimates the delay imposed by each of the seven stages of Full Leios as a transaction moves from memory pool to being referenced by a Praos block. diff --git a/cost-dashboard/Main.agda b/cost-dashboard/Main.agda index b2f41a034..040a3bc7b 100644 --- a/cost-dashboard/Main.agda +++ b/cost-dashboard/Main.agda @@ -26,24 +26,24 @@ baseScenario = ; verify_vcpu_ms_per_tx = 1.50 ; ib_per_slot = 0.25 - ; io_per_ib = 1000.0 + ; io_per_ib = 10.0 ; build_vcpu_ms_per_ib = 300.0 ; verify_vcpu_ms_per_ib = 100.0 ; eb_per_pipeline = 0.8 - ; io_per_eb = 200.0 + ; io_per_eb = 2.0 ; build_vcpu_ms_per_eb = 300.0 ; verify_vcpu_ms_per_eb = 100.0 ; vote_per_pipeline = 500.0 ; kb_per_vote = 0.250 - ; io_per_vote = 25.0 + ; io_per_vote = 1.0 ; build_vcpu_ms_per_vote = 2.0 ; verify_vcpu_ms_per_vote = 3.0 ; cert_per_pipeline = 1.0 - ; kb_per_cert = 75.0 - ; io_per_cert = 1000.0 + ; kb_per_cert = 7.0 + ; io_per_cert = 2.0 ; build_vcpu_ms_per_cert = 200.0 ; verify_vcpu_ms_per_cert = 200.0 diff --git a/cost-dashboard/index.html b/cost-dashboard/index.html index 0057e4582..c0e036605 100644 --- a/cost-dashboard/index.html +++ b/cost-dashboard/index.html @@ -10,7 +10,7 @@

Ouroborous Leios cost estimator

-

v0.4, video tutorial

+

v0.5, video tutorial

Explore the costs and benefits of Ouroborous Leios

WARNING: This is a very preliminary tool for estimating the costs of running Leios nodes. At this point, it is really just useful for structuring thinking about Leios costs and making some very rough calculations for guiding further study. The Leios R&D task aims to refine both the inputs to models like this and the cost model itself. Also note that the design of the Leios protocol itself is under revision. Ask questions on Discord or report problems on GitHub.

@@ -80,7 +80,7 @@

v0.4, ⓘ - + IO/IB @@ -106,7 +106,7 @@

v0.4, ⓘ - + IO/EB @@ -127,7 +127,7 @@

v0.4, ⓘ - + IO/vote @@ -143,12 +143,12 @@

v0.4, Certificate ⓘ Size ⓘ - + kB/cert IO ⓘ - + IO/cert diff --git a/crypto-benchmarks.rs/Specification.md b/crypto-benchmarks.rs/Specification.md index 9b319284d..5825e220f 100644 --- a/crypto-benchmarks.rs/Specification.md +++ b/crypto-benchmarks.rs/Specification.md @@ -46,8 +46,6 @@ Altogether, a key registration occupies $28 + 96 + 2 \times 48 + 448 = 668$ byte Figure 7 of the [Fait Accompli paper](https://iohk.io/en/research/library/papers/fait-accompli-committee-selection-improving-the-size-security-tradeoff-of-stake-based-committees/) provides the algorithm for determining which pools are persistent voters. The inequality for this determination can be computed exactly using rational arithmetic, so there is no danger of round-off errors. The input to the formula is the size of the committee and the distribution of stake among the pools. The Rust type [`fait_accompli::FaSortition`](src/fait_accompli.rs) implements this algorithm. -[The Leios sortition](../docs/technical-report-1.md#sortition) for input blocks (IB), endorser blocks (EB), and votes allows the possibility that a block-producing node may be elected several times in the same slot (for IBs) or pipeline (for EBs and votes). - The non-persistent pools are subject to local sortition (LS) for each vote, based on an updated stake distribution where the persistent voters have been removed and where the distribution is normalized to unit probability. The VRF value for that sortition is the bytes of the SHA-256 hash of the BLS signature on the election identifier $eid$. The probability that a pool with fraction $\sigma$ of the stake is awarded $k$ votes of the committee of $n$ votes is $$ @@ -63,6 +61,7 @@ Each vote has a weight, measured as stake. A quorum is achieved if the weights o The Rust function [`sortition::voter_check`](src/sortition.rs) implements this using rational arithmetic. The same implementation (but different $n$) applies to IBs, EBs, and votes. +[The Leios sortition](../docs/technical-report-1.md#sortition) for input blocks (IB), endorser blocks (EB), and votes allows the possibility that a block-producing node may be elected several times in the same slot (for IBs) or pipeline (for EBs and votes). However, it may be desirable for to limit IBs and/or EBs to one per producer per slot: in this case, the probability of producing the block would be $\mathcal{P} := 1 - e^{- n\sigma}$. ### Votes diff --git a/docs/leios-cip-draft.md b/docs/leios-cip-draft.md index 0051a54bc..170b37617 100644 --- a/docs/leios-cip-draft.md +++ b/docs/leios-cip-draft.md @@ -21,6 +21,13 @@ License: Apache-2.0 > > A short (\~200 word) description of the proposed solution and the technical issue being addressed. +As Cardano evolves, there will be increasing demand for greater network +capacity to support new and existing users and applications. The long term +solution is to rebase Cardano on the new Ouroboros Leios protocol. +Ouroboros Leios is a new member of the Ouroboros family that is designed +specifically for high throughput, without compromising security. This will +meet expected future demands, providing a basis for continuing Cardano growth +and scalability. ## Motivation: why is this CIP necessary? @@ -28,7 +35,30 @@ License: Apache-2.0 > > A clear explanation that introduces a proposal's purpose, use cases, and stakeholders. If the CIP changes an established design, it must outline design issues that motivate a rework. For complex proposals, authors must write a [Cardano Problem Statement (CPS) as defined in CIP-9999][CPS] and link to it as the `Motivation`. - +Cardano's current throughput (measured both in data rate and available script +execution time) is adequate for the current demand. There is also some +opportunity to increase the block sizes and script execution limits to meet +emerging future demands for increased network capacity. There are however +fundamental limits to how far the block size and the script execution budget +can be pushed, while maintaining system security. + +Under Ouroboros Praos, in order to ensure the security of the overall system, +blocks must be distributed across the network reliably in "" time slots. +This is set to be 5 seconds on the Cardano mainnet. The block relaying process +is an essentially serial process: blocks must be relayed between consecutive +block producer nodes through a series of intermediate relay nodes. The overall +time that this takes is proportional to the number of network hops between one +block producer and the next, and the network latency of each of those hops +(which must in general span the whole globe). Given that this must always +happen within 5 seconds, this puts a hard upper limit on how large each block +can be and also on how much time can be spent validating transactions and +scripts. + +In order to substantially scale beyond this requires changes to the underlying +blockchain algorithm. There are significant opportunities to scale: the +network and CPU resources on most nodes are almost idle much of the time. With +a different algorithm, these resources can be used to increase the total chain +bandwidth. ## Specification > [!NOTE] @@ -149,8 +179,6 @@ Altogether, a key registration occupies $28 + 96 + 2 \times 48 + 448 = 668$ byte Figure 7 of the [Fait Accompli paper](https://iohk.io/en/research/library/papers/fait-accompli-committee-selection-improving-the-size-security-tradeoff-of-stake-based-committees/) provides the algorithm for determining which pools are persistent voters. The inequality for this determination can be computed exactly using rational arithmetic, so there is no danger of round-off errors. The input to the formula is the size of the committee and the distribution of stake among the pools. The Rust type [`fait_accompli::FaSortition`](src/fait_accompli.rs) implements this algorithm. -[The Leios sortition](technical-report-1.md#sortition) for input blocks (IB), endorser blocks (EB), and votes allows the possibility that a block-producing node may be elected several times in the same slot (for IBs) or pipeline (for EBs and votes). - The non-persistent pools are subject to local sortition (LS) for each vote, based on an updated stake distribution where the persistent voters have been removed and where the distribution is normalized to unit probability. The VRF value for that sortition is the bytes of the SHA-256 hash of the BLS signature on the election identifier $eid$. The probability that a pool with fraction $\sigma$ of the stake is awarded $k$ votes of the committee of $n$ votes is $$ @@ -166,6 +194,7 @@ Each vote has a weight, measured as stake. A quorum is achieved if the weights o The Rust function [`sortition::voter_check`](src/sortition.rs) implements this using rational arithmetic. The same implementation (but different $n$) applies to IBs, EBs, and votes. +[The Leios sortition](../docs/technical-report-1.md#sortition) for input blocks (IB), endorser blocks (EB), and votes allows the possibility that a block-producing node may be elected several times in the same slot (for IBs) or pipeline (for EBs and votes). However, it may be desirable for to limit IBs and/or EBs to one per producer per slot: in this case, the probability of producing the block would be $\mathcal{P} := 1 - e^{- n\sigma}$. ##### Votes diff --git a/site/static/cost-estimator/index.html b/site/static/cost-estimator/index.html index 0057e4582..c0e036605 100644 --- a/site/static/cost-estimator/index.html +++ b/site/static/cost-estimator/index.html @@ -10,7 +10,7 @@

Explore the costs and benefits of Ouroborous Leios

WARNING: This is a very preliminary tool for estimating the costs of running Leios nodes. At this point, it is really just useful for structuring thinking about Leios costs and making some very rough calculations for guiding further study. The Leios R&D task aims to refine both the inputs to models like this and the cost model itself. Also note that the design of the Leios protocol itself is under revision. Ask questions on Discord or report problems on GitHub.

@@ -80,7 +80,7 @@

v0.4, ⓘ - + IO/IB @@ -106,7 +106,7 @@

v0.4, ⓘ - + IO/EB @@ -127,7 +127,7 @@

v0.4, ⓘ - + IO/vote @@ -143,12 +143,12 @@

v0.4, Certificate ⓘ Size ⓘ - + kB/cert IO ⓘ - + IO/cert