Is Cardano pushing developers into an Ethereum-type account model?

Question

Cardano is build on the eUTxO model which it prides to be more robust and easy to think about than the Ethereum account model. When Cardano introduced native tokens it also was proud to announce their elegance and simplicity:

Native support grants distinct advantages for developers as there is no need to create smart contracts to handle custom token creation or transactions. This means that the accounting ledger will track the ownership and transfer of assets instead, removing extra complexity and potential for manual errors, while ensuring significant cost efficiency.

However - and this is a very big caveat - Cardano does not allow transactions that don't also carry a minimum Ada value (which is around 1 to 1.4 Ada). This means that it is not possible to send only native tokens. The sender must also send alongside the native token these minimum Ada to the recepient.

This severely impacts the usefulness of native tokens and forces developers to combine native tokens with smart contracts to work around this restriction. For example, SundaeSwap does not send tokens earned as part of the ISO directly but uses a smart contract where it stores which wallets are entitled to the tokens (see https://www.youtube.com/watch?v=OqNU99s6o_Q&t=1s at minute 12:00). The solution of SundaeSwap pretty much resembles the Ethereum model where a smart contract acts like a central register of who holds how many tokens. It is also a solution that implements an account model, that Cardano views as inferior to the UTxO-model.

So is this the way that Cardano wants their users to go ? Are we all now using the UTxO model only on the surface but then relying on an account model buried in a smart contract to make things work?

Also, why does Cardano implement native tokens when it seems to think at the same time that their UTxO model is not able not handle a possible state bloat due to native token transactions?

Answer 1

As I understand it, the SundaeSwap solution is not like ETH account model. The smart contract will temporary store tokens for the address x until the proprietary of this address send the minADA value to "withdraw" tokens. Then he will receive back the minADA + tokens, spending only transaction fees. minADA that has to be sent along tokens is some kind of "bail". eUTxO is versatile, I expect there will be some interesting ideas to manage nicely this constraint.

Answer 2

Short answer, No.

Cardano will have the ablity to use Tokens for fees, but that is in the pipe line as we are just getting step 3 done.

https://iohk.io/en/blog/posts/2021/02/25/babel-fees/

Cardano is currently using only eUTxO, Cardano is a 5 step process and Smart contracts is only step 3. The Account base model isn't good because it needs a globel state like ETH does now which ETH users pay for in the fees of crazyness. Cardano will never be like that due to EUTxO and coming Hydra node that can just plop the Sundae Swap plutus contract on it natively to make using it ever cheaper.

Read these articals and spend some time on IOHKs site, its dense content but it answers all your concerns.

https://iohk.io/en/blog/posts/2021/03/11/cardanos-extended-utxo-accounting-model/

Answer 3

Firstly, the min-uTxO-value requirement isn’t an accidental one. It’s primarily designed to serve as a collateral parameter which mitigates flood attacks via spam transactions and activities. This minimumADAvalue is not limited to native tokens but also ADA as well and it’s all integrated into the fee system to ensure seamless implementation. This requirement doesn’t in any hinder/hamper the fluidity or robustness of what native assets are and how they’re used. Note: min-uTxO-value is an adjustable parameter. I’d advise spending more time revising the publicly available documentation for Min-ADA-Value Requirement.

Secondly, SundaeSwap isn’t and should not be the determiner of establishing models from which DApps or other smart contact related developments are built. With that said it’s best to understand the difference in smart contract models between Ethereum and Cardano, unlike Ethereum-based contracts that are essentially built to be automated accounts with address that are imbued with code and execution triggers, Plutus smart contracts are rather simply validating scripts that check, the validity, of transactions of both simple and complex business logic. Plutus scripts do not own any signing keys or any other key that makes up an address on the ledger. If Ethereum contracts are personal assistants then Cardano contracts are bodyguards. As such, DApp architectures and design models will drastically differ from EVM compatible ones and if certain project decides to build their Cardano products by emulating methods and approaches as done in EVM structures, that’s their decision and not a limitation of the Cardano protocol. More info on Plutus contracts at the IOHK Research Library, keyword: “Functional Blockchain Contracts” to locate the resource.