I am curious how does Fabric choose among one of selected Organizations in an "OR"-type Endorsement Policy. Is it a random choice or does it follow a predetermined logic?
For instance, let's say that I have a following policy :
OR('Org1.member', 'Org2.member', 'Org3.member')
Now, let's say that the Endorsing Peer which is supposed to process an incoming transaction proposal belongs to Org1.
Because of uncertainty about network connectivity and availability of other organizations, Org1 would be a preferred entity elected for endorsement (because it happens locally on that very same peer).
However, is this the case in Hyperledger Fabric?
Any help understanding the above will be greatly appreciated.
Fabric clients should be aware of the endorsement policies and it's up to them to decide on endorsing peers. So in your example with:
OR('Org1.member', 'Org2.member', 'Org3.member')
client should know that in order to get valid transaction it has to be endorsed by either someone from org1 or org2 or org3. So client could send transaction proposal to some peer into org1 and wait until get response. An alternative strategy would be to send transaction proposal to 3 peers one from each organization.
Once client collects enough endorsement it will submit transaction to the ordering service and prior to commit peer will ensure that endorsement policy being satisfied. Now please note that endorsement policy doesn't specifies exact endorsement peers, but just saying that it has to be someone from that org with certificate approved by org root CA.
So right now client has to know endorsement policies and being aware of the membership to being able sent transaction proposals, however there work in progress FAB-5451, to provide service discovery based capabilities so client will be able to dynamically learn policies and will be able to query for set of endorsing peers.
wouldn't it be better to step back from talking directly to peers and orderers? use channel instead. always speaking only to specific elements is SO fragile.
Related
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.
Let's say we have a 6 peer in Hyperledger Fabric network and 3 organization. Each organization has 2 peers. All 6 peers belongs to one single channel.
What if one of the peer is down? Is the network still validate transaction and creates block?
This depends on the way your chaincode is set up. On a channel you have chaincode deployed, this chaincode has a specific version number. When you instantiate the chaincode or when you upgrade it, you can specify which endorsement policy to use.
This endorsement policy dictates what rules a transaction must satisfy in order to be validated. To be more specific, it specifies the organisations who must endorse it, via their endorsing peers, of course.
You can read more about it here: https://hyperledger-fabric.readthedocs.io/en/release-1.3/endorsement-policies.html
If one of your orgs has 2 endorsing peers and the endorsement policy requires one peer, then if one goes down, you're still fine.
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.
Can someone explain how the immutability is implemented in Hyperledger Fabric? If we have private channel with little amount of peers, how it can be guaranteed, that one side hasn't changed data in it's ledger?
In order to guarantee that no party in the channel has tampered data in its own favor you need to present sophisticated endorsement policy to include all required parties and make sure they adequately represented within endorsement policy. Hence making it obligatory for client which issues new transaction to get endorsement from all interested parties, hence ensuring that all have same consistent state. For example if you have two organizations Org1 and Org2 and they do not trust each other, you would like to create endorsement policy:
AND(Org1.memmber, Org2.member)
Therefore client will have to collect endorsements from peers of both organization to consider the transaction valid those endorsement have to sign same bytes, which won't be the case if data was forged. You can read more about endorsements in official documentation. There is also a recent publication of Fabric architecture which explains it in more details.
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