Whenever a private transaction was initiated and executed the address
would be created on the public state when initialising the initial Call.
To prevent this we use the msg's address rather than using the to method
on the state transition object.
Improved private transaction tests by checking existance of private and
public addresses on the incorrect state.
This commit implements a dual state approach. The dual state approach
separates public and private state by making the core vm environment
context aware.
Although not currently implemented it will need to prohibit value
transfers and it must initialise all transactions from accounts on the
public state. This means that sending transactions increments the
account nonce on the public state and contract addresses are derived
from the public state when initialised by a transaction. For obvious
reasons, contract created by private contracts are still derived from
public state.
This is required in order to have consensus over the public state at all
times as non-private participants would still process the transaction on
the public state even though private payload can not be decrypted. This
means that participants of a private group must do the same in order to
have public consensus. However the creation of the contract and
interaction still occurs on the private state.
It implements support for the following calling model:
S: sender, (X): private, X: public, ->: direction, [ ]: read only mode
1. S -> A -> B
2. S -> (A) -> (B)
3. S -> (A) -> [ B -> C ]
It does not support
1. (S) -> A
2. (S) -> (A)
3. S -> (A) -> B
Implemented "read only" mode for the EVM. Read only mode is checked
during any opcode that could potentially modify the state. If such an
opcode is encountered during "read only", it throws an exception.
The EVM is flagged "read only" when a private contract calls in to
public state.
The chain maker and the simulated backend now run with a homestead phase
beginning at block 0 (i.e. there's no frontier).
This commit also fixes up #2388
Added chain configuration options and write out during genesis database
insertion. If no "config" was found, nothing is written to the database.
Configurations are written on a per genesis base. This means
that any chain (which is identified by it's genesis hash) can have their
own chain settings.
Previously all blocks that were already in our chain were never re
announced as potential uncle block (e.g. ChainSideEvent). This is
problematic during mining where you want to gather as much possible
uncles as possible increasing the profit. This is now addressed in this
PR where during reorganisations of chains the old chain is regarded as
uncles.
Fixed#2298
Pending logs are now filterable through the Go API. Filter API changed
such that each filter type has it's own bucket and adding filter
explicitly requires you specify the bucket to put it in.
When a chain reorganisation occurs we collect the logs that were deleted
during the chain reorganisation. The removed logs are posted to the
event mux indicating that those were deleted during the reorg.
This removes the burden on a single object to take care of all
validation and state processing. Now instead the validation is done by
the `core.BlockValidator` (`types.Validator`) that takes care of both
header and uncle validation through the `ValidateBlock` method and state
validation through the `ValidateState` method. The state processing is
done by a new object `core.StateProcessor` (`types.Processor`) and
accepts a new state as input and uses that to process the given block's
transactions (and uncles for rewords) to calculate the state root for
the next block (P_n + 1).
Patrick Mylund Nielsen
bas-vk
Jeffrey Wilcke
Bas van Kervel
Péter Szilágyi
Bas van Kervel
zsfelfoldi
Jeffrey Wilcke
Leif Jurvetson