search

openethereum / parity-ethereum

The fast, light, and robust client for Ethereum-like networks.
Other
6.83k stars 1.68k forks source link

Ethereum Classic (ETC) is stuck on syncing when using OpenEthereum v3.0.1 #11843

Closed gituser closed 4 years ago

gituser commented 4 years ago

My client is stuck syncing on block #10908537

2020-08-02 14:01:45  IO Worker #1 INFO import  Syncing #10908537 0xb7e6…2d65     0.00 blk/s    0.0 tx/s    0.0 Mgas/s      0+    0 Qed  #10908506   15/50 peers      5 MiB chain  130 MiB db  0 bytes queue   20 MiB sync  RPC:  0 conn,    0 req/s,   26 µs

Comparing with ethercluster I can see I'm on the shorter chain for some reason:

ethercluster.com last block: 10915386
local last block: 10908537

What is going on with the support lately?

Do you drop ethereum classic support completely? -- see https://github.com/openethereum/openethereum/pull/11821

I see there is other issue (https://github.com/openethereum/openethereum/issues/11842) being closed without any explanation how to fix this issue with the split?

I've been a parity / openethereum user for 4 years and contributed a lot to the client and I'm sure there are many others just like me who have been using parity and integrated it in their production environments and switching to other client might be not very trivial.

Why not provide users with the support on how to resolve this issue and admit that there is something wrong with the client as was the last time when you've released version v3.0.1 to fix similar issue for ETC.

gituser commented 4 years ago

I've found this post https://that.world/~classic/2020/06/10/deprecate/ by googling a bit and now it's more clear to me why you discontinue ethereum classic support.

EDIT: I propose to remove classic entirely if it's not supported from everywhere - documentation, cli options, etc. Also you should add this somewhere on the github as well and in the documentation more clearly why you've removed support for ETC entirely. Apparently this has been done already - https://github.com/openethereum/openethereum/pull/11821

I have another question as well: who is maintaining the OpenEthereum project right now and making important decisions about it's future?

gituser commented 4 years ago

For those who still want to support ETC network: you need to migrate to Besu (https://besu.hyperledger.org) or Core-Geth (https://github.com/etclabscore/core-geth) from OpenEthereum.

quyse commented 4 years ago

Apparently OpenEthereum is still perfectly capable of running on ETC network: I got an OpenEthereum node synced from scratch to the correct chain, with warp sync disabled (more precisely, it had tracing feature enabled, which in turn disables warp sync). On the other hand, another node with enabled warp sync, synced from scratch and got on the wrong chain, the same as other (continuously running) OpenEthereum nodes got stuck at.

So it appears the warp sync has consensus issues, but normal syncronization performs correctly.

This may be useful for those who relies on OpenEthereum and cannot quickly switch to other node implementation. (I guess we'll have to do the switch eventually anyway, given the projects's stance).

gituser commented 4 years ago

@quyse thank you for the info, I have the node with warp syncing disabled and with tracing = on, but it's still stuck. I guess I have to try and resync it from scratch for the time being. Doesn't guarantee though that this situation might happen again or worse if it would happen on the ETH network.

quyse commented 4 years ago

@gituser Yeah, our nodes were stuck too, we had to resync from scratch. My understanding is that fully synced OpenEthereum nodes (which have been running at the moment when the alternative chain was revealed) were not able to switch to that chain simply because state of the diverging block was pruned long time ago (depth of the reorg was ~3700 blocks, but default number of states to keep is only 64 from the top). So to sync correctly the node must start from a height less than 10904147 (first diverging block) plus value of pruning_history param (that is, 64 by default).

It seems wise to configure pruning_history=10000 or similar, in anticipation of possible future reorgs.

Although not sure why CoreGeth/Besu nodes were able to reorg correctly, don't they do state pruning too?

gituser commented 4 years ago

@quyse big --pruning-history value takes a lot of memory, e.g. with 10000 I had multiple OOMs on a box with 16GB memory.

There was another reorganization on ETC recently at block 10935622 and exchanges shut down deposits and withdrawals.

quyse commented 4 years ago

@gituser

There was another reorganization on ETC recently at block 10935622 and exchanges shut down deposits and withdrawals.

Yeah, and I can confirm all of our OpenEthereum nodes correctly handled it automatically this time.

big --pruning-history value takes a lot of memory, e.g. with 10000 I had multiple OOMs on a box with 16GB memory.

Well it can't be helped I guess. We just use dedicated servers with lots of RAM. Although it may be only an issue during initial synchronization, there were several tough spots in ETC history - you may try to sync with default pruning_history value until more recent times. Currently I can see that our ETC nodes consume around 5 Gb RAM each.

gituser commented 4 years ago

@quyse

Yeah, and I can confirm all of our OpenEthereum nodes correctly handled it automatically this time.

For me it's not.. I finally got it re-synced and it's stuck at #10918907.

2020-08-06 21:18:12  IO Worker #2 INFO import  Syncing #10918907 0xb3d2…3360     0.00 blk/s    0.0 tx/s    0.0 Mgas/s      0+    0 Qed  #10904155    6/25 peers      6 MiB chain    1 GiB db  0 bytes queue   52 MiB sync  RPC:  0 conn,    0 req/s,    0 µs

Does it work for you now?

quyse commented 4 years ago

@gituser Yes, it is working for me now.

gituser commented 4 years ago

@quyse what's block you're on?

Are you using OpenEthereum/v3.0.1-stable-8ca8089-20200601/x86_64-unknown-linux-gnu/rustc1.43.1 ?

Weird, my node isn't working properly.

stevanlohja commented 4 years ago

We had OpenEthereum and Parity clients of families fail in cross-client testing. You should use https://core-geth.org/ for Ethereum Classic.

quyse commented 4 years ago

@gituser our nodes are up to date, at the same block as https://blockscout.com/. We are using our docker image coinmetrics/fullnode:openethereum-3.0.1 (on Docker Hub).

@stevanlohja Well, yes, everybody keeps telling what we should use without mentioning technical details, but it's not really helping, sorry. I get that eventually we'll have to switch to Geth, but we rely on OpenEthereum-specific APIs, so the switch will take effort. Also we used to run Geth in the past, and Parity (back then) compared much better in terms of stability and performance.

To me it seems there's only two real (technical) issues with OpenEthereum for ETC at the moment:

With warp sync disabled and pruning_history=10000 we got OpenEthereum ETC nodes synced from scratch in ~50 hours, and then all our nodes successfully processed the 4000 blocks reorg of August 5th attack.