Live data from Hacker News

The Limits to Blockchain Scalability

vitalik.ca

291–300 of 465 posts

Re: The Limits to Blockchain Scalability

#291
post #183

Earlier quoted context omitted.

>All that matters is the valid history with the largest weight (longest chain rule in PoW). No, that exactly the believe that comes from BTCs implementation and while it may be true for BTC its completely irrelevant for other systems. Imagine there is a room full of people all have a paper with the exact same transactions in order on it. Now a new person joins and copies someones paper and then verifies all Tx. Ok, n…

The model you propose is weak to sybil attacks [1] and is based on trust, while the BTC model is based on zero-trust. There is nothing stopping someone malicious from spinning up thousands of nodes that all say the current hash is Y (with transactions that break the rules of the blockchain) while the remaining minority of nodes say the hash is actually X (the original longest chain). It is only by calculating the has…

> while the BTC model is based on zero-trust.

Its based on trusting that never more than 50% hashpower colludes You still trust its just no defined whom you trust. Its an illusion of no trust. Any decentral system can somehow be fooled if someone has a majority of "something". There is simply no way to prevent that. For BTC this is "something" is hashpower for other system like the XRPL it is the scarcity of mutual trust. But the quorum is actually 80%. And an attacker cannot know how much "mutual trust" his nodes have with others.

>There is nothing stopping someone malicious from spinning up thousands of nodes that all say the current hash is Y

Thats true but is irrelevant because the node decides whom it asks. And if it gets conflicting answers it would not accept a final state.

As the owner of a node you add a list of other nodes that should be asked. Lets say you have 20 nodes on that list the fact that someone spins up thousands of nodes doesn't mean anything. No one connects to them and if they do only to send data or receive data that can be validated like a signed Tx. The nodes have no power. Listing to a node is completely voluntary. Obviously people listen to nodes which are publicly known who operates them and therefore it also clear that they are not operated by the same entities. In reality such nodes are run by exchanges, companies that use the network and universities that do blockchain research. But anyone could its just up to you how you convince anyone to use yours. Maybe you can create one that almost everyone will use. maybe even two. But your army of thousand nameless nodes is never gonna be added by anyone. They are just listing and if they speak no on listens to them.

Also very important is the fact that a successful Sybil attack could not do much that's useful. Even if all the 20 nodes my node was told to listen to, declares a double spend as final, my node would not. You cant change the code I run and the code says the state is invalid. You created more tokens and that's not possible. It doesn't need to know the Tx that lead to this to know its wrong. The node would simply halt and all I have to do is remove the dishonest nodes from my list an add honest nodes and it keeps going. And the fact that a node lied is public so once an attack was attempted the node is "burned" no one will ever trust it again. In other words an immense amount of work and month and month more likely years of luring people into trusting all your nodes would give you the power to halt the network once (or more likely only a certain node) for an indefinite time (because it depend on human interaction) then all your work is toast. Assuming you would even manage to get enough nodes. You dont see who listens to your nodes so you fire blind and only have once shot.

>There may be other ways of tackling this issue that I am not aware of, but this problem in particular is one of the fundamental problems that Blockchains / Bitcoin were designed to solve (consensus among peers that is not disrupted by hostile actors). I have yet to see a better solution for this particular problem.

The fundamental problem it solved was the double-spending problem without an arbitrator of truth. But it is technically only partially solved because there is no final state.

However if you can reach decentral consensus over anything (a single bit) then the double spending problem isn't even a real problem anymore. If there are 2 conflicting transaction at the same time simply pick one that render the later one invalid because it attempts to move non-existing tokens[1].

Here is the doc about Sybil attacks on the XRPL https://xrpl.org/consensus-protections.html#sybil-attacks there is probably more technical stuff to read about it the official forum threads from 2013 or so.

[1] https://xrpl.org/consensus-principles-and-rules.html#the-dou...

Re: The Limits to Blockchain Scalability

#292
post #241

Earlier quoted context omitted.

What stops the authority from blocking internet access they can't spy on..

That is a very different discussion altogether.

Its a major problem to all the hype around crypto - it relies on a centralized internet infrastructure.

Re: The Limits to Blockchain Scalability

#293
post #104

So, what happens when one of the shards goes offline, or forks? What are the cascading consequences for validators of other shards, if any? Asking because I don't think there's a viable strategy for keeping all shard data around indefinitely, without giving up either scalability or durability: * If the system requires cross-shard state-transitions to be mirrored to on a "central" chain (e.g. the beacon chain) in orde…

The shards have thousands of different validators, all of which are staking their Ethereum on being accurate, and if they are malicious, they lose that Ethereum they staked. There are over 100k people signed up to this already (each staking 32+ ETH). So the likelihood of a shard going offline or forking is about as likely as AWS going down. The beacon chain is the central chain, all shards write a hash of what they'v…

Validators != separate physical computers. Also, what happens if the nodes for shard S in epoch N fail to replicate the shard data to the nodes assigned to S in epoch N+1?

Re: The Limits to Blockchain Scalability

#294
post #246

Earlier quoted context omitted.

I don't think shards are powered by hashing? I think nodes participating in Ethereum 2.0 are assigned to shards by the beacon chain, and they work to grow the shard's transactions by deciding on transaction ordering and inclusion in a BFT manner. Also, it's not clear to me that it's "thousands," nor is it clear to me that this even matters. If they're all in the same datacenter, and that datacenter temporarily gets d…

Why would they all be in the same datacenter? The beacon chain will periodically select staking nodes at random to go in each shard, and there's an economic incentive for stakers not to use the same infrastructure as everyone else.

Why is the chain's liveness and resiliency to server failures dependent on where people happen to be keeping their validators? This isn't a problem in Ethereum 1.0.

Re: The Limits to Blockchain Scalability

#295

Earlier quoted context omitted.

It essentially means that the Code is the product. Everything is visible and public. Every smart contract can be publicly viewed and verified. If the code isn't up to scratch, you can review it. If it has an exploit, you can detect it. Whatever it is doing, is transparent. You can't say the same when you deposit money into, say, Robinhood. You don't know what the code is doing with that money.

>> You can't say the same when you deposit money into, say, Robinhood How do you know what the major exchanges are doing as well? By the way, how did the exchanges wind up becoming so powerful and rich. Becoming almost a parallel Wall Street, just a smaller one, in a system that was supposed to ultimately democratise power. Some people with resources managed to emerge at the top in decision making...

Centralized exchanges are a necessary evil for now. DeFi (Decentralized Finance) is where code is law. Services like Uniswap, Curve, Aave etc are all just code that you interact with on Ethereum. Once you've onboarded into the decentralized world you can use them at will and eventually you'll be able to live your life without having to use centralized services again.

Re: The Limits to Blockchain Scalability

#296
post #85

This has some really questionable assumptions. Like the part about permanence. "An important property of a blockchain that users really value is permanence. A digital asset stored on a server will stop existing in 10 years when the company goes bankrupt or loses interest in maintaining that ecosystem. An NFT on Ethereum, on the other hand, is forever." This is wrong 2 times. First, there is no general requirement of…

I agree with this, a durable record of every transaction ever performed is in fact an anti-feature for a digital ledger. Mimblewimble[0] is one interesting solution to this. Unfortunately, the requirement in current implementations (such as Grin) that both wallets be online to complete a transaction, eliminates some valuable types of transaction, such as sending coin to a cold wallet. I do think for a 'world computer…

If these schemes with inherent MLM-Ponzi structures crash, how long will mining be lucrative enough? Perhaps then mining will distribute to the holders to try to maintain some value or use?

But you conclude with your worry that there are real costs, and zero pitch decks or white papers I've seen include arguably the most important competitive factor: cost of "how people do it now" vs. cost doing it "this new way;" and in-person, real life networks of trust networks has been how we've become as successful as we have as a society - and so works quite well - and doesn't inherently lineup with "trustless" propaganda of these popular blockchains; if blockchain is a valuable tool, say for legal institutions, they could create their own and run it themselves under agreement.

Re: The Limits to Blockchain Scalability

#297

Earlier quoted context omitted.

The model you propose is weak to sybil attacks [1] and is based on trust, while the BTC model is based on zero-trust. There is nothing stopping someone malicious from spinning up thousands of nodes that all say the current hash is Y (with transactions that break the rules of the blockchain) while the remaining minority of nodes say the hash is actually X (the original longest chain). It is only by calculating the has…

One way to sidestep this: every few minutes, post the longest hash to some distributed medium that can't be edited, like Twitter. Then the threat model moves to "do we trust the person with the keys to this twitter account?" However, this is also "zero trust," because you can write a program to verify every tweet as it's tweeted, and run that on a server somewhere. But, now that I've written this, I suppose Vitalik's…

>One way to sidestep this: every few minutes, post the longest hash to some distributed medium that can't be edited, like Twitter. Then the threat model moves to "do we trust the person with the keys to this twitter account?"

The XRPL does this by broadcasting. Every node tells everyone what they think is right, therefore everyone can see who lies and more importantly no one can see who you listen too. Its hard to trick me if you dont even know whom I listen too. And you cant test it because once you lie to me you lie to everyone and that the last time anyone listened to you.

The "zero trust" thing is an illusion. All decentral systems trust that the majority of something does "the right thing".

Some system use the majority of hashpower other use other metrics and some lets you pick and include or exclude participants. BTC for example doesn't give you any options you simply trust that from 100% hashpower more than 50% is controlled by honest people. Its not zero trust its more like zero choice trust.

Re: The Limits to Blockchain Scalability

#298
post #22

Vitalik is consistently one of the most interesting people to follow in the blockchain space. Even his (5+ year) old writing is quite interesting, if nothing else to see how Ethereum's research thinking has evolved over time. A few questions re: why "Ethereum is not going further than quadratic [sharding]." The first reason given: there's a minimum number of nodes required for shard for safety guarantees. So, a coupl…

>Vitalik is consistently one of the most interesting people to follow

Really? He has consistently argued for on-chain scaling and for people to not validate the blockchain state much like Elon Musk, with his seemingly 101-level understanding of blockchains. This post is a strange 180 from Vitalik's usual "do the opposite of Bitcoin because that is good marketing".

Now Vitalik is aware of the importance of running a full node and validating the blockchain state, and how blockchains can't scale, and how keeping blockchain bloat limited to allow easy verification is important? I'm convinced Vitalik has been replaced by some Bizzarro version of himself because of how astonishing this 180 is.

It took creating an entirely new separate altcoin, complete with massive premine for himself, and the greater part of a decade, to finally realize Bitcoiners were right all along.

Such a strange mountain man fantasy!

Re: The Limits to Blockchain Scalability

#299
post #183

Earlier quoted context omitted.

>All that matters is the valid history with the largest weight (longest chain rule in PoW). No, that exactly the believe that comes from BTCs implementation and while it may be true for BTC its completely irrelevant for other systems. Imagine there is a room full of people all have a paper with the exact same transactions in order on it. Now a new person joins and copies someones paper and then verifies all Tx. Ok, n…

The model you propose is weak to sybil attacks [1] and is based on trust, while the BTC model is based on zero-trust. There is nothing stopping someone malicious from spinning up thousands of nodes that all say the current hash is Y (with transactions that break the rules of the blockchain) while the remaining minority of nodes say the hash is actually X (the original longest chain). It is only by calculating the has…

The solution is to use the hash power between points of consensus. Aka everyone thinks node A is state last year and here are the next N transactions resulting in the current state X. Sybil attack says no it’s actually B and here are the next N transactions resulting in state Y.

You can compare the effort it takes for history A vs History B. Now, unlike traditional 51% attacks you don’t just need hashing power that instant but instead for very long periods. As such you can compute a minimum history such that actual 51% attacks are significantly cheaper.

That might seem weaker, but Bitcoin’s trust is simply an economic argument. The actual consensus risk is from someone hacking a few nodes thus enabling a 51% attack at near zero cost.

Re: The Limits to Blockchain Scalability

#300
post #85

This has some really questionable assumptions. Like the part about permanence. "An important property of a blockchain that users really value is permanence. A digital asset stored on a server will stop existing in 10 years when the company goes bankrupt or loses interest in maintaining that ecosystem. An NFT on Ethereum, on the other hand, is forever." This is wrong 2 times. First, there is no general requirement of…

I agree with this, a durable record of every transaction ever performed is in fact an anti-feature for a digital ledger. Mimblewimble[0] is one interesting solution to this. Unfortunately, the requirement in current implementations (such as Grin) that both wallets be online to complete a transaction, eliminates some valuable types of transaction, such as sending coin to a cold wallet. I do think for a 'world computer…

>the whole system is only as durable as the increasingly-enormous data centers which hold all that information.

That is exactly what Ethereum's direction has been for years now. It is centralized on Amazon AWS via Infura's nodes (which they charge access to, mind you). It's not a world computer. It's EC2 with additional complexity (and fees).

Post reply on HN