馃嚨馃嚤 Czy blockchain to powolna i kosztowna baza danych? Cardano tworzy histori臋

W krypto-艣wiecie obecne jest wiele mit贸w. Te mity s膮 cz臋sto utrzymywane przy 偶yciu przez ludzi, kt贸rzy czerpi膮 finansowe korzy艣ci poprzez ich wspieranie i propagowanie. Rzu膰my okiem na jeden z takich mit贸w.

Od dawna m贸wi si臋, 偶e blockchain jest powoln膮, kosztown膮 i zasadniczo nieskuteczn膮 baz膮 danych i 偶e nie mo偶na tej technologii u偶ywa膰 do niczego poza kryptowalutami. W tym artykule wyja艣nimy, dlaczego baza danych nie mo偶e by膰 r贸wnowa偶nikiem poj臋cia blockchain, a z kolei blockchain niekoniecznie musi by膰 powolny lub drogi, chyba 偶e takie jest jego za艂o偶enie i przeznaczenie. Konsensus sieci proof of stake, taki jak zastosowany w Cardano, mo偶e by膰 dobrym przyk艂adem dobrego rozwi膮zania.

Baza danych to nie blockchain

Zacznijmy od obalenia jednego mitu. Baza danych nigdy nie b臋dzie blockchainem. Upraszczaj膮c, baza danych to miejsce do przechowywania okre艣lonych rzeczy. Tw贸j pracodawca prawdopodobnie ma baz臋 danych i przechowuje w niej informacje o Tobie. Ka偶dy sklep internetowy ma w艂asn膮 baz臋 danych przechowuj膮c膮 informacje o wszystkich towarach, zam贸wieniach, klientach, rachunkach itp. Blockchain jest rozproszon膮 ksi臋g膮 (st膮d skr贸t DLT 鈥 Distributed Ledger Technology, technologia rozproszonego rejestru). Mo偶esz sobie wyobrazi膰 t膮 ksi臋g臋 czy rejestr jako ksi臋g臋 rachunkow膮 czy rozpisk臋 bilansu finansowego. Jest to zbi贸r danych tego samego rodzaju i zawiera informacje o ich w艂asno艣ci. Cyfrowa ksi臋ga jest w stanie 艣ledzi膰 histori臋 i mo偶na w 艂atwy spos贸b uzyska膰 z niej najnowszy prawid艂owy stan 鈥瀝achunk贸w鈥. Jako u偶ytkownik portfela kryptowalut, ta rozproszona ksi臋ga mo偶e dostarczy膰 informacji o tym, ile monet posiada Ja艣 czy Ma艂gosia :wink:

Baza danych. Nie ma 偶adnego konsensusu w obr臋bie sieci, to administrator ma nad ni膮 ca艂kowit膮 kontrol臋. Dane nie s膮 w艂asno艣ci膮 u偶ytkownika.

Mo偶liwe jest tworzenie, odczyt, aktualizowanie i usuwanie (z angielskiego operacje CRUD) danych z bazy, a wszystkie operacje s膮 szybkie i wysoce skalowalne. Jest to mo偶liwe, poniewa偶 istnieje tylko jeden w臋ze艂 lub serwer z baz膮 danych i nie jest wymagany 偶aden konsensus sieci. Dlatego ka偶da operacja odbywa si臋 natychmiast. Blockchain jest niezmienny, wi臋c mo偶liwe jest tylko dodawanie nowych danych bez mo偶liwo艣ci przepisywania (poprawiania) historii. Dlatego historia jest zawsze w pe艂ni kontrolowalna. Blockchain jest w stanie zachowa膰 wszystkie transakcje. W ten spos贸b mo偶liwe jest przechodzenie przez wszystkie historyczne transakcje przechowywane w pierwszym bloku 艂a艅cucha blokowego a偶 do ko艅ca blockchaina. Po odczytaniu ostatnio dodanego bloku mo偶esz zobaczy膰 aktualny stan ksi臋gi.

Po uzyskaniu uprawnie艅 na zmian臋 warto艣ci w bazie danych i spe艂nieniu okre艣lonych warunk贸w, rekord zostaje natychmiast zmieniony. Zwykle istnieje tylko jedna kopia bazy danych, ale mo偶na regularnie wykonywa膰 jej kopi臋 zapasow膮, aby unikn膮膰 nieoczekiwanej utraty danych. Administrator ma pe艂n膮 kontrol臋 nad baz膮 danych, dzi臋ki czemu dane mog膮 by膰 ka偶dorazowo zmieniane przez wszystkich posiadaj膮cych wymagane uprawnienia. Baz臋 danych, jako pojedynczy punkt awarii, mo偶na oczywi艣cie zhackowa膰, a atakuj膮cy mo偶e swobodnie zmieni膰 dane.

Aby doda膰 nowe dane do 艂a艅cucha blok贸w, zwykle do艂膮czanie nowego bloku wymaga uzyskania rozproszonego konsensusu sieciowego. W臋z艂y sprawdzaj膮 poprawno艣膰 nowo zaproponowanego bloku wraz z transakcjami i, je艣li jest akceptowany, zostanie on trwale dodany do 艂a艅cucha blok贸w tylko za zgod膮 wi臋kszo艣ci w臋z艂贸w. Po uzgodnieniu wszystkie uczciwe w臋z艂y b臋d膮 mia艂y t臋 sam膮 kopi臋 rozproszonej ksi臋gi. Dlatego nie ma centralnego organu maj膮cego prawo do zmiany danych. Istnieje grupa niezale偶nych operator贸w, w艂a艣cicieli waliduj膮cych w臋z艂贸w, kt贸rzy aktywnie uczestnicz膮 w pracach konsensusu, a moc decyzyjna jest rozdzielona mi臋dzy wszystkie strony.


Baza danych kontra blockchain.

G艂贸wne r贸偶nice mi臋dzy baz膮 danych a blockchainem polegaj膮 na tym, 偶e istniej膮 okre艣lone zasady dotycz膮ce sprawdzania poprawno艣ci transakcji i dodawania nowego bloku do 艂a艅cucha blok贸w. Ponadto sprawdzanie poprawno艣ci jest wykonywane na wszystkich pe艂nych w臋z艂ach w sieci rozproszonej. Uczciwe w臋z艂y utrzymuj膮 prawid艂owy stan ksi臋gi. Dane s膮 tylko do艂膮czane, a historia jest niezmienna, tj. nie ma opcji jej edycji.

Same dane, na przyk艂ad informacje o stanie posiadania kryptowaluty ADA, s膮 jakby przypisane do w艂a艣ciciela. Innymi s艂owy, dane s膮 odr臋bn膮 w艂asno艣ci膮 i tylko w艂a艣ciciel klucza prywatnego mo偶e zmieni膰 t膮 w艂asno艣膰. Aby wydawa膰 monety ADA ze swojego adresu, tylko w艂a艣ciciel odpowiedniego klucza prywatnego jest w stanie podpisa膰 transakcj臋. Transakcja jest zatwierdzana przez wszystkie sprawdzaj膮ce w臋z艂y, a je艣li jest poprawna (a tak偶e ca艂y blok jest poprawny), w贸wczas zmienia si臋 w艂asno艣膰 monet 鈥 czyli dokonywany jest transfer.

Blockchain jest niezast膮piony, gdy wymagane jest niemo偶liwe do zmiany przechowywanie informacji, to znaczy, 偶e np. dla u偶ytkownika X stan Y jest aktualny w czasie Z. Jest on bardzo odpowiedni do przechowywania informacji o w艂asno艣ci cennych aktyw贸w. Na przyk艂ad monet ADA, jak pokazano powy偶ej. Pi臋kno blockchaina polega na tym, 偶e to sam w艂a艣ciciel naprawd臋 posiada okre艣lone zasoby, a nawet sie膰 w jakikolwiek spos贸b nie mo偶e tego zmieni膰, bez dost臋pu do klucza prywatnego. Tylko w艂a艣ciciel mo偶e zainicjowa膰 zmian臋 w艂asno艣ci za pomoc膮 transakcji, a sie膰 tylko zatwierdza 偶膮danie i mo偶e je zaakceptowa膰, dodaj膮c transakcj臋 do nowego bloku do艂膮czonego do 艂a艅cucha blok贸w. Zmiana w艂asno艣ci nast臋puje w pe艂ni w spos贸b zdecentralizowany. Jest to co艣, czego nie osi膮ga baza danych. W bazie danych zawsze istnieje centralny organ, kt贸remu trzeba zaufa膰.


U偶ytkownik X podpisa艂 transakcj臋, aby zmieni膰 stan Y w czasie Z. Blockchain zatwierdza transakcj臋 i musi doj艣膰 do konsensusu sieci, aby zaakceptowa膰 proponowan膮 zmian臋. U偶ytkownik X jest jedynym prawowitym w艂a艣cicielem zasobu i mo偶e zmieni膰 stan Y. Nikt inny nie mo偶e tego zrobi膰.

Blockchain po prostu niezmiennie przechowuje informacje o danych, kt贸re mog膮 by膰 publicznie dost臋pne i dzi臋ki temu podlega膰 niezale偶nej kontroli. Sie膰 mo偶e z 艂atwo艣ci膮 chroni膰 i okre艣li膰 maksymaln膮 liczb臋 dost臋pnych monet lub token贸w, poniewa偶 wszystkie dane s膮 przechowywane w ksi臋dze. Ka偶dy pe艂ny w臋ze艂 jest 鈥炁泈iadomy鈥 bie偶膮cego stanu i mo偶e 艂atwo zweryfikowa膰 poprawno艣膰 proponowanych zmian. Jak powiedzieli艣my, nikt nie jest w stanie zmieni膰 danych w ksi臋dze, na przyk艂ad w艂asno艣ci monet ADA, z wyj膮tkiem w艂a艣ciciela. Sie膰 rozproszona jest wi臋c stron膮 nie wymagaj膮c膮 zaufania (a wi臋c zastosowanie ma tu modne w 艣wiecie krypto s艂owo 鈥瀟rustless鈥) mi臋dzy Jasiem i Ma艂gosi膮, gdy chc膮 ze sob膮 prowadzi膰 interesy. Sie膰 rozproszona jest zasadniczo niezale偶na od zaufania z dw贸ch powod贸w: sama sie膰 nie mo偶e zmienia膰 偶adnych danych, poniewa偶 zawsze wymagany jest udzia艂 rozproszonego konsensusu i podpis w艂a艣ciciela. Innymi s艂owy, je艣li posiadasz monety ADA, tylko Ty jeste艣 odpowiedzialny za przechowywanie prywatnych kluczy, kt贸re pozwalaj膮 Ci wydawa膰 艣rodki, a nikt inny nie jest w stanie tego zrobi膰. Sie膰 tylko potwierdza Twoje 偶yczenia i dzia艂a.

Stan Y, kt贸ry u偶ytkownik X mo偶e zmieni膰, mo偶e by膰 czym艣 wi臋cej ni偶 tylko stanem posiadania monet ADA. Mo偶e to by膰 dowolny inny wydany token r贸偶nego rodzaju. Dzi臋ki temu blockchain jest w stanie przechowywa膰 informacje o akcjach, obligacjach, w艂asno艣ci nieruchomo艣ci, przedmiotach do gier online itp. Stan Y mo偶e nawet by膰 warunkiem zdefiniowanym w inteligentnej umowie (smart kontrakcie), m贸wi膮cym, 偶e je艣li Ma艂gosia wy艣le 鈥嬧媡oken Q do Jasia, w贸wczas Ma艂gosia stanie si臋 w艂a艣cicielem tokena R.

Blockchain jest bardzo przydatny do przechowywania prawie ka偶dego rodzaju informacji o w艂asno艣ci, je艣li mo偶na je zdigitalizowa膰 czy stokenizowa膰. Jednak sama ta funkcja nie wystarczy do popularyzacji i musimy pracowa膰 nad innymi przydatnymi zastosowaniami, poniewa偶 tylko po艂膮czenie wielu funkcji sprawi, 偶e nowoczesne sieci rozproszone, takie jak Cardano, b臋d膮 jeszcze bardziej wydajne i ch臋tnie wykorzystywane. Aby jeszcze lepiej wykorzysta膰 sieci rozproszone, potrzebujemy ich odpowiedniego skalowania. Oznacza to, 偶e wielu u偶ytkownik贸w mo偶e z nich korzysta膰 jednocze艣nie. Do tej pory by艂 to problem, st膮d pojawi艂a si臋 ta narracja m贸wi膮ca, 偶e 鈥嬧媌lockchain jest powoln膮 i kosztown膮 baz膮 danych. Je艣li mamy m贸wi膰 o kryptowalutach, kt贸rych ludzie chc膮 u偶ywa膰 na co dzie艅, sieci musz膮 koniecznie skalowa膰 si臋. Je艣li transakcje maj膮 by膰 powolne i kosztowne, nie mo偶emy nawet m贸wi膰 o globalnie u偶ytecznych kryptowalutach. Skalowalno艣膰, ale tak偶e programowalno艣膰 pieni臋dzy i token贸w, 艣ci艣lejsze powi膮zania ze 艣wiatem fizycznym i praca z cyfrow膮 to偶samo艣ci膮 otworz膮 tej technologii drzwi, o kt贸rych dzi艣 nawet nie 艣nimy.

Sp贸jrzmy na powody, dla kt贸rych m贸wi si臋, 偶e blockchain jest powolny i drogi.

Dlaczego blockchain wydaje si臋 by膰 powolny i drogi

Pow贸d, dla kt贸rego blockchain wydaje si臋 by膰 powolny, jest bardzo prosty. Konsensus sieci rozproszonej zawsze b臋dzie wymaga艂 wi臋cej czasu na wykonanie swojej pracy, ni偶 bazy danych. Baza danych szybko sprawdza poprawno艣膰 偶膮dania i wprowadza wymagane zmiany od razu. Skalowalno艣膰 nie stanowi problemu. Sie膰 rozproszona potrzebuje wi臋cej czasu, poniewa偶 w臋ze艂 zwykle 艂膮czy kilka transakcji w celu utworzenia nowego bloku. Blok jest nast臋pnie sprawdzany przez inne w臋z艂y. Ka偶dy konsensus dzia艂a troch臋 inaczej. Niekt贸re mog膮 zale偶e膰 od intensywnej komunikacji wewn臋trznej, inne mog膮 przyznawa膰 uprawnienia do tworzenia blok贸w konkretnemu w臋z艂owi, a nast臋pnie sprawdza膰, czy wszystko jest w porz膮dku.

Proof of Work (PoW, ang. dow贸d pracy) w przypadku Bitcoina to pierwszy udany konsensus sieci stosowany w 艣wiecie kryptowalut z czasem tworzenia bloku ustawionym na oko艂o 10 minut. PoW jest bardzo prosty. Wszystkie w臋z艂y zainteresowane otrzymaniem nagrody za wygenerowanie bloku pr贸buj膮 wygra膰 w okre艣lonym konkursie. Wszystkie w臋z艂y pr贸buj膮 rozwi膮za膰 trudne zadanie matematyczne, kt贸re powinno zaj膮膰 oko艂o 10 minut. Zadanie jest bardzo wymagaj膮ce pod wzgl臋dem mocy obliczeniowej i trudno jest przewidzie膰, czy zajmie ono dok艂adnie 2, 10, czy 60 minut. Tylko jeden w臋ze艂 wygra konkurencj臋. Po rozwi膮zaniu zadania przez w臋ze艂 po prostu przekazuje dalej (propaguje) blok do innych w臋z艂贸w w celu sprawdzenia jego poprawno艣ci. Cz臋艣ci膮 procesu sprawdzania poprawno艣ci bloku jest tak偶e weryfikacja czy zadanie zosta艂o faktycznie rozwi膮zane, aby blok m贸g艂 zosta膰 do艂膮czony do 艂a艅cucha blok贸w.

Proof of work jest r贸wnie偶 bardzo drogi i zasadniczo nieskuteczny. Moc obliczeniowa potrzebna do rozwi膮zania zadania wymaga du偶ej ilo艣ci energii elektrycznej. Aby zachowa膰 dobr膮 uczciwo艣膰 konkurencyjn膮 konsensusu proof of work, blok musi mie膰 ograniczony rozmiar, a do ograniczonego rozmiaru mo偶na wstawi膰 tylko ograniczon膮 liczb臋 transakcji. Generuje to okre艣lone konsekwencje.

Je艣li we藕miemy pod uwag臋, 偶e typowa transakcja mo偶e mie膰 oko艂o 250 bajt贸w, w贸wczas blok o pojemno艣ci 1 megabajta mo偶e pomie艣ci膰 4000 transakcji. 4000 transakcji na 10 minut daje nam 6,7 transakcji na sekund臋. Konsensus proof of work Bitcoina jest obecnie w stanie przetwarza膰 nie wi臋cej ni偶 10 transakcji na sekund臋 (TPS), a przyczyn膮 jest g艂贸wnie d艂ugi czas generowania bloku (czas potrzebny do jego stworzenia).


Blockchain. Do zmiany danych wymagany jest konsensus sieciowy. Nie ma centralnego organu zarz膮dzaj膮cego.

Proof of work pierwotnie pe艂ni艂 funkcj臋 ochrony antyspamowej lub DoS, kt贸ra zosta艂a wprowadzona w 1993 roku. Osoba korzystaj膮ca z us艂ugi musia艂a zapewni膰 PoW, wykona膰 kawa艂ek trudnej i kosztownej pracy przed skorzystaniem z us艂ugi. Dlatego osoba atakuj膮ca nie mog艂a spamowa膰 sieci, poniewa偶 generowanie wi臋kszej ilo艣ci wiadomo艣ci wymaga艂oby du偶ej ilo艣ci pracy (mocy obliczeniowej), wi臋c by艂oby to drogie. Proof of Work nie zosta艂 wymy艣lony jako konsensus sieciowy. U偶ywa艂 go Satoshi Nakamoto, poniewa偶 w tamtym czasie trudno by艂o wypracowa膰 inny wiarygodny rozproszony konsensus odpowiedni dla globalnej sieci. PoW jest powolny, nieskuteczny i drogi. Opr贸cz wszystkich wymienionych wad trzeba jednak przyzna膰, 偶e dzia艂a i jest bardzo bezpieczny. Proof of work jest prosty i solidny, a stworzenie i propagacja fa艂szywego bloku w sieci jest bardzo kosztowna. Potencjalny atakuj膮cy w sieci PoW musia艂by mie膰 bardzo wysok膮 moc haszuj膮c膮 (obliczeniow膮), aby przeprowadzi膰 skuteczny atak. Bezpiecze艅stwo jest uwa偶ane za najwi臋ksz膮 zalet臋 algorytmu konsensusu proof of work. Jednak PoW jest zwykle w du偶ej mierze scentralizowany.

Mo偶emy rozwa偶y膰 2 sposoby zwi臋kszenia przepustowo艣ci sieci, co oznacza przetwarzanie wi臋kszej liczby transakcji na sekund臋 (TPS 鈥 transactions per second). Mo偶emy zwi臋kszy膰 rozmiar bloku, aby m贸c wstawi膰 do niego wi臋cej transakcji lub skr贸ci膰 czas bloku, aby cz臋艣ciej tworzy膰 bloki. Op贸藕nienie sieci sprawia, 偶e 鈥嬧媧wi臋kszenie bloku jest prawie niemo偶liwe. Gdyby blok by艂 zbyt du偶y, w贸wczas propagacja na wszystkie kontynenty zaj臋艂aby du偶o czasu. Zobacz poni偶ej czas potrzebny na dostarczenie bloku o wielko艣ci 2 MB z Londynu do innych cz臋艣ci 艣wiata za po艣rednictwem protoko艂u TCP / IP:

  • Pary偶 鈥 0.1s
  • Wschodnie wybrze偶e Stan贸w Zjednoczonych 鈥 1.1s
  • Zachodnie wybrze偶e Stan贸w Zjednoczonych 鈥 2.5s
  • Brazylia 鈥 3.0s
  • Korea 鈥 3.4s
  • Australia 鈥 5.3s

Zwi臋kszenie rozmiaru bloku przez jaki艣 czas nie b臋dzie realn膮 alternatyw膮, ale w przysz艂o艣ci prawdopodobnie b臋dzie mo偶liwe jego zwi臋kszenie, wraz ze zwi臋kszeniem przepustowo艣ci sieci i rozwojem infrastruktury. Musimy wi臋c aktualnie d膮偶y膰 do skr贸cenia czasu bloku. Jest to jednak mo偶liwe tylko wtedy, gdy wykorzystamy inny konsensus sieci, ale jednocze艣nie nie zagrozimy bezpiecze艅stwu i decentralizacji.

Proof of stake (PoS) mo偶e by膰 szybkim i tanim konsensusem

Oczekuje si臋, 偶e protok贸艂 konsensusu PoS Cardano Ouroboros b臋dzie w stanie przetworzy膰 200鈥250 transakcji na sekund臋. Innymi parametrami konsensusu mo偶e by膰 czas bloku oko艂o 20 sekund, ponad 50% delegowanych (stakowanych) monet wymaganych do przeprowadzenia ataku 51% i oko艂o 1000 pul stakingowych (stake pools) w sieci.

Cardano Ouroboros PoS zasadniczo podniesie jako艣膰 decentralizacji w sieciach publicznych. Obecna sytuacja nie jest zbyt dobra, je艣li we藕miemy pod uwag臋, 偶e w sieci Bitcoin jest tylko ok. 10 znacz膮cych pul. Inne du偶e projekty wykorzystuj膮 konsensus DPoS, kt贸ry ma sta艂膮 liczb臋 podmiot贸w z prawem do utworzenia bloku. Na przyk艂ad EOS ma 21 takich podmiot贸w, a Tron niewiele wi臋cej. Ethereum 1.0 u偶ywa konsensusu proof of work i pod wzgl臋dem liczby du偶ych graczy jest bardzo podobny do Bitcoina. Ethereum 2.0 przeprowadzi migracj臋 do algorytmu PoS, aby osi膮gn膮膰 lepsz膮 decentralizacj臋 i skalowalno艣膰. Ale kiedy to nast膮pi, na razie nie wiadomo.

Jako艣膰 decentralizacji jest najwa偶niejsz膮 cech膮 sieci rozproszonych. Czasami s艂yszymy, 偶e nie chodzi o jako艣膰 decentralizacji, ale o bezpiecze艅stwo. Mamy dzisiaj dobrze zabezpieczon膮 i scentralizowan膮 sie膰. Prawda jest taka, 偶e 鈥嬧媝otrzebujemy zar贸wno decentralizacji, jak i bezpiecze艅stwa. Jedno bez drugiego nie mo偶e dobrze dzia艂a膰 na d艂u偶sz膮 met臋. Je艣li jednak musieliby艣my wybra膰 jedn膮 funkcj臋, w naszym mniemaniu musia艂aby to by膰 decentralizacja. Cardano wytycza wysok膮 poprzeczk臋 dla wysokiej jako艣ci decentralizacji. Nadszed艂 czas, aby udowodni膰 jako艣膰 bezpiecze艅stwa w rzeczywisto艣ci. Zesp贸艂 IOHK od dawna bada艂 algorytm proof of work i z t膮 wiedz膮 opracowywa艂 spos贸b zapewnienia r贸wnie bezpiecznego systemu PoS. Zosta艂o to osi膮gni臋te dzi臋ki d艂ugim i szczeg贸艂owym badaniom naukowym, jak to w zwyczaju Cardano. Teraz trzeba to zaprezentowa膰 ca艂emu 艣wiatu, wraz z nadej艣ciem kolejnej ery Shelley.

Przetwarzanie 250 transakcji na sekund臋 wci膮偶 oczywi艣cie nie jest wystarczaj膮ce, aby protok贸艂 maj膮cy globalne ambicje m贸g艂 zosta膰 wykorzystany do p艂atno艣ci, czy nawet do wielu innych rzeczy. Cardano ma jednak asa w r臋kawie i jest to sharding (ang. fragmentowanie). Sharding jest sposobem na r贸wnoleg艂e przetwarzanie transakcji w wielu sieciach, przy czym nadal utrzymywany jest jeden sp贸jny stan.

Sharding opiera si臋 na za艂o偶eniu, 偶e wszystkie w臋z艂y w sieci niekoniecznie musz膮 sprawdza膰 poprawno艣膰 wszystkich transakcji. W臋z艂y mo偶na podzieli膰 na wiele podsieci, jednostek lub fragment贸w (鈥瀞hard贸w鈥). Ka偶da podjednostka nast臋pnie zweryfikuje tylko cz臋艣膰 wszystkich transakcji. Je艣li sie膰 mia艂aby 1000 w臋z艂贸w aktywnie uczestnicz膮cych w konsensusie sieci i zostan膮 one podzielone na 10 shard贸w, sie膰 mo偶e zweryfikowa膰 oko艂o 10 razy wi臋cej transakcji. Prawdopodobnie mo偶liwe jest r贸wnie偶 zwi臋kszenie liczby w臋z艂贸w w ramach shard贸w. Dzi臋ki shardingowi mo偶emy pomno偶y膰 TPS jednego blockchaina kilkadziesi膮t, mo偶e setki razy. Mo偶liwe jest uzyskanie niezb臋dnych dziesi膮tek tysi臋cy transakcji na sekund臋. Na przyk艂ad, je艣li Cardano mia艂oby 10 shard贸w, przepustowo艣膰 wynosi艂aby 2 500 TPS.


Sharding: 4 fragmenty, jeden stan

Utrzymanie sp贸jno艣ci i jednolito艣ci sieci we wszystkich fragmentach wymaga synchronizacji mi臋dzy shardami, a op贸藕nienie sieci jest nadal du偶ym problemem. Osi膮gni臋cie r贸wnoleg艂o艣ci w rozproszonym 艣rodowisku sieciowym jest jednym z najwi臋kszych wyzwa艅 dla zespo艂u IOHK.

Dzi臋ki shardingowi sie膰 mo偶na zdecentralizowa膰, zabezpieczy膰 i skalowa膰 w ramach tzw. rozwi膮zania pierwszej warstwy. Jest to bardzo wa偶ne z punktu widzenia do艣wiadczenia u偶ytkownika i og贸lnej niezawodno艣ci. Jest to jednak rozwi膮zanie, kt贸re ewentualnie zostanie wprowadzone w dalekiej przysz艂o艣ci. Charles Hoskinson, CEO IOHK, powiedzia艂 w jednym ze swoich AMA (spotka艅 online ze spo艂eczno艣ci膮), 偶e zesp贸艂 ma na ten temat wiedz臋 i jest w stanie wprowadzi膰 sharding na poziomie blockchaina. Jednak og艂oszone przez zesp贸艂 rozwi膮zanie drugiej warstwy - Hydra, b臋dzie wystarczaj膮ce najpewniej przez najbli偶sze 5鈥10 lat.

Rzu膰my jeszcze okiem na inne alternatywy, jak mo偶na osi膮gn膮膰 wy偶sz膮 skalowalno艣膰.

Architektura warstwowa

Zasadniczo ka偶dy projekt ma dwie podstawowe opcje poprawy obecnego najbardziej pal膮cego problemu blockchaina, czyli skalowalno艣ci. Zesp贸艂 mo偶e ulepszy膰 konsensus sieciowy w ramach rozwi膮za艅 pierwszej warstwy lub u偶y膰 innej warstwy o r贸偶nych w艂a艣ciwo艣ciach. Przyk艂adem pierwszej opcji jest praca nad proof of stake i dzielenie w臋z艂贸w sieci na fragmenty (sharding). Przyk艂adem rozwi膮za艅 drugiej warstwy jest Bitcoin i jego Lightning Network (LN). Takie podej艣cie nazywa si臋 architektur膮 warstwow膮.

Bitcoin, jako przedstawiciel blockchain贸w pierwszej generacji, wybra艂 drug膮 opcj臋. Monety s膮 przekazywane z pierwszej warstwy do drugiej, gdzie mo偶na zastosowa膰 b艂yskawiczne i tanie transakcje o znacznie wi臋kszej przepustowo艣ci sieci. Lightning Network to zupe艂nie inna, oddzielna sie膰 z w艂asnymi w臋z艂ami, adresami, portfelami itp. Przenoszenie monet z i do drugiej warstwy wymaga transakcji on-chain (na blockchainie, online) w pierwszej warstwie.


Architektura warstwowa

Jednak to rozwi膮zanie ma r贸wnie偶 kilka wad. Gdy moneta pojawi si臋 na drugiej warstwie, bezpiecze艅stwo Twoich monet jest w pe艂ni zale偶ne od tej warstwy. LN nie ma konsensusu sieciowego, w kt贸rym w臋z艂y pr贸bowa艂yby uzgodni膰 jedn膮 wersj臋 鈥瀙rawdy鈥. Zamiast tego d膮偶y si臋 do tego, aby transfer monet mi臋dzy warstwami by艂 wystarczaj膮co bezpieczny i aby monet nie mo偶na by艂o wytworzy膰 znik膮d lub zgubi膰 w ustalonym kanale p艂atno艣ci, na przyk艂ad mi臋dzy Alice i Bobem. Bezpiecze艅stwo b臋dzie nadzorowane przez scentralizowane podmioty zwane Obserwatorami (ang. Watchers).

Teraz wyobra藕 sobie sytuacj臋, w kt贸rej Alice otworzy艂a kana艂 p艂atno艣ci A z Bobem, aby m贸c szybko wysy艂a膰 monety w Lightning Network, a Bob otworzy艂 kolejny kana艂 p艂atno艣ci B z Carol. Zobacz zdj臋cie poni偶ej.

呕贸艂te kropki reprezentuj膮 monety. Ka偶dy uczestnik mo偶e przes艂a膰 3 monety do swojego odpowiednika za po艣rednictwem kana艂u. Zauwa偶, 偶e nie ma bezpo艣redniego kana艂u utworzonego mi臋dzy Alice i Carol. Gdyby Alice chcia艂a wys艂a膰 3 monety do Carol, mo偶na by stworzy膰 nowy kana艂 poprzez powoln膮 i kosztown膮 transakcj臋 w sieci na pierwszej warstwie. Drug膮 opcj膮 jest u偶ycie obu ju偶 otwartych kana艂贸w p艂atno艣ci A i B. W tym przypadku monety Boba musz膮 by膰 u偶yte do przeniesienia warto艣ci z portfela Alice dp Carol. Na koniec Alice b臋dzie mia艂a 0 monet, a Bob b臋dzie mia艂 6 monet w kanale A, kt贸ry jest otwarty mi臋dzy nimi. Carol b臋dzie mia艂a 6 monet. Bob b臋dzie mia艂 0 monet na kanale B, kt贸ry jest otwarty mi臋dzy Bobem i Carol. Bob ma 6 monet przed i po transakcji mi臋dzy Alice i Carol. Jednak jego p艂ynno艣膰 na kanale B wynosi teraz 0.

Zasadniczo oznacza to, 偶e Bob nie jest ju偶 w stanie wysy艂a膰 monet do Carol, a Alice nie jest w stanie wys艂a膰 偶adnych monet do Boba. Wi臋c je艣li Alice chcia艂a wys艂a膰 monety do Boba, kana艂 A musi zosta膰 zamkni臋ty i ponownie otwarty poprzez transakcje pierwszej warstwy. To samo jest potrzebne, je艣li Bob chce wys艂a膰 monety do Carol. Dodajmy, 偶e wszystkie portfele musz膮 by膰 online, aby mog艂a nast膮pi膰 transakcja mi臋dzy Alice i Carol.

Aby wysy艂a膰 monety w wielu kana艂ach, musi istnie膰 podmiot w sieci, kt贸ry jest w stanie stale monitorowa膰 aktualny status wszystkich kana艂贸w i szuka膰 trasy, kt贸r膮 mo偶na wykorzysta膰 do p艂atno艣ci. Wraz ze wzrostem liczby u偶ytkownik贸w i liczby kana艂贸w mo偶e to sta膰 si臋 zadaniem coraz trudniejszym obliczeniowo, a proces prawdopodobnie doprowadzi do centralizacji. Aby wysy艂a膰 monety wieloma kana艂ami, kana艂y musz膮 mie膰 wystarczaj膮c膮 p艂ynno艣膰. Po wyczerpaniu p艂ynno艣ci kana艂y musz膮 zosta膰 zamkni臋te i ponownie otwarte. LN jest przeznaczony wy艂膮cznie do mikrotransakcji. Wysy艂anie wi臋kszych kwot zawsze mo偶e by膰 trudne, a niekt贸rych b艂臋d贸w w p艂atno艣ciach prawdopodobnie nie da si臋 unikn膮膰.

Proof of stake a rozwi膮zania drugiej warstwy

Rozwi膮zania drugiej warstwy s膮 zdecydowanie wa偶ne i b臋d膮 potrzebne. Z drugiej strony LN niekoniecznie jest kompletnym i wystarczaj膮cym rozwi膮zaniem problemu skalowalno艣ci. Wyobra藕 sobie, 偶e b臋dzie wiele drugich warstw, a te drugie warstwy b臋d膮 r贸wnie偶 wymienia膰 monety ze sob膮. W tej sytuacji bardzo trudno b臋dzie okre艣li膰, ile monet lub token贸w mo偶e istnie膰. Im wi臋cej sieci drugiej warstwy, tym trudniej b臋dzie zsynchronizowa膰 dane o liczbie monet w obiegu.

Rozwi膮zanie problemu skalowalno艣ci w pierwszej warstwie za po艣rednictwem protoko艂u Ouroboros PoS jest prawdopodobnie bardziej niezawodnym i bezpiecznym rozwi膮zaniem. Druga i dodatkowe warstwy s膮 r贸wnie偶 potrzebne w systemie, w kt贸rym b臋dzie u偶ywany proof of stake. Zawsze jednak pojawia si臋 pytanie, jak zapewni膰 dobre bezpiecze艅stwo wy偶szych warstw oraz jak cz臋sto i za ile mo偶liwe b臋dzie dokonanie rozliczenia na pierwszej warstwie. Pierwsza warstwa zawsze b臋dzie najbezpieczniejsza. Trzymanie monet w wy偶szych warstwach przez d艂ugi czas mo偶e nie by膰 niezawodne, a je艣li wiele rozlicze艅 b臋dzie ci膮gle wykonywana na pierwszej warstwie, mo偶e ona nadal si臋 zapycha膰, a op艂aty transakcyjne mog膮 by膰 wysokie.

Wiele os贸b twierdzi, 偶e PoS nigdy nie b臋dzie tak bezpieczny jak proof of work. IOHK matematycznie udowodni艂, 偶e jest to mo偶liwe przy u偶yciu nowoczesnej kryptografii. Nikt nie zaprzecza, 偶e potrzebne na rynku s膮 zar贸wno zastosowania typu proof of work jak i proof of stake. Zastosowanie otwartych sieci rozproszonych jest nadal bardzo niskie, a jedn膮 z cz臋sto dyskutowanych przeszk贸d jest problem skalowalno艣ci. Jednak mamy gotowe rozwi膮zania. W przypadku Cardano np. to druga warstwa, Hydra i PoS z shardingiem. Teraz potrzebujemy tylko czasu, aby wypr贸bowa膰 oba rozwi膮zania i pozwoli膰 ludziom wybiera膰.

Druga warstwa, taka jak Lightning Network, prawdopodobnie zawsze b臋dzie wymaga艂a otwierania i zamykania kana艂贸w oraz dbania o p艂ynno艣膰 w nich. U偶ytkownik musi zastanowi膰 si臋, z kim otwiera dany kana艂 i ile 艣rodk贸w wymagane jest, aby wykona膰 transfery. Je艣li transakcje na pierwszej warstwie s膮 kosztowne, utrzymanie kana艂贸w na drugiej warstwie te偶 b臋dzie kosztowne. Nie musisz si臋 z tym k艂opota膰 w ramach PoS. B臋dziesz mie膰 wszystkie swoje zasoby w jednym portfelu i mo偶esz wys艂a膰 bezpo艣rednie transakcje do dowolnej osoby w dowolnym momencie. Wszystko dzieje si臋 na blockchainie. Nie ma zale偶no艣ci od portfeli internetowych, p艂ynno艣ci, w臋z艂贸w szukaj膮cych tras, a u偶ytkownicy nie musz膮 polega膰 na sieciach off-chain (poza blockchainem). Przynajmniej z punktu widzenia interfejsu u偶ytkownika, PoS mo偶e zaoferowa膰 znacznie 艂adniejsze rozwi膮zanie

Podsumowanie

Blockchain mo偶e zapewni膰 kontrol臋 w艂asno艣ci aktyw贸w. Jest to 艣wietna funkcja, kt贸rej baza danych nie mo偶e zaoferowa膰. Aby ta funkcja zosta艂a powszechnie przyj臋ta, musi by膰 technicznie 艂atwo dost臋pna. W chwili obecnej jest to trudne, ale wszystko idzie w dobr膮 stron臋. Je艣li ludzie zdecyduj膮 si臋 w wi臋kszym stopniu wykorzysta膰 potencja艂 stoj膮cy za blockchainem, mo偶liwo艣ci s膮 prawie nieograniczone.

Zwolennicy PoW twierdz膮, 偶e PoS nie b臋dzie dzia艂a膰. Nale偶y zda膰 sobie spraw臋, 偶e system proof of work dzia艂a wzgl臋dnie dobrze. Z kolei nad protoko艂em Cardano du偶y zesp贸艂 ekspert贸w pracuje od ponad 5 lat. Nie ma 偶adnego logicznego powodu, by s膮dzi膰, 偶e im si臋 nie uda. Rynek jest wci膮偶 bardzo m艂ody. Zawsze lepiej jest mie膰 mo偶liwo艣膰 wyboru spo艣r贸d wi臋kszej liczby alternatyw ni偶 by膰 zmuszonym do korzystania z jednego rozwi膮zania.

Artyku艂 jest t艂umaczeniem wpisu z bloga Cardanians.io z drobnymi zmianami.

2 Likes

wow, bardzo fajny artyku艂 @cornl
Chyba pokusz臋 si臋 za jaki艣 czas o video.
P贸ki co zapraszam na faz臋 Basho / skalowalno艣膰 po japo艅sku na Kanale YT 鈥淒zienna Dawka Dyskomfortu鈥

1 Like

Dzi臋ki, a Twoje ostatnie filmy o Cardano s膮 naprawd臋 na poziomie. Dzi艣 widzia艂em, 偶e dotar艂e艣 nawet dalej, do fazy Voltaire :wink: w https://www.youtube.com/watch?v=jdC7BRA3kQA

1 Like

Dobra robota

1 Like

Dzi臋ki :slight_smile: zach臋cam do udost臋pniania dalej :wink:

1 Like