In version 1.x of Fabric you can use Couchdb as a state store. How does Fabric ensure the integrity of the state? For example, what if someone manipulated the state outside of Fabric by directly accessing Couchdb on a specific node. At a minimum that could cause that node to be inconsistent with the rest of the network.
The way to detect someone has manipulated and tempered state in one of the peers is to leverage and carefully define endorsement policies.
For example suppose you have two organizations and each have two peers: OrgA, OrgB and peer1_orgA, peer2_orgA, peer1_orgB, peer2_orgB. Hence you can define an endorsement policy which will require endorsement of all 4 peers. Next, suppose peer1_orgA got compromised and state forged.
Since client has to satisfy the endorsement policy it will send transaction proposal to all peers, peers will simulate transaction and return RWSet based on the state and signature on hashed RWSet.
Now, since state of peer1_orgA forged it will return different RWSet and therefore signature will differ as a consequence client won't be able to satisfy the endorsement policy moreover it will be able to discover that result of peer1_orgA has diverged.
This allows you to prevent fork in the state, as well as takes care of non-determinism ensuring integrity of the state.
Related
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.
In Hyperledger Fabric, one asset has multiple transactions. These transactions update the state of the asset and maintain a trace as well.
Currently, if I want to have different transaction types for one asset, then I've written different functions in the chaincode which correspond to transaction types.
For example: If my assets are Cars, then each asset can have transactions of types sale, purchase, service, repair, etc. For each of these purchase, repair, service, etc., I've written a function in chaincode which gets invoked based on the type of transaction that is sent as input (type of transaction is sent as an argument in peer chaincode invoke command).
Do you think this is a good approach? What do you follow? What is recommended to achieve different transaction types?
Also, how can I enforce different endorsement policies for different transaction types?
Note: I'm aware of the asset based (or key based) endorsement policies (Fabric v1.4) that can be written in chaincode. But this does not allow me to configure endorsement policies based on transaction types.
The pattern you are using is fairly typical ... chaincode is after all really just a state machine. It's fairly common to have different chaincode representing different types of assets or asset classes. You'll typically have multiple functions which manage the lifecycle of the asset (which it seems you do). The typical pattern is that the first argument when invoking chaincode represents the function you wish to invoke but up to you if you want to modify that pattern.
In terms of having different endorsement policies for different actions taken on the same state, this is not supported as it's typically not needed. You need to take care not to confuse endorsement policies (agreement on the output of an invocation) with an agreement protocol (e.g. I agree to sell you my car). That type of logic is typically handled within the chaincode function(s) (for example you'd check that the creator of the invoke is actually the owner of the car).
Hope this helps.
P.S. If you did want to have different endorsement policies for different transaction types, you could probably use state-based endorsement ... the policies are set via chaincode anyway ... so you could attempt to set the endorsement policy for each state based on the transaction type.
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.
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.