Many ethereum developers have high hopes that the Enterprise Ethereum Alliance, backed by the likes of JPMorgan and Microsoft, will help to join private blockchains tailored toward the corporate world with the larger ethereum network.
Launched in Brooklyn last week, the group aims to provide the tools to make ethereum, which currently faces scalability and privacy challenges, more usable for companies.
But, one vision is that it will do more than that – like help to spur larger scale adoption of ethereum.
He offered an analogy:
“We talk about ‘the internet’ as if it’s one thing. It’s not one thing. The internet is a network of networks. That is how the internet is built. That’s important to note in the context of private and public networks.”
The latest reminder of this effort comes from a newly released paper, “Ethereum Enterprise Vision,” which outlines a variety of technical goals for the alliance, especially over the next year.
The paper is no means a final plan, and, admittedly, it might be a bit early to hypothesize about the long-term trajectory of a week-old consortium.
Still, against a backdrop of murmurings about how the consortium could help bridge the private and public blockchain worlds, it’s notable that making private ethereum implementations compatible with the larger public blockchain pops up repeatedly as one of the technical objectives.
However, focusing on the technical requirements to help make that happen is not a necessarily a priority for all members of the consortium.
At least one member company, Monax, hopes to see a roadmap more focused on standardizing the tools needed by private versions of ethereum.
In this case, that means focusing on the ethereum virtual machine (EVM), the piece of ethereum responsible for executing smart contracts, rather than building out the other components necessary to make private blockchains compatible with the public blockchain.
“Basically, private chains are totally different animals than public chains and we think that trying to track the public chain ecosystem is inappropriate for a consortium whose first business will be to adopt standards for private chain use cases,” Monax Industries COO Preston Byrne told CoinDesk.
He added that, in his opinion, being expected to build their technology around a spec that needs to meet the needs of the public blockchain would be “regressive and impair performance of our software”.
Monax, a private blockchain provider, has been experimenting with using the EVM in a private setting, going as far as to propose a codebase featuring the technology to the Linux-led Hyperledger consortium.
Byrne expects that other companies will agree. He said:
“As we actually maintain a popular ethereum client, our suspicion is that corporate users will wind up agreeing with us that line-for-line copies of the public chain ecosystem are not required for their use cases.”
Even if it isn’t winning everyone over, it’s an idea that has attracted quite a bit of attention, especially at the alliance’s launch event.
So, how would the idea play out at a technical level?
Each implementation, public or private, uses a different ‘consensus algorithm’, or a way for the network to come to agreement on the transaction history.
The trouble is making such disparate networks interoperable, so as to switch from one algorithm to another, say, if you want to send money to another network.
There’s one technical idea called ‘pluggable consensus’, mentioned many times throughout the conference, that might help form such a bridge.
“Pluggable consensus is the idea that you can swap out your consensus algorithm based on your environment. Everything is a tradeoff,” ConsenSys head of global business development Andrew Keys explained in the Ask Me Anything, a portion of the launch event where the audience tossed out questions about how Enterprise Ethereum Alliance will work.
The idea is to build an implementation that supports everything: proof-of-stake, proof-of-work, or permissioned blockchains based on consensus algorithms that predate bitcoin, such as PBFT or Practical Byzantine Fault Tolerance.
Later in the day, ConsenSys lead architects Bob Summerwill and Shahan Khatchadourian put forth a technical roadmap for the project, one that looks similar to the white paper. For 2017, their goal is to create a specification for Ethereum Enterprise, building a reference client based on that specification (written in the programming language Python), and building out a package of testing tools.
The plan is to grow from there.
“The ultimate goal is to be a lot braver than that,” Summerwill said, later noting that pluggable consensus was on the list of things to work on down the line.
“The intention is that the enterprise client should work perfectly well on the public chain as well,” he added.
However, so far pluggable consensus appears to be a longer-term project, since it might not be such an easy problem to solve.
Summerwill expanded on the term in a later panel:
“‘Pluggable consensus’ is a buzzword. It sounds nice and you think you understand what it means, but it kind of doesn’t really mean anything. It’s like saying ‘we’re going to build an interface and you can stick anything behind it’. Anything? In the world? It’s obviously not going to be perfect.”
“That’s really where we’re going to need to go step-by-step, starting with what we have with the ethereum setup and expanding it one thing at a time and standardizing that out,” he continued.
While it’s clearly not a buzzword to the degree that ‘blockchain’ is, it’s at least been making the rounds in technical circles, with Google search results for ‘pluggable consensus’ turning up competing consortia, R3CEV and Hyperledger.
Even JPMorgan has developed its own very similar term for the concept. In a demo of ethereum-based Quorum, JPMorgan Python developer Tyrone Lobban referred to “configurable consensus”.
Despite the unknowns, with such popularity at the alliance’s first conference and an appearance in the consortium’s first paper, it looks to be a concept to look out for as the consortium’s work progresses.
Magnet image via Shutterstock