Sharding centralizes Ethereum by selling you Scaling-In disguised as Scaling-Out
Tags: Bitcoin, Blockchain, Ethereum, Sharding, Scaling

My point here was even though “full-validation” is divided into sub-jobs, the group of nodes that do those jobs is still limited. He says these nodes would be processing less than current Ethereum nodes, but again that was never the issue. The issue is that the difficulty to do so grows over time, and the amount of nodes shrinks over time because of it. It’s inherently centralizing. Vitalik even agreed that this number would shrink over time if the gas limits kept going up, and there’s nothing stopping that from happening. Right now miners are being altruistic, but what happens when mining doesn’t even exist? What happens when it’s just staking and the people doing it don’t care about other people’s blocks getting orphaned? Why would they keep the gas limit down? Remember they can manually adjust this, so why would they intentionally keep it low if they’re hyper-connected to each other and fully capable of processing that data? What happens when they start compounding their staking earnings, setting up more nodes, and gain more control of the network?

What happens when people don’t think it’s a shitcoin though? Most are going to fail, but what happens when one of them is convincingly decentralized just enough for the time being to keep people using it?

I said all of this was going to be easy. I don’t feel like it turned out that way, but I tried to keep it as simple as I could. I mention this because I’d like to close this article with a link to the Sharding FAQ where there’s a long list of admitted issues with Sharding, and how they plan to address them, and how each one of those introduces a new complexity with it’s own issue, and another solution to resolve that new issue. It’s convoluted, it took me too long just to decipher the verbiage for the node types, but it’s only fair to provide it.

My issue was never with whether it “worked”, but whether it remains decentralized. It was kind of bad prior to Sharding, but I don’t think it could be any clearer that there’s only one path for this network on a long enough timescale. If you don’t mind having centralized validators, you might as well buy EOS. They skipped the whole pretending part and went straight to being centralized. They don’t even need Sharding because they just handle the blockchain data in a centralized fashion.

Google can process everyones payment’s.

We don’t want Google to process everyone’s payments.

We don’t want the Fortune 500 or the Forbes 400 processing it either.

So what did we learn?

No.

Use a 2nd Layer.

Breaking Down Vitalik’s Response

1:

This is *severely* uninformed. Ethereum already has a block size limit in the form of its gas limit, and this gas limit is at 8 million and has been there for the last six months.

I addressed this above. You will raise the gas limit if Sharding isn’t ready soon enough to come in and stall this issue.

2:

Fast sync datadir growth has flatlined at 10GB per month for the last six months and it’s not going to go much higher, if only because increasing the gaslimit much further would lead to uncle rate centralization issues. So we *already are* experiencing the worst of it and have been for half a year.

If you don’t increase the gas limit the fees will disable Dapps and cause outrage among the community because they have expectations and demands. I went over this above as well. Uncle rate won’t matter when you have no other solution, right now the miners are just being altruistic by listening to you. That’s an issue in and of itself.

3:

Also, focusing on archive node size is highly fallacious because (i) you can have a much lower datadir size by either resyncing even once per year, or just running a Parity node, which prunes for you, and (ii) it includes a bunch of extraneous data (technically, all historical states, plus Patricia tree nodes) that could be recalculated from the blockchain (under 50 GB) anyway, so you’re not even “throwing away history” in any significant information-theoretic sense by doing so. And if you *are* ok with throwing away history, you could run Parity in state-only mode and the disk requirements drop to under 10 GB.

I addressed this “conflict” when I showed the data throughput over time graph. The directory size is analogous to the same exponential growth that’s occurring with the nodes processing requirements. The only counter-response to this is that you won’t raise the gas limit. You will.

4:

The whole point of sharding is that the network can theoretically survive with ZERO of what you call “full nodes”. And if there are five full nodes, those five full nodes don’t have any extra special power to decide consensus; they just verify more stuff and so will find their way to the correct chain more quickly, that’s all. Consensus-forming nodes need only be shard nodes.

I addressed sharding above.

5 (lol):

Finally, you’re using the term “BCash” wrong; it’s an implementation, not a blockchain/cryptocurrency.

Breaking Down Gustav Simonsson’s Response:

1: “(…) the incentive structure of the base layer is completely broken because there is no cap on Ethereum’s blocksize (…)”

This is misleading at best and false at worst. Ethereum has a block size limit due to the block gas limit enforced by the consensus protocol. they are unlikely to vote for a blocksize increase that would break the network

I addressed the gas limit further in this article. Thanks for motivating me. The network doesn’t break because validators drop off and peers are lost. The network functions with two datacenters. What breaks is decentralization. The connected nodes have no incentive to care about other less-connected nodes validation abilities.

2: “Even if one [blocksize cap] was put in place it would have to be reasonable, and then these Dapps wouldn’t even work because they’re barely working now with no cap.”

Nobody goes to the beach anymore — it’s too crowded. If a blockchain network is at capacity, with all blocks filled with transaction, then all the tx senders found utility in sending their txs with their particular fees.

This completely misses the point because this is the same argument we make in Bitcoin. It’s very popular, but Bitcoin doesn’t promise low fees and usability to Dapp developers and users. When those Dapps get priced out to basic transactions from mixers (lol) using 90% of the block space to dump their hacked/stolen coins because mixing is worth paying more than using silly Dapps no one really uses, what marketing do you have left? That’s the point. You can argue this down all you want, but at some point you start justifying Ethereum’s existence with only the matching properties of Bitcoin without the fancy bells and whistles, and Bitcoin does Bitcoin better.

The author continues their fallacy by directly contradicting themselves by arguing for apps on Ethereum to move over to Bitcoin. If apps become useless on Ethereum due to increased tx fees, then they would be useless on Bitcoin too if crowded out by other users who pay higher tx fees.

I suggested developpers develop on top of Bitcoin. I didn’t say take the same program ideas you have that may never actually work and build it on Bitcoin. Almost all Dapps are centralized to begin with and aren’t actually “dapps”. They can all be built on Lightning. You won’t have fee issues no matter the blocksize on a payment channel network. Again you could argue Ethereum can do this too, but that doesn’t give its base layer promises any extra reason to exist.

There is no such thing as apps crippling Ethereum due to high load

3: “The [Bitcoin] blocksize doesn’t restrict transaction flow, it regulates the amount of broadcast-to-all data being sent over the network.”

This is false for any sane definition of “transaction flow”. An arbitrary limit on tx/s does restrict transaction flow, as more transactions cannot flow within a given time period… And if we’re including off-chain solutions such as the lightning network as an argument that L1 tx/s limits does not decrease flow, then we should include in such discussions already live solutions on Ethereum too. Or recognize that the cost to setup e.g. payment channels increases as the L1 fees goes up…

We are including them, which is why I said it doesn’t restrict flow. The blocksize is a dam that generates power in the form of fees. The overflow spills into the Lightning Network, which has no upper limitations on transaction throughput outside the volume of Lightning nodes and payment channels, which have no limit themselves.

Also, any transaction where you receive Bitcoin, can be received straight to a newly opened channel. This isn’t a two-step process.

4: “I am saying that this information needs to stop being obscured. I’m also saying that if/when it ever is unobscured, it’ll be too late and nothing can be done about it anyway.”

This information is not obscured. You can simply run a full node and query it Just because you haven’t found a website doing this the argument that it “it’ll be too late” when it is unobscured is at best a faulty generalization and at worst the post hoc fallacy.

It’s obscured. It’s not a matter of me “not being able to locate” sites that track this. The sites that did track it stopped tracking it.

You forgot to include the next sentence: “It’s already too late.”

It was a quip, not a fallacy. Take it or leave it.

5: “Keep in mind, none of this information [block propagation times and transaction times] is available for Ethereum”

This is false. Block propagation times can easily be measured by running a few, geographically distributed full nodes, connect them to each other and measure when they see and relay new blocks and transactions. too lazy to spend a few hours learning how to deploy, use and even add debugging to Ethereum clients, in order to gather such information, they can always check propagation times for nodes connected to https://ethstats.net/

First, that’s opposite of easy. Again this isn’t about me, because I’m clearly able to discern the differences in these networks and gather the information together. I’m the one sharing it because I did so.

Second, I don’t need to set up nodes around the globe to check this, and all the complaints online plus the data to the left of this from the very website you suggested only solidifies the consensus online. When half the nodes that volunteer their data to this website have terrible latency it’s indicative of an issue.

Thirdly, a lazy person wouldn’t go through the effort I am, nor am I false stating this isn’t publicly available. Network data in general is not publicly available, it’s literally not there for the public to see, and some of it once was. You need more than common knowledge to access it.

6: [vague rant about using the blockchain the “right” way and hatin’ on CryptoKitties]

The author presumes there is a “right” way to use a public, permissionless blockchain. The beauty of blockchains such as Bitcoin and Ethereum is that users can use them for whatever they want as long as they can convince a miner to accept their tx. For example, a lot of people actually _enjoy_ CryptoKitties, to the extent of bidding $140,000 worth of ETH for one cat at a recent auction.

This isn’t about what transactions miners accept. I’m saying that even though they are being accepted now, in the future any Dapps that can only function using low fees won’t be usable unless the limit is raised, or decentralization is sacrificed. You might want to start looking elsewhere for this functionality. If you don’t care about decentralization then this just doesn’t apply to you, that’s totally fine. But this is literally Ethereum’s selling point right now:

Putting money laundering aside, idiots exist. CryptoKitties is a great tool to demonstrate this. I actually like CryptoKitties because of this valuable publicly available litmus test, and I don’t hate cats:

7: “The Bitcoin network has about 115,000 nodes, of which about 12,000 are listening-nodes.”

This appears to contradict several other sources on Bitcoin node counts If all these sources are wrong, they would probably love to know exactly how nodes are counted by the site the author links. Moreover, who has audited the scripts calculating these larger node count numbers?

All it does is count non-listening nodes as well as the listening nodes. Counting both is harder to do, so websites don’t do it. Likewise, segregating light-node and validating nodes in Ethereum is harder, so websites don’t do it.

8: “That Ethereum node count? Guarantee you those are mostly Light-Nodes doing absolutely zero validation work (checking headers isn’t validation). Don’t agree with that? Prove me wrong. Show me data.”

How about the author provides some data supporting their speculative claims? “Guarantee you” implies an appeal to authority, and given the above false claims and misunderstandings, the author has in my mind lost enough credibility to be taken seriously on matters of (Ethereum) protocols and networks.

I admit to presuming, but to say my credibility is lost is a bit far-fetched. My concerns are legitimate and shouldn’t be ignored. You can disagree, but you need to make a case for why you disagree, and this and my prior article laid out a pretty clear case: Validating nodes are important and Ethereum neglects them at a protocol level.

9: When your node can’t stay in sync it downgrades to a light client.

False. Even if a node is behind a number of blocks when syncing, it can still answer queries for past blocks and transactions and service other nodes that are syncing. The author would do good to examine the concurrency and state handling of clients such as parity and go-ethereum to understand more how nodes currently implement syncing and will work with new sharding proposals.

It’s not false, you just took it literally. All the comments online about peoples nodes falling out of sync result in the person then deciding to use fast sync, usually after being compelled by someone else telling them “it’s fine”. From a zoomed out perspective, this results in validating nodes offlining &light-nodes onlining, like the diagram I showed above.

10: “How would you even know how many fully validating nodes there are in this set up? You can’t even tell now because the only sites tracking it count the light clients in the total. How would you ever know that the full-nodes centralized to let’s say, 10 datacenters? You’ll never know. You. Will. Never. Know.”

OK, so right now we are able to know, with full certainty, that there are 115000 correctly verifying full Bitcoin nodes, but in this hypothetical future the author imagines we are unable to know how many correctly verifying full nodes there are in the Ethereum network? Clearly there is some network engineering design magic currently present in Bitcoin that this future Ethereum network could leverage. Given that both Bitcoin and Ethereum clients are open source, I expect this magic to soon be discovered by Ethereum developers and then merged in, enabling us all to know exactly how many full nodes are present at any given time.

The reason you can be sure for Bitcoin is because all nodes validate. Every participating actor in the network validates the chain, it’s the only way you can know the next block is valid without trusting anyone else. There are no light-nodes in Bitcoin.

In Ethereum there are so many ambiguous ways nodes interact with each other that the only way to reasonably detect which nodes are fully validating would be to request random blocks from the past to see if they have that full block, but most Ethereum nodes typically don’t keep the history because Ethereum is state based.

The networks are fundamentally different, which is why it’s easy to poll the network for Bitcoin, and problematic at best for Ethereum.

— — —

Naturally, it requires more to run an Ethereum full node. And it can strain especially older laptops, and definitely requires an SSD. However, it does not require a beefy server by any reasonable measure. In fact, any dedicated machine with a CPU from the last 6 years, 8 GB of RAM and a modern SSD can process an Ethereum full node just fine (or several full nodes as run on my pretty modest server). The bandwidth usage of tx and block relay is something to consider but is generally not a problem on well connected networks.

1: It’s getting more difficult with time.

2: It’s also kind of moot given the $45,000 validating nodes.

3: Bandwidth on non-$45,000 validating node networks is most certainly important because “well-connected” is dangerous for privacy, as I’ve described above.

— — —

Miners are aware of the current block size (gas) limit and actively take part in discussions with other parts of the community around what an ideal block size limit is Miners have historically acted both to lower and to increase the limit before

None of this matters in a PoS centralized network. It’s very dangerous in a PoW system over the long term though. There’s no incentive to keep “other” nodes connected or in sync “when they can just sync the headers”. They might be acting altruistic now, but there’s no reason to expect this behavior in the future. It’s a dangerous proposition to start trust honesty among those in power as these networks start scaling up.

— — —

Overall, as clients have continuously improved performance since the launch of the network, miners have gradually increased the limit towards the current value of 8M (Ethereum launched with 3.14M). Generally, if syncing issues become significant enough to affect the ETH price, miners become incentivized to lower the limit to regulate the network.

I have no reason to believe the limit will be lowered, as I’ve made clear throughout these articles.

— — —

As others have already discussed the various sync modes supported by Ethereum clients and their varying resource requirements, another thing worth talking about as an emergency remedy — if the Ethereum network does indeed grow so fast that it becomes hard for most full nodes to keep up — are checkpoints. Someone like StopAndDecrypt probably panics at the very mention of something as unholy and sinful as blockchain checkpoints. How can a blockchain be decentralized if clients implementing the consensus protocol agree on a checkpoint block rather than syncing from the genesis block?!

Checkpoints have their functions, but you’re presuming a bit in regards to what I think about them. Regardless, sync modes don’t matter, they’re fine for you if that’s what you want to do. My concern, again, is the validating node set, and checkpoints only address history data, not data processing requirements after getting synced.

In practice, a reorg in either Bitcoin or Ethereum deeper than a few hours is extremely unlikely

I agree.

— — —

Epilogue No one actually knows how many full nodes are required for a network to be “secure”. Until then, we cannot know if 1K, 5K, 10K or some other number is the minimum required to keep a network reasonable secure.

See above.

— — —

That said, we should continue to encourage individuals and projects working on Ethereum apps — or anyone interested in contributing to the network — to run their own full node.

I hope that have upwards of $45,000 once PoS+Sharding comes. If ETH goes up, that’s even worse. DASH requires 1000 coins, it was $1,000,000 to run a masternode at one point.

— — —

For those for who read this far —

I did, and I don’t hate you. People tend to take my writing as hostile. It’s not.