search

orbs-network / orbs-spec

Orbs platform protocol and service specifications, network architecture, etc
MIT License
29 stars 6 forks source link

VM should use block height from state storage rather than block storage #109

Open electricmonk opened 5 years ago

electricmonk commented 5 years ago

There's a race condition in virtual machine that might cause reading from stale state. It is documented here: https://github.com/orbs-network/orbs-network-go/issues/400#issuecomment-434726027

It's easy to prevent this race from happening. In virtual machine, it currently takes the recent block height from state storage - see call to StateStorage.GetStateStorageBlockHeight(). We can change this call to be on block storage instead - BlockStorage.GetStateStorageBlockHeight().

talkol commented 5 years ago

We need to make the decision in the linked [comment](orbs-network/orbs-network-go#400 (comment)) @OdedWx @erankirsh

OdedWx commented 5 years ago

Few comments:

  1. Height from block storage implies that not updates state storage will hold (on a short race) / fail the call (on state storage not in sync)
  2. Reading from the block storage on every call seams expensive in a a micro-service arch. In general the VM requires a high BW / low latency access to the state storage so this is likely to be solved while frequent access to the block storage is less intuitive.
  3. Another approach which isn't too nice is to delay the TP update until the state storage acknowledges.

Let's discuss if we're willing to live with the race before adding the block storage to the call flow.

talkol commented 5 years ago

I was convinced by @OdedWx that we should keep the spec as is. Meaning keep the call to the state storage and not the block storage.

If we look at service affinity, the VM and SS are affiliated and communicate frequently. Adding a hot connection between VM and BS is a bad idea.

electricmonk commented 5 years ago

but this leaves the system in a non-deterministic state