JSON RPC methods converting args more consistently

[rmoreliovlabs]

There are some JSON RPC methods that process transactions with data provided as JSON, like eth_sendTransaction, eth_call, eth_estimateGas (the method eth_sendRawTransaction receives the encoded transaction in an hexadecimal string)

Description

They are some JSON RPC methods that process transactions with data provided as JSON, like eth_sendTransaction, eth_call, eth_estimateGas (the method eth_sendRawTransaction receives the encoded transaction in an hexadecimal string)

Let's take one of this arguments: gas

It comes as a string, like "1000000", "0xa000", but also "a000" is accepted in SOME methods (not all, others reject this value without 0x prefix). This is the inconsistency.

In the method EthModule.call

public String call(Web3.CallArguments args, String bnOrId)

an internal method is used: callConstant:

    private ProgramResult callConstant(Web3.CallArguments args, Block executionBlock) {
        CallArgumentsToByteArray hexArgs = new CallArgumentsToByteArray(args);
        return reversibleTransactionExecutor.executeTransaction(
                executionBlock,
                executionBlock.getCoinbase(),
                hexArgs.getGasPrice(),
                hexArgs.getGasLimit(),
                hexArgs.getToAddress(),
                hexArgs.getValue(),
                hexArgs.getData(),
                hexArgs.getFromAddress()
        );
    }

The args.gas field is string. The hexArgs.getGasLimit() code is:

    public byte[] getGasLimit() {
        // maxGasLimit value is 100000000000000
        String maxGasLimit = "0x5AF3107A4000";
        byte[] gasLimit = stringHexToByteArray(maxGasLimit);
        if (args.gas != null && args.gas.length() != 0) {
            gasLimit = stringHexToByteArray(args.gas);
        }

        return gasLimit;
    }

But NOTABLY, the stringHexToByteArray method converts the numeric string (ie "1000") AS HEXADECIMAL:

    public static byte[] stringHexToByteArray(String x) {
        String result = x;
        if (x.startsWith("0x")) {
            result = x.substring(2);
        }
        if (result.length() % 2 != 0) {
            result = "0" + result;
        }
        return Hex.decode(result);
    }

So, the result is a byte array with { 0x10, 0x00 }

This contrasts with the send transaction behavior. eth_sendTransaction receives the same args but it processes them differently. Internally, it executes EthModuleTransactionBase.sendTransaction, that use TypeConverter.stringNumberAsBigInt(args.gas) to convert the gas string.

This is the code of the conversion method:

    public static BigInteger stringNumberAsBigInt(String input) {
        if (input.startsWith("0x")) {
            return TypeConverter.stringHexToBigInteger(input);
        } else {
            return TypeConverter.stringDecimalToBigInteger(input);
        }
    }

IT TAKES INTO ACCOUNT THE PREFIX 0x, so, "1000" will be parse AS DECIMAL, not hexadecimal.

This inconsistency does not affect the consensus, and apparently only affects non-critical methods (query methods).

TO CHECK: other fields conversion, like args.gasPrice

Extracted from: #1458

Motivation and Context

It will add more consistency at the moment of parsing args from our RPC methods

How Has This Been Tested?

Yes added some tests and also tested on postman

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• Tests for the changes have been added (for bug fixes / features)
• Requires Activation Code (Hard Fork)

• Other information:

[rmoreliovlabs]

pipeline:run

[Vovchyk]

pipeline:run

[Vovchyk]

pipeline:run

[rmoreliovlabs]

pipeline:run

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
5 Code Smells

95.2% Coverage
0.0% Duplication