making HyperLedger Blockchain …simple & my learning : June 2020

22 min readJun 15, 2020

I am new to Hyperledger … I have written some Golden terms & statements which will teach HLD to all … Thanks ..keep learning ..its tough for newbies !!

Multiple Peer Nodes use a Single Channel (Private Ledger & SC’s)
Single Peer Node can use Multiple Channels
Consortium
Organization
Network
Ledger holds [List of Blocks]
World State
World state is queried & updated using Key-based lookups, range queries
Block holds [List of Transactions] Rows
Transaction Row of a Block holds [Tx ID, Date, Chaincode Name (Input params/Output results & R/W Data from World state, Initiator Name, Endorser Name, Tx Status]
Transactions consist of versions of key/value that are read & written by Chaincodes (from World State)
Peers validate Transactions against endorsement policies and enforce rules
Type of Transactions: some can do query or update or delete
Only Chaincode can update the Ledger and world state
Chaincode/Smart contracts: run business logic
Chaincode are functions, which accept Transaction as Parameter
Chaincode: Read from & Write into World state
Chaincode: installed on Peers & instantiated on Channels
Chaincode attributes: ID, Version, Path, Names of Peer Nodes (on which CC is installed, Names of Channels(on which CC is instantiated)
Chaincode runs on Secured & Isolated Containers (runtimes)
Chaincodes are available specific to a (Scope) Channel
Genesis Block
Transactions
Channel manages/runs Ledger(Blocks) & World State
A separate Ledger is maintained by a Channel
A Ledger exists in the Scope of a Channel
A Ledger in a Channel A cannot be accessed by Channel B or others
Channel’s Ledger contains a Configuration Block — defining Policies, ACL
Participants can connect to one or more Channels in a Network
Data can be encrypted before putting in a Channel
Each Peer keeps Copy of Ledger for their Channel of which they are a member
Channel has attributes [Ledger, Smart contracts, Peer Nodes]
MSP creates Digital identities for Peers and Users of the Org
Data access controls is governed on Whole Network and Channels, using Crypto Certs — PKI
Fabric CA is an implementation of the MSP
Fabric CA (MSP) registers & issues Digital Certs (X.509)
Fabric CA runs in a Docker container
Fabric CA stores Identity data & X.509 Certs in SQL Database
Commit Peer Nodes
Endorser Peer Nodes
Orderer Node
CA Node
Signature with Private Key
Verify Signature
Consensus Algorithms
Transaction & Endorsement flow
Gossip Protocol
Endorsement Policies
A peer in Network can hold more than one Ledgers, which can be governed by one or more Chaincodes
In Peer Node, we can have Ledger L2 can be accessed only by Chaincode C1 & C5
Private key is used to generate Signature for each Transaction sent
Public keys can be distributed to all (256 bits long)
Private Key encrypts & Public key decrypts
A Crypto Address is a representation of Public key
One way Hash function are used to derive Address from Public Key
Cryptocurrency Address = Hash(Public Key)
1st install Chaincode on a Peer node of a HyperLedger Network
Chaincode has to be 1st instantiated on a Channel & then run on Channel
“Instantiate Chaincode” means Activating a CC on a Channel (init() func)
“Instantiate CC” action is written in a new Block as a Transaction on CH
During “Instantiate CC” select “Endorsement policy” for CC
“Endorsement policy” : num of Members (Org) required to endorse Tran
CC attributes (ID, Version,CH Name, Peer URL, CodeType, init() func)
Wallet: used to interact with Blockchain
Using Wallet, Users can generate Private Key & Public address
Digital Signatures : identity proof for people transacting with Blockchain
Digital Signatures prove that somebody is “who they say they are”
Sender uses Private Key to Sign messages Digitally
Recipient of Message, will use Public Key of Sender to Verify the Signature
Every Trans executed on Blockchain is signed by Sender (private key)
Peer Node Type: Endorser (Clients talk to Endorser Nodes only)
Peer Node Type: Committer(updates the Ledger and World State)
Orderer: manages Consensus & creates the Block -> sends to Committers
MSP: validates the Identities of Nodes, Users of the Network
Client sends the Transaction proposal to Set of Endorser Nodes
Endorsers will Verify & Sign the Client Transaction, later send the [Approval, Signature & Read/Write Set of Records for that Transaction] to the Client
If Client gets the required Endorsements for their Transaction, the Client will send Transaction Approval data to the Orderer
Orderer will verify Transaction details, create a new Block for those approved Transaction Group and send Block to all Peers (Endorsers & Committers)
Once all Peers validate all Block Transactions, they will commit the Ledger
After Commit process, the Peer nodes will inform Client that their Transaction is committed or not committed to Ledger
Transaction is a request to the Blockchain to execute a Function on Ledger
All Transactions rejected by Endorsers, will also be committed to Ledger
Whenever a write Transaction is performed, it modifies the world State & record of the Transaction is made in the log of the Ledger.
Organizations form a “Consortium”
Orgs which are part of a Network are called “Members”
Each Member Org in the Network is responsible to set up their own Peers
All Peer nodes need to be configured with Crypto: CA & others
CA : [Root Certs, Intermediate Certs, Client Certs]
When interacting with Network, the Actor presents Digital Cert. The Network accepts or denies the Request & Cert based on the Policy
In Bitcoin: A Proposer is any random Node, which is selected randomly by the Network. The Proposer will prepare the Block with Trans and propagate to the Committee for Verification of the new Block.
In Bitcoin, after Verification, the Block is committed to Ledger by all Nodes
In Bitcoin, the Proposer & Committee group are selected using a Algorithm
PBFT Protocol : “Tendermint”
Assets & Participants are stored under Registries (World State storage)
Assets can be created by Chaincode & also by Composer API
Participants are members of a Blockchain Network
Participants can create or update Assets by submitting Transactions
An Identity is a Digital Cert & Private Key
Identity Registry stores : (Participant ID <-> Cert and Private Key)
A Business Network card provides all the Information needed to connect to a Hyperledger Network
A Participant can only access a Network using a Card
Cards contains : Identity, Connection Profile, Cert, Metadata
Card can be shared with other Participants
Events are defined under Model file (.cto)
Events are emitted under Tran Processor file
Apps can subscribe for Event types
Root Cert (ROOTCERT) for each Org of the Network
Enrollment (ECERT) for each Member and User
Transaction Cert (TCERT) for each enrolled User
TCERT is mandatory to send Transactions
Each TCERT authorizes only one Transaction on the Network
If a Member has a valid ECERT but does not have a TCERT, then member cannot send a Tran to the Network
NEAR protocol : each Account can hold (Zero or One Contract)
NEAR protocol : One Contract can be part of multiple Accounts
NEAR protocol : Contract = Account + State of that Account
NEAR protocol : Each Account = Metadata + Data values (K:V pairs)
MSP will validate Identity(Certs) & Signature verification
HyperLedger 2.0 - majority of Participants have to agree(Vote) to terms of a Chaincode, before CC can be activated on a Channel
HLD : using email, we can invite other Orgs to join our Consortium
HLD: few Admin tasks [Setting policy configs across Network, Certificate generation, Resource allocation for Nodes & Automated updates to Channel config for every new Org & Peer that joins]
HLD: Install & upgrading of Chaincodes requires approval from multiple Orgs before CC is executed
HLD 2.0: new decentralized governance for Smart contracts means that a Network can be configured to require, that every Org must agree to Parameters of the CC before it can become active
Bitcoin & Ethereum : Data is not encrypted by default on blockchain. This means that anyone can read the data freely.
Quorum (forked from Ethereum): No Miners, All Trans Free & Private
Node synchronization: the New Node needs to download [existing Blocks, account balances, smart contract code & data
Speed up Syncing process for New Node joining Network-> When a Node creation request is initiated, restore Ledger for New Node from latest snapshot of Main Ledger. Instead, only the data added since the latest Ledger snapshot needs to be downloaded.
DApps can run -> when certain Conditions are met
In Proof of Work (POW): one of the Miner who cracks “Nonce”, will validate Block & decide and send next Block (which Trans will be added)
In Proof of Stake(POS): Validator who has highest Stake of ETH, will (have higher voting power & validate Block) & (also decide the next Block)
In POW & POS, Miners & Validators receive Tokens for work done
Mine Blocks == Validate Trans
In Ethereum, to become a Validator you need to deposit (32 Ether)
Chaincode runs inside a secured Docker container
Ledger State created by a Chaincode is scoped exclusively to that CC & cannot be accessed by another CC
One CC can invoke another CC to fetch others State (same Network)
if Ledger : A is inside the Channel : B, if CC: Z wants to use this Ledger A then CC : Z should be inside the Channel : B
When User sends a Transaction -> HLD invokes a CC of a Channel, passing Transaction as a Parameter
Invoke the Channel.Chaincode.function(transactions)
Install CC in only those Peers, which are part of CC’s Channel
Peer Nodes[L, M, N, O], if Peers M & O are part of Channel : B, then install CC :Z of Channel : B on Peers M & O only
When we Install CC, nothing happens, only download Code in Peer Node
When we instantiate CC -> start the CC Container, make connections, Scanning code, etc (ready to use CC)
When we instantiate CC, we have to Provide the Policy for CC
Endorsement Policy for CC, The Peer checks VSCC (Validation System Chaincode) for the Transaction’s Chaincode to determine validity of Trans
Before commit Trans to Ledger, every Peer for this CC, should verify Endorsement Policy for that CC
A CC deployer will specify Endorsement Policy for their CC. This Policy has to be verified by specific Peer nodes.
MSP: A Principal in terms of the MSP, will Validate the Identity of Signer & Role of the Signer within that MSP
If we have a Channel : B, which has 3 Chaincode [P, Q, R], then each CC : P, Q n R will have their own Policy attached
MSP: Principal is (MSP_ID.Role_Name) example: ‘Org0.admin’
A Peer may be part of One or Many Channels
Every single Channel has a Separate Ledger
Every single Channel may have One or Many Chaincodes
Every Chaincode has its own Policy
An invoke Transaction refers to one of Chaincode’s function being invoked
We have many special Chaincodes for management functions & parameters, collectively called system chaincodes
Deploy transaction means, which will create a new Chaincode, and also invoke a Transaction on a system Chaincode
A Transaction either creates new Chaincode or invokes already deployed Chaincode function.
In Chainstack Infra, when create a new Network, by default [Single Raft Orderer Node, initial Channel, One Anchor Peer Node] created
Peer Attributes: [Peer Name, Peer URL, Type, MSP ID]
Blockchain App using 3 Nodes & a consensus order Node, need 4 VMs, about 120,000 yuan (US$17,000) on Alibaba, adding minimum cost for a DLT app in China ranges from $28,000 to $43,000
A Bitcoin Node typically makes 8 outbound connections, it will broadcast a Transaction to 8 other Bitcoin Nodes.
Slowly, every Node in Bitcoin Network confirms & writes down a Transaction made by another node, if valid.
Channel is an isolated HLD instance within a Single Network
Channels: defined by Members(Orgs), Anchor Peers, Shared Ledger, Chaincodes and Ordering Service nodes
The election of a leading peer for each member(Org) on a Channel determines which Peer of the Org communicates with the Ordering service on behalf of the member(Org) for this Channel
Ordering service orders Trans & delivers them in a block, to each Leading peer of each member(Org). The leading Peer then distributes this block to its member Peers, using the gossip protocol
Each Peer that joins a Channel, the Peer has its own identity given by a MSP, which authenticates each Peer to its Channel Peer & Services
Each Transaction on the Network, will execute on a Channel.
Each Party must be authenticated & authorized to transact on that Channel
When a new Channel is created, a new “Genesis Block” for Channel Ledger is created, which stores Config info about Channel policies, Orgs(members) & Anchor Peers.
When a new Member is added to a existing Channel, the Latest Genesis config Block, is shared with new Member
Every Org(Member) will have a Leading Peer for a specific Channel, who will communicate with Ordering Service on behalf of the Org
Ordering service will order the Trans and delivers the new Block to all Leading Peer (of each Org), then each Leading Peer distributes the new Block to its Org’s Peers for that Channel only (using Gossip protocol)
Each Peer can belong to multiple Channels and will maintain multiple Channels/Ledgers. But no ledger data can pass from One Channel to another Channel
Although any one Anchor Peer can belong to multiple Channels, & therefore maintain multiple Ledgers, but no ledger data can pass from one Channel to another Channel.
The dissemination of Transaction data, which includes info on transactions, ledger state and channel membership, is restricted to peers with verifiable membership on the channel.
This isolation of Members & Ledger data, by channel level, allows Members(Orgs) that require private Trans to coexist with competitors & other restricted members(Orgs), on same Network.
Separation of a Channel(Isolation), implemented by Config Chaincode, Identity MSP & Gossip data dissemination protocol
Info on Channel ledger state, transactions info, channel membership is restricted to only Peers with verifiable membership on that Channel
in Hyperledger 2.0, we can Commit the CC definition to a Channel, only when All Orgs of your Network approve that CC definition
HLD 2, committing a Channel definition requires Endorsement from Orgs
CC definition includes: Endorsement policy, Private data collection config, etc
CC definition attributes: [Name:PAY, Version:1.0, End policy:(2 of 2), Seq:1, Package_ID:PAY_1.0:hash]
(a) Each Org has to install new CC package on all Peer nodes
(b) Each Org has to approve new CC definition
New CC lifecycle flow for upgrades, -> Repackage CC ->install CC on all Peers -> Orgs will Approve the CC Definition -> Commit CC Definition to a Channel ->Upgrade CC Container on all Peers
After CC is committed to a Channel, when a New Org joins this Channel, the new Org can automatically start using this Chaincode(CC)
When updating the CC Endo policy, no need to install CC or restart the Container, only new CC definition is committed
Orgs can approve CC definition without installing CC package
CC logic on Peer & CC definition on Channel are decoupled
You can install Single CC package, but deploy CC multiple times with Different names on the Same Channel
You can install Single CC package, but deploy CC multiple times with Different names on Different Channels
Single CC package, can have multiple Definitions on the Channel
RW sets are the output of a CC function
Every Org can have CC in different languages, but CC ->execution results -> RW sets should be same
Chaincode can run in a Docker container or Kubernetes POD
When we use CouchDB as External State database, read delays during Endorsement & Validation phases are a bottleneck
Now Reads are faster, by using New Peer cache.
Ordering Node, decides which Channels it will Serve
Peer Nodes: Transaction validation is parallelized in Commit phase (faster)
Solo and Kafka consensus types are deprecated (2020)
Hyperledger Fabric Docker images will use Alpine Linux, Base OS
Chaincode does not have direct access to Ledger state
For a single Channel, have minimum 1 or >1 Anchor Peers
Org: “orgA” and Peer name: “Processor.orgA”
ACL is part of Channel configuration
ACL(Policy) is persisted in Channel’s Configuration Block
ACL (access to Resources):(identities satisfying the Policy)
ACL is stored in “configtx.yaml”
Blocks are created by Orderers & (validated & committed by Peers)
Peer will validate all Transactions of a Block, based on conditions mark each Trans Valid or Invalid in the Block(commits all Trans)
After each Transaction is marked “Valid” by Peer in its own Block, if the Trans is Valid, then only Peer will update Global State (own Node)
Channel will authenticate every incoming Request (Peers who want to interact with Channel’s ledger)
?CCVC(Concurrency Control Version Check): keeps Ledger state in Sync across all Peers of a Channel.
If the State data read for the Transaction, has changed between Execution (Simulation time by Peer) & Commit time(same Peer), then we get CCVC violation & this Trans is marked “Invalid” on Block & the State is not updated.
Configuration Block: contains all Configuration data defining Members & Policies for a System Chain(Ordering Service) or a Channel.
Any Config modifications to a Channel or Network(member joining or leaving) will result in a New Configuration Block appended to a specific Chain. This Block will contain Contents of “Genesis Block + Delta”
At Channel creation time, all Orgs added to the Channel must be part of the Consortium
The CC definition is used by all Orgs to agree on the parameters of a Chaincode before it can be used on a Channel
Channel members need to approve CC definition
Channel member can use the CC for endorsing Trans or query the Ledger
After CC definition is approved, the CC defn is committed to Channel
CC can be started only after CC defn is committed
Endorsement is a process, where specific Peer nodes execute a CC (Transaction), and returns the Proposal response [CC execution response msg, results(read Set & write Set), Events, Signature as Proof]
Endorsement policy: defines the specific Peer Nodes on a Channel that must execute Trans attached to a specific CC and the required combination of Responses (endorsements)
A Endorsement policy could require that, a Transaction be endorsed by a minimum number or % of endorsing peers or by all endorsing peers that are assigned to a specific CC
Transactions have to be “endorsed” & only endorsed Trans may be committed & have an effect on the State
A transaction that is submitted must satisfy the Endorsement policy before being marked as Valid by committing peers
Raft protocol: Leader based consensus, where Follower Orderer Nodes replicate log entries produced by the Leader Orderer Node
Raft: Follower Nodes always receive “heartbeat” msgs from Leader Node
Genesis Block: Configuration block that initializes Ordering service or the first Block on a Chain
Gossip data dissemination protocol performs: 1) manages peer discovery & channel membership 2) disseminates ledger data across all peers on the channel 3) syncs ledger state across all peers on the channel
Hyperledger Fabric CA is Default Certificate Authority component, issues PKI-based Certs to Network member Orgs and their Users
The CA issues one root certificate (rootCert) to each member & one enrollment certificate (ECert) to each authorized user
Init function in Chaincode: initializes CC app
All CC need to have an Init function, be default Init() is never executed
Use CC defn to request execution of Init func in order to initialize the CC
CC Install: placing CC files on the Peer’s file system
CC Instantiate: process of starting & initializing a CC on a Channel
After CC instantiation only, the Peers that have CC installed can accept CC invocations
CC Invoke: used to call CC functions
CC Invoke: parameters(Channel identifier, CC func name, Array of args)
CC Invoke: If the Invoke only queried the Ledger(Read only), then the Client App would not Submit the Read-only Trans to Orderer
Each Org can have multiple Peers subscribing to a specific Channel. One of the Peer will be the Leading Peer for a Channel(Org level). This Leading Peer will communicate with Ordering Service on behalf of their Org
Ordering Service will deliver new Block to all Leading Peer of each Org. Then each Leading Peer distributes this Block to all Peers of their own Org
PKI : X. 509 certificate used, to verify that a Public key belongs to the user, computer or service identity contained within the certificate.
509 certificate includes a Public key, Digital signature & info about Identity associated with the certificate and its issuing certificate authority (CA).
SSL/TLS Certs ( both are same): they encrypt Data that is sent over Internet & provide Identity assurance also
Digital Certs: Now when someone wants ur Public keys, you send them your Certificate, other party will verify the Signature on Certificate with CA, & if it verifies, then they can trust your keys.
In SSL, the Server has a public key, which it sends to the client as an X. 509 certificate. The Client validates the certificate, then uses the public key contained therein, in order to establish a session key with the server, and encrypt the data with that session key.
Public key is embedded in the SSL certificate and private key is stored on the server and kept secret.
MSP: Membership services code runs in all Peers and Orderers, it authenticates & authorizes blockchain operations
MSP: manages identities, authenticates & authorizes
Orderers: collection of Nodes that orders Transactions into a Block & then distributes this Block to specific Peers for validation & commit
Orderers: orders Transactions on FIFO basis for all Channels of Network
Orderers contains Cryptographic identity material tied to each Member
Org is called “Member”
An Org joins a Network by adding its own MSP to the Network
MSP of the new Org defines, how other Orgs will verify the Signature of Transactions generated by Valid Identity of this new Org
MSP of new Org: The particular access rights of Identities within (new Org) MSP are governed by policies which are agreed upon when the new Organization joined the network.
Transaction endpoint of an Org is a Peer
Collection of Orgs form a “Consortium”
Peer: network entity that maintains a Ledger & runs Chaincode containers in order to perform read/write operations to Ledger.
Hyperledger Policies: used to restrict access to Resources on Network
Policy dictates who can read from or write to a Channel
Policies may be defined in configtx.yaml
Policy is specified when instantiating Chaincode on a Channel
We can connect a Peer to multiple Channels & Networks
we use different Keys to administer Nodes
All Peers in a Channel must use the same database type
Peer Containers are used, when Smart contracts are instantiated on a Channel & during Transaction processing
An HSM is a hardware appliance that performs Cryptographic operations & provides capability to ensure that Crypto keys never leave the HSM.
Certificate Authority (CA) stores Keys & Certs in PostgreSQL
CA, creates identities in form of x.509 certificates
CA will issue certificates, validate certificates & user authentication
MSP turn verifiable identities issued by CA into the members of a blockchain network.
An Org MSP, has an MSP subfolder called admins. Any user whose Certificate is inside this admin folder is an admin of the Org.
If a Org is a member of a Channel, then the Org’s MSP details is listed in the Configuration on this Channel
Whenever an admin of the Org tries to perform an action on the above Channel, the signing Certificate of the admin (which is attached to all of its interactions) is checked against the Certificates listed in the MSP of the Channel configuration.
Does the certificate of the admin, match the Cert listed in the Channel configuration? If it does, the other organizations will validate it and the action can be performed. If not, the request to execute the transaction is rejected.
Hyperledger uses deterministic consensus algorithms
Bitcoin & Ethereum — probabilistic consensus algorithms that eventually guarantee Ledger consistency to a high degree of probability
Ordering Service, maintains what is known as “system channel”, a default channel that hosts the “consortium”, the list of Orgs that can create & join application Channels.
Application Channels inherits certain aspects by default, from system channel (certain capability levels)
Ordering service admins will establish these defaults (system Channel)
Raft protocol, in which a Leader Node is dynamically elected among Ordering Nodes in a Channel (this collection of nodes is known as the “consenter set”) & that Leader replicates messages to all Follower Nodes
Raft is said to be “crash fault tolerant” (CFT), because the system can sustain the loss of nodes, including leader nodes, as long as there is a majority of ordering nodes (what’s known as a “quorum”) remaining.
We can deploy an Chaincode, only on those Peers who are part of the Channel (of this Chaincode)
Private Data collections:
Service discovery:
Channel Based Events:
Connection profile:
BFT ordering service:
Ledger Checkpoint:
Ledger Pruning:
create & put commands sent to Network, will go thru Consensus
delete command, can only Delete “Key” from World State, not Transactions
get command (from World State), not go thru Consensus
Clients can read Block info using REST API
MSP does 2 functions: identity validation & (signature generation & signature verification)
Every Peer & Orderer has their own CA’s
MSP uses Policy as ACL
Policy allows the Identity associated with the Request to be checked against the Policy attached with the Action taken on requested Resource
REST Proxy is used to expose Smart contract to external world
All Orgs are created separately for your Network
You need to import all Certs and JSON files (CA and Peer nodes of all Participant Orgs) into Founder Org
Each Org in a Consortium can have a Role “Founder” or “Participant”
Each Org can have diff Nodes [Console, Peer, CA, Rest proxy]
Under Founder Org screen, we need to upload Certs of Participant Orgs (for adding Participant Org to the Network) Each Participant Org should export Certs and give to Founder Org
Import all Participant Orgs ->Peer Nodes (Certs and JSON file) into Founder Org, after this you can see all Peer nodes (all Participant Orgs) info in Main Network
Merge all config & Certs data of all Participant Orgs into Founder Org
Import Founder Org ->Orderer Service JSON into all Participant Orgs
Read-only permission on a Channel can only read Transactions from Channel, but cannot execute Smart Contract on the Channel
Channels cannot be deleted
Channel attributes: (Ledger (Blocks & Trans), Instantiated CC, Peers, Orgs, Channel Policies, ACL)
Policy attributes for a Channel (Policy Name, Type, Rule)
Policy Name [Admins, Creator, Readers, Writers]
Policy Type [IMPLICIT_META, SIGNATURE]
Policy Rule [Admins, OR[MSPID.ADMIN]]
ACL attributes for a Channel (Resources, Reassign with (Readers or Writers))
Resources=[lscc/GetChaincodeData, qscc/GetBlockByNumber]
In Fabric v1.0, the User could interact directly with Peer/s
In Fabric v2.0, the User cannot interact directly with Peer/s, but can invoke the Smart contracts
What is Orderer genesis block? this is the genesis Block for the system Channel, as it is the basic Configuration Block for the Network.
System Channel is a special Channel, managed by Orderer admins, it includes a list of Orgs permitted to create new Channels.
Every participating Org in a Channel, has an anchor Peer.
anchor Peer, main role is Peer discovery
anchor Peer is always attached to a specific Channel
anchor Peer, allows for Peers belonging to different Members(Orgs) to discover all existing Peers on a Channel.
Client app: submits an actual Transaction-invocation to the Endorsers & broadcasts Transaction-proposals to the Ordering service
User chaincode has 4 life cycle steps “Install”, “Instantiate”, “Invoke” and “Query”.
Participants in Hyperledger network are not Users, but entire Orgs.
“peer chaincode” command allows Admins to perform Chaincode operations on a Peer, such as installing, instantiating, invoking, packaging, querying, and upgrading chaincode
CA is used to create Identities & MSP’s
A CA’s Certificate Revocation List (CRL) documents the Certs that are no longer Valid. For example, a Certificate may be revoked because the cryptographic private material associated to the Cert has been exposed.
Instantiate the Chaincode: You will install Chaincode only on those Peers (Node file system), who are part of the Chaincode channel. CC must be instantiated on the Channel, so that Peers can interact with the Ledger via the Chaincode container.
The CA generates a new Certificate M (Client Metadata + Public Key Y) & new Private Key Z. Later the CA, will generate new Signature for Cert M using Pv key Z
Keystore is a Server-side asset that stores private keys & Certs with their public & private keys. Truststore is a Client-side asset that serves as a Repo of Certs that the Client should trust.
180+ root Certs trusted in Mozilla Firefox browser, 80 organizations
How does a Browser verify a Certificate? a Browser will obtain a sequence of Certs, each one having signed the next Cert in the sequence, connecting the signing CA’s root to the Server’s Cert. This sequence of Certs is called Certification path.
Should I trust Intermediate CA or Cert? You only need to trust Root CA. Intermediate (and other)Certs will be checked, if they are signed by a trusted root CA, or a intermediate that is trusted by a root CA. If that root CA is trusted by you, all Certs signed with Root CA will be trusted by you.
How CA signs a Certificate? The CA signs the Server’s public key with their private key and then gives Signature to Server. When the Client connects to a Server, the Server sends both its Public key and the Signature to Client. Clients already have the public keys of all CA’s they trust. These are called root Certificates.
The usage of an intermediate certificate thus provides an added level of security as the CA does not need to issue certificates directly from the CA root certificate. The Intermediate CA supplies the necessary chaining to a trusted root in an SSL connection and acts as a link for trust.
new CSR request to a CA : When you create a new CSR, the private & public keys are created. A CA will use CSR(Metadata+Public key only) to create your SSL Cert, but it does not need your private key.
A private key is created by you, Certificate Owner, when you request your Cert with a Certificate Signing Request (CSR).
The Digital signature of the CA is vital to trust the certificate.
The private key should be kept secret at all times and should therefore not be published in a digital certificate.
A root certificate is a public key Cert that identifies a root CA
Org identity : Org Name & Org MSP ID
Admin user Identity : Username, Private Key & Certificate
Peer attributes: Peer Name(URL), RPC endpoint(URL), Owner, Client version, Location, Configuration(Anchor or Committer)
Network details : Orderer name(URL), Orderer RPC endpoint(URL), Default Channel ID, Orderer TLS cert, Connection profile
The introduction of “leader” optimizes the overall process as Ordering service only sends to the leader of each organization, and leader to other peers in this organization.
Leader is per organization. Each organization will have its own leader. Leader is also per channel.
Before joining a channel, there is no “leader” concept. It becomes relevant after the peer joins a channel.
Anchor peer is needed in a network for peers to learn channel members outside its own organization.
Without an anchor peer, knowledge of channel members is only limited to just one’s organization.
For example, without an anchor peer, peers in Org1 only know peers in Org1 as channel members, but no knowledge of peers in Org2.
At least one anchor peer is needed on a channel such that any peers in every organization know all other members in this channel.
Other than a preset configuration, anchor peer requires configuration update to a live channel.
An update transaction is first created using configtxgen and a proper configuration file. This transaction is signed and sent to ordering service.
A new configuration block carrying this anchor peer update transaction, is generated by ordering service. After this block reaches all peers joining this channel, each peer commits the block and now knows the anchor peer. Through gossiping each peer now knows all peers, both inside and outside its own organization, as channel members.
a network of two peer organizations, Org1 and Org2, each is configured with two peers (peer0 and peer1). A channel mychannel is created and joined by all four peers. Peer0 of Org1 and Org2 are configured as Anchor Peers.
Create a new Network : Generate crypto material and channel artifacts for the whole network -> Bring up all network components ->Create genesis block for “mychannel” ->Join all four peers (from both organizations) to “mychannel”->Update anchor peer configuration for both Orgs->The network is ready for deployment->Each peer knows other peers in this channel, in its own organization and others.
Peer joins a Channel mychannel->“peer channel join -b mychannel.block”
Gossip works well within an Org, as peers know each other inside an organization.
As peers need to know peers in other Orgs. For this we need to configure an Anchor peer, for Gossip Protocol
Without anchor peer, peer has no knowledge of cross-organization channel members
All Peers of all Orgs learn about each others using Gossip protocol
Each peer inside a Channel knows of all other peers, inside and outside its organization
When Endorsing Peer(EP) gets a Transaction from Client for validation, the Endorsing Peer will check the Signature of the Transaction
EP will first check the Certificate of the Client (User)
Private Key is also called == Signed Key
Public Key is also called == Verify Key
Transaction Proposal contains [MSP_ID, Certificate, Channel_ID, Chaincode_ID, Function name, Arguments to Function, Signature]
Install Chaincode : pass arguments-> [CC Name, CC Package ID, CC Version, CC Sequence Number, Channel ID]
Commit Chaincode : pass arguments-> [Orderer_address, Channel ID, CC Name, CC Version, CC Sequence Number]
When you Invoke CC : pass arguments-> [Channel Name, CC Name, Peer Node Address, User Certificate]
Under orgs->org1.example.com->users->admin user of the org1.example.com->certs-> cert name “admin@org1.example.com-cert.pem” contents ->(Serial number, Issuer, Validity, Subject, Public Key of the Subject, Issuer Signature)
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a

making HyperLedger Blockchain …simple & my learning : June 2020

Written by Docker Turtle

No responses yet