The Astar Vision Part 3: The Innovation Hub of Web3.0
The Innovation Hub
As a platform for user-facing smart contracts, Astar strives to become the innovation hub of Web3.0. In Parts 1 and 2 we presented leveraging the unique features of a parachain via the XCM, extending smart contract language capability, and writing complex dApps with WASM contracts as the building block for innovation, yet, these tools are not enough. We believe that innovation starts by knowing what the users want. The dApps Staking mechanism strives to create an environment where the user of the dApp can express what projects they like, and support them as a result. Astar Network works as a user-facing contract platform because the end-users are the one who has the power to support a project, and project teams must build something that users will use in order to sustain themselves through the dApps Staking mechanism.
Through this, we encourage projects with innovative ideas to develop on Astar Network with all the tools we provide and form a community of supporters to sustain their project in a decentralized environment. Moreover, through XCM we believe Astar can become a hub of innovation and interoperability for our developers and users. We want to close our conversation of Astar’s vision by presenting examples of how we can build the future of Polkadot together.
Examples
We can think of several applications of XCM based on the current parachains, potential parachains, and hypothetical parachains; and how they become interoperable with Astar Network.
i. Tornado Cash with Manta
Manta Network is a privacy blockchain that uses UTXO and ZKPs to facilitate private transactions where the counter-party does not require the exposure of sensitive information like account balances to settle a transaction.
The simplest use case of Manta Network for a dApp on Astar would be a “Tornado Cash-like” privacy transaction protocol.
In this use case, the dApp will treat Manta Network as the layer 2 relayer-equivalent for Tornado Cash. Users can deposit their tokens by sending the asset to the Manta Network account, a single UI can control the assets by allowing transfers within Manta Network or withdrawing to a different address in Astar Network.
ii. Hybrid Lending Protocol with Centrifuge, Acala, and KILT
Centrifuge is a blockchain that bridges real-life assets and commodities with on-chain representations that can be used by DeFi protocols.
As the vision of Centrifuge states, the core value proposition for Centrifuge is its ability to provide real-life assets to DeFi protocols. This means that in theory, it will be possible for Astar Network to create a completely decentralized hybrid lending protocol that can collateralize real-life assets for crypto assets, and vice versa, further reducing the gap between on-chain data with reality.
Although this use case will be difficult, in practice for regulatory reasons and feasibility for corporations, with the use of a trusted network KYC like KILT, this will no longer be a problem.
KILT is a blockchain identity protocol for centralized identity verification and attestation. It aims to become the trust layer for blockchains, providing the opportunity for KYC for projects within the Polkadot network via XCM.
Without overcomplicating the architecture, someone can deploy a lending protocol on Astar Network that uses fungible assets brought from Centrifuge, and trade it with a stable coin like aUSD, or any other registered assets on Astar Network; a process similar to the RWA market on AAVE, but with much more flexibility and completely on the Polkadot ecosystem. With the power of KILT’s decentralized identity, we can provide a superior UX than that of the RWA market without going through a rigorous KYC process.
iii. Utility Smart Contract Repository with t3rn Network
t3rn is a composable smart contract platform with an interoperable smart contract failsafe for guaranteed executions. They offer an incentive mechanism for developers and teams who contribute to the open-source smart contract registry that anyone can use, and the contributor will be rewarded every time the contract gets called.
At a glance, we can see many similarities between t3rn and Astar as both of them are WASM smart contract platforms that focus on developer incentivization, and cross-virtual machine of interoperable smart contracts. Some might say that we are competitors with little opportunity for collaboration; and, any collaboration might lead to a zero-sum game of taking smart contracts and dApp projects from each other. However, if we define Astar Network’s position in the ecosystem as strictly a platform for user-facing dApp projects and t3rn as a strictly developer-facing smart contract platform, we can find a very interesting synergy that cannot be found between any other networks.
If we can establish a cross-environment arbitrary smart contract execution standard and open an XCM channel between the two networks, so that both networks can freely read, write, and call from a contract in a different environment (e.g., the XBI standard), then dApps on Astar Network can use utility smart contracts or smart contract libraries from t3rn (alongside features from other parachains)as part of their business logic for the end-user will interact with. In other words, t3rn network can become the NPM or cargo for smart contracts that projects on Astar Network can fully utilize. The library contract developer on t3rn will be rewarded by the system itself, and dApps on Astar will be rewarded by the users through staking, making t3rn an ideal smart contract development environment for Astar.
iv. Universal NFT Marketplace with Statemint, Efinity, Unique Network, and other NFTs
Statemint is a common-good parachain on Polkadot Network for storing state data and custom asset data for the benefit of the entire Polkadot ecosystem. RMRK (pronounced “remark”) is a project built on top of the Polkadot ecosystem, without becoming a parachain, that provides a standard method for creating an NFT on the Kusama relay chain and Statemine/Statemint. Unique Network is a blockchain that focuses on scalable and extendable NFT assets for various use cases. There are several other NFT blockchains or standards that are used throughout the Polkadot ecosystem, but, for this section, we will mainly focus on the two projects.
The Polkadot ecosystem has a major problem with highly fragmented standards amongst the projects. This is most apparent when representing NFTs, as the Substrate framework can support EVM standards, WASM contract standards, and pallet-level NFTs. To be precise, currently, we have the Substrate Uniques pallet, ORML NFT pallet, ERC721 on EVM, PSP34 on WASM contract environment, and several custom-made NFT pallets for certain networks. All of these standards are not compatible with each other in the traditional sense–users cannot manage all of their NFTs from a single place and developers cannot create a generic solution for managing all NFTs throughout the ecosystem (e.g., Polkadot NFT wallet, or marketplaces). This is because before XCM, parachains, and projects in the Polkadot ecosystem are very isolated without any need for pallet standardization. A lack of standardization helps the project to customize and rethink the fundamental concept of NFT to create an innovative solution, but this hurts interoperability in the long run. For example, Unique Network has a unique (pun-intended) NFT pallet that allows custom functionality that is only possible within their network. This means that even if we can teleport the NFT from Unique to a different network, this will strip away the extended feature that can only be used within Unique Network, making some NFTs effectively worthless. This is a problem because we might want to access the mature marketplace and wide array of applications in the metaverse that Efinity provides alongside other NFTs, such as Unique Network, in parallel.
Astar Network is a blockchain with multiple smart contract environments (EVM and WASM) and multiple standards. We also have one of the biggest NFT marketplaces in the Polkadot ecosystem. We believe that Astar Network is capable of becoming the common denominator for various NFTs throughout the ecosystem, and we believe that there is a way to gather all NFTs in the ecosystem into a single universal marketplace that allows anyone to trade, sell, and purchase NFTs from Astar Network without losing any custom functionalities that are only available on a certain chain.
Let’s say we have an NFT marketplace dApp that can support NFTs in both the WASM contract environment and the EVM environment. In this case, bringing the ERC721 NFT from a foreign chain to Astar’s marketplace is as easy as teleporting the NFT to Astar via XCM. Alternatively, the NFT marketplace dApp could decide to integrate directly with the other chain to become a multi-chain marketplace. The same can be said for PSP34 NFTs.
However, this is not applicable for NFTs that are stored at the pallet level without losing certain features or creating a custom adaptor, especially ones that rely on the pallet’s custom functionality, like those on Unique Network. Teleporting might not be a feasible option for the network or the user, and asking the UI to implement it for all cases and networks will be a developer nightmare. But if we use XCM, there is a way to enable full marketplace access without losing any custom features of the foreign network. We can do this by creating an XCM NFT controller contract that shares the PSP34/1155 interface. The controller contract will contain the asset metadata and ownership data of the NFT that exists in the foreign network’s state, effectively creating a shallow copy of the original asset on Astar Network. The owner of the original NFT can sign the transaction for the controller contract on Astar, which will initiate a remote transfer on the foreign parachain where the original exists, and transfer the NFT on behalf of the owner. The controller contract will change the owner of the asset accordingly.
This way, we can have the full metadata of the NFT and the ownership proof in a PSP34/1155-compatible format on Astar Network. So, with a single account users can interact with NFTs from various networks without losing the unique features of the NFT since the ownership of the original asset will be the same as the mirrored ownership on Astar Network. Furthermore, developers will only have to integrate with the Astar RPC and implement the PSP34/1155 and ERC721/1155 interface to access all the NFTs throughout the Polkadot ecosystem.
This is just the tip of the iceberg on how developers on Astar Network can leverage the power of XCM, and how parachains can work together to create an innovative one-of-a-kind dApp. Some of the example use cases described in this paper may not be feasible in practice, some features might not be possible with the current version of XCM, or the development process can be unbelievably complex for anyone to make it.
But imagine if a utility smart contract is dedicated to sending XCM calls for specific extrinsics on a parachain deployed on Astar Network. All developers must do is load from that contract to utilize what the parachain can offer to their dApp fully. With the right tools, the right mind, and progress from the ecosystem, we believe that this will be the future of dApps in a heterogeneous network of blockchains.
XCM via WASM Smart Contracts
The Substrate contract pallet (also known as the WASM Smart Contract environment throughout this paper) is a contract execution environment that WebAssembly powers at the native Substrate level. Thanks to this, WASM contracts on Substrate do not face EVM’s overhead, and it has wider language support such as ink! (Rust) and ask (AssemblyScript) at the moment, with more to come.
The combination of extensive language support and increased performance (through reduced overhead) means that developers can create complex dApps that are difficult to build only using Solidity on EVM. Another important component of WASM contracts on Substrate is the concept of chain extensions. Chain extensions allow the smart contract to read directly and execute pallets from the network. And because the language of Substrate and ink are more or less compatible, communicating with pallets and other native on-chain data will not be difficult.
Suppose we have a chain extension for the XCM pallet on Astar Network. In that case, we can create custom XCM transfers from a smart contract executed on-chain, allowing dApps to interact with other foreign parachains directly from the smart contract. Because the ink’s syntax is very close to native Substrate pallets, it will be much easier to compose and utilize parachain unique features from ink rather than create everything from scratch using Solidity. In other words, the hypothetical complex use case described in the previous section can only be realized through WASM smart contracts!
How will this look in action? In Astar Network, when we open a new channel between different networks, we will also consider the features the network can provide to our ecosystem projects. For each channel, we will create a parachain interface contract that will directly compose the XCM instructions and expose the main features of the parachain as a function for the contract. Projects on Astar Network only have to load the contract with the correct traits, and they can call that from their contract. Through this mechanism, projects can use the power of other parachains from their smart contract without having to understand anything about XCM or XCMP.
Let’s use the KILT Protocol as an example. To oversimplify things, KILT’s core features can be divided into the following components:
- Create DID accounts
- DID that can be linked to a Web3Name (also query the Web3Name)
- Request attestation for a claim
- Issue credentials
- And verify a credential
These could be further abstracted into a function interface that can be called from a smart contract. Note that this interface is only used as a basic example for illustrations purpose, so some technical details are ignored.
interface IXCKilt:
LinkDidW3N(sender, did): void
QueryW3N(account): bytes
VerifyCredential(presentation, challenge): trueOnce we have the interface for a parachain, we will develop an interface contract that will directly interact with the parachain by composing XCM instructions that will execute the features that the interface exposes. For the dApp developers, they will load the contract from the interface contract address and implement the traits to access the functions. In other words, the dApps will have no idea of the XCM instructions and still be able to use the core features of another parachain that is not possible within Astar natively.
You might notice that there is no function for requesting attestation or issuing a credential for the contract interface. There are two reasons for this. One is that some of these functions must require the signature of an external account (the identity), meaning that the signature cannot originate from a smart contract. For the second reason, even if the origin of these functions could be somehow delegated to a smart contract, there is no added value for moving these features to the chain, as attestation issuance and request can be made from the client side as long as the user is the owner of their key. However, verifying an attested credential could be a critical part of the contract logic as that is not something you cannot delegate to the client application without getting a centralized system involved in your dApp logic. Note that due to the current limitations of XCM and the protocol behind it, some features like response query or the lack of proper asynchronous blockchain syntax, the example I presented above may not be technically feasible at the current state. But this should not prevent us from thinking about what could be possible in the future with enough ingenuity. I will discuss this in detail in the next section.
WASM smart contract development with ink or ask and XCM with chain-specific features is a new concept for dApp developers. Documentation, education, and standard API will be crucial for developer engagement. This should be the responsibility of both Astar Network and the integrating parachain to clarify the value proposition of a certain XCM channel and how dApp developers can use its API to create something that the end-user can use. To encourage innovation, Astar Network will open and accept XCMP channels based on the community or leading team’s proposal of how their parachain could be used by dApps on the Astar ecosystem. Once the proposal is accepted, the parties involved in the operation should jointly work on the interface contract. If the community or the incoming parachain decides to implement the interface directly, the parachain interface contract could be listed on dApps Staking and incentivized to maintain the project.
Limitations and Considerations
Due to the nature of XCMP and the blockchain, it does not make sense for all parachain calls to be executable on the chain by the contract. We can consider the following limitations and considerations when using XCMP for certain applications.
- XCM is asynchronous: Due to the nature of cross-chain functions, there cannot be any guarantees for any cross-chain functions. This is similar to real-life servers, as delegating any operation to a system with a different clock cycle (or even a different thread) is essentially a black box in the perspective of the local process.
- XCMP cannot be finalized in a single block: This is similar to the above point but from a different perspective. Because XCM is asynchronous, no operations can be finalized in a single block. Any operation that depends on block-by-block operations will never be usable via XCMP. For example, oracles or VRF could easily be comprised if used over XCMP. This problem will also affect the user experience of applications like DeFi or dApps that could be created and used from a single blockchain but through XCMP as they take longer to execute than deploying on a single chain.
- No one can trust a parachain over XCMP: XCMP in the Polkadot ecosystem means connecting and sending instructions across different blockchains. However, XCM is only the instruction and the message format, which means it is unaware of the implementation and the representation of the message being sent. These implementation details are left up to the individual parachains. Furthermore, Substrate blockchain allows forkless runtime upgrades, which means that any function of a parachain can and will change without being noticed. Not only that, but a parachain could also lose its lease period if it fails in the slot auction. A smart contract that relies on a parachain that could change its feature at any time will lead to disaster.
- XCMP is a pallet, and parachains are a sovereign state machine: Unlike a traditional system or a custom bridge, Substrate extrinsic call has a very specific architecture. At the same time, parachains are state machine that uses pallets for customized transactions. This means that XCMP inherently shares the limitations of a pallet. Another thing to consider is that every XCM instruction sent to another parachain is executed in the state context of the receiving parachain. This means that if there is an unexpected state change in the other parachain that you want to communicate to, this will result in state differences that your dApp did not account for. At the same time, checking for all chain states for corner cases may result in inefficient execution.
With these in mind, you can see that XCMP is not a magical God bridge that can unify blockchains into one. Instead — just like all technologies — XCMP has a clear limitation. Instead, we should look at XCM as something that will create a message that describes a common standard for universal concepts amongst various blockchains like accounts systems (Ethereum, Substrate, and Cosmos), and XCMP as something that facilitates cross-chain executions using XCM instructions.
The Astar Vision
Some of the example use cases described in this paper may not be feasible in practice, some features might not be possible with the current version of XCM, or the development process may be too unbelievably complex for anyone to actually make it. But imagine if there is a utility smart contract that is dedicated to sending XCM calls for specific extrinsics on a parachain deployed on Astar Network, and all developers have to do is load from that contract to fully utilize what the parachain can offer to their dApp. With the right tools, the right mind, and progress from the ecosystem, we believe that this will be the future of dApps in a heterogeneous network of blockchains.
Part 1 here: https://medium.com/astar-network/the-astar-vision-part-1-interoperability-and-multi-chain-dapps-30f014087831
