IntersectMBO / plutus

The Plutus language implementation and tools
Apache License 2.0
1.57k stars 476 forks source link

Re-cost SECP256k1 functions #4802

Closed kwxm closed 2 years ago

kwxm commented 2 years ago

The implementation of the SECP256k1 signature verification built-in functions in Plutus Core was updated by @kozross in #4786, and the change in the implementation will have changed the execution times of these functions. This issue is just to report how the execution times have changed and how this will affect the cost model (summary: the change is pretty small so we probably don't need to do anything).

The current Plutus Core cost model is based on benchmarks run on the 12th of May 2022, and I re-ran the costing benchmarks for the SECP functions on the 3rd of August. There have been efficiency improvements in the Plutus Core evaluator since then, so I also re-ran some of the other built-in functions to see if/how they changed.

VerifyEcdsaSecp256k1Signature

The VerifyEcdsaSecp256k1Signature function takes a fixed length message, so we'd expect the execution time to be about constant. That's borne out by the benchmark results: Ecdsa

The new implementation takes about 10% longer than the old one, which is reasonable given that the function's now carrying out more preliminary checks. Our inference procedure fits a constant cost of 35190005 units to the old implementation and 39724068 units to the new one.

VerifySchnorrSecp256k1Signature

This takes a variable-length message and we expect the time taken to be approximately linear in the message size. This is indeed the case:

Schnorr

This time the new implementation is actually faster than the old one by a few percent. It seems likely that the decrease is due to improvements in the Plutus Core evaluator since May, and other functions show similar speedups (see below). The costing function inferred for the old implementation was 39121781 + 32260*m, (where m is the message size), and the costing function for the new one is 44339318 + 30542*m. Note that the new function has a larger intercept (probably due to extra costs being carried out n inputs) but a lower slope (consistent with improved evaluation times).

Other functions

Benchmark results for VerifyEd25519Signature and DecodeUtf8 are shown below. Both of these show speedups similar to VerifySchnorrSecp256k1Signature Ed25519 DecodeUtf8

Conclusion

The costs of the new implementations of the SECP signature verification functions have changed by a few percent, but so have the costs of other functions whose implementations have not been changed. Nothing unexpected appears to have happened where the new implementations are concerned.

Any changes seem quite minimal, so I don't think we need to update the cost model specially for the new SECP implementations. We'll re-calibrate the entire thing at some point before the next hard fork, and that should take care of changes due to both evaluator efficiency and the updated SECP implementations.

kwxm commented 2 years ago

I'll close this issue in a day or two. It's really just here to record the results and doesn't need any action.