-
Notifications
You must be signed in to change notification settings - Fork 1k
NEP-25 #4043
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
base: dev
Are you sure you want to change the base?
Conversation
This reverts commit d392f50.
- Document all implemented features and components - Add usage examples for different type definitions - Confirm backward compatibility with NEP-14 - Mark implementation as complete and tested
- Update FromStackItem_ShouldHandleNullFields test to include all 8 fields - Update ToStackItem_ShouldProduceNullFields test to expect 8 fields - Tests now match the actual ExtendedType implementation which uses 8 fields
@neo-project/core ready to review again |
Ping @neo-project/core |
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.
Looks good, your style is getting 💯 times better 👍 . Good call on RestServer
.
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.
Missing semantic checks is still the main problem.
if (ExtendedReturnType != null) | ||
{ | ||
item.Add(ExtendedReturnType.ToStackItem(referenceCounter)); | ||
} |
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.
Looks like a bit inconsistent encoding, we add NULL stackitem for missing NamedTypes
, but do not add it for missing ExtendedReturnType
. Should work both ways, but I'd prefer some unified approach to new fields. Same thing with other types.
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 think it's solved now
|
||
internal StackItem ToStackItem(IReferenceCounter referenceCounter, Struct array) | ||
{ | ||
array.Add((byte)Type); |
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.
What do you think of using map type for stack item encoding? Array-based encoding always requires 8 elements, but in practice the most typical number of active elements is 2 (type+smth), more rarely 3, in a map that'd be 4-6 stack items. I'm a little concerned about big manifests (like in #3802).
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.
Done
var startIndex = 0; | ||
Type = (ContractParameterType)(byte)array[startIndex++].GetInteger(); | ||
if (!Enum.IsDefined(typeof(ContractParameterType), Type)) throw new FormatException("Incorrect Type"); | ||
if (Type == ContractParameterType.Void) throw new FormatException("Void Type is not allowed in NEP-25"); |
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.
NEP-25 technically doesn't forbid that, the type can be used as method return type. In which case ExtendedType
is useless as it can't contain any other data but the same type, but still valid.
if (!Enum.IsDefined(typeof(ContractParameterType), Type)) throw new FormatException(); | ||
NamedType = array[startIndex++].GetString(); | ||
|
||
if (array[startIndex++] is Integer length) |
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.
Optional, but what if array[startIndex++]
is a map, for example?
{ | ||
Fields = null; | ||
} | ||
} |
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.
The question is more about semantic checks, almost all fields are optional, but not all combinations of fields are valid. This is described in NEP-25 and both deserialization methods should check for it.
Need a hardfork. So many incompatible data are there. Compared full mainnet node sync with #4167 and #4043, here's the result.
|
I think that's related to #4043 (comment), if we're to not encode missing fields at all stack item representation will be the same for old (NEP-14) manifests. |
Done |
Description
Implement NEP-25 neo-project/proposals#160 (review)
Replace of #3272
Type of change
How Has This Been Tested?
Test Configuration:
Checklist: