ABCI applications must implement deterministic finite-state machines to ensure secure replication by the CometBFT consensus engine. Block execution over the Consensus Connection must be strictly deterministic: given the same ordered set of requests, all nodes must compute identical responses for BeginBlock, DeliverTx, EndBlock, and Commit. This is crucial because these responses are included in the header of the next block, either as a Merkle root or directly, requiring all nodes to agree on the exact state.
To maintain determinism, application state changes should only be triggered by block execution events and not through any external inputs.
However, non-determinism can happen in the ExecutionPayload message handler. During transaction execution, the handler makes a call to a Geth node, which introduces variability due to infrastructure and network conditions.
This could result in nodes returning different values, preventing them from producing the same block, and leading to chain halts if some nodes experience connection issues.
Solution recommendation
A possible solution would be to move all the logic involving calls to external nodes outside of the DeliverTx function. For example it could be done when accepting the proposed block.
Description and context
ABCI applications must implement deterministic finite-state machines to ensure secure replication by the CometBFT consensus engine. Block execution over the Consensus Connection must be strictly deterministic: given the same ordered set of requests, all nodes must compute identical responses for BeginBlock, DeliverTx, EndBlock, and Commit. This is crucial because these responses are included in the header of the next block, either as a Merkle root or directly, requiring all nodes to agree on the exact state.
To maintain determinism, application state changes should only be triggered by block execution events and not through any external inputs.
However, non-determinism can happen in the ExecutionPayload message handler. During transaction execution, the handler makes a call to a Geth node, which introduces variability due to infrastructure and network conditions.
This could result in nodes returning different values, preventing them from producing the same block, and leading to chain halts if some nodes experience connection issues.
Solution recommendation
A possible solution would be to move all the logic involving calls to external nodes outside of the DeliverTx function. For example it could be done when accepting the proposed block.