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.
Related
An endorsement is the process where endorsing peers execute a transaction and agree on the result. How is it different from the consensus in Fabric?
One key difference between Hyperledger Fabric and many other blockchain platforms is the lifecycle of a transaction.
In other platforms, the lifecycle of a transaction is usually Order-execute in which:
Order: transactions are added to the ledger in some order and disseminated to all peers.
Execute: transactions are sequentially executed (e.g. using smart contract code) on all peers.
While in Hyperledger Fabric, the lifecycle of a transaction is different as it is a Execute-order-validate model:
Execute: Transactions are executed (using chaincode) in any order, possibly even in parallel.
Order: When enough peers agree on the results of a transaction, it’s added to the ledger and disseminated to all peers. This step is where the transactions are first given an ordering — until transactions are added to the ledger.
Validate: Each peer validates and applies the ledger’s transactions in sequence. Now that the transactions have an ordering, the peers can check whether a later transaction was invalidated by an earlier transaction. For example, this prevents one item from being sold two times (called double-spending).
Endorsement in Hyperledger Fabric basically allows users to define policies around the execution of chaincode. These endorsement policies define which peers need to agree on the results of a transaction before it can be added to the ledger.
Now let's see how endorsement works:
Fabric starts with a transaction proposal. It’s a bundle of information used to trigger a specific chaincode. The transaction proposal is sent to some peers for endorsement. An endorsing peer executes the chaincode, which (if it succeeds) yields an actual transaction for the ledger. The endorsing peer then signs the transaction and returns it to the proposer. This is the Execute step in execute-order-validate.
Once the creator of the proposal receives enough signatures to satisfy the endorsement policy, it can submit the transaction (and the signatures) to be added to the ledger. This is the Order step.
Consensus or Validation is the last step in which all the peers verify if there are any changes in the world state in between this whole transaction process and then validates only those transactions that are valid and marks other transactions as invalid.
In case of Bitcoin (and Proof of Work in general) there is a simple rule that provides automatic conflict resolution when there are 2 differing copies of the ledger for any reason. And that rule is the longer chain wins.
But how are conflicts resolved in case of Fabric? Saying that conflicts never occur in Fabric is not an answer because if conflicts never occur, then what is the purpose of getting endorsement from more than one peer?
Stating alternatively, if your answer is that conflicts never occur in Fabric, then please explain why would someone want to get endorsement from more than one peer?
Yet another way to frame this question: let's say the copy of the ledger hosted on the peer of another organization got hacked unbeknownst to them. Now your organization and the other organization have different records. How will the conflict be reconciled? And don't forget the havoc this will cause - all transactions submitted by users will now fail to get endorsement until the conflict is resolved. A hack on another organization disrupted your business even though your ledger was not compromised.
In Proof of work:
Client will submit a transaction and it will be in pool, any miner can take and validate the transaction and then do mining, if he get solved quickly then he will publish to other miners. Here many nodes involved in Orderer to create a block
In Hyperledger Fabric [HighLevel]:
Client send transaction to endorsing peers(more than one), endorsing peers will sent back R/W and signatures to client, if endorsement failed means data in consistency then it will mark as failed and sent back to client.
Client will send entire payload to Orderer. Orderer simply creates a block and ship to committing peers, committing peers simply very endorsements (more than one ) and commit to the ledger
No tell me by comparing both, do u think still conflicts will come in hyperledger fabric?
Purpose of getting endorsement: In order to authentic more endorsements more accurate.
LowLevel:
Stage 1: [CLient Initiate Tx]
Client A is sending a request to update the ledger.
This request targets peerA and peerB, who are respectively
representative of Client A and Client B. The endorsement policy states
that both peers must endorse any transaction, therefore the request
goes to peerA and peerB.
Stage 2: Endorsing peers verify signature & execute the transaction
The endorsing peers verify (1) that the transaction proposal is well
formed, (2) it has not been submitted already in the past
(replay-attack protection), (3) the signature is valid (using the
MSP), and (4) that the submitter (Client A, in the example) is
properly authorized to perform the proposed operation on that channel
(namely, each endorsing peer ensures that the submitter satisfies the
channel’s Writers policy). The endorsing peers take the transaction
proposal inputs as arguments to the invoked chaincode’s function. The
chaincode is then executed against the current state database to
produce transaction results including a response value, read set, and
write set (i.e. key/value pairs representing an asset to create or
update). No updates are made to the ledger at this point. The set of
these values, along with the endorsing peer’s signature is passed back
as a “proposal response” to the SDK which parses the payload for the
application to consume.
Stage 3: Client Proposal responses are inspected
The application verifies the endorsing peer signatures and compares
the proposal responses to determine if the proposal responses are the
same. If the chaincode is only queried the ledger, the application
would inspect the query response and would typically not submit the
transaction to the ordering service. If the client application intends
to submit the transaction to the ordering service to update the
ledger, the application determines if the specified endorsement policy
has been fulfilled before submitting (i.e. did peerA and peerB both
endorse). The architecture is such that even if an application chooses
not to inspect responses or otherwise forwards an unendorsed
transaction, the endorsement policy will still be enforced by peers
and upheld at the commit validation phase.
Stage 4 : Client assembles endorsements into a transaction and broadcast
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.
Stage 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.
Stage 6: Ledger updated
Each peer appends the block to the channel’s chain, and for each valid
transaction the write sets are committed to current state database. An
event is emitted, to notify the client application that the
transaction (invocation) has been immutably appended to the chain, as
well as notification of whether the transaction was validated or
invalidated.
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.
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.
According to hyperledger fabric documentation, the chaincode should only be deployed in endorsing peers, and it says still the non endorsing peers can validate and update the ledger. Now I am bit confused if non endorsing peers don't have a chaincode, how can they generate R/W sets. How the non endorsing peers will be able to create new state for the asset, if they aren't aware of the logic (chaincode) behind it ?
If you look at https://hyperledger-fabric.readthedocs.io/en/release-1.1/txflow.html#, you'll find a section that states:
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.
A block is an ordered set of transactions and transactions include the state transitions in the form of read/write sets. The output of endorsement is actually the read/write set and these are what are ordered and delivered to all peers in the channel.
In order to validate a transaction, a peer needs to check the following:
Is the transaction well-formed
Was the endorsement policy met (the
endorsement policy is distributed to all peers in a channel when
chaincode is instantiated even if the peer does not have the
chaincode bytes)
MVCC check
In order to do the above, peers do not need to execute the chaincode itself.