|
| 1 | +<pre> |
| 2 | + NEP: 8 |
| 3 | + Title: Stack Isolation for NeoVM |
| 4 | + Author: Erik Zhang < [email protected]> |
| 5 | + Type: Standard |
| 6 | + Status: Final |
| 7 | + Created: 2017-12-26 |
| 8 | + Replaces: 4 |
| 9 | +</pre> |
| 10 | + |
| 11 | +==Abstract== |
| 12 | + |
| 13 | +This NEP proposes that stack isolation of the NeoVM evaluation stack should be carried out to ensure the security of dynamic invocations and provide support for future new features. |
| 14 | + |
| 15 | +==Motivation== |
| 16 | + |
| 17 | +Now that [[nep-4.mediawiki|NEP-4 (dynamic invocation)]] has been implemented, but because the NeoVM evaluation stack is not isolated, a dynamically invoked contract may break the caller's stack at runtime, resulting in the contract not being executed as expected. |
| 18 | + |
| 19 | +On the other hand, some features, such as exception handling, also require stack isolation to be implemented. |
| 20 | + |
| 21 | +==Rationale== |
| 22 | + |
| 23 | +We need a new set of instructions so that each invocation creates a separate evaluation stack and automatically copies the arguments of the function to the new stack. After the function has finished running, the return value is automatically copied to the caller's stack. In this way, the invoked contract will no longer affect the caller's behavior by modifying with the stack. |
| 24 | + |
| 25 | +==Specification== |
| 26 | + |
| 27 | +We add five new instructions for starting invocations with stack isolation: <code>CALL_I</code>, <code>CALL_E</code>, <code>CALL_ED</code>, <code>CALL_ET</code>, <code>CALL_EDT</code>. |
| 28 | + |
| 29 | +===CALL_I=== |
| 30 | + |
| 31 | +The instruction <code>CALL_I</code> is very similar to the old instruction <code>CALL</code>. The difference is that <code>CALL_I</code> requires an operand behind the instruction for representing the number of parameters and return values to copy. |
| 32 | + |
| 33 | +===CALL_E=== |
| 34 | + |
| 35 | +The instruction <code>CALL_E</code> is very similar to the old instruction <code>APPCALL</code> for static invocations. The difference is that <code>CALL_E</code> requires an operand behind the instruction for representing the number of parameters and return values to copy. |
| 36 | + |
| 37 | +===CALL_ED=== |
| 38 | + |
| 39 | +The instruction <code>CALL_ED</code> is very similar to the old instruction <code>APPCALL</code> for dynamic invocations. The difference is that <code>CALL_ED</code> requires an operand behind the instruction for representing the number of parameters and return values to copy. |
| 40 | + |
| 41 | +===CALL_ET=== |
| 42 | + |
| 43 | +The instruction <code>CALL_ET</code> is very similar to the instruction <code>CALL_E</code>. The difference is that <code>CALL_ET</code> will start a tail call. |
| 44 | + |
| 45 | +===CALL_EDT=== |
| 46 | + |
| 47 | +The instruction <code>CALL_EDT</code> is very similar to the instruction <code>CALL_ED</code>. The difference is that <code>CALL_EDT</code> will start a tail call. |
| 48 | + |
| 49 | +==Backwards Compatibility== |
| 50 | + |
| 51 | +All old contracts can be executed correctly in the original instruction set, but no new contracts are proposed to continue using the old instructions. When a new contract requires dynamic invocation, the old instructions should be avoided. |
| 52 | + |
| 53 | +==Implementation== |
| 54 | + |
| 55 | +https://github.com/neo-project/neo-vm/pull/39 |
0 commit comments