Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Tracked by #3611
dryruner opened this issue Oct 12, 2021 · 6 comments · May be fixed by #3717
Open
Tracked by #3611

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

dryruner opened this issue Oct 12, 2021 · 6 comments · May be fixed by #3717

Comments

@dryruner
Copy link

dryruner commented Oct 12, 2021

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:
image
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)
  }
}
  1. 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
Copy link
Author

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

@joshuahannan
Copy link
Member

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
Copy link
Member

@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:

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

@bjartek
Copy link
Contributor

bjartek commented Oct 23, 2021

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

@10thfloor
Copy link
Contributor

+1

@bluesign
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants