How the Accounting Model and Design of the Blockchain Affects Scalability

Cardano uses the UTxO model and only small scripts are validated on-chain. Ethereum uses an account-based model and all application logic is implemented in smart contracts. Let's explore how these different approaches affect scalability options.

Scalability is about Resources

Scalability is about computer resources that enable the operation of a network. Blockchain platforms are global decentralized networks composed of a large number of nodes operated by volunteers. These are the only computing resources available to the network. It is necessary to use these resources as efficiently as possible if high scalability is to be achieved. The topic of costs and rewards could be addressed separately.

Platforms enable not only the transfer of value but also the execution of complex operations (smart contracts). When designing the platform, it is necessary to think about how to implement individual functions of the network so that they consume as few resources as possible.

The blockchain network needs the following resources:

• Processing power (CPU) for performing calculations and executing instructions. Regular transactions usually consume less processing power than the execution of smart contracts.
• Storage space is important for storing data and information. It is necessary to permanently store the entire blockchain. Nodes also need to temporarily store data for validating transactions and executing smart contracts (for example, UTxO set, stake distribution, list of active certificates, etc.).
• Bandwidth, which is the rate of data transfer or communication in a system.

The scalability of blockchain is affected by the availability, efficiency, and utilization of mentioned resources. A scalable network can increase or optimize its resources to accommodate more users, transactions, or applications without degrading its performance and quality.

Individual applications can differ significantly in terms of processing power, storage, and bandwidth requirements. It is not only the design of the platform that matters but also the teams that design and implement the applications.

The network design should allow for incremental scalability by supplying more resources, but this has its limits. Blockchain networks need high scalability, meaning being able to process more transactions per second (TPS), but they must maintain security, decentralization, and functionality. This is a big challenge for teams.

For example, increasing the block size or reducing the block time can increase the TPS, but it also increases the storage and bandwidth requirements of the nodes, as well as the risk of forks and orphaned blocks. Increasing the number of nodes can increase the security and decentralization of the network, but it also increases the latency and complexity of the consensus mechanism.

Teams must carefully balance between all the important features of the blockchain network, keeping in mind the mission of the project and the requirements of the community.

Teams must not sacrifice security and decentralization for scalability. However, there may be projects for which scalability is more important than decentralization.

Communities expect benefits such as decentralization, transparency, and resilience from distributed networks, but these features bring limitations such as network latency, complexity, and coordination which are unfavorable properties for scalability.

Scalability is influenced mainly by the design of the blockchain network (including the execution of smart contracts) and the accounting model. We will deal with both.

In the article, we will talk about Cardano as a platform using the UTxO model and the Plutus platform for the validation of scripts. Ethereum is a representative platform using an account-based model and the Ethereum Virtual Machine (EVM) for executing smart contracts.

Most platforms that use an account-based model and EVM may have similar problems as Ethereum. However, if teams managed to implement sharding, for example, they could scale better than Ethereum. The aim of the article is not to compare SC platforms in detail but to draw attention to the differences in design.

Differences between Accounting Models

The UTXO model is like a verification system, where each transaction output (UTxO) represents a digital asset that can be spent by its owner.

One of the advantages of the UTxO model is that it allows for more parallelism, which means that transactions can be processed independently and concurrently by different nodes in the network, as long as they do not spend the same UTxOs.

This can improve the scalability and throughput of the network, as more transactions can be verified and confirmed in a given time. The UTxO model also reduces the need for synchronization and coordination among nodes, as each node only needs to keep track of the UTxOs that are relevant to its transactions.

The UTxO model is simple and secure, as it does not require complex logic or smart contracts to execute transactions. It only involves simple arithmetic operations and cryptographic checks to verify the validity and authenticity of transactions.

The disadvantage of the UTxO model is that it is more prone to fragmentation, as it creates many small UTxOs that may be distributed across different addresses (Cardano and Bitcoin users usually have funds in multiple addresses). This can increase the number and size of transactions, as more inputs and outputs may be needed to fulfill a spending request.

The UTxO model also increases the storage and bandwidth requirements of the nodes, as they need to store and transmit all the UTxOs that are relevant to their transactions.

The account-based model is more like a database system, where each account has a balance that can be updated by transactions. It requires more synchronization and coordination among nodes, as transactions need to update the global state of the accounts.

The global state is the collection of all the account balances and states on the network, which grows over time and needs to be stored and verified by all nodes.

The account-based model allows for less parallelism, as transactions may depend on or affect the state of other transactions. This can reduce the scalability and throughput of the network, as transactions need to be executed in a sequential order and cannot be processed independently or concurrently by different nodes.

The global state consumes a lot of processing power as it needs to be computed and verified by every node. This applies especially to complex or large transactions or the execution of complex smart contracts. I will talk about transferring tokens and executing smart contracts in the next section.

Blockchains that use the UTxO model can (at least in theory) achieve higher scalability and throughput than the account-based model because transactions can be validated in parallel. Blockchains that use the account-based model may face bottlenecks or congestion due to their global state dependency. Of course, even blockchains that use an account-based model can scale well. Second layers (rollups, sidechains, etc.) are more suitable for this.

Parallelism is beneficial for scalability because it can improve the performance and quality of a system by distributing the workload among multiple nodes (better use of resources, as nodes do not need to be idle). It can increase the speed, throughput, and capacity of a system, as well as enable more functionality and programmability.

However, parallelism also introduces new challenges, such as coordination and synchronization. The workload can be distributed to multiple nodes, but the network must ensure the consistency and correctness of the system. Even if transactions are validated independently of each other on different nodes, double spending must not occur.

The account-based model may appear to be a more secure approach (less coordination and synchronization between nodes), but at the cost of inefficiency (it is difficult to achieve high scalability). The problem is that inefficiencies must be addressed, which ultimately leads to complexity (sharding) anyway.

Differences between Designs of Platforms

When Cardano needs to execute a smart contract to validate a transaction, it is usually only a validation of a simple script. Validator scripts usually contain only a few simple conditions (preferably just one) and their result is only a True or False return value (a True value enables UTxO spending). Scripts are not intended to perform complex operations such as calling other contracts or making complex calculations.

Smart contracts on Cardano are composed of on-chain (validator scripts) and off-chain logic. All complex smart contract operations are performed offline and do not consume distributed network resources. To execute off-chain logic, resources of users (wallets) or servers (cloud) are consumed. Applications are composable, as teams are not limited by the platform's capabilities in terms of mutual interaction.

This approach may have a disadvantage in the context of decentralization. Many DEXes in the Cardano ecosystem use batchers. However, decentralization of the off-chain part of the contracts is possible.

It is also important in how many cases it is necessary to execute the smart contract. Cardano has native assets meaning that the transfer of tokens is ensured directly by the Cardano protocol and it is not necessary to execute smart contracts (or scripts).

Cardano is also efficient in that multiple tokens can be transferred to multiple recipients in one transaction. This mainly saves storage and bandwidth. DEXes can create one large transaction in which there are multiple swaps.

Ethereum has no native assets. All tokens are created through smart contracts, which must be executed for every interaction with tokens, including their transfer from account to account. This is more demanding on the computing resources of the network than in the case of native assets.

Smart contracts on Ethereum mostly contain all the application logic. Their execution is therefore very demanding on network resources. As with transactions, smart contracts must be executed sequentially.

Almost everything Ethereum does requires executing a smart contract, with the exception of transferring ETH.

If we are talking about the possibilities of how to scale better, it is necessary to look at it through the lens of resource utilization. Resources are always limited and the goal is to maximize their use meaning to use the given amount of resources to achieve maximum TPS.

Adding a new resource to the network does not mean that it will be used efficiently.

If there are hundreds of nodes in the network, but only one can work on a block at a time, it is inefficient. Adding a new block producer node to the network (new resources) increases decentralization, but not necessarily throughput and capacity (coordination may even be slower). This is the current state of Cardano (but also Bitcoin and many other blockchains).

Multiple nodes participate in the creation of a new block in the Ethereum network, but this is not parallelization. One node proposes a block and other nodes pre-approve it. This increases block finalization, but does not increase network throughput and capacity.

Input Endorsers

The difference between the UTxO-based and account-based models can be well explained by looking at the Input Endorsers (IE) feature (Ouroboros Leios). IE is one way that can improve the scalability of Cardano. We will show how IE improves the scalability of Cardano, but also why something similar cannot be implemented in the case of an account-based model.

The scalability and efficiency of Cardano can be improved by separating transaction selection from block production. Transactions can be pre-processed (pre-validated) by the network before inserting into a block. Transactions can be selected and endorsed by input endorsers (randomly chosen nodes based on stake). The endorsed transactions are then propagated through the network and processed by other nodes before the block producers bundle them into blocks. The blocks only contain references to the endorsed transactions.

Note that when transactions are included in a block, they have confirmations from multiple nodes. This improves the finality of transactions.

IE reduces the latency and variability of block propagation times, as transactions can be streamed constantly without waiting for consensus. This also improves the speed and responsiveness of the network.

Transactions can be processed in parallel by different nodes before being included in blocks, so it increases the throughput and capacity of the network. Cardano will be able to process more transactions (and they can be more complex).

IE leverages the UTXO model, more precisely parallelism.

IE is different from sharding, which is another technique to scale blockchain networks. IE does not require cross-shard communication or synchronization, as all nodes process the same endorsed transactions before they are included in blocks.

IE is complementary to sharding, as it can improve the scalability and efficiency of each shard or layer of the network. So, Cardano can have sharding once IE is implemented.

IE may not be easily applicable to the account-based model.

The validation of each transaction depends on the validation of all previous transactions, i.e. on the global state. Ethereum nodes cannot (in advance) validate transactions without knowing the (future) global state. The account-based model requires more synchronization and coordination among nodes, as transactions need to update the global state of the accounts.

In other words, Ethereum nodes cannot take a portion of transactions and verify them independently of other transactions. The problem is that the global state changes in only one place in the network (block producer) and all other nodes wait until they can verify the new block. So they are idling (they can only pre-approve a new block).

Sharding

Ethereum was supposed to have sharding, but the team abandoned this intention and is now more inclined to second layers. Let's think about how sharding on an account-based model could look like.

Sharding is a technique that splits the blockchain into smaller pieces, called shards, that can process transactions in parallel. Sharding can increase the scalability and throughput of the network, but it also introduces new challenges and trade-offs.

One of the challenges regarding the global state is how to ensure the consistency and security of cross-shard transactions, which are transactions that involve accounts or contracts on different shards. Cross-shard transactions require coordination and communication between the shards, which can introduce latency and complexity.

Moreover, cross-shard transactions may face the risk of double-spending or reordering attacks, where malicious actors try to manipulate the order or validity of the transactions.

Each shard would have its own global state and the state would have to be synchronized among all shards. Each shard could have its own independent state, meaning a unique set of account balances and smart contracts. The global state of the network (all shards together) would not be a fixed state. It would have to be a dynamic and evolving state that depends on the interactions and consensus among the shards.

If the network were to have one state at any given time, it could be incredibly inefficient and require a lot of communication and synchronization.

Even if Ethereum had sharding, it would still suffer from the inefficiencies associated with the global state. Each shard would have its own global state. In each shard, a new block would be produced independently of the other shards (which is a form of parallelization), but in an equally inefficient way. That is, in each round, there is always one block producer who fills the block with transactions and a bunch of other nodes who can do nothing but wait for this block so that they can validate it. The need to synchronize the global states of all shards only complicates everything. Nodes from different shards must communicate with each other to agree on valid global states. The reason is that users and assets of one network are in different shards.

Implementing sharding on Cardano would also be a big challenge. However, it is simpler than in the case of account-based models. Once the Input Endorsers feature is ready, it can be considered.

The EUTxO model could have some advantages for sharding implementation over the account-based model thanks to natural parallelism.

Multiple nodes can actively participate in sharding at the same time. IE would help with it. Transactions can be streamed constantly without waiting for consensus, so it would reduce the latency and complexity of cross-shard transactions.

Similar to the account-based model, sharding requires more synchronization and coordination among nodes across shards. However, IE would significantly improve the functioning of sharding on Cardano, as it would speed up consensus within shards.

Nodes would have to be aware not only of their shard (their own UTxO set, for example) but also at least partially aware of the surrounding shards. It is possible that some sort of (dynamic and evolving) global state of the network (all shards together) would need to be implemented.

The implementation of sharding on account-based or UTxO-based models is not a trivial task. While this might be easier in the case of the UTxO model (mainly thanks to parallelism), it is certainly not an easy target.

Conclusion

The scalability of blockchains (and platforms) is affected by the accounting model, network design, optimizations, and other things. For example, Mithril will enable the creation of stateless clients, which are nodes that do not store the entire state of the blockchain, but only verify transactions using cryptographic proofs.

In my view, scalability is mainly about the smart use of computing resources in the best possible way and the ability to add resources. But this has its limits (unlike centralized networks) and teams must balance between important network properties.

Even if the UTxO-based model seems to be more advantageous for scalability, it may not be the best possible solution for the specific use case that the platform offers.

The best asset of the project is a team that is able to adapt the project to market conditions or community wishes and deliver the solution that is needed for adoption at the given moment. Low scalability is a barrier when it prevents wider adoption. There are projects that (allegedly) have thousands of TPS on the first layer, yet they are not in the top 10.