Chaincode as a Kubernetes service (CCaaKS)

CCaaKS contains CICD pipelines to support the software life-cycle of chaincode in Hyperledger Fabric. This document provides a comprehensive analysis on different aspects of CCaaKS with a comparison on the existing methodology of chaincode deployment in Hyperledger Fabric. The content is structured as follows:

• Life-cycle of a chaincode
• Impact on chaincode life-cycle
• Pros and cons of CCaaKS
• Concerns related to CCaaKS

Life-cycle of a chaincode

The following diagram illustrates how the life-cycle of a chaincode is impacted by both the default and CCaaKS processes.

Impact on chaincode life-cycle

The following table contains a summary of the key differences between 2 approaches in terms of the chaincode life-cycle, i.e. using the default method provided by Hyperledger Fabric vs using the CCaaKS method as proposed in this repository.

Phase	Common key points	Default process	CCaaKS
Package chaincode	Requires tar.gz extension and specific folder structure	Use peer binary for packaging Package contains metadata and implementation	Can use external tools to package as long as it adheres to the folder structure Package contains only metadata to connect to the external chaincode
Install chaincode	Requires peer admin role Different versions can be installed on different organizations Allows logics specific for each organization Same package can be used in/across organizations for coherence Installation returns package ID (label + hash)	Peer builds the chaincode and returns any build errors Package ID provides integrity of the source code	Does not involve peer Chaincode is installed and maintained on a separate instance Integrity of the source code can not be verified by package ID Refer to the notes below for countermeasures Requires a custom buildpack
Approve chaincode definition	Requires organization admin role Needs to be done once for an organization until endorsement policy is satisfied with the number of organizations Can enable Init function to be required for the chaincode, which may be used for initial validations during the bootstrap of a chaincode Same chaincode instance can be used with different definitions for different purposes
Commit chaincode definition	Requires organization admin role Needs to done once for the channel Signature policy allows for a distinct set of approvers	Launches chaincode container	Chaincode can already be up and running when committing the definition
Update or upgrade chaincode	Upgrades should have backward compatibility	For each upgrade, an update must be carried out Chaincode container is not affected if it is only an update	Update and upgrade processes can be done independently of each other

Pros and cons of CCaaKS

The following table provides pros and cons of CCaaKS compared to the default methodology in Fabric to deploy chaincodes (using in-built builders by the peer to start a chaincode).

	Point	Explanation
Advantages	1. Compilation errors at build-time, not runtime	As we now compile, build and deploy the image to the container registry in advance, compilation errors are not validated during the runtime installation on a peer
	2. No tight coupling with Docker	Running chaincode as a Docker container is not mandatory anymore. In addition to the flexibility, this eliminates security vulnerabilities that come with DinD or binding Docker sockets.
	3. Faster deployments	This process does not require chaincode definitions to be approved and committed with each chaincode deployment. Further, it does not require installing chaincode on each peer, which can be time-consuming and error-prone.
	4. Single deployment	Chaincode needs to be deployed only once instead of installing on every peer multiple times.
	5. Single source of truth	Multiple deployments might lead to inconsistent chaincode package installations on peers which is now eliminated as they all can interact with the same chaincode service
	6. Administration and development roles are separated	Admins can only focus on network infrastructure, while developments can take place separately without needing an administrator.
	7. Chaincode process life-cycle is decoupled from Chaincode peer life-cycle	This enables CICD pipelines to be integrated into chaincode development.
	8. Higher reliability and availability	Chaincode service can benefit from Kubernetes features such as fail-over, autoscaling and load balancing.
	9. Convenience in managing chaincodes	Chaincode service management can be achieved within the Kubernetes context.
Disadvantages	1. Secure communication between peer and CC is required	Since chaincode is running externally (which may even involve traversing through external networks), peer to chaincode communication should be secure and safe.
	2. Integrity of chaincode can not be verified by peer	Since peer package contains only metadata, peer has no further resource to verify the implementation of a chaincode
	3. Chaincode process and chaincode peer life-cycles are intertwined	Despite the separation, chaincode life-cycle is not entirely removed from chaincode peer life-cycle since it still requires to be packaged and installed on the peer whenever the metadata changes.
	4. Prerequisites	External buildpack needs to be implemented, configured with core.yaml and copied into the file system of each peer.
	5. Necessity of ACLs on chaincode deployments	Since peer admins are no longer required, chaincode deployments should be governed and restricted.

*1-7 advantages are inherited from CCaaS

Concerns

Integrity of a chaincode

This problem intends to address the inability of a peer to verify the implementation of a chaincode.

Can different versions of a chaincode be running in CCaaKS?

From the service point of view, there is no constraint to restrict the bootstrap of multiple chaincode instances in CCaaKS. This is perfectly aligned with the core concepts of Fabric which enables multiple chaincode packages to be executed whenever appropriate.

How does a peer ensure that it communicates with the correct chaincode?

By means of the connection.json package. As long as this package is reliable, peer will connect to the correct endpoint for chaincode interaction despite the fact that there can be many chaincode instances running in the cluster.

But how can the peer verify if this chaincode instance has the correct implementation?

In the current CCaaKS (as well as in CCaaS) model, peer is agnostic of the chaincode implementation and hence unable to verify the integrity of the chaincode.

What are the potential risks associated with the absence of integrity?

This can lead the peer to interact with an invalid/malevolent chaincode instance. For example, the chaincode service can be replaced with a different implementation without any impact on the peer, if access control on chaincode deployments are not properly designed.

What are the possible suggestions to enable integrity within the peer?

1. Include a checksum of source code to metadata
   - needs modifications to the Fabric core implementation
   - chaincode process and peer life-cycles become more coupled
2. Add validation plugins during the endorsement phase of a transaction
   + does not require Fabric core to be changed
   - does not solve peer connecting to incorrect chaincodes
   - can be adversarial in cases where endorsement policies are not strong enough
3. Sign metadata by chaincode before installation on the peer and sign every subsequent response from the chaincode instance
   - needs modifications to the Fabric core implementation
   - buildpack contains cryptography logics
4. Include the launch process of the chaincode in buildpack (with build/run binaries)
   + solves the issue of connecting to multiple chaincode instances
   - CD becomes separated from CI
   - introduces peer administration into chaincode lifecycle
5. Add commonly agreed testing package/framework for the chaincode package, which can be invoked either during build-time (by CICD pipelines) or runtime (via Init function).
   - complexity in designing test framework to capture all adversarial outcomes