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 for legacy world contracts in migration + support for pre-manifest migration #1928

Closed
wraitii opened this issue May 5, 2024 · 5 comments
Assignees
Labels
bug Something isn't working sozo
Milestone

Comments

@wraitii
Copy link
Contributor

wraitii commented May 5, 2024

Describe the bug
Still experiencing some issues with the briq contract migration from a Dojo v0.3 to Dojo v0.7

Namely:

  1. the ModelRegistered struct was updated with new fields and the deserialisation of my events fails.
  2. The executor argument to the constructor was removed, but I have it in my deployment TX, thus the generated world address differs from the actual world address (my TX is https://starkscan.co/contract/0x059f31686991d7cac25a7d4844225b9647c89e3e1e2d03460dbc61e3fbfafc59#overview)
  3. The original_class_hash is set by default to the local class hash. This should probably be the remote class hash, if there is one, but it is furthermore broken: I have actually upgraded the world, so I would need to manually specify it.
  4. the base class hash suffers from the same problem, and thus is also broken.
  5. Because the contracts are unknown, they also have no registered base class, and so they default to the new base class, which is incorrect, so they are deployed to new addresses instead of upgrading in-place.
  6. The contract salt is incorrect: it uses the fully qualified name when my contracts used the short-name originally.
  7. The model comparison logic relies on conversion from snake_case (local models) to Pascal-case, for remote events. However, this fails with e.g. a model named ERC1155Balance, the snake-case is erc_1155_balance which gets converted to Erc1155Balance, and so the comparison fails. I think the comparison should be done in lowercase.

Points (1), (2), (6), (7) are going to remain problematic going forward, the rest should be fixed once I have a manifest set-up locally. It would be convenient to be able to "pull" the manifest first though.

To Reproduce

  • Compile the briq repo @ branch dojo_update_07 (updated to 0.7)
  • call sozo migrate plan --world 0x1ea16366a82e211a9b9045725309a5080c0260d5caf45c58836fc61b42501f5 --name briq_protocol
  • Note the problems

Suggestion of fixes
Point (1): Should probably handle both in-code somehow. Dojo doesn't actually use addresses for now.
Point (2): I think there's no good solution, IMO just add an explicit executor argument to the manifest, and if present use it - this is legacy support. Alternatively, "trust" the user world-address.
Points (3/4/5): not sure.
Point (6): Needs a parameter of some kind (at some point we discussed use-short-name?) or a parameter in the manifest of some kind.
Point (7): I suggest adding to_lowercase to WorldDiff L48 (model comparison)

@wraitii wraitii added the bug Something isn't working label May 5, 2024
@wraitii
Copy link
Contributor Author

wraitii commented May 5, 2024

I have a very dirty commit with the changes I've done to make it appear to work here: https://github.com/wraitii/dojo/tree/briq_upgrade_07_test

@lambda-0x
Copy link
Contributor

Point 1: is this for sozo events subcommand?
Point 3:

The original_class_hash is set by default to the local class hash.

by default this is expected behaviour, user need to override the original_class_hash using overlays since there isn't a generalized way to figure this out automatically.

Point 5: similar to point 3

It would be convenient to be able to "pull" the manifest first though.

we have opened an issue (#1921) for this but since the class_hash used during the first deployment isn't stored anywhere i am not sure how to fetch it automatically

Point 7: we noticed this before #1820 (comment) and it should be solved with #1629. But as a quick fix we can also compare them in lowercase, wdyt @glihm ?

@wraitii
Copy link
Contributor Author

wraitii commented May 6, 2024

Point 1: is this for sozo events subcommand?

No, solo migrate recreates the remote manifest using events.

Point 3:

The original_class_hash is set by default to the local class hash.
by default this is expected behaviour, user need to override the original_class_hash using overlays since there isn't a generalized way to figure this out automatically.

Will look into that, is there documentation already ?

It would be convenient to be able to "pull" the manifest first though.
we have opened an issue (#1921) for this but since the class_hash used during the first deployment isn't stored anywhere i am not sure how to fetch it automatically

I'm guessing events as well then, unless you plan on changing that?

@lambda-0x
Copy link
Contributor

Will look into that, is there documentation already ?

we recently merged this: dojoengine/book#264, let us know if its not clear or you have any other questions.

I'm guessing events as well then, unless you plan on changing that?

yeah, we where thinking to add that info in the world contract itself but its still understand discussion

@glihm glihm added the sozo label Jun 19, 2024
@glihm glihm changed the title [sozo] Support for legacy world contracts in migration + support for pre-manifest migration Support for legacy world contracts in migration + support for pre-manifest migration Jun 19, 2024
@glihm glihm added this to the 1.0.0 milestone Jun 19, 2024
@glihm glihm self-assigned this Jun 19, 2024
@glihm glihm modified the milestones: 1.0.0-alpha, 1.0.0-rc Jul 7, 2024
@glihm
Copy link
Collaborator

glihm commented Nov 8, 2024

With rc we are not able anymore to support legacy contract of those versions. Too much has changed in the contract and having backward compatibility would have been too much compromise on the new features.

Currently the best migration possible is migrating data with specific systems.

In the new world, the migrations will break less easily because:

  1. No more base contract, which avoid having to keep a mapping for addresses computation.
  2. Sozo no more requires local state to be saved to be consistent. Everything is available on-chain and can be reconstructed anytime without any local prior knowledge.

@glihm glihm closed this as completed Nov 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working sozo
Projects
None yet
Development

No branches or pull requests

3 participants