Blocks and Prayers
Blocks and Prayers
Share Dialog
Share Dialog
For many users, L1 development may seem like a black box, especially for Ethereum. While the ETH Foundation puts in a lot of effort to keep development progressive and decentralized, for an outsider it's a lot like reading scientific/technical papers. While most of their resources to understand Ethereum are out in public, Ethereum has nearly a 10-year trail worth of discussion for protocol development. Although most resources to understand Ethhereum are publicly available, they are written for those who are already familiar with the fundamentals. These posts will attempt to showcase what is in the Ethereum core developer/mechanism design mindshare.
Block size: Maximum amount of computational work that can be done in a single block. This is not fixed at a size like BTC, but rather variable with gas.
Calldata: Input data sent with a transaction that tells a smart contract how to execute.
EIPs: Ethereum improvement proposals, suggestions for improvements to the Ethereum network, and can be proposed by anyone.
Ethereum's gas limit is what decides how much can be done in a single block, the higher the gas limit the more transactions can be executed per block. The block gas limit has not changed since EIP-1559 (released 3 years ago). The capability to increase or decrease this limit is in the hands of the stakers. Block size, however, has only grown, especially over the past year where block size doubled.
There are risks for gas limit increases as well.
Missed Block Rate: This metric represents the total number of slots where a validator failed to produce a block. This happens if validators are offline or opt out of proposing in their allocated slot. Increasing the block gas limit may increased missed block rate for nodes that are under-provisioned.
State Size: Increasing the gas would also accelerate the biggest problem for scalability, state size. It is not necessarily the size that is the problem, rather there is a problem with accessing/modifying this data. Larger state sizes mean that operations onchain would become slower due to increased timer equired to read from and write to the state.
History Size: This is the historical data of everything recorded since the chain's inception, every transaction, block, and smart contract execution. Transaction count has more than doubled within the past three years, leading to increases in full node size. Increasing the gas limit would make history size increase faster and thus contribute to increases in full node size.
There's been a lot of discussion about increasing the block gas limit, perhaps in response to the criticism about Ethereum being slow compared to Solana. On Twitter, Vitalik made a comment saying that the block gas limit can be increased by a validator vote at any point. Then over an Ethereum Core Developer AMA on Reddit, there was further discussion. General consensus among core developers is that they are willing to increase the gas limit as long as there are incentives in place to keep data and other transactions on other layers (i.e., certain transactions/data should move to rollups)
This discussion transitioned to ethresearch later with notes and design considerations for a possible increase. A few different ideas for solutions have came up.
Increasing calldata costs. Raising these costs allows room to be made for a change in the block gas limit. Rather than straight up raising the block gas limit, thus increasing block size, and then we encounter all the risks aforementioned, calldata can be disincentivized for the L1. Raising calldata price allows more room to be made for the block gas limit without increasing the block size. However, there could be downstream effects for STARKs.
Increase calldata and decrease other costs. Same as above, except ETH R&D specifies a few specific cost drivers for gas usage. This approach is the alleviate ZK L2s like Starknet. The goal is to lower costs just enough so that proof verification from Starknet is not overshadowed by the increased calldata gas price.
Simple 2D calldata pricing. This is EIP-4488 (stagnant development). Could cap the calldata per block, turning it into a strictly scarce resource. This keeps block size relatively bigger compared to the two solutions prior.
Full 2D calldata pricing. This is creating an EIP-1559 for calldata specifically, this would look like blob transactions in the sense that blobs are a separate resource from gas, in this type of market, the resource while separate from gas is priced in variable gas which adjusts so that the number for that resource hits a target (in the long run).
The Loyalty Bonus. This would compensate protocols that need to spend on increased calldata costs. This proposal aims to balance the needs of applications requiring a lot of calldata (ZK applications). In this proposal, applications that require large amounts of calldata but do not accomplish much onchain computation could face higher gas costs, encouraging optimized data usage.
EIP-4444. This EIP is history expiry, and it essentially allows Ethereum clients the capability to prune their historical data (headers, bodies, and transaction receipts) older than a year. This means that historical data older than a year is no longer passed around between nodes.
If you do like reading all the mumbo jumbo, here are some pretty good aggregate resources to check out.
For many users, L1 development may seem like a black box, especially for Ethereum. While the ETH Foundation puts in a lot of effort to keep development progressive and decentralized, for an outsider it's a lot like reading scientific/technical papers. While most of their resources to understand Ethereum are out in public, Ethereum has nearly a 10-year trail worth of discussion for protocol development. Although most resources to understand Ethhereum are publicly available, they are written for those who are already familiar with the fundamentals. These posts will attempt to showcase what is in the Ethereum core developer/mechanism design mindshare.
Block size: Maximum amount of computational work that can be done in a single block. This is not fixed at a size like BTC, but rather variable with gas.
Calldata: Input data sent with a transaction that tells a smart contract how to execute.
EIPs: Ethereum improvement proposals, suggestions for improvements to the Ethereum network, and can be proposed by anyone.
Ethereum's gas limit is what decides how much can be done in a single block, the higher the gas limit the more transactions can be executed per block. The block gas limit has not changed since EIP-1559 (released 3 years ago). The capability to increase or decrease this limit is in the hands of the stakers. Block size, however, has only grown, especially over the past year where block size doubled.
There are risks for gas limit increases as well.
Missed Block Rate: This metric represents the total number of slots where a validator failed to produce a block. This happens if validators are offline or opt out of proposing in their allocated slot. Increasing the block gas limit may increased missed block rate for nodes that are under-provisioned.
State Size: Increasing the gas would also accelerate the biggest problem for scalability, state size. It is not necessarily the size that is the problem, rather there is a problem with accessing/modifying this data. Larger state sizes mean that operations onchain would become slower due to increased timer equired to read from and write to the state.
History Size: This is the historical data of everything recorded since the chain's inception, every transaction, block, and smart contract execution. Transaction count has more than doubled within the past three years, leading to increases in full node size. Increasing the gas limit would make history size increase faster and thus contribute to increases in full node size.
There's been a lot of discussion about increasing the block gas limit, perhaps in response to the criticism about Ethereum being slow compared to Solana. On Twitter, Vitalik made a comment saying that the block gas limit can be increased by a validator vote at any point. Then over an Ethereum Core Developer AMA on Reddit, there was further discussion. General consensus among core developers is that they are willing to increase the gas limit as long as there are incentives in place to keep data and other transactions on other layers (i.e., certain transactions/data should move to rollups)
This discussion transitioned to ethresearch later with notes and design considerations for a possible increase. A few different ideas for solutions have came up.
Increasing calldata costs. Raising these costs allows room to be made for a change in the block gas limit. Rather than straight up raising the block gas limit, thus increasing block size, and then we encounter all the risks aforementioned, calldata can be disincentivized for the L1. Raising calldata price allows more room to be made for the block gas limit without increasing the block size. However, there could be downstream effects for STARKs.
Increase calldata and decrease other costs. Same as above, except ETH R&D specifies a few specific cost drivers for gas usage. This approach is the alleviate ZK L2s like Starknet. The goal is to lower costs just enough so that proof verification from Starknet is not overshadowed by the increased calldata gas price.
Simple 2D calldata pricing. This is EIP-4488 (stagnant development). Could cap the calldata per block, turning it into a strictly scarce resource. This keeps block size relatively bigger compared to the two solutions prior.
Full 2D calldata pricing. This is creating an EIP-1559 for calldata specifically, this would look like blob transactions in the sense that blobs are a separate resource from gas, in this type of market, the resource while separate from gas is priced in variable gas which adjusts so that the number for that resource hits a target (in the long run).
The Loyalty Bonus. This would compensate protocols that need to spend on increased calldata costs. This proposal aims to balance the needs of applications requiring a lot of calldata (ZK applications). In this proposal, applications that require large amounts of calldata but do not accomplish much onchain computation could face higher gas costs, encouraging optimized data usage.
EIP-4444. This EIP is history expiry, and it essentially allows Ethereum clients the capability to prune their historical data (headers, bodies, and transaction receipts) older than a year. This means that historical data older than a year is no longer passed around between nodes.
If you do like reading all the mumbo jumbo, here are some pretty good aggregate resources to check out.
Subscribe to Order and Flow
Subscribe to Order and Flow
Darren
Darren
<100 subscribers
<100 subscribers
No activity yet