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.