This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
weights for include_pvf_check_statement #4933
Comments
24 tasks
pepyakin
added a commit
that referenced
this issue
Feb 17, 2022
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.
1 task
pepyakin
added a commit
that referenced
this issue
Feb 17, 2022
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.
1 task
pepyakin
added a commit
that referenced
this issue
Feb 21, 2022
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.
pepyakin
added a commit
that referenced
this issue
Feb 21, 2022
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.
pepyakin
added a commit
that referenced
this issue
Feb 21, 2022
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.
pepyakin
added a commit
that referenced
this issue
Feb 22, 2022
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.
eskimor
added a commit
that referenced
this issue
Mar 24, 2022
* paras: `include_pvf_check_statement` rt bench 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. * 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 * 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 * 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 * 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 * Fix import error Co-authored-by: Parity Bot <[email protected]> Co-authored-by: Robert Klotzner <[email protected]> Co-authored-by: Lldenaurois <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
No description provided.
The text was updated successfully, but these errors were encountered: