Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: tx-pause and safe-mode pallets integration #1388

Merged
merged 15 commits into from
Dec 5, 2024

Conversation

ipapandinas
Copy link
Contributor

@ipapandinas ipapandinas commented Nov 25, 2024

Pull Request Summary

This PR integrates the SafeMode and TxPause pallets into the Shibuya runtime. Key configuration decisions are as follows:

SafeMode Configuration

  • EnterDepositAmount and ExtendDepositAmount are set to None, making safe-mode non-permissionless.
  • EnterDuration is set to 4 hours, with extensions allowed in increments of 2 hours.
  • Only accounts with EnsureRootOrHalfTechnicalCommittee origin can force enter or extend safe-mode
  • Only accounts with EnsureRootOrTwoThirdsTechnicalCommittee origin can force exit safe-mode
  • dAppStaking’s maintenance mode is triggered by Notify when entering/exiting safe-mode.

TxPause Configuration

  • Calls can be paused/unpaused by accounts with EnsureRootOrHalfTechnicalCommittee origin. The same origin is used by the dAppStaking maintenance manager.
  • All calls can be paused.

These pallets are designed to complement each other effectively, for example if halting block production after entering safe-mode is required, this can be performed by pausing System or Timestamp calls by using tx-pause.

Benchmarks

The additional DB read introduced by the TxPause base filter in the extrinsic base weight is hardcoded with 1 db read for now. This is a temporary fix, a proper benchmark must be done in the future.

Check list

  • added or updated unit tests
  • updated Astar official documentation
  • added OnRuntimeUpgrade hook for precompile revert code registration
  • added benchmarks & weights for any modified runtime logics.

@ipapandinas ipapandinas added shibuya related to shibuya runtime This PR/Issue is related to the topic “runtime”. labels Nov 25, 2024
@ipapandinas ipapandinas changed the title feat: tx-pause and safe-mode pallets integration feat: tx-pause and safe-mode pallets integration Nov 25, 2024
@ipapandinas ipapandinas requested review from ermalkaleci and Dinonard and removed request for ermalkaleci November 25, 2024 16:32
Comment on lines 1556 to 1558
// System and Timestamp are required for block production
| RuntimeCall::System(_)
| RuntimeCall::Timestamp(_)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dumb question - aren't these calls inherent though?
If such calls also need to be filtered, parachain system should also be included here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I remove Timestamp block production stops:

❌️ Mandatory inherent extrinsic returned error. Block cannot be produced.

But, I removed SafeMode since the safe-mode pallet cannot disable it's own calls and I added ParachainSystem.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm strange, have to admit that I'm surprised :)

runtime/shibuya/src/lib.rs Outdated Show resolved Hide resolved
runtime/shibuya/src/lib.rs Outdated Show resolved Hide resolved
runtime/shibuya/src/lib.rs Outdated Show resolved Hide resolved
runtime/shibuya/src/lib.rs Outdated Show resolved Hide resolved
runtime/shibuya/src/lib.rs Outdated Show resolved Hide resolved
runtime/shibuya/src/lib.rs Outdated Show resolved Hide resolved
runtime/shibuya/src/lib.rs Show resolved Hide resolved
Comment on lines 252 to 254
// Adjusting the base extrinsic weight to account for the additional database
// read introduced by the `tx-pause` pallet during extrinsic filtering.
weights.base_extrinsic = ExtrinsicBaseWeight::get().saturating_add(RocksDbWeight::get().reads(1));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't the way to do it 🙂

  • RocksDb weights is a config param of the frame_system and we should use it from there
  • That aside, this shouldn't be necessarily hardcoded but it should be benchmarked. There is a command to measure base weight and perhaps now is the time to use it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean using the /bench command from the workflows? Should I run it specifically for frame-system and pallet-tx-pause, or should I include others as well? I’m thinking of pallets that involve dispatches, such as proxy, collective-proxy, utility, and scheduler.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a specific command to measure overhead, or base extrinsic weight.

E.g. using the frame-omni-bencher, it should be frame-omni-bencher v1 benchmark overhead.

I guess we'd need to adapt the CI a bit 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing out this command to me; I was not aware of its existence! The overhead command is not yet available in frame-omni-bencher v0.7.0 but should be released in the next Polkadot SDK stable2412 version. I've adjusted the CI to include it alongside our existing benchmarking approach. I will run it below using the /bench command.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, very neat!

runtime/shibuya/src/lib.rs Outdated Show resolved Hide resolved
@AstarNetwork AstarNetwork deleted a comment from github-actions bot Dec 2, 2024
pub type HostFunctions = (
cumulus_client_service::ParachainHostFunctions,
moonbeam_primitives_ext::moonbeam_ext::HostFunctions,
);

/// Host functions required for kitchensink runtime and Substrate node.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't need this. The benchmark host functions is injected by benchmarking-cli itself

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am getting this error if I remove benchmarking host functions:

Finished release [optimized] target(s) in 3m 14s
     Running `target/release/astar-collator benchmark overhead --dev --header=./.github/license-check/headers/HEADER-GNUv3`
Error: Service(Client(VersionInvalid("Other error happened while constructing the runtime: runtime requires function imports which are not present on the host: 'env:ext_benchmarking_proof_size_version_1', 'env:ext_benchmarking_add_to_whitelist_version_1', 'env:ext_benchmarking_current_time_version_1', 'env:ext_benchmarking_commit_db_version_1', 'env:ext_benchmarking_read_write_count_version_1', 'env:ext_benchmarking_wipe_db_version_1', 'env:ext_benchmarking_get_read_and_written_keys_version_1', 'env:ext_benchmarking_reset_read_write_count_version_1', 'env:ext_benchmarking_set_whitelist_version_1'")))
2024-12-02 13:52:50 Cannot create a runtime error=Other("runtime requires function imports which are not present on the host: 'env:ext_benchmarking_proof_size_version_1', 'env:ext_benchmarking_add_to_whitelist_version_1', 'env:ext_benchmarking_current_time_version_1', 'env:ext_benchmarking_commit_db_version_1', 'env:ext_benchmarking_read_write_count_version_1', 'env:ext_benchmarking_wipe_db_version_1', 'env:ext_benchmarking_get_read_and_written_keys_version_1', 'env:ext_benchmarking_reset_read_write_count_version_1', 'env:ext_benchmarking_set_whitelist_version_1'")

PS: I will fix the comment (copied)

Copy link
Contributor

@ermalkaleci ermalkaleci Dec 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like overhead doesn't include it, wonder why

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can make an issue or PR for it, probably it's small effort.

@@ -248,7 +249,7 @@ parameter_types! {
pub RuntimeBlockWeights: BlockWeights = BlockWeights::builder()
.base_block(BlockExecutionWeight::get())
.for_class(DispatchClass::all(), |weights| {
weights.base_extrinsic = ExtrinsicBaseWeight::get();
weights.base_extrinsic = weights::base_extrinsic::ExtrinsicBaseWeight::get();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need this. Why not use ExtrinsicBaseWeight and add 2 extra reads. We don't have to maintain this benchmark. Also make sure the fee calculation reflects this

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recommended to use this so I can answer - we benchmark everything else essentially, relying on automated measurements when possible.

It's easier to have something like this, then to hardcode it, IMO.
More correct & consistent also.

Shouldn't be that much of a maintenance since only an additional command is executed within an existing loop, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Dinonard if that's the case then benchmark is missing reads

Copy link
Contributor

@ermalkaleci ermalkaleci Dec 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ipapandinas @Dinonard this overhead benchmark doesn't count any IO. It just measures the overhead of an extrinsic. So there's no use for this. We just need to manually add 2 reads and it should be fine

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't checked the code, only the description of the command.
According to it, it should measure everything?

Maybe it doesn't measure IO operations discretely, but it accounts for them as part of the overall measurement.

Running benchmarks before & after inclusion of the new check could show this I guess.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it doesn't, we should make an issue about it.

It should also measure PoV.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've checked the overhead benchmark command code.

Remark extrinsics pushed into the block used during the benchmark are executed in the client runtime via the FrameExecutive::apply_extrinsic. These extrinsics are dispatched, and the FrameSystem::BaseCallFilter is checked alongside the origin. The new SafeMode & TxPause filters are then measured.

When running the command locally, here are the results I obtained:

Without base call filtering:

type BaseCallFilter = frame_support::traits::Everything;
Average Result: 95_705 nanoseconds

With base call filtering:

type BaseCallFilter = InsideBoth<SafeMode, TxPause>;
Average Result: 103_702 nanoseconds

This represents an 8% increase.
PoV is also measured - reference: paritytech/substrate#11637

Copy link
Contributor Author

@ipapandinas ipapandinas Dec 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However I have the following error when performing the overhead benchmark command via shibuya-dev in the Github workflow:

Finished release [optimized] target(s) in 38m 52s
2024-12-02 14:51:56 Using the chain spec instead of the runtime to generate the genesis state is deprecated. Please remove the `--chain`/`--dev`/`--local` argument, point `--runtime` to your runtime blob and set `--genesis-builder=runtime`. This warning may become a hard error any time after December 2024.    
2024-12-02 14:51:57 assembling new collators for new session 0 at #0    
2024-12-02 14:51:57 assembling new collators for new session 1 at #0    
2024-12-02 14:51:57 Loading WASM from genesis state    
[+] Benchmarking 1 Astar collator pallets.
[+] Benchmarking pallet_tx_pause with weight file ./benchmark-results/shibuya-dev/tx_pause_weights.rs
[+] Benchmarking block and extrinsic overheads...
2024-12-02 14:52:03 assembling new collators for new session 0 at #0    
2024-12-02 14:52:03 assembling new collators for new session 1 at #0    
2024-12-02 14:52:05 🔨 Initializing Genesis block/state (state: 0x81fd…3aae, header-hash: 0x69b1…ac53)    
2024-12-02 14:52:05 panicked at /home/astar-admin/.cargo/git/checkouts/polkadot-sdk-cff69157b985ed76/b98e0b3/cumulus/pallets/parachain-system/src/lib.rs:1297:30:
included head not present in relay storage proof    
Error: Client(RuntimeApiError(Application(Execution(AbortedDueToTrap(MessageWithBacktrace { message: "wasm trap: wasm `unreachable` instruction executed", backtrace: Some(Backtrace { backtrace_string: "error while executing at wasm backtrace:\n    0: 0x1680a - <unknown>!rust_begin_unwind\n    1: 0x52f5 - <unknown>!core::panicking::panic_fmt::hc677f413e2f2c888\n    2: 0x6c74b0 - <unknown>!frame_support::storage::transactional::with_transaction::hdd4b19daa5635076\n    3: 0x19b9ee - <unknown>!<cumulus_pallet_parachain_system::pallet::Call<T> as frame_support::traits::dispatch::UnfilteredDispatchable>::dispatch_bypass_filter::{{closure}}::hf5e7b72922057598\n    4: 0x15bf8b - <unknown>!<shibuya_runtime::RuntimeCall as frame_support::traits::dispatch::UnfilteredDispatchable>::dispatch_bypass_filter::hb7c74cdeb42c4a6a\n    5: 0x154f5b - <unknown>!<shibuya_runtime::RuntimeCall as sp_runtime::traits::Dispatchable>::dispatch::he9dab724d3fc532c\n    6: 0x5d1038 - <unknown>!frame_executive::Executive<System,Block,Context,UnsignedValidator,AllPalletsWithSystem,COnRuntimeUpgrade>::apply_extrinsic::hfe4db20b64a1ce4c\n    7: 0x61f955 - <unknown>!BlockBuilder_apply_extrinsic" }) })))))
2024-12-02 14:52:05 1 storage transactions are left open by the runtime. Those will be rolled back.    
2024-12-02 14:52:05 1 storage transactions are left open by the runtime. Those will be rolled back.    
[-] Failed to benchmark the block and extrinsic overheads. Error written to ./benchmark-results/shibuya-dev/bench_errors.txt; continuing...
[+] Benchmarking the machine...
[-] Benchmarks failed:  ./benchmark-results/shibuya-dev/bench_errors.txt

@ipapandinas
Copy link
Contributor Author

/bench shibuya-dev pallet_tx_pause

Copy link

github-actions bot commented Dec 2, 2024

Benchmarks job is scheduled at https://github.com/AstarNetwork/Astar/actions/runs/12121139663.
Please wait for a while.
Branch: feat/tx-pause-safe-mode
SHA: 03d0f9a

Copy link

github-actions bot commented Dec 2, 2024

Benchmarks have been finished.
You can download artifacts if exists https://github.com/AstarNetwork/Astar/actions/runs/12121139663.

@ermalkaleci
Copy link
Contributor

I would like to have some e2e tests for this, especially what will happen when chain receives a xcm call. Maybe we can use chopsticks to test different scenarios

@Dinonard
Copy link
Member

Dinonard commented Dec 2, 2024

I would like to have some e2e tests for this, especially what will happen when chain receives a xcm call. Maybe we can use chopsticks to test different scenarios

Don't the existing tests cover this?
It's the same as changing how much any existing extrinsic weighs, right?

@ermalkaleci
Copy link
Contributor

@Dinonard No, I mean to test xcm when chain is on restriction mode

@ipapandinas
Copy link
Contributor Author

/bench astar-dev pallet_balances

Copy link

github-actions bot commented Dec 4, 2024

Benchmarks job is scheduled at https://github.com/AstarNetwork/Astar/actions/runs/12158641670.
Please wait for a while.
Branch: feat/tx-pause-safe-mode
SHA: 03d0f9a

Copy link

github-actions bot commented Dec 4, 2024

Benchmarks have been finished.
You can download artifacts if exists https://github.com/AstarNetwork/Astar/actions/runs/12158641670.

runtime/shibuya/src/lib.rs Outdated Show resolved Hide resolved
Dinonard
Dinonard previously approved these changes Dec 4, 2024
runtime/shibuya/src/lib.rs Outdated Show resolved Hide resolved
Dinonard
Dinonard previously approved these changes Dec 4, 2024
@Dinonard Dinonard self-requested a review December 4, 2024 17:43
Copy link

github-actions bot commented Dec 4, 2024

Code Coverage

Package Line Rate Branch Rate Health
precompiles/dapp-staking/src 90% 0%
precompiles/dispatch-lockdrop/src 86% 0%
pallets/ethereum-checked/src 74% 0%
chain-extensions/unified-accounts/src 0% 0%
chain-extensions/pallet-assets/src 56% 0%
pallets/collective-proxy/src 86% 0%
pallets/dapp-staking/src 83% 0%
precompiles/unified-accounts/src 100% 0%
primitives/src 57% 0%
pallets/dapp-staking/src/benchmarking 98% 0%
pallets/collator-selection/src 92% 0%
primitives/src/xcm 65% 0%
pallets/astar-xcm-benchmarks/src 86% 0%
pallets/inflation/src 89% 0%
precompiles/sr25519/src 64% 0%
precompiles/xcm/src 71% 0%
pallets/price-aggregator/src 82% 0%
pallets/dapp-staking/src/test 0% 0%
chain-extensions/types/unified-accounts/src 0% 0%
pallets/static-price-provider/src 85% 0%
pallets/unified-accounts/src 86% 0%
pallets/astar-xcm-benchmarks/src/fungible 100% 0%
precompiles/substrate-ecdsa/src 74% 0%
pallets/astar-xcm-benchmarks/src/generic 100% 0%
precompiles/assets-erc20/src 78% 0%
pallets/dapp-staking/rpc/runtime-api/src 0% 0%
precompiles/dapp-staking/src/test 0% 0%
chain-extensions/types/assets/src 0% 0%
pallets/vesting-mbm/src 89% 0%
pallets/dynamic-evm-base-fee/src 89% 0%
pallets/xc-asset-config/src 50% 0%
Summary 79% (3736 / 4744) 0% (0 / 0)

Minimum allowed line rate is 50%

@ipapandinas ipapandinas merged commit 17fc034 into master Dec 5, 2024
8 checks passed
@ipapandinas ipapandinas deleted the feat/tx-pause-safe-mode branch December 5, 2024 17:19
@ipapandinas ipapandinas linked an issue Dec 5, 2024 that may be closed by this pull request
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
runtime This PR/Issue is related to the topic “runtime”. shibuya related to shibuya
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Integrate tx-pause and safe-mode pallets
3 participants