Partnered With:

How to understand the 51% attack in the blockchain?

Read this article in 16 Minutes

Everyone has a misconception about 51% attacks

Original Title: "Everyone Misunderstands 51% Attacks"

Original Author: Dankrad Feist

Original Compilation: Block unicorn

There is a saying that if you control more than 50% of the computing power in Bitcoin, Ethereum or other blockchains, then You can do anything you want on the Internet. A similar reiteration of Proof of Stake is that if you control more than two-thirds of your stake, you can do anything. You can take other people's coins. You can print new coins, it's not true.

Let's discuss what a 51% attack can do:

< br>

- They can block you from using the chain, i.e. block any transactions they don't like. This is called censorship.

- they can restore the chain, i.e. revoke a certain number of blocks and change the order of transactions in them .

What they cannot do is change the rules of the system. This means for example:

- outside the rules of the blockchain system, they cannot simply New tokens can be printed freely; for example, Bitcoin currently gives each new block producer 6.25 BTC; they cannot simply turn that into 1 million BTC.

- They cannot spend tokens from addresses that do not have a private key.

- They cannot make bigger blocks than the consensus rules allow.

This is not to say that 51% attacks are not damaging. They're still pretty bad attacks. Reordering allows double-spending coins, which is quite a problem. But there are limits to what they can do.

Now, how do most blockchains including Bitcoin and Ethereum ensure this a little? What happens if a miner mines a block that violates the rules? Or a majority stake signed a block that violated the rules?

Blockchain Security Model

Sometimes people claim that the longest chain is the valid Bitcoin or Ethereum chain. This is a bit incomplete. The correct definition of the current chain head is:

The valid chain with the highest total difficulty.

Accepting should therefore use a chain to represent the current history Previously, the client needed to validate two properties:

1. It must be valid. This means that all state transitions are valid; e.g. in Bitcoin, this means that all transactions only spend previously unspent transaction outputs, coinbase only receives transaction fees and block rewards, etc.

2. It must be the most difficult chain. In layman's terms, this is the longest chain, but it is not measured by blocks, but by the total mining power spent on this chain.

This may sound a bit abstract. Is it reasonable to ask who will verify the first condition, that all blocks on the chain should be valid? Because if it's just that the miners also verified that the chain is valid, then it's a tautology and we don't really get anything.

But blockchain is different, let's see why, from normal client/server Database schema start:

< br>

Note that with a typical database, the user trusts the database server. They don't check that the response is correct; the client makes sure it's formatted validly according to the protocol, that's all. The client (represented here by an empty square) is "dumb": it cannot verify anything.

However, the blockchain architecture looks like this:< br>

So let's summarize what's going on here matter. Miners (or stakers) with production chains. There is a peer-to-peer network - what it does is ensure that a valid chain is always available to everyone, even if some nodes are dishonest (you need to be connected to at least one honest and well-connected P2P node to ensure that you will always be connected to Valid chains are kept in sync). There is also a client that sends transactions to the P2P network and receives the latest chain update (or full chain, if they are syncing) from other nodes in the network. They are actually part of the network and will also contribute by forwarding blocks and transactions, but that's not important here.

The important part is that the user is running a full node like a cylinder in their client as indicated. Whenever a client gets a new block, just like any other node, be it a miner or a node in a P2P network, they verify that the block is a valid state transition.

If it is not a valid state transition, the block will be ignored. This is why it makes little sense for miners to try to mine invalid state transitions in the network. Everyone just ignores it.

Many users run their own nodes to interact with blockchains like Ethereum or Bitcoin. Many communities have made this part of their culture and place a high value on everyone running their own node, so they are part of the validation process.

In fact, you could argue that most users, especially those with a lot of value, running full nodes really matter; if most users become Too lazy, and miners may suddenly be tempted to produce invalid blocks, and this pattern will no longer hold.

Analog: Separation of Powers

You can think of this a bit like the separation of powers in a liberal democracy - there are different branches of government, and just because you have a majority in one of them (like legislation) doesn't mean you can do whatever you want Things like and disregard all laws. Miners or stakeholders have the power to order transactions in the blockchain; they do not have the power to simply dictate new rules to the community.

But do all blockchains work this way? That's a good question. Note that this only works if a full node is easy to run. As a regular user, if that means having to spend $5,000 on another computer and permanently needing a 1 GBit/s internet connection, then you're not doing it at all.

Even if you could get such a connection somewhere, it might not be very convenient to have it permanently blocked by your blockchain node. In this case, you probably won't be running your own node (unless your transactions are extremely valuable), which means you'll be trusting someone else to do it for you.

Imagine a chain so expensive to run that only stakers and transactions All you need to run a full node. You just changed the trust model and most stakers and exchanges can band together to change the rules. There is no debate with users about this - if users don't control the chain at all, they can't lead a fork. They can stick to the old rules, but unless they start running full nodes, they don't know if their requests will be answered with a chain that satisfies the rules they want.

This is why there is always an argument around increasing the block size (e.g. Ethereum or Bitcoin) Arguing - every time you do this, you increase the burden on the people who run their own nodes. For miners, this isn't a big deal -- the cost of running a node is small compared to the actual mining operation -- so it shifts the balance of power from users to miners (or stakers).

What about light clients?

Okay, but what if you just want to pay for your coffee with cryptocurrency? Are you going to run a full node on your phone?

Of course, no one expected this. And users don't. Here, light clients come into play. Light clients are simpler clients that don't validate the entire chain - they only validate the consensus, which is either the total difficulty or the number of shares voting for it.

In other words, light clients can be tricked into following a chain that contains invalid blocks. There are remedies for this, including data availability checks and fraud proofs. As far as I know, no chain currently implements these, but at least Ethereum will do so in the future.

So using a light client with data availability checks and fraud proof we will be able to Provides a blockchain security model without requiring all users to run full nodes. This is the ultimate goal, any mobile phone can easily run the Ethereum light client.

What about sidechains?

Sidechains are a hot topic right now. It looks like they are a simple way to provide scaling without the complexity of aggregation, simply:

- Create a new proof-of-stake chain.

- Build a two-way bridge with Ethereum.

- Profit! Note that the security of sidechains relies almost entirely on bridges — structures that allow one chain to know the state of another. After all, if you can trick the bridge on the main chain that all assets on the bridge chain now belong to Mr. Evil, it doesn't matter if the full nodes on the proof-of-stake chain think differently, so everything is on the bridge.

Unfortunately, the state of the bridge is the same as the light client. They do not verify correctness, but only a large part of the consensus conditions. However, two things are worse than light clients:

1. Bridges are used for very high-value transactions, and most users will choose full nodes if they can.

2. Unfortunately, there is no way like we do for light clients Bridges are strengthened that way - because they cannot validate data availability checks.

The second point is very subtle, could easily fill another or two blog posts. But in short, bridges cannot do data availability checks, without which fraud proofs are mostly useless. With zero-knowledge proofs, you gain an improvement by requiring bridges to include proofs that all blocks are correct - unfortunately this is still subject to some data availability attacks, but it's an improvement.

In summary, sidechains have different, weaker much more secure model. They cannot prevent invalid state transitions.

Is this all about sharding?

In fact, all of these have a lot to do with sharding. The reason we need sharding to scale is because it is the only way to scale without raising the bar for running a full node, while maintaining the full security guarantees of the blockchain as much as possible.

But what if you just undo all history? Then you can still steal all your bitcoins/ether/etc. From a theoretical point of view, on a non-checkpoint proof-of-work chain, it is true that by not reverting some transactions, but reverting all transactions, you still get all the bitcoins. Ok, so you can't print a trillion bitcoins, but you still get all the bitcoins that exist, so that's fine, right?

I think this is very theoretical. The probability that any of these communities will accept a fork that modifies its history for years (or even hours) is exactly zero. There will be plenty of bickering on all possible channels and it will quickly be concluded that people should reject this and agree that the valid chain should be the one that already exists.

Through Proof of Stake and Finalization, this mechanism will become formal - clients never The finalized block will be restored.