Skip to content
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

System.Contract.IsStandard and possible improvements to it #1753

Closed
roman-khimov opened this issue Jul 7, 2020 · 0 comments · Fixed by #1754
Closed

System.Contract.IsStandard and possible improvements to it #1753

roman-khimov opened this issue Jul 7, 2020 · 0 comments · Fixed by #1754
Labels
Discussion Initial issue state - proposed but not yet accepted

Comments

@roman-khimov
Copy link
Contributor

Summary

I think System.Contract.IsStandard syscall is a little strange in its behavior and it could probably be improved by changing its meaning and behavior. This is more of an open discussion though.

Current status

System.Contract.IsStandard is supposed to be checking for contract standardness where a contract is considered as a standard one if it's a simple signature or multisignature check script. It takes an input of Uint160 (script hash) and returns a boolean. The implementation of this syscall tries to pull the contract from current snapshot and returns true if the contract is not found or if its script really is a standard contract satisfying the condition described earlier.

Background and potential issues

This syscall was originally added to Neo 2 as Neo.Account.IsStandard in #389 to solve #304. Of course it has changed a little since then, but the core idea of implementation is still the same.

Judging from #304 it was intended to distinguish standard contracts from non-standards ones, which is not that hard to do by looking at the script. But the syscall takes a script hash as an input and it's impossible to tell anything just by staring at the script hash, so it gets a contract from snapshot using this script hash.

In the end what we have is:

  • if there is no script with the given hash in the list of deployed contracts, the syscall returns true assuming contract to be standard.
    I don't think it's a correct assumption, as was noted above, it's impossible to tell anything about the script just by looking at its hash.
  • if there is a deployed contract with the given hash, even though it can theoretically be standard it will never be in practice, no one deploys standard contracts, they're used as witness scripts and that's enough for them.

Which means that it's almost an "always true" syscall. And maybe that explains why in 184 contracts deployed at the height of 5313339 on Neo 2 mainnet there are none using it.

Possible improvements

Option 1, make IsStandard work

If we really want to have this check available to smart contracts it should probably take a script as an input and then it'll be easy to do appropriate checks and return a correct result. But it's probably not that practical as contracts rarely deal with scripts especially given that they no longer access to witnesses in Neo 3. And IMO there are other things a contract might be
interested in.

Option 2, switch to IsDeployed

Hash-based IsStandard doesn't seem to be very useful, so we can switch to checking whether a contract is deployed or not. Although one can also do it with System.Blockchain.GetContract, some IsDeployed(hash) may be a cheaper alternative to that.

Option 3, make IsPayable

But what's probably more interesting to calling contract is whether it can transfer money to the account given, so some IsPayable(hash) is also an option, again it could be derived from System.Blockchain.GetContract, but for IsPayable it would be appropriate to return true if the contract is not deployed (as you can transfer money to it anyway).

Option 4, forget IsStandard and its alternatives

Of course we can also just drop IsStandard as useless and not replace it with anything.

Neo Version

  • Neo 3

Where in the software does this update applies to?

  • SDK (syscalls)
@roman-khimov roman-khimov added the Discussion Initial issue state - proposed but not yet accepted label Jul 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Initial issue state - proposed but not yet accepted
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant