status-im
/
status-node-manager
mirror of https://github.com/status-im/status-node-manager.git
2
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

docs: Add README

This commit is contained in:
Zahary Karadjov 2024-01-13 22:24:59 +02:00
parent d1ef092006
commit 621cf9750b
No known key found for this signature in database
GPG Key ID: C1F42EAFF38D570F
2 changed files with 42 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
README.md
View File

@ -0,0 +1,21 @@
# Status Node Manager
The Status node manager is the back-end service for the [Nimbus node management GUI](https://github.com/status-im/nimbus-gui).
The GUI is focused to the [Nimbus consensus layer](https://nimbus.guide) at the moment, but it will eventually support other [Logos](https://logos.co) node types, such as [Nimbus EL](https://github.com/status-im/nimbus-eth1), [Fluffy](https://fluffy.guide), [Codex](https://github.com/codex-storage/nim-codex), [Waku](https://github.com/waku-org) and [Nomos](https://github.com/logos-co/nomos-node).
## Configuration
The GUI app connects to the node manager through the Waku protocol. This ensures that a persistent pairing between the two can be established without any networking configuration (i.e. the user doesn't have to specify IP addresses and ports of the running Nimbus instances) and that not even metadata regarding the connection is leaked to anyone. The locally running Nimbus node can bind its REST API and metrics port to localhost and the Status node manager can make them available to the GUI through a HTTP-over-Waku transport.
The [pairing protocol](./docs/pairing_protocol.md) is very simple: The user clicks on a "Connect to Node Manager" button in the GUI which generates a random numeric ID. The user can then simply run the command `nimbus pair <random-id>` on the host where the node manager is installed to complete the process.
## Functionality
Once configured, the node manager supports the following functionality:
- [ ] It allows the user to manage the set of validator keys on the managed nodes (including the ability to generate and execute deposit transactions in order to create new validators).
- [ ] It provides access to the REST APIs and metrics of the managed nodes. It delivers useful notifications, alerts and actionable diagnostic information that can help the user maintain the optimal performance of their validators.
- [ ] It keeps track of new releases of the Nimbus consensus layer and its own command-line management utilities.
- [ ] It can upgrade and roll-back any of the above components in zero-downtime fashion. The initial version of the zero-downtime upgrade procedure will take advantage of the "time to next action" metric of the Nimbus beacon node.
- [ ] It can perform upgrades automatically. The user is free to enable or disable this policy and also to specify an upgrade delay period (e.g. 2 weeks) in order to allow for potential problems to be discovered by more active early adopters.
- [ ] The user can remotely start new Nimbus nodes connected to different networks (e.g. testnets). The Status node manager then either acts as a simple supervisor for the started processes or it can leverage Systemd for the same purpose.

21
docs/pairing_protocol.md Normal file
View File

@ -0,0 +1,21 @@
# Status Node Manager Pairing Protocol
## Introduction
This documents provides a high-level outline of the pairing protocol that is used to establish a persistent connection between the Nimbus GUI app and the Status node manager. The connection can be established even when both of the endpoints lack public IP addresses and can be maintained without re-configuration even after arbitrary changes to their physical locations. These properties are achieved through the use of the [Waku2 communication protocol](https://rfc.vac.dev/spec/10/).
## Pairing procedure
The protocol involves the following steps:
1) The user initiates the pairing procedure in the GUI app.
2) The app generates a 64-bit random number `P`.
3) Using this number and a key derivation function `kdf(x, salt)`, the app derives a Waku topic name `T = kdf(P, TOPIC_SALT)` and a handshake key `HS = kdf(P, HANDSHAKE_KEY_SALT)`. `TOPIC_SALT` and `HANDSHAKE_KEY_SALT` are protocol constants.
4) The app connects to the Waku network using identity key `APP_IDENTITY` and starts listening for messages sent to the `T` topic.
5) The user enters the same number on the machine where the Status node manager is running and the node manager is able to derive the same values for `T` and `HS`.
6) The node manager connects to the Waku network using identity key `NODE_MANAGER_IDENTITY` and sends a message `HELLO_APP = encrypt(HS, node_manager_identity)` to the `T` topic.
7) The app receives the `HELLO_APP` messages and successfully decrypts it using `HS`. The app persists `NODE_MANAGER_IDENTITY` in its local storage.
8) The app responds by sending the message `HELLO_NODE_MANAGER = encrypt(HS, app_identity)` on the `T` topic.
9) The node manager receives the `HELLO_NODE_MANAGER` message and successfully decrypts it using `HS`. The node manager persists `APP_IDENTITY` in its local storage.
10) The node manager tries to establish a [Waku Noise Session](https://rfc.vac.dev/spec/37/) using the app identity key. The app accepts the session.
11) On every consecutive start-up, both sides immediately try to establish noise sessions with all of their persisted counterparties. Incoming sessions from known counterparties are accepted.