tendermint: Introduce BlockGasUsed field in ResponseCheckTx and ResponseDeliverTx
Proposal to add a BlockGasUsed uint64 field into the ResponseCheckTx and ResponseDeliverTx structs in abci/types package.
The Response structs are created by the application and sent over ABCI to inform Tendermint and clients what the result of a transaction execution was. The GasUsed field is useful information when diagnosing why a transaction failed and can be useful even information even when transaction succeeds.
However, the GasUsed field is currently getting used in two different contexts in the SDK. In normal cases where transaction succeeds or exceeds the tx gas limit, the GasUsed field is set to the amount of gas consumed by the transaction.
However, in the exceptional case where the BlockGasLimit is exceeded on a transaction execution; the GasUsed field reflects the total gas consumed in the block, rather than the gas consumed in this single transaction. This is necessary since it is the only field where we can fit this important information into the response. However, it confuses the semantics of the GasUsed field since it is now being used for two different purposes depending on the internal state of the application.
This makes it hard for clients to programatically depend on the GasUsed field since its value may be representing different things based on the specific state of the application.
To avoid this problem, I propose adding a BlockGasUsed field to the Response structs. This still allows developers to return the total gas consumed in a block after a transaction gets executed, which is valuable information when the BlockGasLimit has been exceeded; while solidifying the semantics of the GasUsed field so that it is always representing the same information regardless of the transaction’s execution path.
Ref: https://github.com/cosmos/cosmos-sdk/pull/5421#discussion_r359550560
cc: @alexanderbez
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 25 (25 by maintainers)
Let’s discuss this in the meeting. I don’t think the image reflects the desired flow well (e.g. if it’s a protocol change and solution certainty is high, we nevertheless want to discuss the change in the spec repo). From what I can see
/docs/adrif change is substantial; we may want to define what substantial is or decide as we go)sorry for confusion @alexanderbez
Ohhh so the current flow is exactly what I want to do then. ADR -> spec update -> implementation. What am I missing?
Shall I work on this?
This makes sense to me 👍