Zakończenie debaty bitcoin kontra blockchain

Węzeł źródłowy: 1849174

Czy jest jakaś wartość w łańcuchu bloków bez kryptowaluty?

Debata trwa już od jakiegoś czasu, ale w zeszłym miesiącu nastąpiła poważna poprawa. Zadawane pytanie brzmi:

Czy jest jakaś wartość w łańcuchu bloków bez kryptowaluty? I czy te „beztokenowe wspólne księgi” można w ogóle nazwać łańcuchami bloków?

Więc czytałem Artykuł Baileya, Obejrzane Wideo Tima, przeczytaj ten post na Nasdaq, po Richarda każdy słowo, a nawet miałem własne dobra debata (patrz komentarze) z Chrisem DeRose z fundacji Counterparty. Tyle gorącego powietrza.

Jedna rzecz, którą Chris robi dobrze, sprowadza się do pytania: czy blockchain jest innowacją ekonomiczną czy informatyczną? Wynika z tego, że jeśli łańcuchy bloków są czysto ekonomiczną innowacją, nie ma sensu ich stosowanie bez kryptowalut. Pozwólcie więc, że przedstawię moją pozycję na początku:

Blockchain bitcoin był zarówno ekonomiczny i innowacja informatyczna.

Pozwalam na włączenie tu „innowacji” nowe połączenie istniejących technikzamiast czegoś, co nie ma żadnego precedensu. Definicja ta pozwala uważać światową sieć za innowację, mimo że nie przyniosła ona więcej niż połączenie hipertekstu z modyfikacją niektórych istniejących protokołów internetowych. Jeśli chcesz przyjąć bardziej rygorystyczną definicję innowacji, bądź moim gościem, ale będziesz zaskoczony, jak niewiele pozostaje prawdziwych „innowacji”. Parafrazować Nauczyciel, pod słońcem jest mało nowego.

Mówiąc dokładniej, twierdzę, że łańcuchy bloków bez tokena służą celowi, ale to jest inny cel w porównaniu z oryginalnym blockchainem Bitcoin. Głowy kryptowalut śmieją się z łańcuchów blokowych wolnych od tokenów, ponieważ nie mogą zapewnić odporności na cenzurę i zdecentralizowanego bezpieczeństwa poprzez dowód pracy. Fintechowcy śmieją się z publicznych blockchainów, ponieważ są one powolne, drogie i nieodpowiednie dla tradycyjnych finansów. Cóż, śmiejcie się dalej, bo wierzę, że oboje macie rację.

Będę argumentował, że łańcuchy bloków bez tokenów są przydatne do utrzymywania synchronizacji zdecentralizowanych baz danych, nawet w jednej organizacji, do której istnieje pełne zaufanie. A potem zobaczymy, jakie inne funkcje oferują blockchainy, dzięki czemu nadają się do tworzenia konsensusu dla określone rodzaje transakcji między organizacjami, gdzie zaufanie jest ograniczone i niedoskonałe.

Niestety, aby podążać za tym argumentem, będziesz musiał pogadać ze mną na temat modelu transakcyjnego Bitcoin, kontroli współbieżności baz danych (MVCC) i problemu rozwiązywania konfliktów w replikacji bazy danych z wieloma wzorcami. Zrobię co w mojej mocy, aby trzymać się angielskiego, ale nadal jest to kwestia techniczna i nie da się jej uniknąć.

Model transakcyjny Bitcoina

Model transakcyjny Bitcoin jest prosty, ale potężny. Każda transakcja bitcoin ma zestaw wejść i zestaw wyjść. Każde wejście „wydaje” jedno wyjście poprzedniej transakcji. Wszystkie bitcoiny wchodzące w skład transakcji wpływają do tej transakcji i są rozdzielane na jej wyjścia zgodnie z zapisanymi w nich ilościami. W ten sposób transakcje tworzą wielostronnie połączony łańcuch, który kończy się na transakcjach „bazy monet”, w których tworzone są nowe bitcoiny.

Bitcoin ma kilka dodatkowych reguł, które są egzekwowane przez każdy węzeł w sieci:

  • Każde wejście w transakcję musi udowadniać, że ma prawo wydać poprzednie dane wyjściowe, z którymi jest połączone. Prawo to jest ograniczone warunkami zakodowanymi w poprzednim wyjściu.
  • Transakcja musi mieć wystarczającą ilość bitcoinów w wejściach, aby pokryć sumę zapisaną na jej wyjściach. Jedynymi wyjątkami są transakcje w bazie monet, które tworzą nowe jednostki waluty.
  • Każde wyjście może zostać wydane tylko raz, innymi słowy, może być połączone tylko z jednym wejściem w jednej kolejnej transakcji.

Ze względu na tę ostatnią zasadę sieć wymaga mechanizmu umożliwiającego osiągnięcie konsensusu co do tego, które transakcje są ważne, i to właśnie robi blockchain. Konkretnie:

Jeśli dwie transakcje będą próbowały wydać ten sam wynik, ostatecznie tylko jedna z nich zostanie zaakceptowana. Blockchain działa jako ujednolicony mechanizm wykrywania i zapobiegania takim konfliktom w sieci.

Blockchain jest zbudowany jako seria połączonych bloków, w których każdy blok zawiera zestaw transakcji, które nie powodują konfliktów między sobą ani z poprzednimi blokami, począwszy od pierwszego bloku utworzonego w 2009 roku. Teoretycznie łańcuch mógłby zawierać serie pojedynczych transakcji, ale grupując transakcje w bloki, uzyskujemy szereg usprawnień, które czynią schemat bardziej praktycznym.

Jaki jest więc w tym wszystkim cel kryptowaluty? Sprowadza się do pytania, kto decyduje o blokach tworzących łańcuch. Bitcoin jest zdecentralizowany i nie ma władzy, która może podjąć taką decyzję, dlatego musi znaleźć inny sposób na osiągnięcie konsensusu.

Chcielibyśmy zastosować podejście demokratyczne, w którym węzły w sieci głosują na bloki, a większość wygrywa. Niestety, jak może wykazać każda ankieta internetowa, demokracja przedstawicielska nie jest możliwa w Internecie z powodu problemu podszywania się (znanego również jako Atak Sybil). Jedna osoba może przejąć milion komputerów i decydować o sposobie głosowania, przejmując w ten sposób kontrolę nad konsensusem sieciowym. Nikt inny nawet nie będzie wiedział, że to się stało.

Aby rozwiązać ten problem, bitcoin celowo utrudnia dodanie bloku do łańcucha poprzez proces zwany „wydobyciem”. Aby utworzyć blok, musisz rozwiązać trudny, ale bezsensowny problem matematyczny, który wymaga wielu obliczeń (a więc energii elektrycznej i pieniędzy). Potrzebujesz też szczęścia, ponieważ konkurujesz z wieloma innymi górnikami blokowymi na całym świecie. Kupując mocniejszy komputer górniczy, nie da się długo wyprzedzić, ponieważ sieć regularnie dostosowuje poziom trudności problemu, aby utrzymać stały globalny wskaźnik jednego bloku na 10 minut.

Jeśli stworzenie bloku jest tak trudne i kosztowne, po co ktoś miałby się tym przejmować? Odpowiedź jest w nagrodzie za blok. Udany górnik bloku kontroluje transakcję w bazie monet, która przyznaje mu 25 bitcoinów (ta suma zmniejsza się o połowę co cztery lata). Mogą sprzedać te bitcoiny na otwartym rynku za 7,000 USD (po dzisiejszym kursie), spłacić rachunek za prąd i, miejmy nadzieję, zarobić. Górnicy pobierają też trochę więcej z opłat, które są związane z transakcjami, chociaż na razie opłaty te odgrywają niewielką rolę.

Tak więc bitcoin generuje konsensus poprzez dowód pracy, a sedno argumentu głów bitcoinów jest następujące: Bez kryptowaluty nie ma sposobu, aby zachęcić do zdecentralizowanego wydobywania bloków. Dlatego nie ma sposobu, aby zabezpieczyć otwarty łańcuch bloków przed atakami podszywania się. Dlatego każdy może zmonopolizować konsensus sieci i uczynić całość bezużyteczną. Nie będę się z tym kłócić.

Kontrola współbieżności w wielu wersjach

W międzyczasie chcę porozmawiać o czymś, co może wydawać się zupełnie niezwiązane.

Baza danych to repozytorium ustrukturyzowanych informacji, pogrupowanych w elementy przypominające arkusze kalkulacyjne, zwane tabelami. Prostym przykładem takiej tabeli jest lista rachunków bankowych, w której każdy wiersz zawiera numer rachunku wraz z saldem tego rachunku. Załóżmy, że dzień na Twoim koncie zaczyna się z saldem 900 USD. Na dzień dzisiejszy zaplanowana jest automatyczna spłata kredytu hipotecznego w wysokości 750 USD, a ponadto musisz wypłacić 400 USD z bankomatu. Niestety nie masz kredytu w rachunku bieżącym, więc jedna z tych operacji jest skonfigurowana jako nieudana.

Procesy spłaty kredytu hipotecznego i wypłaty z bankomatów działają w oddzielnych systemach, z których oba mają dostęp do tej bazy danych jednego konta. Powiedzmy, że każdy proces działa poprzez odczyt salda konta, sprawdzenie, czy wystarczy do operacji, zainicjowanie tej operacji, sprawdzenie, czy operacja się zakończyła, obliczenie nowego salda, a następnie zapisanie go do bazy danych.

Dopóki spłata kredytu hipotecznego i wypłata z bankomatu nie pokrywają się, ta logika będzie działać dobrze. Pierwsza operacja zakończy się powodzeniem, a druga zostanie przerwana, ponieważ na koncie nie ma wystarczających środków. W zależności od zamówienia otrzymasz zły telefon z banku lub niegrzeczną wiadomość na ekranie bankomatu.

Ale co się stanie, jeśli oba procesy rozpoczną się w tym samym czasie? W takim przypadku każdy przeczyta saldo Twojego konta i uzna, że ​​wystarczy, aby kontynuować. Po zakończeniu spłaty kredytu hipotecznego Twoje nowe saldo zostanie obliczone na 150 USD i zapisane w bazie danych. Po zakończeniu wypłaty z bankomatu Twoje nowe saldo w wysokości 500 USD zostanie podobnie zapisane. Jedna z tych operacji zapisu zastąpi drugą i, w zależności od szczęścia, otrzymasz z banku premię w wysokości 750 lub 400 USD. Bez wątpienia wkrótce nauczysz się, jak zaplanować wizyty w bankomacie na dzień spłaty kredytu hipotecznego.

Oczywiście tak się nie dzieje w rzeczywistości z powodu technologii baz danych o nazwie nadzór konkurencji. Dzięki kontroli współbieżności nasze dane (zwłaszcza finansowe) są rozsądne i bezpieczne, a przybiera ona wiele form. Jednak wszystkie podzielają zasadę, że operacje na bazach danych są grupowane w „transakcje”, które są traktowane niepodzielnie, co oznacza, że ​​jako całość kończą się sukcesem lub niepowodzeniem. Współbieżność zachowuje spójność, blokując lub zamrażając części bazy danych, gdy są one używane przez jedną transakcję, aby uniemożliwić innym transakcjom działanie na tych samych informacjach w sprzeczny sposób.

Gdybyśmy nie musieli uruchamiać transakcji równolegle, moglibyśmy zablokować całą bazę danych na cały czas trwania każdej pojedynczej transakcji. Jednak nie jest to praktyczne w większości rzeczywistych zastosowań. Dobry schemat kontroli współbieżności pozwala na operacje równoległe poprzez blokowanie jak najmniejszej ilości danych na tak krótki czas, jak to tylko możliwe. W powyższym przykładzie tylko wiersz bazy danych odpowiadający Twojemu kontu byłby zablokowany i tylko na ułamek sekundy, w którym miało miejsce ostateczne sprawdzenie i odliczenie. Konfliktowa transakcja działająca równolegle musiałaby po prostu poczekać, aż ta blokada zostanie zwolniona.

Jedna z popularnych technik kontroli współbieżności nosi nazwę kontrola współbieżności wielu wersjilub w skrócie MVCC. W MVCC każda transakcja widzi spójną migawkę danych w określonym momencie, nawet jeśli część tych danych jest aktualizowana przez drugą jednoczesną transakcję. To izolacja migawki właściwość zapewnia, na przykład, że wyciąg pokazujący nasze całkowite saldo na kilku kontach zawsze będzie poprawny, nawet jeśli niektóre środki są w trakcie przenoszenia z jednego konta na drugie. Jedna transakcja wpłynie na dane widziane przez drugą transakcję tylko wtedy, gdy druga rozpocznie się po pomyślnym zastosowaniu wszystkich zmian pierwszej.

W tle MVCC działa, umożliwiając jednoczesne utrzymywanie wielu wersji wiersza, wraz ze znacznikiem czasowym, który reprezentuje datę ostatniej modyfikacji każdej wersji. Modyfikacja wiersza bazy danych w MVCC oznacza bieżącą wersję tego wiersza do usunięcia, podczas stosowania modyfikacji do pliku kopia tego wiersza ze zaktualizowaną sygnaturą czasową. Z punktu widzenia warstwy przechowywania bazy danych nie ma czegoś takiego jak modyfikowanie wiersza w miejscu. Każda transakcja dokładnie wie, kiedy się rozpoczęła i widzi tylko wersje wierszy, których sygnatura czasowa jest wcześniejsza. Stare wersje wierszy można usunąć z magazynu, gdy nie ma żadnych trwających transakcji, które mogą wymagać dostępu do nich.

MVCC, co najważniejsze dla naszych celów, zapobiega konfliktom między operacjami zapisu. Konkretnie:

Jeśli dwie transakcje próbują usunąć tę samą wersję wiersza, ostatecznie tylko jedna z tych transakcji zostanie zaakceptowana. Kontrola współbieżności wielu wersji działa jak ujednolicony mechanizm wykrywania i zapobiegania takim konfliktom w bazie danych.

Zadzwonić w dzwony? Musimy omówić jeszcze jeden element tła.

Replikacja bazy danych z wieloma wzorcami

Porozmawiajmy teraz o replikacji bazy danych, w której baza danych istnieje w wielu kopiach. Istnieje wiele dobrych powodów, dla których warto replikować bazę danych, takich jak:

  • Aby zwiększyć niezawodność, tak aby w przypadku utraty jednej kopii bazy danych (np. Z powodu awarii dysku) można było błyskawicznie przełączyć się na drugą kopię.
  • Aby zwiększyć przepustowość, jeśli wielkość operacji przekracza możliwości pojedynczego serwera bazy danych.
  • Aby zmniejszyć opóźnienia, aby procesy działające w biurze w Singapurze nie musiały czekać na odpowiedzi z bazy danych znajdującej się w Toronto.

Jeśli chodzi o czytanie danych z baz danych, replikacja jest techniką idealną, ponieważ wszystkie repliki zawierają te same informacje. Jednak sytuacja staje się trudniejsza, jeśli chodzi o operacje zapisu, ponieważ musimy zdecydować, gdzie te operacje zapisu są wykonywane i jak są przenoszone do innych kopii bazy danych.

Najczęstszą odpowiedzią jest użycie replikacji typu master-slave, w której pojedyncza baza danych („master”) jest uznawana za autorytatywną. Wszelkie zmiany danych są dokonywane wyłącznie na urządzeniu głównym, a następnie przesyłane są do wszystkich innych „podrzędnych” baz danych za pośrednictwem dziennika transakcji. Dzięki temu wszystkie kopie bazy danych (mniej lub bardziej) są natychmiast zsynchronizowane.

Niestety, jeśli operacje zapisu są częste, replikacja typu master-slave prowadzi nas z powrotem do problemu, który replikacja miała rozwiązać. Baza danych master staje się wąskim gardłem pod względem niezawodności, przepustowości i opóźnień, ponieważ każda operacja zapisu jest wykonywana samodzielnie.

Bardziej złożona strategia nazywana jest replikacją wielowzorcową, w której zapisy mogą być wykonywane na dowolnej kopii bazy danych, a nie na pojedynczym wzorcu. W takim przypadku kopie udostępniają sobie aktualizacje na zasadzie peer-to-peer, aby zachować synchronizację.

W teorii brzmi to prosto, ale replikacja z wieloma wzorcami wprowadza nowy problem, ponieważ mogą wystąpić konflikty. Co się stanie, jeśli dwie kopie bazy danych zaktualizują ten sam wiersz w tym samym czasie, a następnie spróbują wymienić te aktualizacje między sobą? Obie bazy danych zauważą, że miała miejsce aktualizacja powodująca konflikt, i będą musiały zastosować jakąś uzgodnioną strategię rozwiązywania tych konfliktów. I tu się dzieje dość złożony - zobacz dokumentację MySQL, SQL Server or wyrocznia kilka przykładów strategii rozwiązywania konfliktów. (Ignoruję synchroniczną lub tak zwaną „gorączkową” replikację wielowzorcową, w której wszystkie repliki muszą wykonać operację zapisu, zanim będzie mogła ona mieć miejsce, ponieważ każdy kopię bazy danych w wąskie gardło).

Oto, dokąd prowadzi całe to tło:

Czy nie byłoby miło, gdybyśmy mogli mieć rozproszoną kontrolę współbieżności wielu wersji, aby zapobiec konfliktom występującym w replikacji z wieloma wzorcami?

Cóż, tak, wyobrażam sobie, że byłoby to naprawdę bardzo miłe. Uważam, że właśnie to robią blockchainy.

Blockchainy jako rozproszone MVCC

Przepiszmy kilka zdań, które napisałem pogrubioną czcionką powyżej:

Jeśli dwie transakcje próbują wydać to samo wydajność, wtedy tylko jedna z tych transakcji zostanie ostatecznie zaakceptowana. Blockchain działa jako ujednolicony mechanizm wykrywania i zapobiegania takim konfliktom w całej sieci.

Jeśli dwie transakcje próbują usunąć to samo wersja wierszowa, wtedy tylko jedna z tych transakcji zostanie ostatecznie zaakceptowana. Kontrola współbieżności w wielu wersjach działa jako ujednolicony mechanizm wykrywania i zapobiegania takim konfliktom w bazie danych.

Zdania te są identyczne z wyjątkiem pogrubionych terminów. Oto, co zamierzam twierdzić:

Blockchain zapewnia rozproszone MVCC (z kilkoma dodatkowymi dzwonkami i gwizdkami).

Rozwińmy to porównanie nieco dalej. Z perspektywy węzła blockchain, bieżący zestaw niewydanych wyników transakcji bitcoin tworzy bazę danych, w której każdy wiersz jest pojedynczym niewydanym wyjściem. Jest to podobne do bazy danych rachunków bankowych, które opisaliśmy wcześniej, z tą niewielką różnicą, że saldo każdego rachunku można podzielić na wiele wierszy, z których każdy jest oznaczony tym samym numerem konta.

Transakcja bitcoin zużywa co najmniej jeden z tych wyników i tworzy w rezultacie co najmniej jedno nowe wyjście. To jest dokładnie jak transakcja bazy danych, która usuwa jedną lub więcej wersji wierszy i w rezultacie tworzy jeden lub więcej nowych wierszy (pamiętaj, że w MVCC nie ma czegoś takiego jak modyfikowanie wiersza w miejscu). Blockchain Bitcoin zapewnia, że ​​jedno wyjście nie może zostać wydane przez więcej niż jedną transakcję. Jest to równoważne z zapewnieniem, że wersja z jednym wierszem nie może zostać usunięta przez więcej niż jedną transakcję bazy danych.

Zanim damy się ponieść emocjom, nie twierdzę, że łańcuchy bloków to świetna technologia ogólnego przeznaczenia do rozproszonej synchronizacji baz danych w całkowicie zaufanym środowisku. Istnieje wiele innych technologii, takich jak Paxos, Raft i Zatwierdzenie dwufazowe które wykonują pracę bardzo ładnie. Ale wierzę, że łańcuchy bloków mają swoje słodkie miejsce, które można scharakteryzować jako aplikacje, w których:

  • Możemy zaakceptować krótkie opóźnienie między momentem, w którym transakcja zostanie prawdopodobnie zaakceptowana, a ostatecznym przyjęciem. (To opóźnienie może być kwestią sekund, a nie 10 minut, jak w przypadku bitcoin).
  • Sprzeczne transakcje nigdy nie powinny mieć miejsca, jeśli wszyscy są uczciwi, a ich systemy działają prawidłowo.
  • Każda transakcja modyfikuje tylko kilka wierszy jednocześnie (w przeciwnym razie nasze transakcje w łańcuchu bloków będą miały nieporęczną liczbę danych wejściowych).
  • Rozmiar każdego wiersza bazy danych jest dość mały (ponownie, aby zapobiec zwiększeniu rozmiaru naszych transakcji w łańcuchu bloków).

Wszystkie te kryteria spełniają aplikacje finansowe. Świat finansów jest już przyzwyczajony do opóźnień (nawet do 3 dni!) Pomiędzy przeprowadzeniem transakcji a jej ostatecznym rozliczeniem. Jeśli chodzi o zapobieganie konfliktom, posiada umowy i regulacje dotyczące wykrywania oszustw, a konsekwencje mogą być poważne. A ilość danych związanych z każdą transakcją jest dość mała - pomyśl o przykładzie konta bankowego powyżej.

Jak dotąd pokazałem tylko, że łańcuchy bloków to kolejny mechanizm synchronizacji rozproszonych baz danych. Wielkie wow. Rzeczy stają się naprawdę interesujące tylko wtedy, gdy weźmiemy pod uwagę dodatkowe funkcje, które zapewniają łańcuchy bloków.

Blockchainy poza MVCC

Transakcja bitcoin to znacznie więcej niż tylko wskazanie niektórych wcześniejszych wyników transakcji i utworzenie w ich miejsce nowych. Nawet najprostsza transakcja bitcoin służy dwóm dodatkowym celom.

Po pierwsze, zasady dotyczące ważnych transakcji zawierają część logiki aplikacji dla naszej bazy danych rachunków. Przypomnij sobie, że całkowita ilość bitcoinów we wejściach transakcji musi pokrywać całkowitą ilość w wyjściach. W tłumaczeniu na logikę aplikacji bazodanowej jest to reguła, która stwierdza, że ​​transakcje bazodanowe (z wyjątkiem baz monet) nie mogą zwiększać całkowitej ilości bitcoinów w bazie danych. Tego rodzaju ograniczenie wykracza poza zwykłą bazę danych procedury składowane ponieważ w żadnych okolicznościach nie można go obejść.

Po drugie, pamiętaj, że każdy wynik transakcji bitcoin koduje warunki, w jakich może zostać wydany. W przypadku zwykłych bitcoinów warunek ten jest oparty na kryptografii klucza publicznego. Adres publiczny jest osadzony w wyjściowym „skrypcie”, dzięki czemu można go używać tylko przy użyciu klucza prywatnego odpowiadającego temu adresowi publicznemu. Jeśli weźmiemy pod uwagę te dane wyjściowe jako wiersz bazy danych, otrzymamy bazę danych z uprawnieniami do każdego wiersza, które są oparte na kryptografii klucza publicznego. Ponadto każda transakcja przedstawia publicznie podlegający audytowi dowód, że jej twórca (y) miał prawo do usuwania / modyfikowania jej poprzednich wierszy. To (jak sądzę) jest prawdziwą nowością w technologii baz danych.

I znowu tak się składa, że ​​obie te funkcje są niezwykle przydatne w zastosowaniach finansowych. Podoba nam się fakt, że nasza baza danych zapewnia na najniższym możliwym poziomie, że pieniędzy nie da się stworzyć z powietrza. Lubimy mieć niezaprzeczalną ścieżkę audytu pokazującą, że każda transakcja była autoryzowana przez posiadacza środków, które przeniosła. Tak jak szczegółowo omówione tutaj, możemy również lubić przeprowadzanie bezpiecznych, atomowych transakcji wymiany peer-to-peer (dostawa kontra płatność w rozmowie o finansach), nawet nie znając tożsamości naszego kontrahenta.

Więc gdzie jest token?

Oczywiście nic z tego nie jest przypadkiem, ponieważ sam bitcoin jest piękną aplikacją finansową typu peer-to-peer. Jednak żadna z powyższych cech łańcucha blokowego nie jest w ogóle zależna od tokena. Jeśli zmodyfikujemy nasz schemat „bazy danych”, tak aby każdy wiersz mógł reprezentować wiele aktywów, a nie rodzimą walutę łańcucha blokowego, wówczas możemy całkowicie pozbyć się tej waluty. To pozostawia nam łańcuch bloków jako sposób na osiągnięcie konsensusu i bezpieczeństwa w aplikacji finansowej typu peer-to-peer dla dowolna klasa aktywów.

Tylko jedno małe pytanie: Kto zajmuje się wydobyciem, aby osiągnąć ten konsensus? W Bitcoin anonimowi górnicy muszą wykonywać kosztowne, bezużyteczne obliczenia i są do tego motywowani nagrodami blokowymi (i opłatami transakcyjnymi) denominowanymi w rodzimej walucie lub tokenie łańcucha blokowego. Czy mamy inne możliwości?

Okazuje się, że tak. Możemy mieć zamkniętą listę dozwolonych górników, którzy identyfikują się, podpisując utworzone przez siebie bloki. Zasady dotyczące rozproszonego konsensusu (lub „wydobywania różnorodności”, jak to nazywamy MultiChain) zapewniają inny sposób zapobiegania mniejszościowej kontroli łańcucha bloków, tak długo, jak możesz zaakceptować, że górnicy są wstępnie zatwierdzeni. Oczywiście w przypadku bitcoina jest to niedopuszczalne, ponieważ częściowo chodzi o zezwolenie na anonimowe wydobywanie, więc nie ma możliwości centralnego cenzurowania transakcji. Ale gdybyśmy, powiedzmy, mieli wysoce regulowany system finansowy, w którym model bitcoina nie miałby zastosowania, być może w końcu moglibyśmy zaakceptować wstępnie zatwierdzoną listę górników? Gdybyśmy mieli ich dość i wystarczająco dobrze rozprowadzili między instytucjami i zawarli z nimi wszystkie umowy prawne, czy naprawdę istnieje prawdopodobieństwo, że zrzeszą się i podkopią sieć, od której są zależni, kiedy to doprowadzi ich do więzienia?

Epilog

Mam nadzieję, że pokazałem, że łańcuchy bloków bez tokenów mają kilka przydatnych aplikacji, nawet jeśli są one bardzo różne od łańcucha bloków bitcoin. Niemniej jednak pozostaje jedno pytanie:

Czy te uprawnione, wolne od tokenów systemy współdzielonej księgi naprawdę zasługują na miano „blockchain”?

Krótka odpowiedź brzmi: kogo to obchodzi? Rzadko warto się spierać o znaczenie słów, ponieważ jest brak właściwej odpowiedzi.

Ale żeby pójść trochę głębiej, powiedzmy, że przyjmuję założenie, że blockchain bitcoin jest archetypem blockchain. W takim przypadku naprawdę powinniśmy zapytać:

Czy te wspólne księgi są na tyle podobne do bitcoina, że ​​zasługują na miano „blockchain”?

Oto mój osobisty pogląd tak. Ponieważ łączy ich ogromna liczba podobieństw technicznych, nawet jeśli różnią się modelem uprawnień i zachętami ekonomicznymi. A co najważniejsze, ponieważ oba generują konsensus w rozproszonej bazie danych za pośrednictwem pliku łańcuch bloków.

Dziękuję za przeczytanie tego bloga z roznymi moimi bledami ortograficznymi i skladniowymi.

Możesz śledź mnie na Twitterze tutaj. Zobacz też: Dostawa a płatność na blockchainie.

Oto kilka innych artykułów, które warto przeczytać na ten temat Piotra Piaseckiego i Wykop Campbell.

Znak czasu:

Więcej z Multichain