CIP-0109? | Modular Exponentiation Built-in for Plutus Core #641
Conversation
perturbing
changed the title
|
I would say the use cases are both simplifying the usage of the new BLS builtins. Currently you have to pass in the inverses of scalars because calculating them is prohibitively expensive (close to 10% cpu). In the case of a Plonk implementation made by perturbing. This also allows for signature and pub key aggregation on-chain to be used for other signature schemes like schnorr and ecdsa256k. Currently adding points on those curves is prohibitively expensive since the calculation of adding points requires an inverse calculation. |
There was a problem hiding this comment.
@perturbing thanks for your submission but this isn't fully ready for review unless you add a Path to Active that addresses the items here, and maybe also update the other sections with these particulars:
CIP-XXXX/README.md
Outdated
| \end{equation} | ||
| $$ | ||
|
|
||
| We propose to also include this extension to the plutus built-in, for optimized inversion when this is possible. This is inversion is not guaranteed to exist for all numbers $b$, only when the modulus $m$ is a prime number this is guaranteed. We also propose that the built-in fails if this inverse does not exist, and if a modulus is provided that is smaller than one. |
There was a problem hiding this comment.
I'm slightly unsure about this. If we don't have this we're just requiring the user to do the inverse themselves, which in a prime finite field is just exponentiating to p-1, right? And then you can merge the exponentiations and do b^((p-1)*e) mod p? So it would still be one builtin call?
There was a problem hiding this comment.
I guess it is logical though.
There was a problem hiding this comment.
You are almost correct, if we do not have it, they will have to exponeniate with p-2 to get find the inverse.
That said, this is less efficient than a dedicated implementation, which may fail in the case if p is not prime. But, failing is not bad behavior in my opinion, as a dApp developer then can rely on this property. Whereas, the p-2 trick will just return an incorrect answer.
rphair
changed the title
rphair
changed the title
There was a problem hiding this comment.
@perturbing you're all set for CIP number 109... please rename your CIP directory as well 🎉
There was a problem hiding this comment.
The feedback on this from Plutus reps has been good, and my own question (from last CIP meeting # 79, repeating #641 (review)), about CIP-0035 compliance, appears addressed by 52baecf and d120768 unless @michaelpj thinks anything is missing from Path to Active.
@perturbing this is coming up for review in today's CIP meeting (https://hackmd.io/@cip-editors/80) and I would say it's good to move to Last Check where the Plutus team & experts can give it further/final confirmation.
rphair
added
the
Last Check
| ### Cost model | ||
| The computational impact of modular exponentiation is complexified by it having three arguments. That said, observe that the integers used can always be bound by the modulus. Preliminary [benchmarks](https://github.com/perturbing/expFast-bench/tree/cca69b842050de9523493d52c20384bc50c80b22) on the time consumption of this `integerPowMod` function show that it can be costed constant in the size of its first argument (the base) and linear in the other two. | ||
|
|
||
| ## Rationale: how does this CIP achieve its goals? |
There was a problem hiding this comment.
Would be nice to see a little more discussion in the Rationale.
Perhaps:
- What would be other alternatives to this design?
- Any backwards compatibility considerations?
There was a problem hiding this comment.
Mainly resolved with ebcd2ec.
Editor consensus to resolve current deadlock from CIP meeting 81 in which Rationale was identified to be "thin" but still not being able to get supplementary writing from authors.
Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com>
…foundation#641) * add readme for modular exponentiation CIP * add other authors * remove unwanted semi-colon * remove unwanted semi-colon * add path to active * add historic note, extra acceptance criteria and formatting * assign official CIP number 109 * change directory name to match assigned cip number * delete old CIP-XXXX dir * pin github links * add implementors * formatting * corrected missing CC license link * formatting * Update CIP-0109/README.md * moved Rationale paragraph to Rationale from Motivation Editor consensus to resolve current deadlock from CIP meeting 81 in which Rationale was identified to be "thin" but still not being able to get supplementary writing from authors. * more detail in satisfaction of implementation requirements Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com> --------- Co-authored-by: Robert Phair <rphair@cosd.com> Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com>
…foundation#641) * add readme for modular exponentiation CIP * add other authors * remove unwanted semi-colon * remove unwanted semi-colon * add path to active * add historic note, extra acceptance criteria and formatting * assign official CIP number 109 * change directory name to match assigned cip number * delete old CIP-XXXX dir * pin github links * add implementors * formatting * corrected missing CC license link * formatting * Update CIP-0109/README.md * moved Rationale paragraph to Rationale from Motivation Editor consensus to resolve current deadlock from CIP meeting 81 in which Rationale was identified to be "thin" but still not being able to get supplementary writing from authors. * more detail in satisfaction of implementation requirements Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com> --------- Co-authored-by: Robert Phair <rphair@cosd.com> Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com>
Hi
This CIP proposes an extension of the current plutus functions to provide support for the efficient calculation of modular exponentiation with inverses.
Rendered proposal on branch.