Help Needed: Recovery from 51% Attack Mitigation

We’re developing Email to scale: Getting to real-world usage for aeternity and as recommended are running our own node for that.

As far as I understand from the posts here, and the Telegram group, there was a 51% attack a few weeks ago (Notice regarding the recent attack) and the attacker used the proceeds from this attack ( to fund another 51% attack yesterday.

In response, aeternity Anstalt has been working with the mining pools to roll back the chain and re-start mining with higher hash power in order to win the mining battle against the attacker.

As a result, our service has been having issues for around 24 hours writing transactions and we’re concerned our node may still be on the attackers branch.

Are there any instructions for how to recover our node from this state?

Starting a new node from scratch took ~2 days last time, and we would really prefer not to have that kind of backlog for our transactions. So any advice on how to proceed would be much appreciated.

What do we need to do in order to get our node onto the correct chain?

Thank you so much for any help you might be able to provide and all your hard work! :pray:


Any advice please @gorbak25 ? :pray:

1 Like

There are a bunch of options available:

  1. Wait for the official 5.6.3 release which will FORCE you on the correct chain.
  2. Download the 5.6.2 pre release and start a node with a DB snapshot from
  3. Download the 5.6.2 and manually force the node to the correct chain using an erlang console

Thank you for the response, @gorbak25! :pray:

Follow-up question: Is there anything we can do with version 5.2 to get back on track?

Background: We have been stuck on 5.2 for the last months, because that is the last version that supports the OpenPOWER architecture, which is currently the only Open Hardware architecture that follows the principle of security by transparency, auditability, no hidden management engines or backdoors.

It is also really strong for cloud applications, and has a lot of Hardware Security benefits with its pluggable OpenCAPI interfaces.

There is even a secure workstation available for it:

TL;DR: OpenPOWER is the only hardware architecture that actually follows the principles of user control, security, trust, privacy of aeternity, blockchain in general, and Vereign.

Since IBM acquired Red Hat, it is also fully supported and a primary choice for the entire OpenShift & Cloud platform across a lot of major companies.

Unfortunately, aeternity nodes above version 5.2 fail to build on POWER hardware, due to their dependency on and we also had to patch to get it to compile and run.

The latter is something we would happily contribute upstream, but MCL is not something we can do anything about, unfortunately. We’re right now considering to bring up an up to date node on Intel, but it’s definitely not our preferred choice.

Hence the question: Is there anything we can do with version 5.2 to get back on track?

1 Like

Please open an issue regarding POWER compatibility in our GH repositories - now that we know that we have POWER users we can prioritize accordingly and ensure compatibility.
Unfortunately backporting the community fork patches for 5.2 is not straightforward as between 5.5 and 5.6 we did some major refactoring in preparation for Hyperchains - I can do it but only after the 5.6.3 release is fully tested.
Keep in mind that after some time(few days) the attacker will get outmined and your node will automatically switch over to the community fork.


Hello, @gorbak25 about 51 attacks, thank you for what you did. After Hyperchains goes online, as a pos, will the tps of the AE mainnet increase? As a Pow coin 116tps is our pride, if pos coin does not increase tps, I think we have no advantage. Do you agree?


This release requires the node to be running without the GC being enabled. If your node has it enabled - the DB is not suitable and your node will likely crash on start. In this case please either sync from the genesis block or download a DB backup. Once on the community fork - you can enable the GC.

Please join the mainnet by following the instructions in the documentation attached on the Release link, and let us know if you have any problems by opening a ticket. Troubleshooting of common issues is documented in the wiki.


Thank you for all the information!

Just pulled down and tried starting a node on my server at home but got:

Corruption: Snappy not supported or corrupted Snappy compressed block contents

as error during startup. So tried starting fresh from genesis block. Sync now seems to be running fine.

1 Like



Let me C&P something here:

WARNING: Our builder bot built the release docker image with one build flag missing and our CI pipeline missed this. As a result the current 5.6.3 docker image on dockerhub is unable to open pre 5.6 databases. We noticed the issue now and will improve our CI pipeline for this to never happen again.
If you want to upgrade to 5.6.3 and are operaring a docker node then please wait for a docker image which will appear soon on dockerhub!

If you are using a standalone release(not the docker image) then you are not affected.

Either docker pull aeternity/aeternity:v5.6.3.1 or wait for 5.6.4 which contains one SDK fix + the docker build fix:

Understood. Apologies, did not see that earlier.

Meanwhile my own node is fully synchronised and running - but now we’re running into

Is this going to be a priority fix? We are blocked until the SDK works again.