|
Mic Bowman
Per our discussion in the TSC call this morning about getting clarity for the purpose & objectives of the HLP white paper.
Here are the “candidate” objectives for the white paper we’ve been discussing in the white paper working group. We felt like these reflected the various high level comments provided during the feedback session a couple weeks ago. These
are intended as a starting point for the discussion.
·
Call for action to back and drive the HLP as the preeminent means for advancing distributed ledger technologies
·
Capture the concepts of the 'Umbrella organization' and clarify
·
Establish a common vocabulary for discussing technology and usages
·
Establish a future vision of HLP… where do we see HLP 1, 2, 4 years from now
|
|
|
Hart Montgomery <hmontgomery@...>
Thank you for the objective summary Mic. To follow up on this, I think it’s also important to consider what audience we are targeting. Are we intending the whitepaper for: 1. People who are not currently involved in Hyperledger. In this case, the whitepaper is essentially a technical marketing document designed to drive interest in Hyperledger. We list the features and some of the vision, but keep everything very high-level. 2. People who are getting started using Hyperledger. This was (in my opinion—I obviously didn’t write the OBC whitepaper) the initial conception of the whitepaper, as it focused on basic technical details and features, and was a good first read for a technical person who wanted to understand how Hyperledger worked. However, as Hyperledger has matured and the whitepaper has moved away from the original IBM OBC whitepaper, this is not totally the focus anymore (and doesn’t necessarily have to be), although new Hyperledger users still seem to be the main audience of the current whitepaper. 3. Current Hyperledger developers/users. If this is the case, the document becomes a sort of manifesto, and we would want to focus on high-level architectural requirements, vision, and goals of the project. The whitepaper’s current emphasis on modular structure seems to fall somewhat into this category. I don’t think there is a right or wrong answer here, and we could obviously mix and match who we are targeting (i.e. some sections target #1, others #2). However, it would be nice to know what the community and TSC think the audience of the whitepaper should be, as the expected audience will heavily impact how we need to rewrite the whitepaper. Thank you all for your time, and have a great day. Hart
From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Bowman, Mic via hyperledger-tsc Sent: Thursday, October 13, 2016 7:34 AM To: hyperledger-tsc@... Subject: [Hyperledger Project TSC] white paper objectives Per our discussion in the TSC call this morning about getting clarity for the purpose & objectives of the HLP white paper. Here are the “candidate” objectives for the white paper we’ve been discussing in the white paper working group. We felt like these reflected the various high level comments provided during the feedback session a couple weeks ago. These are intended as a starting point for the discussion. · Call for action to back and drive the HLP as the preeminent means for advancing distributed ledger technologies · Capture the concepts of the 'Umbrella organization' and clarify · Establish a common vocabulary for discussing technology and usages · Establish a future vision of HLP… where do we see HLP 1, 2, 4 years from now
|
|
|
Christopher Ferris <chris.ferris@...>
Mic, thanks for starting this thread.
Hart, I tend to think that #1 is definitely a target audience, and that #2 is a subset of #1 that will actually get their hands dirty.
So, basically, I think of this as providing the concepts that Mic outlined (I tend to agree that this should be the scope) and that we provide enough meat to point people in the right direction to get started either collaborating or using the technologies we are collectively creating.
It should also be a call to action for others to come play.
Chris
On Thu, Oct 13, 2016 at 5:31 PM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@...> wrote: Thank you for the objective summary Mic. To follow up on this, I think it’s also important to consider what audience we are targeting. Are we intending the whitepaper for: 1. People who are not currently involved in Hyperledger. In this case, the whitepaper is essentially a technical marketing document designed to drive interest in Hyperledger. We list the features and some of the vision, but keep everything very high-level. 2. People who are getting started using Hyperledger. This was (in my opinion—I obviously didn’t write the OBC whitepaper) the initial conception of the whitepaper, as it focused on basic technical details and features, and was a good first read for a technical person who wanted to understand how Hyperledger worked. However, as Hyperledger has matured and the whitepaper has moved away from the original IBM OBC whitepaper, this is not totally the focus anymore (and doesn’t necessarily have to be), although new Hyperledger users still seem to be the main audience of the current whitepaper. 3. Current Hyperledger developers/users. If this is the case, the document becomes a sort of manifesto, and we would want to focus on high-level architectural requirements, vision, and goals of the project. The whitepaper’s current emphasis on modular structure seems to fall somewhat into this category. I don’t think there is a right or wrong answer here, and we could obviously mix and match who we are targeting (i.e. some sections target #1, others #2). However, it would be nice to know what the community and TSC think the audience of the whitepaper should be, as the expected audience will heavily impact how we need to rewrite the whitepaper. Thank you all for your time, and have a great day. Hart Per our discussion in the TSC call this morning about getting clarity for the purpose & objectives of the HLP white paper. Here are the “candidate” objectives for the white paper we’ve been discussing in the white paper working group. We felt like these reflected the various high level comments provided during the feedback session a couple weeks ago. These are intended as a starting point for the discussion. · Call for action to back and drive the HLP as the preeminent means for advancing distributed ledger technologies · Capture the concepts of the 'Umbrella organization' and clarify · Establish a common vocabulary for discussing technology and usages · Establish a future vision of HLP… where do we see HLP 1, 2, 4 years from now
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
Richard Brown <richard@...>
I agree with the points made below. To my mind, it feels like there should be a logical progression across a series of papers:
·
Hyperledger Project Whitepaper (the thing we’re currently discussing I guess!)
o
This should be the technical ‘manifesto’ for the Project. What do we believe? What problems are we solving? What are the defining characteristics of
the field and the aspects that unite us?
o
The reader of this paper should be left understanding exactly what the project is for, what it means for a codebase to be part of the project and where
the project is going
o
For those who haven’t seen it, we tried to do this – but in a more narrow sense – in the first sections of the introductory whitepaper for Corda (http://r3cev.com/s/corda-introductory-whitepaper-final.pdf).
Chapters 2 and 3 (Context and Vision) are our attempt at describing what we think defines the distributed ledger space, what problems this tech can solve and it does so from the context of financial services.
o
Perhaps something like that but written more broadly/expansively is called for?
·
Whitepapers for specific Hyperledger Project projects
o
ie a Fabric whitepaper, an STL whitepaper, etc, etc, etc.
o
A reader of one of these papers should come away understanding that platform’s unique objectives, design and architecture.
o
The paper should probably reference the overall Project whitepaper but the purpose of these whitepapers is to leave the reader with complete clarity
as to the overall design/architecture/purpose/objectives of a particular codebase.
Richard
Richard Gendal Brown
R3
|
Chief Technology Officer
City Tower, Floor Fifteen
40 Basinghall Street
London, EC2V 5DE
Cell: +44 776 466 6821
richard@... | www.r3cev.com
Email Disclaimer
From:
<hyperledger-tsc-bounces@...> on behalf of Christopher Ferris via hyperledger-tsc <hyperledger-tsc@...>
Reply-To: Christopher Ferris <chris.ferris@...>
Date: Thursday, 13 October 2016 at 16:42
To: Hart Montgomery <hmontgomery@...>
Cc: "hyperledger-tsc@..." <hyperledger-tsc@...>
Subject: Re: [Hyperledger Project TSC] white paper objectives
Mic, thanks for starting this thread.
Hart, I tend to think that #1 is definitely a target audience, and that #2 is a subset of #1 that will actually get their hands dirty.
So, basically, I think of this as providing the concepts that Mic outlined (I tend to agree that this should be the scope) and that we provide enough meat to point people in the right direction to get started
either collaborating or using the technologies we are collectively creating.
It should also be a call to action for others to come play.
toggle quoted message
Show quoted text
On Thu, Oct 13, 2016 at 5:31 PM, Hart Montgomery via hyperledger-tsc < hyperledger-tsc@...> wrote:
Thank you for the objective summary Mic. To follow up on this, I think it’s also important to consider what audience we are targeting. Are we intending the whitepaper for:
1.
People who are not currently involved in Hyperledger. In this case, the whitepaper is essentially a technical marketing document designed to drive interest in Hyperledger. We list the features and some of the
vision, but keep everything very high-level.
2.
People who are getting started using Hyperledger. This was (in my opinion—I obviously didn’t write the OBC whitepaper) the initial conception of the whitepaper, as it focused on basic technical details and features,
and was a good first read for a technical person who wanted to understand how Hyperledger worked. However, as Hyperledger has matured and the whitepaper has moved away from the original IBM OBC whitepaper, this is not totally the focus anymore (and doesn’t
necessarily have to be), although new Hyperledger users still seem to be the main audience of the current whitepaper.
3.
Current Hyperledger developers/users. If this is the case, the document becomes a sort of manifesto, and we would want to focus on high-level architectural requirements, vision, and goals of the project. The
whitepaper’s current emphasis on modular structure seems to fall somewhat into this category.
I don’t think there is a right or wrong answer here, and we could obviously mix and match who we are targeting (i.e. some sections target #1, others #2). However, it would be nice to know what the community and TSC
think the audience of the whitepaper should be, as the expected audience will heavily impact how we need to rewrite the whitepaper.
Thank you all for your time, and have a great day.
Hart
Per our discussion in the TSC call this morning about getting clarity for the purpose & objectives of the HLP white paper.
Here are the “candidate” objectives for the white paper we’ve been discussing in the white paper working group. We felt like these reflected the various high level comments provided during the feedback session a couple weeks ago. These are
intended as a starting point for the discussion.
·
Call for action to back and drive the HLP as the preeminent means for advancing distributed ledger technologies
·
Capture the concepts of the 'Umbrella organization' and clarify
·
Establish a common vocabulary for discussing technology and usages
·
Establish a future vision of HLP… where do we see HLP 1, 2, 4 years from now
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
I agree that the Hyperledger Project Whitepaper should provide enough info to point people in the right direction to get started using the technology. Should each project under the umbrella receive a paragraph where they state their objectives and goals and link to the project’s specific whitepaper? It may be nice to come up with a standard feature matrix that each project could fill out based on the common vocabulary defined in the whitepaper. For example, private/public, smart contracts, consensus algorithm, etc. These may require a living part of the paper so it may make sense to maintain the into elsewhere. What I'd like to see though is a single 'quick overview' of each project without having to delve into each project's individual whitepaper.
-Sheehan
On Sun, Oct 16, 2016 at 9:36 PM, Richard Brown via hyperledger-tsc <hyperledger-tsc@...> wrote:
I agree with the points made below. To my mind, it feels like there should be a logical progression across a series of papers:
·
Hyperledger Project Whitepaper (the thing we’re currently discussing I guess!)
o
This should be the technical ‘manifesto’ for the Project. What do we believe? What problems are we solving? What are the defining characteristics of
the field and the aspects that unite us?
o
The reader of this paper should be left understanding exactly what the project is for, what it means for a codebase to be part of the project and where
the project is going
o
For those who haven’t seen it, we tried to do this – but in a more narrow sense – in the first sections of the introductory whitepaper for Corda (http://r3cev.com/s/corda-introductory-whitepaper-final.pdf).
Chapters 2 and 3 (Context and Vision) are our attempt at describing what we think defines the distributed ledger space, what problems this tech can solve and it does so from the context of financial services.
o
Perhaps something like that but written more broadly/expansively is called for?
·
Whitepapers for specific Hyperledger Project projects
o
ie a Fabric whitepaper, an STL whitepaper, etc, etc, etc.
o
A reader of one of these papers should come away understanding that platform’s unique objectives, design and architecture.
o
The paper should probably reference the overall Project whitepaper but the purpose of these whitepapers is to leave the reader with complete clarity
as to the overall design/architecture/purpose/objectives of a particular codebase.
Richard
Email Disclaimer
Mic, thanks for starting this thread.
Hart, I tend to think that #1 is definitely a target audience, and that #2 is a subset of #1 that will actually get their hands dirty.
So, basically, I think of this as providing the concepts that Mic outlined (I tend to agree that this should be the scope) and that we provide enough meat to point people in the right direction to get started
either collaborating or using the technologies we are collectively creating.
It should also be a call to action for others to come play.
On Thu, Oct 13, 2016 at 5:31 PM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@lists.hyperledger.org> wrote:
Thank you for the objective summary Mic. To follow up on this, I think it’s also important to consider what audience we are targeting. Are we intending the whitepaper for:
1.
People who are not currently involved in Hyperledger. In this case, the whitepaper is essentially a technical marketing document designed to drive interest in Hyperledger. We list the features and some of the
vision, but keep everything very high-level.
2.
People who are getting started using Hyperledger. This was (in my opinion—I obviously didn’t write the OBC whitepaper) the initial conception of the whitepaper, as it focused on basic technical details and features,
and was a good first read for a technical person who wanted to understand how Hyperledger worked. However, as Hyperledger has matured and the whitepaper has moved away from the original IBM OBC whitepaper, this is not totally the focus anymore (and doesn’t
necessarily have to be), although new Hyperledger users still seem to be the main audience of the current whitepaper.
3.
Current Hyperledger developers/users. If this is the case, the document becomes a sort of manifesto, and we would want to focus on high-level architectural requirements, vision, and goals of the project. The
whitepaper’s current emphasis on modular structure seems to fall somewhat into this category.
I don’t think there is a right or wrong answer here, and we could obviously mix and match who we are targeting (i.e. some sections target #1, others #2). However, it would be nice to know what the community and TSC
think the audience of the whitepaper should be, as the expected audience will heavily impact how we need to rewrite the whitepaper.
Thank you all for your time, and have a great day.
Hart
Per our discussion in the TSC call this morning about getting clarity for the purpose & objectives of the HLP white paper.
Here are the “candidate” objectives for the white paper we’ve been discussing in the white paper working group. We felt like these reflected the various high level comments provided during the feedback session a couple weeks ago. These are
intended as a starting point for the discussion.
·
Call for action to back and drive the HLP as the preeminent means for advancing distributed ledger technologies
·
Capture the concepts of the 'Umbrella organization' and clarify
·
Establish a common vocabulary for discussing technology and usages
·
Establish a future vision of HLP… where do we see HLP 1, 2, 4 years from now
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
Baohua Yang
Love the idea, however, this may results in late WP releasing and more efforts.
On the other hand, the joining of new projects are still happening often, will we wait when it's more stable?
We can certainly add briefs of each existing project's scope, however.
On Mon, Oct 17, 2016 at 10:43 AM, Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote: I agree that the Hyperledger Project Whitepaper should provide enough info to point people in the right direction to get started using the technology. Should each project under the umbrella receive a paragraph where they state their objectives and goals and link to the project’s specific whitepaper? It may be nice to come up with a standard feature matrix that each project could fill out based on the common vocabulary defined in the whitepaper. For example, private/public, smart contracts, consensus algorithm, etc. These may require a living part of the paper so it may make sense to maintain the into elsewhere. What I'd like to see though is a single 'quick overview' of each project without having to delve into each project's individual whitepaper.
-Sheehan
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
Hi,
The issue of whether the Whitepaper is technical enough for people to get started and build a working prototype or a vision paper is due to the basic tension between the idea of Hyperledger as an umbrella concept and the fact there are at least two (if not three with Iroha) specific projects under incubation.
This is further complicated by the fact that the paper had its genesis in the OBC whitepaper.
So, we have to decide what should the Hyperledger whitepaper cover? (NOT what the Fabric, STL, Iroha or Corda whitepaper cover).
As far as the Hyperledger whitepaper, it could be a vision paper with general architectural principles laid out and enough technical discussion on the various points that are generic to all DLTs. Which means not only the currently incubation DLTs but also any emergent ones . (obviously to a limited extent, as future technical solutions cannot be fully predicted).
Individual DLTs under incubation can have their own technical yellow paper and a whitepaper. The Hyperledger Whitepaper will have a link to a location that have links to Fabric, STL, Iroha whitepapers or include them in the appendix.
Regards,
Vipin
|
|
|
Mark Parzygnat <markparz@...>
+1
A benefit of the whitepaper would be to not just call out terms and theories that are equivalent across projects, but include the key differentiators to help guide folks to the appropriate project best suited for their needs and comfort level (code base developed on, link to key feature sets and what they mean as this should be more living documentation than the white paper itself, etc... probably not a difference in target users).
We've all seen newcomers ask, which project is best for me, or what's the difference....
Regards
 vipin bharathan via hyperledger-tsc ---10/17/2016 11:48:55 AM---Hi, The issue of whether the Whitepaper is technical enough for people to get
From: vipin bharathan via hyperledger-tsc <hyperledger-tsc@...>
To: Baohua Yang <yangbaohua@...>
Cc: hyperledger-tsc@...
Date: 10/17/2016 11:48 AM
Subject: Re: [Hyperledger Project TSC] white paper objectives
Sent by: hyperledger-tsc-bounces@...
Hi, The issue of whether the Whitepaper is technical enough for people to get started and build a working prototype or a vision paper is due to the basic tension between the idea of Hyperledger as an umbrella concept and the fact there are at least two (if not three with Iroha) specific projects under incubation. This is further complicated by the fact that the paper had its genesis in the OBC whitepaper. So, we have to decide what should the Hyperledger whitepaper cover? (NOT what the Fabric, STL, Iroha or Corda whitepaper cover). As far as the Hyperledger whitepaper, it could be a vision paper with general architectural principles laid out and enough technical discussion on the various points that are generic to all DLTs. Which means not only the currently incubation DLTs but also any emergent ones . (obviously to a limited extent, as future technical solutions cannot be fully predicted). Individual DLTs under incubation can have their own technical yellow paper and a whitepaper. The Hyperledger Whitepaper will have a link to a location that have links to Fabric, STL, Iroha whitepapers or include them in the appendix. Regards,
Vipin
On Oct 17, 2016 11:15 AM, "Baohua Yang via hyperledger-tsc" < hyperledger-tsc@...> wrote: Love the idea, however, this may results in late WP releasing and more efforts.
On the other hand, the joining of new projects are still happening often, will we wait when it's more stable?
We can certainly add briefs of each existing project's scope, however.
On Mon, Oct 17, 2016 at 10:43 AM, Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote:
I agree that the Hyperledger Project Whitepaper should provide enough info to point people in the right direction to get started using the technology. Should each project under the umbrella receive a paragraph where they state their objectives and goals and link to the project’s specific whitepaper? It may be nice to come up with a standard feature matrix that each project could fill out based on the common vocabulary defined in the whitepaper. For example, private/public, smart contracts, consensus algorithm, etc. These may require a living part of the paper so it may make sense to maintain the into elsewhere. What I'd like to see though is a single 'quick overview' of each project without having to delve into each project's individual whitepaper.
-Sheehan
On Sun, Oct 16, 2016 at 9:36 PM, Richard Brown via hyperledger-tsc <hyperledger-tsc@...> wrote:I agree with the points made below. To my mind, it feels like there should be a logical progression across a series of papers: · Hyperledger Project Whitepaper (the thing we’re currently discussing I guess!) o This should be the technical ‘manifesto’ for the Project. What do we believe? What problems are we solving? What are the defining characteristics of the field and the aspects that unite us? o The reader of this paper should be left understanding exactly what the project is for, what it means for a codebase to be part of the project and where the project is going o For those who haven’t seen it, we tried to do this – but in a more narrow sense – in the first sections of the introductory whitepaper for Corda (http://r3cev.com/s/corda-introductory-whitepaper-final.pdf). Chapters 2 and 3 (Context and Vision) are our attempt at describing what we think defines the distributed ledger space, what problems this tech can solve and it does so from the context of financial services. o Perhaps something like that but written more broadly/expansively is called for?
· Whitepapers for specific Hyperledger Project projectso ie a Fabric whitepaper, an STL whitepaper, etc, etc, etc. o A reader of one of these papers should come away understanding that platform’s unique objectives, design and architecture. o The paper should probably reference the overall Project whitepaper but the purpose of these whitepapers is to leave the reader with complete clarity as to the overall design/architecture/purpose/objectives of a particular codebase.
Richard Richard Gendal Brown R3 | Chief Technology Officer City Tower, Floor Fifteen 40 Basinghall Street London, EC2V 5DE Cell: +44 776 466 6821 richard@... | www.r3cev.com Email Disclaimer From: <hyperledger-tsc-bounces@...> on behalf of Christopher Ferris via hyperledger-tsc <hyperledger-tsc@...>
Reply-To: Christopher Ferris <chris.ferris@...>
Date: Thursday, 13 October 2016 at 16:42
To: Hart Montgomery <hmontgomery@...>
Cc: "hyperledger-tsc@..." <hyperledger-tsc@...>
Subject: Re: [Hyperledger Project TSC] white paper objectives Mic, thanks for starting this thread. Hart, I tend to think that #1 is definitely a target audience, and that #2 is a subset of #1 that will actually get their hands dirty. So, basically, I think of this as providing the concepts that Mic outlined (I tend to agree that this should be the scope) and that we provide enough meat to point people in the right direction to get started either collaborating or using the technologies we are collectively creating. It should also be a call to action for others to come play. Chris On Thu, Oct 13, 2016 at 5:31 PM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@...> wrote: Thank you for the objective summary Mic. To follow up on this, I think it’s also important to consider what audience we are targeting. Are we intending the whitepaper for: 1. People who are not currently involved in Hyperledger. In this case, the whitepaper is essentially a technical marketing document designed to drive interest in Hyperledger. We list the features and some of the vision, but keep everything very high-level. 2. People who are getting started using Hyperledger. This was (in my opinion—I obviously didn’t write the OBC whitepaper) the initial conception of the whitepaper, as it focused on basic technical details and features, and was a good first read for a technical person who wanted to understand how Hyperledger worked. However, as Hyperledger has matured and the whitepaper has moved away from the original IBM OBC whitepaper, this is not totally the focus anymore (and doesn’t necessarily have to be), although new Hyperledger users still seem to be the main audience of the current whitepaper. 3. Current Hyperledger developers/users. If this is the case, the document becomes a sort of manifesto, and we would want to focus on high-level architectural requirements, vision, and goals of the project. The whitepaper’s current emphasis on modular structure seems to fall somewhat into this category. I don’t think there is a right or wrong answer here, and we could obviously mix and match who we are targeting (i.e. some sections target #1, others #2). However, it would be nice to know what the community and TSC think the audience of the whitepaper should be, as the expected audience will heavily impact how we need to rewrite the whitepaper. Thank you all for your time, and have a great day. Hart From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Bowman, Mic via hyperledger-tsc
Sent: Thursday, October 13, 2016 7:34 AM
To: hyperledger-tsc@...
Subject: [Hyperledger Project TSC] white paper objectives Per our discussion in the TSC call this morning about getting clarity for the purpose & objectives of the HLP white paper. Here are the “candidate” objectives for the white paper we’ve been discussing in the white paper working group. We felt like these reflected the various high level comments provided during the feedback session a couple weeks ago. These are intended as a starting point for the discussion. · Call for action to back and drive the HLP as the preeminent means for advancing distributed ledger technologies · Capture the concepts of the 'Umbrella organization' and clarify · Establish a common vocabulary for discussing technology and usages · Establish a future vision of HLP… where do we see HLP 1, 2, 4 years from now
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
Best wishes!
Baohua Yang
https://yeasy.github.io
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
I think the whitepaper should callout some the "design principles" of Hyperledger, something that the community is contributing to the world -- beyond the lifetime of the Hyperledger projects. Something that people will recall 20 years from now. Looking at the long history of the IETF ("...running code and rough consensus) it's worth noting that in the early 1990s even the IETF had to work-out (fight over) some design principles for the nascent Internet routing. One of these is the end-to-end principle, which is now taken for granted. So in addition to writing code, the Hyperledger community could do well in producing these "design principles of the future blockchain systems". Some examples (in lay language): (1) Separation of consensus-making protocol from ledger maintenance mechanisms. (2) Separation of block syntax from transaction semantics. (3) Separation of person-identity from transaction-identity. Etc. etc. Lots more. I can lend a hand if the TSC needs help writing. /thomas/ ------------------------------------------ Thomas Hardjono MIT Connection Science & Engineering connection.mit.edu ------------------------------------------ From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Mark Parzygnat via hyperledger-tsc Sent: Monday, October 17, 2016 1:29 PM To: vipin bharathan Cc: hyperledger-tsc-bounces@...; hyperledger-tsc@... Subject: Re: [Hyperledger Project TSC] white paper objectives +1 A benefit of the whitepaper would be to not just call out terms and theories that are equivalent across projects, but include the key differentiators to help guide folks to the appropriate project best suited for their needs and comfort level (code base developed on, link to key feature sets and what they mean as this should be more living documentation than the white paper itself, etc... probably not a difference in target users). We've all seen newcomers ask, which project is best for me, or what's the difference.... Regards vipin bharathan via hyperledger-tsc ---10/17/2016 11:48:55 AM---Hi, The issue of whether the Whitepaper is technical enough for people to get From: vipin bharathan via hyperledger-tsc <hyperledger-tsc@...> To: Baohua Yang <yangbaohua@...> Cc: hyperledger-tsc@... Date: 10/17/2016 11:48 AM Subject: Re: [Hyperledger Project TSC] white paper objectives Sent by: hyperledger-tsc-bounces@... ________________________________________ Hi, The issue of whether the Whitepaper is technical enough for people to get started and build a working prototype or a vision paper is due to the basic tension between the idea of Hyperledger as an umbrella concept and the fact there are at least two (if not three with Iroha) specific projects under incubation. This is further complicated by the fact that the paper had its genesis in the OBC whitepaper. So, we have to decide what should the Hyperledger whitepaper cover? (NOT what the Fabric, STL, Iroha or Corda whitepaper cover). As far as the Hyperledger whitepaper, it could be a vision paper with general architectural principles laid out and enough technical discussion on the various points that are generic to all DLTs. Which means not only the currently incubation DLTs but also any emergent ones . (obviously to a limited extent, as future technical solutions cannot be fully predicted). Individual DLTs under incubation can have their own technical yellow paper and a whitepaper. The Hyperledger Whitepaper will have a link to a location that have links to Fabric, STL, Iroha whitepapers or include them in the appendix. Regards, Vipin On Oct 17, 2016 11:15 AM, "Baohua Yang via hyperledger-tsc" <hyperledger-tsc@...> wrote: Love the idea, however, this may results in late WP releasing and more efforts. On the other hand, the joining of new projects are still happening often, will we wait when it's more stable? We can certainly add briefs of each existing project's scope, however. On Mon, Oct 17, 2016 at 10:43 AM, Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote: I agree that the Hyperledger Project Whitepaper should provide enough info to point people in the right direction to get started using the technology. Should each project under the umbrella receive a paragraph where they state their objectives and goals and link to the project’s specific whitepaper? It may be nice to come up with a standard feature matrix that each project could fill out based on the common vocabulary defined in the whitepaper. For example, private/public, smart contracts, consensus algorithm, etc. These may require a living part of the paper so it may make sense to maintain the into elsewhere. What I'd like to see though is a single 'quick overview' of each project without having to delve into each project's individual whitepaper. -Sheehan On Sun, Oct 16, 2016 at 9:36 PM, Richard Brown via hyperledger-tsc <hyperledger-tsc@...> wrote: I agree with the points made below. To my mind, it feels like there should be a logical progression across a series of papers: • Hyperledger Project Whitepaper (the thing we’re currently discussing I guess!) o This should be the technical ‘manifesto’ for the Project. What do we believe? What problems are we solving? What are the defining characteristics of the field and the aspects that unite us? o The reader of this paper should be left understanding exactly what the project is for, what it means for a codebase to be part of the project and where the project is going o For those who haven’t seen it, we tried to do this – but in a more narrow sense – in the first sections of the introductory whitepaper for Corda ( http://r3cev.com/s/corda-introductory-whitepaper-final.pdf). Chapters 2 and 3 (Context and Vision) are our attempt at describing what we think defines the distributed ledger space, what problems this tech can solve and it does so from the context of financial services. o Perhaps something like that but written more broadly/expansively is called for? • Whitepapers for specific Hyperledger Project projects o ie a Fabric whitepaper, an STL whitepaper, etc, etc, etc. o A reader of one of these papers should come away understanding that platform’s unique objectives, design and architecture. o The paper should probably reference the overall Project whitepaper but the purpose of these whitepapers is to leave the reader with complete clarity as to the overall design/architecture/purpose/objectives of a particular codebase. Richard Richard Gendal Brown R3 | Chief Technology Officer City Tower, Floor Fifteen 40 Basinghall Street London, EC2V 5DE Cell: +44 776 466 6821 richard@... | www.r3cev.com Email Disclaimer From: <hyperledger-tsc-bounces@...> on behalf of Christopher Ferris via hyperledger-tsc <hyperledger-tsc@...> Reply-To: Christopher Ferris <chris.ferris@...> Date: Thursday, 13 October 2016 at 16:42 To: Hart Montgomery <hmontgomery@...> Cc: "hyperledger-tsc@..." <hyperledger-tsc@...> Subject: Re: [Hyperledger Project TSC] white paper objectives Mic, thanks for starting this thread. Hart, I tend to think that #1 is definitely a target audience, and that #2 is a subset of #1 that will actually get their hands dirty. So, basically, I think of this as providing the concepts that Mic outlined (I tend to agree that this should be the scope) and that we provide enough meat to point people in the right direction to get started either collaborating or using the technologies we are collectively creating. It should also be a call to action for others to come play. Chris On Thu, Oct 13, 2016 at 5:31 PM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@...> wrote: Thank you for the objective summary Mic. To follow up on this, I think it’s also important to consider what audience we are targeting. Are we intending the whitepaper for: 1. People who are not currently involved in Hyperledger. In this case, the whitepaper is essentially a technical marketing document designed to drive interest in Hyperledger. We list the features and some of the vision, but keep everything very high-level. 2. People who are getting started using Hyperledger. This was (in my opinion—I obviously didn’t write the OBC whitepaper) the initial conception of the whitepaper, as it focused on basic technical details and features, and was a good first read for a technical person who wanted to understand how Hyperledger worked. However, as Hyperledger has matured and the whitepaper has moved away from the original IBM OBC whitepaper, this is not totally the focus anymore (and doesn’t necessarily have to be), although new Hyperledger users still seem to be the main audience of the current whitepaper. 3. Current Hyperledger developers/users. If this is the case, the document becomes a sort of manifesto, and we would want to focus on high-level architectural requirements, vision, and goals of the project. The whitepaper’s current emphasis on modular structure seems to fall somewhat into this category. I don’t think there is a right or wrong answer here, and we could obviously mix and match who we are targeting (i.e. some sections target #1, others #2). However, it would be nice to know what the community and TSC think the audience of the whitepaper should be, as the expected audience will heavily impact how we need to rewrite the whitepaper. Thank you all for your time, and have a great day. Hart From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Bowman, Mic via hyperledger-tsc Sent: Thursday, October 13, 2016 7:34 AM To: hyperledger-tsc@... Subject: [Hyperledger Project TSC] white paper objectives Per our discussion in the TSC call this morning about getting clarity for the purpose & objectives of the HLP white paper. Here are the “candidate” objectives for the white paper we’ve been discussing in the white paper working group. We felt like these reflected the various high level comments provided during the feedback session a couple weeks ago. These are intended as a starting point for the discussion. • Call for action to back and drive the HLP as the preeminent means for advancing distributed ledger technologies • Capture the concepts of the 'Umbrella organization' and clarify • Establish a common vocabulary for discussing technology and usages • Establish a future vision of HLP… where do we see HLP 1, 2, 4 years from now _______________________________________________ hyperledger-tsc mailing list hyperledger-tsc@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc_______________________________________________ hyperledger-tsc mailing list hyperledger-tsc@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc_______________________________________________ hyperledger-tsc mailing list hyperledger-tsc@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc-- Best wishes! Baohua Yang https://yeasy.github.io_______________________________________________ hyperledger-tsc mailing list hyperledger-tsc@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc_______________________________________________ hyperledger-tsc mailing list hyperledger-tsc@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
Hart Montgomery <hmontgomery@...>
Thanks everyone for the comments and feedback. It's been really nice for me to hear some of the ideas from the community, and I'm sure others in the whitepaper WG would agree. There has been a lot of discussion about the overall philosophy of the whitepaper, which has been great, but it would also be nice to tie some of this discussion down concretely.
Below is the current outline of the whitepaper:
1. Abstract
2. Background
3. Why a New Blockchain? (Why Hyperledger?)
4. Our Vision
5. Industry Use Cases
a. Financial Asset Depository
b. Corporate Action
c. Supply Chain
d. Master Data Management
e. Sharing Economy and Internet of Things
6. Featured Requirements
a. Private Transactions and Confidential Contracts
b. Identity and Auditability
c. Interoperability
d. Portability
7. Architecture
8. Application Programming Interface
9. Network Topology
10. Conclusion.
A. Glossary
Does anyone have any suggestions, comments, or feedback on structural changes to the whitepaper to meet some of these philosophical requirements, and to accommodate the umbrella principle? Obviously we are going to have to completely rework the architecture section, and there has been some good discussion on how we ought to do this. Some of the other sections (API, Network Topology) might need to be eliminated or reworked in some manner. If anyone has suggestions for how to modify the outline/structure of the whitepaper, I think it would be great to see them. Personally, I am especially interested in getting a consensus on how/where we should incorporate the umbrella structure, and how we want to handle all of the separate projects (i.e. highlight a few, mention a paragraph about all of them, etc.).
Thanks,
Hart
toggle quoted message
Show quoted text
-----Original Message----- From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Thomas Hardjono via hyperledger-tsc Sent: Monday, October 17, 2016 10:40 AM To: hyperledger-tsc@... Subject: Re: [Hyperledger Project TSC] white paper objectives I think the whitepaper should callout some the "design principles" of Hyperledger, something that the community is contributing to the world -- beyond the lifetime of the Hyperledger projects. Something that people will recall 20 years from now. Looking at the long history of the IETF ("...running code and rough consensus) it's worth noting that in the early 1990s even the IETF had to work-out (fight over) some design principles for the nascent Internet routing. One of these is the end-to-end principle, which is now taken for granted. So in addition to writing code, the Hyperledger community could do well in producing these "design principles of the future blockchain systems". Some examples (in lay language): (1) Separation of consensus-making protocol from ledger maintenance mechanisms. (2) Separation of block syntax from transaction semantics. (3) Separation of person-identity from transaction-identity. Etc. etc. Lots more. I can lend a hand if the TSC needs help writing. /thomas/ ------------------------------------------ Thomas Hardjono MIT Connection Science & Engineering connection.mit.edu ------------------------------------------ From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Mark Parzygnat via hyperledger-tsc Sent: Monday, October 17, 2016 1:29 PM To: vipin bharathan Cc: hyperledger-tsc-bounces@...; hyperledger-tsc@... Subject: Re: [Hyperledger Project TSC] white paper objectives +1 A benefit of the whitepaper would be to not just call out terms and theories that are equivalent across projects, but include the key differentiators to help guide folks to the appropriate project best suited for their needs and comfort level (code base developed on, link to key feature sets and what they mean as this should be more living documentation than the white paper itself, etc... probably not a difference in target users). We've all seen newcomers ask, which project is best for me, or what's the difference.... Regards vipin bharathan via hyperledger-tsc ---10/17/2016 11:48:55 AM---Hi, The issue of whether the Whitepaper is technical enough for people to get From: vipin bharathan via hyperledger-tsc <hyperledger-tsc@...> To: Baohua Yang <yangbaohua@...> Cc: hyperledger-tsc@... Date: 10/17/2016 11:48 AM Subject: Re: [Hyperledger Project TSC] white paper objectives Sent by: hyperledger-tsc-bounces@... ________________________________________ Hi, The issue of whether the Whitepaper is technical enough for people to get started and build a working prototype or a vision paper is due to the basic tension between the idea of Hyperledger as an umbrella concept and the fact there are at least two (if not three with Iroha) specific projects under incubation. This is further complicated by the fact that the paper had its genesis in the OBC whitepaper. So, we have to decide what should the Hyperledger whitepaper cover? (NOT what the Fabric, STL, Iroha or Corda whitepaper cover). As far as the Hyperledger whitepaper, it could be a vision paper with general architectural principles laid out and enough technical discussion on the various points that are generic to all DLTs. Which means not only the currently incubation DLTs but also any emergent ones . (obviously to a limited extent, as future technical solutions cannot be fully predicted). Individual DLTs under incubation can have their own technical yellow paper and a whitepaper. The Hyperledger Whitepaper will have a link to a location that have links to Fabric, STL, Iroha whitepapers or include them in the appendix. Regards, Vipin On Oct 17, 2016 11:15 AM, "Baohua Yang via hyperledger-tsc" <hyperledger-tsc@...> wrote: Love the idea, however, this may results in late WP releasing and more efforts. On the other hand, the joining of new projects are still happening often, will we wait when it's more stable? We can certainly add briefs of each existing project's scope, however. On Mon, Oct 17, 2016 at 10:43 AM, Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote: I agree that the Hyperledger Project Whitepaper should provide enough info to point people in the right direction to get started using the technology. Should each project under the umbrella receive a paragraph where they state their objectives and goals and link to the project’s specific whitepaper? It may be nice to come up with a standard feature matrix that each project could fill out based on the common vocabulary defined in the whitepaper. For example, private/public, smart contracts, consensus algorithm, etc. These may require a living part of the paper so it may make sense to maintain the into elsewhere. What I'd like to see though is a single 'quick overview' of each project without having to delve into each project's individual whitepaper. -Sheehan On Sun, Oct 16, 2016 at 9:36 PM, Richard Brown via hyperledger-tsc <hyperledger-tsc@...> wrote: I agree with the points made below. To my mind, it feels like there should be a logical progression across a series of papers: • Hyperledger Project Whitepaper (the thing we’re currently discussing I guess!) o This should be the technical ‘manifesto’ for the Project. What do we believe? What problems are we solving? What are the defining characteristics of the field and the aspects that unite us? o The reader of this paper should be left understanding exactly what the project is for, what it means for a codebase to be part of the project and where the project is going o For those who haven’t seen it, we tried to do this – but in a more narrow sense – in the first sections of the introductory whitepaper for Corda ( http://r3cev.com/s/corda-introductory-whitepaper-final.pdf). Chapters 2 and 3 (Context and Vision) are our attempt at describing what we think defines the distributed ledger space, what problems this tech can solve and it does so from the context of financial services. o Perhaps something like that but written more broadly/expansively is called for? • Whitepapers for specific Hyperledger Project projects o ie a Fabric whitepaper, an STL whitepaper, etc, etc, etc. o A reader of one of these papers should come away understanding that platform’s unique objectives, design and architecture. o The paper should probably reference the overall Project whitepaper but the purpose of these whitepapers is to leave the reader with complete clarity as to the overall design/architecture/purpose/objectives of a particular codebase. Richard Richard Gendal Brown R3 | Chief Technology Officer City Tower, Floor Fifteen 40 Basinghall Street London, EC2V 5DE Cell: +44 776 466 6821 richard@... | www.r3cev.com Email Disclaimer From: <hyperledger-tsc-bounces@...> on behalf of Christopher Ferris via hyperledger-tsc <hyperledger-tsc@...> Reply-To: Christopher Ferris <chris.ferris@...> Date: Thursday, 13 October 2016 at 16:42 To: Hart Montgomery <hmontgomery@...> Cc: "hyperledger-tsc@..." <hyperledger-tsc@...> Subject: Re: [Hyperledger Project TSC] white paper objectives Mic, thanks for starting this thread. Hart, I tend to think that #1 is definitely a target audience, and that #2 is a subset of #1 that will actually get their hands dirty. So, basically, I think of this as providing the concepts that Mic outlined (I tend to agree that this should be the scope) and that we provide enough meat to point people in the right direction to get started either collaborating or using the technologies we are collectively creating. It should also be a call to action for others to come play. Chris On Thu, Oct 13, 2016 at 5:31 PM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@...> wrote: Thank you for the objective summary Mic. To follow up on this, I think it’s also important to consider what audience we are targeting. Are we intending the whitepaper for: 1. People who are not currently involved in Hyperledger. In this case, the whitepaper is essentially a technical marketing document designed to drive interest in Hyperledger. We list the features and some of the vision, but keep everything very high-level. 2. People who are getting started using Hyperledger. This was (in my opinion—I obviously didn’t write the OBC whitepaper) the initial conception of the whitepaper, as it focused on basic technical details and features, and was a good first read for a technical person who wanted to understand how Hyperledger worked. However, as Hyperledger has matured and the whitepaper has moved away from the original IBM OBC whitepaper, this is not totally the focus anymore (and doesn’t necessarily have to be), although new Hyperledger users still seem to be the main audience of the current whitepaper. 3. Current Hyperledger developers/users. If this is the case, the document becomes a sort of manifesto, and we would want to focus on high-level architectural requirements, vision, and goals of the project. The whitepaper’s current emphasis on modular structure seems to fall somewhat into this category. I don’t think there is a right or wrong answer here, and we could obviously mix and match who we are targeting (i.e. some sections target #1, others #2). However, it would be nice to know what the community and TSC think the audience of the whitepaper should be, as the expected audience will heavily impact how we need to rewrite the whitepaper. Thank you all for your time, and have a great day. Hart From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Bowman, Mic via hyperledger-tsc Sent: Thursday, October 13, 2016 7:34 AM To: hyperledger-tsc@... Subject: [Hyperledger Project TSC] white paper objectives Per our discussion in the TSC call this morning about getting clarity for the purpose & objectives of the HLP white paper. Here are the “candidate” objectives for the white paper we’ve been discussing in the white paper working group. We felt like these reflected the various high level comments provided during the feedback session a couple weeks ago. These are intended as a starting point for the discussion. • Call for action to back and drive the HLP as the preeminent means for advancing distributed ledger technologies • Capture the concepts of the 'Umbrella organization' and clarify • Establish a common vocabulary for discussing technology and usages • Establish a future vision of HLP… where do we see HLP 1, 2, 4 years from now _______________________________________________ hyperledger-tsc mailing list hyperledger-tsc@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc_______________________________________________ hyperledger-tsc mailing list hyperledger-tsc@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc_______________________________________________ hyperledger-tsc mailing list hyperledger-tsc@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc-- Best wishes! Baohua Yang https://yeasy.github.io_______________________________________________ hyperledger-tsc mailing list hyperledger-tsc@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc_______________________________________________ hyperledger-tsc mailing list hyperledger-tsc@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc_______________________________________________ hyperledger-tsc mailing list hyperledger-tsc@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
I think the “Featured Requirements” section is too opinionated currently given the umbrella nature of Hyperledger. Perhaps this would be a good location to introduce the common vocabulary that Mic suggested and introduce users to various choices surrounding blockchain projects including why one may make a particular choice. These would be choices such as public membership vs restricted membership, pseudo anonymous vs auditable identities, turing complete smart contracts vs limited scripting, etc. There are sub-items here also, for example smart contracts may always execute on every peer vs executing on a specified subset of peers.
The blockchain community is quite polarized over many of these decisions currently and I think if an umbrella project is to succeed vs one chain to rule them all, it will be important for the members to have an agreed upon view on the merits of various design choices so it does not feel like an collection of competing projects.
Does this sound like a reasonable approach for the “Featured Requirements” (need to think of a different name) section? If so, I think the next step would be to come up with a list of X vs Y choices and then work with proponents of a particular design decision to accurately document its merits and potential drawbacks.
I feel that sections 7, 8, and 9 are potentially too specific and would need to live in each individual project’s whitepaper. Maybe there would be some standards around these in the future, but it’s still very early.
Regards, -Sheehan
On Mon, Oct 17, 2016 at 3:02 PM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@...> wrote: Thanks everyone for the comments and feedback. It's been really nice for me to hear some of the ideas from the community, and I'm sure others in the whitepaper WG would agree. There has been a lot of discussion about the overall philosophy of the whitepaper, which has been great, but it would also be nice to tie some of this discussion down concretely.
Below is the current outline of the whitepaper:
1. Abstract
2. Background
3. Why a New Blockchain? (Why Hyperledger?)
4. Our Vision
5. Industry Use Cases
a. Financial Asset Depository
b. Corporate Action
c. Supply Chain
d. Master Data Management
e. Sharing Economy and Internet of Things
6. Featured Requirements
a. Private Transactions and Confidential Contracts
b. Identity and Auditability
c. Interoperability
d. Portability
7. Architecture
8. Application Programming Interface
9. Network Topology
10. Conclusion.
A. Glossary
Does anyone have any suggestions, comments, or feedback on structural changes to the whitepaper to meet some of these philosophical requirements, and to accommodate the umbrella principle? Obviously we are going to have to completely rework the architecture section, and there has been some good discussion on how we ought to do this. Some of the other sections (API, Network Topology) might need to be eliminated or reworked in some manner. If anyone has suggestions for how to modify the outline/structure of the whitepaper, I think it would be great to see them. Personally, I am especially interested in getting a consensus on how/where we should incorporate the umbrella structure, and how we want to handle all of the separate projects (i.e. highlight a few, mention a paragraph about all of them, etc.).
Thanks,
Hart
-----Original Message-----
From: hyperledger-tsc-bounces@lists.hyperledger.org [mailto: hyperledger-tsc-bounces@...] On Behalf Of Thomas Hardjono via hyperledger-tsc
Sent: Monday, October 17, 2016 10:40 AM
To: hyperledger-tsc@lists.hyperledger.org
Subject: Re: [Hyperledger Project TSC] white paper objectives
I think the whitepaper should callout some the "design principles" of Hyperledger, something that the community is contributing to the world -- beyond the lifetime of the Hyperledger projects. Something that people will recall 20 years from now.
Looking at the long history of the IETF ("...running code and rough consensus) it's worth noting that in the early 1990s even the IETF had to work-out (fight over) some design principles for the nascent Internet routing. One of these is the end-to-end principle, which is now taken for granted.
So in addition to writing code, the Hyperledger community could do well in producing these "design principles of the future blockchain systems".
Some examples (in lay language):
(1) Separation of consensus-making protocol from ledger maintenance mechanisms.
(2) Separation of block syntax from transaction semantics.
(3) Separation of person-identity from transaction-identity.
Etc. etc. Lots more.
I can lend a hand if the TSC needs help writing.
/thomas/
------------------------------ ------------
Thomas Hardjono
MIT Connection Science & Engineering
connection.mit.edu
------------------------------ ------------
From: hyperledger-tsc-bounces@lists.hyperledger.org [mailto: hyperledger-tsc-bounces@...] On Behalf Of Mark Parzygnat via hyperledger-tsc
Sent: Monday, October 17, 2016 1:29 PM
To: vipin bharathan
Cc: hyperledger-tsc-bounces@lists.hyperledger.org; hyperledger-tsc@lists.hyperledger.org
Subject: Re: [Hyperledger Project TSC] white paper objectives
+1
A benefit of the whitepaper would be to not just call out terms and theories that are equivalent across projects, but include the key differentiators to help guide folks to the appropriate project best suited for their needs and comfort level (code base developed on, link to key feature sets and what they mean as this should be more living documentation than the white paper itself, etc... probably not a difference in target users).
We've all seen newcomers ask, which project is best for me, or what's the difference....
Regards
vipin bharathan via hyperledger-tsc ---10/17/2016 11:48:55 AM---Hi, The issue of whether the Whitepaper is technical enough for people to get
From: vipin bharathan via hyperledger-tsc < hyperledger-tsc@lists.hyperledger.org>
To: Baohua Yang < yangbaohua@...>
Cc: hyperledger-tsc@lists.hyperledger.org
Date: 10/17/2016 11:48 AM
Subject: Re: [Hyperledger Project TSC] white paper objectives Sent by: hyperledger-tsc-bounces@lists.hyperledger.org
______________________________ __________
Hi,
The issue of whether the Whitepaper is technical enough for people to get started and build a working prototype or a vision paper is due to the basic tension between the idea of Hyperledger as an umbrella concept and the fact there are at least two (if not three with Iroha) specific projects under incubation.
This is further complicated by the fact that the paper had its genesis in the OBC whitepaper.
So, we have to decide what should the Hyperledger whitepaper cover? (NOT what the Fabric, STL, Iroha or Corda whitepaper cover).
As far as the Hyperledger whitepaper, it could be a vision paper with general architectural principles laid out and enough technical discussion on the various points that are generic to all DLTs. Which means not only the currently incubation DLTs but also any emergent ones . (obviously to a limited extent, as future technical solutions cannot be fully predicted).
Individual DLTs under incubation can have their own technical yellow paper and a whitepaper. The Hyperledger Whitepaper will have a link to a location that have links to Fabric, STL, Iroha whitepapers or include them in the appendix.
Regards,
Vipin
On Oct 17, 2016 11:15 AM, "Baohua Yang via hyperledger-tsc" < hyperledger-tsc@lists.hyperledger.org> wrote:
Love the idea, however, this may results in late WP releasing and more efforts.
On the other hand, the joining of new projects are still happening often, will we wait when it's more stable?
We can certainly add briefs of each existing project's scope, however.
On Mon, Oct 17, 2016 at 10:43 AM, Sheehan Anderson via hyperledger-tsc < hyperledger-tsc@lists.hyperledger.org> wrote:
I agree that the Hyperledger Project Whitepaper should provide enough info to point people in the right direction to get started using the technology. Should each project under the umbrella receive a paragraph where they state their objectives and goals and link to the project’s specific whitepaper? It may be nice to come up with a standard feature matrix that each project could fill out based on the common vocabulary defined in the whitepaper. For example, private/public, smart contracts, consensus algorithm, etc. These may require a living part of the paper so it may make sense to maintain the into elsewhere. What I'd like to see though is a single 'quick overview' of each project without having to delve into each project's individual whitepaper.
-Sheehan
On Sun, Oct 16, 2016 at 9:36 PM, Richard Brown via hyperledger-tsc < hyperledger-tsc@lists.hyperledger.org> wrote:
I agree with the points made below. To my mind, it feels like there should be a logical progression across a series of papers:
• Hyperledger Project Whitepaper (the thing we’re currently discussing I guess!)
o This should be the technical ‘manifesto’ for the Project. What do we believe? What problems are we solving? What are the defining characteristics of the field and the aspects that unite us?
o The reader of this paper should be left understanding exactly what the project is for, what it means for a codebase to be part of the project and where the project is going
o For those who haven’t seen it, we tried to do this – but in a more narrow sense – in the first sections of the introductory whitepaper for Corda ( http://r3cev.com/s/corda-introductory-whitepaper-final.pdf). Chapters 2 and 3 (Context and Vision) are our attempt at describing what we think defines the distributed ledger space, what problems this tech can solve and it does so from the context of financial services.
o Perhaps something like that but written more broadly/expansively is called for?
• Whitepapers for specific Hyperledger Project projects
o ie a Fabric whitepaper, an STL whitepaper, etc, etc, etc.
o A reader of one of these papers should come away understanding that platform’s unique objectives, design and architecture.
o The paper should probably reference the overall Project whitepaper but the purpose of these whitepapers is to leave the reader with complete clarity as to the overall design/architecture/purpose/ objectives of a particular codebase.
Richard
Richard Gendal Brown
R3 | Chief Technology Officer
City Tower, Floor Fifteen
40 Basinghall Street
London, EC2V 5DE
Cell: +44 776 466 6821
richard@... | www.r3cev.com
Email Disclaimer
From: < hyperledger-tsc-bounces@lists.hyperledger.org> on behalf of Christopher Ferris via hyperledger-tsc < hyperledger-tsc@lists.hyperledger.org>
Reply-To: Christopher Ferris < chris.ferris@...>
Date: Thursday, 13 October 2016 at 16:42
To: Hart Montgomery < hmontgomery@...>
Cc: " hyperledger-tsc@lists.hyperledger.org" < hyperledger-tsc@lists.hyperledger.org>
Subject: Re: [Hyperledger Project TSC] white paper objectives
Mic, thanks for starting this thread.
Hart, I tend to think that #1 is definitely a target audience, and that #2 is a subset of #1 that will actually get their hands dirty.
So, basically, I think of this as providing the concepts that Mic outlined (I tend to agree that this should be the scope) and that we provide enough meat to point people in the right direction to get started either collaborating or using the technologies we are collectively creating.
It should also be a call to action for others to come play.
Chris
On Thu, Oct 13, 2016 at 5:31 PM, Hart Montgomery via hyperledger-tsc < hyperledger-tsc@lists.hyperledger.org> wrote:
Thank you for the objective summary Mic. To follow up on this, I think it’s also important to consider what audience we are targeting. Are we intending the whitepaper for:
1. People who are not currently involved in Hyperledger. In this case, the whitepaper is essentially a technical marketing document designed to drive interest in Hyperledger. We list the features and some of the vision, but keep everything very high-level.
2. People who are getting started using Hyperledger. This was (in my opinion—I obviously didn’t write the OBC whitepaper) the initial conception of the whitepaper, as it focused on basic technical details and features, and was a good first read for a technical person who wanted to understand how Hyperledger worked. However, as Hyperledger has matured and the whitepaper has moved away from the original IBM OBC whitepaper, this is not totally the focus anymore (and doesn’t necessarily have to be), although new Hyperledger users still seem to be the main audience of the current whitepaper.
3. Current Hyperledger developers/users. If this is the case, the document becomes a sort of manifesto, and we would want to focus on high-level architectural requirements, vision, and goals of the project. The whitepaper’s current emphasis on modular structure seems to fall somewhat into this category.
I don’t think there is a right or wrong answer here, and we could obviously mix and match who we are targeting (i.e. some sections target #1, others #2). However, it would be nice to know what the community and TSC think the audience of the whitepaper should be, as the expected audience will heavily impact how we need to rewrite the whitepaper.
Thank you all for your time, and have a great day.
Hart
From: hyperledger-tsc-bounces@lists.hyperledger.org [mailto: hyperledger-tsc-bounces@...] On Behalf Of Bowman, Mic via hyperledger-tsc
Sent: Thursday, October 13, 2016 7:34 AM
To: hyperledger-tsc@lists.hyperledger.org
Subject: [Hyperledger Project TSC] white paper objectives
Per our discussion in the TSC call this morning about getting clarity for the purpose & objectives of the HLP white paper.
Here are the “candidate” objectives for the white paper we’ve been discussing in the white paper working group. We felt like these reflected the various high level comments provided during the feedback session a couple weeks ago. These are intended as a starting point for the discussion.
• Call for action to back and drive the HLP as the preeminent means for advancing distributed ledger technologies
• Capture the concepts of the 'Umbrella organization' and clarify
• Establish a common vocabulary for discussing technology and usages
• Establish a future vision of HLP… where do we see HLP 1, 2, 4 years from now
______________________________ _________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
______________________________ _________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
______________________________ _________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
Best wishes!
Baohua Yang
https://yeasy.github.io
______________________________ _________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
______________________________ _________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
______________________________ _________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
______________________________ _________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
+1 to your note, Sheehan.
> Does this sound like a reasonable approach for the “Featured Requirements” (need to think of a different name) section? If so, I think the next step would be to come up with a list of X vs Y choices and then work with proponents of a particular design decision to accurately document its merits and potential drawbacks.
Rather than a list of X vs. Y (which is a good start), perhaps it makes sense to define functional modules, and enumerate approaches within each function.
In a modular, plug-and-play approach, each module's interface can be defined and then one or more components can be implemented for that module. E.g. if you define a consensus module, you can build components for permissionless networks in the categories of proof of work and proof of stake, and you can also build components for round robin validation, random selection validation, pBFT, Paxos/Raft, etc, in more strongly governed or constrained contexts.
> I feel that sections 7, 8, and 9 are potentially too specific and would need to live in each individual project’s whitepaper. Maybe there would be some standards around these in the future, but it’s still very early.
Provisional APIs could perhaps be sketched at the module level.
On Mon, Oct 17, 2016 at 11:38 PM Sheehan Anderson via hyperledger-tsc < hyperledger-tsc@...> wrote: I think the “Featured Requirements” section is too opinionated currently given the umbrella nature of Hyperledger. Perhaps this would be a good location to introduce the common vocabulary that Mic suggested and introduce users to various choices surrounding blockchain projects including why one may make a particular choice. These would be choices such as public membership vs restricted membership, pseudo anonymous vs auditable identities, turing complete smart contracts vs limited scripting, etc. There are sub-items here also, for example smart contracts may always execute on every peer vs executing on a specified subset of peers.
The blockchain community is quite polarized over many of these decisions currently and I think if an umbrella project is to succeed vs one chain to rule them all, it will be important for the members to have an agreed upon view on the merits of various design choices so it does not feel like an collection of competing projects.
Does this sound like a reasonable approach for the “Featured Requirements” (need to think of a different name) section? If so, I think the next step would be to come up with a list of X vs Y choices and then work with proponents of a particular design decision to accurately document its merits and potential drawbacks.
I feel that sections 7, 8, and 9 are potentially too specific and would need to live in each individual project’s whitepaper. Maybe there would be some standards around these in the future, but it’s still very early.
Regards, -Sheehan
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
Good idea, I agree that documenting functional modules would be a better approach.
I think sketching provisional APIs is a good idea, I’m just not sure if it makes sense to try something in the near term or wait for projects to continue to mature and hope that some thinking around APIs may naturally converge as good ideas prove themselves in the real world.
-Sheehan
On Tue, Oct 18, 2016 at 7:51 AM, Joseph Lubin via hyperledger-tsc <hyperledger-tsc@...> wrote: +1 to your note, Sheehan.
> Does this sound like a reasonable approach for the “Featured Requirements” (need to think of a different name) section? If so, I think the next step would be to come up with a list of X vs Y choices and then work with proponents of a particular design decision to accurately document its merits and potential drawbacks.
Rather than a list of X vs. Y (which is a good start), perhaps it makes sense to define functional modules, and enumerate approaches within each function.
In a modular, plug-and-play approach, each module's interface can be defined and then one or more components can be implemented for that module. E.g. if you define a consensus module, you can build components for permissionless networks in the categories of proof of work and proof of stake, and you can also build components for round robin validation, random selection validation, pBFT, Paxos/Raft, etc, in more strongly governed or constrained contexts.
> I feel that sections 7, 8, and 9 are potentially too specific and would need to live in each individual project’s whitepaper. Maybe there would be some standards around these in the future, but it’s still very early.
Provisional APIs could perhaps be sketched at the module level.
I think the “Featured Requirements” section is too opinionated currently given the umbrella nature of Hyperledger. Perhaps this would be a good location to introduce the common vocabulary that Mic suggested and introduce users to various choices surrounding blockchain projects including why one may make a particular choice. These would be choices such as public membership vs restricted membership, pseudo anonymous vs auditable identities, turing complete smart contracts vs limited scripting, etc. There are sub-items here also, for example smart contracts may always execute on every peer vs executing on a specified subset of peers.
The blockchain community is quite polarized over many of these decisions currently and I think if an umbrella project is to succeed vs one chain to rule them all, it will be important for the members to have an agreed upon view on the merits of various design choices so it does not feel like an collection of competing projects.
Does this sound like a reasonable approach for the “Featured Requirements” (need to think of a different name) section? If so, I think the next step would be to come up with a list of X vs Y choices and then work with proponents of a particular design decision to accurately document its merits and potential drawbacks.
I feel that sections 7, 8, and 9 are potentially too specific and would need to live in each individual project’s whitepaper. Maybe there would be some standards around these in the future, but it’s still very early.
Regards, -Sheehan
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
Pete Harris (Lighthouse) <pete@...>
So - apologies in advance but I am a marketing guy these day (though I used to write code in assembly language for fine computers like the PDP-11) and I think the Use Cases section needs a redux. It either needs to be replaced by a couple of grafs saying the use cases are many and varied, or a more comprehensive (though high level) discussion needs to be included. Happy to provide some substance/ideas if there is interest.
Pete Harris
Good idea, I agree that documenting functional modules would be a better approach.
I think sketching provisional APIs is a good idea, I’m just not sure if it makes sense to try something in the near term or wait for projects to continue to mature and hope that some thinking around APIs may naturally converge as good ideas prove themselves in the real world.
-Sheehan
_______________________________________________ hyperledger-tsc mailing list hyperledger-tsc@...https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
> I’m just not sure if it makes sense to try something in the near term or wait for projects to continue to mature and hope that some thinking around APIs may naturally converge as good ideas prove themselves in the real world.
A bit of the former (sketching modules and APIs) to build and maintain an evolving map of the territory. And lots of the latter (building and maturing projects) to explore the various solution spaces and converge of what works best for different use cases.
On Tue, Oct 18, 2016 at 9:59 PM Sheehan Anderson via hyperledger-tsc < hyperledger-tsc@...> wrote: Good idea, I agree that documenting functional modules would be a better approach.
I think sketching provisional APIs is a good idea, I’m just not sure if it makes sense to try something in the near term or wait for projects to continue to mature and hope that some thinking around APIs may naturally converge as good ideas prove themselves in the real world.
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
Mic Bowman
I think documenting some common “capabilities” might be reasonable. However… with the diversity of projects that already exist in HL, defining APIs in a white
paper would likely derail any attempt to complete the white paper. I would strongly prefer to move all details about the projects and APIs out of the initial white paper. Those are documents that need to be written, but we’ve been unable to complete the existing
WP because 1) the projects are a moving target and 2) because the project has become an umbrella, the use of any project leads to misrepresentation of others.
I’m all in favor of documenting projects, components, etc…
However… We’ve been working on the WP for six months & need to wrap it up. My suggestion is that, for the current high level white paper, we keep project-specific
details out, and focus on what Hyperledger working group is about. And… we separately work to develop an architecture document (which Ram is working towards in the Arch WG) and strongly encourage each project to put together a high level description and we
put together some form of “comparative analysis” for the projects to help with the selection of a particular platform.
--mic
toggle quoted message
Show quoted text
From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...]
On Behalf Of Sheehan Anderson via hyperledger-tsc
Sent: Tuesday, October 18, 2016 6:59 PM
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives
Good idea, I agree that documenting functional modules would be a better approach.
I think sketching provisional APIs is a good idea, I’m just not sure if it makes sense to try something in the near term or wait for projects to continue to mature and hope that some thinking around APIs may naturally converge as good ideas
prove themselves in the real world.
On Tue, Oct 18, 2016 at 7:51 AM, Joseph Lubin via hyperledger-tsc <hyperledger-tsc@...> wrote:
+1 to your note, Sheehan.
> Does this sound like a reasonable approach for the “Featured Requirements” (need to think of a different name) section? If so, I think the next step would be to come up with a list of X vs Y choices and then work with proponents of a
particular design decision to accurately document its merits and potential drawbacks.
Rather than a list of X vs. Y (which is a good start), perhaps it makes sense to define functional modules, and enumerate approaches within each function.
In a modular, plug-and-play approach, each module's interface can be defined and then one or more components can be implemented for that module. E.g. if you define a consensus module, you can build components for permissionless networks
in the categories of proof of work and proof of stake, and you can also build components for round robin validation, random selection validation, pBFT, Paxos/Raft, etc, in more strongly governed or constrained contexts.
> I feel that sections 7, 8, and 9 are potentially too specific and would need to live in each individual project’s whitepaper. Maybe there would be some standards around these in the future, but it’s still very early.
Provisional APIs could perhaps be sketched at the module level.
On Mon, Oct 17, 2016 at 11:38 PM Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote:
I think the “Featured Requirements” section is too opinionated currently given the umbrella nature of Hyperledger. Perhaps this would be a good location to introduce the common vocabulary that Mic suggested and introduce users to various
choices surrounding blockchain projects including why one may make a particular choice. These would be choices such as public membership vs restricted membership, pseudo anonymous vs auditable identities, turing complete smart contracts vs limited scripting,
etc. There are sub-items here also, for example smart contracts may always execute on every peer vs executing on a specified subset of peers.
The blockchain community is quite polarized over many of these decisions currently and I think if an umbrella project is to succeed vs one chain to rule them all, it will be important for the members to have an agreed upon view on the merits
of various design choices so it does not feel like an collection of competing projects.
Does this sound like a reasonable approach for the “Featured Requirements” (need to think of a different name) section? If so, I think the next step would be to come up with a list of X vs Y choices and then work with proponents of a particular
design decision to accurately document its merits and potential drawbacks.
I feel that sections 7, 8, and 9 are potentially too specific and would need to live in each individual project’s whitepaper. Maybe there would be some standards around these in the future, but it’s still very early.
On Mon, Oct 17, 2016 at 3:02 PM, Hart Montgomery via hyperledger-tsc
<hyperledger-tsc@...> wrote:
Thanks everyone for the comments and feedback. It's been really nice for me to hear some of the ideas from the community, and I'm sure others in the whitepaper WG would agree. There has been a lot of discussion about the overall philosophy
of the whitepaper, which has been great, but it would also be nice to tie some of this discussion down concretely.
Below is the current outline of the whitepaper:
1. Abstract
2. Background
3. Why a New Blockchain? (Why Hyperledger?)
4. Our Vision
5. Industry Use Cases
a. Financial Asset Depository
b. Corporate Action
c. Supply Chain
d. Master Data Management
e. Sharing Economy and Internet of Things
6. Featured Requirements
a. Private Transactions and Confidential Contracts
b. Identity and Auditability
c. Interoperability
d. Portability
7. Architecture
8. Application Programming Interface
9. Network Topology
10. Conclusion.
A. Glossary
Does anyone have any suggestions, comments, or feedback on structural changes to the whitepaper to meet some of these philosophical requirements, and to accommodate the umbrella principle? Obviously we are going to have to completely rework the architecture
section, and there has been some good discussion on how we ought to do this. Some of the other sections (API, Network Topology) might need to be eliminated or reworked in some manner. If anyone has suggestions for how to modify the outline/structure of the
whitepaper, I think it would be great to see them. Personally, I am especially interested in getting a consensus on how/where we should incorporate the umbrella structure, and how we want to handle all of the separate projects (i.e. highlight a few, mention
a paragraph about all of them, etc.).
Thanks,
Hart
-----Original Message-----
From:
hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Thomas Hardjono via hyperledger-tsc
Sent: Monday, October 17, 2016 10:40 AM
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives
I think the whitepaper should callout some the "design principles" of Hyperledger, something that the community is contributing to the world -- beyond the lifetime of the Hyperledger projects. Something that people will recall 20 years from now.
Looking at the long history of the IETF ("...running code and rough consensus) it's worth noting that in the early 1990s even the IETF had to work-out (fight over) some design principles for the nascent Internet routing. One of these is the end-to-end principle,
which is now taken for granted.
So in addition to writing code, the Hyperledger community could do well in producing these "design principles of the future blockchain systems".
Some examples (in lay language):
(1) Separation of consensus-making protocol from ledger maintenance mechanisms.
(2) Separation of block syntax from transaction semantics.
(3) Separation of person-identity from transaction-identity.
Etc. etc. Lots more.
I can lend a hand if the TSC needs help writing.
/thomas/
------------------------------------------
Thomas Hardjono
MIT Connection Science & Engineering
connection.mit.edu
------------------------------------------
From:
hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Mark Parzygnat via hyperledger-tsc
Sent: Monday, October 17, 2016 1:29 PM
To: vipin bharathan
Cc:
hyperledger-tsc-bounces@...;
hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives
+1
A benefit of the whitepaper would be to not just call out terms and theories that are equivalent across projects, but include the key differentiators to help guide folks to the appropriate project best suited for their needs and comfort level (code base developed
on, link to key feature sets and what they mean as this should be more living documentation than the white paper itself, etc... probably not a difference in target users).
We've all seen newcomers ask, which project is best for me, or what's the difference....
Regards
vipin bharathan via hyperledger-tsc ---10/17/2016 11:48:55 AM---Hi, The issue of whether the Whitepaper is technical enough for people to get
From: vipin bharathan via hyperledger-tsc <hyperledger-tsc@...>
To: Baohua Yang <yangbaohua@...>
Cc: hyperledger-tsc@...
Date: 10/17/2016 11:48 AM
Subject: Re: [Hyperledger Project TSC] white paper objectives Sent by:
hyperledger-tsc-bounces@...
________________________________________
Hi,
The issue of whether the Whitepaper is technical enough for people to get started and build a working prototype or a vision paper is due to the basic tension between the idea of Hyperledger as an umbrella concept and the fact there are at least two (if not
three with Iroha) specific projects under incubation.
This is further complicated by the fact that the paper had its genesis in the OBC whitepaper.
So, we have to decide what should the Hyperledger whitepaper cover? (NOT what the Fabric, STL, Iroha or Corda whitepaper cover).
As far as the Hyperledger whitepaper, it could be a vision paper with general architectural principles laid out and enough technical discussion on the various points that are generic to all DLTs. Which means not only the currently incubation DLTs but also any
emergent ones . (obviously to a limited extent, as future technical solutions cannot be fully predicted).
Individual DLTs under incubation can have their own technical yellow paper and a whitepaper. The Hyperledger Whitepaper will have a link to a location that have links to Fabric, STL, Iroha whitepapers or include them in the appendix.
Regards,
Vipin
On Oct 17, 2016 11:15 AM, "Baohua Yang via hyperledger-tsc" <hyperledger-tsc@...> wrote:
Love the idea, however, this may results in late WP releasing and more efforts.
On the other hand, the joining of new projects are still happening often, will we wait when it's more stable?
We can certainly add briefs of each existing project's scope, however.
On Mon, Oct 17, 2016 at 10:43 AM, Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote:
I agree that the Hyperledger Project Whitepaper should provide enough info to point people in the right direction to get started using the technology. Should each project under the umbrella receive a paragraph where they state their objectives and goals and
link to the project’s specific whitepaper? It may be nice to come up with a standard feature matrix that each project could fill out based on the common vocabulary defined in the whitepaper. For example, private/public, smart contracts, consensus algorithm,
etc. These may require a living part of the paper so it may make sense to maintain the into elsewhere. What I'd like to see though is a single 'quick overview' of each project without having to delve into each project's individual whitepaper.
-Sheehan
On Sun, Oct 16, 2016 at 9:36 PM, Richard Brown via hyperledger-tsc <hyperledger-tsc@...> wrote:
I agree with the points made below. To my mind, it feels like there should be a logical progression across a series of papers:
• Hyperledger Project Whitepaper (the thing we’re currently discussing I guess!)
o This should be the technical ‘manifesto’ for the Project. What do we believe? What problems are we solving? What are the defining characteristics of the field and the aspects that unite us?
o The reader of this paper should be left understanding exactly what the project is for, what it means for a codebase to be part of the project and where the project is going
o For those who haven’t seen it, we tried to do this – but in a more narrow sense – in the first sections of the introductory whitepaper for Corda (http://r3cev.com/s/corda-introductory-whitepaper-final.pdf).
Chapters 2 and 3 (Context and Vision) are our attempt at describing what we think defines the distributed ledger space, what problems this tech can solve and it does so from the context of financial services.
o Perhaps something like that but written more broadly/expansively is called for?
• Whitepapers for specific Hyperledger Project projects
o ie a Fabric whitepaper, an STL whitepaper, etc, etc, etc.
o A reader of one of these papers should come away understanding that platform’s unique objectives, design and architecture.
o The paper should probably reference the overall Project whitepaper but the purpose of these whitepapers is to leave the reader with complete clarity as to the overall design/architecture/purpose/objectives of a particular codebase.
Richard
Richard Gendal Brown
R3 | Chief Technology Officer
City Tower, Floor Fifteen
40 Basinghall Street
London, EC2V 5DE
Cell: +44 776 466 6821
richard@... |
www.r3cev.com
Email Disclaimer
From: <hyperledger-tsc-bounces@...> on behalf of Christopher Ferris via hyperledger-tsc <hyperledger-tsc@...>
Reply-To: Christopher Ferris <chris.ferris@...>
Date: Thursday, 13 October 2016 at 16:42
To: Hart Montgomery <hmontgomery@...>
Cc: "hyperledger-tsc@..." <hyperledger-tsc@...>
Subject: Re: [Hyperledger Project TSC] white paper objectives
Mic, thanks for starting this thread.
Hart, I tend to think that #1 is definitely a target audience, and that #2 is a subset of #1 that will actually get their hands dirty.
So, basically, I think of this as providing the concepts that Mic outlined (I tend to agree that this should be the scope) and that we provide enough meat to point people in the right direction to get started either collaborating or using the technologies we
are collectively creating.
It should also be a call to action for others to come play.
Chris
On Thu, Oct 13, 2016 at 5:31 PM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thank you for the objective summary Mic. To follow up on this, I think it’s also important to consider what audience we are targeting. Are we intending the whitepaper for:
1. People who are not currently involved in Hyperledger. In this case, the whitepaper is essentially a technical marketing document designed to drive interest in Hyperledger. We list the features and some of the vision, but keep everything very high-level.
2. People who are getting started using Hyperledger. This was (in my opinion—I obviously didn’t write the OBC whitepaper) the initial conception of the whitepaper, as it focused on basic technical details and features, and was a good first read for
a technical person who wanted to understand how Hyperledger worked. However, as Hyperledger has matured and the whitepaper has moved away from the original IBM OBC whitepaper, this is not totally the focus anymore (and doesn’t necessarily have to be), although
new Hyperledger users still seem to be the main audience of the current whitepaper.
3. Current Hyperledger developers/users. If this is the case, the document becomes a sort of manifesto, and we would want to focus on high-level architectural requirements, vision, and goals of the project. The whitepaper’s current emphasis on modular
structure seems to fall somewhat into this category.
I don’t think there is a right or wrong answer here, and we could obviously mix and match who we are targeting (i.e. some sections target #1, others #2). However, it would be nice to know what the community and TSC think the audience of the whitepaper should
be, as the expected audience will heavily impact how we need to rewrite the whitepaper.
Thank you all for your time, and have a great day.
Hart
From:
hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Bowman, Mic via hyperledger-tsc
Sent: Thursday, October 13, 2016 7:34 AM
To: hyperledger-tsc@...
Subject: [Hyperledger Project TSC] white paper objectives
Per our discussion in the TSC call this morning about getting clarity for the purpose & objectives of the HLP white paper.
Here are the “candidate” objectives for the white paper we’ve been discussing in the white paper working group. We felt like these reflected the various high level comments provided during the feedback session a couple weeks ago. These are intended as a starting
point for the discussion.
• Call for action to back and drive the HLP as the preeminent means for advancing distributed ledger technologies
• Capture the concepts of the 'Umbrella organization' and clarify
• Establish a common vocabulary for discussing technology and usages
• Establish a future vision of HLP… where do we see HLP 1, 2, 4 years from now
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
Best wishes!
Baohua Yang
https://yeasy.github.io
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
Hart Montgomery <hmontgomery@...>
I agree with Mic here. In the long term, it would be nice to have some sort of outline of APIs and modules for “core” Hyperledger projects (although exact APIs and technical details should be left out), but, given as we don’t even know exactly what these will look like, it’s probably best to leave this for later. I’m becoming more and more in favor of a high-level whitepaper that encompasses the whole project (a “manifesto”, if you will), and then individual whitepapers for each project that go into more technical details about the architecture/functionality of a given project. Additionally, we could have an architecture document (probably coming from the architecture WG) that would eventually define some of the core modules and APIs between projects. The original point of the featured requirements section was to tell people some of the cool things that we expected Hyperledger to be able to do. It would be nice to do something that accomplished this in the whitepaper (we do want to convince people to use Hyperledger), but I’m not entirely sure how we want to present this, given that some “featured requirements” might not be in every project. Thoughts? I’d love to hear comments/suggestions. Thanks, Hart
From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Bowman, Mic via hyperledger-tsc
Sent: Wednesday, October 19, 2016 7:30 AM
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives I think documenting some common “capabilities” might be reasonable. However… with the diversity of projects that already exist in HL, defining APIs in a white paper would likely derail any attempt to complete the white paper. I would strongly prefer to move all details about the projects and APIs out of the initial white paper. Those are documents that need to be written, but we’ve been unable to complete the existing WP because 1) the projects are a moving target and 2) because the project has become an umbrella, the use of any project leads to misrepresentation of others. I’m all in favor of documenting projects, components, etc… However… We’ve been working on the WP for six months & need to wrap it up. My suggestion is that, for the current high level white paper, we keep project-specific details out, and focus on what Hyperledger working group is about. And… we separately work to develop an architecture document (which Ram is working towards in the Arch WG) and strongly encourage each project to put together a high level description and we put together some form of “comparative analysis” for the projects to help with the selection of a particular platform. --mic From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Sheehan Anderson via hyperledger-tsc
Sent: Tuesday, October 18, 2016 6:59 PM
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives Good idea, I agree that documenting functional modules would be a better approach. I think sketching provisional APIs is a good idea, I’m just not sure if it makes sense to try something in the near term or wait for projects to continue to mature and hope that some thinking around APIs may naturally converge as good ideas prove themselves in the real world. On Tue, Oct 18, 2016 at 7:51 AM, Joseph Lubin via hyperledger-tsc <hyperledger-tsc@...> wrote: +1 to your note, Sheehan. > Does this sound like a reasonable approach for the “Featured Requirements” (need to think of a different name) section? If so, I think the next step would be to come up with a list of X vs Y choices and then work with proponents of a particular design decision to accurately document its merits and potential drawbacks. Rather than a list of X vs. Y (which is a good start), perhaps it makes sense to define functional modules, and enumerate approaches within each function. In a modular, plug-and-play approach, each module's interface can be defined and then one or more components can be implemented for that module. E.g. if you define a consensus module, you can build components for permissionless networks in the categories of proof of work and proof of stake, and you can also build components for round robin validation, random selection validation, pBFT, Paxos/Raft, etc, in more strongly governed or constrained contexts. > I feel that sections 7, 8, and 9 are potentially too specific and would need to live in each individual project’s whitepaper. Maybe there would be some standards around these in the future, but it’s still very early. Provisional APIs could perhaps be sketched at the module level. On Mon, Oct 17, 2016 at 11:38 PM Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote: I think the “Featured Requirements” section is too opinionated currently given the umbrella nature of Hyperledger. Perhaps this would be a good location to introduce the common vocabulary that Mic suggested and introduce users to various choices surrounding blockchain projects including why one may make a particular choice. These would be choices such as public membership vs restricted membership, pseudo anonymous vs auditable identities, turing complete smart contracts vs limited scripting, etc. There are sub-items here also, for example smart contracts may always execute on every peer vs executing on a specified subset of peers. The blockchain community is quite polarized over many of these decisions currently and I think if an umbrella project is to succeed vs one chain to rule them all, it will be important for the members to have an agreed upon view on the merits of various design choices so it does not feel like an collection of competing projects. Does this sound like a reasonable approach for the “Featured Requirements” (need to think of a different name) section? If so, I think the next step would be to come up with a list of X vs Y choices and then work with proponents of a particular design decision to accurately document its merits and potential drawbacks. I feel that sections 7, 8, and 9 are potentially too specific and would need to live in each individual project’s whitepaper. Maybe there would be some standards around these in the future, but it’s still very early. On Mon, Oct 17, 2016 at 3:02 PM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@...> wrote: Thanks everyone for the comments and feedback. It's been really nice for me to hear some of the ideas from the community, and I'm sure others in the whitepaper WG would agree. There has been a lot of discussion about the overall philosophy of the whitepaper, which has been great, but it would also be nice to tie some of this discussion down concretely.
Below is the current outline of the whitepaper:
1. Abstract
2. Background
3. Why a New Blockchain? (Why Hyperledger?)
4. Our Vision
5. Industry Use Cases
a. Financial Asset Depository
b. Corporate Action
c. Supply Chain
d. Master Data Management
e. Sharing Economy and Internet of Things
6. Featured Requirements
a. Private Transactions and Confidential Contracts
b. Identity and Auditability
c. Interoperability
d. Portability
7. Architecture
8. Application Programming Interface
9. Network Topology
10. Conclusion.
A. Glossary
Does anyone have any suggestions, comments, or feedback on structural changes to the whitepaper to meet some of these philosophical requirements, and to accommodate the umbrella principle? Obviously we are going to have to completely rework the architecture section, and there has been some good discussion on how we ought to do this. Some of the other sections (API, Network Topology) might need to be eliminated or reworked in some manner. If anyone has suggestions for how to modify the outline/structure of the whitepaper, I think it would be great to see them. Personally, I am especially interested in getting a consensus on how/where we should incorporate the umbrella structure, and how we want to handle all of the separate projects (i.e. highlight a few, mention a paragraph about all of them, etc.).
Thanks,
Hart -----Original Message-----
From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Thomas Hardjono via hyperledger-tsc
Sent: Monday, October 17, 2016 10:40 AM
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives
I think the whitepaper should callout some the "design principles" of Hyperledger, something that the community is contributing to the world -- beyond the lifetime of the Hyperledger projects. Something that people will recall 20 years from now.
Looking at the long history of the IETF ("...running code and rough consensus) it's worth noting that in the early 1990s even the IETF had to work-out (fight over) some design principles for the nascent Internet routing. One of these is the end-to-end principle, which is now taken for granted.
So in addition to writing code, the Hyperledger community could do well in producing these "design principles of the future blockchain systems".
Some examples (in lay language):
(1) Separation of consensus-making protocol from ledger maintenance mechanisms.
(2) Separation of block syntax from transaction semantics.
(3) Separation of person-identity from transaction-identity.
Etc. etc. Lots more.
I can lend a hand if the TSC needs help writing.
/thomas/
------------------------------------------
Thomas Hardjono
MIT Connection Science & Engineering
connection.mit.edu
------------------------------------------
From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Mark Parzygnat via hyperledger-tsc
Sent: Monday, October 17, 2016 1:29 PM
To: vipin bharathan
Cc: hyperledger-tsc-bounces@...; hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives
+1
A benefit of the whitepaper would be to not just call out terms and theories that are equivalent across projects, but include the key differentiators to help guide folks to the appropriate project best suited for their needs and comfort level (code base developed on, link to key feature sets and what they mean as this should be more living documentation than the white paper itself, etc... probably not a difference in target users).
We've all seen newcomers ask, which project is best for me, or what's the difference....
Regards
vipin bharathan via hyperledger-tsc ---10/17/2016 11:48:55 AM---Hi, The issue of whether the Whitepaper is technical enough for people to get
From: vipin bharathan via hyperledger-tsc <hyperledger-tsc@...>
To: Baohua Yang <yangbaohua@...>
Cc: hyperledger-tsc@...
Date: 10/17/2016 11:48 AM
Subject: Re: [Hyperledger Project TSC] white paper objectives Sent by: hyperledger-tsc-bounces@...
________________________________________
Hi,
The issue of whether the Whitepaper is technical enough for people to get started and build a working prototype or a vision paper is due to the basic tension between the idea of Hyperledger as an umbrella concept and the fact there are at least two (if not three with Iroha) specific projects under incubation.
This is further complicated by the fact that the paper had its genesis in the OBC whitepaper.
So, we have to decide what should the Hyperledger whitepaper cover? (NOT what the Fabric, STL, Iroha or Corda whitepaper cover).
As far as the Hyperledger whitepaper, it could be a vision paper with general architectural principles laid out and enough technical discussion on the various points that are generic to all DLTs. Which means not only the currently incubation DLTs but also any emergent ones . (obviously to a limited extent, as future technical solutions cannot be fully predicted).
Individual DLTs under incubation can have their own technical yellow paper and a whitepaper. The Hyperledger Whitepaper will have a link to a location that have links to Fabric, STL, Iroha whitepapers or include them in the appendix.
Regards,
Vipin
On Oct 17, 2016 11:15 AM, "Baohua Yang via hyperledger-tsc" <hyperledger-tsc@...> wrote:
Love the idea, however, this may results in late WP releasing and more efforts.
On the other hand, the joining of new projects are still happening often, will we wait when it's more stable?
We can certainly add briefs of each existing project's scope, however.
On Mon, Oct 17, 2016 at 10:43 AM, Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote:
I agree that the Hyperledger Project Whitepaper should provide enough info to point people in the right direction to get started using the technology. Should each project under the umbrella receive a paragraph where they state their objectives and goals and link to the project’s specific whitepaper? It may be nice to come up with a standard feature matrix that each project could fill out based on the common vocabulary defined in the whitepaper. For example, private/public, smart contracts, consensus algorithm, etc. These may require a living part of the paper so it may make sense to maintain the into elsewhere. What I'd like to see though is a single 'quick overview' of each project without having to delve into each project's individual whitepaper.
-Sheehan
On Sun, Oct 16, 2016 at 9:36 PM, Richard Brown via hyperledger-tsc <hyperledger-tsc@...> wrote:
I agree with the points made below. To my mind, it feels like there should be a logical progression across a series of papers:
• Hyperledger Project Whitepaper (the thing we’re currently discussing I guess!)
o This should be the technical ‘manifesto’ for the Project. What do we believe? What problems are we solving? What are the defining characteristics of the field and the aspects that unite us?
o The reader of this paper should be left understanding exactly what the project is for, what it means for a codebase to be part of the project and where the project is going
o For those who haven’t seen it, we tried to do this – but in a more narrow sense – in the first sections of the introductory whitepaper for Corda (http://r3cev.com/s/corda-introductory-whitepaper-final.pdf). Chapters 2 and 3 (Context and Vision) are our attempt at describing what we think defines the distributed ledger space, what problems this tech can solve and it does so from the context of financial services.
o Perhaps something like that but written more broadly/expansively is called for?
• Whitepapers for specific Hyperledger Project projects
o ie a Fabric whitepaper, an STL whitepaper, etc, etc, etc.
o A reader of one of these papers should come away understanding that platform’s unique objectives, design and architecture.
o The paper should probably reference the overall Project whitepaper but the purpose of these whitepapers is to leave the reader with complete clarity as to the overall design/architecture/purpose/objectives of a particular codebase.
Richard
Richard Gendal Brown
R3 | Chief Technology Officer
City Tower, Floor Fifteen
40 Basinghall Street
London, EC2V 5DE
Cell: +44 776 466 6821
richard@... | www.r3cev.com
Email Disclaimer
From: <hyperledger-tsc-bounces@...> on behalf of Christopher Ferris via hyperledger-tsc <hyperledger-tsc@...>
Reply-To: Christopher Ferris <chris.ferris@...>
Date: Thursday, 13 October 2016 at 16:42
To: Hart Montgomery <hmontgomery@...>
Cc: "hyperledger-tsc@..." <hyperledger-tsc@...>
Subject: Re: [Hyperledger Project TSC] white paper objectives
Mic, thanks for starting this thread.
Hart, I tend to think that #1 is definitely a target audience, and that #2 is a subset of #1 that will actually get their hands dirty.
So, basically, I think of this as providing the concepts that Mic outlined (I tend to agree that this should be the scope) and that we provide enough meat to point people in the right direction to get started either collaborating or using the technologies we are collectively creating.
It should also be a call to action for others to come play.
Chris
On Thu, Oct 13, 2016 at 5:31 PM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thank you for the objective summary Mic. To follow up on this, I think it’s also important to consider what audience we are targeting. Are we intending the whitepaper for:
1. People who are not currently involved in Hyperledger. In this case, the whitepaper is essentially a technical marketing document designed to drive interest in Hyperledger. We list the features and some of the vision, but keep everything very high-level.
2. People who are getting started using Hyperledger. This was (in my opinion—I obviously didn’t write the OBC whitepaper) the initial conception of the whitepaper, as it focused on basic technical details and features, and was a good first read for a technical person who wanted to understand how Hyperledger worked. However, as Hyperledger has matured and the whitepaper has moved away from the original IBM OBC whitepaper, this is not totally the focus anymore (and doesn’t necessarily have to be), although new Hyperledger users still seem to be the main audience of the current whitepaper.
3. Current Hyperledger developers/users. If this is the case, the document becomes a sort of manifesto, and we would want to focus on high-level architectural requirements, vision, and goals of the project. The whitepaper’s current emphasis on modular structure seems to fall somewhat into this category.
I don’t think there is a right or wrong answer here, and we could obviously mix and match who we are targeting (i.e. some sections target #1, others #2). However, it would be nice to know what the community and TSC think the audience of the whitepaper should be, as the expected audience will heavily impact how we need to rewrite the whitepaper.
Thank you all for your time, and have a great day.
Hart
From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Bowman, Mic via hyperledger-tsc
Sent: Thursday, October 13, 2016 7:34 AM
To: hyperledger-tsc@...
Subject: [Hyperledger Project TSC] white paper objectives
Per our discussion in the TSC call this morning about getting clarity for the purpose & objectives of the HLP white paper.
Here are the “candidate” objectives for the white paper we’ve been discussing in the white paper working group. We felt like these reflected the various high level comments provided during the feedback session a couple weeks ago. These are intended as a starting point for the discussion.
• Call for action to back and drive the HLP as the preeminent means for advancing distributed ledger technologies
• Capture the concepts of the 'Umbrella organization' and clarify
• Establish a common vocabulary for discussing technology and usages
• Establish a future vision of HLP… where do we see HLP 1, 2, 4 years from now
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
Best wishes!
Baohua Yang
https://yeasy.github.io
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
|
|
|
Agree with Mic. The comparative analysis or the specifics of each DLT platform should be kept out of the White Paper and included in the Architecture Document.
We could provide a reference to it in the White paper as a natural progression for any new comers.
Thanks
Murali
toggle quoted message
Show quoted text
From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...]
On Behalf Of Bowman, Mic via hyperledger-tsc
Sent: Wednesday, October 19, 2016 10:30 AM
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives
I think documenting some common “capabilities” might be reasonable. However… with the diversity of projects that already exist in HL, defining APIs in a white
paper would likely derail any attempt to complete the white paper. I would strongly prefer to move all details about the projects and APIs out of the initial white paper. Those are documents that need to be written, but we’ve been unable to complete the existing
WP because 1) the projects are a moving target and 2) because the project has become an umbrella, the use of any project leads to misrepresentation of others.
I’m all in favor of documenting projects, components, etc…
However… We’ve been working on the WP for six months & need to wrap it up. My suggestion is that, for the current high level white paper, we keep project-specific
details out, and focus on what Hyperledger working group is about. And… we separately work to develop an architecture document (which Ram is working towards in the Arch WG) and strongly encourage each project to put together a high level description and we
put together some form of “comparative analysis” for the projects to help with the selection of a particular platform.
--mic
From:
hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...]
On Behalf Of Sheehan Anderson via hyperledger-tsc
Sent: Tuesday, October 18, 2016 6:59 PM
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives
Good idea, I agree that documenting functional modules would be a better approach.
I think sketching provisional APIs is a good idea, I’m just not sure if it makes sense to try something in the near term or wait for projects to continue to mature and hope that some thinking around APIs may naturally converge as good ideas
prove themselves in the real world.
On Tue, Oct 18, 2016 at 7:51 AM, Joseph Lubin via hyperledger-tsc <hyperledger-tsc@...> wrote:
+1 to your note, Sheehan.
> Does this sound like a reasonable approach for the “Featured Requirements” (need to think of a different name) section? If so, I think the next step would be to come up with a list of X vs Y choices and then work with proponents of a
particular design decision to accurately document its merits and potential drawbacks.
Rather than a list of X vs. Y (which is a good start), perhaps it makes sense to define functional modules, and enumerate approaches within each function.
In a modular, plug-and-play approach, each module's interface can be defined and then one or more components can be implemented for that module. E.g. if you define a consensus module, you can build components for permissionless networks
in the categories of proof of work and proof of stake, and you can also build components for round robin validation, random selection validation, pBFT, Paxos/Raft, etc, in more strongly governed or constrained contexts.
> I feel that sections 7, 8, and 9 are potentially too specific and would need to live in each individual project’s whitepaper. Maybe there would be some standards around these in the future, but it’s still very early.
Provisional APIs could perhaps be sketched at the module level.
On Mon, Oct 17, 2016 at 11:38 PM Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote:
I think the “Featured Requirements” section is too opinionated currently given the umbrella nature of Hyperledger. Perhaps this would be a good location to introduce the common vocabulary that Mic suggested and introduce users to various
choices surrounding blockchain projects including why one may make a particular choice. These would be choices such as public membership vs restricted membership, pseudo anonymous vs auditable identities, turing complete smart contracts vs limited scripting,
etc. There are sub-items here also, for example smart contracts may always execute on every peer vs executing on a specified subset of peers.
The blockchain community is quite polarized over many of these decisions currently and I think if an umbrella project is to succeed vs one chain to rule them all, it will be important for the members to have an agreed upon view on the merits
of various design choices so it does not feel like an collection of competing projects.
Does this sound like a reasonable approach for the “Featured Requirements” (need to think of a different name) section? If so, I think the next step would be to come up with a list of X vs Y choices and then work with proponents of a particular
design decision to accurately document its merits and potential drawbacks.
I feel that sections 7, 8, and 9 are potentially too specific and would need to live in each individual project’s whitepaper. Maybe there would be some standards around these in the future, but it’s still very early.
On Mon, Oct 17, 2016 at 3:02 PM, Hart Montgomery via hyperledger-tsc
<hyperledger-tsc@...> wrote:
Thanks everyone for the comments and feedback. It's been really nice for me to hear some of the ideas from the community, and I'm sure others in the whitepaper WG would agree. There has been a lot of discussion about the overall philosophy
of the whitepaper, which has been great, but it would also be nice to tie some of this discussion down concretely.
Below is the current outline of the whitepaper:
1. Abstract
2. Background
3. Why a New Blockchain? (Why Hyperledger?)
4. Our Vision
5. Industry Use Cases
a. Financial Asset Depository
b. Corporate Action
c. Supply Chain
d. Master Data Management
e. Sharing Economy and Internet of Things
6. Featured Requirements
a. Private Transactions and Confidential Contracts
b. Identity and Auditability
c. Interoperability
d. Portability
7. Architecture
8. Application Programming Interface
9. Network Topology
10. Conclusion.
A. Glossary
Does anyone have any suggestions, comments, or feedback on structural changes to the whitepaper to meet some of these philosophical requirements, and to accommodate the umbrella principle? Obviously we are going to have to completely rework the architecture
section, and there has been some good discussion on how we ought to do this. Some of the other sections (API, Network Topology) might need to be eliminated or reworked in some manner. If anyone has suggestions for how to modify the outline/structure of the
whitepaper, I think it would be great to see them. Personally, I am especially interested in getting a consensus on how/where we should incorporate the umbrella structure, and how we want to handle all of the separate projects (i.e. highlight a few, mention
a paragraph about all of them, etc.).
Thanks,
Hart
-----Original Message-----
From:
hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Thomas Hardjono via hyperledger-tsc
Sent: Monday, October 17, 2016 10:40 AM
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives
I think the whitepaper should callout some the "design principles" of Hyperledger, something that the community is contributing to the world -- beyond the lifetime of the Hyperledger projects. Something that people will recall 20 years from now.
Looking at the long history of the IETF ("...running code and rough consensus) it's worth noting that in the early 1990s even the IETF had to work-out (fight over) some design principles for the nascent Internet routing. One of these is the end-to-end principle,
which is now taken for granted.
So in addition to writing code, the Hyperledger community could do well in producing these "design principles of the future blockchain systems".
Some examples (in lay language):
(1) Separation of consensus-making protocol from ledger maintenance mechanisms.
(2) Separation of block syntax from transaction semantics.
(3) Separation of person-identity from transaction-identity.
Etc. etc. Lots more.
I can lend a hand if the TSC needs help writing.
/thomas/
------------------------------------------
Thomas Hardjono
MIT Connection Science & Engineering
connection.mit.edu
------------------------------------------
From:
hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Mark Parzygnat via hyperledger-tsc
Sent: Monday, October 17, 2016 1:29 PM
To: vipin bharathan
Cc:
hyperledger-tsc-bounces@...;
hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives
+1
A benefit of the whitepaper would be to not just call out terms and theories that are equivalent across projects, but include the key differentiators to help guide folks to the appropriate project best suited for their needs and comfort level (code base developed
on, link to key feature sets and what they mean as this should be more living documentation than the white paper itself, etc... probably not a difference in target users).
We've all seen newcomers ask, which project is best for me, or what's the difference....
Regards
vipin bharathan via hyperledger-tsc ---10/17/2016 11:48:55 AM---Hi, The issue of whether the Whitepaper is technical enough for people to get
From: vipin bharathan via hyperledger-tsc <hyperledger-tsc@...>
To: Baohua Yang <yangbaohua@...>
Cc: hyperledger-tsc@...
Date: 10/17/2016 11:48 AM
Subject: Re: [Hyperledger Project TSC] white paper objectives Sent by:
hyperledger-tsc-bounces@...
________________________________________
Hi,
The issue of whether the Whitepaper is technical enough for people to get started and build a working prototype or a vision paper is due to the basic tension between the idea of Hyperledger as an umbrella concept and the fact there are at least two (if not
three with Iroha) specific projects under incubation.
This is further complicated by the fact that the paper had its genesis in the OBC whitepaper.
So, we have to decide what should the Hyperledger whitepaper cover? (NOT what the Fabric, STL, Iroha or Corda whitepaper cover).
As far as the Hyperledger whitepaper, it could be a vision paper with general architectural principles laid out and enough technical discussion on the various points that are generic to all DLTs. Which means not only the currently incubation DLTs but also any
emergent ones . (obviously to a limited extent, as future technical solutions cannot be fully predicted).
Individual DLTs under incubation can have their own technical yellow paper and a whitepaper. The Hyperledger Whitepaper will have a link to a location that have links to Fabric, STL, Iroha whitepapers or include them in the appendix.
Regards,
Vipin
On Oct 17, 2016 11:15 AM, "Baohua Yang via hyperledger-tsc" <hyperledger-tsc@...> wrote:
Love the idea, however, this may results in late WP releasing and more efforts.
On the other hand, the joining of new projects are still happening often, will we wait when it's more stable?
We can certainly add briefs of each existing project's scope, however.
On Mon, Oct 17, 2016 at 10:43 AM, Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote:
I agree that the Hyperledger Project Whitepaper should provide enough info to point people in the right direction to get started using the technology. Should each project under the umbrella receive a paragraph where they state their objectives and goals and
link to the project’s specific whitepaper? It may be nice to come up with a standard feature matrix that each project could fill out based on the common vocabulary defined in the whitepaper. For example, private/public, smart contracts, consensus algorithm,
etc. These may require a living part of the paper so it may make sense to maintain the into elsewhere. What I'd like to see though is a single 'quick overview' of each project without having to delve into each project's individual whitepaper.
-Sheehan
On Sun, Oct 16, 2016 at 9:36 PM, Richard Brown via hyperledger-tsc <hyperledger-tsc@...> wrote:
I agree with the points made below. To my mind, it feels like there should be a logical progression across a series of papers:
• Hyperledger Project Whitepaper (the thing we’re currently discussing I guess!)
o This should be the technical ‘manifesto’ for the Project. What do we believe? What problems are we solving? What are the defining characteristics of the field and the aspects that unite us?
o The reader of this paper should be left understanding exactly what the project is for, what it means for a codebase to be part of the project and where the project is going
o For those who haven’t seen it, we tried to do this – but in a more narrow sense – in the first sections of the introductory whitepaper for Corda (http://r3cev.com/s/corda-introductory-whitepaper-final.pdf).
Chapters 2 and 3 (Context and Vision) are our attempt at describing what we think defines the distributed ledger space, what problems this tech can solve and it does so from the context of financial services.
o Perhaps something like that but written more broadly/expansively is called for?
• Whitepapers for specific Hyperledger Project projects
o ie a Fabric whitepaper, an STL whitepaper, etc, etc, etc.
o A reader of one of these papers should come away understanding that platform’s unique objectives, design and architecture.
o The paper should probably reference the overall Project whitepaper but the purpose of these whitepapers is to leave the reader with complete clarity as to the overall design/architecture/purpose/objectives of a particular codebase.
Richard
Richard Gendal Brown
R3 | Chief Technology Officer
City Tower, Floor Fifteen
40 Basinghall Street
London, EC2V 5DE
Cell: +44 776 466 6821
richard@... |
www.r3cev.com
Email Disclaimer
From: <hyperledger-tsc-bounces@...> on behalf of Christopher Ferris via hyperledger-tsc <hyperledger-tsc@...>
Reply-To: Christopher Ferris <chris.ferris@...>
Date: Thursday, 13 October 2016 at 16:42
To: Hart Montgomery <hmontgomery@...>
Cc: "hyperledger-tsc@..." <hyperledger-tsc@...>
Subject: Re: [Hyperledger Project TSC] white paper objectives
Mic, thanks for starting this thread.
Hart, I tend to think that #1 is definitely a target audience, and that #2 is a subset of #1 that will actually get their hands dirty.
So, basically, I think of this as providing the concepts that Mic outlined (I tend to agree that this should be the scope) and that we provide enough meat to point people in the right direction to get started either collaborating or using the technologies we
are collectively creating.
It should also be a call to action for others to come play.
Chris
On Thu, Oct 13, 2016 at 5:31 PM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thank you for the objective summary Mic. To follow up on this, I think it’s also important to consider what audience we are targeting. Are we intending the whitepaper for:
1. People who are not currently involved in Hyperledger. In this case, the whitepaper is essentially a technical marketing document designed to drive interest in Hyperledger. We list the features and some of the vision, but keep everything very high-level.
2. People who are getting started using Hyperledger. This was (in my opinion—I obviously didn’t write the OBC whitepaper) the initial conception of the whitepaper, as it focused on basic technical details and features, and was a good first read for
a technical person who wanted to understand how Hyperledger worked. However, as Hyperledger has matured and the whitepaper has moved away from the original IBM OBC whitepaper, this is not totally the focus anymore (and doesn’t necessarily have to be), although
new Hyperledger users still seem to be the main audience of the current whitepaper.
3. Current Hyperledger developers/users. If this is the case, the document becomes a sort of manifesto, and we would want to focus on high-level architectural requirements, vision, and goals of the project. The whitepaper’s current emphasis on modular
structure seems to fall somewhat into this category.
I don’t think there is a right or wrong answer here, and we could obviously mix and match who we are targeting (i.e. some sections target #1, others #2). However, it would be nice to know what the community and TSC think the audience of the whitepaper should
be, as the expected audience will heavily impact how we need to rewrite the whitepaper.
Thank you all for your time, and have a great day.
Hart
From:
hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Bowman, Mic via hyperledger-tsc
Sent: Thursday, October 13, 2016 7:34 AM
To: hyperledger-tsc@...
Subject: [Hyperledger Project TSC] white paper objectives
Per our discussion in the TSC call this morning about getting clarity for the purpose & objectives of the HLP white paper.
Here are the “candidate” objectives for the white paper we’ve been discussing in the white paper working group. We felt like these reflected the various high level comments provided during the feedback session a couple weeks ago. These are intended as a starting
point for the discussion.
• Call for action to back and drive the HLP as the preeminent means for advancing distributed ledger technologies
• Capture the concepts of the 'Umbrella organization' and clarify
• Establish a common vocabulary for discussing technology and usages
• Establish a future vision of HLP… where do we see HLP 1, 2, 4 years from now
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
Best wishes!
Baohua Yang
https://yeasy.github.io
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
|
|
|
Tamas Blummer <tamas@...>
I think that the incubated projects did allow for an exploration of the technology, and we might now be in the position to define building blocks, utilities that the technology needs.
It would be great to capture those and show what alternatives the projects explore in their implementation. I think it was premature to fix API for the building blocks though.
TAMAS BLUMMER
CHIEF LEDGER ARCHITECT
Digital Asset
T: +36 1 883 0300
E: tamas@...
W: digitalasset.com
toggle quoted message
Show quoted text
On 19 Oct 2016, at 03:58, Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote:
Good idea, I agree that documenting functional modules would be a better approach.
I think sketching provisional APIs is a good idea, I’m just not sure if it makes sense to try something in the near term or wait for projects to continue to mature and hope that some thinking around APIs may naturally converge as good ideas prove themselves in the real world.
-Sheehan
On Tue, Oct 18, 2016 at 7:51 AM, Joseph Lubin via hyperledger-tsc <hyperledger-tsc@...> wrote:
+1 to your note, Sheehan.
Does this sound like a reasonable approach for the “Featured Requirements” (need to think of a different name) section? If so, I think the next step would be to come up with a list of X vs Y choices and then work with proponents of a particular design decision to accurately document its merits and potential drawbacks. Rather than a list of X vs. Y (which is a good start), perhaps it makes sense to define functional modules, and enumerate approaches within each function.
In a modular, plug-and-play approach, each module's interface can be defined and then one or more components can be implemented for that module. E.g. if you define a consensus module, you can build components for permissionless networks in the categories of proof of work and proof of stake, and you can also build components for round robin validation, random selection validation, pBFT, Paxos/Raft, etc, in more strongly governed or constrained contexts.
I feel that sections 7, 8, and 9 are potentially too specific and would need to live in each individual project’s whitepaper. Maybe there would be some standards around these in the future, but it’s still very early. Provisional APIs could perhaps be sketched at the module level.
On Mon, Oct 17, 2016 at 11:38 PM Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote:
I think the “Featured Requirements” section is too opinionated currently given the umbrella nature of Hyperledger. Perhaps this would be a good location to introduce the common vocabulary that Mic suggested and introduce users to various choices surrounding blockchain projects including why one may make a particular choice. These would be choices such as public membership vs restricted membership, pseudo anonymous vs auditable identities, turing complete smart contracts vs limited scripting, etc. There are sub-items here also, for example smart contracts may always execute on every peer vs executing on a specified subset of peers.
The blockchain community is quite polarized over many of these decisions currently and I think if an umbrella project is to succeed vs one chain to rule them all, it will be important for the members to have an agreed upon view on the merits of various design choices so it does not feel like an collection of competing projects.
Does this sound like a reasonable approach for the “Featured Requirements” (need to think of a different name) section? If so, I think the next step would be to come up with a list of X vs Y choices and then work with proponents of a particular design decision to accurately document its merits and potential drawbacks.
I feel that sections 7, 8, and 9 are potentially too specific and would need to live in each individual project’s whitepaper. Maybe there would be some standards around these in the future, but it’s still very early.
Regards,
-Sheehan
On Mon, Oct 17, 2016 at 3:02 PM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thanks everyone for the comments and feedback. It's been really nice for me to hear some of the ideas from the community, and I'm sure others in the whitepaper WG would agree. There has been a lot of discussion about the overall philosophy of the whitepaper, which has been great, but it would also be nice to tie some of this discussion down concretely.
Below is the current outline of the whitepaper:
1. Abstract
2. Background
3. Why a New Blockchain? (Why Hyperledger?)
4. Our Vision
5. Industry Use Cases
a. Financial Asset Depository
b. Corporate Action
c. Supply Chain
d. Master Data Management
e. Sharing Economy and Internet of Things
6. Featured Requirements
a. Private Transactions and Confidential Contracts
b. Identity and Auditability
c. Interoperability
d. Portability
7. Architecture
8. Application Programming Interface
9. Network Topology
10. Conclusion.
A. Glossary
Does anyone have any suggestions, comments, or feedback on structural changes to the whitepaper to meet some of these philosophical requirements, and to accommodate the umbrella principle? Obviously we are going to have to completely rework the architecture section, and there has been some good discussion on how we ought to do this. Some of the other sections (API, Network Topology) might need to be eliminated or reworked in some manner. If anyone has suggestions for how to modify the outline/structure of the whitepaper, I think it would be great to see them. Personally, I am especially interested in getting a consensus on how/where we should incorporate the umbrella structure, and how we want to handle all of the separate projects (i.e. highlight a few, mention a paragraph about all of them, etc.).
Thanks,
Hart
-----Original Message-----
From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Thomas Hardjono via hyperledger-tsc
Sent: Monday, October 17, 2016 10:40 AM
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives
I think the whitepaper should callout some the "design principles" of Hyperledger, something that the community is contributing to the world -- beyond the lifetime of the Hyperledger projects. Something that people will recall 20 years from now.
Looking at the long history of the IETF ("...running code and rough consensus) it's worth noting that in the early 1990s even the IETF had to work-out (fight over) some design principles for the nascent Internet routing. One of these is the end-to-end principle, which is now taken for granted.
So in addition to writing code, the Hyperledger community could do well in producing these "design principles of the future blockchain systems".
Some examples (in lay language):
(1) Separation of consensus-making protocol from ledger maintenance mechanisms.
(2) Separation of block syntax from transaction semantics.
(3) Separation of person-identity from transaction-identity.
Etc. etc. Lots more.
I can lend a hand if the TSC needs help writing.
/thomas/
------------------------------------------
Thomas Hardjono
MIT Connection Science & Engineering
connection.mit.edu
------------------------------------------
From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Mark Parzygnat via hyperledger-tsc
Sent: Monday, October 17, 2016 1:29 PM
To: vipin bharathan
Cc: hyperledger-tsc-bounces@...; hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives
+1
A benefit of the whitepaper would be to not just call out terms and theories that are equivalent across projects, but include the key differentiators to help guide folks to the appropriate project best suited for their needs and comfort level (code base developed on, link to key feature sets and what they mean as this should be more living documentation than the white paper itself, etc... probably not a difference in target users).
We've all seen newcomers ask, which project is best for me, or what's the difference....
Regards
vipin bharathan via hyperledger-tsc ---10/17/2016 11:48:55 AM---Hi, The issue of whether the Whitepaper is technical enough for people to get
From: vipin bharathan via hyperledger-tsc <hyperledger-tsc@...>
To: Baohua Yang <yangbaohua@...>
Cc: hyperledger-tsc@...
Date: 10/17/2016 11:48 AM
Subject: Re: [Hyperledger Project TSC] white paper objectives Sent by: hyperledger-tsc-bounces@...
________________________________________
Hi,
The issue of whether the Whitepaper is technical enough for people to get started and build a working prototype or a vision paper is due to the basic tension between the idea of Hyperledger as an umbrella concept and the fact there are at least two (if not three with Iroha) specific projects under incubation.
This is further complicated by the fact that the paper had its genesis in the OBC whitepaper.
So, we have to decide what should the Hyperledger whitepaper cover? (NOT what the Fabric, STL, Iroha or Corda whitepaper cover).
As far as the Hyperledger whitepaper, it could be a vision paper with general architectural principles laid out and enough technical discussion on the various points that are generic to all DLTs. Which means not only the currently incubation DLTs but also any emergent ones . (obviously to a limited extent, as future technical solutions cannot be fully predicted).
Individual DLTs under incubation can have their own technical yellow paper and a whitepaper. The Hyperledger Whitepaper will have a link to a location that have links to Fabric, STL, Iroha whitepapers or include them in the appendix.
Regards,
Vipin
On Oct 17, 2016 11:15 AM, "Baohua Yang via hyperledger-tsc" <hyperledger-tsc@...> wrote:
Love the idea, however, this may results in late WP releasing and more efforts.
On the other hand, the joining of new projects are still happening often, will we wait when it's more stable?
We can certainly add briefs of each existing project's scope, however.
On Mon, Oct 17, 2016 at 10:43 AM, Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote:
I agree that the Hyperledger Project Whitepaper should provide enough info to point people in the right direction to get started using the technology. Should each project under the umbrella receive a paragraph where they state their objectives and goals and link to the project’s specific whitepaper? It may be nice to come up with a standard feature matrix that each project could fill out based on the common vocabulary defined in the whitepaper. For example, private/public, smart contracts, consensus algorithm, etc. These may require a living part of the paper so it may make sense to maintain the into elsewhere. What I'd like to see though is a single 'quick overview' of each project without having to delve into each project's individual whitepaper.
-Sheehan
On Sun, Oct 16, 2016 at 9:36 PM, Richard Brown via hyperledger-tsc <hyperledger-tsc@...> wrote:
I agree with the points made below. To my mind, it feels like there should be a logical progression across a series of papers:
• Hyperledger Project Whitepaper (the thing we’re currently discussing I guess!)
o This should be the technical ‘manifesto’ for the Project. What do we believe? What problems are we solving? What are the defining characteristics of the field and the aspects that unite us?
o The reader of this paper should be left understanding exactly what the project is for, what it means for a codebase to be part of the project and where the project is going
o For those who haven’t seen it, we tried to do this – but in a more narrow sense – in the first sections of the introductory whitepaper for Corda (http://r3cev.com/s/corda-introductory-whitepaper-final.pdf). Chapters 2 and 3 (Context and Vision) are our attempt at describing what we think defines the distributed ledger space, what problems this tech can solve and it does so from the context of financial services.
o Perhaps something like that but written more broadly/expansively is called for?
• Whitepapers for specific Hyperledger Project projects
o ie a Fabric whitepaper, an STL whitepaper, etc, etc, etc.
o A reader of one of these papers should come away understanding that platform’s unique objectives, design and architecture.
o The paper should probably reference the overall Project whitepaper but the purpose of these whitepapers is to leave the reader with complete clarity as to the overall design/architecture/purpose/objectives of a particular codebase.
Richard
Richard Gendal Brown
R3 | Chief Technology Officer
City Tower, Floor Fifteen
40 Basinghall Street
London, EC2V 5DE
Cell: +44 776 466 6821
richard@... | www.r3cev.com
Email Disclaimer
From: <hyperledger-tsc-bounces@...> on behalf of Christopher Ferris via hyperledger-tsc <hyperledger-tsc@...>
Reply-To: Christopher Ferris <chris.ferris@...>
Date: Thursday, 13 October 2016 at 16:42
To: Hart Montgomery <hmontgomery@...>
Cc: "hyperledger-tsc@..." <hyperledger-tsc@...>
Subject: Re: [Hyperledger Project TSC] white paper objectives
Mic, thanks for starting this thread.
Hart, I tend to think that #1 is definitely a target audience, and that #2 is a subset of #1 that will actually get their hands dirty.
So, basically, I think of this as providing the concepts that Mic outlined (I tend to agree that this should be the scope) and that we provide enough meat to point people in the right direction to get started either collaborating or using the technologies we are collectively creating.
It should also be a call to action for others to come play.
Chris
On Thu, Oct 13, 2016 at 5:31 PM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thank you for the objective summary Mic. To follow up on this, I think it’s also important to consider what audience we are targeting. Are we intending the whitepaper for:
1. People who are not currently involved in Hyperledger. In this case, the whitepaper is essentially a technical marketing document designed to drive interest in Hyperledger. We list the features and some of the vision, but keep everything very high-level.
2. People who are getting started using Hyperledger. This was (in my opinion—I obviously didn’t write the OBC whitepaper) the initial conception of the whitepaper, as it focused on basic technical details and features, and was a good first read for a technical person who wanted to understand how Hyperledger worked. However, as Hyperledger has matured and the whitepaper has moved away from the original IBM OBC whitepaper, this is not totally the focus anymore (and doesn’t necessarily have to be), although new Hyperledger users still seem to be the main audience of the current whitepaper.
3. Current Hyperledger developers/users. If this is the case, the document becomes a sort of manifesto, and we would want to focus on high-level architectural requirements, vision, and goals of the project. The whitepaper’s current emphasis on modular structure seems to fall somewhat into this category.
I don’t think there is a right or wrong answer here, and we could obviously mix and match who we are targeting (i.e. some sections target #1, others #2). However, it would be nice to know what the community and TSC think the audience of the whitepaper should be, as the expected audience will heavily impact how we need to rewrite the whitepaper.
Thank you all for your time, and have a great day.
Hart
From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Bowman, Mic via hyperledger-tsc
Sent: Thursday, October 13, 2016 7:34 AM
To: hyperledger-tsc@...
Subject: [Hyperledger Project TSC] white paper objectives
Per our discussion in the TSC call this morning about getting clarity for the purpose & objectives of the HLP white paper.
Here are the “candidate” objectives for the white paper we’ve been discussing in the white paper working group. We felt like these reflected the various high level comments provided during the feedback session a couple weeks ago. These are intended as a starting point for the discussion.
• Call for action to back and drive the HLP as the preeminent means for advancing distributed ledger technologies
• Capture the concepts of the 'Umbrella organization' and clarify
• Establish a common vocabulary for discussing technology and usages
• Establish a future vision of HLP… where do we see HLP 1, 2, 4 years from now
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
Best wishes!
Baohua Yang
https://yeasy.github.io
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
-- 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.
|
|
|
Voell, David L <david.l.voell@...>
Just a reminder to please make an effort to attend today’s HLP White Paper working group meeting where special guests Brian Behlendorf and Richard Gendal Brown
along with distinguished members of the working group will be sharing their views on the topics below…
1.
Do we agree on the high level objectives of the white paper?
a.
Call for action to back and drive the HLP as the preeminent means for advancing distributed ledger technologies
b.
Capture the concepts of the 'Umbrella organization' and clarify
c.
Establish a common vocabulary for discussing technology and usages
d.
Establish a future vision of HLP… where do we see HLP 1, 2, 4 years from now
2.
What is the vision of the ‘Umbrella Organization’, near-term and long-term and how do we reconcile that with our desire to establish standards and discourage fragmentation?
3.
Who is our target audience?
4.
What structural changes to the white paper should be considered?
In terms of priority we’ll want to make sure we at least cover the first two topics in this one hour meeting. Looking forward to an active discussion.
Dial-in details for today’s call, 1-2pm (NY).
United States Toll free: 1 866 215 2642
United States International direct: +1 617 597 5043
Passcode:
9324 9799#
Regards,
-Dave
toggle quoted message
Show quoted text
From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...]
On Behalf Of Bowman, Mic via hyperledger-tsc
Sent: Wednesday, October 19, 2016 10:30 AM
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives
I think documenting some common “capabilities” might be reasonable. However… with the diversity of projects that already exist in HL, defining APIs in a white
paper would likely derail any attempt to complete the white paper. I would strongly prefer to move all details about the projects and APIs out of the initial white paper. Those are documents that need to be written, but we’ve been unable to complete the existing
WP because 1) the projects are a moving target and 2) because the project has become an umbrella, the use of any project leads to misrepresentation of others.
I’m all in favor of documenting projects, components, etc…
However… We’ve been working on the WP for six months & need to wrap it up. My suggestion is that, for the current high level white paper, we keep project-specific
details out, and focus on what Hyperledger working group is about. And… we separately work to develop an architecture document (which Ram is working towards in the Arch WG) and strongly encourage each project to put together a high level description and we
put together some form of “comparative analysis” for the projects to help with the selection of a particular platform.
--mic
From:
hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...]
On Behalf Of Sheehan Anderson via hyperledger-tsc
Sent: Tuesday, October 18, 2016 6:59 PM
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives
Good idea, I agree that documenting functional modules would be a better approach.
I think sketching provisional APIs is a good idea, I’m just not sure if it makes sense to try something in the near term or wait for projects to continue to mature and hope that some thinking around APIs may naturally converge as good ideas
prove themselves in the real world.
On Tue, Oct 18, 2016 at 7:51 AM, Joseph Lubin via hyperledger-tsc <hyperledger-tsc@...> wrote:
+1 to your note, Sheehan.
> Does this sound like a reasonable approach for the “Featured Requirements” (need to think of a different name) section? If so, I think the next step would be to come up with a list of X vs Y choices and then work with proponents of a
particular design decision to accurately document its merits and potential drawbacks.
Rather than a list of X vs. Y (which is a good start), perhaps it makes sense to define functional modules, and enumerate approaches within each function.
In a modular, plug-and-play approach, each module's interface can be defined and then one or more components can be implemented for that module. E.g. if you define a consensus module, you can build components for permissionless networks
in the categories of proof of work and proof of stake, and you can also build components for round robin validation, random selection validation, pBFT, Paxos/Raft, etc, in more strongly governed or constrained contexts.
> I feel that sections 7, 8, and 9 are potentially too specific and would need to live in each individual project’s whitepaper. Maybe there would be some standards around these in the future, but it’s still very early.
Provisional APIs could perhaps be sketched at the module level.
On Mon, Oct 17, 2016 at 11:38 PM Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote:
I think the “Featured Requirements” section is too opinionated currently given the umbrella nature of Hyperledger. Perhaps this would be a good location to introduce the common vocabulary that Mic suggested and introduce users to various
choices surrounding blockchain projects including why one may make a particular choice. These would be choices such as public membership vs restricted membership, pseudo anonymous vs auditable identities, turing complete smart contracts vs limited scripting,
etc. There are sub-items here also, for example smart contracts may always execute on every peer vs executing on a specified subset of peers.
The blockchain community is quite polarized over many of these decisions currently and I think if an umbrella project is to succeed vs one chain to rule them all, it will be important for the members to have an agreed upon view on the merits
of various design choices so it does not feel like an collection of competing projects.
Does this sound like a reasonable approach for the “Featured Requirements” (need to think of a different name) section? If so, I think the next step would be to come up with a list of X vs Y choices and then work with proponents of a particular
design decision to accurately document its merits and potential drawbacks.
I feel that sections 7, 8, and 9 are potentially too specific and would need to live in each individual project’s whitepaper. Maybe there would be some standards around these in the future, but it’s still very early.
On Mon, Oct 17, 2016 at 3:02 PM, Hart Montgomery via hyperledger-tsc
<hyperledger-tsc@...> wrote:
Thanks everyone for the comments and feedback. It's been really nice for me to hear some of the ideas from the community, and I'm sure others in the whitepaper WG would agree. There has been a lot of discussion about the overall philosophy
of the whitepaper, which has been great, but it would also be nice to tie some of this discussion down concretely.
Below is the current outline of the whitepaper:
1. Abstract
2. Background
3. Why a New Blockchain? (Why Hyperledger?)
4. Our Vision
5. Industry Use Cases
a. Financial Asset Depository
b. Corporate Action
c. Supply Chain
d. Master Data Management
e. Sharing Economy and Internet of Things
6. Featured Requirements
a. Private Transactions and Confidential Contracts
b. Identity and Auditability
c. Interoperability
d. Portability
7. Architecture
8. Application Programming Interface
9. Network Topology
10. Conclusion.
A. Glossary
Does anyone have any suggestions, comments, or feedback on structural changes to the whitepaper to meet some of these philosophical requirements, and to accommodate the umbrella principle? Obviously we are going to have to completely rework the architecture
section, and there has been some good discussion on how we ought to do this. Some of the other sections (API, Network Topology) might need to be eliminated or reworked in some manner. If anyone has suggestions for how to modify the outline/structure of the
whitepaper, I think it would be great to see them. Personally, I am especially interested in getting a consensus on how/where we should incorporate the umbrella structure, and how we want to handle all of the separate projects (i.e. highlight a few, mention
a paragraph about all of them, etc.).
Thanks,
Hart
-----Original Message-----
From:
hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Thomas Hardjono via hyperledger-tsc
Sent: Monday, October 17, 2016 10:40 AM
To: hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives
I think the whitepaper should callout some the "design principles" of Hyperledger, something that the community is contributing to the world -- beyond the lifetime of the Hyperledger projects. Something that people will recall 20 years from now.
Looking at the long history of the IETF ("...running code and rough consensus) it's worth noting that in the early 1990s even the IETF had to work-out (fight over) some design principles for the nascent Internet routing. One of these is the end-to-end principle,
which is now taken for granted.
So in addition to writing code, the Hyperledger community could do well in producing these "design principles of the future blockchain systems".
Some examples (in lay language):
(1) Separation of consensus-making protocol from ledger maintenance mechanisms.
(2) Separation of block syntax from transaction semantics.
(3) Separation of person-identity from transaction-identity.
Etc. etc. Lots more.
I can lend a hand if the TSC needs help writing.
/thomas/
------------------------------------------
Thomas Hardjono
MIT Connection Science & Engineering
connection.mit.edu
------------------------------------------
From:
hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Mark Parzygnat via hyperledger-tsc
Sent: Monday, October 17, 2016 1:29 PM
To: vipin bharathan
Cc:
hyperledger-tsc-bounces@...;
hyperledger-tsc@...
Subject: Re: [Hyperledger Project TSC] white paper objectives
+1
A benefit of the whitepaper would be to not just call out terms and theories that are equivalent across projects, but include the key differentiators to help guide folks to the appropriate project best suited for their needs and comfort level (code base developed
on, link to key feature sets and what they mean as this should be more living documentation than the white paper itself, etc... probably not a difference in target users).
We've all seen newcomers ask, which project is best for me, or what's the difference....
Regards
vipin bharathan via hyperledger-tsc ---10/17/2016 11:48:55 AM---Hi, The issue of whether the Whitepaper is technical enough for people to get
From: vipin bharathan via hyperledger-tsc <hyperledger-tsc@...>
To: Baohua Yang <yangbaohua@...>
Cc: hyperledger-tsc@...
Date: 10/17/2016 11:48 AM
Subject: Re: [Hyperledger Project TSC] white paper objectives Sent by:
hyperledger-tsc-bounces@...
________________________________________
Hi,
The issue of whether the Whitepaper is technical enough for people to get started and build a working prototype or a vision paper is due to the basic tension between the idea of Hyperledger as an umbrella concept and the fact there are at least two (if not
three with Iroha) specific projects under incubation.
This is further complicated by the fact that the paper had its genesis in the OBC whitepaper.
So, we have to decide what should the Hyperledger whitepaper cover? (NOT what the Fabric, STL, Iroha or Corda whitepaper cover).
As far as the Hyperledger whitepaper, it could be a vision paper with general architectural principles laid out and enough technical discussion on the various points that are generic to all DLTs. Which means not only the currently incubation DLTs but also any
emergent ones . (obviously to a limited extent, as future technical solutions cannot be fully predicted).
Individual DLTs under incubation can have their own technical yellow paper and a whitepaper. The Hyperledger Whitepaper will have a link to a location that have links to Fabric, STL, Iroha whitepapers or include them in the appendix.
Regards,
Vipin
On Oct 17, 2016 11:15 AM, "Baohua Yang via hyperledger-tsc" <hyperledger-tsc@...> wrote:
Love the idea, however, this may results in late WP releasing and more efforts.
On the other hand, the joining of new projects are still happening often, will we wait when it's more stable?
We can certainly add briefs of each existing project's scope, however.
On Mon, Oct 17, 2016 at 10:43 AM, Sheehan Anderson via hyperledger-tsc <hyperledger-tsc@...> wrote:
I agree that the Hyperledger Project Whitepaper should provide enough info to point people in the right direction to get started using the technology. Should each project under the umbrella receive a paragraph where they state their objectives and goals and
link to the project’s specific whitepaper? It may be nice to come up with a standard feature matrix that each project could fill out based on the common vocabulary defined in the whitepaper. For example, private/public, smart contracts, consensus algorithm,
etc. These may require a living part of the paper so it may make sense to maintain the into elsewhere. What I'd like to see though is a single 'quick overview' of each project without having to delve into each project's individual whitepaper.
-Sheehan
On Sun, Oct 16, 2016 at 9:36 PM, Richard Brown via hyperledger-tsc <hyperledger-tsc@...> wrote:
I agree with the points made below. To my mind, it feels like there should be a logical progression across a series of papers:
• Hyperledger Project Whitepaper (the thing we’re currently discussing I guess!)
o This should be the technical ‘manifesto’ for the Project. What do we believe? What problems are we solving? What are the defining characteristics of the field and the aspects that unite us?
o The reader of this paper should be left understanding exactly what the project is for, what it means for a codebase to be part of the project and where the project is going
o For those who haven’t seen it, we tried to do this – but in a more narrow sense – in the first sections of the introductory whitepaper for Corda (http://r3cev.com/s/corda-introductory-whitepaper-final.pdf).
Chapters 2 and 3 (Context and Vision) are our attempt at describing what we think defines the distributed ledger space, what problems this tech can solve and it does so from the context of financial services.
o Perhaps something like that but written more broadly/expansively is called for?
• Whitepapers for specific Hyperledger Project projects
o ie a Fabric whitepaper, an STL whitepaper, etc, etc, etc.
o A reader of one of these papers should come away understanding that platform’s unique objectives, design and architecture.
o The paper should probably reference the overall Project whitepaper but the purpose of these whitepapers is to leave the reader with complete clarity as to the overall design/architecture/purpose/objectives of a particular codebase.
Richard
Richard Gendal Brown
R3 | Chief Technology Officer
City Tower, Floor Fifteen
40 Basinghall Street
London, EC2V 5DE
Cell: +44 776 466 6821
richard@... |
www.r3cev.com
Email Disclaimer
From: <hyperledger-tsc-bounces@...> on behalf of Christopher Ferris via hyperledger-tsc <hyperledger-tsc@...>
Reply-To: Christopher Ferris <chris.ferris@...>
Date: Thursday, 13 October 2016 at 16:42
To: Hart Montgomery <hmontgomery@...>
Cc: "hyperledger-tsc@..." <hyperledger-tsc@...>
Subject: Re: [Hyperledger Project TSC] white paper objectives
Mic, thanks for starting this thread.
Hart, I tend to think that #1 is definitely a target audience, and that #2 is a subset of #1 that will actually get their hands dirty.
So, basically, I think of this as providing the concepts that Mic outlined (I tend to agree that this should be the scope) and that we provide enough meat to point people in the right direction to get started either collaborating or using the technologies we
are collectively creating.
It should also be a call to action for others to come play.
Chris
On Thu, Oct 13, 2016 at 5:31 PM, Hart Montgomery via hyperledger-tsc <hyperledger-tsc@...> wrote:
Thank you for the objective summary Mic. To follow up on this, I think it’s also important to consider what audience we are targeting. Are we intending the whitepaper for:
1. People who are not currently involved in Hyperledger. In this case, the whitepaper is essentially a technical marketing document designed to drive interest in Hyperledger. We list the features and some of the vision, but keep everything very high-level.
2. People who are getting started using Hyperledger. This was (in my opinion—I obviously didn’t write the OBC whitepaper) the initial conception of the whitepaper, as it focused on basic technical details and features, and was a good first read for
a technical person who wanted to understand how Hyperledger worked. However, as Hyperledger has matured and the whitepaper has moved away from the original IBM OBC whitepaper, this is not totally the focus anymore (and doesn’t necessarily have to be), although
new Hyperledger users still seem to be the main audience of the current whitepaper.
3. Current Hyperledger developers/users. If this is the case, the document becomes a sort of manifesto, and we would want to focus on high-level architectural requirements, vision, and goals of the project. The whitepaper’s current emphasis on modular
structure seems to fall somewhat into this category.
I don’t think there is a right or wrong answer here, and we could obviously mix and match who we are targeting (i.e. some sections target #1, others #2). However, it would be nice to know what the community and TSC think the audience of the whitepaper should
be, as the expected audience will heavily impact how we need to rewrite the whitepaper.
Thank you all for your time, and have a great day.
Hart
From:
hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Bowman, Mic via hyperledger-tsc
Sent: Thursday, October 13, 2016 7:34 AM
To: hyperledger-tsc@...
Subject: [Hyperledger Project TSC] white paper objectives
Per our discussion in the TSC call this morning about getting clarity for the purpose & objectives of the HLP white paper.
Here are the “candidate” objectives for the white paper we’ve been discussing in the white paper working group. We felt like these reflected the various high level comments provided during the feedback session a couple weeks ago. These are intended as a starting
point for the discussion.
• Call for action to back and drive the HLP as the preeminent means for advancing distributed ledger technologies
• Capture the concepts of the 'Umbrella organization' and clarify
• Establish a common vocabulary for discussing technology and usages
• Establish a future vision of HLP… where do we see HLP 1, 2, 4 years from now
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
Best wishes!
Baohua Yang
https://yeasy.github.io
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC").
This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations.
Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.
|
|
|
