Doesn’t look like we have a CIP for including Elliptic curve operations as built-in functions in Plutus. I did a little searching but haven’t found any yet. If such a thing does exist, I’d love to take a look.
If nothing is out there yet, I’m putting together a list of such functions, and would love to share it as a CIP. What do y’all think?
I would be keen to see that. Not that I can understand the maths behind it. Still, I try to learn.
I would particularly like to have a function that I can apply to my stake pool private key, slot number, and epoch nonce, in order to check the output of the VRF that Cardano uses for leadership election.
There are people feeling that they don’t trust this VRF code built into cardano-node and actually running that function on real data to confirm when their pool gets elected as leader and when it doesn’t would help.
It’s because CIP-0381’s PR has been closed with no activity that I was suggesting you might want to champion this CIP and continue the PR or reincarnate it as another one merged with your work. This would be rare but welcome … if any “abandoned” CIP has been taken over & completed by someone else, it’s been arranged behind the scenes in a way that wasn’t clear from GitHub activity.
using your private key in a built-in function in Plutus would mean that you have to share your private key. I’m not sure what exactly you want, but you could implement the VRF independently and run it on your local machine to check whether the value matches with the one computed by the node.
It’s quite advanced, and we are now running benchmarks. In a nutshell, we want to see whether a zero knowledge proof can be verified within the execution budget with these primitives.
Pasta curves have very nice properties. The downside of them, and the recursive proofs over pasta curves, are that the verification complexity is linear WRT the statement that you want to prove. Even for small proofs the cost of verification is already around 50ms, which is above the script limit. In other words, even if we had the pasta curves arithmetic as built-in functions, we wouldn’t be able to verify a (recursive) proof on-chain.
yes, you’re right, I got them mixed up. Truthfully there’s no way to monitor the implementation of either curve CIP (the officially merged or the unmerged candidate) because neither of them have a checklist or implementors in a Path to Active section.
If you needed to enquire so that some responsible parties could find out the implementation status, I’d like to think you could post on the PR for that CIP, even if closed, but that’s not always successful.
Posting a request in the issue queue for the CIPs repository mainly gets processed by CIP editors and we often don’t know any more about implementation status than the general public: so I wouldn’t recommend that either.
The best bet (if no further responses here) could be asking in the CIP Discord in the #general category next (since you’re already documented the issue well enough here on the Forum):
There is a blogpost about the script budget in plutus
Hope this helps you!
Regarding help unblocking the BLS PR, what we are really doing is trying to understand that the functions are cheap enough for certain use cases. So probably, the best one can do now is think about use cases for those curve operations, and have estimates of how many of each operation is required. For example, if you want to use those built-ins for BLS aggregate signature verification, then one needs n G1 additions (where n is the size of the batch) and one pairing evaluation.
Understanding these use cases and their feasibility will definitely help.