Why does Ethereum Gas fee hinder the development of DeFi? what to do?
Editor's Note: This article comes fromChain News ChainNews (ID: chainnewscom)Editor's Note: This article comes from
Chain News ChainNews (ID: chainnewscom)
, written by: Remco Bloemen, 0x technical expert, compiled by: Leo Young, published with permission.
If you have used DeFi products recently, you will definitely be discouraged by the high transaction fees. It is now normal to pay transaction fees ranging from tens to hundreds of dollars for Ethereum transactions. At current rates, only "whales" trade profitably. Forget the lofty goals of “banking-the-unbanked” or “building a permissionless financial infrastructure for everyone.” Ethereum has become a playground for the rich.
image description
Small transaction fees can sometimes be as high as 10%
We want to create a tokenized world where all value flows freely, but the limitations of the blockchain are preventing us from achieving this mission. That’s why 0x Labs has dedicated a team of engineers to address these limitations. Through our research, we hope to explore the limitations of Ethereum through this article, and how it affects DeFi users. In addition, this article will briefly discuss the next generation of blockchain. In the future, we will also write articles exploring different solutions Layer 2 and demonstrating our strategies for meeting the needs of DeFi.
First of all, the size of Ethereum transactions is calculated in gas. Transactions are collected in blocks, approximately every 13 seconds. The number of transactions that each block can accommodate is limited, which is the "ga s upper limit". Currently each block has about 12 million gas transaction space. A pure ERC-20 token transfer requires about 50,000 gas. That is, each block can accommodate up to 240 token transfers, about 18 transfers per second. DeFi transfers typically involve multiple token transfers and bookkeeping, doubling transaction costs and limiting block throughput. The "gas cap" and block time means that the gas required for transactions needs to be continuously provided.
First, let's look at how Ethereum's gas supply and its usage have grown historically.
Gas use
About 6,000 blocks are dug out on Ethereum every day, and there are billions of worth of gas transaction space. Mainly due to the increase of the "gas limit", the number of gas transactions also changes and increases over time. At the same time, the total gas fee consumed by the transaction will also increase as the number of transactions on Ethereum increases and becomes larger.
Looking back at the gas supply (gray) and consumption (black) of the entire history of Ethereum, as shown in the figure below:
image description
As can be seen from the above figure, Ethereum is an enterprise-level application, because the application of office hours is the highest
In the "Ice Age", the block generation time increased significantly, resulting in a decrease in the number of blocks produced in a single day and a decrease in gas supply. Of course this situation is very unpopular, forcing a network hard fork to adjust. The purpose of this is to force hard forks to bring about upgrades and improvements, and to prevent innovation from stagnating. The Istanbul (Istanbul) hard fork did not reset the "difficulty bomb", so the Muir Glacier hard fork was carried out soon. The upcoming Berlin (Berlin) hard fork considers changing this mechanism (EIP 2515).
Looking at the usage (black), since the ICO craze of Ethereum in 2017, the gas usage has always accounted for more than 60%. After that, the "gas upper limit" was increased to four times several times, and the gas usage also increased proportionally after each upper limit increase. Ethereum usage has been stuck at 95% for the past few months.
To understand why the gas usage of Ethereum does not exceed 95%, you need to understand the concepts of "empty block" and "ommer block".
secondary title
"Empty Block" and "Uncle Block"
In the history of Ethereum, even if the demand is high, the gas usage has never exceeded the upper limit of 95%. Surprisingly, the remaining 5% is wasted on completely empty blocks. These empty blocks appear periodically, approximately one in every twenty blocks. There are transactions that need to be paid to be packaged into blocks, why would anyone want to mine empty blocks? First look at the following data:
The empty block rate has steadily increased over time and is currently 5%. All mining pools have the same empty block rate, so it will not be malicious miners who mine empty blocks. On the contrary, the real reason may be that blocks are generated too quickly. If the block mining time is less than six seconds, the probability of obtaining an empty block will increase geometrically.
One explanation is that as soon as the miners get the new block header, they start digging the next block before the entire block is packaged. This operation is called SPV mining in Bitcoin, which allows miners to start looking for the next block immediately without completing a block verification, but can only add empty blocks. After the new block is fully packaged, the next complete block can be added and switched to mining.
Further evidence for this explanation is that if the same miner mines two blocks in quick succession, the empty block rate decreases by 25%.
Another way to mine empty blocks is to process new blocks at the same time as the previous block was mined. This results in multiple blocks being mined at the same time. If such a situation occurs, Ethereum will select a main block and mark other blocks as "uncle blocks" (ommer). Miners who dig "uncle blocks" can still get small rewards. The rate at which this occurs is stable:
During the peak of gas usage in 2018, the "uncle block" rate also reached a new high, but then the proportion dropped to 5% of all mined blocks. This coincides with the fact that miners may change their mining strategy at this time, resulting in an increase in the empty block rate.
The harm the empty block rate does to Ethereum’s scalability isn’t immediately apparent, but it does have an impact. Since the EIP-100 proposal upgraded by Byzantium, the difficulty adjustment maintains a certain ratio of main chain blocks and "uncle blocks". Therefore, a high rate of "uncle blocks" means that more "uncle blocks" are wasted and fewer blocks are added to the main chain. This is reflected in the extension of the daily block generation time and the reduction of the total daily gas amount. (Another reason for the extended block time is the "difficulty bomb")
A more decentralized solution would be to create dedicated connections between mining pools like bloXroute does. Inspired by "spy mining", mining pools can pre-share blocks currently being mined. Other mining pools prepare subsequent blocks that may be mined. After the mining pool has successfully dug its own blocks, it already knows which blocks can be mined in the future and switches immediately. Above the stack, improving node communication protocols and processing algorithms is also effective, and there is still room for improvement in these areas. Ultimately, reducing the empty block rate and "uncle block" rate can increase the gas supply by up to 5% in a single day.
gas price
So there seems to be a 95% gas cap, but what if someone wants to use more than 95%?
secondary title
gas price
What will happen if the Ethereum gas limit is reached? Miners are free to choose to package transactions (detailed later), but in fact miners package transactions according to the "principle of high gas fee priority", because this is the most profitable. This creates a first-price auction for available gas.
Gas price has become a textbook model of "perfect inelastic supply". As the network utilization exceeds 80% and rises to 95%, the gas price increases significantly. Any potential increase in demand will only increase the price until the price drives off the demand and falls back to the same level.
The only way to get the price down is to increase gas supply, or reduce demand, and recent gas cap increases have not been enough to effectively lower gas prices.
At first glance, increased interest in Ethereum will only drive up prices, not usage. In fact, high-value uses will drive out low-value uses, with fewer cheap game-type non-fungible token (NFT) transactions and more large-value DeFi transactions.
According to the proposal EIP-1559, there is still a fixed gas issuance rate in the long run, which means that the gas price will continue to rise until the demand is small enough. EIP-1559 still encourages priority packing within the same block that pays a premium (assuming pools continue to mine blocks in the original order). This means that front-running transactions, gas bidding, and miner profit still exist.
The numbers in the figure represent the lowest price that can be packaged in the next block. The longer you are willing to wait, the lower the gas price will be. Historical data shows that if you are willing to wait two minutes or more, the price will be low. EIP-1559 helps reduce premiums for faster transaction processing.
So the gas cap pushes the gas price up, so how do we raise the cap?
secondary title
Gas limit
The mining pool determines the gas limit. Here is a brief overview of how miners and pools work: almost all miners pool computing resources. Miners will not go to the next block alone at the risk of no harvest for a long time, but gather resources to obtain a stable income. The mining pool verifies the computing power contributed by each miner, and then continues to dig the next block, which promotes the development of the mining pool. Large mining pools end up mining a larger share of blocks.
Let’s take a look at the development of mining pool shares on Ethereum:
Xinghuo, Ethermine and Yuchi won the main blocks.
Due to the lack of detailed information on the actual operation of miners, we will use a simple method: the voting system. […] hopefully in the future we can soft fork to a more precise algorithm.
**Ethereum Design Principles (First added in March 2015)**
The way Ethereum’s early miners set the upper limit of gas was a “filling solution”. Many "filling solutions" are good enough to become backup parameters. EIP 1559 proposes a different mechanism, which is currently under discussion for use in the event of a Berlin fork. Before that, mining pool operators could control gas supply just like OPEC controls oil production.
image description
Recently, the two mining pools unanimously decided to increase the gas output by 25%, which is quite controversial. The purpose is to alleviate the pressure of high transaction fees by increasing the gas supply. What we have seen so far is that transaction demand is growing faster than the gas cap. This creates a temporary slowdown in prices, which will eventually rise.
Increasing the gas limit will bring huge hidden dangers to the security of Ethereum. As mentioned above, the gas cap will increase the "uncle block" rate and the empty block rate. Under normal transaction load, this increase is small. But for security, we don't care about normal behavior, only bad behavior in bad situations. Perez and Livshits (2019) studied this bad situation, and the result is that under the same gas cost, transactions in bad times are 100 times slower than normal transactions. It takes ninety seconds for a block to be filled with transactions. This causes the node synchronization to lag, and the mining pool digs "uncle blocks" and empty blocks. As of the publication of this manuscript, the problem has been alleviated, but not enough to avoid it. This led two main node developers, Péter Szilágyi and Alexey Akhunov, to criticize the decision to increase the gas limit.
Therefore, the gas cap drives up the gas price. Seems like we shouldn't just increase the gas limit. What should I do? Maybe lower gas costs for transactions?
secondary title
Gas cost
The gas cost of a transaction is mainly composed of EVM operating costs. A transaction is composed of many EVM operations, and the cost of each operation is determined by EIP and hard fork. Over the past few hard forks, the gas cost of some operations has increased (EIPs 150, 160, 1884) and some decreased (EIPs 1108, 2028, 2200). The planned Berlin hard fork is also considering changing the gas cost of certain operations.
The goal of all changes is to make fees more accurately reflect the true cost of operations. This means that as computers and algorithms get faster, computing costs decrease to run.
This means that storage is still a "big cost" for DeFi applications. Creating a new balance costs 20,000 gas, and modifying an existing balance costs 5,000 gas. The transfer needs to modify the balance at least twice, and the remittance needs to be modified at least four times. The status fee required for DeFi transactions is higher. There doesn't seem to be an easy way to reduce the amount of storage involved, and storage fees go up as demand arises. On the bright side, Layer 2 scaling solutions tend to be light-weight storage and high-computing, which seems to have more advantages.
Finally, as the gas cap increases, the same security concerns arise: bad things matter. Locally optimizing the gas cost to the average cost of the current operation is dangerous.
This makes it clear why Ethereum's scalability problem is so thorny. Before giving a solution, it is necessary to mention another limitation of Ethereum that currently hurts DeFi users.
secondary title
miners for profit
Block packers obey the consensus rules. Consensus rules guarantee important freedoms such as transaction selection and ordering. For ordinary token transfers, it's not a big problem. But for DeFi transactions such as exchanges, front-running transactions have high economic value. When both sides of the target transaction are attacked, more complex profit-making behaviors will emerge. Daian et al. (2019) call this "miner extractable value".
In other cases, the very next trade will have value, such as being the first to liquidate a position after a price oracle update. This is called "back-running", and it also benefits miners as a result.
Large price differences, price deviations, high fees and more failed transactions will eventually damage DeFi users and profit miners. For a better DeFi experience, this problem needs to be solved. To solve this problem, it is necessary to limit the freedom of ordering transactions, such as requiring the transaction with the lowest gas price in a block to be given priority.
The limitations of Ethereum and how it affects DeFi are now fully understood. Surely all star teams working on scalability will solve this problem eventually, right?
secondary title
Strengthen the bottom layer, focus on the second layer
There are many great teams working on different scalability solutions. There are two solutions: Layer 1 and Layer 2 . The goal of the Layer 1 solution is to build a more scalable Ethereum, and the Layer 2 solution is to build a more scalable infrastructure on the basis of Ethereum.
Start with the most obvious problem: improving the performance of existing Ethereum - this is what Eth1x is about. There are still many improvements that can be made to improve the performance of the Ethereum client. Unfortunately, Eth1x has hardly any support it deserves, and all progress is very slow.
To understand what kind of performance Eth1x can achieve, let's first look at Solana. The throughput of Solona can reach more than a thousand times that of Ethereum, and there is still room for improvement. The main disadvantage of this approach is that the hardware requirements to run a full node are high.
Most other solutions have three things in common:
Using WebAssembly as a virtual machine, minimal stateful architecture, and most importantly sharding. Currently all transactions on Ethereum are executed sequentially. Transaction ordering is without a doubt the key to blockchains. The disadvantage of this model is that it is difficult to parallelize, so investing more resources cannot easily solve the scalability problem. This is what the next generation blockchain Eth2.0 will solve.
Allow transactions to be processed in parallel by changing the way transactions are executed. This scheme is achieved by dividing the blockchain into multiple loosely connected domains, or processes called "shards". Transactions within a shard are still ordered, but asynchronously between shards. This allows all shards to run in parallel, scaling the network by the number of shards.
The domain used for separation does not necessarily match the shard. The same shard can have multiple domains, and domains can even be migrated to achieve load balancing. For an in-depth understanding of sharding technology, readers are referred to the "Night Shadow" paper of the Near Protocol.
Where and when the main chain of the next-generation blockchain is divided into domains depends on the situation. Second-generation blockchains can be seen as a spectrum from fine-grained (many tiny domains) to coarse-grained (few large domains).
Two projects occupy either side of the granularity spectrum: Dfinity is on the fine-grained end, where each agent has its own domain and each agent interaction is asynchronous. The Near protocol is slightly less fine-grained, and each contract has its own domain. The coarse-grained end is Polkadot, and its domain is the entire shard. This situation is called "parallel chain" more accurately. It is too early to judge Ethereum 2.0 from the perspective of DApp developers. Eth1EE (Eth1 Execution Environment on Eth2) will be coarse-grained, with boundaries consistent with sharding, and the current Ethereum will become a shard. The advantage of a fine-grained solution is transparency; calls between contracts look the same whether they cross shard boundaries or not. This in turn allows moving contracts between shards to easily balance load.
The disadvantage is that cross-domain transactions are no longer atomic, but become parallel, some of which are irrevocable. Dfinity and Near show that the call between contracts is async, and the return contract waits for await. All transactions that occur during the await will be written to the chain. Then other people's transactions can be superimposed on top of it. At this time, all previous transactions cannot be undone. After await is finally confirmed, it can return the success or failure command of the contract call. There are multiple proposals to avoid this situation and achieve some atomicity across shards, but this also has disadvantages. Embracing deatomization seems like a natural consequence.
For DeFi, the asynchronous transferFrom call poses a big challenge. Imagine a simple transaction between two parties, Alice and Bob want to trade in ETH and DAI. The base contract should be:
But now I need to handle errors. If the first transaction fails, we can stop the transaction. If the second transaction fails, 1 ETH needs to be returned to Alice. The problem is, at this point Bob may have already spent that 1 ETH. One way to solve this problem is hosting.
That's it, no one loses. But now Bob has exclusive freedom to choose Alice's transaction. Alice's tokens are in escrow, no other transactions will be made, and there is no guarantee that the transaction with Bob will be successful. Fixing this issue could lead to penalties for violators. However, DeFi transactions are very expensive, so it is difficult to determine how much punishment is appropriate. Solving this problem can require all parties in the market to initially deposit funds into custody in a deposit contract. And this becomes a centralized state, and there is basically no need for sharding.
Transactions are the foundation of DeFi construction and are a series of processing procedures. We already know how exchange trading books pose challenges. The automatic market maker exchange is relatively simple because there is a escrow reserve, but the balance of the reserve forms a bottleneck that prevents parallelism. Even on the fastest traditional exchanges, settlement is not parallelized (although there will be redundancy), and is done in a single matching engine order. For a detailed look at how traditional exchanges work, Brian Nigito's talk is great.
refer to
Daniel Perez & Benjamin Livshits (2019). “Broken Metre: Attacking Resource Metering in EVM.”
Daian et al. (2019). “Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges.”
Brian Nigito (2017). “How to Build an Exchange.”
Danny Ryan (2020). “The State of Eth2, June 2020.”
Scott Shapiro & William Villanueva (2020). “ETH 2 Phase 2 WIKI.”
Near Protocol sharding design
