-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CIP-0097? | Representing the Script Context as a SOP term #507
base: master
Are you sure you want to change the base?
CIP-0097? | Representing the Script Context as a SOP term #507
Conversation
What is blocking us from simply making handling |
Now that I understand how SOPs will work in the vm. I'll make some examples comparing and contrasting using data in Aiken vs using sop in Aiken. That way I can show off use case costs. Gonna work on the these examples this week. |
2. Translating ("decoding") the script context into a native form ([Scott encoding][] or SOPs) is far too slow because of 1 and because script contexts become large | ||
|
||
These combine to make decoding real world script contexts prohibitive in many cases: | ||
budget profiling of examples in `plutus-use-cases` that naively decode the script context revealed that many were spending 30-40% of their budget just on the decoding step, which is unacceptable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do these tests have been performed only on scripts generated using PlutusTX?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that only PlutusTx (as far as I know?) is trying to translate the script context into some intermediate representation, I'd assume that yes.
So it could be interesting to get some before/after benchmarks for solutions like Plu-ts or Aiken regarding the impact of using SOP vs Data. Though, if the script context still comes in the form of (forget that last bit, my mind was still on CIP-0085 for a second; this proposal here is precisely about representing the script context as a SOP)Data
from the ledger, I believe that the overhead of turning a Data
into a SOP will be still high.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is really only for people who actually try to convert the script context into another form. Although I do still think this is desirable - it's just obviously too expensive to be worth it at the moment.
So the numbers here are more meant to indicate how unacceptably high the cost is, not to argue that these are reductions that real users might see (the test cases in question are not real). I can see that's misleading, I'll rephrase.
The full specification of the new translation is to be determined in collaboration with the ledger team, but broadly: | ||
- Integers and bytestrings are translated to Plutus Core integers and bytestrings instead of using the `I` and `B` Data constructors. | ||
- Constructors are translated to Plutus Core `constr` terms instead of using the Data `Constr` constructor. | ||
- Uses of the `Map` and `List` Data constructors will need more specific handling but will be translated in line with their underlying dataype representation in Plutus Core. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious on the current approach to handle maps and lists. Has this been fleshed out anymore?
Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com>
I like SOP for its fast destructuring, but the problem is the blocker on missing out equals data and serialise_data. As a different compromise how about a new builtin that is similar to case. Say case_constr. Takes in a constant of type data that is a constr and any term. Then it applies all field arguments from constr plus the constr index to that term. Then that single term can handle constr index and whatever fields it has applies. The current approach is to unconstr_data then fst_pair to check index, then access each field by doing some combination of head_list and tail_list. This is vastly improved by only requiring one builtin to get a constr index and its fields from a constant data that is type constr. Now I know this step is computationally more expensive than SOP. But since we have a lot of builtins that operate on data, I wonder if operating on data in a more efficient way might be the solution. Even converting script context to SOP does not change that we still need better ways to operate on data because of datum, redeemer, and script context still has data fields in datums, inputs, outputs, and redeemers fields. Here's an example @michele-nuzzi
this evaluate to
you could imagine other_term is:
EDIT: and perhaps this builtin should be moved to a new CIP, but the more I think about it, even with SOP, the more essential a builtin like this is. |
not sure |
Typically I am seeing dApps that have use cases that check values, addresses, and datums of outputs against input. I'll come back and clarify some more in a bit but here's what I got. Common Cases where I see SOP as more efficient:
Common Cases where I see SOP as less inefficient:
Cases where SOP has no effect: |
It would be more efficient than having to do head and tail list to get each constr field and get the constr index. |
@@ -0,0 +1,205 @@ | |||
--- | |||
CIP: ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CIP: ? | |
CIP: 97 |
(just noted this on Discord but probably better to address here) @michaelpj would you come to our next CIP meeting - currently scheduled 20 June, 9:30 am UTC - to review this & invite any other Plutus representatives you think would have a stake in that issue? (cc @L-as) |
Could I get an invite @rphair? The discord links don't work for me. |
yes @MicroProofs it would be good to have you there 🤓 https://discord.gg/kyaTyzkBqd |
p.s. @MicroProofs seems @michaelpj is unavailable for meeting this month so we have bumped the discussion until meeting # 69 (which if regularly scheduled would fall on 04 July). |
I don't think we should do this. Being able to hash the script context is highly convenient for evaluating snarks on it, since you can use the hash of the script context as a circuit witness trivially this way. If you can't hash it cheaply, it gets an order of magnitude harder, which is not nice. The real issue is that the Plutus interpreter is unperformant. |
@michaelpj @L-as @MicroProofs @michele-nuzzi 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 |
Michael is on leave, so I attempted to join instead of him, but it seems I wasn't let in. If you have any questions, I'd be happy to try to answer them, although I'm not sure what medium we should use. |
Are you talking about "let in" to Discord? If not, here's the invite link: https://discord.gg/kyaTyzkBqd ... if so, I don't see any problems reported in the |
No, I took a meeting from Michael's calendar. Sorry, I should've just asked here. Thank you for the clarification. I've now joined the Discord server.
Unfortunately, in 2 hours from that moment (i.e. now in an hour) I'm going to be traveling likely without access to the Internet. I'll try to make it, but chances of that are not high. |
Tagging |
This is the other part split out from #455 that talks about changing the representation of the script context to be a SOP term rather than
Data
. It depends on CIP-85.(rendered proposal in branch)