Trait UpdateDataSource 

pub trait UpdateDataSource<Types: NodeType>: UpdateAvailabilityData<Types> {
    // Required method
    fn update<'life0, 'life1, 'async_trait>(
        &'life0 self,
        event: &'life1 CoordinatorEvent<Types>,
    ) -> Pin<Box<dyn Future<Output = Result<(), u64>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait,
             'life1: 'async_trait;
}

An extension trait for types which implement the update trait for each API module.

If a type implements UpdateAvailabilityData and UpdateStatusData, then it can be fully kept up to date through two interfaces:

• populate_metrics, to get a handle for populating the status metrics, which should be used when initializing a SystemContextHandle
• update, provided by this extension trait, to update the query state when a new HotShot event is emitted

Required Methods

fn update<'life0, 'life1, 'async_trait>( &'life0 self, event: &'life1 CoordinatorEvent<Types>, ) -> Pin<Box<dyn Future<Output = Result<(), u64>> + Send + 'async_trait>>

where Self: 'async_trait, 'life0: 'async_trait, 'life1: 'async_trait,

Update query state based on consensus event.

The caller is responsible for authenticating event. This function does not perform any authentication, and if given an invalid event (one which does not follow from the latest known state of the ledger) it may panic or silently accept the invalid event. This allows the best possible performance in the case where the query service and the HotShot instance are running in the same process (and thus the event stream, directly from HotShot) is trusted.

If you want to update the data source with an untrusted event, for example one received from a peer over the network, you must authenticate it first.

For each decided leaf the query service stores a BlockInfo containing the leaf paired with a QC that certifies it (LeafQueryData), the block payload and VID data when available, and only on the newest leaf in the batch, it stores the proof that finalizes it: a qc_chain for legacy protocol set via BlockInfo::with_qc_chain, or a cert2 for new protocol set via BlockInfo::with_cert2. The two protocols differ only in where those pieces come from:

In both events leaves arrive in newest → oldest order (leaves[0] is the leaf being finalized; each subsequent leaf is its ancestor reached via justify_qc). For the new protocol, vid_shares is parallel to leaves (same ordering, one share per leaf). The handler iterates in reverse so heights are appended ascending.

• Legacy (CoordinatorEvent::LegacyEvent → EventType::Decide). The newest leaf is certified by committing_qc; each older leaf is certified by the next-newer leaf’s justify_qc. The newest leaf’s qc_chain is set to [committing_qc, deciding_qc] — the two consecutive QCs that decide it under the legacy 3-chain rule.

• New protocol (CoordinatorEvent::NewDecide). The newest leaf is certified by cert1; older leaves are again certified by the next leaf’s justify_qc. When a cert2 is present, it is attached to the newest leaf. Under the new protocol a single cert2 finalizes that leaf directly, replacing the legacy QC chain.

Returns

If all provided data is successfully inserted into the database, returns Ok(()). If any error occurred, the error is logged, and the return value is the height of the first leaf which failed to be inserted.

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.

Implementors

impl<Types: NodeType, T> UpdateDataSource<Types> for T

where T: UpdateAvailabilityData<Types> + Send + Sync, Header<Types>: QueryableHeader<Types>, Payload<Types>: QueryablePayload<Types>,