Initialization argument encoding issues.

[dimonkov]

Seems similar to the #410, #414, #60 (especially this one, but we are not using a beta version of Truffle or Ganache).

zos create <contract> --init args [arg0, ...] argument encoding sometimes fails.

As you can see in this attached project, we have a single test contract named o that inherits from Ownable and has a single function initialize that accepts 1 argument of type address and just memorises it.

The issue is that by suppling different addresses in args (zos create o --init --args "address_goes_here") and later reading the value from the contract we get very different results.

With these two addresses : '0xC2D7CF95645D33006175B78989035C7c9061d3F9','0xEB1020C2BfA170489fca37068F9c857CDCd5f19F' is seems to work just fine,
however, with these two: '0x931BEd74FF2eDCd6f7fF7504a2e74971Aaf4ABCA', '0x39af68cF04Abb0eF8f9d8191E1bD9c041E80e18e' - a weird number is returned instead of the supplied address (it is 0x0000000000000000000000000000000000000977 every time).

We were able to identify, that with these 2 last addresses(and possibly more of them) the transaction data that is sent to the blockchain is identical (we diff'ed TxData from Ganache, it is the same),
whereas it is different with the 2 first addresses (as it should be!).

So, we came to the conclusion, that argument encoding is broken.

Please see the attached project file and follow the instructions to reproduce the issue.

Steps to reproduce the issue:

0) start ganache at 127.0.0.1:9545  
1) npm i  
2) zos session -n local  
3) zos push -d  
4) zos create o --init --args "0x39af68cF04Abb0eF8f9d8191E1bD9c041E80e18e"  

5) truffle console --network local  
6) truffle(local)> var o1 = o.at("address_of_deployed_contract");  
7) truffle(local)> o1.owner({from: "0xe301aa420C65525E19020eAdB5f5fbe09B97DB10"});  

Displays '0x0000000000000000000000000000000000000977'.

Should display '0x39af68cF04Abb0eF8f9d8191E1bD9c041E80e18e'.

Software versions:

macOS 10.14.1

npm version { test: '1.0.0', npm: '6.4.1', ares: '1.14.0', cldr: '33.1', http_parser: '2.8.0', icu: '62.1', modules: '67', napi: '3', nghttp2: '1.34.0', node: '11.1.0', openssl: '1.1.0i', tz: '2018e', unicode: '11.0', uv: '1.23.2', v8: '7.0.276.32-node.7', zlib: '1.2.11' }

Truffle v4.1.14 (core: 4.1.14)
Solidity v0.4.24 (solc-js)
Ganache GUI version v1.2.2
ZeppelinOS version 2.0.1

[theethernaut]

Hey @dimonkov . Thx for the report.

A couple of things look a bit awkward on your example, could you please clarify?

1. Since you are not using npx and instead a global version of ZeppelinOS, what version are you using? Just as a side note, I strongly suggest that you use npx and a local version of ZeppelinOS in your projects and stop using the global version.
2. If o.sol's inititialize function takes a single address argument, then why are you talking about calling it with two addresses instead of one? In your "steps to reproduce" you use only one, and I was not able to reproduce the reported behavior using ZeppelinOS 2.0.1.

[dimonkov]

Oh, sorry if my description confused you.

1. zos --version gives me 2.0.1, so - the same version as you have.
2. Yes, it takes only one address, but depending on the address passed it ether behaves normally or writes complete noncence into it.

Just try to deploy it once with 0xEB1020C2BfA170489fca37068F9c857CDCd5f19F - it will behave correctly.

Restart ganache and redeploy the contract, but this time with 0x39af68cF04Abb0eF8f9d8191E1bD9c041E80e18e as init address and it writes 0x0000000000000000000000000000000000000977 into it instead (at least for me and my collegue).

We tested this on two machines and observed exactly the same behaviour.

[dimonkov]

@ajsantander as a side note - this article recommends using a globally installed version.
Is there something I'm missing, or it's just an old documentation then?

[medied]

Chiming in here to share a similar behavior I saw executing a zos create—

root@eth:~/zos-token# npx zos create openzeppelin-eth/StandaloneERC20 --args "democracyEarthTest,VOTE,18,100000000000,0x409fBa3B052139E67812e405c52cc4E9fAaB9F3D,[],[]" --network mainnet
Creating proxy to logic contract 0x3ead9354c7ec6f0907e10a3d69f321def89429b2 and initializing by calling initialize with:
 - name (string): "democracyEarthTest"
 - symbol (string): "VOTE"
 - decimals (uint8): "18"
 - initialSupply (uint256): "100000000000"
 - initialHolder (address): "0x409fBa3B052139E67812e405c52cc4E9fAaB9F3D"
 - minters (address[]): []
 - pausers (address[]): []
Instance created at 0x801a58593299102ca861f5a633e549c43d129a1c
0x801a58593299102ca861f5a633e549c43d129a1c
Updated zos.mainnet.json

The zos create went through with no errors but tokens landed in 0x0000000000000000000000000000000000000977 account instead of the initialHolder specified.

On a second attempt, I tried with the initialHolder address all in lowercase and that worked as expected. I'm reading capitalization in the address indicates if it has a checksum or not, but still haven't been able to confirm if that has anything to do with the issue

[nfurfaro]

I've just experienced the same issue trying to run:
zos create Unlock --init initialize --args 0x3CA206264762Caf81a8F0A843bbB850987B41e16
Afterwards,unlock.owner() returns '0x0000000000000000000000000000000000000977'

[znss1989]

Same problem occurs. After switching the address arguments to lower case, the getter function for owner returns 0x0 now, rather than 0x977. However, this error occurs only in my test in Rinkeby. In ganache test, everything works correctly. Quite confused.

For contract below

pragma solidity ^0.4.24;

import "openzeppelin-eth/contracts/ownership/Ownable.sol";

contract Foo is Ownable {

    uint256 public x;
    string public s;

    function initialize(uint256 _x, string _s, address _supplier) initializer public {
        
        x = _x;
        s = _s;
        Ownable.initialize(_supplier);
    }
}

I used the command below to have the proxy contract, where the two address below are the ones that have some Rinkeby ethers.

zos create Foo --network rinkeby --init initialize --args 42,hello,0x9b71XXXXXXXXXXXXXXXXf21 --from 0x64fXXXXXXXXXXXXXXXXXX45a

My truffle configuration is as below.

'use strict';

const HDWalletProvider = require('truffle-hdwallet-provider');

const getMnemonic = require('./getMnemonic');
const rinkebyEndpoint = "https://rinkeby.infura.io/v3/0d714XXXXXXXXXXX67a";

module.exports = {
  networks: {
    local: {
      host: 'localhost',
      port: 9545,
      gas: 5000000,
      gasPrice: 5e9,
      network_id: '*'
    },
    rinkeby: {
      provider: () => {
        return new HDWalletProvider(getMnemonic(), rinkebyEndpoint);
      },
      network_id: 4,
      gasPrice: 41000000000
    }
  }
};

In truffle console for rinkeby I get response below

foo = Foo.at('0x8263dcee5086dfe72b17945fa483b7e7ea5f04fd')
foo.owner()
// '0x0000000000000000000000000000000000000000'

[leshaaa]

Hi guys, I've also experienced this issue and I believe it's a bug in 'helpers/encodeCall'. There is a regex check /\d+(\.\d+)?e(\+)?\d+/ supposed to match numbers like '4.5e6'. But I've faced with the problem that it matches also address arguments like '0x6379881e1E1dE4aD627C91b0545a27F5DF379B2F' (Ganache first address). I figured it out when I run the following command against zos 2.0.2:

zos create MyContract --init initialize --args 0x6379881e1E1dE4aD627C91b0545a27F5DF379B2F

This command gives the following output:

Creating proxy to logic contract 0xa3cee732f34d3ee72ea40098e6db3fb2a53cda0a and initializing by calling initialize with:
 - owner (address): "0x6379881e1E1dE4aD627C91b0545a27F5DF379B2F"

The output looks correct, but in fact, it initializes contract with a wrong value '0000000000000000000000000000000000000000000000000000000000000977' which is NaN after abi.rawEncode

[theethernaut]

@dimonkov

Yes, you are right, the documentation still has examples that show global usage of zos. This is something we intend to fix soon. For now, I confirm that the recommendation is to use npx instead.

Also, thx for the clarification on the bug's description. I can reproduce it now. Will come back with an update!

[theethernaut]

@leshaaa indeed, that was the problem. Submitting a fix =D thxx