fix(crypto): deprecate events field in shielded TRC20 scan APIs

[Federico2014]

What does this PR do?

Deprecates the events field in shielded TRC20 scan API requests and removes server-side log-type filtering.

1. Marked the events field as [deprecated = true] in IvkDecryptTRC20Parameters and OvkDecryptTRC20Parameters request messages in api.proto
2. Added runtime rejection: gRPC returns INVALID_ARGUMENT, HTTP returns 400 when the events field contains at least one non-empty string. An events list that is absent or contains only empty strings is treated as not set and passes through normally.
3. Removed topicList parameter from internal method signatures in Wallet, RpcApiService, and HTTP servlet handlers (ScanShieldedTRC20NotesByIvkServlet, ScanShieldedTRC20NotesByOvkServlet)
4. All log types (Mint/Transfer/Burn) are now always inspected during a scan
5. Added gRPC and HTTP test coverage for both the rejection path and the empty-events pass-through path across Full, Solidity, and PBFT stubs

Why are these changes required?

The events field allowed callers to filter shielded TRC20 event classes by passing user-controlled log topic strings that were hashed and matched server-side. This was an unnecessary attack surface — callers should always scan all log types and filter client-side. Removing the field simplifies the API contract and eliminates potential information leakage through selective scanning.

⚠️ Breaking Changes:

• scanShieldedTRC20NotesByIvk/Ovk — the events field is rejected when it contains at least one non-empty value (INVALID_ARGUMENT on gRPC, HTTP 400). An absent field or a field containing only empty strings is accepted and treated as if the field were not set. Clients still sending non-empty event values must remove them. Clients that relied on the field to limit scan scope will now receive results for all log types.
• Other malformed inputs (e.g. invalid block index format in GET) continue to return the existing error response and are not affected by this change.

This PR has been tested by:

• Unit Tests — RpcApiServicesTest, WalletMockTest, ShieldedTRC20BuilderTest
• Build passes (./gradlew clean build)

Follow up

No consensus logic or on-chain state transitions affected.

Extra details

[waynercheung]

[SHOULD] The new rejection coverage is currently gRPC-only, but HTTP 400 is also part of the external contract introduced by this PR. Please add servlet-level regression tests for scanShieldedTRC20NotesByIvk/Ovk GET and POST to verify that requests with events return HTTP 400 and include the deprecation message. A small smoke test for the Solidity/PBFT HTTP wrappers would also help confirm the status code is preserved through the futureGet(...) wrapper.

[Federico2014]

@waynercheung Fixed. Added ScanShieldedTRC20NotesServletTest covering all four cases — IVK POST, IVK GET, OVK POST, OVK GET — each asserting HTTP 400 and the deprecation message in the response body.

For the Solidity/PBFT wrappers: futureGet is synchronous and simply sets a DB cursor before delegating to super.doPost/doGet, so the rejectIfEventsPresent check and the SC_BAD_REQUEST status are set before any cursor operation is reached. The behavior is identical to the main servlet, with no additional code path to verify.

[3for]

There are currently four predefined topic constants:

• SHIELDED_TRC20_LOG_TOPICS_MINT
• SHIELDED_TRC20_LOG_TOPICS_TRANSFER
• SHIELDED_TRC20_LOG_TOPICS_BURN_LEAF
• SHIELDED_TRC20_LOG_TOPICS_BURN_TOKEN

With the current change, when events is not provided, the behavior remains the same (matching all four standard topics). However, previously supported subset filtering (e.g., events=["mint"]) is no longer accepted and now results in 400 / INVALID_ARGUMENT.

It seems this change also disables custom topic scanning, which is understandable since the previous sha3 + substring match approach was not very reliable.

For clarity, the behavior change can be summarized as:

Client Behavior	Old Server	New Server	Impact
No events param	Scan all 4 types	Scan all 4 types	No change
events=["mint"] (subset filtering)	Return only mint	400 / INVALID_ARGUMENT	Breaking change
Custom topic (non-standard event)	sha3 + substring match (unreliable)	400 / INVALID_ARGUMENT	Breaking change

Suggestion

Would it be possible to only disable custom/non-standard event scanning, while still allowing filtering within the predefined topic set?

In other words:

• ✅ Keep support for standard subsets such as events=["mint"], ["transfer"], or combinations
• ❌ Disallow arbitrary/custom topics outside the predefined constants

This would preserve backward compatibility for existing clients while still addressing the reliability concerns of custom topic matching.

[Federico2014]

@3for Thanks for the detailed breakdown. To clarify: the old code never implemented subset filtering either. When events was empty, it always scanned all 4 predefined types (exact match against the 4 log topic constants). When events was non-empty, it did a sha3(topic_string) comparison — which only matched if the caller passed the exact full ABI event signature string, and even then, the classification still relied on a fragile substring check. There was no "pass mint, get only mint results" path.

The PR removes this non-functional code path and makes the behavior explicit: always scan all predefined types, reject any non-empty events field. This is the intended design.

[bladehan1]

Followup on the previous review — all 5 received comments are addressed; thanks for the thorough iteration. A few small follow-ups inline.

[bladehan1]

[SHOULD] testGetShieldedTRC20LogType2 in WalletMockTest.java does not assert the return value

After removing the topicsList parameter, Wallet.getShieldedTRC20LogType performs a pure constant comparison against SHIELDED_TRC20_LOG_TOPICS_MINT/TRANSFER/BURN_LEAF/BURN_TOKEN. The test currently only asserts that no exception is thrown — it does not verify that any of the four expected log types actually return the correct int value (1, 2, 3, 4). If the constants are wrong or the byte-comparison logic has a bug, the test will still pass.

Suggestion: Add assertEquals assertions after invoking the method with each of the four topic constants, verifying the returned value is 1, 2, 3, and 4 respectively, plus assert that an unknown topic returns 0. Could be tackled in a follow-up PR if you prefer to keep this one focused on the deprecation rollout.

[Federico2014]

@bladehan1 Agreed — the existing tests only validated the input-validation path and the unknown-topic path; the four happy branches (return 1/2/3/4) had no coverage, which would have masked a bug in either the constants or the byte-comparison. Addressed in this PR rather than deferred since the simplification of getShieldedTRC20LogType is itself one of the deliverables.

Changes:

• Added testGetShieldedTRC20LogTypeReturnsCorrectInt: hashes each of the four event signatures (MintNewLeaf, TransferNewLeaf, BurnNewLeaf, TokenBurn) with Hash.sha3(...) and asserts the method returns 1, 2, 3, 4 respectively.
• Tightened testGetShieldedTRC20LogType1 and testGetShieldedTRC20LogType2 to capture the return value and assertEquals(0, ...), making the unknown-topic contract explicit instead of just "didn't throw".

Build + targeted run pass: all 4 testGetShieldedTRC20LogType* tests green.

[bladehan1]

LGTM

[0xbigapple]

LGTM

[waynercheung]

LGTM