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

Post-Execution Verification #2011

Closed
igormcoelho opened this issue Oct 21, 2020 · 3 comments
Closed

Post-Execution Verification #2011

igormcoelho opened this issue Oct 21, 2020 · 3 comments
Labels
Discussion Initial issue state - proposed but not yet accepted

Comments

@igormcoelho
Copy link
Contributor

igormcoelho commented Oct 21, 2020

Summary or problem description
This is a fundamental proposal for having users verifying contracts by using "natural chain state" (which is verification), now extended for all kinds of execution (including Notifications and invocation return value), without any extra MPT or something of the sort.

Do you have any solution you want to propose?
Neo currently has Verification and Invocation. I propose to add some "Post-Invocation Verification", that runs after Invocation and has exactly the same workings as Verification (return boolean and executes over GAS quota).

Idea:
Everything put on Verification is verified right away on mempool, so we assume this will never be reverted.
Invocation, on the other hand, executes after block has been proposed (or during proposal), and we cannot have its output immediately written on chain (due to performance issues). However, all invocations need to be processed at most one height extra (otherwise chain would lag forever). So I propose that, after Invocation, user may attach an optional verification script for post invocation, that receives as INPUT the pair: (transaction execution state = FAULT/PASS/etc, Invocation Script OUTPUT)

Usage:
User wants to transfer 10 NEP-5 assets from A to B

  • User attaches witness of A (on Verification)
  • User may also attach other witnesses if it prefers on Verification (see Solid State Transfers proposals#97)
  • Neo consensus put tx on block and starts executing Invocation
  • After finishing Invocation, it directly executes the Post-Verification Script, if any exists (that will return True or False)
  • If post-invocation script fails, the Invocation effects must be reverted for that TX.
  • If invocation result is FAULT, post-execution will issue False "by default".. it means that NO POST-EXECUTION means, INPUT[0] != "FAULT"

Note that, on the next block, the consensus COULD (theoretically) attach the post-execution boolean vector (one bool per tx, VERY SMALL), that would indicate if these have passed or not, in that precise moment of time. This script may check for Notifications, output results, anything else user wants (within the GAS quota).

With this, no MPT is strictly required, although still desirable.

Neo Version (BOTH VERSIONS)

  • Neo 2
  • Neo 3

Where in the software does this update applies to?

  • Consensus
  • Ledger
  • Wallet
@igormcoelho igormcoelho added the Discussion Initial issue state - proposed but not yet accepted label Oct 21, 2020
@igormcoelho
Copy link
Contributor Author

@erikzhang @shargon please take a careful look at this.

@roman-khimov
Copy link
Contributor

including Notifications

Just as a side node: storing notifications would allow to fix #1861 and I think in the end we'll need that anyway.

After finishing Invocation, it directly executes the Post-Verification Script, if any exists (that will return True or False)

How does it differ from invocation script including the same post-verification part and ABORTing if anything goes wrong?

@igormcoelho
Copy link
Contributor Author

How does it differ from invocation script including the same post-verification part and ABORTing if anything goes wrong?

The key difference is execution guarantee and the possibility of standardization: the same NEP for pre-execution witnesses could be used for post-execution witnesses on wallets, thus reinforcing assertions that we expect, e.g., my balance was 1000 and now is 2000. Verifying readable assertions is so much easier than reading any MPT proof, and like I said, this is a complementary technique much easier for wallets/users, thus not excludent.

If you just ABORT these assertions inside invocation script, you will never be able to know if these were totally, partially, or even executed, because script may just "jump it". Post-Execution follows the same logic of the double aspects of VerificationScript (Invocation Part vs Verification Part). What I propose is just to add the "Verification Part" to current InvocationScripts, which is lacking (and would be very useful indeed).

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

No branches or pull requests

3 participants