I've worked on private blockchain solutions for financial firms (in supply chain and commodity trade finance). The reason companies are doing these projects is because in a lot of scenarios no one trusts each other. Even if they do, there are not allowed to for legal and compliance reasons. As such huge parts of the industry are paper based. Because if there was a simple MySQL solution from a company they would have gone with that 2 decades ago.
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.
There are a lot of issues with your thinking. I will just start with a few ones.
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.
> 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.
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.
> I don't know any private blockchains that have apps running on smartphones
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 am not inventing anything new here, just exposing the claim vs. the reality.
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 you said you worked on proof of concepts, not production ready products. Show me a production ready product and I can show you how you can do the same without a blockchain.
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 recognized if you have a private contracts agreeing on recognizing them.
> 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.
> Pulling things out of context eh ;) It's unfortunate you're not aware of any production ready private blockchain solutions. Maybe keep that in mind before you start with your next discussion.
Correction: I am not aware of any production ready private blockchain that cannot be replaced by another technology not using blockchain.
> Woah your e-penis is indeed very long! I am impressed!
It seems you don't know how to talk here in HN. You started your thread saying "I've worked on private blockchain solutions for financial firms" then there are many of your comments where you are showing some level of experience. I am showing my level of experience in the business like you.
> You started your thread saying "I've worked on private blockchain solutions for financial firms"
Yes: I stated "I work in this field, this is what I see around me at companies that are doing private blockchains. I haven't heard these arguments around me before."
While your approach is: "Here is my resume, now I demand you to give me examples so I can prove my point."
> Correction: I am not aware of any production ready private blockchain that cannot be replaced by another technology not using blockchain.
Ah great! Since your argument is that they can all be replaced, can you name a private blockchain solution that IS running in production that can be replaced?
While you are at it:
> Digital contracts are recognized if you have a private contracts agreeing on recognizing them.
IANAL but AFAIK this is completely false. Do you have any examples of smart contracts running on blockchains being enforced in a court?
> While your approach is: "Here is my resume, now I demand you to give me examples so I can prove my point."
I already probed my point beyond what I said afterwards. You just need existing cryptography and don't need a blockchain to make secure agreements between parties.
> Ah great! Since your argument is that they can all be replaced, can you name a private blockchain solution that IS running in production that can be replaced?
I don't need to since I am arguing about the no sense of private blockchains.
> IANAL but AFAIK this is completely false. Do you have any examples of smart contracts running on blockchains being enforced in a court?
If the smart contract uses digital signatures they are enforced by the existing law.
Also, as you probably know, this field is very new and the law was not, in general, involved with this kind of technologies.
They might not trust each others but if they know each others, why can’t they simply use a public private key solution? For a transaction to be valid it needs to have been signed by both parties.
They can and do. What's most useful about blockchain tech is the eventually immutable chronological ordering bit.
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.
> They can and do. What's most useful about blockchain tech is the eventually immutable chronological ordering bit.
> 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.
> This was the missing building block that was necessary to build a decentral cryptocurrency.
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.
> 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).
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:
DigiCash lacked the novel, decentralized proof of work consensus introduced by Bitcoin and I also suspect the general public was much better able to participate with 2008 broadband than what we had 1998
Very true, in my experience talking with lawyers is that blockchains are still very far away from having any type of legal meaning: if there is a problem down the line you can't refer to the blockchain in a lawsuit (IANAL).
This seems a little hard to believe given that in today's lawsuits the parties are often referring to emails. What's the fundamental difference between an email and a txn in a block?
In my understanding you can definitely point to some tx and say that has something to do with the other party. But if there is a "contract" between two companies, like company A should give this in these circumstances to company B. If there is then a dispute about these circumstances, it matters whether the contract was on paper with actual signatures (a document designed to be able to be enforced by law) or a "smart contract" on a blockchain system somewhere. In case of the latter you cannot say "I want my money because the contract says so" if the contract only exists as a smart contract on a blockchain. If it's on paper the decision might be based on the actual wording (in English or another language) - this is all very hard when you're dealing with a programming language (or set of instructions).
If you read the definition of blockchain by Nakamoto in the post, the most important point of a blockchain is to provably keep track of the order of the transactions. That is not so easy to achieve with just a public key infrastructure. Actually, timestamping is a very difficult problem and bitcoin solved it.
For compliance and privacy reasons. For example I deal with a lot of Swiss banks and Swiss law is very strict about what kind of data is allowed to leave Switzerland (not very much).
Is it privacy as in no one must be aware that this particular party signed a contract?
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.
I'm not sure that @askmike uses PoW in his project(s). It sounds like if the companies know each other and can form consensus, they don't need PoW to form consensus.
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.
You probably need chronological ordering as well, and to broadcast transactions to all stakeholders, and tools to interact with and verify the structure, and to not roll your own crypto - all of which are provided by following the "blockchain" standard.
> Otherwise the public/private key could also be used for the encryption of the contract.
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..
If you don't mind asking, what kind of actual use cases do you see in the supply chain environment for blockchain? I would assume the financa part would be more suitable, but up to now I didn't find a use case where I personally see the benefit. As I assume I might miss something it would be great to hear your opinion on it.
As an example, food safety in the developing world. Food firms claim food is fresh and came from places where it did not come from. If you introduce an agricultural and food tagging system that logs food item IDs into a blockchain-based system, you can know when and where food was made and grown.
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.
You don't take the data at face value. The goal of these systems is to reduce human intervention, not to remove the intervention. If a firm fakes data, you still have proof in the bad products and customer complaints. This lets you investigate and file complaints on the public blockchain. Think of it like a review of a company's supply chain reliability.
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.
They can always print fake labels, but they can't deliver fake products too many times. Customers will realize that fraud is happening. Again, there are also ways to make labels that cannot be faked, then attach those labels to tamper-proof packaging. It helps to realize that these labels and packaging exist so that the food items can be scanned and tracked as they enter and leave different facilities along the supply chain.
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.
Hard to say for me, because the obstacles and problems in these projects are always legal and business. I'm just an engineer ;)
> 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.
Thanks for the quick answer! So it would be fair to say to get rid of the paper work by making it digital and using blockchain to reduce the fraud risk?
Anyway, I'm really curious to see what people come up with! And yes, being faster and cheaper is summing up logisitcs pretty well! ;-)
> So it would be fair to say to get rid of the paper work by making it digital and using blockchain to reduce the fraud risk?
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.
I'm only involved with proof of concepts, as such I usually work with pre made blockchain solutions with smart contracts slapped on top.
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:
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.