I am currently trying to specify the Tuplespace (TS) so that it cleanly interfaces with Casper. This is an ongoing conversation with Michael Birch.

Here is the planned pseudocode for the TS implementation

```
produce data
case no matching continuation
store data
log data
case partially matching continuation
store data
log data
case fully matching continuation
consume match
log match

consume continuation
case no matching data
store continuation
log continuation
case partially matching data
store continuation
log continuation
case fully matching data
consume match
log match
```

Casper will then read the log output of the TS and use that to make proposals in the consensus protocol.

Open Questions

The TS updates the DB so that it reflects a state that is ahead of what the state would look like if it was only based on finalized transactions. This is a similar problem to what Bitcoin or Ethereum encounters when there is a block reorganization due to a swap in forks.

Note

I'm working on figuring out block reorganizations for the Tuplespace implementation and I'm studying how pyethereum does it. I've posted this on the pyeth-dev gitter chat but it seems somewhat inactive. Maybe someone can put me in contact with one of the devs? --- Why is it possible to apply_block to a temp_state that hasn't set its storage data yet https://github.com/ethereum/pyethereum/blob/develop/ethereum/pow/chain.py#L304 ? I'm expecting to see some code where the storage data is (re)set like https://github.com/ethereum/pyethereum/blob/develop/ethereum/state.py#L463.

----------

Related code snippets

def consume(ctxt_tuple: Tuple2[Continuation, Tuple2[Code, Any]], location: Tuple3[List[Channel], List[Pattern], Persistent]): Tuple2[Continuation, List[Product]]

type Candidate = Tuple2[Tuple2[Int, Channel], Tuple2[Int, Data]]
List[List[Candidate]]

def select_match(candidates: List[List[Candidate]]): List[Candidate] = {

}