L2 Aliasing of EVM based Addresses from the EEA-OASIS Community Projects L2 Standards Working Group

1 Introduction

The L2 WG is an open-source initiative with a scope to

  • Identify and document the most relevant use cases and business requirements for Layer 2 and other Blockchain Scalability solutions for EVM-compatible public blockchains

  • Define a technical standard with identification and differentiation of classes of scalability solutions as required that meet both ecosystem and enterprise requirements, with a particular focus on interoperability between Layer 2 solutions for EVM compatible public blockchains

  • For EVM-compatible public blockchains, identify, document, and devise solution approaches for Layer 2 Blockchain scalability solution-specific challenges such as MEV, block (gas) limits, TVL concentration, etc.

  • Identify and document characteristics of Layer 2 Blockchain environments for EVM-compatible public blockchains that will be key in addressing mainstream and enterprise adoption.

The work is an EEA Community Project, which is managed by OASIS.

The L2 Standards WG has just released a first draft of a L2 Aliasing of EVM based Addresses specification. The WG is intending to release this specification also as an EIP. As part of the EIP process, this post is to start a discussion on this topic.

1.1 Overview

The ability to deterministically derive addresses of a digital asset or an externally owned account (EOA) in EVM-based execution frameworks for L1s, L2s, and Sidechains based on an origin chain of an asset or EOA, known as address aliasing, simplifies interoperability between EVM based L1s, L2s, and Sidechains because:

  • It allows messages from chain A (source chain) to unambiguously address asset A (smart contract) or EOA on chain Y (target chain), if asset A or EOA exists on Chain X and on Chain Y.

  • It allows a user to deterministically verify the source chain of a message, and, if required, directly verify the origin chain of asset A or EOA and its state on its origin chain utilizing a canonical token list of the (message) source chain.

Note, that address-aliasing between non-EVM and EVM-based L1s, L2s, and Sidechains, and between non-EVM-based L1s, L2s, and Sidechains is out of the scope of this document.

The EIP is now in DRAFT status.

Please, review and comment!

There are a few other EIPs that describe addresses plus which chain they belong to. Have you considered them, and if so, what benefits does this proposal bring over those standards?

@SamWilsn Apologies for the very liing delay. I presume you refer to EIP-3770 (chain specific addresses). The suggested approach generalizes 3770 and extends approaches used in practice. Hence, the proposal.

EIP-4337 (Account Abstraction) is not really relevant as the address aliasing is meant to be used in bridge messages. Similar arguments apply EIP-2678 and EIP-4834.

If there are others that I missed, please, advise.