Ethereum: Wprowadzenie do Bitcoin i istniejących koncepcji

Wprowadzenie do bitcoin i istniejących koncepcji

Historia
Koncepcja zdecentralizowanej waluty cyfrowej, a także alternatywnych zastosowań, takich jak rejestry nieruchomości, istnieją już od dziesięcioleci. Anonimowe protokoły e-gotówkowe z 1980 i 1990 były w większości zależne od pierwotnych protokołów kryptograficznych, znanych jako Chaumian Blinding. Chaumian Blinding dostarczały nowych walut z wysokimi stopniami prywatności, ale ich podstawowe protokoły w znacznej mierze nie uzyskały właściwego stopnia przyczepności, ze względu na ich zależność od scentralizowanego pośrednika. W 1998 roku,  B-money od Wei Dai stały się pierwszą propozycją wprowadzenia idei tworzenia pieniędzy poprzez rozwiązywanie zagadek obliczeniowych, jak chociażby poprzez zdecentralizowanie konsensusu, jednakże propozycja ta była dość skąpa pod względem szczegółów odnośnie tego, w jaki sposób zdecentralizowany konsensus może być rzeczywiście realizowany. W 2005 roku Hal Finney wprowadził koncepcję „wielokrotnego użytku dowodów pracy”, systemu, który wykorzystuje pomysły zaczerpnięte z b-money, wraz z obliczeniowo trudnymi zagadkami Hashcash autorstwa Adama Back’a, aby stworzyć koncepcję dla krypto waluty, jednakże po raz kolejny było to dalekie od ideału, w wyniku powoływania się na zaufane obliczenia wyjściowe. W 2009 zdecentralizowana waluta została po raz pierwszy wdrożona w praktyce przez Satoshi Nakamoto, łącząc ustanowione funkcje pierwotne z zarządzaniem własnościami, stosując klucz kryptografii publicznej z algorytmu konsensusu poprzez śledzenie, kto jest właścicielem monet, odwołując się do pojęcia znanego jako „dowód pracy.”
Mechanizm odpowiedzialny za dowód wykonywania pracy okazał się przełomem, ponieważ równocześnie rozwiązywał dwa problemy. Po pierwsze, dostarczał prosty i efektywnie umiarkowany algorytm konsensusu, pozwalając węzłom w sieci, aby wspólnie mogły uzgodnić zestaw aktualizacji do stanu rejestru Bitcoin. Po drugie, dostarczał mechanizmu umożliwiającego wstęp do procesu konsensusu, rozwiązując problem politycznego decydowania, kto może mieć wpływ na konsensus, jednocześnie zapobiegając atakom z zewnątrz. Czynił to poprzez zastąpienie formalnej bariery uczestnictwa, takiej jak wymóg, by móc być zarejestrowanym jako unikalna jednostka o określonej liście, z barierą ekonomiczną – waga pojedynczego węzła w procesie głosowania konsensusu jest wprost proporcjonalna do mocy obliczeniowej, które dany węzeł przynosi. Od tego więc czasu, zaproponowano alternatywne podejście zwane proof of stake, poprzez obliczanie wagi węzła jako proporcjonalnej do posiadanych walut, a nie jego zasobów obliczeniowych. Dyskusja dotycząca względnych zalet obu rozwiązań znajduje się poza zakresem tego artykułu, jednakże należy tu zauważyć, że oba podejścia mogą być wykorzystane, aby służyć jako szkielet podstawy krypto walutowej.


Bitcoin jako System Przejściowy

stan_przejsc

 

Z technicznego punktu widzenia, rejestr z krypto walutowania taki jak Bitcoin może być traktowany jako system stanu przejściowego, w którym znajduje się „stan” składający się ze stanu posiadania wszystkich istniejących bit-monet i „funkcji stanu przejściowego”, które z kolei nadają temu stanowi oraz transakcji możliwość wygenerowania zupełnie nowego stanu, jako rezultatu końcowego. Przykładowo, w standardowym systemie bankowym, dany stan to bilans, a transakcja to żądanie przeniesienia $ X z punktu A do B, zaś funkcja stanu przejścia zmniejsza tutaj wartość na koncie użytkownika A przez $ X i zwiększa wartość konta użytkownika B przez $ X. Jeśli konto użytkowania A ma mniej niż $ X w pierwszej kolejności, to funkcja stanu przejścia zwraca błąd. Stąd można formalnie zdefiniować:

UŻYCIE(S,TX) -> S' lub BŁĄD
 W systemie bankowym zdefiniowanym powyżej:
 STOSOWAĆ ({ Alice: $50, Bob: $50 },"wysłać $20 od Alice do Bob") = { Alice: $30, Bob: $70 }
 Ale:
 UŻYCIE ({ Alice: $50, Bob: $50 },"wysłać $70 od Alice do Bob") = BŁĄD
„Stan” w Bitcoin jest zbiorem wszystkich monet (technicznie, jest „niewykorzystanym wyjściem transakcyjnym” lub UTXO), które zostały wybite i jeszcze nie wydane, z każdego UTXO posiadającego denominację i właściciela (zdefiniowanego przez adres 20-bajtowy, który jest zasadniczym kryptograficznym kluczem publicznym [1]). Transakcja zawiera jedno lub więcej wejść, z każdego wejścia zawierającego odniesienie do istniejącego UTXO i podpisu kryptograficznego utworzonego przez klucz prywatny związany z adresem właściciela, a także jedno lub więcej wyjść z każdego innego wyjścia, zawierającego nową UTXO jako dodatek do stanu.
Funkcja stanu przejściowego STOSOWAĆ (S,TX) -> S’ może być w przybliżeniu zdefiniowana następująco:
  1. Dla każdego wejścia w TX:

    • Jeżeli odwołanie UTXO nie znajduje się w S, to zwraca błąd.

    • Jeżeli dostarczony podpis nie pasuje do właściciela UTXO, to zwraca błąd.

  2. Jeżeli suma wszystkich denominacji wejściowych UTXO jest mniejsza niż suma wszystkich denominacji wyjściowych UTXO, to zwraca błąd.

  3. Zwrot S’ wraz ze wszystkimi wejściowymi UTXO usunięto i dodano wszystkie wyjścia UTXO.

Pierwsza połowa dotycząca realizacji kroku pierwszego uniemożliwia nadawcom transakcji wydawanie monet, które nie istnieją, druga połowa pierwszego kroku uniemożliwia nadawcom transakcji wydawanie monet innych ludzi, tak więc drugi etap wymusza zachowanie pewnych wartości. W celu wykorzystania tego odnośnie płatności, protokół jest następujący. Załóżmy, że Alice chce wysłać 11,7 BTC do Boba. Po pierwsze, Alice będzie szukać zestawu dostępnego UTXO, którego jest właścicielką, i który wynosi co najmniej 11,7 BTC. Realistycznie, Alice nie będzie w stanie uzyskać dokładnie 11,7 BTC; powiedzmy zatem, że najmniejszy jaki mogła dostać to 6 + 4 + 2 = 12. Następnie tworzy transakcję z tymi trzema wejściami i dwoma wyjściami. Pierwsze wyjście wyniesie 11,7 BTC z adresem Boba jako jej właściciela, zaś drugie wyjście będzie wynosić wartość pozostałych 0,3 BTC „zmiana”. Jeśli Alicja nie rości sobie tej zmiany, wysyłając ją na adres posiadany przez siebie, to wówczas górnik będzie mógł ją sobie zastrzec.

Górnictwo

gornictwo

Gdybyśmy mieli dostęp do wiarygodnego scentralizowanego serwisu, to system ten będzie banalny do wdrożenia; może to być kodowane dokładnie tak jak to opisano, za pomocą twardego scentralizowanego serwera do śledzenia stanu. Jednak, korzystając z Bitcoin staramy się zbudować system walutowy zdecentralizowany, więc musimy połączyć system stanu przejściowego z systemem konsensusu w celu zapewnienia, że wszyscy zgadzają się na zlecenie transakcji. Zdecentralizowany proces konsensusu Bitcoin wymaga węzłów w sieci, aby mieć możliwość stale próbować wytwarzać pakiety transakcji zwane „blokami”.

Sieć ma na celu stworzenie jednego bloku mniej więcej co dziesięć minut, gdzie każdy blok zawiera znacznik czasu, nonce (taki licznik w kryptografii), hash poprzedniego bloku oraz listy wszystkich transakcji, które miały miejsce w poprzednim bloku. Z biegiem czasu, tworzy się tu trwały, stale rosnący „łańcuch blokowy”, który stale dokonuje aktualizacji do przedstawienia aktualnego stanu rejestru Bitcoin.
Algorytm dla sprawdzenia, czy blok jest ważny, wyrażony w tym paradygmacie, jest następujący:

  1. Sprawdzić, czy poprzedni blok określony przez bloki istniejące jest ważny.

  2. Sprawdzić, czy znacznik czasu bloku będzie większy niż w poprzednim bloku, [2], i czy będzie trwał mniej niż 2 godziny w przyszłości.

  3. Sprawdzić, czy dowód pracy na bloku jest ważny.

  4. Niech S[0] będzie stanem końcowym poprzedniego bloku.

  5. Załóżmy, że TX jest listą transakcji bloku z transakcjami n. Dla wszystkich i w 0…n-1, zbiór S[i+1] = STOSOWAĆ (S[i],TX[i].) Jeśli jakaś aplikacja zwróci błąd, wyjście i powrót zwraca nieprawidłowość.

  6. Powrócić do prawidłowości, następnie zarejestrować S[n] jako stan na koniec tego bloku.

Zasadniczo, każda transakcja w bloku musi zapewnić poprawną zmianę stanu, który był stanem kanonicznym przed transakcją, która została wykonana do pewnego nowego stanu. Należy pamiętać, że stan ten nie jest zakodowany w bloku w jakikolwiek sposób; jest on typu wyłącznie abstrakcyjnego by być zapamiętanym przez węzeł zatwierdzenia i może być (bezpiecznie) obliczany tylko dla każdego bloku, zaczynając od stanu genezy oraz w wyniku kolejno stosowanej każdej transakcji w każdym bloku. Dodatkowo należy pamiętać, że kolejność w jakiej górnik uwzględnia transakcje w kwestiach blokowych; jeśli istnieją dwie transakcje A i B w bloku tak, że B zużywa UTXO stworzone przez A, a następnie blok będzie ważny, jeśli A jest przed B, ale nie inaczej.
Jedynym obecnym warunkiem ważności w powyższym wykazie, który nie występuje w innych systemach jest wymóg dla „dowodu pracy”. Dokładnym warunkiem jest tutaj to, że podwójny SHA256 z każdego bloku, traktowane są jako liczba 256-bitowa, muszą być mniejsze niż dynamicznie skorygowany cel, który począwszy od chwili pisania tego tekstu wynosi około 2**187. Celem tego jest to, aby utworzyć blok obliczeniowo „twardy”, zapobiegając atakom zewnętrznym przed przerobieniem całego łańcucha blokowego na ich korzyść. Ponieważ SHA256 ma być zupełnie nieprzewidywalną funkcją pseudolosową, jedynym sposobem, aby stworzyć ważny blok jest po prostu metoda prób i błędów, poprzez wielokrotne zwiększanie jednorazowe i obserwacje, czy nowe hashe się pokrywają.
Przy obecnym celu wynoszącym ~2^187, sieć musi mieć około ~2^69 prób zanim ważny blok zostanie znaleziony; na ogół cel zostanie ponownie skalibrowany przez sieć co 2016 bloków tak, że średnio nowy blok jest wytwarzany za pośrednictwem węzła w sieci, co dziesięć minut. W celu zrekompensowania górnikom tej obliczeniowej pracy, górnik każdego bloku ma prawo zawierać transakcję nadając sobie 25 BTC znikąd. Dodatkowo, jeżeli transakcja ma wyższą całkowitą denominację w swoich wejściach aniżeli w swoich wyjściach, różnica ta podąża w stronę górnika jako „opłata transakcyjna”. Nawiasem mówiąc, jest to również jedyny mechanizm, dzięki któremu BTC są wydawane; geneza stanu nie zawierała w ogóle żadnych monet.
Aby lepiej zrozumieć cel górnictwa, zbadajmy co dzieje się w przypadku złośliwego atakującego. Od kiedy bazowa kryptografia Bitcoin jest znana jako bezpieczna, atakujący będzie kierować swój atak na jedną część systemu Bitcoin, która nie jest chroniona przez kryptografię bezpośrednio: kolejność transakcji. Strategia atakującego jest prosta:

  1. Wysłać 100 BTC do handlującego w zamian za jakiś produkt (najlepiej szybko dostarczone dobro cyfrowe).

  2. Poczekać na dostawę produktu.

  3. Wykonać kolejną transakcję wysyłając te same 100 BTC do siebie.

  4. Postarać się przekonać sieć, że jej transakcja była tą, która doszła jako pierwsza.

Zanim nastąpi etap (1), po kilku minutach górnik uwzględnia transakcję w bloku, np. w bloku o numerze 270000. Po upływie około jednej godziny, kolejne pięć bloków zostanie dodanych do łańcucha po tym bloku, przy czym każdy z tych bloków pośrednio wskazuje na transakcję, a tym samym „zatwierdza” ją. W tym momencie, handlowiec będzie akceptować płatności jako zakończone i dostarczy produkt; skoro jesteśmy przy założeniu, że są to dobra cyfrowe, dostawa jest natychmiastowa. Teraz atakujący tworzy kolejną transakcję wysyłając 100 BTC do siebie. Jeśli atakujący po prostu wypuszcza ją, transakcja nie zostanie przetworzona; górnicy będą próbować uruchomić ZASTOSOWAĆ (S, TX) i zauważmy tu, że TX zużywa UTXO które już nie znajduje się w danym stanie. Ponieważ dane bloku są inne, wymaga to ponownego wykonania dowodu pracy. Ponadto, nowa wersja bloku atakującego o numerze 270000 posiada inne hashe, więc oryginalne bloki 270001 do 270005 nie „wskazują” na niego; w ten sposób oryginalny łańcuch i nowy łańcuch atakującego są całkowicie oddzielne. Zasadą tu jest, że w rozwidleniu najdłuższy łańcuch blokowy przyjmuje się za prawdę, tak więc pełnoprawnie górnicy będą pracować na łańcuchu 270005, podczas gdy sami atakujący pracują na łańcuchu 270000. Aby łańcuch blokowy atakującego był najdłuższy, będzie musiał mieć większą moc obliczeniową niż reszta sieci połączonej w celu nadrobienia zaległości (stąd, „51% atak”).


Drzewa Merkle’go 

merkle_tree_btc

Lewy: wystarczy przedstawić tylko niewielką liczbę węzłów w drzewie Markle’go, aby dać dowód ważności gałęzi.
Prawy: każda próba zmiany jakiejkolwiek części drzewa Merkle’go ostatecznie prowadzić będzie do niespójności gdzieś w górze łańcucha.
Ważną cechą skalowalności Bitcoin jest to, że blok jest przechowywany w strukturze danych wielopoziomowych. Hash bloku jest rzeczywiście tylko hashem nagłówka bloku. Nagłówek bloku to w przybliżeniu 200 bajtów danych, które zawierają znacznik czasu, nonce (licznik kryptograficzny), hash poprzedniego bloku i hash gałęzi, zwanej drzewem Merkle’go służącym do przechowywania wszystkich transakcji w danym bloku. Drzewo Merkle’go jest drzewem typu binarnego, składającego się z zestawu węzłów z dużą ilością węzłów liściowych w dolnej części drzewa, zawierających podstawowe dane, zbiór węzłów pośrednich, gdzie każdy z węzłów stanowi hash dwojga swoich dzieci i wreszcie jeden węzeł główny, także utworzony z hashu swoich dwojga dzieci, reprezentujący „wierzchołek” drzewa. Celem drzewa Merkle’go jest to, aby zezwolić danym w bloku na dostarczenie ich fragmentarycznie: węzeł pobiera tylko nagłówek bloku z jednego źródła, a niewielka część drzewa odpowiada im z innego źródła, lecz mimo to należy upewnić się, że wszystkie dane są poprawne. Powodem, dla którego tak to działa jest to, że zbędne dane rozchodzą się w górę: jeśli złośliwy użytkownik próbuje manipulować w fałszywej transakcji kierując ją w dół drzewa Merkle’go, zmiana ta spowoduje zmianę w węźle powyżej, a następnie zmianę w kolejnym węźle znajdującym się powyżej, aż wreszcie zmieniając korzenie drzewa i zbędne dane bloku, powodując zarejestrowanie protokołu jako zupełnie innego bloku (prawie na pewno z nieprawidłowym dowodem pracy).
Protokół drzewa Merkle’go jest niewątpliwie istotny dla długoterminowej stabilności. „Pełen węzeł” w sieci Bitcoin, taki, który przechowuje i przetwarza całość każdego bloku, zajmuje około 15 GB przestrzeni dyskowej w sieci Bitcoin na kwiecień 2014 roku, i rośnie o ponad gigabajt miesięcznie. Obecnie jest to opłacalne dla niektórych komputerów, lecz nie telefonów, a później w przyszłości tylko przedsiębiorcy i hobbyści będą mogli w tym uczestniczyć. Protokół znany jako „uproszczona weryfikacja płatności” (SPV) pozwala istnieć innej klasie węzłów, zwanej „lekkimi węzłami”, pobierając nagłówki bloku, weryfikując dowód pracy na nagłówkach bloku, a następnie pobierając tylko „gałęzie „związane z transakcjami, które są istotne dla nich. Pozwala to węzłom lekkim na określenie z silną gwarancją bezpieczeństwa jaki jest status każdej transakcji Bitcoin, oraz ich bieżącego salda podczas pobierania jedynie bardzo niewielkiej części całego łańcucha blokowego.


Alternatywne Aplikacje Łańcucha Blokowego
Pomysł rozważenia podstawowego pojęcia łańcucha blokowego i zastosowania go do innych pojęć także ma długą historię. W 2005 roku Nick Szabo wyszedł z koncepcją „bezpiecznych tytułów własności z uprawnieniem właściciela”, dokumentem opisujący to, jak „nowe osiągnięcia w replikowaniu technologii baz danych” pozwolą systemowi opartemu na łańcuchu blokowym do przechowywania ewidencji dotyczącej tego, kto jest właścicielem i jakiej ziemi, tworząc skomplikowaną strukturę obejmującą pojęcia, takie jak gospodarzenie, zasiedzenie i gruziński podatek gruntowy. Jednakże, nie było niestety wówczas dostępnych skutecznych zreplikowanych systemów baz danych w tamtym czasie, a więc protokół nie został wdrożony w praktyce. Po 2009 roku, po zdecentralizowaniu konsensusu przez Bitcoin, został opracowany szereg alternatywnych zastosowań, które dość szybko zaczęły się pojawiać.
⦁ Namecoin – utworzony w 2010 roku, najlepiej można opisać jako zdecentralizowane bazy danych rejestracji nazwy. W zdecentralizowanych protokołach, takich jak Tor, Bitcoin i BitMessage, musi występować jakiś sposób identyfikacji konta w taki sposób, aby inni ludzie mogli wchodzić w interakcję z nimi, ale we wszystkich istniejących rozwiązaniach, jedynym dostępnym rodzajem identyfikatora są pseudolosowe hashe jak 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. Najlepiej by było, aby móc mieć konto o nazwie typu „george”. Jednak problemem jest to, że jeśli jedna osoba może utworzyć konto o nazwie „george”, to ktoś inny może korzystać z tego samego procesu, aby zarejestrować „george” dla siebie, jak również i podszywać się pod nim. Jedynym rozwiązaniem jest najpierw użycie pliku paradygmatu, gdzie pierwszy rejestrator się zarejestruje, a drugi już nie – problem ten doskonale pasuje do protokołu konsensusu Bitcoin. Namecoin jest najstarszym i najbardziej udanym wdrożeniem systemu rejestracji nazw przy użyciu takiego pomysłu.
⦁ Kolorowe monety – celem kolorowych monet jest to, aby służyć jako protokół oraz umożliwić użytkownikom tworzenie własnych walut cyfrowych – lub też w istotnym trywialnym przypadku tworzyć waluty z jednej jednostki, oraz żetony cyfrowe dla łańcucha blokowego Bitcoin. W protokole kolorowych monet, jedna „wydaje” nową walutę przez publiczne przypisanie koloru do konkretnego UTXO Bitcoin, zaś protokół rekurencyjnie określa kolor innego UTXO, aby był taki sam jak kolor w wejściach, zaś transakcja tworzy je (niektóre szczególne zasady obowiązują w przypadku wejść w mieszanym kolorze). Pozwala to użytkownikom na utrzymanie swoich portfeli zawierających tylko UTXO o określonym kolorze i wysyłać je naokoło jak zwykłe bit-monety, wycofując je przez łańcuch blokowy, aby określić kolor dowolnego UTXO który otrzymują.
⦁ Metacoins – ideą stojącą za metacoin jest posiadanie protokołu, który egzystować by mógł na szczycie Bitcoin, wykorzystując transakcje Bitcoin do przechowywania transakcji metacoin, lecz mających inną funkcję zmiany stanu, STOSOWAĆ’. Ponieważ protokół metacoin nie może zapobiec pojawianiu się nieprawidłowych transakcji metacoin w łańcuchu blokowym Bitcoin, reguła głosi, że jeśli STOSOWAĆ'(S,TX) zwraca błąd, protokół zmienia się domyślnie na STOSOWAĆ'(S,TX) = S. Zapewnia to łatwy mechanizm do tworzenia dowolnego protokołu krypto walutowego, z potencjalnie zaawansowanymi funkcjami, które nie mogą być realizowane wewnątrz samego Bitcoin, nawet przy bardzo niskich kosztach rozwojowych, ponieważ zawiłości powstające w górnictwie i sieci są już obsługiwane przez protokół Bitcoin. Metacoins zostały wykorzystane do realizacji niektórych klas kontraktów finansowych, rejestracji nazw i zdecentralizowanej wymiany.
A zatem, na ogół są dwa podejścia w kierunku budowy protokołu konsensusowego: budowa niezależnej sieci i budowa protokołu przy wierzchołku Bitcoin. Dawne podejście do tego zagadnienia, choć racjonalnie sukcesywne w przypadku aplikacji takich jak Namecoin, jest trudne do zrealizowania; każda indywidualna realizacja wymaga załadowania niezależnego łańcucha blokowego, a także utworzenia i przetestowania wszystkich niezbędnych stanów przejściowych i sieciowych kodu. Dodatkowo jesteśmy w stanie przewidzieć to, że zestaw aplikacji dla zdecentralizowanych technologii konsensusu przyczyni się do dystrybucji prawa energetycznego, gdzie zdecydowana większość aplikacji będzie zbyt mała, aby uzasadnić swoje łańcuchy blokowe i zauważamy tutaj też, że istnieją tu duże klasy zdecentralizowanych aplikacji, zwłaszcza zdecentralizowanych autonomicznych organizacji, które muszą współdziałać ze sobą.
Wgląd w Bitcoin, z drugiej strony ma pewną wadę, mianowicie, że nie odziedzicza uproszczonych funkcji weryfikacji płatności dla tego systemu. SPV pracuje dla Bitcoin, ponieważ może używać głębi łańcuchów blokowych jako serwera proxy dla uzyskania ważności; w pewnym momencie, gdy protoplaści transakcji postanawiają pójść wystarczająco daleko wstecz, to jednak na pewno można powiedzieć, że stali się oni zasadnie częścią tego stanu. Bazujące na łańcuchach blokowych meta-protokoły, z drugiej jednak strony nie mogą zmusić łańcuchów blokowych do nie obejmowania transakcji, które nie są ważne w kontekście ich własnych protokołów. Stąd też, w pełni bezpieczna realizacja meta-protokołów SPV musiałaby poddać dogłębnemu przeskanowaniu całą drogę do początku łańcucha blokowego Bitcoin w celu ustalenia, czy niektóre transakcje są nadal ważne. Obecnie wszystkie „lekkie” implementacje meta protokołów opartych o Bitcoin polegają na zaufanym serwerze w celu dostarczenia danych, prawdopodobnie wysoce suboptymalnych wyników zwłaszcza wtedy, gdy jednym z głównych celów krypto walutowania jest wyeliminowanie potrzeby zaufania.


Pisanie Skryptów
Nawet bez żadnych rozszerzeń, protokół Bitcoin dostarcza słabą wersję koncepcji „inteligentnych umów”. UTXO w Bitcoin może być w posiadaniu nie tylko za pomocą klucza publicznego, ale także poprzez bardziej skomplikowany skrypt wyrażony w prostym języku programowania opartym na tzw. stosie. W tym paradygmacie nakłady transakcji, w których UTXO muszą dostarczać danych, muszą jednocześnie spełniać ten skrypt. Rzeczywiście, nawet podstawowy klucz publiczny mechanizmu własności jest realizowany za pomocą skryptu: skrypt wykonuje eliptyczny podpis krzywej jako wejście, weryfikuje ją przed transakcją oraz adres, który posiada UTXO i zwraca 1, jeśli weryfikacja jest skuteczna i 0 w przeciwnym przypadku. Inne, bardziej skomplikowane skrypty istnieją dla różnych dodatkowych przypadków użycia. Na przykład, można utworzyć skrypt, który wymaga podpisów dwóch z trzech dostępnych kluczy prywatnych, aby potwierdzić („multi podpis”) ustawień przydatnych dla kont firmowych, bezpiecznych rachunków oszczędnościowych oraz niektórych sytuacji depozytowych. Skrypty mogą być również wykorzystywane do płacenia premii dla rozwiązań problemów obliczeniowych, jednakże można zbudować także taki skrypt, który mówi coś w stylu „ten Bitcoin UTXO należy do ciebie, jeśli potrafisz dostarczyć SPV jako dowód wysłania transakcji Dogecoin, dotyczącej denominacji, do mnie”, zasadniczo umożliwiając zdecentralizowaną wymianę trans-granicznego krypto walutowania.
Jednakże, język skryptowy wdrożony w Bitcoin ma kilka ważnych ograniczeń:
⦁ Brak kompletności Turinga – to znaczy, gdy istnieje duży podzbiór obliczeń, który obsługuje język skryptowy Bitcoin, to nie obsługuje on jednak wszystkiego. Główną kategorią, której tutaj brakuje, są pętle. Chodzi o to, aby uniknąć powstawania nieskończonej pętli podczas weryfikacji transakcji; teoretycznie jest to możliwą do pokonania przeszkodą dla programistów skryptów, ponieważ każda pętla może być symulowana przez zwykłe powtarzanie kodu wyjściowego wielokrotnie z instrukcji, lecz nie prowadzi to do skryptów, które są dosyć bardzo czasowo nieefektywne. Na przykład, wprowadzenie algorytmu alternatywnej krzywej eliptycznej podpisu będzie prawdopodobnie wymagać 256 powtarzających się mnożeń rund, wszystkich zawartych indywidualnie w kodzie.
⦁ Ślepa wartość – nie ma sposobu, aby skrypt UTXO zapewnił precyzyjną kontrolę nad ilością, które mogą zostać wycofane. Na przykład, jeden potężny przypadek zastosowania umowy Oracle mógłby być zabezpieczeniem takiej umowy, gdzie A i B umieszcza wartość $ 1000 w BTC i po 30 dniach skrypt wysyła wartość $ 1000 w BTC do A i resztę do B. To wymagałoby od Oracle, aby określić wartość 1 BTC w dolarach, ale nawet wtedy jest to ogromna poprawa pod względem zaufania i wymogów infrastruktury w stosunku do pełni scentralizowanych rozwiązań, które są dostępne już teraz. Jednak ze względu na to, że UTXO to wszystko albo nic, jedynym sposobem osiągnięcia tego celu jest dość nieefektywna próba posiadania wielu UTXO o różnych nominałach (np. jednego UTXO 2k dla każdego k do 30) oraz dokonanie wyboru O i podjęcie decyzji, które UTXO wysłać do A, a które do B.
⦁ Brak stanu – UTXO może albo zostać wydane, albo niewykorzystane; nie ma możliwości dla zamówień wieloetapowych lub skryptów, które prowadzą do jakiegokolwiek innego stanu wewnętrznego poza tym. To sprawia, że ciężko jest wykonać wieloetapowe kontrakty, oferty zdecentralizowanej wymiany walutowej, bądź też dwustopniowe kryptograficzne protokoły zobowiązania (niezbędne do uzyskania bezpiecznych premii obliczeniowych). Oznacza to również, że UTXO mogą być wykorzystywane jedynie do tworzenia prostych, jednorazowych kontraktów i niezbyt bardziej złożonych „pełno-stanowych” umów, takich jak organizacje zdecentralizowane, co sprawia, że meta-protokoły są trudne do wdrożenia. Stan binarny w połączeniu ze ślepą wartością oznacza, że każda kolejna istotna aplikacja nie może wpłynąć na odwołanie limitów wypłat.
⦁ Ślepa wartość łańcucha blokowego – UTXO są ślepe na pewne rodzaje danych łańcucha blokowego, takie jak nonce i poprzednie hashe bloku. To poważnie ogranicza zastosowanie tych danych w hazardzie i kilku innych kategoriach, poprzez pozbawienie języka skryptowego potencjalnie cennego źródła losowości.
Tak więc widzimy trzy podejścia do budowania zaawansowanych aplikacji na szczycie krypto walutowania: budowa nowego łańcucha blokowego używając skryptowania na samym wierzchołku Bitcoin i budowanie meta-protokołów także na wierzchołku Bitcoin. Budowa nowego łańcucha blokowego pozwala na nieograniczoną swobodę w budowaniu zestawu funkcji, jednakże kosztem czasu rozwoju, ładowania początkowego, wysiłku i bezpieczeństwa. Korzystanie ze skryptowania jest łatwe do wdrożenia i standaryzacji, lecz jest bardzo ograniczone w swoich możliwościach, a meta-protokoły, choć proste, są ograniczone z powodu błędów w skalowalności. Z zastosowaniem Ethereum zamierzamy zbudować swoistą alternatywną ramę, która zapewni jeszcze większe zyski w łatwości rozwoju, jak również także silniejsze właściwości przypisane dla klientów drobniejszych, jednocześnie pozwalając aplikacjom na dzielenie się otoczeniem ekonomicznym i zabezpieczeniem łańcucha blokowego.

Może Ci się również spodoba

1 Odpowiedź

  1. Rafal napisał(a):

    Widząc temat mialem nadzieje na ogolny opis tej kryptowaluty. A tutaj rtykul gigant jezeli chodzi o ilosc wiedzy.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *