Live data from Hacker News

Ethereum London Mainnet Announcement

blog.ethereum.org

61–70 of 153 posts

Re: Ethereum London Mainnet Announcement

#61

Earlier quoted context omitted.

Not quite. They would need to coordinate a new hard fork before Mid-End August because of the incoming ice age which intentionally slows the chain to a stop unless a hard fork happens. Simply saying "No I don't want to do that" isn't enough, you need to get together people to form at least one suitable alternative. That's why the ethereum devs could maintain control of the chain and the Bitcoins couldn't. Consequentl…

So it's not up to the miners and the consensus to decide what's best for the network? The leadership can decide the rules of a new fork unless everyone else coordinate to oppose it? Edit: What prohibits the leadership to do an arbitrary fork? How do cryptographic protocols factor the fact that leadership can just say 'no' and do the opposite and the chain will follow. Especially the word 'secure' in every coin looses…

Why the hell should I trust the miners more than the leadership? You say this like the leadership is this big, scary, shadowy group. The Ethereum leadership is one of the main reasons I invested in the coin. I love the leadership, and I trust them to make good decisions for the ecosystem.

Re: Ethereum London Mainnet Announcement

#62
post #40

Earlier quoted context omitted.

Sometime in 2017/18 it has been found that one of the biggest bottlenecks for the network were propagation speeds and that those were largely weighed down by disk writes. Thus pretty much the whole network switched to SSDs and things improved tremendously. Some other networks have implemented stateless clients and Ethereum has been working on going in that direction for a while with a lot of effort being dedicated to…

Does the node need bulk write speeds? or does it need fast IO ops per second?

It needs low latency. There is a huge amount of inherently sequential lookups in the state (~9 leveldb lookups per 1 state acess in a smart contract) and you can't store the state in RAM on most consumer hardware.

Re: Ethereum London Mainnet Announcement

#63

Will the miners accept 1559? It’s an optional space, miners are free to maintain the old chain and split. Of course this would be catastrophic. I know my history, this isn’t anything like the other times.

Because of the existence of stablecoins, forking Ethereum is essentially infeasible. Only crypto assets, namely BTC, exist on the Bitcoin chain. Crypto assets can be forked, but real assets cannot. Whatever chain USDT/USDC recognize automatically becomes the "true chain" regardless of how much hash power the miners throw behind the fork.

[deleted]

Re: Ethereum London Mainnet Announcement

#64
post #40

Earlier quoted context omitted.

Sometime in 2017/18 it has been found that one of the biggest bottlenecks for the network were propagation speeds and that those were largely weighed down by disk writes. Thus pretty much the whole network switched to SSDs and things improved tremendously. Some other networks have implemented stateless clients and Ethereum has been working on going in that direction for a while with a lot of effort being dedicated to…

Does the node need bulk write speeds? or does it need fast IO ops per second?

It's read as well as write IOPS and seek time. The Ethereum state database uses hashes as keys and is larger than anyone's reasonable amount of RAM. So most accesses are all over the database in terms of physical location, and it can't be cached in RAM effectively.

There is various work to improve this, but the basic architecture does depend on random access storage to a great extent.

Re: Ethereum London Mainnet Announcement

#65
post #41

Earlier quoted context omitted.

I don't understand, why is spinning metal not good enough? For the large amount of storage required it seems like it would be a good idea.

If you use spinning rust for the initial sync you’ll most likely never catch up. If you have craploads of RAM to allocate to ARC, you may actually be able to do it on ZFS I guess.

I think this may no longer be true with the Snap sync protocol (introduced in Geth this year). Even though transactions are very random access, Snap iterates sequentially over storage to transfer it all from one node to another, which is HDD friendly.

However I'm not confident it will be able to stay in sync afterwards using HDD.

Re: Ethereum London Mainnet Announcement

#66

If readers are curious how to get up-and-running with a (non-mining) full node (ETH1) at home, it's quite simple. This is how I did/do it on my Intel NUC running Ubuntu Server 20.04: 1. Download a prebuilt binary from https://geth.ethereum.org/downloads/ . 2. Unpack it. Optionally make it (or a symlink) available in your PATH. 3. Create a service definition, enable it, and start it: [Unit] Description=Go Ethereum [Se…

I don't understand, why is spinning metal not good enough? For the large amount of storage required it seems like it would be a good idea.

It's a great idea. It just doesn't work. HDDs don't have the right performance characteristics, unfortunately.

You can do about 300 random access per second on a good HDD, which isn't enough to keep up with Ethereum's transaction rate, and each transaction needs quite a few of those each.

You can do about 300,000 per second on NVMe. 1000 times faster. That's plenty.

Re: Ethereum London Mainnet Announcement

#67

Earlier quoted context omitted.

Because of the existence of stablecoins, forking Ethereum is essentially infeasible. Only crypto assets, namely BTC, exist on the Bitcoin chain. Crypto assets can be forked, but real assets cannot. Whatever chain USDT/USDC recognize automatically becomes the "true chain" regardless of how much hash power the miners throw behind the fork.

Doesn’t that seriously centralize the network overtime?

We'll see. Stablecoins are a workaround for the current price fluctuations, if the cryptos stabilize they might replace the stablecoins at some point in the future.

Re: Ethereum London Mainnet Announcement

#68
post #29

Earlier quoted context omitted.

But the custodians have to choose just one chain because they only have enough assets to back one copy. They don't want a situation where there's, say, 50B USDCA and 50B USDCB backed by only $50B in assets. So if there's a fork, a custodian will decide that the USDC on one chain is redeemable and the USDC on all other chains is not redeemable (i.e. worth zero), then other DeFi assets on the losing chain will go to ze…

Wouldn't a custodian have a potential conflict of interest here, picking a chain whose rules, say, give the custodian a recurring "management fee" to support their important role?

I don't think the Ethereum community cares about conflicts of interest.

Re: Ethereum London Mainnet Announcement

#69
post #68

Earlier quoted context omitted.

Wouldn't a custodian have a potential conflict of interest here, picking a chain whose rules, say, give the custodian a recurring "management fee" to support their important role?

I don't think the Ethereum community cares about conflicts of interest.

[deleted]

Re: Ethereum London Mainnet Announcement

#70

Will the miners accept 1559? It’s an optional space, miners are free to maintain the old chain and split. Of course this would be catastrophic. I know my history, this isn’t anything like the other times.

in reality, this is irrelevant in this case. all of the on/off ramps, applications, wallets, etc will point to the consensus chain. in the case where miner rewards are completely removed (ie the switch to PoS), then there are definitely some issues, and those issues are being worked on.
Post reply on HN