-
Notifications
You must be signed in to change notification settings - Fork 1.6k
paras: include_pvf_check_statement
rt bench
#4938
Conversation
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
9520bed
to
86256cf
Compare
/benchmark runtime polkadot runtime_parachains::paras |
Benchmark Runtime Polkadot Pallet for branch "pep-pvf-include-pvf-check-benchmark" with command cargo run --quiet --profile=production --features=runtime-benchmarks -- benchmark --chain=polkadot-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic="*" --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/polkadot/src/weights/runtime_parachains_paras.rs Toolchain: stable-x86_64-unknown-linux-gnu (default) Results
|
/benchmark runtime kusama runtime_parachains::paras |
/benchmark runtime westend runtime_parachains::paras |
/benchmark runtime custom --chain=rococo-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic="*" --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/rococo/src/weights/runtime_parachains_paras.rs |
Benchmark Runtime Kusama Pallet for branch "pep-pvf-include-pvf-check-benchmark" with command cargo run --quiet --profile=production --features=runtime-benchmarks -- benchmark --chain=kusama-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic="*" --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/kusama/src/weights/runtime_parachains_paras.rs Toolchain: stable-x86_64-unknown-linux-gnu (default) Results
|
8a22999
to
f80186a
Compare
Benchmark Runtime Westend Pallet for branch "pep-pvf-include-pvf-check-benchmark" with command cargo run --quiet --profile=production --features=runtime-benchmarks -- benchmark --chain=westend-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic="*" --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/westend/src/weights/runtime_parachains_paras.rs Toolchain: stable-x86_64-unknown-linux-gnu (default) Results
|
Benchmark Runtime Custom for branch "pep-pvf-include-pvf-check-benchmark" with command cargo run --quiet --profile=production --features runtime-benchmarks -- benchmark --chain=rococo-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic="*" --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/rococo/src/weights/runtime_parachains_paras.rs Toolchain: stable-x86_64-unknown-linux-gnu (default) Results
|
f80186a
to
92c0ce5
Compare
853f8a0
to
35bb16c
Compare
92c0ce5
to
2a2b2f1
Compare
3cbd9aa
to
bc536c8
Compare
Resolves #4933 This PR adds a benchmark for the `include_pvf_check_statement` dispatchable. This is a necessary step to make it work without modifications. That enables us to proceed with testing on Versi. This introduces 5 new benchmarks. Those measure performance of the `include_pvf_check_statement` under 2 different conditions: 1. regular vote submission. That's the common case. 2. submission of the last vote. That happens only once and leads to a heavy finalization stage. There are 2 different types of finalization (one for onboarding, one for upgrading) and there are two outcomes: accepted and rejected. Those 4 are similar but I decided to cover them all and assign the maximum of all 4. This is to avoid a situation when one of those paths becomes more heavier than others and opens up an attack venue. The regular vote submission weight is drastically different from the submission last vote weight. That's why in case during runtime finalization was not executed the weight consumed value will be lowered down to the regular vote submission. The finalization weight is proportional to the number of "causes", i.e. the events that caused the PVF pre-checking vote in the first place, and here we assume that the maximum number of causes is 100. Theoretically, there is nothing that prevents an adversary to register/upgrade to more than 100 parachains. In that case, the consumed weight will be lower than the actual time consumed by the finalization process. That can enable a DoS vector. However, practically, it is not very possible. Right now it is very expensive to call `schedule_para_initialize` because it requires a very large lock up of funds. Moreover, finalizing a vote with 100 causes leads to around 31ms time spent. Finalizing more will require more time. However, finalizing with 200 causes will cause ≈62ms delay. This is not that bad since even though we had a full block and the adversary tried to finalize 200 causes it won't be able to even exceed the operational extrinsic boundary of 250ms and even if so it won't make big difference. That said, this should be addressed later on, esp. when we enable parathreads, which will make creating causes easier. One of potential solutions will be shifting the logic of finalization into `on_initialize`/`on_finalize`. Another is to create a maximum number of causes and then reject upgrades or onboardings if that was reached.
…-- benchmark --chain=polkadot-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/polkadot/src/weights/runtime_parachains_paras.rs
…-- benchmark --chain=kusama-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/kusama/src/weights/runtime_parachains_paras.rs
…-- benchmark --chain=westend-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/westend/src/weights/runtime_parachains_paras.rs
…-- benchmark --chain=rococo-dev --steps=50 --repeat=20 --pallet=runtime_parachains::paras --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --header=./file_header.txt --output=./runtime/rococo/src/weights/runtime_parachains_paras.rs
bc536c8
to
be6b1da
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Damn it. Can't merge because of conflicts. Could you quickly resolve them @Lldenaurois ? Thanks for the review! |
/benchmark runtime westend runtime_parachains::paras |
* master: Try to fix out of view statements (#5177) Companion for Substrate#11107 (#5197) paras: `include_pvf_check_statement` rt bench (#4938) [ci] Run short benchmarks only in PR pipelines (#5200) Companion for paritytech/substrate#10242 (#4862) [ci] Add short benchmarks to the pipeline (#5188) upgrade coarsetime to 0.1.22 to fix a potential panic (#5193) Update docs and enable DOT-over-XCM (#4809) enable disputes on all chains (#5182) companion for validator self-vote in bags (#5088) Extract MAX_FINALITY_LAG constant from relay_chain_selection (#5159)
Closes #4933
This PR adds a benchmark for the
include_pvf_check_statement
dispatchable. This is a necessary step to make it work without
modifications. That enables us to proceed with testing on Versi.
This introduces 5 new benchmarks. Those measure performance of the
include_pvf_check_statement
under 2 different conditions:heavy finalization stage.
There are 2 different types of finalization (one for onboarding, one for
upgrading) and there are two outcomes: accepted and rejected. Those 4
are similar but I decided to cover them all and assign the maximum of
all 4. This is to avoid a situation when one of those paths becomes more
heavier than others and opens up an attack venue.
The regular vote submission weight is drastically different from the
submission last vote weight. That's why in case during runtime
finalization was not executed the weight consumed value will be lowered
down to the regular vote submission.
The finalization weight is proportional to the number of "causes", i.e.
the events that caused the PVF pre-checking vote in the first place, and
here we assume that the maximum number of causes is 100.
Theoretically, there is nothing that prevents an adversary to
register/upgrade to more than 100 parachains. In that case, the consumed
weight will be lower than the actual time consumed by the finalization
process. That can enable a DoS vector.
However, practically, it is not very possible. Right now it is very
expensive to call
schedule_para_initialize
because it requires a verylarge lock up of funds. Moreover, finalizing a vote with 100 causes
leads to around 31ms time spent. Finalizing more will require more time.
However, finalizing with 200 causes will cause ≈62ms delay. This is not
that bad since even though we had a full block and the adversary tried
to finalize 200 causes it won't be able to even exceed the operational
extrinsic boundary of 250ms and even if so it won't make big difference.
That said, this should be addressed later on, esp. when we enable
parathreads, which will make creating causes easier. One of potential
solutions will be shifting the logic of finalization into
on_initialize
/on_finalize
. Another is to create a maximum number ofcauses and then reject upgrades or onboardings if that was reached.
TODO: