[Feature] Deprecate events field in shielded TRC20 scan APIs

[Federico2014]

Summary

Deprecate and reject the events field in scanShieldedTRC20NotesByIvk / scanShieldedTRC20NotesByOvk API requests. Remove server-side log-type filtering; all log types are always inspected during a scan.

Problem

Motivation

The events field in IvkDecryptTRC20Parameters and OvkDecryptTRC20Parameters allows callers to pass arbitrary topic strings that are hashed and matched server-side to filter shielded TRC20 event classes (Mint / Transfer / Burn). This is an unnecessary attack surface and a source of complexity.

Current State

• The events field is accepted by gRPC and HTTP endpoints
• Server-side code hashes user-supplied topic strings via Hash.sha3() and matches them against known log topics
• Callers can selectively scan only specific log types

Limitations or Risks

• User-controlled strings are hashed server-side, expanding the API attack surface unnecessarily
• Selective scanning can be used for information leakage through side-channel timing
• The filtering logic adds complexity to Wallet.getShieldedTRC20LogType() with nested conditionals
• Clients should filter results client-side rather than relying on server-side filtering

Proposed Solution

Proposed Design

1. Mark the events field as [deprecated = true] in api.proto
2. Reject requests containing the deprecated field at runtime: gRPC returns INVALID_ARGUMENT, HTTP returns 400
3. Remove the topicList / topicsList parameter from all internal method signatures (Wallet, RpcApiService, HTTP servlets)
4. Simplify getShieldedTRC20LogType() to always match against all known log topics

Key Changes

• Protocol: api.proto — deprecate events field in IvkDecryptTRC20Parameters and OvkDecryptTRC20Parameters
• API: RpcApiService — add INVALID_ARGUMENT rejection for Full, Solidity, and PBFT stubs
• API: ScanShieldedTRC20NotesByIvkServlet, ScanShieldedTRC20NotesByOvkServlet — add HTTP 400 rejection
• Module: Wallet — remove topicList parameter, simplify getShieldedTRC20LogType()

Impact

• Security: Reduces API attack surface by removing server-side processing of user-controlled strings
• Stability: Simplifies scan logic, fewer code paths to maintain
• Developer Experience: Cleaner API contract — callers no longer need to understand topic filtering

Compatibility

• Breaking Change: Yes
• Default Behavior Change: All log types are now always scanned; clients that relied on the events field to limit scope will receive results for all log types
• Migration Required: Clients must remove the events field from requests; otherwise requests will be rejected

Additional Notes

• Do you have ideas regarding implementation? Yes
• Are you willing to implement this feature? Yes