2019-05-29 Minutes

Owned by Attila Klenik
May 30, 2019
3 min read

Hyperledger Caliper Project

Community Regular Meeting
May 29, 2019 (9AM – 10AM UTC)
via Zoom

Participants

Nick Lincoln, Yu Pan, Qinghui Hou, Feihu Jiang, Attila Klenik

Proposed agenda items

  1. Gathering the requirements for publishing the npm packages
  2. Gathering the requirements for publishing Docker images 
  3. Brainstorming about how a privacy-preserving Caliper architecture would look like
  4. Hopefully coming up with a short and focused roadmap

Agenda discussion summary

NPM package requirements

  1. Goal: publish the packages as soon as possible (preferably in June) to see the bad/good practices as soon as possible (and it's also more convenient for users)
  2. Nick will split the caliper-application package into a CLI and a sample part.
  3. The packages will be published manually first before making it a CI process (just to come up with the correct workflow for publishing)
  4. Currently, there isn't any API reference doc, so the adapter and architecture documentation will serve as an API specification.
  5. About versioning:
    1. The adapter packages will match the corresponding backend platform versions, e.g., caliper-fabric@1.4.0 => published with v1.4.0 SDK for Fabric 1.4.0 networks
    2. This will take every (major/minor/patch) versioning part from the adapter versions, so their versioning must be solved elsewhere.
    3. The actual package semantic versioning will happen in the CLI package. Whenever an adapter package should be bumped, the CLI package version will be bumped instead.
    4. We'll see how/if this works. If it's not flexible enough, we'll reach out to other teams about best practices.
  6. Summary: let's publish as soon as possible, so we can fix the errors (there will be some, probably) also as soon as possible

Docker image requirements

Once the NPM packages are published, "containerization" becomes easier. However, we still need to deprecate the current "worker process spawning" approach and decouple the clients from the master process. 

  1. This will result in something like the current Zookeeper mode, i.e., completely distributed workload generator clients
    1. Scaling out will be much easier
    2. The deployment will become easier for multiple "container platforms"
  2. Zookeeper might be a little overkill for this purpose
    1. Caliper doesn't need high availability as a service, it's not a long-running process (at least compared to a Fabric network)
    2. Some lightweight (e.g., REST) communication middleware is needed

Summary: NPM packages and loosely-coupled distributed clients are needed for containerization.

Privacy-preserving Caliper architecture

This document overviews the privacy support of different platforms. Even though Caliper has been removed from it (since it's not an actual BC platform I guess), the previous concerns are still valid:

  1. Caliper acts as a super-user in the network, it knows every private key, thus can create arbitrary network artifacts (e.g., channels)
  2. This is convenient for testing purposes and traditional benchmarking since one organization/user/evaluator can spin up an arbitrary infrastructure and benchmark it 
  3. However, when evaluating industrial deployments, then there are some constraints (taking Fabric as an example)
    1. Different organizations will manage different physical nodes (thus access to them are not centralized)
    2. Certain chaincodes might not be public to every participant (Fabric supports this)
    3. The realistic workload of an organization will probably be considered sensitive information.
    4. System-level metrics should be reported in an aggregated manner (as proposed by the PSWG) without disclosing sensitive information/data.
    5. These metrics should be assembled without collecting every detailed/sensitive data in a central location (e.g., Caliper reporting module)

The following architecture tries to tackle these problems with a fully decentralized design (even the network artifact initialization is decentralized). The key aspects of the architecture will be detailed in the Caliper Development Plan page.

Short-term (~June) roadmap

Most of the effort should be redirected towards the things discussed in the NPM section above. Publishing the packages is a priority. 

The documentation must also be updated to reflect the current design and usage (and an API specification if possible).