Add local signer backup recovery flow#715
Conversation
ihordiachenko
force-pushed
the
feature/state_backup
branch
from
bf8917e to
c557661
Compare
cdecker
left a comment
cdecker
left a comment
There was a problem hiding this comment.
Hm, not quite sure this is the direction we should go. Calling the client API from the signer is not necessary as far as I can see. The idea was to just take a snapshot of the signer state, which contains all the relevant information to recover on its own, whereas this change is a sprawling change, injecting new client connections in a variety of places, and adding strong coupling.
The original issue had the following line:
Conclusion: VLS state contains all SCB data plus much more. Storing VLS state snapshots should be sufficient for disaster recovery.
| use std::io::Write; | ||
| use std::path::Path; |
There was a problem hiding this comment.
This would prevent us from compiling in no_std environments, of which we target wasm as well as embedded environments. This means we need to gate the use and functionality behind a #[cfg(...)] guard, so we can exclude these parts for no_std envs.
|
|
||
| mod approver; | ||
| mod auth; | ||
| mod backup; |
There was a problem hiding this comment.
We likely need to #[cfg(...)] guard to the mod, then we have a nice and clean separation.
| async fn process_request( | ||
| &self, | ||
| req: HsmRequest, | ||
| mut node_client: Option<&mut crate::node::ClnClient>, |
There was a problem hiding this comment.
I don't quite understand the logic behind pushing a backup side-effect into the processing itself, when we can do snapshot comparison in the caller.
| } | ||
| } | ||
|
|
||
| fn backup_peerlist_client(&self, channel: Channel) -> Result<Option<node::ClnClient>, Error> { |
There was a problem hiding this comment.
Not sure why we need a node::ClnClient here at all, we have all the necessary data in the signerstate already, so let's just extract from there.
2 participants
Adds opt-in local VLS signer backups with CLI inspection/conversion tooling. There are two available backup strategies:
new-channels-only: default, low I/O, snapshots when a channel first becomes recoverable.periodic: snapshots new recoverable channels and then refreshes after configured recoverable-channel updates, with more disk writesBackups can be created through:
Backups can be converted to CLN
recoverchannelinput with:Tradeoffs