Score:1

Does the private blockchain have to follow client-server model when considering BFT?

do flag

I'm a newbie, currently interested in data security & integrity.

I'm quite new to blockchain and distributed system theories, and suffering from some unclear doubts/questions on the fault-tolerant consensus.

May I ask for your kind advice on my dull thoughts regarding on the blockchain's true objective?

It would be a great help for me to step forward on understading better concept of consensus.

Here's the summary of what I understand (please correct me if I'm wrong)

In a synchronous network model, it is assumed that one can guarantee the message being delivered within a certain amount of time. In an asynchronous network model, there is no certain guarantee on the message delivery.

In a design perspective, it is easier & more efficient to design a system based on the synchronous model. Even the quorum size requirement can be reduced - synchronous model needs only f+1 votes while asynchronous model needs 2f+1 votes on the consensus. (This is because that the synchronous model can eliminate the possiblity of message dropout (up to f), while the async model needs to consider both message dropout & possibly malicious messages.)

But in a distributed system based on multiple nodes, it is normally impossible to guarantee the message delivery since there is no central manager who can monitor all nodes whether each receives the message or not. That is why most of the blockchain-oriented distributed ledgers (non-currency) are based on the asynchronous consensus schemes such as PBFT (Castro, Liskov 99).

In a private blockchain scenario, I believe that the main & final purpose of the consensus is to let all nodes hold a chain of blocks, where each block has a certain amount of agreements (i.e. more than f signatures).

So, based on the facts above, I got curious whether the fault-tolerance model only stands for the standard "client-server" environment.

What happens if we give up the client-server model, and let the client supersede peers' broadcast communications?

(For a scenario where the client has enough computation power but is just short on storage, so it wants to manage multiple (but few, e.g. 3) replicas to store data via transactions)

To be more specific with a simple example (an authenticated environment with PKI):

Each replica only performs a "block creation (+signing)" and "block finalization (verifying signatures)" logic, and there may exist some malicious replicas (up to f) which try to spread different outputs, which is not originated from the client's transaction.

Let the client (a "data owner/manager" would be a more suitable term now...) visit all replicas, and it handles each replica as below:

  1. Enforce that all replicas work as a synchronized state machine; assure all 3 replicas are synced up (check the latest block of each, and supplement the lagged ones)

  2. Sets a callback (with a timeout) for each replica to guarantee the message delivery

  3. Send a transaction to all replicas, and receive the block (with a signature) generated from the corresponding transaction (assume that the block contains only one transaction)

  4. If more than f signatures (from replicas) for the same block message are collected, deliver the collected signatures to all replicas and order them to finalize the block.

If we do as above, instead of replicas making consensus on their own (i.e. no view-changes), can we still say that the system suffices a BFT model?

It seems that byzantine replicas cannot breach safety, since the client (and honest replicas) will only order/accept block finalization when the block comes with more than f signatures.

The concern is the liveness - can we say that the liveness still holds, since the system can continue (not a client-server model anymore, but the "system" goes on) because the client will ignore the faulty replica response and order honest replicas to finalize?

This curiosity is just stuck in my head, and it's blocking me from clearly understanding why the private blockchain systems need asynchronous consensus process among peers themselves.

(since they already trust the client transactions, and participants are designated by PKI & signatures)

Could anyone be kind and inform that whether my dominant-client example can still suffice the BFT, or something would go wrong?

Thank you so much!

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.