[IMPACT] 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.
[IMPACT] 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
[IMPACT] 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
flatfrom the bottom up (not convenient) -
implementing a specialized subset of
flatin 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 )[FEASIBILITY] Please provide a detailed plan, including timeline and key milestones for delivering your proposal.
estimated total of 8 months
- UPLC AST implementation (3 weeks)
including:
- actual implementation
- test coverage
- UPLC AST initial, low-level, utility functions (4 weeks)
including:
- actual implementation
- test coverage
- UPLC AST serialization (5-8 weeks)
including:
- lat``` implementation
- test coverage
- high-level functions and classes implementation (with test coverage) ( 3-4 months )
- critical code audit ( 1-2 weeks )
> from the moment that there is a separated (but related) off-chain proposal for the same library with a similar timeline, in the evenience of both passing there are two options to distruibute the load:
- expand the team right-away
- pause temporarily one of the two proposals to first complete the other (summing up the timelines)
[FEASIBILITY] Please provide a detailed budget breakdown.
> based on salary.com stats
> ( 32 $/h * 8 h/day * 30 day/month * 8 months )
61'440 $ for 8 months full-time development
> based on the same logic of above, assuming maintainance is less intesive, covering 3 months for reference
> ( 32 $/h * 5 h/day * 30 day/month * 3 months )
14'400 $ for repository maintenance over time
> this cost is present since, being plutus a relatively new tool, the smart contract creation details on cardano are constantly evolving, the amount should cover any additional and critical development update without the need to re-create a found request for it
30'000 $ for critical code audit
> where for "critical code" is meant code that is responasabile for smart contract compilation and Abstract Syntax Tree creation
> only "critical code" is covered since auditing repositories tends to be costly,
> In the case of a necessity for a more in depth audit comes out, a new catalyst proposal will be made.
[FEASIBILITY] Please provide details of the people who will work on the project.
to start up the project and minimise costs (maximizing the chances of being founded) the "team" will be constituted of only one person
> in the evening of the proposal passing a dedicated one could be proposed in found 10 for team expansion
unfortunately, I'm not very active on LinkedIn etc.
useful links are:
-
[FEASIBILITY] If you are funded, will you return to Catalyst in a later round for further funding? Please explain why / why not.
as explained there might be other following proposals to improve the project:
- team expansion
- in dept code auditing and verification
> IMPORTANT NOTE: the founds requested should be enough for the project completation as-is, those are "only" improvements that would be made
[AUDITABILITY] Please describe what you will measure to track your project's progress, and how will you measure these?
the project will be opensource, therefore verifiable by anyone with an internet connection
updates will be published on my Youtube channel with (possibly) weekly videos
and on my Twitter profile
[AUDITABILITY] What does success for this project look like?
The ideal goal would be to see 1 or 2 major projects taking advantage of client-side smart contract creation
other important goals are:
-
Developer adoption (do developers use this tool?)
-
Developer migration (people developing on chains using different languages for smart contract creation will find this option as easy to use?)
[AUDITABILITY] Please provide information on whether this proposal is a continuation of a previously funded project in Catalyst or an entirely new one.
this proposal IS NOT a continuation of a previously funded project