Pasé un tiempo leyendo la guía de actualización del protocolo Newton y una y otra vez volví a un detalle de implementación: las nuevas variables de almacenamiento siempre se agregan al diseño de almacenamiento existente en lugar de insertarse en él.
Eso suena casi trivial
No creo que lo sea
He visto contratos actualizables romperse porque alguien subestimó la disposición del almacenamiento. La actualización del proxy supera las pruebas, todo parece estar bien y luego, semanas después, alguien descubre que una variable ha sido sobrescrita porque cambió el orden del almacenamiento. Es un desastre. El contrato no necesariamente falla de inmediato. A veces simplemente empieza a comportarse de manera diferente, lo cual es muchísimo más difícil de diagnosticar.
El Protocolo Newton evita esa trampa tratando el diseño del almacenamiento como algo que debe preservarse en lugar de reordenarse. Me gusta ese enfoque porque respeta lo frágiles que pueden ser los proxies actualizables
Otro detalle que se destacó fue la bandera newtonPolicyClientInitialized. Su propósito es simple: la inicialización post-actualización solo puede ocurrir una vez. El Protocolo Newton también recomienda probar las actualizaciones en un fork y usar un timelock o un multisig al ejecutar la transacción de inicialización. Eso no me pareció un consejo de plantilla. Me pareció un reconocimiento de que la actualización no está terminada cuando se despliega la nueva implementación
La inicialización forma parte de la actualización
Hasta que se complete ese paso, la lógica de autorización puede ya existir dentro del contrato, pero el cliente de políticas todavía no está conectado al TaskManager correcto ni asignado al propietario intended del cliente de políticas. Si cualquiera de esos valores es incorrecto, la capa de autorización puede fallar aunque el despliegue en sí haya parecido exitoso
Por eso creo que la bandera de inicialización de una sola vez es importante
Evita que alguien vuelva a ejecutar la inicialización, pero no protege contra equivocarse con la primera ejecución. Si la configuración inicial contiene errores, bloquearla detrás de una bandera de una sola vez no los arregla mágicamente. Solo convierte la primera ejecución en uno de los momentos más sensibles de todo el despliegue
También noté que el Protocolo Newton no congela permanentemente cada configuración después de la inicialización. El propietario del cliente de políticas todavía puede actualizar los ajustes de la política, cambiar la dirección del contrato de políticas y transferir la propiedad más tarde. En realidad lo prefiero a fingir que los sistemas nunca necesitan evolucionar. Cambios en la infraestructura. Cambios de gobernanza. Cambios de requisitos. El desafío es asegurarse de que esos permisos sigan bien controlados con el tiempo. La compatibilidad del almacenamiento crea una categoría de riesgo completamente distinta
Una cosa que agradezco del Protocolo Newton es que permite a los equipos introducir la aplicación de políticas sin reconstruir su aplicación desde cero. Esa es una elección de diseño práctica. Pero la actualización del proxy todavía tiene que preservar la compatibilidad del almacenamiento a la perfección. Inserta una variable en la posición equivocada y la capa de autorización puede verse completamente saludable mientras el estado de la aplicación no relacionado se corrompe silenciosamente por debajo
He visto suficientes sistemas actualizables como para saber que esa no es una preocupación hipotética
Otro detalle que no creo que deba pasarse por alto es el flujo de ejecución. Agregar una nueva función protegida por Newton no asegura automáticamente una función más antigua que realiza la misma acción. Cada ruta que deba aplicar autorización todavía tiene que llamar a validateAttestation o validateAttestationDirect antes de que se ejecute la lógica de negocio protegida. Si se omite una ruta de ejecución, se crean garantías de seguridad inconsistentes sin darse cuenta
Probablemente eso fue lo más interesante que encontré sobre el Protocolo Newton
La arquitectura separa NewtonPolicyClient
en lugar de forzar a los desarrolladores a rediseñarlo todo alrededor de un nuevo framework. En general, prefiero ese tipo de enfoque modular porque los sistemas grandes rara vez se reescriben desde cero. Evolucionan una actualización a la vez
Al mismo tiempo. Me sigo preguntando si el riesgo realmente desaparece
O si simplemente se mueve
El Protocolo Newton hace que la autorización sea más fácil de integrar en contratos actualizables existentes. Creo que eso es valioso. Pero también significa que la actualización del proxy, la migración de almacenamiento y la primera llamada de inicialización se convierten en los puntos donde se concentra gran parte del riesgo operativo
No lo veo como una debilidad del diseño
Lo veo como un recordatorio de que una buena arquitectura no elimina decisiones difíciles. Normalmente solo las hace más fáciles de identificar
Cada actualización cambia el código, pero no todas las actualizaciones fortalecen la seguridad. Para mí, el Protocolo Newton muestra que los detalles de implementación más pequeños a menudo tienen el mayor impacto al construir contratos inteligentes resilientes