Storage node v0.23.0+ds.19

Storage node v0.23.0+ds.19 for Linux x86_64 (Ubuntu 24.04 or newer).

Running nodes install it by themselves within the staged-rollout window.
The archive is signed with ML-DSA-65; check it with:
ant-keygen verify --key release-signing-key.pub --input ant-node-cli-linux-x64.tar.gz --signature ant-node-cli-linux-x64.tar.gz.sig

The archive also contains LICENSE-MIT and LICENSE-APACHE, plus THIRD-PARTY-NOTICES.txt and RUST-STD-COPYRIGHT.html with the licences and copyright notices of the third-party code in the binary and of the tools used to build it.

What changes

ds.19 nodes work next to ds.18 and older nodes. They send no new kind of message, field or reply: every message ds.19 sends between nodes is one that every earlier release already reads and handles. What changes is how much a stored record costs the network in traffic between nodes: about 11.6 MB to about 1.7 MB for a tiny record, and about 180 MB to about 1.7 MB for a full 4 MiB chunk. No payment rule changes: what a client pays, and what every store and notice check requires, are as in ds.18.

Slim proofs between nodes

• What a node forwards. A client's PUT carries every quote it was given, each with its commitment sidecar, about 57 KB. Once a storer has accepted the record, the nodes it tells about it need only what their own check reads: the quotes at the median price (normally one) and the payment's transaction hashes. Notices, offers and pointer offers now carry only those, with no sidecars and every byte field written as a byte string: about 5.5 KB.
• Every release reads it. The proof's tag byte and field order are unchanged, so every release decodes a slim proof with the decoder it already has, and its payment check reads the same median quote and the same amount. A proof the storer can't slim (a merkle proof, one that doesn't decode, one whose quotes fail the payment check's own local checks, or one for another record) is not forwarded at all.

Holding notices

• "I hold it." A storer that has stored a record and written the key into its own paid list now tells the rest of the record's close group with a payment notice whose proof is empty: a holding notice. Every release ignores a notice with an empty proof, so it costs the receiver nothing, and records nothing there.
• A node that already held the record sends one too, when it answers a PUT "already stored": once per key in 20 seconds, for a key in its own paid list that it is responsible for.
• The rest of the paid group gets the slim proof at once, as before. A storer whose own paid-list write failed sends the slim proof to the whole paid group, close group included.

Offers only where they're needed

• The hold. After a store, a storer holds its offers for up to 10 seconds, the client's own wait for a store answer, so the other storers' holding notices arrive first. The hold ends sooner once every close-group peer has been heard from or is marked full.
• When it ends, each close-group peer the storer didn't hear from gets the notice with the slim proof at once, never behind back-pressure, and a peer not marked full is then offered the record. Normally every peer was heard from, and nothing more is sent. A peer heard from is one that sent this node, within 20 seconds, a holding notice, a notice with a proof, or an offer of the record.
• The close group here is the one ds.17 widens: the 7 nearest, one more for each peer marked full among them, at most 20. A peer marked full gets the notice with the slim proof and no offer; the nearest beyond stand in for it.
• Every peer is still checked. Every peer of the unwidened close group that the storer skipped or offered still gets its possession check: a skipped peer from when the hold ends, an offered peer from when its offer is dispatched. The stand-ins are offered the record and not checked, as in ds.17. A peer marked full that the record's payment didn't pay keeps ds.17's waiver.
• A hint for sending only. Being heard from never counts as proof that a peer holds a record: not for erasure, repairs, the paid-list quorum, audits or the "full" waiver. Those still rest on possession checks.
• When the node stops, the open holds' notices are sent before it does. A record removed or found unreadable during its hold sends no proof notice: an unreadable one sends its notices once a read finds it.

No answers to one-way offers

• A fresh offer sent as a one-way message is no longer answered: the sender doesn't wait for an answer, so it was sent for nothing. An offer sent as a request is answered as before.

Possession checks within a byte budget

• 64 MiB per node. A possession check takes a share of a node-wide budget the size of its record before it reads its copy, and gives it back when its last probe ends. Checks waiting behind a slow peer can no longer hold more record bytes than that; a check waiting for its share holds only its key and its peers.

Payment notices from one storer

• Each sender's share. A node admits 64 payment notices at once. One sender may now hold up to 48 of them, the pool less 16 kept for senders that hold none. With offers held, the notices a close-group peer still receives come from a storer whose hold ended without hearing from it, one per record, at the pace of the upload, so one storer's notices during an ordinary upload are no longer dropped.

New counters

• The fresh replication summary (a line on ant_node::replication::traffic, every 5 minutes, cumulative) counts every new path: holding notices and notices with a proof sent and received, offers sent and skipped (heard from, or marked full), how holds ended (early, at the hold time, or at the cap on held proofs), close-group peers left unserved when a hold ended (always 0), stored writes with no proof to send, proofs the slim builder declined, proofs refused for their form in notices, offers and pointer offers, possession checks scheduled by how each peer was served, checks waiting for the byte budget and the bytes running checks hold, confirmed possession failures on skipped peers, proof refusals, notices dropped at admission, and answers to one-way offers not sent.
• Sends per recipient. New lines on the same target, every 5 minutes, add <message>_sent_count and <message>_sent_bytes for every message between nodes, counted once per recipient and per attempt, beside the per-encoding <message>_tx_* fields. The "full" notice and the sync pages are counted too.

Updating the image (Docker)

ds.19 changes nothing in the image. Nodes install ds.19 by themselves, with everything above, whether or not you pull.

What ds.17's notes say about images still applies: the nodes status list of full nodes needs ds.17's image or later, and on an image older than the one that ships darwin-nodes, pull the new one (docker compose pull, then docker compose up -d).