1

Since nodes in Ethereum are decentralized and distributed, how does the system ensure consistency regarding the state of the blockchain.

I am aware that a validator, once they find the answer to the POW, mints a block and broadcasts it. Other nodes then verify and accept.

But in a distributed network, what is causing multiple similar broadcast happening at different edges of the network, such that different nodes receives different things?

Also i can imagine it takes a while for a broadcast to spread across the network, in between that time, what is stopping a node who has not received the updated state to process another operation that could leave it in an inconsistent state?

1

As you describe, there are minor consensus failures all the time and they change the "tip of the chain." Minor blockchain reorganisations happen: Some blocks disappear, new one appear with the same transactions.

This is handled by the Ethereum clients choosing the heaviest chain (as opposed to the longest chain in Bitcoin). If your node goes against this rule it will be eventually kicked out form the P2P network as a spammer.

1

The short answer is they're not synchronizing the state. They're synchronizing transactions.

The Ethereum Virtual Machine is modelled as a state machine. A state machine has one definite state and one or more state transition processes. That is to say that given an initial state and something that happened, the new state is created because it's the only correct interpretation of what happened.

Since signed transactions are always deterministic protocol transactions such as mining a block or transferring funds, or data sent to contracts which are themselves deterministic, every transaction result is deterministic.

The result of mining is a block. A block is a well-ordered set of transactions. The chain of blocks is, therefore, a well-ordered set of all transactions that have ever occurred. Given this, it is possible for each node to correctly compute the state for themselves.

The process is similar to a transaction log that can be used to reconstruct the state of a database. In summary, they don't try to sync the state. They simply reach consensus about the transactions.

Nodes can and do fall behind, and new nodes need to catch up. There is even some churn at the head of the chain. Eventually, nodes reach a consistent state at the same block height because it's the only way it can be.

Hope it helps.

6
  • > Nodes can and do fall behind, and new nodes need to catch up How does this system ensures that nodes that need to catch up do not diverge based on the fact they got different state transition messages late? Sep 12 at 9:35
  • They reach consensus about the blocks at a given height because they "hear" about the block. The block exists and if it's valid, then it must be accepted. Consensus about the transactions at a given block height equates to agreement about what the state must be. The heaviest chain rule helps them decide which chain to follow when they know of two candidate blocks at the same block height. This leads to eventual consensus with all other nodes heading the same way. Generally, they go the same way because they know the majority will also go that way. Sep 12 at 18:01
  • Nodes are not "forced" to go a certain way, by design. Ethereum Classic is a forked chain. Nodes decided to reject an upgrade. They deliberately ignored the "heaviest chain" and went their own. They cannot get back into consensus with main chain. Thus, ETC is a separate chain with a shared history prior to the split. Sep 12 at 18:03
  • Generally, people wait for "confirmations" which is just blocks stacking up on top of the block that contains a transaction that one wants to "confirm." With each new block, the probability of reorganization is exponentially smaller. At a point, it's vanishingly small. say ... 10 blocks. Sep 12 at 18:05
  • Two nodes will reach agreement about the state at a certain block height. They won't reach that conclusion at exactly the same time. It's not like a redundant database with each server synchronizing a state. When your node hears about block 12345 it will agree with my node at block 12345. One or both of us might be behind the chain. Each block is like a checkpoint and our checkpoints agree. Sep 12 at 18:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.