Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


07.06.2022

Red Hat Enterprise Linux 9

Red Hat zaprezentował system operacyjny Red Hat Enterprise Linux 9 (RHEL 9)...
07.06.2022

Technologiczna piaskownica

Koalicja partnerów KIR, IBM, Chmura Krajowa, PKO Bank Polski, Urząd Komisji Nadzoru...
07.06.2022

Sztuczna inteligencja w...

OVHcloud wprowadziło na rynek AI Notebooks – najnowszy element w ofercie usług...
07.06.2022

Spójna ochrona brzegu sieci

Fortinet zaprezentował FortiOS 7.2 – najnowszą wersję swojego flagowego systemu...
07.06.2022

Zarządzanie transferem

Firma Progress wypuściła nową wersję oprogramowania do zarządzania transferem plików...
07.06.2022

Notebook ekstremalny

Panasonic przedstawił 14-calowy Toughbook 40, notebook do pracy w ekstremalnych...
07.06.2022

Zestaw startowy dla robotyki

Firma AMD przedstawiła najnowszy produkt w portfolio adaptacyjnych modułów SOM...
07.06.2022

Precyzja kadrowania

Najnowsze rozwiązania klasy pro firmy Poly mają sprostać zmieniającym się potrzebom...
07.06.2022

Serwer klasy korporacyjnej

QNAP zaprezentował nowy model serwera NAS, TS-h1886XU-RP R2, który działa na systemie...

Rozwój sieci IOTA Tangle

Data publikacji: 06-05-2022 Autor: Adam Kamiński

Wizja skalowalnego, pozbawionego opłat, zdecentralizowanego protokołu rejestru rozproszonego przedstawiona została w 2015 r. w ramach projektu IOTA. Od tamtej pory jego autorzy wdrożyli ogromną liczbę zmian, aktualizacji, sieci rozwojowych, nowych protokołów czy różnych wersji oprogramowania. Warto je wszystkie usystematyzować.

 

Po ponad 14 latach od pojawienia się pierwszego blockchaina w 2008 r. i innowacji wprowadzanych w technologiach rozproszonego rejestru, sieci te cierpią na ten sam zestaw podstawowych bolączek zaszczepionych razem z architekturą blockchain: nie są prawdziwie zdecentralizowane, nie są wystarczająco skalowalne, mają nieefektywne struktury opłat, zużywają ogromne ilości energii, nie są wystarczająco bezpieczne albo wszystkie te problemy naraz.


Mimo sceptycyzmu większości krytyków DLT i przekonania, że nie da się wprowadzić zupełnie nowej architektury rozproszonego rejestru bez opłat transakcyjnych i dotacji ekonomicznych (w formie inflacji) w celu zachęcenia walidatorów, która mogłaby być uznana za bezpieczną, IOTA udowodniła, że jest to możliwe. Uruchomienie pierwszej sieci głównej IOTA w czerwcu 2016 r. było początkiem zrewolucjonizowania rejestrów rozproszonych. Wprowadzono jedną z pierwszych (nie zapominajmy o Hederze) DLT opartych na skierowanym grafie acyklicznym (DAG) – skalowalnym i lekkim protokole, który miał na celu przezwyciężenie rosnących kosztów i zużycia energii poprzez usunięcie górników i opłat – i nazwana, jak doskonale wiemy, Tangle.


Twórcy IOTA, jako pionierzy w tej dziedzinie, początkowo podejmowali wiele nietrafionych i nieoptymalnych decyzji projektowych. Jednak popełnianym błędom towarzyszyła również nauka, która pozwała je dostrzegać i naprawiać. Potknięcia zauważali także członkowie Fundacji IOTA, zewnętrzni programiści, badacze bezpieczeństwa, przedsiębiorstwa i organizacje, które wspólnie przyczyniają się do ulepszania protokołu IOTA, dlatego też projekt doczekał się tak wielu zmian i aktualizacji prowadzących do jego rozwoju.


W większości DLT bez zezwolenia, motywacje ekonomiczne górników są sprzeczne z motywacjami użytkowników sieci. Lepsza przepustowość i niższe opóźnienia mogą zakłócić rynek opłat, na którym polegają górnicy, a zatem zgoda na modernizację sieci może wpłynąć na ich dochody. Dlatego proces przyjmowania głównych ulepszeń protokołu w IOTA jest stosunkowo wyjątkowy wśród „bezzezwoleniowych” (ang. permissionless) DLT ze względu na brak górników. W IOTA walidatorzy i użytkownicy są jednym i tym samym. Nie ma tu konfliktu interesów, co oznacza znacznie prostszą drogę do ulepszeń sieci.

> Poczwarka


Pierwszą dużą modernizacją do wersji IOTA 1.5 dotykającą wszystkich aspektów protokołu, bibliotek, portfeli i implementacji oprogramowania opracowanych przez Fundację IOTA była seria aktualizacji o zbiorczej nazwie Chrysalis, co po angielsku znaczy „poczwarka”, bo i ta sieć była stadium pośrednim przed jej finalną formą. Plan jej wdrożenia podzielony był na dwie fazy. W sierpniu 2020 r. opublikowany został pierwszy zestaw zmian, które miały na celu popchnięcie IOTA w kierunku gotowości produkcyjnej. Obejmował on wprowadzenie metody „białej flagi” do obliczania sald – było to prostsze, nieuwzględniające konfliktów podejście, które poprawiało szybkość i skuteczność wyboru końcówek, eliminowało niektóre wektory ataków i znacznie zmniejszało potrzebę ponownego dołączania. Pierwsza faza wprowadziła również nowy algorytm wyboru kamieni milowych dla koordynatora, skoncentrowany na umożliwieniu sieci obsługi jak największej liczby CTPS (ang. confirmed transactions per second), przy wyższej wydajności obliczeniowej, a także nowy wybór końcówki URTS w oprogramowaniu węzła – szybszy i wydajniejszy niż poprzednie podejście. Rezultatem pierwszej fazy Chrysalis było: skrócenie czasu potwierdzania transakcji do około 10 sekund; transakcje bardzo rzadko wymagały ponownego dołączenia; znaczny wzrost TPS w sieci głównej; poprawa wydajności i niezawodności węzłów; skrócenie czasu konfiguracji węzłów dzięki automatycznemu zarządzaniu.


Druga faza obejmowała transakcje atomowe; przejście na binarny układ transakcji; wprowadzenie nowego schematu podpisu i wsparcie dla standardowej kryptografii z adresami wielokrotnego użytku (EdDSA) z szybszym, bezpieczniejszym haszowaniem; przejście z modelu równowagi na model oparty na UTXO (ang. unspent transaction output), umożliwiając programowanie i skryptowanie transakcji. Dzięki temu każda moneta na danym adresie stała się jednoznacznie identyfikowalna, a każdy wydający mógł wymieniać dokładnie te monety, które chciał przenieść. Pozwoliło to na szybszą i dokładniejszą obsługę konfliktów oraz poprawiło odporność i bezpieczeństwo protokołu. Dodatkowo dzięki przejściu na UTXO natywne aktywa na IOTA stały się możliwe. W przyszłości w połączeniu z maną (Coordicide) stworzyło to bardzo atrakcyjny model tokenizacji. Rezultatem drugiej fazy Chrysalis było: wsparcie sprzętowe dla wszystkich głównych architektur, dzięki EdDSA; uproszczenie układu i zmniejszenie rozmiaru transakcji z 1,7 kB do mniej niż 100 bajtów, co jeszcze bardziej zwiększyło wydajność; wprowadzenie nowych funkcji, takich jak aktywa natywne (wcześniej znane jako kolorowe monety). Wprowadzenie adresów wielokrotnego użytku było ważną zmianą dla posiadaczy tokenów. Znacznie poprawiło to użyteczność IOTA i usprawniło integrację z nowymi giełdami, portfelami i systemami płatności. Wśród zmian wprowadzonych w Chrysalis również oprogramowanie węzłów IRI, będące podstawą sieci IOTA, zostało zastąpione przez Hornet (napisane w języku Go) a następnie Bee (na bibliotece Rust). W trakcie prac nad Chrysalis rozpoczęto też działania mające w efekcie usunąć koordynatora.


Obecnie IOTA 1.5 Chrysalis to wciąż mainnet dla projektu, która stanowi bezpieczną przystań dla użytkowników, programistów i organizacji, oferując bezprowizyjne transakcje, stabilne środowisko, doskonałą dokumentację i dojrzałe narzędzia oraz wsparcie dla różnych popularnych języków programowania, które zapewniają identyczność funkcji. Pozwala ona na około 1000 bezprowizyjnych transakcji danych i wartościowych transakcji na sekundę (TPS).

> Produkcja miodu


Po zakończeniu prac nad Chrysalis wysiłki inżynierów IOTA Fundation skupiły się na dążeniach do IOTA 2.0. W planie fundacji proces ten podzielony był na trzy fazy, które miały odzwierciedlać znaczące kamienie milowe i wydania sieci testowej prowadzące do Coordicide. Kolejne etapy pracy nad dążące do Coordicide przyjęły nazwy Pollen (Pyłek), Nectar (Nektar) i Honey (Miód).


Pollen była pierwszym oficjalnym testnetem sieci IOTA 2.0. Reprezentowała ona znaczącą zmianę w stosunku do poprzedniego wydania GoShimmer v0.1.3, tworząc podstawy dla pierwszej i funkcjonalnej sieci bez koordynatora. Sieć Pollen stanowiła przede wszystkim poligon badawczy dla fundacji IOTA, społeczności i zewnętrznych badaczy, aby zweryfikować koncepcje zawarte w białych księgach Coordicide i symulować pewne wektory ataków. Podczas tej aktywnej fazy badań, większość specyfikacji Coordicide została w pełni sfinalizowana. Pyłek stanowił znaczną aktualizację w stosunku do poprzedniego wydania Alphanet v0.1.3. – zmiany liczyły w przybliżeniu 60 tys. dodatków i 25 tys. usunięć w bazie kodu. Wdrożone zostały podstawy funkcjonalnej sieci bez koordynatorów.


Główne testy w pracach nad tą siecią skupione były bardziej na ogólnym zachowaniu sieci niż na jej wydajności i wrażeniach użytkowników. Z punktu widzenia implementacji, nowo wprowadzone komponenty dopiero raczkowały (np. biblioteka portfeli, FPC), a kilka komponentów nie zostało jeszcze zoptymalizowanych (np. protokół plotki). Została tu wprowadzona nowa architektura składająca się z trzech oddzielnych warstw: sieciowej, komunikacyjnej i aplikacyjnej. Miała ona zapewnić wsparcie dla przyszłych funkcji, takich jak tokenizacja, skalowalne inteligentne kontrakty, zdecentralizowane aplikacje (dApps) bez opłat i sharding.


W Pollen przebudowie został poddany cały rdzeń sieci. Każda wiadomość (transakcja) zawierała hashe rodziców, informacje o emisji (identyfikator węzła, znacznik czasu, itp.), ładunek, PoW i podpis węzła wydającego. Opracowana również została nowa konfigurowalna biblioteka PoW (Proof of Work), która w kolejnych iteracyjnych wydaniach przekształcała się w ich autorski adaptacyjny mechanizm PoW. Zintegrowane również zostało wsparcie dla tradycyjnej kryptografii klucza publicznego opartej na krzywych eliptycznych (np. Ed25519 i BLS), a także binarnych funkcji skrótu, takich jak SHA-256, SHA-512 i Blake2b. Ta wersja GoShimmer zawierała zupełnie nowy rejestr zbudowany na rozszerzonej wersji UTXO, a stan rejestru oparty na równoległej rzeczywistości w multiwersum Mooga. Oddzielenie konsensusu od śledzenia sald zapewniło duży poziom elastyczności i znacznie zmniejszyło złożoność komunikatów dzięki głosowaniu tylko nad konfliktami.


Dodany również został szybki konsensus probabilistyczny (FPC) – nowy algorytm konsensusu IOTA dla sieci zdecentralizowanej. W tej „waniliowej” (czyli bez niestandardowych modyfikacji lub rozszerzeń) wersji protokołu węzły mogły uruchamiać FPC w przypadku wykrycia konfliktów podczas solidyfikacji. Początkowe opinie są oparte były na czasach nadejścia wiadomości. Jednak nowe węzły wchodzące do sieci nie otrzymywały wiadomości w odpowiedniej kolejności, dlatego mogły wydawać błędne opinie o transakcjach. W kolejnych wydaniach dodano mechanizm synchronizacji, który zapobiegał takim rozbieżnościom. Losowość stosowana przez FPC generowana była lokalnie przez każdy węzeł na podstawie unixowego znacznika czasu. Każdą minutę dzielono na epoki (ang. epochs) po 5 sekund. Jest oczywiste, że sekwencja liczb losowych wygenerowana tą metodą jest przewidywalna, a zatem niezabezpieczona. Jednak jej prostota i niezależność od sieci lub innych komponentów powodowała, że nadawała się do wstępnego sprawdzenia zachowania FPC. W następnej iteracji zastosowany został dRNG oparty na społeczności.

 

[...]

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"