Polygon’s Zero Knowledge Odyssey: Part 4
Polygon Avail: Why zero knowledge is not enough.
Note: The following article is a part of a 5-part series. Highly recommend reading the previous article before proceeding.
Now that we’ve explored the major zero knowledge solutions of Polygon, let’s take hike a layer above to the hills of Polygon Avail.
Polygon Avail is a modular blockchain that aims to enhance the accessibility and organization of blockchain transaction data. It achieves this by maintaining a comprehensive record of transactions and ensuring the data’s accessibility through verification, making it possible to prove that block data is available without downloading the whole block.
The Data Availability Problem
In a blockchain network, multiple types of nodes collaborate to maintain the blockchain’s integrity. there are generally three main categories of blockchain nodes.
· Validator Nodes: They are responsible for collecting and storing transactions on the network and creating new blocks.
· Light Clients: These nodes download and keep track of the header section of a block, which contains a summary of the information in the block’s body. Because light clients only have access to the headers, they are unable to participate in the verification process and must trust that the validators are trustworthy.
· Full Nodes: Full nodes validate blocks by obtaining the whole block information from the validators and comparing it to the consensus rules. They download the entire block data and verify its authenticity and compliance with the established consensus rules to maintain the blockchain’s integrity.
Achieving efficient storage of a large number of transactions is a crucial objective for blockchain networks, which can be accomplished by creating a data availability (DA) layer. One way to enhance scalability is to increase the block size and reduce the block time, enabling more transactions to be stored within a given time. However, as the blockchain network scales up quickly, the ledger size grows, and the hardware requirements for setting up a full node become more demanding, resulting in inefficiencies and potential centralization. This decrease in the number of full nodes undermines the network’s decentralization, which is one of the primary goals of a blockchain technology. As a result, some blockchain networks choose to limit scalability by restricting block size.
In the event that a validator includes an invalid transaction within the block body, a full node would detect the invalid transaction since it downloads the entire block data. They can generate a fraud proof and let the other nodes in the network know about it. Conversely, light clients that lack access to the block body data are unable to create a fraud proof and would be unaware that the blockchain is invalid, causing them to continue following it. This problem is known as a data availability issue, where data is unavailable due to data omission, causing light nodes to unintentionally fork away from full nodes.
Avail’s approach to this Problem
Avail addresses this problem by focusing on ensuring the availability and order of the transaction data posted, rather than verifying the application state. To be considered valid, a block must have consensus and the data behind that block must be accessible. This is done to prevent block producers from releasing block headers without releasing the data behind them, which would prevent clients from accessing the transactions required to compute the state of their applications.
Avail offers a shared data availability layer that can be utilized across various execution environments, standalone chains, sidechains, and off-chain scaling solutions. It provides the layer by utilizing a highly secure mathematical primitive known as data availability checks, which use erasure codes with a key innovation. It employs Kate polynomial commitments to establish a 2D data availability scheme, eliminating the need for fraud proofs and removing the reliance on honest full nodes to verify the data availability, all while not depending on honest majority assumptions.
To conduct data availability checks, each light client is required to randomly sample a small number of chunks from each block in the chain. When a group of light clients collaborates, they can sample the entire blockchain in this manner. This process can be conceptualized in a manner similar to p2p file sharing systems such as Torrent, where different seeds and peers typically store only some parts of a file.
Avail uses a KZG commitment-based scheme. Using it, the entire data in a block is organized as a two-dimensional matrix in which each column of the matrix is erasure coded to double the size of the original one, bringing in data redundancy. Kate commitments are used to commit to each row of the matrix, and this commitment is included in the block header. As any light client with access only to block headers can query random cells of the matrix and get short proofs (thanks to the Kate commitments), it becomes easy to catch a data hiding attempt.
The data redundancy also forces the block producer to hide a significant part of the block even if it intends to hide just a single transaction. This makes it vulnerable to getting caught on random sampling, eliminating the need for fraud proofs. Moreover, the binding nature of the Kate commitments makes it computationally infeasible for block producers to construct incorrect commitments and not get caught. Finally, the homomorphic property of the KZG commitment scheme enables the commitments for the extended rows to be computed.
Avail vs Zero Knowledge
To achieve higher throughput, a variety of Ethereum Layer 2 solutions are already there, including optimistic rollups, ZK rollups, and Validiums. These solutions enable off-chain execution while maintaining on-chain application verification and data availability. However, while the off-chain execution architecture improves throughput, it is still limited by the main chain’s ability to handle data.
In the case of optimistic rollups, the operator may submit invalid transactions and then hide parts of the block to prevent other full nodes from verifying the submitted assertion. Without access to the necessary data, they cannot produce a fraud-proof or challenge to demonstrate that the assertion is invalid.
Similarly, in Zero-knowledge based roll-ups, accepted transactions are guaranteed to be valid through ZKPs. However, not revealing the data backing a transaction can have serious consequences, including other validators being unable to calculate the current state of the system and a user’s balance being frozen as they lack the required information (witnesses) to access it.
Therefore, to achieve higher throughput, we not only need to focus on off-chain execution but also ensure that the necessary data is available for reconstruction in the future. This is crucial for maintaining the security and integrity of the system while still achieving high scalability.
Where Avail Fits
The 3 main components of the Blockchain Execution workflow are:
· Data Hosting and Ordering (Avail): This component is responsible for receiving transactional data and ordering it in a decentralized manner. The data is then stored, and data availability is ensured. This is the core function of Avail.
· Execution: After the data has been ordered, the execution component takes the transactions and executes them. It creates a checkpoint or proof, which is then submitted to the data verification layer for processing. We refer to this component as the execution layer.
· Verification/Dispute Resolution: This component serves as the anchor to the main chain and is responsible for ensuring the security and robustness of the system. The data verification layer processes the checkpoint or proof submitted by the execution layer and only accepts valid state transitions in the system, provided that the necessary data is available. This component is critical to the security of the overall design.
Avail provides this robust data hosting and ordering component.
Avail’s unique approach to data availability yields three major benefits:
· It significantly enhances the scalability of the data availability consensus layer. Through the use of erasure coding and Kate polynomial commitments, Avail can guarantee data availability without requiring fraud proofs. As a result, availability can be verified with just a small random sample of the total data, effectively solving the data availability problem.
· Avail allows light clients to operate with a comparable level of security as full nodes, as they can determine data availability without having to rely on an honest majority.
· As the data consensus layer is agnostic to the nature of the transactions, it can accommodate any type of transaction in a single layer. This enables us to multiplex the Avail chain, making it adaptable enough to support transactions from multiple independent, sovereign chains that share only Avail’s consensus and data availability functions. Each chain can implement and fully own its own execution environment.
Use Cases
Avail offers a unique solution for blockchain builders who want to outsource their consensus layer while retaining full control over their chain. This allows for greater flexibility in forking, upgrading, or changing the chain as desired. As more clients use Avail, the system becomes more secure and capable of holding and keeping data available for longer periods of time. With the use of light clients, users can benefit from the same level of security as running a full node, promoting true decentralization.
Avail also provides benefits for teams looking to experiment with novel execution environments. Each chain built on Avail can implement its own execution environment, such as EVM, WASM, or new environments that don’t exist yet. This eliminates the need to bootstrap an independent consensus layer and bring a new validator set online.
Existing rollups can also benefit from Avail by implementing validium solutions to reduce data posted to Ethereum. This leads to better, cheaper, and more stable transaction prices.
Timeline
As of today, the Public Testnet of Polygon Avail is live.
Conclusion
Avail is a much-needed step forward in the direction of a completely decentralized inter-blockchain network, where user can create and execute their Dapps completely on their own clients, without the need of full nodes, while not compromising the security of the same.
A towards a modular future where the hierarchies of Layer 1 and Layer 2 dissolve, and chains work together to solve crucial problems, all in the name of decentralized execution in applications from gaming to governance, to Defi, and beyond.
In the long term, Avail can become the base layer for thousands of chains built atop it, enabling trustless bridges between blockchain worlds. This will enable anyone to spin up their own blockchain without having to worry about bootstrapping their own validator set or creating a token to handle tokenomics.
Stay tuned as we conclude the series in an epic finale of summaries and comparisons of the solutions journeyed thus far! :)
References:
Polygon Avail: Polygon Avail Articles — Polygon Blog
Polygon Avail Development: How to use Polygon Avail | Polygon Wiki