Moduł Autopeering
Kilka miesięcy temu udostępniliśmy kod źródłowy GoShimmer, prototyp i narzędzia badawcze IOTA, aby eksperymentować i testować elementy składowe Coordicide. Cieszymy się z tak dużego i produktywnego zaangażowania społeczności i chcemy wszystkim podziękować za wasz wkład i opinie! Były one bardzo przydatne w ulepszaniu GoShimmer, a także pomagały nam zidentyfikować, w jaki sposób lepiej przeprojektować moduł autopeeringu.
Z przyjemnością dzielimy się z tobą kodem źródłowym ulepszonego i przeprojektowanego modułu autopeeringu.
Możesz uzyskać dostęp do kodu z następującego repozytorium:
https://github.com/iotaledger/autopeering-sim
Kontekst
W protokole IOTA, Nod (lub peer) jest maszyną przechowującą informacje o Tangle, podstawowej strukturze danych IOTA. Nody często pełnią również rolę punktu dostępu i wykorzystania Tangle. Aby sieć działała sprawnie, nody wymieniają między sobą informacje o stanie nowej księgi. Obecnie wykorzystywany jest proces ręcznego porównywania lub łączenia węzłów w celu wzajemnego rejestrowania się jako sąsiedzi. Jednakże, ręczne przeglądanie może być przedmiotem ataków (np. socjotechniki), aby wpłynąć na topologię sieci. Aby zapobiec tym atakom i uprościć proces konfiguracji nowych węzłów, wprowadziliśmy w białej księdze Coordicide mechanizm, który pozwala węzłom na automatyczne wybieranie swoich sąsiadów. Proces wybierania sąsiadów przez węzły bez ręcznej interwencji operatora węzła nosi nazwę autopeering.
Celem przeprojektowania modułu autopeeringu jest ułatwienie symulacji przy jednoczesnym zachowaniu tej samej podstawy kodu, która będzie używana w GoShimmer. Możliwość oceny zachowania i wydajności autopeeringu przez symulacje jest bardzo ważna dla IOTA. Pozwala odpowiedzieć na kilka pytań, jak np. ile zapytań peeringowych każdy węzeł musi wysłać średnio zanim zostanie zaakceptowany, jak długo będzie trwało połączenie, jak szybko konwertuje protokół itd. Ponadto stanowi podstawę do badania wektorów ataku w kontrolowanym środowisku.
Projektowanie
Podzieliliśmy logicznie moduł autopeering na dwa główne submoduły: wykrywanie peerów i wybór sąsiadów. Pierwszy z nich odpowiada za operacje, takie jak odkrywanie nowych peerów i sprawdzanie ich statusu online. Ten ostatni odpowiada za wyszukiwanie i zarządzanie sąsiadami dla węzłów IOTA. Zawarliśmy również warstwę sieciową (komunikacja P2P) oraz warstwę pamięci masowej (utrzymujące się informacje od peerów) poprzez wykorzystanie interfejsów Go. Na poniższej ilustracji przedstawiono ogólny zarys konstrukcji:
Dzięki tej konstrukcji można łatwo przełączać się z bazy danych na dużo lżejszą pamięć masową i przełączać się z połączeń między serwerami na komunikację między procesami. Serwery i baza danych są wymagane dla GoShimmera. Zastąpienie ich sprawia, że pisanie wydajnej symulacji działającej na jednym komputerze jest równie proste jak pisanie kilku wierszy kodu.
Symulacja
Jako demonstrujący napisaliśmy symulację, która skupia się na submodule wyboru sąsiada. W symulacji zakładamy, że odkryte peere znają wszystkie węzły w sieci, aby móc ocenić wyłącznie efekt selekcji peerów. Scenariusze z częściowym spojrzeniem na sieć, jak również wyniki wzajemnego odkrywania będą przedmiotem dalszych symulacji i analiz.
Wybór sąsiadów, a w szczególności decyzja o tym, którzy potencjalni sąsiedzi są preferowani, jest podejmowana na podstawie ich odległości. Ta funkcja odległości opiera się na prywatnych i publicznych salt, jak określono w białej księdze Coordicide. Następnym krokiem będzie dodanie funkcji Mana w zależności od odległości.
Obecnie symulacja może być skonfigurowana z następującymi parametrami:
- N: całkowita liczba peerów
- T: czas życia salt(ciągu), w sekundach
- SimDuration: czas trwania symulacji, w sekundach
- VisualEnabled: włączania/wyłączania wizualizacji symulacji, dostępny pod adresem http://localhost:8844 po rozpoczęciu symulacji
- dropAll: przełącznik włączający/wyłączający upuszczanie wszystkich sąsiadów przy każdej aktualizacji salt
Poniższa animacja została zarejestrowana podczas uruchamiania symulacji. Zapewnia nam wizualne przedstawienie procesu komunikacji peerów.
Nowo utworzone połączenia między peerami i są podświetlone na niebiesko, a pytające i akceptujący peery są odpowiednio oznaczone kolorem niebieskim i zielonym. Zerwane połączenia są podświetlone na czerwono.
Pomiary i ocena
Obecnie symulator obsługuje następujące wskaźniki, dla których zapewniamy skrypty oceny:
- Konwergencja: odsetek peerów, którzy mają maksymalną liczbę sąsiadów.
- Czas przeżycia połączenia: prawdopodobieństwo, że dane połączenie jest nadal aktywne po pewnym czasie.
- Analiza wiadomości: statystyki dotyczące liczby wysyłanych i odbieranych wiadomości (żądania peeringowe, odpowiedzi peeringowe i spadki połączeń).
Załączamy również skrypt ewaluacyjny, plot.py, napisany w Pythonie z Matplotlib. Skrypt ten wyodrębnia dane z plików CSV-output, które są wytwarzane przez kod symulacyjny i generuje wykresy zarówno dla konwergencji, jak i czasu przetrwania łącza.
Na przykład na poniższych wykresach widać: a) procent nodów z 8 sąsiadami (w tej konfiguracji 8 to maksymalna liczba sąsiadów) oraz średnią liczbę sąsiadów w czasie, b) prawdopodobieństwo, że dane połączenie przetrwa określoną ilość czasu.
Ponadto, uruchomienie symulacji tworzy plik CSV (wewnątrz folderu danych) z danymi analizy wiadomości. Przykład tego można zobaczyć w poniższej tabeli:
Tutaj, średnia liczba wysłanych zapytań peeringowych (OUTgoing) jest równa średniej liczbie otrzymanych zapytań peeringowych (INcoming). Łatwo jest obliczyć średnią liczbę wniosków peeringowych wysłanych przed otrzymaniem ACCepted: poprzez podzielenie wniosków wychodzących przez przyjęte wnioski. Jest to, w tym przykładzie, 9.17 / 7.03 = 1.3. Możemy również wyciągnąć informacje o tempie, w jakim połączenia są DROPped (zrywane): w tym przykładzie jeden peer jest wymieniany średnio dla każdej przychodzącej wiadomości co 9.17 / 3.03 = 3.02.
Będziemy nadal opracowywać kolejne symulacje do wykrywania peerów i selekcji sąsiadów oraz dodawać je do repozytorium! Naszym celem jest również przeniesienie kodu z symulacji do GoShimmer. Dzięki elastyczności i modułowości autopeeringu i GoShimmera, będzie to możliwe już po kilku adaptacjach. Jeśli wyzwanie brzmi interesująco, serdecznie zapraszamy do pomocy w integracji! Ponadto, oceniamy możliwość integracji autopeeringu z aktualnym protokołem IOTA (z koordynatorem) jako część serii usprawnień dla oficjalnego mainnetu.
W następnej części serii postów autopeering bloga, zanurzymy się głębiej w wewnętrzne funkcjonowanie tego modułu. W międzyczasie mamy nadzieję, że kod ten będzie przydatny dla każdego, kto jest zainteresowany analizą modułu autopeeringu. Zapraszamy do współtworzenia kodu z nowymi funkcjami! Alternatywnie, możesz uruchomić symulację i przekazać informacje zwrotne lub możesz sprawdzić nasz otwarty nabór do programu Coordicide grant, aby dowiedzieć się o dalszych możliwościach współpracy.
Jak zawsze, mile widziane są Państwa komentarze i pytania tutaj albo na oficjalnym serwerze IOTA Discord, w kanale dyskusyjnym #tanglemath lub #goshimmer.
Powyższy tekst jest tłumaczeniem postu z języka angielskiego który oryginalnie ukazał pod tym adresem.
