0

Whenever a new transaction is made, it is added to the mempool and a miner will take these transactions from the pool and try to generate a block which contains this transaction.

However, before making the transaction, we need to make sure that the sender has enough balance to broadcast the transaction which is calculated from iterating through the blockchain.

The problem arises when a transaction is made by the sender (who had previously made an unconfirmed transaction and which is sent to the miner) and the mining process is still happening since we cannot calculate the sender's balance as the previous transaction is still being mined and the balance needs to be confirmed by the blockchain. Technically, we can still calculate the balance but the balance calculated will be incorrect and outdated.

So, how does Ethereum calculate the balance before making a transaction?

1

It's like writing a check (cheque).

This may be hard to accept, but the mempool is irrelevant. Nothing in the mempool has actually happened, nor is there any guarantee that those transactions will be mined or work as expected. Conditional logic means there is no general-purpose way of knowing, in every case, exactly what will happen until there is context and transactions actually run in that context - What was the state when the transaction was executed? What does the contract say? That's the only way to arrive at a dependable answer.

A conscientious sender may indeed take their mempool transactions into account (they are the only party who reliably knows what those are). It's analogous to accounting for your unprocessed cheques and conducting yourself in a way that avoids overdrawing your account when everything finally clears. Seen from this perspective, it is a client-side concern, if implemented at all.

No one can say, with certainty, what anyone's account balances will be without running pending transactions, in context, because conditional logic and contracts may result in funds and assets moving in ways that can only be understood by running contracts. A transaction that appears to send a little money may result in receiving much more. The process that disambiguates the "what will happen" question is mining. It establishes what did happen and the order of events.

The protocol itself doesn't depend on the client being conscientious or accurate in its estimate of what will happen or what is safe to promise in the future. In other words, there is nothing in the checkbook itself that prevents the issuance of a bad cheque. For clarity, a wallet is free to do some off-chain accounting and stand up some guards to help out from a user perspective, but it isn't protocol.

Receivers don't depend on items in the mempool - at least, they shouldn't do that for non-trivial amounts. The important thing is what did happen. Cautious receivers wait for multiple confirmations, ever-mindful of possible chain reorganization near the head.

So, I think the uncashed checks (cheque) analogy is reasonable. There can be many of those floating about. Although the majority are them are honest, they are a class apart from money in the bank.

Hope it helps.

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.