Como la tercera criptomoneda más grande, la mayoría de las personas familiarizadas con el espacio han oído hablar de Ripple y entienden que es una red global de pagos y divisas que fue diseñada para reemplazar la obsoleta red bancaria SWIFT. Y aunque funciona muy bien para ese caso de uso específico, de lo contrario, ha mostrado una utilidad limitada en otras funciones.
Sin embargo, todo eso podría arreglarse, ya que Flare Network se creó con el objetivo de mejorar la utilidad de los tokens XRP mediante la creación de una red con capacidad de contrato inteligente para el token XRP. Para asegurarse de que los contratos inteligentes no se agreguen a la red Ripple, sino que estarán en la red Flare, y esa red admitirá el uso de XRP como FXRP.
Valor de desbloqueo para Rippple (XRP). Imagen vía Llamarada
Flare Network también tiene su propio token llamado Spark (FLR), que se lanzó recientemente a los titulares de XRP en un lanzamiento aéreo que creó un gran revuelo en la comunidad de Ripple.
Si todo esto te parece interesante, tómate algo para beber y prepárate para aprender más sobre Flare Network.
¿Qué es Flare?
Flare fue creado por Hugo Philion y Sean Rowan para resolver dos problemas básicos de blockchain:
- Tres cuartas partes del valor de los tokens públicos de blockchain no se pueden usar con contratos inteligentes de manera no confiable. Este es el problema de la necesidad inmediata según Philion y Rowan.
Flare Network promete desbloquear el valor atrapado en blockchains. Imagen vía Slideshare.net
- Las direcciones que se toman al intentar escalar las redes blockchain podrían conducir a posibles problemas futuros, ya que muchas de las nuevas redes están abordando el escalado a través del consenso de Prueba de participación o alguna variación del mismo. Todos estos protocolos obtienen la seguridad de su red del token nativo de la cadena de bloques. Esto presenta un problema tanto inmediato como a largo plazo.
Prueba de problemas de participación
Según Flare, el problema más inmediato con Prueba de participación El consenso es que no está diseñado adecuadamente para permitir usos alternativos seguros de los tokens nativos. Como estamos viendo con la explosión de las plataformas DeFi, cualquier poseedor de tokens racional que pueda aumentar el rendimiento de su token al proporcionar liquidez a una moneda estable lo hará. El problema es que esto quita las fichas del juegoy amenaza la seguridad de la red.
Los sistemas Proof of Stake son muy populares. Imagen a través de Shutterstock
A largo plazo, el problema potencial proviene de la posibilidad de que con el tiempo el valor de un token de apuesta no aumente de valor. Si eso ocurre mientras el tráfico de la red aumenta, la red también se vuelve cada vez más insegura. Si bien un token de mayor valor es bueno para la seguridad de la red y para los inversores de tokens, es malo si queremos que la descentralización se convierta en la norma para hacer negocios.
Cuando el valor de la ficha aumenta, está desviando capital de otros usos. A largo plazo, esto se convierte en un problema porque eventualmente en una red de contrato inteligente que usa prueba de participación, la escala de capital necesaria simplemente para asegurar la red se volvería demasiado alta para ser factible.
En última instancia, las redes Proof of Stake pueden escalar para transacciones, pero no pueden escalar por valor.
Cómo Flare pretende resolver estos problemas
Flare propone una nueva forma de escalar las plataformas de contratos inteligentes sin vincular la seguridad de la red al valor del token. Si bien la red aún requiere un token nativo para disuadir el spam, ese token no está vinculado de ninguna manera a la seguridad de la red. Flare usa el token FLR como su token nativo y es muy adecuado para permitir el uso sin confianza de tokens completos que no son de Turing con contratos inteligentes.
Flare se autodenomina la primera red completa del Acuerdo Bizantino Federado (FBA) de Turing. Utiliza el protocolo de consenso Avalanche que se ha adaptado al consenso de Logística de Amazon. El beneficio de usar Logística de Amazon es su capacidad para lograr la seguridad de la red sin depender de incentivos económicos para los titulares. Debido a que Flare usa una versión de la máquina virtual Ethereum (EVM), es capaz de ejecutar contratos inteligentes completos de Turing.
A los desarrolladores de Flare les encanta FBA. Imagen vía HaciaDataScience.com
Logística de Amazon ha sido criticada porque puede conducir a una topología frágil donde la falla de un solo nodo puede causar la falla de toda la red. Flare evita esto implementando una topología de Lista de nodos únicos (UNL) para enfatizar la claridad y la facilidad de uso mientras se mantiene la propiedad de membresía abierta de Logística de Amazon.
Si bien Flare permite el uso completo de contratos inteligentes de Turing, también tiene un protocolo construido en la parte superior de la red que permite la emisión, el uso y el canje sin confianza de XRP en Flare. Flare llama a este protocolo FXRP y permite que XRP se convierta en FXRP en Flare, asegurado por el token FLR nativo. En esencia, esto permite que XRP use contratos inteligentes y también puede crear una canalización sin confianza para XRP a otras redes con fines de interoperabilidad.
Esta metodología general también se puede extender a cualquier otro token completo que no sea de Turing, y la capacidad de hacerlo se ha incluido en el gobierno y los sistemas de la red. Esto significa que cualquier token completo que no sea de Turing puede eventualmente acceder a la capacidad de usar contratos inteligentes y volverse interoperable a través de Flare.
Descripción general de FXRP
El problema al que se enfrenta el equipo de Flare al llevar XRP a Flare Network es la imposibilidad de un contrato inteligente de blockchain público para controlar una dirección XRP. Esto se debe a que los contratos inteligentes no tienen forma de almacenar una clave secreta y mantener su secreto.
Si Flare intentara traer XRP a la red usando solo código, también requeriría que un grupo de personas se reunieran y usaran una dirección de firmas múltiples que controlan colectivamente para autorizar transacciones. Por supuesto, esto significaría que FXRP en estas condiciones no sería ni descentralizado ni sin confianza. Y eso sería inaceptable.
Conexión entre Ripple y Flare. Imagen vía Informe técnico de FXRP
Con la implementación actual de FXRP, cualquier titular de XRP puede enviar sus tokens a un agente en la red XRP. El agente tiene el XRP y se comunica con los contratos inteligentes en Flare, que emiten FXRP en una proporción de 1: 1. Estos tokens FXRP también están asegurados con FLR en una proporción de 1: 2.5. Entonces, por cada 1 FXRP emitido, debe haber 2.5 FLR apostados. Esto mantiene seguro el XRP en poder del agente y elimina la necesidad de cualquier intermediario centralizado.
¿Cómo funciona FXRP?
Los propietarios de FLR pueden enviar sus tokens a los contratos inteligentes en Flare que componen el sistema FXRP. En esencia, esto proporciona una garantía al sistema FXRP. Estos contratos inteligentes se denominan agentes. El sistema FXRP estará compuesto por muchos agentes. Vamos a nombrar a uno de ellos Guy.
Como agente en el sistema FXRP, Guy ha apostado 5,000 FLR como garantía. El sistema requiere 2.5 FLR por cada token FXRP emitido. Si el tipo de cambio de FLR a XRP es actualmente de 10: 1, estos 5,000 FLR permitirán a Guy emitir 200 FXRP. es decir (5,000 / 10) / 2.5
Ahora Guy está listo para acuñar FXRP. Cuando un titular de XRP desea crear FXRP, envía una transacción al sistema FXRP. El titular que inicia esta transacción se denomina originador. Para crear FXRP, también pagan una tarifa del 0.1% del valor de la transacción. La tarifa va al agente y la transacción le dice al agente a qué dirección debe enviar el FXRP cuando se acuña y desde dónde se originará el XRP en el Libro mayor de XRP.
Un enfoque transaccional del sistema FXRP. Imagen vía Llamarada.
Suponiendo que haya suficiente garantía en el sistema FXRP, está bloqueado para asegurar el FXRP, lo que hace que la transacción no sea confiable porque el originador no tiene que confiar en el agente que ahora tiene un incentivo para devolver el XRP cuando se le solicita hacerlo o perder el FLR que se mantiene como garantía. Si el sistema no tiene suficiente garantía, devolverá el XRP y la tarifa al originador.
Es clave tener en cuenta que la proporción de garantía de 2.5 debe mantenerse en todo momento. Si en algún momento el valor de XRP aumenta o el valor de FLR cae de manera que la ración cae por debajo de 2.5, Guy tendrá un corto período de tiempo para restaurar la proporción agregando más tokens de FLR o comprando tokens de FXRP para canjear.
Si por alguna razón Guy no puede o no quiere restaurar la relación de garantía de 2.5, su garantía se subasta para recomprar el FXRP que se emitió en su contra. Si queda alguna garantía después de que este tipo pueda quedarse con el resto.
Si Guy mantiene la garantía en 2.5 o más, todo está bien. Más tarde, cuando el originador decide canjear el FXRP de nuevo al libro mayor de XRP, realiza una transacción para hacerlo, lo que le permite al sistema saber qué dirección debe acreditarse con el XRP. Guy recibirá instrucciones del sistema con respecto a cuánto XRP devolver y a qué dirección enviarlo.
Junto con eso, también recibirá dos plazos en los que debe completarse la transacción. Si completa la transacción antes de la primera fecha límite, recibirá toda su garantía. Sin embargo, si pasa la primera fecha límite y él completa la transacción antes de la segunda fecha límite, se aplicará una pequeña multa antes de que se le devuelva el resto de su garantía. El sistema quema esa tarifa de multa.
Si el agente no devuelve el XRP, es un error de canje, Imagen a través de Flare.
Si Guy no completa la transacción antes de la segunda fecha límite, se considera un fracaso de canje. En este caso, el originador es compensado con tokens FLR de la participación de Guy, más un 1% adicional para cubrir los costos de transacción de usar ese FLR para recomprar XRP. El FLR restante de la garantía de Guy ve el 50% quemado como una penalización, y el 50% restante se devuelve a Guy.
FLR y aplicaciones dependientes
El sistema FXRP es nuestro primer ejemplo de la aplicación dependiente de FLR (SDA). Esta es una dApp que utiliza FLR como garantía, los titulares de tokens de FLR para la gobernanza, el Flare Time Series Oracle (FTSO) o alguna combinación de estos elementos. Tenga en cuenta que todos estos son elementos opcionales. Cualquier aplicación en Flare Network puede funcionar usando solo FLR para los costos de transacción y pago.
En el caso del sistema FXRP, utiliza FLR como garantía, Flare Time Series Oracle para rastrear el precio XRP / FLR y la propiedad del token FLR establecida para la gobernanza sobre ciertos parámetros, como la tarifa de creación de FXRP y la relación de garantía. El modelo SDA proporciona una plantilla a los desarrolladores para ampliar el uso de los tres elementos opcionales.
Oráculo Flare Time Series
Los titulares del token FLR son elegibles para contribuir al FTSO para ayudar a formar estimaciones precisas de datos fuera de la cadena mientras mantienen la descentralización. La estructura de la FTSO permite muchas estimaciones de cualquier serie de tiempo fuera de la cadena. El valor XRP / FLR es un ejemplo de dicha serie temporal.
La revolución de los contratos inteligentes. Imagen vía bobina.com
La formulación de los datos de series de tiempo suele tener dos grupos participantes. Uno son los titulares del token FLR, y el segundo son los titulares del token de la aplicación dependiente, que Flare llama el activo F. En el caso del sistema FXRP, el token FXRP es el activo F. Cuando hay una aplicación más compleja que requiere el cálculo de múltiples series de tiempo, el activo F será algo similar a un token de gobierno emitido.
Al crear la serie de tiempo, la FTSO consultará a cada participante para obtener una estimación del valor de los datos. Los titulares de FLR proporcionan estimaciones para cada serie de tiempo, pero los titulares de activos F solo pueden proporcionar una estimación de la serie de tiempo relacionada con el activo F. Las estimaciones se procesan como se detalla en la sección 4 del Libro blanco Flare y el resultado se envía al sistema que requiere los datos de la serie temporal.
Los titulares de activos F están incentivados a participar y proporcionar datos para contribuir a la seguridad de la aplicación que utiliza esos datos. Los titulares de FLR están incentivados por la posibilidad de ganar una recompensa de oráculo, que son tokens FLR acuñados por el sistema. Los titulares de tokens FLR obtienen esta recompensa cuando proporcionan datos que el sistema considera correctos. La mecánica específica de este cálculo es bastante compleja y se puede ver en el documento técnico de Flare.
Versión simplificada de un contrato inteligente
Este sistema apuesta implícitamente a todos los tokens FLR en el sistema, ya que los no participantes o aquellos que proporcionan datos que se consideran incorrectos no obtienen recompensas, lo que es un desincentivo en comparación con los poseedores de tokens que reciben la recompensa. Esta es la versión de Flare de recompensas de apuesta o minería.
La FTSO se iniciará para proporcionar los siguientes precios para: XRP / FLR, USD / FLR, BTC / FLR y XLM / FLR. Solo XRP / FLR tendrá un activo F correspondiente desde el principio. Se pueden proponer y aceptar series de tiempo adicionales y sus activos F relacionados mediante el proceso de gobernanza.
Delegación FLR
Las estimaciones provendrán de la FTSO cada pocos segundos, pero es realista suponer que no todos los titulares de FLR estarán interesados en participar en el gobierno de la red, o que tendrán el hardware necesario para contribuir a la FTSO.
Debido a que el equipo de Flare ha asumido que esto es cierto, hicieron posible separar los votos para estas responsabilidades y delegarlos en otros. La delegación se puede cancelar en cualquier momento y, si el token se transfiere a una nueva dirección, la delegación se cancela automáticamente.
Una característica importante de la delegación es que los SDA pueden delegar votos al propietario real, quien luego puede volver a delegar esos votos a otra entidad. Esto significa que los agentes no tienen que elegir entre ganar FLR por proporcionar garantía al sistema FXRP o ganar dinero del FTSO. Por lo tanto, siempre que los tokens FLR no estén disponibles para los propietarios en un SDA, siempre que la aplicación defina quién es el propietario real, se puede utilizar la delegación.
Gobernanza Flare
Los titulares de tokens de FLR votan para gobernar la red, y los SDA también pueden solicitar ser gobernados por los titulares de tokens de FLR.
En el documento técnico de Flare, puede encontrar regímenes para cualquier cambio manual en cadena que los titulares de FLR puedan iniciar y votar. Se trata de cosas como cambiar las tarifas asociadas con las acciones, cambiar la relación de garantía, cambiar los costos de transacción y otras variables que no requieren un cambio de código.
Diferentes niveles de gobernanza en Flare Network. Imagen a través del documento técnico de Flare.
Para aquellas cosas que requieren un cambio de código, como cambiar los parámetros de consenso de la red o agregar una nueva serie de tiempo al FTSO, se creará una Fundación Flare. La Fundación aún no se ha creado, pero será una entidad sin ánimo de lucro con responsabilidad en 5 áreas: subvenciones, inversiones, investigación y desarrollo, educación, publicidad y colaboraciones.
Debido a que la Fundación tiene la función de investigación y desarrollo, se vuelven parte integral del proceso de actualización del código, construyendo, probando, analizando y luego implementando cualquier cambio de código propuesto.
La Fundación se creará para ser completamente transparente en sus actividades y sus gastos. Publicará un informe semestral sobre sus actividades y gastos. Lo más importante es que no está facultado para establecer una agenda, sino que se crea de una manera que solo le permite seguir la dirección de los titulares de la RPF.
Obtenga más información en los informes técnicos de Flare. Imagen a través de Flare.
Debido a esta restricción, la Fundación no puede:
- contribuir a la FTSO de cualquier forma;
- desplegar cualquiera de sus existencias de FLR como garantía para cualquier aplicación en la red;
- usar sus tenencias de FLR para votar en cualquier voto de gobierno o asignar sus tokens de FLR a otros para que lo hagan.
Además, los titulares de FLR podrían votar en cualquier momento para disolver la Fundación, en cuyo caso se le requeriría cerrar todas las actividades y quemar cualquiera de sus tokens restantes.
Emisión de FLR y Airdrop
Flare eligió lanzar sus tokens en algo que denominó horquilla de utilidad. Las bifurcaciones tradicionales han dividido la base de usuarios de una red, con una parte que se dirige en su propia dirección y, por lo general, adopta una postura antagónica a la cadena principal.
Por el contrario, la horquilla utilitaria está destinada a agregar valor a la cadena original. Eso es exactamente lo que hace Flare al permitir que XRP continúe brindando una liquidación rápida, confiable y sin confianza al mismo tiempo que le brinda contratos inteligentes y la posibilidad de crear tuberías confiables a otras cadenas de bloques. Es un ejemplo perfecto de cómo traer una nueva utilidad a una cadena de bloques existente.
Flare está creando 100 mil millones de tokens FLR para reflejar la cantidad de tokens XRP existentes. La intención al principio es hacer que estos tokens estén disponibles para direcciones que no sean propiedad de Ripple Labs, fundadores de Ripple, cuentas de ballenas y cualquier dirección que sea estafadora conocida.
Flare ha hecho que los titulares de XRP puedan reclamar 45 mil millones de FLR y estos tokens se asignan a direcciones que tienen XRP en el momento en que se tomó una instantánea del Libro mayor a las 00:00 GMT del 12 de diciembre de 2020. Además, 30 mil millones de FLR se asignan a la Fundación Flare y se asignan 25 mil millones de FLR adicionales a Flare Networks Limited, que es la organización con fines de lucro que respalda el desarrollo de Flare.
Los titulares de XRP se benefician del lanzamiento aéreo Spark. Imagen vía RippleCoinNoticias.com
La asignación está destinada a ser 1: 1, sin embargo el cálculo real condujo a una relación de distribución de 1.0073 FLR para cada XRP en el momento de la instantánea. Además, los tokens no se pueden reclamar hasta que la red principal entre en funcionamiento, lo que se supone que ocurrirá en las primeras semanas de junio de 2021. Cualquiera que tenga tokens XRP en un intercambio que admita el lanzamiento aéreo recibirá automáticamente tokens FLR cuando se distribuyan.
La lista de intercambios de apoyo incluye Binance, KuCoin, Coinbase, Poloniex y muchos otros. Aquellos que mantengan su XRP en una billetera de auto-custodia deberán registrar un reclamo, y los tokens de FLR se entregarán a la dirección establecida en el reclamo. Habrá una serie de carteras compatibles con FLR para elegir cuando se lance la red principal.
También vale la pena señalar que Flare ha dicho "Puede reclamar FLR después de que la red entre en funcionamiento, pero no después de la fecha de 6 meses desde la instantánea ". Dado que la instantánea ocurrió el 12 de diciembre de 2020, indica que la red principal se lanzará antes del 12 de junio de 2021.
Además, no todos los tokens se distribuyen de inmediato. Flare se liberará 15% de la asignación de tokens cuando se lanza la red principal. El FLR restante se liberará durante los próximos 25 a 34 meses a una tasa del 2 al 4% por mes.
¿Quién está detrás de Flare Networks?
El CEO y cofundador de Flare Network es Hugo Philión. Antes de crear Flare, fue el fundador del sistema de construcción modular Future Generations. Tiene experiencia en inversiones y tiene una licenciatura en Gestión de Riesgos Financieros e Inversiones de Cass Business School.
Posteriormente recibió una Maestría en Ciencias en Aprendizaje Automático de la UCL. También ganó experiencia trabajando como administrador de cartera de derivados de materias primas en dos fondos de más de mil millones de dólares.
Hugo y Sean, los cofundadores de Flare. Imagen a través de Flare.
El otro cofundador de Flare y su CTO es Sean Rowan. Sean ha estado involucrado en el espacio blockchain desde 2015 cuando diseñó protocolos de comunicaciones vehiculares seguros aprovechando una infraestructura de clave pública basada en blockchain con colegas de UCLA y TCD. Antes de eso, recibió una doble licenciatura en Matemáticas y BE en Ingeniería Electrónica e Informática del Trinity College Dublin.
Más tarde recibió una Maestría en Ciencias en Aprendizaje Automático de la University College London, que presumiblemente es donde conoció a Hugo Philion. Sean también fue ingeniero de I + D en RAIL en Dublín, Irlanda, donde desarrolló un software de red backend para un robot de asistencia sanitaria. La última versión de este robot de RAIL aparece en la portada de la revista TIME en noviembre de 2019.
Conclusión
Con Ripple teniendo tantos seguidores y un enorme potencial en el espacio bancario, Flare Network podría volverse tan grande como la red que brinda la funcionalidad de contrato inteligente a XRP. Eso es ciertamente lo que esperan los fundadores del proyecto, y es probable que haya un gran grupo de entusiastas de XRP que estén igualmente entusiasmados con las posibilidades que ofrece Ripple por Flare.
Una cosa que se puede decir del proyecto es que ciertamente generó mucho revuelo con su lanzamiento aéreo, y estamos dispuestos a apostar que hay millones que nunca antes habían oído hablar de Flare y que ahora están al tanto de su existencia, y posiblemente de su misión y metas. Después de leer este artículo, debería contarse entre ellos.
El lanzamiento aéreo también creó un gran revuelo dentro de la comunidad de Ripple, ya que el token XRP subió casi un 300% en noviembre de 2020. Eso se debió a que los especuladores se agolparon en la moneda para aprovechar el lanzamiento aéreo. Desde entonces, las cosas no han sido tan optimistas, ya que XRP ha caído de un máximo de alrededor de $ 0.90 a un mínimo de $ 0.227880 el 23 de diciembre de 2020.
No sabemos qué pasará con el token FLR cuando se distribuya, pero incluso con el programa de emisión lento inicialmente planeado, parece que el mercado se inundará con tokens FLR en los primeros 2-3 años posteriores al lanzamiento de la red principal. . A menos que haya algunos desarrollos que causen un aumento similar en la demanda durante ese tiempo, el token podría estar a punto de caer, ya que los mismos especuladores que compraron XRP para el lanzamiento aéreo deciden deshacerse de su FLR lo antes posible.
Si está tomando un horizonte de tiempo más largo, este podría ser un buen proyecto para atrasarse, y si tenemos razón sobre el lanzamiento de la red principal, podría presentar una buena oportunidad para comprar bolsas masivas de FLR a bajo precio. Por supuesto, solo el tiempo dirá si eso es cierto.
La otra cosa para recordar es que Flare comenzó con Ripple, pero teóricamente puede agregar funcionalidad e interoperabilidad de contrato inteligente a cualquier blockchain. Teniendo en cuenta que las tres cuartas partes del valor de los tokens de blockchain públicos no se pueden utilizar con contratos inteligentes de manera desconfiada, actualmente, Flare tiene una enorme curva de crecimiento potencial por delante.
Imagen destacada a través de Shutterstock
Descargo de responsabilidad: estas son las opiniones del autor y no deben considerarse consejos de inversión. Los lectores deben hacer su propia investigación.