Pasé un tiempo leyendo la guía de actualización del Protocolo Newton y no dejaba de volver 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ó el diseño del almacenamiento. La actualización del proxy tiene éxito, las pruebas se ven bien y luego, semanas después, alguien descubre que una variable se ha sobrescrito porque cambió el orden del almacenamiento. Es un desastre. El contrato no necesariamente falla de inmediato. A veces simplemente empieza a comportarse de forma diferente, lo cual es mucho más difícil de diagnosticar
El Protocolo Newton evita esa trampa tratando la distribución del almacenamiento como algo que debe preservarse en lugar de reorganizarse. Me gusta ese enfoque porque respeta lo frágiles que pueden ser los proxies actualizables
Otro detalle que destacó fue la bandera newtonPolicyClientInitialized. Su propósito es simple: la inicialización posterior a la actualización solo puede ocurrir una vez. El Protocolo Newton también recomienda probar las actualizaciones en una bifurcación (fork) y usar un timelock o un multisig al ejecutar la transacción de inicialización. Eso no me pareció un consejo de rutina. 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 ese paso se complete, la lógica de autorización puede ya existir dentro del contrato, pero el cliente de políticas aún no está conectado al TaskManager correcto ni está asignado al propietario pretendido 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
Impide que alguien ejecute la inicialización otra vez, pero no protege contra equivocarse en 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 aún puede actualizar los ajustes de políticas, cambiar la dirección del contrato de políticas y transferir la propiedad más adelante. En realidad, prefiero eso a fingir que los sistemas nunca necesitan evolucionar. Cambios de infraestructura. Cambios de gobernanza. Los requisitos cambian. El desafío es asegurarse de que esos permisos sigan estando bien controlados con el tiempo
La compatibilidad del almacenamiento crea una categoría de riesgo completamente distinta. Una cosa que aprecio 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 decisión de diseño práctica. Pero la actualización del proxy aún tiene que preservar la compatibilidad del almacenamiento perfectamente. Inserta una variable en la posición equivocada y la capa de autorización puede parecer completamente sana mientras que, debajo, el estado de la aplicación no relacionada se corrompe silenciosamente
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 anterior que realiza la misma acción. Cada ruta que debería imponer la autorización aún tiene que llamar a validateAttestation o validateAttestationDirect antes de que se ejecute la lógica de negocio protegida. Si se te escapa una ruta de ejecución, creas garantías de seguridad inconsistentes sin darte cuenta
Probablemente eso fue lo más interesante que encontré sobre el Protocolo Newton
La arquitectura separa NewtonPolicyClient de la lógica de negocio de la aplicación en lugar de obligar 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. No dejo de preguntarme 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 del almacenamiento y la llamada de inicialización inicialísima se convierten en los puntos donde se concentra casi todo el 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. Usualmente hace que sea más fácil identificarlas
#NEW $NEWT @NewtonProtocol #Newt
Cada actualización cambia el código, pero no todas las actualizaciones fortalecen la seguridad. Para mí, el Protocolo Newton demuestra que los detalles más pequeños de la implementación suelen tener el mayor impacto en construir contratos inteligentes resilientes
#GillibrandCallsForDigitalAssetEthicsBan #NHHB639ProtectsDigitalAssetSelfCustody #BitcoinReboundsAbove$61K