Flare Network Review: Smart Contract Network til XRP

Som den tredje største kryptokurrency har de fleste mennesker, der er fortrolige med rummet, hørt om Ripple, og de forstår, at det er et globalt betalings- og valutanetværk, der er designet til at erstatte det forældede SWIFT-banknetværk. Og mens det fungerer godt til den specifikke brugssag, har det ellers vist begrænset anvendelighed i andre funktioner.

Alt dette kan dog løses, da Flare-netværket er oprettet med det mål at forbedre XRP-tokens nytte ved at oprette et netværk med smart kontraktfunktion til XRP-token. For at være sikker tilføjes de smarte kontrakter ikke til Ripple-netværket, men vil være på Flare-netværket, og det netværk understøtter derefter brugen af ​​XRP som FXRP.

Flare-netværk

Lås op for værdi for Rippple (XRP). Billede via Flare

Flare-netværket har også sit eget token kaldet Spark (FLR), som for nylig blev frigivet til XRP-indehavere i en luftdrop, der skabte en hel del oprør i Ripple-samfundet.

Hvis alt dette lyder interessant, så tag dig selv noget at drikke og gør dig klar til at lære mere om Flare Network.

Hvad er Flare?

Flare blev skabt af Hugo Philion og Sean Rowan for at løse to grundlæggende blockchain-problemer:

  1. Tre fjerdedele af værdien i offentlige blockchain-tokens kan ikke bruges med smarte kontrakter på en tillidsløs måde. Dette er spørgsmålet om øjeblikkeligt behov ifølge Philion og Rowan.

    Låse op for værdi

    Flare Network lover at låse op for den værdi, der er fanget i blokkæder. Billede via Slideshare.net

  2. Retningen, der tages i forsøget på at skalere blockchain-netværk, kan føre til potentielle fremtidige problemer, da mange af de nye netværk adresserer skalering gennem Bevis for indsats konsensus eller en eller anden variation deraf. Alle disse protokoller udleder deres netværkssikkerhed fra blockchains oprindelige token. Dette udgør både et øjeblikkeligt og et langsigtet problem.

Bevis for problemer med staven

Ifølge Flare er det mest øjeblikkelige problem med Proof of Stake-konsensus, at det ikke er korrekt designet til at muliggøre sikker alternativ anvendelse af de oprindelige tokens. Som vi ser med eksplosionen i DeFi-platforme, vil enhver rationel tokenholder, der er i stand til at øge udbyttet på deres token ved at give likviditet til en stablecoin, det. Spørgsmålet er, at dette tager poletter væk fra indsatsen, og truer netværkets sikkerhed.

Bevis for stavflare

Bevis for stakesystemer er meget populære. Billede via Shutterstock

På længere sigt kommer det potentielle problem fra muligheden for, at værdien af ​​et staking-token over tid ikke stiger i værdi. Hvis det sker, mens netværkstrafikken øges, bliver netværket også stadig mere usikkert. Mens et token med højere værdi er godt for netværkssikkerhed og for tokeninvestorer, er det dårligt, hvis vi vil have decentralisering til at blive normen for at drive forretning.

Når værdien af ​​tokenet stiger, omdirigerer den kapital væk fra andre anvendelser. På lang sigt bliver dette et problem, fordi i sidste ende i et smart kontraktnetværk, der bruger bevis på indsatsen, skal den kapital, der er nødvendig, blot for at sikre netværket, blive for høj til at være mulig.

I sidste ende kan Proof of Stake-netværk skalere for transaktioner, men de kan ikke skalere for værdi.

Hvordan Flare sigter mod at løse disse problemer

Flare foreslår en ny måde at skalere smarte kontraktplatforme på uden at forbinde sikkerheden på netværket med værdien af ​​tokenet. Mens netværket stadig kræver et oprindeligt token for at afskrække spam, er dette token på ingen måde knyttet til netværkssikkerheden. Flare bruger FLR-token som sit oprindelige token, og det er velegnet til at muliggøre den tillidsløse brug af ikke-Turing-komplette tokens med smarte kontrakter.

Flare kalder sig det første Turing-komplette Federated Byzantine Agreement (FBA) netværk. Det bruger Avalanche-konsensusprotokollen, der er tilpasset FBA-konsensus. Fordelen ved at bruge FBA ligger i dets evne til at opnå netværkssikkerhed uden at stole på økonomiske incitamenter for indehavere. Fordi Flare bruger en version af Ethereum Virtual Machine (EVM), er den i stand til at køre Turing komplette smarte kontrakter.

Federeret byzantinsk aftale

Flare-udviklere elsker FBA. Billede via TowardsDataScience.com

FBA er blevet kritiseret, fordi det kan føre til skrøbelig topologi, hvor svigt i en enkelt knude kan forårsage svigt i hele netværket. Flare undgår dette ved at implementere en UNL-topologi (Unique Node List) for at understrege klarhed og brugervenlighed og samtidig opretholde FBA’s ejendom med åbent medlemskab.

Mens Flare muliggør Turing komplet smart kontraktbrug, har den også en protokol bygget oven på netværket, der giver mulighed for den tillidsløse udstedelse, brug og indløsning af XRP på Flare. Flare kalder denne protokol FXRP, og det gør det muligt for XRP at blive FXRP på Flare, sikret af det oprindelige FLR-token. Dette giver XRP i det væsentlige mulighed for at bruge smarte kontrakter og kan også skabe en tillidsløs pipeline for XRP til andre netværk med henblik på interoperabilitet.

Denne generelle metode kan også udvides til ethvert andet ikke-Turing-komplet token, og evnen til at gøre det er inkluderet i netværksstyringen og -systemerne. Dette betyder, at ethvert ikke-Turing-komplet token i sidste ende kan få adgang til muligheden for at bruge smarte kontrakter og blive interoperable gennem Flare.

FXRP Oversigt

Flare-teamets problem med at bringe XRP til Flare-netværket er umuligheden af ​​en offentlig blockchain smart kontrakt til at kontrollere en XRP-adresse. Dette skyldes, at smarte kontrakter ikke har nogen måde at gemme en hemmelig nøgle på og opretholde dens hemmeligholdelse.

Hvis Flare forsøgte at bringe XRP på netværket ved hjælp af bare kode, ville det også kræve, at en gruppe enkeltpersoner mødtes og brugte en multi-signatur-adresse, som de kollektivt kontrollerer for at godkende transaktioner. Selvfølgelig ville dette betyde, at FXRP under disse forhold hverken ville være decentraliseret eller tillidsløs. Og det ville være uacceptabelt.

FXRP-system

Forbindelse mellem Ripple og Flare. Billede via FXRP Whitepaper

Med den nuværende implementering af FXRP kan enhver XRP-indehaver sende deres tokens til en agent på XRP-netværket. Agenten har XRP og kommunikerer med de smarte kontrakter på Flare, som udsteder FXRP i forholdet 1: 1. Disse FXRP-tokens er også sikret med FLR i forholdet 1: 2,5. Så for hver 1 FXRP, der udstedes, skal der være 2,5 FLR-indsats. Dette holder XRP indeholdt af agenten sikker, og det fjerner behovet for enhver central mellemhandler.

Hvordan fungerer FXRP?

Ejere af FLR er i stand til at sende deres tokens til de smarte kontrakter på Flare, der udgør FXRP-systemet. I det væsentlige giver dette sikkerhedsstillelse til FXRP-systemet. Disse smarte kontrakter kaldes agenter. FXRP-systemet vil være sammensat af mange agenter. Lad os nævne en af ​​dem fyr.

Som agent i FXRP-systemet har Guy sat 5.000 FLR som sikkerhed. Systemet kræver 2,5 FLR for hvert udstedt FXRP-token. Hvis valutakursen for FLR til XRP i øjeblikket er 10: 1, giver disse 5.000 FLR Guy mulighed for at udstede 200 FXRP. dvs. (5.000/10) / 2.5

Nu er Guy klar til at prinde FXRP. Når en XRP-indehaver ønsker at oprette FXRP, sender de en transaktion til FXRP-systemet. Indehaveren, der igangsætter denne transaktion, kaldes ophavsmand. For at oprette FXRP betaler de også et gebyr på 0,1% af transaktionsværdien. Gebyret går til agenten, og transaktionen fortæller agenten, hvilken adresse den skal sende FXRP til, når den er præget, og hvor XRP kommer fra på XRP Ledger.

FXRP-transaktion

En transaktionsmæssig tilgang til FXRP-systemet. Billede via Flare.

Forudsat at der er tilstrækkelig sikkerhed i FXRP-systemet, er den låst for at sikre FXRP, hvilket gør transaktionen tillidsløs, fordi ophavsmanden ikke behøver at stole på den agent, der nu har et incitament til at returnere XRP, når han bliver bedt om at gøre det eller miste FLR, der holdes som sikkerhed. Hvis systemet ikke har tilstrækkelig sikkerhed, returnerer det XRP og gebyret til ophavsmanden.

Det er nøglen at bemærke, at sikkerhedsgraden på 2,5 altid skal opretholdes. Hvis værdien af ​​XRP til enhver tid stiger, eller værdien af ​​FLR falder, så rationen falder til under 2,5, vil Guy have en kort periode til at gendanne forholdet ved at tilføje flere FLR-tokens eller købe FXRP-tokens for at indløse.

Hvis Guy af en eller anden grund ikke er i stand til eller ikke er villig til at genoprette 2.5-sikkerhedsforholdet, auktioneres hans sikkerhed for at genkøbe den FXRP, der blev udstedt mod den. Hvis der er sikkerhed tilbage efter denne fyr er i stand til at beholde den resterende.

Hvis Guy holder sikkerhedsstillelsen på eller over 2,5, er alt godt. Senere, når ophavsmanden beslutter at indløse FXRP tilbage til XRP-hovedbogen, foretager de en transaktion for at gøre det og fortæller systemet, hvilken adresse der skal krediteres XRP. Guy modtager instruktioner fra systemet om, hvor meget XRP der skal returneres, og hvilken adresse de skal sende til.

Sammen med det modtager han også to deadlines, inden for hvilke transaktionen skal gennemføres. Hvis han gennemfører transaktionen inden den første frist, modtager han al sin sikkerhed tilbage. Men hvis den første frist overgår, og han gennemfører transaktionen inden den anden frist, vil der være et mindre gebyr vurderet, inden resten af ​​hans sikkerhed returneres. Dette gebyr forbrændes af systemet.

FXRP-indløsningsfejl

Hvis agenten ikke returnerer XRP, er det en indløsningsfejl, Image via Flare.

Hvis Guy ikke gennemfører transaktionen inden den anden frist, betragtes det som en indløsningsfejl. I dette tilfælde kompenseres ophavsmanden med FLR-tokens fra Guy’s andel plus yderligere 1% til dækning af transaktionsomkostningerne ved at bruge denne FLR til at tilbagekøbe XRP. Den resterende FLR fra Guy’s sikkerhed ser 50% brændt som en straf, og de resterende 50% returneres til Guy.

FLR og afhængige applikationer

FXRP-systemet er vores første eksempel på FLR Dependent Application (SDA). Dette er en dApp, der bruger FLR som sikkerhed, FLR-tokenholdere til styring, Flare Time Series Oracle (FTSO) eller en kombination af disse elementer. Bemærk, at disse alle er valgfri elementer. Enhver applikation på Flare-netværket kan fungere ved kun at bruge FLR til transaktions- og betalingsomkostninger.

I tilfælde af FXRP-systemet bruger det FLR som sikkerhed, Flare Time Series Oracle til at spore XRP / FLR-prisen og FLR-token-ejerskabet indstillet til styring over visse parametre såsom FXRP-oprettelsesgebyr og sikkerhedsforholdet. SDA-modellen giver udviklere en skabelon til udvidelse af brugen af ​​de tre valgfri elementer.

Flare tidsserie Oracle

Indehavere af FLR-token er berettiget til at bidrage til FTSO for at hjælpe med at danne nøjagtige estimater uden for kæden, mens de stadig bevarer decentralisering. FTSO’s struktur giver mulighed for mange estimater af enhver tidsserie uden for kæden. XRP / FLR-værdien er et eksempel på en sådan tidsserie.

Smarte kontrakter om flare

Revolutionen inden for smarte kontrakter. Billede via Coil.com

Formuleringen af ​​tidsseriedataene har typisk to deltagende grupper. Den ene er FLR-tokenholdere, og den anden er indehaverne af det afhængige applikationstoken, som Flare kalder F-aktivet. I tilfælde af FXRP-systemet er FXRP-token F-aktivet. Når der er en mere kompleks applikation, der kræver beregning af flere tidsserier, vil F-aktivet være noget der ligner et udstedt styringstoken.

Når du opretter tidsserien, spørger FTSO hver deltager om et skøn over dataværdien. FLR-indehaverne giver skøn for hver tidsserie, men indehavere af F-aktiver kan kun give et skøn for den tidsserie, der er relateret til F-aktivet. Estimaterne behandles som beskrevet i afsnit 4 i programmet Flare hvidbog og resultatet sendes til det system, der kræver tidsseriedata.

Indehavere af F-aktiver tilskyndes til at deltage og levere data for at bidrage til sikkerheden i applikationen ved hjælp af disse data. FLR-indehavere tilskyndes af potentialet til at optjene en oracle-belønning, som er FLR-tokens præget af systemet. FLR-tokenholdere tjener denne belønning, når de leverer data, som systemet anser for at være korrekte. Den specifikke mekanik i denne beregning er ret kompleks og kan ses i Flare-hvidbogen.

Smart kontrakt forenklet

Forenklet version af en smart kontrakt

Dette system placerer implicit alle FLR-tokens i systemet, da ikke-deltagere eller dem, der leverer data, der anses for ukorrekte, ikke tjener belønninger, hvilket er et afskrækkende forhold til de tokenholdere, der modtager belønningen. Dette er Flares version af belønninger for indsats eller minedrift.

FTSO vil blive initieret til at give følgende priser for: XRP / FLR, USD / FLR, BTC / FLR og XLM / FLR. Kun XRP / FLR har et tilsvarende F-aktiv fra starten. Yderligere tidsserier og deres relaterede F-aktiver kan foreslås og accepteres gennem styringsprocessen.

FLR-delegation

Estimater kommer fra FTSO hvert par sekunder, men det er realistisk at antage, at ikke alle FLR-indehavere vil være interesseret i at deltage i netværksstyring, eller at de har den nødvendige hardware til at bidrage til FTSO.

Fordi Flare-teamet har antaget, at dette er sandt, gjorde de det muligt at frigøre stemmerne for disse ansvarsområder og delegere det til andre. Delegationen kan annulleres når som helst, og hvis tokenet overføres til en ny adresse, annulleres delegationen automatisk.

Et vigtigt træk ved delegering er, at SDA’er er i stand til at delegere stemmer tilbage til den faktiske ejer, som derefter kan delegere disse stemmer til en anden enhed. Dette betyder, at agenter ikke behøver at vælge mellem at tjene FLR for at stille sikkerhed til FXRP-systemet eller at tjene fra FTSO. Så når FLR-tokens bliver utilgængelige for ejerne i en SDA, så længe applikationen definerer, hvem den faktiske ejer er, kan delegering bruges.

Blussstyring

FLR-tokenholdere stemmer for at styre netværket, og SDA’er kan også anmode om at blive styret af FLR-token-indehavere.

I Flare-hvidbogen kan du finde regimer for eventuelle manuelle ændringer i kæden, der kan initieres og stemmes om af FLR-indehavere. Dette er ting som at ændre gebyrerne forbundet med handlinger, ændre sikkerhedsforholdet, ændre transaktionsomkostninger og andre variabler, der ikke kræver kodeændring.

Blussstyring

Forskellige styringsniveauer på Flare-netværket. Billede via Flare whitepaper.

For de ting, der kræver en kodeændring, såsom at ændre netværkskonsensusparametre eller tilføje en ny tidsserie til FTSO, oprettes der et Flare Foundation. Fonden er ikke oprettet endnu, men det vil være en nonprofit enhed med ansvar for 5 områder: tilskud, investeringer, forskning og udvikling, uddannelse, reklame og partnerskaber.

Fordi fonden har forsknings- og udviklingsfunktionen, bliver de integreret i kodeopdateringsprocessen, opbygger, tester, analyserer og derefter implementerer eventuelle foreslåede kodændringer.

Fonden vil blive oprettet for at være fuldstændig gennemsigtig i sine aktiviteter og sine udgifter. Den offentliggør en halvårlig rapport om sine aktiviteter og udgifter. Vigtigst er det ikke bemyndiget til at sætte en dagsorden, men er skabt på en måde, der kun tillader det at tage retning fra FLR-indehaverne.

Flare Foundation

Lær mere i whitepapers fra Flare. Billede via Flare.

På grund af denne begrænsning kan fonden ikke:

  • bidrage til FTSO på nogen måde
  • distribuere nogen af ​​sine FLR-beholdninger som sikkerhed for enhver applikation på netværket
  • bruge sine FLR-beholdninger til at stemme i enhver governance-stemme eller tildele sine FLR-tokens til andre til at gøre det.

Derudover kunne FLR-indehavere til enhver tid stemme for at opløse fonden, i hvilket tilfælde det ville være nødvendigt at afvikle alle aktiviteter og brænde nogen af ​​dets resterende tokens.

FLR Udstedelse og Airdrop

Flare valgte at frigive sine tokens i noget, det betegnes som en værktøjsgaffel. Traditionelle gafler har delt brugerbasen i et netværk med en del på vej i deres egen retning og tager normalt en antagonistisk holdning til moderkæden.

Derimod er værktøjsgaffelen beregnet til at tilføre værdi til den oprindelige kæde. Det er præcis, hvad Flare gør ved at lade XRP fortsætte med at levere hurtig, pålidelig, tillidsløs afvikling, samtidig med at det giver smarte kontrakter og muligheden for at oprette tillidsløse rørledninger til andre blockchains. Det er et perfekt eksempel på at bringe nyt værktøj til en eksisterende blockchain.

Flare skaber 100 milliarder FLR-tokens for at spejle antallet af eksisterende XRP-tokens. Hensigten i starten er at gøre disse tokens tilgængelige for adresser, der ikke ejes af Ripple Labs, Ripple-grundlæggere, hvalkonti og alle adresser, der er kendte svindlere.

Flare har gjort 45 milliarder FLR gældende af XRP-indehavere, idet disse tokens tildeles adresser, der har XRP på det tidspunkt, hvor et øjebliksbillede af Ledger blev taget kl. 00:00 GMT den 12. december 2020. Derudover tildeles 30 milliarder FLR til Flare Foundation , og yderligere 25 milliarder FLR tildeles Flare Networks Limited, som er en profitorganisation, der understøtter Flares udvikling.

Spark Airdrop

XRP-indehavere drager fordel af Spark airdrop. Billede via RippleCoinNews.com

Tildelingen skal dog ske på 1: 1 basis den faktiske beregning førte til et fordelingsforhold på 1,0073 FLR for hver XRP på tidspunktet for øjebliksbillede. Derudover kan tokens ikke kræves, før mainnet går live, hvilket formodes at forekomme i de første uger af juni 2021. Enhver, der har XRP-tokens på en børs, der understøtter airdrop, krediteres automatisk FLR-tokens, når de distribueres.

Listen over understøttende børser inkluderer Binance, KuCoin, Coinbase, Poloniex og mange andre. De, der holder deres XRP i en selvbevarende tegnebog, skal registrere et krav, og FLR-tokens leveres til den adresse, der er angivet i kravet. Der vil være et antal FLR-kompatible tegnebøger at vælge imellem, når mainnet startes.

Det er også værd at bemærke, at Flare har sagt ”Du må kræve FLR efter at netværket går live, men ikke efter 6 måneders datoen fra øjebliksbillede. ” Da øjebliksbillede opstod den 12. december 2020, der indikerer, at mainnet vil starte før den 12. juni 2021.

Derudover distribueres ikke alle tokens med det samme. Flare frigøres 15% af tokenallokeringen, når mainnet startes. Den resterende FLR frigives i løbet af de næste 25-34 måneder med en hastighed på 2-4% pr. Måned.

Hvem står bag flare-netværk?

Administrerende direktør og en medstifter af Flare Network er Hugo Philion. Før han skabte Flare var han grundlægger af det modulære byggesystem, Future Generations. Hans baggrund er i investeringer, og han har en Bachelor of Science-grad i Investment and Financial Risk Management fra Cass Business School.

Senere modtog han en kandidatgrad i maskinlæring fra UCL. Han fik også erfaring med at arbejde som porteføljeforvalter af råvarederivater for to $ 1 mia. + Fonde.

Flare grundlæggere

Hugo og Sean, medstifterne af Flare. Billede via Flare.

Den anden medstifter af Flare og dets CTO er Sean Rowan. Sean har været involveret i blockchain-rummet siden 2015, da han designede sikre køretøjskommunikationsprotokoller, der udnytter en blockchain-baseret offentlig nøgleinfrastruktur med kolleger på UCLA og TCD. Før det fik han en dobbelt BA i matematik og BE i elektronik og computerteknik fra Trinity College Dublin.

Han fortsatte senere med at modtage en Master of Science i Machine Learning fra University College London, som sandsynligvis er, hvor han mødte Hugo Philion. Sean var også en R&D Engineer hos RAIL i Dublin, Irland, hvor han udviklede backend-netværkssoftware til en sundhedsassistent robot. Den seneste version af denne robot fra RAIL vises på forsiden af ​​tidsskriftet TIME i november 2019.

Konklusion

Da Ripple har et så stort efterfølger og et stort potentiale i bankområdet, kan Flare-netværket blive lige så stort som det netværk, der bringer smart kontraktfunktionalitet til XRP. Det er bestemt det, som grundlæggerne af projektet håber på, og der er sandsynligvis en stor gruppe af XRP-entusiaster, der er lige så begejstrede over mulighederne, som Flare bringer til Ripple.

En ting, der kan siges om projektet, er, at det helt sikkert genererede en masse hype med sin airdrop, og vi er villige til at satse på, at der er millioner, der aldrig har hørt om Flare før, som nu er klar over dets eksistens og muligvis om dens mission og mål. Efter at have læst denne artikel, skal du regnes blandt dem.

Airdrop skabte også ophidselse inden for Ripple-samfundet, da XRP-token steg højere med næsten 300% i november 2020. Det skyldtes spekulanter, der trængte sig ind i mønten for at drage fordel af airdrop. Siden da har tingene ikke været så rosenrøde, da XRP er faldet fra et højt niveau omkring $ 0,90 til så lavt som $ 0,227880 den 23. december 2020.

Vi ved ikke, hvad der vil ske med FLR-token, når det distribueres, men selv med den oprindeligt planlagte langsomme emissionsplan, ser det ud til, at markedet vil blive oversvømmet med FLR-tokens i de første 2-3 år efter lanceringen af ​​mainnet . Medmindre der er nogle udviklinger, der forårsager en lignende stigning i efterspørgslen i løbet af den tid, kan symbolet være klar til at falde, da de samme spekulanter, der købte XRP til airdrop, beslutter at dumpe deres FLR så hurtigt som muligt.

Hvis du tager en længere tidshorisont, kan dette være et godt projekt at komme bagud, og hvis vi har ret i lanceringen af ​​mainnet, kan det være en god mulighed for at få fat i massive poser med FLR til det billige. Selvfølgelig vil kun tiden vise, om det er sandt.

Den anden ting at huske er, at Flare begyndte med Ripple, men teoretisk kan det tilføje smart kontraktfunktionalitet og interoperabilitet til enhver blockchain. I betragtning af at tre fjerdedele af værdien i offentlige blockchain-tokens ikke kan bruges med smarte kontrakter på en tillidsløs måde, har Flare i øjeblikket en enorm potentiel vækstkurve fremover.

Fremhævet billede via Shutterstock

Ansvarsfraskrivelse: Dette er forfatterens udtalelser og bør ikke betragtes som investeringsrådgivning. Læsere bør gøre deres egen forskning.

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