>> From a trust perspective, it makes no difference if your banking cartel is writing to a Quorum, Hyperledger, or Kafka instance.
> Of course it does. The protocol of blockchains makes them work with "proof of X". Appending to any event store, whether in Kafka or SQL does not require proof of anything.
The author should have qualified that from a user's perspective, it makes no difference. If my bank decided to store its users' transactions on a proof of work database, I wouldn't even know. Which is the author's point: it makes no difference from a trust perspective, I'm still trusting the bank to store and settle my transaction either way.
It's not proof of work by itself that makes something like Bitcoin trustless (again, from the user's perspective). It's the fact that both the proof of work and blocks are public and verifiable, thus I can validate the blockchain and make sure the miners are doing the work correctly (my transactions are there and the proof of work is valid). Proof of work without making the database public and audit-able by users is pointless. But if it is public and it's shown that the miners are not settling transactions as they should, then users can fork or move to a blockchain that doesn't censor transactions.
>> If you’re not looking at the public chain, you’re wasting your time
> I disagree. Not having a single point of failure (one place that can get hacked) is valuable.
I.e. if your chain isn't public there are benefits to using it.
If you suddenly say the same benefits can be obtained with kafka or a relational database, you will be introducing proof of something... Which means you'll now have a blockchain / distributed system based on a relational database. Which comes with the limitations imposed by the CAP theorem.
The most popular version of event sourcing produces such a high throughput, because immediate consistency is sacrificed. I'd like to see what the author proposes in a production system. Global rules would not be enforceable (e.g. no balance under zero), unless throughput is sacrificed to allow for immediate consistency.
> Of course it does. The protocol of blockchains makes them work with "proof of X". Appending to any event store, whether in Kafka or SQL does not require proof of anything.
The author should have qualified that from a user's perspective, it makes no difference. If my bank decided to store its users' transactions on a proof of work database, I wouldn't even know. Which is the author's point: it makes no difference from a trust perspective, I'm still trusting the bank to store and settle my transaction either way.
It's not proof of work by itself that makes something like Bitcoin trustless (again, from the user's perspective). It's the fact that both the proof of work and blocks are public and verifiable, thus I can validate the blockchain and make sure the miners are doing the work correctly (my transactions are there and the proof of work is valid). Proof of work without making the database public and audit-able by users is pointless. But if it is public and it's shown that the miners are not settling transactions as they should, then users can fork or move to a blockchain that doesn't censor transactions.