This Draft Specification is copyright © 2022 Enterprise Ethereum Alliance Incorporated (EEA). It is made available under the terms of the Apache License version 2.0. [[Apache2]]
This is an editors' draft of material that might be developed into Enterprise Ethereum Alliance Permissined Blockchain Deployment Guidance. It has not been approved for publication by the Enterprise Ethereum Alliance (EEA) Core Specifications Working Group nor anyone else. It is not appropriate to quote or reference this document except as "Work in Progress", and it should be considered unreliable and unstable in its present state. Please send any comments to the EEA Technical Steering Committee at [https://entethalliance.org/contact/](https://entethalliance.org/contact/).This document describes good practices and information that is useful when deploying an Enterprise Ethereum permissioned blockchain.
Enterprise Ethereum is the set of enterprise-focused extensions to public Ethereum that are defined in the Enterprise Ethereum Alliance Client Specification [[EEA-clients]]. These extensions provide the ability to perform private transactions, and enforce access controls (permissioning), for Ethereum blockchains that use them. Such blockchains are formally known as Enterprise Ethereum Permissioned Blockchains.
Public Ethereum is the public blockchain-based distributed computing platform featuring smart contract (programming) functionality defined by the [[Ethereum-Yellow-Paper]], [[EIPs]], and associated specifications. The mainnet is a public ethereum blockchain, with `chainId` and `NetworkId` values of 1.
There are other public ethereum blockchains, usually with slightly different characteristics. For example "testnets" like Ropsten, Rinkeby, and Goerli are all used to test Ethereum technnology.
connectionAllowed
and transactionAllowed
at a known address, to determine whether to allow
an incoming connection, or whether to treat a given transaction as valid.
An Enterprise Ethereum Client can cache results from calling the methods of a
permissioning contract, in order to minimise such calls. To do so safely,
it must listen for update events emmitted by the contract, and modify its cache appropriately.
maxcodesize
nodePermissionContract
transactionPermissionContract
organizationRegistryContract
Implementations need to provide deployment and debugging tools for Enterprise Ethereum smart contracts. Tools used in public Ethereum, for example, include [[Truffle]] and [[Remix]].
Implementations should also extend formal verification methods for use with Enterprise Ethereum smart contracts.
Implementations might provide integration libraries enabling convenience of interaction through additional language bindings. These libraries might include [[web3j]], [[web3.js]], [[Nethereum]], [[protocol-buffers]], or a REST API.
Performance is important to many (but not all) Enterprise Ethereum use cases. However, performance is multidimensional; attempts to require specific performance targets on a single aspect generally leads to all implementations being optimised for that target instead of meeting the varying needs of Enterprise Ethereum customers.
There are some common goals however. Specifically, increasing the cost of a blockchain over time is incompatible with many use cases, and many use cases need to ensure significant scalability is feasible.
The computing power to validate blocks is meant to remain constant over time, regardless of the blockchain size or the number of network participants. The constant power requirements include:
- Ensuring the power required to validate a block does not increase significantly.Off-chain processing is a mechanism that can improve scalability. Likewise, Sharding, a mechanism proposed for Ethereum 2.0, will probably improve scalability too.
Implementations might implement data storage used for optional off-chain operations. For example, implementations could locally choose to cache the results from a trusted oracle or store information related to other systems extensions not covered by the [Client Specification](https://entethalliance.github.io/client-spec/spec.html).
Persistent storage that is resistant to brute force attacks generally uses a "defense-in-depth" approach. For example, instead of relying on restricted access to protect plain text storage, an implementation can further protect the data by encrypting it with an Authenticated Encryption with Additional Data (AEAD) algorithm, such as one described in [[RFC5116]].
Enterprise Ethereum clients might support local key management allowing users to secure their private keys.
Clients might also support secure interaction with an external key management system for key generation and secure key storage.
For example, implementations could securely interact with a Hardware Security Module (HSM), a physical device to provide strong and secure key generation, key storage, and cryptographic processing for deployments where strong security is needed.