Deep dive into OpenBrush
My name is Danylo Semirazov — I am a CTO at Asylum and Supercolony and will walk you through our open-source product — OpenBrush, a tool for smart contracts development. I’ll explain to you what it is and why it is crucial for the future of WASM smart contracts.
When we started our product a year ago, on the scene of Smart Contracts development, the Ethereum ecosystem looked way more attractive. You can start scratching a project in Remix IDE, and take basic blocks from OpenZeppelin contracts, which are well tested and secure. Then, cover your contracts with integration tests with the help of Hardhat or Truffle, then deploy your contracts on test-net Rinkeby with the help of Infura suite. Unlike Ethereum, Polkadot community pays less attention to Smart Contracts, focusing more on Layer-1 solutions. But still, there is a beautiful tool ink!, which allows you to write Smart contracts on Rust and then compile them into WASM.
But still, talking about the developer tools, there is no such diversity as in Ethereum, and for ordinary developers, it is tough to start something in Polkadot.
I want to share with you our experience. In May 2021 together with our friends AllianceBlock, we were working on the lending protocol and we decided to implement it fully on smart contracts in ink! and thus test this concept. It was so difficult to build something complex in ink! so we started by implementing the basic blocks: FT in ink!, NFT, Multi Token standards and then layered the functionality step by step. Then we combined all these best practices and utilities and created a library based on which we successfully built quite complex DeFi projects on smart contracts which are DEX and lending protocol.
What is OpenBrush?
Further, with the support of W3F we introduced this library to the public and named it — OpenBrush. So OpenBrush is a library for secure smart contracts development in ink!. And now you have ink! and a Brush to write your beautiful smart contracts in Polkadot.
Motivation
Our motivation was relatively straightforward. We wanted to have a library on Rust for writing smart contracts which will ease the smart contract development by providing all necessary utilities. Moreover, the library should provide secure and easy-to-reuse contracts built upon the standards to make these contracts interoperable, which is very important. We understand that it is impossible without contributing to ink! and substrate contracts pallet and this is the part of OpenBrush team’s responsibility. Finally, such a library should serve as some kind of entry point for any smart contract developer in Polkadot.
Features
Let’s eventually understand the features OpenBrush provides. According to the Rust specifics, we call the first feature default implementation.
Default implementation
Open Brush includes over 25 contract default implementations. You can reuse our implementations simply by specifying the contract’s storage and selecting the field where default storage will be embedded, and then implementing default traits for your storage. Thereby you’ll inherit all necessary methods from the default implementation.
Contracts
You have contracts default implementations for different purposes, and this list is not final and will be extended with future library releases.
Modifiers
Modifiers are pretty much the same concept as in Solidity. You can use them, for instance, to declaratively control the access to the contracts’ method. As you can see in the example below, only the owner can access the mint method.
Wrappers
Wrappers is a handy feature that simplifies the cross-contact communication within your project. Due to the Rust specifics, the cross-contract communication can be pretty verbose, so we hid all inners inside the beautiful #[brush::wrapper] macro, and you can simply refer to any contract in the network by its interface.
Upgradeable Contracts
The next feature is upgradeable contracts, and at the moment, you have two options to write your upgradeable contracts. The first option is more from the Ethereum world, and you can use the delegate code technique: Proxy or Diamond standard. The second option is the powerful set_code_hash, and I’d mark this option as high risk as you can lose access to the contract storage by mistake, but it’s closer to the Polkadot world. A more detailed explanation of upgradable contracts in ink! you can find in Polkadot Decoded video below.
Optimized WASM binary size
One is the bottleneck of the contracts pallet in Polkadot might become Relay Chain validators who will execute smart contracts WASM binary. That’s why we should keep the lowest binary size, and we did a lot of work around the storage data structure in ink! to find the best option which will be easy to use and well-optimized. Of course, it comes without saying that all OpenBrush default implementations are size optimized.
Standards
There is not much sense in talking about smart contracts if they’re not built upon the standards. Standards are very important for interoperability and in the Polkadot world, we have the Polkadot Standards Proposal (PSP), which is a community-driven repository for such standards. With the OpenBrush team, we developed and proposed three token standards: FT standard — PSP22, NFT standard — PSP34, and Multi Token standard — PSP35. Two of them are already accepted by the community, and the last one is in the finalization stage.
These standards are pretty much inspired by ERC20, 721, and 1155 but more advanced, keeping the Polkadot specifics, covering some missing features, and more open for extension.
What are our plans?
It’s hard to find a project in the Dotsama community that doesn’t support XCM — the Cross-Consensus Message Format, which is so crucial and so important for interoperability in the Polkadot. OpenBrush contracts are not an exception. We’re going to implement the chain extension for each kind of token standard introduced in OpenBrush. Thus delegating the storage to the substrate level instead of the contract level. Of course, we have to standardize it via PSP so that anyone in the network can achieve interoperability in smart contracts. These steps will, of course, reduce the size of the smart contracts and finally bring XCM support by default so that any PSP22 smart contract deployed to Parachain A can talk to another PSP22 smart contract on Parachain B.
New standards for WASM contracts
We plan to create an NFT2.0 token standard. Of course, we will create the chain extension and bring XCM support and in the same way, we’re going to introduce the multi-token standard on the substrate level and integrate it with the smart contracts.
Adoption
We have to fight for developers' attention as they are crucial players who push the community, so we have to make WASM smart contracts more attractive. Developers adore educational materials, and that’s why we’re going to create more educational content, articles, and videos and continue updating our documentation. We have already done three workshops, and we are going to make more and continue our social network activity. Talking about their marketing strategy, we are going to organize the hackathons and involve developers from different channels, and introduce the power of WASM smart contracts.
About Supercolony 🪐
Supercolony is a venture studio dedicated to converting business ideas into successful high-level companies, leading the development processes, improving and strengthening business models, and increasing market capitalization. Supercolony’s goal is ecosystem creation, taking leadership in moving the market forward, creating the vector of ecosystem development, and making the entrance points for businesses more accessible.
Our main mission is to make blockchain usable for everyone.
