Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Limits to Blockchain Scalability

vitalik.ca

Post reply on HN
Print view View original

301–310 of 465 posts

Re: The Limits to Blockchain Scalability

#301

Post by noxer »

atweiden wrote: post #285
noxer wrote: post #239

Earlier quoted context omitted.

Don't assume blockchains are bitcoin or BTC like systems. I talk about the "current and undisputed or better indisputable (final) state". Bitcoin does not have this. Hence it can not function without history. This is a property of BTC not one of blockchains in general. Plenty other systems have a current state and a final state and there is no "better state" that can comer around and replace it. Final really means fi…

> BTCs "final" is just to wait some blocks its never final its just becomes incredibly unlikely to change the longer you wait. This is objectively worse than having a final state and on top of that it requires the history rather than just the last final state. You can have that type of finality with centralized protocols built on top of the Bitcoin blockchain — Lightning Network being the standout example. N.B. this…

>You can have that type of finality with centralized protocols built on top of the Bitcoin blockchain — Lightning Network being the standout example.

Whats the point? No one wants that beside that LN needs BTC on chain Tx which if you dont arbitrary define as final after some blocks makes it exactly the same - not final.

PoS/PoW is rather irrelevant. we already have solutions to make blocks/ledgers final its doesn't need PoW or PoS its just a properties that BTC doesn't have because it was designed without. There is no fundamental reason why it cant have it.

Re: The Limits to Blockchain Scalability

#302

Post by noobly »

noxer wrote: 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 dont care how my coins was moved 10 years ago. The only storage that is relevant for me, now, for value transfer is the current undisputed state

I don't have anything to add, but this has always struck me as inelegant, especially for Ethereum, which is more of a dApp platform. Can someone point me towards something that can run dApps and maintain current state with distributed consensus _without_ a blockchain (or explain why this is an ignorant question)? Also, what's wrong with truncating the chain after X blocks?

Re: The Limits to Blockchain Scalability

#303

Post by atweiden »

noxer wrote: post #301
atweiden wrote: post #285

Earlier quoted context omitted.

> BTCs "final" is just to wait some blocks its never final its just becomes incredibly unlikely to change the longer you wait. This is objectively worse than having a final state and on top of that it requires the history rather than just the last final state. You can have that type of finality with centralized protocols built on top of the Bitcoin blockchain — Lightning Network being the standout example. N.B. this…

>You can have that type of finality with centralized protocols built on top of the Bitcoin blockchain — Lightning Network being the standout example. Whats the point? No one wants that beside that LN needs BTC on chain Tx which if you dont arbitrary define as final after some blocks makes it exactly the same - not final. PoS/PoW is rather irrelevant. we already have solutions to make blocks/ledgers final its doesn't…

I don’t quite catch your point. The chances your brain continues functioning over the next twelve minutes is not 100%, but 100% less some infinitesimally small fraction. 99.999999...% is as close physical reality ever comes to 100%.

> PoS/PoW is rather irrelevant

It’s an incredibly relevant fact that PoS blockchains pos1, pos2, pos3 cannot be compared without overtly trusting central authorities to give you the “correct” answer. Conversely, the PoW blockchains pow1, pow2, and pow3 can be objectively ranked by cumulative hashrate using simple mathematical comparisons.

Contrary to popular belief — and despite the endless handwaiving PoS acolytes engage in over social media — PoS blockchains continue to lack a meaningful answer to this predicament which doesn’t boil down to overtly trusting central authorities. Which begs the question: why do they need a blockchain at all?

Re: The Limits to Blockchain Scalability

#304

Post by s17n »

wmf wrote: post #101
s17n wrote: post #65

If Vitalik is correct that the only viable defense against the attack described in this article is users validating nodes en masse, then blockchain is doomed, because you're never going to convince more than a small percentage of users to validate blocks. Personally, I think that custodial entities such as Coinbase (or in the future, banks) can probably be relied on to not do anything too controversial.

I don't think you're disagreeing as much as you think. A small percentage could still be 10,000 nodes or more which seems like a healthy number. (Of course, even a billion nodes can't prevent attacks if they have no economic weight...)

Yeah, I'm disagreeing with the notion that it matters whether you can run a full node on a laptop. Users casually running nodes on the hardware they have lying around is not a realistic model. Those 10000 nodes, to matter, will have to be representing economic interests that can't simply be ignored, and as such, will be able to afford whatever hardware is necessary.

Re: The Limits to Blockchain Scalability

#306

Post by johndoe42377 »

narush wrote: 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…

Come on, he has neither math not cs background.

Only elusive daydreaming.

Everything serious begins with a math model. Otherwise this is just handwaving, which is precisely what it is.

Re: The Limits to Blockchain Scalability

#307

Post by shkkmo »

javert wrote: post #9
laurent92 wrote: post #3

Earlier quoted context omitted.

I was trying to summarize, for an employee who got caught in “Elon Musk shouldn’t have manipulated the BTC” (!) (obviously the employee lost 25% of his savings), I was trying to summarize the list of dangers of having savings in BTC. - Laws of any big country could change and trigger the sale for a lot of sellers of a country, - Especially given BTC is used by Iran to bypass petrol restrictions, used by ransomware an…

There are also big risks to fiat money, such having the entire economic output of your civilization be grossly distorted by central banks.

Until the cryptocurrency community sorts out their Tether problem, they should probably lay off the "but central banks print money" talking point...

Re: The Limits to Blockchain Scalability

#309

Post by noxer »

Retric wrote: post #299
jimmydorry wrote: post #248

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…

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 i…

You mean like hacking a few mining pools like 4 and then performer 51% attack at near zero cost. Sounds silly but you get the point. The hacking argument is just not realistic. And it gets less and less relisting to more nodes there are. (and more realistic the fewer mining pools are needed for a 51% attack)

BTW if you would have full control over any 4 XRPL validator nodes at your choice you could do absolutely nothing. No double spend, not even halt the network, nothing at all. You could turn them off and only a few nerds who constantly check the network would notice. User of the actual network would not.

Post reply on HN