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.
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.
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.
More broadly, I think that the article misses the point of private blockchains when it discusses them:
> 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).
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.
First, some additional benchmarks:
* Juno (w/ hardcoded language): 500 tx/s
* TendermintBFT w/ EVM: 1k tx/s
* ScalableBFT w/ Pact: 8k tx/s
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.
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.
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.
More broadly, I think that the article misses the point of private blockchains when it discusses them:
> 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).
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.
I have a longer comment about it here: https://news.ycombinator.com/item?id=14853521