Przejdź do głównej zawartości
Change page

Bloki

Strona ostatnio zaktualizowana: 23 lutego 2026

Bloki są zestawami transakcji z kryptograficznym hashem poprzedniego bloku w łańcuchu. Łączy to bloki razem (w łańcuch), ponieważ hashe są kryptograficznymi pochodnymi z danych bloku. Zapobiega to oszustwom, ponieważ pojedyncza zmiana w dowolnym, historycznym bloku unieważniłaby wszystkie bloki następujące po nim, gdyż zmianie uległyby kolejne hashe, co wychwyciłby każdy, kto korzysta z blokchaina.

Wymagania wstępne

Bloki to temat przyjazny dla nowicjuszy. Aby lepiej zrozumieć tę stronę, zalecamy najpierw zapoznanie się z artykułami o kontach, transakcjach oraz z naszym wprowadzeniem do Ethereum.

Dlaczego bloki?

Aby upewnić się, że wszyscy uczestnicy sieci Ethereum pozostają w zsynchronizowanym stanie i zgadzają się co do dokładnej historii transakcji, grupujemy transakcje w blokach. Oznacza to, że dziesiątki (lub setki) transakcji są zatwierdzane, uzgadniane i synchronizowane jednocześnie.

Diagram pokazujący transakcję w bloku powodującą zmiany stanu Diagram zaadaptowany z Ethereum EVM illustrated (opens in a new tab)

Oddzielając zatwierdzenia, dajemy wszystkim uczestnikom sieci wystarczająco dużo czasu na osiągnięcie konsensusu: nawet jeśli żądania transakcji pojawiają się dziesiątki razy na sekundę, bloki są tworzone i zatwierdzane w Ethereum tylko raz na dwanaście sekund.

Jak działają bloki

Aby zachować historię transakcji, bloki są ściśle uporządkowane (każdy nowy blok zawiera odniesienie do bloku nadrzędnego), podobnie ściśle uporządkowane są transakcje wewnątrz bloków. Poza rzadkimi przypadkami w każdym dowolnym momencie wszyscy uczestnicy sieci uzgadniają dokładną liczbę i historię bloków, pracują również nad tym, aby grupować bieżące żądania transakcji w następnym bloku.

Po złożeniu bloku przez losowo wybrany walidator w sieci jest on rozpowszechniany w pozostałej części sieci; wszystkie węzły dodają ten blok do końca swojego blockchaina, a do utworzenia następnego bloku wybiera się nowy walidator. Dokładny proces składania bloków i proces zatwierdzania/konsensusu jest obecnie określony przez protokół „proof-of-stake” sieci Ethereum.

Protokół proof-of-stake

Proof-of-stake oznacza, że:

  • Węzły walidujące muszą zestakować 32 ETH do kontraktu depozytowego jako zabezpieczenie przed niewłaściwym zachowaniem. Pomaga to chronić sieć, ponieważ udowodniona nieuczciwa aktywność prowadzi do zniszczenia części lub całości tej stawki.
  • W każdym slocie (w odstępie dwunastu sekund) walidator jest losowo wybierany na proponenta bloku. Łączy on transakcje, wykonuje je i określa nowy „stan”. Informacje te zawija w blok i przekazuje innym walidatorom.
  • Inne walidatory, które usłyszą o nowym bloku, ponownie wykonują transakcje, aby upewnić się, że zgadzają się z proponowaną zmianą globalnego stanu. Zakładając, że blok jest prawidłowy, dodają go do własnej bazy danych.
  • Jeśli walidator usłyszy o dwóch sprzecznych blokach dla tego samego slotu, używa swojego algorytmu wyboru forka, aby wybrać ten popierany przez najwięcej zestakowanych ETH.

Więcej o proof-of-stake

Co znajduje się w bloku?

W bloku znajduje się wiele informacji. Na najwyższym poziomie blok zawiera następujące pola:

PoleOpis
slotslot, do którego należy blok
proposer_indexidentyfikator walidatora proponującego blok
parent_roothash poprzedniego bloku
state_rootgłówny hash obiektu stanu
treśćobiekt zawierający kilka pól, opisanych poniżej

Body bloku zawiera kilka własnych pól:

PoleOpis
randao_revealwartość używana do wyboru następnego proponenta bloku
eth1_datainformacja o kontrakcie depozytowym
graffitidowolne dane używane do oznaczania bloków
proposer_slashingslista walidatorów do odcięcia
attester_slashingslista poświadczających do odcięcia
poświadczenialista poświadczeń utworzonych dla poprzednich slotów
depozytylista nowych depozytów do kontraktu depozytowego
voluntary_exitslista walidatorów opuszczających sieć
sync_aggregatepodzbiór walidatorów używanych do obsługi lekkich klientów
execution_payloadtransakcje przekazane od klienta wykonawczego

Pole attestations zawiera listę wszystkich poświadczeń w bloku. Poświadczenia mają swój własny typ danych, który zawiera kilka elementów danych. Każde poświadczenie zawiera:

PoleOpis
aggregation_bitslistę walidatorów, którzy uczestniczyli w tym poświadczeniu
danekontener z wieloma podpolami
podpiszagregowany podpis zestawu walidatorów dla części data

Pole data w poświadczeniu zawiera:

PoleOpis
slotslot, do którego odnosi się poświadczenie
indexindeksy dla poświadczających walidatorów
beacon_block_roothasz główny bloku beacon postrzeganego jako głowica łańcucha
źródłoostatni uzasadniony punkt kontrolny
targetblok graniczny ostatniej epoki

Wykonanie transakcji w execution_payload aktualizuje stan globalny. Wszyscy klienci ponownie wykonują transakcje w execution_payload, aby upewnić się, że nowy stan jest zgodny z tym w polu state_root nowego bloku. W ten sposób klienty mogą stwierdzić, że nowy blok jest ważny i można go bezpiecznie dodać do ich blockchaina. Sam execution_payload jest obiektem z kilkoma polami. Istnieje również execution_payload_header, który zawiera ważne informacje podsumowujące dane wykonania. Te struktury danych są zorganizowane w następujący sposób:

execution_payload_header zawiera następujące pola:

PoleOpis
parent_hashhash bloku nadrzędnego
fee_recipientadres konta do uiszczania opłat transakcyjnych
state_rootgłówny hash dla globalnego stanu po zastosowaniu zmian w tym bloku
receipts_roothasz potwierdzeń transakcji drzewa trie
logs_bloomstruktura danych zawierająca dzienniki zdarzeń
prev_randaowartość używana w losowym wyborze walidatora
block_numbernumer bieżącego bloku
gas_limitmaksymalny gaz dozwolony w tym bloku
gas_usedrzeczywista ilość gazu użytego w tym bloku
timestampczas bloku
extra_datadowolne dodatkowe dane jako surowe bajty
base_fee_per_gaswartość opłaty podstawowej
block_hashhash bloku wykonania
transactions_rootgłówny hash transakcji w ładunku (payload)
withdrawal_rootgłówny hash wypłat w ładunku (payload)

Sam execution_payload zawiera następujące pola (zauważ, że są one identyczne jak w nagłówku, z wyjątkiem tego, że zamiast hasza głównego transakcji zawiera rzeczywistą listę transakcji i informacje o wypłatach):

PoleOpis
parent_hashhash bloku nadrzędnego
fee_recipientadres konta do uiszczania opłat transakcyjnych
state_rootgłówny hash dla globalnego stanu po zastosowaniu zmian w tym bloku
receipts_roothasz potwierdzeń transakcji drzewa trie
logs_bloomstruktura danych zawierająca dzienniki zdarzeń
prev_randaowartość używana w losowym wyborze walidatora
block_numbernumer bieżącego bloku
gas_limitmaksymalny gaz dozwolony w tym bloku
gas_usedrzeczywista ilość gazu użytego w tym bloku
timestampczas bloku
extra_datadowolne dodatkowe dane jako surowe bajty
base_fee_per_gaswartość opłaty podstawowej
block_hashhash bloku wykonania
transakcjelista transakcji do wykonania
wypłatylista obiektów do wypłaty

Lista withdrawals zawiera obiekty withdrawal o następującej strukturze:

PoleOpis
adresadres konta, z którego dokonano wypłaty
amountkwota wypłaty
indexwartość indeksu wypłaty
validatorIndexwartość indeksu walidatora

Czas bloku

Czas bloku odnosi się do czasu oddzielającego bloki. W Ethereum czas jest podzielony na dwunastosekundowe jednostki zwane „slotami”. W każdym slocie wybierany jest pojedynczy walidator do zaproponowania bloku. Zakładając, że wszystkie walidatory są online i w pełni funkcjonalne, w każdym slocie będzie blok, co oznacza, że czas bloku wynosi 12 sekund. Jednakże, od czasu do czasu walidatory mogą być offline, gdy zostaną wezwane do zaproponowania bloku, co oznacza, że sloty mogą być czasami puste.

Implementacja ta różni się od systemów opartych na proof-of-work, w których czasy bloków są probabilistyczne i wyznaczane przez docelową trudność wydobycia protokołu. Średni czas bloku (opens in a new tab) Ethereum jest tego doskonałym przykładem, z którego można jasno wywnioskować przejście z proof-of-work na proof-of-stake na podstawie spójności nowego, 12-sekundowego czasu bloku.

Rozmiar bloku

Ważna uwaga na zakończenie jest taka, że same bloki są ograniczone pod względem rozmiaru. Każdy blok ma docelowy rozmiar 30 milionów gazu, ale rozmiar bloków będzie się zwiększał lub zmniejszał zgodnie z zapotrzebowaniem sieci, aż do limitu bloku wynoszącego 60 milionów gazu (2x docelowy rozmiar bloku). Limit gazu w bloku może być korygowany w górę lub w dół o współczynnik 1/1024 w stosunku do limitu gazu w poprzednim bloku. W wyniku tego walidatorzy mogą zmieniać limit gazu w bloku za pośrednictwem konsensusu. Całkowita ilość gazu zużytego przez wszystkie transakcje w bloku musi być mniejsza niż limit gazu w bloku. Jest to ważne, gdyż gwarantuje, iż bloki nie mogą być dowolnie duże. Gdyby bloki mogły mieć dowolną wielkość, wtedy mniej wydajne, pełne węzły stopniowo przestawałyby nadążać za siecią z powodu wymogów odnośnie do przestrzeni i prędkości. Im większy blok, tym większa moc obliczeniowa jest wymagana do przetworzenia go na czas do następnego slotu. Jest to siła centralizująca, której można przeciwdziałać ograniczając rozmiary bloków.

Dalsza lektura

Znasz jakieś zasoby społeczności, które Ci pomogły? Edytuj tę stronę i dodaj je!

Czy ten artykuł był pomocny?