Zrozumienie specyfikacji EVM z Yellow Paper

Yellow Paper (opens in a new tab) to formalna specyfikacja Ethereum. Z wyjątkiem zmian wprowadzonych w ramach procesu EIP, zawiera ona dokładny opis działania wszystkiego. Jest napisana jako praca matematyczna, która zawiera terminologię, która może nie być znana programistom. W tym artykule dowiesz się, jak ją czytać, a co za tym idzie, inne powiązane prace matematyczne.

Który Yellow Paper?

Podobnie jak prawie wszystko inne w Ethereum, Yellow Paper ewoluuje z czasem. Aby móc odnieść się do konkretnej wersji, załadowałem aktualną wersję w momencie pisania tego tekstu. Numery sekcji, stron i równań, których używam, będą odnosić się do tej wersji. Dobrym pomysłem jest otwarcie jej w innym oknie podczas czytania tego dokumentu.

Dlaczego EVM?

Oryginalny Yellow Paper został napisany na samym początku rozwoju Ethereum. Opisuje oryginalny mechanizm konsensusu oparty na proof-of-work, który był pierwotnie używany do zabezpieczania sieci. Jednakże we wrześniu 2022 roku Ethereum wyłączyło proof-of-work i zaczęło używać konsensusu opartego na proof-of-stake. Ten samouczek skupi się na częściach Yellow Paper definiujących Wirtualną Maszynę Ethereum. EVM pozostała niezmieniona po przejściu na proof-of-stake (z wyjątkiem zwracanej wartości kodu operacyjnego DIFFICULTY).

9 Model wykonania

Ta sekcja (s. 12-14) zawiera większość definicji EVM.

Termin stan systemu obejmuje wszystko, co trzeba wiedzieć o systemie, aby go uruchomić. W typowym komputerze oznacza to pamięć, zawartość rejestrów itp.

Maszyna Turinga (opens in a new tab) jest modelem obliczeniowym. Zasadniczo jest to uproszczona wersja komputera, o której udowodniono, że ma taką samą zdolność do wykonywania obliczeń jak normalny komputer (wszystko, co może obliczyć komputer, może obliczyć maszyna Turinga i na odwrót). Ten model ułatwia udowadnianie różnych twierdzeń o tym, co jest, a co nie jest obliczalne.

Termin kompletność Turinga (opens in a new tab) oznacza komputer, który może wykonywać te same obliczenia co maszyna Turinga. Maszyny Turinga mogą wpaść w nieskończone pętle, a EVM nie, ponieważ zabrakłoby jej gazu, więc jest tylko quasi-kompletna w sensie Turinga.

9.1 Podstawy

Ta sekcja przedstawia podstawy EVM i porównuje ją z innymi modelami obliczeniowymi.

Maszyna stosowa (opens in a new tab) to komputer, który przechowuje dane pośrednie nie w rejestrach, ale na stosie (opens in a new tab). Jest to preferowana architektura dla maszyn wirtualnych, ponieważ jest łatwa w implementacji, co oznacza, że błędy i luki w zabezpieczeniach są znacznie mniej prawdopodobne. Pamięć na stosie jest podzielona na 256-bitowe słowa. Zostało to wybrane, ponieważ jest to wygodne dla podstawowych operacji kryptograficznych Ethereum, takich jak haszowanie Keccak-256 i obliczenia na krzywych eliptycznych. Maksymalny rozmiar stosu to 1024 elementy (1024 x 256 bitów). Kiedy kody operacyjne są wykonywane, zazwyczaj pobierają swoje parametry ze stosu. Istnieją kody operacyjne specjalnie do reorganizacji elementów na stosie, takie jak POP (usuwa element z wierzchołka stosu), DUP_N (duplikuje N-ty element na stosie) itp.

EVM posiada również ulotną przestrzeń zwaną pamięcią, która jest używana do przechowywania danych podczas wykonywania. Pamięć ta jest zorganizowana w 32-bajtowe słowa. Wszystkie lokalizacje w pamięci są inicjalizowane do zera. Jeśli wykonasz ten kod w Yul (opens in a new tab), aby dodać słowo do pamięci, wypełni on 32 bajty pamięci, uzupełniając pustą przestrzeń w słowie zerami, tzn. tworzy jedno słowo – z zerami w lokalizacjach 0–29, 0x60 w lokalizacji 30 i 0xA7 w lokalizacji 31.

1mstore(0, 0x60A7)

mstore to jeden z trzech kodów operacyjnych, które EVM zapewnia do interakcji z pamięcią – ładuje słowo do pamięci. Pozostałe dwa to mstore8, który ładuje pojedynczy bajt do pamięci, oraz mload, który przenosi słowo z pamięci na stos.

EVM posiada również oddzielną, nietrwałą pamięć trwałą (storage), która jest utrzymywana jako część stanu systemu – jest ona zorganizowana w tablice słów (w przeciwieństwie do adresowalnych słowami tablic bajtów na stosie). W tej pamięci trwałej kontrakty przechowują trwałe dane — kontrakt może wchodzić w interakcje tylko z własną pamięcią trwałą. Pamięć trwała jest zorganizowana w mapowania klucz-wartość.

Chociaż nie jest to wspomniane w tej sekcji Yellow Paper, warto również wiedzieć, że istnieje czwarty rodzaj pamięci. Calldata to adresowalna bajtowo pamięć tylko do odczytu, używana do przechowywania wartości przekazanej wraz z parametrem data transakcji. EVM ma określone kody operacyjne do zarządzania calldata. calldatasize zwraca rozmiar danych. calldataload ładuje dane na stos. calldatacopy kopiuje dane do pamięci.

Standardowa architektura von Neumanna (opens in a new tab) przechowuje kod i dane w tej samej pamięci. EVM nie przestrzega tego standardu ze względów bezpieczeństwa — współdzielenie pamięci ulotnej umożliwia zmianę kodu programu. Zamiast tego kod jest zapisywany w pamięci trwałej.

Istnieją tylko dwa przypadki, w których kod jest wykonywany z pamięci:

• Gdy kontrakt tworzy inny kontrakt (przy użyciu CREATE (opens in a new tab) lub CREATE2 (opens in a new tab)), kod konstruktora kontraktu pochodzi z pamięci.
• Podczas tworzenia dowolnego kontraktu kod konstruktora jest uruchamiany, a następnie zwraca kod właściwego kontraktu, również z pamięci.

Termin wykonanie wyjątkowe oznacza wyjątek, który powoduje zatrzymanie wykonywania bieżącego kontraktu.

9.2 Przegląd opłat

W tej sekcji wyjaśniono, w jaki sposób obliczane są opłaty za gaz. Istnieją trzy koszty:

Koszt kodu operacyjnego

Nieodłączny koszt danego kodu operacyjnego. Aby uzyskać tę wartość, znajdź grupę kosztów kodu operacyjnego w Dodatku H (s. 28, pod równaniem (327)) i znajdź grupę kosztów w równaniu (324). Daje to funkcję kosztu, która w większości przypadków wykorzystuje parametry z Dodatku G (s. 27).

Na przykład kod operacyjny CALLDATACOPY (opens in a new tab) należy do grupy W_copy. Koszt kodu operacyjnego dla tej grupy to G_verylow+G_copy×⌈μ_s[2]÷32⌉. Patrząc na Dodatek G, widzimy, że obie stałe wynoszą 3, co daje nam 3+3×⌈μ_s[2]÷32⌉.

Nadal musimy rozszyfrować wyrażenie ⌈μ_s[2]÷32⌉. Zewnętrzna część, ⌈ <value> ⌉, to funkcja sufitu, czyli funkcja, która dla danej wartości zwraca najmniejszą liczbę całkowitą, która nie jest mniejsza od tej wartości. Na przykład ⌈2,5⌉ = ⌈3⌉ = 3. Wewnętrzna część to μ_s[2]÷32. Patrząc na sekcję 3 (Konwencje) na s. 3, μ to stan maszyny. Stan maszyny jest zdefiniowany w sekcji 9.4.1 na s. 13. Zgodnie z tą sekcją jednym z parametrów stanu maszyny jest s dla stosu. Podsumowując, wydaje się, że μ_s[2] to lokalizacja #2 na stosie. Patrząc na kod operacyjny (opens in a new tab), lokalizacja #2 na stosie to rozmiar danych w bajtach. Patrząc na inne kody operacyjne w grupie W_copy, CODECOPY (opens in a new tab) i RETURNDATACOPY (opens in a new tab), mają one również rozmiar danych w tej samej lokalizacji. Zatem ⌈μ_s[2]÷32⌉ to liczba 32-bajtowych słów wymaganych do przechowywania kopiowanych danych. Podsumowując wszystko, nieodłączny koszt CALLDATACOPY (opens in a new tab) to 3 jednostki gazu plus 3 za każde kopiowane słowo danych.

Koszt bieżący

Koszt uruchomienia kodu, który wywołujemy.

• W przypadku CREATE (opens in a new tab) i CREATE2 (opens in a new tab) jest to konstruktor nowego kontraktu.
• W przypadku CALL (opens in a new tab), CALLCODE (opens in a new tab), STATICCALL (opens in a new tab) lub DELEGATECALL (opens in a new tab) jest to kontrakt, który wywołujemy.

Koszt rozszerzenia pamięci

Koszt rozszerzenia pamięci (w razie potrzeby).

W równaniu 324 wartość ta jest zapisana jako C_mem(μ_i')-C_mem(μ_i). Patrząc ponownie na sekcję 9.4.1, widzimy, że μ_i to liczba słów w pamięci. Zatem μ_i to liczba słów w pamięci przed kodem operacyjnym, a μ_i' to liczba słów w pamięci po kodzie operacyjnym.

Funkcja C_mem jest zdefiniowana w równaniu 326: C_mem(a) = G_memory × a + ⌊a² ÷ 512⌋. ⌊x⌋ to funkcja podłogi, czyli funkcja, która dla danej wartości zwraca największą liczbę całkowitą, która nie jest większa od tej wartości. Na przykład ⌊2,5⌋ = ⌊2⌋ = 2. Gdy a < √512, a² < 512, a wynik funkcji podłogi wynosi zero. Zatem dla pierwszych 22 słów (704 bajtów) koszt rośnie liniowo wraz z liczbą wymaganych słów pamięci. Powyżej tego punktu ⌊a² ÷ 512⌋ jest dodatnie. Gdy wymagana pamięć jest wystarczająco duża, koszt gazu jest proporcjonalny do kwadratu ilości pamięci.

Uwaga: te czynniki wpływają tylko na nieodłączny koszt gazu – nie uwzględniają rynku opłat ani napiwków dla walidatorów, które określają, ile użytkownik końcowy musi zapłacić – to tylko surowy koszt uruchomienia określonej operacji na EVM.

Przeczytaj więcej o gazie.

9.3 Środowisko wykonawcze

Środowisko wykonawcze to krotka, I, która zawiera informacje, które nie są częścią stanu blockchaina ani EVM.

Kilka innych parametrów jest niezbędnych do zrozumienia reszty sekcji 9:

9.4 Przegląd wykonania

Teraz, gdy mamy już wszystkie wstępne informacje, możemy w końcu zacząć pracować nad tym, jak działa EVM.

Równania 137–142 podają nam warunki początkowe do uruchomienia EVM:

Równanie 143 mówi nam, że w każdym momencie podczas wykonywania istnieją cztery możliwe warunki i co z nimi zrobić:

1. Z(σ,μ,A,I). Z reprezentuje funkcję, która sprawdza, czy operacja tworzy nieprawidłowe przejście stanu (zobacz zatrzymanie wyjątkowe). Jeśli wynikiem jest Prawda, nowy stan jest identyczny ze starym (z wyjątkiem tego, że gaz jest spalany), ponieważ zmiany nie zostały zaimplementowane.
2. Jeśli wykonywany jest kod operacyjny REVERT (opens in a new tab), nowy stan jest taki sam jak stary stan, a część gazu przepada.
3. Jeśli sekwencja operacji jest zakończona, co jest sygnalizowane przez RETURN (opens in a new tab)), stan jest aktualizowany do nowego stanu.
4. Jeśli nie jesteśmy w jednym z warunków końcowych 1-3, kontynuuj działanie.

9.4.1 Stan maszyny

Ta sekcja wyjaśnia bardziej szczegółowo stan maszyny. Określa, że w to bieżący kod operacyjny. Jeśli μ_pc jest mniejsze niż ||I_b||, długość kodu, to ten bajt (I_b[μ_pc]) jest kodem operacyjnym. W przeciwnym razie kod operacyjny jest zdefiniowany jako STOP (opens in a new tab).

Ponieważ jest to maszyna stosowa (opens in a new tab), musimy śledzić liczbę elementów zdjętych ze stosu (δ) i umieszczonych na nim (α) przez każdy kod operacyjny.

9.4.2 Wyjątkowe zatrzymanie

W tej sekcji zdefiniowano funkcję Z, która określa, kiedy mamy do czynienia z nienormalnym zakończeniem. Jest to funkcja logiczna (opens in a new tab), więc używa ∨ dla lub logicznego (opens in a new tab) i ∧ dla i logicznego (opens in a new tab).

Mamy wyjątkowe zatrzymanie, jeśli którykolwiek z tych warunków jest prawdziwy:

• μ_g < C(σ,μ,A,I) Jak widzieliśmy w sekcji 9.2, C to funkcja, która określa koszt gazu. Nie ma wystarczającej ilości gazu na pokrycie następnego kodu operacyjnego.

• δ_w=∅ Jeśli liczba elementów zdejmowanych dla kodu operacyjnego jest niezdefiniowana, to sam kod operacyjny jest niezdefiniowany.

• || μ_s || < δ_w Niedomiar stosu, niewystarczająca liczba elementów na stosie dla bieżącego kodu operacyjnego.

• w = JUMP ∧ μ_s[0]∉D(I_b) Kod operacyjny to JUMP (opens in a new tab), a adres to nie JUMPDEST (opens in a new tab). Skoki są ważne tylko wtedy, gdy miejscem docelowym jest JUMPDEST (opens in a new tab).

• w = JUMPI ∧ μ_s[1]≠0 ∧ μ_s[0] ∉ D(I_b) Kod operacyjny to JUMPI (opens in a new tab), warunek jest prawdziwy (niezerowy), więc skok powinien nastąpić, a adres nie jest JUMPDEST (opens in a new tab). Skoki są ważne tylko wtedy, gdy miejscem docelowym jest JUMPDEST (opens in a new tab).

• w = RETURNDATACOPY ∧ μ_s[1]+μ_s[2]>|| μ_o || Kod operacyjny to RETURNDATACOPY (opens in a new tab). W tym kodzie operacyjnym element stosu μ_s[1] to przesunięcie, od którego należy odczytywać dane w buforze danych zwrotnych, a element stosu μ_s[2] to długość danych. Ten warunek występuje, gdy próbujesz odczytać dane poza końcem bufora danych zwrotnych. Należy zauważyć, że nie ma podobnego warunku dla calldata ani dla samego kodu. Gdy próbujesz odczytać dane poza końcem tych buforów, otrzymujesz po prostu zera.

• || μ_s || - δ_w + α_w > 1024

  Przepełnienie stosu. Jeśli uruchomienie kodu operacyjnego spowoduje, że stos będzie zawierał ponad 1024 elementy, przerwij.

• ¬I_w ∧ W(w,μ) Czy działamy statycznie (¬ to negacja (opens in a new tab), a I_w jest prawdziwe, gdy możemy zmienić stan blockchaina)? Jeśli tak i próbujemy wykonać operację zmiany stanu, nie może ona się powieść.

  Funkcja W(w,μ) jest zdefiniowana później w równaniu 150. W(w,μ) jest prawdą, jeśli jeden z tych warunków jest prawdziwy:

  • w ∈ {CREATE, CREATE2, SSTORE, SELFDESTRUCT} Te kody operacyjne zmieniają stan, tworząc nowy kontrakt, przechowując wartość lub niszcząc bieżący kontrakt.

  • LOG0≤w ∧ w≤LOG4 Jeśli jesteśmy wywoływani statycznie, nie możemy emitować wpisów dziennika. Kody operacyjne dziennika znajdują się w zakresie od LOG0 (A0) (opens in a new tab) do LOG4 (A4) (opens in a new tab). Liczba po kodzie operacyjnym dziennika określa, ile tematów zawiera wpis dziennika.

  • w=CALL ∧ μ_s[2]≠0 Możesz wywołać inny kontrakt, gdy jesteś statyczny, ale jeśli to zrobisz, nie możesz przelać do niego ETH.

• w = SSTORE ∧ μ_g ≤ G_callstipend Nie można uruchomić SSTORE (opens in a new tab), chyba że masz więcej gazu niż G_callstipend (zdefiniowane jako 2300 w Dodatku G).

9.4.3 Prawidłowość miejsca docelowego skoku

Tutaj formalnie definiujemy, czym są kody operacyjne JUMPDEST (opens in a new tab). Nie możemy po prostu szukać wartości bajtowej 0x5B, ponieważ może ona znajdować się wewnątrz PUSH (a zatem być danymi, a nie kodem operacyjnym).

W równaniu (153) definiujemy funkcję N(i,w). Pierwszy parametr, i, to lokalizacja kodu operacyjnego. Drugi, w, to sam kod operacyjny. Jeśli w∈[PUSH1, PUSH32], oznacza to, że kod operacyjny to PUSH (nawiasy kwadratowe definiują zakres, który obejmuje punkty końcowe). W takim przypadku następny kod operacyjny znajduje się w i+2+(w−PUSH1). W przypadku PUSH1 (opens in a new tab) musimy przesunąć się o dwa bajty (sam PUSH i jednobajtowa wartość), w przypadku PUSH2 (opens in a new tab) musimy przesunąć się o trzy bajty, ponieważ jest to dwubajtowa wartość itd. Wszystkie inne kody operacyjne EVM mają tylko jeden bajt długości, więc we wszystkich innych przypadkach N(i,w)=i+1.

Ta funkcja jest używana w równaniu (152) do zdefiniowania D_J(c,i), który jest zbiorem (opens in a new tab) wszystkich prawidłowych miejsc docelowych skoku w kodzie c, zaczynając od lokalizacji kodu operacyjnego i. Ta funkcja jest zdefiniowana rekurencyjnie. Jeśli i≥||c||, oznacza to, że jesteśmy na końcu kodu lub za nim. Nie znajdziemy już żadnych miejsc docelowych skoku, więc po prostu zwróć pusty zbiór.

We wszystkich innych przypadkach patrzymy na resztę kodu, przechodząc do następnego kodu operacyjnego i pobierając zbiór, zaczynając od niego. c[i] to bieżący kod operacyjny, więc N(i,c[i]) to lokalizacja następnego kodu operacyjnego. D_J(c,N(i,c[i])) jest zatem zbiorem prawidłowych miejsc docelowych skoku, który zaczyna się od następnego kodu operacyjnego. Jeśli bieżący kod operacyjny nie jest JUMPDEST, po prostu zwróć ten zbiór. Jeśli jest to JUMPDEST, umieść go w zbiorze wyników i zwróć go.

9.4.4 Normalne zatrzymanie

Funkcja zatrzymania H może zwracać trzy typy wartości.

• Jeśli nie jesteśmy w kodzie operacyjnym zatrzymania, zwróć ∅, pusty zbiór. Zgodnie z konwencją wartość ta jest interpretowana jako logiczny fałsz.
• Jeśli mamy kod operacyjny zatrzymania, który nie generuje danych wyjściowych (albo STOP (opens in a new tab), albo SELFDESTRUCT (opens in a new tab)), zwróć sekwencję zerowej liczby bajtów jako wartość zwracaną. Należy zauważyć, że jest to zupełnie co innego niż pusty zbiór. Ta wartość oznacza, że EVM naprawdę się zatrzymała, tylko nie ma danych zwrotnych do odczytania.
• Jeśli mamy kod operacyjny zatrzymania, który generuje dane wyjściowe (albo RETURN (opens in a new tab), albo REVERT (opens in a new tab)), zwróć sekwencję bajtów określoną przez ten kod operacyjny. Ta sekwencja jest pobierana z pamięci, wartość na szczycie stosu (μ_s[0]) to pierwszy bajt, a wartość za nią (μ_s[1]) to długość.

H.2 Zestaw instrukcji

Zanim przejdziemy do ostatniej podsekcji EVM, 9.5, spójrzmy na same instrukcje. Są one zdefiniowane w Dodatku H.2, który zaczyna się na s. 29. Wszystko, co nie jest określone jako zmieniające się wraz z tym konkretnym kodem operacyjnym, powinno pozostać takie samo. Zmienne, które się zmieniają, są określone jako <coś>′.

Spójrzmy na przykład na kod operacyjny ADD (opens in a new tab).

δ to liczba wartości, które zdejmujemy ze stosu. W tym przypadku dwie, ponieważ dodajemy dwie górne wartości.

α to liczba wartości, które odkładamy na stos. W tym przypadku jedna, suma.

Zatem nowy wierzchołek stosu (μ′_s[0]) jest sumą starego wierzchołka stosu (μ_s[0]) i starej wartości pod nim (μ_s[1]).

Zamiast przechodzić przez wszystkie kody operacyjne w postaci „listy przyprawiającej o zawrót głowy”, ten artykuł wyjaśnia tylko te kody operacyjne, które wprowadzają coś nowego.

Jest to pierwszy kod operacyjny, który uzyskuje dostęp do pamięci (w tym przypadku tylko do odczytu). Może on jednak wykraczać poza obecne granice pamięci, więc musimy zaktualizować μ_i. Robimy to za pomocą funkcji M zdefiniowanej w równaniu 328 na s. 29.

Adres, którego saldo musimy znaleźć to μ_s[0] mod 2¹⁶⁰. Wierzchołek stosu to adres, ale ponieważ adresy mają tylko 160 bitów, obliczamy wartość modulo (opens in a new tab) 2¹⁶⁰.

Jeśli σ[μ_s[0] mod 2¹⁶⁰] ≠ ∅, oznacza to, że istnieją informacje o tym adresie. W takim przypadku σ[μ_s[0] mod 2¹⁶⁰]_b to saldo dla tego adresu. Jeśli σ[μ_s[0] mod 2¹⁶⁰] = ∅, oznacza to, że ten adres jest niezainicjalizowany, a saldo wynosi zero. Listę pól informacyjnych konta można zobaczyć w sekcji 4.1 na s. 4.

Drugie równanie, A'_a ≡ A_a ∪ {μ_s[0] mod 2¹⁶⁰}, jest związane z różnicą w kosztach między dostępem do ciepłej pamięci trwałej (pamięci, do której ostatnio uzyskano dostęp i która prawdopodobnie jest w pamięci podręcznej) a zimną pamięcią trwałą (pamięcią, do której nie było dostępu i która prawdopodobnie znajduje się w wolniejszej pamięci, której odzyskanie jest droższe). A_a to lista adresów, do których wcześniej uzyskano dostęp w ramach transakcji, a zatem dostęp do nich powinien być tańszy, zgodnie z definicją w sekcji 6.1 na s. 8. Więcej na ten temat można przeczytać w EIP-2929 (opens in a new tab).

Należy pamiętać, że aby użyć dowolnego elementu stosu, musimy go zdjąć, co oznacza, że musimy również zdjąć wszystkie elementy stosu znajdujące się nad nim. W przypadku DUP<n> (opens in a new tab) i SWAP<n> (opens in a new tab) oznacza to konieczność zdjęcia, a następnie odłożenia na stos do szesnastu wartości.

9.5 Cykl wykonania

Teraz, gdy mamy już wszystkie części, możemy w końcu zrozumieć, jak udokumentowany jest cykl wykonania EVM.

Równanie (155) mówi, że biorąc pod uwagę stan:

• σ (globalny stan blockchaina)
• μ (stan EVM)
• A (podstan, zmiany, które mają nastąpić po zakończeniu transakcji)
• I (środowisko wykonawcze)

Nowy stan to (σ', μ', A', I').

Równania (156)-(158) definiują stos i zmianę w nim spowodowaną przez kod operacyjny (μ_s). Równanie (159) to zmiana w gazie (μ_g). Równanie (160) to zmiana w liczniku programu (μ_pc). Wreszcie równania (161)-(164) określają, że pozostałe parametry pozostają takie same, chyba że zostały wyraźnie zmienione przez kod operacyjny.

W ten sposób EVM jest w pełni zdefiniowana.

Wnioski

Notacja matematyczna jest precyzyjna i pozwoliła Yellow Paper na określenie każdego szczegółu Ethereum. Ma to jednak pewne wady:

• Może być zrozumiana tylko przez ludzi, co oznacza, że testy zgodności (opens in a new tab) muszą być pisane ręcznie.
• Programiści rozumieją kod komputerowy. Mogą rozumieć notację matematyczną lub nie.

Być może z tych powodów nowsze specyfikacje warstwy konsensusu (opens in a new tab) są napisane w Pythonie. Istnieją specyfikacje warstwy wykonawczej w Pythonie (opens in a new tab), ale nie są one kompletne. Dopóki cały Yellow Paper nie zostanie również przetłumaczony na język Python lub podobny, Yellow Paper będzie nadal w użyciu i warto umieć go czytać.

Strona ostatnio zaktualizowana: 3 marca 2026

m (opens in a new tab)

s (opens in a new tab)

p (opens in a new tab)

+9

Zobacz współtwórców