-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Check ABI for notifications #2810
Conversation
A little worried that this will break old contract and make data incompatible. |
We need to check mainnet of course, if something breaks this should be a hardfork, but it's a valuable improvement in general. Now if we could trust NEP-11/NEP-17 manifest specifications (#1883)... |
That can break and may need a hardfork as you mentioned. However, in a long-term perspective this is a good compliance to be followed by contracts as @roman-khimov emphasized. |
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 PR is precise @erikzhang ,as always, code looks simple, we will test asap.
I can't approve this, we need fork height, otherwise will be break at block 693180 in mainnet. @erikzhang @shargon |
Do you have the hash of the contract causing the problem? We may want to search through the whole chain for these inconsistencies and notify contract developers because they need to upgrade their (broken) contracts before the hardfork height. |
|
My current list (up to 2215218 height) is:
And it's not a small one (please recheck though). As much as I like this change we can't just enable it at some height and hope it works, there will be some breakage and I don't think it's acceptable for mainnet. Suggestions are:
|
Very useful. I created an issue internally to address the Bool - Integer conversion and then for the contracts created with |
Normalizing in compiler is an option too, even a better one, it's just that it requires contract updates and I'm not sure it can be done in timely manner for mainnet. |
I totally agree with that. I was mostly posting with the idea of indicating we're working on having a migration plan ready for the affected contracts created with boa, so the contract authors should have to spend as little time as possible on it. |
case ContractParameterType.Integer: | ||
return aType == StackItemType.Integer; | ||
case ContractParameterType.ByteArray: | ||
case ContractParameterType.String: |
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.
Don't we want to have some additional checks for the String
type? The way it is now it's absolutely the same as ByteArray
, maybe some differentiation can be useful like if String
could only contain valid UTF-8 byte sequence.
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.
@shargon, how about this additional check?
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.
@AnnaShaleva Done
@erikzhang Let's move on. It's in 3.5.0 release checklist. |
Any example on how to log warning? I'm a little worried if we log it in cli or rpc, still can't be noticed by most people. |
Well, it's a usual log message (like the one from dBFT or RPC for example), but I know neo-cli does it in a bit different manner than neo-go. We have it in 0.99.4 release already and it's just another log message. Yes, people may not notice it, but they at least will have some chance and it also is tightly related to proper scheduling/announcement of this change. If developers will be aware of the change they will try to take a look at how their contracts behave, if they care about them. If they don't, well, then the contract is obsolete already in some ways. |
Maybe we can send mail to these contract deployers since their emails are in manifest. |
I've sent a mail to these admins to ask them pay attention for this change, I think we could move on. |
Hi all, This is our event: This is how it's described in the manifest: This is how we are using it: /// <summary>
/// Update contract paused state without access control.
/// </summary>
/// <remarks>
/// Internal function without access restriction.
/// </remarks>
/// <param name="paused">The new paused value to be set.</param>
protected static void UpdatePaused(bool paused)
{
PausedStore.Put(paused);
OnPausedChanged(paused);
} |
Nothing wrong, currently Neo push integer instead of bool in VM which will cause break in ABI check. It will be fixed in neo-project/neo-vm#497 |
Ok, so we don't have to change anything? |
Yes! |
Follow the neo-project/neo#2884. A part of the neo-project/neo#2810. Signed-off-by: Anna Shaleva <[email protected]>
case ContractParameterType.ByteArray: | ||
case ContractParameterType.String: | ||
return aType is StackItemType.Any or StackItemType.ByteString or StackItemType.Buffer && | ||
Utility.StrictUTF8.GetString(item.GetSpan()) is not null; // Prevent any non-UTF8 string | ||
{ | ||
if (aType is StackItemType.Any or StackItemType.ByteString or StackItemType.Buffer) | ||
{ |
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.
Now this check is being performed for both cases when type
is either ContractParameterType.ByteArray
or ContractParameterType.String
. But the initial idea was to perform this check only for ContractParameterType.String
and let the ContractParameterType.ByteArray
be as is.
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.
My bad :)
case ContractParameterType.String: | ||
{ | ||
if (aType is StackItemType.Any or StackItemType.ByteString or StackItemType.Buffer) | ||
{ | ||
try | ||
{ | ||
_ = Utility.StrictUTF8.GetString(item.GetSpan()); // Prevent any non-UTF8 string | ||
return true; | ||
} | ||
catch { } | ||
} | ||
return false; | ||
} |
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.
And the last question from my side: if we have Null
stackitem passed as notification parameter and in manifest it is declared ContractParameterType.String
, what should happen? The previous version allowed this, but seems that the current code will throw the InvalidCastException
exception on item.GetSpan()
call for Null
stackitem. But I think it's valid to pass Null
stackitem as ContractParameterType.String
.
@shargon, @roman-khimov, what do you think?
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.
@AnnaShaleva, you're programming in Go, string
can't be null there!
Jokes aside, I don't think I have any strong preference here. I'm slightly more in favor of making strings always have some contents (even if it's "", basically the way it is now), but if there are useful cases where Null
is applicable, we can accept it too. We can also try having more strict policy for now and then relax it if needed (it's always easier than the other way around).
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.
Let's then adjust a bit the current check so that it'll be more explicit:
if (aType is StackItemType.ByteString or StackItemType.Buffer)
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.
StackItemType.Any
normal indicates NULL
. But normally depends on where it is.
you can always check for StackItem.IsNull
or StackItem.Null
Maybe treat strings the same as string.IsNullOrEmpty()
does.
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 that should be empty, not 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.
@shargon, good, then see the #2810 (comment), please.
I've compared all block data, at least it's compatible before |
Co-authored-by: Anna Shaleva <[email protected]>
Follow the neo-project/neo#2884. A part of the neo-project/neo#2810. Signed-off-by: Anna Shaleva <[email protected]>
Follow the neo-project/neo#2810 (comment). Signed-off-by: Anna Shaleva <[email protected]>
Follow the neo-project/neo#2884. A part of the neo-project/neo#2810. Fix failing tests along the way (a lot of them have invalid notifications format which differs from the one declared in manifest). Signed-off-by: Anna Shaleva <[email protected]>
Follow the neo-project/neo#2810 (comment). Signed-off-by: Anna Shaleva <[email protected]>
// is
Runtime.Notify("Hello", new[] { "World" });
// the as
[DisplayName("Hello")]
public static event Action<string> event_name;
event_name("world"); Just wondering if the above calls the same function in the VM. I don't make smart contracts so i don't know. |
Close #1879