Here is the log of Hyperledger Fabric test network. There are 2 peer node(peer0.org1.example.com & peer0.org2.example.com) and 2 orderer node(orderer.example.com & orderer2.example.com).
My question is what 「writeBlock」,「StoreBlock」，「Validate」「commit」stage actually does? I know that at 「propose」stage, a chosen orderer(in this case, orderer.example.com) will create a block and then send the created block to other orderer such as orderer2.example.com. However, I don't understand what orderers does at「writeBlock」stage. Do they sign the created block at 「writeBlock」stage? Next, peer nodes received the block from who? orderer.example.com or orderer2.example.com? In my guess, I think it's from orderer.example.com but I'm not sure.
I don't understand what orderers does at「writeBlock」stage.
I'm not sure about those stages (writeBlock looks self-explanatory). I don't know about "StoreBlock", it isn't mentioned in the official docs. I'm wondering which Fabric version you are using.
Next, peer nodes received the block from who?
In a RAFT network you have a leader/follower model. You can think of a leader peer as an entry point/doorman for all communication coming from the ordering nodes. An ordering node sends blocks to the leading peer(s) of each organization; the leading peer is then responsible for distributing those blocks to other peers belonging to the same organization. Distribution is done using gossip protocol.
Hyperledger Fabric is a complex system, with many components and a lot of moving parts.
The log that you are referring to is the log of the orderer node - orderer.example.com. It's a part of the Fabric test network. You can see what's happening in detail by looking at the logs of other Fabric components, such as peer node logs.
The Fabric network has a set of orderer nodes, which are responsible for ordering the transactions and creating blocks in the blockchain.
The orderer nodes are configured to use a consensus algorithm (such as Solo or Kafka) to achieve a consensus about the order of the transactions.
A Fabric network has a set of peer nodes, which are responsible for executing the chaincode (smart contracts) and catching and validating the transactions.
The Fabric test network consists of one orderer node, which is configured to use Solo consensus algorithm. This orderer node is orderer.example.com.
The Fabric test network consists of two peer nodes, which are peer0.org1.example.com and peer0.org2.example.com.
The log that you are referring to is the log of the orderer node - ord
Related
I want to ask about blockhain Hyperledger Fabric. Is it possible to let Peer nodes to do Orderer node's task which is packing the transaction into new block?
I kind of think the orderer node is kind of a redundant node since for example in Bitcoin network, the packing of the transactions into block and the verification of new transaction is solely done by the full node(miner node).
Can anyone give me justification why there should be orderer's node in the Hyperledger Fabric?
And if I were to build my project on Hyperledger network and forgo orderer node(which means the peer node will do both the verification of transaction and the packing of transaction) is it possible?
Please tell me your thoughts and ideas.
Thank you.
TL;DR
HLF by design is deterministic so the orderer nodes are important. Only they participate in consensus not all peers and the blocks they produce are Final (Not prone to forks).
No you cannot make a peer orderer as well. Your network configuration for HLF must have at least one orderer to work
Hyperledger Fabric (HLF) vs Bitcoin
HLF is a private permissioned blockchain where as Bitcoin is a public permissionless blockchain. You should not expect them to work similarly.
Public blockchains
In public blockchain for example bitcoin everyone is treated equal in other words no one have special privileges you may think well miner are the ones minning block but the important point is anyone can become miner its open game no restriction on who can become miner or who can run a node etc.
Private Blockchain
In private blockchain for example HLF roles are predefined at the time of setting up and starting blockchain. Each role has certain tasks and privileges and restriction. The no of organisations peers, endorser peers, orderers, channels all are predefined and some have special privileges which no other role has like orderer whose is responsible for receiving endorsed transactions from peers and put them into blocks then these blocks are distributed to all peers. These blocks are Final.
But Why?
Private Blockchains (Like HLF) full-fill special use cases for example supply chain, B2B operations In such use cases one may want to harness positives of blockchain like transparency, auditing, provenance but may also want some sort of role based access or restrictions of certain data to certain audience public blockchains like Ethereum and bitcoin does not fit here.
Now coming toward your question
Why is there an orderer node in HLF isn't it redundant ?
No it's not redundant, HLF has deterministic consensus algorithms where as Ethereum and Bitcoin have probabilistic consensus algorithms which means there can be ledger forks. In HLF there are no Ledger forks because fork occur when two equal participants have conflict at a common point. Incase of HLF the participants are not equal as peers cannot participate in consensus process the block order set by orderers is Final. And rightfully so because for the use cases it is designed for does not want forks and want to have special roles and much much more transaction throughput.
Must must Read !
https://hyperledger-fabric.readthedocs.io/en/release-2.2/orderer/ordering_service.html#what-is-ordering
No it is not possible to assign peers orderer's role you must have at least 1 orderer in your HLF network to work.
In Hyperledger Fabric, what is the expected behavior of peer when all orderer nodes are down.
Should peer also down, or stop serving request from client, or continue to serve query request?
In our test, after orderers are stopped, the peer keeps writing "failed to create connection to orderer" log. When we query a key by calling chaincode the value is returned.
Can you help clarify if this is expected behavior. Thank you.
I am working on a distributed hyperledger fabric network. I would recommend the Orderer Raft Consensus https://hyperledger-fabric.readthedocs.io/en/release-2.2/orderer/ordering_service.html#ordering-service-implementations.
I have solved this in such a way that in my case I have three orderers that run independently on different environments.
If I crash all these orderers, the peer containers will continue to run on the other participants of the network. As you said, they cannot make any transactions.
If one of my orderers crashes it is not so bad after the raft consensus, the containers keep running. If another one fails, no transactions can be made. In this case I let the peers continue and check if the orderers are available again.
The behaviour you described I would put down to the fact that the peer requests the value from his ledger, he doesn't need an orderer for that. https://hyperledger.github.io/fabric-chaincode-node/master/api/fabric-shim.ChaincodeStub.html#getState
Have a read of this: https://github.com/hyperledger/fabric/blob/master/docs/source/peers/peers.md This is the best documentation for how the system works I've found and there's more in the docs directory on the repo for orderers, etc.
My understanding is: The peers are there to sign (endorse) transaction proposals. The orderer exists to order, validate, package and distribute transactions to peers. The peers can also distribute their knowledge of validated transactions via the gossip channel.
If all orderers go down, the transactions will not be validated/packaged/distributed so the blockchain will be out of action until the orderers are restored.
When we query a key by calling chaincode the value is returned.
Peers will still remain up and ready to sign/endorse transaction proposals, and querying the blockchain held at the peers will still work. Chaincodes are hosted by the peers. Orderers do not host chaincode.
Also see here https://github.com/hyperledger/fabric/blob/master/docs/source/orderer/ordering_service.md#ordering-service-implementations for the various modes the orderer can be run in: Raft mode, Kafka ordering, Solo ordering.
I think the current observerd behavour is expected and in my view it is just fine.
Let's check the purpose of orderer?
Order the transactions
Cut the block and distribute the block amongst the orgs when the criteria is met ( min txn/size or time).
This also means, orderer is needed when your Fabric network is processing those transactions which intend to write data into the ledger, isnt it? And Query is not a transaction which writes into the ledger. So it doesn't need the orderer. For query, it will pick up the data from the peer's local database.
So I think what could be done is, to send out an alert to the production support when your application detect orderer node down ( with some health check ? ). And your application displays a dimnished capacity/limited operations message while work on bringing up the orderer network, the system can still serve the search queries.
From my view, its just fantastic. But its finally upto you. Cheers!!
Consider the following situation:
I am running fabric-samples/first-network for the HLF in RAFT mode.
I use the CLI container to fetch the latest block for mychannel and edit the OrdererAddresses section by removing 4 orderers namely, orderer2.example.com, orderer3.example.com, orderer4.example.com, orderer5.example.com from it.
I am assuming this should disturb RAFT protocol because orderers are meant to communicate with one another by looking at the endpoints in OrdererAddresses section.
Now, the issue is that, despite the above fact, the RAFT keeps working fine. I wait for 10 minutes, assuming RAFT would break after EvictionSuspicion timeout as no longer leader can comunicate to other orderers. But this does not happen. I am still able to read blocks from the mychannel as well as I am able to submit new transactions (invoke operations) on the chaincode on that channel.
This means that OrdererAddresses are not looked into while communicating. Please correct me if I am wrong. By this, I need to know:
What is the exact functionality of OrdererAddresses section in the RAFT channels?
I learnt that RAFT orderers communicate to one another using the
host and port properties of the Consenters section for the
purpose of consensus messages. The endpoints present in the
OrdererAddresses section are used for replication of blocks.
The learning could be verified from here as answered by Yacov M.
Does the gossip protocol is used only to spread the committed blocks via all peers on the "order" stage? Does it work on the “execute” stage, when the endorsing peers execute and sign the transactions?
The gossip component is the peer's communication layer, and it contributes to the block dissemination via having peers distribute blocks among themselves instead of having all of them pull them directly from the orderer nodes.
It works roughly like this:
When the orderer cuts a new block, it appends it to its local file system.
In every organization, there is usually a peer that is selected among the peers in its organization (for that channel) to pull blocks from the orderer, and forward them to other peers in its organziation. The other peers also forward the blocks even further to other peers, etc. etc. and this all happens via a "gossip" style protocol.
I recommend that you read the gossip section in the documentation.
All,
As I know, in Hyperledger Fabric environment, an orderer delivers messages to peers. If there is an off-line peer. How is the message delivered to the peer when it recovers to ON-LINE? How does the orderer know the peer recovers to ON-LINE?
Regards,
Count
When the peer comes back online it will get blocks as follows:
If the peer is a gossip leader in the org, then it requests a stream
of blocks from an orderer via deliver API, starting at the peers
current block height.
If the peer is not a gossip leader and is
current or just a little behind (within a small threshold), then it
gets blocks via gossip from the org's leader peer (or potentially
another peer in the org).
If the peer is not a gossip leader and is
way behind (beyond the threshold), then it gets blocks via block
transfer from another peer (can be cross-org).
For more details see the gossip data dissemination layer documentation.
I'd like to add more details on the flow of state replication. First of all ordering service provides following API:
service AtomicBroadcast {
rpc Broadcast(stream common.Envelope) returns (stream BroadcastResponse) {}
rpc Deliver(stream common.Envelope) returns (stream DeliverResponse) {}
}
Where Broadcast used to send transactions for ordering to the ordering service and Deliver used by peers to request blocks from the ordering service starting from certain position. Possible options for Deliver are
message SeekPosition {
oneof Type {
SeekNewest newest = 1;
SeekOldest oldest = 2;
SeekSpecified specified = 3;
}
}
There are two possible mode of operations for the peer considering status synchronization and replication of the ledger. Generally speaking ledger blocks distributed across the network by using gossip algorithm. In order to prevent all peers connecting to the ordering service there is a notion of leader election, e.g. for each organization there is one peer selected to open connection to the ordering service and start pulling blocks and forward them to the gossip layer to make them distributed between peers in the network. Before start leader check what is the ledger height and ask to deliver new blocks starting from it, all peers monitor availability of the leader and initiate new leader election if needed.
Now, there is additional background process which collects state messages from the peers and if it discovers there is a gap between local ledger height and height of others peers in the network it will initiate replication of missing blocks, via "state transfer" process as was mentioned by #Dave.
Hence, to conclude if peers comes online and for some reason elected to be a leader it will replicate ledger blocks directly from ordering service, otherwise he will get either via gossip layer or state transfer in case of significant gap in ledger height.
You can refer to this image for a brief overview