-
Notifications
You must be signed in to change notification settings - Fork 252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[secp256r1] Add CU costs #3826
[secp256r1] Add CU costs #3826
Conversation
7d82dd4
to
e42b525
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Thanks for adding it.
Will this be backported to 2.0/2.1? If it is released after CU limits are enforced on Replay, it will need a feature gate since it changes transaction's CU cost.
Okay, I rekeyed the existing feature gate and then put the cost behind that feature gate. Yeah the original plan was to backport, but I think we will have to wait until the next backport meeting. |
builtins-default-costs/src/lib.rs
Outdated
native_cost: 0, | ||
core_bpf_migration_feature: None, | ||
} | ||
) | ||
// DO NOT ADD MORE ENTRIES TO THIS MAP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ha apparently this warning wasn't sufficient? We can't add more entries to this map without risking a consensus failure because after #3799, any changes will impact the default compute unit limit we calculate for transactions which don't specify a limit explicitly. The specific issues is that any tx instruction which invokes a "builtin program" (i.e. an entry in this map) will be allocated 3k cu's rather than 200k cu's. If you revert this change the rest of the PR looks ok to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I did see the warning and asked about it, but I seemed to have misinterpreted the answers that I got 😅. I will revert!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please let's land #3866 and eliminate this footgun.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#3948 to document cost model issue with precompile
67b3e4f
to
9f9bb84
Compare
Sorry I seem to have left this hanging. I'll merge this tomorrow. Please let me know if there is anything stopping this from going in. We will not need to backport this. |
Problem
The secp256r1 precompile (#3152) was added, but the compute cost has not been assigned.
Summary of Changes
Added builtin default costs and a static cost in the cost-model for the secp256r1 precompile.
For the static cost, I benchmarked the existing three precompiles on my dev machine.
For each transaction length, secp256k1 signatures took at most 3x the time compared to ed25519. The assigned compute units for secp256k1 is about 3x that of ed25519, which seemed to make sense.
Secp256r1 signatures take at most 2x the time compared to ed25519. It would be safe to assign CU about 2x that of ed25519, so I added 160 CUs. Please let me know if there are better ways to approximate the static costs.
Fixes #