I learn in NEO3, there are 2 ways to construct script to use rpc method to invoke native contracts:
Method A will always fail.
Example: Invoke name method of NEO contract:
Method A: 00c1046e616d656845c49284 - FAULT
Method B: 00c1046e616d651415caa04214310670d5e5a398e147e0dbed98cf4368627d5b52 - HALT
. # 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.
You cannot call neo native methods directly, you will get the error at:
@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:

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.
Most helpful comment
@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 interopdefinition 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.