Skip to content

[Proposal] Further clean up spend limits #3264

Description

@vicsn

💥 Proposal

There are several goals we need to keep in mind:

  1. A high inclusion rate: meaning honest validators should not pack more transmissions than the batch_spend_limit allows.
  2. A stable blocktime: meaning we want to limit the batch_spend_limit.

We should consider implement the following improvements still with regards to goal 1.:

  • Consider lowering the TRANSACTION_SPEND_LIMIT such that it is a fraction of the batch_spend_limit so we can have higher fairness guarantees (requires regression analysis to see if a lower transaction spend limit offers acceptable UX)

We should consider implement the following improvements still with regards to goal 2.:

  • Lower batch_spend_limit to for example 5_f64 * credits_per_second_of_runtime / max_certificates, but for clarity/consistency take care that it doesn't drop below TRANSACTION_SPEND_LIMIT.
  • Enforce the batch_spend_limit in the finalize scope on a per-certificate basis, not aggregated across the block.

Finally, there are a few places in the code where we select a hardcoded element (N::TRANSACTION_SPEND_LIMIT[1].1) even though we should select by ConsensusVersion

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions