Ostatni miesiąc był bardzo produktywny dla naszego zespołu, bowiem zmierzamy w kierunku pełnej, formalnej specyfikacji IOTA 2.0. Nasz team pracował bardzo ciężko, zarówno przy kończeniu bieżących zadań, jak i przy planowaniu naszych badań po specyfikacji. Poniżej znajdują się aktualizacje z kilku naszych zespołów badawczych. Proszę zauważyć, że planujemy przeorganizować kilka z grup, które zakończyły już prace nad specyfiką działalności, więc w przyszłym miesiącu aktualizacja będzie miała nieco inną formę prezentacji.
Implementacja GoShimmer-a. W tym miesiącu zespół skupił się na stabilizacji i niezawodności sieci testowej „Pollen”, wydając wersje GoShimmer v0.2.2. To wydanie przynosi kilka zmian pod maską. Obejmuje ono przeprojektowaną pulę roboczą i zarządzanie żądaniami wiadomości, lepszy proces konsolidacji oraz nowy plugin Beacon zastępujący poprzedni plugin bootstrap. Zmiany te prowadzą do ogólnej poprawy procesu synchronizacji.
Usprawniliśmy również proces walidacji zarówno wiadomości, jak i transakcji. Dokonuje się to poprzez regulację maksymalnej ilości danych wprowadzanych do transakcji oraz maksymalnej wielkości wiadomości, a także dodanie weryfikacji podpisu przed wydaniem.
Nowe API, umożliwienia użytkownikowi wydawanie transakcji poprzez dostarczenie ich w formacie JSON oraz nowy interfejs końcowy API który ułatwia debugowanie stanu konsolidacji, narzędzie to jest częścią nowych ulepszeń API.
Na koniec skupiliśmy się na aspekcie użyteczności „Pollen”, udostępniając zupełnie nowy portfel GUI, a także wzbogacony lokalny pulpit nawigacyjny Grafana z wykresami. Obejmuje to informacje o komunikatach w bazie danych (skonsolidowane, nie skonsolidowane, całkowite), średni czas konsolidacji i wielkości kolejki wiadomości.
Więcej informacji na temat tej wersji można znaleźć w naszym poście na blogu. Ponieważ nasza społeczność nadal testuje i pomaga nam ulepszać każdą wersję testową Pollen, będziemy stopniowo dodawać nowe funkcje i moduły Coordicide do sieci. Pierwszym kandydatem do tego procesu będzie najprawdopodobniej rozproszony generator liczb losowych (dRNG).
Networking. Ponieważ wersja podstawowa algorytmu kontroli przeciążenia została ukończona, skupiliśmy się na strojeniu parametrów i wymiarowaniu buforów. Dzięki odpowiedniemu ustawieniu progów backoff’u modułu ustawiającego prędkość, można poprawić wydajność (np. poprzez zmniejszenie opóźnienia propagacji komunikatów). Osiągnęliśmy również postęp w zakresie polityki dropingu wiadomości, która ma fundamentalne znaczenie dla zagwarantowania ochrony przed złośliwymi lub autodestrukcyjnymi nodami: kiedy bufor skrzynki nadawczej zostanie zapełniony, nasza propozycja polega na usuwaniu wiadomości z najdłuższej kolejki (pamiętajmy, że mamy jedną kolejkę na nod wydający) oraz na zrzucaniu połączeń z sąsiednimi węzłami spamującymi. W kolejnym kroku sformalizujemy te pomysły i przeprowadzimy odpowiednie symulacje.
Dodatkowo do czasopisma IEEE Transactions on Computers zgłosiliśmy artykuł na temat szybkiego generowania liczb głównych poprzez zastosowanie gładkich liczb całkowitych. Porównujemy również techniki wielu wykładów, aby przyspieszyć czas obliczeń VDF na sprzęcie ogólnego przeznaczenia.
dRNG. Kontynuowaliśmy pracę nad spisaniem naszych ustaleń w formie prac naukowych. Zgłosiliśmy jedno z naszych opracowań dRNG na konferencję „22nd International Conference on Distributed Computing and Networking”, gdzie mamy nadzieję przedstawić nasze wyniki. Drugi referat jest jeszcze w trakcie opracowywania. Mamy nadzieję, że w najbliższych tygodniach będzie on gotowy do publikacji.
Mana i Autopeering. W tym miesiącu zakończyliśmy nasze główne cele: specyfikacje autopeering i mana są już gotowe. Poza napisaniem odpowiedniej specyfikacji dla IOTA 2.0, dodatkowo przedstawiliśmy kilka interesujących pytań dotyczących ekonomiki mana oraz tego, jak wybory użytkownika mogą być kształtowane przez naszą implementację. Dział badawczy przekazał odpowiednie informacje do naszego działu współpracy i rozwoju biznesu w Fundacji IOTA w celu dalszego badania.
Jednym ze wstępnych technicznych rezultatów tych dyskusji jest koncepcja, że przyszłe optymalizacje będą prawdopodobnie obejmowały co najmniej dwie różne rodzaje many, i będą wykorzystywane one do różnych celów (jedną dla „dostępu”, a drugą dla konsensusu). Należy zauważyć, że mana nigdy nie musiała być zdefiniowana w jeden sposób, a różne mana mogą być obliczane na różne sposoby. Takie optymalizacje przyczynią się do zwiększenia solidności protokołu w miarę jego dojrzewania. Proszę również zauważyć, że niniejsza dyskusja odnosi się ściśle do IOTA 2.0 i że sharding radykalnie zmienia wszystkie obecne względy ekonomiczne. Mimo, że dyskusje na temat many będą kontynuowane, oficjalnie „mana i autopeering group” przerwie nasze sesje w ramach planowanej restrukturyzacji grupy, a więc jest to nasza ostatnia aktualizacja.
Protokół. W tym miesiącu skupiliśmy się na przeglądzie Chrysalis RFC, napisaniu Specyfikacji Protokołu i odbyliśmy kilka dyskusji na temat teoretycznych aspektów działania algorytmów doboru końcówek.
Obecnie zespół koncentruje się na ukończeniu specyfikacji i ich weryfikacji w ramach przygotowań do przeglądu podczas kolejnego szczytu naukowego.
Specyfikacje. Po raz pierwszy mieliśmy gotowe wszystkie wersje robocze, więc zebraliśmy wszystkie pliki razem, aby skompilować pierwszą pełną wersję specyfikacji. Chociaż mamy całą teorię i elementy dla każdego modułu, sklejenie elementów w jednym pliku do prezentacji to dużo ciężkiej pracy. Stworzony został plan, jak to zrobić, i ma on cztery główne cele:
- Przygotuj wszystkie pliki w jednym środowisku pracy, które będzie łatwo dostępne i wykonalne dla wszystkich naukowców.
- Standaryzacja wszystkich plików poprzez stworzenie leksykonu, indeksu parametrów i listy funkcji wszystkich pseudo-algorytmów. Upewnij się również, że gramatyka i wielkość liter są zgodne we wszystkich plikach.
- Przejrzyj wszystkie pliki, zwracając uwagę na możliwe błędy lub mylące części.
- Zakończ pracę nad plikiem głównym, układając ewentualne zamówienia, wprowadzenia, teksty, odniesienia i obrazy, które mogą być potrzebne.
W tej chwili jesteśmy między krokiem 2 a 3 i planujemy zakończyć krok 3 podczas trwającego właśnie szczytu badawczego!
Mamy nadzieję, że te aktualizacje okażą się dla Ciebie pomocne. Jeśli masz jakieś pytania lub chciałbyś się tylko przywitać, możesz znaleźć członków naszego zespołu badawczego w kanale #tanglemath na naszym Discord. Zapraszamy również do śledzenia i uczestniczenia w naszych technicznych dyskusjach na naszym publicznym forum: IOTA.cafe.
Powyższy tekst jest tłumaczeniem postu z języka angielskiego który oryginalnie ukazał pod tym adresem.
