Dynamically resolving import addresses

[janezpodhostnik]

Issue To Be Solved

Hunting down addresses for the contracts you are supposed to be importing can be hard. You also have to use different addresses depending on which network we are on.

Suggested solution

This is a rough idea of a solution that just came to my mind...

Allow the import statement to resolve functions that return addresses. This would mean I could write something like:

import PackageManagerContract from 0x000123213
import FlowToken from PackageManagerContract.resolve("@flow.FlowToken")
import FungibleToken from PackageManagerContract.resolve("@flow.FungibleToken")
import SomeContract from PackageManagerContract.resolve("@someone.SomeContract")

The PackageManagerContract.resolve implementation could even have a version field which would resolve different versions to different addresses.

The PackageManagerContract would allow people to register their contract addresses.

Maybe there would be a provider for a "Resolver" contract that promises that all the contract they resolve are vetted...

[dete]

Yeah, this is such a tough problem. One the one hand, asking humans to copy around a bunch of hex digits is super annoying. On the other hand, a simple cache poisoning attack that maps to the wrong contract could be DISASTROUS resulting in an incredible amount of lost value.

[turbolent]

Adding such a feature would mean that the type checker needs to be able to evaluate the program to be able to type check it.

Allowing any value/expression as the import location is unlikely to be implementable, especially if it interacts with the rest of the program (e.g. refers to variables). However, one could imagine that the evaluation would be for a certain specific subset e.g. another contract/function, in another location (e.g. a package manager contract with a resolving function).

Adding such a feature is likely not worth the effort, given that other (off-chain) alternatives exist.