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.

This is not my forté either, but if this one you might have seen already isn’t what you’re looking for, then maybe you could say say what’s missing & I’ll keep an eye out for it?

If this is you’re looking for but you need a different curve, there’s also this one which was in progress for a while:

… but that we had to close when the author apparently abandoned it; if appropriate, perhaps you could take it over and/or combine it with the work you’ve already done

I’m totally all for CIP-381 to get implemented ASAP, though. Where can we check how things are going regarding implementation of a Proposed CIP? (which it looks like it is)

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.

The GitHub issue tracking it shows it’s Blocked (since Nov 7, 2022). I wonder if there’s any help needed to get it over the hump.

Super-interested to learn more about such limits: What is the actual number for the limit? Where is it set?
Do you have a link to the source code / docs / spec, by any chance?

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.