[deleted]
Scaling Blockchains with Apache Kafka
11–15 of 15 posts
Re: Scaling Blockchains with Apache Kafka
#12> If you aren’t familiar with the database pattern known as event sourcing (don’t worry — it’s relatively new), It's not relatively new. That “transaction file” thing in your database? Event Sourcing. https://goodenoughsoftware.net/2012/03/02/case-studies/ > 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.…
>> 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.
Re: Scaling Blockchains with Apache Kafka
#13> If you aren’t familiar with the database pattern known as event sourcing (don’t worry — it’s relatively new), It's not relatively new. That “transaction file” thing in your database? Event Sourcing. https://goodenoughsoftware.net/2012/03/02/case-studies/ > 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.…
>> 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 stor…
May I refer you back to
>> 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.
Re: Scaling Blockchains with Apache Kafka
#14> If you aren’t familiar with the database pattern known as event sourcing (don’t worry — it’s relatively new), It's not relatively new. That “transaction file” thing in your database? Event Sourcing. https://goodenoughsoftware.net/2012/03/02/case-studies/ > 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.…
> good old CAP theorem.
Sat in on a candidate interview recently whereby I heard the news that the blockchain "invalidates CAP". Not sure if it will also cure cancer.
Re: Scaling Blockchains with Apache Kafka
#15Earlier quoted context omitted.
Yes, event sourcing is just a loosely defined pattern. It does make tamper proofing a bit easier due to its log like nature. I know some systems do use physically "append-only" storage.
Do you have any more info on these RO storage systems? What springs to mind is... tape?!
There's some info here:
https://en.wikipedia.org/wiki/Write_once_read_many#Current_W...