Previously we had populated the public receipt `failed` field with the
result of the transaction. This is correct for public transactions. It's
also correct for successful private transactions. But it's not correct
for failing private transactions, because their public receipt should
not indicate failure. The fix is straightforward.
Testing:
I used this contract:
contract RevertTest{
uint public newValue;
function revertFunction() public{
uint a = 1;
require(a == 0);
}
}
After deploying the contract I sent in several failing transactions via
function sendBad() {
eth.sendTransaction({
from: eth.accounts[0],
data: web3.sha3("revertFunction()"),
gas: 0x47b760,
privateFor: ["ROAZBWtSacxXQrOe3FGAqJDyJjFePR5ce4TSIzmJ0Bc="]
});
}
Watching the logs (`1.log` and `2.log`), I saw the `TX-ACCEPTED` events
scroll as I sent `revertFunction` transactions. I see 10 `TX-ACCEPTED`
events in both logs (1 for deploy and 9 tests via `sendBad`).
Via extra logging, in `1.log` I see that the public receipts have status
`1`, whereas private receipts have status `0`. In `2.log` they all have
status `1`.
All nodes stayed up the whole time.
Fixes#434
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.
This implements a generic approach to enabling soft forks by allowing
anyone to put in hashes of contracts that should not be interacted from.
This will help "The DAO" in their endevour to stop any whithdrawals from
any DAO contract by convincing the mining community to accept their code
hash.
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.
* change gas cost for contract creating txs
* invalidate signature with s value greater than secp256k1 N / 2
* OOG contract creation if not enough gas to store code
* new difficulty adjustment algorithm
* new DELEGATECALL op code
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).