IntersectMBO / IntersectMBO/plutus

Investigate automatic explanation of Plutus script evaluation result

Open
#6,116 0 comments 0 reactions 0 assignees View on GitHub
Evaluation Low priority status: triaged User experience
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.