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 więcej teoretycznej strony mana, a także wdrożymy nieco w jej implementację.
Naszym celem nie jest tutaj przedstawienie specyfikacji z technicznego i matematycznego punktu widzenia, ale raczej pomoc użytkownikom IOTA w zrozumieniu tego ważnego komponentu Coordicide na poziomie teoretycznym i praktycznym. Oczywiście wszystkie szczegóły zostaną opublikowane wraz z opublikowaniem pełnych specyfikacji IOTA 2.0.
Ten post obejmuje:
- Podstawowym wymogiem każdego DLT jest, aby mieć zarówno ochronę Sybil, jak i kontrolę przeciążenia. Wyjaśniamy, w jaki sposób mana spełnia te teoretyczne wymagania. Jednym prostym sposobem myślenia o mana jest to, że jest ona używana do ważenia wpływu na różne moduły, w tym głosowanie FPC, dRNG, autopeering i kontrolę przeciążeń
- Prezentacja wysokiego poziomu wdrożenia many w IOTA 2.0
- Komentarze i przemyślenia na temat tego, jak użytkownicy będą „wchodzić w interakcje” z maną w sieci na żywo
- Kilka często zadawanych pytań od społeczności
Czym jest mana?
Każde DLT potrzebuje kilku różnych komponentów, ale w kontekście tej dyskusji skupimy się na wymaganiu dwóch specyficznych funkcji: formie ochrony Sybil i sposobie kontrolowania przeciążenia sieci.
Ochrona Sybil zapobiega uzyskaniu przez atakującego nadmiernego wpływu na sieć poprzez utworzenie wielu tożsamości. Kontrola przeciążeń określa, kto ma możliwość zapisywania do księgi w czasie przeciążenia. Każdy DLT musi zawierać komponenty, które spełniają te podstawowe wymagania.
Mana jest prawdopodobnie najlepiej postrzegana jako narzędzie używane w różnych rolach w sieci. Jest powiązana z tokenem IOTA, ale także pozostaje od niego oddzielona. Kiedy transakcja z wartością jest przetwarzana, ilość zwana maną zostanie „zastawiona” na określonym ID noda. Ta ilość jest powiązana z kwotą IOTA wprowadzoną do transakcji. Mana zastawiona dla każdego ID noda jest przechowywana jako rozszerzenie księgi.
Jedynym sposobem na zdobycie Mana jest przekonanie posiadacza tokenów IOTA, aby ci ją zastawił. W tym sensie mana jest Delegowanym Dowodem Własności Tokena (Delegated Proof of Token Ownership). Dlatego też mana zapewnia odpowiednią ochronę Sybil, ponieważ trudno ją zdobyć w dowolnych ilościach.
Dodatkowo mana działa jako mechanizm kontrolujący Sybil w algorytmie kontroli przeciążenia. Tak więc, chociaż różne czynniki, takie jak użycie sieci, wpływają na limit wiadomości noda, mana posiadana przez noda określa, ile wiadomości może wysłać w stosunku do całkowitej przepustowości sieci.
Proces składania zobowiązań („zastawiania”) jest wykonywany dwukrotnie, raz dla modułów zajmujących się konsensusem i ponownie dla kontroli przeciążeń. Ma to na celu zapewnienie maksymalnej swobody i bezpieczeństwa w sieci.
Ponieważ zachęty do zapewnienia bezpieczeństwa i dostępu mogą być potencjalnie sprzeczne, to oddzielenie gwarantuje, że użytkownicy zawsze będą mogli działać w sposób najlepiej zabezpieczający sieć, zachowując jednocześnie swobodę przydzielania dostępu zgodnie z ich interesami ekonomicznymi. Posiadacz tokena może zatem delegować swój dostęp bez przypisywania delegatowi żadnej dodatkowej „wagi” w procesie konsensusu.
Jak omówimy później, posiadacze tokenów mogą dzierżawić swoją manę dostępu, ale nie ma powodu, aby to robić w przypadku many konsensusu. Konkretnie oznacza to, że przypisujemy dwie oddzielne wartości mana, którą nazywamy maną konsensusu i maną dostępu.
Implementacja mana
W tej sekcji wymieniamy kilka ważnych aspektów implementacji mana. Przedstawimy sposób obliczania many, sposób przypisywania many do ID noda oraz rolę many w każdym z komponentów IOTA 2.0.
Oprócz dwóch zastosowań Mana (ochrona Sybil i kontrola przeciążeń), nasza implementacja IOTA 2.0 wprowadza dwa sposoby obliczania many.
Jednym ze sposobów obliczenia many (powszechnie nazywanej „mana 1”) jest to, że zastawiona mana jest po prostu równa liczbie tokenów przeniesionych w transakcji. Drugi sposób, w jaki można obliczyć manę („mana 2”), to zwiększenie many 1, które obejmuje nie tylko delegowany dowód posiadania, ale także dowód aktywności noda. Mana 2 ma przewidywalną ewolucję w czasie, w tym sensie, że nie mają na nią wpływu dodatkowe transfery tokenów. Ta przewidywalność może być ważna dla użytkowników wchodzących w interakcje na „rynku dostępu do many” (więcej na ten temat poniżej), którzy chcą zapewnić kontrolę nad zakupionym lub dzierżawionym dostępem.
Nasz zespół wciąż bada, który wybór spośród tych dwóch jest lepszy, wdrażając obie opcje w GoShimmer. Obie opcje będą działać, ale ostateczny wybór zostanie dokonany poprzez solidne testy obu rozwiązań jednocześnie w GoShimmer.
Cenimy również informacje zwrotne otrzymane od partnerów i niezależnych badaczy. Nie ma pośpiechu, aby zdecydować się na jedną opcję na tym etapie, bez uprzedniego zobaczenia jej „w akcji”. Postrzegamy ten wybór jako po prostu wybór lepszej z dwóch dobrych opcji. Po obliczeniu many protokół przebiega w następujący sposób.
Waga zarówno many konsensusu, jak i many dostępowej danego noda jest odniesiona do całkowitej „aktywnej many”, czyli many posiadanej przez nody aktywne w sieci. Na przykład, jeśli nod ma 5% całkowitej many dostępu i tylko 50% many dostępu jest aktywne, wtedy nod będzie mógł dodać 10% wszystkich danych dozwolonych przez protokół do Tangle.
Podobnie, siła głosu jest proporcjonalna do many aktywnego konsensusu. Im więcej many konsensusu posiada nod, tym więcej zapytań FPC otrzymuje, czyli tym większą ma siłę głosu. Podobnie w przypadku dRNG, liczby losowe są wydawane przez najbardziej aktywnych posiadaczy mana. Chociaż mana dostępu gwarantuje minimalny dostęp do sieci, całkowita aktywna mana określa faktyczny przyznany dostęp.
Mana jest używana przez każdy moduł protokołu wymagający ochrony Sybil:
- Kontrola przeciążeń: Ilość danych, które można dodać do Tangle, jest proporcjonalna do ich many. Jeśli dane są dodawane do Tangle z maksymalną szybkością 1000 KB/s (uwaga: tutaj używamy tylko okrągłej liczby do celów dyskusji), wtedy nod z 5% many może dodać 50 KB/s danych. W szczególności nod z brakiem many nie może wystawiać żadnych transakcji.
- FPC: Prawdopodobieństwo, że nod zostanie zapytany, jest proporcjonalne do ilości posiadanej przez niego many.
- DRNG: Posiadacze największej ilości many ustawiają DRNG.
- Autopeering: Nody z podobnymi odpowiednikami many, lepiej chronią nody z dużą ilością many przed atakami eclipse.
Interakcje z mana
Teraz, aby połączyć to wszystko razem, dochodzimy do dość ważnego tematu, w jaki sposób użytkownicy IOTA będą „współdziałać” z maną.
Dla większości użytkowników mana będzie bezproblemową częścią korzystania z IOTA. Przygotowując podpisaną transakcję, portfel użytkownika wybiera ID noda, któremu ma zastawić manę. Zwykle portfel wybiera ID noda nadawczego. Wybór ID noda jest rzeczywiście automatyczny w oprogramowaniu portfela stworzonego przez Fundację IOTA. Należy pamiętać, że w niektórych przypadkach mana może być przypisywana do identyfikatorów nodów innych niż nody nadawcze, na przykład podczas przekazywania many dla nowego noda.
Jak wspomniano powyżej, mana jest przypisywana do ID noda. Z technicznego punktu widzenia operatorzy nodów mogą zdobywać manę na trzy sposoby:
- Trzymanie tokenów: operatorzy nodów mogą kupować tokeny i zastawiać swoim własnym nodom manę generowaną przez te tokeny.
- Wypożyczanie many od posiadaczy tokenów. Płatności czynszu mogą być dokonywane IOTĄ lub pieniędzmi.
- Przetwarzanie ruchu związanego z wartością: Nod może przetwarzać płatności na giełdzie w zamian za manę zastawioną w tych płatnościach.
Rola many w module kontroli przeciążenia staje się ważniejsza w czasach przeciążenia sieci. W takich okresach ilość many dostępu wzrośnie, a zatem nody będą potrzebować więcej many dostępu niż w czasach bez przeciążeń, aby zagwarantować określoną przepustowość. Przy wystarczającym zapotrzebowaniu na manę dostępu naturalne jest, że powstanie rynek wynajmu many, na którym posiadacze tokenów mogą potencjalnie skorzystać z leasingu swojej many. Aby proces ten stał się płynną częścią dla użytkownika, można użyć inteligentnych kontraktów. Biorąc pod uwagę stosunkowo wysoką przepustowość sieci IOTA 2.0, nie spodziewamy się występowania przeciążeń sieci niezwiązanych ze spamem – co oznacza, że mamy dużo czasu na wdrożenie naszego rozwiązania shardingu w miarę wzrostu popularności.
Często zadawane pytania
Kiedy mana zostanie wdrożona w Pollen Testnet?
Jest wdrażana w momencie publikacji tego wpisu.
Ile many wystarczy, aby wysłać transakcje?
Odpowiedź na to pytanie zależy w dużej mierze od warunków sieciowych. Ponieważ przepustowość jest skończona, gdy węzły zmagają się ze strumieniem transakcji, musi istnieć mechanizm nadawania priorytetów wiadomościom. Mana wymagana do uzyskania dostępu do Tangle zależy od tego, ile transakcji chcesz wysłać i jak zatłoczona jest sieć.
Jak sharding wpłynie na manę?
Wciąż jesteśmy na wczesnym etapie definiowania sposobu działania naszego rozwiązania shardingu, ale z pewnością będzie ono zawierało manę „shardingu”. Jest na to kilka sposobów. Na przykład, każdy adres będzie należał do fragmentu, a kiedy środki zostaną wydane z tego adresu, zastawiona mana może być również oznaczona tym samym fragmentem.
Czy mana to rodzaj Proof of Stake? Czy jest to rodzaj Delegated Proof of Stake?
Istnieją pewne podobieństwa między maną a Delegated Proof of Stake. Jednak terminy PoS i DPoS oznaczają system, w którym walidatorzy są wybierani do tworzenia bloków, otrzymywania nagród i opłat oraz mogą stracić stawkę, jeśli źle się zachowują. W naszym nowatorskim podejściu opartym na DAG nie mamy bloków, nagród ani opłat, więc porównania między maną a PoS i DPoS są ograniczone.
Czy istnieje rola dla Proof of Work w IOTA 2.0? Czy mana w ogóle wykorzystuje Proof of Work?
Dla wszystkich zamiarów i celów uczciwych użytkowników zasadniczo nie będzie dowodu pracy. Protokół będzie implementował coś, co nazywa się adaptacyjnym dowodem pracy jako zapobieganie spamowi. Uczciwe nody tworzące transakcje będą musiały wykonać bardzo mały dowód pracy (znacznie mniejszy niż obecnie), aby utworzyć wiadomość. Jednak złośliwy node usiłujący spamować sieć zostanie szybko ukarany ogromnymi wymaganiami dotyczącymi PoW, które fizycznie ograniczą jego zdolność do tworzenia wiadomości. Ten mechanizm nie będzie karał uczciwych nodów.
Mana nie użyje żadnego rodzaju Proof of Work.
Czy różnica w postrzeganiu many powoduje problemy? Czy atakujący może wyolbrzymić te różnice?
Jest to bardzo ważne pytanie dotyczące wdrażania many, ale ma bardzo techniczną odpowiedź. Załóżmy, że transakcja przenosząca dużą ilość funduszy usuwa manę z noda A i przekazuje ją do noda B. Podczas gdy transakcja rozprzestrzenia się w sieci, niektóre nody, które jako pierwsze otrzymają transakcję, tymczasowo zobaczą, że node B ma dużo many, a inne zobaczą, że A ma dużo many. Co więcej, atakujący ze znaczną ilością many może wysłać sekwencję transakcji przenoszących dużo many pomiędzy różnymi ID nodów.
Aby złagodzić ten atak, protokół obliczy manę z wykładniczą średnią kroczącą. Oznacza to, że protokół będzie używał dwóch różnych ilości: many podstawowej i many efektywnej. Bazowa mana jest przedłużeniem stanu księgi. Zostanie obliczona bezpośrednio z transakcji dodanych do stanu księgi. Tymczasem efektywna mana to mana używana przez każdy moduł i będzie okresowo aktualizowana za pomocą następującej rekurencyjnej formuły:
New Effective Mana=α(Base Mana) +(1-α)(Old Effective Mana)
gdzie α wynosi od 0 do 1. Przy wykładniczej średniej kroczącej efektywna mana spowalnia efekt zmian w bazowej manie. W związku z tym duże zmiany w podstawowej manie w powyższym ataku będą rejestrowane powoli i dopiero wtedy, gdy transakcje będą miały szansę rozprzestrzenić się w całej sieci. Parametr α kontroluje, jak powolne są te zmiany.
Każdy moduł protokołu może tolerować pewne rozbieżności w postrzeganiu many. W sieci GoShimmer dokładnie zbadamy, jak duże mogą być te rozbieżności, co określi odpowiedni parametr α.
Jako nowy nod, jak mogę uzyskać manę, aby uzyskać dostęp do systemu? Czy muszę to kupić? Jak długo trwa wysyłanie wiadomości?
Jak wspomnieliśmy powyżej, mana będzie bezproblemową częścią doświadczenia użytkownika. Najprostszym sposobem na rozpoczęcie przez operatora noda jest zakup własnych tokenów, utworzenie transakcji, która zastawia te tokeny dla siebie, a następnie znalezienie innego noda, który wyda tę transakcję. IF może również stworzyć „kran many”, do którego użytkownicy mogą przyjść i poprosić o zastaw many dla swojego noda.
Gdy mana zostanie przypisana do ID noda, node musi poczekać kilka minut, aż wykładnicza średnia krocząca zarejestruje zmiany w mana, i nod będzie miał swobodny dostęp do sieci.
Czy istnieją strategie gromadzenia many, której osoba atakująca może użyć do zaatakowania sieci?
Mana jest zawsze związana z identyfikatorem noda (node ID), który jest po prostu kluczem publicznym, a niektóre podpisane wiadomości wyzwalają obliczanie many. W ten sposób pojedynczy fizyczny nod może z łatwością działać przy użyciu tysięcy ID noda. Jednak ani dzielenie, ani łączenie nie są motywowane, ponieważ korzyść z many jest zwykle proporcjonalna do zadeklarowanej kwoty. W szczególności bez many nod nie może uzyskać dostępu do sieci. Mana może zostać przekazana do dowolnego ID noda, nawet ID odpowiadające maszynom offline lub nieistniejącym. Dlatego mówimy, że aktywna mana to mana trzymana przez aktywnego noda.
Atakujący może próbować gromadzić manę do niecnych celów, ale niedobór many powinien to utrudniać. Co więcej, ponieważ żaden rynek na manę konsensusu nie powinien się rozwijać, bizantyjski użytkownik może atakować warstwę konsensusu tylko poprzez kupowanie tokenów i potrzebowałby ich więcej niż uczciwi aktorzy, tacy jak IF.
Czy ten system many jest bezpieczny? Co powstrzymuje atakującego przed zgromadzeniem dużej ilości many zgodnej z konsensusem, sprzedażą wszystkich tokenów, a następnie zaatakowaniem systemu?
Tak, system many jest bezpieczny. Ściśle mówiąc, mana konsensusu może być przydzielana dowolnie. Jednak jest całkiem oczywiste, że dla każdego, kto posiada żetony Iota, po prostu nie ma zachęty do „handlu” maną konsensusu. Tylko atakujący miałby interes w gromadzeniu nadmiernej ilości many konsensusu, dlatego projekt IOTA polegający na oddzieleniu many konsensusu i dostępu jest tak ważny. Pozwala na dostęp do handlu, jednocześnie zapewniając ochronę konsensusu. Niezależnie od braku zachęty do handlu maną konsensusu, atakujący nadal może próbować kupić tokeny w celu gromadzenia many konsensusu, którą można następnie wykorzystać do ataku na sieć. Taki atak byłby jednak zbyt kosztowny, ponieważ zakup powoduje wzrost ceny, a do wykonania ataku wymagana byłaby duża liczba tokenów. Ponadto sprzedaż tokenów przed atakiem bez obniżenia ceny zajęłaby znacznie więcej czasu, niż mana konsensusu zachowałaby swój wpływ na sieć.
Dlaczego IF nie dokonał wyboru między maną 1 a maną 2?
Jesteśmy przekonani, że oba obliczenia many służą zamierzonemu celowi. Nie jest to wybór między dobrem a złem, a raczej między dobrym a lepszym. Chcemy, aby oba zostały zaimplementowane w Pollen, abyśmy mogli podjąć świadomą decyzję, która z nich działa najlepiej, lub czy w rzeczywistości istnieje między nimi jakakolwiek praktyczna różnica.
Czy mana to system reputacji?
Mana może być traktowana jako bardzo podstawowy system reputacji sam w sobie, chociaż wyobrażamy sobie, że będzie to jeden z elementów oceny reputacji. Dobry system reputacji wziąłby pod uwagę zachowanie noda, a reputacja spadłaby do zera, gdyby node źle się zachował. Obecnie finansujemy grant na ten temat.
* * *
Mamy szczerą nadzieję, że ten post był dla Ciebie źródłem wiedzy. Jeśli masz jakieś pytania lub komentarze, możesz znaleźć członków naszego zespołu badawczego na kanale #tanglemath na naszym Discordzie. Zapraszamy również do śledzenia i uczestniczenia w naszych dyskusjach technicznych na naszym publicznym forum: IOTA.cafe.
Powyższy tekst jest tłumaczeniem postu z języka angielskiego który oryginalnie ukazał pod tym adresem.
