Popular Science | Expanding DeFi Throughput: Layer-One Articles

以太坊爱好者

特邀专栏作者

2020-09-10 14:12 (UTC+8)

This article is about 9314 words, reading the full article takes about 14 minutes

Explore the limitations of Ethereum and its impact on DeFi users.

AI Summary

Expand

Explore the limitations of Ethereum and its impact on DeFi users.

Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from

Ethereum enthusiasts (ID: ethfans)

, Author: Remco Bloemen, Translator & Proofreader: Min Min & A Jian, reproduced by Odaily with authorization.

If you have used DeFi recently, the recent skyrocketing transaction fees will make you jaw-dropping. Today, transaction fees in the tens or even hundreds of dollars are not uncommon for Ethereum transactions. With such high fees, only giant whales can be profitable, not to mention the grand plans of "making banking services accessible to the unbanked" and "making permission-free financial infrastructure benefit everyone". Ethereum is becoming a place for the rich.

image description

- If it is a small transaction, the handling fee may exceed 10% of the transaction amount -

We want to create a tokenized world where all value can flow freely, and the limitations of the blockchain will prevent us from realizing this vision. That's why 0x Labs has assembled a dedicated team of research engineers to develop solutions to these limitations. In this article, we explore the limitations of Ethereum and its impact on DeFi users. We will also briefly introduce the next generation of blockchains. In a follow-up article, we'll explore another class of solutions (Layer 2) and introduce our own strategy for addressing DeFi's needs.

First of all, it is important to know that the size of Ethereum transactions is measured by Gas consumption. Transactions are packaged into blocks, and a block is produced approximately every 13 seconds. Each block can only hold a limited number of transactions because of what is called a "block gas limit". Currently, the gas limit for each block is 12 million. An ordinary ERC20 token transaction needs to consume about 50,000 Gas. This means that a block can accommodate up to 240 token transfer operations, that is, about 18 transactions can be completed per second. DeFi transactions often involve multiple token transfers, among other bookkeeping operations, which can double costs and further limit throughput. Gas capacity and block time means that there is a steady stream of Gas available for transactions.

Let’s first take a look at the growth of Gas supply and usage since the birth of Ethereum.

Gas usage

Every day, about 6,000 blocks are added to Ethereum, accommodating billions of Gas transactions. This amount is constantly changing and growing over time, mainly due to increased block gas caps. At the same time, as the number and scale of transactions on Ethereum continue to increase, the total amount of Gas consumed by transactions is also increasing.

Looking back at the entire development history of Ethereum, the supply (gray part) and consumption (black part) of Gas are shown in the following figure:

image description

As the graph shows, the gas supply saw a jagged dip before the Byzantium, Constantinople, and Muir Glacier hard forks. These are the effects of the Ethereum difficulty bomb, also known as the ice age. During the ice age, the block generation time will increase exponentially, resulting in a decrease in the number of blocks mined per day, and a decrease in the total daily Gas supply. Of course, this situation is very bad, so the Ethereum network needs to use a hard fork to restore the network. That's what the difficulty bomb is designed to do: introduce improvements so that innovation doesn't stagnate. Since the Constantinople hard fork forgot to reset the difficulty bomb, Ethereum immediately introduced the Muir Glacier hard fork. The subsequent Berlin hard fork is considering changing this mechanism (EIP 2515).

From the Gas usage in the black part of the figure, we can see that since the ICO boom in 2017, Ethereum’s Gas usage has accounted for more than 60% of the upper limit of Gas. Since then, the gas limit has quadrupled through several jumps. After each jump, there is a corresponding increase in Gas usage. For the past few months, Ethereum gas usage seems to be stuck at 95% of the gas limit.

To understand why the Gas utilization rate of Ethereum cannot exceed 95%, we need to understand empty blocks and uncle blocks first.

secondary title

Empty blocks and uncle blocks

Throughout the development history of Ethereum, even when the supply exceeds demand, the Gas usage of Ethereum has not exceeded 95% of the upper limit of Gas. Surprisingly, the remaining 5% of gas is wasted in empty blocks. Empty blocks are regular, about every 20 blocks will have an empty block. Why would anyone mine an empty block when there are paid transactions waiting to be included? Let's look at the data:

The empty block rate has steadily increased over time and is currently around 5%. All mining pools have empty blocks, so it is not malicious. The real problem is that the block rate is too fast. If it takes less than 6 seconds to mine a block, the probability of the block being empty increases exponentially.

One explanation is that miners start mining the next block when they receive the header of a new block but have not yet processed the entire block. This is called "Simple Payment Verification (SPV)" mining in Bitcoin, and allows miners to immediately start mining the next block, but only empty blocks. Once a new block is processed, miners can start packaging and mining the next block. Another piece of evidence that would corroborate this explanation is that if the same miner mines two blocks in a row, the empty block rate decreases by 25%.

In addition to emptying blocks, there is another way to continue mining the previous block (instead of digging newer mineable slots) while processing the new block. This has the potential to result in multiple new blocks being mined. If this happened to Ethereum, the network would elect a valid block and treat other blocks as uncles. Miners who dig out uncle blocks will get the same block rewards. The uncle block rate is very stable:

In 2018, when gas usage peaked, so did the uncle block rate (now down to a steady 5%). During that time, the empty block rate also increased, probably because miners changed their strategy.

There are some methods that can be used to reduce the empty block rate and uncle block rate. It is assumed that the root cause of the high empty block rate and uncle block rate is that the mining pool cannot obtain the latest status due to network and block processing delays. A simple (but undesirable) approach is to make mining pools more centralized, with the latest state in one place. A more decentralized solution is to use bloxroute to create dedicated interconnection channels between mining pools. Another solution inspired by "spy mining" is to have mining pools pre-share the blocks they are mining. Other mining pools can prepare the next block for each block being mined. Once a certain mining pool has successfully dug out a block, the other mining pools will know which block to mine next and switch over immediately. At a higher level, improving node communication protocols and processing algorithms can also help, and perhaps bring some benefits. However, as we have seen, reducing the uncle block rate and empty block rate can increase the daily gas supply by up to 5% or so.

gas price

From this, the gas cap is 95% of the gas supply. So what happens if people's demand for gas exceeds this ceiling?

secondary title

gas price

What happens when the demand for Gas from Ethereum users approaches the upper limit? Miners can choose transactions to include as they wish (see below for details). But in fact, miners will give priority to packaging transactions with high Gas prices, because this will maximize their profits, and eventually trigger the highest price auction for Gas.

Gas price has become a perfect example of inelastic supply. As the utilization rate of Gas on the Ethereum network exceeds 80% and approaches the upper limit of 95%, the price of Gas will rise sharply. The increase in demand will only drive up the price of Gas until users cannot afford it. The only way to lower the price of Gas is to increase the supply of Gas or reduce the demand for Gas. The recent increase in the gas limit is not enough to effectively lower the gas price.

The data in the figure represents the minimum price that needs to be paid to be included in the next block. If you are willing to wait a little longer, the gas price will be much lower. Judging from recent historical data, if you are willing to wait for two minutes or more, the gas price will drop. EIP 1559 helps to speed up the processing of transactions while reducing premiums.

Gas limit

secondary title

The mining pool determines the gas limit of the block. Let’s start with a quick recap of how miners and pools operate: almost all miners choose to pool their origins of computing power with those of others. They will pool their resources together and obtain a steady flow of income, rather than risking no income for a long time and mining alone. Therefore, mining pools came into being, responsible for verifying the contribution of each miner and assigning the mining task of the next block. Most blocks are mined by large mining pools. The figure below shows the percentage of blocks produced by mining pools since the birth of Ethereum:

As can be seen from the figure above, Spark Pool, Ethermine and F2Pool are far ahead in the proportion of block generation.

In addition to participating in hard forks, mining pool operators also undertake an important governance responsibility: setting the gas limit of Ethereum. Different from characteristics such as block time and Gas price, the gas upper limit of each block needs to be actively set. The difference between the gas limit of the new block and the previous block must be within 0.1%, so the size of each block can only fluctuate slightly (see the yellow paper: formula 47). If the mining pool operators reach a consensus, the gas limit can be adjusted significantly: within 2.5 hours, the gas limit can be doubled or halved. If there is no consensus, the gas limit is the weighted median of the mining pool size.

Currently, due to the lack of detailed information about the real behavior of miners, we have taken a simpler approach: the voting system. Hopefully we will be able to convert this approach to a more precise algorithm in the future via a soft fork.

- Fundamental Design Principles of Ethereum (March 2015)

text

image description

Recently, two of the largest Ethereum mining pools in the world made a controversial decision to increase daily gas production by 25%. The purpose of this move is to curb excessively high transaction fees by increasing the Gas supply. So far, we have found that no matter how we increase the gas limit, we cannot keep up with the growth rate of user demand for transactions. This means that after a short-term decline in Gas prices, they will eventually rise again.

Increasing the gas limit will bring high hidden security costs to Ethereum. As we can see, increasing the gas limit will increase the rate of uncle blocks and empty blocks. In the case of normal transaction load, this effect is not significant. But for security reasons, we are only interested in extreme cases, not normal cases. According to the research of Perez and Livshits (2019), in the worst case, if a batch of transactions with extremely low processing efficiency is generated (the speed of processing such transactions is 100 times slower than ordinary transactions at the same Gas cost), And pack it into the block, the node needs to spend 90 seconds to process this block, which causes the node to fall behind, and the mining pool digs out a large number of empty blocks and uncle blocks. Since the publication of this study, some mitigations have emerged, but the problem has not been fully resolved. Therefore, the decision to increase the gas limit was criticized by two of the main node developers, Péter Szilágyi and Alexey Akhunov.

text

So when the gas cap is reached, the gas price goes up, and it doesn't seem like we should raise the gas cap any further. So what else can we do? Can we reduce the gas cost required for transactions?

secondary title

Gas consumption

The gas consumption of a transaction is basically the consumption of its EVM operation. A transaction is composed of many basic EVM operations, and the Gas consumption of each operation is governed by EIP and hard fork. In the past hard forks, the Gas consumption of major operations increased (EIPs 150, 160, 1884) and decreased (EIPs 1108, 2028, 2200). The planned "Berlin" hard fork is also considering introducing several gas consumption changes (EIPs 1380, 1559, 2046, 2565, 2537).

This means that storage will still be a big chunk of DeFi costs. Creating a new balance costs 20,000 Gas, and modifying an existing balance costs 5,000. A transfer needs to change at least two months, and an exchange needs to change at least 4. More complex DeFi transactions will include more expensive state operations. It seems that it is really not easy to reduce the quantity and cost of related storage, and this trend cannot be pulled back. But the good news is that the Layer-2 scaling solution will try to be storage-intensive and computing-intensive, which will look more pleasing.

Finally, increasing the gas limit of a block also has security concerns: increasing the gas limit is the worst of the effective methods. It is also very dangerous to change the Gas consumption purely based on the average cost of the current real operation (Naively optimizing the Gas cost for the current true average cost of operations is very dangerous.).

By now, it should be clear why scaling Ethereum is a tricky problem. Before we discuss the solutions you have proposed, we want to discuss one more current disadvantage of Ethereum that may hurt DeFi users.

secondary title

Miners can extract value

Although block producers are constrained by consensus rules, consensus rules also provide them with some important freedoms, such as transaction selection and ordering. For general token transfers, the freedom of producers will not have a great impact, but for DeFi transactions such as exchange transactions, front-running (refers to sending transactions with higher Gas Prices to preemptively use transactions on the chain) may reap huge economic value. To further complicate matters, a target transaction is sandwiched between two transactions. Daian et al. (2019) refer to the value that can be obtained from front-running transactions as miner extractable value.

On the other hand, it may also be valuable to have your own transaction on the chain immediately after another transaction, such as being the first to liquidate a position after the price information transmission mechanism updates the information. This is called back-running, and it will eventually become the miners' income.

The value that miners can extract is ultimately obtained from ordinary DeFi users, manifested in larger spreads, worse prices, higher handling fees, and more failed transactions. To get a better DeFi experience, this problem should be solved. One of the solutions is to limit the freedom of ordering transactions, such as requiring transactions in a block to be ordered from low to high by Gas Price.

Now we have a comprehensive understanding of the limitations of Ethereum and its impact on DeFi. Of course, all great teams are developing solutions, right?

secondary title

One Layer-1, Two Visions

There are a lot of great teams working on different scalability solutions right now. The solution mainly has two directions, "Layer-1" and "Layer-2". The Layer-1 solution is to create a more scalable blockchain to replace the current Ethereum, and the Layer-2 solution is to try to access a more scalable infrastructure based on the current Ethereum. We will talk about Layer-1 here, and leave the Layer-2 solution to the next article.

We start with the most obvious one: improving the performance of the current Ethereum blockchain. That is what "Eth1.x" colleagues are doing. In terms of improving the performance of the Ethereum client alone, there is a lot of work that can be done. However, Eth1.x has not received the support they deserve, so progress is slow. If you want to have a basic idea of the extent to which performance improvement in this direction can be achieved, you only need to know about Solana. Solana has achieved 1000 times the throughput of Ethereum, and there is still room for improvement; the disadvantage is that it requires very advanced hardware. to run a full node.

Most of the other solutions have three things in common: (1) use of WebAssembly as a virtual machine; (2) architecture with minimal state; and most importantly, (3) sharding. The current Ethereum executes all transactions serially. In fact, enabling transactions to be queued is arguably the whole point of the blockchain. But the disadvantage of this model is that it is difficult to execute transactions in parallel, so we cannot solve the scaling problem by investing more resources directly. Then divide the blockchain into multiple loosely interconnected fields, and a thread is called a "shard", which can realize parallel processing. Within a shard, transactions still occur serially, but transactions in different shards occur incrementally. This allows all shards to run in parallel, expanding the throughput of the network by a multiple of the number of shards. The domains we use to split the network do not need to be in one-to-one correspondence with the shards. We can assign multiple domains to the same shard (thread), and even move them for load balancing. See Near Protocol's "Night Shadow" protocol white paper for a deeper understanding of sharding in general.

The two items of chains represent the two ends of the spectrum. DFinity is at the fine-grained end, where each "actor" has its own domain, and the interactions between each actor are asynchronous. A slightly larger Near Protocol, where each contract has its own domain. At the coarse-grained end is PolkaDot, a domain is an entire shard, and more specifically it should be called a "parallel chain". From a dApp developer's perspective, it's too early to tell where Ethereum 2.0 will be. ETH1 EE (execution environment) should be coarse-grained, and its boundary is exactly the same as the boundary of a shard, which is a shard formed by the current Ethereum (that is, the future of Eth1 after the realization of Eth2). A dedicated Eth2EE might opt for a more fine-grained approach. The strength of fine-grained schemes is that they are transparent; all cross-contract calls can be treated equally, whether they cross shard boundaries or not. This in turn allows us to load balance by moving contracts between shards.

But for DeFi applications, an asynchronous transferFrom call will bring considerable challenges. Imagine a simple exchange between two parties, Alice and Bob wishing to exchange Eth and Dai. A basic contract would look something like this:

But now we need to be able to handle errors. If the first transaction fails, we can simply abort the transaction. But if the first transaction is successful and the second transaction fails, we need to be able to return an ETH to Alice. The problem is that Bob may have spent the money before we have dealt with the error. One way around this is to use an escrow:

Great, no one will lose coins now. But now Bob has a free exclusive option on Alice's bid. Although Alice's money is now kept in the custody of the custodian, the money can neither accept other people's transaction requests nor guarantee that the transaction with Bob will be successful. You can solve this problem by punishing malicious behavior, but it is difficult for you to determine a reasonable punishment, because the value of different DeFi transactions varies greatly. You could also require all market participants to put their money in the same savings contract (custodian) from the start, but that would re-centralize the state and defeat the point of sharding.

Another thing to be aware of is that these concurrency issues can be tricky. In a real exchange, the fill-state of the order needs to be updated continuously, which makes writing it more complicated. If the reentrancy bug that plagued Ethereum 1.0 is a butterfly with potentially huge consequences, then the concurrency problem is a bug in the bed that can get in everywhere. Concurrency bugs are non-deterministic and may not show up at all in testing. As we saw in the simple swap example above, developers need to rethink the entire architecture from the ground up, like bed bugs, the only way to get rid of them is to pull everything down and rebuild from scratch.

Exchanges are the cornerstone of the rest of the DeFi world, and are clearly a continuous process. We’ve already seen how order book-type exchanges face challenges. Automated market maker exchanges are simpler because participants already store funds in custodians (contracts), but in this scenario, the reserve balance itself prevents parallel processing. Even in faster traditional exchanges, settlement activities are ultimately processed sequentially in a matching engine, and concurrency will not be used, (but it is better that traditional exchanges can also have redundancy). For an in-depth look at how traditional exchanges work, watch Brian Nigito's talk.

text