This blog is the part 1 of my block chain journey. The blogs will come in sequence to make you fully aware of concepts and development (using AWS Cloud9 and Truffle)
What all to think about while designing a block chain?
For any Block Chain, the factors that you would need to understand are part of a Typical Block Chain Stack illustrated in the image below. Scroll down for each
layer definition in easy manner.
Following definitions will try to ease your
understanding associated with the image above.
The stack decisions will finally help you
decide what kind of architecture and components you need.
1.
Applications : Who
all will use it?
a.
E.g. Public users?
Enterprise Organizations? IoT Devices?
Based on who will use it, the lower layers architecture will be decided (
you will understand by the end of this blog)
2.
APIs : APIs to
access the various methods for the applications to do some transactions. API
security and access has to be thought about.
3.
Membership
a.
How will the applications
register their identity to the chain? What info would be the part of block for
member ship?
e.g. if users are public users, you might need different info than in
case of enterprises or IoT devices.
4.
Cryptographic
a.
What all methods will you
use for the hashing and to generate the encrypted link between blocks.
5.
Events
a.
What all events can take
place between the blocks e.g. transfer, update, view etc.
6.
Transactions
a.
What will be the
transactions based on the events and how they will be stored, you can offload
some data from chain to simple storage like s3 etc. So you need to think of all
scenarios. E.g. if you are dealing with changing of content, the actual content
you would not like to keep on the chain, rather on some storage like AWS S3
etc.
7.
Consensus
a.
Based on the applications,
you can choose any Consensus mechanism e.g. if the architecture is between
trusted nodes only i.e. let us say your company with some known other parties,
you can use PoA ( proof of authority ), this makes the block chain faster and
also more secure. Choose the consensus mechanism per your needs. If you need
for a public user ( then you might use PoW or PoS, but they need more resources
and power).
b.
So all the layers above
will help to decide on Consensus ( I will also write a blog to understand
different consensus mechanisms)
8.
Smart Contracts
a.
What will be the part of
contract? What templates do you want to use e.g. you want to use ETH with
Solidity? Or some other templates?
9.
Distributed Ledger
a.
How will your ledger look
like? What will be the part of it? How to offload the info from Ledger to make
the chain or consensus mechanism faster? What service would you use for it e.g.
AWS block chain service? Or your own ledger on Hadoop? Or some ledger over
IPFS?
That’s it for the stack. We will go to each level and lead
you to development for real use cases.
** Disclaimer - Material for this blog is also taken from AWS Re-invent
sessions. But the explanation is made in a simple understandable manner.
Comments
Post a Comment