Reseña de Flare Network Review: red de contratos inteligentes XRP
Reseña de Flare Network Review: red de contratos inteligentes XRP
Reseña de Flare Network Review: red de contratos inteligentes XRP
Últimas actualizaciones:
1 feb 2021
Al ser la tercera criptomoneda más grande, la mayoría de las personas de este mundillo han oído hablar de Ripple y entienden que es una red global de pagos y de intercambio de divisas que fue diseñada para reemplazar la anticuada red bancaria SWIFT. Y aunque se puede decir que funciona muy bien para ese caso de uso específico, lo cierto es que ha mostrado una utilidad limitada en otras funciones.
Este problema podría solucionarse ya que se ha creado Flare Network con el objetivo de mejorar la utilidad de los tokens XRP mediante la creación de una red con capacidad de soportar contratos inteligentes con el token XRP. En realidad, los contratos inteligentes no se están añadiendo a la red Ripple, sino que estarán en la Flare Network, y esa red soportará el uso tanto de XRP como de FXRP.
Desbloqueando el valor de Rippple (XRP). Imagen vía Flare
Flare Network también tiene su propio token llamado Spark (FLR), que fue distribuido recientemente entre los poseedores de XRP en un airdrop que creó un gran revuelo dentro de la comunidad de Ripple.
Si todo esto te suena interesante, entonces coge algo de 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 la cadena de bloques:
Las tres cuartas partes del valor de los tokens de cadenas de bloques públicas no se pueden utilizar con contratos inteligentes de forma fiable. Este es un problema que debe ser resuelto de inmediato, según Philion y Rowan.
Flare Network promete desbloquear el valor atrapado en las cadenas de bloques. Imagen vía Slideshare.net
Las direcciones que se están tomando para intentar escalar las redes de cadenas de bloques podrían conducir a posibles problemas en el futuro, ya que muchas de las nuevas redes están abordando el escalado a través del consenso Prueba de Participacion (PoS) o alguna variación del mismo. Todos estos protocolos derivan lu seguridad de red del token nativo de la cadena de bloques. Esto supone un problema tanto inmediato como a largo plazo.
Problemas de la Prueba de Participación
Según Flare, el problema más inmediato del consenso Prueba de Participación es que no está bien diseñado para permitir usos alternativos seguros de los tokens nativos. Como estamos viendo con la explosión de las plataformas DeFi, cualquier poseedor racional de tokens que pueda aumentar el rendimiento de su token proporcionando liquidez a una moneda estable lo hará. El problema es que esto desincentiva el staking y amenaza la seguridad de la red.
Los sistemas de Prueba de Participación son muy populares. Imagen vía Shutterstock
A largo plazo, el problema potencial proviene de la posibilidad de que, con el tiempo, el valor de un token en staking no aumente. Si esto ocurre a la vez que aumenta el tráfico de la red, ésta se vuelve cada vez más insegura. Aunque un token con mayor valor es bueno para la seguridad de la red y para los inversores en tokens, es malo si queremos que la descentralización se convierta en la norma para hacer negocios.
Cuando el valor del token aumenta, está desviando el capital de otros usos. A largo plazo, esto se convierte en un problema, ya que, en una red de contratos inteligentes que utilice Prueba de Participación, la proporción de capital necesaria para asegurar la red sería demasiado alta para ser viable.
En última instancia, las redes de Prueba de Participación pueden escalar las transacciones, pero son incapaces de escalar el valor.
¿Cómo pretende Flare 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. Aunque la red sigue necesitando un token nativo para disuadir el spam, ese token no está vinculado de ninguna manera a la seguridad de la red. Flare utiliza el token FLR como su token nativo y es muy adecuado para permitir el uso sin confianza de tokens no completos de Turing con contratos inteligentes.
Flare se autodenomina la primera red de Acuerdo Bizantino Federado (FBA, Federated Byzantine Agreement) de Turing completa. Utiliza el protocolo de consenso de Avalanche adaptado al consenso FBA. La ventaja de utilizar FBA es su capacidad para lograr la seguridad de la red sin depender de ningún incentivo económico para los titulares de tokens. Dado que Flare utiliza una versión de la máquina virtual de Ethereum (EVM, Ethereum Virtual Machine), es capaz de ejecutar contratos inteligentes de Turing completos .
Los desarrolladores de Flare adoran el FBA. Imagen vía TowardsDataScience.com
El FBA ha sido criticado porque puede dar lugar a una topología frágil en la que el fallo de un solo nodo puede provocar el fallo de toda la red. Flare evita esto implementando una topología de Lista de Nodos Únicos (UNL, Unique Node List) para enfatizar la claridad y la facilidad de uso mientras se mantiene la propiedad de pertenencia abierta al FBA.
Esta metodología general también puede extenderse a cualquier otro token de Turing no completo, y la capacidad de hacerlo se ha incluido en la gobernanza y en los sistemas de la red. Esto significa que cualquier token de Turing no completo puede eventualmente acceder a la capacidad de utilizar contratos inteligentes y ser interoperable a través de Flare.
Visión general de FXRP
El problema al que se enfrenta el equipo de Flare para llevar XRP a Flare Network es la imposibilidad de que un contrato inteligente de una cadena de bloques pública controle 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 tratara de traer XRP a la red usando sólo código, también requeriría que un grupo de individuos se unieran y usaran una dirección multifirma bajo su control colectivo para autorizar las transacciones. Por supuesto, el FXRP en estas condiciones no estaría descentralizado ni sería confiable. Y eso sería inaceptable.
Conexión entre Ripple y Flare. Imagen vía FXRP Whitepaper
Con la implementación actual de FXRP cualquier poseedor de XRP puede enviar sus tokens a un agente en la red XRP. El agente mantiene 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. Así, por cada 1 FXRP emitido debe haber 2.5 FLR en staking. Esto mantiene la seguridad del XRP en manos del agente y elimina la necesidad de cualquier intermediario centralizado.
¿Cómo funciona el FXRP?
Los propietarios de FLR pueden enviar sus tokens a los contratos inteligentes en Flare que conforman el sistema FXRP. En esencia, esto supone proporcionar una garantía al sistema FXRP. Estos contratos inteligentes se llaman agentes. El sistema FXRP estará compuesto por muchos agentes. Vamos a nombrar a uno de ellos, Guy.
Como agente del sistema FXRP, Guy ha hecho staking de 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 quiere crear FXRP, envía una transacción al sistema FXRP. El titular que inicia esta transacción se llama originador. Para crear FXRP también se paga una tasa del 0.1% del valor de la transacción. La tarifa es para el agente, y la transacción indica al agente a qué dirección debe enviar el FXRP cuando se acuñe y de dónde se originará el XRP a partir del registro de XRP.
Un enfoque transaccional del sistema FXRP. Imagen vía Flare.
Suponiendo que haya suficiente garantía en el sistema FXRP bloqueada para asegurar el FXRP, las transacciones son sin confianza (trustless transactions) ya que el originador no tiene que confiar en el agente, que ahora tiene un incentivo para devolver el XRP cuando se le solicite o perderá el FLR que mantiene como garantía. Si el sistema no tiene suficiente garantía, devolverá el XRP y la comisión al originador.
Es fundamental tener en cuenta que el ratio de garantía de 2.5 debe mantenerse en todo momento. Si en algún momento el valor de XRP sube o el valor de FLR baja de manera que la proporción cae por debajo de 2.5, Guy tendrá un breve lapso de tiempo para restaurar la proporción añadiendo más tokens FLR o comprando tokens de FXRP para poder canjearlos.
Si por alguna razón Guy no puede o no quiere restablecer el ratio de garantía de 2.5, su garantía se subasta para recomprar el FXRP que se emitió contra ella. Si después de esto queda algún tipo de garantía, Guy puede recuperarla.
Si Guy mantiene la garantía a un nivel igual o superior a 2.5, no hay problema. Más tarde, cuando el originador decida canjear el FXRP de vuelta al registro de XRP, necesitará una transacción para hacerlo, informando al sistema de la dirección en la que debe abonarse el XRP. Guy recibirá instrucciones del sistema sobre la cantidad de XRP que debe devolver y a qué dirección debe enviarlo.
Además, se le darán dos plazos para completar la transacción. Si completa la transacción antes del primer plazo, recibirá toda su garantía. Sin embargo, si pasa el primer plazo y completa la transacción antes del segundo plazo, se aplicará una pequeña comisión de penalización antes de que se le devuelva el resto de la garantía. El sistema quema esta comisión de penalización.
Si el agente no devuelve el XRP se trata de un fallo de canje., Imagen vía Flare.
Si Guy no logra completar la transacción en el segundo plazo, se considera un fallo de canje. En este caso, el originador es compensado con tokens FLR del staking de Guy, más un 1% adicional para cubrir los costes de transacción de usar ese FLR para recomprar XRP. El FLR restante del staking Guy se quema en un 50% como penalización, y el 50% restante se devuelve a Guy.
FLR y aplicaciones dependientes
El sistema FXRP es nuestro primer ejemplo de aplicación dependiente de FLR (SDA). Se trata de una aplicación descentralizada que utiliza FLR como garantía, tokens FLR para la gobernanza, el Oráculo de Series Temporales de Flare (FTSO, Flare Time Series Oracle), o alguna combinación de estos elementos. Tenga en cuenta que todos estos elementos son opcionales. Cualquier aplicación en Flare Network es capaz de funcionar utilizando sólo FLR para los costes de transacción y de pago.
El sistema FXRP utiliza FLR como garantía, el FTSO de Flare para rastrear el precio de XRP/FLR y el conjunto de propiedad de tokens de FLR para gobernar ciertos parámetros como la tasa de creación de FXRP y el ratio de garantía. El modelo SDA proporciona una plantilla a los desarrolladores para ampliar el uso de los tres elementos opcionales.
Oráculo de Series Temporales de Flare (FTSO)
Los poseedores del token FLR pueden contribuir al FTSO para ayudar a realizar estimaciones precisas de datos fuera de la cadena, manteniendo la descentralización. La estructura del FTSO permite realizar muchas estimaciones de cualquier serie temporal fuera de la cadena. El valor de XRP/FLR es un ejemplo de dicha serie temporal.
La revolución de los contratos inteligentes. Imagen vía Coil.com
La configuración de los datos de las series temporales suele tener dos grupos de participantes. Uno es el de los titulares del token FLR, y el otro es el de los titulares del token de aplicación dependiente, que Flare denomina F-asset. En el caso del sistema FXRP, el token FXRP es el F-asset. Cuando existe una aplicación más compleja que requiere el cálculo de múltiples series temporales, el F-asset será algo similar a un token de gobierno emitido.
Al crear las series temporales, el FTSO solicitará a cada participante una estimación del valor de los datos. Los titulares de FLR proporcionan estimaciones para cada serie temporal, pero los titulares de F-asset sólo pueden proporcionar una estimación para la serie temporal que está relacionada con dicho F-asset. Las estimaciones se procesan tal y como se detalla en la sección 4 del documento técnico de Flare y el resultado se envía al sistema que requiere los datos de las series temporales.
Los titulares de F-asset 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 puede verse en el documento técnico de Flare.
Versión simplificada de un contrato inteligente
Este sistema hace staking de todos los tokens de FLR, ya que los no participantes o aquellos que proporcionan datos que se consideran incorrectos no obtienen recompensas, lo que supone un desincentivo en comparación con los poseedores de tokens que sí reciben recompensas. Esta es la interpretación de Flare de las recompensas de staking o minería.
El FTSO se lanzará para proporcionar los siguientes precios: XRP/FLR, USD/FLR, BTC/FLR y XLM/FLR. Sólo XRP/FLR tendrá un F-asset al comienzo. Pueden proponerse y aceptarse otras series temporales y sus correspondientes F-assets a través del proceso de gobernanza.
Delegación de FLR
Las estimaciones provendrán del FTSO cada pocos segundos, pero es realista suponer que no todos los titulares de FLR estarán interesados en participar en la gobernanza de la red, o que tendrán el hardware necesario para contribuir al FTSO.
Como el equipo de Flare ha asumido que esto es cierto, han hecho posible desligar los votos de 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 SDAs pueden delegar los votos de vuelta al propietario real, que a su vez puede volver a delegar esos votos a otra entidad. Esto significa que los agentes no tienen que elegir entre ganar FLR por proporcionar una garantía al sistema FXRP o ganar del FTSO. Por lo tanto, siempre que los tokens FLR no estén disponibles para los propietarios en un SDA, mientras la aplicación defina quién es el propietario real, se puede utilizar la delegación.
Gobernanza de Flare
Los titulares de tokens FLR votan para gobernar la red, y los SDA también pueden solicitar ser gobernados por los titulares de tokens FLR.
En el documento técnico de Flare se pueden encontrar reglas para cualquier cambio manual en la cadena que pueda ser iniciado y votado por los titulares de FLR. Se trata de cosas como el cambio de las tarifas asociadas a las acciones, el cambio del ratio de garantía, el cambio de los costes de las transacciones y otras variables que no requieren un cambio de código.
Diferentes niveles de gobernanza en la Red Flare. Image via Flare whitepaper.
Para aquellas cosas que sí requieren un cambio de código, como cambiar los parámetros de consenso de la red o añadir una nueva serie temporal al FTSO, se creará Flare Foundation. 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 asociaciones.
Dado que la fundación tiene la función de investigación y desarrollo, se convierte en parte integrante del proceso de actualización del código, construyendo, probando, analizando y luego desplegando cualquier cambio de código propuesto.
La fundación se creará para ser completamente transparente en sus actividades y sus gastos. Publicará un informe bianual sobre sus actividades y gastos. Y lo que es más importante, no está facultada para establecer una agenda, sino que se crea de forma que sólo pueda recibir instrucciones de los titulares de la FLR.
Más información en los documentos técnicos de Flare. Image via Flare.
Debido a esta restricción, la fundación no puede:
contribuir al FTSO de ninguna manera;
utilizar sus token FLR como garantía para cualquier aplicación en la red;
utilizar sus token FLR para votar en cualquier votación de gobierno o ceder sus tokens de FLR a otros para que lo hagan.
Además, los titulares de FLR podrían votar en cualquier momento disolver la fundación, en cuyo caso se le exigiría que concluyera todas sus actividades y quemara cualquiera de sus tokens restantes.
Emisión de FLR y airdop
Flare optó por lanzar sus tokens en lo que denominó una bifurcación de utilidad. Las bifurcaciones tradicionales han dividido a la base de usuarios de una red, con una parte dirigiéndose en su propia dirección, y normalmente adoptando una postura antagónica a la cadena matriz.
Por el contrario, la bifurcación de utilidad pretende añadir valor a la cadena original. Eso es exactamente lo que hace Flare al permitir que XRP continúe ofreciendo una liquidación rápida, fiable y sin confianza, a la vez que aporta contratos inteligentes y la posibilidad de crear conductos sin confianza a otras cadenas de bloques. Es un ejemplo perfecto de aportar un nuevo caso de uso a una cadena de bloques existente.
Flare está creando 100 mil millones de tokens FLR para replicar el número de tokens XRP existentes. La intención inicial es hacer que estos tokens estén disponibles para las direcciones que no son propiedad de Ripple Labs, los fundadores de Ripple, las cuentas de ballenas y cualquier dirección que sea un estafador conocido.
Flare ha hecho las gestiones para que 45 mil millones de FLR puedan ser reclamados por los titulares de XRP, asignándose estos tokens a las direcciones que posean XRP en el momento en que se tome una instantánea de la cadena 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 otros 25 mil millones de FLR se asignan a Flare Networks Limited, que es la organización con fines de lucro que apoya el desarrollo de Flare.
Los titulares de XRP se benefician del airdrop de Spark. Imagen vía RippleCoinNews.com
La asignación se supone que es en un ratio de 1:1, sin embargo, el cálculo real llevó 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 pueden reclamarse 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 exchange que apoye el airdrop será acreditado automáticamente con tokens FLR cuando se distribuyan.
La lista de exchanges que soportan el airdrop incluye Binance, KuCoin, Coinbase, Poloniex y muchos otros. Aquellos que tengan sus XRP en unmonedero propio tendrán que registrar una reclamación, y los tokens FLR se entregarán a la dirección establecida en la reclamación. Habrá una serie de monederos compatibles con FLR a elegir cuando se lance la red principal.
También vale la pena señalar que Flare ha dicho que "Se pueden reclamar los FLR después de que la red se ponga en marcha, pero no más allá de la fecha de 6 meses desde la instantánea". Dado que la instantánea se produjo el 12 de diciembre de 2020, eso indica que la red principal se lanzará antes del 12 de junio de 2021.
Además, no todos los tokens se distribuirán inmediatamente. Flare liberará el 15% de la asignación de tokens cuando se lance la red principal. El resto de FLR se liberará durante los próximos 25-34 meses a un ritmo del 2-4% al mes.
¿Quién está detrás de Flare Networks?
El director general y cofundador de Flare Network es Hugo Philion. Antes de crear Flare fue el fundador del sistema de construcción modular Future Generations. Su formación es en inversiones y es licenciado en Gestión de Inversiones y Riesgos Financieros por la Cass Business School.
Más tarde obtuvo un máster en machine learning por la UCL. También adquirió experiencia trabajando como gestor de carteras 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 vía Flare.
El otro cofundador de Flare y director de tecnología es Sean Rowan. Sean ha estado vinculado al mundo de las cadenas de bloques desde 2015, cuando diseñó protocolos de comunicaciones vehiculares seguras aprovechando una infraestructura de clave pública con colegas de la UCLA y el TCD. Con anterioridad, obtuvo una doble licenciatura en Matemáticas y en Ingeniería Electrónica e Informática en el Trinity College de Dublín.
Más tarde obtuvo un máster en machine learning en la University College London, donde probablemente conoció a Hugo Philion. Sean también fue ingeniero de I+D en RAIL, en Dublín (Irlanda), donde desarrolló un software de red 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
Dado que Ripple tiene tanto un importante número de seguidores como un enorme potencial en el ámbito bancario, la red Flare podría llegar a ser igual de grande al ser la red que aporta la funcionalidad de los contratos inteligentes a XRP. Eso es ciertamente lo que esperan los fundadores del proyecto, y es probable que haya un gran grupo de entusiastas del XRP que estén igualmente entusiasmados con las posibilidades que aporta Flare a Ripple.
Una cosa que se puede decir del proyecto es que ha generado mucho revuelo con su airdrop, y estamos dispuestos a apostar que hay millones de personas que nunca habían oído hablar de Flare y que ahora conocen su existencia, y posiblemente su misión y objetivos. Después de leer este artículo, deberías contarte entre ellos.
El airdrop también creó revuelo dentro de la comunidad de Ripple, ya que el token XRP subió casi un 300% en noviembre de 2020. Esto se debió a que los especuladores se abalanzaron sobre la moneda para aprovechar el lanzamiento aéreo. Desde entonces, las cosas no han sido tan halagüeñas, ya que XRP ha caído desde un máximo de alrededor de 0,90 dólares hasta un mínimo de 0,227880 dólares el 23 de diciembre de 2020.
No sabemos qué pasará con el token FLR cuando se distribuya, pero incluso con el lento calendario de emisión previsto inicialmente parece que el mercado se inundará de tokens FLR en los 2-3 años iniciales tras el lanzamiento de la red principal. A menos que haya algunos desarrollos que causen un pico similar en la demanda durante ese tiempo, el token podría caer, si los mismos especuladores que compraron XRP para el airdrop deciden deshacerse de su FLR tan pronto como sea posible.
Si tienes un horizonte temporal más largo, este podría ser un buen proyecto para tener en cuenta, y si estamos en lo cierto sobre el lanzamiento de la red principal, podría ser una buena oportunidad para conseguir grandes cantidades de FLR a bajo precio. Por supuesto, sólo el tiempo dirá si esto es así.
La otra cosa que hay que recordar es que Flare comenzó con Ripple, pero teóricamente puede añadir funcionalidad de contratos inteligentes e interoperabilidad a cualquier cadena de bloques. Teniendo en cuenta que las tres cuartas partes del valor de los tokens de las cadenas de bloques públicas no se pueden utilizar con contratos inteligentes de forma fiable, actualmente Flare tiene una enorme curva de crecimiento potencial por delante.
Imagen destacada vía Shutterstock
Aviso: Estas son las opiniones del autor y no deben considerarse como un consejo de inversión. Los lectores deben hacer su propia investigación.
El artículo Reseña de Flare network : Red de contratos inteligentes para XRP se publicó en primer lugar en Coin Bureau.
Al ser la tercera criptomoneda más grande, la mayoría de las personas de este mundillo han oído hablar de Ripple y entienden que es una red global de pagos y de intercambio de divisas que fue diseñada para reemplazar la anticuada red bancaria SWIFT. Y aunque se puede decir que funciona muy bien para ese caso de uso específico, lo cierto es que ha mostrado una utilidad limitada en otras funciones.
Este problema podría solucionarse ya que se ha creado Flare Network con el objetivo de mejorar la utilidad de los tokens XRP mediante la creación de una red con capacidad de soportar contratos inteligentes con el token XRP. En realidad, los contratos inteligentes no se están añadiendo a la red Ripple, sino que estarán en la Flare Network, y esa red soportará el uso tanto de XRP como de FXRP.
Desbloqueando el valor de Rippple (XRP). Imagen vía Flare
Flare Network también tiene su propio token llamado Spark (FLR), que fue distribuido recientemente entre los poseedores de XRP en un airdrop que creó un gran revuelo dentro de la comunidad de Ripple.
Si todo esto te suena interesante, entonces coge algo de 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 la cadena de bloques:
Las tres cuartas partes del valor de los tokens de cadenas de bloques públicas no se pueden utilizar con contratos inteligentes de forma fiable. Este es un problema que debe ser resuelto de inmediato, según Philion y Rowan.
Flare Network promete desbloquear el valor atrapado en las cadenas de bloques. Imagen vía Slideshare.net
Las direcciones que se están tomando para intentar escalar las redes de cadenas de bloques podrían conducir a posibles problemas en el futuro, ya que muchas de las nuevas redes están abordando el escalado a través del consenso Prueba de Participacion (PoS) o alguna variación del mismo. Todos estos protocolos derivan lu seguridad de red del token nativo de la cadena de bloques. Esto supone un problema tanto inmediato como a largo plazo.
Problemas de la Prueba de Participación
Según Flare, el problema más inmediato del consenso Prueba de Participación es que no está bien diseñado para permitir usos alternativos seguros de los tokens nativos. Como estamos viendo con la explosión de las plataformas DeFi, cualquier poseedor racional de tokens que pueda aumentar el rendimiento de su token proporcionando liquidez a una moneda estable lo hará. El problema es que esto desincentiva el staking y amenaza la seguridad de la red.
Los sistemas de Prueba de Participación son muy populares. Imagen vía Shutterstock
A largo plazo, el problema potencial proviene de la posibilidad de que, con el tiempo, el valor de un token en staking no aumente. Si esto ocurre a la vez que aumenta el tráfico de la red, ésta se vuelve cada vez más insegura. Aunque un token con mayor valor es bueno para la seguridad de la red y para los inversores en tokens, es malo si queremos que la descentralización se convierta en la norma para hacer negocios.
Cuando el valor del token aumenta, está desviando el capital de otros usos. A largo plazo, esto se convierte en un problema, ya que, en una red de contratos inteligentes que utilice Prueba de Participación, la proporción de capital necesaria para asegurar la red sería demasiado alta para ser viable.
En última instancia, las redes de Prueba de Participación pueden escalar las transacciones, pero son incapaces de escalar el valor.
¿Cómo pretende Flare 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. Aunque la red sigue necesitando un token nativo para disuadir el spam, ese token no está vinculado de ninguna manera a la seguridad de la red. Flare utiliza el token FLR como su token nativo y es muy adecuado para permitir el uso sin confianza de tokens no completos de Turing con contratos inteligentes.
Flare se autodenomina la primera red de Acuerdo Bizantino Federado (FBA, Federated Byzantine Agreement) de Turing completa. Utiliza el protocolo de consenso de Avalanche adaptado al consenso FBA. La ventaja de utilizar FBA es su capacidad para lograr la seguridad de la red sin depender de ningún incentivo económico para los titulares de tokens. Dado que Flare utiliza una versión de la máquina virtual de Ethereum (EVM, Ethereum Virtual Machine), es capaz de ejecutar contratos inteligentes de Turing completos .
Los desarrolladores de Flare adoran el FBA. Imagen vía TowardsDataScience.com
El FBA ha sido criticado porque puede dar lugar a una topología frágil en la que el fallo de un solo nodo puede provocar el fallo de toda la red. Flare evita esto implementando una topología de Lista de Nodos Únicos (UNL, Unique Node List) para enfatizar la claridad y la facilidad de uso mientras se mantiene la propiedad de pertenencia abierta al FBA.
Esta metodología general también puede extenderse a cualquier otro token de Turing no completo, y la capacidad de hacerlo se ha incluido en la gobernanza y en los sistemas de la red. Esto significa que cualquier token de Turing no completo puede eventualmente acceder a la capacidad de utilizar contratos inteligentes y ser interoperable a través de Flare.
Visión general de FXRP
El problema al que se enfrenta el equipo de Flare para llevar XRP a Flare Network es la imposibilidad de que un contrato inteligente de una cadena de bloques pública controle 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 tratara de traer XRP a la red usando sólo código, también requeriría que un grupo de individuos se unieran y usaran una dirección multifirma bajo su control colectivo para autorizar las transacciones. Por supuesto, el FXRP en estas condiciones no estaría descentralizado ni sería confiable. Y eso sería inaceptable.
Conexión entre Ripple y Flare. Imagen vía FXRP Whitepaper
Con la implementación actual de FXRP cualquier poseedor de XRP puede enviar sus tokens a un agente en la red XRP. El agente mantiene 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. Así, por cada 1 FXRP emitido debe haber 2.5 FLR en staking. Esto mantiene la seguridad del XRP en manos del agente y elimina la necesidad de cualquier intermediario centralizado.
¿Cómo funciona el FXRP?
Los propietarios de FLR pueden enviar sus tokens a los contratos inteligentes en Flare que conforman el sistema FXRP. En esencia, esto supone proporcionar una garantía al sistema FXRP. Estos contratos inteligentes se llaman agentes. El sistema FXRP estará compuesto por muchos agentes. Vamos a nombrar a uno de ellos, Guy.
Como agente del sistema FXRP, Guy ha hecho staking de 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 quiere crear FXRP, envía una transacción al sistema FXRP. El titular que inicia esta transacción se llama originador. Para crear FXRP también se paga una tasa del 0.1% del valor de la transacción. La tarifa es para el agente, y la transacción indica al agente a qué dirección debe enviar el FXRP cuando se acuñe y de dónde se originará el XRP a partir del registro de XRP.
Un enfoque transaccional del sistema FXRP. Imagen vía Flare.
Suponiendo que haya suficiente garantía en el sistema FXRP bloqueada para asegurar el FXRP, las transacciones son sin confianza (trustless transactions) ya que el originador no tiene que confiar en el agente, que ahora tiene un incentivo para devolver el XRP cuando se le solicite o perderá el FLR que mantiene como garantía. Si el sistema no tiene suficiente garantía, devolverá el XRP y la comisión al originador.
Es fundamental tener en cuenta que el ratio de garantía de 2.5 debe mantenerse en todo momento. Si en algún momento el valor de XRP sube o el valor de FLR baja de manera que la proporción cae por debajo de 2.5, Guy tendrá un breve lapso de tiempo para restaurar la proporción añadiendo más tokens FLR o comprando tokens de FXRP para poder canjearlos.
Si por alguna razón Guy no puede o no quiere restablecer el ratio de garantía de 2.5, su garantía se subasta para recomprar el FXRP que se emitió contra ella. Si después de esto queda algún tipo de garantía, Guy puede recuperarla.
Si Guy mantiene la garantía a un nivel igual o superior a 2.5, no hay problema. Más tarde, cuando el originador decida canjear el FXRP de vuelta al registro de XRP, necesitará una transacción para hacerlo, informando al sistema de la dirección en la que debe abonarse el XRP. Guy recibirá instrucciones del sistema sobre la cantidad de XRP que debe devolver y a qué dirección debe enviarlo.
Además, se le darán dos plazos para completar la transacción. Si completa la transacción antes del primer plazo, recibirá toda su garantía. Sin embargo, si pasa el primer plazo y completa la transacción antes del segundo plazo, se aplicará una pequeña comisión de penalización antes de que se le devuelva el resto de la garantía. El sistema quema esta comisión de penalización.
Si el agente no devuelve el XRP se trata de un fallo de canje., Imagen vía Flare.
Si Guy no logra completar la transacción en el segundo plazo, se considera un fallo de canje. En este caso, el originador es compensado con tokens FLR del staking de Guy, más un 1% adicional para cubrir los costes de transacción de usar ese FLR para recomprar XRP. El FLR restante del staking Guy se quema en un 50% como penalización, y el 50% restante se devuelve a Guy.
FLR y aplicaciones dependientes
El sistema FXRP es nuestro primer ejemplo de aplicación dependiente de FLR (SDA). Se trata de una aplicación descentralizada que utiliza FLR como garantía, tokens FLR para la gobernanza, el Oráculo de Series Temporales de Flare (FTSO, Flare Time Series Oracle), o alguna combinación de estos elementos. Tenga en cuenta que todos estos elementos son opcionales. Cualquier aplicación en Flare Network es capaz de funcionar utilizando sólo FLR para los costes de transacción y de pago.
El sistema FXRP utiliza FLR como garantía, el FTSO de Flare para rastrear el precio de XRP/FLR y el conjunto de propiedad de tokens de FLR para gobernar ciertos parámetros como la tasa de creación de FXRP y el ratio de garantía. El modelo SDA proporciona una plantilla a los desarrolladores para ampliar el uso de los tres elementos opcionales.
Oráculo de Series Temporales de Flare (FTSO)
Los poseedores del token FLR pueden contribuir al FTSO para ayudar a realizar estimaciones precisas de datos fuera de la cadena, manteniendo la descentralización. La estructura del FTSO permite realizar muchas estimaciones de cualquier serie temporal fuera de la cadena. El valor de XRP/FLR es un ejemplo de dicha serie temporal.
La revolución de los contratos inteligentes. Imagen vía Coil.com
La configuración de los datos de las series temporales suele tener dos grupos de participantes. Uno es el de los titulares del token FLR, y el otro es el de los titulares del token de aplicación dependiente, que Flare denomina F-asset. En el caso del sistema FXRP, el token FXRP es el F-asset. Cuando existe una aplicación más compleja que requiere el cálculo de múltiples series temporales, el F-asset será algo similar a un token de gobierno emitido.
Al crear las series temporales, el FTSO solicitará a cada participante una estimación del valor de los datos. Los titulares de FLR proporcionan estimaciones para cada serie temporal, pero los titulares de F-asset sólo pueden proporcionar una estimación para la serie temporal que está relacionada con dicho F-asset. Las estimaciones se procesan tal y como se detalla en la sección 4 del documento técnico de Flare y el resultado se envía al sistema que requiere los datos de las series temporales.
Los titulares de F-asset 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 puede verse en el documento técnico de Flare.
Versión simplificada de un contrato inteligente
Este sistema hace staking de todos los tokens de FLR, ya que los no participantes o aquellos que proporcionan datos que se consideran incorrectos no obtienen recompensas, lo que supone un desincentivo en comparación con los poseedores de tokens que sí reciben recompensas. Esta es la interpretación de Flare de las recompensas de staking o minería.
El FTSO se lanzará para proporcionar los siguientes precios: XRP/FLR, USD/FLR, BTC/FLR y XLM/FLR. Sólo XRP/FLR tendrá un F-asset al comienzo. Pueden proponerse y aceptarse otras series temporales y sus correspondientes F-assets a través del proceso de gobernanza.
Delegación de FLR
Las estimaciones provendrán del FTSO cada pocos segundos, pero es realista suponer que no todos los titulares de FLR estarán interesados en participar en la gobernanza de la red, o que tendrán el hardware necesario para contribuir al FTSO.
Como el equipo de Flare ha asumido que esto es cierto, han hecho posible desligar los votos de 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 SDAs pueden delegar los votos de vuelta al propietario real, que a su vez puede volver a delegar esos votos a otra entidad. Esto significa que los agentes no tienen que elegir entre ganar FLR por proporcionar una garantía al sistema FXRP o ganar del FTSO. Por lo tanto, siempre que los tokens FLR no estén disponibles para los propietarios en un SDA, mientras la aplicación defina quién es el propietario real, se puede utilizar la delegación.
Gobernanza de Flare
Los titulares de tokens FLR votan para gobernar la red, y los SDA también pueden solicitar ser gobernados por los titulares de tokens FLR.
En el documento técnico de Flare se pueden encontrar reglas para cualquier cambio manual en la cadena que pueda ser iniciado y votado por los titulares de FLR. Se trata de cosas como el cambio de las tarifas asociadas a las acciones, el cambio del ratio de garantía, el cambio de los costes de las transacciones y otras variables que no requieren un cambio de código.
Diferentes niveles de gobernanza en la Red Flare. Image via Flare whitepaper.
Para aquellas cosas que sí requieren un cambio de código, como cambiar los parámetros de consenso de la red o añadir una nueva serie temporal al FTSO, se creará Flare Foundation. 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 asociaciones.
Dado que la fundación tiene la función de investigación y desarrollo, se convierte en parte integrante del proceso de actualización del código, construyendo, probando, analizando y luego desplegando cualquier cambio de código propuesto.
La fundación se creará para ser completamente transparente en sus actividades y sus gastos. Publicará un informe bianual sobre sus actividades y gastos. Y lo que es más importante, no está facultada para establecer una agenda, sino que se crea de forma que sólo pueda recibir instrucciones de los titulares de la FLR.
Más información en los documentos técnicos de Flare. Image via Flare.
Debido a esta restricción, la fundación no puede:
contribuir al FTSO de ninguna manera;
utilizar sus token FLR como garantía para cualquier aplicación en la red;
utilizar sus token FLR para votar en cualquier votación de gobierno o ceder sus tokens de FLR a otros para que lo hagan.
Además, los titulares de FLR podrían votar en cualquier momento disolver la fundación, en cuyo caso se le exigiría que concluyera todas sus actividades y quemara cualquiera de sus tokens restantes.
Emisión de FLR y airdop
Flare optó por lanzar sus tokens en lo que denominó una bifurcación de utilidad. Las bifurcaciones tradicionales han dividido a la base de usuarios de una red, con una parte dirigiéndose en su propia dirección, y normalmente adoptando una postura antagónica a la cadena matriz.
Por el contrario, la bifurcación de utilidad pretende añadir valor a la cadena original. Eso es exactamente lo que hace Flare al permitir que XRP continúe ofreciendo una liquidación rápida, fiable y sin confianza, a la vez que aporta contratos inteligentes y la posibilidad de crear conductos sin confianza a otras cadenas de bloques. Es un ejemplo perfecto de aportar un nuevo caso de uso a una cadena de bloques existente.
Flare está creando 100 mil millones de tokens FLR para replicar el número de tokens XRP existentes. La intención inicial es hacer que estos tokens estén disponibles para las direcciones que no son propiedad de Ripple Labs, los fundadores de Ripple, las cuentas de ballenas y cualquier dirección que sea un estafador conocido.
Flare ha hecho las gestiones para que 45 mil millones de FLR puedan ser reclamados por los titulares de XRP, asignándose estos tokens a las direcciones que posean XRP en el momento en que se tome una instantánea de la cadena 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 otros 25 mil millones de FLR se asignan a Flare Networks Limited, que es la organización con fines de lucro que apoya el desarrollo de Flare.
Los titulares de XRP se benefician del airdrop de Spark. Imagen vía RippleCoinNews.com
La asignación se supone que es en un ratio de 1:1, sin embargo, el cálculo real llevó 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 pueden reclamarse 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 exchange que apoye el airdrop será acreditado automáticamente con tokens FLR cuando se distribuyan.
La lista de exchanges que soportan el airdrop incluye Binance, KuCoin, Coinbase, Poloniex y muchos otros. Aquellos que tengan sus XRP en unmonedero propio tendrán que registrar una reclamación, y los tokens FLR se entregarán a la dirección establecida en la reclamación. Habrá una serie de monederos compatibles con FLR a elegir cuando se lance la red principal.
También vale la pena señalar que Flare ha dicho que "Se pueden reclamar los FLR después de que la red se ponga en marcha, pero no más allá de la fecha de 6 meses desde la instantánea". Dado que la instantánea se produjo el 12 de diciembre de 2020, eso indica que la red principal se lanzará antes del 12 de junio de 2021.
Además, no todos los tokens se distribuirán inmediatamente. Flare liberará el 15% de la asignación de tokens cuando se lance la red principal. El resto de FLR se liberará durante los próximos 25-34 meses a un ritmo del 2-4% al mes.
¿Quién está detrás de Flare Networks?
El director general y cofundador de Flare Network es Hugo Philion. Antes de crear Flare fue el fundador del sistema de construcción modular Future Generations. Su formación es en inversiones y es licenciado en Gestión de Inversiones y Riesgos Financieros por la Cass Business School.
Más tarde obtuvo un máster en machine learning por la UCL. También adquirió experiencia trabajando como gestor de carteras 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 vía Flare.
El otro cofundador de Flare y director de tecnología es Sean Rowan. Sean ha estado vinculado al mundo de las cadenas de bloques desde 2015, cuando diseñó protocolos de comunicaciones vehiculares seguras aprovechando una infraestructura de clave pública con colegas de la UCLA y el TCD. Con anterioridad, obtuvo una doble licenciatura en Matemáticas y en Ingeniería Electrónica e Informática en el Trinity College de Dublín.
Más tarde obtuvo un máster en machine learning en la University College London, donde probablemente conoció a Hugo Philion. Sean también fue ingeniero de I+D en RAIL, en Dublín (Irlanda), donde desarrolló un software de red 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
Dado que Ripple tiene tanto un importante número de seguidores como un enorme potencial en el ámbito bancario, la red Flare podría llegar a ser igual de grande al ser la red que aporta la funcionalidad de los contratos inteligentes a XRP. Eso es ciertamente lo que esperan los fundadores del proyecto, y es probable que haya un gran grupo de entusiastas del XRP que estén igualmente entusiasmados con las posibilidades que aporta Flare a Ripple.
Una cosa que se puede decir del proyecto es que ha generado mucho revuelo con su airdrop, y estamos dispuestos a apostar que hay millones de personas que nunca habían oído hablar de Flare y que ahora conocen su existencia, y posiblemente su misión y objetivos. Después de leer este artículo, deberías contarte entre ellos.
El airdrop también creó revuelo dentro de la comunidad de Ripple, ya que el token XRP subió casi un 300% en noviembre de 2020. Esto se debió a que los especuladores se abalanzaron sobre la moneda para aprovechar el lanzamiento aéreo. Desde entonces, las cosas no han sido tan halagüeñas, ya que XRP ha caído desde un máximo de alrededor de 0,90 dólares hasta un mínimo de 0,227880 dólares el 23 de diciembre de 2020.
No sabemos qué pasará con el token FLR cuando se distribuya, pero incluso con el lento calendario de emisión previsto inicialmente parece que el mercado se inundará de tokens FLR en los 2-3 años iniciales tras el lanzamiento de la red principal. A menos que haya algunos desarrollos que causen un pico similar en la demanda durante ese tiempo, el token podría caer, si los mismos especuladores que compraron XRP para el airdrop deciden deshacerse de su FLR tan pronto como sea posible.
Si tienes un horizonte temporal más largo, este podría ser un buen proyecto para tener en cuenta, y si estamos en lo cierto sobre el lanzamiento de la red principal, podría ser una buena oportunidad para conseguir grandes cantidades de FLR a bajo precio. Por supuesto, sólo el tiempo dirá si esto es así.
La otra cosa que hay que recordar es que Flare comenzó con Ripple, pero teóricamente puede añadir funcionalidad de contratos inteligentes e interoperabilidad a cualquier cadena de bloques. Teniendo en cuenta que las tres cuartas partes del valor de los tokens de las cadenas de bloques públicas no se pueden utilizar con contratos inteligentes de forma fiable, actualmente Flare tiene una enorme curva de crecimiento potencial por delante.
Imagen destacada vía Shutterstock
Aviso: Estas son las opiniones del autor y no deben considerarse como un consejo de inversión. Los lectores deben hacer su propia investigación.
El artículo Reseña de Flare network : Red de contratos inteligentes para XRP se publicó en primer lugar en Coin Bureau.
Al ser la tercera criptomoneda más grande, la mayoría de las personas de este mundillo han oído hablar de Ripple y entienden que es una red global de pagos y de intercambio de divisas que fue diseñada para reemplazar la anticuada red bancaria SWIFT. Y aunque se puede decir que funciona muy bien para ese caso de uso específico, lo cierto es que ha mostrado una utilidad limitada en otras funciones.
Este problema podría solucionarse ya que se ha creado Flare Network con el objetivo de mejorar la utilidad de los tokens XRP mediante la creación de una red con capacidad de soportar contratos inteligentes con el token XRP. En realidad, los contratos inteligentes no se están añadiendo a la red Ripple, sino que estarán en la Flare Network, y esa red soportará el uso tanto de XRP como de FXRP.
Desbloqueando el valor de Rippple (XRP). Imagen vía Flare
Flare Network también tiene su propio token llamado Spark (FLR), que fue distribuido recientemente entre los poseedores de XRP en un airdrop que creó un gran revuelo dentro de la comunidad de Ripple.
Si todo esto te suena interesante, entonces coge algo de 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 la cadena de bloques:
Las tres cuartas partes del valor de los tokens de cadenas de bloques públicas no se pueden utilizar con contratos inteligentes de forma fiable. Este es un problema que debe ser resuelto de inmediato, según Philion y Rowan.
Flare Network promete desbloquear el valor atrapado en las cadenas de bloques. Imagen vía Slideshare.net
Las direcciones que se están tomando para intentar escalar las redes de cadenas de bloques podrían conducir a posibles problemas en el futuro, ya que muchas de las nuevas redes están abordando el escalado a través del consenso Prueba de Participacion (PoS) o alguna variación del mismo. Todos estos protocolos derivan lu seguridad de red del token nativo de la cadena de bloques. Esto supone un problema tanto inmediato como a largo plazo.
Problemas de la Prueba de Participación
Según Flare, el problema más inmediato del consenso Prueba de Participación es que no está bien diseñado para permitir usos alternativos seguros de los tokens nativos. Como estamos viendo con la explosión de las plataformas DeFi, cualquier poseedor racional de tokens que pueda aumentar el rendimiento de su token proporcionando liquidez a una moneda estable lo hará. El problema es que esto desincentiva el staking y amenaza la seguridad de la red.
Los sistemas de Prueba de Participación son muy populares. Imagen vía Shutterstock
A largo plazo, el problema potencial proviene de la posibilidad de que, con el tiempo, el valor de un token en staking no aumente. Si esto ocurre a la vez que aumenta el tráfico de la red, ésta se vuelve cada vez más insegura. Aunque un token con mayor valor es bueno para la seguridad de la red y para los inversores en tokens, es malo si queremos que la descentralización se convierta en la norma para hacer negocios.
Cuando el valor del token aumenta, está desviando el capital de otros usos. A largo plazo, esto se convierte en un problema, ya que, en una red de contratos inteligentes que utilice Prueba de Participación, la proporción de capital necesaria para asegurar la red sería demasiado alta para ser viable.
En última instancia, las redes de Prueba de Participación pueden escalar las transacciones, pero son incapaces de escalar el valor.
¿Cómo pretende Flare 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. Aunque la red sigue necesitando un token nativo para disuadir el spam, ese token no está vinculado de ninguna manera a la seguridad de la red. Flare utiliza el token FLR como su token nativo y es muy adecuado para permitir el uso sin confianza de tokens no completos de Turing con contratos inteligentes.
Flare se autodenomina la primera red de Acuerdo Bizantino Federado (FBA, Federated Byzantine Agreement) de Turing completa. Utiliza el protocolo de consenso de Avalanche adaptado al consenso FBA. La ventaja de utilizar FBA es su capacidad para lograr la seguridad de la red sin depender de ningún incentivo económico para los titulares de tokens. Dado que Flare utiliza una versión de la máquina virtual de Ethereum (EVM, Ethereum Virtual Machine), es capaz de ejecutar contratos inteligentes de Turing completos .
Los desarrolladores de Flare adoran el FBA. Imagen vía TowardsDataScience.com
El FBA ha sido criticado porque puede dar lugar a una topología frágil en la que el fallo de un solo nodo puede provocar el fallo de toda la red. Flare evita esto implementando una topología de Lista de Nodos Únicos (UNL, Unique Node List) para enfatizar la claridad y la facilidad de uso mientras se mantiene la propiedad de pertenencia abierta al FBA.
Esta metodología general también puede extenderse a cualquier otro token de Turing no completo, y la capacidad de hacerlo se ha incluido en la gobernanza y en los sistemas de la red. Esto significa que cualquier token de Turing no completo puede eventualmente acceder a la capacidad de utilizar contratos inteligentes y ser interoperable a través de Flare.
Visión general de FXRP
El problema al que se enfrenta el equipo de Flare para llevar XRP a Flare Network es la imposibilidad de que un contrato inteligente de una cadena de bloques pública controle 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 tratara de traer XRP a la red usando sólo código, también requeriría que un grupo de individuos se unieran y usaran una dirección multifirma bajo su control colectivo para autorizar las transacciones. Por supuesto, el FXRP en estas condiciones no estaría descentralizado ni sería confiable. Y eso sería inaceptable.
Conexión entre Ripple y Flare. Imagen vía FXRP Whitepaper
Con la implementación actual de FXRP cualquier poseedor de XRP puede enviar sus tokens a un agente en la red XRP. El agente mantiene 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. Así, por cada 1 FXRP emitido debe haber 2.5 FLR en staking. Esto mantiene la seguridad del XRP en manos del agente y elimina la necesidad de cualquier intermediario centralizado.
¿Cómo funciona el FXRP?
Los propietarios de FLR pueden enviar sus tokens a los contratos inteligentes en Flare que conforman el sistema FXRP. En esencia, esto supone proporcionar una garantía al sistema FXRP. Estos contratos inteligentes se llaman agentes. El sistema FXRP estará compuesto por muchos agentes. Vamos a nombrar a uno de ellos, Guy.
Como agente del sistema FXRP, Guy ha hecho staking de 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 quiere crear FXRP, envía una transacción al sistema FXRP. El titular que inicia esta transacción se llama originador. Para crear FXRP también se paga una tasa del 0.1% del valor de la transacción. La tarifa es para el agente, y la transacción indica al agente a qué dirección debe enviar el FXRP cuando se acuñe y de dónde se originará el XRP a partir del registro de XRP.
Un enfoque transaccional del sistema FXRP. Imagen vía Flare.
Suponiendo que haya suficiente garantía en el sistema FXRP bloqueada para asegurar el FXRP, las transacciones son sin confianza (trustless transactions) ya que el originador no tiene que confiar en el agente, que ahora tiene un incentivo para devolver el XRP cuando se le solicite o perderá el FLR que mantiene como garantía. Si el sistema no tiene suficiente garantía, devolverá el XRP y la comisión al originador.
Es fundamental tener en cuenta que el ratio de garantía de 2.5 debe mantenerse en todo momento. Si en algún momento el valor de XRP sube o el valor de FLR baja de manera que la proporción cae por debajo de 2.5, Guy tendrá un breve lapso de tiempo para restaurar la proporción añadiendo más tokens FLR o comprando tokens de FXRP para poder canjearlos.
Si por alguna razón Guy no puede o no quiere restablecer el ratio de garantía de 2.5, su garantía se subasta para recomprar el FXRP que se emitió contra ella. Si después de esto queda algún tipo de garantía, Guy puede recuperarla.
Si Guy mantiene la garantía a un nivel igual o superior a 2.5, no hay problema. Más tarde, cuando el originador decida canjear el FXRP de vuelta al registro de XRP, necesitará una transacción para hacerlo, informando al sistema de la dirección en la que debe abonarse el XRP. Guy recibirá instrucciones del sistema sobre la cantidad de XRP que debe devolver y a qué dirección debe enviarlo.
Además, se le darán dos plazos para completar la transacción. Si completa la transacción antes del primer plazo, recibirá toda su garantía. Sin embargo, si pasa el primer plazo y completa la transacción antes del segundo plazo, se aplicará una pequeña comisión de penalización antes de que se le devuelva el resto de la garantía. El sistema quema esta comisión de penalización.
Si el agente no devuelve el XRP se trata de un fallo de canje., Imagen vía Flare.
Si Guy no logra completar la transacción en el segundo plazo, se considera un fallo de canje. En este caso, el originador es compensado con tokens FLR del staking de Guy, más un 1% adicional para cubrir los costes de transacción de usar ese FLR para recomprar XRP. El FLR restante del staking Guy se quema en un 50% como penalización, y el 50% restante se devuelve a Guy.
FLR y aplicaciones dependientes
El sistema FXRP es nuestro primer ejemplo de aplicación dependiente de FLR (SDA). Se trata de una aplicación descentralizada que utiliza FLR como garantía, tokens FLR para la gobernanza, el Oráculo de Series Temporales de Flare (FTSO, Flare Time Series Oracle), o alguna combinación de estos elementos. Tenga en cuenta que todos estos elementos son opcionales. Cualquier aplicación en Flare Network es capaz de funcionar utilizando sólo FLR para los costes de transacción y de pago.
El sistema FXRP utiliza FLR como garantía, el FTSO de Flare para rastrear el precio de XRP/FLR y el conjunto de propiedad de tokens de FLR para gobernar ciertos parámetros como la tasa de creación de FXRP y el ratio de garantía. El modelo SDA proporciona una plantilla a los desarrolladores para ampliar el uso de los tres elementos opcionales.
Oráculo de Series Temporales de Flare (FTSO)
Los poseedores del token FLR pueden contribuir al FTSO para ayudar a realizar estimaciones precisas de datos fuera de la cadena, manteniendo la descentralización. La estructura del FTSO permite realizar muchas estimaciones de cualquier serie temporal fuera de la cadena. El valor de XRP/FLR es un ejemplo de dicha serie temporal.
La revolución de los contratos inteligentes. Imagen vía Coil.com
La configuración de los datos de las series temporales suele tener dos grupos de participantes. Uno es el de los titulares del token FLR, y el otro es el de los titulares del token de aplicación dependiente, que Flare denomina F-asset. En el caso del sistema FXRP, el token FXRP es el F-asset. Cuando existe una aplicación más compleja que requiere el cálculo de múltiples series temporales, el F-asset será algo similar a un token de gobierno emitido.
Al crear las series temporales, el FTSO solicitará a cada participante una estimación del valor de los datos. Los titulares de FLR proporcionan estimaciones para cada serie temporal, pero los titulares de F-asset sólo pueden proporcionar una estimación para la serie temporal que está relacionada con dicho F-asset. Las estimaciones se procesan tal y como se detalla en la sección 4 del documento técnico de Flare y el resultado se envía al sistema que requiere los datos de las series temporales.
Los titulares de F-asset 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 puede verse en el documento técnico de Flare.
Versión simplificada de un contrato inteligente
Este sistema hace staking de todos los tokens de FLR, ya que los no participantes o aquellos que proporcionan datos que se consideran incorrectos no obtienen recompensas, lo que supone un desincentivo en comparación con los poseedores de tokens que sí reciben recompensas. Esta es la interpretación de Flare de las recompensas de staking o minería.
El FTSO se lanzará para proporcionar los siguientes precios: XRP/FLR, USD/FLR, BTC/FLR y XLM/FLR. Sólo XRP/FLR tendrá un F-asset al comienzo. Pueden proponerse y aceptarse otras series temporales y sus correspondientes F-assets a través del proceso de gobernanza.
Delegación de FLR
Las estimaciones provendrán del FTSO cada pocos segundos, pero es realista suponer que no todos los titulares de FLR estarán interesados en participar en la gobernanza de la red, o que tendrán el hardware necesario para contribuir al FTSO.
Como el equipo de Flare ha asumido que esto es cierto, han hecho posible desligar los votos de 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 SDAs pueden delegar los votos de vuelta al propietario real, que a su vez puede volver a delegar esos votos a otra entidad. Esto significa que los agentes no tienen que elegir entre ganar FLR por proporcionar una garantía al sistema FXRP o ganar del FTSO. Por lo tanto, siempre que los tokens FLR no estén disponibles para los propietarios en un SDA, mientras la aplicación defina quién es el propietario real, se puede utilizar la delegación.
Gobernanza de Flare
Los titulares de tokens FLR votan para gobernar la red, y los SDA también pueden solicitar ser gobernados por los titulares de tokens FLR.
En el documento técnico de Flare se pueden encontrar reglas para cualquier cambio manual en la cadena que pueda ser iniciado y votado por los titulares de FLR. Se trata de cosas como el cambio de las tarifas asociadas a las acciones, el cambio del ratio de garantía, el cambio de los costes de las transacciones y otras variables que no requieren un cambio de código.
Diferentes niveles de gobernanza en la Red Flare. Image via Flare whitepaper.
Para aquellas cosas que sí requieren un cambio de código, como cambiar los parámetros de consenso de la red o añadir una nueva serie temporal al FTSO, se creará Flare Foundation. 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 asociaciones.
Dado que la fundación tiene la función de investigación y desarrollo, se convierte en parte integrante del proceso de actualización del código, construyendo, probando, analizando y luego desplegando cualquier cambio de código propuesto.
La fundación se creará para ser completamente transparente en sus actividades y sus gastos. Publicará un informe bianual sobre sus actividades y gastos. Y lo que es más importante, no está facultada para establecer una agenda, sino que se crea de forma que sólo pueda recibir instrucciones de los titulares de la FLR.
Más información en los documentos técnicos de Flare. Image via Flare.
Debido a esta restricción, la fundación no puede:
contribuir al FTSO de ninguna manera;
utilizar sus token FLR como garantía para cualquier aplicación en la red;
utilizar sus token FLR para votar en cualquier votación de gobierno o ceder sus tokens de FLR a otros para que lo hagan.
Además, los titulares de FLR podrían votar en cualquier momento disolver la fundación, en cuyo caso se le exigiría que concluyera todas sus actividades y quemara cualquiera de sus tokens restantes.
Emisión de FLR y airdop
Flare optó por lanzar sus tokens en lo que denominó una bifurcación de utilidad. Las bifurcaciones tradicionales han dividido a la base de usuarios de una red, con una parte dirigiéndose en su propia dirección, y normalmente adoptando una postura antagónica a la cadena matriz.
Por el contrario, la bifurcación de utilidad pretende añadir valor a la cadena original. Eso es exactamente lo que hace Flare al permitir que XRP continúe ofreciendo una liquidación rápida, fiable y sin confianza, a la vez que aporta contratos inteligentes y la posibilidad de crear conductos sin confianza a otras cadenas de bloques. Es un ejemplo perfecto de aportar un nuevo caso de uso a una cadena de bloques existente.
Flare está creando 100 mil millones de tokens FLR para replicar el número de tokens XRP existentes. La intención inicial es hacer que estos tokens estén disponibles para las direcciones que no son propiedad de Ripple Labs, los fundadores de Ripple, las cuentas de ballenas y cualquier dirección que sea un estafador conocido.
Flare ha hecho las gestiones para que 45 mil millones de FLR puedan ser reclamados por los titulares de XRP, asignándose estos tokens a las direcciones que posean XRP en el momento en que se tome una instantánea de la cadena 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 otros 25 mil millones de FLR se asignan a Flare Networks Limited, que es la organización con fines de lucro que apoya el desarrollo de Flare.
Los titulares de XRP se benefician del airdrop de Spark. Imagen vía RippleCoinNews.com
La asignación se supone que es en un ratio de 1:1, sin embargo, el cálculo real llevó 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 pueden reclamarse 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 exchange que apoye el airdrop será acreditado automáticamente con tokens FLR cuando se distribuyan.
La lista de exchanges que soportan el airdrop incluye Binance, KuCoin, Coinbase, Poloniex y muchos otros. Aquellos que tengan sus XRP en unmonedero propio tendrán que registrar una reclamación, y los tokens FLR se entregarán a la dirección establecida en la reclamación. Habrá una serie de monederos compatibles con FLR a elegir cuando se lance la red principal.
También vale la pena señalar que Flare ha dicho que "Se pueden reclamar los FLR después de que la red se ponga en marcha, pero no más allá de la fecha de 6 meses desde la instantánea". Dado que la instantánea se produjo el 12 de diciembre de 2020, eso indica que la red principal se lanzará antes del 12 de junio de 2021.
Además, no todos los tokens se distribuirán inmediatamente. Flare liberará el 15% de la asignación de tokens cuando se lance la red principal. El resto de FLR se liberará durante los próximos 25-34 meses a un ritmo del 2-4% al mes.
¿Quién está detrás de Flare Networks?
El director general y cofundador de Flare Network es Hugo Philion. Antes de crear Flare fue el fundador del sistema de construcción modular Future Generations. Su formación es en inversiones y es licenciado en Gestión de Inversiones y Riesgos Financieros por la Cass Business School.
Más tarde obtuvo un máster en machine learning por la UCL. También adquirió experiencia trabajando como gestor de carteras 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 vía Flare.
El otro cofundador de Flare y director de tecnología es Sean Rowan. Sean ha estado vinculado al mundo de las cadenas de bloques desde 2015, cuando diseñó protocolos de comunicaciones vehiculares seguras aprovechando una infraestructura de clave pública con colegas de la UCLA y el TCD. Con anterioridad, obtuvo una doble licenciatura en Matemáticas y en Ingeniería Electrónica e Informática en el Trinity College de Dublín.
Más tarde obtuvo un máster en machine learning en la University College London, donde probablemente conoció a Hugo Philion. Sean también fue ingeniero de I+D en RAIL, en Dublín (Irlanda), donde desarrolló un software de red 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
Dado que Ripple tiene tanto un importante número de seguidores como un enorme potencial en el ámbito bancario, la red Flare podría llegar a ser igual de grande al ser la red que aporta la funcionalidad de los contratos inteligentes a XRP. Eso es ciertamente lo que esperan los fundadores del proyecto, y es probable que haya un gran grupo de entusiastas del XRP que estén igualmente entusiasmados con las posibilidades que aporta Flare a Ripple.
Una cosa que se puede decir del proyecto es que ha generado mucho revuelo con su airdrop, y estamos dispuestos a apostar que hay millones de personas que nunca habían oído hablar de Flare y que ahora conocen su existencia, y posiblemente su misión y objetivos. Después de leer este artículo, deberías contarte entre ellos.
El airdrop también creó revuelo dentro de la comunidad de Ripple, ya que el token XRP subió casi un 300% en noviembre de 2020. Esto se debió a que los especuladores se abalanzaron sobre la moneda para aprovechar el lanzamiento aéreo. Desde entonces, las cosas no han sido tan halagüeñas, ya que XRP ha caído desde un máximo de alrededor de 0,90 dólares hasta un mínimo de 0,227880 dólares el 23 de diciembre de 2020.
No sabemos qué pasará con el token FLR cuando se distribuya, pero incluso con el lento calendario de emisión previsto inicialmente parece que el mercado se inundará de tokens FLR en los 2-3 años iniciales tras el lanzamiento de la red principal. A menos que haya algunos desarrollos que causen un pico similar en la demanda durante ese tiempo, el token podría caer, si los mismos especuladores que compraron XRP para el airdrop deciden deshacerse de su FLR tan pronto como sea posible.
Si tienes un horizonte temporal más largo, este podría ser un buen proyecto para tener en cuenta, y si estamos en lo cierto sobre el lanzamiento de la red principal, podría ser una buena oportunidad para conseguir grandes cantidades de FLR a bajo precio. Por supuesto, sólo el tiempo dirá si esto es así.
La otra cosa que hay que recordar es que Flare comenzó con Ripple, pero teóricamente puede añadir funcionalidad de contratos inteligentes e interoperabilidad a cualquier cadena de bloques. Teniendo en cuenta que las tres cuartas partes del valor de los tokens de las cadenas de bloques públicas no se pueden utilizar con contratos inteligentes de forma fiable, actualmente Flare tiene una enorme curva de crecimiento potencial por delante.
Imagen destacada vía Shutterstock
Aviso: Estas son las opiniones del autor y no deben considerarse como un consejo de inversión. Los lectores deben hacer su propia investigación.
El artículo Reseña de Flare network : Red de contratos inteligentes para XRP se publicó en primer lugar en Coin Bureau.
