IOTA Polska
  • Home
  • Podstawy
  • Ogłoszenia
  • Badania i Rozwój
  • Ekosystem
  • Artykuły
  • Zakup IOTA
  • Kontakt
No Result
View All Result
  • Home
  • Podstawy
  • Ogłoszenia
  • Badania i Rozwój
  • Ekosystem
  • Artykuły
  • Zakup IOTA
  • Kontakt
No Result
View All Result
IOTA Polska
No Result
View All Result

Aktualizacja Coordicide – Moduł Autopeering: część 1

Niven przez Niven
4 listopada 2019
w Badania i Rozwój
92
VIEWS
Udostępnij na TwitterzeUdostępnij na Facebooku

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.

Tagi: CoordicideResearch And Development
TweetUdostępnijWyślij
Poprzedni Artykuł

Aktualizacja deweloperska – Październik 2019

Następny Artykuł

Aktualizacja Coordicide – Moduł Autopeering: część 2

Powiązane Artykuły

Wyjaśnienie czym jest Mana w IOTA

Wyjaśnienie czym jest Mana w IOTA

przez Beliar
3 października 2020
0

Jednym z tematów w IOTA 2.0, na który często otrzymujemy pytania, jest mana. To ważny temat, dlatego z przyjemnością wyjaśnimy...

Chrysalis (IOTA 1.5) Etap 2 aktualizacja i kolejne kroki

przez Beliar
29 września 2020
0

IOTA 1.5 Pierwsza faza IOTA 1.5 (znana również jako Chrysalis) - pośredni etap sieci głównej przed Coordicide - jest zakończona....

Aktualizacja deweloperska – Wrzesień 2020

Aktualizacja deweloperska – Wrzesień 2020

przez Niven
26 września 2020
0

Wydawana co miesiąc przez zespół IOTA dev, aktualizacja dostarczy Ci newsów i aktualizacji dotyczących naszych kluczowych projektów! Kliknij tutaj, jeśli...

Aktualizacja deweloperska – Sierpień 2020

przez Niven
18 sierpnia 2020
0

Wydawana co miesiąc przez zespół IOTA dev, aktualizacja dostarczy Ci newsów i aktualizacji dotyczących naszych kluczowych projektów! Kliknij tutaj, jeśli...

Aktualizacja zespołu badawczego IOTA – Sierpień 2020

przez Niven
10 sierpnia 2020
0

Ostatni miesiąc był bardzo produktywny dla naszego zespołu, bowiem zmierzamy w kierunku pełnej, formalnej specyfikacji IOTA 2.0. Nasz team pracował...

Wczytaj Więcej

Newsletter

Otrzymuj powiadomienia o nowych postach

  • Trending
  • Comments
  • Latest

Narzędzie do migracji tokenów IOTA

1 marca 2020

Wartość Zero

6 września 2019

Podsumowanie roku 2019, zapowiedź kolejnego

6 stycznia 2020
IOTA prezentuje identyfikowalność energii w Powerhouse

IOTA prezentuje identyfikowalność energii w Powerhouse

16 września 2019

Chrysalis (IOTA 1.5) Publiczna sieć Testnet dostępna

0
Czym jest DLT?

Czym jest DLT?

0
Prototyp GoShimmer na otwartym oprogramowaniu

Prototyp GoShimmer na otwartym oprogramowaniu

0
Co dalej z Trinity?

Co dalej z Trinity?

0

Chrysalis (IOTA 1.5) Publiczna sieć Testnet dostępna

15 grudnia 2020

Firefly – portfel nowej generacji IOTA

2 grudnia 2020

IOTA, Pantos i Uniwersytet Techniczny w Wiedniu ogłaszają otwarcie laboratorium dla badań DLT

30 listopada 2020

Przedstawiamy IOTA Access

7 października 2020

IOTA Polska

Portal IOTA Polska tworzony jest przez społeczność wspierającą projekt IOTA. Powstał z potrzeby rzetelnego informowania i edukowania osób zainteresowanych tą technologią.

Menu

  • Artykuły
  • Badania i Rozwój
  • Ekosystem
  • Ogłoszenia
  • Podstawy

Tagi

Alvarium Announcements Basic Bee Chronicle Chrysalis Consensus Coordicide Data Data Confidence Fabric Dell Technologies Devnet DLT Eclass Ecosystem Entangled Entra Powerhouse Fiware FPC GoShimmer Hyperledger Fabric Industry Marketplace Iota Iota1.5 IRI Jaguar Land Rover Linux Foundation Mainnet MAM Mana Nodejs Open Source Permanode Pollen Programming Qubic Research And Development Smart Buildings Smart Cities Smart Contracts Software Development Sybil Attack Tangle Trinity Wallet Workshop

Newsletter

Otrzymuj powiadomienia o nowych postach

Portal IOTA Polska nie jest powiązany z Fundacją IOTA. Może przedstawiać artykuły i opinie nie będące oficjalnym stanowiskiem fundacji.

© 2018 IOTA Polska

No Result
View All Result
  • Home
  • Podstawy
  • Ogłoszenia
  • Badania i Rozwój
  • Ekosystem
  • Artykuły
  • Zakup IOTA
  • Kontakt

© 2018 IOTA Polska