dzisiaj z przyjemnością przedstawiamy nasze szczegółowe plany wdrożenia sieci flary. Plany te można w pełni zbadać, zanurzając się w naszych szkicu białych ksiąg obejmujących Sieć i jej natywny token, Spark (tutaj) oraz bezproblemową integrację XRP z Flare (tutaj). Dokumenty są w formie szkicu i nie będzie zmian optymalizacji od teraz do dnia Flare idzie na żywo. Nie powinno być zmian, które istotnie odbiegają od przedstawionego poniżej przeglądu. W tym poście chcemy podkreślić to, co uważamy za najważniejsze aspekty flary. Minimalnie techniczny przegląd każdego ważnego komponentu zostanie opublikowany w ciągu następnych tygodni, począwszy od tego tygodnia, z omówieniem niezawodnej integracji Flare z XRP, FXRP. Zapnij pasy!

(a TL; DR jest na końcu tego posta.)

co to jest Flare i dlaczego go budujemy?

Flare istnieje, aby rozwiązać dwa kluczowe problemy:

Po pierwsze, i natychmiastowe znaczenie dla budowania naszej branży jest to, że 75% wartości istniejącej w publicznym blockchain nie może być obecnie wykorzystywane w sposób bez zaufania z inteligentnymi kontraktami.

Po drugie, zarówno w perspektywie krótkoterminowej, jak i długoterminowej, istnieją potencjalne problemy z wdrażaniem skalowania dla inteligentnych sieci kontraktowych. Większość nowych sieci używa Proof of Stake lub jego wariantów. Protokoły te czerpią bezpieczeństwo sieci z ich natywnego tokena.

bezpośrednim problemem związanym z Proof of Stake jest to, że konstrukcja konsensusu nie pozwala jeszcze bezpiecznie na alternatywne użycie natywnego tokena. Jeśli posiadacz tokena może uzyskać wyższą rentowność (i bez możliwości cięcia) poprzez zapewnienie zabezpieczenia w celu stworzenia stablecoin niż może to zrobić dzięki stakingowi, to jako racjonaliści ekonomiczni prawdopodobnie to zrobią. To odwraca tokeny od stakowania i kanibalizuje bezpieczeństwo sieci. (Wysoce wnikliwy artykuł na ten temat znajduje się tutaj.) Podejrzewamy, że jest to prawdopodobnie kluczowy powód, dla którego pomimo stosunkowo wyższych kosztów transakcji i znacznie niższej przepustowości transakcji, Ethereum nadal przoduje w DeFi.

w dłuższej perspektywie problem polega na tym, że jako dowód na to, że sieć zyskuje wykorzystanie, a wartość zbudowana na niej wzrasta, wartość tokena stakingowego musi wzrosnąć, w przeciwnym razie sieć stanie się niebezpieczna. Jest to świetne dla inwestorów w tokenie, ale złe dla ludzi, którzy chcą, aby decentralizacja stała się częścią głównego nurtu prowadzenia biznesu. Dlaczego? Ponieważ aby wartość tokenu, która zabezpiecza sieć, wzrosła, kapitał musi zostać przekierowany z innego wykorzystania do zakupu tokenu. Biorąc pod uwagę logiczny punkt końcowy, gdyby inteligentne sieci kontraktowe wykorzystujące proof of stake stały się wszechobecną metodą prowadzenia biznesu, skala przekierowania kapitału wymaganego od innych przedsięwzięć, tylko po to, aby zabezpieczyć wartość zbudowaną na tych sieciach, sprawiłaby, że koszt handlu stałby się niemożliwie wysoki. Z tego powodu jest to niezwykle mało prawdopodobne. Proof of Stake i variants mogą skalować przepustowość transakcji, ale istniejące implementacje nie mogą skalować wartości. Naszym zdaniem Proof of Stake jest raczej przystankiem niż rozwiązaniem.

Jak Flare rozwiązuje te problemy?

Flare to nowy sposób skalowania platform inteligentnych kontraktów, który nie łączy bezpieczeństwa z wartością tokenu. Flare nadal wymaga tokena do działania sieci, głównie w celu powstrzymania transakcji spamowych. Token flary nazywa się Spark. Ponieważ Spark nie ma wpływu na bezpieczeństwo sieci, dobrze nadaje się do umożliwienia niezawodnego korzystania z kompletnych tokenów bez Turinga z inteligentnymi kontraktami.

Flare jest pierwszą na świecie siecią Turinga complete Federated Byzantine Agreement (FBA). Węzły obsługują protokół konsensusu Avalanche z kluczowym dostosowaniem do topologii konsensusu FBA. FBA jest unikalna jako topologia konsensusu, ponieważ osiąga bezpieczeństwo bez polegania na zachętach ekonomicznych, które mogą kolidować z przypadkami użycia o wysokiej wartości i wysokim ryzyku. Krytyka czystego FBA polega na tym, że prowadzi do kruchych struktur węzłów składowych, umożliwiając scenariusze topologii, w których awaria pojedynczego węzła może spowodować awarię całej sieci. Z tego powodu priorytetem jest określone ustawienie FBA zwane topologią Unique Node List (UNL), które podkreśla przejrzystość i łatwość użycia przy zachowaniu właściwości open-membership FBA. Procentowe nakładanie się UNL jest parametrem zdefiniowanym przez zarządzanie, a mniejsze nakładanie się poprawia właściwość open-membership sieci. Sieć Flare wykorzystuje maszynę wirtualną Ethereum (EVM), umożliwiając sieci uruchamianie kompletnych inteligentnych kontraktów.

przy uruchomieniu sieci, zbudowany na szczycie flary jest wtedy protokołem, aby bezpiecznie umożliwić bezproblemowe wydawanie, używanie i wykup XRP na Flarze. Protokół ten nazywa się FXRP. XRP bezpiecznie i niezawodnie staje się FXRP, na Flarze, zabezpieczony natywnym tokenem flary, Spark. XRP istnieje obecnie w kompletnej sieci Turinga, a gdy już tam istnieje, możliwa jest niezawodna interoperacyjność z innymi sieciami, zarówno poprzez protokoły interoperacyjności, takie jak Cosmos i Polkadot, jak i z Ethereum poprzez dobrze zdefiniowane protokoły mostów. W skrócie: Flare może być używany jako platforma smart contract dla XRP lub jako trustless pipeline dla XRP do innych sieci.

ponadto ogólna metodologia FXRP jest rozszerzalna na dowolny pełny token bez Turinga, a możliwość decydowania, które inne tokeny mają obsługiwać, a następnie rozszerzać środki, aby to zrobić, jest wbudowana w systemy i zarządzanie siecią.

Flare łączy wartość kompletnych tokenów bez Turinga z transformacyjną mocą inteligentnych kontraktów w sieci, które mogą skalować wartość, jak również przepustowość transakcji.

przegląd FXRP

złożoność wprowadzenia XRP na Flare polega na tym, że nie ma możliwości, aby inteligentna umowa na publicznym łańcuchu bloków kontrolowała adres w Księdze XRP. Powodem tego jest fakt, że inteligentne kontrakty nie mają obecnie odpowiedniego sposobu przechowywania tajnego klucza w sposób, który jest rzeczywiście tajny. Aby uzyskać XRP na Flare używając tylko kodu, wymagałoby to, aby pewna grupa uczestników zebrała się razem z adresem podpisu multi, który wspólnie kontrolują, przy czym jeśli K Z N stron podpisze transakcję, transakcja jest autoryzowana. Każdy użytkownik aktywów wystawionych przez ten adres multisig musiałby zaufać tej kolekcji użytkowników, a zatem aktywa nie byłyby ani bez zaufania, ani zdecentralizowane.

FXRP bezpiecznie pozwala posiadaczowi XRP (inicjatorowi) wysłać swój XRP do zestawu adresów (zwanych agentami) w Księdze XRP. Inteligentne kontrakty FXRP na Flare następnie wydają inicjatora fxrp na Flare, który jest 1: 1 zamienny z XRP i zabezpieczony Spark. Kiedy posiadacz FXRP chce wymienić go na XRP (Odkupiciela), odsyła go z powrotem do inteligentnych kontraktów FXRP na Flarze. Następnie agenci wysyłają XRP na adres redeemers w Księdze XRP. Jeśli agenci nie zrealizują tego odkupienia wystarczająco szybko, Odkupiciel otrzymuje rekompensatę wartości ich XRP plus kwotę, która zrekompensuje koszty transakcji związane z ponownym wykupieniem XRP.

W przypadku FXRP nie jest potrzebny scentralizowany pośrednik.

FXRP działa w następujący sposób:

właściciele natywnego tokena Flare, Spark, mogą wysyłać swoje tokeny do kolekcji inteligentnych kontraktów na Flare, które są określane jako system FXRP. Użytkownicy, którzy to robią, zapewniają zabezpieczenie systemu FXRP. Zwani są agentami. Zadzwońmy do jednego z agentów Boba. W systemie FXRP będzie wielu agentów.

powiedzmy, że Bob włożył 5000 tokenów Spark do systemu FXRP. W tym przykładzie 10 tokenów Spark można obecnie kupić za 1 token XRP. System FXRP wymaga współczynnika zabezpieczenia 2,5, co oznacza, że przez cały czas agent musi dostarczyć systemowi 2,5 razy wartość FXRP, którą system przydzielił im w tokenach Spark. FXRP jest tutaj wyceniany jako 1: 1 z XRP. Stąd 5000 tokenów Spark Boba pozwala systemowi wydać 200 FXRP.

gdy ktoś, powiedzmy Alice, chce utworzyć FXRP, wysyła transakcję do systemu FXRP ze stałą opłatą w wysokości 0,1% wartości XRP, którą chce zamienić na FXRP. Alice jest określana jako pomysłodawczyni. Transakcja informuje również system FXRP, na jaki adres wysłać FXRP na Flare, gdy zostanie wybity, i z jakiego adresu XRP będzie pochodzić z Księgi XRP. Jeśli w systemie FXRP jest dostępna pojemność, zabezpieczenie w celu zabezpieczenia tworzonej ilości fxrp jest blokowane na pewien czas przed zbliżającą się transakcją Alice. W ten sposób Alice nie musi ufać Bobowi. W zamian generowany jest zestaw instrukcji dla Alice mówiących jej, na jaki adres (adres Boba) wysłać XRP w Księdze XRP i jaki indeks ostatniej księgi użyć. Jeśli w systemie nie ma możliwości wydania żądanej kwoty FXRP, Alice otrzymuje zwrot opłaty.

następnie Alicja wysyła poprawną kwotę XRP plus opłatę za utworzenie w XRP na adres Boba w Księdze XRP. Opłata za stworzenie to ogromna większość pieniędzy, które Bob zarobi za zamknięcie swojego zabezpieczenia iskry, zauważ, że jego zarobki są głównie w XRP. Flare obserwuje tę transakcję za pomocą systemu o nazwie State Connector, zdefiniowanego w sekcji 2 białej księgi Flare (oraz w temacie przyszłego postu na blogu). FXRP jest następnie wybity przez system i dostarczony na wskazany adres Alice na Flare.

współczynnik zabezpieczenia 2,5 x musi być utrzymany przez cały czas. Jeśli cena XRP wzrośnie w stosunku do Spark, wartość zabezpieczenia Boba spadnie poniżej 2.5-krotność fxrp wydanego przeciwko niemu, wtedy Bob ma ograniczony czas, aby dodać więcej tokenów Spark jako zabezpieczenie lub kupić i wymienić tokeny FXRP, aby przywrócić jego współczynnik zabezpieczenia. Na przykład, powiedzmy, że 200 tokenów FXRP jest emitowanych przeciwko 5000 tokenom Spark Boba, a cena XRP/Spark wzrasta do 12. Bob musi teraz dodać 1000 Spark do systemu lub kupić i wymienić 33.34 FXRP, aby zmniejszyć jego przydział wyemitowanych FXRP do 166.66.

Jeśli Bob nie ma dostępu do dodatkowych tokenów Spark, nie jest dla niego finansowo uciążliwe zmniejszanie salda FXRP obsługiwanego przez jego adres. Zabezpieczenie Boba umożliwiło systemowi FXRP wydanie 200 tokenów FXRP, w tym procesie Bob otrzymał 200 tokenów XRP w Księdze XRP. Tak więc, jeśli Bob nie ma dodatkowego kapitału na zakup tokenów Spark, może sprzedać wystarczającą ilość XRP dla FXRP na giełdzie, dzięki czemu może odkupić co najmniej 33.34 FXRP lub pozostać w czysto zdecentralizowanym środowisku, jeśli w systemie FXRP są inni agenci z wystarczającym nadmiarem zabezpieczenia, może wymienić wystarczającą ilość FXRP i natychmiast ją odkupić. Drugi scenariusz zasadniczo przenosi obowiązek na resztę systemu. Jeśli Bob nic nie zrobi i pozostanie w zwłoce w stosunku do wskaźnika zabezpieczenia, zabezpieczenie Boba zostanie automatycznie wystawione na aukcji za kwotę fxrp wyemitowaną przeciwko niemu, która w tym przypadku wynosi 200. Bob zachowuje wszelkie pozostałe zabezpieczenia po tej operacji.

powiedzmy, że Bob zdecydował się dodać dodatkową iskrę jako zabezpieczenie. Teraz jakiś czas później Alice, która jest właścicielem wszystkich 200 wydanych FXRP, chce odkupić całą kwotę z powrotem do księgi XRP. Alice po prostu dokonuje transakcji z systemem FXRP wysyłając FXRP do systemu i mówiąc mu, jaki adres chce zaksięgować. System następnie wydaje zestaw instrukcji dla Boba, informując go, ile XRP wysłać i gdzie wraz z dwoma terminami numeru księgi XRP, w których transakcja musi zostać zakończona. Jeśli Bob zakończy transakcję w pierwszym terminie, jego zabezpieczenie zostanie całkowicie odblokowane. Jeśli Bob nie uda się w pierwszym terminie, ale uda się w drugim, zostanie obciążony niewielką opłatą karną, a reszta jego zabezpieczenia zostanie odblokowana. Opłata karna jest spalona.

Jeśli Bob nie sfinalizuje transakcji w drugim terminie, jest to określane jako niepowodzenie wykupu. Alice jest następnie kompensowana tokenami Spark do wartości odkupionego XRP plus 1% wzrost na pokrycie kosztów transakcji zakupu XRP, jest to pobierane z zabezpieczenia Boba. Z pozostałych zabezpieczeń Boba 50% zostaje spalone jako kara, a pozostałe 50% wraca do niego. Alice może wtedy kupić zamienny XRP na giełdzie. Alternatywnie, zakładając, że są inni agenci na Flare z wystawionym FXRP i ludzie, którzy chcą go sprzedać, Alice może kupić więcej FXRP na Flare i odkupić go przeciwko tym agentom.

Spark and Dependent Applications

FXRP to pierwszy przykład czegoś, co nazywamy aplikacją zależną od Spark (SDA). SDA jest zdefiniowany jako aplikacja, która wykorzystuje w swojej konstrukcji pewną kombinację: Spark dla zabezpieczenia, the Flare Time Series Oracle i posiadaczy tokenów Spark do zarządzania. Każdy z tych elementów jest całkowicie opcjonalny, a aplikacja może działać na Flare tylko współdziałając ze Spark w celu zapłaty kosztów transakcyjnych. Na przykład FXRP używa Spark jako zabezpieczenia, Oracle Flare Time Series dla ceny XRP / Spark i własności tokena Spark ustawionej do zarządzania niektórymi parametrami, takimi jak opłata za utworzenie FXRP i współczynnik zabezpieczenia. Model SDA ma na celu dostarczenie szablonu do rozszerzenia każdego z trzech komponentów na dowolną liczbę aplikacji. Korzystanie ze Spark jako zabezpieczenia we wszystkich aplikacjach jest proste, najważniejszym elementem było rozważenie, w jaki sposób można stworzyć bezpieczną metodologię oracle w wielu szeregach czasowych.

Flare Time Series Oracle

własność tokena Spark pozwala na udział w Flare Time Series Oracle (FTSO). Celem FTSO jest sporządzenie dokładnych szacunków danych dotyczących rozbłysków z poza łańcucha przy zachowaniu decentralizacji. FTSO jest skonstruowany tak, aby dostarczać wiele oszacowań poszczególnych szeregów czasowych. Cena XRP / Spark jest przykładem pojedynczego szeregu czasowego.

każde wyjście szeregów czasowych przez FTSO będzie na ogół miało dwie grupy uczestników: pierwszym z nich są posiadacze tokenów Spark, a drugim posiadacze zależnego tokena aplikacji, który jest określany jako F-asset. W aplikacji FXRP f-asset jest tokenem FXRP. W przypadku bardziej złożonych aplikacji, takich jak aplikacja na instrumenty pochodne, gdzie aplikacja wymaga wielu szeregów czasowych, f-asset może być czymś bardziej zbliżonym do wyemitowanego tokenu zarządzania.

dla każdego szeregu czasowego, FTSO prosi każdego odpowiedniego zestawu uczestników o przedstawienie kosztorysu. Posiadacze iskier dostarczą szacunki dla wszystkich szeregów czasowych, a posiadacze aktywów typu F dostarczą szacunki tylko dla szeregów czasowych związanych z ich aktywami typu F. Szacunki te są następnie przetwarzane zgodnie z definicją w sekcji 4 whitepaper Flare i wyprowadzane przez system.

zachętą dla posiadaczy F-aktywów do przekazywania danych do systemu jest bezpieczeństwo ich stosowania. Posiadacze tokenów Spark są zachęcani do zdobycia czegoś, co nazywa się nagrodą oracle. Jest to ilość Tokenów Spark, które są wybite przez system. Oracle reward to roczna stawka podzielona jednolicie na każdy okres szacowania FTSO. Na przykład, jeśli stawka wynosi 10%, szacunki 365 w ciągu roku i początkowa liczba tokenów Spark wynosi 100, to 10 Spark zostanie utworzonych w ciągu 1 roku i ~0,03 Spark wybite i nagrodzone dziennie. Współtwórcy tokena Spark mogą zdobyć tę nagrodę, przesyłając dane, które są uważane za”poprawne”. Dokładna mechanika jest określona w białej księdze. Co ważne, wszyscy posiadacze tokenów Spark są domyślnie obstawiani w systemie, tak jakby nie zdobyli nagrody poprzez BRAK WKŁADU lub podanie „nieprawidłowych” szacunków, które tracą wartość dla posiadaczy tokenów, którzy zostali nagrodzeni. To jest wersja flary z nagrodami blokowymi.

FTSO zostanie zainicjowany, aby zapewnić następujące ceny dla: XRP/Spark, USD/Spark, BTC/Spark i XLM/Spark. Tylko XRP / Spark będzie miał na początku odpowiedni f-asset. Dodatkowe szeregi czasowe i związane z nimi aktywa typu F mogą zostać zaproponowane i zaakceptowane w procesie zarządzania.

Delegacja

FTSO będzie w rzeczywistości dostarczać szacunki co kilka sekund. Nie każdy posiadacz iskry będzie chciał lub mógł uruchomić sprzęt, aby przyczynić się do FTSO i osobno może nie być zainteresowany głosowaniem za zarządzaniem siecią. W związku z tym głosy dla obu obowiązków mogą być oddzielone od samego tokena i oddzielnie przekazane innym stronom. Delegacja może zostać anulowana w dowolnym momencie, A gdy token jest przenoszony z jednego adresu na drugi, delegacja jest automatycznie anulowana, tak że prawa głosu idą razem z tokenem. Mechanizm umożliwia również SDA, takie jak FXRP, delegowanie głosów Spark z powrotem do ostatecznego właściciela, który może następnie ponownie delegować te głosy dalej do podmiotów, które chcą głosować w jego imieniu. Jeśli więc Bob ma 5000 tokenów Spark w aplikacji FXRP, deleguje głosy z tych tokenów na adres określony przez Boba. Jeśli Bob chce, aby dedykowany dostawca danych przyczynił się do FTSO w jego imieniu, Bob może ponownie przekazać dostawcy danych swoje głosy na FTSO. Co ważne, oznacza to, że Bob nie musi wybierać między zarabianiem Spark poprzez zapewnienie zabezpieczenia aplikacji FXRP a potencjalnie zarabianiem nagrody z FTSO, może zrobić oba. Każdy SDA, który sprawia, że tokeny Spark są niedostępne dla swoich właścicieli bazowych, pod warunkiem, że w aplikacji istnieje definicja, kim jest właściciel bazowy, może wdrożyć procedurę delegowania.

Zarządzanie& Fundacja

zarządzana jest w całości przez posiadaczy tokenów Spark poprzez głosowanie. SDA mogą opcjonalnie zażądać, aby były zarządzane przez posiadaczy tokenów Spark.

niektóre decyzje mogą być podejmowane w sposób zautomatyzowany on-chain, takie jak zmiana kosztu transakcji, stawki Oracle reward lub, patrząc na FXRP jako SDA, zmiana współczynnika zabezpieczenia i opłaty za utworzenie. Inne decyzje, takie jak dodanie nowego szeregu czasowego do FTSO i powiązanie proponowanego F-majątku, zmiana parametrów konsensusu sieciowego lub bardziej złożone długoterminowe aktualizacje, wymagają zmiany kodu. Biała księga Flare zawiera propozycję, zasady rozwoju i testowania ręcznych zmian, które mogą być inicjowane i głosowane przez posiadaczy tokenów Spark. Aby pomóc wdrożyć ten proces i wykonać uzgodnione zmiany, powstanie Fundacja flary. Fundacja będzie organizacją non-profit, która zostanie założona w nadchodzących miesiącach. Ma być odpowiedzialna za 5 kluczowych obszarów: dotacje, inwestycje, badania i rozwój, edukację, promocję i partnerstwa.

jest to funkcja badawczo-rozwojowa, która pozwala Fundacji być integralną częścią procesu aktualizacji sieci, nawet posuwając się do analizy, raportowania, a następnie budowania, testowania i wdrażania proponowanych zmian w kodzie sieci.

fundacja musi być bardzo przejrzysta i nie marnować pieniędzy. Będą przestrzegane i publikowane dwa sprawozdania roczne na temat jej działalności i wydatków. Fundacja ma na celu wyłącznie przyjmowanie wskazówek od posiadaczy tokenów Spark, a nie ustalanie porządku obrad. W związku z tym nie może: wnosić wkładu w FTSO w żaden sposób, wykorzystywać swoich udziałów Spark jako zabezpieczenia dla jakiejkolwiek aplikacji w sieci i nie może wykorzystywać swoich udziałów Spark do głosowania w jakimkolwiek głosowaniu w sprawie zarządzania. W tym celu nie może przypisać swoich tokenów Spark innym osobom. Co więcej, zapisem w konstytucji fundacji będzie obowiązek, że jeśli głosowanie w rządzie zgodzi się, że fundacja nie służy już pożytecznemu celowi, fundacja musi zakończyć swoją działalność i spalić wszystkie pozostałe tokeny przy najbliższej okazji.

emisja Spark

najlepszą społecznością do posiadania aktywów, które umożliwiają korzystanie z XRP z Turing complete smart contracts, jest społeczność, która będzie z niego korzystać i czerpać z niego korzyści: posiadacze XRP. Flare nie robi ITO. Zamiast tego robi to, co nazywamy widelcem narzędzia. Wierzymy, że jest to pierwszy tego rodzaju.

fork tradycyjnie dążył do przejęcia bazy użytkowników istniejącej sieci i odejścia całkowicie od tej sieci, zwykle po to, aby mieć antagonistyczny związek z pierwotnym łańcuchem. W przeciwieństwie do tego, widelec narzędziowy ma na celu przywrócenie wartości oryginalnemu łańcuchowi, zamiast odchodzić od niego. Flare pozwala XRPL robić to, co robi najlepiej, szybkie rozliczanie, przy jednoczesnym doprowadzeniu do XRPL, inteligentnych kontraktów i możliwości stworzenia niezawodnego potoku do innych sieci blockchain. Uważamy, że jest to naprawdę potężne połączenie i doskonały przykład użyteczności.

100 miliardów tokenów Spark zostanie utworzonych w celu odzwierciedlenia ilości XRP, która istnieje. Istnieje około 45 Bn tokenów XRP, które nie należą do Ripple labs. Celem dystrybucji jest to, że posiadacze XRP inni niż Ripple mogą ubiegać się o około 1:1 Ilość iskry do swojego gospodarstwa XRP. 45 BN Spark będzie roszczony przez posiadaczy XRP (usuwając znane adresy Ripple labs). 25 Bn Spark trafi do Flare Networks Limited, która jest organizacją nastawioną na zysk. 30 mld iskier trafi do Fundacji Flare.

ponieważ wielu właścicieli XRP faktycznie korzysta z giełd do przechowywania swoich tokenów XRP, istnieje możliwość, że posiadacz XRP, który chce odebrać tokeny Spark, może nie być w stanie tego zrobić, ponieważ albo Giełda rości sobie prawo do Spark i zatrzymuje je, zamiast przekazywać je dalej, albo alternatywnie nie rości sobie prawa do nich w ogóle. Aby umożliwić właścicielom XRP udział w dystrybucji, naciskając na ich giełdę, aby rozpowszechnili tokeny Spark lub przenieśli exchange do takiego, który to robi, migawka księgi XRP zostanie wykonana w dniu bliżej premiery. Lista uczestniczących wymian będzie publikowana na stronie internetowej Flare i okresowo aktualizowana. Numer Księgi migawek zostanie opublikowany na stronie internetowej po wykonaniu migawki.

TL;DR

Flare jest pierwszą na świecie siecią Federated Byzantine Agreement (FBA). Integruje maszynę wirtualną Ethereum (EVM) i nie czerpie bezpieczeństwa z tokena. Oprócz tego zbudowany jest protokół, który bezpiecznie umożliwia bezproblemowe wydawanie, używanie i wykupywanie XRP na Flare. Protokół ten nazywa się FXRP. Ogólna metodologia protokołu i systemu, który łączy Flare z innymi sieciami, jest rozszerzalna na dowolny pełny token Turinga. Niezawodna interoperacyjność z innymi sieciami jest możliwa, zarówno dzięki protokołom interoperacyjności, takim jak Cosmos i Polkadot, jak i Ethereum za pośrednictwem dobrze zdefiniowanych protokołów mostów.

token Flare, Spark jest tworzony przez to, co może być pierwszym w historii widelcem narzędzia, dzięki któremu sieć origin, w tym przypadku Księga XRP, zyskuje dzięki zwiększonej użyteczności. 100 miliardów tokenów Spark zostanie utworzonych na początku sieci Flare, z czego 45 miliardów będzie należeć do istniejących posiadaczy XRP, z wyłączeniem Ripple Labs. Odzwierciedla to istniejącą ilość rozproszonych XRP, dzięki czemu obecni posiadacze XRP będą mogli odebrać około 1 Token Spark za każdy posiadany token XRP. 25 miliardów tokenów trafi do deweloperów, Flare, a 30 miliardów tokenów trafi do fundacji non-profit o nazwie The Flare foundation. Posiadacze tokenów Spark mogą uzyskać zwrot ze swoich tokenów Spark zarówno poprzez zaangażowanie tokenów Spark jako zabezpieczenia w celu zabezpieczenia bezinteresownej emisji i umorzenia FXRP, jak i poprzez wnoszenie danych do oracle Flare time series. Funkcje te nie konkurują ze sobą.

token Spark służy do zarządzania siecią poprzez głosowanie. Z wyjątkiem dotacji i inwestycji mających na celu pomoc w rozwoju flary, Fundacja przejmuje kierownictwo techniczne od właścicieli tokenów Spark. Kluczową rolą Fundacji jest pomoc w przeprowadzaniu aktualizacji i zmian w sieci, uzgodnionych w drodze głosowania nad zarządzaniem, których nie można wdrożyć bez zmiany kodu. Co ważne, w konstytucji fundacji będzie zapis, że fundacja musi zostać zlikwidowana, a wszystkie tokeny Spark w posiadaniu Fundacji spalone, jeśli posiadacze tokenów Spark zgodzą się, że jej istnienie nie jest już korzystne dla sieci.

Flare łączy wartość kompletnych tokenów bez Turinga z transformacyjną mocą inteligentnych kontraktów w sieci, które mogą skalować wartość, jak również przepustowość transakcji.

odpowiedzi na dwa pytania:

czy Spark tworzy dowód stawki przy tylnym wejściu?

tylko wyemitowane tokeny wymagające zabezpieczenia, takie jak FXRP, są zabezpieczone Spark. Sieć nie wykorzystuje Spark dla bezpieczeństwa w osiągnięciu konsensusu.

mieliśmy (co uważamy za) bardzo silne koncepcje dla stabilnej monety denominowanej w USD, ale wymagało to gruntownej przebudowy maszyny Wirtualnej Ethereum, która opóźniłaby uruchomienie i miała nieprzewidywalny wpływ na przyszłą kompatybilność z EVM. Spark, ponieważ jest zorganizowany, oferuje znacznie większą użyteczność i korzyści zarówno dla społeczności XRP, jak i dla księgi XRP.