Flare-netværk
i dag er vi glade for at offentliggøre vores detaljerede planer for implementering af Flare-netværket. Disse planer kan udforskes fuldt ud ved at dykke ned i vores udkast til hvidbøger, der dækker netværket og dets oprindelige token, Spark (her) og den tillidsløse integration af RRP med Flare (her). Papirerne er i udkast, og der vil være optimeringsændringer mellem nu og dagen Flare går live. Der bør ikke være ændringer, der væsentligt afviger fra oversigten nedenfor. I dette indlæg sigter vi mod at fremhæve, hvad vi anser for at være de vigtigste aspekter af Flare. Et minimalt teknisk overblik over hver vigtig komponent vil blive offentliggjort i løbet af de følgende uger, der starter senere i denne uge med en gennemgang af Flare ‘ s tillidsløse integration. Spænd selen!
(en TL;DR er i slutningen af dette indlæg.)
Hvad er Flare, og Hvorfor bygger vi det?
Flare eksisterer for at løse to nøgleproblemer:
for det første og af umiddelbar betydning for opbygningen af vores branche er, at 75% af den værdi, der findes i offentlig blockchain, ikke i øjeblikket kan bruges på en tillidsløs måde med smarte kontrakter.
for det andet og af både kortsigtede og langsigtede konsekvenser er der potentielle problemer med, hvordan skalering implementeres for smarte kontraktnetværk i dag. De fleste nye netværk bruger Proof of Stake eller dens varianter. Disse protokoller henter netværkssikkerhed fra deres oprindelige token.
det umiddelbare problem, der er forbundet med Proof of Stake, er, at konsensusdesignet endnu ikke sikkert tillader alternative anvendelser af det oprindelige token. Hvis en tokenindehaver kan opnå et højere udbytte (og uden mulighed for at skære) ved at stille sikkerhed for at skabe et stablecoin, end de kan fra staking, så vil de som økonomiske rationalister sandsynligvis gøre det. Dette afleder tokens væk fra staking og kannibaliserer netværkets sikkerhed. (En meget indsigtsfuld artikel om dette emne er her .) Vi formoder, at dette måske er hovedårsagen til, at Ethereum trods relativt højere transaktionsomkostninger og langt lavere transaktionsgennemstrømning stadig fører an i DeFi.
et længerevarende problem er, at som et bevis på Stake netværk gevinster forbrug og værdien bygget oven på det stiger, værdien af staking token skal stige eller netværket vil blive usikre. Dette er godt for investorer i token, men dårligt for folk, der ønsker at se decentralisering blive en del af den almindelige måde at drive forretning på. Hvorfor? For for at tokenværdien, der sikrer netværket, skal stige, skal kapitalen omdirigeres fra en anden brug for at købe token. Taget til det logiske slutpunkt, hvis smarte kontraktnetværk, der bruger bevis for indsats, skulle blive den allestedsnærværende metode til at drive forretning, omfanget af omdirigering af kapital, der kræves fra andre bestræbelser, bare for at sikre den værdi, der er bygget på disse netværk, ville gøre omkostningerne ved handel umuligt høje. Af denne grund er det yderst usandsynligt at ske. Bevis for indsats og varianter kan skalere transaktionsgennemstrømning, men eksisterende implementeringer kan ikke skalere for værdi. Efter vores mening er bevis for indsats mere af en stopgap end en løsning.
Hvordan løser Flare disse problemer?
Flare er kernen i en ny måde at skalere smarte kontraktplatforme på, der ikke forbinder sikkerhed med værdien af dets token. Flare kræver stadig et token til driften af netværket, primært for at afskrække spam-transaktioner. Flare ‘ s token hedder Spark. Fordi Spark ikke har netværkssikkerhedsimplikationer, er det velegnet til at muliggøre den tillidsløse brug af ikke-Turing komplette tokens med smarte kontrakter.Flare er verdens første Turing complete Federated Bysantine Agreement (FBA) netværk. Noder kører Avalanche-konsensusprotokollen med en nøgletilpasning til FBA-konsensustopologien. FBA er unik som en konsensustopologi, idet den opnår sikkerhed uden at stole på økonomiske incitamenter, der kan forstyrre brugssager af høj værdi og høj risiko. En kritik af ren FBA er, at det fører til skrøbelige strukturer af bestanddele, der tillader topologiscenarier, hvor en enkelt knudefejl kan forårsage en netværksdækkende fiasko. Af denne grund prioriteres en specifik indstilling af FBA kaldet en unik Node List (UNL) topologi, der understreger klarhed og brugervenlighed, samtidig med at FBA ‘ s open-membership-egenskab opretholdes. Den procentvise overlapning af UNL er en styringsdefineret parameter, med en lavere overlapning, der forbedrer netværkets åbne medlemsejendom. Flare-netværket udnytter Ethereum Virtual Machine (EVM), hvilket gør det muligt for netværket at køre Turing komplette smarte kontrakter.
Ved netværksstart, bygget oven på Flare, er derefter en protokol, der sikkert muliggør den tillidsløse udstedelse, brug og indløsning af RRP på Flare. Denne protokol kaldes FKRP. På Flare, sikret af Flare ‘ s native token, Spark. En gang der er tillidsløs interoperabilitet med andre netværk mulig, både gennem interoperabilitetsprotokoller som Cosmos og Polkadot eller med Ethereum via veldefinerede broprotokoller. Kort sagt: Flare kan bruges som en smart kontraktplatform til RRP eller som en tillidsløs pipeline til RRP til andre netværk.
desuden kan den generelle metode til valutapolitik udvides til ethvert ikke-Turing komplet token, og evnen til at beslutte, hvilke andre tokens der skal understøttes og derefter udvide midlerne til at gøre det, er indbygget i netværkets systemer og styring.
Flare samler værdien af de ikke-Turing komplette tokens med den transformative effekt af smarte kontrakter på et netværk, der kan skalere for værdi såvel som transaktionsgennemstrømning.
kompleksiteten ved at få RRP på Flare er, at der ikke er nogen måde for en smart kontrakt på en offentlig blockchain at styre en adresse på RRP-hovedbogen. Årsagen til dette er, at smarte kontrakter i øjeblikket ikke har nogen tilstrækkelig måde at lagre en hemmelig nøgle på en måde, der virkelig er hemmelig. For at få Flare på Flare ved hjælp af kun kode ville det kræve, at en gruppe deltagere kommer sammen med en multi signature-adresse, som de kollektivt kontrollerer, hvorved hvis k af N-parter underskriver en transaktion, er transaktionen godkendt. Enhver bruger af et aktiv udstedt af denne multisig-adresse skulle derefter have tillid til denne samling af brugere, og aktivet ville således hverken være tillidsløst eller decentraliseret.det er vigtigt at vide, hvordan man bruger en computer til at finde ud af, hvordan man bruger den. De smarte kontrakter om Flare udsteder derefter originatorfrp på Flare, som er 1: 1 konvertibel med RP og sikret med gnist. Når en indehaver af valutaomregner ønsker at indløse den til valutaomregner ( en indløser), sender de den tilbage til valutaomregner smart contracts on Flare. Agenterne sender derefter RRP til indløseradressen på RRP-hovedbogen. Hvis agenterne ikke gennemfører denne indløsning hurtigt nok, kompenseres indløseren værdien af deres RP plus et beløb til at kompensere for transaktionsomkostninger for at genkøbe RP.
med Valutaomregner er der ikke behov for centraliseret mellemmand.
fungerer som følger:
ejere af Flare ‘ s native token, Spark, kan sende deres tokens til en samling af smarte kontrakter på Flare, der kaldes flare-systemet. Brugere, der gør dette, stiller sikkerhed til systemet. De kaldes agenter. Lad os ringe til en af agenterne Bob. Der vil være mange agenter i FKP-systemet.lad os sige, at Bob har indsat 5000 Spark tokens i systemet. I dette eksempel 10 Spark tokens kan i øjeblikket købes for 1 KKP token. Systemet kræver et sikkerhedsforhold på 2,5, hvilket betyder, at en agent til enhver tid skal have givet systemet 2,5 gange værdien af den valuta, systemet har fordelt til dem i Spark tokens. RP er her vurderet som 1: 1 med RP. Derfor giver Bobs 5000 Spark tokens systemet mulighed for at udstede 200 F.kr.når nogen, siger Alice, ønsker at oprette valutaomregner, sender de en transaktion til VALUTAOMREGNERSYSTEMET med et fast gebyr på 0,1% af værdien af valutaomregner, som de ønsker at samle i valutaomregner. Alice kaldes en ophavsmand. Transaktionen fortæller også valutasystemet, hvilken adresse der skal sendes til On Flare, når den først er præget, og hvilken adresse den vil stamme fra på Finansbogen. Hvis der er ledig kapacitet i VALUTAOMREGNINGSSYSTEMET, låses sikkerhedsstillelse for at sikre mængden af VALUTAOMREGNET, der oprettes, i en bestemt periode mod Alices kommende transaktion. På denne måde behøver Alice ikke at stole på Bob. Til gengæld genereres et sæt instruktioner til Alice, der fortæller hende, hvilken adresse (Bobs adresse) der skal sendes til på hovedbogen, og hvilket sidste hovedbogsindeks der skal bruges. Hvis der ikke er kapacitet i systemet til at udstede det ønskede beløb, refunderes Alice gebyret.
Alice sender derefter det korrekte beløb plus et oprettelsesgebyr i HRP til Bobs adresse på HRP-hovedbogen. Oprettelsesgebyret er den store del af de penge, Bob tjener til at låse sin Gnistsikkerhed, bemærk, at hans indtjening overvejende er i HRP. Flare observerer denne transaktion ved hjælp af et system kaldet State Connector, defineret i Afsnit 2 i Flare-hvidbogen (og emnet for et fremtidigt blogindlæg). Systemet præges derefter af systemet og leveres til Alices nominerede adresse på Flare.
sikkerhedsforholdet på 2,5 gange skal opretholdes til enhver tid. Hvis prisen stiger mod Spark, således at værdien af Bobs sikkerhedsstillelse falder til under 2.5 gange den valuta, der er udstedt mod det, så har Bob en begrænset tid til enten at tilføje flere Spark tokens som sikkerhedsstillelse eller købe og indløse valuta tokens for at bringe hans sikkerhedsforhold tilbage i køen. 200 tokens udstedt mod Bobs 5000 Spark tokens, og prisen på Spark/Spark stiger til 12. Bob skal nu enten tilføje 1000 Spark til systemet eller købe og indløse 33.34-valuta for at reducere sin fordeling af udstedt valuta til 166.66.
Hvis Bob ikke har adgang til yderligere Spark-tokens, er det ikke økonomisk besværligt for ham at reducere balancen i f.eks. Bobs sikkerhedsstillelse gjorde det muligt for systemet at udstede 200 tokens, i færd med at gøre det har Bob modtaget 200 tokens på hovedbogen. Således, hvis Bob ikke har yderligere kapital til at købe Spark tokens, kan han enten sælge tilstrækkeligt til Spark tokens på en børs, således at han kan indløse mindst 33,34 valuta eller forblive i et rent decentraliseret miljø, hvis der er andre agenter i valutasystemet med tilstrækkelig overskydende sikkerhed i Han kan mynte tilstrækkelig valuta og straks indløse den. Det andet scenario flytter i det væsentlige forpligtelsen til resten af systemet. Hvis Bob ikke gør noget og forbliver i misligholdelse mod sikkerhedsforholdet, auktioneres Bobs sikkerhedsstillelse automatisk for det beløb, der er udstedt mod det, hvilket i dette tilfælde er 200. Bob beholder enhver resterende sikkerhed efter denne operation.
lad os sige, at Bob valgte at tilføje yderligere gnist som sikkerhed. Nu nogen tid senere Alice, der ejer alle de 200 udstedte valutaomregner ønsker at indløse hele beløbet tilbage til FINANSBOGEN. Alice foretager simpelthen en transaktion med valutasystemet, der sender valutasystemet til systemet og fortæller det, hvilken adresse hun ønsker krediteret. Systemet udsteder derefter et sæt instruktioner til Bob, der fortæller ham, hvor meget HRP skal sende, og hvor sammen med to HRP-hovedbogsnummerfrister, hvormed transaktionen skal gennemføres. Hvis Bob gennemfører transaktionen inden den første frist, er hans sikkerhed helt låst op. Hvis Bob mislykkes inden den første frist, men lykkes med den anden, opkræves han et lille strafgebyr, og resten af hans sikkerhed er låst op. Straffen er brændt.
Hvis Bob ikke gennemfører transaktionen inden den anden frist, kaldes det en indløsningsfejl. Alice kompenseres derefter med Spark tokens til værdien af hendes indløste RP plus en stigning på 1% For at dække transaktionsomkostninger ved at købe tilbage RP, dette trækkes fra Bobs sikkerhed. Af Bobs resterende sikkerhed brændes 50% som en straf, og de andre 50% returneres til ham. Alice kan derefter købe erstatning på en børs. Alternativt, forudsat at der er andre agenter på Flare med udstedt valuta og folk, der ønsker at sælge det, kan Alice købe mere valuta på Flare og indløse det mod disse agenter.
Spark and Dependent Applications
er det første eksempel på noget, vi kalder en Spark Dependent Application (SDA). En SDA er defineret som et program, der i sin konstruktion bruger en kombination af: Spark for collateral, Flare Time Series Oracle og Spark token indehavere til styring. Hvert af disse elementer er helt valgfrit, og et program kan fungere på Flare kun interagere med Spark til betaling af transaktionsomkostninger. F. eks.bruger
Flare Time Series Oracle
ejerskab af Spark token giver mulighed for bidrag til Flare Time Series Oracle (FTSO). Formålet med FTSO er at danne nøjagtige estimater af data om Flare fra off-chain, samtidig med at decentraliseringen opretholdes. FTSO er struktureret til at give mange skøn over individuelle tidsserier. Gnistprisen er et eksempel på en enkelt tidsserie.
hver tidsserie output af FTSO vil generelt have to grupper af deltagere: den første er Spark token indehavere og den anden er indehaverne af det afhængige applikationstoken, der kaldes et F-aktiv. I applikationen er F-asset selve tokenet. For en mere kompleks applikation som en derivatapplikation, hvor applikationen kræver flere tidsserier, kan F-aktivet være noget mere beslægtet med et udstedt styringstoken.
for hver tidsserie beder FTSO hvert relevant sæt deltagere om at give et skøn. Spark indehavere vil give skøn for alle tidsserier og f-asset indehavere vil give skøn over kun tidsserier relateret til deres F-Aktiv. Disse estimater behandles derefter som defineret i Afsnit 4 i Flare-hvidbogen og output fra systemet.
incitamentet for f-aktivindehavere til at levere data til systemet er sikkerheden ved deres anvendelse. Spark token indehavere er tilskyndet af potentialet til at tjene noget, der hedder oracle belønning. Dette er en mængde Spark tokens, der er præget af systemet. Oracle-belønningen er en årlig sats fordelt ensartet på tværs af hver ftso-estimeringsperiode. For eksempel, hvis satsen er 10%, er der 365 estimater om et år og et startnummer på Spark tokens på 100, så oprettes 10 Spark om 1 år og ~0,03 Spark præget og belønnet pr. Spark token-bidragydere kan tjene denne belønning ved at bidrage med data, der anses for at være “korrekte”. Den præcise mekanik er beskrevet i hvidbogen. Det er vigtigt, at alle Spark token-indehavere implicit sættes i systemet, som om de ikke tjener belønningen enten gennem ikke-bidrag eller leverer “forkerte” estimater, de mister værdi til tokenindehavere, der belønnes. Dette er Flares version af blokbelønninger.
FTSO vil blive indledt for at give følgende priser for: USD/Spark, BTC/Spark og Spark/Spark. Kun f-Asset vil have et tilsvarende F-aktiv fra starten. Yderligere tidsserier og deres relaterede f-aktiver kan foreslås og accepteres gennem styringsprocessen.
Delegation
FTSO vil i virkeligheden give estimater hvert par sekunder. Ikke alle Gnistholdere vil have eller være i stand til at køre udstyr for at bidrage til FTSO, og hver for sig er de måske ikke interesserede i at stemme for netværksstyring. Derfor kan stemmerne for begge ansvarsområder løsnes fra selve tokenet og delegeres separat til andre parter. Delegationen kan til enhver tid annulleres, og når et token overføres fra en adresse til en anden, annulleres delegationen automatisk, således at stemmerettighederne følger med tokenet. Mekanismen tillader også SDA ‘ er som f.eks. Så hvis Bob har 5000 Spark tokens i programmet, vil det delegere stemmerne fra disse tokens til en adresse angivet af Bob. Hvis Bob ønsker, at en dedikeret dataudbyder skal bidrage til FTSO på hans vegne, kan Bob derefter delegere sine stemmer for FTSO til dataudbyderen. Det er vigtigt, at Bob ikke behøver at vælge mellem at tjene Spark ved at stille sikkerhed til FTSO-applikationen og potentielt tjene belønningen fra FTSO, han kan gøre begge dele. Enhver SDA, der gør Spark tokens utilgængelige for deres underliggende ejere, forudsat at der er en definition i ansøgningen om, hvem den underliggende ejer er, kan implementere delegationsproceduren.
Governance& Foundation
Flare styres udelukkende af Spark token indehavere gennem afstemning. SDA ‘ er kan eventuelt anmode om at blive styret af Spark token indehavere.
visse beslutninger kan træffes på en automatiseret måde på kæden, såsom ændring af transaktionsomkostninger, oracle-belønningssatsen eller, når man ser på valutaomregning som en SDA, ændring af sikkerhedsforholdet og oprettelsesgebyret. Andre beslutninger såsom tilføjelse af en ny tidsserie til FTSO og sammenkædning af det foreslåede F-aktiv, ændring af netværkskonsensusparametre eller mere komplekse langsigtede opdateringer kræver en kodeændring. Flare-hvidbogen indeholder et forslag, udviklings-og testregime for manuelle ændringer, som kan indledes og stemmes om af Spark token-indehavere. For at hjælpe med at gennemføre denne proces og udføre de aftalte ændringer vil der være et Flare fundament. Fonden vil være en non-profit, der skal indarbejdes i de kommende måneder. Det skal være ansvarligt for 5 nøgleområder: tilskud, investeringer, forskning og udvikling, uddannelse, reklame og partnerskaber.
det er forsknings-og udviklingsfunktionen, der gør det muligt for fundamentet at være en integreret del af netværksopdateringsprocessen, endda gå så langt som at analysere, rapportere om og derefter opbygge, teste og implementere foreslåede ændringer i netværkskoden.
fundamentet skal være meget gennemsigtigt og ikke spilde penge. To rapporter om året om dets aktiviteter og udgifter vil blive overholdt og offentliggjort. Fonden er kun beregnet til at tage retning fra Spark token indehavere og ikke at sætte dagsordenen. Som sådan, det må ikke: bidrage til FTSO på nogen måde, implementere nogen af sine Spark holdings som sikkerhed for enhver applikation på netværket, og det må ikke bruge sine Spark holdings til at stemme i nogen regeringsstemme. Det kan ikke tildele sine Spark tokens til andre for at gøre det. Desuden, skrevet ind i fondens forfatning vil være den forpligtelse, at hvis en regeringsafstemning er enig i, at fonden ikke længere tjener et gavnligt formål, skal fonden afvikle sine aktiviteter og brænde alle sine resterende token-beholdninger så hurtigt som muligt.
Gnistudstedelse
det bedste samfund til at eje det aktiv, der muliggør brugen af RRP med Turing complete smart contracts, er det samfund, der vil bruge det og drage fordel af det: RP-indehavere. Flare laver ikke en ITO. I stedet gør det, hvad vi kalder en hjælpegaffel. Vi tror, det er den første af sin art.
en gaffel har traditionelt forsøgt at tage brugerbasen af et eksisterende netværk og afvige helt fra dette netværk, normalt for at have et antagonistisk forhold til den oprindelige kæde. I modsætning hertil er en hjælpegaffel beregnet til at bringe værdi tilbage til den originale kæde i stedet for at bevæge sig væk fra den. Flare giver os mulighed for at gøre, hvad det gør bedst, hurtig afvikling, samtidig med at vi bringer smarte kontrakter og muligheden for at skabe en tillidsløs pipeline til andre blockchains. Vi mener, at dette er en virkelig stærk kombination og et perfekt eksempel på nytte.
100 milliarder Spark tokens vil blive oprettet for at afspejle mængden af KSRP, der eksisterer. Der er cirka 45 Bn-tokens, der ikke tilhører Ripple labs. Formålet med distributionen er, at andre holdere end Ripple kan kræve ca.en 1:1 mængde gnist til deres holding. 45 Bn Spark kan gøres krav på af holdere (stripping out kendte Ripple labs adresser). 25 Bn Spark vil gå til Flare netværk Limited, som er Flare ‘ s for-profit organisation. 30 Bn Spark vil gå til Flare foundation.
da mange HRP-ejere faktisk bruger udvekslinger til at holde deres HRP-tokens, er der en mulighed for, at en indehaver af HRP, der ønsker at kræve Spark-tokens, muligvis ikke kan, fordi enten udvekslingen hævder gnisten og bevarer dem i stedet for at videregive dem, eller alternativt ikke hævder dem overhovedet. For at give ejerne mulighed for at deltage i distributionen, enten ved at presse deres udveksling til at distribuere Spark tokens eller for at flytte udveksling til en, der gør det, vil snapshotet af RP ledger blive taget på en dato tættere på lanceringen. En liste over deltagende børser vil blive offentliggjort på Flare ‘ s hjemmeside og opdateret med jævne mellemrum. Snapshot-hovedbogsnummeret vil blive sendt til hjemmesiden, når snapshot er taget.
TL;DR
Flare er verdens første Turing complete Federated Bysantine Agreement (FBA) netværk. Det integrerer Ethereum Virtual Machine (EVM) og udleder ikke sikkerhed fra et token. På toppen af dette er der bygget en protokol, der sikkert muliggør den tillidsløse udstedelse, brug og indløsning af RRP på Flare. Denne protokol kaldes FKRP. Den generelle metode for protokollen og systemet, der forbinder Flare til andre netværk, kan udvides til ethvert ikke-Turing komplet token. Tillidsløs interoperabilitet med andre netværk er mulig, både gennem interoperabilitetsprotokoller som Cosmos og Polkadot eller med Ethereum via veldefinerede broprotokoller.Flare ‘ s token, Spark er skabt gennem det, der kan være den første hjælpegaffel nogensinde, hvorved oprindelsesnetværket, i dette tilfælde hovedbogen, nyder godt af øget nytteværdi. 100 milliarder Spark tokens vil blive oprettet i starten af Flare-netværket, hvoraf 45 milliarder vil kunne påberåbes af eksisterende RP-indehavere eksklusive Ripple Labs. Dette afspejler den eksisterende mængde distribuerede RP, således at nuværende RP-indehavere vil være i stand til at kræve cirka 1 Gnisttoken for hvert RP-token, der holdes. 25 milliarder tokens vil gå til udviklerne, Flare og 30 milliarder tokens vil gå til et non-profit fundament kaldet Flare foundation. Spark token indehavere kan tjene et afkast på deres Spark tokens både ved at begå Spark tokens som sikkerhed for at sikre den tillidsløse udstedelse og indløsning af FEKSRP og ved at bidrage med data til Flare time series oracle. Disse funktioner konkurrerer ikke med hinanden.Spark token bruges til styring af netværket gennem afstemning. Med undtagelse af tilskud og investeringer for at hjælpe med at udvikle Flare, tager fonden teknisk retning fra Spark token-ejerne. En nøglerolle for fonden er at hjælpe med at udføre opgraderinger og ændringer i netværket, aftalt af governance vote, der ikke kan implementeres uden en kodeændring. Vigtigere, skrevet ind i fondens forfatning, vil være en vedtægt, at fundamentet skal afvikles, og alle Spark tokens, som fonden har brændt, hvis Spark token indehavere er enige om, at dets eksistens ikke længere er til gavn for netværket.
Flare samler værdien af de ikke-Turing komplette tokens med den transformative effekt af smarte kontrakter på et netværk, der kan skalere for værdi såvel som transaktionsgennemstrømning.
svar på to spørgsmål:
skaber Spark bevis for indsats ved bagdøren?
kun udstedte tokens, der kræver sikkerhedsstillelse, f.eks. Netværket bruger ikke Spark til sikkerhed for at komme til enighed.
Vi havde (hvad vi synes er) meget stærke koncepter for en USD-denomineret stabil mønt, men det krævede omfattende ombygning af Ethereum Virtual Machine, som ville have forsinket lanceringen og haft uforudsigelige virkninger på fremtidig kompatibilitet med EVM. Spark, da den er struktureret, giver meget større nytte og fordel for både RRP-samfundet og RRP-hovedbogen.