1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
|
.. _state_tests:
################################################################################
State Tests
################################################################################
Found in ``/StateTest``, the state tests aim is to test the basic workings of the state in isolation.
It is based around the notion of executing a single transaction, described by the ``transaction`` portion of the test. The overarching environment in which it is executed is described by the ``env`` portion of the test and includes attributes of the current and previous blocks. A set of pre-existing accounts are detailed in the ``pre`` portion and form the world state prior to execution. Similarly, a set of accounts are detailed in the ``post`` portion to specify the end world state. Since the data of the blockchain is not given, the opcode ``BLOCKHASH`` could not return the hashes of the corresponding blocks. Therefore we define the hash of block number ``n`` to be ``SHA256("n")``.
The log entries (``logs``) as well as any output returned from the code (``output``) is also detailed.
It is generally expected that the test implementer will read ``env``, ``transaction`` and ``pre`` then check their results against ``logs``, ``out``, and ``post``.
Basic structure
--------------------------------------------------------------------------------
::
{
"test name 1": {
"env": { ... },
"logs": { ... },
"out": { ... },
"post": { ... },
"pre": { ... },
"transaction": { ... },
},
"test name 2": {
"env": { ... },
"logs": { ... },
"out": { ... },
"post": { ... },
"pre": { ... },
"transaction": { ... },
},
...
}
Sections
--------------------------------------------------------------------------------
* **The** ``env`` **section:**
| ``currentCoinbase``
| The current block's coinbase address, to be returned by the `COINBASE` instruction.
| ``currentDifficulty``
| The current block's difficulty, to be returned by the `DIFFICULTY` instruction.
| ``currentGasLimit``
| The current block's gas limit.
| ``currentNumber``
| The current block's number. Also indicates network rules for the transaction. Since blocknumber = **1000000** Homestead rules are applied to transaction. (see https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2.mediawiki)
| ``currentTimestamp``
| The current block's timestamp.
| ``previousHash``
| The previous block's hash.
|
* **The** ``transaction`` **section:**
| ``data``
| The input data passed to the execution, as used by the `CALLDATA`... instructions. Given as an array of byte values. See $DATA_ARRAY.
| ``gasLimit``
| The total amount of gas available for the execution, as would be returned by the `GAS` instruction were it be executed first.
| ``gasPrice``
| The price of gas for the transaction, as used by the `GASPRICE` instruction.
| ``nonce``
| Scalar value equal to the number of transactions sent by the sender.
| ``address``
| The address of the account under which the code is executing, to be returned by the `ADDRESS` instruction.
| ``secretKey``
| The secret key as can be derived by the v,r,s values if the transaction.
| ``to``
| The address of the transaction's recipient, to be returned by the `ORIGIN` instruction.
| ``value``
| The value of the transaction (or the endowment of the create), to be returned by the `CALLVALUE`` instruction (if executed first, before any `CALL`).
|
* **The** ``pre`` **and** ``post`` **sections each have the same format of a mapping between addresses and accounts. Each account has the format:**
| ``balance``
| The balance of the account.
| ``nonce``
| The nonce of the account.
| ``code``
| The body code of the account, given as an array of byte values. See $DATA_ARRAY.
| ``storage``
| The account's storage, given as a mapping of keys to values. For key used notion of string as digital or hex number e.g: ``"1200"`` or ``"0x04B0"`` For values used $DATA_ARRAY.
|
| The ``logs`` sections is a mapping between the blooms and their corresponding logentries.
| Each logentry has the format:
| ``address`` The address of the logentry.
| ``data`` The data of the logentry.
| ``topics`` The topics of the logentry, given as an array of values.
|
Finally, there is one simple key ``output``
| ``output``
| The data, given as an array of bytes, returned from the execution (using the ``RETURN`` instruction). See $DATA_ARRAY. In order to avoid big data files, there is one exception. If the output data is prefixed with ``#``, the following number represents the size of the output, and not the output directly.
|
**$DATA_ARRAY** - type that intended to contain raw byte data
and for convenient of the users is populated with three
types of numbers, all of them should be converted and
concatenated to a byte array for VM execution.
The types are:
1. number - (unsigned 64bit)
2. "longnumber" - (any long number)
3. "0xhex_num" - (hex format number)
e.g: ``````[1, 2, 10000, "0xabc345dFF", "199999999999999999999999999999999999999"]``````
|
