Skip to content

Latest commit

 

History

History
49 lines (32 loc) · 3.09 KB

nep-11.mediawiki

File metadata and controls

49 lines (32 loc) · 3.09 KB
Raw

  NEP: 11
  Title: Smart Contract Verification and Invocation with System Assets
  Author: Alex DiCarlo (alex.dicarlo@neotracker.io)
  Type: Standard
  Status: Draft
  Created: 2018-06-07
  Replaces: NEP-7

Table of Contents

Abstract

This NEP defines a scheme for smart contracts to handle system asset transfers.

Motivation

Smart contract authors cannot reliably refuse system asset transfers in smart contract invocations. They cannot refuse or react to system asset transfers made with transactions other than invocation transactions to the smart contract address. There is additional complexity in handling the possibility of multiple invocations in the same invocation transaction that expect system assets, typically requiring tracking between calls. At a high level, there are two main issues that this NEP aims to solve:

  1. Allow smart contracts to refuse system asset transfers.
  2. Allow smart contracts to react to system asset transfers.

Specification

Implement the following changes to the NEO protocol:

  1. Run invocation transactions' script with the `VerificationR` trigger if it contains system assets sent to a smart contract address. Track which smart contracts have been executed and verify that for each smart contract address output the associated smart contract has executed at least once.
  2. Incorporate temporary storage for use in the VM during consensus which is used across verification of transactions
  3. Reject all non-invocation transactions whose outputs contain an address that is a smart contract address.

Rationale

The specification ensures that smart contracts have a chance to refuse system asset transfers in invocation transactions. By running the script with the `VerificationR` trigger and verifying that the smart contract was called, we also guarantee that the smart contract will have a chance to react to system transfers in the `Application` trigger. Finally, by rejecting all non-invocation transactions that contain a smart contract address as the output, we close the loop and guarantee that whenever a smart contract address is the output of a system asset transfer, the smart contract has the chance to refuse and react to the transfer.

In addition, it has the following beneficial properties:

  1. Multiple methods that expect system assets are supported.
  2. Which method and the arguments to the invoked method are known and can be used in the `VerificationR` trigger.
  3. We introduce a new `VerificationR` trigger, which introduces additional complexity, however, in most cases the functionality of the smart contract need not change whether the smart contract is being run in `Application` or `VerificationR` mode.
  4. The `VerificationR` trigger can track invocations across calls, and even across transactions in a single block, using storage.
See additional discussion here: neo-project/neo#172.

Backwards Compatibility

This NEP has the potential to break ongoing ICOs and thus we must coordinate the launch to ensure that all existing smart contracts will handle the `VerificationR` trigger appropriately.

Implementation

neo-project/neo#276