22

What are the differences between developing a Substrate FRAME Pallet and a Substrate Smart Contract (for example with the ink! language)?

What are some examples of applications which are best written in one form or the other?

Original: https://stackoverflow.com/questions/56040779/when-should-i-build-a-substrate-runtime-module-versus-a-substrate-smart-contract

Improve this question

3 Answers 3

Reset to default
26

Substrate Pallets and Substrate Smart Contracts are two different approaches to building "decentralized applications" using the Substrate framework.

Smart Contracts

A traditional smart contract platform allows users to publish additional logic on top of some core blockchain logic. Since smart contract logic can be published by anyone, including malicious actors and inexperienced developers, there are a number of intentional safe guards built around the smart contract platform. Some examples are:

  • Fees: Ensuring that contract developers are charged for the computation and storage they force on the computers running their contract, and not allowed to abuse the block creators.
  • Sandbox: A contract is not able to modify core blockchain storage or the storage of other contracts directly. It's power is limited to only modifying it's own state, and the ability to make outside calls to other contracts or runtime functions.
  • State Rent: A contract takes up space on the blockchain, and thus should be charged for simply existing. This ensures that people don't take advantage of "free, unlimited storage".
  • Revert: A contract can be prone to have situations which lead to logical errors. The expectations of a contract developer are low, so extra overhead is added to support reverting transactions when they fail so no state is updated when things go wrong.

These different overheads makes running contracts slower and more costly, but again, the "target audience" for contract development is different than runtime developers.

Contracts can allow your community to extend and develop on top of your runtime logic without needing to go through all the craziness of proposals, runtime upgrades, etc... It may even be used as a testing grounds for future runtime changes, but done in a way that isolates your network from any of the growing pains or errors which may occur.

In summary, Substrate Smart Contracts:

  • Are inherently safer to the network.
  • Have built in economic incentives against abuse.
  • Have computational overhead to support graceful failures in logic.
  • Have a lower bar to entry for development.
  • Enable fast pace community interaction through a playground to write new logic.

Pallets

NOTE: Pallets use to be called Runtime Modules.

Pallets on the other hand afford none of these protections or safe guards that Smart Contracts give you. As a runtime developer, the bar to entry on the code you produce jumps way up.

You have full control of the underlying logic that each node on your network will run. You have full access to each and every storage item across all of your modules, which you can modify and control. You can even brick your chain with incorrect logic or poor error handling.

Pallet development has the intention of producing lean, performant, and fast nodes. It affords none of the protections or overhead of transaction reverting, and does not implicitly introduce any fee system to the computation which nodes on your chain run. This means while you are developing runtime functions, it is up to you to correctly asses and apply fees to the different parts of your runtime logic such that it will not be abused by bad actors and hurt your network.

In summary, Pallets:

  • Provide low level access to your entire blockchain.
  • Have removed the overhead of built-in safety for performance.
  • Have a high bar to entry for developers.
    • Not necessarily to write working code, but to avoid writing broken code.
  • Has no inherent economic incentives to repel bad actors.

The Right Tool For You

Substrate Pallets and Substrate Smart Contracts are tools made available to you to solve problems.

There is likely some amount of overlap in the kinds of problems each one can solve, but there is also a clear set of problems suited for only one of the two. Two give just one example in each category:

  • Pallets: Building a privacy layer on top of transactions in your blockchain.
  • Shared: Building a DApp like Cryptokitties which may need to build up a community of users (leaning toward Smart Contract), or may need to scale to millions of transactions a day (leaning toward Pallets).
  • Smart Contract: Introducing 2nd layer tokens and custom assets to your network.

In addition to everything written above, you also need to take into account the costs to set up a DApp using a certain tool. Deploying a contract is a relatively simple and easy process since you take advantage of the existing network. The only costs to you are those fees which you pay to deploy and maintain your contract.

Setting up your own blockchain on the other hand has the cost of building a community who find value in your service or establishing a private network with the overhead of cloud computing system and general network maintenance.

I think that now is really the first time it has been so easy and approachable to build runtime logic. In the past, everyone built their "decentralized application idea" using the tool available to them, Smart Contracts, even when that wasn't the best tool for the job.

With the introduction of Substrate, there is a new tool available for building your decentralized applications; but again, it would be wrong to think that all of your ideas should be a Substrate Pallet.

Instead, for the first time as a community, we have two tools, and we need to figure out together which one is best to use for each scenario. I don't think all the answers to this exist today, but we can learn and make some educated guesses along the way.

Improve this answer
4

Beyond the engineering tradeoffs correctly outlined above (tradeoffs of economic costs, responsibility and margin for error), there's a high level and fundamental difference between smart contracts and pallets this answer could benefit from outlining:

  • The runtime of a Substrate chain is composed of pallets, some of which can also be pallets that enable smart contract execution. In this way, comparing the two is like comparing apples and oranges: a runtime engineer can extend the underlying execution logic and capabilities of a chain using pallets, whereas a smart contract engineer develops applications on-top of some existing execution model (for example, pallet-contract or pallet-evm).
  • What a smart contract can provide in terms of user facing interactions is a subset of what a pallet can provide. Pallets can be used to write more complex functionality, for example modifying the fee system of the chain, adding a multi-asset payment system or giving a reward to certain users every n blocks.
  • Smart contracts can be written by anyone, added and removed at any time, while pallets are part of the runtime and can only be added or modified using on-chain governance via a runtime upgrade.

All in all, pallets are suited for developers building application-specific blockchains, whereas smart contracts are suited for developers building applications on-top of a blockchain specialized for executing smart contracts.

Improve this answer
1

This article has quite a few strong points between smart contract vs runtime development.

It aims to provide insight on reasons for choosing smart contract development over runtime development for your on-chain logic.

The Polkadot wiki has some notes on this:

Also related, a nice blog article on using both pallets + smart contracts: "hybrid chains":

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.