This post is part of a series on Web 3.0 Development with Substrate.

Pallets are pluggable modules that extend the basic design of a runtime and allow the blockchain to expand its business logic over time. Pallets operate as building blocks within the Substrate Framework: they determine the kind of DApps that can be built and deployed on a Substrate blockchain. In this article, we consider how Pallets are used to generate back-end services for a wide range of DApps.

Composable legos

As we have previously seen, pallets are built according to the FRAME standard to support runtime development. The Substrate runtime is not a static immutable object: it encapsulates the evolving business logic of a Substrate blockchain. As such, the Substrate runtime can be conceptualised as an engine that is made of core parts (Types), that can interact with on-chain and off-chain data (Events and Extrinsics) and alter the state of the blockchain (Storage). At a basic level, it is therefore possible to use the Substrate runtime as a back-end server for a variety of DApps.

The FRAME standard has been released in two versions and each of them can be used to create pallets with variable functionalities. In FRAME v1, pallets have five core sections, meanwhile in FRAME v2, two extra sections have been added. Individual pallets are composed of different data structures, storage items, functions, hooks and APIs that can be used to update the runtime of an application-specific blockchain at any point in time. Although these components are declared in the different sections of the pallet according to a standardised structure, they do not follow the same configuration settings. When adding pallets to the runtime, developers must always ensure that they are importing the correct pallet crates before adding the pallets and updating their nodes.

Standalone modules

With Substrate, runtime development can be used to provide back-end services for DApps, however this comes with a higher bar to entry for developers and also requires constant monitoring of the code to manage safety and performance benchmarks. To improve the security, scalability and efficiency of DApps, Substrate uses standalone modules for Smart Contracts (SC) development: Contracts pallet and EVM pallet. With the Contracts pallet, Substrate runtimes can deploy and execute WebAssembly (Wasm) SCs, meanwhile the EVM pallet is used to execute Ethereum Virtual Machine (EVM) SCs in a Substrate chain.

For a Substrate runtime, a user account and a SC account created with the Contracts pallet bear no difference. In reality, a SC account has the ability to modify a SC’s code, make contract calls and manage storage rent charges. This is possible because the Contracts pallet separates the SC logic from the SC account. By contrast, all SCs implemented via the EVM pallet strictly follow the logic of Ethereum by which a SC locks permanent storage on the blockchain, yet cannot be repaired nor upgraded. From this perspective, there is a strong incentive for entry-level and beginner developers to start their DApp development career in the Substrate ecosystem.

Creating a robust and secure back-end for DApp is a straightforward experience with Substrate, thanks to standardised runtime builds and interoperable Smart Contract pallets. Developers that are new to the Substrate ecosystem will find a growing number of ready-made recipes and client libraries that can be used to optimise their DApps from the get-go. We will review some of the runtime APIs and RPC endpoints exposed by Substrate pallets in Part 7.

References:

Substrate Developer Hub: Prebuilt pallets

Substrate Developer Hub: Smart Contracts vs Runtime Development 

Ethereum Developer Resources: Smart Contracts