STORE Begins Testing on BlockFin’s ‘Feed & Follow’ Design

BlockFin, @storecoin's Dynamic Proof-of-Stake (DyPoS) consensus engine consists of 2 cooperating p2p networks. One is a larger network of validators and second, smaller network of Messagenodes.

— $STORE Engineering (@STOREdevs) May 25, 2018

The validators, as the name suggests, validate transactions and blocks and the Messagenodes provide storage and bandwidth services to validators. But how do you bring *trust* between the participating nodes?

— $STORE Engineering (@STOREdevs) May 25, 2018

We want something like, "trust, but double-check" model where cryptographic signatures bring *trust* so a *signed* message can be verified by anyone, but how do we double check that a message is relayed correctly?

— $STORE Engineering (@STOREdevs) May 25, 2018

In the "feeds" and "follow" model, each node creates its messages as its own private "feed" and let other nodes "follow" the feed. For example, Messagenodes follow validators for transactions received by them.

— $STORE Engineering (@STOREdevs) May 25, 2018

When Messagenodes in turn follow each other, the transactions are replicated among them. Messagenodes cannot censor, alter, or perform any malicious activities because validators will be watching over them.

— $STORE Engineering (@STOREdevs) May 25, 2018

So, unless a majority of nodes collude to breach the BFT threshold, the network is secure without incurring the overhead of traditional blockchains with O(n**2) complexity.

— $STORE Engineering (@STOREdevs) May 25, 2018

The "feeds" and "follow" model works best in asynchronous environments where network connectivity and quality cannot be guaranteed. This is the exact setup @storecoin envisions for its public blockchain.

— $STORE Engineering (@STOREdevs) May 25, 2018

In a globally distributed network, the latency and up-time cannot be guaranteed. So, BlockFin cannot make any timing assumptions.

— $STORE Engineering (@STOREdevs) May 25, 2018

For example, we cannot say that a block will be produced every N seconds because that makes BlockFin fully *synchronous*. That in turn results in eventual centralization. Why?

— $STORE Engineering (@STOREdevs) May 25, 2018

Strong timing assumptions eventually force a leader or delegate selection because you can guarantee connectivity or latency only when the number of participants is small.

— $STORE Engineering (@STOREdevs) May 25, 2018

So nodes with poor up-time or latency will eventually be ignored/down-voted by others resulting in possible centralization. In BlockFin, nodes make progress asynchronously.

— $STORE Engineering (@STOREdevs) May 25, 2018

So, BlockFin favors "C"onsistency over "A"vailability. Availability is addressed via economic rewards where *all* participating validators and Messagenodes earn a portion of the block reward for the blocks they helped validate.

— $STORE Engineering (@STOREdevs) May 25, 2018

Stronger consistency is important because, remember, blockchains are supposed to be *immutable*? A weaker consistency makes immutability meaningless.

— $STORE Engineering (@STOREdevs) May 25, 2018

Now, back to the testing. In the next few weeks, our goal is to test the "feeds" and "follow" model in a network consisting of 220 validators and 44 Messagenodes. These nodes are globally distributed around the world.

— $STORE Engineering (@STOREdevs) May 25, 2018

We want to measure the performance characteristics of the model to ensure that the a) desire for stronger consistency is achieved and b) network makes progress in unreliable environments.

— $STORE Engineering (@STOREdevs) May 25, 2018

The "feeds" and "follow" model is built using https://t.co/GviCF2wnyd. SSBC's focus on decentralization matches @storecoin's so we want to evaluate it to see how far we can go with it.

— $STORE Engineering (@STOREdevs) May 25, 2018

In the event of network partitions, our desire is for individual nodes to continue to make *local* progress and *eventually* converge their work with the larger network without sacrificing consistency.

— $STORE Engineering (@STOREdevs) May 25, 2018

So, any reliance on one or more nodes for *entire* blockchain is undesirable, because the *continuity* of the chain after the partition depends on the *views* of the connected nodes.

— $STORE Engineering (@STOREdevs) May 25, 2018

So, we want to experiment if a global distribution of a large number of nodes provides better security in the event of network partition. We'll update our findings here after the test.

— $STORE Engineering (@STOREdevs) May 25, 2018