Hacker News Reader

Comment by gruez | Hacker News Reader

>None of this is new. The Bitcoin "block size war" was fought over this very point. Unworkable scaling schemes are going to end in disaster with no fallback, and no recourse for those who lose money. You end up with nothing, and will be sad.

I don't see the parallel to 'the Bitcoin "block size war"', though? The solution on either side (bigger blocks, lightning network) doesn't require trusting some party to handle transactions.

View on HN

I think their point is that at some block size, it's no longer feasible for most people to run their own node to verify the blockchain, and you start relying on a client-server model instead of a peer to peer model.

Yes, interestingly with Ethereum it's not the individual block size that's holding it back (they're around 80kb), it's the protected size of all blocks for people running validator nodes. You don't want to require node operators to have 100TB in SSD storage because your blocks all pile up too quickly (this is one of the main concerns about Avalanche scaling).

Part of it IS the individual block size though. Individual blocks might seem small, but there's a lot more of them. Ethereum dApps store a LOT of state directly on the base chain. The other scalability disaster is making every node validate every instruction of a Turing-complete scripting language, which results in insane "gas fees" (or loss of fees when you didn't supply quite enough for the script to fully execute).

> (or loss of fees when you didn't supply quite enough for the script to fully execute).

Are they planning to address this in any of the updates on their timeline? This turned me off from ETH completely, just feels like a house-always-wins situation skimming money from users.

No idea, Ethereum was an intriguing experiment for the first few years, but it’s seemed like a dead end for a while now

Since it's deterministic, you can get a good estimate (in fact exact as long as you are not front-run) by simulating the execution locally before submitting it. All major wallets do this.

In addition to what 3np said, you can use Flashbots as your RPC node, and your transaction won't be submitted if it's going to fail.

Minor note, the reason for charging for failed transactions is to prevent abuse of network resources, don't want someone submitting millions of bogus transactions to DOS the network.

That's a good reason, still need people to pay for scarce resources, just a shame that there's no mechanism to pick up where you left off.

Thanks for the tip about flashbots, never heard of it

With larger blocks, you can still hold your own private keys. As long as ONE of the blockchain explorers you rely on is honest, you also cannot be scammed. Given the blockchain data is public domain, and freely exchanged, the idea that you won't be able to find a single honest information purveyor seems farfetched.

Reply on news.ycombinator.com