Merge pull request #292 from holgerd77/update-docs

Structural overhaul of the whole docs / Updated state test section / info box on test type status

1 files changed, 0 insertions, 132 deletions

diff --git a/docs/state_tests/index.rst b/docs/state_tests/index.rst
deleted file mode 100644
index 978d2542a..000000000
--- a/docs/state_tests/index.rst
+++ /dev/null
@@ -1,132 +0,0 @@
-.. _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"]``````			 
\ No newline at end of file