As we might know well-known approaches for writing smart contracts on Cardano are using Plutus Tx or Marlowe based on specific requirements. However, according to the growth of the Cardano community, many new choices for writing smart contracts appear. Could Plutus Tx be a good choice in the future?
List of possible tools:
PlutusTx inherits its qualities from Haskell, and thus has many of the same benefits/drawbacks:
Pros: auditability, maintainability, and upgradeability of code.
Cons: developers' unfamiliarity with functional programming. High resource usage.
PlutusTx is especially useful when safety and correctness are the #1 priority, such as in massive DeFi dApps or any other mission critical system.
On the other hand, PlutusTx is relatively resource-hungry (in terms of script execution units), which limits the size of deployable contracts. Although it may be possible to address some of these limitation through optimizations/changes to Plutus Core (i.e. CIP-38, CIP-85 and others), newer languages like Aiken and Plu-ts offer a lighter-weight execution budget and greater accessibility to a broader set of developers.
Non-turing complete DSLs like Marlowe offer even greater developer accessibility via low-code or even no-code contract deployment.
TLDR; all of these are just tools in the toolbox. All (or most) of them will be future smart contract langugaes.
Marlowe... or its descendants/variations ;-)
I would like to emphasize the difference between Marlowe and all the other solutions and later on focus on Marlowe. I'll even allow myself to speculate a bit about its possible future:
All the other languages compile down to a "binary (lambda?) blob" (Plutus Core) and that is how they end up on the chain.
Binary blobs of a Turing-complete program are generally hard to understand. It seems rather infeasible to build a generic tool for binary programs (considering issues like the halting problem etc.), which could analyze them and answer questions about what will happen in the future if I join the contract.
Marlowe doesn't compile to anything (by design!). It is interpreted on the chain, merely serialized and placed into the Datum..
Marlowe is limited and non Turing complete. You can analyze and discover a lot of properties of the contract statically.
Marlowe is severely limited on purpose. We are playing with peoples money here. It requires more thinking to design some contracts. Some contracts are just impossible in Marlowe (like "open auction"). But if you assume some "sensible" limits (do I have to support more than 1000 rounds in this auction? can I limit participants to some known group?) you can do a lot with it.
The Marlowe interpreter V1 will be a single identifier of a constant script (after its release, the Marlowe interpreter should be present on the chain as a reference script). So given an UTxO with a script hash and datum you are able to decode the whole picture of Marlowe interpreter state (there are some optional nuances about "role token" minting but we can ignore them in this discussion).
Marlowe is a pretty simple DSL and it can be produced from any programming language which supports JSON (json encoding is part of the official spec: https://github.com/input-output-hk/marlowe/releases/download/v3-rc2/specification-v3-rc2.pdf - page 62, Appendix E).
When you build a dapp (in any language!) you could on your backend or even frontend(!) have a template of a Marlowe contract which it can fill in with values (like addresses, amounts, timeouts etc.) dynamically.
Learning curve for Marlowe seems to be pretty low. Interestingly Marlowe pretty nicely integrates with the UTxO model. A step ("user action") in a contract is usually translated to a transaction on the chain. A programmer can possibly transfer Marlowe knowledge between projects written in different languages, frameworks etc. (like we do with SQL or HTML/CSS knowledge).
Marlowe contract execution runtime which takes care of the deployment on the chain and monitors the chain is also in a pre-release phase. It exposes pretty simple REST API which can be naturally integrated into any project.
What could it mean in practice?
The audit's cost for a Marlowe-based solution should be much lower. Everyone has access to a set of static analysis tools for Marlowe. An audit may even be unnecessary in simpler scenarios.
The operational costs and business risks of Marlowe-based solution should be also lower - more developers can pick it up and learn etc.
Developers like to talk about performance and expresivness but I hope that in the domain of financial contracts they can see the value in the DSL which is limited but provides guarantees.
Because Marlowe is present on the chain as a 'source code' contracts could be visualized by wallets, explorers etc. In such a case user could just pick a dapp contract and possibly check the contract and answer a lot of questions himself before signing any tx.
Marlowe is not the only possible DSL which we could have. We can imagine other more expressive (with less guarantees? harder to visulaize?) or less expressive (easier to understand and visulaize) languages which we can build using this kind of interpreter pattern which gives the contract its transparent nature.
