In Fabric, we know the term of peers, according to the docs, as
a fundamental element of the network because they host ledgers and
smart contracts
Based on that, I assume that peers are some kind of hardware servers that organization assign.
But I'm not so sure about that, so I ask:
What exactly is the physical representation of peers in real-case organization?
Is it a computer that must always be online? Is it operated by some person in the related organizations?
It is also said in this paper on page 6 about the consensus process, that
In particular, this requires all endorsers
as determined by the policy to produce the same execution result
(i.e., identical readset and writeset). Then, the client proceeds to
create the transaction and passes it to the ordering service
This leaves me to the next question:
In real life usage, if the endorsing peers failed temporarily (say, due to electricity issue), does it mean that the blockchain transactions can't happen in that time?
A peer is a software service. An organization can have multiple peers running for resilience. When a peer fails, for whatever reason, when it is restarted, it will catch up with the other peers in an organization's cluster either by receiving missing transaction blocks from the orderer, or by gossiping with other peers.
If an endorsing peer fails, it does not necessarily mean that the transaction processing will be blocked. Again, an org can have multiple redundant endorsing peers, and depending on the endorsement policy chosen for the channel, propose the transaction to other endorsing peers for that channel in order to receive the requisite number of endorsements to satisfy the policy.
Of course, if you ran a single endorsing peer for a channel/network... then yes, if it failed then transaction processing would be blocked. That would not be a wise deployment choice;-) Fabric was designed for resilience.
Related
Sorry for the long question but Hyperledger is a fairly complex system.
Reading the Blockchain network In the section Generating and accepting transactions
In contrast to peer nodes, which always host a copy of the ledger, we
see that there are two different kinds of peer nodes; those which host
smart contracts and those which do not. In our network, every peer
hosts a copy of the smart contract, but in larger networks, there will
be many more peer nodes that do not host a copy of the smart contract
How to design the blockchain network and to decide how many peers should have smart contracts and how many should not?, Is there any design rules or patterns ?
When we have multiple organizations, should every organization has an endorsing peer, or they all can have only one within one organization and all other can call it ?
How to design the blockchain network and to decide how many peers
should have smart contracts and how many should not?, Is there any
design rules or patterns ?
My rule of thumb is - you first think about the endorsement policy, and then you install the chaincode on peers that belong to organizations that are in the endorsement policy.
Then, you can also optionally install the chaincode for query-only transactions (that don't get into the Blockchain) on peers of organizations regardless of their involvements in the endorsement policy or not, because it makes sense that a client would want to query its own organization (since it trusts it the most).
The only corner case is that sometimes the code of the chaincode is not known and the organizations of the endorsement policy, do not want to share it.
When we have multiple organizations, should every organization have an
endorsing peer, or they all can have only one within one organization
and all other can call it ?
It depends on the use case. Some organizations have clients only, and some organizations have peers only, or only orderers.
Whether an organization is an endorser for a chaincode, usually depends on the endorsement policy.
Given the fact that all peers are running the same chaincode and have same ledger, does it make any difference whether one or multiple peers are chosen for endorsement? Isn't getting endorsement from multiple peers redundant?
Hyperledger fabric uses order-execute model by separating the transaction flow into three steps:
execute a transaction and check its correctness, thereby endorsing it,
order transactions via a (pluggable) consensus protocol, and
validate transactions against an application-specific endorsement policy before committing them to the ledger.
When a peer gets a transaction, it executes transactions against the current state data held by it to simulate the transaction.
The most probable reason for multiple peer endorsement is to ensure concurrent states across peers upon execution of the transaction and ensuring correct transaction execution, This is necessary to ensure data that was read during chaincode execution has not changed, and therefore the execution results are still valid and can be committed to the ledger state database.
I don't know some details about Fabric in this document.
Document: The application verifies the endorsing peer signatures and compares the proposal responses.
Is it necessary to have all the responses the same when verifying， or most of them？
If it is part of them, what is the ratio?
Whether it can be controlled by the Fabric SDK?
Document: The ordering service does not need to inspect the entire content of a transaction in order to perform its operation, it simply receives transactions from all channels in the network, orders them chronologically by channel, and creates blocks of transactions per channel.
Raft and Kafka are only used to guarantee availability, not for voting. Is this correct?
Document: Transaction is validated and committed.
When committing, is there a process of voting verification?
The application does not actually need to check anything (it's
optional but a good way to avoid sending invalid transactions).
When you instantiate chaincode on a channel, you set the endorsement policy for that chaincode. The endorsement policy specifies how many organization's peers must sign the response. This is actually enforced during validation on the peers (after the peer receives blocks/transaction from the orderer but prior to committing the data). If there are not enough signatures to satisfy the policy, transactions are marked invalid and state is not committed.
With Fabric v1.2 and later, clients can use the discovery service to obtain the minimum list of peers required to meet the endorsement policy for chaincode on each channel.
Kafka / Raft are used to ensure that all ordering service nodes process transactions and deliver blocks in the same order. With Fabric v1.4.1 you will have the option to use Raft consensus rather than Kafka.
See comment in 2. about enforcing endorsement policies during validation.
Below is my understanding of a Hyperledger Fabric system. Do let me know if any of it is incorrect.
1) So we have peers (endorser, anchor, general (who has the ledger), orderer). Also when we setup the fabric, let's say we registered two organizations. let's call them Company A and Company B. Now what I should do is use cryptogen to generate their certificates which go to specific folder.(in crypto folder, what I'll have at this stage is keystore and signcerts for Company A and Company B).
Now for these companies, A and B, I also make the peers for them. Let's say I give peer0 (anchor) to Company A and peer1 (anchor) to Company B and also
I give peer2 (general) to Company A and peer3 (general) to Company B and also I give peer4 (endorser) to Company A and peer5 (endorser) to Company B. As my understanding each organization must have at least 1 endorser peer (who receives requests from client), at least 1 general peer (who has the ledger) and at least 1 anchor peer who gets blocks from orderer to give it to general peers in the same organization.
So this is the setup. Let's say I give these peers to company A and B and I also setup orderer peer (let's leave it as SOLO). before I run the network, I also need to have genesis block and channel. Let's create global channel and call it EveryoneChannel and put all peers in it.
I will go on. Now when I want to have chaincode, which node should have this written chaincode? My understanding is that chaincode must be owned by endorser, because as I read it's the one who executes chaincode to simulate proposal to return it to user. So endorsers have chaincodes? General peers have ledgers. anchors get blocks and give it to general peers in the same organization. I know what orderer does.
Who are the clients? I have read many times that clients make transaction requests to network. So my guess is in each organization, for example Company A, Company A can register employees that will be binded to Company A's Organization. Let's say Company A has registered three employees, employee1, employee2,employee3. so what will happen is 3 certificates will be created for these employees and they will also be saved in crypto folder.
Now what can happen is employe1 can make a transaction request to the endorser peer that is in the same organization as is employee1. employee1 already has the certificate as I mentioned so request and response and transaction will be valid. Company A's endorser will take care of it.
Now I also have read about endorsement policy. so it means transaction will be valid if it will be validated by n-th times of number peers from organizations and it's said that this endorsement policy is written
in chaincode. if we have Company A and Company B, and their endorsers have chaincodes, should I put endorsement policy in both of them? I guess when client makes transaction request, he can only make this request to his only organization, not other organizations. so Company A's endorser will have this chaincode and endorsement policy. so what will happen? Company'As endorser also throws this request to Company B's endorser and waits its response and returns two responses to client?
First, I would refer you to the answer for this question. It explains the different peer types, as well as linking to the relevant Hyperledger Fabric documentation. The documentation explains everything much better than I could, with some nice diagrams :)
You have the right general idea about how the network is configured and operates, but to pick up on a couple of points in your question:
Anchor peers do not have any special responsibility for distributing blocks, they merely act as initial connection endpoints to allow other organizations to discover all other peers in the network. See here for more details on how this works.
The endorsement policy is defined when the chaincode is instantiated. If an endorsement policy requires endorsement from multiple organisations, the client initiating the transaction must send the transaction proposal to an endorsing peer for each organisation required by the endorsement policy. Once all necessary peers have returned a properly signed transaction response, these are then sent to the orderer for packaging into a block, and transmission to all peers. On receipt of a block from the orderer, each peer then performs it's own validation against the endorsement policy, before committing the block to its copy of the ledger.
NB: I am seeking to understand how endorsements works in general. This will help me determine how to design applications when using Hyperledger Composer.
When I read the links here and here, I came across this statement: "Transactions have to be “endorsed” and only endorsed transactions may be committed and have an effect on the state". The statement is clear. However, let's consider the composer developer tutorial here. We have a commodity that is currently owned by an owner(Trader1) who could sell it to somebody else(Trader 2). Currently, how many endorsements are needed for the transaction to be put on the blockchain? Because, when running the application, I only submit a transaction Trade and I get results. I only deal with one function, and I get results. The following things are transparent to me as a programmer:
Creation of a transaction proposal,
When the transaction proposal is endorsed and by whom,
Whether an endorsement is performed explicitly by a human on the other end or it's programmatically done by code
That there is a proposal response from the endorser and how many they are,
When the application verifies the endorsing peer signatures
When the application creates a transaction message from the transaction proposal and response
etc.
All I do is submit one transaction and get a result.
So it becomes hard for me to assess the value of endorsement policies besides the theory in the text. And thus, the difficulty in designing a program to utilize the same. For example, consider two scenarios which we could use to handle a Trade:
We need 2 endorsements from the seller and the buyer before a transaction is commited. This would effectively be one transaction (This is what is transparent to me)
We need 2 authorizations from seller and the buyer before a transaction is commited. These authorizations could update states in the commodity such that we capture the approval from both the seller and the buyer. This could be 2 transactions i.e. sellerTradeRequest, buyerTradeApproval. The sellerTradeRequest could update commodity.sellerApproval=true while the buyerTradeApproval could update commodity.buyerApproval=true. Then, a final trade transaction that checks that the states on the commodity are OK i.e. commodity.sellerApproval=true and commodity.buyerApproval=true before commiting the transaction.
If I get a clear distinction between 1 and 2, especially how composer enables 1 above. Then maybe I will start understanding how to use endorsements.
Could anyone help?
The endorsement process is described in the docs. That said, in simple terms, the process of endorsement involves an endorsing peer signing the read/write set of a transaction proposal with its certificate. This basically says: the peer identified by the signing certificate asserts that these are the read/write sets of the proposed transaction simulation.
A client that invokes a proposed transaction will need knowledge of the endorsement policy for that channel/chaincode so that it can transmit the proposed transaction to each of the endorsing peers (or to a sufficient subset of endorsing peers to satisfy the policy). When it has received the responses from each endorsing peer, it will check that the transaction is valid and then broadcast the endorsed transaction to the ordering service, which will add it to a block and broadcast to the validating peers for that channel.
Validating peers will then validate the endorsement policy of the channel/chaincode against the transactions in a block to ensure that:
all endorsements are valid (i.e. they are valid signatures from valid certificates over the expected message)
there are an appropriate number of endorsements
endorsements come from the expected source(s)
If the endorsement policy is satisfied, then the transaction is committed and the world state updated with the read/write set.
At present, Composer cannot manage the endorsement policy, but this is definitely on the development roadmap.
The endorsement policy enables you the chance to add an extra verification layer to your Blockchain. You define it when you create the channel.
When a (Initial) Peer sends a proposal, firts of all the proposal is send to all of the Peers that you have defined in your Endorsement policy.
Then, each Endorser Peer executes the proposal against its ledger. The Endorser Peer will send the result signed to the Initial Peer.
The Initial Peer will receive more than one respone. Then, the Initial Peer will verify all the signatures and will compare the result of each response. The result sent by each Endorse Peer have to be the same.
In that case, the Initial Peer will send the transaction to the Orderers. That transaction will wraper all the responses all of the Endorses Peers.
So, you should define your Endorsement policy according to your requirements