[Feature] Introduce BLOCK_SPEND_LIMIT
#2565
Conversation
Extend deployment verification benchmarks
synthesizer/src/vm/finalize.rs
Outdated
| if current_block_height >= N::CONSENSUS_V2_HEIGHT { | ||
| // If the transaction is an execution, ensure that the total finalize cost does not exceed the block spend limit. | ||
| if let Transaction::Execute(_, execution, _) = transaction { |
There was a problem hiding this comment.
nit: it might be a good idea to swap these conditions in order to not suggest that the code block below contains the only CONSENSUS_V2 logic (since there is also extra logic for deploy txs); alternatively, that extra logic applicable to deploy txs could be moved under this code block (without altering the order), keeping all the V2 logic in one place
There was a problem hiding this comment.
Agree I like the clarity: fcbbb68
synthesizer/process/src/cost.rs
Outdated
| @@ -86,6 +89,12 @@ fn execution_storage_cost<N: Network>(size_in_bytes: u64) -> u64 { | |||
| } | |||
| } | |||
|
|
|||
| /// Returns the fixed cost for an execution. | |||
| /// NOTE: this constant reflects the compute cost of an execution, but is not required to be paid by the user. | |||
| pub fn execution_fixed_cost<N: Network>() -> u64 { | |||
There was a problem hiding this comment.
are there plans to extend this logic (in which case an alternative name might be more fitting)? I'm wondering about the rationale for the existence of a (non-const) function wrapper for a const
There was a problem hiding this comment.
I swear this was in my git staging area already: 3443c3e
are there plans to extend this logic (in which case an alternative name might be more fitting)?
Unclear at the moment. Only other name I can imagine is execution_compute_cost?
Motivation
This PR introduces
BLOCK_SPEND_LIMIT, the maximum amount in microcredits that can be spent on finalizing executions and synthesizing deployments in a block. This gives much greater certainty of maximum blocktimes. The advantages of this limit, analogous to a gas limit, are:more accurate (validator/mining) rewards if they're assuming a particular blocktimeNo longer relevantThe new limit is only enabled from
CONSENSUS_V2_HEIGHTonwards.A limit of 950 credits was chosen because:
BLOCKTIMEis supposed to be 10 seconds.Solutionverification, this incurs significant free compute. 4 solutions take 180ms to verify on macbook M1 max.EXECUTION_FIXED_COSTof 2 credits is introduced. This is not reflected in fees, as it is subsidized, but it does count towards theBLOCK_SPEND_LIMIT. Benchmarks on M2 max imply between 15ms and 25ms verification time for executions.137executions, which would still remain below thisBLOCK_SPEND_LIMIT.Open questions
ROUND_SPEND_LIMIT*num_roundsorPROPOSAL_SPEND_LIMIT*num_proposals? Or better: could we impose a spend limit per individual proposal?Out of scope / future work
Test Plan
Related PRs
Replaces #2371