Czym jest Flare (FLR)? Proste wyjaśnienie

Czym jest Flare (FLR)?

Flare to blockchain Layer 1. Oznacza to, że Flare jest samodzielną siecią blockchain, na której przetwarzane są transakcje i mogą działać aplikacje.

Flare został opracowany przede wszystkim po to, aby smart contracts mogły uzyskiwać dostęp do danych spoza własnej sieci. Chodzi na przykład o dane cenowe lub informacje o transakcjach na innych blockchainach.

Sieć jest zgodna z EVM. EVM to skrót od Ethereum Virtual Machine. Dzięki tej zgodności Flare może korzystać z wielu narzędzi i smart contracts, które są używane także w ekosystemie Ethereum.

Natywny token Flare nazywa się FLR. Natywny oznacza, że FLR jest własnym tokenem sieci. FLR służy między innymi do opłacania opłat transakcyjnych oraz do wspierania bezpieczeństwa sieci poprzez staking.

FLR jest także używany do governance. Dzięki temu posiadacze tokenów mogą głosować nad określonymi propozycjami i zmianami w sieci.

W przypadku niektórych funkcji FLR można zamienić 1:1 na WFLR. Nazywa się to wrappingiem. Nadal posiadasz wtedy tę samą wartość bazową, ale w formie, którą można wykorzystać w określonych smart contracts.

WFLR można na przykład wykorzystać do delegowania do dostawców danych w Flare Time Series Oracle, czyli FTSO. Są to podmioty, które dostarczają sieci dane, takie jak informacje cenowe. Przy delegowaniu nie przekazujesz swoich tokenów, lecz jedynie przypisujesz swoją siłę głosu do takiego dostawcy danych.

Wszystkie opłaty transakcyjne płacone w FLR są spalane. Oznacza to, że tokeny te są trwale usuwane z obiegu.

Ważnym elementem Flare jest więc udostępnianie danych zewnętrznych dla smart contracts. Dzięki temu aplikacje na Flare mogą korzystać z informacji, które nie znajdują się bezpośrednio na samej blockchainie Flare.

Najważniejsze informacje

• Flare to zgodny z EVM blockchain Layer 1 dla smart contracts i danych zewnętrznych.
• FLR to natywny token używany do opłat transakcyjnych, stakingu, governance i delegowania.
• FTSO dostarcza między innymi dane cenowe dla aplikacji na Flare.
• FDC pomaga smart contracts weryfikować dane spoza Flare.
• Staking walidatorów i delegowanie FTSO to dwa różne sposoby wykorzystania FLR.

Jak działa Flare?

Flare składa się z dwóch ważnych środowisk. Na C-Chain działają smart contracts i aplikacje. P-Chain służy do stakingu i zarządzania walidatorami.

Flare wykorzystuje Proof of Stake do zabezpieczania sieci. Walidatorzy blokują FLR i pomagają weryfikować transakcje oraz bloki.

Protokół konsensusu Flare nazywa się Snowman++. Protokół ten pochodzi z rodziny Avalanche i sprawia, że walidatorzy mogą uzgodnić kolejność oraz ważność transakcji i bloków.

Oprócz tej warstwy sieciowej Flare ma także Flare Systems Protocol. System ten służy do wbudowanych protokołów danych Flare, w tym Flare Time Series Oracle, czyli FTSO, oraz Flare Data Connector, czyli FDC.

Dostawcy danych przekazują do nich informacje. Ich wpływ w systemie zależy między innymi od WFLR, które zostały im delegowane, oraz od FLR stakowanego przez walidatorów na P-Chain. Delegowanie FTSO i staking to dwa różne procesy.

Flare (FLR) - przegląd

Jaką rolę pełni FLR w ekosystemie Flare?

FLR jest natywnym tokenem sieci Flare i pełni kilka funkcji w ekosystemie.

Po pierwsze FLR służy do opłacania kosztów transakcyjnych na Flare. Opłaty te są spalane, dzięki czemu użyty FLR jest trwale usuwany z obiegu.

FLR odgrywa też rolę w bezpieczeństwie sieci. Walidatorzy blokują FLR na P-Chain, a inni użytkownicy mogą delegować FLR do walidatora. W zamian mogą otrzymywać nagrody za staking.

FLR jest również używany do governance oraz do delegowania do dostawców danych w sieci Flare. Do tych zastosowań FLR można zamienić 1:1 na WFLR.

FLR pełni więc rolę w transakcjach, bezpieczeństwie sieci, danych i zarządzaniu Flare.

Jak działa infrastruktura danych Flare?

Flare ma protokoły danych wbudowane bezpośrednio w sieć. Dwa ważne elementy to Flare Time Series Oracle, zwykle nazywany FTSO, oraz Flare Data Connector, czyli FDC.

FTSO dostarcza dane, które często się zmieniają, takie jak dane cenowe. Aplikacje i smart contracts na Flare mogą korzystać z tych danych bez konieczności samodzielnego pobierania ich bezpośrednio ze źródeł zewnętrznych.

FTSOv2 wykorzystuje między innymi block-latency feeds i anchor feeds.

Block-latency feeds to szybkie feedy cenowe, które są aktualizowane mniej więcej przy każdym nowym bloku. Flare tworzy blok średnio co 1,8 sekundy. Oznacza to, że nowe dane cenowe mogą być dostępne bardzo regularnie. Przy każdej aktualizacji wybierany jest zestaw dostawców danych, którzy przekazują informacje.

Anchor feeds działają wolniej i służą do osiągania jednej wspólnej wartości w ustalonych momentach. Dostawcy danych najpierw przesyłają swoje dane, nie ujawniając ich od razu publicznie. Później ujawniają, jaką wartość wysłali. Nazywa się to commit-reveal i pomaga zapobiegać sytuacji, w której dostawcy zmieniają swoje zgłoszenie po zobaczeniu zgłoszeń innych.

Następnie wszystkie poprawne zgłoszenia są łączone w jedną wartość. Flare używa do tego ważonej mediany. Oznacza to, że nie każdy dostawca danych ma taki sam wpływ. Dostawcy z większą siłą głosu mają większy udział w ustalaniu wartości końcowej.

Anchor feeds są aktualizowane co 90 sekund. Służą też jako punkt odniesienia dla szybszych block-latency feeds i pomagają utrzymać ich dokładność w dłuższym okresie.

Dostawcy danych odgrywają więc ważną rolę w FTSO. Użytkownicy mogą delegować siłę głosu swojego WFLR do jednego lub dwóch z tych dostawców. Tokeny pozostają przy tym w ich własnym wallet. Nazywa się to delegowaniem FTSO.

Flare Data Connector pełni inną funkcję. FDC umożliwia weryfikację danych spoza Flare, zanim smart contract ich użyje. Mogą to być na przykład transakcje i płatności na innych blockchainach.

Po weryfikacji dane są przetwarzane w drzewo Merkle. Na Flare zapisywany jest tylko root Merkle. Dzięki dowodowi Merkle smart contract może później sprawdzić, czy określone dane były częścią zweryfikowanego zbioru danych.

Jaką rolę pełnią FTSO i FAssets w Flare?

FTSO sprawia, że aplikacje na Flare mają dostęp do danych, takich jak feedy cenowe. Dane te mogą być następnie wykorzystywane przez inne elementy ekosystemu Flare.

Przykładem są FAssets. FAssets to nadzabezpieczone reprezentacje aktywów z innych blockchainów. Nadzabezpieczenie oznacza, że jako zabezpieczenie utrzymywana jest większa wartość niż wartość wyemitowanych FAssets.

FAssets mają sprawić, że aktywa z sieci o ograniczonej funkcjonalności smart contracts będą mogły być używane w aplikacjach na Flare.

Obecnie działa FXRP, czyli wersja FAsset dla XRP. System FAssets został zaprojektowany tak, aby w przyszłości mógł obsługiwać także inne aktywa bez rozbudowanej funkcjonalności smart contracts.

FAsset nie jest tym samym co pierwotny aktyw na jego własnym blockchainie. Na przykład FXRP to token na Flare, który reprezentuje XRP. Użytkownicy mogą korzystać z FXRP w ekosystemie Flare, a następnie wymienić go z powrotem na XRP na XRP Ledger za pośrednictwem protokołu FAssets.

Do działania FAssets potrzebnych jest kilka elementów Flare. FTSO dostarcza dane cenowe, a FDC pomaga weryfikować transakcje na blockchainie bazowym. Dodatkowo wykorzystywane jest zabezpieczenie do pokrycia wyemitowanych FAssets.

Zabezpieczenie składa się z kilku rodzajów collateral. Agenci używają do tego zatwierdzonych tokenów, a FLR może być używany jako dodatkowe zabezpieczenie w collateral pools.

FAssets są więc zależne od kilku elementów systemu i nie są tym samym co bezpośrednie posiadanie pierwotnego aktywa.

Jak działa staking i delegowanie w Flare?

Staking walidatorów i delegowanie FTSO to dwa różne sposoby wykorzystania FLR w sieci Flare.

W stakingu walidatora blokujesz FLR na określony czas, aby wspierać walidatora na P-Chain. Walidatorzy pomagają zabezpieczać sieć oraz przetwarzać transakcje i bloki.

Aby bezpośrednio delegować FLR do walidatora, potrzebujesz co najmniej 50 000 FLR. Tokeny te są blokowane na minimum 14 dni. Do samodzielnego uruchomienia walidatora potrzebny jest self-bond wynoszący co najmniej 1 milion FLR, z minimalnym okresem 60 dni.

Nagrody za staking są ustalane dla każdego reward epoch i zależą między innymi od wyników wybranego walidatora. Na Flare Mainnet reward epoch trwa około 3,5 dnia.

Delegowanie FTSO działa inaczej. W tym przypadku zamieniasz FLR na C-Chain 1:1 na WFLR. Następnie możesz delegować siłę głosu swojego WFLR do jednego lub dwóch dostawców danych FTSO.

Nie przekazujesz przy tym swojego WFLR dostawcy danych. Tokeny pozostają w Twoim własnym wallet, a delegowana siła głosu liczy się na rzecz wybranego dostawcy.

Dostawcy danych FTSO mogą zatrzymać część nagród jako prowizję. To, ile otrzyma delegator, zależy więc między innymi od wyników dostawcy i ustalonej prowizji.

Jak powstał Flare?

Flare został założony w 2019 roku przez Hugo Philiona, Seana Rowana i Naïri Usher. Projekt początkowo koncentrował się na udostępnianiu funkcjonalności smart contracts i danych zewnętrznych dla zastosowań związanych z różnymi sieciami blockchain.

Genesis mainnetu Flare miał miejsce 14 lipca 2022 roku. Sieć rozpoczęła wtedy najpierw fazę obserwacyjną. Publiczny Token Distribution Event, podczas którego FLR był dystrybuowany do użytkowników, odbył się 9 stycznia 2023 roku.

W momencie genesis, czyli pierwszego bloku sieci, utworzono 100 miliardów FLR. FLR ma 18 miejsc po przecinku.

Po zmianie podziału tokenów w ramach FIP.01 część FLR była rozdzielana przez FlareDrops przez 36 miesięcy. Ta dystrybucja zakończyła się 30 stycznia 2026 roku.

Koniec FlareDrops nie oznaczał zakończenia wszystkich nagród. Nagrody protokołowe, między innymi za staking i delegowanie FTSO, nadal istnieją.

Jakie są zalety Flare?

• Smart contracts i dane w jednej sieci: Flare łączy środowisko zgodne z EVM z wbudowanymi protokołami dla feedów cenowych i weryfikacji danych zewnętrznych.

• Szybkie i okresowe feedy cenowe: FTSOv2 oferuje block-latency feeds aktualizowane mniej więcej przy każdym nowym bloku oraz anchor feeds, które okresowo ustalają wspólną wartość. Dzięki temu aplikacje mogą korzystać z różnych rodzajów danych cenowych.

• Weryfikowalne dane z innych blockchainów: FDC może weryfikować dane z obsługiwanych sieci, w tym Bitcoin, Dogecoin, XRP Ledger i Ethereum.

• Wykorzystanie aktywów z innych sieci: FAssets zostały zaprojektowane tak, aby nadzabezpieczone reprezentacje aktywów z innych blockchainów mogły być używane w aplikacjach na Flare.

• Delegowanie bez przekazywania tokenów: W delegowaniu FTSO możesz delegować siłę głosu swojego WFLR do dostawców danych, a tokeny pozostają w Twoim własnym wallet.

Jakie są wady Flare?

• Dodatkowe kroki przy stakingu walidatora: Aby bezpośrednio stakować u walidatora, FLR trzeba przenieść z C-Chain na P-Chain. Po zakończeniu trzeba ponownie odesłać FLR na C-Chain, jeśli chcesz używać tokenów tam.

• Wysoki próg dla delegowania do walidatora: Do bezpośredniego delegowania do walidatora potrzebne jest co najmniej 50 000 FLR i obowiązuje minimalny lock-up wynoszący 14 dni. Sprawia to, że ta forma stakingu jest mniej dostępna dla mniejszych posiadaczy.

• FAssets zależą od wielu elementów: System korzysta między innymi z agentów, zabezpieczenia, feedów cenowych i danych z blockchaina bazowego. Problemy z którymkolwiek z tych elementów mogą wpłynąć na działanie FAssets.

• Zależność od dostawców danych: FTSO i FDC korzystają z wielu dostawców danych do przekazywania i weryfikacji informacji. Aplikacje korzystające z tych danych pozostają więc zależne od dostępności i prawidłowego działania tych systemów.

• Nagrody za delegowanie nie są stałe: Zysk z delegowania FTSO zależy między innymi od wyników i prowizji wybranego dostawcy danych.

Podsumowanie

Flare to zgodny z EVM blockchain Layer 1, który łączy smart contracts z wbudowaną infrastrukturą dla danych zewnętrznych. FLR jest natywnym tokenem sieci i służy do opłat transakcyjnych, stakingu, governance i delegowania.

Dwa ważne elementy to FTSO i FDC. FTSO dostarcza między innymi dane cenowe, natomiast FDC umożliwia smart contracts weryfikację danych spoza Flare. FAssets rozwijają ten model, czyniąc reprezentacje aktywów z innych sieci użytecznymi w obrębie Flare.

Wiążą się z tym także ryzyka i dodatkowe kroki. Staking walidatora wymaga lock-upu i przeniesienia FLR na P-Chain. Delegowanie FTSO i FAssets są ponadto zależne od różnych elementów i uczestników w sieci Flare.