ma örömmel tesszük nyilvánosságra a Flare hálózat telepítésére vonatkozó részletes terveinket. Ezeket a terveket teljes mértékben feltárhatjuk, ha belemerülünk a hálózatra és annak natív tokenjére, a Spark-ra (itt), valamint az XRP és a Flare megbízhatatlan integrációjára (itt). A papírok tervezet formájában vannak, és optimalizálási változások lesznek mostantól a Flare életbe lépéséig. Nem szabad olyan változtatásokat végrehajtani, amelyek lényegesen eltérnek az alábbi áttekintéstől. Ebben a bejegyzésben arra törekszünk, hogy kiemeljük a Flare legfontosabb szempontjait. Az egyes fontos összetevők minimális technikai áttekintése a következő hetekben kerül közzétételre, a hét későbbi szakaszában kezdődik a Flare megbízhatatlan integrációjának áttekintése XRP, FXRP. Csatold be magad!

(a TL; DR a bejegyzés végén található.)

mi az a Flare és miért építjük?

a Flare két kulcsfontosságú kérdés megoldására létezik:

először is, az iparágunk kiépítésének közvetlen jelentősége az, hogy a nyilvános blokkláncban meglévő érték 75% – a jelenleg nem használható megbízható módon intelligens szerződésekkel.

másodszor, mind a rövid távú, mind a hosszú távú következmények miatt potenciális problémák merülhetnek fel azzal kapcsolatban, hogy manapság hogyan alkalmazzák a méretezést az intelligens szerződéses hálózatokra. Az új hálózatok többsége a Proof of Stake-et vagy annak változatait használja. Ezek a protokollok a hálózati biztonságot a natív tokenből származtatják.

a Proof of Stake-ben rejlő azonnali probléma az, hogy a konszenzus kialakítása még nem teszi lehetővé biztonságosan a natív token alternatív használatát. Ha egy token birtokosa magasabb hozamot érhet el (és nincs lehetősége a vágásra) azáltal, hogy biztosítékot nyújt egy stabil érme létrehozásához, mint amennyit a staking-től tud, akkor mint gazdasági racionalisták, valószínűleg ezt fogják tenni. Ez eltéríti a zsetonokat a kockától, és kannibalizálja a hálózat biztonságát. (Erről a témáról itt található egy nagyon érdekes cikk.) Azt gyanítjuk, hogy talán ez a legfontosabb oka annak, hogy annak ellenére, hogy viszonylag magasabb tranzakciós költségek és sokkal alacsonyabb tranzakciós áteresztőképesség, Ethereum még mindig élen jár a DeFi.

hosszabb távú probléma, hogy a Téthálózat használatának bizonyítékaként és a tetejére épített érték növekedésével a tét token értékének növekednie kell, különben a hálózat biztonságossá válik. Ez nagyszerű a token befektetők számára, de rossz azok számára, akik szeretnék látni, hogy a decentralizáció az üzleti tevékenység mainstream módjának részévé válik. Miért? Mert ahhoz, hogy a hálózatot biztosító token értéke emelkedjen, a tőkét el kell terelni valamilyen más felhasználástól a token megvásárlásához. A logikai végponthoz képest, ha a proof of stake-et használó intelligens szerződéses hálózatok az üzleti tevékenység mindenütt jelenlévő módszerévé válnának, a tőke más törekvésekből való elterelésének mértéke, csak az ezekre a hálózatokra épített érték biztosítása érdekében, a kereskedelem költségeit megvalósíthatatlanul magasra tenné. Emiatt rendkívül valószínűtlen, hogy megtörténjen. A Proof of Stake és a variánsok skálázhatják a tranzakciós teljesítményt, de a meglévő implementációk nem skálázhatják az értéket. Véleményünk szerint A tét bizonyítása inkább megállás, mint megoldás.

hogyan oldja meg a Flare ezeket a problémákat?

a Flare az intelligens szerződéses platformok skálázásának új módja, amely nem kapcsolja össze a biztonságot a token értékével. A Flare továbbra is tokent igényel a hálózat működéséhez, elsősorban a spam tranzakciók megakadályozására. Flare jelzőjét Sparknak hívják. Mivel a Sparknak nincs hálózati biztonsági vonatkozása, kiválóan alkalmas a nem Turing-teljes tokenek megbízhatatlan használatára intelligens szerződésekkel.

Flare a világ első Turing teljes Bizánci Szövetségi megállapodás (FBA) hálózat. A csomópontok futtatják az Avalanche konszenzus protokollt az FBA konszenzus topológiájához való kulcsfontosságú adaptációval. Az FBA konszenzusos topológiaként egyedülálló abban a tekintetben, hogy biztonságot ér el anélkül, hogy olyan gazdasági ösztönzőkre támaszkodna, amelyek zavarhatják a nagy értékű és magas kockázatú felhasználási eseteket. A tiszta FBA kritikája az, hogy az alkotó csomópontok törékeny struktúráihoz vezet, lehetővé téve a topológiai forgatókönyveket, ahol egyetlen csomópont meghibásodása hálózati szintű hibát okozhat. Ezért az FBA egy egyedi Csomópontlista (UNL) topológiának nevezett speciális beállítása elsőbbséget élvez, amely hangsúlyozza az egyértelműséget és a könnyű használatot, miközben fenntartja az FBA nyílt tagsági tulajdonságát. Az UNL százalékos átfedése egy irányítás által meghatározott paraméter, alacsonyabb átfedéssel javítva a hálózat nyílt tagsági tulajdonságát. A Flare hálózat kihasználja az Ethereum virtuális Gépet (EVM), lehetővé téve a hálózat számára a Turing teljes intelligens szerződések futtatását.

hálózati indításkor, a Flare tetejére építve egy protokoll, amely biztonságosan lehetővé teszi az XRP megbízhatatlan kiadását, használatát és visszaváltását a Flare-en. Ezt a protokollt FXRP-nek hívják. Az XRP biztonságosan és megbízhatatlanul FXRP-vé válik a Flare-en, amelyet a flare natív tokenje, a Spark biztosít. Az XRP jelenleg egy Turing-teljes hálózaton létezik, és ha már ott van, akkor a többi hálózattal való bizalom nélküli interoperabilitás megvalósítható mind az interoperabilitási protokollok, például a Cosmos és a Polkadot, mind az Ethereum jól definiált hídprotokollokon keresztül. Röviden: Flare lehet használni, mint egy intelligens szerződés platform XRP vagy a trustless csővezeték XRP más hálózatokra.

továbbá az fxrp általános módszertana kiterjeszthető bármely nem Turing-teljes Tokenre, és a hálózat rendszereibe és irányításába beépíthető annak eldöntése, hogy mely más tokeneket támogassa, majd bővítse az ehhez szükséges eszközöket.

a Flare egyesíti a nem Turing-teljes tokenek értékét az intelligens szerződések átalakító erejével egy olyan hálózaton, amely az értéket és a tranzakciós teljesítményt is méretezheti.

FXRP áttekintés

az XRP flare-re való bejutásának összetettsége az, hogy nincs mód arra, hogy egy nyilvános blokkláncon lévő intelligens szerződés vezérelje az XRP főkönyvi címet. Ennek oka az, hogy az intelligens szerződéseknek jelenleg nincs megfelelő módja a titkos kulcs valódi titkos tárolására. Ahhoz, hogy az XRP csak a kód használatával fáklyára kerüljön, a résztvevők egy csoportjának össze kell állnia egy több aláírási címmel, amelyet együttesen ellenőriznek, amikor ha k n fél aláír egy tranzakciót, akkor a tranzakció engedélyezett. A multisig-cím által kibocsátott eszköz bármely felhasználójának meg kell bíznia a felhasználók gyűjteményében, így az eszköz nem lesz sem megbízható, sem decentralizált.

az FXRP biztonságosan lehetővé teszi az XRP-tulajdonos (kezdeményező) számára, hogy elküldje XRP-jét az XRP főkönyvi címek (úgynevezett ügynökök) halmazára. Az fxrp Intelligens szerződések Flare majd kiadja a kezdeményező FXRP Flare, amely 1: 1 átváltható XRP és biztosított Spark. Amikor az FXRP birtokosa be akarja váltani az XRP-re ( Megváltó), visszaküldik az fxrp intelligens szerződéseinek a Flare-en. Az ügynökök ezután elküldik az XRP-t az XRP főkönyvi beváltók címére. Ha az ügynökök nem teljesítik ezt a visszaváltást elég gyorsan, a Megváltó kompenzálja az XRP értékét, plusz egy összeget az XRP visszavásárlásának tranzakciós költségeinek kompenzálására.

az FXRP-vel nincs szükség központosított közvetítőre.

az FXRP a következőképpen működik:

a Flare natív tokenjének, a Sparknak a tulajdonosai elküldhetik tokenjeiket a Flare intelligens szerződéseinek gyűjteményébe, amelyeket FXRP rendszernek neveznek. Azok a felhasználók, akik ezt teszik, biztosítékot nyújtanak az FXRP rendszerhez. Ügynöknek nevezik őket. Hívjuk az egyik ügynököt Bobnak. Az FXRP rendszerben sok ügynök lesz.

tegyük fel, hogy Bob 5000 Spark tokent helyezett be az FXRP rendszerbe. Ebben a példában jelenleg 10 Spark token vásárolható meg 1 XRP tokenért. Az FXRP rendszer 2,5-es biztosítékarányt igényel, ami azt jelenti, hogy egy ügynöknek mindenkor 2,5-szer kell megadnia a rendszernek annak az FXRP-nek az értékét, amelyet a rendszer Spark tokenekben osztott fel nekik. Az FXRP értéke itt 1: 1 az XRP-vel. Ezért a Bob 5000 Spark tokenje lehetővé teszi a rendszer számára, hogy 200 FXRP-t adjon ki.

amikor valaki, mondjuk Alice, fxrp-t akar létrehozni, tranzakciót küld az FXRP rendszerbe az XRP értékének 0,1% – ának rögzített díjával, amelyet FXRP-be akarnak verni. Alice-t kezdeményezőnek nevezik. A tranzakció azt is megmondja az FXRP rendszernek, hogy milyen címre küldje el az FXRP-t a Flare-en, miután verték, és milyen címről származik az XRP az XRP főkönyvben. Ha rendelkezésre áll kapacitás az FXRP rendszerben, a létrehozandó FXRP összegének biztosítására szolgáló biztosíték egy bizonyos időszakra zárolva van Alice közelgő tranzakciójával szemben. Így Alice – nek nem kell bíznia bobban. Cserébe egy sor utasítás jön létre Alice számára, hogy megmondja neki, milyen címre (Bob címére) küldje el az XRP-t az XRP főkönyvben, és milyen utolsó főkönyvi indexet használjon. Ha a rendszerben nincs kapacitás a kívánt FXRP összeg kiadására, akkor Alice visszatéríti a díjat.

Alice ezután elküldi a megfelelő mennyiségű XRP-t, plusz egy létrehozási díjat XRP-ben Bob címére az XRP főkönyvben. A létrehozási díj annak a pénznek a nagy része, amelyet Bob keres a szikra fedezetének lezárásáért, vegye figyelembe, hogy jövedelme túlnyomórészt az XRP-ben van. A Flare ezt a tranzakciót a flare fehér könyv 2.szakaszában meghatározott Állapotcsatlakozó (és egy jövőbeli blogbejegyzés tárgya) segítségével figyeli meg. Az FXRP-t ezután a rendszer veri, és eljuttatja Alice jelölt címére a Flare-en.

a 2,5-szeres biztosítékarányt mindenkor fenn kell tartani. Ha az XRP ára növekszik a Spark ellen, úgy, hogy Bob biztosítékának értéke 2 alá esik.5-ször az fxrp ellen kiadott, akkor Bobnak korlátozott ideje van arra, hogy további Spark tokeneket adjon biztosítékként, vagy vásároljon és váltson be FXRP tokeneket, hogy a biztosíték aránya visszatérjen a sorba. Például mondjuk 200 FXRP tokent bocsátanak ki Bob 5000 Spark tokenjeivel szemben, és az XRP/Spark ára 12-re emelkedik. Bobnak most hozzá kell adnia az 1000 Spark-ot a rendszerhez, vagy meg kell vásárolnia és beváltania a 33.34 FXRP-t, hogy csökkentse a kibocsátott FXRP felosztását 166.66-ra.

Ha Bobnak nincs hozzáférése további Spark tokenekhez, akkor pénzügyileg nem megterhelő számára, hogy csökkentse a címe által támogatott FXRP egyenlegét. Bob biztosítéka lehetővé tette az FXRP rendszer számára, hogy 200 FXRP tokent adjon ki, ennek során Bob 200 XRP tokent kapott az XRP főkönyvön. Így ha Bobnak Nincs további tőkéje a Spark tokenek megvásárlásához, akkor vagy eladhat elegendő XRP-t az FXRP-hez egy olyan tőzsdén, hogy legalább 33.34 FXRP-t válthasson be, vagy tisztán decentralizált környezetben maradhat, ha vannak más ügynökök az FXRP rendszerben, elegendő többlet biztosítékkal. A második forgatókönyv lényegében áthelyezi a kötelezettséget a rendszer többi részére. Ha Bob nem tesz semmit, és nem teljesíti a fedezeti arányt, akkor Bob biztosítékát automatikusan elárverezik az ellene kibocsátott FXRP összegére, amely ebben az esetben 200. Bob megtartja a fennmaradó biztosítékot a művelet után.

tegyük fel, hogy Bob úgy döntött, hogy további Spark biztosítékként. Most valamivel később Alice, aki az összes 200 kibocsátott FXRP tulajdonosa, a teljes összeget vissza akarja váltani az XRP főkönyvébe. Alice egyszerűen tranzakciót hajt végre az FXRP rendszerrel, és elküldi az FXRP-t a rendszernek, és elmondja neki, hogy milyen címet szeretne jóváírni. A rendszer ezután utasításokat ad Bobnak, hogy elmondja neki, mennyi XRP-t kell küldenie, és hol, valamint két XRP főkönyvi határidővel, ameddig a tranzakciót be kell fejezni. Ha Bob befejezi a tranzakciót az első határidőig, a biztosítéka teljesen feloldódik. Ha Bob az első határidőig kudarcot vall, de a másodikra sikerrel jár, kis összegű büntetési díjat számítanak fel, a többi biztosítékot pedig feloldják. A büntetési díjat elégetik.

Ha Bob nem teljesíti a tranzakciót a második határidőig, azt visszaváltási hibának nevezzük. Alice-t ezután Spark tokenekkel kompenzálják a megváltott XRP értékére, plusz 1% – os növekedéssel az XRP visszavásárlásának tranzakciós költségeinek fedezésére, ezt Bob biztosítékából vonják le. Bob fennmaradó biztosítékának 50% – át büntetésként elégetik, a másik 50% – ot pedig visszaadják neki. Alice lehet majd vásárolni csere XRP egy csere. Alternatív megoldásként, feltételezve, hogy vannak más ügynökök a Flare-en kibocsátott FXRP-vel, és olyan emberek, akik el akarják adni, Alice több FXRP-t vásárolhat a Flare-en, és beválthatja azokat az ügynökök ellen.

Spark és függő alkalmazások

az FXRP az első példa valamire, amit Spark függő alkalmazásnak (SDA) nevezünk. Az SDA-t olyan alkalmazásként definiálják, amely az építés során a következők kombinációját használja: spark for collateral, a Flare Time Series Oracle és a Spark token tulajdonosok az irányításhoz. Ezen elemek mindegyike teljesen opcionális, és egy alkalmazás csak a Spark-szal együttműködve működhet a flare-en a tranzakciós költségek megfizetése érdekében. Például az FXRP a Spark-ot használja biztosítékként, a Flare Time Series Oracle-t az XRP/Spark árhoz, valamint a Spark token tulajdonosi készletét bizonyos paraméterek, például az FXRP létrehozási díja és a fedezeti arány irányításához. Az SDA modell célja, hogy sablont biztosítson a három komponens mindegyikének tetszőleges számú alkalmazásra történő kiterjesztésére. A Spark fedezetként történő használata minden alkalmazásban egyszerű, a legfontosabb elem annak mérlegelése volt, hogy miként lehet biztonságos oracle módszertant létrehozni több idősoron keresztül.

Flare Time Series Oracle

A Spark token tulajdonjoga lehetővé teszi a hozzájárulást a Flare Time Series Oracle (FTSO). Az FTSO célja, hogy pontos becsléseket készítsen a láncon kívüli Fáklyákról, miközben megőrzi a decentralizációt. Az FTSO úgy van felépítve, hogy számos becslést adjon az egyes idősorokról. Az XRP / Spark ár egy példa egyetlen idősorra.

az ftso minden egyes idősoros kimenete általában két résztvevőcsoporttal rendelkezik: az első a Spark token tulajdonosai, a második pedig a függő alkalmazás token tulajdonosai, amelyet F-eszköznek neveznek. Az FXRP alkalmazásban az F-eszköz maga az FXRP token. Egy összetettebb alkalmazás, mint egy származékos alkalmazás, ahol az alkalmazás több idősort igényel, az F-eszköz valami hasonlóbb lehet egy kiadott irányítási tokenhez.

minden idősor esetében az FTSO felkéri a résztvevők minden releváns csoportját, hogy adjanak becslést. A Spark-tulajdonosok becsléseket adnak az összes idősorra vonatkozóan, az F-eszköz tulajdonosai pedig csak az F-eszközükhöz kapcsolódó idősorokra vonatkozóan adnak becsléseket. Ezeket a becsléseket ezután a rendszer feldolgozza a Fellángolási fehér könyv 4.szakaszában meghatározottak szerint.

az F-eszközök tulajdonosainak ösztönzése arra, hogy adatokat szolgáltassanak a rendszernek, az alkalmazásuk biztonsága. A Spark token tulajdonosokat ösztönzi az oracle reward nevű valami keresésének lehetősége. Ez egy olyan mennyiségű Spark token, amelyet a rendszer vert. Az oracle jutalom egy éves kamatláb, amely egyenletesen oszlik meg az egyes ftso becslési időszakokban. Például, ha az arány 10%, akkor egy évben 365 becslés van, és a Spark tokenek kezdő száma 100, akkor 10 Spark jön létre 1 év alatt, és ~0,03 Sparkot vernek és jutalmaznak naponta. A Spark token közreműködői ezt a jutalmat “helyesnek”tekintett adatok hozzájárulásával szerezhetik meg. A pontos mechanikát a fehér könyv tartalmazza. Fontos, hogy az all Spark token tulajdonosok implicit módon be vannak kötve a rendszerbe, mintha nem járulnának hozzá a jutalomhoz, vagy “helytelen” becsléseket adnak, amelyek elveszítik értéküket a jutalmazott token tulajdonosok számára. Ez Flare változata blokk jutalmak.

az FTSO a következő árak megadását kezdeményezi: XRP/Spark, USD/Spark, BTC/Spark és XLM/Spark. Csak az XRP/Sparknak lesz megfelelő F-eszköze az elején. További idősorok és kapcsolódó F-eszközök javasolhatók és elfogadhatók az irányítási folyamaton keresztül.

delegálás

az FTSO valójában néhány másodpercenként becsléseket ad. Nem minden Spark tulajdonos akar vagy képes futtatni hardvert, hogy hozzájáruljon az FTSO-hoz, és külön-külön lehet, hogy nem érdekli a hálózati irányítás szavazása. Ezért mindkét felelősség szavazata leválasztható magáról a tokenről, és külön átruházható más pártokra. A delegálás bármikor törölhető, és amikor egy tokent egyik címről a másikra továbbítanak, a delegálás automatikusan törlődik, így a szavazati jogok a tokennel együtt járnak. A mechanizmus lehetővé teszi az SDA-k, például az FXRP számára, hogy a Spark szavazatokat visszaküldjék a végső tulajdonosnak, aki ezt követően újra átruházhatja ezeket a szavazatokat olyan entitásokra, amelyekre a nevében szavazni akar. Tehát, ha Bobnak 5000 Spark tokenje van az FXRP alkalmazásban, akkor a tokenek szavazatait a Bob által megadott címre delegálja. Ha Bob azt akarja, hogy egy dedikált adatszolgáltató hozzájáruljon az FTSO-hoz az ő nevében, akkor Bob újra átruházhatja az ftso-ra vonatkozó szavazatait az adatszolgáltatóra. Fontos, hogy ez azt jelenti, hogy Bobnak nem kell választania a Spark megszerzése között azáltal, hogy biztosítékot nyújt az FXRP alkalmazáshoz, és potenciálisan megszerezheti a jutalmat az FTSO-tól, mindkettőt megteheti. Bármely SDA, amely a Spark tokeneket nem teszi elérhetővé az alapul szolgáló tulajdonosok számára, feltéve, hogy az alkalmazásban van egy meghatározás arról, hogy ki az alapul szolgáló tulajdonos, végrehajthatja a delegálási eljárást.

kormányzás& Alapítvány

a Flare-t teljes egészében a Spark token tulajdonosai irányítják szavazás útján. Az SDA-k opcionálisan kérhetik, hogy a Spark token tulajdonosai irányítsák őket.

bizonyos döntések automatizált módon hozhatók meg a láncon, mint például a tranzakciós költség megváltoztatása, az oracle jutalomaránya, vagy az FXRP-t SDA-ként tekintve, a biztosíték arányának és a létrehozási díjnak a megváltoztatása. Más döntések, mint például egy új idősor hozzáadása az FTSO-hoz, a javasolt F-eszköz összekapcsolása, a hálózati konszenzus paramétereinek megváltoztatása vagy a bonyolultabb hosszú távú frissítések kódmódosítást igényelnek. A Flare fehér könyv javaslatot, fejlesztési és tesztelési rendszert határoz meg a kézi változtatásokra, amelyeket a Spark token tulajdonosai kezdeményezhetnek és szavazhatnak meg. Ennek a folyamatnak a végrehajtásához és az elfogadott változtatások végrehajtásához egy Flare alapítvány lesz. Az Alapítvány nonprofit lesz, amelyet az elkövetkező hónapokban be kell építeni. 5 kulcsfontosságú területért felel: támogatások, beruházások, kutatás és fejlesztés, oktatás, nyilvánosság és partnerségek.

Ez a kutatási és fejlesztési funkció, amely lehetővé teszi az alapítvány számára, hogy a hálózati frissítési folyamat szerves része legyen, még akkor is, ha a javasolt hálózati kódváltozásokat elemzi, jelentést készít, majd elkészíti, teszteli és telepíti.

az alapítványnak nagyon átláthatónak kell lennie, és nem szabad pénzt pazarolni. Évente két jelentést tesz közzé és tesz közzé tevékenységeiről és kiadásairól. Az alapítvány célja csak az, hogy irányt vegyen a Spark token tulajdonosaitól, nem pedig a napirend kitűzésére. Mint ilyen, nem járulhat hozzá semmilyen módon az FTSO-hoz, nem telepítheti Spark-részesedéseit biztosítékként a hálózat bármely alkalmazásához, és nem használhatja Spark-részesedéseit semmilyen irányítási szavazáson való szavazáshoz. Lehet, hogy nem rendeli hozzá a Spark tokeneket másoknak. Ezenkívül az alapítvány alkotmányába be lesz írva az a kötelezettség, hogy ha egy kormányzati szavazás beleegyezik abba, hogy az alapítvány már nem szolgál hasznos célt, akkor az alapítványnak a lehető leghamarabb le kell állítania tevékenységét, és fel kell égetnie az összes fennmaradó token-részesedését.

Spark Kibocsátás

a legjobb közösség, amely birtokolja az eszközt, amely lehetővé teszi az XRP használatát a Turing complete smart contracts használatával, az a közösség, amely használni fogja és profitál belőle: XRP tulajdonosok. Flare nem csinál ITO-t. Ehelyett azt csinálja, amit közüzemi villának nevezünk. Úgy gondoljuk, hogy ez az első a maga nemében.

a fork hagyományosan arra törekedett, hogy egy meglévő hálózat felhasználói bázisát vegye fel, és teljesen eltérjen attól a hálózattól, általában antagonista kapcsolatban áll az eredeti lánccal. Ezzel szemben a közüzemi Villa célja, hogy értéket hozzon vissza az eredeti lánchoz, ahelyett, hogy eltávolodna tőle. A Flare lehetővé teszi az XRPL számára, hogy azt tegye, amit a legjobban tud, gyors elszámolást, miközben az xrpl-hez, az intelligens szerződésekhez és a megvalósíthatósághoz hozza létre a trustless csővezetéket más blokkláncokhoz. Úgy gondoljuk, hogy ez egy igazán hatékony kombináció és a hasznosság tökéletes példája.

100 milliárd Spark token jön létre, hogy tükrözze a létező XRP mennyiségét. Körülbelül 45 Bn XRP token van, amelyek nem tartoznak a Ripple labs – hoz. A disztribúció célja, hogy a Ripple-től eltérő XRP-tulajdonosok körülbelül 1:1 mennyiségű szikrát igényelhessenek XRP-birtokukba. Az 45 Bn Spark az XRP tulajdonosai által igényelhető (az ismert Ripple labs címek eltávolítása). Az 25 Bn Spark a Flare Networks Limited-hez kerül, amely a Flare profitorientált szervezete. 30 milliárd szikra megy a Flare alapítványhoz.

mivel sok XRP tulajdonos ténylegesen cseréket használ az XRP tokenek megtartására, fennáll annak a lehetősége, hogy az XRP birtokosa, aki Spark tokeneket kíván igényelni, nem képes erre, mert vagy a csere igényli a Sparkot, és megtartja őket, ahelyett, hogy továbbadná őket, vagy alternatívaként egyáltalán nem követeli meg őket. Annak érdekében, hogy az XRP tulajdonosai részt vehessenek a terjesztésben, vagy nyomást gyakorolva a cserére a Spark tokenek terjesztésére, vagy az exchange áthelyezésére, az XRP főkönyv pillanatképe az indításhoz közelebb eső időpontban készül. A részt vevő cserék listáját közzéteszik a Flare weboldalán, és rendszeresen frissítik. A pillanatfelvétel főkönyvi száma a pillanatfelvétel elkészítésekor a webhelyre kerül.

TL;DR

Flare a világ első Turing teljes Bizánci Szövetségi megállapodás (FBA) hálózat. Integrálja az Ethereum virtuális Gépet (EVM), és nem a tokenből származik a biztonság. Ezen felül épül egy protokoll, amely biztonságosan lehetővé teszi az XRP megbízhatatlan kiadását, használatát és visszaváltását a Flare-en. Ezt a protokollt FXRP-nek hívják. A protokoll és a Flare-t más hálózatokkal összekötő rendszer általános módszertana kiterjeszthető bármilyen nem Turing-teljes Tokenre. A más hálózatokkal való megbízhatatlan interoperabilitás megvalósítható mind az interoperabilitási protokollok, például a Cosmos és a Polkadot, mind az Ethereum segítségével jól definiált hídprotokollok révén.

Flare ‘ s token, Spark jön létre, mi lehet az első utility villát, amellyel a származási hálózat, ebben az esetben a XRP főkönyvi, előnyök révén fokozott hasznosság. A Flare hálózat kezdetén 100 milliárd Spark tokent hoznak létre, ebből 45 milliárdot a meglévő XRP-tulajdonosok igényelhetnek, kivéve a Ripple Labs-t. Ez tükrözi az elosztott XRP meglévő mennyiségét, így a jelenlegi XRP-tulajdonosok körülbelül 1 Spark tokent igényelhetnek minden megtartott XRP-tokenhez. 25 milliárd token kerül a fejlesztőkhöz, a Flare-hez, 30 milliárd token pedig a Flare foundation nevű nonprofit alapítványhoz. A Spark token tulajdonosok megtérülést szerezhetnek Spark tokenjeiken mind a Spark tokenek biztosítékként történő elkötelezettségével az FXRP megbízhatatlan kibocsátásának és visszaváltásának biztosítása érdekében, mind az adatok hozzájárulásával a Flare time series oracle-hez. Ezek a funkciók nem versenyeznek egymással.

a Spark tokent a hálózat szavazáson keresztüli irányítására használják. A flare fejlesztését elősegítő támogatások és beruházások kivételével az alapítvány a Spark token tulajdonosaitól veszi át a technikai irányítást. Az alapítvány kulcsfontosságú szerepe, hogy segítse a hálózat frissítéseinek és változtatásainak végrehajtását, a kormányzási szavazással egyetértésben, amelyek kódmódosítás nélkül nem valósíthatók meg. Fontos, hogy az alapítvány alkotmányába írva olyan alapszabály lesz, amely szerint az alapítványt fel kell számolni, és az alapítvány által tartott összes szikra tokent el kell égetni, ha a szikra token tulajdonosai egyetértenek abban, hogy létezése már nem előnyös a hálózat számára.

a Flare egyesíti a nem Turing-teljes tokenek értékét az intelligens szerződések átalakító erejével egy olyan hálózaton, amely az értéket és a tranzakciós teljesítményt is méretezheti.

válaszok két kérdésre:

A Spark létrehozza a hátsó ajtó tétjének bizonyítékát?

csak olyan kibocsátott tokenek vannak biztosítva, amelyek biztosítékot igényelnek, mint például az FXRP. A hálózat nem használja a Spark-ot a biztonság érdekében, hogy konszenzusra jusson.

nagyon erős elképzeléseink voltak egy USD-ben denominált stabil érmével kapcsolatban, de ehhez az Ethereum virtuális gép alapos áttervezésére volt szükség, ami késleltette volna a bevezetést, és kiszámíthatatlan hatással volt az EVM-mel való jövőbeli kompatibilitásra. A Spark felépítése sokkal nagyobb hasznosságot és előnyöket kínál mind az XRP közösség, mind az XRP ledger számára.