Sharding ma być rozwiązaniem problemu skalowalności w nadchodzącej wersji Ethereum 2.0, a także nadzieją poprawy wydajności innych blockchainów. Skalowalność to kluczowy czynnik przekładający się na szybkość działania danego blockchaina. Słowem tym określa się rozwiązania technologiczne mające na celu zwiększenie osiągów sieci blockchain: przetwarzania większej ilości transakcji na sekundę.  Obecnie Bitcoin potrafi przetworzyć około 3-7 transakcji na sekundę, tymczasem Ethereum ok. 7-15. Realizacja shardingu mogłaby ten wynik znacznie poprawić.

Co jest przyczyną problemu wydajności blockchainów?
Jaka jest podstawa działania shardingu, który ma pojawić się w Ethereum 2.0?
Czym jest Blockchain Trillema?

W przystępny sposób wyjaśnię to.

Przyczyny ograniczonej wydajności sieci blockchain

System blockchain to zdecentralizowana baza danych, która działa, przetwarza, zapisuje, komunikuje się w czasie rzeczywistym. Zbudowana jest z węzłów, które można określić jako jednostki (oprogramowanie), które realizują właśnie opisane funkcje. Cechą charakterystyczną blockchaina jest fakt, że w klasycznym modelu wszystkie operacje przetwarzające są wykonywane przez wszystkie węzły w sieci. Komunikacja i dane, przetwarzanie oraz zapisywanie w blockchainie oparte jest o transakcje. Transakcje to niejako cyfrowa koperta krążąca w sieci blockchain zawierająca dane mające zostać przetworzone i zapisane.

Mówiąc o przetwarzaniu i zapisywaniu trochę upraszczam, ale chodzi mi teraz o podkreślnie różnicy między transakcjami w blockchainie Bitcoin i blockchainie Ethereum. Mówimy konkretnie o tych dwóch technologiach, ponieważ Bitcoin zapoczątkował, a Ethereum rozwinęło stopień zaawansowania operacji w blockchainie.

Bitcoin ogranicza się do możliwości przesyłania kryptowaluty – w praktyce polega na to odczycie pewnych danych określających posiadanie określonej ilości kryptowalut (zapisy UTXO, które odkodować można kluczem kryptograficznym użytkownika), oraz bardzo prostą logikę przetworzenia tych zapisów celem przekazania ich dalej (przesyłu Bitcoinów). Ta logika przetworzenia jest na tyle prosta, że można powiedzieć, że Bitcoin tylko zapisuje dane.

W przypadku Ethereum mówimy o znacznie więcej niż prostym zapisie, którego widocznym efektem jest przesłanie kryptowaluty. Ethereum umożliwia przetwarzanie smart contractów, czyli programów komputerowych istniejących w blockchainie. Ethereum więc nie tylko zapisuje, ale i przetwarza. I robi to każdy węzeł sieci.

Każdy węzeł Ethereum przetwarza transakcje, które mają na celu przesłanie Etherów z jednego konta na drugie (jak w Bitcoinie) oraz/lub (to zależy od operacji jakie użytkownicy wykonują) prztwarza transakcje, które mają na celu uruchomienie smart contractu i zapis pewnych danych do blockchaina (zgodnie z logiką smart contractu). Jak więc pewnie możesz sobie wyobrazić – praca obliczeniowa jaką musi wykonać każdy z węzłów, jest spora i w samej teorii jej skalowalność jest ograniczona. W takim modelu po prostu istnieje limit, który określa maksymalną przepustowość działania takiego mechanizmu – czyli ilości transakcji jakie sieć będzie mogła w skończonym czasie przetworzyć. Bardzo trudne jest też wskazanie konkretnej liczby transakcji na sekundę jaką sieć obsługuje – ponieważ ta efektywność zależy od wielu czynników: typu transakcji (czy tylko przesył kryptowaluty, czy wykonanie kontraktu), ilości danych, jakie mają być przetworzone, czasu synchronizacji w sieci itp.

Sposobów na poprawę skalowalności sieci blockchain jest kilka. Każdy ma plusy i minusy. Zwiększanie wielkości bloku (żeby więcej transakcji można było przetworzyć przed zapisem ich do blockchaina) jest jednym ze sposobów – przykład zastosowania to Bitcoin Cash. Tzw. druga warstwa (ang. second layer) polega na odciążeniu głównego blockchaina i realizacji niektórych transakcji poza głównym łańcuchem (Lighting Network w Bitcoin, lub projekt Plasmy w Ethereum).

Sharding to rozwiązanie, które ma się pojawić w Ethereum 2.0 i jemu się przyjrzymy.

Jak działa sharding?

Założenie shardingu w najprostszej formie jest następujące:

Nie przetwarzajmy wszystkich transakcji na każdym z węzłów sieci. Podzielmy sieć tak, aby wydzielone części przetwarzały określoną grupę transakcji – dzięki czemu możliwe jest przetworzenie kilku grup transakcji przez kilka niezależnych grup węzłów w tym samym czasie.

Obrazuje to diagram:

Aktualnie wszystkie węzły sieci przetwarzają te same transakcje i efektywność całej sieci to ok. 5 transakcji na sekundę. Dzieląć sieć na 10 shardów, gdzie każdy z nich będzie przetwarzał niezależnie podobną ilość transakcji do obecnej – uzyskujemy w sumie efektywność całej sieci na poziomie 50 transakcji na sekundę (w przypadku idealnym, nie wliczając potrzebnego czasu na synchronizację między węzłami i wszystkie akcje wymagane do poprawnego działania sieci).

Problemy shardingu i Blockchain Trillema

Realizacja shardingu nie jest prosta. W przypadku klasycznych systemów rozproszonych (popularnie realizowanych w formie mikroserwisów) istnieje prawo zwane z angielskiego CAP theorem. Twierdzenie to definiuje 3 właściwości systemu (informatycznego systemu rozproszonego), dotyczące węzłów, które taki system tworzą: spójność (ang. consistency), dostępność (ang. accessibility,) częściowa tolerancja (ang. partition tolerance – to moje osobiste tłumaczenie na polski i pewnie nie jest najlepsze).

• Spójność – w danym czasie wszystkie węzły systemu posiadają te same, spójne dane.
• Dostępność – system jako kolektywna całość zawsze daje odpowiedź na zapytanie.
• Częściowa tolerancja – system jako kolektywna całość działa poprawnie, nawet jeśli węzły w systemie nie potrafią się skomunikować.

Tak w skrócie. Meriturm tego twierdzenia jest następujące: z tych 3 właściwości niemożliwe jest posiadanie więcej niż 2. Czyli: możesz stworzyć system, który będzie posiadał 2 właściwości, ale nigdy 3. Niemożliwe jest stworzenie systemu idealnego. W praktyce ostatnia właściwość (partition tolerance) jest wybierania prawie zawsze, zostaje więc możliwość wybrania spójności lub dostępności.

Nawiązuję do twierdzenia CAP, ponieważ system blockchain zdaje się charakteryzować podobną właściwością. Blockchain Trillema – niestety nie istnieje w polskim języku odpowiednik słowa trillema. Twierdzenie analogiczne do twierdzenia CAP, stworzone przez Vitalika Buterina, dotyczące systemu blockchain.

Blockchain Trillema

Sieć blockchain może posiadać maksymalnie 2 z 3 właściwości: decentralizacja (ang.decentralization), skalowalność (ang. scalability), bezpieczeństwo (ang. security).

Ultymatywnym celem jest stworzenie sieci blockchain posiadającej wszystkie 3 właściwości. Nad tym pracuje cała społeczność wokół Ethereum z VItalikiem na czele. Nie należy brać tego twierdzenia jako pewnik, na chwilę obecną zaprojektowanie systemu posiadającego wszystkie 3 właściwości wydaje się być bardziej możliwe, niż w przypadku systemów rozproszonych (dla których istnieje twierdzenie CAP).

Niestety na ten moment prawdziwość powyższego twierdzenia w przypadku shardingu może powodować np. zagrożenia bezpieczeństwa. Wyobraźmy sobie blockchain, który działa w architekturze opartej o sharding. Taki system jest zdecentralizowany, poprzez sharding jest także efektywny, skalowalny. Niestety istnieje tutaj bardzo dużo wyzwań dotyczących bezpieczeństwa (trzeciej składowej Blockchain Trillema). Przykładowo realizacja grupowego przetwarzania może doprowadzić do sytuacji, gdzie atakujący sieć w jakiś sposób przejmie wszystkie węzły w danej grupie, mając możliwość dokonania przekłamania na poziomie całej sieci. Taka sytuacja jest niedopuszczalna.

Wyzwania shardingu

W systemach blockchain najważniejszym apsketem prawie zawsze jest bezpieczeństwo. Realizacja shardingu to szereg wyzwań w tym zakresie, jak wspomniałem wyżej. Chcę jednak zwrócić uwagę na wyzwania związane z “użyciem” sieci opartej o sharding.

W Ethereum możliwa jest komunikacja między kontraktami. Smart contract A, może w swojej funkcji definiować wywołanie funkcji ze smart contractu B. W klasycznym modelu, w którym każdy węzeł posiada kopię blockchaina i przetwarza wszystkie transakcje, możliwa jest operacja cofnięcia zmian (ang. revert). Jeśli funkcja ze smart contractu A zakończy się niepowodzeniem z jakiegoś powodu (błędu), a jej wykonanie “zdążyło” wywołać funkcję ze smart contractu B, to ostatecznie zmiany wykonane przez funkcję ze smart contractu B będą cofnięte. Ostatecznie stan blockchaina będzie niezmieniony, ponieważ całościowo wywołanie funkcji ze smart contractu A się nie udało. Realizacja, tego scenariusza w architekturze opartej o sharding będzie na pewno trudniejsza do realizacji. Może okazać się bowiem, że wywołanie smart contractu B będzie polegało na komunikacji między shardami.

Społeczność Ethereum wyraża pewne obawy wobec zmian w modelu programowania smart contractów, jaki istnieje dzisiaj, ale Vitalik zdaje się uspokajać, że ta mechanika nie zmieni się (znacząco?).

Podsumowanie

Ethereum 2.0 zbliża się wielkimi krokami. Jego realizacja ma być długofalowa, w zasadzie kilkuletnia. Obejmować będzie wprowadzenie usprawnień wielu elementów sieci blockchain. Optymalizacja skalowalności blockchaina Ethereum ma w założeniu pojawić się dopiero po zmianie algorytmu konsesusu na Proof-of-Stake. Według planu, pierwszych zmian możemy spodziewać w 2020 roku.

Vitalik Buterin, lider flagowego Ethereum zdaje się rozwiewać wątpliwości i rozwiązywać problemy w kolejnych propozycjach usprawnień blockchaina. To odpowiedzialne zdanie i zdecydowanie pionierski szlak. Pojawia się mnóstwo pomysłów, a globalna burza mózg trwa, aby osiągnąć możliwie najlepszy rezultat.

Co myślisz o shardingu? Uważasz, że to dobry kierunek? Być może są lepsze rozwiązania?
Daj znać w komentarzu – Przemek.