Date   

Re: Hyperledger Besu Proposal is Live

Middleton, Dan <dan.middleton@...>
 

First off thanks for all the work going into the proposal and the timely responses to this list and the wiki. While there is already collaboration with portions of the Ethereum and EEA communities, more involvement and collaboration is always very welcome. I think this project could foster even more and I have a just a few questions remaining in my mind after reviewing all the comments in this thread and the wiki.

 

 

Adding another framework to Hyperledger presents both opportunities and risks. On the risks side, we are just now at a point where we were starting to see real progress on componentization and steps towards architectural convergence. A siloed project could upset that progress. I appreciate the Besu proposers expressing a willingness to work with existing component projects (e.g. Transact & Ursa). Is Besu architected in a way to also provide components to the rest of Hyperledger? Are there pieces that offer independent value?

 

 

On the opportunities side, with new frameworks we’ve always had a constantly rising bar… what does this new proposal bring that is unique to our greenhouse. The most prominent item I see is Ethereum mainnet compatibility. Could someone articulate the value of that in specific terms? I am familiar with the notion of using mainnet as a receipt log. I would like to understand other benefits and use cases for permissioned networks to link with mainnet.

 

I look forward to discussing this proposal in our steering meeting tomorrow (8/22).

 

Thanks,

 

Dan Middleton

Chair, Technical Steering Committee

 

 

From: <tsc@...> on behalf of Jonathan Levi <jonathan@...>
Reply-To: "jonathan@..." <jonathan@...>
Date: Tuesday, August 20, 2019 at 6:19 PM
To: "joseph.lubin@..." <joseph.lubin@...>, Grace Hartley <grace.hartley@...>
Cc: Virgil Griffith <virgil@...>, Dan O'Prey <dan@...>, Hyperledger List <tsc@...>, Daniel Heyman <daniel.heyman@...>, Rob Dawson <rob.dawson@...>, Mohan Venkataraman <mohan.venkataraman@...>
Subject: Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live

 

Joe - we can probably do it, and pretty quickly. We already have both Fabric and Ethereum nodes (full nodes) on the Unbounded Network for quite a while... and we are already bridging Fabric - Quorum (JPM's), etc...

 

BUT, 

 

I don't think being under the same foundation will guarantee that people actively "make it work". One can argue that some of the biggest Fabric supporters also part of EEA/TTI and still haven't made this a priority. I wonder who will spend the money and time.. 

 

Also, for those more familiar with the Ethereum Ecosystem - there are so many tools that are not part of Hyperledger, from Truffle to Infura and I don't want to even mention block explorers and others. Do we want a commitment that all these tools will be part of Hyperledger, or that code will move from these projects (some are with GPL and others) into the respective HL candidates? There are actually announcements left, right and center about truffle adding Fabric support, etc. These developments are not done in Hyperledger. 

 

-----

 

What I don't understand is, since when we have ever required anything like some of the things I see below from a project at incubation? Shall we make these a future requirement? 

 

I will put together a wider response tomorrow, actually with a few questions that I belive we should answer within Hyperledger first, before we make so many changes "after a proposal is submitted". We saw it with Grid, which required an escalation to the board, and we are beginning to see some similar traits.

 

In the meantime, enjoy the Web3 Summit, Berlin BC Week, where applies.

 

Jonathan Levi

 

 

 

 

 

On Wed, Aug 21, 2019 at 1:20, Joseph Lubin

<joseph.lubin@...> wrote:

Mohan,

 

We have also engaged in discussions for a year of so with some Fabric focussed groups around finding a project that would benefit from a Fabric-Ethereum bridge.  To this point we haven't found a partner that was interested in doing this with us, but I expect this will happen quite quickly if we are all part of the same foundation. 

 

 

 

On Tue, Aug 20, 2019 at 6:08 PM, Grace Hartley <grace.hartley@...> wrote:

Hi Mohan, 

 

Here are our team's thoughts, but we'd love to hear the community's feedback as well.

 

In the short term we see the majority of interop and cross ledger communication happening at layer 2.  We are actively working with teams in the wider community to ensure that Besu facilitates layer 2 cross ledger communication, particularly working with the web3j team who are adding support for Hyperledger Fabric, and the Truffle team who are doing the same.



In the medium-term we are very interested in interoperability between chains, and we will be investing increasing effort in this direction, and in doing so expect to leverage many of the existing Hyperledger projects to do so. The two most obvious projects for collaboration currently are Burrow due to it’s EVM execution environment and aim of providing a practical base for EVM extensions in a many-chain world. In addition we look towards working with Quilt for its implementation of the interledger protocol. Quilt is a natural collaboration opportunity due to both the technologies it supports, and the fact that it is a JVM based technology.  

 

Thanks,

Grace

 

On Tue, Aug 20, 2019 at 11:44 AM Mohan Venkataraman <mohan. venkataraman@ chainyard. com> wrote:

Thank you Grace, for the kind response

 

How do you foresee Besu converge with Hyperledger technologies. For example, do you see Besu converging or inter-operating with Fabric or Sawtooth anytime. I do see blockchain networks going Hybrid as they evolve. There are several other yperledger projects like URSA and Transact. Quite interested in knowing Besu leveraging these.

 

Thanks

Mohan

 

On Mon, Aug 19, 2019, 1:15 PM Grace Hartley <grace. hartley@ consensys. net> wrote:

Hi All,

 

Thanks for the thoughtful questions. We've responded to them below.

 

Virgil’s Question: 

Why the name "Besu"?  That seems an odd choice, I'd imagine you'd want to pick an Ethereum-related word like "Rainbow", "Unicorn", or some such.

 

PegaSys' Response:

As Dan mentioned, we had a trademark challenge with Pantheon and we have to switch our name regardless of the Proposal. We chose Hyperledger Besu because “besu” means base in Japanese. We felt like base indicated how we developed the Ethereum client. We believe it is a solid foundation for blockchain developers to work on to run networks, build applications or send transactions, as an example.

 

Hyperledger’s naming principles target names that are not “common” words and that are easy to trademark. Unicorn, rainbow and all other words we explored that have more direct connections to Ethereum will have trademark challenges.

 

Mohan’s Question: 

Hyperledger technologies support a permissioned blockchain. They do not, at least to my understanding, have a crypto aspect. Is the intent to incubate Besu as a permissioned ethereum based blockchain and support interoperability with other platforms like Sawtooth, Iroha , Fabric? Also, how does this relate to Hyperledger Burrow?

 

PegaSys' Response:
The intent for Besu to be submitted in its current form. It can be run on the Ethereum public network or on private permissioned networks, as well as test networks such as Rinkeby, Ropsten, and Görli. We think public chain compatibility aligns with the enterprise market’s growing interest in using mainnet for a broader and more diverse set of use cases. Because this project is a protocol, it can be used for many different applications. Enabling cryotocurrency is only one of the applications. This project would be the first public chain compatible client within Hyperledger.

Silas provides a great response on his thoughts about how the project relates to Burrow and some ideas around collaboration here. Burrow is most well known for its EVM, which could connect in with Besu. They have a number of other components that we have started discussing with Silas. We are excited about closely working with the Hyperledger community to find areas for interoperability across the other projects. We have ideas mentioned in the Proposal around who we can collaborate with. 

 

Thanks,

Grace

 

 

On Sat, Aug 17, 2019 at 2:43 PM Mohan Venkataraman <mohan. venkataraman@ chainyard. com> wrote:

Hyperledger technologies support a permissioned blockchain. They do not, at least to my understanding, have a crypto aspect. Is the intent to incubate Besu as a permissioned ethereum based blockchain and support interoperability with other platforms like Sawtooth, Iroha , Fabric? Also, how does this relate to Hyperledger Burrow?

 

 

Regards

 

Mohan Venkataraman

Chainyard

 

On Sat, Aug 17, 2019, 9:41 AM Virgil Griffith via Lists. Hyperledger. Org <virgil=ethereum. org@ lists. hyperledger. org> wrote:

Why the name "Besu"?  That seems an odd choice, I'd imagine you'd want to pick an Ethereum-related word like "Rainbow", "Unicorn", or some such.

 

-V

 

On Sat, Aug 17, 2019 at 9:21 PM Dan O'Prey via Lists. Hyperledger. Org <dan=digitalasset. com@ lists. hyperledger. org> wrote:

There were some trademark issues around "Pantheon", unfortunately


Dan O'Prey

CMO & Head of Community / +1 646 647 5957

Digital Asset, creators of DAML

 

 

On Fri, Aug 16, 2019 at 8:28 PM Morgan Bauer <mbauer@ us. ibm. com> wrote:

Why rename it?

On 8/8/19 11:23:12, grace. hartley@ consensys. net wrote:

Hi All, We are excited to share that PegaSys, the Protocol Engineering team at ConsenSys, submitted the Proposal for our Ethereum client, Hyperledger Besu (currently known as Pantheon), for your consideration as a new Hyperledger project. 

 

We welcome your feedback on the Proposal and look forward to engaging with you on it. Feel free to send our team feedback via email or comment directly in the Proposal document.

Thank you,

PegaSys and ConsenSys Team Joseph Lubin, ConsenSys, joseph. lubin@ consensys. netDaniel Heyman, ConsenSys/ PegSys, daniel. heyman@ consensys. netRob Dawson, ConsenSys/ PegaSys, rob. dawson@ consensys. netGrace Hartley, ConsenSys/PegaSys, grace. hartley@ consensys. netDanno Ferrin, ConsenSys/PegaSys, danno. ferrin@ consensys. net

 


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http:/ / www. digitalasset. com/ emaildisclaimer. html. If you are not the intended recipient, please delete this message.

 


Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Baohua Yang
 

It would be a good idea if we can have some consensus library that is sharable among different blockchains, that's more valuable than a single implementation.

We have Ursa which covers the crypto techniques already.

Thanks!

On Wed, Aug 21, 2019 at 9:12 AM Shawn Amundson <amundson@...> wrote:
I'm a big fan of the idea of top-level consensus projects. We've

As a community, we've already had many conversations about consolidating what we already have across the existing projects. The effort to maintain consensus engines is exceptionally high, which makes them good candidates for sharing across the DLT projects. The previous conversations have focused on what we would need to do in order to have a universal consensus API across projects.

Fundamentally what we need out of that universal consensus API:

1. A library which can work with both Rust and Go
2. DLT agnostic, so all the DLTs can adopt it. This means it does not define any network protocols, should not define it's own system processes, etc.
2a. It should not define a networking layer (it should rely on the DLT to provide it)

We've started down this path within our Sawtooth work. The initial iteration can be seen in Sawtooth's existing consensus engine design, and we are working on a library-based iteration of the approach to make it more easily consumable outside of Sawtooth.

I'd like to see a commitment in this project to support all Hyperledger DLTs. That support can come in the form of being agnostic (doing the Fabric/Burrow integration in Fabric/Burrow and keeping Babble agnostic so it can be adopted by other projects), which is the approach taken by Ursa and Transact.

Eventually, maybe we end up with a lot of top-level consensus projects:

- Consensus API - defines the APIs which consensus engines implement and the DLT-facing Rust and Go APIs for using them
- Babble - Hashgraph
- PBFT - derived from Sawtooth's PBFT implementation
- PoET - derived from Sawtooth's PoET implementation
- Raft - derived from Fabric or Sawtooth's Raft implementations
- other projects implementing the Consensus API

-Shawn


On Wed, Aug 21, 2019 at 9:11 AM Silas Davis via Lists.Hyperledger.Org <silas=monax.io@...> wrote:
Time flies...

If Martin is still interested, I would support this project. I think it is quite in-line with the recent spate of cross-cutting project types, whilst still being complete as an implementation - it's a fully executable thing not just library. It occupies a similar cutout to that of Tendermint.

Silas

On Tue, 20 Aug 2019 at 05:57, Stefan Buhrmester <buhrmi@...> wrote:
Two years later....

On Tue, Jul 4, 2017 at 4:18 PM, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thanks for the information Brian,

Before we go on to take care of the patent issues and changing the name we need to establish if it actually makes sense to incorporate our code base with Hyperledger.

On our side, we will need to show that the algorithm performs well compared to other comparable systems and that it has other qualitative advantages.

It also seems that there is no consensus among the TSC as to whether this type of project is a fit architecturally for Hyperledger.

So it would be good to keep the discussion going and to put the proposal on hold until these points are addressed.

Best,
Martin


On 4 Jul 2017, at 04:09, Brian Behlendorf <bbehlendorf@...> wrote:

I want to follow up and state that Leemon Baird (Hashgraph author) had reached out to me, and I asked him to confirm that this interpretation matches his understanding.  It sounds like they have multiple patents awarded and others filed and awaiting award relating to hashgraph, and we'd need either a clear grant to those patents as applied to Hyperledger code (essentially a DCO) from them or a statement that indeed their patents do not read upon Babble for the reasons you gave, before giving the OK here for babble to be contributed.  Otherwise you're asking a lot of people to take on a difficult-to-quantify risk, and patent issues are much more challenging to fix later than say copyright or trademark issues. 

Regarding the name - it has to be a name that isn't trademarked or otherwise owned/managed by another company, as that could lead to confusion.  Sometimes it's best to come up with a new name as it enters, such as happened with Fabric, Sawtooth, Indy, and Burrow.  I take it babble.io would still be a company & trademark you'd want to keep.

Brian

On 06/28/2017 11:14 AM, Martin Arrivets wrote:
Hello Brian,

Here is a link to a document describing the IP landscape around the issue: 

We suggest the name Babble.

Hope this helps,

Regards,
Martin


-----Original message-----
From: Brian Behlendorf via hyperledger-tsc
Sent: Wednesday, June 28 2017, 5:30 pm
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

I can ask our counsel once we know more about what's being proposed, and how that relates to the patent landscape.  Can someone involved in the proposal provide a write-up (which should be part of the repository, eventually) that details the known IP in this field, and how it relates to the project?  Just forwarding this thread probably isn't enough to go on.

Also, can we call this something more creative than just "Consensus Platform"?

Brian

On 06/28/2017 09:22 AM, Middleton, Dan via hyperledger-tsc wrote:

I don’t view journal publication as a gate on adding a project. It can be a factor in assessing technical merit but not the only factor. I’ll be looking whether there is sufficient detail/formality in the proposal and its references to assess that technical merit - regardless of academic status.

 

Part of the notion of pluggable consensus is to enable users to make informed tradeoffs in security and performance guarantees for different deployment environments.

 

The TSC also has a governance role on licensing. From this thread, specific patent concerns have been raised. I request that Hyperledger’s legal counsel provide some guidance to the TSC on that risk.

 

Regards,

Dan

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Brian Behlendorf via hyperledger-tsc
Sent: Wednesday, June 28, 2017 09:55
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

I am a bit more leery of viewing academic peer-review as a gating function for new projects joining Hyperledger.  It is completely appropriate IMHO for the Fabric maintainer community to state that they will only include consensus plug-ins in the Fabric install that meet some criteria for quality, and peer-reviewed consensus mechanisms may be that.  But not all possible consensus plug-ins need to be included within the Fabric project.  We could accept a new Hyperledger project to build a new/different consensus plug-in, with a different set of maintainers, who set their own standards for the proven-ness of the algorithm.  That might be the right thing for a Hashgraph plugin, especially if there are some edge-case patent concerns. 

Brian

On 06/27/2017 11:03 AM, Hart Montgomery via hyperledger-tsc wrote:

Hi Martin,

 

Is there a reason this hasn’t been submitted to a conference for peer review?  I’d highly recommend doing so—you’ll have a lot more credibility with regards to people believing the protocol if you can get it published in some conference proceedings.  If you need help, I bet there are people on this list who would be happy to point you in the right direction.

 

As it is, I’d be wary of accepting any new crypto or consensus into Hyperledger that hasn’t been published in a reputable conference or heavily reviewed and documented by outsiders.  It sets the precedent that the TSC or other members of the community would have to be academic-style crypto reviewers in order to properly assess new contributions.  While some of us may be, it puts an impossible burden on those that are not, and the appropriate place for new research to be evaluated (which new crypto or consensus is) is an academic conference anyways.  Additionally, to be truly safe, lots of time and review is needed for protocols that will be critical to systems.  For instance, the SHA-3 competition and review process took five years.  While we don’t need that much time for new consensus algorithms, I think this is still an area where it is much better to be safe than sorry.

 

Thanks for your time, and have a great day.

 

Hart

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Martin Arrivets via hyperledger-tsc
Sent: Tuesday, June 27, 2017 9:55 AM
To: Christian Cachin <cca@...>
Cc: Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...>; Giacomo Puri Purini <giacomo@...>
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

Thanks for the links,

 

Indeed the problem cannot be solved with a deterministic protocol

 

But there are ways to circumvent the FLP theorem by sacrificing determinism

cf Rabin, M.O. (1983) ‘Randomized Byzantine generals’ for example.

 

It is possible for a nondeterministic system to achieve consensus with probability

one.

 

That is what the Hashgraph does and that is what I meant when I wrote that participants 

will "eventually" (with probability one) know the exact location of a transaction in history.

 

The Hasgraph algorithm introduces periodic 'coin-rounds' where witnesses vote randomly. This

defends against attackers that control the internet and want to partition the network.

 

Martin

-----Original message-----
From: Christian Cachin
Sent: Tuesday, June 27 2017, 6:09 pm
To: Martin Arrivets
Cc: Martin Arrivets via hyperledger-tsc; David Huseby; Christopher Ferris; Giacomo Puri Purini
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform


Martin,
 
I've understood that there exists a white paper, yes.
 
But perhaps you should be aware that mathematically, in a "fully asynchronous
system" as you describe below, with < 1/3 faulty nodes (that crash or
act maliciously), or even with just one node that may crash, the "consensus
problem" cannot be solved with a deterministic protocol.
 
This is a famous result in distributed systems:
"Impossibility of Distributed Consensus with One Faulty Process" usually 
just called "FLP impossibility".
 
See more:
  https://en.wikipedia.org/wiki/Consensus_(computer_science)
  https://en.wikipedia.org/wiki/Byzantine_fault_tolerance
or a textbook I co-authored - www.distributedprogramming.net - although the
FLP result is not explained in there.
 
What you describe seems equivalent to this well-understood consensus problem.
 
In contrast to hashgraph, PBFT has been peer-reviewed and widely understood 
to achieve consensus in the appropriate model (eventual synchrony, not
asynchrony).
 
Regards,
 
      Christian
 
 
 
On 27 Jun 2017 12:03:06 +0000, Martin Arrivets <martin@...> wrote:
> Hi Christian,
> 
> The system achieves consensus in the sense that a participant will
> eventually know the exact location of a transaction in history and have
> a mathematical guarantee of finality (that this is the consensus order).
> The knowledge is not probabilistic but a mathematical guarantee.
> 
> The proofs in the whitepaper
> <http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf>; make the
> standard assumptions:
> 
> More than 2/3 of the computers are "honest", which means they follow the
> algorithm correctly and are available. Although an honest computer may
> go down for a while (and stop communicating) as long as they eventually
> come back up.
> 
> Nodes can collude and are allowed to mostly control the internet . Their
> only limit on control on the internet is that if Alice repeatedly sends
> Bob messages they must eventually allow Bob to receive one.
> 
> The proofs are for a fully asynchronous system. There is no assumption
> that an honest node will always respond within a certain interval. If
> all the nodes go to sleep, then progress continues as soon as they come
> back up. In normal conditions with a small number of nodes, consensus
> can happen in less than a second.
> 
> I am not aware of any third-party reviews of the whitepaper. 
> 
> The concepts are very similar to other voting-based BFT algorithms
> except the voting is "virtual". If the security of those systems (like
> PBFT or Tendermint...) has been vetted by the schemes you mention then
> perhaps they could be applied to Hashgraph as well.
> 
> Hope this answers you questions.
> 
> Regards,
> Martin
> -----Original message-----
> From: Christian Cachin
> Sent: Tuesday, June 27 2017, 11:43 am
> To: Martin Arrivets via hyperledger-tsc
> Cc: Martin Arrivets; David Huseby; Christopher Ferris; Giacomo Puri
> Purini Subject: Re: [Hyperledger Project TSC] Project Proposal:
> Consensus Platform
> 
> 
> Martin,
> 
> Can you point to any independent analysis of the properties achieved by 
> Swirlds consensus?  In which sense does it reach "consensus"?  Are there 
> any peer-reviewed publications or other third-party endorsements
> available?
> 
> In analogy with cryptography, where such issues have been discussed at 
> large, and over many decades, the security of a system should be based 
> on well-established and widely agreed-on schemes.
> 
> (FYI - I'm a cryptographer and also working on consensus protocols...)
> 
> Regards,
> 
>     Christian
> 
> 
> --- 
> Christian Cachin                           email: cca@...
> <mailto:cca@...> IBM Research -
> Zurich                           tel: +41-44-724-8989 Säumerstrasse 4
> CH-8803 Rüschlikon, Switzerland       http://www.zurich.ibm.com/˜cca
> <http://www.zurich.ibm.com/˜cca>; 
> 
> 
> 




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

 

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


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


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

hyperledger-tsc mailing list

hyperledger-tsc@...

https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


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

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




--
Best wishes!

Baohua Yang


Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Silas Davis
 

Sadly it is - but in my IANAL understanding - not in Europe where software patents of this form are not enforceable. MosaicNetworks are currently London based - still just about in Europe...

FWIW I did discuss (i.e. bemoan) the patents to Christian Hasker once, Hedera's CMO. His explanation was that it was designed to avoid fragmentation of the public network they want to launch. This didn't make much sense to me.

On Wed, 21 Aug 2019 at 17:14, Shawn Amundson <amundson@...> wrote:
On Wed, Aug 21, 2019 at 11:12 AM Shawn Amundson via Lists.Hyperledger.Org <amundson=bitwise.io@...> wrote:
I'm a big fan of the idea of top-level consensus projects. We've


Sorry - finishing the thought there - We've considered Hashgraph in the past but were under the impression that it was patent encumbered.
 
As a community, we've already had many conversations about consolidating what we already have across the existing projects. The effort to maintain consensus engines is exceptionally high, which makes them good candidates for sharing across the DLT projects. The previous conversations have focused on what we would need to do in order to have a universal consensus API across projects.

Fundamentally what we need out of that universal consensus API:

1. A library which can work with both Rust and Go
2. DLT agnostic, so all the DLTs can adopt it. This means it does not define any network protocols, should not define it's own system processes, etc.
2a. It should not define a networking layer (it should rely on the DLT to provide it)

We've started down this path within our Sawtooth work. The initial iteration can be seen in Sawtooth's existing consensus engine design, and we are working on a library-based iteration of the approach to make it more easily consumable outside of Sawtooth.

I'd like to see a commitment in this project to support all Hyperledger DLTs. That support can come in the form of being agnostic (doing the Fabric/Burrow integration in Fabric/Burrow and keeping Babble agnostic so it can be adopted by other projects), which is the approach taken by Ursa and Transact.

Eventually, maybe we end up with a lot of top-level consensus projects:

- Consensus API - defines the APIs which consensus engines implement and the DLT-facing Rust and Go APIs for using them
- Babble - Hashgraph
- PBFT - derived from Sawtooth's PBFT implementation
- PoET - derived from Sawtooth's PoET implementation
- Raft - derived from Fabric or Sawtooth's Raft implementations
- other projects implementing the Consensus API

-Shawn


On Wed, Aug 21, 2019 at 9:11 AM Silas Davis via Lists.Hyperledger.Org <silas=monax.io@...> wrote:
Time flies...

If Martin is still interested, I would support this project. I think it is quite in-line with the recent spate of cross-cutting project types, whilst still being complete as an implementation - it's a fully executable thing not just library. It occupies a similar cutout to that of Tendermint.

Silas

On Tue, 20 Aug 2019 at 05:57, Stefan Buhrmester <buhrmi@...> wrote:
Two years later....

On Tue, Jul 4, 2017 at 4:18 PM, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thanks for the information Brian,

Before we go on to take care of the patent issues and changing the name we need to establish if it actually makes sense to incorporate our code base with Hyperledger.

On our side, we will need to show that the algorithm performs well compared to other comparable systems and that it has other qualitative advantages.

It also seems that there is no consensus among the TSC as to whether this type of project is a fit architecturally for Hyperledger.

So it would be good to keep the discussion going and to put the proposal on hold until these points are addressed.

Best,
Martin


On 4 Jul 2017, at 04:09, Brian Behlendorf <bbehlendorf@...> wrote:

I want to follow up and state that Leemon Baird (Hashgraph author) had reached out to me, and I asked him to confirm that this interpretation matches his understanding.  It sounds like they have multiple patents awarded and others filed and awaiting award relating to hashgraph, and we'd need either a clear grant to those patents as applied to Hyperledger code (essentially a DCO) from them or a statement that indeed their patents do not read upon Babble for the reasons you gave, before giving the OK here for babble to be contributed.  Otherwise you're asking a lot of people to take on a difficult-to-quantify risk, and patent issues are much more challenging to fix later than say copyright or trademark issues. 

Regarding the name - it has to be a name that isn't trademarked or otherwise owned/managed by another company, as that could lead to confusion.  Sometimes it's best to come up with a new name as it enters, such as happened with Fabric, Sawtooth, Indy, and Burrow.  I take it babble.io would still be a company & trademark you'd want to keep.

Brian

On 06/28/2017 11:14 AM, Martin Arrivets wrote:
Hello Brian,

Here is a link to a document describing the IP landscape around the issue: 

We suggest the name Babble.

Hope this helps,

Regards,
Martin


-----Original message-----
From: Brian Behlendorf via hyperledger-tsc
Sent: Wednesday, June 28 2017, 5:30 pm
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

I can ask our counsel once we know more about what's being proposed, and how that relates to the patent landscape.  Can someone involved in the proposal provide a write-up (which should be part of the repository, eventually) that details the known IP in this field, and how it relates to the project?  Just forwarding this thread probably isn't enough to go on.

Also, can we call this something more creative than just "Consensus Platform"?

Brian

On 06/28/2017 09:22 AM, Middleton, Dan via hyperledger-tsc wrote:

I don’t view journal publication as a gate on adding a project. It can be a factor in assessing technical merit but not the only factor. I’ll be looking whether there is sufficient detail/formality in the proposal and its references to assess that technical merit - regardless of academic status.

 

Part of the notion of pluggable consensus is to enable users to make informed tradeoffs in security and performance guarantees for different deployment environments.

 

The TSC also has a governance role on licensing. From this thread, specific patent concerns have been raised. I request that Hyperledger’s legal counsel provide some guidance to the TSC on that risk.

 

Regards,

Dan

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Brian Behlendorf via hyperledger-tsc
Sent: Wednesday, June 28, 2017 09:55
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

I am a bit more leery of viewing academic peer-review as a gating function for new projects joining Hyperledger.  It is completely appropriate IMHO for the Fabric maintainer community to state that they will only include consensus plug-ins in the Fabric install that meet some criteria for quality, and peer-reviewed consensus mechanisms may be that.  But not all possible consensus plug-ins need to be included within the Fabric project.  We could accept a new Hyperledger project to build a new/different consensus plug-in, with a different set of maintainers, who set their own standards for the proven-ness of the algorithm.  That might be the right thing for a Hashgraph plugin, especially if there are some edge-case patent concerns. 

Brian

On 06/27/2017 11:03 AM, Hart Montgomery via hyperledger-tsc wrote:

Hi Martin,

 

Is there a reason this hasn’t been submitted to a conference for peer review?  I’d highly recommend doing so—you’ll have a lot more credibility with regards to people believing the protocol if you can get it published in some conference proceedings.  If you need help, I bet there are people on this list who would be happy to point you in the right direction.

 

As it is, I’d be wary of accepting any new crypto or consensus into Hyperledger that hasn’t been published in a reputable conference or heavily reviewed and documented by outsiders.  It sets the precedent that the TSC or other members of the community would have to be academic-style crypto reviewers in order to properly assess new contributions.  While some of us may be, it puts an impossible burden on those that are not, and the appropriate place for new research to be evaluated (which new crypto or consensus is) is an academic conference anyways.  Additionally, to be truly safe, lots of time and review is needed for protocols that will be critical to systems.  For instance, the SHA-3 competition and review process took five years.  While we don’t need that much time for new consensus algorithms, I think this is still an area where it is much better to be safe than sorry.

 

Thanks for your time, and have a great day.

 

Hart

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Martin Arrivets via hyperledger-tsc
Sent: Tuesday, June 27, 2017 9:55 AM
To: Christian Cachin <cca@...>
Cc: Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...>; Giacomo Puri Purini <giacomo@...>
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

Thanks for the links,

 

Indeed the problem cannot be solved with a deterministic protocol

 

But there are ways to circumvent the FLP theorem by sacrificing determinism

cf Rabin, M.O. (1983) ‘Randomized Byzantine generals’ for example.

 

It is possible for a nondeterministic system to achieve consensus with probability

one.

 

That is what the Hashgraph does and that is what I meant when I wrote that participants 

will "eventually" (with probability one) know the exact location of a transaction in history.

 

The Hasgraph algorithm introduces periodic 'coin-rounds' where witnesses vote randomly. This

defends against attackers that control the internet and want to partition the network.

 

Martin

-----Original message-----
From: Christian Cachin
Sent: Tuesday, June 27 2017, 6:09 pm
To: Martin Arrivets
Cc: Martin Arrivets via hyperledger-tsc; David Huseby; Christopher Ferris; Giacomo Puri Purini
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform


Martin,
 
I've understood that there exists a white paper, yes.
 
But perhaps you should be aware that mathematically, in a "fully asynchronous
system" as you describe below, with < 1/3 faulty nodes (that crash or
act maliciously), or even with just one node that may crash, the "consensus
problem" cannot be solved with a deterministic protocol.
 
This is a famous result in distributed systems:
"Impossibility of Distributed Consensus with One Faulty Process" usually 
just called "FLP impossibility".
 
See more:
  https://en.wikipedia.org/wiki/Consensus_(computer_science)
  https://en.wikipedia.org/wiki/Byzantine_fault_tolerance
or a textbook I co-authored - www.distributedprogramming.net - although the
FLP result is not explained in there.
 
What you describe seems equivalent to this well-understood consensus problem.
 
In contrast to hashgraph, PBFT has been peer-reviewed and widely understood 
to achieve consensus in the appropriate model (eventual synchrony, not
asynchrony).
 
Regards,
 
      Christian
 
 
 
On 27 Jun 2017 12:03:06 +0000, Martin Arrivets <martin@...> wrote:
> Hi Christian,
> 
> The system achieves consensus in the sense that a participant will
> eventually know the exact location of a transaction in history and have
> a mathematical guarantee of finality (that this is the consensus order).
> The knowledge is not probabilistic but a mathematical guarantee.
> 
> The proofs in the whitepaper
> <http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf>; make the
> standard assumptions:
> 
> More than 2/3 of the computers are "honest", which means they follow the
> algorithm correctly and are available. Although an honest computer may
> go down for a while (and stop communicating) as long as they eventually
> come back up.
> 
> Nodes can collude and are allowed to mostly control the internet . Their
> only limit on control on the internet is that if Alice repeatedly sends
> Bob messages they must eventually allow Bob to receive one.
> 
> The proofs are for a fully asynchronous system. There is no assumption
> that an honest node will always respond within a certain interval. If
> all the nodes go to sleep, then progress continues as soon as they come
> back up. In normal conditions with a small number of nodes, consensus
> can happen in less than a second.
> 
> I am not aware of any third-party reviews of the whitepaper. 
> 
> The concepts are very similar to other voting-based BFT algorithms
> except the voting is "virtual". If the security of those systems (like
> PBFT or Tendermint...) has been vetted by the schemes you mention then
> perhaps they could be applied to Hashgraph as well.
> 
> Hope this answers you questions.
> 
> Regards,
> Martin
> -----Original message-----
> From: Christian Cachin
> Sent: Tuesday, June 27 2017, 11:43 am
> To: Martin Arrivets via hyperledger-tsc
> Cc: Martin Arrivets; David Huseby; Christopher Ferris; Giacomo Puri
> Purini Subject: Re: [Hyperledger Project TSC] Project Proposal:
> Consensus Platform
> 
> 
> Martin,
> 
> Can you point to any independent analysis of the properties achieved by 
> Swirlds consensus?  In which sense does it reach "consensus"?  Are there 
> any peer-reviewed publications or other third-party endorsements
> available?
> 
> In analogy with cryptography, where such issues have been discussed at 
> large, and over many decades, the security of a system should be based 
> on well-established and widely agreed-on schemes.
> 
> (FYI - I'm a cryptographer and also working on consensus protocols...)
> 
> Regards,
> 
>     Christian
> 
> 
> --- 
> Christian Cachin                           email: cca@...
> <mailto:cca@...> IBM Research -
> Zurich                           tel: +41-44-724-8989 Säumerstrasse 4
> CH-8803 Rüschlikon, Switzerland       http://www.zurich.ibm.com/˜cca
> <http://www.zurich.ibm.com/˜cca>; 
> 
> 
> 




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

 

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


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


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

hyperledger-tsc mailing list

hyperledger-tsc@...

https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


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

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



Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Shawn Amundson
 

On Wed, Aug 21, 2019 at 11:12 AM Shawn Amundson via Lists.Hyperledger.Org <amundson=bitwise.io@...> wrote:
I'm a big fan of the idea of top-level consensus projects. We've


Sorry - finishing the thought there - We've considered Hashgraph in the past but were under the impression that it was patent encumbered.
 
As a community, we've already had many conversations about consolidating what we already have across the existing projects. The effort to maintain consensus engines is exceptionally high, which makes them good candidates for sharing across the DLT projects. The previous conversations have focused on what we would need to do in order to have a universal consensus API across projects.

Fundamentally what we need out of that universal consensus API:

1. A library which can work with both Rust and Go
2. DLT agnostic, so all the DLTs can adopt it. This means it does not define any network protocols, should not define it's own system processes, etc.
2a. It should not define a networking layer (it should rely on the DLT to provide it)

We've started down this path within our Sawtooth work. The initial iteration can be seen in Sawtooth's existing consensus engine design, and we are working on a library-based iteration of the approach to make it more easily consumable outside of Sawtooth.

I'd like to see a commitment in this project to support all Hyperledger DLTs. That support can come in the form of being agnostic (doing the Fabric/Burrow integration in Fabric/Burrow and keeping Babble agnostic so it can be adopted by other projects), which is the approach taken by Ursa and Transact.

Eventually, maybe we end up with a lot of top-level consensus projects:

- Consensus API - defines the APIs which consensus engines implement and the DLT-facing Rust and Go APIs for using them
- Babble - Hashgraph
- PBFT - derived from Sawtooth's PBFT implementation
- PoET - derived from Sawtooth's PoET implementation
- Raft - derived from Fabric or Sawtooth's Raft implementations
- other projects implementing the Consensus API

-Shawn


On Wed, Aug 21, 2019 at 9:11 AM Silas Davis via Lists.Hyperledger.Org <silas=monax.io@...> wrote:
Time flies...

If Martin is still interested, I would support this project. I think it is quite in-line with the recent spate of cross-cutting project types, whilst still being complete as an implementation - it's a fully executable thing not just library. It occupies a similar cutout to that of Tendermint.

Silas

On Tue, 20 Aug 2019 at 05:57, Stefan Buhrmester <buhrmi@...> wrote:
Two years later....

On Tue, Jul 4, 2017 at 4:18 PM, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thanks for the information Brian,

Before we go on to take care of the patent issues and changing the name we need to establish if it actually makes sense to incorporate our code base with Hyperledger.

On our side, we will need to show that the algorithm performs well compared to other comparable systems and that it has other qualitative advantages.

It also seems that there is no consensus among the TSC as to whether this type of project is a fit architecturally for Hyperledger.

So it would be good to keep the discussion going and to put the proposal on hold until these points are addressed.

Best,
Martin


On 4 Jul 2017, at 04:09, Brian Behlendorf <bbehlendorf@...> wrote:

I want to follow up and state that Leemon Baird (Hashgraph author) had reached out to me, and I asked him to confirm that this interpretation matches his understanding.  It sounds like they have multiple patents awarded and others filed and awaiting award relating to hashgraph, and we'd need either a clear grant to those patents as applied to Hyperledger code (essentially a DCO) from them or a statement that indeed their patents do not read upon Babble for the reasons you gave, before giving the OK here for babble to be contributed.  Otherwise you're asking a lot of people to take on a difficult-to-quantify risk, and patent issues are much more challenging to fix later than say copyright or trademark issues. 

Regarding the name - it has to be a name that isn't trademarked or otherwise owned/managed by another company, as that could lead to confusion.  Sometimes it's best to come up with a new name as it enters, such as happened with Fabric, Sawtooth, Indy, and Burrow.  I take it babble.io would still be a company & trademark you'd want to keep.

Brian

On 06/28/2017 11:14 AM, Martin Arrivets wrote:
Hello Brian,

Here is a link to a document describing the IP landscape around the issue: 

We suggest the name Babble.

Hope this helps,

Regards,
Martin


-----Original message-----
From: Brian Behlendorf via hyperledger-tsc
Sent: Wednesday, June 28 2017, 5:30 pm
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

I can ask our counsel once we know more about what's being proposed, and how that relates to the patent landscape.  Can someone involved in the proposal provide a write-up (which should be part of the repository, eventually) that details the known IP in this field, and how it relates to the project?  Just forwarding this thread probably isn't enough to go on.

Also, can we call this something more creative than just "Consensus Platform"?

Brian

On 06/28/2017 09:22 AM, Middleton, Dan via hyperledger-tsc wrote:

I don’t view journal publication as a gate on adding a project. It can be a factor in assessing technical merit but not the only factor. I’ll be looking whether there is sufficient detail/formality in the proposal and its references to assess that technical merit - regardless of academic status.

 

Part of the notion of pluggable consensus is to enable users to make informed tradeoffs in security and performance guarantees for different deployment environments.

 

The TSC also has a governance role on licensing. From this thread, specific patent concerns have been raised. I request that Hyperledger’s legal counsel provide some guidance to the TSC on that risk.

 

Regards,

Dan

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Brian Behlendorf via hyperledger-tsc
Sent: Wednesday, June 28, 2017 09:55
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

I am a bit more leery of viewing academic peer-review as a gating function for new projects joining Hyperledger.  It is completely appropriate IMHO for the Fabric maintainer community to state that they will only include consensus plug-ins in the Fabric install that meet some criteria for quality, and peer-reviewed consensus mechanisms may be that.  But not all possible consensus plug-ins need to be included within the Fabric project.  We could accept a new Hyperledger project to build a new/different consensus plug-in, with a different set of maintainers, who set their own standards for the proven-ness of the algorithm.  That might be the right thing for a Hashgraph plugin, especially if there are some edge-case patent concerns. 

Brian

On 06/27/2017 11:03 AM, Hart Montgomery via hyperledger-tsc wrote:

Hi Martin,

 

Is there a reason this hasn’t been submitted to a conference for peer review?  I’d highly recommend doing so—you’ll have a lot more credibility with regards to people believing the protocol if you can get it published in some conference proceedings.  If you need help, I bet there are people on this list who would be happy to point you in the right direction.

 

As it is, I’d be wary of accepting any new crypto or consensus into Hyperledger that hasn’t been published in a reputable conference or heavily reviewed and documented by outsiders.  It sets the precedent that the TSC or other members of the community would have to be academic-style crypto reviewers in order to properly assess new contributions.  While some of us may be, it puts an impossible burden on those that are not, and the appropriate place for new research to be evaluated (which new crypto or consensus is) is an academic conference anyways.  Additionally, to be truly safe, lots of time and review is needed for protocols that will be critical to systems.  For instance, the SHA-3 competition and review process took five years.  While we don’t need that much time for new consensus algorithms, I think this is still an area where it is much better to be safe than sorry.

 

Thanks for your time, and have a great day.

 

Hart

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Martin Arrivets via hyperledger-tsc
Sent: Tuesday, June 27, 2017 9:55 AM
To: Christian Cachin <cca@...>
Cc: Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...>; Giacomo Puri Purini <giacomo@...>
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

Thanks for the links,

 

Indeed the problem cannot be solved with a deterministic protocol

 

But there are ways to circumvent the FLP theorem by sacrificing determinism

cf Rabin, M.O. (1983) ‘Randomized Byzantine generals’ for example.

 

It is possible for a nondeterministic system to achieve consensus with probability

one.

 

That is what the Hashgraph does and that is what I meant when I wrote that participants 

will "eventually" (with probability one) know the exact location of a transaction in history.

 

The Hasgraph algorithm introduces periodic 'coin-rounds' where witnesses vote randomly. This

defends against attackers that control the internet and want to partition the network.

 

Martin

-----Original message-----
From: Christian Cachin
Sent: Tuesday, June 27 2017, 6:09 pm
To: Martin Arrivets
Cc: Martin Arrivets via hyperledger-tsc; David Huseby; Christopher Ferris; Giacomo Puri Purini
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform


Martin,
 
I've understood that there exists a white paper, yes.
 
But perhaps you should be aware that mathematically, in a "fully asynchronous
system" as you describe below, with < 1/3 faulty nodes (that crash or
act maliciously), or even with just one node that may crash, the "consensus
problem" cannot be solved with a deterministic protocol.
 
This is a famous result in distributed systems:
"Impossibility of Distributed Consensus with One Faulty Process" usually 
just called "FLP impossibility".
 
See more:
  https://en.wikipedia.org/wiki/Consensus_(computer_science)
  https://en.wikipedia.org/wiki/Byzantine_fault_tolerance
or a textbook I co-authored - www.distributedprogramming.net - although the
FLP result is not explained in there.
 
What you describe seems equivalent to this well-understood consensus problem.
 
In contrast to hashgraph, PBFT has been peer-reviewed and widely understood 
to achieve consensus in the appropriate model (eventual synchrony, not
asynchrony).
 
Regards,
 
      Christian
 
 
 
On 27 Jun 2017 12:03:06 +0000, Martin Arrivets <martin@...> wrote:
> Hi Christian,
> 
> The system achieves consensus in the sense that a participant will
> eventually know the exact location of a transaction in history and have
> a mathematical guarantee of finality (that this is the consensus order).
> The knowledge is not probabilistic but a mathematical guarantee.
> 
> The proofs in the whitepaper
> <http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf>; make the
> standard assumptions:
> 
> More than 2/3 of the computers are "honest", which means they follow the
> algorithm correctly and are available. Although an honest computer may
> go down for a while (and stop communicating) as long as they eventually
> come back up.
> 
> Nodes can collude and are allowed to mostly control the internet . Their
> only limit on control on the internet is that if Alice repeatedly sends
> Bob messages they must eventually allow Bob to receive one.
> 
> The proofs are for a fully asynchronous system. There is no assumption
> that an honest node will always respond within a certain interval. If
> all the nodes go to sleep, then progress continues as soon as they come
> back up. In normal conditions with a small number of nodes, consensus
> can happen in less than a second.
> 
> I am not aware of any third-party reviews of the whitepaper. 
> 
> The concepts are very similar to other voting-based BFT algorithms
> except the voting is "virtual". If the security of those systems (like
> PBFT or Tendermint...) has been vetted by the schemes you mention then
> perhaps they could be applied to Hashgraph as well.
> 
> Hope this answers you questions.
> 
> Regards,
> Martin
> -----Original message-----
> From: Christian Cachin
> Sent: Tuesday, June 27 2017, 11:43 am
> To: Martin Arrivets via hyperledger-tsc
> Cc: Martin Arrivets; David Huseby; Christopher Ferris; Giacomo Puri
> Purini Subject: Re: [Hyperledger Project TSC] Project Proposal:
> Consensus Platform
> 
> 
> Martin,
> 
> Can you point to any independent analysis of the properties achieved by 
> Swirlds consensus?  In which sense does it reach "consensus"?  Are there 
> any peer-reviewed publications or other third-party endorsements
> available?
> 
> In analogy with cryptography, where such issues have been discussed at 
> large, and over many decades, the security of a system should be based 
> on well-established and widely agreed-on schemes.
> 
> (FYI - I'm a cryptographer and also working on consensus protocols...)
> 
> Regards,
> 
>     Christian
> 
> 
> --- 
> Christian Cachin                           email: cca@...
> <mailto:cca@...> IBM Research -
> Zurich                           tel: +41-44-724-8989 Säumerstrasse 4
> CH-8803 Rüschlikon, Switzerland       http://www.zurich.ibm.com/˜cca
> <http://www.zurich.ibm.com/˜cca>; 
> 
> 
> 




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

 

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


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


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

hyperledger-tsc mailing list

hyperledger-tsc@...

https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


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

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



Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Shawn Amundson
 

I'm a big fan of the idea of top-level consensus projects. We've

As a community, we've already had many conversations about consolidating what we already have across the existing projects. The effort to maintain consensus engines is exceptionally high, which makes them good candidates for sharing across the DLT projects. The previous conversations have focused on what we would need to do in order to have a universal consensus API across projects.

Fundamentally what we need out of that universal consensus API:

1. A library which can work with both Rust and Go
2. DLT agnostic, so all the DLTs can adopt it. This means it does not define any network protocols, should not define it's own system processes, etc.
2a. It should not define a networking layer (it should rely on the DLT to provide it)

We've started down this path within our Sawtooth work. The initial iteration can be seen in Sawtooth's existing consensus engine design, and we are working on a library-based iteration of the approach to make it more easily consumable outside of Sawtooth.

I'd like to see a commitment in this project to support all Hyperledger DLTs. That support can come in the form of being agnostic (doing the Fabric/Burrow integration in Fabric/Burrow and keeping Babble agnostic so it can be adopted by other projects), which is the approach taken by Ursa and Transact.

Eventually, maybe we end up with a lot of top-level consensus projects:

- Consensus API - defines the APIs which consensus engines implement and the DLT-facing Rust and Go APIs for using them
- Babble - Hashgraph
- PBFT - derived from Sawtooth's PBFT implementation
- PoET - derived from Sawtooth's PoET implementation
- Raft - derived from Fabric or Sawtooth's Raft implementations
- other projects implementing the Consensus API

-Shawn


On Wed, Aug 21, 2019 at 9:11 AM Silas Davis via Lists.Hyperledger.Org <silas=monax.io@...> wrote:
Time flies...

If Martin is still interested, I would support this project. I think it is quite in-line with the recent spate of cross-cutting project types, whilst still being complete as an implementation - it's a fully executable thing not just library. It occupies a similar cutout to that of Tendermint.

Silas

On Tue, 20 Aug 2019 at 05:57, Stefan Buhrmester <buhrmi@...> wrote:
Two years later....

On Tue, Jul 4, 2017 at 4:18 PM, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thanks for the information Brian,

Before we go on to take care of the patent issues and changing the name we need to establish if it actually makes sense to incorporate our code base with Hyperledger.

On our side, we will need to show that the algorithm performs well compared to other comparable systems and that it has other qualitative advantages.

It also seems that there is no consensus among the TSC as to whether this type of project is a fit architecturally for Hyperledger.

So it would be good to keep the discussion going and to put the proposal on hold until these points are addressed.

Best,
Martin


On 4 Jul 2017, at 04:09, Brian Behlendorf <bbehlendorf@...> wrote:

I want to follow up and state that Leemon Baird (Hashgraph author) had reached out to me, and I asked him to confirm that this interpretation matches his understanding.  It sounds like they have multiple patents awarded and others filed and awaiting award relating to hashgraph, and we'd need either a clear grant to those patents as applied to Hyperledger code (essentially a DCO) from them or a statement that indeed their patents do not read upon Babble for the reasons you gave, before giving the OK here for babble to be contributed.  Otherwise you're asking a lot of people to take on a difficult-to-quantify risk, and patent issues are much more challenging to fix later than say copyright or trademark issues. 

Regarding the name - it has to be a name that isn't trademarked or otherwise owned/managed by another company, as that could lead to confusion.  Sometimes it's best to come up with a new name as it enters, such as happened with Fabric, Sawtooth, Indy, and Burrow.  I take it babble.io would still be a company & trademark you'd want to keep.

Brian

On 06/28/2017 11:14 AM, Martin Arrivets wrote:
Hello Brian,

Here is a link to a document describing the IP landscape around the issue: 

We suggest the name Babble.

Hope this helps,

Regards,
Martin


-----Original message-----
From: Brian Behlendorf via hyperledger-tsc
Sent: Wednesday, June 28 2017, 5:30 pm
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

I can ask our counsel once we know more about what's being proposed, and how that relates to the patent landscape.  Can someone involved in the proposal provide a write-up (which should be part of the repository, eventually) that details the known IP in this field, and how it relates to the project?  Just forwarding this thread probably isn't enough to go on.

Also, can we call this something more creative than just "Consensus Platform"?

Brian

On 06/28/2017 09:22 AM, Middleton, Dan via hyperledger-tsc wrote:

I don’t view journal publication as a gate on adding a project. It can be a factor in assessing technical merit but not the only factor. I’ll be looking whether there is sufficient detail/formality in the proposal and its references to assess that technical merit - regardless of academic status.

 

Part of the notion of pluggable consensus is to enable users to make informed tradeoffs in security and performance guarantees for different deployment environments.

 

The TSC also has a governance role on licensing. From this thread, specific patent concerns have been raised. I request that Hyperledger’s legal counsel provide some guidance to the TSC on that risk.

 

Regards,

Dan

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Brian Behlendorf via hyperledger-tsc
Sent: Wednesday, June 28, 2017 09:55
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

I am a bit more leery of viewing academic peer-review as a gating function for new projects joining Hyperledger.  It is completely appropriate IMHO for the Fabric maintainer community to state that they will only include consensus plug-ins in the Fabric install that meet some criteria for quality, and peer-reviewed consensus mechanisms may be that.  But not all possible consensus plug-ins need to be included within the Fabric project.  We could accept a new Hyperledger project to build a new/different consensus plug-in, with a different set of maintainers, who set their own standards for the proven-ness of the algorithm.  That might be the right thing for a Hashgraph plugin, especially if there are some edge-case patent concerns. 

Brian

On 06/27/2017 11:03 AM, Hart Montgomery via hyperledger-tsc wrote:

Hi Martin,

 

Is there a reason this hasn’t been submitted to a conference for peer review?  I’d highly recommend doing so—you’ll have a lot more credibility with regards to people believing the protocol if you can get it published in some conference proceedings.  If you need help, I bet there are people on this list who would be happy to point you in the right direction.

 

As it is, I’d be wary of accepting any new crypto or consensus into Hyperledger that hasn’t been published in a reputable conference or heavily reviewed and documented by outsiders.  It sets the precedent that the TSC or other members of the community would have to be academic-style crypto reviewers in order to properly assess new contributions.  While some of us may be, it puts an impossible burden on those that are not, and the appropriate place for new research to be evaluated (which new crypto or consensus is) is an academic conference anyways.  Additionally, to be truly safe, lots of time and review is needed for protocols that will be critical to systems.  For instance, the SHA-3 competition and review process took five years.  While we don’t need that much time for new consensus algorithms, I think this is still an area where it is much better to be safe than sorry.

 

Thanks for your time, and have a great day.

 

Hart

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Martin Arrivets via hyperledger-tsc
Sent: Tuesday, June 27, 2017 9:55 AM
To: Christian Cachin <cca@...>
Cc: Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...>; Giacomo Puri Purini <giacomo@...>
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

Thanks for the links,

 

Indeed the problem cannot be solved with a deterministic protocol

 

But there are ways to circumvent the FLP theorem by sacrificing determinism

cf Rabin, M.O. (1983) ‘Randomized Byzantine generals’ for example.

 

It is possible for a nondeterministic system to achieve consensus with probability

one.

 

That is what the Hashgraph does and that is what I meant when I wrote that participants 

will "eventually" (with probability one) know the exact location of a transaction in history.

 

The Hasgraph algorithm introduces periodic 'coin-rounds' where witnesses vote randomly. This

defends against attackers that control the internet and want to partition the network.

 

Martin

-----Original message-----
From: Christian Cachin
Sent: Tuesday, June 27 2017, 6:09 pm
To: Martin Arrivets
Cc: Martin Arrivets via hyperledger-tsc; David Huseby; Christopher Ferris; Giacomo Puri Purini
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform


Martin,
 
I've understood that there exists a white paper, yes.
 
But perhaps you should be aware that mathematically, in a "fully asynchronous
system" as you describe below, with < 1/3 faulty nodes (that crash or
act maliciously), or even with just one node that may crash, the "consensus
problem" cannot be solved with a deterministic protocol.
 
This is a famous result in distributed systems:
"Impossibility of Distributed Consensus with One Faulty Process" usually 
just called "FLP impossibility".
 
See more:
  https://en.wikipedia.org/wiki/Consensus_(computer_science)
  https://en.wikipedia.org/wiki/Byzantine_fault_tolerance
or a textbook I co-authored - www.distributedprogramming.net - although the
FLP result is not explained in there.
 
What you describe seems equivalent to this well-understood consensus problem.
 
In contrast to hashgraph, PBFT has been peer-reviewed and widely understood 
to achieve consensus in the appropriate model (eventual synchrony, not
asynchrony).
 
Regards,
 
      Christian
 
 
 
On 27 Jun 2017 12:03:06 +0000, Martin Arrivets <martin@...> wrote:
> Hi Christian,
> 
> The system achieves consensus in the sense that a participant will
> eventually know the exact location of a transaction in history and have
> a mathematical guarantee of finality (that this is the consensus order).
> The knowledge is not probabilistic but a mathematical guarantee.
> 
> The proofs in the whitepaper
> <http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf>; make the
> standard assumptions:
> 
> More than 2/3 of the computers are "honest", which means they follow the
> algorithm correctly and are available. Although an honest computer may
> go down for a while (and stop communicating) as long as they eventually
> come back up.
> 
> Nodes can collude and are allowed to mostly control the internet . Their
> only limit on control on the internet is that if Alice repeatedly sends
> Bob messages they must eventually allow Bob to receive one.
> 
> The proofs are for a fully asynchronous system. There is no assumption
> that an honest node will always respond within a certain interval. If
> all the nodes go to sleep, then progress continues as soon as they come
> back up. In normal conditions with a small number of nodes, consensus
> can happen in less than a second.
> 
> I am not aware of any third-party reviews of the whitepaper. 
> 
> The concepts are very similar to other voting-based BFT algorithms
> except the voting is "virtual". If the security of those systems (like
> PBFT or Tendermint...) has been vetted by the schemes you mention then
> perhaps they could be applied to Hashgraph as well.
> 
> Hope this answers you questions.
> 
> Regards,
> Martin
> -----Original message-----
> From: Christian Cachin
> Sent: Tuesday, June 27 2017, 11:43 am
> To: Martin Arrivets via hyperledger-tsc
> Cc: Martin Arrivets; David Huseby; Christopher Ferris; Giacomo Puri
> Purini Subject: Re: [Hyperledger Project TSC] Project Proposal:
> Consensus Platform
> 
> 
> Martin,
> 
> Can you point to any independent analysis of the properties achieved by 
> Swirlds consensus?  In which sense does it reach "consensus"?  Are there 
> any peer-reviewed publications or other third-party endorsements
> available?
> 
> In analogy with cryptography, where such issues have been discussed at 
> large, and over many decades, the security of a system should be based 
> on well-established and widely agreed-on schemes.
> 
> (FYI - I'm a cryptographer and also working on consensus protocols...)
> 
> Regards,
> 
>     Christian
> 
> 
> --- 
> Christian Cachin                           email: cca@...
> <mailto:cca@...> IBM Research -
> Zurich                           tel: +41-44-724-8989 Säumerstrasse 4
> CH-8803 Rüschlikon, Switzerland       http://www.zurich.ibm.com/˜cca
> <http://www.zurich.ibm.com/˜cca>; 
> 
> 
> 




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

 

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


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


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

hyperledger-tsc mailing list

hyperledger-tsc@...

https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


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

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



Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Silas Davis
 

Time flies...

If Martin is still interested, I would support this project. I think it is quite in-line with the recent spate of cross-cutting project types, whilst still being complete as an implementation - it's a fully executable thing not just library. It occupies a similar cutout to that of Tendermint.

Silas

On Tue, 20 Aug 2019 at 05:57, Stefan Buhrmester <buhrmi@...> wrote:
Two years later....

On Tue, Jul 4, 2017 at 4:18 PM, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thanks for the information Brian,

Before we go on to take care of the patent issues and changing the name we need to establish if it actually makes sense to incorporate our code base with Hyperledger.

On our side, we will need to show that the algorithm performs well compared to other comparable systems and that it has other qualitative advantages.

It also seems that there is no consensus among the TSC as to whether this type of project is a fit architecturally for Hyperledger.

So it would be good to keep the discussion going and to put the proposal on hold until these points are addressed.

Best,
Martin


On 4 Jul 2017, at 04:09, Brian Behlendorf <bbehlendorf@...> wrote:

I want to follow up and state that Leemon Baird (Hashgraph author) had reached out to me, and I asked him to confirm that this interpretation matches his understanding.  It sounds like they have multiple patents awarded and others filed and awaiting award relating to hashgraph, and we'd need either a clear grant to those patents as applied to Hyperledger code (essentially a DCO) from them or a statement that indeed their patents do not read upon Babble for the reasons you gave, before giving the OK here for babble to be contributed.  Otherwise you're asking a lot of people to take on a difficult-to-quantify risk, and patent issues are much more challenging to fix later than say copyright or trademark issues. 

Regarding the name - it has to be a name that isn't trademarked or otherwise owned/managed by another company, as that could lead to confusion.  Sometimes it's best to come up with a new name as it enters, such as happened with Fabric, Sawtooth, Indy, and Burrow.  I take it babble.io would still be a company & trademark you'd want to keep.

Brian

On 06/28/2017 11:14 AM, Martin Arrivets wrote:
Hello Brian,

Here is a link to a document describing the IP landscape around the issue: 

We suggest the name Babble.

Hope this helps,

Regards,
Martin


-----Original message-----
From: Brian Behlendorf via hyperledger-tsc
Sent: Wednesday, June 28 2017, 5:30 pm
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

I can ask our counsel once we know more about what's being proposed, and how that relates to the patent landscape.  Can someone involved in the proposal provide a write-up (which should be part of the repository, eventually) that details the known IP in this field, and how it relates to the project?  Just forwarding this thread probably isn't enough to go on.

Also, can we call this something more creative than just "Consensus Platform"?

Brian

On 06/28/2017 09:22 AM, Middleton, Dan via hyperledger-tsc wrote:

I don’t view journal publication as a gate on adding a project. It can be a factor in assessing technical merit but not the only factor. I’ll be looking whether there is sufficient detail/formality in the proposal and its references to assess that technical merit - regardless of academic status.

 

Part of the notion of pluggable consensus is to enable users to make informed tradeoffs in security and performance guarantees for different deployment environments.

 

The TSC also has a governance role on licensing. From this thread, specific patent concerns have been raised. I request that Hyperledger’s legal counsel provide some guidance to the TSC on that risk.

 

Regards,

Dan

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Brian Behlendorf via hyperledger-tsc
Sent: Wednesday, June 28, 2017 09:55
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

I am a bit more leery of viewing academic peer-review as a gating function for new projects joining Hyperledger.  It is completely appropriate IMHO for the Fabric maintainer community to state that they will only include consensus plug-ins in the Fabric install that meet some criteria for quality, and peer-reviewed consensus mechanisms may be that.  But not all possible consensus plug-ins need to be included within the Fabric project.  We could accept a new Hyperledger project to build a new/different consensus plug-in, with a different set of maintainers, who set their own standards for the proven-ness of the algorithm.  That might be the right thing for a Hashgraph plugin, especially if there are some edge-case patent concerns. 

Brian

On 06/27/2017 11:03 AM, Hart Montgomery via hyperledger-tsc wrote:

Hi Martin,

 

Is there a reason this hasn’t been submitted to a conference for peer review?  I’d highly recommend doing so—you’ll have a lot more credibility with regards to people believing the protocol if you can get it published in some conference proceedings.  If you need help, I bet there are people on this list who would be happy to point you in the right direction.

 

As it is, I’d be wary of accepting any new crypto or consensus into Hyperledger that hasn’t been published in a reputable conference or heavily reviewed and documented by outsiders.  It sets the precedent that the TSC or other members of the community would have to be academic-style crypto reviewers in order to properly assess new contributions.  While some of us may be, it puts an impossible burden on those that are not, and the appropriate place for new research to be evaluated (which new crypto or consensus is) is an academic conference anyways.  Additionally, to be truly safe, lots of time and review is needed for protocols that will be critical to systems.  For instance, the SHA-3 competition and review process took five years.  While we don’t need that much time for new consensus algorithms, I think this is still an area where it is much better to be safe than sorry.

 

Thanks for your time, and have a great day.

 

Hart

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Martin Arrivets via hyperledger-tsc
Sent: Tuesday, June 27, 2017 9:55 AM
To: Christian Cachin <cca@...>
Cc: Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...>; Giacomo Puri Purini <giacomo@...>
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

Thanks for the links,

 

Indeed the problem cannot be solved with a deterministic protocol

 

But there are ways to circumvent the FLP theorem by sacrificing determinism

cf Rabin, M.O. (1983) ‘Randomized Byzantine generals’ for example.

 

It is possible for a nondeterministic system to achieve consensus with probability

one.

 

That is what the Hashgraph does and that is what I meant when I wrote that participants 

will "eventually" (with probability one) know the exact location of a transaction in history.

 

The Hasgraph algorithm introduces periodic 'coin-rounds' where witnesses vote randomly. This

defends against attackers that control the internet and want to partition the network.

 

Martin

-----Original message-----
From: Christian Cachin
Sent: Tuesday, June 27 2017, 6:09 pm
To: Martin Arrivets
Cc: Martin Arrivets via hyperledger-tsc; David Huseby; Christopher Ferris; Giacomo Puri Purini
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform


Martin,
 
I've understood that there exists a white paper, yes.
 
But perhaps you should be aware that mathematically, in a "fully asynchronous
system" as you describe below, with < 1/3 faulty nodes (that crash or
act maliciously), or even with just one node that may crash, the "consensus
problem" cannot be solved with a deterministic protocol.
 
This is a famous result in distributed systems:
"Impossibility of Distributed Consensus with One Faulty Process" usually 
just called "FLP impossibility".
 
See more:
  https://en.wikipedia.org/wiki/Consensus_(computer_science)
  https://en.wikipedia.org/wiki/Byzantine_fault_tolerance
or a textbook I co-authored - www.distributedprogramming.net - although the
FLP result is not explained in there.
 
What you describe seems equivalent to this well-understood consensus problem.
 
In contrast to hashgraph, PBFT has been peer-reviewed and widely understood 
to achieve consensus in the appropriate model (eventual synchrony, not
asynchrony).
 
Regards,
 
      Christian
 
 
 
On 27 Jun 2017 12:03:06 +0000, Martin Arrivets <martin@...> wrote:
> Hi Christian,
> 
> The system achieves consensus in the sense that a participant will
> eventually know the exact location of a transaction in history and have
> a mathematical guarantee of finality (that this is the consensus order).
> The knowledge is not probabilistic but a mathematical guarantee.
> 
> The proofs in the whitepaper
> <http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf>; make the
> standard assumptions:
> 
> More than 2/3 of the computers are "honest", which means they follow the
> algorithm correctly and are available. Although an honest computer may
> go down for a while (and stop communicating) as long as they eventually
> come back up.
> 
> Nodes can collude and are allowed to mostly control the internet . Their
> only limit on control on the internet is that if Alice repeatedly sends
> Bob messages they must eventually allow Bob to receive one.
> 
> The proofs are for a fully asynchronous system. There is no assumption
> that an honest node will always respond within a certain interval. If
> all the nodes go to sleep, then progress continues as soon as they come
> back up. In normal conditions with a small number of nodes, consensus
> can happen in less than a second.
> 
> I am not aware of any third-party reviews of the whitepaper. 
> 
> The concepts are very similar to other voting-based BFT algorithms
> except the voting is "virtual". If the security of those systems (like
> PBFT or Tendermint...) has been vetted by the schemes you mention then
> perhaps they could be applied to Hashgraph as well.
> 
> Hope this answers you questions.
> 
> Regards,
> Martin
> -----Original message-----
> From: Christian Cachin
> Sent: Tuesday, June 27 2017, 11:43 am
> To: Martin Arrivets via hyperledger-tsc
> Cc: Martin Arrivets; David Huseby; Christopher Ferris; Giacomo Puri
> Purini Subject: Re: [Hyperledger Project TSC] Project Proposal:
> Consensus Platform
> 
> 
> Martin,
> 
> Can you point to any independent analysis of the properties achieved by 
> Swirlds consensus?  In which sense does it reach "consensus"?  Are there 
> any peer-reviewed publications or other third-party endorsements
> available?
> 
> In analogy with cryptography, where such issues have been discussed at 
> large, and over many decades, the security of a system should be based 
> on well-established and widely agreed-on schemes.
> 
> (FYI - I'm a cryptographer and also working on consensus protocols...)
> 
> Regards,
> 
>     Christian
> 
> 
> --- 
> Christian Cachin                           email: cca@...
> <mailto:cca@...> IBM Research -
> Zurich                           tel: +41-44-724-8989 Säumerstrasse 4
> CH-8803 Rüschlikon, Switzerland       http://www.zurich.ibm.com/˜cca
> <http://www.zurich.ibm.com/˜cca>; 
> 
> 
> 




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

 

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


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


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

hyperledger-tsc mailing list

hyperledger-tsc@...

https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


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

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



Re: Hyperledger Besu Proposal is Live

Jonathan Levi
 

Joe - we can probably do it, and pretty quickly. We already have both Fabric and Ethereum nodes (full nodes) on the Unbounded Network for quite a while... and we are already bridging Fabric - Quorum (JPM's), etc...

BUT, 

I don't think being under the same foundation will guarantee that people actively "make it work". One can argue that some of the biggest Fabric supporters also part of EEA/TTI and still haven't made this a priority. I wonder who will spend the money and time.. 

Also, for those more familiar with the Ethereum Ecosystem - there are so many tools that are not part of Hyperledger, from Truffle to Infura and I don't want to even mention block explorers and others. Do we want a commitment that all these tools will be part of Hyperledger, or that code will move from these projects (some are with GPL and others) into the respective HL candidates? There are actually announcements left, right and center about truffle adding Fabric support, etc. These developments are not done in Hyperledger. 

-----

What I don't understand is, since when we have ever required anything like some of the things I see below from a project at incubation? Shall we make these a future requirement? 

I will put together a wider response tomorrow, actually with a few questions that I belive we should answer within Hyperledger first, before we make so many changes "after a proposal is submitted". We saw it with Grid, which required an escalation to the board, and we are beginning to see some similar traits.

In the meantime, enjoy the Web3 Summit, Berlin BC Week, where applies.

Jonathan Levi





On Wed, Aug 21, 2019 at 1:20, Joseph Lubin
<joseph.lubin@...> wrote:
Mohan,

We have also engaged in discussions for a year of so with some Fabric focussed groups around finding a project that would benefit from a Fabric-Ethereum bridge.  To this point we haven't found a partner that was interested in doing this with us, but I expect this will happen quite quickly if we are all part of the same foundation. 



On Tue, Aug 20, 2019 at 6:08 PM, Grace Hartley <grace.hartley@...> wrote:
Hi Mohan, 

Here are our team's thoughts, but we'd love to hear the community's feedback as well.

In the short term we see the majority of interop and cross ledger communication happening at layer 2.  We are actively working with teams in the wider community to ensure that Besu facilitates layer 2 cross ledger communication, particularly working with the web3j team who are adding support for Hyperledger Fabric, and the Truffle team who are doing the same.

In the medium-term we are very interested in interoperability between chains, and we will be investing increasing effort in this direction, and in doing so expect to leverage many of the existing Hyperledger projects to do so. The two most obvious projects for collaboration currently are Burrow due to it’s EVM execution environment and aim of providing a practical base for EVM extensions in a many-chain world. In addition we look towards working with Quilt for its implementation of the interledger protocol. Quilt is a natural collaboration opportunity due to both the technologies it supports, and the fact that it is a JVM based technology.  

Thanks,
Grace

On Tue, Aug 20, 2019 at 11:44 AM Mohan Venkataraman <mohan. venkataraman@ chainyard. com> wrote:
Thank you Grace, for the kind response

How do you foresee Besu converge with Hyperledger technologies. For example, do you see Besu converging or inter-operating with Fabric or Sawtooth anytime. I do see blockchain networks going Hybrid as they evolve. There are several other yperledger projects like URSA and Transact. Quite interested in knowing Besu leveraging these.

Thanks
Mohan

On Mon, Aug 19, 2019, 1:15 PM Grace Hartley <grace. hartley@ consensys. net> wrote:
Hi All,

Thanks for the thoughtful questions. We've responded to them below.

Virgil’s Question: 

Why the name "Besu"?  That seems an odd choice, I'd imagine you'd want to pick an Ethereum-related word like "Rainbow", "Unicorn", or some such.


PegaSys' Response:

As Dan mentioned, we had a trademark challenge with Pantheon and we have to switch our name regardless of the Proposal. We chose Hyperledger Besu because “besu” means base in Japanese. We felt like base indicated how we developed the Ethereum client. We believe it is a solid foundation for blockchain developers to work on to run networks, build applications or send transactions, as an example.


Hyperledger’s naming principles target names that are not “common” words and that are easy to trademark. Unicorn, rainbow and all other words we explored that have more direct connections to Ethereum will have trademark challenges.


Mohan’s Question: 

Hyperledger technologies support a permissioned blockchain. They do not, at least to my understanding, have a crypto aspect. Is the intent to incubate Besu as a permissioned ethereum based blockchain and support interoperability with other platforms like Sawtooth, Iroha , Fabric? Also, how does this relate to Hyperledger Burrow?


PegaSys' Response:
The intent for Besu to be submitted in its current form. It can be run on the Ethereum public network or on private permissioned networks, as well as test networks such as Rinkeby, Ropsten, and Görli. We think public chain compatibility aligns with the enterprise market’s growing interest in using mainnet for a broader and more diverse set of use cases. Because this project is a protocol, it can be used for many different applications. Enabling cryotocurrency is only one of the applications. This project would be the first public chain compatible client within Hyperledger.

Silas provides a great response on his thoughts about how the project relates to Burrow and some ideas around collaboration here. Burrow is most well known for its EVM, which could connect in with Besu. They have a number of other components that we have started discussing with Silas. We are excited about closely working with the Hyperledger community to find areas for interoperability across the other projects. We have ideas mentioned in the Proposal around who we can collaborate with. 


Thanks,
Grace


On Sat, Aug 17, 2019 at 2:43 PM Mohan Venkataraman <mohan. venkataraman@ chainyard. com> wrote:
Hyperledger technologies support a permissioned blockchain. They do not, at least to my understanding, have a crypto aspect. Is the intent to incubate Besu as a permissioned ethereum based blockchain and support interoperability with other platforms like Sawtooth, Iroha , Fabric? Also, how does this relate to Hyperledger Burrow?


Regards

Mohan Venkataraman
Chainyard

On Sat, Aug 17, 2019, 9:41 AM Virgil Griffith via Lists. Hyperledger. Org <virgil=ethereum. org@ lists. hyperledger. org> wrote:
Why the name "Besu"?  That seems an odd choice, I'd imagine you'd want to pick an Ethereum-related word like "Rainbow", "Unicorn", or some such.

-V

On Sat, Aug 17, 2019 at 9:21 PM Dan O'Prey via Lists. Hyperledger. Org <dan=digitalasset. com@ lists. hyperledger. org> wrote:
There were some trademark issues around "Pantheon", unfortunately

Dan O'Prey

CMO & Head of Community / +1 646 647 5957
Digital Asset, creators of DAML


On Fri, Aug 16, 2019 at 8:28 PM Morgan Bauer <mbauer@ us. ibm. com> wrote:

Why rename it?

On 8/8/19 11:23:12, grace. hartley@ consensys. net wrote:

Hi All, We are excited to share that PegaSys, the Protocol Engineering team at ConsenSys, submitted the Proposal for our Ethereum client, Hyperledger Besu (currently known as Pantheon), for your consideration as a new Hyperledger project. 


We welcome your feedback on the Proposal and look forward to engaging with you on it. Feel free to send our team feedback via email or comment directly in the Proposal document.

Thank you,

PegaSys and ConsenSys Team Joseph Lubin, ConsenSys, joseph. lubin@ consensys. netDaniel Heyman, ConsenSys/ PegSys, daniel. heyman@ consensys. netRob Dawson, ConsenSys/ PegaSys, rob. dawson@ consensys. netGrace Hartley, ConsenSys/PegaSys, grace. hartley@ consensys. netDanno Ferrin, ConsenSys/PegaSys, danno. ferrin@ consensys. net



This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http:/ / www. digitalasset. com/ emaildisclaimer. html. If you are not the intended recipient, please delete this message.



Re: Hyperledger Besu Proposal is Live

Joseph Lubin
 

Mohan,

We have also engaged in discussions for a year of so with some Fabric focussed groups around finding a project that would benefit from a Fabric-Ethereum bridge.  To this point we haven't found a partner that was interested in doing this with us, but I expect this will happen quite quickly if we are all part of the same foundation. 



On Tue, Aug 20, 2019 at 6:08 PM, Grace Hartley <grace.hartley@...> wrote:
Hi Mohan, 

Here are our team's thoughts, but we'd love to hear the community's feedback as well.

In the short term we see the majority of interop and cross ledger communication happening at layer 2.  We are actively working with teams in the wider community to ensure that Besu facilitates layer 2 cross ledger communication, particularly working with the web3j team who are adding support for Hyperledger Fabric, and the Truffle team who are doing the same.

In the medium-term we are very interested in interoperability between chains, and we will be investing increasing effort in this direction, and in doing so expect to leverage many of the existing Hyperledger projects to do so. The two most obvious projects for collaboration currently are Burrow due to it’s EVM execution environment and aim of providing a practical base for EVM extensions in a many-chain world. In addition we look towards working with Quilt for its implementation of the interledger protocol. Quilt is a natural collaboration opportunity due to both the technologies it supports, and the fact that it is a JVM based technology.  

Thanks,
Grace

On Tue, Aug 20, 2019 at 11:44 AM Mohan Venkataraman <mohan.venkataraman@chainyard.com> wrote:
Thank you Grace, for the kind response

How do you foresee Besu converge with Hyperledger technologies. For example, do you see Besu converging or inter-operating with Fabric or Sawtooth anytime. I do see blockchain networks going Hybrid as they evolve. There are several other yperledger projects like URSA and Transact. Quite interested in knowing Besu leveraging these.

Thanks
Mohan

On Mon, Aug 19, 2019, 1:15 PM Grace Hartley <grace.hartley@consensys.net> wrote:
Hi All,

Thanks for the thoughtful questions. We've responded to them below.

Virgil’s Question: 

Why the name "Besu"?  That seems an odd choice, I'd imagine you'd want to pick an Ethereum-related word like "Rainbow", "Unicorn", or some such.


PegaSys' Response:

As Dan mentioned, we had a trademark challenge with Pantheon and we have to switch our name regardless of the Proposal. We chose Hyperledger Besu because “besu” means base in Japanese. We felt like base indicated how we developed the Ethereum client. We believe it is a solid foundation for blockchain developers to work on to run networks, build applications or send transactions, as an example.


Hyperledger’s naming principles target names that are not “common” words and that are easy to trademark. Unicorn, rainbow and all other words we explored that have more direct connections to Ethereum will have trademark challenges.


Mohan’s Question: 

Hyperledger technologies support a permissioned blockchain. They do not, at least to my understanding, have a crypto aspect. Is the intent to incubate Besu as a permissioned ethereum based blockchain and support interoperability with other platforms like Sawtooth, Iroha , Fabric? Also, how does this relate to Hyperledger Burrow?


PegaSys' Response:
The intent for Besu to be submitted in its current form. It can be run on the Ethereum public network or on private permissioned networks, as well as test networks such as Rinkeby, Ropsten, and Görli. We think public chain compatibility aligns with the enterprise market’s growing interest in using mainnet for a broader and more diverse set of use cases. Because this project is a protocol, it can be used for many different applications. Enabling cryotocurrency is only one of the applications. This project would be the first public chain compatible client within Hyperledger.

Silas provides a great response on his thoughts about how the project relates to Burrow and some ideas around collaboration here. Burrow is most well known for its EVM, which could connect in with Besu. They have a number of other components that we have started discussing with Silas. We are excited about closely working with the Hyperledger community to find areas for interoperability across the other projects. We have ideas mentioned in the Proposal around who we can collaborate with. 


Thanks,
Grace


On Sat, Aug 17, 2019 at 2:43 PM Mohan Venkataraman <mohan.venkataraman@chainyard.com> wrote:
Hyperledger technologies support a permissioned blockchain. They do not, at least to my understanding, have a crypto aspect. Is the intent to incubate Besu as a permissioned ethereum based blockchain and support interoperability with other platforms like Sawtooth, Iroha , Fabric? Also, how does this relate to Hyperledger Burrow?


Regards

Mohan Venkataraman
Chainyard

On Sat, Aug 17, 2019, 9:41 AM Virgil Griffith via Lists.Hyperledger.Org <virgil=ethereum.org@lists.hyperledger.org> wrote:
Why the name "Besu"?  That seems an odd choice, I'd imagine you'd want to pick an Ethereum-related word like "Rainbow", "Unicorn", or some such.

-V

On Sat, Aug 17, 2019 at 9:21 PM Dan O'Prey via Lists.Hyperledger.Org <dan=digitalasset.com@lists.hyperledger.org> wrote:
There were some trademark issues around "Pantheon", unfortunately

Dan O'Prey

CMO & Head of Community / +1 646 647 5957
Digital Asset, creators of DAML


On Fri, Aug 16, 2019 at 8:28 PM Morgan Bauer <mbauer@us.ibm.com> wrote:

Why rename it?

On 8/8/19 11:23:12, grace.hartley@consensys.net wrote:

Hi All, We are excited to share that PegaSys, the Protocol Engineering team at ConsenSys, submitted the Proposal for our Ethereum client, Hyperledger Besu (currently known as Pantheon), for your consideration as a new Hyperledger project. 


We welcome your feedback on the Proposal and look forward to engaging with you on it. Feel free to send our team feedback via email or comment directly in the Proposal document.

Thank you,

PegaSys and ConsenSys Team Joseph Lubin, ConsenSys, joseph.lubin@consensys.netDaniel Heyman, ConsenSys/ PegSys, daniel.heyman@consensys.netRob Dawson, ConsenSys/ PegaSys, rob.dawson@consensys.netGrace Hartley, ConsenSys/PegaSys, grace.hartley@consensys.netDanno Ferrin, ConsenSys/PegaSys, danno.ferrin@consensys.net



This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.



Re: Hyperledger Besu Proposal is Live

Grace Hartley
 

Hi Mohan, 

Here are our team's thoughts, but we'd love to hear the community's feedback as well.

In the short term we see the majority of interop and cross ledger communication happening at layer 2.  We are actively working with teams in the wider community to ensure that Besu facilitates layer 2 cross ledger communication, particularly working with the web3j team who are adding support for Hyperledger Fabric, and the Truffle team who are doing the same.

In the medium-term we are very interested in interoperability between chains, and we will be investing increasing effort in this direction, and in doing so expect to leverage many of the existing Hyperledger projects to do so. The two most obvious projects for collaboration currently are Burrow due to it’s EVM execution environment and aim of providing a practical base for EVM extensions in a many-chain world. In addition we look towards working with Quilt for its implementation of the interledger protocol. Quilt is a natural collaboration opportunity due to both the technologies it supports, and the fact that it is a JVM based technology.  

Thanks,
Grace

On Tue, Aug 20, 2019 at 11:44 AM Mohan Venkataraman <mohan.venkataraman@...> wrote:
Thank you Grace, for the kind response

How do you foresee Besu converge with Hyperledger technologies. For example, do you see Besu converging or inter-operating with Fabric or Sawtooth anytime. I do see blockchain networks going Hybrid as they evolve. There are several other yperledger projects like URSA and Transact. Quite interested in knowing Besu leveraging these.

Thanks
Mohan

On Mon, Aug 19, 2019, 1:15 PM Grace Hartley <grace.hartley@...> wrote:
Hi All,

Thanks for the thoughtful questions. We've responded to them below.

Virgil’s Question: 

Why the name "Besu"?  That seems an odd choice, I'd imagine you'd want to pick an Ethereum-related word like "Rainbow", "Unicorn", or some such.


PegaSys' Response:

As Dan mentioned, we had a trademark challenge with Pantheon and we have to switch our name regardless of the Proposal. We chose Hyperledger Besu because “besu” means base in Japanese. We felt like base indicated how we developed the Ethereum client. We believe it is a solid foundation for blockchain developers to work on to run networks, build applications or send transactions, as an example.


Hyperledger’s naming principles target names that are not “common” words and that are easy to trademark. Unicorn, rainbow and all other words we explored that have more direct connections to Ethereum will have trademark challenges.


Mohan’s Question: 

Hyperledger technologies support a permissioned blockchain. They do not, at least to my understanding, have a crypto aspect. Is the intent to incubate Besu as a permissioned ethereum based blockchain and support interoperability with other platforms like Sawtooth, Iroha , Fabric? Also, how does this relate to Hyperledger Burrow?


PegaSys' Response:
The intent for Besu to be submitted in its current form. It can be run on the Ethereum public network or on private permissioned networks, as well as test networks such as Rinkeby, Ropsten, and Görli. We think public chain compatibility aligns with the enterprise market’s growing interest in using mainnet for a broader and more diverse set of use cases. Because this project is a protocol, it can be used for many different applications. Enabling cryotocurrency is only one of the applications. This project would be the first public chain compatible client within Hyperledger.

Silas provides a great response on his thoughts about how the project relates to Burrow and some ideas around collaboration here. Burrow is most well known for its EVM, which could connect in with Besu. They have a number of other components that we have started discussing with Silas. We are excited about closely working with the Hyperledger community to find areas for interoperability across the other projects. We have ideas mentioned in the Proposal around who we can collaborate with. 


Thanks,
Grace


On Sat, Aug 17, 2019 at 2:43 PM Mohan Venkataraman <mohan.venkataraman@...> wrote:
Hyperledger technologies support a permissioned blockchain. They do not, at least to my understanding, have a crypto aspect. Is the intent to incubate Besu as a permissioned ethereum based blockchain and support interoperability with other platforms like Sawtooth, Iroha , Fabric? Also, how does this relate to Hyperledger Burrow?


Regards

Mohan Venkataraman
Chainyard

On Sat, Aug 17, 2019, 9:41 AM Virgil Griffith via Lists.Hyperledger.Org <virgil=ethereum.org@...> wrote:
Why the name "Besu"?  That seems an odd choice, I'd imagine you'd want to pick an Ethereum-related word like "Rainbow", "Unicorn", or some such.

-V

On Sat, Aug 17, 2019 at 9:21 PM Dan O'Prey via Lists.Hyperledger.Org <dan=digitalasset.com@...> wrote:
There were some trademark issues around "Pantheon", unfortunately

Dan O'Prey

CMO & Head of Community / +1 646 647 5957
Digital Asset, creators of DAML


On Fri, Aug 16, 2019 at 8:28 PM Morgan Bauer <mbauer@...> wrote:

Why rename it?

On 8/8/19 11:23:12, grace.hartley@... wrote:

Hi All, We are excited to share that PegaSys, the Protocol Engineering team at ConsenSys, submitted the Proposal for our Ethereum client, Hyperledger Besu (currently known as Pantheon), for your consideration as a new Hyperledger project. 


We welcome your feedback on the Proposal and look forward to engaging with you on it. Feel free to send our team feedback via email or comment directly in the Proposal document.

Thank you,

PegaSys and ConsenSys Team Joseph Lubin, ConsenSys, joseph.lubin@...Daniel Heyman, ConsenSys/ PegSys, daniel.heyman@...Rob Dawson, ConsenSys/ PegaSys, rob.dawson@...Grace Hartley, ConsenSys/PegaSys, grace.hartley@...Danno Ferrin, ConsenSys/PegaSys, danno.ferrin@...



This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.


Re: Monthly Hyperledger Contributor-MC Meetings

Dan O'Prey <dan@...>
 

Hope as many of you can make it as possible! Would love to bridge the gap more between marketing and technical side, especially when it comes to project specific marketing.

Dan O'Prey

CMO & Head of Community / +1 646 647 5957
Digital Asset, creators of DAML


On Tue, Aug 20, 2019 at 3:58 PM Brian Behlendorf <bbehlendorf@...> wrote:

Hi all,

Starting Sept 11th, there will be a monthly call hosted by the Marketing Committee chairs (currently Dan O'Prey and Alissa Worley), and our marketing lead Jessica Rampen, to build a dialogue with the technical community about how to better promote what you're building, and how to involve you in the opportunities (press & analysts, content, speaking opps, etc) that we receive and are lining up.

It'll be at 9am on the 2nd Wednesdays of every month.  You can find the entry for it on the Hyperledger Calendar at https://wiki.hyperledger.org/display/HYP/Calendar+of+Public+Meetings (look under Sept 11th, and set your time zone as appropriate) and add it to your calendar that way, or through the Google Calendar .ics link.  All are welcome but in particular we would like maintainers and active contributors involved, so we can be the best possible champions of what you're building.

Here's the description from the calendar entry:


The purpose of this call is to discuss marketing related initiatives around the Hyperledger projects and community. This is a great opportunity for project maintainers and contributors to learn how they can get involved in many aspects of marketing including overall messaging, events, content, social media, and PR, to further help the public hear about and understand Hyperledger and its community.


Goal(s): 

  • Improve the communication between marketing and technical leaders in the community

  • Gain guidance and involvement from Hyperledger project technical experts in marketing initiatives 

  • Understand how we can better work together to amplify Hyperledger’s public presence and marketing messages


Who should join: Maintainers, active contributors to Hyperledger projects


Dial in information: 

The second Wednesday of every month

Kick off call: Wednesday, Sept 11 at 9am PT

Join Zoom Meeting

https://zoom.us/j/982600073


One tap mobile

+16465588656,,982600073# US (New York)

+16699006833,,982600073# US (San Jose)


Dial by your location

        +1 646 558 8656 US (New York)

        +1 669 900 6833 US (San Jose)

        877 369 0926 US Toll-free

        855 880 1246 US Toll-free

        +1 647 558 0588 Canada

        855 703 8985 Canada Toll-free

Meeting ID: 982 600 073

Find your local number: https://zoom.us/u/abaoIu7JMk


Thanks,


Brian

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

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.


Monthly Hyperledger Contributor-MC Meetings

Brian Behlendorf
 

Hi all,

Starting Sept 11th, there will be a monthly call hosted by the Marketing Committee chairs (currently Dan O'Prey and Alissa Worley), and our marketing lead Jessica Rampen, to build a dialogue with the technical community about how to better promote what you're building, and how to involve you in the opportunities (press & analysts, content, speaking opps, etc) that we receive and are lining up.

It'll be at 9am on the 2nd Wednesdays of every month.  You can find the entry for it on the Hyperledger Calendar at https://wiki.hyperledger.org/display/HYP/Calendar+of+Public+Meetings (look under Sept 11th, and set your time zone as appropriate) and add it to your calendar that way, or through the Google Calendar .ics link.  All are welcome but in particular we would like maintainers and active contributors involved, so we can be the best possible champions of what you're building.

Here's the description from the calendar entry:


The purpose of this call is to discuss marketing related initiatives around the Hyperledger projects and community. This is a great opportunity for project maintainers and contributors to learn how they can get involved in many aspects of marketing including overall messaging, events, content, social media, and PR, to further help the public hear about and understand Hyperledger and its community.


Goal(s): 

  • Improve the communication between marketing and technical leaders in the community

  • Gain guidance and involvement from Hyperledger project technical experts in marketing initiatives 

  • Understand how we can better work together to amplify Hyperledger’s public presence and marketing messages


Who should join: Maintainers, active contributors to Hyperledger projects


Dial in information: 

The second Wednesday of every month

Kick off call: Wednesday, Sept 11 at 9am PT

Join Zoom Meeting

https://zoom.us/j/982600073


One tap mobile

+16465588656,,982600073# US (New York)

+16699006833,,982600073# US (San Jose)


Dial by your location

        +1 646 558 8656 US (New York)

        +1 669 900 6833 US (San Jose)

        877 369 0926 US Toll-free

        855 880 1246 US Toll-free

        +1 647 558 0588 Canada

        855 703 8985 Canada Toll-free

Meeting ID: 982 600 073

Find your local number: https://zoom.us/u/abaoIu7JMk


Thanks,


Brian

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


Re: Hyperledger Besu Proposal is Live

Mohan Venkataraman
 

Thank you Grace, for the kind response

How do you foresee Besu converge with Hyperledger technologies. For example, do you see Besu converging or inter-operating with Fabric or Sawtooth anytime. I do see blockchain networks going Hybrid as they evolve. There are several other yperledger projects like URSA and Transact. Quite interested in knowing Besu leveraging these.

Thanks
Mohan

On Mon, Aug 19, 2019, 1:15 PM Grace Hartley <grace.hartley@...> wrote:
Hi All,

Thanks for the thoughtful questions. We've responded to them below.

Virgil’s Question: 

Why the name "Besu"?  That seems an odd choice, I'd imagine you'd want to pick an Ethereum-related word like "Rainbow", "Unicorn", or some such.


PegaSys' Response:

As Dan mentioned, we had a trademark challenge with Pantheon and we have to switch our name regardless of the Proposal. We chose Hyperledger Besu because “besu” means base in Japanese. We felt like base indicated how we developed the Ethereum client. We believe it is a solid foundation for blockchain developers to work on to run networks, build applications or send transactions, as an example.


Hyperledger’s naming principles target names that are not “common” words and that are easy to trademark. Unicorn, rainbow and all other words we explored that have more direct connections to Ethereum will have trademark challenges.


Mohan’s Question: 

Hyperledger technologies support a permissioned blockchain. They do not, at least to my understanding, have a crypto aspect. Is the intent to incubate Besu as a permissioned ethereum based blockchain and support interoperability with other platforms like Sawtooth, Iroha , Fabric? Also, how does this relate to Hyperledger Burrow?


PegaSys' Response:
The intent for Besu to be submitted in its current form. It can be run on the Ethereum public network or on private permissioned networks, as well as test networks such as Rinkeby, Ropsten, and Görli. We think public chain compatibility aligns with the enterprise market’s growing interest in using mainnet for a broader and more diverse set of use cases. Because this project is a protocol, it can be used for many different applications. Enabling cryotocurrency is only one of the applications. This project would be the first public chain compatible client within Hyperledger.

Silas provides a great response on his thoughts about how the project relates to Burrow and some ideas around collaboration here. Burrow is most well known for its EVM, which could connect in with Besu. They have a number of other components that we have started discussing with Silas. We are excited about closely working with the Hyperledger community to find areas for interoperability across the other projects. We have ideas mentioned in the Proposal around who we can collaborate with. 


Thanks,
Grace


On Sat, Aug 17, 2019 at 2:43 PM Mohan Venkataraman <mohan.venkataraman@...> wrote:
Hyperledger technologies support a permissioned blockchain. They do not, at least to my understanding, have a crypto aspect. Is the intent to incubate Besu as a permissioned ethereum based blockchain and support interoperability with other platforms like Sawtooth, Iroha , Fabric? Also, how does this relate to Hyperledger Burrow?


Regards

Mohan Venkataraman
Chainyard

On Sat, Aug 17, 2019, 9:41 AM Virgil Griffith via Lists.Hyperledger.Org <virgil=ethereum.org@...> wrote:
Why the name "Besu"?  That seems an odd choice, I'd imagine you'd want to pick an Ethereum-related word like "Rainbow", "Unicorn", or some such.

-V

On Sat, Aug 17, 2019 at 9:21 PM Dan O'Prey via Lists.Hyperledger.Org <dan=digitalasset.com@...> wrote:
There were some trademark issues around "Pantheon", unfortunately

Dan O'Prey

CMO & Head of Community / +1 646 647 5957
Digital Asset, creators of DAML


On Fri, Aug 16, 2019 at 8:28 PM Morgan Bauer <mbauer@...> wrote:

Why rename it?

On 8/8/19 11:23:12, grace.hartley@... wrote:

Hi All, We are excited to share that PegaSys, the Protocol Engineering team at ConsenSys, submitted the Proposal for our Ethereum client, Hyperledger Besu (currently known as Pantheon), for your consideration as a new Hyperledger project. 


We welcome your feedback on the Proposal and look forward to engaging with you on it. Feel free to send our team feedback via email or comment directly in the Proposal document.

Thank you,

PegaSys and ConsenSys Team Joseph Lubin, ConsenSys, joseph.lubin@...Daniel Heyman, ConsenSys/ PegSys, daniel.heyman@...Rob Dawson, ConsenSys/ PegaSys, rob.dawson@...Grace Hartley, ConsenSys/PegaSys, grace.hartley@...Danno Ferrin, ConsenSys/PegaSys, danno.ferrin@...



This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.


Upcoming Event: Hyperledger Grid Quarterly Update Due #tsc-project-update - Thu, 08/22/2019 #tsc-project-update #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: Hyperledger Grid Quarterly Update Due #tsc-project-update

When: Thursday, 22 August 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Grid project update to the TSC was due 19 August, 2019, and it will be presented to the TSC on 22 August, 2019. Please review prior to the meeting and bring your questions.


Upcoming Event: Hyperledger Technical WG China Quarterly Update Due #tsc-wg-update - Thu, 08/22/2019 #cal-reminder #tsc-wg-update

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: Hyperledger Technical WG China Quarterly Update Due #tsc-wg-update

When: Thursday, 22 August 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Technical WG China update to the TSC was due 19 August, 2019, and it will be presented to the TSC on 22 August, 2019. Please review prior to the meeting and bring your questions.


Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

Stefan Buhrmester <buhrmi@...>
 

Two years later....

On Tue, Jul 4, 2017 at 4:18 PM, Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thanks for the information Brian,

Before we go on to take care of the patent issues and changing the name we need to establish if it actually makes sense to incorporate our code base with Hyperledger.

On our side, we will need to show that the algorithm performs well compared to other comparable systems and that it has other qualitative advantages.

It also seems that there is no consensus among the TSC as to whether this type of project is a fit architecturally for Hyperledger.

So it would be good to keep the discussion going and to put the proposal on hold until these points are addressed.

Best,
Martin


On 4 Jul 2017, at 04:09, Brian Behlendorf <bbehlendorf@...> wrote:

I want to follow up and state that Leemon Baird (Hashgraph author) had reached out to me, and I asked him to confirm that this interpretation matches his understanding.  It sounds like they have multiple patents awarded and others filed and awaiting award relating to hashgraph, and we'd need either a clear grant to those patents as applied to Hyperledger code (essentially a DCO) from them or a statement that indeed their patents do not read upon Babble for the reasons you gave, before giving the OK here for babble to be contributed.  Otherwise you're asking a lot of people to take on a difficult-to-quantify risk, and patent issues are much more challenging to fix later than say copyright or trademark issues. 

Regarding the name - it has to be a name that isn't trademarked or otherwise owned/managed by another company, as that could lead to confusion.  Sometimes it's best to come up with a new name as it enters, such as happened with Fabric, Sawtooth, Indy, and Burrow.  I take it babble.io would still be a company & trademark you'd want to keep.

Brian

On 06/28/2017 11:14 AM, Martin Arrivets wrote:
Hello Brian,

Here is a link to a document describing the IP landscape around the issue: 

We suggest the name Babble.

Hope this helps,

Regards,
Martin


-----Original message-----
From: Brian Behlendorf via hyperledger-tsc
Sent: Wednesday, June 28 2017, 5:30 pm
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

I can ask our counsel once we know more about what's being proposed, and how that relates to the patent landscape.  Can someone involved in the proposal provide a write-up (which should be part of the repository, eventually) that details the known IP in this field, and how it relates to the project?  Just forwarding this thread probably isn't enough to go on.

Also, can we call this something more creative than just "Consensus Platform"?

Brian

On 06/28/2017 09:22 AM, Middleton, Dan via hyperledger-tsc wrote:

I don’t view journal publication as a gate on adding a project. It can be a factor in assessing technical merit but not the only factor. I’ll be looking whether there is sufficient detail/formality in the proposal and its references to assess that technical merit - regardless of academic status.

 

Part of the notion of pluggable consensus is to enable users to make informed tradeoffs in security and performance guarantees for different deployment environments.

 

The TSC also has a governance role on licensing. From this thread, specific patent concerns have been raised. I request that Hyperledger’s legal counsel provide some guidance to the TSC on that risk.

 

Regards,

Dan

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Brian Behlendorf via hyperledger-tsc
Sent: Wednesday, June 28, 2017 09:55
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

I am a bit more leery of viewing academic peer-review as a gating function for new projects joining Hyperledger.  It is completely appropriate IMHO for the Fabric maintainer community to state that they will only include consensus plug-ins in the Fabric install that meet some criteria for quality, and peer-reviewed consensus mechanisms may be that.  But not all possible consensus plug-ins need to be included within the Fabric project.  We could accept a new Hyperledger project to build a new/different consensus plug-in, with a different set of maintainers, who set their own standards for the proven-ness of the algorithm.  That might be the right thing for a Hashgraph plugin, especially if there are some edge-case patent concerns. 

Brian

On 06/27/2017 11:03 AM, Hart Montgomery via hyperledger-tsc wrote:

Hi Martin,

 

Is there a reason this hasn’t been submitted to a conference for peer review?  I’d highly recommend doing so—you’ll have a lot more credibility with regards to people believing the protocol if you can get it published in some conference proceedings.  If you need help, I bet there are people on this list who would be happy to point you in the right direction.

 

As it is, I’d be wary of accepting any new crypto or consensus into Hyperledger that hasn’t been published in a reputable conference or heavily reviewed and documented by outsiders.  It sets the precedent that the TSC or other members of the community would have to be academic-style crypto reviewers in order to properly assess new contributions.  While some of us may be, it puts an impossible burden on those that are not, and the appropriate place for new research to be evaluated (which new crypto or consensus is) is an academic conference anyways.  Additionally, to be truly safe, lots of time and review is needed for protocols that will be critical to systems.  For instance, the SHA-3 competition and review process took five years.  While we don’t need that much time for new consensus algorithms, I think this is still an area where it is much better to be safe than sorry.

 

Thanks for your time, and have a great day.

 

Hart

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Martin Arrivets via hyperledger-tsc
Sent: Tuesday, June 27, 2017 9:55 AM
To: Christian Cachin <cca@...>
Cc: Martin Arrivets via hyperledger-tsc <hyperledger-tsc@...>; Giacomo Puri Purini <giacomo@...>
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

Thanks for the links,

 

Indeed the problem cannot be solved with a deterministic protocol

 

But there are ways to circumvent the FLP theorem by sacrificing determinism

cf Rabin, M.O. (1983) ‘Randomized Byzantine generals’ for example.

 

It is possible for a nondeterministic system to achieve consensus with probability

one.

 

That is what the Hashgraph does and that is what I meant when I wrote that participants 

will "eventually" (with probability one) know the exact location of a transaction in history.

 

The Hasgraph algorithm introduces periodic 'coin-rounds' where witnesses vote randomly. This

defends against attackers that control the internet and want to partition the network.

 

Martin

-----Original message-----
From: Christian Cachin
Sent: Tuesday, June 27 2017, 6:09 pm
To: Martin Arrivets
Cc: Martin Arrivets via hyperledger-tsc; David Huseby; Christopher Ferris; Giacomo Puri Purini
Subject: Re: [Hyperledger Project TSC] Project Proposal: Consensus Platform


Martin,
 
I've understood that there exists a white paper, yes.
 
But perhaps you should be aware that mathematically, in a "fully asynchronous
system" as you describe below, with < 1/3 faulty nodes (that crash or
act maliciously), or even with just one node that may crash, the "consensus
problem" cannot be solved with a deterministic protocol.
 
This is a famous result in distributed systems:
"Impossibility of Distributed Consensus with One Faulty Process" usually 
just called "FLP impossibility".
 
See more:
  https://en.wikipedia.org/wiki/Consensus_(computer_science)
  https://en.wikipedia.org/wiki/Byzantine_fault_tolerance
or a textbook I co-authored - www.distributedprogramming.net - although the
FLP result is not explained in there.
 
What you describe seems equivalent to this well-understood consensus problem.
 
In contrast to hashgraph, PBFT has been peer-reviewed and widely understood 
to achieve consensus in the appropriate model (eventual synchrony, not
asynchrony).
 
Regards,
 
      Christian
 
 
 
On 27 Jun 2017 12:03:06 +0000, Martin Arrivets <martin@...> wrote:
> Hi Christian,
> 
> The system achieves consensus in the sense that a participant will
> eventually know the exact location of a transaction in history and have
> a mathematical guarantee of finality (that this is the consensus order).
> The knowledge is not probabilistic but a mathematical guarantee.
> 
> The proofs in the whitepaper
> <http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf>; make the
> standard assumptions:
> 
> More than 2/3 of the computers are "honest", which means they follow the
> algorithm correctly and are available. Although an honest computer may
> go down for a while (and stop communicating) as long as they eventually
> come back up.
> 
> Nodes can collude and are allowed to mostly control the internet . Their
> only limit on control on the internet is that if Alice repeatedly sends
> Bob messages they must eventually allow Bob to receive one.
> 
> The proofs are for a fully asynchronous system. There is no assumption
> that an honest node will always respond within a certain interval. If
> all the nodes go to sleep, then progress continues as soon as they come
> back up. In normal conditions with a small number of nodes, consensus
> can happen in less than a second.
> 
> I am not aware of any third-party reviews of the whitepaper. 
> 
> The concepts are very similar to other voting-based BFT algorithms
> except the voting is "virtual". If the security of those systems (like
> PBFT or Tendermint...) has been vetted by the schemes you mention then
> perhaps they could be applied to Hashgraph as well.
> 
> Hope this answers you questions.
> 
> Regards,
> Martin
> -----Original message-----
> From: Christian Cachin
> Sent: Tuesday, June 27 2017, 11:43 am
> To: Martin Arrivets via hyperledger-tsc
> Cc: Martin Arrivets; David Huseby; Christopher Ferris; Giacomo Puri
> Purini Subject: Re: [Hyperledger Project TSC] Project Proposal:
> Consensus Platform
> 
> 
> Martin,
> 
> Can you point to any independent analysis of the properties achieved by 
> Swirlds consensus?  In which sense does it reach "consensus"?  Are there 
> any peer-reviewed publications or other third-party endorsements
> available?
> 
> In analogy with cryptography, where such issues have been discussed at 
> large, and over many decades, the security of a system should be based 
> on well-established and widely agreed-on schemes.
> 
> (FYI - I'm a cryptographer and also working on consensus protocols...)
> 
> Regards,
> 
>     Christian
> 
> 
> --- 
> Christian Cachin                           email: cca@...
> <mailto:cca@...> IBM Research -
> Zurich                           tel: +41-44-724-8989 Säumerstrasse 4
> CH-8803 Rüschlikon, Switzerland       http://www.zurich.ibm.com/˜cca
> <http://www.zurich.ibm.com/˜cca>; 
> 
> 
> 




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

 

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


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


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

hyperledger-tsc mailing list

hyperledger-tsc@...

https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


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

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



Re: Trusted Compute Framework (TCF) Project Proposal

Brian Behlendorf
 

This is very cool!  So glad to see it building on work done in Labs; so glad to see the very large list of collaborators and the specific commitments made by different companies; and so glad to see one of the first real fruits of the EEA/Hyperledger relationship.  Congrats Yarmosh, Mic, and everyone who worked on this.

Brian

On 8/19/19 11:25 AM, Mic Bowman wrote:

On Fri, Aug 16, 2019 at 4:01 PM <yevgeniy.y.yarmosh@...> wrote:
Hello,

I have just posted Trusted Compute Framework (TCF) Project Proposal for the review and discussion.

Regards,
Eugene Yarmosh
yevgeniy.y.yarmosh@...


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


Re: Nominations for the 2019-2020 TSC are open

Brian Behlendorf
 

To clarify, if you are a contributor, and did not get that email, THEN use that form to apply for contributor status so we can count you as a voter (and you can run for TSC), as we may have missed you using the automated tools at our disposal.

<IMHO>
I would strongly encourage anyone who is an occasional-or-more contributor to any Hyperledger project, even if in non-technical ways, and who cares about the operations and health of the overall community, to consider running for the TSC.  It is true that the T and the S stand for "Technical Steering", and that often expresses itself in very technical discussions about the merits of new proposed projects or how best to use our different tools. You should be technical enough to keep up with the kinds of discussions you've seen here and on the calls and feel confident in voting when required. You also need to be able to attend most of those 10am ET Thursday calls.  :)  But it's not intended that the TSC be a map to the 11 most prolific contributors by lines-of-code, nor the 11 most active senders of emails or chat messages, nor the 11 most well-traveled conference presenters.  Nor are you there to "represent" your project, or home country, or other subset constituency. You should run if you want to serve the interests of the full Hyperledger community, and the community it can grow to become.
</IMHO>

Brian

On 8/19/19 12:18 PM, Ry Jones wrote:
Here is the nomination form:

Please read:

If you are a contributor, and you did not get this email:

Please use this form:

Ry
--
Ry Jones
Community Architect, Hyperledger


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


Nominations for the 2019-2020 TSC are open

Ry Jones
 

Here is the nomination form:

Please read:

If you are a contributor, and you did not get this email:

Please use this form:

Ry
--
Ry Jones
Community Architect, Hyperledger


Re: Trusted Compute Framework (TCF) Project Proposal

Mic Bowman
 


On Fri, Aug 16, 2019 at 4:01 PM <yevgeniy.y.yarmosh@...> wrote:
Hello,

I have just posted Trusted Compute Framework (TCF) Project Proposal for the review and discussion.

Regards,
Eugene Yarmosh
yevgeniy.y.yarmosh@...


Re: Hyperledger Besu Proposal is Live

Grace Hartley
 

Hi All,

Thanks for the thoughtful questions. We've responded to them below.

Virgil’s Question: 

Why the name "Besu"?  That seems an odd choice, I'd imagine you'd want to pick an Ethereum-related word like "Rainbow", "Unicorn", or some such.


PegaSys' Response:

As Dan mentioned, we had a trademark challenge with Pantheon and we have to switch our name regardless of the Proposal. We chose Hyperledger Besu because “besu” means base in Japanese. We felt like base indicated how we developed the Ethereum client. We believe it is a solid foundation for blockchain developers to work on to run networks, build applications or send transactions, as an example.


Hyperledger’s naming principles target names that are not “common” words and that are easy to trademark. Unicorn, rainbow and all other words we explored that have more direct connections to Ethereum will have trademark challenges.


Mohan’s Question: 

Hyperledger technologies support a permissioned blockchain. They do not, at least to my understanding, have a crypto aspect. Is the intent to incubate Besu as a permissioned ethereum based blockchain and support interoperability with other platforms like Sawtooth, Iroha , Fabric? Also, how does this relate to Hyperledger Burrow?


PegaSys' Response:
The intent for Besu to be submitted in its current form. It can be run on the Ethereum public network or on private permissioned networks, as well as test networks such as Rinkeby, Ropsten, and Görli. We think public chain compatibility aligns with the enterprise market’s growing interest in using mainnet for a broader and more diverse set of use cases. Because this project is a protocol, it can be used for many different applications. Enabling cryotocurrency is only one of the applications. This project would be the first public chain compatible client within Hyperledger.

Silas provides a great response on his thoughts about how the project relates to Burrow and some ideas around collaboration here. Burrow is most well known for its EVM, which could connect in with Besu. They have a number of other components that we have started discussing with Silas. We are excited about closely working with the Hyperledger community to find areas for interoperability across the other projects. We have ideas mentioned in the Proposal around who we can collaborate with. 


Thanks,
Grace


On Sat, Aug 17, 2019 at 2:43 PM Mohan Venkataraman <mohan.venkataraman@...> wrote:
Hyperledger technologies support a permissioned blockchain. They do not, at least to my understanding, have a crypto aspect. Is the intent to incubate Besu as a permissioned ethereum based blockchain and support interoperability with other platforms like Sawtooth, Iroha , Fabric? Also, how does this relate to Hyperledger Burrow?


Regards

Mohan Venkataraman
Chainyard

On Sat, Aug 17, 2019, 9:41 AM Virgil Griffith via Lists.Hyperledger.Org <virgil=ethereum.org@...> wrote:
Why the name "Besu"?  That seems an odd choice, I'd imagine you'd want to pick an Ethereum-related word like "Rainbow", "Unicorn", or some such.

-V

On Sat, Aug 17, 2019 at 9:21 PM Dan O'Prey via Lists.Hyperledger.Org <dan=digitalasset.com@...> wrote:
There were some trademark issues around "Pantheon", unfortunately

Dan O'Prey

CMO & Head of Community / +1 646 647 5957
Digital Asset, creators of DAML


On Fri, Aug 16, 2019 at 8:28 PM Morgan Bauer <mbauer@...> wrote:

Why rename it?

On 8/8/19 11:23:12, grace.hartley@... wrote:

Hi All, We are excited to share that PegaSys, the Protocol Engineering team at ConsenSys, submitted the Proposal for our Ethereum client, Hyperledger Besu (currently known as Pantheon), for your consideration as a new Hyperledger project. 


We welcome your feedback on the Proposal and look forward to engaging with you on it. Feel free to send our team feedback via email or comment directly in the Proposal document.

Thank you,

PegaSys and ConsenSys Team Joseph Lubin, ConsenSys, joseph.lubin@...Daniel Heyman, ConsenSys/ PegSys, daniel.heyman@...Rob Dawson, ConsenSys/ PegaSys, rob.dawson@...Grace Hartley, ConsenSys/PegaSys, grace.hartley@...Danno Ferrin, ConsenSys/PegaSys, danno.ferrin@...



This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

1321 - 1340 of 3898