“`html
One significant metric of how much capacity the Ethereum blockchain can securely manage is the response of the uncle rate to the gas consumption of a transaction. Across all blockchains of the Satoshian proof-of-work type, any block that is created faces the possibility of becoming “stale”, meaning it will not be part of the primary chain, because another miner could have published a competing block prior to the newly published block reaching them, resulting in a scenario where there is a “competition” between two blocks, with one inevitably left behind.
An essential aspect is that the greater the number of transactions a block encompasses (or the higher the gas usage of a block), the longer it takes to disseminate throughout the network. In the Bitcoin ecosystem, a pivotal study in this area was Decker and Wattenhofer (2013), which discovered that the average block propagation time was approximately 2 seconds, plus an additional 0.08 seconds for each kilobyte within the block (i.e., a 1 MB block would require around 82 seconds). A more recent study from Bitcoin Unlimited demonstrated that this has since diminished to about 0.008 seconds per kilobyte, thanks to advancements in transaction propagation technologies. It is also evident that if a block experiences extended propagation times, the likelihood of it becoming stale increases; at a block time of 600 seconds, a 1 second increase in propagation time is expected to result in an increased probability of 1/600 of being left behind.
In Ethereum, we can conduct a comparable evaluation, especially since Ethereum’s “uncle” mechanism provides us with robust data for examination. Stale blocks in Ethereum can be reincorporated into the chain as “uncles”, where they receive up to 75% of their original block reward. This mechanism was initially implemented to mitigate centralization influences, by diminishing the advantage that well-connected miners hold over poorly connected miners. However, it offers several additional benefits, one of which is that stale blocks are preserved for eternity in a highly searchable database – the blockchain itself. We can utilize a data dump of blocks 1 to 2283415 (prior to the Sep 2016 attacks) as a basis for our analysis.
Here is a script to generate source data: http://github.com/ethereum/research/tree/master/uncle_regressions/block_datadump_generator.py
Here is the source data: http://github.com/ethereum/research/tree/master/uncle_regressions/block_datadump.csv
The columns, in sequence, represent block number, count of uncles in the block, total uncle reward, cumulative gas used by uncles, transaction quantity in the block, gas utilized by the block, size of the block in bytes, and the block size in bytes excluding zero-length bytes.
Utilizing this script enables us to perform an analysis: http://github.com/ethereum/research/tree/master/uncle_regressions/base_regression.py
The findings are as follows. Generally, the uncle rate hovers around 0.06 to 0.08, while the average gas utilized per block lies between 100000 and 300000. Given we possess the gas consumption figures for both blocks and uncles, we performed a linear regression to approximate how much 1 unit of gas augments the likelihood that a specific block will be an uncle. The derived coefficients are as follows:
Block 0 to 200k: 3.81984698029e-08
Block 200k to 400k: 5.35265798406e-08
Block 400k to 600k: 2.33638832951e-08
Block 600k to 800k: 2.12445242166e-08
Block 800k to 1000k: 2.7023102773e-08
Block 1000k to 1200k: 2.86409050022e-08
Block 1200k to 1400k: 3.2448993833e-08
Block 1400k to 1600k: 3.12258208662e-08
Block 1600k to 1800k: 3.18276549008e-08
Block 1800k to 2000k: 2.41107348445e-08
Block 2000k to 2200k: 1.99205804032e-08
Block 2200k to 2285k: 1.86635688756e-08
Thus, each 1 million gas worth of transactions that is integrated into a block now contributes approximately 1.86% to the probability that the block will turn into an uncle, although during the Frontier stage this was closer to 3-5%. The “base” (i.e., uncle rate for a 0-gas block) remains consistently around 6.7%. For now, we will maintain this result as it is and refrain from drawing further conclusions; there is an additional complication that I will address in the future regarding the implications this finding has on gas limit policy.
Gas Pricing
Another factor that influences uncle rates and transaction dissemination is gas pricing. In conversations regarding Bitcoin development, a common point raised is that block size constraints are unnecessary since miners inherently possess a natural motivation to restrict their block sizes, as each kilobyte they incorporate raises the stale rate and thus jeopardizes their block reward. Considering the 8 seconds per megabyte delay identified in the Bitcoin Unlimited study, and the fact that every second of delay is equivalent to a 1/600 chance of forfeiting a 12.5 BTC block reward, this infers an equilibrium transaction fee of 0.000167 BTC per kilobyte in the absence of block size restrictions.
Within Bitcoin’s context, there are reasons to be enduringly skeptical regarding the economics of such a limit-free incentive structure, as ultimately there will be no block reward. When miners’ only risk from including an excessive number of transactions is loss of fees from their other transactions, there exists an economic argument suggesting that the equilibrium stale rate could potentially reach as high as 50%. Nevertheless, adjustments can be implemented within the protocol to limit this coefficient.
In Ethereum’s existing environment, block rewards stand at 5 ETH and will persist in this manner until an algorithmic modification occurs. Accepting 1 million gas translates into a 1.86% likelihood of the block becoming an uncle. Fortunately, Ethereum’s uncle mechanism has a favorable side effect in this regard: the average uncle reward is approximately 3.2 ETH, meaning that 1 million gas merely indicates a 1.86% chance of risking 1.8 ETH, or an anticipated loss of 0.033 ETH instead of 0.093, as would be the case in the absence of
“`an uncle mechanism. Consequently, the prevailing gas rates of approximately 21 shannon are indeed fairly near the “economically rational” gas price of 33 shannon (this is prior to the DoS intrusions and the optimizations derived from them; currently, it is probably even lower).
The most straightforward method to further lower the equilibrium gas price is to enhance uncle inclusion mechanisms and aim to have uncles incorporated into blocks as swiftly as feasible (perhaps by independently disseminating each block as a “potential uncle header”); in an ideal scenario, if every uncle is included as promptly as possible, the equilibrium gas price could decrease to about 11 shannon.
Is Data Underpriced?
A secondary linear regression analysis can be conducted using the source script here: http://github.com/ethereum/research/tree/master/uncle_regressions/tx_and_bytes_regression.py
The aim is to assess whether, after considering the above-calculated coefficients for gas, a correlation exists with the number of transactions or the size of a block in bytes remaining. Regrettably, we do not possess figures for block size or transaction count pertaining to uncles, necessitating a more indirect approach that evaluates blocks and uncles in sets of 50. The gas coefficients derived from this analysis are higher than those obtained previously: approximately 0.04 uncle rate per million gas. A plausible explanation is that if a single block experiences a high propagation time, resulting in an uncle, there’s a 50% likelihood that this uncle is the block with a high propagation time, yet there is also a 50% chance that the uncle is the other block it competes against. This hypothesis aligns well with the 0.04 per million “social uncle rate” and the ~0.02 per million “private uncle rate” findings; thus, we will consider this the most probable interpretation.
The regression reveals that, after accounting for this social uncle rate, one byte corresponds to an additional ~0.000002 uncle rate. Bytes in a transaction demand 68 gas, of which 61 gas represents its contribution to bandwidth (the remaining 7 covers the inflation of the history database). If we wish to align both the bandwidth coefficient and the computation coefficient in the gas table with propagation time, this indicates that if we desired to truly optimize gas expenses, we would need to boost the gas cost per byte by 50 (i.e., to 138). This would also require increasing the base gas cost of a transaction by 5500 (note: this rebalancing wouldn’t imply that everything becomes more expensive; the gas limit would rise by ~10% so that the average-case transaction throughput would stay consistent). Conversely, the threat of worst-case denial-of-service attacks is greater for execution than for data, therefore execution necessitates larger safety margins. As such, there is arguably not compelling evidence to implement any re-pricings at least for now.
One potential long-term protocol modification could involve introducing distinct gas pricing models for in-EVM execution and transaction data; the rationale here is that the two can be separated more easily as transaction data can be processed independently from everything else, suggesting that the optimal strategy might be to enable the market to balance them; however, precise methods to achieve this still require development.
Gas Limit Policy
For a solitary miner establishing their gas price, the “private uncle rate” of 0.02 per million gas is the pertinent statistic. From the broader perspective of the entire system, the “social uncle rate” of 0.04 per million gas is what holds significance. Were we unconcerned about safety factors and accepted an uncle rate of 0.5 uncles per block (indicating a “51% attack” would only require 40% hashpower to succeed, which isn’t as dire as it seems) then at least this analysis implies that the gas limit could theoretically be increased to ~11 million (20 tx/sec given an average of 39k gas per tx as is evident under current usage, or 37 tx/sec for basic sends). With recent optimizations, this could be pushed even higher. Nonetheless, since we prioritize safety factors and prefer a reduced uncle rate to mitigate centralization risks, 5.5 million is likely an optimal threshold for the gas limit, though, in the medium term, a “dynamic gas limit” formula targeting a specific block processing time would present a better strategy, as it would rapidly and automatically adapt in response to attacks and dangers.
It’s important to recognize that concerns regarding centralization risks and the necessity for safety factors do not compound with one another. This stems from the fact that during an active denial-of-service attack, the blockchain needs to endure, not necessarily be resistant to long-term economic centralization; the argument posits that if the attacker’s intention were to economically induce centralization, they could simply contribute funds to the largest pool to incentivize other miners to join it.
In the future, we anticipate enhancements to the virtual machine will further decrease uncle rates, although advancements in networking will eventually be demanded as well. There exists a cap on the degree of scalability achievable on a singular chain, with the primary bottleneck being disk reads and writes, thus after a certain threshold (likely 10-40 million gas) sharding will be the sole avenue for processing additional transactions. If our goal is solely to lower equilibrium gas prices, then Casper will contribute significantly by rendering the “slope” of uncle rate to gas consumption near-zero at least up to a certain extent.
