Różne znaczenia decentralizacji

Tysiące godzin badań zostało poświęconych, a biliony dolarów w urządzeniach rozwiązujących hashe wydanych dla tego jednego celu – żeby osiągnąć decentralizację, ochraniać ją i ulepszać. Tymczasem w zaciętej dyskusji pomiędzy zwolennikami konkretnych protokołów bardzo często rzucany jest “ostateczny” argument dyskredytujący przeciwnika – że oto przedstawione propozycje oznaczają “centralizację”.

Niestety jest sporo nieporozumień przy tłumaczeniu znaczenia słowa decentralizacja. Za przykład może służyć poniższy, zupełnie nieprzydatny, a jednocześnie zbyt często używany diagram:


A teraz przyjrzyjmy się dwóm tłumaczeniom z serwisu Quora, które pojawiają się, kiedy zapytamy “jaka jest różnica między systemem rozproszonym a zdecentralizowanym”. Pierwsze jest w zasadzie odbiciem powyższego diagramu, natomiast drugie mówi nam o tym, że “rozproszony system oznacza, że proces transakcji nie jest w całości przeprowadzany w jednym miejscu” podczas gdy “zdecentralizowany system nie pozwala, żeby żaden pojedynczy uczestnik sieci miał całkowitą kontrolę nad przebiegiem transakcji”. Gdy natomiast sprawdzimy odpowiedź na podobne pytanie na Ethereum Stack Exchange, wyjdzie nam w zasadzie podobny diagram jak powyżej, tyle tylko, że słowa distributed (rozproszony) i decentralized (zdecentralizowany) są zamienione miejscami. Wygląda na to, że należy natychmiast wyjaśnić tę sytuację.

Trzy rodzaje decentralizacji

Kiedy ludzie rozmawiają o decentralizacji oprogramowania, właściwie mówią o trzech różnych możliwych osiach centralizacji/decentralizacji. W niektórych wypadkach trudno może być wyobrazić sobie jedną z tych osi bez drugiej, z reguły jednak są one raczej niezależne. Można wymienić trzy następujące osie:

  1. (De)centralizacja architektury – ile fizycznych komputerów składa się na cały system? Ile tych komputerów może w tym samym momencie ulec awarii, nie wpływając na pracę systemu?
  2. (De)centralizacja polityczna – ile osób bądź instytucji kontroluje komputery, z których składa się system?
  3. (De)centralizacja logiczna – Czy interfejs i struktura bazy danych tego systemu wyglądają raczej jak jeden monolityczny obiekt, czy coś w rodzaju bezkształtnego roju? To w gruncie rzeczy sprowadza się do pytania, czy system nadal będzie w stanie funkcjonować jako nie-zależne podmioty, jeśli przetniemy całość na pół (wliczając w to zarówno usługodawców, jak i użytkowników).

Można spróbować zamknąć te trzy wymiary w tabelkę:


Należy zwrócić uwagę, że sporo pól jest czysto umownych i można na ich temat dyskutować. Przeanalizujmy je:

  • Tradycyjne korporacje podlegają centralizacji politycznej (jeden CEO), centralizacji architektury (jedna główna siedziba) i centralizacji logicznej (w gruncie rzeczy nie można ich przeciąć na pół).
  • Prawo cywilne (ang. civil law) opiera się na pojedynczym ciele prawodawczym, natomiast prawo zwyczajowe (ang.common law) opiera się na prawie precedensu, ustanowionego przez wielu pojedynczych sędziów. Prawo cywilne podlega nieco decentralizacji architektury, ponieważ mamy tu wiele dość niezależnych sądów, jednak w prawie zwyczajowym ta decentralizacja jest znacznie bardziej widoczna. Oba zestawy praw podlegają centralizacji logicznej (“prawo jest prawem”).
  • Języki są logicznie zdecentralizowane; angielski, którym Alice porozumiewa się z Bobem, wcale nie musi zgadzać się z angielskim, którym Charlie porozumiewa się z Davidem. Nie ma też żadnej centralnej infrastruktury potrzebnej do tego, żeby język istniał, a reguły gramatyczne języka angielskiego nie są tworzone czy kontrolowane przez jedną osobę (pewnym wyjątkiem może być stworzony przez Ludwika Zamenhofa język esperanto, choć nawet ten twór obecnie jest już językiem żywym, ewoluującym bez żadnej kontroli ze strony pojedynczego podmiotu).
  • BitTorrent jest logicznie zdecentralizowany, podobnie do języka angielskiego. Rozproszone systemy dostarczania treści (ang. content delivery networks) są podobne, jednak kontrolowane przez pojedynczą firmę.
  • Blockchainy [publiczne – przyp. red.] są politycznie zdecentralizowane (nikt ich nie kontroluje) i zbudowane są również w sposób zdecentralizowany (nie mają pojedynczego punktu awarii) ale podlegają centralizacji logicznej (mamy jedną wspólną, ustaloną przez sieć prawdę, a system “zachowuje się” jak pojedynczy komputer).

Ludzie często wymieniają jako zaletę blockchaina posiadanie jednej wspólnej bazy danych, jednej wspólnej prawdy. Ta centralizacja to centralizacja logiczna i jest to taki rodzaj centralizacji, który w wielu wypadkach jest cechą pozytywną (choć Juan Benet z IPFS [InterPlanetary File System – przyp. red.] jest również zwolennikiem decentralizacji logicznej wszędzie, gdzie to tylko możliwe, ponieważ logicznie zdecentralizowane systemy zazwyczaj lepiej znoszą podziały, dobrze funkcjonują w rejonach świata z niską jakością połączeń internetowych, itd. Zainteresowanych odsyłam do artykułu po angielsku na scuttlebot.io o zaletach logicznej decentralizacji pt. “Design Challenge: Avoid Centralization and Singletons”).

Centralizacja architektury danego systemu często prowadzi również do centralizacji politycznej, choć niekoniecznie musi to mieć miejsce. W demokracji politycy spotykają się i przeprowadzają głosowania zazwyczaj w jednej, wybranej sali, ale ludzie odpowiedzialni za utrzymywanie tej sali w czystości wcale nie mają z tego tytułu żadnej znaczącej władzy, która mogłaby mieć odzwierciedlenie w podejmowanych decyzjach. W systemach komputerowych decentralizacja architektury bez decentralizacji politycznej również może się zdarzyć. Przykładem może tu być społeczność internetowa, posiadająca dla wygody centralnie zarządzane forum – ale taka społeczność, która umówi się między sobą na natychmiastową zmianę tego forum na inne, w wypadku niewłaściwych zachowań jego właściciela (taką cechę od początku posiadają społeczności, które zawiązały się w konsekwencji rebelii przeciwko cenzurze na jeszcze innym forum).

Logiczna centralizacja sprawia, że decentralizacja architektury jest trudniejsza, ale nie niemożliwa – wystarczy spojrzeć na działające już przecież zdecentralizowane sieci oparte o konsensus. Utrzymanie takiego systemu jest jednak dużo bardziej skomplikowane niż np. BitTorrenta. Logiczna centralizacja utrudnia też polityczną decentralizację, ponieważ w systemach opartych o logiczną centralizację dużo trudniej rozwiązać spór zwyczajnie odwołując się do zasady “żyj i daj żyć innym”.

Trzy powody decentralizacji

Należy teraz zadać pytanie – dlaczego potrzebna jest nam decentralizacja. Zazwyczaj łączy się to pytanie z kilkoma podobnymi odpowiedziami:

  1. Odporność na awarię (ang. fault tolerance) – zdecentralizowane systemy mają dużo mniejszą podatność na przypadkowe błędy, ponieważ zazwyczaj mogą działać, nawet jeśli część systemu zostanie zniszczona lub uszkodzona.
  2. Odporność na ataki – zniszczenie takich systemów, manipulacja lub ataki są dużo bardziej kosztowne, ponieważ systemy zdecentralizowane nie posiadają pojedynczego punktu awarii.
  3. Odporność na zmowę – Uczestnikom zdecentralizowanych systemów dużo trudniej jest, w wąskiej grupie zainteresowanych, wprowadzać zmiany, które przyniosłyby korzyści im samym, a oznaczałyby poniesienie kosztów dla innych użytkowników sieci. Korporacje i rządy na świecie właściwie nieustannie w wąskich grupach koordynują swoje działania w sposób, który da im przewagę nad mniej skoordynowanymi obywatelami, klientami, pracownikami czy szeroko pojętym społeczeństwem.

Wszystkie trzy powyższe argumenty są ważne, wszystkie trzy prowadzą również do pewnych interesujących, lecz przede wszystkim różnych wniosków w kontekście decyzji dotyczących protokołu, który ma budować zdecentralizowany system. Przyjrzyjmy się każdemu z tych argumentów po kolei.

Odporność na uszkodzenia

Jeśli chodzi o odporność na uszkodzenia, sprawa jest prosta. Czy bardziej prawdopodobne jest, że awarii ulegnie jeden komputer, czy pięć z dziesięciu komputerów w tym samym momencie? Zasada ta nie jest skomplikowana i używa jej się w wielu życiowych sytuacjach – można wymienić chociażby silniki samolotów odrzutowych, systemy awaryjnego zasilania (szczególnie w takich miejscach jak szpitale lub infrastruktura wojskowa), dywersyfikację inwestycyjnego portfolio czy również sieci komputerowe.

Jednak ten rodzaj decentralizacji, oczywiście w wielu wypadkach bardzo ważny i wręcz wymagany, często wcale nie jest rozwiązaniem tak doskonałym, jak wskazywałyby na to modele matematyczne. Wszystko przez zjawisko zwane common mode failure. Oczywiście cztery silniki w jednym samolocie teoretycznie mają dużo mniejszą szansę na awarię niż jeden. Co jednak, jeśli wszystkie cztery wyprodukowane były w tej samej fabryce, a usterka wprowadzona została we wszystkich przez jednego nieuczciwego pracownika?

Czy dzisiejsza generacja blockchainów chroni użytkowników przed common mode failure? Niekoniecznie. Przyjrzyjmy się poniższym scenariuszom:

  • Wszystkie węzły w blockchainie używają tego samego oprogramowania (klienta) i to oprogramowanie zawiera jakiś błąd.
  • Wszystkie węzły w blockchainie używają tego samego oprogramowania (klienta), a zespół deweloperów tego oprogramowania jest niemoralny, ma złe zamiary wobec sieci.
  • Zespół naukowców proponujących zmiany w protokole jest niemoralny, ma złe zamiary wobec sieci.
  • W blockchainie opartym o Proof of Work, 70% górników znajduje się na terenie jednego kraju, a kraj ten decyduje się przejąć wszystkie kopalnie z powodu “bezpieczeństwa narodowego”.
  • Większość sprzętu dla górników jest budowane przez tę samą firmę, a firma ta zostaje przekupiona lub zmuszona do zainstalowania w sprzęcie ukrytej funkcji wyłączania urządzenia na życzenie.
  • W blockchainie opartym o Proof of Stake, 70% całej stawki to wkład jednej giełdy kryptowalutowej.

Holistyczny pogląd na decentralizację skupioną na odporności na uszkodzenia każe przyjrzeć się tym wszystkim zagrożeniom i sprawdzić, w jaki sposób mogą zostać zminimalizowane.

Nasuwa się kilka dość oczywistych wniosków:

  • Posiadanie kilku rywalizujących ze sobą implementacji jest kluczowe.
  • Wiedza i możliwość udzielania się w dyskusjach dotyczących zmian technicznych w aktualizacjach protokołu musi być zdemokratyzowana – tak, żeby jak najwięcej ludzi mogło brać w nich czynny udział i krytykować zmiany protokołu, które są zwyczajnie złe dla systemu.
  • Core deweloperzy i naukowcy zajmujący się protokołem powinni być zatrudniani przez kilka firm i organizacji (lub też alternatywnie wielu z nich powinno być wolontariuszami).
  • Algorytmy górnicze powinny być zaprojektowane w sposób, który minimalizuje ryzyko centralizacji.
  • Wprowadzany jest Proof of Stake, żeby pozbyć się ryzyka centralizacji związanej z produkcją sprzętu górniczego (choć należy oczywiście być mocno ostrożnym w związku z nowymi zagrożeniami, jakie niesie ze sobą także Proof of Stake).

Należy zwrócić uwagę, że omawiana cecha (odporność na awarie) w swojej naiwnej formie skupia się na decentralizacji architektury, jednak kiedy zacznie się rozważać tę właściwość również w kontekście społeczności rządzącej ciągłym rozwojem takiego protokołu, okazuje się, że polityczna decentralizacja jest równie ważna.

Odporność na ataki

Przejdźmy teraz do odporności na ataki. Niektóre czysto ekonomiczne modele sugerują, że decentralizacja tak naprawdę nie ma znaczenia. Jeśli stworzysz protokół, w którym walidatorzy stracą 50 milionów dolarów w wypadku ataku 51% (np. finality reversion), nie ma większego znaczenia, czy walidatorzy kontrolowani są przez jedną firmę, czy przez sto firm – zawsze oznacza to 50 milionów dolarów marginesu bezpieczeństwa ekonomicznego. Właściwie istnieją głębokie przesłanki z obszaru teorii gier, które sugerują, że centralizacja w tym wypadku znacznie zwiększ pojęcie bezpieczeństwa ekonomicznego (model doboru transakcji w obecnych blockchainach zresztą zdaje się to nieco odzwierciedlać, ponieważ włączanie transakcji w bloki to w zasadzie szybko zmieniająca się między zainteresowanymi dyktatura).

Jeśli jednak rozważymy szerszy model ekonomiczny, w szczególności taki, który przyjmuje prawdopodobieństwo wystąpienia przymusu (lub, mniej brutalnie, na przykład wycelowanego w węzły ataku DoS), decentralizacja zaczyna mieć większe znaczenie. Jeśli ktoś zagrozi śmiercią komuś innemu, nagle 50 milionów dolarów przestanie mieć dla tej osoby znaczenie. Jeśli jednak te 50 milionów dolarów podzielone jest na 10 osób, wtedy atakujący musi popełnić ten sam czyn 10 razy i to jednocześnie. Ogólnie rzecz biorąc, nasza nowoczesna rzeczywistość w wielu wypadkach charakteryzuje się asymetrią na rzecz atakujących (w parze atak/obrona). Budynek, którego zbudowanie kosztowało 10 milionów dolarów, może zostać zniszczony kosztem mniejszym niż 100 tysięcy dolarów. Z drugiej jednak strony przy mniejszym budynku stosunek nie jest już taki korzystny dla atakującego – na przykład zniszczenie budynku za milion dolarów może kosztować około 30 tysięcy. Im mniejsza skala, tym ten stosunek jest mniej korzystny dla strony atakującej.

Do czego mogą prowadzić te rozważania?

Po pierwsze, działają mocno na rzecz Proof of Stake jako alternatywy dla Proof of Work, ponieważ sprzęt komputerowy łatwo wykryć, regulować i atakować, natomiast coiny można dużo łatwiej ukryć (Proof of Stake ma też inne właściwości zwiększające odporność na ataki, o których możecie przeczytać w artykule “A Proof of Stake Design Philosophy” na platformie medium.com).

Po drugie, jest to głos popierający duże rozproszenie zespołów deweloperskich, w tym również rozproszenie geograficzne. Po trzecie, daje nam do zrozumienia, że podczas projektowania algorytmu konsensusu musimy brać pod uwagę zarówno model ekonomiczny, jak i model odporności na awarie.

Odporność na zmowę

W końcu możemy przejść do najbardziej zawiłego argumentu z całej trójki – odporności na zmowy. Ciężko w ogóle zdefiniować zmowę; prawdopodobnie jedyny właściwy sposób to napisanie, że zmowa to “koordynacja, która nam się nie podoba lub nie leży w naszym interesie”. Jest wiele takich sytuacji w życiu, w których właściwa koordynacja między wszystkimi uczestnikami byłaby idealna, natomiast jedna podgrupa, która może koordynować swoje działania, kiedy inni nie mogą, to sytuacja mocno niebezpieczna.

Prosty przykład to prawo antymonopolowe, czyli celowe bariery regulacyjne zwiększające trudności działań monopolowych – zyskownych dla niewielu wybranych uczestników rynku, kosztem innych oraz najczęściej również kosztem dobrobytu całego społeczeństwa. Innym przykładem może być wyrok w sprawie zakazu aktywnej koordynacji między kandydatami i tzw. super-PACs w Stanach Zjednoczonych [super PACs to, w dużym skrócie, organizacje bez limitów dotyczących przekazywania funduszy, jednak nie na konkretne kampanie kandydatów i partie, lecz na inne związane z polityką działania – przyp. red.]. Jeszcze innym, choć dużo mniejszym przykładem, może być zasada przyjęta na niektórych turniejach szachowych, uniemożliwiająca dwóm graczom rozgrywanie wielu meczów między sobą w celu podbicia rankingu (lub wyniku punktowego) jednego z nich. Gdzie nie spojrzeć, wszędzie widzimy próby zwalczania niepożądanej koordynacji.

W przypadku protokołów blockchaina, matematyczne i ekonomiczne podwaliny pod bezpieczeństwo konsensusu często opierają się o model nieskoordynowanego wyboru lub założenia, że gra składa się z wielu małych uczestników podejmujących decyzje niezależnie od siebie. Jeśli którykolwiek z uczestników zdobędzie więcej niż 1/3 mining power w systemie działającym na Proof of Work, może liczyć na duże zyski, wykorzystując procedurę tzw. selfish-miningu. Czy jednak możemy stwierdzić, że model nieskoordynowanego wyboru jest realistyczny, kiedy 90% największych górników bitcoina jest na tyle dobrze skoordynowane, żeby pojawić się na tej samej konferencji [odniesienie do konferencji Scaling bitcoin 2015 – przyp. red.]?

Zwolennicy blockchaina mogą również użyć argumentu, że bezpieczniej jest budować na blockchainie, ponieważ tego typu protokół nie może zmieniać swoich zasad, kiedy tylko chce, pod wpływem impulsu. Trudno jednak byłoby wybronić ten argument, gdyby wszyscy deweloperzy projektu pracowali dla jednej firmy lub byli członkami jednej rodziny i zasiadali przy jednym stole. Najważniejsze, żeby te systemy nie posiadały cech monopoli działających w swoim interesie. Można zatem bez problemu przyjąć tezę, że blockchainy będą tym bezpieczniejsze, im bardziej nieskoordynowane.

To jednak powoduje powstanie fundamentalnego paradoksu. Wiele społeczności, w tym społeczność Ethereum, chwalonych jest często za silnego ducha i szybkie koordynowanie działań, na przykład związanych z opracowaniem i aktywowaniem hard forka, żeby naprawić błąd typu denial-of-service w protokole i to w niecałe sześć dni. Jak jednak można zachęcać i ulepszać tego rodzaju dobrą koordynację, jednocześnie chroniąc sieć przed “złą koordynacją”, na przykład górników próbujących oszukać całą resztę, koordynując bez przerwy ataki 51%?

Możemy na to odpowiedzieć na trzy sposoby:

  • Nie trudź się zwalczaniem niechcianej koordynacji; zamiast tego buduj protokoły, które od początku przeciwdziałają takim praktykom.
  • Szukaj złotego środka, czyli koordynacji wystarczającej do zdrowego rozwoju protokołu, jednocześnie niewystarczającej do przeprowadzenia ataku.
  • Postaraj się rozróżnić korzystną koordynację od niekorzystnej koordynacji, ułatwiaj tę pierwszą, utrudniaj tę drugą.

Pierwszy z wymienionych sposobów to w sporej części również filozofia, którą staramy się zrealizować w projekcie protokołu o nazwie Casper. Zastosowany indywidualnie, może być jednak niewystarczający, ponieważ opieranie się jedynie na ekonomii nie rozwiązuje dwóch pozostałych kategorii wątpliwości związanych z decentralizacją.

Drugi ze sposobów trudno jest celowo zaprojektować, szczególnie mając na uwadze horyzont długoterminowy, często jednak rozwiązanie pojawia się niejako przy okazji. Na przykład jako taki szczęśliwy przypadek można uważać fakt, że większość core deweloperów bitcoina mówi po angielsku, natomiast górnicy raczej po chińsku. Tworzy to niejako “dwuizbowy” system zarządzania, co może znacznie utrudniać koordynację i w efekcie zmniejszyć ryzyko wspomnianego wyżej common mode failure, ponieważ chińsko i anglojęzyczne społeczności, ze względu na dystans i problemy z komunikacją, będą dyskutowały o ważnych sprawach raczej w tych dwóch podgrupach językowych – a to być może pozwoli uniknąć popełnienia tego samego błędu przez obie społeczności.

Trzeci wspomniany sposób to właściwie zagadnienie społeczne; rozwiązania zatem mogą być następujące:

  • Interwencje społeczne mające na celu zwiększenie lojalności użytkowników wobec projektu jako całości, zmniejszenie natomiast prawdopodobieństwa wzrostu lojalności jednej grupy tylko wobec siebie.
  • Promowanie komunikacji pomiędzy różnymi “stronami rynku”, żeby żadna z grup (czy to górnicy, deweloperzy czy walidatorzy), nie widziała siebie jako oddzielnej grupy i nie czuła potrzeby skoordynowania działań w celu obrony własnych interesów.
  • Projektowanie protokołu w sposób, który zniechęca walidatorów/górników do zawierania “specjalnych relacji” w małej grupie czy uruchamiania dedykowanych kanałów komunikacji dla “wybranych”.
  • Jasne i przejrzyste normy dotyczące fundamentalnych cech, jakie ma posiadać protokół, oraz informacje o tym, co nie powinno być robione lub może zostać zrobione tylko w ekstremalnych sytuacjach.

Ten trzeci cel decentralizacji, czyli decentralizacja, która ma pozwolić protokołowi na uniknięcie niechcianej koordynacji, jest prawdopodobnie najtrudniejszy do osiągnięcia, a kompromisy w tym obszarze są nie do uniknięcia. Prawdopodobnie najlepszym rozwiązaniem tego problemu jest poleganie w dużej mierze na jedynej prawdziwie zdecentralizowanej grupie: użytkownikach protokołu.

Artykuł, pierwotnie pojawił się tutaj w lutym 2017 roku i został przetłumaczony za zgodą autora.