What happens is that the transaction is simulated on a peer that didn't get the latest block of the blockchain and thus the version of the key that was used in the simulation was 2799, while the latest version of that key in the blockchain was 2800 (because of a previous transaction that its corresponding block didn't get into the ledger of the peer on time). Notice that the ledger invalidates the transaction and considers it as an invalid because of MVCC (multi-version concurrency control) conflicts.
Lower the latency of the batch creation of the block in configtx.yaml which would result in the orderer cutting blocks more frequently and thus the pees would be updated faster (Note that this will decrease throughput) Use the event hub to know when the transaction has been committed before sending a new transaction that needs keys that a previous transaction modified. Redesign the chaincode so that you will have less dependencies between the keys.