Miscellaneous edits to draft CIP, crypto spec, and cost calculator

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.

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
 

cost-dashboard/index.html

@@ -10,7 +10,7 @@
     <div id="uiHeader">
       <div>
         <h1>Ouroborous Leios cost estimator</h1>
-        <h2>v0.4, <small><a href="https://drive.google.com/file/d/1pH1GYRInevlKcrkpFRJYIvRqFtcv3yFd/view?usp=sharing">video tutorial</a></small></h2>
+        <h2>v0.5, <small><a href="https://drive.google.com/file/d/1pH1GYRInevlKcrkpFRJYIvRqFtcv3yFd/view?usp=sharing">video tutorial</a></small></h2>
       </div>
       <p><em>Explore the costs and benefits of Ouroborous Leios</em></p>
       <p><span style="color:red">WARNING:</span> This is a <em>very preliminary</em> 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&amp;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 <a href="https://discord.com/channels/826816523368005654/1247688618621927505">on Discord</a> or report problems on <a href="https://github.com/input-output-hk/ouroboros-leios/issues">GitHub</a>.</p>
@@ -80,7 +80,7 @@ <h2>v0.4, <small><a href="https://drive.google.com/file/d/1pH1GYRInevlKcrkpFRJYI
           </tr>
           <tr>
             <th>IO <span title="Input/output operations per Input Block">ⓘ</span></th>
-            <td><input id="uiIbIo" type="number" min="0" max="10000" value="1000" step="1"/></td>
+            <td><input id="uiIbIo" type="number" min="0" max="1000" value="10" step="1"/></td>
             <td>IO/IB</td>
           </tr>
           <tr>
@@ -106,7 +106,7 @@ <h2>v0.4, <small><a href="https://drive.google.com/file/d/1pH1GYRInevlKcrkpFRJYI
           </tr>
           <tr>
             <th>IO <span title="Input/output operations per Endorser Block">ⓘ</span></th>
-            <td><input id="uiEbIo" type="number" min="0" max="10000" value="200" step="1"/></td>
+            <td><input id="uiEbIo" type="number" min="0" max="1000" value="2" step="1"/></td>
             <td>IO/EB</td>
           </tr>
           <tr>
@@ -127,7 +127,7 @@ <h2>v0.4, <small><a href="https://drive.google.com/file/d/1pH1GYRInevlKcrkpFRJYI
           </tr>
           <tr>
             <th>IO <span title="Input/output operations per vote.">ⓘ</span></th>
-            <td><input id="uiVoteIo" type="number" min="0" max="10000" value="25" step="1"/></td>
+            <td><input id="uiVoteIo" type="number" min="0" max="100" value="1" step="1"/></td>
             <td>IO/vote</td>
           </tr>
           <tr>
@@ -143,12 +143,12 @@ <h2>v0.4, <small><a href="https://drive.google.com/file/d/1pH1GYRInevlKcrkpFRJYI
           <tr>
             <th rowspan="4">Certificate <span title="A Leios certificate records a successful vote for an Endorser Block.">ⓘ</span></th>
             <th>Size <span title="Size of a certificate.">ⓘ</span></th>
-            <td><input id="uiCertSize" type="number" min="0" max="200" value="15" step="1"/></td>
+            <td><input id="uiCertSize" type="number" min="0" max="200" value="7" step="1"/></td>
             <td>kB/cert</td>
           </tr>
           <tr>
             <th>IO <span title="Input/output operations per certificate.">ⓘ</span></th>
-            <td><input id="uiCertIo" type="number" min="0" max="10000" value="1000" step="1"/></td>
+            <td><input id="uiCertIo" type="number" min="0" max="1000" value="2" step="1"/></td>
             <td>IO/cert</td>
           </tr>
           <tr>

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
 

docs/leios-cip-draft.md

@@ -21,14 +21,44 @@ 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?
 
 > [!NOTE]
 > 
 > 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
 

site/static/cost-estimator/index.html

@@ -10,7 +10,7 @@
     <div id="uiHeader">
       <div>
         <h1>Ouroborous Leios cost estimator</h1>
-        <h2>v0.4, <small><a href="https://drive.google.com/file/d/1pH1GYRInevlKcrkpFRJYIvRqFtcv3yFd/view?usp=sharing">video tutorial</a></small></h2>
+        <h2>v0.5, <small><a href="https://drive.google.com/file/d/1pH1GYRInevlKcrkpFRJYIvRqFtcv3yFd/view?usp=sharing">video tutorial</a></small></h2>
       </div>
       <p><em>Explore the costs and benefits of Ouroborous Leios</em></p>
       <p><span style="color:red">WARNING:</span> This is a <em>very preliminary</em> 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&amp;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 <a href="https://discord.com/channels/826816523368005654/1247688618621927505">on Discord</a> or report problems on <a href="https://github.com/input-output-hk/ouroboros-leios/issues">GitHub</a>.</p>
@@ -80,7 +80,7 @@ <h2>v0.4, <small><a href="https://drive.google.com/file/d/1pH1GYRInevlKcrkpFRJYI
           </tr>
           <tr>
             <th>IO <span title="Input/output operations per Input Block">ⓘ</span></th>
-            <td><input id="uiIbIo" type="number" min="0" max="10000" value="1000" step="1"/></td>
+            <td><input id="uiIbIo" type="number" min="0" max="1000" value="10" step="1"/></td>
             <td>IO/IB</td>
           </tr>
           <tr>
@@ -106,7 +106,7 @@ <h2>v0.4, <small><a href="https://drive.google.com/file/d/1pH1GYRInevlKcrkpFRJYI
           </tr>
           <tr>
             <th>IO <span title="Input/output operations per Endorser Block">ⓘ</span></th>
-            <td><input id="uiEbIo" type="number" min="0" max="10000" value="200" step="1"/></td>
+            <td><input id="uiEbIo" type="number" min="0" max="1000" value="2" step="1"/></td>
             <td>IO/EB</td>
           </tr>
           <tr>
@@ -127,7 +127,7 @@ <h2>v0.4, <small><a href="https://drive.google.com/file/d/1pH1GYRInevlKcrkpFRJYI
           </tr>
           <tr>
             <th>IO <span title="Input/output operations per vote.">ⓘ</span></th>
-            <td><input id="uiVoteIo" type="number" min="0" max="10000" value="25" step="1"/></td>
+            <td><input id="uiVoteIo" type="number" min="0" max="100" value="1" step="1"/></td>
             <td>IO/vote</td>
           </tr>
           <tr>
@@ -143,12 +143,12 @@ <h2>v0.4, <small><a href="https://drive.google.com/file/d/1pH1GYRInevlKcrkpFRJYI
           <tr>
             <th rowspan="4">Certificate <span title="A Leios certificate records a successful vote for an Endorser Block.">ⓘ</span></th>
             <th>Size <span title="Size of a certificate.">ⓘ</span></th>
-            <td><input id="uiCertSize" type="number" min="0" max="200" value="15" step="1"/></td>
+            <td><input id="uiCertSize" type="number" min="0" max="200" value="7" step="1"/></td>
             <td>kB/cert</td>
           </tr>
           <tr>
             <th>IO <span title="Input/output operations per certificate.">ⓘ</span></th>
-            <td><input id="uiCertIo" type="number" min="0" max="10000" value="1000" step="1"/></td>
+            <td><input id="uiCertIo" type="number" min="0" max="1000" value="2" step="1"/></td>
             <td>IO/cert</td>
           </tr>
           <tr>