Najważniejszym elementem każdego DLT jest konsensus wykonywany przez automatyczne działanie zaimplementowanego kodu. Na drodze do osiągnięcia pełnej centralizacji IOTA zastosowała mechanizm osiągania konsensusu, który zdecydowanie wyróżnia ją spośród innych technologii rozproszonego rejestru.

Do niedawna sieć IOTA w wersji Chrysalis była zarządzana przez koordynatora, scentralizowany węzeł pełniący funkcję organu nadzorczego prowadzony przez IOTA Foundation. Koordynator określał, które transakcje i dane są włączane do księgi głównej, tj. listy sald tokenów wszystkich użytkowników.

Podczas gdy IOTA 2.0 jest złożonym protokołem z różnymi modułami, jego podstawowa idea jest w rzeczywistości dość prosta. Dane i transakcje są zawarte w obiektach zwanych wiadomościami. Każda wiadomość musi odnosić się do od dwóch do ośmiu innych wiadomości. W ten sposób zbiór wszystkich wiadomości, zwany Splotem (Tangle), jest stale rosnącym, skierowanym grafem acyklicznym (DAG).

Założenia działania protokołu

Bez koordynatora decydującego o tym, które transakcje należy uwzględnić, autoryzowana wiadomość musi mieć spójną historię bez żadnych konfliktów. Gdy jednak pojawiają się konflikty, Tangle rozwidla się na różne gałęzie. Protokół konsensusu IOTA 2.0 musi dokonać dwóch rzeczy:

• zdecydować, które gałęzie przetrwają;
• zapisać tę decyzję dla nowych węzłów dołączających do sieci później.

Pozwala to protokołowi IOTA na utrzymanie spójnej księgi, w której saldo każdego węzła jest zawsze dostępne. Rozstrzygnięcie takiego konfliktu ilustruje opisany poniżej przykład. Alicja ma 5 MIOTA i najpierw, poprzez transakcję A, wysyła je Bartkowi. Następnie Alicja przypadkowo (lub celowo) wysyła te same 5 MIOTA do Celiny w transakcji B. Powoduje to powstanie dwóch sprzecznych transakcji, A i B, a Tangle rozwidla się na trzy gałęzie: gałąź 1, która zawiera transakcję A do Bartka; gałąź 2, która zawiera transakcję B do Celiny; oraz gałąź 3, która odrzuca obie transakcje do Bartka i Celiny.

Protokół musi wybrać jedno z następujących rozwiązań:

• gałąź 1, w tym transakcja A do Bartka, zostanie odrzucona, dając Celinie 5 MIOTA;
• gałąź 2, w tym transakcja B do Celiny, zostanie odrzucona, dając Bartkowi 5 MIOTA;
• obie gałęzie 1 i 2 zostaną odrzucone wraz z transakcjami do Bartka i Celiny, pozostawiając Alicji jej 5 MIOTA.

Załóżmy, że protokół odrzuca gałąź 1. Wtedy gałęzie 2 i 3 przetrwają, a ostatecznie gałąź 2 zabsorbuje gałąź 3, ponieważ nie jest ona w konflikcie z gałęzią 2. Jednak ze względu na to, że atakujący może zachować dla siebie gałąź 1, protokół musi informować nowe węzły dołączające do sieci, że gałąź 1 jest odrzucana. Atakujący może stworzyć wiele konfliktów o skomplikowanych zależnościach, tworząc rozbudowaną sieć rozgałęzień. Używając „teorii multiwersum” Hansa Mooga (ramka Multiwersum Mooga), starszego naukowca ds. badań w IOTA, moduł zarządzający gałęziami efektywnie śledzi wszystkie gałęzie w Splocie. Bez względu na złożoność gałęzi protokół IOTA zawsze wybiera jedną gałąź, a następnie jeden obowiązujący stan księgi głównej. Aby podjąć te decyzje, protokół IOTA 2.0 działa w cyklu przedstawionym na schemacie powyżej i opisanym w ramce Moduły cyklu akceptacji wiadomości.

Działanie cyklu składa się z kilku etapów. Wiadomości wchodzą do sieci poprzez algorytm kontroli zatorów, który zarządza dostępem. Węzły głosują nad nowymi konfliktami za pomocą protokołu głosowania FPC (ang. Fast Probabilistic Consensus), który określa, które gałęzie powinny zostać odrzucone. Głosowanie FPC jest chronione przed napastnikami przez manę. Po odrzuceniu przez FPC złych gałęzi z poprawnych wybierane są tipy, do których mają się odnosić nowe wiadomości. W miarę jak te poprawne gałęzie zdobywają więcej wiadomości, mówimy, że ich waga zatwierdzenia (ang. Approval Weight, AW) rośnie. Gdy gałąź uzyska wystarczającą wagę zatwierdzenia, transakcje znajdujące się w niej są finalizowane i księgowane w rejestrze, a mana jest aktualizowana, określając kolejnych głosujących FPC.

Konsensus probabilistyczny

Kiedy nowe wiadomości wchodzą do sieci, konflikty uruchamiają protokół głosowania FPC. Jest to protokół głosowania binarnego, w którym każdy węzeł zaczyna z początkową opinią na temat transakcji ustaloną przez FCoB (ramka Konsensus barceloński).

Najpierw węzły decydują, które z konfliktowych transakcji chcą polubić (zaakceptować), bazując na pierwszeństwie przybycia wiadomości. Następnie każdy węzeł głosuje poprzez bezpośrednie zapytanie kilku innych węzłów, które transakcje mu się podobają. Jeśli wystarczająca liczba tych węzłów lubi daną transakcję (gdzie „wystarczająca” jest losowym progiem), węzeł również ją zatwierdzi. Następnie każdy węzeł ponownie pyta kilka innych węzłów o zdanie, powtarzając ten proces kilka razy, aż wszystkie opinie się ustabilizują i każdy węzeł zakończy głosowanie z ostateczną wartością: lubię lub nie lubię. Jednak na wynik
głosowania duży wpływ ma proporcja początkowej opinii.

W przypadku dwóch transakcji, które są ze sobą sprzeczne i są widziane przez większość węzłów w sieci w ciągu pierwszego czasu kwarantanny (K1), najprawdopodobniej obie zostaną odrzucone przez FPC, a tym samym nie zostaną dodane do puli tipów i ostatecznie będą sierotami. Sierotami określa się transakcje, do których nie odwołuje się żadna następna transakcja. Sierota nie jest uważana za potwierdzoną i nie będzie częścią konsensusu. Natomiast wiadomość zatwierdzona przez inną wiadomość jest nazywana rodzicem tej ostatniej. Rodzic może być wybrany jako silny lub słaby. Jeśli przeszły stożek rodzica jest lubiany (ma akceptację innych węzłów), rodzic jest określony jako silny. Jeśli wiadomość jest lubiana, ale jej przeszły stożek jest nielubiany, będzie to rodzic słaby. Mechanizm ten nazywany jest przełącznikiem akceptacji.
Bez wyraźnego zwycięzcy nowe węzły dołączające do sieci lub istniejące węzły, które utrwalają brakujące wiadomości, mogą otrzymać tylko jedną z dwóch transakcji (np. z powodu pośredniego utrwalenia poprzez słabe referencje lub awarię sieci), ustawić początkową opinię jako pozytywną poprzez FCoB i w ten sposób próbować dołączyć swoje nowe wiadomości do strony Splotu, która nie uzyska wystarczającej wagi zatwierdzenia, aby zostać kiedykolwiek potwierdzona.

[...]