-
Notifications
You must be signed in to change notification settings - Fork 23
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
FLIP 282: Import of pre-Cadence 1.0 Programs #283
Conversation
I strongly support this FLIP. One side question, I was gonna bring up yesterday on the meeting but time ran out: As we will have pre 1.0 parser in the codebase, does that mean that contracts can still update to 1.0 if they want later? |
At the moment this is not possible, because the state migration for Cadence 1.0/Crescendo is implemented as "all-at once", and does not support individual contracts to be updated later. It might be feasible, but we have not investigated how individual contracts could be updated later. Especially the migration of links to capability controller and the entitlements migration makes this problematic. We would definitely need the pre-1.0 parser in the codebase for the pre-1.0 to 1.0 contract updatability checking (currently done during the migration). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also strongly support this.
I think there is an argument to be made for still supporting deposit and withdraw. I need to consider it more, but it seems like if a project is willing to let their contract break with Cadence 1.0, the concern about potentially overwriting any custom withdraw/deposit functionality might be overblown. IMO, losing access to that functionality completely is worse than losing access to some small custom logic in those functions, which probably only applies to <1% of contracts anyway.
Maybe if we are worried about overwriting custom withdraw/deposit functionality, we could do some sort of parsing of those functions to see if they just use the typical implementation and only overwrite them if they match the generic implementation.
Co-authored-by: Joshua Hannan <joshua.hannan@dapperlabs.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice write-up! I like the proposal, and particularly like the idea of this being a run-time recovery, rather than a one-off recovery during the migration. So the recovery can be improved later, and could support more features, and more contracts in future.
I've opened onflow/cadence#3505, which implements one of the suggested solutions to how programs could determine if a type (of a value) is defined in a recovered program, e.g. to avoid function calls (which will always fail): Add a new field For example, when working with a If this seems like a good idea, I can add it to the proposal. cc @austinkline |
Thanks everyone for the feedback! This FLIP has not received new comments in over 2 weeks, and had no updates since last breakout session. There has been no concerns and the feedback has been very positive, so we can consider this FLIP as approved! 🎉 |
@turbolent Would this be able to be modified to allow access to the There will still be some projects that accept that their contract is broken but would still like to be able to deploy new contracts for their users to own new NFTs that are the same ones they owned before, so it would be nice to be able to query these collections for their list of IDs. Will that be possible at all or no? |
@joshuahannan From a technical perspective that is definitely possible. In general, the proposal suggests to panic in all functions, as it is impossible to correctly convert pre-1.0 function implementations to 1.0. The current implementation of the recovered NFT contract can be found here: Could you please open an issue in flow-go? PRs are of course also very welcome |
Thank you! I'm glad that that should be possible. I created an issue and I can try to work on a PR soon once I get done with my current priorities. |
FLIP #282