Hyperledger Project

Technical Steering Committee (TSC) Meeting

May 26, 2016 (7:00am - 8:30am PT)

via GoToMeeting

TSC Members

Resources:

• Github:  www.github.com/hyperledger

• Wiki:  https://github.com/hyperledger/hyperledger/wiki

• IRC:  #hyperledger on freenode.net (has Meetbot)

• Public lists:  lists.hyperledger.org

• Slack:  https://slack.hyperledger.org/ (self-generated invites)

• Information on the TSC Members can be found at https://www.hyperledger.org/about/tsc

• Meetings:  https://github.com/hyperledger/hyperledger/wiki/PublicMeetingCalendar

Agenda

• Action item review

• HIP:  IBM-DTCC Joint Proposal for Java Chaincode Support

• WG updates

Action Item Review

• TSC representation policy draft (Chris Ferris)

• Done via TSC list.

• Whitepaper review (Dave Voell)

• To be covered in WG updates.

• June (virtual) Hackathon (Todd Benzies)

• Last day to respond http://doodle.com/poll/tzmnqwe279sfzwa2

• What platform(s) do the Community want to leverage?

• Etherpad is used in some projects.

• Brian B:  part of value is speed and responsiveness on existing tools.  People are there and focused, not competing for attention.  Value is in quick responses leveraging real-time channel like Slack.  Make sure people are present and responding quickly.  Etherpad or Google docs are great.

• CF:  If it is code, using Screenhero would be a good alternative.

• Christopher A:  done a few vHackathons; main thing is periodic check-in times (every 8 hours).  Also, does need a good beginning and end.

• July Hackathon (west coast) (Todd Benzies)

• Last day to respond http://doodle.com/poll/qumqqpsprsi9xzia

• Exit criteria summary (Chris Ferris)

• Still pending.

TSC Representation Policy

• https://docs.google.com/document/d/11KCqr40-zjMB0KqQCnfJvFtem2_A_QkOznw5c9dseZI/edit

• VOTE:  Passed unanimously.

HIP:  IBM-DTCC Joint Proposal for Java Chaincode Support (Murali, Pardha, Sheehan, Muralidharan)

• Proposal here as presented by Murali Krishna (DTCC)

• Comments/questions

• RGB:  Do you envisage people would take core Fabric code for one set of use cases and deploy a version with Java chaincode, and for a different independent set of use cases (and network), may use Go or some other language.  Or do you envisage a network that runs both chaincodes which means anyone participating in that network would need to be able to validate both types of transactions?  Is this a choice at the network level, or an additional thing that networks would support?

• Murali -- For same network should be allowed to specify smart contract in Go and Java.

• Sheehan -- Could turn one of both on.  Network decision.

• Tamas: envision further API for Java edit functionality compared to what is in Go chaincode?  Or literal translation of interfaces in existence.

• Murali -- Will support same interfaces from Java side.

• Tamas -- basically same chaincode APIs as in G.

• What has been accomplished or what is working?

• Sheehan -- IBM wrote an initial experiment of Java chaincode working and running...however, now it is out of sync with current fabric.  Would contribute that code and a branch (may not be fully working state as it catches up with current Fabric APIs, and then add new APIs from last month or two)

• Fabric allows mixed types?

• In same network should be able to have Go and Java smart contracts running at same time.

• What about verifying code… what version of Java?

• Mic:  the whole concept of versioning is a general challenge.  Would be nice to have some insights come out of your project to understand general problem and how to architect for it.  Interesting problem to look at and this is a nice area to do so.  Version of Java you have will have to evolve over time.  Not just single shot versioning, it is a progression of versions over time.

• Richard R3:  Good thing to explore, have been working on this with Corda.  Versioning, sandboxing, whitelist of deterministic classes.

• Mic:  on resources -- expect this to last 1-1.5 months, this is with single specific version, correct?  This seems optimistic, unless it is very constrained.

• Murali -- estimates based on joint feedback between DTCC/IBM.  This would be a first version equivalent to Go that is running on same network.  Once stable, would expand on it.

• CF:  Agreement to support this sub-project proposal to be incorporated into HLP Fabric?

• VOTE:  Passed unanimously.

WG Updates

• Requirements WG (Oleg Abdrashitov)

• Working on financial use cases… swaps, interest rate, etc.

• Different trading scenarios (OTC, exchanges, etc.)

• Need help from different members to validate use cases

• DIscussion on how much of implementation of workflow detail to include in the use cases (only user stories?  ...or propose how they can get implemented to solve something?)

• Equity contracts and fixed income

• Trying to complete financial use cases as first milestone

• Architecture WG (Ram Jagadeesan)

• Met yesterday -- good progress on understanding consensus module and smart contract business logic layer and how the two interact

• Previously decided to use slack -- yesterday, decided to setup a mailing list for deeper discussions w/ appropriate contract

• Self-subscribe at https://lists.hyperledger.org/mailman/listinfo/hyperledger-arch-wg

• Would like to have use cases and requirements baked before more detailed discussions on architecture -- but, while we wait, decided to pick up more obvious topics with understanding of requirements.  Picked functionality and interaction consensus module and smart contract business logic layer.

• 2 approaches -- one is more closely aligned with bitcoin style mechanisms and STL… other is fabric folks developing and documentation for requirements of confidential transactions (meet confidentiality requirements).  Trying to determine, can we align on one approach?

• Whitepaper WG (Dave Voell)

• RGB: feedback sent via email to technical-discuss.

• Lots of unsupported assertions throughout paper, primarily about value of blockchain technology -- need these to be justified.  Stuff is not yet deployed, we don’t know for sure.

• A lot of assumed knowledge in paper -- terms used without being introduced or defined.  We know that these terms are evolving in their interpretation.  Benefit from defining terms or providing a glossary so that there isn’t misinterpretation.

• Vision -- reader is left at end wondering what vision is.  Closest we got was vision is that lots of different blockchains need to be built from the same underlying architecture.  Not particularly inspiring and it may or may not be true.  Could make argument that modularity is desirable based on things like Linux…. But, this is not entirely clear or justified.

• Quality of prose needs to be raised -- this may come out in editing at end.  Just needs some general fixing.

• Section labeled requirements… but it doesn’t really have any requirements.  Should say “must” “should” “may”.... as opposed to a sales pitch.

• Paper does not yet adequately establish vision of HLP as a whole…. i.e. architecture onwards is mainly focused on OBC… didn’t focus on the high-level project with projects in incubation under that… also doesn’t seem to be any focus on STL.

• DV:  Great feedback!  We’ll take all these points in consideration.  Requirements, for example, this is not meant to be requirements doc.  Just wanted to provide some examples that would be illustrative of features we’d like to do. Did receive other feedback from form that there were more examples of use cases, requirements, and want to have those ideas transferred over the Requirements WG.  Remainder of comments are really excellent.

• 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

• DV:  Group met yesterday.  Confirmed that strategy is to publish a new draft every other week.  Process is to review feedback and discuss, assign people to do updates (or live on call), following week would incorporate input and push out a new draft version.

• Brian -- consider posting incorporated feedback to announcement list…. But, try to have as few channels for feedback as possible.  This is a foundational document -- people will be rallying around this.  Most common watering hole is the technical-discuss list.  Once you are ready for broader input… try to focus comments on technical-discuss and on google doc (add comments) so people can build on each others comments.

• Identity WG (Christopher Allen)

• Did not meet this week (only bi-weekly).

• Next Wednesday should have IBM membership services team present a deeper dive into architecture and a bit about cryptography and confidentiality support that membership services feature of fabric demonstrates.  Have not yet received confirmation, but hopeful.

• CI WG (Chris Ferris)

• Jenkins up and running -- getting it to spin out slaves onto alternate platforms

• Need to do some work to integrate with slack/email

• Gerrit is stood up… but only actively using for CI pipeline right now… and spinning up Jenkins jobs

• Eventually want to transition other things as well

• ACTION:  Todd to schedule an overview training session “immersion into using Gerrit” (or maybe during TSC call).

• Please jump on CI pipeline channel on Slack.

• Would love to see process of STL transitioned over.  Tamas -- for Fabric API buildout, if there is something we can do to help transfer over build processes to LF Jenkins, that would be great.

• Dan Middleton:  put a bunch of detail about our jenkins process into a thread with other folks on the CI process.

Action Items

• Finalize June (virtual) Hackathon (Todd)

• Finalize July Hackathon (west coast) (Todd)

• Schedule an overview training session “Immersion into using Gerrit” (or maybe during TSC call) (Todd)

• Exit Criteria Summary (Chris Ferris)