Comparing Input Endorsers with Sharding

Input Endorsers will increase the scalability of the Cardano network. Sharding is a popular solution with the same goal. The aim of the article is to point out the different concepts of both solutions, especially with regard to maintaining a uniform global state of the systems. Cardano can have Input Endorsers and sharding. We will show how such a system could look like.

Security First

Each blockchain must maintain a single valid global state. From a security perspective, all nodes in the network must be aware of the global state and have clearly defined rules for observing and maintaining it.

A global state is the shared and consistent view of the data and transactions stored on the blockchain by all the nodes in the network. It ensures that every node agrees on the same history and current status of the blockchain.

The local state that each individual node maintains must be the same as the global state, as it is a prerequisite for verifying the validity of new transactions and blocks. The global state is not only stored but also updated by the nodes that participate in the consensus.

The global state evolves at regular intervals. If a blockchain is to scale, network consensus must allow global state changes to be made as frequently as possible over large volumes of data. This is a challenge because data consistency and security must be ensured. This is only possible if all participants work with the same global state.

In a monolithic blockchain with first-generation consensus, changes to the global state are made by a single randomly drawn node at a single location on the network. This change is made through a new block that is diffused into the network. So other nodes accept (or reject) the change with a slight delay. Network latency is a barrier to making frequent global state changes with large amounts of data. In other words, it is necessary to ensure data consistency on all nodes between state changes. That is, make a change and then wait a long enough time for the state to be unified across all nodes.

In the picture below, you can see that the top node produced a new block at time T. The block reaches the nodes in the middle at time T+1. At the bottom node at time T+2. The direction of block movement is indicated by red arrows. The global state is consistent at time T+2. At time T and T+1, each node had a different global state.

A monolithic blockchain handles all the core components of the system, such as consensus, data availability, and execution, in the same layer (in a single layer). All nodes participating in the network consensus share a single space in which they jointly validate transactions and blocks. The global state is stored on all nodes, making it easy to maintain data consistency and completeness at any given moment.

However, this places demands on nodes in terms of resources (storage, bandwidth, computation). A monolithic system can tend towards centralization and have higher node performance requirements. It is therefore very difficult for a monolithic blockchain to achieve high scalability and at the same time ensure a high degree of decentralization. A monolithic blockchain can usually provide a high level of security and reliability but it does not scale.

As blockchain needs to scale more, teams are coming up with innovations like Input Endorsers and sharding.

Remember, each system, whether monolithic, using Input Endorsers, or using sharding, must maintain a single valid global state. In this article, we will compare different approaches to increase scalability mainly with respect to the global state.

All methods that aim to increase blockchain scalability try to employ elements of parallelization and concurrency into network consensus. Improvements can only be implemented with global state consistency in mind. Inconsistency can result in reduced security and reliability.

Simply put, network consensus can allow nodes to do multiple operations simultaneously at multiple locations on the network, but the ledger state (global state) must be consistent. Nodes must be synchronized in time and correctly.

Maintaining a global state is a challenge with the increasing complexity of consensus and the higher amount of data being transferred in the network.

Sharding

A sharded blockchain divides the network into smaller groups of nodes, called shards. Shards can process transactions in parallel. Each shard has its own subset of the blockchain data and its own consensus protocol.

To simplify, you can think of sharding as copying one blockchain (including nodes and its global state) several times side by side.

In the image below you see a sharded blockchain. 15 nodes are divided into 3 shards. In each shard, one new block is produced at time T+1. You see more blocks because the block is diffused to all communication channels at the same time in a P2P network.

The biggest advantage of sharded blockchain is the high scalability achieved through parallelization for transaction verification. The validation of transactions is distributed among several partially independent groups of nodes. This has additional advantages as it reduces the storage, bandwidth, and computational power requirements of individual nodes.

However, in a sharded blockchain, it is more difficult to maintain the consistency of the global state as it is maintained in individual shards. Each shard has only partial knowledge of the global state as it does not have all the data. There must be some synchronization mechanism between shards to ensure that the global state is consistent across all of them. This brings complexity and challenges from a security perspective.

Nodes in a sharded blockchain are not aware of all users and assets. The distribution of users and assets depends on the specific design and implementation of the sharding mechanism. A general principle is that users and assets are assigned to shards based on some criteria, such as their addresses, transaction history, or load balancing.

Dapps are also distributed across shards. Unlike users and assets, dApps may span multiple shards if they need to interact with other dApps or assets on different shards.

Distribution of users, assets and dApps requires cross-shard communication that involves sending messages between shards and ensuring their consistency and atomicity. Different sharded blockchains have different approaches to handling cross-shard communication, such as using relay chains, notary schemes, or receipt proofs.

If Alice is in shard 1, Bob is in shard 2, and Carol is in shard 3, each transaction would be in a different block that would only be verified by the nodes in that shard. But how do shards 2 and 3 learn about Alice's transaction? There are two possible ways to inform shards 2 and 3 about the Alice transaction.

One way is to use a global coordinator that can be called a relay chain or a beacon chain. The coordinator connects all the shards. It can periodically receive block headers from each shard and broadcast them to other shards. Shards 2 and 3 can learn about the Alice transaction by receiving the block header from shard 1 via the global coordinator.

Another way is to use a notary scheme or a receipt proof that involves direct communication between shards. So no global coordinator is needed. A shard can send a message to another shard (or shards) indicating that a certain transaction has been executed or committed. Shards 2 and 3 can learn about the Alice transaction by receiving the message or proof from shard 1 directly.

Every time a shard produces a new block (with many transactions), a block header is sent to the global coordinator. The global coordinator sends the block header to all other shards. This way, all the shards can maintain a consistent view of the global state. However, this also introduces some overhead and latency, as the coordinator has to process and broadcast all the block headers from all the shards. Therefore, some sharded blockchains use different techniques to optimize the performance of the global coordinator, such as batching, caching, or sampling.

Imagine a scenario where Alice is in shard 1 and Bob is in shard 2. Alice wants to send Bob 10 coins. In this simple scenario, up to 8 cross-shard messages could be used to ensure that the cross-shard transaction is executed atomically and securely across shards.

In the image below you can see the normal flow of messages during cross-shard communication if Alice and Bob are in two different shards.

Using 8 cross-shard messages is currently the best solution considering security and atomicity.

It may be possible to achieve the same result with fewer messages, but it would require some trade-offs between security, efficiency, and simplicity. For example, one could try to combine some of the messages into one. However, this would increase the size and complexity of each message, and potentially introduce more risks of network delays or failures. Alternatively, one could try to eliminate some of the messages. This would reduce the level of synchronization and verification among shards, and potentially compromise the atomicity and finality of the cross-shard transaction.

As you can see, maintaining a global state of the sharded blockchain is a complex task. It requires coordination and synchronization between different shards, as well as consistency and security guarantees for cross-shard transactions. The size of the overhead depends on the sharding protocol, the number of shards, the frequency of cross-shard transactions, and the network conditions.

The cross-shard communication overhead is a factor that affects the scalability of a sharded blockchain. The more cross-shard transactions there are, the more messages and data need to be exchanged between shards, which consumes bandwidth, storage, and computation resources. Therefore, the cross-shard communication overhead can limit the scalability of the system, especially when the number of shards is large or the network conditions are poor.

All shards maintain local consensus and must also take care of cross-shard communication. This is resource and synchronization intensive. The local consensus ensures that each shard maintains a consistent and secure ledger of its own transactions. When a transaction involves multiple shards the shards need to communicate with each other to execute and verify the transaction. The combination of local consensus and cross-shard communication enables sharding blockchains to achieve high scalability and performance in comparison with monolithic blockchains.

The main purpose of sharding is to increase scalability, but, perhaps somewhat paradoxically, this solution can be overwhelmed by a large number of cross-shard messages. For a blockchain to benefit from using sharding, the benefits of parallelization must outweigh the overhead related to the synchronization of shards and cross-shard communication.

It really depends on the specific implementation and the way users use the network. With an increasing number of users, but especially with a higher need for cross-shard communication, the overhead may increase, and thus the efficiency of parallelization when processing transactions in individual shards may decrease.

The more shards a system has, the more dispersed users, assets, and applications are. High dispersion is not desirable, as it increases the need for cross-shard communication, but a sharded blockchain cannot avoid it in principle.

The number of shards cannot grow to infinity. The ideal number of shards is dependent on the utilization of the current number of shards and also on other factors, such as the security, efficiency, complexity of the sharding protocol, and the way users desire to use the system. However, this cannot be predicted in advance.

Input Endorsers

Input Endorsers keep users, assets, and dApps in one layer. Consensus uses elements of parallelization and concurrency but maintains a single global state (one version of the ledger). It is therefore not necessary to divide users, assets, and dApps into several separate groups.

The main purpose of the Input Endorser feature is to separate transaction selection from block production. A trio of blocks is used for this. Input Blocks (IB), Endorsement Blocks (EB), and Ranking Blocks (RB).

Ranking blocks serve to maintain a unified global state, while input blocks and endorsement blocks serve to select and validate transactions, which take place concurrently to maintain a unified state.

All block types are minted in parallel in the Cardano network but with a different frequency. Ranking blocks can be seen as consensus blocks as they ensure the linearity of the blockchain. Ranking blocks form a consensus over data in endorsement blocks that reference input blocks (which contain the payload). Between the minting of two ranking blocks, many endorsement and input blocks are minted. Consensus is formed on a larger amount of data than in the case of a monolithic blockchain.

In the picture, you can see the minting of blocks in the Cardano network that uses Input Endorsers. Every second a new block is minted (several blocks can be minted in parallel in the same second).

Input blocks are referenced by endorsement blocks. Endorsement blocks are referenced by ranking blocks. There is a clearly defined link between all block types that serves as a synchronization mechanism. This is important because the information is propagated in the network through the diffusion of blocks. It is not necessary to introduce another messaging mechanism as in the case of sharding, because all nodes are in one space.

In the image below you can see the relationships between all block types. Black arrows indicate references between input blocks and endorsement blocks and also between ranking blocks and endorsement blocks. The red arrows indicate the references of input blocks to the current ledger state, i.e. to ranking blocks. Input blocks are minted with respect to the current global state, which is represented by the recent ranking block. The blue arrows indicate the linearity of the blockchain, i.e. the relationship between ranking blocks when the new ranking blocks must follow the previous ranking block. As time passes, all transactions will enter the ledger through input blocks. In the image, you can also see the blue rectangles behind the endorsement blocks, which represent endorsement certificates.

Information about Alice's transaction will gradually get from the input block to the ranking block. In the input block and endorsement block, transactions are only being prepared. Network consensus takes place through the appending of a new ranking block to the blockchain and the subsequent acceptance (or rejection) of this block by the rest of the nodes in the network. A node that mints a new ranking block can resolve conflicts between transactions by selecting the most advantageous set of endorsement blocks.

In the picture below, you can see how Alice's transaction gets from the input block to the endorsement block and through it to the ranking block. The movement of the transaction is indicated by the red arrows.

Unlike sharding, Input Endorsers act as a monolithic blockchain when it comes to sending transactions between Alice and Bob. What is more complex is the distribution of information about Alice's transaction. Alice's transaction, with a large number of other transactions, is verified by a large number of nodes before it is included in the blockchain through a ranking block.

Input blocks can be minted (streamed) essentially constantly every 0.2-2 seconds (the frequency will be set by the protocol parameter). This means that instead of creating one block every 20 seconds, 10 to 100 input blocks can be minted during the same time. Input blocks, but also endorsement blocks, can be simultaneously validated before they become part of the blockchain history through the ranking block.

Input Endorsers increase scalability within a single space. The network maintains a single global state, so there is no need to synchronize sub-global states similar to sharding.

Conclusion

If the current scalability of a monolithic blockchain network is, say, 30 TPS, then sharding does not increase the scalability of this network, but rather creates several copies of this network, thus creating shards (multiple layers). Each shard has its own consensus and local state for part of the users, assets, and applications of the network. It is necessary to maintain the global state of the network, which occurs through the synchronization of local states. If two participants communicate with each other and each is in a different shard, then for a simple transaction it is necessary to use up to 8 cross-shard messages. This is a relatively large overhead.

Input Endorsers is a solution that increases blockchain scalability. One global state is maintained which is common to all users, assets, and applications. There are elements of parallelism and concurrency in the system, but synchronization occurs naturally through the diffusion of three types of blocks in the network. A single transaction is always sufficient for the interaction between two participants, as they are all in a single layer.

Cardano can theoretically have both sharding and Input Endorsers. In each shard, there can be a consensus supported by Input Endorsers improvement. So there would be multiple layers and a global coordinator (or a solution without a coordinator would be used). Synchronization of local states would occur at the level of ranking blocks. It might look like the image below.

For now, however, this is only a distant theory, as Cardano does not even have Input Endorsers and it will take some time for this system to be implemented. Input Endorsers may be a sufficient solution in the medium term. However, further improvements will need to be considered as blockchain networks must scale as well as current financial systems if they are to disrupt it. Many teams are looking towards second layers, but in order for them to work reliably, the first layers must scale well. We'll see what the future brings us.