We are pleased to announce that the first stable version of Lighthouse's validator management UI (codename: Siren) has been released!
Siren
Siren is an interface that connects to a Lighthouse Beacon node and Validator client in order to aggregate some useful data for the end user without too much technical information that may come with a grafana dashboard. In particular, Siren aims to show basic health of the underlying nodes and validators, the general performance of your validators (and their statuses) as well as making some modifications easier, such as withdrawing validators or modifying their graffiti values.
Siren v1.0.0 is the beginning. There are features planned in its future, such as adding new validators (which will assist with deposits and seamlessly add the validator keys to the validator client on the fly), aggregated historic validator metrics (such as missed/total blocks produced) and potentially execution client integration to keep track of withdrawn rewards. Ideally, the future feature set will be heavily based on what our end-users want and so we encourage feature requests on the Siren repository, sigp/siren.
For this reason, if you're running validators with Lighthouse, we encourage you to check it out! Keep in mind, you may have to add some extra CLI flags to your beacon node/validator client in order for Siren to connect to them.
The details for setting up, configuring and using Siren can be found in our Lighthouse book in the Siren section and help/support can be found in the #ui-siren channel of the Lighthouse discord.
Although the Lighthouse book has a run down of how to use Siren, let me post some of the features to save you the effort of clicking the above link.
Features
Dashboard
The main part of the app is a dashboard. Here is an example of a rather poorly performing beacon node on a testnet.
It also has a light theme...
This dash shows some basic node health metrics, such as sync state, connected peers, uptime, versions etc. It also has some metrics which indicate the health of the network as a whole via the participation rate and blocks behind (which is a measure of how many slots have occurred since the last block was observed). This also shows validator balances, a short history of the balances in graph form, validator status's and indications if the validator still needs to update their BLS withdrawal credentials. Finally, the dash also shows general health of the machine running the beacon node and provides some useful alerts for when things are not performing as they should be.
Validator Management
Validators themselves can be managed via this dashboard.
Here validators can be named, their graffiti's can be modified, BLS credentials updated and validators can even be withdrawn (note that Siren disallows withdrawals with BLS credentials to avoid unexpected behaviour).
The validator management dashboard just provides a little more information and features to manage individual validators. As mentioned above, the feature set of what we can do with validators in this management console will likely expand in the future.
Logs
I know most people reading this will not be as excited as I am about logs, but we did integrate beacon node logs and validator client logs into the dash for those who also like staring at walls of moving text.
For mainly performance reasons, we exclude debug and trace level logs. If there is any kind of error or warning, they will appear here and you should get an indication of what is wrong, if anything. You can select between beacon node and validator client logs and also do some rudimentary searching. As an added feature, you can turn off auto-refresh if you're the kind of person that prefers static walls of text to moving walls of text.
Security
Something must be said about the security model of Siren and how users should use this software.
Siren connects to the HTTP API's of both a beacon node and a validator client. In this regard, it has no extra authority/privilege than anybody else that can access these APIs. However, user's setups may change in order to give Siren access, i.e users may expose their BN (Beacon Node) and VC (Validator Client) to a wider network in order to give a remote Siren access to monitor the nodes. There are a few main things users should be weary of. Firstly, we do not recommend exposing either the BN or VC HTTP API ports to the internet. We recommend they only be open locally and then accessed remotely via alternate methods, such as a VPN or a reverse ssh tunnel. If you are using Siren in a browser, often the CORS HTTP header needs to be set appropriately. Our docs suggest setting the CORS domain to "*" but this should be used with caution and a more specific domain can be set to limit undesired requests.
Finally, and most importantly, Siren is able to do non-reversible actions on your validators. Specifically, Siren can withdraw/exit your validators!! The main security mechanism that prevents anyone from performing this action is the validator clients api token. This is a key that is required to perform any action on a VC. Simply having access to the HTTP API is not enough. When Siren starts, you must enter this key in order to have access to the VC. Siren gives you the option to enter a password, which if chosen, will encrypt this api token in local storage. This way, you either need to remember the API token OR the password you entered. If you forget the password, you can always just go back and re-enter the api token. Siren requires this key or password, when doing dangerous operations such as withdrawing a validator. Although this helps mitigate scenarios where a user has left Siren running on a computer and a malicious actor decides to come along and withdraw all their validators, it does not alleviate this issue (as the api-key is stored in memory in the browser in order to get validator metrics/info). Therefore, Siren should not be used on public computers or where unauthorized actors may get access to the browser/app that is running Siren.
The Future
The future of Siren does have a rough roadmap, but we hope it's primarily guided by our users, so please play around, tell us what you think and feel free open feature requests and we'll try to accommodate to the best of our ability.
Lastly, it should be said that Siren could not have been completed without the extensive and excellent design work of Aqeel from Empire and the long-hours of development by our own Mavrick.