TLDR
Main Applicant: Michele Nuzzi
Email: [email protected]
Requested funds: 1,389,696 ADA
Duration: 12 months
Objective: Implement a client cardano-node in Typescript, broadening the development of the protocol to typescript developers, diversifying the network, and making Cardano more resilient.
The Cardano Typescript Node is an interface for developers to engage with the Cardano blockchain using the popular programming language, TypeScript. It simplifies blockchain interactions, making it more accessible for a wider developer audience. Leveraging the strengths of TypeScript, it ensures type safety, better code quality, and improved debugging capabilities. This node not only benefits developers by reducing the learning curve for Cardano-based application development but also strengthens the overall Cardano ecosystem by fostering more applications and integrations. Its adoption would be monitored by the number of applications developed using it, the community engagement, and feedback from developers.
Background of the Problem
In the current landscape of Cardano’s ecosystem, a noticeable degree of centralization exists, primarily manifested in its reliance on the input-output-hk/cardano-node repository. For a decentralized ecosystem that is built on the principles of security, resilience, and accessibility, such a bottleneck is both contradictory and risky. This challenge is not unique to Cardano; it’s a common thread that runs through several blockchain protocols. However, what makes it more pronounced is the sheer magnitude and promise Cardano holds for the decentralized world.
For clarity, the issue is not that a single node repository is inherently flawed. The challenge lies in the potential vulnerabilities and risks associated with a singular point of control and maintenance. In the world of decentralized systems, having all your eggs in one basket, so to speak, can be an Achilles heel.
The Ethereum Parallel
Drawing a comparison with Ethereum provides a more transparent view of the challenge. Ethereum boasts a diversified network with nine distinct node implementations, spread between execution clients and consensus clients. Out of these, five are consensus clients. This diversification offers Ethereum a multi-faceted shield against potential vulnerabilities. A failure or exploit in one client doesn’t compromise the entire network, as there are alternative clients to fall back on.
Such diversity and resilience in network infrastructure are what Cardano currently lacks.
Centralization Concerns and Single Points of Failure
The reliance on the input-output-hk/cardano-node repository can be viewed from two angles:
Centralization Concerns: A singular repository translates to a concentrated point of control. Even if this isn’t the practical reality, from an external perspective, this can be seen as a centralization aspect.
Single Point of Failure: From a technical standpoint, any vulnerabilities or issues in this single node can propagate throughout the Cardano network, with the potential to disrupt operations.
Unlocking the Potential of TypeScript
Cardano’s protocol has been primarily implemented in Haskell — a functional programming language known for its robustness and formal verification capabilities. However, the programming world outside the blockchain sphere has seen a significant shift towards more universally accepted languages like JavaScript and its statically-typed sibling, TypeScript.
TypeScript, with its vast developer community, offers a golden opportunity. Implementing a client cardano-node in TypeScript not only opens the door to a broader pool of developers but also paves the way for more diverse and resilient Cardano network infrastructure. It promises more eyes on the code, more contributors, and, consequently, a richer and more secure ecosystem.
Furthermore, the possibility of light clients running in browsers, made feasible by a TypeScript implementation, can propel Cardano’s adoption among everyday users, increasing its reach and utility.
The Solution
In the contemporary technological landscape, the crafting of protocols and their corresponding nodes necessitates accuracy, trustworthiness, and a grasp of the decentralized milieu. Given Cardano’s reputation as a third-generation blockchain, it becomes crucial to investigate avenues that amplify its reach, variety, robustness, and decentralization. Their solution is oriented towards these objectives by proposing an alternate Cardano node realization in Typescript.
Why Typescript?
Broad Developer Base: Typescript, which is a superset of JavaScript, has garnered the attention of developers worldwide. By introducing a Cardano node in Typescript, it immediately welcomes a significant number of developers skilled in both Typescript and JavaScript. Such an approach can potentially catalyze community-driven enhancements, novel ideas, and advancements in the Cardano sphere.
Safety and Security: Owing to Typescript’s statically-typed characteristic, there is a reduction in developmental errors, ensuring that the resultant node remains robust with a diminished susceptibility to glitches.
Scalability and Performance: Coupled with the emergence and fine-tuning of Node.js, Typescript can deliver performance on par with conventional programming languages.
Portability: Javascript, and consequently Typescript, is versatile in its operation. This translates to a Cardano node that is both adaptable and free from intricate environment setups, ensuring it can function on any platform.
Opportunity for Light Clients: The ability of Typescript to function on web browsers opens the door to pioneering in-browser lightweight node realizations. This endeavor can potentially make the Cardano blockchain more user-friendly for the general populace.
Key Highlights of the Typescript Node Realization:
Decentralization and Resilience: The presence of diverse Cardano node realizations ensures the system is not overly dependent on a singular code foundation. This strategy minimizes the risk of a broad-spectrum malfunction and amplifies the network’s defense against any adversities or flaws unique to one particular realization.
Evolutive Architecture: Their blueprint would adopt an evolutive framework that encapsulates both past and anticipated modifications in the Cardano protocol. This strategy guarantees that their node maintains synergy with all the varying iterations of the Cardano blockchain.
Open-Source Ethos: Their dedication to preserving an open-source ethos for the project certifies that the global audience can examine, enhance, and expand upon their blueprint. Such an approach nurtures mutual trust and communal progress.
Integrated Plutus Support: The expertise they’ve garnered from prior work on plu-ts will be employed to assure flawless Plutus script execution.
Can the applicant deliver?
Expertise and Past Experience:
Michele Nuzzi showcases significant familiarity with the Cardano ecosystem. He has already implemented Cardano-specific software that requires an in-depth understanding of the protocol, namely projects like plu-ts, cardano-ledger-ts, and ouroboros-miniprotocols-ts.
His intention to hire qualified engineers prior to the project’s initiation suggests an understanding of the project’s scale and complexity. It also indicates a proactive approach to ensuring the project has the necessary resources and expertise from the outset.
Understanding of the Problem:
The proposal demonstrates a comprehensive grasp of Cardano’s current challenges, especially in relation to its dependency on the input-output-hk/cardano-node repository. The identification of this as a point of centralization and potential vulnerability is an accurate assessment of the current state of the Cardano ecosystem.
Additionally, the recognition of the benefits of a diverse node ecosystem, as seen in other blockchain systems like Ethereum, indicates a forward-thinking approach.
Technical Approach:
The proposed solution, involving the implementation of a client cardano-node in Typescript, is sound. Not only does this tap into a broader developer community, but it also lays the groundwork for potential light clients, enhancing the accessibility and versatility of the Cardano network.
Breaking down the project into distinct components (network, consensus, ledger, plutus) provides clarity and helps in setting tangible milestones.
Open Source Commitment:
The commitment to keeping the project fully open source means that it aligns with Cardano’s ethos of decentralization and transparency. This also allows for community-driven improvements and adaptations in the future.
Budgeting and Value Proposition:
The detailed budget breakdown, including the logic behind each calculation, suggests thorough planning. While the total amount requested is substantial, the justification provided in terms of the project’s scale, the expertise required, and the projected long-term benefits for the Cardano ecosystem makes a compelling case for the allocation of funds.
Dependencies and Risks:
The proposal has no dependencies on other organizations, which is positive as it minimizes potential bottlenecks or challenges related to third-party involvement.
The choice of Typescript also mitigates potential development risks, given its popularity and the wide pool of developers familiar with it.
Accountability and Reporting:
Plans to use platforms like Twitter and GitHub for consistent progress updates ensures transparency and allows the community to keep track of project developments. This also provides avenues for feedback, which is crucial for iterative improvements.
Further Questions/Interview
I connected with Michele and here is what he had to say
Can you elaborate on the benefits of having a Typescript implementation of the Cardano node, especially for the non-technical users?
There are many different potential benefits of a typescript implementation.
The first that comes to mind is a much more easy to use setup to run a node.
Virtually any machine nowadays comes with a runtime for Javascript (compilation target of Typescript);
and even if missing it can be installed in a couple of clicks.
Once you have a JavaScript runtime aviable there’s nothing more you really need; you just get the source code of the node, run a command, et voilà, you have a node running.
This, unfortunately, is not already the case for the current implementation, where some more steps are required to have a running node, so this is definitely a benefit of the implementation.
There are a couple more major benefits deriving from the choice of typescript as a language; both mainly due to the fact that Typescript is understood and used by an impiortant slice of professional developers.
The first is opening the development of the Cardano protocol to many more devs than we can reach currently only basing ourselves on Haskell.
And I’m not talking only of Typescript developers here but professional developers in general.
Since so many devs can understand Typescript (even if Typescript is not necessarely their preferred language) this project could really help expand the development of the protocol not only to Typescript devs but also to Rust, Go, C, <insert your weapon of choice> developers.
And finally, always thanks to the wide adoption of Typescript, the project will make much easier for libary creators and maintainers to work much closer to the cardano-node and even build other tools that can better integrate with it.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
You mentioned that your proposed project aims to help Cardano from a regulatory perspective. Could you provide more details about how exactly your proposal would accomplish this?
First of all I want to make clear that we do not have the necessary legal expertise to have a direct impact in any way on the subject.
With that being said is clear that one of the major factors that are cause of debate when talking of regulations in the ecosystem is decentralization.
Now, decentralization can be seen under many aspects, one of which is the development of the protocol.
In particular if only a small set of people is able to unilateraly make changes of the protocol it could be seen as an aspect where the protocol is poorly decentralized.
Cardano is constantly improving under the decentralization aspect, especially considering the movment we are witnessing trough the era of Voltaire, to help with this effort we believe that multiple implementations will further help with the goal and the typescript one is a concrete step in that direction.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — –
How do you plan on testing and verifying the security and robustness of the new node implementation before releasing it to the wider Cardano community?
Testing the new node implementaion against the Haskell one will be a crucial step for interoperability between the two softwares, and the process serves the purpose of security and robustness both of the node itself but also of the protocol.
The first step is of course to follow the specifcicaiton where present.
There are infact a series of rules already defined that we must follow in order to have a working node, this goes from the node comunication to the serialization of the different data types.
An Agda specificaiton is underway for the ledger rules and a more complete specificaiton for the full node is cleary being worked out by the IOG engineers; the formal specification will play an important role in verifying the robustness of the new node and we’ll keep testing the softwere as soon as the specifications are released/updated.
Once the node reaches a sufficiently stable development we’ll also seek support by the SPO community to use the node in a testnet environment and receive their feedback and suggestions.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Can you expand on why you chose Typescript as the language for the implementation? Are there any specific technical benefits or capabilities it provides that make it uniquely suited for this project?
There are many reasons behind the choice of Typescript, the benefits elencated in the previous question are only some of them.
First of all there is the practical reason, infact I’m already working with typescript on plu-ts, a smart contract programming language for Typescript developers.
plu-ts is currently under development (infact there is a proposal to support the development to a produciton ready framework in this round too: https://cardano.ideascale.com/c/idea/100658), and the latest versons is 0.4.*. The passage from 0.3 to 0.4 included a process of modularization, meaning that the entire project was split in different sub-modules so that it would be easier to reuse the code.
From that process many different component can already be reused for the cardano node, in particular most of the ledger is defined there but also all the components needed for Plutus execution.
Other great benefit that comes from Typescript is the possiblity to run the node possibly everywhere!
That means that we’ll have the usual nodes on the every-day computer but possibly also embedded in smartphone or web applicaitons!
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
How could the implementation of the Cardano node in Typescript impact the performance of the Cardano network?
The Cardano protocol is very meticulously designed; as such it includes some minimum standards that a node must respect for it to operate properly.
The critical part of node in term of performances are in the block creation process, that will be possibly integrate with a future proposal as suggested by the community.
As an example a new Block must propagate trough the network in less than 5 seconds, or it won’t be valid.
But in general all the network comunications are designed so that it would be incredibly hard to cause problems to the network (in particular it is really hard to “waste” resources in a node-to-node communication).
So when we we’ll have a new implementation (or possibly many) in the network, the difference in performance should not be noticeable.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
As the development is planned to be open source, do you intend to handle contributions from the wider development community? Is there a process or guidelines in place to manage such collaborations?
Absolutely! I’d love to see the project being developed by many indipended developers!
For coordination there is a little discord server where you’ll find other developers playing around with the Harmonic Laboratories tools: https://discord.gg/CGKNcG7ade
The guidelines are the most simple ones:
– respeact each other
– ask for feedback before submission or if you feel stuck.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
The proposal indicates a possibility of creating light clients. Could you elaborate on the benefits and potential use cases for light clients in the Cardano ecosystem?
Light clients are a “simpler” version of the node optimized for a specific use-case.
A full node is a piece of softwere that is doing a bunch of stuff, and usually a specific user doesn’t really need all of that.
We can think at many different types of light clients; one meant to run in the browser and submit transactiions directly to the network, one to only sync data for the governace aspects, one only to work as chain indexer, etc…
Light clients can be optimized for a specific use case and require little to no maintainance (depending on the use) compared to a full node.
The disadvantage compared to a full node is in the security but even there is orders of magnitude more secure than trusting a centralized service.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Is there any potential for additional costs that aren’t included in the initial budget?
Following the Community’s feedback we decided to focus the development on a simple client node (what SPOs would call a relay node);
a relay node is able to communicate with other nodes, download, validate and follow the chain but is not able to extend it (aka. can’t create new blocks)
As mentioned before the block creation process is one of the most important and delicate task a node can do (along many others).
Many tought that aiming for a full block producing node in a 1 year timeline could result in an unsuccessful project, so we decided to listen to their feedback.
Potentially we will consider extending the tyepscript node funcitonalities with the possiblitiy to produce blocks in a future proposal;
ideally once the new node will be in the testing phase by SPOs and other community members in the testnet.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Could you provide a contingency plan if the actual project cost exceeds the estimated budget?
Harmonic Laboratories is the company that will take care of the development of the new node.
On top of infrasturcture development we offer other serivces for the community, such as dApp development and audits and consulting.
There is a website in case anyone whants to contact us: harmoniclabs.tech.
We are still a small startup but definitely growing day by day, hopefully during this time we’ll grow enough to ensure a stable development under all aspects.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Do you have any plans for the long-term maintenance and updates post project completion?
As mentioned before it is in our best interest to make sure we are still operative on the long term; it would also be great to see the project start growing organically accepting submissions by many different developers out there.
