Plutarch Overview
Plutarch User Guide:
<https://github.com/Plutonomicon/plutarch/blob/master/docs/README.md>
Plutarch Developer Guide: <https://github.com/Plutonomicon/plutarch/blob/koz/numeric/docs/DEVGUIDE.md>
Plutarch is an eDSL in Haskell for writing on-chain scripts for Cardano. With some caveats, Plutarch is a simply-typed lambda calculus (or STLC). Writing a script in Plutarch allows us to leverage the language features provided by Haskell while retaining the ability to compile to compact Untyped Plutus Core (or UPLC, which is an untyped lambda calculus).
When we talk about "Plutarch scripts," we are referring to values of type Term (s :: S) (a :: PType). Term is a newtype wrapper around a more complex type, the details of which Plutarch end-users can ignore. A Term is a typed lambda term; it can be thought of as representing a computation that, if successfully evaluated, will return a value of type a.
The two type variables of the Term s a declaration have particular kinds:
s :: S is like the s of ST s a. It represents the computation context in a manner that mimics mutable state while providing a familiar functional interface. Sections 1 through 4 of [1] give an accessible introduction to how this works. s is never instantiated with a concrete value; it is merely a type-level way to ensure that computational contexts remain properly encapsulated (i.e., different state threads don't interact). For more in-depth coverage of this and other eDSL design principles used in Plutarch, see [2].
a :: PType is short-hand for "Plutarch Type". We prefix these types with a capital P, such as PInteger, PBool, and so forth. Tagging a Term with a PType indicates the type of the Term's return value. Doing this allows us to bridge between the simple type system of Plutarch and the untyped UPLC.
In brief, when writing Plutarch scripts, we have a few tasks:
A.) Defining Plutarch Types (or PTypes). We prefix these types with a capital P, such as PInteger, PMaybe a, PBool, and so forth. As previously mentioned, these form the "tags" for Plutarch Term's, representing the type of the result of compiling and evaluating a Plutarch Script.
B.) Working with Plutarch Terms, which are values of the type Term (s :: S) (a :: PType). These are the Plutarch scripts themselves, from which we build up more complex scripts before compiling and executing them on-chain.
C.) Writing Haskell-level functions between Plutarch Terms (i.e., with types like Term s a -> Term s b). Doing so allows us to leverage Haskell's language features and ecosystem.
D.) Efficiently Converting the functions from (C.) to Plutarch-level functions, which are of the type Term s (a :–> b). We can directly convert the functions from (C.) to Plutarch-level functions at the most naive level using plam. Additional Plutarch utilities provide for optimization opportunities.
E.) Compiling and executing the functions from (D.), targeting UPLC for on-chain usage.
*There are two general categories of functions in Plutarch: "Haskell-level" functions between terms, and "Plutarch-level" functions as lambda terms. By convention, we will prefix the Haskell-level functions with h and the Plutarch-level lambdas with p, (example in attached image).
Plutarch written validators are often significantly more efficient than Plutus Tx (massive reduction in execution costs) written validators. With Plutarch, developers have much more fine gained control of the Plutus Core validator generated, without giving up any type information.
To put things into perspective, one validator script from a large production contract was rewritten in Plutarch, changed from Plutus Tx. The comparison between the Plutarch script's execution cost compared to the Plutus Tx script's execution cost (benchmark comparison of the CPU, Memory, Script Size attached). These numbers were gathered by simulating the whole contract flow on a testnet.
Plutarch provides a highly performant alternative for Haskell engineers to begin writing Plutus core validators *today* without the current limitations of PlutusTx.
An open source alternative to writing validators in PlutusTx addresses the open source development challenge in several ways. With the release of Plutarch v1.1:
Haskell developers now have the infrastructure needed to write untyped Plutus Core validators and a lower barrier to building Plutus smart contracts since no need to learn the nuances of PlutusTx.
With Plutarch as a smart contract language closer to raw Haskell new developers now gain a diverse selections of paths to build their Plutus smart contracts rather than the singular PlutusTx option.
Expanding options and lowering the barrier to entry for proficient Haskell devs who want to build Cardano smart contracts but don't want to learnt the subtleties of PlutusTx, this is how Plutarch addresses the open source development challenge.
As an open source project the main risk is linked to implementing a structure to ensure the code maintenance and feature updates continue at a predictable pace from dedicated (incentivized) core code contributors. Currently contributions come from engineers at multiple firms (with MLabs coordinating the work).