Anastasia Labs - Streamlining Development: A User-Friendly Smart Contract Library for Plutarch and Aiken Design Patterns & Efficiency

[GENERAL] Name and Surname of Main Applicant

[GENERAL] Email address of Main Applicant

Additional Applicants

Jonathan Rodriguez

Mladen Lamesevic

[GENERAL] Please specify how many months you expect your project to last (from 2-12 months)

[GENERAL] Please indicate if your proposal has been auto-translated into English from another language.

[GENERAL] Does your project have any dependencies on other organizations, technical or otherwise?

[GENERAL] If YES, please describe what the dependency is and why you believe it is essential for your project’s delivery. If NO, please write “No dependencies.” in this field.

No dependencies.

[GENERAL] Will your project outputs be fully Open Source?

[GENERAL] If NO, please describe which outputs are not going to be open source. If YES, please write “Project will be fully open source.” in this field.

Project will be fully open source.

[METADATA] Category of Proposal

[IMPACT] 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?

PlutusTypeEnumData

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".

[IMPACT] 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.

[IMPACT] 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.

[IMPACT] 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.

[CAPABILITY/ FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability?

Anastasia Labs has rapidly established itself as a leading development firm within the Cardano Ecosystem. Our team consists of highly skilled developers who have made significant contributions to various community projects, including Lucid, Agora, Liqwid-Plutarch-Extra, and Aada Finance. Furthermore our developers have had experience developing and publishing end-to-end DApps including production projects such as WingRiders.

In addition to our project involvement, our team has been actively engaged in the developer experience domain. We have actively participated in educational panels focused on DApp Security Practices and Design Patterns, and our members have served as co-chairs of the IOHK developer experience working group.

Furthermore, our collaboration with Emurgo Academy has been instrumental in educating aspiring developers, with our team playing an essential role in this endeavor. We have also recognized and recruited the most exceptional talents from the academy's classes.

We have developed software development kits (SDKs) that facilitate the integration of existing dApps with other systems through off-chain code. Our team has also designed various protocols, including bridges and staking systems, while also actively contributing to open-source smart contract languages and their associated standard libraries.

Overall, Anastasia Labs has established itself as a highly capable and versatile development firm with a broad range of expertise within the Cardano Ecosystem.

[CAPABILITY/ FEASIBILITY] What are the main goals for the project and how will you validate if your approach is feasible?

The main goals of this proposal are:

• provide awareness of these unintuitive / hacky design patterns to the Cardano smart contract developer community.
• robust up to date documentation for all these design patterns, as-well-as simple examples of their practical applications.
• a clean interface (the wrapper libraries) to allow developers to use these design patterns without sacrificing readability.

[CAPABILITY/ FEASIBILITY] Please provide a detailed breakdown of your project’s milestones and each of the main tasks or activities to reach the milestone plus the expected timeline for the delivery.

Phase 1 - Robust Documentation of these Design Patterns

1 months

This time will be spent to create robust documentation for these unintuitive / hacky design patterns and publish said documentation to a standalone Github repository, as-well-as to existing developer documentation Github repositories such as the Plutonomicon, Developer Portal, Aiken Documentation, and Plutarch Documentation.

Phase 2 - Design Pattern Wrapper Libraries for Plutarch & Aiken

3 months

Implement the design pattern wrapper libraries for Plutarch & Aiken. Provide documentation to clearly illustrate the purpose of each design pattern and how the associated wrapper function can be used to apply the design pattern without sacrificing readability.

Phase 3 - Unit Testing - Property Based Testing 

1 month

Implement extensive unit tests & property based tests for the wrapper libraries. Provide documentation that clearly illustrates the purpose of each test, and how each component of the testing framework is used (Aiken Check, Plutus-Simple-Model, Plutarch-Context-Builder, Plutarch-Unit).

[CAPABILITY/ FEASIBILITY] Please describe the deliverables, outputs and intended outcomes of each milestone.

Phase 1 - Robust Documentation of these Design Patterns

Deliverable:

Robust documentation of unintuitive / hacky design patterns published to a standalone Github repository, as-well-as to existing developer documentation Github repositories such as the Plutonomicon, Developer Portal, Aiken Documentation, and Plutarch Documentation.

Phase 2 - Design Pattern Wrapper Libraries for Plutarch & Aiken

Deliverables:

An Aiken library that allows users to apply the unintuitive design patterns & hacky efficiency tricks without sacrificing readability and without needing to write a ton of repetitive boilerplate.

An Plutarch library that allows users to apply the unintuitive design patterns & hacky efficiency tricks without sacrificing readability and without needing to write a ton of repetitive boilerplate.

Phase 3 - Unit Testing - Property Based Testing 

A series of unit-tests and property based tests that provide some assurance that the implementations of the wrapper functions adhere to their technical specifications.

[RESOURCES & VALUE FOR MONEY] Please provide a detailed budget breakdown of the proposed work and resources.

Robust documentation of the design patterns and efficiency tricks:

Engineering hours for thoroughly documenting the design patterns and efficiency tricks we are familiar with; as-well-as reaching out to other teams and in the unlikely event that they share one that we did not know, documenting it. Getting the documentation published to all the relevant sources of Cardano developer documentation.

₳50,000

Design Pattern Wrapper Libraries for Plutarch & Aiken:

Engineering hours for designing and implementing the efficiency / design pattern wrapper libraries for Plutarch and Aiken.

₳150,000

Unit Testing - Property Based Testing :

Engineering hours for writing a series of unit-tests and property based tests that provide some assurance that the implementations of the wrapper functions adhere to their technical specifications.

₳50,000

[RESOURCES & VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

Currently there are many DApps live on Cardano that are simply unaware of these design patterns & efficiency techniques. Even after introducing them to the techniques, they have some reservations about using them because of their negative impact on readability (and the possible impact that could have on audit costs).

This proposal will get projects to adopt these design patterns and efficiency techniques which in will result in a large increase in the efficiency of new DApps (and even old DApps who choose to upgrade to gain access to these new efficiency improvements). For many live projects (ex. WingRiders) they consider the hassle of upgrading the protocol to V2 to outweigh the efficiency improvements offered by Vasil. Now projects will have another reason to upgrade to V2, namely, they will have access to all these new efficiency techniques and design patterns.

To put it into perspective, the MuesliSwap team published the following benchmarks regarding improvements of Vasil:

Plutus v1 Transaction

Size: 14.73 kB

Fee: 1.44 $ADA

Plutus v2 Transaction

Size: 1.31 kB

Fee: 0.73 $ADA

Our benchmarks demonstrate a similar level of improvement when comparing PlutusV2 Spending Scripts without the tx-level-validation design pattern to Plutus V2 Spending Scripts with the tx-level-validation design pattern.

Depending the number of script inputs in the transaction, transaction level validation can result in a 5-10x efficiency improvement over current design patterns. For protocols using the batcher architecture, this directly translates to a 5-10x increase in protocol throughput.

[IMPORTANT NOTE] The Applicant agreed to Fund10 rules and also that data in the Submission Form and other data provided by the project team during the course of the project will be publicly available.