Miners Aren’t Your Friends

Miners and Consensus: Part 1 of 2

The Consensus Layer Illusion

Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference.

— Ethereum.org

As developers, we like to believe in a consensus layer that takes care of all the hard distributed systems problems and lets us write applications. Miners live in the consensus layer, doing whatever it is miners do. Developers live in the application layer with the smart contracts: elegant programs that run perfectly forever on the Ethereum Virtual Machine (EVM). Our dApps interact with an eternal ethereal computer and rely on its integrity.

We know the EVM is powered by consensus, but we don’t need to care about that as long as it works. We don’t worry about miners. After all, nobody needs to understand how semiconductors work, or the circuit design of a modern CPU. Unfortunately, this nice, smooth division between layers is an illusion. The consensus layer illusion helps us forget that miners aren’t our friends.

In practice, however, the boundary between contracts and consensus has more bumps, folds, and blurs than the marketing indicates. Block production affects the state of the EVM, which affects calls to smart contracts. In turn this affects the dApps making those calls and the dApps’ users. If blocks are slow, dApps are slow. If blocks are fast, dApps are fast. If blocks are empty, dapps are frozen.

The consensus layer accidentally interferes with dApps all the time. But sometimes it can reach up and interfere deliberately. The consensus layer is controlled by miners. Miners work for money. The consensus layer will only support the application layer as long as it’s profitable to do so. If miners can make more money by interfering with the application layer, they will eventually do it.

The Mining Treadmill

Miners aren’t your friend. But they aren’t your enemy either. They don’t want to hurt you, they simply can’t avoid it. It’s in their nature. It’s required. Proof of Work demands it. Miners must compete viciously to get very slim margins. They’re stuck on the mining treadmill, and the fastest runners control the speed.

Every time miners figure out how to hash faster or cheaper, the difficulty increases. When difficulty increases, each hash becomes less valuable. Your hashrate may stay the same, but you get paid less and less. In this way, Proof of Work forces miners to constantly re-invest revenue. Miners only profit through constant spending, constant optimization, constant competition. Miners that can’t compete fall off the treadmill.

If your profit margin is 1%, then a 1% decrease in revenue eliminates your profits. If a miner’s hashrate falls behind even a little bit, they fall behind the pack. If they’re not careful they’ll end up falling off the treadmill as it speeds up. On the other hand, a 1% increase in revenue would double profits. A slightly more efficient miner will have much more money to reinvest in more hardware. They’ll gain a bigger and bigger edge until other miners just can’t compete. Proof of Work forces miners to find those small advantages and use them to push other miners off the treadmill.

There are two ways to increase mining profitability: generate more revenue, or reduce expenses. Revenues comes from block rewards and transaction fees. Expenses come from electricity, hardware, employees, offices, etc.

Right now, miners compete via gross optimizations: obvious, valuable things like cheaper electricity or better hardware. Unfortunately, these have diminishing returns — it becomes harder and harder to find cheaper power, GPUs approach limits on memory bandwidth, and ASICs approach physical limits on transistor size. Right now, these are still the most profitable optimizations. But at some point, the big optimizations are going to run out, and miners are going to be forced to look for finer, less obvious optimizations.

There are some very effective fine optimizations. Unfortunately, they hurt you. I’d like to focus on the ways miners can increase revenue and decrease expenses by taking money from the people and systems that rely on blockchains. And while you read this try to keep in mind that miners don’t want to take your money; they have to take your money. Proof of Work demands that they compete.

How Miners Can Interfere

There are many ways miners can interfere with the EVM and the applications running on it. Because each miner controls the blocks they generate, they can also exercise control over the state changes in that block. Let’s run through a few of the easiest methods at a high level. For each of these, we’ll try to identify the interference strategy, who gets hurt, and how the miner makes money.

Transaction Reordering

Transactions are processed in blocks. Each block has a canonical order in which transactions’ state changes are processed. Miners apply each transaction to the EVM state in order, and calculate the root of the final state to place in the block header. The miner that produces the block controls the order of transactions in blocks. Essentially, miners, by controlling the order of transactions in a block, also control the order of state changes.

Say I want to send payments to a friend. I’ll make a simple contract with three functions: deposit, unlock, and retrieve . Calling deposit locks funds away. I unlock 5 Ether whenever I want to send him money. My friend calls retrieve which sends him all unlocked funds. If a miner sees an unlock and a retrieve transaction in the same block, they can reorder them so that retrieve is processed first. The call to retrieve will retrieve any unlocked funds. Then the call to unlock will process. My friend will be forced to submit a second retrieve transaction, and will pay a second transaction fee.

By reordering calls to contracts, miners can affect the results of contract execution. This means they can, to a limited extent, control the state of the EVM. This gets especially bad in large public-facing contracts managing interactions between many users. The more transactions a miner has access to, the more control the miner has over the end state.

Contract developers must plan for arbitrary reordering of transactions in blocks, or risk exposing their users to extra fees or other unintended harm.

Transaction Insertion

When transactions are being ordered in a block, miners aren’t limited to transactions other people have made. They can make transactions of their own. Miners hold Ether. They can gamble in on-chain casinos and buy or sell in on-chain markets, just like the rest of us. But because miners decide what order transactions are processed in, sometimes they get to cut to the head of the line.

Again, let’s design a simple smart contract. This time Alice wants to play a guessing game. Alice puts 5 Ether in her contract. That ETH goes to the person that guesses closest to the number she’s thinking of. Alice calls commit with the hash of the number, so she can’t change her mind. Anyone else can call guess to submit a guess. After 2 blocks Alice calls reveal to tell everyone what the number is.

With this simple guessing game, Alice is prevented from cheating by the commitment. But the miner can cheat easily. The miner can wait to make a guess until he sees Alice’s reveal call. He gets to see the result before the block is made! Even if David guesses 4 as well, the miner can reorder David right out of the win.

When a normal user makes a transaction, they send it off to miners for inclusion in a block. Users must commit to making that transaction before knowing for sure what the outcome of it will be. Miners, on the other hand, can wait until they’re building a block before deciding whether or not to make a transaction. This means that miners have access to more information than regular users, in addition to the power to reorder transactions. This gives miners a strong advantage in any on-chain system.

Any time users and miners interact on-chain via a smart contract, there’s a risk that miners will insert and reorder transactions to their benefit. This usually involves taking money that would otherwise have gone to a regular user. Smart contract developers should design their systems with this kind of user inequality in mind.

Forced Errors

Miners can use transaction reordering and insertion to interfere with smart contract calls. Sometimes, they can even cause the calls to fail entirely. We call these forced errors. Forced errors happen when miners can cause a call to error out by modifying the state to something the call does not expect. They do this by inserting transactions that affect that state.

Let’s build a simple contract for a marketplace. I’ll call sell to list some tokens for sale at a set price. Anyone can call buy to buy some of my tokens.

The miner here, can inspect Bob’s incoming buy call, and decide whether or not he’d like to also buy that token. If he does, he can buy just enough to make Bob’s transaction error. If Bob goes to buy 2.5 GNT, the miner can make sure there’s not enough left. Bob’s transaction will error, and the miner will keep the transaction fee. Bob unwillingly subsidized the miner’s purchase of GNT, and ends up with nothing to show for it.

This attack is particularly bad with older versions of Solidity. The older assert and throw keywords would give all attached gas to the miner, which would lead to very high fees for doing no work. The newer require and revertkeywords limit gas usage to the actual work done.

Forced errors allow miners to get a fee for refusing to perform work. When a transaction errors, the state is reverted. If a miner can reliably make calls error, they don’t even have to process the state changes. For a miner, the ideal block is completely full of errored transactions. Full of fee payments and no other state changes.

Smart contract developers can mitigate this by examining their revert and require statements carefully. If miners can cause your contract to error reliably, they can take extra fees from your users. As a rule of thumb, if a call relies on state that can be changed by another user, it’s vulnerable to forced errors.

Censorship

When deciding how to order transactions in a block miners can also choose to ignore transactions. They might do this for political or financial reasons. Users have no guarantees that miners will ever include a given transaction in a block.

Say Alice wants to make herself a piggy bank. She might set up a simple contract that lets her withdraw funds after 10,000 blocks. Alice is a nice person, and wants to make sure that the money will go to someone if she dies. So she lets miners take her money after 50,000 blocks.

Each individual miner has a strong incentive to not include Alice’s retrieval transaction. After all, if she never withdraws, then they have a shot at the money in the future. And she can’t withdraw unless the miners let her. Even without miners colluding to censor Alice or any sort of 51% attack they might all decide to censor this transaction.

This means that no contract can assume that users transactions arrive in a timely manner or at all! You have to design with unpredictable miner censorship in mind. A contract can’t tell when miners want to censor a transaction, so it has to be prepared for arbitrary delays.

Escalating problems

The more money in a system, the more likely it is that miners will mess with it. As we build bigger exchanges, more complex casinos, and add more and more value to the chain, miners have greater incentives to interfere.

Consensus isn’t a layer underneath our dApps- the two are deeply intertwined. When we write software, we don’t care about the physical properties of silicon — because silicon doesn’t actively try to take our money. Unfortunately, the EVM doesn’t run directly on silicon, it runs through miners — and if miners can’t be trusted, then the EVM can’t be trusted.

Solidity developers must program a computer that’s working against them. The EVM itself is a Byzantine system. Any part of it that can fail will do so, at the worst possible moment. We’re still very early in our understanding of cryptocurrency, mining, and smart contracts. Miners aren’t actively looking to optimize at the expense of users — yet. But as Ethereum grows, we’ll someday remember this as the golden age of dApps.

Miners aren’t your friends or enemies — they’re a force of nature in our consensus systems. Systems that fail to plan around this will eventually lose out to clever miners.

Special thanks to our editors for lending their expertise to this piece including: Matt Luongo, Antonio Salazar Cardozo, Lex Sheehan, Joe Urgo, Luis Cuende, Brayton Williams, Kyle Samani, Linda Xie, and Joey Krug

Learn More

For more information about the Keep Network:

• Join us on Reddit.
• Check out our whitepaper.
• Read our business primer.
• Subscribe for email updates.
• Follow us on Twitter.
• Join our Slack.
• Join our Telegram