[Feature] Move keystore-factory as toolkit subcommand

[Federico2014]

Background

KeystoreFactory is a standalone command-line utility for generating wallet keystores and importing private keys, invoked via the --keystore-factory CLI flag from FullNode.jar.

The plugins module already contains several similar standalone tools:

• ArchiveManifest - Archive manifest tool (main entry point)
• Toolkit - General purpose utilities, including DbConvert, DbLite, DbCopy, DbMove, DbRoot, etc.

Problem Statement

KeystoreFactory is functionally a standalone utility tool, not core framework logic. Its current placement in the framework module:

1. Blurs module boundaries: framework should contain core node logic, while plugins houses standalone tools
2. Increases framework coupling: KeystoreFactory has no dependencies on framework-specific code beyond common modules
3. Inconsistent organization: Similar standalone tools already exist in plugins

Rationale

Why should this feature exist?

Moving KeystoreFactory to plugins would:

• Improve code organization by grouping all standalone tools together
• Reduce framework module size
• Make the plugin module's purpose clearer as the home for auxiliary tools
• Follow the existing pattern of similar utilities

What are the use cases?

1. Developers building custom tools: Clearer module structure makes it easier to understand where new tools should be placed
2. Build optimization: Plugin tools can be built and distributed independently
3. Code maintenance: Easier to locate and maintain standalone utilities

Who would benefit from this feature?

• Core developers maintaining the java-tron codebase
• Users who need keystore generation tools (clearer separation of concerns)

Proposed Solution

Move KeystoreFactory to plugins module as a subcommand of Toolkit

Following the existing pattern where db is a subcommand of Toolkit, KeystoreFactory should be added as another subcommand.

Source: framework/src/main/java/org/tron/program/KeystoreFactory.java
Destination: plugins/src/main/java/common/org/tron/plugins/KeystoreFactory.java

Specification

Changes Required:

1. Move the class: Relocate KeystoreFactory.java to plugins/src/main/java/common/
2. Update package: Change package from org.tron.program to org.tron.plugins
3. Refactor to picocli: Add picocli annotations to support being a Toolkit subcommand (like DbLite)
4. Register with Toolkit: Add KeystoreFactory as a subcommand in Toolkit.java
5. Remove CLI flag: Remove --keystore-factory from CLIParameter.java and FullNode.java
6. Update documentation: Update user docs to reflect new invocation method

API Changes

Breaking Change: The --keystore-factory CLI flag will be removed from FullNode.jar.

New invocation method:

# Old method (no longer works after this change)
java -jar FullNode.jar --keystore-factory

# New method (as a Toolkit subcommand)
java -jar Toolkit.jar keystore-factory

Scope of Impact

• Documentation
• Build system / Module structure

Backward Compatibility

• CLI interface changes - users need to update their invocation method
• No impact on keystore file format or functionality

Implementation

Do you have ideas regarding the implementation?

Yes, the implementation follows the existing DbLite subcommand pattern.

Are you willing to implement this feature?

• Yes, I can implement this feature

[halibobo1205]

Agree with removing KeystoreFactory from framework — it doesn't belong there.

But moving it to plugins isn't that simple. KeystoreFactory → WalletUtils → crypto module → common module, which drags in libp2p, prometheus, aspectj, and a bunch of unrelated stuff. Plus WalletUtils calls Args.getInstance(), pulling in Spring as well. Toolkit.jar would get significantly bloated, which kind of defeats the purpose.

Also worth noting that removing KeystoreFactory from the framework would barely reduce the size of FullNode.jar — it's just one small class, and all its dependencies (WalletUtils, crypto, common, etc.) are already used by the node itself. So there's no real packaging benefit on the framework side either.

Since this is a breaking change anyway, why not just remove KeystoreFactory and point users to wallet-cli? It already covers keystore generation and private key import. Framework gets cleaned up, Toolkit stays lean.

[Federico2014]

@halibobo1205 , thank you very much for your suggestion.

I’ve tried this migration: the keystore can be moved from the framework module to the crypto module, and plugins only need to add a dependency on the crypto module. Unnecessary modules such as libp2p, prometheus, and aspectj can also be excluded:

implementation(project(":crypto")) {
    exclude(group: 'io.github.tronprotocol', module: 'libp2p')
    exclude(group: 'io.prometheus')
    exclude(group: 'org.aspectj')
    exclude(group: 'org.apache.httpcomponents')
}

After completing the migration, the Toolkit.jar size increased from 49 MB to 56 MB, which is not a significant increase. Completely removing KeystoreFactory from java-tron is also an option worth considering.

[lxcmyf]

@Federico2014
Will the old FullNode.jar --keystore-factory entry be kept for a transition period, or will it be removed immediately once this feature is merged?

Since some existing scripts or operational tools may already depend on the old invocation method, an abrupt CLI change could break automation.

[Federico2014]

@lxcmyf The current implementation removes java -jar FullNode.jar --keystore-factory immediately. If this causes any negative impact, we could consider introducing a transition period.

Alternatively, could we identify which scripts and operational tools depend on the old CLI usage and update them all accordingly?

[lxcmyf]

@Federico2014
Thanks for the clarification.

Some scripts depending on --keystore-factory may not only exist internally — users may also rely on this CLI entry in their own automation. If it is removed immediately, they might only notice after upgrading.

Providing a short transition path (e.g., deprecation notice or temporary compatibility) could make the migration clearer for external users.