[Feature] Batch proposal spend limits #2601
Conversation
065a96b to
66d957b
Compare
| const BATCH_SPEND_LIMIT: u64 = Self::TRANSACTION_SPEND_LIMIT; | ||
| /// The base cost in microcredits to verify an execution. | ||
| /// NOTE: this constant reflects the compute cost of an execution, but is not required to be paid by the user. | ||
| const EXECUTION_BASE_COST: u64 = 2_000_000; // 2 million microcredits. |
There was a problem hiding this comment.
"is not required to be paid by the user" What does this mean?
A transfer_public is currently around 51k microcredits, why is there a need for the additional 2 million microcredits?
There was a problem hiding this comment.
Is this to arbitrarily say that a proposal is upper bounded by BATCH_SPEND_LIMIT / EXECUTION_BASE_COST number of executions?
There was a problem hiding this comment.
Executions do incur compute, we just don't price it in at the moment. So it makes sense to take it into account when determining the spend limit - or better wording: 'compute limit'.
Right now it doesn't matter too much because we have a batch proposal size limit, we could leave it it.
However, in the future we may want to consider getting rid of the batch proposal size limit, and only keep the compute limit, at which point we better not forget that proof verification takes up a significant amount of compute.
I agree 2 credits seems like a lot - but note that single-threaded proof verification costs multiple milliseconds. I think in any case this can likely be lowered to 1 or 0.5 for now.
There was a problem hiding this comment.
It seems like cost is an overloaded term here, as it implies it's used for the execution fees paid by the user.
In theory, the execution fee should already price in the cost of compute. An execution fee is the cost of finalize + storage cost; the storage cost can be considered the base level of payment for storing and performing the verification on the transaction.
It feels confusing that a constant is tacked on here to limit the proposal spend by misrepresenting and inflating the "cost" of each transaction.
| @@ -132,6 +133,12 @@ pub trait Network: | |||
| const MAX_FEE: u64 = 1_000_000_000_000_000; | |||
| /// The maximum number of microcredits that can be spent on a finalize block. | |||
There was a problem hiding this comment.
nit
| /// The maximum number of microcredits that can be spent on a finalize block. | |
| /// The maximum number of microcredits that can be spent on a transaction's finalize scope. |
This PR introduces a
BATCH_SPEND_LIMITwhich is currently set to 100 credits and continues the exploratory work done in #2565. Under the assumption that 100 credits equals 1s of single-threaded runtime and given that a block containsNUM_MAX_CERTIFICATES, the upper bound on block time should be approximately 16s, in the worst case. Unfortunately, this approach does scale with the number of validators.Drafted as more discussion and testing is required.
Note: we'll need to adjust the relevant block heights for the transition to
ConsensusVersion::V4enabling the spend limits once we're closer to shipping this PR.