feat(realtime): encrypt proposal blobs and consume forced inclusions

[AnshuJalan]

Summary

Wires the realtime proposer for the cross-stack privacy feature and re-enables forced-inclusion consumption against the new RealTimeInbox queue.

• Encryption — new realtime/src/privacy/ with ProposalCipher (AES-256-GCM with a fresh OsRng nonce per blob). Applied at both manifest-building sites — the L1 proposal builder and the async Raiko-request builder — so the bytes Raiko sees match what's hashed on L1.
• Forced inclusion consumption — ExecutionLayer.send_batch_to_l1 reads getForcedInclusionState() each propose tick, computes numForcedInclusions = min(pending, fi_max_per_proposal), and threads it into ProposeInput / ProposeInputV2. The contract reverts with UnprocessedForcedInclusionIsDue if the cap is below the due count.
• Config — SURGE_PRIVACY_MODE, SURGE_PRIVACY_SYMMETRIC_KEY, FI_MAX_PER_PROPOSAL new env vars on RealtimeConfig. Privacy mode without a key fails fast at startup. ABI regenerated to expose the new contract methods.
• No ECIES in Catalyst — Catalyst never decrypts FI blobs; submitters encrypt them off-system to PK_sys.

Companion PRs:

• surge-taiko-mono#300 — protocol contracts + driver decryption
• raiko — prover decryption (cipher module + host CLI + guest hash-binding)

See PRIVACY_STACK.md for the cross-stack design reference.

[AnshuJalan]

@claude review

[claude]

Claude finished @AnshuJalan's task in 3m 0s —— View job

---

PR Review: feat(realtime): encrypt proposal blobs and consume forced inclusions

Todo:

• Read changed files
• Review realtime/src/privacy/aes.rs (crypto implementation)
• Review realtime/src/privacy/mod.rs (ProposalCipher)
• Review realtime/src/l1/execution_layer.rs (forced inclusion logic)
• Review realtime/src/l1/proposal_tx_builder.rs (encryption at proposal build)
• Review realtime/src/node/proposal_manager/async_submitter.rs
• Review config changes (realtime/src/utils/config.rs, realtime/src/l1/config.rs)
• Review bindings/ABI changes
• Address CodeQL security findings
• Post final review

---

Overall this is a clean, well-structured addition. The AES-256-GCM crypto layer itself is correct, the fast-fail config validation is good, and the forced-inclusion wiring is straightforward. There is one critical correctness bug in privacy mode, one security hygiene issue with the key in Debug output, and a few smaller items below.

Critical: Double-Encryption Nonce Mismatch in Privacy Mode

This is the most important finding. When privacy_mode = true, cipher.wrap() is called twice on the same manifest data via two independent code paths, each generating a fresh random nonce. The two calls produce different nonces → different ciphertexts → different blob hashes.

Path 1 — async_submitter.rs:187-194 builds the sidecar to send to Raiko:

let blob_payload = ethereum_l1.execution_layer.proposal_cipher().wrap(&manifest_data)?;
let sidecar_builder: SidecarBuilder<BlobCoder> = SidecarBuilder::from_slice(&blob_payload);
// blob_hashes from this sidecar go to Raiko → proof binds to these hashes

Path 2 — proposal_tx_builder.rs:262 builds the sidecar for the actual L1 transaction:

let blob_payload = self.cipher.wrap(&manifest_data)?;
// nonce_2 ≠ nonce_1 → blob_hash_2 ≠ blob_hash_1

Raiko's proof commits to blob_hash_1. The L1 transaction posts blobs identified by blob_hash_2. Every propose call in privacy mode will submit a proof that doesn't match the on-chain blob hashes and will revert.

Fix: Encrypt the manifest once (in async_submitter.rs) and carry the resulting payload on Proposal so proposal_tx_builder.rs can consume it directly without re-encrypting. Example sketch:

// Proposal struct gains an optional pre-encrypted blob payload
pub struct Proposal {
    // ...
    pub encrypted_blob_payload: Option<Vec<u8>>,
}

Then proposal_tx_builder.rs uses batch.encrypted_blob_payload.as_deref() when present, falling back to cipher.wrap only when absent (plaintext mode — which is deterministic, so the double-call is harmless there). Fix this →

---

Security: RealtimeConfig Debug Derive Exposes Symmetric Key

realtime/src/utils/config.rs:8: #[derive(Debug, Clone)] is on RealtimeConfig, which contains privacy_symmetric_key: Option<[u8; 32]>. Rust's derived Debug will print the key bytes verbatim. If RealtimeConfig is ever logged via {:?}, the key appears in logs/traces.

The Display impl correctly omits it. The Debug impl should be made safe as well — either implement Debug manually or wrap the key in a newtype:

struct RedactedKey(pub [u8; 32]);
impl fmt::Debug for RedactedKey {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        f.write_str("<redacted>")
    }
}

Fix this →

---

Potential Lint Failure: cast_possible_truncation at execution_layer.rs:253

let num_forced_inclusions = pending.min(u64::from(self.fi_max_per_proposal)) as u16;

pending is u64; as u16 is a truncating cast. The workspace Cargo.toml denies cast_possible_truncation. The value is logically bounded by fi_max_per_proposal: u16, but the compiler has no way to prove that, so clippy will fire. This will fail CI. Use u16::try_from(...) instead:

let num_forced_inclusions =
    u16::try_from(pending.min(u64::from(self.fi_max_per_proposal)))
        .unwrap_or(self.fi_max_per_proposal);

Or, since the min is provably within range, a expect("bounded by fi_max_per_proposal") is also acceptable. Fix this →

---

CodeQL Findings: Both Are False Positives

• Line 24 (let mut nonce = [0u8; NONCE_LEN]): This is a zero-initialized stack buffer immediately overwritten by OsRng.fill_bytes(&mut nonce) on the next line. CodeQL sees an initialized array and flags it; the actual nonce is always random.
• Line 62 (let nonce = [0x37u8; NONCE_LEN]): This is inside #[cfg(test)] and intentionally uses a deterministic nonce for the round-trip test. The module doc at line 29–30 explicitly marks encrypt_with_nonce as test-only. No action needed.

If you want to suppress the alerts cleanly without noise in the source, a #[allow(clippy::...)] attribute on the test function and a brief comment pointing at CodeQL issue numbers would be sufficient.

---

Resilience: Silent FI State Failure May Burn Gas

execution_layer.rs:244-250: if getForcedInclusionState RPC fails, the code silently falls back to num_forced_inclusions = 0. When there are actually "due" forced inclusions, the resulting propose call will revert with UnprocessedForcedInclusionIsDue, wasting gas. Consider returning an Err and skipping the proposal for this slot rather than committing to a predictably-reverting transaction.

---

Minor Nits

• proposal_tx_builder.rs:95: #[allow(clippy::too_many_arguments)] on build_propose_blob which only has 4 arguments — can be removed.
• realtime/src/utils/config.rs:175: Display for RealtimeConfig prints privacy_mode but not whether privacy_symmetric_key is set. A line like Privacy key: {} (set/not set) would make the startup log more informative during debugging.
• async_submitter.rs:250: std::fs::write("/tmp/raiko_request.json", ...) runs on every bypass invocation and could silently fail to write if the filesystem is read-only. The error is dropped via ? which would propagate correctly — this is fine, just worth noting in ops docs.

---

Summary

Severity	Finding
🔴 Critical	Double-encryption: async_submitter.rs and proposal_tx_builder.rs independently call cipher.wrap(), generating mismatched blob hashes in privacy mode
🟡 Medium	RealtimeConfig derived Debug exposes the raw AES key bytes
🟡 Medium	as u16 cast violates cast_possible_truncation = deny workspace lint
🟢 Info	Both CodeQL nonce alerts are false positives
🟢 Minor	FI state failure silently proceeds to a likely-reverting L1 call
🟢 Nit	Stale #[allow(clippy::too_many_arguments)] on build_propose_blob