Keyless TEST candidate sync receipt

This is an initial sync diagnostic, not validator admission. It addresses a specific onboarding gap: an operator can now collect one bounded, sanitized receipt from their own running TEST node and let another party recheck its block history. No wallet, secret, signature, transaction, bond or role ACK is involved. It does not change M0, the frozen round, settlement or compensation terms.

Authenticate the operator archive through the release index, inspect its sources, and first complete the operator README's explicit node/Tor setup. Existing installations retain their own keys, genesis and chain data. Do not replace them with files from an archive. Copy/review only public source updates, including scripts/pilot-node-proof.mjs, scripts/pilot-node-proof.sh and compose.pilot-proof.yaml.

Observe, persist, share, recheck

From the operator package root, after your TEST candidate is synchronized:

sh scripts/pilot-node-proof.sh help
sh scripts/pilot-node-proof.sh observe candidate-a.json --rpc http://pilot-node:8545
sh scripts/pilot-node-proof.sh verify candidate-a.json

The explicit one-off service joins the existing operator Compose network. It does not start/recreate the node or its dependencies. The wrapper rejects remote Docker endpoints, creates a missing mode0700 receipt directory only for explicit observe, and stats its owner inside a keyless container before selecting the UID/GID for observation. This supports rootless UID remapping without broadening file permissions. Existing insecure or symlinked receipt directories fail closed; inspect/fix your own directory explicitly instead of bypassing the check. Wrapper help starts no container and creates no files. Use a local Docker context. The only writable mount is state/pilot/proofs; the script and public TEST manifest are read-only. No keys, chain database, socket, provider credential or RPC host port are mounted/exposed. The helper is separately capped at 128 MiB / 0.5 CPU, outside Besu's unchanged 512 MiB / 1 CPU budget. Linux Docker Engine and the existing Linux Docker Desktop image path are used; no real macOS host run is claimed.

Linux users with Node.js 22+ may instead run the same keyless script natively:

umask 077
mkdir -p state/pilot/proofs
node scripts/pilot-node-proof.mjs observe candidate-a.json --rpc http://127.0.0.1:28545
node scripts/pilot-node-proof.mjs verify candidate-a.json

Native receipt I/O intentionally requires Linux directory-fd semantics. Native Windows/macOS are not supported by this helper; use the pinned Linux container. This is separate from the existing native POSIX role-ACK interface. Never expose ADMIN RPC to the Internet to let someone else run the observer.

Observation checks TEST chain 2026090604 and the packaged genesis, requires eth_syncing=false, a node public key different from the packaged bootstrap, and the bootstrap peer at both ends. It captures a baseline and ten subsequent consecutive blocks, checks parent hashes and timestamps, then compares all eleven headers against the fixed https://tokn.bepc.cc/testnet/rpc. Initial/final headers must be within 60 seconds of the local clock; the operation has a 180-second deadline. Individual RPC reads have a 10-second deadline and bounded response sizes. Redirects, credentials, non-loopback native ADMIN URLs, transaction methods, wrong chain/genesis and public-RPC fallback are rejected.

Success saves one tokn-pilot-node-proof/1 JSON document at state/pilot/proofs/candidate-a.json, mode0600, through exclusive atomic publication, file/directory fsync and exact-byte readback. A pre-existing name is never overwritten: use verify for an existing receipt, or a new name for a new observation. A failed final filesystem check can leave an existing receipt for inspection; preserve it. Fsync syscall success is not a claim that sudden power loss or every storage device/filesystem has been tested.

Review the receipt before sharing. It contains public node/peer IDs, TEST chain/genesis, the observation interval and eleven block headers. It deliberately omits IP/onion addresses, full ADMIN responses, wallet addresses, host paths and free-text fields. Share only this exact JSON and the emitted SHA-256 through an authorized channel, not the entire state directory. The hash authenticates no sender by itself; the receiving party must obtain the expected hash and node ID through an authenticated channel and request a new observation when freshness matters. Verification parses data only and does not execute peer code.

A verifier can place the received file under their private state/pilot/proofs/ directory and run sh scripts/pilot-node-proof.sh verify candidate-a.json. They must use their own authenticated operator package, not a sender-supplied script. The output reports canonicalHistoryMatches, observation age and the digest of the actual file. A future observation time beyond five seconds of clock skew is rejected; this timestamp check authenticates no observer. It does not report current liveness. Old receipts remain historical evidence; reverification neither refreshes their observation time nor proves the node is still running.

Limits and failure interpretation

The observer trusts the local RPC report. A proxy or fabricated local server can copy canonical headers and report an invented node/peer ID; this tool cannot cryptographically prove a process, host, key possession or controller independence. HTTPS recheck also trusts the current centralized canonical gateway; it is not a QBFT light client or independent seal verification. A same-controller local probe is useful QA and counts as zero independent operators.

Initial bootstrap connectivity is not full mesh, continuous uptime or admission readiness. Later admission requires each operator's separately consented role, control review, agreed roster, reciprocal signed observations, bonds, the actual notice and bootstrap-offline/recovery gates. The first cohort remains one bootstrap plus three independently controlled external validators, not merely four matching receipts. No TEST/production reward or market value follows from this diagnostic.

The read methods follow Besu's admin_nodeInfo, admin_peers, eth_syncing and block RPC interfaces. See the Besu API reference and JSON-RPC 2.0 response requirements.