[Feature] Add ABI semantic validation for `/wallet/deploycontract`

[yanghang8612]

Summary

Add semantic ABI validation to the /wallet/deploycontract interface so malformed or non-standard ABI definitions are rejected before transaction construction. The validation rules should follow the Solidity ABI specification to improve tooling compatibility and reduce audit findings around "ABI injection".

Problem

Motivation

The /wallet/deploycontract interface currently accepts user-supplied ABI data with only basic JSON-to-protobuf parsing. This leaves room for malformed ABI definitions to pass through even when they do not conform to common ABI expectations.

Current State

In the current implementation, the abi field in the deploy contract request is parsed into protobuf structures, but there is no complete semantic validation of ABI entry types or parameter types.

Examples of inputs that may not be properly rejected today include:

• invalid parameter types such as uint, malformed array types, or illegal bytesN
• duplicate fallback or receive entries
• receive entries with non-payable mutability
• tuple-related definitions that cannot be fully represented by the current schema

Limitations or Risks

This creates several issues:

• malformed ABI metadata may be accepted and persisted
• downstream tooling may interpret the stored ABI inconsistently
• audit tools may report this as an ABI injection issue
• developer experience suffers because invalid ABI is not rejected early with clear errors

Proposed Solution

Proposed Design

Introduce a dedicated ABI validation step for the /wallet/deploycontract interface and reject malformed ABI definitions before building the transaction.

This proposal changes the behavior of that specific interface: requests with an invalid abi field should fail fast during request handling / transaction construction, instead of being accepted and converted into protobuf ABI data.

At minimum, the validation should:

• validate top-level ABI entry types
• validate parameter types in inputs and outputs
• reject duplicate fallback and receive entries
• require receive.stateMutability == payable
• reject tuple definitions that cannot be safely stored or parsed by the current ABI schema

The implementation should follow the Solidity ABI specification, while keeping the final logic aligned with java-tron's own schema and compatibility requirements.

Key Changes

• Module(s): /wallet/deploycontract request handling
• Module(s): ABI parsing / validation utility
• API: stricter validation for the abi field in /wallet/deploycontract requests
• Test: add coverage for representative invalid ABI cases

Impact

This change is expected to improve:

• Security: stronger input validation and less room for malformed ABI payloads
• Stability: fewer inconsistencies in stored ABI metadata
• Developer Experience: earlier and clearer error reporting for invalid ABI input
• Tooling Compatibility: behavior closer to common ABI expectations

Compatibility

• Breaking Change: No
• Default Behavior Change: Invalid ABI payloads sent to the /wallet/deploycontract interface that were previously accepted may now be rejected during request handling / deploy transaction construction
• Migration Required: No for valid ABI definitions

References (Optional)

• Prior art: Solidity ABI specification and Solidity documentation
• Related issue: audit findings describing the problem as "ABI injection"

Additional Notes

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

[lxcmyf]

Looked through the current code path and the missing validation seems to be in /wallet/deploycontract: DeployContractServlet currently wraps the raw abi array and feeds it directly into JsonFormat.merge(...), so today we mostly get protobuf-shape validation, not ABI semantic validation.

A practical implementation path seems to be:

• add a dedicated ABI validator before transaction construction
• validate top-level entry kinds and parameter type strings against Solidity ABI rules
• reject duplicate fallback / receive
• enforce receive as stateMutability=payable
• reject tuple / tuple arrays for now, because SmartContract.ABI.Entry.Param only stores name / type / indexed and has no components

One more thing worth keeping aligned: smart_contract.proto already defines Receive, but helper JSON-to-ABI parsers such as PublicMethod.jsonStr2Abi and TvmTestUtils.jsonStr2Abi still do not enforce the same semantic rules. If this is implemented in the deploy path, it would be better to reuse the same validator in those conversion helpers as well, otherwise the behavior will drift between request handling and test/util code.

[lvs0075]

The direction is right, but there's a compatibility risk worth discussing upfront.

A large number of contracts already deployed via /wallet/deploycontract may have ABI entries that don't strictly conform to the Solidity spec — historically, some toolchains generated ABI with bare uint types without bit widths. Since the new validation only affects incoming deploy requests and not on-chain data, that's fine and consistent with what the issue describes.

The more immediate concern is third-party SDKs. Older versions of TronWeb and similar tooling may serialize the abi field in ways that don't fully match the spec. Before rolling this out, it would be worth:

1. Sampling a set of real on-chain contract ABIs to measure the false-rejection rate of the proposed rules
2. Ensuring error responses include the specific field path and failure reason, so SDK maintainers can adapt quickly

If the validation rules are precise, this change is transparent to users and not a breaking change in practice. If the false-rejection rate is non-trivial, it will create significant friction for developers. The sampling step would help calibrate that before implementation.

[yanghang8612]

@lxcmyf Thanks, this makes sense.

I agree the main gap here is ABI semantic validation in /wallet/deploycontract, not protobuf parsing itself. The current path already gives us basic protobuf-shape validation through JsonFormat.merge(...), but it does not validate ABI semantics.

I also agree with the proposed direction:

• add a dedicated validator before transaction construction
• validate entry kinds and parameter type strings against Solidity ABI rules
• reject duplicate fallback / receive
• require receive to be payable
• reject tuple / tuple arrays for now, since the current Param schema does not preserve components

Good point as well on keeping helper conversions aligned. Reusing the same validator in PublicMethod.jsonStr2Abi and TvmTestUtils.jsonStr2Abi would help avoid drift between request handling and test/util code.

[yanghang8612]

@lvs0075 Thanks, this is a good point.

I agree the main compatibility risk is not existing on-chain ABI data, but incoming deploy requests from older SDKs or toolchains that may not fully follow the Solidity ABI spec.

I will sample and analyze a recent set of on-chain contract ABIs in the near term to estimate the false-rejection risk before narrowing the validation rules. I also agree that, if this moves forward, the error response should include the exact field path and failure reason so SDK maintainers can adapt quickly.

[CodeNinjaEvan]

Thanks for putting this together — this is a valuable improvement!

One thing worth considering: java-tron exposes both the HTTP interface (/wallet/deploycontract) and a gRPC interface for contract deployment. If the ABI semantic validation is only added at the DeployContractServlet layer, the gRPC path may not go through the same validation logic and could potentially bypass these checks. Has this been considered in the design?