diff --git a/public/content/translations/pl/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md b/public/content/translations/pl/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md new file mode 100644 index 00000000000..499528f60cb --- /dev/null +++ b/public/content/translations/pl/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md @@ -0,0 +1,195 @@ +--- +title: Definicja tajnego magazynu Web3 +description: "Formalna definicja przechowywania sekretów web3" +lang: pl +sidebarDepth: 2 +--- + +Aby Twoja aplikacja działała na Ethereum, możesz użyć obiektu web3 dostarczonego przez bibliotekę web3.js. Pod maską komunikuje się z lokalnym węzłem za pomocą wywołań RPC. [web3](https://github.com/ethereum/web3.js/) działa z każdym węzłem Ethereum, który udostępnia warstwę RPC. + +`web3` zawiera obiekt `eth` – web3.eth. + +```js +var fs = require("fs") +var recognizer = require("ethereum-keyfile-recognizer") + +fs.readFile("keyfile.json", (err, data) => { + var json = JSON.parse(data) + var result = recognizer(json) +}) + +/** wynik + * [ 'web3', 3 ] plik kluczy web3 (v3) + * [ 'ethersale', undefined ] plik kluczy Ethersale + * null nieprawidłowy plik kluczy + */ +``` + +Ten dokument opisuje **wersję 3** definicji przechowywania sekretów Web3. + +## Definicja {#definition} + +Rzeczywiste kodowanie i dekodowanie pliku pozostaje w dużej mierze niezmienione w stosunku do wersji 1, z wyjątkiem tego, że algorytm kryptograficzny nie jest już na stałe ustawiony na AES-128-CBC (minimalnym wymaganiem jest teraz AES-128-CTR). Większość znaczeń/algorytmów jest podobna do wersji 1, z wyjątkiem `mac`, który jest podany jako SHA3 (keccak-256) konkatenacji drugich od lewej 16 bajtów klucza pochodnego wraz z pełnym `ciphertext`. + +Pliki kluczy tajnych są przechowywane bezpośrednio w `~/.web3/keystore` (dla systemów typu Unix) i `~/AppData/Web3/keystore` (dla Windows). Mogą mieć dowolną nazwę, ale dobrą konwencją jest `.json`, gdzie `` to 128-bitowy identyfikator UUID przypisany do klucza tajnego (zastępstwo dla adresu klucza tajnego, które chroni prywatność). + +Wszystkie takie pliki mają powiązane hasło. Aby uzyskać klucz tajny danego pliku `.json`, najpierw należy uzyskać klucz szyfrowania pliku; odbywa się to poprzez pobranie hasła pliku i przekazanie go przez funkcję wyprowadzania klucza opisaną przez klucz `kdf`. Statyczne i dynamiczne parametry zależne od KDF dla funkcji KDF są opisane w kluczu `kdfparams`. + +PBKDF2 musi być obsługiwany przez wszystkie minimalnie zgodne implementacje, oznaczane jako: + +- `kdf`: `pbkdf2` + +Dla PBKDF2, kdfparams obejmują: + +- `prf`: musi być `hmac-sha256` (może zostać rozszerzony w przyszłości); +- `c`: liczba iteracji; +- `salt`: salt przekazywane do PBKDF; +- `dklen`: długość klucza pochodnego. Musi być >= 32. + +Po uzyskaniu klucza pliku należy go zweryfikować poprzez wyprowadzenie MAC. MAC powinien być obliczany jako hasz SHA3 (keccak-256) tablicy bajtów utworzonej jako konkatenacja drugich od lewej 16 bajtów klucza pochodnego z zawartością klucza `ciphertext`, tzn.: + +```js +KECCAK(DK[16..31] ++ ) +``` + +(gdzie `++` jest operatorem konkatenacji) + +Wartość ta powinna być porównana z zawartością klucza `mac`; jeśli są różne, należy poprosić o alternatywne hasło (lub anulować operację). + +Po zweryfikowaniu klucza pliku, szyfrogram (klucz `ciphertext` w pliku) może zostać odszyfrowany przy użyciu symetrycznego algorytmu szyfrowania określonego przez klucz `cipher` i sparametryzowanego przez klucz `cipherparams`. Jeśli rozmiar klucza pochodnego i rozmiar klucza algorytmu nie pasują do siebie, jako klucz do algorytmu należy użyć uzupełnionych zerami, skrajnych prawych bajtów klucza pochodnego. + +Wszystkie minimalnie zgodne implementacje muszą obsługiwać algorytm AES-128-CTR, oznaczony poprzez: + +- `cipher: aes-128-ctr` + +Ten szyfr przyjmuje następujące parametry, podane jako klucze do klucza cipherparams: + +- `iv`: 128-bitowy wektor inicjalizujący dla szyfru. + +Kluczem do szyfru jest skrajne lewe 16 bajtów klucza pochodnego, tzn. `DK[0..15]` + +Tworzenie/szyfrowanie klucza tajnego powinno być zasadniczo odwrotnością tych instrukcji. Upewnij się, że `uuid`, `salt` i `iv` są rzeczywiście losowe. + +Oprócz pola `version`, które powinno działać jako „twardy” identyfikator wersji, implementacje mogą również używać `minorversion` do śledzenia mniejszych, niezakłócających zmian w formacie. + +## Wektory testowe {#test-vectors} + +Szczegóły: + +- `Address`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b` +- `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67` +- `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6` +- `Password`: `testpassword` +- `Secret`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d` + +### PBKDF2-SHA-256 {#PBKDF2-SHA-256} + +Wektor testowy wykorzystujący `AES-128-CTR` i `PBKDF2-SHA-256`: + +Zawartość pliku `~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json`: + +```json +{ + "crypto": { + "cipher": "aes-128-ctr", + "cipherparams": { + "iv": "6087dab2f9fdbbfaddc31a909735c1e6" + }, + "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46", + "kdf": "pbkdf2", + "kdfparams": { + "c": 262144, + "dklen": 32, + "prf": "hmac-sha256", + "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd" + }, + "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2" + }, + "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", + "version": 3 +} +``` + +**Wartości pośrednie**: + +`Klucz pochodny`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551` +`Treść MAC`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46` +`MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2` +`Klucz szyfru`: `f06d69cdc7da0faffb1008270bca38f5` + +### Scrypt {#scrypt} + +Wektor testowy wykorzystując AES-128-CTR i Scrypt: + +```json +{ + "crypto": { + "cipher": "aes-128-ctr", + "cipherparams": { + "iv": "740770fce12ce862af21264dab25f1da" + }, + "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2", + "kdf": "scrypt", + "kdfparams": { + "dklen": 32, + "n": 262144, + "p": 1, + "r": 8, + "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034" + }, + "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c" + }, + "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", + "version": 3 +} +``` + +**Wartości pośrednie**: + +`Klucz pochodny`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d` +`Treść MAC`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2` +`MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c` +`Klucz szyfru`: `7446f59ecc301d2d79bc3302650d8a5c` + +## Zmiany w stosunku do wersji 1 {#alterations-from-v2} + +Ta wersja naprawia kilka niespójności z wersją 1 opublikowaną [tutaj](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst). W skrócie są to: + +- Wielkość liter jest nieuzasadniona i niespójna (scrypt pisany małymi literami, Kdf pisany z wielkiej i małej litery, MAC pisany wielkimi literami). +- Adres jest niepotrzebny i narusza prywatność. +- `Salt` jest z natury parametrem funkcji wyprowadzania klucza i zasługuje na to, by być z nią kojarzonym, a nie z kryptografią w ogóle. +- _SaltLen_ niepotrzebne (wystarczy wyprowadzić je z Salt). +- Funkcja wyprowadzania klucza jest podana, ale algorytm kryptograficzny jest sztywno określony. +- `Version` jest z natury numeryczna, a jednak jest ciągiem znaków (wersjonowanie strukturalne byłoby możliwe z ciągiem znaków, ale można uznać, że wykracza poza zakres rzadko zmieniającego się formatu pliku konfiguracyjnego). +- `KDF` i `cipher` są pojęciowo rodzeństwem, ale są inaczej zorganizowane. +- `MAC` jest obliczany na podstawie fragmentu danych, który ignoruje białe znaki (!) + +Wprowadzono zmiany w formacie, aby uzyskać następujący plik, funkcjonalnie równoważny z przykładem podanym na poprzednio podlinkowanej stronie: + +```json +{ + "crypto": { + "cipher": "aes-128-cbc", + "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b", + "cipherparams": { + "iv": "16d67ba0ce5a339ff2f07951253e6ba8" + }, + "kdf": "scrypt", + "kdfparams": { + "dklen": 32, + "n": 262144, + "p": 1, + "r": 8, + "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91" + }, + "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd", + "version": 1 + }, + "id": "0498f19a-59db-4d54-ac95-33901b4f1870", + "version": 2 +} +``` + +## Zmiany w stosunku do wersji 2 {#alterations-from-v2} + +Wersja 2 była wczesną implementacją w C++ z wieloma błędami. Wszystkie podstawowe elementy pozostają w niej niezmienione. diff --git a/public/content/translations/pl/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/pl/developers/docs/design-and-ux/dex-design-best-practice/index.md new file mode 100644 index 00000000000..c51e922fa77 --- /dev/null +++ b/public/content/translations/pl/developers/docs/design-and-ux/dex-design-best-practice/index.md @@ -0,0 +1,219 @@ +--- +title: "Najlepsze praktyki projektowania zdecentralizowanej giełdy (DEX)" +description: "Przewodnik wyjaśniający decyzje UX/UI dotyczące wymiany tokenów." +lang: pl +--- + +Od czasu uruchomienia Uniswap w 2018 roku na dziesiątkach różnych łańcuchów uruchomiono setki zdecentralizowanych giełd. +Wiele z nich wprowadziło nowe elementy lub własne modyfikacje, ale interfejs ogólnie pozostał taki sam. + +Jednym z tego powodów jest [prawo Jakoba](https://lawsofux.com/jakobs-law/): + +> Użytkownicy spędzają większość czasu na innych stronach. Oznacza to, że użytkownicy wolą, aby Twoja strona działała w taki sam sposób, jak wszystkie inne strony, które już znają. + +Dzięki wczesnym innowatorom, takim jak Uniswap, Pancakeswap i Sushiswap, użytkownicy DeFi mają wspólne wyobrażenie o tym, jak wygląda DEX. +Z tego powodu pojawia się teraz coś w rodzaju „najlepszej praktyki”. Widzimy, że coraz więcej decyzji projektowych jest standaryzowanych na różnych stronach. Ewolucję giełd DEX można postrzegać jako ogromny przykład testowania na żywo. To, co działało, pozostało, a to, co nie, zostało odrzucone. Nadal jest miejsce na indywidualność, ale istnieją pewne standardy, do których giełda DEX powinna się dostosować. + +Ten artykuł jest podsumowaniem: + +- co należy uwzględnić +- jak sprawić, by było to jak najbardziej użyteczne +- głównych sposobów dostosowywania projektu + +Wszystkie przykładowe makiety zostały stworzone specjalnie na potrzeby tego artykułu, chociaż wszystkie opierają się na prawdziwych projektach. + +Zestaw Figma znajduje się również na dole – możesz go używać i przyspieszyć tworzenie własnych makiet! + +## Podstawowa anatomia giełdy DEX {#basic-anatomy-of-a-dex} + +Interfejs użytkownika zazwyczaj zawiera trzy elementy: + +1. Główny formularz +2. Przycisk +3. Panel szczegółów + +![Ogólny interfejs użytkownika DEX, pokazujący trzy główne elementy](./1.png) + +## Wariacje {#variations} + +Będzie to częsty motyw w tym artykule, ale istnieje wiele różnych sposobów organizacji tych elementów. „Panel szczegółów” może znajdować się: + +- Powyżej przycisku +- Poniżej przycisku +- Ukryty w panelu akordeonowym +- I/lub w oknie modalnym „podglądu” + +N.B. Okno modalne „podglądu” jest opcjonalne, ale jeśli w głównym interfejsie użytkownika wyświetlasz bardzo mało szczegółów, staje się ono niezbędne. + +## Struktura głównego formularza {#structure-of-the-main-form} + +Jest to pole, w którym faktycznie wybierasz, który token chcesz wymienić. Komponent składa się z pola wejściowego i małego przycisku w jednym rzędzie. + +Giełdy DEX zazwyczaj wyświetlają dodatkowe szczegóły w jednym rzędzie powyżej i jednym poniżej, chociaż można to skonfigurować inaczej. + +![Wiersz wejściowy z wierszem szczegółów powyżej i poniżej](./2.png) + +## Wariacje {#variations2} + +Pokazano tu dwie wariacje interfejsu użytkownika: jedną bez obramowań, tworzącą bardzo otwarty projekt, i drugą, w której wiersz wejściowy ma obramowanie, skupiając uwagę na tym elemencie. + +![Dwie wariacje interfejsu użytkownika głównego formularza](./3.png) + +Ta podstawowa struktura pozwala na pokazanie w projekcie **czterech kluczowych informacji**: po jednej w każdym rogu. Jeśli jest tylko jeden górny/dolny wiersz, to są tylko dwa miejsca. + +Podczas ewolucji DeFi uwzględniono tu wiele różnych rzeczy. + +## Kluczowe informacje do uwzględnienia {#key-info-to-include} + +- Saldo w portfelu +- Przycisk Max +- Ekwiwalent w walucie fiducjarnej +- Wpływ na cenę dla „otrzymanej” kwoty + +We wczesnych dniach DeFi często brakowało ekwiwalentu w walucie fiducjarnej. Jeśli tworzysz jakikolwiek projekt Web3, niezbędne jest pokazanie ekwiwalentu w walucie fiducjarnej. Użytkownicy nadal myślą w kategoriach lokalnych walut, więc aby dopasować się do rzeczywistych modeli myślowych, należy to uwzględnić. + +W drugim polu (tym, w którym wybierasz token, na który wymieniasz) możesz również uwzględnić wpływ na cenę obok kwoty w walucie fiducjarnej, obliczając różnicę między kwotą wejściową a szacowaną kwotą wyjściową. Jest to dość przydatny szczegół do uwzględnienia. + +Przyciski procentowe (np. 25%, 50%, 75%) mogą być użyteczną funkcją, ale zajmują więcej miejsca, dodają więcej wezwań do działania i zwiększają obciążenie psychiczne. To samo dotyczy suwaków procentowych. Niektóre z tych decyzji dotyczących interfejsu użytkownika będą zależeć od Twojej marki i typu użytkownika. + +Dodatkowe szczegóły mogą być pokazane poniżej głównego formularza. Ponieważ tego typu informacje są przeznaczone głównie dla zaawansowanych użytkowników, sensowne jest, aby: + +- utrzymać je na jak najbardziej minimalnym poziomie lub; +- ukryć je w panelu akordeonowym + +![Szczegóły pokazane w rogach tego głównego formularza](./4.png) + +## Dodatkowe informacje do uwzględnienia {#extra-info-to-include} + +- Cenę tokenów +- Poślizg +- Minimalna otrzymana kwota +- Oczekiwana kwota +- Wpływ na cenę +- Szacowany koszt gazu +- Inne opłaty +- Routing zleceń + +Niewątpliwie niektóre z tych szczegółów mogą być opcjonalne. + +Routing zleceń jest interesujący, ale dla większości użytkowników nie robi dużej różnicy. + +Niektóre inne szczegóły to po prostu powtórzenie tego samego na różne sposoby. Na przykład „minimalna otrzymana kwota” i „poślizg” to dwie strony tego samego medalu. Jeśli masz ustawiony poślizg na 1%, to minimalna kwota, jaką możesz otrzymać = oczekiwana kwota - 1%. Niektóre interfejsy użytkownika pokażą oczekiwaną kwotę, minimalną kwotę i poślizg… Co jest przydatne, ale być może to przesada. + +Większość użytkowników i tak zostawi domyślny poślizg. + +„Wpływ na cenę” jest często pokazywany w nawiasach obok ekwiwalentu w walucie fiducjarnej w polu „do”. To świetny szczegół UX do dodania, ale jeśli jest pokazany tutaj, czy naprawdę musi być pokazany ponownie poniżej? A potem znowu na ekranie podglądu? + +Wielu użytkowników (szczególnie tych wymieniających małe kwoty) nie będzie przejmować się tymi szczegółami; po prostu wpiszą liczbę i klikną „wymień”. + +![Niektóre szczegóły pokazują to samo](./5.png) + +To, jakie dokładnie szczegóły są pokazywane, zależeć będzie od Twoich odbiorców i od tego, jakie odczucia ma wywoływać aplikacja. + +Jeśli uwzględnisz tolerancję poślizgu w panelu szczegółów, powinieneś również umożliwić jej edycję bezpośrednio stąd. To dobry przykład „akceleratora”; zgrabna sztuczka UX, która może przyspieszyć przepływy pracy doświadczonych użytkowników, nie wpływając na ogólną użyteczność aplikacji. + +![Poślizg można kontrolować z panelu szczegółów](./6.png) + +Dobrym pomysłem jest dokładne przemyślenie nie tylko jednej konkretnej informacji na jednym ekranie, ale całego przepływu: Wprowadzanie liczb w głównym formularzu → Skanowanie szczegółów → Kliknięcie ekranu podglądu (jeśli masz ekran podglądu). +Czy panel szczegółów powinien być widoczny przez cały czas, czy użytkownik musi go kliknąć, aby go rozwinąć? +Czy powinieneś tworzyć tarcie, dodając ekran podglądu? Zmusza to użytkownika do zwolnienia i przemyślenia swojej transakcji, co może być przydatne. Ale czy chcą znowu widzieć te same informacje? Co jest dla nich najbardziej przydatne w tym momencie? + +## Opcje projektowe {#design-options} + +Jak wspomniano, wiele z tego sprowadza się do Twojego osobistego stylu +Kim jest Twój użytkownik? +Jaka jest Twoja marka? +Czy chcesz interfejsu „pro” pokazującego każdy szczegół, czy chcesz być minimalistą? +Nawet jeśli celujesz w zaawansowanych użytkowników, którzy chcą wszystkich możliwych informacji, powinieneś pamiętać o mądrych słowach Alana Coopera: + +> Niezależnie od tego, jak piękny i fajny jest Twój interfejs, byłoby lepiej, gdyby było go mniej. + +### Struktura {#structure} + +- tokeny po lewej lub tokeny po prawej stronie +- 2 rzędy lub 3 +- szczegóły nad lub pod przyciskiem +- szczegóły rozwinięte, zminimalizowane lub niepokazane + +### Styl komponentu {#component-style} + +- pusty +- obramowany +- wypełniony + +Z czysto UX-owego punktu widzenia, styl interfejsu użytkownika ma mniejsze znaczenie, niż myślisz. Trendy wizualne przychodzą i odchodzą cyklicznie, a wiele preferencji jest subiektywnych. + +Najłatwiejszym sposobem, aby to wyczuć – i pomyśleć o różnych konfiguracjach – jest przyjrzenie się kilku przykładom, a następnie samodzielne poeksperymentowanie. + +Dołączony zestaw Figma zawiera puste, obramowane i wypełnione komponenty. + +Spójrz na poniższe przykłady, aby zobaczyć różne sposoby, w jakie możesz to wszystko połączyć: + +![3 rzędy w stylu wypełnionym](./7.png) + +![3 rzędy w stylu obramowanym](./8.png) + +![2 rzędy w stylu pustym](./9.png) + +![3 rzędy w stylu obramowanym, z panelem szczegółów](./10.png) + +![3 rzędy z wierszem wejściowym w stylu obramowanym](./11.png) + +![2 rzędy w stylu wypełnionym](./12.png) + +## Ale po której stronie powinien znaleźć się token? {#but-which-side-should-the-token-go-on} + +Konkluzja jest taka, że prawdopodobnie nie ma to większego wpływu na użyteczność. Jest jednak kilka rzeczy, o których należy pamiętać, a które mogą Cię skłonić w jedną lub drugą stronę. + +Dość interesujące jest obserwowanie, jak moda zmienia się z czasem. Początkowo Uniswap miał token po lewej stronie, ale od tego czasu przeniósł go na prawo. Sushiswap również dokonał tej zmiany podczas aktualizacji projektu. Większość, ale nie wszystkie, protokoły poszły w ich ślady. + +Zgodnie z konwencją finansową, symbol waluty tradycyjnie umieszcza się przed liczbą, np. $50, €50, £50, ale _mówimy_ 50 dolarów, 50 euro, 50 funtów. + +Dla ogólnego użytkownika - zwłaszcza kogoś, kto czyta od lewej do prawej, od góry do dołu - token po prawej stronie prawdopodobnie wydaje się bardziej naturalny. + +![Interfejs użytkownika z tokenami po lewej stronie](./13.png) + +Umieszczenie tokena po lewej stronie, a wszystkich liczb po prawej, wygląda przyjemnie symetrycznie, co jest plusem, ale ten układ ma też wadę. + +Prawo bliskości mówi, że elementy, które są blisko siebie, są postrzegane jako powiązane. W związku z tym chcemy umieszczać powiązane elementy obok siebie. Saldo tokena jest bezpośrednio związane z samym tokenem i zmieni się za każdym razem, gdy zostanie wybrany nowy token. Dlatego ma nieco więcej sensu, aby saldo tokena znajdowało się obok przycisku wyboru tokena. Można by go przenieść pod token, ale to psuje symetrię układu. + +Ostatecznie obie opcje mają swoje plusy i minusy, ale interesujące jest to, jak trend wydaje się zmierzać w kierunku tokena po prawej stronie. + +## Zachowanie przycisku {#button-behavior} + +Nie twórz osobnego przycisku do zatwierdzania. Nie twórz też osobnego kliknięcia do zatwierdzania. Użytkownik chce dokonać wymiany (Swap), więc po prostu umieść napis „wymień” na przycisku i zainicjuj zatwierdzenie jako pierwszy krok. Okno modalne może pokazywać postęp za pomocą steppera lub prostego powiadomienia „transakcja 1 z 2 – zatwierdzanie”. + +![Interfejs użytkownika z osobnymi przyciskami do zatwierdzania i wymiany](./14.png) + +![Interfejs użytkownika z jednym przyciskiem z napisem „zatwierdź”](./15.png) + +### Przycisk jako pomoc kontekstowa {#button-as-contextual-help} + +Przycisk może pełnić podwójną funkcję jako alert! + +Jest to w rzeczywistości dość nietypowy wzorzec projektowy poza Web3, ale stał się standardem w jego obrębie. To dobra innowacja, ponieważ oszczędza miejsce i utrzymuje skupienie uwagi. + +Jeśli główna akcja – WYMIANA (SWAP) – jest niedostępna z powodu błędu, przyczyna może być wyjaśniona za pomocą przycisku, np.: + +- przełącz sieć +- połącz portfel +- różne błędy + +Przycisk może być również **zmapowany do akcji**, która musi zostać wykonana. Na przykład, jeśli użytkownik nie może dokonać wymiany, ponieważ jest w niewłaściwej sieci, przycisk powinien mieć napis „przełącz na Ethereum”, a gdy użytkownik kliknie przycisk, powinien przełączyć sieć na Ethereum. To znacznie przyspiesza przepływ pracy użytkownika. + +![Kluczowe akcje inicjowane z głównego CTA](./16.png) + +![Komunikat o błędzie pokazany w głównym CTA](./17.png) + +## Zbuduj własny za pomocą tego pliku Figma {#build-your-own-with-this-figma-file} + +Dzięki ciężkiej pracy wielu protokołów projektowanie giełd DEX znacznie się poprawiło. Wiemy, jakich informacji potrzebuje użytkownik, jak powinniśmy je pokazywać i jak sprawić, by przepływ był jak najbardziej płynny. +Mam nadzieję, że ten artykuł stanowi solidny przegląd zasad UX. + +Jeśli chcesz poeksperymentować, możesz skorzystać z zestawu makiet Figma. Jest tak prosty, jak to tylko możliwe, ale ma wystarczającą elastyczność, aby budować podstawową strukturę na różne sposoby. + +[Zestaw makiet Figma](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit) + +DeFi będzie nadal ewoluować i zawsze jest miejsce na ulepszenia. + +Powodzenia! diff --git a/public/content/translations/pl/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/pl/developers/docs/design-and-ux/heuristics-for-web3/index.md new file mode 100644 index 00000000000..f2450dd5979 --- /dev/null +++ b/public/content/translations/pl/developers/docs/design-and-ux/heuristics-for-web3/index.md @@ -0,0 +1,138 @@ +--- +title: 7 heurystyk dla projektowania interfejsu Web3 +description: "Zasady poprawiające użyteczność Web3" +lang: pl +--- + +Heurystyki użyteczności to ogólne „praktyczne zasady”, których możesz użyć do pomiaru użyteczności swojej witryny. +Przedstawione tutaj 7 heurystyk jest specjalnie dostosowanych do Web3 i powinno się je stosować wraz z [10 ogólnymi zasadami projektowania interakcji](https://www.nngroup.com/articles/ten-usability-heuristics/) Jakoba Nielsena. + +## Siedem heurystyk użyteczności dla web3 {#seven-usability-heuristics-for-web3} + +1. Informacja zwrotna następuje po akcji +2. Bezpieczeństwo i zaufanie +3. Najważniejsze informacje są oczywiste +4. Zrozumiała terminologia +5. Akcje są jak najkrótsze +6. Połączenia sieciowe są widoczne i elastyczne +7. Kontrola z poziomu aplikacji, a nie portfela + +## Definicje i przykłady {#definitions-and-examples} + +### 1. Informacja zwrotna następuje po akcji {#feedback-follows-action} + +**Powinno być oczywiste, kiedy coś się wydarzyło lub dzieje się.** + +Użytkownicy decydują o swoich następnych krokach na podstawie wyników swoich poprzednich kroków. Dlatego ważne jest, aby byli na bieżąco informowani o stanie systemu. Jest to szczególnie ważne w Web3, ponieważ zatwierdzenie transakcji w łańcuchu bloków może czasami zająć trochę czasu. Jeśli nie ma informacji zwrotnej informującej ich, że mają czekać, użytkownicy nie są pewni, czy cokolwiek się wydarzyło. + +**Wskazówki:** + +- Informuj użytkownika za pomocą wiadomości, powiadomień i innych alertów. +- Wyraźnie komunikuj czasy oczekiwania. +- Jeśli akcja ma zająć więcej niż kilka sekund, uspokój użytkownika za pomocą licznika czasu lub animacji, aby poczuł, że coś się dzieje. +- Jeśli proces składa się z wielu kroków, pokaż każdy krok. + +**Przykład:** +Pokazanie każdego kroku związanego z transakcją pomaga użytkownikom dowiedzieć się, na jakim etapie procesu się znajdują. Odpowiednie ikony informują użytkownika o stanie jego działań. + +![Informowanie użytkownika o każdym kroku podczas wymiany tokenów](./Image1.png) + +### 2. Bezpieczeństwo i zaufanie są wbudowane {#security-and-trust-are-backed-in} + +Bezpieczeństwo powinno być traktowane priorytetowo i należy to podkreślać użytkownikowi. +Ludzie bardzo dbają o swoje dane. Bezpieczeństwo jest często główną troską użytkowników, więc powinno być brane pod uwagę na wszystkich poziomach projektowania. Zawsze powinieneś starać się zdobyć zaufanie swoich użytkowników, ale sposób, w jaki to robisz, może oznaczać różne rzeczy w różnych aplikacjach. Nie powinno to być coś, o czym myśli się na końcu, ale powinno być świadomie projektowane na każdym etapie. Buduj zaufanie w całym doświadczeniu użytkownika, włączając w to kanały społecznościowe i dokumentację, a także ostateczny interfejs użytkownika. Kwestie takie jak poziom decentralizacji, status multi-sig skarbca i to, czy tożsamość zespołu jest publiczna, wszystko to wpływa na zaufanie użytkowników. + +**Wskazówki:** + +- Z dumą wymieniaj swoje audyty +- Uzyskaj wiele audytów +- Reklamuj wszelkie zaprojektowane przez siebie funkcje bezpieczeństwa +- Podkreślaj możliwe zagrożenia, w tym te związane z integracjami bazowymi +- Komunikuj złożoność strategii +- Rozważ kwestie niezwiązane z interfejsem użytkownika, które mogą wpływać na postrzeganie bezpieczeństwa przez użytkowników + +**Przykład:** +Umieść swoje audyty w stopce, w widocznym rozmiarze. + +![Audyty, do których odniesiono się w stopce strony internetowej](./Image2.png) + +### 3. Najważniejsze informacje są oczywiste {#the-most-important-info-is-obvious} + +W przypadku złożonych systemów pokazuj tylko najistotniejsze dane. Określ, co jest najważniejsze, i nadaj priorytet wyświetlaniu tych informacji. +Zbyt wiele informacji jest przytłaczające, a użytkownicy zazwyczaj opierają się na jednej informacji przy podejmowaniu decyzji. W DeFi prawdopodobnie będzie to APR w aplikacjach do generowania zysków i LTV w aplikacjach pożyczkowych. + +**Wskazówki:** + +- Badania użytkowników pozwolą odkryć najważniejszą metrykę +- Kluczowe informacje przedstaw w dużym rozmiarze, a pozostałe szczegóły w małym i dyskretnym. +- Ludzie nie czytają, oni skanują wzrokiem; upewnij się, że Twój projekt można łatwo przeskanować wzrokiem. + +**Przykład:** duże, kolorowe tokeny są łatwe do znalezienia podczas skanowania wzrokiem. Wartość APR jest duża i podświetlona kolorem akcentującym. + +![Token i APR są łatwe do znalezienia](./Image3.png) + +### 4. Zrozumiała terminologia {#clear-terminology} + +Terminologia powinna być zrozumiała i odpowiednia. +Żargon techniczny może być ogromną przeszkodą, ponieważ wymaga zbudowania zupełnie nowego modelu myślowego. Użytkownicy nie są w stanie odnieść projektu do słów, zwrotów i pojęć, które już znają. Wszystko wydaje się mylące i nieznane, a do tego dochodzi stroma krzywa uczenia się, zanim w ogóle będą mogli spróbować z tego skorzystać. Użytkownik może podejść do DeFi, chcąc zaoszczędzić trochę pieniędzy, a to, co znajduje, to: Mining, farming, staking, emisje, łapówki, skarbce, schowki, veTokeny, vesting, epoki, zdecentralizowane algorytmy, płynność należąca do protokołu... +Staraj się używać prostych terminów, które będą zrozumiałe dla jak najszerszej grupy osób. Nie wymyślaj zupełnie nowych terminów tylko na potrzeby swojego projektu. + +**Wskazówki:** + +- Używaj prostej i spójnej terminologii +- W miarę możliwości używaj istniejącego języka +- Nie wymyślaj własnych terminów +- Postępuj zgodnie z pojawiającymi się konwencjami +- W miarę możliwości edukuj użytkowników + +**Przykład:** +„Twoje nagrody” to szeroko rozumiane, neutralne pojęcie, a nie nowe słowo wymyślone na potrzeby tego projektu. Nagrody są wyrażone w USD, aby pasowały do rzeczywistych modeli myślowych, nawet jeśli same nagrody są w innym tokenie. + +![Nagrody w tokenach, wyświetlane w dol. amerykańskich](./Image4.png) + +### 5. Akcje są jak najkrótsze {#actions-are-as-short-as-possible} + +Przyspiesz interakcje użytkownika, grupując pod-akcje. +Można to zrobić na poziomie inteligentnego kontraktu, jak również w interfejsie użytkownika. Użytkownik nie powinien musieć przechodzić z jednej części systemu do drugiej – ani całkowicie opuszczać systemu – aby wykonać typową akcję. + +**Wskazówki:** + +- Łącz „Zatwierdź” z innymi akcjami, jeśli to możliwe +- Grupuj kroki podpisywania tak blisko siebie, jak to możliwe + +**Przykład:** Połączenie „dodaj płynność” i „stake” jest prostym przykładem akceleratora, który oszczędza czas i gaz użytkownika. + +![Modal pokazujący przełącznik do łączenia akcji wpłaty i stakowania](./Image5.png) + +### 6. Połączenia sieciowe są widoczne i elastyczne {#network-connections-are-visible-and-flexible} + +Informuj użytkownika, z którą siecią jest połączony, i zapewnij przejrzyste skróty do zmiany sieci. +Jest to szczególnie ważne w aplikacjach wielołańcuchowych. Główne funkcje aplikacji powinny być nadal widoczne po rozłączeniu lub połączeniu z nieobsługiwaną siecią. + +**Wskazówki:** + +- Pokaż jak najwięcej z aplikacji, gdy jesteś rozłączony +- Pokaż, z którą siecią użytkownik jest aktualnie połączony +- Nie zmuszaj użytkownika do przechodzenia do portfela w celu zmiany sieci +- Jeśli aplikacja wymaga od użytkownika zmiany sieci, wywołaj akcję z głównego wezwania do działania +- Jeśli aplikacja zawiera rynki lub skarbce dla wielu sieci, jasno określ, który zestaw użytkownik aktualnie przegląda + +**Przykład:** Pokaż użytkownikowi, z którą siecią jest połączony, i pozwól mu ją zmienić na pasku aplikacji. + +![Przycisk rozwijany pokazujący podłączoną sieć](./Image6.png) + +### 7. Kontrola z poziomu aplikacji, a nie portfela {#control-from-the-app-not-the-wallet} + +Interfejs użytkownika powinien informować użytkownika o wszystkim, co musi wiedzieć, i dawać mu kontrolę nad wszystkim, co musi zrobić. +W Web3 istnieją akcje, które podejmujesz w interfejsie użytkownika, i akcje, które podejmujesz w portfelu. Zazwyczaj inicjujesz akcję w interfejsie użytkownika, a następnie potwierdzasz ją w portfelu. Użytkownicy mogą czuć się niekomfortowo, jeśli te dwa wątki nie są starannie zintegrowane. + +**Wskazówki:** + +- Komunikuj stan systemu za pomocą informacji zwrotnych w interfejsie użytkownika +- Prowadź rejestr ich historii +- Udostępniaj linki do eksploratorów bloków dla starych transakcji +- Udostępnij skróty do zmiany sieci. + +**Przykład:** Dyskretny kontener pokazuje użytkownikowi, jakie odpowiednie tokeny ma w swoim portfelu, a główne wezwanie do działania zapewnia skrót do zmiany sieci. + +![Główne wezwanie do działania skłania użytkownika do zmiany sieci](./Image7.png) diff --git a/public/content/translations/pl/developers/docs/design-and-ux/index.md b/public/content/translations/pl/developers/docs/design-and-ux/index.md new file mode 100644 index 00000000000..5ea240d171a --- /dev/null +++ b/public/content/translations/pl/developers/docs/design-and-ux/index.md @@ -0,0 +1,86 @@ +--- +title: Design i UX w web3 +description: "Wprowadzenie do projektowania UX i badań w przestrzeni web3 i Ethereum" +lang: pl +--- + +Dopiero zaczynasz projektować z Ethereum? To odpowiednie miejsce dla Ciebie. Społeczność Ethereum przygotowała zasoby, które wprowadzą Cię w podstawy projektowania i badań w web3. Poznasz podstawowe pojęcia, które mogą różnić się od innych projektów aplikacji, które znasz. + +Potrzebujesz najpierw bardziej podstawowej wiedzy o web3? Sprawdź [**Centrum Wiedzy**](/learn/). + +## Zacznij od badań użytkowników {#start-with-user-research} + +Skuteczne projektowanie to coś więcej niż tworzenie atrakcyjnych wizualnie interfejsów użytkownika. Wymaga ono głębokiego zrozumienia potrzeb, celów i czynników motywujących użytkownika. Dlatego gorąco polecamy, aby wszyscy projektanci przyjęli proces projektowy, taki jak [**proces podwójnego diamentu**](https://en.wikipedia.org/wiki/Double_Diamond_\(design_process_model\)), w celu zapewnienia, że ich praca jest przemyślana i celowa. + +- [Web3 potrzebuje więcej badaczy i projektantów UX](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - Przegląd obecnej dojrzałości projektowej +- [Prosty przewodnik po badaniach UX w web3](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - Prosty przewodnik, jak prowadzić badania +- [Jak podchodzić do decyzji UX w Web3](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - Krótki przegląd badań ilościowych i jakościowych oraz różnic między nimi (wideo, 6 min) +- [Bycie badaczem UX w web3](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - Osobiste spojrzenie na to, jak to jest być badaczem UX w web3 + +## Badania w web3 {#research-in-web3} + +To jest wybrana lista badań użytkowników przeprowadzonych w web3, która może pomóc w podejmowaniu decyzji projektowych i produktowych lub posłużyć jako inspiracja do przeprowadzenia własnego badania. + +| Obszar zainteresowania | Nazwa | +| :----------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Wprowadzanie do krypto | [The Reown Pulse 2024: Crypto Consumer Sentiment & Usage](https://reown.com/blog/unveiling-walletconnects-consumer-crypto-report) | +| Wprowadzanie do krypto | [CRADL: UX w kryptowalutach](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) | +| Wprowadzanie do krypto | [CRADL: Wprowadzanie do kryptowalut](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) | +| Wprowadzanie do krypto | [Raport UX Bitcoin](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) | +| Wprowadzanie do krypto | [ConSensys: Stan postrzegania Web3 na świecie w 2023 r.](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) | +| Wprowadzanie do krypto | [NEAR: Przyspieszanie drogi do adopcji](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) | +| Staking | [OpenUX: UX operatora węzła Rocket Pool](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) | +| Staking | [Staking: Kluczowe trendy, wnioski i prognozy - Eth Staker](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) | +| Staking | [Staking w wielu aplikacjach](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20\(MAS\)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) | +| DAO | [Aktualizacja badań DAO 2022: Czego potrzebują twórcy DAO?](https://blog.aragon.org/2022-dao-research-update/) | +| DeFi | [Pule ubezpieczeniowe](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) | +| DeFi | [ConSensys: Raport z badań użytkowników DeFi 2022](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) | +| Metawersum | [Metawersum: Raport z badań użytkowników](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) | +| Metawersum | [Na safari: Badanie użytkowników w metawersum](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (wideo, 27 min) | + +## Projektowanie dla web3 {#design-for-web3} + +- [Podręcznik projektowania UX w Web3](https://web3ux.design/) - Praktyczny przewodnik po projektowaniu aplikacji Web3 +- [Zasady projektowania w Web3](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - Zbiór zasad UX dla dapek opartych na blockchainie +- [Zasady projektowania blockchain](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - Wnioski wyciągnięte przez zespół projektantów blockchain w IBM +- [Neueux.com](https://neueux.com/apps) - Biblioteka UI przepływów użytkowników z różnorodnymi opcjami filtrowania +- [Kryzys użyteczności Web3: Co MUSISZ wiedzieć!](https://www.youtube.com/watch?v=oBSXT_6YDzg) - Dyskusja panelowa na temat pułapek budowania projektów skoncentrowanych na deweloperach (wideo, 34 min) + +## Pierwsze kroki {#getting-started} + +- [Heurystyki dla Web3](/developers/docs/design-and-ux/heuristics-for-web3/) - 7 heurystyk projektowania interfejsu Web3 +- [Dobre praktyki projektowania DEX](/developers/docs/design-and-ux/dex-design-best-practice/) - Przewodnik po projektowaniu zdecentralizowanych giełd + +## Studia przypadków projektowania w Web3 {#design-case-studies} + +- [Deep Work Studio](https://www.deepwork.studio/case-studies) +- [Sprzedaż NFT na OpenSea](https://builtformars.com/case-studies/opensea) +- [Analiza UX portfela: jak portfele muszą się zmienić](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (wideo, 20 min) + +## Nagrody za projekty {#bounties} + +- [Dework](https://app.dework.xyz/bounties) +- [Hackathony Buildbox](https://app.buidlbox.io/) +- [Hackathony ETHGlobal](https://ethglobal.com/) + +## DAO projektowe i społeczności {#design-daos-and-communities} + +Zaangażuj się w profesjonalne organizacje kierowane przez społeczność lub dołącz do grup projektowych, aby dyskutować z innymi członkami na tematy i trendy związane z projektowaniem i badaniami. + +- [Vectordao.com](https://vectordao.com/) +- [Deepwork.studio](https://www.deepwork.studio/) +- [We3.co](https://we3.co/) +- [Openux.xyz](https://openux.xyz/) + +## Systemy projektowe i inne zasoby projektowe {#design-systems-and-resources} + +- [System projektowy Optimism](https://www.figma.com/@optimism) (Figma) +- [System projektowy Ethereum.org](https://www.figma.com/@ethdotorg) (Figma) +- [Finity, system projektowy od Polygon](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma) +- [System projektowy Kleros](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma) +- [System projektowy Safe](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma) +- [System projektowy ENS](https://thorin.ens.domains/) +- [System projektowy Mirror](https://degen-xyz.vercel.app/) + +**Artykuły i projekty wymienione na tej stronie nie stanowią oficjalnego poparcia** i są udostępniane wyłącznie w celach informacyjnych. +Dodajemy linki na tę stronę w oparciu o kryteria zawarte w naszej [polityce umieszczania na liście](/contributing/design/adding-design-resources). Jeśli chcesz, abyśmy dodali projekt/artykuł, edytuj tę stronę na [GitHubie](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md). diff --git a/public/content/translations/pl/developers/docs/development-networks/index.md b/public/content/translations/pl/developers/docs/development-networks/index.md index 14b2c647c78..c6e43f88e41 100644 --- a/public/content/translations/pl/developers/docs/development-networks/index.md +++ b/public/content/translations/pl/developers/docs/development-networks/index.md @@ -1,6 +1,6 @@ --- -title: Frameworki programistyczne -description: Przegląd sieci programistycznych i narzędzi dostępnych do tworzenia aplikacji Ethereum. +title: Sieci programistyczne +description: "Przegląd sieci programistycznych i narzędzi dostępnych do tworzenia aplikacji Ethereum." lang: pl --- @@ -8,9 +8,9 @@ Podczas tworzenia aplikacji Ethereum z inteligentnymi kontraktami, chcesz urucho Podobnie jak możesz uruchomić lokalny serwer na komputerze w celu tworzenia stron internetowych, możesz użyć sieci programistycznej, aby utworzyć lokalną instancję blockchain do przetestowania aplikacji zdecentralizowanej. Te sieci deweloperskie Ethereum zapewniają funkcje, które umożliwiają znacznie szybszą iterację niż publiczne sieci testowe (np. nie musisz zajmować się nabyciem ETH z sieci testowej). -## Warunki wstępne {#prerequisites} +## Wymagania wstępne {#prerequisites} -Powinieneś zrozumieć [podstawy stosu Ethereum](/developers/docs/ethereum-stack/) i [sieci Ethereum](/developers/docs/networks/) przed zagłębieniem się w sieci programistycznej. +Powinieneś zrozumieć [podstawy stosu Ethereum](/developers/docs/ethereum-stack/) i [sieci Ethereum](/developers/docs/networks/), zanim zagłębisz się w sieci programistyczne. ## Czym jest sieć programistyczna? {#what-is-a-development-network} @@ -18,38 +18,54 @@ Sieci programistyczne są zasadniczo klientami Ethereum (implementacje Ethereum) **Dlaczego nie uruchomić standardowego węzła Ethereum lokalnie?** -_Mógłbyś_ [uruchomić węzeł](/developers/docs/nodes-and-clients/#running-your-own-node) (taki jak Geth, OpenEthereum lub Nethermind), ale ponieważ sieci programistyczne są budowane w celach programistycznych, często są wyposażone w mnóstwo wygodnych funkcji: +_Mógłbyś_ [uruchomić węzeł](/developers/docs/nodes-and-clients/#running-your-own-node), ale ponieważ sieci programistyczne są tworzone specjalnie na potrzeby rozwoju, często są wyposażone w wygodne funkcje, takie jak: -- Deterministyczne zasilanie blockchaina danymi (np. konta z saldami ETH) -- Natychmiastowe wydobywanie bloków z każdą otrzymaną transakcją, w kolejności i bez opóźnień +- Deterministyczne zasilanie lokalnego blockchaina danymi (np. konta z saldami ETH) +- Natychmiastowe tworzenie bloków z każdą otrzymaną transakcją, w kolejności i bez opóźnień - Ulepszone funkcje debugowania i rejestrowania ## Dostępne narzędzia {#available-projects} -**Uwaga**: większość [frameworków programistycznych](/developers/docs/frameworks/) zawiera wbudowaną sieć programistyczną. Zalecamy zaczynać od frameworka, aby [skonfigurować lokalne środowisko programistyczne](/developers/local-environment/). +**Uwaga**: Większość [frameworków programistycznych](/developers/docs/frameworks/) zawiera wbudowaną sieć programistyczną. Zalecamy zacząć od frameworka, aby [skonfigurować lokalne środowisko programistyczne](/developers/local-environment/). ### Sieć Hardhat {#hardhat-network} -Lokalna sieć Ethereum zaprojektowana pod kątem [rac programistycznych. Pozwala na wdrożenie kontraktów, wykonanie testów i debugowanie kodu +Lokalna sieć Ethereum zaprojektowana pod kątem prac programistycznych. Pozwala na wdrożenie kontraktów, wykonanie testów i debugowanie kodu. Sieć Hardhat jest wbudowana w Hardhat, środowisko programistyczne Ethereum dla profesjonalistów. - [Strona internetowa](https://hardhat.org/) -- [GitHub](https://github.com/nomiclabs/hardhat) +- [GitHub](https://github.com/NomicFoundation/hardhat) + +### Lokalne łańcuchy śledzące {#local-beacon-chains} + +Niektóre klienty konsensusu mają wbudowane narzędzia do tworzenia lokalnych łańcuchów śledzących do celów testowych. Instrukcje dla Lighthouse, Nimbus i Lodestar są dostępne: + +- [Lokalna sieć testowa z wykorzystaniem Lodestar](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/) +- [Lokalna sieć testowa z wykorzystaniem Lighthouse](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets) ### Publiczne łańcuchy testowe Ethereum {#public-beacon-testchains} -Istnieją również dwie publiczne implementacje testowe Ethereum: Sepolia i Hoodi. Sepolia to zalecana standardowa sieć testowa do tworzenia aplikacji, z zamkniętym zestawem walidatorów zapewniającym szybką synchronizację. Hoodi to sieć testowa do walidacji i stakingu, która wykorzystuje otwarty zestaw walidatorów i potencjalnie umożliwia walidację każdemu. +Istnieją również dwie publiczne implementacje testowe Ethereum: Sepolia i Hoodi. Rekomendowana sieć testowa z długoterminowym wsparciem to Hoodi, na której każdy może za darmo walidować. Sepolia korzysta z uprawnionego zestawu walidatorów, w taki znaczeniu, że nie ma ogólnego dostępu do nowych walidatorów na tej sieci testowej. + +- [Hoodi Staking Launchpad](https://hoodi.launchpad.ethereum.org/) + +### Pakiet Kurtosis Ethereum {#kurtosis} + +Kurtosis to system kompilacji dla wielokontenerowych środowisk testowych, który umożliwia deweloperom lokalne uruchamianie odtwarzalnych instancji sieci blockchain. + +Pakiet Ethereum Kurtosis może być użyty w celu szybkiego utworzenia parametryzowalnej, wysoce skalowalnej i prywatnej sieci testowej Ethereum za pomocą Docker lub Kubernetes. Pakiet posiada wsparcie dla wszystkich głównych klientów warstw egzekucyjnych (EL) oraz warstw konsensusu (CL). Kurtosis z gracją obsługuje wszystkie lokalne mapowania portów i połączenia z usługami dla sieci reprezentacyjnej, która ma być użyta w procesie walidacji i testowania przepływów pracy w odniesieniu do kluczowej infrastruktury Ethereum. -- [Launchpad stakingu Hoodi](https://hoodi.launchpad.ethereum.org/en/) -- [Strona internetowa Sepolia](https://sepolia.dev/) -- [Strona internetowa Hoodi](https://hoodi.ethpandaops.io/) +- [Pakiet sieci Ethereum](https://github.com/kurtosis-tech/ethereum-package) +- [Strona internetowa](https://www.kurtosis.com/) +- [GitHub](https://github.com/kurtosis-tech/kurtosis) +- [Dokumentacja](https://docs.kurtosis.com/) ## Dalsza lektura {#further-reading} -_Znasz jakieś zasoby społeczności, które Ci pomogły? Wyedytuj tę stronę i dodaj je!_ +_Znasz jakieś zasoby społeczności, które Ci pomogły? Edytuj tę stronę i dodaj je!_ ## Powiązane tematy {#related-topics} -- [Frameworki programistyczne](/developers/docs/frameworks/) -- [Konfigurowanie lokalnego środowiska programistycznego](/developers/local-environment/) +- [Frameworki deweloperskie](/developers/docs/frameworks/) +- [Skonfiguruj lokalne środowisko programistyczne](/developers/local-environment/) diff --git a/public/content/translations/pl/developers/docs/ethereum-stack/index.md b/public/content/translations/pl/developers/docs/ethereum-stack/index.md index 6d9d91792e1..149d293c3d1 100644 --- a/public/content/translations/pl/developers/docs/ethereum-stack/index.md +++ b/public/content/translations/pl/developers/docs/ethereum-stack/index.md @@ -1,59 +1,61 @@ --- title: Wprowadzenie do stosu Ethereum -description: Omówienie różnych warstw stosu Ethereum i sposobu, w jaki się ze sobą łączą. +description: "Omówienie różnych warstw stosu Ethereum i sposobu, w jaki się ze sobą łączą." lang: pl --- -Podobnie jak każdy stos oprogramowania, kompletny stos Ethereum będzie się różnił w zależności od projektu w zależności od Twoich celów biznesowych. +Podobnie jak każdy stos oprogramowania, kompletny „stos Ethereum” będzie się różnił w zależności od projektu w zależności od Twoich celów. -Istnieją jednak podstawowe technologie Ethereum, które pomagają stworzyć model interakcji oprogramowania z blockchainem Ethereum. Zrozumienie warstw stosu pomoże Ci zrozumieć różne sposoby integracji Ethereum z projektami oprogramowania. +Istnieją jednak podstawowe komponenty Ethereum, które pomagają stworzyć model mentalny tego, jak aplikacje wchodzą w interakcję z blockchainem Ethereum. Zrozumienie warstw stosu pomoże Ci zrozumieć różne sposoby integracji Ethereum z projektami oprogramowania. -## Warstwa 1: Wirtualna Maszyna Ethereum {#ethereum-virtual-machine} +## Poziom 1: Wirtualna Maszyna Ethereum {#ethereum-virtual-machine} -Wirtualna Maszyna Ethereum ([Ethereum Virtual Machine, EVM](/developers/docs/evm/)) jest środowiskiem uruchomieniowym inteligentnych kontraktów w Ethereum. Wszystkie inteligentne kontrakty i zmiany stanu w blockchain Ethereum są wykonywane przez [transakcje](/developers/docs/transactions/). EVM obsługuje cały proces przetwarzania transakcji w sieci Ethereum. +[Wirtualna Maszyna Ethereum (EVM)](/developers/docs/evm/) to środowisko uruchomieniowe dla inteligentnych kontraktów w Ethereum. Wszystkie inteligentne kontrakty i zmiany stanu na blockchainie Ethereum są wykonywane przez [transakcje](/developers/docs/transactions/). EVM obsługuje cały proces przetwarzania transakcji w sieci Ethereum. -Podobnie jak w przypadku dowolnej maszyny wirtualnej, EVM tworzy poziom abstrakcji pomiędzy kodem wykonującym a maszyną wykonującą (węzeł Ethereum). Obecnie EVM działa w tysiącach węzłów rozmieszczonych na całym świecie. +Podobnie jak w przypadku dowolnej maszyny wirtualnej, EVM tworzy poziom abstrakcji pomiędzy kodem wykonującym a maszyną wykonującą (węzeł Ethereum). Obecnie EVM działa na tysiącach węzłów rozmieszczonych na całym świecie. -EVM używa zbioru instrukcji kodów operacyjnych w celu wykonywania konkretnych zadań. Tych (140 unikatowych) kodów operacji pozwala EVM na [kompletność Turinga](https://pl.wikipedia.org/wiki/Kompletno%C5%9B%C4%87_Turinga) co znaczy tyle, że EVM jest w stanie przetworzyć praktycznie wszystko, jeśli posiada wystarczająco dużo zasobów. +EVM używa zbioru instrukcji kodów operacyjnych w celu wykonywania konkretnych zadań. Te (140 unikalnych) kodów operacyjnych pozwala EVM być [kompletnym w sensie Turinga](https://en.wikipedia.org/wiki/Turing_completeness), co oznacza, że EVM jest w stanie obliczyć prawie wszystko, przy założeniu posiadania wystarczających zasobów. -Jako programiści zdecentralizowanych aplikacji nie musimy wiedzieć zbyt wiele na temat EVM poza tym, że istnieje i że niezawodnie zasila wszystkie aplikacje w Ethereum bez przestojów. +Jako programista dapek nie musisz wiedzieć zbyt wiele o EVM, poza tym, że istnieje i że niezawodnie zasila wszystkie aplikacje w Ethereum bez przestojów. -## Warstwa 2: Inteligentne kontrakty (Smart Contracts) {#smart-contracts} +## Poziom 2: Inteligentne kontrakty {#smart-contracts} -[Inteligentne kontrakty](/developers/docs/smart-contracts/) to programy wykonywalne, które działają w łańcuchu bloków Ethereum. +[Inteligentne kontrakty](/developers/docs/smart-contracts/) to programy wykonywalne, które działają na blockchainie Ethereum. -Inteligentne kontrakty są napisane przy użyciu określonych [języków programowania](/developers/docs/smart-contracts/languages/) , które kompilują do bytecode EVM (niskopoziomowe instrukcje maszynowe zwane opcode). +Inteligentne kontrakty są pisane przy użyciu określonych [języków programowania](/developers/docs/smart-contracts/languages/), które kompilują się do kodu bajtowego EVM (niskopoziomowych instrukcji maszynowych zwanych kodami operacyjnymi). -Inteligentne kontrakty służą nie tylko jako biblioteki open source, ale są to zasadniczo otwarte usługi API, które działają 24/7 i nie mogą zostać zlikwidowane. Inteligentne kontrakty zapewniają funkcje publiczne, z którymi aplikacje ([dapps](/developers/docs/dapps/)) mogą wchodzić w interakcje bez konieczności uzyskania zezwolenia. Każda aplikacja może zintegrować się z wdrożonymi inteligentnymi kontraktami w celu stworzenia funkcjonalności (takich jak kanały danych lub zdecentralizowana wymiana). Każdy może wdrożyć nowe inteligentne kontrakty do Ethereum w celu dodania niestandardowych funkcji, aby zaspokoić potrzeby ich aplikacji. +Inteligentne kontrakty służą nie tylko jako biblioteki open source, ale są w zasadzie otwartymi usługami API, które działają cały czas i nie można ich wyłączyć. Inteligentne kontrakty udostępniają funkcje publiczne, z którymi użytkownicy i aplikacje ([dapki](/developers/docs/dapps/)) mogą wchodzić w interakcję bez konieczności uzyskania pozwolenia. Każda aplikacja może integrować się z wdrożonymi inteligentnymi kontraktami w celu komponowania funkcjonalności, na przykład dodając [źródła danych](/developers/docs/oracles/) lub obsługując wymianę tokenów. Dodatkowo każdy może wdrożyć nowe inteligentne kontrakty w Ethereum, aby dodać niestandardową funkcjonalność w celu zaspokojenia potrzeb swojej aplikacji. Jako dewelopera dapp musisz zapisać inteligentne kontrakty tylko wtedy, gdy chcesz dodać niestandardowe funkcje w blockchainu Ethereum. Możesz znaleźć że możesz osiągnąć większość lub wszystkie potrzeby swojego projektu jedynie poprzez integrację z istniejącymi inteligentnymi kontraktami, na przykład jeśli chcesz wspierać płatności w stabilnych monetach lub włączyć zdecentralizowaną wymianę tokenów. -## Warstwa 3: Węzły Ethereum {#ethereum-nodes} +## Poziom 3: Węzły Ethereum {#ethereum-nodes} -Aby aplikacja mogła komunikować się z blockchainem Ethereum (np. pobierać dane z blockchainu lub wysyłać transakcje do sieci), musi być podłączona do [węzła w sieci Ethereum](/developers/docs/nodes-and-clients/). +Aby aplikacja mogła wejść w interakcję z blockchainem Ethereum, musi połączyć się z [węzłem Ethereum](/developers/docs/nodes-and-clients/). Połączenie z węzłem umożliwia odczytywanie danych blockchainu Ethereum i/lub wysyłanie transakcji do sieci. -Węzły Ethereum są komputerami, które obsługują oprogramowanie - klienta Ethereum. Klient jest implementacją Ethereum, która za zadanie ma weryfikację wszystkich transakcji w kolejnych blokach, utrzymywać bezpieczeństwo sieci i poprawność danych. Węzły Ethereum SĄ blockchainem Ethereum. Kolektywnie przechowują stan sieci Ethereum i ustalają konsensus nad transakcjami, aby zmienić stan blockchainu. +Węzły Ethereum są komputerami, które obsługują oprogramowanie - klienta Ethereum. Klient jest implementacją Ethereum, która za zadanie ma weryfikację wszystkich transakcji w kolejnych blokach, utrzymywać bezpieczeństwo sieci i poprawność danych. **Węzły Ethereum SĄ blockchainem Ethereum**. Kolektywnie przechowują stan sieci Ethereum i ustalają konsensus nad transakcjami, aby zmienić stan blockchainu. -Poprzez połączenie swojej aplikacji z węzłem Ethereum (przez specyfikację JSON RPC), nasza aplikacja jest w stanie czytać dane pochodzące z blockchinu (takie jak bilans konta użytkownika), jak również rozgłaszać nowe transakcje do sieci (jak transfer ETH pomiędzy kontami użytkowników lub wykonywanie inteligentnych kontraktów). +Łącząc swoją aplikację z węzłem Ethereum (za pośrednictwem [API JSON-RPC](/developers/docs/apis/json-rpc/)), może ona odczytywać dane z blockchainu (takie jak salda kont użytkowników), a także rozgłaszać nowe transakcje w sieci (takie jak przesyłanie ETH między kontami użytkowników lub wykonywanie funkcji inteligentnych kontraktów). -## Warstwa 4: Interfejsy API klienta Ethereum {#ethereum-client-apis} +## Poziom 4: API klienta Ethereum {#ethereum-client-apis} -Wiele wygodnych bibliotek (zbudowanych i utrzymywanych przez otwartą społeczność Ethereum) pozwala aplikacjom dla użytkowników końcowych na połączenie i komunikowanie z blockchianem Ethereum. +Wiele bibliotek ułatwiających (tworzonych i utrzymywanych przez społeczność open source Ethereum) pozwala aplikacjom łączyć się i komunikować z blockchainem Ethereum. -Jeśli twoja aplikacja skierowana do użytkownika jest aplikacją internetową, możesz wybrać `npm install` a [JavaScript API](/developers/docs/apis/javascript/) bezpośrednio w Twojej witrynie. Możemy także wybrać zainstalowanie tej funkcji po stronie serwera przy użyciu [Pythona](/developers/docs/programming-languages/python/) lub [Javy](/developers/docs/programming-languages/java/). +Jeśli Twoja aplikacja dla użytkownika jest aplikacją internetową, możesz zainstalować za pomocą `npm install` [API JavaScript](/developers/docs/apis/javascript/) bezpośrednio w swoim frontendzie. Możesz też zaimplementować tę funkcjonalność po stronie serwera, używając API w języku [Python](/developers/docs/programming-languages/python/) lub [Java](/developers/docs/programming-languages/java/). -Chociaż API te nie są niezbędnymi elementami stosu, odsuwają one wiele bezpośrednich interakcyjnych złożoności z węzłem Ethereum. Zapewniają one także użyteczne funkcje (np. konwersję ETH na Gwei), dzięki czemu jako programiści możemy spędzić mniej czasu na zajmowaniu się zawiłościami klientów, a skupić się w głównej mierze na unikalnej funkcji naszej aplikacji. +Chociaż API te nie są niezbędnymi elementami stosu, odsuwają one wiele bezpośrednich interakcyjnych złożoności z węzłem Ethereum. Zapewniają one również funkcje pomocnicze (np. konwersję ETH na Gwei), dzięki czemu jako deweloper możesz spędzać mniej czasu na zmaganiu się ze złożonością klientów Ethereum, a więcej na funkcjonalności specyficznej dla Twojej aplikacji. -## Warstwa 5: Aplikacje użytkownika końcowego {#end-user-applications} +## Poziom 5: Aplikacje dla użytkowników końcowych {#end-user-applications} Na samej górze stosu są aplikacje komunikujące się bezpośrednio z użytkownikiem. Są to standardowe aplikacje regularnie używane i budowane w dzisiejszych czasach: głównie aplikacje webowe i mobilne. Sposób, w jaki tworzone są te interfejsy użytkownika, pozostaje w gruncie rzeczy niezmieniony. Często użytkownicy nie muszą wiedzieć, że używana przez nich aplikacja została utworzona przy użyciu blockchainu. -## Gotowy do stworzenia swojego stosu? {#ready-to-choose-your-stack} +## Gotowy do stworzenia swojego stosu? Gotowy, by wybrać swój stack? {#ready-to-choose-your-stack} -Sprawdź w przewodniku, w jaki sposób [przygotować lokalne środowisko deweloperskie](/developers/local-environment/) dla Twojej aplikacji na Ethereum. +Sprawdź nasz przewodnik po [konfiguracji lokalnego środowiska deweloperskiego](/developers/local-environment/) dla Twojej aplikacji Ethereum. ## Dalsza lektura {#further-reading} -_Znasz jakieś zasoby społeczności, które Ci pomogły? Wyedytuj tę stronę i dodaj je!_ +- [Architektura aplikacji Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) – _Preethi Kasireddy_ + +_Znasz jakieś zasoby społeczności, które Ci pomogły? Edytuj tę stronę i dodaj je!_ diff --git a/public/content/translations/pl/developers/docs/evm/index.md b/public/content/translations/pl/developers/docs/evm/index.md index 452885250fb..af29f8ab24c 100644 --- a/public/content/translations/pl/developers/docs/evm/index.md +++ b/public/content/translations/pl/developers/docs/evm/index.md @@ -1,62 +1,72 @@ --- title: Maszyna wirtualna Ethereum (EVM) -description: Wprowadzenie do maszyny wirtualnej Ethereum i jej powiązania ze stanem, transakcjami i inteligentnymi kontraktami. +description: "Wprowadzenie do maszyny wirtualnej Ethereum i jej powiązania ze stanem, transakcjami i inteligentnymi kontraktami." lang: pl --- -Maszyna wirtualna Ethereum (EVM) to zdecentralizowane, wirtualne środowisko, które wykonuje kod spójnie i bezpiecznie we wszystkich węzłach Ethereum. Węzły uruchamiają EVM w celu wykonania inteligentnych kontraktów, wykorzystując „[gaz](/gas/)” do pomiaru wysiłku obliczeniowego wymaganego do [operacji](/developers/docs/evm/opcodes/) i zapewniając efektywną alokację zasobów i bezpieczeństwo sieci. +Maszyna wirtualna Ethereum (EVM) to zdecentralizowane, wirtualne środowisko, które wykonuje kod spójnie i bezpiecznie we wszystkich węzłach Ethereum. Węzły uruchamiają EVM w celu wykonywania inteligentnych kontraktów, używając "[gazu](/developers/docs/gas/)" do pomiaru wysiłku obliczeniowego wymaganego do [operacji](/developers/docs/evm/opcodes/), zapewniając wydajną alokację zasobów i bezpieczeństwo sieci. ## Wymagania wstępne {#prerequisites} -Do zrozumienia EVM konieczna jest znajomość podstawowej terminologii informatycznej, takiej jak [bajty](https://wikipedia.org/wiki/Byte), [pamięć](https://wikipedia.org/wiki/Computer_memory) i [stos](https://wikipedia.org/wiki/Stack_(abstract_data_type)). Przydatna będzie również znajomość pojęć związanych z kryptografią/blockchainem, takich jak [funkcja haszująca](https://wikipedia.org/wiki/Cryptographic_hash_function) i [drzewo Merkle](https://wikipedia.org/wiki/Merkle_tree). +Do zrozumienia EVM konieczna jest podstawowa znajomość popularnej terminologii informatycznej, takiej jak [bajty](https://wikipedia.org/wiki/Byte), [pamięć](https://wikipedia.org/wiki/Computer_memory) i [stos](https://wikipedia.org/wiki/Stack_\(abstract_data_type\)). Pomocna będzie również znajomość pojęć z zakresu kryptografii/blockchaina, takich jak [funkcje haszujące](https://wikipedia.org/wiki/Cryptographic_hash_function) i [drzewo Merkle'a](https://wikipedia.org/wiki/Merkle_tree). -## Od księgi głównej do maszyny stanowej {#from-ledger-to-state-machine} +## Od rejestru do maszyny stanu {#from-ledger-to-state-machine} Analogia „rozproszonej księgi głównej” jest często używana w celu opisania blockchainów np. takich jak Bitcoin, które umożliwiają zdecentralizowanym walutom używanie fundamentalnych narzędzi kryptograficznych. Księga główna prowadzi rejestr aktywności, który musi być zgodny z zestawem reguł określających, co ktoś może, a czego nie może zrobić, aby zmodyfikować księgę. Na przykład adres Bitcoina nie może wydać więcej Bitcoinów, niż wcześniej otrzymał. Zasady te są podstawą wszystkich transakcji na Bitcoinie i wielu innych blockchainach. -Choć Ethereum ma swoją własną kryptowalutę (Ether), która działa niemal dokładnie według tych samych intuicyjnych zasad, pozwala również stosować znacznie bardziej rozbudowaną funkcję: [inteligentne kontrakty](/developers/docs/smart-contracts/). Dla tej skomplikowanej funkcji wymagana jest bardziej wyszukana analogia. W odróżnieniu od rozproszonej księgi głównej, Ethereum jest rozproszoną [maszyną stanową](https://wikipedia.org/wiki/Finite-state_machine). Stany Ethereum są wielkimi strukturami danych, które przechowują nie tylko wszystkie konta i ich salda, ale też _stan maszyny_, który może zmieniać się od bloku do bloku zgodnie z predefiniowanymi zasadami, i który może wykonywać dowolny kod maszynowy. Konkretne zasady zmiany stanu od bloku do bloku są zdefiniowane przez EVM. +Mimo że Ethereum ma swoją własną natywną kryptowalutę (ether), która działa według niemal tych samych intuicyjnych zasad, umożliwia również o wiele potężniejszą funkcję: [inteligentne kontrakty](/developers/docs/smart-contracts/). Dla tej skomplikowanej funkcji wymagana jest bardziej wyszukana analogia. Zamiast rozproszonego rejestru, Ethereum jest rozproszoną [maszyną stanu](https://wikipedia.org/wiki/Finite-state_machine). Stan Ethereum to duża struktura danych, która przechowuje nie tylko wszystkie konta i salda, ale także _stan maszyny_, który może zmieniać się z bloku na blok zgodnie z predefiniowanym zestawem zasad i który może wykonywać dowolny kod maszynowy. Konkretne zasady zmiany stanu od bloku do bloku są zdefiniowane przez EVM. -![Schemat przedstawiający strukturę EVM](./evm.png) _Schemat zaadaptowany z [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +![Diagram przedstawiający budowę EVM](./evm.png) +_Diagram zaadaptowany z [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ -## Funkcja przejścia stanów Ethereum {#the-ethereum-state-transition-function} +## Funkcja przejścia stanu Ethereum {#the-ethereum-state-transition-function} -EVM zachowuje się jak funkcja matematyczna: biorąc pod uwagę dane wejściowe, wytwarza deterministyczne dane wyjściowe. Dlatego bardziej pomocne jest bardziej formalne opisanie Ethereum jako posiadającego **funkcję zmiany stanu**: +EVM zachowuje się jak funkcja matematyczna: biorąc pod uwagę dane wejściowe, wytwarza deterministyczne dane wyjściowe. Dlatego bardzo pomocne jest bardziej formalne opisanie Ethereum jako posiadającego **funkcję przejścia stanu**: ``` Y(S, T)= S' ``` -Uwzględniając stary ważny stan `(S)` oraz nowy zestaw ważnych transakcji `(T)`, funkcja zmiany stanu Ethereum `Y(S, T)` tworzy nowy prawidłowy stan wyjściowy `S'` +Biorąc pod uwagę stary ważny stan `(S)` i nowy zestaw ważnych transakcji `(T)`, funkcja przejścia stanu Ethereum `Y(S, T)` tworzy nowy, ważny stan wyjściowy `S'` ### Stan {#state} -W odniesieniu do Ethereum stan jest olbrzymią strukturą danych nazywaną [zmodyfikowanym drzewem trie Merkle Patricia](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/), która zachowuje wszystkie [konta](/developers/docs/accounts/) połączone haszami i redukowalne do pojedynczego haszu korzenia przechowywanego na blockchainie. +W kontekście Ethereum stan jest ogromną strukturą danych zwaną [zmodyfikowanym drzewem Merkle Patricia Trie](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/), która przechowuje wszystkie [konta](/developers/docs/accounts/) połączone haszami i redukowalne do pojedynczego haszu głównego przechowywanego na blockchainie. ### Transakcje {#transactions} -Transakcje są to pojedyncze kryptograficznie podpisane instrukcję pochodzące z kont użytkowników. Możemy wyróżnić dwa typy transakcji: te, których wynikiem są wywołania komunikatów, oraz te, których wynikiem jest utworzenie kontraktu. +Transakcje to podpisane kryptograficznie instrukcje od kont. Możemy wyróżnić dwa typy transakcji: te, których wynikiem są wywołania komunikatów, oraz te, których wynikiem jest utworzenie kontraktu. -Rezultatem stworzenia nowego kontraktu jest stworzenie nowego konta kontaktu zawierającego skompilowany kod bitowy [inteligentnego kontraktu](/developers/docs/smart-contracts/anatomy/). Ilekroć inne konto wysyła wywołania komunikatów do tego kontraktu, wykonuje on kod bitowy. +Utworzenie kontraktu skutkuje utworzeniem nowego konta kontraktu zawierającego skompilowany kod bajtowy [inteligentnego kontraktu](/developers/docs/smart-contracts/anatomy/). Ilekroć inne konto wysyła wywołania komunikatów do tego kontraktu, wykonuje on kod bitowy. ## Instrukcje EVM {#evm-instructions} -EVM działa jako [maszyna stosu](https://wikipedia.org/wiki/Stack_machine) o pojemności 1024 elementów. Każdy element to 256-bitowe słowo, które zostało wybrane ze względu na łatwość użycia z 256-bitową kryptografią (taką jak hasze Keccak-256 lub podpisy secp256k1). +EVM działa jako [maszyna stosowa](https://wikipedia.org/wiki/Stack_machine) o głębokości 1024 elementów. Każdy element to 256-bitowe słowo, które zostało wybrane ze względu na łatwość użycia z 256-bitową kryptografią (taką jak hasze Keccak-256 lub podpisy secp256k1). -Podczas realizacji EVM przechowuje _pamięć_ przejściową (w postaci tablicy bajtów z adresami słów), która jednak nie jest trwała między transakcjami. +Podczas wykonywania EVM utrzymuje przejściową _pamięć_ (jako tablicę bajtów adresowaną słowami), która nie jest zachowywana między transakcjami. -Kontrakty jednak zawierają drzewo _pamięciowe_ Merkle Patricia (jako adresowalną tablicę słów), powiązane w wiadomości z odpowiednim kontem i częścią stanu globalnego. +### Przechowywanie przejściowe -Skompilowany kod bitowy inteligentnego kontraktu wykonywany jest jako szereg [kodów operacyjnych](/developers/docs/evm/opcodes) EVM, które przeprowadzają standardowe operacje na stosie, takie jak `XOR`, `AND`, `ADD`, `SUB` itp. EVM implementuje również szereg operacji stosu specyficznych dla blockchaina, takich jak `ADDRESS`, `BALANCE`, `BLOCKHASH` itp. +Przechowywanie przejściowe to magazyn typu klucz-wartość per transakcja, do którego dostęp uzyskuje się za pomocą kodów operacyjnych `TSTORE` i `TLOAD`. Jest ono zachowywane we wszystkich wywołaniach wewnętrznych w ramach tej samej transakcji, ale jest czyszczone na koniec transakcji. W przeciwieństwie do pamięci, przechowywanie przejściowe jest modelowane jako część stanu EVM, a nie ramki wykonania, jednak nie jest zapisywane w stanie globalnym. Przechowywanie przejściowe umożliwia wydajne pod względem zużycia gazu tymczasowe współdzielenie stanu między wewnętrznymi wywołaniami w trakcie transakcji. -![Schemat pokazujący, gdzie potrzebny jest gaz dla operacji EVM](../gas/gas.png) _Schemat zaadaptowany z [zilustrowane Ethereum EVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +### Przechowywanie -## Implementacja EVM {#evm-implementations} +Kontrakty zawierają drzewo _storage_ trie Merkle Patricia (jako tablicę słów adresowaną słowami), powiązane z danym kontem i będące częścią stanu globalnego. To trwałe przechowywanie różni się od przechowywania przejściowego, które jest dostępne tylko na czas trwania pojedynczej transakcji i nie stanowi części trwałego drzewa przechowywania konta. + +### Kody operacyjne + +Skompilowany kod bajtowy inteligentnego kontraktu jest wykonywany jako szereg [kodów operacyjnych](/developers/docs/evm/opcodes) EVM, które wykonują standardowe operacje na stosie, takie jak `XOR`, `AND`, `ADD`, `SUB` itp. EVM implementuje również szereg operacji na stosie specyficznych dla blockchaina, takich jak `ADDRESS`, `BALANCE`, `BLOCKHASH` itp. Zestaw kodów operacyjnych zawiera również `TSTORE` i `TLOAD`, które zapewniają dostęp do przechowywania przejściowego. + +![Diagram pokazujący, gdzie potrzebny jest gaz do operacji EVM](../gas/gas.png) +_Diagramy zaadaptowane z [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ + +## Implementacje EVM {#evm-implementations} Wszystkie implementacje EVM muszą być zgodne ze specyfikacją opisaną w Ethereum Yellowpaper. -W ponad dziewięcioletniej historii Ethereum EVM przeszła kilka zmian; w ciągu tego czasu miało miejsce również kilka implementacji EVM w różnych językach programowania. +W ciągu dziesięcioletniej historii Ethereum EVM przeszła kilka zmian i istnieje kilka implementacji EVM w różnych językach programowania. -[Klienty wykonawcze Ethereum](/developers/docs/nodes-and-clients/#execution-clients) zawierają implementację EVM. Ponadto istnieje wiele niezależnych implementacji, w tym: +[Klienci wykonawczy Ethereum](/developers/docs/nodes-and-clients/#execution-clients) zawierają implementację EVM. Ponadto istnieje wiele niezależnych implementacji, w tym: - [Py-EVM](https://github.com/ethereum/py-evm) - _Python_ - [evmone](https://github.com/ethereum/evmone) - _C++_ @@ -66,13 +76,13 @@ W ponad dziewięcioletniej historii Ethereum EVM przeszła kilka zmian; w ciągu ## Dalsza lektura {#further-reading} - [Ethereum Yellowpaper](https://ethereum.github.io/yellowpaper/paper.pdf) -- [Jellopaper, zwany też KEVM: Semantyka EVM w K](https://jellopaper.org/) +- [Jellopaper aka KEVM: Semantyka EVM w K](https://jellopaper.org/) - [The Beigepaper](https://github.com/chronaeon/beigepaper) -- [Maszyna wirtualna Ethereum — kody operacyjne](https://www.ethervm.io/) -- [Interaktywne odniesienie do kodów operacyjnych maszyny wirtualnej Ethereum](https://www.evm.codes/) +- [Kody operacyjne Wirtualnej Maszyny Ethereum](https://www.ethervm.io/) +- [Interaktywny informator o kodach operacyjnych Wirtualnej Maszyny Ethereum](https://www.evm.codes/) - [Krótkie wprowadzenie w dokumentacji Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6) -- [Z Ethereum za pan brat — Maszyna wirtualna Ethereum](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc) +- [Mastering Ethereum - Wirtualna Maszyna Ethereum](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc) -## Tematy powiązane {#related-topics} +## Powiązane tematy {#related-topics} - [Gaz](/developers/docs/gas/) diff --git a/public/content/translations/pl/developers/docs/evm/opcodes/index.md b/public/content/translations/pl/developers/docs/evm/opcodes/index.md index 85f0968b841..6a1b8590cca 100644 --- a/public/content/translations/pl/developers/docs/evm/opcodes/index.md +++ b/public/content/translations/pl/developers/docs/evm/opcodes/index.md @@ -1,174 +1,177 @@ --- title: Kody operacyjne dla EVM -description: Lista wszystkich dostępnych kodów operacyjnych dla maszyny wirtualnej Ethereum. +description: "Lista wszystkich dostępnych kodów operacyjnych dla maszyny wirtualnej Ethereum." lang: pl --- ## Przegląd {#overview} -Jest to zaktualizowana wersja strony referencyjnej EVM pod adresem [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes). Dane zaczerpnięto również z implementacji [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf), [Jello Paper](https://jellopaper.org/evm/) i [geth](https://github.com/ethereum/go-ethereum). Ma to być przystępne odniesienie, ale nie jest szczególnie rygorystyczne. Jeśli chcesz mieć pewność poprawności i świadomość każdego skrajnego przypadku, zaleca się użycie Jello Paper lub implementacji klienta. +To jest zaktualizowana wersja strony referencyjnej EVM pod adresem [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes). +Zaczerpnięto również z [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf), [Jello Paper](https://jellopaper.org/evm/) i implementacji [geth](https://github.com/ethereum/go-ethereum). +Ma to być przystępne odniesienie, ale nie jest szczególnie rygorystyczne. +Jeśli chcesz mieć pewność poprawności i świadomość każdego skrajnego przypadku, zaleca się użycie Jello Paper lub implementacji klienta. Szukasz interaktywnego odniesienia? Sprawdź [evm.codes](https://www.evm.codes/). -W przypadku operacji z dynamicznymi kosztami gazu sprawdź [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md). +W przypadku operacji z dynamicznymi kosztami gazu zobacz [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md). -Szybka wskazówka: Aby wyświetlić całe linie, użyj `[shift] + scroll` do przewijania w poziomie na pulpicie. +💡 Szybka wskazówka: aby wyświetlić całe linie, użyj kombinacji `[shift] + scroll`, aby przewijać w poziomie na pulpicie. -| Stos | Nazwa | Gaz | Początkowy stos | Powstały stos | Pamięć / Przechowywanie | Uwagi | -|:-----:|:-------------- |:-----------------------------------------------------------------------------------------------:|:------------------------------------------------ |:-------------------------------------------- |:----------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 00 | STOP | 0 | | | | halt execution | -| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 addition modulo 2\*\*256 | -| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 multiplication modulo 2\*\*256 | -| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 addition modulo 2\*\*256 | -| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 division | -| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 division | -| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 modulus | -| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 modulus | -| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 addition modulo N | -| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 multiplication modulo N | -| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 exponentiation modulo 2\*\*256 | -| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [sign extend](https://wikipedia.org/wiki/Sign_extension) `x` from `(b+1)` bytes to 32 bytes | -| 0C-0F | _invalid_ | | | | | | -| 10 | LT | 3 | `a, b` | `a < b` | | uint256 less-than | -| 11 | GT | 3 | `a, b` | `a > b` | | uint256 greater-than | -| 12 | SLT | 3 | `a, b` | `a < b` | | int256 less-than | -| 13 | SGT | 3 | `a, b` | `a > b` | | int256 greater-than | -| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 equality | -| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 iszero | -| 16 | AND | 3 | `a, b` | `a && b` | | bitwise AND | -| 17 | OR | 3 | `a, b` | `a \|\| b` | | bitwise OR | -| 18 | XOR | 3 | `a, b` | `a ^ b` | | bitwise XOR | -| 19 | NOT | 3 | `a` | `~a` | | bitwise NOT | -| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`th byte of (u)int256 `x`, from the left | -| 1B | SHL | 3 | `shift, val` | `val << shift` | | shift left | -| 1C | SHR | 3 | `shift, val` | `val >> shift` | | logical shift right | -| 1D | SAR | 3 | `shift, val` | `val >> shift` | | arithmetic shift right | -| 1E-1F | _invalid_ | | | | | | -| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | -| 21-2F | _invalid_ | | | | | | -| 30 | ADDRESS | 2 | `.` | `address(this)` | | address of executing contract | -| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | balance, in wei | -| 32 | ORIGIN | 2 | `.` | `tx.origin` | | address that originated the tx | -| 33 | CALLER | 2 | `.` | `msg.sender` | | address of msg sender | -| 34 | CALLVALUE | 2 | `.` | `msg.value` | | msg value, in wei | -| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | read word from msg data at index `idx` | -| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | length of msg data, in bytes | -| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | copy msg data | -| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | length of executing contract's code, in bytes | -| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | copy executing contract's bytecode | -| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | gas price of tx, in wei per unit gas [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | -| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | size of code at addr, in bytes | -| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | copy code from `addr` | -| 3D | RETURNDATASIZE | 2 | `.` | `size` | | size of returned data from last external call, in bytes | -| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | copy returned data from last external call | -| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | hash = addr.exists ? keccak256(addr.code) : 0 | -| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | -| 41 | COINBASE | 2 | `.` | `block.coinbase` | | address of proposer of current block | -| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | timestamp of current block | -| 43 | NUMBER | 2 | `.` | `block.number` | | number of current block | -| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | randomness beacon | -| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | gas limit of current block | -| 46 | CHAINID | 2 | `.` | `chain_id` | | push current [chain id](https://eips.ethereum.org/EIPS/eip-155) onto stack | -| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | balance of executing contract, in wei | -| 48 | BASEFEE | 2 | `.` | `block.basefee` | | base fee of current block | -| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | -| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | blob base fee of current block ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | -| 4B-4F | _invalid_ | | | | | | -| 50 | POP | 2 | `_anon` | `.` | | remove item from top of stack and discard it | -| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | read word from memory at offset `ost` | -| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | write a word to memory | -| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | write a single byte to memory | -| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | read word from storage | -| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | write word to storage | -| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` mark that `pc` is only assigned if `dst` is a valid jumpdest | -| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ? dst : $pc + 1` | -| 58 | PC | 2 | `.` | `$pc` | | program counter | -| 59 | MSIZE | 2 | `.` | `len(mem)` | | size of memory in current execution context, in bytes | -| 5A | GAS | 2 | `.` | `gasRemaining` | | | -| 5B | JUMPDEST | 1 | | | mark valid jump destination | a valid jump destination for example a jump destination not inside the push data | -| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | read word from transient storage ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | -| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | write word to transient storage ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | -| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | copy memory from one area to another ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) | -| 5F | PUSH0 | 2 | `.` | `uint8` | | umieszcza stałą wartość 0 na stosie | -| 60 | PUSH1 | 3 | `.` | `uint8` | | push 1-byte value onto stack | -| 61 | PUSH2 | 3 | `.` | `uint16` | | push 2-byte value onto stack | -| 62 | PUSH3 | 3 | `.` | `uint24` | | push 3-byte value onto stack | -| 63 | PUSH4 | 3 | `.` | `uint32` | | push 4-byte value onto stack | -| 64 | PUSH5 | 3 | `.` | `uint40` | | push 5-byte value onto stack | -| 65 | PUSH6 | 3 | `.` | `uint48` | | push 6-byte value onto stack | -| 66 | PUSH7 | 3 | `.` | `uint56` | | push 7-byte value onto stack | -| 67 | PUSH8 | 3 | `.` | `uint64` | | push 8-byte value onto stack | -| 68 | PUSH9 | 3 | `.` | `uint72` | | push 9-byte value onto stack | -| 69 | PUSH10 | 3 | `.` | `uint80` | | push 10-byte value onto stack | -| 6A | PUSH11 | 3 | `.` | `uint88` | | push 11-byte value onto stack | -| 6B | PUSH12 | 3 | `.` | `uint96` | | push 12-byte value onto stack | -| 6C | PUSH13 | 3 | `.` | `uint104` | | push 13-byte value onto stack | -| 6D | PUSH14 | 3 | `.` | `uint112` | | push 14-byte value onto stack | -| 6E | PUSH15 | 3 | `.` | `uint120` | | push 15-byte value onto stack | -| 6F | PUSH16 | 3 | `.` | `uint128` | | push 16-byte value onto stack | -| 70 | PUSH17 | 3 | `.` | `uint136` | | push 17-byte value onto stack | -| 71 | PUSH18 | 3 | `.` | `uint144` | | push 18-byte value onto stack | -| 72 | PUSH19 | 3 | `.` | `uint152` | | push 19-byte value onto stack | -| 73 | PUSH20 | 3 | `.` | `uint160` | | push 20-byte value onto stack | -| 74 | PUSH21 | 3 | `.` | `uint168` | | push 21-byte value onto stack | -| 75 | PUSH22 | 3 | `.` | `uint176` | | push 22-byte value onto stack | -| 76 | PUSH23 | 3 | `.` | `uint184` | | push 23-byte value onto stack | -| 77 | PUSH24 | 3 | `.` | `uint192` | | push 24-byte value onto stack | -| 78 | PUSH25 | 3 | `.` | `uint200` | | push 25-byte value onto stack | -| 79 | PUSH26 | 3 | `.` | `uint208` | | push 26-byte value onto stack | -| 7A | PUSH27 | 3 | `.` | `uint216` | | push 27-byte value onto stack | -| 7B | PUSH28 | 3 | `.` | `uint224` | | push 28-byte value onto stack | -| 7C | PUSH29 | 3 | `.` | `uint232` | | push 29-byte value onto stack | -| 7D | PUSH30 | 3 | `.` | `uint240` | | push 30-byte value onto stack | -| 7E | PUSH31 | 3 | `.` | `uint248` | | push 31-byte value onto stack | -| 7F | PUSH32 | 3 | `.` | `uint256` | | push 32-byte value onto stack | -| 80 | DUP1 | 3 | `a` | `a, a` | | clone 1st value on stack | -| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clone 2nd value on stack | -| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clone 3rd value on stack | -| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clone 4th value on stack | -| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clone 5th value on stack | -| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clone 6th value on stack | -| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clone 7th value on stack | -| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clone 8th value on stack | -| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clone 9th value on stack | -| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clone 10th value on stack | -| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clone 11th value on stack | -| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clone 12th value on stack | -| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clone 13th value on stack | -| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clone 14th value on stack | -| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clone 15th value on stack | -| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clone 16th value on stack | -| 90 | SWAP1 | 3 | `a, b` | `b, a` | | | -| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | | -| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | | -| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | | -| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | | -| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | | -| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | | -| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | | -| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | | -| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | | -| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) | -| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) | -| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) | -| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) | -| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) | -| A5-EF | _invalid_ | | | | | | -| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) | -| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | | -| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | same as DELEGATECALL, but does not propagate original msg.sender and msg.value | -| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | return mem[ost:ost+len-1] | -| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | -| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] | -| F6-F9 | _invalid_ | | | | | | -| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | -| FB-FC | _invalid_ | | | | | | -| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) | -| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | designated invalid opcode - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | | -| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | sends all ETH to `addr`; if executed in the same transaction as a contract was created it destroys the contract | +| Stos | Nazwa | Gaz | Początkowy stos | Powstały stos | Pamięć / Przechowywanie | Uwagi | | +| :---: | :-------------- | :---------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------- | +| 00 | STOP | 0 | | | | wstrzymaj wykonanie | | +| 01 | ADD | 3 | `a, b` | `a + b` | | dodawanie (u)int256 modulo 2\*\*256 | | +| 02 | MUL | 5 | `a, b` | `a * b` | | mnożenie (u)int256 modulo 2\*\*256 | | +| 03 | SUB | 3 | `a, b` | `a - b` | | odejmowanie (u)int256 modulo 2\*\*256 | | +| 04 | DIV | 5 | `a, b` | `a // b` | | dzielenie uint256 | | +| 05 | SDIV | 5 | `a, b` | `a // b` | | dzielenie int256 | | +| 06 | MOD | 5 | `a, b` | `a % b` | | modulo uint256 | | +| 07 | SMOD | 5 | `a, b` | `a % b` | | modulo int256 | | +| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | dodawanie (u)int256 modulo N | | +| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | mnożenie (u)int256 modulo N | | +| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | potęgowanie uint256 modulo 2\*\*256 | | +| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [rozszerzenie znaku](https://wikipedia.org/wiki/Sign_extension) `x` z `(b+1)` bajtów do 32 bajtów | | +| 0C-0F | _nieprawidłowy_ | | | | | | | +| 10 | LT | 3 | `a, b` | `a < b` | | uint256 mniejsze niż | | +| 11 | GT | 3 | `a, b` | `a > b` | | uint256 większe niż | | +| 12 | SLT | 3 | `a, b` | `a < b` | | int256 mniejsze niż | | +| 13 | SGT | 3 | `a, b` | `a > b` | | int256 większe niż | | +| 14 | EQ | 3 | `a, b` | `a == b` | | równość (u)int256 | | +| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 jest zerem | | +| 16 | AND | 3 | `a, b` | `a && b` | | bitowe AND | | +| 17 | OR | 3 | `a, b` | `a \\|\\| b` | | bitowe OR | | +| 18 | XOR | 3 | `a, b` | `a ^ b` | | bitowe XOR | | +| 19 | NOT | 3 | `a` | `~a` | | bitowe NOT | | +| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`-ty bajt (u)int256 `x`, od lewej | | +| 1B | SHL | 3 | `shift, val` | `val << shift` | | przesunięcie w lewo | | +| 1C | SHR | 3 | `shift, val` | `val >> shift` | | logiczne przesunięcie w prawo | | +| 1D | SAR | 3 | `shift, val` | `val >> shift` | | arytmetyczne przesunięcie w prawo | | +| 1E-1F | _nieprawidłowy_ | | | | | | | +| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | | +| 21-2F | _nieprawidłowy_ | | | | | | | +| 30 | ADDRESS | 2 | `.` | `address(this)` | | adres wykonywanego kontraktu | | +| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | saldo, w wei | | +| 32 | ORIGIN | 2 | `.` | `tx.origin` | | adres, z którego pochodzi transakcja | | +| 33 | CALLER | 2 | `.` | `msg.sender` | | adres nadawcy wiadomości | | +| 34 | CALLVALUE | 2 | `.` | `msg.value` | | wartość wiadomości, w wei | | +| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | odczytaj słowo z danych wiadomości pod indeksem `idx` | | +| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | długość danych wiadomości, w bajtach | | +| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | kopiuj dane wiadomości | | +| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | długość kodu wykonywanego kontraktu, w bajtach | | +| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | kopiuj kod bajtowy wykonywanego kontraktu | +| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | cena gazu transakcji, w wei za jednostkę gazu [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | | +| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | rozmiar kodu pod adresem, w bajtach | | +| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | kopiuj kod z `addr` | | +| 3D | RETURNDATASIZE | 2 | `.` | `size` | | rozmiar zwróconych danych z ostatniego wywołania zewnętrznego, w bajtach | | +| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | kopiuj zwrócone dane z ostatniego wywołania zewnętrznego | | +| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | hasz = addr.exists ? keccak256(addr.code) : 0 | | +| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | | +| 41 | COINBASE | 2 | `.` | `block.coinbase` | | address of proposer of current block | | +| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | znacznik czasu bieżącego bloku | | +| 43 | NUMBER | 2 | `.` | `block.number` | | numer bieżącego bloku | | +| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | sygnalizator losowości | | +| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | limit gazu bieżącego bloku | | +| 46 | CHAINID | 2 | `.` | `chain_id` | | umieść bieżący [identyfikator łańcucha](https://eips.ethereum.org/EIPS/eip-155) na stosie | | +| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | saldo wykonywanego kontraktu, w wei | | +| 48 | BASEFEE | 2 | `.` | `block.basefee` | | podstawowa opłata bieżącego bloku | | +| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | | +| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | podstawowa opłata za blob bieżącego bloku ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | | +| 4B-4F | _nieprawidłowy_ | | | | | | | +| 50 | POP | 2 | `_anon` | `.` | | usuń element ze szczytu stosu i odrzuć go | | +| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | odczytaj słowo z pamięci z przesunięciem `ost` | | +| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | zapisz słowo w pamięci | | +| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | zapisz pojedynczy bajt w pamięci | | +| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | odczytaj słowo z przechowywania | | +| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | zapisz słowo w przechowywaniu | | +| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` oznacza, że `pc` jest przypisywane tylko wtedy, gdy `dst` jest prawidłowym celem skoku | | +| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ?` dst : $pc + 1` | | +| 58 | PC | 2 | `.` | `$pc` | | licznik programu | | +| 59 | MSIZE | 2 | `.` | `len(mem)` | | rozmiar pamięci w bieżącym kontekście wykonania, w bajtach | | +| 5A | GAS | 2 | `.` | `gasRemaining` | | | | +| 5B | JUMPDEST | 1 | | | oznacz prawidłowy cel skoku | prawidłowy cel skoku, na przykład cel skoku, który nie znajduje się wewnątrz danych push | | +| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | odczytaj słowo z przejściowego przechowywania ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | | +| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | zapisz słowo w przejściowym przechowywaniu ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | | +| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | kopiuj pamięć z jednego obszaru do drugiego ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) | | +| 5F | PUSH0 | 2 | `.` | `uint8` | | umieszcza stałą wartość 0 na stosie | | +| 60 | PUSH1 | 3 | `.` | `uint8` | | umieść 1-bajtową wartość na stosie | | +| 61 | PUSH2 | 3 | `.` | `uint16` | | umieść 2-bajtową wartość na stosie | | +| 62 | PUSH3 | 3 | `.` | `uint24` | | umieść 3-bajtową wartość na stosie | | +| 63 | PUSH4 | 3 | `.` | `uint32` | | umieść 4-bajtową wartość na stosie | | +| 64 | PUSH5 | 3 | `.` | `uint40` | | umieść 5-bajtową wartość na stosie | | +| 65 | PUSH6 | 3 | `.` | `uint48` | | umieść 6-bajtową wartość na stosie | | +| 66 | PUSH7 | 3 | `.` | `uint56` | | umieść 7-bajtową wartość na stosie | | +| 67 | PUSH8 | 3 | `.` | `uint64` | | umieść 8-bajtową wartość na stosie | | +| 68 | PUSH9 | 3 | `.` | `uint72` | | umieść 9-bajtową wartość na stosie | | +| 69 | PUSH10 | 3 | `.` | `uint80` | | umieść 10-bajtową wartość na stosie | | +| 6A | PUSH11 | 3 | `.` | `uint88` | | umieść 11-bajtową wartość na stosie | | +| 6B | PUSH12 | 3 | `.` | `uint96` | | umieść 12-bajtową wartość na stosie | | +| 6C | PUSH13 | 3 | `.` | `uint104` | | umieść 13-bajtową wartość na stosie | | +| 6D | PUSH14 | 3 | `.` | `uint112` | | umieść 14-bajtową wartość na stosie | | +| 6E | PUSH15 | 3 | `.` | `uint120` | | umieść 15-bajtową wartość na stosie | | +| 6F | PUSH16 | 3 | `.` | `uint128` | | umieść 16-bajtową wartość na stosie | | +| 70 | PUSH17 | 3 | `.` | `uint136` | | umieść 17-bajtową wartość na stosie | | +| 71 | PUSH18 | 3 | `.` | `uint144` | | umieść 18-bajtową wartość na stosie | | +| 72 | PUSH19 | 3 | `.` | `uint152` | | umieść 19-bajtową wartość na stosie | | +| 73 | PUSH20 | 3 | `.` | `uint160` | | umieść 20-bajtową wartość na stosie | | +| 74 | PUSH21 | 3 | `.` | `uint168` | | umieść 21-bajtową wartość na stosie | | +| 75 | PUSH22 | 3 | `.` | `uint176` | | umieść 22-bajtową wartość na stosie | | +| 76 | PUSH23 | 3 | `.` | `uint184` | | umieść 23-bajtową wartość na stosie | | +| 77 | PUSH24 | 3 | `.` | `uint192` | | umieść 24-bajtową wartość na stosie | | +| 78 | PUSH25 | 3 | `.` | `uint200` | | umieść 25-bajtową wartość na stosie | | +| 79 | PUSH26 | 3 | `.` | `uint208` | | umieść 26-bajtową wartość na stosie | | +| 7A | PUSH27 | 3 | `.` | `uint216` | | umieść 27-bajtową wartość na stosie | | +| 7B | PUSH28 | 3 | `.` | `uint224` | | umieść 28-bajtową wartość na stosie | | +| 7C | PUSH29 | 3 | `.` | `uint232` | | umieść 29-bajtową wartość na stosie | | +| 7D | PUSH30 | 3 | `.` | `uint240` | | umieść 30-bajtową wartość na stosie | | +| 7E | PUSH31 | 3 | `.` | `uint248` | | umieść 31-bajtową wartość na stosie | | +| 7F | PUSH32 | 3 | `.` | `uint256` | | umieść 32-bajtową wartość na stosie | | +| 80 | DUP1 | 3 | `a` | `a, a` | | sklonuj 1. wartość na stosie | | +| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | sklonuj 2. wartość na stosie | | +| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | sklonuj 3. wartość na stosie | | +| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | sklonuj 4. wartość na stosie | | +| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | sklonuj 5. wartość na stosie | | +| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | sklonuj 6. wartość na stosie | | +| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | sklonuj 7. wartość na stosie | | +| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | sklonuj 8. wartość na stosie | | +| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | sklonuj 9. wartość na stosie | | +| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | sklonuj 10. wartość na stosie | | +| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | sklonuj 11. wartość na stosie | | +| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | sklonuj 12. wartość na stosie | | +| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | sklonuj 13. wartość na stosie | | +| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | sklonuj 14. wartość na stosie | | +| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | sklonuj 15. wartość na stosie | | +| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | sklonuj 16. wartość na stosie | | +| 90 | SWAP1 | 3 | `a, b` | `b, a` | | | | +| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | | | +| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | | | +| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | | | +| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | | | +| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) | | +| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) | | +| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) | | +| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) | | +| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) | | +| A5-EF | _nieprawidłowy_ | | | | | | | +| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) | | +| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | | | +| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | to samo co DELEGATECALL, ale nie propaguje oryginalnych msg.sender i msg.value | | +| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | return mem[ost:ost+len-1] | | +| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | | +| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] | | +| F6-F9 | _nieprawidłowy_ | | | | | | | +| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | | +| FB-FC | _nieprawidłowy_ | | | | | | | +| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) | | +| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | wyznaczony nieprawidłowy kod operacji – [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | | | +| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | wysyła wszystkie ETH na `addr`; jeśli zostanie wykonane w tej samej transakcji, w której utworzono kontrakt, niszczy kontrakt | | diff --git a/public/content/translations/pl/developers/docs/frameworks/index.md b/public/content/translations/pl/developers/docs/frameworks/index.md index 3fa1025c602..17d9f582490 100644 --- a/public/content/translations/pl/developers/docs/frameworks/index.md +++ b/public/content/translations/pl/developers/docs/frameworks/index.md @@ -1,67 +1,151 @@ --- title: Frameworki programistyczne zdecentralizowanych aplikacji -description: Zapoznaj się z zaletami frameworków i porównaj dostępne opcje. +description: "Zapoznaj się z zaletami frameworków i porównaj dostępne opcje." lang: pl --- ## Wprowadzenie do frameworków {#introduction-to-frameworks} -Budowa pełnoprawnej zdecentralizowanej aplikacji wymaga różnych technologii. Frameworki programistyczne zawierają wiele z potrzebnych funkcji lub zapewniają łatwe systemy pluginów, aby wybrać narzędzia, których potrzebujesz. +Budowa pełnoprawnej zdecentralizowanej aplikacji wymaga +różnych technologii. Frameworki programistyczne zawierają wiele z potrzebnych funkcji +lub zapewniają łatwe systemy pluginów, aby wybrać narzędzia, których potrzebujesz. Te frameworki mają wiele gotowych funkcji, takich jak: -- Funkcje rozbijania lokalnej instancji blockchain. +- Funkcje do uruchomienia lokalnej instancji blockchain. - Narzędzia do kompilacji i testowania Twoich inteligentnych kontraktów. -- Dodatki programistyczne do tworzenia aplikacji przeznaczonych dla użytkowników w ramach tego samego projektu/repozytorium. -- Konfiguracja połączenia się z sieciami Ethereum i wdrażania kontraktów, niezależnie od tego, czy jest to lokalnie uruchomiona instancja, czy jedna z publicznych sieci Ethereum. -- Zdecentralizowana dystrybucja aplikacji — integracja z opcjami przechowywania, takimi jak IPFS. +- Dodatki programistyczne klienta do budowania aplikacji skierowanej do użytkownika w ramach tego samego projektu/repozytorium. +- Konfiguracja do łączenia się z sieciami Ethereum i wdrażania kontraktów, zarówno w lokalnie działającej instancji, jak i w jednej z publicznych sieci Ethereum. +- Dystrybucja aplikacji zdecentralizowanych — integracje z opcjami przechowywania, takimi jak IPFS. -## Warunki wstępne {#prerequisites} +## Wymagania wstępne {#prerequisites} -Przed zagłębieniem się w frameworki zalecamy przeczytanie naszego wprowadzenia do [aplikacji zdecentralizowanych](/developers/docs/dapps/) i [stosu Ethereum](/developers/docs/ethereum-stack/). +Zanim zagłębisz się w frameworki, zalecamy najpierw przeczytać nasze wprowadzenie do [dapek](/developers/docs/dapps/) i [stosu Ethereum](/developers/docs/ethereum-stack/). ## Dostępne frameworki {#available-frameworks} -**Hardhat —** **_środowisko programistyczne Ethereum dla profesjonalistów_** +**Foundry** - **_Foundry to niezwykle szybki, przenośny i modułowy zestaw narzędzi do tworzenia aplikacji Ethereum_** + +- [Zainstaluj Foundry](https://book.getfoundry.sh/) +- [Książka o Foundry](https://book.getfoundry.sh/) +- [Czat społeczności Foundry na Telegramie](https://t.me/foundry_support) +- [Awesome Foundry](https://github.com/crisgarner/awesome-foundry) + +**Hardhat -** **_Środowisko programistyczne Ethereum dla profesjonalistów._** - [hardhat.org](https://hardhat.org) - [GitHub](https://github.com/nomiclabs/hardhat) -**SDK OpenZeppelin —** **_najlepszy zestaw narzędzi do kontraktów inteligentnych: zestaw narzędzi, które pomogą Ci opracowywać, kompilować, aktualizować i wdrażać kontrakty inteligentne oraz przeprowadzać z nimi interakcje._** +**Ape -** **_Narzędzie do tworzenia inteligentnych kontraktów dla Pythonistów, analityków danych i specjalistów ds. bezpieczeństwa._** -- [OpenZeppelin SDK](https://openzeppelin.com/sdk/) -- [GitHub](https://github.com/OpenZeppelin/openzeppelin-sdk) -- [Forum społeczności](https://forum.openzeppelin.com/c/support/17) +- [Dokumentacja](https://docs.apeworx.io/ape/stable/) +- [GitHub](https://github.com/ApeWorX/ape) -**Brownie —** **_środowisko programistyczne i framework testowy oparty na Pythonie._** +**Web3j -** **_Platforma do tworzenia aplikacji blockchain na JVM._** -- [Dokumentacja](https://eth-brownie.readthedocs.io/en/latest/) -- [GitHub](https://github.com/eth-brownie/brownie) +- [Strona główna](https://www.web3labs.com/web3j-sdk) +- [Dokumentacja](https://docs.web3j.io) +- [GitHub](https://github.com/web3j/web3j) + +**ethers-kt -** **_Asynchroniczna, wysokowydajna biblioteka Kotlin/Java/Android dla blockchainów opartych na EVM._** -**Create Eth App —** **_tworzenie aplikacji opartych na Ethereum za pomocą jednego polecenia. Zawiera szeroką ofertę frameworków interfejsu użytkownika i szablonów DeFi do wyboru._** +- [GitHub](https://github.com/Kr1ptal/ethers-kt) +- [Przykłady](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) +- [Discord](https://discord.gg/rx35NzQGSb) + +**Create Eth App -** **_Twórz aplikacje oparte na Ethereum za pomocą jednego polecenia. Zawiera szeroką ofertę frameworków interfejsu użytkownika i szablonów DeFi do wyboru._** - [GitHub](https://github.com/paulrberg/create-eth-app) - [Szablony](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates) -**scaffold-eth —** **_Hardhat + Create Eth App: wszystko, czego potrzebujesz, aby rozpocząć budowanie zdecentralizowanych aplikacji opartych na inteligentnych kontraktach._** +**Scaffold-Eth -** **_Komponenty i hooki Ethers.js + Hardhat + React dla web3: wszystko, czego potrzebujesz, aby rozpocząć tworzenie zdecentralizowanych aplikacji opartych na inteligentnych kontraktach._** - [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) -**The Graph —** **_protokół Graph do efektywnego odpytywania danych blockchainu_** +**Tenderly -** **_Platforma deweloperska Web3, która umożliwia deweloperom blockchain tworzenie, testowanie, debugowanie, monitorowanie i obsługę inteligentnych kontraktów oraz poprawę UX dapek._** + +- [Strona internetowa](https://tenderly.co/) +- [Dokumentacja](https://docs.tenderly.co/) + +**The Graph -** **_The Graph do wydajnego odpytywania danych blockchain._** - [Strona internetowa](https://thegraph.com/) - [Samouczek](/developers/tutorials/the-graph-fixing-web3-data-querying/) -**Alchemy —** **_platforma programistyczna Ethereum._** +**Alchemy -** **_Platforma programistyczna Ethereum._** -- [alchemyapi.io](https://alchemyapi.io/) +- [alchemy.com](https://www.alchemy.com/) - [GitHub](https://github.com/alchemyplatform) -- [Discord](https://discord.gg/kwqVnrA) +- [Discord](https://discord.com/invite/alchemyplatform) + +**NodeReal -** **_Platforma deweloperska Ethereum._** + +- [Nodereal.io](https://nodereal.io/) +- [GitHub](https://github.com/node-real) +- [Discord](https://discord.gg/V5k5gsuE) + +**thirdweb SDK -** **_Twórz aplikacje web3, które mogą wchodzić w interakcje z Twoimi inteligentnymi kontraktami przy użyciu naszych potężnych SDK i CLI._** + +- [Dokumentacja](https://portal.thirdweb.com/sdk/) +- [GitHub](https://github.com/thirdweb-dev/) + +**Chainstack -** **_Platforma deweloperska Web3 (Ethereum i inne)._** + +- [chainstack.com](https://www.chainstack.com/) +- [GitHub](https://github.com/chainstack) +- [Discord](https://discord.gg/BSb5zfp9AT) + +**Crossmint -** **_Platforma deweloperska web3 klasy korporacyjnej, która pozwala tworzyć aplikacje NFT na wszystkich głównych łańcuchach EVM (i innych)._** + +- [Strona internetowa](https://www.crossmint.com) +- [Dokumentacja](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) + +**Brownie -** **_Środowisko programistyczne i framework testowy oparty na Pythonie._** + +- [Dokumentacja](https://eth-brownie.readthedocs.io/en/latest/) +- [GitHub](https://github.com/eth-brownie/brownie) +- **Brownie jest obecnie nieobsługiwany** + +**OpenZeppelin SDK -** **_Najlepszy zestaw narzędzi do inteligentnych kontraktów: pakiet narzędzi, który pomoże Ci tworzyć, kompilować, uaktualniać, wdrażać i wchodzić w interakcje z inteligentnymi kontraktami._** + +- [OpenZeppelin Defender SDK](https://docs.openzeppelin.com/defender/sdk) +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-sdk) +- [Forum społeczności](https://forum.openzeppelin.com/c/support/17) +- **Programowanie z użyciem OpenZeppelin SDK się wyczerpało** + +**Catapulta -** **_Wielołańcuchowe narzędzie do wdrażania inteligentnych kontraktów, które automatyzuje weryfikacje w eksploratorach bloków, śledzi wdrożone inteligentne kontrakty i udostępnia raporty wdrożenia. Plug-and-play dla projektów Foundry i Hardhat._** + +- [Strona internetowa](https://catapulta.sh/) +- [Dokumentacja](https://catapulta.sh/docs) +- [Github](https://github.com/catapulta-sh) + +**GoldRush (obsługiwany przez Covalent) -** **_GoldRush oferuje najbardziej kompleksowy pakiet API z danymi blockchain dla deweloperów, analityków i przedsiębiorstw._** **_Niezależnie od tego, czy budujesz pulpit DeFi, portfel, bota handlowego, agenta AI czy platformę zgodności, interfejsy API danych zapewniają szybki, dokładny i przyjazny dla programistów dostęp do niezbędnych danych on-chain, których potrzebujesz._** + +- [Strona internetowa](https://goldrush.dev/) +- [Dokumentacja](https://goldrush.dev/docs/chains/ethereum) +- [GitHub](https://github.com/covalenthq) +- [Discord](https://www.covalenthq.com/discord/) + +**Wake -** **_Wszechstronny framework w Pythonie do testowania kontraktów, fuzzingu, wdrażania, skanowania podatności i nawigacji po kodzie._** + +- [Strona główna](https://getwake.io/) +- [Dokumentacja](https://ackeeblockchain.com/wake/docs/latest/) +- [GitHub](https://github.com/Ackee-Blockchain/wake) +- [Rozszerzenie VS Code](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity) + +**Veramo -** **_Framework open source, modułowy i agnostyczny, który ułatwia deweloperom zdecentralizowanych aplikacji wbudowywanie zdecentralizowanych tożsamości i weryfikowalnych poświadczeń w swoje aplikacje._** + +- [Strona główna](https://veramo.io/) +- [Dokumentacja](https://veramo.io/docs/basics/introduction) +- [GitHub](https://github.com/uport-project/veramo) +- [Discord](https://discord.com/invite/FRRBdjemHV) +- [Pakiet NPM](https://www.npmjs.com/package/@veramo/core) ## Dalsza lektura {#further-reading} -_Znasz jakieś zasoby społeczności, które Ci pomogły? Wyedytuj tę stronę i dodaj je!_ +_Znasz jakieś zasoby społeczności, które Ci pomogły? Edytuj tę stronę i dodaj je!_ ## Powiązane tematy {#related-topics} -- [Konfigurowanie lokalnego środowiska programistycznego](/developers/local-environment/) +- [Skonfiguruj lokalne środowisko programistyczne](/developers/local-environment/) diff --git a/public/content/translations/pl/developers/docs/gas/index.md b/public/content/translations/pl/developers/docs/gas/index.md index 0e8f9a79175..0a710a4b102 100644 --- a/public/content/translations/pl/developers/docs/gas/index.md +++ b/public/content/translations/pl/developers/docs/gas/index.md @@ -1,40 +1,42 @@ --- -title: Gaz i opłaty -description: +title: "Gaz i opłaty" +metaTitle: "Opłaty i gaz w Ethereum: przegląd techniczny" +description: "Dowiedz się więcej o opłatach gazowych Ethereum, jak są obliczane oraz o ich roli w bezpieczeństwie sieci i przetwarzaniu transakcji." lang: pl --- Gaz ma kluczowe znaczenie dla sieci Ethereum. To jest paliwo, które pozwala mu działać w taki sam sposób, jak samochód potrzebuje benzyny. -## Warunki wstępne {#prerequisites} +## Wymagania wstępne {#prerequisites} -Aby lepiej zrozumieć tę stronę, zalecamy najpierw przeczytanie informacji na temat [transakcji](/developers/docs/transactions/) i [EVM](/developers/docs/evm/). +Aby lepiej zrozumieć tę stronę, zalecamy najpierw przeczytać o [transakcjach](/developers/docs/transactions/) i [EVM](/developers/docs/evm/). -## Co to jest gaz? {#what-is-gas} +## Czym jest gaz? {#what-is-gas} Gaz odnosi się do jednostki, która mierzy ilość wysiłku obliczeniowego wymaganego do wykonania określonych operacji w sieci Ethereum. Skoro każda transakcja Ethereum wymaga zasobów obliczeniowych do wykonania, te zasoby należy opłacić, aby mieć pewność, że Ethereum nie jest podatne na spam i nie może utknąć w nieskończonych pętlach obliczeniowych. Płatność za obliczenia odbywa się w formie opłaty za gaz. -Opłata za gaz to ** ilość zużytego gazu potrzebnego do wykonania jakiejś operacji, pomnożona przez koszt jednostkowy gazu**. Opłata jest pobierana niezależnie od tego, czy transakcja się powiedzie, czy nie. +Opłata za gaz to **ilość gazu zużytego do wykonania operacji, pomnożona przez koszt jednostki gazu**. Opłata jest pobierana niezależnie od tego, czy transakcja się powiedzie, czy nie. -![Schemat pokazujący, gdzie potrzebny jest nam gaz dla operacji EVM](./gas.png) _Schemat zaadaptowany z [zilustrowane EVM Ethereum](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +![Diagram pokazujący, gdzie potrzebny jest gaz w operacjach EVM](./gas.png) +_Diagram zaadaptowany z [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ Opłaty za gaz należy uiszczać w natywnej walucie Ethereum, jaką jest ether (ETH). Ceny gazu są zwykle podawane w gwei, który jest jednostką ETH. Każdy gwei jest równy jednej miliardowej ETH (0,000000001 ETH lub 10-9 ETH). Na przykład zamiast mówić, że Twój gaz kosztuje 0,000000001 ethera, możesz powiedzieć, że Twój gaz kosztuje 1 gwei. -Słowo „gwei” jest skrótem od „giga-wei”, które oznacza „miliard wei”. Jeden gwei jest równy jednemu miliardowi wei. Samo wei (nazwane na cześć [Wei Dai](https://wikipedia.org/wiki/Wei_Dai), twórcy tzw. [b-money](https://www.investopedia.com/terms/b/bmoney.asp)) jest najmniejszą jednostką ETH. +Słowo „gwei” jest skrótem od „giga-wei”, które oznacza „miliard wei”. Jeden gwei jest równy jednemu miliardowi wei. Sam Wei (nazwany na cześć [Wei Dai](https://wikipedia.org/wiki/Wei_Dai), twórcy [b-money](https://www.investopedia.com/terms/b/bmoney.asp)) jest najmniejszą jednostką ETH. ## Jak naliczane są opłaty za gaz? {#how-are-gas-fees-calculated} Możesz ustawić ilość gazu, którą chcesz zapłacić podczas przesyłania transakcji. Oferując pewną ilość gazu, tak naprawdę licytujesz swoją transakcję, aby była ona uwzględniona w następnym bloku. Jeśli zaoferujesz zbyt mało, to mniej prawdopodobne jest, że walidatory uwzględnią Twoją transakcję, co oznacza, że może ona zostać wykonana z opóźnieniem albo wcale. Jeśli zaoferujesz zbyt dużo, możesz zmarnować trochę ETH. A więc skąd wiedzieć, ile trzeba zapłacić? -Całkowity gaz, który musisz zapłacić, dzieli się na dwie części: `opłatę podstawową` oraz `opłatę priorytetową ` (napiwek). +Całkowity gaz, który płacisz, dzieli się na dwa składniki: `podstawową opłatę` i `opłatę priorytetową` (napiwek). -Ta pierwsza, czyli `opłata podstawowa`, jest ustalana przez protokół — jest to minimalna kwota, jaką musisz zapłacić, aby Twoja transakcja została uznana za ważną. Natomiast `opłata priorytetowa` to napiwek, który dodajesz do podstawowej opłaty, aby uczynić transakcję atrakcyjniejszą dla walidatorów, tak aby uwzględnili ją w następnym bloku. +`Podstawowa opłata` jest ustalana przez protokół — musisz zapłacić co najmniej tę kwotę, aby Twoja transakcja została uznana za ważną. `Opłata priorytetowa` to napiwek, który dodajesz do podstawowej opłaty, aby Twoja transakcja stała się atrakcyjna dla walidatorów, dzięki czemu wybiorą ją do włączenia w następnym bloku. -Transakcja, która płaci tylko `opłatę podstawową` jest technicznie ważną, ale mało prawdopodobne jest to, że zostanie uwzględniona, ponieważ nie zachęca w ogóle walidatorów do wybrania jej pośród innych transakcji. „Prawidłowa” opłata `priorytetowa` jest określana na podstawie wykorzystania sieci w czasie, w którym próbujesz wysłać swoją transakcję — jeśli zapotrzebowanie jest duże, to najprawdopodobniej będzie wymagane zwiększenie opłaty `priorytetowej`, ale gdy zapotrzebowanie jest mniejsze, możesz zapłacić mniej. +Transakcja, która opłaca tylko `podstawową opłatę`, jest technicznie ważna, ale jest mało prawdopodobne, że zostanie uwzględniona, ponieważ nie oferuje walidatorom żadnej zachęty do wybrania jej ponad jakąkolwiek inną transakcję. „Prawidłowa” `opłata priorytetowa` jest określana przez wykorzystanie sieci w momencie wysyłania transakcji — jeśli jest duże zapotrzebowanie, być może będziesz musiał ustawić `opłatę priorytetową` wyżej, ale gdy zapotrzebowanie jest mniejsze, możesz zapłacić mniej. Załóżmy na przykład, że Jordan chce zapłacić Taylor 1 ETH. Transfer ETH wymaga 21 000 jednostek gazu, a opłata bazowa wynosi 10 gwei. Jordan dodaje napiwek w wysokości 2 gwei. @@ -42,52 +44,56 @@ Całkowita opłata wynosiłaby teraz: `jednostki zużytego gazu * (opłata podstawowa + opłata priorytetowa)` -gdzie `opłata podstawowa` jest wartością ustalaną przez protokół, a `opłata priorytetowa` jest wartością ustalaną przez użytkownika jako napiwek dla walidatora. +gdzie `podstawowa opłata` to wartość ustalana przez protokół, a `opłata priorytetowa` to wartość ustalana przez użytkownika jako napiwek dla walidatora. -Czyli `21 000 * (10 + 2) = 252 000 gwei` (0,000252 ETH). +np. `21 000 * (10 + 2) = 252 000 gwei` (0,000252 ETH). -Kiedy Jordan wyśle pieniądze, to z jego kontra zostanie pobrana kwota w wysokości 1,000252 ETH. Taylor otrzyma 1,0000 ETH. Walidator otrzyma napiwek w wysokości 0,000042 ETH. `Opłata podstawowa` w wysokości 0,00021 ETH zostanie spalona. +Kiedy Jordan wyśle pieniądze, to z jego kontra zostanie pobrana kwota w wysokości 1,000252 ETH. Taylor otrzyma 1,0000 ETH. Walidator otrzyma napiwek w wysokości 0,000042 ETH. `Podstawowa opłata` w wysokości 0,00021 ETH jest spalana. -### Opłata podstawowa {#base-fee} +### Podstawowa opłata {#base-fee} -Każdy blok ma opłatę podstawową, która działa jako cena rezerwowa. Aby się zakwalifikować na uwzględnienie w bloku, oferowana kwota za gaz musi być co najmniej równa opłacie podstawowej. Opłata podstawowa jest obliczana niezależnie od obecnego bloku, a zamiast tego determinują ją bloki poprzedzające — co sprawia, że opłaty transakcyjne są bardziej przewidywalne dla użytkowników. Kiedy blok zostaje stworzony, ta **opłata podstawowa zostaje „spalona”**, co usuwa ją z obiegu. +Każdy blok ma opłatę podstawową, która działa jako cena rezerwowa. Aby się zakwalifikować na uwzględnienie w bloku, oferowana kwota za gaz musi być co najmniej równa opłacie podstawowej. Podstawowa opłata jest obliczana niezależnie od bieżącego bloku i jest zamiast tego określana przez bloki go poprzedzające, co sprawia, że opłaty transakcyjne są bardziej przewidywalne dla użytkowników. Gdy blok jest tworzony, ta **podstawowa opłata jest „spalana”**, co usuwa ją z obiegu. -Opłata podstawowa obliczana jest na podstawie wzoru, który porównuje wielkość poprzedniego bloku (ilość gazu wykorzystanego na wszystkie transakcje) z docelowym rozmiarem. Opłata ta wzrośnie maksymalnie o 12,5% na blok, jeśli docelowy rozmiar bloku zostanie przekroczony. Ten rosnący wzrost sprawia, że utrzymanie dużego rozmiaru bloku w nieskończoność jest ekonomicznie nieopłacalne. +Podstawowa opłata jest obliczana za pomocą wzoru, który porównuje rozmiar poprzedniego bloku (ilość gazu zużytego na wszystkie transakcje) z rozmiarem docelowym (połowa limitu gazu). Podstawowa opłata wzrośnie lub spadnie o maksymalnie 12,5% na blok, jeśli docelowy rozmiar bloku będzie odpowiednio powyżej lub poniżej celu. Ten rosnący wzrost sprawia, że utrzymanie dużego rozmiaru bloku w nieskończoność jest ekonomicznie nieopłacalne. | Numer bloku | Ilość gazu | Wzrost opłaty | Obecna opłata podstawowa | -| ----------- | ----------:| -------------:| ------------------------:| -| 1 | 15 mln | 0% | 100 gwei | -| 2 | 30 mln | 0% | 100 gwei | -| 3 | 30 mln | 12,5% | 112,5 gwei | -| 4 | 30 mln | 12,5% | 126,6 gwei | -| 5 | 30 mln | 12,5% | 142,4 gwei | -| 6 | 30 mln | 12,5% | 160,2 gwei | -| 7 | 30 mln | 12,5% | 180,2 gwei | -| 8 | 30 mln | 12,5% | 202,7 gwei | - -Zgodnie z powyższą tabelą, aby stworzyć transakcję w bloku o numerze 9, portfel poinformuje użytkownika z pewnością, że **maksymalna opłata bazowa**, którą należy zapłacić, aby zostać dodanym do następnego bloku, wynosi `obecny base fee * 112,5%` lub `202,7 gwei * 112,5% = 228,1 gwei`. +| ----------- | ---------: | ------------: | -----------------------: | +| 1 | 18 mln | 0% | 100 gwei | +| 2 | 36 mln | 0% | 100 gwei | +| 3 | 36 mln | 12,5% | 112,5 gwei | +| 4 | 36 mln | 12,5% | 126,6 gwei | +| 5 | 36 mln | 12,5% | 142,4 gwei | +| 6 | 36 mln | 12,5% | 160,2 gwei | +| 7 | 36 mln | 12,5% | 180,2 gwei | +| 8 | 36 mln | 12,5% | 202,7 gwei | + +W powyższej tabeli przedstawiono przykład z użyciem 36 milionów jako limitu gazu. Zgodnie z tym przykładem, aby utworzyć transakcję w bloku numer 9, portfel poinformuje użytkownika z całą pewnością, że **maksymalna podstawowa opłata**, która zostanie dodana do następnego bloku, wynosi `bieżąca podstawowa opłata * 112,5%` lub `202,7 gwei * 112,5% = 228,1 gwei`. Ważne jest również, aby pamiętać, że mało prawdopodobne jest to, abyśmy ujrzeli wydłużone wzrosty pełnych bloków ze względu na szybkość, z jaką podstawowa opłata wzrasta przed pełnym blokiem. -| Numer bloku | Ilość gazu | Wzrost opłaty | Obecna opłata podstawowa | -| ----------- | ----------:| -------------:| ------------------------:| -| 30 | 30 mln | 12,5% | 2705,6 gwei | -| ... | ... | 12,5% | ... | -| 50 | 30 mln | 12,5% | 28531,3 gwei | -| ... | ... | 12,5% | ... | -| 100 | 30 mln | 12,5% | 10302608,6 gwei | +| Numer bloku | Ilość gazu | Wzrost opłaty | Obecna opłata podstawowa | +| --------------------------------------------------- | --------------------------------------------------: | ------------: | --------------------------------------------------: | +| 30 | 36 mln | 12,5% | 2705,6 gwei | +| ... | ... | 12,5% | ... | +| 50 | 36 mln | 12,5% | 28531,3 gwei | +| ... | ... | 12,5% | ... | +| 100 | 36 mln | 12,5% | 10302608,6 gwei | ### Opłata priorytetowa (napiwki) {#priority-fee} -Opłata priorytetowa (napiwek) zachęca walidatorów do uwzględnienia transakcji w bloku. Bez napiwków walidatorom opłacałoby się wydobywać puste bloki, ponieważ otrzymywaliby taką samą nagrodę za blok. Małe napiwki stanowią dla walidatorów minimalną zachętę do uwzględnienia transakcji. Aby transakcje były wykonywane przed innymi transakcjami w tym samym bloku, można dodać większy napiwek, aby spróbować przelicytować konkurencyjne transakcje. +Opłata priorytetowa (napiwek) motywuje walidatorów do maksymalizacji liczby transakcji w bloku, ograniczona jedynie limitem gazu bloku. Bez napiwków racjonalny walidator mógłby włączyć mniej transakcji — lub nawet zero — bez żadnej bezpośredniej kary na warstwie wykonawczej lub warstwie konsensusu, ponieważ nagrody za staking są niezależne od liczby transakcji w bloku. Dodatkowo, napiwki pozwalają użytkownikom przebijać oferty innych w celu uzyskania pierwszeństwa w tym samym bloku, skutecznie sygnalizując pilność. ### Maksymalna opłata {#maxfee} -Aby wykonać transakcję w sieci, użytkownicy mogą określić maksymalny limit, jaki chcą zapłacić za wykonanie swojej transakcji. Ten opcjonalny parametr jest zwany `maxFeePerGas`. Żeby transakcja została wykonana, maksymalna opłata musi przewyższać sumę opłaty podstawowej i napiwku. Nadawca transakcji otrzymuje zwrot różnicy między maksymalną opłatą a sumą opłaty podstawowej i napiwku. +Aby wykonać transakcję w sieci, użytkownicy mogą określić maksymalny limit, jaki chcą zapłacić za wykonanie swojej transakcji. Ten opcjonalny parametr jest znany jako `maxFeePerGas`. Żeby transakcja została wykonana, maksymalna opłata musi przewyższać sumę opłaty podstawowej i napiwku. Nadawca transakcji otrzymuje zwrot różnicy między maksymalną opłatą a sumą opłaty podstawowej i napiwku. ### Rozmiar bloku {#block-size} -Każdy blok ma docelowy rozmiar 30 milionów gazu, ale rozmiar bloków będzie zwiększać się lub zmniejszać zgodnie z zapotrzebowaniem sieci, aż do limitu bloku wynoszącego 60 milionów gazu (dwukrotność docelowego rozmiaru bloku). Protokół osiąga zrównoważony rozmiar bloku wynoszący średnio 30 milionów poprzez proces nazywany _tâtonnement_. Oznacza to, że jeśli rozmiar bloku jest większy niż docelowy rozmiar bloku, protokół zwiększy opłatę podstawową dla kolejnego bloku. Podobnie również protokół zmniejszy opłatę podstawową, jeśli rozmiar bloku jest mniejszy niż docelowy rozmiar bloku. Kwotą, o jaką opłata podstawowa zostaje dostosowana, jest proporcjonalna do tego, jak daleko aktualny rozmiar bloku znajduje się od tego docelowego. [Więcej na temat bloków](/developers/docs/blocks/). +Każdy blok ma docelowy rozmiar równy połowie bieżącego limitu gazu, ale rozmiar bloków będzie się zwiększał lub zmniejszał w zależności od zapotrzebowania sieci, aż do osiągnięcia limitu bloku (2x docelowy rozmiar bloku). Protokół osiąga średni rozmiar bloku w równowadze na poziomie docelowym poprzez proces _tâtonnement_. Oznacza to, że jeśli rozmiar bloku jest większy niż docelowy rozmiar bloku, protokół zwiększy opłatę podstawową dla kolejnego bloku. Podobnie również protokół zmniejszy opłatę podstawową, jeśli rozmiar bloku jest mniejszy niż docelowy rozmiar bloku. + +Kwotą, o jaką opłata podstawowa zostaje dostosowana, jest proporcjonalna do tego, jak daleko aktualny rozmiar bloku znajduje się od tego docelowego. Jest to liniowe obliczenie od -12,5% dla pustego bloku, 0% przy rozmiarze docelowym, do +12,5% dla bloku osiągającego limit gazu. Limit gazu może z czasem ulegać wahaniom w zależności od sygnałów walidatorów, a także poprzez aktualizacje sieci. Możesz [zobaczyć zmiany w limicie gazu w czasie tutaj](https://eth.blockscout.com/stats/averageGasLimit?interval=threeMonths). + +[Więcej o blokach](/developers/docs/blocks/) ### Obliczanie opłat za gaz w praktyce {#calculating-fees-in-practice} @@ -97,15 +103,16 @@ Możesz jasno określić, ile jesteś w stanie zapłacić za wykonanie transakcj Krótko mówiąc, opłaty za gaz pomagają utrzymać bezpieczeństwo sieci Ethereum. Wymagając opłaty za każde obliczenie wykonane w sieci, zapobiegamy jej spamowaniu przez złośliwe podmioty. Aby uniknąć przypadkowym lub wrogim nieskończonym pętlom lub innym stratom obliczeniowym w kodzie, każda transakcja musi ustawić limit kroków obliczeniowych wykonania kodu, których może użyć. Podstawową jednostką obliczeniową jest „gaz”. -Pomimo tego, że transakcja zawiera limit, gaz niewykorzystany w transakcji zostaje zwrócony użytkownikowi (zwrócona zostaje `opłata maksymalna - (opłata podstawowa + napiwek))`. +Chociaż transakcja zawiera limit, każdy niewykorzystany gaz w transakcji jest zwracany użytkownikowi (np. zwracane jest `maksymalna opłata - (podstawowa opłata + napiwek)`). -![Schemat pokazujący, w jaki sposób zwracany jest niewykorzystany gaz](../transactions/gas-tx.png) _Schemat zaadaptowany z [zilustrowane EVM Ethereum](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +![Diagram pokazujący, jak zwracany jest niewykorzystany gaz](../transactions/gas-tx.png) +_Diagram zaadaptowany z [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ ## Czym jest limit gazu? {#what-is-gas-limit} -Limit gazu odnosi się do maksymalnej ilości gazu, jaką jesteś w stanie zużyć na transakcję. Bardziej skomplikowane transakcje wykorzystujące [inteligentne kontrakty](/developers/docs/smart-contracts/) wymagają więcej pracy obliczeniowej, a więc wymagają większego limitu gazu, niż zwykła płatność. Zwykły transfer ETH wymaga limitu gazu w wysokości 21 000 jednostek gazu. +Limit gazu odnosi się do maksymalnej ilości gazu, jaką jesteś w stanie zużyć na transakcję. Bardziej skomplikowane transakcje z udziałem [inteligentnych kontraktów](/developers/docs/smart-contracts/) wymagają więcej pracy obliczeniowej, więc wymagają wyższego limitu gazu niż prosta płatność. Zwykły transfer ETH wymaga limitu gazu w wysokości 21 000 jednostek gazu. -Na przykład jeśli ustawisz limit gazu na 50 000 dla zwykłego transferu ETH, EVM zużyje 21 000, a pozostałe 29 000 otrzymasz z powrotem. Jeśli jednak ustawisz zbyt mało gazu, na przykład 20 000 dla zwykłego transferu ETH, to EVM zużyje te 20 000 jednostek gazu próbując zrealizować transakcję, ale nie zostanie ona zakończona. EVM następnie przywróci wszelkie zmiany, ale ponieważ walidator wykonał już pracę wartą 20 000 jednostek gazu, to zostaje on zużyty. +Na przykład jeśli ustawisz limit gazu na 50 000 dla zwykłego transferu ETH, EVM zużyje 21 000, a pozostałe 29 000 otrzymasz z powrotem. Jeśli jednak wyznaczysz zbyt małą ilość gazu, na przykład limit 20000 dla prostego transferu ETH, transakcja nie powiedzie się w fazie walidowania. Zostanie odrzucona przed dodaniem do bloku, w wyniku czego gaz nie zostanie zużyty. Z drugiej strony, jeśli transakcja wyczerpie limit gazu w trakcie działania (np. inteligentny kontrakt zużyje cały gaz w połowie drogi), EVM anuluje wszystkie zmiany, ale cały wyznaczony gaz zostanie zużyty w zamian za wykonaną pracę. ## Dlaczego opłaty za gaz są tak wysokie? {#why-can-gas-fees-get-so-high} @@ -113,26 +120,32 @@ Opłaty za gaz są wysokie ze względu na popularność Ethereum. Jeśli zapotrz ## Inicjatywy mające na celu zmniejszenie kosztów gazu {#initiatives-to-reduce-gas-costs} -[Ulepszenia skalowalności](/roadmap/) Ethereum powinny ostatecznie rozwiązać niektóre problemy związane z opłatami za gaz, co z kolei umożliwi platformie przetwarzanie tysięcy transakcji na sekundę oraz skalowanie na skalę światową. +[Aktualizacje skalowalności](/roadmap/) Ethereum powinny ostatecznie rozwiązać niektóre z problemów związanych z opłatami za gaz, co z kolei umożliwi platformie przetwarzanie tysięcy transakcji na sekundę i skalowanie na całym świecie. + +Skalowanie warstwy 2 jest główną inicjatywą mająca na celu poprawę kosztów gazu, doświadczenia użytkownika oraz skalowalności. -Skalowanie warstwy 2 jest główną inicjatywą mająca na celu poprawę kosztów gazu, doświadczenia użytkownika oraz skalowalności. [Więcej na temat skalowania warstwy 2](/developers/docs/scaling/#layer-2-scaling). +[Więcej o skalowaniu warstwy 2](/developers/docs/scaling/#layer-2-scaling) ## Monitorowanie opłat za gaz {#monitoring-gas-fees} Jeśli chcesz monitorować ceny gazu, aby taniej wysłać swoje ETH, możesz skorzystać z wielu różnych narzędzi, takich jak: -- [Etherscan](https://etherscan.io/gastracker) _Estymator cen gazu za transakcję_ -- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _Rozszerzenie przeglądarki Chrome do szacowania cen gazu wspierające zarówno starsze transakcje typu 0, jak i transakcje EIP-1559 typu 2._ -- [Cryptoneur Gas Fees Calculator](https://www.cryptoneur.xyz/gas-fees-calculator) _Oblicz opłaty za gaz w swojej walucie dla różnych typów transakcji w sieci głównej, Arbitrum oraz na Polygon._ +- [Etherscan](https://etherscan.io/gastracker) _Narzędzie do szacowania ceny gazu transakcyjnego_ +- [Blockscout](https://eth.blockscout.com/gas-tracker) _Narzędzie open source do szacowania ceny gazu transakcyjnego_ +- [ETH Gas Tracker](https://www.ethgastracker.com/) _Monitoruj i śledź ceny gazu Ethereum i L2, aby zmniejszyć opłaty transakcyjne i oszczędzać pieniądze_ +- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _Rozszerzenie do Chrome szacujące opłaty za gaz, obsługujące zarówno transakcje starszego typu (Typ 0), jak i transakcje EIP-1559 (Typ 2)._ +- [Cryptoneur Gas Fees Calculator](https://www.cryptoneur.xyz/gas-fees-calculator) _Obliczaj opłaty za gaz w swojej lokalnej walucie dla różnych typów transakcji w sieciach Mainnet, Arbitrum i Polygon._ ## Powiązane narzędzia {#related-tools} -- [Blocknative's Gas Platform](https://www.blocknative.com/gas) _API do szacowania cen gazu zasilany przez światową platformę danych puli pamięci (mempool) firmy Blocknative_ +- [Platforma gazowa Blocknative](https://www.blocknative.com/gas) _API do szacowania opłat za gaz, zasilane przez globalną platformę danych mempool firmy Blocknative_ +- [Gas Network](https://gas.network) Wyrocznie gazu on-chain. Wsparcie dla ponad 35 łańcuchów. ## Dalsza lektura {#further-reading} -- [Objaśnienia dotyczące gazu Ethereum](https://defiprime.com/gas) -- [Zmniejszanie zużycia gazu przez Twój inteligentny kontrakt](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a) +- [Wyjaśnienie gazu w Ethereum](https://defiprime.com/gas) +- [Zmniejszanie zużycia gazu przez Twoje inteligentne kontrakty](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a) - [Strategie optymalizacji gazu dla deweloperów](https://www.alchemy.com/overviews/solidity-gas-optimization) -- [Dokumenty EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) +- [Dokumentacja EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). - [Zasoby EIP-1559 Tima Beiko](https://hackmd.io/@timbeiko/1559-resources) +- [EIP-1559: oddzielanie mechanizmów od memów](https://web.archive.org/web/20241126205908/https://research.2077.xyz/eip-1559-separating-mechanisms-from-memes) diff --git a/public/content/translations/pl/developers/docs/ides/index.md b/public/content/translations/pl/developers/docs/ides/index.md index 6a7211abfc2..b4aee359339 100644 --- a/public/content/translations/pl/developers/docs/ides/index.md +++ b/public/content/translations/pl/developers/docs/ides/index.md @@ -1,35 +1,64 @@ --- -title: Zintegrowane środowiska programistyczne (IDEs) -description: +title: "Zintegrowane środowiska programistyczne (IDE)" +description: "Dowiedz się więcej o internetowych i desktopowych środowiskach IDE do tworzenia aplikacji na Ethereum, w tym o Remix, VS Code i popularnych wtyczkach." lang: pl --- -Jeśli chodzi o konfigurowanie [zintegrowanego środowiska programistycznego (IDE)](https://wikipedia.org/wiki/Integrated_development_environment), budowanie za pomocą Ethereum jest podobne do każdego innego projektu oprogramowania. Jest wiele opcji do wyboru, więc pod koniec dnia wybierz to, które najlepiej pasuje do twoich preferencji. +Jeśli chodzi o konfigurowanie [zintegrowanego środowiska programistycznego (IDE)](https://wikipedia.org/wiki/Integrated_development_environment), programowanie aplikacji na Ethereum jest podobne do programowania każdego innego projektu oprogramowania. Istnieje wiele możliwości do wyboru, więc na początek wybierz IDE lub edytor kodu, który najlepiej pasuje do Twoich preferencji. Najprawdopodobniej najlepszym wyborem IDE dla programowania Ethereum będzie IDE, którego używasz już do tradycyjnego tworzenia oprogramowania. -## Internetowe IDE {#web-based-ides} +## Środowiska IDE oparte na sieci {#web-based-ides} -Jeśli szukasz kodu przed [skonfigurowaniem lokalnego środowiska programistycznego](/developers/local-environment/), te aplikacje sieciowe są utworzone specjalnie do tworzenia inteligentnych kontraktów Ethereum. +Jeśli chcesz poeksperymentować z kodem, zanim [skonfigurujesz lokalne środowisko programistyczne](/developers/local-environment/), te aplikacje internetowe są stworzone specjalnie do tworzenia inteligentnych kontraktów Ethereum. -**Remix —** **_internetowe środowisko IDE z wbudowaną analizą statyczną i testowa maszyna wirtualna blockchainu._** +**[Remix](https://remix.ethereum.org/)** – **_internetowe środowisko IDE z wbudowaną analizą statyczną i testową maszyną wirtualną blockchain_** -- [remix.ethereum.org](https://remix.ethereum.org/) +- [Dokumentacja](https://remix-ide.readthedocs.io/en/latest/#) +- [Gitter](https://gitter.im/ethereum/remix) -**EthFiddle —** **_internetowe IDE, które umożliwia pisanie, kompilowanie i debugowanie inteligentnego kontraktu._** +**[ChainIDE](https://chainide.com/)** – **_wielołańcuchowe środowisko IDE oparte na chmurze_** + +- [Dokumentacja](https://chainide.gitbook.io/chainide-english-1/) +- [Forum pomocy](https://forum.chainide.com/) + +**[Replit (Solidity Starter – Beta)](https://replit.com/@replit/Solidity-starter-beta)** – **_konfigurowalne środowisko programistyczne dla Ethereum z przeładowywaniem na gorąco, sprawdzaniem błędów i obsługą sieci testowej pierwszej klasy_** + +- [Dokumentacja](https://docs.replit.com/) + +**[Tenderly Sandbox](https://sandbox.tenderly.co/)** – **_szybkie środowisko do prototypowania, w którym można pisać, wykonywać i debugować inteligentne kontrakty w przeglądarce przy użyciu Solidity i JavaScript_** + +**[EthFiddle](https://ethfiddle.com/)** – **_internetowe środowisko IDE, które pozwala pisać, kompilować i debugować inteligentne kontrakty_** -- [ethfiddle.com](https://ethfiddle.com/) - [Gitter](https://gitter.im/loomnetwork/ethfiddle) -## Desktopowe IDE {#desktop-ides} +## Desktopowe środowiska IDE {#desktop-ides} Większość utworzonych IDE ma wbudowane wtyczki, aby poprawić jakość pracy nad Ethereum. Zapewniają co najmniej podświetlanie składni dla [języków inteligentnych kontraktów](/developers/docs/smart-contracts/languages/). -**Visual Studio Code —** **_profesjonalne wieloplatformowe środowisko IDE z oficjalną obsługą Ethereum._** +**Visual Studio Code –** **_profesjonalne, wieloplatformowe środowisko IDE z oficjalnym wsparciem Ethereum_** - [Visual Studio Code](https://code.visualstudio.com/) -- [Azure Blockchain Workbench](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/microsoft-azure-blockchain.azure-blockchain-workbench?tab=Overview) - [Przykłady kodu](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md) - [GitHub](https://github.com/microsoft/vscode) +**IDE od JetBrains (IntelliJ IDEA, itp.) -** **_Niezbędne narzędzia dla programistów oraz zespołów_** + +- [JetBrains](https://www.jetbrains.com/) +- [GitHub](https://github.com/JetBrains) +- [IntelliJ Solidity](https://github.com/intellij-solidity/intellij-solidity/) + +**Remix Desktop –** **_Poznaj Remix IDE na swoim lokalnym komputerze_** + +- [Pobierz](https://github.com/ethereum/remix-desktop/releases) +- [GitHub](https://github.com/ethereum/remix-desktop) + +## Wtyczki i rozszerzenia {#plugins-extensions} + +- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) – język Ethereum Solidity dla Visual Studio Code +- [Solidity + Hardhat for VS Code](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) – obsługa Solidity i Hardhat przez zespół Hardhat +- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) – formater kodu używający prettier + ## Dalsza lektura {#further-reading} -_Znasz jakieś zasoby społeczności, które Ci pomogły? Wyedytuj tę stronę i dodaj je!_ +- [Środowiska IDE dla Ethereum](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _– lista środowisk IDE dla Ethereum od Alchemy_ + +_Znasz jakieś zasoby społeczności, które Ci pomogły? Edytuj tę stronę i dodaj je!_ diff --git a/public/content/translations/pl/developers/docs/index.md b/public/content/translations/pl/developers/docs/index.md index 52caf516cb6..39b5efcb693 100644 --- a/public/content/translations/pl/developers/docs/index.md +++ b/public/content/translations/pl/developers/docs/index.md @@ -1,22 +1,22 @@ --- title: Dokumentacja rozwoju Ethereum -description: Przedstawiamy dokumentację programisty ethereum.org. +description: "Przedstawiamy dokumentację programisty ethereum.org." lang: pl --- Ta dokumentacja jest zaprojektowana tak, aby pomóc Ci tworzyć z Ethereum. Obejmuje Ethereum jako koncepcję, wyjaśnia stos technologii Ethereum i dokumentuje zaawansowane tematy dla bardziej złożonych zastosowań i przypadków użycia. -To jest wysiłek społeczności open-source'owej, więc zachęcamy do sugerowania nowych tematów, dodawania nowych treści i dostarczania przykładów wszędzie tam, gdzie Twoim zdaniem może to być pomocne. Całą dokumentację można edytować za pośrednictwem GitHub – jeśli nie masz pewności, jak to zrobić [postępuj zgodnie z tymi instrukcjami](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md). +To jest wysiłek społeczności open-source'owej, więc zachęcamy do sugerowania nowych tematów, dodawania nowych treści i dostarczania przykładów wszędzie tam, gdzie Twoim zdaniem może to być pomocne. Całą dokumentację można edytować za pośrednictwem GitHuba – jeśli nie wiesz, jak to zrobić, [postępuj zgodnie z tymi instrukcjami](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md). -## Moduły rozwojowe {#development-modules} +## Moduły programistyczne {#development-modules} Jeśli jest to Twoja pierwsza próba rozwoju Ethereum, zalecamy zacząć od początku i przerobić to jak książkę. -### Zagadnienia podstawowe {#foundational-topics} +### Tematy podstawowe {#foundational-topics} -### stos Ethereum {#ethereum-stack} +### Stos Ethereum {#ethereum-stack} diff --git a/public/content/translations/pl/developers/docs/intro-to-ether/index.md b/public/content/translations/pl/developers/docs/intro-to-ether/index.md index bbe36deb762..efc489bba2c 100644 --- a/public/content/translations/pl/developers/docs/intro-to-ether/index.md +++ b/public/content/translations/pl/developers/docs/intro-to-ether/index.md @@ -1,12 +1,12 @@ --- -title: Wprowadzenie do etheru +title: Techniczne wprowadzenie do etheru description: Wprowadzenie programisty do kryptowaluty ether. lang: pl --- -## Wymogi wstępne {#prerequisites} +## Wymagania wstępne {#prerequisites} -Aby lepiej zrozumieć tę stronę, zalecamy najpierw przeczytanie naszego [wprowadzenia do Ethereum](/developers/docs/intro-to-ethereum/). +Aby lepiej zrozumieć tę stronę, zalecamy najpierw przeczytanie [Wprowadzenia do Ethereum](/developers/docs/intro-to-ethereum/). ## Czym jest kryptowaluta? {#what-is-a-cryptocurrency} @@ -16,17 +16,17 @@ Kryptowaluta jest środkiem wymiany zabezpieczonym przez rejestr oparty na block Pierwszą kryptowalutą był Bitcoin, stworzony przez Satoshi Nakamoto. Od czasu premiery Bitcoina w 2009 r. ludzie stworzyli tysiące kryptowalut w wielu różnych blockchainach. -## Czym jest eter? {#what-is-ether} +## Czym jest ether? {#what-is-ether} -**Ether (ETH)** to kryptowaluta używana do wielu rzeczy w sieci Ethereum. Zasadniczo jest to jedyna akceptowalna forma płatności za opłaty transakcyjne, a po [Połączeniu](/roadmap/merge), ether jest wymagany do walidacji i proponowania bloków w sieci głównej. Ether jest również wykorzystywany jako podstawowa forma zabezpieczenia na rynkach pożyczkowych [DeFi](/defi), jako jednostka rozliczeniowa na rynkach NFT, jako płatność za świadczenie usług lub sprzedaż towarów w świecie rzeczywistym i nie tylko. +**Ether (ETH)** to kryptowaluta używana do wielu rzeczy w sieci Ethereum. Zasadniczo jest to jedyna akceptowalna forma płatności za opłaty transakcyjne, a po [The Merge](/roadmap/merge) ether jest wymagany do walidacji i proponowania bloków w sieci głównej. Ether jest również wykorzystywany jako podstawowa forma zabezpieczenia na rynkach pożyczkowych [DeFi](/defi), jako jednostka rozliczeniowa na rynkach NFT, jako płatność za świadczenie usług lub sprzedaż towarów w świecie rzeczywistym i nie tylko. -Ethereum umożliwia programistom tworzenie [**zdecentralizowanych aplikacji (dapps)**](/developers/docs/dapps), które współdzielą pulę mocy obliczeniowej. Ta wspólna pula jest ograniczona, więc Ethereum potrzebuje mechanizmu określającego, kto może z niej korzystać. W przeciwnym razie zdecentralizowana aplikacja mogłaby przypadkowo lub złośliwie wykorzystać wszystkie zasoby sieciowe, co zablokowałoby innym dostęp do nich. +Ethereum umożliwia programistom tworzenie [**aplikacji zdecentralizowanych (dapki)**](/developers/docs/dapps), które współdzielą pulę mocy obliczeniowej. Ta wspólna pula jest ograniczona, więc Ethereum potrzebuje mechanizmu określającego, kto może z niej korzystać. W przeciwnym razie zdecentralizowana aplikacja mogłaby przypadkowo lub złośliwie wykorzystać wszystkie zasoby sieciowe, co zablokowałoby innym dostęp do nich. -Kryptowaluta ether obsługuje mechanizm wyceny mocy obliczeniowej Ethereum. Kiedy użytkownicy chcą dokonać transakcji, muszą zapłacić ether, aby ich transakcja została rozpoznana w blockchainie. Te koszty użytkowania są znane jako [opłaty za gaz](/developers/docs/gas/), a opłata za gaz zależy od ilości mocy obliczeniowej wymaganej do wykonania transakcji i zapotrzebowania na moc obliczeniową w całej sieci w danym momencie. +Kryptowaluta ether obsługuje mechanizm wyceny mocy obliczeniowej Ethereum. Kiedy użytkownicy chcą dokonać transakcji, muszą zapłacić ether, aby ich transakcja została rozpoznana w blockchainie. Koszty te znane są jako [opłaty za gaz](/developers/docs/gas/), a wysokość opłaty za gaz zależy od ilości mocy obliczeniowej wymaganej do wykonania transakcji i zapotrzebowania na moc obliczeniową w całej sieci w danym momencie. W związku z tym, nawet jeśli złośliwa aplikacja przesłała nieskończoną pętlę, transakcja ostatecznie wyczerpałaby ether i zakończyłaby się, umożliwiając sieci powrót do normalnego stanu. -[Powszechne](https://www.reuters.com/article/us-crypto-currencies-lending-insight-idUSKBN25M0GP#:~:text=price%20of%20ethereum) [jest](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845#:~:text=cryptocurrencies%20including%20ethereum) [łączenie](https://www.cnn.com/2021/03/14/tech/nft-art-buying/index.html#:~:text=price%20of%20ethereum) terminów Ethereum i ether — kiedy ludzie odnoszą się do „ceny Ethereum”, opisują cenę etheru. +[Powszechnie myli się](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845) Ethereum z etherem — kiedy ludzie mówią o "cenie Ethereum", tak naprawdę opisują cenę etheru. ## Wybijanie etheru {#minting-ether} @@ -38,11 +38,11 @@ Ether jest wybijany jako nagroda za każdy zaproponowany blok i w każdym punkci Oprócz tworzenia etheru poprzez nagrody blokowe ether może zostać zniszczony w procesie zwanym „spalaniem”. Po spaleniu ether zostaje trwale usunięty z obiegu. -Spalanie etheru występuje w każdej transakcji na Ethereum. Gdy użytkownicy płacą za swoje transakcje, podstawowa opłata za gaz, ustalona przez sieć zgodnie z zapotrzebowaniem na transakcje, zostaje zniszczona. W połączeniu ze zmiennymi rozmiarami bloków i maksymalną opłatą za gaz upraszcza to szacowanie opłat transakcyjnych na Ethereum. Gdy zapotrzebowanie sieci jest wysokie, [bloki](https://etherscan.io/block/12965263) mogą spalić więcej etheru niż wybijają, skutecznie kompensując emisję etheru. +Spalanie etheru występuje w każdej transakcji na Ethereum. Gdy użytkownicy płacą za swoje transakcje, podstawowa opłata za gaz, ustalona przez sieć zgodnie z zapotrzebowaniem na transakcje, zostaje zniszczona. W połączeniu ze zmiennymi rozmiarami bloków i maksymalną opłatą za gaz upraszcza to szacowanie opłat transakcyjnych na Ethereum. Gdy zapotrzebowanie w sieci jest wysokie, [bloki](https://eth.blockscout.com/block/22580057) mogą spalić więcej etheru niż go wybijają, skutecznie kompensując jego emisję. -Spalenie opłaty podstawowej utrudnia producentom bloków manipulowanie transakcjami. Na przykład jeśli producenci bloków otrzymaliby opłatę podstawową, mogliby włączyć własne transakcje za darmo i podnieść opłatę podstawową dla wszystkich innych. Ewentualnie mogliby oni zwrócić opłatę podstawową niektórym użytkownikom poza łańcuchem, prowadząc do bardziej nieprzejrzystego i złożonego rynku opłat transakcyjnych. +Spalenie opłaty podstawowej utrudnia producentom bloków manipulowanie transakcjami. Na przykład jeśli producenci bloków otrzymaliby opłatę podstawową, mogliby włączyć własne transakcje za darmo i podnieść opłatę podstawową dla wszystkich innych. Alternatywnie, mogliby oni zwracać podstawową opłatę niektórym użytkownikom offchain, co prowadziłoby do bardziej nieprzejrzystego i złożonego rynku opłat transakcyjnych. -## Nominały etheru {#denominations} +## Denominacje etheru {#denominations} Ponieważ wartość wielu transakcji na Ethereum jest niewielka, ether ma kilka nominałów, które można określić jako mniejsze jednostki rozliczeniowe. Spośród tych nominałów szczególnie ważne są Wei i gwei. @@ -57,22 +57,22 @@ Gwei, skrót od giga-wei, jest często używany do opisywania kosztów gazu w Et ## Przesyłanie etheru {#transferring-ether} -Każda transakcja na Ethereum zawiera pole `value`, które określa ilość etheru do przesłania, denominowaną w wei, w celu wysłania z adresu nadawcy na adres odbiorcy. +Każda transakcja w Ethereum zawiera pole `value`, które określa ilość etheru do przesłania, wyrażoną w wei, z adresu nadawcy na adres odbiorcy. -Gdy adres odbiorcy jest [inteligentnym kontraktem](/developers/docs/smart-contracts/), przekazany ether może zostać wykorzystany do zapłaty za gaz, gdy inteligentny kontrakt zrealizuje swój kod. +Gdy adres odbiorcy jest [inteligentnym kontraktem](/developers/docs/smart-contracts/), ten przesłany ether może zostać wykorzystany do zapłaty za gaz, gdy inteligentny kontrakt wykona swój kod. [Więcej o transakcjach](/developers/docs/transactions/) -## Sprawdzanie etheru {#querying-ether} +## Sprawdzanie salda etheru {#querying-ether} -Użytkownicy mogą sprawdzić saldo etheru dowolnego [konta](/developers/docs/accounts/) poprzez sprawdzenie pola `balance` konta, które pokazuje zasoby etheru denominowane w wei. +Użytkownicy mogą sprawdzić saldo etheru dowolnego [konta](/developers/docs/accounts/), sprawdzając pole `balance` konta, które pokazuje posiadany ether wyrażony w wei. -[Etherscan](https://etherscan.io) to popularne narzędzie do sprawdzania sald adresów za pośrednictwem aplikacji internetowej. Na przykład [ta strona Etherscan](https://etherscan.io/address/0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae) pokazuje saldo Fundacji Ethereum. Salda kont można również sprawdzać za pomocą portfeli lub bezpośrednio, wysyłając żądania do węzłów. +[Etherscan](https://etherscan.io) i [Blockscout](https://eth.blockscout.com) to popularne narzędzia do sprawdzania sald adresów za pośrednictwem aplikacji internetowych. Na przykład [ta strona Blockscout](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe) pokazuje saldo dla Ethereum Foundation. Salda kont można również sprawdzać za pomocą portfeli lub bezpośrednio, wysyłając żądania do węzłów. ## Dalsza lektura {#further-reading} -- [Definiowanie Etheru i Ethereum](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) — _Grupa CME_ -- [Biała księga Ethereum](/whitepaper/): Oryginalna propozycja dla Ethereum. Dokument ten zawiera opis etheru i motywacji stojącej za jego stworzeniem. -- [Kalkulator Gwei](https://www.alchemy.com/gwei-calculator): Użyj tego kalkulatora gwei, aby łatwo konwertować wei, gwei i ether. Wystarczy wprowadzić dowolną ilość wei, gwei lub ETH, aby automatycznie obliczyć konwersję. +- [Definiowanie etheru i Ethereum](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) – _CME Group_ +- [Biała księga Ethereum](/whitepaper/): Oryginalna propozycja Ethereum. Dokument ten zawiera opis etheru i motywacji stojącej za jego stworzeniem. +- [Kalkulator Gwei](https://www.alchemy.com/gwei-calculator): Użyj tego kalkulatora gwei, aby łatwo przeliczać wei, gwei i ether. Wystarczy wprowadzić dowolną ilość wei, gwei lub ETH, aby automatycznie obliczyć konwersję. -_Znasz jakieś zasoby społeczności, które Ci pomogły? Wyedytuj tę stronę i dodaj je!_ +_Znasz jakieś zasoby społeczności, które Ci pomogły? Edytuj tę stronę i dodaj je!_ diff --git a/public/content/translations/pl/developers/docs/intro-to-ethereum/index.md b/public/content/translations/pl/developers/docs/intro-to-ethereum/index.md index b6aff1a98f3..48e2aacc275 100644 --- a/public/content/translations/pl/developers/docs/intro-to-ethereum/index.md +++ b/public/content/translations/pl/developers/docs/intro-to-ethereum/index.md @@ -1,6 +1,6 @@ --- -title: Wprowadzenie do Ethereum -description: Wprowadzenie programisty aplikacji zdecentralizowanych do podstawowych pojęć Ethereum. +title: "Wstęp techniczny do Ethereum" +description: "Wprowadzenie programisty aplikacji zdecentralizowanych do podstawowych pojęć Ethereum." lang: pl --- @@ -8,15 +8,15 @@ lang: pl Blockchain to publiczna baza danych, która jest aktualizowana i udostępniana na wielu komputerach w sieci. -„Blok” odnosi się do faktu, że dane i stan są przechowywane w sekwencyjnych partiach lub „blokach”. Jeśli wysyłasz ETH do kogoś innego, dane transakcji muszą zostać dodane do bloku, aby mogły być skuteczne. +„Blok” odnosi się do faktu, że dane i stan są przechowywane w sekwencyjnych partiach lub „blokach”. Jeśli wysyłasz ETH do kogoś innego, dane transakcji muszą zostać dodane do bloku, aby zakończyła się ona powodzeniem. „Chain” odnosi się do faktu, że każdy blok kryptograficznie odwołuje się do swojego rodzica (nadrzędnego elementu). Innymi słowy, bloki są łączone w łańcuchy. Dane w bloku nie mogą ulec zmianie bez zmiany wszystkich kolejnych bloków, co wymagałoby konsensusu całej sieci. Każdy komputer w sieci musi zgodzić się na każdy nowy blok i łańcuch jako całość. Te komputery nazywane są „węzłami”. Węzły zapewniają, że każda osoba wchodząca w interakcję z blockchainem ma te same dane. Aby osiągnąć to rozproszone porozumienie, blockchainy potrzebują mechanizmu konsensusu. -Ethereum wykorzystuje [mechanizm konsensusu oparty na proof-of-stake](/developers/docs/consensus-mechanisms/pos/). Każdy, kto chce dodać nowe bloki do łańcucha, musi stakować ETH — natywną walutę Ethereum — jako zabezpieczenie i uruchomić oprogramowanie walidatora. Te „walidatory” mogą być następnie losowo wybierane do proponowania bloków, które inne walidatory sprawdzają i dodają do blockchainu. Istnieje system nagród i kar, który silnie motywuje uczestników do bycia uczciwymi i dostępnymi online tak długo, jak to możliwe. +Ethereum używa [mechanizmu konsensusu opartego na proof-of-stake](/developers/docs/consensus-mechanisms/pos/). Każdy, kto chce dodać nowe bloki do łańcucha, musi stakować ETH — natywną walutę Ethereum — jako zabezpieczenie i uruchomić oprogramowanie walidatora. Te „walidatory” mogą być następnie losowo wybierane do proponowania bloków, które inne walidatory sprawdzają i dodają do blockchainu. Istnieje system nagród i kar, który silnie motywuje uczestników do bycia uczciwymi i dostępnymi online tak długo, jak to możliwe. -Jeśli chcesz zobaczyć, jak dane blockchainu są hashowane, a następnie dołączane do historii odniesień bloków, koniecznie sprawdź [to demo](https://andersbrownworth.com/blockchain/blockchain) Andersa Brownwortha i obejrzyj jego film poniżej. +Jeśli chcesz zobaczyć, jak dane blockchaina są haszowane, a następnie dołączane do historii odwołań do bloków, koniecznie sprawdź [to demo](https://andersbrownworth.com/blockchain/blockchain) autorstwa Andersa Brownwortha i obejrzyj towarzyszący mu film poniżej. Zobacz, jak Anders wyjaśnia hashe w blockchainach: @@ -34,7 +34,7 @@ Mechanizmy kryptograficzne gwarantują, że po zweryfikowaniu transakcji jako po ## Czym jest ether? {#what-is-ether} -**Ether (ETH)** jest natywną kryptowalutą Ethereum. Celem ETH jest umożliwienie rynku obliczeń. Taki rynek stanowi ekonomiczną zachętę dla uczestników do weryfikowania i wykonywania żądań transakcji oraz dostarczania zasobów obliczeniowych do sieci. +**Ether (ETH)** to natywna kryptowaluta Ethereum. Celem ETH jest umożliwienie rynku obliczeń. Taki rynek stanowi ekonomiczną zachętę dla uczestników do weryfikowania i wykonywania żądań transakcji oraz dostarczania zasobów obliczeniowych do sieci. Każdy uczestnik, który wysyła żądanie transakcji, musi również zaoferować pewną ilość ETH do sieci jako nagrodę. Sieć spali część tej nagrody, a resztę przyzna temu, kto ostatecznie wykona pracę polegającą na weryfikacji transakcji, wykonaniu jej, zatwierdzeniu jej w blockchainie i rozesłaniu jej do sieci. @@ -44,7 +44,7 @@ ETH jest również wykorzystywane do zapewnienia bezpieczeństwa kryptoekonomicz ## Czym są inteligentne kontrakty? {#what-are-smart-contracts} -W praktyce uczestnicy nie piszą nowego kodu za każdym razem, gdy chcą zażądać obliczeń na EVM. Jest raczej tak, że programiści aplikacji przesyłają programy (fragmenty kodu wielokrotnego użytku) do stanu EVM, a użytkownicy wysyłają żądania wykonania tych fragmentów kodu z różnymi parametrami. Programy przesyłane do sieci i wykonywane przez nią nazywamy inteligentnymi kontraktami. +W praktyce uczestnicy nie piszą nowego kodu za każdym razem, gdy chcą zażądać obliczeń na EVM. Jest raczej tak, że programiści aplikacji przesyłają programy (fragmenty kodu wielokrotnego użytku) do stanu EVM, a użytkownicy wysyłają żądania wykonania tych fragmentów kodu z różnymi parametrami. Programy przesyłane do sieci i przez nią wykonywane nazywamy "inteligentnymi kontraktami". Na bardzo podstawowym poziomie można myśleć o inteligentnym kontrakcie jak o swego rodzaju automacie: skrypcie, który po wywołaniu z określonymi parametrami wykonuje pewne czynności lub obliczenia, jeśli spełnione są określone warunki. Na przykład, prosty inteligentny kontrakt sprzedawcy może utworzyć i przypisać własność cyfrowego zasobu, jeśli wywołujący wyśle ETH do określonego odbiorcy. @@ -60,11 +60,11 @@ Sekwencja wszystkich bloków, które zostały zatwierdzone w sieci Ethereum w hi ### ETH {#eth} -**Ether (ETH)** jest natywną kryptowalutą Ethereum. Użytkownicy płacą ETH innym użytkownikom, aby ich żądania wykonania kodu zostały spełnione. +**Ether (ETH)** to natywna kryptowaluta Ethereum. Użytkownicy płacą ETH innym użytkownikom, aby ich żądania wykonania kodu zostały spełnione. -[Więcej na temat ETH](/developers/docs/intro-to-ether/) +[Więcej o ETH](/developers/docs/intro-to-ether/) -### Maszyna Wirtualna Ethereum (EVM) {#evm} +### EVM {#evm} Maszyna wirtualna Ethereum to globalny komputer wirtualny, którego stan przechowuje i akceptuje każdy uczestnik sieci Ethereum. Każdy uczestnik może zażądać wykonania dowolnego kodu na EVM; wykonanie kodu zmienia stan EVM. @@ -100,17 +100,25 @@ Wolumen transakcji jest bardzo wysoki, więc transakcje są „zatwierdzane” w ### Inteligentne kontrakty {#smart-contracts} -Fragment kodu wielokrotnego użytku (program), który programista umieszcza w stanie EVM. Każdy może zażądać wykonania kodu inteligentnego kontraktu składając żądanie transakcji. Ponieważ programiści mogą pisać dowolne aplikacje wykonywalne w EVM (gry, rynki, instrumenty finansowe itp.) poprzez publikowanie inteligentnych kontraktów, są one często określane jako [dapps lub zdecentralizowane aplikacje](/developers/docs/dapps/). +Fragment kodu wielokrotnego użytku (program), który programista umieszcza w stanie EVM. Każdy może zażądać wykonania kodu inteligentnego kontraktu składając żądanie transakcji. Ponieważ programiści mogą pisać dowolne aplikacje wykonywalne w EVM (gry, rynki, instrumenty finansowe itp.) poprzez publikowanie inteligentnych kontraktów, są one często nazywane także [dapkami lub aplikacjami zdecentralizowanymi](/developers/docs/dapps/). -[Więcej na temat inteligentnych kontraktów](/developers/docs/smart-contracts/) +[Więcej o inteligentnych kontraktach](/developers/docs/smart-contracts/) ## Dalsza lektura {#further-reading} -- [Dokumentacja Ethereum](/whitepaper/) -- [Jak w ogóle działa Ethereum?](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) — _Preethi Kasireddy_ (**Chociaż** ten zasób jest nadal wartościowy, należy pamiętać, że pochodzi on sprzed czasu [Połączenia](/roadmap/merge) i dlatego nadal odnosi się do mechanizmu proof-of-work Ethereum — Ethereum jest obecnie zabezpieczone za pomocą [proof-of-stake](/developers/docs/consensus-mechanisms/pos)) +- [Biała księga Ethereum](/whitepaper/) +- [Jak w ogóle działa Ethereum?](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) – _Preethi Kasireddy_ (**UWAGA:** ten zasób jest wciąż wartościowy, ale należy pamiętać, że pochodzi on sprzed [Połączenia](/roadmap/merge) i w związku z tym nadal odnosi się do mechanizmu proof-of-work Ethereum – Ethereum jest obecnie zabezpieczone za pomocą [proof-of-stake](/developers/docs/consensus-mechanisms/pos)) -_Znasz jakieś zasoby społeczności, które Ci pomogły? Wyedytuj tę stronę i dodaj je!_ +### Jesteś raczej wzrokowcem? Dla wzrokowców {#visual-learner} + +Ta seria filmów oferuje dogłębne omówienie podstawowych zagadnień: + + + +[Playlista: podstawy Ethereum](https://youtube.com/playlist?list=PLqgutSGloqiJyyoL0zvLVFPS-GMD2wKa5&si=kZTf5I7PKGTXDsOZ) + +_Znasz jakieś zasoby społeczności, które Ci pomogły? Edytuj tę stronę i dodaj je!_ ## Powiązane samouczki {#related-tutorials} -- [Przewodnik programisty po Ethereum, część 1](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _ — bardzo przyjazne dla początkujących odkrywanie Ethereum przy użyciu Pythona i web3.py_ +- [Przewodnik programisty po Ethereum, część 1](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– Bardzo przyjazne dla początkujących odkrywanie Ethereum przy użyciu Pythona i web3.py_ diff --git a/public/content/translations/pl/developers/docs/mev/index.md b/public/content/translations/pl/developers/docs/mev/index.md new file mode 100644 index 00000000000..dfafaed41f2 --- /dev/null +++ b/public/content/translations/pl/developers/docs/mev/index.md @@ -0,0 +1,221 @@ +--- +title: "Maksymalna wartość ekstrahowalna (MEV)" +description: "Wprowadzenie do maksymalnej możliwej do wyodrębnienia wartości ( MEV)" +lang: pl +--- + +Maksymalna wartość ekstrakcji (MEV) odnosi się do maksymalnej wartości, którą można wydobyć z produkcji bloku ponad standardową nagrodę za blok i opłaty za gaz poprzez włączanie, wyłączanie i zmianę kolejności transakcji w bloku. + +## Maksymalna wartość ekstrakcji {#maximal-extractable-value} + +Maksymalna wartość ekstrakcji została po raz pierwszy zastosowana w kontekście [dowodu pracy](/developers/docs/consensus-mechanisms/pow/) i początkowo określano ją jako „wartość możliwa do wydobycia przez górnika”. Dzieje się tak, ponieważ w dowodzie pracy górnicy kontrolują włączanie, wyłączanie i porządkowanie transakcji. Jednak od czasu przejścia na dowód stawki poprzez [Połączenie](/roadmap/merge) za te role odpowiedzialni są walidatorzy, a wydobycie nie jest już częścią protokołu Ethereum. Metody ekstrakcji wartości nadal jednak istnieją, więc obecnie zamiast tego używa się terminu „maksymalna wartość ekstrakcji”. + +## Wymagania wstępne {#prerequisites} + +Upewnij się, że znasz [transakcje](/developers/docs/transactions/), [bloki](/developers/docs/blocks/), [dowód stawki](/developers/docs/consensus-mechanisms/pos) i [gaz](/developers/docs/gas/). Pomocna jest również znajomość [dapek](/apps/) i [DeFi](/defi/). + +## Ekstrakcja MEV {#mev-extraction} + +Teoretycznie MEV w całości przypada walidatorom, ponieważ są jedyną stroną, która może zagwarantować wykonanie dochodowej okazji MEV. W praktyce jednak duża część MEV jest wydobywana przez niezależnych uczestników sieci, zwanych „poszukiwaczami”. Poszukiwacze uruchamiają złożone algorytmy na danych blockchain w celu wykrycia dochodowych okazji MEV i posiadają boty do automatycznego przesyłania tych dochodowych transakcji do sieci. + +Walidatorzy i tak otrzymują część pełnej kwoty MEV, ponieważ poszukiwacze są gotowi płacić wysokie opłaty za gaz (które trafiają do walidatora) w zamian za większe prawdopodobieństwo włączenia ich dochodowych transakcji do bloku. Zakładając, że poszukiwacze są racjonalni ekonomicznie, opłata za gaz, którą poszukiwacz jest skłonny zapłacić, będzie kwotą do 100% MEV poszukiwacza (ponieważ gdyby opłata za gaz była wyższa, poszukiwacz straciłby pieniądze). + +W związku z tym, w przypadku niektórych wysoce konkurencyjnych okazji MEV, takich jak [arbitraż DEX](#mev-examples-dex-arbitrage), poszukiwacze mogą być zmuszeni do zapłacenia 90% lub nawet więcej swoich całkowitych przychodów z MEV w postaci opłat za gaz na rzecz walidatora, ponieważ tak wiele osób chce przeprowadzić tę samą dochodową transakcję arbitrażową. Dzieje się tak, ponieważ jedynym sposobem na zagwarantowanie, że ich transakcja arbitrażowa zostanie wykonana, jest przesłanie transakcji z najwyższą ceną gazu. + +### Gas golfing {#mev-extraction-gas-golfing} + +Ta dynamika sprawiła, że bycie dobrym w „gas golfing” – czyli programowaniu transakcji tak, aby zużywały jak najmniej gazu – stało się przewagą konkurencyjną, ponieważ pozwala poszukiwaczom ustawić wyższą cenę gazu przy jednoczesnym utrzymaniu stałych całkowitych opłat za gaz (ponieważ opłaty za gaz = cena gazu \* zużyty gaz). + +Kilka dobrze znanych technik „gas golfing” to: używanie adresów, które zaczynają się od długiego ciągu zer (np. [0x0000000000C521824EaFf97Eac7B73B084ef9306](https://eth.blockscout.com/address/0x0000000000C521824EaFf97Eac7B73B084ef9306)), ponieważ zajmują mniej miejsca (a więc i gazu) do przechowywania; oraz pozostawianie niewielkich sald tokenów [ERC-20](/developers/docs/standards/tokens/erc-20/) w kontraktach, ponieważ więcej gazu kosztuje zainicjowanie slotu pamięci (w przypadku gdy saldo wynosi 0) niż zaktualizowanie go. Znajdowanie kolejnych technik zmniejszania zużycia gazu jest aktywnym obszarem badań wśród poszukiwaczy. + +### Uogólnieni frontrunnerzy {#mev-extraction-generalized-frontrunners} + +Zamiast programować złożone algorytmy do wykrywania dochodowych okazji MEV, niektórzy poszukiwacze uruchamiają uogólnionych frontrunnerów. Uogólnieni frontrunnerzy to boty, które obserwują mempool w celu wykrywania dochodowych transakcji. Frontrunner skopiuje kod potencjalnie dochodowej transakcji, zastąpi adresy adresem frontrunnera i uruchomi transakcję lokalnie, aby sprawdzić, czy zmodyfikowana transakcja przyniesie zysk na adres frontrunnera. Jeśli transakcja jest rzeczywiście dochodowa, frontrunner prześle zmodyfikowaną transakcję z zastąpionym adresem i wyższą ceną gazu, „wyprzedzając” pierwotną transakcję i uzyskując MEV pierwotnego poszukiwacza. + +### Flashbots {#mev-extraction-flashbots} + +Flashbots to niezależny projekt, który rozszerza klientów wykonawczych o usługę pozwalającą poszukiwaczom na przesyłanie transakcji MEV do walidatorów bez ujawniania ich w publicznym mempool. Zapobiega to wyprzedzaniu transakcji przez uogólnionych frontrunnerów. + +## Przykłady MEV {#mev-examples} + +MEV pojawia się w blockchain na kilka sposobów. + +### Arbitraż na giełdach DEX {#mev-examples-dex-arbitrage} + +Arbitraż na [zdecentralizowanych giełdach](/glossary/#dex) (DEX) jest najprostszą i najbardziej znaną okazją do uzyskania MEV. W rezultacie jest to również najbardziej konkurencyjna metoda. + +Działa to w następujący sposób: jeśli dwie giełdy DEX oferują token po dwóch różnych cenach, ktoś może kupić token na giełdzie DEX o niższej cenie i sprzedać go na giełdzie DEX o wyższej cenie w ramach jednej, atomowej transakcji. Dzięki mechanice blockchaina jest to prawdziwy, pozbawiony ryzyka arbitraż. + +[Oto przykład](https://eth.blockscout.com/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4) dochodowej transakcji arbitrażowej, w której poszukiwacz zamienił 1000 ETH na 1045 ETH, wykorzystując różne ceny pary ETH/DAI na Uniswap i Sushiswap. + +### Likwidacje {#mev-examples-liquidations} + +Likwidacje w protokołach pożyczkowych stanowią kolejną dobrze znaną okazję do uzyskania MEV. + +Protokoły pożyczkowe, takie jak Maker i Aave, wymagają od użytkowników zdeponowania pewnego zabezpieczenia (np. ETH). To zdeponowane zabezpieczenie jest następnie wykorzystywane do udzielania pożyczek innym użytkownikom. + +Użytkownicy mogą następnie pożyczać aktywa i tokeny od innych w zależności od tego, czego potrzebują (np. możesz pożyczyć MKR, jeśli chcesz głosować w propozycji zarządzania MakerDAO) do określonego procentu zdeponowanego zabezpieczenia. Na przykład, jeśli kwota pożyczki wynosi maksymalnie 30%, użytkownik, który wpłaci do protokołu 100 DAI, może pożyczyć do 30 DAI w innym aktywie. Protokół określa dokładny procent zdolności pożyczkowej. + +Wraz ze zmianą wartości zabezpieczenia pożyczkobiorcy, zmienia się również jego zdolność pożyczkowa. Jeśli z powodu wahań rynkowych wartość pożyczonych aktywów przekroczy, powiedzmy, 30% wartości ich zabezpieczenia (ponownie, dokładny procent jest określony przez protokół), protokół zazwyczaj pozwala każdemu na zlikwidowanie zabezpieczenia, natychmiast spłacając pożyczkodawców (jest to podobne do tego, jak działają [wezwania do uzupełnienia depozytu](https://www.investopedia.com/terms/m/margincall.asp) w tradycyjnych finansach). W przypadku likwidacji pożyczkobiorca musi zazwyczaj zapłacić wysoką opłatę likwidacyjną, której część trafia do likwidatora – i tu właśnie pojawia się okazja MEV. + +Poszukiwacze konkurują w jak najszybszym parsowaniu danych blockchain, aby ustalić, którzy pożyczkobiorcy mogą zostać zlikwidowani, i jako pierwsi przesłać transakcję likwidacyjną i pobrać opłatę likwidacyjną dla siebie. + +### Handel kanapkowy {#mev-examples-sandwich-trading} + +Handel kanapkowy to kolejna popularna metoda ekstrakcji MEV. + +Aby przeprowadzić atak kanapkowy, poszukiwacz obserwuje mempool w poszukiwaniu dużych transakcji na giełdach DEX. Załóżmy na przykład, że ktoś chce kupić 10 000 UNI za DAI na Uniswap. Transakcja tej wielkości będzie miała znaczący wpływ na parę UNI/DAI, potencjalnie znacznie podnosząc cenę UNI w stosunku do DAI. + +Poszukiwacz może obliczyć przybliżony wpływ cenowy tej dużej transakcji na parę UNI/DAI i wykonać optymalne zlecenie kupna natychmiast _przed_ dużą transakcją, kupując UNI tanio, a następnie wykonać zlecenie sprzedaży natychmiast _po_ dużej transakcji, sprzedając je po wyższej cenie spowodowanej dużym zleceniem. + +Atak kanapkowy jest jednak bardziej ryzykowny, ponieważ nie jest atomowy (w przeciwieństwie do arbitrażu DEX, jak opisano powyżej) i jest podatny na [atak salmonella](https://github.com/Defi-Cartel/salmonella). + +### MEV w NFT {#mev-examples-nfts} + +MEV w przestrzeni NFT jest zjawiskiem nowym i niekoniecznie dochodowym. + +Ponieważ jednak transakcje NFT odbywają się na tym samym blockchainie, który jest współdzielony przez wszystkie inne transakcje Ethereum, poszukiwacze mogą również stosować podobne techniki do tych używanych w tradycyjnych okazjach MEV na rynku NFT. + +Na przykład, jeśli odbywa się popularny drop NFT, a poszukiwacz chce zdobyć określony NFT lub zestaw NFT, może zaprogramować transakcję tak, aby być pierwszym w kolejce do zakupu NFT, lub może kupić cały zestaw NFT w jednej transakcji. Lub jeśli NFT zostanie [omyłkowo wystawiony po niskiej cenie](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent), poszukiwacz może wyprzedzić innych nabywców i zgarnąć go tanio. + +Jeden z głośnych przykładów MEV w NFT miał miejsce, gdy poszukiwacz wydał 7 milionów dolarów, aby [kupić](https://eth.blockscout.com/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5?tab=txs) każdego Cryptopunka po cenie minimalnej. Badacz blockchain [wyjaśnił na Twitterze](https://twitter.com/IvanBogatyy/status/1422232184493121538), w jaki sposób nabywca współpracował z dostawcą MEV, aby utrzymać swój zakup w tajemnicy. + +### Długi ogon {#mev-examples-long-tail} + +Arbitraż na giełdach DEX, likwidacje i handel kanapkowy to bardzo dobrze znane okazje MEV, które prawdopodobnie nie będą dochodowe dla nowych poszukiwaczy. Istnieje jednak długi ogon mniej znanych okazji MEV (MEV w NFT jest prawdopodobnie jedną z takich okazji). + +Poszukiwacze, którzy dopiero zaczynają, mogą odnieść większy sukces, szukając MEV w tym dłuższym ogonie. [Tablica ofert pracy MEV](https://github.com/flashbots/mev-job-board) od Flashbots wymienia niektóre z pojawiających się możliwości. + +## Skutki MEV {#effects-of-mev} + +MEV nie jest do końca złe — istnieją zarówno pozytywne, jak i negatywne konsekwencje MEV w Ethereum. + +### Zalety {#effects-of-mev-the-good} + +Wiele projektów DeFi opiera się na racjonalnych ekonomicznie podmiotach w celu zapewnienia użyteczności i stabilności swoich protokołów. Na przykład arbitraż na giełdach DEX zapewnia użytkownikom najlepsze, najbardziej prawidłowe ceny ich tokenów, a protokoły pożyczkowe polegają na szybkich likwidacjach, gdy pożyczkobiorcy spadają poniżej wskaźników zabezpieczenia, aby zapewnić spłatę pożyczkodawców. + +Bez racjonalnych poszukiwaczy, którzy wyszukują i naprawiają nieefektywności ekonomiczne oraz wykorzystują bodźce ekonomiczne protokołów, protokoły DeFi i ogólnie dapki mogłyby nie być tak solidne, jak są dzisiaj. + +### Wady {#effects-of-mev-the-bad} + +Na warstwie aplikacji niektóre formy MEV, takie jak handel kanapkowy, skutkują jednoznacznie gorszym doświadczeniem dla użytkowników. Użytkownicy, którzy padli ofiarą ataku kanapkowego, doświadczają zwiększonego poślizgu i gorszej realizacji swoich transakcji. + +Na warstwie sieciowej uogólnieni frontrunnerzy i aukcje cen gazu, w których często uczestniczą (gdy dwóch lub więcej frontrunnerów konkuruje o włączenie ich transakcji do następnego bloku, stopniowo podnosząc cenę gazu dla własnych transakcji), powodują przeciążenie sieci i wysokie ceny gazu dla wszystkich innych próbujących przeprowadzić zwykłe transakcje. + +Oprócz tego, co dzieje się _wewnątrz_ bloków, MEV może mieć szkodliwe skutki _pomiędzy_ blokami. Jeśli MEV dostępna w bloku znacznie przekracza standardową nagrodę za blok, walidatorzy mogą być zachęcani do reorganizacji bloków i przejęcia MEV dla siebie, powodując reorganizację blockchaina i niestabilność konsensusu. + +Ta możliwość reorganizacji blockchaina została [wcześniej zbadana na blockchainie Bitcoin](https://dl.acm.org/doi/10.1145/2976749.2978408). W miarę jak nagroda za blok Bitcoina zmniejsza się o połowę, a opłaty transakcyjne stanowią coraz większą część nagrody za blok, pojawiają się sytuacje, w których dla górników staje się racjonalne ekonomicznie zrezygnowanie z nagrody za następny blok i ponowne wydobycie poprzednich bloków z wyższymi opłatami. Wraz z rozwojem MEV podobna sytuacja może wystąpić w Ethereum, zagrażając integralności blockchaina. + +## Stan MEV {#state-of-mev} + +Ekstrakcja MEV gwałtownie wzrosła na początku 2021 roku, co spowodowało niezwykle wysokie ceny gazu w pierwszych miesiącach roku. Pojawienie się przekaźnika MEV Flashbots zmniejszyło skuteczność uogólnionych frontrunnerów i przeniosło aukcje cen gazu poza łańcuch, obniżając ceny gazu dla zwykłych użytkowników. + +Chociaż wielu poszukiwaczy wciąż zarabia dobre pieniądze na MEV, w miarę jak możliwości stają się coraz bardziej znane i coraz więcej poszukiwaczy konkuruje o te same okazje, walidatorzy będą przejmować coraz większą część całkowitych przychodów z MEV (ponieważ tego samego rodzaju aukcje gazowe, co pierwotnie opisano powyżej, również występują w Flashbots, aczkolwiek prywatnie, a walidatorzy przejmą wynikające z nich przychody z gazu). MEV nie jest również unikalne dla Ethereum, a w miarę jak możliwości stają się bardziej konkurencyjne w Ethereum, poszukiwacze przenoszą się na alternatywne blockchainy, takie jak Binance Smart Chain, gdzie istnieją podobne możliwości MEV jak w Ethereum, ale z mniejszą konkurencją. + +Z drugiej strony, przejście z dowodu pracy na dowód stawki i trwające wysiłki w celu skalowania Ethereum za pomocą rollupów zmieniają krajobraz MEV w sposób, który wciąż jest nieco niejasny. Nie jest jeszcze dobrze wiadomo, jak posiadanie gwarantowanych proposerów bloków, znanych z niewielkim wyprzedzeniem, zmienia dynamikę ekstrakcji MEV w porównaniu z probabilistycznym modelem w dowodzie pracy, ani jak zostanie to zakłócone, gdy wdrożone zostaną [wybory jednego tajnego lidera](https://ethresear.ch/t/secret-non-single-leader-election/11789) i [technologia rozproszonych walidatorów](/staking/dvt/). Podobnie, dopiero okaże się, jakie możliwości MEV istnieją, gdy większość aktywności użytkowników zostanie przeniesiona z Ethereum na jego rollupy warstwy 2 i shardy. + +## MEV w Ethereum z dowodem stawki (PoS) {#mev-in-ethereum-proof-of-stake} + +Jak wyjaśniono, MEV ma negatywne konsekwencje dla ogólnego doświadczenia użytkownika i bezpieczeństwa warstwy konsensusu. Ale przejście Ethereum na konsensus dowodu stawki (nazwane „Połączenie”) potencjalnie wprowadza nowe ryzyka związane z MEV: + +### Centralizacja walidatorów {#validator-centralization} + +W Ethereum po Połączeniu walidatorzy (którzy wnieśli depozyty zabezpieczające w wysokości 32 ETH) osiągają konsensus co do ważności bloków dodawanych do Beacon Chain. Ponieważ 32 ETH mogą być poza zasięgiem wielu, [dołączenie do puli stakingu](/staking/pools/) może być bardziej wykonalną opcją. Niemniej jednak, zdrowy rozkład [stakerów indywidualnych](/staking/solo/) jest idealny, ponieważ łagodzi centralizację walidatorów i poprawia bezpieczeństwo Ethereum. + +Uważa się jednak, że ekstrakcja MEV jest w stanie przyspieszyć centralizację walidatorów. Jest to częściowo spowodowane tym, że ponieważ walidatorzy [zarabiają mniej za proponowanie bloków](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply) niż wcześniej górnicy, ekstrakcja MEV znacznie [wpłynęła na zarobki walidatorów](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb) od czasu [Połączenia](/roadmap/merge/). + +Większe pule stakingu prawdopodobnie będą miały więcej zasobów do inwestowania w niezbędne optymalizacje w celu przechwytywania możliwości MEV. Im więcej MEV te pule wydobędą, tym więcej zasobów będą miały na ulepszenie swoich możliwości ekstrakcji MEV (i zwiększenie ogólnych przychodów), zasadniczo tworząc [korzyści skali](https://www.investopedia.com/terms/e/economiesofscale.asp#). + +Z mniejszymi zasobami do dyspozycji, stakerzy indywidualni mogą nie być w stanie czerpać zysków z możliwości MEV. Może to zwiększyć presję na niezależnych walidatorów, aby dołączali do potężnych pul stakingu w celu zwiększenia swoich zarobków, zmniejszając decentralizację w Ethereum. + +### Mempool z uprawnieniami {#permissioned-mempools} + +W odpowiedzi na ataki kanapkowe i frontrunning, handlowcy mogą zacząć zawierać umowy pozałańcuchowe z walidatorami w celu zapewnienia prywatności transakcji. Zamiast wysyłać potencjalną transakcję MEV do publicznego mempool, handlowiec wysyła ją bezpośrednio do walidatora, który włącza ją do bloku i dzieli się zyskiem z handlowcem. + +„Ciemne pule” są większą wersją tego układu i funkcjonują jako mempoole z uprawnieniami, dostępne tylko dla użytkowników gotowych zapłacić określone opłaty. Ten trend zmniejszyłby brak konieczności posiadania uprawnień i zaufania w Ethereum i potencjalnie przekształciłby blockchain w mechanizm „pay-to-play”, który faworyzuje najwyższego licytanta. + +Mempool z uprawnieniami przyspieszyłby również ryzyko centralizacji opisane w poprzedniej sekcji. Duże pule obsługujące wielu walidatorów prawdopodobnie skorzystają na oferowaniu prywatności transakcji handlowcom i użytkownikom, zwiększając swoje przychody z MEV. + +Zwalczanie tych problemów związanych z MEV w Ethereum po Połączeniu jest kluczowym obszarem badań. Do tej pory dwoma rozwiązaniami zaproponowanymi w celu zmniejszenia negatywnego wpływu MEV na decentralizację i bezpieczeństwo Ethereum po Połączeniu są [**Separacja Proposera-Buildera (PBS)**](/roadmap/pbs/) i [**Builder API**](https://github.com/ethereum/builder-specs). + +### Separacja Proposera-Buildera {#proposer-builder-separation} + +Zarówno w dowodzie pracy, jak i w dowodzie stawki, węzeł, który buduje blok, proponuje go do dodania do łańcucha innym węzłom uczestniczącym w konsensusie. Nowy blok staje się częścią kanonicznego łańcucha, gdy inny górnik zbuduje na nim kolejny blok (w PoW) lub otrzyma poświadczenia od większości walidatorów (w PoS). + +Połączenie ról producenta bloków i proposera bloków jest tym, co wprowadza większość problemów związanych z MEV, które zostały opisane wcześniej. Na przykład węzły konsensusu są zachęcane do wywoływania reorganizacji łańcucha w [atakach typu time-bandit](https://www.mev.wiki/attack-examples/time-bandit-attack), aby zmaksymalizować zyski z MEV. + +[Separacja proposera-buildera](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) (PBS) ma na celu złagodzenie wpływu MEV, zwłaszcza na warstwie konsensusu. Główną cechą PBS jest rozdzielenie zasad producenta bloków i proposera bloków. Walidatorzy nadal są odpowiedzialni za proponowanie i głosowanie nad blokami, ale nowa klasa wyspecjalizowanych podmiotów, zwanych **builderami bloków**, ma za zadanie porządkowanie transakcji i budowanie bloków. + +W ramach PBS builder bloków tworzy pakiet transakcji i składa ofertę na jego włączenie do bloku Beacon Chain (jako „ładunek wykonawczy”). Walidator wybrany do zaproponowania następnego bloku następnie sprawdza różne oferty i wybiera pakiet z najwyższą opłatą. PBS zasadniczo tworzy rynek aukcyjny, na którym builderzy negocjują z walidatorami sprzedającymi przestrzeń w bloku. + +Obecne projekty PBS wykorzystują [schemat commit-reveal](https://gitcoin.co/blog/commit-reveal-scheme-on-ethereum/), w którym builderzy publikują jedynie kryptograficzne zobowiązanie do zawartości bloku (nagłówek bloku) wraz ze swoimi ofertami. Po zaakceptowaniu zwycięskiej oferty, proposer tworzy podpisaną propozycję bloku, która zawiera nagłówek bloku. Oczekuje się, że builder bloków opublikuje pełną treść bloku po zobaczeniu podpisanej propozycji bloku, a także musi otrzymać wystarczającą liczbę [poświadczeń](/glossary/#attestation) od walidatorów, zanim zostanie sfinalizowany. + +#### Jak separacja proposera-buildera łagodzi wpływ MEV? {#how-does-pbs-curb-mev-impact} + +Separacja proposera-buildera w protokole zmniejsza wpływ MEV na konsensus poprzez usunięcie ekstrakcji MEV z zakresu obowiązków walidatorów. Zamiast tego, builderzy bloków, którzy uruchamiają wyspecjalizowany sprzęt, będą odtąd wykorzystywać możliwości MEV. + +Nie wyklucza to jednak całkowicie walidatorów z dochodów związanych z MEV, ponieważ builderzy muszą licytować wysoko, aby ich bloki zostały zaakceptowane przez walidatorów. Niemniej jednak, gdy walidatorzy nie są już bezpośrednio skoncentrowani na optymalizacji dochodów z MEV, zagrożenie atakami typu time-bandit maleje. + +Separacja proposera-buildera zmniejsza również ryzyko centralizacji MEV. Na przykład, użycie schematu commit-reveal usuwa potrzebę, aby builderzy ufali walidatorom, że nie ukradną możliwości MEV ani nie ujawnią jej innym builderom. Obniża to barierę dla indywidualnych stakerów, aby mogli czerpać korzyści z MEV, w przeciwnym razie builderzy skłanialiby się ku faworyzowaniu dużych pul z reputacją poza łańcuchem i zawieraniu z nimi umów poza łańcuchem. + +Podobnie walidatorzy nie muszą ufać builderom, że nie wstrzymają treści bloków ani nie opublikują nieprawidłowych bloków, ponieważ płatność jest bezwarunkowa. Opłata walidatora jest nadal przetwarzana, nawet jeśli proponowany blok jest niedostępny lub uznany za nieważny przez innych walidatorów. W tym drugim przypadku blok jest po prostu odrzucany, co zmusza buildera bloków do utraty wszystkich opłat transakcyjnych i przychodów z MEV. + +### Builder API {#builder-api} + +Chociaż separacja proposera-buildera obiecuje zmniejszyć skutki ekstrakcji MEV, jej wdrożenie wymaga zmian w protokole konsensusu. W szczególności reguła [wyboru forka](/developers/docs/consensus-mechanisms/pos/#fork-choice) na Beacon Chain musiałaby zostać zaktualizowana. [Builder API](https://github.com/ethereum/builder-specs) jest tymczasowym rozwiązaniem mającym na celu zapewnienie działającej implementacji separacji proposera-buildera, aczkolwiek z większymi założeniami dotyczącymi zaufania. + +Builder API jest zmodyfikowaną wersją [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) używaną przez klientów warstwy konsensusu do żądania ładunków wykonawczych od klientów warstwy wykonawczej. Jak określono w [specyfikacji uczciwego walidatora](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/validator.md), walidatorzy wybrani do obowiązków proponowania bloków żądają pakietu transakcji od podłączonego klienta wykonawczego, który włączają do proponowanego bloku Beacon Chain. + +Builder API działa również jako oprogramowanie pośredniczące między walidatorami a klientami warstwy wykonawczej; ale jest inne, ponieważ pozwala walidatorom na Beacon Chain pozyskiwać bloki od zewnętrznych podmiotów (zamiast budować blok lokalnie za pomocą klienta wykonawczego). + +Poniżej znajduje się przegląd działania Builder API: + +1. Builder API łączy walidatora z siecią builderów bloków, którzy uruchamiają klientów warstwy wykonawczej. Podobnie jak w PBS, builderzy są wyspecjalizowanymi stronami, które inwestują w zasobochłonne budowanie bloków i stosują różne strategie w celu maksymalizacji dochodów z MEV i napiwków priorytetowych. + +2. Walidator (uruchamiający klienta warstwy konsensusu) żąda ładunków wykonawczych wraz z ofertami od sieci builderów. Oferty od builderów będą zawierać nagłówek ładunku wykonawczego — kryptograficzne zobowiązanie do zawartości ładunku — oraz opłatę do zapłacenia walidatorowi. + +3. Walidator przegląda przychodzące oferty i wybiera ładunek wykonawczy z najwyższą opłatą. Korzystając z Builder API, walidator tworzy „zaślepioną” propozycję bloku Beacon, która zawiera tylko jego podpis i nagłówek ładunku wykonawczego, i wysyła ją do buildera. + +4. Oczekuje się, że builder uruchamiający Builder API odpowie pełnym ładunkiem wykonawczym po zobaczeniu zaślepionej propozycji bloku. Pozwala to walidatorowi na stworzenie „podpisanego” bloku Beacon, który propaguje w całej sieci. + +5. Oczekuje się, że walidator korzystający z Builder API nadal będzie budował blok lokalnie w przypadku, gdy builder bloków nie odpowie w odpowiednim czasie, aby nie przegapić nagród za propozycję bloku. Jednak walidator nie może stworzyć kolejnego bloku, używając ani teraz ujawnionych transakcji, ani innego zestawu, ponieważ byłoby to równoznaczne z _dwuznacznością_ (podpisaniem dwóch bloków w tym samym slocie), co jest wykroczeniem podlegającym slashingowi. + +Przykładem implementacji Builder API jest [MEV Boost](https://github.com/flashbots/mev-boost), ulepszenie [mechanizmu aukcji Flashbots](https://docs.flashbots.net/Flashbots-auction/overview) zaprojektowane w celu ograniczenia negatywnych efektów zewnętrznych MEV w Ethereum. Aukcja Flashbots pozwala walidatorom w systemie dowodu stawki zlecać pracę budowania dochodowych bloków wyspecjalizowanym stronom zwanym **poszukiwaczami**. +![Diagram szczegółowo pokazujący przepływ MEV](./mev.png) + +Poszukiwacze szukają lukratywnych okazji MEV i wysyłają pakiety transakcji do proposerów bloków wraz z [ofertą w zamkniętej kopercie](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction) w celu włączenia do bloku. Walidator uruchamiający mev-geth, sforkowaną wersję klienta go-ethereum (Geth), musi tylko wybrać pakiet z największym zyskiem i włączyć go jako część nowego bloku. Aby chronić proposerów bloków (walidatorów) przed spamem i nieprawidłowymi transakcjami, pakiety transakcji przechodzą przez **przekaźniki** w celu walidacji, zanim dotrą do proposera. + +MEV Boost zachowuje te same zasady działania co oryginalna aukcja Flashbots, aczkolwiek z nowymi funkcjami zaprojektowanymi na potrzeby przejścia Ethereum na dowód stawki. Poszukiwacze wciąż znajdują dochodowe transakcje MEV do włączenia do bloków, ale nowa klasa wyspecjalizowanych stron, zwanych **builderami**, jest odpowiedzialna za agregowanie transakcji i pakietów w bloki. Builder akceptuje oferty w zamkniętych kopertach od poszukiwaczy i przeprowadza optymalizacje, aby znaleźć najbardziej dochodową kolejność. + +Przekaźnik jest nadal odpowiedzialny za walidację pakietów transakcji przed przekazaniem ich do proposera. Jednak MEV Boost wprowadza **depozyty** odpowiedzialne za zapewnienie [dostępności danych](/developers/docs/data-availability/) poprzez przechowywanie treści bloków wysyłanych przez builderów i nagłówków bloków wysyłanych przez walidatorów. Tutaj walidator podłączony do przekaźnika prosi o dostępne ładunki wykonawcze i używa algorytmu porządkowania MEV Boost, aby wybrać nagłówek ładunku z najwyższą ofertą i napiwkami MEV. + +#### Jak Builder API łagodzi wpływ MEV? {#how-does-builder-api-curb-mev-impact} + +Podstawową zaletą Builder API jest jego potencjał do demokratyzacji dostępu do możliwości MEV. Używanie schematów commit-reveal eliminuje założenia dotyczące zaufania i zmniejsza bariery wejścia dla walidatorów pragnących czerpać korzyści z MEV. Powinno to zmniejszyć presję na indywidualnych stakerów, aby integrowali się z dużymi pulami stakingu w celu zwiększenia zysków z MEV. + +Szerokie wdrożenie Builder API zachęci do większej konkurencji wśród builderów bloków, co zwiększa odporność na cenzurę. Ponieważ walidatorzy przeglądają oferty od wielu builderów, builder zamierzający cenzurować jedną lub więcej transakcji użytkownika musi przebić wszystkich innych niecenzurujących builderów, aby odnieść sukces. To znacznie zwiększa koszt cenzurowania użytkowników i zniechęca do tej praktyki. + +Niektóre projekty, takie jak MEV Boost, używają Builder API jako części ogólnej struktury zaprojektowanej w celu zapewnienia prywatności transakcji niektórym stronom, takim jak handlowcy próbujący uniknąć ataków typu frontrunning/sandwiching. Osiąga się to poprzez zapewnienie prywatnego kanału komunikacji między użytkownikami a builderami bloków. W przeciwieństwie do opisanych wcześniej mempooli z uprawnieniami, to podejście jest korzystne z następujących powodów: + +1. Istnienie wielu builderów na rynku sprawia, że cenzurowanie jest niepraktyczne, co przynosi korzyści użytkownikom. W przeciwieństwie do tego, istnienie scentralizowanych i opartych na zaufaniu ciemnych pul skoncentrowałoby władzę w rękach kilku builderów bloków i zwiększyło możliwość cenzury. + +2. Oprogramowanie Builder API jest oprogramowaniem open-source, co pozwala każdemu oferować usługi budowania bloków. Oznacza to, że użytkownicy nie są zmuszeni do korzystania z żadnego konkretnego buildera bloków i poprawia neutralność i brak konieczności posiadania uprawnień w Ethereum. Co więcej, handlowcy szukający MEV nie będą nieumyślnie przyczyniać się do centralizacji, korzystając z prywatnych kanałów transakcyjnych. + +## Powiązane zasoby {#related-resources} + +- [Dokumentacja Flashbots](https://docs.flashbots.net/) +- [Flashbots na GitHub](https://github.com/flashbots/pm) +- [mevboost.org](https://www.mevboost.org/) – _Tracker ze statystykami w czasie rzeczywistym dla przekaźników MEV-Boost i builderów bloków_ + +## Dalsza lektura {#further-reading} + +- [Czym jest wartość możliwa do wydobycia przez górnika (MEV)?](https://blog.chain.link/what-is-miner-extractable-value-mev/) +- [MEV i ja](https://www.paradigm.xyz/2021/02/mev-and-me) +- [Ethereum to mroczny las](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/) +- [Ucieczka z mrocznego lasu](https://samczsun.com/escaping-the-dark-forest/) +- [Flashbots: Wyprzedzanie kryzysu MEV](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752) +- [Wątki MEV @bertcmiller](https://twitter.com/bertcmiller/status/1402665992422047747) +- [MEV-Boost: Architektura Flashbots gotowa na Połączenie](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177) +- [Czym jest MEV Boost](https://www.alchemy.com/overviews/mev-boost) +- [Dlaczego warto uruchomić mev-boost?](https://writings.flashbots.net/writings/why-run-mevboost/) +- [Autostopem przez Ethereum](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) diff --git a/public/content/translations/pl/developers/docs/networking-layer/index.md b/public/content/translations/pl/developers/docs/networking-layer/index.md new file mode 100644 index 00000000000..28489c36e9a --- /dev/null +++ b/public/content/translations/pl/developers/docs/networking-layer/index.md @@ -0,0 +1,163 @@ +--- +title: Warstwa sieciowa +description: Wprowadzenie do warstwy sieciowej Ethereum. +lang: pl +sidebarDepth: 2 +--- + +Ethereum to sieć peer-to-peer z tysiącami węzłów, które muszą być w stanie komunikować się ze sobą przy użyciu ustandaryzowanych protokołów. „Warstwa sieciowa” jest stosem protokołów, które umożliwiają tym węzłom znajdować się i wymieniać informacje. Obejmuje to „plotkowanie” informacji (komunikacja jeden do wielu) w sieci, jak również wymienianie żądań oraz odpowiedzi pomiędzy określonymi węzłami (komunikacja jeden do jednego). Każdy węzeł musi przestrzegać określonych zasad sieciowych, aby zapewnić wysyłanie i odbieranie prawidłowych informacji. + +Istnieją dwie części oprogramowania klienta (klienty wykonawcze i klienty konsensusu), oba ze swoim własnym stosem sieciowym. Oprócz komunikacji z innymi węzłami Ethereum, klienty wykonawcze i konsensusu muszą się również komunikować ze sobą. Ta strona zawiera wstępne wyjaśnienie protokołów, które umożliwiają tę komunikację. + +Klienty wykonawcze plotkują transakcje po sieci peer-to-peer warstwy wykonawczej. Wymaga to szyfrowanej komunikacji między uwierzytelnionymi rówieśnikami. Kiedy walidator zostanie wybrany do proponowania bloku, transakcje z lokalnej puli transakcji węzła zostaną przesłane do klienta konsensusu za pomocą lokalnego połączenia RPC, które zostaną spakowane w bloki śledzące. Klienty konsensusu następnie rozplotkują bloki śledzące w swojej sieci P2P. To wymaga dwóch osobnych sieci P2P: jednej łączącej klienty wykonawcze do plotkowania transakcji i jednej łączącej klienty konsensusu do plotkowania bloku. + +## Wymagania wstępne {#prerequisites} + +Pewna wiedza na temat [węzłów i klientów](/developers/docs/nodes-and-clients/) Ethereum będzie pomocna w zrozumieniu tej strony. + +## Warstwa wykonawcza {#execution-layer} + +Protokoły sieciowe warstwy wykonawczej są podzielone na dwa stosy: + +- stos odkrywania: zbudowany na bazie UDP, umożliwia nowemu węzłowi znalezienie rówieśników, z którymi może się połączyć + +- stos DevP2P: oparty na TCP, umożliwia węzłom wymianę informacji + +Oba stosy działają równoległe. Stos odkrywania wprowadza nowych uczestników sieci do sieci, a stos DevP2P umożliwia ich interakcje. + +### Odkrywanie {#discovery} + +Odkrywanie to proces znajdowania innych węzłów w sieci. Jest to inicjowane za pomocą małego zestawu bootnode'ów (węzłów, których adresy są [zakodowane na stałe](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) w kliencie, aby można je było natychmiast znaleźć i połączyć klienta z peerami). Te węzły rozruchowe istnieją tylko po to, aby wprowadzić nowy węzeł do zbioru rówieśników — jest to ich jedyny cel, nie uczestniczą w normalnych zadaniach klienta takich jak synchronizacja z łańcuchem, oraz są używane tylko przy pierwszym uruchomieniu klienta. + +Protokół używany do interakcji między węzłami a bootnode'ami to zmodyfikowana forma protokołu [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f), która wykorzystuje [rozproszoną tablicę haszującą](https://en.wikipedia.org/wiki/Distributed_hash_table) do udostępniania list węzłów. Każdy węzeł ma własną wersję tej tablicy zwierającą informacje wymagane do połączenia się z jego najbliższym rówieśnikiem. Ta „bliskość” nie jest geograficzna — odległość określana jest poprzez podobieństwo identyfikatora węzła. Tablica każdego węzła jest regularnie odświeżana, jako funkcja bezpieczeństwa. Na przykład w protokole odkrywania [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5), węzły mogą również wysyłać „ogłoszenia”, które wyświetlają podprotokoły obsługiwane przez klienta, pozwalając peerom negocjować protokoły, których obie strony mogą używać do komunikacji. + +Odkrywanie zaczyna się grą w PING-PONG. Pomyślny PING-PONG „wiąże” nowy węzeł z węzłem rozruchowym. Początkowym komunikatem, który informuje bootnode'a o istnieniu nowego węzła wchodzącego do sieci, jest `PING`. Ten `PING` zawiera zhaszowane informacje o nowym węźle, bootnodzie i znacznik czasu wygaśnięcia. Bootnode odbiera `PING` i zwraca `PONG` zawierający hasz `PING`. Jeśli hasze `PING` i `PONG` są zgodne, połączenie między nowym węzłem a bootnode'em jest weryfikowane i mówi się, że zostały "powiązane". + +Po powiązaniu nowy węzeł może wysłać żądanie `FIND-NEIGHBOURS` do bootnode'a. Dane zwracane przez węzeł rozruchowy zawierają listę rówieśników, do których może się połączyć nowy węzeł. Jeśli węzły nie są powiązane, żądanie `FIND-NEIGHBOURS` zakończy się niepowodzeniem, więc nowy węzeł nie będzie mógł dołączyć do sieci. + +Po otrzymaniu przez nowy węzeł listy sąsiadów od węzła rozruchowego rozpoczyna on z każdym z nich wymianę PING-PONG. Pomyślne PING-PONGi wiążą nowy węzeł z jego sąsiadami, umożliwiając wymianę wiadomości. + +``` +uruchom klienta --> połącz z bootnode'em --> powiąż z bootnode'em --> znajdź sąsiadów --> powiąż z sąsiadami +``` + +Klienci wykonawczy obecnie używają protokołu odkrywania [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) i trwają aktywne prace nad migracją do protokołu [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5). + +#### ENR: Rekordy węzłów Ethereum {#enr} + +[Rekord węzła Ethereum (ENR)](/developers/docs/networking-layer/network-addresses/) to obiekt, który zawiera trzy podstawowe elementy: podpis (hasz zawartości rekordu utworzony zgodnie z ustalonym schematem tożsamości), numer sekwencyjny śledzący zmiany w rekordzie oraz dowolną listę par klucz:wartość. Jest to format odporny na zmiany w przyszłości, który umożliwia łatwiejszą wymianę informacji identyfikacyjnych między nowymi peerami i jest preferowanym formatem [adresu sieciowego](/developers/docs/networking-layer/network-addresses) dla węzłów Ethereum. + +#### Dlaczego odkrywanie opiera się na UDP? {#why-udp} + +UDP nie umożliwia żadnego sprawdzania błędów, ponownego przesyłania błędnych pakietów ani dynamicznego otwierania i zamykania połączeń — zamiast tego wysyła po prostu ciągły strumień informacji do celu, bez względu na to, czy zostaną one poprawnie odebrane. Ta minimalna funkcjonalność oznacza również minimalne obciążenie, co sprawia, że połączenie to jest bardzo szybkie. Do odkrywania, gdzie węzeł po prostu chce powiadomić o swoim istnieniu, aby następnie nawiązać formalne połączenie z rówieśnikiem, UDP jest wystarczające. Jednak dla reszty stosu sieciowego, UDP nie nadaje się tego celu. Wymiana informacji pomiędzy węzłami jest dość złożona, a więc wymaga bardziej funkcjonalnego protokołu, który umożliwia ponowne wysyłanie, sprawdzanie błędów itp. Dodatkowe obciążenia związane z TCP warte są dodatkowych funkcji. Dlatego też większość stosu P2P działa na TCP. + +### DevP2P {#devp2p} + +DevP2P sam w sobie jest całym stosem protokołów, które implementuje Ethereum w celu ustanowienia i utrzymania sieci peer-to-peer. Gdy nowe węzły dołączą do sieci, ich interakcje są regulowane przez protokoły ze stosu [DevP2P](https://github.com/ethereum/devp2p). Wszystkie opierają się na TCP i obejmują protokół transportowy RLPx, protokół przewodowy i szereg podprotokołów. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) to protokół zarządzający inicjowaniem, uwierzytelnianiem i utrzymywaniem sesji między węzłami. RLPx koduje wiadomości przy użyciu RLP (prefiks o rekursywnej długości), który jest bardzo oszczędzającą pamięć metodą kodowania danych w minimalne struktury do wysyłania pomiędzy węzłami. + +Sesja RLPx między dwoma węzłami rozpoczyna się od początkowego kryptograficznego uścisku dłoni. Oznacza to wysłanie przez węzeł wiadomości uwierzytelniającej, która następnie zostaje zweryfikowana przez rówieśnika. Po pomyślnej weryfikacji rówieśnik generuje wiadomość o potwierdzeniu uwierzytelnienia, którą następnie odsyła do węzła inicjującego. Jest to proces wymiany kluczy, który umożliwia węzłom na prywatne i bezpieczne komunikowanie się. Pomyślny kryptograficzny uścisk dłoni powoduje następnie, że oba węzły wysyłają do siebie wiadomość „hello” „po przewodzie”. Protokół przewodowy jest inicjowany przez pomyślną wymianę wiadomości „hello”. + +Wiadomości „hello” zawierają: + +- wersję protokołu +- identyfikator klienta +- port +- identyfikator węzła +- listę obsługiwanych podprotokołów + +Są to informacje potrzebne do pomyślnej interakcji, ponieważ określają jakie możliwości są współdzielone przez oba węzły oraz konfigurują komunikację. Istnieje proces negocjacji podprotokołów, w którym listy podprotokołów obsługiwanych przez każdy węzeł są porównywane, a te, które są wspólne dla obu węzłów, mogą zostać wykorzystane w sesji. + +Oprócz wiadomości „hello” protokół przewodowy może również wysyłać wiadomość „disconnect”, która ostrzega rówieśnika, że połączenie zostanie zamknięte. Protokół przewodowy zawiera również wiadomości PING i PONG, które są okresowo wysyłane w celu utrzymania otwartej sesji. Wymiany protokołów RLPx i przewodowego ustanawiają zatem podstawy komunikacji między węzłami, zapewniając strukturę do wymiany użytecznych informacji zgodnie z określonym podprotokołem. + +### Podprotokoły {#sub-protocols} + +#### Protokół komunikacyjny {#wire-protocol} + +Po połączeniu się rówieśników i rozpoczęciu sesji RLPx protokół przewodowy określa, w jaki sposób komunikują się rówieśnicy. Początkowo protokół przewodowy określał trzy główne zadania: synchronizacje łańcucha, propagację bloku i wymianę transakcji. Jednak kiedy Ethereum przeszło na proof-of-stake, propagowanie bloku i synchronizowanie łańcucha stało się częścią warstwy konsensusu. Wymiana transakcji nadal pozostaje zadaniem klientów wykonawczych. Wymiana transakcji odnosi się do wymiany oczekujących transakcji między węzłami tak, aby twórcy bloków mogli wybrać niektóre i uwzględnić je w następnym bloku. Szczegółowe informacje o tych zadaniach są dostępne [tutaj](https://github.com/ethereum/devp2p/blob/master/caps/eth.md). Klienci, którzy obsługują te podprotokoły, udostępniają je za pośrednictwem [JSON-RPC](/developers/docs/apis/json-rpc/). + +#### les (podprotokół lekkiego Ethereum) {#les} + +Jest to minimalny protiokół do synchronizowania lekkich klientów. Protokół ten był rzadko używany, ponieważ od pełnych węzłów wymaga się dostarczania danych do lekkich klientów bez żadnych zachęt. Domyślnym zachowaniem klientów wykonawczych jest niedostarczanie danych lekkim klientom poprzez les. Więcej informacji jest dostępnych w [specyfikacji](https://github.com/ethereum/devp2p/blob/master/caps/les.md) les. + +#### Snap {#snap} + +[Protokół snap](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) to opcjonalne rozszerzenie, które pozwala peerom na wymianę migawek ostatnich stanów, co umożliwia im weryfikację danych konta i pamięci masowej bez konieczności pobierania pośrednich węzłów drzewa Merkle trie. + +#### Wit (protokół świadka) {#wit} + +[Protokół świadka](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) to opcjonalne rozszerzenie, które umożliwia wymianę świadectw stanu między peerami, pomagając w synchronizacji klientów z końcówką łańcucha. + +#### Whisper {#whisper} + +Whisper był protokołem, który miał na celu umożliwienie bezpiecznego przesyłania wiadomości pomiędzy rówieśnikami bez zapisywania żadnych informacji w blockchainie. Był on częścią protokołu przewodowego DevP2P, ale obecnie jest wycofany. Istnieją również inne [powiązane projekty](https://wakunetwork.com/) o podobnych celach. + +## Warstwa konsensusu {#consensus-layer} + +Klienty konsensusu uczestniczą w osobnej sieci peer-to-peer z inną specyfikacją. Klienty konsensusu muszą uczestniczyć w plotkowaniu bloku, tak aby mogły otrzymać nowe bloki od rówieśników i rozgłaszać je, gdy najdzie ich kolej na bycie proponentem bloku. Podobnie jak w przypadku warstwy wykonawczej, wymaga to najpierw protokołu odkrywania, aby węzeł mógł znaleźć rówieśników i ustanowić bezpiecze sesje do wymiany bloków, poświadczeń itp. + +### Odkrywanie {#consensus-discovery} + +Podobnie jak klienci wykonawczy, klienci konsensusu używają protokołu [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) przez UDP do znajdowania peerów. Implementacja discv5 w warstwie konsensusu różni się od implementacji w klientach wykonawczych tylko tym, że zawiera adapter łączący discv5 ze stosem [libP2P](https://libp2p.io/), wycofując DevP2P. Sesje RLPx warstwy wykonawczej zostały porzucone na rzecz bezpiecznego kanału uścisku dłoni libP2P. + +### ENR-y {#consensus-enr} + +ENR dla węzłów konsensusu zawiera klucz publiczny węzła, adres IP, porty UDP i TCP oraz dwa pola specyficzne dla konsensusu: pole bitowe podsieci poświadczeń i klucz `eth2`. To pierwsze ułatwia węzłom znalezienie rówieśników uczestniczących w określonych podsieciach plotkujących poświadczenia. Klucz `eth2` zawiera informacje o tym, której wersji forka Ethereum używa węzeł, co zapewnia, że peery łączą się z właściwą siecią Ethereum. + +### libP2P {#libp2p} + +Stos libP2P obsługuje całą komunikację po odkrywaniu. Klienty mogą wybierać i nasłuchiwać na IPv4 i/lub IPv6 zgodnie z tym, jak to zostało określone w ich ENR. Protokoły w warstwie libP2P mogą zostać podzielone na domeny plotkujące i żądanie-odpowiedź. + +### Gossip {#gossip} + +Domena plotkująca zawiera wszystkie informacje, które muszą zostać szybko rozprzestrzenione w sieci. Wlicza się w to bloki śledzące, dowody, poświadczenia, wyjścia oraz odcięcia. Wszystko to przesyłane jest przy użyciu gossipsub v1 od libP2P i opiera się na różnych metadanych przechowywanych lokalnie w każdym węźle, wliczając w to maksymalny rozmiar ładunku plotkującego do odebrania i przesłania. Szczegółowe informacje o domenie gossip są dostępne [tutaj](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub). + +### Żądanie-odpowiedź {#request-response} + +Domena żądanie-odpowiedź zawiera protokoły dla klientów żądających specyficznych informacji od swoich rówieśników. Przykładem może być żądanie określonych bloków śledzących pasujących do określonych hashy korzeni lub znajdujących się w określonym zakresie slotów. Odpowiedzi są zawsze zwracane jako bajty zakodowane w formie SSZ i skompresowane przy użyciu Snappy. + +## Dlaczego klient konsensusu preferuje SSZ zamiast RLP? {#ssz-vs-rlp} + +SSZ to skrót od prostej serializacji. Wykorzystuje ona stałe przesunięcia, które ułatwiają dekodowanie indywidualnych części zakodowanej wiadomości bez potrzeby dekodowania całej struktury, co jest bardzo pomocne dla klienta konsensusu, ponieważ może efektywnie pobierać określone informacje z zakodowanej wiadomości. Został on również zaprojektowany specjalnie do integracji z protokołami Merkle, co przynosi korzyści w zakresie efektywności Merkleizacji. Ponieważ wszystkie hashe w warstwie konsensusu są korzeniami Merkle, przekłada się to na znaczącą poprawę. SSZ gwarantuje również unikalne reprezentacje wartości. + +## Łączenie klientów wykonawczych i konsensusu {#connecting-clients} + +Oba te klienty działają równoległe. Muszą być połączone, aby klient konsensusu mógł dostarczać instrukcje do klienta wykonawczego, a klient wykonawczy mógł przekazywać pakiety transakcji do klienta konsensusu, aby zostały uwzględnione w blokach śledzących. Ta komunikacja między dwoma klientami może zostać osiągnięta przy użyciu lokalnego połączenia RPC. API znane jako ['Engine-API'](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) definiuje instrukcje wysyłane między tymi dwoma klientami. Ponieważ oba klienty znajdują się za pojedynczą tożsamością sieciową, współdzielą ENR (Ethereum Node Record), który zawiera osobny klucz dla każdego klienta (klucz eth1 i klucz eth2). + +Poniżej przedstawiono podsumowanie przepływu, z odpowiednim stosem sieciowym w nawiasach. + +### Gdy klient konsensusu nie jest producentem bloku: {#when-consensus-client-is-not-block-producer} + +- Klient konsensusu otrzymuje blok za pośrednictwem protokołu plotkowania bloku (konsensus p2p) +- Klient konsensusu wstępnie waliduje blok, tzn. upewnia się, że pochodzi on od prawidłowego nadawcy i zawiera poprawne metadane. +- Transakcje w bloku zostają wysłane do warstwy wykonawczej jako ładunek wykonawczy (lokalne połączenie RPC) +- Warstwa wykonawcza wykonuje transakcje i waliduje stan w nagłówku bloku (tzn. sprawdza, czy hasze się zgadzają). +- Warstwa wykonawcza przekazuje zweryfikowane dane z powrotem do warstwy konsensusu, blok uważany jest teraz za zweryfikowany (lokalne połączenie RPC) +- Warstwa konsensusu dodaje blok na początek swojego łańcucha i poświadcza go, rozgłaszając poświadczenie w sieci (konsensus p2p) + +### Gdy klient konsensusu jest producentem bloku: {#when-consensus-client-is-block-producer} + +- Klient konsensusu otrzymuje powiadomienie, że jest twórcą następnego bloku (konsensus p2p) +- Warstwa konsensusu wywołuje metodę `create block` w kliencie wykonawczym (lokalne RPC). +- Warstwa wykonawcza uzyskuje dostęp do pamięci puli transakcji, która została zapełniona przez protokół plotkowania transakcji (wykonawcze p2p) +- Klient wykonawczy łączy transakcje w blok, wykonuje transakcje i generuje hash bloku +- Klient konsensusu pobiera transakcje i hash bloku od klienta wykonawczego, a następnie dodaje je do bloku śledzącego (lokalne RPC) +- Klient konsensusu rozgłasza blok po protokole plotkowania bloku (konsensus p2p) +- Inne klienty otrzymują zaproponowany blok za pomocą protokołu plotkowania bloku i weryfikują go tak jak zostało to opisane powyżej (konsensus p2p) + +Po poświadczeniu bloku przez wystarczającą liczbę walidatorów zostaje on dodany na początek łańcucha, uzasadniony i ostatecznie sfinalizowany. + +![](cons_client_net_layer.png) +![](exe_client_net_layer.png) + +Schemat warstwy sieciowej dla klientów konsensusu i wykonawczych, z [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) + +## Dalsza lektura {#further-reading} + +[DevP2P](https://github.com/ethereum/devp2p) +[LibP2p](https://github.com/libp2p/specs) +[Specyfikacje sieciowe warstwy konsensusu](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) +[kademlia do discv5](https://vac.dev/kademlia-to-discv5) +[Artykuł o kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) +[Wprowadzenie do p2p Ethereum](https://p2p.paris/en/talks/intro-ethereum-networking/) +[Relacja eth1/eth2](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) +[Wideo ze szczegółami dotyczącymi The Merge i klienta eth2](https://www.youtube.com/watch?v=zNIrIninMgg) diff --git a/public/content/translations/pl/developers/docs/networking-layer/network-addresses/index.md b/public/content/translations/pl/developers/docs/networking-layer/network-addresses/index.md new file mode 100644 index 00000000000..1e0f0513d1e --- /dev/null +++ b/public/content/translations/pl/developers/docs/networking-layer/network-addresses/index.md @@ -0,0 +1,39 @@ +--- +title: Adresy sieciowe +description: "Wprowadzenie do adresów sieciowych." +lang: pl +sidebarDepth: 2 +--- + +Węzły Ethereum muszą identyfikować się za pomocą pewnych podstawowych informacji, aby połączyć się z innymi węzłami. Aby zapewnić, że każdy potencjalny rówieśnik może zinterpretować te informacje, są one przekazywane w jednym z trzech standardów formatów, które każdy węzeł Ethereum może zrozumieć: multiaddr, enode lub Ethereum Node Records (ENR). ENR są obecnym standardem dla adresów sieciowych Ethereum. + +## Wymagania wstępne {#prerequisites} + +Zrozumienie tej strony wymaga pewnej wiedzy na temat [warstwy sieciowej](/developers/docs/networking-layer/) Ethereum. + +## Multiaddr {#multiaddr} + +Oryginalnym formatem adresu węzła Ethereum był „multiaddr” (skrót od „multi-addresses”). Multiaddr to uniwersalny format zaprojektowany dla sieci peer-to-peer. Adresy są reprezentowane jako pary klucz-wartość z kluczami oraz wartościami oddzielonymi ukośnikiem. Na przykład multiaddr dla węzła z adresem IPv4 192.168.22.27 nasłuchującego na porcie TCP 33000 wygląda następująco: + +`/ip4/192.168.22.27/tcp/33000` + +W przypadku węzła Ethereum multiaddr zawiera identyfikator węzła (hash jego klucza publicznego): + +`/ip4/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br` + +## Enode {#enode} + +Enode to sposób identyfikacji węzła Ethereum przy użyciu formatu adresu URL. Szesnastkowy identyfikator węzła jest zakodowany w części adresu URL przeznaczonej na nazwę użytkownika, oddzielony od hosta za pomocą znaku @. Nazwa hosta może zostać podana tylko jako adres IP; nazwy DNS nie są dozwolone. Port w sekcji nazwy hosta jest portem nasłuchującym TCP. Jeśli porty TCP i UDP (odkrywania) różnią się, port UDP jest określany jako parametr zapytania "discport". + +W poniższym przykładzie adres URL węzła opisuje węzeł o adresie IP 10.3.58.6, porcie TCP 30303 i porcie odkrywania UDP 30301. + +`enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301` + +## Rekordy węzłów Ethereum (ENR) {#enr} + +Ethereum Node Records (ENR) to ustandaryzowany format dla adresów sieci w Ethereum. Zastępuje on mulltiaddr i enode. Jest on wyjątkowo przydatny, ponieważ umożliwia na większą wymianę informacji pomiędzy węzłami. ENR zawiera podpis, numer sekwencyjny i pola określające schemat tożsamości wykorzystywany do tworzenia i walidacji podpisów. ENR może również zostać wypełniony dowolnymi danymi zorganizowanymi w pary klucz-wartość. Te pary klucz-wartość zawierają adres IP węzła oraz informacje o podprotokołach, z których węzeł może korzystać. Klienci konsensusu używają [specyficznej struktury ENR](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) do identyfikowania węzłów rozruchowych, a także zawierają pole `eth2` zawierające informacje na temat bieżącego forka Ethereum oraz podsieci plotkującej do poświadczeń (łączy to węzeł z określonym zestawem peerów, których poświadczenia są razem agregowane). + +## Dalsza lektura {#further-reading} + +- [EIP-778: Rekordy węzłów Ethereum (ENR)](https://eips.ethereum.org/EIPS/eip-778) +- [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/) diff --git a/public/content/translations/pl/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/pl/developers/docs/networking-layer/portal-network/index.md new file mode 100644 index 00000000000..238b36fbb09 --- /dev/null +++ b/public/content/translations/pl/developers/docs/networking-layer/portal-network/index.md @@ -0,0 +1,89 @@ +--- +title: "Sieć portali" +description: "Przegląd Sieci portali — sieci w fazie rozwoju, zaprojektowanej do obsługi klientów o niskich zasobach." +lang: pl +--- + +Ethereum to sieć złożona z komputerów, na których działa oprogramowanie klienckie Ethereum. Każdy z tych komputerów nazywany jest „węzłem”. Oprogramowanie klienckie pozwala węzłowi wysyłać i odbierać dane w sieci Ethereum oraz weryfikuje dane pod kątem zasad protokołu Ethereum. Węzły przechowują wiele danych historycznych w swojej pamięci dyskowej i dodają do nich nowe pakiety informacji, znane jako bloki, otrzymywane od innych węzłów w sieci. Jest to konieczne, aby zawsze sprawdzać, czy dany węzeł posiada informacje zgodne z resztą sieci. Oznacza to, że uruchomienie węzła może wymagać dużo miejsca na dysku. Niektóre operacje węzła mogą również wymagać dużej ilości pamięci RAM. + +Aby obejść ten problem z pamięcią dyskową, opracowano „lekkie” węzły, które żądają informacji od pełnych węzłów, zamiast przechowywać je wszystkie samodzielnie. Oznacza to jednak, że lekki węzeł nie weryfikuje informacji samodzielnie i zamiast tego ufa innemu węzłowi. Oznacza to również, że pełne węzły muszą podjąć dodatkową pracę, aby obsłużyć te lekkie węzły. + +Sieć portali to nowy projekt sieciowy dla Ethereum, który ma na celu rozwiązanie problemu dostępności danych dla „lekkich” węzłów bez konieczności ufania lub dodatkowego obciążania pełnych węzłów poprzez udostępnianie niezbędnych danych w małych fragmentach w całej sieci. + +Więcej na temat [węzłów i klientów](/developers/docs/nodes-and-clients/) + +## Dlaczego potrzebujemy Sieci portali {#why-do-we-need-portal-network} + +Węzły Ethereum przechowują własną pełną lub częściową kopię blockchaina Ethereum. Ta lokalna kopia jest używana do walidacji transakcji i zapewnienia, że węzeł podąża za właściwym łańcuchem. Te lokalnie przechowywane dane pozwalają węzłom niezależnie zweryfikować, czy przychodzące dane są ważne i prawidłowe, bez konieczności ufania żadnemu innemu podmiotowi. + +Ta lokalna kopia blockchaina oraz powiązane dane o stanie i potwierdzeniach zajmują dużo miejsca na dysku twardym węzła. Na przykład, do uruchomienia węzła za pomocą [Geth](https://geth.ethereum.org) sparowanego z klientem konsensusu zalecany jest dysk twardy o pojemności 2 TB. Korzystając z synchronizacji typu snap, która przechowuje tylko dane łańcucha z relatywnie najnowszego zestawu bloków, Geth zazwyczaj zajmuje około 650 GB miejsca na dysku, ale rośnie w tempie około 14 GB/tydzień (można okresowo przycinać węzeł z powrotem do 650 GB). + +Oznacza to, że uruchamianie węzłów może być kosztowne, ponieważ duża ilość miejsca na dysku musi być przeznaczona na Ethereum. W planie działania Ethereum istnieje kilka rozwiązań tego problemu, w tym [wygasanie historii](/roadmap/statelessness/#history-expiry), [wygasanie stanu](/roadmap/statelessness/#state-expiry) i [bezstanowość](/roadmap/statelessness/). Jednakże do ich wdrożenia prawdopodobnie pozostało jeszcze kilka lat. Istnieją również [lekkie węzły](/developers/docs/nodes-and-clients/light-clients/), które nie zapisują własnej kopii danych łańcucha, lecz żądają potrzebnych im danych od pełnych węzłów. Oznacza to jednak, że lekkie węzły muszą ufać pełnym węzłom w kwestii dostarczania rzetelnych danych, a także obciąża to pełne węzły, które muszą obsługiwać dane potrzebne lekkim węzłom. + +Sieć portali ma na celu zapewnienie alternatywnego sposobu pozyskiwania danych przez lekkie węzły, który nie wymaga zaufania ani znacznego zwiększania pracy, jaką muszą wykonywać pełne węzły. Sposobem na to będzie wprowadzenie nowej metody udostępniania danych przez węzły Ethereum w całej sieci. + +## Jak działa Sieć portali? {#how-does-portal-network-work} + +Węzły Ethereum mają ścisłe protokoły, które określają sposób ich wzajemnej komunikacji. Klienci wykonawczy komunikują się za pomocą zestawu podprotokołów znanych jako [DevP2P](/developers/docs/networking-layer/#devp2p), podczas gdy klienci konsensusu używają innego stosu podprotokołów o nazwie [libP2P](/developers/docs/networking-layer/#libp2p). Definiują one typy danych, które mogą być przekazywane między węzłami. + +![devP2P i libP2P](portal-network-devp2p-libp2p.png) + +Węzły mogą również udostępniać określone dane za pośrednictwem [API JSON-RPC](/developers/docs/apis/json-rpc/), w ten sposób aplikacje i portfele wymieniają informacje z węzłami Ethereum. Jednak żaden z nich nie jest idealnym protokołem do obsługi danych dla lekkich klientów. + +Lekcy klienci nie mogą obecnie żądać określonych fragmentów danych łańcucha za pośrednictwem DevP2P lub libP2p, ponieważ protokoły te są przeznaczone wyłącznie do umożliwienia synchronizacji łańcucha oraz rozpowszechniania bloków i transakcji. Lekcy klienci nie chcą pobierać tych informacji, ponieważ przestałyby być „lekkimi”. + +Interfejs API JSON-RPC również nie jest idealnym wyborem dla żądań danych przez lekkiego klienta, ponieważ opiera się na połączeniu z określonym pełnym węzłem lub scentralizowanym dostawcą RPC, który może obsłużyć dane. Oznacza to, że lekki klient musi ufać uczciwości danego węzła/dostawcy, a także pełny węzeł może być zmuszony do obsługi wielu żądań od wielu lekkich klientów, co zwiększa jego wymagania dotyczące przepustowości. + +Celem Sieci portali jest ponowne przemyślenie całego projektu, budując go specjalnie z myślą o lekkości, poza ograniczeniami projektowymi istniejących klientów Ethereum. + +Główną ideą Sieci portali jest wykorzystanie najlepszych elementów obecnego stosu sieciowego poprzez umożliwienie udostępniania informacji potrzebnych lekkim klientom, takich jak dane historyczne i tożsamość obecnej głowy łańcucha, za pośrednictwem lekkiej, zdecentralizowanej sieci peer-to-peer w stylu DevP2P, wykorzystującej [DHT](https://en.wikipedia.org/wiki/Distributed_hash_table) (podobne do Bittorrent). + +Pomysł polega na dodaniu do każdego węzła małych części całkowitych historycznych danych Ethereum i niektórych określonych obowiązków węzła. Następnie żądania są obsługiwane poprzez wyszukiwanie węzłów przechowujących określone dane, o które poproszono, i pobieranie ich od nich. + +Odwraca to normalny model, w którym lekkie węzły znajdują pojedynczy węzeł i proszą go o filtrowanie i obsługę dużych ilości danych; zamiast tego szybko filtrują dużą sieć węzłów, z których każdy obsługuje niewielkie ilości danych. + +Celem jest umożliwienie zdecentralizowanej sieci lekkich klientów Portal: + +- śledzenie głowy łańcucha +- synchronizowanie najnowszych i historycznych danych łańcucha +- pobieranie danych o stanie +- transmitowanie transakcji +- wykonywanie transakcji przy użyciu [EVM](/developers/docs/evm/) + +Korzyści płynące z tego projektu sieci to: + +- zmniejszenie zależności od scentralizowanych dostawców +- Zmniejszenie zużycia przepustowości internetowej +- Zminimalizowana lub zerowa synchronizacja +- Dostępność dla urządzeń o ograniczonych zasobach (\<1 GB RAM, \<100 MB miejsca na dysku, 1 procesor) + +Poniższa tabela przedstawia funkcje istniejących klientów, które mogą być dostarczane przez Sieć portali, umożliwiając użytkownikom dostęp do tych funkcji na urządzeniach o bardzo niskich zasobach. + +### Sieci portali + +| Lekki klient Beacon | Sieć stanu | Plotkowanie transakcji | Sieć historii | +| -------------------- | ------------------------ | ---------------------- | ------------- | +| Lekki łańcuch Beacon | Konto i pamięć kontraktu | Lekki mempool | Nagłówki | +| Dane protokołu | | | Treści bloków | +| | | | Potwierdzenia | + +## Domyślna różnorodność klientów {#client-diversity-as-default} + +Deweloperzy Sieci portali podjęli również decyzję projektową, aby od samego początku budować cztery oddzielne klienty Sieci portali. + +Klienci Sieci portali to: + +- [Trin](https://github.com/ethereum/trin): napisany w języku Rust +- [Fluffy](https://fluffy.guide): napisany w języku Nim +- [Ultralight](https://github.com/ethereumjs/ultralight): napisany w języku Typescript +- [Shisui](https://github.com/zen-eth/shisui): napisany w języku Go + +Posiadanie wielu niezależnych implementacji klientów zwiększa odporność i decentralizację sieci Ethereum. + +Jeśli jeden klient napotka problemy lub luki w zabezpieczeniach, inne klienty mogą nadal działać płynnie, zapobiegając pojedynczemu punktowi awarii. Dodatkowo, różnorodne implementacje klientów sprzyjają innowacjom i konkurencji, napędzając ulepszenia i zmniejszając ryzyko monokultury w ekosystemie. + +## Dalsza lektura {#further-reading} + +- [Sieć portali (Piper Merriam na Devcon Bogota)](https://www.youtube.com/watch?v=0stc9jnQLXA). +- [Discord Sieci portali](https://discord.gg/CFFnmE7Hbs) +- [Strona internetowa Sieci portali](https://www.ethportal.net/) diff --git a/public/content/translations/pl/developers/docs/networks/index.md b/public/content/translations/pl/developers/docs/networks/index.md index e00ca54a3cc..5109f87ab6a 100644 --- a/public/content/translations/pl/developers/docs/networks/index.md +++ b/public/content/translations/pl/developers/docs/networks/index.md @@ -1,14 +1,14 @@ --- title: Sieci -description: Przegląd sieci Ethereum i informacje o miejscach, w których można uzyskać ether testnetowy (ETH) do testowania aplikacji. +description: "Przegląd sieci Ethereum i informacje o miejscach, w których można uzyskać ether testnetowy (ETH) do testowania aplikacji." lang: pl --- -Sieci Ethereum to grupy połączonych komputerów, które komunikują się za pomocą protokołu Ethereum. Istnieje tylko jedna sieć główna Ethereum, ale do celów testowych i rozwojowych można tworzyć niezależne sieci zgodne z tymi samymi zasadami protokołu. Istnieje wiele niezależnych "sieci", które są zgodne z protokołem bez interakcji między sobą. Możesz nawet uruchomić jedną lokalnie na własnym komputerze do testowania inteligentnych kontraktów i aplikacji web3. +Sieci Ethereum to grupy połączonych komputerów, które komunikują się za pomocą protokołu Ethereum. Istnieje tylko jedna sieć główna Ethereum, ale do celów testowych i rozwojowych można tworzyć niezależne sieci zgodne z tymi samymi zasadami protokołu. Istnieje wiele niezależnych „sieci”, które są zgodne z protokołem bez interakcji między sobą. Możesz nawet uruchomić jedną lokalnie na własnym komputerze do testowania inteligentnych kontraktów i aplikacji web3. Twoje konto Ethereum będzie działać w różnych sieciach, ale saldo konta i historia transakcji nie będą przenoszone z głównej sieci Ethereum. Do celów testowych warto wiedzieć, które sieci są dostępne i jak uzyskać testnetowe ETH do zabawy. Ogólnie rzecz biorąc, ze względów bezpieczeństwa nie zaleca się ponownego używania kont sieci głównej w sieciach testowych i odwrotnie. -## Warunki wstępne {#prerequisites} +## Wymagania wstępne {#prerequisites} Przed zapoznaniem się z różnymi sieciami powinieneś zrozumieć [podstawy Ethereum](/developers/docs/intro-to-ethereum/), ponieważ sieci testowe dadzą ci tanią, bezpieczną wersję Ethereum do zabawy. @@ -24,7 +24,7 @@ Kiedy ludzie i giełdy rozmawiają o cenach ETH, mówią o ETH sieci głównej. ### Sieci testowe Ethereum {#ethereum-testnets} -Oprócz sieci głównej istnieją publiczne sieci testowe. Są to sieci wykorzystywane przez deweloperów protokołów lub inteligentnych kontraktów do testowania zarówno aktualizacji protokołu, jak i potencjalnych inteligentnych kontraktów w środowisku produkcyjnym przed wdrożeniem do sieci głównej. Można to traktować jako analogię relacji pomiędzy serwerami produkcyjnymi i pośredniczącymi. +Oprócz sieci głównej istnieją publiczne sieci testowe. Są to sieci wykorzystywane przez deweloperów protokołów lub deweloperów inteligentnych kontraktów do testowania zarówno aktualizacji protokołu, jak i potencjalnych inteligentnych kontraktów w środowisku produkcyjnym przed wdrożeniem do sieci głównej. Można to traktować jako analogię relacji pomiędzy serwerami produkcyjnymi i pośredniczącymi. Każdy napisany kod kontraktu należy przetestować w sieci testowej przed wdrożeniem go w sieci głównej. Wśród zdecentralizowanych aplikacji, które integrują się z istniejącymi inteligentnymi kontraktami, większość projektów ma kopie wdrożone w sieciach testowych. @@ -34,17 +34,13 @@ ETH w sieciach testowych nie powinno mieć żadnej realnej wartości, jednak pow #### Której sieci testowej powinienem użyć? -Dwie publiczne sieci testowe, które obecnie wykorzystują programiści klientów, to Sepolia i Hoodi. Sepolia to sieć dla twórców kontraktów i aplikacji przeznaczona do testowania aplikacji. Sieć Hoodi pozwala programistom protokołów testować aktualizacje sieci, a stakerom testować uruchomienie walidatorów. +Dwie publiczne sieci testowe utrzymywane przez programistów klienckich są obecnie Sepolia i Hoodi. Sepolia to sieć dla twórców kontraktów i aplikacji przeznaczona do testowania aplikacji. Sieć Hoodi pozwala programistom protokołu testowanie usprawnień sieci oraz umożliwia stakerom testowanie walidatorów. #### Sepolia {#sepolia} -**Sepolia to zalecana domyślna sieć testowa do rozwoju aplikacji**. Sieć Sepolia wykorzystuje zamknięty zestaw walidatorów. Jest stosunkowo nowa, co oznacza, że zarówno jej stan, jak i historia są bardzo małe. Oznacza to, że sieć szybko się synchronizuje, a uruchomienie węzła wymaga mniej pamięci masowej. Jest to przydatne dla użytkowników, którzy chcą szybko uruchomić węzeł i bezpośrednio komunikować się z siecią. +**Sepolia jest zalecaną domyślną siecią testową do rozwoju aplikacji**. Sieć Sepolia korzysta z zestawu uprawnionych walidatorów kontrolowanych przez zespoły klienckie i testujące. -- Zamknięty zestaw walidatorów, zarządzany przez zespoły klientów i testów -- Nowa sieć testowa, mniej wdrożonych aplikacji niż w innych sieciach testowych -- Szybka synchronizacja i wymaga minimalnej przestrzeni dyskowej do uruchomienia węzła - -##### Zasoby +##### Źródła - [Strona internetowa](https://sepolia.dev/) - [GitHub](https://github.com/eth-clients/sepolia) @@ -52,39 +48,73 @@ Dwie publiczne sieci testowe, które obecnie wykorzystują programiści klientó - [Etherscan](https://sepolia.etherscan.io) - [Blockscout](https://eth-sepolia.blockscout.com/) -##### Kraniki +##### Krany -- [QuickNode Sepolia Faucet](https://faucet.quicknode.com/drip) +- [Kran Alchemy Sepolia](https://www.alchemy.com/faucets/ethereum-sepolia) +- [Kran Chain Platform Sepolia](https://faucet.chainplatform.co/faucets/ethereum-sepolia/) +- [Kran Chainstack Sepolia](https://faucet.chainstack.com/sepolia-testnet-faucet) +- [Kran ekosystemu Ethereum](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia) +- [Kran ethfaucet.com Sepolia](https://ethfaucet.com/networks/ethereum) +- [Kran Google Cloud Web3 Sepolia](https://cloud.google.com/application/web3/faucet/ethereum/sepolia) - [Grabteeth](https://grabteeth.xyz/) -- [PoW Faucet](https://sepolia-faucet.pk910.de/) -- [Coinbase Wallet Faucet | Sepolia](https://coinbase.com/faucets/ethereum-sepolia-faucet) -- [Alchemy Sepolia Faucet](https://sepoliafaucet.com/) -- [Infura Sepolia Faucet](https://www.infura.io/faucet) -- [Chainstack Sepolia Faucet](https://faucet.chainstack.com/sepolia-faucet) -- [Ethereum Ecosystem Faucets](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia) +- [Kran Infura Sepolia](https://www.infura.io/faucet) +- [Kran PoW](https://sepolia-faucet.pk910.de/) +- [Kran QuickNode Sepolia](https://faucet.quicknode.com/ethereum/sepolia) #### Hoodi {#hoodi} -_Uwaga: [Sieć testowa Goerli jest przestarzała](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) i została zastąpiona przez Hoodi. Rozważ migrację swoich aplikacji do Sepolia._ - -Hoodi to sieć testowa do testowania walidacji i stakingu. Sieć Hoodi jest otwarta dla użytkowników, którzy chcą uruchomić walidatora sieci testowej. Stakerzy, którzy chcą testować aktualizacje protokołu przed ich wdrożeniem w sieci głównej, powinni używać Hoodi. +Hoodi jest siecią testową przeznaczoną do testowania procesu walidacji oraz stakowania. Sieć Hoodi jest otwarta dla użytkowników chcących uruchomić walidatora na sieci testowej. Stakerzy chcący przetestować aktualizację protokołu przed wdrożeniem jej na sieci głównej, powinni zatem użyć Hoodi. - Otwarty zestaw walidatorów, stakerzy mogą testować aktualizacje sieci -- Duży stan, przydatny do testowania złożonych interakcji ze smart kontraktami -- Dłuższy czas synchronizacji i wymaga więcej pamięci masowej do uruchomienia węzła +- Rozbudowany stan, przydatny do testowania złożonych interakcji inteligentnych kontraktów +- Wymaga więcej pamięci, aby uruchomić węzeł oraz dłuższego czasu synchronizacji -##### Zasoby +##### Źródła - [Strona internetowa](https://hoodi.ethpandaops.io/) - [GitHub](https://github.com/eth-clients/hoodi) -- [Explorer](https://explorer.hoodi.ethpandaops.io/) -- [Checkpoint Sync](https://checkpoint-sync.hoodi.ethpandaops.io/) +- [Eksplorator](https://explorer.hoodi.ethpandaops.io/) +- [Synchronizacja z punktu kontrolnego](https://checkpoint-sync.hoodi.ethpandaops.io/) +- [Otterscan](https://hoodi.otterscan.io/) +- [Etherscan](https://hoodi.etherscan.io/) + +##### Krany + +- [Kran Chain Platform Hoodi](https://faucet.chainplatform.co/faucets/ethereum-hoodi/) +- [Kran Hoodi](https://hoodi.ethpandaops.io/) +- [Kran PoW](https://hoodi-faucet.pk910.de/) + +#### Ephemery {#ephemery} + +Ephemery jest unikalną siecią testową, która resetuje się w pełni każdego miesiąca. Stan konsensusu przywracany jest do stanu początkowego co 28 dni, sprawiając, że wszystko, co dzieje się na sieci jest nietrwałe. To czyni Ephemery idealnym rozwiązaniem dla krótkotrwałych testów, szybkiego stawiania węzłów oraz aplikacji typu "hello world", które nie potrzebują trwałości. -##### Kraniki +- Zawsze świeży stan, krótkotrwałe testowanie walidatorów i apek +- Zawiera jedynie podstawowy zestaw kontraktów +- Otwarty zestaw walidatorów i łatwy dostęp do dużego zasobu funduszy +- Najniższe wymagania dotyczące węzła oraz najszybsza synchronizacja, <średnio 5GB -- [Hoodi Faucet](https://hoodi.ethpandaops.io/) +##### Źródła -Aby uruchomić Walidatora w sieci testowej Hoodi, użyj [Hoodi launchpad](https://hoodi.launchpad.ethereum.org/en/). +- [Strona internetowa](https://ephemery.dev/) +- [Github](https://github.com/ephemery-testnet/ephemery-resources) +- [Czat społeczności](https://matrix.to/#/#staker-testnet:matrix.org) +- [Blockscout](https://explorer.ephemery.dev/) +- [Otterscan](https://otter.bordel.wtf/) +- [Eksplorator Beacon](https://beaconlight.ephemery.dev/) +- [Synchronizacja z punktu kontrolnego](https://checkpoint-sync.ephemery.ethpandaops.io) +- [Launchpad](https://launchpad.ephemery.dev/) + +#### Krany + +- [Kran Bordel](https://faucet.bordel.wtf/) +- [Kran PoW Pk910](https://ephemery-faucet.pk910.de/) + +#### Holesky (przestarzały) {#holesky} + +Sieć testowa Holesky zostanie wycofana we wrześniu 2025 roku. Zamiast niego, stakerzy oraz dostawcy infrastruktury powinni używać Hoodi do testowania walidatorów. + +- [Ogłoszenie o wyłączeniu sieci testowej Holesky](https://blog.ethereum.org/2025/09/01/holesky-shutdown-announcement) – _blog EF, 1 września 2025_ +- [Aktualizacje sieci testowych Holesky i Hoodi](https://blog.ethereum.org/en/2025/03/18/hoodi-holesky) – _blog EF, 18 marca 2025_ ### Sieci testowe warstwy 2 {#layer-2-testnets} @@ -94,50 +124,93 @@ Aby uruchomić Walidatora w sieci testowej Hoodi, użyj [Hoodi launchpad](https: Sieć testowa dla [Arbitrum](https://arbitrum.io/). +##### Źródła + +- [Etherscan](https://sepolia.arbiscan.io/) +- [Blockscout](https://sepolia-explorer.arbitrum.io/) + ##### Krany -- [Kran Chainlink](https://faucets.chain.link/arbitrum-sepolia) -- [Kran Alchemy](https://www.alchemy.com/faucets/arbitrum-sepolia) +- [Kran Alchemy Arbitrum Sepolia](https://www.alchemy.com/faucets/arbitrum-sepolia) +- [Kran Chainlink Arbitrum Sepolia](https://faucets.chain.link/arbitrum-sepolia) +- [Kran ethfaucet.com Arbitrum Sepolia](https://ethfaucet.com/networks/arbitrum) +- [Kran QuickNode Arbitrum Sepolia](https://faucet.quicknode.com/arbitrum/sepolia) #### Optimistic Sepolia {#optimistic-sepolia} Sieć testowa dla [Optimism](https://www.optimism.io/). +##### Źródła + +- [Etherscan](https://sepolia-optimistic.etherscan.io/) +- [Blockscout](https://optimism-sepolia.blockscout.com/) + ##### Krany -- [Kran Chainlink](https://faucets.chain.link/optimism-sepolia) - [Kran Alchemy](https://www.alchemy.com/faucets/optimism-sepolia) +- [Kran Chainlink](https://faucets.chain.link/optimism-sepolia) +- [Kran ethfaucet.com Optimism Sepolia](https://ethfaucet.com/networks/optimism) +- [Kran sieci testowej](https://docs.optimism.io/builders/tools/build/faucets) #### Starknet Sepolia {#starknet-sepolia} Sieć testowa dla [Starknet](https://www.starknet.io). +##### Źródła + +- [Starkscan](https://sepolia.starkscan.co/) + ##### Krany - [Kran Alchemy](https://www.alchemy.com/faucets/starknet-sepolia) +- [Kran Blast Starknet Sepolia](https://blastapi.io/faucets/starknet-sepolia-eth) +- [Kran Starknet](https://starknet-faucet.vercel.app/) ## Sieci prywatne {#private-networks} -Sieć Ethereum jest siecią prywatną, jeśli jej węzły nie są połączone z siecią publiczną (tj. sieć główna albo sieć testowa). W tym kontekście "prywatna" oznacza jedynie sieć zastrzeżoną lub odizolowaną, a nie chronioną lub bezpieczną. +Sieć Ethereum jest siecią prywatną, jeśli jej węzły nie są podłączone do sieci publicznej (tj. sieci głównej lub sieci testowej). W tym kontekście „prywatna” oznacza jedynie sieć zastrzeżoną lub odizolowaną, a nie chronioną lub bezpieczną. -### Frameworki programistyczne {#development-networks} +### Sieci deweloperskie {#development-networks} Przy tworzeniu aplikacji Ethereum będziesz chciał uruchomić ją w sieci prywatnej, aby przed jej wdrożeniem sprawdzić, jak działa. Podobnie jak wtedy, gdy tworzysz lokalny serwer na komputerze do tworzenia stron internetowych, możesz utworzyć lokalną instancję blockchainu, aby przetestować swoją zdecentralizowaną aplikację. Pozwala to na znacznie szybszą iterację niż publiczna sieć testowa. -Istnieją projekty i narzędzia pomocne w tych działaniach. Dowiedz się więcej o [sieciach programistycznych](/developers/docs/development-networks/). +Istnieją projekty i narzędzia pomocne w tych działaniach. Dowiedz się więcej o [sieciach deweloperskich](/developers/docs/development-networks/). -### Sieci Consortium {#consortium-networks} +### Sieci konsorcjum {#consortium-networks} Proces konsensusu jest kontrolowany przez uprzednio określony zestaw zaufanych węzłów. Na przykład prywatna sieć znanych instytucji akademickich, z których każda zarządza jednym węzłem, a bloki są zatwierdzane przez próg sygnatariuszy w ramach sieci. Jeśli publiczna sieć Ethereum jest jak publiczny Internet, to sieć Consortium jest jak prywatny intranet. +## Dlaczego sieci testowe Ethereum noszą nazwy stacji metra? {#why-naming} + +Wiele sieci testowych Ethereum nosi nazwy prawdziwych stacji metra lub pociągów. Ta tradycja nazewnictwa zaczęła się wcześnie i odzwierciedla globalne miasta, w których mieszkali lub pracowali współtwórcy. Jest symboliczna, zapadająca w pamięć i praktyczna. Tak jak sieci testowe są odizolowane od sieci głównej Ethereum, tak linie metra działają oddzielnie od ruchu naziemnego. + +### Powszechnie używane i starsze sieci testowe {#common-and-legacy-testnets} + +- **Sepolia** – dzielnica w Atenach (Grecja) połączona z metrem. Obecnie używana do testowania inteligentnych kontraktów i dapek. +- **Hoodi** – nazwa pochodzi od stacji metra Hoodi w Bengaluru w Indiach. Używana do testowania walidatorów i aktualizacji protokołów. +- **Goerli** _(przestarzały)_ – nazwa pochodzi od dworca Görlitzer Bahnhof w Berlinie w Niemczech. +- **Rinkeby** _(przestarzały)_ – nazwa pochodzi od przedmieścia Sztokholmu ze stacją metra. +- **Ropsten** _(przestarzały)_ – odnosi się do obszaru i dawnego terminalu promowego/metra w Sztokholmie. +- **Kovan** _(przestarzały)_ – nazwa pochodzi od stacji MRT w Singapurze. +- **Morden** _(przestarzały)_ – nazwa pochodzi od stacji londyńskiego metra. Pierwsza publiczna sieć testowa Ethereum. + +### Inne wyspecjalizowane sieci testowe {#other-testnets} + +Niektóre sieci testowe zostały stworzone do krótkoterminowych testów lub testów specyficznych dla aktualizacji i niekoniecznie mają motyw metra: + +- **Holesky** _(przestarzały)_ – nazwa pochodzi od stacji Holešovice w Pradze. Używana do testowania walidatorów; wycofana w 2025 r. +- **Kiln**, **Zhejiang**, **Shandong**, **Prater**, **Pyrmont**, **Olympic** _(wszystkie przestarzałe)_ i **Ephemery** – stworzone specjalnie do symulacji aktualizacji, takich jak Połączenie, Szanghaj lub eksperymentów z walidatorami. Niektóre nazwy mają charakter regionalny lub tematyczny, a nie oparty na metrze. + +Używanie nazw stacji metra pomaga deweloperom szybko identyfikować i zapamiętywać sieci testowe bez konieczności polegania na numerycznych identyfikatorach łańcucha. Odzwierciedla również kulturę Ethereum: praktyczną, globalną i skoncentrowaną na człowieku. + ## Powiązane narzędzia {#related-tools} -- [Chainlist](https://chainlist.org/) — _lista sieci EVM do połączenia portfeli i dostawców z odpowiednim identyfikatorem łańcucha i identyfikatorem sieci_ -- [ Łańcuchy oparte na EVM](https://github.com/ethereum-lists/chains) — _ repozytorium GitHub metadanych łańcucha, które zasila Chainlist_ +- [Chainlist](https://chainlist.org/) _lista sieci EVM do połączenia portfeli i dostawców z odpowiednim identyfikatorem łańcucha i identyfikatorem sieci_ +- [Łańcuchy oparte na EVM](https://github.com/ethereum-lists/chains) _repozytorium GitHub z metadanymi łańcucha, które zasilają Chainlist_ ## Dalsza lektura {#further-reading} -- [Propozycja: Przewidywalny cykl życia sieci testowej Ethereum](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) +- [Propozycja: Przewidywalny cykl życia sieci testowych Ethereum](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) - [Ewolucja sieci testowych Ethereum](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/) diff --git a/public/content/translations/pl/developers/docs/nodes-and-clients/archive-nodes/index.md b/public/content/translations/pl/developers/docs/nodes-and-clients/archive-nodes/index.md new file mode 100644 index 00000000000..b78ec563c49 --- /dev/null +++ b/public/content/translations/pl/developers/docs/nodes-and-clients/archive-nodes/index.md @@ -0,0 +1,81 @@ +--- +title: "Węzeł archiwalny Ethereum" +description: "Przegląd węzłów archiwalnych" +lang: pl +sidebarDepth: 2 +--- + +Węzeł archiwalny to instancja klienta Ethereum skonfigurowanego do tworzenia archiwum wszystkich historycznych stanów. Jest to przydatne narzędzie dla niektórych przypadków użycia, ale może być trudniejsze do uruchomienia niż pełny węzeł. + +## Wymagania wstępne {#prerequisites} + +Należy rozumieć koncepcję [węzła Ethereum](/developers/docs/nodes-and-clients/), [jego architekturę](/developers/docs/nodes-and-clients/node-architecture/), [strategie synchronizacji](/developers/docs/nodes-and-clients/#sync-modes), praktyki [uruchamiania](/developers/docs/nodes-and-clients/run-a-node/) i [korzystania z nich](/developers/docs/apis/json-rpc/). + +## Czym jest węzeł archiwalny + +Aby zrozumieć znaczenie węzła archiwalnego, wyjaśnijmy pojęcie „stanu”. Ethereum można określić jako _maszynę stanową opartą na transakcjach_. Składa się kont i aplikacji wykonujących transakcje, które zmieniają jego stan. Globalne dane zwierające informacje o każdym koncie i kontrakcie są przechowywanie w bazie danych o strukturze drzewa trie, nazywanej stanem. Zajmuje się tym klient warstwy wykonawczej (EL) i obejmuje: + +- Salda i nonce kont +- Kod oraz pamięć kontraktu +- Dane związane z konsensusem, np. kontrakt depozytowy stakingu + +Aby wchodzić w interakcję z siecią, weryfikować i tworzyć nowe bloki, klienty Ethereum muszą nadążać za najnowszymi zmianami (czubkiem łańcucha), a więc bieżącym stanem. Klient warstwy wykonawczej skonfigurowany jako pełny węzeł weryfikuje i śledzi najnowszy stan sieci, ale buforuje tylko kilka ostatnich stanów, np. stan powiązany z ostatnimi 128 blokami, dzięki czemu może obsługiwać reorganizacje łańcucha i zapewniać szybki dostęp do najnowszych danych. Najnowszy stan jest tym, czego wszystkie klienty potrzebują do zweryfikowania przychodzących transakcji oraz korzystania z sieci. + +Pomyśl sobie o stanie jak o chwilowej migawce sieci w danym bloku, a o archiwum jak o powtórce historii. + +Historyczne stany mogą być bezpiecznie przycinane, ponieważ nie są wymaganie sieci do jej funkcjonowania oraz bezużyteczne byłoby dla klienta przechowywania tych wszystkich nieaktualnych danych. Stany, które istniały przed ostatnim blokiem (np. 128 bloków przed głową), są skutecznie odrzucane. Pełne węzły przechowują tylko historyczne dane blockchainu (bloki i transakcje) oraz sporadyczne historyczne migawki tak, aby mogły zregenerować starsze stany na żądanie. Robią to poprzez ponowne wykonanie przeszłych transakcji w EVM, co może być wymagające obliczeniowo, kiedy pożądany stan znajduje się daleko od najbliższej migawki. + +Jednak oznacza to, że dostęp do historycznego stanu na pełnym węźle zużywa wiele obliczeń. Klient może być zmuszony wykonać wszystkie przeszłe transakcje oraz obliczyć jeden historyczny stan od genezy. Węzły archiwalne rozwiązują ten problem, przechowując nie tylko najnowsze stany, ale również każdy historyczny stan stworzony po każdym bloku. Zasadniczo stanowi to kompromis z wymaganiem na większą przestrzeń dyskową. + +Należy zapamiętać, że siec nie zależy od węzłów archiwalnych na przechowywaniu i dostarczaniu wszystkich historycznych danych. Jak wspomniano wyżej, wszystkie historyczne stany pośrednie mogą zostać pozyskane na pełnym węźle. Transakcje są przechowywane przez dowolny pełny węzeł (obecnie mniej niż 400 GB) i mogą być odtworzone do utworzenia całego archiwum. + +### Przypadki użycia + +Zwykłe korzystanie z Ethereum takie jak wysyłanie transakcji, wdrażanie kontraktów, weryfikowanie konsensusu itp. nie wymaga dostępu do historycznych stanów. Użytkownicy nigdy nie potrzebują węzła archiwalnego do standardowych interakcji z siecią. + +Główną zaletą archiwum stanu jest szybki dostęp do historycznych danych podczas zażądań. Dla przykładu węzeł archiwalny natychmiastowo zwróciłby wyniki na pytania takie jak: + +- _Jakie było saldo ETH konta 0x1337... w bloku 15537393?_ +- _Jakie jest saldo tokena 0x w kontrakcie 0x w bloku 1920000?_ + +Jak już wyjaśniono powyżej, pełny węzeł potrzebowałby wygenerować te dane przez wykonanie EVM, co wykorzystuje CPU i wymaga czasu. Węzły archiwalne biorą te informacje ze swojego dysku i natychmiastowo odpowiadają. Jest to przydatna funkcja dla niektórych części infrastruktury, na przykład: + +- Dostawców usług takich jak eksploratory bloków +- Badaczy +- Analityków bezpieczeństwa +- Deweloperów zdecentralizowanych aplikacji +- Audytów i zgodności + +Istnieją różne bezpłatne [usługi](/developers/docs/nodes-and-clients/nodes-as-a-service/), które również umożliwiają dostęp do danych historycznych. Ponieważ uruchomienie węzła archiwalnego staje się coraz bardziej wymagające, dostęp ten jest w większości ograniczony i działa tylko w przypadku okazjonalnego dostępu. Jeśli Twój projekt wymaga ciągłego dostępu do historycznych danych, to zastanów się, czy nie uruchomić własnego węzła archiwalnego. + +## Implementacja i użycie + +W tym kontekście węzeł archiwalny oznacza dane obsługiwane przez klienty warstwy wykonawczej skierowane do użytkownika, ponieważ obsługują one bazą danych stanu oraz zapewniają punkty końcowe JSON-RPC. Opcje konfiguracji, czas synchronizacji i rozmiar bazy danych mogą różnić się w zależności od klienta. Szczegóły znajdziesz w dokumentacji swojego klienta. + +Przed uruchomieniem własnego węzła archiwalnego, zapoznaj się z różnicami między klientami, a w szczególności z różnymi [wymaganiami sprzętowymi](/developers/docs/nodes-and-clients/run-a-node/#requirements). Większość klientów nie jest zoptymalizowana pod względem tej funkcji, a ich archiwa mogą wymagać ponad 12 TB pamięci. W przeciwieństwie, implementacje takie jak Erigon mogą przechowywać te same dane, zajmując mniej niż 3 TB pamięci, co czyni je najbardziej efektywnym sposobem uruchamiania węzła archiwalnego. + +## Zalecane praktyki + +Poza ogólnymi [zaleceniami dotyczącymi uruchamiania węzła](/developers/docs/nodes-and-clients/run-a-node/) węzeł archiwalny może być bardziej wymagający pod względem sprzętu i konserwacji. Biorąc pod uwagę [kluczowe funkcje](https://github.com/ledgerwatch/erigon#key-features) Erigona, najbardziej praktycznym podejściem jest użycie implementacji klienta [Erigon](/developers/docs/nodes-and-clients/#erigon). + +### Sprzęt + +Zawsze weryfikuj wymagania sprzętowe dla konkretnego trybu w dokumentacji klienta. +Największym wymaganiem dla węzłów archiwalnych jest przestrzeń dyskowa. W zależności od klienta wacha się ona od 3 TB do 12 TB. Nawet jeśli dysk HDD może być lepszym rozwiązaniem do przechowywania dużych ilości danych, to synchronizacja ich oraz ciągłe aktualizowanie początku łańcucha będzie wymagało dysków SSD. Dyski [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html) są wystarczająco dobre, ale powinny być niezawodnej jakości, co najmniej [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences). Dyski mogą zostać zamontowane w komputerze stacjonarnym lub serwerze z odpowiednią liczbą gniazd. Takie dedykowane urządzenia są idealnie do uruchamiania węzłów, które mają pracować nieprzerwanie przez długi czas. Całkowicie możliwe jest również uruchomienie go na laptopie, ale możliwość przenoszenia wiąże się z dodatkowymi kosztami. + +Wszystkie dane muszą zmieścić się na jednym woluminie, dlatego dyski muszą być połączone, np. za pomocą [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) lub LVM. Warto również rozważyć użycie [ZFS](https://en.wikipedia.org/wiki/ZFS), ponieważ obsługuje on "Copy-on-write", co zapewnia, że dane są poprawnie zapisywane na dysku bez żadnych błędów niskiego poziomu. + +Dla większej stabilności i bezpieczeństwa w zapobieganiu przypadkowemu uszkodzeniu bazy danych, zwłaszcza w profesjonalnej konfiguracji, rozważ użycie [pamięci ECC](https://en.wikipedia.org/wiki/ECC_memory), jeśli Twój system ją obsługuje. Zaleca się zazwyczaj, aby pamięć RAM była taka sama jak dla pełnego węzła, ale więcej pamięci RAM może pomóc w przyspieszeniu procesu synchronizacji. + +Podczas początkowej synchronizacji, klienty w trybie archiwalnym wykonają każdą transakcję od samej genezy. Prędkość wykonania jest głównie ograniczana przez procesor, więc szybszy procesor może pomóc z czasem wstępnej synchronizacji. Na przeciętnym komputerze, początkowa synchronizacja może zająć nawet do miesiąca. + +## Dalsza lektura {#further-reading} + +- [Pełny węzeł Ethereum kontra węzeł archiwalny](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) – _QuickNode, wrzesień 2022_ +- [Budowa własnego węzła archiwalnego Ethereum](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) – _Thomas Jay Rush, sierpień 2021_ +- [Jak skonfigurować Erigon, RPC Erigona i TrueBlocks (scrape i API) jako usługi](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _– Magnus Hansson, zaktualizowano we wrześniu 2022_ + +## Powiązane tematy {#related-topics} + +- [Węzły i klienci](/developers/docs/nodes-and-clients/) +- [Uruchamianie węzła](/developers/docs/nodes-and-clients/run-a-node/) diff --git a/public/content/translations/pl/developers/docs/nodes-and-clients/bootnodes/index.md b/public/content/translations/pl/developers/docs/nodes-and-clients/bootnodes/index.md new file mode 100644 index 00000000000..e7bbfa06c80 --- /dev/null +++ b/public/content/translations/pl/developers/docs/nodes-and-clients/bootnodes/index.md @@ -0,0 +1,31 @@ +--- +title: "Wprowadzenie do węzłów rozruchowych Ethereum" +description: "Podstawowe informacje, których potrzebujesz, aby zrozumieć węzły rozruchowe" +lang: pl +--- + +Kiedy nowy węzeł dołącza do sieci Ethereum, to potrzebuje on połączyć się z węzłami, które już są w sieci, aby móc odkryć nowych rówieśników. Te punkty wejścia do sieci Ethereum są nazywane węzłami rozruchowymi. Klienty zazwyczaj mają zakodowaną w siebie listę węzłów rozruchowych. Te węzły rozruchowe są zazwyczaj uruchamiane przez zespół DevOps Fundacji Ethereum lub zespoły samych klientów. Należy zapamiętać, że węzły rozruchowe nie tym samym co węzły statyczne. Węzły statyczne są w kółko wywoływane, podczas gdy węzły rozruchowe są wywoływane, tylko gdy nie ma wystarczającej ilości rówieśników, do których można się podłączyć lub gdy węzeł potrzebuje utworzyć trochę nowych połączeń. + +## Połącz z węzłem rozruchowym {#connect-to-a-bootnode} + +Większość klientów ma wbudowaną listę węzłów rozruchowych, ale możesz również uruchomić własny węzeł rozruchowy lub użyć takiego, który nie znajduje się na zakodowanej na stałe liście klienta. W takim przypadku możesz określić je podczas uruchamiania swojego klienta w następujący sposób (ten przykład jest dla Geth, sprawdź dokumentację swojego klienta po więcej informacji): + +``` +geth --bootnodes "enode://@:" +``` + +## Uruchom węzeł rozruchowy {#run-a-bootnode} + +Węzły rozruchowe to pełne węzły, które nie znajdują się za NAT ([translacja adresów sieciowych](https://www.geeksforgeeks.org/network-address-translation-nat/)). Każdy pełny węzeł może zachowywać się jak węzeł rozruchowy, dopóki jest publicznie dostępny. + +Po uruchomieniu węzła powinien on zarejestrować Twój [enode](/developers/docs/networking-layer/network-addresses/#enode), który jest publicznym identyfikatorem pozwalającym innym na połączenie się z Twoim węzłem. + +Ten enode jest zazwyczaj generowany po każdym restarcie, a więc upewnij się, aby znaleźć w dokumentacji swojego klienta to, w jaki sposób stworzyć stały enode dla Twojego węzła rozruchowego. + +Aby być dobrym węzłem rozruchowym, dobrym pomysłem jest zwiększenie maksymalnej liczby rówieśników, którzy mogą się z nim połączyć. Uruchamianie węzła rozruchowego z wieloma rówieśnikami znacznie zwiększy wymagania przepustowości. + +## Dostępne węzły rozruchowe {#available-bootnodes} + +Lista wbudowanych węzłów rozruchowych w go-ethereum znajduje się [tutaj](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23). Te węzły rozruchowe są utrzymywane przez Fundację Ethereum oraz zespół go-ethereum. + +Dostępne są również inne listy węzłów rozruchowych utrzymywanych przez wolontariuszy. Upewnij się, aby zawsze uwzględnić przynajmniej jeden oficjalny węzeł rozruchowy, inaczej może Cię dotknąć atak zaćmienia (atak, w którym złośliwy podmiot odizolowuje określonego użytkownika lub węzeł od reszty sieci peer-to-peer). diff --git a/public/content/translations/pl/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/translations/pl/developers/docs/nodes-and-clients/client-diversity/index.md new file mode 100644 index 00000000000..50aceaa6b30 --- /dev/null +++ b/public/content/translations/pl/developers/docs/nodes-and-clients/client-diversity/index.md @@ -0,0 +1,132 @@ +--- +title: "Różnorodność klientów" +description: "Ogólne wyjaśnienie znaczenia różnorodności klientów Ethereum." +lang: pl +sidebarDepth: 2 +--- + +Zachowanie węzła Ethereum jest kontrolowane przez uruchomione oprogramowanie klienta. Istnieje wiele klientów Ethereum na poziomie produkcyjnym, a każdy z nich jest rozwijany oraz utrzymywany w innym języku oraz przez różne zespoły. Klienty są tworzone zgodnie ze wspólną specyfikacją, która zapewnia im płynną komunikację i posiadanie tych samych funkcji oraz dostarczanie podobnych doświadczeń użytkownika. Jednak obecnie rozłożenie klientów między węzłami nie jest wystarczające równa, aby w pełni wykorzystać potencjał fortyfikacji tej sieci. Idealnie byłoby, gdyby użytkownicy byli mniej więcej równo podzieleni między różnymi klientami, co by zapewniło jak największą różnorodność w sieci. + +## Wymagania wstępne {#prerequisites} + +Jeśli jeszcze nie rozumiesz, czym są węzły i klienci, sprawdź [węzły i klienci](/developers/docs/nodes-and-clients/). Warstwy [wykonawcza](/glossary/#execution-layer) i [konsensusu](/glossary/#consensus-layer) są zdefiniowane w słowniku. + +## Dlaczego istnieje wiele klientów? {#why-multiple-clients} + +Istnieje wiele niezależnie rozwijanych oraz utrzymywanych klientów, ponieważ różnorodność klientów uodparnia sieć przed atakami i błędami. Jest to unikalna zaleta Ethereum — inne blockchainy opierają się na nieomylności pojedynczego klienta. Nie wystarczy jednak zwykłe posiadanie wielu klientów, muszą one zostać przyjęte przez społeczność, a wszystkie aktywne węzły muszą być rozłożone stosunkowo równomiernie między nimi. + +## Dlaczego różnorodność klientów jest ważna? {#client-diversity-importance} + +Posiadanie wielu niezależnie rozwijanych i utrzymywanych klientów jest kluczowe dla zdrowia zdecentralizowanej sieci. Dowiedzmy się zatem dlaczego. + +### Błędy {#bugs} + +Błąd w indywidualnym kliencie jest mniejszym zagrożeniem dla sieci, gdy stanowi on mniejszość węzłów Ethereum. Przy mniej więcej równomiernym rozłożeniu węzłów pomiędzy różnymi klientami, prawdopodobieństwo dzielenia wspólnego problemu przez większość klientów jest małe, co sprawia, że sieć jest bardziej wytrzymała. + +### Odporność na ataki {#resilience} + +Różnorodność klientów również zapewnia odporność na ataki. Na przykład atak, który [nakłoni konkretnego klienta](https://twitter.com/vdWijden/status/1437712249926393858) do przejścia na konkretną gałąź łańcucha, jest mało prawdopodobny, ponieważ inne klienty raczej nie będą podatne na wykorzystanie w ten sam sposób, a kanoniczny łańcuch pozostaje nienaruszony. Mała różnorodność klientów zwiększa ryzyko związane z włamaniem do dominującego klienta. Różnorodność klientów udowodniła już, że jest ważną obroną przed złośliwymi atakami na sieć, dla przykładu atak blokady usług w Szanghaju w 2016 roku był możliwy, ponieważ atakujący zdołali oszukać dominującego klienta (Geth) do wykonania powolnej operacji i/o dysku dziesiątki tysięcy razy na blok. Ponieważ inne klienty niedzielące tej luki były online, Ethereum mogło odeprzeć atak i kontynuować działanie, podczas gdy luka w Geth została naprawiona. + +### Nieodwołalność w Proof-of-Stake {#finality} + +Błąd w kliencie konsensusu z ponad 33% węzłów Ethereum mógłby uniemożliwić warstwie konsensusu finalizację, co oznaczałoby, że użytkownicy nie mogliby mieć pewności, że transakcje nie zostaną w pewnym momencie cofnięte lub zmienione. To byłoby bardzo problematyczne dla wielu aplikacji zbudowanych na Ethereum, w szczególności DeFi. + + Co gorsza, krytyczny błąd w kliencie z większością dwóch trzecich mógłby spowodować nieprawidłowy podział i finalizację łańcucha, co doprowadziłoby do utknięcia dużej grupy walidatorów w nieprawidłowym łańcuchu. Jeśli chcieliby ponownie dołączyć do właściwego łańcucha, to walidatorzy ci byliby narażeni na odcięcia lub powolną i droga dobrowolną wypłatę oraz reaktywację. Wielkość odcięć rośnie wraz z liczbą winnych węzłów, przy czym 2/3 większości sieci zostałoby odcięte maksymalnie (32 ETH). + +Chociaż są to mało prawdopodobne scenariusze, to ekosystem Ethereum może zmniejszyć ryzyko, wyrównując rozkład klientów pośród aktywnych węzłów. Najlepiej byłoby, gdyby żaden klient konsensusu nigdy nie osiągnął 33% udziału wszystkich węzłów. + +### Współdzielona odpowiedzialność {#responsibility} + +Posiadanie większościowych klientów wiąże się również z ludzkimi kosztami. Nakłada to nadmiernie obciążenie i odpowiedzialność na mały zespół zajmujący się jego rozwojem. Im mniejsza jest różnorodność klientów tym większa odpowiedzialność na deweloperach utrzymujących klienta większościowego. Rozłożenie tej odpowiedzialności na wiele zespołów jest dobre zarówno dla zdrowia sieci węzłów Ethereum, jak i sieci ludzi. + +## Obecna różnorodność klientów {#current-client-diversity} + +### Klienty wykonawcze {#execution-clients-breakdown} + + + +### Klienty konsensusu {#consensus-clients-breakdown} + + + +Ten diagram może być nieaktualny — przejdź na [ethernodes.org](https://ethernodes.org) i [clientdiversity.org](https://clientdiversity.org), aby uzyskać aktualne informacje. + +Dwa powyższe wykresy kołowe przedstawiają migawki bieżącej różnorodności klientów dla warstwy wykonawczej i konsensusu (w chwili pisania, w październiku 2025 r.). Różnorodność klientów poprawiła się na przestrzeni lat, a w warstwie wykonawczej odnotowano spadek dominacji klienta [Geth](https://geth.ethereum.org/). Drugie miejsce z niewielką stratą zajmuje [Nethermind](https://www.nethermind.io/nethermind-client), trzecie [Besu](https://besu.hyperledger.org/), a czwarte [Erigon](https://github.com/ledgerwatch/erigon), przy czym pozostali klienci stanowią mniej niż 3% sieci. Najczęściej używany klient w warstwie konsensusu — [Lighthouse](https://lighthouse.sigmaprime.io/) — ma wynik zbliżony do drugiego najczęściej używanego klienta. [Prysm](https://prysmaticlabs.com/#projects) i [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) stanowią odpowiednio ~31% i ~14%, a pozostali klienci są rzadko używani. + +Dane dotyczące warstwy wykonawczej zostały uzyskane z [supermajority.info](https://supermajority.info/) w dniu 26 października 2025 r. Dane dla klientów konsensusu uzyskano od [Michaela Sproula](https://github.com/sigp/blockprint). Dane klientów konsensusu są cięższe do uzyskania, ponieważ klienty warstwy konsensusu nie zawsze mają jednoznaczne ślady, które mogą zostać wykorzystane do ich zidentyfikowania. Dane zostały wygenerowane przy użyciu algorytmu klasyfikacji, który czasami myli niektórych klientów mniejszościowych (zobacz więcej szczegółów [tutaj](https://twitter.com/sproulM_/status/1440512518242197516)). Na powyższym diagramie te niejednoznaczne klasyfikacje zostały oznaczone etykietą „albo/albo” (np. Nimbus/Teku). Niemniej jednak jasne jest, że większość sieci korzysta z klienta Prysm. Pomimo tego, że są to tylko migawki, wartości na diagramach zapewniają dobry ogólny obraz obecnego stanu różnorodności klientów. + +Aktualne dane dotyczące różnorodności klientów dla warstwy konsensusu są teraz dostępne na [clientdiversity.org](https://clientdiversity.org/). + +## Warstwa wykonawcza {#execution-layer} + +Dotąd, konwersacja na temat różnorodności klientów koncentrowała się głównie na warstwie konsensusu. Jednakże klient wykonawczy [Geth](https://geth.ethereum.org) stanowi obecnie około 85% wszystkich węzłów. Ten duży odsetek jest problematyczny z tych samych powodów co w przypadku klientów konsensusu. Dla przykładu błąd w Geth wpływający na obsługę transakcji lub tworzenie ładunków wykonawczych mógłby prowadzić do finalizowania problematycznych lub błędnych transakcji przez klientów konsensusu. Ethereum byłoby więc zdrowsze z bardziej zrównoważonym rozkładem klientów wykonawczych, w najlepszym przypadku z żadnym niereprezentującym ponad 33% sieci. + +## Użyj klienta mniejszościowego {#use-minority-client} + +Rozwiązanie kwestii różnorodności klientów wymaga czegoś więcej, niż tylko wybrania klienta mniejszościowego przez indywidualnych użytkowników — wymaga to również zmiany klientów przez pule walidatorów oraz instytucje, takie jak główne dapki i giełdy. Wszyscy użytkownicy mogą jednak przyczynić się do wyrównania obecnych dysproporcji oraz znormalizowania korzystania z całego dostępnego oprogramowania Ethereum. Po Połączeniu wszyscy operatorzy węzłów będą musieli uruchomić klienta wykonawczego i klienta konsensusu. Wybranie kombinacji klientów podanych poniżej, pomoże w zwiększeniu różnorodności klientów. + +### Klienci wykonawczy {#execution-clients} + +- [Besu](https://www.hyperledger.org/use/besu) +- [Nethermind](https://downloads.nethermind.io/) +- [Erigon](https://github.com/ledgerwatch/erigon) +- [Go-Ethereum](https://geth.ethereum.org/) +- [Reth](https://reth.rs/) + +### Klienci konsensusu {#consensus-clients} + +- [Nimbus](https://nimbus.team/) +- [Lighthouse](https://github.com/sigp/lighthouse) +- [Teku](https://consensys.io/teku) +- [Lodestar](https://github.com/ChainSafe/lodestar) +- [Prysm](https://prysm.offchainlabs.com/docs/) +- [Grandine](https://docs.grandine.io/) + +Techniczni użytkownicy mogą pomóc przyspieszyć ten proces, pisząc więcej samouczków i dokumentacji dla klientów mniejszościowych oraz zachęcają swoich operujących węzły rówieśników do migracji od dominujących klientów. Przewodniki dotyczące przełączenia się na mniejszościowego klienta konsensusu są dostępne na [clientdiversity.org](https://clientdiversity.org/). + +## Pulpity nawigacyjne różnorodności klientów {#client-diversity-dashboards} + +Szereg pulpitów nawigacyjnych zapewnia statystyki różnorodności klientów w czasie rzeczywistym dla warstwy wykonawczej i konsensusu. + +**Warstwa wykonawcza:** + +- [Rated.network](https://www.rated.network/) +- [clientdiversity.org](https://clientdiversity.org/) + +**Warstwa wykonawcza:** + +- [supermajority.info](https://supermajority.info//) +- [Ethernodes](https://ethernodes.org/) + +## Dalsza lektura {#further-reading} + +- [Różnorodność klientów w warstwie konsensusu Ethereum](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) +- [The Merge w Ethereum: Uruchamiaj klienta większościowego na własne ryzyko!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) – _Dankrad Fiest, 24 marca 2022_ +- [Znaczenie różnorodności klientów](https://our.status.im/the-importance-of-client-diversity/) +- [Lista usług węzłów Ethereum](https://ethereumnodes.com/) +- [„Pięć razy dlaczego” problemu różnorodności klientów](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08) +- [Różnorodność w Ethereum i jak ją rozwiązać (YouTube)](https://www.youtube.com/watch?v=1hZgCaiqwfU) +- [clientdiversity.org](https://clientdiversity.org/) + +## Powiązane tematy {#related-topics} + +- [Uruchom węzeł Ethereum](/run-a-node/) +- [Węzły i klienci](/developers/docs/nodes-and-clients/) diff --git a/public/content/translations/pl/developers/docs/nodes-and-clients/index.md b/public/content/translations/pl/developers/docs/nodes-and-clients/index.md index 5243a46b506..220c95fbc25 100644 --- a/public/content/translations/pl/developers/docs/nodes-and-clients/index.md +++ b/public/content/translations/pl/developers/docs/nodes-and-clients/index.md @@ -1,222 +1,313 @@ --- -title: Węzły i klienci -description: Przegląd węzłów Ethereum i oprogramowania klienta, a także jak skonfigurować węzeł i dlaczego powinieneś to zrobić. +title: "Węzły i klienci" +description: "Przegląd węzłów Ethereum i oprogramowania klienta, a także instrukcja jak skonfigurować węzeł i dlaczego należy to zrobić." lang: pl sidebarDepth: 2 -isOutdated: true --- -Aby Ethereum działało w sposób zdecentralizowany, potrzebuje rozproszonej sieci węzłów, która może weryfikować bloki i dane transakcji. Potrzebujesz aplikacji znanej jako klient, aby „uruchomić węzeł”. +Ethereum jest rozproszoną siecią komputerów (znanych jako węzły), które mogą weryfikować bloki i dane transakcji. Aby przekształcić komputer w węzeł Ethereum, należy uruchomić na nim oprogramowanie. Dwa oddzielne elementy oprogramowania (znane jako „klienci”) są wymagane do stworzenia węzła. ## Wymagania wstępne {#prerequisites} -Powinieneś zrozumieć koncepcję zdecentralizowanej sieci, zanim zagłębisz się w nią i uruchomisz własną instancję klienta Ethereum. Spójrz na nasze [wprowadzenie do Ethereum](/developers/docs/intro-to-ethereum/). +Zanim zagłębisz się w temat i uruchomisz własną instancję klienta Ethereum, powinieneś zrozumieć koncepcję sieci peer-to-peer oraz [podstawy EVM](/developers/docs/evm/). Zapoznaj się z naszym [wprowadzeniem do Ethereum](/developers/docs/intro-to-ethereum/). + +Jeśli dopiero zaczynasz przygodę z węzłami, zalecamy najpierw zapoznanie się z naszym przyjaznym dla użytkownika wprowadzeniem na temat [uruchamiania węzła Ethereum](/run-a-node). ## Czym są węzły i klienci? {#what-are-nodes-and-clients} -„Węzeł” odnosi się do oprogramowania znanego jako klient. Klient jest implementacją Ethereum, która za zadanie ma weryfikację wszystkich transakcji w kolejnych blokach, utrzymywać bezpieczeństwo sieci i poprawność danych. +„Węzeł” to dowolna instancja oprogramowania klienta Ethereum, która jest połączona z innymi komputerami, na których również działa oprogramowanie Ethereum, tworzące sieć. Klient to implementacja Ethereum, która weryfikuje dane zgodnie z zasadami protokołu i zapewnia bezpieczeństwo sieci. Węzeł musi uruchomić dwóch klientów: klienta konsensusu i klienta wykonawczego. + +- Klient wykonania (zwany również mechanizmem wykonania, klientem EL lub, wcześniej, klientem Eth1) nasłuchuje nowych transakcji emitowanych w sieci, wykonuje je w EVM i przechowuje najnowszy stan i bazę danych wszystkich aktualnych danych Ethereum. +- Klient konsensusu (znany również jako węzeł śledzący, klient CL lub, wcześniej, klient Eth2) wdraża algorytm konsensusu proof-of-stake, który umożliwia sieci osiągnięcie porozumienia na podstawie zwalidowanych danych od klienta wykonawczego. Istnieje również trzeci element oprogramowania, znany jako „walidator”, który może zostać dodany do klienta konsensusu, pozwalając węzłowi na uczestniczenie w zabezpieczaniu sieci. + +Te klienty działają razem, aby śledzić początek łańcucha Ethereum i umożliwić użytkownikom interakcję z siecią Ethereum. Modułowa konstrukcja z wieloma elementami oprogramowania współpracującymi ze sobą jest nazywana [złożonością hermetyzowaną](https://vitalik.eth.limo/general/2022/02/28/complexity.html). Takie podejście ułatwiło płynne przeprowadzenie [The Merge](/roadmap/merge), ułatwia utrzymywanie i rozwijanie oprogramowania klienta i umożliwia ponowne wykorzystanie poszczególnych klientów, na przykład w [ekosystemie warstwy 2](/layer-2/). + +![Połączone klienty wykonawcze i konsensusu](./eth1eth2client.png) +Uproszczony diagram połączonego klienta wykonawczego i konsensusu. + +### Różnorodność klientów {#client-diversity} + +Zarówno [klienci wykonawczy](/developers/docs/nodes-and-clients/#execution-clients), jak i [klienci konsensusu](/developers/docs/nodes-and-clients/#consensus-clients) istnieją w różnych językach programowania i są rozwijani przez różne zespoły. + +Wiele implementacji klientów może wzmocnić sieć, zmniejszając jej zależność od jednej bazy kodu. Idealnym celem jest osiągnięcie różnorodności bez dominacji któregokolwiek klienta w sieci, co eliminuje potencjalny pojedynczy punkt awarii. +Różnorodność języków zachęca także szerszą społeczność programistów do tworzenia integracji w preferowanych przez nich językach. -Możesz zobaczyć widok sieci Ethereum w czasie rzeczywistym, patrząc na [mapę węzłów](https://etherscan.io/nodetracker). +Dowiedz się więcej o [różnorodności klientów](/developers/docs/nodes-and-clients/client-diversity/). -Wiele [implementacji klientów Ethereum](/developers/docs/nodes-and-clients/#execution-clients) istnieje w wielu językach. Cechą wspólną tych implementacji klienckich jest to, że wszystkie są zgodne z formalną specyfikacją. Ta specyfikacja określa, jak działa sieć Ethereum i blockchain. +Wspólną cechą tych implementacji jest to, że wszystkie są zgodne z jedną specyfikacją. Specyfikacje określają sposób działania sieci Ethereum i blockchainu. Każdy szczegół techniczny został zdefiniowany, a specyfikacje można znaleźć jako: -![Klient Eth1x](./client-diagram.png) Uproszczony schemat funkcji klienta Ethereum. +- Pierwotnie, [Żółta Księga Ethereum](https://ethereum.github.io/yellowpaper/paper.pdf) +- [Specyfikacje wykonawcze](https://github.com/ethereum/execution-specs/) +- [Specyfikacje konsensusu](https://github.com/ethereum/consensus-specs) +- [EIP](https://eips.ethereum.org/) wdrożone w różnych [aktualizacjach sieci](/ethereum-forks/) + +### Śledzenie węzłów w sieci {#network-overview} + +Wiele trackerów oferuje w czasie rzeczywistym przegląd węzłów w sieci Ethereum. Należy pamiętać, że ze względu na naturę sieci zdecentralizowanych programy te mogą zapewnić jedynie ograniczony obraz sieci i mogą podawać różne wyniki. + +- [Mapa węzłów](https://etherscan.io/nodetracker) od Etherscan +- [Ethernodes](https://ethernodes.org/) od Bitfly +- [Nodewatch](https://www.nodewatch.io/) od Chainsafe, przeszukujący węzły konsensusu +- [Monitoreth](https://monitoreth.io/) – od MigaLabs, rozproszone narzędzie do monitorowania sieci +- [Tygodniowe raporty o stanie sieci](https://probelab.io) – od ProbeLab, przy użyciu [crawlera Nebula](https://github.com/dennis-tra/nebula) i innych narzędzi ## Typy węzłów {#node-types} -Jeśli chcesz uruchomić swój własny węzeł, powinieneś zrozumieć, że istnieją różne typy węzłów, które zużywają dane w inny sposób. W rzeczywistości klienci mogą uruchamiać 3 różne typy węzłów — lekki, pełny i archiwalny. Istnieją również opcje różnych strategii synchronizacji, które umożliwiają szybszą synchronizację. Synchronizacja odnosi się do tego, jak szybko może uzyskać najbardziej aktualne informacje o stanie Ethereum. +Jeśli chcesz [uruchomić własny węzeł](/developers/docs/nodes-and-clients/run-a-node/), powinieneś wiedzieć, że istnieją różne typy węzłów, które w różny sposób wykorzystują dane. Klienty mogą prowadzić trzy różne typy węzłów: lekkie, pełne i archiwalne. Dostępne są również opcje różnych strategii synchronizacji, które umożliwiają skrócenie czasu synchronizacji. Synchronizacja odnosi się do tego, jak szybko uzyskiwane są aktualne informacje o stanie Ethereum. ### Pełny węzeł {#full-node} -- Przechowuje pełne dane blockchainu. +Pełne węzły przeprowadzają walidację blockchainu blok po bloku, pobierając oraz weryfikując treść bloku i dane stanu dla każdego bloku. Istnieją różne klasy pełnych węzłów — niektóre zaczynają od bloku genezy i weryfikują każdy pojedynczy blok w całej historii blockchainu. Inne rozpoczynają weryfikację od nowszego bloku, który uznają za prawidłowy (np. „synchronizacja snap” w Geth). Niezależnie od miejsca rozpoczęcia weryfikacji, pełne węzły przechowują tylko lokalną kopię stosunkowo najnowszych danych (zazwyczaj najnowsze 128 bloków), pozwalając na usuwanie starszych danych w celu zaoszczędzenia miejsca na dysku. Starsze dane mogą zostać zregenerowanie, kiedy będą potrzebne. + +- Przechowuje pełne dane sieci blockchain (chociaż są one okresowo przycinane, więc pełny węzeł nie przechowuje wszystkich danych stanu od samej genezy) - Uczestniczy w walidacji bloków, weryfikuje wszystkie bloki i stany. -- Wszystkie stany mogą pochodzić z pełnego węzła. +- Wszystkie stany mogą zostać pozyskane z pamięci lokalnej lub wygenerowane z „migawek” przez pełny węzeł. - Obsługuje sieć i dostarcza dane na żądanie. -### Lekki węzeł {#light-node} - -- Przechowuje łańcuch nagłówków i żąda wszystkiego innego. -- Potrafi zweryfikować poprawność danych względem korzeni stanu w nagłówkach bloków. -- Przydatne dla urządzeń o niskiej przepustowości, takich jak urządzenia wbudowane lub telefony komórkowe, które nie stać na przechowywanie gigabajtów danych blockchainu. +### Węzeł archiwalny {#archive-node} -### Węzeł archiwum {#archive-node} +Węzły archiwalne to pełne węzły, które weryfikują każdy blok od genezy i nigdy nie usuwają żadnych pobranych danych. -- Przechowuje wszystko w pełnym węźle i buduje archiwum stanów historycznych. Potrzebne, jeśli chcesz zapytać o coś takiego jak saldo konta w bloku #4 000,000. +- Przechowuje wszystko w pełnym węźle i buduje archiwum stanów historycznych. Jest on potrzebny, jeśli chcesz sprawdzić przykładowo stan konta w bloku nr 4000000 lub po prostu niezawodnie przetestować własny zestaw transakcji bez potrzeby potwierdzania ich za pomocą śledzenia. - Dane te reprezentują jednostki terabajtów, co sprawia, że ​​węzły archiwów są mniej atrakcyjne dla przeciętnych użytkowników, ale mogą być przydatne w przypadku usług takich jak eksploratory bloków, dostawcy portfeli i analizy łańcuchów. -Synchronizowanie klientów w dowolnym trybie innym niż archiwum spowoduje wyczyszczenie danych łańcucha bloków. Oznacza to, że nie ma archiwum wszystkich stanów historycznych, ale cały węzeł jest w stanie budować je na żądanie. +Synchronizowanie klientów w trybie innym niż archiwalny spowoduje przycięcie danych blockchainu. To znaczy, że nie ma archiwum wszystkich historycznych stanów, ale pełny węzeł jest w stanie utworzyć je na żądanie. + +Dowiedz się więcej o [węzłach archiwalnych](/developers/docs/nodes-and-clients/archive-nodes). + +### Lekki węzeł {#light-node} + +Zamiast pobierać każdy blok, lekkie węzły pobierają tylko nagłówki bloków. Nagłówki te zawierają podsumowane informacje dotyczące zawartości bloków. Wszelkie inne informacje, jakich potrzebuje lekki węzeł, są żądane od pełnego węzła. Lekki węzeł może wtedy niezależnie weryfikować otrzymane dane, porównując je ze źródłami stanu w nagłówkach bloków. Lekkie węzły umożliwiają użytkownikom uczestniczenie w sieci Ethereum bez mocnego sprzętu i dużej przepustowości wymaganej do uruchomienia pełnych węzłów. Ostatecznie lekkie węzły mogą działać na telefonach komórkowych lub urządzeniach wbudowanych. Lekkie węzły nie uczestniczą w konsensusie (tzn. nie mogą być walidatorami), ale mogą uzyskać dostęp do blockchaina Ethereum z taką samą funkcjonalnością i gwarancjami bezpieczeństwa jak pełny węzeł. + +Lekkie klienty to obszar aktywnego rozwoju Ethereum i spodziewamy się wkrótce zobaczyć nowych lekkich klientów warstwy konsensusu i warstwy wykonawczej. +Istnieją również potencjalne sposoby dostarczania danych lekkich klientów przez [sieć gossip](https://www.ethportal.net/). Jest to korzystne, ponieważ sieć plotkująca mogłaby obsługiwać sieć lekkich węzłów, nie wymagając od pełnych węzłów obsługi żądań. + +Ethereum nie obsługuje jeszcze dużej liczby lekkich węzłów, ale obsługa lekkich węzłów jest obszarem, który w najbliższej przyszłości zapewne będzie się szybko rozwijał. W szczególności klienci tacy jak [Nimbus](https://nimbus.team/), [Helios](https://github.com/a16z/helios) i [LodeStar](https://lodestar.chainsafe.io/) są obecnie mocno skoncentrowani na lekkich węzłach. ## Dlaczego należy uruchomić węzeł Ethereum? {#why-should-i-run-an-ethereum-node} -Uruchomienie węzła pozwala Ci bezspornie i prywatnie korzystać z Ethereum podczas wspierania ekosystemu. +Uruchomienie węzła pozwala Ci na bezpośrednie, pozbawione zaufania i prywatne korzystanie z Ethereum, a jednocześnie wspieranie sieci poprzez zwiększanie jej niezawodności i decentralizacji. ### Korzyści dla Ciebie {#benefits-to-you} -Prowadzenie własnego węzła umożliwia korzystanie z Ethereum w sposób naprawdę prywatny, samowystarczalny i pozbawiony zaufania. Nie musisz ufać sieci, ponieważ możesz samodzielnie zweryfikować dane ze swoim klientem. „Nie ufaj, sprawdź” jest popularną mantrą blockchainu. +Prowadzenie własnego węzła umożliwia korzystanie z Ethereum w sposób prywatny, samowystarczalny i pozbawiony zaufania. Nie musisz ufać sieci, ponieważ możesz samodzielnie zweryfikować dane za pomocą swojego klienta. „Nie ufaj, sprawdzaj” jest popularną mantrą blockchainu. -- Twój węzeł samodzielnie weryfikuje wszystkie transakcje i bloki pod kątem zasad konsensusu. Oznacza to, że nie musisz polegać na żadnych innych węzłach w sieci ani w pełni im zaufać. -- Nie będziesz musiał ujawniać swoich adresów i sald do przypadkowych węzłów. Wszystko można sprawdzić z własnym klientem. -- Twoja zdecentralizowana aplikacja może być bezpieczniejsza i bardziej prywatna, jeśli używasz własnego węzła. [MetaMask](https://metamask.io), [MyEtherWallet](https://myetherwallet.com) i kilka innych portfeli można łatwo skierować na swój własny lokalny węzeł. +- Twój węzeł samodzielnie weryfikuje wszystkie transakcje i bloki pod względem zasad konsensusu. To znaczy, że nie musisz polegać na żadnych innych węzłach w sieci ani w pełni im ufać. +- Można używać portfela Ethereum z własnym węzłem. Można używać zdecentralizowanych aplikacji bezpieczniej i bardziej prywatnie, ponieważ nie musisz przekazywać swoich adresów i sald pośrednikom. Wszystko można sprawdzić za pomocą własnego klienta. [MetaMask](https://metamask.io), [Frame](https://frame.sh/) i [wiele innych portfeli](/wallets/find-wallet/) oferuje importowanie RPC, co pozwala im na korzystanie z Twojego węzła. +- Możesz korzystać z innych usług, które zależą od danych z Ethereum, i samodzielnie je prowadzić. Na przykład mogą to być walidator łańcucha śledzącego, oprogramowanie warstwy 2, infrastruktura, eksploratory bloków, operatorzy płatności itd. +- Możesz udostępnić własne niestandardowe [punkty końcowe RPC](/developers/docs/apis/json-rpc/). Możesz nawet publicznie oferować te punkty końcowe społeczności, aby pomóc im uniknąć dużych scentralizowanych dostawców. +- Możesz połączyć się ze swoim węzłem za pomocą **komunikacji międzyprocesowej (IPC)** lub przepisać węzeł tak, aby ładował Twój program jako wtyczkę. Zapewnia to niską latencję, co bardzo pomaga, np. podczas przetwarzania dużej ilości danych przy użyciu bibliotek web3 lub gdy musisz jak najszybciej zastąpić swoje transakcje (tj. frontrunning). +- Możesz bezpośrednio stakować ETH, aby zabezpieczać sieć i zdobywać nagrody. Zobacz [solo staking](/staking/solo/), aby zacząć. ![Jak uzyskać dostęp do Ethereum za pośrednictwem aplikacji i węzłów](./nodes.png) ### Korzyści dla sieci {#network-benefits} -Różnorodny zestaw węzłów jest ważny dla zdrowia, bezpieczeństwa i odporności operacyjnej Ethereum. +Różnorodny zestaw węzłów jest ważny dla dobrej kondycji, bezpieczeństwa i odporności operacyjnej Ethereum. -- Zapewniają one dostęp do danych blockchainu dla niewielkich klientów, którzy od niego zależą. W szczytowych okresach użytkowania musi być wystarczająca liczba pełnych węzłów, aby ułatwić synchronizację lekkich węzłów. Lekkie węzły nie przechowują całego łańcucha bloków, zamiast tego weryfikują dane za pomocą [głównych stanów w nagłówkach bloków](/developers/docs/blocks/#block-anatomy). Mogą żądać więcej informacji od bloków, jeśli ich potrzebują. -- Pełne węzły wymuszają reguły konsensusu proof-of-work, więc nie można ich oszukać w celu zaakceptowania bloków, które ich nie przestrzegają. Zapewnia to dodatkowe bezpieczeństwo w sieci, ponieważ jeśli wszystkie węzły były lekkimi węzłami, które nie przeprowadzają pełnej weryfikacji, górnicy mogą zaatakować sieć i na przykład tworzyć bloki z wyższymi nagrodami. +- Pełne węzły wymuszają zasady konsensusu, więc nie można ich oszukać w celu akceptowania bloków, które są niezgodne z tymi zasadami. Zapewnia to dodatkowe bezpieczeństwo w sieci, ponieważ gdyby wszystkie węzły były węzłami lekkimi, które nie dokonują pełnej weryfikacji, walidatorzy mogliby zaatakować sieć. +- W przypadku ataku, który pokona kryptoekonomiczną obronę [dowodu stawki](/developers/docs/consensus-mechanisms/pos/#what-is-pos), pełne węzły mogą przeprowadzić odzyskiwanie społeczne, wybierając podążanie za uczciwym łańcuchem. +- Większa liczba węzłów w sieci skutkuje bardziej zróżnicowaną i niezawodną siecią, stanowiącą ostateczny cel — decentralizację — i umożliwiającą system odporny na cenzurę i niezawodny. +- Pełne węzły zapewniają dostęp do danych blockchainu lekkim klientom, które są od nich zależne. Lekkie węzły nie przechowują całego łańcucha bloków, zamiast tego weryfikują dane za pomocą [korzeni stanu w nagłówkach bloków](/developers/docs/blocks/#block-anatomy). W razie potrzeby mogą zażądać dodatkowych informacji od pełnych węzłów. -Jeśli uruchomisz pełny węzeł, korzysta z niego cała sieć Ethereum. +Jeśli masz uruchomiony pełny węzeł, korzysta z niego cała sieć Ethereum, nawet jeśli jest on bez walidatora. ## Uruchamianie własnego węzła {#running-your-own-node} -### Projekty {#projects} +Interesuje Cię prowadzenie własnego klienta Ethereum? -[**Wybierz klienta i postępuj zgodnie z jego instrukcjami**](#clients) +Aby uzyskać wprowadzenie przyjazne dla początkujących, odwiedź naszą stronę [uruchamianie węzła](/run-a-node), aby dowiedzieć się więcej. -**ethnode —** **_uruchom węzeł Ethereum (Geth lub Parity) do celów rozwoju lokalnego._** +Jeśli jesteś bardziej technicznym użytkownikiem, zagłęb się w więcej szczegółów i opcji dotyczących tego, jak [uruchomić własny węzeł](/developers/docs/nodes-and-clients/run-a-node/). -- [GitHub](https://github.com/vrde/ethnode) +## Alternatywy {#alternatives} -**DAppNode —** **_system operacyjny do uruchamiania węzłów Web3, w tym Ethereum, na dedykowanym komputerze._** +Konfigurowanie własnego węzła może kosztować czas i zasoby, ale nie zawsze musisz uruchamiać własne wystąpienie. W tym przypadku możesz użyć zewnętrznego dostawcy API. Aby zapoznać się z omówieniem korzystania z tych usług, sprawdź [węzły jako usługa](/developers/docs/nodes-and-clients/nodes-as-a-service/). -- [dappnode.io](https://dappnode.io) +Jeśli ktoś uruchamia węzeł Ethereum z publicznym interfejsem API w Twojej społeczności, możesz skierować swoje portfele do węzła społeczności za pośrednictwem niestandardowego RPC i zyskać większą prywatność, niż korzystając z losowej zaufanej strony trzeciej. -### Źródła {#resources} +Z drugiej strony, jeśli prowadzisz klienta, możesz udostępniać go znajomym, którzy mogą tego potrzebować. -- [Uruchamianie pełnych węzłów Ethereum: kompletny przewodnik](https://medium.com/coinmonks/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _7 listopada 2019 r. – Justin Leroux_ -- [Schemat konfiguracji węzła](https://dev.to/5chdn/ethereum-node-configuration-modes-cheat-sheet-25l8) _5 stycznia, 2019 – Afryka Schoeden_ -- [Jak zainstalować i uruchomić węzeł Geth](https://www.quiknode.io/guides/infrastructure/how-to-install-and-run-a-geth-node) _4 października 2020 r. – Sahil Sen_ -- [Jak zainstalować i uruchomić węzeł OpenEthereum (poprzednio węzeł parzystości)](https://www.quiknode.io/guides/infrastructure/how-to-run-a-openethereum-ex-parity-client-node) _22 września 2020 r. – Sahil Sen_ +## Klienci wykonawczy {#execution-clients} -## Alternatywy {#alternatives} +Społeczność Ethereum utrzymuje wielu klientów wykonania o otwartym kodzie źródłowym (znanych wcześniej jako „klienci Eth1” lub po prostu „klienci Ethereum”), opracowanych przez różne zespoły przy użyciu różnych języków programowania. To sprawia, że sieć jest silniejsza i bardziej [zróżnicowana](/developers/docs/nodes-and-clients/client-diversity/). Idealnym celem jest osiągnięcie różnorodności bez zdominowania przez żadnego klienta w celu zmniejszenia pojedynczych punktów awarii. -Uruchamianie własnego węzła może być trudne i nie zawsze musisz uruchamiać własną instancję. W tym przypadku możesz użyć zewnętrznego dostawcy API, takiego jak [Infura](https://infura.io), [Alchemia](https://alchemyapi.io) lub [QuikNode](https://www.quiknode.io). Alternatywnie [ArchiveNode](https://archivenode.io/) to wspierany przez społeczność węzeł archiwizacji, który ma nadzieję na przekazanie danych archiwalnych w blockchain Ethereum niezależnym programistom, którzy w przeciwnym razie nie mogli sobie na nie pozwolić. +W tej tabeli przedstawiono podsumowanie poszczególnych klientów. Wszystkie z nich przechodzą [testy klienta](https://github.com/ethereum/tests) i są aktywnie utrzymywane, aby być na bieżąco z aktualizacjami sieci. -Jeśli ktoś uruchamia węzeł Ethereum z publicznym API w Twojej społeczności, możesz wskazać swoje lekkie portfele (takie jak MetaMask) do węzła społeczności [za pośrednictwem niestandardowego RPC](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node) i zyskać większą prywatność niż korzystając z zaufanej trzeciej strony. +| Klient | Język | Systemy operacyjne | Sieci | Strategie synchronizacji | Czyszczenie stanu | +| ------------------------------------------------------------------------------------------- | ------------------------ | --------------------- | ----------------------------- | ----------------------------------------------------------------------------------- | ----------------- | +| [Geth](https://geth.ethereum.org/) | Go | Linux, Windows, macOS | Sieć główna, Sepolia, Holesky | [Snap](#snap-sync), [Pełna](#full-sync) | Archive, Pruned | +| [Nethermind](https://www.nethermind.io/) | C#, .NET | Linux, Windows, macOS | Sieć główna, Sepolia, Holesky | [Snap](#snap-sync) (bez serwowania), Szybka, [Pełna](#full-sync) | Archive, Pruned | +| [Besu](https://besu.hyperledger.org/en/stable/) | Java | Linux, Windows, macOS | Sieć główna, Sepolia, Holesky | [Snap](#snap-sync), [Szybka](#fast-sync), [Pełna](#full-sync) | Archive, Pruned | +| [Erigon](https://github.com/ledgerwatch/erigon) | Go | Linux, Windows, macOS | Sieć główna, Sepolia, Holesky | [Pełna](#full-sync) | Archive, Pruned | +| [Reth](https://reth.rs/) | Rust | Linux, Windows, macOS | Sieć główna, Sepolia, Holesky | [Pełna](#full-sync) | Archive, Pruned | +| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(beta)_ | TypeScript | Linux, Windows, macOS | Sepolia, Holesky | [Pełna](#full-sync) | Pruned | -Z drugiej strony, jeśli uruchamiasz klienta, możesz podzielić się nim ze znajomymi, którzy mogą tego potrzebować. +Więcej informacji o obsługiwanych sieciach znajdziesz w [sieciach Ethereum](/developers/docs/networks/). -## Klienci {#execution-clients} +Każdy klient ma unikalne zastosowania i zalety, więc należy wybrać jednego z nich odpowiednio do własnych preferencji. Różnorodność pozwala implementacjom skupić się na różnych funkcjach i odbiorcach. Możesz wybrać klienta na podstawie funkcji, wsparcia, języka programowania lub licencji. -Ethereum jest zaprojektowany do oferowania różnych klientów, stworzonych przez różne zespoły przy użyciu różnych języków programowania. Dzięki temu sieć jest silniejsza i bardziej zróżnicowana. Idealnym celem jest osiągnięcie różnorodności bez zdominowania przez żadnego klienta w celu zmniejszenia pojedynczych punktów niepowodzenia. +### Besu {#besu} -W tabeli przedstawiono podsumowanie poszczególnych klientów. Wszystkie z nich są aktywnie opracowywane, utrzymywane i przechodzą [testy klienckie](https://github.com/ethereum/tests). +Hyperledger Besu to klient Ethereum klasy korporacyjnej dla sieci publicznych i autoryzowanych. Obsługuje wszystkie funkcje sieci głównej Ethereum, od śledzenia do GraphQL, ma rozbudowany monitoring i jest obsługiwany przez ConsenSys, zarówno w otwartych kanałach społecznościowych, jak i poprzez komercyjne umowy SLA dla przedsiębiorstw. Jest napisany w języku Java i oferowany na licencji Apache 2.0. -| Klient | Język | Systemy operacyjne | Sieci | Strategie synchronizacji | Wycinanie stanu | -| ------------------------------------------------------------ | -------- | --------------------- | ----------------------------------------- | ------------------------------ | --------------- | -| [Geth](https://geth.ethereum.org/) | Go | Linux, Windows, macOS | Mainnet, Görli, Rinkeby, Ropsten | Szybka, pełna | Archive, Pruned | -| [OpenEthereum](https://github.com/openethereum/openethereum) | Rust | Linux, Windows, macOS | Mainnet, Kovan, Ropsten i więcej | Warp, pełna | Archive, Pruned | -| [Nethermind](http://nethermind.io/) | C#, .NET | Linux, Windows, macOS | Mainnet, Görli, Ropsten, Rinkeby I więcej | Szybka, pełna | Archive, Pruned | -| [Besu](https://besu.hyperledger.org/en/stable/) | Java | Linux, Windows, macOS | Mainnet, Rinkeby, Ropsten, i Görli | Szybka, pełna | Archive, Pruned | -| [Trinity](https://trinity.ethereum.org/) | Python | Linux, macOS | Mainnet, Görli, Ropsten, Rinkeby i więcej | Pełna, wiązka, szybka/nagłówek | Archive | +Obszerna [dokumentacja](https://besu.hyperledger.org/en/stable/) Besu poprowadzi Cię przez wszystkie szczegóły dotyczące jego funkcji i konfiguracji. -Więcej informacji o obsługiwanych sieciach znajdziesz w rozdziale [Sieci Ethereum](/developers/docs/networks/). +### Erigon {#erigon} -### Zalety różnych implementacji {#advantages-of-different-implementations} +Erigon, znany wcześniej jako Turbo-Geth, powstał jako fork Go Ethereum, nastawiony na szybkość i oszczędność miejsca na dysku. Erigon jest całkowicie przebudowaną implementacją Ethereum, obecnie napisaną w języku Go, ale trwają prace nad implementacją w innych językach. Celem Erigon jest zapewnienie szybszej, bardziej modułowej i zoptymalizowanej implementacji Ethereum. W ciągu 3 dni może wykonać pełną synchronizację węzła archiwum, wykorzystując około 2 TB miejsca na dysku. -Każdy klient ma unikalne przypadki i zalety, więc powinieneś wybrać jeden na podstawie własnych preferencji. Różnorodność pozwala implementacjom skupić się na różnych funkcjach i odbiorcach. Możesz wybrać klienta na podstawie funkcji, wsparcia, języka programowania lub licencji. +### Go Ethereum {#geth} -#### Go Ethereum {#geth} +Go Ethereum (w skrócie Geth) jest jedną z oryginalnych implementacji protokołu Ethereum. Obecnie jest to najbardziej rozpowszechniony klient z największą bazą użytkowników i różnorodnością narzędzi dla użytkowników i deweloperów. Jest napisany w języku Go, w pełni open source i oferowany na licencji GNU LGPL v3. -Go Ethereum (w skrócie Geth) jest jedną z oryginalnych implementacji protokołu Ethereum. Obecnie jest to najbardziej rozpowszechniony klient z największą bazą użytkowników i różnorodnością narzędzi dla użytkowników i programistów. Jest napisany w Go, w pełni open source i licencjonowany na mocy GNU LGPL v3. +Dowiedz się więcej o Geth w jego [dokumentacji](https://geth.ethereum.org/docs/). -#### OpenEthereum {#openethereum} +### Nethermind {#nethermind} -OpenEthereum jest szybkim, bogatym w funkcje i zaawansowanym klientem Ethereum opartym na CLI. Został zbudowany w celu zapewnienia niezbędnej infrastruktury dla szybkich i niezawodnych usług, które wymagają szybkiej synchronizacji i maksymalnego czasu pracy. Celem OpenEthereum jest być najszybszy, najlżejszy i najbezpieczniejszy klient Ethereum. Zapewnia czystą, modułową bazę kodową pozwalającą na: +Nethermind to implementacja Ethereum stworzona w oparciu o technologię C# .NET, na licencji LGPL-3.0, działająca na wszystkich głównych platformach, w tym ARM. Oferuje wspaniałą wydajność dzięki: -- łatwe dostosowywanie. -- łatwą integrację z usługami lub produktami. -- minimalną ilość pamięci i miejsca przechowywania. +- zoptymalizowanej maszynie wirtualnej; +- dostępowi do stanu; +- funkcjom sieciowym i bogatym funkcjom, takim jak pulpity nawigacyjne Prometheus/Grafana, obsługa rejestrowania sekwencyjnego dla przedsiębiorstw, śledzenie JSON-RPC i wtyczki analityczne. -OpenEthereum jest rozwijany przy użyciu najnowocześniejszego języka programowania Rust i licencjonowanego na licencji GPLv3. +Nethermind ma również [szczegółową dokumentację](https://docs.nethermind.io), silne wsparcie dla deweloperów, społeczność online i wsparcie 24/7 dostępne dla użytkowników premium. -#### Nethermind {#nethermind} +### Reth {#reth} -Nethermind to implementacja Ethereum stworzona za pomocą stosu technologicznego C# .NET, działająca na wszystkich głównych platformach, w tym ARM. Oferuje ona wspaniałe wyniki dzięki: +Reth (skrót od Rust Ethereum) jest implementacją pełnego węzła Ethereum, która koncentruje się na byciu łatwym w obsłudze, dużej modułowości, szybkości oraz wydajności. Reth był pierwotnie stworzony i rozwijany przez Paradigm i jest licencjonowany na licencjach Apache oraz MIT. -- zoptymalizowanej maszynie wirtualnej -- dostępowi do stanu -- funkcjom sieciowym i bogatym funkcjom, takim jak pulpity nawigacyjne Prometheus/Graphana, obsługa rejestrowania sekwencyjnego dla przedsiębiorstw, śledzenie RPC JSON i wtyczki analityczne. +Reth jest gotowy do produkcji i nadaje się do użytku w środowiskach o znaczeniu krytycznym takich jak staking czy usługi o wysokim czasie działania. Dobrze sprawdza się w przypadkach, w których wymagana jest duża wydajność z dużym marginesem takich jak RPC, MEV, indeksowanie, symulacje czy działania P2P. -Nethermind ma również [dokładną dokumentację](https://docs.nethermind.io), silne wsparcie dla programistów, społeczność online i wsparcie 24/7 dostępne dla użytkowników premium. +Dowiedz się więcej, sprawdzając [Księgę Reth](https://reth.rs/) lub [repozytorium Reth na GitHubie](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth). -#### Besu {#besu} +### W fazie rozwoju {#execution-in-development} -Hyperledger Besu to klient Ethereum klasy korporacyjnej dla sieci publicznych i autoryzowanych. Obsługuje wszystkie funkcje sieci głównej Ethereum, od śledzenia do GraphQL, ma rozbudowany monitoring i jest obsługiwany przez ConsenSys, zarówno w otwartych kanałach społecznościowych, jak i poprzez komercyjne umowy SLA dla przedsiębiorstw. Jest napisany w Java i jest licencjonowany Apache 2.0. +Te klienty są nadal we wczesnej fazie rozwoju i nie zaleca się korzystania ich do celów produkcyjnych. -### Tryb synchronizacji {#sync-modes} +#### EthereumJS {#ethereumjs} -- Pełna – pobiera wszystkie bloki (w tym nagłówki, transakcje i paragony) i generuje stan łańcucha bloków stopniowo poprzez wykonanie każdego bloku. -- Szybka (domyślna) – pobiera wszystkie bloki (w tym nagłówki, transakcje i paragony), weryfikuje wszystkie nagłówki i pobiera stan i weryfikuje go w nagłówkach. -- Lekki – pobiera wszystkie nagłówki bloków, dane bloków i weryfikuje niektóre losowo. -- Synchronizacja warp – co 5000 bloków, węzły wykonają migawkę o krytycznym znaczeniu dla konsensusu. Każdy węzeł może pobrać te zrzuty w sieci, umożliwiając szybką synchronizację. [Więcej o warp](https://openethereum.github.io/Warp-Sync-Snapshot-Format.html) -- Synchronizacja beam – tryb synchronizacji, który umożliwia szybsze działanie. Nie wymaga długich oczekiwań na synchronizację, zamiast tego wypełnia dane z upływem czasu. [Więcej o beam](https://medium.com/@jason.carver/intro-to-beam-sync-a0fd168be14a) -- Synchronizacja nagłówka – możesz użyć zaufanego punktu kontrolnego, aby rozpocząć synchronizację od nowszego nagłówka, a następnie pozostawić to procesowi w tle, aby ostatecznie wypełnić luki +Klient wykonawczy EthereumJS jest napisany w TypeScript i składa się wielu pakietów, w tym podstawowych prymitywów Ethereum reprezentowanych przez klasy Block, Transaction i Merkle-Patricia Trie oraz podstawowych komponentów klienta, w tym implementacji maszyny wirtualnej Ethereum (EVM), klasy blockchainu i stosu sieciowiego DevP2P. -Typ synchronizacji określasz podczas konfiguracji, na przykład: +Dowiedz się więcej na ten temat, czytając jego [dokumentację](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master) -**Konfigurowanie synchronizacji lekkiej w [GETH](https://geth.ethereum.org/)** +## Klienci konsensusu {#consensus-clients} -`geth --syncmode "light"` +Istnieje wielu klientów konsensusu (wcześniej znanych jako klienci „Eth2”), którzy wspierają [aktualizacje konsensusu](/roadmap/beacon-chain/). Są one odpowiedzialne za całą logikę związaną z konsensusem, w tym algorytm wyboru forka, przetwarzanie atestacji oraz zarządzanie nagrodami i karami w ramach [dowodu stawki](/developers/docs/consensus-mechanisms/pos). -**Konfigurowanie synchronizacji nagłówka w Trinity** +| Klient | Język | Systemy operacyjne | Sieci | +| ------------------------------------------------------------- | ---------- | --------------------- | ---------------------------------------------------------- | +| [Lighthouse](https://lighthouse.sigmaprime.io/) | Rust | Linux, Windows, macOS | Łańcuch śledzący, Holesky, Pyrmont, Sepolia i inne | +| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | Linux, Windows, macOS | Łańcuch śledzący, Holesky, Sepolia i inne | +| [Nimbus](https://nimbus.team/) | Nim | Linux, Windows, macOS | Łańcuch śledzący, Holesky, Sepolia i inne | +| [Prysm](https://prysm.offchainlabs.com/docs/) | Go | Linux, Windows, macOS | Łańcuch śledzący, Gnosis, Holesky, Pyrmont, Sepolia i inne | +| [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java | Linux, Windows, macOS | Łańcuch śledzący, Gnosis, Holesky, Sepolia i inne | +| [Grandine](https://docs.grandine.io/) | Rust | Linux, Windows, macOS | Łańcuch śledzący, Holesky, Sepolia i inne | -`trinity --sync-from-checkpoint eth://block/byhash/0xa65877df954e1ff2012473efee8287252eee956c0d395a5791f1103a950a1e21?score=15,835,269,727,022,672,760,774` +### Lighthouse {#lighthouse} -## Sprzęt {#hardware} +Lighthouse jest implementacją klienta konsensusu napisaną w języku Rust na licencji Apache-2.0. Jest on utrzymywany przez Sigma Prime i jest stabilny i gotowy do produkcji od czasu genezy łańcucha śledzącego. Korzystają z niego różne firmy, pule stakingowe i osoby fizyczne. Ma być bezpieczny, wydajny i interoperacyjny w wielu środowiskach, od komputerów stacjonarnych po zaawansowane, zautomatyzowane wdrożenia. -Wymagania sprzętowe różnią się w zależności od klienta, ale zazwyczaj nie są wysokie, ponieważ węzeł musi po prostu pozostać zsynchronizowany. Nie należy mylić tego z wydobywaniem, które wymaga dużo większej mocy obliczeniowej. Jednak czas synchronizacji i wydajność poprawiają się dzięki mocniejszemu sprzętowi. W zależności od Twoich potrzeb i pragnień, Ethereum można uruchomić na Twoim komputerze, serwerze domowym, komputerach jednopłytowych lub wirtualnych serwerach prywatnych w chmurze. +Dokumentację można znaleźć w [Księdze Lighthouse](https://lighthouse-book.sigmaprime.io/) -Prostym sposobem na uruchomienie własnego węzła jest użycie wtyczek „plug and play”, takich jak [DAppNode](https://dappnode.io/). Zapewnia sprzęt do uruchamiania klientów i aplikacji od nich zależnych z prostym interfejsem użytkownika. +### Lodestar {#lodestar} -### Wymagania {#requirements} +Lodestar jest gotową do produkcji implementacją klienta konsensusu napisaną w języku Typescript na licencji LGPL-3.0. Jest on utrzymywany przez ChainSafe Systems i jest najnowszym klientem konsensusu dla solo-stakerów, deweloperów i badaczy. Lodestar składa się z węzła śledzącego i klienta walidatora obsługiwanego przez implementacje protokołów Ethereum w języku JavaScript. Lodestar ma na celu zwiększenie użyteczności Ethereum dzięki lekkim klientom, rozszerzeniu dostępności na większą grupę deweloperów i dalsze przyczynianie się do różnorodności ekosystemu. -Przed zainstalowaniem klienta upewnij się, że komputer ma wystarczającą ilość zasobów, aby go uruchomić. Poniżej znajdują się minimalne i zalecane wymagania, jednak kluczowym elementem jest przestrzeń dyskowa. Synchronizacja blockchainu Ethereum jest bardzo intensywna pod kątem wejścia/wyjścia. Najlepiej mieć dysk półprzewodnikowy (SSD). Aby uruchomić klienta Ethereum na dysku twardym, potrzebujesz co najmniej 8 GB pamięci RAM jako pamięci podręcznej. +Więcej informacji można znaleźć na [stronie internetowej Lodestar](https://lodestar.chainsafe.io/) -#### Minimalne wymagania {#recommended-specifications} +### Nimbus {#nimbus} -- Procesor z 2+ rdzeniami -- Minimum 4 GB RAM z SSD, 8 GB+ jeśli masz HDD -- Przepustowość 8 Mbit/s +Nimbus jest implementacją klienta konsensusu napisaną w języku Nim na licencji Apache 2.0. Jest to klient gotowy do produkcji, używany przez solo-stakerów i pule stakingu. Nimbus został zaprojektowany z myślą o efektywnym wykorzystaniu zasobów, dzięki czemu można go z równą łatwością uruchamiać na urządzeniach o ograniczonych zasobach, jak i w infrastrukturze przedsiębiorstwa, bez uszczerbku dla stabilności i wydajności osiągania nagród. Mniejsze obciążanie zasobów znaczy, że klient ma większy margines bezpieczeństwa, gdy sieć jest pod obciążeniem. -#### Zalecane specyfikacje {#recommended-specifications} +Dowiedz się więcej w [dokumentacji Nimbus](https://nimbus.guide/) -- Szybki procesor z ponad 4 rdzeniami -- 16 GB+ RAM -- Szybki SSD z co najmniej 500 GB wolnego miejsca -- 25+ Mbit/s przepustowość +### Prysm {#prysm} -W zależności od tego, które oprogramowanie i tryb synchronizacji mają być używane, potrzebne są setki GB przestrzeni dyskowej. Przybliżone wartości i wzrost można znaleźć poniżej. +Prysm to w pełni funkcjonalny klient konsensusu typu open-source napisany w języku Go na licencji GPL-3.0. Ma opcjonalny interfejs użytkownika aplikacji internetowej, a jego priorytetem jest wygoda użytkowania, dokumentacja i możliwość konfiguracji zarówno dla użytkowników-stakerów domowych, jak i instytucjonalnych. -| Klient | Rozmiar dysku (szybka synchronizacja) | Rozmiar dysku (pełne archiwum) | -| --------------- | ------------------------------------- | ------------------------------ | -| Klient Ethereum | 400 GB+ | 4,7 TB+ | -| OpenEthereum | 280 GB+ | 4,6 TB+ | -| Nethermind | 200 GB+ | 3 TB+ | -| Besu | 750 GB+ | 4 TB+ | +Odwiedź [dokumentację Prysm](https://prysm.offchainlabs.com/docs/), aby dowiedzieć się więcej. -Te wykresy pokazują, jak zawsze zmieniają się wymagania dotyczące przechowywania. Aby uzyskać najbardziej aktualne dane dla Geth i Parity, zobacz [pełną synchronizację danych](https://etherscan.io/chartsync/chaindefault) i [archiwum danych synchronizacji](https://etherscan.io/chartsync/chainarchive). +### Teku {#teku} -### Ethereum na komputerze jednopłytowym {#ethereum-on-a-single-board-computer} +Teku jest jednym z oryginalnych klientów genezy łańcucha śledzącego. Oprócz zwykłych celów (bezpieczeństwo, niezawodność, stabilność, użyteczność, wydajność) Teku dąży do tego, by w pełni spełniać wymogi wszystkich standardów klienta konsensusu. -Najbardziej wygodnym i tanim sposobem uruchomienia węzła Ethereum jest korzystanie z jednego komputera z architekturą ARM jak Raspberry Pi. [Ethereum na ARM](https://twitter.com/EthereumOnARM) dostarcza obrazy klientów Geth, Parity, Nethereumd i Besu. Oto prosty samouczek [jak zbudować i skonfigurować klienta ARM](/developers/tutorials/run-node-raspberry-pi/). +Teku oferuje bardzo elastyczne opcje wdrożenia. Węzeł śledzący i klient walidatora mogą być uruchomione razem jako jeden proces, co jest bardzo wygodne dla solo-stakerów, lub węzły można uruchomić oddzielnie w celu wykonywania zaawansowanych operacji stakingu. Ponadto Teku jest w pełni interoperacyjny z [Web3Signer](https://github.com/ConsenSys/web3signer/), co zapewnia bezpieczeństwo klucza do podpisu i ochronę przed slashingiem. -Małe, niedrogie i wydajne urządzenia, takie jak te, są idealne do uruchomienia węzła w domu. +Teku jest napisany w języku Java na licencji Apache 2.0. Został opracowany przez zespół ds. protokołów w ConsenSys, który jest również odpowiedzialny za oprogramowanie Besu i Web3Signer. Dowiedz się więcej w [dokumentacji Teku](https://docs.teku.consensys.net/en/latest/). -## Klienci Eth2 {#consensus-clients} +### Grandine {#grandine} -Pojawili się nowi klienci obsługujący [aktualizacje Eth2](/roadmap/beacon-chain/). Będą obsługiwać łańcuch śledzący i wspierać nowy mechanizm konsensusu [proof-of-stake](/developers/docs/consensus-mechanisms/pos/). +Grandine to implementacja klienta konsensusu napisana w języku Rust na licencji GPL-3.0. Jest szybko, wysoce wydajny i lekki a utrzymuje go główny zespół Grandine. Odpowiada na potrzeby wszystkich stakujących — od stakujących solo na urządzeniach o niskich zasobach takich jak Raspberry Pi aż do dużych instytucjonalnych stakujących, którzy utrzymują tysiące walidatorów. -## Dalsza lektura {#further-reading} +Dokumentację można znaleźć w [Księdze Grandine](https://docs.grandine.io/) + +## Tryby synchronizacji {#sync-modes} + +Aby śledzić i sprawdzać aktualne dane w sieci, klient Ethereum musi synchronizować się z najnowszym stanem sieci. Odbywa się to poprzez pobieranie danych z węzłów równorzędnych, kryptograficzną weryfikację ich integralności i budowanie lokalnej bazy danych blockchain. + +Tryby synchronizacji reprezentują różne podejścia do tego procesu z różnymi kompromisami. Klienci różnią się także pod względem implementacji algorytmów synchronizacji. Szczegółowe informacje na temat implementacji można znaleźć w oficjalnej dokumentacji wybranego klienta. + +### Tryby synchronizacji warstwy wykonawczej {#execution-layer-sync-modes} -W Internecie jest wiele instrukcji i informacji o klientach Ethereum, tutaj jest kilka, które mogą być pomocne. +Warstwa wykonawcza może być uruchomiona w różnych trybach, aby dopasować się do różnych przypadków użycia, od ponownego wykonania stanu blockchainu do synchronizowania tylko początku łańcucha od zaufanego punktu kontrolnego. + +#### Pełna synchronizacja {#full-sync} + +Pełna synchronizacja pobiera wszystkie bloki (w tym nagłówki i treści bloku) i generuje ponownie stan blockchainu przyrostowo, wykonując każdy blok od genezy. + +- Minimalizuje zaufanie i zapewnia najwyższe bezpieczeństwo, weryfikując każdą transakcję. +- Przy rosnącej liczbie transakcji przetworzenie wszystkich transakcji może zająć od kilku dni do kilku tygodni. + +[Węzły archiwalne](#archive-node) wykonują pełną synchronizację, aby zbudować (i zachować) pełną historię zmian stanu dokonanych przez każdą transakcję w każdym bloku. + +#### Szybka synchronizacja {#fast-sync} + +Podobnie jak w przypadku pełnej synchronizacji, szybka synchronizacja pobiera wszystkie bloki (w tym nagłówki, transakcję i potwierdzenia). Zamiast jednak odtwarzać historyczne transakcje, szybka synchronizacja opiera się na potwierdzeniach, dopóki nie dotrze do samego początku, kiedy to przełącza się na importowanie oraz przetwarzanie bloków, aby zapewnić pełny węzeł. + +- Strategia szybkiej synchronizacji. +- Zmniejsza zapotrzebowanie na przetwarzanie na rzecz wykorzystania przepustowości. + +#### Synchronizacja snap {#snap-sync} + +Synchronizacje snap również weryfikują łańcuch blok po bloku. Jednak, zamiast zaczynać od bloku genezy, synchronizacja snap zaczyna od nowszego „zaufanego” punktu kontrolnego, który wiadomo, że jest częścią prawdziwego blockchainu. Węzeł zapisuje okresowe punkty kontrolne, usuwając dane starsze od określonego wieku. Te migawki zostają użyte do regeneracji danych stanu w razie potrzeby, zamiast przechowywania ich w nieskończoność. + +- Najszybsza strategia synchronizacji, obecnie domyślna w sieci głównej Ethereum. +- Oszczędza wiele miejsca na dysku i przepustowości sieci bez poświęcania bezpieczeństwa. + +[Więcej o synchronizacji snap](https://github.com/ethereum/devp2p/blob/master/caps/snap.md). + +#### Lekka synchronizacja {#light-sync} + +W trybie lekkiego klienta pobierane są wszystkie nagłówki bloków, dane bloków i niektóre są sprawdzane losowo. Synchronizuje tylko końcówkę łańcucha z zaufanego punktu kontrolnego. + +- Pobiera tylko najnowszy stan, opierając się na zaufaniu do deweloperów i mechanizmie konsensusu. +- Klient gotowy do użycia z bieżącym stanem sieci w ciągu kilku minut. + +**Uwaga**: Lekka synchronizacja nie działa jeszcze z Ethereum w wersji z dowodem stawki – nowe wersje lekkiej synchronizacji powinny pojawić się wkrótce! + +[Więcej o lekkich klientach](/developers/docs/nodes-and-clients/light-clients/) + +### Tryby synchronizacji warstwy konsensusu {#consensus-layer-sync-modes} + +#### Synchronizacja optymistyczna {#optimistic-sync} + +Synchronizacja optymistyczna to strategia synchronizacji po Połączeniu, zaprojektowana jako możliwa do wybrania i zgodna wstecz, pozwalająca węzłom wykonania na synchronizację za pomocą ustalonych metod. Silnik wykonawczy może _optymistycznie_ importować bloki beacon bez ich pełnej weryfikacji, znajdować najnowszą głowicę, a następnie rozpocząć synchronizację łańcucha za pomocą powyższych metod. Następnie, gdy klient wykonania nadrobi zaległości, poinformuje klienta konsensusu o ważności transakcji w łańcuchu śledzącym. + +[Więcej o synchronizacji optymistycznej](https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md) + +#### Synchronizacja z punktu kontrolnego {#checkpoint-sync} + +Synchronizacja punktów kontrolnych, znana także jako synchronizacja ze słabą podmiotowością, zapewnia użytkownikowi lepsze wrażenia z synchronizacji węzła śledzącego. Opiera się na założeniach o [słabej subiektywności](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/), co umożliwia synchronizację Łańcucha Śledzącego z ostatniego punktu kontrolnego słabej subiektywności, a nie od genezy. Synchronizacje z punktu kontrolnego znacznie skracają czas początkowej synchronizacji przy podobnych założeniach dotyczących zaufania, jak w przypadku synchronizacji od [bloku genezy](/glossary/#genesis-block). + +W praktyce oznacza to, że węzeł łączy się z usługą zdalną, aby pobrać ostatnie sfinalizowane stany, i kontynuuje weryfikację danych od tego punktu. Stronie trzeciej dostarczającej danych trzeba zaufać i należy ją starannie wybrać. + +[Więcej o synchronizacji z punktu kontrolnego](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice) + +## Dalsza lektura {#further-reading} -- [Ethereum 101 – Część 2 – Zrozumienie węzłów](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _–Wil Barnes, 13 lutego 2019_ -- [Uruchamianie pełnych węzłów Ethereum: kompletny przewodnik](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _7 listopada 2019 r. – Justin Leroux_ -- [Analizowanie wymagań sprzętowych dla Ethereum w pełni zweryfikowany węzeł](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _– Albert Palau, 24 września 2018 r._ -- [Uruchomienie węzła Besu na Ethereum Mainnet: Korzyści, Wymagania i Ustawienia](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _– Felipe Faraggi, 7 maja 2020_ +- [Ethereum 101 – część 2 – Zrozumieć węzły](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _– Wil Barnes, 13 lutego 2019_ +- [Uruchamianie pełnych węzłów Ethereum: przewodnik dla słabo zmotywowanych](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– Justin Leroux, 7 listopada 2019_ ## Powiązane tematy {#related-topics} @@ -225,4 +316,4 @@ W Internecie jest wiele instrukcji i informacji o klientach Ethereum, tutaj jest ## Powiązane samouczki {#related-tutorials} -- [Turn your Raspberry Pi 4 into an Eth 1.0 or Eth 2.0 node just by flashing the MicroSD card – Installation guide](/developers/tutorials/run-node-raspberry-pi/) _– Flash your Raspberry Pi 4, plug in an ethernet cable, connect the SSD disk and power up the device to turn the Raspberry Pi 4 into a full Ethereum 1.0 node or an Ethereum 2.0 node (beacon chain / validator)._ +- [Zamień swoje Raspberry Pi 4 w węzeł walidatorski poprzez wgranie obrazu na kartę MicroSD – instrukcja instalacji](/developers/tutorials/run-node-raspberry-pi/) _– Sporządź obraz urządzenia Raspberry Pi 4, podłącz kabel Ethernet, podłącz dysk SSD i włącz urządzenie, aby zamienić Raspberry Pi 4 w pełnoprawny węzeł Ethereum działający w warstwie wykonawczej (sieci głównej) i/lub warstwie konsensusu (Łańcuch śledzący / walidator)._ diff --git a/public/content/translations/pl/developers/docs/nodes-and-clients/light-clients/index.md b/public/content/translations/pl/developers/docs/nodes-and-clients/light-clients/index.md new file mode 100644 index 00000000000..82b1d39b1a3 --- /dev/null +++ b/public/content/translations/pl/developers/docs/nodes-and-clients/light-clients/index.md @@ -0,0 +1,61 @@ +--- +title: Lekkie klienty +description: "Wprowadzenie do lekkich klientów Ethereum." +lang: pl +--- + +Uruchomienie pełnego węzła jest najbardziej prywatnym, zdecentralizowanym, odpornym na cenzurę oraz niewymagającym zaufania sposobem na interakcję z Ethereum. Z pełnym węzłem zachowujesz swoją własną kopię blockchainu, którą możesz natychmiastowo przeszukiwać oraz otrzymujesz bezpośredni dostęp do sieci peer-to-peer Ethereum. Uruchomienie pełnego węzła wymaga jednak dużych zasobów pamięci, przestrzeni oraz procesora. Oznacza to, że nie każdy może uruchomić swój własny węzeł. Istnieje wiele rozwiązań na to w planie działania Ethereum, wliczając w to bezstanowość, ale minie jeszcze kilka lat, zanim zostaną one zaimplementowane. Rozwiązaniem w najbliższym czasie jest kompromis między niektórymi korzyściami płynącymi z uruchomienia pełnego węzła, a dużą poprawą wydajności, która pozwala węzłom na działanie z bardzo niskimi wymaganiami sprzętowymi. Węzły, które zapewniają ten kompromis, znane są jako lekkie węzły. + +## Czym jest lekki klient? {#what-is-a-light-client} + +Lekki węzeł to węzeł działający z oprogramowaniem lekkiego klienta. Zamiast przechowywać lokalną kopię danych blockchainu i niezależnie weryfikować wszystkie zmiany, żądają niezbędnych danych od jakiegoś dostawcy. Dostawcą może być bezpośrednie połączenie do pełnego węzła lub za pośrednictwem jakiegoś scentralizowanego serwera RPC. Dane zostają następnie zweryfikowane przez lekki węzeł, pozwalając mu na nadążenie za początkiem łańcucha. Lekki węzeł przetwarza tylko nagłówki bloków, okazjonalnie pobierając rzeczywistą zawartość bloku. Węzły mogą się różnić swoją lekkością w zależności od kombinacji oprogramowania lekkiego i pełnego klienta, które uruchamiają. Na przykład najlżejszą konfiguracją byłoby uruchomienie lekkiego klienta wykonawczego i lekkiego klienta konsensusu. Prawdopodobne jest również to, że wiele węzłów zdecyduje się na uruchomienie lekkiego klienta konsensusu z pełnym klientem wykonawczym lub na odwrót. + +## Jak działają lekkie klienty? {#how-do-light-clients-work} + +Kiedy Ethereum zaczęło korzystać z mechanizmu konsensusu opartego na proof-of-stake, wprowadzona została nowa infrastruktura specjalnie do obsługi lekkich klientów. Sposób działania polega na losowym wybieraniu podzbioru 512 walidatorów co każde 1,1 dnia, aby pełnili funkcję **komitetu synchronizacji**. Komitet synchronizacji podpisuje nagłówki najnowszych bloków. Każdy nagłówek bloku zawiera zagregowany podpis walidatorów w komitecie synchronizacji oraz „pole bitowe”, które pokazuje, który walidator podpisał, a który nie. Każdy nagłówek zawiera również listę wszystkich walidatorów, od których oczekuje się podpisania następnego bloku. Oznacza to, że lekki klient może szybko zobaczyć czy komitet synchronizacji podpisał otrzymane dane, a także może sprawdzić, czy komitet synchronizacji jest prawdziwy, porównując ten, który otrzymał z tym którego się spodziewał w poprzednim bloku. W ten sposób lekki klient może ciągle aktualizować swoją wiedzę na temat najnowszego bloku Ethereum bez faktycznego pobierania samego bloku, tylko nagłówka zawierającego podsumowane informacje. + +W warstwie wykonawczej nie ma pojedynczej specyfikacji dla lekkiego klienta wykonawczego. Zakres lekkiego klienta wykonawczego może różnić się od „lekkiego trybu” pełnego klienta wykonawczego, który ma wszystkie funkcje EVM i sieciowe pełnego węzła, ale tylko weryfikuje nagłówki bloków bez pobierania powiązanych danych lub może to być bardziej okrojony klient, który w dużym stopniu opiera się na przekierowywaniu żądań do dostawcy RPC w celu interakcji z Ethereum. + +## Dlaczego lekkie klienty są ważne? {#why-are-light-clients-important} + +Lekkie klienty mają znaczenie, ponieważ pozwalają użytkownikom na weryfikowanie przychodzących danych, zamiast ufać na ślepo, że ich dostawca danych ma rację i jest uczciwy, wykorzystując małą cześć zasobów obliczeniowych pełnego węzła. Dane otrzymywane przez lekkie klienty mogą zostać sprawdzone pod kątem nagłówków bloków, o których wiadomo, że zostały podpisane przez co najmniej 2/3 losowego zbioru 512 walidatorów Ethereum. Jest to bardzo silny dowód na to, że dane są poprawne. + +Lekki klient wykorzystuje tylko małą ilość mocy obliczeniowej, pamięci oraz przestrzeni, więc może on zostać uruchomiony na telefonie, osadzony w aplikacji lub jako część przeglądarki. Lekkie klienty są sposobem na zminimalizowany pod względem zaufania dostęp do Ethereum w sposób tak samo bezproblemowy jak zaufanie dostawcy strony trzeciej. + +Rozważmy prosty przykład. Wyobraź sobie, że chcesz sprawdzić saldo swojego konta. Aby to zrobić, musisz wysłać żądanie do węzła Ethereum. Węzeł ten następnie sprawdzi swoją lokalną kopię stanu Ethereum pod kątem Twojego salda i Ci je zwróci. Jeśli nie masz bezpośredniego dostępu do węzła, to możesz skorzystać ze scentralizowanych operatorów, którzy dostarczą te dane w ramach usługi. Możesz wysłać do nich żądanie, oni sprawdzają swój węzeł, a następnie wysyłają wyniki do Ciebie. Problem z tym jest taki, że musisz zaufać dostawcy, że dostarcza Ci prawidłowe informacje. Nigdy nie możesz mieć pewności, że informacje są prawidłowe, jeśli ich samodzielnie nie możesz zweryfikować. + +Lekkie klienty rozwiązują ten problem. Wciąż wysyłasz żądanie danych do jakiegoś zewnętrznego dostawcy, ale kiedy otrzymujesz je z powrotem, są one dostarczane z dowodem, który Twój lekki węzeł może sprawdzić z informacjami, które otrzymał w nagłówku bloku. Oznacza to, że Ethereum weryfikuje poprawność Twoich danych, a nie jakiś zaufany operator. + +## Jakie innowacje umożliwiają lekkie klienty? {#what-innovations-do-light-clients-enable} + +Główną zaletą lekkich klientów jest umożliwienie większej ilości osób na niezależny dostęp do Ethereum przy znikomych wymaganiach sprzętowych oraz minimalnej zależności od stron trzecich. Jest to dobre dla użytkowników, ponieważ mogą weryfikować swoje własne dane, oraz jest to dobre dla sieci, ponieważ zwiększa to liczbę oraz różnorodność węzłów weryfikujących łańcuch. + +Możliwość uruchomienia węzłów Ethereum na urządzeniach z bardzo małą przestrzenią dyskową, pamięcią oraz mocą obliczeniową jest jednym z głównych obszarów innowacji umożliwionych przez lekkie klienty. Podczas gdy obecne węzły Ethereum wymagają dużych zasobów obliczeniowych, lekkie klienty mogłyby być osadzane w przeglądarkach, działać na telefonach, a może nawet na jeszcze mniejszych urządzeniach takich jak smartwatche. To oznacza, że portfele Ethereum ze wbudowanymi klientami mogłyby działać na telefonach. A to z kolei oznacza, że mobilne portfele mogłyby być bardziej zdecentralizowane, ponieważ nie musiałyby ufać scentralizowanym dostawcom danych odnośnie swoich danych. + +Rozszerzeniem tego jest umożliwienie urządzeń **internetu rzeczy (IoT)**. Lekki klient może zostać wykorzystany do szybkiego udowodnienia własności salda jakiegoś tokena lub NFT, ze wszystkimi gwarancjami bezpieczeństwa zapewnionymi przez komitety synchronizacji, wywołując pewne działanie w sieci IoT. Wyobraź sobie [wypożyczalnię rowerów](https://youtu.be/ZHNrAXf3RDE?t=929), która wykorzystuje aplikację z wbudowanym lekkim klientem do szybkiego zweryfikowania, czy jesteś właścicielem NFT wypożyczalni, a jeśli tak, odblokowuje rower, na którym możesz odjechać! + +Pakiety zbiorcze Ethereum również skorystałyby na lekkich klientach. Jednym z największych problemów związanym z pakietami zbiorczymi są włamania wymierzone w mosty, które pozwalają na transfer środków z sieci głównej Ethereum do pakietu zbiorczego. Jedną z luk w zabezpieczeniach są wyrocznie, których używają pakiety zbiorcze do wykrycia czy użytkownik dokonał wpłaty do mostu. Jeśli wyrocznia dostarczy złe dane, to mogłyby one oszukać pakiet zbiorczy do myślenia, że do mostu zostały wpłacone środki, co spowodowałoby nieprawidłowe wypłaty środków. Lekki klient wbudowany w pakiet zbiorczy mógłby zostać użyty do ochrony przed skorumpowanymi wyroczniami, ponieważ wpłata do mostu mogłaby przyjść z dowodem, który może zostać zweryfikowany przez pakiet zbiorczy przed wypłatą jakichkolwiek tokenów. Ta samo koncepcja mogłaby również zostać zastosowana w innych mostach międzyłańcuchowych. + +Lekkie klienty mogłyby również zostać wykorzystanie do ulepszenia portfeli Ethereum. Zamiast ufać danym dostarczonym od dostawcy RPC, Twój portfel mógłby bezpośrednio zweryfikować te dane, używając wbudowanego lekkiego klienta. Zwiększyłoby to bezpieczeństwo Twojego portfela. Jeśli dostawca RPC byłby nieuczciwy i dostarczył Ci nieprawidłowe dane, to wbudowany lekki klient by o tym powiedział! + +## Jaki jest obecny stan rozwoju lekkich klientów? {#current-state-of-development} + +Istnieje wiele lekkich klientów w fazie rozwoju, w tym lekkie klienty wykonawcze, konsensusu, a nawet oba na raz. Oto implementacje lekkich klientów, o których wiemy w czasie pisania tej strony: + +- [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): lekki klient konsensusu w języku TypeScript +- [Helios](https://github.com/a16z/helios): połączony lekki klient wykonawczy i konsensusu w języku Rust +- [Geth](https://github.com/ethereum/go-ethereum/tree/master/beacon/light): tryb lekki dla klienta wykonawczego (w fazie rozwoju) w języku Go +- [Nimbus](https://nimbus.guide/el-light-client.html): lekki klient konsensusu w języku Nim + +Z naszej wiedzy wynika, że żaden z tych nie jest jeszcze gotowy na poziomie produkcji. + +Prowadzonym jest również wiele prac nad ulepszeniem sposobów, w jakie lekkie klienty mogą mieć dostęp do danych Ethereum. Obecnie lekkie klienty opierają się na żądaniach RPC do pełnych węzłów przy użyciu modelu klient/serwer, ale w przyszłości dane mogłyby być żądane w bardziej zdecentralizowany sposób przy użyciu dedykowanej sieci, takiej jak [Portal Network](https://www.ethportal.net/), która mogłaby obsługiwać dane dla lekkich klientów za pomocą protokołu plotkarskiego peer-to-peer. + +Inne elementy [planu działania](/roadmap/) takie jak [drzewa Verkle](/roadmap/verkle-trees/) oraz [bezstanowość](/roadmap/statelessness/) ostatecznie zrównają gwarancje bezpieczeństwa lekkich klientów z gwarancjami pełnych klientów. + +## Dalsza lektura {#further-reading} + +- [Zsolt Felfodhi o lekkich klientach Geth](https://www.youtube.com/watch?v=EPZeFXau-RE) +- [Etan Kissling o sieciach lekkich klientów](https://www.youtube.com/watch?v=85MeiMA4dD8) +- [Etan Kissling o lekkich klientach po The Merge](https://www.youtube.com/watch?v=ZHNrAXf3RDE) +- [Piper Merriam: Kręta droga do funkcjonalnych lekkich klientów](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/)