>> Privacy needs to be solved differently anyway, e.g. through payload data encryption or zero-knowledge transaction. And here, permissioned ledgers actually aren’t that good compared to projects such as Enigma or Tezos.
Second sentence is a big assumption. Linking to each respective project’s websites != a compelling argument to declare “permissioned ledgers actually aren’t that good compared to projects such as <public ones>?
>> Control is a tricky one, as the question is who you trust more: Your competitors to play fair or a machine-coded incentive system to work as intended. If you use a permissioned network for monetary value exchange, you might actually loose in case of a participant’s bankruptcy since there are no publicly tradable tokens. A public ledger on the other hand is at risk of being hacked. Let’s call it a draw on this one.
If you enter into a permission blockchain with everyone. You have the blockchain framework’s code to enforce rules. But you should also sign business contracts. So if someone screws you over in the permissioned setting, you can sue them. In public space, since there are rarely external contractual obligations, you cannot guarantee the same.
>> It’s similar when it comes to maintenance of the system. Since it’s not practical to set up and run a network by your own, the decision is between having your permissioned network run by a technology service provider (BaaS) or a public network run by a non-profit organization and a self-governed community. A draw again, it’s a bit like deciding between commercial and open-source software.
I disagree, most if not all of the permission networks offered as BaaS are open source frameworks (hyperledger fabric, corda, parity Ethereum). So it’s not like “deciding between commercial and open-source software”. It’s more like deciding on whether or not to have someone host your open sourced blockchain network infrastructure and depending on level of control you want to give up, improving the existing user experience to certain things like voting and gathering signatures.
>> The most critical aspect though is complexity: Managing the number of networks, and managing updates to networks. If everyone builds a permissioned network with their partners and suppliers, we’ll have a combinatorial explosion of different networks for which each firm would have to manage its membership. And every time a new member needs to be added to a network or a member leaves a network, agreements would have to be updated with the other participants; multiply that by the number of networks. In public networks those aren’t problems, just business as usual.
That’s why people use BaaS so that a tech provider handles membership management. Plus frameworks like Hyperledger fabric have built in protocols to handle joining/leaving networks. Plus the combinatorial explosion fixation is built on a shaky foundation. It assumes that each network participant will create a permissioned network with each permutation of network participants in the network. I can not find many use cases where this is required.
>> In my opinion, permissioned networks are dead end, maybe except for very specific niches. I suppose people didn’t notice its biggest drawbacks yet, since almost no projects has moved beyond pilot stage. There is a lot of talk about throughput & privacy, even though that doesn’t really make a difference.
Throughput doesn’t make a difference? In an enterprise setting, if a permissioned blockchain is used to process transactions for businesses e..g for VISA, you need to handle easily 10k transactions per second. public Ethereum is at 20 TPS… I also dont need to talk about the necessity of privacy. Also “In my opinion permissions networks are a dead end” please enumerate the arguments for his thesis except for combinatorial explosion which is just a big assumption.
