Page tree
Skip to end of metadata
Go to start of metadata


The Hyperledger Besu community would like to apply for the project to be moved from incubation to active status. Below outlines an assessment of the requirements of graduating from incubation status to active status and how Hyperledger Besu meets each requirement. From a high-level, we believe we believe the project is ready for active status because:

  1. Diversity of Community and Contributors: Besu has built an extensive and active community around its project. Some data points around the community include:
    1. There are 28 external contributors outside of the PegaSys team with 111 contributions (as of July 2019). Since Besu's submission and approval to Hyperledger, there have been 21 contributors from the PegaSys team and 8 contributors from outside of the PegaSys team.
    2. There have been over 100 community-raised issues on the project since November 2018, when the project was launched. This demonstrates the engagement and excitement around the project.
    3. Dozens of companies building blockchain applications have tested out Besu, provided feedback, and demonstrated its usability for their application. There are several organizations that are deeply integrated in our stack, including web3 labs and iobuilders. These teams are major contributors using Besu and providing feedback on the codebase.
  2. 1.0 Release Occurred in April 2019: Besu had it’s 1.0 Release demonstrating its production readiness months prior to this proposal. 
  3. Besu is Meant for Production: Several enterprises are building permissioned networks to use Besu in production. It is also a fully compatible client that runs in production in mainnet Ethereum.
  4. The Besu Team Is Already Involved in the Community: Since being accepted as a project in August 2019, the Besu team has been participating in the following activities:
    1. Added support for Besu in Caliper (Oct. 20)
    2. Participated in the CI/CD working group conversations and sharing our project’s research and best practices (Sep .- Oct.)
    3. Attended the Maintainer summit in Minneapolis (Oct. 8-9)
    4. Presented a talk at the Hyperledger booth at Sibos (Sep.23-25) 
    5. Submitted several talks for consideration for the Hyperledger Global Forum and participated in planning of agenda (Sep. - Oct.)
    6. Attended the Hyperledger meet-up at Devcon in Japan (Oct. 9)
    7. Presented privacy solution at Architecture WG - Privacy Confidentiality track (Sep. 20)


The assessment against the requirements can be found here:


Category

Requirement

Besu Community Response

Legal

All code has been made available under the Apache License and is free of incompatible dependencies

Complete.

Project name has been checked for trademark issues

Complete.

DCO check

Besu Repo:

(lftools) user@dev > ~/Projects/besu > (master) $ git id
7fbdcbcaa9632351b65323331385864e45e714a7
(lftools) user@dev > ~/Projects/besu > (master) $ lftools dco check
Checking commits in branch origin/master for commits missing DCO...
(lftools) ✘ user@dev > ~/Projects/besu > (master) $

Besu Docs Repo:
(lftools) user@dev > ~/Projects/besu-docs > (master) $ git id
34c4aa7931f0632b5bcd62c73b75c84841000b60
(lftools) user@dev > ~/Projects/besu-docs > (master) $ lftools dco check
Checking commits in branch origin/master for commits missing DCO...
(lftools) ✘ user@dev > ~/Projects/besu-docs > (master) $

Run by David Huseby

License check

Notes for besu scan 2019-10-24:

  1. The Gradle check-licenses file at /gradle/check-licenses.gradle in lines 139-152 appears to list license choices for a few third party dependencies (to be separately provided and not checked into the source code repo). Two of those listed are for licenses other than Apache-2.0: * javax.ws.rs - CDDL-1.1 * org.checkerframework - MIT Is besu using these dependencies? If so, then under the Hyperledger IP Policy these should likely be included in a license exception request to the Governing Board. I expect it is likely that the GB would grant exceptions to use these as build-time dependencies.
  2. Hyperledger's documentation license is Creative Commons Attribution 4.0, CC-BY-4.0. None of the files in besu contained CC-BY-4.0 notices. Consider adding notices to any Hyperledger documentation files, such as: SPDX-License-Identifier: CC-BY-4.0 Most of these documentation files should be listed in the "No license found" tab of the license scan report spreadsheet.
  3. Although virtually all besu source code files contain Apache-2.0 license notices, there are a small number of files with no license information. In the "No license found" tab of the spreadsheet, the files with "No license found" do not contain license notices that were detected from our scanning. Where possible, for those that contain Hyperledger code, Apache-2.0 comments should likely be added. This can be done by adding a comment with an SPDX short-form identifier, such as: SPDX-License-Identifier: Apache-2.0 Note that any files in this tab labelled as "third party directory", "excluded file extension" or "empty file" likely do not need to have these notices added. More information for #2 and #3 can be found on the Hyperledger wiki, at https://wiki.hyperledger.org/display/HYP/Copyright+and+License+Policy

Scan report:

besu-2019-10-24.xlsx

Community Support

The project must have an active and diverse set of contributing members representing various constituencies

Hyperledger Besu has had an active community. We have 55 contributors (as of July 2019) and over 200 members of our public Gitter channel and 70 on RocketChat. There have been 28 external contributors since the projects’ inception in November 2018 with 111 external contributions total.

The project is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)

While PegaSys is the main organization that is contributing to Besu, there are several organizations and contributors contributing to Besu, including web3labs. We have instituted a process for adding external maintainers with our first external maintainer being voted on these past few weeks.

Release plans are developed and executed in public by the community.

The releases of Pantheon and now Besu have been in a public forum available on the GitHub and the Gitter channel, and RocketChat. We also have set up a bi-weekly contributor call in which release activities are discussed. Meeting minutes and agendas are posted publicly on the Besu Wiki.

Finer grained details are managed via Jira. Epics, and stories are maintained in Jira, and tracked against versions.

Test

Sufficient test coverage

See below.

The project must include a comprehensive unit and integration test suite and document its coverage. Additional performance and scale test capability is desirable.

Currently there are comprehensive unit, integration and acceptance tests with Besu. Merges to master are prevented if there are failing tests.

Performance and scale testing is under development through a partnership with WhiteBlock.

Documentation

Sufficient user documentation

Hyperledger Besu team maintains a robust documentation site here. 

The project must include enough documentation for anyone to test or deploy any of the modules.

Done. See above.

Alignment

Requirements fulfillment

Hyperledger Besu team maintains a robust Documentation site that provides details on requirements, use cases, and other expectations for the project.

The project must document what requirements and use cases it addresses.

Hyperledger Besu team maintains a robust Documentation site that provides details on requirements, use cases, and other expectations for the project.

The project must document how it fits within the Hyperledger Architecture

Besu’s architecture can be seen in this blog post. Because it's a mainnet Ethereum client, Besu represents some new considerations and opportunities for the Architecture Working group which require further discussion.

Compatibility with other Hyperledger projects

This is a work in progress that we are excited to continue to engage with the community on. Our team attended the maintainer summit Oct. 8-9 to begin exploring these options.

Where applicable, the project should be compatible with other active projects.

This is a work in progress that we are excited to continue to engage with the community on.

Alignment

Release numbering: the project should use the Hyperledger standard release taxonomy, once that is agreed upon.

Besu uses the appropriate naming taxonomy.

Project must make a release, even a “developer preview”, before graduation.

The past releases and the respective documentation for Hyperledger Besu can be found here.

Infrastructure

Gerrit or Github repo has been created

Done and code has been moved. https://github.com/hyperledger/besu

https://github.com/hyperledger/besu-docs

Mailing lists have been created and are archived

Done: https://lists.hyperledger.org/g/besu

Other communication means used, such as slack channels, are set up

Done:

https://chat.hyperledger.org/channel/besu

https://chat.hyperledger.org/channel/besu-contributors

Project is set up with Continuous Integration

Done

All information necessary for someone to join the community and be able to start contributing is duly documented (location of repo, list of maintainers, mailing lists addresses, slack channels if used, etc) following the Hyperledger Project standard practice (CONTRIBUTING.md, MAINTAINERS.txt, SECURITY.md, etc)

We currently have documentation in the current Docs and Wiki site referenced above.

CII Badge

A team seeking to graduate from incubation shall have started the CII Badge application and be nearly complete with incomplete badge requirements referenced in their graduation proposal. 100% of the applicable criteria for the CII Badge is a requirement for releasing a 1.0 of the project. That does not mean the project must have 100% of all criteria, just 100% of the applicable criteria. This is to allow for projects such as test harnesses, that have “N/A” answers for questions that don't offer that as an option.

CII Badge was completed. Seen here.

Other Considerations

Sufficient real world use

The project should be used in real applications and not just in demos. Because not all real applications may be discussed publicly, in such cases statements providing as much detail as possible should be made.

Sufficient scalability

The project must demonstrate sufficient scalability and document its scalability over various dimensions such as:

  • Maximum number of transactions per second
  • Maximum number of transactions per chain
  • Maximum size of a block

Minimum test code coverage expected, such as, for example:

  • Minimum coverage for Security & cryptography
  • Minimum coverage for other functionality
  • Minimum coverage for Business logic/smart contract

Besu has several real world use cases. There are several that are not public. Here are links to a couple of public real world applications being developed using Hyperledger Besu:

  1. LiquidShare
  2. IoBuilders
  3. ZarX

Scalability - PegaSys has performed several monitoring and benchmarking assessments of Besu.

PegaSys also has a research & development team fully dedicated to the long-term scalability of Ethereum and Hyperledger Besu.

Reviewed by

  • No labels

18 Comments

  1. I've left a number of comments inlined, above (as has Tracy).

    1. Thank you! Will respond over the next day or two.

  2. Have any 3rd party security scans, penetration tests, etc been performed?

  3. Gari Singh The codebase has had a security audit performed in 2018 when it was named Pantheon. You can find the assessment report here: https://pegasys.tech/wp-content/uploads/2018/12/PegaSys-Pantheon-Final-Report-Updated.pdf.

    We are also currently working with David Huseby with RFPs being sent out to begin another security audit on the codebase in the coming weeks. We are in the process of selecting the appropriate vendor before we kick off the work.

    1. Perfect ... thanks

  4. From the project description, I don't get if the EEA-like private transactions are already supported. Is it the case?

    1. Angelo De Caro Yes, EEA-like private transactions are supported. There is a private transaction manager, Orion, that manages sending private transactions. You can also create privacy groups. Orion, however, is a separate codebase from Besu and still housed within PegaSys' repos. http://besu.hyperledger.org/en/latest/Concepts/Privacy/Privacy-Overview/

      1. Is it the case that in order to use Besu for permissioned use case, a user would need to integrate with Orion? If so, please help me understand why Orion was not also submitted.

  5. While I appreciate the desire of the Besu team to quickly move to Active status I must admit not to have expected this request to come so soon. I quite frankly think it is materially impossible for a team to fully integrate an organization so quickly and I think there are several signs of that showing up which have already been highlighted by others.

    I'm especially interested to see the response regarding the affiliation of the maintainers. As I pointed out in a comment on Besu's HIP, “having 26 full time developers from the same company on this project isn’t going to make it easy to create a really open community and move to Active status quickly as it is hoped for.”

    I will also note that the stated governance of the project is totally at odd with Hyperledger and if nothing else makes the project unsuitable to move to Active status:

    “This project is led by a benevolent dictator (PegaSys) and managed by the community.”

    The Incubation Exit Criteria clearly states that one requirement is that:

    "The project is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)"

    The reason that all other projects, even those that were well established before coming to Hyperledger, spent several months working within Hyperledger before applying to move to Active status is because it actually takes time to get there. Not that it is a requirement to wait for some time but simply because what is required takes time to achieve.

    Of course you could quickly change the governance document – and you should! – but making the actual change in how the project is run will take longer. The fact is that it takes quite a bit of effort for a company that has been the primary driver of a project to build a community and relinquish control and share it with the community. Other projects have struggled with this and often still do. In fact, I think it is always the one criteria that stops projects from moving to Active status because unlike other criteria this is not something that is easy to control. So, you're not alone!

    Just keep working on it and I trust that given the demonstrated eagerness of the Besu team you will eventually get there.

    If nothing else, going through this application process should help you identify areas that need improvement and help us clarify our documentation if needed so that what is expected is more clearly stated. Your feedback here would be much appreciated.

    Thanks.



  6. Hi Arnaud and TSC,

    Thanks for your thoughtful review of the proposal. We’ve tried to respond to some of the themes we’ve seen in the comments and provide additional context to the project’s efforts and processes:

    Diversity of Project:

    The Besu project is committed to diversity of its project and has many instituted best practices for OSS (discussed below). We would welcome working with the TSC on this matter and discuss recommendations on how other projects have successfully grown their contributor and maintainer base. Currently there are two organizations dedicated to Besu. We understand if the TSC wants to see a third organization prior to approving active status. 

    Implemented OSS Best Practices

    Besu has implemented best practices for running the project to be as community-friendly as possible. We use these best practices when running the project:

    • Contributor Calls: We have bi-weekly contributor calls where all are welcome and able to contribute agenda topics.
    • Release Management: First major release was already released as Besu (1.3 Release)
    • RocketChat and Mailing List Activities: All project communication is done on these open channels. We have seen active chatter and questions on RocketChat since moving the conversations there.
    • Maintainer Process: We have a formal and objective process to add maintainers modeled after OpenJDK. This is unlike a subjective processes used by other projects.

    How Besu is Already Engaging in the Hyperledger Community

    The Besu team is excited to be a part of the Hyperledger community and the team has already begun contributing to the community. We’ve put together a list of activities the Hyperledger Besu team has participated in since being approved as a Hyperledger project:

    Note: I’ve also added this list to the proposal above.

    • Added support for Besu in Caliper (Oct. 20)
    • Participated in the CI/CD working group conversations and sharing our project’s research and best practices (Sep.-Oct.)
    • Attended the Maintainer summit in Minneapolis (Oct. 8-9)
    • Presented a talk at the Hyperledger booth at Sibos (Sep.23-25) 
    • Submitted several talks for consideration for the Hyperledger Global Forum and participated in planning of agenda (Sep.-Oct.)
    • Attended the Hyperledger meet-up at Devcon in Japan (Oct. 9)

    Thank you for calling out the governance page and it’s outdated information! We are in the process of updating it.

    Asks from the Besu Team to the TSC: 

    In the case the TSC doesn’t choose to approve the project into Active status at this time, we would like to see the TSC provide a clear list of the targets we need to hit to be approved into Active status. We hope we’ve already demonstrated our eagerness to address challenges raised by the TSC to date and we look forward to continuing to work with you on this matter.

    1. Why the rush?  What do you actually think "active" status does for you?

      I actually think that people confuse/conflate project status with the actual quality/state of the code.  Project status is about where a project stands in terms of meeting the governance policies of being a Hyperledger project; it has nothing to do with the actual "production" readiness of the code.

      I also think somehow people believe that Hyperledger projects are actually products.  They are not.  For example, Fabric is a project.  Oracle Blockchain Platform, IBM Blockchain Platform, SAP Cloud Platform Blockchain service, etc are products which are built from/incorporate the Fabric project codebase.  For Besu, Kaleido would be a product which uses Besu and of course PegaSys could product supported products based on Besu as well.

      I believe that too much importance has been wrongly placed on project status and it has been conflated with product readiness.

  7. For a third organization it will likely be Chainsafe labs and/or ETC Cooperative, they really want our client working on the ETC network.  They are working on patches here https://github.com/chainsafe/besu but it looks like they are preferring the giant functional patch approach rather than the small PRs approach Web3Labs and ConsenSys prefers.

  8. I'm still looking for a response to my question about Orion, above. Why was it not contributed to Hyperledger?

    1. Sorry for missing that one. The PegaSys team wanted to focus on a seamless transition of Besu/Pantheon first prior to moving other codebases over. We did not want to complicate that transition with multiple codebases. We are looking to move Orion to Hyperledger in the next couple of months. 

      1. Well, I can appreciate that, BUT, the whole premise of Hyperledger is about developing blockchain technology for the enterprise. Mostly, this has been about permissioned networks. Now we have Besu which in its current form requires a 3rd party (PegaSys) module to operate in permissioned mode. This seems awkward at best. I'd personally really like to see Orion brought over sooner rather than later. I don't know how other TSC members feel.

        1. Orion is not required to run in pemissioned mode.  Those are covered by the IBFT2 and Clique consensus protocols which are already a part of Besu.  Orion handles "restricted private transactions" where the private transaction is not stored on the blockchain.  "Unrestricted private transactions" are already handled in besu via smart contracts.  The unrestricted part means that there is no change to the core blockchain operations like is needed for restricted privacy.

  9. Based on comments to date (Nov 14) there is still some administrative work to do (migrate Jira) and more substantially the contributor diversity does not yet seem to pass the litmus test (i.e. if one company goes away will the project continue). 

    I do appreciate all the work that I see so far in the rest of the items and the thoroughness in this report itself. Continuing that proactive effort will no doubt soon close the main gap with contributor diversity.

  10. Just as a quick update: 

    -The Jira migration was completed last week to Hyperledger's Jira. The PegaSys one remains open to ensure a smooth transition, but will be frozen in a week or two.

    -The third organization, Chainsafe, is currently in the process of merging their commits for the ETC work Danno mentioned above.

    We can discuss further in the TSC meeting. Thanks!