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

261–270 of 465 posts

Re: The Limits to Blockchain Scalability

#261

Post by noxer »

c01n wrote: post #237
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…

Imagine a peer goes offline and stuff happens on the network while its offline, when the peer goes back online what state does it follow, remember that it is a decentralized network what peer does it trust? This is where the chain of verifiable transactions come in. Also with this setup it is kind of easy to prevent double spending. > BTW cash does not have a recorded Tx history Sorta... The central banks know every…

Not a problem if its a DLT with final state. You just need to request the hash of the final state from enough nodes to assure its the real deal. They would all need to lie the same way to trick you. If they are all compromised then the system is rendered useless anyway.

Also basic properties like the total amount of tokens can be validated on the last state alone. You can assure no one added more tokens simply by summing all balances. You dont need any history data for that.

>Sorta... The central banks know every coin that has been created and notes that have been printed. When you fill in your Tax forms you are creating this Tx history manually.

Yeah no, you are moving and stretching the goal post to far here. Notes are unique but that's not a Tx history at all and neither is a Tax form.

Re: The Limits to Blockchain Scalability

#262

Post by SubiculumCode »

atweiden wrote: post #243
SubiculumCode wrote: post #209

Earlier quoted context omitted.

I really don't know what you are talking about. ETH hit its all time high a few weeks ago (May 10th) both in terms of USD and BTC. Its still double it's ATH from its peak in 2018, before the crypto crash. As to your other ramblings, mere snobbish tripe meant to demean and belittle those that disagree with your opinion. In other words, yours is a low information post.

> I really don't know what you are talking about. ETH hit its all time high a few weeks ago (May 10th) both in terms of USD and BTC. Its still double it's ATH from its peak in 2018, before the crypto crash. > As to your other ramblings, mere snobbish tripe meant to demean and belittle those that disagree with your opinion. In other words, yours is a low information post. ETH broke 0.12 ETH/BTC last narrative cycle. T…

You are correct re BTC, but not it has well exceeded that re USD. Why BTC has some special place in terms of the utility of smart contract blockchain is questionable.

Re: The Limits to Blockchain Scalability

#263

Post by sillysaurusx »

noxer wrote: post #239
vvillena wrote: post #219

Earlier quoted context omitted.

Blockchains don't have a concept of a "current undisputed state". If you managed to create a longer (and valid) Bitcoin chain on your own than the longest one there is at this very moment, and publish it, all other clients will start using it as the new longest chain. And if two equally long chains are published at about the same time, and clients get split, things will probably get resolved in the next block. So, mo…

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…

No matter what your validating gives you in the end you can only accept the current final state of the running network or not use it at all.

I'm a bit of a blockchain noob, but isn't this the opposite of how blockchain works?

What I mean is, yes, you can design it the way you're saying, but doesn't that open you up to double-spend attacks and enforced centralization? You need a central ledger at that point, since your "final state" has to come from somewhere.

I'm confused but intrigued.

EDIT: Ah, https://news.ycombinator.com/item?id=27259783 points out the problems with this approach much more eloquently than I did.

Re: The Limits to Blockchain Scalability

#264

Post by DennisP »

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…

Regarding your first reason, I think having more users can increase the security of the data, even if you're conservative about the minimum number of users you need.

For the second, if you don't care about data permanence, it's relatively easy to put the data on a second layer. Just host the data there and put merkle roots on the blockchain for consensus. If you want to verify state transitions on chain you can do that too, e.g. with zksnarks.

Re: The Limits to Blockchain Scalability

#265

Post by napoleond »

crazypython wrote: post #231
idlewords wrote: post #115

The really obvious weakness in any blockchain setup is the software. Whoever controls the software upgrade channel will always have potential control of the blockchain, whether that's the official entity in charge, or some intermediary. If you want really widespread distribution of full nodes, you need to make a consumer-friendly distribution of the node software, and package it and keep it updated in a way that regu…

> you need to make a consumer-friendly distribution of the node software https://bitcoinknots.org It's a distribution of Bitcoin Core. It needs 5GB to store enough blockchain state to fully verify everything. AFAIK Bitcoin Core also has a convenient GUI interface. I set up a node on my computer. I didn't touch the command-line once. It has a nice GUI and built-in wallet.

And how did you verify its integrity? And what is the upgrade path?

Re: The Limits to Blockchain Scalability

#266

Post by DennisP »

Judgmentality wrote: post #118
TarasBob wrote: post #110

Earlier quoted context omitted.

Ethereum proof of stake beacon chain has been live for 6 months now: https://beaconcha.in/

That's running only a fraction of the network, though. The concerns are whether or not it can scale (or at least those have always been my concerns), and I'm of the opinion it won't work. I hope I'm wrong.

It's not running any of the network. It's running on its own, and it's well beyond the point required for security. It reads the PoW chain, and reaches its own consensus on block hashes.

What remains is to alter the clients of the PoW chain, so that it reads the PoS chain. Then instead of choosing the blocks with the most accumulated work, it chooses the blocks chosen by the PoS chain.

That's not a big change for the PoW clients, it doesn't add load to the PoS network at all, and it's all that's needed to eliminate mining.

Re: The Limits to Blockchain Scalability

#267

Post by noxer »

mvzvm wrote: post #229
noxer wrote: post #98

Earlier quoted context omitted.

https://ripple.com/ripplenet/on-demand-liquidity/ This is a real product, real people use it (without knowing that they do).

Can you elaborate?

ODL is a product that uses a DLT (the XRPL) and a digital asset (XRP) to facilitate cross bolder transaction.

Instead of finding a bank or payment provider that hold the foreign currency you want to deliver somewhere and exchange it for you currency, this system converts you local currency to XRP send the XRP to the destination and sells it there for the local currency.

If you send money to the Philippines or Mexico you may have used it without knowing.

Re: The Limits to Blockchain Scalability

#268

Post by sillysaurusx »

jimmydorry wrote: post #248
noxer wrote: 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…

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 "Limits to Blockchain Scalability" addresses this: even if it's theoretically possible to validate the hashes on a supercomputer somewhere, you want your users to be the ones doing this validation, because otherwise it would be possible to compromise the "zero trust" model described above by compromising one twitter account and N verification servers. When N is small, this might be a realistic concern, especially if the verification servers are continuously pulling code changes from a central source code repo.

Re: The Limits to Blockchain Scalability

#269

Post by baylor121 »

mvzvm wrote: post #26

Scam after scam, that's all blockchain is. Just another way to fleece the average consumer. There has not been a single valuable use, a single product, that actually improves anyone's day / process / life / anything. I am very open to changing my stance if someone presents evidence to the contrary.

Someone from africa or russia can buy tokenized american stocks (like aapl/goog) that they wouldn't have access to easily in their national stock exchanges. I'm really excited to use tokenized stock projects like mirror that are popping up.

Re: The Limits to Blockchain Scalability

#270

Post by [deleted] »

noxer wrote: post #261
c01n wrote: post #237

Earlier quoted context omitted.

Imagine a peer goes offline and stuff happens on the network while its offline, when the peer goes back online what state does it follow, remember that it is a decentralized network what peer does it trust? This is where the chain of verifiable transactions come in. Also with this setup it is kind of easy to prevent double spending. > BTW cash does not have a recorded Tx history Sorta... The central banks know every…

Not a problem if its a DLT with final state. You just need to request the hash of the final state from enough nodes to assure its the real deal. They would all need to lie the same way to trick you. If they are all compromised then the system is rendered useless anyway. Also basic properties like the total amount of tokens can be validated on the last state alone. You can assure no one added more tokens simply by sum…

[deleted]
Post reply on HN