Substrate Runtime Module Development vs Ethereum Smart Contract Development

[shawntabrizi]

Update 3/25/19:

I think it is reasonable hypothesis that people who are looking to develop on Substrate are familiar with or have worked with Solidity in the past. People who are less technical may be able to evaluate which kinds of apps would be suitable as an Ethereum smart contract (business oriented) and those who are actual contract developers may have developed thought processes or patterns for smart contract development.

I want to have a doc which specifically targets these people who are "comfortable" with Ethereum, and states clearly the differences in thinking and development when building on substrate.

For example:

• What sorts of projects would be good for Ethereum Smart Contracts vs Substrate Runtime Module, and why?
• Substrate is inherently a fee-less system, and how that affects your development and functions you can build
• Storing only critical blockchain specific data on chain, not strings and other random stuff
• Bricking your chain with bad code
• Verify first, Write Last vs Revert
• How to write modular substrate modules versus how you might do the same with solidity
• etc...

[joepetrowski]

Wrote this the other day for the web 3 wiki. Has NOT been reviewed and is quite high level. I haven't developed much in Solidity, so I'm not the most qualified for a deeper analysis. But, this might help someone get started:

What is the difference between a parachain and smart contract?

Polkadot provides two ways for you to deploy your application: as a smart contract on an existing parachain, or as your own parachain. There are tradeoffs when working with each one, and this section will help you understand them.

Parachains are individual chains, with their own runtime logic, that benefit from the shared security and inter-chain message passing provided by the relay chain. Parachains permit a high degree of flexibility and customization, but require more effort to create.

In the Polkadot mainnet, there will be one (or more) parachains that act as smart contract platforms. Smart contracts are executable programs that exist on a single chain. By grace of being on a single chain, smart contracts have smooth interoperability. However, all contracts on that chain are limited by the characteristics of the chain.

If you want to have control over the design and features of your application, a parachain is usually the better choice. Smart contracts can be a great testing ground before putting in the effort required to launch a full-fledged parachain, and will have more tooling, like IDEs, to get started.

Using a parachain allows you to build your monetary system from the ground up. For example, you can have:

• Custom fee structure (e.g. flat or by byte)
• Custom inflation policy
• Treasury to act as a DAO
• Governance to manage the DAO

A parachain opens the possibility to construct complex runtimes that would be too expensive to execute on a smart contract. That said, the tradeoff that allows complex runtimes is that parachains omit a gas-metering system. Any logic that requires iteration with an unknown number of computations - e.g. numerical convergence - should go in a smart contract where the gas is metered or off-chain. At Parity, we are also building tools for verifiable, off-chain computation.

You can also harness a combination of parachain and smart contract. If you have loops that cannot be removed, use the runtime for the complex logic and call the smart contract to handle iteration.

	Parachain	Smart Contract
Ease of development	-	+
Ease of deployment	-	+
Ease of maintenance	-	+
Level of complexity	+	-
Strict resource control	-	+
Level of customization	+	-

[folsen]

Ease of development is... complicated, I wouldn't say you could put a + or a - on either side. They're different. A simple chain that's only supposed to do something very easy (like manage a UTXO set) is actually relatively easy to implement, a hell of a lot easier than a smart contract like MakerDAO. But implementing MakerDAO as a Dappchain is probably easier than as a smart contract.

It depends on what you're trying to achieve, I would say that parachains and smart contracts are very different in nature so comparing their development difficulty might not make sense?

Not sure how others feel about that

[joepetrowski]

Yeah, totally fair. It makes sense to remove that because the point of the entire piece is to help you decide which one makes sense for your project, not which one is easier.

Polkadot/parachain should also be completely removed and replaced with Substrate chain or dappchain or SRML chain.

[shawntabrizi]

I have written a clarification paragraph for this issue on the original post. It is not clear to me exactly what this content will look like, but I hope that the goals listed above resonate with you all. Feel free to give your perspective.

[4meta5]

I wrote a very high-level blog post on Dapps vs Dappchains; relevant part:

Dapps

The advent of smart contract platforms like Ethereum enabled rapid prototyping. By providing a sandboxed and secure execution environment, these platforms paved the way for innovation by appealing to developers. Keeping a global store of account balances fosters statefulness, thereby simplifying implementation logic in the context of basic value transfer as well as smart contract interaction. The technical burden placed on developers is also eased by the fact that users pay for the resources used. In the end, these factors decrease barriers to entry for curious developers and encourage innovative prototyping.

A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty. Ethereum Whitepaper

Although public smart contract blockchains simplify development, applications built on these platforms are still forced to accept the tradeoffs decided by protocol developers. This often translates to sacrificing privacy as well as scalability. By default, transactions stored on-chain are not encrypted and can be tracked by anyone watching the chain. Moreover, the spillover effects of heightened demand for a single DApp (ie Cryptokitties) can make interaction with all other deployed contracts prohibitively expensive.

Later Section on Not Abusing Substrate

Although Substrate provides increased freedom and flexibility, not every blockchain use case requires its own blockchain.

It doesn't make sense to take a jet for a 10 km commute.

For common token transfers, basic timestamping, and other simple blockchain use cases, existing smart contract platforms are still preferrable. By implementing computational metering and conditional transaction reversion, public smart contract platforms are conducive to non-upgradeable applications that require only occasional interaction with the blockchain.

Additionally, public smart contract blockchains foster rich composability between deployed contracts. With a few existing public blockchains experiencing significant network effects, it may be advantageous to initially prototype on these platforms. When a DApp needs to scale to production, developers can migrate the smart contract logic to a Substrate-based DAppchain to enjoy increased efficiency as well as flexibility with respect to future upgrades.

I want to work more on this so I'll start collecting more examples of when it's appropriate to use smart contracts vs runtime module development.

[4meta5]

I'm going to port MolochDAO (minimally viable DAO in Solidity) to Substrate. I'll learn a few things along the way and then reassign myself once I finish this sample.

[ltfschoen]

To help Solidity developers who are migrating to ink! gain confidence in the product, would it be worthwhile to show with each ink! smart contract what it's equivalent would be in Solidity (i.e. in the Substrate Contracts Workshop)? And if features are missing (i.e. 'fallback functions' not supported by ink!), then show how the user could introduce that feature to ink! Core

Below is my understanding of the equivalent of Flipper in Solidity (using Truffle for tests)

// contracts/Flipper.sol

pragma solidity ^0.5.7;

contract Flipper {

    /// This simple dummy contract has a `bool` value that can
    /// alter between `true` and `false` using the `flip` message.
    /// Users can retrieve its current state using the `get` message.
    struct Flipper {
        /// The current state of our flag.
        bool value;
    }

    bool public value;

    event ShowFlipState (bool _value);

    /// Initializes our state to `false` upon deploying our smart contract.
    function Flipper() {
        value = false;
    }

    /// Flips the current state of our smart contract.
    function flip() {
        value = !value;
    }

    /// Returns the current state.
    function get() constant returns (bool) {
        ShowFlipState(value);
        return value;
    }
}

// test/TestFlipper.sol

pragma solidity ^0.5.7;

import "truffle/Assert.sol";
import "truffle/DeployedAddresses.sol";
import "../contracts/Flipper.sol";

contract TestFlipper {

    function it_works() {
        Flipper flipper = Flipper(DeployedAddresses.Flipper());
        Assert.equal(flipper.get(), false, "Initial flipped state should be false.");
        Assert.equal(flipper.flip(), true, "Flipping should toggle state.");
    }
}

[4meta5]

I'll open a similar issue in the Substrate V2.0 docs milestone, but I think a greater priority now is comparing runtime module development to smart contract development more broadly. This way, we are comparing ink and module development on Substrate.

[shawntabrizi]

Relevant StackOverflow Post:

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

[shawntabrizi]

Reopening this as something we should have available in our V2.0 documentation.

@riusricardo would look to you to make a draft here, use the content I have written and others have written in this issue, and talk with Robin, Sergei, Gav, etc to come to an agreement on what our recommendations here are.

Would be good to include a table or venn diagram of what kinds of things would work as a module, as a contract, or both.

[riusricardo]

I see the need to document it. I'll start a draft focused on ink! 2.0

[joepetrowski]

Closing this in favor of polkadot-developers/knowledgebase#37

Smart contracts in general needs an overhaul and reconsideration of the content.