By Andre Cronje

Transaction responsiveness is a concept required for user experience viability. Irrespective of overall throughput, you would like to submit a transaction and receive confirmation of the transaction in real-time.

Consider you want to buy a coffee with Bitcoin. You go to the shop, you scan the QR code, and you send the transaction. The transaction itself is propagated through the network (travels to all nodes) within a few seconds. But it has to be packed into a block (~10 minutes) before it is accepted.

This means a bitcoin payment has a responsiveness of at least 10 minutes. Because of the longest chain rule, most likely more (3+ blocks).

Next consider a BFT / voting based solution. Where we have a proposer that proposes a block, and we have validators who cast their votes on the block. If the block receives more than 2n/3 votes, the block is approved (and finalized). This at least means we don’t have to wait for the longest chain rule.

Let’s say the BFT solution proposes a block every 2 seconds. That is acceptable from a responsiveness point of view. However, what if the block can only pack 10 transactions, and there are 100 transactions? If your transaction is transaction number 100, it will take 10 blocks until your transaction is finalized (here throughput becomes important).

So let’s consider the block a bottleneck, and let’s remove the block. Assume we have transactions coming into the system, and we would like to process them as fast as possible. We already do this via the underlying broadcast mechanism (which shares a received transaction with nodes as fast as it can transfer).

A traditional BFT solution requires 3 rounds of voting to finalize / commit a transaction. And this can be “attacked” by malicious actors, causing view changes, this won’t be discussed in detail for now. So instead, we want an asynchronous way to vote on the transactions.

As a validator receives a transactions, it creates a new type of message a transaction vote, and it signs this message. Now again, it uses traditional gossip to transfer this message to all nodes.

On receipt of a transaction vote, it compares this against all the votes it currently has and the current validator set. If the votes are greater than 2n/3 it can consider the transaction finalized and broadcast this to the application layer.

So now, we have transaction responsiveness that can occur as fast as validator message signing + network broadcasting. Both achievable with sub second latency (network graph dependent). But what was the trade off? We increased message overhead, message overhead has increased to n * t (where n is the amount of validators and t is the amount of transactions), and we have decreased security (because of the asynchronous manner of votes we might never receive 2n/3 votes).

Txflow is not a new consensus, but instead a protocol to run concurrently to consensus. The reason for this is the decreased security. Regular consensus systems (such as BFT creating blocks and voting on them) are still required as a secondary (or perhaps rather primary) security mechanism. So if a transaction did not receive enough votes before the block proposal that would have included it, it will still be added.

Txflow in an optimistic environment increases responsiveness which is required for sufficient UX. While traditional consensus mechanisms (like Lachesis) allows for full security.