mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-06-13 04:41:02 +00:00
frame-benchmarking-cli: Remove native dispatch requirement (#14474)
* frame-benchmarking-cli: Remove native dispatch requirement No need for this, we can just use the `WasmExecutor` directly. * Fixes * Pass benchmarking host functions * Ensure we can pass custom host functions
This commit is contained in:
@@ -1152,10 +1152,10 @@ where
|
||||
// Verification for imported blocks is skipped in two cases:
|
||||
// 1. When importing blocks below the last finalized block during network initial
|
||||
// synchronization.
|
||||
// 2. When importing whole state we don't calculate epoch descriptor, but rather
|
||||
// read it from the state after import. We also skip all verifications
|
||||
// because there's no parent state and we trust the sync module to verify
|
||||
// that the state is correct and finalized.
|
||||
// 2. When importing whole state we don't calculate epoch descriptor, but rather read it
|
||||
// from the state after import. We also skip all verifications because there's no
|
||||
// parent state and we trust the sync module to verify that the state is correct and
|
||||
// finalized.
|
||||
return Ok(block)
|
||||
}
|
||||
|
||||
|
||||
@@ -78,11 +78,11 @@ pub(crate) struct VoterOracle<B: Block> {
|
||||
///
|
||||
/// There are three voter states coresponding to three queue states:
|
||||
/// 1. voter uninitialized: queue empty,
|
||||
/// 2. up-to-date - all mandatory blocks leading up to current GRANDPA finalized:
|
||||
/// queue has ONE element, the 'current session' where `mandatory_done == true`,
|
||||
/// 2. up-to-date - all mandatory blocks leading up to current GRANDPA finalized: queue has ONE
|
||||
/// element, the 'current session' where `mandatory_done == true`,
|
||||
/// 3. lagging behind GRANDPA: queue has [1, N] elements, where all `mandatory_done == false`.
|
||||
/// In this state, everytime a session gets its mandatory block BEEFY finalized, it's
|
||||
/// popped off the queue, eventually getting to state `2. up-to-date`.
|
||||
/// In this state, everytime a session gets its mandatory block BEEFY finalized, it's popped
|
||||
/// off the queue, eventually getting to state `2. up-to-date`.
|
||||
sessions: VecDeque<Rounds<B>>,
|
||||
/// Min delta in block numbers between two blocks, BEEFY should vote on.
|
||||
min_block_delta: u32,
|
||||
|
||||
@@ -84,19 +84,17 @@ use std::{
|
||||
/// the API of this behaviour and towards the peerset manager is aggregated in
|
||||
/// the following way:
|
||||
///
|
||||
/// 1. The enabled/disabled status is the same across all connections, as
|
||||
/// decided by the peerset manager.
|
||||
/// 2. `send_packet` and `write_notification` always send all data over
|
||||
/// the same connection to preserve the ordering provided by the transport,
|
||||
/// as long as that connection is open. If it closes, a second open
|
||||
/// connection may take over, if one exists, but that case should be no
|
||||
/// different than a single connection failing and being re-established
|
||||
/// in terms of potential reordering and dropped messages. Messages can
|
||||
/// be received on any connection.
|
||||
/// 3. The behaviour reports `NotificationsOut::CustomProtocolOpen` when the
|
||||
/// first connection reports `NotifsHandlerOut::OpenResultOk`.
|
||||
/// 4. The behaviour reports `NotificationsOut::CustomProtocolClosed` when the
|
||||
/// last connection reports `NotifsHandlerOut::ClosedResult`.
|
||||
/// 1. The enabled/disabled status is the same across all connections, as decided by the peerset
|
||||
/// manager.
|
||||
/// 2. `send_packet` and `write_notification` always send all data over the same connection to
|
||||
/// preserve the ordering provided by the transport, as long as that connection is open. If it
|
||||
/// closes, a second open connection may take over, if one exists, but that case should be no
|
||||
/// different than a single connection failing and being re-established in terms of potential
|
||||
/// reordering and dropped messages. Messages can be received on any connection.
|
||||
/// 3. The behaviour reports `NotificationsOut::CustomProtocolOpen` when the first connection
|
||||
/// reports `NotifsHandlerOut::OpenResultOk`.
|
||||
/// 4. The behaviour reports `NotificationsOut::CustomProtocolClosed` when the last connection
|
||||
/// reports `NotifsHandlerOut::ClosedResult`.
|
||||
///
|
||||
/// In this way, the number of actual established connections to the peer is
|
||||
/// an implementation detail of this behaviour. Note that, in practice and at
|
||||
|
||||
@@ -402,9 +402,9 @@ pub trait NetworkNotification {
|
||||
/// a receiver. With a `NotificationSender` at hand, sending a notification is done in two
|
||||
/// steps:
|
||||
///
|
||||
/// 1. [`NotificationSender::ready`] is used to wait for the sender to become ready
|
||||
/// 1. [`NotificationSender::ready`] is used to wait for the sender to become ready
|
||||
/// for another notification, yielding a [`NotificationSenderReady`] token.
|
||||
/// 2. [`NotificationSenderReady::send`] enqueues the notification for sending. This operation
|
||||
/// 2. [`NotificationSenderReady::send`] enqueues the notification for sending. This operation
|
||||
/// can only fail if the underlying notification substream or connection has suddenly closed.
|
||||
///
|
||||
/// An error is returned by [`NotificationSenderReady::send`] if there exists no open
|
||||
|
||||
@@ -192,12 +192,10 @@ pub struct Finalized<Hash> {
|
||||
/// The event generated by the `follow` method.
|
||||
///
|
||||
/// The events are generated in the following order:
|
||||
/// 1. Initialized - generated only once to signal the
|
||||
/// latest finalized block
|
||||
/// 1. Initialized - generated only once to signal the latest finalized block
|
||||
/// 2. NewBlock - a new block was added.
|
||||
/// 3. BestBlockChanged - indicate that the best block
|
||||
/// is now the one from this event. The block was
|
||||
/// announced priorly with the `NewBlock` event.
|
||||
/// 3. BestBlockChanged - indicate that the best block is now the one from this event. The block was
|
||||
/// announced priorly with the `NewBlock` event.
|
||||
/// 4. Finalized - State the finalized and pruned blocks.
|
||||
#[derive(Debug, Clone, PartialEq, Serialize, Deserialize)]
|
||||
#[serde(rename_all = "camelCase")]
|
||||
|
||||
Reference in New Issue
Block a user