Hi there,
I am aware that IOHK maintains three Cardano client codebases.
- Haskell Cardano Node
- Jormungandr Rust implementation
- some experimental impl that I don’t have much input about
Are there any community driven or independently developed node implementations? If not, is there a reason why?
I am convinced that implementation diversity is a key feature every technology should aim for. Even if only to increase resilience against black swan events. And I would like to help work towards that goal.
Kiriakos
EDIT: I find it very interesting that I wrote that post 3 hours before Charles Hoskinson livestreamed the Mantis client introduction for Ethereum Classic
3 Likes
Okay, I plan to submit this for Fund 3. I have more than enough skill to start doing this and have a realistic chance for success.
Who’s with me?
Incidentally I would propose another Haskell implementation. Only due to the fact that I like the language and would like to up my game in it. But I think I am flexible on that front. If diversifying compilers is important maybe another language would be better (Frege? OCaml? other?).
1 Like
Some core thoughts:
- 100% Open Source (MIT or GPL, up to debate)
- 100% Develop in the open (I would use github, dockerhub and the CI and infra of my personal https://kind.software infra)
- Project should roughly be split in two month iterations with very specific high level goals
- Config compatibility with iohk/cardano-node
But happy to discuss these on Ideascale! 
I get asked some questions every time I post about this, so fere goes:
FAQ
NO this is not to compete with IOG, CF or any other entity.
NO this is not about forking Cardano Mainnet!
This is purely to:
- Strengthen the Cardano ecosystem by providing resilience against black swans via diversity
- Strengthen the meaning of CIPs by making them the single way in which Cardano is developed (currently there is only one entity, IOG, that deals with CIP implementation, adding other entities makes for a better process)
Interesting project @kiriakos,
I see the advantages of an alternative Cardano-node and would welcome an implementation in, for example, Rust. In my opinion, this would add a lot of value to the whole ecosystem.
What I don’t understand is why this alternative Cardano-node should also be written in Haskell. Could you explain this in more detail? It doesn’t make sense to me at first glance.
1 Like
Good question!
In general I am impartial to the language used. Though I am pushing this Idea because I actually want to be one of the developers of this project. So there is a bit of personal preference.
The pros I personally see in doing a Haskell (or other pure FP) implementation
- I do have considerably more experience in Haskell than in Rust
- Haskell is one of the few languages that allows a high degree of correct by compilation constraints. This should theoretically lead to a less noisy development lifecycle in terms of defect significance.
Cons:
- Obviously choosing Haskell as the implementation language of the independent cardano-node would allow for compiler based vulnerabilities to shine through. Though, from my experience, CVEs in GHC are very rare and bugs tend to be catched early on. Often through client code that is tested with QuickCheck or similar.
- Implementation similarity could be an issue. I need to think about this one, or maybe somebody from IOG could pitch in. I think the nature of Haskell might lead both developers in creating sort of the same codebase which of course would be counter to the idea of diversifying the code.
But again, I am very happy to discuss this and chose the path that most benefits the two goals I put up earlier!
Edit: syntax
1 Like
And we are live!
https://cardano.ideascale.com/a/dtd/Indie-Cardano-Node/340960-48088?submitted=1
Proposal submitted! Looking forward to discussing with you all and get this thing rolling! There also is the Rust Ouroboros crate proposal from the 2nd-Layer group, so the “create cardano-node alternatives” space is heating up. Let’s not forget ETH has 4 actively maintained full nodes, and we should make sure we also have more than one or two!