Dev hyper aos migration - #4
Open
jim-toth wants to merge 13 commits into
Open
Conversation
Third W4 port. Replaces @permaweb/aoconnect 0.0.59, the local send-aos-message.ts
wrapper, and the vendored src/util/arbundles-lite 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).
Reads reworked to the D4 design:
- The operator-registry read was a View-State dryrun pulling all five registry
maps to use two. It now asks for the `scoring` view, which the native contract
added for exactly this consumer. Note the view calls it `hardware`, not
`verifiedHardware`.
- `Last-Snapshot` becomes the `last_snapshot` view, which returns PreviousRound
verbatim and matches the RoundSnapshot DTO 1:1.
That second point is where staking DIVERGES from relay-rewards, and the
difference is in the contracts rather than the clients. Relay must read its
snapshot from the Complete-Round SETTLE SLOT because it deliberately does not
persist per-fingerprint Details (~3.6MB a round across 9750 entries). Staking's
Details are per-HODLER and small enough to keep in state, so PreviousRound
survives and a plain view read is enough. completeRound therefore stays a boolean
here and no BullMQ job plumbing changes — unlike the relay port. The comment on
getLastSnapshot says so, and the spec asserts Details are present so a future
change to that decision trips a test rather than silently archiving less.
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
staking-rewards and operator-registry state: a round settles and reads back with
Details, and a stale round is refused ("No pending round") rather than reported
as settled. Typecheck is net -1 error against baseline and introduces none.
NB the spec needs EVM_JSON_RPC and HODLER_CONTRACT_ADDRESS set even though it
never dials them — this service's constructor hard-requires them, where
relay-rewards gates the same code behind USE_HODLER. Documented in the spec
header.
Both HCLs rendered ANYONE_API_URL from the api-service Consul service, and the README documented it, but nothing in src/ has ever read it. Unlike operator-registry-controller and relay-rewards-controller, this service has no geo-ip module — staking rewards are derived from token holdings, not relay geography — so there is nothing here to fetch /fingerprint-map/ for. The cost of leaving it was a phantom dependency: the template made this job look like it needs api-service to render, which is misleading when reasoning about deploy ordering. Found while sweeping for consumers that read AO state via api-service. There are none; api-service's only AO-derived endpoint is /operators, whose sole consumer is the dashboard.
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 33 -> 16 (high 11 -> 3). 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.
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.
Rides on the first batch; the contract takes the last per operator.
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
1 participant
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.
No description provided.