¿Es posible y sensato implementar un contrato en la misma dirección en Mainnet y Ropsten?

Tradicionalmente, cuando las personas han implementado contratos para uso público, han tendido a publicar direcciones de contrato separadas para Testnet y Mainnet. A menudo, esto requiere que incluyan un código para verificar en qué red está el contrato, como vemos en este ejemplo .

Esto parece haber sido necesario anteriormente porque, en ausencia de protección de reproducción, Morden usó una cuenta StartNonce muy alta , por lo que no era práctico crear la misma dirección en Mainnet. (Consulte ¿Es posible dar un contrato a la misma dirección de Morden? )

Ahora que la protección de reproducción EIP 155 está activa y Ropsten está usando una cuentaStartNonce de 0 como Mainnet, ¿quedan buenas razones para seguir usando direcciones separadas para mainnet y testnet, o deberíamos deshacernos de este código y usar una sola dirección? ¿para ambos?

sigue siendo una red de seguridad válida que tiene 2 direcciones. Pero no habrá una respuesta completamente objetiva a esta pregunta. Cuestion de gusto.
Quería crear exactamente la misma pregunta, siendo mi motivación: "publicar el contrato ICO en la red de prueba y permitir que personas con menos experiencia prueben MEW, Metamask y otras herramientas". y la explicación de por qué "Es una idea terriblemente mala: enviar ETH real a la dirección de la red de prueba terminará en la nada. Y no importa cuántas veces se comunique, seguramente alguien lo hará. ASÍ QUE NO IR "
@MichelStefanow No entiendo esa respuesta. Las direcciones de Testnet y Mainnet son las mismas. Si implementa en la misma dirección de contrato en ambas redes, un gasto de testnet alcanzará el contrato de testnet y un gasto de mainnet alcanzará el contrato de mainnet. Si tiene direcciones diferentes y envía monedas de la red principal a la dirección destinada a la red de prueba, terminarán en un vacío, aunque podría rescatarlas implementando un contrato posteriormente.
@EdmundEdgar Mi motivación para tener la misma dirección fue un intento previo Mainneta Ropstenla ICO, lo que permitió a las personas probar sus billeteras, contraseñas, todo... Pero debido a que algunas personas cometerán errores y enviarán ETH real a la dirección de la red de prueba, NO SE PUEDE .
you could rescue them by deploying a contract subsequently- No estoy de acuerdo con eso, ¿y si la cuenta nonce es demasiado alta? En una nota separada: lo hice accidentalmente, cuenta nueva, mismo momento, magia: steemit.com/ethereum/@genesisre/…

Respuestas (1)

Un argumento bastante débil en contra de su sugerencia es el siguiente: el implementador tendría que usar la misma clave privada tanto en la prueba como en la red principal. Esto podría considerarse un riesgo de seguridad, ya que las claves privadas en la red de prueba generalmente no tienen que almacenarse y manejarse de manera segura, mientras que en la red principal definitivamente sí lo hacen. Mezclar los dos dominios, por lo tanto, desdibujaría los requisitos de seguridad de cada uno de ellos.

Sin embargo, diría que las ventajas de tener la misma dirección tanto en la prueba como en la red principal tampoco son muy convincentes. En el ejemplo que vinculó, en mi opinión, una mejor solución sería pasar la dirección respectiva en el constructor.

Además, no todo el código específico de la red quedaría obsoleto de todos modos (p. ej., parámetros como la duración de las ventas masivas, los números de validadores, etc.).

Creo que la forma de manejar las claves sería transferir inmediatamente el control del contrato a una dirección diferente después de crearlo (y antes de anunciarlo) para que la clave utilizada para extraer el contrato no estuviera en una ruta de seguridad crítica en ningún caso.
Creo que la codificación de las direcciones que vinculé es apropiada. El problema es que este es un código API que desea que otras personas puedan incorporar. No desea tener que obligarlos a administrar su dirección a través de su constructor; solo desea que puedan agregar using YourAPIy comenzar a llamar funciones desde allí.