Unified Entrypoint for Script Verifications

[igormcoelho]

Summary
This is an important proposal, initially by Erik on neo-vm discussions, that may solve some migration issues, drastically improve simplicity and project organization. All Script verifications should be done by a "verify" method, and contract direct VerificationTrigger access (on SDK) could be abolished.

Do you have any solution you want to propose?

On Neo 2, CHECKSIG opcode (from NeoVM2) took ScriptContainer hash (Tx Header) and matched it against a passed signature and pubkey. CHECKSIG was removed from NeoVM, to detach it from Neo (good move). CHECKSIG became an Interop, and although possible to convert from both address formats, it will hit most of Neo2 users on migration to Neo3.

I have two proposals:
(1) recover CHECKSIG to NeoVM, but with a "verify" prefix, so Transaction header hash would be pushed automatically as "verify" array parameter. User scripts would be identical as Neo2.
(2) keep CHECKSIG as Interop, but adopt "verify" invocation as method entrypoint verification, so we would need to include an IF inside new Neo3 user scripts (since it changed anyway, no problem with another breaking change before migration).

Option (1) would be very good in my opinion, because it would restore full Neo2 compatibility for regular addresses. The only drawback is that NeoVM would reincorporate something which is "not fully pure" (by checking a "verify" and array stack item, from its Neo blockchain origins, but no ScriptContainer anymore). One fix to that, is allowing VM EXTENSIONS proposal to go on, so that it would incorporate CHECKSIG and CHECKMULTISIG as options to disable on bit check (first two extensions would be these two, although the rest would come in an EXTENSIONS opcode).

Option (2) is very easy to do now, but it keeps breaking address compatibility changes with Neo 2 (which is accepted already by most community members, I guess). It would require an extra IF (or JMPIF, or DROP) to check for "verify" method, and match against a pushed transaction hash, first parameter of verify param array. This parameter would be pushed automatically by Neo system, when processing some witness verification script (before Invocation Script is pushed on stack). Erik did a very similar proposal some time ago on neo-vm, I have to find that comment and link it here...

After that, we should disable Contracts to being invoked as witnesses and inputs (therefore, removing VerificationTrigger from them), and an option to take assets from them is simply using ApplicationTrigger, where they will directly invoke NeoNative "transfer", and CallingScriptHash could be considered as witness for verification (CheckWitness considering CallingScriptHash too). Another option here is to create a InvokeAsWitness, that would include CallingScriptHash in witness list, for that only specific invocation, and Scope being added to this invocation (good for partial refunds... entire refunds could just FAULT execution and revert everything, so regular contract witness could be used instead).

Important: this proposal will not remove VerificationTrigger from the blockchain, as it changes behavioral execution model (no storage, etc), so how could contracts pay for third-party operations? Simple. If Sender is a deployed contract, method "verify" would be pushed on stack, and it would be executed on VerificationTrigger (no storage change). For contract transfers (withdraws by owner), this should be performed as regular transfer on NEP-5 Application, adding this contract as a regular Witness/Cosigner (thus passing regular "verify" method on VerificationTrigger), denying if Scope is not safe enough (could be another "verify" array parameter perhaps). One challenge is to check that fee was well spent, or not spent to invoke other contracts in same Script... Entry script would need to be inspected perhaps, not easy to see how to do this efficiently.

Where in software does this update applies to?

• Ledger
• VM

[igormcoelho]

This would also allow @belane proposal (https://github.com/neo-project/neo/issues/1076) of receiving/reacting to assets, since "verify" could be replaced by "payable" method, when querying an script if it's payable. CHECKSIG upgraded opcode (or interop) could also respond to this payable, by default returning true.
The point if NEP-5 would query (or not) regarding payable condition, should not be enforced on all NEP-5 anyway... but for those who do this, we will have a possibility to respond "yes" automatically, even on the simplest addresses.

[igormcoelho]

Closing this in favor of #1115