Date   

[Hyperledger Project TSC] TWG China Monthly Report for August 2017

Baohua Yang
 

Dear TSC

On behalf of the Technical Working Group China, we have drafted the monthly report for August 2017. 

Please feel free to find the report at wiki.hyperledger.org/groups/twgc/report/2017-08.

Welcome for any advice and comment!


Thanks!

--
Best wishes!

Baohua Yang


[Hyperledger Project TSC] Minutes / August 24th, 2017

Todd Benzies <tbenzies@...>
 

Hyperledger Project

Technical Steering Committee (TSC) Meeting

August 24, 2017 (7:00am - 8:00am PT)

via GoToMeeting


TSC Members

Arnaud Le Hors

Yes

Baohua Yang


Binh Nguyen

Yes

Christopher Ferris


Dan Middleton


Greg Haskins

Yes

Hart Montgomery

Yes

Jonathan Levi

Yes

Kelly Olson


Mic Bowman


Nathan George

Yes


*quorum not reached*


Resources:


Hackfest Planning


TSC Annual Election

  • Please join me in welcoming the following new or returning members to the TSC (in alphabetical order):

  • Arnaud Le Hors

  • Baohua Yang

  • Binh Nguyen

  • Christopher Ferris

  • Dan Middleton

  • Greg Haskins

  • Hart Montgomery

  • Jonathan Levi

  • Kelly Olson

  • Mic Bowman

  • Nathan George

  • TSC Chair nomination/election to commence


PSWG Charter (Mark Wagner)

  • Revised draft

  • WG wants more clarification on rough consensus to be consistent with what other WGs are doing

  • Mark to bring this back to PSWG and then come back to TSC for a final approval and vote


[HIP] Hyperledger Caliper - a benchmark framework for performance testing (Haojun Zhou)

  • Proposal

  • Haojun Zhou provided an overview of the proposal (recording 9:45 - 46:26)

  • ACTION:  follow-up discussion via email thread


--
Todd Benzies
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)


[Hyperledger Project TSC] Election Results

Todd Benzies <tbenzies@...>
 

Hyperledger Project Technical Community,

The TSC election has now concluded.  Please join me in welcoming the following new or returning members to the TSC (in alphabetical order):
  • Arnaud Le Hors
  • Baohua Yang
  • Binh Nguyen
  • Christopher Ferris
  • Dan Middleton
  • Greg Haskins
  • Hart Montgomery
  • Jonathan Levi
  • Kelly Olson
  • Mic Bowman
  • Nathan George
We will kick off the TSC Chair nomination and election process later today.

Regards,

Todd

-- 
Todd Benzies
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)


[Hyperledger Project TSC] Agenda for August 24th, 2017

Todd Benzies <tbenzies@...>
 

  • Hackfest Planning
  • TSC Annual Election
    • Results from election will be announced
    • TSC Chair nomination/election to commence [timeline]
  • PSWG Charter (Mark Wagner)
  • [HIP] Hyperledger Caliper - a benchmark framework for performance testing [proposal | thread] (Haojun Zhou)

--
Todd Benzies
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)


Re: [Hyperledger Project TSC] Project Proposal: Caliper - a benchmark framework for performance testing

Todd Benzies <tbenzies@...>
 

Thanks!  We've added this to the agenda for Thursday.

In the meantime, please continue discussion/questions via email.

On Tue, Aug 22, 2017 at 1:50 AM, Zhouhaojun <zhouhaojun@...> wrote:

Dear all,

 

We would like to submit a HIP we called it Caliper, which is a blockchain benchmark framework designed to test performance of multiple blockchain solutions with a set of predefined use cases.

 

The main purposes of this project are:

1.       To provide a common performance testing framework integrated with multiple blockchain solutions, like Fabric, Sawtooth, etc. To make it easy to write test cases for different blockchain systems.

2.       To standardize the implementation of performance measuring  to make it possible to compare the performance of different blockchain solutions in the same way.

3.       To provide some benchmark cases for typical blockchain scenarios.

 

The detailed proposal is at

https://docs.google.com/document/d/1cwScsNgYUj72vP2fqZ6vihYiuQcy45Ml2C_yLRI7EoQ/edit?ts=59955891#

 

The existing code is at

https://github.com/Huawei-OSG/caliper

 

We look forward to hearing your feedback.

 

And Todd, we would like to present the proposal at this week’s TSC meeting. Is there any time for this topic?

 

Best Regards,

 

Haojun Zhou

Huawei Nanjing R&D Center
101 Software Avenue,Yuhuatai District, Nanjing 210012
Jiangsu, P.R.C.
Tel: +86-25-56627049

Fax: +86-25-56629035
http://www.huawei.com

 




--
Todd Benzies
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)


Re: [Hyperledger Project TSC] Project Proposal: Caliper - a benchmark framework for performance testing

Benjamin Bollen <ben@...>
 

This project proposal has my support;  as does working to integrate a connection module to Burrow for it.  Great work and thanks

Ben

On Tue, Aug 22, 2017 at 10:50 AM, Zhouhaojun via hyperledger-tsc <hyperledger-tsc@...> wrote:

Dear all,

 

We would like to submit a HIP we called it Caliper, which is a blockchain benchmark framework designed to test performance of multiple blockchain solutions with a set of predefined use cases.

 

The main purposes of this project are:

1.       To provide a common performance testing framework integrated with multiple blockchain solutions, like Fabric, Sawtooth, etc. To make it easy to write test cases for different blockchain systems.

2.       To standardize the implementation of performance measuring  to make it possible to compare the performance of different blockchain solutions in the same way.

3.       To provide some benchmark cases for typical blockchain scenarios.

 

The detailed proposal is at

https://docs.google.com/document/d/1cwScsNgYUj72vP2fqZ6vihYiuQcy45Ml2C_yLRI7EoQ/edit?ts=59955891#

 

The existing code is at

https://github.com/Huawei-OSG/caliper

 

We look forward to hearing your feedback.

 

And Todd, we would like to present the proposal at this week’s TSC meeting. Is there any time for this topic?

 

Best Regards,

 

Haojun Zhou

Huawei Nanjing R&D Center
101 Software Avenue,Yuhuatai District, Nanjing 210012
Jiangsu, P.R.C.
Tel: +86-25-56627049

Fax: +86-25-56629035
http://www.huawei.com

 


_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



[Hyperledger Project TSC] Project Proposal: Caliper - a benchmark framework for performance testing

Haojun Zhou
 

Dear all,

 

We would like to submit a HIP we called it Caliper, which is a blockchain benchmark framework designed to test performance of multiple blockchain solutions with a set of predefined use cases.

 

The main purposes of this project are:

1.       To provide a common performance testing framework integrated with multiple blockchain solutions, like Fabric, Sawtooth, etc. To make it easy to write test cases for different blockchain systems.

2.       To standardize the implementation of performance measuring  to make it possible to compare the performance of different blockchain solutions in the same way.

3.       To provide some benchmark cases for typical blockchain scenarios.

 

The detailed proposal is at

https://docs.google.com/document/d/1cwScsNgYUj72vP2fqZ6vihYiuQcy45Ml2C_yLRI7EoQ/edit?ts=59955891#

 

The existing code is at

https://github.com/Huawei-OSG/caliper

 

We look forward to hearing your feedback.

 

And Todd, we would like to present the proposal at this week’s TSC meeting. Is there any time for this topic?

 

Best Regards,

 

Haojun Zhou

Huawei Nanjing R&D Center
101 Software Avenue,Yuhuatai District, Nanjing 210012
Jiangsu, P.R.C.
Tel: +86-25-56627049

Fax: +86-25-56629035
http://www.huawei.com

 


Re: [Hyperledger Project TSC] React and the Facebook BSD + patents license

Brian Behlendorf
 

Hi Simon, thanks for bringing this up.  Licenses like this are exactly why we carefully parse the licenses of dependencies shipped as a part of our products, at least by a 1.0 release but ideally this kind of awareness is happening on projects sooner.  I wish the various "BSD + Patents" licenses would just die in a fire and people would just use Apache instead, especially when they intend no broader rights than Apache grants anyways.  The Facebook version of this for React is particularly odious.  And as you note, this is more nuanced as the generator would not ship React, but create an object with a dependency upon it.  So a decision is likely needed.

I'd like to suggest that the TSC hand this off to the Legal Committee - a group of legal counsels from our members that have met informally (such as to review the results of the Fabric 1.0 license scan) and will be chartered at tomorrow's Governing Board meeting to meet on a more regular basis, to consider questions like this.  I'd suspect we could address this relatively quickly, since there is a good template in Apache's "resolved legal issues" page at https://www.apache.org/legal/resolved.html#optional :
Can Apache projects rely on components under prohibited licenses?

Apache projects cannot distribute any such components within their releases. However, if the component is only needed for optional features, a project can provide the user with instructions on how to obtain and install the non-included work. Optional means that the component is not required for standard use of the product or for the product to achieve a desirable level of quality. The question to ask yourself in this situation is:

"Will the majority of users want to use my product without adding the optional components?"
So as a dependecy driven by an optional feature, and one not shipped with the product itself, this seems like it would be safe.  Meanwhile I can bring it up to the legal committee as its first order of business.

Brian
 
On 08/20/2017 08:43 AM, Simon Stone1 via hyperledger-tsc wrote:
Hi,

Most people are probably aware of the recent Apache Foundation announcement to mark the Facebook BSD + patents license as "Category X". This affected the use of RocksDB, which Facebook has relicensed, and also React, which Facebook have now declared they will not relicense. The TL;DR of "Category X" seems to be that all Apache Foundation projects cannot include or depend upon code using that license.

Hyperledger Composer currently has an Angular application generator for generating skeleton web applications. I regularly see requests for a React version of that generator, and I'm responding to those requests by trying to encourage the community to get involved and contribute.

This part of our code is also vague in terms of "what is a dependency" - in this case, Hyperledger Composer and the React application generator itself might *not* explicitly depend on React, but it would generate an application that does have a dependency on React (and the user would have to install React). However, that might change if our builds install React as part of an automated test for the React generator.

Before anybody makes any real progress on contributing such a generator, I'd like to get some clarification around whether or not we'd actually be able to accept the contributions. What is Hyperledger's position on the Facebook BSD + patents license? Are dependencies to code or modules that are under this license acceptable within Hyperledger repositories?

Many thanks,
 
Simon Stone
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


[Hyperledger Project TSC] React and the Facebook BSD + patents license

Simon Stone1 <SSTONE1@...>
 

Hi,

Most people are probably aware of the recent Apache Foundation announcement to mark the Facebook BSD + patents license as "Category X". This affected the use of RocksDB, which Facebook has relicensed, and also React, which Facebook have now declared they will not relicense. The TL;DR of "Category X" seems to be that all Apache Foundation projects cannot include or depend upon code using that license.

Hyperledger Composer currently has an Angular application generator for generating skeleton web applications. I regularly see requests for a React version of that generator, and I'm responding to those requests by trying to encourage the community to get involved and contribute.

This part of our code is also vague in terms of "what is a dependency" - in this case, Hyperledger Composer and the React application generator itself might *not* explicitly depend on React, but it would generate an application that does have a dependency on React (and the user would have to install React). However, that might change if our builds install React as part of an automated test for the React generator.

Before anybody makes any real progress on contributing such a generator, I'd like to get some clarification around whether or not we'd actually be able to accept the contributions. What is Hyperledger's position on the Facebook BSD + patents license? Are dependencies to code or modules that are under this license acceptable within Hyperledger repositories?

Many thanks,

Simon Stone
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Re: [Hyperledger Project TSC] Hyperledger CI outage

Ry Jones
 

This has been resolved.
Ry

On Fri, Aug 18, 2017 at 9:57 PM, Ry Jones <rjones@...> wrote:
We are having an unplanned outage.
Status updates here:
Ry


[Hyperledger Project TSC] Hyperledger CI outage

Ry Jones
 

We are having an unplanned outage.
Status updates here:
Ry


[Hyperledger Project TSC] Minutes / August 17th, 2017

Todd Benzies <tbenzies@...>
 

Hyperledger Project

Technical Steering Committee (TSC) Meeting

August 17, 2017 (7:00am - 8:00am PT)

via GoToMeeting


TSC Members

Arnaud Le Hors

Yes

Binh Nguyen

Yes

Christopher Ferris

Yes

Dan Middleton


Greg Haskins

Yes

Hart Montgomery

Yes

Mic Bowman

Yes

Murali Krishna Katipalli

Yes

Richard Brown

Yes

Sheehan Anderson

Yes

Tamas Blummer



Resources:


Hackfest Planning

  • US:  9/21 & 9/22 in Chicago register now | draft agenda

  • Europe:  tracking on 10/28 & 10/29 in Berlin (meetup on Thursday prior to Hackfest)


TSC Annual Election

  • Voting begins on Thursday (8/17) at 8:00am PT -- details will be sent directly to all eligible voters.


Repo for Educational Materials

  • Creating a MOOC for Hyperledger and want to store in a GitHub repo (thread)

  • Discussion ensued, leading to the recommendation to create a GitHub repo now, and then bring a proposal for a corresponding WG (and named participants) back to the TSC next week.

    • VOTE:  Unanimous


Security Audit update

  • Security team has formed and mailing lists have been set up

  • Confidential bug handling in Jira

  • Have an outside firm (Nettitude) doing a security audit of Hyperledger Fabric

  • Nettitude is sending folks to Chicago Hackfest to present on methods/results and what has been done to harden the platform


Task force to look at GitHub for all Hyperledger projects

  • Chris Ferris made the suggestion to create a task force to look at using GitHub for all Hyperledger projects and evaluating what standard set of guidelines could be laid across all projects (i.e. enforcing DCO, code reviews, branching models, etc.) and to further enable collaboration between projects.

  • Brian noted that developer productivity and legal coherence should be the primary focus to optimize for

  • ACTION:  Chris to send a note to technical-discuss with thoughts and to solicit volunteers, and then bring a proposal back to the TSC


Next week:  PSWG Charter discussion/approval


--
Todd Benzies
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)


Re: [Hyperledger Project TSC] Rough Consensus in IETF

Christopher Ferris
 

Thanks, Ram!

On Wed, Aug 16, 2017 at 9:13 PM, Ram Jagadeesan (rjagadee) via hyperledger-tsc <hyperledger-tsc@...> wrote:

Folks,

 

Some info on rough consensus in IETF working groups.

How are your humming skills?

 

Regards,

 

Ram

 

https://www.ietf.org/tao.html#getting.things.done

“Another aspect of Working Groups that confounds many people is the fact that there is no formal voting. The general rule on disputed topics is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree. The exact method of determining rough consensus varies from Working Group to Working Group. Sometimes consensus is determined by "humming" — if you agree with a proposal, you hum when prompted by the chair. Most "hum" questions come in two parts: you hum to the first part if you agree with the proposal, or you hum to the second part if you disagree with the proposal. Newcomers find it quite peculiar, but it works. It is up to the chair to decide when the Working Group has reached rough consensus.

The lack of formal voting has caused some very long delays for some proposals, but most IETF participants who have witnessed rough consensus after acrimonious debates feel that the delays often result in better protocols. (And, if you think about it, how could you have "voting" in a group that invites all interested individuals to participate, and when it's impossible to count the participants?) Rough consensus has been defined in many ways; a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong.

A related problem is that some people think that their proposals should be discussed in the WG even when the WG Chairs do not. For example, if the proposed work is not really part of the charter, the WG Chairs may constrain the discussion of the proposal in order to keep the WG focused on the chartered work. Individuals who think that a WG should bring up a topic that is considered off-charter by the WG Chairs can bring their concerns to the responsible AD; the AD may agree to add the topic to the charter, or that it is already covered in the charter, or that the WG Chairs are correct and that the participant should work on the proposal outside the WG.

When a WG document has been fully discussed, it usually goes through Working Group Last Call (often abbreviated as "WGLC"). This is a hopefully-final time fo the WG to iron out issues. Sometimes, WGLC will bring out so many issues that there will be a second WGLC after the revisions have been incorporated. There are no formal rules for how a WGLC happens, or even if a WGLC is needed: it is up to the WG chairs.”

More detailed discussion: “On Consensus and Humming in the IETF”

https://tools.ietf.org/html/rfc7282

Having full consensus, or unanimity, would be ideal, but we don't

   require it: Requiring full consensus allows a single intransigent

   person who simply keeps saying "No!" to stop the process cold.  We

   only require rough consensus: If the chair of a working group

   determines that a technical issue brought forward by an objector has

   been truly considered by the working group, and the working group has

   made an informed decision that the objection has been answered or is

   not enough of a technical problem to prevent moving forward, the

   chair can declare that there is rough consensus to go forward, the

   objection notwithstanding.”

 


_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



Re: [Hyperledger Project TSC] a new repo for educational materials

Christopher Ferris
 

I was looking at GitHub again... it is getting closer to being capable of supporting our needs (though GH Issues not so much, frankly). It may deserve a thorough consideration by the TSC.

It troubles me that we are not aligned in how we govern projects. We should be striving to leverage the same toolchain.

Chris

On Wed, Aug 16, 2017 at 5:40 PM, David Huseby via hyperledger-tsc <hyperledger-tsc@...> wrote:
I really like the idea of just having a github repo for this material since github presents a much lower barrier to entry.  I can use this as an excuse to look into setting up a DCO bot to enforce our license restrictions.  I like the much leaner approach of just using github PRs and having a maintainer review and merge.

Dave

---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...
Skype: dwhuseby

On Tue, Aug 15, 2017 at 11:00 PM, alex g <alexandrag2254@...> wrote:
Hi all,

Thanks David for bringing this topic forward. 

I hope our efforts to develop example code for the intro HL MOOC leads to more educational and open source contributions from the community. 

I am happy to help any way I can, along with Robert and the other members of the DLT.education team. 

Thanks,
Alexandra

On Tue, Aug 15, 2017 at 10:08 PM, Baohua Yang <yangbaohua@...> wrote:
+1!

Training/education are so important for new members of a community.

TWGC has also contributed those training and education related work (specially in Greater China area) in past several months, we have organizing training/education seminars and demos. Now with the new training working group, we hope get more support from the wider community.

In addition, TWGC has organized volunteers to finish the translations of 20+ documentation and now we are evaluating those i18n platforms like transifex and zanata.

We will be glad to help explore the potential by building up an i18n Working Group, which will definitely cooperate closely with the training group by providing documentation with more languages, and also potential support of various version of the Hyperledger projects. We will be glad to post a more formal request in the mail-list after the evaluation.

Welcome for more comments/advice!

Thanks!

On Wed, Aug 16, 2017 at 11:39 AM, Brian Behlendorf via hyperledger-tsc <hyperledger-tsc@...dger.org> wrote:
Thanks Dave for raising this.  As greater context for the community, as I don't think we've mentioned this: we (the LF/Hyperledger team) have hired Robert Schwentker, cc'd on this email, and a team he has pulled together, to develop training materials for Hyperledger - a breadth-first survey of the different projects available, as well as "Blockchain for Enterprise 101" style content.  We plan to release this content as CC licensed works and would like to host them on Hyperledger.  We'd like to set it up such that each project can update and extend the training material for more in-depth tutorials on different features.  This will allow and we hope encourage companies to provide training products and services based on this content, and contribute back in the form of updates and improvements and extensions - just like open source code. 

We felt it was important to bootstrap a foundational collection of such content to get this effort kicked off.  What we haven't worked out yet is the best governance model for the stewardship and evolution of this content, both the Hyperledger-wide content and the project-specific content.  This "content" would include the source for all training documents, videos, as well as example code, which we'd love to see grow into a healthy collection for each project.  We also hope this would help create some repeatable templates and other assets for helping to draw out the differences between each projects - e.g imagine something similar to the "Fabric 1.0 Deep Dive" deck created by Tracy and used by Jonathan Levi in the recent hackathon, but developed for each project, using similar metaphors and diagrams and terms, but mapped to the unique features and characteristics of each platform.  The first tranche of content should be available in September. 

Perhaps at that point the best thing to do would be to propose a "Training" project at Hyperledger, a ninth one to sit next to the other 8.  That can at least host the HL-wide content and standard templates, and the project-specific content could either be a part of this project too or a part of each of the others (e.g. linking to a repo like fabric-training, sawtooth-training, etc).

Alternately, we could establish a "Training Working Group", a complement to the Architecture, Identity, etc technical WG's, though they would be chartered with the development of common code and content much more actively than typical technical WGs are.  The advantage of this is to firmly establish it as a cross-project effort aiming to assist in HL-wide coherence and integration, as Arch and Identity and others are.

In the short term, would anyone be opposed to the establishment of a "training" repo at https://github.com/hyperledger/ ?  Bootstrapped with Robert, Tracy, and a few others (and anyone else interested) as co-maintainers, with a formal proposal to the TSC to come shortly?

Brian





On 08/15/2017 05:02 PM, David Huseby via hyperledger-tsc wrote:
Hi TSC,

As part of the educational course we are developing for students to learn about Hyperledger, we are developing some example code that we'd like to store in a git repo somewhere.  Two questions for the TSC:

1) Should the repo be on Gerrit or Github?
2) May we have approval to set it up?

Thanks
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...
Skype: dwhuseby


_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...ger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...g
Twitter: @brianbehlendorf

_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...ger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc




--
Best wishes!

Baohua Yang



_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



Re: [Hyperledger Project TSC] [technical-discuss] Privacy and Confidentiality not assured in Ordering Service?

Baohua Yang
 

Agree, there's always trade-off in system engineering.

We need to carefully design out some way,  to make it both efficient to perform and reasonable to operate.

On Thu, Aug 17, 2017 at 9:34 AM, Jonathan Levi (HACERA) <jonathan@...> wrote:
Yes, channels are individual blockchains, and I guess Extreme Us's questions are from the observations that all these "blockchains" are sharing the same ordering service, due to the design today (i.e., using kafka).  <snip>

Indeed. I tried to quickly mention that at the end of the Linux Foundation webinar (the minute or so left in the end) when people asked us about channels and the performance. Kafka scales, no doubt. I was trying to address the question of whether 100s and 1000s of channel are recommended by basically saying that it’s all a matter of "whether or not you trust the orderer/ordering service”. In general, by the way, personally, I do. Otherwise, I would not share/post some transactions on such a chain, let alone that there are way to check/verify matters, in some cases where the orderer is “not fair”.

It may get extremely complicated if/when we don’t take advantage of the permissioning steps that are in place. This is one of the reasons why there are some pretty complicated consensus algorithms out there (proposed mostly for public chains)… and due to the complexity, they do not offer the same performance/transaction rate/throughput.

Thanks,

Jonathan Levi Chief Sparkling Officer
HACERA
  -  Blockchain with Confidence

E  jonathan@...
W  https://hacera.com

On Aug 16, 2017, at 5:09 PM, Baohua Yang via hyperledger-tsc <hyperledger-tsc@lists.hyperledger.org> wrote:

Thanks for the clarification, and some comments in line.

On Thu, Aug 17, 2017 at 6:20 AM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@...>wrote:
Hi Brian,

One of the key features of privacy-preserving sidechains or lightning network-inspired projects is the ability to move things (the outputs of the all of the transactions on the subnet) back to the blockchain in a way that doesn't reveal what happened on the subnet (the intermediate states).  This doesn't exist yet in Fabric channels--you would have to build it yourself if you wanted to use it (I assume several people have their own implementations of this protocol already, including probably Jonathan).

This additional feature gives sidechains/lightning networks a lot of their privacy guarantees.  I could be wrong here, but I'd guess that a lot of the confusion about the privacy of Fabric channels comes from the ambiguity about returning the state of channels to the main blockchain.

Exactly, many people are familiar with those public blockchain techniques, and would think them as a base and then compare with Hyperledger platforms. I believe it's easy to introduce confusions by simply comparing the channel concept in fabric, to those sidechans/lightning network features, which initially helps to improve the scalability and efficiency in bitcoin network.
 

As Jonathan points out correctly, Fabric channels fundamentally are individual blockchains.  In order to achieve the same functionality as privacy preserving sidechains/lightning networks, we need more functionality than just channels, but the tools to do this can be built on channels (cue advertisement for Jonathan).

Yes, channels are individual blockchains, and I guess Extreme Us's questions are from the observations that all these "blockchains" are sharing the same ordering service, due to the design today (i.e., using kafka).  With more consensus types (e.g., BFT) and those sidedb features, it would be more clear that we can enhance the data transparency in every corner.
 

I hope this clarifies things.  Let me know what you all think.

Thanks,
Hart

-----Original Message-----
From: hyperledger-technical-discuss-bounces@lists.hyperledger.org [mailto:hyperledger-technical-discuss-bounces@...] On Behalf Of Brian Behlendorf via hyperledger-technical-discuss
Sent: Wednesday, August 16, 2017 2:50 PM
To: hyperledger-technical-discuss@...
Subject: Re: [technical-discuss] Privacy and Confidentiality not assured in Ordering Service?

I appreciate Kelly and Jonathan's muted rebuke of my plea to move Fabric-specific commentary to the fabric mailing list :)  To which I'll reply that perhaps this is an opportunity to talk about something cross-project anyways, echoing last week's conversation about
confidentiality:

On 08/16/2017 02:07 PM, Jonathan Levi (HACERA) via hyperledger-technical-discuss wrote:
> But in the meantime, I would like to just quickly highlight, that in Hyperledger Fabric (1.0), channels fundamentally _are_ individual blockchains. There is a backing blockchain structure for each channel. Fabric just makes it very easy for you to spin them up with a subset of consortium participants… but essentially, this is what’s going on “under the hood”.

And from a 100k foot view, this is not unlike "side-chains", Lightning,
and other approaches to scalability that have to do with subsetting
networks for other transactions.  It would be helpful to know if other
systems (Sawtooth, Iroha, etc) have support for this kind of subsetting
or side-channelling, and if so what it's called (is it worth trying to
synchronize terminology?) and if not whether adopting a common
approach/terminology would help.  It's not the only tool in the
confidentiality or scalability toolkit, but seems like it will be a
recurring one.

Brian

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...g
Twitter: @brianbehlendorf

_______________________________________________
hyperledger-technical-discuss mailing list
hyperledger-technical-discuss@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-technical-discuss
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...ger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



-- 
Best wishes!

Baohua Yang
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc




--
Best wishes!

Baohua Yang


Re: [Hyperledger Project TSC] [technical-discuss] Privacy and Confidentiality not assured in Ordering Service?

Jonathan Levi (HACERA)
 

Yes, channels are individual blockchains, and I guess Extreme Us's questions are from the observations that all these "blockchains" are sharing the same ordering service, due to the design today (i.e., using kafka).  <snip>

Indeed. I tried to quickly mention that at the end of the Linux Foundation webinar (the minute or so left in the end) when people asked us about channels and the performance. Kafka scales, no doubt. I was trying to address the question of whether 100s and 1000s of channel are recommended by basically saying that it’s all a matter of "whether or not you trust the orderer/ordering service”. In general, by the way, personally, I do. Otherwise, I would not share/post some transactions on such a chain, let alone that there are way to check/verify matters, in some cases where the orderer is “not fair”.

It may get extremely complicated if/when we don’t take advantage of the permissioning steps that are in place. This is one of the reasons why there are some pretty complicated consensus algorithms out there (proposed mostly for public chains)… and due to the complexity, they do not offer the same performance/transaction rate/throughput.

Thanks,

Jonathan Levi Chief Sparkling Officer
HACERA
  -  Blockchain with Confidence

E  jonathan@...
W  https://hacera.com

On Aug 16, 2017, at 5:09 PM, Baohua Yang via hyperledger-tsc <hyperledger-tsc@...> wrote:

Thanks for the clarification, and some comments in line.

On Thu, Aug 17, 2017 at 6:20 AM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@...>wrote:
Hi Brian,

One of the key features of privacy-preserving sidechains or lightning network-inspired projects is the ability to move things (the outputs of the all of the transactions on the subnet) back to the blockchain in a way that doesn't reveal what happened on the subnet (the intermediate states).  This doesn't exist yet in Fabric channels--you would have to build it yourself if you wanted to use it (I assume several people have their own implementations of this protocol already, including probably Jonathan).

This additional feature gives sidechains/lightning networks a lot of their privacy guarantees.  I could be wrong here, but I'd guess that a lot of the confusion about the privacy of Fabric channels comes from the ambiguity about returning the state of channels to the main blockchain.

Exactly, many people are familiar with those public blockchain techniques, and would think them as a base and then compare with Hyperledger platforms. I believe it's easy to introduce confusions by simply comparing the channel concept in fabric, to those sidechans/lightning network features, which initially helps to improve the scalability and efficiency in bitcoin network.
 

As Jonathan points out correctly, Fabric channels fundamentally are individual blockchains.  In order to achieve the same functionality as privacy preserving sidechains/lightning networks, we need more functionality than just channels, but the tools to do this can be built on channels (cue advertisement for Jonathan).

Yes, channels are individual blockchains, and I guess Extreme Us's questions are from the observations that all these "blockchains" are sharing the same ordering service, due to the design today (i.e., using kafka).  With more consensus types (e.g., BFT) and those sidedb features, it would be more clear that we can enhance the data transparency in every corner.
 

I hope this clarifies things.  Let me know what you all think.

Thanks,
Hart

-----Original Message-----
From: hyperledger-technical-discuss-bounces@... [mailto:hyperledger-technical-discuss-bounces@lists.hyperledger.org] On Behalf Of Brian Behlendorf via hyperledger-technical-discuss
Sent: Wednesday, August 16, 2017 2:50 PM
To: hyperledger-technical-discuss@lists.hyperledger.org
Subject: Re: [technical-discuss] Privacy and Confidentiality not assured in Ordering Service?

I appreciate Kelly and Jonathan's muted rebuke of my plea to move Fabric-specific commentary to the fabric mailing list :)  To which I'll reply that perhaps this is an opportunity to talk about something cross-project anyways, echoing last week's conversation about
confidentiality:

On 08/16/2017 02:07 PM, Jonathan Levi (HACERA) via hyperledger-technical-discuss wrote:
> But in the meantime, I would like to just quickly highlight, that in Hyperledger Fabric (1.0), channels fundamentally _are_ individual blockchains. There is a backing blockchain structure for each channel. Fabric just makes it very easy for you to spin them up with a subset of consortium participants… but essentially, this is what’s going on “under the hood”.

And from a 100k foot view, this is not unlike "side-chains", Lightning,
and other approaches to scalability that have to do with subsetting
networks for other transactions.  It would be helpful to know if other
systems (Sawtooth, Iroha, etc) have support for this kind of subsetting
or side-channelling, and if so what it's called (is it worth trying to
synchronize terminology?) and if not whether adopting a common
approach/terminology would help.  It's not the only tool in the
confidentiality or scalability toolkit, but seems like it will be a
recurring one.

Brian

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

_______________________________________________
hyperledger-technical-discuss mailing list
hyperledger-technical-discuss@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-technical-discuss
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



-- 
Best wishes!

Baohua Yang
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


[Hyperledger Project TSC] Rough Consensus in IETF

Ram Jagadeesan (rjagadee)
 

Folks,

 

Some info on rough consensus in IETF working groups.

How are your humming skills?

 

Regards,

 

Ram

 

https://www.ietf.org/tao.html#getting.things.done

“Another aspect of Working Groups that confounds many people is the fact that there is no formal voting. The general rule on disputed topics is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree. The exact method of determining rough consensus varies from Working Group to Working Group. Sometimes consensus is determined by "humming" — if you agree with a proposal, you hum when prompted by the chair. Most "hum" questions come in two parts: you hum to the first part if you agree with the proposal, or you hum to the second part if you disagree with the proposal. Newcomers find it quite peculiar, but it works. It is up to the chair to decide when the Working Group has reached rough consensus.

The lack of formal voting has caused some very long delays for some proposals, but most IETF participants who have witnessed rough consensus after acrimonious debates feel that the delays often result in better protocols. (And, if you think about it, how could you have "voting" in a group that invites all interested individuals to participate, and when it's impossible to count the participants?) Rough consensus has been defined in many ways; a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong.

A related problem is that some people think that their proposals should be discussed in the WG even when the WG Chairs do not. For example, if the proposed work is not really part of the charter, the WG Chairs may constrain the discussion of the proposal in order to keep the WG focused on the chartered work. Individuals who think that a WG should bring up a topic that is considered off-charter by the WG Chairs can bring their concerns to the responsible AD; the AD may agree to add the topic to the charter, or that it is already covered in the charter, or that the WG Chairs are correct and that the participant should work on the proposal outside the WG.

When a WG document has been fully discussed, it usually goes through Working Group Last Call (often abbreviated as "WGLC"). This is a hopefully-final time fo the WG to iron out issues. Sometimes, WGLC will bring out so many issues that there will be a second WGLC after the revisions have been incorporated. There are no formal rules for how a WGLC happens, or even if a WGLC is needed: it is up to the WG chairs.”

More detailed discussion: “On Consensus and Humming in the IETF”

https://tools.ietf.org/html/rfc7282

Having full consensus, or unanimity, would be ideal, but we don't

   require it: Requiring full consensus allows a single intransigent

   person who simply keeps saying "No!" to stop the process cold.  We

   only require rough consensus: If the chair of a working group

   determines that a technical issue brought forward by an objector has

   been truly considered by the working group, and the working group has

   made an informed decision that the objection has been answered or is

   not enough of a technical problem to prevent moving forward, the

   chair can declare that there is rough consensus to go forward, the

   objection notwithstanding.”

 


[Hyperledger Project TSC] Agenda for August 17th, 2017

Todd Benzies <tbenzies@...>
 

  • Hackfest Planning
  • TSC Annual Election
    • Voting begins on Thursday (8/17) at 8:00am PT -- details will be sent directly to all eligible voters (candidate bios attached)
  • Repo for Educational Materials thread
  • Security Audit update

--
Todd Benzies
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)


Re: [Hyperledger Project TSC] [technical-discuss] Privacy and Confidentiality not assured in Ordering Service?

Baohua Yang
 

Thanks for the clarification, and some comments in line.

On Thu, Aug 17, 2017 at 6:20 AM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@...> wrote:
Hi Brian,

One of the key features of privacy-preserving sidechains or lightning network-inspired projects is the ability to move things (the outputs of the all of the transactions on the subnet) back to the blockchain in a way that doesn't reveal what happened on the subnet (the intermediate states).  This doesn't exist yet in Fabric channels--you would have to build it yourself if you wanted to use it (I assume several people have their own implementations of this protocol already, including probably Jonathan).

This additional feature gives sidechains/lightning networks a lot of their privacy guarantees.  I could be wrong here, but I'd guess that a lot of the confusion about the privacy of Fabric channels comes from the ambiguity about returning the state of channels to the main blockchain.

Exactly, many people are familiar with those public blockchain techniques, and would think them as a base and then compare with Hyperledger platforms. I believe it's easy to introduce confusions by simply comparing the channel concept in fabric, to those sidechans/lightning network features, which initially helps to improve the scalability and efficiency in bitcoin network.
 

As Jonathan points out correctly, Fabric channels fundamentally are individual blockchains.  In order to achieve the same functionality as privacy preserving sidechains/lightning networks, we need more functionality than just channels, but the tools to do this can be built on channels (cue advertisement for Jonathan).

Yes, channels are individual blockchains, and I guess Extreme Us's questions are from the observations that all these "blockchains" are sharing the same ordering service, due to the design today (i.e., using kafka).  With more consensus types (e.g., BFT) and those sidedb features, it would be more clear that we can enhance the data transparency in every corner.
 

I hope this clarifies things.  Let me know what you all think.

Thanks,
Hart

-----Original Message-----
From: hyperledger-technical-discuss-bounces@... [mailto:hyperledger-technical-discuss-bounces@lists.hyperledger.org] On Behalf Of Brian Behlendorf via hyperledger-technical-discuss
Sent: Wednesday, August 16, 2017 2:50 PM
To: hyperledger-technical-discuss@lists.hyperledger.org
Subject: Re: [technical-discuss] Privacy and Confidentiality not assured in Ordering Service?

I appreciate Kelly and Jonathan's muted rebuke of my plea to move Fabric-specific commentary to the fabric mailing list :)  To which I'll reply that perhaps this is an opportunity to talk about something cross-project anyways, echoing last week's conversation about
confidentiality:

On 08/16/2017 02:07 PM, Jonathan Levi (HACERA) via hyperledger-technical-discuss wrote:
> But in the meantime, I would like to just quickly highlight, that in Hyperledger Fabric (1.0), channels fundamentally _are_ individual blockchains. There is a backing blockchain structure for each channel. Fabric just makes it very easy for you to spin them up with a subset of consortium participants… but essentially, this is what’s going on “under the hood”.

And from a 100k foot view, this is not unlike "side-chains", Lightning,
and other approaches to scalability that have to do with subsetting
networks for other transactions.  It would be helpful to know if other
systems (Sawtooth, Iroha, etc) have support for this kind of subsetting
or side-channelling, and if so what it's called (is it worth trying to
synchronize terminology?) and if not whether adopting a common
approach/terminology would help.  It's not the only tool in the
confidentiality or scalability toolkit, but seems like it will be a
recurring one.

Brian

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

_______________________________________________
hyperledger-technical-discuss mailing list
hyperledger-technical-discuss@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-technical-discuss
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



--
Best wishes!

Baohua Yang


Re: [Hyperledger Project TSC] a new repo for educational materials

David Huseby <dhuseby@...>
 

I agree with Brian.  I think we should talk about making a rule that repos must be owned by somebody (i.e. there has to be maintainers).  No orphan code/content.

---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...
Skype: dwhuseby

On Wed, Aug 16, 2017 at 3:22 PM, Brian Behlendorf via hyperledger-tsc <hyperledger-tsc@...> wrote:
The question isn't really github vs gerrit for this material right now; the question is who's responsible for that repository.  I'd like to suggest the TSC approve a github repo for training at tomorrow's TSC call, so that folks can get started collaborating, and then in the next week or two we can figure out if we want it as a technical working group or software project.

Brian


On 08/16/2017 03:09 PM, Jonathan Levi (HACERA) via hyperledger-tsc wrote:
I also think that keeping it simple makes sense. Github is probably easier and indeed presents a much lower barrier to entry.

FWIW,

Jonathan Levi 
Chief Sparkling Officer
HACERA
  -  Blockchain with Confidence

E  jonathan@...
W  https://hacera.com

On Aug 16, 2017, at 2:40 PM, David Huseby via hyperledger-tsc <hyperledger-tsc@lists.hyperledger.org> wrote:

I really like the idea of just having a github repo for this material since github presents a much lower barrier to entry.  I can use this as an excuse to look into setting up a DCO bot to enforce our license restrictions.  I like the much leaner approach of just using github PRs and having a maintainer review and merge.

Dave

---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...
Skype: dwhuseby

On Tue, Aug 15, 2017 at 11:00 PM, alex g <alexandrag2254@...> wrote:
Hi all,

Thanks David for bringing this topic forward. 

I hope our efforts to develop example code for the intro HL MOOC leads to more educational and open source contributions from the community. 

I am happy to help any way I can, along with Robert and the other members of the DLT.education team. 

Thanks,
Alexandra

On Tue, Aug 15, 2017 at 10:08 PM, Baohua Yang <yangbaohua@...> wrote:
+1!

Training/education are so important for new members of a community.

TWGC has also contributed those training and education related work (specially in Greater China area) in past several months, we have organizing training/education seminars and demos. Now with the new training working group, we hope get more support from the wider community.

In addition, TWGC has organized volunteers to finish the translations of 20+ documentation and now we are evaluating those i18n platforms like transifex and zanata.

We will be glad to help explore the potential by building up an i18n Working Group, which will definitely cooperate closely with the training group by providing documentation with more languages, and also potential support of various version of the Hyperledger projects. We will be glad to post a more formal request in the mail-list after the evaluation.

Welcome for more comments/advice!

Thanks!

On Wed, Aug 16, 2017 at 11:39 AM, Brian Behlendorf via hyperledger-tsc <hyperledger-tsc@...dger.org> wrote:
Thanks Dave for raising this.  As greater context for the community, as I don't think we've mentioned this: we (the LF/Hyperledger team) have hired Robert Schwentker, cc'd on this email, and a team he has pulled together, to develop training materials for Hyperledger - a breadth-first survey of the different projects available, as well as "Blockchain for Enterprise 101" style content.  We plan to release this content as CC licensed works and would like to host them on Hyperledger.  We'd like to set it up such that each project can update and extend the training material for more in-depth tutorials on different features.  This will allow and we hope encourage companies to provide training products and services based on this content, and contribute back in the form of updates and improvements and extensions - just like open source code. 

We felt it was important to bootstrap a foundational collection of such content to get this effort kicked off.  What we haven't worked out yet is the best governance model for the stewardship and evolution of this content, both the Hyperledger-wide content and the project-specific content.  This "content" would include the source for all training documents, videos, as well as example code, which we'd love to see grow into a healthy collection for each project.  We also hope this would help create some repeatable templates and other assets for helping to draw out the differences between each projects - e.g imagine something similar to the "Fabric 1.0 Deep Dive" deck created by Tracy and used by Jonathan Levi in the recent hackathon, but developed for each project, using similar metaphors and diagrams and terms, but mapped to the unique features and characteristics of each platform.  The first tranche of content should be available in September. 

Perhaps at that point the best thing to do would be to propose a "Training" project at Hyperledger, a ninth one to sit next to the other 8.  That can at least host the HL-wide content and standard templates, and the project-specific content could either be a part of this project too or a part of each of the others (e.g. linking to a repo like fabric-training, sawtooth-training, etc).

Alternately, we could establish a "Training Working Group", a complement to the Architecture, Identity, etc technical WG's, though they would be chartered with the development of common code and content much more actively than typical technical WGs are.  The advantage of this is to firmly establish it as a cross-project effort aiming to assist in HL-wide coherence and integration, as Arch and Identity and others are.

In the short term, would anyone be opposed to the establishment of a "training" repo at https://github.com/hyperledger/ ?  Bootstrapped with Robert, Tracy, and a few others (and anyone else interested) as co-maintainers, with a formal proposal to the TSC to come shortly?

Brian





On 08/15/2017 05:02 PM, David Huseby via hyperledger-tsc wrote:
Hi TSC,

As part of the educational course we are developing for students to learn about Hyperledger, we are developing some example code that we'd like to store in a git repo somewhere.  Two questions for the TSC:

1) Should the repo be on Gerrit or Github?
2) May we have approval to set it up?

Thanks
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...
Skype: dwhuseby


_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...ger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...g
Twitter: @brianbehlendorf

_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...ger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc




--
Best wishes!

Baohua Yang


_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc



_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


2501 - 2520 of 3559