La página de enmiendas conocidas de XRPL lista fixCleanup3_1__3 para 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 Permiso, Bóvedas y el Protocolo de Préstamos, y el blog de XRPL estableció el voto predeterminado como Sí debido a la importancia de esas correcciones.
El proceso de enmienda requiere más del 80% de apoyo de validadores confiables durante dos semanas antes de que las nuevas reglas se vuelvan permanentes.
Lo que hace que el episodio valga la pena examinar más allá de la fecha límite es lo que el cocreador de XRPL David Schwartz dijo sobre lo que realmente requeriría una bifurcación real, porque su respuesta revela cómo funciona la legitimidad del protocolo en cualquier cadena de bloques.
El punto central de Schwartz es que el conteo bruto de nodos es un mal sustituto para el poder de consenso. Un sistema donde los nodos votan en proporción a su número crea una superficie de ataque donde cualquiera puede iniciar miles de máquinas a bajo costo.
En el modelo XRPL, cada operador de servidor mantiene un conjunto curado de validadores en los que confía el servidor para no coludirse, la Lista de Nodos Únicos, y la UNL determina qué votos de validación el servidor cuenta durante el consenso.
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, generando un sistema en el que la alineación de UNL y la adopción económica determinan qué libro mayor sobrevive a una división.
Por qué una bifurcación real requiere una campaña de coordinación completa
Para la votación de XRPL el 27 de mayo, los servidores que se vuelven bloqueados por enmienda pierden la capacidad de determinar la validez del libro mayor, enviar o procesar transacciones, participar en el consenso o votar sobre enmiendas futuras.
Esto hace que la fecha límite sea operativamente importante para cualquier exchange, monedero, Explorador u operador de infraestructura que aún ejecute software anterior a la versión 3.1.3, ya que esos servidores dejan de ser participantes en el libro mayor canónico hasta que el operador actualice.
La infraestructura bloqueada por enmienda pierde el acceso a la cadena actualizada y carece de la infraestructura de coordinación para anclar un rival funcional.
Para producir una bifurcación creíble, un grupo disidente necesitaría validadores dispuestos a seguir generando libros contables bajo las reglas antiguas, y sin validadores, no hay flujo de libros contables al que seguir.
Luego necesitarían una Lista de Nodos Únicos competidora que los servidores puedan configurar o que el software pueda tener como predeterminada, porque sin una lista de validadores de confianza, 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 que tenga valores predeterminados que apunten a la UNL rival, y necesitarían soporte de infraestructura de monederos, exchanges, Exploradores y aplicaciones suficiente para hacer accesible y negociable el libro de contabilidad de las reglas antiguas.
La documentación de XRPL cita investigaciones que muestran que en el peor de los casos, UNLs competidores pueden necesitar un 90% de superposición para evitar una bifurcación, lo que significa que cualquier UNL rival necesitaría compartir casi todo el conjunto de validadores confiables con el canonical para mantener la coherencia interna.
Una bifurcación que se forma alrededor de un conjunto de validadores radicalmente diferente corre el riesgo de producir un libro mayor que no puede sostener su propio consenso, por no decir 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 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, las exchange, monederos u operadores de infraestructura que se retrasen respecto a la activación del 27 de mayo se vuelven bloqueados por enmienda y dejan de funcionar como participantes del libro mayor.
Los usuarios que transitan por esos proveedores experimentan interrupciones en el servicio, como transacciones que no se pueden enviar, exploradores que no pueden confirmar la validez del libro mayor y aplicaciones que no pueden procesar pagos.
Ese costo operativo recae en los operadores que pospusieron la actualización, y vale la pena rastrearlo, especialmente para cualquier exchange o custodio importante que aún esté ejecutando nodos pre-3.1.3 en la activación.
Un retraso sostenido en la infraestructura en suficientes proveedores crearía fricción real para los usuarios, incluso mientras el libro contable canónico continúa bajo las nuevas reglas.
En el escenario alcista, fixCleanup3_1_3 se activa según el cronograma con la supermayoría de validadores intacta, los operadores de infraestructura actualizan sin incidentes mayores y el episodio se convierte en una activación de enmienda rutinaria.
Las correcciones a los NFT, Dominios con Permiso, Cofres y el Protocolo de Préstamos entran en vigor, y la red avanza. El debate de gobernanza que surge con la actualización sobrevive cualquier resultado, porque la explicación de Schwartz sobre lo que requeriría un verdadero split se aplica a cualquier enmienda futura.
Mantener las reglas antiguas requiere un grupo disidente que ejecute software antiguo, reclute validadores alrededor de una UNL competidora y convenza a monederos, exchanges y market makers de reconocer su libro mayor como el libro mayor XRP canónico, frente a una configuración predeterminada que dirige a todos los demás hacia la cadena actualizada.
Cada cadena de bloques 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 archivado de estado en Stellar Core, que fue un evento de mantenimiento que requería la misma clase de adopción coordinada por parte de los validadores.
La capa de legitimidad equivalente del bitcoin pasa por los mineros, los nodos económicos, las implementaciones de clientes y las listas en exchange. La del ethereum pasa por los validadores, la infraestructura de staking, la diversidad de clientes, los desarrolladores principales y la adopción en la capa de aplicaciones.
Lo que XRPL hace explícito a través de UNLs, otras redes lo incorporan en la distribución del poder de minería, la economía de staking o el consenso social en torno al cual los desarrolladores de software cliente confían.
Los mecanismos difieren entre bitcoin, ethereum y XRPL, mientras que la dependencia de decisiones humanas coordinadas para hacer permanentes los cambios en las reglas recorre los tres.
La activación del 27 de mayo ilustra cómo la capa de gobernanza de XRPL convierte el acuerdo de los validadores en permanencia del libro mayor, con la configuración de UNL que determina qué acuerdos cuentan.
Un operador que no está de acuerdo con fixCleanup3_1_3 tiene la libertad técnica para ejecutar software antiguo y configurar una UNL rival.
Si alguna exchange lista el token resultante, si algún monedero lo admite o si algún market maker proporciona liquidez es una pregunta que el protocolo no puede responder por ellos.
Esa desconexión de coordinación es la razón por la que las actualizaciones del protocolo en redes ampliamente adoptadas rara vez producen bifurcaciones duraderas: la economía de seguir la cadena canónica casi siempre supera a la economía de construir una cadena paralela desde cero, y la cadena canónica es aquella que el mercado decide como real.
La publicación La actualización del 27 de mayo de XRPL muestra cómo los validadores y los mercados deciden una división de la cadena de bloques apareció por primera vez en CryptoSlate.