Illusion level consensus
Ethereum is a decentralized platform that serves as the basis for the operation of smart contracts - applications that work exactly according to their software code, without the slightest probability of downtime, censorship, or the intervention of fraudsters or third-party agents.
- Ethereum.org
We, developers, love to believe in the level of consensus, which imposes the solution of all complex tasks of distributed systems, allowing us to write applications. Miners live at the level of consensus, doing their mining affairs. Developers sit at the application level and write smart contracts - programs that run inside the Ethereum Virtual Machine (EVM). Our decentralized applications interact with the computer, relying on its integrity and security.
We know that EVM works by consensus, and we don’t need to think about this mechanism as long as it works. We do not think about miners, because in the end, there is no need to understand the principle of operation of semiconductors or the design features of modern computer chips. But, alas, this convenient and predictable separation between levels is nothing more than an illusion. The illusion of a level of consensus that helps us forget that miners are not our friends.
In practice, the transition from contracts to consensus is a much less smooth phenomenon, and not as unambiguous as is commonly believed. Creating blocks affects the state of EVM, which in turn affects the challenges of smart contracts and as a result affects the operation of decentralized applications and their users. The slower the blocks, the slower the decentralized applications. The faster the blocks, the faster the application. Empty blocks cause applications to stop working.
From time to time, the level of consensus inadvertently interferes with the work of decentralized applications. But there may be cases in which representatives of this level can intervene deliberately. Manage the level of consensus miners. They work for money, and therefore they will maintain the application level only as long as it brings them profit. If they can earn more money by intervening at the application level, they will eventually do it.
Miner you are not friends. But not enemies. They don't want to hurt you, they just can't avoid it. These are the requirements of Proof-of-Work. Miners have to engage in fierce competition for the right to receive a very small margin. They are stuck on the “Miner treadmill”, where the fastest runners set the pace.
Whenever they manage to invent another way to speed up or cheapen the calculation of hashes, the complexity increases. With its growth, each individual hash becomes all significant to me. Your hash rate may remain unchanged, but you gradually start getting less and less. In this respect, Proof-of-Work forces miners to constantly reinvest profits. They make a profit only by constant spending, optimizing and maintaining competitiveness. Those of them who fail to compete go the distance .
If your profitability is 1%, then a 1% decline in income deprives you of profit. If the miner's hash rate becomes a little less than the current norm, it lags behind the rest of his colleagues. On the other hand, a 1% increase in revenue leads to a doubling of profits. Even a small gap in efficiency allows miner to receive much more money for their reinvestment in equipment. And the detachment of such participants is growing more and more, as a result of which less successful competitors with time can no longer oppose anything to them. Proof-of-Work provokes miners to look for small advantages, improve any aspects of the process and use this to throw competitors off the treadmill.
There are two ways to improve the profitability of mining - increasing profitability or reducing costs. Profit consists of awards for approved blocks and commissions for the transactions included in them. Costs arise from the need to pay for electricity, equipment, staff salaries, office rent and similar costs.
Currently, miners are competing with quite obvious major improvements, such as finding lower electricity tariffs or improving equipment. Unfortunately, this approach leads to a further decrease in profits in the future. It is becoming more and more difficult for companies to find cheaper electricity. Mining with the help of graphics cards rests on the limitation of memory bandwidth, and "Asiki", in turn, is limited by the minimum physical size of transistors used in their chips. Now all these paths of development still retain their relevance, but at one fine moment their potential will be exhausted, and the miners will be forced to look for less obvious , more sophisticated optimization options.
There are some very effective and non-obvious ways. Unfortunately, they are harmful to other users of the system. I would like to focus on ways in which miners can increase profits and reduce costs by withdrawing money from people and systems that rely on the work of blockchains. While you will be reading this material, try not to forget that the miners do not want to take your money, they have to do it. Proof of Work requires them to increase competitiveness.
There are many ways for miners to interfere with the operation of EVM and the applications running in it. Since each miner has the ability to control the blocks that he generates, he can also control the state changes in this block. Let's go over some of the simplest methods, without going too deep into the details. For each of them, we will try to determine the intervention strategy, who will suffer and how the miners can earn money.
Change transaction order
Transactions are processed in blocks. Each block has a canonical order of processing changes in the status of transactions. Miners apply each transaction to the state of EVM in order and determine the root hash of the final state, placed in the block header. The miner generating the block has control over the order of transactions in the blocks. The ability to control the order of transactions in a block actually allows you to control the order of state changes.
Suppose I want to send a friend a payment. I will create a simple contract with three functions:
By changing the order of export contracts, miners can influence the results of the implementation of contracts. This means that they can, within certain limits, monitor the state of EVM. The situation is especially aggravated in large publicly available contracts that govern the interaction between a large number of users. The wider the pool of transactions available to the miner, the more control he has over the final state.
Contract developers should provide for such attempts to arbitrarily change the order of transactions in blocks. Otherwise, miners may provoke payment of additional commissions or cause other unintended harm to application users.
When forming the order of transactions in the block, miners are not limited to the mere possibility of manipulating other people's transactions. They can create their own transactions. They have ETH. And like all of us, they can play with him in blockchain casinos and buy or sell them in blockchain markets. However, the ability to determine the order of processing transactions in some cases may allow them to become first in the processing queue.
Let's come up with another simple smart contract. This time Alice wants to play a guessing game. She puts 5 airs in the contract. This amount is sent to the person who calls the closest to the number. Alice calls
Alice can not cheat because it is stipulated by the contract. But the miner has such an opportunity. He can wait and give his number after he sees the challenge to reveal. He will know the result before the formation of the block! Even if David also calls 4, the miner can change the order, thus beating him.
When an ordinary user creates a transaction, he sends it to miners for inclusion in the block. The user must give an irreversible consent to the transaction before he sees the result of its implementation. Miners, on the contrary, can wait in the process of creating a block and only then decide whether they should include this or that transaction. This means that they have access to more information than ordinary users, as well as the power to change the order of transactions. This gives them a significant advantage in any system operating on the blockchain base.
Whenever users and miners interact on the blockchain through a smart contract, there is a risk that miners will insert transactions and change their order for their own benefit. As a rule, this means that they will receive money that would otherwise have been sent to the pockets of a regular user. Developers of smart contracts should design their systems to reflect this inequality.
Forced mistakes
Miners can use reordering and inserts to interfere with the challenges of smart contracts. Sometimes they can even completely challenge. Let's call such cases compulsory errors. They occur when miners change a state to some unforeseen call, as a result of which it ends with an error. They can do this by inserting a transaction that will affect the state.
Let's create a simple smart contract for the market. I take out
In this situation, the miner can check the incoming
This attack is especially dangerous in older versions of Solidity. Older versions of the keywords
Forced errors allow miners to receive fees for refusing to perform work. In case of completion of a transaction with errors, the state returns to its original state. If the miner finds a reliable way to provoke erroneous calls, he will not even need to handle state changes. A miner’s ideal block is one that is filled with failure by erroneous transactions and payments with a transfer of the commission for processing them, without any other state changes.
Developers of smart contracts can partially prevent this behavior by carefully examining their expressions
Censoring
When deciding on the order of transactions in a block, miners can also selectively ignore certain transactions. They can do this for political or financial reasons. Users generally have no guarantees that the miners will ever include one or another transaction in the block.
Suppose Alice wants to make a piggy bank. She can launch a simple contract that allows her to withdraw money no earlier than after 10 thousand blocks. Alice is a good person and therefore she wants to make sure that in case of her sudden death, the money will be sent at least to someone else. Therefore, it makes sure that the contract allows the miners to take money after 50 thousand blocks.
Each individual miner has a strong motivation not to include its transaction to extract funds in its blocks. They have nothing to lose: if she can never take the money, they can try their luck and get it in the future. In addition, she will be able to withdraw money only if the miners allow her to do it. Even if they do not conspire and ignore its transactions, or carry out a 51% attack, they can all together refuse to take its transaction for processing.
This means that there are no contracts to ensure 100% timely delivery of the transaction! You will have to design applications with unpredictable possible censoring by the miners. And since the contract cannot foresee their desire to intervene, it must allow for possible arbitrary time delays.
The more money goes into the system, the more likely it is that the miners will want to interfere in one way or another with its work. As exchanges grow and casinos become more complex and the value of the blockchain increases, the miners' motivation to intervene grows.
Consensus is not just the level at which our decentralized applications are kept. In fact, they are closely intertwined with the application layer. When we write programs, we do not think about the physical properties of silicon, because we know that it will not actively try to take away our money. Unfortunately, between EVM and silicon there is a layer in the form of miners, and if they cannot be trusted, then EVM cannot be trusted either.
Solidity developers must program a computer that works against them. EVM as such is the “Byzantine system”. Any part of it that is subject to an unfortunate outcome will come to him at the worst moment. Today, we are still at a very early stage of understanding cryptocurrency, mining, and smart contracts. Now miners do not show an active desire to optimize their activities at the expense of users, but this is only for now. Ethereum will grow and someday, we will remember this time as the golden age of decentralized applications.
Miners are not friends and not enemies. They represent a kind of uncontrollable natural elements operating in our consensus systems. Those of them who do not learn to control this element will ultimately fall victim to advanced miners.
- Ethereum.org
We, developers, love to believe in the level of consensus, which imposes the solution of all complex tasks of distributed systems, allowing us to write applications. Miners live at the level of consensus, doing their mining affairs. Developers sit at the application level and write smart contracts - programs that run inside the Ethereum Virtual Machine (EVM). Our decentralized applications interact with the computer, relying on its integrity and security.
We know that EVM works by consensus, and we don’t need to think about this mechanism as long as it works. We do not think about miners, because in the end, there is no need to understand the principle of operation of semiconductors or the design features of modern computer chips. But, alas, this convenient and predictable separation between levels is nothing more than an illusion. The illusion of a level of consensus that helps us forget that miners are not our friends.
In practice, the transition from contracts to consensus is a much less smooth phenomenon, and not as unambiguous as is commonly believed. Creating blocks affects the state of EVM, which in turn affects the challenges of smart contracts and as a result affects the operation of decentralized applications and their users. The slower the blocks, the slower the decentralized applications. The faster the blocks, the faster the application. Empty blocks cause applications to stop working.
From time to time, the level of consensus inadvertently interferes with the work of decentralized applications. But there may be cases in which representatives of this level can intervene deliberately. Manage the level of consensus miners. They work for money, and therefore they will maintain the application level only as long as it brings them profit. If they can earn more money by intervening at the application level, they will eventually do it.
Miner treadmill
Miner you are not friends. But not enemies. They don't want to hurt you, they just can't avoid it. These are the requirements of Proof-of-Work. Miners have to engage in fierce competition for the right to receive a very small margin. They are stuck on the “Miner treadmill”, where the fastest runners set the pace.
Whenever they manage to invent another way to speed up or cheapen the calculation of hashes, the complexity increases. With its growth, each individual hash becomes all significant to me. Your hash rate may remain unchanged, but you gradually start getting less and less. In this respect, Proof-of-Work forces miners to constantly reinvest profits. They make a profit only by constant spending, optimizing and maintaining competitiveness. Those of them who fail to compete go the distance .
If your profitability is 1%, then a 1% decline in income deprives you of profit. If the miner's hash rate becomes a little less than the current norm, it lags behind the rest of his colleagues. On the other hand, a 1% increase in revenue leads to a doubling of profits. Even a small gap in efficiency allows miner to receive much more money for their reinvestment in equipment. And the detachment of such participants is growing more and more, as a result of which less successful competitors with time can no longer oppose anything to them. Proof-of-Work provokes miners to look for small advantages, improve any aspects of the process and use this to throw competitors off the treadmill.
There are two ways to improve the profitability of mining - increasing profitability or reducing costs. Profit consists of awards for approved blocks and commissions for the transactions included in them. Costs arise from the need to pay for electricity, equipment, staff salaries, office rent and similar costs.
Currently, miners are competing with quite obvious major improvements, such as finding lower electricity tariffs or improving equipment. Unfortunately, this approach leads to a further decrease in profits in the future. It is becoming more and more difficult for companies to find cheaper electricity. Mining with the help of graphics cards rests on the limitation of memory bandwidth, and "Asiki", in turn, is limited by the minimum physical size of transistors used in their chips. Now all these paths of development still retain their relevance, but at one fine moment their potential will be exhausted, and the miners will be forced to look for less obvious , more sophisticated optimization options.
There are some very effective and non-obvious ways. Unfortunately, they are harmful to other users of the system. I would like to focus on ways in which miners can increase profits and reduce costs by withdrawing money from people and systems that rely on the work of blockchains. While you will be reading this material, try not to forget that the miners do not want to take your money, they have to do it. Proof of Work requires them to increase competitiveness.
How miners can intervene
There are many ways for miners to interfere with the operation of EVM and the applications running in it. Since each miner has the ability to control the blocks that he generates, he can also control the state changes in this block. Let's go over some of the simplest methods, without going too deep into the details. For each of them, we will try to determine the intervention strategy, who will suffer and how the miners can earn money.
Change transaction order
Transactions are processed in blocks. Each block has a canonical order of processing changes in the status of transactions. Miners apply each transaction to the state of EVM in order and determine the root hash of the final state, placed in the block header. The miner generating the block has control over the order of transactions in the blocks. The ability to control the order of transactions in a block actually allows you to control the order of state changes.
Suppose I want to send a friend a payment. I will create a simple contract with three functions:
deposit , unlock and retrieve . Calling deposit transfers funds to storage. Whenever I want to send him money, I unlock 5 airs. My friend calls the retrieve function, which sends him all funds not blocked by deposit . If the miner sees the unlock and retrieve transactions in one block, he can swap them and the retrieve will be called earlier. Calling retrieve will allow you to receive all free, non-custodial funds. After that unlock will be called. As a result, my friend will be forced to send the retrieve transaction again, re-paying a commission for it.By changing the order of export contracts, miners can influence the results of the implementation of contracts. This means that they can, within certain limits, monitor the state of EVM. The situation is especially aggravated in large publicly available contracts that govern the interaction between a large number of users. The wider the pool of transactions available to the miner, the more control he has over the final state.
Contract developers should provide for such attempts to arbitrarily change the order of transactions in blocks. Otherwise, miners may provoke payment of additional commissions or cause other unintended harm to application users.
Insert transactions
When forming the order of transactions in the block, miners are not limited to the mere possibility of manipulating other people's transactions. They can create their own transactions. They have ETH. And like all of us, they can play with him in blockchain casinos and buy or sell them in blockchain markets. However, the ability to determine the order of processing transactions in some cases may allow them to become first in the processing queue.
Let's come up with another simple smart contract. This time Alice wants to play a guessing game. She puts 5 airs in the contract. This amount is sent to the person who calls the closest to the number. Alice calls
commit with a number hash, thereby guaranteeing its immutability. Anyone can cause a guess and participate in guessing. After 2 blocks, Alice calls reveal , so that everyone knows what number was made up.Alice can not cheat because it is stipulated by the contract. But the miner has such an opportunity. He can wait and give his number after he sees the challenge to reveal. He will know the result before the formation of the block! Even if David also calls 4, the miner can change the order, thus beating him.
When an ordinary user creates a transaction, he sends it to miners for inclusion in the block. The user must give an irreversible consent to the transaction before he sees the result of its implementation. Miners, on the contrary, can wait in the process of creating a block and only then decide whether they should include this or that transaction. This means that they have access to more information than ordinary users, as well as the power to change the order of transactions. This gives them a significant advantage in any system operating on the blockchain base.
Whenever users and miners interact on the blockchain through a smart contract, there is a risk that miners will insert transactions and change their order for their own benefit. As a rule, this means that they will receive money that would otherwise have been sent to the pockets of a regular user. Developers of smart contracts should design their systems to reflect this inequality.
Forced mistakes
Miners can use reordering and inserts to interfere with the challenges of smart contracts. Sometimes they can even completely challenge. Let's call such cases compulsory errors. They occur when miners change a state to some unforeseen call, as a result of which it ends with an error. They can do this by inserting a transaction that will affect the state.
Let's create a simple smart contract for the market. I take out
sell to put up any tokens for sale at a given price. Anyone can call buy to buy some of my tokens.In this situation, the miner can check the incoming
buy call from Bob and consider the option of his purchase of tokens. He can buy just as much as he needs for Bob’s transaction to complete with an error. If Bob wants to buy 2.5 GNT, the miner can achieve a shortage of this amount. Bob's transaction will complete with an error, but the miner will receive a commission for it. Thus, Bob, against his will, will pay for the purchase by the miner of GNT tokens, without receiving anything in return.This attack is especially dangerous in older versions of Solidity. Older versions of the keywords
assert and throw will transfer all the attached gas to the miner, which will result in them receiving very high commissions for the lack of any work. Newer keywords require and revert limit gas usage based on actual work done.Forced errors allow miners to receive fees for refusing to perform work. In case of completion of a transaction with errors, the state returns to its original state. If the miner finds a reliable way to provoke erroneous calls, he will not even need to handle state changes. A miner’s ideal block is one that is filled with failure by erroneous transactions and payments with a transfer of the commission for processing them, without any other state changes.
Developers of smart contracts can partially prevent this behavior by carefully examining their expressions
revert and require . If miners manage to find the right way to drive a contract into an error, they can collect additional commissions from your users. Rule number one in such cases: if the call relies on a state that can be changed by another user, then it is vulnerable to forced errors.Censoring
When deciding on the order of transactions in a block, miners can also selectively ignore certain transactions. They can do this for political or financial reasons. Users generally have no guarantees that the miners will ever include one or another transaction in the block.
Suppose Alice wants to make a piggy bank. She can launch a simple contract that allows her to withdraw money no earlier than after 10 thousand blocks. Alice is a good person and therefore she wants to make sure that in case of her sudden death, the money will be sent at least to someone else. Therefore, it makes sure that the contract allows the miners to take money after 50 thousand blocks.
Each individual miner has a strong motivation not to include its transaction to extract funds in its blocks. They have nothing to lose: if she can never take the money, they can try their luck and get it in the future. In addition, she will be able to withdraw money only if the miners allow her to do it. Even if they do not conspire and ignore its transactions, or carry out a 51% attack, they can all together refuse to take its transaction for processing.
This means that there are no contracts to ensure 100% timely delivery of the transaction! You will have to design applications with unpredictable possible censoring by the miners. And since the contract cannot foresee their desire to intervene, it must allow for possible arbitrary time delays.
Escalation of problems
The more money goes into the system, the more likely it is that the miners will want to interfere in one way or another with its work. As exchanges grow and casinos become more complex and the value of the blockchain increases, the miners' motivation to intervene grows.
Consensus is not just the level at which our decentralized applications are kept. In fact, they are closely intertwined with the application layer. When we write programs, we do not think about the physical properties of silicon, because we know that it will not actively try to take away our money. Unfortunately, between EVM and silicon there is a layer in the form of miners, and if they cannot be trusted, then EVM cannot be trusted either.
Solidity developers must program a computer that works against them. EVM as such is the “Byzantine system”. Any part of it that is subject to an unfortunate outcome will come to him at the worst moment. Today, we are still at a very early stage of understanding cryptocurrency, mining, and smart contracts. Now miners do not show an active desire to optimize their activities at the expense of users, but this is only for now. Ethereum will grow and someday, we will remember this time as the golden age of decentralized applications.
Miners are not friends and not enemies. They represent a kind of uncontrollable natural elements operating in our consensus systems. Those of them who do not learn to control this element will ultimately fall victim to advanced miners.
Source: https://habr.com/ru/post/409735/