3

I have been attempting to create a simple upgradable contract using Zeppelin OS:

Following the tutorial I have been able to: - Create a new contract - Deploy it using zos push - Create the proxy using zos create MyContractName --init initialize --args singleArgValue

After I have deployed I fire up truffle via truffle console --network local and instantiate access to the contract via `contract = MyContractName.at('0xProxyDeploymentAddress')

Every attempted call or sendTransaction always throws with the same error:

Error: VM Exception while processing transaction: revert Cannot call fallback function from the proxy admin
    at XMLHttpRequest._onHttpResponseEnd (/Users/machine-name/.nvm/versions/node/v8.11.4/lib/node_modules/truffle/build/webpack:/~/xhr2/lib/xhr2.js:509:1)
    at XMLHttpRequest._setReadyState (/Users/machine-name/.nvm/versions/node/v8.11.4/lib/node_modules/truffle/build/webpack:/~/xhr2/lib/xhr2.js:354:1)
    at XMLHttpRequestEventTarget.dispatchEvent (/Users/machine-name/.nvm/versions/node/v8.11.4/lib/node_modules/truffle/build/webpack:/~/xhr2/lib/xhr2.js:64:1)
    at XMLHttpRequest.request.onreadystatechange (/Users/machine-name/.nvm/versions/node/v8.11.4/lib/node_modules/truffle/build/webpack:/~/web3/lib/web3/httpprovider.js:128:1)
    at /Users/machine-name/.nvm/versions/node/v8.11.4/lib/node_modules/truffle/build/webpack:/packages/truffle-provider/wrapper.js:134:1
    at /Users/machine-name/.nvm/versions/node/v8.11.4/lib/node_modules/truffle/build/webpack:/~/web3/lib/web3/requestmanager.js:86:1
    at Object.InvalidResponse (/Users/machine-name/.nvm/versions/node/v8.11.4/lib/node_modules/truffle/build/webpack:/~/web3/lib/web3/errors.js:38:1)

I am able to refer to the original contract (not the proxy) and execute correctly, but everything throws on the proxy.

4

Their documentation isn't the clearest on this one. https://docs.zeppelinos.org/docs/deploying.html

Note that we are using a specific address for the --from option which is different to the default address that ganache-cli would use. This is because we need to use different addresses in order to create upgradeable contracts and to query them. This problem is know as the "transparent proxy issue" and you can read more about it in the ZeppelinOS upgrades pattern section.```

Let's say your available accounts in ganache-cli look like this:

Available Accounts
==================  
(0) 0x90f8bf6a479f320ead074411a4b0e7944ea8c9c1 (~100 ETH)
(1) 0xffcf8fdee72ac11b5c542428b35eef5769c409f0 (~100 ETH)
(2) 0x22d491bde2303f2f43325b2108d26f1eaba1e32b (~100 ETH)

What you want to avoid is choosing the 0-indexed account on there. So start your session with any other in your particular development instance, like so:

zos session --network local --from 0xffcf8fdee72ac11b5c542428b35eef5769c409f0 --expires 3600

I don't know why the documentation doesn't exactly specify this, their explanation is a little vague and it'd be nice if they would clear that up a little.

| improve this answer | |
2

I just faced the same issue. I solved it by adding {from:__non_admin_address__} to my calls, where __non_admin_address__ is address other than admin (deployer). In case of ganache admin address is accounts[0] by default so doing the call with {from:web3.eth.accounts[1]} worked for me. See https://github.com/zeppelinos/zos-lib/issues/226

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.