Uso de ENS para actualización de contrato

Situación:

supongamos que tenemos

  • un contrato de almacenamiento de datos
  • bibliotecas que importan el contrato de almacenamiento de datos
  • un contrato de lógica empresarial que implementa las bibliotecas

Pregunta:

  • ¿Podemos usar ENS, o más específicamente su enfoque con registro, propietario y resolución, como "herramienta de actualización", publicando un "nombre" para el contrato y permitiendo que la resolución apunte al contrato de lógica comercial actualmente válido?
Las preguntas múltiples no son bienvenidas como se define en el centro de ayuda, también parece una pregunta más abierta o conversacional. Consulte ¿Cómo hago una buena pregunta?
Punto tomado, editado. Preguntaré a los demás en nuevas publicaciones. Disculpas.
¿Qué significa ENS?

Respuestas (2)

Esta es una pregunta bastante general para este sitio, por lo que podría ser rechazada.

Está claro que ha hecho algunos deberes y está considerando cómo encajarían todas las partes de un sistema actualizable de contratos.

Sí.

Es un solucionador de nombres que podría usarse para resolver una dirección de contrato. Eso brinda a los desarrolladores la opción de designar nuevos contratos orientados al usuario para asumir el control de manera efectiva. Se abstendrían de codificar la dirección del contrato y usarían un nombre lógico en su lugar, como DNS. Luego, usarían el Servicio de nombres de Ethereum para resolver las direcciones de contrato "en vivo".

http://ens.readthedocs.io/en/latest/introduction.html

¿Conoces un código de ejemplo que implemente esto?
No. Mi impresión es que es tan nuevo que las mejores discusiones son sobre los méritos de las mejoras propuestas, etc. En la práctica, podría ser mejor implementar su propio contrato que simplemente devuelva una dirección de una manera que entienda claramente; para lograr un resultado similar. Este documento hace un trabajo razonable al explicar la visión de la solución a escala global: medium.com/@_maurelian/…

Sí, un dominio ENS se puede actualizar para apuntar a una nueva dirección si es necesario implementar un nuevo contrato para actualizar la lógica comercial o las correcciones de código. Sin embargo, el almacenamiento de datos del contrato anterior permanecerá con el contrato anterior.

Para prepararse para esta posibilidad, sería ideal codificar los contratos originales para que tuvieran algún tipo de funcionalidad de "congelación", donde el contrato se puede poner en un estado bloqueado y de solo lectura. Luego, cualquier contrato nuevo podría apuntar al contrato anterior (un "principal") y podría incluir una lógica para leer el estado anterior/existente del contrato anterior (usando sus métodos de acceso público), como un medio para arrancar los datos del nuevo contrato. contrato.

El MiniMeToken toma esta idea (aunque sin congelar el contrato original), al tener la lógica de que si una transacción de consulta está buscando datos más atrás que el historial del contrato actual, sabe ir al contrato principal para buscar ese historial. .