OpenZeppelin in ink!
This article explores how ink! has most of the features required for usage however the usability of ink! is low.
There are currently no guides on how to use ink! with examples of ERC standards and how these can be customized by users with their own logic. There is also currently, no description of how the contract must be designed, in comparison to Solidity. (Rust doesn’t have full features of OOP, so users must use another pattern during contract implementation).
OpenZeppelin in ink!
Supercolony has developed a vision of how analog for OpenZeppelin can be implemented. It will fit perfectly within Rust’s paradigm. The implementation will allow users to import contracts, implemented by another user, without problems and enable the reuse of code.
Several issues need to be resolved first:
(Scroll down to see the pseudo code examples of the lib)
Several issues on ink! and one on the substrate level:
1) The code of one contract cannot be injected into the code of another contract during compilation time. It greatly reduces the re-usage of code. Most of the business logic can be implemented on rust level. But ink!’s related code generates only in the contract section. So to emit events(or other useful features) we need to inject one contract into another.
Here is an example of how it can be easily implemented. This in turn creates another issue.
2) During the generation of metadata, we don’t use the metadata of imported contracts. So if code injection is available, we still will not be able to generate metadata for imported implementations at the moment.
3) We cannot create an implementation for some generic type, if trait defined via #[ink::trait_definition]. The code below will fail to compile.
Therefore resolving the 3 issues highlighted above, will allow us to define implementation in the repository for most of ERC standards. This enables any user to import a crate + implements storage’s trait (for example Erc20Storage) and they will then automatically have an implementation from the imported crate.
We have found other additional issues that would be beneficial to fix such as: simplify usage and understanding of contracts.
4) It is not currently clear for the user that if the contract returns an error — it doesn’t mean that contract is reverted. And if the user wants to revert the contract they must use throwing of exception or return_value function. So this issue is also critical, but easy to fix.
5) At the moment the existing contract pallet doesn’t provide the ability to return the error from the contract (text message). So ink! also does not provide it. This feature can be critical for debugging or using the contracts.
6) When the contract is imported like “ink-disable-dispatch” it creates a wrapper around the struct which simplifies the usage of the external contract. But if the struct implements the trait it will fail. It is an example of a workaround for that problem, but it causes us to duplicate the code.
Overall ink! has a lot of small issues highlighted, however they are not all required to be resolved, for the implementation of OpenZeppelin.
ink!’s OpenZeppelin implementation
Below is an example of how Erc20 can be implemented and easily reused if the issues are fixed.
It is a Cargo file, where we are importing erc20 implementation as dependencies with disabled entry points(we want to inject the code).
How we can reuse and customize implementation of Erc20.
SuperColony operates as a DAO venture studio designing and building companies by bringing together experienced blockchain talent, resources, and capital to compress time, iterate quickly and scale more ambitiously than would otherwise be possible.
We connect founders to all of the necessary partners to achieve success in today’s crypto ecosystem. We have aligned ourselves with partners in every major crypto geography, including traditional trading firms, VC’s, legal/compliance experts, marketing and pr firms, launchpads, and security auditors.
