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.
> What? There is consensus on the public blockchain every few seconds + block depth. It's called Nakamoto consensus, so yes blockchain 'solves' the problem.
It's a name used for Bitcoin's protocol. It doesn't mean it's consensus.
How does the established value by this "consensus" protocol look like? And why
do you consider it established, when other participants can have a totally
different view of the list of documents in the protocol, or your view can
change completely with next message? How is it an agreed value? And at what
point should we look at the views of two different participants to see the
same value?
And how does it relate to Lamport's original publication about the consensus
problem?
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.
> The established value of the consensus is the transactions contained within the block.
Which of them? Because every node has a slightly different view and doesn't
know how it differs from anybody else's view.
> 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.
The problem is that every node has slightly different view. You can't tell
"this is the agreed value", because no particular node has this value as its
state. Yet somehow it emerges as network's agreed value? By what means
(algorithm) anybody can take a list of transactions and say "this is the
network's agreed value"?
Not to mention that the list of transactions constantly changes, you didn't
address the problem that agreed value requires the protocol to terminate
first.
> 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.
In what way is "solve block problem" consensus?
> Not sure what specific consensus problem Nakamoto consensus doesn't solve,
Yes, this is typical problem with blockchain enthusiasts. They're usually too
uneducated and don't know the fundamentals, like the definition of consensus
problem. I pointed you to Byzantine generals paper already, it should have
been easy to find even with just "consensus problem Lamport" keywords.
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.
> Just because it doesn't fit into your contrarian view on consensus it doesn't mean it doesn't provide consensus.
You do realize that this "my contrarian view" is what computer science calls
"the consensus problem", right? And that "my contrarian view" comes from
a highly regarded publication that's thirty years old?
> Nakamoto consensus solves the Byzantine problem quite well.
Explain to me how. Byzantine generals problem comes with a rigorous proof
that network cannot agree on a single value if the cooperating nodes don't
outnumber the adversarial ones by more than 2:1. The blockchain guarantees its
functions with merely 50% + 1 of cooperating nodes. Something doesn't add up
if blockchain was intended to solve consensus problem.
> I get that it's cool to be contrarian and it makes people feel smart to badmouth blockchain.
Oh, but I don't badmouth blockchain. I think it's quite ingenious
cryptosystem. I only badmouth blockchain enthusiasts, and the undereducated
ones at that.
Blockchain was never intended to be a consensus protocol, it was always
a timestamping protocol. We had a number of those before, but blockchain is
the first one that doesn't use trusted third party. This is the ingenuity of
blockchain, not consensus that blockchain doesn't solve.
And then the idea behing Bitcoin, that a digital cash protocol (of which we
had some number before, too) can be built on top of published and timestamped
transactions, which together form a ledger. This is smart as well. But it's
still not a consensus protocol.
> But Nakamoto consensus does reach a consensus on value that is accepted by the network.
Despite that nobody can tell what value exactly was agreed upon? And despite
that you can't designate any specific point in time that the agreement is
reached? I fail to see how is this "consensus".
> Do all miners [eventually] agree on the value of a block? Yes? That's a consensus.
It's amazing how many things you got wrong in such a short statement. First,
a program can't say when this "eventually" is. Then the "agree" part is wrong,
too, because it can change just like that (because of forks), which even
changes the history, not just a single transaction or group of them. And then
there's also "all miners" part, which even read as customary universal
quantifier ("all" meaning "most of them") falls apart if you remember that
this needs to be assessed by a program with limited knowledge.
It's not a consensus in any computer related meaning that one could think of.
Dude, you haven't provided any usable criteria to declare any particular
block as "agreed upon". All you said was "eventually", and even that has
flaws. It's not something to argue against well known mathematics.
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.
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.
Decentralized system where 'retweeting' is rehosting. You traverse trust network n-levels deep and only access the content which has distributed trust to you. Every view is unique that user and their network.
How can one possibly moderate to prevent rehosting illegal content automatically? You need active filtering of some sort. If rehosting is not automatic, the platform will die very quickly.
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: miguel@zero-x.co.
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.