Să presupunem că aveți un sistem de stocare distribuit precum bittorrent sau ipfs și doriți să urmăriți rapoartele de încărcare/descărcare (sau răspuns/cerere) ale colegilor. Cu toate acestea, nu doriți să utilizați un instrument de urmărire centralizat și să păstrați totul peer-to-peer? Poti tu estima raportul u/d în siguranță într-un mod distribuit, fără a copleși sistemul?

Un gând pe care l-am avut a fost să modific HyperLogLog (HLL) cu o combinație a acestui răspuns: Este posibil să creați un sistem de „dovadă de încărcare” pentru urmărirea raportului BitTorrent?.

În acest sistem, toată lumea are perechi de chei publice/private, iar solicitanții includ token-uri semnate pentru fiecare Xmb de date (fiecare token este pentru aceeași cantitate de date). La fiecare cerere către un alt nod, nodul de procesare ar stoca hash-ul jetonului într-un hyperlog sub id-ul solicitantului și returnează un nou jeton de răspuns semnat cu răspunsul. Dacă nodul de procesare returnează un răspuns bun, solicitantul stochează jetonul de răspuns într-un hyperlog sub ID-ul furnizorului.

Dacă ai avut colegi: p1, p2, p3 și ai vrea să calculezi raportul dintre cererile făcute și cererile furnizate pentru p1, ai putea așa ceva de genul:

1. P2 și p3 îmbină hiperlogurile de jetoane de răspuns din p1 în hll_1
2. p2 și p3 îmbină hiperlogurile de jetoane de solicitări de la p1 în hll_2

Raportul cotelor este cardinalitate(hll_1)/cardinalitate(hll_2)

Pentru ca HLL-urile să fie „securizate”, pentru fiecare HLL „bină” care numără zerourile finale ale hashului, înregistrați simbolul și semnătura care a produs hash-ul care are cel mai mare număr de zerouri pe bin. În acest fel, atunci când p2 și p3 își îmbină HLL-urile împreună, ei pot confirma că HLL-urile unul de la celălalt au fost făcute din jetoane semnate și pot respinge dacă semnăturile nu se potrivesc. P1 poate analiza HLL-urile combinate și poate confirma că provin din cererile pe care le-au semnat. Acest lucru ar forța fiecare nod să demonstreze că a văzut jetoanele care alcătuiesc HLL-ul lor.

Atacurile

P1 poate verifica că p2 și p3 sunt sincere verificând HLL-urile raportate. Dacă p2 sau p3 fie subraportează răspunsuri (au primit un răspuns de la p1, dar au decis să nu-l includă în HLL), fie supraraportează cereri (adică p2 ar fi putut primi o solicitare de la p1, dar nu a trimis un răspuns), P1 le poate bloca pur și simplu de la tabelul său de rutare.

P1 și P2 sau P3 s-ar putea înțelege prin schimbul de jetoane fără a lucra, așa că veți avea nevoie în continuare de un tip de serviciu central pentru a emite JWT-uri pentru a controla apartenența la roi și a căuta coluziune.

Un alt unghi de atac este că solicitanții ar putea să își filtreze cererile și să trimită numai cereri care nu cresc HLL (adică asigurați-vă că hash-ul jetonului nu are zerouri finale). Pentru a preveni acest lucru, puteți solicita fiecărui nod să atașeze o sare la jeton înainte ca acesta să fie hashing și inserat în HLL. De asemenea, ar preveni reutilizarea simbolurilor.

Compresie cu pierderi

Se pare că, cu HyperLogLogs, ar trebui să păstrați doar câte semnături aveți pentru a verifica cantități foarte mari (miliarde) de solicitări cu o precizie rezonabilă. Aceste semnături în HLL ar ocupa mult spațiu, dar mult mai puțin spațiu decât stocarea fiecărei cereri!

Puteți îmbina cantități mari de HLL utilizând un DHT precum kademlia pentru a alege noduri pentru a trimite HLL-uri, astfel încât roiul să poată raporta informații despre un anumit nod într-un loc comun.

Sunt sigur că am omis ceva fundamental despre motivul pentru care acest lucru nu ar funcționa sau despre modalitățile de a o îmbunătăți. Funcționează această schemă sau există o modalitate mai ușoară de a o face?