În această serie formată din trei părți, vom dezvălui realizările tehnologice capabile să îmbunătățească semnificativ procesarea datelor aplicațiilor care rulează pe protocolul de internet computer (ICP).
Această actualizare este o piatră de hotar Stellarator în foaia de parcurs a ICP și este în prezent promovată în întreaga rețea. Stellarator este o descoperire revoluționară în stocarea datelor pe lanț, permițând fiecărei subneturi să găzduiască peste 1TB de memorie, oferind oportunități pentru aplicații bogate în date care au fost anterior limitate de stocare.
Această progresie permite dezvoltatorilor să construiască aplicații complexe care necesită procesarea de date la scară largă, aducând un nou nivel de utilitate tehnologiilor blockchain.
Fără alte ceremonii, să începem această serie și să vedem cum ICP folosește acum actualizările Stellarator pentru a stoca date.
Persistența datelor pe internet computer
Această postare pe blog oferă o prezentare generală a modului în care funcționează stocarea pe mașinile replicat ale internet computer, axându-se în special pe recentele modificări introduse prin stocarea bazată pe structuri de fuziune a jurnalelor (LSMT), care includ realizarea unei replicări mai mari a stocării în subnetul internet computer și îmbunătățirea capacității acestora de a gestiona sarcini de lucru intensive.
Internet computer este format din subneturi și mașini virtuale care efectuează aceeași replicare pe 13-40 de mașini de replicare. Fiecare replicat este responsabil pentru executarea tuturor mesajelor trimise către acel subnet și stochează toate datele containerului, astfel încât toate replicile au un stat complet și identic al subnetului.
Dezvoltatorii pot desfășura containere pe internet computer. Containerele sunt similare cu contractele inteligente de pe alte blockchain-uri, dar pot efectua calcule mai generale și pot stoca de ordinul mai mare de date decât contractele inteligente de pe alte lanțuri.
Datele stocate în container trebuie în cele din urmă să fie păstrate pe un anumit hardware fizic. Datorită introducerii recente a stratului de stocare bazat pe LSMT și a multor altor optimizări și îmbunătățiri, subneturile de pe internet computer pot stoca până la 1TB de date ale containerului.
Cea mai mare parte a datelor din containere este stocată fie în memoria heap (până la 4GB la scriere), fie în memoria stabilă (până la 500GB la scriere). Există și alte forme de date asociate cu containerele, cum ar fi codul containerului, mesajele aflate în procesare și diverse informații, cum ar fi lista de controlere și soldurile Cycles.
Stratul de stocare ICP închide diferența dintre stocarea containerelor (de exemplu, heap și memorie stabilă) și hardware-ul de stocare al mașinilor replicat de bază (de exemplu, disc și RAM).
Ca parte a pietrei de hotar Stellarator, stratul de stocare a fost reproiectat și implementat pe scară largă pentru a permite ICP să facă față provocărilor de scalabilitate viitoare și pentru a aborda cele mai importante obstacole de scalabilitate ale vechiului strat de stocare. Toate modificările relevante au fost finalizate recent, iar internet computer funcționează acum cu noua implementare a stratului de stocare de câteva luni.
Restul acestei postări pe blog va discuta procesul de reproiectare a stratului de stocare ca structură de date a arborilor de fuziune a jurnalelor, reproiectare care vizează eliminarea obstacolelor legate de stocare și oferirea unei experiențe mai bune utilizatorilor și dezvoltatorilor containerelor care consumă multă stocare.
Pentru utilizatorii ICP, cel mai notabil lucru este că acest lucru a permis statului replicat pe un singur subnet să crească recent la 1TB. În plus, reproiectarea a permis internet computer să gestioneze mai bine containerele care scriu cantități mari de date.
Punct de verificare
În general, stratul de stocare al internet computer combină stocarea persistentă de pe disc cu stocarea temporară în RAM. Un concept cheie despre cum internet computer își stochează starea este ceea ce se numește punct de verificare, un punct de verificare este un moment logic în care întreaga stare a subnetului este stocată pe disc.
Punctele de verificare sunt create la fiecare 500 de blocuri sau la intervale de câteva minute într-o manieră deterministă, ceea ce înseamnă că toate replicile vor scrie același punct de verificare la aceeași înălțime. Punctele de verificare sunt stocate sub formă de directoare de fișiere pe discurile fiecărui nod replicat, structura directorului este următoarea (foarte simplificată):
În această structură, fiecare container este stocat în propriul său subdirector, iar fiecare director de container conține fișiere separate pentru memoria heap, memoria stabilă și alte informații (precum mesajele aflate în procesare). Există mai multe motive pentru care datele sunt salvate pe disc sub formă de puncte de verificare.
1. Persistența datelor: Mașinile replicat pot fi repornite în orice moment, codul replicat ar putea avea erori software, hardware-ul ar putea să nu funcționeze sau ar putea exista probleme cu alimentarea centrului de date. În astfel de cazuri, se poate reîncărca cel mai recent punct de verificare.
Vă rugăm să rețineți că, chiar și atunci când un punct de verificare este creat doar la fiecare 500 de tururi, replicile pot recrea starea pentru înălțimi non-punct de verificare. Replica are nevoie doar de cel mai recent punct de verificare și de toate blocurile finale între punctul de verificare și cel mai recent stat. Deoarece toate execuțiile sunt deterministe, aceste blocuri pot fi redate, iar starea recreată va fi exact aceeași. Blocurile necesare pot fi stocate separat de punctul de verificare pe disc sau pot fi obținute de la alte replici.
2. Sincronizare: Toate mesajele (replicate) sunt executate de toate replicile, astfel încât, pentru orice înălțime h dată, toate replicile ar trebui să aibă aceeași stare. Protocolul împiedică divizarea prin procesarea mai întâi a stării prin hashing, apoi semnarea pragului hash-ului generat. Numai atunci când cel puțin ⅔ (mai exact 2f + 1) din replici sunt de acord cu același hash, se poate crea o astfel de semnătură de prag, astfel încât subnetul să poată continua să funcționeze.
Cu toate acestea, subneturile internet computer pot avea un stat mai mare. La momentul scrierii, limita este de 1TB, iar menținerea a până la 2.5 blocuri pe secundă (ceea ce cel mai rapid subnet de pe internet computer poate realiza acum) face imposibilă hasharea unei cantități atât de mari de date după fiecare bloc. Prin urmare, internet computer face hash doar asupra unei părți selectate din starea non-punct de verificare, incluzând, de exemplu, unele informații de bază despre fiecare container, răspunsurile recente la mesajele de intrare și mesajele XNet trimise către alte subneturi.
Pentru punctele de verificare, protocolul va face hashing întregii stări pentru a obține o structură de date numită listă de verificare. Această listă de verificare este calculată prin hashing toate fișierele din directorul punctului de verificare și include hash-urile tuturor fișierelor individuale fragmentate în blocuri de 1MB. La finalizarea calculului listei de verificare, se va calcula hash-ul rădăcinii listei de verificare, acoperind toate hash-urile individuale din listă, iar subnetul va semna această listă de verificare prin prag. Calculul listei de verificare poate dura câteva zeci de secunde, dar această muncă se face doar la fiecare 500 de blocuri și se execută în paralel cu executarea containerului în fundal.
3. Sincronizarea stării: Internet computer permite modificarea topologiei subnetului prin propunerile NNS. Atunci când nodurile replicat se alătură subnetului, acestea pot obține cel mai recent punct de verificare de la alte noduri replicat. Amintiți-vă că punctul de verificare este o colecție de fișiere, astfel că, după verificarea semnăturii de prag a rădăcinii sale și a listei de verificare a subnetului, protocolul de sincronizare a stării poate obține fișierele bloc cu bloc, comparând valorile hash ale blocurilor obținute cu cele din lista de verificare. Dacă toate verificările au succes, replica poate concluziona că starea obținută corespunde stării agreate a fiecărui subnet la înălțimea punctului de verificare. Sincronizarea stării va fi declanșată de asemenea dacă replica este întârziată din alte motive și decalajul față de starea sănătoasă este prea mare pentru a recupera pur și simplu prin redarea blocurilor.
4. Dimensiunea maximă a stării: În prezent, dimensiunea maximă a stării este de 1TB, iar RAM-ul mașinilor nodurilor replicat este de 512GB, astfel că nu este posibil să se încarce întreaga stare în RAM. Internet computer folosește RAM în principal pentru a păstra cele mai recente date care nu au fost persistente și pentru a cache datele pentru a îmbunătăți performanța.
PageMap și înălțimea non-punct de verificare
Deoarece un punct de verificare este creat doar la fiecare 500 de blocuri, ICP trebuie să ofere un spațiu de stocare diferit pentru starea non-punct de verificare a containerelor. Ideea de bază pe care se bazează stratul de stocare este că aceste date sunt stocate pe disc sub formă de combinație a ultimului punct de verificare, iar orice modificare ulterioară este stocată în RAM.
PageMap este implementarea majorității conținutului stării subnetului pentru replici. Majoritatea stării subnetului este starea containerelor, în special memoriile heap și stabilă ale containerelor.
În prezent, un container poate avea până la 4GB de memorie heap, 500GB de memorie stabilă, iar limita totală de stare a subnetului este de 1TB, dar toate aceste limite ar putea fi modificate în viitor. Ambele tipuri de memorie pot fi citite prin apeluri de containere de copiere (actualizare) și non-copiere (interogare) și pot fi modificate prin apeluri de copiere.
Structura de date PageMap este concepută pentru a permite citiri și scrieri eficiente în memorie și pentru a sprijini scrierea eficientă a punctelor de verificare. Un obiectiv specific este de a face performanța independentă de dimensiunea totală a memoriei. Vă rugăm să rețineți că numele PageMap provine din faptul că toate granularitățile de citire și scriere sunt pagini de 4KB, care este aceeași dimensiune a paginii utilizate de sistemul de operare de bază.
PageMap stochează starea în două straturi. Primul strat se numește stocare și este format din fișierele provenite din punctul de verificare anterior, care reprezintă starea la înălțimea punctului de verificare anterior. Al doilea strat, numit pagini incrementale, reprezintă toate modificările efectuate de la acel punct de verificare și sunt stocate în RAM.
Când se citește din PageMap, datele sunt fie extrase din paginile incrementale, fie citite din fișierele de punct de verificare (dacă lipsesc). Scrierea în PageMap se face prin modificarea paginilor incrementale cu date noi.
Ciclul de viață al punctului de verificare
Principalul obiectiv al stratului de stocare este de a scrie punctele de verificare pe disc și de a menține toate PageMap-uri actualizate. Atunci când scrie un nou punct de verificare, toate paginile incrementale sunt actualizate pe disc, actualizând astfel partea de stocare a tuturor PageMap-urilor.
Pentru a asigura că toate datele sunt păstrate, replicile trebuie să păstreze întotdeauna cel mai recent punct de verificare care a fost semnat prin prag. Aceasta înseamnă că nu este posibil să se suprascrie pur și simplu fișierul vechi de punct de verificare, deoarece orice modificare de acest tip va schimba punctul de verificare anterior înainte ca noul punct de verificare să fie complet scris, existând astfel riscul pierderii de date. În același timp, costul de a scrie un punct de verificare complet pe disc (de până la 1TB) la fiecare 500 de tururi va fi extrem de ridicat. În schimb, crearea unui nou punct de verificare include 3 pași de bază:
„Copierea” punctului de verificare vechi într-un dosar temporar, denumit sugestie;
Modificarea sugestiei pentru a reprezenta datele noului punct de verificare;
Renaming the suggestion to the new checkpoint directory (for atomic creation of new checkpoints).
Primul pas poate fi cel mai costisitor, deoarece cu cât starea este mai mare, cu atât mai mult timp este necesar pentru a copia fișierele. Prin urmare, fișierul de punct de verificare devine mai mare.
Aceasta este exact zona în care formatul de fișier al punctelor de verificare și al structurilor de fuziune a jurnalelor joacă un rol important. Prin utilizarea LSMT, acest pas are un cost scăzut și nu se extinde odată cu dimensiunea stării. Comparativ, înainte de reproiectarea LSMT a stratului de stocare, acest pas era lent și imprevizibil.
Structura de fuziune a jurnalelor
Structura de fuziune a jurnalelor (LSMT) este o structură de date utilizată pe scară largă, în special pentru baze de date. Pe internet computer, ele sunt utilizate ca bază a părții de stocare a PageMaps, un aspect special pe care îl pot rezolva este simplificarea pașilor de „copiere” din ciclul de viață al punctelor de verificare, deoarece toate fișierele sunt scrise o singură dată și niciodată modificate.
Utilizând LSMT, starea (logică) poate fi modificată prin scrierea unor fișiere de acoperire suplimentare. Pentru a citi valoarea unei pagini, algoritmul verifică mai întâi cele mai recent scrise fișiere de acoperire pentru a vedea dacă pagina există în acel fișier. Dacă există, valoarea paginii este citită din acel fișier de acoperire; în caz contrar, se verifică următorul fișier de acoperire mai vechi. În implementarea utilizată pe internet computer, dacă pagina nu există în niciun fișier de acoperire, aceasta este citită ca fiind zero.
Imaginea de mai jos arată un set de trei fișiere de acoperire care reprezintă starea unui container, săgețile verticale arată citirile diferite ale datelor și fișierul care conține datele finale citite.
Ciclul de viață al punctului de verificare LSMT este prezentat mai jos:
Linkarea dură a tuturor fișierelor punctului de verificare anterior într-un dosar temporar, denumit sugestie;
Scrierea unui nou fișier de acoperire care conține toate modificările de la ultimul punct de verificare;
Renaming the suggestion to the new checkpoint directory (for atomicity).
Cheia este că fiecare fișier de acoperire este scris o singură dată și nu va fi niciodată modificat, astfel încât să se poată seta în siguranță mai multe puncte de verificare pe disc și să se partajeze unele fișiere între ele prin linkuri dure. Vă rugăm să rețineți că dacă ciclul de viață al punctului de verificare încearcă să modifice orice fișier, acest proces nu va funcționa, deoarece dacă un fișier are mai multe linkuri dure, modificarea oricărui fișier va schimba datele din toate linkurile dure, compromițând astfel punctele de verificare deja validate.
Structurile de fuziune a jurnalelor pot stoca mai multe versiuni ale aceleași interval de date, ceea ce va duce la un cost de stocare, definit ca raportul dintre dimensiunea totală a tuturor fișierelor de acoperire și dimensiunea logică a datelor reprezentate. În plus, datele pot fi distribuite pe mai multe fișiere.
Pe măsură ce costul de stocare sau numărul de fișiere de acoperire crește, implementarea stratului de stocare va programa fuziuni. Fuziunea reorganizează datele prin obținerea unui set de fișiere de acoperire și înlocuirea acestora cu un singur fișier care conține doar ultima versiune a fiecărei date. Fuziunile sunt programate pentru PageMap-urile cu costuri de stocare deosebit de mari sau cu un număr mare de fișiere și se execută în fundal pentru a nu interfera cu execuția mesajelor containerului.
Designul anterior utilizând Reflinks
Stratul de stocare inițial al internet computer nu s-a bazat pe LSMT. Între anul 2021, când a fost creat internet computer, și 2024, stratul de stocare s-a bazat în mare măsură pe realocare.
Realocarea, uneori denumită și copiere la scriere, este o operațiune de sistem de fișiere utilizată pentru a copia fișiere. Anumite sisteme de fișiere susțin această operațiune; replicile internet computer utilizează sistemul de fișiere XFS care suportă această operațiune. Realocarea diferă de copierea obișnuită a fișierelor prin faptul că nu copiază întreaga conținut a fișierului. În schimb, sistemul de fișiere își amintește ce date sunt partajate între fișierul original și nou, iar realocarea diferă de linkurile dure prin faptul că ambele fișiere pot fi modificate independent unul de celălalt.
În vechea design a stratului de stocare, modul de funcționare al ciclului de viață al punctului de verificare era următorul:
Realocarea tuturor fișierelor punctului de verificare anterior într-un dosar temporar, denumit sugestie;
Modificarea fișierelor din sugestie pe baza tuturor modificărilor de la ultimul punct de verificare;
Renaming the suggestion to the new checkpoint directory.
Un avantaj potențial este că PageMap va fi reprezentat de un singur fișier în punctul de verificare, evitând costurile de stocare, dar pentru a modifica fișierul pentru a se adapta la noua înălțime a punctului de verificare, este necesară realocarea fișierelor corespunzătoare din punctul de verificare anterior, nu linkuri dure.
Avantajele LSMT față de Reflinks
În principiu, realocarea garantează viteza linkurilor dure și disponibilitatea replicării. Din păcate, pe măsură ce cerințele de date ale internet computer cresc (fie în I/O, fie în cantitatea totală de date), din diverse motive, realocarea a devenit un obstacol în calea performanței.
1. Viteza de realocare lentă: Timpul necesar pentru a realoca fișiere poate varia foarte mult. În unele cazuri, poate dura doar câteva secunde, dar în experimente, am observat, de asemenea, că realocarea a 370GB poate dura până la 10 ore. În logica veche a punctelor de verificare de pe Internet Computer, un pas de realocare de 10 ore ar putea duce la stagnarea întregului subnet timp de 10 ore.
Fragmentarea duce la viteze proaste de realocare. În interior, sistemul de fișiere XFS menține o structură de date care mapează diferitele părți ale fișierelor la blocuri de date fizice pe disc. Când costul parcurgerii acestor structuri de date devine prea mare, apare fragmentarea și viteze de realocare mai lente.
Fragmentarea poate fi declanșată în special de următoarea secvență: scriere masivă în fișiere, apoi realocarea acestora, scriere masivă într-o copie, realocarea din nou etc. Din păcate, având în vedere fluxul de lucru al punctelor de verificare pe internet computer, utilizarea masivă a containerelor va declanșa exact acest comportament.
Pe de altă parte, linkurile dure au performanțe constante, nefiind afectate de problemele de fragmentare.
Înainte de introducerea structurii de fuziune a jurnalelor, au fost implementate multe soluții temporare, inclusiv defragmentarea manuală a fișierelor (prin citirea fișierului și scrierea acestuia din nou) și scrierea fișierelor în părți continue mai mari, ambele metode având un cost mai mare în scriere și putând duce în continuare la întârzieri de până la 30 de minute.
2. Dimensiunea maximă a stării: Pe lângă timpul foarte lung de realocare cauzat de fragmentarea excesivă, chiar și fragmentarea moderată va face ca timpul de realocare să fie proporțional cu cantitatea totală de date stocate pe subnet. În implementările anterioare ale stratului de stocare, internet computer a specificat că capacitatea de stocare a fiecărui subnet nu poate depăși 700GB. Această valoare depinde în mare măsură de cât de multe date de fragmentare medie pot fi realocate în 20-30 de secunde.
Atunci când se utilizează linkuri dure, timpul de verificare nu se va extinde în același mod odată cu dimensiunea datelor, eliminând astfel acest obstacol.
3. Performanța slabă în multitasking: Unul dintre obiectivele logice ale punctului de verificare este de a evita cât mai mult posibil operațiile de sincronizare, deoarece execuția containerelor se va opri în timpul punctului de verificare. În mod natural, se pune problema dacă se poate efectua realocarea în fundal (chiar și cu o viteză foarte lentă) în timp ce execuția continuă. Din păcate, experiența arată că nu este posibil să se realoce și să se citească fișiere în același timp, așa că realocarea care se desfășoară în paralel cu execuția va încetini doar execuția.
În noua design a stratului de stocare, linkurile dure sunt executate în paralel și nu se încetinesc reciproc.
4. Cache: După cum s-a menționat anterior, citirea datelor din memorie va implica citirea simultană a datelor din RAM și din fișierele de punct de verificare de bază. Citirea repetată a aceluiași fișier nu va necesita, în general, citiri multiple dintr-un hard disk sau SSD real. În schimb, aceste date vor fi stocate în cache de sistemul de operare. Din păcate, realocarea va interfera cu cache-ul, deoarece, în primul rând, linkul fișierului și apoi citirea din nou din replică nu va folosi cache-ul. Prin urmare, pe internet computer, după scrierea punctului de verificare, se observă vârfuri mari (și lente) în citirile de pe disc, deoarece toate citirile vor comuta la fișierele noi. În plus, calculul explicit (adică calcularea hash-ului tuturor fișierelor de punct de verificare pentru a ajunge la consens) beneficiază, de asemenea, foarte mult de un cache mai bun.
În schimb, atunci când se linkează fișierele dure, toate cache-urile sunt păstrate, orice date citite sau scrise recent, chiar dacă s-au întâmplat în intervalele anterioare de punct de verificare, vor fi de asemenea cache-uite, ceea ce permite o recuperare rapidă.
Rezultate
Stratul de stocare LSMT a fost promovat la toate subneturile internet computer în câteva săptămâni din trimestrul 2 al anului 2024. Imaginea de mai jos arată metricile înainte și după upgrade-ul codului replicat, unde linia verticală roșie indică momentul activării stratului de stocare LSMT.
Prima imagine arată timpul de punct de verificare al subnetului w4rem, care găzduiește containere pentru integrarea Bitcoin. Comparativ cu multe alte subneturi, containerele găzduite de subnetul Bitcoin au încărcături de lucru intensive în scriere, astfel că fragmentarea este o problemă deosebit de îngrijorătoare pentru acest subnet.
Din punct de vedere metric, timpul de punct de verificare a fost redus de la peste 20 de secunde la doar 1-2 secunde, în principal datorită eliminării pașilor de realocare, care ocupau cea mai mare parte a timpului de 20 de secunde.
Pentru utilizatorii containerului Bitcoin, beneficiul este o viteză de răspuns mai rapidă; în timpul punctului de verificare, subnetul nu va procesa apeluri de actualizare sau interogări de copiere. Dacă un utilizator trimite un apel de actualizare sau o interogare de copiere containerului Bitcoin la începutul punctului de verificare, va trebui să aștepte cel puțin 20 de secunde pentru a primi un răspuns. Utilizând stratul de stocare LSMT, aceste răspunsuri inconsistent pot fi practic eliminate.
A doua imagine arată rata de finalizare pe subnetul k44fs; rata de finalizare sau rata blocurilor este numărul de blocuri generate de subnet pe secundă.
Internet computer limitează numărul de instrucțiuni executate pe tură la o valoare care corespunde, grosso modo, cantității de muncă pe care o poate finaliza într-o secundă, astfel încât rata finalizării să poată fi menținută la peste 1 bloc pe secundă.
Înainte de a face upgrade la stratul de stocare LSMT, rata de finalizare a scăzut în mod regulat, corespunzând în totalitate punctelor de verificare. Punctele de verificare afectează rata de finalizare din două motive principale: în primul rând, timpul necesar pentru a crea punctul de verificare, timp în care nu se execută blocuri. După upgrade, impactul în acest sens va fi redus, deoarece timpul de punct de verificare este de obicei mult mai scurt.
Al doilea motiv este că comportamentul de cache al stratului de stocare LSMT este mai bun. În special, pasul de realocare din implementarea veche a stratului de stocare a dus la invalidarea cache-ului. Prin urmare, după un punct de verificare, orice container care citește din memorie va determina replicile să obțină acele date de pe disc, ceea ce este cu câteva ordine de mărime mai lent decât datele disponibile în cache în RAM. Noua structură de stocare LSMT nu suferă de această problemă.
După cum indică metricile, scăderea ratei de finalizare după upgrade a devenit semnificativ mai mică, deoarece punctele de verificare în sine sunt mai rapide și nu mai necesită realocare, iar cache-urile de fișiere nu mai sunt invalidate.
Pentru utilizatorii containerului de pe acest subnet, aceasta înseamnă timpi de răspuns mai rapizi și o capacitate de procesare mai mare.
Concluzie
Reproiectarea stratului de stocare al internet computer pe baza structurii de date a arborilor de fuziune a jurnalelor este o investiție importantă în scalabilitatea și performanța platformei, permițând nu doar activități de lucru care consumă multă memorie, ci și oferind internet computer un stat mai mare pentru containere.
În contextul rulării de mari modele de limbaj pe lanț în inteligența artificială, containerele care operează pe date mari sunt deosebit de interesante. Aceste containere nu depind doar de stocarea unei cantități mari de date, ci se bazează în mod serios pe capacitatea de procesare a I/O.
În plus, aceasta pune bazele pentru îmbunătățiri ulterioare, cum ar fi reducerea volumului de muncă pe calea critică prin utilizarea mai bună a concurenței, ceea ce face ca internet computer să răspundă mai rapid. Experiența stratului de stocare original arată că evitarea realocării este esențială pentru a realiza acest lucru, iar structura de date LSMT poate face acest lucru.
Îți place această postare? Împărtășește-ți gândurile pe canalul DFINITY Developers X, alătură-te călătoriei noastre Stellarator partea 2 de mâine, împreună cu Luc Bläser, pentru a explora persistența ortogonală îmbunătățită.
Conținutul IC care te interesează
Progrese tehnologice | Informații despre proiect | Evenimente globale
Adăugați și urmăriți canalul IC Binance
Fiți la curent cu ultimele noutăți
