Just because it doesn't fit into your contrarian view on
consensus it doesn't mean it doesn't provide consensus.
Nakamoto consensus solves the Byzantine problem quite well.
The list of transactions doesn't not constantly change? Are you saying there is no consensus as to the value of the first blocks?
I get that it's cool to be contrarian and it makes people feel smart to badmouth blockchain. But Nakamoto consensus does reach a consensus on value that is accepted by the network.
It's like saying a voting election didn't matter because certain people didn't participate.
The established value of the consensus is the transactions contained within the block. It's established because it's what the network accepted, regardless of individual node states.
That's the point, one should not have to consider the values of other nodes to reach consensus. If the network agrees on something, that's consensus. If a certain node doesn't, that's their problem.
It's agreed because that miner solved the block problem first. If you have a different view, you must fix it. This is how it achieves consensus.
Not sure what specific consensus problem Nakamoto consensus doesn't solve, but it does provide a consensus based on the specific rules of the network. So yes, it's a consensus system. You might want to be contrarian and dispute what consensus means to you. But that's what it means to to the miners and that's what matters.
What? There is consensus on the public blockchain every few seconds + block depth. It's called Nakamoto consensus, so yes blockchain 'solves' the problem.
In smaller chains, there can certainly be consensus, it just won't be as trusted as a public chain and 51% attacks are potentially more feasible due to it having a smaller economic barrier.
Totally, solving that issue is the most challenging thing. A middle ground could be democratized voting where users can vote to keep or remove messages.
I think this is the antithesis of the blockchain. I think a much better idea is: "Uncensorable Twitter".
With how much twitter and Google censor users they find offensive I think a product like that would take off and not be too difficult to build.
Looks very interesting, have you looked at H2O.ai which spits out a classifiers as Java code which can be wrapped in an ultra low latency API without caching.
This is great advice. I'd add that the culture around data engineering projects tend to be very different.
I've seen companies that treat data projects as if they were this great unknown projects where the developers could get away with using bad or no patterns and not follow patterns that other applications in the company use.
Technologies like Spark have made more common and easier to develop big data applications and implement design patterns that regular engineers can understand and follow.
Couple a great data engineer that with great data scientist using tools like Spark, R, H2O, Alluxio, Parquet, etc. and companies can truly exploit their large sets of data effectively.
The problem is DevOps and bridging the gap between a scientist's environment and a production environment and keeping both as flexible and testable as possible.
We started a company to bootstrap companies into this culture by providing DevOps services and UIs which simplify the deployment of Kubernets, Spark, Druid, H2O, etc. clusters. We also provide tools and services for simplifying and automating ETL pipelines with which models can be trained.
If you are interested in finding out more about these services contact us at: [email protected].
Because "it might fork" that's why it's not a consensus? lol, ok buddy.