Once you have finalized the use case, consensus algorithm platform and also design the architecture, the next step required is to finalize the design of blockchain instance. It's always prescribed that meticulous attention to details is necessary to develop a blockchain instance. As this design will be carried for the lifecycle of the blockchain. Every specific blockchain platform has blockchain parameters associated with it, which you can configure as per your requirement. Even if you're building a blockchain platform from scratch, you can include all the parameters mentioned here. Please pay careful notice to the parameters when you are building your blockchain instance.

The first parameter is permissions. We need to see whether we require permissions in our blockchain implementation or not. For example, if we are building a student credential storage for education industry over blockchain, then we might require permissions where we can provide the permissions to the students to only fetch or read the records. And on the other hand, we can provide the permissions to the universities to store as well as read the student credential records. It could also be a solution similar to Bitcoin, where we want to create a regulated cryptocurrency. For this kind of solution, we might want to keep all the permissions open.

The second parameter we need to look into is the asset issuance and reissuance. It could be a solution where we want to create assets as a digital representation of a physical thing present in the real world. For example, we can develop assets related to Cars, which can be listed for sale, we can call one car token as one car in the physical world. And when we are transferring one car token, that means we are selling one of our real car. For this example, we issued assets over the blockchain, which corresponds to cars. But now for the same scenario, we don't require reissuance of the assets.

Because once the car has been sold, we cannot resell the same car. On the other hand, if we are working on a solution for the agriculture industry, then we might issue assets against fruits. Let's suppose we issued assets for 10 oranges, and 20 apples, and within the same day, we sold all our fruits. Now in the next day, we might again require 10 more oranges and 20 more Apple assets or 50 new banana assets for such a solution, we require the capability of creations of assets, we need to carefully judge whether we require asset issuance or re issuance in our solution. The third parameter is the atomic exchange. We also need to figure out whether we require exchange of assets or cryptocurrencies in over system or not exchanges work on the principle of give and take, we are passing on one kind of asset or money and receiving some different kind of asset or currency.

For example, we could be providing bitcoins and acquiring ethers, or asset related to the physical world, like providing apples and receiving oranges in the same transaction. If we require atomic exchanges, we need to maintain them in the blockchain instance from the start. The next thing we require is a schema engagement. This is one of the most important aspects of our blockchain instance, we should manage over keys securely and efficiently. Most of the blockchain solutions are being hacked because of their key management mistakes. There was one example where one of the blockchain exchanges was storing the private keys of the users on a central server.

The hackers were able to gain access to that server, they were able to steal the user keys, which the exchange was holding, and they transferred all the bitcoins to their accounts. We need to manage the keys for our blockchain solution carefully. It could be a solution, where you don't hold the keys at your end, and provide the private keys to end users only. It could also be a solution that users store the keys inside a hardware wallet or it could be a solution. Where we have a central server for storage of the private keys, but always make sure that the user keys are protected as this is the primary entity authenticating users over the blockchain. After managing keys, we also need to look into multi signatures.

Multi signatures work similarly as the approval systems in any approval based hierarchy or system, different level of approvals are present and only if the approvals are done, then the process moves further and will be successful. If the approvals have not been met, then the process becomes a failure. For example, when an employee is posting the reimbursement of spendings to his company, then he has to have his managers approval. And in some cases, the approval of group directors is required as well. Only when the employee gets the approval. Over his request, then his reimbursement will be processed.

Multi signatures work on the same principle. For example, we could distribute five different private keys related to one account over the blockchain and have a policy which dictates that only if two of the private keys out of the five sign the transaction, then only it can be broadcasted over the blockchain. The next important thing to finalize upon are the block parameters. Block parameters are essential for the blockchain as they define the capabilities of the blockchain. Block parameters include the block time, block size, transaction size, minimum transaction value, maximum transaction value fees, and many more parameters. All these parameters will define how a transaction block and data will look like in the blockchain.

Blockchain will follow these parameters for each new block produced. So, we require to put in the careful thought in designing block parameters. After designing capabilities with the block parameters, we also need to see the limitations of the blockchain limitations are also necessary for the security and scalability for the blockchain. Some limits could be related to transaction metadata, where a transaction must have a specific data included. It could also be related to the block size, which can be uploaded over the blockchain. For example, Bitcoin has the limitation of one MB for the block size.

Depending on the use case, we need to define limitations for the blockchain instance. After limitations, we need to establish the network protocols and handshaking process For the nodes, or computers, this is one of the significant parts of the blockchain projects and used to create peer to peer network where computer communicates and synchronizes the data. We need to develop a strategy related to how network protocols are going to work. Whether the network includes verification and validation of nodes, whether we are going to run gossip protocols to distribute the data between different nodes, or are we going to implement our services like TLS, or HTTPS. These will help us to distribute the data with the nodes. We also need to define the handshake agreements and synchronization processes between different nodes which are going to connect to the blockchain.

After designing all of the above, we will also need to set up over key and address formats which we are going to use Different blockchains have different formats. These formats are created for implementing various encoding and transformations required for the private keys and addresses over the blockchain. We need to define how the keys and addresses are going to be represented. We can take up the format's already defined in the public blockchain. Or if required, we can create our definition of formats. Proper key and address formats unnecessary to safeguard the blockchain securely.

Finally, you also need to see the requirement for the native currencies or assets. Native assets are different from the assets which we talked about earlier. Native assets here are like ether, which is a cryptocurrency present over the Ethereum blockchain. And assets are like the tokens in the Ico which we deploy over the blockchain. For a specific function, and between the agreed upon parties, as per our use case, we need to see the requirement of the cryptocurrencies with our project. If we are going to keep some fees over the transactions or pay the participants for doing any work on the blockchain, then we might require to keep the native assets.

This was just a brief about designing the blockchain instance, after designing the blockchain instance, you need to see the API's which will be enabled for your blockchain. Now, let's go and see about the blockchain API's.