Alternative and independent cardano-node

Hi there,

I am aware that IOHK maintains three Cardano client codebases.

  1. Haskell Cardano Node
  2. Jormungandr Rust implementation
  3. 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.

:peace_symbol:
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:

  1. 100% Open Source (MIT or GPL, up to debate)
  2. 100% Develop in the open (I would use github, dockerhub and the CI and infra of my personal https://kind.software infra)
  3. Project should roughly be split in two month iterations with very specific high level goals
  4. Config compatibility with iohk/cardano-node

But happy to discuss these on Ideascale! :slight_smile:

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:

  1. Strengthen the Cardano ecosystem by providing resilience against black swans via diversity
  2. 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 :slight_smile:
  • 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

Okay, I added two Perspectives to the Fund3 insights today based on this:
Having-only-one-node-implementation-might-be-risky
We-need-to-prove-that-development-of-the-Cardano-protocol-is-open-and-democratic

Cardano Catalyst Discord link to the proposal: