Tracking: 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
#6666	Remove actuator.whitelist and related logic to eliminate potential fork risks.
#6665	Remove InfluxDB metrics backend support.
#6595	Remove scheduled database backup in favor of dual-node failover.
#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.

[GuipaiQigong111]

Thanks for putting this tracking issue together. The overall direction makes sense, and I agree that each cleanup item should be handled in a separate issue and PR so the changes remain easy to review, verify, and roll back.

A few requirements should be applied to the follow-up work:

• Changes involving consensus, cryptography, hashing, serialization, or cursor switching must demonstrate that observable behavior on MainNet, Nile, and Shasta is unchanged. Please add byte-level regression checks where applicable.
• Public API and protobuf removals must follow the agreed deprecation window and document any downstream compatibility impact.
• Removing a configuration option must also update reference.conf, validation, documentation, migration guidance, and release notes.
• HTTP and gRPC consolidation must preserve endpoint semantics, error behavior, and cursor isolation under concurrent requests. Equivalence and concurrency tests should be included.
• Each child issue should describe the exact scope, evidence that the code is unused or unreachable, compatibility impact, test plan, and rollback considerations.

Please link every child issue and PR back to this tracking issue and keep the Completed and Planned sections updated. I suggest starting with the lower-risk utility and implementation cleanup items, while handling the cryptographic engine and public API or protobuf changes as separate, higher-scrutiny efforts.

[Sunny6889]

Strongly support this cleanup effort — the duplicated implementations and the silent feature drift they cause are a real maintenance burden, and consolidating them is well worth it.

#6922 is an important subtask under this track, on the HTTP layer: the same API surface is maintained four times (FullNode / Solidity / PBFT / standalone SolidityNode), and the Solidity and PBFT stacks alone are ~96 wrapper servlets whose only job is switching the read cursor, with each service also keeping its own hand-written registration list. It collapses those per-endpoint wrappers into one servlet Filter per cursor service and drives all four services from a single declarative endpoint registry — removing ~2,900 lines with zero external behavior change.

[317787106]

@Sunny6889 Thanks for the support and for opening #6922. This proposal is clearly aligned with the HTTP API consolidation item and is appropriate to track as a child issue.

One clarification: the current proposal should not be described as having “zero external behavior change.” The four services do not expose exactly the same API surface today, and #6922 includes several intentional observable changes, such as adding two endpoints to the PBFT surface, removing five PBFT endpoints, aligning SolidityNode response behavior, and changing IOException handling.

Please continue the detailed design and scope discussion in #6922. Once the scope and verification plan are agreed, we can update this tracking issue accordingly.

[yanghang8612]

Strongly support this cleanup roadmap. Legacy code is not merely cosmetic debt: duplicated implementations can drift over time, ineffective configuration options mislead node operators, and unreachable consensus or cryptographic branches unnecessarily increase maintenance costs and the security-audit surface.

The proposed safeguards are appropriate: preserve observable network behavior, handle each cleanup through a separate Issue and PR, deprecate public APIs before removal, and perform byte-level regression verification for consensus, hashing, serialization, and protocol-encoding changes.

With these safeguards, this cleanup should significantly improve maintainability and security without affecting MainNet, Nile, or Shasta behavior. +1.

[Sunny6889]

@Sunny6889 Thanks for the support and for opening #6922. This proposal is clearly aligned with the HTTP API consolidation item and is appropriate to track as a child issue.

One clarification: the current proposal should not be described as having “zero external behavior change.” The four services do not expose exactly the same API surface today, and #6922 includes several intentional observable changes, such as adding two endpoints to the PBFT surface, removing five PBFT endpoints, aligning SolidityNode response behavior, and changing IOException handling.

Please continue the detailed design and scope discussion in #6922. Once the scope and verification plan are agreed, we can update this tracking issue accordingly.

Thanks for your clarification suggestion, will update the issue description.