Update transaction format for Arbitrum

[leszko]

Is your feature request related to a problem? Please describe.
Arbitrum treats the gas price differently than Ethereum. It uses gasPrice as the maximum gas price that a user may pay. Also Aribtrum probably does not accept the post-london upgrade transaction format.

Describe the solution you'd like
We need address the following points:

• Gas Price Monitor (oracle) does not make sense anymore
• Transaction Replacement does not make sense anymore
• All places where we use baseFee do not make sense anymore (there is no baseFee in Arbitrum)
• Setting max gas price is different

[yondonfu]

Can we just handle Arbitrum transactions the same way that we would handle any pre-London chain by defaulting to the legacy tx format similar to what the contract binding base code does i.e. check if the latest block header of the chain specifies a BaseFee and if not assume that the chain does not support the dynamic tx format and use the legacy tx format instead?

Gas Price Monitor (oracle) does not make sense anymore

I don't think this is true. The GasPriceMonitor is still used to return a cached gas price representing the expected current gas price of the chain in pm.Recipient in order to estimate the current transaction cost for redeeming a ticket.

Transaction Replacement does not make sense anymore

I don't think this is necessarily true. We could just adjust the GasPrice field of the replacement tx using the legacy format instead of the GasFeeCap/GasTipCap fields of the replacement using the dynamic fee format. It is worth noting that there is less of a need for replacement txs on Arbitrum right now given that txs should be confirmed almost instantaneously after being received, however, given the possibility of slower confirmations in the event of congestion I think it is worthwhile keeping this mechanism around for now.

All places where we use baseFee do not make sense anymore (there is no baseFee in Arbitrum)

It is also used here

go-livepeer/eth/backend.go

Line 132 in 970d0aa

if head.BaseFee == nil {

.

Setting max gas price is different

I believe the GasPrice field of a tx will always be the max that a user will pay per unit of gas consumed on Arbitrum and if that is the case we could just set the GasPrice field to the -maxGasPrice specified by a user and the user will always pay that price or less (will be less if the current gas price on Arbitrum is lower than the specified gas price). So, this could actually simplify things a bit!

[leszko]

Can we just handle Arbitrum transactions the same way that we would handle any pre-London chain by defaulting to the legacy tx format similar to what the contract binding base code does i.e. check if the latest block header of the chain specifies a BaseFee and if not assume that the chain does not support the dynamic tx format and use the legacy tx format instead?

Yes, I think you're right, I made the changes in the max gas price PR: #2171. PTAL

Gas Price Monitor (oracle) does not make sense anymore

I don't think this is true. The GasPriceMonitor is still used to return a cached gas price representing the expected current gas price of the chain in pm.Recipient in order to estimate the current transaction cost for redeeming a ticket.

Right, I didn't touch Gas Price Monitor.

Transaction Replacement does not make sense anymore

I don't think this is necessarily true. We could just adjust the GasPrice field of the replacement tx using the legacy format instead of the GasFeeCap/GasTipCap fields of the replacement using the dynamic fee format. It is worth noting that there is less of a need for replacement txs on Arbitrum right now given that txs should be confirmed almost instantaneously after being received, however, given the possibility of slower confirmations in the event of congestion I think it is worthwhile keeping this mechanism around for now.

Yes, you may be right. I kept the replacement logic. However, note that I never encountered the slow configuration. So the transaction was either accepted or rejected, never pending in Arbitrum.

All places where we use baseFee do not make sense anymore (there is no baseFee in Arbitrum)

It is also used here

go-livepeer/eth/backend.go

Line 132 in 970d0aa

if head.BaseFee == nil {

We don't need to change it for now since this logic is executed only in the case of dynamic fee tx. So, it won't be ever executed in Aribitrum.