feat: TON support for foreign tx validation requests in mpc contract

[DSharifi]

closes #3241

co-authored with: @frolvanya

[DSharifi]

@claude review

[DSharifi]

@claude review

[claude]

Pull request overview

Re-review after the May 15 round. The prior blocking items have been addressed: TonCellRefs is now EmptyBoundedVec<Hash256, TON_CELL_MAX_REFS> (refs are 32-byte cell-hash commitments, max 4 → 128 B total, no inner unboundedness), and TonCellBody now carries an explicit bit_length: u16 validated against bits.len() via ceiling-division — with both the Deserialize and BorshDeserialize impls routed through a single TonCellBodyRepr → TryFrom choke point, plus unit/property tests confirming the bit/byte mismatch + max-bit-length checks reject invalid input on both wire formats. The doc comment on ForeignTxSignPayload ("Never reorder variants/fields") is honored — Ton is appended at the tail of ForeignChainRpcRequest, ExtractedValue, and ForeignChain, preserving existing Borsh discriminants.

Changes:

• TonCellRefs re-typed as EmptyBoundedVec<Hash256, TON_CELL_MAX_REFS> (was unbounded inner Vec<u8>).
• TonCellBody introduced as { bits, bit_length } with constructor-only invariants; manual Deserialize/BorshDeserialize enforce the same invariants on the wire.
• Hash-distinguishability test (ton_log_compute_msg_hash__should_differ_for_same_bytes_but_different_bit_length) pins the previously-flagged 7-vs-8-bit collision case.

Reviewed changes

Per-file summary

File	Description
crates/near-mpc-contract-interface/src/types/foreign_chain.rs	Adds Ton DTOs, TonCellBody with validated bit-length, error type, and a battery of constructor/round-trip tests.
crates/near-mpc-contract-interface/src/types/snapshots/...ton__should_have_consistent_hash.snap	Pinned canonical-payload hash for the Ton case.
crates/contract/tests/sandbox/common.rs	ton_request() / bogus_ton_log_extracted_value() helpers.
crates/contract/tests/sandbox/foreign_chain_request.rs	Ton case added to three rstest matrices.
crates/contract/tests/snapshots/abi__abi_has_not_changed.snap	ABI snapshot extended with Ton variants + TonRpcRequest/TonAddress/TonExtractor/TonFinality/TonTxId.

Findings

Non-blocking (nits, follow-ups, suggestions):

• crates/near-mpc-contract-interface/src/types/foreign_chain.rs:336 — TonCellBody::new validates bits.len() == ⌈bit_length / 8⌉ but does not validate that the unused low bits in the final byte are zero, even though the doc comment two lines above promises "the final byte's unused low bits zeroed." Concretely, TonCellBody { bits: [0xF0], bit_length: 4 } and TonCellBody { bits: [0xFF], bit_length: 4 } are both accepted today but Borsh-serialize to different bytes and therefore produce different compute_msg_hash outputs. Because this hash drives MPC quorum, two inspectors that read the same on-chain message but pack the trailing padding differently would silently disagree and never reach quorum. The simplest fix is a 2-line guard:

  let trailing = bit_length % 8;
  if trailing != 0 {
      let mask: u8 = 0xFF >> trailing; // low (8 - trailing) bits
      if let Some(last) = bits.as_ref().last() {
          if last & mask != 0 {
              return Err(TonCellBodyError::NonCanonicalTrailingBits { last: *last, bit_length });
          }
      }
  }

  Cheaper to add now than after V1 payloads ship, since both Deserialize and BorshDeserialize already route through new. Not strictly a contract-side concern (only the hash flows on-chain) but it's a real footgun for the upcoming inspector PR.
• crates/near-mpc-contract-interface/src/types/foreign_chain.rs:507 — still no negative test that ForeignChainRpcRequest::Ton(...) paired with a non-Ton ExtractedValue (e.g. EvmExtractedValue::BlockHash) hashes to something different than the Ton-Ton pairing — mirroring the existing foreign_tx_sign_payload_v1__should_produce_different_hashes_for_different_requests. The previous review's nit; carrying it forward since the snapshot test alone doesn't guard variant-reordering against cross-chain payload collisions.
• crates/node/src/providers/verify_foreign_tx/sign.rs:319 — the catchall _ => bail!(\"unsupported foreign chain request\") still rejects every Ton request at runtime, and crates/node-config/src/foreign_chains.rs has no Ton entry. Intentional (this PR is contract/DTO-only) — please call that out in the PR description so deployers don't infer end-to-end TON support from this merge alone.

✅ Approved

[anodar]

Thank you!

[anodar]

optional nit: consider adding a comment here so that we know in the future how we kept bumping it up.

[DSharifi]

I'll skip this, as the other PR I have allows us to bump this to 2MiB

[SimonRastikian]

Overall seems good with a couple of questions