Lesson 5: TransactionError: Tx dropped

[semsion]

After running 2 x deploy.py scripts in quick succession from Brownie, I had the following error / failed transaction:

$ ➜  brownie_simple_storage brownie run scripts/deploy.py --network rinkeby
Brownie v1.17.0 - Python development framework for Ethereum
BrownieSimpleStorageProject is the active project.


Running 'scripts/deploy.py::main'...
Transaction sent: 0xc93ae35cae3e386600acdbd4a750afea25ba6001cee5c4cc6f359d318c1f1905
  Gas price: 1.000000008 gwei   Gas limit: 368944   Nonce: 34
  File "brownie/_cli/run.py", line 50, in main
    return_value, frame = run(
  File "brownie/project/scripts.py", line 103, in run
    return_value = f_locals[method_name](*args, **kwargs)
  File "./scripts/deploy.py", line 20, in main
    deploy_simple_storage()
  File "./scripts/deploy.py", line 5, in deploy_simple_storage
    simple_storage = SimpleStorage.deploy({"from": account})
  File "brownie/network/contract.py", line 521, in __call__
    return tx["from"].deploy(
  File "brownie/network/account.py", line 508, in deploy
    receipt, exc = self._make_transaction(
  File "brownie/network/account.py", line 758, in _make_transaction
    receipt = self._await_confirmation(receipt, required_confs, gas_strategy, gas_iter)
  File "brownie/network/account.py", line 800, in _await_confirmation
    raise TransactionError(f"Tx dropped without known replacement: {receipt.txid}")
TransactionError: Tx dropped without known replacement: 0xc93ae35cae3e386600acdbd4a750afea25ba6001cee5c4cc6f359d318c1f1905

It looks like the transaction went through, but also got dropped.

I got charged but the full contract deployment didn’t go through.

If I wanted to get this to ‘fully mine’ it sounds like it is possible by sending the transaction again, using the same nonce but with a higher gas price. Discussed here https://community.infura.io/t/transaction-dropped/863/2 - this may just have happened because I sent two deployments in quick succession.

It seems like if you wait a minute or two, or more, between sending transactions to the (test) blockchain, deployments appear to go through OK.

I'm wondering if this could be a mechanism to help stop DOS attacks and the like.

My concern is losing transaction fees over such occurrences on the mainnet.

Has anyone else noticed anything like this?

[cromewar]

You are 100% right and you can loose money as you would have to pay the gas anyway, for mainnet deployment you also would have to add more block confirmations on the blockchain (remember tx.wait(1)) and of course it will cost even more gas. But, let's take something in consideration:

1. You are deploying the exact same contract, so it will have the exact same hash code which is unlikely to happen on mainnet, the goal would be deploy the contract just once (as you will have ran a lot of test on development before) and let the users to interact with it. So on a production environment you wouldn't deploy the same contract over and over again, which reduces the risks to drop your transactions. If you want to make changes you might upgrade the contract (as you'll see on lesson 12) or deploy a complete new one.
2. Regarding DOS attacks, well it depends... If your contract is 100% on-chain it would be almost impossible as there is not a single point of failure, but of course if your contract depends on a web page to interact with it (as you'll see on lesson 13) of course you could have a DOS attack.

This is an interesting topic to discuss, I would like to have more opinions from the community.

[semsion]

Yes it sounds possible that less contracts over a short period of time will be deployed on a mainnet.

What I actually meant in regard to a denial of service, was a DDOS attack, which after some investigation appears to be something the Ethereum blockchain can be susceptible to. It least it has been a couple of times in the past decade or so.
In this context I was hypothesising that maybe rapid successive deployments from the same address could be possibly flagged as malicious from a node / group of nodes.

[cromewar]

I did research on this and your are right Ethereum blockchain might be vulnerable to this, the attacker should pay anyway the gas fee, no? another interesting attacks were discussed on a recent streamer on chainlink channel here: https://www.youtube.com/watch?v=nrnC2Z-ZZow