Skip to content
This repository has been archived by the owner on Mar 30, 2018. It is now read-only.

Fabric Next

Jump to bottom
Binh Q Nguyen edited this page Jun 27, 2016 · 34 revisions

Status: Draft (not ready for review; not yet prioritized)

This page contains a list of high-level items proposed for development of the next generation Fabric. It includes both existing feature enhancements and new features.

The key motivation for the next generation is modularization to achieve plug-ability and concurrency. As outlined in the next consensus architecture and the next ledger structure, we want to enable different implementations to plug in at different points, including consensus, storage, and membership services. We can achieve concurrency at endorsers and consenters based on the transaction endorsement policy, which allows driving multiple channels of consensus as a service.

Deployment Scenarios

The new architecture offers great flexibility in deployments. As the current generation, the simple 1 peer development environment, where a developer may quickly iterate over edit-compile-debug of the fabric code or a chaincode, is still intact. What change are the varieties of network deployment options, from a simple network of a few peers to a complex hundred of peers with different configurations possible.

Conceptually a peer may perform all the functions (submitting, endorsing, ordering, and committing transactions); this is called full peer, or peer. A partial or light peer may perform a specific task like consensus (ordering transactions) or a combination of submitting, endorsing, and committing transactions. A member of a network generally owes a peer and/or some light peers. For high availability, a member may deploy multiple peers but 1 endorsement vote. Currently we have 2 types of peers: Validating peer (VP) and none-validating peer (NVP). We may roughly think of VP as a full peer and NVP as a light peer with submitting and committing tasks.

Network Deployment

A simple network could be made up of several full peers, where each peer owed by a member with unique enrollment identity in a permissioned network. Building on this, a member may add more peers to increase availability and to support fail-over; however, these single-member peers must operate as a cluster with 1 vote on endorsement. A cluster of peers could be achieved by a shared ledger and a proxy to dispatch messages to the member peers, or a leader-followers pattern.

Consensus Network

Consenters may independently operate to form a consensus network, isolating from the other peer functions (submitting, endorsing and committing transactions). This capability allows the members to set up a consensus network such that it can serve multiple blockchains, which only need to deploy light peers (without consenter enabled). The consensus network can be agnostic to the transactions enabling data isolation such that submitters may replace the transaction payload with its hash.

Chaincode

Currently we have 2 types of chaincodes: System and user chaincodes. System chaincode is built with the peer code and initialized during peer startup, whereas, user chaincode is built during deploy transaction and runs in a sandbox (default to Docker container).

System chaincode concept allows us to reorganize the peer chaincode services into system chaincodes. For example, chaincode life-cycle (deploy, upgrade, terminate), chaincode naming, key management, etc can be implemented as system chaincodes since these are "trusted" operations which require access to the peer.

  1. Life-cycle management issue 1127: A chaincode begins life at deployment and ends at termination (out of service). Along this timeline, there might be several upgrades either to fix bugs or to amend functions. We have implemented deployment (via Deploy transaction) but have not done (completed) upgrade and terminate. Upgrading of a chaincode is not only involved code changes but also data (and potentially security) migration. We can implement chaincode life-cycle in a system chaincode, named "uber-chaincode", such that, to deploy a chaincode, we would send an Invoke transaction to the uber chaincode; similarly for update and terminate. This means that, our transaction types now would only consist of Invoke and Query. And Deploy transaction is no longer needed.

  2. Naming services:

  3. Calling another chaincode with security

  4. Access control: Enable access control on chaincode deployment, function invocation

Membership Services
  1. TCert attributes:
  2. Decentralization:
  3. Key rotation
  4. HSM support
  5. Auditability
Consensus
  1. Decouple consensus from peer:
  2. Dynamic membership: Allowing peers to come and go
  3. Refactoring (submitter, endorser, committer)
  4. Consensus channels
Ledger
  1. Transaction read/write-set
  2. Enhance API to enable pluggable data store
  3. Simulate transaction execution
  4. Data store reference implementation (file-base)
  5. World state cache
  6. Ability to archive/prune "spent" transactions
  7. SQL-like queries (point in time, filter)
Protocol
  1. Enhance message structures: Remove unused or duplicated fields; version number
  2. Status codes and messages
  3. Error handling
  4. Extensions
SDK
  1. Nodejs: Event handling, REST API
  2. Java
  3. Go
Transaction confidentiality
Upgrade Fabric
  1. No protocol changes
  2. Protocol changes
  3. Ledger migration?
Integration (SoR)
Clone this wiki locally