13

Traditionally when people have deployed contracts for public use they have tended to publish separate contract addresses for Testnet and Mainnet. Often this then requires them to include code to check which network the contract is on, as we see in this example .

This seems to have been necessary previously because in the absence of replay protection, Morden used a very high accountStartNonce, making it impractical to create the same address on Mainnet. (See Is it possible to give a contract the same address from morden )

Now that EIP 155 replay protection is live and Ropsten is using an accountStartNonce of 0 like Mainnet, are there any good reasons left to carry on using separate addresses for mainnet and testnet, or should we get rid of this code and just use a single address for both?

Improve this question
5
  • it's still a valid safety net having 2 addresses. But there will not be a fully objective answer to this question. Matter of taste.
    – Roland Kofler
    Commented Dec 26, 2016 at 9:12
  • I wanted to created exactly same question, my motivation being: "to publish ICO contract on the testnet and allow less experienced people to to test the MEW, Metamask, other tools." and the explanation why "It is a terribly bad idea - sending real ETH to testnet address will end up in void. And no matter how many times it will be communicated, surely someone will do this. SO NO GO"
    – Mars Robertson
    Commented Jan 1, 2018 at 16:31
  • @MichelStefanow I don't understand that response. Testnet and Mainnet addresses are the same. If you deploy to the same contract address on both networks, a testnet spend will reach the testnet contract, and a mainnet spend will reach the mainnet contract. If you have different addresses and send mainnet coins to the address intended for testnet, they will end up in a void, although you could rescue them by deploying a contract subsequently.
    – Edmund Edgar
    Commented Jan 4, 2018 at 1:16
  • @EdmundEdgar My motivation to have the same address on Mainnet and Ropsten was pre-ICO attempt, allowing people to test drive their wallets, passwords, everything... But because some people will make mistakes and send real ETH to testnet address it's NO GO.
    – Mars Robertson
    Commented Jan 13, 2018 at 4:34
  • you could rescue them by deploying a contract subsequently - I do not agree to that, what if account nonce is too high? On a separate note - I accidentally did it, fresh account, same nonce, magic: steemit.com/ethereum/@genesisre/…
    – Mars Robertson
    Commented Apr 23, 2018 at 7:58

1 Answer 1

Reset to default
3

A rather weak argument against your suggestion is the following: The deployer would have to use the same private key in both test and main net. This could be considered a security risk, as private keys in test net usually do not have to be stored and handled securely, while in main net they most definitely do. Mixing the two domains would, thus, blur the security requirements of each of them.

I would argue, though, that the pros of having the same address in both test and main net are not very convincing either. In the example you linked a better solution would, in my opinion, be passing the respective address in the constructor.

Also, not all net-specific code would be made obsolete anyway (e.g., parameters such as crowd sale durations, validator numbers, ...).

Improve this answer
2
  • I think the way to handle the keys would be to immediately transfer control of the contract to a different address after creating it (and before advertising it) so the key used to mine the contract wasn't in a critical security path in any case.
    – Edmund Edgar
    Commented Dec 25, 2016 at 22:09
  • I think the hard-coding of addresses that I linked is appropriate. The problem is that this is API code that you want other people to be able to incorporate. You don't want to have to force them to manage your address through their constructor - you just want them to be able to add using YourAPI and start calling functions from it.
    – Edmund Edgar
    Commented Dec 25, 2016 at 22:57

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.