Ripple Lanza XRPL 3.0.0 Con Un Gran Avance en la Contabilidad de Escrow

Ripple ha lanzado la versión 3.0.0 de XRP Ledger e instó a los validadores y operadores de nodos a actualizar rápidamente para evitar interrupciones. No es solo una actualización. Esto se debe a que corrige un problema tecnológico fundamental que se relaciona con el depósito en garantía de tokens.

Esta es una de las funciones clave utilizadas para la liquidación, así como para las transacciones programadas en XRPL. Los involucrados en el desarrollo de aplicaciones empresariales han considerado el depósito en garantía como uno de los pilares vitales de la confianza.

Leer también: El segundo trimestre de XRPL registra un récord del 154% en la adopción de RLUSD en medio del aumento de la capitalización de mercado de XRP

Por qué el depósito en garantía de tokens es importante para XRPL

Sin embargo, el depósito en garantía siempre ha sido una parte integral de los servicios de liquidación de XRPL. Durante mucho tiempo, ha soportado exclusivamente el uso de XRP. Pero esto significaba que si una empresa emitiera sus tokens en XRPL, le resultaría difícil aprovechar las funciones avanzadas.

La propuesta llamada XLS-85 Token Escrow introdujo el servicio de depósito en garantía para los activos emitidos, como IOUs y Tokens Multiusos.

Los Tokens Multiusos son particularmente relevantes en la tokenización. Son una combinación de tokens fungibles y no fungibles y también contienen una gran cantidad de metadatos.

Los desarrolladores de XRPL citan los Tokens Multiusos como una solución para un entorno de alto cumplimiento porque pueden incluir reglas y ciclos de vida sin utilizar smart contracts externos.

El error contable que generó preocupaciones

Los evaluadores internos del diseño original de Token Escrow notaron el problema relacionado con los MPTs, que contienen comisiones por transacción. Este problema surgió después de la finalización del proceso de depósito en garantía y la liberación de los tokens. 

Cuando se desbloquearon 100 tokens, con la comisión por transacción de 1 token, el destinatario recibió efectivamente 99 tokens.

El problema residía en la contabilidad de los emisores. El Ledger disminuyó el LockedAmount del emisor solo en 99 en lugar de los 100 completos depositados originalmente en garantía. Por lo tanto, un token permaneció en estado bloqueado. Eventualmente, este problema menor puede acumularse y conducir a discrepancias en los montos de suministro en la red.

Los expertos que siguen la infraestructura de XRPL han destacado constantemente los peligros de las más mínimas discrepancias contables en el contexto de las redes de tokens y cómo pueden socavar la confianza en dichas redes.

Cómo TokenEscrowV1 soluciona el problema

Este problema se ha resuelto en la enmienda TokenEscrowV1, en la cual la lógica bruta de depósito en garantía se ha aislado de la entrega neta. Una vez que se haya completado el depósito en garantía, LockedAmount disminuirá en su valor total previamente bloqueado.

Las comisiones por transacción se procesarán de forma independiente para que solo el valor neto impacte el suministro. No quedarán tokens bloqueados y los valores de suministro total se mantendrán precisos.

Leer también: La billetera XRPL de próxima generación de Anodos simplifica la incorporación y recompensa a los usuarios