[Feature] Expose effective runtime parameters through the Admin API

[317787106]

Background

The Admin framework described in tronprotocol#6497 provides a unified JSON-RPC service over Admin HTTP and local IPC. Both transports use the same method definitions and business implementation, making the framework suitable for querying the effective state of a running FullNode.

At present, operators mainly inspect configuration files and logs when diagnosing a node. The configuration file does not always represent the effective runtime state because parameters may have been initialized, normalized, overridden, or dynamically reloaded after startup. A read-only Admin method is therefore needed to expose the parameters currently used by the node.

Rationale

Runtime parameter inspection improves observability and troubleshooting without requiring a node restart. It allows operators to confirm whether configuration changes have taken effect and compare the effective settings of different nodes.

The exported data must not be implemented as unrestricted serialization of the complete configuration object. CommonParameter contains implementation objects, dynamically discovered network state, database-backed governance values, and potentially sensitive fields. The API needs a reviewed and stable export boundary so that adding a field to an internal class does not automatically make it publicly visible.

Specification

Add the following read-only method to AdminJsonRpc:

@JsonRpcMethod("admin_getRuntimeParameters")
Map<String, Object> getRuntimeParameters();

The method should be available through both Admin HTTP and IPC and should not accept parameters.

A JSON-RPC request can be sent as follows:

{
  "jsonrpc": "2.0",
  "method": "admin_getRuntimeParameters",
  "params": [],
  "id": 1
}

The response should represent a snapshot of the effective runtime parameters. Top-level keys should be returned in lexicographical field-name order to provide stable and readable output.

Export Boundary

Only explicitly reviewed fields should be exposed. A top-level @Exportable annotation should be introduced for fields in the active CommonParameter implementation. Fields without this annotation must be excluded by default.

1. Committee and governance parameters whose effective values are maintained in the database should not be exported from their configuration defaults, because those values may not represent the current chain state.
2. Complex configuration objects must not be recursively serialized without review. Genesis, Storage, and P2P configuration should use explicit snapshots containing only stable and supported values.
3. The Genesis snapshot should export account names as UTF-8 strings and account and witness addresses as configuration-compatible Base58Check strings. This avoids exposing protobuf metadata or Base64-encoded byte arrays.
4. The Storage snapshot should include reviewed database settings, option overrides, cache strategies, configured databases, and Merkle roots. Runtime collaborators and unsupported third-party implementation fields should not be serialized automatically.
5. The P2P snapshot should contain reviewed network settings while excluding the node ID and runtime-discovered seed, active, and trust peer collections. These collections may change while the node runs and may contain addresses that were not supplied directly by the operator.

Sensitive Data Handling

The exporter should recursively inspect exported object and array values. Fields whose names indicate passwords, private keys, secrets, credentials, tokens, authorization data, mnemonic phrases, or similar sensitive information must be replaced with a fixed value such as:

[REDACTED]

DNS publishing credentials must be explicitly redacted. eventPluginConfig.dbConfig should be omitted because it may contain backend connection details or credentials.

If one field cannot be converted into a stable snapshot, the failure should not make the complete Admin request fail. The affected field should be represented as unavailable, while the remaining parameters are still returned. Logs should identify the field and exception type without exposing its value.

Runtime Consistency

Dynamic configuration may replace active, passive, fast-forward, or seed-node collections while the API is building its response. Updated collections should therefore be constructed completely before being published to the active runtime configuration.

A caller should observe either the previous complete snapshot or the new complete snapshot. It should not observe a temporary empty or partially updated collection during dynamic configuration reload.

The API returns a point-in-time operational snapshot. It does not guarantee that every independently changing runtime value was captured at the same instant.

Security Considerations

Although this method is read-only, runtime configuration may reveal network topology, ports, storage settings, and other operational information. It must only be exposed through the existing Admin HTTP and IPC security boundaries.

Admin HTTP should remain disabled by default and bound to loopback by default. IPC access should continue to be protected by local socket-file permissions. Deployments exposing Admin HTTP beyond loopback must provide appropriate network isolation and authentication.

The explicit allowlist, reviewed snapshots, recursive redaction, and omission rules provide complementary protection. Newly added fields must not become externally visible until they have been reviewed and explicitly marked for export.

Test Specification

Tests should verify that only annotated fields are exported, top-level keys are ordered deterministically, unmarked and database-backed governance fields are excluded, and sensitive nested values are redacted.

Genesis tests should verify UTF-8 account names and Base58Check addresses. Storage tests should cover database options, overrides, cache strategies, database properties, and Merkle roots. P2P tests should confirm that stable configuration is included while runtime peer collections and the node ID are excluded.

Dynamic configuration tests should verify that callers cannot observe transient empty or partially updated node lists. Admin HTTP and IPC tests should confirm that admin_getRuntimeParameters is dispatched consistently and returns the same JSON-compatible structure.

Scope of Impact

The change affects CommonParameter, dynamic configuration publication, the Admin JSON-RPC interface, and the runtime parameter exporter. It does not modify runtime parameters, configuration files, chain state, consensus behavior, P2P messages, or existing public APIs. The method is observational and has no side effects.

Backwards Compatibility

This change only adds a new Admin JSON-RPC method. Existing Admin methods and existing HTTP, IPC, gRPC, and JSON-RPC interfaces remain unchanged. No configuration migration is required, and nodes that do not call the new method retain their existing behavior.

References

The Admin transport and security architecture is described in tronprotocol#6497.