ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, a malicious block producer can terminate zebrad by placing the same shielded transaction in a non-finalized parent block and its child. In zebra-state/src/service/non_finalized_state/chain.rs, Chain::push originally inserted the transaction hash into tx_loc_by_hash and asserted uniqueness before updating shielded data and running the duplicate Sprout, Sapling, or Orchard nullifier checks. The repeated transaction therefore reached the transactions must be unique within a single chain assertion before contextual validation could reject it cleanly. Zebra release builds use panic equals abort, so the reachable assertion terminates the entire process; exploitation requires either two consecutive attacker-mined blocks or an attacker-mined child immediately after an honest block includes the attacker's shielded transaction. This issue is fixed in version 4.5.0.

Affected: crates.io: zebra-state, crates.io: zebrad

### Am I affected

You are affected if:

1. You run `zebrad` up to and including `v4.4.1`. 2. Your node processes blocks past the checkpoint height (non-finalized state is active). 3. The network has NU5 or later activated.

All default configurations are affected.

### Summary

`Chain::push` in the non-finalized state updates the transaction-location index (`tx_loc_by_hash`) before it runs the duplicate shielded-nullifier guard. When an invalid child block repeats a shielded transaction from its non-finalized parent, the `assert_eq!(prior_pair, None, "transactions must be unique within a single chain")` fires before the contextual validation that would cleanly reject the duplicate. Under Zebra's `panic = "abort"` release profile, this terminates the entire node process.

The block should be rejected with a duplicate-nullifier contextual validation error. Instead, the ordering of index updates within `Chain::push` causes the process to abort.

### Details

In `zebra-state/src/service/non_finalized_state/chain.rs:1608-1628`, the block push sequence is:

1. Insert transaction hash into `tx_loc_by_hash` with `assert_eq!` on uniqueness 2. Update transparent outputs and inputs 3. Update shielded data (JoinSplit, Sapling, Orchard) — including nullifier uniqueness checks

The shielded nullifier uniqueness check at step 3 would correctly reject the duplicate transaction. But the `assert_eq!` at step 1 fires first because the transaction hash is already in `tx_loc_by_hash` from the p…