Hyperledger Project

Technical Steering Committee (TSC) Meeting

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

F2F at Linux Foundation Collaboration Summit & 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:  hyperledgerproject.slack.com/signup (email tbenzies@... for access)

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

Agenda

• Action Item Review

• Intel - proposed contribution (Patrick Holmes)

• Discuss and Finalize

• Project Lifecycle template (Arnaud Le Hors)

• Project Proposal template (Vipin Bharathan)

• Updates

• Requirements WG (Patrick Holmes)

• Architecture WG (Ram Jagadeesan)

• Whitepaper WG (Dave Voell)

• Identity Subgroup (Chris Allen)

• Tooling F2F

• Next Technical F2F

Action Item Review

• Chris sent request to call for CI volunteers and created slack channel

• Chris A and Mic are having discussions to complete the readme for the merged code proposal that was approved

Intel - proposed contribution (Patrick Holmes)

• Open sourcing project “distributed ledger”

• Highly modular and extensible

• Gossip topology:  Random walk and Barabasi-Albert

• Consensus: PoET and Quorum voting

• Solution domains:  Transaction Families

• Transaction Families

• Provide data model, transaction semantics and validation

• Proof of Elapsed Time (PoET) Consensus

• A power-efficient replacement for proof-of-work

• Each node delays a random duration before claiming leadership

• Trusted Execution Environment provides attestation

• github.com/intelledger

• Internal name “Sawtooth”

• Sawtooth core is the fundamental component

• Sawtooth validator is the validator process (startup, configuration settings, etc.)

• Sawtooth marketplace is more complex marketplace

• Sawtooth dev tools is the vagrant environment

• Documentation on github.io

• Developer’s guide with API documentation

• Marketplace Developer’s guide to use marketplace code

• http://intelledger.github.io/

• https://inteldl.slack.com/

• Q:  Going to make a formal proposal?

• Patrick -- hoping people go study, do tutorial, give us feedback.  Then we come back in a week with further proposal of what we’d like to do.

• Q:  Is it possible to use SGX with this code?

• SGX is on some processors, but not all.  We’ve created a PoET simulator.  Simulates it running inside SGX, but not actually running inside SGX.  So, it is not secure implementation -- only simulating trusted execution environment.  Working on plans now for final implementation using a trusted environment.

• DM:  Algorithm there is algorithm that would run inside of trusted environment.  Important aspects is brings consensus back to 1 CPU 1 vote.

• There is a slack channel in documentation -- would love to get feedback.

• Q:  Is there a whitepaper or something on this?

• Patrick:   No.  But, introduction in documentation is what is available.

• Q:  How does validation work?  Is there an execution engine or scripting engine?

• PH:  Blocks are made up of transaction identifiers (hashes of transactions)… transactions are distributed through gossip network.

• Q:  Transaction family is part of distributed ledger?

• It is running on each node.  The validators is a composition of business logic which is abstracted from consensus mechanism, the selections of the consensus and peer protocols.

• Q:  Business use cases?  Have you implement like IoT for example?  Or other business cases?

• Mic:  a couple -- used endpoint registry (IoT)... also participated in R3 projects, financial services uses cases.  Have tested consensus mechanism with up to 1000 participating validators.  2,000 was highest it was pushed (on VMs).

• Q:  What language support for smart contract development?

• PH:  validator and code is Python.

• Q:  Transaction families support Turing complete language?  Or is it more deterministic?

• DM:  Author transaction family that has whatever orthogonality you want.  Could be fully Turing complete.  Attach an Ethereum-style execution model as a transaction family.  Example transaction families written have restricted verbiage to them right now.

• Q:  Privacy achieved in executing through SGX environment?

• DM:  Anticipate doing some unique things in SGX enclaves to support privacy in transaction models.

• DV:  So wouldn’t be able to implement with current code base?

• DM:  There isn’t a private facility within this code.  Transactions are fairly open.  But, nothing restricts you from layering privacy model into it.

• Mic:  in this release, does not provide some of the fundamental capabilities of doing peer to peer private transactions at this point.

• Q:  1 vote / 1 CPU -- how is permission identified?

• Mic:  All of validators register themselves.  That can be used as point of restriction for identity access.  SGX signing allows us to identify the fact two certificates originated from the same location.

Discuss and Finalize

• Project Lifecycle template (Arnaud Le Hors)

• Looked at draft a few weeks ago, have factored in edits and comments.

• Clarified what incubation entails -- incubation should be fairly easy to get into… want people to bring ideas to explore.  We don’t want to preclude things at this level.

• Question about different stages and how to progress -- is it linear?  Text has been clarified.

• Just because things are easy to get into incubation, does not mean there is a guarantee that you will progress beyond incubation or that it will be easy.

• Need to define criteria to get to incubation and the to go to mature stage.  Chris Allen is working on this.

• Can iterate and make changes as we move forward.

• Q:  Are there particular reviews for going state to state?

• Idea that within each project people are labeled as leaders.  They decide when they want to go to mature, they have own internal decision making process.  From there, they would need to bring it to the TSC to decide if it goes to maturation.

• VOTE:  This Project LIfecycle as a starting point.  We can amend over time.

• 7 of 8 present in favor (Richard abstained).  Approved.

• ACTION:  Chris to move it on wiki.

• Project Proposal template (Vipin Bharathan)

• Nothing has come up except for Chris’ comment that something should say “sponsor” instead of “author”

• VOTE:  8 of 8 present - unanimous.  Approved.

• ACTION:  Chris to move this on wiki.

Updates

• Requirements WG (Patrick Holmes)

• Meeting was announced on slack requirements channel
• Goal of group is to create system requirements… best way to do that is through use cases.
• Next meeting will take use case through entire process.  Primrose (Accenture) will do work with counterfeit drugs use case.
• Will continue to use wiki.
• Next meeting time not yet set -- but will be announced on TSC list.
• Semi-active slack channel -- please join us.

• Architecture WG (Ram Jagadeesan)

• n/a today -- updates coming next week

• Whitepaper WG (Dave Voell)

• First meeting post-F2F yesterday
• Noam, Murali, and Mic are new participants (now there are 9)
• Reviewed why the group is starting with OBC article?  Reiterated that it wasn’t rubber stamping OBC… it was really taking it from perspective that whitepaper was a good start in technical journalistic rigor.  Set a good baseline to start developing and modifying from, to reflect what is different.
• Talked about logistics of whitepaper.
• Every 2 weeks we’ll publish new version of the draft.  Want broad community feedback.  We’ll define process on how people can submit comments on wiki, as well as slack and tech mailing list.
• Google docs is good for now… but will probably migrate later.
• Should we have a whitepaper for each code stack?  Consensus was “no” -- this should not have any implementation details or specifics to any fabric under hyperledger banner.
• Actual edits -- accepted a bunch of earlier suggestions.
• Background section of paper -- OBC was originally designed to be permission only.  However, we will modify paper to envision scope of other use cases for public permissionless type mechanism.  But, this would be a later focus.  Have not yet phrased this how we want.  From there, it would be valuable to get Board review and agreement.
• ACTION:  Finalize wording to get in front of Board to review and opine on.
• ACTION:  Dave to update minutes on wiki

• Identity Subgroup (Chris Allen)

• Reached out on mailing list -- has a starting list of people that are interested in the discussion
• Determining how to meet, how to have discussion
• Identity is an important part of a permissioned system
• Identity at the blockchain level is very different than identity from business logic level and how to handle
• May feed into requirements working group
• ACTION:  Chris Allen to canvass everyone that expressed interest, determine if they prefer a list created or just using slack.

Tooling F2F

• Steve Westmoreland suggested everyone get together for .5 day or 1 day to run through tooling needs, driving integration, Gerrit, integrate with Slack and Travis, Jenkins, etc. or whatever for build orchestration.

• ACTION:  Todd to create Doodle poll -- sometime during next few weeks.

• Location:  possibly New York or East Coast?

Next Technical F2F

• Next Technical F2F.  Possibly 1st week of May during Consensus event?

• ACTION:  Todd to send Doodle poll -- 2 days would be good.  Will start soliciting space, as well.

Actions:

• Chris A and Mic to complete the readme for the merged code proposal that was approved

• Chris Ferris to move Project Lifecycle on wiki (no longer under proposals)

• Chris Ferris to move Project Proposal on wiki (no longer under proposals)

• Dave to finalize wording of whitepaper to get in from of Board to review and opine on.

• Dave to update minutes for whitepaper WG

• Chris Allen to canvass everyone that expressed interest in Identity subgroup, determine if they prefer a list created or just using slack.

• Todd to create Doodle poll for Tooling F2F

• Todd to create Doodle poll for Technical F2F

Hyperledger Project

Technical Steering Committee (TSC) Meeting

March 31, 2016 (7:00am -8:30am PT)

F2F at Linux Foundation Collaboration Summit & 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:  hyperledgerproject.slack.com/signup (email tbenzies@... for access)

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

Agenda

• Proposal for merged codebase

• Linux Foundation IT/Tools Discussion

Proposal for merged codebase

• Chris Ferris:  After close of last week’s Technical F2F, we agreed to bring forward proposal to the TSC this week

• https://docs.google.com/document/d/1XECRVN9hXGrjAjysrnuNSdggzAKYm6XESR6KmABwhkE/edit

• Proposing to formally incubate the merged codebase that emerged from last week’s F2F and formally evaluate through the incubation process where it builds and we can have a release.

• Project sponsored by Chris Ferris (IBM) and Tamas (DAH)

• PoC resulted from Hackathon

• Team proposed set of high level next steps articulated in proposal along with another set of tasks to get to point of mature implementation

• This was proposed as a incubation project

• A question had come up if other projects could come forward with proposals -- answer is yes.  If others have proposals, bring them to the TSC.

• Resources -- IBM and DAH are both committing FTEs to this.  Binh, Tamas, Robert, Sheehan would be initial maintainers.

• Questions / Comments

• Q:  Is this effort of only IBM/DAH, or community?

• Not just IBM/DAH… it is the Hyperledger Community.

• Q:  Can you establish a set of guidelines or documentation to help people that are new and want to get up to speed to help?

• Yes, this can be part of initial work.  Will add initial next steps to create this.

• Q:  Number of stages?  i.e. incubation and then?

• Previously discussed a project lifecycle proposal (not yet finalized).

• https://docs.google.com/document/d/1asqGu-6xlldY4uwmnkgJs3uhqUDa_wCdv9-cGUEEIOY/edit#

• Q:  Hackathon was great -- but, concern with word “incubation”... it feels premature to start down this path.  Proposals need to be vendor neutral.  This was a hackathon… let’s continue to experiment and turn into a proposal before it can be incubation.

• CF:  Incubation is the first step.

• ST:  There was a proposal… we worked on this during hackathon.  At this point, we move to incubation.

• MD:  We shouldn’t be gateing and creating barriers for getting incubation and ideas to start.  This is different than a standards effort.  Others are free to bring proposals as well.  This method is similar to every major open source project.

• HM:  May be a matter of semantics.  Need to make code easier to use.  Shouldn’t be wedded to a single architecture.  People seem to agree on what we need to do, but maybe arguing about terminology.

• MB:  This is not _the_ codebase.  This is _a_ codebase that will be evaluated at a future point.  Want to understand what this evaluation will entail and what efforts are setting this criteria?  Lastly, feels like proposal is code without an understanding exactly what it is being proposed.  Architecture is extremely high level… want to understand how these components will be deployed, made available, etc.  What is being proposed architecturally?  That said, in favor of making code work, in parallel.

• CF:  We need to aggressively work on evaluation criteria.  We can make that part of the proposal.  That said, we need to get code into the HLP project that everyone can start collaborating on.  If someone else wants to do a proposal that we incubate side-by-side, it is welcomed!

• SL:  What are we accepting?  Maybe we accept parts of architecture and break into separate projects?  Right now it seems we are accepting entire OBC architecture as a proposal

• CF:  This is a place to start from, not an end result.

• RGB:  Struggling to understand how to contribute to process.  It is becoming clear that he needs to understand what we think an end state could be.  I disagree that there will ever be one correct codebase… different architectures for different requirements.  If the intention is that we get to one codebase, then we need to agree on the problem we are trying to solve.  Or, if the vision is that there are several sister projects addressing needs, that is possible too.  When we talk about eval process, need to address this.

• CF:  May be a problem of semantics.  We are not selecting a code base.  Requirements, use cases, etc. will all shape what we build.  This is like starting with a lump of clay.  Just want to start a process of getting people to collaborate and working together.

• Murali:  In favor of merging code bases.  Maybe we come up with a target architecture and identify different components and note which components come from which proposals.

• CF:  Yes.  Other people may come forward with ideas of better member services (for example)... this is exactly what we want to do.  This is just a lump of clay to evolve.

• PD:  If you have another idea, put a proposal forward.  Competing ideas lead to innovation.

• CF:  OpenStack, for example.  Someone may want to refactor a component.  Get others to collaborate with them.

• EM:  Maybe noting that this is one project being moved into incubation, but it is not intended as the _only_ foundation.

• CF:  Correct.  But, people need to bring proposals.

• ST:  Help us and others understand the initial proposed code… need a 101 description which would help everyone put it on a broader development base.

• DV:  Sounds like a lot of violent agreement.  A lot is semantics.  Doesn’t see how moving this to incubation conflicts with any points above or what happens next or someone makes a different suggestion.

• TB:  There are advantages to this merge.  DAH comes from bitcoin angle, IBM comes from more general angle.  This is pragmatic merge.

• MB:  What does accepting proposal mean?  1) we give it a label that it is incubation status.  2)  give it a spot on the hyperledger github.  What else? What changes?

• CF:  Bring under HLP umbrella and it goes under the governance of the project.  It would be moved from the independent repository.  This would put it under governance to engage and accept work from others.

• MB:  In terms of process, it sounds like the real difference under HLP label, set of guidelines for code review, commitment, licensing, community, contributions, etc.

• CF:  Successful at hackathon with getting different companies to collaborate.  There can be other proposals.  But, important that we start engaging and collaborating as community.

• CA:  How about we accept the proposal into incubation, but make sure there, in this repo, there is further clarity that a) we are hoping for further proposals and incubation projects, that b) this isn't not a base at this time, and c) that as the first in there are incomplete understanding of goal end state and are waiving requirements of the proposal process of having a well defined scope as we don't know scope yet.

• ALH:  Suffering by lack of common understanding of what it means to be in incubation.  Project Lifecycle doc could have solved this.  This document needs more work.  Need to finalize work of lifecycle doc and publish on web.

• ACTION:  Christopher Allen and Mic Bowman suggest verbiage for readme for how we characterize this

• MD:  Need to think in long term.  Putting up gates in front end for proposals may create challenges.  Focus more on getting out of incubation, as opposed to getting into incubation.

• RGB:  Good point.  This makes the readme clarification important.

• Primrose:  There are multiple proposals.  Why are just IBM, DAH, Blockstream as an incubator?  How does Ripple or others become incubating?

• MD:  Those were statements of proposed contribution.  Please put forward a proposal for incubation.

• CF:  It sounds like people are ok, but stuck on semantics.

• RJ:  Would be good to have an Architecture WG

• Ram will lead the WG, Hart will help.

• Ram to circulate note on mailing list with more details and call for volunteers

• VOTE -- Proposal with modifications from Stefan (accessible for new people), also added from Mic (TSC will work in parallel on incubation, graduation, etc. criteria)... Mic/Chris A. to collaborate on clear section in readme that describes exactly what this is).

• Vote passes unanimously with the 9 TSC members present.

Linux Foundation IT/Tools Discussion

• Steve Westmoreland, Linux Foundation CIO

• Gerrit is helpful in controlling to make sure there is a review process and any comments/questions can go back to the contributor, if necessary.  Code management and review.

• Would also like to have a working session on infrastructure.

• Linux Foundation will assign a release engineer.  Also, anyone that wants to work on CI, please let us know.

• ACTION:  Chris Ferris to send a request to the list.

Evaluation Criteria for Incubation to Mature

• MB:  Expect to come out of the requirements workgroup.  Will talk to Patrick Holmes on this.

• CA:  Had put out a call for an Identity Subgroup.

• ACTION:  LF to add an Identity mailing lists.

• MD:  Note that LF IT team is working on slack/mailing list integration

Hyperledger Project

Technical Steering Committee (TSC) Meeting

March 25, 2016 (8:00am - 9:00am PT)

F2F in Brooklyn & via WebEx

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:  hyperledgerproject.slack.com/signup (email tbenzies@... for access)

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

Readouts from Technical F2F

• Recording available of readouts from Technical F2F, which took place prior to TSC Meeting

Getting to a Code Base

• A team at the hackathon developed a PoC for a merged code base

• This team demonstrated their PoC work

• The team noted that they pivoted slightly from the original plans once the pulled code together and merged

• The net result is that they found a more elegant solution in the process

Open Discussion

• Comment about identity issues.  Talking about federation and very different requirements... are we supporting multi-sig, what are wallet requirements, regulatory issues (hardware, tokens, etc.), privacy issues (i.e. Europe vs. US),  This will affect all of our Federations.  If we create a lot of different chaincodes with authority being granted by those chaincodes, how does that work?  Suggested to TSC to determine where identity fits into the project.

• The TSC discussed general topics of the relationship of HLP protocols, code and architecture. There was interest in eventually creating a way to pass cryptographic proofs with a protocol for exchanging.

Next Steps

• Chris Ferris:  recommend to merge the codebases to then start building and testing

• Most TSC members favored moving forward with this proposal

• A request was made to see the proposal documented with a few more specifics before casting a formal vote

• https://docs.google.com/presentation/d/185C9JUICwJQFnf6vH2nOEBNATAVG1XBVY-e-EV6oRSQ/edit

• ACTION:  Chris Ferris will formalize proposal and send out for review prior to a vote

Future F2F

• Plan to have another F2F in roughly 1 month's time.

• Preference for east coast -- though may want to move GEO around

Hyperledger Project

Technical Steering Committee (TSC) Meeting

March 17, 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:  hyperledgerproject.slack.com/signup (email tbenzies@... for access)

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

Agenda

• White Paper Update (Dave Voell)

• Code of Conduct (Arnaud Le Hors)

• Technical F2F (3/22 - 3/25), Brooklyn, NY (Chris Ferris)

• Linux Foundation IT Discussion (Steve Westmoreland)

• Requirements WG Update (Patrick Holmes)

White Paper Update

• https://github.com/hyperledger/hyperledger/pull/8

• Dave Voell is the editor

• Chris Ferris laid out a potential outline for this white paper

• For next week F2F, Dave will lead a breakout on this (looking for people to participate)

• Please pre-read the IBM whitepaper, other versions are welcome, as well

• OBC whitepaper is a good template and has done a good job of articulating plans

• Scalability, confidentiality, privacy

• Enterprise use cases -- many operating in regulated industries (big requirements there)

• Q:  How do you want feedback on this?  Google docs comment?

• Yes, Google docs works

Code of Conduct

• Survey results are visible here: https://www.surveymonkey.com/results/SM-BHZY7NXW/

• Seems to be preference for W3C (not a landslide, but preference)

• Majority prefer W3C

• Also, more people object to CF version (only 1 disagrees with W3C)

• The goal is to have a Code of Conduct to start moving on.  Suggest TSC to adopt W3C draft as a starting point.

• Add a point about staying focused/on topic (from CF version)

• Add a point about step down considerately -- if you leave the project, don’t just drop the ball, put a transition plan in place (from CF version)

• TSC 6 in favor (Stan, Hart, Chris, Mic, Dave, Stefan), 1 abstain (Richard) -- W3C version with 2 additions above is approved as the Code of Conduct

• Arnaud to make edits and work with Todd to get posted

Technical F2F (3/22 - 3/25), Brooklyn, NY

• Reminder to register https://www.regonline.com/hyperledgertechf2f

• 61 registered (capacity: 100)

• Now 77 (as of 3/18)

• Proposed F2F Agenda

• https://drive.google.com/a/nodejs.org/file/d/0B42vMkapQi1MT2QxRDhKR2x4MzA/view?pli=1

• Q:  In terms of dev environment -- is Windows ok?

• Windows, Linux, Mac should all work.

• Q:  Working inside VM itself?

• Yes.

• Tamas:  additional feedback on goals for F2F can be found at:

• https://github.com/DigitalAssetCom/hlp-candidate/blob/master/HACKATLON.md

• Q:  any merging of code?

• CF:  the intention is to drive this experiment and see if we are confident of this being something we are comfortable going forward with

Linux Foundation IT Discussion

• General discussion led by Steve Westmoreland, CIO, The Linux Foundation

• LF IT provides a host of services to projects

• Infra, security, web services, wiki, etc.

• Github and Gerrit

• Support both Travis CI and Jenkins CI functionality

• Bug mgmt / bug tracking -- Jira

• There will likely be a dedicated release engineer

• Ability to have geo-diversity to support timezones/locations

• SW:  Gerrit is a tool that has historically been integrated in with Github.  Allows to control the process around code review.  Code gets checked in, pre-configured requirements that it will go through review, enforces fact that it requires two committers, etc. other requirements that the code gets reviewed, scored, passed or failed.  Part of ecosystem that comes w/ Git.

• CF:  mitigates potential for random code merge or accidents or mistakes

• DV:  yes, should start off with something like this.  If there are complaints or issues… we can evaluate other options.  But, we need something in place that shows evidence of code reviews.

• Stan:  think Gerrit is a great thing to have with this many potential contributors.  However, there may be a risk with setting up this early, could be a barrier to contributions.  Maybe after Hackathon, once we have a more final form for project.  But, it could be problematic before we have a single line of code (as it could be viewed as a barrier).

• Sheehan:  agrees.  I like code review, but it can also slow things down if reviewers are not very active.

• Need for further IT discussion

Requirements WG Update

• https://github.com/hyperledger/hyperledger/wiki/Requirements-WG-Status

• 15 people working on this

• Developing a template for use cases (not finalized)

• Session at F2F next week