Miesiąc: Wrzesień 2019

W Ethereum konta są mapowane na odpowiadające im stany. Mapowanie między wszystkimi kontami Ethereum, w tym EOA i Konta kontraktowe z ich stanami są wspólnie nazywane stanami światowymi. Aby przechowywać te dane mapowania, strukturą danych stosowaną w Ethereum jest MPT. Tak więc MPT jest główną strukturą danych stosowaną w Ethereum, znanym również jako Merkle Patricia trie. Dowiedzieliśmy się o drzewkach Merkle w rozdziale Bitcoin, który już teraz zajmuje nam połowę zrozumienia MPT. MPT jest w rzeczywistości uzyskiwany przez pobieranie elementów zarówno z drzewa Merkle, jak i drzewa Patricia. Przypomnij sobie z rozdziału Bitcoin, że drzewa Merkle są binarne drzewa skrótów, w których węzły liścia zawierają skrót bloków danych, a każdy nieleafowy węzeł zawiera skróty ich węzłów potomnych. Po zaimplementowaniu takiej struktury danych łatwo jest sprawdzić, czy określona transakcja była częścią bloku. Tylko przy użyciu bardzo małej ilości informacji z całego bloku, to znaczy przy użyciu tylko gałęzi Merkle zamiast całego drzewa, dostarczenie dowodu członkostwa było dość łatwe. Drzewa merkle ułatwiają sprawną i bezpieczną weryfikację zawartości w zdecentralizowanych systemach. Zamiast pobierać każdą transakcję i każdy blok, klienci light mogą pobierać tylko łańcuch nagłówków bloków, to znaczy 80-bajtowe fragmenty danych dla każdego bloku, które zawierają tylko pięć rzeczy: skrót poprzedniego nagłówka bloku, znacznik czasu, trudność wyszukiwania , wartość nonce, która spełniała wartość PoW, a skrót główny drzewa Merkle zawierający wszystkie transakcje dla tego bloku. Chociaż jest to dość użyteczne i interesujące, zauważ tutaj, że oprócz sprawdzania dowodu członkostwa dla transakcji w bloku, nic nie możesz zrobić. Jednym szczególnym ograniczeniem jest to, że nie można udowodnić żadnych informacji o bieżącym stanie (np. Całkowite zasoby aktywów cyfrowych, rejestracja nazw, status umów finansowych). Nawet w celu sprawdzenia, ile Bitcoinów posiadasz, wiąże się to z dużą ilością zapytań i weryfikacji. Z drugiej strony drzewa Patricia są formą drzew Radix. Nazwa PATRICIA oznacza „Praktyczny algorytm odzyskiwania informacji zakodowanych alfanumerycznie”. Drzewo Patricia ułatwia wydajne operacje wstawiania / usuwania. Wyszukiwanie klucz-wartość w drzewie Patricia jest bardzo wydajne. Klucze są zawsze zakodowane na ścieżce. Zatem „klucz” to ścieżka, którą pobierasz od korzenia do węzła liścia, w którym przechowywana jest „wartość”. Klucze to zwykle ciągi znaków, które pomagają zejść w dół ścieżki, gdzie każdy znak wskazuje, który węzeł potomny ma podążać, aby dotrzeć do węzła liścia i znaleźć w nim zapisaną wartość. Tak więc MPT zapewniają kryptograficznie uwierzytelnioną strukturę danych używaną do przechowywania wszystkich powiązań (klucz, wartość) w Ethereum. Są w pełni deterministyczne, co oznacza, że ​​drzewo Patricia z tymi samymi powiązaniami (klucz, wartość) z pewnością będzie takie samo aż do ostatniego bajtu. Operacje wstawiania, wyszukiwania i usuwania są dość wydajne przy złożoności O (log (n)). Ze względu na część Merkle w MPT, skrót węzła jest używany jako wskaźnik do węzła, a MPT jest odpowiednio skonstruowany, gdzie Key == SHA3 (RLP (wartość)) Podczas gdy część Merkle zapewnia odporną na manipulacje i deterministyczną strukturę drzewa, część Patricia zapewnia wydajną funkcję wyszukiwania informacji. Więc jeśli zauważysz uważnie, węzeł główny w MPT staje się kryptograficznym odciskiem palca całej struktury danych. W sieci Ethereum P2P, gdy transakcje są transmitowane przewodowo, są one montowane przez każdy węzeł wydobywczy, który je otrzymał. Węzły następnie tworzą Drzewo (a.k.a. trie) i obliczają wartość skrótu głównego, aby uwzględnić ją w nagłówku bloku. Chociaż transakcje są przechowywane lokalnie w drzewie, są one wysyłane do innych węzłów lub klientów po ich serializacji na listy. Strony odbierające muszą je przekształcić z postaci szeregowej z powrotem w celu utworzenia drzewa transakcji w celu weryfikacji względem wartości skrótu głównego. Zauważ też, że w Ethereum, MPT są nieco zmodyfikowane, aby lepiej pasowały do ​​implementacji Ethereum. Zamiast binarnego używany jest szesnastkowy – znaki X z 16-znakowego „alfabetu”. Dlatego węzły w drzewie lub trie mają 16 węzłów potomnych (16-znakowy alfabet szesnastkowy) i maksymalną głębokość X. Aby dać znać, a W wielu miejscach znak szesnastkowy nazywany jest „skubkiem”. Podstawową ideą MPT w Ethereum jest to, że dla pojedynczej operacji zmodyfikuje tylko minimalną liczbę węzłów, aby ponownie obliczyć skrót główny. W ten sposób pamięć i złożoność są minimalne.

Nauczyliśmy się trzech rodzajów prób, które mają swoje korzenie w nagłówku bloku. Te korzenie są w zasadzie wskazówkami dla tych trzech prób. Chociaż przyjrzeliśmy się jednoznacznym wyjaśnieniom tych prób w poprzednich sekcjach, przyjrzyjmy się im z nieco innym wyborem słów

• Trie stanowe: reprezentuje cały stan (stan globalny) po uzyskaniu dostępu do bloku.
• Trie transakcji: reprezentuje wszystkie transakcje w bloku kluczowanym przez indeks (tj. Klucz: 0 dla pierwszej transakcji do wykonania, klucz: 1 dla drugiej transakcji itp.). Przypomnijmy podstawy MPT, które omówiliśmy wcześniej i spróbuj je skorelować.
• Trie paragonów: reprezentuje „paragony” odpowiadające każdej transakcji. Potwierdzeniem transakcji jest struktura danych zakodowana w RLP, jak pokazano poniżej:

[medstate, gas_used, logbloom, logs]

Zagłębmy się teraz w trie pokwitowań, ponieważ nie omówiliśmy jeszcze podstaw tego tematu. Spójrz na wszystkie pola w strukturze danych zakodowanej w RLP w Triksie odbioru i postępuj zgodnie z poniższymi opisami dla tych pól:

• medstate: jest to państwowy katalog główny po przetworzeniu transakcji. Pomyślna transakcja aktualizuje stan Ethereum.
• gas_used: Jest to całkowita ilość gazu zużytego do przetworzenia transakcji.
• dzienniki: jest to lista elementów formularza

[adres, [temat1, temat2 …], dane]

• Te elementy listy są generowane przez kody LOG0, LOG1… podczas realizacji transakcji. Pole „adres” to adres kontraktu, który utworzył dziennik, pola „temat” mają maksymalnie cztery

Wartości 32-bajtowe, a pole „data” to tablica bajtów o dowolnym rozmiarze.

• Logbloom: Jest to filtr Blooma złożony z adresów i tematów wszystkich dzienników w transakcji. Różni się on od obecnego w nagłówku bloku.

Dowiedzieliśmy się, że z każdym kontem jest powiązany stan. Przyjrzeliśmy się także dwóm rodzajom kont, które istnieją w Ethereum, jednym z nich jest Konto Kontraktu, a drugim Konto Posiadane Zewnętrznie lub EOA. Niezależnie od rodzaju konta są one śledzone przez pierwiastek „stateRoot” Merkle w nagłówku bloku i mogą wyglądać tak, jak pokazano na rysunku

Jak widać na rysunku, niezależnie od tego, czy konto jest EOA lub Konto Kontraktu składa się z czterech następujących elementów:

• Saldo rachunku: całkowite saldo „Etheru” na rachunku. Dokładniej, liczba Wei posiadanych przez adres (1ETH = 1018 Wei)
• CodeHash: Jest to skrót „kodu”. Każde Konto Kontraktu zawiera „kod”, który jest wykonywany na EVM. Hash tego kodu jest przechowywany w tym polu CodeHash. Jednak dla kont EOA tam nie jest „kodem”, więc pole CodeHash zawiera skrót pustego łańcucha.
• StorageRoot: 256-bitowy skrót główny drzewa Merkle koduje zawartość konta. MPT koduje skrót zawartości pamięci. Utrzymywanie skrótu głównego tego drzewa w polu StorageRoot pomaga śledzić zawartość konta, a także pomaga zapewnić jego integralność.
• Nonce: jest licznikiem, który zapewnia, że ​​każda transakcja jest przetwarzana tylko raz. W przypadku EOA liczba ta reprezentuje liczbę transakcji z adresu konta. W przypadku kont kontraktowych reprezentuje liczbę umów utworzonych przez to konto. Tak więc to trie „stanowe” są odpowiedzialne za śledzenie stanu zmiany łańcucha bloków Ethereum. Jednak nieco skomplikowane jest to, że stan nie jest bezpośrednio zapisywany w każdym bloku, a raczej w postaci danych zakodowanych w prefiksie długości rekurencyjnej (RLP) w MPT w każdym węźle Ethereum. Tak więc, aby utrzymać stan globalny, łańcuch bloków Ethereum zawiera „korzenie stanu” w każdym bloku, który przechowuje skrót hash drzewa skrótu (korzeń Merkle) reprezentujący stan systemu w momencie utworzenia bloku. Zgodnie z żółtą księgą Ethereum „stan świata” to mapowanie między adresami (identyfikatory 160-bitowe) a stanami kont. Zatem państwo świata ma informacje o wszystkich kontach w blockchain, ale nie są przechowywane w każdym bloku. Każdy blok modyfikuje tylko części stanu. W pewien sposób państwo świata jest generowane przetwarzając każdy blok od momentu powstania bloku genezowego. Niektóre węzły Ethereum mogą wybrać zachowanie wszystkich stanów historycznych poprzez zachowanie wszystkich transakcji historycznych, to znaczy przejść między stanami i ich wyników. Umożliwia to klientom sprawdzanie stanu blockchain w dowolnym momencie, nawet historycznych, bez konieczności ponownego obliczania wszystkiego od początku. Pobieranie informacji o stanie jest podobne do zagregowanego zapytania w SQL, w którym dane są łatwo dostępne; wymagana jest tylko agregacja. Stare dane stanu można więc łatwo usunąć (jest to nazywane „przycinaniem”), ponieważ można je w razie potrzeby ponownie obliczyć. Cóż, dane stanu z założenia są domyślną dada, co oznacza, że ​​informacje o stanie należy obliczać tylko.

Mimo że Ethereum jest w pewnym sensie rozszerzeniem Bitcoin, wyobraża się sobie z zupełnie nowym projektem z własnym zestawem zalet i wad kompromisu. Przyjrzyjmy się następującym zaletom kont Ethereum w porównaniu z projektem Bitcoin:

• Znacząca oszczędność miejsca: w bitcoinach, gdy wiele transakcji jest ze sobą powiązanych, aby dokonać jednej transakcji (np. Jeśli musisz dokonać transakcji 5BTC i nigdy nie otrzymałeś jednej transakcji z co najmniej 5BTC, której możesz użyć w tym przypadku, to masz aby powiązać wiele transakcji, tak aby ich suma przekroczyła 5BTC), należy wprowadzić wiele odniesień do tych pojedynczych transakcji. Ponadto wszystkie te transakcje muszą mieć różne adresy, więc tyle transakcji, że wiele adresów też! Jednak na kontach Ethereum wystarczy tylko jedno odniesienie do konta. Mimo że Ethereum używa drzewa Merkle Patricia (MPT), które zajmuje nieco więcej miejsca niż drzewo Merkle, ostatecznie oszczędzasz znaczną ilość miejsca na złożone transakcje.
• Prosty do kodowania: wraz z UTXO i skryptami, które nie są kompletne w Turinga, trudno jest zaprojektować złożone systemy. UTXO można wydać lub wydać; pomiędzy nimi nie ma żadnego innego stanu. Co utrudnia kodowanie skomplikowanej logiki biznesowej. Parzysty jeśli skrypty są w stanie zrobić więcej, staje się to bardziej skomplikowane w porównaniu do zwykłego korzystania z kont. Ponieważ celem Ethereum jest wyjście poza kryptowalutę i dostosowanie się do różnych rodzajów przypadki użycia (poprzez DApps), system oparty na kontach jest prawie nieunikniony.
• Lekkie odniesienie do klienta: W przeciwieństwie do klientów Bitcoin, aplikacje klienckie Ethereum mogą łatwo i szybko uzyskać dostęp do wszystkich danych związanych z kontem, skanując drzewo stanu w określonym kierunku. W modelu UTXO zwykle istnieje wiele odniesień do wielu transakcji związanych z każdą konkretną rozważaną transakcją.

Musimy zrozumieć, że celem projektu Bitcoin było zachowanie anonimowości w możliwym zakresie. Kiedy porównamy to z Ethereum, następujące zalety UTXO wydają się mieć duże znaczenie:

• Lepsza prywatność: w Bitcoinach zaleca się używanie nowego adresu podczas otrzymywania transakcji, co pomaga wzmocnić anonimowość. Nawet przy zastosowaniu zaawansowanych technik statystycznych lub uczenia maszynowego trudno jest połączyć konta, choć nie jest to niemożliwe.
• Potencjalnie bardziej skalowalny: Dyskusja na temat skalowalności jest zwykle bardzo subiektywna i zależy od kontekstu, użytego przypadku i wielu innych czynników. Chodzi tutaj o to, aby wspomnieć o nieodłącznym potencjale skalowania UTXO. Transakcje są bardzo łatwe równolegle. Ponadto, gdy właściciel lub inne węzły przechowujące dane dowodu własności Merkle dla niektórych monet tracą te dane, dotyczy to tylko właściciela. Wręcz przeciwnie, gdy dane drzewa Merkle dla jakiegoś konta zostaną utracone, wówczas żadna operacja na tym koncie nie byłaby możliwa, nawet wysłanie do niego.

Konta Ethereum, w przeciwieństwie do Bitcoinów, nie mają postaci niewykorzystanych wyników transakcji (UTXO). W rozdziale Bitcoin dowiedzieliśmy się, że Bitcoiny są faktycznie obecne w postaci transakcji, które mają właściciela (klucz publiczny właściciela, 20-bajtowy adres) i wartość. Właściciel może wydać transakcję, jeśli ma prawidłowy klucz prywatny dla transakcji, którą próbuje wydać. Bitcoin jest zatem systemem zmiany stanu, w którym „stan” odnosi się do zbioru wszystkich UTXO. Za każdym razem, gdy blok jest wydobywany, następuje zmiana stanu, ponieważ każdy blok zawiera wiązkę transakcji, w których każda transakcja obejmuje UTXO (y) i wytwarza UTXO (y). Zauważ, że stan nie jest zakodowany w blokach. Tak więc nie ma pojęcia salda konta jako takiego w projekcie Bitcoin. Z drugiej strony Ethereum jest stanowe, a jego podstawową jednostką jest konto. Każde konto ma stan skojarzony z nim, a także ma adres 20-bajtowy (160 bitów), przez który jest identyfikowany i przywoływany. Celem blockchain w Ethereum jest śledzenie zmian stanu. Istnieją zasadniczo dwa rodzaje kont Ethereum:

• Rachunki zewnętrzne (EOA): konta te są również znane jako „proste konta”, które zwykle są własnością użytkowników lub urządzeń kontrolujących te konta za pomocą kluczy prywatnych. EOA mogą wysyłać transakcje do innych EOA lub kont kontraktowych, podpisując je kluczem prywatnym. Transakcja między dwoma EOA ma zwykle na celu przekazanie dowolnej wartości. Z drugiej strony, gdy EOA dokonuje transakcji na Konto Kontraktu, celem jest aktywacja „kodu” na Koncie Kontraktu.
• Konta kontraktowe: są one kontrolowane tylko przez kod w nich zawarty. Ten kod w Kontach Kontraktu jest określany jako „inteligentne kontrakty”. Zazwyczaj są one aktywowane, gdy transakcja jest wysyłana na Konto Kontraktu przez EOA lub inne Konta Kontraktu. Mimo że Konta Kontraktowe są w stanie wykonywać złożone logiki biznesowe za pomocą zawartego w nich kodu, nie mogą samodzielnie inicjować nowych transakcji i zawsze zależą od EOA. Wszystko, co mogą zrobić, to reagować na inne transakcje (oczywiście dokonując transakcji) zgodnie z logiką zakodowaną w ich „kodzie”. Spójrz na następujące trzy scenariusze dla lepszego zrozumienia komunikacji między EOA i Kontem kontraktowym

Transakcja EOA do EOA:

EOA do transakcji na rachunku kontraktu:

EOA do konta kontraktu na inną transakcję rachunku kontraktu:

Aby poprzednie zamieszania nie były mylące, pamiętaj, że Konta Konta są wewnętrzne i komunikacja między nimi również. W przeciwieństwie do kont EOA, na których EOA dokonują transakcji wprowadzanej do blockchaina, Konta Kontraktowe i transakcje między nimi są zjawiskiem wewnętrznym

Struktura danych łańcucha bloków Ethereum jest bardzo podobna do struktury Bitcoinów, z tym wyjątkiem, że w nagłówku bloku znajduje się znacznie więcej informacji, aby uczynić go bardziej niezawodnym i pomóc utrzymać właściwy stan. Dowiemy się więcej o stanach Ethereum w poniższych sekcjach. Skupmy się bardziej na strukturze danych blockchain i nagłówku w tej sekcji. W Bitcoinach w nagłówku bloku był tylko jeden katalog główny Merkle dla wszystkich transakcji w bloku. W Ethereum są jeszcze dwa korzenie Merkle, więc w sumie są trzy następujące korzenie Merkle:

• stateRoot: Pomaga utrzymać stan globalny.
• transakcjeRoot: służy do śledzenia i zapewnienia integralności

wszystkich transakcji w bloku, podobnie jak korzeń Bitcoin Merkle.

• receiptsRoot: Jest to skrót główny kwitu kwitów odpowiadający transakcjom w bloku

Przyjrzymy się tym rdzeniom Merkle w odpowiednich sekcjach informacji nagłówka bloku. Dla lepszego zrozumienia spójrz na rysunek

Każdy blok zwykle zawiera nagłówek bloku, listę transakcji, listę wujków i opcjonalne dodatkowe dane. Spójrzmy teraz na pola nagłówka, aby zrozumieć, co oznaczają i jaki jest cel bycia w nagłówku. Robiąc to, pamiętaj, że mogą istnieć niewielkie warianty tych nazw w różnych miejscach lub kolejność ich prezentacji może być różna w różnych miejscach. Sugerujemy, abyś dobrze zrozumiał te dziedziny, aby żadna inna terminologia, na którą się natkniesz, nie przeszkadzała ci zbytnio.

Sekcja 1: Blokuj metadane

• ParentHash: 256-bitowy skrót Keccak nagłówka bloku rodzica, podobnie jak w stylu Bitcoin
• znacznik czasu: blok prądu uniksowego znacznika czasu
• numer: numer bloku bieżącego bloku
• Beneficjent: 160-bitowy adres konta „autora” odpowiedzialnego za utworzenie bieżącego bloku, do którego pobierane są wszystkie opłaty za pomyślne wydobycie bloku

Sekcja 2: Odniesienia do danych

• Transakcje root: 256-bitowy skrót Keccak (root Merkle) transakcji trie zapełniony wszystkimi transakcjami w tym bloku
• ommersHash: jest również znany jako „uncleHash”. Jest to skrót segmentu wujków bloku, tj. 256-bitowy skrót Keccak części listy bloków tego bloku (bloki, o których wiadomo, że mają element nadrzędny równy rodzic rodzica obecnego bloku).
• extraData: Arbitralna tablica bajtów zawierająca dane istotne dla tego bloku. Rozmiar tych danych jest ograniczony do 32 bajtów (256 bitów). W chwili pisania tego tekstu istnieje możliwość, że to pole może stać się „extraDataHash”, co wskazuje na „extraData” zawartą w bloku. extraData mogą być surowymi danymi, obciążanymi jednocześnie

ilość gazu jak w danych transakcyjnych.

Sekcja 3: Informacje o realizacji transakcji

• stateRoot: 256-bitowy skrót Keccak (root Merkle) stanu końcowego po sprawdzeniu i wykonaniu wszystkich transakcji tego bloku
• receiptsRoot: 256-bitowy skrót główny Keccak (Merkle

root) paragonów trie zapełnianych adresatami

każdej transakcji w tym bloku

• logBloom: Skumulowany filtr Bloom dla każdego z wpływy transakcji ”Blooms, czyli„ OR ”wszystkich

Kwitnie dla transakcji w bloku

• gasUsed: Całkowita ilość gazu zużytego przez każdy z nich

transakcje w tym bloku

• gasLimit: maksymalna ilość gazu, którą blokuje

może wykorzystać (wartość dynamiczna w zależności od aktywności w sieć)

Sekcja 4: Informacje dotyczące podsystemu konsensusu

• trudność: Obliczono limit trudności dla tego bloku

na podstawie trudności i znacznika czasu poprzedniego bloku

• mixHash: 256-bitowy skrót mieszający w połączeniu z

„Nonce” dla PoW tego bloku

• nonce: nonce to 64-bitowy skrót, który jest łączony z mixHash i może być używany jako weryfikacja PoW.

Dowiedzieliśmy się o celu blockchain Ethereum i jego filozofii projektowania. Aby zrozumieć i docenić ten blockchain następnej generacji i zbudować na nim zdecentralizowane aplikacje, w tej sekcji szczegółowo omówimy podstawowe komponenty Ethereum.

Ethereum pożycza wiele koncepcji od Bitcoin Core, ponieważ przetrwał próbę czasu, ale został zaprojektowany z inną filozofią. Rozwój Ethereum został wykonany zgodnie z następującymi zasadami:

• Uproszczona konstrukcja: blockchain Ethereum został zaprojektowany tak, aby był możliwie jak najprostszy, dzięki czemu łatwo jest zrozumieć i opracować zdecentralizowane aplikacje. Złożoność wdrożenia jest ograniczona do minimum na poziomie konsensusu i zarządzana na poziomie wyższym. W rezultacie wysoki poziom

kompilacja języka lub serializacja / deserializacja argumentów itp. nie dotyczą programistów.

• Swoboda rozwoju: platforma Ethereum ma na celu zachęcanie do jakiejkolwiek decentralizacji na platformie blockchain i nie dyskredytuje ani nie faworyzuje konkretnych przypadków użycia. Ta swoboda jest zapewniona do tego stopnia, że ​​deweloper może zakodować nieskończoną pętlę w inteligentnej umowie i wdrożyć ją. Oczywiście pętla będzie działać, dopóki będą płacić opłatę transakcyjną (Cena gazu), a pętla ostatecznie zakończy się, gdy zabraknie gazu.
• Brak pojęcia funkcji: aby uczynić system bardziej uogólnionym, Ethereum nie ma wbudowanych funkcji, z których mogliby korzystać programiści. Zamiast tego Ethereum zapewnia obsługę języka Turing-complete i pozwala użytkownikom rozwijać własne funkcje tak, jak chcą. Począwszy od podstawowych funkcji, takich jak „czas blokady”, jak w bitcoinach, po pełne przypadki użycia, wszystko można zakodować w Ethereum.

Dzięki blockchainowi Bitcoin społeczność programistów próbowała budować różne zdecentralizowane aplikacje za pomocą zupełnie nowego blockchaina lub próbowała zmodyfikować Bitcoin Core, aby zwiększyć zestaw funkcjonalizacji. W każdym razie było to skomplikowane i czasochłonne. Inna konstrukcja z alternatywnym protokołem była wtedy prawdopodobnie potrzebą godziny, dlatego platforma blockchain Ethereum! Celem było ułatwienie rozwoju wielu aplikacji blockchain na jednej platformie Ethereum zamiast budowania dedykowanych blockchain dla każdej aplikacji osobno. Ethereum umożliwił szybki rozwój zdecentralizowanych aplikacji, które mogłyby ze sobą współdziałać, zapewniając odpowiednie bezpieczeństwo. Jak wspomniano w poprzedniej sekcji, Ethereum robi to, budując abstrakcyjną warstwę fundamentową. W przeciwieństwie do Bitcoin, Ethereum wspierało język kompletny Turinga, dzięki czemu każdy mógł pisać inteligentne kontrakty, które praktycznie mogłyby zrobić wszystko i wszystko z perspektywy programistycznej. Ponadto Ethereum jest z założenia stanowe i śledzi stany rachunków, co bardzo różni się od Bitcoin, gdzie wszystko pozostaje jako transakcja i nie ma wewnętrznej trwałej pamięci dla skryptów. Za pomocą abstrakcyjnej warstwy fundamentalnej ukryte są przed deweloperami złożoności, a nie tylko; programiści zyskują elastyczność w projektowaniu własnych funkcji zmiany stanu dla bezpośredniego transferu wartości i informacji oraz formatów transakcji. Aby osiągnąć ten cel, podstawową innowacją Ethereum była wirtualna maszyna Ethereum (EVM). Obsługa języków Turing-complete za pośrednictwem EVM ułatwia programistom tworzenie aplikacji blockchain. Tak jak Java Virtual Machine (JVM) wymagana do uruchomienia kodu Java, EVM jest wymagany do obsługi inteligentnych umów. Na razie pamiętaj tylko, że inteligentne kontrakty to skrypty Ethereum napisane w języku kompletnym Turinga, które są automatycznie wykonywane w przypadku wystąpienia określonego zdarzenia. „ScriptSig” i „ScriptPubKey” w Bitcoinach są podstawowymi wersjami inteligentnych umów, że tak powiem. W poprzednim rozdziale dowiedzieliśmy się, że w Bitcoinach zestaw instrukcji był bardzo ograniczony. Jednak w Ethereum można kodować prawie każdy program, który działałby na EVM na każdym węźle w sieci blockchain Ethereum. Zdecentralizowane aplikacje w Ethereum nazywane są DApps. Ethereum jest globalnym zdecentralizowanym systemem komputerowym bez scentralizowanego serwera. DApps to aplikacje działające bez przestojów, oszustw i jakichkolwiek innych regulacji. Elektroniczny system gotówkowy peer-to-peer, taki jak Bitcoin, jest bardzo łatwy do zbudowania na Ethereum jako DApp. Podobnie każdy inny zasób o pewnej wartości wewnętrznej, taki jak ziemia, samochody, domy, głosy itp., Można łatwo przeprowadzać za pośrednictwem odpowiednich kont DA w Ethereum w formie tokenów. W przeciwieństwie do tradycyjnego programowania i wdrażania oprogramowania, DApps nie musi być hostowany na serwerze wewnętrznym. „Kod” jest osadzony jako ładunek w transakcjach, że tak powiem, które są następnie wysyłane do węzłów wydobywczych w sieci Ethereum. Takie transakcje byłyby rozpatrywane przez ekosystem górniczy, ponieważ ETH (eter) płacony jako „cena gazu”. Podobnie jak w Bitcoin, transakcje te są transmitowane do innych górników w sieci, do których są dostępni. Transakcja w końcu wchodzi w blok i staje się wieczną częścią łańcucha bloków, gdy osiągnięty jest konsensus . Deweloperzy mogą kodować dowolne rozwiązania i wdrażać je w sieci Ethereum. Sieć sama to wykonuje, a także sprawdza i generuje dane wyjściowe. Cóż, gdyby był bez żadnych kosztów, sieć nie byłaby zrównoważona. Z każdą transakcją blockchain wiąże się cena gazu, a napisanie śmieciowego kodu i wdrożenie go w sieci Ethereum może być kosztownym przedsięwzięciem!