You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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.
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.
The text was updated successfully, but these errors were encountered:
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
viaselfdestruct
.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.
The text was updated successfully, but these errors were encountered: