Skip to content

Storage node v0.23.0+ds.16

Choose a tag to compare

View all tags
@github-actions github-actions released this 27 Oct 04:05
· 113 commits to main since this release
Immutable release. Only release title and notes can be modified.
v0.23.0+ds.16
1315dcc

Storage node v0.23.0+ds.16 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

Every change in this release is local to each node: nodes send each other no new messages, and ds.16 nodes work next to ds.15 nodes. Prices and quotes don't change.

Payment checks spare chain reads, and answer a store in time

  • Payment facts. A node keeps up to 16,384 payment facts by quote hash: the amount paid and the payee, and only for payments the vault recorded. An empty record, a missing receipt, an error or a timeout is never kept. A fact that pays the quote settles it with no further read. A quote with no fact, or one its fact doesn't pay, is read from the vault's record (completedPayments) as before, and every refusal still comes from that read.
  • Receipts. The node reads the receipts of the first 4 distinct transactions a proof names, and counts only the vault's DataPaymentMade logs in a receipt whose transaction succeeded. One receipt can settle a whole wave of chunks.
  • Batched reads. Reads of one record at once share a single call while it is in flight. Record reads made while another is in flight go together as one JSON-RPC batch of up to 32 calls. An RPC that refuses batches, or leaves calls out of its answer, is read one call at a time.
  • A deadline inside the client's wait. Released clients wait 10 seconds for a store's answer, so a store's whole payment check, the envelope lookup included, now ends within 7 seconds. Each call has 2.5 seconds. A call still unanswered after 2 seconds also goes to the second RPC, and the first good answer counts. On a store, the proof's receipts get a 500 ms head start before the record read starts beside them. At the deadline, the store is refused with the payment error, and the reads still in flight fill the facts, so the client's next try passes.
  • Hold-off. An RPC that answered busy, or didn't answer in time, is asked after the others for 30 seconds. Background reads (fresh replication offers, paid notices, listings) give each call 15 seconds.
  • Unchanged: reads fall back across RPCs in up to 2 rounds, 0.5 seconds apart. A record that reads empty is read once more 1.5 seconds later, now on a fresh connection, at the next RPC when there is one.
  • Paid notices for a key the node's paid list already holds are dropped before they are admitted.
  • The RPC traffic figures count receipt reads, batches and block reads as their own kinds.

Default RPCs: Robinhood Chain's RPC and PublicNode

  • The node's built-in public RPCs are now PublicNode (robinhood-rpc.publicnode.com) and Robinhood Chain's own RPC (rpc.mainnet.chain.robinhood.com). A node whose RPC is one of them falls back to the other. A node on https://rpc.ordofi.network falls back to both (below). A node on any other RPC reads through that RPC alone.
  • The image's default RPC_URLS is now Robinhood Chain's own RPC alone. It was Robinhood Chain's RPC and rpc.ordofi.network.
  • rpc.ordofi.network is no longer built in. A node whose RPC is https://rpc.ordofi.network (trailing slashes aside) still reads payments through it first, then falls back to the two built-in RPCs; a node on any other form of it, such as http://rpc.ordofi.network or one with a path or query after it, reads through it alone. No node falls back to rpc.ordofi.network. The new image prints a notice at start when RPC_URL or RPC_URLS names it, saying which of these applies. To use the image's RPCs, delete RPC_URL and RPC_URLS from docker-compose.yml, pull the new image (see "Updating the image" below), then run docker compose up -d.
  • To see which RPC each node uses, look for RPC host in the node logs (docker compose logs | grep 'RPC host'). Each node logs only the RPC's host, never the rest of its URL.

Browser access: higher limits, a quick refusal, and your own config file

  • New defaults:

    • 128 browser sessions per node (was 32);
    • 7 sessions from one IPv4 address or IPv6 /64 (was 4);
    • 256 data channels across the node (was 32), two for each session.

  • Unchanged: 16 concurrent requests; 256 requests a second per node, 32 per address and 16 per session; 64 MiB of bytes in flight per node and 16 MiB per address; and new sessions from one address at a burst of 12, then 6 a minute.

  • The session ceiling. A node refuses more than 256 sessions at start, with a message naming the setting. 256 is the most the transport (saorsa-transport 0.38.2, now required) holds.

  • Bytes in flight. A browser GET reserves bytes in proportion to its record's stored size, no longer three times the largest record. More small records are read side by side, with no more bytes in flight than before.

  • A used-up channel pool refuses only the new channel. It no longer closes the browser's whole session.

  • The quick refusal. A node at its session limit, for the whole node or for one address, answers a new browser's connection check with a STUN 486 within about a second. Before, the browser waited out its connection timeout.

  • Refusals are logged by the limit reached, per address and in total, every five minutes (browser refusals (cumulative)).

  • Lowering a limit in Docker. Write the values in a node config file, for example node.toml next to docker-compose.yml:

    [webrtc_direct]
max_connections = 64
max_connections_per_ip = 4

    Mount it under volumes: as - ./node.toml:/etc/storage-node/node.toml:ro and run docker compose up -d. The log then says Nodes read /etc/storage-node/node.toml.

    • The settings the image passes itself (ports, rewards address, RPC, bootstrap peers, ANT_RELAY_SERVING) still take precedence over the file's.
    • A mount whose file doesn't exist is refused, with what to do.
    • The relations lowered values must keep are in docker/README.md, "Your own node settings".
    • Mounting the file takes the new image.

Full at 1 GiB free

  • The new line. Nodes now stop taking new data at 1 GiB free, where ds.15 stopped at 500 MiB: they refuse to store a record that would leave less. Each node therefore stores up to 500 MiB less.
  • Why. The node manager in images older than the one that ships darwin-nodes deletes a node's data at 500 MiB free. The higher line keeps the nodes' own writes away from that point.
  • Your own setting. The disk_reserve_mb default is now 1024; a value you set yourself is still used.
  • Refusal logs. At the line, each kind of refused store is logged once, then counted for five minutes; the next line says how many were held back.

Capped logs

  • Rotation and cap. Each node's log files start anew at 50 MiB or each hour, whichever comes first, and take at most 500 MiB in all; the oldest are deleted first. They rotated daily, with no size bound. --log-max-files still limits the number of files, and its help text no longer says rotation is daily.
  • At the 1 GiB line, logs give way. A node deletes its oldest log files first, then writes only warnings and errors into the room that frees, and nothing once none are left to delete. When the disk has room again, it logs how many lines it dropped.
  • The browser refusal counts and the hourly commitment line are kept at the line, as warnings are.

Upgrade timing and the space check

  • Timing. A node's staged-rollout delay, within the 24 hours after a release, now counts from the release's publication time, by GitHub's clock. A restart no longer starts the delay again, and a node that sees a release after its due time takes it at once. A release without a publication time, or with one in the future, counts from when the node first sees it, as before.
  • The first check. A node first checks for releases at a random point 1 to 5 minutes after it starts. It used to wait about an hour.
  • This release's own rollout runs on ds.15's timing. The new timing applies from the next release.
  • The space check. Before downloading, a node checks that its upgrade's writes leave at least 256 MiB above 500 MiB free. The writes are the archive twice and the binary twice. If they don't fit, the node skips the cycle with one log line and tries again at its next check. A node at the 1 GiB line still upgrades.
  • One node at a time. The nodes of one machine upgrade one after another, under a lock file in the shared upgrade cache.
  • Cache pruning. After a clean start, a node prunes the upgrade cache to the running version, the one before it, and any newer one a node on the machine is upgrading to.

The image marker

  • Images from the one that ships darwin-nodes on pass each node the commit the image was built from.
  • A ds.16 node reports it in its user agent, after its version (node/0.23.0+ds.16.image.<commit>), so the network's node census can count the installs still on an older image.
  • A node with no marker logs one warning at start: No image marker (ANT_IMAGE_VERSION): ... pull the new image. A node run outside Docker logs the same line, and can ignore it.

The hourly commitment line

Every hourly storage commitment tick now logs one info line, Storage commitment tick, with the number of records committed to, whether or not the commitment changed.

Updating the image (Docker)

Auto-upgrade replaces only each node's binary. The rest of the container changes only when you pull a new image: docker compose pull, then docker compose up -d. ds.16's image brings:

  • the node manager darwin-nodes, which deletes no node's data however full the disk gets. Its status warns at 1 GiB free and reports the disk as critical at 500 MiB;
  • a cap on the node manager's own log: a new file every 10 MiB or hour, at most 50 MiB in all, giving way at 1 GiB free as the nodes' logs do;
  • the new default RPC_URLS, and the notice for rpc.ordofi.network;
  • the node config file at /etc/storage-node/node.toml;
  • the image marker, for installs on images older than the one that ships darwin-nodes.

Without the pull, the nodes still install ds.16 by themselves, with everything above that is part of the node: payment checks, browser limits, the 1 GiB line, capped logs, upgrade timing. Then:

  • If docker exec storage-node darwin-nodes --version fails, your image still runs Autonomi's node manager. At 500 MiB free it deletes the data of the node holding the least (never the last one). ds.16 nodes stop their own writes and logs at 1 GiB free, but other writers on the same disk can still bring it to 500 MiB. Each node logs the no-marker warning at start. Pulling the new image is the fix.
  • If it works but you haven't pulled since this release, your node manager deletes nothing, but its own log rotates daily and keeps 30 files, with no bound on a file's size, and you can't mount a node config file.
  • On images from ds.7 up to those built before this release's default RPC_URLS (including the first images that ship darwin-nodes), with 2 or more nodes and no RPC_URL, some nodes (with 2 nodes, the second) are given rpc.ordofi.network by the old default RPC_URLS. On ds.16 those nodes read payments through it first and still fall back to the built-in RPCs (see "Default RPCs" above). To read through the image's RPCs instead, pull the new image. An RPC_URL of your own replaces them and is read alone, with no fallback.
Assets 7
Loading