cardano-node typescript implementation

[GENERAL] Name and Surname of Main Applicant

Michele Nuzzi

[GENERAL] Email address of Main Applicant

michele.nuzzi.2014@gmail.com

Additional Applicants

None

[GENERAL] Please specify how many months you expect your project to last (from 2-12 months)

12

[GENERAL] Please indicate if your proposal has been auto-translated into English from another language.

No

[GENERAL] Does your project have any dependencies on other organizations, technical or otherwise?

No

[GENERAL] If YES, please describe what the dependency is and why you believe it is essential for your project’s delivery. If NO, please write “No dependencies.” in this field.

No dependencies.

[GENERAL] Will your project outputs be fully Open Source?

Yes

[GENERAL] If NO, please describe which outputs are not going to be open source. If YES, please write “Project will be fully open source.” in this field.

Project will be fully open source.

[METADATA] Category of Proposal

Other

[IMPACT] Please describe your proposed solution.

to date, the entirety of Cardano depends (directly or indirectly) on the existence and maintenance of the input-output-hk/cardano-node repository.

This may by some be seen as an aspect in which Cardano is centralized, on top of as a single point of failure for Cardano as a protocol.

Other ecosystems are aware of the above risks and Ethereum as an example counts 9 different node implementations between execution clients and consensus clients, of which 5 are consensus clients.

With this proposal, we want to actively start moving the protocol to a more diversified and resilient network.

Here we propose a path to an implementation of an alternative node implementation (hopefully the first of many) written in Typescript.

The choice of Typescript as a language is discussed in the section below, highlighting the potential benefits this implementation would have on Cardano.

[IMPACT] How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?

The major benefits have been mentioned above, we'll highlight them here quickly.

A new node implementation will:

• improve the decentralization of the protocol
• make the protocol more resilient mitigating possible single points of failure

on top of that, the choice of Typescript as a language comes with additional benefits too:

1) A great number of developers are able to understand and work with Typescript

a typescript implementation would allow those developers to further contribute to the development of the protocol.

2) open the possibility of light clients

Most of the code (exceptions for the storage logic) will be designed to work in any javascript runtime

it will be possible then to reuse this code for an in-browser light node implementation.

[IMPACT] How do you intend to measure the success of your project?

The description of the challenge includes "technical standard" as a possible proposal to submit; with the goal of improving the protocol performance and security; which is the same goal that in principle client (node) diversity aims to solve (or at least mitigate).

[IMPACT] Please describe your plans to share the outputs and results of your project?

So far Twitter has been mainly used to communicate the progress of the various projects.

Mainly the HarmonicLabs account will be alongside the (personal) MicheleHarmonic account where appropriate.

Twitter has proven itself a useful tool to share the progress and it will still be used.

for any unreported progress, the project itself has always been open source, and anyone interested should be able to use GitHub to stay updated; the repository can be found at: ( TODO insert link of repo )

[CAPABILITY/ FEASIBILITY] 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.

[CAPABILITY/ FEASIBILITY] 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.

[CAPABILITY/ FEASIBILITY] 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

1. node to node handshake
2. node to client handshake
3. chain-sync (blocks for n2c and headers for n2n)
4. node to node tx submission
5. node to client local tx submission
6. keep alive (n2n only)
7. 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:

1. immutable database
2. volatile database
3. garbage collection (passage of blocks from volatile to immutable)
4. ledger state
5. chain-sync + block-fetch
6. mempool
7. 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:

1. Byron ledger
2. Shelley ledger
3. Allegra ledger
4. Mary ledger
5. Alonzo ledger
6. 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.

[CAPABILITY/ FEASIBILITY] 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.

[RESOURCES & VALUE FOR MONEY] Please provide a detailed budget breakdown of the proposed work and resources.

The total amount required for the project is 1,389,696 ADA.

The amount has been calculated as follows:

The total amount of ADA allocated to the challenge is 8,685,600 ADA.

To operate with a price that is not subject to volatility over time we are assuming that corresponds to an allocation of 2,500,000 $

that would roughly correspond to a price of 2,500,000 / 8,685,600 = 0,287832735 $/ADA

or equivalently 8,685,600 / 2,500,000 = 3,47424 ADA/$

Ideally, a team of at least 3 engineers should be actively working on the project (qualified engineers will be recruited before the start of the project; therefore this isn't a milestone)

We feel a wage of 50 $/h after taxes is fair for the experience required for such project;

Since the hiring entity operates in Italy we'll consider a 22% standard tax due to VAT (see source on agenzia delle entrate)

50 · (100 / (100 - 22)) =

50 · 100 / 78 =

5000 / 78 ~= 64,102564103 $/h

The estimated timeline for the final product is of one year.

assuming 8h of work a day; for 5 days a week, for 52 weeks a year, the following should be the yearly cost of a single engineer involved in the project:

64,102564103 · 8 · 5 · 52 = 133,333.333334 $

multiplied by 3, which is the number of expected people actively working on it, we should have the final cost of the project in dollar value:

133,333.333334 · 3 ~= 400,000.00 $

which, at a rate of 3,47424 ADA per $, results in a final amount of:

400,000.00 $ · 3,47424 ADA/$ = 1,389,696 ADA

[RESOURCES & VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

The problem we are trying to solve is big and highly specialized.

We are aware that the price of the proposal is not usual, on the other hand, the proposal itself differs from the vast majority of the ones Catalyst has ever seen; in any case, we tried our best to keep the price reasonable especially considering on the impact the project will have.

The alternative node implementation would immensely help Cardano both from a regulatory perspective and from a protocol security and resilience perspective.

[IMPORTANT NOTE] The Applicant agreed to Fund10 rules and also that data in the Submission Form and other data provided by the project team during the course of the project will be publicly available.

I Accept