mirror of
https://github.com/sigp/lighthouse.git
synced 2026-03-03 00:31:50 +00:00
Siren Docs Upgrade (#5979)
* fix: removed unused sections * Update book/src/ui-authentication.md Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com> * feat: added more information about features and screenshots * Update book/src/ui-usage.md Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com> * Update book/src/ui-usage.md Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com> * Update book/src/ui-usage.md Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com> * Update book/src/ui-usage.md Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com> * Update book/src/ui-usage.md Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com> * Update book/src/ui-installation.md Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com> * Update book/src/ui-usage.md Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com> * Update ui-usage.md * Update ui-faqs.md * fix: lint fixes * Update ui-usage.md * Update book/src/ui-usage.md Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com> * Update book/src/ui-usage.md Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com> * Update book/src/ui-usage.md Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com> * add siren's ssl certificate usage to `book` * update `ui` docs * lint fixes * Update book/src/ui-installation.md Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com>
This commit is contained in:
Ricki Moore
BIN
book/src/imgs/ui-auth.png
Normal file
BIN
book/src/imgs/ui-auth.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 866 KiB |
BIN
book/src/imgs/ui-bls-modal.png
Normal file
BIN
book/src/imgs/ui-bls-modal.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 386 KiB |
BIN
book/src/imgs/ui-bls-required.png
Normal file
BIN
book/src/imgs/ui-bls-required.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 364 KiB |
BIN
book/src/imgs/ui-session.png
Normal file
BIN
book/src/imgs/ui-session.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.4 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 346 KiB After Width: | Height: | Size: 797 KiB |
BIN
book/src/imgs/ui-val-edit.png
Normal file
BIN
book/src/imgs/ui-val-edit.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 279 KiB |
BIN
book/src/imgs/ui-val-exit.png
Normal file
BIN
book/src/imgs/ui-val-exit.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 424 KiB |
BIN
book/src/imgs/ui-val-modal.png
Normal file
BIN
book/src/imgs/ui-val-modal.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 351 KiB |
@@ -1,31 +1,13 @@
|
||||
# Authentication
|
||||
|
||||
To enhance the security of your account, we offer the option to set a session password. This allows the user to avoid re-entering the api-token when performing critical mutating operations on the validator. Instead a user can simply enter their session password. In the absence of a session password, Siren will revert to the api-token specified in your configuration settings as the default security measure.
|
||||
## Siren Session
|
||||
|
||||
> This does not protect your validators from unauthorized device access.
|
||||
For enhanced security, Siren will require users to authenticate with their session password to access the dashboard. This is crucial because Siren now includes features that can permanently alter the status of user validators. The session password must be set during the [installation](./ui-installation.md) process before running the Docker or local build, either in an `.env` file or via Docker flags.
|
||||
|
||||
|
||||
|
||||
Session passwords must contain at least:
|
||||
|
||||
- 12 characters
|
||||
- 1 lowercase letter
|
||||
- 1 uppercase letter
|
||||
- 1 number
|
||||
- 1 special character
|
||||
|
||||
|
||||
## Protected Actions
|
||||
|
||||
Prior to executing any sensitive validator action, Siren will request authentication of the session password or api-token.
|
||||
Prior to executing any sensitive validator action, Siren will request authentication of the session password. If you wish to update your password please refer to the Siren [installation process](./ui-installation.md).
|
||||
|
||||
|
||||
|
||||
In the event of three consecutive failed attempts, Siren will initiate a security measure by locking all actions and prompting for configuration settings to be renewed to regain access to these features.
|
||||
|
||||
|
||||
|
||||
## Auto Connect
|
||||
|
||||
In the event that auto-connect is enabled, refreshing the Siren application will result in a prompt to authenticate the session password or api-token. If three consecutive authentication attempts fail, Siren will activate a security measure by locking the session and prompting for configuration settings to be reset to regain access.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,15 +1,12 @@
|
||||
# Configuration
|
||||
|
||||
Siren requires a connection to both a Lighthouse Validator Client
|
||||
and a Lighthouse Beacon Node. Upon running you will first be greeted by the
|
||||
following configuration screen.
|
||||
|
||||
|
||||
Siren requires a connection to both a Lighthouse Validator Client and a Lighthouse Beacon Node.
|
||||
To enable connection, you must generate .env file based on the provided .env.example
|
||||
|
||||
## Connecting to the Clients
|
||||
|
||||
Both the Beacon node and the Validator client need to have their HTTP APIs enabled. These ports should be accessible from the computer running Siren. This allows you to enter the address and ports of the associated Lighthouse
|
||||
Beacon node and Lighthouse Validator client.
|
||||
Both the Beacon node and the Validator client need to have their HTTP APIs enabled.
|
||||
These ports should be accessible from Siren.
|
||||
|
||||
To enable the HTTP API for the beacon node, utilize the `--gui` CLI flag. This action ensures that the HTTP API can be accessed by other software on the same machine.
|
||||
|
||||
@@ -21,10 +18,7 @@ If you require accessibility from another machine within the network, configure
|
||||
|
||||
In a similar manner, the validator client requires activation of the `--http` flag, along with the optional consideration of configuring the `--http-address` flag. If `--http-address` flag is set on the Validator Client, then the `--unencrypted-http-transport` flag is required as well. These settings will ensure compatibility with Siren's connectivity requirements.
|
||||
|
||||
If you run Siren in the browser (by entering `localhost` in the browser), you will need to allow CORS in the HTTP API. This can be done by adding the flag `--http-allow-origin "*"` for both beacon node and validator client.
|
||||
|
||||
A green tick will appear once Siren is able to connect to both clients. You
|
||||
can specify different ports for each client by clicking on the advanced tab.
|
||||
If you run the Docker container, it will fail to startup if your BN/VC are not accessible, or if you provided a wrong API token.
|
||||
|
||||
## API Token
|
||||
|
||||
@@ -41,13 +35,3 @@ client. The default path is
|
||||
|
||||
The contents of this file for the desired validator client needs to be
|
||||
entered.
|
||||
|
||||
## Name
|
||||
|
||||
This is your name, it can be modified and is solely used for aesthetics.
|
||||
|
||||
## Device
|
||||
|
||||
This is a name that can be associated with the validator client/beacon
|
||||
node pair. Multiple such pairs can be remembered for quick swapping between
|
||||
them.
|
||||
|
||||
@@ -14,53 +14,17 @@ If you receive a red notification with a BEACON or VALIDATOR NODE NETWORK ERROR
|
||||
|
||||
## 4. How do I connect Siren to Lighthouse from a different computer on the same network?
|
||||
|
||||
The most effective approach to enable access for a local network computer to Lighthouse's HTTP API ports is by configuring the `--http-address` to match the local LAN IP of the system running the beacon node and validator client. For instance, if the said node operates at `192.168.0.200`, this IP can be specified using the `--http-address` parameter as `--http-address 192.168.0.200`. When this is set, the validator client requires the flag `--beacon-nodes http://192.168.0.200:5052` to connect to the beacon node.
|
||||
Subsequently, by designating the host as `192.168.0.200`, you can seamlessly connect Siren to this specific beacon node and validator client pair from any computer situated within the same network.
|
||||
Siren is a webapp, you can access it like any other website. We don't recommend exposing it to the internet; if you require remote access a VPN or (authenticated) reverse proxy is highly recommended.
|
||||
|
||||
## 5. How can I use Siren to monitor my validators remotely when I am not at home?
|
||||
|
||||
There are two primary methods to access your Beacon Node and Validator Client remotely: setting up a VPN or utilizing SSH-reverse tunneling.
|
||||
|
||||
Most contemporary home routers provide options for VPN access in various ways. A VPN permits a remote computer to establish a connection with internal computers within a home network. With a VPN configuration in place, connecting to the VPN enables you to treat your computer as if it is part of your local home network. The connection process involves following the setup steps for connecting via another machine on the same network on the Siren configuration page and [`connecting to clients section`](./ui-configuration.md#connecting-to-the-clients).
|
||||
|
||||
In the absence of a VPN, an alternative approach involves utilizing an SSH tunnel. To achieve this, you need remote SSH access to the computer hosting the Beacon Node and Validator Client pair (which necessitates a port forward in your router). In this context, while it is not obligatory to set a `--http-address` flag on the Beacon Node and Validator Client, you can configure an SSH tunnel to the local ports on the node and establish a connection through the tunnel. For instructions on setting up an SSH tunnel, refer to [`Connecting Siren via SSH tunnel`](./ui-faqs.md#6-how-do-i-connect-siren-to-lighthouse-via-a-ssh-tunnel) for detailed guidance.
|
||||
## 6. Does Siren support reverse proxy or DNS named addresses?
|
||||
|
||||
## 6. How do I connect Siren to Lighthouse via a ssh tunnel?
|
||||
Yes, if you need to access your beacon or validator from an address such as `https://merp-server:9909/eth2-vc` you should configure Siren as follows:
|
||||
`VALIDATOR_URL=https://merp-server:9909/eth2-vc`
|
||||
|
||||
If you would like to access Siren beyond the local network (i.e across the internet), we recommend using an SSH tunnel. This requires a tunnel for 3 ports: `80` (assuming the port is unchanged as per the [installation guide](./ui-installation.md#docker-recommended)), `5052` (for beacon node) and `5062` (for validator client). You can use the command below to perform SSH tunneling:
|
||||
|
||||
```bash
|
||||
|
||||
ssh -N -L 80:127.0.0.1:80 -L 5052:127.0.0.1:5052 -L 5062:127.0.0.1:5062 username@local_ip
|
||||
|
||||
```
|
||||
|
||||
Where `username` is the username of the server and `local_ip` is the local IP address of the server. Note that with the `-N` option in an SSH session, you will not be able to execute commands in the CLI to avoid confusion with ordinary shell sessions. The connection will appear to be "hung" upon a successful connection, but that is normal. Once you have successfully connected to the server via SSH tunneling, you should be able to access Siren by entering `localhost` in a web browser.
|
||||
|
||||
You can also access Siren using the app downloaded in the [Siren release page](https://github.com/sigp/siren/releases). To access Siren beyond the local computer, you can use SSH tunneling for ports `5052` and `5062` using the command:
|
||||
|
||||
```bash
|
||||
|
||||
ssh -N -L 5052:127.0.0.1:5052 -L 5062:127.0.0.1:5062 username@local_ip
|
||||
|
||||
```
|
||||
|
||||
## 7. Does Siren support reverse proxy or DNS named addresses?
|
||||
|
||||
Yes, if you need to access your beacon or validator from an address such as `https://merp-server:9909/eth2-vc` you should follow the following steps for configuration:
|
||||
|
||||
1. Toggle `https` as your protocol
|
||||
2. Add your address as `merp-server/eth2-vc`
|
||||
3. Add your Beacon and Validator ports as `9909`
|
||||
|
||||
If you have configured it correctly you should see a green checkmark indicating Siren is now connected to your Validator Client and Beacon Node.
|
||||
|
||||
If you have separate address setups for your Validator Client and Beacon Node respectively you should access the `Advance Settings` on the configuration and repeat the steps above for each address.
|
||||
|
||||
## 8. How do I change my Beacon or Validator address after logging in?
|
||||
|
||||
Once you have successfully arrived to the main dashboard, use the sidebar to access the settings view. In the top right-hand corner there is a `Configuration` action button that will redirect you back to the configuration screen where you can make appropriate changes.
|
||||
|
||||
## 9. Why doesn't my validator balance graph show any data?
|
||||
## 7. Why doesn't my validator balance graph show any data?
|
||||
|
||||
If your graph is not showing data, it usually means your validator node is still caching data. The application must wait at least 3 epochs before it can render any graphical visualizations. This could take up to 20min.
|
||||
|
||||
@@ -1,113 +1,73 @@
|
||||
# 📦 Installation
|
||||
|
||||
Siren runs on Linux, MacOS and Windows.
|
||||
Siren supports any operating system that supports container runtimes and/or NodeJS 18, this includes Linux, MacOS, and Windows. The recommended way of running Siren is by launching the [docker container](https://hub.docker.com/r/sigp/siren) , but running the application directly is also possible.
|
||||
|
||||
## Version Requirement
|
||||
|
||||
The Siren app requires Lighthouse v3.5.1 or higher to function properly. These versions can be found on the [releases](https://github.com/sigp/lighthouse/releases) page of the Lighthouse repository.
|
||||
To ensure proper functionality, the Siren app requires Lighthouse v4.3.0 or higher. You can find these versions on the [releases](https://github.com/sigp/lighthouse/releases) page of the Lighthouse repository.
|
||||
|
||||
## Pre-Built Electron Packages
|
||||
## Running the Docker container (Recommended)
|
||||
|
||||
There are pre-compiled electron packages for each operating systems which can
|
||||
be downloaded and executed. These can be found on the
|
||||
[releases](https://github.com/sigp/siren/releases) page of the
|
||||
Siren repository.
|
||||
The most convenient way to run Siren is to use the Docker images built and published by Sigma Prime.
|
||||
|
||||
Simply download the package specific to your operating system and run it.
|
||||
They can be found on [Docker hub](https://hub.docker.com/r/sigp/siren/tags), or pulled directly with `docker pull sigp/siren`
|
||||
|
||||
## Building From Source
|
||||
|
||||
### Requirements
|
||||
|
||||
Building from source requires `Node v18` and `yarn`.
|
||||
|
||||
### Building From Source
|
||||
|
||||
The electron app can be built from source by first cloning the repository and
|
||||
entering the directory:
|
||||
|
||||
```
|
||||
git clone https://github.com/sigp/siren.git
|
||||
cd siren
|
||||
```
|
||||
|
||||
Once cloned, the electron app can be built and ran via the Makefile by:
|
||||
|
||||
```
|
||||
make
|
||||
```
|
||||
|
||||
alternatively it can be built via:
|
||||
|
||||
```
|
||||
yarn
|
||||
```
|
||||
|
||||
Once completed successfully the electron app can be run via:
|
||||
|
||||
```
|
||||
yarn dev
|
||||
```
|
||||
|
||||
### Running In The Browser
|
||||
|
||||
#### Docker (Recommended)
|
||||
|
||||
Docker is the recommended way to run a webserver that hosts Siren and can be
|
||||
connected to via a web browser. We recommend this method as it establishes a
|
||||
production-grade web-server to host the application.
|
||||
|
||||
`docker` is required to be installed with the service running.
|
||||
|
||||
The docker image can be built and run via the Makefile by running:
|
||||
|
||||
```
|
||||
make docker
|
||||
```
|
||||
|
||||
Alternatively, to run with Docker, the image needs to be built. From the repository directory
|
||||
run:
|
||||
|
||||
```
|
||||
docker build -t siren .
|
||||
```
|
||||
Configuration is done through environment variables, the easiest way to get started is by copying `.env.example` to `.env` and editing the relevant sections (typically, this would at least include adding `BEACON_URL`, `VALIDATOR_URL`, `API_TOKEN` and `SESSION_PASSWORD`)
|
||||
|
||||
Then to run the image:
|
||||
|
||||
```
|
||||
docker run --rm -ti --name siren -p 80:80 siren
|
||||
```
|
||||
`docker compose up`
|
||||
or
|
||||
`docker run --rm -ti --name siren -p 4443:443 --env-file $PWD/.env sigp/siren`
|
||||
|
||||
This will open port 80 and allow your browser to connect. You can choose
|
||||
another local port by modifying the command. For example `-p 8000:80` will open
|
||||
port 8000.
|
||||
This command will open port 4443, allowing your browser to connect.
|
||||
|
||||
To view Siren, simply go to `http://localhost` in your web browser.
|
||||
To start Siren, visit `https://localhost:4443` in your web browser.
|
||||
|
||||
#### Development Server
|
||||
Advanced users can mount their own certificates, see the `SSL Certificates` section below
|
||||
|
||||
A development server can also be built which will expose a local port 3000 via:
|
||||
## Building From Source
|
||||
|
||||
```
|
||||
yarn start
|
||||
```
|
||||
### Docker
|
||||
|
||||
Once executed, you can direct your web browser to the following URL to interact
|
||||
with the app:
|
||||
The docker image can be built with the following command:
|
||||
`docker build -f Dockerfile -t siren .`
|
||||
|
||||
```
|
||||
http://localhost:3000
|
||||
```
|
||||
### Building locally
|
||||
|
||||
A production version of the app can be built via
|
||||
To build from source, ensure that your system has `Node v18.18` and `yarn` installed.
|
||||
|
||||
```
|
||||
yarn build
|
||||
```
|
||||
#### Build and run the backend
|
||||
|
||||
and then further hosted via a production web server.
|
||||
Navigate to the backend directory `cd backend`. Install all required Node packages by running `yarn`. Once the installation is complete, compile the backend with `yarn build`. Deploy the backend in a production environment, `yarn start:production`. This ensures optimal performance.
|
||||
|
||||
### Known Issues
|
||||
#### Build and run the frontend
|
||||
|
||||
If you experience any issues in running the UI please create an issue on the
|
||||
[Lighthouse UI](https://github.com/sigp/lighthouse-ui) repository.
|
||||
After initializing the backend, return to the root directory. Install all frontend dependencies by executing `yarn`. Build the frontend using `yarn build`. Start the frontend production server with `yarn start`.
|
||||
|
||||
This will allow you to access siren at `http://localhost:3000` by default.
|
||||
|
||||
## Advanced configuration
|
||||
|
||||
### About self-signed SSL certificates
|
||||
|
||||
By default, Siren will generate and use a self-signed certificate on startup.
|
||||
This will generate a security warning when you try to access the interface.
|
||||
We recommend to only disable SSL if you would access Siren over a local LAN or otherwise highly trusted or encrypted network (i.e. VPN).
|
||||
|
||||
#### Generating persistent SSL certificates and installing them to your system
|
||||
|
||||
[mkcert](https://github.com/FiloSottile/mkcert) is a tool that makes it super easy to generate a self-signed certificate that is trusted by your browser.
|
||||
|
||||
To use it for `siren`, install it following the instructions. Then, run `mkdir certs; mkcert -cert-file certs/cert.pem -key-file certs/key.pem 127.0.0.1 localhost` (add or replace any IP or hostname that you would use to access it at the end of this command)
|
||||
|
||||
The nginx SSL config inside Siren's container expects 3 files: `/certs/cert.pem` `/certs/key.pem` `/certs/key.pass`. If `/certs/cert.pem` does not exist, it will generate a self-signed certificate as mentioned above. If `/certs/cert.pem` does exist, it will attempt to use your provided or persisted certificates.
|
||||
|
||||
### Configuration through environment variables
|
||||
|
||||
For those who prefer to use environment variables to configure Siren instead of using an `.env` file, this is fully supported. In some cases this may even be preferred.
|
||||
|
||||
#### Docker installed through `snap`
|
||||
|
||||
If you installed Docker through a snap (i.e. on Ubuntu), Docker will have trouble accessing the `.env` file. In this case it is highly recommended to pass the config to the container with environment variables.
|
||||
Note that the defaults in `.env.example` will be used as fallback, if no other value is provided.
|
||||
|
||||
@@ -1,38 +1,42 @@
|
||||
# Usage
|
||||
|
||||
Siren offers many features ranging from diagnostics, logs, validator management including graffiti and exiting. Below we will describe all major features and how to take advantage of Siren to the fullest.
|
||||
|
||||
## Dashboard
|
||||
|
||||
Siren's dashboard view provides a summary of all performance and key validator metrics. Sync statuses, uptimes, accumulated rewards, hardware and network metrics are all consolidated on the dashboard for evaluation.
|
||||
|
||||
|
||||
|
||||
## Account Earnings
|
||||
### Account Earnings
|
||||
|
||||
The account earnings component accumulates reward data from all registered validators providing a summation of total rewards earned while staking. Given current conversion rates, this component also converts your balance into your selected fiat currency.
|
||||
|
||||
Below in the earning section, you can also view your total earnings or click the adjacent buttons to view your estimated earnings given a specific time frame based on current device and network conditions.
|
||||
|
||||
Keep in mind, if validators have updated (`0x01`) withdrawal credentials, this balance will only reflect the balance before the accumulated rewards are paid out and will subsequently be reset to a zero balance and start accumulating rewards until the next reward payout.
|
||||
|
||||
|
||||
|
||||
## Validator Table
|
||||
### Validator Table
|
||||
|
||||
The validator table component is a list of all registered validators, which includes data such as name, index, total balance, earned rewards and current status. Each validator row also contains a link to a detailed data modal and additional data provided by [Beaconcha.in](https://beaconcha.in).
|
||||
|
||||
|
||||
|
||||
## Validator Balance Chart
|
||||
### Validator Balance Chart
|
||||
|
||||
The validator balance component is a graphical representation of each validator balance over the latest 10 epochs. Take note that only active validators are rendered in the chart visualization.
|
||||
|
||||
|
||||
|
||||
By clicking on the chart component you can filter selected validators in the render. This call allow for greater resolution in the rendered visualization.
|
||||
By clicking on the chart component you can filter selected validators in the render. This will allow for greater resolution in the rendered visualization.
|
||||
|
||||
<img src="imgs/ui-balance-modal.png" width="48%" style="display: inline; float: left; margin-right: 4%" alt="balance-modal" />
|
||||
|
||||
<img src="imgs/ui-validator-balance2.png" width="48%" alt="validator-balance2" />
|
||||
<img src="imgs/ui-validator-balance2.png" width="48%" style="margin-bottom: 25px" alt="validator-balance2" />
|
||||
|
||||
## Hardware Usage and Device Diagnostics
|
||||
### Hardware Usage and Device Diagnostics
|
||||
|
||||
The hardware usage component gathers information about the device the Beacon Node is currently running. It displays the Disk usage, CPU metrics and memory usage of the Beacon Node device. The device diagnostics component provides the sync status of the execution client and beacon node.
|
||||
|
||||
@@ -40,11 +44,13 @@ The hardware usage component gathers information about the device the Beacon Nod
|
||||
|
||||
<img height="350" src="imgs/ui-device.png" alt="device" />
|
||||
|
||||
## Log Statistics
|
||||
### Log Statistics
|
||||
|
||||
The log statistics present an hourly combined rate of critical, warning, and error logs from the validator client and beacon node. This analysis enables informed decision-making, troubleshooting, and proactive maintenance for optimal system performance.
|
||||
The log statistics present an hourly combined rate of critical, warning, and error logs from the validator client and beacon node. This analysis enables informed decision-making, troubleshooting, and proactive maintenance for optimal system performance. You can view the full log outputs in the logs page by clicking `view all` at the top of the component.
|
||||
|
||||
<img height="350" src="imgs/ui-dash-logs.png" alt="log" />
|
||||
<img height="350" src="imgs/ui-dash-logs.png" style="margin-bottom: 50px" alt="log" />
|
||||
|
||||
________________________________________________________________________________________________________________________________
|
||||
|
||||
## Validator Management
|
||||
|
||||
@@ -52,17 +58,36 @@ Siren's validator management view provides a detailed overview of all validators
|
||||
|
||||
|
||||
|
||||
## Validator Modal
|
||||
### Validator Modal
|
||||
|
||||
Clicking the validator icon activates a detailed validator modal component. This component also allows users to trigger validator actions and as well to view and update validator graffiti. Each modal contains the validator total income with hourly, daily and weekly earnings estimates.
|
||||
|
||||
<img height="450" src="imgs/ui-validator-modal.png" alt="ui-validator-modal" />
|
||||
<img height="450" src="imgs/ui-val-modal.png" alt="ui-validator-modal" />
|
||||
|
||||
## Settings
|
||||
### Validator BLS Withdrawal Credentials
|
||||
|
||||
Siren's settings view provides access to the application theme, version, name, device name and important external links. From the settings page users can also access the configuration screen to adjust any beacon or validator node parameters.
|
||||
When Siren detects that your validator is using outdated BLS withdrawal credentials, it will temporarily block any further actions by the validator. You can identify if your validator does not meet this requirement by an `exclamation mark` on the validator icon or a message in the validator modal that provides instructions for updating the credentials.
|
||||
|
||||
|
||||
|
||||
|
||||
If you wish to convert your withdrawal address, Siren will prompt you to provide a valid `BLS Change JSON`. This JSON can include a single validator or multiple validators for your convenience. Upon validation, the process will initiate, during which your validator will enter a processing state. Once the process is complete, you will regain access to all other validator actions.
|
||||
|
||||
|
||||
|
||||
### Validator Edit
|
||||
|
||||
Siren makes it possible to edit your validator's display name by clicking the edit icon in the validator table. Note: This does not change the validator name, but gives it an alias you can use to identify each validator easily.
|
||||
These settings are stored in your browser's `localStorage`
|
||||
|
||||
|
||||
|
||||
### Validator Exit
|
||||
|
||||
Siren provides the ability to exit/withdraw your validators via the validator management page. In the validator modal, click the validator action `withdraw validator`. Siren will then prompt you with additional information before requiring you to validate your session password. Remember, this action is irreversible and will lock your validator into an exiting state. Please take extra caution.
|
||||
|
||||
|
||||
|
||||
________________________________________________________________________________________________________________________________
|
||||
|
||||
## Validator and Beacon Logs
|
||||
|
||||
@@ -71,3 +96,11 @@ The logs page provides users with the functionality to access and review recorde
|
||||
Additionally, users can obtain log statistics, which are also available on the main dashboard, thereby facilitating a comprehensive overview of the system's log data. Please note that Siren is limited to storing and displaying only the previous 1000 log messages. This also means the text search is limited to the logs that are currently stored within Siren's limit.
|
||||
|
||||
|
||||
|
||||
________________________________________________________________________________________________________________________________
|
||||
|
||||
## Settings
|
||||
|
||||
Siren's settings view provides access to the application theme, version, display name, and important external links. If you experience any problems or have feature request, please follow the github and or discord links to get in touch.
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user