...

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#L463Ethereum handles block reorganizations by effectively snapshotting the current state after each block. Thus if a fork is started from a previous block, an Ethereum node will revert back to a snapshot of that previous block's post-state and then apply transactions starting from there. We can follow a similar approach in Rchain: essentially the TS will be responsible for applying transactions but not reverting them.

----------

Related code snippets

...