Allow to deploy proxy contract more than once #38
Comments
dimpar
added a commit
to keep-network/tbtc-v2
that referenced
this issue
Feb 27, 2023
…550) Closes #543 # The contract `L2TBTC` is a canonical L2/sidechain token implementation. tBTC token is minted on L1 and locked there to be moved to L2/sidechain. By deploying a canonical token on each L2/sidechain, we can ensure the supply of tBTC remains sacrosanct, while enabling quick, interoperable cross-chain bridges and localizing ecosystem risk. This contract is flexible enough to: - Delegate minting authority to a native bridge on the chain, if present. - Delegate minting authority to a short list of ecosystem bridges. - Have mints and burns paused by any one of n guardians, allowing avoidance of contagion in case of a chain- or bridge-specific incident. - Be governed and upgradeable. The token is burnable by the token holder and supports EIP2612 permits. Token holder can authorize a transfer of their token with a signature conforming EIP712 standard instead of an on-chain transaction from their address. Anyone can submit this signature on the user's behalf by calling the permit function, paying gas fees, and possibly performing other actions in the same transaction. The governance can recover ERC20 and ERC721 tokens sent mistakenly to `L2TBTC` token contract. # Testing All functions defined in `L2TBTC` contract are fully covered with tests. `L2TBTC` contract inherits from OpenZeppelin contracts and we do not want to test the framework. At the same time, we need to make sure all the declared functionalities are exposed by the contract and that they work. The tests must fail if the contract initialization gets broken or if one of the OpenZeppelin extensions is dropped from the inheritance. To make it happen, the tests cover really basic scenarios for the code implemented in OpenZeppelin ERC20 and extensions. The tests use `helpers.upgrades.deployProxy` to deploy `L2TBTC` and to test it as a contract deployed behind a proxy. There is a [small complication](https://github.com/keep-network/tbtc-v2/pull/550/files/7ae7122334a75cbbcd3a2b117082ad4e5ddde3d3#diff-35dc35185324e88cdeb94aa85d52542cd9bf3fb6b3bddddb2e2fcbf7a42c4ebd) with this approach that led to opening an issue in our hardhat plugins repo: keep-network/hardhat-helpers#38.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sometimes I want to deploy a contract behind a proxy in a unit test, outside of deployment scripts. One example of such a contract is
L2TBTC. A common parent contract for all L2s and sidechains. Each chain-specific implementation will inherit from that contract and specify the token name and symbol. To not repeat the same tests over and over again, I want to test the parentL2TBTCcontract. Since this contract is upgradeable and all L2 tokens are expected to be deployed behind a proxy, I want to test this contract as deployed behind a proxy. At the same time, I do not want to add it to the deployment scripts because it is deployed by a separate project, specific to the given chain.When I call
await helpers.upgrades.deployProxyfor the second time (callyarn testtwice), the second run fails with* was already deployederror here because the artifact for the contract is stored indeployments/hardhat.I think this behavior is different from
hre.deployments.deploy. From the docs:If detecting code changes is hard, I would suggest to add a flag allowing to force deployment, even if the contract was already deployed.
The text was updated successfully, but these errors were encountered: