11 ms·

Ethereum Fork Fails on OpenEthereum

112 points by vecio 6y ago

axiosgunnar 6y ago
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?
- robinhoodexe 6y ago
  No. It’s “just” a client issue, and OpenEthereum is “only” used by ~11% of the nodes. I believe the former name is Parity, which had a major bug related to frozen coins some years ago. See https://mobile.twitter.com/etherscan/status/1382662485832994816 https://mobile.twitter.com/etherscan/status/1382662485832994...
  - DennisP 6y ago
    Although the frozen coins bug wasn't related to the Parity client itself. It was a smart contract multisig wallet made by the same company.
  - dcolkitt 6y ago
    Theoretically there’s a protocol standard, and every client implementation is equal. Functionally, whatever Geth does is the actual standard because a supermajority of nodes run Geth.
    - fjl 6y ago
      This is not true, and I can say that because I work on Geth. We take great care to ensure that all clients behave according to the specification, and Geth has had similar faults in the past.
      - joosters 6y ago
        Surely it doesn't matter what the specification says? If the majority of the hashpower is using an implementation which deviates from the spec, then the blockchain will follow that code and not the 'correct' version. By the time the devs have fixed the bugs, it will be too late and too costly to roll back the chain and reverse all the subsequent transactions.
        capableweb 6y ago
        In theory you're right, yes. If the majority of the hashpower runs a specific version with specific consensus rules, then that version of the chain would "win". But in reality, developers and others write the specification, which gets implemented in the clients and when a new version is available, the miners usually upgrade to the new version without any qualms what so ever. So in practice, the specification is what controls the network, as developers writing the clients implement things from the specification.
        joosters 6y ago
        I mean in terms of bugs, rather than a 'rogue' client, i.e. not a deliberate attempt to cause a chain divergence. If a 'broken' transaction gets accepted by a buggy client, and that buggy client has a majority of hash power, then that transaction is, by definition, not actually broken at all and everyone will be forced to accept it (because it will take too long to write a bug fix and re-write the blockchain history)
        splix 6y ago
        In practice if an "official" client has a different interpretation of the spec it must be accepted by other clients. Like with mentioned OpenEthereum (ex. Parity) here: https://github.com/openethereum/openethereum/blob/582bca385fedb1af682e989e5bcc6b3b2cf53028/crates/ethcore/types/src/transaction/transaction.rs#L1091 https://github.com/openethereum/openethereum/blob/582bca385f...
      - Canada 6y ago
        Can geth provide the same traces that OE does? I need to be able to detect when some internal tx sends ETH to one of my accounts and learn the txid...
    - yjftsjthsd-h 6y ago
      https://etherscan.io/nodetracker https://etherscan.io/nodetracker only shows 55% on geth; I wouldn't call that a super majority. EDIT: Actually, that page shows 15% on openethereum so we must be looking at different sources. Where did you get 11% on openethereum?
- COGlory 6y ago
  No, that was not in this fork, that one is slated for July. This fork was not contentious.
- yulaow 6y ago
  Reading the comments seems more like a technical problem on the consensus protocol of some implementation of eth nodes (in particular openethereum and geth)
- erwan 6y ago
  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 happened here: the OpenEthereum client (11% of the network) has had a bug following the Berlin hard-fork (network upgrade). Nodes runnning this client are stalling at a certain block because they don't recognize the new "post-Berlin" blocks as legitimate because of a bug in the implementation.
  - axiosgunnar 6y ago
    So are procotol-level changes announced ahead of time with a precise date when they get into force and the clients hard code that date as a transition? Or perhaps a block number is used?
    - nodja 6y ago
      Block number is used.
  - dogman144 6y ago
    So this is basically similar to segwit or taproot failing for btc? No idea how ethereum handles these roll outs.
    - zionic 6y ago
      Not at all. It’s like finding out Waterfox didn’t support HTTP3 well on release. Chrome and Firefox are still fine.
- bouncycastle 6y ago
  > Can somebody explain the significance? These were non-mining nodes, so they were not participating in consensus (block ordering). The chain did not split and nothing really happened, except cause a temporary outage of a "block explorer" website.
- vmception 6y ago
  It is only related to the Parity/OpenEthereum team continuing to have distractions on things more important to them like their own blockchain projects Nobody should be using their client software
joosters 6y ago
Fork = All NFT holders get another FREE copy of the nothing that they own!
arberx 6y ago
Back up and running: https://forkmon.ethdevops.io/ https://forkmon.ethdevops.io/ Might take a bit to sync
- fjl 6y ago
  It's not fixed yet, the OE instance in forkmon was syncing the whole time and hasn't hit the issue yet.
  - arberx 6y ago
    You sure? Thought it was in a failed state earlier? I think a block recently processed on OE, that's why it's showing as good. But yeah, don't think it's fixed yet.
    - fjl 6y ago
      The fix is in https://github.com/openethereum/openethereum/pull/364 https://github.com/openethereum/openethereum/pull/364 Actually, it's this commit of the PR: https://github.com/openethereum/openethereum/pull/364/commits/a49cc34d1ce353b2ab7d271dad70e8d81d5f11a3 https://github.com/openethereum/openethereum/pull/364/commit...
      - runeks 6y ago
        386 files changed? This has to include more than just the fix, right?
        deleted 6y ago
        [deleted]
        warp 6y ago
        Looks like they've extracted it to a separate hotfix PR here: https://github.com/openethereum/openethereum/pull/366 https://github.com/openethereum/openethereum/pull/366
vecio 6y ago
Fix https://github.com/openethereum/openethereum/pull/366 https://github.com/openethereum/openethereum/pull/366
seibelj 6y ago
My former employer (major exchange) switched from Parity / Openethereum after the last major issue. The Parity devs gave it up when they switched to focusing on Polkadot and the community is not super committed to it. Geth is the safer choice.
CryptoLich 6y ago
Fireblocks (massive institutional settlement platform for crypto-to-crypto and crypto-to-fiat transactions (like bank-size transactions) is on openethereum too -- all the settlements are completely backed up right now and tether is going really bid
throw4738 6y ago
Ethereum is THE fork. Original is called Ethereum Classic.
- jcpham2 6y ago
  You are getting downvoted but the internet has a very short memory. Ethereum's DAO fork and the ETC debacle is why your OG's don't support Ethereum.
- bpodgursky 6y ago
  As they say, the winners write the history books (and also the blockchains)
- baobabKoodaa 6y ago
  Nope, Ethereum was forked multiple times BEFORE that fork. So Ethereum Classic is not the "original" chain either (if by "original" you mean a chain that can be validated by running software from a time before the first fork).
deleted 6y ago
[deleted]
rfd4sgmk8u 6y ago
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://bitcointalk.org/index.php?topic=195.msg1611#msg1611 https://bitcointalk.org/index.php?topic=195.msg1611#msg1611 In ETH land, the wise guidance of Satoshi is regularly ignored.
- throwaway4good 6y ago
  So much for a protocol eh ...
- capableweb 6y ago
  "In a different blockchain they go by different rules" yeah no shit, of course. Ethereum is not Bitcoin because Ethereum doesn't want to be Bitcoin, otherwise Ethereum wouldn't have existed in the first place. That's like complaining that GCP is not following the advice of AWS "leaders", of course they are not gonna do that, otherwise they would work together, not on two different projects... Also, no matter what Satoshi wrote in 2010, multiple implementations of Bitcoin does exist today, most of them relatively stable: https://en.bitcoin.it/wiki/Clients https://en.bitcoin.it/wiki/Clients And the integrity of the network is not harmed by multiple clients either, just harms the users of that client, not other clients so not sure what the harm is. Yes, it's difficult, but so is a lot of problems in the cryptocurrency space.
  - uncletammy 6y ago
    > Ethereum is not Bitcoin because Ethereum doesn't want to be Bitcoin, otherwise Ethereum wouldn't have existed in the first place This isn't exactly true. Vitalik only created Ethereum because the new core devs ( Blockstream ) were actively limiting what types of things could be done with Bitcoin. They were moving away from programmable money in favor of "digital gold". Source: https://twitter.com/vitalikbuterin/status/929805462052229120?lang=en https://twitter.com/vitalikbuterin/status/929805462052229120... Here's a more detailed telling of the events by one of the Decred developers: https://old.reddit.com/r/decred/comments/6wxueo/your_best_pitch_for_decred/dmcer4d/ https://old.reddit.com/r/decred/comments/6wxueo/your_best_pi... TLDR: Ethereum actually does want to be Bitcoin but that's only because Bitcoin doesn't really want to be Bitcoin anymore. They've dumbed down their protocol. They've dumbed down their infrastructure. Hell, they've even managed to dumb down their users. Ethereum will make a fine Bitcoin.
deleted 6y ago
[deleted]
m00dy 6y ago
The problematic block https://hash.horse/0xac324366422b3ef181a3f62efd81eee6a3a887cf1ef7ce520d8a5ddc1a210f8e https://hash.horse/0xac324366422b3ef181a3f62efd81eee6a3a887c...
- Eduard 6y ago
  Currently says "We couldn't find anything"
  - m00dy 6y ago
    Then they might have fixed the block :). Hash horse is just an aggregator across blockchains
    - runeks 6y ago
      What? The problem was with a client implementation, not the block.
      - m00dy 6y ago
        How do you explain missing funds then ?
      - m00dy 6y ago
        There is a sync issue after this block. https://hash.horse/12244294 https://hash.horse/12244294
lucasnortj 6y ago
who cares, cryptos are a pointless invention used only by people who have nothing sensible to do with their lives
elwell 6y ago
Fix merged: https://github.com/openethereum/openethereum/pull/366#event-4600217874 https://github.com/openethereum/openethereum/pull/366#event-...
- justinzollars 6y ago
  well done
- yjftsjthsd-h 6y ago
  And 3.2.3 is now released to use that fix:)
fogof 6y ago
It seems the issue was in how OpenEthereum handled access lists introduced by EIP2929/2930. They were adding built-in contract addresses to access lists in blocks before those addresses were activated.

112 points by vecio 6y ago

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?

robinhoodexe 6y ago
No. It’s “just” a client issue, and OpenEthereum is “only” used by ~11% of the nodes. I believe the former name is Parity, which had a major bug related to frozen coins some years ago. See https://mobile.twitter.com/etherscan/status/1382662485832994816 https://mobile.twitter.com/etherscan/status/1382662485832994...
- DennisP 6y ago
  Although the frozen coins bug wasn't related to the Parity client itself. It was a smart contract multisig wallet made by the same company.
- dcolkitt 6y ago
  Theoretically there’s a protocol standard, and every client implementation is equal. Functionally, whatever Geth does is the actual standard because a supermajority of nodes run Geth.
  - fjl 6y ago
    This is not true, and I can say that because I work on Geth. We take great care to ensure that all clients behave according to the specification, and Geth has had similar faults in the past.
    - joosters 6y ago
      Surely it doesn't matter what the specification says? If the majority of the hashpower is using an implementation which deviates from the spec, then the blockchain will follow that code and not the 'correct' version. By the time the devs have fixed the bugs, it will be too late and too costly to roll back the chain and reverse all the subsequent transactions.
      - capableweb 6y ago
        In theory you're right, yes. If the majority of the hashpower runs a specific version with specific consensus rules, then that version of the chain would "win". But in reality, developers and others write the specification, which gets implemented in the clients and when a new version is available, the miners usually upgrade to the new version without any qualms what so ever. So in practice, the specification is what controls the network, as developers writing the clients implement things from the specification.
        joosters 6y ago
        I mean in terms of bugs, rather than a 'rogue' client, i.e. not a deliberate attempt to cause a chain divergence. If a 'broken' transaction gets accepted by a buggy client, and that buggy client has a majority of hash power, then that transaction is, by definition, not actually broken at all and everyone will be forced to accept it (because it will take too long to write a bug fix and re-write the blockchain history)
        splix 6y ago
        In practice if an "official" client has a different interpretation of the spec it must be accepted by other clients. Like with mentioned OpenEthereum (ex. Parity) here: https://github.com/openethereum/openethereum/blob/582bca385fedb1af682e989e5bcc6b3b2cf53028/crates/ethcore/types/src/transaction/transaction.rs#L1091 https://github.com/openethereum/openethereum/blob/582bca385f...
    - Canada 6y ago
      Can geth provide the same traces that OE does? I need to be able to detect when some internal tx sends ETH to one of my accounts and learn the txid...
  - yjftsjthsd-h 6y ago
    https://etherscan.io/nodetracker https://etherscan.io/nodetracker only shows 55% on geth; I wouldn't call that a super majority. EDIT: Actually, that page shows 15% on openethereum so we must be looking at different sources. Where did you get 11% on openethereum?
COGlory 6y ago
No, that was not in this fork, that one is slated for July. This fork was not contentious.
yulaow 6y ago
Reading the comments seems more like a technical problem on the consensus protocol of some implementation of eth nodes (in particular openethereum and geth)
erwan 6y ago
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 happened here: the OpenEthereum client (11% of the network) has had a bug following the Berlin hard-fork (network upgrade). Nodes runnning this client are stalling at a certain block because they don't recognize the new "post-Berlin" blocks as legitimate because of a bug in the implementation.
- axiosgunnar 6y ago
  So are procotol-level changes announced ahead of time with a precise date when they get into force and the clients hard code that date as a transition? Or perhaps a block number is used?
  - nodja 6y ago
    Block number is used.
- dogman144 6y ago
  So this is basically similar to segwit or taproot failing for btc? No idea how ethereum handles these roll outs.
  - zionic 6y ago
    Not at all. It’s like finding out Waterfox didn’t support HTTP3 well on release. Chrome and Firefox are still fine.
bouncycastle 6y ago
> Can somebody explain the significance? These were non-mining nodes, so they were not participating in consensus (block ordering). The chain did not split and nothing really happened, except cause a temporary outage of a "block explorer" website.
vmception 6y ago
It is only related to the Parity/OpenEthereum team continuing to have distractions on things more important to them like their own blockchain projects Nobody should be using their client software

joosters 6y ago

Fork = All NFT holders get another FREE copy of the nothing that they own!

arberx 6y ago

Back up and running: https://forkmon.ethdevops.io/ https://forkmon.ethdevops.io/ Might take a bit to sync

fjl 6y ago
It's not fixed yet, the OE instance in forkmon was syncing the whole time and hasn't hit the issue yet.
- arberx 6y ago
  You sure? Thought it was in a failed state earlier? I think a block recently processed on OE, that's why it's showing as good. But yeah, don't think it's fixed yet.
  - fjl 6y ago
    The fix is in https://github.com/openethereum/openethereum/pull/364 https://github.com/openethereum/openethereum/pull/364 Actually, it's this commit of the PR: https://github.com/openethereum/openethereum/pull/364/commits/a49cc34d1ce353b2ab7d271dad70e8d81d5f11a3 https://github.com/openethereum/openethereum/pull/364/commit...
    - runeks 6y ago
      386 files changed? This has to include more than just the fix, right?
      - deleted 6y ago
        [deleted]
      - warp 6y ago
        Looks like they've extracted it to a separate hotfix PR here: https://github.com/openethereum/openethereum/pull/366 https://github.com/openethereum/openethereum/pull/366

vecio 6y ago

Fix https://github.com/openethereum/openethereum/pull/366 https://github.com/openethereum/openethereum/pull/366

seibelj 6y ago

My former employer (major exchange) switched from Parity / Openethereum after the last major issue. The Parity devs gave it up when they switched to focusing on Polkadot and the community is not super committed to it. Geth is the safer choice.

CryptoLich 6y ago

Fireblocks (massive institutional settlement platform for crypto-to-crypto and crypto-to-fiat transactions (like bank-size transactions) is on openethereum too -- all the settlements are completely backed up right now and tether is going really bid

throw4738 6y ago

Ethereum is THE fork. Original is called Ethereum Classic.

jcpham2 6y ago
You are getting downvoted but the internet has a very short memory. Ethereum's DAO fork and the ETC debacle is why your OG's don't support Ethereum.
bpodgursky 6y ago
As they say, the winners write the history books (and also the blockchains)
baobabKoodaa 6y ago
Nope, Ethereum was forked multiple times BEFORE that fork. So Ethereum Classic is not the "original" chain either (if by "original" you mean a chain that can be validated by running software from a time before the first fork).

deleted 6y ago

[deleted]

rfd4sgmk8u 6y ago

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://bitcointalk.org/index.php?topic=195.msg1611#msg1611 https://bitcointalk.org/index.php?topic=195.msg1611#msg1611 In ETH land, the wise guidance of Satoshi is regularly ignored.

throwaway4good 6y ago
So much for a protocol eh ...
capableweb 6y ago
"In a different blockchain they go by different rules" yeah no shit, of course. Ethereum is not Bitcoin because Ethereum doesn't want to be Bitcoin, otherwise Ethereum wouldn't have existed in the first place. That's like complaining that GCP is not following the advice of AWS "leaders", of course they are not gonna do that, otherwise they would work together, not on two different projects... Also, no matter what Satoshi wrote in 2010, multiple implementations of Bitcoin does exist today, most of them relatively stable: https://en.bitcoin.it/wiki/Clients https://en.bitcoin.it/wiki/Clients And the integrity of the network is not harmed by multiple clients either, just harms the users of that client, not other clients so not sure what the harm is. Yes, it's difficult, but so is a lot of problems in the cryptocurrency space.
- uncletammy 6y ago
  > Ethereum is not Bitcoin because Ethereum doesn't want to be Bitcoin, otherwise Ethereum wouldn't have existed in the first place This isn't exactly true. Vitalik only created Ethereum because the new core devs ( Blockstream ) were actively limiting what types of things could be done with Bitcoin. They were moving away from programmable money in favor of "digital gold". Source: https://twitter.com/vitalikbuterin/status/929805462052229120?lang=en https://twitter.com/vitalikbuterin/status/929805462052229120... Here's a more detailed telling of the events by one of the Decred developers: https://old.reddit.com/r/decred/comments/6wxueo/your_best_pitch_for_decred/dmcer4d/ https://old.reddit.com/r/decred/comments/6wxueo/your_best_pi... TLDR: Ethereum actually does want to be Bitcoin but that's only because Bitcoin doesn't really want to be Bitcoin anymore. They've dumbed down their protocol. They've dumbed down their infrastructure. Hell, they've even managed to dumb down their users. Ethereum will make a fine Bitcoin.

deleted 6y ago

[deleted]

m00dy 6y ago

The problematic block https://hash.horse/0xac324366422b3ef181a3f62efd81eee6a3a887cf1ef7ce520d8a5ddc1a210f8e https://hash.horse/0xac324366422b3ef181a3f62efd81eee6a3a887c...

Eduard 6y ago
Currently says "We couldn't find anything"
- m00dy 6y ago
  Then they might have fixed the block :). Hash horse is just an aggregator across blockchains
  - runeks 6y ago
    What? The problem was with a client implementation, not the block.
    - m00dy 6y ago
      How do you explain missing funds then ?
    - m00dy 6y ago
      There is a sync issue after this block. https://hash.horse/12244294 https://hash.horse/12244294

lucasnortj 6y ago

who cares, cryptos are a pointless invention used only by people who have nothing sensible to do with their lives

elwell 6y ago

Fix merged: https://github.com/openethereum/openethereum/pull/366#event-4600217874 https://github.com/openethereum/openethereum/pull/366#event-...

justinzollars 6y ago
well done
yjftsjthsd-h 6y ago
And 3.2.3 is now released to use that fix:)

fogof 6y ago

It seems the issue was in how OpenEthereum handled access lists introduced by EIP2929/2930. They were adding built-in contract addresses to access lists in blocks before those addresses were activated.