[OLD] The F4 Address Class

[Stebalien]

This post contained a draft of the F4 address class FIP proposal. The FIP has now been proposed but you can view past versions of this post by clicking the "edited" drop-down at the top of this post.

FIP Proposed: #474
New Discussion: #473

[mriise]

A way to enforce checksums would be to include a byte length of the bytes, with the remaining bytes being the checksum.
[4, {leb128 id}, {leb128 addr len}, {sub-address}, {checksum}]
textual format could have add a delimiter in between the sub-address and the checksum, but wouldnt strictly be necessary.

[Stebalien]

My main goal was size and uniformity with other Filecoin addressing schemes. hex + checksum would definitely make the most sense for Ethereum support.

[mriise]

bikeshed of a checksum delimiter = e.g. f432-xxxxxx=yyyy since it is the check_sum_ of the previous bytes. :)

[Stebalien]

I'd like it to be as safe as possible for filenames, domains, etc.

[steven004]

I would love to see the checksum is attached in f4 addresses, same as f1, f2, f3, since it would be used for fund transaction.

I know there are some mistakes happened already while some users using f0 address as destination for fund sending. It results in fund lost since it is short and no checksum, very easy to make mistake.

If there is no checksum for f4, same thing will happen.

[Stebalien]

Yep, I agree. We definitely need a checksum (and it should probably cover the ID as well).

[mriise]

Should the Code CID of egg actors be a magic CID or the CID of some (carefully made) minimal actor code?

[Stebalien]

Yeah, minimal actor code would likely be the cleanest, honestly. It could even abort all method invocations with some form of "is an egg" exit code.

[mriise]

We can try to borrow MAX_SUBADDRESS_BYTES from domain names and go with a limit of 256 bytes though if nested addressing happens at some point in the future with 32 bytes per address, things get cramped somewhat quick, but not unreasonably so.

[mriise]

I would err on the larger size, since this will be used as a generic addressing scheme. What I would really like is to leave us open to have raw post-quantum pubkeys in addresses, though unfortunately most are significantly larger than 64 bytes outside of SPHINCS+.

[Stebalien]

1. We tend to copy addresses around by value, so we do need these to be smallish.
2. Erring on the size of "larger" only helps if "larger" is large enough, which isn't going to be the case here regardless of what we do.

In the case of post-quantum keys, I expect those won't be included directly in the address. In that case, I'd expect the address to be the hash of the key.

[mriise]

Hashing it works, but i'm not the biggest fan of having hashed pubkeys that needs another lookup before being able to use it for validation. That isn't enough reason motivate a significantly larger size than 32 though. 64 bytes I would still like to have though, those extra bytes appended to a signature will be useful for inline metadata things.

[Stebalien]

• If you use secp256k1, you'll just hash and use ecrecover.
• Otherwise, you'll likely use ed25512 which has 32 byte public keys.
• Otherwise, you're likely using something large at which point you'll need to hash.

We can make it a little bit bigger for some extra metadata, but every byte counts here as we tend to copy these things around by-value, charge for them on the network, etc.

Right now, the "max size" of an address is 49 bytes (BLS). The max size of an f4 address with a 32 byte payload is 42 bytes. We could allow up to 39 bytes without increasing the size overall. Or, we could say that the max encoded address size is 64 bytes and allow 54 bytes for the payload.

[mriise]

Sounds reasonable. So the total number of bytes we pass around the network is 64, with 10 reserved for prefix-ing and namespace things, with whatever remaining being reserved for the value of the subaddress. Do we hard cap value at 54 bytes or have it just be 64 - prefix.len()?

[Stebalien]

We propose deploying well-known (FIP-bearing) address management actors starting at ID address 32 (to save room for additional singletons). The ETH Address Manager will be the first, at f032.

We could also start this address range earlier at, say, 20.

[anorth]

I think we actually wouldn't want a built-in for the "native" counterfactual, since that makes it actually more malleable than a user-deployed contract (and immutability is critical here).

[raulk]

The next unassigned singleton address is 7 (source). I would err on the side of something easy and memorable because this ID address will be more prominent and visible across various UI surfaces than other singleton addresses. Maybe 10 so that we get f410-...?

[Stebalien]

I think we actually wouldn't want a built-in for the "native" counterfactual, since that makes it actually more malleable than a user-deployed contract (and immutability is critical here).

I think being able to recognize the address is more important. Yes, it could be modified in a network upgrade, but upgrades are really allowed to modify just about anything and require whole-network consensus.

[steven004]

I think we actually wouldn't want a built-in for the "native" counterfactual, since that makes it actually more malleable than a user-deployed contract (and immutability is critical here).

I have the same question. It will be much more flexible for upgrading if it is a user-deployed contract. And, another question is why the ETH address-manager is a build-in actor, while all others deployed in future will be in user space?

And, if we really want a build-in actor at this time, I would prefer 60 rather than 32 to be compatible to BIP44 in which the coin-type of ETH is 60.

[Stebalien]

I have the same question. It will be much more flexible for upgrading if it is a user-deployed contract.

I expect users will deploy their own. The goal would be to have some set of "well known" address managers for common counterfactual interactions.

And, another question is why the ETH address-manager is a build-in actor, while all others deployed in future will be in user space?

The ETH address manager would be deployed in M2.1 and general user-defined Wasm actors won't be deployable till M2.2.

And, if we really want a build-in actor at this time, I would prefer 60 rather than 32 to be compatible to BIP44 in which the coin-type of ETH is 60.

That's not really a pattern we can keep for other addressing schemes, so I'm not sure if it's really worth trying here.

[ZenGround0]

Exec4 for creating new actors with an f4 address (in addition to an f2 address).

How are f4 and f2 associated together? An additional map in init actor? Both added to address_map and three addrs returned from Exec4 and force the caller to maintain association?

[ZenGround0]

I was asking about how to use the stable address for your f4 but I think the answer is just Exec4 returns all 3 and the user uses the returned f2.

[Stebalien]

Ah, yes, I'll define the return address.

[Stebalien]

Hm. Ok, so, I'm currently proposing that it should return the f0 and f2 address. It could return the f4 address... but that's not really necessary? The calling actor should know what the f4 address will be.

[raulk]

I think it helps to clarify that the "calling actor" is not an arbitrary actor, but rather the Address Manager / Actor Factory for that namespace who actually -- it is actually a qualified actor who owns the address space. In fact, I'd imagine the proposal would become generally clearer if it made that distinction.

Perhaps some of the confusion comes from the fact that up until now, Exec has encapsulated the responsibility of generating and assigning all addresses for the newly created actor. With Exec4, the semantics change a little because it no longer generates all addresses the actor is bound to.

Thought: I've always found the Exec term confusing and short-sighted (it assumed that the init actor only ever did one thing, and that thing was represented by "executing the init actor"). Could now be a good opportunity to rename...?

• Exec => Create -- creates an actor assigning f0 and f2 addresses
• Exec4 => CreateBind4 -- creates an actor assigning f0 and f2 addresses, and binding a supplied f4 address
• Bind4 => Bind4 -- binds an f4 address to an actor that already has an f0 address (not sure about the f2, need to read all the threads to parse where we finally landed)

[Stebalien]

Perhaps some of the confusion comes from the fact that up until now, Exec has encapsulated the responsibility of generating and assigning all addresses for the newly created actor. With Exec4, the semantics change a little because it no longer generates all addresses the actor is bound to.

How so? It's basically Exec except that it also binds an f4 address.

Thought: I've always found the Exec term confusing and short-sighted (it assumed that the init actor only ever did one thing, and that thing was represented by "executing the init actor"). Could now be a good opportunity to rename...?

I agree, but that feels like a followup FIP (or a prequel if we want to do it that way).

[ZenGround0]

From context it looks like Exec4 calls into Bind4 functionality if the f4 address contains an egg but this is not laid out explicitly in the Exec4 spec. Is that correct?

[Stebalien]

Not quite. Does the "Bind-Only (No Exec4)" section help distinguish between the two?

[ZenGround0]

It helped but only enough to ask this question. I'm having some trouble parsing the Exec4 spec in the case the f4 address points to an egg

2. If an actor exists at that address, and it's not an egg, abort. f4 addresses MUST NOT be rebound once code has been deployed.

This is clear. "exists at that address" here means that the init actor address map has a mapping

3. Otherwise, if an actor does not exist at that address, create a new actor and assign the f4 address to that actor.
4. Assign an f2 (stable) address to the actor (the f4 address may not be reorg stable).

Clear I think. We don't do 3 in case of an egg but everything else we do.

5. Deploy the specified code CID to the actor, and invoke the actor's constructor.

Does "deploy" here mean overwrite the code CID of the egg?

[ZenGround0]

Finally, Exec4 will return the new actor's ID and f2 (stable) address.

We return the ID address already assigned to the egg when it was created on send?

[Stebalien]

Does "deploy" here mean overwrite the code CID of the egg?

Yes. I'll clarify.

We return the ID address already assigned to the egg when it was created on send?

Yes, that's the difference between Bind4.

[ZenGround0]

Do f4 eggs created through sends also get a stable f2 address?

[Stebalien]

Does the section make more sense now?

[ZenGround0]

Yes, to be super clear is it the case that this

Bind the target f4 address to that actor.

means the init actor address_map associates f4 to the egg actor's id?

[Stebalien]

means the init actor address_map associates f4 to the egg actor's id?

Yes. I'll define that explicitly.

[anorth]

Sending to an unbound f2 address will not be supported.

Can you explain why we can't support this? I would urge us to try.

Without this, it's impossible to get the actor ID corresponding to an unbound f2 address. This means that for a natural representation of state like token balances as a mapping of actor ID to balance, f2 addresses cannot be supported. This would prevent transferring tokens to a counterfactual address.

This request is somewhat independent of this f4 proposal, and I was going to request it anyway, suggesting a similar placeholder/embryo approach to hold the balance until an actor could be deployed there. Will this proposal make that harder?

[Stebalien]

I'm not sure how an f2 address can be used counterfactually.

Unless we change how they're computed, that is. But then they're less useful as reorg stable addresses.

[anorth]

My proposal in #379 used the same f2 address space for predictable addresses, despite the different method of generating them.

Having digested this proposal more fully now, I think there is some introductory context missing about the relationship between f4 and f2 addresses. With my proposal above and earlier ideas about embedding addresses in mind, as I was reading I had thoughts like "why?" (above), "will f2 become second-class citizen vs other types?", "is f2 a subclass of f4? which actor owns it?".

So up front I think helpful context would be:

• f2 and f4 are distinct address classes, and there is no subset relationship or embedding
• an address of both types can be mapped to the same actor ID
• f2 remains solely as a re-org stable address for some actors, and won't be used for predictable addresses as Predictable actor address generation for wallet contracts, state channels (aka CREATE2) #379
• f2 addresses never map to eggs

[anorth]

The sentence "However, an f2 address will only bound if/when code is deployed to this embryo" is confusing, because it suggests an f2 address could have an embryo, in contradiction to the earlier statement "Sending to an unbound f2 address will not be supported".

[raulk]

I think it would be helpful to elicit the constraints and limitations that lead us to this design decision, as well as the implications for FVM native actors and bidirectional interoperability with non-native actors.

It may also help to draw a few more strokes of the owl and define the basics of the f4 namespace that would serve to unify all actors?

[Stebalien]

I've updated the proposal (links don't work because github discussions, but take a look at the F2 versus F4 section).

[ZenGround0]

Two small questions about forwarding

Replacing the egg’s state with an inline CID containing the target actor’s ID address (CBOR encoded).

This is the egg's state cid at the top level actor struct right? Could we instead inline actor id? Just a varint should be good no?

** If we call these things eggs then forwarded eggs should be called hatched. (If we call them embryos they should be differentiated)

2. There's a brief mention of system forwarding. Is it correct that this means when some actor does a send to a hatched egg the fvm will follow the id to the bound actor and invoke the send on that actor instead? So calling the hatched egg or the id of the bound actor will always get the same behavior?

[Stebalien]

This is the egg's state cid at the top level actor struct right? Could we instead inline actor id? Just a varint should be good no?

We could. I'm just proposing this solution as the "least breaking":

• State-roots are always CIDs.
• No kinded unions.

** If we call these things eggs then forwarded eggs should be called hatched. (If we call them embryos they should be differentiated)

Well, I was going to call them scrambled. Eggs hatch into actors (chickens), or get scrambled and forwarded (ok, fine, the metaphor breaks down a bit).

There's a brief mention of system forwarding. Is it correct that this means when some actor does a send to a hatched egg the fvm will follow the id to the bound actor and invoke the send on that actor instead? So calling the hatched egg or the id of the bound actor will always get the same behavior?

Yes. The idea is to treat the ID as an alias.

[ZenGround0]

We could. I'm just proposing this solution as the "least breaking":
State-roots are always CIDs.

I wasn't being clear I meant use inline CID for stateroot but instead of CBOR encoding address varint encode actor id as the CID's inline data. I like "state-roots are always CIDs"

Well, I was going to call them scrambled.

aha brilliant

[Stebalien]

I wasn't being clear I meant use inline CID for stateroot but instead of CBOR encoding address varint encode actor id as the CID's inline data.

Well, it needs some format. That format could be raw bytes, but IDs are numbers.

[anorth]

A few note on the clarity/context/expression, separate from comments about the substance:

Bind the target f4 address to that actor

What does this new term "bind" mean? I figured it out, of course, but please either define this or (preferable) remove it and talk about "mapping address to actor ID" explicitly instead.

where {caller-actor-id} is the f0 address (ID address) of the actor invoking the init actor

Do you mean the actor ID or the (f0) ID address? Using the address here is just a waste of space. Just use the actor ID. Also you don't need to define actor ID in terms of the payload of an f0 address: the actor ID is canonical and addresses defined in terms of it.

I suggest using actor ID directly generally everywhere that you're using an f0 address (including the inline CID for forwarding that Zen commented above).

"embryo actor" (hereafter called an “egg”)

Please pick just one of these terms and use it exclusively. I'd already forgotten the "hereafter" by the time I first read "egg", partly because you did then use "embryo" a few times before switching. Delete reference to the other term from the doc entirely.

[Stebalien]

What does this new term "bind" mean? I figured it out, of course, but please either define this or (preferable) remove it and talk about "mapping address to actor ID" explicitly instead.

I'll change it to assign, but I've left the method name as Bind4 until we finish the discussion (to avoid confusion). At that point, we can decide to rename it, remove it, etc.

Do you mean the actor ID or the (f0) ID address?

Yes. Fixed.

I suggest using actor ID directly generally everywhere that you're using an f0 address (including the inline CID for forwarding that Zen commented above).

Fixed.

Please pick just one of these terms and use it exclusively.

Fixed. I just went with embryo.

[anorth]

Why mix the f4 bindings into the others? We can save HAMT traversal if we can identify a subset directly from the key, and have two, smaller HAMTs.

"Requiring no additional state or state migrations" is not a good reason for a design choice here – these are easy to do.

[Stebalien]

This is a log-base32 datastructure with bucketing, so the overhead is very minimal. Doubling the number of items (worst case and unlikely) will add less than a single layer (1/15th of a layer if fully balanced, but I'm not sure how the probabilities work out.

Given that we already store f1-f3 in this HAMT, moving f4 to another HAMT would be an exception.

[anorth]

f1-f3 are mutually exclusive, so another property we currently have is that an ActorID only appears as a value once. I'm not sure whether that's an important property though.

[Stebalien]

I don't think so? We could also drop f2 addresses from these actors, but those are still useful for stable addresses. I'll discuss the different requirements in the draft.

[anorth]

I do not think the motivation for ID address forwarding justifies the complexity introduced. Re-binding addresses breaks the monotonicity of address -> ID mapping, as well as the "actor has one ID" property that you noted. This stable mapping is needed for on- and off-chain programming. Forwarding won't work for actors that have stored eggs' actor IDs in state, e.g. as keys to a mapping of asset balances. But given N:1 actor addresses to IDs, the ID is the only sensible key to use. Token-like actors need a canonical key to be fixed so they can stably identify whether two addresses refer to the same actor. And they do need to be able to assign balances to IDs of not-yet-deployed actors just the same as native tokens. This'll be neatly solved by f4 in the basic case.

Anything like “the eggs funds will be transferred to the actor” will break in the general case of user actors – so needing to do it is probably a design warning. It only works for the actor->balance mapping embedded in the state tree. Note that DeleteActor also has the "transfer funds to another actor" thing, but it's not at all surprising that any user-programmed tokens held by a deleted actor are lost.

Forwarding also adds a bunch of complexity to understanding the state tree forevermore: future core protocol developments as well as countless off-chain analysis tooling.

I recommend simply removing Bind4.

[Stebalien]

In general, I agree. I hate the forwarding approach is ugly and has a lot of implications. Unfortunately, creation-on-send means that any form of "bind" either requires forwarding or tombstoning, both of which have issues.

I mostly want this so a user can have a single account for both the Ethereum world (e.g., metamask) and the Filecoin world. But we have a few options:

• Have lotus users deploy a "proxy" eth account actor at the target address, controlled by their account actor. This would give the user two "accounts" at two addresses controlled by the same key, but that's not the end of the world as long as we present it well in the UI.
• Implement userspace forwarding (see Provide an option to disable method-0 (value only sends) ref-fvm#835) and allow users to deploy a "forwarding" eth account actor at the target f4 address. This will make receiving value at that address more expensive, but it means the user would only have to deal with one balance.

[Stebalien]

For now, I think the simplest solution is the proxy solution. I was originally concerned about sending Ethereum/Filecoin messages from the same key, but if we proxy the Ethereum messages through the filecoin account, we should be fine.

Basically, we'll have to implement some form of Exec or Forward method on the EthereumAccount actor that only executes messages from an account with the correct key address. I.e.:

fn forward(key: PublicKey, msg: MessageSpec) -> RawBytes {
    // derive the f1 address from the key.
    // resolve the f1 address and compare it with the caller.
    // derive the ethereum address from the key.
    // compare it with this account's key.
    // if that all checks out, execute the message.
}

[anorth]

I have been assuming (but realise it's not stated) that the embryo actor code will include an upgrade function that essentially allows whoever owns the address to upgrade-in-place to any actor they like there (including an EVM actor). In this scheme, the ownership predicate for the address might be delegated to the address management actor – this is actually a nice way of making that extensible (rather than having scheme-specific checks within the embryo code itself). Would this not support the "single account for both worlds" (after sending an upgrade message)?

If not this, what functionality do you envision the embryo having? Was it only "to be replaced by Bind4"?

[Stebalien]

have been assuming (but realise it's not stated) that the embryo actor code will include an upgrade function that essentially allows whoever owns the address to upgrade-in-place to any actor they like there (including an EVM actor).

Technically, no. The plan is to simply overwrite it with a new actor, calling the constructor on the new actor instead of following the upgrade path.

Asside: I'd prefer to use an upgrade method, but that's tricky because upgrade will invoke a special wasm upgrade entrypoint instead of the standard constructor. This way, both the old actor and the new actor have a chance to "opt in" to the upgrade. Otherwise, an attacker could deploy a malicious actor, register itself with some other actor, then "upgrade" to another actor.

In this scheme, the ownership predicate for the address might be delegated to the address management actor – this is actually a nice way of making that extensible (rather than having scheme-specific checks within the embryo code itself). Would this not support the "single account for both worlds" (after sending an upgrade message)?

Ah, well, the issue is that one could end up with two actors. I.e.:

1. User A sends to the account's f1 address.
2. User B sends to the account's f4 address.

At this point we'd have an account (f1) and an embryo (f4). With bind, we'd be able to merge the embryo into the account. Without bind, there's no way to go from two actors to one.

[Stebalien]

If not this, what functionality do you envision the embryo having? Was it only "to be replaced by Bind4"?

Except in this "merge" case, I expect new actors to be deployed over embryos. The merge case was... rather special.

[anorth]

I think it's implied, and some of it in the comments, but it would have helped me to see an explicit proposal for predictable addresses. You've kinda covered it in "counterfactual interactions", but that is only one use case for predictable addresses. I would like to see:

• Explicit statement that this proposal would replace discussion Predictable actor address generation for wallet contracts, state channels (aka CREATE2) #379
• Address my concern that predictable addresses couldn't receive user-programmed assets by using f4 instead of my proposal which embedded into the f2 address space

[Stebalien]

Explicit statement

Done.

Address my concern that predictable addresses couldn't receive user-programmed assets by using f4 instead of my proposal which embedded into the f2 address space

Which specific concern? That's what the "counterfactual interactions" section is supposed to cover, so I'm not sure what else to write.

[Schwartz10]

Generally in favor of this proposal, still trying to wrap my head around certain parts. Zooming out a bit and thinking about use cases, I think it's important to meet the following criteria:

• An address scheme should make it easier for Filecoin block explorers and indexers to handle alternative runtimes
• An ethereum wallet should be able to begin receiving and sending $FIL with no additional messages required
• Solidity smart contracts need stable, re-org proof addresses for access control and permissioning

This proposal certainly meets the first point, but I'm still trying to figure out more about the second 2

[Stebalien]

An ethereum wallet should be able to begin receiving and sending $FIL with no additional messages required

This will require additional support from the abstract accounts proposal.

Solidity smart contracts need stable, re-org proof addresses for access control and permissioning

This proposal allows us to compute Ethereum addresses (CREATE, CREATE2, account addresses, etc.) as described in the Ethereum paper, so that shouldn't be a problem.

[mriise]

Can a namespace bind multiple addresses to the same code CID?

[Stebalien]

Addresses are bound to actors, not code CIDs.

[mriise]

ah.

If the target f4 address is unassigned, Bind4 will assign it to the specified actor and return.

If the target f4 subaddress is unassigned in the given namespace, Bind4 will assign it to the specified actor and return.
?

[Stebalien]

The f4 address includes the namespace.

[mriise]

Yes, sorry I wasn't clear. The way it is written now, Bind4 will let namespace managers bind any number of subaddresses to an actor (without their permission). Correct?

[Stebalien]

Yes.

[steven004]

the base32-encoded sub-address

Could we let the name management actor define how to encode the sub-address, so that we could use different encoding method for different purpose.

It would be really great if the f432 (or f460 as I suggested) address shows the same sub-address as its corresponding Eth address, i.e. hex. When it comes to BTC, base58 is used to keep the addresses the same too.

[Stebalien]

I'd love to but that would require reading chain state (possibly executing wasm) to decode an address, which isn't really an option for most tooling.

Instead, I expect tooling to handle things like this internally. E.g., a Filecoin client might recognize an address starting with 0x and internally convert it into an f4 address.

[steven004]

I think it does not really require reading chain state to decode, especially for well-known name-management-actors.
When a name-management actor is immutable (it should be, I think), the encoding method is fixed, then, the tooling and API level service could do the encode/decode work by executing the same logic. And for new introduced name-management actors, there is always a way to call a method of the actor for encoding, which is also good.

An implicit advantage of this is that checksum is usually included in the sub-address, so that we do not need to consider it for the whole address.

In this way, the f4 address class is like a super class, and is extensible to contain sub-classes.

[Stebalien]

But it still depends on chain state at some point. I think it's important to have a "universal" format that doesn't depend on chain state at all. That way I can create a simple standalone library, tool, etc. that can encode/decode addresses.

Again, for "well known" address formats, I expect tools will support address-specific encodings by convention. But that wouldn't necessarily be the "portable" format.

[Stebalien]

Proposed changes (before I make them to the draft)

1. Remove Bind4 and redirection (due to the complexity/ambiguity of actors having multiple ID addresses). We'll work around this limitation in the clients.
2. Add the f4 (and potentially add the f2, but I'm not sure if this really matters?) addresses to the root actor object for easy reverse-lookup. This wasn't possible with Bind4 because we might end up mapping multiple f4 addresses onto a single actor. But there's little reason not to do this now.

[Stebalien]

cc @anorth @raulk

[anorth]

Thanks.

What's the main motivation for (2)? Some reasons not to do it might include:

• locks us out of design space for the future where a stronger motivation to support multiple mappings might emerge
• adds cost to every method invocation (including internal sends) to load the address, even when the address is not needed

The Account actor already stores the f1/3 address in state explicitly, and others that need it could do similarly.

[Stebalien]

The EVM actor needs to know the Ethereum address of the caller. I have three options:

1. Have the caller send its EVM address along with the message. The receiver could then call validate_immediate_caller_is to validate this.
2. Store the f4 address in the state and:
   • Call back into the caller to ask it for the address.
   • Somehow read the parent's state go ask for the address.
3. Store the f4 address in the actor's root object (this proposal), provide a syscall to look it up.

[Stebalien]

So, not being able to just "lookup" an actor's address by ID is pretty annoying:

• The actor must take the address in the constructor if it wants to be able to use it later.
  • At a minimum, this is mildly annoying.
  • There may be cases where the caller doesn't know the target actor's final address on construction.
• The actor must validate any addresses passed into the constructor. IMO, that's a pretty unfortunate footgun.

While actors likely don't need their f2 addresses, it would be really convenient to include the "predictable" address (f1/f3/f4) in the root actor object.

[anorth]

Yeah, ok you convinced me.