On October 1, the Enterprise Ethereum Alliance (EEA) and Hyperledger, two of the most influential enterprise blockchain communities, joined one another’s organizations. This is a big deal, and I know because I’ve been very fortunate to have contributed to both of these excellent communities: first in Hyperledger Fabric as a code maintainer, and then in the EEA as a code contributor to Quorum (the most prominent EEA-spec compliant client to date) and as a reviewer of the EEA spec 2.0 (to be delivered in Devcon IV). What is the significance of such an improbable alliance? And more importantly, what will this mean for the overall advancement of enterprise blockchains?

Spec-First + Code-First

First, some background on both organizations. The Ethereum Enterprise Alliance is a standards body. The organization’s sole focus is producing specifications that define compliant interoperable Enterprise Ethereum blockchain implementations. Think of it along the lines of HTML5 (or 4 or 3 or …) or the newer Web Assembly (WASM) from the W3C, which is used to define valid web browsers, or even VLAN or 802.11n defining ethernet-compliant devices.

Activities are organized into Technical Working Groups and Special Interest Groups. Working Groups are “cross-cutting” technology rather than industry focused, one example being the Technical Specification Working Group, of which I am a member. Special Interest Groups are vertical industry-specific, such as financial services and healthcare. By combining wide representation from the customer space and vendor space, this arrangement matches meaningful, realistic requirements with useful and effective solutions.

Hyperledger, on the other hand, take a “code-first” approach.The code itself is the specification. It’s really an umbrella-like grouping that encompasses a number of projects in blockchain frameworks and tools. Some of the more prominent projects include Fabric, Indy, and Sawtooth Lake as full blockchain frameworks, and Composer as a tool. Being a charter of the Linux Foundation, the organization has provided excellent code governance services to ensure open collaboration. Another important aspect of the organization’s mission has always been cross-pollination. Examples include projects like Sawtooth Lake’s support for Burrow as contract engine; z-mix, a collaboration of the teams behind Fabric and Indy; and fabric-secure-chaincode, a collaboration between IBM and Intel.

With this context on the EEA and Hyperledger backgrounds you should already see what the two groups bring to each other. The two organizations are highly complementary in nature: industry requirements expressed alternatively as standards-based specifications and as implemented code. Sounds like a perfect match, right? That indeed seems to be the motivation supporting this collaboration.

Competitive Collaboration: Identity, Privacy, and Interoperability

How could this be the case, though when the common refrain pits Ethereum in competition with Hyperledger Fabric? Truth be told, that is not an entirely incorrect assumption. The two blockchain frameworks do occupy the top positions in enterprise adoption. Historically, many customers I have met — both when I was working on Fabric and later on Ethereum’s enterprise-focused Quorum — evaluate the two options as exclusive choices on a project by project basis. But as a blockchain engineer, I’ve been known for my pragmatism and resistance to dogmatism when it comes to technology. So for the purpose of this piece, I will look to the future and give reasons based on my personal understanding as to why this is a good move for the EEA and Hyperledger, and importantly, the blockchain community as a whole.

First it’s about sharing the talent pools. Both camps of technologies have come a long way to solve some of the fundamental problems in building viable enterprise consortiums. On the other hand there are still exciting opportunities for further improvements and functions for both communities: effective, performant zero-knowledge proofs generation and verifications; flexible privacy-preserving transactions for different levels of privacy requirements; how to best utilize Trusted Execution Environments; scalability; and a common definition of performance metrics are just some examples of technical work yet to be fully addressed.

There are already signs of cross-pollination, though. Burrow, an implementation of Ethereum Virtual Machine developed by Monax, was the 4th blockchain framework in Hyperledger. It has since been adopted by Hyperledger’s Sawtooth Lake and Fabric projects as a smart contract engine to enable a large community of Solidity developers to easily target their dApps for those two blockchain frameworks.

Identity

Much more can be done. For example, in the identity area, the Fabric team has developed an attribute-based identity verification mechanism called Identity Mixer that uses zero-knowledge proofs to demonstrate possession of digital signatures and private keys. Using this technology, Mixer allows you to prove you can do something without revealing who you are. On the other hand, if the goal is identity masking without attribute claims, the Ethereum community has been using a much simpler technique called Hierarchical Deterministic Wallet (HD-Wallet), which originated in the Bitcoin community so that you never reuse a digital identifier more than once. This eliminates any ability to correlate transactions over time, while all private keys are derived from a single root secret.

Privacy

Privacy-preserving transactions, or private transactions, is another interesting area where the two communities have come up with complementary approaches. Quorum’s design, as with other implementations inspired by the same design such as Crux and Orion, allows private state to be designated on a per-transaction basis, without involving special logic in the smart contract code, and is maintained based on the collection of private parties. The private state is detected on an ad hoc manner because the same smart contract function can be the target of both public and private transactions. This provides simplicity and flexibility for the application developers. It also results in a hash representing the private transaction input payload to be saved on the chain, to support dispute resolution and audits.

Fabric took a slightly different approach from Quorum. In Fabric’s design, private data are formalized into collections with membership policies and data definitions that are statically defined by chaincode logic. The overhead of these formalizations are more than made up for though, by having consensus and finality on private states.

Interoperability

Sharing talent is not limited to the technical space, but also extends to business domains. Given the large amount of industry participation in both organizations, use cases and business requirements should be another area of deep collaboration going forward. It’s very likely an enterprise will end up adopting more than one blockchain. Maybe the same company is participating in the payment consortium on the one hand, which is based on Ethereum or one of its derivatives; and at the same time also participating in the asset trading consortium, based on Fabric. It would be a win-win if APIs for client applications to interact with the blockchains, and programming models are compatible. It would be even more awesome if there exists an atomic cross-chain transaction system that utilizes technique such as state channels for atomic swaps, or connector-based techniques such as Hyperledger Quilt (an Interledger Protocol implementation).

On the identity front, ideally the identities of an organization would not need to be re-built from scratch each time it joins a new consortium. Using a common decentralized identity system, whether it’s based on Hyperledger Indy or Ethereum uPort, or even based on links to legacy federated SSO systems such as ActiveDirectory or LDAP, makes this possible. Certainly more work is required to make this a reality.

Interoperability is multi-dimensional too. If we consider the techniques like state channels and Hyperledger Quilt as “horizontal interop” where assets move laterally across chains, what would “vertical interop,” where assets or commitment data move between “layers” of blockchains, look like? A multi-layer architecture can be useful in addressing a number of different requirements. Plasma is an exciting Ethereum project using a layered architecture to increase scalability. Transaction executions are conducted in the “child chains” while the “parent chain” is used as security anchors and the safety hatch when participants of the child chains need to stop their participation.

As another example, my colleagues and I at Kaleido recognized that a permissioned blockchain network is more susceptible to collusion than a public network due to its much reduced number of participants. We created Kaleido’s mainnet relay function which utilizes the layered approach with public Ethereum’s mainnet to protect against collusion. It would not be a far-fetched notion to have permissioned networks based on both EEA and Hyperledger blockchain frameworks to be set up as child chains and utilize a common root chain in a Plasma-like configuration.

A New Vector for Enterprise Blockchain Solutions

It’s an exciting time for enterprise software infrastructure. The decentralized model of blockchain has opened a new vector for companies to transact with new trust models and collaboration capabilities. Joining forces between the EEA and Hyperledger technology and teams bodes well for this new ecosystem.

Visit kaleido.io to learn more about Kaleido’s Blockchain Business Cloud, which radically simplifies the creation and operation of private blockchain networks for enterprises.