10 Things You Should Consider When Building a Blockchain Solution
What is being decentralized?
When building a blockchain solution, the most important part is to figure out what is being decentralized and how it could impact the users. Are we decentralizing a decision making process (eg: DAOs), or payment processing (eg: Bitcoins), or services (eg: DeFi), or something else? Having clarity on this is extremely critical in building and communicating your blockchain solution. Investors love this clarity too.
On-chain and Off-chain data
Not all the data and logic belong on the chain. Blockchains are not built to store all the data. They are there to help reach an agreement on the state of data. We must make sure that only the data that is critical for consensus should be stored on chain.
Blockchains are NOT databases, they are consensus machines.
Should you build your own blockchain?
Depending on what you figure out in the above, you should consider whether you want to deploy smart contracts on an existing network, or you want to build your own chain. Generally, until you find out a product-market fit, or if you need use-case specific optimizations on the on-chain logic, the former is good to start with and gets you faster to market.
Governance
How does your blockchain logic evolve and who are the key stakeholders? How do you want to make sure that the voice of all participating parties is heard fairly? Who gets the right to vote, and how?
Integration with Off-chain Systems
How do you want to integrate your off-chain data and logic with your on-chain data and logic? Efficiently listening to and acting on blockchain events, batching transactions, callback transactions, etc. are all part of this.
Privacy
If you are using a permission-less network that does not inherently provide privacy features, and if your use-case requires data privacy, you should think even harder on the first two points in this post. In addition, think about how you want to protect the on-chain data and only showing it to the relevant parties. Encryption, ZKPs, trusted enclaves, etc. can be considered, depending on the use case.
User Identities and Interfaces
How would your users access the application or solution? Could they use their external identities with your solution? What kind of wallets and key management services you would need to integrate with your solution?
Gas and Transaction Fee
When using a permission-less network for your blockchain business logic, you need to consider how you should optimize and delegate the payment of transaction fees. Should the user pay for it directly or should the platform encapsulate the fees?
Development Practices
Once deployed, smart contracts cannot be changed or updated. You can deploy new ones, but that could require data migration. It is extremely critical that you plan your off-chain system’s development with your smart contracts’ development and iterations.
What if something goes wrong?
Sometimes, we have to roll things back when they don’t go as intended. In multi-user and multi-process workflows and on high load, this can happen unsurprisingly. Blockchains generally do not allow the deletion of data. So, how do you handle this? Think about compensation transactions in your on-chain logic. As far as all involved parties agree, you should be good.