Intro

So you want to plutus, but how?! You have plenty of choice between options, no silve bullets and (probably) plenty of headaches.

A warning:

• This is a fast moving space. Things that were true may no longer be true.
• Some things that are claimed to be true might never have been true, only misunderstood.
• It’s a WIP
• Many of the tools I’ve never actually used
• It’s opinionated

Tooling is roughly broken up into:

• on-chain (creating validators)
• tx-building / wallet integration
• chain data provider / indexer
• testing
• optimizing

On-chain

plutus-apps

home

The original vision of IOG on how smart contracts should and would be. This boldly identified all the perceived issues of eth, and “fixed” them. Some years after launch, much of the vision has yet to be realized. Built in fairly monolithic fashion, its been viewed by many as unusable, a non-starter, and a complete car crash of a project.

Plutus-apps is a higher level framework, now split off from the lower level plutus repo (see below). It is an outlier here: It handles both on-chain and off-chain logic simultaneously. In fact, it was supposed to be the entire stack. All other tools stay in their lane (on-chain, off-chain, testing, optimizing). The part that has never worked was called the PAB, and envisioned that a user would be running a full node and “running dapps in their wallet”.

Much of the derision was, and remains, valid (source: me). However, projects have managed to dig in and salvage enough of a framework to make product (eg guchi, half of spacebudz orginal market place, …).

Pros

• it has had the most eyes and the most attention
• it has some laudable design tenets including write-once for on and off chain code (note: aiken devs think this is a con), and the ability to write declaritive validators
• by far the most extensive set of examples and testing framework.
• most examples
• IOG is persisting with its development (although they’ve been far from frank about their plans )

Cons

• Generates validators that can easily exceed size limits of the blockchain. This is the main criticism you’ll hear. Depending on your use case this either will or wont be your problem. Ok - its a bit more grey than that, but many sufficeintly simple validators will have this issue only when a user is trying to make a tx with their 3000 NFTs. For more complex dapps (executing multiple validators within a single tx) this is hard wall to overcome while using plutus-apps. My take: this was more true on first release, for ambitious projects. It then became lore: “everyone know you can’t use plutus-apps” <- Not true.
• Plutus-apps is not being developed with users in mind. The DX is super painful. Its a fast moving space, you’ll need to version bump to access new features, and when you do you’ll be fixing all the breaking changes: refactors, renaming, un-renaming from previous naming … (Side rant: the power of nix is a drug - (almost) perfect reproduciblity. Side-effect of drug: through semantic version control out the windows along with all promises to the user.)
• To use it you’ll probably need to fork it. A lot of code to maintain.

Plutus-tx

home

… or simply [plutus]¹. This is the lower level lib (libs, actually) on which plutus-apps depends. Originally this was the same repo, so it’s origin story is essentially the same.

Pros

• Is well resourced since its an IOG project.
• Is the most researched.
• Can use plutus-apps as inspiration rather than a dependency, which annuls some of the DX issues (Only some).
• Repo condition is reasonable: extensive code comments explaining intetions, design decisions, shortcomings, and unknowns. It uses flakes, and nix-std.
  The plutus repo is in a significantly better state than plutus-apps.
• Targets PIR (Plutus Intermediate Representation). This means you will be able to leverage code testing and coverage,

Cons

• Lose plutus-contracts which is the cheapest way to run tests.
• “There be dragons”. The code base is complex with dark corners. Many comments of the code highlight the complexity of the repos aims: employ ghc for the heavy lifting of the compiler. The author speaks of GHC magic and other unknowns, including the above. As a dependency, maybe this will be your problem, maybe it won’t - it depends how deep you go.

Plutarch

home

Comment

m-labs’s answer to “Shit, plutus doesn’t work”. Rather than IOGs route to writing plutus (write haskell and use a custom compiler pipeline); Plutarch is an embedded domain specific language (eDSL). In essence “you write typed plutus directly”.

Plutarch is on-chain only.

Pros

• Significantly smaller scripts than IOGs plutus. This was its main goal.
• Well resourced and relatively mature. Probably matching that of IOGs repos, and otherwise unrivalled.
• Examples exist: toy and real.
• Demonstably integrates with other mlabs output such their testing tools
  
• Approachable and responive devs.

Cons

• Readable by experts, not humans. (Highly subjective point:) its harder to clearly align code with code intention.
• Targets UPLC so no leveraging PIR specific tooling.

Aiken

home

Comment

In their own words

Cardano smart contract language and toolchain

Pros

• Active, knowledgable, and approachable dev team
• Built with DX as a primary concern (cf IOG plutus)
• fast evolving
• Relatively small stack.

Nix is great, and haskell is great (depending on quite what the metric is), but both are pretty hard to wrap your head around when you’ve got big projects.
IOGs haskell.nix is a form of the dark arts. Not using it, is a plus (depending on your needs).

Cons

• opinionated take: Its yet another language with its own esotericness. Rather than be “rust except x,y, and z”, aiken is “a bit like rust, a bit like elm, a bit like some other stuff”. The authors surely had their reasons, and its their perogative.
• Relatively young: still in alpha.
• Compiles to UPLC via Aiken Intermediate Representation. No chance of reusing the testing tools of IOG that rely on PIR.
• Lacking examples, but this will change.

TODO

Helios

Imperator?

Tx builder/ wallet integration

Cardano-serializtion-lib

Emurgo’s iteration of an IOG rust lib and the ‘orginal’ foundation of web-based cardano.

It is a base layer rather than plug-and-play library.

Pros

• Long life, relatively well supported (relatively)

Cons

• Aimed at being web first via wasm-bindgen, it was awkward to use as a rust lib
• (Perceived) slow progress and “issues” mean’t that it has been forked (see CML)

Cardano-multiplatform-lib

dcSpark’s fork of CSL.

At the time of writting it is going through a major refactor. The main motivations are

• split libraries to be more modular
• split off wasm-bindgen to make more ergonomic rust crates.
• rationalize some of the code to-date.

Pros

• Inherits the pros of the CSL : Maintains a long track record.
• Refactor seems sensible.

Cons

• Right now, its a bit hard to build on a moving target.

Lucid

Mainly the output of spacebudz creator and berry pool operator, ales.

This is a higher level interface built on ales’s fork of the CML, which diverged quite a while back.

Pros

• Well regarded, under active development
• Opensourced examples that are kept up-to-date
• Examples with integrations such as aiken and blockfrost and “kupmios”

Cons

• Lacking docs.
• Small (1-man) team without clear communication of design decisions, roadmap, etc.

Cardano-tx-lib

Plu-ts

Meshjs

home

Comment

Very slick docs, with heavy focus on onboarding process and getting something running as easily as possible.

Despite the name, it is infact written in typescript.

It depends on the CSL (emurgo’s fork)

Chain indexers

db-sync

Kupo

Scrolls

Carp

Testing tools

Cooked-validators

Plutus-…-bot

Plutip

Compilation optimizers

Plutonomoy

Piroutte

home