Do not send batch poster reports in fee token based chains

[gvladika]

This is a short term solution for Anytrust Orbit chains that use custom fee token. Due to missing ETH<->fee token conversion rates, batch poster reports are not being sent in fee token based chains. Long term solution is researched which will involve some kind of oracle.

[shotaronowhere]

If the goal is for the pricePerUnit on the L3 to be zero, then this looks like one of the first steps.

arbos will debt the sequencer an amount of weiSpent = 0 , since the l1BaseFeeWei is reported as zero in this PR, this LGTM.

There are additional steps however to ensure pricePerUnit on the L3 to be zero

1. The perUnitReward is initialized at 10. The arb owner should set this value to zero, can be accomplished in the orbit deployment script.
2. The rollup init message sets the initial pricePerUnit to the l1BaseFeeEstimate. You can add a nativeToken aware condition here to instead set it to zero.
3. I don't completely understand why the retryable submission fee is not paid for erc20s. I thought this is a problem with the NodeInterface calculation of the submission fee, but if PricePerUnit = 0, then the submission fee is zero. Something to look into further.

---

Seems that there's much more complexity than meets the surface for a simple patch.

I think using an initial fixed conversion rate of feeToken / eth and reporting batch spending in terms of the feeToken is preferable as a temporary measure until there is a more robust feeToken pricing model.

Perhaps the arb owner can update the exchange rate.

[yahgwai]

Do we support custom fee tokens on L2 Anytrust chains? If so, fetching the native token below will be quite expensive to do on every batch post. In that case we should consider having an immutable var on this contract so that we dont have to do a .call or storage lookup.

[gvladika]

Switched to using immutable bool - 4c994f6

[yahgwai]

If the goal is for the pricePerUnit on the L3 to be zero, then this looks like one of the first steps.

arbos will debt the sequencer an amount of weiSpent = 0 , since the l1BaseFeeWei is reported as zero in this PR, this LGTM.

There are additional steps however to ensure pricePerUnit on the L3 to be zero

1. The perUnitReward is initialized at 10. The arb owner should set this value to zero, can be accomplished in the orbit deployment script.
2. The rollup init message sets the initial pricePerUnit to the l1BaseFeeEstimate. You can add a nativeToken aware condition here to instead set it to zero.
3. I don't completely understand why the retryable submission fee is not paid for erc20s. I thought this is a problem with the NodeInterface calculation of the submission fee, but if PricePerUnit = 0, then the submission fee is zero. Something to look into further.

Seems that there's much more complexity than meets the surface for a simple patch.

I think using an initial fixed conversion rate of feeToken / eth and reporting batch spending in terms of the feeToken is preferable as a temporary measure until there is a more robust feeToken pricing model.

Perhaps the arb owner can update the exchange rate.

I believe custom fee tokens only work with anytrust, so in most cases no batch spending report will be processed at all. But in the case that not all the DAS members sign the batch the sequencer can fall back to posting full data, and triggering this code. In that case we need to think more about the consequences in the l1pricing algo, as you're pointing out above. I believe anytrust sets a bunch of these parameters already, but I could be wrong about that.

[gvladika]

If the goal is for the pricePerUnit on the L3 to be zero, then this looks like one of the first steps.
arbos will debt the sequencer an amount of weiSpent = 0 , since the l1BaseFeeWei is reported as zero in this PR, this LGTM.
There are additional steps however to ensure pricePerUnit on the L3 to be zero

1. The perUnitReward is initialized at 10. The arb owner should set this value to zero, can be accomplished in the orbit deployment script.
2. The rollup init message sets the initial pricePerUnit to the l1BaseFeeEstimate. You can add a nativeToken aware condition here to instead set it to zero.
3. I don't completely understand why the retryable submission fee is not paid for erc20s. I thought this is a problem with the NodeInterface calculation of the submission fee, but if PricePerUnit = 0, then the submission fee is zero. Something to look into further.

Seems that there's much more complexity than meets the surface for a simple patch.
I think using an initial fixed conversion rate of feeToken / eth and reporting batch spending in terms of the feeToken is preferable as a temporary measure until there is a more robust feeToken pricing model.
Perhaps the arb owner can update the exchange rate.

I believe custom fee tokens only work with anytrust, so in most cases no batch spending report will be processed at all. But in the case that not all the DAS members sign the batch the sequencer can fall back to posting full data, and triggering this code. In that case we need to think more about the consequences in the l1pricing algo, as you're pointing out above. I believe anytrust sets a bunch of these parameters already, but I could be wrong about that.

Yep custom fee token is only supported with Anytrust. Though batch spending reports will still be generated as part of DA certs postings, right? It's tricky to check if all the pricing params which @shotaronowhere mentioned are correctly set as most of them are not exposed. I'll try to figure out a way

[gvladika]

If the goal is for the pricePerUnit on the L3 to be zero, then this looks like one of the first steps.

arbos will debt the sequencer an amount of weiSpent = 0 , since the l1BaseFeeWei is reported as zero in this PR, this LGTM.

There are additional steps however to ensure pricePerUnit on the L3 to be zero

1. The perUnitReward is initialized at 10. The arb owner should set this value to zero, can be accomplished in the orbit deployment script.
2. The rollup init message sets the initial pricePerUnit to the l1BaseFeeEstimate. You can add a nativeToken aware condition here to instead set it to zero.
3. I don't completely understand why the retryable submission fee is not paid for erc20s. I thought this is a problem with the NodeInterface calculation of the submission fee, but if PricePerUnit = 0, then the submission fee is zero. Something to look into further.

Seems that there's much more complexity than meets the surface for a simple patch.

I think using an initial fixed conversion rate of feeToken / eth and reporting batch spending in terms of the feeToken is preferable as a temporary measure until there is a more robust feeToken pricing model.

Perhaps the arb owner can update the exchange rate.

Very good points, I'll be checking further 1) and 2).
Regarding 3), my understanding is that actual submission calculation is done here . It takes as input tx.L1BaseFee which is parsed out from MessageDelivered event here . That's why we report 0 as basefee in MessageDelivered.

[gvladika]

If the goal is for the pricePerUnit on the L3 to be zero, then this looks like one of the first steps.
arbos will debt the sequencer an amount of weiSpent = 0 , since the l1BaseFeeWei is reported as zero in this PR, this LGTM.
There are additional steps however to ensure pricePerUnit on the L3 to be zero

1. The perUnitReward is initialized at 10. The arb owner should set this value to zero, can be accomplished in the orbit deployment script.
2. The rollup init message sets the initial pricePerUnit to the l1BaseFeeEstimate. You can add a nativeToken aware condition here to instead set it to zero.
3. I don't completely understand why the retryable submission fee is not paid for erc20s. I thought this is a problem with the NodeInterface calculation of the submission fee, but if PricePerUnit = 0, then the submission fee is zero. Something to look into further.

Seems that there's much more complexity than meets the surface for a simple patch.
I think using an initial fixed conversion rate of feeToken / eth and reporting batch spending in terms of the feeToken is preferable as a temporary measure until there is a more robust feeToken pricing model.
Perhaps the arb owner can update the exchange rate.

I believe custom fee tokens only work with anytrust, so in most cases no batch spending report will be processed at all. But in the case that not all the DAS members sign the batch the sequencer can fall back to posting full data, and triggering this code. In that case we need to think more about the consequences in the l1pricing algo, as you're pointing out above. I believe anytrust sets a bunch of these parameters already, but I could be wrong about that.

Yep custom fee token is only supported with Anytrust. Though batch spending reports will still be generated as part of DA certs postings, right? It's tricky to check if all the pricing params which @shotaronowhere mentioned are correctly set as most of them are not exposed. I'll try to figure out a way

Checked the recent custom fee token based chain deployment. Pricing params had default values (pricePerUnit = L2 basefee + L1 basefee estimate, pricePerUnit = 10) and were later updated by chain owner. I've updated pricePerUnit calculation in initMsg. And pricePerUnit has to be set by precompile call from owner, we should document that and let the teams know

[shotaronowhere]

LGTM

I'd be interested in running some e2e tests, but the contract changes look like they achieve the desired goal.

And pricePerUnit has to be set by precompile call from owner, we should document that and let the teams know

You mean the rewardPerUnit right?

---

Another param teams should be aware of is the minL2BaseFee. On nova this is set to 0.01 Gwei and fees are denominated in eth. Nitro initializes the minBaseFee to 0.1 Gwei. It's plausible an anytrust L3 is deployed with a fee token with much different value order of magnitude (wbtc, usdc). Without correspondingly modifying the minBaseFee, the minimum fees will be similarly orders of magnitude different than when deploying a chain with eth as the fee token. I'm not sure setting the minimum basefee too low (stable coin fee token) is a big problem since validator hardware is a fixed cost. Setting the minimum basefee too high (wbtc) would however decrease chain usage. In the wbtc example, with default minBaseFee params, L3 anytrust chain fees would be similar to L2 rollup fees (~10 cents for a simple transfer).

[gvladika]

LGTM

I'd be interested in running some e2e tests, but the contract changes look like they achieve the desired goal.

And pricePerUnit has to be set by precompile call from owner, we should document that and let the teams know

You mean the rewardPerUnit right?

Another param teams should be aware of is the minL2BaseFee. On nova this is set to 0.01 Gwei and fees are denominated in eth. Nitro initializes the minBaseFee to 0.1 Gwei. It's plausible an anytrust L3 is deployed with a fee token with much different value order of magnitude (wbtc, usdc). Without correspondingly modifying the minBaseFee, the minimum fees will be similarly orders of magnitude different than when deploying a chain with eth as the fee token. I'm not sure setting the minimum basefee too low (stable coin fee token) is a big problem since validator hardware is a fixed cost. Setting the minimum basefee too high (wbtc) would however decrease chain usage. In the wbtc example, with default minBaseFee params, L3 anytrust chain fees would be similar to L2 rollup fees (~10 cents for a simple transfer).

Yep I meant rewardPerUnit can be set by arb owner. But after some discussion with Lee conclusion was that even simpler solution is to not send reports at all if chain is using fee token. This means pricePerUnit will be set to 0 by initMsg and won't be updated afterwards. In that case it's not necessary to update rewardPerUnit as pricing code which uses it will never be triggered.

Regarding minL2BaseFee, agree that teams need to set it accordingly to the value of the fee token. It can always be set by SetMinimumL2BaseFee call and I think our deployment UI provides an option to customize it.

[gzeoneth]

LGTM but do not merge yet