Address resolution/initialization warts

filecoin-project / actors-utils

Collection of libraries to implement common patterns and standards on the Filecoin Virtual Machine

Other

15 stars 13 forks source link

Address resolution/initialization warts #147

Open Stebalien opened 2 years ago

Stebalien commented 2 years ago

The current address initialization/resolution logic has a few warts:

resolve_id doesn't guarantee that the ID address is actually assigned. This isn't a huge issue, but can be very confusing.
With FIP0048, initialize_account is no longer accurate. It will need to be something like initialize_address.
Users should never call initialize_address/initialize_account. They should instead call resolve_or_create/resolve_or_init.

IMO, we should have two methods:

resolve_existing that asserts that the target ID actually exists.
resolve_or_init that tries to create the target ID.

We can also just rename initialize_account to initialize_address...

anorth commented 2 years ago

resolve_id calls actor::resolve_address which, if I recall correctly implements the semantics that "If the argument is an ID address it is returned directly." Am I correct that one of your complaints is you don't want that behaviour?

If we want to fix it, I'd say the VM should change. But I would warn that this is very common (almost every method call) and so the pass-through behaviour probably makes quite a difference, vs a HAMT lookup.

Stebalien commented 2 years ago

resolve_id calls actor::resolve_address which, if I recall correctly implements the semantics that "If the argument is an ID address it is returned directly." Am I correct that one of your complaints is you don't want that behaviour?

Basically, yes.

But I would warn that this is very common (almost every method call) and so the pass-through behaviour probably makes quite a difference, vs a HAMT lookup.

Yeah... I agree. I've just talked with users who have been surprised.

Honestly, it probably isn't worth changing for the reasons you're stating.