1

This question already has an answer here:

In an Ethereum node, my brief understanding regarding transaction flow is below.

When a client initiates a transaction, all mining nodes receives this request. Based on gas price, miner choose to process the request. after processing they keep the transaction in their own tx pool. Once it becomes a block (Block has collection of transactions) ,this block get's added into ledger. Here it is possible that multiple miner accept to process this request and put it in their own tx pool before storing into blockchain and each block can have own set of transaction pool.

My query is, when multiple miners solve the puzzle and keep the transaction in their own pool and when each one has their block ready , how Ethereum consensus decide which one to accept. If it is on First Come First Serve Basis then what happens to other blocks, whole block gets rejected or only transaction which was already processed gets rejected.

Question may not be well phrased but hope you got my question. Looking for answer.

marked as duplicate by Ismael, shane, Briomkez, Achala Dissanayake, flygoing Dec 18 '18 at 14:12

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

3

It's different.

From reading your question, I got the impression that you're thinking about this from the perspective of a cluster of computers that know and trust each other. There is some misuse of terms that may make it difficult for you to interpret documentation and explanations. If I may, I'll try to sort a few things out without getting too technical about the details.

First thing is Ethereum is designed for a hostile environment in which up to 49.9% of the nodes may be not merely non-functional (crashed), but overtly hostile and deliberately sewing confusion in the network. It is not optimized for performance. The focus is on resilience.

The txpool is subjective from every perspective. It can be understood as the transactions a node (miner, if they want to be) is aware of that haven't been mined into a block. Transactions propagate through gossip, so eventually all nodes will be aware of all proposed transactions. In practice, this is never the case because of network latency. This is why the list is subjective from the perspective of every node.

Transactions that are malformed will not be propagated, otherwise that would be a denial of service attack vector. Transactions don't need to have any chance of success to propagate, for example, attempting to double-spend. The system imposes a financial cost to such exploits in the form of transaction fees (gas) that will be burned in the case of failed transaction. i.e. It is expensive to flood the network with useless transactions.

Another concern is the order of the transactions. Every (full) node processes transactions and forms its own conclusion about the network state. In this context, "state" means balances and data stored in contracts. But, in order to reach consensus about state, the nodes first need to reach consensus about the transaction order. This important function is addressed by miners and the mining process.

Miners have latitude about which transactions to include in a block. There are all sorts of economic considerations. Generally, the gas price is the sender's bid for priority. While it isn't the only consideration, miners are more likely to include transactions with a high gas price, especially during periods of network congestion.

Which miner should perform the task?

In the case of a network where all the participants know and trust each other, something like a round-robin or fault-tolerant scheme would work. This is common in the world of private blockchains. A public blockchain needs another solution. Consider that reordering transactions can have non-trivial financial consequences. All sorts of angles are possible, so a public blockchain needs another solution to prevent a selfish miner from gaining outsized influence over network happenings.

This is where Proof-of-Work comes in. The puzzle (lottery) proves that considerable work went into "searching" for a magic number that will make the transaction block (an ordered set of transactions) work according to the network rules including difficulty.

When a successful miner "finds" a block (with a magic number, the nonce) they broadcast to the network. Other nodes will recognize the validity of the "solution" and accept the block of transactions as a de facto agreed transaction order. That makes it possible for each node to process the transactions in the same order as everyone else and reach the same conclusions about the impact of the transactions. In other words, everyone agrees on the results because everyone agrees on the inputs.

It is common for multiple miners to "find" a block more or less at the same time and without knowledge that another miner also found a block due to network latency. In that case there are two possible interpretations and after some gossip, everyone will know. In that case, the "heaviest" fork wins. The other equally valid block gets some reward and still helps secure the consensus as an "ommer" a.k.a. "uncle". Those are the keywords if you want to dig deeper into mining.

In the end, the blockchain is a well-ordered series of blocks and each block is a well-ordered series of transactions. The transaction pool is a queue-like construct that is different on every node.

Hope it helps.

  • 2
    I think you mean "ommer." – smarx Dec 14 '18 at 8:23
  • Miners maintain a transaction pool (Lsit of transactions executed by them) before forming a block and adding it into blockchain. Each miner can maintains their own pool. Say MinerX picsk and solve transactoin A, B , C and form a block B1 and MinerY solve A, D, E and for a block B2. Here since both B1 and B2 has transaction A in common, which Block get's added into blockchain. Let's say B1 got added then entire B2 block will get rejected ? if yes then what about transaction D and E. – SHAAN Dec 14 '18 at 8:57
  • It doesnt matter what previous work was done. The miner needs to decide which block it is building on and go forward from there. Eventually the network will decide whick chain of blocks is the canonical chain. In your scenario, D and E are not in it yet. Someone will add them to block on top of B1. – Rob Hitchens - B9lab Dec 14 '18 at 15:39
  • For completeness, someone else might decide to keep banging on B2. In that case, B and C are candidates. So you can and do have multple heads moving forward. Each version of history tells a different story about the order of events. Eventually, the network settles on the longest chain probalistically. No one is compelled to, but everyone knows everyone else probably will. – Rob Hitchens - B9lab Dec 14 '18 at 15:46

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