Some of the key concepts in Hyperledger fabric are:
- Member
- Membership Services
- Multi-Channel
- Private Channels
- Peer
- Ledger
- Block
- Chaincode
- Consensus
- Transaction
- Policy
Member & Membership Services
An organization is a
managed group of members. This can be something as big as a multinational
corporation or a small as a flower shop.
Hyperledger,
1.
Is a permissioned network. No anonymous access
(anonymous access allowed in bitcoin).
2.
All identities are known.
Member: Member
represent an independent entity. They are legally separate and independent like
shown below.
Member identities
in hyperledger are managed by certificates (x509).
When a participant identity is created certificate issued to the participant.
When a transaction initiated by the participant, the private key is used for signing the transaction.
Any component in the network can validate authenticity of the transaction by using participants public key.
Every component in hyperleger got an identity. For example it can be infrastructure component like server in hyperledger network.
Even a member has a certificate.
Certificates: certificates issued and revoked by certification authority (CA).
Member can manage identity within their organization.
Membership Service Provider: this service inside the member ORG, create/revoke certificates. It can create certificate for participants, certificate for infrastructure components.
When a participant identity is created certificate issued to the participant.
When a transaction initiated by the participant, the private key is used for signing the transaction.
Any component in the network can validate authenticity of the transaction by using participants public key.
Every component in hyperleger got an identity. For example it can be infrastructure component like server in hyperledger network.
Even a member has a certificate.
Certificates: certificates issued and revoked by certification authority (CA).
Member can manage identity within their organization.
Membership Service Provider: this service inside the member ORG, create/revoke certificates. It can create certificate for participants, certificate for infrastructure components.
MSP’s are part of a member. That means each member will have
its own MSP.
MSP provide two services,
1.
Authentication: is user certificate value?
2.
Authorization: Is user allowed to take this
action?
As shown above Certificate Authority (CA), issue, validate
or revoke the certificate.
Fabric CA is implemented in two parts,
Server: Manages certificates inside a database. By default Sqlite, can be configured to MySql, PostgresSql, LDAP etc..
Client: The person who manage certificate use client to access server.
Ledger
Ledger provides a verifiable history of,Successful state changes (valid transactions).Ledger is kept at all peers, and referred as PeerLedger.
Unsuccessful attempts to change state (invalid transactions).
A ledger contains the current state of a business as a journal of transactions.
A blockchain ledger consists of two distinct, though related, parts – a world state and a blockchain.
Firstly, there’s a world state – a database that holds the current values of a set of ledger states.
The world state makes it easy for a program to get the current value of these states, rather than having to calculate them by traversing the entire transaction log.
Ledger states are, by default, expressed as key-value pairs.
The world state can change frequently, as states can be created, updated and deleted.
Secondly, there’s a blockchain – a transaction log that records all the changes that determine the world state.
Transactions are collected inside blocks that are appended to the blockchain – enabling you to understand the history of changes that have resulted in the current world state.
The blockchain data structure is very different to the world state because once written, it cannot be modified.
It is an immutable sequence of blocks, each of which contains a set of ordered transactions.
Example Sequence,
Sequence 1: Person A sells a CAR to person B.
Transaction Log: Car sold, Person A to Person B.
State: Car {Vin:xxx; Owner: Person B}
Sequence 2: Person B sells CAR to Person C.
Transaction Log: Car sold, Person A to Person B.
Car sold, Person B to Person C.
State: Car {Vin:xxx; Owner: Person C}
Points to Note:
Transaction log is immutable.
If we take, CRUD operations those in GREEN are possible. RED is not possible.
In a transaction log, Create, Read, Update, Delete
In a state data: Create, Read, Update, Delete
Sequence 1: Person A sells a CAR to person B.
Transaction Log: Car sold, Person A to Person B.
State: Car {Vin:xxx; Owner: Person B}
Sequence 2: Person B sells CAR to Person C.
Transaction Log: Car sold, Person A to Person B.
Car sold, Person B to Person C.
State: Car {Vin:xxx; Owner: Person C}
Points to Note:
Transaction log is immutable.
If we take, CRUD operations those in GREEN are possible. RED is not possible.
In a transaction log, Create, Read, Update, Delete
In a state data: Create, Read, Update, Delete
World State
By default, level DB. But can be pluggable with other Database.
It is key-value store.
When state data is updated. The existing data is not overwritten. But retained in the form of version.
The visual representation of versioning. Take the example of car. The ownership of the car is changed. So as the version representing the CAR. The VIN number remains same. So the VIN version remains at 1.
Nodes and Channels
Nodes
Nodes connect to other nodes to form the Blockchain network.
Nodes connect to other nodes to form the Blockchain network.
Unlike bitcoin, in hyperledger, not all nodes are equal.
Each entity in the above diagram can be considered as a node.
Each node will have a certificate.
A participant can connect to a node using his own certificate.
Participant signs the transaction, but the network use certificate of a node to check validity of the transaction.
Each node will have a certificate.
A participant can connect to a node using his own certificate.
Participant signs the transaction, but the network use certificate of a node to check validity of the transaction.
Different type of nodes,
Client Nodes: applications use to Initiates a transaction.
Peer Nodes: keep the ledger sync across the network.
Orderers: Transaction distribution.
Peers
Peers are fundamental element of the network. They host
ledgers and smart contracts.
Peers expose a set of APIs that enable administartors and applications to interact with the services that they provide.
Chaincode: simply a piece of code that accesses the ledger. Fabric implements smart contracts with chaincode.
A peer host instances of ledgers and instances of chaincodes. There can be many ledgers and chaincodes hosted on an individual peer.
Two type of peers,
- Anchor peers
- Endorsing peers
Peers in the organization receive transaction request from the client.Orderer creates blocks based on the transaction and send to peer.
The Peer who receive the block is called Anchor peer.Anchor peer validate the block and update other peers.
Anchor peer is created as part of channel configuration.
Anchor peer receives updates and broadcasts the updates to the other peers in the organization.
Anchor peers are discoverable.
So any peer marked as Anchor peer can be discovered by the Orderer peer or any other peer.
Client send invocation request to endorser peer.
Endorser validate the transaction.
After validation successfully finish endorser simulate chaincode.
After it execute the chaincode it will not save the state to the blockchain. It just simulate the chaincode.
Endorser will either reject transaction or accept the transaction.
Only the endorser execute the chaincode.
Life cycle of a transaction.
Execute: Transactions are executed (using chaincode) in any order.
Order: When enough peers agree on the results of a transaction, it’s added to the ledger and disseminated to all peers. This step is where the transactions are first given an ordering — until transactions are added to the ledger, there’s no concept of one transaction happening before or after another.
Validate: Each peer validates and applies the ledger’s transactions in sequence. Now that the transactions have an ordering, the peers can check whether a later transaction was invalidated by an earlier transaction. For example, this prevents one item from being sold two times (called double-spending).
All peers need to update the ledger, so all peers do the Validate step. But not every peer needs to Execute the smart contract. Hyperledger Fabric uses endorsement policies to define which peers need to execute which transactions. This means that a given chaincode (smart contract) can be kept private from peers that aren’t part of the endorsement policy.
Transactions can be executed before they are put in order. This allows peers to execute transactions in parallel, which can improve throughput.
In Fabric’s three-step execute-order-validate model, the results of executing chaincode for a transaction are explicitly agreed upon (according to the endorsement policy) before the transaction is added to the ledger.
Endorsement Policy
Hyperledger Fabric allows users to define policies around the execution of chaincode. These endorsement policies define which peers need to agree on the results of a transaction before it can be added to the ledger. Fabric includes a small domain-specific language for specifying endorsement policies. Example endorsement policies might be:Peers A, B, C, and F must all endorse transactions of type T
A majority of peers in the channel must endorse transactions of type U
At least 3 peers of A, B, C, D, E, F, G must endorse transactions of type V
In the order-execute model, the concepts of executing chaincode and updating the ledger are combined into one idea — transaction.
Fabric starts with a transaction proposal. It’s a bundle of information used to trigger a specific chaincode. The transaction proposal is sent to endorser peer. The endorser executes the chaincode, which (if it succeeds) yields an actual transaction for the ledger. The endorsing peer then signs the transaction and returns it to the proposer.
Channels, a mechanism by which a set of components withing blockchain network can communicate and trasact privately. These components are typically peer nodes, orderer nodes and applications, by joining a channel they agree to collaborate to collectively share and manage identical copies of the ledger associated with that channel.
Fabric starts with a transaction proposal. It’s a bundle of information used to trigger a specific chaincode. The transaction proposal is sent to endorser peer. The endorser executes the chaincode, which (if it succeeds) yields an actual transaction for the ledger. The endorsing peer then signs the transaction and returns it to the proposer.
Channels, a mechanism by which a set of components withing blockchain network can communicate and trasact privately. These components are typically peer nodes, orderer nodes and applications, by joining a channel they agree to collaborate to collectively share and manage identical copies of the ledger associated with that channel.
Things may get little complicated.
Multi-Channel
The fabric will allow for multiple channels with a
designated ledger per channel (data segregation). This capability allows for
multilateral contracts where only the restricted participants on the channel
will submit, endorse, order, or commit transactions on that channel. As such, a single peer can maintain multiple
ledgers without compromising privacy and confidentiality.
Private Channel
Private channels are the generic term used to describe a method of communicating using a blockchain ledger with a subset of network participants.
Private channels are the generic term used to describe a method of communicating using a blockchain ledger with a subset of network participants.
Orderer
Ordering-service-node or orderer: a node running the
communication service that implements a delivery guarantee, such as atomic or
total order broadcast.
Orderers (can be
multiple instances) who are responsible for making sure that all the peers in
the network have committed a transaction. When a transaction is proposed and
committed by a peer, the orderer is informed about the new transaction and it
forwards and commits this block to all adjacent peers.
Orderers are not dependent on one organization. However, it is suggested to have multiple orderers to reduce failure rates.
Orderers are responsible for creating consistent ledger state across the network.
Consensus, build in fabric using orderer.
They are responsible to maintaining order of the transaction.
Blocks are created by orderer. Once created the blocks are delivered to each peer in the network. Order guarantee atomic delivery of each block.
Implemented using, messaging system, SOLO (for Dev use). Prod use Kafka.
Provides a communication layer within the network.
Administrator Roles
Two administrator roles,1. Peer Administrator
2. Network Administrator
Peer administrator, created on the node level, to excute action on node level.
Network admin, created for application level administration activities. They are created by peer admin.
Business Network Cards.
A Business Network Card provides all of the information needed to connect to a blockchain business network. It is only possible to access a blockchain Business Network through a valid Business Network Card. A Business Network Card contains and Identity for a single Participant within a deployed business network.
Composer tool needs the Business Network Card to conduct the CRUD (Create, Retrieve, Update and Delete) operations. Business Network Cards encapsulates details about the credentials, keys and certificates and the connection profile.
The following script can create a new card.
| 'use strict'; | |
| const idCardClass = require('composer-common').IdCard; | |
| let metadata = {version: 1, userName: 'abcbuddy', enrollmentSecret: "abcbuddy", businessNetwork: "tutorial-network"}; | |
| let connectionprofile = { name: 'hlfv1', | |
| type: 'hlfv1', | |
| orderers: [ { url: 'grpc://localhost:7050' } ], | |
| ca: { url: 'http://localhost:7054', name: 'ca.org1.example.com' }, | |
| peers: | |
| [ { requestURL: 'grpc://localhost:7051', | |
| eventURL: 'grpc://localhost:7053' } ], | |
| channel: 'composerchannel', | |
| mspID: 'Org1MSP', | |
| timeout: 300 }; | |
| const newIdCard =new idCardClass(metadata,connectionprofile); | |
| newIdCard.toDirectory('/home/abcbuddy/.composer/cards/abcbuddy@tutorial-network').then(function(){ | |
| console.log('new card created'); | |
| }); |
As show above the card should have credentials, keys and certificates, and connection profile.
Cards are stored on file system Linux check /home/user/.composer directory (~/.composer).
It's interesting that many of the bloggers to helped clarify a few things for me as well as giving.Most of ideas can be nice content.The people to give them a good shake to get your point and across the command.
ReplyDeleteBlockchain Technology