Date   

Re: Hyperledger Besu Proposal is Live

Christopher Ferris <chrisfer@...>
 

I linked to this thread... easier than cutting and pasting different comments.
 
Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
email: chrisfer@...
twitter: @christo4ferris
IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402
 
 

----- Original message -----
From: "Mic Bowman" <cmickeyb@...>
Sent by: tsc@...
To: Christopher Ferris <chris.ferris@...>
Cc: Shawn Amundson <amundson@...>, VIPIN BHARATHAN <vip@...>, "vipinsun@..." <vipinsun@...>, Silas Davis <silas@...>, "jon.geater@..." <jon.geater@...>, "tsc@..." <tsc@...>
Subject: [EXTERNAL] Re: [Hyperledger TSC] Hyperledger Besu Proposal is Live
Date: Tue, Aug 27, 2019 12:31 PM
 
can i suggest that the working group comments be moved to the page where we are trying to capture all of these discussions? the role of wg's is really not relevant to the besu proposal discussion.
 
 
--mic
 
 
On Tue, Aug 27, 2019 at 6:14 AM Christopher Ferris <chris.ferris@...> wrote:
comments in-lined, below.
 
On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
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.
We already have really good pluggable consensus within Hyperledger that supports both voting and lottery style consensus that is very close to being suitable for cross-project use. The next step is packaging that up into a library that can be reused by the various projects, reconciling the code from the various projects, and refining the rough edges. I think there is substantial interest, but it is a lot of work to accomplish. If the Architecture WG activity in this area is deep consideration of the pluggable consensus API, with an eye towards documenting potential enhancements, there are certainly maintainers that would be interested in joining and participating.
 
I would agree with Shawn, here. There could be a bit more alignment, across projects but we do have plug-able consensus. However, I will remind people that code doesn't write itself, and no one ever shipped an architecture diagram/paper into production. Hyperledger is, all being said, an open source community. I would really love to see people diving in and working out the "how" and then rolling up sleeves to help drive the implementation of their thinking.
  • 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.
The presumption that WGs are where "such work should take place" could only hold true if the WGs produce artifacts that can be used as input into project development. I've not seen an active campaign against WGs, and would love to see useful design documents come out of them.
 
Agree, no one is campaigning against WGs, per se. The discussion of WGs is more about making WGs *more relevant* to the projects so that the project contributors and maintainers might pay them more attention and participate, meaningfully to the benefit of the projects and the broader community.
 
  • 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. 
To some extent, the question is "What is Hyperledger?" Is Hyperledger an organization like Apache that has many unrelated projects; or, as we have been discussing for the last year, is Hyperledger driving toward more unification of its technology stack (not by having a single DLT, but rather by having the DLTs have some common code across them). I'm not sure it is mutually exclusive. However, we have had discussions in which some TSC members and maintainers have favored an approach of more re-usable projects and less (or no) completely new top-level frameworks.
 
...
  • 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.
But, should the competition be within Hyperledger itself? I'm not convinced that the competition within Hyperledger makes Hyperledger better. Maybe sometimes. I'd definitely like to see more collaboration across projects than an increase in competition across projects.
 
...
 
  • 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. 
Every recent project proposal has had to justify itself in relation to other Hyperledger projects. :)
 
Agreed. I've been struggling with this. I think that there's positive benefit to bringing the Hyperledger and Ethereum communities closer together in the hopes that kumbayah. Though, I don't necessarily think that there will ever be one DLT to rule them all, and in the darkness bind them. What I DO think that Hyperledger needs to sort out is how it positions and promotes its projects. Right now, there is a considerable amount of overlap/redundancy, and it can be difficult at best to try to articulate to the general public how the projects are differentiated from one another. Further, during any project's life-cycle there's a great deal of effort expended to raise its voice above the din, to get people to kick the tires and maybe get more interested/invested.
 
I'm fine if Hyperledger is to become the Apache-for-Enterprise-Blockchain-and-DLTs, but note that Apache marketing is about promoting Apache and the Apache Way, not Hadoop, Kafka, Maven, Tomcat, or OpenWhisk.
 
Brian and Jessica have a difficult job, just as any parents with multiple offspring. Each child is special yet loved and nurtured equally. When someone asks a parent which child they love more, the correct response is "all of them". So, what should be the Hyperledger response when asked by press and analysts which of its projects is better, the correct answer needs to be "judge for yourself, we support them all equally". Yet, in this ultra-competitive landscape there is a natural tendency for press and analysts to look for differentiation, conflict and adoption to inform their audiences (and drive clicks). How do we enable the projects to make their case if they are promoted as equals?
 
Where am I going with all of this? I think we need to collectively (with the Board and Marketing) address the question that Shawn posed: "What is Hyperledger?". If Hyperledger is indeed to be a "greenhouse" or "umbrella" organization where open source blockchain/dlt for enterprise is developed - taking its cue from Apache. Then, I think we need to come to terms with two things:
 
1) what we want to be the "Hyperledger Way", and
2) how projects are marketed
 
I think there's much to be learned from the success of Apache and Eclipse, both of which are home to hundreds of projects, some overlapping/competing, some collaborative integrate-able components that fit a given framework. It could be just about creating a "safe place to innovate", as I like to say. It could be about encouraging growth of community(s) around projects. It could be about defining a single compose-able framework for DLTs shepherded by a collection of WGs that do top-down architecture overseen by the TSC.
 
However, whatever we choose, we then need to sort out how (or whether) we market the projects via Hyperledger or, allow the projects to manage their own messaging.
 
 
 
-Shawn

 

 

 

 

 


Re: TSC 2019-2020 Nominee slate

Christopher Ferris <chrisfer@...>
 

Agreed - thanks, Ry!
 
I would also note that it is indeed an impressive list. I am really pleased that there is so much interest!
 
I also think that this makes clear that we should, indeed, expand the TSC.
 
Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
email: chrisfer@...
twitter: @christo4ferris
IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402
 
 

----- Original message -----
From: "Jonathan Levi (HACERA)" <jonathan@...>
Sent by: tsc@...
To: Hyperledger List <tsc@...>
Cc:
Subject: [EXTERNAL] Re: [Hyperledger TSC] TSC 2019-2020 Nominee slate
Date: Tue, Aug 27, 2019 12:10 PM
 
Many thanks for blazingly quick turnaround time here Ry !
 
Jonathan
 


Re: Hyperledger Besu Proposal is Live

Mic Bowman
 

can i suggest that the working group comments be moved to the page where we are trying to capture all of these discussions? the role of wg's is really not relevant to the besu proposal discussion.


--mic


On Tue, Aug 27, 2019 at 6:14 AM Christopher Ferris <chris.ferris@...> wrote:
comments in-lined, below.

On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
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.
We already have really good pluggable consensus within Hyperledger that supports both voting and lottery style consensus that is very close to being suitable for cross-project use. The next step is packaging that up into a library that can be reused by the various projects, reconciling the code from the various projects, and refining the rough edges. I think there is substantial interest, but it is a lot of work to accomplish. If the Architecture WG activity in this area is deep consideration of the pluggable consensus API, with an eye towards documenting potential enhancements, there are certainly maintainers that would be interested in joining and participating.

I would agree with Shawn, here. There could be a bit more alignment, across projects but we do have plug-able consensus. However, I will remind people that code doesn't write itself, and no one ever shipped an architecture diagram/paper into production. Hyperledger is, all being said, an open source community. I would really love to see people diving in and working out the "how" and then rolling up sleeves to help drive the implementation of their thinking.
  • 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.
The presumption that WGs are where "such work should take place" could only hold true if the WGs produce artifacts that can be used as input into project development. I've not seen an active campaign against WGs, and would love to see useful design documents come out of them.

Agree, no one is campaigning against WGs, per se. The discussion of WGs is more about making WGs *more relevant* to the projects so that the project contributors and maintainers might pay them more attention and participate, meaningfully to the benefit of the projects and the broader community.
  • 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. 
To some extent, the question is "What is Hyperledger?" Is Hyperledger an organization like Apache that has many unrelated projects; or, as we have been discussing for the last year, is Hyperledger driving toward more unification of its technology stack (not by having a single DLT, but rather by having the DLTs have some common code across them). I'm not sure it is mutually exclusive. However, we have had discussions in which some TSC members and maintainers have favored an approach of more re-usable projects and less (or no) completely new top-level frameworks.

...
  • 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.
But, should the competition be within Hyperledger itself? I'm not convinced that the competition within Hyperledger makes Hyperledger better. Maybe sometimes. I'd definitely like to see more collaboration across projects than an increase in competition across projects.

...

  • 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. 
Every recent project proposal has had to justify itself in relation to other Hyperledger projects. :)

Agreed. I've been struggling with this. I think that there's positive benefit to bringing the Hyperledger and Ethereum communities closer together in the hopes that kumbayah. Though, I don't necessarily think that there will ever be one DLT to rule them all, and in the darkness bind them. What I DO think that Hyperledger needs to sort out is how it positions and promotes its projects. Right now, there is a considerable amount of overlap/redundancy, and it can be difficult at best to try to articulate to the general public how the projects are differentiated from one another. Further, during any project's life-cycle there's a great deal of effort expended to raise its voice above the din, to get people to kick the tires and maybe get more interested/invested.

I'm fine if Hyperledger is to become the Apache-for-Enterprise-Blockchain-and-DLTs, but note that Apache marketing is about promoting Apache and the Apache Way, not Hadoop, Kafka, Maven, Tomcat, or OpenWhisk.

Brian and Jessica have a difficult job, just as any parents with multiple offspring. Each child is special yet loved and nurtured equally. When someone asks a parent which child they love more, the correct response is "all of them". So, what should be the Hyperledger response when asked by press and analysts which of its projects is better, the correct answer needs to be "judge for yourself, we support them all equally". Yet, in this ultra-competitive landscape there is a natural tendency for press and analysts to look for differentiation, conflict and adoption to inform their audiences (and drive clicks). How do we enable the projects to make their case if they are promoted as equals?

Where am I going with all of this? I think we need to collectively (with the Board and Marketing) address the question that Shawn posed: "What is Hyperledger?". If Hyperledger is indeed to be a "greenhouse" or "umbrella" organization where open source blockchain/dlt for enterprise is developed - taking its cue from Apache. Then, I think we need to come to terms with two things:

1) what we want to be the "Hyperledger Way", and
2) how projects are marketed

I think there's much to be learned from the success of Apache and Eclipse, both of which are home to hundreds of projects, some overlapping/competing, some collaborative integrate-able components that fit a given framework. It could be just about creating a "safe place to innovate", as I like to say. It could be about encouraging growth of community(s) around projects. It could be about defining a single compose-able framework for DLTs shepherded by a collection of WGs that do top-down architecture overseen by the TSC.

However, whatever we choose, we then need to sort out how (or whether) we market the projects via Hyperledger or, allow the projects to manage their own messaging.


-Shawn


Re: TSC 2019-2020 Nominee slate

Jonathan Levi (HACERA)
 

Many thanks for blazingly quick turnaround time here Ry !

Jonathan


TSC 2019-2020 Nominee slate

Ry Jones
 

More people have been nominated. Please read the biographies carefully.
https://wiki.hyperledger.org/display/HYP/2019+Nomination+Statements

Three nominees asked to be removed; they were nominated by someone else.
Ry
--
Ry Jones
Community Architect, Hyperledger


Re: Hyperledger Besu Proposal is Live

Christopher Ferris <chris.ferris@...>
 

comments in-lined, below.

On Tue, Aug 27, 2019 at 2:11 AM Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
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.
We already have really good pluggable consensus within Hyperledger that supports both voting and lottery style consensus that is very close to being suitable for cross-project use. The next step is packaging that up into a library that can be reused by the various projects, reconciling the code from the various projects, and refining the rough edges. I think there is substantial interest, but it is a lot of work to accomplish. If the Architecture WG activity in this area is deep consideration of the pluggable consensus API, with an eye towards documenting potential enhancements, there are certainly maintainers that would be interested in joining and participating.

I would agree with Shawn, here. There could be a bit more alignment, across projects but we do have plug-able consensus. However, I will remind people that code doesn't write itself, and no one ever shipped an architecture diagram/paper into production. Hyperledger is, all being said, an open source community. I would really love to see people diving in and working out the "how" and then rolling up sleeves to help drive the implementation of their thinking.
  • 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.
The presumption that WGs are where "such work should take place" could only hold true if the WGs produce artifacts that can be used as input into project development. I've not seen an active campaign against WGs, and would love to see useful design documents come out of them.

Agree, no one is campaigning against WGs, per se. The discussion of WGs is more about making WGs *more relevant* to the projects so that the project contributors and maintainers might pay them more attention and participate, meaningfully to the benefit of the projects and the broader community.
  • 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. 
To some extent, the question is "What is Hyperledger?" Is Hyperledger an organization like Apache that has many unrelated projects; or, as we have been discussing for the last year, is Hyperledger driving toward more unification of its technology stack (not by having a single DLT, but rather by having the DLTs have some common code across them). I'm not sure it is mutually exclusive. However, we have had discussions in which some TSC members and maintainers have favored an approach of more re-usable projects and less (or no) completely new top-level frameworks.

...
  • 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.
But, should the competition be within Hyperledger itself? I'm not convinced that the competition within Hyperledger makes Hyperledger better. Maybe sometimes. I'd definitely like to see more collaboration across projects than an increase in competition across projects.

...

  • 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. 
Every recent project proposal has had to justify itself in relation to other Hyperledger projects. :)

Agreed. I've been struggling with this. I think that there's positive benefit to bringing the Hyperledger and Ethereum communities closer together in the hopes that kumbayah. Though, I don't necessarily think that there will ever be one DLT to rule them all, and in the darkness bind them. What I DO think that Hyperledger needs to sort out is how it positions and promotes its projects. Right now, there is a considerable amount of overlap/redundancy, and it can be difficult at best to try to articulate to the general public how the projects are differentiated from one another. Further, during any project's life-cycle there's a great deal of effort expended to raise its voice above the din, to get people to kick the tires and maybe get more interested/invested.

I'm fine if Hyperledger is to become the Apache-for-Enterprise-Blockchain-and-DLTs, but note that Apache marketing is about promoting Apache and the Apache Way, not Hadoop, Kafka, Maven, Tomcat, or OpenWhisk.

Brian and Jessica have a difficult job, just as any parents with multiple offspring. Each child is special yet loved and nurtured equally. When someone asks a parent which child they love more, the correct response is "all of them". So, what should be the Hyperledger response when asked by press and analysts which of its projects is better, the correct answer needs to be "judge for yourself, we support them all equally". Yet, in this ultra-competitive landscape there is a natural tendency for press and analysts to look for differentiation, conflict and adoption to inform their audiences (and drive clicks). How do we enable the projects to make their case if they are promoted as equals?

Where am I going with all of this? I think we need to collectively (with the Board and Marketing) address the question that Shawn posed: "What is Hyperledger?". If Hyperledger is indeed to be a "greenhouse" or "umbrella" organization where open source blockchain/dlt for enterprise is developed - taking its cue from Apache. Then, I think we need to come to terms with two things:

1) what we want to be the "Hyperledger Way", and
2) how projects are marketed

I think there's much to be learned from the success of Apache and Eclipse, both of which are home to hundreds of projects, some overlapping/competing, some collaborative integrate-able components that fit a given framework. It could be just about creating a "safe place to innovate", as I like to say. It could be about encouraging growth of community(s) around projects. It could be about defining a single compose-able framework for DLTs shepherded by a collection of WGs that do top-down architecture overseen by the TSC.

However, whatever we choose, we then need to sort out how (or whether) we market the projects via Hyperledger or, allow the projects to manage their own messaging.


-Shawn


Re: Hyperledger Besu Proposal is Live

Virgil Griffith <virgil@...>
 

> Every recent project proposal has had to justify itself in relation to other Hyperledger projects. :)

Sounds reasonable.  Besu has some valuable things to contribute to the Hyperledger ecosystem, but probably the more salient is encouraging the larger sharing between the Ethereum and Hyperledger worlds even outside of Besu.  I see several natural points of contact between Hyperledger and Besu + the larger Ethereum ecosystem:

(1) I can commit to getting Ursa used in as many Ethereum-related projects as possible.  Right now that's not easy because there's no direct way to compile Rust to EVM.  But after Ethereum moves to WebAssembly, this will become possible.  But I will push for this.

(2) It's plausible that Ethereum could contribute to Hyperledger Explorer.  We currently have several opensource blockchain explorers, such as:

I'm not on these block explorer teams, but given the overlap it seems plausible there's some common components so there's less duplicated work in both camps.

(3) It's plausible that Besu and other Ethereum clients (geth, parity, etc) can start contributing to the Caliper tool for improving performance of Ethereum clients.  This also seems a natural point of collaboration.

-Virgil


On Tue, Aug 27, 2019 at 14:11:08, Shawn Amundson <amundson@...> wrote:
On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@dlt.nyc> wrote:
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.
We already have really good pluggable consensus within Hyperledger that supports both voting and lottery style consensus that is very close to being suitable for cross-project use. The next step is packaging that up into a library that can be reused by the various projects, reconciling the code from the various projects, and refining the rough edges. I think there is substantial interest, but it is a lot of work to accomplish. If the Architecture WG activity in this area is deep consideration of the pluggable consensus API, with an eye towards documenting potential enhancements, there are certainly maintainers that would be interested in joining and participating.
  • 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.
The presumption that WGs are where "such work should take place" could only hold true if the WGs produce artifacts that can be used as input into project development. I've not seen an active campaign against WGs, and would love to see useful design documents come out of them.
  • 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. 
To some extent, the question is "What is Hyperledger?" Is Hyperledger an organization like Apache that has many unrelated projects; or, as we have been discussing for the last year, is Hyperledger driving toward more unification of its technology stack (not by having a single DLT, but rather by having the DLTs have some common code across them). I'm not sure it is mutually exclusive. However, we have had discussions in which some TSC members and maintainers have favored an approach of more re-usable projects and less (or no) completely new top-level frameworks.

...
  • 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.
But, should the competition be within Hyperledger itself? I'm not convinced that the competition within Hyperledger makes Hyperledger better. Maybe sometimes. I'd definitely like to see more collaboration across projects than an increase in competition across projects.

...

  • 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. 
Every recent project proposal has had to justify itself in relation to other Hyperledger projects. :)

-Shawn


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

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

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

When: Thursday, 29 August 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Aries update to the TSC is due. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


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

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

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

When: Thursday, 29 August 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Explorer update to the TSC was due 26 August, 2019, and it will be presented to the TSC on 29 August, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


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

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

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

When: Thursday, 29 August 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Composer update to the TSC was due 26 August, 2019, and it will be presented to the TSC on 29 August, 2019. Please review prior to the meeting and bring your questions.


Re: Hyperledger Besu Proposal is Live

Shawn Amundson
 

On Mon, Aug 26, 2019 at 7:43 AM VIPIN BHARATHAN <vip@...> wrote:
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.
We already have really good pluggable consensus within Hyperledger that supports both voting and lottery style consensus that is very close to being suitable for cross-project use. The next step is packaging that up into a library that can be reused by the various projects, reconciling the code from the various projects, and refining the rough edges. I think there is substantial interest, but it is a lot of work to accomplish. If the Architecture WG activity in this area is deep consideration of the pluggable consensus API, with an eye towards documenting potential enhancements, there are certainly maintainers that would be interested in joining and participating.
  • 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.
The presumption that WGs are where "such work should take place" could only hold true if the WGs produce artifacts that can be used as input into project development. I've not seen an active campaign against WGs, and would love to see useful design documents come out of them.
  • 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. 
To some extent, the question is "What is Hyperledger?" Is Hyperledger an organization like Apache that has many unrelated projects; or, as we have been discussing for the last year, is Hyperledger driving toward more unification of its technology stack (not by having a single DLT, but rather by having the DLTs have some common code across them). I'm not sure it is mutually exclusive. However, we have had discussions in which some TSC members and maintainers have favored an approach of more re-usable projects and less (or no) completely new top-level frameworks.

...
  • 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.
But, should the competition be within Hyperledger itself? I'm not convinced that the competition within Hyperledger makes Hyperledger better. Maybe sometimes. I'd definitely like to see more collaboration across projects than an increase in competition across projects.

...

  • 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. 
Every recent project proposal has had to justify itself in relation to other Hyperledger projects. :)

-Shawn


2019 Q3 Hyperledger Transact Quarterly Update Is Available

Mark Ford <mfford@...>
 

Team,

The 2019 Q3 Hyperledger Transact quarterly update is now available for review.


Thanks,
-Mark


Re: Restart / 2 Day Delay for TSC Election

VIPIN BHARATHAN
 

Vote early and vote often!


From: tsc@... <tsc@...> on behalf of Brian Behlendorf via Lists.Hyperledger.Org <bbehlendorf=linuxfoundation.org@...>
Sent: Monday, August 26, 2019 3:31:59 PM
To: tsc@... <tsc@...>
Cc: tsc@... <tsc@...>
Subject: [Hyperledger TSC] Restart / 2 Day Delay for TSC Election
 
It was brought to our attention that the TSC election deadlines had an
off-by-one error: nominations open until August 26th, but voting was
scheduled to start the same day, so it meant we opened voting before
being able to accomodate two inbound nominations we know of, and
possibly others.

So, nominations for the election are still open until today, end of day,
US Pacific time.

To correct the error, new ballots will be sent on Wednesday morning and
voting will be restarted.  If you voted before, please vote again.  The
deadline for votes, and the rest of the process, has also been delayed
by 2 days, plus some similar additional buffer time during the TSC Chair
election.  The new TSC will be named September 4th, the new Chair Sep 13th.

Thank you,

Brian

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





Restart / 2 Day Delay for TSC Election

Brian Behlendorf
 

It was brought to our attention that the TSC election deadlines had an off-by-one error: nominations open until August 26th, but voting was scheduled to start the same day, so it meant we opened voting before being able to accomodate two inbound nominations we know of, and possibly others.

So, nominations for the election are still open until today, end of day, US Pacific time.

To correct the error, new ballots will be sent on Wednesday morning and voting will be restarted.  If you voted before, please vote again.  The deadline for votes, and the rest of the process, has also been delayed by 2 days, plus some similar additional buffer time during the TSC Chair election.  The new TSC will be named September 4th, the new Chair Sep 13th.

Thank you,

Brian

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


Re: New TSC candidates

Shawn Amundson
 

Thanks Dan, very kind. I agree that Andi, Gari, and Tracy would be excellent TSC representatives.

In addition, here is a shout out for all the other code-contributing maintainers as well: please vote for maintainers! It is important that the projects have deep technical representation on the TSC, and the best way to do that is to vote for maintainers. Several of the maintainers on the list are fairly quiet and not well-known, but have substantial personal investment in building Hyperledger's codebase. All the maintainers on the list are great to work with. Vote for them!

Thanks,

-Shawn


On Mon, Aug 26, 2019 at 11:10 AM Middleton, Dan <dan.middleton@...> wrote:

I would like to highlight a few of the candidates who have not previously been on the TSC, but whom I would be happy to see on the TSC based on my direct knowledge of their extensive contributions.

 

Andrea Gunderson is one of the most prolific contributors in Hyperledger. Her development work on the web assembly engine, Sabre, stands out for both its technical sophistication and relevance to cross project interests. What you will not know from her bio and pitch is that she is very detail and delivery oriented. I’m confident that if elected to the TSC, Ms. Gunderson will arrive informed and prepared to increase the velocity of the TSC.

 

Gari Singh should be familiar to most involved with Fabric. Like Ms. Gunderson, Mr. Singh is a long time maintainer and prolific developer. As Fabric embodies different architectural priorities than the other frameworks, I do not believe that Mr. Singh’s technical opinions will always align with my own, but I do anticipate that the TSC will be better for his participation.

 

Tracy Kuhrt should be familiar to all of the project communities. Not only has she made direct contributions, but as one of the original community architects, Ms. Kuhrt has been exposed to the full breadth of Hyperledger. In fact, I believe that she has a unique breadth and depth of contribution to Hyperledger that the TSC should not be without. 

 

Shawn Amundson has worked across several projects and may be familiar to different portions of our Hyperledger Community. I view him as the initiator of the cross-project effort now called Transact (among substantial contributions to several other projects). He is an ardent proponent of open source principles and championed the adoption of the Rust project’s RFC process which has been independently adopted by several of our projects. 

 


The 2019-2020 election is underway

Ry Jones
 

If you did not get a ballot, and you think you should have, please reach out to me directly.

If you did get a ballot - please vote!


New TSC candidates

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

I would like to highlight a few of the candidates who have not previously been on the TSC, but whom I would be happy to see on the TSC based on my direct knowledge of their extensive contributions.

 

Andrea Gunderson is one of the most prolific contributors in Hyperledger. Her development work on the web assembly engine, Sabre, stands out for both its technical sophistication and relevance to cross project interests. What you will not know from her bio and pitch is that she is very detail and delivery oriented. I’m confident that if elected to the TSC, Ms. Gunderson will arrive informed and prepared to increase the velocity of the TSC.

 

Gari Singh should be familiar to most involved with Fabric. Like Ms. Gunderson, Mr. Singh is a long time maintainer and prolific developer. As Fabric embodies different architectural priorities than the other frameworks, I do not believe that Mr. Singh’s technical opinions will always align with my own, but I do anticipate that the TSC will be better for his participation.

 

Tracy Kuhrt should be familiar to all of the project communities. Not only has she made direct contributions, but as one of the original community architects, Ms. Kuhrt has been exposed to the full breadth of Hyperledger. In fact, I believe that she has a unique breadth and depth of contribution to Hyperledger that the TSC should not be without. 

 

Shawn Amundson has worked across several projects and may be familiar to different portions of our Hyperledger Community. I view him as the initiator of the cross-project effort now called Transact (among substantial contributions to several other projects). He is an ardent proponent of open source principles and championed the adoption of the Rust project’s RFC process which has been independently adopted by several of our projects. 

 


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

1261 - 1280 of 3868