Vdash - Node dashboard for Safe Network

Hmmm :thinking: But yours aren’t?


Similar with zgrep

root@localhost:~# zgrep ValidSpendRecordPutFromNetwork .local/share/safe/node/*/logs/* | wc -l
root@localhost:~# zgrep ValidRegisterRecordPutFromNetwork .local/share/safe/node/*/logs/* | wc -l
root@localhost:~# zgrep ValidChunkRecordPutFromNetwork .local/share/safe/node/*/logs/* | wc -l
root@localhost:~# zgrep "Wrote record" .local/share/safe/node/*/logs/* | wc -l

Is that not 2048? – poss 2047?

1 Like

This is of general interest for anyone programming in Rust.

It highlights the extreme vulnerability of Rust’s dependence on crates.io as a single point of failure, and as a system easily susceptible to supply chain interference.

I’m posting here as a reply to the comments about packaging Rust dependencies in Debian, because the article explains how to use those packages to mitigate the risks of depending on crates.io alone.

I suggest that these measures, as well as others mentioned in the article would be wise to look into for Safe Network, because the failure of an outage of crates.io risks bringing development to a halt. Cc @chriso


@happybeing In preparation for the next testnet I thought I’d update my Pi. Even after running:-

rustup default stable
rustup update

I’m getting this:-

   Compiling vdash v0.14.2
error[E0283]: type annotations needed
   --> /home/safe/.cargo/registry/src/index.crates.io-6f17d22bba15001f/vdash-0.14.2/src/bin/../custom/ui_node.rs:426:4
426 |         .constraints(constraints.as_ref())
    |          ^^^^^^^^^^^             ------ type must be known at this point
    |          |
    |          cannot infer type of the type parameter `C` declared on the method `constraints`
    = note: multiple `impl`s satisfying `Vec<Constraint>: AsRef<_>` found in the `alloc` crate:
            - impl<T, A> AsRef<Vec<T, A>> for Vec<T, A>
              where A: Allocator;
            - impl<T, A> AsRef<[T]> for Vec<T, A>
              where A: Allocator;
help: consider specifying the generic argument
426 |         .constraints::<&T>(constraints.as_ref())
    |                     ++++++

For more information about this error, try `rustc --explain E0283`.
error: could not compile `vdash` (bin "vdash") due to previous error
error: failed to compile `vdash v0.14.2`, intermediate artifacts can be found at `/tmp/cargo-install36NhtM`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.

These are my versions:-

rustc -V
rustc 1.74.0 (79e9716c9 2023-11-13)

cargo -V
cargo 1.74.0 (ecb9851af 2023-10-18)

uname -a
Linux sn-test-02 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux

What I’ll do next is try the whole thing on a different machine and see if I get the same result.

1 Like

My apologies, you are ahead of me. If you switch to v1.73 all should be well.

I’ll look into this, thanks for the report.

EDIT: fixed in next release.


vdash v0.15.0 adds checkpoints! :partying_face:

NOTE: you may see error messages when vdash starts up but you can ignore them. I’ll clean that up later!

This update means you can stop vdash at any point and re-start it and it will both get started much quicker and more importantly, not lose any statistics due to logfile rotation. Providing you don’t wait too long to restart vdash that is. If a logfile is rotated after a checkpoint, you would lose any cumulative data (e.g. PUTS, GETS, ERRORS) and timeline data in slots that fall between the checkpoint and the end of the rotated logfile, so still not much.

Beware, I have not done much testing but am releasing in case those sneaks start a testnet while I’m travelling…

For more on how to update etc see this reply.

Rust Wins Again

I had expected this feature to take me weeks to implement but it has taken only a few days due largely to the amazing Rust ecosystem. Even as a first time user of the serialisation library serde I have been able to save and load a complex set of structs and values, including hashmaps, vectors and many other types with minimal effort by using a few macros. Most of the work has been in application logic which was fairly straightforward, along with some refactoring to accommodate that.

Rust :clap:


Amazing! That was it. Now I’ll know not to jump the gun and what to try if I do!


I noticed this anomaly in the node number column

This may be down to me starting these local nodes on my own LANnet with a script that includes a sleep 10 in the loop. I stopped and restarted vdash twice in the 30 x 10 secs it took for the script to complete.

1 Like

Another good catch from the Bugfinder General!

If you were restarting vdash while starting new nodes I can see why this might happen.

I’ll have a think about a fix. Thanks for the report.


This is a bit of a non-issue, really. If I had RTFM’d and used the ‘R’ command instead of hitting it with the ‘q’ hammer, I suspect all would be well.

Possibly make the ‘R for reload’ command more prominent? said he, weakly…

1 Like

The user is king :rofl:


vdash v0.15.3 fixes a few things including one serious bug in the new checkpoints feature which I’m afraid means you can’t reload older checkpoints with this new version.

So best only update for the next testnet or when starting all nodes from scratch.

For more on how to update etc see this reply.