Hybrid dApps and the future of Smart Contracts

Post Material after WASM conference 2022

Historically, there were only a few options when building a blockchain protocol: build using smart contracts and deploying it to either Layer 1 or Layer 2 blockchains, or building it as a Layer 1 or a Layer 2 blockchain. Each option has its own advantages and disadvantages, but there are always some trade-offs. However, there is a third option that is currently fairly unexplored. We can decide on both options simultaneously. Getting the best of both worlds is achieved by thoughtfully designing the architecture of components and creating a hybrid DApp that utilizes the advantages of both approaches mentioned in the beginning. The ability to build a blockchain and smart contracts using the same language (e.g. Rust), which are running within the same virtual machine (e.g. WASM), opens up many interesting and possibly revolutionary possibilities to be discovered.

Acala and the Protocol Setup

Acala is the decentralised finance network powering the aUSD (native multichain overcollateralized stablecoin) ecosystem. aUSD is the native decentralised stablecoin of Polkadot Polkadot and Kusama, and can be easily and trustlessly integrated into parachains and DApps. aUSD protocol implements advanced risk management mechanisms such as on-chain keeper system and Quality of Service for Oracle price feeds.

Acala leverges unique features powered by Substrate and Polkadot’s shared security & crosschain interaction protocol to deliver a solid foundation to build a new generation of DeFi protocols. By offering both pallets and smart contracts protocols, new innovative ideas can be implemented benefiting from the hybrid DApps architecture.

Acala has three native supporting protocols:

• Homa Liquid Staking powering LDOT/LKSM staking derivatives as high-quality collateral for aUSD and an essential building block for DeFi on Polkadot
• Acalaswap is an evolving DeX aggregator. Its core purpose is to enhance the liquidation mechanism for aUSD and power `pay fees in any token` feature of the Acala network.
• EVM+ that brings together the best of Substrate pallet development and smart contract development; it empowers Acala to be the multi-chain liquidity hub, where smart contracts can integrate Polkadot-native assets seamlessly as ERC-assets, and ERC-assets can become Polkadot-native assets and trustlessly cross to any other connected parachains. EVM+ also allows developers to build Hybrid DApps that integrate with native pallet protocols and leverage powerful Substrate features such as auto-scheduler.

Examples of different types of DApps

1. Core protocols built using pallets: aUSD Stablecoin, Liquid Staking, and Acalaswap.
2. Smart contract dapps: Wormhole (multichain bridge), Citizend (Compliant Polkadot Launchpad), Project Venkman (Loyalty and NFT platform for real world businesses)
3. Hybrid protocols that built with both pallets and Smart Contracts: Taipo (stableswap and synthetic asset) and Kujira (liquidation marketplace)

Compiled versus scripted approach

When teams are considering building their solutions in the Polkadot ecosystem, they often consider whether they should build a pallet or a smart contract. Determining the best option requires understanding the advantages and disadvantages of pallets and smart contracts, and how they compare to each other. Interestingly, the comparison is similar to between choosing a compiled language (e.g. C++, Rust, Go) versus choosing a scripting language (e.g. JavaScript, Python, Ruby) when building a web2 project.

Advantages and disadvantages of pallets

The primary advantage of building a pallet is the ability to access the raw performance of the platform. This way the application is faster and uses less memory or storage. It also means the application has direct access to the low-level features and can use various advanced APIs that might be available. Since the ability to access the low level primitives translates to more optimization possibilities, the performance cannot be matched using smart contracts.

The downside of using the pallet approach is the development, deployment, and execution feedback loop is usually much longer for pallets than it is for smart contracts. This is because the whole runtime usually takes longer to build, the changes can affect multiple other modules, and additionally the deployment of the runtime usually requires a long governance process, similar to a long review process when deploying a native app to an app store. The ability to access the low level primitives can be powerful but introduces additional security aspects to consider at the same time. These include, but are not limited to, logic errors, resource exhaustion errors and denial of service attack vectors. If the runtime panics, the blockchain is likely to be bricked and can be very hard to restore. Adding up all the potential pitfalls of the pallet approach means there is a very steep learning curve, because there is a significant amount of knowledge required besides just writing business logic.

Advantages and disadvantages of smart contracts

Compared to pallets, smart contracts offer a fresh set of advantages and disadvantages. The chief advantage of smart contracts is that they are more accessible. The deployment of smart contracts is usually permissionless, so anyone with enough funds to pay for the transaction fee can deploy their own smart contract. This is similar to when applications offer the ability for external developers to write and deploy plugins using a scripting language. Another benefit of smart contracts is the development and deployment cycles are usually faster, as there is less compilation required, and deployment is easier and faster. This can improve productivity by allowing developers to have a shorter feedback loop and can adjust the code based on the actual execution quicker. Smart contracts, as well as scripts, are usually executed within a sandbox. While this means there might be restrictions on what can be done, it also means the code can’t do things it’s not supposed to (unless there is a critical vulnerability in the sandbox). Security is still the top priority of any smart contract, but in case anything goes wrong, the sandbox will ensure only the faulty smart contract (and the contracts that depend on it) are affected, and won’t will not damage the underlying platform. Another benefit of smart contracts is developers only need to focus on the business logic without worrying about many additional details. This means they have a more gradual learning curve and are easier for new developers to get started.

Running inside a sandbox also introduces additional overhead. This means the application might be slower and use additional resources due to the overhead. Since the application can only access features exposed by the sandbox, it may not access some of the more advanced features that are deemed potentially unsafe. The smart contract can only execute whatever the platform allows it to.

Hybrid approach to DApp design

We observed the advantages and disadvantages of both approaches. However, if we thoughtfully approach the design of our application components, we can create a hybrid application that utilizes the benefits of both approaches, while avoiding as many of the disadvantages. This approach has already been employed to address various use cases, such as game engines, IDEs and automation tools. Game engines are usually written in system programming languages such as C or C++, since they are very sensitive to the performance and resource usage. They also require direct control of the execution and all the resources.However, to improve the productivity of game development, most of the game engines can embed a scripting language for the game logic that is not performance sensitive. IIt creates a possibility for third party developers to create custom mods and add additional features to the game. Developers have the ability to build new games on top of an existing game. Another example are IDEs and advanced text editors. Most of them support third-party plugins that allow third-party developers to create and publish plugins to further enhance their functionality. It’s relatively easy to create a new plugin for an IDE to support a new language, with no IDE team to get involved at all.

Examining how traditional applications employ the hybrid approach can provide some insight into how a similar approach can be utilized when building a DApp. Much like the game engine design, where the performance sensitive features are implemented in a compiled programming language, the compute-intensive operations should be implemented in the pallets to avoid the extra overhead and expose them in a way that they are accessible to the smart contracts. Many features, like initialization on hook and transaction fee customization, are unsafe to be exposed to the permissionless smart contracts directly. However, it’s safe to expose a limited set of those functionalities for a specific purpose to allow smart contracts to utilize those advanced features as well.

For example, it’s possible to pay a transaction fee in Acala using any ERC-20 token that’s listed on Acala Swap. Because of security requirements and the nature of decentralized governance, it’s imperative for the runtime upgrade process to be slow. This means it can take a significant amount of time to have new changes to pallets deployed. For this reason, the pallet code needs to be stable, and the code that requires frequent modifications and upgrades should be implemented with smart contracts, which can be upgraded relatively quickly, depending on the governance configuration. For example, the token fee model can be implemented in smart contracts to allow anyone to propose their own model and use governance to decide which one shall be selected. Smart contracts can enhance pallet code. We can use smart contracts to implement more advanced batch transaction mechanics to smartly execute multi step actions automatically based on various conditions. This can make advanced yield farming strategies easily accessible to everyone. We could also use smart contracts to complement pallets. For example, we can implement a passive liquidation pooling strategy to participate in stablecoin liquidations on off-chain liquidation bots to actively participate in liquidations. These are just a few examples of what can be done. There are a lot more interesting applications of hybrid pallet approaches that could change how we are building DApps.

Another advantage of specifically building using ink! and WASM smart contracts if they are powered by the same tool that powers a Substrate chain: Rust and WASM. This means sometimes you don’t even need to decide where the logic will be executed initially. With the right abstractions, you can design the logic to be generic and runnable within both, pallets and smart contracts. This provides the freedom to explore the best way to structure the components without committing to one option too early into the development. We can share a lot of code between the pallet and the runtime because of it. For example, XCM has defined many structures that would be cumbersome to redefine in other languages. But with ink! we could theoretically just import the crate from Polkadot and have an up-to-date definition of XCM. The ability to share code and interfaces between pallets and smart contracts can significantly reduce the effort required to build and maintain a hybrid app and eliminate a category of bugs caused by mismatched interfaces. This also provides a graduation path for smart contracts. People can prototype and launch their project with smart contracts, deploy to one of the parachains that support smart contracts and later, if needed, can upgrade them to a parathread or parachain by reusing most of the existing code.

DApps The Future of Blockchain

Among the hindrances of blockchain application advancement or DApp development is the complexity in design approach; developers must select either the pallets route or smart contract route and accept the pros and cons of each option. However, with the hybrid design, developers can leverage the best of both worlds.

Traditional applications like games demonstrate the effectiveness of utilizing different approaches to deliver an efficient, performing application. Applying the same concept to DApps encourages inventive thinking on DApp development. Smart contracts and pallets when used tactfully and with purpose, both technologies can synergise to facilitate complex logic execution in advanced industry scenarios.

The hybrid model provides a path for developer integration and advancement in the world of blockchain. The code sharing ability between smart contracts and pallets through the hybrid model encourages gradual developer improvement in DApp design, and the code and interface exchange between smart contracts and pallets can inspire developers to continue building with the goal of constantly upgrading or improving their DApps as they better understand the hybrid model.

Thus, hybrid application highlights the future of smart contracts, one where developers use them as stepping stones to create holistic, strengthening platforms.