Triage
Updated: 2 Sept 2024
Items on the triage have been reviewed by the CIR-WG and accepted to develop further through the process flow. Items in this list may require further input and/or wider discussion at TWG or SIGs as appropriate. From time to time the items on this list will be re-assessed to align with the evolving product direction.
OBL-1. Ouroboros Leios
Ouroboros Leios is a novel protocol extending Ouroboros Praos that aims at dramatically increasing the throughput of Cardano network. Leios is based on the key idea of input endorsers. Whereas in a classical blockchain, the blocks' body directly contains transactions, in Leios the blocks' body can also contain references to Endorser blocks which themselves contain references to so-called Input blocks containing the actual transactions. Those references are certified through a voting mechanism that guarantees a majority of validators agree on the content of Endorser blocks. By decoupling the logic of validating blocks' payload and extending the blockchain, and limiting the work needed to verify the chain, much higher throughput can be achieved and new use cases can be unlocked.
Simulating Leios is a critical precursor to subsequently implementing it because Leios aims to make full use of network bandwidth in a heterogeneous environment where input blocks, endorser blocks, votes, certificates are diffused in addition to the ordinary Ouroboros Praos traffic. Simulation will provide detailed statistics on Leios performance under normal conditions, during congestion, and in the face of adversarial activity. Formal methods are required to verify that the network simulations are faithful to the Leios protocol.
Status | This item is pending validation of business benefits. A SIG is being set up to gather community input to articulate its value. |
Drivers | Scalability |
Documentation | Research paper High-Throughput Blockchain Consensus under Realistic Network Assumptions and repository github:/input-output-hk/ouroboros-leios and web site https://leios.cardano-scaling.org/ Youtube explainer: Scaling Blockchain Protocols |
Target State | Prototyping Simulations, Formal specs |
Definition of Done | Publish simulations, their source code, visualizations, and specifications for community and stakeholder use |
Product Stage | Currently at SRL2 (Target to get to SRL5) |
Functional Requirements | Implement multi-node simulations that are formally verified to be faithful to the Leios protocol; develop analysis and visualization tools to quantify Leios behavior and performance. |
Non-functional Requirements | Simulations can be used interactively by the stakeholder community to study Leios. |
External Dependencies | TBC |
Communication Channel | Website, Github repository, Discord channel, video |
Indicative Sizing | 2L |
Context of Indicative Sizing | Six months of 5 FTEs (1x Architect, 1x Formal Methods Engineer, 2x prototyping engineers, 0.5x Researcher, 0.5x Product Owner) |
Dependencies & Dependant | TBC |
Hardfork (Yes,No, TBC) | Not for this proof of concept |
Security Review | N/A |
Code Audit | N/A |
Community Endorsement | Yes |
Feasibility Study Required? | Yes |
Reviewing Working Group | Consensus, Networking |
Core Infrastructure (Yes, No, TBC) | Yes |
Item Champion | IOR |
Talking Points (Optional) | - Prerequisite to implementing Leios - Builds engineering and business cases for Leios - Lays groundwork for detailed formal specification of Leios in a (revised) CIP |
OBP-1. Ouroboros Peras
Ouroboros Peras modifies the chain-selection rule to include the "boosting" of the dominant chain's blocks by a quorum of votes from periodic randomly-selected voting committees. It reduces the settlement time by orders of magnitude without weakening the existing security guarantees. It is compatible with and orthogonal to Leios and Genesis, and it only has a very minor impact on the resource consumption of block-producing nodes. It requires modification of the chain-selection rule, a small change the the CDDL of the block body, and the creation, transport, and verification of votes and the certificates that witness a quorum of votes. It adds several new protocol parameters.
Peras has synergies with Leios and other proposals that involve voting, certificates, or transport/storage of additional data beyond what Praos and Genesis already handle. The Peras task involves (a) implementing this protocol in the Haskell-based Cardano node, (b) providing node-oriented conformance tests (which are distinct from the already existing protocol-level conformance tests) so that non-Haskell nodes (in Rust, Go, etc.) can be verified, and (c) updating the relevant node documentation and specifications.
One of the key benefits is Peras will dramatically shorten the "settlement" or "finality" time for transactions, providing near-certainty within a couple of minutes regarding whether a block will forever remain on the main chain.
Status | This item is pending validation of business benefits. A SIG is being set up to gather community input to articulate its value. |
Drivers | Adoption |
Documentation | https://peras-staging.cardano-scaling.org (soon to become https://peras.cardano-scaling.org/), https://github.com/input-output-hk/peras-design, and draft CIP to be submitted early August |
Target State | Production |
Definition of Done | Implementation + audit + testnet + hard fork |
Product Stage | Currently at SRL 4 (prototyping, specification, formalization, and conformance testing already completed) |
Service Level | BRL 2 |
Functional Requirements | Implement Peras protocol (described in CIP and research paper) in the Haskell-based Cardano node. |
Non-functional Requirements | Implement a comprehensive, node-level conformance test suite usable by nodes written in any programming language; update node specifications and CDDL; benchmark node network usage to ensure that it increased by less than 20% due to Peras vote and certificate transport. |
External Dependencies | Coordination and architectural coherence with work on other node developments such as Genesis, Leios, and Mithril. |
Communication Channel | Web site, Discord channel, YouTube video, GitHub repository, blog posts |
Indicative Sizing | 2L |
Context of Indicative Sizing | The development, testing, and documentation effort is approximately two person-years. (This estimate does not include ancillary activities like testnet operation.) However, there may be synergies with other items such as Leios, and leveraging those could reduce the combined level of effort. |
Dependencies & Dependant | TBC |
Hardfork (Yes,No, TBC) | Yes |
Security Review | Yes |
Code Audit | Yes |
Community Endorsement | Yes |
Feasibility Study Required? | No |
Reviewing Working Group | Consensus |
Core Infrastructure (Yes, No, TBC) | Yes |
Item Champion | IOR |
Talking Points (Optional) | - High benefit (fast settlement) at low develoment cost and without compromises to security - Synergies with Leios, Mithril, and Genesis - Enables fast interoperability with partner chains and bridges |
BAB-1. Marketplace application for Babel fees
For the purpose of allowing atomic swaps, DApp fee sponsorship, fee coverage, etc., a proposal is raised for ledger changes that (1) add new fields to Tx which allow a top-level tx to contain sub-txs (2) allow individual sub-txs to be unbalanced, and not provide their own collateral inputs or witnesses, but the full batch (top level+sub-txs) must be fully valid, i.e. is balanced, has collateral, etc. (3) showcase how this approach can be extended to other types of intent processing
There are multiple key benefits to this implementation, including (1) transactions can be unbalanced, which allows for performing implicit trades within batches (including covering each others' collateral, fees, minUTxO) (2) scripts can inspect other transactions in the same batch (3) allows deduplication of script and datum data across multiple transactions in one batch and (4) possibility of extension to other intents
Status | This item is pending validation of business benefits. A SIG is being set up to gather community input to articulate its value. |
Drivers | Adoption/Traffic Management |
Documentation | https://iohk.io/en/blog/posts/2021/02/25/babel-fees/ ; https://github.com/cardano-foundation/CIPs/pull/862 CIP has been created, with lots of community input in progress. |
Target State | Production |
Definition of Done | Done within Innovation = prototype built on ledger codebase + CIP, prototype build on Agda codebase (specification); done in production = implemented within a new era in the node + documentation |
Product Stage | Prototype - with Test cases (though changes have been made since), specification |
Service Level | SRL4; BRL1 |
Functional Requirements | new era defined for the node (including ledger, CLI, consensus, etc.), new Plutus version |
Non-functional Requirements | documentation, conformance testing, unit testing, benchmarking |
External Dependencies | Plutus, Dependency for adoption = community development of off-chain infrastructure for Babel fees service |
Communication Channel | CIP-0118 |
Indicative Sizing | M |
Context of Indicative Sizing | TBC |
Dependencies & Dependant | TBC |
Hardfork (Yes,No, TBC) | Yes |
Security Review | Yes |
Code Audit | Yes |
Community Endorsement | Yes |
Feasibility Study Required? | No |
Reviewing Working Group | Ledger |
Core Infrastructure (Yes, No, TBC) | Yes |
Item Champion | IO Innovation |
HYD-1. Hydra Development
There are various scopes that can be potentially developed for this item. Please follow this page and the Hydra working group for future updates to this item.
Interconnecting Hydra heads approaching the full heterogenous vision on scaling solutions for Cardano. By building a lightning-like system for processing payments off-chain at near zero cost and instant finality, we will enable several payment use cases and pave the way for generalized interconnection of Hydra heads isomorphic script execution across off-chain ledgers using Interhead Hydra.
The key benefits are (1) Payments of any fungible Cardano native asset unimpacted by L1 congestion (2) Re-usable payment channels for B2B, B2C and C2C micro-payments (3) Interoperability with Bitcoin Lightning (4) Near-zero cost, instant finality, and full security Cardano transactions processing for small groups of validators (Head protocol)
Status | This item is pending community input to progress. Cardano members are encouraged to join the product SIGs to discuss development direction and user needs. |
Drivers | There is no decentralized future if it is not scalable enough. |
Documentation | https://hydra.family, constellation diagram |
Target State | TBC |
Definition of Done | TBC |
Product Stage | Production |
Service Level | SRL8 |
Functional Requirements | - P2P Hydra node networking (also browser) - HTLC and Adaptor signature swaps - Keep ADA staked in Heads, Pledge usable as collateral - Payment invoices and routing - ... |
Non-functional Requirements | TBC |
External Dependencies | TBC |
Communication Channel | Website, Working group, Discord channels, YouTube video, GitHub repository |
Indicative Sizing | L + 30% |
Context of Indicative Sizing | Current team size for 12 months + 30% for support, special projects |
Dependencies & Dependant | TBC |
Hardfork (Yes,No, TBC) | No |
Security Review | TBC |
Code Audit | Yes |
Community Endorsement | - Proposals and projects depending on Hydra: Wine Supply Chain Tracking, Hydra-Enabled Accounting and Micropayments System, API pay-per-use (Blockfrost, Demeter, ...), Ikigai Auctions, ... - New revenue stream for SPOs (running Hydra payment channel network nodes) and infrastructure projects like iagon |
Feasibility Study Required? | No. Research papers and bitcoin lightning sets a precedent, while small related R&D project already underway. |
Reviewing Working Group | |
Core Infrastructure (Yes, No, TBC) | TBC |
Item Champion | Trym Bruset (primary), Sebastian Nagel (secondary) |
Talking Points (Optional) | TBC |
TLM-1. Timeliness Market
Provides the ability to ensure the insertion of a transaction over a given (short) time frame into the chain with a high level of assurance irrespective of the load on the chain at that time
Key benefits are the assurance that key transactions occur in a given time frame - eg oracles for dApps, payments with real-world deadlines, etc
Status | This item is pending validation of business benefits. A SIG is being set up to gather community input to articulate its value. |
Drivers | Need for assured insertion of transactions into the chain in a given timeframe - assurance known hours, days, weeks in advance; Existence of such assurance (and where a contractual commitment can be made - feasible in this approach) helps ameliorate risks inherent in various use cases of Cardano in dApps and other commercial processes. |
Documentation | As published Google Docs and Report on Cardano timeliness constraints.pdf |
Target State | Two possible targets: 1) changes to cardano-node (additional call in client-to-node API; minor change to mempool structure) or 2) which is (1) + initial activity to develop the "Cardano Timeliness Future Market" |
Definition of Done | for (1) - code base updated, property tests written and integrated, regression testing completed |
Product Stage | TBC |
Service Level | TBC |
Functional Requirements | TBC |
Non-functional Requirements | TBC |
External Dependencies | for (1) - none; for (2) - needs an appropriate ecosystem to evolve to create futures market |
Communication Channel | TBC |
Indicative Sizing | for (1): Development Effort: 4-6 person months (development and property tests); regression testing in addition to this |
Context of Indicative Sizing | just (1); (2) would need different skills including indivdual to spearhead the market creation` |
Dependencies & Dependant | TBC |
Hardfork (Yes,No, TBC) | No |
Security Review | No change to security model - not needed |
Code Audit | External audit not needed, internal auditing (as part of standard development process) along with suitable property coverage should be sufficient |
Community Endorsement | TBC |
Feasibility Study Required? | No, the effort requirements are low, feasilblity study would probably represent as great an effort as low-level design and implementation |
Reviewing Working Group | TBC, Network |
Core Infrastructure (Yes, No, TBC) | Yes |
Item Champion | Neil Davies |
Talking Points (Optional | TBC |
PUW-1. Proof of Useful Work for Deep Learning
Use the training process of deep learning as “useful work” for validators to elect a block producer ensuring traceability of dataset and models trained, and obtained accuracy.
While PoW is secure, PoUW is a greener solution in which validators compute useful tasks instead of solving mathematical puzzles that have no other purpose than selecting a block producer
Status | Drafting |
Drivers | Innovation, Sustainability (ESG), Security (with Minotaur, a PartnerChain could leverage PoS & PoUW), Blockchain-based AI |
Documentation | |
Target State | From SRL2 (research paper) to SRL5. From BRL0 (concept in validation) to BRL4. |
Definition of Done | Prototype(s), Simulations, Full specifications, Target Neural Networks models identified |
Product Stage | R&D |
Service Level | SRL2 |
Functional Requirements | Demonstrate feasibility and total addressable market depending on which Neural Networks (RNN, CAN, LLM, SLM, etc.) can run in the constraints of the protocol |
Non-functional Requirements | Identify the time/memory/computing/networking constraints of the protocol for Deep Learning models for the validators. Validate that models can be trained improving accuracy. |
External Dependencies | TBC |
Communication Channel | Website, Github repository, Discord channel, videos |
Indicative Sizing | 4-5L |
Context of Indicative Sizing | 1 year of formal methods, ML, prototyping, architecture, applied crypto engineers with support of researchers |
Dependencies & Dependant | Might require cooperating with AI specialized companies as well as AI data providers/consumers |
Hardfork (Yes,No, TBC) | No, this is not intended for Cardano Mainnet, most likely PartnerChains |
Security Review | No |
Code Audit | No |
Community Endorsement | TBC |
Feasibility Study Required? | TBC |
Reviewing Working Group | Consensus |
Core Infrastructure (Yes, No, TBC) | TBC |
Item Champion | Romain Pellerin (IOR) |
Talking Points (Optional) | PoW is secure, PoUW is a greener solution for PoW in which you use computational power to serve useful tasks instead of solvin mathematical puzzles that have no other purpose then selecting a block producer |
MTH-1. Mithril
Mithril is a stake-based multi-signature scheme that leverages the Cardano network to provide certified snapshots of all or part of the blockchain state. These snapshots are valuable for various use cases, including secure voting, data exchange, and synchronization between applications, sidechains, and light wallets.
The beta version of Mithril was successfully launched on the mainnet in July 2023, enabling faster bootstrapping of Cardano nodes. Since then, numerous improvements and optimizations have been made, enhancing the protocol’s functionality and robustness. While Mithril has reached a mature state, two critical areas require further development to ensure readiness for real-world use cases: decentralization and sustainability.
Use cases include: snapshotting / fast bootstrap, more secure light wallets, trustless bridges (related catalyst proposal)
Status | Triaged |
Drivers |
|
Documentation | Mithril: Stronger Lighter Blockchain for better efficiency Cardano Decentralised Message Queue |
Target State | Production |
Definition of Done | TBC |
Product Stage | BRL 6 |
Functional Requirements | Anybody can run an aggregator. |
Non-functional Requirements | Fully decentralized and sustainable protocol, including an incentive model which ensure SPO participation. |
External Dependencies | TxPipe to implement node-to-client mini-protocol in Pallas library |
Communication Channel | TBC |
Indicative Sizing | Large (For Network only) Full Solution = 5L + 1L Networking Team Support = 6L |
Context of Indicative Sizing | Protocol maintenance and enhancements, decentralization of signer key registration and P2P signature broadcast, enabling multiple aggregators, design and implement an incentive model |
Dependencies & Dependant | TBC |
Hardfork (Yes,No, TBC) | TBC |
Security Review | Yes |
Code Audit | Partial |
Community Endorsement | Yes |
Feasibility Study Required? | Yes, we have started with some of the feasibility studies but more will be required |
Reviewing Working Group | Consensus/Network |
Core Infrastructure (Yes, No, TBC) | Yes |
Item Champion | Reza Baram / Marcin Szamotulski |
Last updated