By BlockApps CTO | Jim Hormuzdiar
The Ethereum public net works well, so why would anyone consider creating smaller private nets?
At BlockApps, our vision is “to restore to digital transactions the reliability and efficiency of face-to-face interactions through secure and connected information”. We want to bring you back to the day where you could spend a dollar out of pocket without the need to bring in banks, lawyers, and whole governments into that transaction. Blockchains are part of the solution, but in some ways make the problem worse.
Blockchains remove central authorities in a way similar to the old leprechaun story:
“a young farmer captures a Leprechaun and forces him to hand over his gold. The Leprechaun says that the gold is hidden beneath a tree in the woods and shows him which one it is. The farmer ties his red scarf around the tree and after making the Leprechaun promise not to remove the scarf he heads to his farm to get a shovel. But when the farmer returns he finds that the Leprechaun has tied a red scarf around every tree in the woods.”
Similarly, blockchains don’t eradicate a single central authority, but they convert *everyone in the world* into a potential authority. This improves trust and is nearly impossible to scam, however, it hurts scalability and anonymity. Old fashioned face-to-face transactions were scalable and anonymous, so it’s no surprise that customers ask us for private chains.
The ideal private chain would act like self auditing cash. Let me be upfront, the “ideal private chain” *does not* yet exist. Practical partial solutions do exist.
The “ideal private chain” would have the following characteristics:
- Scalability/Full Decentralization: If Alice and Bob exchange a dollar, bits would only flow on Alice and Bob’s computers, nowhere else.
- Privacy: If Alice pays Bob a dollar, Carol has no idea this happened.
- Solves the Double Spend Problem (across mutually private chains): This is hard to resolve with points 1 and 2! A private chain can lock funds on a global public chain, preventing spending in other private chains (this works at the expense of some privacy and performance. It also forces you to overcommit ahead of the transaction). The old pre-Internet banking system solved this problem in a very different way…. It allowed some double spending (bounced checks) in exchange for a fee (fines). Since the counterparties in a private chain typically know each other, this can be a viable option in some use cases. (I’ve never seen anyone propose this, however).
- Allows Smart Contracts: Alice and Bob can deploy Ethereum style programmable contracts on their personal 2 node chain.
- Orders Transactions Fairly: If Alice and Bob deploy an auction contract, we can trust that there is no bias in the selection of the ordering of transactions.
- Auditable: Although the data in a private chain is private, we will need to be able to prove certain results to the outside world (ie- final balances).
- Limited Visibility: Auditors need to view a summary column, but shouldn’t see all the other data. Alice should be able to pay Bob funds without seeing Carol’s balance. (this sounds like magic, but is all possible using stateroots and limiting who can see the various transactions).
So, how do some of today’s solutions compare?
Sidechains was an early proposal to break one chain into smaller ones. Mostly, the sidechains paper is a rigorous take on how to securely lock funds on one chain (well, Bitcoin in particular) and move the value to a newer, smaller chain. It is agnostic on the makeup of this smaller chain, but assumes that once the chain is done doing whatever it does, it will unlock the funds on the original chain, allocating ownership properly.
As such, sidechains mostly describe a tool that can be used in any other solution.
Attempts to use sidechains brought up some problems. For instance, small, new chains might not have the mining power to be secure. Plus, why do you even want to move funds from a secure blockchain (Bitcoin) to an untested one? Does the newly mined coin on the sidechain hold value, given that it is going to be potentially lost when the chain is dropped? If so, why do we need to move the original funds at all?
Sidechains taught some lessons, like “don’t use traditional mining on in a small temporary chain” (perhaps something voting based like variants of proof-of-stake or PBFT will work), and “transferring funds from a stable chain to an unstable one can be a bad idea” (although as collateral against double spending, it can be fine).
How does sidechains fare on the points above?
- Scalability: Quite good, except for a small locking footprint on the mainchain.
- Privacy: N/A, since nothing is specified about the rules of the sidechain (maybe good, maybe bad)
- Double Spend Problem: Since funds are globally locked, the double spend problem is solved.
- Allows Smart Contracts: N/A
- Orders Transactions Fairly: On paper this is solved, but in reality not enough mining power can be obtained quickly enough on a sidechain to make this really work.
- Auditable: N/A
- Limited Visibility: N/A
Hyperledger Fabric is a well thought out modular system that allows groups to build up a comprehensive blockchain solution. Fabric is its first implementation, but it cut some corners to get things up and running (ie- it is mostly a wrapper around Kafka, and is missing some components that would really qualify it to be called a blockchain).
Multiple chains can be obtained by creating multiple ledgers, but fabric has no native coin, contracts are not metered (in the same way that Ethereum meters gas), and consensus is owned by a central authority.
- Scalability: Very scalable, but only because as far as I can tell Fabric ignores all the problems that would make this hard (consensus, funds locking, etc). Basically multiple ledgers are just different instances of fabric that don’t communicate. (“no ledger data can pass from one channel to another”.)
- Privacy: Very secure, all the traffic is encrypted and permissioned, using industry standards.
- Double Spend Problem: N/A, Fabric doesn’t have a native coin. You need to program your own coin in a contract.
- Allows Smart Contracts: Yes, but smart contract just means “a program” (usually written in go). (this is referenced in many places, but this issue proves to me that there is no “gas” in Fabric)
- Orders Transactions Fairly: No, consensus is owned by a central authority.
- Auditable: An auditor can read all the data and transactions in the database, but you need to trust that the database hasn’t been tampered with.
- Limited Visibility: No…. this video claims that there is a roadmap item to share the ledger state without sharing transactions, but no work has been done (I would suggest they use a stateroot).
Quorum takes a compromise approach. Virtual private chains exist, but are ordered by the main chain (this is a bit like merge mining, but happens at the transaction level). For privacy and performance, only hashes of private transactions appear on the main chain (each user in a private chain needs to run their own private transactions in the order determined by the main chain). Block consensus is great (if you trust the public chain). Scalability is better than one public chain, not as good as fully independent chains.
Despite the closeness of Quorum public and private chains, there is no sharing of tokens or any other data between the two (adding this would be easy, as the chains are already synced). Unfortunately, despite the fact that private chains can have their own stateroots, there is no verification between parties that these stateroots remain synced. In fact, stateroots are actually not chain based, but peer based, which in rare circumstances could lead to chain inconsistencies (this will probably be fixed soon).
- Scalability: Medium- private transactions are kept off the main chain, but hashes are stored on it.
- Privacy: Good (private transactions are encrypted and sent using a separate service).
- Double Spend Problem: Between chains, this is not solved. Value is never moved from chain to chain, and value in the chains is hidden (It wouldn’t be that hard to add this though)
- Allows Smart Contracts: Yes, all chains use a full EVM
- Orders Transactions Fairly: Yes, as long as the main chain has enough mining power. Private chains use the main chain for mining (at a small expense for scalability).
- Auditable: Yes/No (it’s complicated, there is a stateroot, but it isn’t verified). Since all the transaction hashes are stored on the main chain, you can always forgo some privacy and hand the full history transaction to an auditor.
- Limited Visibility: No, but could be added if the stateroot verification problem were solved.
State channels are a bit like a Starbucks card. You lock up some coins on the public chain (ie- purchase a $20 Starbucks card), then quickly spend offchain in small increments until the coins are used up. Some clever blockchainin’ at the end guarantees funds distributed accordingly. So, many small transactions convert into two public chain transactions (one to lock, one to unlock). You can also glue together two one-way state channels to create a two-way state channel.
State channels are only useful for payments between a fixed set of users (typically two). If you happen to know that you and a buddy are going to exchange a lot of tokens in a short period, they can improve performance. For just one or two transactions, however, there is no advantage, just a bit of overhead.
- Scalability: Quite good (most of the work is off-chain), but not perfect (you still need to lock up funds on the mainchain)
- Privacy: Potentially perfect privacy (depending on how the transactions are sent), other than the public locking and final transfer on the main chain
- Double Spend Problem: Perfect (funds are publicly locked on the main chain, so other private chains know not to use the same funds)
- Allows Smart Contracts: No, just used for payment
- Orders Transactions Fairly: No, you could never run a fair auction on a state channel.
- Auditable: Yes, counterparties can provide the newest signed transactions and balances (the other peer can offer a newer transaction if the first peer is lying). More importantly, the system won’t allow resolution with the mainchain in a false state (unless one of the peers goes offline during the resolution period)
- Limited Visibility: N/A- There is only one number to audit…. The account transfer balance (between the two chosen peers)
The lightning network is the next evolutionary step of the state channel concept. The Lightning network sets up a set of state channels between a handful of users, then manages multiple hop transactions across these channels in ways that let all parties send value to all other parties. The end result is a system with similar performance to state channels, but with many fewer state channels needed.
- Scalability: Similar but better than a single state channel.
- Privacy: Poor, since your payment might go through any other user.
- Double Spend Problem: Perfect, funds are locked on the mainchain.
- Allows Smart Contracts: No, the Lightning Network is for payments only.
- Orders Transactions Fairly: No, you could never run a fair auction on a state channel
- Auditable: Yes, although the token trail is more complicated than a single state channel. In certain circumstances it might become intractable, although the final balances are provably trustable. As with a single state channel, it is almost impossible for the main chain to be brought to a false state.
- Limited Visibility: N/A- There is only one number (per account) to audit…. The account balance.
Plasma is ambitious, but still in the research stage and yet to be fully implemented. If built, it could be very impressive.
The plasma architecture would be a multi-chain solution for smart contracts. It is well thought out, avoiding the pitfalls of previous projects (like sidechains), while offering some of the advantages of successful projects (like the Lightning Network). It is a huge project with many sub parts that could be build up piecewise.
Plasma arranges multiple chains into a tree like fashion. Locking and bonding happen on parent chains in a way that allows the transfer of real value in the children blockchains, while simultaneously keeping child chains honest.
- Scalability: Similar to sidechains or lightning…. Tokens on the main chain are locked, then the rest of the work happens outside of the main chain. Byzantine actors can force private chain transactions to run on the main chain, although game theoretic considerations imply this should never happen.
- Privacy: Good, but there is potential trouble. Work generally happens on the smaller chains, which implementers may choose to keep private, but Byzantine behavior can push work up to a parent, forcing a breach in privacy.
- Double Spend Problem: Perfect. Tokens can be locked on the main chain to prevent chain-wise double spending.
- Allows Smart Contracts: Definitely, definitionally! Plasma is an attempt to bring multi-chain best practices to smart contracts.
- Orders Transactions Fairly: Questionable, depending on the circumstances. The paper mentions using proof-of-stake for consensus, which is probably a wise move, given the flakiness of proof-of-work in small temporary blockchains…. However, in small (2-10) peer chains, it is likely that one participant will dominate. In really small (2-3) peer chains, participants will always order transactions to their liking. It doesn’t seem possible to me that any type of auction contract could work on a small chain.
- Auditable: Yes, if implemented, plasma will include a map-reduce like tool that can query data across chains….
- Limited Visibility: The map-reduce tool could certainly be implemented to selectively show or hide information, however, remember, if work is moved up to a parent chain, it will be made public anyway….
I have doubts that ordering fairness is even possible in a small private chain (i.e no fair digital auction can occur solely between two peers in a private network without some external source of randomness). As far as I can tell, no product has solved this problem (without using the main chain for ordering, like Quorum does), and I am not completely sure if this is possible at all.