Trait TrustedPreallocate

pub trait TrustedPreallocate {
    // Required method
    fn max_allocation() -> u64;
}

Blind preallocation of a Vec<T: TrustedPreallocate> is based on a bounded length. This is in contrast to blind preallocation of a generic Vec<T>, which is a DOS vector.

The max_allocation() function provides a loose upper bound on the size of the Vec<T: TrustedPreallocate> which can possibly be received from an honest peer. If this limit is too low, Zebra may reject valid messages. In the worst case, setting the lower bound too low could cause Zebra to fall out of consensus by rejecting all messages containing a valid block.

Required Methods

fn max_allocation() -> u64

Provides a loose upper bound on the size of the Vec<T: TrustedPreallocate> which can possibly be received from an honest peer.

Object Safety

This trait is not object safe.

Implementations on Foreign Types

impl TrustedPreallocate for Signature<SpendAuth>

fn max_allocation() -> u64

impl TrustedPreallocate for Signature<SpendAuth>

fn max_allocation() -> u64

impl<T> TrustedPreallocate for Arc<T>

where T: TrustedPreallocate,

fn max_allocation() -> u64

Implementors

impl TrustedPreallocate for Transaction

No valid Zcash message contains more transactions than can fit in a single block

tx messages contain a single transaction, and block messages are limited to the maximum block size.

impl TrustedPreallocate for Input

The maximum number of inputs in a valid Zcash on-chain transaction.

If a transaction contains more inputs than can fit in maximally large block, it might be valid on the network and in the mempool, but it can never be mined into a block. So rejecting these large edge-case transactions can never break consensus.

impl TrustedPreallocate for Hash

The maximum number of hashes in a valid Zcash protocol message.

impl TrustedPreallocate for CountedHeader

impl TrustedPreallocate for Action

The maximum number of orchard actions in a valid Zcash on-chain transaction V5.

If a transaction contains more actions than can fit in maximally large block, it might be valid on the network and in the mempool, but it can never be mined into a block. So rejecting these large edge-case transactions can never break consensus.

impl TrustedPreallocate for Groth16Proof

impl TrustedPreallocate for OutputInTransactionV4

The maximum number of sapling outputs in a valid Zcash on-chain transaction. This maximum is the same for transaction V4 and V5, even though the fields are serialized in a different order.

If a transaction contains more outputs than can fit in maximally large block, it might be valid on the network and in the mempool, but it can never be mined into a block. So rejecting these large edge-case transactions can never break consensus

impl TrustedPreallocate for OutputPrefixInTransactionV5

impl TrustedPreallocate for Spend<PerSpendAnchor>

The maximum number of sapling spends in a valid Zcash on-chain transaction V4.

impl TrustedPreallocate for SpendPrefixInTransactionV5

The maximum number of sapling spends in a valid Zcash on-chain transaction V5.

If a transaction contains more spends than can fit in maximally large block, it might be valid on the network and in the mempool, but it can never be mined into a block. So rejecting these large edge-case transactions can never break consensus.

impl TrustedPreallocate for JoinSplit<Bctv14Proof>

impl TrustedPreallocate for JoinSplit<Groth16Proof>

impl TrustedPreallocate for Output

The maximum number of outputs in a valid Zcash on-chain transaction.

If a transaction contains more outputs than can fit in maximally large block, it might be valid on the network and in the mempool, but it can never be mined into a block. So rejecting these large edge-case transactions can never break consensus.