Triage
Updated: 2 Sept 2024
Last updated
Updated: 2 Sept 2024
Last updated
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.
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.
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.
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
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)
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
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
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)
Partner Chains toolkit empowers Cardano Stake Pool Operators (SPOs) to validate and produce blocks for specialized blockchains directly connected to Cardano. This enables SPOs to increase their earning potential while actively contributing to the expansion and diversification of the Cardano ecosystem. By introducing native cross-chain transaction capabilities, Partner Chains enhance scalability and foster seamless interoperability with EVM-based applications, significantly boosting the connectivity and utility of the Cardano network.
If implemented, this item can potentially unlock new revenue streams for Cardano SPOs and supercharge the ecosystem's growth by enabling scalable, cross-chain Partner Chains that enhance connectivity and interoperability across blockchain networks.
Amaru is an open-source project that aims to build a new fully interoperable block-producing node for improving the overall performance the Cardano blockchain. The Amaru node provides a simplified entry point for building things on Cardano by using a modular design and Rust as its main coding language.
If implemented, this item aims to improving all the performance aspects of a Cardano node, enable less resources used for better performance and creating a modular design, giving the opportunity to tailor to the operator use case
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
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
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
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
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
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
Status
Triaged
Drivers
Scalability, Interoperability, Adoption
Secure access to the Cardano blockchain traditionally requires running a full node, which demands significant resources. Mithril addresses this challenge by enhancing security for light clients. It provides efficient cryptographic proofs that allow lightweight clients to directly verify the validity of blockchain data without relying on third parties. This approach not only reduces the resource burden on users but also maintains high security standards, enabling broader participation and adoption across the Cardano ecosystem
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
Status
Triaged
Drivers
Cardano Economic Growth | Cardano Network Effects
Improving the scalability and interoperability of the network
Documentation
Target State
To be added
Definition of Done
To be added
Product Stage
Alpha production
Functional Requirements
Mixed-resource security and block production Facilitate native cross-chain transactions at the consensus layer Reference chain with EVM execution environment
Non-functional Requirements
High scalability and performance. Robust security and fault tolerance. Seamless interoperability with existing Cardano infrastructure.
External Dependencies
Integration with Cardano network protocols - LibP2P. Compatibility with EVM-based applications and tools.
Communication Channel
Website, Github repository, Intersect TWG Discord channel, Videos
Indicative Sizing
3L
Context of Indicative Sizing
Two workstreams: security and cross-chain transactions. Each workstream is a large chunk of work with multiple sub-streams
Dependencies & Dependants
TBC
Hardfork
No
Security Review
TBC
Code Audit
Mandatory prior to production deployment of PCs
Community Endorsement
Yes
Feasibility Study Required?
No
Reviewing Working Group
Yes, already formed TWG Partner Chains
Core Infrastructure
Yes
Item Champion
Karen Chang (Omer Husain, Nick Stanford)
Status
Triaged
Drivers
Bringing diversity and operational resilience to Cardano Performance with no compromise regarding security Focusing on operator experience Resilience in all aspect of the design (Framework, Product, Teams contributing) Interoperability Adoption
Documentation
Repository : https://github.com/pragma-org/amaru Roadmap : https://github.com/orgs/pragma-org/projects/1/views/1
Target State
Bloc producing node capability
Definition of Done
Various use case implemented Audited code base
Product Stage
BRL6 on the client aspects of the node: peer to peer and networking BRL5 on the relay mecanisms: consensus implementation and ledger rules BRL5 on the bloc production aspects of the node
Functional Requirements
Feature parity with the current Cardano node (Haskell) Compatibility with middlewares Testing environment capabilities
Non-functional Requirements
Modular architecture (able to customise the build you're running) Pre-built implementation
External Dependencies
Dolos A first incarnation of a node client, albeit geared towards client applications such as DApps. Dolos is de-facto a foundation which will inspire the design and work on Amaru. Pallas Hosts many Rust primitives and building blocks for the node already powering tools like Dolos. In particular, the networking and serialization logic. java-rewards-calculation A Java re-implementation of the Cardano rewards calculation which can now serve as a reference implementation for a Rust version. uplc An Untyped Plutus Core (UPLC) parser and CEK machine for evaluating Plutus V2 and Plutus V3 on-chain scripts. mithril A stake-based threshold multi-signatures protocol. cardano-multiplatform-library A Rust implementation of various Cardano data and crypto primitives. cncli A Rust implementation of Cardano CLI tools including VRF functionality, and some consensus tooling like leaderlogs.
Communication Channel
Indicative Sizing
2L
Context of Indicative Sizing
Ongoing analysis - Rough estimate for a year : 9 FTE (7 Senior Dev; 1 Engineering Manager; 1 Product/Project manager) Testing infrastructure to be estimated
Hardfork (Yes,No, TBC)
TBC
Security Review
TBC
Code Audit
Yes
Community Endorsement
To be confirmed, currently participating: Blink labs, Cardano Foundation, dcSparks, Sundae Labs, Txpipe
Feasibility Study Required?
No
Reviewing Working Group
TBC
Core Infrastructure (Yes, No, TBC)
TBC
Item Champion
Giorgio Zinetti