Port onto @anyone-protocol/ao-client (D15/D16/D17) - #4
Open
jim-toth wants to merge 6 commits into
Open
Conversation
Second W4 port, following operator-registry-controller. Replaces
@permaweb/aoconnect 0.0.59, the local send-aos-message.ts wrapper, and the
vendored src/util/arbundles-lite (an old copy of Irys arbundles) with the shared
client and the maintained @dha-team/arbundles.
D17 — explicit endpoints. CU_URL is gone, replaced by a single HB_URL with NO
default (nodeUrlFromEnv fails closed).
Two reads reworked to the D4 design, and neither is a like-for-like swap:
1. The operator-registry read was a View-State dryrun that pulled all five
registry maps and used two. The native contract exposes `scoring` for exactly
this consumer, so it now asks for that slice. Note the view calls it
`hardware`, not `verifiedHardware`.
2. `Last-Snapshot` does not exist on the native contract, and could not: the
per-fingerprint `Details` are deliberately never persisted to state (they
would add ~3.6MB per round to a tree that is re-read constantly). They exist
only as the OUTPUT of Complete-Round, so getLastSnapshot now reads that
message's own slot via readSlotOutput.
(2) means the settle slot has to reach persistRound, which runs as a SEPARATE
BullMQ job. completeRound therefore returns the slot instead of a boolean, and
the existing parent/child return value carries it — the child already fed
getChildrenValues(). The slot travels, not the payload: a ~3.6MB snapshot has no
business in a Redis job result. persistRound keeps its Timestamp === stamp guard,
and now gets it from the exact round it settled rather than re-reading whatever
was latest.
Contract rejections are detected properly now. A rejected write returns HTTP 200
with the reason only in its own slot output, so the old code reported success for
writes that changed nothing; ao-client confirms the slot and raises
AoContractError.
Integration specs, 5/5 green against a local node holding the real migrated relay
-rewards and operator-registry state: a round settles, the snapshot comes back
from the settle slot WITH Details, and a stale round is correctly refused
("No pending round") rather than silently archiving the wrong one. Typecheck is
net -1 error against baseline and introduces none.
Declared as a direct dependency but never imported — the Arweave interaction all goes through the bundling service, which used the Turbo SDK. No effect on `npm audit`: arweave stays in the tree transitively via @ardrive/turbo-sdk and @dha-team/arbundles. This is declaration hygiene, so the manifest says what the service actually uses.
ArDrive left Arweave, and the SDK was doing very little here — sign a data item,
POST it — while costing a great deal.
What it dragged in, all of it now gone from the tree:
* @permaweb/aoconnect 0.0.57, bundled inside the SDK. Older than any pin this
migration removed, and it carries third-party default endpoints. So the
"aoconnect removed from every service" claim was true of our code and false
of the dependency tree.
* The entire Solana payment stack — @solana/spl-token, @solana/buffer-layout-utils,
bigint-buffer — inherited purely to upload to Arweave.
`npm audit` drops from 66/67/65 to 53/54/52 across the three.
The wire format is the one publish-module.ts already proved: POST the raw signed
item to `<bundler>/~bundler@1.0/tx`. That path is served both by up.arweave.net
— it is HyperBEAM's own default `bundler_ans104` target, see dev_arweave.erl
post_tx/4 — and by our own node. So moving to self-hosted bundling later is a
BUNDLER_NODE change, not a rewrite; the commented-out line above it in each HCL
records the two prerequisites (edge-allow /~bundler@1.0/tx, faff-allow-list the
signer).
BUNDLER_GATEWAY and BUNDLER_NETWORK are dropped — both existed only to configure
Turbo.
The three copies of this service had drifted into three distinct implementations
differing by one line; they are byte-identical again.
Non-breaking advisory fixes only; no direct dependency changed, lockfile only. Production vulnerabilities 37 -> 22 (high 13 -> 8). Tracked with `npm audit --omit=dev`: the all-inclusive headline moves the wrong way because the tree now resolves fully and the growth is dev-only tooling (jest, eslint, the Nest CLI) that never ships. Build clean.
Clears all 3 production criticals. These came from @dha-team/arbundles, which pins the EOL @ethersproject v5 line; arbundles 1.0.4 is already latest and the advisory range is `*`, so there was no upgrade to take — npm's suggested "fix" is a downgrade to 1.0.3. But the advisories are version-exact and both packages already ship fixes: elliptic critical hits <=6.6.0, patched in 6.6.1 secp256k1 high hits exactly 5.0.0, patched in 5.0.1 Both were installed twice — the patched version hoisted at the root, and a vulnerable copy nested under arbundles that its ethersproject chain resolved to. An override collapses them onto the patched ones, so this needs no change to arbundles or to ethers (our own code is already on v6.17). Verified rather than assumed: these are the ECDSA signing primitives, so a clean build proves nothing. The integration specs were run against a real node holding real migrated state, exercising ANS-104 signed writes end to end — operator registry 5/5 (registration credits, operator certificates) and relay rewards 3/3 (settles a round, reads the snapshot back from the settle slot). One low remains in elliptic with range <=6.6.1, i.e. unfixed at latest.
Declared but imported nowhere. GeoIpService does not use it — it fetches /fingerprint-map/ from api-service over HTTP, so the geolocation data comes from there, not from a local database. It was the single largest source of production advisories left in this service. It pulls rimraf 2 -> glob 7 -> minimatch 3 -> brace-expansion 1, and every high in that chain came from it. Its spec baseline is unchanged: 4 failed / 1 passed before and after, the failures being pre-existing and requiring a live api-service at ANYONE_API_URL. --- Clears the last production highs. @dha-team/arbundles pulls @ethersproject/providers 5.7.2, which pins ws 7.4.6 — inside the advisory range 7.0.0 - 7.5.10 for two DoS reports. Same nested-vs-hoisted shape as elliptic and secp256k1: a safe ws 8.21.0 sits hoisted for ethers v6 while the vulnerable 7.4.6 sits nested. The override is SCOPED to @ethersproject/providers so ethers v6 keeps ws 8; forcing ws 7 globally would break it. 7.5.13 is the patched 7.x line, so ethersproject stays on a compatible major. This also clears the aggregate advisories on @dha-team/arbundles and @ethersproject/providers themselves, which were flagged only by way of their vulnerable leaves. With elliptic, secp256k1 and now ws all patched, nothing is left — so the cluster was never actually blocked on arbundles leaving ethersproject v5, as previously recorded. Worth stating plainly: these are DoS bugs in WebSocket frame handling, and nothing on this path opens a WebSocket — arbundles pulls @ethersproject/providers for wallet and provider types, and no WebSocketProvider is ever constructed. This is noise reduction, not risk reduction. Verified against a real node holding real migrated state: the operator-registry integration spec passes 5/5 including ANS-104 signed writes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second W4 port, following operator-registry-controller. Replaces @permaweb/aoconnect 0.0.59, the local send-aos-message.ts wrapper, and the vendored src/util/arbundles-lite (an old copy of Irys arbundles) with the shared client and the maintained @dha-team/arbundles.
D17 — explicit endpoints. CU_URL is gone, replaced by a single HB_URL with NO default (nodeUrlFromEnv fails closed).
Two reads reworked to the D4 design, and neither is a like-for-like swap:
The operator-registry read was a View-State dryrun that pulled all five registry maps and used two. The native contract exposes
scoringfor exactly this consumer, so it now asks for that slice. Note the view calls ithardware, notverifiedHardware.Last-Snapshotdoes not exist on the native contract, and could not: the per-fingerprintDetailsare deliberately never persisted to state (they would add ~3.6MB per round to a tree that is re-read constantly). They exist only as the OUTPUT of Complete-Round, so getLastSnapshot now reads that message's own slot via readSlotOutput.(2) means the settle slot has to reach persistRound, which runs as a SEPARATE BullMQ job. completeRound therefore returns the slot instead of a boolean, and the existing parent/child return value carries it — the child already fed getChildrenValues(). The slot travels, not the payload: a ~3.6MB snapshot has no business in a Redis job result. persistRound keeps its Timestamp === stamp guard, and now gets it from the exact round it settled rather than re-reading whatever was latest.
Contract rejections are detected properly now. A rejected write returns HTTP 200 with the reason only in its own slot output, so the old code reported success for writes that changed nothing; ao-client confirms the slot and raises AoContractError.
Integration specs, 5/5 green against a local node holding the real migrated relay -rewards and operator-registry state: a round settles, the snapshot comes back from the settle slot WITH Details, and a stale round is correctly refused ("No pending round") rather than silently archiving the wrong one. Typecheck is net -1 error against baseline and introduces none.