Skip to content

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

Open
yanghang8612 wants to merge 2 commits intotronprotocol:developfrom
yanghang8612:feat/tip-7951-p256verify
Open

feat(vm): add P256VERIFY precompile (TIP-7951)#6720
yanghang8612 wants to merge 2 commits intotronprotocol:developfrom
yanghang8612:feat/tip-7951-p256verify

Conversation

@yanghang8612
Copy link
Copy Markdown
Collaborator

@yanghang8612 yanghang8612 commented Apr 28, 2026

Summary

  • Adds the P256VERIFY precompile (TIP-7951 / EIP-7951) at address 0x100, gated by ALLOW_TVM_OSAKA.
  • Pure-Java BouncyCastle port — same path as ECRecover, no native dependency.
  • 81 conformance vectors from go-ethereum's EIP-7951 test suite (P256VerifyTest).
  • 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

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
  • ./gradlew :framework:test --no-daemon --tests 'org.tron.common.runtime.vm.PrecompileBenchmark' -i

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 (gas) 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× gas ratio (6900/3000), so the proposed pricing carries ~24% safety margin.

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

precompile (gas) 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.

Pure-Java BC port of EIP-7951; gated by ALLOW_TVM_OSAKA.
Manual @test, not part of regular suite. Run via --tests filter.
@github-actions github-actions Bot requested a review from CodeNinjaEvan April 28, 2026 11:05
@halibobo1205 halibobo1205 added the topic:vm VM, smart contract label Apr 28, 2026
@halibobo1205 halibobo1205 added this to the GreatVoyage-v4.8.2 milestone Apr 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

topic:vm VM, smart contract

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants