Neo: [NEO3] RPC method invokeScript will fail when directly calling native contract interop service

Created on 16 Aug 2019  路  11Comments  路  Source: neo-project/neo

I learn in NEO3, there are 2 ways to construct script to use rpc method to invoke native contracts:

  • A: args + operation + systemCall + native_contract_interopservice
  • B: args + operation + scripthash + systemCall + System.Contract.Call

Method A will always fail.
Example: Invoke name method of NEO contract:
Method A: 00c1046e616d656845c49284 - FAULT
Method B: 00c1046e616d651415caa04214310670d5e5a398e147e0dbed98cf4368627d5b52 - HALT

help wanted

Most helpful comment

Why we register interop services? They cann't be used.

@kickseason this was the proposed design, by actually performing an "internal/private" syscall. Its used to define a script that will never change, even after bugfixes.
we discussed on it, and concluded that supporting both invocation ways (syscall and call) wouldnt be consistent/good (I remember now).

@tommo-l described correctly: "I understand, the context is different, the native contract execution context must be themselves."

In fact, if you do a syscall on native contract, you wouldnt be able to protect the stack with only intended parameters (appcall does this now, considering standard entrypoint format); isolate the actual idea of a regular call.

Finally, @morgandream, if we remove this, we lose ScopedSig protector for native NEP-5. If we allow syscall, we allow script to run on same context level as invoker, and we would never be able to describe specific situations where we want or not the intended witness (unless we redesign Scoped witnesses too).

I think that, in the end, the private interop definition is the best for us, it's an interop, like any other, but can only be invoked by System itself, not directly from other contracts.

All 11 comments

. # 12 bytes
00 0: PUSH0 #An empty array of bytes is pushed onto the stack
c1 1: PACK #
04 2: PUSHBYTES4 6e616d65 # name
68 7: SYSCALL 45c49284

. # 33 bytes
00 0: PUSH0 #An empty array of bytes is pushed onto the stack
c1 1: PACK #
04 2: PUSHBYTES4 6e616d65 # name
14 7: PUSHBYTES20 15caa04214310670d5e5a398e147e0dbed98cf43 # B1pGC
68 28: SYSCALL 627d5b52

Need to see why...
~other situation is standard entry point (string, object[] args), do we have it? If so, it may require two params (empty array) , did you test that?~

Just saw you put the array.. scripthash is correct?

The scripthash is NEO, and it's definitely correct, cause Method B is using it, and it succeeds.

@shargon Why we register interop services? They cann't be used.

why not support? or for security consideration?

If we don't support, then we can't also use NEO and GAS in contract directly, which like the following:
image

I understand, the context is different, the native contract execution context must be themselves.

@shargon What do you think? Shall we keep it like this or change it?

Why we register interop services? They cann't be used.

@kickseason this was the proposed design, by actually performing an "internal/private" syscall. Its used to define a script that will never change, even after bugfixes.
we discussed on it, and concluded that supporting both invocation ways (syscall and call) wouldnt be consistent/good (I remember now).

@tommo-l described correctly: "I understand, the context is different, the native contract execution context must be themselves."

In fact, if you do a syscall on native contract, you wouldnt be able to protect the stack with only intended parameters (appcall does this now, considering standard entrypoint format); isolate the actual idea of a regular call.

Finally, @morgandream, if we remove this, we lose ScopedSig protector for native NEP-5. If we allow syscall, we allow script to run on same context level as invoker, and we would never be able to describe specific situations where we want or not the intended witness (unless we redesign Scoped witnesses too).

I think that, in the end, the private interop definition is the best for us, it's an interop, like any other, but can only be invoked by System itself, not directly from other contracts.

Thanks @igormcoelho @shargon . We can close this.

Was this page helpful?
0 / 5 - 0 ratings