I always have a theoretical and general question in my mind: let's assume that there are two orgs: org1 and org2. And each org has one peer. If the endorsement policy is set to AND(org1, org2), which means that every transaction needs the endorsement from both org1 and org2's peer.
Let's assume a scenario: org1 and org2 have already endorsed 5 transactions. But some day, let's say, org1 doesn't want to endorse any transaction at all, which means that for every new incoming transaction(e.g. 6th transaction), org1 wants to say no, and refuses to endorse the new transaction. So my question is:
How can org1 refuse endorsing new incoming transaction? In more vivid words, as an org, how to say no? Thanks in advance.
You can actually pull this off with a little custom pluggable code which can be loaded at the startup of the peer.
What you need to do, is to create an authentication filter which will prevent endorsements and return errors instead of forwarding the request to the next authentication filter.
From the core.yaml file:
handlers:
authFilters:
-
name: DefaultAuth
-
name: ExpirationCheck # This filter checks identity x509 certificate expiration
These are the default built-in filters that exist in the peer. For example - the ExpirationCheck filter - checks for expiration of the identity of the client.
What you need to do, is to add another filter which simply refuses proposals from clients (let's name it - NopeFilter) and then compile it to a golang plugin, and add the following entry:
-
name: FilterOne
library: /opt/lib/filter.so
The content of the filter will be very similar to the DefaulAuth filter (which does nothing):
func (nf *NopeFilter) ProcessProposal(ctx context.Context, signedProp *peer.SignedProposal) (*peer.ProposalResponse, error) {
return nil, errors.New("nope")
}
At peer startup, the list of filters is read from the core.yaml section, and is then chained into a chain of filters which either reject the proposal, or pass it to the next filter.
The last filter is always the real endorser service in the peer, which actually performs the chaincode execution and endorsement (signing the results).
An endorsement is not an option, where a user chooses between yes and no. The transactions are executed in the peers having chaincode and when the peers, as specified by the endorsement policy, agree on the result then the transaction is said to be endorsed. The process of execution of a transaction may depend upon the ledgers of the peer. For example, all the peers have stored in the ledger that Ram has 50 value Ram:50, now the new transaction adds 20 value to Ram's account. This gets executed in the endorsing peers and the added result Ram:70 is agreed by all the peers. Now the transaction will be endorsed. But if the ledger of one peer is altered as Ram:40 and that peer needs to endorse the transaction, it will come up with a result of Ram:60 which won't match the result of rest of the peers and the transaction will not be endorsed.
Related
I was going through https://hyperledger-fabric.readthedocs.io/en/latest/peers/peers.html link where 3 phases of ledger updates have been discussed. My question is with regard to phase 3.We have below text at the above link:
After a peer has successfully validated each individual transaction, it updates the ledger.Failed transactions are not applied to the ledger, but they are retained for audit purposes, as are successful transactions.
Where are these failed transactions retained, are these with peer's FileSystem?
Are Failed and Invalidated transactions the same?
They are appended to the block of the corresponding channel's chain, but they do not alter the channel's state.
With "failed" you probably refer to those transactions discarded by the chaincode's logic (those returning an HTTP 500 error on endorsement as launched by shim.Error).
With "invalidated" you probably refer to those transactions that do not fulfill the endorsement policy. For instance, individual endorsements return an HTTP 200 success code, but endorsements from different peers do not match. Another example: a MVCC_READ_CONFLICT error when trying to update the same writeset in the same block.
I have query, i am reading the hyperledger fabric article, In article its mention that, User User1 sends a transaction Tx1 to Peer P1, Peer P1 endose E1, the transaction Tx1, the transaction received back to user1 and he pass it to order or1, And order will validate the Tx1 and create the block and it will commit.
My Question is :
1. when order is committing the block, why it will send to peer P1 back.
2. In article they mention Peer P1 is also validate Tx1, How Peer will
verify the Tx1.
3. If Peer P1 verify the Tx1, does Peer P1 also keep the record of all the Peers and Orderer details.
4. If Peer also can Validate the Tx1, best thing is to apply the
block/Batch creation mechanism to Peer directly, so no need of orderer. i have doubt please suggest me.
The application “broadcasts” the transaction proposal and response
within a “transaction message” to the ordering service. The
transaction will contain the read/write sets, the endorsing peers
signatures and the Channel ID. 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.
Read this doc: https://hyperledger-fabric.readthedocs.io/en/release-1.4/txflow.html
However, I will answer to your questions:
when order is committing the block, why it will send to peer P1 back.
A) Orderer will just receive pool of transactions and form blocks and ship to committing peers, it will not do any validation and it creates blocks so orderer also will have a copy of the ledger
In the article they mention Peer P1 is also validate Tx1, How Peer will
verify the Tx1.
A) If Peer1 is an endorsing peer then it will simulate the ledger by making the transaction commit and it will record the behavior it will send back to the user.
If Peer P1 verify the Tx1, does Peer P1 also keep the record of all the Peers and Orderer details.
A) By default all endorsing peers are commiting peers, so yes it will keep
If Peer also can Validate the Tx1, best thing is to apply the
block/Batch creation mechanism to Peer directly, so no need of orderer. i have doubt please suggest me.
A) Here if you come from ethereum background orderer is like a miner, here he will not do any calculations simply form batches and ship to peers like a postman job.
what does it actually mean when we say endorsing peer simulates a proposed transaction. Why does endorsing peer needs to hold smart contracts to simulate proposed transaction ?
So, keep in mind that the transaction flow works as follows:
The client sends a transaction proposal to some peers, with input parameters for the transaction, such as: "please move 20$ from alice to bob"
The peers run the transaction in the chaincode container, and afterwards sign the output of the transaction: "this is the new balance of alice, and the new balance of bob"
The client sends the transaction that contains the results and the signatures of the peers to the ordering service
The ordering service puts the transaction into some block
The peers pull the blocks from the ordering service or from other peers, and then commit the transaction (if it's valid) into the database.
Therefore, the transaction is not committed in the peers at the time of its execution, but instead - it's "simulated". Meaning - the peer runs the transaction in a simulation where the reads from the database are normal database operations that read data, but the writes to the database are not actually being written during the transaction execution - but instead, they are recorded as "simulation results" which the peer signs and returns to the client
I would really like to understand how endorsments work in Hyperledger Fabric in order to help me in designing a solution to a problem.
let's assume I am an endorser and a transaction proposal has just arrived. I would randomly select a participant within my organization, use its identity to perform the validations, checking for replay attacks etc then sign an endorsement with that participant's private key. Assuming I used an admin's credentials, the admin(person) may not be aware that I used its identities to validate and endorse a transaction proposal. Is this example correct?
Initial discussions here makes me feel like the more I look into it, the more confused I become. Could anyone help?
Just to start with, the endorser is the peer that capable to handle incoming invocation, maintain and run the chaincode. The flow works as following, support you have a client (C) and the endorsing peer (P), which runs a chaincode (CC).
Client forms transaction proposal request which includes parameters for chaincode invocation.
In order to get an endorsement for this proposal he sends it the endorsing peer.
Endorsing peer opens a transaction proposal and forwards requests to the required chaincode along the way it passes all parameters.
Chaincode get invoked which produces a RWset (set of keys and values read of changed during the invocation)
Peer collects RWset and forms proposal response and signs it
Client gets the proposal response, signs it as well and send it to the ordering service
Ordering service collects proposal responses and cuts the block which got distributed to the peers in the network.
Upon arrival peers opens a block and validates all transactions, one of the validation is to check whenever transaction conforms the endorsement policy, where basically it checks whenever transaction has enough signatures which satisfies the policy.
Back to your question, please note that at each step everyone uses its own key and certificate to sign, no one randomly selects participants to use they identities for signatures or whatever else.
PS. Note that process above a bit simplified and lack a lot of technical details.
PPS. There is a new course on Coursera which covers pretty well many technical aspects of Hyperledger Fabric architecture and the interaction between different components, I would urge you to consider taking this course.
According to architecture explained (http://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html), ordering service collects transactions (RWSets) into block for distribution to committing peers. Then, committing peer validates endorsement policy and RWsets then apply the transaction to ledger.
To verify the transaction was succeeded, should client application wait until all committing peers returned "Success" event ? Or just need to verify only one "Success" event ?
To verify the transaction was succeeded, should client application
wait until all committing peers returned "Success" event ? Or just
need to verify only one "Success" event ?
Tanaka, that's a very good question!
The short answer is No.
The reason is that in contrast to existing popular blockchains, HLF has a unique transaction lifecycle which does:
A transaction is simulated on some endorser or a few endorsers
It is sent to the ordering service and is cut into some block
The block is sent to peers, and they all execute the same validation code and all validation code for a specific transaction is guaranteed to reach the same conclusion in all peers, because they run it in the same order across all of them.
Therefore, if a transaction is validated on some peer - when other peers will receive the block the transaction resides in - they will too consider it as valid.
However - a very important aspect you should consider is data availability and synchronization.
For example, if you have an application that uses 10 peers and only 1 peer got the event and the rest didn't, and you invoke another transaction on the other peers, it might be that the endorsements that the other peers will compute will be turned into an invalid transaction, because they will simulate on old data (the fact that they didn't get the event yet proves that they have not processed the block for that transaction), so you need to keep that in mind.