2016 05 19 TSC Minutes

Hyperledger Project

Technical Steering Committee (TSC) Meeting

May 19, 2016 (7:00am - 8:30am PT) via GoToMeeting

TSC Members

Emmanuel Viale

Accenture

Yes

Stan Liberman

CME Group

Yes

Tamas Blummer

DAH

Yes

Stefan Teis

Deutsche Boerse Group

Yes

Pardha Vishnumolakala

DTCC

Yes

Hart Montgomery

Fujitsu

Yes

Satoshi Oshima

Hitachi

Yes

Chris Ferris

IBM

Yes

Mic Bowman

Intel

Yes

David Voell

J.P. Morgan

Yes

Richard G. Brown

R3

Resources:

Welcoming Brian Behlendorf, Executive Director, Hyperledger Project

Agenda

  • Action item review
  • WG updates
  • Exit criteria discussion

Action Item Review

  • TSC representation policy draft (Chris Ferris)

    • Will complete by 5/26

  • Whitepaper draft by 5/18 then on 5/19 TSC agenda (Dave Voell)

    • Will discuss during WG updates

  • Bishop to work with Binh, Sheehan, and Greg to get HIP busywork Exerciser integrated into fabric

    • Pull request due to land today

  • Doodle poll for June (virtual) Hackathon (Todd Benzies)

  • Doodle poll for July Hackathon (west coast) (Todd Benzies)

  • Exit criteria doodle pool (Todd Benzies) – can start discussion during TSC call

WG Updates

  • Requirements WG (Oleg Abdrashitov)

  • Architecture WG (Ram Jagadeesan)

    • No meeting held this week; will update next week.

  • Whitepaper WG (Dave Voell)

    • Whitepaper Draft v0.1 (published May 19, 2016)
    • Please provide feedback to the Whitepaper working group through our Feedback Form
    • Request for everyone, especially TSC members, to read through and add edits prior to this draft going to the Governing Board

  • Identity WG (Christopher Allen)

    • Minutes from May 18th meeting

    • Need more work in requirements and use cases around lifecycles of identities, will be working on some docs to share with those WGs

    • Variety of discussions around possible technologies being deployed elsewhere with real relevance

    • Selective disclosure and different approaches was a hot topic for the group

    • May need different identity services and determine what APIs would be needed

    • Tomorrow is big UN conference on digiital identity http://www.weboftrust.info/

    • Jeremy S: we came up with list of potential use cases and will be reaching out to Oleg to see how it maps in.  As we getting a better sense of dimensions of layers of system – helps to have a common language to separate out some of these things.

      • Christopher A:  conflation in a variety of areas.  Different identity communities call “key holders” vs. “principals”… need to reconcile some terminology issues.  Fundamental difference between finance and supply chain workflows. Discussed with Eric Anderson of Bloomberg who will be sharing with Identity workshop some of the use cases that Bloomberg wants to share.

  • CI WG (Chris Ferris)

    • Gerrit has been stood up; need some more config and training and then a planned migration from Github to Gerrit
    • Jenkins is up; but still needs a small amount of confg, should be done early next week
    • If people want to help with CI, plenty of opportunity to volunteer

Exit Criteria Discussion [thank you to Alice Ma and Bill for the notes below!]

  • https://hyperledgerproject.slack.com/archives/exit-criteria/p1460655008000006

  • Project must have cultivated a diverse set of contributing members

    • One of the most important factors
    • Ensure that membership is > 1
    • Diversity includes diversity of usage, e.g.: companies that use the technology and servicing the technology. We shouldn’t just measure the contributions, we need to take into account the types sizes of companies that can deploy solutions

  • Must demonstrate some threshold of test coverage.

    •     Some sections of the codebase are more important to cover than others (crypto, security)

    •     We need a yardstick to measure this beyond “we always need more (tests)”

    •     What’s a reasonable % of test coverage?

      • Hard to say because it’s different at different levels:

        • security stuff: upper 90’s
        • business logic: 5 lines of test per 10 000lines of code (?)
      • Further discussion required

  • Scalability

    • Which dimensions?
    • Is this idea related to scale of use in real world?

  •  Appropriateness of requirements met by MVP

    • Concern: Given that running code wins, is there a risk in putting too many requirements?

      • Programming practices of security world are difficult to do in an agile way BUT there’s still value to the agile paradigm. When it comes to business logic, we could do better than Ethereum smart contracts (15 serious errors per 1000)
      • HOWEVER: Contracts/chain code (except for samples) are not quite what we’re doing
      • STILL, some things need to be strong, so we do need a high bar (e.g. identity/IBM’s new crypto system using keys in a new form)

  • Project must have real world use

    • Use by a small supply chain/something that is “real “in some fashion is a criteria for being mature

    • Real problems: does the code fit into the regulatory requirement?

      • Test ledgers perpetually running?
      • Less rigorous definition

    • Refinement period is necessary for all OS projects:

      • Ledgers cannot be treated like a service package. Needs to be cross-autonomizationservice?
      • Can incubate DNS bind and understand how it works as a package
      • Other projects had continually running test pads to verify cross-organization consistency: not a full-blown production systems

    • May need to know whether or not it’s “transaction-ready”

      • Has it been audited/blessed by security/crypto community
      • Has it been used by a regulator
      • Ensure that there’s enough disclaimers so that there’s no misunderstandings/legal trouble

  • What does “maturity” and “incubation” mean from a community perspective?

    • Should discuss this further outside of the call.

    • Definition of “mature”: is there a separate interpretation of maturity within the Hyperledger organization (vs the interpretation within other OS communities)

    • Just because something is out of incubation doesn’t mean it’s not incubating anymore. It means that it’s at its beginning, and that more tests and functionality can be added

    • Should there be a level in between “mature” and “incubating”?  Or should this be handled by levels of release? (1.0, 2.0, 3.0, etc)

    • Does “mature” really mean “mature enough to rely on it in some fashion”?

    • Proposed definition of “incubation” and “maturity” – “maturity” means that we have agreed that this thing is something we’re going to continue to support and develop

      • “Anchor points”: both terms reference a project’s participation in the final release of the code base, not in terms of maturity or use of the code IRL

    • Input from someone (name?):

      • The “incubation” label is like “beta”
      • Considerations: Has this project/module proven capable of releases? People maintaining, debugging as necessary, security patches
      • Look to Apache incubator for how other OSF’s do this (they don’t require proof of production use)

  • Sufficient documentation

    • Should be enough for anyone to test/deploy any of the modules. Documentation should illustrate test cases, demonstrate various test cases

  • Input from Christopher Allen:

    • We haven’t had discussion on:

      • Multiple identity system
      • Pluggable architecture
      • E.g.: Hyperledger would only have 1 “master” codebase, future iterations will have to reconcile with existing ones
    • Does one version of a module need to be compatible with existing mature versions for it to be considered “mature”?

  • Other Concerns

    • Slack channel: archived messages can’t be seen
    • Modes of communication/collaboration: slack, email, conference calls
    • If we want to use slack, then maybe we should consider getting an enterprise version
    • Todd and Brian to have a conversation about what we can do to fix

Action Items

Recording