Solidity Contract Invocation – Handling String Parameter in Raw Call

contract-developmentcontract-invocationsolidity

I'm trying to invoke another contract in solidity using raw calls but I'm encountering some problems.

instance.call.gas(gas).value(price)(bytes4(keccak256("method(string)")), param);

this instruction is inside my second contract and while I try to get the value of the param from my first contract function its empty but instead its value is passed into msg.data.

I added an event on my first contract to see how the parameters has been sent.

function method(string param) payable external {
 Debug(param, msg.sender, msg.value, msg.data);
}

basically param is always empty while the data inside the msg are always sent and in msg.data there is my parameter value (in bytes).

I saw this discussion already and I tried to cast my string to bytes32 or passing the value without storing it into a local variable but the result is the same.

Calling a method directly with a parameter eg. instance.method2(stringParam) will work, but I can't use it in my case since I'm trying to call a payable method and I need to sent eth.

Best Answer

You have to properly encode the parameter using the ABI encoding. Something like

instance.call.gas(gas).value(price)(
    bytes4(keccak256("method(string)")),
    u256(0x20),   // pointer to data
    param.length, // length of data
    param         // actual data
);

could work, but it would probably be better to either use inline assembly for that (because it does not include any magic) or wait a little more and use the function abi.encode which should hopefully be available soon.

In general, using low-level calls is discouraged and should only be used of there is no other way, for example if you do not want to propagate a revert condition.

You can do the same (apart from not propagating the revert) using

interface MethodStringInterface {
    function method(string);
}
contract MyContract {
    function myFunction(address _a) {
        MethodStringInterface(_a).method("abc");
    }
}

or even better:

interface MethodStringInterface {
    function method(string);
}
contract MyContract {
    function myFunction(MethodStringInterface _a) {
        _a.method("abc");
    }
}

Related Solutions

Solidity – Error When Encoding Arguments to Call a Function with Bytes32 Type Parameters

You need to convert the value in hex to be passed. neo is 0x6e656f in hex. If you try to pass '0x6e656f' it will work (don't forget the quote).

Solidity Contract Design – How to Transfer All msg.sender.balance to Contract Without msg.value Input

You need to reverse the flow of things or this will never make sense.

There is no way to code a contract to transfer funds from a user wallet. Not all, not some, not any.

address(this).transfer(msg.sender.balance)

That means the destination (to) is address(this) and the amount is the msg.sender's balance. from: address is implicitly address(this) because nothing else is possible. Therefore, from isn't mentioned in the syntax.

What you actually want to happen is for the user to sign a transaction that sends their money to your contract. I don't know why it has to be their entire balance and that sounds to me like another design misstep but here is how you would do it.

It's a front-end concern. Again, for emphasis, because only the user can authorize the transfer of their own funds. On the contract side, all you can do is receive it, validate the transaction and possibly reject it if something is wrong.

function depositFunds() public payable {
  // carry on
  // msg.value and msg.sender inform about who and how much
}

On the front end you would Web3 or a similar library to help the user form a valid transaction with amount: as much as possible, to: your contract, {gas: amount, gasPrice: bid}.

The user has to pay for gas, and this will reduce the amount of funds available to send to your contract. You have to take that into account. Your front end will have to figure out:

gas estimate for the transaction
gasPrice (Ether cost consumed = gas estimate * gasPrice)
Funds available to send (user's balance - cost consumed), leaving the user with exactly 0 remaining balance.

If the browser (or server) performs the computation, then the user will be presented the option to sign a transaction sending x amount, and bidding y for gas, with a gas estimate of z leaving them with a final balance of 0.

It's unclear to me why anyone would agree to such terms.

Hope it helps.

Best Answer

Related Solutions

Solidity – Error When Encoding Arguments to Call a Function with Bytes32 Type Parameters

Solidity Contract Design – How to Transfer All msg.sender.balance to Contract Without msg.value Input

Related Topic