mirror of https://github.com/poanetwork/quorum.git
Update NOTES.md
This commit is contained in:
parent
9e08c25f2c
commit
eab8d793f9
102
NOTES.md
102
NOTES.md
|
@ -2,7 +2,57 @@
|
|||
|
||||
## How does private state work?
|
||||
|
||||
Let's look at the EVM structure:
|
||||
Original commit from Jeff explains the dual public and private state with INITIAL restrictions:
|
||||
```
|
||||
commit 763f939f4725daa136161868d3b01fa7a84eb71e
|
||||
Author: Jeffrey Wilcke <jeffrey@ethereum.org>
|
||||
Date: Mon Oct 31 12:46:40 2016 +0100
|
||||
|
||||
core, core/vm: dual state & read only EVM
|
||||
|
||||
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.
|
||||
```
|
||||
|
||||
|
||||
Some things have changed since, let's look at the EVM structure in some more detail:
|
||||
|
||||
```go
|
||||
type EVM struct {
|
||||
|
@ -60,53 +110,3 @@ func (env *EVM) Pop() {
|
|||
Note the invariant that `StateDB` always points to the current state db.
|
||||
|
||||
The other interesting note is read only mode. Any time we call from the private state into the public state (`env.privateState != statedb`), we require anything deeper to be *read only*. Private state transactions can't affect public state, so we throw an EVM exception on any mutating operation (`SELFDESTRUCT, CREATE, SSTORE, LOG0, LOG1, LOG2, LOG3, LOG4`). Question: have any more mutating operations been added? Question: could we not mutate deeper private state?
|
||||
|
||||
|
||||
Original commit explanation:
|
||||
```
|
||||
commit 763f939f4725daa136161868d3b01fa7a84eb71e
|
||||
Author: Jeffrey Wilcke <jeffrey@ethereum.org>
|
||||
Date: Mon Oct 31 12:46:40 2016 +0100
|
||||
|
||||
core, core/vm: dual state & read only EVM
|
||||
|
||||
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.
|
||||
```
|
||||
|
|
Loading…
Reference in New Issue