Closed gituser closed 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?
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.
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).
@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.
@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?
@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.
@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.
@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?
@gituser Yes, it is working for me now.
@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.
We had OpenEthereum and Parity clients of families fail in cross-client testing. You should use https://core-geth.org/ for Ethereum Classic.
@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:
pruning_history
param (64) is too low to handle reorgs that deepWith 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.
My client is stuck syncing on block #10908537
Comparing with
ethercluster
I can see I'm on the shorter chain for some reason: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.