1

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?

Shubham Chadokar
  • 1,286
  • 12
  • 34

2 Answers2

2

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.

Gari Singh
  • 7,804
  • 2
  • 12
  • 31
  • what do you mean by serialized block? Do you mean arranging? Transaction sorting is done by orderer. What is this external metadata which adds to the block? Can you share the link where it is explained? Thanks – Shubham Chadokar Mar 12 '19 at 12:30
  • 1
    The blocks are serialized to disk (aka the ledger). There is a metadata structure which is part of the overall block structure ... the peer adds a section to the metadata which flags which transactions in the block are invalid before serialized the blocks to disk – Gari Singh Mar 12 '19 at 15:36
2

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

Niraj Kumar
  • 625
  • 9
  • 21