What is the impact of underestimating weights? In what way could an adversary make use of this?

3 Answers 3


Basically the same as what happened in Ethereum's Shanghai Attacks. An "attacker" would submit a lot of transactions with the underestimated weights. They would effectively underpay the network for its work and the network would find it had more work to do than the time allowed. However, there's really no material difference here between attacking the network and using the network. The only difference is one of intention.

For Relay chains like Polkadot, this is problematic in that it slows down block production and disenfranchises users transacting with accurate weights. Taken to the extreme, you'll end up with a degenerate network where blocks take many times as long to create as the nominal block period.

For parachains this is far worse: parachains work within a much more stringent timing requirements, needing to prepare, author, submit and have verified their blocks in a limited period. The consequence of substantial underestimation of weights could result in the chain stalling completely. (Asynchronous Backing, a major parachain optimization feature will likely help with this, but won't alleviate it completely.)


Great question!

You don't really need an adversary as even normal chain usage can cause problems in such a scenario.
The speed of block finalization in Substrate relies on the assumption that each block takes a known-in-advance time to execute, defined by its weight.
Lets assume the following scenario:
The weights of Balances::transfer is too low for whatever reason.

Substrate now receives a block with many transfers.
It assumes to be able to execute it in 2 seconds, since weights indicate that.
Now since the weights are too low, it takes longer than 2s.
This makes it impossible to meet the target time to finish the finalization and stalls any further operation.
An "adversary" could now exploit that by sending many transfers to stall the chain further.

I am not sure what the consequences of that would be;
in the best case the tx-pool would just fill up and you would need to wait longer for your Extrinsic fo finalize.


They can flood your chain with spam transactions and worse they can bloat your state. If your state is very large then it is more time consuming to sync and costly to store. Ideally state growth should stay under the growth of the underlying storage of SSD sizes otherwise things get expensive and you can't use readily available consumer hardware.

So best to err on the side of caution and be conservative. You can always reduce the weights later.

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.