Skip to content

Bern v5.0.0
Compare
Choose a tag to compare
@sanada08 sanada08 released this 19 Dec 06:53
· 58 commits to master since this release
v5.0.0
930a37c
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Verified
Learn about vigilant mode.

Mandatory Update

Overview

Bern 5.0.0 signifies a pivotal hard fork release for the Mainnet, slated to occur at block 2986890, approximately on January 29th, 2024, at 05:30:00 AM UTC. It is imperative for all Master Node operators to complete the upgrade to version 5.0.0 prior to reaching block 2986890, as failure to do so will result in their decommissioning and deregistration by the network.

In conjunction with the version upgrade, Master Node operators must integrate Beldex Storage Server version 2.3.0 and Belnet version 0.9.7 into their configurations. Both the storage server and Belnet play indispensable roles in the optimal operation of the master node. The absence of these essential components exposes Master Node operators to the risk of decommissioning and deregistration.

To underscore, the upgrade requirement extends beyond transitioning to version 5.0.0; it specifically encompasses the incorporation of Beldex Storage Server version 2.3.0 and Belnet version 0.9.7. Strict adherence to these specifications is paramount to preserving the operational viability of Master Nodes. Any deviation from these directives carries the serious consequence of decommissioning and deregistration from the network.

Major Features

BNS Belnet Namespace:

With the initiation of hard fork 18, the Belnet namespace becomes accessible for name registration within the BNS. Interested parties can procure Belnet names for durations of 1, 2, 5, or 10 years, and these registrations are open for renewal at any point, subject to specific burn requirements outlined below:

Year(s): Beldex Burn Requirement:
1 : 650
2 : 1000
5 : 2000
10 : 4000
Belnet names are available for purchase through the CLI wallet using a command like:

bns_buy_mapping mybnsname.bdx 96ttn1fk9hxreihi7nzafhyb4nmw74pjqa5a49w8k1kfzfmec5dy.bdx

For additional assistance, such as making a multi-year purchase, users can refer to the guidance provided by executing help bns_buy_mapping within the wallet.

BNS Lighter Encryption/Pricing Update:

The encryption methodology for records in BNS has undergone a refinement, adopting a swifter and more resource-efficient scheme. It is strongly recommended that BNS records be updated to leverage this improved method. The upgrade can be executed on a per-name basis to enhance the encryption scheme using the CLI wallet, as illustrated by the following command:

bns_update_mapping <record name>

For further assistance, users can refer to the guidance available through help bns_update_mapping in the wallet.

Notably, the wallet now has the capability to retain names that users have registered, contributing to a more user-friendly experience.

BNS wallet registrations

With the onset of the hard fork, users can initiate the process of registering BNS wallet names, exemplified by names like "tucci.bdx," which are linked to corresponding wallet addresses (e.g., "Bxdyujsdf..."). This registration enables users to employ the registered short name instead of their considerably longer wallet address. Initially, these names are functional only when utilizing a "trusted" beldexd, typically a local instance, ensuring heightened security. However, ongoing efforts are underway to develop wallet enhancements that will extend secure usability to all wallets in the future.

Similar to Bchat names, the registration of wallet names incurs a one-time fee. Importantly, these fees are non-expiring, providing users with a persistent and convenient alternative to their lengthy wallet addresses.

Master nodes now periodically send the time around to other master nodes, to help operators diagnose when time may be out of sync. (Being too far out of sync can be a cause for master node deregistration as master nodes will be unwilling to participate in flash quorums or accept new blocks).

Decommissions and deregistrations now include a "reason" flag in the decommission/deregistration transaction: this indicates why the quorum decided to decommission or deregister a node which can be extremely helpful diagnosing potential problems. One of the most common questions when a deregistration happens is "why did this happen?" and it is often guesswork to figure it out: but with Bucephalus you can now see the reason(s) by just looking up the decommission transaction.

Storage server's interaction with beldexd is completely rewritten, in particular with respect to storage server testing. Storage server now reports test results much more frequently and right away which significantly improves the diagnostics available for storage server reachability problems.

HTTP/JSON RPC Overhaul
A almost complete re-write and overhaul of the HTTP/JSON RPC server in the Daemon improving reliability and performance of communication between the Wallet and Daemon

Belnet 0.9.7 - stability and performance improvements

Following the initial hard fork at version 4.0.0, various issues were identified in the 0.9.x Belnet release. Subsequently, a dedicated effort has been underway to address these concerns and implement enhancements across the 0.9.x releases, culminating in the latest 0.9.7 release.

Notably, the most critical improvements are incorporated in the 0.9.7 release, specifically addressing issues related to how Belnet master nodes communicate with each other. Despite the existence of the 0.9.4 release for some time, the nature of these fixes necessitated an updated version to be deployed across the entire network. As a result, this upgrade is deemed mandatory to ensure the comprehensive implementation of critical fixes and enhancements for the optimal performance and stability of the Belnet network.

We've also made improvements to belnet's memory footprint, especially over time; our testing shows routers using approximately half the memory after running for a week.

Storage Server 2.3.0

The Beldex Storage Server undergoes a substantial transformation in this release, with a primary focus on enhancing performance, reliability, and facilitating future expansions. These comprehensive changes introduce new features that empower clients, such as Bchat, to directly manage messages. Specifically, clients can now delete individual messages or entire message sets, update expiration dates for messages, and utilize these functions reliably.

Additionally, the update allows clients to deposit new messages more seamlessly by establishing communication with a single swarm node. This streamlined process ensures that there is a dependable confirmation of storage, deletion, or retrieval, and that this information is efficiently disseminated to all members of the network. Overall, these advancements are geared towards making the Beldex Storage Server more efficient and robust, with an eye towards future scalability.

The Storage Server updates also significantly unifies our communication technology stack -- with this update, we are using the same libraries for communication (node-to-node; cpr for making HTTP requests; and uWebSockets for handling HTTP requests) among all the core software (beldex-core, beldex-storage-server, belnet-router).

Changelog

  • Belnet name registration
  • Changes to Master Node uptime credits
  • Update precomputed block hashes
  • Deprecate Monero stle keys for Master Nodes
  • Fix broken sync timer.
  • Switch to C++17
  • Flash: Remove deprecated bool blink in wallet RPC interface
  • Fix max uint64_t errors when contributing to a reserved spot
  • Don't overwrite mainnet lns.db for test suite/fakechain
  • Add beldex-mn-keys MN key management tool
  • Master node contribution fixes

Release binaries

As usual, we recommend installing the updates for Debian and Ubuntu based systems from our apt repository, though we also support self-compiled and static builds that we upload here.

Assets 8
Loading