Comiesięczna aktualizacja statusu badań IOTA będzie zawierać nowości i aktualizacje dotyczące naszych głównych projektów.
Aktualizacja w tym miesiącu dotyczy naszego głównego projektu – Coordicide (projekt usunięcia koordynatora- decentralizacja sieci).
Nasz zespół został podzielony na kilka podgrup, z których każda koncentruje się na konkretnym obszarze Coordicide. Osoby bezpośrednio odpowiedzialne DRI (Directly Responsible Indywiduals) dla każdej grupy, spotykają się regularnie, aby omawiać postępy i działania wewnątrz grup. Przekonaliśmy się, że ten sposób pracy jest bardzo efektywny.
Naszym głównym celem jest dostarczenie specyfikacji dla oprogramowania noda Bee, które będzie stanowić naszą implementację Coordicide. Oprogramowanie najpierw będzie działać na sieci Testnet, a następnie na sieci głównej Mainnet. Nasz zespół zajmuje się obecnie trzema zadaniami: napisaniem specyfikacji badań, poprawkami w whitepaperze oraz badaniem składników Coordicide.
Specyfikacja badań
Ta specyfikacja jest podobna do whitepapera, ale z wymaganymi szczegółami technicznymi, aby mogła zostać przekształcona w nasz kolejny produkt: specyfikację techniczną. Specyfikacja techniczna zostanie następnie przekazana naszym programistom do napisania kodu, przetestowania i wydania.
Poprawki w whitepaper
Otrzymaliśmy wspaniały odzew od opinii publicznej oraz naszych współpracowników akademickich, w tym członków Rady Badań IOTA. Piszemy teraz ulepszony whitepaper na bazie naszych badań. Ten dokument jest dla nas niezwykle ważny, stanowi on podstawę na bazie której eksperci mogą zweryfikować rdzeń dla naszych rozwiązań.
Badanie składników Coordicide
Coordicide składa się z kilku składników. Podczas gdy aktywnie badamy wiele tematów, w tym poście skupiliśmy się na głównych składnikach Coordicide, niezbędnych do skompletowania specyfikacji badań. Poniżej przedstawiamy aktualizację statusu tych komponentów.
Autopeering
Mamy dwie propozycje dla rozwiązania autopeering: „salt-based” oraz „arrow”. Analizowaliśmy propozycję salt-based zarówno analitycznie, jak i poprzez symulację w GoShimmer. W szczególności badaliśmy czas trwania połączeń pomiędzy nodami, a także siłę testu sprawdzalnej losowości (verifiable randomness). Rozpoczęliśmy również modelowanie fluktuacji liczby połączeń na wykresie nodów. Wkrótce porównamy wyniki symulacji i analizy, i zestawimy je w serii publikacji naukowych. Po zakończeniu, będziemy mogli sfinalizować specyfikację autopeeringu do przekazania jej zespołowi inżynierskiemu.
Fast Probabilistic Consensus (FPC)
Nasze badanie symulacyjne FPC zostało niedawno opublikowane na arXiv. Wraz z wpisami na blogu Simulation study of FPC oraz The FPC symulator, został ukończony pierwszy kamień milowy w zrozumieniu FPC.
Osiągnęliśmy znaczący postęp wykrywaniu Berserka, i wkrótce pojawi się blok post na ten temat. Wpis będzie oparty na wątku IOTA.cafe na ten temat. Omówimy funkcję bezpieczeństwa, która uniemożliwia atak Berserk w FPC. Przez implementację tych funkcji, zmniejszymy skuteczność możliwych ataków, prowadząc do zmniejszenia prawdopodobieństwa porozumienia i zakończenia niepowodzenia. Potwierdzają to zarówno dokumentacja FPC oraz nasze symulacje.
Aktualna implementacja FPC, będzie zależeć od parametrów zdefiniowanych przez system reputacji oraz mana nodów. Biorąc pod uwagę, że dokładny rozkład mana po Coordicide jest zmienny i nieznany, naszym podejściem jest zbadanie wpływu różnych rozkładów mana na wytrzymałość i wydajność FPC. Ta analiza pozwoli nam określić ostateczne parametry FPC, oraz dokończyć specyfikację. Zakończenie tej analizy jest priorytetowym zadaniem grupy FPC.
Cellular Automata
Protokoły sieciowe autopeeringu zostały zaprojektowane tak, aby protokół Cellular Automata mógł osiągnąć szybką i niezawodną zbieżność. Jednak, istniejąca teoria nie obejmuje wszystkich praktycznych sytuacji. Aby zintegrować CA, najpierw ustaliliśmy, czy powiązane testy analityczne zapewniają pożądaną zbieżność. Te wstępne badania potwierdziły to czego oczekiwaliśmy od samego początku – trudno byłoby uzyskać nowe teoretyczne wyniki dla CA.
Następnym logicznym krokiem było przeprowadzenie analizy poprzez symulację. W tym celu, CA został zaimplementowany w GoShimmer: https://github.com/iotaledger/goshimmer/tree/ca. Wykorzystamy tą implementację do uruchomienia testów oraz symulacji. Pozwoli nam to sprawdzić, czy utrzymuje się oczekiwana wytrzymałość.
Jako protokół głosowania, CA wyróżnia się wyjątkowo szybkim uzyskaniem zbieżności, dlatego nadaje się do aplikacji IoT, w których spodziewamy się, że się doskonale sprawdzi. FPC zapewnia bardziej niezawodne uzyskanie zbieżności. Na podstawie symulacji, zdecydujemy, czy uwzględnić CA
w pierwszej wersji Coordicide. Oczekujemy, że oba będą współistnieć w przyszłych optymalizacjach.
Rate Control
Obecnie uzupełniamy nasz poprzedni dokument na temat adaptacyjnego PoW, który przedłożyliśmy na konferencji IEE ICBC jako kontynuacja naszej zeszłorocznej publikacji. Następnie, planujemy zintegrować adaptacyjny Proof of Work z GoShimmer w celu testowania i dostrajania parametrów.
Równolegle badamy wykorzystanie funkcji weryfikowalnego opóźnienia (Verifiable Delay Function VDF) jako mechanizmu antyspamowego. Badania koncentrują się na wygenerowaniu publicznego modułu RSA w sposób rozproszony, który zostanie użyty w Wesolowski-like VDF. W listopadzie, przedłożyliśmy dwa dokumenty w toku na konferencji Stanford Blockchain. Teraz piszemy trzeci, w jaki sposób zintegrować VDF jako mechanizm kontroli oceny w IOTA, planujemy go przedłożyć na ACM MobiHoc.
Dodatkowo, pracujemy nad definicją mechanizmu kontroli przeciążenia dla Tangle. Głównym wyzwaniem jest zagwarantowanie, że nody dzielą tą samą wizję transakcji przychodzących (lub równoważnie zapobiegają podziałom sieci) poprzez efektywne wykorzystanie przepustowości sieci. Naszkicowaliśmy propozycję protokołu zainspirowaną powszechnie stosowanym w Internecie algorytmem Zwiększania Mnożnikowego Zmniejszania Przyrostowego (Additive Increase Multiplicative Decrease), a obecnie budujemy symulator do oceny jego wydajności. Po tej fazie walidacji, następnym zadaniem będzie przedstawienie pełnych specyfikacji dla Coordicide.
GoShimmer
Różne pakiety zostały zintegrowane w repozytorium hive.go. Wspólne pakiety i funkcje między GoShimmer i Hornet są zorganizowane razem w ramach tego pojedynczego repozytorium. Nowy moduł autopeeringu salt-based (autopeering-sim) został zintegrowany z GoShimmer i jest obecnie w fazie testowania/debugowania. Stan Ledger jest bliski ukończenia, obecnie w fazie testowania/debugowania. Warstwa gossip również została zrefaktoryzowana.
Te aktualizacje GoShimmer są niezbędne, ponieważ sprawiają, że ogólna implementacja jest bardziej silna i niezawodna. To z kolei pozwoli nam skupić się na zintegrowaniu warstwy głosowania.
Komponenty Coordicide idą pełną parą! Oczekujcie kolejnych aktualizacji. Jak zwykle zachęcamy do kontaktu na naszych kanałach komunikacyjnych. Możesz być na bieżąco z zespołem badawczym IOTA na kanale #tanglemath na naszym Discordzie. Niedawno uruchomiliśmy także nasze forum publiczne: IOTA.cafe. Zapoznajcie się z tymi zasobami, aby uzyskać więcej szczegółów na temat tego, co zostało powyżej opisane.
Powyższy tekst jest tłumaczeniem postu z języka angielskiego który oryginalnie ukazał pod tym adresem.
