Design issues for Permissioned blockchains

· BGP (Byzantine General Protocols) protocols such as PBFT provide consensus mechanisms in permissioned BCs.

· A BGP protocol allows the network to detect the behaviour of malicious nodes, and all working nodes can reach a consensus if the number of compromised node is less than one-third of the total number of nodes, or n >= 3f +1 where n is the number of nodes and f is the number of compromised nodes.

· PBFT has three phases, and each node maintains its own view of the network.

· The protocol is initiated by a leader in the network. Even if the leader failed, other nodes take over the responsibility and resume the operation.

· A simplified 3-phase process is as follows:

o A leader sends out pre-prepare message to all the nodes;

o Each node received the message will produce a response, and send the response, i.e., prepare, to every node;

o After receiving sufficient such as 2/3 prepare messages from the nodes, each can commit to the agreement, and send out the commit message to everyone.

· Thus, to reach a consensus, there will be three rounds of messaging, one for each pre-prepare, prepare, and commit message.

· The PBFT is more complicated as it also handles the case when a leader is crashed. In permissioned BCs, a Byzantine consensus will be needed only when a new block is to be created, and all working nodes need to agree with the contents of the new block.

· However, for an enterprise system, due to asynchronous message arrival and large volume of data, each node may receive different messages since the previous block creation, and thus it can be difficult for all the nodes to agree with all the contents of the new block even if the nodes are working properly.

· If the system has few transactions per second, this is not an issue, but this is an issue for an enterprise system. Thus, the goal of consensus protocol is modified as follows:

1. Most of working nodes can reach a consensus on most of items in a new block;

2. Detection of those failed nodes so that they can be safely ignored during consensus building;

3. Detection of those compromised nodes that sent out different messages to different nodes to disrupt the operation;

4. Those items that should be in the BC, but not voted in the current block, will be placed in the next block to be voted in the future;

5. Those items that should not be in the BC should be clearly identified and should not be placed in a queue to be considered in the next block.

· Issue 1 is a relaxed version of a common BC.

· Instead of having identical contents, one can allow each node to have slightly different contents in a new block yet to be voted on.

· This is to allow each node to receive different messages from different sources due to asynchronous messaging. However, as a part of the voting process, all working nodes must decide on the contents of the new block.

· In this way, after voting, all the nodes will have identical content in the newly created block.

· Issue 2 is important in a permissioned BC as failed nodes should not be involved in future voting until

they are fully recovered. The recovered node also needs to retrieve any missing data during the absent period.

· Issue 3 is important as compromised nodes should not be involved as a compromised node can cause significant troubles for a BC. In fact, they should be excluded from the BC operation completely as soon as they are identified as the damage done by compromised nodes is far greater than the damage done by failed nodes.

· Issue 4 is a new problem in a permissioned BC as each second numerous data may enter the BC, and those valid data must be stored to maintain the trust of the BC. For example, a lottery machine may send out ticket information to a permissioned BC. Due to message delays, some messages did not get into every node, and they were not included in the new block. As they are valid tickets, they should be stored in the next block. This scenario is considered as false negative as a valid message was excluded due to various reasons.

· Issue 5 is a new problem due to Issue 4 as data not included in the previous block can be included in the next new block to be created, thus potentially an increasing number of data can be postponed and continued to be considered for inclusion. But some of these data may not be valid at all, and should be removed for good rather than to be re-considered in future blocks. This scenario is considered as false positive as invalid messages continued to be considered in block creation.