11 sie Flare Network, Token Spark, inteligentne kontrakty FXRP i XRP
Dziś zostały przestawione szczegółowe plany dotyczące wdrożenia sieci Flare Network. Plany te można w pełni zbadać, zagłębiając się we wstępne oficjalne dokumenty dotyczące sieci i jej natywnego tokena, Spark oraz integracji nie wymagającej zaufania XRP z Flare. Dokumenty są w wersji roboczej i od teraz do dnia uruchomienia Flare zostaną wprowadzone zmiany optymalizacyjne. Nie powinno być zmian, które w istotny sposób odbiegają od przedstawionego poniżej przeglądu. W tym poście staramy się podkreślić to, co jest najważniejsze we Flare. Minimalnie techniczny przegląd każdego ważnego komponentu zostanie opublikowany w ciągu następnych tygodni, zaczynając jeszcze w tym tygodniu, wraz z przewodnikiem po integracji która nie wymaga zaufania Flare z XRP, FXRP.
Czym jest sieć Flare i po co jest stworzona?
Flare istnieje, aby rozwiązać dwa kluczowe problemy:
Po pierwsze i najważniejsze dla budowania poza naszą branżą jest to, że 75% wartości istniejącej w publicznym łańcuchu bloków nie może być obecnie wykorzystane w sposób bez zaufania w przypadku inteligentnych kontraktów (smart contracts).
Po drugie, z konsekwencjami zarówno krótko-, jak i długoterminowymi, istnieją potencjalne problemy ze sposobem wdrażania dziś skalowania w sieciach inteligentnych kontraktów. Większość nowych sieci korzysta z Proof of Stake lub jego wariantów. Te protokoły zapewniają bezpieczeństwo sieci z ich natywnego tokenu.
Bezpośrednim problemem związanym z Proof of Stake jest to, że projekt konsensusu nie pozwala jeszcze bezpiecznie na alternatywne zastosowania tokena natywnego. Jeśli posiadacz tokenów może uzyskać wyższy zysk (i bez możliwości cięcia), dostarczając zabezpieczenia w celu stworzenia stablecoina niż w przypadku obstawiania, to jako racjonaliści ekonomiczni prawdopodobnie to zrobią. To odwraca tokeny od obstawiania i kanibalizuje bezpieczeństwo sieci. (Tutaj znajduje się bardzo wnikliwy artykuł na ten temat). Podejrzewamy, że jest to prawdopodobnie główny powód, dla którego pomimo stosunkowo wyższych kosztów transakcji i znacznie niższej przepustowości, Ethereum nadal jest liderem w DeFi.
W dłuższej perspektywie problem polega na tym, że gdy sieć Proof of Stake zyskuje na popularności, a wartość zbudowana na jej podstawie wzrasta, wartość tokena obstawiania musi wzrosnąć, w przeciwnym razie sieć stanie się niebezpieczna. Jest to świetne rozwiązanie dla inwestorów w tokenie, ale złe dla osób, które chcą, aby decentralizacja stała się częścią głównego nurtu prowadzenia działalności. Czemu? Ponieważ aby wartość tokena, która zabezpiecza sieć, wzrosła, kapitał musi zostać skierowany do innego celu, aby kupić token. Wracając do logicznego punktu końcowego, jeśli sieci inteligentnych kontraktów wykorzystujące dowód udziału miałyby stać się wszechobecną metodą prowadzenia działalności, skala przekierowania kapitału wymaganego z innych przedsięwzięć, tylko w celu zabezpieczenia wartości zbudowanej w tych sieciach, spowodowałaby koszt handelu niewyobrażalnie wysoki. Z tego powodu jest to niezwykle mało prawdopodobne. Proof of Stake i warianty mogą skalować przepustowość transakcji, ale istniejące implementacje nie mogą skalować pod kątem wartości. Naszym zdaniem Proof of Stake jest bardziej prowizorycznym rozwiązaniem niż rozwiązaniem.
Jak Flare rozwiązuje te problemy?
Flare jest w swej istocie nowym sposobem skalowania platform inteligentnych kontraktów, który nie łączy bezpieczeństwa z wartością jego tokena. Flare nadal wymaga tokena do działania sieci, głównie w celu powstrzymania transakcji spamowych. Token Flare nazywa się Spark. Ponieważ Spark nie ma wpływu na bezpieczeństwo sieci, jest dobrze przystosowany do umożliwienia bez zaufania używania kompletnych tokenów innych niż Turing z inteligentnymi kontraktami.
Flare to pierwsza na świecie kompletna sieć Turinga Federated Bizantine Agreement (FBA). Węzły obsługują protokół konsensusu Avalanche z kluczową adaptacją do topologii konsensusu FBA. FBA jest wyjątkowa jako topologia konsensusu, ponieważ zapewnia bezpieczeństwo bez polegania na bodźcach ekonomicznych, które mogą kolidować z przypadkami użycia o wysokiej wartości i wysokim ryzyku. Krytyką czystego FBA jest to, że prowadzi to do kruchych struktur węzłów składowych, zezwalając na scenariusze topologii, w których awaria pojedynczego węzła może spowodować awarię całej sieci. Z tego powodu określone ustawienie FBA, zwane topologią unikalnej listy węzłów (UNL), jest traktowane priorytetowo, co podkreśla przejrzystość i łatwość użycia, przy jednoczesnym zachowaniu właściwości otwartego członkostwa FBA. Procentowe nakładanie się UNL jest parametrem zdefiniowanym przez zarządzanie, przy czym mniejsze nakładanie się poprawia właściwość otwartego członkostwa sieci. Flare Network wykorzystuje maszynę wirtualną Ethereum (EVM), umożliwiając sieci uruchamianie pełnych inteligentnych kontraktów Turing.
Podczas uruchamiania sieci, protokuł zbudowany na Flare, który umożliwia bezpieczne wydawanie, używanie i wykupywanie XRP na Flare. Ten protokół nazywa się FXRP. XRP bezpiecznie i bez zaufania staje się FXRP na Flare, zabezpieczonym natywnym tokenem Flare, Spark. XRP obecnie faktycznie istnieje w kompletnej sieci Turing, a gdy już tam jest, możliwa jest niezawodna interoperacyjność z innymi sieciami, zarówno za pośrednictwem protokołów interoperacyjności, takich jak Cosmos i Polkadot, jak i Ethereum za pośrednictwem dobrze zdefiniowanych protokołów mostowych. W skrócie: Flare może być używana jako platforma inteligentnych kontraktów dla XRP lub jako niezaufany rurociąg dla XRP do innych sieci.
Ponadto ogólną metodologię FXRP można rozszerzyć na dowolny kompletny token inny niż Turing, 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 innych niż Turing z transformacyjną mocą inteligentnych kontraktów w sieci, którą można skalować pod kątem wartości, a także przepustowości transakcji.
Czym jest FXRP
Złożoność pobierania XRP na Flare polega na tym, że nie ma sposobu, aby inteligentny kontrakt w publicznym łańcuchu bloków kontrolował 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 przy użyciu tylko kodu, pewna grupa uczestników musiałaby mieć wspólny adres z wieloma podpisami, który wspólnie kontrolują, przy czym jeśli k z n stron podpisze transakcję, transakcja jest autoryzowana. Każdy użytkownik zasobu wystawionego przez ten adres multisig musiałby wtedy ufać tej kolekcji użytkowników, a zatem zasób nie byłby ani pozbawiony zaufania, ani zdecentralizowany.
FXRP bezpiecznie pozwala posiadaczowi XRP (inicjatorowi) na wysłanie swojego XRP na zestaw adresów (zwanych agentami) w księdze XRP. Inteligentne kontrakty FXRP na Flare następnie wystawiają pierwotnego FXRP na Flare, który jest konwertowalny 1: 1 z XRP i zabezpieczony Spark. Gdy posiadacz FXRP chce go wymienić na XRP (odkupiciel), odsyła go z powrotem do inteligentnych kontraktów FXRP na Flare. Następnie agenci przesyłają XRP na adres odbiorcy w księdze XRP. Jeśli agenci nie zrealizują tego wykupu wystarczająco szybko, osoba odbierająca otrzyma rekompensatę w wysokości ich XRP plus kwota na pokrycie kosztów transakcji ponownego zakupu XRP.
W przypadku FXRP nie jest potrzebny żaden scentralizowany pośrednik.
Jak działa FXRP?
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. Nazywa się je agentami. Zadzwońmy do jednego z agentów Bob. W systemie FXRP będzie wielu agentów.
Powiedzmy, że Bob umieścił 5000 tokenów Spark w systemie FXRP. W tym przykładzie 10 tokenów Spark można obecnie kupić za 1 token XRP. System FXRP wymaga współczynnika zabezpieczenia na poziomie 2,5, co oznacza, że zawsze agent musiał dostarczyć do systemu 2,5-krotność wartości FXRP, którą system przydzielił im w tokenach Spark. FXRP jest tutaj wyceniany jako 1: 1 z XRP. W związku z tym 5000 tokenów Spark Boba umożliwia systemowi wydanie 200 FXRP.
Kiedy ktoś, na przykład Alicja, chce utworzyć FXRP, wysyła transakcję do systemu FXRP ze stałą opłatą w wysokości 0,1% wartości XRP, którą chce wbić w FXRP. Alice jest nazywana pomysłodawcą. Transakcja informuje również system FXRP, na jaki adres ma wysłać FXRP na Flare, po jego wybiciu oraz z jakiego adresu XRP będzie pochodzić w księdze XRP. Jeśli w systemie FXRP jest dostępna zdolność, zabezpieczenie kwoty tworzonego FXRP jest blokowane na pewien okres przed nadchodzącą transakcją Alicji. W ten sposób Alicja nie musi ufać Bobowi. W zamian generowany jest zestaw instrukcji dla Alicji, informujących ją, na jaki adres (adres Boba) ma wysłać XRP w księdze XRP i jakiego ostatniego indeksu księgi użyć. Jeśli w systemie nie ma możliwości wydania żądanej kwoty FXRP, Alicja otrzymuje zwrot opłaty.
Następnie Alicja wysyła prawidłową kwotę XRP plus opłatę za utworzenie w XRP na adres Boba w księdze XRP. Opłata za utworzenie to ogromna część pieniędzy, które Bob zarobi za zamknięcie swojego zabezpieczenia Spark, zwróć uwagę, że jego zarobki są głównie w XRP. Flare obserwuje tę transakcję za pomocą systemu zwanego State Connector, zdefiniowanego w sekcji 2 białej księgi Flare (i tematu przyszłego wpisu na blogu). FXRP jest następnie wybijany przez system i dostarczany pod wskazany adres Alicji na Flare.
Przez cały czas należy utrzymywać współczynnik zabezpieczenia 2,5x. Jeśli cena XRP wzrośnie w stosunku do Sparka, tak że wartość zabezpieczenia Boba spadnie poniżej 2,5-krotności FXRP wyemitowanego przeciwko niemu, Bob ma ograniczony czas, aby albo dodać więcej tokenów Spark jako zabezpieczenie, albo kupić i wykupić tokeny FXRP, aby przynieść swoje zabezpieczenie stosunek z powrotem do linii. Na przykład, powiedzmy, że 200 tokenów FXRP jest wydawanych na 5000 tokenów Spark Boba, a cena XRP / Spark wzrasta do 12. Bob musi teraz albo dodać 1000 Spark do systemu, albo kupić i wymienić 33,34 FXRP, aby zmniejszyć swój udział w wydanych FXRP do 166,66.
Jeśli Bob nie ma dostępu do dodatkowych tokenów Spark, zmniejszenie salda FXRP obsługiwanego przez jego adres nie jest dla niego obciążające finansowo. Zabezpieczenie Boba umożliwiło systemowi FXRP wydanie 200 tokenów FXRP, w trakcie wykonywania tego 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 albo sprzedać wystarczającą ilość XRP na FXRP na giełdzie, aby mógł wykupić co najmniej 33,34 FXRP, lub pozostać w czysto zdecentralizowanym środowisku, jeśli w systemie FXRP są inni agenci z wystarczająca nadwyżka zabezpieczenia może wyrzucić wystarczającą ilość FXRP i natychmiast je umorzyć. Drugi scenariusz zasadniczo przenosi obowiązek na resztę systemu. Jeśli Bob nie zrobi nic i pozostanie w zwłoce ze współczynnikiem zabezpieczenia, zabezpieczenie Roberta zostanie automatycznie sprzedane na aukcji za kwotę wystawionego FXRP, która w tym przypadku wynosi 200. Bob zachowuje wszelkie pozostałe zabezpieczenia po tej operacji.
Załóżmy, że Bob zdecydował się dodać dodatkowy Spark jako zabezpieczenie. Teraz, jakiś czas później, Alicja, która jest właścicielem wszystkich 200 wyemitowanych FXRP, chce wykupić całą kwotę z powrotem do księgi XRP. Alicja po prostu dokonuje transakcji z systemem FXRP, wysyłając FXRP do systemu i informując go, jaki adres chce, aby został zaksięgowany. Następnie system wydaje zestaw instrukcji Bobowi, informując go, ile XRP ma wysłać i gdzie, wraz z dwoma terminami dotyczącymi numerów 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 zda egzaminu w pierwszym terminie, ale odniesie sukces w drugim, zostanie obciążony niewielką opłatą karną, a reszta jego zabezpieczenia zostanie odblokowana. Opłata karna jest spalona.
Jeśli Bob nie zakończy transakcji w drugim terminie, jest to określane jako niepowodzenie wykupu. Następnie Alice otrzymuje rekompensatę za pomocą tokenów Spark do wartości jej umorzonego XRP plus 1% wzrost na pokrycie kosztów transakcji odkupu XRP, jest to pobierane z zabezpieczenia Boba. Z pozostałych zabezpieczeń Boba 50% zostaje spalone jako kara, a pozostałe 50% zostaje mu zwrócone. Alice może wtedy kupić zastępczy XRP na giełdzie. Alternatywnie, zakładając, że na Flare są inni agenci z wydanymi FXRP i ludzie, którzy chcą go sprzedać, Alice może kupić więcej FXRP na Flare i wymienić je na tych agentów.
Spark i aplikacje zależne
FXRP jest pierwszym przykładem czegoś, co nazywamy aplikacją zależną od iskry (SDA). SDA definiuje się jako aplikację, która wykorzystuje w swojej konstrukcji pewną kombinację: Spark jako zabezpieczenie, The Flare Time Series Oracle i posiadacze 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 wchodząc w interakcję ze Spark w celu pokrycia kosztów transakcji. Na przykład FXRP wykorzystuje Spark jako zabezpieczenie, Flare Time Series Oracle dla ceny XRP / Spark i własność tokena Spark ustaloną do zarządzania niektórymi parametrami, takimi jak opłata za utworzenie FXRP i współczynnik zabezpieczenia. Model SDA ma zapewnić szablon umożliwiający rozszerzenie każdego z trzech komponentów do dowolnej liczby zastosowań. Używanie Spark jako zabezpieczenia we wszystkich aplikacjach jest proste, najważniejszym elementem było rozważenie, w jaki sposób można stworzyć bezpieczną metodologię wyroczni w wielu szeregach czasowych.
Flare Time Series Oracle
Własność tokena Spark pozwala na wniesienie wkładu do Flare Time Series Oracle (FTSO). Celem FTSO jest stworzenie dokładnych szacunków danych dotyczących Flare spoza łańcucha, przy jednoczesnym zachowaniu decentralizacji. Struktura FTSO umożliwia dostarczanie wielu oszacowań poszczególnych szeregów czasowych. Cena XRP / Spark jest przykładem pojedynczego szeregu czasowego.
Każdy szereg czasowy generowany przez FTSO będzie miał na ogół dwie grupy uczestników: pierwsza to posiadacze tokenów Spark, a druga to posiadacze zależnego tokenu aplikacji, który jest nazywany zasobem F. W aplikacji FXRP aktywa F to sam token FXRP. W przypadku bardziej złożonych aplikacji, takich jak aplikacje pochodne, w których aplikacja wymaga wielu szeregów czasowych, składnik F może być czymś bardziej zbliżonym do wydanego tokenu zarządzania.
Dla każdego szeregu czasowego FTSO prosi każdy odpowiedni zestaw uczestników o przedstawienie oszacowania. Posiadacze Spark przedstawią oszacowania dla wszystkich szeregów czasowych, a posiadacze F-Asset dostarczą oszacowania tylko dla szeregów czasowych związanych z ich F-Asset. Szacunki te są następnie przetwarzane zgodnie z sekcją 4 opracowania na temat Flare i generowane przez system.
Zachętą dla posiadaczy aktywów F do dostarczania danych do systemu jest bezpieczeństwo ich stosowania. Posiadacze tokenów Spark są motywowani możliwością zdobycia czegoś, co nazywa się nagrodą wyroczni. Jest to liczba żetonów Spark, które zostały wybite przez system. Nagroda wyroczni to roczny podział stawki równomiernie na każdy okres szacowania FTSO. Na przykład, jeśli stawka wynosi 10%, istnieje 365 szacunków w ciągu roku i początkowa liczba tokenów Spark wynosząca 100, to 10 Spark zostanie utworzonych w ciągu 1 roku i ~ 0,03 Spark bity i nagradzany dziennie. Dostawcy tokenów Spark mogą otrzymać tę nagrodę, przekazując dane, które są uważane za „prawidłowe”. Dokładna mechanika została opisana w białej księdze. Co ważne, wszyscy posiadacze tokenów Spark są niejawnie obstawiani w systemie, tak jakby nie otrzymali nagrody ani przez brak wkładu, albo przez podanie „nieprawidłowych” szacunków, tracą wartość na rzecz posiadaczy tokenów, którzy są nagradzani. To jest wersja nagród blokowych Flare.
FTSO zostanie zainicjowane, aby zapewnić następujące ceny: XRP / Spark, USD / Spark, BTC / Spark i XLM / Spark. Tylko XRP / Spark będzie miał na początku odpowiedni zasób F. Dodatkowe szeregi czasowe i związane z nimi aktywa F można zaproponować i zaakceptować w ramach procesu zarządzania.
Delegacja
W rzeczywistości FTSO będzie przedstawiać szacunki co kilka sekund. Nie każdy posiadacz Spark będzie chciał lub był w stanie uruchomić sprzęt, aby wnosić wkład do FTSO i osobno może nie być zainteresowany głosowaniem w sprawie zarządzania siecią. W związku z tym głosy dotyczące obu obowiązków można oddzielić od samego tokena i oddzielnie przekazać innym stronom. Delegacja może zostać w każdej chwili odwołana, a gdy token jest przesyłany z jednego adresu na drugi, delegacja jest automatycznie anulowana w taki sposób, że prawa głosu są przekazywane z tokenem. Mechanizm umożliwia również SDA, takim jak FXRP, delegowanie głosów Sparka z powrotem do ostatecznego właściciela, który może następnie ponownie przekazać te głosy podmiotom, na które chce głosować w jego imieniu. Więc jeśli Bob ma 5000 tokenów Spark w aplikacji FXRP, przekaże głosy z tych tokenów na adres określony przez Boba. Jeśli Bob chce, aby wyznaczony dostawca danych przyczynił się do FTSO w jego imieniu, Bob może następnie przekazać swoje głosy na FTSO dostawcy danych. Co ważne, oznacza to, że Bob nie musi wybierać między zarabianiem Sparka poprzez dostarczenie zabezpieczenia do aplikacji FXRP a potencjalnie zdobyciem nagrody od FTSO, może zrobić jedno i drugie. Każdy SDA, który sprawia, że tokeny Spark są niedostępne dla ich właścicieli bazowych, pod warunkiem, że w aplikacji znajduje się definicja tego, kto jest właścicielem bazowym, może zaimplementować procedurę delegowania.
Zarządzanie i fundacja
Flare jest w całości zarządzana przez posiadaczy tokenów Spark w drodze głosowania. SDA mogą opcjonalnie zażądać zarządzania przez posiadaczy tokenów Spark.
Niektóre decyzje mogą być podejmowane w sposób zautomatyzowany w łańcuchu, na przykład zmiana kosztu transakcji, stopy nagrody wyroczni lub, patrząc na FXRP jako SDA, zmiana wskaźnika zabezpieczenia i opłaty za utworzenie. Inne decyzje, takie jak dodanie nowego szeregu czasowego do FTSO i powiązanie proponowanego zasobu F, zmiana parametrów konsensusu sieciowego lub bardziej złożone aktualizacje długoterminowe, wymagają zmiany kodu. Biała księga Flare przedstawia propozycję, program rozwoju i testowania ręcznych zmian, które mogą być inicjowane i głosowane przez posiadaczy tokenów Spark. Aby pomóc we wdrożeniu tego procesu i wykonaniu uzgodnionych zmian, zostanie utworzona podstawa Flare. Fundacja będzie organizacją non-profit, która ma zostać włączona w najbliższych miesiącach. Ma odpowiadać 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, posuwając się nawet do analizy, raportowania, a następnie budowania, testowania i wdrażania proponowanych zmian w kodzie sieci.
Fundament musi być bardzo przejrzysty i nie marnować pieniędzy. Dwa sprawozdania rocznie na temat jego działań i wydatków zostaną wykonane i opublikowane. Fundacja ma na celu tylko przyjmowanie wskazówek od posiadaczy tokenów Spark, a nie ustalanie porządku obrad. W związku z tym nie może: w jakikolwiek sposób wnosić wkładu do FTSO, wykorzystywać swoich udziałów w Spark jako zabezpieczenie dla jakiejkolwiek aplikacji w sieci i nie może wykorzystywać swoich zasobów w Spark do głosowania w głosowaniu w ramach zarządzania. Nie może przypisywać swoich tokenów Spark do innych osób, aby to zrobić. Co więcej, w konstytucji fundacji będzie zapisany obowiązek, że jeśli w głosowaniu zarządczym zostanie uzgodnione, że fundacja nie służy już pożytecznym celom, to fundacja musi zakończyć swoją działalność i spalić wszystkie pozostałe udziały symboliczne przy najbliższej okazji.
Wydanie Spark
Najlepszą społecznością posiadającą zasób, który umożliwia korzystanie z XRP z kompletnymi inteligentnymi kontraktami Turing, jest społeczność, która będzie go używać i czerpać z niego korzyści: posiadacze XRP. Flare nie wykonuje ITO. Zamiast tego robi to, co nazywamy rozwidleniem narzędzi. Uważamy, że jest to pierwszy tego rodzaju.
Rozwidlenie tradycyjnie starało się przejąć bazę użytkowników istniejącej sieci i całkowicie od niej odejść, zwykle tworząc antagonistyczny związek z oryginalnym łańcuchem. W przeciwieństwie do tego, fork ma na celu przywrócenie wartości do pierwotnego łańcucha, zamiast oddalać się od niego. Flare pozwala XRPL robić to, co robi najlepiej, szybkie rozliczenia, jednocześnie wprowadzając do XRPL, inteligentne kontrakty i wykonalność tworzenia bez zaufania rurociągu do innych łańcuchów bloków. Uważamy, że jest to naprawdę potężna kombinacja i doskonały przykład użyteczności.
Zostanie utworzonych 100 miliardów tokenów Spark, aby odzwierciedlić ilość istniejących XRP. Istnieje około 45 tokenów XRP Bn, które nie należą do laboratoriów Ripple. Celem dystrybucji jest to, że posiadacze XRP inni niż Ripple mogą ubiegać się o około 1: 1 kwoty Spark do ich zasobów XRP. 45 Bn Spark będzie przedmiotem roszczeń posiadaczy XRP (usunięcie znanych adresów laboratoriów Ripple). 25 Bn Spark przejdzie do Flare Networks Limited, organizacji nastawionej na zysk. 30 Bn Spark 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 Sparka, może nie być w stanie tego zrobić, ponieważ albo giełda przejmuje Spark i zachowuje je zamiast przekazywać, albo alternatywnie w ogóle ich nie żąda. Aby umożliwić właścicielom XRP wzięcie udziału w dystrybucji poprzez wywieranie nacisku na ich wymianę w celu dystrybucji tokenów Spark lub przeniesienie wymiany na taką, która to robi, migawka księgi XRP zostanie wykonana w terminie bliższym uruchomieniu. Lista uczestniczących giełd będzie publikowana na stronie internetowej Flare i okresowo aktualizowana. Numer księgi migawek zostanie opublikowany na stronie internetowej po wykonaniu migawki.
Podsumowanie
Flare to pierwsza na świecie kompletna sieć Turinga Federated Bizantine Agreement (FBA). Integruje maszynę wirtualną Ethereum (EVM) i nie zapewnia bezpieczeństwa z tokena. Ponadto zbudowany jest protokół, który umożliwia bezpieczne wydawanie, używanie i wykupywanie XRP na Flare bez zaufania. Ten protokół nazywa się FXRP. Ogólną metodologię protokołu i systemu, który łączy Flare z innymi sieciami, można rozszerzyć na dowolny kompletny token inny niż Turing. Bez zaufania współdziałanie z innymi sieciami jest możliwe, zarówno za pomocą protokołów interoperacyjności, takich jak Cosmos i Polkadot, jak i Ethereum za pośrednictwem dobrze zdefiniowanych protokołów mostowych.
Token Flara, Spark, jest tworzony za pomocą czegoś, co może być pierwszym rozwidleniem narzędzi, dzięki czemu sieć pochodzenia, w tym przypadku XRP Ledger, zyskuje dzięki zwiększonej użyteczności. 100 miliardów tokenów Spark zostanie utworzonych na początku sieci Flare, z których 45 miliardów będzie do odebrania przez istniejących posiadaczy XRP, z wyłączeniem Ripple Labs. Odzwierciedla to istniejącą ilość rozproszonych XRP, tak że obecni posiadacze XRP będą mogli ubiegać się o około 1 token Spark za każdy posiadany token XRP. 25 miliardów tokenów trafi do programistów, Flare, a 30 miliardów tokenów trafi do fundacji non-profit o nazwie Flare Foundation. Posiadacze tokenów Spark mogą uzyskać zwrot ze swoich tokenów Spark zarówno poprzez przekazanie tokenów Spark jako zabezpieczenia w celu zabezpieczenia wydawania i wykupu FXRP bez zaufania, jak i poprzez dostarczanie danych do wyroczni szeregów czasowych Flare. Te funkcje nie konkurują ze sobą.
Token Spark służy do zarządzania siecią poprzez głosowanie. Z wyjątkiem grantów i inwestycji, które mają pomóc w rozwoju Flare, fundacja przyjmuje techniczne wskazówki od właścicieli tokenów Spark. Kluczową rolą fundacji jest pomoc w przeprowadzaniu uaktualnień i zmian w sieci, uzgodnionych w drodze głosowania, których nie można wdrożyć bez zmiany kodu. Co ważne, do statutu fundacji zostanie wpisane postanowienie, że fundacja musi zostać zlikwidowana, a wszystkie tokeny Sparka znajdujące się w jej posiadaniu spalone, jeśli posiadacze tokenów Spark zgodzą się, że jej istnienie nie jest już korzystne dla sieci.
Flare łączy wartość kompletnych tokenów innych niż Turing z transformacyjną mocą inteligentnych kontraktów w sieci, którą można skalować pod kątem wartości, a także przepustowości transakcji.
XPRING Inwestycja we Flare Networks
Czyli włączanie funkcji Smart Contract dla XRP Ledger
Oto co pisali autorzy z Xpring odnośnie inwestycji we Flare Network w 2019 roku.
W Xpring obsługa nowych przypadków użycia XRP zawsze była kluczowym priorytetem. Wierzymy w interoperacyjność, która napędza powszechne przyjęcie technologii blockchain, szukając możliwości skoncentrowanych na inteligentnych kontraktach, które pokrywają się z interesami naszej branży w zakresie gier i zdecentralizowanych finansów (DeFi).
Z dumą ogłaszamy naszą najnowszą inwestycję w inteligentne kontrakty z Flare Networks, pierwszym w historii protokołem Turing Complete Federated Bizantine Agreement (FBA). Flare Network integruje maszynę wirtualną Ethereum, umożliwiając sieciom publicznym i / lub prywatnym wykorzystanie inteligentnych kontraktów. Podobnie jak XRP Ledger (XRPL), Flare nie wymaga potencjalnie nieskalowalnych zachęt ekonomicznych, aby zagwarantować bezpieczeństwo sieci.
Natywny token Flare będzie algorytmicznym stablecoinem utworzonym częściowo przez spalanie XRP, a płatności za kontrakt można będzie dokonywać i odbierać w XRP za pośrednictwem Interledger, który zostanie zintegrowany z Flare. Flare wykorzysta również adres i system szyfrowania XRP, aby zapewnić użytkownikom XRP praktycznie bezproblemowy sposób interakcji z inteligentnymi kontraktami w sieci Flare.
Zasób cyfrowy przeznaczony do płatności, XRP rozlicza się szybko i taniej do wykorzystania w transakcjach niż inne zasoby cyfrowe obecnie. Użytkownicy i programiści chcieliby wykorzystać XRP w większej liczbie przypadków użycia, a Flare Network umożliwi tę możliwość większej liczbie firm i programistów, którzy chcą wykorzystać XRPL do swoich potrzeb. Flare Network jest obecnie w fazie testów z wczesnymi partnerami, w tym Securitize, Singularity, BuenoBit, Neuhanse Network i wieloma innymi, które zostaną ogłoszone.