MEV V2 infrastructure

[shamil-gadelshin]

This PR introduces infrastructure for the upcoming MEV Shield V2 feature. The idea is to accumulate encrypted extrinsics in a queue and decrypt them in the next block during the on_initialize phase. Encryption and decryption are
outside the scope of this PR and abstracted via the ExtrinsicDecryptor trait. Protective limits include encrypted call size (const), queue size, weight for extrinsic execution, and lifetime in the queue.

PR features

• Add on_initialize hook to process pending encrypted extrinsics with configurable weight limits, extrinsic lifetime, and queue size
• Add store_encrypted extrinsic for queuing encrypted calls for deferred execution
• Add three root-gated configuration extrinsics: set_max_pending_extrinsics_number, set_on_initialize_weight, and set_stored_extrinsic_lifetime
• Introduce ExtrinsicDecryptor trait for decrypting stored extrinsics before dispatch, with expiration, weight budgeting, and event logging

Details

New Storage Items

• PendingExtrinsics — map of queued encrypted extrinsics awaiting execution
• NextPendingExtrinsicIndex / PendingExtrinsicCount — auto-increment index and live count for the queue
• MaxPendingExtrinsicsLimit — configurable max queue depth (default: 100)
• OnInitializeWeight — configurable max weight budget for on_initialize processing (default: 500B ref_time, capped at 2T)
• ExtrinsicLifetime — configurable max age in blocks before expiration (default: 10)

New Extrinsics

• store_encrypted — signed extrinsic to queue an encrypted call
• set_max_pending_extrinsics_number — root-only, sets queue limit
• set_on_initialize_weight — root-only, sets weight budget with absolute max guard
• set_stored_extrinsic_lifetime — root-only, sets expiration window

Processing Logic (on_initialize)

Iterates pending extrinsics in insertion order. For each entry:

1. Expired entries are removed and ExtrinsicExpired is emitted
2. Decryption failures are removed and ExtrinsicDecodeFailed is emitted
3. If dispatching would exceed the weight budget, processing stops (ExtrinsicPostponed)
4. Otherwise, the call is dispatched from the submitter's signed origin

Other Changes

• Added RuntimeCall and ExtrinsicDecryptor associated types to pallet_shield::Config
• Disambiguated T::RuntimeCall in check_mortality.rs to resolve ambiguity between frame_system::Config and pallet_shield::Config
• Comprehensive tests for all new extrinsics, storage limits, expiration, weight budgeting, and edge cases

Unit Test Plan

• Unit tests for store_encrypted(success, queue full, event emission)
• Unit tests for set_max_pending_extrinsics_number (root-only, value persistence)
• Unit tests for set_on_initialize_weight (root-only, absolute max rejection)
• Unit tests for set_stored_extrinsic_lifetime (root-only, value persistence)
• Unit tests for on_initialize processing (dispatch, expiration, weight limits, decode failures)

Benchmarks

To be added after the initial review.

[l0r1s]

This is maybe one of the rare case where we could use a CountedStorageMap

[l0r1s]

test name is on_initialize_handles_dispatch_failure but we check success on multiple calls?

[l0r1s]

Overall the design is good. My only concern is that the inner call is never charged for, the user gets free execution for whatever is inside. This could probably be fixed by implementing an additional check when trying to execute the call similar to what the ChargeTransactionPayment extension does and reject it if fee can't be paid, could even be done through a DispatchExtension.

[JohnReedV]

Looks good to me. Didn't see anything in addition to Loris’s comments.