0

I am trying to implement upgrade of contracts. One pattern by [1] is to have a layer to resolve the actual address of a contract. I implemented that adding the Pausable manipulation. My idea was to pause the old contract before replace them. The old and the new implementation are Pausable contracts (Open Zeppelin). I imagined that it was possible to load the existing contract using their superclass (Pausable). However, this code does not work when trying to change the contract by the second time. In the first time, the code is ok because Resolver was compiled with the original contract and knows that it is Pausable. In the second time, it seems that Resolver cannot understand the load as a kind of Pausable. Do you know how the EVM works? Any idea to solve that?

contract Resolver {

mapping (string => address) nameToAddress;
mapping (string => address[]) nameToPreviousAddresses;

function changeContract(string memory name, address newAddr) public onlyOwner returns (bool) {

    address contractAddr = nameToAddress[name];
    if(newAddr != contractAddr) {

        if (contractAddr != address(0)) {
            Pausable pausable = Pausable(contractAddr);
            pausable.pause();
        }

        nameToPreviousAddresses[name].push(newAddr);
        nameToAddress[name] = newAddr;
        return true;
    }

    return false;
}

function getAddr(string memory name) public view returns (address) {
    return nameToAddress[name];
}

}

[1] https://consensys.github.io/smart-contract-best-practices/software_engineering/#upgrading-broken-contracts

3
  • What exactly do you mean with "Resolver cannot understand the load as a kind of Pausable"? ie It calls pause() but it reverts / It doesn't call pause() / It calls it but it does nothing. I'd check if contractAddr is not null and point to the right contract.
    – Ismael
    Commented Sep 13, 2019 at 5:19
  • It reverts. I realised later that the point was that resolver was not the owner of the second object. Then, it reverts when calling pause. Thank you! Commented Sep 13, 2019 at 13:17
  • If you resolved your issue please add your solution as an answer so the question can be marked as resolved. Thank you!
    – Ismael
    Commented Sep 13, 2019 at 14:31

1 Answer 1

0

I later realized that the resolver was not the owner of the second Pausable. That was the reason of my error. In other words, the EVM solves the call dinamically. If I can change the object, the EVM will call the function of the changed class without error.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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