Updated VM tests

2 files changed, 53 insertions, 19 deletions

diff --git a/docs/transaction_tests/index.rst b/docs/transaction_tests/index.rst
index eb06504f6..f4bac251d 100644
--- a/docs/transaction_tests/index.rst
+++ b/docs/transaction_tests/index.rst
@@ -4,11 +4,21 @@ Transaction Tests
 =================
 
 Describes a complete transaction and its `RLP <https://github.com/ethereum/wiki/wiki/RLP>`_ representation using the .json file.
+
+=================== ==============================================================
+Location            `/TransactionTests <https://github.com/ethereum/tests/tree/develop/TransactionTests>`_
+Supported Hardforks ``Constantinople`` | ``EIP158`` | ``Frontier`` | ``Homestead``
+Status              Actively supported
+=================== ==============================================================
+
+Test Implementation
+-------------------
+
 The client should read the rlp and check whether the transaction is valid, has the correct sender and corresponds to the transaction parameters.
 If it is an invalid transaction, the transaction and the sender object will be missing.
 
-Basic structure
----------------
+Test Structure
+--------------
 ::
 
 	{
@@ -36,7 +46,7 @@ Basic structure
 	}
 
 Sections
---------
+^^^^^^^^
 
 * ``rlp`` - RLP encoded data of this transaction
 * ``transaction`` - transaction described by fields
diff --git a/docs/vm_tests/index.rst b/docs/vm_tests/index.rst
index 16716d53b..4ab33c921 100644
--- a/docs/vm_tests/index.rst
+++ b/docs/vm_tests/index.rst
@@ -3,12 +3,20 @@
 VM Tests
 ========
 
-Found in ``/VMTest``, the VM tests aim is to test the basic workings of the VM in
-isolation. This is specifically not meant to cover transaction, creation or call 
+The VM tests aim is to test the basic workings of the VM in
+isolation.
+
+=================== ==============================================================
+Location            `/VMTests <https://github.com/ethereum/tests/tree/develop/VMTests>`_
+Supported Hardforks Currently only one fork support depending on latest test fill
+Status              Actively supported
+=================== ==============================================================
+
+This is specifically not meant to cover transaction, creation or call 
 processing, or management of the state trie. Indeed at least one implementation 
 tests the VM without calling into any Trie code at all.
 
-It is based around the notion of executing a single piece of code as part of a transaction, 
+A VM test is based around the notion of executing a single piece of code as part of a transaction, 
 described by the ``exec`` 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 
@@ -18,6 +26,15 @@ of accounts are detailed in the ``post`` portion to specify the end world state.
 The gas remaining (``gas``), the log entries (``logs``) as well as any output returned 
 from the code (``output``) is also detailed.
 
+
+Test Implementation
+-------------------
+
+It is generally expected that the test implementer will read ``env``, ``exec`` and ``pre`` 
+then check their results against ``gas``, ``logs``, ``out``, ``post`` and ``callcreates``. 
+If an exception is expected, then latter sections are absent in the test. Since the 
+reverting of the state is not part of the VM tests.
+
 Because 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 SHA3-256("n").
@@ -29,13 +46,8 @@ details each ``CALL`` or ``CREATE`` operation in the order they would have been
 Furthermore, gas required is simply that of the VM execution: the gas cost for 
 transaction processing is excluded.
 
-It is generally expected that the test implementer will read ``env``, ``exec`` and ``pre`` 
-then check their results against ``gas``, ``logs``, ``out``, ``post`` and ``callcreates``. 
-If an exception is expected, then latter sections are absent in the test. Since the 
-reverting of the state is not part of the VM tests.
-
-Basic structure
----------------
+Test Structure
+--------------
 
 ::
 
@@ -63,10 +75,8 @@ Basic structure
 	   ...
 	}
 
-Sections
---------------------------------------------------------------------------------
-
-The ``env`` section:
+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.
@@ -75,7 +85,8 @@ The ``env`` section:
 * ``currentTimestamp``: The current block's timestamp.
 * ``previousHash``: The previous block's hash.
 
-The ``exec`` section:
+The exec Section
+^^^^^^^^^^^^^^^^
 
 * ``address``: The address of the account under which the code is executing, to be returned by the ``ADDRESS`` instruction.
 * ``origin``: The address of the execution's origin, to be returned by the ``ORIGIN`` instruction.
@@ -86,6 +97,9 @@ The ``exec`` section:
 * ``gasPrice``: The price of gas for the transaction, as used by the ``GASPRICE`` instruction.
 * ``gas``: The total amount of gas available for the execution, as would be returned by the ``GAS`` instruction were it be executed first.
 
+The pre and post Section
+^^^^^^^^^^^^^^^^^^^^^^^^
+
 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.
@@ -93,6 +107,9 @@ The ``pre`` and ``post`` sections each have the same format of a mapping between
 * ``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 callcreates Section
+^^^^^^^^^^^^^^^^^^^^^^^
+
 The ``callcreates`` section details each ``CALL`` or ``CREATE`` instruction that has been executed. It is an array of maps with keys:
 
 * ``data``: An array of bytes specifying the data with which the ``CALL`` or ``CREATE`` operation was made. In the case of ``CREATE``, this would be the (initialisation) code. See $DATA_ARRAY.
@@ -100,12 +117,19 @@ The ``callcreates`` section details each ``CALL`` or ``CREATE`` instruction that
 * ``gasLimit``: The amount of gas with which the operation was made.
 * ``value``: The value or endowment with which the operation was made.
 
-The ``logs`` sections is a mapping between the blooms and their corresponding logentries. Each logentry has the format:
+The logs Section
+^^^^^^^^^^^^^^^^
+
+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.  
 
+The gas and output Keys
+^^^^^^^^^^^^^^^^^^^^^^^
+
 Finally, there are two simple keys, ``gas`` and ``output``:
 
 * ``gas``: The amount of gas remaining after execution.