pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-05-31 13:21:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

Use a BoundedVec in ValidationResult (#6603)

Browse Source 
* Use a `BoundedVec` in `ValidationResult`

> Use a `BoundedVec` for `upward_messages` and `horizontal_messages` in order to
> limit the number of individual messages/memory allocations right at decoding
> time. The reason for this is that the `ValidationResult` may contain a code
> upgrade (including a full PVF binary), so the total size limit can't be set
> too low and this limit will still allow several millions of upward messages,
> which will (due to the memory allocator overhead) already have a
> non-negligible memory footprint in decoded form.

* List all fields when hashing so we don't miss one

* Define types for  `BoundedVec`s of messages

* Fix test compile errors

* Depend on `bounded-collections` 0.1.4 (fixes allocation issue)

* Fix compilation issue

* Derive `Hash` instead of manual `impl`

* Avoid use of unwrap
This commit is contained in:
Marcin S
2023-02-16 16:08:56 +01:00
committed by GitHub
parent 686f6972ce
commit d5a7991429
26 changed files with 124 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/parachain/src/primitives.rs
+19 -2
View File
@@ -19,6 +19,7 @@
use sp_std::vec::Vec;
use bounded_collections::{BoundedVec, ConstU32};
use frame_support::weights::Weight;
use parity_scale_codec::{CompactAs, Decode, Encode, MaxEncodedLen};
use scale_info::TypeInfo;
@@ -361,6 +362,22 @@ pub struct ValidationParams {
pub relay_parent_storage_root: Hash,
}
/// Maximum number of HRMP messages allowed per candidate.
///
/// We also use this as a generous limit, which still prevents possible memory exhaustion, from
/// malicious parachains that may otherwise return a huge amount of messages in `ValidationResult`.
pub const MAX_HORIZONTAL_MESSAGE_NUM: u32 = 16 * 1024;
/// Maximum number of UMP messages allowed per candidate.
///
/// We also use this as a generous limit, which still prevents possible memory exhaustion, from
/// malicious parachains that may otherwise return a huge amount of messages in `ValidationResult`.
pub const MAX_UPWARD_MESSAGE_NUM: u32 = 16 * 1024;
pub type UpwardMessages = BoundedVec<UpwardMessage, ConstU32<MAX_UPWARD_MESSAGE_NUM>>;
pub type HorizontalMessages =
BoundedVec<OutboundHrmpMessage<Id>, ConstU32<MAX_HORIZONTAL_MESSAGE_NUM>>;
/// The result of parachain validation.
// TODO: balance uploads (https://github.com/paritytech/polkadot/issues/220)
#[derive(PartialEq, Eq, Clone, Encode)]
@@ -371,9 +388,9 @@ pub struct ValidationResult {
/// An update to the validation code that should be scheduled in the relay chain.
pub new_validation_code: Option<ValidationCode>,
/// Upward messages send by the Parachain.
pub upward_messages: Vec<UpwardMessage>,
pub upward_messages: UpwardMessages,
/// Outbound horizontal messages sent by the parachain.
pub horizontal_messages: Vec<OutboundHrmpMessage<Id>>,
pub horizontal_messages: HorizontalMessages,
/// Number of downward messages that were processed by the Parachain.
///
/// It is expected that the Parachain processes them from first to last.