Allow Native Contracts to be updated#2942
Merged
Conversation
shargon
commented
Nov 5, 2023
vncoelho
reviewed
Nov 6, 2023
vncoelho
reviewed
Nov 6, 2023
vncoelho
reviewed
Nov 6, 2023
vncoelho
reviewed
Nov 6, 2023
Contributor
|
@shargon does this native update still require a resync? |
vncoelho
reviewed
Nov 6, 2023
Member
vncoelho
left a comment
There was a problem hiding this comment.
I started reviewing, @shargon,
The changes looks good and compact.
I still did not reach the part where we can call functions from previous versions while re-syncing. Can you pin that for me?
I will soon be back to the code and, then, test it. It will require some good attention.
Merged
Member
Author
In this version I think that is not required. But I want to remove |
shargon
commented
Nov 6, 2023
vncoelho
reviewed
Nov 6, 2023
vncoelho
reviewed
Nov 6, 2023
Member
Author
|
@superboyiii I promise that now it will work :) |
Member
|
@shargon All feature works well on my privatenet now. To ensure everything compatible, I will re-check storage on mainnet. Give me 1 more day. |
Member
Author
|
@neo-project/core is reviewed? |
This was referenced Feb 22, 2024
vncoelho
approved these changes
Feb 22, 2024
Member
vncoelho
left a comment
There was a problem hiding this comment.
Since I reviewed I think it is not changed
Member
Author
|
@superboyiii ready? |
superboyiii
approved these changes
Feb 23, 2024
Member
superboyiii
left a comment
There was a problem hiding this comment.
Mainnet data is compatible.
AnnaShaleva
added a commit
to nspcc-dev/neo-go
that referenced
this pull request
Apr 9, 2024
Ported as a part of neo-project/neo#2942. Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
AnnaShaleva
added a commit
to nspcc-dev/neo-go
that referenced
this pull request
Apr 9, 2024
Ported as a part of neo-project/neo#2942. Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
10 tasks
AnnaShaleva
added a commit
to nspcc-dev/neo-go
that referenced
this pull request
Apr 18, 2024
Ported as a part of neo-project/neo#2942. Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
AnnaShaleva
added a commit
to nspcc-dev/neo-go
that referenced
this pull request
Apr 18, 2024
Ported as a part of neo-project/neo#2942. Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
AnnaShaleva
added a commit
to nspcc-dev/neo-go
that referenced
this pull request
Apr 18, 2024
Ported as a part of neo-project/neo#2942. Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
AnnaShaleva
added a commit
to nspcc-dev/neo-go
that referenced
this pull request
Apr 25, 2024
Ported as a part of neo-project/neo#2942. Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
AnnaShaleva
added a commit
that referenced
this pull request
Apr 23, 2025
Problem:
Consider a hardfork (Echidna in our case) that is:
1. Explicitly ommitted from the node configuration;
2. Given the fact that the set of previous hardforks are explicitly enabled
in the node configuration.
The problem is that this hardfork is treated as "enabled from genesis"
by `IsInitializeBlock` function.
This problem is discovered when running N3 mainnet/testnet node with the default
configuration on the current master. This behaviour leads to unexected
Echidna-related changes being included into the node state starting from genesis
block. Here are some data:
Hardforks configuration that is used in config.json file:
```
"Hardforks": {
"HF_Aspidochelone": 210000,
"HF_Basilisk": 2680000,
"HF_Cockatrice": 3967000,
"HF_Domovoi": 4144000
},
```
Genesis block state difference between the current master and 3.7 version:
```
Processing directory BlockStorage_0
file BlockStorage_0/dump-block-0.json: block 0, changes length mismatch: 34 vs 41
```
In particular, there are 7 extra storage items stored in genesis. All
these changes relate to new functionality added in Echidna hardfork
(Policy extensions, Notary contract and etc.):
```
{
"id": -7,
"key": "+f///xQi",
"state": "Added",
"value": "gJaYAA=="
},
{
"id": -7,
"key": "+f///xU=",
"state": "Added",
"value": "mDo="
},
{
"id": -7,
"key": "+f///xY=",
"state": "Added",
"value": "gBY="
},
{
"id": -7,
"key": "+f///xc=",
"state": "Added",
"value": "gBQg"
},
{
"id": -1,
"key": "/////wg77DUxEZu6123QRJILDebDGU/hwQ==",
"state": "Added",
"value": "QAUhAfYhACgUO+w1MRGbutdt0ESSCw3mwxlP4cEohk5FRjNuZW8tY29yZS12My4wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4EEEa93tnQBBBGvd7Z0AQQRr3e2dAEEEa93tnQBBBGvd7Z0AQQRr3e2dAEEEa93tnQBBBGvd7Z0CdOC1CQQgoBk5vdGFyeUAASABAASgGTkVQLTI3QQJACEEFKAliYWxhbmNlT2ZAAUECKAdhY2NvdW50IQEUIQERIQAgAUEFKAxleHBpcmF0aW9uT2ZAAUECKAdhY2NvdW50IQEUIQERIQEHIAFBBSgZZ2V0TWF4Tm90VmFsaWRCZWZvcmVEZWx0YUAAIQERIQEOIAFBBSgQbG9ja0RlcG9zaXRVbnRpbEACQQIoB2FjY291bnQhARRBAigEdGlsbCEBESEBECEBFSAAQQUoDm9uTkVQMTdQYXltZW50QANBAigEZnJvbSEBFEECKAZhbW91bnQhARFBAigEZGF0YSEAIQL/ACEBHCAAQQUoGXNldE1heE5vdFZhbGlkQmVmb3JlRGVsdGFAAUECKAV2YWx1ZSEBESEC/wAhASMgAEEFKAZ2ZXJpZnlAAUECKAlzaWduYXR1cmUhARIhARAhASogAUEFKAh3aXRoZHJhd0ACQQIoBGZyb20hARRBAigCdG8hARQhARAhATEgAEAAQAFBAgAAQAAoBG51bGw="
},
{
"id": -1,
"key": "/////wz////2",
"state": "Added",
"value": "O+w1MRGbutdt0ESSCw3mwxlP4cE="
},
{
"id": -10,
"key": "9v///wo=",
"state": "Added",
"value": "jAA="
},
```
Solution:
Since EnsureOmittedHardforks is always applied to configured hardfork
values, this function ensures that all omitted hardfork heights are set
to 0. We don't need additional checks anywhere and can rely on
settings.Hardforks explicitly after that. If hardfork is not in
settings.Hardforks then it is disabled.
Originaly it was an intention of #2942 (comment),
but somehow we missed this bug during review.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
AnnaShaleva
added a commit
that referenced
this pull request
Apr 23, 2025
Problem:
Consider a hardfork (Echidna in our case) that is:
1. Explicitly ommitted from the node configuration;
2. Given the fact that the set of previous hardforks are explicitly enabled
in the node configuration.
The problem is that this hardfork is treated as "enabled from genesis"
by `IsInitializeBlock` function.
This problem is discovered when running N3 mainnet/testnet node with the default
configuration on the current master. This behaviour leads to unexected
Echidna-related changes being included into the node state starting from genesis
block. Here are some data:
Hardforks configuration that is used in config.json file (given this
config, Echidna should be treated as disabled):
```
"Hardforks": {
"HF_Aspidochelone": 210000,
"HF_Basilisk": 2680000,
"HF_Cockatrice": 3967000,
"HF_Domovoi": 4144000
},
```
Genesis block state difference between the current master and 3.7 version:
```
Processing directory BlockStorage_0
file BlockStorage_0/dump-block-0.json: block 0, changes length mismatch: 34 vs 41
```
In particular, there are 7 extra storage items stored in genesis. All
these changes relate to new functionality added in Echidna hardfork
(Policy extensions, Notary contract and etc.):
```
{
"id": -7,
"key": "+f///xQi",
"state": "Added",
"value": "gJaYAA=="
},
{
"id": -7,
"key": "+f///xU=",
"state": "Added",
"value": "mDo="
},
{
"id": -7,
"key": "+f///xY=",
"state": "Added",
"value": "gBY="
},
{
"id": -7,
"key": "+f///xc=",
"state": "Added",
"value": "gBQg"
},
{
"id": -1,
"key": "/////wg77DUxEZu6123QRJILDebDGU/hwQ==",
"state": "Added",
"value": "QAUhAfYhACgUO+w1MRGbutdt0ESSCw3mwxlP4cEohk5FRjNuZW8tY29yZS12My4wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4EEEa93tnQBBBGvd7Z0AQQRr3e2dAEEEa93tnQBBBGvd7Z0AQQRr3e2dAEEEa93tnQBBBGvd7Z0CdOC1CQQgoBk5vdGFyeUAASABAASgGTkVQLTI3QQJACEEFKAliYWxhbmNlT2ZAAUECKAdhY2NvdW50IQEUIQERIQAgAUEFKAxleHBpcmF0aW9uT2ZAAUECKAdhY2NvdW50IQEUIQERIQEHIAFBBSgZZ2V0TWF4Tm90VmFsaWRCZWZvcmVEZWx0YUAAIQERIQEOIAFBBSgQbG9ja0RlcG9zaXRVbnRpbEACQQIoB2FjY291bnQhARRBAigEdGlsbCEBESEBECEBFSAAQQUoDm9uTkVQMTdQYXltZW50QANBAigEZnJvbSEBFEECKAZhbW91bnQhARFBAigEZGF0YSEAIQL/ACEBHCAAQQUoGXNldE1heE5vdFZhbGlkQmVmb3JlRGVsdGFAAUECKAV2YWx1ZSEBESEC/wAhASMgAEEFKAZ2ZXJpZnlAAUECKAlzaWduYXR1cmUhARIhARAhASogAUEFKAh3aXRoZHJhd0ACQQIoBGZyb20hARRBAigCdG8hARQhARAhATEgAEAAQAFBAgAAQAAoBG51bGw="
},
{
"id": -1,
"key": "/////wz////2",
"state": "Added",
"value": "O+w1MRGbutdt0ESSCw3mwxlP4cE="
},
{
"id": -10,
"key": "9v///wo=",
"state": "Added",
"value": "jAA="
},
```
Solution:
Since EnsureOmittedHardforks is always applied to configured hardfork
values, this function ensures that all omitted hardfork heights are set
to 0. We don't need additional checks anywhere and can rely on
settings.Hardforks explicitly after that. If hardfork is not in
settings.Hardforks then it is disabled.
Originaly it was an intention of #2942 (comment),
but somehow we missed this bug during review.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
10 tasks
shargon
added a commit
that referenced
this pull request
Apr 25, 2025
Problem:
Consider a hardfork (Echidna in our case) that is:
1. Explicitly ommitted from the node configuration;
2. Given the fact that the set of previous hardforks are explicitly enabled
in the node configuration.
The problem is that this hardfork is treated as "enabled from genesis"
by `IsInitializeBlock` function.
This problem is discovered when running N3 mainnet/testnet node with the default
configuration on the current master. This behaviour leads to unexected
Echidna-related changes being included into the node state starting from genesis
block. Here are some data:
Hardforks configuration that is used in config.json file (given this
config, Echidna should be treated as disabled):
```
"Hardforks": {
"HF_Aspidochelone": 210000,
"HF_Basilisk": 2680000,
"HF_Cockatrice": 3967000,
"HF_Domovoi": 4144000
},
```
Genesis block state difference between the current master and 3.7 version:
```
Processing directory BlockStorage_0
file BlockStorage_0/dump-block-0.json: block 0, changes length mismatch: 34 vs 41
```
In particular, there are 7 extra storage items stored in genesis. All
these changes relate to new functionality added in Echidna hardfork
(Policy extensions, Notary contract and etc.):
```
{
"id": -7,
"key": "+f///xQi",
"state": "Added",
"value": "gJaYAA=="
},
{
"id": -7,
"key": "+f///xU=",
"state": "Added",
"value": "mDo="
},
{
"id": -7,
"key": "+f///xY=",
"state": "Added",
"value": "gBY="
},
{
"id": -7,
"key": "+f///xc=",
"state": "Added",
"value": "gBQg"
},
{
"id": -1,
"key": "/////wg77DUxEZu6123QRJILDebDGU/hwQ==",
"state": "Added",
"value": "QAUhAfYhACgUO+w1MRGbutdt0ESSCw3mwxlP4cEohk5FRjNuZW8tY29yZS12My4wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4EEEa93tnQBBBGvd7Z0AQQRr3e2dAEEEa93tnQBBBGvd7Z0AQQRr3e2dAEEEa93tnQBBBGvd7Z0CdOC1CQQgoBk5vdGFyeUAASABAASgGTkVQLTI3QQJACEEFKAliYWxhbmNlT2ZAAUECKAdhY2NvdW50IQEUIQERIQAgAUEFKAxleHBpcmF0aW9uT2ZAAUECKAdhY2NvdW50IQEUIQERIQEHIAFBBSgZZ2V0TWF4Tm90VmFsaWRCZWZvcmVEZWx0YUAAIQERIQEOIAFBBSgQbG9ja0RlcG9zaXRVbnRpbEACQQIoB2FjY291bnQhARRBAigEdGlsbCEBESEBECEBFSAAQQUoDm9uTkVQMTdQYXltZW50QANBAigEZnJvbSEBFEECKAZhbW91bnQhARFBAigEZGF0YSEAIQL/ACEBHCAAQQUoGXNldE1heE5vdFZhbGlkQmVmb3JlRGVsdGFAAUECKAV2YWx1ZSEBESEC/wAhASMgAEEFKAZ2ZXJpZnlAAUECKAlzaWduYXR1cmUhARIhARAhASogAUEFKAh3aXRoZHJhd0ACQQIoBGZyb20hARRBAigCdG8hARQhARAhATEgAEAAQAFBAgAAQAAoBG51bGw="
},
{
"id": -1,
"key": "/////wz////2",
"state": "Added",
"value": "O+w1MRGbutdt0ESSCw3mwxlP4cE="
},
{
"id": -10,
"key": "9v///wo=",
"state": "Added",
"value": "jAA="
},
```
Solution:
Since EnsureOmittedHardforks is always applied to configured hardfork
values, this function ensures that all omitted hardfork heights are set
to 0. We don't need additional checks anywhere and can rely on
settings.Hardforks explicitly after that. If hardfork is not in
settings.Hardforks then it is disabled.
Originaly it was an intention of #2942 (comment),
but somehow we missed this bug during review.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Co-authored-by: Jimmy <jinghui@wayne.edu>
Co-authored-by: Shargon <shargon@gmail.com>
cschuchardt88
pushed a commit
to cschuchardt88/neo
that referenced
this pull request
Jun 8, 2025
Problem:
Consider a hardfork (Echidna in our case) that is:
1. Explicitly ommitted from the node configuration;
2. Given the fact that the set of previous hardforks are explicitly enabled
in the node configuration.
The problem is that this hardfork is treated as "enabled from genesis"
by `IsInitializeBlock` function.
This problem is discovered when running N3 mainnet/testnet node with the default
configuration on the current master. This behaviour leads to unexected
Echidna-related changes being included into the node state starting from genesis
block. Here are some data:
Hardforks configuration that is used in config.json file (given this
config, Echidna should be treated as disabled):
```
"Hardforks": {
"HF_Aspidochelone": 210000,
"HF_Basilisk": 2680000,
"HF_Cockatrice": 3967000,
"HF_Domovoi": 4144000
},
```
Genesis block state difference between the current master and 3.7 version:
```
Processing directory BlockStorage_0
file BlockStorage_0/dump-block-0.json: block 0, changes length mismatch: 34 vs 41
```
In particular, there are 7 extra storage items stored in genesis. All
these changes relate to new functionality added in Echidna hardfork
(Policy extensions, Notary contract and etc.):
```
{
"id": -7,
"key": "+f///xQi",
"state": "Added",
"value": "gJaYAA=="
},
{
"id": -7,
"key": "+f///xU=",
"state": "Added",
"value": "mDo="
},
{
"id": -7,
"key": "+f///xY=",
"state": "Added",
"value": "gBY="
},
{
"id": -7,
"key": "+f///xc=",
"state": "Added",
"value": "gBQg"
},
{
"id": -1,
"key": "/////wg77DUxEZu6123QRJILDebDGU/hwQ==",
"state": "Added",
"value": "QAUhAfYhACgUO+w1MRGbutdt0ESSCw3mwxlP4cEohk5FRjNuZW8tY29yZS12My4wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4EEEa93tnQBBBGvd7Z0AQQRr3e2dAEEEa93tnQBBBGvd7Z0AQQRr3e2dAEEEa93tnQBBBGvd7Z0CdOC1CQQgoBk5vdGFyeUAASABAASgGTkVQLTI3QQJACEEFKAliYWxhbmNlT2ZAAUECKAdhY2NvdW50IQEUIQERIQAgAUEFKAxleHBpcmF0aW9uT2ZAAUECKAdhY2NvdW50IQEUIQERIQEHIAFBBSgZZ2V0TWF4Tm90VmFsaWRCZWZvcmVEZWx0YUAAIQERIQEOIAFBBSgQbG9ja0RlcG9zaXRVbnRpbEACQQIoB2FjY291bnQhARRBAigEdGlsbCEBESEBECEBFSAAQQUoDm9uTkVQMTdQYXltZW50QANBAigEZnJvbSEBFEECKAZhbW91bnQhARFBAigEZGF0YSEAIQL/ACEBHCAAQQUoGXNldE1heE5vdFZhbGlkQmVmb3JlRGVsdGFAAUECKAV2YWx1ZSEBESEC/wAhASMgAEEFKAZ2ZXJpZnlAAUECKAlzaWduYXR1cmUhARIhARAhASogAUEFKAh3aXRoZHJhd0ACQQIoBGZyb20hARRBAigCdG8hARQhARAhATEgAEAAQAFBAgAAQAAoBG51bGw="
},
{
"id": -1,
"key": "/////wz////2",
"state": "Added",
"value": "O+w1MRGbutdt0ESSCw3mwxlP4cE="
},
{
"id": -10,
"key": "9v///wo=",
"state": "Added",
"value": "jAA="
},
```
Solution:
Since EnsureOmittedHardforks is always applied to configured hardfork
values, this function ensures that all omitted hardfork heights are set
to 0. We don't need additional checks anywhere and can rely on
settings.Hardforks explicitly after that. If hardfork is not in
settings.Hardforks then it is disabled.
Originaly it was an intention of neo-project#2942 (comment),
but somehow we missed this bug during review.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Co-authored-by: Jimmy <jinghui@wayne.edu>
Co-authored-by: Shargon <shargon@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Close #2932
Can be tested with #2925