The Private Blockchain Fallacy
berk.es
berk.es
The article talks about reasons for wanting a private blockchain. But I have never heard any of these reasons come up in any of my projects. I'm not sure what projects the author is talking about, but definitely not anything related to what most private blockchain projects companies are doing. That said there is a lot of hype in the space (not denying that).
You can make an argument that bitcoin in the whitepaper was defined as an open access system, and as such any closed access system is not a blockchain. Sure, but the developers on these projects (like me) are calling them blockchains nonetheless because most the of the tech is the same (except for things like consensus forming, you probably would never use PoW in a private blockchain).
----
Companies are looking into private blockchains because they allow for systems where not one party is in charge of all the data and the network. But they require more than an append only log.
Otherwise the public/private key could also be used for the encryption of the contract. Then you have an encrypted blob signed by both parties, and any of these two parties can decrypt it.
What I am not sure I get is why you need a block chain when the parties know each others. If they exchange public keys (and financial institutions have to go through a lengthy KYC process anyway), do you need a proof of work mechanism given that a transaction could be validated simply by both parties signing it.
What is more, when there is a "consortium of companies that do no trust eachother using a private blockchain" they imply three things:
* They have a permissioned system: not everyone can participate. This means there is a mechanism to punish adversaries right there: just remove their permissions! A large part of what "a blockchain" is all about, is dealing with sybil attacks stemming from the requirement of it being permissionless. * They know eachother. Hence there won't be a sybil attack possible. * They have established communication channels (otherwise it is impossible to grant access to the private blockchain). Hence the Byzantine problem is non-existing or not an actual problem.
Maybe, very maybe, there is a case for a private blockchain in which there are many participants and a system to fully anonymize all these participants once they "are inside the firewall". I really cannot comprehend this, though. But that would make a case for a private blockchain, becayse sybil attacks are then again possible and need to be dealt with.
No bank inside the EU is allowed to send one bitcoin to another bank for the reason that the miner (a service provider) is not KYCed. There are ways around this (by not broadcasting the UTXO in the open, but only giving it to a miner you KYCed before - but other things like in some jurisdictions bitcoin isn't fungible from a legal perspective, meaning the Bank is required to have KYCed everyone who ever owned that Bitcoin). In other words, public blockchains are a world of pain from a compliance perspective in highly regulated fields (like banking).
Note that technology is a few steps ahead of legislators. And banks cannot take any risk in doing things they are not allowed to do.
> Otherwise the public/private key could also be used for the encryption of the contract. Then you have an encrypted blob signed by both parties, and any of these two parties can decrypt it.
If no one is able to validate the contract, why push it through the blockchain at all? Just use PGP over e-mail? That said: it's an interesting approach and a number of blockchain systems offer you to do exactly this: you have a contract with another party (node on the network), you both sign and it push the hash to the blockchain. So that everyone in the network can form consensus over that you and someone agreed to some contract that hashed to Y (for example private transactions in Quorum). But note that here you are still leaking a lot of data: people can figure out you have a contract with someone else, etc.
> What I am not sure I get is why you need a block chain when the parties know each others. If they exchange public keys (and financial institutions have to go through a lengthy KYC process anyway), do you need a proof of work mechanism given that a transaction could be validated simply by both parties signing it.
The KYC is indeed lengthy, but only a small part of the story:
I'm dealing with a lot of situations that are like "a chain of contracts". In commodity trade finance you'll have contracts between buyers and sellers, and both of them can use a bank. There are a huge number of parties involved and between all of them there are contracts (the seller is going to ship some goods, for example by boat between different countries - this requires a ton of parties and certificates, documents from customs, etc).
All of these contracts kind of rely on each other, for example the contract between the banks (the LC) has a lot of information regarding what was sold and bought - and this needs to match whats in all the other contracts and documents. Right now you have huge departments where people are going over this manually (multiple times per party), there is some software but there is not very much digitally communicated between companies.
Note that most of these contracts are signed months before the sale, and in most cases most people in this chain are not allowed to see the whole chain, just a small part that concerns them. At specific times (not when the contract is signed).
A private blockchain allows you to build these kind of solutions. With a public blockchain you can too but there are many more obstacles. What if the encryption is broken 20 years down the line? All the data would be on the street..
It's not trivial, but at least possible. Because if you are bank you cannot ignore the law because you want to use Ethereum mainnet.
As an example, 2 parties can enter into a contract. The contract details are signed by both parties. The contract is placed on a blockchain that's visible to both parties and any interested regulators etc. You can even use the same chain for multiple competing parties simply by encrypting the contracts.
Note, this isn't acting as a transaction in the Bitcoin sense. It's simply using the basic mechanism of linked, hashed blocks to establish a permanent time-ordered ledger.
Time passes. Now, if there's any dispute, all parties have a shared view of exactly what occurred when. It's not practical to manipulate it as the parties know who they all are and can easily resort to external measures.
But it does solve a huge, very expensive problem that financial institutions and regulators have: a single, shared version of the truth. This is a multi-million dollar problem and blockchain tech can definitely be part of the solution.
But as I said, IANAL.
> As an example, 2 parties can enter into a contract. The contract details are signed by both parties. The contract is placed on a blockchain that's visible to both parties and any interested regulators etc. You can even use the same chain for multiple competing parties simply by encrypting the contracts.
> Note, this isn't acting as a transaction in the Bitcoin sense. It's simply using the basic mechanism of linked, hashed blocks to establish a permanent time-ordered ledger.
For this, you do not need a blockchain. Instead hashed and signed non-cyclic data structures suffice (e.g. hash lists [1], hash chains [2], hash trees). Note that the Merkle trees ([3]) that are used in Bitcoin are special cases of hash trees.
According to [3], "[t]he concept of hash trees is named after Ralph Merkle who patented it in 1979.".
What do blockchains solve that cannot be solved by these data structures that are 40 years old? The answer is: decentral consensus when the parties cannot trust each other. This was the missing building block that was necessary to build a decentral cryptocurrency.
[1] https://en.wikipedia.org/w/index.php?title=Hash_list&oldid=8...
[2] https://en.wikipedia.org/wiki/Hash_chain
[3] https://en.wikipedia.org/w/index.php?title=Merkle_tree&oldid...
Indeed. But if that's not what you want then you can drop that bit and use the rest.
If your point is that nothing stopped people doing this a generation ago, if they'd thought about it, then I agree completely.
But the key bit is they didn't think about it (or think it was sufficiently important). What Bitcoin did was publicize the techniques and, crucially, show that the interesting bits work well.
Of course, if you choose to use a definition of blockchain that involves trustlessness then the usage I described isn't blockchain, by definition. By I tend to use Satoshi's definition, more or less, which is orthogonal to the idea of trust.
> But the key bit is they didn't think about it (or think it was sufficiently important).
My opinion on this topic rather is: everything (except how to build decentralized trust) has been known for a long time. It is also known for a very long time that these techniques work well (otherwise Satoshi Nakamoto would never have come up with the idea to make them a central piece of Bitcoin). The central reason why it wasn't implemented before rather was that the people who knew about it did not have the charisma to convince "the people with money" that they should finance an implementation.
For example, already in 1989, there was an attempt to build a digital anonymous (though not decentral as far as I know) currency called DigiCash by David Chaum:
> https://en.wikipedia.org/w/index.php?title=DigiCash&oldid=83...
What happened to them? This company simply went bankrupt in 1998.
I am interested in esp not using PoW in consensus - what makes consensus??
Consensus is arguably the hardest part of a blockchain (if you need distributed data storage just use something like IPFS). An example is Quorum (JP morgan fork of Ethereum), this is their take on consensus algorithms:
https://github.com/jpmorganchase/quorum/wiki/Quorum-Consensu...
> use case where I personally see the benefit
This is just infrastructure (as it should be), right now the middlemen are very expensive because of all the paper documents going between companies, and all the people hired to go over all of them. The usual arguments for these projects are:
- Cheaper
- Quicker decision making & communication
- Less fraud & errors
For us consumers that would probably result in cheaper apples in the the grocery store I guess.
Anyway, I'm really curious to see what people come up with! And yes, being faster and cheaper is summing up logisitcs pretty well! ;-)
I'm no expert on fraud, but I think most of it comes when data enters a system. With a blockchain (or any digital system really) you can easily check that your data stays consistent (when it needs to be between different documents and contracts). But if the guy entering how many tons of apple are in this container is lying about it a blockchain won't really help you.
Note that this ignores the huge expense of measuring and storing all of this data, but I've seen some interest in these use cases in Asia, especially for staple crops like rice.
More advanced systems consider using third party, tamper proof scanning systems and packaging. Again, the costs of these systems are quite high, especially for food, but there are physical ways to reduce fraud if the data holds enough value.
Someone who fakes products can read the blockchain and print fake labels based on what is there.
> This lets you investigate and file complaints on the public blockchain. Think of it like a review of a company's supply chain reliability.
So the blockchain in this case is used as company review database? How is a blockchain useful for that?
A blockchain is useful as a review database because you have guarantees that the reviews came from the claimed reviewer. This reduces fake claim fraud, which you might, for example, see in restaurant reviews. The reputation of the purchasing company is also at stake when they make claims that another company committed fraud. You want good guarantees that information came from the party it's ascribed to. It's reputation building in a scenario without mutual trust.
One is that in a trustless blockchain like Bitcoin your source of truth is the blockchain, no external force (based on some security assumptions) can change that. In a private blockchain the source of truth is the law, if the organizations signed their transactions, published it in a typical SQL database but they were not recognized by the other parties you can sue other parties legally. This is not possible with public blockchains.
Another is the number of security point of failures you have. If you use your blockchain for supply chain but the input to the supply chain depends on devices, since all these devices can be hacked or impersonated you cannot trust them.
> Because if there was a simple MySQL solution from a company they would have gone with that 2 decades ago.
No, this is an organizational problem where different organizations cannot agree on different protocols. It is difficult to agree on a common API, workflow, etc if you have 100 organizations.
I don't know any private blockchains that have apps running on smartphones that connect directly to them. Companies have IT systems (what your app talks to) running in private clouds protected by cameras, people with guns and layers of firewalls. And those systems interface with a private blockchain. Authenticating over a number of factors (eg. 2FA) is obviously done, but that's unrelated from the blockchain.
> In a private blockchain the source of truth is the law
Definitely not true (in any jurisdiction I have worked in, mostly EU), and if it was lawsuits are very expensive and drag out over long periods of time.
> No, this is an organizational problem where different organizations cannot agree on different protocols. It is difficult to agree on a common API, workflow, etc if you have 100 organizations.
You're right that it's hard, but that's definitely not the problem in any of the projects I have worked in. The problem is trust.
In the example you mentioned: supply chain, you have an external device (outside the blockchain) pushing transactions to the blockchain. You can see this example repeated over a billion of times, it is the typical private blockchain use case. I am not inventing anything new here, just exposing the claim vs. the reality.
> Definitely not true (in any jurisdiction I have worked in, mostly EU), and if it was lawsuits are very expensive and drag out over long periods of time.
The law is the last resource I cannot imagine NASDAQ and financial institutions having security issues because the financial institution doesn't recognize a message signed by NASDAQ. This is clearly ridiculous. This can be handled in many ways If the message was signed because of fraud or a security breach.
I have worked on on proof of concept experiments that did this. Because it's easier to showcase "data goes in here, comes out there". But that's obviously not how these products will run in production. All these experiments aim to test/showcase the viability of using a blockchain between parties. The app is just there to show the business people how it works (also for PR reasons).
> The law is the last resources I cannot imagine NASDAQ and financial institutions having security issues because the financial institution doesn't recognize a message signed by NASDAQ. This is clearly ridiculous.
I'm not saying that if NASDAQ signs a message that won't hold up as proof that NASDAQ said something. I am saying that if two parties engage in a transaction and it's recorded in a digital contract on a blockchain, that might not always be enforceable as such in a court.
As I said before and can expand now, blockchains have very specific security assumptions that are not present in a public blockchain. Once you remove those assumptions cryptographic protocols are enough to give security when organizations are not anonymous.
> I am saying that if two parties engage in a transaction and it's recorded in a digital contract on a blockchain, that might not always be enforceable as such in a court.
Digital signatures are recognized by the law in most countries.
Digital contracts are not. If you believe they are, start posting some examples like you keep asking me to do.
> Show me a production ready product and I can show you how you can do the same without a blockchain.
I don't know any production blockchain solutions I'm allowed to talk about. Do you know any?
> I don't know any production blockchain solutions
Nothing more to say. There is no production ready private blockchain to show.
BTW, I work in this field in very well known projects (e.g. RSK, Algorand, Xapo, Jaxx, Ripio) in the public blockchain space and have adviced companies like MuleSoft at the CXX level in the private blockchain space.
This makes the piece come across ideological. As a case in point, you write that the public aspect of a blockchain is what ensures its permanence but that is not at all the case. The public aspect is what guarantees open access. Open access in turn guarantee decentralization under conditions where decentralization is economically feasible. The only thing that guarantees permanence is the economic incentive structure that pays participants to store and distribute data.
We don't have a good taxonomy for discussing these ideas yet, but most people working on scale are beyond this. Ethereum is experimenting with rent. Bitcoin variants exist which have adjusted their genesis block manually. Some layer-two networks are designed be transient, while Saito uses a transient blockchain to put bandwidth-intensive applications directly the first layer. The direction of development in the space is tilting very clearly towards utility networks and disposable data-structures. The disagreement is over at what layer this needs to take place, and how to preserve things like open access while paying for things like bandwidth and storage.
I think, indeed, that with "permanence" i've made the mistake to pull that together with "immutability". My first draft had them as different points, but I found that this made the explanation too complex. So I decided to go only for "immutability" and to move the "permanence" under there.
In your definition of permanence (the correct one, BTW) this is not the same. Permanence needs economic incentives. As we can see with IPFS (and it not -yet- being permanent in practice). Immutability, however, needs (i) cryptography and (ii) conflict resolution and (iii) permanence. Which implies "being public". As I tried to explain.
Or did I misunderstand your comment, and do you mean immutability as well as permanence?
On the permanence/immutability issue, I guess my opinion is that permanence is distinct from immutability and that while all blockchains require immutability, they can exist with varying degrees of data persistence. I tend to think bitcoin would be perfectly safe running on a 100 year chain with periodic hardforks to upgrade the genesis hash, for instance, and that it would be a bit strange to suggest that this wouldn't count as a blockchain, even if the trade-offs would make the network lose some properties of "digital gold". At a minimum, arguing otherwise would seem to imply that UBTC isn't a blockchain, which is obviously wrong.
Exercise for the blockchain advocates: explain as simply as possible why a “private blockchain” is better than Git.
they both might be able to perform similar functions with enough customisation, but a blockchain is fit for purpose out of the box.
note: i’m thinking here a blockchain with POA where tokens are distributed between known parties, so no overhead of POW. POW has very obvious down sides
Besides, how can people say a private blockchain is "trustless"? You just said "POA" ( = proof of authority). The conversations I often got into at my job were like this. It was so incredibly difficult to pin down exactly why they even wanted a blockchain. Or what a blockchain even was in their heads.
Git (or a DAG) + priv/pub keys + Proof of Work = blockchain
If you remove "PoW" it is just "signing in git". Which is an interesing and complex thing.
And it being private removes all the need for PoW or removes the function that PoW fulfills. So a "private blockchain with PoW" is really stupid and (even more so) a waste of energy.
Whereas a "private blockchain without PoW" is "just git".
1. Blockchain was this clever solution related to money. Anonymous person invented it. Some news about crime around it. Lots of money around it. So blockchain is this money thing and technology thing? Sounds kinda sexy.
2. Business people heard about it, thought it might be The Next Big Thing. Ask boffins to investigate.
3. Other business people heard their rivals think blockchains are The Next Big Thing so they need to get on it too.
4. hmmmm, turns out a business is mostly all about being centralized which is at odds with a boockchain. hmmm it's actually kinda uselsss? Maybe we can get rid of all the bits we don't like about it? oops we just reinvented the wheel.
A "private blockchain with proof of authority" is like cutting the hump of a camel and calling it a horse. Just use Git.
>A "private blockchain with proof of authority" is like cutting the hump of a camel and calling it a horse. Just use Git.
This sounds clever, but it isn't right: Git has no equivalent to consensus for transaction correctness, for example. It has no equivalent to smart contracts. It has no peer discovery mechanism. It has no automatic transaction propagation mechanism. And on...
Executive summary : "there may be a pony in there somewhere"
I conjecture that blockchains have no applications beyond cryptocurrency. I hope someone can give me a very simple counterexample. I've seen blockchains for the music industry, for porn, for university, for bananas in Laos, for weed, for voting, for "supply chain" something or other. I've never seen an application explained simply that makes sense. I am highly skeptical of the field.
The storage part of the transactions is suprisingly simple and is what makes up the blockchain: the PoW, DAG and signatures of all that: PoW + git + pub/priv signatures.
Because with git you either go:
- The linux way with one upstream and everyone branching of the "main" repo: In a lot of ways everyone is relying on the centralized main repo of linux, and in every other way they disagree on the final state (eg. the final code).
- The "github" way where there is one version hosted on a centralized service that everyone needs to trust.
Beyond the obvious security problems when trying to use git for actually important data ( for example: https://shattered.io/ ), git doesn't help you in any way to come to a consensus about what happened and in what order. Instead it gives tools to rewrite history as how you see fit (like rebase).
> Merkle trees have been around since the 70s.
Blockchains didn't reinvent many things, 95% of a blockchain is basic cryptography. Merkle trees are awesome and they are used as well (for example when grouping transactions into blocks within Bitcoin). The reason why you need more than a merkle tree is because a merkle tree doesn't help you if:
- You can't trust one single party to maintain (or host) the whole thing: yes you can use digital signatures to make sure they don't forge what you said. But what if they deny you access and ignore your messages? What if they change the order people said things? A merkle tree can't protect you from this.
- You need to agree with other people in what order certain things happened, this is a hard problem in networks / distributed systems. Especially if you have actors trying to manipulate this very thing.
- You need to align incentives in a way that breaking the complete system is infeasible from a financial point of view.
----
Take Bitcoin as an example, a (kind of) anonymous payment system in the internet, the only things protecting everyone's money are public/private cryptography and the costs involved with rewriting history (51% attack). Bad actors attack it every day, but no matter who's door the police kicks in you only have to trust cryptography (the only other weak link is your personal private key, so if you they hit in your door - but there is no other middlemen).
> I just don't get the hype.
There is a ton of hype, and whether it's valid or not depends on if the world needs such a system. Blockchain proponents say that once you have a stable decentralized system that can run any code and cannot be corrupted in any way, you will see innovation flourishing similar to the internet: the internet brought complete freedom of information (and industries build on top were not imaginable in the 80s), some people think the blockchain will bring freedom to anything that is (or should be) scarce. Like money and commodities.
If you’re arguing for the latter, then try to explain to me as simply as possible how a blockchain with “proof of authority” is better to Git with signed commits. Or CT. Or Keybase. It seems that these business blockchains are inefficient, append-only Merkle trees. It’s not particularly novel, and replicating the database across all nodes of the network and constantly engaging on a consensus protocol to agree on the state of the network while all peers are trusted anyway with proof of authority seems quite useless.
If I am wrong, then the blockchain people can do themselves a favour and make a simple comparison chart of their solution compared to possible alternatives. But I don’t think they want to do thst. I think they baffle non-technical people with words like “decentralised”, and “cryptographic signature” and polish it nicely until people believe in them. Just try reading Alex Tapscott’s book “The blockchain revolution”. I think it is snake oil. The emperor’s new blockchain.
I just went on explaining why you want to use a blockchain (private or not) instead of git. It's a broad question so you'll get a broad answer. This is the only thing I went into:
> Exercise for the blockchain advocates: explain as simply as possible why a “private blockchain” is better than Git.
I haven't talked about anything else. If you want to know what people think about using blockchains for A and B, you should ask that instead. My target hasn't moved at all.
> try to explain to me as simply as possible how a blockchain with “proof of authority” is better to Git with signed commits.
I specifically explained where an append-only merkle tree doesn't cut it in the comment you just replied to (my previous one). Note that git is an append-only merkle tree. You are more than welcome to go into my points.
> It’s not particularly novel, and replicating the database across all nodes of the network and constantly engaging on a consensus protocol to agree on the state of the network while all peers are trusted anyway with proof of authority seems quite useless.
If all peers are completely trusted you are 100% correct, if you trust everyone completely you don't need a blockchain. However in the real world trust isn't binary. If a bunch of banks KYC each other and go into a blockchain consortium, they do this specifically because they don't trust each other enough. Else they would have gone with a straight forward solution like git a decade ago.
Anyways, perhaps a better exercise to clarify would be: Find a single example where a (precisely defined) type of blockchain makes sense vs possible alternatives such as solutions along the lines of Git, CT, etc. I conjecture that there are none beyond cryptocurrency.
I never said they were the same, however the similarity is that they are both blockchain systems. And you cannot achieve the same with git for exactly the same reason (you cna't trust all parties).
> Or are you suggesting proof of work or something?
Nope, definitely not. Not sure what made you think that?
> Find a single example where a (precisely defined) type of blockchain makes sense vs possible alternatives such as solutions along the lines of Git, CT, etc. I conjecture that there are none beyond cryptocurrency.
There are loads all over commodity trade finance and supply chain (the field I have experience). But I've spend an hour typing an answer out your initial question:
> Exercise for the blockchain advocates: explain as simply as possible why a “private blockchain” is better than Git.
And now you state you aren't really interested in that explanation and want to have clarification on something completely different.
I'm done with typing out "examples and clarifications" when as soon as I do you start asking a different question, never going into my points. So "I am exiting out of this conversation :-)"
You made me think you might be suggesting some proof of work scheme instead of "proof of authority" because the example you chose was bitcoin. You also said: "You need to align incentives in a way that breaking the complete system is infeasible from a financial point of view.". So that's why I thought of it. Apologies if I was mistaken.
I don't quite understand why this conversation is getting heated for you. Perhaps because it is your career so you feel personally attacked or something. That's not my intention. Anyways, I'm still none the wiser as to why to use a "private blockchain". Blocking commits or whatever isn't really solved by a private blockchain. You don't need a blockchain for the problem of changing the order people said things either. And how many banking consortia were really moaning about these issues before a blockchain came along? A blockchain seems like a solution looking for a problem most of the time.
Comments like this:
> Blockchain proponents say that once you have a stable decentralized system that can run any code and cannot be corrupted in any way, you will see innovation flourishing similar to the internet: the internet brought complete freedom of information (and industries build on top were not imaginable in the 80s), some people think the blockchain will bring freedom to anything that is (or should be) scarce. Like money and commodities.
Comparing blockchain to the internet? I think that is just crazy la la land. I really hope I'm wrong because that sounds amazing. (Although I have no idea what "that" is, but the internet was a good thing and I like good things.) But I'm definitely not.
But anyways I agree with you that we should stop.
I'm totally fine, hope you are too. I don't feel personally attacked at all. But on the internet a thick skin is required. I hope you don't feel attacked either.
> Anyways, I'm still none the wiser as to why to use a "private blockchain" but I agree with you that we should stop.
That's unfortunate, I hope you do understand one day. I won't go into it now since you started with a different question (or technically an exercise). And after my lengthy attempt in explaining it you expressed that you don't actually care and instead ask questions about consensus algorithms used in different blockchains (like PoW and PoA) - which has nothing to do with why one uses a blockchain and not git.
So please next time if you are interested in something, don't start by asking something else. After that trying to steer the conversation towards your hidden objective all while you are accusing the other side of "moving the target" (you are moving the target from git towards consensus algorithms and blockchain use cases).
Though I believe the deciding factors aren't very technical. For public projects it all depends on what people want (in reaction to government control, surveillance, financial and capital controls)
And for private blockchains in my experience (in finance anyway) it all depends on the regulators and what they will allow. They are also reacting to whatever is happening in the world.
Currently it all looks pretty bleak indeed.
Git is a blockchain, and sometimes a private one.
1. Satoshi comes up with this clever blockchain thing with proof of work and hashing and append-only characteristics. It solves a very specific problem.
2. It involves money and new tech so business people get on the bandwagon and tell the boffins to investigate.
3. There's a lot of hype and good publicity for it (e.g. KodakCoin, Long Island Iced Tea Blockchain)
4. The technology as Satoshi defines it is actually pretty useless for their application. So they bend the definition slightly. Blockchain becomes Git or something with a signature or hashing or even a Merkle Tree.
5. Git etc is actually useful sometimes. The blockchain prophecy is complete. The business people are happy. The boffins don't do anything really, but everyone gets paid so nobody really cares.
Context from referred Nakamoto pdf: In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions
So this is not definition of blockchain by Nakamoto (There is no term blockchain at all in this pdf)
Definition from wikipedia (I agree with): A blockchain is a growing list of records, called blocks, which are linked using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data (generally represented as a merkle tree root hash)
From this definition git is also kind of blockchain.
So its hard to follow article with such vague definition from start.
> chain of hash-based proof-of-work
and
> chain of blocks
in this paper. His later communication does call this "block chain".
So you are right that he/them/she does not use the term "blockchain" in the paper. Nor "block chain" but the term can be extracted from there clearly.
This thing, however, exists only for the purpose of solving decentralized trust problem and cannot be secure without a popular public cryptocurrency. Hence private blockchain is a fallacy. If trust relies on authority it's just a weird database, not a "private" blockchain.
It's similar to how people were annoyed with the commons clause added to an open source license being associated with the same old unrestricted license, that in fact became a completely different license.
This is the approach the erstwhile InterPlanetary database was planning to take. IPDB shut down earlier this year. Some of us really wanted this so we're setting up an Ethereum-compatible, permissioned+public blockchain called Indium.Network: https://indium.network/
If it is permissioned, does that not essentially mean its write-side is "private"?
What can an observer now do in case the whitelisted entities decide to change history, other than tweeting about it? I'd argue that if the observer now has power to eject the rogue entity/ies from their power, it is a public system. Just via a separate layer.
And if it is permissioned, does that not automatically mean it is centralized?
Not parent, but yes.
>And if it is permissioned, does that not automatically mean it is centralized?
That depends on your definition of centralized: if you mean "under the control of humans" then yes it does. If you mean "under the control of one human" than no it doesn't.
For example a common approach is to designate a set of institutions (e.g. not for profit foundations in several different countries) to be in control of the validating nodes. Under that model a quorum of those institutions would need to be subverted in order to censor transactions.
So I guess that means certificate transparency is a "blockchain"?
He then quotes a "more accessible" definition that explicitly precludes private blockchains. So fine, if you define blockchain as being open then, sure, it can't be private.
He then has a flowchart that doesn't refer to either definition and follows that with a set of reasons why people want a private blockchain and refutes them. Two of these are fine: private data and access control. Two of these are just plain strawmen: scaling and confidence.
And of the 2 reasons that do make sense he makes clearly incorrect statements:
> A blockchain has to be public in order to ensure permanence or immutability.
No it doesn't. A restricted group of people can use identically the same features that a public blockchain has to manage eventual immutability. If that weren't true then it would imply that, say, the Bitcoin blockchain would not have it's current immutability properties if only its current users could access it. But that's simply not true.
> A blockchain has to be permissionless in order to ensure permanence.
Again, no it doesn't. Just because you restrict who writes to the end of the chain says nothing about the rest of the chain.
Now, it would be a reasonable argument to say that the useful properties of a blockchain are only available to people who have read access to the whole blockchain. And I'd agree with that. But he's not making that argument, as far as I can see, so his actual argument is either tautological or verifiably wrong.
Interesting point. But I think this evolves around what makes "private" and what not. Is a network of ~10.000 anonymous nodes "private" if you now close it? I guess it would be called "permissioned" and not "private".
Further, my point is that when you would close the current network and disallow anyone to write and read from it, other than the currently online ~10.000 nodes, disallow new wallets and participants (making it private) you'd loose three things, essentially rendering the blockchain unusable: breaking it's immutability:
* There would be no new miners.
* There will be no increase in usabiltity: no future gain.
These two things will logically cause centralisation of the existing mining. After all: no new miners can join, and only miners can drop out.
A typical "private blockchain" so not one that started out public, grew large and then turned private, but one that starts out private, therefore has no need for PoW at all: it makes no sense, and adds no security that is not already there (through enforcements of access controls). Hence either the PoW is just nonense and (even more so) a waste of energy. Or it is left out.
And a blockchain without a PoW is just a DAG tree. Or cryptographically signed logbook.
Which can be useful in itself. But which is not a blockchain.
In such scenarios, the role of block producer is centralised and limited to the owner of the private chain which means a less power-hungry consensus mechanism such as Proof of Authority can be used and have block interval times in the milliseconds.
A project I've worked on recently aimed at delivering a similar solution in a global company that has historically grown through acquisitions and mergers where the IT systems never fully integrated, meaning that despite operating under the same name, there are hundreds of BUs that don't "trust" each other.
* Permissionless Blockchain
* Public Permissioned Blockchain
* Private Permissioned Blockchain
However, the article describes a lot of examples that are clearly not blockchains, but cryptographic interesting solutions like a ledger that gets distributed amongst all observers. It even often concludes that "this is not a blockchain". But then goes on to call it "blockchain solutions like this".
If the paper would stop abusing the word "blockchain" for "anything with cryptography", and instead use more precise terms, it would be a very good paper. And it would underwrite what I am trying to say:
There's loads of interesting data-structures to solve many interesting problems that industries have. Lets' call them what they are instead: DHTs, DAGs, Merkle Trees, Pub/Sub buses, etc.
"A distributed ledger (also called a shared ledger, or distributed ledger technology, DLT) is a consensus of replicated, shared, and synchronized digital data geographically spread across multiple sites, countries, or institutions." [1]
[1] https://assets.publishing.service.gov.uk/government/uploads/...
Nowhere in my article did I say that "private distributed ledgers" are nonsense (allthough, writing it down gives me cringes).
But the whoe focus on "terminlogy" is in my article for pricesly this reason. I am not talking about how it is silly to have your excel sheet shared amongts a predefined set of participants using fancy bittorrent-streams (a distributed ledger).
But that a blockchain being private is nonsense.
And allthough your average marketing department might hate to hear it, but your distributed ledger is quite certainly not a blockchain.
- Control read / write - A list of companies in a consortium might like to maintain shared settlement resources but don't trust a single party for consensus. A private ledger offers a genuine improvement in security over other technologies during a breach. I.e. imagine if there are machines being controlled by authorized humans working with contracts on the private ledger. Hacking a few servers there isn't going to compromise the contracts which is really cool.
- Scale better (scrap the distributed part) - Some of the newer ledgers are doing exactly that. When you cut node count it does reduce decentralization but the trade-offs are on a gradient. Again, not necessarily an incorrect choice. Look at something like Ricardian contracts on Corda for settling bank deals. The actual "settlement" isn't done on the ledger at all. All that occurs on Corda is a beautiful way to craft financial contracts that will be easier to audit by regulators. Private ledgers all help with that and would benefit from not using an entire flooding-based p2p network to do it.
- So we can store private data - There are many companies and institutions that need to store private data. One can imagine advertising companies sharing demographics or hospitals sharing medical records. There's nothing novel here about acting as a database. What the author fails to grasp are some of the more subtle aspects of distributed ledgers. Like the more nuanced trust relationships between companies or business requirements (upgrading old technology, sharing the costs, incentivized standardization.)
Caveat: distributed ledgers are not blockchains. But my problem with this article is the blockchain fanaticism mixed with the authors seeming inability to think outside of black and white terms. He dismisses everything about enterprise ledger technology that doesn't fit in his narrow definitions and can't see any of the nuances of using them. The result is a person who fails to understand either public blockchains or private ledgers very well (like most people it seems.)
Author here. Thanks for your criticism.
I think you are making my point too. And you do touch on the reason why I focused so heavily on the "terminology part".
What irritates me, is that anything "crypto" is suddenly called "blockchain". Signing transactions and including a pointer to a predecessor is not a blockchain, it's a DAG and we use it daily (git).
"Distributing your data" maybe even using merkle trees, is not a blockchain. Its "distribution". An interesting and broad subject in itself. Distributing a ledger is hardly new, though still a field very much in motion.
All the things you describe are really very interesting fields often tremendously complex.
They all usepieces of tech found in a blockchain too. But then again: the whole basis of bitcoin is really just a combination of existing tech put together in a novel architecture.
Many of the things you describe (like distributed ledgers) require quite novel concepts and most of all leaning heavily on cryptography. But none are "blockchain".
Because there are no trees.
The hashing used in BitTorrent metainfo files works by splitting the concatenation of all constituent files into equally sized blocks, individually hashing each block (using SHA1), and concatenating the hashes. Paths and sizes for all the files are also stored, but separately from the hashes.
It seems reasonable for three companies to create a block chain only they see. It is public, in a sense, because the transactions span different trust domains. It is not public because it is not on the open internet like Bitcoin.
Multi company blockchains are the primary use I know of the term 'private blockchains'.
I don't see anything in this paper which argues against this...
PoS (or PoW) are not needed because there is no sybil attack nor a byzantine-general problem to be solved. In fact, most "Private Blockchains" ditch the PoW and therefore can claim "tremendous scaling" or things like that.
Ditching the PoW solves most of the scaling issues. Sure.
But a blockchain without a PoW is simply a log that is cryptographically signed (but not secured). Because I could very easily just change block #2 and simply accept the cascading effect. People familiar with Git use this principle every day. A git --amend and git push --force is exactly this.
Once you can convince the participants in your private network (your colleagues) to use your branch, history has been rewritten. (And the old work is just one garbage-collection away from being forgotten forever).
So, yes, it is very much a definition question. But that is because "a blockchain" has it's requirements and its pro's and cons built into that definition. So if you start stretching the definition, you simply loose requirements. And you end up with something that really makes no sense.
In that case, each company is trusted to at least be authoritative for their entities and to be trusted to the extent that their identities are known and they may be held accountable.
In that situation, an append-only log with merkle-tree-like crypto could handle the situation just fine.
The key thing that isn't needed there is proof of work; participants do not need to be "rate limited" and, if a conflict arises, they can all be trusted to, say, arbitrarily pick the item with the lowest sequence number rather than needing a proof of work system.
In what situations do you think a private blockchain is warranted and specifically why is proof of work necessary in that scenario?
They have it built in based on picking the chain which the most work has gone into.
Arbitrarily assigning a number to a transaction and having everyone to agree to pick the smallest in the case of conflict is easier and works fine if your members are all trusted to not maliciously abuse that facet of the code.
Proof of work is throwing away resources to solve a problem you don't have if no one is crafting malicious transactions.
This would be like a traditional eventually consistent distributed database (using total order to resolve conflicts).
And we might ask "why did those deploying private blockchains not just use that kind of thing?".
I'm not sure, but potential reasons are:
1. That kind of thing doesn't actually exist in a form that they can easily use, so they re-purposed existing, reasonably proven blockchain technology to achieve an equivalent functionality.
2. The parties don't completely trust each other so in fact malicious transactions can be crafted.
3. They don't trust their software to not craft malicious trasnsactions and the blockchain provides a neat way to filter them out.
4. Blockchain is very hyped right now and they want to show that they are hip and cool by keeping up with the latest trends.
And to protect against sybils that cannot exist by nature of being private. Or to protect against Byzantine nodes that cannot exist by the nature of being private.
This fallacy the same thing that happened for the word "Disrupt"/"Disruption"/"Disruptive Technology". Even Clay Christensen, the creator of the phrase, says most people misuse the phrase "disruption" when compared to his explanation in the Innovators Dilemma[1]. There are Tons[2] of[3] people[3] complaining that the term is misused. In the end, if you casually tell someone you've got an idea for a Taco Food truck that's going to disrupt the food truck industry, people will know what you mean.
The definition of this word "blockchain" is being misused so much that it is changing faster real eduction can help. I think posts like this are great if you're technical, but as I said above — It doesn't matter what the fallacy is.
[1] - https://www.amazon.com/Innovators-Dilemma-Revolutionary-Chan...
[2] - https://techcrunch.com/2013/02/16/the-truth-about-disruption...
[3] - https://www.forbes.com/sites/vukivujasinovic/2017/03/02/its-...
[4] - https://www.newyorker.com/magazine/2014/06/23/the-disruption...
The counterargument to "words mean what people agree they mean" is that "to computers, instructions mean what they have already been defined to mean". If you change Python's meanings, you need to tell everybody that you're using Python 3.5-Joe, not Python 3.5.
Clearly true, but in this field "private" is really being used to denote "not a Public Blockchain like Bitcoin and Ethereum".
It doesn't mean "actually private". It means "we built our own rather than pay to use Ethereum".
Private really means what you think it is "a blockchain that only a small selected group can access". A lot of "Private blockchains" are just Ethereum-nodes running behind a firewall and with a secret genesis-block.
It does not, however, mean that it cannot be peer-reviewed. Allthough that still leaves the problem of not knowing if what you've reviewed is what is running.