The Polygon Avail Testnet is now live. As users begin incorporating Avail into their chain designs, a question that often comes up is, “How many transactions can Avail process?”
This is Part Two in a three-part series of articles that will address Polygon Avail’s current performance, as well as its ability to scale in the near and long term.
In Part One of this series, we explored how Polygon Avail operates today. In part 2, we’ll make it clear that we can scale (by increasing the block size) quite quickly. We’ll walk through precisely how and why that is possible. We’ll introduce the concepts that will allow us to scale Polygon Avail beyond simple block size increases. And we’ll introduce exactly where interventions to increase throughput are going to come in the Avail block production, and verification process.
So, let’s explore the most straightforward way to scale Avail: increasing block size.
As we’ve played around with different block sizes for Avail, we’ve learned that rows and columns in the Avail data matrix must be treated differently.
In an Avail block:
The three things that must be done before a light client can reach a data availability guarantee are as follows:
The thing is, there’s a constant tradeoff between the time it takes to build commitments, and the time it takes to handle proofs. This becomes especially salient as Avail’s block size is increased.
The main tension when increasing the block size of Avail can be described as commitment generation (performed by validators), versus proof generation & verification (performed by full nodes & light clients, respectively).
The more rows included in a block’s data matrix, the longer the block generation time. This is because more rows means producers must create more commitments (think of commitments as more advanced state roots).
Conversely, the more columns, the more time it takes to build and verify proofs as we’re dealing with polynomials of higher degree. For more details on the inner workings of the KZG polynomial commitment scheme that underpins Avail’s architecture, this post by Dankrad Feist shares more information.
For example, currently Avail has a 256x256 matrix (~65K cells). In order to double the block size, we can:
Doubling the block size should always result in ~131K cells, double the 65K we have now.
Keeping this in mind, we could increase the size of an Avail block from the current 2 MB to 32 MB. This is quite achievable in the near future. For example, a 1024x1024 (32 MB) Avail block takes 4s to generate commitments, 4ms to build a proof, and 620ms to verify a proof. These numbers suggest that a 32 MB block can have commitments generated, all proofs built, and verified within the current 20s block limit.
And, there’s plenty of computation headroom to increase block sizes beyond even 32 MB. An Avail block of 128 MB with dimensions 64x65,536 takes 7.25s to generate commitments, 174ms to build a proof, and 55ms to verify a proof.
This provides us with a realistic computational limit on what can be accomplished by the producers generating commitments, and full nodes generating cell proofs within 20 seconds.
With block sizes of ~128 MB though, the network as a whole begins running into bandwidth constraints. Propagating blocks of that size over typical Internet speeds begins to present a real challenge. This is a common scaling bottleneck that will be faced by all data availability layers.
The numbers below show our experimental results for block sizes of 2 MB, 32 MB, and 128 MB with varying row to column ratios. You can find more of our results here.
Over the course of this series, we've focused on the technical methods we could implement to enable the Avail network to handle more and more transactions per second. Just as important to consider in any blockchain based system are the incentives to scale, as well.
As the network grows, validators will incur the cost of scaling. Should Avail become sufficiently decentralized, validators will have their own interests independent of Polygon.
Rest assured that as Avail both decentralizes and grows, validators will be incentivized to keep prices low. As each throughput limit is reached, growth allows for the possibility of increased gas fees via rent-seeking validators.
However, Avail’s design fosters the continued growth of transaction throughput (and affordability of transaction costs), even in a fully decentralized system.
If you keep cost per transaction the same while increasing block size, validators end up with the opportunity to make much more money overall. Validators can get access to a larger and larger pool of users. We don’t have to limit how many users Avail can support in the way blockchains that handle execution have to. Computing constraints are no longer the limiting factor on growth. That means that as long as prices stay low, the total number of transactions will continue to increase.
As the network grows, and validators are able to capture value, validators also get to take advantage of economies of scale.
Thus, the “marketplace” we’re creating with Avail is one that can offer consistent growth to a network of validators, while offering consistently low cost per transaction to users.
The Avail testnet is already live with updated versions on the way. As Polygon works toward the Avail mainnet, we’re interested in partnering with any teams looking to implement data availability solutions on their chains.
Let’s bring the world to Ethereum!
The Polygon Avail Testnet is now live. As users begin incorporating Avail into their chain designs, a question that often comes up is, “How many transactions can Avail process?” This is the final piece in a three-part series of articles that will address Polygon Avail’s current performance, as well as its ability to scale in...
The Polygon Avail Testnet is now live. As users begin incorporating Avail into their chain designs, a question that often comes up is, “How many transactions can Avail process?” This is the first in a series of articles that will address Polygon Avail’s current performance, as well as its ability to scale in the near...
If we want the entire world to join Web3, blockchains will need to handle more transactions. Monolithic blockchains can’t scale because they’re asked to perform too many tasks (execution, settlement, and data availability) at once. But if chains were able to focus on just one part of the stack at a time, the entire ecosystem...