În această serie formată din trei părți, vom dezvălui realizările tehnologice care pot îmbunătăți semnificativ procesarea datelor aplicațiilor care rulează pe Protocolul de Calcul Internet (ICP).
Această actualizare este un milestone în foaia de parcurs a ICP, numită Stellarator, care este în prezent desfășurată în întreaga rețea, Stellarator a realizat progrese în stocarea datelor pe lanț și capacitatea de procesare, permițând fiecărui subnet să gestioneze peste 1TB de memorie și să încarce date mai repede, oferind oportunități pentru aplicații bogate în date care anterior erau limitate de stocare și capacitate de procesare.
Această avansare permite dezvoltatorilor să construiască aplicații complexe care necesită procesare masivă de date, aducând un nou nivel de utilitate tehnologiei blockchain.
Ca parte finală a acestei serii, Kamil Popielarz și Yvonne-Anne Pignolet vor împărtăși progresele recente în creșterea capacității de procesare a mesajelor de intrare în internetul computer, dacă ați ratat părțile anterioare ale acestei serii, le puteți găsi aici și aici.
Creșterea capacității de procesare a mesajelor de intrare
Dacă sunteți ca noi, atunci așteptarea ca datele să fie încărcate pe dapp nu este activitatea dvs. preferată, așa că suntem încântați să anunțăm că Sistemul Nervos de Rețea (NNS) lansează optimizări pentru Protocolul de Calcul Internet pentru a îmbunătăți capacitatea de procesare a consensului.
Aceste modificări ale protocolului au redus consumul de lățime de bandă și timpul necesar pentru difuzarea blocurilor, menținând în același timp proprietățile de securitate ale ICP, astfel încât utilizatorii vor petrece mai mult timp interacționând mai rapid cu dapp-ul ICP.
Context
Protocolul de Calcul Internet coordonează nodurile sale de rețea, oferind servicii de calcul descentralizate, chiar și atunci când unele noduri se abat de la protocol.
Este bine cunoscut că ICP poate găzdui aplicații care combină codul și datele, aceste aplicații fiind numite containere, containerele pot procesa mesaje de intrare trimise de utilizatori și pot interacționa cu alte containere prin schimbul și executarea mesajelor.
Nodurile de rețea nu mai copiază execuția fiecărui container pe toate nodurile, ci sunt împărțite în mai multe fragmente, numite sub-rețele, fiecare subnet folosind un protocol de consens robust pentru a asigura execuția și consistența stării containerelor găzduite pe nodurile sale.
Protocolul de consens este responsabil pentru crearea și validarea blocurilor, fiecare bloc conținând un set de mesaje container, iar după ce s-a ajuns la un consens asupra ordinii și conținutului acestor blocuri, nodurile pot executa codul container în mod determinist și consistent, menținând integritatea serviciului de calcul.
Sarcina blocului conține mesaje de intrare trimise de utilizatori, folosite pentru a declanșa apelurile containerului replicate, după primirea mesajelor de intrare de la utilizatori, nodul va efectua o serie de verificări (de exemplu, semnături, dimensiune, timp de expirare), dacă aceste verificări au succes, nodul va adăuga mesajul în piscina sa de intrare și va difuza mesajul către celelalte noduri din subnet folosind protocolul P2P al ICP.
Când vine rândul unui nod să creeze o propunere de bloc, acel nod va include un set de mesaje de intrare din piscina sa de intrare, apoi nodul va difuza această propunere către nodurile de rețea.
Cu toate acestea, deoarece cele mai multe noduri de rețea au deja majoritatea acestor mesaje de intrare în piscinele lor locale, acest proces irosește lățimea de bandă.
O altă dezavantajă a acestei metode este că trimiterea unei propuneri care conține 1000 de mesaje de 4KB către toate nodurile de rețea durează mai mult decât trimiterea unei propuneri care conține 1000 de hash-uri.
Presupunând că replicile au lățimea de bandă minimă sugerată de 300Mbit/s, difuzarea unei propuneri de bloc care conține o sarcină utilă de 4MB către toate nodurile de rețea dintr-un subnet cu 13 noduri necesită: 4MB * (13-1) / 300Mbit/s = 1.28 secunde.
Dacă fiecare hash este mai mic de 50 de biți, aceeași propunere poate fi transmisă către toate nodurile cu o viteză de peste 800 de ori mai rapidă, iar pentru subneturi mai mari, aceste diferențe se acumulează, astfel impactul va fi mai mare.
Optimizare
Pentru a reduce timpul de livrare a propunerilor și consumul de lățime de bandă, protocolul a fost îmbunătățit, permițând nodurilor să includă referințe la mesajele de intrare (hash-uri) în blocuri, în loc de mesaje complete, deoarece nodurile vor difuza oricum mesajele de intrare folosind protocolul P2P, astfel încât replicile ar trebui să fie capabile să recupereze toate mesajele de intrare din piscinele lor respective pentru a reconstrui propunerile de bloc.
Cu toate acestea, este posibil ca unele mesaje de intrare să se piardă în piscina locală a nodului, această situație putând fi cauzată de condiții de rețea slabe, piscine pline, prăbușiri ale nodurilor sau comportamente malițioase ale nodurilor, nodul trebuie să aibă toate mesajele de intrare ale propunerii pentru a verifica și/sau executa propunerea, pentru a obține mesajele de intrare pierdute, nodul poate solicita mesajele pe care nu le are de la nodul de rețea care a publicat propunerea.
Pentru a crește șansele ca toate mesajele de intrare să existe în piscina de intrare a tuturor nodurilor înainte de a propune un bloc care conține hash-urile acestora, anumite aspecte ale implementării piscinei de intrare au fost modificate.
În primul rând, nodurile acum trimit direct mesajele de intrare către nodurile de rețea, în loc să trimită reclame către nodurile de rețea și să aștepte cereri de la acestea, economisind astfel cel puțin o călătorie de întoarcere, ceea ce face ca difuzarea mesajelor de intrare către nodurile de rețea să fie mai rapidă.
În plus, gestionarea dimensiunii piscinei de intrare a fost îmbunătățită, până acum, numărul de mesaje și dimensiunea totală pe care le pot ocupa au o limită globală, iar dacă aceste limite sunt depășite, nodurile vor refuza orice mesaj de intrare difuzat de nodurile de rețea.
Prin urmare, în condiții de sarcină foarte mare, nodurile dintr-un singur subnet ar putea ajunge să aibă piscine de intrare aproape neintersecționate, în această situație, pentru fiecare propunere de bloc, toate nodurile trebuie să ceară toate mesajele de la creatorul de bloc, ceea ce va crește întârzierea și va reduce capacitatea de procesare.
Pentru a rezolva această problemă, limita globală a fost înlocuită cu limita fiecărui nod de rețea, iar până acum, atâta timp cât există spațiu în piscina de intrare pentru acel nod, acesta va accepta mesaje de intrare de la acel nod.
Deoarece la orice moment dat, replicile oneste vor difuza mesajele de intrare către fiecare limită de rețea, putem fi foarte siguri că, chiar și sub o sarcină mare, nodurile din aceeași subnet vor avea piscine de intrare foarte intersecționate.
Pentru a minimiza modificările aduse protocolului global, a fost adăugat un nou component între P2P și consens, responsabil pentru eliminarea mesajelor de intrare din propunerea expeditorului și readăugarea acestora la receptor, restul logicii P2P și consensului rămânând neschimbate.
Evaluarea performanței
Pentru a ilustra impactul optimizărilor, am efectuat experimente într-un subnet de testare cu 13 noduri, aplicând o întârziere de 300ms RTT și limitând lățimea de bandă la 300Mbps.
Experimentele arată că prin transmiterea a numeroase mesaje mici (aproximativ 4KB), capacitatea de procesare a crescut de la 2MB/s la 6MB/s.
Similar, în experimentul nostru în care am trimis mesaje mari (puțin sub 2MB), capacitatea de procesare a crescut de la 2MB/s la 7MB/s.
Vă rugăm să rețineți că în experimente ne-am concentrat doar pe capacitatea de procesare a consensului, iar containerul prin care trimitem mesaje nu a efectuat nicio muncă semnificativă.
Diagrama de mai jos arată capacitatea de procesare din experimentele menționate mai sus:
De asemenea, am efectuat experimente care demonstrează că adăugarea de noduri la subnet (prinderea din urmă) și performanța subneturilor cu multe containere sau multe noduri este cel puțin la fel de bună (și în multe cazuri mult mai bună) decât înainte.
Concluzie
Aceste modificări ale protocolului îmbunătățesc experiența utilizatorului pe internetul computer, punând bazele pentru modificări ulterioare care gestionează mesaje mai mari și mai multe.
Aceste modificări au fost activate în unele sub-rețele de rețea principală, unde puteți experimenta în mod direct beneficiile acestora, de asemenea, se aplică și condițiilor reale de rețea și variațiilor de sarcină, nu doar în cadrul experimentelor mici folosind modele de trafic sintetice.
Vă rugăm să ne spuneți părerile dvs., puteți împărtăși gândurile dvs. oricând pe canalul DFINITY Developers X și pe forumul dezvoltatorilor, și continuați să urmăriți actualizările tehnice viitoare.
Conținut IC care te interesează
Progrese tehnologice | Informații despre proiect | Activități globale
Urmărește canalul IC de pe Binance
Rămâneți la curent cu cele mai recente informații
