Comparison of fees on Cardano and Ethereum platforms

In our previous article, we explained how to run a script or smart contract on Bitcoin, Ethereum, and Cardano. In this article, we will compare Cardano and Ethereum. We will focus mainly on fees. We will explain what the fees depend on and how they are affected by the design choices the teams have made when building the platforms.

The costs of executing smart contracts

The execution of smart contracts in a distributed network consumes computer resources. Users must pay a fee to execute a smart contract. Executing a contract requires more resources than validating a normal transaction, so the fees are usually higher. To measure the amount of computational effort required to execute a smart contract on Ethereum, the concept of GAS is used. GAS is a unit that represents the smallest fraction of work that can be done by the Ethereum Virtual Machine (EVM).

Each operation that can be performed by the EVM has a fixed GAS cost. For example, adding two numbers costs 3 GAS, while storing a value in memory costs 20 GAS. Executing the same steps within the same smart contract will always cost the same amount of GAS.

The user fee depends on the GAS cost, which is the amount of ETH that is paid per unit of GAS. The GAS cost is not fixed by the protocol but rather set by the user when submitting a transaction or deploying a smart contract. The more ETH the validators can get, the more likely the transaction or smart contract will be included in the next block.

A user must pay a different amount of ETH for the execution of the same operations in the same smart contract, depending on the gas price that they choose. The gas price is a market-based mechanism that allows users to bid for limited network resources.

The GAS model has some advantages and disadvantages for users. On one hand, it allows them to have some control over their fees and prioritize their transactions or smart contracts according to their urgency and importance. On the other hand, it also introduces some complexity and uncertainty in estimating and managing their fees and ensuring their transactions or smart contracts are executed successfully and timely.

Cardano uses a different fee system than Ethereum, which does not depend on GAS or GAS cost.

Cardano’s fee system is based on two protocol parameters: A and B. The formula for calculating the minimum fee for a transaction (tx) is: fee = A + B * size(tx), where:

• A and B are protocol parameters that can be adjusted
• size(tx) is the transaction size in bytes

The parameter A reflects the fixed cost of processing any transaction, regardless of its size or complexity. The parameter B reflects the variable cost of processing a transaction, depending on its size. The larger the transaction, the more resources are needed to store and process it.

The protocol parameters A and B are currently set at 0.155381 ADA and 0.000043946 ADA/byte, respectively. For example, if a transaction has a size of 200 bytes, then the fee would be 0.164271 ADA (0.155381 + 0.000043946 * 200).

The fee for a transaction on Cardano is independent of its computational complexity or the network congestion. It only depends on the transaction size, which is determined by the number and type of inputs, outputs, certificates, and metadata in the transaction. Therefore, the fee system on Cardano is simpler and more predictable than the gas model on Ethereum.

For the execution of the same contract on Ethereum, the user can pay a different amount of ETH each time, while in the case of Cardano, the fee in ADA will be the same each time. Fees on Ethereum are unpredictable while on Cardano they are predictable. Everything is complicated by the fact that the market value of ETH and ADA is also unpredictable.

The fee system on Cardano also has some limitations and challenges. One limitation is that it does not allow users to prioritize their transactions by paying higher fees, as they can do on Ethereum. All transactions on Cardano are treated equally by the stake pool operators. Transaction processing is more predictable as it behaves on a first-come, first-served basis. This is the behavior expected by the user in some cases, but it is not always an advantage.

Another challenge is that the protocol parameters A and B have to be carefully calibrated to balance the interests of users, developers, and pool operators, and to adapt to the changes in transaction volume, hardware prices, and the market value of ADA.

Failed transactions

Another difference between Cardano and Ethereum concerns payment for failed transactions and the effect of failed transactions on the ledger.

On Ethereum, users must pay ETH also for failed transactions. This is because the validators still need to confirm the transactions and execute the smart contracts, even if they fail or revert. The fee is paid for the computational resources that are consumed by the transaction, regardless of its outcome. This can result in unexpected costs and losses for the users.

Cardano users can verify beforehand locally whether the transaction will pass the validation by the network. This is because Cardano uses a deterministic transaction validation scheme, which means that the outcome and effects of a transaction can be predicted before it is executed on the ledger. Cardano also uses a two-phase validation approach, where the first phase checks whether the transaction is constructed correctly and can pay its fee, and the second phase runs the scripts included in the transaction. If the transaction passes both phases locally, then it will also pass them on the network, unless there are changes in the ledger state caused by other transactions processed in between.

If the transaction fails in the first phase, it is immediately discarded and no fee is paid. If the transaction passes the first phase but fails in the second phase, it is still included in a block, and a fee is paid, but the transaction has no (unpredictable) effect on the ledger state. This is because Cardano uses an extended UTXO model, which ensures that transactions are deterministic and predictable.

Transactions on Ethereum can have unpredictable effects on the ledger, depending on the outcome of the smart contracts that they invoke. Some operations may fail or revert due to various reasons, such as:

• Running out of gas: If a transaction or a smart contract exceeds its gas limit, which is the maximum amount of gas that the user is willing to pay for, then it will fail and revert all its effects but still consume all the GAS and pay the maximum fee.
• Invalid opcode: If a transaction or a smart contract encounters an invalid opcode, which is an instruction that is not recognized by the EVM, then it will throw an exception and revert all its effects. This can happen due to bugs in the smart contract code or malicious attempts to exploit vulnerabilities.
• Revert opcode: If a transaction or a smart contract explicitly calls the revert opcode, which is an instruction that allows the smart contract to abort execution and revert all its effects, then it will do so. This can happen due to various reasons, such as failing to meet certain conditions, triggering certain events, or enforcing certain rules.

These unpredictable effects on the ledger can result in unexpected costs and losses for the users who initiate the transactions or deploy the smart contracts. For example, if a user sends ETH to a smart contract that fails or reverts for any reason, then the user will lose the ETH that they sent and also pay the fee for the failed transaction.

Modular vs. monolithic approach

Cardano and Ethereum platforms have different approaches to how they handle smart contract execution and validation. Cardano uses a modular approach, where smart contracts consist of two components: on-chain code and off-chain code. Ethereum uses a monolithic approach, where smart contracts are executed and validated entirely on the blockchain.

A different approach has an impact on fees, performance, security, and scalability. The amount of fees for on-chain services depends on scalability.

Let's look at scalability first.

Ethereum’s GAS model has some scalability issues, as it creates a bottleneck for the network capacity and a source of volatility for the fees. The network capacity is limited by the block GAS limit, which is the maximum amount of GAS that can be included in a block by the validators. The block GAS limit is not fixed by the protocol but rather voted by the validators based on their preferences and incentives. The higher the block GAS limit, the more transactions or smart contracts can be processed in a block, but also the more resources are required by the validators to validate and store the block.

These scalability issues on Ethereum affect both users and developers negatively. Users have to pay high and unpredictable fees for their transactions or smart contracts, which reduces their usability and affordability. Developers have to deal with complex and uncertain fee estimation and management for their applications, which increases their development cost and risk.

Cardano’s fee system has some scalability advantages over Ethereum’s GAS model, as it does not depend on GAS. The network capacity is not limited by a block GAS limit, but rather by a block size limit. The block size limit ensures that all blocks can be validated and stored efficiently by all validators, regardless of their computational resources.

The fees on Cardano are stable, as they only depend on the transaction size, which is determined by its content and structure. The transaction size does not vary much with the network activity or events, as it does not reflect its computational complexity or urgency.

These scalability advantages on Cardano benefit both users and developers positively. Users can pay low and predictable fees for their transactions or smart contracts, which increases their usability and affordability. Developers can deal with simple and certain fee calculations and management for their applications, which reduces their development costs and risk.

The dependence of the fee on the size of the transaction has another advantage, which we will talk about below.

Cardano’s fee system also has some scalability challenges that need to be addressed in the future. One challenge is that it does not account for the memory cost of tracking the accumulated chain state, in particular UTXOs. UTXOs have to be stored in memory by all validators to validate new transactions or smart contracts. As more transactions or smart contracts are processed on Cardano, more UTXOs are created and stored in memory, which increases the memory consumption and cost for validators.

As we have already said, another challenge is that users cannot prioritize their transactions or smart contracts by paying higher fees.

Let's now look at the different concepts of understanding what a smart contract is.

Cardano uses a modular approach, where smart contracts consist of two components: on-chain code and off-chain code. We described it in detail in the article mentioned in the introduction. You can see a simplified version in the following image.

On-chain code is a script (validator script) that runs on the blockchain to validate transactions that involve the smart contract. Off-chain code is an application that runs on the user’s machine to generate transactions that conform to the smart contract logic. The on-chain code is written in Plutus and it is compiled into Plutus Core, a low-level language that runs on the Cardano Virtual Machine (CVM). The off-chain code can be written in any language that can interact with the Cardano node API.

It is important to note that the validator scripts are usually small and with a minimum of operations. It mostly just unlocks funds by performing simple operations such as checking signatures, verifying hashes, or comparing values.

On-chain logic can also perform some complex operations, such as generating random numbers, creating non-fungible tokens, or implementing state machines.

However, these operations are usually more expensive and less efficient than when they are implemented in off-chain logic. Their execution requires more resources per execution on the blockchain, which can be expensive. Therefore, they are usually used sparingly and only when necessary. With regard to fees, more complex logic is implemented on the backend. The backend can be a user's desktop wallet, or an online service running on a server.

Off-chain logic can also interact with other smart contracts or spend tokens off-chain. These interactions still have to be validated by the on-chain logic before they are executed on the blockchain. Therefore, they are usually subject to the same rules and constraints as on-chain logic, such as requiring signatures, hashes, or values.

Ethereum uses a monolithic approach, where smart contracts are executed and validated entirely on the blockchain. Smart contracts are written in high-level languages, such as Solidity or Vyper, and compiled into bytecode that runs on the Ethereum Virtual Machine (EVM). Every node on the network has to run the same smart contract code for every transaction that involves the smart contract.

Put simply, there is only on-chain logic that is processed by EVM. All operations (logic) of the Ethereum smart contract must be defined in the contract and a transaction just invokes the operations. A transaction can trigger one or more functions or operations in the smart contract, depending on the data and value that it provides. The smart contract then executes the functions or operations according to its logic and rules and updates its state accordingly. You can see it in the following image.

The modular approach of Cardano has some advantages over the monolithic approach of Ethereum in terms of fees and scalability.

A complex service can be created on Cardano with very low fees. Most of the functionality can be performed off-chain and only the necessary parts on-chain. The smaller the Cardano transaction, the smaller the fees. Off-chain fees can naturally be significantly lower (or almost none if the user runs the backend locally).

In the case of Ethereum, all of the smart contract logic is executed on-chain. If the smart contract code is complex and large then it automatically increases the ETH fees. Developers are forced to write as small and simple contracts as possible. They may tend to skip some validations to make the execution of individual operations cheaper. The complexity of the contract increases fees.

The modular approach of Cardano improves its scalability by reducing the load on the blockchain and allowing parallel execution of smart contracts. Since most of the smart contract logic is executed off-chain, the blockchain only has to validate transactions that invoke the on-chain code, which reduces its computational and storage requirements.

The scalability of Ethereum is limited by its monolithic approach, which increases the load on the blockchain and prevents parallel execution of smart contracts. Since all of the smart contract logic is executed on-chain, every node on the network has to run every smart contract code for every transaction that involves it, which increases its computational and storage requirements. Moreover, since all transactions have to be processed sequentially (the shared global state), they can interfere with each other and create bottlenecks or processing delays on the platform.

Conclusion

Some think that the fee market is the best solution to get a part of the on-chain resources, while others believe that blockchain networks will one day only be available to the rich. I dare to say that how to properly set the fee policy is an unsolved topic, including Bitcoin transactions. If fees for on-chain services are to be low and stable, it is essential to address scalability.

It is not possible to say unequivocally whether Cardano or Ethereum is better. Both platforms have advantages and disadvantages. It always depends on the team what functionality they want to implement and what the specific platform offers them.

Users will always prefer the lowest possible fees for the best possible services. Third-party developers must adapt to this and build applications that users will want to use and will be willing to pay for. Paying $1 for a regular transaction and $5 to execute a smart contract is unacceptably expensive for most people. Technological development must continue.