Date   

Re: Hyperledger Besu Proposal is Live

VIPIN BHARATHAN
 

Hi Jon,
Thanks for the thoughtful response.
  • Pluggable consensus has been in active discussion in the Architecture working group. Unfortunately participation in such cross dlt architectural conversations has dropped, at least under the aegis of the AWG. We have had conversations of how to reboot the WGs and you should join the conversation.
  • There has been no support to bring "consistent technical principles". Working Groups and other cross-dlt areas where such work should take place are languishing and there are many actively campaigning against WGs. However this again has nothing to do with whether we should approve Besu or not.
  • HL is unique in its sheltering  of multiple DLT solutions, there is no comparable consortium and we are inventing the integrative concepts around such co-opetition. I am also an advocate of a full offering (integrating documentation, deployment, operational support, simple and intuitive UIs, adherence to regulation demonstrable with security audits, monitoring and self-healing),  having had some experience importing dlt solutions into highly regulated enterprises. 
  • The comparison of public and private consensus algorithms is interesting and I do agree with many of RGBs points. However for large networks, BFT solutions that support liveness and safety at scale (i.e. where there is a linear  or log not quadratic or higher order relation to N) should be adopted. But what does this have to do with Besu? The fact that it will offer a link between private and public dlts could lead to emergent effects, which none of us can predict at this point.
  • The arrival of new projects into Hyperledger, especially something backed by large networks who are new to Hyperledger will stimulate work in all areas. When there is competition, people will be forced to improve their offerings to stay relevant.
  • Ursa adoption in Ethereum is being worked on, Virgil has been leading this effort and hopefully Besu will join this effort.
  • In short, I am against holding Besu to a different standard than the existing platforms in Hyperledger. Let us be consistent. Getting new blood and new ideas into HL will make a difference in existing dlts as well. The new entrants may revive interest in cross-dlt efforts like the working groups and SIGs. 
Best,
Vipin

dlt.nyc
Vipin Bharathan
Enterprise Blockchain Consultant
vip@...


From: tsc@... <tsc@...> on behalf of Jon Geater via Lists.Hyperledger.Org <jon.geater=jitsuin.com@...>
Sent: Sunday, August 25, 2019 10:56 AM
To: vipinsun@... <vipinsun@...>; Silas Davis <silas@...>
Cc: tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live
 
Thanks Vipin, that does bring some clear points to draw the discussion around.  However if you consider the parallel thread about architecture it’s quite possible to see these virtues as vices.

If we want to have pluggable consensus, widespread proper use of Ursa and all those other great things that adoption of the Hyperledger code bases promises then at some point we need to have architectural constraints and adherence throughout all the frameworks and projects.  Early on, the more overlapping co-opetitive projects we add the better: competition drives quality and features and ideas.  But as time goes on and numbers grow it can lead to fragmentation, redundant work, and lower overall progress.  Especially if (as is almost inevitable with multiple projects with different provenance) they have a different idea of where architectural layers should be drawn and where the functional responsibilities of major objects lie.  That’s the path to adapters, proxies and so on, which is in turn a path to potential problems.

I’ve worked at the leading edge of large technology ecosystems for a long time now and something that constantly comes up is that there is ‘good differentiation’, where different offerings provide stability and choice to consumers while competing on niche or value-add offers; and ‘bad differentiation’, where suppliers compromise consumer choice by insisting on being different in layers that should be standardised and enabling.  This is not just about standardizing APIs or protocols: it’s also all around the peripheral stuff: keeping documentation up to date; learning and deploying management systems and administrative functionality; differences in system design assumptions that lead to subtle operational problems; differences in cryptographic design assumptions that lead to subtle security problems; etc.  

I don’t want to seem negative, either towards new proposals in general, or Besu in particular. But to address your first bullet, when you have a mission and a stable of existing projects, ‘technical merit’ is not an absolute, objective, or independent measure.  It’s absolutely right that we discuss the technical fit and feature overlap of new projects with old, including the ‘gymnastic’ aspects, because it might be (as others have noted) that we _should_ accept the new thing but should then also guide older things in different directions so as not to ride too many horses in the same race.

We’re discussing TCF next week.  I won’t write much about that here because it’s such a huge (different) topic.  But imagine trying to write a proper threat analysis or system composition or whatever if everylayer of every one of those stacks had differently opinionated versions of the same concepts.  It would make a great Ph.D. thesis but it won’t catch on.

Again, not against Besu at all.  The mature, stable, battle-hardened aspects you mention are great strengths, we need those.  All I’m trying to say is that we can’t make these decisions in isolation and as Hyperledger we do need to judge proposals against consistent technical principles across all the projects and frameworks, otherwise we’re not a community and force multiplier, we’re just a giant repo.  Whatever the decisions made it wouldn’t be great to see that rationale and the external effects reflected.

Regards

Jon

Jon Geater
Chief Technology Officer, Jitsuin
+44 7500 786537


Re: Hyperledger Besu Proposal is Live

Jon Geater
 

Thanks Vipin, that does bring some clear points to draw the discussion around.  However if you consider the parallel thread about architecture it’s quite possible to see these virtues as vices.

If we want to have pluggable consensus, widespread proper use of Ursa and all those other great things that adoption of the Hyperledger code bases promises then at some point we need to have architectural constraints and adherence throughout all the frameworks and projects.  Early on, the more overlapping co-opetitive projects we add the better: competition drives quality and features and ideas.  But as time goes on and numbers grow it can lead to fragmentation, redundant work, and lower overall progress.  Especially if (as is almost inevitable with multiple projects with different provenance) they have a different idea of where architectural layers should be drawn and where the functional responsibilities of major objects lie.  That’s the path to adapters, proxies and so on, which is in turn a path to potential problems.

I’ve worked at the leading edge of large technology ecosystems for a long time now and something that constantly comes up is that there is ‘good differentiation’, where different offerings provide stability and choice to consumers while competing on niche or value-add offers; and ‘bad differentiation’, where suppliers compromise consumer choice by insisting on being different in layers that should be standardised and enabling.  This is not just about standardizing APIs or protocols: it’s also all around the peripheral stuff: keeping documentation up to date; learning and deploying management systems and administrative functionality; differences in system design assumptions that lead to subtle operational problems; differences in cryptographic design assumptions that lead to subtle security problems; etc.  

I don’t want to seem negative, either towards new proposals in general, or Besu in particular. But to address your first bullet, when you have a mission and a stable of existing projects, ‘technical merit’ is not an absolute, objective, or independent measure.  It’s absolutely right that we discuss the technical fit and feature overlap of new projects with old, including the ‘gymnastic’ aspects, because it might be (as others have noted) that we _should_ accept the new thing but should then also guide older things in different directions so as not to ride too many horses in the same race.

We’re discussing TCF next week.  I won’t write much about that here because it’s such a huge (different) topic.  But imagine trying to write a proper threat analysis or system composition or whatever if everylayer of every one of those stacks had differently opinionated versions of the same concepts.  It would make a great Ph.D. thesis but it won’t catch on.

Again, not against Besu at all.  The mature, stable, battle-hardened aspects you mention are great strengths, we need those.  All I’m trying to say is that we can’t make these decisions in isolation and as Hyperledger we do need to judge proposals against consistent technical principles across all the projects and frameworks, otherwise we’re not a community and force multiplier, we’re just a giant repo.  Whatever the decisions made it wouldn’t be great to see that rationale and the external effects reflected.

Regards

Jon

Jon Geater
Chief Technology Officer, Jitsuin
+44 7500 786537


Re: Hyperledger Besu Proposal is Live

Vipin Bharathan
 

Hello all,

The current discussion focusing on the main differentiators of Besu is missing the point.

Two camps: one asserting that these differentiators are not compelling enough to welcome Besu, another that they justify welcoming Besu into hyperledger.
  • Evaluate the proposal on its technical merits. Even if some solutions under the HL greenhouse have similar features (like the Identity binding to the Enterprise), the implementation inside Besu seems different enough. 
  • Many of the emergent effects are unknown at this point (notwithstanding the elaborate technical gymnastics in the current thread). 
  • Given that they are bringing in a code-base, battle tested and with diverse contributors from an active ecosystem, we should be welcoming Besu
  • Besu will strengthen the spirit of co-opetition already alive in Hyperledger
Best,
Vipin

On Fri, Aug 23, 2019 at 9:36 AM Silas Davis via Lists.Hyperledger.Org <silas=monax.io@...> wrote:
Okay this is interesting, thanks Richard. Firstly:

> Like I said near the start, I know my position as CTO of a firm with an open source permissioned blockchain means what I write can’t be seen as unbiased.

Ha. For the record I have the same biases for the same reasons. So good to tease apart why we each tend towards different conclusions. Though it sounds like neither of us are exactly concluded on this. I would agree with your remarks on traditional BFT research and your ambivalence towards PoW security assurances. Though I do think there are unique properties of an physically decentralised network.

I substantially agree with your premises so I'll only pick up one ones I would adjust or challenge.

> the economics are such that the relevant participants are usually relatively few in number…. possibly far fewer than would participate in a robust traditional BFT cluster!

There is clearly an awkward level of centralisation in bitcoin mining pools, but I'm not aware of any good evidence on how concentrated that power is. Also in a permissionless system if centralisation becomes a problem it _is_ possible for more hashing power to come online - without any permission from existing validators unlike the permissioned case.

> First: notice how the permissionless approach to consensus says nothing about security. It is primarily about censorship-resistance.

Having the possibility of an unbounded validator set does say something about security - this is effectively related to being permissionless (and also requires asynchronicity with eventual agreement).

> It is primarily about censorship-resistance.

Censorship-resistance sounds rather more fringe than network neutrality -- which is also what it is -- which is a useful feature of a public network.

Let's also put aside debates about the current levels of centralisation of PoW networks and assume we can use the laws of physics and economics to achieve some distribution of validator power with a permissionless chain that avoids collusion better than any authority-based chain. I'm not saying I know the optimal way to do this, but I don't find it unreasonable. If you have such a system then I believe you can make it more tamper resistant than any other chain. And if so it makes sense to start discovery of the world state from there. Thus the layer 1 to layer 2 idea. It's still only as good as the information stored there and by whom, but at least you can trust its the least likely system to have had its history rewritten. In principle.

> With respect to interchain-connectivity (proving A happened before B on different networks), isn’t that almost a perfect example of where a permissionless chain would be the wrong choice?

I don't think I was very clear here. I had two situations in mind.

Firstly where you want an ordering between a and b but you _don't care_ what it is. Not proving a happened before b, but just establish an order by letting them race. The point is not that you prove one happened before the other, but for some reason it is important that the world agrees that there _is an ordering_ for those events. For example we may want to take the first 10 pairs of such events, they can be data-wise unrelated but it is important they have a canonical order across all sidechains. I'll admit that in some circumstances you would be able canonicalise base on convention, e.g. by sorting for example, but they still need to be shared somewhere. You may also have some reduction step (as in map-reduce) and that has to happen the same way for everyone. I posit a public chain is a good place for that.

Secondly and I think more importantly, consider two transactions that initially do not depend on each other (they come from separate blockchains), but in some grander scheme _ought_ to depend on one another, and you want to establish that ordering (or more generally the combination/result of them). The decision on how they should depend on each other, or indeed how a set of initially independent transactions ought to depend on each other, is a service provide by mainnet (or perhaps just the 'next chain up'; let's call it the 'reducing chain'). This may involve some kind of resolution among a batch of transactions/state updates.

I may shoot myself in the foot here, but let me try and expand the contrivance of my shipping/insurance example I gave previously. Suppose we have 3 separate networks - one concerned with chartering vessels, one concerned with insuring things, and once concerned with shipping goods. Suppose each works independently (<hand-wave>efficiency</hand-wave>) producing streams of: boats that are available of different capacities, packages of risk category/money allocations with which to insure things, and palettes of goods of different values and fragilities respectively. At least these are the resultant transactions they choose to escalate to the reducing chain (they presumably have lots of other supporting transactions in their own domains that they keep to themselves). On our reducing chain we have a smart contract concerned with a tripartite matching of boats, insurance, and goods. Presumably this contract would look a bit like a bid/offer system but with some potentially complicated rules. This would be an example of the reducing chain establishing an ordering and a matching via a resolution mechanism.

What I'm describing is just a tree-shaped structure of chains or a hub-and-spoke model. It is not at all specific to permissionless chains (it's what Tendermint's Cosmos proposal entails for example). My argument is if we think this tree-shaped way of connecting chains makes sense, then trees terminate at a root, and that root is logically mainnet.

> One transaction depend on the other to force an ordering then you already have your proof of ordering and so why do you need the blockchain?

As above, my premise ought to have been not that we have an existing data dependency, but we would like to establish one (if this naturally falls out of your problem, then yay we do not need to pay for consensus as you say). We may even not know which other dependencies are relevant (on mainnet) - we just fire our externally relevant transactions into coordination contracts on the reducing chain.

> wouldn’t a platform that includes probabilistic finality and treats reorgs as a normal part of business be the perfect tool to let them perform their dastardly deeds?

I think systems with probabilistic finality do not treat reorgs as a normal part of business at all. I think they consider that a fork. If they are working as intended under the assumption of number byzantine actors, then after a sufficient number of blocks state can be considered final since probability of reversal goes off like a Poisson distribution. You may have to wait a while depending on block times. Just like you can effectively rely on uuids not colliding. If your hash function is broken that's a different question. I'm also not saying that current consensus networks aren't broken (as you allude to with centralisation), but if their assumptions are actually met then it should work. Being broken is not a normal state of affairs.

> With respect to announcements, is the idea here that the public chain is being used as a way to reassure yourself that there is no newer announcement from any given party… ie that you’re looking at the most current publication about a certain topic from somebody?  If so, I agree that’s a highly desirable service to have as part of a solution design if one were available. But, again, isn’t it something that a permissionless chain is singularly bad at providing?

Yes I agree, this is exactly the domain of synchronous or partially synchronous consensus.

Though, for the purposes of announcing state root and validator hashes it is good enough that we know everyone will see the same value tagged with a particular height when they do eventually see it, and we don't really care about propagation time.
If they are trying to verify these values for a height later than that they can see, they will just wait. I think this generalises to checking any state sidechain that is viewstamped by height. I happen to think this is a very powerful pattern.

> as opposed to enabling business-focused use-cases to be deployed directly onto a permissionless chain.

(sorry for mangling the order of your original statements here, but it suits me better :) )

Not everyone feels this way, but I certainly do. For the record I don't think anything very interesting happens on mainnet in this world view (which is why Ethereum as a 'world computer' doesn't chime with me at all), I think it is mostly a dumb system of record, largely consisting of opaque hash identifiers with some smart contracts doing a few things at the margins.

Thanks for the opportunity to think about and discuss these things. I definitely don't have finality on most of these topics -- I'm not even that far down the asymptote -- so I appreciate the discussion.

Silas

On Fri, 23 Aug 2019 at 12:12, Richard G Brown (R3) via Lists.Hyperledger.Org <richard=r3.com@...> wrote:

(sorry if this is duplicated - the submission from my mail client was rejected I think)

Hi Silas,

 

Thanks for this write-up; I found it helpful.

 

All,

 

I hope nobody minds my joining this discussion but I think the framing of the proposed contribution of Besu provides the opportunity for a timely technical/architectural debate. In particular, I understand that the basis of the proposed contribution (the ‘net-new capability this contribution would make to Hyperledger’, so to speak) is the Besu client’s ability to talk to the public Ethereum network – and that, by implication, this would be of value to a project whose mission is to: “create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions.”

 

I regularly see claims online that connecting a “private” or “permissioned” blockchain to a “mainnet” can provide benefits but I’ve always struggled to understand exactly what those benefits would be. The problem, I think, is that Tweets and Medium articles aren’t really the place for nuanced technical discussion.  Hence why this very narrowly focused proposal in this forum is such an opportunity.

 

I know there can be emotion and I am obviously not unbiased so in what follows I’ll try to keep the discussion generic as I try to outline what I don’t understand – and ask for help in figuring out what I’m missing.  

 

First – let’s check we have similar mental models.  For me, the whole permissioned/permissionless thing is solely about transaction confirmation. Specifically: who are the entities that take place in the consensus forming process for a network and how is their participation decided? We often call these entities validators but I think that’s unhelpful… their primary role is transaction ordering/confirmation, not validation… validation is the responsibility of a much larger group (‘full nodes’ in most architectures). Assuming this focus on “who decides if a transaction gets confirmed or not” is at the absolute heart of things then we can tease out some distinctions.

 

In a ‘permissioned’ chain such as Fabric or Corda, traditional consensus theory is applied. The participants in the network agree to utilise the services of some number of actors who will collaborate to confirm transactions. These actors could be assumed to be entirely trustworthy or BFT-style assumptions may be made that some proportion could be malicious. The key point is that the number of actors is known and the network participants go to lengths to ensure the actors are not sybils, etc.  And, as a result, ‘traditional’ consensus research can be applied. This approach is not without its downsides (of course) but it has an important property of importance to business: once a transaction is marked as confirmed it will stay confirmed. And it is a fault of the system if this property does not hold. 

 

The starting point for ‘permissionless’ blockchains, by contrast – and we can trace this all the way back to Bitcoin – is that agreeing on a known set of transaction confirmers makes it impossible to build censorship-resistant networks. Bluntly, if you know who the transaction confirmers are, then so do the authorities. And so they can be shut down or pressured to censor/delete transactions.  So if you have a desire to build a solution where those in authority can not prevail on transaction confirmers to bend to their will, you need a design where the set of transaction confirmers is unknown – unknown in terms of who they are and how many there are, and where they can come and go at will. This means that the consensus algorithms developed over previous decades can’t be used and Satoshi’s genius was to devise a totally new way of solving the problem. However, the rules of mathematics and computer science didn’t change with the advent of Bitcoin. Instead, a requirement was softened. That requirement was finality.  If we are willing to accept the probability that a transaction could sometimes go from “confirmed” to “unconfirmed” then a whole world of possibility opens up and techniques such as Proof of Work become possible.  This was an amazing insight and most of us are probably in this space today because of it and its implications.

 

But… this probabilistic finality situation is annoying, of course. Like I said to John Wolpert of ConsenSys on a podcast a while back, if there wasa permissionless system that truly gave me finality and over which I could reason about concentration/collusion risk, etc., I’d probably be abuyer of such a thing.  But there isn’t and so I can’t.  It’s as if we’re in this annoying situation where there’s something we’d all like to be true… but the universe is conspiring against us to make it just not so!

 

Now… assuming my (hopefully not over-simplistic) model is broadly OK then we can observe a few things.

 

First: notice how the permissionless approach to consensus says nothing about security. It is primarily about censorship-resistance. This is especially important to note because the last ten years have shown that, whilst it is possible to build consensus systems where the participants can come and go at will without permission, the economics are such that the relevant participants are usually relatively few in number…. possibly far fewer than would participate in a robust traditional BFT cluster!   Note: this is not a comment about the security of any given client implementation (I fully agree that code such as geth has clearly been battle-tested). The security question is one about how many people you have to hack to take over the consensus forming process.  If there are 21 unique participants in a Fabric BFT cluster and five miners with 80+% of the hashing power for a PoW blockchain, I would submit that it would be easier to subvert the latter chain than the former. (Note: you don’t need to hack the Fabric or Geth clients to take over confirmation processing for a network… you simply need to gain control of whichever systems are controlling the miners’ infrastructures… a Linux kernel vulnerability or somebody willing to kidnap the miners’ families might be all you need).   So I’m unpersuaded by security arguments for or against a permissioned or permissionless approach in terms of compromises to transaction confirmation integrity.  It ultimately all comes down to whether you need censorship resistance or not.

 

Secondly: experience has shown us that whilst we’d like to believe the probability of a transaction reversal on permissionless chains trends asymptotically to zero quickly, in reality there are occasional events far out in the tail that make analysis and engineering extremely difficult…. eg the Ethereum Classic 100+ block reorg a while back. 

 

So the piece I’ve always struggled with – and which I hope this discussion can help open my eyes to is:  if I don’t have the need for censorship-resistance in transaction confirmation for my business problem – or if it’s an anti-requirement for my problem, what’s the argument for why I would use a permissionless chain?  It strikes me that there are lots of downsides and no obvious upsides.

 

That said, the discussions below seem mostly to be about bridging or integrating the permissionless and permissioned worlds, as opposed to enabling business-focused use-cases to be deployed directly onto a permissionless chain.  But if the discussion is primarily only about integration/bridging that then makes me scratch my head even harder. If I look at Silas’s use-cases (thanks again btw… this is the first time I’ve seen them enumerated so clearly), I’ll disregard 1) and 3) for the purposes of this discussion since I’m only really qualified to talk about the business problems I see in my work, none of which involve usage of eth.

 

Which leaves me with: announcements and interchain-connectivity.

 

With respect to interchain-connectivity (proving A happened before B on different networks), isn’t that almost a perfect example of where a permissionless chain would be the wrong choice?  The two independent transactions could be reordered in the event of a reorg and it would not be a fault… it would be the system working as designed.  But if you sought to overcome this by making one transaction depend on the other to force an ordering then you already have your proof of ordering and so why do you need the blockchain?

 

With respect to announcements, is the idea here that the public chain is being used as a way to reassure yourself that there is no newer announcement from any given party… ie that you’re looking at the most current publication about a certain topic from somebody?  If so, I agree that’s a highly desirable service to have as part of a solution design if one were available. But, again, isn’t it something that a permissionless chain is singularly bad at providing? If your threat model admits the possibility that the publisher would try to deceive you about the most currently published document, wouldn’t a platform that includes probabilistic finality and treats reorgs as a normal part of business be the perfect tool to let them perform their dastardly deeds? It would seem that the correct architectural solution would be something like a widely-witnessed proof-of-existence service, such as Guardtime’s offering that publishes merkle roots in a national newspaper.

 

Like I said near the start, I know my position as CTO of a firm with an open source permissioned blockchain means what I write can’t be seen as unbiased. So I’ve tried my hardest to write objectively and constructively and to avoid setting up strawmen (hence the laboured permissioned/permissionless section so you can ‘see my working’). 

 

There has been so much noise and ‘people talking past each other’ at the boundary of permissioned and permissionless chains… and so, done right, this debate could be something we look back on as a milestone in really nailing some of these concepts.  

 

Richard

 

Richard G Brown R3. | Chief Technology Officer

2 London Wall Place | Floor 12 | London | EC2Y 5AU

richard@... . www.r3.com


Re: Hyperledger Besu Proposal is Live

Richard Brown <richard@...>
 

Hi Silas,

 

Thanks for this write-up; I found it helpful.

 

All,

 

I hope nobody minds my joining this discussion but I think the framing of the proposed contribution of Besu provides the opportunity for a timely technical/architectural debate. In particular, I understand that the basis of the proposed contribution (the ‘net-new capability this contribution would make to Hyperledger’, so to speak) is the Besu client’s ability to talk to the public Ethereum network – and that, by implication, this would be of value to a project whose mission is to: “create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions.”

 

I regularly see claims online that connecting a “private” or “permissioned” blockchain to a “mainnet” can provide benefits but I’ve always struggled to understand exactly what those benefits would be. The problem, I think, is that Tweets and Medium articles aren’t really the place for nuanced technical discussion.  Hence why this very narrowly focused proposal in this forum is such an opportunity.

 

I know there can be emotion and I am obviously not unbiased so in what follows I’ll try to keep the discussion generic as I try to outline what I don’t understand – and ask for help in figuring out what I’m missing.  

 

First – let’s check we have similar mental models.  For me, the whole permissioned/permissionless thing is solely about transaction confirmation. Specifically: who are the entities that take place in the consensus forming process for a network and how is their participation decided? We often call these entities validators but I think that’s unhelpful… their primary role is transaction ordering/confirmation, not validation… validation is the responsibility of a much larger group (‘full nodes’ in most architectures). Assuming this focus on “who decides if a transaction gets confirmed or not” is at the absolute heart of things then we can tease out some distinctions.

 

In a ‘permissioned’ chain such as Fabric or Corda, traditional consensus theory is applied. The participants in the network agree to utilise the services of some number of actors who will collaborate to confirm transactions. These actors could be assumed to be entirely trustworthy or BFT-style assumptions may be made that some proportion could be malicious. The key point is that the number of actors is known and the network participants go to lengths to ensure the actors are not sybils, etc.  And, as a result, ‘traditional’ consensus research can be applied. This approach is not without its downsides (of course) but it has an important property of importance to business: once a transaction is marked as confirmed it will stay confirmed. And it is a fault of the system if this property does not hold. 

 

The starting point for ‘permissionless’ blockchains, by contrast – and we can trace this all the way back to Bitcoin – is that agreeing on a known set of transaction confirmers makes it impossible to build censorship-resistant networks. Bluntly, if you know who the transaction confirmers are, then so do the authorities. And so they can be shut down or pressured to censor/delete transactions.  So if you have a desire to build a solution where those in authority can not prevail on transaction confirmers to bend to their will, you need a design where the set of transaction confirmers is unknown – unknown in terms of who they are and how many there are, and where they can come and go at will. This means that the consensus algorithms developed over previous decades can’t be used and Satoshi’s genius was to devise a totally new way of solving the problem. However, the rules of mathematics and computer science didn’t change with the advent of Bitcoin. Instead, a requirement was softened. That requirement was finality.  If we are willing to accept the probability that a transaction could sometimes go from “confirmed” to “unconfirmed” then a whole world of possibility opens up and techniques such as Proof of Work become possible.  This was an amazing insight and most of us are probably in this space today because of it and its implications.

 

But… this probabilistic finality situation is annoying, of course. Like I said to John Wolpert of ConsenSys on a podcast a while back, if there was a permissionless system that truly gave me finality and over which I could reason about concentration/collusion risk, etc., I’d probably be a buyer of such a thing.  But there isn’t and so I can’t.  It’s as if we’re in this annoying situation where there’s something we’d all like to be true… but the universe is conspiring against us to make it just not so!

 

Now… assuming my (hopefully not over-simplistic) model is broadly OK then we can observe a few things.

 

First: notice how the permissionless approach to consensus says nothing about security. It is primarily about censorship-resistance. This is especially important to note because the last ten years have shown that, whilst it is possible to build consensus systems where the participants can come and go at will without permission, the economics are such that the relevant participants are usually relatively few in number…. possibly far fewer than would participate in a robust traditional BFT cluster!   Note: this is not a comment about the security of any given client implementation (I fully agree that code such as geth has clearly been battle-tested). The security question is one about how many people you have to hack to take over the consensus forming process.  If there are 21 unique participants in a Fabric BFT cluster and five miners with 80+% of the hashing power for a PoW blockchain, I would submit that it would be easier to subvert the latter chain than the former. (Note: you don’t need to hack the Fabric or Geth clients to take over confirmation processing for a network… you simply need to gain control of whichever systems are controlling the miners’ infrastructures… a Linux kernel vulnerability or somebody willing to kidnap the miners’ families might be all you need).   So I’m unpersuaded by security arguments for or against a permissioned or permissionless approach in terms of compromises to transaction confirmation integrity.  It ultimately all comes down to whether you need censorship resistance or not.

 

Secondly: experience has shown us that whilst we’d like to believe the probability of a transaction reversal on permissionless chains trends asymptotically to zero quickly, in reality there are occasional events far out in the tail that make analysis and engineering extremely difficult…. eg the Ethereum Classic 100+ block reorg a while back. 

 

So the piece I’ve always struggled with – and which I hope this discussion can help open my eyes to is:  if I don’t have the need for censorship-resistance in transaction confirmation for my business problem – or if it’s an anti-requirement for my problem, what’s the argument for why I would use a permissionless chain?  It strikes me that there are lots of downsides and no obvious upsides.

 

That said, the discussions below seem mostly to be about bridging or integrating the permissionless and permissioned worlds, as opposed to enabling business-focused use-cases to be deployed directly onto a permissionless chain.  But if the discussion is primarily only about integration/bridging that then makes me scratch my head even harder. If I look at Silas’s use-cases (thanks again btw… this is the first time I’ve seen them enumerated so clearly), I’ll disregard 1) and 3) for the purposes of this discussion since I’m only really qualified to talk about the business problems I see in my work, none of which involve usage of eth.

 

Which leaves me with: announcements and interchain-connectivity.

 

With respect to interchain-connectivity (proving A happened before B on different networks), isn’t that almost a perfect example of where a permissionless chain would be the wrong choice?  The two independent transactions could be reordered in the event of a reorg and it would not be a fault… it would be the system working as designed.  But if you sought to overcome this by making one transaction depend on the other to force an ordering then you already have your proof of ordering and so why do you need the blockchain?

 

With respect to announcements, is the idea here that the public chain is being used as a way to reassure yourself that there is no newer announcement from any given party… ie that you’re looking at the most current publication about a certain topic from somebody?  If so, I agree that’s a highly desirable service to have as part of a solution design if one were available. But, again, isn’t it something that a permissionless chain is singularly bad at providing? If your threat model admits the possibility that the publisher would try to deceive you about the most currently published document, wouldn’t a platform that includes probabilistic finality and treats reorgs as a normal part of business be the perfect tool to let them perform their dastardly deeds? It would seem that the correct architectural solution would be something like a widely-witnessed proof-of-existence service, such as Guardtime’s offering that publishes merkle roots in a national newspaper.

 

Like I said near the start, I know my position as CTO of a firm with an open source permissioned blockchain means what I write can’t be seen as unbiased. So I’ve tried my hardest to write objectively and constructively and to avoid setting up strawmen (hence the laboured permissioned/permissionless section so you can ‘see my working’). 

 

There has been so much noise and ‘people talking past each other’ at the boundary of permissioned and permissionless chains… and so, done right, this debate could be something we look back on as a milestone in really nailing some of these concepts.  

 

Richard

 

Richard G Brown R3. | Chief Technology Officer

2 London Wall Place | Floor 12 | London | EC2Y 5AU

richard@... . www.r3.com

 

From: <tsc@...> on behalf of "Silas Davis via Lists.Hyperledger.Org" <silas=monax.io@...>
Reply to: "silas@..." <silas@...>
Date: Thursday, 22 August 2019 at 14:17
To: "Middleton, Dan" <dan.middleton@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live

 

> 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.

 

This quite a big topic, but I will give some examples I like.

 

First its worth noting for all of these use cases what is interesting is not just being able to 'do it on mainnet' -- anyone can send transactions to Ethereum from bash -- but rather having mainnet connectivity. The strongest for of this would be that a quorum (ideally any quorum) of your validators are jointly responsible for issuing transactions (via some kind of multisig on mainnet) and checking state on return (via multisig on sidechain). Lesser forms of connectivity might be via 'trusted' third parties or even a single service (i.e. an ethereum oracle). The effect could be the same, but in the weaker forms you have thrown away much of you byzantine tolerance. Ideally you want the same threshold for state changes on the sidechain as for state changes to the relevant contracts on mainnet. If all you require is a proof that a transaction was included (i.e. account X has placed a bond) rather than joint custody of an asset (i.e. paying out from the sidechain's reserve contract - where (super-)majority of validators must agree) then you can get away without quorum at the expense of liveness. To do this kind of strong connectivity it is helpful for validators on both sides (mainnet and sidechain) to be aware of each other. This is where Pantheon could help Burrow for instance - by pushing state back to us rather than us pulling - where a Burrow chain's validators would hold accounts on mainnet, and a validator pool from mainnet would hold accounts on the burrow sidechain. This isn't something we could get go-ethereum to do, but we might persuade Pantheon to provide this intermediate layer.

 

1. Bond-holding and value transfer.

This probably the most obvious one. Since eth is worth something you can pay people in it. In particular you may want to run micro-transactions on your chain that are secured against a bond placed on ethereum. In order to guarantee the bond you need to be able to observe that a reserve of funds are locked on mainnet, you also need to be able to atomically swap them which is where you need connectivity. For proof-of-stake chains on Burrow you can ask entities wishing to validate to store bond on mainnet, credit them with validator power on Burrow, and if necessary in the case of validator unavailability or equivocation to slash part of their bond on mainnet. We would like all of these actions to be under control of a quorum of validators on the Burrow chain. We can fudge it now, but proper connectivity is what we would like to do it well.

 

2. Announcement and light clients

I think your receipt log example would come under this bracket. The most interesting to me is announcing state hash, validator set hash, and seed location for a Burrow (or other) network. If I am a participant or validator wanting to join a Burrow network I would like to find out a recent snapshot of the validator set (their public keys) and also how I can connect to them. I could trust, say, Monax to tell me but I'd rather use Ethereum as a public system of announcement. If the validator set hash and state hash is updated in a timely fashion, as a light client I can use it to verify merkle proofs issued by a Burrow node without trusting that Burrow node so long as the history of the state root hash was updated by a quorum of validators periodically (and >1/3 of the set hasn't changed since the last update). This is great because I don't have to validator the entire Burrow network

 

3. Counter-factual instantiation

This language comes from 'state channels'. If we consider a sidechain as a kind of state channel with its own consensus where some counterparties can more quickly transact than they can on mainnet then they can go about their business issuing signed incremental transactions that would also be valid on mainnet. This works for micro-payments but can be generalised to any state where you have a rule that says the highest sequence number is valid. If the participants on the sidechain have a dispute they can all submit their latest transactions and an ethereum contract can adjudicate. At worst a participant on the sidechain only loses out on state since the last checkpoint they were okay with (e.g. before the sidechain suffered a sybil attack).

 

4. Inter-chain connectivity

Suppose I have two chains A and B, each chain has a total ordering of its own transactions. If I want to establish a partial ordering between just some transactions on A and B I can do that by instituting some form of meta-consensus on mainnet. This could just be a race if it is unimportant which transaction comes first or it could be some kind of conflict resolution. For example if my chain A is managing bills of lading for shipping and wants to issue an insurance agreement (b) on my agreements network B for a consignment (a). We can transact away on A building the bill of lading and follow a formation and signing process for the agreement on B before finally submitting an transaction on mainnet that defines the insurance agreement as executed _before_ the bill of lading is accepted. The transaction 'b then a' on mainnet is a kind of stronger guarantee that you were insured before you shipped (than say timestamps) - and it's also a public record of the fact. You then only pay the price of cross-chain consensus for transactions that need to depend on each other.

 

I don't share all of the fervour, and I'm not quite so bullish on Ethereum (though it does have that big advantage of being a thing right now...), but I think the following blog provides quite a nice frame for thinking about possible relationships between mainnet and permissioned networks:

 

 

Silas

 

On Wed, 21 Aug 2019 at 20:08, Middleton, Dan <dan.middleton@...> wrote:

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 Besu Proposal is Live

Silas Davis
 

Okay this is interesting, thanks Richard. Firstly:

> Like I said near the start, I know my position as CTO of a firm with an open source permissioned blockchain means what I write can’t be seen as unbiased.

Ha. For the record I have the same biases for the same reasons. So good to tease apart why we each tend towards different conclusions. Though it sounds like neither of us are exactly concluded on this. I would agree with your remarks on traditional BFT research and your ambivalence towards PoW security assurances. Though I do think there are unique properties of an physically decentralised network.

I substantially agree with your premises so I'll only pick up one ones I would adjust or challenge.

> the economics are such that the relevant participants are usually relatively few in number…. possibly far fewer than would participate in a robust traditional BFT cluster!

There is clearly an awkward level of centralisation in bitcoin mining pools, but I'm not aware of any good evidence on how concentrated that power is. Also in a permissionless system if centralisation becomes a problem it _is_ possible for more hashing power to come online - without any permission from existing validators unlike the permissioned case.

> First: notice how the permissionless approach to consensus says nothing about security. It is primarily about censorship-resistance.

Having the possibility of an unbounded validator set does say something about security - this is effectively related to being permissionless (and also requires asynchronicity with eventual agreement).

> It is primarily about censorship-resistance.

Censorship-resistance sounds rather more fringe than network neutrality -- which is also what it is -- which is a useful feature of a public network.

Let's also put aside debates about the current levels of centralisation of PoW networks and assume we can use the laws of physics and economics to achieve some distribution of validator power with a permissionless chain that avoids collusion better than any authority-based chain. I'm not saying I know the optimal way to do this, but I don't find it unreasonable. If you have such a system then I believe you can make it more tamper resistant than any other chain. And if so it makes sense to start discovery of the world state from there. Thus the layer 1 to layer 2 idea. It's still only as good as the information stored there and by whom, but at least you can trust its the least likely system to have had its history rewritten. In principle.

> With respect to interchain-connectivity (proving A happened before B on different networks), isn’t that almost a perfect example of where a permissionless chain would be the wrong choice?

I don't think I was very clear here. I had two situations in mind.

Firstly where you want an ordering between a and b but you _don't care_ what it is. Not proving a happened before b, but just establish an order by letting them race. The point is not that you prove one happened before the other, but for some reason it is important that the world agrees that there _is an ordering_ for those events. For example we may want to take the first 10 pairs of such events, they can be data-wise unrelated but it is important they have a canonical order across all sidechains. I'll admit that in some circumstances you would be able canonicalise base on convention, e.g. by sorting for example, but they still need to be shared somewhere. You may also have some reduction step (as in map-reduce) and that has to happen the same way for everyone. I posit a public chain is a good place for that.

Secondly and I think more importantly, consider two transactions that initially do not depend on each other (they come from separate blockchains), but in some grander scheme _ought_ to depend on one another, and you want to establish that ordering (or more generally the combination/result of them). The decision on how they should depend on each other, or indeed how a set of initially independent transactions ought to depend on each other, is a service provide by mainnet (or perhaps just the 'next chain up'; let's call it the 'reducing chain'). This may involve some kind of resolution among a batch of transactions/state updates.

I may shoot myself in the foot here, but let me try and expand the contrivance of my shipping/insurance example I gave previously. Suppose we have 3 separate networks - one concerned with chartering vessels, one concerned with insuring things, and once concerned with shipping goods. Suppose each works independently (<hand-wave>efficiency</hand-wave>) producing streams of: boats that are available of different capacities, packages of risk category/money allocations with which to insure things, and palettes of goods of different values and fragilities respectively. At least these are the resultant transactions they choose to escalate to the reducing chain (they presumably have lots of other supporting transactions in their own domains that they keep to themselves). On our reducing chain we have a smart contract concerned with a tripartite matching of boats, insurance, and goods. Presumably this contract would look a bit like a bid/offer system but with some potentially complicated rules. This would be an example of the reducing chain establishing an ordering and a matching via a resolution mechanism.

What I'm describing is just a tree-shaped structure of chains or a hub-and-spoke model. It is not at all specific to permissionless chains (it's what Tendermint's Cosmos proposal entails for example). My argument is if we think this tree-shaped way of connecting chains makes sense, then trees terminate at a root, and that root is logically mainnet.

> One transaction depend on the other to force an ordering then you already have your proof of ordering and so why do you need the blockchain?

As above, my premise ought to have been not that we have an existing data dependency, but we would like to establish one (if this naturally falls out of your problem, then yay we do not need to pay for consensus as you say). We may even not know which other dependencies are relevant (on mainnet) - we just fire our externally relevant transactions into coordination contracts on the reducing chain.

> wouldn’t a platform that includes probabilistic finality and treats reorgs as a normal part of business be the perfect tool to let them perform their dastardly deeds?

I think systems with probabilistic finality do not treat reorgs as a normal part of business at all. I think they consider that a fork. If they are working as intended under the assumption of number byzantine actors, then after a sufficient number of blocks state can be considered final since probability of reversal goes off like a Poisson distribution. You may have to wait a while depending on block times. Just like you can effectively rely on uuids not colliding. If your hash function is broken that's a different question. I'm also not saying that current consensus networks aren't broken (as you allude to with centralisation), but if their assumptions are actually met then it should work. Being broken is not a normal state of affairs.

> With respect to announcements, is the idea here that the public chain is being used as a way to reassure yourself that there is no newer announcement from any given party… ie that you’re looking at the most current publication about a certain topic from somebody?  If so, I agree that’s a highly desirable service to have as part of a solution design if one were available. But, again, isn’t it something that a permissionless chain is singularly bad at providing?

Yes I agree, this is exactly the domain of synchronous or partially synchronous consensus.

Though, for the purposes of announcing state root and validator hashes it is good enough that we know everyone will see the same value tagged with a particular height when they do eventually see it, and we don't really care about propagation time.
If they are trying to verify these values for a height later than that they can see, they will just wait. I think this generalises to checking any state sidechain that is viewstamped by height. I happen to think this is a very powerful pattern.

> as opposed to enabling business-focused use-cases to be deployed directly onto a permissionless chain.

(sorry for mangling the order of your original statements here, but it suits me better :) )

Not everyone feels this way, but I certainly do. For the record I don't think anything very interesting happens on mainnet in this world view (which is why Ethereum as a 'world computer' doesn't chime with me at all), I think it is mostly a dumb system of record, largely consisting of opaque hash identifiers with some smart contracts doing a few things at the margins.

Thanks for the opportunity to think about and discuss these things. I definitely don't have finality on most of these topics -- I'm not even that far down the asymptote -- so I appreciate the discussion.

Silas


On Fri, 23 Aug 2019 at 12:12, Richard G Brown (R3) via Lists.Hyperledger.Org <richard=r3.com@...> wrote:

(sorry if this is duplicated - the submission from my mail client was rejected I think)

Hi Silas,

 

Thanks for this write-up; I found it helpful.

 

All,

 

I hope nobody minds my joining this discussion but I think the framing of the proposed contribution of Besu provides the opportunity for a timely technical/architectural debate. In particular, I understand that the basis of the proposed contribution (the ‘net-new capability this contribution would make to Hyperledger’, so to speak) is the Besu client’s ability to talk to the public Ethereum network – and that, by implication, this would be of value to a project whose mission is to: “create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions.”

 

I regularly see claims online that connecting a “private” or “permissioned” blockchain to a “mainnet” can provide benefits but I’ve always struggled to understand exactly what those benefits would be. The problem, I think, is that Tweets and Medium articles aren’t really the place for nuanced technical discussion.  Hence why this very narrowly focused proposal in this forum is such an opportunity.

 

I know there can be emotion and I am obviously not unbiased so in what follows I’ll try to keep the discussion generic as I try to outline what I don’t understand – and ask for help in figuring out what I’m missing.  

 

First – let’s check we have similar mental models.  For me, the whole permissioned/permissionless thing is solely about transaction confirmation. Specifically: who are the entities that take place in the consensus forming process for a network and how is their participation decided? We often call these entities validators but I think that’s unhelpful… their primary role is transaction ordering/confirmation, not validation… validation is the responsibility of a much larger group (‘full nodes’ in most architectures). Assuming this focus on “who decides if a transaction gets confirmed or not” is at the absolute heart of things then we can tease out some distinctions.

 

In a ‘permissioned’ chain such as Fabric or Corda, traditional consensus theory is applied. The participants in the network agree to utilise the services of some number of actors who will collaborate to confirm transactions. These actors could be assumed to be entirely trustworthy or BFT-style assumptions may be made that some proportion could be malicious. The key point is that the number of actors is known and the network participants go to lengths to ensure the actors are not sybils, etc.  And, as a result, ‘traditional’ consensus research can be applied. This approach is not without its downsides (of course) but it has an important property of importance to business: once a transaction is marked as confirmed it will stay confirmed. And it is a fault of the system if this property does not hold. 

 

The starting point for ‘permissionless’ blockchains, by contrast – and we can trace this all the way back to Bitcoin – is that agreeing on a known set of transaction confirmers makes it impossible to build censorship-resistant networks. Bluntly, if you know who the transaction confirmers are, then so do the authorities. And so they can be shut down or pressured to censor/delete transactions.  So if you have a desire to build a solution where those in authority can not prevail on transaction confirmers to bend to their will, you need a design where the set of transaction confirmers is unknown – unknown in terms of who they are and how many there are, and where they can come and go at will. This means that the consensus algorithms developed over previous decades can’t be used and Satoshi’s genius was to devise a totally new way of solving the problem. However, the rules of mathematics and computer science didn’t change with the advent of Bitcoin. Instead, a requirement was softened. That requirement was finality.  If we are willing to accept the probability that a transaction could sometimes go from “confirmed” to “unconfirmed” then a whole world of possibility opens up and techniques such as Proof of Work become possible.  This was an amazing insight and most of us are probably in this space today because of it and its implications.

 

But… this probabilistic finality situation is annoying, of course. Like I said to John Wolpert of ConsenSys on a podcast a while back, if there wasa permissionless system that truly gave me finality and over which I could reason about concentration/collusion risk, etc., I’d probably be abuyer of such a thing.  But there isn’t and so I can’t.  It’s as if we’re in this annoying situation where there’s something we’d all like to be true… but the universe is conspiring against us to make it just not so!

 

Now… assuming my (hopefully not over-simplistic) model is broadly OK then we can observe a few things.

 

First: notice how the permissionless approach to consensus says nothing about security. It is primarily about censorship-resistance. This is especially important to note because the last ten years have shown that, whilst it is possible to build consensus systems where the participants can come and go at will without permission, the economics are such that the relevant participants are usually relatively few in number…. possibly far fewer than would participate in a robust traditional BFT cluster!   Note: this is not a comment about the security of any given client implementation (I fully agree that code such as geth has clearly been battle-tested). The security question is one about how many people you have to hack to take over the consensus forming process.  If there are 21 unique participants in a Fabric BFT cluster and five miners with 80+% of the hashing power for a PoW blockchain, I would submit that it would be easier to subvert the latter chain than the former. (Note: you don’t need to hack the Fabric or Geth clients to take over confirmation processing for a network… you simply need to gain control of whichever systems are controlling the miners’ infrastructures… a Linux kernel vulnerability or somebody willing to kidnap the miners’ families might be all you need).   So I’m unpersuaded by security arguments for or against a permissioned or permissionless approach in terms of compromises to transaction confirmation integrity.  It ultimately all comes down to whether you need censorship resistance or not.

 

Secondly: experience has shown us that whilst we’d like to believe the probability of a transaction reversal on permissionless chains trends asymptotically to zero quickly, in reality there are occasional events far out in the tail that make analysis and engineering extremely difficult…. eg the Ethereum Classic 100+ block reorg a while back. 

 

So the piece I’ve always struggled with – and which I hope this discussion can help open my eyes to is:  if I don’t have the need for censorship-resistance in transaction confirmation for my business problem – or if it’s an anti-requirement for my problem, what’s the argument for why I would use a permissionless chain?  It strikes me that there are lots of downsides and no obvious upsides.

 

That said, the discussions below seem mostly to be about bridging or integrating the permissionless and permissioned worlds, as opposed to enabling business-focused use-cases to be deployed directly onto a permissionless chain.  But if the discussion is primarily only about integration/bridging that then makes me scratch my head even harder. If I look at Silas’s use-cases (thanks again btw… this is the first time I’ve seen them enumerated so clearly), I’ll disregard 1) and 3) for the purposes of this discussion since I’m only really qualified to talk about the business problems I see in my work, none of which involve usage of eth.

 

Which leaves me with: announcements and interchain-connectivity.

 

With respect to interchain-connectivity (proving A happened before B on different networks), isn’t that almost a perfect example of where a permissionless chain would be the wrong choice?  The two independent transactions could be reordered in the event of a reorg and it would not be a fault… it would be the system working as designed.  But if you sought to overcome this by making one transaction depend on the other to force an ordering then you already have your proof of ordering and so why do you need the blockchain?

 

With respect to announcements, is the idea here that the public chain is being used as a way to reassure yourself that there is no newer announcement from any given party… ie that you’re looking at the most current publication about a certain topic from somebody?  If so, I agree that’s a highly desirable service to have as part of a solution design if one were available. But, again, isn’t it something that a permissionless chain is singularly bad at providing? If your threat model admits the possibility that the publisher would try to deceive you about the most currently published document, wouldn’t a platform that includes probabilistic finality and treats reorgs as a normal part of business be the perfect tool to let them perform their dastardly deeds? It would seem that the correct architectural solution would be something like a widely-witnessed proof-of-existence service, such as Guardtime’s offering that publishes merkle roots in a national newspaper.

 

Like I said near the start, I know my position as CTO of a firm with an open source permissioned blockchain means what I write can’t be seen as unbiased. So I’ve tried my hardest to write objectively and constructively and to avoid setting up strawmen (hence the laboured permissioned/permissionless section so you can ‘see my working’). 

 

There has been so much noise and ‘people talking past each other’ at the boundary of permissioned and permissionless chains… and so, done right, this debate could be something we look back on as a milestone in really nailing some of these concepts.  

 

Richard

 

Richard G Brown R3. | Chief Technology Officer

2 London Wall Place | Floor 12 | London | EC2Y 5AU

richard@... . www.r3.com


Re: Hyperledger Besu Proposal is Live

Richard G Brown (R3) <richard@...>
 

(sorry if this is duplicated - the submission from my mail client was rejected I think)

Hi Silas,

 

Thanks for this write-up; I found it helpful.

 

All,

 

I hope nobody minds my joining this discussion but I think the framing of the proposed contribution of Besu provides the opportunity for a timely technical/architectural debate. In particular, I understand that the basis of the proposed contribution (the ‘net-new capability this contribution would make to Hyperledger’, so to speak) is the Besu client’s ability to talk to the public Ethereum network – and that, by implication, this would be of value to a project whose mission is to: “create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions.”

 

I regularly see claims online that connecting a “private” or “permissioned” blockchain to a “mainnet” can provide benefits but I’ve always struggled to understand exactly what those benefits would be. The problem, I think, is that Tweets and Medium articles aren’t really the place for nuanced technical discussion.  Hence why this very narrowly focused proposal in this forum is such an opportunity.

 

I know there can be emotion and I am obviously not unbiased so in what follows I’ll try to keep the discussion generic as I try to outline what I don’t understand – and ask for help in figuring out what I’m missing.  

 

First – let’s check we have similar mental models.  For me, the whole permissioned/permissionless thing is solely about transaction confirmation. Specifically: who are the entities that take place in the consensus forming process for a network and how is their participation decided? We often call these entities validators but I think that’s unhelpful… their primary role is transaction ordering/confirmation, not validation… validation is the responsibility of a much larger group (‘full nodes’ in most architectures). Assuming this focus on “who decides if a transaction gets confirmed or not” is at the absolute heart of things then we can tease out some distinctions.

 

In a ‘permissioned’ chain such as Fabric or Corda, traditional consensus theory is applied. The participants in the network agree to utilise the services of some number of actors who will collaborate to confirm transactions. These actors could be assumed to be entirely trustworthy or BFT-style assumptions may be made that some proportion could be malicious. The key point is that the number of actors is known and the network participants go to lengths to ensure the actors are not sybils, etc.  And, as a result, ‘traditional’ consensus research can be applied. This approach is not without its downsides (of course) but it has an important property of importance to business: once a transaction is marked as confirmed it will stay confirmed. And it is a fault of the system if this property does not hold. 

 

The starting point for ‘permissionless’ blockchains, by contrast – and we can trace this all the way back to Bitcoin – is that agreeing on a known set of transaction confirmers makes it impossible to build censorship-resistant networks. Bluntly, if you know who the transaction confirmers are, then so do the authorities. And so they can be shut down or pressured to censor/delete transactions.  So if you have a desire to build a solution where those in authority can not prevail on transaction confirmers to bend to their will, you need a design where the set of transaction confirmers is unknown – unknown in terms of who they are and how many there are, and where they can come and go at will. This means that the consensus algorithms developed over previous decades can’t be used and Satoshi’s genius was to devise a totally new way of solving the problem. However, the rules of mathematics and computer science didn’t change with the advent of Bitcoin. Instead, a requirement was softened. That requirement was finality.  If we are willing to accept the probability that a transaction could sometimes go from “confirmed” to “unconfirmed” then a whole world of possibility opens up and techniques such as Proof of Work become possible.  This was an amazing insight and most of us are probably in this space today because of it and its implications.

 

But… this probabilistic finality situation is annoying, of course. Like I said to John Wolpert of ConsenSys on a podcast a while back, if there wasa permissionless system that truly gave me finality and over which I could reason about concentration/collusion risk, etc., I’d probably be abuyer of such a thing.  But there isn’t and so I can’t.  It’s as if we’re in this annoying situation where there’s something we’d all like to be true… but the universe is conspiring against us to make it just not so!

 

Now… assuming my (hopefully not over-simplistic) model is broadly OK then we can observe a few things.

 

First: notice how the permissionless approach to consensus says nothing about security. It is primarily about censorship-resistance. This is especially important to note because the last ten years have shown that, whilst it is possible to build consensus systems where the participants can come and go at will without permission, the economics are such that the relevant participants are usually relatively few in number…. possibly far fewer than would participate in a robust traditional BFT cluster!   Note: this is not a comment about the security of any given client implementation (I fully agree that code such as geth has clearly been battle-tested). The security question is one about how many people you have to hack to take over the consensus forming process.  If there are 21 unique participants in a Fabric BFT cluster and five miners with 80+% of the hashing power for a PoW blockchain, I would submit that it would be easier to subvert the latter chain than the former. (Note: you don’t need to hack the Fabric or Geth clients to take over confirmation processing for a network… you simply need to gain control of whichever systems are controlling the miners’ infrastructures… a Linux kernel vulnerability or somebody willing to kidnap the miners’ families might be all you need).   So I’m unpersuaded by security arguments for or against a permissioned or permissionless approach in terms of compromises to transaction confirmation integrity.  It ultimately all comes down to whether you need censorship resistance or not.

 

Secondly: experience has shown us that whilst we’d like to believe the probability of a transaction reversal on permissionless chains trends asymptotically to zero quickly, in reality there are occasional events far out in the tail that make analysis and engineering extremely difficult…. eg the Ethereum Classic 100+ block reorg a while back. 

 

So the piece I’ve always struggled with – and which I hope this discussion can help open my eyes to is:  if I don’t have the need for censorship-resistance in transaction confirmation for my business problem – or if it’s an anti-requirement for my problem, what’s the argument for why I would use a permissionless chain?  It strikes me that there are lots of downsides and no obvious upsides.

 

That said, the discussions below seem mostly to be about bridging or integrating the permissionless and permissioned worlds, as opposed to enabling business-focused use-cases to be deployed directly onto a permissionless chain.  But if the discussion is primarily only about integration/bridging that then makes me scratch my head even harder. If I look at Silas’s use-cases (thanks again btw… this is the first time I’ve seen them enumerated so clearly), I’ll disregard 1) and 3) for the purposes of this discussion since I’m only really qualified to talk about the business problems I see in my work, none of which involve usage of eth.

 

Which leaves me with: announcements and interchain-connectivity.

 

With respect to interchain-connectivity (proving A happened before B on different networks), isn’t that almost a perfect example of where a permissionless chain would be the wrong choice?  The two independent transactions could be reordered in the event of a reorg and it would not be a fault… it would be the system working as designed.  But if you sought to overcome this by making one transaction depend on the other to force an ordering then you already have your proof of ordering and so why do you need the blockchain?

 

With respect to announcements, is the idea here that the public chain is being used as a way to reassure yourself that there is no newer announcement from any given party… ie that you’re looking at the most current publication about a certain topic from somebody?  If so, I agree that’s a highly desirable service to have as part of a solution design if one were available. But, again, isn’t it something that a permissionless chain is singularly bad at providing? If your threat model admits the possibility that the publisher would try to deceive you about the most currently published document, wouldn’t a platform that includes probabilistic finality and treats reorgs as a normal part of business be the perfect tool to let them perform their dastardly deeds? It would seem that the correct architectural solution would be something like a widely-witnessed proof-of-existence service, such as Guardtime’s offering that publishes merkle roots in a national newspaper.

 

Like I said near the start, I know my position as CTO of a firm with an open source permissioned blockchain means what I write can’t be seen as unbiased. So I’ve tried my hardest to write objectively and constructively and to avoid setting up strawmen (hence the laboured permissioned/permissionless section so you can ‘see my working’). 

 

There has been so much noise and ‘people talking past each other’ at the boundary of permissioned and permissionless chains… and so, done right, this debate could be something we look back on as a milestone in really nailing some of these concepts.  

 

Richard

 

Richard G Brown R3. | Chief Technology Officer

2 London Wall Place | Floor 12 | London | EC2Y 5AU

richard@... . www.r3.com


Call for volunteers: Hyperledger Global Forum Program Committee

Brian Behlendorf
 

Dear all,

As you hopefully know, we're holding the next Hyperledger Global Forum in Phoenix, Arizona March 3rd-6th, 2020. The Call For Papers was announced two weeks ago, and we already have a nice batch of submissions. To really ensure that the program is built by and represents the full community, we are forming a Program Committee to oversee the content and the agenda for the event.  You can now nominate yourself for the Program Committee.  We expect the burden to be approximately 1 to 2 hours a week from late September to early December, by which point the agenda should be final.  Being on the Committee does not prevent you from submitting talk proposals of your own.  Nominations close September 11th.  Feel free to forward to other parts of the community.  Let us know if you have any questions, and thanks in advance!

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


Re: Hyperledger Besu Proposal is Live

Silas Davis
 

> 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.

This quite a big topic, but I will give some examples I like.

First its worth noting for all of these use cases what is interesting is not just being able to 'do it on mainnet' -- anyone can send transactions to Ethereum from bash -- but rather having mainnet connectivity. The strongest for of this would be that a quorum (ideally any quorum) of your validators are jointly responsible for issuing transactions (via some kind of multisig on mainnet) and checking state on return (via multisig on sidechain). Lesser forms of connectivity might be via 'trusted' third parties or even a single service (i.e. an ethereum oracle). The effect could be the same, but in the weaker forms you have thrown away much of you byzantine tolerance. Ideally you want the same threshold for state changes on the sidechain as for state changes to the relevant contracts on mainnet. If all you require is a proof that a transaction was included (i.e. account X has placed a bond) rather than joint custody of an asset (i.e. paying out from the sidechain's reserve contract - where (super-)majority of validators must agree) then you can get away without quorum at the expense of liveness. To do this kind of strong connectivity it is helpful for validators on both sides (mainnet and sidechain) to be aware of each other. This is where Pantheon could help Burrow for instance - by pushing state back to us rather than us pulling - where a Burrow chain's validators would hold accounts on mainnet, and a validator pool from mainnet would hold accounts on the burrow sidechain. This isn't something we could get go-ethereum to do, but we might persuade Pantheon to provide this intermediate layer.

1. Bond-holding and value transfer.
This probably the most obvious one. Since eth is worth something you can pay people in it. In particular you may want to run micro-transactions on your chain that are secured against a bond placed on ethereum. In order to guarantee the bond you need to be able to observe that a reserve of funds are locked on mainnet, you also need to be able to atomically swap them which is where you need connectivity. For proof-of-stake chains on Burrow you can ask entities wishing to validate to store bond on mainnet, credit them with validator power on Burrow, and if necessary in the case of validator unavailability or equivocation to slash part of their bond on mainnet. We would like all of these actions to be under control of a quorum of validators on the Burrow chain. We can fudge it now, but proper connectivity is what we would like to do it well.

2. Announcement and light clients
I think your receipt log example would come under this bracket. The most interesting to me is announcing state hash, validator set hash, and seed location for a Burrow (or other) network. If I am a participant or validator wanting to join a Burrow network I would like to find out a recent snapshot of the validator set (their public keys) and also how I can connect to them. I could trust, say, Monax to tell me but I'd rather use Ethereum as a public system of announcement. If the validator set hash and state hash is updated in a timely fashion, as a light client I can use it to verify merkle proofs issued by a Burrow node without trusting that Burrow node so long as the history of the state root hash was updated by a quorum of validators periodically (and >1/3 of the set hasn't changed since the last update). This is great because I don't have to validator the entire Burrow network

3. Counter-factual instantiation
This language comes from 'state channels'. If we consider a sidechain as a kind of state channel with its own consensus where some counterparties can more quickly transact than they can on mainnet then they can go about their business issuing signed incremental transactions that would also be valid on mainnet. This works for micro-payments but can be generalised to any state where you have a rule that says the highest sequence number is valid. If the participants on the sidechain have a dispute they can all submit their latest transactions and an ethereum contract can adjudicate. At worst a participant on the sidechain only loses out on state since the last checkpoint they were okay with (e.g. before the sidechain suffered a sybil attack).

4. Inter-chain connectivity
Suppose I have two chains A and B, each chain has a total ordering of its own transactions. If I want to establish a partial ordering between just some transactions on A and B I can do that by instituting some form of meta-consensus on mainnet. This could just be a race if it is unimportant which transaction comes first or it could be some kind of conflict resolution. For example if my chain A is managing bills of lading for shipping and wants to issue an insurance agreement (b) on my agreements network B for a consignment (a). We can transact away on A building the bill of lading and follow a formation and signing process for the agreement on B before finally submitting an transaction on mainnet that defines the insurance agreement as executed _before_ the bill of lading is accepted. The transaction 'b then a' on mainnet is a kind of stronger guarantee that you were insured before you shipped (than say timestamps) - and it's also a public record of the fact. You then only pay the price of cross-chain consensus for transactions that need to depend on each other.

I don't share all of the fervour, and I'm not quite so bullish on Ethereum (though it does have that big advantage of being a thing right now...), but I think the following blog provides quite a nice frame for thinking about possible relationships between mainnet and permissioned networks:


Silas


On Wed, 21 Aug 2019 at 20:08, Middleton, Dan <dan.middleton@...> wrote:

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 Besu Proposal is Live

Joseph Lubin
 

Thanks for the note, Jonathan.

> 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...

Great.  We should discuss this.

> 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.. 

True, but the focus over there is Ethereum so it didn't come up as a priority in that context, and there is likely more focus here on interoperation.



On Tue, Aug 20, 2019 at 7:19 PM, Jonathan Levi <jonathan@...> wrote:
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
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@consensys.net> 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 Dan,


Below are our team’s thoughts on your questions. We are looking forward to the discussion tomorrow.


Question 1:

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?


PegaSys’ Thoughts:

Besu has been built with a modular architecture in mind.  Elements of it could be reused by other parts of Hyperledger. The leading elements for this would be:

  • The use of the devp2p library for listening to an Ethereum network

  • The EVM for execution in an Ethereum based network.

Other elements may also be useful.  As these modules have not yet been run independently, there would likely be work required to ensure that they run well outside of Besu, but this is certainly possible.



Question 2:

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.


PegaSys’ Thoughts:

This article published last week by ConsenSys does a good job articulating the value of Ethereum mainnet as well as the benefits for linking permissioned networks with Ethereum mainnet. In our opinion, this section from the article provides a good overview:


“Many enterprise blockchain experts anticipate that permissioned blockchain networks’ access to the mainnet will be analogous to an intranet’s access to the Internet today, in which users behind security firewalls still have access to all or select parts of the Internet. In the case of blockchain, enterprise networks would have access to the Ethereum mainnet via a bridge, with the ability to pick and choose which networks, nodes, and accounts to interact with on the main chain. Permissioned network interoperability with the Ethereum mainnet would allow data storage across the blockchain and private cloud with customizable privacy and scalability. Connecting to the mainnet also allows compatibility with and access to:

  • other open source or business blockchain networks

  • wider markets and users

  • data or governance logic

  • thousands of dapps”


Thank you,
Grace


On Wed, Aug 21, 2019 at 3:08 PM Middleton, Dan <dan.middleton@...> wrote:

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

Hart Montgomery
 

Hi Mark,

 

As someone who regularly participates in the architecture WG, I don’t think it has the proper set of people right now to drive something like this.  What we would really need for this hypothetical project would be buy-in and participation from maintainers of the consensus algorithms of multiple current projects.  Otherwise, we risk spending a lot of time creating some hypothetical interface that no one uses.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Mark Wagner
Sent: Wednesday, August 21, 2019 3:10 PM
To: Montgomery, Hart <hmontgomery@...>
Cc: Baohua Yang <yangbaohua@...>; Shawn Amundson <amundson@...>; Silas Davis <silas@...>; Stefan Buhrmester <buhrmi@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

is this an area where the architecture WG can be leveraged and they can drive?

 

On Wed, Aug 21, 2019, 18:07 hmontgomery@... <hmontgomery@...> wrote:

+1 to this idea.  Thanks for bringing it up Shawn.

 

I think it would be a great idea to have such a library, as long as we can reasonably infer that people will be able to agree on a consensus interface. 

 

So do we have:

1.       General consensus that we can bridge consensus interfaces across projects.

2.       People across multiple projects willing to lead this effort.

 

If we have those two things, I think this makes perfect sense. 

 

As a first step towards looking into the feasibility of such a project, how about we have a group/meeting at the upcoming contributors’ summit focused on consensus interfaces?  This seems like a productive use of our time in Milwaukee.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Baohua Yang
Sent: Wednesday, August 21, 2019 10:28 AM
To: Shawn Amundson <amundson@...>
Cc: Silas Davis <silas@...>; Stefan Buhrmester <buhrmi@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

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

Mark Wagner
 

is this an area where the architecture WG can be leveraged and they can drive?


On Wed, Aug 21, 2019, 18:07 hmontgomery@... <hmontgomery@...> wrote:

+1 to this idea.  Thanks for bringing it up Shawn.

 

I think it would be a great idea to have such a library, as long as we can reasonably infer that people will be able to agree on a consensus interface. 

 

So do we have:

1.       General consensus that we can bridge consensus interfaces across projects.

2.       People across multiple projects willing to lead this effort.

 

If we have those two things, I think this makes perfect sense. 

 

As a first step towards looking into the feasibility of such a project, how about we have a group/meeting at the upcoming contributors’ summit focused on consensus interfaces?  This seems like a productive use of our time in Milwaukee.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Baohua Yang
Sent: Wednesday, August 21, 2019 10:28 AM
To: Shawn Amundson <amundson@...>
Cc: Silas Davis <silas@...>; Stefan Buhrmester <buhrmi@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

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

Hart Montgomery
 

+1 to this idea.  Thanks for bringing it up Shawn.

 

I think it would be a great idea to have such a library, as long as we can reasonably infer that people will be able to agree on a consensus interface. 

 

So do we have:

1.       General consensus that we can bridge consensus interfaces across projects.

2.       People across multiple projects willing to lead this effort.

 

If we have those two things, I think this makes perfect sense. 

 

As a first step towards looking into the feasibility of such a project, how about we have a group/meeting at the upcoming contributors’ summit focused on consensus interfaces?  This seems like a productive use of our time in Milwaukee.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Baohua Yang
Sent: Wednesday, August 21, 2019 10:28 AM
To: Shawn Amundson <amundson@...>
Cc: Silas Davis <silas@...>; Stefan Buhrmester <buhrmi@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] [Hyperledger Project TSC] Project Proposal: Consensus Platform

 

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 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.


1281 - 1300 of 3871