Why We Rebuilt Ethereum from Scratch
DISCLAIMER: As of September 2019, Pantheon has been renamed to Hyperledger Besu. In posts prior to September 2019, we refer to the Ethereum client as Pantheon.
PegaSys, the protocol engineering team at ConsenSys, is excited to announce the open source release of Pantheon Core. We have been working on Pantheon Core as part of PegaSys’s mission of building enterprise-grade solutions in tandem with the Ethereum community. Pantheon Core will also be the center of our future Enterprise releases, which will include private transactions and permissioning. With today’s release, users can run nodes to connect to the Ethereum mainnet, Rinkeby or Ropsten testnets, or create their own private networks.
Today’s release has a few features that should be useful for developers. Pantheon currently is updated to the Constantinople release. There are multiple consensus algorithms, including Proof of Work and Proof of Authority (clique PoA) for fast private networks, with IBFT 2.0 coming in the next release. We’ve also added an importer tool that can get a node up to the current block in less than a day.
Pantheon also works with the tools you’re already familiar with: Truffle, Remix, web3j, and Nethereum already work, and Kaleido and Epirus are coming soon. (Tell us what other tools you’d like to use on our Gitter!). We have a nifty new explorer from Alethio that can run on Pantheon as well, and Infura is running Core nodes in their cluster, so if your dApp runs on Infura, you’re already using Pantheon!
We’re also very excited to have Pantheon available in Azure Marketplace (or direct via Azure Portal) through our partnership with Microsoft. On our partnership with Microsoft, Marley Gray, Principal Architect at Azure Blockchain, noted, “We’re excited to partner with PegaSys to bring Pantheon to Azure. The emphasis on open source, enterprise-focused tools that are easy to use is something both our companies believe is key to wide-scale adoption of blockchain.”
So Why’d We Do It?
Writing an Ethereum client is not easy. In fact, as Peter Szilagyi of the Ethereum Foundation pointed out, there is a “graveyard” of clients (Haskell, Ruby, C++) that are no longer maintained because of the amount of work involved and Ethereum’s constant evolution, led by the Geth team. Our motivation to contribute a new client is threefold: to build something that can get to enterprise production, to support and scale mainnet, and to prepare for the future of Enterprise Ethereum.
I'm happy that we plan more clients in the #Ethereum ecosystem, but please remember the ghosts of the past (C++, JS, Ruby, Haskell, Python, Erlang, C#). We're walking on a graveyard of abandoned clients. Almost nobody realizes the effort involved in keeping Ethereum alive. https://t.co/bhrchUUL4V
— Péter Szilágyi (@peter_szilagyi) September 28, 2018
Getting to Production
Our singular focus is getting Enterprise Ethereum to production. To that end, we wrote a new client to to build a more enterprise-grade design and architecture, and to lower the barrier to entry for enterprises with a more friendly license (Apache 2.0) and language (Java).
Design and architecture decisions have been aimed at clean interfaces and modularity, with the goal of making Pantheon a platform for others to build on. This client-as-platform idea means we hope the community creates new modules (for consensus, privacy, databases, analytics/reporting, and so on) that can be configured as needed by an enterprise to suit a production environment. By trying to create separation among elements (networking, storage, EVM, etc) within the client, we hope to ease configuration and maintainability for future changes.
To get Ethereum to production, we also need to lower the barrier to entry for enterprises. Many companies’ legal or compliance departments restrict them from using software under the Gnu Public License (GPL), which the mainstream Ethereum clients currently use. We have heard stories of enterprises that completed a successful pilot on Ethereum, only to be stopped from going to production because of company policies around OSS licenses. We hope to solve that pain point by releasing Pantheon Core under an Apache 2.0 license and smooth the path for adoption.
We have talked about our motivation for using Java in the past, but it bears repeating that our goals — to create a vibrant ecosystem of knowledgeable enterprise users while building high quality, production-grade software — are helped greatly by using Java. From IT approvals to monitoring and infrastructure tools to the massive community of Java champions, we want to make this path easier and bring in existing tools whenever possible.
Open source software is everywhere in 2018, but the most widely used open source software is typically vendor-supported (Android, Linux, Hadoop). As such, we built the new client to give enterprises what they need: a throat to choke for when questions need answers. We aim to provide technical support eventually all the way up to enterprise-grade, and by having our own client can make the changes or bug fixes that are needed to meet modern SLAs, and to add enterprise-specific requests to our roadmap.
Supporting and Scaling Mainnet
Scaling is not just about transactions per second. Scaling is also about creating a powerful virtuous circle of developers contributing to the protocol layer. Currently, Ethereum has thousands of application layer contributors, but the number of devs who understand the EVM is much smaller. In our eyes, bringing production-minded developers and enterprise into the core would be a big step to creating a sustainable public blockchain. At the center of the venn diagram of Java and open source, you will find some of the most popular and widely used enterprise distributed systems — Kafka, Hadoop — and if we are able to bring some of the minds behind those systems to Ethereum, we would consider Pantheon a success.
Moreover, having multiple clients makes Ethereum stronger. Geth and Parity do a lot of heavy lifting right now on their own, and adding a third mainstream client would add balance. Geth and Parity currently learn and exchange ideas, as concepts like new consensus algorithms (i.e. Proof of Authority) flow from one client to another. Our goal is to meaningfully contribute to this exchange, with a particular eye for standards and enterprise-readiness.
Preparing for the Future
PegaSys is driven by a short term vision focused on production-readiness and a long-term vision based on bridging the public and private blockchain worlds. Because of this long-term vision, public chain interoperability with the core of our Enterprise product offering was a critical piece.
We envisage a future in which enterprises will seek compatibility with the powerful network effects Mainnet applications will be able to offer. We think the walls between private consortium networks and public chains will gradually weaken, both as enterprise networks become larger and more like “enterprise main-nets” (an inevitable result of adoption) and as Mainnet itself improves scalability and security. Moreover, we see bridging these efforts as part of our mission.
Our motivation also includes the software development cycle where enterprises need stability. Enterprises will build applications on top of our protocols, so a timely release schedule helps these developers with their planning. As such, we aim to have release cycles in line with the rest of Ethereum and at our own regular cadence.
Our immediate goal for Pantheon Core is to create a vibrant ecosystem centered on an open source community (learn how to make your first contribution here). Looking to next year, this release will be the core of Pantheon Enterprise, which will add permissioning and privacy as additional modules. An Enterprise Alpha is forthcoming, targeted for Q1 2019, with a production-grade client to be related some months afterward.
In the meantime, we aim to continue the conversations we are currently having with enterprises already working on Ethereum, the Enterprise Ethereum Alliance, and others on the front lines. By using the EEA client specification as a guidepost, our requirements come directly from the enterprises building and contributing to the spec. Our contributions on the standard typically include insights from our role as builders and our R&D efforts that now cover topics including privacy, sidechains, and Ethereum 2.0. If you’re interested in working with us on the future of Enterprise Ethereum, get in touch, write some code, or download our work so far.
Want the latest PegaSys updates straight to your inbox? Join our mailing list.