NEP: 16 Title: NEO Executable Format (NEF) Author: Erik Zhang <[email protected]>, Fernando Díaz Toledano <[email protected]>, Igor Machado Coelho <[email protected]>, Li Jianying <[email protected]>, Vitor Nazário Coelho <[email protected]> Type: Standard Status: Final Created: 2020-03-31
Compiled code to be executed by the Neo virtual machine is represented using a binary format, typically stored in a file, known as the nef file format. The nef file contains Neo bytecodes, as well as other ancillary information such as byte ordering and compiler used.
This NEP describes the NEF standard for NEO smart contracts.
For the sake of security, we need to place strong syntactic and structural constraints on the executable file. With the nef file format, we can guarantee both the validity and functionality of the compiled file.
In the field definitions below, we provide both the definitions of the fields as well as the corresponding functions.
A nef file consists of a stream of 8-bit bytes. Multibyte data items are always stored in little-endian order, where the low bytes come first. Its structure is described further below.
nef_file
{
4-byte magic;
64-byte compiler;
2-byte reserve;
method_token{
20-byte hash;
var-byte method;
2-byte parametersCount;
1-byte hasReturnValue;
1-byte callFlags;
} tokens[];
2-byte reserve;
var-byte script;
4-byte checksum;
}
The extension name of the nef file should be .nef.
The magic item supplies the magic number identifying the NEF3 file format; it has the value 0x3346454E.
The compiler is a UTF-8 encoded string representing the compiler used to create the data in the script item. It should indicate the name and the version of the compiler, which must be padded to make it up to the required length if shorter than 64 bytes.
All bits of the reserve item are reserved for future use and must be set to zero in generated nef files.
Each entry in the tokens item must be a method_token structure giving a necessary description of a method invoked by this contract.
The hash item represents the hash of the static contract with the length of 20 bytes, indicating which contract the method belongs to.
The method item is used to represent constant string values of the method name. It has s single-byte length prefix and up to 32 byte string contents encoded in UTF-8.
The parametersCount denotes the number of formal parameters of the method.
The hasReturnValue item is a boolean value that indicates whether the method has return value or not.
The value of the callFlags item is a mask of flags used to denote the calling permission to the method. The Interpretation of each flag, when set, is specified in the following table:
| Flag Name | Value | Interpretation |
|---|---|---|
| None | 0 | called without other permissions |
| ReadStates | 0b00000001 | allow to read the storage |
| WriteStates | 0b00000010 | allow to write the storage |
| AllowCall | 0b00000100 | allow to call methods in other contracts |
| AllowNotify | 0b00001000 | allow to send the notification |
All bits of the callFlags item not assigned in the table are reserved for future use. They should be set to zero in generated nef files.
The value of script stores the raw VM opcodes. The data should be serialised using the variable length format as described in the documentation.
The checksum item is used not only to ensure a corrupt-free transmission, but also to ensure that the file has not been tampered with. It is computed by using the SHA256 algorithm to hash the serialised nef file excluding checksum twice, and converting the result into a 32-bit unsigned integer, which must be identical with the last four bytes of the nef file.
https://github.com/neo-project/neo/blob/master/src/neo/SmartContract/NefFile.cs