zero-x
Because "it might fork" that's why it's not a consensus? lol, ok buddy.
True there are other types of consensus that are perhaps 'fairer' but that's not the issue here.
So yes, it is a consensus protocol. It's called Nakamoto consensus, and it's perfectly fine for its purpose.
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.
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.
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.
Why the Blockchain Needs to Be Used for Ad Standards
That's kinda the whole point, watch it all burn and interact with people at the rawest level.
Introducing Shaman, a low-cost platform for high-frequency real-time analytics
Show HN: Shaman, Self-Serve, Cloud Hosted Apached Druid
Programmatic Conversion Funnels with Apache Druid
Programmatic Conversion Funnels with Apache Druid
Real-Time Programmatic Advertising Visualization
Interactive Bid Requests with Apache Druid
Test Driven Development with Apache Spark
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].