IntersectMBO / IntersectMBO/plutus
Investigate automatic explanation of Plutus script evaluation result
- Dominant language
- Haskell
- Stars
- 1.6k
- Forks
- 508
- Avg merge
- 3d 10h
- Merged PRs (30d)
- 22
Description
It would be nice to have a form of the CEK machine that can automatically generate a readable summary explaining why evaluating a script failed or succeeded. This is useful because some developers may not find Plutus Core programs to be highly readable (Plutus Core is analogous to the assembly language for Cardano). A Plutus Core program is often much larger than the corresponding Plutus Tx source code, and developer tools such as syntax highlighting are lacking at this time. The ability to step through it or set breakpoints may not be helpful for someone if the code is not even comprehensible.
Automatic explanation of the output of a program (even a non-terrible, somewhat useful, best-effort approach) is extremely difficult for general purpose programming languages, but it might be attainable for Plutus Core because (1) Plutus Core is a small enough language, and (2) it is used for one purpose, and one purpose only: returning a boolean value given datum, redeemer, and script context. There is a body of research on explaining the results of query languages like SQL (e.g., "[Why Not?](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.227.6569&rep=rep1&type=pdf)"), which we can potentially learn from.
Notes:
What kind of output are you expecting here?
One thing we could definitely do (and this fits into the debugging story) is to explain why we got an error by pinpointing where it came from (if you have source mapping information). But I’m not sure how much we can say about how we got there.
The ability to step through it or set breakpoints may not be helpful for someone if the code is not even comprehensible.
That’s why we’d need source mapping! You want to set breakpoints in your Haskell code and step through your Haskell code, even if under the hood that’s operating on UPLC.
Contributor guide
Research direction
The issue names no files, tests, or entry points. Start by examining the CEK machine and the source-mapping and debugging discussion, then clarify what explanations and failure locations should be supported. Done would require an agreed scope and design for readable Plutus Core evaluation results.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- haskell
- Domain
- blockchain, compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100