MLabs - Plutarch v2

[IMPACT] Please describe your proposed solution.

Proposal Background

This is the second funding round for the Plutarch project, which received initial funding from Catalyst in Fund8. Currently, several features promised in the Fund8 proposal are implemented while others are still underway. After early marked success, the current proposal details the scope and impact of Plutarch 2.0.

Market

Developers and auditors building out the Cardano ecosystem and verifying the security of dApps

Problem Space

Cardano features powerful smart contracts, however, the limits of smart contracts are very tight. Transactions must at most be 16 KiB, which limits the size of scripts heavily, in addition to having very tight memory and CPU budgets, such that the computational work possible is also tightly limited. These constraints are here for a very good reason, and raising them isn’t a viable long-term solution.

Unfortunately, however, Plutus Tx (the tool to compile Haskell to Plutus) is not up to the task.

The Plutus Compilation Pipeline and Plutus Tx Pain Points

As is widely appreciated, smart contracts on Cardano are written in Haskell, a functionally pure programming language. Historically, the Plutus Tx library is a key component of the compilation pipeline. This process has several steps:

1. GHC: Haskell -> GHC Core
2. Plutus Tx compiler: GHC Core -> Plutus IR (Like TPLC but has data types)
3. Plutus IR compiler: Plutus IR -> Typed Plutus Core (TPLC, variant of System Fωμ)
4. Type eraser: Typed Plutus Core -> Untyped Plutus Core (UPLC)

Although it plays a crucial role here, the Plutus Tx compilation library has several shortcomings. Notably, it:

• Forms an opaque barrier between Haskell and Cardano’s native scripting language (Plutus Core)
• Supports only a small subset of Haskell
• Extensively relies on the INLINEABLE pragma making the majority of existing Haskell libraries unusable
• Produces extremely complicated error messages
• Makes it difficult to use abstractions due to overhead added to the resulting code
• Silently changes the semantics of Haskell code turning function applications strict
• Sensitive to different compilation methods (e.g., cabal build vs cabal repl)
• Can result in inefficient compilations wasting precious transaction space
• Does not allow for fine-tuned control of Plutus Core
• Can result in hard-to-decipher downstream behavior
• Does not erase type abstractions (they get turned into a “delay”)

Most importantly, inefficiencies inherent in Plutus Tx ultimately constrain the features of dApps and raise unnecessary hurdles for developers. Some of these issues are solvable, but many of them are inherent to the approach, as it is not an eDSL.

Optimizations using Plutarch

Plutarch is a typed eDSL in Haskell for writing efficient Plutus Core validators. The v1.0 introduced several optimizations into the development process by offering developers fine-grained control of the Plutus Core they generate. In fact, a ~75% decrease in CPU, memory, and script size is commonly achievable without giving up valuable type information.

The Plutarch GitHub repo provides a thorough overview and how-to for the eDSL. Essentially, Plutarch allows Plutus developers to leverage the beneficial features of Haskell without losing the ability to compile. Plutarch achieves this sleight-of-hand by wrapping data structures in a computational context that mimics mutable state. This allows for type-level operations to occur without manipulating UPLC, the target language of the compilation pipeline mentioned above. Plutarch’s simple type system can then be easily bridged to UPLC during compilation.

Plutarch v1 has been used by several prominent projects and organizations:

• Ardana Labs – Decentralized stablecoin hub
• Minswap Team – Multi-pool decentralized exchange
• Liqwid Labs – Interest rate protocol
• Platonic.Systems – Haskell and Plutus consultancy
• MLabs – Haskell/Plutus, Cardano, and blockchain consultancy
• Genius Yield – All-in-one DeFi Platform
• And others

What were the results of the Fund8 grant?

As mentioned, the first-round grant for Plutarch, posted by our co-contributor and close partner Liqwid, was successfully funded in Fund8. Largely, the grant covered the basic functionality of the eDSL:

• Haskell numeric hierarchy support
• Enhancing testing and benchmark tools
• Implementing helper functions
• Creating and managing Stake Validators
• Technical documentation, and so on

Since the proposal was initially listed in March 2022, we have continued developing Plutarch and are pleased to report significant progress with:

• Testing and benchmark tools
• Significant additions to the set of helper functions
• Managing Stake Validators
• Technical documentation
• Numeric optimizations
• Improving the test spec
• Optimizing resource utilization
• Compatibility with GHC 9.2

Work remains surrounding:

• Extending the Plutarch API functionality
• Incorporating the latest CIPs of the upcoming Vasil HFC

While these achievements represent substantial gains for the Cardano ecosystem, expanding the scope of the Plutarch project will provide even greater benefits to dApps and organizations building in the space.

[IMPACT] Please describe how your proposed solution will address the Challenge that you have submitted it in.

Our Proposal

The Cardano ecosystem is young and underdeveloped. This is readily apparent considering the degree of tooling available to developers. The outsized improvements possible with Plutarch v1.0 represent the degree to which these types of optimizations are possible.

This proposal is intended to support further development of the Plutarch project to make it more useful to auditors and other participants. Planned feature updates for Plutarch 2.0 include:

• Plutus IR backend – Improves code auditability. This backend is similar to the existing single backend for Plutarch v1, albeit it preserves types. Auditors like Tweag necessarily depend on this information for their automated auditing tools like Pirouette.
• Haskell backend – Will facilitate reuse of Plutarch on-chain code in Haskell off-chain code and eliminates the need to duplicate function definitions and data type definitions (e.g., once for off-chain code, once for Plutarch). This way developers can use Plutarch with GHC 9.2, compile the Plutarch data types and functions into GHC 8.10 Haskell, and use it with PAB, Plutip, or similar solutions.
• PureScript backend – A PureScript backend offers the same capabilities but in the browser. This allows developers to use the same logic with the Cardano Transaction Library and avoid reimplementations, i.e. data types and functions can be shared.
• Generalised effect system – UPLC does in fact have an effect: erring. Reasoning about partial functions has proven difficult in practice since it is not clear from the type whether a function is pure or not. Plutarch v2 takes this to the next step and designs a generalised effect system that is ergonomically similar to MTL.

Other improvements include:

• JavaScript backend
• TypeScript backend
• Same data type definition for Data-encoded and Scott-encoded types
• Higher higher-kinded data
• Ergonomic and efficiency improvements
• No accidental duplication of terms
• Ability to embed more powerful "types" into the language which will throw descriptive errors at Plutarch compilation time
• Easy to extend language
• Easy nested matching
• Zero-cost optics
• Symbolic evaluation

[IMPACT] What are the main risks that could prevent you from delivering the project successfully and please explain how you will mitigate each risk?

Plutarch is extensively developed and widely used in production – as such, we do not expect undue difficulty in implementing the features highlighted above. While highly useful, however, Plutarch involves specific training and a non-trivial amount of on-ramping for developers to become fluent in its use. This friction is exacerbated by the limited backend support. Smoothing out this learning/adoption curve is likely the most significant challenge of this proposal. We are well aware of this and are focused on usability and practical improvements to streamline the process for developers.

[FEASIBILITY] Please provide a detailed plan, including timeline and key milestones for delivering your proposal.

1 Month:

Expand backend support to include Plutus IR and the other languages mentioned, start the process of feature optimizations and usability improvements. Reconfiguring data types and effect system.

4 Months:

Backend support for mentioned languages largely, if not completely, accomplished. Moderate optimizations completed with more ongoing. Begin work on state machine support and optimization.

8 Months:

Proposal deliverables largely accomplished with minor optimizations ongoing. Pretty printing intact and incorporation of the Spec Language project largely underway.

[FEASIBILITY] Please provide a detailed budget breakdown.

Engineering hours: 913

Total: $73,040

Breakdown:

Feature Total Time

Plutus IR Backend 120

Haskell Backend 120

PureScript Backend 120

Data Type and Effect System Improvements 100

Efficient State Machine 90

Incorporating the Plutus Specification Project 60

Pretty Printing 80

Ergonomic Improvements 110

Subtotal 800

Change Budget 113

Total Time 913 hours

Total Cost $73,040

[FEASIBILITY] Please provide details of the people who will work on the project.

MLabs

MLabs has quickly become one of the premier development firms in the Cardano Ecosystem. We are an IOG Plutus Partner and work regularly with IOG to develop the Cardano blockchain and ecosystem. Our team is composed of talented developers who have helped build community projects such as:

• Liqwid
• SundaeSwap
• Minswap
• Optim
• Many others

Through our work with early-stage projects, we have one of the largest groups of Haskell/Plutus developers in the community.

Website: https://mlabs.city/

Core Team

Compilers and Formal Methods

Las Safin

Las is a software engineer and formal methods specialist who is experienced with dependently typed languages such as Idris and Agda and who is interested in Cedille. At MLabs, he helps manage Nix environments for use in development and writes application specifications as well as compilers.

Las has also made significant contributions to Cardano tooling. Most notably, he is the creator of Plutarch. Plutarch is a typed eDSL in Haskell for writing efficient Plutus Core validators. Plutarch significantly lowers the resource demands of validators written in the eDSL while providing developers more fine-grained control of the Plutus Core generated. See the GitHub link for more information.

Plutarch: https://github.com/Plutonomicon/plutarch

GitHub: https://github.com/L-as

Performance Optimization and Type systems

Chase Maity

Chase is a polyglot software developer with expertise in Haskell and C. He’s interested in type systems, programming language design, and performance-optimizing compilers. At MLabs, he has worked on both on-chain Plutarch code and off-chain smart contracts; as well as providing technical specialist assistance on Plutus Core and its intricacies. Outside of MLabs, Chase spends time contributing to open source, and learning more about Haskell and type systems.

Chase is also a core contributor to Plutarch, having been a close contributor since before the 1.0 release. He was also the writer of the first Plutarch validator to be used in production, through the Minswap project. Currently, Chase aims to help Plutarch achieve even higher limits both in terms of ergonomics and in terms of on-chain efficiency.

GitHub: https://github.com/TotallyNotChase

Senior Haskell Developer

Mario Blažević

Mario is a software developer with experience in programming language design and development, including standalone compilers, VMs, and embedded languages. He also has a long history as a Haskell developer and open-source contributor, as well as more recent experience as a Cardano

developer. See his GitHub link for more information.

GitHub: https://github.com/blamario

[FEASIBILITY] If you are funded, will you return to Catalyst in a later round for further funding? Please explain why / why not.

This is possible but remains to be determined. This version is the next iteration of Plutarch, a typed eDSL for writing UPLC that offers dApp developers dramatic gains. The features outlined in this proposal comprise a complete release, however, we will continue to upgrade the product in line with community feedback. In so doing, we may support further features and functionality upgrades per this community input by applying again to future Catalyst rounds.

[FEASIBILITY] Are you or any member of your team working on any other proposals in this Fund9?

[FEASIBILITY] Are you or your team working on any other proposals from previous Funds?

[AUDITABILITY] Please describe what you will measure to track your project's progress, and how will you measure these?

Please describe how you will measure the progress and the development of the project?

Intended Fund – Fund9: Developer Ecosystem

Challenge Statement: “How can we create a positive developer experience that helps the developer focus on building successful apps?”

Project Impact: High

Usability: Plutarch will help builders create more expressive smart contract applications while adhering to the resource limitations of Cardano. Moreover, features included in v2.0 will help auditors ensure dApps are correctly implemented and in general make the eDSL easier to use.

Open Source Tooling: Plutarch v2.0 will be open source and freely available for developers to use

Cost-Effective Development: dApps running on Cardano require substantial upfront costs for development. Streamlining the engineering process will result in substantially reduced costs and faster times to market.

As Plutarch is an open-source effort, the GitHub repo is available to the public. It will also serve as a transparent auditing source. For less technical community members, we will provide regular project updates via Medium articles as well as our social channels.

KPIs (Key Performance Indicators)

-general reduction size in script execution size achievable

-number of projects benefiting from Plutarch optimizations

-number of commits to repo and general repo development

-amount of forks/stars as well as number of project contributors

-number of PRs and resolved issues

[AUDITABILITY] What does success for this project look like?

A successful Plutarch 2.0 would see more projects incorporating the eDSL to realize its usability and improvement gains. In addition to seeing positive developments in the above KPIs, we would like to see public input on our GitHub repo and an increased number of contributors.

[AUDITABILITY] Please provide information on whether this proposal is a continuation of a previously funded project in Catalyst or an entirely new one.

This is a continuation of https://cardano.ideascale.com/c/idea/398609