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:
- GHC: Haskell -> GHC Core
- Plutus Tx compiler: GHC Core -> Plutus IR (Like TPLC but has data types)
- Plutus IR compiler: Plutus IR -> Typed Plutus Core (TPLC, variant of System Fωμ)
- 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.
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 <u>Pirouette</u>.
- 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
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.