Block gas consumption limits in a world of tipsets

[anorth]

With the block state root & receipts identifying execution of the messages in the parent tipset, rather than the block's own, how is the execution cost of a block to be limited?

Previously (and in other e=1 chains) each block has a gas limit, which is an upper bound on the gas consumed by the execution of the messages in a block. For us, executing the messages in a single block is a flawed simulation of how they will execute when combined into a tipset (since prior state will be different). If we maintained a similar block gas limit, enforcing it would be the only reason a node must execute the messages in a block outside of the combined tipset message list, essentially doubling validation costs.

Please declare how execution cost is to be limited, and in particular whether it will be some scheme that requires validators to actually execute all a block's messages independently of their inclusion in a tipset.

Supersedes #480. See also #470, 481, #522.

[anorth]

One alternative is limit the sum of each message's declared gas limit, which cannot underestimate the actual gas consumption. This is quick and easy to validate. It would cause the limit on actual gas consumption to be strictly less than stated, and the "gap" between messages declared limits and actual gas consumption would represent an unused capacity in the network.

Block producers would be incentivised to select messages that actually consume most of their declared limit, which they could approximate (but never know for sure) by executing the messages before including them in a block. This cost and complexity would be borne only by block producers, not all validators, and only be relevant when blocks are "full". It's strictly a profit optimization.

There's a potential attack against naive block producers that don't attempt optimization, by posting a message with a high gas price and limit, but low actual consumption. The attack consumes chain capacity, possibly robbing others of the opportunity to include a message. I believe it's reasonably mitigated by block producers not being naive.

[anorth]

@jbenet said

I need to think through this (this may be wrong), but my first reaction is this:

• messages have gas limits. the gas limits can add up to more

• miners should expect that (if they put messages w/ a certain gas limit in a block) the block can indeed take that long (ie should not take advantage of the fact that many executions will be much shorter)

• add up the gas limits to see what the block might take when it gets executed as part of a tipset

• we can reduce the above to a sane per-block gas limit (based on safety_margin (total gas limit for an epoch) / (EC.E_LEADERS 1.5) . where safey_margin is ~1/2 or 1/3, and the `1.5 is for cases where there are a lot of leaders elected.

• this gives us a constant gas limit for any block.

• need to look at the concrete amounts of a typical block before i can say more -- i anticipate the crypto ops to be the worst by far)

• (meta level, this is also a market question. parties wont accept blocks above a certain max limit because otherwise their tipset won't make it)