3

What are the reasons transactions can fail and by this I mean all different types of transactions, i.e. payments EOA to EOA, contract function calls (from EOA or from other contracts) or other types that might be.

I know that nodes (depending on implementation) perform some validations before forwarding transactions but I am not sure about the scope of these. Also what happens to transactions when a function throws, a modifier is not met or an assert fails?

Improve this question

2 Answers 2

Reset to default
1

The transaction can be of two types

  1. Transactions that are used for just transferring funds from one EOA to another.
  2. Transactions that carry a payload of data along with an amount of ether.

The most usual case when the first case fails is when the transaction goes out of gas. i.e., When the gas limit set is lower than the network fee at that point in time.

For transactions that carry data with it, There are a couple of ways it could fail.

  1. If the transaction invokes a method in the smart contract and an error occurs in one of the lines or if a requirement throws or assertion fails, The transaction fails.

  2. A transaction that deploys a contract could fail if there are any errors that come up while executing the lines in the constructor.

  3. A transaction which transfers ether from a contract to another EOA could fail if the contract doesn't have enough ether to transfer or if the gas supplied to execute the method which contains the transfer is insufficient.

If the transaction from one EOA to another fails, then that is pretty straightforward that its gas. In case the failed transaction involves a smart contract, then we need to debug the contract.

Improve this answer
3
  • I am interested more specifically in what happens with the transaction once it fails, especially for external calls to contrats.
    – rosul
    Commented Nov 28, 2017 at 8:01
  • Lets say I emitted a function call/message transaction to the network and lets say that the call will throw; after a while most of the network knows about it, it becomes part of the pending tx pool and soon miner A mines it. But when A was executing the bytecode the call throws and the state is reversed. How does the network know that the transaction was processed so that it doesnt get stuck in the the pend tx pool and the other nodes dont process it again and again? Is it just that the transaction will only transfer the gas cost to the miner and thats it?
    – rosul
    Commented Nov 28, 2017 at 8:12
  • The bytecode is only processed once. When miner A executes the code and mines the transaction, subsequent miners verify and signs the transaction rather than executing again and again. Also, the transaction can end up with revert or assert. Revert uses gas until the error occurs and returns the remaining gas. Assert consumes the remaining gas.
    – Kannan Ravindran
    Commented May 20, 2018 at 17:22
0

When a call fails, all state changes are reverted to before the transaction and the gas is burned.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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