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ęść 2

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

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:

  1. 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
  2. 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:

  1. zmienną którą można zweryfikować
  2. zmienną która jest nieprzewidywalna
  3. 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:

  1. public node id (ciąg 32 bajtów)
  2. public salt (ciąg 20 bajtów)
  3. 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.

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

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

Następny Artykuł

IOTA, Dell Technologies oraz Fundacja Linux łączą siły w projekcie Alvarium

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