perf(bls): remove redundant G2 subgroup check in signature verification

[sashass1315]

The [Signature::verify()](

helios/ethereum/consensus-core/src/types/bls.rs

Lines 39 to 50 in 4a32ac1

	impl Signature {
	pub fn verify(&self, msg: &[u8], aggregate_public_key: &G1Affine) -> bool {
	let sig_point = if let Ok(point) = self.point() {
	point
	} else {
	return false;
	};
	// Subgroup check for signature
	if !subgroup_check_g2(&sig_point) {
	return false;
	}

method was performing an explicit subgroup check via
[subgroup_check_g2()]

helios/ethereum/consensus-core/src/types/bls.rs

Lines 84 to 90 in 4a32ac1

	ate2_evaluation(sig_point, &generator_g1_negative, &msg_hash, &key_point)
	}
	/// Verifies a G2 point is in subgroup `r`.
	fn subgroup_check_g2(point: &G2Affine) -> bool {
	const CURVE_ORDER: &str = "73EDA753299D7D483339D80809A1D80553BDA402FFFE5BFEFFFFFFFF00000001";
	let r = hex_to_scalar(CURVE_ORDER).unwrap();

after calling G2Affine::from_compressed(). However, from_compressed() already performs a subgroup check internally via is_torsion_free() - this is a documented property of the bls12_381 crate.
The explicit check was performing an expensive scalar multiplication (point * r where r is the 255-bit curve order) that duplicated work already done during decompression.

Remove the redundant [subgroup_check_g2()] function and its call from [Signature::verify()]. Also remove the now-unused [hex_to_scalar()] helper and the Scalar import. This eliminates one full G2 scalar multiplicationper signature verification (~30-50% speedup for the verification path).

[sashass1315]

bench rsults:
before:

after:

[karen-sarkisyan]

For context, a similar optimization has been postponed, see here #751 (comment)

[sashass1315]

For context, a similar optimization has been postponed, see here #751 (comment)

Ohh sorry, didn't really thought about looking at PRs. So I close this PR then? if it's yours idea

[karen-sarkisyan]

For context, a similar optimization has been postponed, see here #751 (comment)

Ohh sorry, didn't really thought about looking at PRs. So I close this PR then? if it's yours idea

No of course not, let's keep it. Just added a pointer to remember that it's been discussed before.