Preț Flare Network

Uau, lucrurile se mișcă repede! Nu a trecut nici măcar o săptămână de la lansare, iar contul XRP Flare a depășit deja TVL de 2,4 milioane de dolari. Această creștere aduce TVL-ul total al MoreMarkets la 27,74 milioane de dolari. Este minunat să vezi comunitatea XRP sărind în DeFi pe @FlareNetworks.

Alegerea configurației greșite a nodului Flare poate însemna diferența de mii de dolari dacă nu este aleasă corect. Care este adevărata diferență dintre nodurile de arhivă și cele tăiate? După cum am descoperit pe calea cea grea, există trei configurații principale pe care le iau în considerare. Sînt: Non tăiat ("istoric de arhivă/complet") - > bază de date de 5,5 TB (pe Flare & în creștere) - Toate datele pentru cazuri de utilizare specializate - Mai multe săptămâni pentru sincronizare/bootstrap - ✅ CAN interogează blocuri, chitanțe și jurnale/evenimente încă de la geneză - ✅ CAN interogați starea istorică (aceasta înseamnă solicitarea soldului/funcției de vizualizare a contractului/codului contractului/demonstrațiilor merkle/etc la un anumit bloc din trecut, până la geneză) - ✅ POATE interoga starea curentă (de exemplu, obține puterea de vot curentă, soldul contului etc.) Curăţite - Baza de date <1 TB (pe Flare & creștere) - Majoritatea datelor pentru majoritatea cazurilor de utilizare - 1-2 săptămâni pentru sincronizare/bootstrap - ✅ CAN interogează blocuri, chitanțe și jurnale/evenimente încă de la geneză - ⚠️ POATE interoga starea istorică, dar numai la intervale de commit, ceea ce înseamnă că poate fi interogat doar un mic subset de stare istorică. Configurabil cu 'commit-interval', implicit la fiecare 4096 de blocuri. Tăiat + Sincronizare stare - Baza de date <100 GB (pe Flare & în creștere) - Date esențiale potrivite pentru validatori și utilizarea RPC de bază - Ore de sincronizare/bootstrap - ❌NU POT interoga blocuri, chitanțe și jurnale/evenimente de la geneză. Limitat la blocarea acelui nod a început să se sincronizeze și parametrul "state-sync-min-blocks". - ⚠️ POATE interoga starea istorică, dar numai la intervale de commit, dar semnificativ mai restricționat la blocurile recente. - ✅ POATE interoga starea curentă (de exemplu, obține puterea de vot curentă, soldul contului etc.) Deci, pentru validatori sau pasionați care doresc propriul nod RPC, un nod PRUNED cu SINCRONIZAREA STĂRII ACTIVATĂ este ideal. Permite validarea rețelei și trimiterea tranzacțiilor (și citirea stării curente a rețelei) cu spațiu minim necesar pe hard disk. Pentru majoritatea indexării analitice care se bazează pe chitanțe, jurnale de evenimente și blocuri de la geneză, este potrivit un nod PRUNED cu STATE SYNC DISABLED. Pentru depanare avansată și analiză profundă, se recomandă un nod NON PRUNED cu SINCRONIZAREA STĂRII DEZACTIVATĂ. Acum, dacă încă nu vă este clar diferența dintre nodurile de arhivă și nodurile tăiate (așa cum a fost pentru mine), permiteți-mi să vă explic... Nodurile tăiate nu au libertatea deplină de a utiliza funcții precum: - eth_getBalance(adresă, blocare) - eth_getStorageAt(contract, cheie, bloc) - eth_call(contractCall, block) (de exemplu, contract.getBalance({ blockNumber })) … și o serie de alte funcții similare. Observați cum oferă un bloc de interogare? Un nod de arhivare poate furniza orice număr de bloc existent și poate prelua datele respective, cum ar fi soldul unui cont, o stare a contractelor sau codul unui anumit bloc. Celelalte două noduri au aceste funcții disponibile, dar așa cum am menționat, blocul care poate fi interogat este limitat la încercările angajate, care în mod implicit este la fiecare 4096 de blocuri. Deci lipsește o gamă masivă de date, cu atât mai mult pentru nodurile sincronizate de stare. Dacă sunteți atât de dispus și datele sunt valoroase pentru dvs., puteți interoga date la aceste intervale, dar va trebui să calculați ce stare (blocuri) sunt disponibile folosind niște matematică și/sau debug_getAccessibleState. Deci, înainte de a crea un nod de arhivare, să știți că majoritatea oamenilor nu vor avea nevoie niciodată de el. Costă mai mult decât un măgar zburător pentru a găzdui pe servere cloud și este într-adevăr limitat la utilizarea în exploratorii blockchain, indexarea istorică profundă a stării (așa cum este descris mai sus) sau depanarea avansată. De exemplu, un nod tăiat (fără sincronizare a stării) va fi de obicei suficient pentru majoritatea utilizatorilor care utilizează SDK-ul @SubQueryNetwork indexator. Simt nevoia să o reiterez: această configurație a nodului OFERĂ toate jurnalele de evenimente, tranzacțiile etc. Puteți, de exemplu, să indexați fiecare transfer de token ERC20 făcut vreodată pentru orice token sau fiecare revendicare de recompense FTSO făcută vreodată. Sper că acest lucru clarifică confuzia oricui cu privire la diferența dintre aceste configurații de noduri. Aș recomanda să evitați nodurile de arhivare decât dacă aveți nevoie de funcționalitatea sa. Încercați întotdeauna un nod tăiat (fără sincronizare a stării) înainte de un nod de arhivare pentru majoritatea scopurilor de dezvoltare/analiză sau un nod tăiat (sincronizat cu starea) pentru utilizarea RPC de bază sau validatori.