I want to know the differences between parity ink vs. runtime module. does runtime moudle manages state transition without fee whereas parity ink smart contract take fee for extrinsics?

​

Answer by shawntabrizi :

📷hskang9: I will give the distinction my best shot, but take this with a grain of salt.

Runtime Modules and Smart Contracts are two completely seperate platforms for building "decentralized applications" (I think there might be a better term here, but I am saying that blockchains themselves are decentralized applications, as well as smart contracts).

The traditional smart contract platform allows users to publish additional logic which lives on top of the underlying blockchain logic (the runtime). Since this code can be published by anyone, including "malicious actors", there are intentionally a number of safe guards built around the smart contract platform. Some examples are:

• Fees: Ensuring that contract developers are charged for the computation they force on the computers running their logic, and not allowed to abuse the block creators.
• Sandbox: A contract is not able to modify underlying runtime storage or the storage of other contracts directly.
• Taxes: A contract takes up space on the blockchain, and thus should be charged for existing at all, ensuring people don't take advantage of esentially "free, unlimited storage"
• Revert: A contract can be prone to have situations which lead to errors, and 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. This overhead makes running contracts slower and more costly, but again, the "target audience" is different, and of a lower bar than runtime developers.

Furthermore, 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 could even be 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.

Runtime modules on the other hand afford none of these protections or safe guards. As a runtime developer, the bar on the code you produce jumps way up. You have full control of the underlying runtime logic that your network will run. You have full access to each and every storage item, which you can modify and control. You can brick your chain with incorrect logic or poor error handling.

With the intention of being lean and having 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. When developing runtime functions, it is up to you to correctly asses and apply fees to the different parts of your modules such that it will not be abused by bad actors.

Modules and contracts are tools available to you to solve problems. There is likely some amount of overlap in the kinds of problems they can solve, but there is also a clear set of problems suited for only one of the two. For example, only at the blockchain runtime level can you reasonably set up something like a UTXO blockchain system.

In the end, you need to determine what the problem you are trying to solve is, and which tool is best suited for that need.

I think this Substrate is really the first time it has been so easy and approachable to build runtime logic, so in the past, everyone built their "idea" using smart contracts (aside from the brave few who forked or build entirely new blockchain systems from scratch. With the introduction of Substrate, there is a new tool available for building your decentralized applications, but that does not mean all of your ideas should be a Substrate module. Instead, for the first time, we have two tools, and as a community, we may even need to figure out together which one is best to use for each scenario... but we can make some educated guesses :)

Refer also to:

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