Deterministic Transaction

Issue #?

Hyperledger Fabric transaction is a chaincode function invocation, which typically reads some variables, performs some logic, then writes the variables back to persistent store, part of the ledger. The variables are part of the state key-value pairs, isolated per chaincode. If a chaincode is none deterministic (malicious code or bugs), the resulting variables on each peer might be different, which would cause the block to be rejected from committing to the blockchain.

This proposal (suggested by @chetmurthy) outlines a method to ensure that accepted transactions are deterministic and verifiable thereafter.

Let's call the variables that a chaincode reads, during a transaction, a "readset", and likewise, the variables that a chaincode writes, a "writeset". Let's also make sure that each variable keeps monotonically increased versions; that is, every time a variable is updated, its version is increased.

When a transaction T arrives at a peer, the peer prepares T as follow:

1. Verify T transactor's signature
2. Speculatively execute T. This execution holds the result in a temporary buffer as implemented now. The peer collects the readset and the writeset, including the versions
3. Set T' = T + readset + writeset
4. Send T' to consensus
5. Consensus validates T' and if agreed, include it in block
6. Peers applies T' from the block

T' is recorded on blockchain if it is committed. This will include the necessary data for post verification without requiring replaying the transactions from genesis or from last checkpoint snapshot.