Fabric uses a multiversion concurrency control (MVCC) mechanism to ensure consistency in the ledger and to prevent double spending. Double spending attacks aim to exploit flaws in systems by introducing transactions that use or modify the same resource multiple times, such as spending the same coin multiple times in a cryptocurrency network. A key collision is another type of problems that can occur while processing transactions submitted by parallel clients, and which may attempt to modify the same key/value pairs at the same time.
In addition, due to Fabric's decentralized architecture, the sequence of transaction execution can be ordered and committed differently on the different Fabric components (including endorsers, orderers, and committers), which in turn introduces a delay between the calculation and commitment of the transaction, within which key collision can occur. Decentralization also leaves the network vulnerable to potential problems and attacks by intentionally or unintentionally modifying the sequence of transactions by clients.
To ensure consistency, computer systems such as databases typically use a locking mechanism. However, locking requires a centralized approach, which is unavailable in Fabric. It's also worth noting that locking can sometimes introduce a performance penalty.
To combat this, Fabric uses a versioning system of keys stored on the ledger. The aim of the versioning system is to ensure that transactions are ordered and committed into the ledger in a sequence that does not introduce inconsistencies. When a block is received on a committing peer, each transaction of the block is validated. The algorithm inspects the ReadSet for keys and their versions; if the version of each key in the ReadSet matches the version of the same key in the Worldstate, or of the preceding transactions in the same block, the transaction is considered valid. In other words, the algorithm verifies that none of the data read from the Worldstate during transaction execution has been changed.
If a transaction contains range queries, these will be validated as well. For each range query, the algorithm checks whether the result of executing the query is exactly the same as it was during chaincode execution, or if any modification has taken place.
Transactions that do not pass this validation are marked as invalid in the ledger and the changes they introduce are not projected onto the Worldstate. Note that since the ledger is immutable, the transactions stay on the ledger.
If a transaction passes the validation, the WriteSet is projected onto the Worldstate. Each key modified by the transaction is set in the Worldstate to the new value specified in the WriteSet, and the version of the key in the Worldstate is set to a version derived from the transaction. In this way, any inconsistencies such as double spending are prevented. At the same time, in situations when key collisions may occur, the chaincode design must take the behavior of MVCC into consideration. There are multiple well-known strategies for addressing key collisions and MVCC, such as splitting assets, using multiple keys, transaction queuing, and more.