Add draft FIP for tipset gas reservations

[snissn]

This FIP introduces tipset-scope gas reservations as a consensus rule for Filecoin to eliminate miner exposure to underfunded gas charges within a single tipset while preserving existing receipts and gas accounting. For each tipset, nodes derive the canonical set of explicit messages and construct a per-sender reservation plan equal to the sum, over the tipset, of each message’s gas_limit * gas_fee_cap. The execution engine maintains an internal reservation session ledger keyed by actor identifier; when a session is open, each sender’s free balance is defined as on-chain balance minus the remaining reserved amount recorded in this ledger.

#1210

[snissn]

@ZenGround0

[snissn]

relevant PRs:

filecoin-project/ref-fvm#2236
filecoin-project/lotus#13427
filecoin-project/filecoin-ffi#554

[ZenGround0]

I spent some time talking to @Kubuxu about this today and he raised a problem that I think means we have to rethink this design at least a little bit and maybe significantly.

The concrete problem is that reservations cannot be correctly computed on the block level with current tipset execution semantics.

I missed this because I was missing a concrete feature of how message selection works in a tipset. I'll cover how this works and can be used with a reservation block validation rule to partition the network.

The key message selection property is as follows. Lets say there are two blocks A and B. These blocks contain messages from a sender S. S submits m1 and m2 to the first block and m1' m2 m3 to the second block. The nonce for m1 and m1' is 1, the nonce for m2 is 2 the nonce for m3 is 3. In this case assuming the first block has execution precedence in the tipset (i.e. smaller winning ticket on the block header) then the final tipset will include the state computation of m1, m2 and m3. This is a mixture of messages from the two different blocks.

Now assume S has total value X in their account at the start of the next tipset. S submits message m1 and message m2 to the SP mining block A. I'll denote the reservation needed for each message as r(m). r(m1) + r(m2) < X so block A passes the reservation requirements as determined by the SP mining block A and the block is successfully proposed to the rest of the network. At the same time sender S proposes messages m1' with r(m1') < r(m1) and message m2 and m3. Again r(m1') + r(m2) + r(m3) < X, so the SP mining block B passes reservation requirements. However S sets the gas limit values such that r(m1) + r(m2) + r(m3) > X. So in the case where block A has a smaller ticket than block B and the final tipset message set for S = {m1, m2, m3} there is insufficient reservation to pay for the gas limit. This puts us back into the scenario where we need a miner penalty.

So as it stands today gas reservation is fundamentally a tipset level issue. We would be in a very bad place if we left gas reservation as a tipset validation rule because proposing SPs have no way of knowing if their block will be invalidated in the tipset. There is an assymetric advantage to attackers with tiny amounts of funds allowing them to force SPs out of winning block rewards and critically halt chain progress by propagating messages which instigate forks.

One idea I am hopeful we can use is to simply invalidate all messages from senders that have already had their messages executed in a higher precedence block in a tipset. This extends today's functionality of ignoring duplicate nonce message in the lower precedence blocks. Now we would not execute any messages from a previously executed sender in a higher precedence block. Nonces would not be updated and there would be no reflection of these messages in the state tree.

One obvious issue with this is that now in a malicious scenario no-one is paying for the gas to include messages on chain. This becomes a spam vector. However perhaps it is acceptable to bear this cost especially given the current situation with node state management where messages are pruned from datastore ~ every week on splitstore compaction interval.