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.CallEx #1361

Closed
erikzhang opened this issue Dec 14, 2019 · 7 comments · Fixed by #1364
Closed

System.Contract.CallEx #1361

erikzhang opened this issue Dec 14, 2019 · 7 comments · Fixed by #1364
Labels
Discussion Initial issue state - proposed but not yet accepted
Milestone

Comments

@erikzhang
Copy link
Member

Summary or problem description
Currently, we use System.Contract.Call to invoke a contract. But sometimes, we need to put some restrictions on the call. For example, we require that the called contract cannot call other contracts (no sub-calls); or we require that the called contract cannot modify the state (read-only mode).

Do you have any solution you want to propose?
I introduce a new SYSCALL: System.Contract.CallEx. It is very similar to System.Contract.Call. But it accepts an additional parameter to pass those restrictions on the call.

object CallEx(UInt160 hash, string method, object[] args, CallFlags flags);

Neo Version

  • Neo 3

Where in the software does this update applies to?

  • Other
@erikzhang erikzhang added the Discussion Initial issue state - proposed but not yet accepted label Dec 14, 2019
@igormcoelho
Copy link
Contributor

Very interesting proposal @erikzhang ... reminds me of #446 which was after converted to Scoped Witnesses, as it focus on user perspective rather contract-defined. Yet, this can also be used in benefit of users, as Entry may specific a certain call that disables "features", such as dyn invoke, perhaps storage... etc.

In this sense, what features should we allow disabling on flags? I think at least:

  • dynamic invocations
  • storage writes
  • storage reads (disable storage)
  • static variables (make them constant)
  • payable conditions on general
  • what else?

@shargon
Copy link
Member

shargon commented Dec 14, 2019

It's a very good idea

@erikzhang
Copy link
Member Author

Who want to implement this?

@shargon
Copy link
Member

shargon commented Dec 15, 2019

I can do it after #1362

@Tommo-L
Copy link
Contributor

Tommo-L commented Dec 17, 2019

I wonder whether we should restrict the callee's use of storage, subcall, notify. Or do we have an example that really needs this.

 public enum CallFlags : byte
 {
       None = 0,

       AllowModifyStates = 0b00000001,
       AllowCall = 0b00000010,
       AllowNotify = 0b00000100,

       All = AllowModifyStates | AllowCall | AllowNotify
}

If it is for the security, I think it would be more reasonable to move the constraint to the manifest. If not, there is no need for the caller to concern about the callee's implementation.

@erikzhang
Copy link
Member Author

It is for contracts. It is hard for a contract to read manifest before calling another contract.

@shargon
Copy link
Member

shargon commented Dec 17, 2019

There are different protections. Manifest level, and contract level.

@erikzhang erikzhang added this to the NEO 3.0 milestone Dec 19, 2019
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.

4 participants