Doesn’t seem new to me, Tendermint makes use of deferred execution from day 1. For exactly the reason of being able to pipeline block execution during the voting phase. There’s been a lot of discussion from the Tendermint / Cosmos community on this front and the ramifications (i.e. downsides) of deferred execution:
opened 01:57PM - 17 Jun 20 UTC
closed 12:13AM - 26 Aug 23 UTC
C:abci
C:consensus
S:proposal
stale
This is a draft (will update shortly):
## Summary
Consider enabling immedi… ate execution (either by default, or, somehow make it possible to chose or overwrite the current behaviour for tendermint users).
## Problem Definition
Currently, tendermint executes transactions one "block height off". Meaning that In the current execution model, blocks are executed against the app only after they are committed.
Full block verification (incl. state) always needs access to transactions of the previous block:
state(1) = InitialState
state(h+1) <- Execute(state(h), ABCIApp, block(h))
While that seem to be fine for most use-cases there are a few draw backs here:
1) First of all it's confusing *why* transactions do not simply get executed in the same block (this is mostly a documentation concern). There is no clear documentation why this decision was made in tendermint. There are a few issues where this was discussed but these discussions are difficult to find and they don't explain the decision well enough.
2) Dealing with one-offs is a classical source of bugs. That is a concern for app or rather SDK module developers. E.g., a dev who was instrumental in designing and implementing the PoS module in the SDK confirmed that "it actually being quite annoying to deal with the +1 offset". This is mostly about developer usability. It also (unnecessarily?) complicates the app centric point of view (ref: https://github.com/tendermint/tendermint/issues/2483).
3) In the context of IBC, for some zones it might be annoying to essentially "wait" an extra block for the state to actually be updated. Not sure if this is a real issue actually. But I can imagine for some projects that waiting a few extra seconds is at least non-optimal.
4) For certain fee models, deferred execution is a burden, or makes them hacky/impossible to implement: https://github.com/lazyledger/lazyledger-core/issues/3#issuecomment-644175000
and https://github.com/lazyledger/lazyledger-core/issues/3#issuecomment-644832152
## Proposal
First, the reasoning behind the current execution model needs to be documented (my understanding is that it is an optimization to reduce latency; s.t. validators can reach consensus on tx ordering quickly and then do the state transitions leisurely while timeout_commit didn't kick in yet). This should be done independent of the proposal to execute earlier.
TODO
### Related:
- longish discussion over at LazyLedger: https://github.com/lazyledger/lazyledger-core/issues/3
- https://github.com/tendermint/tendermint/issues/2384
- app centric interpretation of concepts: https://github.com/tendermint/tendermint/issues/2483
- invalid/spam tx in blocks (sdk): https://github.com/cosmos/cosmos-sdk/issues/4695
- also a bit related (block pre-processing phase would happen before the block gets proposed in the immediate exec I guess): https://github.com/tendermint/tendermint/issues/2639
- kinda related discussions on CheckTx: https://github.com/tendermint/tendermint/issues/2384#issuecomment-423359994
____
#### For Admin Use
- [ ] Not duplicate issue
- [ ] Appropriate labels applied
- [ ] Appropriate contributors tagged
- [ ] Contributor assigned/self-assigned
https://github.com/lazyledger/lazyledger-core/issues/3#issuecomment-644175000
Notably, deferred execution prevents gas refunds as they exist on Ethereum today .
On the topic of increasing the block gas limit, block validation rate must be much higher than production rate not for Nakamoto Consensus, but so that users can full sync. Therefore, changing the consensus protocol does not allow us to decrease this multiplier .