[News] Release 5.6 Delay

aeternity Foundation Roadmaps and Announcements
, , ,
1

Due to the recent hackers attack the planed Release 5.6 is delayed and reschedule to the beginning of January with a release date the 10.01.2021.
On the 18.12.2020 only a release candidate 5.6 will be published including the following important features:

  • Networks Health Monitoring Improvement: Enhances the p2p noise protocol with an optional setting to ask a peer for the version of their node. A node operator can set one’s node to not respond to this message if one considers this a private information.

  • FSM Behavior Improvement: Enhance FSM behavior so that when the initiator is offline the responder is allowed to stay online waiting for it even if the timeout timer is reached.

  • Configurations Improvement: Configuration values can now be set using OS environment variables, where the environment variable name is on the form AE__k1__k2, e.g. AE__CHAIN__PERSIST=true. Note that two underscores are used to separate each level. Structured values must be JSON-encoded. The prefix AE can not be customized. The environment variables are applied after reading an available config file, and all values are checked against the schema. See docs/configuration.md.

  • Peer Pool Persistence Improvement: Introduces persistence of the peer pool so that if the node flag for disc persistence is set, after a node restarts, the old peers are loaded from the DB. Trusted peers are provided to the node from the config file so they are already persisted. Since the time being off is unknown, all peers are loaded as unverified, even if they had been verified before the node stop.

  • Speed Up Improvement: The default value is changed and significantly speeds up of the TCP probes is achieved. Those used to be done roughly once every 2 minutes while now they are executed every second. Note that this is done only if there are peers to be checked. If a peer is missing, there is a grace period in which it is marked as ‘suspended’, waiting for its return. If all peers are checked, we wait longer until either a new peer is added or a not-suspended peer is there. Basically, the probes come on demand. Even despite the probes are fast, there is a maximum size of currently ongoing probes.

  • Verified Peers Process Improvement: The process of probing verified peers has been improved. Until now we were probing only unverified peers. If a peer responds to the probe we consider it verified. We downgrade a verified peer only after we fail connecting to it. This resulted in amounting peers that used to be verified at one point of time. This can be improve when we probe verified peers as well. Even more this PR plays really well with PR #3365. This implies that if a peer goes down, we will find it significantly sooner and will downgrade it as an unverified one. This is important as a node shares to other nodes only peers one considers to be verified.

  • Chain Event Reporting: Added support for reporting chain events during contract evaluation. These events are published internally as ‘tx_events’ (available e.g. for plugins), and can also be fetched via the HTTP ‘dry-run’ method. The events are presented as ‘dummy’ transactions, unsigned, reflecting the details of the respective events.

  • Trusted Peers Bug Fixing: There are special trusted peers that are never deleted nor downgraded. Those peers are quite unique as the node considers them to be available. One can pick their own set of trusted peers but this was not really effective: the default peers were always included as a bonus. This PR is now fixed so that if the new config flag is set to false then the defaults are omitted. The flag is called include_default_peers and by default set to be true.

  • Removed Duplicated Peers Copies: There used to be multiple copies of the same peers in peers pool. This resulted in propagation of same peers with different Peer IDs through the network. Now duplicates are cleaned up.

  • Peers Fine Tuning: We used to treat peers that refuse connecting to us as they were malicious. This was the case no matter if peers were active and part of the network and only simply refusing to open a enoise connection to our node (most likely because their inbound pool is saturated already). This is now changed and if the node is responding but refusing to open an enoise connection - we consider it still a valid and a verified participant of the network.

  • Sync’s Peer Propagation Improvement: Peers are split into verified and unverified. We had allowed a grace period for peers to be down while the node still considers them as verified and broadcasts them as such. Once a verified peer is being detected as down, it enters a standby state that allows them to stay verified. This PR tightens the process and once a peer is being detected to be unreachable then it is being downgraded from verified to unverified immediately. The processing of unverified being deleted is left unchanged and they still enter the standby mode for a few times before being removed.

The full list of features included can be found in the Release Note of the Release 5.6.0 Candidate. Here were just the important ones presented.

AF thanks the core and hyperchain developers for supporting the exchanges in the research of the attack and finding a solution to protect the ae users.
Some of the presented feature reflect the need to monitor and protect the aeternity blockchain from hackers attacks.

16 Likes