Wprowadzenie.
W ostatnim poście na blogu, udostępniliśmy wam symulator modelu autopeeringu IOTA Research Team, wraz z pierwszymi wynikami. W tej drugiej części serii postaramy się dać Wam jasny przegląd algorytmu autopeeringu i jego funkcjonowania.
Po pierwsze, dlaczego ważne jest, by automatycznie porównywać się z innymi z pewnym stopniem losowości? Mówiąc jaśniej, jeśli nowy nod połączy się w sieci z innymi, które zostały mu przedstawione jako sąsiedzi, informacje otrzymane przez pierwszy nod będą bardzo podobne do informacji dostępnych dla drugiego noda. Tworząc coś w rodzaju komory echa. Co więcej, dzięki takiemu rozwojowi sieci atakujący może mieć przewagę w wybranym rejonie, udostępniając dużą ilość złośliwych nodów nowo przybyłym nodom/użytkownikom w sieci.
Dlatego naszym celem jest wdrożenie algorytmu, który zapewnia:
- dobre właściwości topologiczne (tj. właściwości związane z układem nodów w sieci) aby umożliwić dobrą zbieżność wbudowanego mechanizmu głosowania
- znikome prawdopodobieństwo, że atak ze strony złośliwego noda zakończy się sukcesem
W tym celu wprowadziliśmy algorytm, który łączy w sobie trzy różne zmienne:
- zmienną którą można zweryfikować
- zmienną która jest nieprzewidywalna
- zmienną która jest związana z czymś ograniczonym
Algorytm autopeeringu.
W tym miejscu wyjaśnimy, jak przebiega proces autopeeringu po zakończeniu wykrywania noda, ponieważ jest on odwzorowany w udostępnionym symulatorze. Każdy z nodów będzie miał ustawione:
- public node id (ciąg 32 bajtów)
- public salt (ciąg 20 bajtów)
- private salt (ciąg 20 bajtów)
Definiujemy żądany dystans między węzłami A i B w następujący sposób:
d_req(A,B) = hash(node_id(A)) XOR hash(node_id(B)+pub_salt(A))
Aby zażądać nowego połączenia, nod A obliczy wartość d_req(A,B) dla wszystkich znanych mu nodów i uporządkuje nody według dystansu. Następnie zacznie wysyłać żądania połączenia od najbliższego do najdalszego noda, aż ilość 1k połączeń zostanie zaakceptowana przez inne nody, a skutkiem tego będzie nawiązanie połączenia
Definiujemy również akceptowalny dystans pomiędzy nodem A i B w następujący sposób:
d_acc(A,B) = hash(node_id(A)) XOR hash(node_id(B)+priv_salt(A))
Nod A zaakceptuje żądanie z Noda B w każdym przypadku, gdy:
- zaakceptował mniej niż 1k zapytań
lub
- d_acc (A, B) jest mniejsza od przyjętego dystansu do jednego z jego zatwierdzonych peerów. W takim przypadku nod A zerwie połączenie z najdalszym akceptowanym nodem.
Okresowo nody będą zmieniać swoje „salt” i aktualizować wszystkie odległości. Zauważ, że każdy węzeł będzie dążył do utworzenia 2k połączeń, 1k połączeń utworzony poprzez zwrócenie się do innych nodów, i 1k połączeń poprzez akceptację wniosków od innych nodów.
W jaki sposób ten algorytm zapobiega atakom?
Po pierwsze, skupmy się na publicznym/prywatnym systemie Salt. Wymagane dystanse zależą wyłącznie od informacji publicznych. W ten sposób nody mogą zweryfikować, czy dany wniosek jest prawdopodobnie uzasadniony, czy też nie, oceniając, czy odległość ma odpowiedni rząd wielkości. To już trochę utrudnia pracę atakującemu, ponieważ teraz będzie musiał „wydobywać public salt”, która zlokalizuje go wystarczająco blisko noda, który chce zaatakować. Ponadto, jeśli salt są generowane z wykorzystaniem łańcuchów haszowych, nody angażują się w długą sekwencję ciągu, co praktycznie uniemożliwia podtrzymanie udanego ataku przez dłuższy czas.
Teraz, jako że akceptacja połączenia będzie zależała od zmiennej znanej tylko ofierze ataku (private salt), to jest to całkowicie nieprzewidywalne dla atakującego czy nawiąże udane połączenie z celem. Spowoduje to jeszcze większe zawężenie możliwych strategii , pozostawiając w praktyce jedynie metodę prób i błędów jako jedyną możliwą strategią ataku. To prowadzi nas do ostatecznego elementu systemu: Mana (jeszcze nie zaimplementowane w symulatorze). Jeśli zestawić zdefiniowane powyżej odległości z różnicami mana, algorytm ustali połączenia pomiędzy węzłami o podobnych ilościach mana. Ponieważ mana ma być deficytowym zasobem, żaden z atakujących nie będzie miał wystarczająco dużo jej, aby spróbować ataku metodą prób i błędów na uczestniczące w sieci nody. To sprawia, że nasze autopeering jest najbardziej obiecującym, losowym, zautomatyzowanym, trudnym do oszukania algorytmem peeringu wśród głównych DLT.
Mamy nadzieję, że podobała Ci się ta krótka seria o modelu autopeeringu! Jak zawsze wszystkie pytania i komentarze są mile widziane, tutaj lub na naszym serwerze Discord.
Powyższy tekst jest tłumaczeniem postu z języka angielskiego który oryginalnie ukazał pod tym adresem.
