Support for storage based library linking.

[pipermerriam]

What is wrong

The current lockfile spec cannot express a library dependency for which the library address resides in storage rather than bytecode.

Consider something like the parity wallet, or a generic interface contract which delegates some or all execution to a contract who's address resides in storage.

How can it be fixed

Yet unsolved, but it probably needs to have the following properties.

• Specify mapping of storage slot as hex encoded unsigned 256 bit integer to existing format for referencing linking addresses.

[pipermerriam]

I'm closing this. In the process of trying to write up the case for this to exist, I talked myself out of it and no longer think it's necessary.

The use case I was considering was based on addresses that proxy all functionality via delegatecall to some address in storage. In theory, you'd want to verify that the contract you are linking against is delegating calls to the correct address. However, since this address is in storage, I think this would both provide a false sense of security as well as weak assurance that you are linking against the correct library.

I'm filing this away as out-of-scope and not something the current spec will try to deal with.