The current default configuration of java-tron node has security and code quality issues that need to be addressed.
Security Risks
-
Key Exposure Risk: allowShieldedTransactionApi = true is enabled by default, exposing sensitive cryptographic key generation APIs:
GetSpendingKey - Random spending key (sk)
GetExpandedSpendingKey - Expanded key components (ask, nsk, ovk)
GetNewShieldedAddress - Complete shielded address with all secrets
-
Remote Attack Surface: Keys transmitted over network can be intercepted; misconfigured firewalls may expose keys to the internet
-
Bug Bounty False Positives: These endpoints frequently trigger security reports requiring manual investigation
-
No Legitimate Remote Use Case: Key generation should be performed locally
Code Quality Issue
Shielded transaction-related code in ShieldedTRC20ParametersBuilder.java and ZenTransactionBuilder.java uses += and -= arithmetic operators. For overflow-safety and explicit behavior, these should use StrictMathWrapper.addExact/subtractExact which throw ArithmeticException on overflow.
Deprecated File
The sprout-verifying.key file is a leftover from the Sprout circuit implementation, which is no longer used (Sapling only).
Important Note (v4.8.1+)
Starting from v4.8.1, the allowShieldedTransactionApi configuration only affects API endpoint availability. Nodes can still validate and process shielded transactions even when the API is disabled.
Proposed Solution
Specification
Configuration Changes
Actual default value location: The default is set in Args.java when the config key is absent (line ~729), not in CommonParameter.java.
Change the fallback default value of allowShieldedTransactionApi from true to false:
// Args.java - applyConfigParams method
PARAMETER.allowShieldedTransactionApi = false; // was: true (fallback when config key absent)
# config.conf
# WARNING: Some shielded transaction APIs require sending private keys as parameters.
# Calling these APIs on untrusted or remote nodes may leak your private keys.
# It is recommended to invoke them locally for development and testing.
# allowShieldedTransactionApi = false
Overflow-Safety Code Improvements
Replace arithmetic operators with StrictMathWrapper for explicit overflow detection:
| File |
Changes |
ShieldedTRC20ParametersBuilder.java |
5 occurrences: 3 addExact + 2 subtractExact |
ZenTransactionBuilder.java |
6 occurrences: 4 addExact + 2 subtractExact |
Note: Using addExact/subtractExact will throw ArithmeticException on overflow, providing explicit failure mode for value boundary violations.
Cleanup Deprecated File
Delete sprout-verifying.key - deprecated Sprout circuit key file. (Need to verify packaging/release scripts before deletion.)
API Changes
Affected APIs (disabled by default when allowShieldedTransactionApi = false):
The allowShieldedTransactionApi flag gates a broader set of shielded wallet/helper APIs than only the secret-material endpoints. This includes all shielded-related wallet APIs accessible via HTTP/gRPC.
HTTP API examples:
/wallet/getspendingkey
/wallet/getexpandedspendingkey
/wallet/getnewshieldedaddress
/wallet/getakfromask
/wallet/getnkfromnsk
/wallet/getincomingviewingkey
/wallet/getpaymentaddress
- ... (all shielded wallet helper APIs)
gRPC API examples:
GetSpendingKey
GetExpandedSpendingKey
GetNewShieldedAddress
GetAkFromAsk
GetNkFromNsk
GetIncomingViewingKey
GetPaymentAddress
- ... (all shielded wallet helper APIs)
Implementation note: Exposed HTTP/gRPC entries are rejected at runtime rather than conditionally unregistered.
Configuration Changes
Users can restore previous behavior by explicitly configuring:
node {
allowShieldedTransactionApi = true
}
Protocol Changes
None - Shielded transaction validation logic is not affected (API control separated since v4.8.1+)
Scope of Impact
Breaking Changes
Yes - Nodes relying on the default true value will have shielded APIs disabled after upgrade.
Backward Compatibility
Previous behavior can be restored through explicit configuration:
node {
allowShieldedTransactionApi = true
}
Implementation
Are you willing to implement this feature?
Estimated Complexity
Regression Test Plan
The following test coverage will be added:
The current default configuration of java-tron node has security and code quality issues that need to be addressed.
Security Risks
Key Exposure Risk:
allowShieldedTransactionApi = trueis enabled by default, exposing sensitive cryptographic key generation APIs:GetSpendingKey- Random spending key (sk)GetExpandedSpendingKey- Expanded key components (ask, nsk, ovk)GetNewShieldedAddress- Complete shielded address with all secretsRemote Attack Surface: Keys transmitted over network can be intercepted; misconfigured firewalls may expose keys to the internet
Bug Bounty False Positives: These endpoints frequently trigger security reports requiring manual investigation
No Legitimate Remote Use Case: Key generation should be performed locally
Code Quality Issue
Shielded transaction-related code in
ShieldedTRC20ParametersBuilder.javaandZenTransactionBuilder.javauses+=and-=arithmetic operators. For overflow-safety and explicit behavior, these should useStrictMathWrapper.addExact/subtractExactwhich throwArithmeticExceptionon overflow.Deprecated File
The
sprout-verifying.keyfile is a leftover from the Sprout circuit implementation, which is no longer used (Sapling only).Important Note (v4.8.1+)
Starting from v4.8.1, the
allowShieldedTransactionApiconfiguration only affects API endpoint availability. Nodes can still validate and process shielded transactions even when the API is disabled.Proposed Solution
Specification
Configuration Changes
Actual default value location: The default is set in
Args.javawhen the config key is absent (line ~729), not inCommonParameter.java.Change the fallback default value of
allowShieldedTransactionApifromtruetofalse:Overflow-Safety Code Improvements
Replace arithmetic operators with
StrictMathWrapperfor explicit overflow detection:ShieldedTRC20ParametersBuilder.javaaddExact+ 2subtractExactZenTransactionBuilder.javaaddExact+ 2subtractExactNote: Using
addExact/subtractExactwill throwArithmeticExceptionon overflow, providing explicit failure mode for value boundary violations.Cleanup Deprecated File
Delete
sprout-verifying.key- deprecated Sprout circuit key file. (Need to verify packaging/release scripts before deletion.)API Changes
Affected APIs (disabled by default when
allowShieldedTransactionApi = false):The
allowShieldedTransactionApiflag gates a broader set of shielded wallet/helper APIs than only the secret-material endpoints. This includes all shielded-related wallet APIs accessible via HTTP/gRPC.HTTP API examples:
/wallet/getspendingkey/wallet/getexpandedspendingkey/wallet/getnewshieldedaddress/wallet/getakfromask/wallet/getnkfromnsk/wallet/getincomingviewingkey/wallet/getpaymentaddressgRPC API examples:
GetSpendingKeyGetExpandedSpendingKeyGetNewShieldedAddressGetAkFromAskGetNkFromNskGetIncomingViewingKeyGetPaymentAddressImplementation note: Exposed HTTP/gRPC entries are rejected at runtime rather than conditionally unregistered.
Configuration Changes
Users can restore previous behavior by explicitly configuring:
Protocol Changes
None - Shielded transaction validation logic is not affected (API control separated since v4.8.1+)
Scope of Impact
Breaking Changes
Yes - Nodes relying on the default
truevalue will have shielded APIs disabled after upgrade.Backward Compatibility
Previous behavior can be restored through explicit configuration:
Implementation
Are you willing to implement this feature?
Estimated Complexity
Regression Test Plan
The following test coverage will be added:
node.allowShieldedTransactionApi = trueArithmeticExceptionis properly handled in overflow scenarios