How should we treat non-deterministic transactions/chaincodes? #591
Comments
@corecode this where you are referring? https://github.com/hyperledger/fabric/blob/master/consensus/obcpbft/obc-sieve.go#L730 Seems like to test this we'd need a non-deterministic chaincode for starters so that we could observe the behavior. |
@christo4ferris you may already be aware of this, but there was discussion of adding a non-deterministic example in PR #1388 |
@ghaskins thanks. @binhn I'm going through old issues to determine whether they are still relevant and where needed, adding information that someone might need to take on the task of resolving the issue. If you are asserting that because some are exploring a refactor of the architecture for consensus in #1631 that this is no longer relevant issue, then we can probably close this, especially since there are non-deterministic chaincode examples being added. Maybe we just close this when #1388 is merged. The main point, though is that we have an abundance of rather old and dusty issues, many of which are insufficient to reproduce, or may no longer be relevant, and which are an impediment for engaging developers that haven't got the benefit of the context that someone such as yourself have. |
This is a policy issue, not a bug report. |
@christo4ferris I agreed and close this issue. |
When Sieve detects a non-deterministic transaction, how should this fact be communicated to the rest of the fabric?
The fact that a transaction executed non-deterministically should be persisted somehow to allow auditing of this event. Right now Sieve only logs a message.
We probably should also mark the whole chaincode as non-deterministic and stop executing any invoke of that chaincode. This addresses a potential DoS, where a chaincode executes non-deterministically and forces the batch of transactions to be rolled back.
The text was updated successfully, but these errors were encountered: