Adding keccak256

[Jim8y]

No description provided.

[Jim8y]

mistakenly deleted previous branch

[vncoelho]

@Liaojinghui ,maybe we need more test cases on edge cases.
It would be good to add more.

Furthermore, what is the idea for future resync and forks? @vang1ong7ang

[vncoelho]

Decide about the possible attack as on 3.6.0 upgrade, and also verify more tests.

[Jim8y]

Decide about the possible attack as on 3.6.0 upgrade, and also verify more tests.

Hi vitor, what this means?

[Jim8y]

@shargon Tests ok and ready for merge.

[shargon]

Decide about the possible attack as on 3.6.0 upgrade, and also verify more tests.

@vncoelho what this means?

[vncoelho]

Nowadays, we don't have this syscall,right?
What happens if someone calls it?
I am imagining that TX will fail.
Later, if this syscall exist the tx can be successful. It just need an if strategy to do malicious things.

These are the ForkTriggers @vang1ong7ang tried to explain.

I did not test yet, but we can try that. If that is a call from Native contract the attack will probably be possible..

[Jim8y]

@vncoelho previous transactions can not call this cause this not yet exist, only if this is added will developers be able to call it, since this will not affect previous transactions at all, no fork will introduce here.

[vncoelho]

If I am right, the attack is very serious, in the same way as reported in #2910, please take some time to understand the previous issue and how critical and dangerous it was.
It was too much imprudent to apply 3.6.0 upgrade to the Consensus Nodes. Let's not be frivolous in conclusions and DO NOT PUT mainnet assets at risk.

It looks like the same issue could happen here if someone perform a malicious transaction before nodes receive the update. Exactly because "can not call this cause this not yet exist". There are combinations/logics that can be done that will cause Fork and even revert Token transactions (if, in the future, a re-sync occurs).

If the attack can proceed, this PR should not be merged without an agreement to definitely solve the issue of updating native functions, etc... (or, at least, use a fork tag precisely connected to the nodes update time). @vang1ong7ang @dusmart.

[Jim8y]

@vncoelho Oh, I see what you mean now.

[vncoelho]

That is why this needs to be solved before this PR is merged. I did not reject the PR for nothing, there is a reason this should not be merged.

First, solve, then add new features.
Or, create a fork tag.

Otherwise, be prepared because at some point some attack will come...The attack is well known nowadays.

[Jim8y]

versioning things, consensus version, vm version all matters,,,,,,even plugin versions.........

[Jim8y]

will reopen after a proper solution to the version is found

[shargon]

Require #2942

[shargon]

It will be merged in update-native-contract brach

[Jim8y]

@AnnaShaleva @roman-khimov neo-go will update accordingly.

[AnnaShaleva]

Sure, will be implemented together with native contracts update.