You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
NOTE: This is specific to the Polkadot/Demo implementations, NOT Substrate.
The native runtime should be able to just the validity of including an extrinsic upon only the information in the extrinsic and basic balance/index information of the sender account. This makes the implementation of the tx queue more straightforward and efficient and also helps make clear arguments against DoS vectors.
Basically, the only conditions upon which apply_extrinsic may panic are:
the free balance of the sender account is less than cost_xt_basic + cost_xt_byte * xt.encode().len(); or
the index of the sender account is not equal to xt.index.
If these "panic" conditions are not met then apply_extrinsic must never panic. To panic thereafter would cause a DoS vector for the miner at best, and will cause the miner to create invalid blocks at worst.
Directly it is determined that apply_extrinsic will not panic, the balance should be reduced by the fee and the sender index incremented. Any further "higher-level" criteria that are not met (and would thus cause a panic in the current code) should be reworked to ensure they return instead without changing any storage items (except, of course, the balance reduction and index increment).
The text was updated successfully, but these errors were encountered:
NOTE: This is specific to the Polkadot/Demo implementations, NOT Substrate.
The native runtime should be able to just the validity of including an extrinsic upon only the information in the extrinsic and basic balance/index information of the sender account. This makes the implementation of the tx queue more straightforward and efficient and also helps make clear arguments against DoS vectors.
Basically, the only conditions upon which
apply_extrinsic
may panic are:cost_xt_basic + cost_xt_byte * xt.encode().len()
; orxt.index
.If these "panic" conditions are not met then
apply_extrinsic
must never panic. To panic thereafter would cause a DoS vector for the miner at best, and will cause the miner to create invalid blocks at worst.Directly it is determined that
apply_extrinsic
will not panic, the balance should be reduced by the fee and the sender index incremented. Any further "higher-level" criteria that are not met (and would thus cause a panic in the current code) should be reworked to ensure they return instead without changing any storage items (except, of course, the balance reduction and index increment).The text was updated successfully, but these errors were encountered: