Scalability! / Cardano forges forward / Basho shows the way

Cardano for the Masses: Lido Nation Read-along

We’re reading the latest edition of Cardano for the Masses by John Greene, and want to encourage community participation by doing a read-along. We invite you to pick up the book, come along, leave a comment, and participate in the related “Every Epoch” giveaway when they come up!

With all signs pointing toward a lively market in the coming months, it’s a great time for any blockchain that wants to keep up with the hype to be thinking about scalability. Cardano’s “Basho” era, which we are in right now, is all about scalability. Chapter 8 of “Cardano for the Masses” covers this topic as well.

In simple terms, scalability refers to the network’s capacity to handle increasing usage. When you get into the details, what it really means to scale can include lots of things. How big should a blockchain transaction be allowed to be? What about the block itself? How fast does transaction confirmation need to be, and what threshold of reliability is acceptable?

Matsuo Basho, for whom the Basho era was named, was a Japanese poet who lived in the 1600s. To this day he is considered the grand master of Haiku poetry. Just as a Haiku famously packs layers of meaning into a few brief, structured, syllables, blockchain scalability means figuring out how to balance the quantities of data that are transmitted in a block, with how succinctly and quickly they can be transmitted.

Just tell me how fast it is

In Chapter 8, author Green takes the first section to explain all the measures that should be looked at when measuring a blockchains current and potential future performance. Often, newcomers will look at comparisons of “TPS” (Transactions per second) between blockchains, assuming that more TPS is better and that’s the end of the story. But as Greene points out:

“Any blockchain can appear fast and sexy using tiny transaction sizes and no scripts. Some high profile blockchains have centralized characteristics such as a minority of validators controlling disproportionate amounts of stake. It’s easy for a blockchain to compromise on decentralization then boast astronomical TPS figures, but if it needs to be stopped and restarted regularly, it should be a clue that it’s not really what it seems.”

Furthermore, Greene reminds us that, given Cardano’s eUTXO model and native asset standard, that a single Cardano transaction can contain a multitude of things - some ada, dozens or hundreds of other native tokens, and even multiple NFTs. On other networks, these might all need to be handled in separate transactions. The bottom line is that TPS turns out to be a very blunt instrument for measuring something far more nuanced.

With this in mind, Greene posits the following as a more balanced list of metrics to consider when measuring system performance and capacity:

  • Throughput: How much data can the system process in a given length of time.
  • CPU seconds: The CPU is the “Central Processing Unit” of a computer, and CPU seconds is a measure of how much time it takes a given computer to complete a task.
  • Finality: How much time until a processed transaction is final and unchangeable throughout the whole network.
  • Concurrency: How many different actors can be using this system at one time without stepping on each others’ toes?
  • Transaction size: How much information can be packed in a single transaction? In Cardano, this is a limit set by a network parameter. Like any parameter, it could be changed someday.

Just as the things we must measure are varied, so are the solutions. Greene groups the solutions he describes into two broad categories:

  • Layer 1, or “On-Chain” solutions: upgrades to the protocol itself
  • Layer 2 or “Off-Chain” solutions: extending functionality with solutions that aren’t part of the primary blockchain itself.

Layer 1 / On-Chain

Parameter Adjustments Author Greene mentions Cardano’s network parameters several times in the article, and how different adjustments to this or that parameter might be used to influence scalability. For detailed (yet approachable!) descriptions of all of Cardano’s parameters, why they are interesting, and how they might be adjusted, readers should follow along on Lido Nation’s Cardano Parameters article series and podcast!

Pipelining I found the explanation of pipelining and how it improved system performance to be a fascinating and exciting example of how real scalability improvements can and have been made directly on Cardano. Each block, Greene explains, goes through an ordered set of steps when processing a block. Always the same steps in the same order. As each block is propagated to other nodes in the network, those steps are performed over and over again by each node. Pipelining is the idea that instead of waiting to finish all the steps before passing a block along to the next node, that it can start right after the first step, and proceed in an overlapping fashion.

Pipelining

Pipelining (courtesy of @jJosjuaThreatt tweet)

Input endorsers Input endorsers got a thorough explanation in this chapter, some of which is well over my head. What I understood is that input endorsers get new transactions queued up in a “pre-constructed block” so that when they get sucked to the front of the line for processing, there is much less processing to do. Those who are interested in this will find a lot more detail in the book.

Layer 2 / Off-Chain

Mithril Like many things in Cardano, Mithril started with a research paper, the results of which were presented by IOG researchers at the 2021 Cardano Summit. Mithril allows data to be validated more quickly, by allowing an application to get the current state of the blockchain ledger without needing to verify its entire history. This is super useful for apps like mobile wallets or other devices with limited resources.

Hydra Any reading about Hydra will quickly land you in a deep weedy patch of thorny vocabulary words like “Isomorphic State Channel” and quasi-mythological references to the Hydra’s “head” and “tail”. Greene does a good job of pulling this reluctant reader through the quagmire, breaking things down a bit. “Isomorphic” means something has the same shape and properties; a State Channel kind of just means taking things into a separate room for a minute. To make use of Hydra, a defined group of participants who have business together can enter a side room – called a Hydra Head. Once they have assembled, no new participants can be added. While they are there, the same rules that govern Cardano are in effect (hence, “isomorphic”). When their business is concluded, the updates to who now owns how much ada or other assets is synced back to the system. So if five participants entered a Hydra Head with 100 ada each to play a game of poker, then at the end of the game there is still 500 ada in the room to be synced back to the system. It probably changed hands a bit, and this is now reflected on the main chain – but the main chain did not have to process every hand of the game as a separate transaction. There is a long list of potential use cases for Hydra, with the appeal being that a multitude of transactions can be conducted at lightning speed in a quiet space, with all the assurances of main-chain verification at the end of the event. With that all said, Greene makes the important clarifications that a hydra head is not a silver bullet. It is not a side chain - no blocks are minted in a Hydra head, and no transaction history naturally exists about what happened. No new participants can be added after it is formed, which creates some natural limits to its use cases.

SideChains A side chain is just a blockchain, with its own nodes, blocks, protocol, and consensus policy. The difference, as Greene puts it, is “philosophical, not technical.” Essentially, we would call it a side chain when there is a two-way bridge between the so-called “Side Chain” and the so-called “Main Chain” and when everyone pretty much knows and agrees about which is which. It’s not so different from bridging between two different “main-chains” – technically. However, there is usually far more overlap. For example, the nodes participating in minting blocks on the side chains will generally be many of the same who are minting blocks on the main chain. In this way, the side chain can quickly benefit from the infrastructure and decentralization of the main chain, without having to build it from zero. According to the chapter, there is some momentum in the community to re-name this concept “Partner chains,” which might seem to more accurately reflect that two chains can be fully independent, while also being closely aligned.

The Midnight network project could be a great example of this kind of blockchain-partnership. If you are a casual observer of the Cardano community in social media and news feeds, you’ve probably seen mention of Midnight, often accompanied by some amount of fear, uncertainty and doubt. Greene does an excellent job in this chapter of clarifying its raison d’être, and why we might be excited about what Midnight could bring to the table as a partner chain to Cardano - I encourage readers to check it out!

Conclusion

Leave us a Haiku about Cardano, scalability, or the future of blockchain in the comments!

Get more articles like this in your inbox

Was the article useful?

Or leave comment

No comments yet…

avatar
You can use Markdown
close

Playlist

  • EP2: epoch_length

    Authored by: Darlington Kofa

    3m 24s
    Darlington Kofa
  • EP1: 'd' parameter

    Authored by: Darlington Kofa

    4m 3s
    Darlington Kofa
  • EP3: key_deposit

    Authored by: Darlington Kofa

    3m 48s
    Darlington Kofa
  • EP4: epoch_no

    Authored by: Darlington Kofa

    2m 16s
    Darlington Kofa
  • EP5: max_block_size

    Authored by: Darlington Kofa

    3m 14s
    Darlington Kofa
  • EP6: pool_deposit

    Authored by: Darlington Kofa

    3m 19s
    Darlington Kofa
  • EP7: max_tx_size

    Authored by: Darlington Kofa

    4m 59s
    Darlington Kofa
0:00
/
~0:00