Blockchain is not a solution for all applications.
Make sure your application requirements need blockchain features.
In other words, blockchain-based solutions and
smart contracts are not a panacea for all problems you have.
Then, what is it good for?
Recall that we learned in course one that blockchain solution is most suitable for
applications with these characteristics: Decentralized problems,
meaning participant hold the assets and are not co-located.
In more, peer-to-peer transaction without intermediaries.
Operate beyond the boundaries of trust among unknown peers.
Require validation, verification, and
recording on a universally timestamped, immutable ledger.
Autonomous operations guided by rules and policies.
Make sure you need a smart contract on blockchain for your application.
Understand that smart contracts will be visible to
all participants on the chain and will be executed on all the full nodes.
You need a smart contract when you need
a collective agreement based on rules, regulation,
policies, or governance enforced,
and the decision and the provenance for it must be recorded.
Smart contract is not for single node computation.
It does not replace your client server or inherently stateless distributed solutions.
Keep the smart contract code simple, coherent, and auditable.
Let it solve a single problem well to avoid design and coding errors.
In other words, let the state variables and the functions
specified in a smart contract be addressing a single problem.
Do not include redundant data or unrelated functions.
Make the smart contract functions auditable by using custom function modifiers
instead of inline if-else code for
checking pre and post conditions for a function execution.
Smart contracts are usually part of a large distributed application;
the part that requires the services provided by the blockchain.
Blockchain is not a data repository.
Keep only the necessary data in the smart contract.
Of course, it is an immutable distributed ledger of transactions.
Recall that the blockchain also manages
the state transitions and maintains the state hash,
transaction hash, and receipt hash in the header of each block.
These are indeed application dependent overheads.
Given these characteristics, it's a good practice to analyze
the application data and separate them into on-chain an off-chain data.
Design the state variables for the smart contract to
be efficient storage for the on-chain data.
Leave the off-chain data to be managed by higher level applications.
As an example, instead of keeping and enter
a 500 pages of a public legal document on the chain,
keep only the metadata about the document,
including a secure hash to protect the integrity of the document.