Oxen Anchor Hardfork (11.2.0)

Today, Oxen is announcing the first technical step in the migration from Oxen to Session Token. This initial step is part of a broader plan that includes two hardforks. The first hardfork, codenamed the Anchor hardfork, is Oxen version 11.2.0.

Following this hardfork, a testing period will ensue. The results of this testing period will determine the date of the Landing upgrade hardfork, and in turn, the TGE of Session Token.

Alongside these changes,  new versions of the Oxen desktop wallet, Oxen mobile wallet and Oxen wallet CLI will be released. Third parties that accept Oxen, like exchanges and brokers, should update their wallets to these new versions before the hardfork to ensure they aren't stuck on the old network and receiving incorrect transactions.

This upgrade introduces several new features and changes, which are detailed below. Additionally, it disables some existing functionality, which has important implications for Service Node operators. 

New Service Node registrations will be disabled

The Anchor hardfork disables new Service Node registration transactions. This ensures that a snapshot can be taken after the Anchor hardfork but before the Landing hardfork, which will include a set of all online Service Node BLS keys. These keys will be used to seed the Arbitrum smart contracts with the initial state of the Session Node network.

As a Service Node operator, if you have registered for the Service Node Bonus Program, and upgrade and run the Oxen Anchor version at the time of the hardfork, you are opting in to participate in the automatic swap of Oxen coins to Session Tokens. As a reminder, the automatic swap will calculate the number of Session Tokens you are entitled to from the Service Node Bonus program, as well as the amount of tokens you would have received through the Oxen Coin Claims program.

These combined totals will be awarded to the Ethereum address you provided during your registration for the Service Node Bonus program, but on the Arbitrum blockchain. Since Arbitrum is a Layer 2 solution built on Ethereum, it uses the same address format as Ethereum. Therefore, any Session Tokens you receive, will  be accessible using the same Ethereum wallet you registered with, by simply switching the chain you are connected to. You will also be part of the first set of Session Nodes registered and rewarded for operating on the Arbitrum chain and supporting Session.

If you choose to submit an unlock and opt out of this hardfork, any points you have earned in the Service Node Bonus program will still be honored, and Session Tokens will be sent to your designated Arbitrum address on TGE. However, your staked amounts will not be automatically swapped for Session Tokens, and you will need to manually migrate these coins using the Oxen to SESH bridge at or after TGE.

If you are not registered for the Service Node Bonus program, you will not receive any bonus Session Tokens and any staked Oxen coins will not be automatically swapped. You will need to migrate these coins using the bridge, as above.

Service Nodes will be required to connect to an Arbitrum One RPC Endpoint

Most notably, the Anchor hardfork implements the ability to witness the Arbitrum One blockchain. All Service Nodes will be required to maintain an active and up-to-date Arbitrum One RPC endpoint to complete the upgrade. This endpoint will be crucial to allow Service Nodes to witness the state of Arbitrum smart contracts, which in the future will contain the list of active Session Nodes.

Service Nodes will be able to generate and publish BLS keys

This release also includes code that allows Service Nodes to automatically generate and publish their BLS key to the network. These BLS keys are necessary to seed the new BLS-based consensus system which allows communication between Arbitrum and the Session statechain/workchain.

Registered Service Nodes will continue to earn Bonus Program points

The Anchor hardfork makes no changes to the Service Node bonus program and points measuring systems. Registered Service Nodes will continue to earn points in the Service Node Bonus program as normal.

How to complete this upgrade

The Anchor hardfork introduces a new requirement for all nodes to maintain an active connection to an Arbitrum One RPC node. Operators who have participated in the Session Node testnet may already be familiar with this requirement using the Arbitrum Sepolia network.

There are two main options for fulfilling this requirement:

1. Public RPC providers

2. Running your own Arbitrum node

Public RPC providers

Public RPC providers handle the complexity and overhead of running an Arbitrum One node. These providers offer a public endpoint for querying. Some examples of public RPC providers that support Arbitrum One are:

• Infura https://www.infura.io/ 

• Alchemy https://www.alchemy.com/

• GetBlock https://getblock.io/

• QuickNode https://www.quicknode.com/ 

• A full more comprehensive list of official and third party RPC providers for Arbitrum can also be found here https://docs.arbitrum.io/build-decentralized-apps/reference/node-providers 

You can sign up for a free account with most of these providers, which typically offer free usage up to a certain limit. In most cases, their free tiers will support up to 2 or 3 Session Nodes without exceeding usage limits. If you need to support more nodes, you can either register for multiple providers and use different endpoints for each set of nodes, or consider upgrading to a paid plan for higher usage.

Note: If you are operating several nodes (More than 2-3 nodes per public provider) you might want to consider deploying a caching server, such as json-rpc-cache-proxy. This setup allows you to significantly reduce the number of calls made to your RPC provider by caching common queries, improving performance and reducing costs.

Running your own Arbitrum Node

If you are staking multiple nodes or prefer not to rely on a public RPC provider, you may want to run your own Arbitrum One node. But be aware that the hardware requirements for running an Arbitrum One node are very demanding.

A full guide on how to run an Arbitrum One node using Nitro can be found here 

https://docs.arbitrum.io/run-arbitrum-node/run-full-node 

Upgrading

Once you have your Arbitrum node or public provider setup, you will receive a URL or local address that will look something like this, depending on your provider or setup:

https://arb-mainnet.g.alchemy.com/v2/32bfi3gb298fbb32byfb32bf

Your node can be upgraded using the following simple commands in your CLI:

 Syncing your repositories: 

 sudo apt update

Then installing updates using:

 sudo apt upgrade

Please note: this will install both updated Oxen packages and any available system updates (this is a good thing!).

During the upgrade process, you will be prompted to enter your Arbitrum RPC address. Enter the URL or local address of your Arbitrum node. You also have the option to specify backup RPC nodes, by adding multiple URLs, separated by a comma. These will be queried if your primary endpoint is unavailable. Adding backup RPC nodes is optional and not required to complete the upgrade.

Support 

If you run into any issues while upgrading, please reach out via the Oxen Service Nodes channel on Telegram or via the Session Token Discord here so that Session contributors can assist you.