[Feature] Remove unused SM2/SM3 crypto engine

[Federico2014]

Summary

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

This proposal revisits tronprotocol/java-tron#6588. The earlier proposal was closed because a cleanup spanning roughly 75 files appeared to offer too little benefit for its change surface. New interoperability findings and the upcoming post-quantum (PQ) signature work change that trade-off: the SM2 path is not a standards-compliant fallback, and retaining it would carry an unreachable branch into a future multi-algorithm design.

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 selected value is exposed throughout the codebase through CommonParameter.isECKeyCryptoEngine(). It affects signing and verification as well as transaction hashes, block hashes, address derivation, and Merkle roots.

Every public TRON network uses the ECKey path. The configuration warns operators not to change it because selecting the alternate path changes consensus-critical values and immediately makes the node incompatible with the public network. Despite that restriction, the switch remains exposed as ordinary configuration and the alternate implementation continues to appear as a supported option.

Current State

The codebase contains 73 production references to isECKeyCryptoEngine across 28 Java files and another 37 references across 14 test files. Boolean dispatch remains part of APIs such as SignUtils and Sha256Hash, even though maintained public-network configurations always select ECKey and SHA-256. The corresponding engine state is also retained in CommonParameter, MiscConfig, and the reference configuration files.

The alternate implementation under crypto/src/main/java/org/tron/common/crypto/sm2/ contains approximately 1,406 lines of code. SM2-specific construction and verification paths also remain in keystore utilities and tests. As a result, an unused branch crosses the crypto, common, chainbase, consensus, actuator, and framework modules and remains present in consensus-critical call chains.

Limitations or Risks

The configuration switch is hazardous because an accidental change affects far more than the signature algorithm: it also changes transaction and block identifiers, addresses, and Merkle roots. A node started with the wrong value can therefore fork from its intended network rather than fail with a simple configuration error.

The SM2 implementation is also not standards-interoperable. SM2Signer.getZ() omits the ENTL || ID input required by the SM2 identity-binding calculation, so its signatures cannot interoperate with compliant implementations even though the code may be understood as providing national-cryptography support.

Keeping this path expands the amount of cryptographic code that must be maintained and audited without protecting behavior used by public TRON networks. The current ECKey/SM2 boolean is also not a useful extension point for PQ signatures, which require an explicit algorithm identifier or registry. Preserving the boolean branch would increase the PQ migration surface and test matrix without providing a reusable abstraction.

Proposed Solution

Proposed Design

The cleanup should proceed in layers so that behavior can be verified after each step. It should begin by recording golden vectors for transaction IDs, block IDs, addresses, signatures, and Merkle roots with crypto.engine = "eckey". These vectors will establish the byte-for-byte behavioral baseline that every later stage must preserve.

With that baseline in place, the core crypto APIs can be simplified. Engine-selection parameters and SM2 branches should be removed from SignUtils, leaving ECKey as its only implementation. The boolean overloads and SM3 branches in Sha256Hash should likewise be removed so that its API represents SHA-256 directly.

Callers should then be migrated in reviewable groups organized by owning module. Changes to chainbase, consensus, actuator, and framework should update production call sites and their corresponding tests together, making each stage easier to review against the established vectors.

After callers no longer depend on engine selection, the configuration and state can be removed. This includes CommonParameter.isECKeyCryptoEngine(), cryptoEngine, MiscConfig.cryptoEngine, Constant.ECKey_ENGINE, and the crypto { engine = "eckey" } blocks in maintained configuration files. Existing custom configurations may temporarily retain the obsolete key, but it will become inert and should be documented as unsupported.

Finally, the implementation under crypto/src/main/java/org/tron/common/crypto/sm2/, its keystore integration, and SM2-only tests can be deleted. Future PQ work should introduce an explicit multi-algorithm abstraction after this cleanup rather than reuse the current boolean switch.

Key Changes

This proposal spans crypto, common, chainbase, consensus, actuator, and framework because the engine decision currently crosses their API boundaries. The work removes crypto.engine, simplifies SignUtils and Sha256Hash, migrates their callers by module, deletes the SM2/SM3 implementation, and replaces conditional test paths with ECKey baselines and golden-vector regression coverage. These changes are intentionally staged because they are strongly dependent parts of one cryptographic cleanup rather than independent module features.

Impact

The resulting codebase will expose only the cryptographic behavior actually used by maintained TRON networks. Removing the non-interoperable SM2 implementation and the fork-prone configuration switch reduces security ambiguity and branching in consensus-critical paths. It also removes approximately 1,406 lines of unused cryptographic code and more than 100 production and test dispatch sites, narrowing future maintenance and audit scope. For the planned PQ work, the cleanup avoids carrying an unreachable PQ x SM2 combination into the new algorithm framework.

Compatibility

• Breaking Change: Yes, for users of SM2/SM3 and the engine-selecting Java APIs.
• Default Behavior Change: No. ECKey/secp256k1 and SHA-256 behavior remains 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 remain on an older release. Because the current implementation omits standard identity binding, users requiring national-cryptography compliance should migrate to a compliant implementation rather than continue depending on this path.
• Configuration Migration: Maintained configurations will remove crypto.engine. Older custom configurations may retain the now-ignored key during a transition period.

Verification

Verification will 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

Focused unit tests will cover BlockCapsule, TransactionCapsule, Sha256HashTest, and WalletTest. Each affected module will run its complete test suite, followed by the full build and checkstyle verification. Maintained Mainnet, Nile, and Shasta configurations will also be checked to confirm that the cleanup produces no behavioral difference.

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