The Session Token testnet has been live for just over a week, marking a significant milestone in the journey towards mainnet and the beginning of the Lighthouse Phase. Here, the Session Token development team reflects on the months of groundwork that have gone into preparing the smart contracts. In particular, this post provides more context around two major areas of technical work for the new Session Network: Arbitrum Witnessing and Streamlining Registration.
Arbitrum Witnessing
The Session Network will use the Oxen appchain to handle some computational tasks, transaction validation and finality, and ensure data availability and security. All of this requires an L2 tracker to communicate between the appchain and Aribtrum One. The L2 tracker is responsible for witnessing events on Arbitrum and transferring information about these events to the Oxen appchain.
One of the challenges with using Arbitrum One is its high hardware requirements—put in place to increase transaction throughput. To avoid having similarly high hardware requirements for Session Nodes, operators will be able to utilise low-cost Arbitrum RPC nodes to witness the chain. This constraint puts an upper limit on the number of times a Session Node can contact the RPC nodes to minimise operating costs. The limits were chosen to ensure compatibility with many of the low-tiers available from Web3 providers like Infura and Alchemy.
It was also critical to consider possible ways that the new Session Network could impact users negatively. Since consensus is now dependent on Arbitrum, there's a possibility of denial-of-service attacks outside of the Session Network’s immediate control. RPC outages or Arbitrum network instability could also affect Session’s stability. Some of the ways we've chosen to mitigate these issues include:
- Allowing multiple fall-back providers that are periodically ranked on performance, measured by their responsiveness to requests
- Treating Arbitrum as providing weak-consensus to the operation of the Session network
The second point means that Session Nodes may accept temporary non-consensus regarding the state of Arbitrum to ensure the continual, uninterrupted operation of the Session Network. This allows the Session Network to smooth out performance degradation during destabilising events (such as Arbitrum provider outages) and maintain Session service in the meantime, before eventually reaching consensus once the final state of Arbitrum is determined.
Streamlining Registration
Another key focus over the past few months was building a node registration process that is user-friendly and streamlined. To achieve this, CLI (command line interface) interactions were reduced as much as possible. In the past, requiring CLI interactions to set up and maintain an Oxen Service Node has been a common cause of issues for network operators. Transitioning to a web-based GUI will help diversify operators and scale the network.
New infrastructure has been set up to facilitate communications between Session Nodes and the Staking Portal, allowing people to register and stake nodes from an interface everyone is familiar with: a web-browser. Of course, this creates a new set of challenges, including the new pipelines for transmitting registration data, new website architecture, and new designs to convey those things in meaningful and useful ways to operators so they can intuitively set up and manage their nodes.
Almost all interactions with the CLI have been successfully offloaded to the Staking Portal. The CLI is now only required initially to install the software package and once more to prepare the registration. From that point, the nodes can be managed from the Staking Portal.
This transition came with its share of challenges, and we extend our gratitude to the community members for their invaluable feedback via Discord, which has already led to the deployment of several fixes. During the ongoing Session Testnet, the continued close collaboration of the community and team will prime the Session Network for a successful mainnet launch.
Onward.