Ayer por la noche revisé de arriba a abajo la página de direcciones del contrato oficial. Detrás de cada contrato venía su número de versión; la planificación para la red de prueba Sepolia y la red principal estaba separada en 2 líneas. La página era corta, pero el contenido no era poco. La propia dirección también es una prueba: los activos de prueba y los activos reales, desde la entrada, se separan.
Tres componentes —Vault Registry, ProtocolParams y adaptadores—, cada uno colgado de tres grupos de identificadores: la versión de Vault Core, la versión de los parámetros fuera de cadena y la versión del conjunto de participantes. Al principio no presté atención a esos números; pensé que los números de versión eran cosa de los desarrolladores. @BabylonLabs_io
Luego leí las descripciones de las dos configuraciones una frente a la otra y entendí qué es lo que realmente bloquean: durante el registro de la bóveda, se sigue una regla de vinculación por versión. Una bóveda, desde el momento de su creación, queda atada a esa tanda de parámetros; las actualizaciones posteriores no pueden cambiarla silenciosamente. Después del número de versión, normalmente también vienen la fecha y el registro de despliegue. Antes y después de una actualización se pueden comparar las diferencias una por una. Los parámetros de despliegue de las 2 configuraciones —red de prueba y red principal— tienen valores propios. Esa es la razón por la que el campo de versión debe registrarse por separado. La fijación de versiones trae un problema práctico: el proceso que la red de prueba verificó, al cambiar a una dirección de la red principal no se copia tal cual; hay que recorrer de nuevo el despliegue y la verificación. Que el sitio oficial liste por separado las dos configuraciones es, en sí mismo, una advertencia: en el entorno de activos, cada despliegue tiene su propio límite de confianza independiente. Lo que se valida con los contratos en la red de prueba solo puede probar lo que ocurre en la red de prueba. $BABY
Antes yo creía que si la red de prueba ya corría, entonces bastaba con pasar directamente a la red principal. Leyéndolo con calma, vi claro que el valor de las etiquetas de entorno y los números de versión en la página de direcciones no es menor que el de los documentos funcionales. En realidad, la conclusión es: para leer los materiales de TBV, primero confirma qué entorno está describiendo; luego mira el número de versión; y finalmente recién entonces revisa la descripción de la función. Entre las direcciones de la red de prueba y la de la red principal —en el caso que figura ahí— lo que hay de por medio es todo el ciclo de despliegue y verificación, no es algo de un clic. En el ecosistema, el aislamiento entre entornos es una decisión de diseño, no una omisión.
Volviendo a esa página de direcciones de anoche: dos líneas de direcciones son dos mundos. Las etiquetas de entorno y los números de versión, más que la descripción de funciones, merecen ser lo primero que se lea. #baby
Tres componentes —Vault Registry, ProtocolParams y adaptadores—, cada uno colgado de tres grupos de identificadores: la versión de Vault Core, la versión de los parámetros fuera de cadena y la versión del conjunto de participantes. Al principio no presté atención a esos números; pensé que los números de versión eran cosa de los desarrolladores. @BabylonLabs_io
Luego leí las descripciones de las dos configuraciones una frente a la otra y entendí qué es lo que realmente bloquean: durante el registro de la bóveda, se sigue una regla de vinculación por versión. Una bóveda, desde el momento de su creación, queda atada a esa tanda de parámetros; las actualizaciones posteriores no pueden cambiarla silenciosamente. Después del número de versión, normalmente también vienen la fecha y el registro de despliegue. Antes y después de una actualización se pueden comparar las diferencias una por una. Los parámetros de despliegue de las 2 configuraciones —red de prueba y red principal— tienen valores propios. Esa es la razón por la que el campo de versión debe registrarse por separado. La fijación de versiones trae un problema práctico: el proceso que la red de prueba verificó, al cambiar a una dirección de la red principal no se copia tal cual; hay que recorrer de nuevo el despliegue y la verificación. Que el sitio oficial liste por separado las dos configuraciones es, en sí mismo, una advertencia: en el entorno de activos, cada despliegue tiene su propio límite de confianza independiente. Lo que se valida con los contratos en la red de prueba solo puede probar lo que ocurre en la red de prueba. $BABY
Antes yo creía que si la red de prueba ya corría, entonces bastaba con pasar directamente a la red principal. Leyéndolo con calma, vi claro que el valor de las etiquetas de entorno y los números de versión en la página de direcciones no es menor que el de los documentos funcionales. En realidad, la conclusión es: para leer los materiales de TBV, primero confirma qué entorno está describiendo; luego mira el número de versión; y finalmente recién entonces revisa la descripción de la función. Entre las direcciones de la red de prueba y la de la red principal —en el caso que figura ahí— lo que hay de por medio es todo el ciclo de despliegue y verificación, no es algo de un clic. En el ecosistema, el aislamiento entre entornos es una decisión de diseño, no una omisión.
Volviendo a esa página de direcciones de anoche: dos líneas de direcciones son dos mundos. Las etiquetas de entorno y los números de versión, más que la descripción de funciones, merecen ser lo primero que se lea. #baby