# Proposal for storing the legacy address translation table

It is proposed to introduce a new address format which increases the length of addresses from 20 to 32 bytes. To ensure backwards compatibility, each `long_address` has a corresponding `legacy_address` and a translation table is used to convert `legacy_address`es to `long_address`es.

This document is a proposal for how to implement the translation table. We assume there is defined a cryptographic hash function `compress` that converts `long_address`es to `legacy_address`es.

## The translation table

The translation table must be accessed in two circumstances:

1. When a `legacy_address` is accessed a lookup must be performed to see whether it refers to a `long_address`.
2. When a `long_address` contract is created or an EOA makes it's first transaction, a translation entry should be created at the corresponding `legacy_address`, unless:
1. A legacy account already exists at the `legacy_address` or
2. A translation table entry for the `legacy_address` already exists.

The subconditions on 2 are required to prevent attacks using generated `legacy_address` collisions, similar to [EIP-3607](https://eips.ethereum.org/EIPS/eip-3607).

## Storing the translation table

We propose to store the translation table entry for `legacy_address` at the same location as an account with that address, which is `keccak(legacy_address)` in the storage trie. The easiest way to do this is to store the `long_address` in the nonce field of the account. An account can be distinguished from a translation table entry easily because [nonces are limited to `2**64-1`](https://eips.ethereum.org/EIPS/eip-2681) and `long_address`es that small are impossible.

We note that it is impossible to create an `legacy_address` account if a translation table entry already exists for it. This must be banned anyway for [EIP-3607](https://eips.ethereum.org/EIPS/eip-3607) style reasons.

## Storing `long_address` accounts

**UPDATE: change [:16] to [:3] so that this works without relying on internal extension nodes**

Since any access to a `long_address` account by legacy contracts or tooling will require a lookup to the corresponding `legacy_address`, it would save resources (mostly reducing witness sizes) if `long_address` accounts were stored stored near their corresponding `legacy_address` in the storage trie.

`legacy_address` accounts are stored at `keccak(legacy_address)` in the storage trie. We propose to store `long_address` accounts at `keccak(compress(long_address))[:3] + keccak(long_address)[3:]`. This will result in the translation table entry for a `legacy_address` and the account for the corresponding `long_address` being near each other in the storage tree reducing witness sizes in the common case when both are accessed.

## Security considerations

Everything proposed here is secure to a 128 bit security level. We have deliberately left unspecified what happens when a `long_address` and it's translation table entry are stored in the same place in the storage trie because finding such an address takes `2**128` hashes.