Please describe your proposed solution.
This proposal is to create two smart contract libraries (to support Plutarch and Aiken) to abstract away unintuitive design patterns that even some of the best developers in the ecosystem don't know (because of how bizarre they are).
This includes:
- Transaction level validation for spending validators via stake validators using the withdraw zero trick.
- Transaction level validation for spending validators via minting policies.
- Input/output indexing with redeemers.
- Strict && validation checks
- PlutusTypeEnum Redeemers - efficient data encoding for simple redeemers as Enums.
- Normalize txInfoMint to get rid of 0 lovelace value.
- Normalize Validity Range.
Why is this important?
Transaction level validation via stake validators by withdrawing 0 ADA
Why does the txInfoMint Value contain 0 lovelace?
Transaction validity range not respected
Due to the computations limitation inherent in blockchain development, there is always a number of hacky / unintuitive trick and tips that developers use to squeeze out extra efficiency to fit more logic in their applications or to facilitate a higher transaction throughput for their protocol. Very often, these hacky tricks are very obscure (only a small number of developers know about them) and their usage incurs a cost (namely, it damages readability of the code). This proposal is important to Cardano because it will make these design patterns readily available to all the developers in the ecosystem, and it will provide a clean intuitive interface for using these tricks so that developers can obtain the improved efficiency without needing to sacrifice the readability of their code.
The design of these smart contract wrappers will be very similar in architecture to Agora Effects
Clarification:
The wording "transaction level validation" and "Transaction level validation for spending validators" is confusing because technically spending validators still are validating against the whole transaction. For clarification, in this proposal when we refer to "transaction level validators" and "input level validators" we are referring to the following:
Spending validators are executed once for each input being unlocked from the script. This means if you are unlocking eight inputs from a script address, the spending validator is executed eight times in the same transaction. The successful execution of a spending validator means "The conditions for unlocking this individual UTxO were satisfied by the transaction".
With the stake validator withdraw zero design pattern, the logic for validating inputs from the spending validator is executed once regardless of how many inputs are being unlocked from the script. This means if you are unlocking eight inputs from a script address, the core validation logic is executed only once in that transaction. The successful execution of the staking validator (in the context of this trick) means "The conditions for unlocking ALL the UTxOs locked by script X were satisfied by the transaction".
How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?
Some very useful design patterns on Cardano can be extremely unintuitive and not widely known; The causes for this are numerous, including the differences in functional vs imperative philosophies; the newness of eUTXO; the quirks in how scripts get evaluated on Cardano; and the strict constraints the chain is under. For example, there is a pattern that allows you to run global logic once, rather than for each input, by utilizing the "Withdraw" redeemer in staking script; this relies on the ability on Cardano to withdraw 0 staking rewards. I had been building on Cardano for nearly a year before Las from MLabs showed me this trick, and many of the other top developers on Cardano such as Pi (SundaeSwap CEO) and the WingRiders smart contract team were similarly unexposed to the idea.
Depending on the number of script inputs in the transaction, transaction level validation can be a 5-10x efficiency improvement over current design patterns.
It was not through any fault of their own that these developers did not know about this pattern. The ecosystem is hyper-competitive, and anything that gives a developer a competitive advantage is as closely guarded a secret as their private key.
First of all, this proposal will include robust up to date documentation for all these design patterns, as-well-as simple examples of their practical applications. This alone will be massively beneficial to the Cardano developer community. This documentation will be published in standalone Github repository, as-well-as to existing developer documentation Github repositories such as the Plutonomicon, Developer Portal, Aiken Documentation, and Plutarch Documentation.
Even when projects do adopt these advanced design patterns, many of these patterns are so unintuitive and hacky that the resulting code sacrifices readability. This can result in a higher auditing cost for their projects. Furthermore, for projects that are open-source these design patterns make it much harder for aspiring developers reading the code to actually understand what is going on and apply the patterns themselves.
The core of the proposal is the wrapper libraries which will make using these design patterns actually make sense. Currently, even if you know about the transaction level validation with stake validators design pattern, using it feels clunky and unintuitive and the resulting code is very hard to understand for those unfamiliar with the tricks involved. The design of the wrappers will be similar to that of the makeEffect wrapper from Agora. For instance, the wrapper library will include mkTxLevelValidator which can be used to create a spending validator that operates at the transaction level, validating the whole txInfo as-opposed to an individual input (via the stake validator trick). This abstracts away the unintuitive hacky components of this design pattern from the user, so that anyone unfamiliar with the trick can immediately understand what is going on and apply it to their own projects.
How do you intend to measure the success of your project?
Good metrics for the success of this project is:
- number of stars / forks of the Github repository
- feedback on the content hosted on external repositories (Plutonomicon, CF Developer Portal, etc)
- number of projects that utilize the wrapper libraries to apply the design patterns with sacrificing readability.
The most important metric for the success of this project is the number of developers that that adopt these advanced design patterns. The main focus of the proposal is to make the developer community aware of these techniques and how incredibly efficient they are compared to the design patterns currently in use. The secondary purpose is to provide a clean interface (the wrapper libraries) for using these design patterns without sacrificing readability. The success of this can be easily measured by the number of developers & projects using the wrapper library.
Please describe your plans to share the outputs and results of your project?
Wrapper libraries to make using the design patterns intuitive in Aiken and Plutarch.
Robust documentation of the design patterns.
Examples using the design patterns directly.
Examples using the design patterns with the abstraction / wrapper library.
As a reach goal, we will include an implementation of CIP 57 for Plutarch.
The outputs of this proposal will be continuously maintained by Anastasia Labs. We will incorporate new design patterns & efficiency tricks as they are introduced to the ecosystem. Our goal is to encourage adoption of these wrapper libraries, so naturally we will want to continue the development and maintenance of them.