Support referencing duplicate contracts (deployed to different accounts) in cadence context

[dryruner]

Issue To Be Solved

Here's an example: https://play.onflow.org/2d6bf889-ac32-4de4-9a79-a25ddf1d5236?type=tx&id=73c0651f-3aba-4150-81ea-5ccaa4b20c61

The same (duplicate code) contract deployed to 0x02 and 0x03, and in the transaction, I'm trying to reference the two duplicated contracts:
However, it gives an error saying "cannot redeclare contract: FUSD is already declared".

I think this restriction here doesn't make any sense. Yes the contract code is duplicated, but they're deployed to different accounts so can carry with different states / storage spaces.

We should allow referencing these contracts in the cadence environment, either through import .. as ... alias, or other developer-friendly ways. (See suggested solution)

Suggested Solution

1. Import .. as .. alias:

import FUSD as FUSD1 from 0x02
import FUSD as FUSD2 from 0x03

transaction {
  prepare(acct: AuthAccount) {
    let typeFUSD = Type<FUSD1>()
    let typeKibble = Type<FUSD2>()
    log(typeFUSD == typeKibble)
    log(typeFUSD.identifier)
    log(typeKibble.identifier)
  }
}

2. Maybe other developer-friendly way?

Additional Comments:

• Why I think this feature is necessary? Let's say here's a scenario like: since each uniswap trading pool shares the same code template from UniswapPair.cdc and deployed as UniswapPair contract. Now say we have 2 pools: FlowUSDT pool and FUSDUSDT pool. Due to the above mentioned error, current developers / arbitrageurs cannot reference these 2 pools in the same contract / transaction code. (I know Blocto workarounds this by naming the two pools with different names - but this is silly! Duplicating code adds technical debt and maintainance efforts with no benefit - it also lost permissionless pool deployment and composability then.)

I think this feature will be good for any pool-based defi projects build on flow, and will be beneficial to flow ecosystem composibility as a whole.

• Any comments against this feature is also welcome, let's debate on the pros and cons then :).

[dryruner]

Hi @turbolent , do you have any comment on this feature request?

[joshuahannan]

Hey @dryruner. It was good to talk to you during office hours. We have this contributing guide, which is a very basic guide to best practices for contributing to the Cadence codebase, but I don't think there is a thorough explanation of the architecture for you to look at.

[turbolent]

@dryruner I think this would be a useful feature to have. It would need changes in the checker and interpreter.

As for contributing documents, we currently don't have much, but these presentations and diagrams should be helpful:

• https://github.com/onflow/cadence/blob/master/docs/Cadence%20Implementation.pdf
• https://github.com/onflow/cadence/blob/master/docs/Cadence%20-%20Implementation%2C%20Present%20and%20Future.pdf
• https://github.com/onflow/cadence/blob/master/runtime/runtime.png

I'm also happy to go over the codebase and point you at the right places if you are looking to implement this.

[bjartek]

This would be a very nice feature to have if you want to migrate from one version of a contract to another.

[10thfloor]

+1

[bluesign]

Anyone working on this? if not I would like to try, would be good for me to learn little parser & interpreter :)

[j1010001]

Waiting for the Cadence WG sync, once the FLIP is approved we can merge the PR and close.

[j1010001]

Sync with DevEx team to ensure tools supports this before it is merged/released Support import aliases in compiler (see https://github.com/onflow/cadence/issues/3804)

[j1010001]

Discussed with @chasefleming today - we will merge the feature on the Cadence side, the tooling does not support this yet but adoption will not happen immediately so we have time to add tooling support after Cadence changes are merged.