Please describe your proposed solution.
Problem
CIP-30 is a universally accepted web-based wallet standard for Cardano. It provides a minimalistic interface that, in principle, can be used to build almost any kind of Cardano dApp. However, the way dApp<->wallet interaction is defined leads to suboptimal dApp architecture due to CIP-30 limits.
Consider the following problems:
Use of CBOR representations
CIP-30 standard uses CBOR encoding for all data passed from the wallet, e.g. addresses and UTxOs. Interpreting this data within the app requires CBOR decoding functionality that is tedious to implement manually, and so users resort to using cardano-serialization-lib or its close alternative, cardano-multiplatform-lib, which both require loading a WebAssembly blob of >1M size.
For comparison, to start a new Web3 app on Ethereum there is no need to use a library for data serialization. It’s possible to interact with the provider object that is given by the wallet directly, although there are libraries to further simplify this. Using CBOR looks unnecessary, given that JSON is a de-facto standard for web data serialization.
Manual Transaction Building
When comparing developer experience for Cardano dApps and Web3 apps on Ethereum, the thing that is usually noticed first is that Ethereum developers operate on a higher level of abstraction than Cardano wallets.
On Ethereum, a smart contract transaction can be triggered by a simple function call on a Contract object, but when CIP-30 is used, the whole process of constructing transactions is delegated to the developer. This process includes:
- Fetching the data from the blockchain, using either CIP-30 interface, custom backend, or, most commonly, both
- Determining the parameters (or constraints) the transaction should have using internal dApp logic
- Constructing a skeleton of the transaction given data from the previous steps
- Making the transaction structure valid for stage1 and stage2 of the validation process - balancing (making sum of outputs plus fees equal to sum of inputs), estimating execution units, and attaching script data (“datums”) and redeemers.
- Serializing the transaction to CBOR format (commonly via cardano-serialization-lib)
- Passing the serialized transaction for signature and submission
The complexity of this process vastly exceeds that of the Ethereum analogue.
Limits of available queries
Most dApps require interacting with scripts, which implies the need to query for available UTxOs locked at script addresses. CIP-30 does not contain a query call that allows that - the only UTxOs that are visible are those owned by the wallet itself.
Some other useful queries, like getting delegation and reward info, stake pool info, transaction metadata or contents, and epoch data, are also outside of scope.
As a result, dApp developers are forced to implement their own query layers on the backend side - which leads to one more problem - inconsistency between states of multiple query layers:
Query Layer State Inconsistency
On Cardano, every running node has its own opinion on the set of currently unspent transaction outputs. Only eventual consistency is guaranteed.
Any dApp that interacts with a CIP-30 wallet has to deal with the inconsistency between the local cardano-node-based query layer and the light wallet query layer, especially when dApp workflow involves sending multiple transactions with the wallet in quick succession.
Thus, the goal of the developers is to ensure that the set of UTxOs available to the wallet and the set of UTxOs the backend cardano-node knows about are synchronized enough to not cause errors when a wallet or backend operations are performed. To give a few examples of potential issues, consider the following scenarios:
- A dApp tries to balance a transaction with UTxOs from the wallet that is not yet available in dApp backend's cardano node, causing an error response during execution units evaluation
- A transaction is passed for signing, but the wallet does not yet know about the UTxOs it spends, and thus refuses to sign it (this happens with Eternl)
- A transaction is sent to the network via the dApp backend (bypassing CIP-30 submit method) and is confirmed there, but the wallet still does not know about its consumed inputs, and thus returns outdated data.
Solution
We propose creating an extension standard on top of CIP-30 that addresses all these problems.
Use of JSON instead of CBOR representations
The standard should specify a new set of API methods, or a non-breaking extension of CIP-30 methods, that would allow specifying a preference for human-readable JSON format instead of CBOR for all CIP-30 data types.
To address the well-known Cardano-related CBOR definite-length vs. indefinite-length problem, the standard should refer to CIP-21 (<u>https://cips.cardano.org/cips/cip21/</u>) and require the implementations to follow it.
Automatic Transaction Building
Another set of API calls should be specified, with the goal of abstracting away tedious parts of transaction building.
Declarative transaction building is hard, but we have some experience we can apply. At MLabs, we created a library named cardano-transaction-lib (CTL) (<u>https://github.com/Plutonomicon/cardano-transaction-lib/</u>) (thanks to Catalyst Funds 8 & 9) that facilitates transaction building in JavaScript environments. The main feature of the library is a declarative constraints interface similar to that of plutus-tx-constraints package (<u>https://input-output-hk.github.io/plutus-apps/main/plutus-tx-constraints/html/index.html</u>).
We could standardize an interface similar conceptually, but using JSON instead of PureScript function calls.
For example, to spend a certain UTxO, the client would just call:
walletAPI.buildTransaction({
mustSpend: [{ utxo: “0x123467890ABCDEF…….12345#0”, redeemer: 42 }]
})
The result would be a JSON-serialized transaction built by the wallet, containing the provided UTxO as one of its inputs.
The transaction could later be modified manually before signing, but we can assume most dApps would not need to do that.
Adding new queries
The wallet query layer should be extended with new methods. We propose making a combination of existing query layer implementations into a standard with minimal changes.
We could take these specs as inspiration:
- Blockfrost: <u>https://docs.blockfrost.io/</u>
- Ogmios: <u>https://ogmios.dev/mini-protocols/local-state-query/</u>
The goal is to make it possible to retrieve the following data without the need to deploy own cardano-node:
- any existing UTxO: by address, by transaction ID
- block metadata and contents
- epoch info
- protocol parameters
- transaction data
- rewards and reward history
- stake pool info
- era summaries
Market
All dApp developers targeting browsers could benefit from this proposal.
How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?
Challenge statement: Development & Infrastructure. What research, tools or software can improve the developer ecosystem or infrastructure to make it easier to build and scale on the Cardano blockchain?
Current wallet API usability on Cardano is limited in comparison to Ethereum due to the aforementioned problems. Resolving these problems could significantly reduce the time-to-market metric for new Cardano projects and cut development costs, while also providing a way to build more lightweight dApps.
What does this proposal entail?
This proposal entails creating a new CIP with the aim to get new APIs standardized.
However, it does not necessarily follow that wallet developers will agree to adopt and implement the new standard.
In the best-case scenario, the CIP will revolutionize Cardano dApp development. In the worst case, it will be left unnoticed by wallet developers.
How do you intend to measure the success of your project?
Success can be measured subjectively: by perceived approval of the new CIP.
The goal of this project is to get the CIP adopted by wallet developers, which is the ultimate indicator of success.
Please describe your plans to share the outputs and results of your project?
MLabs maintains a social presence on Twitter and in Plutonomicon Discord, where updates could be posted. Additionally, the release could be announced on IOG technical Discord.