[Feature] Remove unused SM2/SM3 crypto engine

[Federico2014]

Summary

Remove the unused SM2/SM3 implementation and the crypto.engine switch, and make ECKey/secp256k1 plus SHA-256 the single cryptographic path used by java-tron.

This revisits tronprotocol/java-tron#6588 with additional interoperability findings, a staged implementation plan, and the upcoming post-quantum (PQ) signature work in mind.

Problem

Motivation

java-tron currently selects between two coupled cryptographic suites:

crypto.engine	Signature	Hash	Intended use
eckey (default)	ECKey / secp256k1	SHA-256	Mainnet, Nile, Shasta, and other public networks
other values such as sm2	SM2	SM3	Private or consortium deployments

The value is exposed throughout the codebase as CommonParameter.isECKeyCryptoEngine(). It affects signing, verification, block and transaction hashes, address derivation, and Merkle roots.

For every public TRON network this condition is always true. The configuration itself warns operators not to modify it because doing so changes consensus-critical hashes and immediately disconnects the node from the public network. The alternate path is therefore both dead in production and dangerous to expose as a normal configuration option.

Current State

• The current source contains 73 production references to isECKeyCryptoEngine across 28 Java files, plus 37 test references across 14 files.
• crypto/src/main/java/org/tron/common/crypto/sm2/ contains about 1,406 lines of implementation.
• SignUtils and Sha256Hash expose boolean-dispatch APIs even though public networks always select ECKey and SHA-256.
• CommonParameter, MiscConfig, and the reference configuration retain the engine switch.
• Keystore and test code still expose SM2-specific construction and verification paths.

Limitations or Risks

1. A configuration mistake causes a fork. The switch changes not only the signature algorithm but also transaction hashes, block hashes, addresses, and Merkle roots.
2. The SM2 implementation is not standards-interoperable. SM2Signer.getZ() omits the ENTL || ID input required by the standard SM2 identity-binding calculation. The resulting signatures cannot interoperate with compliant SM2 implementations, while the code can still be mistaken for compliant national-cryptography support.
3. Dead cryptographic code expands audit scope. It creates recurring security findings and requires maintainers to review code that is not used by the TRON network.
4. The boolean abstraction is not a useful long-term extension point. PQ signature support requires multi-algorithm dispatch rather than an ECKey/SM2 boolean. Keeping the dead branch would enlarge the PQ migration and its test matrix without preserving a reusable design.

The earlier proposal was closed because a 75-file cleanup appeared to provide too little benefit for its change surface. The new interoperability finding and the PQ work change that trade-off: the SM2 path is not a compliant fallback, and the same call chain will otherwise have to carry an unreachable branch into a new algorithm framework.

Proposed Solution

Proposed Design

Converge the crypto APIs in layers rather than applying unrelated replacements across the tree:

1. Lock down behavioral baselines
   • Capture golden vectors for transaction IDs, block IDs, addresses, signatures, and Merkle roots with crypto.engine = "eckey".
   • Use these vectors to prove byte-for-byte equivalence before and after each layer.
2. Simplify the core crypto APIs
   • Remove the isECKeyCryptoEngine parameter from SignUtils methods and retain ECKey only.
   • Remove the SM3 branches and boolean overloads from Sha256Hash; retain SHA-256 only.
3. Migrate callers by owning module
   • Update chainbase, consensus, actuator, and framework call sites to the simplified APIs in reviewable groups.
   • Update the corresponding tests in the same group.
4. Remove configuration and state
   • Remove CommonParameter.isECKeyCryptoEngine(), cryptoEngine, MiscConfig.cryptoEngine, and Constant.ECKey_ENGINE.
   • Remove the crypto { engine = "eckey" } blocks from the reference and node configurations. Existing custom configuration keys become inert and should be documented as unsupported.
5. Delete the unused implementation
   • Delete crypto/src/main/java/org/tron/common/crypto/sm2/.
   • Remove SM2 references from keystore utilities and SM2-only tests.

The PQ work should introduce its own explicit algorithm identifier or registry after this cleanup; it should not reuse the current boolean switch.

Key Changes

• Modules: crypto, common, chainbase, consensus, actuator, and framework
• Configuration: remove crypto.engine
• APIs: simplify SignUtils and Sha256Hash
• Tests: replace engine-conditional calls and add golden-vector regression coverage

Impact

• Security: removes a misleading, non-interoperable cryptographic implementation and a configuration switch that can fork a node.
• Stability: reduces branching in consensus-critical hash and signature paths.
• Maintainability: removes about 1,406 lines of unused crypto code and more than 100 boolean dispatch call sites from production and tests.
• PQ readiness: reduces the migration surface and avoids carrying the unreachable PQ x SM2 combination into a multi-algorithm design.

Compatibility

• Breaking Change: Yes, for users of SM2/SM3 and the engine-selecting Java APIs.
• Default Behavior Change: No. ECKey/secp256k1 and SHA-256 remain unchanged.
• Public Network Compatibility: Mainnet, Nile, Shasta, and other ECKey networks must remain byte-for-byte equivalent and must not fork.
• Private Network Compatibility: Deployments that explicitly use SM2/SM3 must migrate or pin to an older release. Because the current implementation omits standard identity binding, users needing national-cryptography compliance should migrate to a compliant implementation rather than depend on this path.
• Configuration Migration: Remove crypto.engine from maintained configurations. Older custom configurations may retain the now-ignored key during a transition period.

Verification

• Compare pre-change and post-change golden vectors for:
  • BlockCapsule block IDs and signatures
  • TransactionCapsule transaction IDs, signatures, and recovered addresses
  • Sha256Hash outputs
  • address derivation and Base58Check checksums
  • Merkle roots
• Run focused unit tests for BlockCapsule, TransactionCapsule, Sha256HashTest, and WalletTest.
• Run the complete module test suites and build/checkstyle verification.
• Confirm that maintained Mainnet, Nile, and Shasta configurations produce no behavioral diff.

References

• tronprotocol/java-tron#6588 - original removal proposal
• tronprotocol/java-tron#6627 - original implementation attempt
• tronprotocol/java-tron#6793 - PQ signature proposal

Additional Notes

• Do you have ideas regarding implementation? Yes
• Are you willing to implement this feature? Yes