The F4 Address Class (FIP-0048)

[Stebalien]

Previous discussion: #459
FIP: #474

I'm opening a new discussion so we can discuss the final text of the FIP with no confusion. Please refer to the previous discussion for context, but keep discussion of the FIP itself here.

[jbenet]

Hey @Stebalien

We split the actor-assigned "sub-address" with a dash for easy readability. We could have encoded this address as f4{base32(leb-encoded-actor-id || sub-address || checksum)}, but that would have been impossible for a human to read.

Talking to @magik6k about this. Dashes are a huge problem for UX -- they break copy paste in most tools. IPFS & the blockchain world worked super hard to keep dashes out of identifiers for the goal of making them very easy to transport across lots of devices (think copy-pasting in a bunch of different kinds of devices and phones, etc). Strong opinion here that we should go for human friendliness in copy-pasting, not reading. most end users don't read & try to interpret addresses, but they do copy-paste them a lot.

[magik6k]

If we want to bikeshed about letters, f also looks like a decent choice - it looks a bit like | if, and is symmetric with the f at the start of address.

f432fabcdefg

[Stebalien]

@raulk brought up a good point with respect to testnets: t432fabcdefg breaks the symmetry a bit. I'm inclined to just keep it as-is to reduce confusion (especially because testnet addressing is pretty rare) but we should still finalize this.

[mriise]

well... in some fonts t is just an upside down f ish soooo....

though underscore counts as a break on IOS things so that's a no-no. I'm for f

[Stebalien]

So, we just tested _ in iOS, and it doesn't select as one word. So we're down to f.

[raulk]

Testnet addressing will become very common, and as a newcomer to Filecoin, I'd find it easier to reason about a symmetric pattern:

t...t... and f...f...
(Oh, it's the same letter, must be a separator of some kind)

Than about two than can only be combined in two special ways:

t...f... and f...f...
(What about f...t...? Now you gotta explain and this breaks the 'separator' mental model)

[anorth]

Thanks for the FIP @Stebalien, this looks great.

[Stebalien]

How should an embryo react if called with a non-zero method number? This isn't covered in the current spec.

• The Ethereum equivalent just accepts any call, and returns nothing.
• The current prototype in ref-fvm rejects any call to any method other than method 0 (value transfer).

Personally, I believe the prototype's approach (reject the calls) is safer. It means that, e.g., if an actor fails to deploy because of some chain re-org, a follow-on invocation of said actor won't just silently succeed. I.e.:

1. User A sends funds to some address A, creating an embryo.
2. User B deploys an actor to address A.
3. User C calls a method on the actor at address A (e.g., buys an NFT).

In Ethreum's model, if step 2 gets "re-orged out", user C's message will silently "succeed" (spending the funds) but intended actor won't be invoked (because it hasn't been deployed yet).

In the current prototype's model, the message at step 3 will fail, reverting the send.

[anorth]

Rejecting sounds good to me.

[Stebalien]

So, I'd like to revisit this as it has an unfortunate interaction with FIP-0054 and FIP-0055.

• In FIP-0054 (FEVM), we need to special case placeholders and non-existent actors because non-method-0 sends will fail.
• In FIP-0055 (EthAccounts), we again need to turn Ethereum transactions with no parameters into "method-0" sends for the same reason. If we didn't,

The solution I'd like to propose for now is to allow calls on all methods. I.e., the placeholder actor will just return success immediately in all cases.

---

Note: In the future, I'd like to revisit placeholders entirely: #473 (comment)

[anorth]

Yep, sounds good now we do nearly that for the built-in account too

[Stebalien]

Future improvement: assign f4 addresses to all actors (cc @shrenujbansal who suggested it).

For accounts (f1/f3):

1. Create a new "address manager" for the builtin account type.
2. Continue to assign f1/f3 addresses to accounts (for now) but treat those as "legacy".
3. When creating a new account, assign an f4 address where the subaddress is key_type ++ public_key.
4. Run a migration that assigns those addresses to all existing accounts.

This should let us (eventually) use account abstraction for "builtin" accounts (as long as we maintain backwards compatibility).

For actors, we treat the init actor as an "address manager". If the user calls Init::exec instead of Init::exec4, the init actor will derive an f4 address for the new actor.

[jennijuju]

oh neat

[Stebalien]

The name "embryo" is confusing. As @raulk notes:

Since we are in draft review time, I will use this opportunity to review the choice of the term "embryo" more generally. This term has repeateadly evoked confusion and "can you explain?" reactions in the community. This indicates that it's not a good name.

A possible issue is that the term "embryo" is highly metaphoric and figurative. Metaphores can be effective when used as part of a story, but generally ineffective when used standalone. We really want easy comprehension for protocol concepts, so I'd avoid using metaphores for protocol names.

Can we consider the name "placeholder actor"? This term already denotes that it's a temporary entity subject to some future replacement. And the replacement, or transition out of this state into a concrete actor (EEOA or EVM runtime in this case), can be termed "reification".

@ribasushi then proposed "stub". Discuss

---

Sending to an f4 address creates a placeholder actor.
Sending to an f4 address creates a stub actor.
Sending to an f4 address creates an uninitialized actor.

Exec4 can deploy code to an existing placeholder actor.
Exec4 can deploy code to an existing stub actor.
Exec4 can deploy code to an existing uninitialized actor.

[jennijuju]

+1 on placeholder

[anorth]

Placeholder (unabbreviated)

[johnnymatthews]

+1 for placeholder.

Stub actor sounds weird in my accent. Uninitialized actor implies that we'll be using the term initialized actor, which we won't/don't.

[trruckerfling]

+1 placeholder, thanks for bringing up, embryo and aborting the actor has been lil odd

[dd45e640b42e6da7da96faee3996ef7c]

if there already is a technical term for what "the thing" actually is/is doing - use that.

[Stebalien]

In the future, I'd like to revisit placeholders. I believe placeholders will serve us for now, but I'm becoming increasingly convinced that we should get rid of them and instead deploy real actors on first send.

• This would avoid annoying edge-cases like The F4 Address Class (FIP-0048) #473 (comment).
• This would remove some "magic" from the system.
• Allow an auto-deployed actor to actually run code instead of just blindly accepting funds.

Specifically, I'd let address managers register an actor that should automatically be deployed on first send to one of the addresses they control. Unlike most actors, these actors would not be able to run a constructor (to avoid running user-defined code on method-0 sends). Instead, a user would have to later "initialize" the actor.

This would require an upgrade syscall and a well-defined upgrade flow to allow users to implement their own "placeholder-like" actor.

Example automatic multisig deployment:

1. Let there be an address manager (actor id=12) for multisig with code M.
2. Said address manager registers M with the init actor.
3. Several actors transfer funds to f412f$INIT_PARAMS_HASH causing an actor with code cid M to be deployed there.
4. The owner of f412f$INIT_PARAMS_HASH initializes the actor with initialization parameters matching $INIT_PARAMS_HASH.
5. The owner can now withdraw funds.

---

However, this is something we can decide on later. A future migration can replace all f410f placeholders with a different actor (likely an EthAccount).

[jennijuju]

What’s the implication of that potential protocol change of existing placeholder actors?

[Stebalien]

The only placeholders that can be deployed right now are managed by the EAM, so there shouldn't be any impact. Basically, we'd:

1. Change the EthAccount actor to allow upgrading an "unused" EthAccount into an EVM actor.
2. Replace all f410f placeholders with EthAccount actors.

[anorth]

I agree with the direction. The upgrade flow is what I always thought we were going for with placeholders anyway.