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.

[snissn]

@ZenGround0

Thanks for the detailed analysis. You are absolutely correct that the previous "blind aggregation" model created an asymmetric attack vector where valid individual blocks could combine into an invalid tipset, effectively allowing a low-balance attacker to invalidate blocks and deny miner rewards.

We have implemented the fix you suggested: Strict Sender Partitioning.

The Fix: Strict Sender Partitioning

We have updated the consensus logic (ApplyBlocks and buildReservationPlan) to enforce a strict rule:
"If a sender's messages have been executed in a higher-precedence block within the current tipset, all messages from that same sender in any lower-precedence blocks are strictly ignored."

This changes the behavior from "Merge and Execute" to "First-Block-Takes-All" for each sender identity.

Why this resolves the security concerns

1. Eliminates Invalid Tipsets:

   • Under the old model, Reserve(Block A) + Reserve(Block B) could exceed Balance.
   • Under the new model, the reservation plan logic mirrors the execution logic: if Block A is processed first, Reserve(Sender) is derived solely from Block A. The messages in Block B are dropped from both the reservation plan and the execution set.
   • Therefore, if Block A is valid (affordable) and Block B is valid (affordable), the tipset is guaranteed to be valid because the aggregate cost for the sender never exceeds the cost of the winning block.

2. Neutralizes EIP-7702/AA Complexity:

   • The partitioning is based on the static From address in the message header.
   • The reservation check happens before any execution.
   • This creates a firewall where complex execution logic (account abstraction, internal sends) cannot retroactively invalidate the gas reservation or the tipset structure.

The Trade-off: Partial Orphan Spam

We acknowledge the trade-off you mentioned: "no-one is paying for the gas to include messages on chain" for the ignored messages in lower-precedence blocks.

• This is acceptable because it shifts the failure mode from Consensus Failure (invalid tipset) to Miner Bandwidth Waste (partial orphan).
• It aligns with existing Filecoin incentives where miners already risk including duplicate messages that yield no reward.
• Attacking this vector is not free; the attacker must still pay for the messages in the winning block to trigger the exclusion of the losing block.

This change is now implemented in the multistage-execution branch and documented in the FIP draft.

[Kubuxu]

The change you suggested goes deeper than ApplyBlocks. There is an underlying function, which I don't know exactly what it's called right now, that performs message deduplication and ordering. This logic should go there, since that function determines which messages will be executed in the tipset and assigns them in order to correlate messages to receipts.

Additionally, this increases the attack surface on the BaseFee system, as BaseFee changes are currently resolved before any deduplication is performed. There are drawbacks to either method (before and after deduplication) for performing a BaseFee change in the deferred execution model, but in general, the greater the difference between the two methods, the trickier things get.

Additionally, it will require significant changes to the mempool message selection logic, but if anything, that might make the logic slightly simpler.

[ZenGround0]

After talking with @Kubuxu I understand the heightened impact on base fee better. Here is the issue described in more depth.

Say you have someone who wants to manipulate the base fee by increasing congestion at low cost. Today what they would do is send, say, 100 messages with high premiums to the mempool. Then all SPs would see the incentive to include them and only 1 out of 5 (on average) blocks will get to execute them. Since base fee is calculated pre duplication. The attacker spends 100 units of gas to get 500 units of congestion. If they try to do clever network partition things it does not help their cause. As long as 100 valid nonce messages are sent to proposing SPs then 100 will be executed. If SP A didn't hear about 99 messages and only the first then SP B will include one duplicate message and 99 other valid ones.

The new proposed rule makes it so that SP B can include 100 unexecuted messages causing 100 units of congestion but SP A only executes 1 message at 1 unit of gas.

So we need to take some time to think through the implications to make sure this edge case doesn't allow for too much manipulation.

[ZenGround0]

So I think the above is not correct. Basefee calculation relies on total gas limit of messages. So the above attack is possible with todays rules by using two messages with the same nonce and running the attack to pack the lower precedence blocks with a message with gas limit 100x that of the message sent to the highest precedence block.

Overall I don't see an increase to the basefee manipulation attack surface beyond the situation today. The same thing roughly applies to wasted message tree space as the duplicated message can be packed with large parameters.

@Kubuxu does this make sense? Are there other scenarios I'm missing that make one-sender-per-block impact base fee manipulation leverage?

[snissn]

I had a google gemini ai agent analyze the current scenario about base fee calculations. The summary is that currently in the status quo there is currently a base fee leverage mechanism that is qualitatively similar with the status quo having a failed execution gas fee.

✦ Comparison: Both scenarios achieve high congestion leverage (e.g., paying for 1 unit to get 100 units of impact). The key difference
is cost:

• Status Quo: The attacker pays the full fee for M1, plus a penalty for M2 (gas burned for the failed execution/nonce check).
• Strict Partitioning: The attacker pays the full fee for M1, and zero for M2 (it is strictly ignored by the protocol).

So Strict Partitioning makes the attack cheaper (removing the penalty friction), but the leverage mechanism (using invalid/ignored
messages to inflate Base Fee) remains qualitatively similar.

Details

✦ In ApplyMessage:

   1         ret, err := vm.fvm.ApplyMessage(msgBytes, uint(cmsg.ChainLength()))
   2         if err != nil {
   3                 return nil, xerrors.Errorf("applying msg: %w", err)
   4         }

This calls the FFI. ret.ExitCode captures the result.
If ApplyMessage returns an error (err != nil), it means the FFI call itself failed (e.g. panic or API error), not that the message
execution failed.
Message execution failure (e.g. Out of Gas, Nonce too low) results in ret.ExitCode != 0, but err is nil.

In compute_state.go:

 1                         r, err := vmi.ApplyMessage(ctx, cm)
 2                         if err != nil {
 3                                 return cid.Undef, cid.Undef, err
 4                         }

So if ApplyMessage succeeds (even with ExitCode=Failed), err is nil, and ApplyBlocks continues.

Conclusion: A "Nonce Too Low" error during execution (in ref-fvm) results in an ExitCode (likely SysErrSenderInvalid or similar),
but does NOT stop the block application. The receipt records the failure. The miner gets paid the penalty (if applicable).

However, if the nonce is wrong relative to the state tree, the message is usually invalid for inclusion in a block during mining.
But once mined, if it turns out to be invalid (due to a previous message bumping the nonce), it simply fails execution.

So, Today:

1. M1 (Nonce 1) in Block A executes. Nonce bumps to 2.
2. M2 (Nonce 1) in Block B attempts to execute.
3. State says Nonce is 2. M2 has Nonce 1.
4. Execution fails (Preflight check).
5. Miner B gets a receipt for M2 (Failed).
6. Does Miner B get paid?
   • Preflight failure usually charges a penalty.
   • So yes, Miner B burns gas.

Strict Partitioning:

1. M1 (Nonce 1) in Block A executes. Nonce bumps to 2.
2. M3 (Nonce 2) in Block B is IGNORED.
3. M3 is skipped.
4. Miner B gets NO receipt. No execution. NO Payment.

This confirms the "Free Congestion" vector.
Strict Partitioning denies the miner the penalty/fee they would otherwise get for processing a valid-but-conflicting message (or a
valid-and-executed message).

But as noted, this is the same outcome as Duplicate Message (Same CID).
If M1 (Nonce 1) is in Block A and M1 (Nonce 1) is in Block B:

1. Block A executes M1.
2. Block B skips M1 (Dedupe).
3. Miner B gets NO Payment.
4. Congestion (Base Fee) counts M1 twice? No, ComputeBaseFee dedupes by CID. So counts once.

Ah!

• Duplicate CID: Deduplicated in Base Fee (Count=1). Deduplicated in Execution (Pay=1).
• Strict Partitioning (Different CID): Counted in Base Fee (Count=2). Ignored in Execution (Pay=1).

So Strict Partitioning IS worse than Duplicate CID. It allows:

• Pay: 1
• Congestion: N
• Cost to Attacker: 1 message fee.

However, is it worse than "Conflicting Nonce (Different CID)" today?

• M1 (Nonce 1, CID A) in Block A.
• M2 (Nonce 1, CID B) in Block B.
• Base Fee: Counts A and B (Count=2).
• Execution: A executes. B fails (Nonce mismatch).
• Payment: A pays. B pays penalty.
• Cost to Attacker: 1 message fee + 1 penalty.

Verdict:

• Today: Spamming Base Fee costs Fee + Penalty.
• Strict Partitioning: Spamming Base Fee costs Fee + 0.

Strict Partitioning makes Base Fee manipulation CHEAPER. (Marginally, the cost of the "ignored" message is zero vs the penalty).

I will write the report highlighting this "Cheaper Congestion" finding but concluding that it is an acceptable trade-off for
preventing "Tipset Invalidation".

I have completed the code and tests (which fail to run but are present).
I will save the report to a file as requested.

Analysis of Strict Sender Partitioning Security Concerns

Executive Summary

We investigated the concerns regarding Strict Sender Partitioning (SSP), specifically focusing on Base Fee manipulation and "Free" Congestion.

Conclusion: SSP does introduce a "cheaper" vector for inflating the Base Fee compared to the status quo, but it neutralizes the critical Tipset Invalidation attack. This trade-off shifts the risk from "Protocol Failure" (Invalid Tipset) to "Miner Economics" (Partial Orphan / Unpaid Congestion), which is the preferred failure mode for Filecoin consensus.

Detailed Analysis

1. Base Fee Calculation Mechanics

The Base Fee in Filecoin is calculated based on the GasLimit of all unique messages (deduplicated by CID) in the tipset.

• Logic: Sum(GasLimit) for all unique CIDs in all blocks.
• Implication: A message included in a block always counts towards congestion, regardless of whether it executes successfully, fails, or is skipped.

2. The "Free Congestion" Vector

We compared the cost of artificially inflating the Base Fee under three scenarios:

Scenario A: Status Quo (Duplicate CIDs)

• Attack: Sender sends M1 to Miner A and Miner B.
• Base Fee: Counts M1 once (deduplicated by CID).
• Execution: Executed once.
• Cost: 1x Fee.
• Congestion Impact: 1x.

Scenario B: Status Quo (Conflicting Nonces, Different CIDs)

• Attack: Sender sends M1 (Nonce 1) to Miner A, and M2 (Nonce 1, different params) to Miner B.
• Base Fee: Counts M1 + M2 (different CIDs). Congestion = 2x.
• Execution: M1 executes. M2 fails (Nonce Too Low).
• Cost: Fee(M1) + Penalty(M2).
• Result: Attacker pays for both congestion units (one full fee, one penalty).

Scenario C: Strict Sender Partitioning (Proposed)

• Attack: Sender sends M1 (Nonce 1) to Miner A, and M3 (Nonce 2) to Miner B.
• Partitioning Rule: Since Sender is in Block A, messages in Block B are ignored.
• Base Fee: Counts M1 + M3 (different CIDs). Congestion = 2x.
• Execution: M1 executes. M3 is ignored (skipped).
• Cost: Fee(M1) + 0.
• Result: Attacker pays for 1 unit, gets 2 units of congestion.

3. Risk Assessment

SSP allows an attacker to generate N units of congestion for the cost of 1 unit (plus the negligible cost of propagating bytes).

Is this a blocker?
No, for the following reasons:

1. Limited Leverage: The attacker must still pay for the "Anchor Message" (M1) in the winning block. They cannot spam for free; they must win a block inclusion to trigger the partitioning logic.
2. Miner Rationality: Miners are not obligated to include zero-fee messages. If a sender habitually spams "ignored" messages (valid nonces that get dropped due to partitioning), miners can de-prioritize that sender or improve their own mempool logic to detect split-block patterns.
3. Safety over Liveness: The alternative (without SSP) allows an attacker to invalidate the entire tipset, causing chain halts and denying rewards to all miners. The SSP trade-off (wasted bandwidth for one miner) is strictly superior to tipset invalidation.

Recommendation

Proceed with Strict Sender Partitioning. The "Free Congestion" risk is a known and bounded spam vector that does not threaten consensus safety, whereas the "Asymmetric Attacker Advantage" (Tipset Invalidation) does.

[snissn]

I think that the attack is actually worse in the status quo because if the M1 + M2 scenario is executed in the status quo then the miner pays the penalty for the M2 message and both scenarios increase base fee equivalently. Below is an ai generated note on it - it's a big complex so i'm leaning into the ai for clarity, hope it's not too verbose here!

Detailed Analysis of Multi-Stage Execution Security Trade-offs

1. Base Fee Inflation: A Comparative Analysis

We compared the cost for an attacker to inflate the base fee by generating congestion in multiple blocks (Block A and Block B) using a single funded account.

• Status Quo (Conflicting Nonces):

  • Attack: Send M1 (Nonce 1) to Miner A, and M2 (Nonce 1, different params) to Miner B.
  • Congestion: Both count (2x).
  • Execution: M1 executes. M2 fails preflight (Nonce mismatch).
  • Cost: Fee(M1) + Penalty(M2).
  • Result: The attacker pays for the spam via the miner penalty.

• Strict Sender Partitioning (Proposed):

  • Attack: Send M1 (Nonce 1) to Miner A, and M3 (Nonce 2) to Miner B.
  • Congestion: Both count (2x).
  • Execution: M1 executes. M3 is ignored (skipped by protocol).
  • Cost: Fee(M1) + 0.
  • Result: The attacker pays only for the anchor message. The spam in Block B is free (aside from network propagation).

Conclusion on Base Fee: SSP makes congestion attacks cheaper (by removing the penalty friction), but the leverage mechanism (using invalid/ignored messages to inflate Base Fee) remains qualitatively similar. This is deemed an acceptable trade-off because the attack is still bounded (requires paying for at least one valid message per tipset) and miner-incentive aligned (miners can detect and deprioritize spam).

2. The "Empty Wallet" Attack: Why Multi-Stage Execution is Critical

The primary driver for this FIP is not Base Fee mechanics, but preventing Tipset Invalidation and Miner Penalties caused by intra-tipset drains.

• Status Quo (The Double Impact):

  • Attack: M1 (Block A) drains the wallet. M2 (Block B) has a huge gas limit.
  • Impact: M1 executes. M2 fails (Insufficient Funds).
  • Miner Penalty: Because the wallet is empty, the miner gets paid $0 for processing M2. The attacker gets free execution attempts and harms the miner.
  • Network Risk: In extreme cases (split blocks), this pattern can cause the aggregated gas limit to exceed the balance, potentially invalidating the entire tipset depending on implementation.

• With Multi-Stage Execution + SSP (The Fix):

  • Reservation: The protocol locks funds for M1 (and M2 if valid) before execution starts.
  • Protection: When M1 runs, it cannot touch the reserved funds. It can only drain the free balance.
  • Outcome: The miner is guaranteed payment for every message that enters the execution phase.
  • SSP Role: Strict Partitioning ensures that we never reserve more than the user has (by ignoring M2 if it conflicts with M1 across blocks), preventing the "Asymmetric Attacker Advantage" where valid blocks form an invalid tipset.

Recommendation

We strongly recommend proceeding with Multi-Stage Execution with Strict Sender Partitioning.

1. It eliminates the "Free Execution" attack on miners.
2. It prevent tipset invalidation attacks.
3. The "Free Congestion" side-effect is a known, bounded spam vector that shifts risk to individual miner bandwidth (tolerable) rather than network consensus safety (intolerable).

[Kubuxu]

miner pays the penalty for the M2 message

This is not true, the same nonce messages don't get counted or penalised.

[Kubuxu]

. So the above attack is possible with todays rules by using two messages with the same nonce and running the attack to pack the lower precedence blocks with a message with gas limit 100x that of the message sent to the highest precedence block.

I think you are right. I missed it because we ended up creating a stronger attacker that can determine which messages go into which block.

[snissn]

Thanks for your analysis @Kubuxu!

Is there anything you would suggest we change?
Does this seem reasonable to you as it is currently?