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 life cycle of the blockchain.
Every specific blockchain platform has blockchain parameters associated with it, which you can configure
as per your requirement.
Even if you are 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 asset issuance and reissuance.
It could be a solution where we want to create assets as digital representation of a physical thing
present in the real world.
For example, we can develop assets related to cars, which we 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 ten oranges and 20 apples and within the same day we sold all our
fruits.
Now on the next day we might again require ten more orange assets and 20 more Apple assets or 50 new
banana assets.
For such a solution, we require the capability of creation 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 currencies in our 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 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 key management.
This is one of the most important aspects of our blockchain instance.
We should manage our 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 the 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 own 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 the
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 and reimbursement of spendings to his company, then he has
to have his manager's approval and in some cases the approval of group directors is required as well.
Only when the employee gets the approval over his her request, then his her 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 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 parameter includes 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 careful
thought process 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 the 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 a 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 the 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 also need to set up our 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 formats already defined in public blockchain or if required, we can create our own
definition of formats.
Proper key and address formats are necessary to safeguard the blockchain securely.
Finally, you also need to see the requirement for the native assets or currencies.
Native assets are different from the assets which we have 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
being 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.
After finalizing the blockchain instance, we also need to define and work with the APIs, which will
be used by the developers to make applications interact with the blockchain.
Now let's go and see how we are going to define our APIs and use them to interact with the blockchain.