Enterprise use of blockchain technology has evolved at an almost unfathomable rate over the past 24 months.
From early bitcoin experiments, senior bankers joining start-ups, the launch of the public Ethereum decentralized application platform and the many private, permissioned systems currently under development using the Ethereum technology, to the creation of industry consortia, blockchain has emerged as one of the top enterprise IT trends entering 2017.
The market has already moved beyond the incubation phase where innovators effectively build the technology along with their initial applications, and possibly beyond the early adopter phase too. Increasingly, mainstream enterprise IT organizations are not only educating themselves and experimenting with blockchain but also are aiming to tackle novel use cases and complex IT challenges with the technology. More and more frequently, our clients are asking for assistance building MVPs not POCs, or hardening environments for production readiness.
With this whirlwind, dare we say tornado, of adoption, it is also clear that certain key technologies are emerging as potential de facto standards as blockchain platforms, while at the same time IT organizations can be overwhelmed at the complexity and capabilities of the technology.
Ethereum is arguably, the most commonly used blockchain technology for enterprise development today. With more than 20,000 developers globally, the benefits of a public chain holding roughly $1bn of value, and an emerging open source ecosystem of development tools, it is little wonder that Accenture observed ‘every self respecting innovation lab is running and experimenting with Ethereum’. Cloud vendors are also supporting Ethereum as a first class citizen: Alibaba Cloud, Microsoft Azure, RedHat OpenShift, Pivotal CloudFoundry all feature Ethereum as one of their, if not the, primary blockchain offering.
Why? The software is widely available: simply download an Ethereum client, pick your favorite development environment, and get going. Ethereum is general purpose and easy to program: full stack / web developers can pick-up the Solidity smart contract programming language in a matter of hours and develop initial applications in only a few days. Documentation is plentiful, as are code samples, deployment frameworks, and training. Little wonder that so many companies are using Ethereum as their blockchain of choice.
Today, enterprises are deploying private Ethereum networks in or near production in areas as diverse as supply chain tracking, payments, data privacy, compliance, and asset tokenisation just to name a few. Certainly, we are some time away from seeing investment banks fully migrate securities clearing and settlement to Ethereum networks, but we already do see private Ethereum blockchain networks in production, even in financial services.
But enterprises adopting Ethereum face a number of challenges, notably:
- Ethereum was developed initially for public chain deployment, where trustless transaction requirements outweigh absolute performance. The current public chain consensus algorithms (notably, proof-of-work) are overkill for networks with trusted actors and high throughput requirements.
- Public chains by definition have limited (at least initially) privacy and permissioning requirements. Although Ethereum does enable permissioning to be implemented within the smart contract and network layers, it is not readily compatible ‘out of the box’ with traditional enterprise security & identity architectures nor data privacy requirements.
- Naturally, the current Ethereum Improvement Process is largely dominated by public chain matters, and it has been previously challenging for enterprise IT requirements to be clarified and prioritised within it.
As a result, many enterprises who have implemented private Ethereum networks have either ‘tweaked’ or forked open source implementations or have relied on proprietary vendor extensions to meet their deployment requirements. Some of these are extremely sophisticated and are on the cutting edge of computer science: BlockApps STRATO, Hydrachain, Quorum, Parity, Dfinity, and Raiden. While understandable, and in fact until now the only effective approach, the downsides are obvious: lack of application portability, code base fragmentation, and vendor lock-in.
Not surprisingly, this has been a point of conversation for some months between enterprise technology vendors, corporate users and Ethereum startups. These discussions have expanded, with the blessing and involvement of Vitalik Buterin and the Ethereum foundation, into a dedicated group of enterprise technology vendors, the largest corporate users and Ethereum infrastructure leaders collaborating to define a roadmap, legal structure, governance and initial technical developments to define ‘Enterprise Ethereum’.
To some extent this parallels the paths of other significant platform technologies, such as TCP/IP & HTTP and perhaps (from a software perspective) more relevantly Java and Hadoop.
Java was never intended to be a broadly used enterprise development tool; it was in fact developed originally for interactive television (specifically set-top boxes and smart cards — who remembers Java Card?). However, Java had many advantages for web development with database back-ends (known as web client-server or three-tier architecture): it had comprehensive web and database APIs, it provided ‘write-once, run anywhere’ platform portability, simplified object-oriented programming constructs with familiar syntax, and a rapidly development ecosystem. Indeed, it was not even Sun that created Java Enterprise Edition (at that time, J2EE); it was a plucky start-up (WebLogic) and a group of enterprise customers and other vendors. Similarly, Hadoop was originally created to index the web and for advertising serving. And who knew TCP/IP would emerge into a protocol that today, literally exists everywhere?
Ethereum is one of the few, indeed perhaps the only, blockchain technology with a similar trajectory and potential. Even the early “public permissionless” vs. “private permissioned” differentiation to expedite enterprise adoption strongly echoes the internet vs. intranet deployment considerations that were so prevalent before enterprises became comfortable with security and scalability issues of the then available public infrastructure.
By banding together the key adopters, supporters and shapers of enterprise usage of Ethereum, we are seeking to provide a platform not only for the technology, but also to provide the governance and tools to create a standard for ‘Enterprise Ethereum’. It is a group of builders & doers, developing sufficient governance for enterprise requirements but not ‘death by committee’ and without ‘pay to play’. Some of our collaborators have noted the refreshing nature of this approach and the pace of technical progress that is achievable from working off a single standard and open source code base. Moreover, Enterprise Ethereum will build upon the current Ethereum scaling roadmap and maintain compatibility and interoperability with public Ethereum. In fact, we believe Enterprise Ethereum will contribute significantly to the overall development of Ethereum.
We’ll soon be releasing formal information regarding the many stakeholders who are already forming Enterprise Ethereum. If you are a large corporate user of Ethereum (or anticipate you will be soon) and are interested in learning more about this initiative, please feel free to contact email@example.com so that we can register your interest.
Stay tuned… the best is yet to come.
Jeremy Millar is Chief of Staff at ConsenSys. He began his career as one of the first Java architects at Oracle, before moving into sales management and strategy roles, both within Oracle and at a number of start-ups. He went on to complete his MBA at Oxford University before joining the M&A team at Goldman Sachs. At ConsenSys, Jeremy has multiple focuses within enterprise and product, and is the chief instigator of Enterprise Ethereum.
Disclaimer: Futurism has a personal affiliation with ConsenSys. This is a piece of editorial content. ConsenSys does not have any review privileges on editorial decisions.