What is your capability to deliver your project with high levels of trust and accountability?
The main proposer (Michele Nuzzi) has already implemented and delivered Cardano-specific software that requires a low-level understanding of the protocol.
namely the open-source project plu-ts and others such as cardano-ledger-ts and ouroboros-miniprotocols-ts
most of the source code above will also turn useful for the implementation of the node as discussed, some proposals are active to support the development of the above modules too.
It is also in the main proposer's best interest to hire qualified engineers before the start of the project in order to maximize the quality and the outcome of the project
NOTE: hiring qualified members is NOT considered a "milestone" of the project but it will be a necessity fulfilled BEFORE the start of it, and conditionally to the proposal being founded.
What are the main goals for the project and how will you validate if your approach is feasible?
The main goal of the project is to produce a new client node implementation for the Cardano protocol.
Following the feedback received by the community the main goal of the proposal will be to have a client node implementation, leaving the possibility for a block-producer node for a future proposal.
A node implementation can be divided into 3-4 components
- network
- consensus
- ledger
- plutus (part of the ledger's responsibilities)
each of the above can be seen as a milestone to complete, but it can be further divided into minor (implementation-specific) goals, which will be discussed in the section below.
Network
The network component is responsible to communicate with other nodes in the protocol;
the implementation of the network component is already under development; the source code can be found at HarmonicLabs/ouroboros-miniprotocols-ts.
the development of the networking stack is part of this proposal.
Consensus
The consensus component is responsible for choosing the active chain of the protocol; it is ultimately what determines the security of the protocol.
Unfortunately, the consensus component is the least documented and highly abstracted.
The path to implement the consensus component is to first implement a concrete instance within the node implementation itself, and later (eventually) abstract it to be Cardano-independent as per specification (this is similar to the approach taken by the Haskell implementation's team).
Ledger
Ledgers' responsibility is to ensure the data on the blockchains (transactions, blocks, etc…) is valid and well-formed.
The latest ledger implementation already exists and can be found at HarmonicLabs/cardano-ledger-ts.
The node however is responsible for validating all the data on the blockchain; not only the latest.
For this reason, is part of this proposal the implementation of all the missing previous eras and respective ledgers.
Plutus
Since Alonzo, validating the data that goes on the blockchain also includes Plutus script execution.
This part is already vastly implemented thanks to the plu-ts project ( which has an active proposal in this found to help sustain the development ).
in particular, the HarmonicLabs/plutus-machine module will be used for the plutus validation.
Please provide a detailed breakdown of your project’s milestones and each of the main tasks or activities to reach the milestone plus the expected timeline for the delivery.
As discussed above we'll break down the project in 4 sections: network, consensus, ledger, plutus.
Network
as per specification (The Shelley Networking Protocol) consists
- node to node handshake
- node to client handshake
- chain-sync (blocks for n2c and headers for n2n)
- node to node tx submission
- node to client local tx submission
- keep alive (n2n only)
- local state query (n2c only) (with numerous possible queries)
Consensus
as specified in the ouroboros-consensus report (The Cardano Consensus and Storage Layer) by consensus we not only mean "the logic adopted by the node to decide which chain is legit" but in this part of the project is also included all the serialization and storage fo the long term history of the chain (immutable DB), the part of the chain subject to change (volatile DB) and the ledger state (aka valid UTxOs & family)
consensus therefore requires:
- immutable database
- volatile database
- garbage collection (passage of blocks from volatile to immutable)
- ledger state
- chain-sync + block-fetch
- mempool
- chain selection
Ledger
the ledger layer is responsible for validating the data that the network layer passes around and that the consensus layer uses for the consensus logic.
the consensus layer supports many different ledgers, general support for the lates ledger adoped is present in the HarmonicLabs/cardano-ledger-ts repository; however the node needs to support all of the ledgers we ever had.
for performance and clarity in the code, we feel each of the ledgers should not be abstracted, and each one should have a concrete implementation; hence the steps:
- Byron ledger
- Shelley ledger
- Allegra ledger
- Mary ledger
- Alonzo ledger
- Babbage ledger
Plutus
all regarding plutus has already been implemented in typescript and that is thanks to plu-ts; so here we can just reuse what has been produced; we would also suggest you have a look at the plu-ts proposal to guarantee healthy development of the project.
Please describe the deliverables, outputs and intended outcomes of each milestone.
The main deliverable is the cardano-node implementation itself;
this also implies modifications and additions to various existing repos; such as HarmonicLabs/ouroboros-miniprotocols-ts and HarmonicLabs/cardano-ledger-ts.
As specified, the entirety of the project will be open source; all the metrics offered by GitHub itself can be used to measure the progress of the project.