Unify builtin lists wip #4039
Unify builtin lists wip #4039
Conversation
There was a problem hiding this comment.
Awesome to have the single source of truth here. Can you take a look at #3975, there two BUILTINS arrays were created - one for migrating one for not-migrating. The motivation is each transaction can have a fixed-length array in meta data, avoiding Vec allocation, by
struct MigrationBuiltinFeatureCounter {
// The vector of counters, matching the size of the static vector MIGRATION_FEATURE_IDS,
// each counter representing the number of times its corresponding feature ID is
// referenced in this transaction.
migrating_builtin: [u16; MIGRATING_BUILTINS_COSTS.len()],
}
Do you think if that's a reasonable approach? If so, could this PR rebase on top of that one?
builtins/src/cost_modeling.rs
Outdated
| pub struct CostModelingConfig { | ||
| /// The default cost of the builtin program. | ||
| /// If None, this builtin program is not cost modeled. | ||
| pub default_cost: Option<u64>, |
There was a problem hiding this comment.
Nice, this solves ZK stuff. We could use enum instead of Option to make it even more distinguished.
There was a problem hiding this comment.
I refactored to use an enum! I think that's a smoother approach. Good tip.
| .chain( | ||
| [ | ||
| ( | ||
| secp256k1_program::id(), |
There was a problem hiding this comment.
+1 for not forgetting these 2.
the new secp256r1 probably will never be added to this list
builtins/src/cost_modeling.rs
Outdated
| lazy_static! { | ||
| static ref BUILTIN_INSTRUCTION_COSTS: AHashMap<Pubkey, BuiltinCost> = BUILTINS | ||
| .iter() | ||
| .map(|builtin| { |
There was a problem hiding this comment.
maybe can filter out those default_cost.is_none() so the BUILTIN_INSTRUCTION_COSTS itself is identical to before-version?
There was a problem hiding this comment.
I didn't filter out default_cost.is_none() only because this allows get_builtin_instruction_cost to query the new_default_cost field based on feature set.
There was a problem hiding this comment.
I believe my refactor does this now!
buffalojoec
force-pushed
the
unify-builtin-lists-wip
branch
from
62aefd8 to
1c5c3d7
Compare
|
@tao-stones thanks for taking a look! I refactored this a bit and re-wrote my commits (I had to rebase anyway from some other changes that went in). With this approach, we can eliminate the footgun of having to update two lists with a new migration feature ID. The only "secondary" area that needs to get updated now is the |
No description provided.