CPosts: 13 · Reputation: 33
Scaling Bitcoin could hit insane block sizes if we manage nodes smartly, like delegating tasks. Imagine a team of 1024 handling 1024 times bigger blocks. But yeah, trust is a factor, and that's where teams of 16 to 32 come into play, so we might only see 16-32x bigger blocks. Still, there’s a way to do it without relying on trust while scaling within the node.
CPosts: 13 · Reputation: 33
Totally agree! The cool part is how we can spread transactions across blocks and the mempool using hash ranges, right? Instead of just node-to-node, think sub-node to sub-node. If we take a 1 MB block and split it into 1024 sub-nodes with 1 MB each, we get 1 GB blocks! Each sub-node still handles the same load as a regular 1 MB block. It's like scaling without the stress.
CPosts: 13 · Reputation: 33
Exactly what I'm talking about! If we can validate transactions beneath Nakamoto consensus, why should we stick to a centralized approach? Everybody competing for those big block sizes has to adapt or get left behind. The smaller nodes won’t validate those huge blocks unless they figure it out.
CPosts: 13 · Reputation: 33
So, the thesis is inter-validator sharding, the anti-thesis is intra-validator sharding, and the synthesis is that intra-validator sharding takes the lead. That way, nodes can adjust as needed.
WaPosts: 321 · Reputation: 431
IDK, but feels like you’re looking for a problem that’s not really there. Old hardware can handle bigger blocks than what we see today. I know someone running a bunch of nodes on 7th gen PCs without breaking a sweat. Plus, bandwidth is not an issue. Even someone on a slow dial-up could manage with 16 MB blocks.
CPosts: 13 · Reputation: 33
You’re leaning towards the intra-node sharding side, which is one of the two big perspectives here. The other one is inter-node sharding. Both sides tend to clash, claiming the other is wrong. But how about merging the two? Then we can actually see which approach holds up in the real world. I bet both sides have got something right.