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

 

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

We are having an unplanned outage.

Status updates here:

https://status.linuxfoundation.org/incidents/kxhh640z07th

Ry

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

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

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

T  https://twitter.com/HACERA_INC
L  https://linkedin.com/in/levitate

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