[Feature] Block Interface JSON Serialization Optimization

[bladehan1]

Problem Statement

　　The current block-related HTTP interfaces have redundant conversion paths in the JSON serialization process: first fully serialize BlockList / Block into a JSON string, then deserialize it into an object, and finally overwrite some fields. This process introduces the following issues: repeated serialization overhead (multiple conversions of protobuf → JSON → object), causing unnecessary CPU consumption; increased memory and GC pressure due to the creation of a large number of intermediate objects, which amplifies GC overhead under high-frequency calls; increased interface latency, as block queries are high-frequency APIs and the serialization path becomes a performance bottleneck.

Proposed Solution

　　Optimize the JSON construction approach of block interfaces by removing the full serialization process and switching to on-demand JSON construction.

Specification

　　Core optimization: avoid full conversion of protobuf → JSON → object, and instead construct JSON manually (field-by-field population).
　　Method-level changes: printBlockList no longer fully serializes BlockList, but directly constructs a JSONObject and populates the block array; printBlockToJSON no longer fully serializes Block, but only serializes block_header and manually populates blockID and transactions (when non-empty).

API Changes (if applicable)
　　The following interfaces are affected, but the returned fields remain unchanged: GetBlockByLimitNext, GetBlockByLatestNum, GetBlock, GetNowBlock, GetBlockByNum, GetBlockByIdS; returned fields remain unchanged: blockID, block_header, transactions (when present).

Scope of Impact

　　API
　　Tests

Breaking Changes
　　None

Backward Compatibility
　　Fully compatible, response structure remains unchanged, no modification required for callers.

Implementation

Do you have ideas regarding the implementation?
　　Changes: Modify Util.java to construct JSON on demand, remove the full serialization path, while maintaining consistency of output fields; enhance tests: add structural assertions in UtilMockTest.testPrintBlockList.

Are you willing to implement this feature?
　　Yes

Estimated Complexity
　　Low, changes are localized with no cross-module impact, low risk.

Testing Strategy

Test Scenarios
　　Single block interface validation: response contains blockID, block_header, transactions (when present); block list interface: correct length of block array and consistent structure for each element; visible mode regression (visible=true / false): consistent address and field formats; transaction scenarios: blocks with no transactions and blocks with transactions.

Performance Considerations
　　Compare interfaces before and after optimization (getblockbylatestnum, getblockbylimitnext), focusing on metrics: average latency, P95 / P99 latency, CPU usage, GC frequency, and object allocation; expected results: reduced serialization time, decreased memory allocation, and lower GC pressure.

Alternatives Considered (Optional)

　　Keep full serialization + caching: limited benefits and introduces cache consistency complexity; replace JSON library: large scope of changes and high risk; trim response at upper layer: cannot solve the underlying repeated serialization problem.

Additional Context (Optional)

　　This optimization is a hot path performance optimization: targeting high-frequency block query interfaces, reducing redundancy in the serialization pipeline to improve API throughput and response stability; applicable scenarios include batch queries by block explorers, block replay by wallets/gateways, and high-frequency block detail queries.

Related Issues/PRs
　　(To be added)

[lxcmyf]

@bladehan1
Is the optimization mainly targeting serialization CPU overhead or response size reduction?

For high-frequency block queries (e.g., block scanners or indexers), do you have any benchmark results showing the performance improvement?

[bladehan1]

This optimization mainly targets serialization overhead rather than response size.

It removes the redundant protobuf -> JSON string -> object -> field override path, so the main gains are reduced CPU usage, fewer allocations, and lower GC pressure. Batch APIs benefit more since the per-block cost accumulates.
Memory usage may improve slightly due to fewer intermediate objects, but shrinking payload size is not the primary goal.

We don’t have benchmark results yet. The plan is to publish the issue first and add benchmarks (especially for high-frequency block queries scenarios) during implementation.