Возможно ли и имеет смысл развернуть контракт на один и тот же адрес в Mainnet и Ropsten?

Традиционно, когда люди развертывали контракты для публичного использования, они, как правило, публиковали отдельные адреса контрактов для Testnet и Mainnet. Часто это требует от них включения кода для проверки того, в какой сети находится контракт, как мы видим в этом примере .

Похоже, это было необходимо ранее, потому что из-за отсутствия защиты от повторного воспроизведения Морден использовал очень высокое значение accountStartNonce , что делало непрактичным создание того же адреса в основной сети. (См. Можно ли указать в контракте тот же адрес, что и в Мордене )

Теперь, когда защита от воспроизведения EIP 155 работает, а Ropsten использует accountStartNonce со значением 0 , как и в основной сети, есть ли веские причины продолжать использовать отдельные адреса для основной сети и тестовой сети, или мы должны избавиться от этого кода и просто использовать один адрес? для обоих?

это все еще действующая система безопасности, имеющая 2 адреса. Но полностью объективного ответа на этот вопрос не будет. Дело вкуса.
Я хотел создать точно такой же вопрос, моя мотивация заключалась в следующем: «опубликовать контракт ICO в тестовой сети и позволить менее опытным людям протестировать MEW, Metamask и другие инструменты». и объяснение, почему «Это ужасно плохая идея — отправка реального ETH на адрес тестовой сети закончится ничем. И независимо от того, сколько раз это будет передано, обязательно кто-нибудь это сделает. ТАК НЕ ИДИТЕ »
@MichelStefanow Я не понимаю этот ответ. Адреса Testnet и Mainnet совпадают. Если вы выполняете развертывание на один и тот же адрес контракта в обеих сетях, расходы на тестовую сеть достигают контракта на тестовую сеть, а расходы на основную сеть достигают контракта в основной сети. Если у вас разные адреса и вы отправляете монеты основной сети на адрес, предназначенный для тестовой сети, они окажутся в пустоте, хотя вы можете спасти их, развернув впоследствии контракт.
@EdmundEdgar Моей мотивацией было иметь тот же адрес, Mainnetи Ropstenэто была попытка до ICO, позволяющая людям тестировать свои кошельки, пароли, все ... Но, поскольку некоторые люди будут совершать ошибки и отправлять настоящие ETH на адрес тестовой сети, это НЕ ПРОЙДЕТ .
you could rescue them by deploying a contract subsequently- Я с этим не согласен, а если счетный одноразовый номер слишком большой? Отдельное замечание - случайно сделал, свежий аккаунт, тот же нонс, магия: steemit.com/ethereum/@genesisre/…

Ответы (1)

Довольно слабый аргумент против вашего предложения заключается в следующем: разработчику придется использовать один и тот же закрытый ключ как в тестовой, так и в основной сети. Это можно рассматривать как угрозу безопасности, так как закрытые ключи в тестовой сети обычно не нужно хранить и обрабатывать безопасно, в то время как в основной сети они определенно нужны. Таким образом, смешивание двух доменов размыло бы требования безопасности каждого из них.

Однако я бы сказал, что плюсы наличия одного и того же адреса как в тестовой, так и в основной сети также не очень убедительны. В приведенном вами примере лучшим решением, на мой взгляд, будет передача соответствующего адреса в конструкторе.

Кроме того, не весь сетевой код в любом случае будет устаревшим (например, такие параметры, как продолжительность краудсейла, номера валидаторов и т. д.).

Я думаю, что способ обработки ключей будет заключаться в немедленной передаче контроля над контрактом на другой адрес после его создания (и до его объявления), чтобы ключ, используемый для майнинга контракта, ни в коем случае не находился на критическом пути безопасности.
Я думаю, что жесткое кодирование адресов, которые я связал, уместно. Проблема в том, что это код API, который вы хотите, чтобы другие люди могли использовать. Вы не хотите заставлять их управлять вашим адресом через их конструктор — вы просто хотите, чтобы они могли добавлять using YourAPIи начинать вызывать функции из него.