Tracking Issue: Code refactor and cleanup

[317787106]

Summary

Over years of development, java-tron has accumulated a considerable amount of legacy code, including dead code, unreachable branches, deprecated APIs, duplicated implementations, and obsolete configuration options. Some feature flags contain branches that are never reachable on public networks, some services are registered but always return UNIMPLEMENTED, while others duplicate the same logic across multiple implementations. There are also configuration options that are no longer functional but still require documentation, testing, and maintenance.

This issue serves as a tracking (epic) issue to consolidate these cleanup efforts. It provides an overview of completed work, tracks planned cleanup tasks, and defines the common principles that should guide future cleanup work.

Each cleanup effort will continue to be implemented through its own dedicated Issue and Pull Request. This tracking issue serves only as an index and roadmap.

Motivation

Legacy code provides little or no functional value while continuously increasing the maintenance burden of the project.

Dead code and permanently unreachable branches make it difficult for contributors to determine whether a piece of code is actually executed or whether a configuration option still has any effect. This increases the cognitive cost of understanding the codebase and slows down development. Likewise, maintaining multiple copies of the same logic—such as separate servlet implementations for FullNode, Solidity, and PBFT—requires every functional change to be replicated in several places, making behavioral inconsistencies more likely over time.

Reducing unused code also reduces the security audit surface. Static analysis, security reviews, and bug bounty programs become more focused, generate fewer false positives, and require less effort to evaluate obsolete implementations. For example, the existing partial SM2 implementation repeatedly raises compliance questions despite being unreachable on public networks.

Some obsolete configuration options are also misleading for node operators. Options such as node.walletExtensionApi appear to enable functionality but have no practical effect, leading to unnecessary operational confusion.

Certain historical feature flags are effectively "footguns" that can introduce consensus risks if misconfigured, such as actuator.whitelist and crypto.engine. Removing these unreachable code paths eliminates unnecessary risk without changing observable network behavior.

Finally, removing dead code, obsolete test utilities, and duplicated implementations reduces long-term maintenance costs, simplifies regression testing, and makes future refactoring significantly easier.

Cleanup Principles

All cleanup tasks should follow a consistent set of principles:

1. The highest priority is preserving observable behavior. Changes must not alter the behavior of MainNet, Nile, or Shasta. For any modifications involving consensus, hashing, serialization, or protocol encoding, byte-level regression verification should be performed to ensure that block hashes, transaction hashes, address derivation, and protobuf encoding remain unchanged.

2. Public APIs and protobuf services should follow a deprecation process. They should first be marked as deprecated and remain available for at least one release cycle before being removed in a future major release. This avoids unexpected compatibility issues for downstream SDKs and applications. The WalletExtension cleanup follows this approach.

3. Each cleanup should be implemented through an independent Issue and Pull Request to simplify review and rollback. Large refactorings may be further divided into logical commits to make review easier.

Whenever a configuration option is removed, the corresponding documentation, reference.conf, and configuration validation should be updated accordingly.

Completed

Issue	Description
tronprotocol#6666	Remove actuator.whitelist and related logic to eliminate potential fork risks.
tronprotocol#6665	Remove InfluxDB metrics backend support.
tronprotocol#6595	Remove scheduled database backup in favor of dual-node failover.
tronprotocol#6548	Remove HTTP REST mappings in gRPC protobuf definitions.

Planned

The following cleanup proposals will each be tracked as independent issues.

1. Consolidate Solidity/PBFT HTTP APIs

The servlet implementations under interfaceOnSolidity.http and interfaceOnPBFT.http contain almost no unique business logic. They simply switch the read cursor before delegating to the corresponding FullNode servlet.

The proposal is to remove these wrapper servlets and reuse the existing FullNode implementations, while switching read cursors through a request-path-based filter for /walletsolidity/* and /walletpbft/*. This eliminates duplicated implementations and prevents long-term behavioral drift.

2. Consolidate Solidity/PBFT gRPC APIs

RpcApiServiceOnSolidity and RpcApiServiceOnPBFT consist almost entirely of boilerplate delegation to the primary RpcApiService.

The proposal is to reuse the existing implementation and perform cursor switching through a parameterized ServerInterceptor, removing nearly one thousand lines of duplicated code.

3. Remove the SM2/SM3 cryptographic engine

The crypto.engine configuration is effectively fixed to ECKey on public networks, making all SM2/SM3 execution paths unreachable. In addition, the current SM2 implementation does not fully comply with the GM/T 0003 specification.

The proposal is to remove the unused SM2 implementation together with all unreachable isECKeyCryptoEngine branches. Besides reducing maintenance costs, this cleanup also prepares a cleaner cryptographic abstraction for future post-quantum cryptography work.

4. Remove WalletExtension dead code and deprecate its protobuf service

The WalletExtension gRPC service has never implemented any functionality. Every RPC method currently returns UNIMPLEMENTED, while node.walletExtensionApi is an ineffective configuration option.

The cleanup will be performed in two stages. The first stage removes the dead Java implementation, obsolete configuration, and test utilities while marking the protobuf service as deprecated. The second stage removes the protobuf service entirely in a future major release.

5. Remove --keystore-factory support from FullNode

Since v4.8.2, keystore generation has been fully migrated to Toolkit.jar. Continuing to support --keystore-factory inside FullNode.jar unnecessarily duplicates functionality and blurs component responsibilities.

Removing this option allows FullNode to focus exclusively on node operation while providing a single entry point for keystore management.

6. Remove unused RLP utilities

The RLP-related utilities under framework/src/main/java/org/tron/core/capsule/utils are no longer part of TRON's core execution path.

Removing these unused utilities will simplify maintenance, reduce testing overhead, and make module boundaries clearer.

7. Remove non-Prometheus metrics implementations

Prometheus has become the standard monitoring solution for java-tron. Maintaining additional metrics implementations and MonitorApi introduces unnecessary duplication and operational confusion.

The proposal is to remove all non-Prometheus metrics implementations together with MonitorApi, leaving Prometheus as the single supported monitoring backend.

Future Work

Additional dead code, unreachable functionality, and obsolete components are welcome.

New cleanup candidates can be proposed under this tracking issue before being promoted into dedicated issues and pull requests.

This tracking issue will continue to be updated as cleanup work progresses.