Custom Gas Token: Catch-all Discussion + Q&A

[tynes]

This is meant to be an open discussion board for OP Stack Custom Gas Token.

• Spec: feat: custom gas token #111
• Implementation: feat: custom gas token optimism#10143
• Setup Guide

Custom gas token has been released at op-contracts/v2.0.0-beta.2

Open Source Bridge UI

The Custom Gas Token feature is a Beta feature of the MIT licensed OP Stack. While it has received initial review from core contributors, it is still undergoing testing, and may have bugs or other issues.

FAQ

How to Deposit on a Custom Gas Token Chain

There is a new function added to the OptimismPortal called depositERC20Transaction. It uses the approve/transferFrom flow, so you must have already called approve on the appropriate ERC20 contract.

How to Withdraw from a Custom Gas Token Chain

Using the L2StandardBridge will not work when withdrawing native asset on a custom gas token chain. The L2ToL1MessagePasser must be used directly. Call the initiateWithdrawal function to kick off a withdrawal on the L2 side. Viem, the deprecated sdk and Base's withdrawer tool can all be used to finalize the withdrawal on L1.

How Do Fees Work

The initial release of custom gas token does not have special logic for taking into account the exchange rate between the custom gas token and ether. This logic is nice to have because it requires ether to purchase data availability for Ethereum. If the chain is earning in a custom gas token and spending in ether, then it must earn enough custom gas token such that it can be sold for ether.

For the initial release of custom gas token, the chain operator will need to manage this either out of band or by manually tuning the fee parameters to ensure profitability. A future release may include L1 Fee Abstraction where the L1 fee is calculated in a smart contract instead of native code. This would enable an on chain oracle to take into account the exchange rate of the custom gas token. This oracle could be something like Uniswap TWAP or Chainlink

[tynes]

If you retry with using the latest commit on ethereum-optimism/optimism#10143 and also follow the setup guide, it should fix your issues. Thanks for being an early adopter!

[tynes]

You can skip the call to sync(), this command has been deprecated and our docs should be updated soon

[sbvegan]

This tutorial is being updated. There is a callout that says this is not for production use and to use the tutorials/chain branch. This branch is old and doesn't have the latest updates.

[0xParticle]

Hey Mark! We want to thank you for initiating the discussion thread. At Wonderland, we are excited to contribute to the research and development of the OP Stack Custom Gas Token.

We have devised a possible solution to help chain operators address the batcher cost issue and use any ERC20 that adheres to the specified criteria as a gas token without making significant changes to the OP Stack.

1. Modifying the L1Block contract to include price inputs.
2. Using the sequencer as the oracle updater.
3. Using Prophet as a Generalized Oracle Interface.

1. Modifying the L1Block Contract

To have an on-chain representation of the rate quote of the ERC20 used as gas token, we can modify the existing L1Block contract. We can add a new input called priceRatio to the existing attributes of the L1Block contract. priceRatio would represent the token's price in terms of ETH and would enable us to compute the new "DataFee" using the formula blobBaseFee * priceRatio. However, the main challenge here would be integrating a safe mechanism to update priceRatio for each block without altering the existing OP architecture philosophy.

2. The Sequencer as the oracle updater

We suggest the sequencer takes responsibility for publishing the prices, as they already execute the system transactions. However, since the sequencer is the only party that can benefit from the gas fees, it is crucial to prevent misbehavior.
One way to minimize the likelihood of misbehavior is to lock the rewards for a certain period after the update. These locked rewards can function as an effective bond that can be slashed in case of dispute. This approach aligns well with the optimistic oracle design space, where data updaters can be disputed afterwards.

3. Prophet as a Generalized Oracle Interface

We can implement the optimistic updates from the sequencer using Prophet, a framework we built alongside Optimism.

What is Prophet?

Prophet presents a versatile and fully adaptable optimistic oracle solution, transcending the boundaries of conventional dispute resolution modules. It moves away from a one-fits-all resolution system and provides customizable modules that can be fine-tuned to meet the unique requirements of each user. With its emphasis on complete control and modularity across all aspects of the system, Prophet is an open-source public good for the Optimism community.

For more details on Prophet, visit this link.

We suggest integrating Prophet into the OP Stack as a universal Oracle interface. This setup facilitates using various data sources, reduces provider lock-in, and provides an independent security layer separate from the selected oracle. Additionally, Prophet is easier to bootstrap than other oracles that require many conditions or depend on liquidity.

How can we integrate Prophet?

We must create an additional contract to update the priceRatio in the L1Block contract. It would require the following parameters:

• The L1 address of the token to use, which should be the same as defined in the L1Block.
• Only the sequencer(s) whitelisted address(es) can propose a priceRatio update.
• The address of the Accounting Extension contract that allows users to deposit and bond funds to be used for payments and disputes.
• The address of the contract that handles resolution.
• The time window for disputes.

We can add logic to define an additional set of rules to handle price changes, especially relevant in high-volatility tokens.

As the proposer, the sequencer will send priceRatio updates for each block by calling the propose function.

• It sets the price of the custom gas token similarly to how SetL1BlockValues are determined at the start of each block.
  • The price can also be updated every certain amount of time (min) or if the price change exceeds a specified percentage. If neither condition is met, the last price stored is used.
• The sequencer can use any data provider or oracle to propose prices.
• If the proposed price information is challenged and resolved as incorrect, the sequencer will lose the fees collected by the L1FeeVault corresponding to the disputed period.
  • The system might require an additional bond for the sequencer.

During the dispute period, anyone can challenge a price submitted by the sequencer by calling the dispute function. If no challenger refutes the price submitted by the proposer within the validity period of the proposal, the priceRatio is deemed correct.

The challenger's bond must be low enough to allow anyone to dispute but high enough to prevent spam attacks. We should configure the dispute period so that the oracle can effectively resolve disputes even in the worst-case scenario.

⚠️ Note that the sequencer can censor the disputant for hours at each interaction until it can force the transaction. For these reasons, we suggest that the dispute period can last for days.

The system should minimize calls to Resolution. One way to achieve this is by using the BondEscalationModule, where parties alternately increase the bond until one side concedes or a threshold is reached. You can check an illustrative diagram below.

We can also consider other dispute mechanisms, such as calling directly to resolution when disputed.

When a resolution is called, it will be forwarded to a module, serving as the source of truth. There are several possible implementations of this module:

• ArbitrationModule: An arbitrator can be appointed, which might be a multisig wallet, a committee of DAO members, or the Token House governor.
• When available, we could resolve disputes by bridging the actual price from the Ethereum mainnet to the OP chain, from a Uniswap pool or Chainlink via the Optimism Portal contract. This method would be more reliable, but we must still consider delays and potential censorship by the sequencer during a certain period.
• CircuitResolver: Allows challengers to verify a zero-knowledge proof circuit for a given request and propose it as a response, initiating and resolving the dispute atomically.

We are eager to discuss this design further and open the debate to contrast with other possible approaches, especially in light of the upcoming research on L1 Fee Abstraction.

Questions

• Is it desirable for fully governed OP Stack chains, like Superchain, to designate specific central roles (disputers, arbitration, etc) to be controlled by governance?
• How can we minimize reliance on the sequencer with respect to transaction inclusion in the event of disputes? What would be an appropriate dispute period to prevent sequencer censorship?
• In what situations would it be reasonable to request an additional sequencer bond for proposing?
• Are there any potential conflicts with the current Interop design that you foresee?

[tynes]

This is a really interesting proposal and I have some feedback for you.

I don't think its a good idea to put subjective information in the L1Block contract. By subjective, I mean information that the sequencer can arbitrarily place in the L1 attributes tx. For full nodes to be able to generate the same blocks, the subjective information would need to be placed in the batch data. To turn the subjective information into something objective, it would need to live in a smart contract. Right now, the L1 attributes information has an objective source of truth on L1. This means that the priceRatio would need to live on L1 and be pushed into L2. It is a value that changes often, so that would mean sending txs to L1 to update it. It isn't ideal to require execution to fetch this data, then otherwise it will require an archive node to sync.

I think its a better idea to sidestep the L1Block contract completely and instead create a fee calculation contract that is responsible for computing the fee. The raw tx is passed to the fallback function of this contract and it returns a uint256. This happens before the actual execution of the tx. The chain operator can define arbitrary logic for charging fees and we don't need to enshrine any particular opinions about the governance of the fee charging logic directly into the OP Stack. This approach is describe in #73.

You could imagine that it would be really easy to plug in prophet into this scheme by implementing a fee calculation contract. You no longer depend on the sequencer running oracle infra to build L1 attributes txs, really anybody can manage the fee calculation contract with whatever permissions that they want. You could then go provide prophet as a service to custom gas token chains by running the oracle infra for them :)

[qizhou]

Following the instructions here and using base withdrawer, we set up a testnet (commit) with custom gas token. We also completed deposit (L1 ERC20 => L2 Gas) and withdraw (L2 Gas => L1 ERC20). The following are the notes to help reproduce the steps:

# check balance and allowance on L1
cast call $GAS_TOKEN_ADDRESS "balanceOf(address)" $TEST_ADDRESS --rpc-url=$L1_RPC_URL
cast call $GAS_TOKEN_ADDRESS "allowance(address,address)" $TEST_ADDRESS $PORTAL_ADDRESS --rpc-url=$L1_RPC_URL

# check native balance on L2
cast balance $TEST_ADDRESS --rpc-url=$L2_RPC_URL

# initiate deposit via bridge
cast send $PORTAL_ADDRESS "depositERC20Transaction(address _to,uint256 _mint,uint256 _value,uint64 _gasLimit,bool _isCreation,bytes memory _data)" $TEST_ADDRESS 1000000000000000000 1000000000000000000  100000 false 0x --private-key=$TEST_PRIVATE_KEY --rpc-url=$L1_RPC_URL
# upon success, the ERC20 gas token should be transferred to the portal via etherscan

# wait for a few seconds and check if the token is received and reflected on native balance on L2
cast balance $TEST_ADDRESS --rpc-url=$L2_RPC_URL

# initiate withdrawal
cast send --value 1234567890 0x4200000000000000000000000000000000000016 "initiateWithdrawal(address _target, uint256 _gasLimit, bytes memory _data)" $TEST_ADDRESS 50000 0x --private-key=$TEST_PRIVATE_KEY --rpc-url=$L2_RPC_URL
# this will return a successful tx and its L2 block number

# check if the L2 block is included in L1 and it is finalized
cast call $OUTPUT_ORALCE_ADDRESS "latestBlockNumber()" --rpc-url $L1_RPC_URL

# send a tx to prove the withdrawal
withdrawer \
		--l2-rpc $L2_RPC_URL \
		--l2oo-address $OUTPUT_ORACLE_ADDRESS \
		--portal-address $PORTAL_ADDRESS \
		--withdrawal <tx hash> \
		--rpc $L1_RPC_URL \
		--private-key ${TEST_PRIVATE_KEY#0x}
		
# withdraw the actual token (same command)
withdrawer \
		--l2-rpc $L2_RPC_URL \
		--l2oo-address $OUTPUT_ORACLE_ADDRESS \
		--portal-address $PORTAL_ADDRESS \
		--withdrawal <tx hash> \
		--rpc $L1_RPC_URL \
		--private-key ${TEST_PRIVATE_KEY#0x}

[nidz-the-fact]

send a tx to prove the withdrawal

withdrawer
--l2-rpc $L2_RPC_URL
--l2oo-address $OUTPUT_ORACLE_ADDRESS
--portal-address $PORTAL_ADDRESS
--withdrawal
--rpc $L1_RPC_URL
--private-key ${TEST_PRIVATE_KEY#0x}

withdraw the actual token (same command)

withdrawer
--l2-rpc $L2_RPC_URL
--l2oo-address $OUTPUT_ORACLE_ADDRESS
--portal-address $PORTAL_ADDRESS
--withdrawal
--rpc $L1_RPC_URL
--private-key ${TEST_PRIVATE_KEY#0x}

Hi @qizhou I still don't understand and am confused about these 2 parts of the command. 👇

proveWithdrawalTransaction, finalizeWithdrawalTransaction The internal information is quite detailed. Could you please explain and show a sample command in more detail?
Thank you

[qizhou]

One improvement to the user experience for the custom gas token feature is to simplify the process of bridging L1 ETH to L2 ERC20. Currently, since directly bridging ETH is prohibited (see code), ETH must first be converted to WETH before bridging via depositERC20. This requires users to sign multiple transactions.

We propose simplifying this process by consolidating these multiple transactions into a single transaction that atomically wraps ETH and then calls depositERC20.

[zhiqiangxu]

@tynes It seems by IOptimismMintableERC20 WETH you're referring to the L2 WETH. IMHO there should be no change on L2, but instead a change on L1 that internally wraps L1 ETH into L1 WETH and then reuse the work flow for bridging ERC20 ?

[tynes]

Yes, I understand that you are talking about wrapping L1 ETH into L1 WETH. What is unclear to me is the L2 address for WETH is under your proposed design

[zhiqiangxu]

@tynes Are you talking about that when withdrawn from L2, L1 doesn't know which ERC20 to unwrap since the L2 address for WETH is unknown?

So even if L1 ETH can be automatically wrapped into L1 WETH for deposit, when it comes back, it can only be L1 WETH, not L1 ETH?(source)

[tynes]

I think we are speaking past each other a bit, so I'd prefer for you to follow up with a specific description of how the feature would work end to end :)

The specific problem that I see is sending ETH to a custom gas token chain requires a mintable ERC20 token on L2. If the functionality is enshrined into the bridge for wrapping ether on L1 then there must be a deterministic address on L2 for WETH where it can be minted. This is because the feature would exist on all chains using OP Stack.

I have created a proposal for such a WETH implemention here ethereum-optimism/design-docs#25

[zhiqiangxu]

I think I understand the problem a bit now:

function bridgeETH(uint32 _minGasLimit, bytes calldata _extraData)

function bridgeERC20(
        address _localToken,
        address _remoteToken,
        uint256 _amount,
        uint32 _minGasLimit,
        bytes calldata _extraData
    )

Put simply: bridgeERC20 needs _remoteToken but bridgeETH doesn't have such a parameter. So there's no way to delegate from bridgeETH to bridgeERC20 unless there's a deterministic L2 address(_remoteToken) for WETH.

Most bridges manually configures the mapping(either by admin or multisignature), but op stack is doing this in a more trustless way.

[sbvegan]

To confirm, the Custom Gas Token feature does not support fault proofs. Is that right?

[sbvegan]

This ethereum-optimism/optimism#10780 is the PR that adds fault proof support; howeer, a new CGT beta release still needs to be cut.

[PinelliaC]

Upon careful examination of the Custom Gas Token design proposals and consideration of aforementioned discussions, we have noted a few areas that may benefit from further refinement:

• Question 1: Fees are paid in the custom gas token (hereinafter referred to as 'CGToken'.), but the exchange rate to ether is not taken into account

  • L1 Fees: Ether is used to pay for posting the data to L1, but custom gas token is collected.
  • L2 Fees: gasPrice * gasUsed is used to calculate and collect fees when the transactions are executed in EVM, but in the same case happens again that custom gas token is collected.
  • If we only take tokenRatio in consideration when calculating L1 Fees, L1 fees will constitute the majority of the transaction cost, it becomes difficult to distinguish the impact of transaction complexity on the fees. In such cases, only the size of the transaction data itself affects the fee.

• Question 2: How to support bridging Ether from Ethereum to L2 when custom gas token is enabled

We try to propose to solve the questions.

• Proposal for question 1. We will involve tokenRatio(a.k.a. priceRatio, an exchange rate between Ether and gas token), and for a specific transaction we will use the formula below to calculate its transaction fee:

  • Data Flow: L1:SystemConfig -> op-node:l1InfoTx -> L2:L1Block
  • Fee = L1 Fee + L2 Fee
  • L1 Fee = l1CostFn * tokenRatio
  • L2 Fee = ((gas * gasPrice) + (blobGas * blobGasPrice)) * tokenRatio

• Proposal for question 2. We propose modifying CrossDomainMessenger and StandardBridgecontracts on both L1 and L2 to enable facilitate transfer of native assets and Ether on custom gas token chains.

  • We propose adding a precompile contract on L2 used to bridge Ether, and we can bridge Ether like other ERC20 behaves, so we don't need to involve WETH on L1.

Involve tokenRatio

In our proposal, we do not need to modify the gas cost, but only need to make changes when verifying and adding/subtracting the balance.

• Add a tokenRatio in the SystemConfig in the L1, which can be adjusted by the chain operator, representing the price difference between ether and CGToken. This value will then be stored in the L1Block on L2 via the l1InfoTx, similar to basefeeScalar, etc.
• Modify the tx.Cost() formula to be ((gas * gasPrice) + (blobGas * blobGasPrice)) * tokenRatio + value.
• Modify the NewL1CostFunc and getL1Fee formulas to be tokenRatio * l1CostFn.
• In the state_transition, when processing the balance and gas, the formula will be ((gas * gasPrice) + (blobGas * blobGasPrice)) * tokenRatio.

Note

Regarding the adaptation of Wallets and SDK, the return of eth_estimateGas should be multiplied by tokenRatio.

Modifying bridge contract

The ether is handled similarly to previous ERC20 tokens, where all assets are held within the L1StandardBridge but NOT need to be sent via message. The CGToken is held within the L1OptimismPortal via transfer, consistent with the depositERC20Transaction behavior.

To distinguish the deposit method for CGToken from other ERC20 tokens, we will prohibit operations on CGToken within the _initiateBridgeERC20 function, and introduce a new _initiateBridgeCGToken to handle the CGToken.

On L2, we will modify the L2StandardBridge, where ether (represented as SuperChainWETH) will be minted in the same way as ERC20 tokens, and the CGToken will be sent as a native token.

Using MNT as an example for the CGToken:

[PinelliaC]

I would like to propose an alternative mechanism for this: #73. The idea is fee abstraction, where instead of native code in the L2 state transition computes the fee, we use EVM execution to compute the fee. Under this model, you would be able to use any sort of oracle on L2 to help compute the fee. There are some details that need to be worked out to be able to take this to production, like the specific fee formula under this model, but I do believe its a promising direction to enable chain operators to charge fees more accurately. You could imagine using a uniswap based oracle, a chainlink based oracle or a hot wallet based oracle.

Regarding #73, as I understand it, are you aiming to implement a function similar to blockhash(uint blockNumber) to simplify the logic for getL1Fee? For example:

function getL1Fee(bytes memory _data) external view returns (uint256) {
    return getL1Fee(_data);
}

Or perhaps another implementation? Could you provide more details?

Regardless of the implementation method, it seems that the Oracle would still need to submit the token ratio to L2. I believe we are aligned on this point. This is why we have proposed the current token ratio update logic.

[PinelliaC]

To distinguish the deposit method for CGToken from other ERC20 tokens, we will prohibit operations on CGToken within the _initiateBridgeERC20 function, and introduce a new _initiateBridgeCGToken to handle the CGToken

The deposit of custom gas tokens can only be called depositERC20Transaction on OptimismPortal, so we introduce a new _initiateBridgeCGToken to handle the CGToken. It will enable users to directly deposit custom gas tokens through the L1StandardBridge. This approach will ensure that users can seamlessly deposit these tokens while maintaining consistency with the existing deposit mechanisms.

I believe the best way to handle this situation is to make SuperchainWETH an IOptimismMintableERC20 and then allow ether that is sent into the L1 bridge to mint SuperchainWETH on L2

In this proposal,

• Does ether need to be wrapped into WETH (an ERC20 token on L1 ) when being bridged to mint SuperchainWETH on L2?
• If needed, does this require users to manually perform the conversion?

[tynes]

I am generally opposed to the idea of enshrining a "fee ratio" into L1 and forcing chain operators to be an oracle and push updates. This is not particularly flexible and I consider such a design to be technical debt. We want to create flexible abstractions that can be used to solve many problems rather than enshrining specific things. I do not think it is acceptable to force a L1 tx inclusion liveness guarantee to ensure that the L2 fees stay accurate.

What I propose with #73 involves EVM execution here rather than native code. A smart contract computes the fee. It may be possible to be more generic than just the L1 fee but is more simple if its just the L1 portion of the fee. This would solve pricing for both custom gas token and alt da and also enable things like subsidizing user fees directly in the protocol (MEV rebates)

You have still not addressed the following statement:

We propose adding a precompile contract on L2 used to bridge Ether, and we can bridge Ether like other ERC20 behaves, so we don't need to involve WETH on L1.

What is the purpose?

Proposal for question 2. We propose modifying CrossDomainMessenger and StandardBridge contracts on both L1 and L2 to enable facilitate transfer of native assets and Ether on custom gas token chains.

Can you clarify this? You want to be able to send ether through the messenger and bridge on a custom gas token chain and have it mint WETH on L2 correct? I don't follow why you would want to deposit custom gas tokens through the standard bridge. Its just a waste of gas. Going straight through the portal is cheaper

[PinelliaC]

I’ve reconsidered. The precompile contract on L2 is consistent with SuperChainWETH, so only SuperChainWETH is needed. Depositing custom gas tokens through the portal also makes more sense. There are no more issues regarding the bridge.

For custom gas token chains, it’s also important to consider the exchange rate between ether and the native token when calculating L2 and L1 fees. I have created a proposal for this: ethereum-optimism/design-docs#66

[tynes]

For custom gas token chains, it’s also important to consider the exchange rate between ether and the native token when calculating L2 and L1 fees. I have created a proposal for this: ethereum-optimism/design-docs#66

Can you please address my concern in #140 (reply in thread)?

I am generally opposed to the idea of enshrining a "fee ratio" into L1 and forcing chain operators to be an oracle and push updates. This is not particularly flexible and I consider such a design to be technical debt. We want to create flexible abstractions that can be used to solve many problems rather than enshrining specific things. I do not think it is acceptable to force a L1 tx inclusion liveness guarantee to ensure that the L2 fees stay accurate.
What I propose with #73 involves EVM execution here rather than native code. A smart contract computes the fee. It may be possible to be more generic than just the L1 fee but is more simple if its just the L1 portion of the fee. This would solve pricing for both custom gas token and alt da and also enable things like subsidizing user fees directly in the protocol (MEV rebates)

There is already a way to do what you are suggesting, its just a bit more complex. You can arbitrarily modify the scalar values to approximate the concept of a fee ratio. Sure its more complex, but you could but a function that does this. I do not find the UX of forcing chain operators to send transactions to keep their fees up to date as a desirable UX.