BIG THANKS TO @th3van for our test satellite
First off, Big Thanks to @th3van for sponsoring a test server for our test satellite, we are at the stage which our tutorial need some real interaction to see how satellite behave in production. I’m in the process of set up testing satellite and will ask for volunteer storage node, there will be a small benefit to join of course.
Today we study about vetting process and auditor, so what is vetting process and auditor?
Surprisingly, there was no explanation what is vetting process is, even in storj.dev, so here one:
What is Vetting?
A storage node begins as a “new node” (unvetted) when it first joins the network. It becomes vetted once it has passed a defined number of audits and has been online long enough. Vetting is how the satellite builds trust in a node before assigning it more data.
A node becomes vetted when both conditions are met simultaneously:
| Condition | Config Field | Production Default | Source |
|---|---|---|---|
| Minimum number of audits passed | AuditCount |
100 audits | satellite/reputation/config.go |
| Minimum time since node creation | MinimumNodeAge |
504 hours (21 days) | satellite/reputation/config.go |
What is Auditor?
The auditor is a sub command of satellite-modular, a background sub-process that continuously verifies data integrity to storage nodes. It runs as a background service on the satellite, continuously pulling segments from a queue, downloading a random data stripe from each piece holder, and using erasure-coding math to confirm nothing has been tampered with.
There are two separate pipelines:
- Verify pipeline — normal audits of full segments (many nodes at once)
- Reverify pipeline — follow-up audits of single pieces on nodes that timed out
Both queues live in the satellitedb SQL database — no separate job system (make sense since this data is important).
Notice that, if node is offline at audit time, it got penalty in offline reputation instead of data integrity one. Node gets at most 3 reverification attempts before being penalized (so 4 in total).
Timeout on Verify → contained (attempt 0)
Timeout on Reverify #1 → re-queued (attempt 1)
Timeout on Reverify #2 → re-queued (attempt 2)
Timeout on Reverify #3 → AUDIT FAILURE (reputation hit)
Minimum auditor command:
./satellite-modular auditor \
--identity-dir ./id/satellite/ \
--server.extensions.revocation false \
--database-options.url "cockroach://my_role:123456@rendezvous.example.com:26257/my_database?sslmode=verify-full&sslrootcert=ca.crt" \
--metainfo.database-url "cockroach://my_role:123456@rendezvous.example.com:26257/my_metainfo_database?sslmode=verify-full&sslrootcert=ca.crt" \
--orders.encryption-keys 88a2ab18c619535b=e9bbe3c658d595d5c40dba994152abc07109cdd4425fec627194bdec32c43333 # not a real key
Check out auditor flags to see what can you config with it ./satellite-modular auditor -h.
There is an interesting option --audit.use-ranged-loop but it seem like dead code (?) - so don’t mind it for now.
See you on part 12.