We have discussed the design and development of a smart contract throughout the course thus far. This module will focus on the best practices. We'll begin with the cautionary note about evaluating whether a blockchain-based solution is suitable for your problem. We'll then discuss some of the best practices when designing Solidity smart contract focusing on data functions and their visibility modifiers and access modifiers. We will follow it up with best practices as it relates to Remix IDE. Upon completion of this module, you will be able to list the best practices when designing blockchain-based application. Illustrate the best practices for designing solutions with smart contract using Solidity and Remix IDE. 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.