W tym artykule przyjrzymy się, czym są smart kontrakty, jakie są ich rodzaje, zapoznamy się z różnymi platformami smart kontraktów, ich cechami, a także omówimy, jak są one zbudowane i jakie korzyści mogą przynieść. Materiał ten będzie niezwykle przydatny dla czytelników, którzy nie są jeszcze dobrze zaznajomieni z tematem smart kontraktów, ale chcą zbliżyć się do jego zrozumienia.
Kontrakt tradycyjny vs. smart kontrakt
Zanim zgłębimy szczegóły, przyjrzyjmy się na przykładzie różnicom między tradycyjnym kontraktem, który jest spisany na papierze, a smart kontraktem, który jest przedstawiony w formie cyfrowej.
Jak to działało przed pojawieniem się smart kontraktów? Wyobraźcie sobie grupę osób, które chcą ustalić pewne zasady i warunki dystrybucji wartości, a także mieć mechanizm gwarantujący wykonanie tej dystrybucji zgodnie z ustalonymi zasadami i warunkami. Wówczas zbierali się razem, sporządzali dokument, na którym zapisywali swoje dane identyfikacyjne, warunki, wartości do rozdysponowania, wpisywali datę i podpisywali się. Ten kontrakt był również potwierdzany przez zaufaną stronę, na przykład notariusza. Następnie ci ludzie rozchodzili się w różne strony z papierową kopią takiego kontraktu i zaczynali podejmować działania, które mogły nie odpowiadać samemu kontraktowi, to znaczy robili jedno, a na papierze było potwierdzone, że powinni robić coś zupełnie innego. I jak wyjść z tej sytuacji? Faktycznie, ktoś z uczestników grupy musiałby wziąć tę papierową wersję, wziąć jakieś dowody, udać się do sądu i starać się o zgodność między kontraktem a faktycznymi działaniami. Dość często osiągnięcie sprawiedliwego wykonania tego kontraktu bywa trudne, co prowadzi do nieprzyjemnych konsekwencji.
Co można powiedzieć o smart kontraktach? Łączą one w sobie zarówno możliwość spisania warunków kontraktu, jak i mechanizm ich ścisłego wykonania. Jeśli warunki zostały określone i odpowiednia transakcja lub żądanie zostały podpisane, to po przyjęciu tej transakcji lub żądania już nie można zmienić warunków ani wpłynąć na ich wykonanie.
Istnieje jeden walidator lub cała sieć, a także baza danych, która przechowuje wszystkie inteligentne kontrakty, które trafiają do realizacji w ścisłej kolejności chronologicznej. Ważne jest również, aby ta baza danych zawierała wszystkie warunki wyzwalające dla realizacji inteligentnego kontraktu. Ponadto musi ona brać pod uwagę wartość, której rozdział opisano w kontrakcie. Jeśli dotyczy to jakiejś waluty cyfrowej, to ta baza danych musi to uwzględniać.
Innymi słowy, walidatory inteligentnych kontraktów muszą mieć dostęp do wszystkich danych, którymi zarządza inteligentny kontrakt. Na przykład, jedna baza danych powinna być używana do jednoczesnego monitorowania walut cyfrowych, sald użytkowników, transakcji użytkowników i znaczników czasowych. Wówczas w inteligentnym kontrakcie warunkiem może być saldo użytkownika w określonej walucie, osiągnięcie pewnego momentu w czasie lub fakt dokonania niektórej transakcji, ale nie więcej.
Definicja inteligentnego kontraktu
Termin ten został wymyślony przez badacza Nicka Szabo i po raz pierwszy zastosowany w 1994 roku, a udokumentowany w 1997 roku w artykule opisującym samą ideę inteligentnych kontraktów.
Inteligentne kontrakty zakładają, że odbywa się pewna automatyzacja rozdzielania wartości, która może zależeć tylko od tych warunków, które zostały wcześniej ustalone. W najprostszym wariancie wygląda to jak kontrakt z ściśle określonymi warunkami, podpisany przez określone strony.
Inteligentne kontrakty mają na celu minimalizację zaufania do stron trzecich. Czasami całkowicie wyklucza się centrum decyzyjne, od którego wszystko zależy. Ponadto, audyt takich kontraktów jest prostszy. Wynika to z niektórych cech projektowania takiego systemu, ale najczęściej przez inteligentny kontrakt rozumiemy zdecentralizowane środowisko i obecność funkcji, które umożliwiają każdemu chętnemu analizę bazy danych i przeprowadzenie pełnego audytu realizacji kontraktów. W ten sposób zapewnia się ochronę przed wprowadzaniem zmian w danych wstecz, które mogłyby skutkować zmianami w realizacji samego kontraktu. Cyfryzacja większości procesów przy tworzeniu i uruchamianiu inteligentnego kontraktu często upraszcza technologię i koszty ich realizacji.
Prosty przykład — usługa Escrow
Przyjrzyjmy się bardzo prostemu przykładzie. Pomoże on zrozumieć funkcjonalności smart kontraktów oraz lepiej orientować się, w jakich sytuacjach warto je stosować.
Można to również zrealizować z wykorzystaniem Bitcoina, choć obecnie nie można tego nazwać w pełni funkcjonalną platformą do smart kontraktów. Mamy więc kupującego i sklep internetowy. Kupujący chce kupić monitor w tym sklepie. W najprostszym przypadku kupujący dokonuje płatności, a sklep internetowy ją przyjmuje, potwierdza, po czym wysyła towar. Jednak w tej sytuacji istnieje potrzeba dużego zaufania — kupujący musi zaufać sklepowi internetowemu na pełną kwotę monitora. Ponieważ sklep może mieć niską reputację w oczach kupującego, istnieje ryzyko, że z jakiegoś powodu sklep odmówi obsługi po przyjęciu płatności i nie wyśle towaru do kupującego. Dlatego kupujący zadaje sobie pytanie (odpowiednio, i sklep internetowy również), co można w tym przypadku zastosować, aby zminimalizować te ryzyka i uczynić takie transakcje bardziej niezawodnymi.
W przypadku Bitcoina można umożliwić kupującemu i sprzedawcy niezależny wybór mediatora. Jest wielu ludzi, którzy zajmują się rozwiązywaniem sporów. Nasi uczestnicy mogą wybrać z ogólnej listy mediatorów tego, któremu jednocześnie będą ufać. Razem tworzą adres multisignature 2 z 3, gdzie znajdują się trzy klucze i potrzebne są dwa podpisy dowolnymi dwoma kluczami, aby wydać monety z tego adresu. Jeden klucz będzie należał do kupującego, drugi — do sklepu internetowego, a trzeci — do mediatora. Na taki adres multisignature kupujący prześle kwotę potrzebną do zapłaty za monitor. Teraz, gdy sprzedawca widzi, że pieniądze są zablokowane na adresie multisignature, który od niego zależy, może śmiało wysyłać monitor pocztą.
Następnie kupujący odbiera paczkę, sprawdza towar i podejmuje decyzję o finalnym zakupie. Może w pełni zgodzić się z świadczoną obsługą i podpisać transakcję swoim kluczem, przekazując monety z adresu multisignature sprzedawcy, lub może być czymś rozczarowany. W takim wypadku kontaktuje się z mediatorem, aby sporządzić alternatywną transakcję, która w inny sposób rozdzieli te monety.
Załóżmy, że monitor przyjechał lekko porysowany i w zestawie nie było kabla do podłączenia do komputera, mimo że na stronie sklepu internetowego było napisane, że kabel powinien być dołączony. Kupujący zbiera dowody, potrzebne do wykazania mediatorowi, że został oszukany w tej sytuacji: wykonuje zrzuty ekranu strony, robi zdjęcie paragonu z poczty, fotografuje rysy na monitorze i pokazuje, że plomba została zerwana, a kabel wyjęty. Sklep internetowy w międzyczasie zbiera swoje dowody i przekazuje je mediatorowi.
Mediator jest zainteresowany zaspokojeniem zarówno oburzenia kupującego, jak i interesów sklepu internetowego (wkrótce wyjaśni się, dlaczego). Sporządza taką transakcję, w której monety z adresu multisignature będą wydawane w pewnej proporcji między kupującym, sklepem internetowym i mediatorem, ponieważ bierze sobie część jako wynagrodzenie za swoją pracę. Załóżmy, że 90% całej kwoty trafi do sprzedawcy, 5% do mediatora i 5% jako rekompensata dla kupującego. Tę transakcję mediator podpisuje swoim kluczem, ale nie może być ona jeszcze zastosowana, ponieważ potrzebne są dwa podpisy, a jest tylko jeden. Taką transakcję wysyła zarówno do kupującego, jak i sprzedawcy. Jeśli przynajmniej jedna z tych osób zgodzi się na taki sposób redystrybucji monet, transakcja zostanie dopisania i rozpropagowana w sieci. Wystarczy, że jeden z uczestników transakcji zgodzi się na propozycję mediatora.
Ważne jest, aby na początku wybrać mediatora, któremu obaj uczestnicy będą ufać. W takim przypadku będzie on działał niezależnie od interesów jednej lub drugiej strony i obiektywnie oceni sytuację. Jeśli mediator nie przedstawi takiej opcji podziału monet, która zadowoli przynajmniej jednego uczestnika, to po uzgodnieniu razem, zarówno kupujący, jak i sklep internetowy mogą przesłać monety na nowy adres multisignature, stawiając swoje dwa podpisy. Nowy adres multisignature zostanie utworzony z innym mediatorem, który być może będzie bardziej kompetentny w tej kwestii i zaproponuje lepszą opcję.
Przykład z akademikiem i lodówką
Przyjrzyjmy się bardziej złożonemu przykładowi, który wyraźniej ilustruje możliwości smart kontraktu.
Załóżmy, że jest trzech chłopaków, którzy niedawno zamieszkali w jednym pokoju w akademiku. Wszyscy trzej są zainteresowani zakupem lodówki do swojego pokoju, z której będą wspólnie korzystać. Jeden z nich zgłosił się do zebrania potrzebnej kwoty na zakup lodówki i prowadzenia negocjacji z sprzedawcą. Jednak niedawno się poznali i nie ma między nimi dostatecznego zaufania. Oczywiste jest, że dwie z nich ryzykują, oddając pieniądze trzeciemu. Ponadto muszą osiągnąć zgodę w wyborze sprzedawcy.
Mogą skorzystać z serwisu escrow, czyli wybrać mediatora, który nadzoruje wykonanie transakcji i wyjaśnia sporne kwestie, jeśli takie się pojawią. Wtedy, po uzgodnieniu, tworzą smart kontrakt i zapisują w nim określone warunki.
Pierwszym warunkiem jest to, że przed upływem określonego czasu, na przykład w ciągu jednego tygodnia, na odpowiednie konto smart kontraktu muszą wpłynąć trzy płatności z określonych adresów na określoną kwotę. Jeśli to nie nastąpi, smart kontrakt przestaje działać i zwraca monety wszystkim uczestnikom. Jeśli warunek jest spełniony, ustalane są wartości identyfikatorów sprzedawcy i mediatora, a także sprawdzane jest, czy wszyscy uczestnicy zgadzają się na wybór sprzedawcy i mediatora. Gdy wszystkie warunki są spełnione, środki są przekazywane na wskazane adresy. Takie podejście może zabezpieczyć uczestników przed oszustwami ze strony jakiejkolwiek ze stron i całkowicie eliminuje potrzebę zaufania.
Na tym przykładzie widzimy samą zasadę, że możliwość krokowego określania parametrów wykonania każdego warunku pozwala na tworzenie systemów o dowolnej złożoności i głębokości zagnieżdżonych poziomów. Ponadto najpierw w smart kontrakcie można określić pierwszy warunek, a dopiero po jego spełnieniu ustalać parametry dla następnego warunku. Innymi słowy, formalnie warunek jest zapisany, a parametry dla niego mogą być ustalane już w trakcie jego działania.
Klasyfikacja smart kontraktów
Dla klasyfikacji można określać różne grupy kryteriów. Jednak na obecnym etapie rozwoju technologii aktualne są cztery z nich.
Smart kontrakty można różnicować według środowiska wykonania, które może być centralizowane lub zdecentralizowane. W przypadku decentralizacji mamy znacznie większą niezależność i odporność na awarie podczas wykonywania smart kontraktów.
Można je również różnicować według procesu określania i wykonywania warunków: mogą być dowolnie programowalne, ograniczone lub predefiniowane, tj. ściśle typowane. Kiedy na platformie smart kontraktów istnieją tylko 4 określone smart kontrakty, można do nich określać parametry w sposób dowolny. W związku z tym ich ustalanie jest znacznie prostsze: wybieramy kontrakt z listy i przekazujemy parametry.
Istnieją zautomatyzowane inteligentne kontrakty, które samodzielnie się uruchamiają przy spełnieniu określonych warunków, oraz takie, w których warunki są ustalone, ale platforma nie sprawdza ich wykonywania automatycznie, wymaga to oddzielnej inicjacji.
Ponadto inteligentne kontrakty różnią się poziomem prywatności. Mogą być całkowicie otwarte, częściowo lub całkowicie poufne. Oznacza to, że osoby trzecie nie widzą warunków inteligentnych kontraktów. Jednak temat prywatności jest bardzo obszerny i lepiej go rozważyć osobno od bieżącego artykułu.
Poniżej omówimy bardziej szczegółowo pierwsze trzy kryteria, aby zwiększyć klarowność w zrozumieniu bieżącego tematu.
Inteligentne kontrakty według środowiska wykonawczego
W zależności od środowiska wykonawczego wyróżniamy centralizowane i zdecentralizowane platformy inteligentnych kontraktów. W przypadku centralizowanych kontraktów cyfrowych używany jest jeden serwis, w którym istnieje tylko jeden walidator, a także może istnieć usługa kopii zapasowej i odbudowy, która jest zarządzana centralnie. Istnieje jedna baza danych, która przechowuje wszystkie niezbędne informacje do ustalania warunków inteligentnego kontraktu oraz do rozdzielania wartości, która jest uwzględniana w tej bazie danych. Taki centralizowany serwis ma klienta, który za pomocą określonych zapytań ustala warunki i korzysta z takich kontraktów. Z powodu centralizacji platformy mechanizmy autoryzacji mogą być mniej niezawodne niż w przypadku kryptowalut.
Jako przykład można wziąć dostawców usług telefonii komórkowej (różnych operatorów komórkowych). Załóżmy, że dany operator centralnie prowadzi rachunek danych na swoich serwerach, które mogą być przesyłane w różnych formatach, na przykład: w postaci połączeń głosowych, przesyłu SMS, danych mobilnego internetu oraz według różnych standardów, a także prowadzi rachunek środków na kontach użytkowników. W związku z tym dostawca usług telefonii komórkowej może tworzyć kontrakty dotyczące rozliczania usług świadczonych i ich płatności z różnymi warunkami. W takim przypadku łatwo ustalić warunki, takie jak „wyślij SMS z takim kodem na taki numer i otrzymaj takie warunki rozdziału danych”.
Można podać jeszcze jeden przykład: tradycyjne banki z rozszerzoną funkcjonalnością bankowości internetowej oraz bardzo proste kontrakty, takie jak regularne płatności, automatyczna konwersja przychodzących płatności, automatyczne odliczanie procentów na wskazany rachunek itp.
Jeśli mówimy o inteligentnych kontraktach w zdecentralizowanym środowisku wykonawczym, wtedy mamy grupę walidatorów. W idealnym przypadku walidatorem może być właściwie każdy. Dzięki protokołowi synchronizacji bazy danych i osiągnięciu konsensusu mamy wspólną bazę danych, która będzie teraz przechowywać wszystkie transakcje z ściśle opisanymi kontraktami, a nie jakieś warunkowe zapytania, których formaty często się zmieniają, a otwartej specyfikacji brak. Tutaj transakcje będą zawierały instrukcje dotyczące wykonania kontraktu zgodnie z rygorystyczną specyfikacją. Ta specyfikacja jest otwarta, więc sami użytkownicy platformy mogą przeprowadzać audyty i walidować inteligentne kontrakty. Widzimy tutaj, że platformy zdecentralizowane przewyższają centralizowane pod względem niezależności i odporności na awarie, ale ich projektowanie i utrzymanie jest znacznie bardziej skomplikowane.
Inteligentne kontrakty według sposobu określania i wykonywania warunków
Teraz omówimy bardziej szczegółowo, jak inteligentne kontrakty mogą różnić się pod względem sposobu określania i wykonywania warunków. Zwrócimy uwagę na inteligentne kontrakty, które są programowane dowolnie i są pełne według Turinga. Pełny według Turinga inteligentny kontrakt pozwala na określanie praktycznie dowolnych algorytmów jako warunków wykonania kontraktu: zapisanie pętli, funkcji obliczających prawdopodobieństwa itd. — aż po własne algorytmy podpisu elektronicznego. W tym przypadku chodzi o naprawdę dowolne pisanie logiki.
Wyróżnia się także dowolne inteligentne kontrakty, ale niepełne według Turinga. Można tu zaliczyć Bitcoina i Litecoina z ich skryptem. Chodzi o to, że można korzystać w dowolnej kolejności tylko z określonych operacji, ale już nie można pisać pętli ani własnych algorytmów.
Ponadto istnieją platformy smart kontraktów, które realizują wcześniejsza zdefiniowane smart kontrakty. Należą do nich Bitshares i Steemit. Bitshares ma szereg smart kontraktów do handlu, zarządzania kontami, zarządzania samą platformą i jej parametrami. Steemit to podobna platforma, ale jest już ukierunkowana nie na emisję tokenów i handel, jak Bitshares, lecz na blogowanie, tzn. przechowuje i przetwarza treści w sposób zdecentralizowany.
Do pełnych kontraktów Turinga można zaliczyć platformę Ethereum i RootStock, która wciąż jest w fazie rozwoju. Dlatego poniżej nieco dokładniej przyjrzymy się platformie smart kontraktów Ethereum.
Smart kontrakty według sposobu inicjacji
Smart kontrakty można również podzielić co najmniej na dwie grupy według sposobu inicjacji: automatyczne i ręczne (nieautomatyczne). Charakterystyczne dla automatycznych jest to, że przy wszystkich znanych parametrach i warunkach, smart kontrakt wykonuje się całkowicie automatycznie, to znaczy nie wymaga wysyłania dodatkowych transakcji ani ponoszenia dodatkowych opłat przy każdym kolejnym wykonaniu. Sama platforma ma wszystkie dane, aby obliczyć, jak zakończy się smart kontrakt. Logika nie jest dowolna, a wcześniej ustalona i wszystko to jest przewidywalne. Można zatem z wyprzedzeniem ocenić stopień trudności wykonania smart kontraktu, zastosować jakąś stałą opłatę za niego i wszystkie procesy jego realizacji przebiegają w sposób bardziej efektywny.
W przypadku smart kontraktów, które są programowane w sposób dowolny, wykonanie nie jest automatyczne. Aby zainicjować taki smart kontrakt, w zasadzie na każdym etapie trzeba tworzyć nową transakcję, która będzie wywoływać kolejny etap wykonania lub kolejną metodę smart kontraktu, opłacać odpowiednią prowizję i czekać na potwierdzenie transakcji. Wykonanie może zakończyć się sukcesem lub nie, ponieważ kod smart kontraktu jest dowolny i mogą wystąpić nieprzewidywalne sytuacje, takie jak nieskończona pętla, brak jakichś parametrów i argumentów, nieprzetworzone wyjątki itp.
Konta w Ethereum
Typy kont Ethereum
Zastanówmy się, jakie konta mogą istnieć na platformie Ethereum. Istnieją tylko dwa typy kont, a żadnych innych opcji nie ma. Pierwszy typ nazywa się konto użytkownika, a drugi — konto kontraktu. Przeanalizujmy, czym się różnią.
Konto użytkownika jest zarządzane wyłącznie przez osobisty klucz elektronicznego podpisu. Właściciel konta generuje swoją parę kluczy do elektronicznego podpisu zgodnie z algorytmem ECDSA (Elliptic Curve Digital Signature Algorithm). Stan tego konta mogą zmieniać tylko transakcje podpisane tym kluczem.
Konto smart kontraktu ma osobną logikę. Może być zarządzane tylko za pomocą uprzednio zdefiniowanego kodu programowania, który w pełni określa zachowanie smart kontraktu: jak będzie dysponować swoimi monetami w określonych okolicznościach, na czyją inicjatywę i przy jakich dodatkowych warunkach te monety będą dystrybuowane. Jeśli niektóre kwestie nie są przewidziane przez twórców w kodzie programowania, mogą wystąpić problemy. Na przykład smart kontrakt może osiągnąć pewien stan, w którym nie akceptuje inicjowania dalszej realizacji od żadnego z użytkowników. W takim przypadku monety faktycznie będą zablokowane, ponieważ smart kontrakt nie przewiduje wyjścia z tego stanu.
Jak tworzy się konta w Ethereum
W przypadku konta użytkownika, właściciel samodzielnie generuje parę kluczy zgodnie z ECDSA. Ważne jest, aby zauważyć, że Ethereum używa do elektronicznego podpisu dokładnie tego samego algorytmu i tej samej krzywej eliptycznej, co Bitcoin, jednak adres obliczany jest nieco inaczej. Tutaj nie stosuje się wyniku podwójnego haszowania, jak w Bitcoinie, lecz przewidziano jednokrotne haszowanie funkcją Keccak o długości 256 bitów. Od uzyskanego wyniku usuwa się młodsze bity, a konkretnie 160 najmłodszych bitów wartości wyjściowej funkcji haszującej. W rezultacie otrzymujemy adres w Ethereum. Faktycznie zajmuje on 20 bajtów.
Zauważmy, że identyfikator konta w Ethereum jest kodowany w hex bez zastosowania sumy kontrolnej, w przeciwieństwie do Bitcoina i wielu innych systemów, gdzie adres kodowany jest w systemie liczbowym o podstawie 58 z dodaną sumą kontrolną. Oznacza to, że należy ostrożnie pracować z identyfikatorami kont w Ethereum: nawet jeden błąd w identyfikatorze gwarantuje utratę monet.
Istnieje ważna cecha, którą należy zauważyć: konto użytkownika na poziomie wspólnej bazy danych jest tworzone w momencie, gdy przyjmuje pierwszy przychodzący płatność.
W odniesieniu do tworzenia konta smart kontraktu stosuje się zupełnie inne podejście. Najpierw ktoś z użytkowników pisze kod źródłowy smart kontraktu, a następnie kod ten jest przepuszczany przez specjalny kompilator dedykowany dla platformy Ethereum, otrzymując kod bajtowy dla własnej wirtualnej maszyny Ethereum. Otrzymany kod bajtowy jest umieszczany w specjalnym polu transakcji. Transakcja ta jest podpisywana w imieniu konta inicjatora. Następnie ta transakcja jest rozpowszechniana w sieci i umieszcza kod smart kontraktu. Opłata za przeprowadzenie transakcji i, odpowiednio, za wykonanie kontraktu jest pobierana z salda konta inicjatora.
Każdy smart kontrakt zawiera swój własny konstruktor (tego kontraktu). Może on być pusty lub może mieć zawartość. Po wykonaniu konstruktora tworzony jest identyfikator konta smart kontraktu, którego używając, można wysyłać monety, wywoływać określone metody smart kontraktu itd.
Struktura transakcji Ethereum
Aby było to zrozumiałe, przejdźmy do omówienia struktury transakcji Ethereum oraz przykładu kodu smart kontraktu.
Transakcja Ethereum składa się z kilku pól. Pierwsze z nich, nonce, to pewien numer porządkowy transakcji względem samego konta, które je rozpowszechnia i jest jego autorem. Jest to potrzebne do odróżnienia duplikatów transakcji, aby wykluczyć sytuację, w której ta sama transakcja jest akceptowana dwukrotnie. Dzięki zastosowaniu identyfikatora każda transakcja ma unikalną wartość haszową.
Następnie pojawia się takie pole, jak cena gazuTutaj podawana jest cena, po której podstawowa waluta Ethereum jest przeliczana na gas, którym opłacana jest realizacja smart kontraktu oraz przydział zasobów wirtualnej maszyny. Co to oznacza?
W Bitcoinie opłaty są płacone bezpośrednio podstawową walutą — samym bitcoinem. Jest to możliwe dzięki prostemu mechanizmowi ich obliczania: płacimy ściśle za objętość danych, która znajduje się w transakcji. W Ethereum sytuacja jest bardziej skomplikowana, ponieważ trudno jest opierać się na objętości danych transakcji. Tutaj transakcja może jeszcze zawierać kod programu, który będzie uruchamiany na wirtualnej maszynie, a każda operacja wirtualnej maszyny może mieć różny stopień złożoności. Istnieją także operacje, które przydzielają pamięć dla zmiennych. Będą one miały swoją złożoność, od której będzie zależała opłata za każdą operację.
Koszt każdej operacji w ekwiwalencie gas będzie stały. Wprowadzany jest on specjalnie po to, aby określić stały koszt każdej operacji. W zależności od obciążenia sieci zmienia się cena gas, czyli współczynnik, według którego podstawowa waluta jest przeliczana na tę pomocniczą jednostkę służącą do opłaty.
Jest jeszcze jedna cecha transakcji w Ethereum: bajt kod, który zawiera do wykonania na wirtualnej maszynie, będzie wykonywany, dopóki nie zakończy się jakimś wynikiem (sukces-niesukces) lub dopóki nie wyczerpie się określona kwota monet przydzielona na opłatę. Aby uniknąć sytuacji, w której z konta nadawcy w przypadku jakiegoś błędu wydano wszystkie monety na opłatę (na przykład, gdy w wirtualnej maszynie uruchomił się jakiś nieskończony cykl), istnieje następujące pole — start gas (często nazywane limitem gas) — określa maksymalną kwotę monet, którą nadawca jest gotów wydać na realizację danej transakcji.
Następne pole nazywa się destination address. Wpisuje się tutaj adres odbiorcy monet lub adres konkretnego smart kontraktu, metody którego będą wywoływane. Po nim następuje pole value, do którego wpisuje się kwotę monet, które są wysyłane na destination address.
Następnie znajduje się interesujące pole o nazwie data, która obejmuje całą strukturę. To nie jest osobne pole, lecz cała struktura, w której definiowany jest kod dla maszyny wirtualnej. Można tu umieszczać dowolne dane — do tego istnieją osobne zasady.
A ostatnie pole nazywa się signature. Zawiera jednocześnie elektroniczny podpis autora tej transakcji oraz klucz publiczny, którym będzie weryfikowany ten podpis. Z klucza publicznego można uzyskać identyfikator konta nadawcy tej transakcji, co oznacza unikalną identyfikację konta nadawcy w samej systemie. Jeśli chodzi o strukturę transakcji, to ustaliliśmy najważniejsze.
Przykład kodu smart kontraktu w Solidity
Przyjrzyjmy się teraz bliżej najprostszemu smart kontraktowi na przykładzie.
contract Bank {
address owner;
mapping(address => uint) balances;
function Bank() {
owner = msg.sender;
}
function deposit() public payable {
balances[msg.sender] += msg.value;
}
function withdraw(uint amount) public {
if (balances[msg.sender] >= amount) {
balances[msg.sender] -= amount;
msg.sender.transfer(amount);
}
}
function getMyBalance() public view returns(uint) {
return balances[msg.sender];
}
function kill() public {
if (msg.sender == owner)
selfdestruct(owner);
}
}Powyżej przedstawiono uproszczony kod źródłowy, który może przechowywać monety użytkowników i zwracać je na żądanie.
Zatem mamy smart kontrakt Bank, który wykonuje następujące funkcje: gromadzi monety na swoim saldzie, co oznacza, że po potwierdzeniu transakcji i umieszczeniu takiego smart kontraktu tworzony jest nowe konto, które może zawierać monety na swoim saldzie; zapamiętuje użytkowników i podział monet między nimi; ma kilka metod zarządzania saldami, czyli istnieje możliwość doładowania, wypłaty i sprawdzenia salda użytkownika.
Przejdźmy przez każdą linię kodu źródłowego. W tym kontrakcie są pola stałe. Jedno z nich, o typie address, nazywa się owner. Tutaj kontrakt zapamiętuje adres użytkownika, który stworzył ten smart kontrakt. Następnie znajduje się struktura dynamiczna, która przechowuje powiązania między adresami użytkowników a stanami ich sald.
Następnie następuje metoda Bank — nazywa się tak samo jak kontrakt. Tak więc jest to jego konstruktor. Tutaj dokonuje się przypisanie zmiennej owner adresu osoby, która umieściła ten smart kontrakt w sieci. To jedyne, co dzieje się w tym konstruktorze. Zatem msg w tym przypadku to dokładnie te dane, które zostały przekazane maszynie wirtualnej wraz z transakcją zawierającą cały kod tego kontraktu. Tak więc msg.sender to autor tej transakcji, która publikowała ten kod. On będzie właścicielem smart kontraktu.
Metoda deposit pozwala na przesłanie określonej ilości monet na konto kontraktu w transakcji. W tym przypadku smart kontrakt, otrzymując te monety, pozostawia je na swoim saldzie, ale w strukturze balances zapisuje, kto dokładnie był nadawcą tych monet, aby wiedzieć, do kogo należą.
Następna metoda nazywa się withdraw i przyjmuje jeden parametr — ilość monet, którą ktoś chce wypłacić z tego banku. Tutaj sprawdzane jest, czy wystarczająca liczba monet jest dostępna na saldzie użytkownika wywołującego tę metodę, aby je wysłać. Jeśli jest ich wystarczająco, smart kontrakt zwraca to wywołującemu w tej samej ilości.
Kolejną metodą jest sprawdzenie bieżącego salda użytkownika. Osoba wywołująca tę metodę będzie używana do uzyskania tego salda w smart kontrakcie. Warto zauważyć, że modyfikator tej metody to view. Oznacza to, że sama metoda w żaden sposób nie zmienia zmiennych swojej klasy i faktycznie jest jedynie metodą do odczytu. Nie tworzona jest odrębna transakcja do wywołania tej metody, opłata nie jest pobierana, a wszystkie obliczenia wykonywane są lokalnie, po czym użytkownik otrzymuje wynik.
Metoda kill jest potrzebna do zniszczenia stanu smart kontraktu. Tutaj zapisano dodatkową weryfikację, czy osoba wywołująca tę metodę jest właścicielem tego kontraktu. Jeśli tak, kontrakt samorzutnie się niszczy, a funkcja niszczenia przyjmuje jeden parametr — identyfikator konta, na które kontrakt wyśle wszystkie monety pozostałe na swoim saldzie. W takim przypadku pozostałe monety automatycznie trafiają na adres właściciela kontraktu.
Jak działa pełny węzeł sieci Ethereum?
Przyjrzyjmy się schematycznie, jak odbywa się realizacja takich smart kontraktów na platformie Ethereum i jak działa pełny węzeł sieci.
Pełny węzeł sieci Ethereum musi mieć co najmniej cztery moduły.
Pierwszym, jak w przypadku każdego zdecentralizowanego protokołu, jest moduł P2P networking — moduł sieciowy do łączenia i współpracy z innymi węzłami, gdzie następuje wymiana bloków, transakcji, informacji o innych węzłach. To tradycyjny komponent dla wszystkich zdecentralizowanych kryptowalut.
Następnie mamy moduł przechowywania danych blockchain, przetwarzania, wyboru priorytetowej gałęzi, dodawania bloków, odczepiania bloków, sprawdzania tych bloków itd.
Trzeci moduł nazywa się EVM (Ethereum Virtual Machine) — to właśnie jest maszyna wirtualna, który przyjmuje kod bajtowy z transakcji Ethereum. Ten moduł przyjmuje aktualny stan określonego konta i dokonuje zmian w jego stanie na podstawie otrzymanego kodu bajtowego. Wersja wirtualnej maszyny na każdym z węzłów sieci musi być identyczna. Obliczenia odbywają się na każdym z węzłów Ethereum dokładnie w ten sam sposób, ale w asynchronicznym porządku: ktoś szybciej sprawdza i przyjmuje tę transakcję, to znaczy wykonuje cały zawarty w niej kod, a ktoś później. W związku z tym, przy tworzeniu transakcji, rozprzestrzenia się ona w sieci; węzły ją przyjmują i w momencie weryfikacji, tak jak w Bitcoinie wykonuje się Bitcoin Script, tutaj wykonuje się kod bajtowy wirtualnej maszyny.
Transakcja jest uważana za zweryfikowaną, jeśli cały zawarty w niej kod został wykonany, zostało wygenerowane nowe stanie określonego konta i przechowywane do momentu, gdy będzie wiadomo, czy ta transakcja została zastosowana, czy nie. Jeśli transakcja została zastosowana, wtedy to stanie jest uważane nie tylko za wykonane, ale i aktualne. Istnieje baza danych, która przechowuje stan każdego konta dla każdego węzła sieci. Dzięki temu, że wszystkie obliczenia odbywają się identycznie, a stan blockchainu jest taki sam, baza danych zawierająca stany wszystkich kont również będzie identyczna dla każdego węzła.
Mity i ograniczenia smart kontraktów
Jeśli chodzi o ograniczenia, które istnieją dla podobnych do Ethereum platform smart kontraktów, można wymienić następujące:
- wykonanie kodu;
- alokacja pamięci;
- dane blockchainu;
- wysyłanie płatności;
- tworzenie nowego kontraktu;
- wywoływanie innych kontraktów.
Przyjrzyjmy się ograniczeniom nakładanym na wirtualną maszynę i rozwiejmy pewne mity na temat inteligentnych kontraktów. Na wirtualnej maszynie, która może działać nie tylko w Ethereum, ale także na podobnych platformach, można przeprowadzać naprawdę dowolne operacje logiczne, co oznacza, że można napisać kod, który będzie wykonywany, oraz przydzielać dodatkową pamięć. Jednakże opłata jest naliczana osobno za każdą operację oraz każdą dodatkowo przydzieloną jednostkę pamięci.
Wirtualna maszyna może odczytywać dane z bazy danych blockchainu, aby użyć ich jako wyzwalaczy do wykonywania określonej logiki inteligentnych kontraktów. Wirtualna maszyna może tworzyć i wysyłać transakcje, może tworzyć nowe kontrakty oraz wywoływać metody innych inteligentnych kontraktów, które zostały już opublikowane w sieci: istnieją, są dostępne itp.
Najbardziej powszechny mit polega na tym, że inteligentne kontrakty Ethereum mogą wykorzystywać informacje z dowolnych zasobów internetowych w swoich warunkach. Prawda jest taka, że wirtualna maszyna nie może wysłać zapytania sieciowego do jakiegoś zewnętrznego źródła informacji w Internecie, co oznacza, że nie można napisać takiego inteligentnego kontraktu, który będzie rozdzielał wartość między użytkownikami w zależności od, powiedzmy, pogody na zewnątrz, albo tego, kto wygrał w jakimś turnieju, albo na podstawie jakiegoś innego zdarzenia w świecie zewnętrznym, ponieważ informacji o tych zdarzeniach po prostu nie ma w bazie danych samej platformy. W blockchainie nie ma nic na ten temat. Jeśli nie pojawi się tam, wirtualna maszyna nie może wykorzystać tych danych jako wyzwalaczy.
Wady Ethereum
Wymieńmy więc ich główne aspekty. Pierwszą wadą jest to, że projektowanie, rozwijanie i testowanie smart kontraktów w Ethereum wiąże się z pewnymi trudnościami (do pisania smart kontraktów w Ethereum wykorzystuje się język Solidity). Rzeczywiście, praktyka pokazuje, że bardzo duży odsetek wszystkich błędów pochodzi od czynnika ludzkiego. To jest aktualne również dla już napisanych smart kontraktów Ethereum, które mają średni lub wyższy poziom skomplikowania. Dla prostych smart kontraktów prawdopodobieństwo błędu jest niskie, ale w skomplikowanych smart kontraktach bardzo często występują błędy, które prowadzą do kradzieży środków, ich zablokowania lub nieprzewidzianego zniszczenia smart kontraktów itd. Już wiele takich przypadków zostało odnotowanych.
Drugą wadą jest to, że sama maszyna wirtualna nie jest doskonała, ponieważ również została napisana przez ludzi. Może wykonywać arbitralne polecenia, co rodzi pewne zagrożenia: można w określony sposób skonfigurować szereg poleceń, które prowadzą do nieprzewidzianych skutków. To bardzo skomplikowana dziedzina, ale istnieje już kilka badań, które pokazują, że te luki istnieją w obecnej wersji sieci Ethereum i mogą prowadzić do awarii wielu smart kontraktów.
Innym dużym wyzwaniem, które można uznać za wadę, jest to, że istnieje praktyczny lub techniczny sposób na to, że, jeśli skompilować bajt kod kontraktu, który będzie uruchamiany na maszynie wirtualnej, można zdefiniować określony porządek operacji. W rezultacie te operacje mocno obciążą maszynę wirtualną i znacznie spowolnią jej działanie w porównaniu do prowizji, która została zapłacona za wykonanie tych operacji.
W przeszłości istniał już taki okres rozwoju Ethereum, kiedy wielu ludzi, którzy szczegółowo rozumieli działanie wirtualnej maszyny, odnajdowało różne luki. W rzeczywistości transakcje miały bardzo niską opłatę, ale jednocześnie znacznie spowalniały działanie całej sieci. Problemy te są bardzo trudne do rozwiązania, ponieważ należy je, po pierwsze, zdeterminować, po drugie, skorygować koszt wykonywania tych operacji, a po trzecie, przeprowadzić hard fork, co oznacza aktualizację wszystkich węzłów sieci do nowej wersji oprogramowania, a następnie jednoczesną aktywację tych zmian.
Jeśli chodzi o Ethereum, przeprowadzono wiele badań, zdobyto ogromne doświadczenie praktyczne: zarówno pozytywne, jak i negatywne, ale wciąż pozostają trudności i luki, które będą wymagały jeszcze jakiegoś sposobu na walkę.
Tak więc, część tematyczna artykułu dobiegła końca, przejdźmy do pytań, które pojawiają się dość często.
Najczęściej zadawane pytania
— Jeśli wszystkie strony działającego smart kontraktu chcą zmienić warunki, czy mogą anulować ten smart kontrakt za pomocą multi-podpisu, a następnie stworzyć nowy smart kontrakt z zaktualizowanymi warunkami jego realizacji?
Odpowiedź na to pytanie jest dwojaka. Dlaczego? Ponieważ z jednej strony smart kontrakt jest ustalany raz na zawsze i nie przewiduje żadnych zmian, a z drugiej strony może mieć wcześniej zdefiniowaną logikę, która przewiduje całkowitą lub częściową zmianę niektórych warunków. To znaczy, jeśli chcesz coś zmienić w swoim smart kontrakcie, musisz wcześniej określić warunki, na podstawie których możesz zaktualizować te warunki. W związku z tym, tylko w ten sposób można zorganizować aktualizację kontraktu. Ale i tutaj można napotkać problemy: popełnić jakiś błąd i uzyskać odpowiednią lukę. Dlatego takie rzeczy trzeba projektować i testować bardzo dokładnie i starannie.
— A jeśli mediator wejdzie w zmowę z jedną ze stron-uczestników: escrow lub smart kontraktu? Czy mediator jest obowiązkowy w smart kontrakcie?
Mediator nie jest obowiązkowy w smart kontrakcie. Może go nie być. Jeśli w przypadku escrow mediator wejdzie w zmowę z jedną ze stron, to tak, ten schemat wówczas traci na wartości. Dlatego mediatorzy są wybierani w taki sposób, że ufają im jednocześnie wszystkie strony zaangażowane w ten proces. W związku z tym po prostu nie będziesz przekazywać monet na adres multisignature z tym mediatorem, któremu nie ufasz.
— Czy można jedną transakcją Ethereum przetransferować wiele różnych tokenów ze swojego adresu na różne cele, na przykład na adresy giełdowe, gdzie te tokeny są handlowane?
To dobre pytanie i dotyczy modelu transakcji Ethereum oraz jego różnic w stosunku do modelu Bitcoin. A różnica ta jest zasadnicza. W modelu transakcji Ethereum po prostu przekazujesz monety, które są przesyłane z jednego adresu na inny, bez reszty, po prostu konkretna kwota, którą wskazałeś. Innymi słowy, nie jest to model niewydanych wyjść (UTXO), lecz model kont i odpowiadających im sald. Teoretycznie można jedną transakcją wysłać kilka różnych tokenów, jeśli napiszesz sprytny smart kontrakt, ale i tak będziesz musiał wykonać wiele transakcji, stworzyć kontrakt, potem przekazać mu tokeny i monety, a następnie wywołać odpowiednią metodę. Wymaga to wysiłku i czasu, dlatego w praktyce tak to nie działa, a wszystkie płatności w Ethereum są dokonywane jako oddzielne transakcje.
— Mitem o platformie Ethereum jest to, że nie można opisać takich warunków, które będą zależne od danych z zewnętrznego zasobu internetowego, jak wtedy być?
Rozwiązanie polega na tym, że sam smart kontrakt może przewidywać jednego lub kilku tzw. zaufanych oracle, którzy zbierają dane o stanie rzeczy w świecie zewnętrznym i przekazują je do smart kontraktów poprzez specjalne metody. Sam kontrakt uznaje za prawdę te dane, które otrzymał od zaufanych stron. Dla większej niezawodności po prostu wybiera się większą grupę oracle i minimalizuje ryzyko ich zmowy. Sam kontrakt może nie brać pod uwagę danych od oracle, które są sprzeczne z opinią większości.
Temat ten jest poruszany w jednym z wykładów kursu online o Blockchain — “”.
Źródło: habr.com
