Naive Alternative Solutions

When taking a look at the value proposition of Milkomeda for on-boarding developers and growing the respective ecosystem, there are a number of naive alternative solutions that may come to mind. In this section we will go through the most common ones and point out the downfalls which caused us to skip over them and put all our effort in building the current version of Milkomeda instead.

Naive Alternative #1: Let’s Compile Solidity to Plutus!

One of the most obvious ideas to aid in bridging the gap for smart contract developers who have experience writing contracts in other languages, such as Solidity, is to simply build a compiler that translates Solidity to Plutus.
Sure, this would impose some up-front cost, but the idea is that once the compiler is created then one would be able to simply run all Solidity contracts through it and magically have efficient Plutus contracts ready-to-go. This would be ideal as Solidity devs can use their existing knowledge of the tooling and programming language, yet get to contribute to the Cardano ecosystem.
Unfortunately, things aren’t quite this simple.
Firstly, one of the key impediments that makes it impossible to compile Solidity into Plutus are the differences in the underlying blockchain structure between the EVM and the EUTXO model. The EVM is account based, meaning that all actions that happen in smart contracts are due to mutation of data in accounts. Cardano is EUTXO-based, meaning that all actions that happen in dApps are based on spending (destroying) old UTXOs locked under smart contracts and creating new UTXOs with a new state.
As such the EVM is based on an imperative approach, but the EUTXO model is based on a functional approach. Furthermore, each of these approaches brings with it deeper consequences wherein Plutus is a non-Turing complete language by design, while Solidity is Turing complete. Turing complete languages can be used to solve any arbitrary computation problem, but without any guarantees on runtime or even whether it will in fact terminate. What this means in practical terms is that Solidity contracts have several orders of magnitude more complexity for what some would consider more power.
However, it has been shown that in the EUTXO model, even though smart contracts are not Turing complete in themselves, they are Turing complete across multiple transactions. In practical terms this means that in the majority of cases Turing completeness isn’t needed for creating dApps, but in the edge cases where it is required, the system is designed to support protocols of arbitrary complexity as well.
Furthermore, rather than forcing smart contract developers to deal with this unbounded complexity 100% of the time, with Plutus it scales based on how complex the protocol that the developers are implementing is. This complexity scaling has further positive effects in making Plutus smart contracts much more prone to static analysis, which means that it is much easier to build tooling which checks for bugs and eventually does full-fledged formal verification. This ends up being a net asset for Plutus, yet does directly prevent direct conversion from Turing complete to non-Turing complete.
If one is not a well versed programmer these may seem like trivial distinctions, but in fact this means that the design of the smart contracts themselves must be distinctly different on each system.
Thus, it is actually impossible to create a compiler that will convert any Solidity contract into a Plutus contract.
Lastly, even if such a compiler were possible, the act of converting code from one language to another, especially with different underlying systems, tends to generate rather inefficient code. The reason for this is that you do not have the freedom of manually implementing performance/efficiency upgrades as you normally would if you directly write the code in the native language. This would lead to contracts that are less efficient on Cardano than on Ethereum not because the underlying system is slower, but because of the conversion process itself.
As can be seen at this point, compiling from Solidity to Plutus is a dead end that will not suffice.

Naive Alternative #2: Let’s Use ADA on Ethereum!

An alternative solution may be to use ADA on Ethereum. By creating a bridge for tokens to be transferred from Cardano to Ethereum, ADA can be moved to the Ethereum blockchain as wrapped ADA (milkADA). Wrapped tokens like milkADA represent assets that have originated from another network, but have now been moved from said origin network onto the current network thereby becoming “wrapped”.
This would allow Solidity developers to create smart contracts and dApps that target milkADA as the main asset, and thereby reuse existing tooling on top of Ethereum. As one can imagine however, this leads to a whole host of problems as well.
To start, running smart contracts that use wrapped ADA on Ethereum does not improve the Cardano ecosystem at all. In fact, it provides more benefits to the Ethereum ecosystem, which is a net negative for the adoption of Cardano. This appears to be a sub-optimal tradeoff for ADA holders as a whole.
Furthermore, even if we ignore the adoption issue, the UX ends up being sub-optimal for ADA holders from a variety of perspectives. For example, gas fees on Ethereum must be paid in ETH and not ADA, meaning that even after moving their assets over to Ethereum they still need to purchase ETH to even begin using their milkADA in smart contracts.
Ethereum at this point is also extremely bloated and suffering because of it. With smart contract transactions sometimes costing hundreds of dollars each, it is hard to say that they are usable by anyone except the affluent. This was one of the reasons Cardano was created in the first place: to try and address this issue by allowing everyone and anyone to access DeFi and other novel dApps.
It makes little sense to move milkADA onto Ethereum and then have users suffer all of the issues they were trying to get away from, even if it ends up being a bit easier for developers.

Naive Alternative #3: Sidechain Using a Different Base Asset

If compiling Solidity to Plutus doesn’t work, and using milkADA on Ethereum makes no sense, what if we instead create a new EVM-based sidechain that has its own token and connect it as a sidechain directly to Cardano?
This has several obvious benefits over the previous two proposed solutions wherein developers get to keep the tech stack that they are used to, yet users are not forced to suffer the horrible experience of a blockchain struggling to keep up under an extremely heavy load it wasn’t designed to handle. Users could move assets from the Cardano mainnet to the sidechain, and get many of the pluses of both of the previous solutions.
While clearly a better choice, this option still has several drawbacks that make it less than ideal
As the sidechain would be a distinct chain that has its own token that is used for gas, it would take away value from Cardano rather than strengthening the mainnet and ADA specifically. The sidechain would in effect be competing for usage over the Cardano mainnet, and the sidechain token would be competing with ADA.
The whole problem we are trying to solve in the first place is onboarding more developers from existing L1 blockchains using different tech stacks into the ecosystem, so it makes little sense to then build an entire sidechain where these developers will be primarily incentivized to push the value of the sidechain token, and not ADA itself.
This sidechain token will have some inherent value and may find some traction on Cardano mainnet as well as a wrapped asset used inside of DeFi protocols, but there is very limited synergy between this token and the rest of Cardano, and in fact it becomes more of an impediment to adoption due to skewing the incentives.
Furthermore, the fact that the sidechain has its own token for gas imposes a cumbersome user experience. Rather than users being able to simply send their ADA over to the sidechain as milkADA and use it both as gas and for smart contracts, users must first purchase the sidechain token in order to do anything on the sidechain. This would force the user to either go through a centralized exchange, which is a large ordeal, or deal with on-chain DEXes and have to pay further fees to acquire the token in the first place. In both cases the user must pay extra fees, take an order of magnitude more time to get started, and suffer a worse experience, which will translate to less usage and adoption of the sidechain.