Flare Network Review: Smart Contract Network for XRP

Som den tredje største kryptovalutaen har de fleste som er kjent med plassen hørt om Ripple, og de forstår at det er et globalt betalings- og valutanettverk som er designet for å erstatte det utdaterte SWIFT-banknettverket. Og mens det fungerer bra for den spesifikke brukssaken, ellers har det vist begrenset nytte i andre funksjoner.

Alt dette kan imidlertid løses ettersom Flare-nettverket er opprettet med det mål å forbedre bruken av XRP-tokens ved å opprette et nettverk med smart kontraktsevne for XRP-token. For å være sikker blir ikke smarte kontrakter lagt til Ripple-nettverket, men vil være på Flare-nettverket, og det nettverket vil da støtte bruken av XRP som FXRP.

Flare Networks

Lås opp verdi for Rippple (XRP). Bilde via Bluss

Flare-nettverket har også sitt eget token kalt Spark (FLR), som nylig ble utgitt til XRP-holdere i en luftdråpe som skapte en stor opprør i Ripple-samfunnet.

Hvis alt dette høres interessant ut, kan du ta deg noe å drikke og gjøre deg klar til å lære mer om Flare Network.

Hva er Flare?

Flare ble opprettet av Hugo Philion og Sean Rowan for å løse to grunnleggende blockchain-problemer:

  1. Tre fjerdedeler av verdien i offentlige blockchain-tokens kan ikke brukes med smarte kontrakter på en tillitsløs måte. Dette er spørsmålet om umiddelbar behov ifølge Philion og Rowan.

    Låse opp verdi

    Flare Network lover å låse opp verdien som er fanget i blokkjeder. Bilde via Slideshare.net

  2. Retningslinjene som tas i forsøk på å skalere blockchain-nettverk kan føre til potensielle fremtidige problemer, ettersom mange av de nye nettverkene adresserer skalering gjennom Proof of Stake-konsensus eller en viss variasjon derav. Alle disse protokollene henter deres nettverkssikkerhet fra blockchainens opprinnelige token. Dette gir både et øyeblikkelig og et langsiktig problem.

Bevis for innsatsproblemer

Ifølge Flare er det mest umiddelbare problemet med Proof of Stake-konsensus at det ikke er riktig designet for å tillate sikker alternativ bruk av de innfødte tokens. Som vi ser med eksplosjonen i DeFi-plattformer, vil enhver rasjonell tokenholder som er i stand til å øke avkastningen på token deres ved å gi likviditet til en stablecoin, det. Problemet er at dette tar tokens vekk fra staking, og truer sikkerheten til nettverket.

Bevis for innsatsbluss

Proof of Stake-systemer er veldig populære. Bilde via Shutterstock

På lengre sikt kommer det potensielle problemet fra muligheten for at verdien av et staking token over tid ikke vil øke i verdi. Hvis det skjer mens nettverkstrafikken øker, blir nettverket også stadig mer utrygt. Selv om et token med høyere verdi er bra for nettverkssikkerhet og for tokeninvestorer, er det ille hvis vi vil at desentralisering skal bli normen for å drive forretning..

Når verdien av tokenet stiger, leder den kapitalen bort fra andre bruksområder. På lang sikt blir dette et problem fordi til slutt i et smart kontraktsnettverk som bruker bevis på innsatsen, skal kapitalen som trengs bare for å sikre nettverket bli for høy til å være mulig.

Til slutt kan Proof of Stake-nettverk skalere for transaksjoner, men de kan ikke skalere for verdi.

Hvordan bluss har som mål å løse disse problemene

Flare foreslår en ny måte å skalere smarte kontraktplattformer uten å knytte sikkerheten til nettverket til verdien av tokenet. Selv om nettverket fremdeles krever et innfødt token for å avskrekke spam, er det token ikke på noen måte knyttet til nettverkets sikkerhet. Flare bruker FLR-token som sitt opprinnelige token, og det er godt egnet til å muliggjøre pålitelig bruk av ikke-Turing komplette tokens med smarte kontrakter.

Flare kaller seg det første Turing-nettverket for Federated Byzantine Agreement (FBA). Den bruker Avalanche-konsensusprotokollen som er tilpasset FBA-konsensus. Fordelen med å bruke FBA ligger i dets evne til å oppnå nettverkssikkerhet uten å stole på økonomiske insentiver for innehavere. Fordi Flare bruker en versjon av Ethereum Virtual Machine (EVM), er den i stand til å kjøre Turing komplette smarte kontrakter.

Federated Byzantine Agreement

Flare-utviklere elsker FBA. Bilde via TowardsDataScience.com

FBA har blitt kritisert fordi det kan føre til skjøre topologi der svikt i en enkelt node kan føre til svikt i hele nettverket. Flare unngår dette ved å implementere en UNL-topologi (Unique Node List) for å understreke klarhet og brukervennlighet og samtidig opprettholde FBAs åpne medlemsegenskap..

Mens Flare muliggjør Turing fullstendig smart kontraktsbruk, har den også en protokoll bygget på toppen av nettverket som tillater tillitsløs utstedelse, bruk og innløsning av XRP on Flare. Flare kaller denne protokollen FXRP, og det gjør at XRP kan bli FXRP på Flare, sikret av det opprinnelige FLR-tokenet. I hovedsak gjør dette at XRP kan bruke smarte kontrakter, og kan også skape en pålitelig rørledning for XRP til andre nettverk for interoperabilitetsformål..

Denne generelle metoden kan også utvides til alle andre ikke-Turing komplette tokener, og muligheten til å gjøre det har blitt inkludert i styringen og systemene i nettverket. Dette betyr at ethvert ikke-Turing komplett token til slutt kan få tilgang til muligheten til å bruke smarte kontrakter og bli interoperabil gjennom Flare.

FXRP Oversikt

Problemet som Flare-teamet står overfor med å bringe XRP til Flare-nettverket, er umuligheten av en offentlig blockchain-smartkontrakt for å kontrollere en XRP-adresse. Dette er fordi smarte kontrakter ikke har noen måte å lagre en hemmelig nøkkel og opprettholde hemmeligholdet.

Hvis Flare prøvde å bringe XRP til nettverket ved å bruke bare kode, ville det også kreve at en gruppe individer skulle komme sammen og bruke en multi-signatur-adresse de samlet kontrollerer for å autorisere transaksjoner. Selvfølgelig vil dette bety at FXRP under disse forholdene verken vil være desentralisert eller pålitelig. Og det ville være uakseptabelt.

FXRP-system

Forbindelse mellom Ripple og Flare. Bilde via FXRP Whitepaper

Med den nåværende implementeringen av FXRP kan enhver XRP-holder sende tokens til en agent på XRP-nettverket. Agenten har XRP og kommuniserer med smarte kontrakter på Flare, som utsteder FXRP i forholdet 1: 1. Disse FXRP-tokens er også sikret med FLR i forholdet 1: 2,5. Så for hver 1 FXRP som utstedes, må det være 2,5 FLR staked. Dette holder XRP holdt av agenten sikker, og det fjerner behovet for et sentralisert mellommann.

Hvordan fungerer FXRP?

Eiere av FLR er i stand til å sende tokens til smarte kontrakter på Flare som utgjør FXRP-systemet. I hovedsak gir dette sikkerheter til FXRP-systemet. Disse smarte kontraktene kalles agenter. FXRP-systemet vil være sammensatt av mange agenter. La oss nevne en av dem Guy.

Som agent i FXRP-systemet har Guy stilt 5000 FLR som sikkerhet. Systemet krever 2,5 FLR for hvert utstedt FXRP-token. Hvis valutakursen mellom FLR og XRP for øyeblikket er 10: 1, vil disse 5000 FLR tillate Guy å utstede 200 FXRP. dvs. (5.000/10) / 2.5

Nå er Guy klar til å lage FXRP. Når en XRP-innehaver ønsker å lage FXRP, sender de en transaksjon til FXRP-systemet. Innehaveren som starter denne transaksjonen kalles opphavsmann. For å lage FXRP betaler de også et gebyr på 0,1% av transaksjonsverdien. Gebyret går til agenten, og transaksjonen forteller agenten hvilken adresse den skal sende FXRP til når den er myntet og hvor XRP vil stamme fra på XRP Ledger.

FXRP-transaksjon

En transaksjonell tilnærming til FXRP-systemet. Bilde via Bluss.

Forutsatt at det er tilstrekkelig sikkerhet i FXRP-systemet, er det låst for å sikre FXRP, noe som gjør transaksjonen pålitelig fordi opphavsmannen ikke trenger å stole på agenten som nå har et insentiv til å returnere XRP når du blir bedt om å gjøre det eller miste FLR som holdes som sikkerhet. Hvis systemet ikke har nok sikkerhet, vil det returnere XRP og gebyret til opphavsmannen.

Det er viktig å merke seg at sikkerhetsgraden på 2,5 må opprettholdes til enhver tid. Hvis verdien av XRP når som helst stiger eller verdien av FLR faller slik at rasjonen faller under 2,5 Guy, vil Guy ha en kort periode på å gjenopprette forholdet ved å legge til flere FLR-tokens eller kjøpe FXRP-tokens for å løse inn.

Hvis Guy av en eller annen grunn ikke er i stand til eller ikke er villig til å gjenopprette sikkerhetsforholdet på 2,5, auksjoneres hans sikkerhet for å tilbakekjøpe FXRP som ble utstedt mot den. Hvis det gjenstår noen sikkerhet etter at denne fyren er i stand til å beholde den resterende.

Hvis Guy holder sikkerheten på eller over 2,5, er alt bra. Senere når opphavsmannen bestemmer seg for å innløse FXRP tilbake til XRP-hovedboken, foretar de en transaksjon for å gjøre det, slik at systemet får vite hvilken adresse som skal krediteres XRP. Guy vil motta instruksjoner fra systemet om hvor mye XRP du skal returnere og hvilken adresse du skal sende den til.

Sammen med det vil han også motta to frister som transaksjonen må fullføres. Hvis han fullfører transaksjonen før den første fristen, vil han motta all sikkerheten tilbake. Men hvis den første fristen går ut, og han fullfører transaksjonen innen den andre fristen, vil det bli vurdert et lite straffegebyr før resten av sikkerheten hans returneres. Straffereavgiften blir brent av systemet.

FXRP-innløsningsfeil

Hvis agenten ikke returnerer XRP, er det en innløsningsfeil, Image via Flare.

Hvis Guy ikke klarer å fullføre transaksjonen innen den andre fristen, regnes det som en innløsningsfeil. I dette tilfellet kompenseres opphavsmannen med FLR-tokens fra Guy’s eierandel, pluss ytterligere 1% for å dekke transaksjonskostnadene ved å bruke FLR til å kjøpe tilbake XRP. Den gjenværende FLR fra Guy’s sikkerhet ser 50% brent som en straff, og de resterende 50% returnerte til Guy.

FLR og avhengige applikasjoner

FXRP-systemet er vårt første eksempel på FLR Dependent Application (SDA). Dette er en dApp som bruker FLR som sikkerhet, FLR-tokenholdere for styring, Flare Time Series Oracle (FTSO), eller en kombinasjon av disse elementene. Merk at dette alle er valgfrie elementer. Enhver applikasjon på Flare Network kan fungere ved å bruke bare FLR for transaksjons- og betalingskostnader.

I tilfelle av FXRP-systemet bruker det FLR som sikkerhet, Flare Time Series Oracle for å spore XRP / FLR-prisen, og FLR-token eierskap satt for styring over visse parametere som FXRP-etableringsgebyr og sikkerhetsforholdet. SDA-modellen gir en mal til utviklere for å utvide bruken av de tre valgfrie elementene.

Flare tidsserie Oracle

Innehavere av FLR-token er kvalifisert til å bidra til FTSO for å bidra til å danne nøyaktige off-chain dataestimater mens de fremdeles beholder desentralisering. Strukturen til FTSO tillater mange estimater av alle tidsserier utenfor kjeden. XRP / FLR-verdien er et eksempel på en slik tidsserie.

Smarte kontrakter på bluss

Revolusjonen av smarte kontrakter. Bilde via Coil.com

Formuleringen av tidsseriedataene har vanligvis to deltakende grupper. Den ene er FLR-tokenholdere, og den andre er innehaverne av det avhengige applikasjonstokenet, som Flare kaller F-eiendelen. Når det gjelder FXRP-systemet, er FXRP-token F-aktiva. Når det er en mer kompleks applikasjon som krever beregning av flere tidsserier, vil F-eiendelen være noe som ligner på et utstedt styringstoken.

Når du lager tidsserien, vil FTSO spørre hver deltaker om et estimat av dataverdien. FLR-eierne gir estimater for hver tidsserie, men F-eiendomsinnehavere kan bare gi et estimat for tidsseriene som er relatert til F-eiendelen. Anslagene behandles som beskrevet i avsnitt 4 i Flare whitepaper og resultatet sendes ut til systemet som krever tidsseriedata.

Innehavere av F-eiendeler insentiveres til å delta og levere data for å bidra til sikkerheten til applikasjonen ved hjelp av disse dataene. FLR-holdere blir oppmuntret av potensialet til å tjene en orakelbelønning, som er FLR-tokens preget av systemet. FLR-tokenholdere tjener denne belønningen når de leverer data som systemet anser for å være korrekte. Den spesifikke mekanikken i denne beregningen er ganske kompleks, og kan sees i Flare-papiret.

Smart kontrakt forenklet

Forenklet versjon av en smart kontrakt

Dette systemet setter implisitt alle FLR-tokens i systemet siden ikke-deltakere eller de som leverer data som anses som uriktige, ikke tjener belønninger, noe som er avskrekkende sammenlignet med tokenholdere som mottar belønningen. Dette er Flares versjon av staking eller gruvedrift.

FTSO vil bli initiert for å gi følgende priser for: XRP / FLR, USD / FLR, BTC / FLR og XLM / FLR. Bare XRP / FLR vil ha en tilsvarende F-ressurs i begynnelsen. Ytterligere tidsserier og tilhørende F-eiendeler kan foreslås og aksepteres gjennom styringsprosessen.

FLR-delegasjonen

Anslag vil komme fra FTSO med noen få sekunders mellomrom, men det er realistisk å anta at ikke alle FLR-innehavere vil være interessert i å delta i nettverksstyring, eller at de vil ha den nødvendige maskinvaren for å bidra til FTSO.

Fordi Flare-teamet har antatt at dette er sant, gjorde de det mulig å løsne stemmene for dette ansvaret og delegere det til andre. Delegering kan avbrytes når som helst, og hvis tokenet overføres til en ny adresse, blir delegasjonen automatisk kansellert.

Et viktig trekk ved delegering er at SDA-ene er i stand til å delegere stemmer tilbake til den faktiske eieren som deretter kan delegere disse stemmene til en annen enhet. Dette betyr at agenter ikke trenger å velge mellom å tjene FLR for å stille sikkerhet til FXRP-systemet eller å tjene fra FTSO. Så når FLR-tokens blir utilgjengelige for eierne i en SDA, så lenge applikasjonen definerer hvem den faktiske eieren er, kan delegering brukes.

Blussstyring

FLR-tokenholdere stemmer for å styre nettverket, og SDA-er kan også be om å bli styrt av FLR-tokenholdere.

I whitepaper for Flare finner du regimer for eventuelle manuelle endringer i kjeden som kan initieres og stemmes om av FLR-innehavere. Dette er ting som å endre gebyrene knyttet til handlinger, endre sikkerhetsgraden, endre transaksjonskostnader og andre variabler som ikke krever kodeendring.

Blussstyring

Ulike styringsnivåer på Flare Network. Bilde via Flare-papir.

For de tingene som krever kodeendring, for eksempel å endre nettverkskonsensusparametere, eller legge til en ny tidsserie i FTSO, vil det bli opprettet en Flare Foundation. Stiftelsen er ikke opprettet ennå, men det vil være en ideell enhet med ansvar for fem områder: tilskudd, investeringer, forskning og utvikling, utdanning, publisitet og partnerskap.

Fordi stiftelsen har forsknings- og utviklingsfunksjon, blir de integrerte i kodeoppdateringsprosessen, bygger, tester, analyserer og deretter distribuerer eventuelle foreslåtte kodeendringer.

Stiftelsen vil bli opprettet for å være helt gjennomsiktig i sine aktiviteter og sine utgifter. Den vil gi ut en halvårlig rapport om sine aktiviteter og utgifter. Viktigst er det ikke bemyndiget til å sette en agenda, men er skapt på en måte som bare gjør det mulig å ta retning fra FLR-innehaverne.

Flare Foundation

Lær mer i Flare-papirene. Bilde via bluss.

På grunn av denne begrensningen kan ikke stiftelsen:

  • bidra til FTSO på noen måte;
  • distribuere noen av sine FLR-beholdninger som sikkerhet for ethvert program på nettverket;
  • bruke sine FLR-beholdninger til å stemme i enhver styringsstemme eller tildele FLR-tokens til andre for å gjøre det.

I tillegg kan FLR-holdere når som helst stemme for å oppløse stiftelsen, i så fall vil det være nødvendig å avvikle alle aktiviteter og brenne noen av de gjenværende tokens..

FLR-utstedelse og Airdrop

Flare valgte å frigjøre tokens i noe den kalte som en verktøygaffel. Tradisjonelle gafler har delt brukerbasen til et nettverk, med en del som går i sin egen retning, og tar vanligvis en antagonistisk holdning til foreldrekjeden.

Derimot er verktøygaffelen ment å gi verdi til den opprinnelige kjeden. Det er akkurat det Flare gjør ved å la XRP fortsette å levere rask, pålitelig og pålitelig avregning samtidig som den gir smarte kontrakter og muligheten til å lage tillitsløse rørledninger til andre blokkjeder. Det er et perfekt eksempel på å bringe nytt verktøy til en eksisterende blockchain.

Flare lager 100 milliarder FLR-tokens for å speile antallet XRP-tokens som eksisterer. Hensikten i starten er å gjøre disse tokens tilgjengelige for adresser som ikke eies av Ripple Labs, Ripple-grunnleggere, hvalkontoer og andre adresser som er kjent svindlere.

Flare har gjort 45 milliarder FLR krav fra XRP-innehavere, med disse tokens tildelt adresser som holder XRP på det tidspunktet et øyeblikksbilde av Ledger ble tatt kl 00:00 GMT den 12. desember 2020. I tillegg tildeles 30 milliarder FLR til Flare Foundation , og ytterligere 25 milliarder FLR tildeles Flare Networks Limited, som er den profittorganisasjonen som støtter Flares utvikling.

Spark Airdrop

XRP-holdere drar nytte av Spark airdrop. Bilde via RippleCoinNews.com

Tildelingen er imidlertid ment å være på 1: 1-basis selve beregningen førte til et fordelingsforhold på 1.0073 FLR for hver XRP på øyeblikksbildet. I tillegg kan ikke tokens hevdes før mainnet settes i live, noe som antas å forekomme de første ukene i juni 2021. Alle som har XRP-tokens på en sentral som støtter airdrop, blir automatisk kreditert FLR-tokens når de distribueres.

Listen over støttende børser inkluderer Binance, KuCoin, Coinbase, Poloniex og mange andre. De som holder XRP-en i en egenbevarende lommebok, må registrere et krav, og FLR-tokens blir levert til adressen som er angitt i kravet. Det vil være en rekke FLR-kompatible lommebøker å velge mellom når mainnet lanseres.

Det er også verdt å merke seg at Flare har sagt “Du kan kreve FLR etter at nettverket går live, men ikke etter 6 måneders datoen fra øyeblikksbildet. ” Siden øyeblikksbildet skjedde 12. desember 2020 som indikerer at mainnet vil starte før 12. juni 2021.

I tillegg distribueres ikke alle tokens umiddelbart. Flare vil slippe 15% av token tildelingen når mainnet starter. Den gjenværende FLR vil bli frigitt i løpet av de neste 25-34 månedene med en hastighet på 2-4% per måned.

Hvem som står bak blussnettverk?

Administrerende direktør og en medstifter av Flare Network er Hugo Philion. Før han opprettet Flare var han grunnleggeren av det modulære byggesystemet, Future Generations. Hans bakgrunn er i investeringer, og han har en bachelorgrad i investering og finansiell risikostyring fra Cass Business School.

Senere mottok han en Master of Science in Machine Learning fra UCL. Han fikk også erfaring med å arbeide som porteføljeforvalter for råvarederivater for to fond på $ 1 milliard.

Flare Grunnleggere

Hugo og Sean, medstifterne av Flare. Bilde via bluss.

Den andre medstifteren av Flare og CTO er Sean Rowan. Sean har vært involvert i blockchain-rommet siden 2015 da han designet sikre kommunikasjonsprotokoller for kjøretøyer som utnyttet en blockchain-basert offentlig nøkkelinfrastruktur med kolleger ved UCLA og TCD. Før det fikk han dobbelt BA i matematikk og BE i elektronikk og datateknikk fra Trinity College Dublin.

Han fortsatte senere med en Master of Science in Machine Learning fra University College London, som antagelig er der han møtte Hugo Philion. Sean var også en R&D Ingeniør ved RAIL i Dublin, Irland hvor han utviklet backend-nettverksprogramvare for en helseassistent robot. Den siste versjonen av denne roboten fra RAIL vises på forsiden av tidsskriftet TIME i november 2019.

Konklusjon

Med Ripple som har et så stort følge, og et stort potensiale i bankområdet, kan Flare Network bli like stort som nettverket som bringer smart kontraktsfunksjonalitet til XRP. Det er absolutt det grunnleggerne av prosjektet håper, og det er sannsynligvis en stor gruppe XRP-entusiaster som er like entusiastiske over mulighetene som Flare bringer til Ripple.

En ting som kan sies for prosjektet er at det absolutt genererte mye hype med airdrop, og vi er villige til å satse på at det er millioner som aldri har hørt om Flare før, som nå er klar over dets eksistens og muligens oppdrag og mål. Etter å ha lest denne artikkelen, bør du regnes blant dem.

Airdrop skapte også opprør i Ripple-samfunnet da XRP-token steg høyere med nesten 300% i november 2020. Det skyldtes spekulanter som trengte seg inn i mynten for å dra nytte av airdrop. Siden da har ting ikke vært så rosenrødt som XRP har falt fra en høyde på rundt $ 0,90 til så lave som $ 0,227880 den 23. desember 2020.

Vi vet ikke hva som vil skje med FLR-token når den distribueres, men selv med den planlagte planen for langsom utslipp, ser det ut til at markedet vil bli oversvømmet med FLR-tokens de første 2-3 årene etter lanseringen av mainnet . Med mindre det er noen utviklinger som forårsaker en lignende økning i etterspørselen i løpet av den tiden, kan symbolet være klar til å falle, da de samme spekulantene som kjøpte XRP for airdrop, bestemmer seg for å dumpe FLR så snart som mulig..

Hvis du tar en lengre tidshorisont, kan dette være et godt prosjekt å komme bak, og hvis vi har rett i lanseringen av mainnet, kan det være en god mulighet til å fange opp store poser med FLR til en billig pris. Selvfølgelig vil bare tiden vise om det er sant.

Den andre tingen å huske er at Flare begynte med Ripple, men teoretisk kan det legge til smart kontraktsfunksjonalitet og interoperabilitet til enhver blockchain. Tatt i betraktning at tre fjerdedeler av verdien i offentlige blockchain-tokens ikke kan brukes med smarte kontrakter på en tillitsløs måte, har Flare for tiden en enorm potensiell vekstkurve fremover.

Utvalgt bilde via Shutterstock

Ansvarsfraskrivelse: Dette er forfatterens meninger og bør ikke betraktes som investeringsråd. Leserne bør gjøre sine egne undersøkelser.

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me