Constructing the EVM with hierarchical addressing [was: hierarchical consensus]

[Stebalien]

The current EVM proposal is to create one top-level actor per EVM contract. However, this leads to some annoying issues:

1. Exactly matching EVM addressing semantics is tricky and ugly (CI speedup? #76).
2. EVM gas accounting for EVM->EVM calls is tricky because there's no great way to communicate how much EVM gas (distinct from FVM gas) is remaining between FVM actors.
3. On-chain automatic account creation from the EVM is tricky because EVM addresses are 20 bytes, and our account public keys are 32 bytes. We'll need a "holding pen" for "pending" accounts regardless of what we do.

One solution to both of these problems is to model the EVM with hierarchical consensus, just without multiple chains. That is:

1. Store all EVM contracts in a single EVM actor (a top-level Filecoin actor).
2. Give all EVM contracts addresses relative to this EVM actor.
3. Let other FVM actors address EVM contracts relative to the EVM actor using hierarchical addresses.
4. Let EVM contracts address each other with normal EVM addresses.
5. Let EVM contracts address FVM actors by actor ID, I.e., 16 zeros, then an 8 byte number.

Pros:

• The entire EVM ecosystem on Filecoin would be self-contained.
• EVM to EVM calls would be simpler and likely cheaper (no translation).
• We want this kind of "cross-system" addressing anyways for hierarchical consensus.
• This model makes it significantly easier to port other foreign runtimes.

Cons:

In general, interop between the two systems becomes a bit more annoying. On the other hand, we want to solve this issue for hierarchical consensus anyways.

We'll also likely end up with EVM "shim accounts" to support the "create account on send" functionality. When an EVM contract sends to a new address, there's no way to know if that new address will end up being an EVM contract or an account. But that's "fine" as long as:

1. There's a way to later bind it to a real "account".
2. Our tooling handles this case automatically.

This also only applies to accounts that don't already exist when an EVM contract first tries to send to them.

[Stebalien]

NOTE: we have discussed this model before, but in the past it always involved "proxy" actors. We didn't like that approach because it would mean that EVM accounts didn't have "real" addresses (from the perspective of FVM actors).

The novel part of this proposal is to introduce first-class hierarchical addressing. We already have support for multiple address formats, so this isn't quite as daunting as it might seem.

But it's still a non-trivial proposal.

[anorth]

The term "hierarchical consensus" brings in a lot of conceptual baggage that I think confuses things here. I would note that a rollup would have many of the same benefits as using a full hierarchical consensus-like mechanism. But I think there's a simpler proposal about addressing in there (but all messages are landing on the same chain/state).

[Stebalien]

Ah, yes. Basically, the idea is to use two parts of hierarchical consensus:

1. The concept of actors being "fronts" for entirely separate systems of actors.
2. Hierarchical addressing.

Not to actually use separate chains, rollups, etc.

[raulk]

We have decided to adopt the flat model, where foreign actors (e.g. EVM smart contracts) are deployed as first-class actors on the FIlecoin chain. This puts them at an equal footing as every other actor, whether native (Wasm) or not, and forces us to introduce protocol advancements to support seamless interoperability across supported runtimes (account abstraction, extensible addressing, etc.) It also makes state management more granular and likely cheaper (every actor has its own state, vs. one massive state subtree containing the subworld of category X of actors). It is subjectively conceptually easier to reason about, prevents hyperspecialisation inside the realm of foreign runtimes, and doesn't require special runtime-level registries or proxies.

One such protocol advancement worthy of mention here is "extensible addressing" (spec submission to follow), which draws from some of the notions around hierarchical addressing introduced above. In essence, we propose to introduce the the concept of actor factories that govern actor construction and the binding of addresses under a new f4 address class, which is namespaced by actor factory ID. @Stebalien will follow with a spec.

[raulk]

@Stebalien should we close this discussion now that we've moving ahead with a concrete approach?

[Stebalien]

Yep.