The purpose of building this blog is to write down the detailed operation history and my memo for learning the dApps and Web3 programming.
The figure below illustrates the architecture of the Hyperledger Fabric blockchain. The application interface is the front end which will interact with the Hyperledger Fabric blockchain. This application is running on SDK which is a software development kit provided by the Hyperledger team. Currently, the most mature SDK are Node JS and Go SDK. These two are equipped with the Hyperledger Fabric system itself.
Every time a user uploads any document through this application interface, the application does not go to this blockchain directly. Instead, the application creates a future update proposal and submits a request for confirmation over the blockchain. With this request, users seek to modify the data stored in the blockchain or the current state of the blockchain. At present, the blockchain is at a stage where all the data has been sent and the users want to add one more transaction on top of that.
The proposal is sent to an endorsing peer. Endorsing peers is to verify and validate the transaction which is coming in. They execute the transaction by simulating it over the copy of the ledger. Simulating means they do not directly change the state of the blockchain but hold a copy of the state and implement the transaction proposal on that copy of the blockchain without updating it.
In Hyperledger blockchain data storage happens in a way that every transaction that is coming in or every block that is coming in are in key-value pairs, and the Hyperledger Fabric database is a key-value pair database. Endorsing peers execute the transaction on top of the copy and once the transactions are implemented, the read set and write set of the keys are changed automatically. Once the endorsing peers check that the transactions are in the correct order then they validate the transaction after verifying it. The endorsing peers sign the proposal with their certificate issued by a membership service provider MSP. After that, they send it back to the application.
Once the application receives this transaction, it checks for the satisfaction of the endorsement policies and if the endorsement policies are met, then it sends the transaction further to the ordering service. The ordering service is the central entity which updates the state of the blockchain. The ordering service receives this transaction and orders them into a block. It checks what kind of reads and writes are going to be updated within the transaction and checks whether are a part of the block or not. Once everything is examined, the ordering service puts this completed transaction change as a new block over the blockchain. It means that once the blockchain state is renewed, the transaction block is refreshed.
After that, the committing peers validate the endorsement policy and commit the new block to the chain and valid transactions to the database. Finally, all the peers who are connected to the blockchain will update their state and get the new read set and write set for the blockchain state through gossip protocol working behind the scenes.
Top comments (0)