feat(vm): add P256VERIFY precompile (TIP-7951)

[yanghang8612]

Summary

• Adds the P256VERIFY precompile (TIP-7951 / EIP-7951) at address 0x100, gated by the ALLOW_TVM_OSAKA proposal (no config-file knob — activates via on-chain proposal vote, mirroring ALLOW_TVM_SELFDESTRUCT_RESTRICTION).
• Pure-Java BouncyCastle port — same path as ECRecover, no native dependency.
• 782 conformance vectors (P256VerifyTest): 778 from the Wycheproof ecdsa_secp256r1_sha256_p1363_test suite plus 4 reference / invalid-input cases adopted from go-ethereum's EIP-7951 fixtures.
• Optional manual microbenchmarks (PrecompileBenchmark) compare against ECRecover. TEST 4 (coldNoWarmup) measures cold no-warmup latency to reflect the low-frequency mainnet case where the JVM has not JIT-compiled the precompile path.

Spec

• TIP-7951: TIP-7951: Precompile for secp256r1 Curve Support tips#785
• EIP-7951: https://eips.ethereum.org/EIPS/eip-7951

The 6900-energy cost is the value mandated by EIP-7951 (not derived from these benchmarks); the benchmarks below confirm that this spec value is conservative for TRON's JVM.

Test

• ./gradlew :framework:test --tests org.tron.common.runtime.vm.P256VerifyTest
• ./gradlew :framework:test --tests org.tron.common.runtime.vm.AllowTvmOsakaTest
• ./gradlew :framework:test --no-daemon --tests 'org.tron.common.runtime.vm.PrecompileBenchmark.coldNoWarmup' -i (manual)
• ./gradlew :framework:test --no-daemon --tests 'org.tron.common.runtime.vm.PrecompileBenchmark' -i (manual)

Benchmark

Server: Linux 8 cores / 32 GB. Two separate --no-daemon runs so the cold measurement gets a truly cold JVM:

1. cold-only — --tests 'PrecompileBenchmark.coldNoWarmup'
2. full class — --tests 'PrecompileBenchmark' (provides warm steady-state and fail-path numbers)

Warm steady-state — TEST 1 / TEST 3 (5000-iter warmup, 5000 × 5 measure)

precompile (energy)	TEST 1: single fixed input	TEST 3: 100 rotating keys
ECRecover (3000)	1,166 ns/op (858 ops/s)	1,182 ns/op (846 ops/s)
P256Verify (6900)	2,034 ns/op (492 ops/s)	2,040 ns/op (490 ops/s)
P256 / EC time ratio	1.75×	1.73×

At C2 steady state P256 is ~1.75× slower than ECRecover, well under the 2.30× energy ratio (6900/3000) — i.e. the EIP-7951-mandated 6900 leaves ~24% headroom against TRON's measured cost.

Cold no-warmup — TEST 4 (100 distinct inputs, per-call timing)

precompile (energy)	call #1	calls #2..10 (avg)	calls #11..100 (avg)
ECRecover (3000)	21.47 ms	1.44 ms	1.39 ms
P256Verify (6900)	12.21 ms	2.68 ms	2.11 ms

The first call pays full JIT / classloading / minor-GC tax — both precompiles land in the 10–20 ms range. P256VERIFY's first call is actually lower than ECRecover's because BouncyCastle's secp256k1 path has more cold code to load. After 100 invocations the JVM has not yet triggered C1/C2 (-XX:CompileThreshold=10000 default), so per-call cost stays around 2 ms — three orders of magnitude above the C2 steady state of ~2 µs. This is the realistic upper bound for a low-frequency precompile that rarely reaches JIT steady state.

Fail-path early-exit — TEST 2 (warm, 5000-iter warmup, 5000 × 5 measure)

stage that fails	ns/op	ops/s
1. len != 160	103	9.7 M
2. r ≥ N (modulus bound)	440	2.3 M
3. qx ≥ P (field bound)	382	2.6 M
4. point at infinity	325	3.1 M
5. point off-curve	2,141	467 K
6. ECDSA verify fails	1,982,966	504
0. VALID full pass	1,999,964	500

Confirms the cheap guards short-circuit before scalar multiplication: length / bound / infinity checks finish in ~100–500 ns, three orders of magnitude faster than a full ECDSA pass. Off-curve detection costs one curve-equation evaluation (~2 µs) but is still ~1000× cheaper than a full verify. A failing ECDSA verify costs the same as a passing one — both run the full scalar multiplication; only the final equality check differs.