CIP-0122? | Logical operations over BuiltinByteString

[kozross]

This CIP describes several operations over bits, including AND, OR and XOR, as well as indexing, setting, and clearing, operating on BuiltinByteString. Additionally, it provides a 'replication' operation to produce a BuiltinByteString of a given length full of identical bytes.

Human-readable form

[rphair]

thanks @kozross, looks great - please keep us updated in PR comments about how the path-to-active progresses. 🙏

@michaelpj @zliu41 can you review this? I've added to the agenda for introduction at the next CIP Editor meeting: https://hackmd.io/@cip-editors/88

[Ryun1]

@michaelpj @zliu41 comment would be appreciated

[michaelpj]

Good work as usual! I'm basically happy with this.

[rphair]

@kozross excellent response to this at the CIP Editors' Meeting on Tuesday of this week. Editors (cc @Ryun1 @Crypto2099) will look to responses to points from @michaelpj's #806 (review) to see what to do next.

re: my #806 (review) about Path to Active, it looks good to me now... althrough if you think those bulleted items might progress intermittently I would suggest turning them into tickboxes.

[rphair]

Looks good as of ef3ecb9 & will invite other editors to confirm.

[kwxm]

I was looking at this while I was reviewing the implementation and added a few comments about fairly superficial things, most of which don't need any response. I didn't check things like the details of the semantics: I'll try to come back and review it more thoroughly later.

[kwxm]

One advantage of failing is that you'd find out immediately if something's the wrong length. When padding/truncation happens automatically a single input of the wrong length in a long chain of calculations will propagate through to the very end and it might be difficult to work out where the problem originated. That's just a comment however: I'm not going to insist that the choice made here is the wrong one.

[kwxm]

I think this is a good choice! I'd initially assumed that you'd have to do these things a bit at a time, and the resource bounds on on-chain scripts would really reduce the usefulness in that case. Allowing a list of updates is a neat solution to that.

[kozross]

Thanks! I came at it from the point of memory use: if you're forced to copy something 10 times to change 10 bits, this is quite bad in a setting where you have limited resources.

[kwxm]

A very pedantic comment: in Plutus Core the types are called bytestring, integer, and so on: see the Plutus Core specification. BuiltinByteString, BuiltinInteger etc are Haskell types in PlutusTx, which are not the same thing, and may not be meaningful to implementers of other languages targeting Plutus Core. I don't think it's necessary to change the notation though, since it's pretty clear what's going on (and I think the same notation was used in the integer/bytestring conversion CIP and nobody noticed). It might also be argued that the document should use the Plutus Core syntax ((con bytestring #123456) and so on) but that would require a lot of work and would just make the document much less readable. I think the mapping between the Haskell-type notation here and the lower-level syntax for Plutus Core should be pretty clear.

[kwxm]

Now I'm wondering what "Plutus" really means in this document. Our names are a bit confusing and strictly there's no such thing as Plutus: there are only (typed and untyped) Plutus Core and the Haskell thing called PlutusTx. There's a suggestion that we should reduce confusion by reserving the name "Plutus" for the thing that runs on the chain (ie, untyped Plutus Core) and rename PlutusTx to something else. I don't know when (or if) that's likely to happen though.

[kozross]

This is a good point more generally: some clarity in what terms we use in CIPs would be good to have, similar to how something like RFC-2119 specifies what certain words mean exactly and standardizes their use.

[kozross]

@Ryun1 - I believe I have addressed your concerns now.

@kwxm - thanks for catching two quite confusing mistakes on my part. I have now fixed these, and hopefully clarified my intent with both.

[rphair]

@kozross we were ready to merge this at tonight's CIP meeting but first we need you to change the proposal document name from the current CIP-0122.md to README.md.

[kozross]

@rphair - done. Sorry for the confusion on my part.