Create Publication

We are looking for publications that demonstrate building dApps or smart contracts!
See the full list of Gitcoin bounties that are eligible for rewards.

Article Thumbnail

Algorand Boosts Performance 5x in Latest Upgrade

As part of Algorand’s latest major protocol upgrade, the blockchain will see a 5x performance boost to 6,000 TPS and a ~10% decrease in round times to <4s. As demand for Algorand block space increases, we want to stay ahead of the adoption curve so end users can focus on the UX of dApps, not the underlying blockchains. As always, Algorand ecosystem apps can rest assured that the underlying technology “just works.”

Let’s dive into how this was accomplished and what to expect moving forward.

Performance Levers

A blockchain works by periodically grouping transactions into “blocks” that get linked to form a chain. Historically, our industry has measured performance by the number of Transactions that can be processed Per Second (TPS).

The most straight-forward three levers to pull in this area are:

  1. 1) Increase block size: add space for more transactions inside each block.
  2. 2) Reduce transaction size: make transactions smaller so you can fit more into a given block.
  3. 3) Reduce latency: produce blocks more frequently to process more transactions per second.

As a side note, the balance between these levers is quite important; a blockchain that finalizes one block per day could still have very high “TPS”. For example, if the block holds 860,400,000 transactions but only finalizes once every 86,400 seconds (1 day) it could still claim 10,000 TPS! Clearly, while the math works, this is not a blockchain that end users would enjoy using.

In Algorand’s 3.9 upgrade, we increased block size to 5 MiB and reduced average round times (block latency) to <4s. By fitting more transactions into each block and producing blocks more frequently, the Algorand blockchain will be able to handle roughly 26,000 transactions per block at peak throughput, translating to 6,000 TPS.

Techniques

Block size is typically capped by two factors: ability to process the blocks (node hardware) and ability to propagate the blocks at the desired speed (block/network latency).

One key part of processing larger blocks is the data needed in memory. Algorand consensus security requires access to accounts’ state history and, in previous versions, that state history was kept in memory. Larger (and fuller) blocks result in more active accounts, requiring each node to store more data in memory, putting pressure on node memory limits. Version 3.9 introduces a significant memory optimization that reduces this memory burden, allowing us to safely produce larger blocks on the same hardware by storing important historical data on disk.

Larger blocks can also cause slower round times (increased latency) because it takes more time to assemble, propagate, and validate more data across a global network. Despite this increase in block size, our propagation buffer allowed us to safely lower average round times by ~500ms.

What’s Next?

One of our key performance goals is to handle 10,000 TPS. After optimizing block size, our next major target is to continue reducing round times to further improve the end user experience and provide more TPS runway for future adoption.

To frame our approach, we think about each round as broken up into 3 phases:

  1. 1) Block assembly (group transactions into a block)
  2. 2) Block propagation (sending block data across a distributed network of nodes)
  3. 3) Block validation (checking if the winning block proposal is valid).

Each of these three phases are able to be optimized and we are working to do so. A few of the options we are actively exploring are:

  1. 1) Faster computation: We can speed up block proposal / validation so less time is required to assemble and validate blocks.
  2. 2) Speculative assembly: Similarly, we could parallelize these processes so the next block is assembled while the previous block is being validated, reducing the total time required.
  3. 3) Faster network: We could more quickly deliver participation nodes the information they need to vote on block proposals so less time is spent waiting for proposals to arrive.

Our team is focused on optimizing each of these components so we can achieve faster round times (and higher TPS) in future protocol upgrades.

To learn more about Algorand’s latest upgrade, check out the version 3.9 release blog.