search

filecoin-project / ref-fvm

Reference implementation of the Filecoin Virtual Machine
https://fvm.filecoin.io/
Other
384 stars 139 forks source link

Fate of the ResolveAddress syscall #368

Closed anorth closed 1 year ago

anorth commented 2 years ago

I think I saw a comment somewhere from @Stebalien that the ResolveAddress syscall should be removed, and instead be an explicit method send to the InitActor. It's been omitted in new gas model discussions.

I advocate for retaining the syscall, and pricing it in expectation that the resolutions are cached in memory with a pretty high hit rate.

During the original VM development it was noted that actor address resolution by looking up the Init actor's HAMT was a significant contributor to overall block validation times. Resolution happens during top-level message dispatch, and also many internal sends (except to singletons). Since address->ID is constant for any address I believe that Lotus and other implementations cache it. Dispatch and sends were priced accordingly.

If we remove the syscall, then actors will be forced to take an expensive path to resolve addresses, when a cheap one exists already.

raulk commented 2 years ago

Similar heuristics apply to the ideas around an eventual naming registry (or a standard to create naming registries). I bring them up here because from a developer pespective, it would be unfortunate to have to identify if what's being provided as input is a name, an actor ID or an actor address, and have to take different code paths as a result.

In fact, one could generalise the address => ActorID resolution path as an immutable name resolution path.

A well-designed naming system would integrate deeply with the protocol such that every place where an address or an ActorID can be used, a name can be specified instead. As a dev, I would expect that resolve_address syscall would take any of those inputs and return an ActorID, or an error.

On the other hand, I think we do want to enable a multi-registry environment where users can deploy their own naming registries. These would be separate actors, so if we want to obviate the message dispatch cost (which IMO we do), there needs to be a fast path mechanism for the resolution syscall to efficiently interact with a naming registry actor.

raulk commented 2 years ago

Related: https://github.com/filecoin-project/FIPs/discussions/297

Stebalien commented 2 years ago

My goal, really, was to avoid having the FVM "understand" the init actor's state. Unfortunately, you're probably right that we'll need a syscall to facilitate caching.

However, I would still like to have the resolve_address syscall call a method on the init actor, when the address isn't cached, instead of reading the actor state directly.

Stebalien commented 1 year ago

If/when we revisit this, it'll likely be a FIP discussion.