Re: [Hyperledger Project TSC] white paper objectives


Hart Montgomery
 

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.

 

-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

 

Join tsc@lists.hyperledger.org to automatically receive all group messages.