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

Improve native contract update mechanism #3210

Closed
AnnaShaleva opened this issue May 3, 2024 · 2 comments · Fixed by #3362
Closed

Improve native contract update mechanism #3210

AnnaShaleva opened this issue May 3, 2024 · 2 comments · Fixed by #3362
Labels
discussion Initial issue state - proposed but not yet accepted enhancement Type - Changes that may affect performance, usability or add new features to existing modules. P1 High Priority: Targeting The Next Release
Milestone

Comments

@AnnaShaleva
Copy link
Member

Summary or problem description
Native contract update mechanism introduced in #2942 allows to enable new methods and events starting from some hardfork, and it's good. However, we're missing the following functionality:

  • update method's signature (change the parameters name, add/remove parameters from method) without introducing new method
  • update event's name or parameter list starting from some hardfork
  • exclude method/event starting from some hardfork
  • destroy native contract

Without this functionality implemented, changes like #3209 will inevitably require node resync, so we consider this functionality a useful one.

Do you have any solution you want to propose?
Almost all cases may be solved with ActiveTill field added to the native contract/method/event. The handler logic for this field should be similar to the logic of the following fields (with single adjustment: ActiveTill prevents contract/method/event from being active):

public virtual Hardfork? ActiveIn { get; } = null;

public Hardfork? ActiveIn { get; init; } = null;

public Hardfork? ActiveIn { get; init; } = null;

Another option was suggested by @roman-khimov (correct me, if I'm wrong, please): we may have a set of separate classes for every version of native contract. Starting from every hardfork, a specific version of the contract should be used (if specified).

Where in the software does this update applies to?

  • Native contracts
@AnnaShaleva AnnaShaleva added the discussion Initial issue state - proposed but not yet accepted label May 3, 2024
@AnnaShaleva AnnaShaleva added the enhancement Type - Changes that may affect performance, usability or add new features to existing modules. label May 3, 2024
@roman-khimov roman-khimov added this to the v3.8.0 milestone May 3, 2024
@shargon
Copy link
Member

shargon commented May 6, 2024

I think that we can add it when needed

@AnnaShaleva AnnaShaleva mentioned this issue May 15, 2024
12 tasks
@AnnaShaleva
Copy link
Member Author

A part of this issue (methods' "active till") is implemented in the #3234. We need to implement events' "active till" (ref. #3234 (comment)) and improve ContractMethodAttribute constructor (ref. #3234 (comment)).

AnnaShaleva added a commit to nspcc-dev/neo-go that referenced this issue May 17, 2024
Port a part of neo-project/neo#3210.
A part of #3440.

Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
@vncoelho vncoelho added the P1 High Priority: Targeting The Next Release label Jun 18, 2024
@shargon shargon mentioned this issue Jun 27, 2024
15 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Initial issue state - proposed but not yet accepted enhancement Type - Changes that may affect performance, usability or add new features to existing modules. P1 High Priority: Targeting The Next Release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants