CIP-0118: Some small comments #1000
Replies: 2 comments 1 reply
-
@kevinhammond I don't know what practical difficulty that could possibly be, because all PRs are on user forks & so therefore is this one: #862 The only thing unusual about the branch is that @polinavino put a In fact we have to require this because otherwise this CIP's review would be impractically fragmented. So @kevinhammond could you try posting the comments above back in that thread & let us know exactly what difficultly you might have after that point? To avoid that fragmentation we won't be able to continue the usual technical review in this "Discussion" thread... but we can certainly use it to help with whatever UI problem you were seeing. |
Beta Was this translation helpful? Give feedback.
-
@kevinhammond it was good to see that your comments could finally be added here: #862 (comment) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I can't see how to contribute on the draft CIP itself (seems to be on a fork?).
Overall, the new version (nested transactions) looks good to me. I had a few small comments
A detailed worked example would be helpful (i.e. what would a nested transaction actually look like for e.g. a swap). It's possible to get a reasonable idea, but the detail would help people who were using this, I expect - it's a relatively complicated feature
I thought a bit about Peras and Leios. I don't immediately see that any specific change is needed for either (Peras just certifies blocks, Leios will only directly consider whole transactions [obviously you have to worry about reordering/cons)
It wasn't obvious to me whether there were any ordering constraints for sub-transactions. I assume there will be, since the CIP talks about iterating over sub-transactions, and there would presumably need to be some kind of dependency analysis/recursion breaking if not
I always worry about limit cases. The obvious one here is where you have empty constraints for some/all of the sub-transactions. I don't see that there will be a problem, but it's always worth considering
I assume that native scripts will still work as normal
The high level language for constraints would certainly be useful (especially for Plutus scripts). I can see this as being quite tricky to work with otherwise
I assume there won't be any complications when adding new Plutus versions (e.g. if there's a Plutus V5 that changes some of/adds new script purposes)
Are the script purposes mutually exclusive? I think that's assumed here
Beta Was this translation helpful? Give feedback.
All reactions