chore: sync v0.7.3 to arc-node

[circle-github-action-bot]

Automated final release sync.

Release tag: v0.7.3
Release branch: release/0.7
Release kind: patch

[osr21]

Automated release sync, but there is substantial technical content worth reviewing. Five things stand out:

---

1. Zero8 hardfork — what changes and what it means for DApp builders

Definition (hardforks.rs):

Zero8, // v0.8 hardfork — delegatecall rejections charge the uniform early-revert penalty

Behavior change (helpers.rs, check_delegatecall):

Before Zero8, a delegatecall targeting a precompile address gets a plain revert with full gas refund:

PrecompileErrorOrRevert::new_reverted(*gas_counter, ERR_DELEGATE_CALL_NOT_ALLOWED)

After Zero8, it charges the uniform early-revert penalty (200 gas) before reverting:

PrecompileErrorOrRevert::new_reverted_with_penalty(
    *gas_counter,
    PRECOMPILE_EARLY_REVERT_GAS_PENALTY, // 200
    ERR_DELEGATE_CALL_NOT_ALLOWED,
)

This aligns delegatecall rejections with the Zero6 precedent applied to unauthorized caller, blocklist, zero-address, zero-amount, and overflow reverts — all of which already charge the 200-gas penalty. Zero8 closes the last precompile rejection category that was still getting a free revert.

Testnet activation: zero_8_time is added as Option<u64> to ArcGenesisInfo but is not set in the testnet hardfork schedule in this PR. Testnet activation timestamp is deferred — a separate genesis config update will be needed. Localdev activates Zero8 at timestamp 0.

DApp builder impact: Any contract that uses delegatecall targeting an Arc precompile address in a way that gets rejected should expect 200 gas charged on reversion after Zero8 activates. Contracts that never delegatecall to precompile addresses are unaffected.

---

2. App-request processing moved to a dedicated task — StatusSnapshot staleness

The consensus app loop (app.rs) now spawns process_app_requests as a separate tokio::spawn task. The main loop publishes a StatusSnapshot over a watch::channel after each message, and the spawned task reads from that channel to serve /status and /certificate requests without blocking consensus.

This is a clean design. One implementation detail worth noting, documented in state.rs:

The snapshot is eventually consistent with State: it is republished after the consensus loop finishes handling a message, so a reader may observe a snapshot that is up to one consensus-message stale.

The /status handler uses the snapshot's (height, round) to query store.get_undecided_blocks(self.height, self.round). If consensus advances between snapshot publication and the DB query resolving, the (height, round) passed to get_undecided_blocks may be stale — the call could return an empty list even if proposals are pending at the new height. Consumers reading undecided_blocks_count from the response should treat it as an eventually-consistent approximation, not a precise live count.

GetCertificate variant changed from tuple to struct match:

// before
AppRequest::GetCertificate(height, reply) => { ... }
// after
AppRequest::GetCertificate { height, reply, .. } => { ... }

Any external test fixtures or tooling that pattern-matches on AppRequest will need updating.

---

3. app_request_full_count — the most operationally important new metric

Four new metrics are added. Three are latency histograms. The fourth is the one operators should alert on:

• arc_malachite_app_app_request_full_count{request=...} — incremented when the app-request channel is full and an incoming request is rejected rather than queued.

A rising value means the spawned task is processing requests slower than they arrive. In practice this surfaces as /status or /certificate calls returning errors intermittently rather than being slow. Recommend alerting at any non-zero rate over a 1-minute window.

One gap: the channel capacity for the app-request queue is not visible in this diff. Knowing that bound would help operators tune the alert threshold and understand at what request rate the counter will start firing.

---

4. record_missed_rounds log volume under sustained proposer failure

record_missed_rounds (started_round.rs) emits one warn! per skipped round:

warn!(%missed_proposer, %height, %missed_round, "Consensus round missed");
metrics.inc_consensus_round_missed(missed_proposer);

The per-round counter is the right signal for dashboards. The per-round warn! becomes noisy when a proposer is offline for an extended window. At a 1-second block time with a 30-second timeout per round, a single offline validator during one height produces ~30 log lines in rapid succession at the next StartedRound event.

A structured summary log ("height N: rounds A–B skipped, proposer=0x...") alongside the existing per-round lines would reduce noise without losing information, since the counter already provides per-proposer granularity for dashboards.

---

5. Malachite consensus library rev bump — no changelog visible

All 13 arc-malachitebft-* crates are bumped from 8ee5d998 to 5cd137fb. The crates are pinned to a git commit rather than a semver tag, so no changelog is attached to this PR for what changed in the consensus engine. The only visible API surface change driven by this bump is the GetCertificate variant restructuring from tuple to struct form.

It would be useful to include a one-line note in the PR body or a linked commit range for 8ee5d998 → 5cd137fb, especially since this is a patch release where unexpected consensus behavior changes would be high-severity.