NEP-22 improvement working group

[AnnaShaleva]

The aim of this issue is to gather and summarize inaccuracies or parts of NEP-22 standard that needs to be improved. These issues do not require immediate standard update or replacement. However, depending on the number of issues found, we may update the standard later.

Below presented the list of issues found by the current moment. These are the issues we've faced while adding support of NEP-22 to NeoGo (nspcc-dev/neo-go#3968, nspcc-dev/neo-go#3971). This list may be extended in future, so don't hesitate to add a comment if you find some inaccuracy or a space for NEP-22 standard improvement.

1. Missing Update event specification

Comparing NEP-22 with NEP-31 destroy standard, which is supposed to have a similar structure, we can see that there's a difference. In destroy standard there's an Events section that specifies the Destroy event of native ContractManagement:

proposals/nep-31.mediawiki

Lines 42 to 56 in 1e32f84

	===Events===
	====Destroy====
	<pre>
	{
	"name": "Destroy",
	"parameters": [
	{
	"name": "contract",
	"type": "Hash160"
	}
	]
	}
	</pre>

Although this event is not a direct part of NEP-31 and mentioned for the informational purposes, it would be nice to unify NEP-22 format by adding Events section with Update event of native ContractManagement.

2. Ambiguity between overloads of update method of native ContractManagement

It is postulated that NEP-22's update method requires exactly 3 parameters. Two of them (nefFile and manifest) MUST be passed to native ContractManagement's update method, whereas the third one (data) is also required according to the NEP-22 method signature, but there's nothing about the fact that native ContractManagement has two overloads with/without data parameter:

proposals/nep-22.mediawiki

Line 53 in 1e32f84

The parameter <code>data</code> can be any type of supported parameters for contract-specific purpose. For [https://github.com/nspcc-dev/neofs-contract/blob/99fb86c35a48ed12017423aa4fee13f7d07fa4c0/contracts/proxy/contract.go#L33 example] some kinds of parameters can be put into data for specific check. See [https://github.com/neo-project/proposals/blob/master/nep-29.mediawiki NEP-29] for additional reference on contract update callback mechanism that works with this parameter.

The problem is that some of existing contracts expose update(nef, manifest) method with two arguments only and call native Management's update with two arguments. Practically, we can say that these contracts support NEP-22 since they support updating functionality and call Management in a proper way. But technically, these contracts can't put NEP-22 in their manifest because update signature doesn't match the one described in NEP-22.

This problem raise an ambiguity in dApps. E.g. in NeoGo CLI tool that supports contract update functionality it's not clear what should we do if user provides only NEF&manifest without data parameter to this command. Should we call update with two arguments or just pass stackitem.Null as the third argument to the contract's update? We can answer this question by retrieving contract's manifest, but it would be nice to have a straight answer without additional interactions with the contract state.

[shargon]

The problem is that some of existing contracts expose update(nef, manifest) method with two arguments only and call native Management's update with two arguments.

Yes, a lot of devs don't use data, we saw a lot of contracts like this