Skip to content
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

FR: Add support for OpShin scripts (including evaluation internally) #105

Open
nielstron opened this issue Oct 24, 2022 · 2 comments
Open
Labels
enhancement New feature or request Feature request

Comments

@nielstron
Copy link
Contributor

nielstron commented Oct 24, 2022

Is your feature request related to a problem? Please describe.
Cardano developers may have a hard time debugging their script, as they need to understand the whole Haskell/Pluto stack.

Describe the solution you'd like
Imperator/pyscc provides a compiler from a subset of Python into UPLC, in other words a programming language for Smart Contracts on Cardano, that IS python.

When adding an Imperator script as a script input to a transaction in pycardano, this means that we could offer to evaluate the script during transaction building and signing. This includes being able to step through the Script as it is being evaluated with a normal python debugger.

What we need for this?

  • A flag to signify an added script input is actually an imperator script (and the corresponding source file)
  • A hook inside the transaction builder that calls the imperator script with the correct parameters (i.e. ScriptContext etc)
  • Optimally: Imperator/pycardano using the same definition for PlutusData

Describe alternatives you've considered
None

Additional context
I am developing Imperator/pyscc and can provide the parts of support that are needed on that end. Currently, I am looking into integrating the pycardano definitions of PlutusData and looking for a place where I could add the evaluation hook.

@cffls cffls added enhancement New feature or request Feature request labels Oct 24, 2022
@cffls
Copy link
Collaborator

cffls commented Oct 24, 2022

Thank you @nielstron, what an excellent idea! This will definitely be the killer feature. 🚀

Regarding the points you made, here are my thoughts:

  • A flag to signify an added script input is actually an imperator script (and the corresponding source file)
    The plutus script is currently stored and passed around as bytes. If I understand correctly, the purpose of passing imperator source file is to make debugging easier?
  • A hook inside the transaction builder that calls the imperator script with the correct parameters (i.e. ScriptContext etc)
    We can also consider adding the hook in chain context, which already exposes an evaluation interface, evaluate_tx. Currently, the underlying implementation calls script evaluation through Ogmios or Blockfrost. We can add a new parameter, e.g. imperator=True, to this function or the constructor of chain context, which will enforce the evaluation to run through a local imperator. With this approach, it will also be easy to construct the script context inside evaluate _tx, because chain context is capable of providing full information for any utxo and protocol parameters.
  • Optimally: Imperator/pycardano using the same definition for PlutusData
    Agree 100%.

Thank you again for integrating Imperator with PyCardano! I am more than happy to help with design or implementation. Also, amazing works on Imperator. It is definitely a treasure to Cardano Developer ecosystem.

@nielstron
Copy link
Contributor Author

eopsin is one of the Imperator languages that is now ready to be integrated. It naturally uses PlutusData definitions from pycardano to define internal datatypes.

https://github.com/ImperatorLang/eopsin

@nielstron nielstron changed the title Add support for Imperator scripts (including evaluation internally) FR: Add support for OpShin scripts (including evaluation internally) Apr 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Feature request
Projects
None yet
Development

No branches or pull requests

2 participants