How private chains make sense (when connected to public chains).

Being a blockchain facilitator, we get asked a lot about what the use case of a stand-alone “private” chain is. Phrases like “… just a bad database” get thrown around a lot, and there seems to be a more absolute split in opinions, akin to the decentralized or not debate. I would like to shed some light on our thinking here, as well as try to establish a taxonomy to ensure we all speak about the same things.

Want to hear more about how Blockdaemon can help you with your Blockchain journey? Contact us today to chat more about our blockchain solutions, or read on to get a closer look at what’s new.

Privacy was first.

Blockchains started with privacy at its core. When and what to release about yourself by yourself. Privacy does not equal anonymity, quite the contrary. In this context it stands for transparency when participating in the context of an event (a transaction or identification). For Bitcoin that means you share the data that is relevant, i.e. you have the funds here and are sending them there. You don’t need to know my home address, just that I have the tokens at a specific place in time. It is the core of a financial transaction. It is transparent yet private.

The main breakthrough, besides the cryptographic components of a blockchain, is the elimination of the double spend problem via consensus that can not be “faked” (because it is decentralized and would require a hacking into 51% of the nodes). Bitcoin has 10,000 nodes all over the world, so faking it is hard to nearly impossible.

‍Everyone can run a node and audit every transaction that ever occurred.

Private Chains are the Grand-Macho-Solos of Databases.

“Private” chains are generally understood to be something altogether different. Private blockchain stands for a chain with a few controlled nodes, that only a select few can look into. They are generally understood to forgo the benefit of decentralization, which allows them to be i) faster and ii) less costly (in total) than public chains. But since they offer privacy without transparency, it’s hard to find a raison d’etre for them, never mind calling them a blockchain.

Since only a few involved parties have access, it’s akin to building a new mobile network including cell towers to chat to 3 or 4 other parties, instead of using a conference call app. Possible but not necessary. A tad over-the-top and only useful to impress others who don’t know better. Most blockchain-as-a-service providers like the cost model underneath a chain (expensive), hence they are pushing this concept, but it makes little sense for enterprises outside of POCs and learning. If no outsiders can validate and hold you accountable, why not go with a direct peer-to-peer connection and a legal contract for binding trust?

Are there useful enterprise solutions using blockchain components?

Does that mean that there is no scenario in which an enterprise should use a blockchain? Of course not. Blockchains are trust-engines with immutability, and there is enough of mistrust and mutability going on in the enterprise space that makes for productive blockchain grounds for enterprises. Where can blockchain simplify a contract? How can it be more efficient than complex audit clauses? Only if total cost is negligible, connection/integration is seamless, and efficiencies can be established when trust seems to have been broken, i.e. easy auditability. Most importantly, immutability needs to be intact. What does that mean?

Business Elvis taught Blockdaemon.

When I started my career negotiating software licensing and distribution deals for mobile data-networks, we often had multi-party contracts (3 or 4). We were T-Mobile International, where I worked for the illustrious Elvis for business for a few years. A deal would be struck with a handset manufacturer (Nokia), a software provider (Microsoft), and a slew of adjacent payment and content partners. Revenue was shared downstream via a combination of rev-shares as well as per transaction minimas. In the end, we held all the data to prove what had been acquired in our ERP & accounting systems (since T-Mobile is a German entity, those were mostly SAP ones). How could any of our partners be sure that we paid them adequately?

They couldn’t. Their sole protection was a legal clause that came with enormous potential cost — a right to audit the books if deemed necessary. The potential cost and consequence mostly kept participants honest, but mistakes remained undetected or without consequence. Tens of thousands of legal $’s are spent trying to define and limit the fall-out of a scenario where an audit becomes necessary. Trade agreements like these are great use-cases for blockchain-tech, with a stack that grows in decentralization.

Hash to hash.

If it is quicker and easier to connect systems and automatically hash to a protected chain that in turn is protected by a “decentralized” one, there is a use-case for permissioned blockchains for enterprises. The ROI calculation needs to make sense, though. Currently it doesn’t. Joining complex consortia, betting on a protocol to survive the pending war of protocols, plus the maintenance of a blockchain dev team make blockchains inefficient. For now.

Lowering the barriers for connections of enterprises to a blockchain is our core tenet. We connect developers to public chains (mostly by individuals) and enterprise private chains. We always remind developers that the benefit of blockchains is private transparency and the only sustainable cost-structure is to connect to a public chain with indirect data being pulled from existing systems. Enterprises have a lot of rules and needs when it comes to data and what they can and can not connect to. Security standards play an important part. It makes most sense to connect a small private chain to existing ERP and accounting systems, so security can be managed, and proof-points can then be hashed into a mainnet that can run queries and serve as a buffer to a fully decentralized chain (i.e. Bitcoin). This requires compliance and security certifications (ISO, SOC etc.; all of which we have). This way public chains can reach back into private chains (they are faster and cheaper) back into enterprises. Now, is that still a blockchain? It is distributed ledger technology being decentralized at the second degree (or key). That is what we mean by a private chain.

No one likes a know-it-all but …

Currently we provide nodes for every major blockchain project — we try and stay agnostic, since, frankly, we are not THE experts and can’t foresee which blockchain, private or public, will inspire the largest developer user base. We are open to all. More and more we do get asked, however, what blockchain to deploy — since we currently launch fabric, quorum, ethereum, stellar, aion, bitcoin asf., we have experience in associating a practical use-case to each based on complexity and cost.

Enterprises ultimately want to be freed from the conundrum of choice, what public or private chain to use, which is the next problem we are actively tackling. Eliminating choice of protocol by channeling data to the most relevant plumbing automatically.

You will be able to experience our interim step to the auto-selection and config-wizard in our ecosystem deployments that are coming for Aion blockchain and Citizen Reserve. These ecosystems need to be simple for developers to connect to and allow for a modicum of configuration so they become usable right away. This, plus our social invite system, lay the foundation of our version of an enterprise product.

Stay tuned for updates and remember, if you aren’t connected to Bitcoin, you are driving the cryptocurrency-highway without paying your toll (click here to deploy a Bitcoin node).