Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Enterprise Ethereum Alliance Releases Vision Paper

Enterprise Ethereum Alliance Releases Vision Paper

This item in japanese

The newly formed Enterprise Ethereum Alliance (EEA) has published a Vision Paper outlining “a vision for users and stakeholders to propose, implement, and integrate advances to the Ethereum protocol with support for Enterprise Ethereum protocols.” In this paper, the EEA discusses many topics related to Pluggable Consensus, governance, interoperability, Ethereum protocol updates, secure code execution, storage and performance optimization.

This Vision Paper was released in conjunction with the Enterprise Ethereum Alliance launch event which formalized 30 organizations coming together to focus on enterprise use cases of Ethereum. The alliance includes large established organizations like Microsoft, J.P. Morgan, Intel, Thomson Reuters and blockchain startups like BlockApps, String Labs and ConsenSys.

In the short term, the EEA has identified five goals for 2017, including:

  1. Develop a sufficiently modular Ethereum implementation to separate and define clear interfaces between networking and storage layers - that is a prototype for pluggable consensus that minimizes the code changes required to switch consensus algorithms.
  2. Experiment with potential consensus algorithms, along with data privacy and permissioning frameworks.
  3. Develop a clear set of capabilities and performance characteristics that suit the needs of enterprises, including:
    1. 100 transactions per second, across a 10 party network
    2. High volume and value use cases
    3. High availability/reliability
    4. Parallelization and horizontal scaling
  4. Develop a Version 1 specification for Enterprise Ethereum, based on the learnings from the above plus the roadmap and requirements gathered from members, i.e., produce a reference implementation.
  5. Leverage a robust governance process to ensure alignment and agreement on approaches


Pluggable Consensus

Consensus is the act of nodes, within a blockchain, agreeing on the state of transactions and is predicated upon an algorithm that participating nodes agree. Since current Ethereum implementations are not modular, when organizations need to add additional features to consensus algorithms, for example privacy, they may end up forking the Ethereum implementation. The problem with forking is that these investments are now difficult to share and create fragmentation. In order to address interoperability needs, the EEA is looking to provide modular based consensus algorithms. The EEA Vision Paper describes why Pluggable Consensus is important:

A common, modularized implementation will provide a code base for developing the Enterprise Ethereum specification and also experimenting with consortia consensus algorithms. Pluggable consensus needs a modularized client with a clean interface for networking and between the Ethereum Virtual Machine and the consensus algorithm - it is really these interfaces that make the consensus layer pluggable.

One consideration the EEA is allowing for, with a modular approach, is they are: 

not being prescriptive as to the specifics of the algorithm, but rather should enable various algorithms to be used dependent on the use case.

Version 1 Enterprise Ethereum Specification

A goal of the EEA is not solely to develop an implementation, but rather to publish a specification in an attempt to:

accelerate ecosystem development by increasing the availability of APIs for integration with development, devops and management tools as well as legacy system integration.

By providing a specification, vendors can provide their own implementations, but because there are interoperability points, through interfaces, organizations can focus on their specific requirements. Compatibility and interoperability is not only a goal with Enterprise Ethereum, but also with public Ethereum.

Robust Governance

The alliance is currently targeting being a US-based not-for-profit foundation. The alliance is looking for a lead executive and volunteer Chair, in addition to an Executive Director, to take on the day-to-day management functions.

The EEA has stated its core will be based upon members and member participation with special interest groups focused on writing prototypes, architectures, roadmaps and industry groups. These interest groups will be grounded in four guiding principles:

  1. Development of open source standards
  2. Working with builders and doers towards a general purpose system
  3. Maintain compatibility with public Ethereum
  4. Not reinventing the wheel on data standards

Emphasis on Interoperability

While cross blockchain protocol interoperability may take some time to be realized, the EEA is building a set of requirements focused on interoperability including:

  1. Ability to switch components at various layers of the Enterprise Ethereum while maintaining application portability and network transactions
  2. Ability to provide non-standard extensions that are interoperable with the core specification
  3. Inbound and outbound data interfaces, and EVM hooks
  4. Public chain compatibility

In order to achieve interoperability, the EEA is designing using:

abstraction and modularity, with clear interfaces and APIs.

The EEA also anticipates that interfaces will be difficult to change once published, and as a result sees this interoperability work to be:

critical, even at these early stages.

Updating the Ethereum Protocol

The current Ethereum protocol is dependent upon a node choosing the next block for the longest-chain based upon a Proof of Work (PoW) algorithm which is computationally expensive. The downside to this approach is that there is a limitation of a blockchain being able to commit a new block around every 10 seconds. As Ethereum make more inroads into the enterprise, the ability to scale services to millions of users creates challenges for the existing protocol.

The EEA is looking for alternatives to PoW that improve scalability and reduce computational costs. There are many approaches being evaluated which may form the future of Ethereum block consensus protocols, including:

  • Delegated Proof of Stake
  • Ouroboros
  • Casper
  • Proof of Authority

Other opportunities exist in the network protocol layer of Ethereum where “atomic broadcasts of a total order of state sequences amongst a network of nodes that may experience byzantine failures” are required. There are several proposals of network consensus protocols for Ethereum being considered, including:

  • HoneyBadger
  • HydraChain
  • Tendermint

There are also some approaches that combine both block and network consensus protocols, including:

  • HydraChain
  • Ethermint

In addition to changes to block and network consensus protocols, other scalability approaches like sharding, parallelization and state channels are also being explored.

Shared Digital Infrastructure Administration

Enterprise Ethereum brings organizations together through Distributed Ledger Technology (DLT). One emerging challenge is in the area of governance. For example, what happens when a shared program, or contract, needs to be versioned and updated? The EEA is looking to:

explore the development of contract interfaces and classes for shared administration, in addition to design patterns applicable to the updating of operational code on already deployed systems.

Trusted Computing and Oracles/Data Feeds

There are a few different approaches to secure trusted code that needs to be executed. One such way is through the use of mainstream hardware. An example of this is “Intel SGX which provides enclaves, memory-encrypted on-silicon circuits which can only run signed, attested code, in a way such that other processes cannot access it.”

Another way to approach this problem is to leverage services like Microsoft Azure’s Cryptlets which is part of its Project Bletchley initiative and focuses on providing secure blockchain middleware services.

Secure locations to run trusted code is important when trying to include data feeds into distributed applications, or smart contracts. The Ethereum Enterprise initiative is trying to address secure code execution by:

focusing on protocol level implementations at the onset, with time, efforts to establish meaningful design patterns around oracle data (and perhaps more importantly, how to apply penalties for bad actors publishing malicious data) are expected to emerge from members of the Foundation.


Many decentralized applications have requirements to store data such as documents and media. Currently, the blockchain is not a cost effective or efficient way to store this type of data, thus requiring a way to securely store this data off-chain. There are a couple initiatives such as IPFS and Swarm trying to solve this problem.

Performance Improvement and Optimization

Currently the Ethereum blockchain is able to process tens of transactions per second. In enterprise settings, organizations will have different requirements depending upon their use cases. Providing flexibility that accounts for geographic locations, number of transactions required over varying connectivity is necessary. In order to address these enterprise needs, the EEA is focusing on the following performance characteristics:

  1. Define useful benchmarks based on various identified parameterizations of features
  2. Sketch how clients could be instrumented to measure various kinds of performance
  3. Relevant Parameters:
    1. Node connectivity
    2. Optimal network topologies (num and patterns of connections)
    3. Reliability of connectivity (maintenance of connectivity among nodes)
    4. Failure cases: when do nodes stop talking to each other
    5. Safety
    6. Liveness
    7. Min. number of healthy honest nodes required for proper operation
    8. Time to transaction finality
    9. Total number of network nodes
    10. Node topologies
    11. Internode distances in terms of transmission time
    12. Synchronous / Asynchronous messaging
    13. Transactions per second throughput
    14. Transaction / block transmission and processing latency

Rate this Article