Inconsistency in what counts as "gas exhaustion" in Call commands vs non-Call commands.

[lyulka]

Problem

In the canonical implementation of Transition (V1), namely pchain-runtime v0.4, there is an inconsistency in what counts as "gas exhaustion" in Call commands vs non-Call commands.

In particular, Call commands terminate because of Gas Exhaustion when gas_used > gas_limit, while non-Call commands terminate because of Gas Exhaustion if gas_used >= gas_limit. Note the subtle difference in the inequality that sits between gas_used and gas_limit in the two cases.

This becomes a problem for the protocol because pchain-runtime v0.4 has been deployed as part of Fullnode v0.4, and have therefore been used to commit blocks in the Mainnet blockchain.

Background

This snippet in the source code computes remaining_gas: u64 after the execution of a contract. But it does not distinguish between the two cases:

1. The execution of the contract used exactly gas_limit.
2. The execution of the contract used more than gas_limit.

In both cases, the Runtime reports that gas is exhausted, even though, intuitively, the first case should be admissible (the command execution should have been reported as OK in its command receipt, instead of GasExhausted.

Proposed solution

Changes to pchain-runtime

Instead of converting the instance of MeteringPoints returned by get_remaining_points into remaining_gas: u64 as in the code snippet, we should instead match the variants of MeteringPoints with the variants of the return value of of the call_method function directly, like so:

match wasmer_middlewares::metering::get_remaining_points(&self.0) {
    MeteringPoints::Exhausted => Err(GasExhaustion),
    MeteringPoints::Remaining(points) => Ok(points),
}

This will make what counts as gas exhaustion in Call command executions consistent with what counts as gas exhaustion in non-Call command executions. Namely, all commands terminate with a GasExhausted status if-and-only-if gas_used > gas_limit.

Changes to the ParallelChain Protocol

We plan to fix this issue in ParallelChain protocol v0.7.