> If you aren’t familiar with the database pattern known as event sourcing (don’t worry — it’s relatively new),<p>It's not relatively new. That “transaction file” thing in your database? Event Sourcing.<p><a href="https://goodenoughsoftware.net/2012/03/02/case-studies/" rel="nofollow">https://goodenoughsoftware.net/2012/03/02/case-studies/</a><p>> If you’re not looking at the public chain, you’re wasting your time<p>I disagree. Not having a single point of failure (one place that can get hacked) is valuable.<p>> From a trust perspective, it makes no difference if your banking cartel is writing to a Quorum, Hyperledger, or Kafka instance.<p>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.<p>> Blockchains are built for trust, databases for throughput. Event sourcing allows us to achieve a hybrid model with characteristics of both.<p>No, the reason blockchains can't have high throughpout / almost infinite horizontal scalability... is because there's a logic check. E.g. in bitcoin, you can't send more bitcoins than you have a balance. Event sourcing gives you the high throughpout if there's no logic checks across aggregates --- if there are, you won't have immediate consistency, and you have to be ready for compensating events.<p>I recommend two books, that cover event sourcing from a Domain Driven Design perspective. The consequences are similar.<p><a href="https://www.amazon.co.uk/Domain-driven-Design-Tackling-Complexity-Software/dp/0321125215" rel="nofollow">https://www.amazon.co.uk/Domain-driven-Design-Tackling-Compl...</a>
<a href="https://www.amazon.co.uk/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577" rel="nofollow">https://www.amazon.co.uk/Implementing-Domain-Driven-Design-V...</a><p>-----------------<p>If that doesn't do it for you, please just remember the good old CAP theorem.<p><a href="https://en.wikipedia.org/wiki/CAP_theorem" rel="nofollow">https://en.wikipedia.org/wiki/CAP_theorem</a>
Preface: lead for Juno & ScalableBFT<p>First, some additional benchmarks:<p>* Juno (w/ hardcoded language): 500 tx/s<p>* TendermintBFT w/ EVM: 1k tx/s<p>* ScalableBFT w/ Pact: 8k tx/s<p>The thing about the high-performance private blockchains is that they are limited by the sequential smart contract execution performance. Juno ran an embedded "rough draft of a langauge" do it doesn't really count (not a full language, more like a complicated hardcoded counter). From TendermintBFT's docs, if memory serves, they say that if you hardcode a counter they hit +10k/s. For ScalabeBFT, it's it's ~14k/s. This is a minor difference, by the way, that isn't due to the consensus mechanism but more to the engineering of the system.<p>The reason for the non-hardcoded performance difference is that ScalableBFT runs Pact for smart contracts, which was designed to be a high performance interpreted language in part because of this bottleneck. Even if/when the EVM moves to WASM, the performance bump only impacts fat contracts by making them kill performance less. As in, if your 10k-step contract takes 200ms to execute and that drops to 2ms you can get 100x perf (not quite but it's fine)... but that only takes you from 5/s to 500/s and not to 1k/s or 8k/s.<p>The numbers above are for a simple coin transfer contract so the performance is mostly dependant on the read/write performance for keys in the DB. There's just not much contract level work to do when you're transferring coins between accounts so the WASM move won't bump things up much if any.<p>More broadly, I think that the article misses the point of private blockchains when it discusses them:<p>> I would discourage you from blockchain consortia if your intention is to never use the public chain and if you don’t care about Ethereum. I’m going to put it bluntly: if you’re not looking at the public chain, you’re wasting your time. The benchmarking numbers paint a pretty obvious story — Quorum will never give you the speed of Kafka, especially since blockchains get less efficient as more participants join (because of that pesky “consensus” thing).<p>They serve a specific purpose: being a multi-administrative DB. Distributed DB systems (like Kafka, raft-based systems, etc.) can't robustly/safely serve that end.<p>I have a longer comment about it here: <a href="https://news.ycombinator.com/item?id=14853521" rel="nofollow">https://news.ycombinator.com/item?id=14853521</a>
> If used correctly, it is tamper-proof, just like the blockchain<p>Is tamper proofing typically a feature of event sourcing systems? If so, how is it implemented?