Hoy estamos encantados de hacer públicos nuestros planes detallados para el despliegue de la Red de Bengalas. Estos planes se pueden explorar completamente sumergiéndose en nuestros borradores de documentos técnicos que cubren la Red y su token nativo, Spark (aquí) y la integración sin confianza de XRP con Flare (aquí). Los documentos están en forma de borrador y habrá cambios de optimización entre ahora y el día en que la llamarada se active. No debe haber cambios que se desvíen materialmente de la visión general que se proporciona a continuación. En este post queremos destacar lo que consideramos los aspectos más importantes de Flare. Una descripción técnica mínima de cada componente importante se publicará en las próximas semanas, a partir de esta semana con un recorrido por la integración sin confianza de Flare de XRP, FXRP. Abróchate el cinturón!

(A TL; DR está al final de este post.)

¿Qué es Flare y por qué lo estamos construyendo?

Flare existe para resolver dos problemas clave:

En primer lugar, y de importancia inmediata para la construcción de nuestra industria, es que el 75% del valor que existe en la cadena de bloques pública actualmente no se puede usar de manera confiable con contratos inteligentes.

En segundo lugar, y de consecuencia a corto y largo plazo, hay problemas potenciales con la forma en que se está implementando el escalado para las redes de contratos inteligentes en la actualidad. La mayoría de las nuevas redes utilizan Proof of Stake o sus variantes. Estos protocolos derivan la seguridad de la red de su token nativo.

El problema inmediato inherente a la Prueba de participación es que el diseño de consenso aún no permite de forma segura usos alternativos del token nativo. Si un poseedor de tokens puede obtener un rendimiento más alto (y sin posibilidad de recortar) al proporcionar garantías para crear una stablecoin de lo que puede obtener al apostar, entonces, como racionalistas económicos, es probable que lo haga. Esto desvía los tokens de las apuestas y canibaliza la seguridad de la red. (Un documento muy perspicaz sobre este tema está aquí.) Sospechamos que esta es quizás la razón clave por la que, a pesar de tener costos de transacción comparativamente más altos y un rendimiento de transacción mucho menor, Ethereum sigue liderando el camino en DeFi.

Un problema a largo plazo es que a medida que una red de Prueba de Apuesta gana uso y el valor construido encima de ella aumenta, el valor del token de apuesta debe aumentar o la red se volverá insegura. Esto es genial para los inversores en el token, pero malo para las personas que quieren ver que la descentralización se convierta en parte de la forma principal de hacer negocios. ¿Por qué? Porque para que el valor del token que asegura la red aumente, el capital debe desviarse de algún otro uso para comprar el token. Llevado al punto final lógico, si las redes de contratos inteligentes que utilizan prueba de participación se convirtieran en el método omnipresente de hacer negocios, la escala de desviación de capital requerida de otros esfuerzos, solo para asegurar el valor construido en estas redes, haría que el costo del comercio fuera inviablemente alto. Por esta razón, es muy poco probable que suceda. La prueba de participación y las variantes pueden escalar el rendimiento de las transacciones, pero las implementaciones existentes no pueden escalar por valor. En nuestra opinión, la prueba de participación es más una solución provisional que una solución.

¿Cómo resuelve Flare estos problemas?

Flare es en esencia una nueva forma de escalar plataformas de contratos inteligentes que no vincula la seguridad con el valor de su token. Flare todavía requiere un token para el funcionamiento de la red, principalmente para disuadir las transacciones de spam. El símbolo de la llamarada se llama Chispa. Debido a que Spark no tiene implicaciones de seguridad de red, es adecuado para permitir el uso sin confianza de tokens completos sin Turing con contratos inteligentes.

Flare es la primera red completa de Turing del Acuerdo Bizantino Federado (FBA). Los nodos ejecutan el protocolo de consenso de Avalancha con una adaptación clave a la topología de consenso de la FBA. La FBA es única como topología de consenso, ya que logra la seguridad sin depender de incentivos económicos que pueden interferir con casos de uso de alto valor y alto riesgo. Una crítica de la FBA pura es que conduce a estructuras frágiles de nodos constituyentes, permitiendo escenarios de topología donde una falla de un solo nodo puede causar una falla en toda la red. Por esta razón, se prioriza una configuración específica de FBA llamada topología de Lista de Nodos únicos (UNL) que enfatiza la claridad y la facilidad de uso, manteniendo al mismo tiempo la propiedad de membresía abierta de FBA. El porcentaje de superposición de la UNL es un parámetro definido por la gobernanza, con una superposición menor que mejora la propiedad de membresía abierta de la red. La red Flare aprovecha la Máquina Virtual Ethereum (EVM), lo que permite que la red ejecute contratos inteligentes completos de Turing.

En el lanzamiento de la red, construido sobre Flare, hay un protocolo para habilitar de forma segura la emisión, el uso y el canje sin confianza de XRP en Flare. Este protocolo se llama FXRP. XRP de forma segura y sin confianza se convierte en FXRP, en Flare, asegurado por el token nativo de Flare, Spark. XRP ahora existe efectivamente en una red completa de Turing y una vez allí, la interoperabilidad sin confianza con otras redes es factible, tanto a través de protocolos de interoperabilidad como Cosmos y Polkadot o con Ethereum a través de protocolos de puente bien definidos. En breve: Flare se puede utilizar como una plataforma de contrato inteligente para XRP o como una canalización sin confianza para XRP a otras redes.

Además, la metodología general de FXRP es extensible a cualquier token completo que no sea de Turing y la capacidad de decidir qué otros tokens admitir y luego extender los medios para hacerlo está incorporada en los sistemas y el gobierno de la red.

Flare combina el valor de los tokens completos sin Turing con el poder transformador de los contratos inteligentes en una red que puede escalarse en función del valor y el rendimiento de las transacciones.

Descripción general de FXRP

La complejidad de obtener XRP en Flare es que no hay forma de que un contrato inteligente en una cadena de bloques pública controle una dirección en el libro mayor de XRP. La razón de esto es que los contratos inteligentes actualmente no tienen una forma adecuada de almacenar una clave secreta de una manera que sea genuinamente secreta. Para obtener XRP en Flare utilizando solo código, se requeriría que algún grupo de participantes se uniera con una dirección de firma múltiple que controlan colectivamente, por lo que si las partes k de n firman una transacción, la transacción está autorizada. Cualquier usuario de un activo emitido por esta dirección multisig tendría que confiar en esa colección de usuarios y, por lo tanto, el activo no carecería de confianza ni estaría descentralizado.

FXRP permite de forma segura a un titular de XRP (un originador) enviar su XRP a un conjunto de direcciones (llamadas agentes) en el libro mayor de XRP. Los contratos inteligentes FXRP en Flare luego emiten el originador FXRP en Flare que es convertible 1: 1 con XRP y asegurado con Spark. Cuando un titular de FXRP desea canjearlo por XRP ( un redentor), lo envía de vuelta a los contratos inteligentes de FXRP en Flare. Luego, los agentes envían el XRP a la dirección del redentor en el libro mayor de XRP. Si los agentes no completan este canje lo suficientemente rápido, se compensa al redentor el valor de su XRP más una cantidad para compensar los costos de transacción para recomprar el XRP.

Con FXRP, no se necesita ningún intermediario centralizado.

FXRP funciona de la siguiente manera:

Los propietarios del token nativo de Flare, Spark, pueden enviar sus tokens a una colección de contratos inteligentes en Flare que se conocen como el sistema FXRP. Los usuarios que hacen esto están proporcionando garantías al sistema FXRP. Se les llama agentes. Llamemos a uno de los agentes Bob. Habrá muchos agentes en el sistema FXRP.

Digamos que Bob ha insertado 5000 tokens Spark en el sistema FXRP. En este ejemplo, actualmente se pueden comprar 10 tokens Spark por 1 token XRP. El sistema FXRP exige una relación colateral de 2,5, lo que significa que en todo momento un agente debe haber proporcionado al sistema 2,5 veces el valor del FXRP que el sistema les ha asignado en tokens Spark. FXRP se valora aquí como 1: 1 con XRP. Por lo tanto, los 5000 tokens Spark de Bob permiten que el sistema emita 200 FXRP.

Cuando alguien, dice Alice, quiere crear FXRP, envía una transacción al sistema FXRP con una tarifa fija del 0,1% del valor de XRP que desea acuñar en FXRP. Alice se denomina originadora. La transacción también le dice al sistema FXRP a qué dirección enviar el FXRP en la llamarada, una vez que se acuñe, y de qué dirección se originará el XRP en el Libro mayor de XRP. Si hay capacidad disponible en el sistema FXRP, la garantía para asegurar la cantidad de FXRP que se está creando se bloquea durante un cierto período contra la próxima transacción de Alice. De esta manera Alice no tiene que confiar en Bob. A cambio, se genera un conjunto de instrucciones para que Alice le diga a qué dirección (la dirección de Bob) enviar el XRP en el libro mayor de XRP y qué último índice del libro mayor usar. Si no hay capacidad en el sistema para emitir la cantidad deseada de FXRP, a Alice se le reembolsará la tarifa.

Alice luego envía la cantidad correcta de XRP más una tarifa de creación en XRP a la dirección de Bob en el libro mayor de XRP. La tarifa de creación es la gran mayoría del dinero que Bob ganará por bloquear su garantía de Chispa, tenga en cuenta que sus ganancias son predominantemente en XRP. Flare observa esta transacción utilizando un sistema llamado Conector de Estado, definido en la Sección 2 del informe técnico de Flare (y el tema de una futura publicación de blog). El FXRP es acuñado por el sistema y entregado a la dirección designada por Alice en Flare.

El coeficiente de garantía de 2,5 x debe mantenerse en todo momento. Si el precio de XRP aumenta frente a Spark, de modo que el valor de la garantía de Bob cae por debajo de 2.5 veces el FXRP emitido en su contra, Bob tiene un tiempo limitado para agregar más tokens Spark como garantía o comprar y canjear tokens FXRP para volver a alinear su relación de garantía. Por ejemplo, digamos que se emiten 200 tokens FXRP contra los 5000 tokens Spark de Bob y el precio de XRP/Spark aumenta a 12. Bob ahora necesita agregar 1000 Spark al sistema o comprar y canjear 33.34 FXRP para reducir su distribución de FXRP emitido a 166.66.

Si Bob no tiene acceso a tokens Spark adicionales, no es financieramente oneroso para él reducir el saldo de FXRP respaldado por su dirección. La garantía de Bob permitió que el sistema FXRP emitiera 200 tokens FXRP, en el proceso de hacerlo, Bob ha recibido 200 tokens XRP en el libro mayor de XRP. Por lo tanto, si Bob no tiene capital adicional para comprar tokens Spark, puede vender suficiente XRP para FXRP en un intercambio de tal manera que pueda canjear al menos 33.34 FXRP o permanecer en un entorno puramente descentralizado si hay otros agentes en el sistema FXRP con suficiente garantía en exceso, puede acuñar suficiente FXRP e inmediatamente canjearlo. La segunda hipótesis traslada esencialmente la obligación al resto del sistema. Si Bob no hace nada y permanece en incumplimiento de la relación de garantía, la garantía de Bob se subastará automáticamente por la cantidad de FXRP emitida en su contra, que en este caso es de 200. Bob retiene cualquier garantía restante después de esta operación.

Digamos que Bob optó por agregar Chispa adicional como garantía. Ahora, algún tiempo después, Alice, propietaria de todos los 200 FXRP emitidos, quiere canjear la cantidad total al libro mayor de XRP. Alice simplemente realiza una transacción con el sistema FXRP enviando el FXRP al sistema y diciéndole qué dirección quiere acreditar. El sistema luego emite un conjunto de instrucciones a Bob diciéndole cuánto XRP debe enviar y dónde, junto con dos plazos de números de libro mayor de XRP para los cuales se debe completar la transacción. Si Bob completa la transacción antes de la primera fecha límite, su garantía se desbloqueará por completo. Si Bob falla en la primera fecha límite, pero tiene éxito en la segunda, se le cobra una pequeña multa y el resto de su garantía se desbloquea. La multa se quema.

Si Bob no completa la transacción en la segunda fecha límite, se denomina fallo de canje. Luego, Alice es compensada con tokens Spark por el valor de su XRP canjeado más un aumento del 1% para cubrir los costos de transacción de la recompra del XRP, que se extrae de la garantía de Bob. De la garantía restante de Bob, el 50% se quema como penalización y el otro 50% se le devuelve. Alice puede comprar XRP de reemplazo en un intercambio. Alternativamente, suponiendo que haya otros agentes en Flare con FXRP emitido y personas que deseen venderlo, Alice puede comprar más FXRP en Flare y canjearlo contra esos agentes.

Spark y Aplicaciones Dependientes

FXRP es el primer ejemplo de algo que denominamos una Aplicación Dependiente de Spark (SDA). Un SDA se define como una aplicación que utiliza en su construcción una combinación de: Spark para garantías, el Oracle de la serie Temporal Flare y los titulares de tokens Spark para el gobierno. Cada uno de estos elementos es totalmente opcional y una aplicación puede operar en Flare interactuando solo con Spark para el pago de los costos de transacción. Por ejemplo, FXRP utiliza Spark como garantía, el Oracle de la serie Temporal Flare para el precio XRP / Spark y el conjunto de propiedad de tokens Spark para el gobierno sobre ciertos parámetros, como la tarifa de creación de FXRP y la relación de garantía. El modelo SDA pretende proporcionar una plantilla para extender cada uno de los tres componentes a un número arbitrario de aplicaciones. El uso de Spark como garantía en todas las aplicaciones es sencillo, el elemento más importante fue considerar cómo se podría crear una metodología segura de Oracle en varias series temporales.

Oracle de la Serie Temporal Flare

La propiedad del token Spark permite la contribución al Oracle de la Serie Temporal Flare (FTSO). El propósito del FTSO es formar estimaciones precisas de los datos sobre la llamarada desde fuera de la cadena, manteniendo al mismo tiempo la descentralización. El FTSO está estructurado para proporcionar muchas estimaciones de series temporales individuales. El precio XRP / Spark es un ejemplo de una sola serie temporal.

La salida de cada serie temporal del FTSO generalmente tendrá dos grupos de participantes: el primero son los titulares de tokens Spark y el segundo son los titulares del token de aplicación dependiente, que se denomina un activo F. En la aplicación FXRP, el activo F es el token FXRP en sí. Para una aplicación más compleja, como una aplicación de derivados, donde la aplicación requiere varias series temporales, el activo F puede ser algo más similar a un token de gobierno emitido.

Para cada serie temporal, el FTSO pide a cada grupo relevante de participantes que proporcione una estimación. Los titulares de Spark proporcionarán estimaciones para todas las series temporales y los titulares de activos F proporcionarán estimaciones sobre solo las series temporales relacionadas con sus activos F. A continuación, esas estimaciones se procesan como se define en la sección 4 del documento técnico sobre llamaradas y el sistema las produce.

El incentivo para que los titulares de activos F proporcionen datos al sistema es la seguridad de su aplicación. Los titulares de tokens de Spark están incentivados por el potencial de ganar algo llamado oracle reward. Esta es una cantidad de tokens Spark que son acuñados por el sistema. La recompensa de oracle es una tasa anual dividida de manera uniforme en cada período estimado de FTSO. Por ejemplo, si la tasa es del 10%, hay 365 estima en un año y número de partida de la Chispa de fichas de 100, 10 Chispa será creado en 1 año y ~0.03 Chispa acuñadas y recompensados por día. Los contribuyentes de tokens de Spark pueden ganar esta recompensa al aportar datos que se consideren «correctos». La mecánica precisa se expone en el libro blanco. Es importante destacar que todos los titulares de tokens de Spark están implícitamente apostados en el sistema como si no ganaran la recompensa, ya sea por no contribuir o proporcionar estimaciones «incorrectas» que pierden valor para los titulares de tokens que son recompensados. Esta es la versión de Flare de recompensas de bloques.

El FTSO se iniciará para proporcionar los siguientes precios para: XRP / Spark, USD/Spark, BTC/Spark y XLM / Spark. Solo XRP / Spark tendrá un activo F correspondiente al principio. Se pueden proponer y aceptar series temporales adicionales y sus activos F conexos a través del proceso de gobernanza.

Delegación

El FTSO en realidad proporcionará estimaciones cada dos segundos. No todos los titulares de Spark querrán o podrán ejecutar hardware para contribuir al FTSO y, por separado, es posible que no estén interesados en votar por el gobierno de la red. Por lo tanto, los votos para ambas responsabilidades pueden separarse del token en sí y delegarse por separado a otros partidos. La delegación podrá cancelarse en cualquier momento y, cuando se transfiera una ficha de una dirección a otra, la delegación se cancelará automáticamente de modo que los derechos de voto vayan con la ficha. El mecanismo también permite a SDA, como FXRP, delegar los votos Spark de nuevo al propietario final, que luego puede volver a delegar esos votos a entidades que desea votar en su nombre. Por lo tanto, si Bob tiene 5000 tokens Spark en la aplicación FXRP, delegará los votos de esos tokens a una dirección especificada por Bob. Si Bob quiere que un proveedor de datos dedicado contribuya al FTSO en su nombre, Bob puede delegar sus votos para el FTSO en el proveedor de datos. Es importante destacar que esto significa que Bob no tiene que elegir entre ganar Spark al proporcionar una garantía para la aplicación FXRP y potencialmente ganar la recompensa del FTSO, puede hacer ambas cosas. Cualquier SDA que haga que los tokens Spark no estén disponibles para sus propietarios subyacentes, siempre que haya una definición en la aplicación sobre quién es el propietario subyacente, puede implementar el procedimiento de delegación.

Gobernanza& Foundation

Flare se rige por completo por los titulares de tokens de Spark a través de la votación. Los SDA pueden solicitar opcionalmente ser gobernados por titulares de tokens de Spark.

Ciertas decisiones se pueden tomar de manera automatizada en la cadena, como cambiar el costo de transacción, la tasa de recompensa de oracle o, al considerar FXRP como un SDA, cambiar la relación de garantía y la tarifa de creación. Otras decisiones, como agregar una nueva serie temporal al FTSO y vincular su activo F propuesto, cambiar los parámetros de consenso de red o actualizaciones a largo plazo más complejas, requieren un cambio de código. El libro blanco de Flare establece una propuesta, desarrollo y régimen de pruebas para cambios manuales que pueden ser iniciados y votados por los titulares de tokens de Spark. Para ayudar a implementar ese proceso y ejecutar los cambios acordados, habrá una fundación Flare. La fundación será una organización sin ánimo de lucro, que se incorporará en los próximos meses. Será responsable de 5 áreas clave: subvenciones, inversiones, investigación y desarrollo, educación, publicidad y asociaciones.

Es la función de investigación y desarrollo la que permite a la fundación ser una parte integral del proceso de actualización de la red, incluso yendo tan lejos como para analizar, informar y luego construir, probar e implementar cambios de código de red propuestos.

La fundación debe ser altamente transparente y no desperdiciar dinero. Se prepararán y publicarán dos informes anuales sobre sus actividades y gastos. La fundación está destinada solo a tomar la dirección de los titulares de tokens de Spark y no a establecer la agenda. Como tal, no puede: contribuir al FTSO de ninguna manera, desplegar ninguna de sus tenencias de Spark como garantía para ninguna aplicación en la red y no puede usar sus tenencias de Spark para votar en ninguna votación de gobernanza. No puede asignar sus tokens Spark a otros para que lo hagan. Además, en la constitución de la fundación estará escrita la obligación de que si una votación de gobierno acuerda que la fundación ya no sirve para un propósito beneficioso, entonces la fundación debe terminar sus actividades y quemar todas sus tenencias de tokens restantes lo antes posible.

Emisión de Spark

La mejor comunidad para poseer el activo que permite el uso de XRP con contratos inteligentes completos de Turing es la comunidad que lo usará y se beneficiará de él: Los titulares de XRP. La llamarada no está haciendo unO. En cambio, está haciendo lo que llamamos una bifurcación de utilidad. Creemos que es el primero de su tipo.

Una bifurcación tradicionalmente ha buscado tomar la base de usuarios de una red existente y apartarse completamente de esa red, generalmente para tener una relación antagónica con la cadena original. Por el contrario, una horquilla de utilidad está destinada a devolver valor a la cadena original en lugar de alejarse de ella. Llamarada permite XRPL hacer lo que mejor hace, pago rápido, aportando XRPL, inteligente contratos y la viabilidad para crear una trustless canalización a otras blockchains. Creemos que esta es una combinación verdaderamente poderosa y un ejemplo perfecto de utilidad.

Se crearán 100 mil millones de tokens Spark para reflejar la cantidad de XRP que existe. Hay aproximadamente 45 Bn de tokens XRP que no pertenecen a Ripple labs. El objetivo de la distribución es que los titulares de XRP que no sean Ripple puedan reclamar aproximadamente una cantidad de chispa de 1:1 a su holding de XRP. Los titulares de XRP podrán reclamar 45 Bn Spark (eliminando las direcciones conocidas de Ripple labs). 25 Bn Spark irán a Flare Networks Limited, que es la organización con fines de lucro de Flare. 30 mil millones de chispas irán a la fundación Flare.

Como muchos propietarios de XRP en realidad usan intercambios para mantener sus tokens XRP, existe la posibilidad de que un titular de XRP que desee reclamar tokens Spark no pueda hacerlo porque el intercambio reclama el Spark y los retiene en lugar de pasarlos, o alternativamente no los reclama en absoluto. Para permitir que los propietarios de XRP participen en la distribución, ya sea presionando a su exchange para que distribuya los tokens de Spark o para que mueva exchange a uno que lo haga, la instantánea del libro mayor de XRP se tomará en una fecha más cercana al lanzamiento. Una lista de intercambios participantes se publicará en el sitio web de Flare y se actualizará periódicamente. El número del libro mayor de instantáneas se publicará en el sitio web cuando se haya tomado la instantánea.

TL;DR

Flare es la primera red completa de Turing del Acuerdo Bizantino Federado (FBA). Integra la Máquina Virtual Ethereum (EVM) y no obtiene seguridad de un token. Además de esto, se ha creado un protocolo para habilitar de forma segura la emisión, el uso y el canje sin confianza de XRP en Flare. Este protocolo se llama FXRP. La metodología general del protocolo y del sistema que conecta Flare a otras redes es extensible a cualquier token completo que no sea de Turing. La interoperabilidad sin confianza con otras redes es factible, tanto a través de protocolos de interoperabilidad como Cosmos y Polkadot como con Ethereum a través de protocolos de puente bien definidos.

El token de Flare, Spark, se crea a través de lo que puede ser la primera bifurcación de utilidad en la que la red de origen, en este caso el Libro Mayor XRP, se beneficia a través de una mayor utilidad. Se crearán 100 Mil millones de tokens Spark al comienzo de la red Flare, de los cuales 45 mil millones serán reclamados por los titulares de XRP existentes, excluyendo Ripple Labs. Esto refleja la cantidad existente de XRP distribuido, de modo que los titulares actuales de XRP podrán reclamar aproximadamente 1 token Spark por cada token XRP que posean. 25 Mil millones de tokens irán a los desarrolladores, Flare y 30 mil millones de tokens irán a una fundación sin fines de lucro llamada fundación Flare. Los titulares de tokens de Spark pueden obtener un rendimiento de sus tokens de Spark, tanto al comprometer tokens de Spark como garantía para asegurar la emisión y el canje sin confianza de FXRP, como al contribuir con datos al oracle de la serie temporal de Flare. Estas funciones no compiten entre sí.

El token de Spark se utiliza para el gobierno de la red a través de la votación. Con la excepción de subvenciones e inversiones para ayudar a desarrollar Flare, la fundación toma la dirección técnica de los propietarios de tokens de Spark. Un papel clave de la fundación es ayudar a ejecutar actualizaciones y cambios en la red, acordados por votación de gobierno, que no se pueden implementar sin un cambio de código. Es importante destacar que, escrito en la constitución de la fundación, habrá un reglamento por el que se debe cerrar la fundación y quemar todos los tokens de Spark que tenga la fundación, si los titulares de los tokens de Spark están de acuerdo en que su existencia ya no es beneficiosa para la red.

Flare combina el valor de los tokens completos sin Turing con el poder transformador de los contratos inteligentes en una red que puede escalarse en función del valor y el rendimiento de las transacciones.

Respuestas a Dos preguntas:

¿Spark está creando una Prueba de Participación por la puerta trasera?

Solo los tokens emitidos que requieren garantía, como FXRP, están asegurados con Spark. La red no utiliza Spark por seguridad para llegar a un consenso.

Teníamos (lo que creemos que son) conceptos muy fuertes para una moneda estable denominada en USD, pero requería una amplia reingeniería de la Máquina Virtual Ethereum que habría retrasado el lanzamiento y tendría efectos impredecibles en la compatibilidad futura con el EVM. Spark, tal como está estructurado, ofrece una utilidad y un beneficio mucho mayores tanto para la comunidad XRP como para el libro mayor XRP.