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

Specifying NativeContract ActiveBlockIndex in code will be an issue for privatenets #2131

Closed
devhawk opened this issue Dec 10, 2020 · 2 comments · Fixed by #2141
Closed

Specifying NativeContract ActiveBlockIndex in code will be an issue for privatenets #2131

devhawk opened this issue Dec 10, 2020 · 2 comments · Fixed by #2141
Assignees
Labels
discussion Initial issue state - proposed but not yet accepted

Comments

@devhawk
Copy link
Contributor

devhawk commented Dec 10, 2020

Summary or problem description
In #2119, NativeContract got a new abstract property called ActiveBlockIndex. This property specifies when a given contract is valid. However, this value of this property is going to be network dependent. Even between mainnet and testnet, new native contracts will be enabled at different block heights. We need a mechanism to specify ActiveBlockIndex of a contract in protocol configuration

Neo Version

  • Neo 3

Where in the software does this update applies to?

  • Native Contracts
@devhawk devhawk added the discussion Initial issue state - proposed but not yet accepted label Dec 10, 2020
@roman-khimov
Copy link
Contributor

Maybe we can do that just for new ones, treating the set we already have as always enabled (since block 0).

@devhawk
Copy link
Contributor Author

devhawk commented Dec 11, 2020

Maybe we can do that just for new ones, treating the set we already have as always enabled (since block 0).

Certainly, the ones we have now should always be enabled. However, I do wonder about how updates will be handled. If we want to update one of the native contracts, will there be a specific block where we indicate we want the new behavior to be enabled?

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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants