Story: The network needs to have the ability to add and remove participants to specific activities of the network, such as endorsement, consensus & sorting, and committing to the ledger. This will enable vibrant and reliable growing networks to evolve, with many actors executing purposeful actions for the environment based on their desired level of participation.
Based on specific needs participants of the blockchain network will not want or need to handle all the functions required in a distributed ledger system (signing, sorting, writing to, or maintaining the ledger). Some of these operations are too costly for business or compute reasons.
Multiple phased approach to make consensus pluggable, scalable (see attachment below) &
Phase 1 -
- Decouple Consensus service from peers
Story: As a blockchain network joiner/starter, I want to be able to pick the role or function I will perform in the blockchain network, so that I am not forced into performing functions on the network which I don't have any vested interest. I also want a better more versatile framework which enables me to create a network with an alternate consensus algorithm that better suits my goals, that being performance, more/less required trust/verification, etc.
In the current architecture all the functions of the fabric are handled by all of the nodes on the network. In order to make the network more flexible, scalable and pluggable we need to modularize the code base. This requires removing the PBFT function from the peers and creating a different architecture based on a model of endorsers, consenters, and committers components. Each of these components need to be self contained (expected input & output). The result will be there is no longer what has been generically called a 'validating peer', instead when joining a node to a network there will be the ability to choose 1 or more components to create the node. The component(s) chosen will have different tasks(actions) to perform. Endorsers will simulate and sign or reject transactions, consenters will complete PBFT on the transactions and order the transactions, committers will receive the ordered batches of transactions from the consenters and write to the ledger. The choice of action performed by the node when joining the network is how the peer to be known as on the network. For further information please see the design discussion at https://github.com/hyperledger/fabric/wiki/Next-Consensus-Architecture-Proposal
MVP defined as :
Transaction successfully submitted via the SDK to the endorser, transaction simulated by the endorser, signed, and returned to the SDK. SDK will then send to single consenter node to 'sort', and send to committer which will write to the ledger. This is the happy path of a single transaction can be successfully processed. For this MVP, a rejected transaction the endorser should execute, fail and simply send rejection back to SDK and drop the transaction.
- Dynmically add/remove endorsers from network
- Basic endorsement policy
Story: Networks need the ability to have someone else join, so that they can, at minimum, have all required stakeholders actively participate in endorserment with a basic endorsement policy.
Phase 2 -
- Consensus protocol and transport layer
- Scale, performance
Story: Networks needs to be able to have a large cluster of consenters in the network so that they can have at minimum a valid number of consenters for the blockchain model with tolerance