Chatka cryptoDZIADKA | Hedera™ Hashgraph cz. II – HASHGRAPH versus BLOCKCHAIN
Najpierw wiadomość z… – no, powiedzmy – ostatniej chwili: 26 lutego 2020, a więc po 5 miesiącach i 9 dniach od swego debiutu na giełdach – HBAR (ℏ), oficjalna moneta platformy Hedera, doczekała się swojej implementacji na portfelach sprzętowych Ledger Nano S i Ledger Nano X. Wcześniej HBAR obsługiwały jedynie portfele mobilne (Hedera Wallet i Hbar Price) oraz ‘przeglądarkowe’ (MyHbarWallet i Composer – rozszerzenie Chrome). 27 lutego – HBAR’a przytulił również Atomic Wallet.
Zacznę cytatem.
Wspomniałem kiedyś mimochodem, że mam wielką słabość do algorytmów typu ‘hashgraph’ albo ‘tangle’. Zdaję sobie sprawę, że pośród czytelników BitHub – wciąż jeszcze przeważają sympatycy BLOCKCHAIN. Dlatego – specjalnie dla nich – wetknę kij w mrowisko i przytoczę te oto słowa Leemona Bairda nt. algorytmu PoW (Proof of Work – Dowód Pracy):
„Najpierw wydam duuużo pieniędzy na wielki superkomputer (platformę wydobywczą), potem zużyję duuużo energii, aby mój superkomputer kopał (czyli rozwiązywał nikomu niepotrzebne problemy matematyczne) – a wszystko to tylko po to, aby sieć działała… W O L N I E J. …To nie brzmi dobrze.”
Czy Baird naigrywa się z PoW? Czy jedynie kopie leżącego…? A może po prostu mówi prawdę – tę którą wszyscy dobrze znamy: KRÓL JEST NAGI!
„PoW jest ekscytujący, bo to on pokazał możliwości DLT. Ale to pierwsza generacja. Musimy ją zostawić i przejść dalej. Z hashgraph – możesz uruchomić pełny węzeł na swoim telefonie.”
Zasadnicze pytanie, na które warto dzisiaj odpowiedzieć brzmi: Czym HASHGRAPH różni się od BLOCKCHAIN?
Blockchain przypomina rosnące, nieustannie przycinane drzewo. Przycinanie to jest konieczne, by zapobiec rozrostowi wymykających się spod kontroli gałęzi bocznych – zgodnie z założeniem, że księga ma się składać z pojedynczego łańcucha bloków. W hashgraph – zamiast przycinać nowo wyrastającą gałąź – wplata się ją z powrotem w korpus księgi.
Podobnie jak w blockchain, w hashgraph każdy użytkownik może w dowolnym momencie utworzyć transakcję, która zostaje umieszczona w kontenerze (bloku danych), po czym rozprzestrzenia się w sieci rozproszonej. Ale:
W blockchain:
Jeśli z dowolnych przyczyn jednocześnie zostaną utworzone dwa bloki, to węzły sieciowe ostatecznie wybiorą jeden z nich i odrzucą ten drugi, aby zapobiec rozwidleniu łańcucha (‘fork’). Odrzucenie to (przycięcie gałęzi) – jest jednakże możliwe wyłącznie wtedy, gdy gałęzie nie rosną zbyt szybko.
Ogrodnik z sekatorem (…Sekatoshi?) ma już zapewne swoje latka, a przecież musi nadążyć! Właśnie dlatego – w trosce o jego zdrowie, samopoczucie i wyniki badań laboratoryjnych – blockchain potrzebuje ‘szprycowania’ PoW lub jakiegoś innego draga, który sztucznie spowolni rzeczywistość. Spowalniacz działa jednak nie tylko na niechciane gałęzie; działa na całą roślinę. W efekcie – zamiast dumnego drzewa – mamy przystrzyżony i naćpany bonsai.
W hashgraph – nie ma ogrodnika!
Każdy kontener transakcji jest włączany do księgi – bez żadnego wybierania, odrzucania, spowalniania i nadążania. Wszystkie gałęzie drzewa są wieczne i rosną szybko, bez strachu przed nożycorękim sadystą – szczęśliwe i splecione w jedną całość. Przez to hashgraph jest nie tylko wydajniejszy, ale – dzięki większej ilości gałęzi – zapewnia silniejsze matematyczne gwarancje, takie jak ‘porozumienie bizantyjskie’ (Byzantine agreement) i ‘uczciwość kolejności transakcji’ (fair transaction order).
Jeden ze sloganów reklamowych głosi, że hashgraph jest ‘forkless’ (BEZROZWIDLENIOWY). Z mojej analizy The Hashgraph Whitepaper wynika jednak, że hashgraph najbardziej przypomina ‘grzybnię’ Eywa planety Pandora (film Avatar) – a więc coś, czego istotą jest bycie jednym wielkim rozwidleniem samego siebie. W tym świetle zwrot ‘forkless’ nabiera nowego znaczenia: rozwidlenie nie rozwidli rozwidlalności (czy jakoś tak…).
Platformy blockchain – nie są ani bizantyjskie (tzn. węzły nigdy nie osiągają pewności, że porozumienie zostało osiągnięte, a jedynie prawdopodobieństwo, które rośnie z czasem), ani uczciwe pod względem kolejności transakcji (górnik ma dowolność w porządkowaniu transakcji w blokach). Brak bizantyjskości blockchain leży też w tym, że nie radzi sobie on automatycznie z ‘partycjami sieci’ – np. jeśli jakaś grupa górników byłaby odizolowana od reszty Internetu – powstałby problem rozwidleń (forks) i konfliktów kolejności transakcji.
Hashgraph – jest nie tylko bizantyjski (pewność osiągnięcia porozumienia) i uczciwy (każda transakcja ma własny znacznik czasowy), ale także wydajny, zgodny z ACID i odporny na ataki DDoS.
Przybliżmy wszystkie te cechy:
WYDAJNOŚĆ / EFEKTYWNOŚĆ
W sensie, w jakim termin ‘wydajność’ używany jest w odniesieniu do blockchain – hashgraph jest wydajny w 100%. Nie marnuje pracy na wydobywanie bloków, które zostaną uznane za przestarzałe i odrzucone – z tego prostego powodu, że hashgraph’owe odpowiedniki bloków transakcji nigdy nie stają się przestarzałe. Jest też wydajny w korzystaniu z przepustowości: pochłania jej bardzo mały okruszek – wyłącznie po to, by ustalić znacznik czasu i uporządkować transakcję w kolejce. Jednocześnie algorytm głosowania hashgraph nie wymaga wysyłania żadnych dodatkowych komunikatów w celu walidacji transakcji – poza komunikatami informującymi o samej transakcji.
BIZANTYJSKOŚĆ
Cechą algorytmu hashgraph jest asynchroniczna tolerancja błędu bizantyjskiego (aBFT – asynchronous Byzantine Fault Tolerance). W tłumaczeniu na język naszych przodków oznacza to, że żaden pojedynczy węzeł, lub niewielka grupa węzłów – nie może uniemożliwić sieci osiągnięcia konsensusu, ani nie może zmienić konsensusu po jego osiągnięciu.
Termin BFT jest tu używany w jego mocnym znaczeniu – czyli zakładamy, że napastnicy ‘zmówili się’ w celu uniemożliwienia konsensusu, a część z nich kontroluje Internet, spowalniając lub zapobiegając dostarczaniu komunikatów. Mimo to – sieć Hedera Hashgraph ostatecznie osiągnie konsensus, a każdy jej węzeł ostatecznie osiągnie punkt, w którym “wie” na pewno, że sieć osiągnęła konsensus.
Tak długo, jak atakujący mają mniej niż ⅓ całkowitego udziału HBAR – nie będą w stanie zatrzymać konsensusu lub choćby ingerować w znaczniki czasowe czy kolejność transakcji.
ZGODNOŚĆ Z ACID
Hashgraph – jako rozproszona baza danych – jest zgodny z tzw. ACID. Jest to anglojęzyczny skrót używany do opisania zestawu własności (atomowość, spójność, izolacja, trwałość) gwarantujących poprawne przetwarzanie transakcji w bazach danych. Po osiągnięciu konsensusu co do kolejności transakcji każdy z węzłów sieci Hedera przekazuje transakcje do własnej (lokalnej) kopii bazy danych – w kolejności zgodnej z konsensusem. Skoro więc każda lokalna baza danych każdego z węzłów posiada wszystkie standardowe własności bazy danych (ACID), oznacza to, że sieć – jako całość – posiada jedną rozproszoną bazę danych o tych samych własnościach.
(W blockchain – nigdy nie następuje moment, w którym wiadomo, że konsensus został osiągnięty, dlatego nie da się o nim powiedzieć, że jest zgodny z ACID).
ODPORNOŚĆ NA ATAK DDoS
Atak DoS (Denial of Service – odmowa wykonania usługi) polega na ‘zalaniu’ węzła komunikatami pozbawionymi znaczenia, uniemożliwiając mu tym samym wykonywanie innych ważnych obowiązków. Atak DDoS (Distributed DoS – rozproszona odmowa usługi) wykorzystuje dodatkowo różne publiczne usługi i publiczne urządzenia, które – nieświadomie – wzmacniają atak DoS, czyniąc go dużo większym zagrożeniem. W sieci rozproszonej ataki DDoS mogą być kierowane na węzły uczestniczące w osiąganiu konsensusu.
Sieć Hedera Hashgraph jest odporna na ataki DDoS – z tego powodu, że żaden pojedynczy węzeł ani niewielka ich grupa – nie posiadają specjalnych uprawnień w zakresie konsensusu. Atak DDoS, owszem, może ‘zalać’ dowolny węzeł lub ich grupę, blokując je na jakiś czas, ale sieć – jako całość – będzie działać normalnie.
UCZCIWOŚĆ / SPRAWIEDLIWOŚĆ
Możemy ją mierzyć w trzech aspektach: I. dostępu, II. znaczników czasowych i III. kolejności transakcji.
1.Sprawiedliwy dostęp
Żaden pojedynczy węzeł nie może zatrzymać czy choćby opóźnić transakcji przed wejściem do systemu. Tego typu próby blokowania transakcji są nieskuteczne ze względu na losowy charakter protokołu plotek hashgraph, za pomocą którego węzły komunikują się ze sobą..
2. Uczciwe znaczniki czasowe
W sieci Hedera – każda transakcja posiada własny ‘konsensusowy’ znacznik czasu (consensus timestamp) obliczony przez automatyczny proces głosowania algorytmu hashgraph: mnogie węzły sieci – kolektywnie i demokratycznie – osiągają konsensus ‘własnymi siłami’. Oznacza to, że nie istnieje żaden lider (węzeł wiodący) ani żaden górnik, który posiadałby uprawnienia do określania czy modyfikowania znaczników czasu transakcji.
To automatyczne, kolektywne i demokratyczne głosowanie, wyłaniające konsensus znacznika czasu – to po prostu obliczenie mediany czasów, w których każdy z węzłów otrzymał daną transakcję po raz pierwszy (za pośrednictwem protokołu plotki). Jeśli więcej niż ⅔ węzłów jest uczciwych i posługuje się wiarygodnymi zegarami – sam znacznik czasu transakcji też będzie uczciwy. Ewentualne działania złośliwe nie mają znaczącego wpływu, są więc pomijalne.
W blockchain (!) każdy blok, owszem, zawiera znacznik czasowy, ale odzwierciedla on tylko jeden zegar – sikor górnika, który wydobył ten blok.
3.Uczciwa kolejność transakcji
Porządek transakcji jest zgodny z ich znacznikami czasu, można więc powiedzieć, że dziedziczy on uczciwość zapewnioną przez głosowanie (obliczanie mediany). Jest to niezwykle ważne. Przykładem niech będzie sytuacja, w której dwóch traderów konkuruje – w tym samym momencie – o zakup ostatniej akcji w danej cenie. W blockchain górnik może umieścić obie transakcje w jednym bloku (mając swobodę w ustalaniu ich kolejności) albo jedną z transakcji przesunąć do bloku kolejnego. W hashgraph – nie ma sposobu, aby pojedynczy węzeł miał wpływ na kolejność konsensusu tych transakcji.
Podsumowując:
Hedera Hashgraph jest platformą, która spełnia wszystkie cztery kryteria bezpieczeństwa na poziomie bankowym (BGS – banking-grade security):
1. Sprawiedliwy dostęp (żadna ze stron nie może zapobiec przepływowi transakcji do księgi)
2. Uczciwe zlecanie transakcji (znaczniki czasu transakcji są określane przez sieć jako całość)
3. Niezmienność historii transakcji (żaden z węzłów w żaden sposób nie może zmienić kolejności transakcji w księdze)
4. Całkowita odporność na ataki DDoS (w przypadku platformy Hedera ataki tego typu są pozbawione sensu, gdyż nawet udany atak DDoS nie może zakłócić przepływu transakcji w całej księdze).
**
Od Redakcji:
Jeżeli zainteresował Was temat Hedera Hashgraph, zachęcamy do lektury pierwszej części:
