La página de enmiendas conocidas de XRPL enumera fixCleanup3_1__3 para su activación el 27 de mayo, y por diseño, el evento es una actualización de mantenimiento.
La versión 3.1.3 de rippled incluye correcciones para NFTs, Dominios con permisos, Vaults y el Protocolo de Préstamos, y el blog de XRPL estableció la votación predeterminada en Sí debido a la importancia de esas correcciones.
El proceso de enmienda requiere más del 80% de apoyo de validadores confiables sostenido durante dos semanas antes de que las nuevas reglas se vuelvan permanentes.
Lo que hace que este episodio merezca ser examinado más allá de la fecha límite es lo que dijo el co-creador de XRPL, David Schwartz, sobre lo que realmente requeriría un fork real, porque su respuesta revela cómo funciona la legitimidad del protocolo en cualquier blockchain.
El punto central de Schwartz es que el número bruto de nodos es un mal indicador del poder de consenso. Un sistema donde los nodos votan en proporción a su número crea una superficie de ataque donde cualquiera puede encender miles de máquinas a bajo costo.
En el modelo de XRPL, cada operador de servidor mantiene un conjunto seleccionado de validadores en los que el servidor confía para que no colaboren, la Lista Única de Nodos, y la UNL determina qué votos de validación cuenta el servidor durante el consenso.
El proceso de enmienda de XRPL requiere el apoyo de más del 80% de validadores confiables sostenido durante dos semanas antes de que las nuevas reglas se vuelvan permanentes, bloqueando a los servidores no actualizados.
Un servidor recibe mensajes de validación de muchos nodos en toda la red, y los validadores en su UNL determinan cuáles de esos mensajes moldean la visión del servidor sobre el libro mayor.
Schwartz explicó que la legitimidad del consenso en XRPL fluye a través de listas de confianza y coordinación de validadores, produciendo un sistema en el que la alineación de la UNL y la adopción económica determinan qué libro mayor sobrevive a una división.
Por qué un fork real requiere una campaña completa de coordinación
Para la votación de XRPL del 27 de mayo, los servidores que quedan bloqueados por enmienda pierden la capacidad de determinar la validez del libro mayor, enviar o procesar transacciones, participar en el consenso o votar sobre futuras enmiendas.
Eso hace que la fecha límite sea operativamente importante para cualquier exchange, billetera, explorador o operador de infraestructura que aún esté ejecutando software anterior a la versión 3.1.3, ya que esos servidores dejarán de ser participantes en el libro mayor canónico hasta que el operador se actualice.
La infraestructura bloqueada por enmienda pierde acceso a la cadena actualizada y carece de la infraestructura de coordinación para anclar una rival funcional.
Para producir un fork creíble, un grupo disidente necesitaría validadores dispuestos a seguir produciendo libros mayores bajo las reglas antiguas, y sin validadores, no hay un flujo de libros mayores que seguir.
Luego necesitarían una Lista Única de Nodos rival que los servidores puedan configurar o que el software pueda usar por defecto, porque sin una lista de validadores confiables, los nodos no tienen ningún mecanismo para coordinarse en torno a las reglas antiguas.
Además, necesitarían una distribución de código que preserve las reglas antiguas y venga con configuraciones predeterminadas que apunten a la UNL rival, y necesitarían soporte de infraestructura de billeteras, exchanges, exploradores y aplicaciones suficiente para hacer accesible y negociable el libro mayor de reglas antiguas.
Un fork creíble de XRPL requiere cinco niveles más allá de los nodos no actualizados: validadores de reglas antiguas, una UNL rival, código de reglas antiguas, soporte de infraestructura y reconocimiento del mercado.
La documentación de XRPL cita investigaciones que muestran que las UNL competidoras podrían necesitar un 90% de superposición en el peor de los casos para evitar un fork, lo que significa que cualquier UNL rival tendría que compartir casi todo el conjunto de validadores confiables con la canónica para mantener la coherencia interna.
Un fork que se forme alrededor de un conjunto radicalmente diferente de validadores corre el riesgo de producir un libro mayor que no pueda sostener su propio consenso, y mucho menos atraer la adopción del mercado.
Lo que realmente rastrea el proceso de enmienda es el apoyo de los validadores, y el umbral del 80% durante dos semanas asegura que las entidades en las que la red confía hayan alcanzado un acuerdo duradero antes de que las nuevas reglas se vuelvan permanentes.
Una gran parte de los nodos no actualizados que no son validadores puede reflejar un retraso en la infraestructura sin implicar nada sobre la trayectoria del libro mayor canónico.
La distancia entre el retraso en la infraestructura y una cadena rival
En el escenario bajista, los exchanges, billeteras o operadores de infraestructura que se queden atrás respecto a la activación del 27 de mayo quedan bloqueados por enmienda y dejan de funcionar como participantes en el libro mayor.
Los usuarios que pasan por esos proveedores encuentran interrupciones en el servicio, como transacciones que no pueden enviarse, exploradores que no pueden confirmar la validez del libro mayor y aplicaciones que no pueden procesar pagos.
Este costo operativo recae sobre los operadores que priorizaron poco la actualización, y vale la pena monitorearlo, especialmente para cualquier exchange o custodio importante que todavía esté ejecutando nodos anteriores a la versión 3.1.3 en la activación.
Un retraso sostenido en la infraestructura entre suficientes proveedores crearía una fricción real para los usuarios, incluso cuando el libro mayor canónico siga bajo las nuevas reglas.
En el escenario alcista, fixCleanup3_1_3 se activa según lo programado con la supermayoría de validadores intacta, los operadores de infraestructura se actualizan sin incidentes importantes y el episodio se convierte en una activación rutinaria de enmienda.
Las correcciones para NFTs, Dominios con permisos, Vaults y el Protocolo de Préstamos entran en vigor, y la red sigue adelante. El debate sobre gobernanza que surge con la actualización sobrevive a ambos resultados, porque la explicación de Schwartz sobre lo que requeriría una división real se aplica a cualquier enmienda futura.
Mantener las reglas antiguas requiere un grupo disidente que ejecute software antiguo, reclute validadores alrededor de una UNL rival y convenza a billeteras, exchanges y creadores de mercado de reconocer su libro mayor como el Libro Mayor canónico de XRP, frente a una configuración predeterminada que apunta a todos los demás hacia la cadena actualizada.
Cada blockchain tiene una capa de gobernanza
Schwartz hizo una comparación con Stellar, cuya actualización del Protocolo 24 es en sí misma una corrección de estabilidad para un error de archivo de estado en Stellar Core, que fue un evento de mantenimiento que requirió el mismo tipo de adopción coordinada de validadores.
La capa de legitimidad equivalente de Bitcoin pasa por mineros, nodos económicos, implementaciones de clientes y listados de exchanges. La de Ethereum pasa por validadores, infraestructura de staking, diversidad de clientes, desarrolladores principales y adopción en la capa de aplicaciones.
Lo que XRPL hace explícito mediante las UNL, otras redes lo incorporan en la distribución del poder minero, la economía de staking o el consenso social en torno al cual los desarrolladores de software de clientes confían.
Los mecanismos difieren entre Bitcoin, Ethereum y XRPL, mientras que la dependencia de decisiones humanas coordinadas para hacer permanentes los cambios de reglas atraviesa a los tres.
En XRPL, Bitcoin, Ethereum y Stellar, los cambios de reglas se vuelven permanentes mediante decisiones coordinadas de validadores, mineros, desarrolladores y mercados, en lugar de contar solo con el número bruto de nodos.
La activación del 27 de mayo ilustra cómo la capa de gobernanza de XRPL convierte el acuerdo de validadores en permanencia del libro mayor, con la configuración de la UNL determinando qué acuerdos cuentan.
Un operador que no esté de acuerdo con fixCleanup3_1_3 tiene la libertad técnica de ejecutar software antiguo y configurar una UNL rival.
Si algún exchange cotiza el token resultante, si alguna billetera lo admite o si algún creador de mercado proporciona liquidez es una pregunta que el protocolo no puede responder por ellos.
Esa desconexión en la coordinación es la razón por la que las actualizaciones de protocolo en redes bien adoptadas rara vez producen forks duraderos: la economía de seguir la cadena canónica casi siempre supera la economía de construir una cadena paralela desde cero, y la cadena canónica es aquella que el mercado decida que es real.
La publicación La actualización de XRPL del 27 de mayo muestra cómo los validadores y los mercados deciden una división de blockchain apareció primero en CryptoSlate.