update-1

Author: oduameh

site/docs/faq.md

@@ -19,25 +19,25 @@ Leios offers several significant advantages:
 
 - **Higher throughput and lower latency.** By splitting transaction processing
   into IB and EB stages, Leios handles more transactions in parallel, enabling
-  faster and more responsive applications.
+  faster and more responsive applications
 - **Better user experience.** Faster transaction processing means quicker
-  confirmations for wallet users and dApp interactions.
+  confirmations for wallet users and DApp interactions
 - **Flexible diffusion strategies.** Nodes can choose how to share blocks (e.g.,
   prioritizing newest or oldest data), optimizing network performance based on
-  conditions.
+  conditions
 - **Enhanced cryptography.** Leios uses Boneh–Lynn–Shacham (BLS) signatures for
   aggregated verification and verifiable random functions (VRFs) for fair leader
-  selection.
+  selection
 - **Robust simulations and formal methods.** Rust and Haskell simulations
   measure real-world performance, and executable specifications ensure
-  correctness.
+  correctness
 - **Scalable cost model.** A cost calculator helps node operators estimate
-  expenses (e.g., storage, CPU usage).
+  expenses (For example, storage, CPU usage).
 
-## What does Leios mean for Cardano users (e.g., wallet users, dApp developers)?
+## What does Leios mean for Cardano users (e.g., wallet users, DApp developers)?
 
 For everyday users, Leios means faster transaction confirmations and a smoother
-experience in wallets and dApps—think near-instant payments or interactions
+experience in wallets and DApps—think near-instant payments or interactions
 instead of waiting 20 seconds or more. For developers, it offers higher
 throughput (more transactions per second), enabling complex, high-volume
 applications like decentralized exchanges or gaming platforms. However, wallets,
@@ -57,11 +57,11 @@ minimize these risks, ensuring Leios remains secure and reliable as it matures.
 
 Leios uses three distinct block types:
 
-- **IB (input block):** a block that contains transactions. Produced by nodes
-  that win the IB sortition lottery.
-- **EB (endorser block):** a block that references one or more IBs, providing
-  endorsements. Produced by nodes that win the EB sortition lottery.
-- **RB (ranking block):** a block that ranks or orders other blocks as part of
+- **IB (Input Block)**. A block that contains transactions. Produced by nodes
+  that win the IB sortition lottery
+- **EB (endorser block)**. A block that references one or more IBs, providing
+  endorsements. Produced by nodes that win the EB sortition lottery
+- **RB (ranking block)**. A block that ranks or orders other blocks as part of
   the consensus mechanism.
 
 Each block type plays a distinct role in moving transactions from submission to
@@ -70,42 +70,49 @@ occur every ~20 seconds.
 
 ## What is the relationship between Ouroboros, Peras, and Leios?
 
-### Ouroboros: The Foundation
+### Ouroboros: The foundation
 
 - What it is: Ouroboros is the overarching family of proof-of-stake (PoS)
   consensus protocols that powers Cardano. It’s designed to be secure,
   energy-efficient, and provably fair, replacing proof-of-work (PoW) systems
   like Bitcoin’s.
 - Key Features:
   - Slot-based time division (epochs and slots, with slots typically 1 second
-    long in earlier versions, now 20 seconds in Praos for block production).
-  - Stake pool leaders elected based on stake to mint blocks.
-  - Formal mathematical proofs of security (e.g., resistance to attacks like
+    long in earlier versions, now 20 seconds in Praos for block production)
+  - Stake pool leaders elected based on stake to mint blocks
+  - Formal mathematical proofs of security (For example, resistance to attacks like
     double-spending or chain forks).
 - Role: Ouroboros is the bedrock consensus mechanism that Peras and Leios build
   upon or refine.
 
-### Peras: A Modular Upgrade
+### Peras: A modular upgrade
 
 - What it is: Peras is a proposed evolution of Ouroboros aimed at improving
   efficiency and modularity.
-- Key Features:
-  - Separation of Concerns: Peras splits consensus into modular components, such
+- Key features:
+<<<<<<< HEAD
+  - Separation of concerns. Peras splits consensus into modular components, such
+    as transaction ordering, validation, and ledger state updates, to allow
+    parallel processing and flexibility
+  - Improved finality. It introduces mechanisms for faster confirmation times,
+=======
+  - Separation of concerns: Peras splits consensus into modular components, such
     as transaction ordering, validation, and ledger state updates, to allow
     parallel processing and flexibility.
-  - Improved Finality: It introduces mechanisms for faster confirmation times,
+  - Improved finality: It introduces mechanisms for faster confirmation times,
+>>>>>>> ceaee0282f9c2d2f0b95d46c26e30d26e9f82847
     potentially reducing the time to finality compared to Praos’ 20-second block
-    intervals.
-  - Adaptability: Designed to integrate with future scaling solutions (like
+    intervals
+  - Adaptability. Designed to integrate with future scaling solutions (like
     Leios) and sidechains or layer-2 systems.
 - Relationship to Ouroboros:
   - Peras is a direct descendant of Ouroboros Praos, refining its mechanics
-    while staying within the PoS framework. It’s like an “Ouroboros 2.0,”
+    while staying within the PoS framework. It’s like an 'Ouroboros 2.0,'
     optimizing the core protocol without fundamentally changing its PoS nature.
   - It serves as a bridge between the foundational Ouroboros Praos and more
     radical scalability-focused variants like Leios.
 
-### Leios: A Scalability Leap
+### Leios: A scalability leap
 
 - What it is: Ouroboros Leios is a specific variant of the Ouroboros family,
   designed to dramatically increase Cardano’s throughput (transactions per
@@ -118,37 +125,37 @@ occur every ~20 seconds.
   - It retains Ouroboros’ security model but reimagines how transactions are
     ingested and validated, making it a next-generation Ouroboros variant.
 
-### The Relationship
+### The relationship
 
 - Ouroboros as the Core:
   - Ouroboros (especially Praos) is the foundational consensus protocol that
     defines Cardano’s PoS system. Both Peras and Leios are built on this
     foundation, inheriting its security properties and stake-based governance.
-- Peras as an Intermediate Step:
+- Peras as an intermediate step:
   - Peras enhances Ouroboros by introducing modularity and efficiency
     improvements, potentially laying the groundwork for integrating advanced
     features like those in Leios. It’s a stepping stone that refines Praos’
     mechanics, making it more adaptable to future needs.
-- Leios as a Scalability Solution:
+- Leios as a scalability solution:
   - Leios takes Ouroboros further by addressing throughput limitations head-on.
     It uses the same PoS principles but introduces a parallel processing model
-    that Peras’ modularity could theoretically support or complement.
-  - Leios can be seen as a “plugin” or evolution that fits into the Ouroboros
+    that Peras’ modularity could theoretically support or complement
+  - Leios can be seen as a 'plugin' or evolution that fits into the Ouroboros
     ecosystem, possibly relying on Peras’ groundwork for smoother integration.
-- Timeline and Evolution:
+- Timeline and evolution:
   - Ouroboros Praos → Current live protocol
   - Peras → A near-future refinement for flexibility and efficiency
   - Leios → A long-term scalability solution, still in research/development,
     aimed at making Cardano competitive with high-TPS blockchains like Solana or
-    Ethereum layer-2s
+    Ethereum layer-2s.
 
 ## What's the state of an IB before an EB or RB gets created for it? Is it visible, is it usable?
 
 Before an Endorsement Block (EB) or Ranking Block (RB) is created, an Input
 Block (IB) is a proposed set of transactions in a preliminary state. Here’s what
 that means:
 
-### State of an Input Block
+### State of an IB
 
 An IB is minted by a node (e.g., a stake pool operator) and contains unconfirmed
 transactions from the mempool. It’s cryptographically signed for authenticity
@@ -174,7 +181,7 @@ still be discarded if it fails validation.
 Leios boosts performance by processing transactions in parallel, even though
 final confirmation still takes 20 seconds. Here’s how:
 
-### Parallel Processing Boost
+### Parallel processing boost
 
 Think of Leios like a factory: In Ouroboros Praos, one worker (a slot leader)
 builds a block every 20 seconds. In Leios, dozens of workers (nodes) create
@@ -183,19 +190,19 @@ Input Blocks (IBs) continuously, others check them with Endorsement Blocks
 This parallelism lets the network handle far more transactions in that
 time—potentially 10x to 100x more than Praos.
 
-### Splitting the Work
+### Splitting the work
 
-- **IBs**: Propose transactions frequently and in parallel.
-- **EBs**: Validate IBs concurrently across nodes.
-- **RBs**: Finalize everything every 20 seconds, ensuring security. Unlike
+- **IBs**. Propose transactions frequently and in parallel.
+- **EBs**. Validate IBs concurrently across nodes.
+- **RBs**. Finalize everything every 20 seconds, ensuring security. Unlike
   Praos, where one block does it all, Leios splits these roles so transaction
   processing isn’t bottlenecked by the 20-second RB interval.
 
-### Practical Gains
+### Practical gains
 
 While IBs aren’t spendable until an RB confirms them, EBs provide early
 confidence, letting apps (like wallets) act on them sooner for low-risk tasks
-(e.g., showing balances). The 20-second RB is a security anchor, not a
+(For example, showing balances). The 20-second RB is a security anchor, not a
 limit—hundreds of IBs can queue up in that window, massively increasing
 throughput.
 
@@ -214,9 +221,9 @@ guarantees.
 
 Leios finalizes blocks through a structured voting mechanism. Nodes may adopt:
 
-- **Single-stage voting:** all votes are broadcast in one phase, possibly
-  resulting in a longer CPU usage 'tail' during high throughput.
-- **Send-recv (two-stage) voting:** votes are first sent, then a follow-up
+- **Single-stage voting**. All votes are broadcast in one phase, possibly
+  resulting in a longer CPU usage 'tail' during high throughput
+- **Send-recv (two-stage) voting**. Votes are first sent, then a follow-up
   receive phase ensures broader propagation before final tallies.
 
 You can configure voting through parameters such as leios-vote-send-recv-stages
@@ -233,9 +240,9 @@ sortition' because once a node proves it was selected to produce a block or vote
 
 Leios supports multiple strategies for propagating blocks and votes:
 
-- **Oldest-first:** prioritizes older blocks or transactions
-- **Freshest-first:** focuses on the newest blocks or transactions first
-- **Peer-order:** requests blocks in the order peers announce them.
+- **Oldest-first**. Prioritizes older blocks or transactions
+- **Freshest-first**. Focuses on the newest blocks or transactions first
+- **Peer-order**. Requests blocks in the order peers announce them.
 
 Your choice of strategy can affect latency, network load, and overall
 throughput.
@@ -253,11 +260,11 @@ sharding, but it is not yet part of Leios.
 Leios incorporates multiple cryptographic techniques to ensure security and
 efficiency:
 
-- BLS signatures: allows efficient aggregation of many signatures into one,
+- BLS signatures. Allows efficient aggregation of many signatures into one,
   reducing verification overhead
-- Mithril or Musen protocols: used for voting and proof aggregation, depending
+- Mithril or Musen protocols. Used for voting and proof aggregation, depending
   on the context
-- VRFs: ensures fair selection of nodes for block production
+- VRFs. Ensures fair selection of nodes for block production.
 
 Recent benchmarking shows that aggregated BLS verification significantly speeds
 up certificate validation.
@@ -290,11 +297,11 @@ Developers continually refine these simulations based on real-world data.
 
 Based on preliminary internal testing and simulations:
 
-- **Block size:** commonly set to about one-third of the available link capacity
+- **Block size**. Commonly set to about one-third of the available link capacity
   for IBs
-- **Voting stages:** choose single-stage or send-recv, depending on reliability
+- **Voting stages**. Choose single-stage or send-recv, depending on reliability
   and speed requirements
-- **Diffusion strategy:** many operators use 'freshest-first,' though
+- **Diffusion strategy**. Many operators use 'freshest-first,' though
   'peer-order' may help maintain compatibility with older setups.
 
 Operators can adjust these parameters, which evolve through community votes.
@@ -306,7 +313,7 @@ You can follow:
 - Weekly updates on the Ouroboros Leios site
 - Technical reports for deeper insights
 - Leios glossary for definitions of commonly used terms
-- Public GitHub repositories that host source code and simulations
+- Public GitHub repositories that host source code and simulations.
 
 These resources provide transparency and regular updates on ongoing development.
 
@@ -315,9 +322,9 @@ These resources provide transparency and regular updates on ongoing development.
 Leios changes how transactions are validated and how blocks and memory pools
 operate, potentially affecting:
 
-- **Wallets and SDKs,** which need to accommodate new block types (IBs and EBs)
-- **Explorers,** which must handle higher throughput and multi-block referencing
-- **Indexers and APIs,** which will see more granular block and vote data.
+- **Wallets and SDKs**. Which need to accommodate new block types (IBs and EBs)
+- **Explorers**. Which must handle higher throughput and multi-block referencing
+- **Indexers and APIs**. Which will see more granular block and vote data.
 
 Weekly updates provide a deeper analysis of these topics, including how advanced
 indexing and potential sharding solutions might eventually mitigate challenges.

site/docs/how-it-works.md

@@ -2,69 +2,66 @@
 sidebar_position: 3
 ---
 
-# How It Works
+# How it works
 
-Leios is a high-throughput overlay protocol designed to enhance blockchain
-scalability, such as for Cardano’s Ouroboros, by managing a structured flow of
-transactions. Here’s a breakdown of how it operates:
+Leios is a high-throughput overlay protocol designed to enhance blockchain scalability—such as for Cardano’s Ouroboros—by managing a structured flow of transactions. Here’s a breakdown of how it operates:
 
-1. **Creating Input Blocks (IBs)**:<br /> Stake pool operators (SPOs), acting as
+1. **Creating Input Blocks (IBs)**<br /> Stake pool operators (SPOs), acting as
    validators, bundle transactions into Input Blocks (IBs) every 0.2–2 seconds
    and broadcast them across the network for parallel processing.
 
-2. **Proofs of Data Availability**:<br /> Validators check that IBs’ transaction
+2. **Proofs of data availability** <br /> Validators check that IBs’ transaction
    data is valid and accessible, a process later confirmed through Endorser
    Blocks (EBs) and voting, ensuring no data is missing or malformed.
 
-3. **Generating Endorser Blocks (EBs)**:<br /> EBs aggregate multiple verified
+3. **Generating Endorser Blocks (EBs)**<br /> EBs aggregate multiple verified
    IBs, grouping them for validation and proposing their inclusion in the
    blockchain’s final ledger.
 
-4. **Pipelined Processing**:<br /> The protocol uses a seven-stage endorsing
+4. **Pipelined processing**<br /> The protocol uses a seven-stage endorsing
    pipeline (detailed below) to process IBs, EBs, and votes in parallel,
    maximizing network bandwidth and throughput.
 
-5. **Voting and Certification**:<br /> Validators vote on EBs using
+5. **Voting and certification**<br /> Validators vote on EBs using
    stake-weighted BLS signatures to certify their correctness and data
    availability, ensuring only compliant IBs (e.g., valid scripts) proceed.
 
-6. **Final Inclusion in the Blockchain**:<br /> Certified EBs are referenced by
+6. **Final inclusion in the blockchain**<br /> Certified EBs are referenced by
    a certificate included in a Ranking Block (RB)—a Praos-style block minted
    every ~20 seconds—finalizing IB transactions on the blockchain while
    maintaining a verifiable, efficient record.
 
 ## Leios architecture
 
-The Leios protocol utilizes a pipelined architecture to achieve high throughput.
-A pipeline instance comprises seven stages:
+Leios uses a pipelined architecture to achieve high throughput. Each pipeline instance includes the following seven stages:
 
 1. **Propose**:<br />
 
    - Validators concurrently generate and propose IBs with transaction data,
-     kicking off the pipeline instance and targeting frequent output (e.g.,
-     every 0.2–2 seconds).
+     kicking off the pipeline instance and targeting frequent output (For example,
+     every 0.2–2 seconds)
    - IBs proposed during this stage are the focus of the current pipeline
      instance.
 
 2. **Deliver1**:<br />
 
    - Time is allocated for proposed IBs to spread across the network using a
      freshest-first diffusion strategy, ensuring honest nodes receive them
-     within a set delay (e.g., Δ_hdr) despite potential adversarial bursts.
+     within a set delay (e.g., Δ_hdr) despite potential adversarial bursts
    - Duration is crucial for ensuring all honest nodes receive IBs before the
      next stage.
 
 3. **Link**:<br />
 
    - Validators create EBs that reference Propose-stage IBs, grouping and
-     ordering them for validation and eventual blockchain inclusion.
+     ordering them for validation and eventual blockchain inclusion
    - EBs serve as containers for grouping and ordering IBs.
 
 4. **Deliver2**:<br />
 
    - Time is allocated for any adversarial IBs referenced by EBs to disseminate,
      ensuring honest nodes have all data needed for fair voting and availability
-     checks.
+     checks
    - Ensures honest nodes have received all relevant IBs before casting votes.
 
 5. **Vote1**:<br />
@@ -77,22 +74,22 @@ A pipeline instance comprises seven stages:
 
    - New EBs reference Vote1-certified EBs, linking across pipeline instances to
      reinforce IB confirmation and ensure high throughput by cross-referencing
-     honest data.
+     honest data
    - Strengthens overall confirmation of IBs.
 
 7. **Vote2**:<br />
    - Validators cast final votes for Endorse-stage EBs, certifying them as
      Vote2-certified if they reference a majority of Vote1-certified EBs,
-     preparing them for RB inclusion and ledger finality.
+     preparing them for RB inclusion and ledger finality
    - Must reference a majority of Vote1-certified EBs.
 
-## Network Resilience
+## Network resilience
 
 Leios counters adversarial tactics with:
 
-- **Freshest-First Diffusion**: Nodes prioritize downloading the newest IBs and
+- **Freshest-first diffusion**: Nodes prioritize downloading the newest IBs and
   EBs (via VRF-based timestamps), limiting delays from malicious message bursts.
-- **Equivocation Proofs**: If a validator double-signs (e.g., sends conflicting
+- **Equivocation proofs**: If a validator double-signs (e.g., sends conflicting
   EBs), honest nodes detect and propagate proofs, ensuring only one valid block
   per slot is processed, minimizing bandwidth waste.
 
@@ -106,4 +103,4 @@ Leios counters adversarial tactics with:
 This pipelined architecture ensures continuous IB generation, parallel
 processing, and robust confirmation, enabling Leios to achieve near-optimal
 transaction throughput (e.g., (1-δ) of network capacity) while resisting
-adversarial tactics like message bursts and equivocations.
+adversarial tactics like message bursts and equivocations.