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.
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) support for non UNIX-like environment
so far the cardano-node implementation only supports UNIX-like environments. This makes it harder for people not used to the system to join the network.
A Typescript implementation would be able to run also on such machines
As an example, it would be much easier to run a stake pool on a Windows machine
3) 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.
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).
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 )