Data availability and settlement layers
Data availability layers
By separating consensus and execution, data availability layers can make scalability optimizations without the constraints of also providing settlement layer functionality.
One of the primary scalability improvements that data availability layers provide is block verification. Since consensus isn't concerned with transaction validity, block verification is reduced to only data availability verification. A key component of this is data availability sampling, which allows nodes to verify availability without having to download the entire block. This is done by completing multiple rounds of sampling small random chunks.
The implication of data availability sampling on light nodes’ resource requirements is that the number of sampling rounds and size of the chunks remains fixed regardless of the block size, only the header size increases. For example, given a block size of 250kb the overhead would be approximately 2kb, and for a 1000kb block it would be approximately 4kb.
Data availability sampling also minimizes bandwidth cost for light nodes. In a blockchain where the entire block is downloaded to verify data availability, the bandwidth cost for the node is equal to the size of the block. With data availability sampling, the bandwidth cost for a node becomes significantly smaller since only a fraction of the data is required to be downloaded.
For example, given a block size of 1000kb and no data availability sampling, the bandwidth overhead is the entire 1000kb. With data availability sampling, that 1000kb bandwidth overhead reduces to only 33kb.
The current scope of settlement layers has been borne out of necessity for a blockchain to scale using a separate execution layer. However, that situation is imperfect as the now settlement layer is still burdened by applications and their corresponding user-based transaction activity. This results in a settlement layer that is crowded with transactions from both individual users and execution layers.
An optimal settlement layer should have negligible user-based transaction activity, such as only staking and native token transfers. Besides that, there is no additional need for non-execution layer transactions on the settlement layer because it adds extra overhead to the system.
The vast majority of the settlement layers transaction activity should consist of execution layers settling transactions. One method of influencing this behavior is to limit smart contracts such that they are only used to interact with execution layers, providing proof verification and bridging tokens. By doing so an environment can be created that is conducive to scaling a settlement layer. Many techniques used to scale execution and data availability layers are also applicable to the settlement layer, including mechanics such as parallel transaction processing, fraud or validity proof, weak statelessness, and history expiry.