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
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
.. _state_tests:
General State Tests
===================
Found in `/GeneralStateTests <https://github.com/ethereum/tests/tree/develop/GeneralStateTests>`_,
the state tests aim is to test the basic workings of the state in isolation.
A state test 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``.
.. note::
The structure description of state tests is outdated. A more up-to-date description
can be found `here <https://github.com/ethereum/EIPs/issues/176>`_ and should be
integrated in these docs in the future.
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"]``````
|
