Finalizing the 0.26.0 Release by performing some “housekeeping”.
Last week, we decided to deviate from our typical release schedule, which is one release every two weeks, and spend a little more time finalizing Release 0.26.0, our second release candidate. We aim to release the finalized version this week.
Over the past week, we have achieved the following milestones:
We were able to identify several scenarios that could negatively impact the performance of æternity nodes:
- We’ve noticed, that when syncing multiple micro blocks in a row, the database seems to be unable to keep up. The disk access is the slow part. When running with persist: false, the database is 5 to 10 times faster. Even better, when we switch off mining, things get even faster. To solve this problem, we will allow nodes to mine only if they are in sync with the rest of the network. To be more specific, we have N peers configured to sync against. If we are much behind those nodes, then mining is rendered infeasible. It is important to note that we cannot just “not mine” if a node claims to be far ahead of ours. We need to align it with the trusted nodes we do have contact with (unreachable nodes are not of interest). This can be mitigated by consulting with trusted peers we have contact with; if they have a median height that is aligned with ours, we can start mining. If the median is five below ours, we should stop mining.
- Syncing and mining in parallel can significantly reduce node performance. This is because mining keeps all CPU cores busy, leaving limited resources that the node can dedicate to the syncing task. The solution is quite simple: keep one CPU out of mining. Currently, we have a flag -t N to set the threats we use for mining. We ensure that, no matter what this flag says, we never use an N larger than Number of CPU cores — 1. That means we have one CPU free for activities other than mining.
We have also performed several updates to our mining core-implementation of the Cuckoo Cycle:
- We brought æternity’s Cuckoo mining implementation up to date with the implementation provided by John Tromp, the inventor of the Cuckoo Cycle.
- We have introduced a small tweak into Cuckoo implementation, in order to make it more difficult to build ASICs for æternity blockchain.
- In addition, we have fixed a number of bugs and introduced several minor features. See the Pivotal Tracker for more details.
Finally, æternity developers teamed up with renowned experts in cryptography, distributed systems, game theory, programming languages, and system security techniques by joining the Initiative For Cryptocurrencies & Contracts (IC3). Learn more about this exciting news here:
Interested in æternity? Get in touch: