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
Related
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.
In the transaction flow documentation
5. Transaction is validated and committed
The blocks of transactions are “delivered” to all peers on the channel. The transactions within the block are validated to ensure endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution. Transactions in the block are tagged as being valid or invalid.
Does it means that a block holds invalid transaction also?
Yes - since blocks from the orderer are signed, the peer serializes the entire block with both valid and invalid transaction. It adds external metadata to the serialized blocks to mark invalid transactions. And of course the state changes for invalid transactions are not applied to the state database.
Even I was confused about it initially, and had to re-read the documentation for better understanding.
As we know - a Hyperledger Fabric Ledger consists of two parts - 1. World State and 2. Transaction Log. So, what happens is, after an orderer sends a block containing ordered transactions with policies and transactions verifications, it is received by an anchor peer which in turn broadcasts the block to all the other peers in the channel.
Once a peer receives the block, it goes through every transactions in the block and validates the transaction - i.e. Policies Check, and sanity check of transaction details against the world state data. If a transaction is found defective on any account (Policies/Data check), the peer marks the transaction invalid and does not commit the transaction on the world state. In contrast, if a transaction is valid, the peer would perform actions (Add/Update/Delete) on the world state based on the transaction's read/write set.
Once all the transactions are processed, the block would be appended to the transaction log (aka Block Chain). Which means, the block in the blockchain would contain both valid as well as invalid transactions and transactions would have markings stating whether it is valid or invalid one. A peer can rebuild the world state by going through the transaction log - in that scenario, only valid transactions would be considered for rebuilding the world state.
There is also another answer on the similar line - https://stackoverflow.com/a/50622463/2040522
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.
I'm studying Hyperledger Fabric.
And I have two questions in transaction flow.
(I'm so sorry that my english is not good)
[Simple example] -> transaction flow
A : 100 , B : 50
A send 10 point to B.
Ordering service has a consensus (PBFT, kafka, SBFT, etc...)
1) Client request a transaction.
2) Peer checks the transaction and executes the chaincode function.
And Peer saves the result in world state(KVS or CouchDB -> A : 90, B : 60).
3) Return result to client. Client sends the result to ordering service.
4) Ordering service collects transactions and sorts them by time.
(Does consensus also.)
4-1) Create a block.
5) Ordering service broadcasts the block to peers, and peers commit the block to ledger.
[Question]
In flow2, the transaction's result was stored in the KVS or CouchDB.
If I query about remains point of A before block creation is complete,
Is the response {A : 90} ? or {A : 100}
(requests query between flow3 and flow4. before flow4,5)
In flow4 and flow4-1, ordering service checks the transactions (by consensus?) and sort them.
If one transaction was refused, (by consensus or some errors or etc...)
and the block was created.
Then how the world state (KVS or CouchDB) value rollback ?
(rollback by transaction log??)
Thank you for reading my post.
In your step 2, the peer does not store the state. Rather, it has simulated the proposal and records the read and write sets for the transaction (the read set being the state prior to the simulation, the write set being what will be committed/written to the ledger after ordering and subsequent validation against endorsement policy (in step 5).
The flow is:
client submits transaction proposal to 1-n endorsing peers in
channel
endorsing peers simulate transaction, returning signed read/write
set to client
client compares results, packages up simulated transactions and
sends to ordering service
ordering service performs consensus and adds transaction to a block
ordering service broadcasts to validating peers in channel
validating peers validate the transactions in a block to ensure that
a) the read set is unchanged, b) the endorsement policy is satisfied
and c) all signatures are valid.
finally the validating peer
applies the write-set to update world state and the block is added
to the ledger even with invalid (uncommitted) transactions.
Hope this helps. You can find more information in the documentation.
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.