Edit, since this was hidden by community flags: this is a valid EIP and I am actively pursuing it. This is not off-topic (despite the punny name)! Thank you for your understanding.
It is impossible for Ethereum to literally “go to the moon” due to a limitation in the protocol: the block length. Should validators attempt to validate on the surface of the moon, they would find that the ~1.25 second communication delay (caused by the speed of light) is might cause issues with synchronization, considering the 12-second timer between blocks. The validators would find themselves slashed on the terrestrial chain, and validating their own fork.
happy april fools’ day the problem would be even graver for EVM-compatible chains with shorter blocktimes, 2s is quite common
does speed of light really require 1.25s to get from earth to the moon though, sounds a bit too much too lazy to do the maths though
Yes, it does, meaning that it takes ~2.5s for a round trip.
The distance is $384400 km=384400000 m$, and the speed of light is $299792458 \frac{m}{s}$, so the time is: $\frac{384400000 m}{299792458 \frac{m}{s}}=1.2822203819 s$
It’s worth noting that this is both a “joke” proposal and one I’m legitimately interested in pursuing. I feel like there are many good reasons to increase the block length.
If we achieve interstellar travel, the communication delay will become longer. Increasing the block length cannot completely solve the latency problem.
Yeah, exactly wouldn’t be any issues blocklength-wise adding a 3s round trip - unless that extended round trip + the inevitable modem comms ping interferes with the client initialisation/sync. Wonder what timezone the moonbase would be using? UTC? That’s a whole other source of pain for future devs!
Lets scale up the problem to its theoretical limits:
Suppose an infinite plane with evenly distributed nodes spaced 1km apart. Design a consensus mechanism that allows multiple light cone consensus silos to communicate.
The best part is that humanity will for sure face a similar problem some day (assuming no extinction, and causality is limited by C)
I must admit that I was one of the persons who submitted a report to this post. Did not think this was a half-way serious issue and I apologize.
Would it make sense to name the EIP to something like “Ethereum to the Moon and Back!” to indicate that it is not just a meme, but also that it relates to the round trip time?
the problem would be even graver for EVM-compatible chains with shorter blocktimes, 2s is quite common 
too lazy to do the maths though 
just need to add an EVM to it so it’s a bit more useful …
) has a EVM-compatible L2, would have loved that for BTC too
wouldn’t be any issues blocklength-wise adding a 3s round trip - unless that extended round trip + the inevitable modem comms ping interferes with the client initialisation/sync. Wonder what timezone the moonbase would be using? UTC? That’s a whole other source of pain for future devs!