Skip to content

Conversation

@iquerejeta
Copy link
Contributor

The cardano base branch has been merged, and the PR for plutus bindings is open IntersectMBO/plutus#5231. Some of the initial notation has changed. This PR adapts the CIP to the new notation.

@rphair rphair changed the title [WIP] Adapt CIP to Plutus bindings CIP-0381 | Adapt to Plutus bindings Apr 17, 2023
@rphair
Copy link
Collaborator

rphair commented Apr 17, 2023

thanks @iquerejeta - I've removed [WIP] from title because people will recognise that from the current Draft review mode.

@rphair
Copy link
Collaborator

rphair commented Apr 17, 2023

also @iquerejeta (cc @michaelpj @dcoutts) do you think the scope of this update PR could be expanded a bit to include the suggestion in #220 (comment)?

@rphair rphair added the Update Adds content or significantly reworks an existing proposal label Apr 17, 2023
@iquerejeta
Copy link
Contributor Author

I thought about adding Duncan's comment in the CIP, and finally decided to simply include a reference to it. Do we want to add the full paragraph, or is a pointer sufficient here?
cc: @michaelpj

@michaelpj
Copy link
Contributor

I'll perhaps let the editors comment, but I think if it's part of the substantive rationale for why the CIP is good, it should go in the content of the CIP.

@rphair
Copy link
Collaborator

rphair commented Apr 19, 2023

yes, I was not being specific enough in #506 (comment) so yes I think what's stated in that text should be addressed in the text of this CIP. 🤓

Copy link
Collaborator

@rphair rphair left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@iquerejeta this was (due to its age I guess) scheduled for today's CIP meeting, but so we can have @michaelpj's review I've delayed it to CIP meeting # 69 in 2 weeks' time when we can also discuss #507.

Also it looks like your last few commits have cleaned up a few things as well as including the supporting material suggested above. So I hope it's OK that I take this out of Draft mode with the intention of reviewing online in the next 2 weeks & then again at the first CIP meeting in July when we'll have Plutus representation. cc @KtorZ

@rphair rphair marked this pull request as ready for review June 20, 2023 08:32
@rphair rphair added the Category: Plutus Proposals belonging to the 'Plutus' category. label Jun 20, 2023
@rphair
Copy link
Collaborator

rphair commented Jul 2, 2023

@iquerejeta this, with other Plutus items, is on the agenda for review early in the CIP editors' meeting Tuesday 04 July 16:00 UTC: https://hackmd.io/@cip-editors/69

@iquerejeta
Copy link
Contributor Author

In yesterdays CIP meeting, it was requested by @michaelpj to have a review on the compression rationale by @kwxm. However, I've seen that the commit of compression was coauthored by Kenneth. Nonetheless, Kenneth, could we get an explicit approval of that rationale in order to move forward with this PR?

@kwxm
Copy link
Contributor

kwxm commented Jul 5, 2023

I see that the link to this CIP on https://cips.cardano.org/ is broken. I think that it points to https://cips.cardano.org/cips/cip381 when it should point to https://cips.cardano.org/cips/cip0381, but I have no idea how to get it fixed.

@rphair
Copy link
Collaborator

rphair commented Jul 5, 2023

@kwxm ... @KtorZ did some work on this in #438 which fixed some link building issues (https://github.com/cardano-foundation/CIPs/tree/master/scripts), but apparently the three significant digits is a unique case that still doesn't work properly.

We have no issue (yet) like "Fix all the things on cips.cardano.org" although I think all prior PRs and issues can be found by working backwards from that PR. As it says in #436 (comment) we have a dependent issue delaying us from overhauling the code now, but maybe @KtorZ can do another band-aid fix like we had with #438 (I am lacking some prerequisites to do this myself).

Copy link
Contributor

@kwxm kwxm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine to me. I'm afraid I got a bit carried away spotting typos and things though. I agree that the rationale for using compression is sensible (although it was me that wrote it, so maybe I shouldn't be approving it).

* `BLS12_381_G2_neg :: BLS12_381G2Element -> BLS12_381G2Element`
* `BLS12_381_H2G2 :: ByteString -> BLS12_381G2Element`
* `BLS12_381_GT_mul :: Blst12381GTElement -> Blst12381GTElement -> Blst12381GTElement`
* `bls12_381_G1_add :: bls12_381_G1_element -> bls12_381_G1_element -> bls12_381_G1_element`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The function types here are all Haskell types, which are slightly different from Plutus Core types (or at least have different names). I'm not sure which ones we actually want here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should have the names that will be used by plutus script developers. I thought we did modify this, but could you provide a pointer to the plutus names please?

Copy link
Contributor

@kwxm kwxm Jul 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you go into the plutus repo and type cabal run uplc print-builtin-signatures it'll show you the names and types of all the built-in functions. I've attached the info for the BLS functions below. Note that it has signatures like

bls12_381_G1_add : [ bls12_381_G1_element, bls12_381_G1_element ] -> bls12_381_G1_element

The notation here is non-standard but matches what we have in the Plutus Core specification. The stuff in square brackets represents the types of the arguments, not some list type. It's like that to make the notation in our spec less ambiguous (if you've got lots of arrows it's not clear where the input types stop and the output type starts). I'm not sure if you should put types like that in the CIP though.

Here's the full list:

bls12_381_G1_add                   : [ bls12_381_G1_element, bls12_381_G1_element ] -> bls12_381_G1_element
bls12_381_G1_neg                   : [ bls12_381_G1_element ] -> bls12_381_G1_element
bls12_381_G1_scalarMul             : [ integer, bls12_381_G1_element ] -> bls12_381_G1_element
bls12_381_G1_equal                 : [ bls12_381_G1_element, bls12_381_G1_element ] -> bool
bls12_381_G1_hashToGroup           : [ bytestring, bytestring ] -> bls12_381_G1_element
bls12_381_G1_compress              : [ bls12_381_G1_element ] -> bytestring
bls12_381_G1_uncompress            : [ bytestring ] -> bls12_381_G1_element
bls12_381_G2_add                   : [ bls12_381_G2_element, bls12_381_G2_element ] -> bls12_381_G2_element
bls12_381_G2_neg                   : [ bls12_381_G2_element ] -> bls12_381_G2_element
bls12_381_G2_scalarMul             : [ integer, bls12_381_G2_element ] -> bls12_381_G2_element
bls12_381_G2_equal                 : [ bls12_381_G2_element, bls12_381_G2_element ] -> bool
bls12_381_G2_hashToGroup           : [ bytestring, bytestring ] -> bls12_381_G2_element
bls12_381_G2_compress              : [ bls12_381_G2_element ] -> bytestring
bls12_381_G2_uncompress            : [ bytestring ] -> bls12_381_G2_element
bls12_381_millerLoop               : [ bls12_381_G1_element, bls12_381_G2_element ] -> bls12_381_mlresult
bls12_381_mulMlResult              : [ bls12_381_mlresult, bls12_381_mlresult ] -> bls12_381_mlresult
bls12_381_finalVerify              : [ bls12_381_mlresult, bls12_381_mlresult ] -> bool

@rphair
Copy link
Collaborator

rphair commented Jul 11, 2023

@iquerejeta this is on our next CIP meeting # 70 agenda as Last Check, probably because @kwxm's review looks well accommodated by the last round of commits... can you confirm currently unresolved #506 (comment) has been addressed? 🙏 https://hackmd.io/@cip-editors/70

@rphair rphair added the State: Last Check Review favourable with disputes resolved; staged for merging. label Jul 11, 2023
Copy link
Collaborator

@rphair rphair left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@iquerejeta as far as I can tell this had been revised according to @kwxm's audit, including the costing details that were requested in earlier meetings, so I'm going to try to get one more editor endorsement at today's CIP meeting so we can merge this on this spot if possible & soon afterward if not. 🚀 cc @KtorZ @SebastienGllmt @Ryun1

Copy link
Collaborator

@Ryun1 Ryun1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - final last check from Plutus team was positive, good to merge 🤓.

@rphair rphair merged commit 797cdc6 into cardano-foundation:master Jul 18, 2023
Ryun1 pushed a commit to Ryun1/CIPs that referenced this pull request Jul 28, 2023
* Adapt CIP to Plutus bindings

* Add dcoutts' analysis on blst library

* Include motivation for using compressed over decompressed form

Co-authored-by: Kenneth MacKenzie <[email protected]>

* Modify hash-to-curve to include DST

* Include instructions for DST > 255 bytes

* Address review comments

---------

Co-authored-by: Kenneth MacKenzie <[email protected]>
Ryun1 pushed a commit to Ryun1/CIPs that referenced this pull request Nov 17, 2023
* Adapt CIP to Plutus bindings

* Add dcoutts' analysis on blst library

* Include motivation for using compressed over decompressed form

Co-authored-by: Kenneth MacKenzie <[email protected]>

* Modify hash-to-curve to include DST

* Include instructions for DST > 255 bytes

* Address review comments

---------

Co-authored-by: Kenneth MacKenzie <[email protected]>
@rphair rphair removed the State: Last Check Review favourable with disputes resolved; staged for merging. label Sep 3, 2024
@euonymos
Copy link

euonymos commented Sep 9, 2025

We do not include the type of the Scalar, nor operations related to it. These type of operations can already be performed with the Integer type.

@iquerejeta, it would be very nice if you happen to remember the motivation regarding why this decision was made. Looks like in some cases (we particularly use a pairing-based accumulator to represent L2 UTxO state in the Hydrozoa project), we do want to do quite extensive arithmetic over the scalar field, and I would like to know more about this.

@iquerejeta
Copy link
Contributor Author

iquerejeta commented Sep 9, 2025

Back when this primitives were added, the priority of the team was to reduce the number of primitives available in Plutus. That's the only reason why we decided not to expose operations over the Scalar field or target group, as well as other operations like MSMs.

There recently was a PR merged to add MSMs.

@perturbing
Copy link
Collaborator

perturbing commented Sep 9, 2025

we do want to do quite extensive arithmetic over the scalar field, and I would like to know more about this.

Can you share some code/benchmarks as to what part makes it expensive?

Also note that there will be a new built-in for modular exponentiation (already in plutus), which will make your life easier and most zk applications cheaper.

@euonymos
Copy link

@perturbing, I opened PR #1087; the draft contains the benchmarks. I am looking forward to hearing your thoughts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Category: Plutus Proposals belonging to the 'Plutus' category. Update Adds content or significantly reworks an existing proposal

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants