Please describe your proposed solution.
For dApps designed with a backend running on the PAB, it will add a lot of utility to have a RESTful abstraction for the off chain code. A frontend can interact with the PAB to invoke the endpoints exposed via the Plutus off-chain code but the PAB cannot return a response back to the calling frontend. A RESTful response from the Plutus off-chain will provide access to attributes deduced with Plutus. For example, the script address of a parameterized Plutus contract.
Benefits:
A convenient way to bridge the frontend/backend for DApps with off-chain Plutus. The RESTful API can be used to fetch at runtime
- Serialized datum
- Datum hash as encoded by Plutus
- Parameterized script address
- Plutus pub key hash for a given bech32 address
- CBOR encoded script generated with Plutus
What is listed above is not an exhaustive set of use cases for getting attributes from the off-chain code. However they go a long way to simplify the frontend-backend-Plutus interaction for a dApp.
To call out a related case, there are differences in the way data serialization is done by different tools like cardano-cli, serialization libs and Plutus. Unless identical serialized bytes are used the corresponding hashes turn out to be different. This leaves an inconsistency across toolsets and can become inconvenient to dApps that use more than one of the tools in their tech stack. This RESTful abstraction will make it easier to employ Plutus Application Backend (PAB) running Plutus smart contracts in the dApp stack.
It is important to highlight that this wrapper tooling is non intrusive that it does not change the way the PAB or Plutus off-chain works. Instead, it provides an abstraction to communicate with the Plutus off-chain code at runtime.
This diagram shows how the deployment model will be when this tooling is used.
Deliverables:
- Open source repository of the implementation
- Tooling: RESTful wrapper over Plutus off chain code
- Examples: Sample PAB executable smart contract example and rest endpoints
- Documentation: Documentation, tutorial and video walkthrough
How can dev teams use this solution?
The wrapper module (written in Haskell) can be imported into their projects which uses Plutus smart contracts. The wrapper will provide the necessary abstraction for the frontend/backend to access the Plutus off-chain. Dev teams can reuse the REST endpoints from this tooling and then wire those with their own smart contracts by following the examples which will be provided. The various endpoints can be invoked by a dApp frontend (or backend) and the REST based wrapper will interact with the off-chain code.
Please describe how your proposed solution will address the Challenge that you have submitted it in.
This proposal is to develop tooling that can make dApp development in Cardano richer and easier. It aligns directly with the following guiding questions of this challenge.
How do we attract developers from outside of our current community to participate in Catalyst? - A RESTful abstraction is one of the most convenient patterns in software development today for system integrations. New Cardano developers already have a steep learning curve of learning how Cardano blockchain works (eUTXO model etc) as well as Plutus. This solution will help them bridge frontend/backend with off-chain Plutus for dApps running Plutus smart contracts in a familiar manner.
What do developers want, and how do they get it from the Cardano dev ecosystem? - Developers often want open source and tested code that they can adopt in their development, preferably from those who have been in the space for longer. This will be one of the open source repositories through which we share our expertise and learning from working on Cardano.
What are enterprise dev managers looking for in order to be able to build out enterprise projects - either internal or commercial? - To have standard approaches to doing something and not having to reinvent the wheel are aspects that dev managers focus on. This solution gives a readily usable tooling/codebase to help in dApp development.
Among the potential directions listed in the challenge, this solution fits under 'Deployment, testing, and monitoring frameworks', 'Samples, recipes and templates' and 'Support structures'
What are the main risks that could prevent you from delivering the project successfully and please explain how you will mitigate each risk?
Overall, this is a low-risk project as delivery can be only delayed but not prevented.
- Unforeseen circumstances affecting availability of dev resources - In case the availability of dev resources reduces during the course of the project due to health issues or other unforeseen circumstances, it will put a strain on the timeline. However, it can only cause a delay in the timeline and cannot prevent delivery. We will be able to complete the development even with just 1 developer although with a delayed timeline if it comes to that.
- IOG or another team building the exact solution in the immediate future - At this point we are not aware of IOG or any other team building this open source solution. In the rare case that such a situation arises before we complete the project, we would like to collaborate with that team. This project may still be deemed successful if a better tooling arises out of such collaborative effort.