Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Research Area: Using L2 Native Token to Pay Gas #114

Open
tynes opened this issue Apr 8, 2024 · 0 comments
Open

Research Area: Using L2 Native Token to Pay Gas #114

tynes opened this issue Apr 8, 2024 · 0 comments

Comments

@tynes
Copy link
Contributor

tynes commented Apr 8, 2024

Enabling a L2 Native ERC20 Token to Pay for Gas

This is an experimental feature and it is not clear if it will ever be included in the OP Stack.
When considering the possibility of using an L2 native ERC20 token to pay for gas, the design constraint
is no diff to the execution layer client. The legacy design of Optimism modified the execution client
such that an ERC20 WETH was used as the native asset. This resulted in a critical bug
that would have allowed infinite minting of ether via selfdestruct.

It may still be possible to use a L2 native ERC20 token to pay for gas given this constraint. The
design could involve modifying the derivation pipeline to accept the previous L2 block's outputs instead
of just the next set of inputs. This would make it more similar to the design of Ethereum's state transition
function.

A simplified design of the Ecotone system:

(mathjax doesn't render on github but does for mdbook, preserved to enable easy copy/paste)

\( L2\_inputs_i = derive(L1\_data_i) \)

\( L2\_outputs_i = state\_transition\_function(L2\_inputs_i) \)

Where \( L1\_data_i \) represents a chunk of L1 data containing L2 batches.

Ethereum State Transition Function:

\( σ_{t+1} ≡ Υ(σ_t, T) \)

Where \( Υ \) is the state transition function, \( σ )\ is the state at a particular block and \( T )\
is the next set of transactions to execute, also known as a block. This is taken directly from the
yellow-paper.

Possible future design of Derivation Pipeline:

\( L2\_inputs_i = derive(L1\_data_i, L2\_outputs_{i-1}) \)

\( L2\_outputs_i = state\_transition\_function(L2\_inputs_i) \)

This would enable a design where the derivation pipeline can be aware of mint events from a particular predeploy.
The predeploy could represent an ERC20 wrapped version of the native asset and contain wrapping/unwrapping logic.
The unwrapping logic would result in a future L2 block containing a deposit transaction that mints the native asset.
The wrapping logic would be provably burning the native asset on chain and minting an ERC20 representation of the asset.
Further work needs to be done to determine if such a design is desirable. A version byte in the storage slot meant
to hold the custom gas token address could be used to make the layer the custom gas token is native on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant