Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ethereum Fork Fails on OpenEthereum

github.com

Post reply on HN
Print view View original

41–50 of 108 posts

Re: Ethereum Fork Fails on OpenEthereum

#41

Post by derefr »

thinkmassive wrote: post #34
rfd4sgmk8u wrote: post #28

Satoshi wrote in 2010: "I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint." https://bitcoint…

bitcoind is the most used implementation by far, but there are others that work fine, like btcd The more significant difference seems to be Ethereum is far more complicated (a Rube Goldberg machine, as critics like to say) and has trouble coordinating hard forks. A hard fork of Bitcoin is considered a different network, so it’s no longer an issue.

The real problem with Ethereum client code, is that almost everyone just starting to work on it — and even some people who've been at it for a while — are under the mistaken belief that Ethereum itself is a 100% formalized system, because the Yellow Paper formalizes the behavior of the EVM. They think that as long as their EVM follows the spec, they can't possibly accidentally calcluate a wrong state and end up out-of-consensus with the network.

However, there are (many!) stateful things that happen during Ethereum block-ingestion that occur outside of contract bytecode execution (i.e. not modelled by the EVM abstract-machine.) So even if you implement your EVM "to spec", there's this whole surrounding edifice of block-processing code that has no spec, that everyone's just guessing and "following the leader" on.

IMHO Ethereum badly needs a "Yellow Paper 2" that takes a step back and formalizes the whole block validation+execution flow. On top of that, there could be a C FFI spec for implementations of a "block processor" to follow, with type declarations for the ADTs such a library would consume/produce — making them into, essentially, plugin libraries (where any Ethereum node implementation could plug in any Ethereum block processor engine implementation.) Think "web browser" vs. "rendering engine" (where the "scripting engine" — i.e. the EVM — is just one part of the "rendering engine.")

If such a formal block-processor plugin interface existed, an Ethereum "node" could then just consist of the storage engine, the consensus engine's policy layer (while needing to rely on standardized consensus machinery existing within the block-processor), the P2P protocols, and the RPC backend. I.e., infrastructure code.

Powerfully, this would mean that networks that are essentially forks of Ethereum or which embed an Ethereum node in their network architecture (i.e. everything listed on https://chainid.network/) could all just link in an up-to-date upstream block-processor engine — rather than drifting away from it just because they've necessarily forked the storage+consensus+p2p+rpc code.

Re: Ethereum Fork Fails on OpenEthereum

#42

Post by dogman144 »

shawnz wrote: post #38
rfd4sgmk8u wrote: post #28

Satoshi wrote in 2010: "I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint." https://bitcoint…

> the wise guidance of Satoshi is regularly ignored. They are basically producing a competing product. Why should they ought to copy the exact formula of their competitors? How can they hope to be better than Bitcoin by doing everything the same way?

I don't think you could call ethereum a competing product, it works fairly differently in a lot of fundamental ways. UDP vs. TCP is more accurate IMO, and those two don't really compete.

Re: Ethereum Fork Fails on OpenEthereum

#43

Post by dogman144 »

erwan wrote: post #8
axiosgunnar wrote: post #2

Can somebody explain the significance? Is this related to the conflict between devs and miners where devs want to reduce the mining fees and miners responded by creating a fork?

Ethereum has different client software, they must all use the same consensus rules: produce/gossip/accept transactions and blocks that follow a certain format and respect certain invariants. When that specification is updated, a hard-fork occurs. It's not a problem if all clients meet the new spec perfectly but sometimes bug happens and different clients disagree on what constitutes the canon chain. This is what happ…

So this is basically similar to segwit or taproot failing for btc? No idea how ethereum handles these roll outs.

Re: Ethereum Fork Fails on OpenEthereum

#45

Post by rfd4sgmk8u »

dogman144 wrote: post #37
rfd4sgmk8u wrote: post #28

Satoshi wrote in 2010: "I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint." https://bitcoint…

Is there some central aggregation point of ~everything (or in that spirit) that SN wrote, across all the various forums and such? I feel like I finally need to dig in and read all of that.

https://satoshi.nakamotoinstitute.org/quotes/

Re: Ethereum Fork Fails on OpenEthereum

#46

Post by AgentME »

makomk wrote: post #20
fjl wrote: post #13

Earlier quoted context omitted.

The fix is in https://github.com/openethereum/openethereum/pull/364 Actually, it's this commit of the PR: https://github.com/openethereum/openethereum/pull/364/commit...

Looks like some really subtle and (as far as I can tell) undocumented aspect of Ethereum internals tripped them up.

They didn't properly implement EIP-2929 (https://eips.ethereum.org/EIPS/eip-2929). I looked at the first section of the code diff in the PR and it matched up with stuff already documented in the EIP, so I wouldn't assume the issue was because of undocumented stuff. Multiple other Ethereum implementations managed to implement the EIP-2929 spec correctly.

Re: Ethereum Fork Fails on OpenEthereum

#47

Post by nivexous »

dogman144 wrote: post #37
rfd4sgmk8u wrote: post #28

Satoshi wrote in 2010: "I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint." https://bitcoint…

Is there some central aggregation point of ~everything (or in that spirit) that SN wrote, across all the various forums and such? I feel like I finally need to dig in and read all of that.

Bitcoin.com has the Satoshi Archive (https://www.bitcoin.com/satoshi-archive/) with all his emails and forum posts. Satoshi wanted big blocks, and so BTC largely ignores him or says "We are all satoshi", but there is a ton of wisdom if you go back and read. This was put together by Derek Magill, who is also a good person to follow on Twitter.

Re: Ethereum Fork Fails on OpenEthereum

#48

Post by zionic »

dogman144 wrote: post #43
erwan wrote: post #8

Earlier quoted context omitted.

Ethereum has different client software, they must all use the same consensus rules: produce/gossip/accept transactions and blocks that follow a certain format and respect certain invariants. When that specification is updated, a hard-fork occurs. It's not a problem if all clients meet the new spec perfectly but sometimes bug happens and different clients disagree on what constitutes the canon chain. This is what happ…

So this is basically similar to segwit or taproot failing for btc? No idea how ethereum handles these roll outs.

Not at all. It’s like finding out Waterfox didn’t support HTTP3 well on release. Chrome and Firefox are still fine.

Re: Ethereum Fork Fails on OpenEthereum

#49

Post by uncletammy »

rfd4sgmk8u wrote: post #28

Satoshi wrote in 2010: "I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint." https://bitcoint…

In BTC, the wise guidance of Satoshi is also regularly ignored.

Here are a few examples

Satoshi's Guidance: Bitcoin should function as cash

Source: https://bitcoin.com/bitcoin.pdf ( See the title )

Satoshi's Guidance: We shouldn't be limiting transaction capacity to accommodate low performance client hardware

Source: https://bitcointalk.org/index.php?topic=532.msg6306#msg6306

Satoshi's Guidance: The blocksize limit should be removed to maximize network capacity. The limit was only meant to be temporary.

Source: https://bitcointalk.org/index.php?topic=1347.msg15366#msg153...

EDIT: formatting

Post reply on HN