IOG did not support smart contracts, as well as documentation to help us understand some things, at the time of our participation. All developments were tested in simulation. Following the release of the Alonzo hard fork, an update that added the ability to create smart contracts and dApps, it was discovered that it does not support many features. We detail the issues we encountered and how they impacted the project's launch:
1. Metadata storage (images, video or audio files associated with the NFT).
It is well known that storing a file on the network significantly raises the cost of a transaction. Furthermore, a maximum of 16 KB of storage is allocated per unit (due to the transaction size limit). This means that to store large files, you must first dice them like a classic salsa recipe, and then devise a method for combining the pieces into the original veggie file.
The solution was adapted from existing Ethereum blockchain practice. We've decided to use IPFS, a distributed file storage system. The file is uploaded to IPFS and assigned a content ID that is a hash of its content. The system works because the hash continues to uniquely identify the files (in other words, they assign addressability to the content).
This solution kills two birds with one stone:
- allows you to uniquely identify NFT with something (thus rendering the token non-fungible);
- allows you to store only a short hash in the chain rather than a large file.
2. Storage of the content ID, which is generated after the file is uploaded to IPFS.
In Ethereum, each token is a smart contract that allows you to use storage. In Cardano, all tokens are native, backed by the ledger, and can behave similarly to the main currency, ADA. In Cardano, the token is only represented by a PolicyID and an immutable asset name, allowing you to uniquely identify, transfer, and track it.
We had two options for solving the problem:
- Use the asset's name for storage — the only place in the token where you can store something unchanged;
- Keep all hashes in the data of some scripts (for example, a marketplace script), with the option to change them. A lot of other related information can also be stored there.
To make the token as lightweight as possible, we decided to store the content identifier in the token name and other information — such as a description of the token — inside the script data.
3. Plutus framework general readiness.
The library was brand new and experimental at the time, and the Cardano network did not support smart contacts. Plutus, the custom smart contract development language and execution platform, was developed concurrently with our marketplace application, so something was constantly not working.
We were prepared, though, and tried to stay up to date on Plutus updates and provide feedback to IOG engineers. We were constantly discussing ways to fix the errors that occurred in a dedicated Discord community with the Plutus developers and other members of the test program. At IOG, we were also supported by the core in-house team.
4. The existing transaction size limitation.
Cardano's maximum transaction size is 16 KB. The number of calculation steps (CPU) and random access memory (RAM) consumed by the script are also limited.
Our scripts proved to be far too large to run online. It was later discovered that this was due to the use of a Plutus framework state machine abstraction. Abstraction is very expensive because it adds a lot of code and makes the script larger.
To fix the size limit issue, we had to rewrite the entire implementation by removing the use of the state machine.
5. PAB does not support remote (browser) wallets.
To buy NFT, the user must navigate to his browser wallet through the browser interface, enter a password, and submit transactions (those who are familiar with MetaMask know this scheme).
However, it was discovered that the Plutus App Framework does not support PAB integration with a remote (browser) wallet. This was the most significant problem, which was discovered only during the course of work. It was then impossible to find a genuine solution.
True, we did not give up right away and planned an alternate scenario for launching the application via the Cardano Wallet Backend. We decided to deploy a PAB locally along with a Cardano wallet, chain-index, and Cardano-node applications. As a result, the dApp user runs all applications on his computer and employs a local wallet with a full node. As a provider, we have undertaken to store all of his data and perform actions on his behalf.
This script violated privacy policies and appeared unappealing to the user, who would have to give us access to his wallet. As a result, we were unable to implement the script and launch the project on the testnet.
PAB is still not working in browser wallet mode as of this writing (September 2022). Any DeFi application must be able to work with browser wallets. More work must be done to explore alternative solutions that will allow the application to run for a wide range of users.
