Please describe your proposed solution.
I'm sure many o you knows about the fact that the code that runs on the Cardano nodes when validating a transaction that contains a smart contract input is not written in Haskell
, rather Haskell
compiles to Untyped Plutus Core
thanks to some libraries.
so the code is actually written in Untyped Plutus Core
, which is meant to be a compilation target
fortunately for us the plutus core specification is clear about the language ( if that is not the case you can find a Plutus core specification paper walkthrough in the plu-ts repository )
this allows us to understand how to create a representation of Untyped Plutus Core
potentially in any language, in this case Typescript
once we are able to get a Untyped Plutus Core
representation the Appendix D tells us how to serialize it in order to be submitted with the transaction.
from this point on it is already possible to write smart contracts in Typescript; however, this approach would be too low-level for practical usage.
for this reason a substantial part of the project is to build an API on top of this core concept, possibly emulating the Haskell
's PlutusTx
API.
Please describe how your proposed solution will address the Challenge that you have submitted it in.
the challenge approval would allow for the creation of a tool that has the potential to be used by a wide community of developers
this tool would also allow for existing dApp developers to generate smart contracts client-side, resulting in truly decentralized applications that could even be served statically
What are the main risks that could prevent you from delivering the project successfully and please explain how you will mitigate each risk?
at the moment, there is no flat
serialization library for Typescript or Javascript,
this is an issue since the haskell
UPLC serialization implementation heavily depends on the library
the reason for this is that the haskell
equivalent leverages the builtin Haskell type class of Generics
in order to have an idea of the data structure to serialize
there are 2 potential solutions to this
- reimplementing
flat
from the bottom up (not convenient) - implementing a specialized subset of
flat
in order to be able to work only with what is needed for the UPLC AST (see plu-ts/docs/proof-of-concept/notes/Appendix D.md file to understand how this would be achieved )