Repository navigation
[Feature] Remove unused SM2 algorithm and related configuration #6588
Description
Background
The java-tron codebase contains a complete SM2 implementation in the crypto module. The SignUtils.java provides a configuration flag isECKeyCryptoEngine to switch between ECKey (SECP256K1) and SM2. Additionally, SM3 hash implementation exists alongside SM2.
The crypto.engine configuration option allows switching between cryptographic engines, but in practice only ECKey is ever used in production.
Problem Statement
-
SM2/SM3 is never used in production: All production deployments use
ECKey (SECP256K1). TheisECKeyCryptoEngineflag is alwaystrue. -
Dead code maintenance burden: Maintaining ~1,100+ lines of unused cryptographic code (SM2 + SM3) increases complexity, testing surface, and audit scope.
-
Incompatible with TRON network: TRON uses
SECP256K1for all transactions. SM2 would not work with existing accounts. -
Bug Bounty false positives: The unused SM2 code frequently triggers false positive reports in bug bounty programs. Security researchers often flag SM2-related code as potential vulnerabilities, requiring time-consuming investigation and response.
-
Unnecessary configuration complexity: The
crypto.engineconfig andisECKeyCryptoEnginechecks exist throughout the codebase but only serve unused code paths.
Rationale
Why should this feature exist?
Removing unused code improves code quality and reduces maintenance overhead. Eliminating the crypto.engine configuration simplifies the codebase by removing conditional logic that never changes in production.
What are the use cases?
- Developers will have cleaner codebase to work with
- Security audits will focus on actually-used cryptography
- Fewer false positive reports in bug bounty programs
- Simplified code with no unnecessary conditional branches
Scope of Impact
- Core protocol
- API/RPC
- Database
- Network layer
- Smart contracts
- Documentation
- Other: crypto module, keystore, config
Breaking Changes:
Yes - but only for non-production code paths:
crypto.engineconfiguration option will be ignoredisECKeyCryptoEnginemethod calls must be updated- SM2-related test files will be removed
Backward Compatibility:
Fully backward compatible for production:
- Default ECKey behavior remains unchanged
- No production config uses SM2
- Config
crypto.enginecan remain in old configs (will be ignored with warning)
Implementation
Are you willing to implement this feature?
- Yes, I can implement this feature
Activity
SeriousCoding789 commentedon Mar 19, 2026
This is an excellent proposal that will significantly improve code quality and reduce maintenance overhead. However, I have some concerns about potential third-party integration impacts that should be addressed through a careful migration strategy.
While SM2 is unused in production, some third-party integrations might still reference SM2-related APIs:
SignUtils.fromPrivate(bytes, isECKeyCryptoEngine)with hardcodedfalsevaluescrypto.engine = "sm2"in their configsI strongly recommend implementing a phased deprecation approach rather than immediate removal - first add deprecation warnings while maintaining API compatibility, then gradually remove the code over 2-3 releases. This would give third-party developers adequate time to update their integrations and minimize ecosystem disruption.
What are your thoughts on this approach?
[-][FEATURE] Remove unused SM2 algorithm and related configuration[/-][+][Feature] Remove unused SM2 algorithm and related configuration[/+]Federico2014 commentedon Mar 19, 2026
@Sunny6889 Thanks for the feedback! I understand your concerns about third-party integrations, but after careful consideration:
SECP256K1for all transactions. SM2 would not work with existing accounts.Given the low impact and the benefits of cleaner codebase, I believe immediate removal is the right approach. If anyone has strong objections with concrete use cases, we can reconsider.
warku123 commentedon Mar 19, 2026
I really support this cleanup.
Removing 1100+ lines of unused SM2/SM3 code will reduce maintenance overhead and eliminate recurring false positive security reports. Since TRON exclusively uses
SECP256K1in production, this is a safe change with no backward compatibility concerns.Federico2014 commentedon Mar 20, 2026
There are many
Args.getInstance().isECKeyCryptoEngine()checks across the code base. If we remove them all, it affects 70+ files, but it's a clean approach. Alternatively, we could only remove the SM2 algorithm and keepArgs.getInstance().isECKeyCryptoEngine()always returning true, which involves fewer code changes. I prefer cleaning up allArgs.getInstance().isECKeyCryptoEngine()checks. Which approach do you think is more reasonable?halibobo1205 commentedon Mar 26, 2026
Agree with removing it directly — SM2 was never part of the public API, and no third party depends on it, so a clean removal seems like the better option. I don't see much value in keeping
isECKeyCryptoEnginearound either; what do others think?zhaog100 commentedon Mar 26, 2026
/attempt
zhaog100 commentedon Mar 26, 2026
/attempt
Federico2014 commentedon Apr 13, 2026
After further discussion in PR #6627 (see #6627 (comment)), I've decided to close this issue.
The reviewer pointed out that the benefit of this change is minimal —
isECKeyCryptoEngineis always true and has no impact on runtime behavior. However, the cost is significant: 75 files changed across core modules. The SM2/SM3 support was designed as a crypto extension point and may still have value as a reserved abstraction.Weighing the risk-to-benefit ratio, we'll leave the current code as-is.