mirror of
https://github.com/nspcc-dev/neo-go.git
synced 2026-03-01 04:28:51 +00:00
T5 state diff at 8813651 #1548
Labels
No labels
I1
I2
I3
I4
S1
S2
S3
S4
U0
U1
U2
U3
U3
U4
blocked
bug
bug
cli
compiler
config
config
consensus
dependencies
discussion
documentation
enhancement
epic
feature
go
good first issue
help wanted
neotest
network
oracle
performance
question
rpc
security
smartcontract
task
task
task
test
vm
wallet
windows
windows
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
nspcc-dev/neo-go#1548
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @AnnaShaleva on GitHub (Aug 25, 2025).
Originally assigned to: @AnnaShaleva on GitHub.
@AnnaShaleva commented on GitHub (Aug 25, 2025):
OK, what I have for now: the problem is in transaction that updates
fusd-lp-stakingcontract0x4de738069f9e9c448f547e59a46e5c1dc6e6eb9f(one of Flamingo contracts).Go node updates contract successfully:
Whereas C# node FAULTs the transaction:
It looks like the problem is related to serialization/deserialization issue, but this time it differs from the set of issues cauesed by improper charaters escaping like https://github.com/nspcc-dev/neo-go/issues/3224.
[B2]might refer to SUPERSCRIPT TWO' (U+00B2) symbol. There's no such symbols in NEF or manifest, and it's known that C# node properly deserializes both NEF and manifest from bytes (proven by unit-test):So I suspect that the root reason is a call to StdLib's serialize/deserialize methods that are used by this contract (it's reflected in the
tokenssection of the NEF file):The
updatemethod itself is not that simple, it has a set of nested calls:There are CALLT instructions calling
updatemethod of native Management in the end, and the most suspicions one isCALL_L 6630instruction that calls the following method:So I'm still investigating the contract code and C# node code.
@AnnaShaleva commented on GitHub (Aug 27, 2025):
The problem is in
ASSERTMSGinstruction handler at9032offset. In particular, the problem is in the way how the exception message is converted to a byteslice(Go)/string(C#) at this line:nspcc-dev/neo-go@875b15b459/pkg/vm/vm.go (L1650)The reference line is:
neo-project/neo@9b9be47357/src/Neo.VM/JumpTable/JumpTable.Types.cs (L92)@AnnaShaleva commented on GitHub (Aug 27, 2025):
C# node enforces strict UTF-8 check for exception message whereas Go node uses raw bytes:
neo-project/neo@9b9be47357/src/Neo.VM/Types/StackItem.cs (L180-L183)@AnnaShaleva commented on GitHub (Aug 27, 2025):
The message itself is a
ByteStringstackitem with the following value (in hex, raw byte and string representation):So it's not a valid UTF-8 string due to raw Uint160 bytes placed in the end of this message, C# node behaviour is correct.
@AnnaShaleva commented on GitHub (Aug 27, 2025):
Just for the record, the replacement that was used in the contract as a workaround to avoid FAULTed
updateexecution: