Enterprise Ethereum
Kaleido supports all major Enterprise Ethereum implementations, which are compliant with the EEA client specification. In addition, Geth which is the most popular Ethereum implementations in the public Ethereum networks, is also supported with the configurations compatible with permissioned network deployments.
Technical Overview
The core Ethereum protocol was born out of the open source effort to build a public decentralized smart contract platform. The protocol specification in the form of the yellow paper has been in publication since 2015 and implemented in many languages. The protocol has been battle-tested and hardened from running in the permissionless Ethereum mainnet and various testnets.
In order to address the enterprise unique needs for privacy, scalability, governance and deployment options, a number of companies both big and small have worked independently to create versions of Ethereum clients that support permissioned deployments. These include Quorum by JPMorgan, Autonity by Clearmatics, Hyperledger Besu by PegaSys (a team in ConsenSys), and Strato by BlockApps. For the last couple of years these companies have started working collaboratively under the leadership of Enterprise Ethereum Alliance (EEA) organization, where Kaleido has been an active contributor, to create a robust Enterprise Ethereum technical specification.
EE Client | Modified From | Developer | Open Source License |
---|---|---|---|
Quorum | go-ethereum | JPMorgan Chase | LGPL |
Besu | New implementation in Java | PegaSys | Apache 2.0 |
Autonity | go-ethereum | Clearmatics | LGPL |
Strato | Haskell Ethereum | BlockApps | Closed-source |
The EEA based collaboration has resulted in enhancements in privacy, identity management, permissioning management and many other aspects in the clients. Currently Kaleido supports the two most widely adopted clients in this group: Quorum and Hyperledger Besu.
Trust Model
The Ethereum protocol is designed to operate in a trustless environment, where no assumptions are made about the safety of the incoming transaction and block relay messages and transaction requests. Each node independently validates every transaction by executing the smart contract. All nodes are expected to have exactly the same copy of the "ledger", or the long list of transactions packed into chains of blocks. Rouge behaviors can be easily detected by mismatched hashes from the different states that do not fit in the merkle tree.
The transaction model also makes no assumptions about identities other than valid signatures. In fact, the smart contract knows nothing about the real identities behind the transaction's signing key. To make this work in the enterprise context, where strong KYC (Know Your Customer) is the norm, application developers must resort to custom components and off-chain mechanism to manage identities and permissions.
For this reason Kaleido has built a pluggable Organizational Identity Registry that allows real world identities to be projected onto the onchain world with verifiable cryptographic proofs. This registry design has been adopted into the latest version, v5, of the EEA Technical Specification.
Privacy
All the Enterprise Ethereum implementations listed above have implemented strong privacy support to allow transactions to happen only between a subset of parties in a verifiable way, which is formally described in the EEA Technical Spec.
The basic design principle is to encrypt the payload and send to the counterparties directly, while broadcasting a commitment (a hash) of the transaction to the entire network as a proof of event for non-repudiation purposes. This way only the counterparties know the transaction details while at the same time the safety is guaranteed by the decentralization of the whole network.
Another privacy concern is about hiding the identities of the counterparties. Because in Ethereum all transactions must be broadcast to all participants in the network, competitors can gain a fair amount of insights by tracing the signing keys behind transactions and analyze trading patterns. A clever solution is to use one-time signing keys. Signing wallets such as Hierarchical Deterministic Wallet (HDWallet), using cryptographic key derivation algorithms, can produce practically unlimited number of signing keys seemingly not related to each other from a single seed secret. Using wallets such as HDWallet makes it possible to use one-time signing keys without having to separately keep track of each key in a huge database.
Finally, some use cases require a globally coherent state to be used to validate transactions. For instance in a token economy it is essential to be assured that every token is not double-spent. While many token types are robustly supported in Ethereum, it also requires all account balances to be transparent to all the participants in the network. In order to maintain a global state without having to disclose counterparty's account balances, advanced techniques such as zero knowledge proofs can be used. Ethereum has been a fertile ground for designing and proving zero knowledge proof algorithms, such as Aztec, Zeth and Zether. Kaleido has built-in support for zero knowledger proof tokens based on the Zether protocol.
Consensus
With every node maintaining a globally validated ledger, the consensus algorithm is essential to make Ethereum networks function. Permissionless blockchains such as the public Ethereum mainnet must use probabilistic algorithms such as Proof-of-Work, or Proof-of-Stake, which require an economic incentive mechanism to function. In a permissioned blockchain context, where all participating node have their identities pre-validated through an onboarding process, faster and more efficient consensus algorithms can be used.
The Ethereum clients in Kaleido support a wide range of consensus algorithms, both in the Crash Fault Tolerant (Raft) and Byzantine Fault Tolerant (Proof-of-Authority, Istanbul BFT) varieties. They each have different characteristics that may be the best fit for certain types of use case requirements.
For a detailed overview on the various consensus algorithms please visit our blog Consensus Algorithm: Poa, IBFT or Raft?.
Programming Model
Ethereum transactions only need to be sent to a single node, typically one either operated by the organization itself or a trusted operator, which will in turn broadcast it to the entire network. In the case of private transactions, the private transaction manager (Tessera for Quorum, or Orion for Hyperledger Besu) will broadcast it to the other designated counterparties.
Transaction ordering in Ethereum is provided through per-account nonces, a sequentially incremental number, which must be consecutive. If there are gaps in the transaction nonces, all transactions with nonces after the gap are held in a queue until the gap is filled in with transactions using the missing nonces.
The client typically is responsible for figuring out the right nonce to use and signing the transactions accordingly. This can be a trickly business especially when transactions are submitted from multiple clients. Kaleido has developed a robust solution to alleviate application developers of these low-level, complex programming concerns, with the REST API Gateway.
Smart Contracts
Smart contracts in Ethereum are EVM (Ethereum Virtual Machine) bytecode compiled from high level languages such as Solidity. Many essential developer tools are available, such as:
- compilers: solc
- unit testing: truffle
- local environments: ganache
- debugging: remix
- library: openzeppelin
For life cycle of smart contracts, Ethereum takes the philosophy that contract code is not immutable. Once deployed it's saved on the chain as an immutable state. If updates are needed, new deployment will result in a completely different instance of the contract code living on the chain.
Techniques such as proxy contracts are available to make smart contracts upgradeable.
Asset Tokenization
Tokens are a powerful programming model to make transactions interoperable based on universally recognized interfaces. The Ethereum community has pioneered many types of tokens: fungible or non-fungile, divisible or whole, mintable, burnable, etc. All have gone through validation with active deployment on the public mainnet.
Industry Adoption
As a general purpose blockchain protocol, Ethereum can support any industry use cases. Enterprise Ethereum has been powering business networks in many industries. Visit the Industry Solutions page to see examplery industry use cases built on Ethereum.
For a deeper understanding of how the Ethereum protocol compares with Corda, as well as Hyperledger Fabric, visit our blog A Technical Analysis of Ethereum vs. Fabric vs. Corda