Negative technical review for Cardano (for experts)

Hi guys, I’m a big Cardano enthusiast and I believe a lot in the team’s technical capacity, but at the same time I try to evaluate criticisms and make considerations. Unfortunately, I still don’t have enough technical knowledge, so I would like to ask the more knowledgeable people if these statements are correct:

The Kindelia project, which is not a cryptocurrency, makes some comparisons with Cardano, which can be seen here: https://github.com/Kindelia/Kindelia/blob/master/WHITEPAPER.md#comparisons-to-cardano

Some criticisms of Cardano are:
“When it comes to efficiency , while Haskell’s compiler, the GHC, produces efficient programs, it is not actually used to run contracts on Cardano! That’s because GHC’s runtime wasn’t designed with a peer-to-peer setup in mind, so, using it would raise complications, such as high compilation times, and how to measure execution costs. Because of that, contracts are compiled to an intermediate language, Plutus, and interpreted on-chain. This is much less efficient than compiling, and ultimately means that Cardano fees can’t be much cheaper than Ethereum’s, under the same load”

A technical rebuttal would be welcome. Thank you

3 Likes

I actually had discussed a similar idea a few years ago with a colleague who believed the primary problem with blockchain was the least useful mechanic is the concept of crypto-currency and that none of the existing chains would ever matter until they focused on crypto-code instead where the incentive is the result of the execution rather than some arbitrary accounting model for a favorable market exchange rate.

That said specifically to your citation from the project there are things to consider:

  • GHC compiles Haskell to C before linking an executable binary and C is still the king of runtime performance. So what they mean by efficiency is the runtime performance as it applies to the Cardano node, Cardano CLI, and anything else compiled with GHC. I believe Ethereum nodes are written in C/C++ directly and so they get similar efficiency so long as virtual functions and polymorphism are avoided.
  • GHC was not designed for distributed compilation but very few tool chains actually are. This requires extra work like building network layers, schedulers, agents, etc. Tools like Incredibuild, distcc, etc can do this for C/C++ to compile faster across multiple networked machines. No one has built this kind of tool for GHC directly that I am aware of but it’s so similar to GCC I would imagine it is possible. The network for smart contract compilation is of course the Cardano nodes themselves.
  • The reason for Plutus as an intermediate subset of Haskell for a smart contract language goes far beyond the issue of compilation times or even implementing distributed compilation. For example inline implementation prevents vulnerabilities from being introduced by libraries by simply not allowing any Haskell libraries or packages outside of Plutus core to be used. Cardano specific ledger, transaction, token, and other related functions become built-ins for purposeful convenience. There are entire white papers and plenty of articles describing “Why Plutus?” in much more detail.
  • Ethereum smart contract language is Solidity which is based on JavaScript similar to how Plutus is based on Haskell. Therefore Ethereum compilation is just translating to byte code instructions like any other intermediate language or ABI. Their format happens to be JSON while the similar process of compiling Plutus to byte code ABI happens to be represented by CBOR in Cardano. Neither of these things have much to do with fee structure unless you consider that CBOR by nature is more concise than JSON.
  • Fee structure is a an entirely separate topic from smart contracts or implementation language as it is more related to the transaction model used by the blockchain protocol. For example Ethereum gas fees are based on network load which is why it can dynamically cost so much $$$$ to get confirmations during high volume congestion of the network. Conversely Cardano fees can be accurately calculated in a deterministic fashion and scale with size which is both cheaper and safer. Both approaches have upsides and downsides but Cardano will ALWAYS be cheaper than Ethereum fee structure simply because there is no scaling cost based on “gas” or even the concept of gas fees at all.
5 Likes

I hope so as well… but if plans like this are in the works, it still smells like gas to me: :grimacing:

https://iohk.io/en/blog/posts/2021/11/26/network-traffic-and-tiered-pricing/

1 Like

It would be unfortunate if they altered the core fee structure of the layer 1 protocol before even launching the layer 2 scaling solution successfully. Ideally Hydra should be to Cardano what Polygon and ZK roll-ups are to Ethereum. That said a tiered approach would still be better than “gas availability” as implemented by Ethereum. There have been numerous cases of multi-million dollar transaction fees due to the inherent flaws in that particular design!

Thanks for your reply, many important things have been mentioned. I confess that at some moments I have the feeling that some strategies did not work out at Cardano. First reading Sebastian’s threads regarding PAB, then analyzing this issue of fees, I would like to get an overview about mistakes and how comprehensive they are. Did the eUTXO model bring greater challenges than expected?

Can anyone guide me on where I can get more information about Milkomeda vs Mamba and network fees?

Ps: I love the Cardano community because people are rational and don’t shy away from talking about difficult topics =)

1 Like

eUTXO is a solid iteration but not particularly innovative. They took a proven solution (UTXO of BTC) and proven problem (Account model of ETH) and came up with a transaction model that combined the strength of the former and overcame the weakness of the latter.

I would debate that the Ouroboros protocol is the the best feature of Cardano. No other proof of stake blockchain even comes close. This is gold.

On the flip side an esoteric language like Haskell as a core software stack greatly hinders development. Almost every other blockchain is using more popular established languages. This is death.

1 Like

Don’t know. Have you looked at Algorand’s? (I have not in detail, but it seemed not so bad to me.)

The concept of stake pools that have to advertise for delegations is not without drawbacks as we see in numerous discussions about k, about pledge, about the sense or nonsense of starting one, … every day.

Also don’t know. Having the reference implementation in Haskell is fine with me. But it could all be specified a little more friendly towards alternative implementations in other languages.

Nope, not familiar with that one. I was mostly thinking of Polkadot, Solana, and what Ethereum will have next year sometime so admittedly that is far too small of a sample for the claim. Similarly I suspect a lot more blockchains are popping up that are primarily written in languages that don’t start with the letter C …

Perhaps 1 out of a 1000 will still be around in 2025 so I only learn about a handful of the most popular ones because I don’t really have time for more than that anyway!

1 Like

Dapp devs doesn’t have to learn haskell. I think it’s not such a bad thing for adoption

1 Like

Although a non-technical approach, the bear market seems to be resolving that issue for ETH

CHG

So long as we all continue to centralize through Blockfrost or another third party API.

I didn’t mean adoption in the general sense of increasing users and uses. Users don’t really care about code as long as it works. I meant having to draw talent from a pool of computer scientists with a background in mathematics, cryptography, and finance that know or are willing to learn Haskell is extremely limiting for development of Cardano itself.

2 Likes

Fair point. But I believe these tasks are already separate. There are mathematicians/cryptographers working on research, and there are other people solely responsible for turning the research into code. I think the bottleneck is at this engineering stage

1 Like

I would wager that if Cardano were to also embrace Rust or even GO it would see a flurry of new development. Rust seems to be the in-demand skill across many blockchains. Even at Dfinity where they started with Motoko (their own language) they quickly provided full Rust support. I suspect there is a better than 50% chance we see Rust support for ADA inside of 12 mos if not sooner.

I recently learned and used Go for a gRPC micro-service project but was not particularly impressed, it felt like a clunky version of C with less performance. I likely will only ever use Go again for k8s. Rust looks much better but I have only fiddled with it a bit as I have been using and learning C++ for decades so it doesn’t really add much to my toolbox.

Technically Rust compiles down to C++ anyway. Similarly it is primarily useful for solving the problem of maximizing performance in cross-platform code. These languages shine brightest when used for building systems and frameworks that provide complexity and power to others. Operating systems, game engines, embedded devices, development tools, graphics, etc.

Many blockchains are actually made with C++ or Rust because of that power but you could definitely win the debate that a purely functional language is better suited to ensuring integrity of concurrently settling the state of a distributed ledger. While you can optionally write functional code in C++ something like Haskell forces you to only use that paradigm. Absolutes can be good for design.

Related to Cardano there was an initial experiment for Rust during the Byron era years back but it was abandoned and is now deprecated / broken. The cardano-serialization-lib might be one of the few things that actually uses Rust now!

1 Like

Thought it’d be worth a mention to include builder tools using Rust or GoLang on Cardano Developer Portal

2 Likes