Uncle Interest Rate and Transaction Fee Analysis
One important indicator of how much load the Ethereum blockchain can safely handle is how the uncle rate reacts to the gas usage of a transaction. In any blockchain of the Satoshian proof-of-work kind, every block published runs the risk of becoming “stale.” Since another miner posted a competing block before the recently published block reached it, and is not part of the main chain, a “contention” occurs between the two blocks, resulting in a situation where one of them inevitably falls behind.
One important thing to note is that the more transactions a block contains (or the more gas it uses), the longer it takes to propagate through the network. One important study of this in the Bitcoin network is: Decker and Whartonhofer (2013), which results in an average propagation time of about 2 seconds for a block, plus 0.08 seconds per kilobyte of the block (i.e., a 1MB block takes ~82 seconds). all Latest Bitcoin Unlimited Research Subsequent improvements in transaction propagation techniques have shown this time to be reduced to ~0.008 seconds per kilobyte. You can also see that the longer a block takes to propagate, the more likely that block is to become stale. With a cutoff time of 600 seconds, a 1 second increase in propagation time should correspond to a 1/600 increase in the chance of falling behind.
A similar analysis can be done on Ethereum. The only difference is that thanks to Ethereum’s “uncle” mechanism, we have very solid data to analyze. Old blocks on Ethereum can be re-included in the chain as “uncles”, where they receive up to 75% of the original block reward. This mechanism was originally introduced to reduce centralization pressure by reducing the advantage that well-connected miners have over poorly connected miners, but it also has several side benefits. One of them is that old blocks are always tracked in a very easily retrievable way. Database – the blockchain itself. Data dumps from blocks 1 to 2283415 (before the September 2016 attacks) can be used as data sources for analysis.
Below is a script that generates some source data. http://github.com/ethereum/research/tree/master/uncle_regressions/block_datadump_generator.py
The source data is as follows: http://github.com/ethereum/research/tree/master/uncle_regressions/block_datadump.csv
The columns represent, in order, block number, number of uncles in the block, total uncle rewards, total gas consumed by uncles, number of transactions in the block, gas consumed in the block, and block length. Length of the block in bytes, excluding bytes and 0 bytes.
You can then use this script to analyze it. http://github.com/ethereum/research/tree/master/uncle_regressions/base_regression.py
The results are as follows: Typically, the uncle ratio is consistently around 0.06 to 0.08, and the average gas consumption per block is around 100000 to 300000. Since we have the gas consumption of both the block and the uncle, we run a linear regression to estimate how much 1 unit is. The amount of gas increases the probability that a particular block will become uncle. The coefficients are:
Block 0~200k: 3.81984698029e-08 Block 200k~400k: 5.35265798406e-08 Block 400k~600k: 2.33638832951e-08 Block 600k~800k: 2.12445242166e-08 Block 8 00k ~1000k: 2.7023102773e-08 block 1000k~1200k : 2.86409050022e-08 Block 1200k~1400k: 3.2448993833e-08 Block 1400k~1600k: 3.12258208662e-08 Block 1600k~1800k: 3.18276549008e-08 Block 1800k~ 2 000k: 2.41107348445e-08 Block 2000k to 2200k: 1.99205804032e-08 Block 2200k~2285k: 1.86635688756e-08
Therefore, for every 1 million gas worth of transactions included in a block, there is an additional ~1.86% chance of that block being an uncle. During the Frontier period, this was closer to 3-5%. The “base” (i.e. uncle rate of 0 gas blocks) is consistently ~6.7%. For now, I will leave these results alone and draw no further conclusions. There is another complication that will be discussed later, at least with regard to the implications of this finding for gas restriction policy.
gas price
Another issue related to the spread of uncle fees and transactions is gas prices. A common argument in Bitcoin development discussions is that block size limits are unnecessary because miners already have a natural incentive to limit block sizes. This means that every kilobyte they add increases the stale rate, threatening the block reward. Considering the impedance of 8 seconds per megabyte and the fact that every second of impedance corresponds to a 1 in 600 chance of losing the 12.5 BTC block reward found in the Bitcoin Unlimited study, this amounts to an equilibrium transaction fee of 0.000167 BTC per kilobyte, assuming otherwise. means. Block size limit.
In the Bitcoin environment, there are reasons to be skeptical over the long term about the economics of this unlimited incentive model. In the end there will be no block rewards, and the only thing miners will lose by including too many transactions is: their fees different The economic argument is that once a transaction occurs, the equilibrium effective efficiency will be: Up to 50%. However, the protocol can be modified to limit this coefficient.
In the current Ethereum environment, the block reward is 5 ETH and will remain so until the algorithm changes. Receiving 1 million gas means there is a 1.86% chance of Block becoming your uncle. Fortunately, Ethereum’s uncle mechanism has a happy side effect here. The recent average uncle reward is around 3.2 ETH, so 1 million gas means you only have a 1.86% chance of risking 1.8 ETH. Without the uncle mechanism, the loss is expected to be 0.033 ETH instead of 0.093. So the current gas price of ~21 shannon is actually very close to the “economically reasonable” gas price of 33 shannon (this was before the DoS attack and subsequent optimization, and is likely much lower now).
The simplest way to further reduce the balance gas price is to improve the uncle inclusion mechanism and try to include uncles in blocks as quickly as possible (perhaps by propagating every block separately as a “potential uncle header”). Once the limit is reached and all uncles are included as quickly as possible, the equilibrium gas price will go down to about 11 shannons.
Is data affordable?
The second linear regression analysis can be performed using the source code here. http://github.com/ethereum/research/tree/master/uncle_regressions/tx_and_bytes_regression.py
The goal here is to ensure that: After considering the gas coefficient calculated above, correlated with the number of transactions or the block size in bytes remaining. Unfortunately, we don’t have block size or transaction count figures for uncles, so we have to rely on a more indirect trick of looking at groups of 50 blocks and their uncles. The gas coefficients found in this analysis are higher than in previous analyses. Uncle rate of approximately 0.04 per million gas. One possible explanation is that if a single block has a long propagation time and is followed by an uncle, there is a 50% chance that its uncle will be a block with a long propagation time, but the uncle will be another competing block. This theory is in good agreement with the results for a “social uncle rate” of ~0.04 per million and a “personal uncle rate” of ~0.02 per million. Therefore, we will accept it as the most likely explanation.
The regression analysis shows that after taking this social uncle rate into account, each byte accounts for an additional ~0.000002 uncle rate. A byte of a transaction takes up 68 gas, of which It is accounted for by 61 gases. Contribution to bandwidth (the remaining 7 are to bloat the historical database). If you want both the bandwidth coefficient and the calculation coefficient in the gas table to reflect propagation time, this means: really To optimize gas cost, you should increase the gas cost per byte to 50 (e.g. 138). This also entails increasing the base gas cost of the transaction by 5500 (Note: this rebalancing does not mean that everything will be more expensive. Gas limits will be increased by up to 10% average case Transaction throughput does not change.) On the other hand, the risk of a worst-case denial of service attack is greater on execution than on data, so execution requires a greater safety factor. So there is no doubt that there is not enough strong evidence to re-price here, at least for the time being.
One possible long-term protocol change is to introduce separate gas pricing mechanisms for execution and transaction data within the EVM. The point here is that transaction data can be calculated separately from everything else, making it much easier to separate the two. Therefore, the optimal strategy may be to somehow allow the market to balance them out. However, the exact mechanisms to accomplish these tasks still need to be developed.
gas limit policy
For private miners who determine gas prices, the “private uncle rate” of 0.02 per million gas is the relevant statistic. From the perspective of the overall system, the “social uncle rate” of 0.04 per million gas is important. If we don’t care about safety factors and are okay with a rate of 0.5 uncles per block (i.e. a “51% attack” only needs 40% hashpower to succeed, which isn’t actually as bad as it sounds), then this is at least as good as it gets. Analysis shows that the gas limit could theoretically be increased (20 tx/sec) up to 11 million (equivalent to an average of 39,000 gas per tx for current usage or 37 tx/sec for simple transfers). With the latest optimizations, this number could go even higher. However, since we care about safety factors and prefer lower uncle ratios to mitigate centralization risks, 5.5 million is likely to be the optimal level for gas limits, but in the medium term we may want to consider “dynamic gas limits” to target specific targets. There is a formula. This would be a better approach as block processing times could be adjusted quickly and automatically in response to attacks and risks.
Concerns about centralization risks and the need for safety factors do not overlap. The reason is that during an active denial-of-service attack, the blockchain must survive, rather than economically, resist centralization in the long run. If the attacker’s goal is to encourage economic centralization, the attacker could donate money to the largest pool to bribe other miners to join.
In the future, we can expect virtual machine improvements to further reduce the uncle ratio, but eventually networking improvements will also be needed. There are limits to the scalability possible on a single chain, and the primary bottleneck is disk reads and writes, so after some point (around 10-40 million gas), sharding will be the only way to process more transactions. If you want to lower the equilibrium gas price, Casper will help substantially by making the “slope” of the uncle ratio for gas consumption almost zero, at least up to a certain point.
