List of Inflight items (2024)
Updated: 19/08/2024
This page is written on behalf of the Core Infrastructure Roadmap working group, the information contained is subject to change and amendment by the working group at any time.
Introduction
The objective of this document is to provide context for the inflight items within Intersect. This list was developed in collaboration with the various suppliers and item champions to encourage accuracy. At the end of this document, we will provide details of future planned work to improve this list further. If you like to read more of the progress on the milestones and deliverables, please refer to the milestone reports published here.
The CIR-wg recognises that public accessibility becomes inherently important as an Open Source environment, however not all documents linked below are publicly accessible - Please send a request to the document owners if you require access to view them!
OCG-1. Cardano Onchain Governance - Voltaire Era (Pre-contracted)
Onchain governance is being implemented on Cardano by engaging with the Community in an open dialogue, the implementation is being carried out primarily by implementation of CIP-1694 on the Blockchain
CIP-1694 is implementing a set of Ledger rules to provide the following:
expose a set of Governance Actions which will allow Community to create governance-actions which can be voted by Ada holders
key management for Constitutional Committee (CC) - the CC is a selected group composed of founding and Community Members who opine on the validity of a raised Governance Action
voted Delegated Representatives (DReps) who see voting power to represent smaller community Ada holders in a larger bloc and vote based on their view on the value of a 'proposed Cardano change' Implementation: IOI have been engaged to implement CIP-1694 based on work already being in-flight, and fitness to undertake the work as deemed by Technical Steering Committee (TSC) and community support for this work to be prioritized
Drivers | Decentralization|Regulatory Compliance|Ecosystem |
Documentation | |
Target State | Onchain Voting available for community members |
Definition of Done | Implementation + Documentation + Service Level Agreements |
Product Stage | Write CIP | Proof of Concept | Research | Standalone, Prototype |
Functional Requirements | Implement onchain voting using an agreed set of Governanace actions, provide interface to GovTool to vote as a DRep |
Non-functional Requirements | Votes to be possible in the agreed epoch |
External Dependencies | Tooling will need to be upgraded such as Wallets, Indexers to work with new Cardano Era |
Communication Channel | Cardano update/Telegram/Twitter/Discord |
Indicative Sizing | 15L |
Context of Indicative Sizing | This will require work on Ledger, Plutus and peripheral tool including wallets and indexers |
Hardfork (Yes,No, TBC) | Yes |
Security Review | Yes |
Code Audit | Yes |
Community Endorsement | Yes |
Feasibility Study Required? | Yes |
Reviewing Working Group | Ledger Working Group |
Core Infrastructure | Yes |
Item Champion | IO Engineering |
LSM-1. Increase Capability to store UTxOs on disk using LSM (Pre-contracted)
With the continued growth of the Cardano Blockchain Ledger, the need to move the ledger state from memory (RAM) to disk is ever more pressing and important. Once achieved, this will enable Cardano to reach Bitcoin scale in terms of the number of users & wallets and the size of the UTxO set. At the same time SPOs nodes and full node wallets will be able to function on commodity hardware, including cheap cloud instances. Until this is achieved however, the RAM use of full nodes will inexorably increase, with corresponding increased costs for SPOs and full node wallet users for ever-bigger hardware capacity.
The implementation of the LSM component is a crucial enabling step that provides the combination of features, performance and testability needed to support storing the bulk of the ledger state on disk. The LSM component itself is standalone. A follow-up stage of the project will be to fully exploit it within the node (in the consensus and ledger layers) to store all the large portions of the ledger state on disk, both the UTxO and the several stake-related tables.
The component itself takes the form of a Haskell library for managing tables of key-value data stored persistently on disk. The component is specified as a stand alone component, in isolation from Cardano, with detailed functional and non-functional requirements. These requirements have been chosen to support the scaling goals for Cardano. For example, one performance target is to have a table (corresponding to the characteristics of the UTxO) of 100 million entries - which is roughly the size of Bitcoin - while achieving certain throughput targets. The work is structured as a fixed price, fixed schedule contract, with fixed functional and non-functional requirements.
Drivers | Scaling - making the node's RAM use (mostly) independent of the size of the ledger state should allow Cardano to reach Bitcoin scale in size (UTxO and total number of users/wallets) |
Documentation | |
Target State | Produce a new Log Structured Merge Tree implementation for Cardano. |
Definition of Done | The criteria for demonstrating that the requirements are met are specified in the contract. |
Product Stage | Full standalone product, but integration outstanding |
Functional Requirements | Detailed functional requirements in the contract. |
Non-functional Requirements | Detailed non-functional requirements in the contract. |
External Dependencies | None, but using/integrating the LSM is a follow-up task. |
Communication Channel | Intersect Development Updates Intersect Knowledge Base |
Indicative Sizing | L |
Context of Indicative Sizing | Data estimated for total personnel x FTE based on milestones |
Hardfork | Not required |
Security Review | |
Code Audit | |
Community Endorsement | Nothing systematic or formal |
Feasibility Study Required? | Covered already by the report "Storing the Cardano ledger state on disk: requirements for high performance backend", Version 0.9, July 2023 |
Reviewing Working Group | Node Working Group |
Core Infrastructure | Yes |
Item Champion | Well-Typed |
Talking Points (Optional) | Scaling to Bitcoin size in terms of number of users & wallets, while still running on commodity hardware, and supporting future transaction throughput targets. |
ZKP-1. Implement Zero Knowledge proof (Pre-contracted)
With the growth Layer1 traffic, the ability to create a mechanism to allow the verification of information in a sidechain where all the underlying data is not necessarily needed, but a mechanism to ensure a high level of security, privacy and traceability is needed; this can be achieved using Zero Knowledge proofs.
The Midnight blockchain was recently announced, a sidechain of Cardano that leverages zero-knowledge proofs (ZKPs). To aid in the launch of Midnight, side chains and future interoperability of Cardano as a whole, Galois work in collaboration with Intersect, IOI and the Electric Coin Company to implement recursion in a codebase Completed tasks, code deliverables, will be submitted for review via pull requests and will include unit and property based tests to improve quality. Pull requests will be made to the open source repository or the corresponding Privacy Scaling Explorations fork of the repository. All code deliverables will be implemented in Rust.
Drivers | Interoperability - enabling the ability to trade between blockchains |
Documentation | TBC |
Target State | Recursive ZKPs for IPA and KZG in Halo2 |
Definition of Done | Implementation + Documentation |
Product Stage | Proof of Concept | Research | Standalone, Prototype |
Functional Requirements | Rust implementations in Halo2 for the Poseidon SAFE spec, recursive PLONK verification, IPA folding, KZG folding, and Incrementally Verifiable Computation (IVC) |
Non-functional Requirements | API for users to run IVC |
External Dependencies | Rust packages: halo2curves, halo2_proofs |
Communication Channel | Cardano update/Telegram/Twitter/Discord |
Indicative Sizing | 10L |
Context of Indicative Sizing | This requires building all the components for recursion and IVC itself |
Hardfork | No |
Security Review | This is a cryptographic implementation to verify state without needing to know the entire state |
Code Audit | - |
Community Endorsement | Which community structure involved? |
Feasibility Study Required? | No |
Reviewing Working Group | Plutus Working Group |
Core Infrastructure | Yes (Plutus) |
Item Champion | Galois |
EDU-1. Enabling Documenting tools including Serialisation, Wallets and Education supporting Age of Voltaire (Pre-contracted)
With the age of Voltaire comes a new set of components, concepts and Governance mechanisms across Cardano, this deliverable includes upgrade of Yoroi Wallet, Serialisation library and also set of Education tools to usher in Voltaire.
Q1 2024 to produce a number of high quality Educational Materials - A covering every aspect of the ‘Age of Voltaire’, with study guides, videos and webinars, this includes all things CIP 1694. This supports growth and understand in all community members new and old. The development and testing of Cardano Serialisation library, including the Cardano Serialisation library updates required for CIP 1694. This is a library, written in Rust, for serialization & deserialization of data structures used in Cardano's Haskell implementation of Alonzo along with useful supporting utility functions.
Drivers | Conway-compatible CSL and both Yoroi Mobile and Extension to enabling users a smooth transition to the post-Chang hard fork. And Voltaire education series to educate the community about the governance era in Cardano including CIP-1694. |
Documentation | Cardano Serialization Library, Yoroi Extension Wallet, Yoroi Mobile Wallet, Education (WIP) Project stemmed from CIP-1694 |
Target State | Upgraded CSL Library, Yoroi (Extension & Wallet) to support Conway Ledger Era, and launched educational series to explain all things Voltaire including CIP 1694 |
Definition of Done | All the items mentioned are upgraded, the final video series are uploaded to EMURGO Education Platform. |
Product Stage | Standalone, Prototype |
Functional Requirements | Accessible and maintained CSL builds with Conway functionality, Conway and CIP-95 being released in Yoroi wallets and extensions. |
Non-functional Requirements | Education videos to be released in online education platform and being branded accordingly |
External Dependencies | TBC |
Communication Channel | EMURGO & Intersect Communication Channels |
Indicative Sizing | - |
Context of Indicative Sizing | - |
Hardfork | Yes for some items and No for some |
Security Review | N/A |
Code Audit | N/A |
Community Endorsement | No |
Feasibility Study Required? | Yes |
Reviewing Working Group | TBC |
Core Infrastructure | Yes |
Item Champion | EMURGO |
OBG-1. Implementing the Ouroboros Genesis protocol (Pre-contracted)
Genesis is a new version of the Consensus layer that allows new nodes to join the network without requiring a trusted set of peers to bootstrap from. This should ultimately allow decommissioning the core relays.
All implementation work, in addition to appropriate testing, benchmarking, and documentation is a continuation of work from 2023. This covers the remaining testing infrastructure, as well as the full system test suite designed to verify and validate the Genesis implementation.
Drivers | Interoperability & Transparency - enables new nodes to join the Cardano blockchain and bootstrap themselves without relying on a trusted service |
Documentation | |
Target State | Stipulated in the Contract |
Definition of Done | Stipulated in the Contract |
Product Stage | Testing and benchmarking |
Functional Requirements | Stipulated in the Contract |
Non-functional Requirements | Stipulated in the Contract |
External Dependencies | NA |
Communication Channel | NA |
Indicative Sizing | Stipulated in the Contract |
Context of Indicative Sizing | Stipulated in the Contract |
Hardfork | Not required |
Security Review | Y |
Code Audit | Y |
Community Endorsement | NA |
Feasibility Study Required? | NA |
Reviewing Working Group | Node Working Group |
Core Infrastructure | Yes |
Item Champion | Tweag |
OSM-1. Deliver an Open Source methodology for Cardano (Pre-contracted)
The Open Source Office (OSO) and the Open Source Committee (OSC) are tasked with ensuring Core Cardano becomes efficiently open sourced by creating a strategy (OSS) to curtail the situation.
Intersect, since January, took ownership of 27 “Core-Cardano” repos which are very centralized in nature from previous IOG management. There are strategies and policies in place but need to undergo testing and evaluation with reference to their implementation. Tweag is contracted to support bodies of work done by the Intersect OSPO.
Drivers | Make Cardano truly Open Source Develop open Source Strategy with OSC Help get OSO fully functional. |
Documentation | |
Target State | Open Source Strategy, Pilot to test strategy, and operational Open Source Office |
Definition of Done | OSC adopted Strategy and fully operational open source office according to these slides, Pilot program to test open source maturity |
Product Stage | Not Applicable, but delivery fully matured |
Functional Requirements | Staff the OSO to support core delivery service, have OSC adopt a strategy, and coordinate OS pilot |
Non-functional Requirements | Help with various items the OSO has in works |
External Dependencies | Open Source Office Staff, Open Source Committee |
Communication Channel | Discord, Gitbook, Github |
Indicative Sizing | Not Applicable |
Context of Indicative Sizing | Not Applicable |
Hardfork | Not Applicable |
Security Review | Not Applicable, but did assist in drafting of security policy for Intersect drafted here |
Code Audit | Not Applicable |
Community Endorsement | Yes, OSC Adoption and Community Feedback into Open Source Strategy |
Feasibility Study Required? | Yes, OSC Adoption and Community Feedback into Open Source Strategy |
Reviewing Working Group | Open Source Committee, Strategy Working Group (now closed, due to task completion) |
Core Infrastructure | Support Core Infra in open Source development practices |
Item Champion | Tweag |
Talking Points (Optional) | Everything to be done by End of Q2, only pilot results remain to be published. |
GOV-1. Implementation of GovTool user journeys (Pre-contracted)
Disclaimer: Govtool consists of multiple vendors, there’s pending work to split this out by vendors. This item presents the implementation from Byron Network OU
GovTool is a webApp that implements key governance tools for important governance user journeys. Two key flows; DRep Explorer flow, Governance Action Submission flow, will be added in order to deliver a usable tool to the Cardano Community.
This implementation was previously worked on and will be continued by supporting the launch and running a beta testing period to discover and fix bugs, collect feedback and ideas for the community.
Drivers | Collective governance, Interoperability, Transparency |
Documentation | |
Target State | An MVP governance system |
Definition of Done | |
Product Stage | Prototype |
Functional Requirements | Users able to delegate to DReps, DReps able to vote on Governance Action |
Non-functional Requirements |
|
External Dependencies | Cardano Node (Conway Era) |
Communication Channel | Discord, Github |
Indicative Sizing | L |
Context of Indicative Sizing | UI build, integration components |
Hardfork | Yes - it requires Chang Hardfork |
Security Review | No |
Code Audit | No |
Community Endorsement | Supported by Community |
Feasibility Study Required? | No |
Reviewing Working Group | Governance Tool Working Group |
Core Infrastructure | Yes |
Item Champion | Ryan Williams |
HWW-1. Ensure interoperability, performance and accessibility of Hardware Wallets (Pre-contracted)
The Ledger devices and Trezor devices are the most popular products on the market for secure management of cryptocurrencies - to ensure its continued practicality and use for the Cardano community a number of enhancements have been contracted.
Work is done to ensure the continued practical use of the Ledger and Trezor hardware wallets for the Cardano community and enhancements to support the Conway era.
Drivers | Provide desired level of security to Voltaire era governance participants Increase participation in governance by enabling most popular HW wallet holders to participate with HW wallet |
Documentation | |
Target State | Trezor and Ledger owners are able to fully participate in Cardano on-chain governance |
Definition of Done | Released by Ledger and Trezor in production |
Product Stage | Trezor - released Ledger - waiting for release (planned 7/2024) |
Functional Requirements | Update following codebases and documentation to enable CIP-95. Ledger’s Cardano app device firmware Ledger’s Cardano App Javascript interface Trezor’s device firmware Trezor’s Connect Suite Cardano HW wallet interoperability library Cardano HW Wallet CLI Cardano Improvement Proposal 21
Analyze and implement following: Voltaire/Conway analysis Stake (de)registration with deposit Delegation to DReps Serialization with tag 258 Redesign of certificate-related code New key derivation schemas (for Ledger except for Nano S) DRep registration (for Ledger except for Nano S) Committee certificates (for Ledger except for Nano S) Voting (for Ledger except for Nano S) Treasury and donations (for Ledger except for Nano S) Integration Layer |
Non-functional Requirements | communication with Ledger, Trezor, security auditors and other stakeholders; project management; npm releases |
External Dependencies | Ledger & Trezor release process |
Communication Channel | Slack, Email |
Indicative Sizing | S |
Context of Indicative Sizing | 0.75 FTE x 9 months |
Hardfork | No |
Security Review | Not related directly to Cardano blockchain security but relevant for overall Cardano governance security |
Code Audit | Yes - Ledger code audited by Kudelski, Trezor code audited by Trezor team |
Community Endorsement | Not directly but related project had great Catalyst support https://projectcatalyst.io/funds/10/f10-products-and-integrations/message-signing-for-trezor-and-ledger-cip-8-cip30 |
Feasibility Study Required? | No |
Reviewing Working Group | N/A |
Core Infrastructure | Related to core Cardano infrastructure as all the big Cardano holders use Trezor or Ledger |
Item Champion | Vacuumlabs |
GOV-2. Enable a Proposal Discussion tool (Pre-contracted)
Proposal Discussion Forum (PDF) is a subset of GovTool, which consists of multiple vendors, there’s pending work to split this out by vendors. This item presents the implementation from WeDeliver.
With on-chain governance, introduced by CIP-1694, ada holders will be empowered to submit a governance action (GA) directly onto the Cardano mainnet. This ability will transform how decisions are made for the blockchain. To support CIP-1694's on-chain features, during the course of the CIP-1694 community workshops, attendees consistently requested off-chain processes and features to ensure GA's have been widely considered and socialized before they are submitted on-chain. In response, a grant was opened to develop a proposal discussion forum. As part of a new feature in the Govtool, the Proposal Discussion Forum enables, promotes, and facilitates structured public discourse, and presents the most relevant information about proposals. The tool will ultimately support ada holders when evaluating the strength of a proposal (and a subsequent governance action).
Drivers | Collective governance, Interoperability, Transparency |
Documentation | Related CIP (CIP-1694): https://github.com/cardano-foundation/CIPs/tree/master/CIP-1694 Knowledge Base Grant : https://docs.intersectmbo.org/intersect-community-grants/closed-grants/proposal-discussion-forum |
Target State | A polished tool enabling users to participate in Cardano collective governance with user friendly voting |
Definition of Done | Implementation + Documentation + Service Level Agreements |
Product Stage | Deployed in Testnet, Preparing for Mainnet |
Functional Requirements | |
Non-functional Requirements | |
External Dependencies | Govtool |
Communication Channel | Intersect MBO Website Discord |
Indicative Sizing | M |
Context of Indicative Sizing | 3 resources in total: 1 Product Design and 2 technical roles working intermittently, during 7 months |
Hardfork | No |
Security Review | No |
Code Audit | No |
Community Endorsement | Yes - through CIP-1694 workshops |
Feasibility Study Required? | No |
Reviewing Working Group | Wallets TWG |
Core Infrastructure | No |
Item Champion | WeDeliver |
CHG-1. Chang Hard Fork Testing (Pre-contracted)
Supporting Chang hard fork development activities by performing regression testing and testing of new features.
Drivers | Decentralization|Regulatory Compliance|Ecosystem |
Documentation | |
Target State | Onchain Voting available for community members |
Definition of Done | Update added to User Story Inventory |
Product Stage | Scope ratified |
Functional Requirements | Execute tests on Plutus, Ledger, Node 8.x and 9.x against Sanchonet |
Non-functional Requirements | Database persists and store submit of DReps actions is in line with previous test batteries |
External Dependencies | Tooling will need to be upgraded such as Wallets, Indexers to work with new Cardano Era |
Communication Channel | Cardano update/Telegram/Twitter/Discord |
Indicative Sizing | 5L |
Context of Indicative Sizing | Plutus and peripheral tool including wallets and indexers are to be tested with automation included in new test suite |
Hardfork (Yes,No, TBC) | Yes, This relates to Chang-HF |
Security Review | No |
Code Audit | No |
Community Endorsement | Yes |
Feasibility Study Required? | No |
Reviewing Working Group | Hardfork Working Group |
Core Infrastructure (Yes, No, TBC) | Yes |
Item Champion | DQuadrant |
BFH-1. BlockFetch (Pre-contracted)
Developing a modification to the block fetch ensure analogous responsiveness from block fetch peers, as an enhancement to the original Ouroboros Genesis work
Drivers | Interoperability & Transparency - enables new nodes to join the Cardano blockchain and bootstrap themselves |
Documentation | Whitepaper - https://eprint.iacr.org/2018/378.pdf |
Target State | Stipulated in the Contract |
Definition of Done | Stipulated in the Contract |
Product Stage | Testing and benchmarking |
Functional Requirements | Stipulated in the Contract |
Non-functional Requirements | Stipulated in the Contract |
External Dependencies | NA |
Communication Channel | NA |
Indicative Sizing | Stipulated in the Contract |
Context of Indicative Sizing | Stipulated in the Contract |
Hardfork | Not required |
Security Review | Y |
Code Audit | Y |
Community Endorsement | NA |
Feasibility Study Required? | NA |
Reviewing Working Group | Node Working Group |
Core Infrastructure | Yes |
Item Champion | Tweag |
GRA-1. Guardrails (Pre-contracted)
Tweag will provide Intersect with audits for the Guardrail script which handles a filtering of users' proposals before being subjected to votes
Drivers | Decentralization|Regulatory Compliance|Ecosystem |
Documentation | |
Target State | Onchain Voting available for community members with Guardrails to protect onchain governance from undesired state |
Definition of Done | Implementation + Documentation + Service Level Agreements |
Product Stage | Write Guardrails per Cardano Constitution | Proof of Concept | Research | Standalone, Prototype |
Functional Requirements | Implement onchain voting using an agreed set of Governance actions, implement protective guardrail to implement tolerable parameter values to be applied |
Non-functional Requirements | No detrimental behaviour to be observed against Babbage era |
External Dependencies | Node 9,x and Plutus v3 will be required |
Communication Channel | Cardano update/Telegram/Twitter/Discord |
Indicative Sizing | 4L |
Context of Indicative Sizing | This will require work on Plutus and peripheral tools to be modified |
Hardfork (Yes,No, TBC) | Yes, Chang-HF |
Security Review | Yes |
Code Audit | Yes |
Community Endorsement | Yes |
Feasibility Study Required? | Yes |
Reviewing Working Group | Plutus Working Group |
Core Infrastructure (Yes, No, TBC) | Yes |
Item Champion | IOI |
IDT-1. Identity Management (Pre-contracted)
Identity Management provides additional control and credential management for institutional members including X509 compatibility. Hot credentials can always be rotated but this requires consensus and an amount of coordination plus cost. A hard fork is needed if a member loses control of their cold credential and does not want to be re-elected by the community. Otherwise, the cold credential can be rotated using an update committee action.
Upon completion,Tweag will provide with audits for the Identity management script. This script thus relies on the latest PlutusV3 features around governance.
Drivers | Decentralization|Regulatory Compliance|Ecosystem |
Documentation | |
Target State | Ability to rotate ICC Onchain Voting available for community members |
Definition of Done | Implementation + Documentation + Service Level Agreements |
Product Stage | Write CIP | Proof of Concept | Research | Standalone, Prototype |
Functional Requirements | Provide ability for rotation of credentials for CC members |
Non-functional Requirements | Votes to be possible in the agreed epoch |
External Dependencies | Tooling will need to be upgraded such as Wallets, Indexers to work with new Cardano Era |
Communication Channel | Cardano update/Telegram/Twitter/Discord |
Indicative Sizing | L |
Context of Indicative Sizing | This will require work on Plutus and peripheral tools to be modified |
Hardfork (Yes,No, TBC) | Yes |
Security Review | Yes |
Code Audit | Yes |
Community Endorsement | Yes |
Feasibility Study Required? | Yes |
Reviewing Working Group | Ledger Working Group |
Core Infrastructure (Yes, No, TBC) | Yes |
Item Champion | Tweag |
Future works planned
With what info we had, we were able to produce this list. Working with our suppliers, we were able to solicit earnest and insightful feedback as to how we can improve the list further. Here are some updates that we’re working on to include for future items: 1) Work Breakdown Structure 2) Business Benefit 3) Team Structure 4) Testing and Verification 5) Counterparty requirements 6) Impacted code structure: 7) Integration strategy 8) Dependencies 9) Artifacts/Deliverables that will be generated (beyond code) 10) Breaking down items based on objectives and contracts
Last updated