After researching the Hyperledger project, I wanted to provide simple outline describing what it is, and what assumptions the project makes within the broader implementation of enterprise (or “mass-market”) blockchain applications and networks:

So what is Hyperledger?

Hyperledger is an enterprise-focused, plug and play, Blockchain framework that can be customized by companies and implemented privately on sed company’s network. The core features of Hyperledger are identity, audibility, private transactions, confidential contracts, modular consensus, performance, scalability, and chaincode. Here’s a few core differences between Ethereum and Hyperledger:

Instead of Smart Contracts, Hyperledger has “Chaincode,” which supports the JAVA, Golang, and JavaScript languages
Hyperledger focuses on private, siloed Blockchain implementations, where participating nodes are registered by a central authority and heavily permissioned and can transact privately
In Hyperledger, there exists a “Registration Authority” which can issue and revoke identities that are participating on the network
With Hyperledger, confidentiality is achieved by encrypting the transactionssuch that only the stakeholders can decrypt and execute them
With Hyperledger, contracts can be cryptographically secured so that it only gets loaded and decrypted at runtime
Businesses use their own plug-in consensus algorithm with Hyperledger. It uses a “Consensus Manager” to organize transactions
Hyperledger has Reputation Managers that enable auditors to view transactionspertaining to a participant , given access
Hyperledger has controllable/customizable “Membership Services,” including Identity Management, Registration, and Auditability
“Membership Services” uses Google RPC P2P Protocol (HTTP/2 standards), working with existing Internet infrastructure
Hyperledger’s Distributed Ledger uses RocksDB to persist the dataset, where large data sets are stored off-chain
Hyperledger supports two types of transactions: (1) Code-deploying that submits/updates chaincode and (2) Code-invoking that calls chaincode functions
In Hyperledger, blockchain state changes are committed to the database
In Hyperledger, there are 3 deployment models: (1) Cloud Hosted 1-Network, (2) Cloud Hosted Many-Networks, (3) Participant Hosted Intranet

Why does the Application Stack look like for Hyperledger?

View Logic: Mobile or Web UI
Control Logic: UI to Hyperledger API logic driving chaincode function calls
Data Model: Manages off-chain data storage
Blockchain Logic: Chaincode that communicates on blockchain

Why is it important?

It is important to companies that would like to utilize an open-source framework to develop their Blockchain application proof-of concepts in an “enterprise-forward” fashion, were central units still control major aspects of internal (and private) blockchain networks.

What is the “Hyperledger audience”?

Enterprise companies doing private network Blockchain application Proof-of-Concepts.

What assumptions does the Hyperledger project make?

This is where it gets fun! I was concerned with the following aspects of Hyperledger’s architecture, primarily because they serve as potentially massive attack vectors on this type of blockchain ecosystem:

Assumption 1: Using Cloud Hosted Network Topologies is Decentralized Given Contractual Control of Nodes

The Hyperledger White Paper quotes when talking about the Cloud hosted one network,

“Even though the network is in a cloud and hosted by a vendor who owns the physical hardware, the participants contractually control the computing resources, making the configuration decentralized within a centralized environment.”

….No. Just no. I don’t consider myself particularly smart and even I know that this is a major assumption. Attacks can still be made on the hardware of your Cloud host, or the Cloud host themselves can meddle with your hardware, OR a host of other attacks on how your network of nodes finds consensus. Just because you have “Contractual” control over something, unless there’s a damn good smart contract enforcing sed control, then you don’t have control.

Assumption 2: Reputation Managers, Registration Authorities, and Consensus Managers are not central points of failure

This is a glaring attack vector that enterprises are going to have to reconcile. If you want centralized control over a blockchain, something that was born our of decentralized consensus, then you’re going to have to think harder than literally outlining central points of failure that manage your Member Services and network consensus.Of course, there can be clever implementations of which node (or groups of nodes) serve as the network’s Reputation Managers, Registration Authorities, and Consensus Managers.

Assumption 3: “Membership Services” uses Google RPC P2P Protocol (HTTP/2 standards)

The assumption being made here is that mass markets (particularly commercial, business to customer markets) will use Web 2.0 far into the foreseeable future. The whole point of Ethereum’s existence is to usher in transaction forward Web 3.0 architecture with Swarm, and Whisper, amongst a plethora of decentralized applications based on sub-currencies of Ether.Running Membership Services using a HTTP/2 based P2P Protocol will only last so long. Yes, maybe decades, but certainly not 100 years.

Assumption 4: Blockchain state changes are committed to the database

I really do hope I read the White Paper incorrectly when I saw this:

“As transactions are run in a new block, a delta from the world state in the last block on the blockchain is maintained. If consensus is reached for the current block, the changes are committed to the database, and the world state block number is incremented by 1. If peers do not reach consensus, the delta is discarded and the database is not modified.”

….So are we persisting our state changes to the RockDB database? A literal central point of failure that, if tampered with, could destroy all participating nodes’ understanding of what the current state of the network is? Please call me out on this if I am misunderstanding — because I really hope I am.

Assumption 5: Businesses use their own plug-in consensus algorithm

Developing customized consensus algorithms to maintain private blockchains within a framework with centralized attack vectors is not smart. Businesses need to learn to retrofit existing Blockchain networks to use in private ways, like J.P. Morgan Chase did with Quorum. If you mess up your consensus algorithm, even a tiny bit, your customers will feel the wrath that bad nodes unleash on your network, potentially costing your company billions of dollars.

What are your thoughts? Let’s discuss!