Rough logic behind a toy example of an approach to a database in the style of [SUS08,RAD09] if this interfaces with one or more blockchains. Suppose the aim is publishing to a blockchain, producing values, but also building a distributed database framework that allows services joining the system and leaving the system to pass around incomplete operations and complete them as information appears.

Using a lot of web workers (each is its own thread) and publishing just the invariants (values that results where order doesn't matter) to the blockchain as these values become available, via a single threaded package like that, may be the way to most quickly build a demo, which, if necessary, can later be refactored.

Suppose a f.F [x] is one of all possible operations requiring x many variables. Further suppose operations considered are those which can partially complete if not all variables are present, but will not entirely complete. That is, if x-2 variables are given, it will produce an output of the type that, if taken as an input to f, if the missing 2 variables are later supplied, will approximately continue where it left off until it completes. Similar to futures in some languages.

Implement perhaps spawn(x)(cell,services(y, A.Script[x+1] )) would produce x many threads each corresponding to (procedurally) named block that is visible or not. If visible, it also prints to the chain via your preferred package or framework.

Each of the x many threads sends a message with the name (id) of its block to each of y many services.

These are services running on, say, heroku, and they listen for some blockchain event. And then if or when the event occurs, read all cells, whose names they have, in the toy example just the current state of the blocks, plus the value provided by the event occurring, run the script, and write to one of the blocks. The script may involve running another spawn(...)(...) type script that waits and listens for additional blockchain events. (The logic then becomes multicategorical.) Initially the blocks are empty and the operation only partly completes.

But now one block stores the result of a begun but not finished operation. Eventually the cells are filled with results, and this allows some operations that were unfinished to actually be completed, or help other operations complete. The threads do the passing and reading and writing in the background, starting and stopping when sent a message by services that know their id. The other service also reads these cells, and so unfinished operations propagate from service to service until they complete. When completed they get posted. And that may or may not be an event for which some service listens.