From b3cff2c811c2994f1dfa8cc16df7ebdf1403c576 Mon Sep 17 00:00:00 2001
From: Joshua <62268199+minimalsm@users.noreply.github.com>
Date: Sat, 14 Feb 2026 00:08:10 +0000
Subject: [PATCH] i18n(pl): translation import part 09 of 13 (23 files)
---
.../index.md | 208 ++
.../tutorials/server-components/index.md | 295 +++
.../index.md | 92 +
.../developers/tutorials/short-abi/index.md | 585 +++++
.../index.md | 77 +-
.../tutorials/stealth-addr/index.md | 443 ++++
.../index.md | 142 +-
.../token-integration-checklist/index.md | 92 +-
.../index.md | 174 +-
.../index.md | 79 +-
.../uniswap-v2-annotated-code/index.md | 1970 +++++++++++++++++
.../tutorials/using-websockets/index.md | 80 +-
.../index.md | 141 +-
.../index.md | 204 ++
.../index.md | 199 ++
.../tutorials/yellow-paper-evm/index.md | 278 +++
public/content/translations/pl/eips/index.md | 37 +-
.../pl/energy-consumption/index.md | 59 +-
.../translations/pl/eth/supply/index.md | 80 +
.../translations/pl/ethereum-forks/index.md | 514 ++++-
.../translations/pl/foundation/index.md | 37 +-
.../content/translations/pl/gaming/index.md | 70 +
.../content/translations/pl/glossary/index.md | 755 ++-----
23 files changed, 5473 insertions(+), 1138 deletions(-)
create mode 100644 public/content/translations/pl/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
create mode 100644 public/content/translations/pl/developers/tutorials/server-components/index.md
create mode 100644 public/content/translations/pl/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
create mode 100644 public/content/translations/pl/developers/tutorials/short-abi/index.md
create mode 100644 public/content/translations/pl/developers/tutorials/stealth-addr/index.md
create mode 100644 public/content/translations/pl/developers/tutorials/uniswap-v2-annotated-code/index.md
create mode 100644 public/content/translations/pl/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
create mode 100644 public/content/translations/pl/developers/tutorials/waffle-test-simple-smart-contract/index.md
create mode 100644 public/content/translations/pl/developers/tutorials/yellow-paper-evm/index.md
create mode 100644 public/content/translations/pl/eth/supply/index.md
create mode 100644 public/content/translations/pl/gaming/index.md
diff --git a/public/content/translations/pl/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md b/public/content/translations/pl/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
new file mode 100644
index 00000000000..937eca077e6
--- /dev/null
+++ b/public/content/translations/pl/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
@@ -0,0 +1,208 @@
+---
+title: "Wysyłanie transakcji za pomocą Web3"
+description: "To jest przyjazny dla początkujących przewodnik po wysyłaniu transakcji Ethereum za pomocą Web3. Istnieją trzy główne kroki, aby wysłać transakcję do blockchaina Ethereum: tworzenie, podpisywanie i rozgłaszanie. Omówimy wszystkie trzy."
+author: "Elan Halpern"
+tags: [ "transakcje", "web3.js", "alchemy" ]
+skill: beginner
+lang: pl
+published: 2020-11-04
+source: Alchemy docs
+sourceUrl: https://www.alchemy.com/docs/how-to-send-transactions-on-ethereum
+---
+
+To jest przyjazny dla początkujących przewodnik po wysyłaniu transakcji Ethereum za pomocą Web3. Istnieją trzy główne kroki, aby wysłać transakcję do blockchaina Ethereum: tworzenie, podpisywanie i rozgłaszanie. Omówimy wszystkie trzy, mając nadzieję, że odpowiemy na wszelkie pytania, jakie możesz mieć! W tym samouczku będziemy używać [Alchemy](https://www.alchemy.com/), aby wysyłać nasze transakcje do łańcucha Ethereum. Możesz [utworzyć darmowe konto Alchemy tutaj](https://auth.alchemyapi.io/signup).
+
+**UWAGA:** Ten przewodnik dotyczy podpisywania transakcji w _backendzie_ aplikacji. Jeśli chcesz zintegrować podpisywanie transakcji we frontendzie, sprawdź integrację [Web3 z dostawcą przeglądarki](https://docs.alchemy.com/reference/api-overview#with-a-browser-provider).
+
+## Podstawy {#the-basics}
+
+Podobnie jak większość deweloperów blockchain na początku swojej drogi, być może szukałeś informacji o tym, jak wysłać transakcję (coś, co powinno być całkiem proste) i natknąłeś się na mnóstwo przewodników, z których każdy mówił co innego, co sprawiło, że czułeś się nieco przytłoczony i zdezorientowany. Jeśli jesteś w takiej sytuacji, nie martw się; wszyscy kiedyś byliśmy! Zanim więc zaczniemy, wyjaśnijmy sobie kilka kwestii:
+
+### 1. Alchemy nie przechowuje Twoich kluczy prywatnych {#alchemy-does-not-store-your-private-keys}
+
+- Oznacza to, że Alchemy nie może podpisywać i wysyłać transakcji w Twoim imieniu. Dzieje się tak ze względów bezpieczeństwa. Alchemy nigdy nie poprosi Cię o udostępnienie Twojego klucza prywatnego i nigdy nie powinieneś go udostępniać hostowanemu węzłowi (ani nikomu innemu).
+- Możesz odczytywać dane z blockchaina za pomocą podstawowego API Alchemy, ale aby do niego zapisywać, musisz użyć czegoś innego do podpisania swoich transakcji przed wysłaniem ich przez Alchemy (to samo dotyczy każdej innej [usługi węzłów](/developers/docs/nodes-and-clients/nodes-as-a-service/)).
+
+### 2. Czym jest „signer”? {#what-is-a-signer}
+
+- Signerzy podpisują dla Ciebie transakcje, używając Twojego klucza prywatnego. W tym samouczku do podpisania naszej transakcji użyjemy [Alchemy web3](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3), ale można również użyć dowolnej innej biblioteki web3.
+- We frontendzie dobrym przykładem signera jest [MetaMask](https://metamask.io/), który podpisuje i wysyła transakcje w Twoim imieniu.
+
+### 3. Dlaczego muszę podpisywać swoje transakcje? {#why-do-i-need-to-sign-my-transactions}
+
+- Każdy użytkownik, który chce wysłać transakcję w sieci Ethereum, musi ją podpisać (używając swojego klucza prywatnego), aby zweryfikować, że pochodzenie transakcji jest zgodne z deklarowanym.
+- Niezwykle ważne jest, aby chronić ten klucz prywatny, ponieważ posiadanie do niego dostępu daje pełną kontrolę nad kontem Ethereum, pozwalając Tobie (lub każdemu, kto ma dostęp) na wykonywanie transakcji w Twoim imieniu.
+
+### 4. Jak chronić mój klucz prywatny? {#how-do-i-protect-my-private-key}
+
+- Istnieje wiele sposobów na ochronę klucza prywatnego i używanie go do wysyłania transakcji. W tym samouczku będziemy używać pliku `.env`. Można jednak również skorzystać z osobnego dostawcy, który przechowuje klucze prywatne, użyć pliku keystore lub innych opcji.
+
+### 5. Jaka jest różnica między `eth_sendTransaction` a `eth_sendRawTransaction`? {#difference-between-send-and-send-raw}
+
+`eth_sendTransaction` i `eth_sendRawTransaction` to funkcje API Ethereum, które rozgłaszają transakcję w sieci Ethereum, aby została ona dodana do przyszłego bloku. Różnią się one sposobem obsługi podpisywania transakcji.
+
+- [`eth_sendTransaction`](https://docs.web3js.org/api/web3-eth/function/sendTransaction) służy do wysyłania _niepodpisanych_ transakcji, co oznacza, że węzeł, do którego je wysyłasz, musi zarządzać Twoim kluczem prywatnym, aby mógł podpisać transakcję przed jej rozgłoszeniem w łańcuchu. Ponieważ Alchemy nie przechowuje kluczy prywatnych użytkowników, nie obsługuje tej metody.
+- [`eth_sendRawTransaction`](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction) służy do rozgłaszania transakcji, które zostały już podpisane. Oznacza to, że najpierw musisz użyć [`signTransaction(tx, private_key)`](https://docs.web3js.org/api/web3-eth-accounts/function/signTransaction), a następnie przekazać wynik do `eth_sendRawTransaction`.
+
+Podczas korzystania z web3 dostęp do `eth_sendRawTransaction` uzyskuje się poprzez wywołanie funkcji [web3.eth.sendSignedTransaction](https://docs.web3js.org/api/web3-eth/function/sendSignedTransaction).
+
+Tego właśnie będziemy używać w tym samouczku.
+
+### 6. Czym jest biblioteka web3? {#what-is-the-web3-library}
+
+- Web3.js jest biblioteką opakowującą standardowe wywołania JSON-RPC, która jest dość często używana w deweloperce Ethereum.
+- Istnieje wiele bibliotek web3 dla różnych języków. W tym samouczku będziemy używać [Alchemy Web3](https://docs.alchemy.com/reference/api-overview), który jest napisany w języku JavaScript. Możesz sprawdzić inne opcje [tutaj](https://docs.alchemyapi.io/guides/getting-started#other-web3-libraries), takie jak [ethers.js](https://docs.ethers.org/v5/).
+
+OK, teraz, gdy odpowiedzieliśmy na kilka pytań, przejdźmy do samouczka. W każdej chwili możesz zadawać pytania na [discordzie](https://discord.gg/gWuC7zB) Alchemy!
+
+### 7. Jak wysyłać bezpieczne, zoptymalizowane pod kątem opłat za gaz i prywatne transakcje? {#how-to-send-secure-gas-optimized-and-private-transactions}
+
+- [Alchemy ma zestaw interfejsów API Transact](https://docs.alchemy.com/reference/transact-api-quickstart). Możesz ich używać do wysyłania wzmocnionych transakcji, symulowania transakcji przed ich wykonaniem, wysyłania transakcji prywatnych oraz wysyłania transakcji zoptymalizowanych pod względem opłat za gaz.
+- Możesz również użyć [API Notify](https://docs.alchemy.com/docs/alchemy-notify), aby otrzymywać powiadomienia, gdy Twoja transakcja zostanie pobrana z mempoola i dodana do łańcucha.
+
+**UWAGA:** Ten przewodnik wymaga posiadania konta Alchemy, adresu Ethereum lub portfela MetaMask oraz zainstalowanych NodeJs i npm. Jeśli nie, wykonaj następujące kroki:
+
+1. [Utwórz darmowe konto Alchemy](https://auth.alchemyapi.io/signup)
+2. [Utwórz konto MetaMask](https://metamask.io/) (lub uzyskaj adres Ethereum)
+3. [Wykonaj te kroki, aby zainstalować NodeJs i NPM](https://docs.alchemy.com/alchemy/guides/alchemy-for-macs)
+
+## Kroki wysyłania transakcji {#steps-to-sending-your-transaction}
+
+### 1. Utwórz aplikację Alchemy w sieci testowej Sepolia {#create-an-alchemy-app-on-the-sepolia-testnet}
+
+Przejdź do swojego [Panelu Alchemy](https://dashboard.alchemyapi.io/) i utwórz nową aplikację, wybierając Sepolia (lub dowolną inną sieć testową) jako swoją sieć.
+
+### 2. Poproś o ETH z kranu Sepolia {#request-eth-from-sepolia-faucet}
+
+Postępuj zgodnie z instrukcjami na stronie [kranu Sepolia od Alchemy](https://www.sepoliafaucet.com/), aby otrzymać ETH. Upewnij się, że podajesz swój adres Ethereum **Sepolia** (z MetaMask), a nie z innej sieci. Po wykonaniu instrukcji sprawdź, czy otrzymałeś ETH w swoim portfelu.
+
+### 3. Utwórz nowy katalog projektu i przejdź do niego za pomocą `cd` {#create-a-new-project-direction}
+
+Utwórz nowy katalog projektu z wiersza poleceń (terminal na komputerach Mac) i przejdź do niego:
+
+```
+mkdir sendtx-example
+cd sendtx-example
+```
+
+### 4. Zainstaluj Alchemy Web3 (lub dowolną bibliotekę web3) {#install-alchemy-web3}
+
+Uruchom następujące polecenie w katalogu projektu, aby zainstalować [Alchemy Web3](https://docs.alchemy.com/reference/api-overview):
+
+Uwaga, jeśli chcesz użyć biblioteki ethers.js, [postępuj zgodnie z instrukcjami podanymi tutaj](https://docs.alchemy.com/docs/how-to-send-transactions-on-ethereum).
+
+```
+npm install @alch/alchemy-web3
+```
+
+### 5. Zainstaluj dotenv {#install-dotenv}
+
+Użyjemy pliku `.env` do bezpiecznego przechowywania naszego klucza API i klucza prywatnego.
+
+```
+npm install dotenv --save
+```
+
+### 6. Utwórz plik `.env` {#create-the-dotenv-file}
+
+Utwórz plik `.env` w katalogu projektu i dodaj następującą treść (zastępując „`your-api-url`” i „`your-private-key`”):
+
+- Aby znaleźć adres URL interfejsu API Alchemy, przejdź do strony szczegółów aplikacji, którą właśnie utworzyłeś w panelu, kliknij „View Key” w prawym górnym rogu i pobierz adres URL HTTP.
+- Aby znaleźć swój klucz prywatny za pomocą MetaMask, zapoznaj się z tym [przewodnikiem](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key).
+
+```
+API_URL = "your-api-url"
+PRIVATE_KEY = "your-private-key"
+```
+
+
+
+
+Nie commituj pliku .env! Upewnij się, że nigdy nie udostępniasz ani nie ujawniasz nikomu swojego pliku .env, ponieważ w ten sposób narażasz swoje poufne dane. Jeśli używasz kontroli wersji, dodaj swój plik .env do pliku gitignore .
+
+
+
+
+### 7. Utwórz plik `sendTx.js` {#create-sendtx-js}
+
+Świetnie, teraz, gdy nasze poufne dane są chronione w pliku `.env`, zacznijmy kodować. W naszym przykładzie wysyłania transakcji będziemy odsyłać ETH z powrotem do kranu Sepolia.
+
+Utwórz plik `sendTx.js`, w którym skonfigurujemy i wyślemy naszą przykładową transakcję, i dodaj do niego następujące linie kodu:
+
+```
+async function main() {
+ require('dotenv').config();
+ const { API_URL, PRIVATE_KEY } = process.env;
+ const { createAlchemyWeb3 } = require("@alch/alchemy-web3");
+ const web3 = createAlchemyWeb3(API_URL);
+ const myAddress = '0x610Ae88399fc1687FA7530Aac28eC2539c7d6d63' //TODO: zastąp ten adres swoim własnym adresem publicznym
+
+ const nonce = await web3.eth.getTransactionCount(myAddress, 'latest'); // nonce zaczyna liczyć od 0
+
+ const transaction = {
+ 'to': '0x31B98D14007bDEe637298086988A0bBd31184523', // adres kranu, na który ma być zwrócony eth
+ 'value': 1000000000000000000, // 1 ETH
+ 'gas': 30000,
+ 'nonce': nonce,
+ // opcjonalne pole danych do wysłania wiadomości lub wykonania smart kontraktu
+ };
+
+ const signedTx = await web3.eth.accounts.signTransaction(transaction, PRIVATE_KEY);
+
+ web3.eth.sendSignedTransaction(signedTx.rawTransaction, function(error, hash) {
+ if (!error) {
+ console.log("🎉 Hasz Twojej transakcji to: ", hash, "\n Sprawdź Mempool Alchemy, aby zobaczyć status swojej transakcji!");
+ } else {
+ console.log("❗Coś poszło nie tak podczas przesyłania transakcji:", error)
+ }
+ });
+}
+
+main();
+```
+
+Pamiętaj, aby zastąpić adres w **wierszu 6** swoim własnym adresem publicznym.
+
+Zanim przejdziemy do uruchomienia tego kodu, omówmy kilka jego komponentów.
+
+- `nonce`: Specyfikacja nonce służy do śledzenia liczby transakcji wysłanych z Twojego adresu. Potrzebujemy tego ze względów bezpieczeństwa i aby zapobiegać [atakom typu replay](https://docs.alchemyapi.io/resources/blockchain-glossary#account-nonce). Aby uzyskać liczbę transakcji wysłanych z Twojego adresu, używamy [getTransactionCount](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_gettransactioncount).
+- `transaction`: Obiekt transakcji ma kilka aspektów, które musimy określić.
+ - `to`: Jest to adres, na który chcemy wysłać ETH. W tym przypadku odsyłamy ETH z powrotem do [kranu Sepolia](https://sepoliafaucet.com/), z którego pierwotnie je pozyskaliśmy.
+ - `value`: Jest to kwota, którą chcemy wysłać, określona w Wei, gdzie 10^18 Wei = 1 ETH.
+ - `gas`: Istnieje wiele sposobów na określenie odpowiedniej ilości gazu do uwzględnienia w transakcji. Alchemy ma nawet [webhook ceny gazu](https://docs.alchemyapi.io/guides/alchemy-notify#address-activity-1), który powiadamia, gdy cena gazu spadnie poniżej określonego progu. W przypadku transakcji w sieci głównej Mainnet dobrą praktyką jest sprawdzanie estymatora gazu, takiego jak [ETH Gas Station](https://ethgasstation.info/), w celu określenia właściwej ilości gazu do uwzględnienia. 21000 to minimalna ilość gazu, jaką zużyje operacja na Ethereum, więc aby zapewnić, że nasza transakcja zostanie wykonana, wpisujemy tutaj 30000.
+ - `nonce`: patrz definicja nonce powyżej. Nonce zaczyna liczyć od zera.
+ - [OPCJONALNE] dane: Służy do wysyłania dodatkowych informacji wraz z transferem lub wywoływania smart kontraktu. Nie jest wymagane w przypadku transferów salda. Sprawdź uwagę poniżej.
+- `signedTx`: Aby podpisać nasz obiekt transakcji, użyjemy metody `signTransaction` z naszym `PRIVATE_KEY`.
+- `sendSignedTransaction`: Gdy mamy już podpisaną transakcję, możemy ją wysłać, aby została uwzględniona w kolejnym bloku, używając `sendSignedTransaction`.
+
+**Uwaga na temat danych**
+Istnieją dwa główne typy transakcji, które można wysyłać w Ethereum.
+
+- Transfer salda: Wyślij ETH z jednego adresu na drugi. Pole danych nie jest wymagane, jednak jeśli chcesz wysłać dodatkowe informacje wraz z transakcją, możesz je umieścić w tym polu w formacie HEX.
+ - Załóżmy na przykład, że chcemy zapisać hasz dokumentu IPFS w łańcuchu Ethereum, aby nadać mu niezmienny znacznik czasu. Nasze pole danych powinno wtedy wyglądać następująco: `web3.utils.toHex(‘hasz IPFS‘)`. I teraz każdy może odpytać łańcuch i zobaczyć, kiedy ten dokument został dodany.
+- Transakcja smart kontraktu: wykonanie kodu smart kontraktu w łańcuchu. W tym przypadku pole danych powinno zawierać inteligentną funkcję, którą chcesz wykonać, wraz z wszelkimi parametrami.
+ - Praktyczny przykład znajdziesz w kroku 8 tego [samouczka „Witaj, świecie”](https://docs.alchemyapi.io/alchemy/tutorials/hello-world-smart-contract#step-8-create-the-transaction).
+
+### 8. Uruchom kod za pomocą `node sendTx.js` {#run-the-code-using-node-sendtx-js}
+
+Wróć do terminala lub wiersza poleceń i uruchom:
+
+```
+node sendTx.js
+```
+
+### 9. Zobacz swoją transakcję w Mempoolu {#see-your-transaction-in-the-mempool}
+
+Otwórz [stronę Mempool](https://dashboard.alchemyapi.io/mempool) w panelu Alchemy i filtruj według utworzonej aplikacji, aby znaleźć swoją transakcję. Tutaj możemy obserwować przejście naszej transakcji ze stanu oczekującego do stanu wydobycia (jeśli się powiedzie) lub do stanu porzucenia, jeśli się nie powiedzie. Upewnij się, że opcja jest ustawiona na „Wszystkie”, aby przechwycić transakcje „wydobyte”, „oczekujące” i „porzucone”. Możesz również wyszukać swoją transakcję, szukając transakcji wysłanych na adres `0x31b98d14007bdee637298086988a0bbd31184523`.
+
+Aby wyświetlić szczegóły transakcji po jej znalezieniu, wybierz jej hasz, co powinno przenieść Cię do widoku, który wygląda następująco:
+
+
+
+Stamtąd możesz wyświetlić swoją transakcję w Etherscan, klikając ikonę zaznaczoną na czerwono!
+
+**Huraaa! Właśnie wysłałeś swoją pierwszą transakcję Ethereum za pomocą Alchemy 🎉**
+
+_Aby uzyskać opinie i sugestie dotyczące tego przewodnika, wyślij wiadomość do Elan na [Discordzie](https://discord.gg/A39JVCM) Alchemy!_
+
+_Oryginalnie opublikowano na stronie [https://docs.alchemyapi.io/tutorials/sending-transactions-using-web3-and-alchemy](https://docs.alchemyapi.io/tutorials/sending-transactions-using-web3-and-alchemy)_
diff --git a/public/content/translations/pl/developers/tutorials/server-components/index.md b/public/content/translations/pl/developers/tutorials/server-components/index.md
new file mode 100644
index 00000000000..04495a4d439
--- /dev/null
+++ b/public/content/translations/pl/developers/tutorials/server-components/index.md
@@ -0,0 +1,295 @@
+---
+title: "Komponenty serwera i agenty dla aplikacji web3"
+description: "Po przeczytaniu tego samouczka będziesz w stanie pisać serwery TypeScript, które nasłuchują zdarzeń w łańcuchu bloków i odpowiednio na nie reagują własnymi transakcjami. Umożliwi to pisanie scentralizowanych aplikacji (ponieważ serwer jest pojedynczym punktem awarii), które mogą wchodzić w interakcje z jednostkami web3. Te same techniki mogą być również użyte do napisania agenta, który reaguje na zdarzenia onchain bez udziału człowieka."
+
+author: Ori Pomerantz
+lang: pl
+tags: [ "agent", "serwer", "offchain" ]
+skill: beginner
+published: 2024-07-15
+---
+
+## Wprowadzenie {#introduction}
+
+W większości przypadków zdecentralizowana aplikacja wykorzystuje serwer do dystrybucji oprogramowania, ale cała faktyczna interakcja zachodzi między klientem (zazwyczaj przeglądarką internetową) a łańcuchem bloków.
+
+
+
+Istnieją jednak przypadki, w których aplikacja odniosłaby korzyść z posiadania niezależnie działającego komponentu serwera. Taki serwer byłby w stanie reagować na zdarzenia i żądania pochodzące z innych źródeł, takich jak API, emitując transakcje.
+
+
+
+Istnieje kilka możliwych zadań, które taki serwer mógłby spełniać.
+
+- Posiadacz tajnego stanu. W grach często przydatne jest, aby nie wszystkie informacje znane grze były dostępne dla graczy. Jednakże _w łańcuchu bloków nie ma żadnych tajemnic_, każdą informację, która się w nim znajduje, każdy może łatwo poznać. Dlatego też, jeśli część stanu gry ma pozostać tajna, musi być przechowywana gdzie indziej (a ewentualne skutki tego stanu zweryfikowane za pomocą [dowodów o wiedzy zerowej](/zero-knowledge-proofs)).
+
+- Scentralizowana wyrocznia. Jeśli stawki są wystarczająco niskie, zewnętrzny serwer, który odczytuje pewne informacje online, a następnie publikuje je w łańcuchu, może być wystarczająco dobry, aby użyć go jako [wyroczni](/developers/docs/oracles/).
+
+- Agent. W łańcuchu bloków nic się nie dzieje bez transakcji, która to aktywuje. Serwer może działać w imieniu użytkownika, wykonując działania takie jak [arbitraż](/developers/docs/mev/#mev-examples-dex-arbitrage), gdy nadarzy się okazja.
+
+## Przykładowy program {#sample-program}
+
+Przykładowy serwer można zobaczyć [na GitHubie](https://github.com/qbzzt/20240715-server-component). Ten serwer nasłuchuje zdarzeń pochodzących z [tego kontraktu](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=contract_code), zmodyfikowanej wersji Greeter od Hardhat. Gdy powitanie zostanie zmienione, zmienia je z powrotem.
+
+Aby go uruchomić:
+
+1. Sklonuj repozytorium.
+
+ ```sh copy
+ git clone https://github.com/qbzzt/20240715-server-component.git
+ cd 20240715-server-component
+ ```
+
+2. Zainstaluj niezbędne pakiety. Jeśli jeszcze go nie masz, [najpierw zainstaluj Node](https://nodejs.org/en/download/package-manager).
+
+ ```sh copy
+ npm install
+ ```
+
+3. Edytuj plik `.env`, aby określić klucz prywatny konta, które posiada ETH w sieci testowej Holesky. Jeśli nie masz ETH na Holesky, możesz [użyć tego kraniku](https://holesky-faucet.pk910.de/).
+
+ ```sh filename=".env" copy
+ PRIVATE_KEY=0x
+ ```
+
+4. Uruchom serwer.
+
+ ```sh copy
+ npm start
+ ```
+
+5. Przejdź do [eksploratora bloków](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=write_contract) i używając innego adresu niż ten, który posiada klucz prywatny, zmodyfikuj powitanie. Zobacz, że powitanie jest automatycznie przywracane.
+
+### Jak to działa? {#how-it-works}
+
+Najłatwiejszym sposobem na zrozumienie, jak napisać komponent serwera, jest przeanalizowanie przykładu linijka po linijce.
+
+#### `src/app.ts` {#src-app-ts}
+
+Zdecydowana większość programu znajduje się w [`src/app.ts`](https://github.com/qbzzt/20240715-server-component/blob/main/src/app.ts).
+
+##### Tworzenie wymaganych obiektów
+
+```typescript
+import {
+ createPublicClient,
+ createWalletClient,
+ getContract,
+ http,
+ Address,
+} from "viem"
+```
+
+Są to potrzebne nam encje [Viem](https://viem.sh/), funkcje i [typ `Address`](https://viem.sh/docs/glossary/types#address). Ten serwer jest napisany w języku [TypeScript](https://www.typescriptlang.org/), który jest rozszerzeniem języka JavaScript, czyniącym go [silnie typowanym](https://en.wikipedia.org/wiki/Strong_and_weak_typing).
+
+```typescript
+import { privateKeyToAccount } from "viem/accounts"
+```
+
+[Ta funkcja](https://viem.sh/docs/accounts/privateKey) pozwala nam wygenerować informacje o portfelu, w tym adres, odpowiadające kluczowi prywatnemu.
+
+```typescript
+import { holesky } from "viem/chains"
+```
+
+Aby używać blockchaina w Viem, musisz zaimportować jego definicję. W tym przypadku chcemy połączyć się z testowym łańcuchem bloków [Holesky](https://github.com/eth-clients/holesky).
+
+```typescript
+// W ten sposób dodajemy definicje z .env do process.env.
+import * as dotenv from "dotenv"
+dotenv.config()
+```
+
+W ten sposób wczytujemy plik `.env` do środowiska. Potrzebujemy go do klucza prywatnego (zobacz później).
+
+```typescript
+const greeterAddress : Address = "0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6"
+const greeterABI = [
+ {
+ "inputs": [
+ {
+ "internalType": "string",
+ "name": "_greeting",
+ "type": "string"
+ }
+ ],
+ "stateMutability": "nonpayable",
+ "type": "constructor"
+ },
+ .
+ .
+ .
+ {
+ "inputs": [
+ {
+ "internalType": "string",
+ "name": "_greeting",
+ "type": "string"
+ }
+ ],
+ "name": "setGreeting",
+ "outputs": [],
+ "stateMutability": "nonpayable",
+ "type": "function"
+ }
+] as const
+```
+
+Aby użyć kontraktu, potrzebujemy jego adresu i [ABI](/glossary/#abi). Podajemy oba tutaj.
+
+W języku JavaScript (a więc i w TypeScript) nie można przypisać nowej wartości do stałej, ale _można_ zmodyfikować obiekt, który jest w niej przechowywany. Używając sufiksu `as const`, informujemy TypeScript, że sama lista jest stała i nie może być zmieniana.
+
+```typescript
+const publicClient = createPublicClient({
+ chain: holesky,
+ transport: http(),
+})
+```
+
+Utwórz [klienta publicznego](https://viem.sh/docs/clients/public.html) Viem. Klienci publiczni nie mają dołączonego klucza prywatnego, a zatem nie mogą wysyłać transakcji. Mogą wywoływać [`funkcje widoku`](https://www.tutorialspoint.com/solidity/solidity_view_functions.htm), odczytywać salda kont itp.
+
+```typescript
+const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`)
+```
+
+Zmienne środowiskowe są dostępne w [`process.env`](https://www.totaltypescript.com/how-to-strongly-type-process-env). Jednak TypeScript jest silnie typowany. Zmienna środowiskowa może być dowolnym ciągiem znaków lub być pusta, więc typem zmiennej środowiskowej jest `string | undefined`. Jednak klucz jest zdefiniowany w Viem jako `0x${string}` (`0x` po którym następuje ciąg znaków). W tym miejscu informujemy TypeScript, że zmienna środowiskowa `PRIVATE_KEY` będzie tego typu. Jeśli tak nie będzie, otrzymamy błąd wykonania.
+
+Funkcja [`privateKeyToAccount`](https://viem.sh/docs/accounts/privateKey) następnie używa tego klucza prywatnego do utworzenia pełnego obiektu konta.
+
+```typescript
+const walletClient = createWalletClient({
+ account,
+ chain: holesky,
+ transport: http(),
+})
+```
+
+Następnie używamy obiektu konta do utworzenia [klienta portfela](https://viem.sh/docs/clients/wallet). Ten klient ma klucz prywatny i adres, więc może być używany do wysyłania transakcji.
+
+```typescript
+const greeter = getContract({
+ address: greeterAddress,
+ abi: greeterABI,
+ client: { public: publicClient, wallet: walletClient },
+})
+```
+
+Teraz, gdy mamy już wszystkie wymagania wstępne, możemy wreszcie utworzyć [instancję kontraktu](https://viem.sh/docs/contract/getContract). Będziemy używać tej instancji kontraktu do komunikacji z kontraktem onchain.
+
+##### Odczytywanie z łańcucha bloków
+
+```typescript
+console.log(`Current greeting:`, await greeter.read.greet())
+```
+
+Funkcje kontraktu, które są tylko do odczytu ([`view`](https://www.tutorialspoint.com/solidity/solidity_view_functions.htm) i [`pure`](https://www.tutorialspoint.com/solidity/solidity_pure_functions.htm)), są dostępne w `read`. W tym przypadku używamy jej do uzyskania dostępu do funkcji [`greet`](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=read_contract#cfae3217), która zwraca powitanie.
+
+JavaScript jest jednowątkowy, więc gdy uruchamiamy długo działający proces, musimy [określić, że robimy to asynchronicznie](https://eloquentjavascript.net/11_async.html#h-XvLsfAhtsE). Wywołanie łańcucha bloków, nawet w przypadku operacji tylko do odczytu, wymaga komunikacji w obie strony między komputerem a węzłem łańcucha bloków. Dlatego w tym miejscu określamy, że kod musi `await` (oczekiwać) na wynik.
+
+Jeśli interesuje Cię, jak to działa, możesz [przeczytać o tym tutaj](https://www.w3schools.com/js/js_promise.asp), ale w praktyce wystarczy wiedzieć, że należy `await` (oczekiwać) na wyniki, jeśli rozpoczynasz operację, która trwa długo, a każda funkcja, która to robi, musi być zadeklarowana jako `async`.
+
+##### Emitowanie transakcji
+
+```typescript
+const setGreeting = async (greeting: string): Promise => {
+```
+
+Jest to funkcja, którą wywołujesz, aby wysłać transakcję zmieniającą powitanie. Ponieważ jest to długa operacja, funkcja jest zadeklarowana jako `async`. Ze względu na wewnętrzną implementację, każda funkcja `async` musi zwracać obiekt `Promise`. W tym przypadku `Promise` oznacza, że nie określamy, co dokładnie zostanie zwrócone w `Promise`.
+
+```typescript
+const txHash = await greeter.write.setGreeting([greeting])
+```
+
+Pole `write` instancji kontraktu zawiera wszystkie funkcje, które zapisują do stanu łańcucha bloków (te, które wymagają wysłania transakcji), takie jak [`setGreeting`](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=write_contract#a4136862). Parametry, jeśli istnieją, są podawane w postaci listy, a funkcja zwraca hasz transakcji.
+
+```typescript
+ console.log(`Pracuję nad poprawką, zobacz https://eth-holesky.blockscout.com/tx/${txHash}`)
+
+ return txHash
+}
+```
+
+Zgłoś hasz transakcji (jako część adresu URL do eksploratora bloków, aby go wyświetlić) i zwróć go.
+
+##### Reagowanie na zdarzenia
+
+```typescript
+greeter.watchEvent.SetGreeting({
+```
+
+[Funkcja `watchEvent`](https://viem.sh/docs/actions/public/watchEvent) pozwala określić, że funkcja ma być uruchamiana po wyemitowaniu zdarzenia. Jeśli interesuje Cię tylko jeden typ zdarzenia (w tym przypadku `SetGreeting`), możesz użyć tej składni, aby ograniczyć się do tego typu zdarzenia.
+
+```typescript
+ onLogs: logs => {
+```
+
+Funkcja `onLogs` jest wywoływana, gdy pojawiają się wpisy w dzienniku. W Ethereum „log” i „zdarzenie” są zwykle używane zamiennie.
+
+```typescript
+console.log(
+ `Adres ${logs[0].args.sender} zmienił powitanie na ${logs[0].args.greeting}`
+)
+```
+
+Może być wiele zdarzeń, ale dla uproszczenia interesuje nas tylko pierwsze z nich. `logs[0].args` to argumenty zdarzenia, w tym przypadku `sender` i `greeting`.
+
+```typescript
+ if (logs[0].args.sender != account.address)
+ setGreeting(`${account.address} nalega, aby było to Hello!`)
+ }
+})
+```
+
+Jeśli nadawcą _nie jest_ ten serwer, użyj `setGreeting`, aby zmienić powitanie.
+
+#### `package.json` {#package-json}
+
+[Ten plik](https://github.com/qbzzt/20240715-server-component/blob/main/package.json) kontroluje konfigurację [Node.js](https://nodejs.org/en). W tym artykule wyjaśniono tylko ważne definicje.
+
+```json
+{
+ "main": "dist/index.js",
+```
+
+Ta definicja określa, który plik JavaScript ma być uruchomiony.
+
+```json
+ "scripts": {
+ "start": "tsc && node dist/app.js",
+ },
+```
+
+Skrypty to różne działania aplikacji. W tym przypadku jedynym, jaki mamy, jest `start`, który kompiluje, a następnie uruchamia serwer. Polecenie `tsc` jest częścią pakietu `typescript` i kompiluje TypeScript do JavaScript. Jeśli chcesz uruchomić go ręcznie, znajduje się on w `node_modules/.bin`. Drugie polecenie uruchamia serwer.
+
+```json
+ "type": "module",
+```
+
+Istnieje wiele typów aplikacji węzła JavaScript. Typ `module` pozwala nam na użycie `await` w kodzie najwyższego poziomu, co jest ważne, gdy wykonujesz wolne (i asynchroniczne) operacje.
+
+```json
+ "devDependencies": {
+ "@types/node": "^20.14.2",
+ "typescript": "^5.4.5"
+ },
+```
+
+Są to pakiety, które są wymagane tylko do programowania. W tym miejscu potrzebujemy `typescript`, a ponieważ używamy go z Node.js, otrzymujemy również typy dla zmiennych i obiektów węzła, takich jak `process`. [Notacja `^`](https://github.com/npm/node-semver?tab=readme-ov-file#caret-ranges-123-025-004) oznacza tę wersję lub wyższą wersję, która nie zawiera przełomowych zmian. Więcej informacji na temat znaczenia numerów wersji można znaleźć [tutaj](https://semver.org).
+
+```json
+ "dependencies": {
+ "dotenv": "^16.4.5",
+ "viem": "2.14.1"
+ }
+}
+```
+
+Są to pakiety wymagane w czasie wykonywania, podczas uruchamiania `dist/app.js`.
+
+## Wnioski {#conclusion}
+
+Scentralizowany serwer, który tu stworzyliśmy, wykonuje swoje zadanie, którym jest działanie jako agent dla użytkownika. Każdy, kto chce, aby dapka nadal funkcjonowała i jest gotów wydać gaz, może uruchomić nową instancję serwera z własnym adresem.
+
+Działa to jednak tylko wtedy, gdy działania scentralizowanego serwera można łatwo zweryfikować. Jeśli scentralizowany serwer ma jakiekolwiek informacje o tajnym stanie lub wykonuje trudne obliczenia, jest to scentralizowany podmiot, któremu trzeba zaufać, aby korzystać z aplikacji, a tego właśnie starają się unikać łańcuchy bloków. W przyszłym artykule planuję pokazać, jak używać [dowodów o wiedzy zerowej](/zero-knowledge-proofs), aby obejść ten problem.
+
+[Zobacz więcej mojej pracy tutaj](https://cryptodocguy.pro/).
diff --git a/public/content/translations/pl/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md b/public/content/translations/pl/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
new file mode 100644
index 00000000000..59f07059bd1
--- /dev/null
+++ b/public/content/translations/pl/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
@@ -0,0 +1,92 @@
+---
+title: "Skonfiguruj web3.js do używania blockchainu Ethereum w JavaScript"
+description: "Dowiedz się, jak skonfigurować bibliotekę web3.js do interakcji z blockchainem Ethereum z aplikacji JavaScript."
+author: "jdourlens"
+tags: [ "web3.js", "JavaScript" ]
+skill: beginner
+lang: pl
+published: 2020-04-11
+source: EthereumDev
+sourceUrl: https://ethereumdev.io/setup-web3js-to-use-the-ethereum-blockchain-in-javascript/
+address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
+---
+
+W tym samouczku zobaczymy, jak zacząć z [web3.js](https://web3js.readthedocs.io/), aby wejść w interakcję z blockchainem Ethereum. Web3.js może być używany zarówno we frontendach, jak i backendach do odczytywania danych z blockchaina, dokonywania transakcji, a nawet wdrażania smart kontraktów.
+
+Pierwszym krokiem jest dołączenie web3.js do Twojego projektu. Aby użyć go na stronie internetowej, możesz zaimportować bibliotekę bezpośrednio za pomocą CDN, takiego jak JSDeliver.
+
+```html
+
+```
+
+Jeśli wolisz zainstalować bibliotekę do użycia w backendzie lub w projekcie frontendowym, który używa kompilacji, możesz ją zainstalować za pomocą npm:
+
+```bash
+npm install web3 --save
+```
+
+Następnie, aby zaimportować Web3.js do skryptu Node.js lub projektu frontendowego Browserify, możesz użyć następującej linii JavaScriptu:
+
+```js
+const Web3 = require("web3")
+```
+
+Teraz, gdy dołączyliśmy bibliotekę do projektu, musimy ją zainicjować. Twój projekt musi być w stanie komunikować się z blockchainem. Większość bibliotek Ethereum komunikuje się z [węzłem](/developers/docs/nodes-and-clients/) poprzez wywołania RPC. Aby zainicjować naszego dostawcę Web3, utworzymy instancję Web3, przekazując jako konstruktor adres URL dostawcy. Jeśli masz węzeł lub [instancję ganache działającą na twoim komputerze](https://ethereumdev.io/testing-your-smart-contract-with-existing-protocols-ganache-fork/), będzie to wyglądać tak:
+
+```js
+const web3 = new Web3("http://localhost:8545")
+```
+
+Jeśli chcesz uzyskać bezpośredni dostęp do hostowanego węzła, możesz znaleźć opcje w [węzłach jako usłudze](/developers/docs/nodes-and-clients/nodes-as-a-service).
+
+```js
+const web3 = new Web3("https://cloudflare-eth.com")
+```
+
+Aby przetestować, czy poprawnie skonfigurowaliśmy naszą instancję Web3, spróbujemy pobrać najnowszy numer bloku za pomocą funkcji `getBlockNumber`. Ta funkcja akceptuje callback jako parametr i zwraca numer bloku jako liczbę całkowitą.
+
+```js
+var Web3 = require("web3")
+const web3 = new Web3("https://cloudflare-eth.com")
+
+web3.eth.getBlockNumber(function (error, result) {
+ console.log(result)
+})
+```
+
+Jeśli wykonasz ten program, po prostu wydrukuje on najnowszy numer bloku: szczyt blockchainu. Możesz również użyć wywołań funkcji `await/async`, aby uniknąć zagnieżdżania wywołań zwrotnych w swoim kodzie:
+
+```js
+async function getBlockNumber() {
+ const latestBlockNumber = await web3.eth.getBlockNumber()
+ console.log(latestBlockNumber)
+ return latestBlockNumber
+}
+
+getBlockNumber()
+```
+
+Możesz zobaczyć wszystkie dostępne funkcje w instancji Web3 w [oficjalnej dokumentacji web3.js](https://docs.web3js.org/).
+
+Większość bibliotek Web3 jest asynchroniczna, ponieważ w tle biblioteka wykonuje wywołania JSON-RPC do węzła, który odsyła wynik.
+
+`txdatazero` ).
+- **Ilość**: Jeśli założymy, że w tym kontrakcie `decimals` wynosi osiemnaście (normalna wartość), a maksymalna ilość tokenów, które transferujemy, wyniesie 1018 , otrzymamy maksymalną ilość 1036 .
+ 25615 > 1036 , więc piętnaście bajtów wystarczy.
+
+Strata 160 gazu na L1 jest normalnie znikoma. Transakcja kosztuje co najmniej [21 000 gazu](https://yakkomajuri.medium.com/blockchain-definition-of-the-week-ethereum-gas-2f976af774ed), więc dodatkowe 0,8% nie ma znaczenia.
+Jednak na L2 sprawy mają się inaczej. Prawie cały koszt transakcji to zapisanie jej na L1.
+Oprócz calldata transakcji, istnieje 109 bajtów nagłówka transakcji (adres docelowy, podpis itp.).
+Całkowity koszt wynosi zatem `109*16+576+160=2480`, a my marnujemy około 6,5% tej kwoty.
+
+## Redukcja kosztów, gdy nie kontrolujesz kontraktu docelowego {#reducing-costs-when-you-dont-control-the-destination}
+
+Zakładając, że nie masz kontroli nad kontraktem docelowym, nadal możesz użyć rozwiązania podobnego do [tego](https://github.com/qbzzt/ethereum.org-20220330-shortABI).
+Przejdźmy do odpowiednich plików.
+
+### Token.sol {#token-sol}
+
+[To jest kontrakt docelowy](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/Token.sol).
+Jest to standardowy kontrakt ERC-20, z jedną dodatkową funkcją.
+Ta funkcja `faucet` pozwala każdemu użytkownikowi otrzymać trochę tokenów do wykorzystania.
+Uczyniłoby to produkcyjny kontrakt ERC-20 bezużytecznym, ale ułatwia życie, gdy ERC-20 istnieje tylko w celu ułatwienia testowania.
+
+```solidity
+ /**
+ * @dev Daje wywołującemu 1000 tokenów do zabawy
+ */
+ function faucet() external {
+ _mint(msg.sender, 1000);
+ } // function faucet
+```
+
+### CalldataInterpreter.sol {#calldatainterpreter-sol}
+
+[To jest kontrakt, który transakcje mają wywoływać z krótszymi calldata](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/CalldataInterpreter.sol).
+Przejdźmy przez niego linia po linii.
+
+```solidity
+//SPDX-License-Identifier: Unlicense
+pragma solidity ^0.8.0;
+
+
+import { OrisUselessToken } from "./Token.sol";
+```
+
+Potrzebujemy interfejsu kontraktu tokena, aby wiedzieć, jak go wywoływać.
+
+```solidity
+contract CalldataInterpreter {
+
+ OrisUselessToken public immutable token;
+```
+
+Adres tokena, dla którego jesteśmy proxy.
+
+```solidity
+
+ /**
+ * @dev Określ adres tokena
+ * @param tokenAddr_ adres kontraktu ERC-20
+ */
+ constructor(
+ address tokenAddr_
+ ) {
+ token = OrisUselessToken(tokenAddr_);
+ } // constructor
+```
+
+Adres tokena jest jedynym parametrem, który musimy określić.
+
+```solidity
+ function calldataVal(uint startByte, uint length)
+ private pure returns (uint) {
+```
+
+Odczytaj wartość z calldata.
+
+```solidity
+ uint _retVal;
+
+ require(length < 0x21,
+ "calldataVal limit długości to 32 bajty");
+
+ require(length + startByte <= msg.data.length,
+ "calldataVal próbuje czytać poza calldatasize");
+```
+
+Zamierzamy załadować do pamięci pojedyncze 32-bajtowe (256-bitowe) słowo i usunąć bajty, które nie są częścią pola, które nas interesuje.
+Ten algorytm nie działa dla wartości dłuższych niż 32 bajty i oczywiście nie możemy czytać poza końcem calldata.
+Na L1 może być konieczne pominięcie tych testów w celu zaoszczędzenia na gazie, ale na L2 gaz jest niezwykle tani, co umożliwia wszelkie testy poprawności, jakie możemy sobie wyobrazić.
+
+```solidity
+ assembly {
+ _retVal := calldataload(startByte)
+ }
+```
+
+Moglibyśmy skopiować dane z wywołania do `fallback()` (patrz niżej), ale łatwiej jest użyć [Yul](https://docs.soliditylang.org/en/v0.8.12/yul.html), języka asemblera EVM.
+
+Tutaj używamy [opcodu CALLDATALOAD](https://www.evm.codes/#35), aby odczytać bajty od `startByte` do `startByte+31` na stos.
+Ogólnie rzecz biorąc, składnia opcodu w Yul to `(, ...).
+
+```solidity
+
+ _retVal = _retVal >> (256-length*8);
+```
+
+Tylko najbardziej znaczące bajty o długości `length` są częścią pola, więc wykonujemy [przesunięcie w prawo](https://en.wikipedia.org/wiki/Logical_shift), aby pozbyć się pozostałych wartości.
+Ma to dodatkową zaletę, że przenosi wartość na prawo od pola, więc jest to sama wartość, a nie wartość pomnożona przez 256coś .
+
+```solidity
+
+ return _retVal;
+ }
+
+
+ fallback() external {
+```
+
+Gdy wywołanie do kontraktu Solidity nie pasuje do żadnej z sygnatur funkcji, wywołuje [funkcję `fallback()`](https://docs.soliditylang.org/en/v0.8.12/contracts.html#fallback-function) (zakładając, że taka istnieje).
+W przypadku `CalldataInterpreter` _każde_ wywołanie trafia tutaj, ponieważ nie ma innych funkcji `external` ani `public`.
+
+```solidity
+ uint _func;
+
+ _func = calldataVal(0, 1);
+```
+
+Odczytaj pierwszy bajt calldata, który informuje nas o funkcji.
+Istnieją dwa powody, dla których funkcja nie byłaby tutaj dostępna:
+
+1. Funkcje, które są `pure` lub `view`, nie zmieniają stanu i nie kosztują gazu (gdy są wywoływane poza łańcuchem).
+ Nie ma sensu próbować zmniejszać ich kosztu gazu.
+2. Funkcje, które opierają się na [`msg.sender`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#block-and-transaction-properties).
+ Wartością `msg.sender` będzie adres `CalldataInterpreter`, a nie adres wywołującego.
+
+Niestety, [patrząc na specyfikacje ERC-20](https://eips.ethereum.org/EIPS/eip-20), pozostaje tylko jedna funkcja, `transfer`.
+Pozostawia to nam tylko dwie funkcje: `transfer` (ponieważ możemy wywołać `transferFrom`) i `faucet` (ponieważ możemy przelać tokeny z powrotem do tego, kto nas wywołał).
+
+```solidity
+
+ // Wywołaj metody zmieniające stan tokena, używając
+ // informacji z calldata
+
+ // faucet
+ if (_func == 1) {
+```
+
+Wywołanie `faucet()`, które nie ma parametrów.
+
+```solidity
+ token.faucet();
+ token.transfer(msg.sender,
+ token.balanceOf(address(this)));
+ }
+```
+
+Po wywołaniu `token.faucet()` otrzymujemy tokeny. Jednak jako kontrakt proxy **nie potrzebujemy** tokenów.
+Potrzebuje ich EOA (konto należące do podmiotu zewnętrznego) lub kontrakt, który nas wywołał.
+Więc transferujemy wszystkie nasze tokeny do tego, kto nas wywołał.
+
+```solidity
+ // transfer (zakładamy, że mamy na to zgodę)
+ if (_func == 2) {
+```
+
+Przesyłanie tokenów wymaga dwóch parametrów: adresu docelowego i kwoty.
+
+```solidity
+ token.transferFrom(
+ msg.sender,
+```
+
+Zezwalamy wywołującym tylko na transfer posiadanych przez nich tokenów
+
+```solidity
+ address(uint160(calldataVal(1, 20))),
+```
+
+Adres docelowy zaczyna się od bajtu nr 1 (bajt nr 0 to funkcja).
+Jako adres, ma długość 20 bajtów.
+
+```solidity
+ calldataVal(21, 2)
+```
+
+W przypadku tego konkretnego kontraktu zakładamy, że maksymalna liczba tokenów, jaką ktokolwiek chciałby przenieść, mieści się w dwóch bajtach (mniej niż 65536).
+
+```solidity
+ );
+ }
+```
+
+Ogólnie rzecz biorąc, transfer zajmuje 35 bajtów calldata:
+
+| Sekcja | Długość | Bajty |
+| ---------------- | ------: | ----: |
+| Selektor funkcji | 1 | 0 |
+| Adres docelowy | 32 | 1-32 |
+| Kwota | 2 | 33-34 |
+
+```solidity
+ } // fallback
+
+} // kontrakt CalldataInterpreter
+```
+
+### test.js {#test-js}
+
+[Ten test jednostkowy JavaScript](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/test/test.js) pokazuje, jak używać tego mechanizmu (i jak zweryfikować jego prawidłowe działanie).
+Zakładam, że rozumiesz [chai](https://www.chaijs.com/) i [ethers](https://docs.ethers.io/v5/) i wyjaśniam tylko te części, które dotyczą konkretnie kontraktu.
+
+```js
+const { expect } = require("chai");
+
+describe("CalldataInterpreter", function () {
+ it("Powinien pozwolić nam używać tokenów", async function () {
+ const Token = await ethers.getContractFactory("OrisUselessToken")
+ const token = await Token.deploy()
+ await token.deployed()
+ console.log("Adres tokena:", token.address)
+
+ const Cdi = await ethers.getContractFactory("CalldataInterpreter")
+ const cdi = await Cdi.deploy(token.address)
+ await cdi.deployed()
+ console.log("Adres CalldataInterpreter:", cdi.address)
+
+ const signer = await ethers.getSigner()
+```
+
+Zaczynamy od wdrożenia obu kontraktów.
+
+```javascript
+ // Pobierz tokeny do zabawy
+ const faucetTx = {
+```
+
+Nie możemy używać funkcji wysokiego poziomu, których normalnie byśmy użyli (takich jak `token.faucet()`) do tworzenia transakcji, ponieważ nie przestrzegamy ABI.
+Zamiast tego musimy sami zbudować transakcję, a następnie ją wysłać.
+
+```javascript
+ to: cdi.address,
+ data: "0x01"
+```
+
+Istnieją dwa parametry, które musimy podać dla transakcji:
+
+1. `to`, adres docelowy.
+ To jest kontrakt interpretera calldata.
+2. `data`, calldata do wysłania.
+ W przypadku wywołania `faucet`, danymi jest pojedynczy bajt, `0x01`.
+
+```javascript
+
+ }
+ await (await signer.sendTransaction(faucetTx)).wait()
+```
+
+Wywołujemy [metodę `sendTransaction` sygnatariusza](https://docs.ethers.io/v5/api/signer/#Signer-sendTransaction), ponieważ już określiliśmy miejsce docelowe (`faucetTx.to`) i potrzebujemy, aby transakcja została podpisana.
+
+```javascript
+// Sprawdź, czy faucet poprawnie dostarcza tokeny
+expect(await token.balanceOf(signer.address)).to.equal(1000)
+```
+
+Tutaj weryfikujemy saldo.
+Nie ma potrzeby oszczędzania gazu na funkcjach `view`, więc po prostu uruchamiamy je normalnie.
+
+```javascript
+// Daj CDI upoważnienie (zatwierdzenia nie mogą być przekazywane przez proxy)
+const approveTX = await token.approve(cdi.address, 10000)
+await approveTX.wait()
+expect(await token.allowance(signer.address, cdi.address)).to.equal(10000)
+```
+
+Daj interpreterowi calldata upoważnienie do wykonywania transferów.
+
+```javascript
+// Transfer tokenów
+const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d"
+const transferTx = {
+ to: cdi.address,
+ data: "0x02" + destAddr.slice(2, 42) + "0100",
+}
+```
+
+Utwórz transakcję transferu. Pierwszy bajt to „0x02”, po nim następuje adres docelowy, a na końcu kwota (0x0100, co w systemie dziesiętnym daje 256).
+
+```javascript
+ await (await signer.sendTransaction(transferTx)).wait()
+
+ // Sprawdź, czy mamy o 256 tokenów mniej
+ expect (await token.balanceOf(signer.address)).to.equal(1000-256)
+
+ // I czy nasz cel je otrzymał
+ expect (await token.balanceOf(destAddr)).to.equal(256)
+ }) // it
+}) // describe
+```
+
+## Zmniejszenie kosztów, gdy kontrolujesz kontrakt docelowy {#reducing-the-cost-when-you-do-control-the-destination-contract}
+
+Jeśli masz kontrolę nad kontraktem docelowym, możesz tworzyć funkcje, które omijają sprawdzanie `msg.sender`, ponieważ ufają interpreterowi calldata.
+[Przykład działania można zobaczyć tutaj, w gałęzi `control-contract`](https://github.com/qbzzt/ethereum.org-20220330-shortABI/tree/control-contract).
+
+Gdyby kontrakt odpowiadał tylko na transakcje zewnętrzne, moglibyśmy sobie poradzić z jednym kontraktem.
+Jednakże, złamałoby to [kompozycyjność](/developers/docs/smart-contracts/composability/).
+O wiele lepiej jest mieć kontrakt, który odpowiada na normalne wywołania ERC-20, i inny kontrakt, który odpowiada na transakcje z krótkimi danymi wywołania.
+
+### Token.sol {#token-sol-2}
+
+W tym przykładzie możemy zmodyfikować `Token.sol`.
+Pozwala to na posiadanie wielu funkcji, które może wywoływać tylko proxy.
+Oto nowe części:
+
+```solidity
+ // Jedyny adres uprawniony do określenia adresu CalldataInterpreter
+ address owner;
+
+ // Adres CalldataInterpreter
+ address proxy = address(0);
+```
+
+Kontrakt ERC-20 musi znać tożsamość autoryzowanego proxy.
+Nie możemy jednak ustawić tej zmiennej w konstruktorze, ponieważ nie znamy jeszcze jej wartości.
+Ten kontrakt jest tworzony jako pierwszy, ponieważ proxy oczekuje adresu tokena w swoim konstruktorze.
+
+```solidity
+ /**
+ * @dev Wywołuje konstruktor ERC20.
+ */
+ constructor(
+ ) ERC20("Oris useless token-2", "OUT-2") {
+ owner = msg.sender;
+ }
+```
+
+Adres twórcy (o nazwie `owner`) jest tutaj przechowywany, ponieważ jest to jedyny adres uprawniony do ustawienia proxy.
+
+```solidity
+ /**
+ * @dev Ustawia adres dla proxy (CalldataInterpreter).
+ * Może być wywołane tylko raz przez właściciela
+ */
+ function setProxy(address _proxy) external {
+ require(msg.sender == owner, "Może być wywołane tylko przez właściciela");
+ require(proxy == address(0), "Proxy jest już ustawione");
+
+ proxy = _proxy;
+ } // funkcja setProxy
+```
+
+Proxy ma uprzywilejowany dostęp, ponieważ może omijać kontrole bezpieczeństwa.
+Aby upewnić się, że możemy zaufać proxy, pozwalamy tylko `owner` na wywołanie tej funkcji, i to tylko raz.
+Gdy `proxy` ma rzeczywistą wartość (niezerową), wartość ta nie może ulec zmianie, więc nawet jeśli właściciel zdecyduje się zbuntować lub jego mnemonik zostanie ujawniony, nadal jesteśmy bezpieczni.
+
+```solidity
+ /**
+ * @dev Niektóre funkcje mogą być wywoływane tylko przez proxy.
+ */
+ modifier onlyProxy {
+```
+
+Jest to [funkcja `modifier`](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm), która modyfikuje działanie innych funkcji.
+
+```solidity
+ require(msg.sender == proxy);
+```
+
+Najpierw zweryfikuj, czy zostaliśmy wywołani przez proxy i nikogo innego.
+Jeśli nie, `revert`.
+
+```solidity
+ _;
+ }
+```
+
+Jeśli tak, uruchom funkcję, którą modyfikujemy.
+
+```solidity
+ /* Funkcje, które pozwalają proxy na faktyczne pośredniczenie dla kont */
+
+ function transferProxy(address from, address to, uint256 amount)
+ public virtual onlyProxy() returns (bool)
+ {
+ _transfer(from, to, amount);
+ return true;
+ }
+
+ function approveProxy(address from, address spender, uint256 amount)
+ public virtual onlyProxy() returns (bool)
+ {
+ _approve(from, spender, amount);
+ return true;
+ }
+
+ function transferFromProxy(
+ address spender,
+ address from,
+ address to,
+ uint256 amount
+ ) public virtual onlyProxy() returns (bool)
+ {
+ _spendAllowance(from, spender, amount);
+ _transfer(from, to, amount);
+ return true;
+ }
+```
+
+Są to trzy operacje, które normalnie wymagają, aby wiadomość pochodziła bezpośrednio od podmiotu transferującego tokeny lub zatwierdzającego upoważnienie.
+Tutaj mamy wersję proxy tych operacji, która:
+
+1. Jest modyfikowana przez `onlyProxy()`, więc nikt inny nie może ich kontrolować.
+2. Otrzymuje adres, który normalnie byłby `msg.sender` jako dodatkowy parametr.
+
+### CalldataInterpreter.sol {#calldatainterpreter-sol-2}
+
+Interpreter calldata jest prawie identyczny z powyższym, z wyjątkiem tego, że funkcje przekazywane przez proxy otrzymują parametr `msg.sender` i nie ma potrzeby posiadania upoważnienia do `transferu`.
+
+```solidity
+ // transfer (nie ma potrzeby posiadania upoważnienia)
+ if (_func == 2) {
+ token.transferProxy(
+ msg.sender,
+ address(uint160(calldataVal(1, 20))),
+ calldataVal(21, 2)
+ );
+ }
+
+ // zatwierdzenie
+ if (_func == 3) {
+ token.approveProxy(
+ msg.sender,
+ address(uint160(calldataVal(1, 20))),
+ calldataVal(21, 2)
+ );
+ }
+
+ // transferFrom
+ if (_func == 4) {
+ token.transferFromProxy(
+ msg.sender,
+ address(uint160(calldataVal( 1, 20))),
+ address(uint160(calldataVal(21, 20))),
+ calldataVal(41, 2)
+ );
+ }
+```
+
+### Test.js {#test-js-2}
+
+Jest kilka zmian między poprzednim kodem testującym a tym.
+
+```js
+const Cdi = await ethers.getContractFactory("CalldataInterpreter")
+const cdi = await Cdi.deploy(token.address)
+await cdi.deployed()
+await token.setProxy(cdi.address)
+```
+
+Musimy poinformować kontrakt ERC-20, któremu proxy ma ufać
+
+```js
+console.log("Adres CalldataInterpreter:", cdi.address)
+
+// Potrzebujemy dwóch sygnatariuszy do weryfikacji upoważnień
+const signers = await ethers.getSigners()
+const signer = signers[0]
+const poorSigner = signers[1]
+```
+
+Aby sprawdzić `approve()` i `transferFrom()`, potrzebujemy drugiego sygnatariusza.
+Nazywamy go `poorSigner`, ponieważ nie dostaje żadnych naszych tokenów (musi mieć oczywiście ETH).
+
+```js
+// Transfer tokenów
+const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d"
+const transferTx = {
+ to: cdi.address,
+ data: "0x02" + destAddr.slice(2, 42) + "0100",
+}
+await (await signer.sendTransaction(transferTx)).wait()
+```
+
+Ponieważ kontrakt ERC-20 ufa proxy (`cdi`), nie potrzebujemy upoważnienia do przekazywania transferów.
+
+```js
+// zatwierdzenie i transferFrom
+const approveTx = {
+ to: cdi.address,
+ data: "0x03" + poorSigner.address.slice(2, 42) + "00FF",
+}
+await (await signer.sendTransaction(approveTx)).wait()
+
+const destAddr2 = "0xE1165C689C0c3e9642cA7606F5287e708d846206"
+
+const transferFromTx = {
+ to: cdi.address,
+ data: "0x04" + signer.address.slice(2, 42) + destAddr2.slice(2, 42) + "00FF",
+}
+await (await poorSigner.sendTransaction(transferFromTx)).wait()
+
+// Sprawdź, czy kombinacja zatwierdzenia / transferFrom została wykonana poprawnie
+expect(await token.balanceOf(destAddr2)).to.equal(255)
+```
+
+Przetestuj dwie nowe funkcje.
+Zauważ, że `transferFromTx` wymaga dwóch parametrów adresu: dającego upoważnienie i odbiorcy.
+
+## Wnioski {#conclusion}
+
+Zarówno [Optimism](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92), jak i [Arbitrum](https://developer.offchainlabs.com/docs/special_features) szukają sposobów na zmniejszenie rozmiaru calldata zapisywanych w L1, a tym samym kosztów transakcji.
+Jednak jako dostawcy infrastruktury poszukujący ogólnych rozwiązań, nasze możliwości są ograniczone.
+Jako deweloper dApp, masz wiedzę specyficzną dla aplikacji, co pozwala na znacznie lepszą optymalizację calldata, niż moglibyśmy to zrobić w rozwiązaniu ogólnym.
+Mamy nadzieję, że ten artykuł pomoże Ci znaleźć idealne rozwiązanie dla Twoich potrzeb.
+
+[Zobacz więcej mojej pracy tutaj](https://cryptodocguy.pro/).
+
diff --git a/public/content/translations/pl/developers/tutorials/smart-contract-security-guidelines/index.md b/public/content/translations/pl/developers/tutorials/smart-contract-security-guidelines/index.md
index 62eec372652..f0d3396026b 100644
--- a/public/content/translations/pl/developers/tutorials/smart-contract-security-guidelines/index.md
+++ b/public/content/translations/pl/developers/tutorials/smart-contract-security-guidelines/index.md
@@ -1,21 +1,18 @@
---
-title: Wskazówki dotyczące bezpieczeństwa kontraktów inteligentnych
-description: Lista kontrolna wytycznych bezpieczeństwa do rozważenia podczas tworzenia aplikacji zdecentralizowanych
+title: "Wskazówki dotyczące bezpieczeństwa kontraktów inteligentnych"
+description: "Lista kontrolna wytycznych bezpieczeństwa do rozważenia podczas tworzenia aplikacji zdecentralizowanych"
author: "Trailofbits"
-tags:
- - "solidity"
- - "inteligentne kontrakty"
- - "ochrona"
+tags: [ "solidity", "smart kontrakty", "bezpieczeństwo" ]
skill: intermediate
lang: pl
published: 2020-09-06
-source: Tworzenie bezpiecznych kontraktów
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md
---
Postępuj zgodnie z tymi ogólnymi zaleceniami, aby tworzyć bezpieczniejsze inteligentne kontrakty.
-## Wytyczne dotyczące projektowania {#design-guidelines}
+## Wytyczne projektowe {#design-guidelines}
Projekt kontraktu powinien być omówiony z wyprzedzeniem, przed napisaniem jakiejkolwiek linijki kodu.
@@ -23,72 +20,72 @@ Projekt kontraktu powinien być omówiony z wyprzedzeniem, przed napisaniem jaki
Dokumentacja może być pisana na różnych poziomach i powinna być aktualizowana w trakcie realizacji umów:
-- **Prosty opis systemu w języku angielskim**, przedstawiający działanie kontraktów i wszelkie założenia dotyczące bazy kodu.
-- **Diagramy schematów i architektury**, w tym interakcje kontraktów i maszyna stanu systemu. [Drukarki Slither](https://github.com/crytic/slither/wiki/Printer-documentation) mogą pomóc w wygenerowaniu tych schematów.
-- **Dokładna dokumentacja kodu**, [format Natspec](https://solidity.readthedocs.io/en/develop/natspec-format.html) może być używany do Solidity.
+- **Prosty opis systemu w języku angielskim**, opisujący działanie kontraktów i wszelkie założenia dotyczące bazy kodu.
+- **Schematy i diagramy architektury**, w tym interakcje kontraktów i maszyna stanu systemu. [Slither printers](https://github.com/crytic/slither/wiki/Printer-documentation) mogą pomóc w generowaniu tych schematów.
+- **Dokładna dokumentacja kodu**, dla Solidity można użyć [formatu Natspec](https://docs.soliditylang.org/en/develop/natspec-format.html).
-### Obliczenia on-chain vs off-chain {#on-chain-vs-off-chain-computation}
+### Obliczenia on-chain a off-chain {#onchain-vs-offchain-computation}
-- **Zachowaj jak najwięcej kodu off-chain.** Zatrzymaj niewielką warstwę on-chain. Wstępnie przetwarzaj dane z kodem off-chain w taki sposób, aby weryfikacja on-chain była prosta. Potrzebujesz uporządkowanej listy? Posortuj listę off-chain, a następnie sprawdź tylko jej kolejność on-chain.
+- **Jak najwięcej kodu trzymaj off-chain.** Utrzymuj jak najmniejszą warstwę on-chain. Wstępnie przetwarzaj dane za pomocą kodu off-chain w taki sposób, aby weryfikacja on-chain była prosta. Potrzebujesz uporządkowanej listy? Posortuj listę off-chain, a następnie sprawdź tylko jej kolejność on-chain.
-### Możliwość uaktualnienia {#upgradeability}
+### Możliwość aktualizacji {#upgradeability}
-Omówiliśmy różne rozwiązania dotyczące możliwości uaktualnień w [poście na blogu](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/). Dokonaj rozważnego wyboru, czy wspierać możliwość uaktualniania, czy nie, przed napisaniem jakiegokolwiek kodu. Decyzja wpłynie na sposób, w jaki ustrukturyzujesz kod. Generalnie zalecamy:
+Omówiliśmy różne rozwiązania dotyczące możliwości aktualizacji w [naszym wpisie na blogu](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/). Dokonaj rozważnego wyboru, czy wspierać możliwość uaktualniania, czy nie, przed napisaniem jakiegokolwiek kodu. Decyzja wpłynie na to, jak ustrukturyzujesz swój kod. Generalnie zalecamy:
-- **Przedkładanie [migracji kontraktu](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) nad możliwość uaktualnienia.** System migracji ma wiele takich samych zalet, jak możliwość uaktualnienia, bez ich wad.
-- **Używanie wzorca separacji danych zamiast wzorca delegatecalproxy.** Jeśli projekt ma wyraźną separację abstrakcji, możliwość uaktualnienia przy użyciu separacji danych będzie wymagać tylko kilku dostosowań. Delegatecallproxy wymaga wiedzy specjalistycznej o EVM i jest wysoce podatny na błędy.
-- **Dokumentowanie procedury migracji/uaktualnienia przed wdrożeniem.** Jeśli będziesz musiał reagować w stresie bez żadnych wytycznych, popełnisz błędy. Zapisz procedurę do wykonania z wyprzedzeniem. Powinna ona obejmować:
+- **Preferowanie [migracji kontraktów](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) zamiast możliwości aktualizacji.** Systemy migracji mają wiele tych samych zalet co systemy z możliwością aktualizacji, a przy tym są pozbawione ich wad.
+- **Stosowanie wzorca separacji danych zamiast wzorca delegatecallproxy.** Jeśli Twój projekt ma wyraźną separację abstrakcji, możliwość aktualizacji z wykorzystaniem separacji danych będzie wymagać tylko kilku dostosowań. Delegatecallproxy wymaga wiedzy specjalistycznej o EVM i jest wysoce podatny na błędy.
+- **Udokumentuj procedurę migracji/aktualizacji przed wdrożeniem.** Jeśli będziesz musiał(a) reagować w stresie bez żadnych wytycznych, popełnisz błędy. Zapisz procedurę do wykonania z wyprzedzeniem. Powinna ona obejmować:
- Wywołania inicjujące nowe kontrakty
- Gdzie są przechowywane klucze i jak uzyskać dostęp do nich
- Jak sprawdzić wdrożenie! Opracowanie i przetestowanie skryptu po wdrożeniu.
-## Wytyczne dotyczące wdrażania {#implementation-guidelines}
+## Wytyczne dotyczące implementacji {#implementation-guidelines}
-**Poszukaj prostoty.** Zawsze używaj najprostszego rozwiązania, które pasuje do Twojego celu. Każdy członek twojego zespołu powinien być w stanie zrozumieć Twoje rozwiązanie.
+**Dąż do prostoty.** Zawsze używaj najprostszego rozwiązania, które odpowiada Twoim celom. Każdy członek twojego zespołu powinien być w stanie zrozumieć Twoje rozwiązanie.
-### Skład funkcji {#function-composition}
+### Składanie funkcji {#function-composition}
Architektura Twojej bazy kodu powinna ułatwić sprawdzenie twojego kodu. Unikaj wyborów architektonicznych, które zmniejszają zdolność rozumowania o jego poprawności.
-- **Podziel logikę swojego systemu** poprzez wiele umów lub grupowanie podobnych funkcji (na przykład uwierzytelniające, arytmetyczne, ...).
-- **Pisz małe funkcje o wyraźnym celu celu.** To ułatwi sprawdzenie i umożliwi testowanie poszczególnych komponentów.
+- **Podziel logikę swojego systemu** na wiele kontraktów lub grupuj podobne funkcje (np. uwierzytelnianie, arytmetyka itp.).
+- **Pisz małe funkcje o jasno określonym celu.** Ułatwi to przegląd i pozwoli na testowanie poszczególnych komponentów.
### Dziedziczenie {#inheritance}
-- **Zachowaj dziedziczenie do zarządzania.** Dziedzictwo powinno być używane do dzielenia logiki, jednak Twój projekt powinien mieć na celu zminimalizowanie głębokości i szerokości drzewa dziedziczenia.
-- **Użyj [drukarki dziedziczenia Slither'a](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph), aby sprawdzić hierarchię kontraktów.** Drukarka dziedziczenia pomoże Ci sprawdzić rozmiar hierarchii.
+- **Utrzymuj dziedziczenie na łatwym do zarządzania poziomie.** Dziedziczenie powinno służyć do podziału logiki, jednak projekt powinien dążyć do zminimalizowania głębokości i szerokości drzewa dziedziczenia.
+- **Użyj [inheritance printer](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph) Slithera, aby sprawdzić hierarchię kontraktów.** Narzędzie to pomoże Ci przeanalizować rozmiar hierarchii.
### Zdarzenia {#events}
-- **Rejestruj wszystkie kluczowe operacje.** Zdarzenia pomogą debugować kontrakt podczas jego oprawcowywania i będą go monitorować po wdrożeniu.
+- **Rejestruj wszystkie kluczowe operacje.** Zdarzenia pomogą w debugowaniu kontraktu podczas jego tworzenia i monitorowaniu go po wdrożeniu.
-### Unikanie znanych pułapek {#avoid-known-pitfalls}
+### Unikaj znanych pułapek {#avoid-known-pitfalls}
-- **Bądź świadomy najczęstszych problemów z bezpieczeństwem.** Istnieje wiele zasobów online do poznania wspólnych problemów, takich jak [Ethernaut CTF](https://ethernaut.openzeppelin.com/), [Zajmij Ether](https://capturetheether.com/)lub [Nie tak inteligentne kontrakty](https://github.com/crytic/not-so-smart-contracts/).
-- **Zwróć uwagę na sekcje ostrzeżeń w [dokumentacji Solidity](https://solidity.readthedocs.io/en/latest/).** Sekcje z ostrzeżeniami poinformują Cię o nieoczywistym zachowaniu języka.
+- **Bądź świadomy(-a) najczęstszych problemów z bezpieczeństwem.** Istnieje wiele zasobów online, z których można dowiedzieć się o powszechnych problemach, takich jak [Ethernaut CTF](https://ethernaut.openzeppelin.com/), [Capture the Ether](https://capturetheether.com/) lub [Not so smart contracts](https://github.com/crytic/not-so-smart-contracts/).
+- **Zwróć uwagę na sekcje z ostrzeżeniami w [dokumentacji Solidity](https://docs.soliditylang.org/en/latest/).** Sekcje z ostrzeżeniami poinformują Cię o nieoczywistym zachowaniu języka.
### Zależności {#dependencies}
- **Używaj dobrze przetestowanych bibliotek.** Importowanie kodu z dobrze przetestowanych bibliotek zmniejszy prawdopodobieństwo, że napiszesz kod z błędami. Jeśli chcesz napisać kontrakt ERC20, użyj [OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20).
-- **Użyj menedżera zależności; unikaj kopiowania kodu.** Jeśli opierasz się na źródle zewnętrznym, musisz na bieżąco aktualizować je w stosunku do źródła oryginalnego.
+- **Używaj menedżera zależności; unikaj kopiowania kodu.** Jeśli polegasz na zewnętrznym źródle, musisz je na bieżąco aktualizować zgodnie z oryginalnym źródłem.
-### Testy i weryfikacja {#testing-and-verification}
+### Testowanie i weryfikacja {#testing-and-verification}
-- **Zapisz dokładne testy jednostkowe.** Rozległy zestaw testowy ma kluczowe znaczenie dla budowy oprogramowania wysokiej jakości.
-- **Napisz niestandardowe kontrole i właściwości dla narzędzi [Slither](https://github.com/crytic/slither), [Echidna](https://github.com/crytic/echidna) i [Manticore](https://github.com/trailofbits/manticore).** Automatyczne narzędzia pomogą zapewnić bezpieczeństwo umowy. Przejrzyj resztę tego przewodnika, aby dowiedzieć się, jak pisać skuteczne kontrole i właściwości.
-- **Użyj [crytic.io](https://crytic.io/).** Crytic integruje się z Githubem, zapewnia dostęp do prywatnych detektorów Slither, i uruchamia niestandardowe kontrole właściwości z Echidny.
+- **Pisz dokładne testy jednostkowe.** Rozbudowany pakiet testów ma kluczowe znaczenie dla tworzenia oprogramowania wysokiej jakości.
+- **Pisz niestandardowe testy i właściwości dla narzędzi [Slither](https://github.com/crytic/slither), [Echidna](https://github.com/crytic/echidna) i [Manticore](https://github.com/trailofbits/manticore).** Zautomatyzowane narzędzia pomogą zapewnić bezpieczeństwo Twojego kontraktu. Przejrzyj resztę tego przewodnika, aby dowiedzieć się, jak pisać skuteczne kontrole i właściwości.
+- **Użyj [crytic.io](https://crytic.io/).** Crytic integruje się z GitHubem, zapewnia dostęp do prywatnych detektorów Slither i uruchamia niestandardowe testy właściwości z Echidny.
### Solidity {#solidity}
-- **Favor Solidity 0.5 ponad 0.4 i 0.6.** Naszym zdaniem Solidity 0.5 jest bezpieczniejszy i ma lepsze wbudowane praktyki niż 0.4. Solidity 0.6 okazała się zbyt niestabilna do produkcji i wymaga czasu, aby dojrzeć.
-- **Użyj stabilnej wersji do kompilacji; użyj najnowszej wersji, aby sprawdzić ostrzeżenia.** Sprawdź, czy Twój kod nie ma zgłoszonych problemów z najnowszą wersją kompilatora. Solidity ma jednak szybki cykl wydawniczy i ma historię błędów kompilatora, więc nie zalecamy wdrażania najnowszej wersji (zobacz [zalecenie wersji Solc](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33)).
-- **Nie używaj wbudowanego asemblera.** Asemblacja wymaga wiedzy fachowej na temat EVM. Nie pisz kodu EVM, jeśli nie _opanowałeś_ żółtej księgi.
+- **Preferuj Solidity 0.5 zamiast 0.4 i 0.6.** Naszym zdaniem Solidity 0.5 jest bezpieczniejszy i ma lepsze wbudowane praktyki niż 0.4. Solidity 0.6 okazała się zbyt niestabilna do produkcji i wymaga czasu, aby dojrzeć.
+- **Użyj stabilnej wersji do kompilacji; użyj najnowszej wersji, aby sprawdzić ostrzeżenia.** Sprawdź, czy Twój kod nie ma zgłoszonych problemów z najnowszą wersją kompilatora. Jednakże Solidity ma szybki cykl wydawniczy i historię błędów kompilatora, dlatego nie zalecamy najnowszej wersji do wdrożenia (zobacz [rekomendację wersji solc od Slithera](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33)).
+- **Nie używaj asemblera wstawkowego.** Używanie asemblera wymaga specjalistycznej wiedzy na temat EVM. Nie pisz kodu EVM, jeśli nie _opanowałeś(-aś)_ do perfekcji żółtej księgi.
## Wytyczne dotyczące wdrażania {#deployment-guidelines}
Po opracowaniu i wdrożeniu kontraktu:
-- **Monitoruj swoje kontrakty.** Obserwuj dzienniki i bądź gotowy do reagowania w przypadku naruszenia kontraktu lub portfela.
-- **Dodaj swoje dane kontaktowe do [blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts).** Ta lista pomaga firmom zewnętrznym skontaktować się z Tobą w przypadku wykrycia luki w zabezpieczeniach.
+- **Monitoruj swoje kontrakty.** Obserwuj logi i bądź gotów(-owa) do reakcji w przypadku naruszenia bezpieczeństwa kontraktu lub portfela.
+- **Dodaj swoje dane kontaktowe do [blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts).** Ta lista pomaga stronom trzecim skontaktować się z Tobą w przypadku odkrycia luki w zabezpieczeniach.
- **Zabezpiecz portfele uprzywilejowanych użytkowników.** Postępuj zgodnie z naszymi [najlepszymi praktykami](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/), jeśli przechowujesz klucze w portfelach sprzętowych.
-- **Opracuj plan reakcji na incydent.** Weź pod uwagę, że Twoje inteligentne kontrakty mogą zostać naruszone. Nawet jeśli twoje kontrakty są wolne od błędów, atakujący może przejąć kontrolę nad kluczami właściciela umowy.
+- **Opracuj plan reakcji na incydenty.** Weź pod uwagę, że Twoje inteligentne kontrakty mogą zostać naruszone. Nawet jeśli twoje kontrakty są wolne od błędów, atakujący może przejąć kontrolę nad kluczami właściciela umowy.
diff --git a/public/content/translations/pl/developers/tutorials/stealth-addr/index.md b/public/content/translations/pl/developers/tutorials/stealth-addr/index.md
new file mode 100644
index 00000000000..7b341dc5cf0
--- /dev/null
+++ b/public/content/translations/pl/developers/tutorials/stealth-addr/index.md
@@ -0,0 +1,443 @@
+---
+title: "Korzystanie z ukrytych adresów"
+description: "Ukryte adresy pozwalają użytkownikom na anonimowe przesyłanie aktywów. Po przeczytaniu tego artykułu będziesz w stanie: wyjaśnić, czym są ukryte adresy i jak działają, zrozumieć, jak używać ukrytych adresów w sposób zachowujący anonimowość, oraz napisać aplikację internetową, która używa ukrytych adresów."
+author: Ori Pomerantz
+tags:
+ [
+ "Ukryty adres",
+ "prywatność",
+ "kryptografia",
+ "rust",
+ "wasm"
+ ]
+skill: intermediate
+published: 2025-11-30
+lang: pl
+sidebarDepth: 3
+---
+
+Jesteś Billem. Z powodów, których nie będziemy tu omawiać, chcesz przekazać darowiznę na kampanię „Alicja na królową świata” i chcesz, aby Alicja wiedziała, że to Ty przekazałeś darowiznę, aby mogła Cię nagrodzić, jeśli wygra. Niestety, jej zwycięstwo nie jest gwarantowane. Istnieje konkurencyjna kampania „Karolina na cesarzową Układu Słonecznego”. Jeśli Karolina wygra i dowie się, że wsparłeś Alicję, będziesz w kłopotach. Więc nie możesz po prostu przelać 200 ETH ze swojego konta na konto Alicji.
+
+Rozwiązaniem jest [ERC-5564](https://eips.ethereum.org/EIPS/eip-5564). Ten ERC wyjaśnia, jak używać [ukrytych adresów](https://nerolation.github.io/stealth-utils) do anonimowych transferów.
+
+**Ostrzeżenie**: Kryptografia stojąca za ukrytymi adresami jest, o ile nam wiadomo, solidna. Istnieją jednak potencjalne ataki typu side-channel. [Poniżej](#go-wrong) zobaczysz, co możesz zrobić, aby zmniejszyć to ryzyko.
+
+## Jak działają ukryte adresy {#how}
+
+Ten artykuł spróbuje wyjaśnić działanie ukrytych adresów na dwa sposoby. Pierwszy to [jak z nich korzystać](#how-use). Ta część jest wystarczająca do zrozumienia reszty artykułu. Następnie znajduje się [wyjaśnienie matematyki stojącej za tym mechanizmem](#how-math). Jeśli interesujesz się kryptografią, przeczytaj również tę część.
+
+### Wersja prosta (jak używać ukrytych adresów) {#how-use}
+
+Alicja tworzy dwa klucze prywatne i publikuje odpowiadające im klucze publiczne (które można połączyć w jeden meta-adres o podwójnej długości). Bill również tworzy klucz prywatny i publikuje odpowiadający mu klucz publiczny.
+
+Używając klucza publicznego jednej strony i klucza prywatnego drugiej, można uzyskać wspólny sekret znany tylko Alicji i Billowi (nie można go uzyskać z samych kluczy publicznych). Używając tego wspólnego sekretu, Bill uzyskuje ukryty adres i może na niego wysyłać aktywa.
+
+Alicja również uzyskuje adres ze wspólnego sekretu, ale ponieważ zna klucze prywatne do opublikowanych przez siebie kluczy publicznych, może również uzyskać klucz prywatny, który pozwala jej wypłacić środki z tego adresu.
+
+### Matematyka (dlaczego ukryte adresy działają w ten sposób) {#how-math}
+
+Standardowe ukryte adresy używają [kryptografii krzywych eliptycznych (ECC)](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/#elliptic-curves-building-blocks-of-a-better-trapdoor), aby uzyskać lepszą wydajność przy mniejszej liczbie bitów klucza, zachowując jednocześnie ten sam poziom bezpieczeństwa. Jednak w większości możemy to zignorować i udawać, że używamy zwykłej arytmetyki.
+
+Istnieje liczba, którą wszyscy znają, _G_. Można mnożyć przez _G_. Ale ze względu na naturę ECC, praktycznie niemożliwe jest dzielenie przez _G_. Sposób, w jaki ogólnie działa kryptografia klucza publicznego w Ethereum, polega na tym, że można użyć klucza prywatnego, _Ppriv _, do podpisywania transakcji, które są następnie weryfikowane przez klucz publiczny, _Ppub = GPpriv _.
+
+Alicja tworzy dwa klucze prywatne, _Kpriv _ i _Vpriv _. _Kpriv _ będzie używany do wydawania pieniędzy z ukrytego adresu, a _Vpriv _ do przeglądania adresów należących do Alicji. Alicja następnie publikuje klucze publiczne: _Kpub = GKpriv _ i _Vpub = GVpriv _
+
+Bill tworzy trzeci klucz prywatny, _Rpriv _, i publikuje _Rpub = GRpriv _ w centralnym rejestrze (Bill mógłby również wysłać go do Alicji, ale zakładamy, że Karolina podsłuchuje).
+
+Bill oblicza _Rpriv Vpub = GRpriv Vpriv _, co, jak oczekuje, Alicja również zna (wyjaśniono poniżej). Ta wartość nazywana jest _S_, wspólnym sekretem. Daje to Billowi klucz publiczny, _Ppub = Kpub +G\*hasz(S)_. Na podstawie tego klucza publicznego może obliczyć adres i wysłać na niego dowolne zasoby. W przyszłości, jeśli Alicja wygra, Bill może podać jej _Rpriv _, aby udowodnić, że zasoby pochodzą od niego.
+
+Alicja oblicza _Rpub Vpriv = GRpriv Vpriv _. Daje jej to ten sam wspólny sekret, _S_. Ponieważ zna klucz prywatny, _Kpriv _, może obliczyć _Ppriv = Kpriv +hasz(S)_. Ten klucz pozwala jej na dostęp do aktywów pod adresem wynikającym z _Ppub = GPpriv = GKpriv +G\*hasz(S) = Kpub +G\*hasz(S)_.
+
+Mamy oddzielny klucz do przeglądania, aby umożliwić Alicji zlecenie usług firmie Dave's World Domination Campaign Services. Alicja jest skłonna pozwolić Dave'owi poznać adresy publiczne i informować ją, gdy dostępne będą kolejne pieniądze, ale nie chce, aby wydawał on pieniądze z jej kampanii.
+
+Ponieważ przeglądanie i wydawanie używają oddzielnych kluczy, Alicja może dać Dave'owi _Vpriv _. Wtedy Dave może obliczyć _S = Rpub Vpriv = GRpriv Vpriv _ i w ten sposób uzyskać klucze publiczne (_Ppub = Kpub +G\*hasz(S)_). Ale bez _Kpriv _ Dave nie może uzyskać klucza prywatnego.
+
+Podsumowując, oto wartości znane przez różnych uczestników.
+
+| Alicja | Opublikowane | Bill | Dave | |
+| ------------------------------------------------------------------------- | ----------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------- |
+| G | G | G | G | |
+| _Kpriv _ | – | – | – | |
+| _Vpriv _ | – | – | _Vpriv _ | |
+| _Kpub = GKpriv _ | _Kpub _ | _Kpub _ | _Kpub _ | |
+| _Vpub = GVpriv _ | _Vpub _ | _Vpub _ | _Vpub _ | |
+| – | – | _Rpriv _ | – | |
+| _Rpub _ | _Rpub _ | _Rpub = GRpriv _ | _Rpub _ | |
+| _S = Rpub Vpriv = GRpriv Vpriv _ | – | _S = Rpriv Vpub = GRpriv Vpriv _ | _S = _Rpub Vpriv _ = GRpriv Vpriv _ | |
+| _Ppub = Kpub +G\*hasz(S)_ | – | _Ppub = Kpub +G\*hasz(S)_ | _Ppub = Kpub +G\*hasz(S)_ | |
+| _Adres=f(Ppub )_ | – | _Adres=f(Ppub )_ | _Adres=f(Ppub )_ | _Adres=f(Ppub )_ |
+| _Ppriv = Kpriv +hasz(S)_ | – | – | – | |
+
+## Kiedy ukryte adresy zawodzą {#go-wrong}
+
+_Na blockchainie nie ma żadnych tajemnic_. Chociaż ukryte adresy mogą zapewnić Ci prywatność, jest ona podatna na analizę ruchu. Jako trywialny przykład wyobraź sobie, że Bill zasila adres i natychmiast wysyła transakcję w celu opublikowania wartości _Rpub _. Bez _Vpriv _ Alicji nie możemy być pewni, że jest to ukryty adres, ale tak należy zakładać. Następnie widzimy inną transakcję, która przenosi całe ETH z tego adresu na adres funduszu kampanii Alicji. Możemy nie być w stanie tego udowodnić, ale jest prawdopodobne, że Bill właśnie przekazał darowiznę na kampanię Alicji. Karolina z pewnością by tak pomyślała.
+
+Bill może łatwo oddzielić publikację _Rpub _ od zasilenia ukrytego adresu (wykonać je w różnym czasie, z różnych adresów). To jednak nie wystarczy. Wzorzec, którego szuka Karolina, polega na tym, że Bill zasila adres, a następnie fundusz kampanii Alicji wypłaca z niego środki.
+
+Jednym z rozwiązań jest to, aby kampania Alicji nie wypłacała pieniędzy bezpośrednio, ale używała ich do zapłaty stronie trzeciej. Jeśli kampania Alicji wyśle 10 ETH do Dave's World Domination Campaign Services, Karolina będzie wiedziała tylko, że Bill przekazał darowiznę jednemu z klientów Dave'a. Jeśli Dave ma wystarczającą liczbę klientów, Karolina nie będzie w stanie stwierdzić, czy Bill przekazał darowiznę Alicji, która z nią konkuruje, czy Adamowi, Albertowi lub Abigail, na których Karolinie nie zależy. Alicja może dołączyć do płatności zahaszowaną wartość, a następnie dostarczyć Dave'owi jej preobraz, aby udowodnić, że była to jej darowizna. Alternatywnie, jak wspomniano powyżej, jeśli Alicja da Dave'owi swoje _Vpriv _, on już wie, od kogo pochodzi płatność.
+
+Głównym problemem tego rozwiązania jest to, że wymaga ono od Alicji dbania o tajemnicę, gdy ta tajemnica przynosi korzyści Billowi. Alicja może chcieć utrzymać swoją reputację, aby przyjaciel Billa, Bob, również przekazał jej darowiznę. Ale możliwe jest również, że nie będzie jej przeszkadzało zdemaskowanie Billa, ponieważ wtedy będzie się on bał, co się stanie, jeśli Karolina wygra. Bill może w końcu udzielić Alicji jeszcze większego wsparcia.
+
+### Używanie wielu warstw ukrytych {#multi-layer}
+
+Zamiast polegać na Alicji w kwestii zachowania prywatności Billa, Bill może zrobić to sam. Może wygenerować wiele meta-adresów dla fikcyjnych osób, Boba i Belli. Następnie Bill wysyła ETH do Boba, a „Bob” (który w rzeczywistości jest Billem) wysyła je do Belli. „Bella” (również Bill) wysyła je do Alicji.
+
+Karolina wciąż może przeprowadzić analizę ruchu i zobaczyć potok od Billa do Boba, do Belli, do Alicji. Jednakże, jeśli „Bob” i „Bella” również używają ETH do innych celów, nie będzie wyglądało na to, że Bill przekazał cokolwiek Alicji, nawet jeśli Alicja natychmiast wypłaci środki z ukrytego adresu na swój znany adres kampanii.
+
+## Pisanie aplikacji z ukrytymi adresami {#write-app}
+
+Ten artykuł wyjaśnia aplikację z ukrytymi adresami [dostępną na GitHub](https://github.com/qbzzt/251022-stealth-addresses.git).
+
+### Narzędzia {#tools}
+
+Istnieje [biblioteka ukrytych adresów w TypeScript](https://github.com/ScopeLift/stealth-address-sdk), której moglibyśmy użyć. Jednak operacje kryptograficzne mogą być intensywne dla procesora. Wolę je implementować w języku kompilowanym, takim jak [Rust](https://rust-lang.org/), i używać [WASM](https://webassembly.org/) do uruchamiania kodu w przeglądarce.
+
+Będziemy używać [Vite](https://vite.dev/) i [React](https://react.dev/). Są to standardowe narzędzia branżowe; jeśli ich nie znasz, możesz skorzystać z [tego samouczka](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/). Aby używać Vite, potrzebujemy Node.
+
+### Zobacz ukryte adresy w akcji {#in-action}
+
+1. Zainstaluj niezbędne narzędzia: [Rust](https://rust-lang.org/tools/install/) i [Node](https://nodejs.org/en/download).
+
+2. Sklonuj repozytorium GitHub.
+
+ ```sh
+ git clone https://github.com/qbzzt/251022-stealth-addresses.git
+ cd 251022-stealth-addresses
+ ```
+
+3. Zainstaluj wymagania wstępne i skompiluj kod Rust.
+
+ ```sh
+ cd src/rust-wasm
+ rustup target add wasm32-unknown-unknown
+ cargo install wasm-pack
+ wasm-pack build --target web
+ ```
+
+4. Uruchom serwer WWW.
+
+ ```sh
+ cd ../..
+ npm install
+ npm run dev
+ ```
+
+5. Przejdź do [aplikacji](http://localhost:5173/). Ta strona aplikacji ma dwie ramki: jedną dla interfejsu użytkownika Alicji, a drugą dla Billa. Te dwie ramki nie komunikują się ze sobą; znajdują się na tej samej stronie tylko dla wygody.
+
+6. Jako Alicja kliknij **Wygeneruj ukryty meta-adres**. Wyświetli to nowy ukryty adres i odpowiadające mu klucze prywatne. Skopiuj ukryty meta-adres do schowka.
+
+7. Jako Bill, wklej nowy ukryty meta-adres i kliknij **Wygeneruj adres**. Otrzymasz adres do zasilenia dla Alicji.
+
+8. Skopiuj adres i klucz publiczny Billa i wklej je w polu „Klucz prywatny dla adresu wygenerowanego przez Billa” w interfejsie użytkownika Alicji. Po wypełnieniu tych pól zobaczysz klucz prywatny umożliwiający dostęp do aktywów pod tym adresem.
+
+9. Możesz użyć [kalkulatora online](https://iancoleman.net/ethereum-private-key-to-address/), aby upewnić się, że klucz prywatny odpowiada adresowi.
+
+### Jak działa program {#how-the-program-works}
+
+#### Komponent WASM {#wasm}
+
+Kod źródłowy, który kompiluje się do WASM, jest napisany w języku [Rust](https://rust-lang.org/). Możesz go zobaczyć w [`src/rust_wasm/src/lib.rs`](https://github.com/qbzzt/251022-stealth-addresses/blob/main/src/rust-wasm/src/lib.rs). Ten kod jest przede wszystkim interfejsem między kodem JavaScript a [biblioteką `eth-stealth-addresses`](https://github.com/kassandraoftroy/eth-stealth-addresses).
+
+**`Cargo.toml`**
+
+[`Cargo.toml`](https://doc.rust-lang.org/cargo/reference/manifest.html) w Rust jest analogiczny do [`package.json`](https://docs.npmjs.com/cli/v9/configuring-npm/package-json) w JavaScript. Zawiera informacje o pakiecie, deklaracje zależności itp.
+
+```toml
+[package]
+name = "rust-wasm"
+version = "0.1.0"
+edition = "2024"
+
+[dependencies]
+eth-stealth-addresses = "0.1.0"
+hex = "0.4.3"
+wasm-bindgen = "0.2.104"
+getrandom = { version = "0.2", features = ["js"] }
+```
+
+Pakiet [`getrandom`](https://docs.rs/getrandom/latest/getrandom/) musi generować wartości losowe. Nie można tego zrobić czysto algorytmicznymi środkami; wymaga to dostępu do procesu fizycznego jako źródła entropii. Ta definicja określa, że uzyskamy tę entropię, pytając przeglądarkę, w której działamy.
+
+```toml
+console_error_panic_hook = "0.1.7"
+```
+
+[Ta biblioteka](https://docs.rs/console_error_panic_hook/latest/console_error_panic_hook/) dostarcza nam bardziej znaczących komunikatów o błędach, gdy kod WASM wpadnie w panikę i nie może kontynuować.
+
+```toml
+[lib]
+crate-type = ["cdylib", "rlib"]
+```
+
+Typ wyjściowy wymagany do wyprodukowania kodu WASM.
+
+**`lib.rs`**
+
+To jest właściwy kod Rust.
+
+```rust
+use wasm_bindgen::prelude::*;
+```
+
+Definicje do stworzenia pakietu WASM z Rusta. Są one udokumentowane [tutaj](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/index.html).
+
+```rust
+use eth_stealth_addresses::{
+ generate_stealth_meta_address,
+ generate_stealth_address,
+ compute_stealth_key
+};
+```
+
+Funkcje, których potrzebujemy z [biblioteki `eth-stealth-addresses`](https://github.com/kassandraoftroy/eth-stealth-addresses).
+
+```rust
+use hex::{decode,encode};
+```
+
+Rust zazwyczaj używa tablic bajtów ([arrays](https://doc.rust-lang.org/std/primitive.array.html)) (`[u8; ]`) dla wartości. Ale w JavaScript zazwyczaj używamy ciągów szesnastkowych. [Biblioteka `hex`](https://docs.rs/hex/latest/hex/) tłumaczy dla nas z jednej reprezentacji na drugą.
+
+```rust
+#[wasm_bindgen]
+```
+
+Generuj powiązania WASM, aby móc wywołać tę funkcję z JavaScript.
+
+```rust
+pub fn wasm_generate_stealth_meta_address() -> String {
+```
+
+Najprostszym sposobem na zwrócenie obiektu z wieloma polami jest zwrócenie ciągu znaków JSON.
+
+```rust
+ let (address, spend_private_key, view_private_key) =
+ generate_stealth_meta_address();
+```
+
+Funkcja [`generate_stealth_meta_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_meta_address.html) zwraca trzy pola:
+
+- Meta-adres (_Kpub _ i _Vpub _)
+- Klucz prywatny do przeglądania (_Vpriv _)
+- Klucz prywatny do wydawania (_Kpriv _)
+
+Składnia [tupli](https://doc.rust-lang.org/std/primitive.tuple.html) pozwala nam ponownie rozdzielić te wartości.
+
+```rust
+ format!("{{\"address\":\"{}\",\"view_private_key\":\"{}\",\"spend_private_key\":\"{}\"}}",
+ encode(address),
+ encode(view_private_key),
+ encode(spend_private_key)
+ )
+}
+```
+
+Użyj makra [`format!`](https://doc.rust-lang.org/std/fmt/index.html), aby wygenerować ciąg znaków w formacie JSON. Użyj [`hex::encode`](https://docs.rs/hex/latest/hex/fn.encode.html), aby zamienić tablice na ciągi szesnastkowe.
+
+```rust
+fn str_to_array(s: &str) -> Option<[u8; N]> {
+```
+
+Ta funkcja zamienia ciąg szesnastkowy (dostarczony przez JavaScript) na tablicę bajtów. Używamy jej do parsowania wartości dostarczonych przez kod JavaScript. Ta funkcja jest skomplikowana ze względu na sposób, w jaki Rust obsługuje tablice i wektory.
+
+Wyrażenie `` nazywane jest [generykiem](https://doc.rust-lang.org/book/ch10-01-syntax.html). `N` jest parametrem, który kontroluje długość zwracanej tablicy. Funkcja jest w rzeczywistości wywoływana jako `str_to_array::`, gdzie `n` to długość tablicy.
+
+Wartość zwracana to `Option<[u8; N]>`, co oznacza, że zwracana tablica jest [opcjonalna](https://doc.rust-lang.org/std/option/). Jest to typowy wzorzec w Rust dla funkcji, które mogą zakończyć się niepowodzeniem.
+
+Na przykład, jeśli wywołamy `str_to_array::10("bad060a7")`, funkcja ma zwrócić tablicę dziesięciu wartości, ale dane wejściowe mają tylko cztery bajty. Funkcja musi zakończyć się niepowodzeniem i robi to, zwracając `None`. Wartością zwrotną dla `str_to_array::4("bad060a7")` byłoby `Some<[0xba, 0xd0, 0x60, 0xa7]>`.
+
+```rust
+ // decode returns Result, _>
+ let vec = decode(s).ok()?;
+```
+
+Funkcja [`hex::decode`](https://docs.rs/hex/latest/hex/fn.decode.html) zwraca `Result, FromHexError>`. Typ [`Result`](https://doc.rust-lang.org/std/result/) może zawierać pomyślny wynik (`Ok(value)`) lub błąd (`Err(error)`).
+
+Metoda `.ok()` zamienia `Result` na `Option`, której wartością jest albo wartość `Ok()`, jeśli operacja się powiedzie, albo `None`, jeśli nie. Na koniec, [operator znaku zapytania](https://doc.rust-lang.org/std/option/#the-question-mark-operator-) przerywa bieżącą funkcję i zwraca `None`, jeśli `Option` jest puste. W przeciwnym razie odpakowuje wartość i zwraca ją (w tym przypadku, aby przypisać wartość do `vec`).
+
+Wygląda to na dziwnie zawiłą metodę obsługi błędów, ale `Result` i `Option` zapewniają, że wszystkie błędy są obsługiwane, w ten czy inny sposób.
+
+```rust
+ if vec.len() != N { return None; }
+```
+
+Jeśli liczba bajtów jest nieprawidłowa, jest to błąd i zwracamy `None`.
+
+```rust
+ // try_into consumes vec and attempts to make [u8; N]
+ let array: [u8; N] = vec.try_into().ok()?;
+```
+
+Rust ma dwa typy tablic. [Tablice](https://doc.rust-lang.org/std/primitive.array.html) mają stały rozmiar. [Wektory](https://doc.rust-lang.org/std/vec/index.html) mogą rosnąć i maleć. `hex::decode` zwraca wektor, ale biblioteka `eth_stealth_addresses` chce otrzymywać tablice. [`.try_into()`](https://doc.rust-lang.org/std/convert/trait.TryInto.html#required-methods) konwertuje wartość na inny typ, na przykład wektor na tablicę.
+
+```rust
+ Some(array)
+}
+```
+
+Rust nie wymaga użycia słowa kluczowego [`return`](https://doc.rust-lang.org/std/keyword.return.html) przy zwracaniu wartości na końcu funkcji.
+
+```rust
+#[wasm_bindgen]
+pub fn wasm_generate_stealth_address(stealth_address: &str) -> Option {
+```
+
+Ta funkcja otrzymuje publiczny meta-adres, który zawiera zarówno _Vpub _, jak i _Kpub _. Zwraca ukryty adres, klucz publiczny do opublikowania (_Rpub _) oraz jednobajtową wartość skanowania, która przyspiesza identyfikację, które opublikowane adresy mogą należeć do Alicji.
+
+Wartość skanowania jest częścią wspólnego sekretu (_S = GRpriv Vpriv _). Ta wartość jest dostępna dla Alicji, a jej sprawdzenie jest znacznie szybsze niż sprawdzenie, czy _f(Kpub +G\*hasz(S))_ jest równe opublikowanemu adresowi.
+
+```rust
+ let (address, r_pub, scan) =
+ generate_stealth_address(&str_to_array::<66>(stealth_address)?);
+```
+
+Używamy biblioteki [`generate_stealth_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_address.html).
+
+```rust
+ format!("{{\"address\":\"{}\",\"rPub\":\"{}\",\"scan\":\"{}\"}}",
+ encode(address),
+ encode(r_pub),
+ encode(&[scan])
+ ).into()
+}
+```
+
+Przygotuj ciąg wyjściowy zakodowany w formacie JSON.
+
+```rust
+#[wasm_bindgen]
+pub fn wasm_compute_stealth_key(
+ address: &str,
+ bill_pub_key: &str,
+ view_private_key: &str,
+ spend_private_key: &str
+) -> Option {
+ .
+ .
+ .
+}
+```
+
+Ta funkcja używa biblioteki [`compute_stealth_key`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.compute_stealth_key.html) do obliczenia klucza prywatnego do wypłaty z adresu (_Rpriv _). To obliczenie wymaga następujących wartości:
+
+- Adres (_Adres=f(Ppub )_)
+- Klucz publiczny wygenerowany przez Billa (_Rpub _)
+- Klucz prywatny do przeglądania (_Vpriv _)
+- Klucz prywatny do wydawania (_Kpriv _)
+
+```rust
+#[wasm_bindgen(start)]
+```
+
+[`#[wasm_bindgen(start)]`](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/on-rust-exports/start.html) określa, że funkcja jest wykonywana po zainicjowaniu kodu WASM.
+
+```rust
+pub fn main() {
+ console_error_panic_hook::set_once();
+}
+```
+
+Ten kod określa, że dane wyjściowe paniki są wysyłane do konsoli JavaScript. Aby zobaczyć to w działaniu, użyj aplikacji i podaj Billowi nieprawidłowy meta-adres (wystarczy zmienić jedną cyfrę szesnastkową). W konsoli JavaScript zobaczysz następujący błąd:
+
+```
+rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/subtle-2.6.1/src/lib.rs:701:9:
+assertion `left == right` failed
+ left: 0
+ right: 1
+```
+
+Po którym następuje ślad stosu. Następnie podaj Billowi prawidłowy meta-adres, a Alicji nieprawidłowy adres lub nieprawidłowy klucz publiczny. Zobaczysz następujący błąd:
+
+```
+rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/eth-stealth-addresses-0.1.0/src/lib.rs:78:9:
+klucze nie generują ukrytego adresu
+```
+
+Ponownie, po którym następuje ślad stosu.
+
+#### Interfejs użytkownika {#ui}
+
+Interfejs użytkownika jest napisany przy użyciu [React](https://react.dev/) i serwowany przez [Vite](https://vite.dev/). Możesz dowiedzieć się o nich, korzystając z [tego samouczka](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/). Nie ma tu potrzeby używania [WAGMI](https://wagmi.sh/), ponieważ nie wchodzimy w bezpośrednią interakcję z blockchainem ani portfelem.
+
+Jedyną nieoczywistą częścią interfejsu użytkownika jest łączność z WASM. Oto jak to działa.
+
+**`vite.config.js`**
+
+Ten plik zawiera [konfigurację Vite](https://vite.dev/config/).
+
+```js
+import { defineConfig } from 'vite'
+import react from '@vitejs/plugin-react'
+import wasm from "vite-plugin-wasm";
+
+// https://vite.dev/config/
+export default defineConfig({
+ plugins: [react(), wasm()],
+})
+```
+
+Potrzebujemy dwóch wtyczek Vite: [react](https://www.npmjs.com/package/@vitejs/plugin-react) i [wasm](https://github.com/Menci/vite-plugin-wasm#readme).
+
+**`App.jsx`**
+
+Ten plik jest głównym komponentem aplikacji. Jest to kontener, który zawiera dwa komponenty: `Alice` i `Bill`, interfejsy użytkownika dla tych użytkowników. Istotną częścią dla WASM jest kod inicjalizacyjny.
+
+```jsx
+import init from './rust-wasm/pkg/rust_wasm.js'
+```
+
+Gdy używamy [`wasm-pack`](https://rustwasm.github.io/docs/wasm-pack/), tworzy on dwa pliki, których tu używamy: plik wasm z właściwym kodem (tutaj, `src/rust-wasm/pkg/rust_wasm_bg.wasm`) oraz plik JavaScript z definicjami do jego użycia (tutaj, `src/rust_wasm/pkg/rust_wasm.js`). Domyślny eksport tego pliku JavaScript to kod, który musi zostać uruchomiony, aby zainicjować WASM.
+
+```jsx
+function App() {
+ .
+ .
+ .
+ useEffect(() => {
+ const loadWasm = async () => {
+ try {
+ await init();
+ setWasmReady(true)
+ } catch (err) {
+ console.error('Error loading wasm:', err)
+ alert("Wasm error: " + err)
+ }
+ }
+
+ loadWasm()
+ }, []
+ )
+```
+
+Hak [`useEffect`](https://react.dev/reference/react/useEffect) pozwala określić funkcję, która jest wykonywana, gdy zmieniają się zmienne stanu. Tutaj lista zmiennych stanu jest pusta (`[]`), więc ta funkcja jest wykonywana tylko raz, gdy strona się ładuje.
+
+Funkcja efektu musi natychmiast zwrócić wartość. Aby użyć kodu asynchronicznego, takiego jak `init` WASM (który musi załadować plik `.wasm` i dlatego wymaga czasu), definiujemy wewnętrzną funkcję [`async`](https://en.wikipedia.org/wiki/Async/await) i uruchamiamy ją bez `await`.
+
+**`Bill.jsx`**
+
+To jest interfejs użytkownika dla Billa. Ma jedną akcję: tworzenie adresu na podstawie ukrytego meta-adresu dostarczonego przez Alicję.
+
+```jsx
+import { wasm_generate_stealth_address } from './rust-wasm/pkg/rust_wasm.js'
+```
+
+Oprócz domyślnego eksportu, kod JavaScript wygenerowany przez `wasm-pack` eksportuje funkcję dla każdej funkcji w kodzie WASM.
+
+```jsx
+ {
+ setPublicAddress(JSON.parse(wasm_generate_stealth_address(stealthMetaAddress)))
+ }}>
+```
+
+Aby wywołać funkcje WASM, po prostu wywołujemy funkcję wyeksportowaną przez plik JavaScript utworzony przez `wasm-pack`.
+
+**`Alice.jsx`**
+
+Kod w `Alice.jsx` jest analogiczny, z wyjątkiem tego, że Alicja ma dwie akcje:
+
+- Wygeneruj meta-adres
+- Uzyskaj klucz prywatny dla adresu opublikowanego przez Billa
+
+## Wnioski {#conclusion}
+
+Ukryte adresy nie są panaceum; muszą być [używane poprawnie](#go-wrong). Ale gdy są używane poprawnie, mogą zapewnić prywatność na publicznym blockchainie.
+
+[Zobacz więcej mojej pracy tutaj](https://cryptodocguy.pro/).
\ No newline at end of file
diff --git a/public/content/translations/pl/developers/tutorials/the-graph-fixing-web3-data-querying/index.md b/public/content/translations/pl/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
index 237406a7540..878b4fbace9 100644
--- a/public/content/translations/pl/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
+++ b/public/content/translations/pl/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
@@ -1,26 +1,27 @@
---
-title: "The Graph: zapytania o dane Web3"
-description: Blockchain jest jak baza danych, ale bez SQL. Wszystkie dane tam są, ale nie ma do nich dostępu. Pokażę ci, jak to naprawić za pomocą The Graph i GraphQL.
+title: "The Graph: Usprawnianie zapytań o dane Web3"
+description: "Blockchain jest jak baza danych, ale bez SQL. Wszystkie dane tam są, ale nie ma do nich dostępu. Pokażę ci, jak to naprawić za pomocą The Graph i GraphQL."
author: Markus Waas
lang: pl
tags:
- - "solidity"
- - "inteligentne kontrakty"
- - "zapytania"
- - "the graph"
- - "create-eth-app"
- - "reakcja"
+ [
+ "solidity",
+ "smart kontrakty",
+ "zapytania",
+ "the graph",
+ "react"
+ ]
skill: intermediate
published: 2020-09-06
source: soliditydeveloper.com
sourceUrl: https://soliditydeveloper.com/thegraph
---
-Tym razem przyjrzymy się bliżej protokołowi The Graph, który zasadniczo stał się częścią standardowego stosu do tworzenia aplikacji dapps w zeszłym roku. Zobaczmy najpierw, jak zrobilibyśmy rzeczy w tradycyjny sposób...
+Tym razem przyjrzymy się bliżej The Graph, który w zeszłym roku stał się zasadniczo częścią standardowego stosu do tworzenia dapek. Zobaczmy najpierw, jak zrobilibyśmy rzeczy w tradycyjny sposób...
## Bez The Graph... {#without-the-graph}
-Przejdźmy więc do prostego przykładu w celach ilustracyjnych. Wszyscy lubimy gry, więc wyobraźmy sobie prostą grę z użytkownikami zakładów:
+Przejdźmy więc do prostego przykładu w celach ilustracyjnych. Wszyscy lubimy gry, więc wyobraźmy sobie prostą grę, w której użytkownicy obstawiają zakłady:
```solidity
pragma solidity 0.7.1;
@@ -35,7 +36,7 @@ contract Game {
if (hasWon) {
(bool success, ) = msg.sender.call{ value: msg.value * 2 }('');
- require(success, "Transfer failed");
+ require(success, "Transfer nie powiódł się");
totalGamesPlayerWon++;
} else {
totalGamesPlayerLost++;
@@ -46,34 +47,34 @@ contract Game {
}
```
-Załóżmy teraz, że w naszej aplikacji dapp chcemy wyświetlić całkowitą liczbę przegranych/wygranych gier, a także aktualizować ją za każdym razem, gdy ktoś gra ponownie. Podejście byłoby następujące:
+Powiedzmy, że w naszej dapce chcemy wyświetlać całkowitą liczbę zakładów, łączną liczbę przegranych/wygranych gier, a także aktualizować ją za każdym razem, gdy ktoś ponownie zagra. Podejście byłoby następujące:
1. Pobierz `totalGamesPlayerWon`.
-2. Pobierz `totalGamesPlayerlost`.
-3. Subskrybuj zdarzenia `BetPlaceed`.
+2. Pobierz `totalGamesPlayerLost`.
+3. Subskrybuj zdarzenia `BetPlaced`.
-Możemy nasłuchiwać zdarzeń [w sieci Web3](https://docs.web3js.org/api/web3/class/Contract#events), jak widać po prawej stronie, ale wymaga to obsługi kilku przypadków.
+Możemy nasłuchiwać [zdarzenia w Web3](https://docs.web3js.org/api/web3/class/Contract#events), jak pokazano po prawej stronie, ale wymaga to obsługi sporej liczby przypadków.
```solidity
GameContract.events.BetPlaced({
fromBlock: 0
}, function(error, event) { console.log(event); })
.on('data', function(event) {
- // event fired
+ // zdarzenie zostało wywołane
})
.on('changed', function(event) {
- // event was removed again
+ // zdarzenie zostało ponownie usunięte
})
.on('error', function(error, receipt) {
- // tx rejected
+ // transakcja odrzucona
});
```
-W naszym prostym przykładzie jest to nadal poniekąd w porządku. Ale powiedzmy, że chcemy teraz wyświetlać kwoty przegranych/wygranych zakładów tylko dla aktualnego gracza. Cóż, nie mamy szczęścia, lepiej wdrożyć nowy kontrakt, który przechowuje te wartości i je pobiera. A teraz wyobraź sobie znacznie bardziej skomplikowany inteligentny kontrakt i dapp, rzeczy mogą szybko się popsuć.
+W naszym prostym przykładzie jest to nadal w miarę w porządku. Ale powiedzmy, że chcemy teraz wyświetlać kwoty przegranych/wygranych zakładów tylko dla aktualnego gracza. Cóż, nie mamy szczęścia, lepiej wdrożyć nowy kontrakt, który przechowuje te wartości i je pobiera. A teraz wyobraź sobie znacznie bardziej skomplikowany inteligentny kontrakt i dapkę, sprawy mogą się bardzo szybko skomplikować.
-
+
-Możesz zobaczyć, że to nieoptymalne:
+Widać, że nie jest to optymalne:
- Nie działa dla już wdrożonych kontraktów.
- Dodatkowe koszty gazu za przechowywanie tych wartości.
@@ -85,50 +86,50 @@ Spójrzmy teraz na lepsze rozwiązanie.
## Pozwól, że przedstawię Ci GraphQL {#let-me-introduce-to-you-graphql}
-Najpierw porozmawiajmy o GraphQL, pierwotnie zaprojektowanym i zaimplementowanym przez Facebooka. Być może znasz tradycyjny model Rest API. Teraz wyobraź sobie, że zamiast tego możesz napisać zapytanie dla dokładnie tych danych, które chciałeś:
+Najpierw porozmawiajmy o GraphQL, pierwotnie zaprojektowanym i zaimplementowanym przez Facebooka. Być może znasz tradycyjny model API REST. A teraz wyobraź sobie, że zamiast tego możesz napisać zapytanie dokładnie o te dane, które chcesz:
-
+
-(0)
player.totalPlayedCount = 0
@@ -229,7 +230,7 @@ export function handleNewBet(event: PlacedBet): void {
player.hasLostCount++
}
- // update array like this
+ // zaktualizuj tablicę w ten sposób
let bets = player.bets
bets.push(bet.id)
player.bets = bets
@@ -238,12 +239,12 @@ export function handleNewBet(event: PlacedBet): void {
}
```
-## Używanie go w frontendzie {#using-it-in-the-frontend}
+## Użycie na frontendzie {#using-it-in-the-frontend}
-Używając czegoś takiego jak Apollo Boost, możesz łatwo zintegrować The Graph z React Dapp (lub Apollo-Vue). Zwłaszcza gdy używasz hooków React i Apollo, pobieranie danych jest tak proste, jak napisanie pojedynczego zapytania GraphQl w twoim komponencie. Typowa konfiguracja może wyglądać tak:
+Używając czegoś takiego jak Apollo Boost, można łatwo zintegrować The Graph w swojej dapce React (lub Apollo-Vue). Szczególnie w przypadku korzystania z hooków React i Apollo, pobieranie danych jest tak proste, jak napisanie pojedynczego zapytania GraphQL w komponencie. Typowa konfiguracja może wyglądać następująco:
```javascript
-// See all subgraphs: https://thegraph.com/explorer/
+// Zobacz wszystkie podgrafy: https://thegraph.com/explorer/
const client = new ApolloClient({
uri: "{{ subgraphUrl }}",
})
@@ -258,9 +259,9 @@ ReactDOM.render(
A teraz możemy napisać na przykład takie zapytanie. Spowoduje to pobranie
-- ile razy obecny użytkownik wygrał
-- ile razy aktualny użytkownik przegrał
-- listę sygnatur czasowych ze wszystkimi jego poprzednimi zakładami
+- ile razy bieżący użytkownik wygrał
+- ile razy bieżący użytkownik przegrał
+- listy sygnatur czasowych ze wszystkimi jego poprzednimi zakładami
Wszystko w jednym żądaniu do serwera GraphQL.
@@ -285,32 +286,29 @@ React.useEffect(() => {
}, [loading, error, data])
```
-
+
-Ale brakuje nam ostatniego elementu układanki, a jest nim serwer. Możesz uruchomić go samodzielnie lub skorzystać z usługi hostowanej.
+Ale brakuje nam ostatniego elementu układanki, którym jest serwer. Można go uruchomić samodzielnie lub skorzystać z usługi hostowanej.
## Serwer The Graph {#the-graph-server}
-### Graph Explorer: usługa hostowana {#graph-explorer-the-hosted-service}
+### Graph Explorer: Usługa hostowana {#graph-explorer-the-hosted-service}
-Najprostszym sposobem jest skorzystanie z usługi hostowanej. Postępuj zgodnie z instrukcjami [tutaj](https://thegraph.com/docs/deploy-a-subgraph), aby wdrożyć subgraf. W przypadku wielu projektów można znaleźć istniejące podgrafy w eksploratorze pod adresem https://thegraph.com/explorer/.
+Najprostszym sposobem jest skorzystanie z usługi hostowanej. Postępuj zgodnie z instrukcjami [tutaj](https://thegraph.com/docs/en/deploying/deploying-a-subgraph-to-hosted/), aby wdrożyć podgraf. Dla wielu projektów można znaleźć istniejące podgrafy w [eksploratorze](https://thegraph.com/explorer/).
### Uruchamianie własnego węzła {#running-your-own-node}
-Alternatywnie możesz uruchomić własny węzeł: https://github.com/graphprotocol/graph-node#quick-start. Jednym z powodów, aby to zrobić, może być korzystanie z sieci, która nie jest obsługiwana przez hostowaną usługę. Obecnie obsługiwane są sieć główna, Sepolia, xDAI i inne popularne sieci.
+Alternatywnie można uruchomić własny węzeł. Dokumentacja [tutaj](https://github.com/graphprotocol/graph-node#quick-start). Jednym z powodów może być korzystanie z sieci, która nie jest obsługiwana przez usługę hostowaną. Obecnie obsługiwane sieci [można znaleźć tutaj](https://thegraph.com/docs/en/developing/supported-networks/).
## Zdecentralizowana przyszłość {#the-decentralized-future}
-GraphQL obsługuje również strumienie dla nowo przychodzących zdarzeń. Nie jest to jeszcze w pełni obsługiwane przez The Graph, ale zostanie wkrótce wydane.
+GraphQL obsługuje również strumienie dla nowo przychodzących zdarzeń. Są one obsługiwane w The Graph za pomocą [Substreams](https://thegraph.com/docs/en/substreams/), które są obecnie w otwartej wersji beta.
-Brakującym aspektem jest jednak wciąż decentralizacja. The Graph w przyszłości ma ostatecznie stać się w pełni zdecentralizowanym protokołem. Oto dwa świetne artykuły, które bardziej szczegółowo wyjaśniają plan:
-
-- https://thegraph.com/blog/the-graph-network-in-depth-part-1
-- https://thegraph.com/blog/the-graph-network-in-depth-part-2
+W [2021](https://thegraph.com/blog/mainnet-migration/) The Graph rozpoczął przejście na zdecentralizowaną sieć indeksującą. Więcej o architekturze tej zdecentralizowanej sieci indeksującej można przeczytać [tutaj](https://thegraph.com/docs/en/network/explorer/).
Dwa kluczowe aspekty to:
-1. Użytkownicy będą płacić indeksatorom za zapytania.
-2. Indeksatorzy będą stakować tokeny Graph (GRT).
+1. Użytkownicy płacą indekserom za zapytania.
+2. Indekserzy stakują tokeny Graph (GRT).
diff --git a/public/content/translations/pl/developers/tutorials/token-integration-checklist/index.md b/public/content/translations/pl/developers/tutorials/token-integration-checklist/index.md
index d4312d70d98..176c43467d2 100644
--- a/public/content/translations/pl/developers/tutorials/token-integration-checklist/index.md
+++ b/public/content/translations/pl/developers/tutorials/token-integration-checklist/index.md
@@ -1,84 +1,86 @@
---
-title: Lista kontrolna integracji tokenów
-description: Lista kontrolna rzeczy do rozważenia podczas interakcji z tokenami
+title: "Lista kontrolna integracji tokenów"
+description: "Lista kontrolna rzeczy do rozważenia podczas interakcji z tokenami"
author: "Trailofbits"
lang: pl
tags:
- - "solidity"
- - "inteligentne kontrakty"
- - "ochrona"
- - "tokeny"
+ [
+ "solidity",
+ "smart kontrakty",
+ "bezpieczeństwo",
+ "tokeny"
+ ]
skill: intermediate
published: 2020-08-13
-source: Tworzenie bezpiecznych kontraktów
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/token_integration.md
---
-Postępuj zgodnie z tą listą kontrolną podczas interakcji z dowolnymi tokenami. Upewnij się, że rozumiesz ryzyko związane z każdym produktem i uzasadnij wszelkie wyjątki od tych zasad.
+Postępuj zgodnie z tą listą kontrolną podczas interakcji z dowolnymi tokenami. Upewnij się, że rozumiesz ryzyko związane z każdym elementem i uzasadnij wszelkie wyjątki od tych zasad.
-Dla wygody wszystkie [narzędzia](https://github.com/crytic/slither#tools) Slithera można uruchomić bezpośrednio na adresie tokena, takim jak:
+Dla wygody wszystkie [narzędzia](https://github.com/crytic/slither#tools) Slithera można uruchomić bezpośrednio na adresie tokena, na przykład:
-[Korzystanie z samouczka Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
+[Samouczek korzystania ze Slithera](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
```bash
slither-check-erc 0xdac17f958d2ee523a2206206994597c13d831ec7 TetherToken
```
-Aby postępować zgodnie z tą listą kontrolną, będziesz chciał uzyskać dane wyjściowe ze Slither dla tokena:
+Aby postępować zgodnie z tą listą kontrolną, potrzebne będą dane wyjściowe ze Slither dla danego tokena:
```bash
-- slither-check-erc [target] [contractName] [optional: --erc ERC_NUMBER]
+- slither-check-erc [target] [contractName] [opcjonalnie: --erc ERC_NUMBER]
- slither [target] --print human-summary
- slither [target] --print contract-summary
-- slither-prop . --contract ContractName # requires configuration, and use of Echidna and Manticore
+- slither-prop . --contract ContractName # wymaga konfiguracji oraz użycia Echidna i Manticore
```
-## Uwagi ogólne {#general-considerations}
+## Ogólne uwagi {#general-considerations}
-- **Kontrakt obejmuje przegląd bezpieczeństwa.** Unikaj interakcji z umowami, które nie mają przeglądu bezpieczeństwa. Sprawdź długość oceny (inaczej „poziom nakładu pracy”), reputację firmy zabezpieczającej oraz liczbę i wagę ustaleń.
-- **Skontaktowałeś się z programistami.** Może być konieczne powiadomienie ich zespołu o incydencie. Poszukaj odpowiednich kontaktów na [blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts).
-- **Mają listę dyskusyjną dotyczącą bezpieczeństwa dla krytycznych ogłoszeń.** Ich zespół powinien informować użytkowników (takich jak Ty!) w przypadku wykrycia krytycznych problemów lub aktualizacji.
+- **Kontrakt przeszedł audyt bezpieczeństwa.** Unikaj interakcji z kontraktami, które nie przeszły audytu bezpieczeństwa. Sprawdź długość oceny (tzw. „poziom włożonego wysiłku”), reputację firmy przeprowadzającej audyt bezpieczeństwa oraz liczbę i wagę wykrytych problemów.
+- **Nawiązano kontakt z deweloperami.** Być może będziesz musiał(a) powiadomić ich zespół o incydencie. Poszukaj odpowiednich kontaktów w [blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts).
+- **Posiadają listę mailingową dotyczącą bezpieczeństwa dla krytycznych ogłoszeń.** Ich zespół powinien informować użytkowników (takich jak Ty!) o wykryciu krytycznych problemów lub o wprowadzeniu uaktualnień.
-## Zgodność ERC {#erc-conformity}
+## Zgodność z ERC {#erc-conformity}
-Slither zawiera narzędzie [slither-check-erc](https://github.com/crytic/slither/wiki/ERC-Conformance), które sprawdza zgodność tokenu z wieloma powiązanymi ERC standardami. Użyj slither-check-erc, aby sprawdzić, czy:
+Slither zawiera narzędzie, [slither-check-erc](https://github.com/crytic/slither/wiki/ERC-Conformance), które sprawdza zgodność tokena z wieloma powiązanymi standardami ERC. Użyj slither-check-erc, aby sprawdzić, czy:
-- **Transfer i transferFrom zwracają wartość logiczną.** Kilka tokenów nie zwraca wartości logicznych w tych funkcjach. W rezultacie ich połączenia w kontrakcie mogą się nie powieść.
-- **Nazwa, miejsca dziesiętne i funkcje symboli są obecne, jeśli są używane.** Te funkcje są opcjonalne w standardzie ERC20 i mogą nie być obecne.
-- **Ułamki dziesiętne zwracają uint8.** Kilka tokenów nieprawidłowo zwraca uint256. W takim przypadku należy zapewnić, aby zwrócona wartość była niższa niż 255.
-- **Token ogranicza znany [wyścig ERC20](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729).** Standard ERC20 ma znaną sytuację wyścigu ERC20, którą należy ograniczyć, aby uniemożliwić atakującym kradzież tokenów.
-- **Token nie jest tokenem ERC777 i nie ma zewnętrznego wywołania w funkcjach transfer i transferFrom.** Wywołania zewnętrzne w funkcjach transferu mogą prowadzić do wielobieżności.
+- **Funkcje transfer i transferFrom zwracają wartość logiczną (boolean).** Niektóre tokeny nie zwracają wartości logicznej w tych funkcjach. W rezultacie ich wywołania w kontrakcie mogą zakończyć się niepowodzeniem.
+- **Funkcje name, decimals i symbol są obecne, jeśli są używane.** Funkcje te są opcjonalne w standardzie ERC20 i mogą nie być zaimplementowane.
+- **Funkcja decimals zwraca uint8.** Niektóre tokeny nieprawidłowo zwracają uint256. W takim przypadku upewnij się, że zwracana wartość jest niższa niż 255.
+- **Token łagodzi znany [problem „race condition” w ERC20](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729).** Standard ERC20 ma znany problem „race condition”, który musi być zaadresowany, aby uniemożliwić atakującym kradzież tokenów.
+- **Token nie jest tokenem ERC777 i nie ma zewnętrznego wywołania funkcji w transfer i transferFrom.** Zewnętrzne wywołania w funkcjach transferu mogą prowadzić do reentrancy.
-Slither zawiera narzędzie [slither-prop](https://github.com/crytic/slither/wiki/Property-generation), które generuje testy jednostkowe i właściwości bezpieczeństwa, które mogą wykryć wiele popularnych wad ERC. Użyj slither-prop, aby sprawdzić, czy:
+Slither zawiera narzędzie [slither-prop](https://github.com/crytic/slither/wiki/Property-generation), które generuje testy jednostkowe i właściwości bezpieczeństwa, które mogą wykryć wiele typowych wad w standardzie ERC. Użyj slither-prop, aby sprawdzić, czy:
-- **Kontrakt przekazuje wszystkie testy jednostkowe i właściwości zabezpieczeń z slither-prop.** Uruchom wygenerowane testy jednostkowe, a następnie sprawdź właściwości za pomocą [Echidna](https://github.com/crytic/echidna) i [Manticore](https://manticore.readthedocs.io/en/latest/verifier.html).
+- **Kontrakt przechodzi wszystkie testy jednostkowe i weryfikacje właściwości bezpieczeństwa z slither-prop.** Uruchom wygenerowane testy jednostkowe, a następnie sprawdź właściwości za pomocą [Echidna](https://github.com/crytic/echidna) i [Manticore](https://manticore.readthedocs.io/en/latest/verifier.html).
-Wreszcie istnieją pewne cechy, które trudno zidentyfikować automatycznie. Sprawdź te warunki ręcznie:
+Istnieją również pewne cechy, które trudno jest zidentyfikować automatycznie. Sprawdź ręcznie następujące warunki:
-- **Transfer i transferFrom nie powinny wiązać się z opłatami.** Tokeny deflacyjne mogą prowadzić do nieoczekiwanego zachowania.
-- **Potencjalne odsetki uzyskane z tokena są brane pod uwagę.** Niektóre tokeny rozdzielają odsetki na posiadaczy tokenów. Te odsetki mogą zostać zablokowane w kontrakcie, jeśli nie zostanie on wzięty pod uwagę.
+- **Funkcje transfer i transferFrom nie powinny pobierać opłaty.** Tokeny deflacyjne mogą prowadzić do nieoczekiwanego zachowania.
+- **Potencjalne odsetki uzyskane z tokena są brane pod uwagę.** Niektóre tokeny rozdzielają odsetki pomiędzy posiadaczy tokenów. Te odsetki mogą zostać uwięzione w kontrakcie, jeśli nie zostaną uwzględnione.
## Kompozycja kontraktu {#contract-composition}
-- **Kontrakt pozwala uniknąć niepotrzebnej złożoności.** Token powinien być prostą umową; token ze złożonym kodem wymaga wyższego standardu weryfikacji. Użyj [drukarki podsumowań ludzkich](https://github.com/crytic/slither/wiki/Printer-documentation#human-summary) Slithera, aby zidentyfikować złożony kod.
-- **Kontrakt korzysta z SafeMath.** Kontrakty, które nie korzystają z SafeMath, wymagają wyższego standardu weryfikacji. Sprawdź umowę ręcznie pod kątem użycia SafeMath.
-- **Kontrakt ma tylko kilka funkcji niezwiązanych z tokenem.** Funkcje niezwiązane z tokenem zwiększają prawdopodobieństwo wystąpienia problemu w kontrakcie. Skorzystaj z [drukarki podsumowań kontraktów](https://github.com/crytic/slither/wiki/Printer-documentation#contract-summary) Slithera, aby ogólnie zapoznać się z kodem użytym w kontrakcie.
-- **Token ma tylko jeden adres.** Tokeny z wieloma punktami wejścia do aktualizacji salda mogą zepsuć wewnętrzną księgowość na podstawie adresu (np. `balances[token_address][msg.sender]` może nie odzwierciedlać faktycznego salda).
+- **Kontrakt unika niepotrzebnej złożoności.** Token powinien być prostym kontraktem; token ze złożonym kodem wymaga wyższego standardu weryfikacji. Użyj narzędzia Slithera [human-summary printer](https://github.com/crytic/slither/wiki/Printer-documentation#human-summary), aby zidentyfikować złożony kod.
+- **Kontrakt używa SafeMath.** Kontrakty, które nie używają SafeMath, wymagają wyższego standardu weryfikacji. Sprawdź ręcznie użycie SafeMath w kontrakcie.
+- **Kontrakt ma tylko kilka funkcji niezwiązanych z tokenem.** Funkcje niezwiązane z tokenem zwiększają prawdopodobieństwo wystąpienia problemu w kontrakcie. Użyj narzędzia Slithera [contract-summary printer](https://github.com/crytic/slither/wiki/Printer-documentation#contract-summary), aby ogólnie przejrzeć kod użyty w kontrakcie.
+- **Token ma tylko jeden adres.** Tokeny z wieloma punktami wejścia dla aktualizacji salda mogą zakłócić wewnętrzną księgowość opartą na adresie (np. `balances[token_address][msg.sender]` może nie odzwierciedlać rzeczywistego salda).
## Uprawnienia właściciela {#owner-privileges}
-- **Tokenu nie można uaktualnić.** Umowy z możliwością uaktualnienia mogą z czasem zmienić swoje zasady. Użyj [drukarki podsumowania ludzkiego](https://github.com/crytic/slither/wiki/Printer-documentation#contract-summary) Slithera, aby określić, czy kontrakt można uaktualnić.
-- **Właściciel ma ograniczone możliwości bicia tokenów.** Złośliwi lub nieuczciwi właściciele mogą nadużywać możliwości bicia tokenów. Użyj [drukarki podsumowania ludzkiego](https://github.com/crytic/slither/wiki/Printer-documentation#contract-summary) Slithera, aby przejrzeć możliwości wybijania tokenów i rozważ ręczne przejrzenie kodu.
-- **Token nie można wstrzymywać.** Złośliwi lub nieuczciwi właściciele mogą blokować umowy oparte na tokenach, które można wstrzymywać. Zidentyfikuj ręcznie kod, który można wstrzymać.
-- **Właściciel nie może umieścić kontraktu na czarnej liście.** Złośliwi lub nieuczciwi właściciele mogą za pomocą czarnej listy blokować umowy oparte na tokenach Ręczne identyfikowanie funkcji czarnej listy.
-- **Zespół odpowiedzialny za token jest znany i może zostać pociągnięty do odpowiedzialności za nadużycia.** Umowy z anonimowymi zespołami programistów lub przebywającymi w legalnych schroniskach powinny wymagać wyższego standardu weryfikacji.
+- **Token nie jest aktualizowalny.** Kontrakty aktualizowalne mogą z czasem zmieniać swoje zasady. Użyj narzędzia Slithera [human-summary printer](https://github.com/crytic/slither/wiki/Printer-documentation#contract-summary), aby ustalić, czy kontrakt jest aktualizowalny.
+- **Właściciel ma ograniczone możliwości mintingu (wybijania).** Złośliwi lub przejęci właściciele mogą nadużywać tych możliwości. Użyj narzędzia Slithera [human-summary printer](https://github.com/crytic/slither/wiki/Printer-documentation#contract-summary), aby przejrzeć możliwości mintingu (wybijania) i rozważ ręczne przejrzenie kodu.
+- **Token nie jest wstrzymywalny.** Złośliwi lub przejęci właściciele mogą zablokować kontrakty opierające się na wstrzymywalnych tokenach. Zidentyfikuj ręcznie kod umożliwiający wstrzymanie.
+- **Właściciel nie może umieścić kontraktu na czarnej liście.** Złośliwi lub przejęci właściciele mogą zablokować kontrakty opierające się na tokenach z czarną listą. Zidentyfikuj ręcznie funkcje czarnej listy.
+- **Zespół stojący za tokenem jest znany i może zostać pociągnięty do odpowiedzialności za nadużycia.** Kontrakty z anonimowymi zespołami deweloperskimi lub te, które znajdują się w rajach prawnych, powinny wymagać wyższego standardu weryfikacji.
-## Niedobór tokenów {#token-scarcity}
+## Rzadkość tokena {#token-scarcity}
-Przeglądy pod kątem problemów związanych z niedoborem tokenów wymagają ręcznego sprawdzenia. Sprawdź te warunki:
+Weryfikacja problemów związanych z rzadkością tokenów wymaga ręcznego sprawdzenia. Sprawdź następujące warunki:
-- **Żaden użytkownik nie jest właścicielem większości zasobów.** Jeśli kilku użytkowników posiada większość tokenów, mogą wpływać na operacje na podstawie podziału tokena.
-- **Całkowita podaż jest wystarczająca.** Tokenami o niskiej łącznej podaży można łatwo manipulować.
-- **Tokeny znajdują się na więcej niż kilku giełdach.** Jeśli wszystkie tokeny znajdują się na jednej giełdzie, kompromis giełdy może naruszyć kontrakt polegający na tokenie.
-- **Użytkownicy rozumieją ryzyko związane z dużymi funduszami lub błyskawicznymi pożyczkami.** Kontrakty opierające się na saldzie tokenów muszą uwzględniać osoby atakujące z dużymi funduszami lub ataki za pośrednictwem błyskawicznych pożyczek.
-- **Token nie pozwala na błyskawiczne wybijanie**. Błyskawiczne wybijanie może prowadzić do znacznych wahań salda i całkowitej podaży, co wymaga ścisłych i kompleksowych kontroli przepełnienia w działaniu tokena.
+- **Żaden użytkownik nie posiada większości podaży.** Jeśli kilku użytkowników posiada większość tokenów, mogą oni wpływać na operacje w zależności od podziału tokena.
+- **Całkowita podaż jest wystarczająca.** Tokenami o niskiej całkowitej podaży można łatwo manipulować.
+- **Tokeny znajdują się na więcej niż kilku giełdach.** Jeśli wszystkie tokeny znajdują się na jednej giełdzie, przejęcie kontroli nad tą giełdą może zagrozić kontraktowi opierającemu się na tym tokenie.
+- **Użytkownicy rozumieją ryzyko związane z dużymi funduszami lub pożyczkami błyskawicznymi (flash loans).** Kontrakty opierające się na saldzie tokenów muszą starannie uwzględniać atakujących z dużymi funduszami lub ataki za pośrednictwem pożyczek błyskawicznych.
+- **Token nie pozwala na błyskawiczny minting (flash minting)**. Błyskawiczny minting może prowadzić do znacznych wahań salda i całkowitej podaży, co wymaga ścisłych i kompleksowych kontroli przepełnienia (overflow) w działaniu tokena.
diff --git a/public/content/translations/pl/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md b/public/content/translations/pl/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md
index fbf2125a81b..7daa4c91d25 100644
--- a/public/content/translations/pl/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md
+++ b/public/content/translations/pl/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/index.md
@@ -1,13 +1,8 @@
---
-title: Transfery i zatwierdzenie tokenów ERC-20 z inteligentnego kontraktu Solidity
-description: Jak używać inteligentnego kontraktu do interakcji z tokenem przy użyciu języka Solidity
+title: "Transfery i zatwierdzenie tokenów ERC-20 z inteligentnego kontraktu Solidity"
+description: "Zbuduj inteligentny kontrakt DEX, który obsługuje transfery i zatwierdzenia tokenów ERC-20 przy użyciu Solidity."
author: "jdourlens"
-tags:
- - "inteligentne kontrakty"
- - "tokeny"
- - "solidity"
- - "pierwsze kroki"
- - "erc-20"
+tags: [ "smart kontrakty", "tokeny", "solidity", "erc-20" ]
skill: intermediate
lang: pl
published: 2020-04-07
@@ -16,19 +11,19 @@ sourceUrl: https://ethereumdev.io/transfers-and-approval-or-erc20-tokens-from-a-
address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
---
-W poprzednim samouczku zbadaliśmy [anatomię tokena ERC-20 w Solidity](/developers/tutorials/understand-the-erc-20-token-smart-contract/) w blockchainie Ethereum. W tym artykule zobaczymy, jak możemy użyć inteligentnego kontraktu do interakcji z tokenem, używając języka Solidity.
+W poprzednim samouczku zbadaliśmy [anatomię tokena ERC-20 w Solidity](/developers/tutorials/understand-the-erc-20-token-smart-contract/) na blockchainie Ethereum. W tym artykule zobaczymy, jak możemy użyć inteligentnego kontraktu do interakcji z tokenem, używając języka Solidity.
-Dla tego inteligentnego kontraktu stworzymy naprawdę fikcyjną zdecentralizowaną giełdę, na której użytkownik może wymieniać ether na nasze nowo wdrożone [tokeny ERC-20](/developers/docs/standards/tokens/erc-20/).
+W ramach tego inteligentnego kontraktu stworzymy prostą, przykładową, zdecentralizowaną giełdę, na której użytkownik może wymieniać ether na nasz nowo wdrożony [token ERC-20](/developers/docs/standards/tokens/erc-20/).
-W tym samouczku użyjemy kodu, który napisaliśmy w poprzednim samouczku jako podstawy. Nasz DEX utworzy instancjr kontraktu w konstruktorze i wykona operacje:
+W tym samouczku użyjemy kodu, który napisaliśmy w poprzednim samouczku jako podstawy. Nasz DEX utworzy instancję kontraktu w swoim konstruktorze i wykona następujące operacje:
- wymiana tokenów na ether
- wymiana etheru na tokeny
-Rozpoczniemy nasz zdecentralizowany kod wymiany poprzez dodanie naszej prostej bazy kodowej ERC20:
+Pracę nad kodem naszej zdecentralizowanej giełdy rozpoczniemy od dodania prostej bazy kodu ERC20:
```solidity
-pragma solidity ^0.6.0;
+pragma solidity ^0.8.0;
interface IERC20 {
@@ -53,24 +48,19 @@ contract ERC20Basic is IERC20 {
uint8 public constant decimals = 18;
- event Approval(address indexed tokenOwner, address indexed spender, uint tokens);
- event Transfer(address indexed from, address indexed to, uint tokens);
-
-
mapping(address => uint256) balances;
mapping(address => mapping (address => uint256)) allowed;
- uint256 totalSupply_ = 100 ether;
+ uint256 totalSupply_ = 10 ether;
- using SafeMath for uint256;
- constructor(uint256 total) public {
- balances[msg.sender] = totalSupply_;
+ constructor() {
+ balances[msg.sender] = totalSupply_;
}
function totalSupply() public override view returns (uint256) {
- return totalSupply_;
+ return totalSupply_;
}
function balanceOf(address tokenOwner) public override view returns (uint256) {
@@ -79,8 +69,8 @@ contract ERC20Basic is IERC20 {
function transfer(address receiver, uint256 numTokens) public override returns (bool) {
require(numTokens <= balances[msg.sender]);
- balances[msg.sender] = balances[msg.sender].sub(numTokens);
- balances[receiver] = balances[receiver].add(numTokens);
+ balances[msg.sender] = balances[msg.sender]-numTokens;
+ balances[receiver] = balances[receiver]+numTokens;
emit Transfer(msg.sender, receiver, numTokens);
return true;
}
@@ -99,29 +89,18 @@ contract ERC20Basic is IERC20 {
require(numTokens <= balances[owner]);
require(numTokens <= allowed[owner][msg.sender]);
- balances[owner] = balances[owner].sub(numTokens);
- allowed[owner][msg.sender] = allowed[owner][msg.sender].sub(numTokens);
- balances[buyer] = balances[buyer].add(numTokens);
+ balances[owner] = balances[owner]-numTokens;
+ allowed[owner][msg.sender] = allowed[owner][msg.sender]-numTokens;
+ balances[buyer] = balances[buyer]+numTokens;
emit Transfer(owner, buyer, numTokens);
return true;
}
}
-library SafeMath {
- function sub(uint256 a, uint256 b) internal pure returns (uint256) {
- assert(b <= a);
- return a - b;
- }
- function add(uint256 a, uint256 b) internal pure returns (uint256) {
- uint256 c = a + b;
- assert(c >= a);
- return c;
- }
-}
```
-Nasz nowy inteligentny kontrakt DEX wdroży ERC-20 i otrzyma wszystkie dostarczone:
+Nasz nowy inteligentny kontrakt DEX wdroży token ERC-20 i otrzyma całą jego podaż:
```solidity
contract DEX {
@@ -131,78 +110,102 @@ contract DEX {
event Bought(uint256 amount);
event Sold(uint256 amount);
- constructor() public {
+ constructor() {
token = new ERC20Basic();
}
function buy() payable public {
- // TODO
+ // DO ZROBIENIA
}
function sell(uint256 amount) public {
- // TODO
+ // DO ZROBIENIA
}
}
```
-Więc wiemy, że mamy nasz DEX i ma całą dostępną rezerwę tokenów. Kontrakt spełnia dwie funkcje:
+Więc teraz mamy nasz DEX, który posiada całą dostępną rezerwę tokenów. Kontrakt ma dwie funkcje:
-- `buy`: użytkownik może wysyłać ether i otrzymywać tokeny w zamian
-- `sell`: użytkownik może zdecydować się na wysłanie tokenów, aby odzyskać ether
+- `buy`: użytkownik może wysyłać ether i otrzymywać w zamian tokeny
+- `sell`: użytkownik może wysłać tokeny, aby odzyskać ether
-## Funkcja kupna {#the-buy-function}
+## Funkcja `buy` {#the-buy-function}
-Zakodujmy funkcję kup. Najpierw będziemy musieli sprawdzić ilość etheru w wiadomości i sprawdzić, czy kontrakty posiadają wystarczającą ilość tokenów i czy wiadomość ma w niej jakiś eter. cJeśli kontrakt posiada wystarczającą ilość tokenów, wyśle liczbę tokenów do użytkownika i wyemituje zdarzenie `Bought`.
+Zakodujmy funkcję `buy`. Najpierw będziemy musieli sprawdzić ilość etheru zawartą w komunikacie i zweryfikować, czy kontrakt posiada wystarczającą liczbę tokenów oraz czy komunikat zawiera jakąś ilość etheru. Jeśli kontrakt posiada wystarczającą liczbę tokenów, wyśle on odpowiednią liczbę tokenów do użytkownika i wyemituje zdarzenie `Bought`.
-Zauważ, że jeśli wywołamy wymagającą funkcję w przypadku błędu, ether wysłany zostanie bezpośrednio przywrócony i odesłany do użytkownika.
+Zwróć uwagę, że jeśli w przypadku błędu wywołamy funkcję `require`, wysłany ether zostanie natychmiast zwrócony do użytkownika.
-Aby uprościć sprawę, po prostu wymieniamy 1 token na 1 eter.
+Dla uproszczenia wymieniamy 1 token na 1 wei.
```solidity
function buy() payable public {
uint256 amountTobuy = msg.value;
uint256 dexBalance = token.balanceOf(address(this));
- require(amountTobuy > 0, "You need to send some ether");
- require(amountTobuy <= dexBalance, "Not enough tokens in the reserve");
+ require(amountTobuy > 0, "Musisz wysłać trochę etheru");
+ require(amountTobuy <= dexBalance, "Niewystarczająca liczba tokenów w rezerwie");
token.transfer(msg.sender, amountTobuy);
emit Bought(amountTobuy);
}
```
-Jeśli zakup zakończył się sukcesem, powinniśmy zobaczyć dwa zdarzenia w transakcji: Token `Transfer` i `Bought` wydarzenie.
+W przypadku pomyślnego zakupu powinniśmy zobaczyć w transakcji dwa zdarzenia: `Transfer` tokena oraz zdarzenie `Bought`.
-## Funkcja kupna {#the-sell-function}
+## Funkcja `sell` {#the-sell-function}
+
+Funkcja odpowiedzialna za sprzedaż (`sell`) będzie w pierwszej kolejności wymagać od użytkownika zatwierdzenia kwoty poprzez wcześniejsze wywołanie funkcji `approve`. Zatwierdzenie transferu wymaga od użytkownika wywołania funkcji na instancji tokena ERC20Basic utworzonej przez DEX. Można to osiągnąć, najpierw wywołując funkcję `token()` kontraktu DEX, aby pobrać adres, pod którym kontrakt DEX wdrożył kontrakt ERC20Basic. Następnie tworzymy instancję tego kontraktu w naszej sesji i wywołujemy jego funkcję `approve`. Następnie możemy wywołać funkcję `sell` kontraktu DEX i wymienić nasze tokeny z powrotem na ether. Na przykład tak to wygląda w interaktywnej sesji brownie:
+
+```python
+#### Python w interaktywnej konsoli brownie...
+
+# wdróż DEX
+dex = DEX.deploy({'from':account1})
+
+# wywołaj funkcję buy, aby wymienić ether na tokeny
+# 1e18 to 1 ether wyrażony w wei
+dex.buy({'from': account2, 1e18})
-Funkcja odpowiedzialna za sprzedaż będzie najpierw wymagała od użytkownika zatwierdzenia kwoty poprzez uprzednie wywołanie zatwierdzonej funkcji. Następnie, gdy funkcja sprzedaży jest uruchomiona, sprawdzimy, czy przelew z adresu dzwoniącego na adres umowy zakończył się sukcesem, a następnie wyślemy Ethers z powrotem na adres dzwoniącego.
+# pobierz adres wdrożenia tokena ERC20,
+# który został wdrożony podczas tworzenia kontraktu DEX
+# dex.token() zwraca adres wdrożonego tokena
+token = ERC20Basic.at(dex.token())
+
+# wywołaj funkcję approve tokena
+# zatwierdź adres dex jako 'spendera' (wydającego)
+# i określ, ile Twoich tokenów może on wydać
+token.approve(dex.address, 3e18, {'from':account2})
+
+```
+
+Następnie, po wywołaniu funkcji `sell`, sprawdzimy, czy transfer z adresu wywołującego na adres kontraktu powiódł się, a następnie odeślemy ether z powrotem na adres wywołującego.
```solidity
function sell(uint256 amount) public {
- require(amount > 0, "You need to sell at least some tokens");
+ require(amount > 0, "Musisz sprzedać co najmniej jakąś liczbę tokenów");
uint256 allowance = token.allowance(msg.sender, address(this));
- require(allowance >= amount, "Check the token allowance");
+ require(allowance >= amount, "Sprawdź przydział tokenów");
token.transferFrom(msg.sender, address(this), amount);
- msg.sender.transfer(amount);
+ payable(msg.sender).transfer(amount);
emit Sold(amount);
}
```
-Jeśli wszystko działa, powinieneś zobaczyć 2 zdarzenia w transakcji (a `Transfer` i `Sold`) i Twoje saldo tokenu i saldo Ethereum zaktualizowane.
+Jeśli wszystko zadziała poprawnie, w transakcji powinny być widoczne 2 zdarzenia (`Transfer` i `Sold`), a salda tokenów i etheru zostaną zaktualizowane.
-
+
][]` (lub odwrotnie).
+
+Druga zmienna, `allPairs`, to tablica, która zawiera wszystkie adresy giełd par utworzonych przez tę fabrykę. W Ethereum nie można iterować po zawartości mapowania ani uzyskać listy wszystkich kluczy, więc ta zmienna jest jedynym sposobem, aby wiedzieć, którymi giełdami zarządza ta fabryka.
+
+Uwaga: Powodem, dla którego nie można iterować po wszystkich kluczach mapowania, jest to, że przechowywanie danych kontraktu jest _drogie_, więc im mniej go używamy, tym lepiej, i im rzadziej je zmieniamy, tym lepiej. Można tworzyć [mapowania, które obsługują iterację](https://github.com/ethereum/dapp-bin/blob/master/library/iterable_mapping.sol), ale wymagają one dodatkowej pamięci masowej na listę kluczy. W większości aplikacji nie jest to potrzebne.
+
+```solidity
+ event PairCreated(address indexed token0, address indexed token1, address pair, uint);
+```
+
+To zdarzenie jest emitowane, gdy tworzona jest nowa giełda par. Obejmuje ono adresy tokenów, adres giełdy par i całkowitą liczbę giełd zarządzanych przez fabrykę.
+
+```solidity
+ constructor(address _feeToSetter) public {
+ feeToSetter = _feeToSetter;
+ }
+```
+
+Jedyną rzeczą, jaką robi konstruktor, jest określenie `feeToSetter`. Fabryki zaczynają bez opłaty i tylko `feeSetter` może to zmienić.
+
+```solidity
+ function allPairsLength() external view returns (uint) {
+ return allPairs.length;
+ }
+```
+
+Ta funkcja zwraca liczbę par giełdowych.
+
+```solidity
+ function createPair(address tokenA, address tokenB) external returns (address pair) {
+```
+
+Jest to główna funkcja fabryki, tworząca giełdę par między dwoma tokenami ERC-20. Zauważ, że każdy może wywołać tę funkcję. Nie potrzebujesz pozwolenia od Uniswap, aby utworzyć nową giełdę par.
+
+```solidity
+ require(tokenA != tokenB, 'UniswapV2: IDENTICAL_ADDRESSES');
+ (address token0, address token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA);
+```
+
+Chcemy, aby adres nowej giełdy był deterministyczny, aby można go było obliczyć z góry poza łańcuchem (może to być przydatne w przypadku [transakcji warstwy 2](/developers/docs/scaling/)).
+Aby to zrobić, musimy mieć spójną kolejność adresów tokenów, niezależnie od kolejności, w jakiej je otrzymaliśmy, więc sortujemy je tutaj.
+
+```solidity
+ require(token0 != address(0), 'UniswapV2: ZERO_ADDRESS');
+ require(getPair[token0][token1] == address(0), 'UniswapV2: PAIR_EXISTS'); // single check is sufficient
+```
+
+Duże pule płynności są lepsze niż małe, ponieważ mają bardziej stabilne ceny. Nie chcemy mieć więcej niż jednej puli płynności na parę tokenów. Jeśli giełda już istnieje, nie ma potrzeby tworzenia kolejnej dla tej samej pary.
+
+```solidity
+ bytes memory bytecode = type(UniswapV2Pair).creationCode;
+```
+
+Aby utworzyć nowy kontrakt, potrzebujemy kodu, który go tworzy (zarówno funkcji konstruktora, jak i kodu, który zapisuje w pamięci kod bajtowy EVM właściwego kontraktu). Zazwyczaj w Solidity używamy po prostu `addr = new ()`, a kompilator zajmuje się wszystkim za nas, ale aby mieć deterministyczny adres kontraktu, musimy użyć [kodu operacyjnego CREATE2](https://eips.ethereum.org/EIPS/eip-1014).
+Kiedy ten kod był pisany, ten kod operacyjny nie był jeszcze obsługiwany przez Solidity, więc konieczne było ręczne pobranie kodu. To już nie jest problemem, ponieważ [Solidity teraz obsługuje CREATE2](https://docs.soliditylang.org/en/v0.8.3/control-structures.html#salted-contract-creations-create2).
+
+```solidity
+ bytes32 salt = keccak256(abi.encodePacked(token0, token1));
+ assembly {
+ pair := create2(0, add(bytecode, 32), mload(bytecode), salt)
+ }
+```
+
+Gdy kod operacyjny nie jest jeszcze obsługiwany przez Solidity, możemy go wywołać za pomocą [asembler wbudowany](https://docs.soliditylang.org/en/v0.8.3/assembly.html).
+
+```solidity
+ IUniswapV2Pair(pair).initialize(token0, token1);
+```
+
+Wywołaj funkcję `initialize`, aby poinformować nową giełdę, jakie dwa tokeny wymienia.
+
+```solidity
+ getPair[token0][token1] = pair;
+ getPair[token1][token0] = pair; // populate mapping in the reverse direction
+ allPairs.push(pair);
+ emit PairCreated(token0, token1, pair, allPairs.length);
+```
+
+Zapisz nowe informacje o parze w zmiennych stanu i wyemituj zdarzenie, aby poinformować świat o nowej giełdzie par.
+
+```solidity
+ function setFeeTo(address _feeTo) external {
+ require(msg.sender == feeToSetter, 'UniswapV2: FORBIDDEN');
+ feeTo = _feeTo;
+ }
+
+ function setFeeToSetter(address _feeToSetter) external {
+ require(msg.sender == feeToSetter, 'UniswapV2: FORBIDDEN');
+ feeToSetter = _feeToSetter;
+ }
+}
+```
+
+Te dwie funkcje pozwalają `feeSetter` kontrolować odbiorcę opłaty (jeśli istnieje) i zmienić `feeSetter` na nowy adres.
+
+### UniswapV2ERC20.sol {#UniswapV2ERC20}
+
+[Ten kontrakt](https://github.com/Uniswap/uniswap-v2-core/blob/master/contracts/UniswapV2ERC20.sol) implementuje token płynności ERC-20. Jest podobny do [kontraktu OpenZeppelin ERC-20](/developers/tutorials/erc20-annotated-code), więc wyjaśnię tylko tę część, która jest inna, funkcjonalność `permit`.
+
+Transakcje w Ethereum kosztują ether (ETH), który jest równowartością prawdziwych pieniędzy. Jeśli masz tokeny ERC-20, ale nie masz ETH, nie możesz wysyłać transakcji, więc nie możesz nic z nimi zrobić. Jednym z rozwiązań tego problemu są [metatransakcje](https://docs.uniswap.org/contracts/v2/guides/smart-contract-integration/supporting-meta-transactions).
+Właściciel tokenów podpisuje transakcję, która pozwala komuś innemu wypłacić tokeny poza łańcuchem i wysyła ją przez Internet do odbiorcy. Odbiorca, który ma ETH, następnie składa pozwolenie w imieniu właściciela.
+
+```solidity
+ bytes32 public DOMAIN_SEPARATOR;
+ // keccak256("Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)");
+ bytes32 public constant PERMIT_TYPEHASH = 0x6e71edae12b1b97f4d1f60370fef10105fa2faae0126114a169c64845d6126c9;
+```
+
+Ten hasz jest [identyfikatorem typu transakcji](https://eips.ethereum.org/EIPS/eip-712#rationale-for-typehash). Jedynym, który tu obsługujemy, jest `Permit` z tymi parametrami.
+
+```solidity
+ mapping(address => uint) public nonces;
+```
+
+Sfałszowanie podpisu cyfrowego przez odbiorcę jest niewykonalne. Jednak trywialne jest dwukrotne wysłanie tej samej transakcji (jest to forma [ataku typu replay](https://wikipedia.org/wiki/Replay_attack)). Aby temu zapobiec, używamy [nonce](https://wikipedia.org/wiki/Cryptographic_nonce). Jeśli nonce nowego `Permit` nie jest o jeden większy niż ostatnio użyty, zakładamy, że jest on nieważny.
+
+```solidity
+ constructor() public {
+ uint chainId;
+ assembly {
+ chainId := chainid
+ }
+```
+
+Jest to kod do pobrania [identyfikatora łańcucha](https://chainid.network/). Używa dialektu asemblera EVM o nazwie [Yul](https://docs.soliditylang.org/en/v0.8.4/yul.html). Zauważ, że w bieżącej wersji Yul musisz używać `chainid()`, a nie `chainid`.
+
+```solidity
+ DOMAIN_SEPARATOR = keccak256(
+ abi.encode(
+ keccak256('EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)'),
+ keccak256(bytes(name)),
+ keccak256(bytes('1')),
+ chainId,
+ address(this)
+ )
+ );
+ }
+```
+
+Oblicz [separator domeny](https://eips.ethereum.org/EIPS/eip-712#rationale-for-domainseparator) dla EIP-712.
+
+```solidity
+ function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external {
+```
+
+Jest to funkcja, która implementuje uprawnienia. Otrzymuje jako parametry odpowiednie pola oraz trzy wartości skalarne dla [podpisu](https://yos.io/2018/11/16/ethereum-signatures/) (v, r i s).
+
+```solidity
+ require(deadline >= block.timestamp, 'UniswapV2: EXPIRED');
+```
+
+Nie akceptuj transakcji po terminie.
+
+```solidity
+ bytes32 digest = keccak256(
+ abi.encodePacked(
+ '\x19\x01',
+ DOMAIN_SEPARATOR,
+ keccak256(abi.encode(PERMIT_TYPEHASH, owner, spender, value, nonces[owner]++, deadline))
+ )
+ );
+```
+
+`abi.encodePacked(...)` to komunikat, którego oczekujemy. Wiemy, jakie powinno być nonce, więc nie ma potrzeby, abyśmy otrzymywali je jako parametr.
+
+Algorytm podpisu Ethereum oczekuje do podpisania 256 bitów, więc używamy funkcji haszującej `keccak256`.
+
+```solidity
+ address recoveredAddress = ecrecover(digest, v, r, s);
+```
+
+Z digestu i podpisu możemy uzyskać adres, który go podpisał, używając [ecrecover](https://coders-errand.com/ecrecover-signature-verification-ethereum/).
+
+```solidity
+ require(recoveredAddress != address(0) && recoveredAddress == owner, 'UniswapV2: INVALID_SIGNATURE');
+ _approve(owner, spender, value);
+ }
+
+```
+
+Jeśli wszystko jest w porządku, traktuj to jako [zatwierdzenie ERC-20](https://eips.ethereum.org/EIPS/eip-20#approve).
+
+## Kontrakty peryferyjne {#periphery-contracts}
+
+Kontrakty peryferyjne to API (interfejs programowania aplikacji) dla Uniswap. Są one dostępne dla wywołań zewnętrznych, zarówno z innych kontraktów, jak i ze zdecentralizowanych aplikacji. Można by wywoływać kontrakty główne bezpośrednio, ale jest to bardziej skomplikowane i można stracić wartość, jeśli popełni się błąd. Kontrakty główne zawierają tylko testy, aby upewnić się, że nie są oszukiwane, a nie kontrole poprawności dla nikogo innego. Te są w peryferiach, więc można je aktualizować w razie potrzeby.
+
+### UniswapV2Router01.sol {#UniswapV2Router01}
+
+[Ten kontrakt](https://github.com/Uniswap/uniswap-v2-periphery/blob/master/contracts/UniswapV2Router01.sol) ma problemy i [nie powinien być już używany](https://docs.uniswap.org/contracts/v2/reference/smart-contracts/router-01). Na szczęście kontrakty peryferyjne są bezstanowe i nie przechowują żadnych aktywów, więc łatwo jest je wycofać i zasugerować ludziom, aby zamiast tego używali zamiennika, `UniswapV2Router02`.
+
+### UniswapV2Router02.sol {#UniswapV2Router02}
+
+W większości przypadków używałbyś Uniswap za pośrednictwem [tego kontraktu](https://github.com/Uniswap/uniswap-v2-periphery/blob/master/contracts/UniswapV2Router02.sol).
+Możesz zobaczyć, jak go używać [tutaj](https://docs.uniswap.org/contracts/v2/reference/smart-contracts/router-02).
+
+```solidity
+pragma solidity =0.6.6;
+
+import '@uniswap/v2-core/contracts/interfaces/IUniswapV2Factory.sol';
+import '@uniswap/lib/contracts/libraries/TransferHelper.sol';
+
+import './interfaces/IUniswapV2Router02.sol';
+import './libraries/UniswapV2Library.sol';
+import './libraries/SafeMath.sol';
+import './interfaces/IERC20.sol';
+import './interfaces/IWETH.sol';
+```
+
+Większość z nich spotkaliśmy już wcześniej lub są dość oczywiste. Jedynym wyjątkiem jest `IWETH.sol`. Uniswap v2 pozwala na wymianę dowolnej pary tokenów ERC-20, ale sam ether (ETH) nie jest tokenem ERC-20. Poprzedza on standard i jest transferowany za pomocą unikalnych mechanizmów. Aby umożliwić wykorzystanie ETH w kontraktach, które dotyczą tokenów ERC-20, ludzie wymyślili kontrakt [opakowanego etheru (WETH)](https://weth.tkn.eth.limo/). Wysyłasz do tego kontraktu ETH, a on wybija Ci równoważną ilość WETH. Możesz też spalić WETH i odzyskać ETH.
+
+```solidity
+contract UniswapV2Router02 is IUniswapV2Router02 {
+ using SafeMath for uint;
+
+ address public immutable override factory;
+ address public immutable override WETH;
+```
+
+Router musi wiedzieć, jakiej fabryki użyć, a dla transakcji, które wymagają WETH, jakiego kontraktu WETH użyć. Te wartości są [niezmienne](https://docs.soliditylang.org/en/v0.8.3/contracts.html#constant-and-immutable-state-variables), co oznacza, że można je ustawić tylko w konstruktorze. Daje to użytkownikom pewność, że nikt nie będzie w stanie ich zmienić, aby wskazywały na mniej uczciwe kontrakty.
+
+```solidity
+ modifier ensure(uint deadline) {
+ require(deadline >= block.timestamp, 'UniswapV2Router: EXPIRED');
+ _;
+ }
+```
+
+Ten modyfikator zapewnia, że transakcje o ograniczonym czasie („zrób X przed czasem Y, jeśli możesz”) nie mają miejsca po upływie ich terminu.
+
+```solidity
+ constructor(address _factory, address _WETH) public {
+ factory = _factory;
+ WETH = _WETH;
+ }
+```
+
+Konstruktor ustawia tylko niezmienne zmienne stanu.
+
+```solidity
+ receive() external payable {
+ assert(msg.sender == WETH); // only accept ETH via fallback from the WETH contract
+ }
+```
+
+Ta funkcja jest wywoływana, gdy wymieniamy tokeny z kontraktu WETH z powrotem na ETH. Tylko kontrakt WETH, którego używamy, jest do tego upoważniony.
+
+#### Dodaj płynność {#add-liquidity}
+
+Te funkcje dodają tokeny do giełdy par, co zwiększa pulę płynności.
+
+```solidity
+
+ // **** ADD LIQUIDITY ****
+ function _addLiquidity(
+```
+
+Ta funkcja służy do obliczania ilości tokenów A i B, które powinny zostać zdeponowane na giełdzie par.
+
+```solidity
+ address tokenA,
+ address tokenB,
+```
+
+Są to adresy kontraktów tokenów ERC-20.
+
+```solidity
+ uint amountADesired,
+ uint amountBDesired,
+```
+
+Są to kwoty, które dostawca płynności chce zdeponować. Są to również maksymalne kwoty A i B do zdeponowania.
+
+```solidity
+ uint amountAMin,
+ uint amountBMin
+```
+
+Są to minimalne dopuszczalne kwoty do zdeponowania. Jeśli transakcja nie może się odbyć z tymi kwotami lub większymi, wycofaj się z niej. Jeśli nie chcesz tej funkcji, po prostu podaj zero.
+
+Dostawcy płynności określają minimum, zazwyczaj dlatego, że chcą ograniczyć transakcję do kursu wymiany zbliżonego do bieżącego. Jeśli kurs wymiany zbytnio się waha, może to oznaczać wiadomości, które zmieniają podstawowe wartości, a oni chcą ręcznie zdecydować, co robić.
+
+Na przykład wyobraź sobie przypadek, w którym kurs wymiany wynosi jeden do jednego, a dostawca płynności określa te wartości:
+
+| Parametr | Wartość |
+| -------------- | ------: |
+| amountADesired | 1000 |
+| amountBDesired | 1000 |
+| amountAMin | 900 |
+| amountBMin | 800 |
+
+Dopóki kurs wymiany pozostaje między 0,9 a 1,25, transakcja ma miejsce. Jeśli kurs wymiany wyjdzie poza ten zakres, transakcja zostanie anulowana.
+
+Powodem tego środka ostrożności jest to, że transakcje nie są natychmiastowe, przesyłasz je i ostatecznie walidator uwzględni je w bloku (chyba że cena gazu jest bardzo niska, w którym to przypadku będziesz musiał przesłać kolejną transakcję z tym samym nonce i wyższą ceną gazu, aby ją nadpisać). Nie możesz kontrolować tego, co dzieje się w okresie między złożeniem a włączeniem.
+
+```solidity
+ ) internal virtual returns (uint amountA, uint amountB) {
+```
+
+Funkcja zwraca kwoty, które dostawca płynności powinien zdeponować, aby mieć stosunek równy bieżącemu stosunkowi między rezerwami.
+
+```solidity
+ // create the pair if it doesn't exist yet
+ if (IUniswapV2Factory(factory).getPair(tokenA, tokenB) == address(0)) {
+ IUniswapV2Factory(factory).createPair(tokenA, tokenB);
+ }
+```
+
+Jeśli nie ma jeszcze giełdy dla tej pary tokenów, utwórz ją.
+
+```solidity
+ (uint reserveA, uint reserveB) = UniswapV2Library.getReserves(factory, tokenA, tokenB);
+```
+
+Pobierz bieżące rezerwy w parze.
+
+```solidity
+ if (reserveA == 0 && reserveB == 0) {
+ (amountA, amountB) = (amountADesired, amountBDesired);
+```
+
+Jeśli bieżące rezerwy są puste, to jest to nowa giełda par. Kwoty do zdeponowania powinny być dokładnie takie same, jak te, które chce dostarczyć dostawca płynności.
+
+```solidity
+ } else {
+ uint amountBOptimal = UniswapV2Library.quote(amountADesired, reserveA, reserveB);
+```
+
+Jeśli musimy zobaczyć, jakie będą kwoty, otrzymujemy optymalną kwotę za pomocą [tej funkcji](https://github.com/Uniswap/uniswap-v2-periphery/blob/master/contracts/libraries/UniswapV2Library.sol#L35). Chcemy tego samego stosunku co bieżące rezerwy.
+
+```solidity
+ if (amountBOptimal <= amountBDesired) {
+ require(amountBOptimal >= amountBMin, 'UniswapV2Router: INSUFFICIENT_B_AMOUNT');
+ (amountA, amountB) = (amountADesired, amountBOptimal);
+```
+
+Jeśli `amountBOptimal` jest mniejsza niż kwota, którą dostawca płynności chce zdeponować, oznacza to, że token B jest obecnie bardziej wartościowy, niż myśli deponent płynności, więc wymagana jest mniejsza kwota.
+
+```solidity
+ } else {
+ uint amountAOptimal = UniswapV2Library.quote(amountBDesired, reserveB, reserveA);
+ assert(amountAOptimal <= amountADesired);
+ require(amountAOptimal >= amountAMin, 'UniswapV2Router: NIEWYSTARCZAJĄCA_ILOŚĆ_A');
+ (amountA, amountB) = (amountAOptimal, amountBDesired);
+```
+
+Jeśli optymalna kwota B jest większa niż pożądana kwota B, oznacza to, że tokeny B są obecnie mniej wartościowe, niż myśli deponent płynności, więc wymagana jest wyższa kwota. Jednak pożądana kwota jest maksimum, więc nie możemy tego zrobić. Zamiast tego obliczamy optymalną liczbę tokenów A dla pożądanej ilości tokenów B.
+
+Łącząc wszystko razem, otrzymujemy ten wykres. Załóżmy, że próbujesz zdeponować tysiąc tokenów A (niebieska linia) i tysiąc tokenów B (czerwona linia). Oś x to kurs wymiany, A/B. Jeśli x=1, mają równą wartość i wpłacasz po tysiąc każdego. Jeśli x=2, A ma dwukrotnie większą wartość niż B (otrzymujesz dwa tokeny B za każdy token A), więc wpłacasz tysiąc tokenów B, ale tylko 500 tokenów A. Jeśli x=0,5, sytuacja jest odwrotna, tysiąc tokenów A i pięćset tokenów B.
+
+
+
+Można zdeponować płynność bezpośrednio w kontrakcie głównym (używając [UniswapV2Pair::mint](https://github.com/Uniswap/uniswap-v2-core/blob/master/contracts/UniswapV2Pair.sol#L110)), ale kontrakt główny sprawdza tylko, czy sam nie jest oszukiwany, więc ryzykujesz utratę wartości, jeśli kurs wymiany zmieni się między czasem złożenia transakcji a czasem jej wykonania. Jeśli używasz kontraktu peryferyjnego, oblicza on kwotę, którą powinieneś wpłacić, i wpłaca ją natychmiast, więc kurs wymiany się nie zmienia i nic nie tracisz.
+
+```solidity
+ function addLiquidity(
+ address tokenA,
+ address tokenB,
+ uint amountADesired,
+ uint amountBDesired,
+ uint amountAMin,
+ uint amountBMin,
+ address to,
+ uint deadline
+```
+
+Ta funkcja może być wywoływana przez transakcję w celu zdeponowania płynności. Większość parametrów jest taka sama jak w `_addLiquidity` powyżej, z dwoma wyjątkami:
+
+. `to` to adres, który otrzymuje nowe tokeny płynności wybite, aby pokazać udział dostawcy płynności w puli
+. `deadline` to limit czasowy transakcji
+
+```solidity
+ ) external virtual override ensure(deadline) returns (uint amountA, uint amountB, uint liquidity) {
+ (amountA, amountB) = _addLiquidity(tokenA, tokenB, amountADesired, amountBDesired, amountAMin, amountBMin);
+ address pair = UniswapV2Library.pairFor(factory, tokenA, tokenB);
+```
+
+Obliczamy kwoty do faktycznego zdeponowania, a następnie znajdujemy adres puli płynności. Aby zaoszczędzić gaz, nie robimy tego, pytając fabryki, ale używając funkcji bibliotecznej `pairFor` (patrz poniżej w bibliotekach)
+
+```solidity
+ TransferHelper.safeTransferFrom(tokenA, msg.sender, pair, amountA);
+ TransferHelper.safeTransferFrom(tokenB, msg.sender, pair, amountB);
+```
+
+Przenieś odpowiednie ilości tokenów od użytkownika na giełdę par.
+
+```solidity
+ liquidity = IUniswapV2Pair(pair).mint(to);
+ }
+```
+
+W zamian przekaż na adres `to` tokeny płynności za częściową własność puli. Funkcja `mint` kontraktu głównego sprawdza, ile dodatkowych tokenów posiada (w porównaniu z tym, co miała ostatnim razem, gdy płynność się zmieniła) i odpowiednio wybija płynność.
+
+```solidity
+ function addLiquidityETH(
+ address token,
+ uint amountTokenDesired,
+```
+
+Gdy dostawca płynności chce zapewnić płynność dla giełdy par Token/ETH, jest kilka różnic. Kontrakt obsługuje opakowywanie ETH dla dostawcy płynności. Nie ma potrzeby określania, ile ETH użytkownik chce zdeponować, ponieważ użytkownik po prostu wysyła je z transakcją (kwota jest dostępna w `msg.value`).
+
+```solidity
+ uint amountTokenMin,
+ uint amountETHMin,
+ address to,
+ uint deadline
+ ) external virtual override payable ensure(deadline) returns (uint amountToken, uint amountETH, uint liquidity) {
+ (amountToken, amountETH) = _addLiquidity(
+ token,
+ WETH,
+ amountTokenDesired,
+ msg.value,
+ amountTokenMin,
+ amountETHMin
+ );
+ address pair = UniswapV2Library.pairFor(factory, token, WETH);
+ TransferHelper.safeTransferFrom(token, msg.sender, pair, amountToken);
+ IWETH(WETH).deposit{value: amountETH}();
+ assert(IWETH(WETH).transfer(pair, amountETH));
+```
+
+Aby zdeponować ETH, kontrakt najpierw opakowuje je w WETH, a następnie transferuje WETH do pary. Zauważ, że transfer jest opakowany w `assert`. Oznacza to, że jeśli transfer się nie powiedzie, to wywołanie kontraktu również się nie powiedzie, a zatem opakowanie tak naprawdę się nie odbywa.
+
+```solidity
+ liquidity = IUniswapV2Pair(pair).mint(to);
+ // refund dust eth, if any
+ if (msg.value > amountETH) TransferHelper.safeTransferETH(msg.sender, msg.value - amountETH);
+ }
+```
+
+Użytkownik już wysłał nam ETH, więc jeśli zostanie jakaś nadwyżka (ponieważ drugi token jest mniej wartościowy, niż myślał użytkownik), musimy dokonać zwrotu.
+
+#### Usuń płynność {#remove-liquidity}
+
+Te funkcje usuną płynność i zwrócą pieniądze dostawcy płynności.
+
+```solidity
+ // **** REMOVE LIQUIDITY ****
+ function removeLiquidity(
+ address tokenA,
+ address tokenB,
+ uint liquidity,
+ uint amountAMin,
+ uint amountBMin,
+ address to,
+ uint deadline
+ ) public virtual override ensure(deadline) returns (uint amountA, uint amountB) {
+```
+
+Najprostszy przypadek usunięcia płynności. Istnieje minimalna ilość każdego tokena, którą dostawca płynności zgadza się zaakceptować, i musi to nastąpić przed terminem.
+
+```solidity
+ address pair = UniswapV2Library.pairFor(factory, tokenA, tokenB);
+ IUniswapV2Pair(pair).transferFrom(msg.sender, pair, liquidity); // send liquidity to pair
+ (uint amount0, uint amount1) = IUniswapV2Pair(pair).burn(to);
+```
+
+Funkcja `burn` kontraktu głównego obsługuje zwrot tokenów użytkownikowi.
+
+```solidity
+ (address token0,) = UniswapV2Library.sortTokens(tokenA, tokenB);
+```
+
+Gdy funkcja zwraca wiele wartości, ale interesują nas tylko niektóre z nich, w ten sposób uzyskujemy tylko te wartości. Jest to nieco tańsze pod względem gazu niż odczytanie wartości i nigdy jej nieużywanie.
+
+```solidity
+ (amountA, amountB) = tokenA == token0 ? (amount0, amount1) : (amount1, amount0);
+```
+
+Przetłumacz kwoty ze sposobu, w jaki zwraca je kontrakt główny (najpierw token o niższym adresie) na sposób, w jaki oczekuje ich użytkownik (odpowiadający `tokenA` i `tokenB`).
+
+```solidity
+ require(amountA >= amountAMin, 'UniswapV2Router: INSUFFICIENT_A_AMOUNT');
+ require(amountB >= amountBMin, 'UniswapV2Router: INSUFFICIENT_B_AMOUNT');
+ }
+```
+
+Można najpierw dokonać transferu, a następnie zweryfikować jego legalność, ponieważ jeśli nie jest legalny, wycofamy się ze wszystkich zmian stanu.
+
+```solidity
+ function removeLiquidityETH(
+ address token,
+ uint liquidity,
+ uint amountTokenMin,
+ uint amountETHMin,
+ address to,
+ uint deadline
+ ) public virtual override ensure(deadline) returns (uint amountToken, uint amountETH) {
+ (amountToken, amountETH) = removeLiquidity(
+ token,
+ WETH,
+ liquidity,
+ amountTokenMin,
+ amountETHMin,
+ address(this),
+ deadline
+ );
+ TransferHelper.safeTransfer(token, to, amountToken);
+ IWETH(WETH).withdraw(amountETH);
+ TransferHelper.safeTransferETH(to, amountETH);
+ }
+```
+
+Usunięcie płynności dla ETH jest prawie takie samo, z tym wyjątkiem, że otrzymujemy tokeny WETH, a następnie wymieniamy je na ETH, aby oddać je dostawcy płynności.
+
+```solidity
+ function removeLiquidityWithPermit(
+ address tokenA,
+ address tokenB,
+ uint liquidity,
+ uint amountAMin,
+ uint amountBMin,
+ address to,
+ uint deadline,
+ bool approveMax, uint8 v, bytes32 r, bytes32 s
+ ) external virtual override returns (uint amountA, uint amountB) {
+ address pair = UniswapV2Library.pairFor(factory, tokenA, tokenB);
+ uint value = approveMax ? uint(-1) : liquidity;
+ IUniswapV2Pair(pair).permit(msg.sender, address(this), value, deadline, v, r, s);
+ (amountA, amountB) = removeLiquidity(tokenA, tokenB, liquidity, amountAMin, amountBMin, to, deadline);
+ }
+
+
+ function removeLiquidityETHWithPermit(
+ address token,
+ uint liquidity,
+ uint amountTokenMin,
+ uint amountETHMin,
+ address to,
+ uint deadline,
+ bool approveMax, uint8 v, bytes32 r, bytes32 s
+ ) external virtual override returns (uint amountToken, uint amountETH) {
+ address pair = UniswapV2Library.pairFor(factory, token, WETH);
+ uint value = approveMax ? uint(-1) : liquidity;
+ IUniswapV2Pair(pair).permit(msg.sender, address(this), value, deadline, v, r, s);
+ (amountToken, amountETH) = removeLiquidityETH(token, liquidity, amountTokenMin, amountETHMin, to, deadline);
+ }
+```
+
+Te funkcje przekazują metatransakcje, aby umożliwić użytkownikom bez etheru wypłatę z puli, używając [mechanizmu pozwolenia](#UniswapV2ERC20).
+
+```solidity
+
+ // **** REMOVE LIQUIDITY (supporting fee-on-transfer tokens) ****
+ function removeLiquidityETHSupportingFeeOnTransferTokens(
+ address token,
+ uint liquidity,
+ uint amountTokenMin,
+ uint amountETHMin,
+ address to,
+ uint deadline
+ ) public virtual override ensure(deadline) returns (uint amountETH) {
+ (, amountETH) = removeLiquidity(
+ token,
+ WETH,
+ liquidity,
+ amountTokenMin,
+ amountETHMin,
+ address(this),
+ deadline
+ );
+ TransferHelper.safeTransfer(token, to, IERC20(token).balanceOf(address(this)));
+ IWETH(WETH).withdraw(amountETH);
+ TransferHelper.safeTransferETH(to, amountETH);
+ }
+
+```
+
+Tej funkcji można używać dla tokenów, które mają opłaty za transfer lub przechowywanie. Gdy token ma takie opłaty, nie możemy polegać na funkcji `removeLiquidity`, aby powiedziała nam, ile tokena odzyskamy, więc musimy najpierw wypłacić, a następnie sprawdzić saldo.
+
+```solidity
+
+
+ function removeLiquidityETHWithPermitSupportingFeeOnTransferTokens(
+ address token,
+ uint liquidity,
+ uint amountTokenMin,
+ uint amountETHMin,
+ address to,
+ uint deadline,
+ bool approveMax, uint8 v, bytes32 r, bytes32 s
+ ) external virtual override returns (uint amountETH) {
+ address pair = UniswapV2Library.pairFor(factory, token, WETH);
+ uint value = approveMax ? uint(-1) : liquidity;
+ IUniswapV2Pair(pair).permit(msg.sender, address(this), value, deadline, v, r, s);
+ amountETH = removeLiquidityETHSupportingFeeOnTransferTokens(
+ token, liquidity, amountTokenMin, amountETHMin, to, deadline
+ );
+ }
+```
+
+Ostatnia funkcja łączy opłaty za przechowywanie z meta-transakcjami.
+
+#### Handel {#trade}
+
+```solidity
+ // **** WYMIANA ****
+ // wymaga, aby początkowa kwota została już wysłana do pierwszej pary
+ function _swap(uint[] memory amounts, address[] memory path, address _to) internal virtual {
+```
+
+Ta funkcja wykonuje wewnętrzne przetwarzanie, które jest wymagane dla funkcji udostępnianych handlarzom.
+
+```solidity
+ for (uint i; i < path.length - 1; i++) {
+```
+
+W chwili, gdy to piszę, istnieje [388 160 tokenów ERC-20](https://eth.blockscout.com/tokens). Gdyby istniała wymiana dla każdej pary tokenów, byłoby to ponad 150 miliardów wymian par. Cały łańcuch w tym momencie [ma tylko 0,1% tej liczby kont](https://eth.blockscout.com/stats/accountsGrowth). Zamiast tego funkcje wymiany obsługują koncepcję ścieżki. Handlarz może wymienić A na B, B na C i C na D, więc nie ma potrzeby bezpośredniej wymiany pary A-D.
+
+Ceny na tych rynkach mają tendencję do synchronizacji, ponieważ gdy nie są zsynchronizowane, stwarza to okazję do arbitrażu. Wyobraźmy sobie na przykład trzy tokeny: A, B i C. Istnieją trzy wymiany par, po jednej dla każdej pary.
+
+1. Sytuacja początkowa
+2. Handlarz sprzedaje 24,695 tokenów A i otrzymuje 25,305 tokenów B.
+3. Handlarz sprzedaje 24,695 tokenów B za 25,305 tokenów C, zatrzymując około 0,61 tokenów B jako zysk.
+4. Następnie handlarz sprzedaje 24,695 tokenów C za 25,305 tokenów A, zatrzymując około 0,61 tokenów C jako zysk. Handlarz ma również 0,61 dodatkowych tokenów A (25,305, które handlarz otrzymuje na koniec, minus pierwotna inwestycja w wysokości 24,695).
+
+| Krok | Wymiana A-B | Wymiana B-C | Wymiana A-C |
+| ---- | ----------------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------- |
+| 1 | A:1000 B:1050 A/B=1,05 | B:1000 C:1050 B/C=1,05 | A:1050 C:1000 C/A=1,05 |
+| 2 | A:1024,695 B:1024,695 A/B=1 | B:1000 C:1050 B/C=1,05 | A:1050 C:1000 C/A=1,05 |
+| 3 | A:1024,695 B:1024,695 A/B=1 | B:1024,695 C:1024,695 B/C=1 | A:1050 C:1000 C/A=1,05 |
+| 4 | A:1024,695 B:1024,695 A/B=1 | B:1024,695 C:1024,695 B/C=1 | A:1024,695 C:1024,695 C/A=1 |
+
+```solidity
+ (address input, address output) = (path[i], path[i + 1]);
+ (address token0,) = UniswapV2Library.sortTokens(input, output);
+ uint amountOut = amounts[i + 1];
+```
+
+Pobierz parę, którą obecnie obsługujemy, posortuj ją (do użytku z parą) i pobierz oczekiwaną kwotę wyjściową.
+
+```solidity
+ (uint amount0Out, uint amount1Out) = input == token0 ? (uint(0), amountOut) : (amountOut, uint(0));
+```
+
+Pobierz oczekiwane kwoty wyjściowe, posortowane w sposób, w jaki oczekuje ich wymiana par.
+
+```solidity
+ address to = i < path.length - 2 ? UniswapV2Library.pairFor(factory, output, path[i + 2]) : _to;
+```
+
+Czy to ostatnia wymiana? Jeśli tak, wyślij tokeny otrzymane w ramach transakcji do miejsca docelowego. Jeśli nie, wyślij je do następnej wymiany par.
+
+```solidity
+
+ IUniswapV2Pair(UniswapV2Library.pairFor(factory, input, output)).swap(
+ amount0Out, amount1Out, to, new bytes(0)
+ );
+ }
+ }
+```
+
+Faktycznie wywołaj wymianę par, aby zamienić tokeny. Nie potrzebujemy wywołania zwrotnego, aby zostać poinformowanym o wymianie, więc nie wysyłamy żadnych bajtów w tym polu.
+
+```solidity
+ function swapExactTokensForTokens(
+```
+
+Ta funkcja jest używana bezpośrednio przez handlarzy do zamiany jednego tokena na inny.
+
+```solidity
+ uint amountIn,
+ uint amountOutMin,
+ address[] calldata path,
+```
+
+Ten parametr zawiera adresy kontraktów ERC-20. Jak wyjaśniono powyżej, jest to tablica, ponieważ może być konieczne przejście przez kilka wymian par, aby przejść od posiadanego zasobu do zasobu, który chcesz uzyskać.
+
+Parametr funkcji w Solidity może być przechowywany w `memory` lub `calldata`. Jeśli funkcja jest punktem wejścia do kontraktu, wywoływanym bezpośrednio przez użytkownika (za pomocą transakcji) lub z innego kontraktu, wartość parametru można pobrać bezpośrednio z danych wywołania. Jeśli funkcja jest wywoływana wewnętrznie, jak `_swap` powyżej, parametry muszą być przechowywane w `memory`. Z perspektywy wywoływanego kontraktu `calldata` jest tylko do odczytu.
+
+W przypadku typów skalarnych, takich jak `uint` lub `address`, kompilator sam wybiera dla nas sposób przechowywania, ale w przypadku tablic, które są dłuższe i droższe, to my określamy rodzaj używanego miejsca do przechowywania.
+
+```solidity
+ address to,
+ uint deadline
+ ) external virtual override ensure(deadline) returns (uint[] memory amounts) {
+```
+
+Zwracane wartości są zawsze zwracane w pamięci.
+
+```solidity
+ amounts = UniswapV2Library.getAmountsOut(factory, amountIn, path);
+ require(amounts[amounts.length - 1] >= amountOutMin, 'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT');
+```
+
+Oblicz kwotę do zakupu w każdej wymianie. Jeśli wynik jest mniejszy niż minimum, które handlarz jest gotów zaakceptować, wycofaj transakcję.
+
+```solidity
+ TransferHelper.safeTransferFrom(
+ path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]
+ );
+ _swap(amounts, path, to);
+ }
+```
+
+Na koniec przelej początkowy token ERC-20 na konto pierwszej wymiany par i wywołaj `_swap`. Wszystko to dzieje się w tej samej transakcji, więc wymiana par wie, że wszelkie nieoczekiwane tokeny są częścią tego transferu.
+
+```solidity
+ function swapTokensForExactTokens(
+ uint amountOut,
+ uint amountInMax,
+ address[] calldata path,
+ address to,
+ uint deadline
+ ) external virtual override ensure(deadline) returns (uint[] memory amounts) {
+ amounts = UniswapV2Library.getAmountsIn(factory, amountOut, path);
+ require(amounts[0] <= amountInMax, 'UniswapV2Router: EXCESSIVE_INPUT_AMOUNT');
+ TransferHelper.safeTransferFrom(
+ path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]
+ );
+ _swap(amounts, path, to);
+ }
+```
+
+Poprzednia funkcja, `swapTokensForTokens`, pozwala handlarzowi określić dokładną liczbę tokenów wejściowych, które jest gotów oddać, oraz minimalną liczbę tokenów wyjściowych, które jest gotów otrzymać w zamian. Ta funkcja wykonuje odwrotną wymianę, pozwala handlarzowi określić liczbę tokenów wyjściowych, które chce, oraz maksymalną liczbę tokenów wejściowych, które jest gotów za nie zapłacić.
+
+W obu przypadkach handlarz musi najpierw udzielić temu kontraktowi peryferyjnemu zezwolenia na ich transfer.
+
+```solidity
+ function swapExactETHForTokens(uint amountOutMin, address[] calldata path, address to, uint deadline)
+ external
+ virtual
+ override
+ payable
+ ensure(deadline)
+ returns (uint[] memory amounts)
+ {
+ require(path[0] == WETH, 'UniswapV2Router: INVALID_PATH');
+ amounts = UniswapV2Library.getAmountsOut(factory, msg.value, path);
+ require(amounts[amounts.length - 1] >= amountOutMin, 'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT');
+ IWETH(WETH).deposit{value: amounts[0]}();
+ assert(IWETH(WETH).transfer(UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]));
+ _swap(amounts, path, to);
+ }
+
+
+ function swapTokensForExactETH(uint amountOut, uint amountInMax, address[] calldata path, address to, uint deadline)
+ external
+ virtual
+ override
+ ensure(deadline)
+ returns (uint[] memory amounts)
+ {
+ require(path[path.length - 1] == WETH, 'UniswapV2Router: INVALID_PATH');
+ amounts = UniswapV2Library.getAmountsIn(factory, amountOut, path);
+ require(amounts[0] <= amountInMax, 'UniswapV2Router: EXCESSIVE_INPUT_AMOUNT');
+ TransferHelper.safeTransferFrom(
+ path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]
+ );
+ _swap(amounts, path, address(this));
+ IWETH(WETH).withdraw(amounts[amounts.length - 1]);
+ TransferHelper.safeTransferETH(to, amounts[amounts.length - 1]);
+ }
+
+
+
+ function swapExactTokensForETH(uint amountIn, uint amountOutMin, address[] calldata path, address to, uint deadline)
+ external
+ virtual
+ override
+ ensure(deadline)
+ returns (uint[] memory amounts)
+ {
+ require(path[path.length - 1] == WETH, 'UniswapV2Router: INVALID_PATH');
+ amounts = UniswapV2Library.getAmountsOut(factory, amountIn, path);
+ require(amounts[amounts.length - 1] >= amountOutMin, 'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT');
+ TransferHelper.safeTransferFrom(
+ path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]
+ );
+ _swap(amounts, path, address(this));
+ IWETH(WETH).withdraw(amounts[amounts.length - 1]);
+ TransferHelper.safeTransferETH(to, amounts[amounts.length - 1]);
+ }
+
+
+ function swapETHForExactTokens(uint amountOut, address[] calldata path, address to, uint deadline)
+ external
+ virtual
+ override
+ payable
+ ensure(deadline)
+ returns (uint[] memory amounts)
+ {
+ require(path[0] == WETH, 'UniswapV2Router: INVALID_PATH');
+ amounts = UniswapV2Library.getAmountsIn(factory, amountOut, path);
+ require(amounts[0] <= msg.value, 'UniswapV2Router: EXCESSIVE_INPUT_AMOUNT');
+ IWETH(WETH).deposit{value: amounts[0]}();
+ assert(IWETH(WETH).transfer(UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]));
+ _swap(amounts, path, to);
+ // zwróć resztę eth, jeśli istnieje
+ if (msg.value > amounts[0]) TransferHelper.safeTransferETH(msg.sender, msg.value - amounts[0]);
+ }
+```
+
+Te cztery warianty dotyczą handlu między ETH a tokenami. Jedyną różnicą jest to, że albo otrzymujemy ETH od handlarza i używamy go do wybicia WETH, albo otrzymujemy WETH z ostatniej wymiany na ścieżce i spalamy go, odsyłając handlarzowi powstałe ETH.
+
+```solidity
+ // **** WYMIANA (obsługa tokenów z opłatą za transfer) ****
+ // wymaga, aby początkowa kwota została już wysłana do pierwszej pary
+ function _swapSupportingFeeOnTransferTokens(address[] memory path, address _to) internal virtual {
+```
+
+Jest to funkcja wewnętrzna do wymiany tokenów, które mają opłaty za transfer lub przechowywanie, w celu rozwiązania ([tego problemu](https://github.com/Uniswap/uniswap-interface/issues/835)).
+
+```solidity
+ for (uint i; i < path.length - 1; i++) {
+ (address input, address output) = (path[i], path[i + 1]);
+ (address token0,) = UniswapV2Library.sortTokens(input, output);
+ IUniswapV2Pair pair = IUniswapV2Pair(UniswapV2Library.pairFor(factory, input, output));
+ uint amountInput;
+ uint amountOutput;
+ { // zakres w celu uniknięcia błędów zbyt głębokiego stosu
+ (uint reserve0, uint reserve1,) = pair.getReserves();
+ (uint reserveInput, uint reserveOutput) = input == token0 ? (reserve0, reserve1) : (reserve1, reserve0);
+ amountInput = IERC20(input).balanceOf(address(pair)).sub(reserveInput);
+ amountOutput = UniswapV2Library.getAmountOut(amountInput, reserveInput, reserveOutput);
+```
+
+Z powodu opłat za transfer nie możemy polegać na funkcji `getAmountsOut`, która informuje nas, ile otrzymujemy z każdego transferu (tak jak robimy to przed wywołaniem oryginalnej funkcji `_swap`). Zamiast tego musimy najpierw dokonać transferu, a następnie zobaczyć, ile tokenów otrzymaliśmy z powrotem.
+
+Uwaga: teoretycznie moglibyśmy po prostu użyć tej funkcji zamiast `_swap`, ale w niektórych przypadkach (na przykład, jeśli transfer zostanie ostatecznie wycofany, ponieważ na końcu nie ma wystarczającej ilości, aby spełnić wymagane minimum) kosztowałoby to więcej gazu. Tokeny z opłatą za transfer są dość rzadkie, więc chociaż musimy je uwzględnić, nie ma potrzeby, aby wszystkie wymiany zakładały, że przechodzą przez co najmniej jeden z nich.
+
+```solidity
+ }
+ (uint amount0Out, uint amount1Out) = input == token0 ? (uint(0), amountOutput) : (amountOutput, uint(0));
+ address to = i < path.length - 2 ? UniswapV2Library.pairFor(factory, output, path[i + 2]) : _to;
+ pair.swap(amount0Out, amount1Out, to, new bytes(0));
+ }
+ }
+
+
+ function swapExactTokensForTokensSupportingFeeOnTransferTokens(
+ uint amountIn,
+ uint amountOutMin,
+ address[] calldata path,
+ address to,
+ uint deadline
+ ) external virtual override ensure(deadline) {
+ TransferHelper.safeTransferFrom(
+ path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amountIn
+ );
+ uint balanceBefore = IERC20(path[path.length - 1]).balanceOf(to);
+ _swapSupportingFeeOnTransferTokens(path, to);
+ require(
+ IERC20(path[path.length - 1]).balanceOf(to).sub(balanceBefore) >= amountOutMin,
+ 'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT'
+ );
+ }
+
+
+ function swapExactETHForTokensSupportingFeeOnTransferTokens(
+ uint amountOutMin,
+ address[] calldata path,
+ address to,
+ uint deadline
+ )
+ external
+ virtual
+ override
+ payable
+ ensure(deadline)
+ {
+ require(path[0] == WETH, 'UniswapV2Router: INVALID_PATH');
+ uint amountIn = msg.value;
+ IWETH(WETH).deposit{value: amountIn}();
+ assert(IWETH(WETH).transfer(UniswapV2Library.pairFor(factory, path[0], path[1]), amountIn));
+ uint balanceBefore = IERC20(path[path.length - 1]).balanceOf(to);
+ _swapSupportingFeeOnTransferTokens(path, to);
+ require(
+ IERC20(path[path.length - 1]).balanceOf(to).sub(balanceBefore) >= amountOutMin,
+ 'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT'
+ );
+ }
+
+
+ function swapExactTokensForETHSupportingFeeOnTransferTokens(
+ uint amountIn,
+ uint amountOutMin,
+ address[] calldata path,
+ address to,
+ uint deadline
+ )
+ external
+ virtual
+ override
+ ensure(deadline)
+ {
+ require(path[path.length - 1] == WETH, 'UniswapV2Router: INVALID_PATH');
+ TransferHelper.safeTransferFrom(
+ path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amountIn
+ );
+ _swapSupportingFeeOnTransferTokens(path, address(this));
+ uint amountOut = IERC20(WETH).balanceOf(address(this));
+ require(amountOut >= amountOutMin, 'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT');
+ IWETH(WETH).withdraw(amountOut);
+ TransferHelper.safeTransferETH(to, amountOut);
+ }
+```
+
+Są to te same warianty, które są używane dla normalnych tokenów, ale zamiast tego wywołują `_swapSupportingFeeOnTransferTokens`.
+
+```solidity
+ // **** FUNKCJE BIBLIOTEKI ****
+ function quote(uint amountA, uint reserveA, uint reserveB) public pure virtual override returns (uint amountB) {
+ return UniswapV2Library.quote(amountA, reserveA, reserveB);
+ }
+
+ function getAmountOut(uint amountIn, uint reserveIn, uint reserveOut)
+ public
+ pure
+ virtual
+ override
+ returns (uint amountOut)
+ {
+ return UniswapV2Library.getAmountOut(amountIn, reserveIn, reserveOut);
+ }
+
+ function getAmountIn(uint amountOut, uint reserveIn, uint reserveOut)
+ public
+ pure
+ virtual
+ override
+ returns (uint amountIn)
+ {
+ return UniswapV2Library.getAmountIn(amountOut, reserveIn, reserveOut);
+ }
+
+ function getAmountsOut(uint amountIn, address[] memory path)
+ public
+ view
+ virtual
+ override
+ returns (uint[] memory amounts)
+ {
+ return UniswapV2Library.getAmountsOut(factory, amountIn, path);
+ }
+
+ function getAmountsIn(uint amountOut, address[] memory path)
+ public
+ view
+ virtual
+ override
+ returns (uint[] memory amounts)
+ {
+ return UniswapV2Library.getAmountsIn(factory, amountOut, path);
+ }
+}
+```
+
+Te funkcje są tylko pośrednikami, które wywołują [funkcje UniswapV2Library](#uniswapV2library).
+
+### UniswapV2Migrator.sol {#UniswapV2Migrator}
+
+Ten kontrakt był używany do migracji wymian ze starej wersji v1 do v2. Teraz, gdy zostały zmigrowane, nie jest to już istotne.
+
+## Biblioteki {#libraries}
+
+[Biblioteka SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math) jest dobrze udokumentowana, więc nie ma potrzeby jej tutaj dokumentować.
+
+### Math {#Math}
+
+Ta biblioteka zawiera kilka funkcji matematycznych, które normalnie nie są potrzebne w kodzie Solidity, więc nie są częścią języka.
+
+```solidity
+pragma solidity =0.5.16;
+
+// biblioteka do wykonywania różnych operacji matematycznych
+
+library Math {
+ function min(uint x, uint y) internal pure returns (uint z) {
+ z = x < y ? x : y;
+ }
+
+ // metoda babilońska (https://wikipedia.org/wiki/Methods_of_computing_square_roots#Babylonian_method)
+ function sqrt(uint y) internal pure returns (uint z) {
+ if (y > 3) {
+ z = y;
+ uint x = y / 2 + 1;
+```
+
+Zacznij od x jako oszacowania, które jest wyższe niż pierwiastek kwadratowy (dlatego musimy traktować 1-3 jako przypadki specjalne).
+
+```solidity
+ while (x < z) {
+ z = x;
+ x = (y / x + x) / 2;
+```
+
+Uzyskaj bliższe oszacowanie, średnią z poprzedniego oszacowania i liczby, której pierwiastek kwadratowy próbujemy znaleźć, podzieloną przez poprzednie oszacowanie. Powtarzaj, aż nowe oszacowanie nie będzie niższe od istniejącego. Więcej szczegółów [znajdziesz tutaj](https://wikipedia.org/wiki/Methods_of_computing_square_roots#Babylonian_method).
+
+```solidity
+ }
+ } else if (y != 0) {
+ z = 1;
+```
+
+Nigdy nie powinniśmy potrzebować pierwiastka kwadratowego z zera. Pierwiastki kwadratowe z jednego, dwóch i trzech to w przybliżeniu jeden (używamy liczb całkowitych, więc ignorujemy część ułamkową).
+
+```solidity
+ }
+ }
+}
+```
+
+### Ułamki stałoprzecinkowe (UQ112x112) {#FixedPoint}
+
+Ta biblioteka obsługuje ułamki, które normalnie nie są częścią arytmetyki Ethereum. Robi to poprzez kodowanie liczby _x_ jako _x\*2^112_. Pozwala nam to na użycie oryginalnych kodów operacyjnych dodawania i odejmowania bez zmian.
+
+```solidity
+pragma solidity =0.5.16;
+
+// biblioteka do obsługi binarnych liczb stałoprzecinkowych (https://wikipedia.org/wiki/Q_(number_format))
+
+// zakres: [0, 2**112 - 1]
+// rozdzielczość: 1 / 2**112
+
+library UQ112x112 {
+ uint224 constant Q112 = 2**112;
+```
+
+`Q112` to kodowanie jedynki.
+
+```solidity
+ // koduje uint112 jako UQ112x112
+ function encode(uint112 y) internal pure returns (uint224 z) {
+ z = uint224(y) * Q112; // nigdy się nie przepełnia
+ }
+```
+
+Ponieważ y to `uint112`, największa możliwa wartość to 2^112-1. Ta liczba nadal może być zakodowana jako `UQ112x112`.
+
+```solidity
+ // dzieli UQ112x112 przez uint112, zwracając UQ112x112
+ function uqdiv(uint224 x, uint112 y) internal pure returns (uint224 z) {
+ z = x / uint224(y);
+ }
+}
+```
+
+Jeśli podzielimy dwie wartości `UQ112x112`, wynik nie będzie już pomnożony przez 2^112. Zamiast tego bierzemy liczbę całkowitą jako mianownik. Musielibyśmy użyć podobnej sztuczki, aby wykonać mnożenie, ale nie musimy wykonywać mnożenia wartości `UQ112x112`.
+
+### UniswapV2Library {#uniswapV2library}
+
+Ta biblioteka jest używana tylko przez kontrakty peryferyjne
+
+```solidity
+pragma solidity >=0.5.0;
+
+import '@uniswap/v2-core/contracts/interfaces/IUniswapV2Pair.sol';
+
+import "./SafeMath.sol";
+
+library UniswapV2Library {
+ using SafeMath for uint;
+
+ // zwraca posortowane adresy tokenów, używane do obsługi wartości zwracanych z par posortowanych w tej kolejności
+ function sortTokens(address tokenA, address tokenB) internal pure returns (address token0, address token1) {
+ require(tokenA != tokenB, 'UniswapV2Library: IDENTICAL_ADDRESSES');
+ (token0, token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA);
+ require(token0 != address(0), 'UniswapV2Library: ZERO_ADDRESS');
+ }
+```
+
+Posortuj dwa tokeny według adresu, abyśmy mogli uzyskać adres wymiany par dla nich. Jest to konieczne, ponieważ w przeciwnym razie mielibyśmy dwie możliwości, jedną dla parametrów A,B, a drugą dla parametrów B,A, co prowadziłoby do dwóch wymian zamiast jednej.
+
+```solidity
+ // oblicza adres CREATE2 dla pary bez wykonywania żadnych wywołań zewnętrznych
+ function pairFor(address factory, address tokenA, address tokenB) internal pure returns (address pair) {
+ (address token0, address token1) = sortTokens(tokenA, tokenB);
+ pair = address(uint(keccak256(abi.encodePacked(
+ hex'ff',
+ factory,
+ keccak256(abi.encodePacked(token0, token1)),
+ hex'96e8ac4277198ff8b6f785478aa9a39f403cb768dd02cbee326c3e7da348845f' // hash kodu inicjującego
+ ))));
+ }
+```
+
+Ta funkcja oblicza adres wymiany par dla dwóch tokenów. Ten kontrakt jest tworzony przy użyciu [kodu operacyjnego CREATE2](https://eips.ethereum.org/EIPS/eip-1014), więc możemy obliczyć adres za pomocą tego samego algorytmu, jeśli znamy parametry, których używa. Jest to o wiele tańsze niż zapytanie kontraktu `factory` i
+
+```solidity
+ // pobiera i sortuje rezerwy dla pary
+ function getReserves(address factory, address tokenA, address tokenB) internal view returns (uint reserveA, uint reserveB) {
+ (address token0,) = sortTokens(tokenA, tokenB);
+ (uint reserve0, uint reserve1,) = IUniswapV2Pair(pairFor(factory, tokenA, tokenB)).getReserves();
+ (reserveA, reserveB) = tokenA == token0 ? (reserve0, reserve1) : (reserve1, reserve0);
+ }
+```
+
+Ta funkcja zwraca rezerwy dwóch tokenów, które posiada wymiana par. Zauważ, że może odbierać tokeny w dowolnej kolejności i sortuje je do użytku wewnętrznego.
+
+```solidity
+ // biorąc pod uwagę pewną ilość zasobu i rezerwy pary, zwraca równowartość drugiego zasobu
+ function quote(uint amountA, uint reserveA, uint reserveB) internal pure returns (uint amountB) {
+ require(amountA > 0, 'UniswapV2Library: INSUFFICIENT_AMOUNT');
+ require(reserveA > 0 && reserveB > 0, 'UniswapV2Library: INSUFFICIENT_LIQUIDITY');
+ amountB = amountA.mul(reserveB) / reserveA;
+ }
+```
+
+Ta funkcja podaje ilość tokena B, którą otrzymasz w zamian za token A, jeśli nie ma żadnej opłaty. To obliczenie uwzględnia fakt, że transfer zmienia kurs wymiany.
+
+```solidity
+ // biorąc pod uwagę kwotę wejściową zasobu i rezerwy pary, zwraca maksymalną kwotę wyjściową drugiego zasobu
+ function getAmountOut(uint amountIn, uint reserveIn, uint reserveOut) internal pure returns (uint amountOut) {
+```
+
+Powyższa funkcja `quote` działa świetnie, jeśli nie ma opłaty za korzystanie z wymiany par. Jeśli jednak istnieje opłata za wymianę w wysokości 0,3%, kwota, którą faktycznie otrzymujesz, jest niższa. Ta funkcja oblicza kwotę po uwzględnieniu opłaty za wymianę.
+
+```solidity
+
+ require(amountIn > 0, 'UniswapV2Library: INSUFFICIENT_INPUT_AMOUNT');
+ require(reserveIn > 0 && reserveOut > 0, 'UniswapV2Library: INSUFFICIENT_LIQUIDITY');
+ uint amountInWithFee = amountIn.mul(997);
+ uint numerator = amountInWithFee.mul(reserveOut);
+ uint denominator = reserveIn.mul(1000).add(amountInWithFee);
+ amountOut = numerator / denominator;
+ }
+```
+
+Solidity nie obsługuje natywnie ułamków, więc nie możemy po prostu pomnożyć kwoty wyjściowej przez 0,997. Zamiast tego mnożymy licznik przez 997, a mianownik przez 1000, uzyskując ten sam efekt.
+
+```solidity
+ // biorąc pod uwagę kwotę wyjściową zasobu i rezerwy pary, zwraca wymaganą kwotę wejściową drugiego zasobu
+ function getAmountIn(uint amountOut, uint reserveIn, uint reserveOut) internal pure returns (uint amountIn) {
+ require(amountOut > 0, 'UniswapV2Library: INSUFFICIENT_OUTPUT_AMOUNT');
+ require(reserveIn > 0 && reserveOut > 0, 'UniswapV2Library: INSUFFICIENT_LIQUIDITY');
+ uint numerator = reserveIn.mul(amountOut).mul(1000);
+ uint denominator = reserveOut.sub(amountOut).mul(997);
+ amountIn = (numerator / denominator).add(1);
+ }
+```
+
+Ta funkcja robi mniej więcej to samo, ale pobiera kwotę wyjściową i podaje kwotę wejściową.
+
+```solidity
+
+ // wykonuje łańcuchowe obliczenia getAmountOut na dowolnej liczbie par
+ function getAmountsOut(address factory, uint amountIn, address[] memory path) internal view returns (uint[] memory amounts) {
+ require(path.length >= 2, 'UniswapV2Library: INVALID_PATH');
+ amounts = new uint[](path.length);
+ amounts[0] = amountIn;
+ for (uint i; i < path.length - 1; i++) {
+ (uint reserveIn, uint reserveOut) = getReserves(factory, path[i], path[i + 1]);
+ amounts[i + 1] = getAmountOut(amounts[i], reserveIn, reserveOut);
+ }
+ }
+
+ // wykonuje łańcuchowe obliczenia getAmountIn na dowolnej liczbie par
+ function getAmountsIn(address factory, uint amountOut, address[] memory path) internal view returns (uint[] memory amounts) {
+ require(path.length >= 2, 'UniswapV2Library: INVALID_PATH');
+ amounts = new uint[](path.length);
+ amounts[amounts.length - 1] = amountOut;
+ for (uint i = path.length - 1; i > 0; i--) {
+ (uint reserveIn, uint reserveOut) = getReserves(factory, path[i - 1], path[i]);
+ amounts[i - 1] = getAmountIn(amounts[i], reserveIn, reserveOut);
+ }
+ }
+}
+```
+
+Te dwie funkcje obsługują identyfikację wartości, gdy konieczne jest przejście przez kilka wymian par.
+
+### Pomocnik transferu {#transfer-helper}
+
+[Ta biblioteka](https://github.com/Uniswap/uniswap-lib/blob/master/contracts/libraries/TransferHelper.sol) dodaje sprawdzenia powodzenia wokół transferów ERC-20 i Ethereum, aby traktować wycofanie i zwrócenie wartości `false` w ten sam sposób.
+
+```solidity
+// SPDX-License-Identifier: GPL-3.0-or-later
+
+pragma solidity >=0.6.0;
+
+// metody pomocnicze do interakcji z tokenami ERC20 i wysyłania ETH, które nie zawsze zwracają true/false
+library TransferHelper {
+ function safeApprove(
+ address token,
+ address to,
+ uint256 value
+ ) internal {
+ // bytes4(keccak256(bytes('approve(address,uint256)')));
+ (bool success, bytes memory data) = token.call(abi.encodeWithSelector(0x095ea7b3, to, value));
+
+```
+
+Możemy wywołać inny kontrakt na jeden z dwóch sposobów:
+
+- Użyj definicji interfejsu, aby utworzyć wywołanie funkcji
+- Użyj [binarnego interfejsu aplikacji (ABI)](https://docs.soliditylang.org/en/v0.8.3/abi-spec.html) "ręcznie", aby utworzyć wywołanie. Tak właśnie zdecydował się zrobić autor kodu.
+
+```solidity
+ require(
+ success && (data.length == 0 || abi.decode(data, (bool))),
+ 'TransferHelper::safeApprove: approve failed'
+ );
+ }
+```
+
+Ze względu na kompatybilność wsteczną z tokenami, które zostały utworzone przed standardem ERC-20, wywołanie ERC-20 może zakończyć się niepowodzeniem albo przez wycofanie (w którym to przypadku `success` ma wartość `false`), albo przez pomyślne wykonanie i zwrócenie wartości `false` (w którym to przypadku istnieją dane wyjściowe, a jeśli zdekodujesz je jako wartość logiczną, otrzymasz `false`).
+
+```solidity
+
+
+ function safeTransfer(
+ address token,
+ address to,
+ uint256 value
+ ) internal {
+ // bytes4(keccak256(bytes('transfer(address,uint256)')));
+ (bool success, bytes memory data) = token.call(abi.encodeWithSelector(0xa9059cbb, to, value));
+ require(
+ success && (data.length == 0 || abi.decode(data, (bool))),
+ 'TransferHelper::safeTransfer: transfer failed'
+ );
+ }
+```
+
+Ta funkcja implementuje [funkcjonalność transferu ERC-20](https://eips.ethereum.org/EIPS/eip-20#transfer), która pozwala kontu na wydanie zezwolenia udzielonego przez inne konto.
+
+```solidity
+
+ function safeTransferFrom(
+ address token,
+ address from,
+ address to,
+ uint256 value
+ ) internal {
+ // bytes4(keccak256(bytes('transferFrom(address,address,uint256)')));
+ (bool success, bytes memory data) = token.call(abi.encodeWithSelector(0x23b872dd, from, to, value));
+ require(
+ success && (data.length == 0 || abi.decode(data, (bool))),
+ 'TransferHelper::transferFrom: transferFrom failed'
+ );
+ }
+```
+
+Ta funkcja implementuje [funkcjonalność transferFrom ERC-20](https://eips.ethereum.org/EIPS/eip-20#transferfrom), która pozwala kontu na wydanie zezwolenia udzielonego przez inne konto.
+
+```solidity
+
+ function safeTransferETH(address to, uint256 value) internal {
+ (bool success, ) = to.call{value: value}(new bytes(0));
+ require(success, 'TransferHelper::safeTransferETH: ETH transfer failed');
+ }
+}
+```
+
+Ta funkcja przesyła ether na konto. Każde wywołanie do innego kontraktu może próbować wysłać ether. Ponieważ nie musimy faktycznie wywoływać żadnej funkcji, nie wysyłamy żadnych danych z wywołaniem.
+
+## Wnioski {#conclusion}
+
+To długi artykuł, liczący około 50 stron. Jeśli dotarliście tutaj, gratulacje! Mamy nadzieję, że do tej pory zrozumieliście już kwestie związane z pisaniem prawdziwej aplikacji (w przeciwieństwie do krótkich programów przykładowych) i jesteście lepiej przygotowani do pisania kontraktów dla własnych przypadków użycia.
+
+Teraz idźcie, napiszcie coś pożytecznego i zadziwcie nas.
+
+[Zobacz więcej mojej pracy tutaj](https://cryptodocguy.pro/).
diff --git a/public/content/translations/pl/developers/tutorials/using-websockets/index.md b/public/content/translations/pl/developers/tutorials/using-websockets/index.md
index 92894584e01..f60e0102c1c 100644
--- a/public/content/translations/pl/developers/tutorials/using-websockets/index.md
+++ b/public/content/translations/pl/developers/tutorials/using-websockets/index.md
@@ -1,18 +1,12 @@
---
-title: Używanie WebSockets
-description: Przewodnik korzystania z WebSockets i Alchemy do wysyłania żądań JSON-RPC i subskrybowania zdarzeń.
+title: "Używanie WebSockets"
+description: "Przewodnik korzystania z WebSockets i Alchemy do wysyłania żądań JSON-RPC i subskrybowania zdarzeń."
author: "Elan Halpern"
lang: pl
-tags:
- - "alchemy"
- - "websockets"
- - "zapytania"
- - "pierwsze kroki"
- - "subskrypcja"
- - "JavaScript"
+tags: [ "alchemy", "websockets", "zapytania", "JavaScript" ]
skill: beginner
-source: Dokumentacja Alchemy
-sourceUrl: https://docs.alchemyapi.io/guides/using-websockets
+source: Alchemy docs
+sourceUrl: https://www.alchemy.com/docs/reference/best-practices-for-using-websockets-in-web3
published: 2020-12-01
---
@@ -24,28 +18,30 @@ W odróżnieniu od HTTP, z WebSockets, nie musisz ciągle wysyłać żądań, gd
Podobnie jak w przypadku jakiegokolwiek połączenia sieciowego, nie należy zakładać, że WebSocket pozostanie otwarty na zawsze bez przerwy, ale właściwa obsługa zerwanego połączenia i ponowne nawiązanie połączenie może zapewnić ciągłość jego prawidłowego działania. Następną niedogodnością WebSocketów jest to, że nie otrzymujesz kodów statusu HTTP w odpowiedzi, ale tylko komunikat o błędzie.
-[Alchemy Web3](https://docs.alchemy.com/reference/api-overview) automatycznie dodaje obsługę awarii WebSocket i ponawiania prób bez konieczności konfiguracji.
+[Alchemy Web3](https://docs.alchemy.com/reference/api-overview) automatycznie dodaje obsługę awarii WebSocket i ponownych prób bez konieczności konfiguracji.
## Wypróbuj {#try-it-out}
-Najprostszym sposobem na przetestowanie WebSockets jest zainstalowanie narzędzia wiersza poleceń do tworzenia żądań WebSocket, takich jak [wscat](https://github.com/websockets/wscat). Używając wscat, możesz wysyłać następujące żądania:
+Najprostszym sposobem na przetestowanie WebSockets jest zainstalowanie narzędzia wiersza poleceń do tworzenia żądań WebSocket, takiego jak [wscat](https://github.com/websockets/wscat). Używając wscat, możesz wysyłać następujące żądania:
-_Uwaga: jeśli posiadasz konto Alchemy, możesz zastąpić `demo` własnym kluczem API. [Sign up for a free Alchemy account here!](https://auth.alchemyapi.io/signup)_
+_Uwaga: jeśli masz konto Alchemy, możesz zastąpić `demo` własnym kluczem API. [Zarejestruj darmowe konto Alchemy tutaj!](https://auth.alchemy.com/signup)_
```
wscat -c wss://eth-mainnet.ws.alchemyapi.io/ws/demo
-> {"jsonrpc": "2.0", "id": 0, "method": "eth_gasPrice"}
-< {"jsonrpc": "2.0", "result": "0xb2d05e00", "id": 0}
+
+> {"jsonrpc": "2.0", "id": 0, "method": "eth_gasPrice"}
+
+< {"jsonrpc": "2.0", "result": "0xb2d05e00", "id": 0}
```
-## Jak korzystać z WebSockets {#how-to-use-websockets}
+## Jak używać WebSockets {#how-to-use-websockets}
-Aby rozpocząć, otwórz WebSocket za pomocą adresu URL WebSocket dla swojej aplikacji. Możesz znaleźć adres URL swojej aplikacji WebSocket, otwierając stronę aplikacji w [pulpicie nawigacyjnym](https://dashboard.alchemyapi.io/) i klikając przycisk „Wyświetl klucz”. Pamiętaj, że adres URL Twojej aplikacji dla WebSocketów różni się od adresu URL dla żądań HTTP, ale oba można znaleźć klikając „Wyświetl klucz”.
+Aby rozpocząć, otwórz WebSocket za pomocą adresu URL WebSocket dla swojej aplikacji. Możesz znaleźć adres URL WebSocket swojej aplikacji, otwierając stronę aplikacji w [swoim pulpicie nawigacyjnym](https://dashboard.alchemy.com/) i klikając „Wyświetl klucz”. Pamiętaj, że adres URL Twojej aplikacji dla WebSocketów różni się od adresu URL dla żądań HTTP, ale oba można znaleźć klikając „Wyświetl klucz”.
-
+
-Każdy z API wymienionych w [alchemy API](https://docs.alchemyapi.io/documentation/alchemy-api-reference/) może być używany przez WebSocket. Aby to zrobić, użyj tego samego ładunku, który zostałby wysłany jako treść żądania HTTP POST, ale zamiast tego wyślij ten ładunek za pośrednictwem protokołu WebSocket.
+Dowolne z interfejsów API wymienionych w [Dokumentacji Alchemy API](https://www.alchemy.com/docs/reference/api-overview) można używać za pośrednictwem WebSocket. Aby to zrobić, użyj tego samego ładunku, który zostałby wysłany jako treść żądania HTTP POST, ale zamiast tego wyślij ten ładunek za pośrednictwem protokołu WebSocket.
## Z Web3 {#with-web3}
@@ -57,13 +53,13 @@ const web3 = new Web3("wss://eth-mainnet.ws.alchemyapi.io/ws/your-api-key")
web3.eth.getBlockNumber().then(console.log) // -> 7946893
```
-## Subskrypcja API {#subscription-api}
+## API subskrypcji {#subscription-api}
-Po połączeniu przez WebSocket, możesz użyć dwóch dodatkowych metod: `eth_subscribe` i `eth_unsubscribe`. Te metody pozwolą Ci na wysłuchanie konkretnych wydarzeń i natychmiastowe powiadomienie.
+Po połączeniu przez WebSocket można użyć dwóch dodatkowych metod: `eth_subscribe` i `eth_unsubscribe`. Te metody pozwolą Ci na wysłuchanie konkretnych wydarzeń i natychmiastowe powiadomienie.
### `eth_subscribe` {#eth-subscribe}
-Tworzy nową subskrypcję dla określonych zdarzeń. [Dowiedz się więcej o `eth_subscribe`](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_subscribe).
+Tworzy nową subskrypcję dla określonych zdarzeń. [Dowiedz się więcej o `eth_subscribe`](https://docs.alchemy.com/reference/eth-subscribe).
#### Parametry {#parameters}
@@ -72,9 +68,9 @@ Tworzy nową subskrypcję dla określonych zdarzeń. [Dowiedz się więcej o `et
Pierwszy argument określa rodzaj wydarzenia, którego należy nasłuchiwać. Drugi argument zawiera dodatkowe opcje, które zależą od pierwszego argumentu. Poniżej opisano różne rodzaje opisów, ich opcje i obciążenia zdarzeniami.
-#### Zwraca {#returns}
+#### Wartości zwracane {#returns}
-ID subskrypcji: Ten identyfikator zostanie dołączony do wszystkich otrzymanych wydarzeń, i może być również używany do anulowania subskrypcji za pomocą `eth_unsubscribe`.
+Identyfikator subskrypcji: Ten identyfikator zostanie dołączony do wszystkich odebranych zdarzeń i może być również użyty do anulowania subskrypcji za pomocą `eth_unsubscribe`.
#### Zdarzenia subskrypcji {#subscription-events}
@@ -83,14 +79,14 @@ Podczas gdy subskrypcja jest aktywna, otrzymasz zdarzenia, które są obiektami
- `jsonrpc`: Zawsze "2.0"
- `method`: Zawsze "eth_subscription"
- `params`: Obiekt z następującymi polami:
- - `subscription`: ID subskrypcji zwrócony przez połączenie `eth_subscription`, które utworzyło tę subskrypcję.
- - `result`: Obiekt, którego zawartość różni się w zależności od rodzaju subskrypcji.
+ - `subscription`: Identyfikator subskrypcji zwrócony przez wywołanie `eth_subscribe`, które utworzyło tę subskrypcję.
+ - `result`: Obiekt, którego zawartość różni się w zależności od typu subskrypcji.
-#### Rodzaj subskrypcji {#subscription-types}
+#### Typy subskrypcji {#subscription-types}
1. `alchemy_newFullPendingTransactions`
-Zwraca informacje o transakcji dla wszystkich transakcji, które są dodane do stanu oczekującego. Ten typ subskrypcji subskrybuje oczekujące transakcje, podobne do standardowego połączenia Web3 `web3.eth. ubscribe("oczekujące transakcje")`, ale różni się w tym, że emituje _pełnych informacji o transakcjach_ zamiast tylko hashów transakcji.
+Zwraca informacje o transakcji dla wszystkich transakcji, które są dodane do stanu oczekującego. Ten typ subskrypcji subskrybuje oczekujące transakcje, podobnie do standardowego wywołania Web3 `web3.eth.subscribe("pendingTransactions")`, ale różni się tym, że emituje _pełne informacje o transakcji_, a nie tylko hasze transakcji.
Przykład:
@@ -140,13 +136,11 @@ Przykład:
"method": "eth_subscription",
"params": {
"result": {
- "difficulty": "0x15d9223a23aa",
"extraData": "0xd983010305844765746887676f312e342e328777696e646f7773",
"gasLimit": "0x47e7c4",
"gasUsed": "0x38658",
"logsBloom":
"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
- "miner": "0xf8b483dba2c3b7176a3da549ad41a48bb3121069",
"nonce": "0x084149998194cc5f",
"number": "0x1348c9",
"parentHash": "0x7736fab79e05dc611604d22470dadad26f56fe494421b5b333de816ce1f25701",
@@ -166,24 +160,24 @@ Przykład:
Emituje logi będące częścią nowo dodanych bloków, które spełniają określone kryteria filtrów.
-Gdy nastąpi reorganizacja łańcucha, logi będące częścią bloków starego łańcucha będą ponownie emitowane z właściwością `removed` ustawioną na `true`. Ponadto emitowane są dzienniki będące częścią bloków w nowym łańcuchu, co oznacza, że w przypadku reorganizacji możliwe jest wielokrotne wyświetlanie dzienników dla tej samej transakcji.
+Gdy nastąpi reorganizacja łańcucha, logi, które są częścią bloków w starym łańcuchu, zostaną ponownie wyemitowane z właściwością `removed` ustawioną na `true`. Ponadto emitowane są dzienniki będące częścią bloków w nowym łańcuchu, co oznacza, że w przypadku reorganizacji możliwe jest wielokrotne wyświetlanie dzienników dla tej samej transakcji.
Parametry
1. Obiekt z następującymi opcjonalnymi kluczami:
- - `adddress` (opcjonalnie): ciąg znaków reprezentujący adres lub tablica takich ciągów.
+ - `address` (opcjonalnie): ciąg znaków reprezentujący adres lub tablica takich ciągów.
- Tylko logi utworzone z jednego z tych adresów zostaną wysłane.
- `topics`: tablica specyfikatorów tematów.
- - Każdy specyfikator tematu jest albo `null`, ciągiem reprezentującym temat, albo tablicą ciągów.
- - Każda pozycja w tablicy, która nie jest `null` ogranicza emitowane logi tylko do tych, którzy mają jeden z podanych tematów w tej pozycji.
+ - Każdy specyfikator tematu to `null`, ciąg znaków reprezentujący temat lub tablica ciągów znaków.
+ - Każda pozycja w tablicy, która nie jest `null`, ogranicza emitowane logi tylko do tych, które mają jeden z podanych tematów na tej pozycji.
Przykłady specyfikacji tematu:
-- `[]`: Wszystkie dozwolone tematy.
-- `[A]`: Pierwsza pozycja (i cokolwiek po).
-- `[null, B]`: wszystko w pierwszej pozycji i B w drugiej pozycji (i cokolwiek po).
-- `[null, B]`: wszystko w pierwszej pozycji i B w drugiej pozycji (i cokolwiek po).
-- `[[A, B], [A, B]]`: (A lub B) w pierwszej pozycji i (A lub B) w drugiej pozycji (i cokolwiek po).
+- `[]`: Dowolne tematy dozwolone.
+- `[A]`: A na pierwszej pozycji (i wszystko, co dalej).
+- `[null, B]`: Cokolwiek na pierwszej pozycji i B na drugiej pozycji (i wszystko, co dalej).
+- `[A, B]`: A na pierwszej pozycji i B na drugiej pozycji (i wszystko, co dalej).
+- `[[A, B], [A, B]]`: (A lub B) na pierwszej pozycji i (A lub B) na drugiej pozycji (i wszystko, co dalej).
Przykład:
@@ -217,11 +211,11 @@ Anuluje istniejącą subskrypcję, aby nie wysyłano żadnych kolejnych wydarze
Parametry
-1. ID subskrypcji, jakie zostało wcześniej zwrócone z połączenia `eth_subscribe`.
+1. Identyfikator subskrypcji, zwrócony wcześniej z wywołania `eth_subscribe`.
Zwraca
-`true` jeśli subskrypcja została pomyślnie anulowana lub `false` jeśli nie istnieje subskrypcja z podanym identyfikatorem.
+`true`, jeśli subskrypcja została pomyślnie anulowana, lub `false`, jeśli nie istniała subskrypcja o podanym identyfikatorze.
Przykład:
@@ -248,4 +242,4 @@ curl https://eth-mainnet.alchemyapi.io/v2/your-api-key
---
-[Zarejestruj się w Alchemy](https://auth.alchemyapi.io/signup) za darmo, sprawdź [naszą dokumentację](https://docs.alchemyapi.io/) aby uzyskać najnowsze wiadomości, obserwuj nas na [Twitterze](https://twitter.com/AlchemyPlatform).
+[Zarejestruj się za darmo w Alchemy](https://auth.alchemy.com), sprawdź [naszą dokumentację](https://www.alchemy.com/docs/), a żeby być na bieżąco z najnowszymi wiadomościami, obserwuj nas na [Twitterze](https://x.com/AlchemyPlatform).
diff --git a/public/content/translations/pl/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md b/public/content/translations/pl/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
index f9dbf6311b5..bd0a94b5ea7 100644
--- a/public/content/translations/pl/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
+++ b/public/content/translations/pl/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
@@ -1,13 +1,15 @@
---
title: "Waffle: Dynamiczne tworzenie atrap i testowanie wywołań kontraktów"
-description: Zaawansowany samouczek Waffle do używania dynamicznego tworzenia atrap i testowania wywołań kontraktów
+description: "Zaawansowany samouczek Waffle dotyczący używania dynamicznego tworzenia atrap i testowania wywołań kontraktów"
author: "Daniel Izdebski"
tags:
- - "waffle"
- - "inteligentne kontrakty"
- - "solidity"
- - "testowanie"
- - "tworzenie atrap"
+ [
+ "waffle",
+ "smart kontrakty",
+ "solidity",
+ "testowanie",
+ "tworzenie atrap"
+ ]
skill: intermediate
lang: pl
published: 2020-11-14
@@ -15,51 +17,52 @@ published: 2020-11-14
## O czym jest ten samouczek? {#what-is-this-tutorial-about}
-Z tego samouczka dowiesz się, jak:
+W tym samouczku dowiesz się, jak:
-- uużywać dynamicznego tworzenia atrap
+- używać dynamicznego tworzenia atrap
- testować interakcje między inteligentnymi kontraktami
Założenia:
-- wiesz już, jak napisać prosty inteligentny kontrakt w `Solidity `
+- wiesz już, jak napisać prosty inteligentny kontrakt w `Solidity`
- znasz się na `JavaScript` i `TypeScript`
-- zapoznałeś się z innymi samouczkami `Waffle` lub wiesz coś na ten temat
+- masz za sobą inne samouczki `Waffle` lub wiesz już co nieco na ten temat
## Dynamiczne tworzenie atrap {#dynamic-mocking}
-Dlaczego dynamiczne tworzenie atrap jest przydatne? No cóż, pozwala nam pisać testy jednostkowe zamiast testów integracyjnych. Co to oznacza? Oznacza to, że nie musimy martwić się zależnościami inteligentnych kontraktów, dlatego możemy je przetestować w całkowicie izolacji. Pozwolę sobie pokazać, jak dokładnie możesz to zrobić.
+Dlaczego dynamiczne tworzenie atrap jest przydatne? Cóż, pozwala nam pisać testy jednostkowe zamiast testów integracyjnych. Co to oznacza? Oznacza to, że nie musimy się martwić o zależności inteligentnych kontraktów, dzięki czemu możemy je testować w całkowitej izolacji. Pokażę ci, jak dokładnie możesz to zrobić.
-### **1. Projekt** {#1-project}
+### \*\*1. **1. Projekt** {#1-project}
-Zanim zaczniemy musimy przygotować prosty projekt node.js:
+Zanim zaczniemy, musimy przygotować prosty projekt node.js:
```bash
-$ mkdir dynamic-mocking
-$ cd dynamic-mocking
-$ mkdir contracts src
+mkdir dynamic-mocking
+cd dynamic-mocking
+mkdir contracts src
-$ yarn init
-# or if you're using npm
-$ npm init
+yarn init
+# lub jeśli używasz npm
+npm init
```
-Zacznijmy od dodania zależności typescript i test — mokka i chai:
+Zacznijmy od dodania zależności TypeScript i testowych – mocha i chai:
```bash
-$ yarn add --dev @types/chai @types/mocha chai mocha ts-node typescript
-# lub jeśli używasz npm $ npm install @types/chai @types/mocha chai mocha ts-node typescript --save-dev
+yarn add --dev @types/chai @types/mocha chai mocha ts-node typescript
+# lub jeśli używasz npm
+npm install @types/chai @types/mocha chai mocha ts-node typescript --save-dev
```
Teraz dodajmy `Waffle` i `ethers`:
```bash
-$ yarn add --dev ethereum-waffle ethers
-# or if you're using npm
-$ npm install ethereum-waffle ethers --save-dev
+yarn add --dev ethereum-waffle ethers
+# lub jeśli używasz npm
+npm install ethereum-waffle ethers --save-dev
```
-Twoja struktura projektu powinna teraz wyglądać tak:
+Struktura twojego projektu powinna teraz wyglądać tak:
```
.
@@ -68,11 +71,11 @@ Twoja struktura projektu powinna teraz wyglądać tak:
└── test
```
-### **2. Inteligentny kontrakt** {#2-smart-contract}
+### \*\*2. **2. Inteligentny kontrakt** {#2-smart-contract}
-Aby rozpocząć dynamiczne tworzenie atrapy, potrzebujemy inteligentnego kontraktu z zależnościami. Nie martw się, pomyślałem o tym!
+Aby rozpocząć dynamiczne tworzenie atrap, potrzebujemy inteligentnego kontraktu z zależnościami. Nie martw się, zadbałem o to!
-Oto prosty inteligentny kontrakt napisany w `Solidity`, którego jedynym celem jest sprawdzenie, czy jesteśmy bogaci. Używa tokena ERC20 do sprawdzenia, czy mamy wystarczającą ilość tokenów. Umieść go w `./contracts/AmIRichAlready.sol`.
+Oto prosty inteligentny kontrakt napisany w `Solidity`, którego jedynym celem jest sprawdzenie, czy jesteśmy bogaci. Używa tokena ERC20 do sprawdzenia, czy mamy wystarczającą liczbę tokenów. Umieść go w `./contracts/AmIRichAlready.sol`.
```solidity
pragma solidity ^0.6.2;
@@ -98,7 +101,7 @@ contract AmIRichAlready {
Ponieważ chcemy używać dynamicznego tworzenia atrap, nie potrzebujemy całego ERC20, dlatego używamy interfejsu IERC20 z tylko jedną funkcją.
-Nadszedł czas, aby zbudować ten kontrakt! W tym celu użyjemy `Waffle`. Najpierw stworzymy prosty plik konfiguracyjny `waffle.json`, który określa opcje kompilacji.
+Czas zbudować ten kontrakt! W tym celu użyjemy `Waffle`. Najpierw stworzymy prosty plik konfiguracyjny `waffle.json`, który określa opcje kompilacji.
```json
{
@@ -109,17 +112,17 @@ Nadszedł czas, aby zbudować ten kontrakt! W tym celu użyjemy `Waffle`. Najpie
}
```
-Teraz jesteśmy gotowi zbudować kontrakt z Waffle:
+Teraz jesteśmy gotowi, aby zbudować kontrakt za pomocą Waffle:
```bash
-$ npx waffle
+npx waffle
```
-Łatwe, prawda? W folderze `build/` pojawiły się dwa pliki odpowiadające umowie i interfejsowi. Wykorzystamy je później do testowania.
+Proste, prawda? W folderze `build/` pojawiły się dwa pliki odpowiadające kontraktowi i interfejsowi. Użyjemy ich później do testowania.
-### **3. Testowanie** {#3-testing}
+### \*\*3. **3. Testowanie** {#3-testing}
-Utwórzmy plik o nazwie `AmIRichAlready.test.ts` dla bieżącego testu. Przede wszystkim musimy poradzić sobie z importem. Będziemy ich potrzebować na później:
+Stwórzmy plik o nazwie `AmIRichAlready.test.ts` do właściwego testowania. Przede wszystkim musimy zająć się importami. Będziemy ich potrzebować później:
```typescript
import { expect, use } from "chai"
@@ -132,34 +135,34 @@ import {
} from "ethereum-waffle"
```
-Z wyjątkiem zależności JS, musimy zaimportować naszą wbudowaną umowę i interfejs:
+Oprócz zależności JS musimy zaimportować nasz zbudowany kontrakt i interfejs:
```typescript
import IERC20 from "../build/IERC20.json"
import AmIRichAlready from "../build/AmIRichAlready.json"
```
-Waffle używa `chai` do testowania. Zanim jednak będziemy mogli go użyć, musimy wstrzyknąć wyrażenie matcher Waffle do samego chai:
+Waffle używa `chai` do testowania. Zanim jednak będziesz mógł go użyć, musimy wstrzyknąć matchery Waffle do samego `chai`:
```typescript
use(solidity)
```
-Musimy zaimplementować funkcję `beforeEach()`, która zresetuje stan kontraktu przed każdym testem. Zastanówmy się najpierw nad tym, czego tam potrzebujemy. Aby wdrożyć umowę, potrzebujemy dwóch rzeczy: portfela i wdrożonego kontraktu ERC20, aby przekazać go jako argument dla kontraktu `AmIRichAlready`.
+Musimy zaimplementować funkcję `beforeEach()`, która zresetuje stan kontraktu przed każdym testem. Najpierw zastanówmy się, czego tam potrzebujemy. Aby wdrożyć kontrakt, potrzebujemy dwóch rzeczy: portfela i wdrożonego kontraktu ERC20, aby przekazać go jako argument do kontraktu `AmIRichAlready`.
-Po pierwsze, tworzymy portfel:
+Najpierw tworzymy portfel:
```typescript
const [wallet] = new MockProvider().getWallets()
```
-Następnie musimy wdrożyć umowę ERC20. Oto trudna część - mamy tylko interfejs. Jest to ta część, w której Waffle nas ratuje. Waffle posiada magiczną funkcję `wdrożenieMockContract()`, która tworzy kontrakt wykorzystujący tylko _abi_ interfejsu:
+Następnie musimy wdrożyć kontrakt ERC20. I tu jest haczyk – mamy tylko interfejs. I tu z pomocą przychodzi nam Waffle. Waffle ma magiczną funkcję `deployMockContract()`, która tworzy kontrakt, używając wyłącznie _abi_ interfejsu:
```typescript
const mockERC20 = await deployMockContract(wallet, IERC20.abi)
```
-Teraz, zarówno z portfelem, jak i z ERC20, możemy kontynuować i wdrożyć kontrakt `AmIRichAlready`:
+Mając portfel i wdrożony kontrakt ERC20, możemy przejść do wdrożenia kontraktu `AmIRichAlready`:
```typescript
const contract = await deployContract(wallet, AmIRichAlready, [
@@ -167,7 +170,7 @@ const contract = await deployContract(wallet, AmIRichAlready, [
])
```
-Po tym wszystkim nasza funkcja `beforeEach()` została zakończona. Jak dotąd plik `AmIRichAlready.test.ts` powinien wyglądać tak:
+I to wszystko, nasza funkcja `beforeEach()` jest gotowa. Na tym etapie twój plik `AmIRichAlready.test.ts` powinien wyglądać tak:
```typescript
import { expect, use } from "chai"
@@ -197,19 +200,19 @@ describe("Am I Rich Already", () => {
})
```
-Zapiszmy pierwszy test do kontraktu `AmIRichAlready`. Czy uważasz, że powinniśmy mieć na uwadze nasz test? Tak, masz rację! Powinniśmy sprawdzić, czy już jesteśmy bogaci :)
+Napiszmy pierwszy test dla kontraktu `AmIRichAlready`. Jak myślisz, czego powinien dotyczyć nasz test? Tak, masz rację! Powinniśmy sprawdzić, czy jesteśmy już bogaci :)
-Ale poczekaj sekundę. Jak nasz pozorowany kontrakt będzie wiedział, jakie wartości należy zwrócić? Nie zaimplementowaliśmy żadnej logiki dla funkcji `balanceOf()`. Jeszcze raz Waffle może tu pomóc. Nasz pozorowany kontrakt ma teraz kilka nowych, fantazyjnych rzeczy:
+Ale chwila. Skąd nasz mockowany kontrakt będzie wiedział, jakie wartości zwrócić? Nie zaimplementowaliśmy żadnej logiki dla funkcji `balanceOf()`. I tu znowu z pomocą przychodzi Waffle. Nasz mockowany kontrakt ma teraz kilka nowych, fajnych dodatków:
```typescript
await mockERC20.mock..returns()
await mockERC20.mock..withArgs().returns()
```
-Dzięki tej wiedzy możemy wreszcie napisać nasz pierwszy test:
+Mając tę wiedzę, możemy wreszcie napisać nasz pierwszy test:
```typescript
-it("returns false if the wallet has less than 1000000 tokens", async () => {
+it("zwraca false, jeśli portfel ma mniej niż 1 000 000 tokenów", async () => {
await mockERC20.mock.balanceOf.returns(utils.parseEther("999999"))
expect(await contract.check()).to.be.equal(false)
})
@@ -217,17 +220,17 @@ it("returns false if the wallet has less than 1000000 tokens", async () => {
Podzielmy ten test na części:
-1. Ustawiliśmy naszą próbną umowę ERC20 tak, aby zawsze zwracała saldo 999999 tokenów.
-2. Sprawdź, czy metoda `contract.check()` zwraca `false`.
+1. Ustawiamy nasz mockowany kontrakt ERC20 tak, aby zawsze zwracał saldo 999 999 tokenów.
+2. Sprawdzamy, czy metoda `contract.check()` zwraca `false`.
-Jesteśmy gotowi wystrzelić z grubej rury:
+Jesteśmy gotowi, aby to odpalić:
-
+
-Tak więc test działa, ale... wciąż jest trochę miejsca na ulepszenia. Funkcja `balanceOf()` zawsze zwróci 99999. Możemy ją ulepszyć poprzez określenie portfela, dla którego funkcja powinna zwracać coś — tak jak prawdziwy kontrakt:
+Więc test działa, ale... wciąż jest pole do poprawy. Funkcja `balanceOf()` zawsze zwróci 99999. Możemy to ulepszyć, określając portfel, dla którego funkcja powinna coś zwrócić – tak jak w prawdziwym kontrakcie:
```typescript
-it("returns false if the wallet has less than 1000001 tokens", async () => {
+it("zwraca false, jeśli portfel ma mniej niż 1 000 001 tokenów", async () => {
await mockERC20.mock.balanceOf
.withArgs(wallet.address)
.returns(utils.parseEther("999999"))
@@ -235,10 +238,10 @@ it("returns false if the wallet has less than 1000001 tokens", async () => {
})
```
-Jak dotąd przetestowaliśmy tylko przypadek, w którym nie jesteśmy wystarczająco bogaci. Przetestujmy przeciwnie:
+Do tej pory testowaliśmy tylko przypadek, w którym nie jesteśmy wystarczająco bogaci. Przetestujmy teraz odwrotną sytuację:
```typescript
-it("returns true if the wallet has at least 1000001 tokens", async () => {
+it("zwraca true, jeśli portfel ma co najmniej 1 000 001 tokenów", async () => {
await mockERC20.mock.balanceOf
.withArgs(wallet.address)
.returns(utils.parseEther("1000001"))
@@ -246,28 +249,28 @@ it("returns true if the wallet has at least 1000001 tokens", async () => {
})
```
-Uruchomiłeś testy...
+Uruchamiasz testy...
-
+
-...i tu jesteś! Nasza umowa wydaje się działać zgodnie z zamierzeniem :)
+...i gotowe! Wygląda na to, że nasz kontrakt działa zgodnie z przeznaczeniem :)
## Testowanie wywołań kontraktów {#testing-contract-calls}
-Podsumujmy dotychczasowe osiągnięcia. Przetestowaliśmy funkcjonalność naszego kontraktu `AmIRichAlready` i wygląda na to, że działa poprawnie. To znaczy, że skończyliśmy, prawda? Nie całkiem! Waffle pozwala nam jeszcze bardziej przetestować nasz kontrakt. Ale jak dokładnie? No cóż, w arsenale Waffle'a znajduje się `calledOnContract()` i wyrażenia matcher `calledOnContractWith()`. Umożliwią nam one sprawdzenie, czy nasz kontrakt wywołał pozorowany kontrakt ERC20. Oto podstawowy test z jednym z tych wyrażeń:
+Podsumujmy, co do tej pory zrobiliśmy. Przetestowaliśmy funkcjonalność naszego kontraktu `AmIRichAlready` i wygląda na to, że działa on poprawnie. To znaczy, że skończyliśmy, prawda? Nie do końca! Waffle pozwala nam na jeszcze dokładniejsze przetestowanie naszego kontraktu. Ale jak dokładnie? Cóż, w arsenale Waffle'a znajdują się matchery `calledOnContract()` i `calledOnContractWith()`. Pozwolą nam one sprawdzić, czy nasz kontrakt wywołał mockowany kontrakt ERC20. Oto podstawowy test z jednym z tych matcherów:
```typescript
-it("checks if contract called balanceOf on the ERC20 token", async () => {
+it("sprawdza, czy kontrakt wywołał balanceOf na tokenie ERC20", async () => {
await mockERC20.mock.balanceOf.returns(utils.parseEther("999999"))
await contract.check()
expect("balanceOf").to.be.calledOnContract(mockERC20)
})
```
-Możemy pójść jeszcze dalej i ulepszyć ten test za pomocą innego wyrażenia matcher, o którym wam mówiłem:
+Możemy pójść o krok dalej i ulepszyć ten test za pomocą drugiego matchera, o którym ci mówiłem:
```typescript
-it("checks if contract called balanceOf with certain wallet on the ERC20 token", async () => {
+it("sprawdza, czy kontrakt wywołał balanceOf z określonym portfelem na tokenie ERC20", async () => {
await mockERC20.mock.balanceOf
.withArgs(wallet.address)
.returns(utils.parseEther("999999"))
@@ -278,20 +281,20 @@ it("checks if contract called balanceOf with certain wallet on the ERC20 token",
Sprawdźmy, czy testy są poprawne:
-
+
-Świetnie, wszystkie testy są zielone.
+Świetnie, wszystkie testy przechodzą pomyślnie.
-Testowanie połączeń kontraktowych z Waffle jest bardzo łatwe. I oto najlepsza część. Te wyrażenia matcher działają zarówno z normalnymi, jak i próbnymi kontraktami! Wynika to z tego, że Waffle rejestruje i filtruje połączenia EVM zamiast wstrzykiwać kod, tak jak w przypadku popularnych bibliotek testowych dla innych technologii.
+Testowanie wywołań kontraktów za pomocą Waffle jest superłatwe. A oto najlepsza część. Te matchery działają zarówno ze zwykłymi, jak i mockowanymi kontraktami! Dzieje się tak, ponieważ Waffle rejestruje i filtruje wywołania EVM, a nie wstrzykuje kod, jak ma to miejsce w przypadku popularnych bibliotek testowych dla innych technologii.
## Meta {#the-finish-line}
-Gratulacje! Teraz wiesz jak korzystać z Waffle do dynamicznego testowania połączeń i modelowania kontraktów. Istnieją o wiele bardziej interesujące funkcje, które należy odkryć. Zalecam nurkowanie w dokumentacji Waffle.
+Gratulacje! Teraz już wiesz, jak używać Waffle do dynamicznego testowania wywołań kontraktów i mockowania kontraktów. Jest o wiele więcej interesujących funkcji do odkrycia. Polecam zagłębić się w dokumentację Waffle.
-Dokumentacja Waffle'a jest dostępna [tutaj](https://ethereum-waffle.readthedocs.io/).
+Dokumentacja Waffle jest dostępna [tutaj](https://ethereum-waffle.readthedocs.io/).
-Kod źródłowy dla tego samouczka można znaleźć [tutaj](https://github.com/EthWorks/Waffle/tree/master/examples/dynamic-mocking-and-testing-calls).
+Kod źródłowy tego samouczka można znaleźć [tutaj](https://github.com/EthWorks/Waffle/tree/master/examples/dynamic-mocking-and-testing-calls).
-Samouczki mogą być interesujące:
+Samouczki, które mogą cię również zainteresować:
-- [Testowanie inteligentnych kontraktów z Waffle](/developers/tutorials/waffle-test-simple-smart-contract/)
+- [Testowanie inteligentnych kontraktów za pomocą Waffle](/developers/tutorials/waffle-test-simple-smart-contract/)
diff --git a/public/content/translations/pl/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md b/public/content/translations/pl/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
new file mode 100644
index 00000000000..886dc0abe43
--- /dev/null
+++ b/public/content/translations/pl/developers/tutorials/waffle-say-hello-world-with-hardhat-and-ethers/index.md
@@ -0,0 +1,204 @@
+---
+title: "Samouczek Waffle „witaj świecie” z Hardhat i ethers"
+description: "Stwórz swój pierwszy projekt Waffle za pomocą Hardhat i ethers.js"
+author: "MiZiet"
+tags:
+ [
+ "waffle",
+ "smart kontrakty",
+ "solidity",
+ "testowanie",
+ "hardhat",
+ "ethers.js"
+ ]
+skill: beginner
+lang: pl
+published: 2020-10-16
+---
+
+W tym [Waffle](https://ethereum-waffle.readthedocs.io) samouczku dowiemy się, jak skonfigurować prosty projekt inteligentnego kontraktu "witaj świecie", przy użyciu [Hardhat](https://hardhat.org/) i [ethers.js](https://docs.ethers.io/v5/). Następnie dowiemy się, jak dodać nową funkcjonalność do naszego inteligentnego kontraktu i jak przetestować go za pomocą Waffle.
+
+Zacznijmy od utworzenia nowego projektu:
+
+```bash
+yarn init
+```
+
+lub
+
+```bash
+npm init
+```
+
+i zainstalowania wymaganych pakietów:
+
+```bash
+yarn add -D hardhat @nomiclabs/hardhat-ethers ethers @nomiclabs/hardhat-waffle ethereum-waffle chai
+```
+
+lub
+
+```bash
+npm install -D hardhat @nomiclabs/hardhat-ethers ethers @nomiclabs/hardhat-waffle ethereum-waffle chai
+```
+
+Następnym krokiem jest utworzenie przykładowego projektu Hardhat przez uruchomienie `npx hardhat`.
+
+```bash
+888 888 888 888 888
+888 888 888 888 888
+888 888 888 888 888
+8888888888 8888b. 888d888 .d88888 88888b. 8888b. 888888
+888 888 "88b 888P" d88" 888 888 "88b "88b 888
+888 888 .d888888 888 888 888 888 888 .d888888 888
+888 888 888 888 888 Y88b 888 888 888 888 888 Y88b.
+888 888 "Y888888 888 "Y88888 888 888 "Y888888 "Y888
+
+👷 Welcome to Hardhat v2.0.3 👷
+
+? What do you want to do? …
+❯ Create a sample project
+Create an empty hardhat.config.js
+Quit
+```
+
+Wybierz `Create a sample project`
+
+Struktura naszego projektu powinna wyglądać następująco:
+
+```
+MyWaffleProject
+├── contracts
+│ └── Greeter.sol
+├── node_modules
+├── scripts
+│ └── sample-script.js
+├── test
+│ └── sample-test.js
+├── .gitattributes
+├── .gitignore
+├── hardhat.config.js
+└── package.json
+```
+
+### Teraz porozmawiajmy o niektórych z tych plików: {#now-lets-talk}
+
+- Greeter.sol - nasz inteligentny kontrakt napisany w Solidity;
+
+```solidity
+contract Greeter {
+string greeting;
+
+constructor(string memory _greeting) public {
+console.log("Deploying a Greeter with greeting:", _greeting);
+greeting = _greeting;
+}
+
+function greet() public view returns (string memory) {
+return greeting;
+}
+
+function setGreeting(string memory _greeting) public {
+console.log("Changing greeting from '%s' to '%s'", greeting, _greeting);
+greeting = _greeting;
+}
+}
+```
+
+Nasz inteligentny kontrakt można podzielić na trzy części:
+
+1. constructor - gdzie deklarujemy zmienną typu string o nazwie `greeting`,
+2. function greet - funkcja, która po wywołaniu zwróci `greeting`,
+3. function setGreeting - funkcja, która pozwala nam zmienić wartość `greeting`.
+
+- sample-test.js - nasz plik z testami
+
+```js
+describe("Greeter", function () {
+ it("Powinien zwrócić nowe powitanie po jego zmianie", async function () {
+ const Greeter = await ethers.getContractFactory("Greeter")
+ const greeter = await Greeter.deploy("Hello, world!")
+
+ await greeter.deployed()
+ expect(await greeter.greet()).to.equal("Hello, world!")
+
+ await greeter.setGreeting("Hola, mundo!")
+ expect(await greeter.greet()).to.equal("Hola, mundo!")
+ })
+})
+```
+
+### Następny krok polega na skompilowaniu naszego kontraktu i uruchomieniu testów: {#compiling-and-testing}
+
+Testy Waffle wykorzystują Mocha (framework testowy) wraz z Chai (biblioteką asercji). Wszystko, co należy zrobić, to uruchomić `npx hardhat test` i poczekać na pojawienie się następującego komunikatu.
+
+```bash
+✓ Powinien zwrócić nowe powitanie po jego zmianie
+```
+
+### Jak na razie wszystko wygląda świetnie, dodajmy trochę więcej złożoności do naszego projektu {#adding-complexity}
+
+Wyobraźmy sobie sytuację, w której ktoś dodaje pusty ciąg znaków jako powitanie. To nie byłoby miłe powitanie, prawda?
+Upewnijmy się, że tak się nie stanie:
+
+Chcemy użyć funkcji `revert` z Solidity, gdy ktoś przekaże pusty ciąg znaków. Zaletą jest to, że możemy łatwo przetestować tę funkcjonalność za pomocą matchera Chai z Waffle: `to.be.revertedWith()`.
+
+```js
+it("Powinien wykonać revert przy przekazaniu pustego ciągu znaków", async () => {
+ const Greeter = await ethers.getContractFactory("Greeter")
+ const greeter = await Greeter.deploy("Hello, world!")
+
+ await greeter.deployed()
+ await expect(greeter.setGreeting("")).to.be.revertedWith(
+ "Powitanie nie powinno być puste"
+ )
+})
+```
+
+Wygląda na to, że nasz nowy test nie zakończył się powodzeniem:
+
+```bash
+Deploying a Greeter with greeting: Hello, world!
+Changing greeting from 'Hello, world!' to 'Hola, mundo!'
+ ✓ Powinien zwrócić nowe powitanie po jego zmianie (1514ms)
+Deploying a Greeter with greeting: Hello, world!
+Changing greeting from 'Hello, world!' to ''
+ 1) Powinien wykonać revert przy przekazaniu pustego ciągu znaków
+
+
+ 1 zaliczony
+ 1 niezliczony
+```
+
+Zaimplementujmy tę funkcjonalność w naszym inteligentnym kontrakcie:
+
+```solidity
+require(bytes(_greeting).length > 0, "Powitanie nie powinno być puste");
+```
+
+Teraz nasza funkcja setGreeting wygląda następująco:
+
+```solidity
+function setGreeting(string memory _greeting) public {
+require(bytes(_greeting).length > 0, "Powitanie nie powinno być puste");
+console.log("Changing greeting from '%s' to '%s'", greeting, _greeting);
+greeting = _greeting;
+}
+```
+
+Uruchommy testy ponownie:
+
+```bash
+✓ Powinien zwrócić nowe powitanie po jego zmianie (1467ms)
+✓ Powinien wykonać revert przy przekazaniu pustego ciągu znaków (276ms)
+
+2 zaliczone (2s)
+```
+
+Gratulacje! Udało się :)
+
+### Wnioski {#conclusion}
+
+Stworzyliśmy prosty projekt z Waffle, Hardhat i ethers.js. Nauczyliśmy się, jak skonfigurować projekt, dodać test i wdrożyć nową funkcjonalność.
+
+Aby poznać więcej świetnych matcherów Chai do testowania swoich inteligentnych kontraktów, zachęcamy do sprawdzenia [oficjalnej dokumentacji Waffle](https://ethereum-waffle.readthedocs.io/en/latest/matchers.html).
diff --git a/public/content/translations/pl/developers/tutorials/waffle-test-simple-smart-contract/index.md b/public/content/translations/pl/developers/tutorials/waffle-test-simple-smart-contract/index.md
new file mode 100644
index 00000000000..3eb14d62df3
--- /dev/null
+++ b/public/content/translations/pl/developers/tutorials/waffle-test-simple-smart-contract/index.md
@@ -0,0 +1,199 @@
+---
+title: "Testowanie prostego inteligentnego kontraktu za pomocą biblioteki Waffle"
+description: "Samouczek dla początkujących"
+author: Ewa Kowalska
+tags: [ "smart kontrakty", "solidity", "Waffle", "testowanie" ]
+skill: beginner
+lang: pl
+published: 2021-02-26
+---
+
+## W tym samouczku dowiesz się, jak {#in-this-tutorial-youll-learn-how-to}
+
+- Testować zmiany salda portfela
+- Testować emisję zdarzeń z określonymi argumentami
+- Sprawdzić, czy transakcja została cofnięta
+
+## Założenia {#assumptions}
+
+- Potrafisz utworzyć nowy projekt w języku JavaScript lub TypeScript
+- Masz podstawowe doświadczenie w testach w języku JavaScript
+- Używasz menedżerów pakietów takich jak yarn lub npm
+- Posiadasz podstawową wiedzę na temat inteligentnych kontraktów i języka Solidity
+
+## Pierwsze kroki {#getting-started}
+
+Samouczek przedstawia konfigurację i uruchamianie testów za pomocą yarn, ale nie ma problemu, jeśli wolisz npm – podam odpowiednie odniesienia do oficjalnej [dokumentacji](https://ethereum-waffle.readthedocs.io/en/latest/index.html) Waffle.
+
+## Instalacja zależności {#install-dependencies}
+
+[Dodaj](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#installation) zależności ethereum-waffle i typescript do zależności deweloperskich (`dev dependencies`) swojego projektu.
+
+```bash
+yarn add --dev ethereum-waffle ts-node typescript @types/jest
+```
+
+## Przykładowy inteligentny kontrakt {#example-smart-contract}
+
+W trakcie tego samouczka będziemy pracować na przykładzie prostego inteligentnego kontraktu – EtherSplitter. Nie robi on wiele poza tym, że pozwala każdemu wysłać trochę wei i podzielić je równo między dwóch predefiniowanych odbiorców.
+Funkcja `split` wymaga, aby liczba wei była parzysta, w przeciwnym razie transakcja zostanie cofnięta. Dla obu odbiorców wykonuje transfer wei, a następnie emituje zdarzenie `Transfer`.
+
+Umieść fragment kodu EtherSplitter w pliku `src/EtherSplitter.sol`.
+
+```solidity
+pragma solidity ^0.6.0;
+
+contract EtherSplitter {
+ address payable receiver1;
+ address payable receiver2;
+
+ event Transfer(address from, address to, uint256 amount);
+
+ constructor(address payable _address1, address payable _address2) public {
+ receiver1 = _address1;
+ receiver2 = _address2;
+ }
+
+ function split() public payable {
+ require(msg.value % 2 == 0, 'Uneven wei amount not allowed');
+ receiver1.transfer(msg.value / 2);
+ emit Transfer(msg.sender, receiver1, msg.value / 2);
+ receiver2.transfer(msg.value / 2);
+ emit Transfer(msg.sender, receiver2, msg.value / 2);
+ }
+}
+```
+
+## Kompilacja kontraktu {#compile-the-contract}
+
+Aby [skompilować](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#compiling-the-contract) kontrakt, dodaj następujący wpis do pliku package.json:
+
+```json
+"scripts": {
+ "build": "waffle"
+ }
+```
+
+Następnie utwórz plik konfiguracyjny Waffle w głównym katalogu projektu – `waffle.json` – a następnie wklej do niego następującą konfigurację:
+
+```json
+{
+ "compilerType": "solcjs",
+ "compilerVersion": "0.6.2",
+ "sourceDirectory": "./src",
+ "outputDirectory": "./build"
+}
+```
+
+Uruchom `yarn build`. W rezultacie pojawi się katalog `build` ze skompilowanym kontraktem EtherSplitter w formacie JSON.
+
+## Konfiguracja testu {#test-setup}
+
+Testowanie za pomocą Waffle wymaga użycia mechanizmów dopasowujących (matcherów) Chai oraz biblioteki Mocha, więc musisz je [dodać](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests) do swojego projektu. Zaktualizuj plik package.json i dodaj wpis `test` w sekcji `scripts`:
+
+```json
+"scripts": {
+ "build": "waffle",
+ "test": "export NODE_ENV=test && mocha -r ts-node/register 'test/**/*.test.ts'"
+ }
+```
+
+Jeśli chcesz [uruchomić](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#running-tests) testy, po prostu wykonaj polecenie `yarn test`.
+
+## Testowanie {#testing}
+
+Teraz utwórz katalog `test` i nowy plik `test\EtherSplitter.test.ts`.
+Skopiuj poniższy fragment kodu i wklej go do naszego pliku testowego.
+
+```ts
+import { expect, use } from "chai"
+import { Contract } from "ethers"
+import { deployContract, MockProvider, solidity } from "ethereum-waffle"
+import EtherSplitter from "../build/EtherSplitter.json"
+
+use(solidity)
+
+describe("Ether Splitter", () => {
+ const [sender, receiver1, receiver2] = new MockProvider().getWallets()
+ let splitter: Contract
+
+ beforeEach(async () => {
+ splitter = await deployContract(sender, EtherSplitter, [
+ receiver1.address,
+ receiver2.address,
+ ])
+ })
+
+ // tutaj dodaj testy
+})
+```
+
+Kilka słów na początek.
+`MockProvider` udostępnia testową wersję blockchaina. Udostępnia również portfele testowe, które posłużą nam do testowania kontraktu EtherSplitter. Możemy uzyskać do dziesięciu portfeli, wywołując metodę `getWallets()` na dostawcy. W tym przykładzie otrzymujemy trzy portfele – dla nadawcy i dwóch odbiorców.
+
+Następnie deklarujemy zmienną o nazwie „splitter” – jest to nasz testowy kontrakt EtherSplitter. Jest on tworzony przed każdym wykonaniem pojedynczego testu za pomocą metody `deployContract`. Ta metoda symuluje wdrożenie kontraktu z portfela przekazanego jako pierwszy parametr (w naszym przypadku portfela nadawcy). Drugim parametrem jest ABI i kod bajtowy testowanego kontraktu – przekazujemy tam plik JSON skompilowanego kontraktu EtherSplitter z katalogu `build`. Trzeci parametr to tablica z argumentami konstruktora kontraktu, którymi w naszym przypadku są dwa adresy odbiorców.
+
+## changeBalances {#changebalances}
+
+Najpierw sprawdzimy, czy metoda `split` faktycznie zmienia salda portfeli odbiorców. Jeśli podzielimy 50 wei z konta nadawcy, spodziewalibyśmy się, że salda obu odbiorców wzrosną o 25 wei. Użyjemy matchera `changeBalances` z Waffle:
+
+```ts
+it("Zmienia salda kont", async () => {
+ await expect(() => splitter.split({ value: 50 })).to.changeBalances(
+ [receiver1, receiver2],
+ [25, 25]
+ )
+})
+```
+
+Jako pierwszy parametr matchera przekazujemy tablicę portfeli odbiorców, a jako drugi – tablicę oczekiwanych wzrostów na odpowiednich kontach.
+Gdybyśmy chcieli sprawdzić saldo jednego konkretnego portfela, moglibyśmy również użyć matchera `changeBalance`, który nie wymaga przekazywania tablic, jak w poniższym przykładzie:
+
+```ts
+it("Zmienia saldo konta", async () => {
+ await expect(() => splitter.split({ value: 50 })).to.changeBalance(
+ receiver1,
+ 25
+ )
+})
+```
+
+Zwróć uwagę, że w obu przypadkach (`changeBalance` i `changeBalances`) przekazujemy funkcję `split` jako wywołanie zwrotne (callback), ponieważ matcher musi mieć dostęp do stanu sald przed i po wywołaniu.
+
+Następnie przetestujemy, czy zdarzenie `Transfer` zostało wyemitowane po każdym transferze wei. Sięgniemy po kolejny matcher z biblioteki Waffle:
+
+## Emit {#emit}
+
+```ts
+it("Emituje zdarzenie przy transferze do pierwszego odbiorcy", async () => {
+ await expect(splitter.split({ value: 50 }))
+ .to.emit(splitter, "Transfer")
+ .withArgs(sender.address, receiver1.address, 25)
+})
+
+it("Emituje zdarzenie przy transferze do drugiego odbiorcy", async () => {
+ await expect(splitter.split({ value: 50 }))
+ .to.emit(splitter, "Transfer")
+ .withArgs(sender.address, receiver2.address, 25)
+})
+```
+
+Matcher `emit` pozwala nam sprawdzić, czy kontrakt wyemitował zdarzenie podczas wywoływania metody. Jako parametry matchera `emit` podajemy kontrakt testowy, który naszym zdaniem wyemituje zdarzenie, wraz z nazwą tego zdarzenia. W naszym przypadku kontraktem testowym jest `splitter`, a nazwą zdarzenia – `Transfer`. Możemy również zweryfikować dokładne wartości argumentów, z którymi zdarzenie zostało wyemitowane – przekazujemy do matchera `withArgs` tyle argumentów, ile oczekuje deklaracja naszego zdarzenia. W przypadku kontraktu EtherSplitter przekazujemy adresy nadawcy i odbiorcy wraz z kwotą transferowanych wei.
+
+## revertedWith {#revertedwith}
+
+Jako ostatni przykład sprawdzimy, czy transakcja została cofnięta w przypadku nieparzystej liczby wei. Użyjemy do tego matchera `revertedWith`:
+
+```ts
+it("Cofa transakcję, gdy kwota Wei jest nieparzysta", async () => {
+ await expect(splitter.split({ value: 51 })).to.be.revertedWith(
+ "Uneven wei amount not allowed"
+ )
+})
+```
+
+Test, jeśli zakończy się pomyślnie, upewni nas, że transakcja rzeczywiście została cofnięta. Musi jednak istnieć dokładna zgodność między komunikatami, które przekazaliśmy w instrukcji `require`, a komunikatem, którego oczekujemy w `revertedWith`. Jeśli wrócimy do kodu kontraktu EtherSplitter, w instrukcji `require` dla kwoty wei podajemy komunikat: „Uneven wei amount not allowed”. Jest on zgodny z komunikatem, którego oczekujemy w naszym teście. Gdyby nie były takie same, test zakończyłby się niepowodzeniem.
+
+## Gratulacje! {#congratulations}
+
+Zrobiłeś(-aś) pierwszy duży krok w kierunku testowania inteligentnych kontraktów za pomocą Waffle!
diff --git a/public/content/translations/pl/developers/tutorials/yellow-paper-evm/index.md b/public/content/translations/pl/developers/tutorials/yellow-paper-evm/index.md
new file mode 100644
index 00000000000..625cd37caca
--- /dev/null
+++ b/public/content/translations/pl/developers/tutorials/yellow-paper-evm/index.md
@@ -0,0 +1,278 @@
+---
+title: Zrozumienie specyfikacji EVM z Yellow Paper
+description: "Zrozumienie części Yellow Paper, formalnej specyfikacji Ethereum, która wyjaśnia Wirtualną Maszynę Ethereum (EVM)."
+author: "qbzzt"
+tags: [ "evm" ]
+skill: intermediate
+lang: pl
+published: 2022-05-15
+---
+
+[Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) to formalna specyfikacja Ethereum. Z wyjątkiem zmian wprowadzonych w ramach [procesu EIP](/eips/), zawiera ona dokładny opis działania wszystkiego. Jest napisana jako praca matematyczna, która zawiera terminologię, która może nie być znana programistom. W tym artykule dowiesz się, jak ją czytać, a co za tym idzie, inne powiązane prace matematyczne.
+
+## Który Yellow Paper? {#which-yellow-paper}
+
+Podobnie jak prawie wszystko inne w Ethereum, Yellow Paper ewoluuje z czasem. Aby móc odnieść się do konkretnej wersji, załadowałem [aktualną wersję w momencie pisania tego tekstu](yellow-paper-berlin.pdf). Numery sekcji, stron i równań, których używam, będą odnosić się do tej wersji. Dobrym pomysłem jest otwarcie jej w innym oknie podczas czytania tego dokumentu.
+
+### Dlaczego EVM? {#why-the-evm}
+
+Oryginalny Yellow Paper został napisany na samym początku rozwoju Ethereum. Opisuje oryginalny mechanizm konsensusu oparty na proof-of-work, który był pierwotnie używany do zabezpieczania sieci. Jednakże we wrześniu 2022 roku Ethereum wyłączyło proof-of-work i zaczęło używać konsensusu opartego na proof-of-stake. Ten samouczek skupi się na częściach Yellow Paper definiujących Wirtualną Maszynę Ethereum. EVM pozostała niezmieniona po przejściu na proof-of-stake (z wyjątkiem zwracanej wartości kodu operacyjnego DIFFICULTY).
+
+## 9 Model wykonania {#9-execution-model}
+
+Ta sekcja (s. 12-14) zawiera większość definicji EVM.
+
+Termin _stan systemu_ obejmuje wszystko, co trzeba wiedzieć o systemie, aby go uruchomić. W typowym komputerze oznacza to pamięć, zawartość rejestrów itp.
+
+[Maszyna Turinga](https://en.wikipedia.org/wiki/Turing_machine) jest modelem obliczeniowym. Zasadniczo jest to uproszczona wersja komputera, o której udowodniono, że ma taką samą zdolność do wykonywania obliczeń jak normalny komputer (wszystko, co może obliczyć komputer, może obliczyć maszyna Turinga i na odwrót). Ten model ułatwia udowadnianie różnych twierdzeń o tym, co jest, a co nie jest obliczalne.
+
+Termin [kompletność Turinga](https://en.wikipedia.org/wiki/Turing_completeness) oznacza komputer, który może wykonywać te same obliczenia co maszyna Turinga. Maszyny Turinga mogą wpaść w nieskończone pętle, a EVM nie, ponieważ zabrakłoby jej gazu, więc jest tylko quasi-kompletna w sensie Turinga.
+
+## 9.1 Podstawy {#91-basics}
+
+Ta sekcja przedstawia podstawy EVM i porównuje ją z innymi modelami obliczeniowymi.
+
+[Maszyna stosowa](https://en.wikipedia.org/wiki/Stack_machine) to komputer, który przechowuje dane pośrednie nie w rejestrach, ale na [**stosie**](https://en.wikipedia.org/wiki/Stack_\(abstract_data_type\)). Jest to preferowana architektura dla maszyn wirtualnych, ponieważ jest łatwa w implementacji, co oznacza, że błędy i luki w zabezpieczeniach są znacznie mniej prawdopodobne. Pamięć na stosie jest podzielona na 256-bitowe słowa. Zostało to wybrane, ponieważ jest to wygodne dla podstawowych operacji kryptograficznych Ethereum, takich jak haszowanie Keccak-256 i obliczenia na krzywych eliptycznych. Maksymalny rozmiar stosu to 1024 elementy (1024 x 256 bitów). Kiedy kody operacyjne są wykonywane, zazwyczaj pobierają swoje parametry ze stosu. Istnieją kody operacyjne specjalnie do reorganizacji elementów na stosie, takie jak `POP` (usuwa element z wierzchołka stosu), `DUP_N` (duplikuje N-ty element na stosie) itp.
+
+EVM posiada również ulotną przestrzeń zwaną **pamięcią**, która jest używana do przechowywania danych podczas wykonywania. Pamięć ta jest zorganizowana w 32-bajtowe słowa. Wszystkie lokalizacje w pamięci są inicjalizowane do zera. Jeśli wykonasz ten kod w [Yul](https://docs.soliditylang.org/en/latest/yul.html), aby dodać słowo do pamięci, wypełni on 32 bajty pamięci, uzupełniając pustą przestrzeń w słowie zerami, tzn. tworzy jedno słowo – z zerami w lokalizacjach 0–29, 0x60 w lokalizacji 30 i 0xA7 w lokalizacji 31.
+
+```yul
+mstore(0, 0x60A7)
+```
+
+`mstore` to jeden z trzech kodów operacyjnych, które EVM zapewnia do interakcji z pamięcią – ładuje słowo do pamięci. Pozostałe dwa to `mstore8`, który ładuje pojedynczy bajt do pamięci, oraz `mload`, który przenosi słowo z pamięci na stos.
+
+EVM posiada również oddzielną, nietrwałą **pamięć trwałą (storage)**, która jest utrzymywana jako część stanu systemu – jest ona zorganizowana w tablice słów (w przeciwieństwie do adresowalnych słowami tablic bajtów na stosie). W tej pamięci trwałej kontrakty przechowują trwałe dane — kontrakt może wchodzić w interakcje tylko z własną pamięcią trwałą. Pamięć trwała jest zorganizowana w mapowania klucz-wartość.
+
+Chociaż nie jest to wspomniane w tej sekcji Yellow Paper, warto również wiedzieć, że istnieje czwarty rodzaj pamięci. **Calldata** to adresowalna bajtowo pamięć tylko do odczytu, używana do przechowywania wartości przekazanej wraz z parametrem `data` transakcji. EVM ma określone kody operacyjne do zarządzania `calldata`. `calldatasize` zwraca rozmiar danych. `calldataload` ładuje dane na stos. `calldatacopy` kopiuje dane do pamięci.
+
+Standardowa [architektura von Neumanna](https://en.wikipedia.org/wiki/Von_Neumann_architecture) przechowuje kod i dane w tej samej pamięci. EVM nie przestrzega tego standardu ze względów bezpieczeństwa — współdzielenie pamięci ulotnej umożliwia zmianę kodu programu. Zamiast tego kod jest zapisywany w pamięci trwałej.
+
+Istnieją tylko dwa przypadki, w których kod jest wykonywany z pamięci:
+
+- Gdy kontrakt tworzy inny kontrakt (przy użyciu [`CREATE`](https://www.evm.codes/#f0) lub [`CREATE2`](https://www.evm.codes/#f5)), kod konstruktora kontraktu pochodzi z pamięci.
+- Podczas tworzenia _dowolnego_ kontraktu kod konstruktora jest uruchamiany, a następnie zwraca kod właściwego kontraktu, również z pamięci.
+
+Termin wykonanie wyjątkowe oznacza wyjątek, który powoduje zatrzymanie wykonywania bieżącego kontraktu.
+
+## 9.2 Przegląd opłat {#92-fees-overview}
+
+W tej sekcji wyjaśniono, w jaki sposób obliczane są opłaty za gaz. Istnieją trzy koszty:
+
+### Koszt kodu operacyjnego {#opcode-cost}
+
+Nieodłączny koszt danego kodu operacyjnego. Aby uzyskać tę wartość, znajdź grupę kosztów kodu operacyjnego w Dodatku H (s. 28, pod równaniem (327)) i znajdź grupę kosztów w równaniu (324). Daje to funkcję kosztu, która w większości przypadków wykorzystuje parametry z Dodatku G (s. 27).
+
+Na przykład kod operacyjny [`CALLDATACOPY`](https://www.evm.codes/#37) należy do grupy _Wcopy _. Koszt kodu operacyjnego dla tej grupy to _Gverylow +Gcopy ×⌈μs [2]÷32⌉_. Patrząc na Dodatek G, widzimy, że obie stałe wynoszą 3, co daje nam _3+3×⌈μs [2]÷32⌉_.
+
+Nadal musimy rozszyfrować wyrażenie _⌈μs [2]÷32⌉_. Zewnętrzna część, _⌈ \ ⌉_, to funkcja sufitu, czyli funkcja, która dla danej wartości zwraca najmniejszą liczbę całkowitą, która nie jest mniejsza od tej wartości. Na przykład _⌈2,5⌉ = ⌈3⌉ = 3_. Wewnętrzna część to _μs [2]÷32_. Patrząc na sekcję 3 (Konwencje) na s. 3, _μ_ to stan maszyny. Stan maszyny jest zdefiniowany w sekcji 9.4.1 na s. 13. Zgodnie z tą sekcją jednym z parametrów stanu maszyny jest _s_ dla stosu. Podsumowując, wydaje się, że _μs [2]_ to lokalizacja #2 na stosie. Patrząc na [kod operacyjny](https://www.evm.codes/#37), lokalizacja #2 na stosie to rozmiar danych w bajtach. Patrząc na inne kody operacyjne w grupie Wcopy , [`CODECOPY`](https://www.evm.codes/#39) i [`RETURNDATACOPY`](https://www.evm.codes/#3e), mają one również rozmiar danych w tej samej lokalizacji. Zatem _⌈μs [2]÷32⌉_ to liczba 32-bajtowych słów wymaganych do przechowywania kopiowanych danych. Podsumowując wszystko, nieodłączny koszt [`CALLDATACOPY`](https://www.evm.codes/#37) to 3 jednostki gazu plus 3 za każde kopiowane słowo danych.
+
+### Koszt bieżący {#running-cost}
+
+Koszt uruchomienia kodu, który wywołujemy.
+
+- W przypadku [`CREATE`](https://www.evm.codes/#f0) i [`CREATE2`](https://www.evm.codes/#f5) jest to konstruktor nowego kontraktu.
+- W przypadku [`CALL`](https://www.evm.codes/#f1), [`CALLCODE`](https://www.evm.codes/#f2), [`STATICCALL`](https://www.evm.codes/#fa) lub [`DELEGATECALL`](https://www.evm.codes/#f4) jest to kontrakt, który wywołujemy.
+
+### Koszt rozszerzenia pamięci {#expanding-memory-cost}
+
+Koszt rozszerzenia pamięci (w razie potrzeby).
+
+W równaniu 324 wartość ta jest zapisana jako _Cmem (μi ')-Cmem (μi )_. Patrząc ponownie na sekcję 9.4.1, widzimy, że _μi _ to liczba słów w pamięci. Zatem _μi _ to liczba słów w pamięci przed kodem operacyjnym, a _μi '_ to liczba słów w pamięci po kodzie operacyjnym.
+
+Funkcja _Cmem _ jest zdefiniowana w równaniu 326: _Cmem (a) = Gmemory × a + ⌊a2 ÷ 512⌋_. _⌊x⌋_ to funkcja podłogi, czyli funkcja, która dla danej wartości zwraca największą liczbę całkowitą, która nie jest większa od tej wartości. Na przykład _⌊2,5⌋ = ⌊2⌋ = 2._ Gdy _a < √512_, _a2 < 512_, a wynik funkcji podłogi wynosi zero. Zatem dla pierwszych 22 słów (704 bajtów) koszt rośnie liniowo wraz z liczbą wymaganych słów pamięci. Powyżej tego punktu _⌊a2 ÷ 512⌋_ jest dodatnie. Gdy wymagana pamięć jest wystarczająco duża, koszt gazu jest proporcjonalny do kwadratu ilości pamięci.
+
+**Uwaga**: te czynniki wpływają tylko na _nieodłączny_ koszt gazu – nie uwzględniają rynku opłat ani napiwków dla walidatorów, które określają, ile użytkownik końcowy musi zapłacić – to tylko surowy koszt uruchomienia określonej operacji na EVM.
+
+[Przeczytaj więcej o gazie](/developers/docs/gas/).
+
+## 9.3 Środowisko wykonawcze {#93-execution-env}
+
+Środowisko wykonawcze to krotka, _I_, która zawiera informacje, które nie są częścią stanu blockchaina ani EVM.
+
+| Parametr | Kod operacyjny dostępu do danych | Kod Solidity do dostępu do danych |
+| --------------- | ---------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- |
+| _Ia _ | [`ADRES`](https://www.evm.codes/#30) | `address(this)` |
+| _Io _ | [`ORIGIN`](https://www.evm.codes/#32) | `tx.origin` |
+| _Ip _ | [`GASPRICE`](https://www.evm.codes/#3a) | `tx.gasprice` |
+| _Id _ | [`CALLDATALOAD`](https://www.evm.codes/#35) itp. | `msg.data` |
+| _Is _ | [`CALLER`](https://www.evm.codes/#33) | `msg.sender` |
+| _Iv _ | [`CALLVALUE`](https://www.evm.codes/#34) | `msg.value` |
+| _Ib _ | [`CODECOPY`](https://www.evm.codes/#39) | `address(this).code` |
+| _IH _ | Pola nagłówka bloku, takie jak [`NUMBER`](https://www.evm.codes/#43) i [`DIFFICULTY`](https://www.evm.codes/#44) | `block.number`, `block.difficulty`, itp. |
+| _Ie _ | Głębokość stosu wywołań dla wywołań między kontraktami (w tym tworzenie kontraktów) | |
+| _Iw _ | Czy EVM może zmieniać stan, czy działa statycznie | |
+
+Kilka innych parametrów jest niezbędnych do zrozumienia reszty sekcji 9:
+
+| Parametr | Zdefiniowano w sekcji | Znaczenie |
+| -------- | -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| _σ_ | 2 (s. 2, równanie 1) | Stan blockchaina |
+| _g_ | 9.3 (s. 13) | Pozostały gaz |
+| _A_ | 6.1 (s. 8) | Naliczony podstan (zmiany zaplanowane na zakończenie transakcji) |
+| _o_ | 9.3 (s. 13) | Dane wyjściowe — zwracany wynik w przypadku transakcji wewnętrznej (gdy jeden kontrakt wywołuje drugi) i wywołania funkcji widoku (gdy pytasz tylko o informacje, więc nie ma potrzeby czekać na transakcję) |
+
+## 9.4 Przegląd wykonania {#94-execution-overview}
+
+Teraz, gdy mamy już wszystkie wstępne informacje, możemy w końcu zacząć pracować nad tym, jak działa EVM.
+
+Równania 137–142 podają nam warunki początkowe do uruchomienia EVM:
+
+| Symbol | Wartość początkowa | Znaczenie |
+| ---------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| _μg _ | _g_ | Pozostały gaz |
+| _μpc _ | _0_ | Licznik programu, adres następnej instrukcji do wykonania |
+| _μm _ | _(0, 0, ...)_ | Pamięć, zainicjalizowana samymi zerami |
+| _μi _ | _0_ | Najwyższa używana lokalizacja pamięci |
+| _μs _ | _()_ | Stos, początkowo pusty |
+| _μo _ | _∅_ | Dane wyjściowe, pusty zbiór do momentu, gdy zatrzymamy się z danymi zwrotnymi ([`RETURN`](https://www.evm.codes/#f3) lub [`REVERT`](https://www.evm.codes/#fd)) lub bez nich ([`STOP`](https://www.evm.codes/#00) lub [`SELFDESTRUCT`](https://www.evm.codes/#ff)). |
+
+Równanie 143 mówi nam, że w każdym momencie podczas wykonywania istnieją cztery możliwe warunki i co z nimi zrobić:
+
+1. `Z(σ,μ,A,I)`. Z reprezentuje funkcję, która sprawdza, czy operacja tworzy nieprawidłowe przejście stanu (zobacz [zatrzymanie wyjątkowe](#942-exceptional-halting)). Jeśli wynikiem jest Prawda, nowy stan jest identyczny ze starym (z wyjątkiem tego, że gaz jest spalany), ponieważ zmiany nie zostały zaimplementowane.
+2. Jeśli wykonywany jest kod operacyjny [`REVERT`](https://www.evm.codes/#fd), nowy stan jest taki sam jak stary stan, a część gazu przepada.
+3. Jeśli sekwencja operacji jest zakończona, co jest sygnalizowane przez [`RETURN`](https://www.evm.codes/#f3)), stan jest aktualizowany do nowego stanu.
+4. Jeśli nie jesteśmy w jednym z warunków końcowych 1-3, kontynuuj działanie.
+
+## 9.4.1 Stan maszyny {#941-machine-state}
+
+Ta sekcja wyjaśnia bardziej szczegółowo stan maszyny. Określa, że _w_ to bieżący kod operacyjny. Jeśli _μpc _ jest mniejsze niż _||Ib ||_, długość kodu, to ten bajt (_Ib [μpc ]_) jest kodem operacyjnym. W przeciwnym razie kod operacyjny jest zdefiniowany jako [`STOP`](https://www.evm.codes/#00).
+
+Ponieważ jest to [maszyna stosowa](https://en.wikipedia.org/wiki/Stack_machine), musimy śledzić liczbę elementów zdjętych ze stosu (_δ_) i umieszczonych na nim (_α_) przez każdy kod operacyjny.
+
+## 9.4.2 Wyjątkowe zatrzymanie {#942-exceptional-halt}
+
+W tej sekcji zdefiniowano funkcję _Z_, która określa, kiedy mamy do czynienia z nienormalnym zakończeniem. Jest to funkcja [logiczna](https://en.wikipedia.org/wiki/Boolean_data_type), więc używa [_∨_ dla lub logicznego](https://en.wikipedia.org/wiki/Logical_disjunction) i [_∧_ dla i logicznego](https://en.wikipedia.org/wiki/Logical_conjunction).
+
+Mamy wyjątkowe zatrzymanie, jeśli którykolwiek z tych warunków jest prawdziwy:
+
+- **_μg < C(σ,μ,A,I)_**
+ Jak widzieliśmy w sekcji 9.2, _C_ to funkcja, która określa koszt gazu. Nie ma wystarczającej ilości gazu na pokrycie następnego kodu operacyjnego.
+
+- **_δw =∅_**
+ Jeśli liczba elementów zdejmowanych dla kodu operacyjnego jest niezdefiniowana, to sam kod operacyjny jest niezdefiniowany.
+
+- **_|| μs || < δw _**
+ Niedomiar stosu, niewystarczająca liczba elementów na stosie dla bieżącego kodu operacyjnego.
+
+- **_w = JUMP ∧ μs [0]∉D(Ib )_**
+ Kod operacyjny to [`JUMP`](https://www.evm.codes/#56), a adres to nie [`JUMPDEST`](https://www.evm.codes/#5b). Skoki są ważne _tylko_ wtedy, gdy miejscem docelowym jest [`JUMPDEST`](https://www.evm.codes/#5b).
+
+- **_w = JUMPI ∧ μs [1]≠0 ∧ μs [0] ∉ D(Ib )_**
+ Kod operacyjny to [`JUMPI`](https://www.evm.codes/#57), warunek jest prawdziwy (niezerowy), więc skok powinien nastąpić, a adres nie jest [`JUMPDEST`](https://www.evm.codes/#5b). Skoki są ważne _tylko_ wtedy, gdy miejscem docelowym jest [`JUMPDEST`](https://www.evm.codes/#5b).
+
+- **_w = RETURNDATACOPY ∧ μs [1]+μs [2]>|| μo ||_**
+ Kod operacyjny to [`RETURNDATACOPY`](https://www.evm.codes/#3e). W tym kodzie operacyjnym element stosu _μs [1]_ to przesunięcie, od którego należy odczytywać dane w buforze danych zwrotnych, a element stosu _μs [2]_ to długość danych. Ten warunek występuje, gdy próbujesz odczytać dane poza końcem bufora danych zwrotnych. Należy zauważyć, że nie ma podobnego warunku dla calldata ani dla samego kodu. Gdy próbujesz odczytać dane poza końcem tych buforów, otrzymujesz po prostu zera.
+
+- **_|| μs || - δw + αw > 1024_**
+
+ Przepełnienie stosu. Jeśli uruchomienie kodu operacyjnego spowoduje, że stos będzie zawierał ponad 1024 elementy, przerwij.
+
+- **_¬Iw ∧ W(w,μ)_**
+ Czy działamy statycznie ([¬ to negacja](https://en.wikipedia.org/wiki/Negation), a _Iw _ jest prawdziwe, gdy możemy zmienić stan blockchaina)? Jeśli tak i próbujemy wykonać operację zmiany stanu, nie może ona się powieść.
+
+ Funkcja _W(w,μ)_ jest zdefiniowana później w równaniu 150. _W(w,μ)_ jest prawdą, jeśli jeden z tych warunków jest prawdziwy:
+
+ - **_w ∈ \{CREATE, CREATE2, SSTORE, SELFDESTRUCT}_**
+ Te kody operacyjne zmieniają stan, tworząc nowy kontrakt, przechowując wartość lub niszcząc bieżący kontrakt.
+
+ - **_LOG0≤w ∧ w≤LOG4_**
+ Jeśli jesteśmy wywoływani statycznie, nie możemy emitować wpisów dziennika.
+ Kody operacyjne dziennika znajdują się w zakresie od [`LOG0` (A0)](https://www.evm.codes/#a0) do [`LOG4` (A4)](https://www.evm.codes/#a4).
+ Liczba po kodzie operacyjnym dziennika określa, ile tematów zawiera wpis dziennika.
+
+ - **_w=CALL ∧ μs [2]≠0_**
+ Możesz wywołać inny kontrakt, gdy jesteś statyczny, ale jeśli to zrobisz, nie możesz przelać do niego ETH.
+
+- **_w = SSTORE ∧ μg ≤ Gcallstipend _**
+ Nie można uruchomić [`SSTORE`](https://www.evm.codes/#55), chyba że masz więcej gazu niż Gcallstipend (zdefiniowane jako 2300 w Dodatku G).
+
+## 9.4.3 Prawidłowość miejsca docelowego skoku {#943-jump-dest-valid}
+
+Tutaj formalnie definiujemy, czym są kody operacyjne [`JUMPDEST`](https://www.evm.codes/#5b). Nie możemy po prostu szukać wartości bajtowej 0x5B, ponieważ może ona znajdować się wewnątrz PUSH (a zatem być danymi, a nie kodem operacyjnym).
+
+W równaniu (153) definiujemy funkcję _N(i,w)_. Pierwszy parametr, _i_, to lokalizacja kodu operacyjnego. Drugi, _w_, to sam kod operacyjny. Jeśli _w∈[PUSH1, PUSH32]_, oznacza to, że kod operacyjny to PUSH (nawiasy kwadratowe definiują zakres, który obejmuje punkty końcowe). W takim przypadku następny kod operacyjny znajduje się w _i+2+(w−PUSH1)_. W przypadku [`PUSH1`](https://www.evm.codes/#60) musimy przesunąć się o dwa bajty (sam PUSH i jednobajtowa wartość), w przypadku [`PUSH2`](https://www.evm.codes/#61) musimy przesunąć się o trzy bajty, ponieważ jest to dwubajtowa wartość itd. Wszystkie inne kody operacyjne EVM mają tylko jeden bajt długości, więc we wszystkich innych przypadkach _N(i,w)=i+1_.
+
+Ta funkcja jest używana w równaniu (152) do zdefiniowania _DJ (c,i)_, który jest [zbiorem](https://en.wikipedia.org/wiki/Set_\(mathematics\)) wszystkich prawidłowych miejsc docelowych skoku w kodzie _c_, zaczynając od lokalizacji kodu operacyjnego _i_. Ta funkcja jest zdefiniowana rekurencyjnie. Jeśli _i≥||c||_, oznacza to, że jesteśmy na końcu kodu lub za nim. Nie znajdziemy już żadnych miejsc docelowych skoku, więc po prostu zwróć pusty zbiór.
+
+We wszystkich innych przypadkach patrzymy na resztę kodu, przechodząc do następnego kodu operacyjnego i pobierając zbiór, zaczynając od niego. _c[i]_ to bieżący kod operacyjny, więc _N(i,c[i])_ to lokalizacja następnego kodu operacyjnego. _DJ (c,N(i,c[i]))_ jest zatem zbiorem prawidłowych miejsc docelowych skoku, który zaczyna się od następnego kodu operacyjnego. Jeśli bieżący kod operacyjny nie jest `JUMPDEST`, po prostu zwróć ten zbiór. Jeśli jest to `JUMPDEST`, umieść go w zbiorze wyników i zwróć go.
+
+## 9.4.4 Normalne zatrzymanie {#944-normal-halt}
+
+Funkcja zatrzymania _H_ może zwracać trzy typy wartości.
+
+- Jeśli nie jesteśmy w kodzie operacyjnym zatrzymania, zwróć _∅_, pusty zbiór. Zgodnie z konwencją wartość ta jest interpretowana jako logiczny fałsz.
+- Jeśli mamy kod operacyjny zatrzymania, który nie generuje danych wyjściowych (albo [`STOP`](https://www.evm.codes/#00), albo [`SELFDESTRUCT`](https://www.evm.codes/#ff)), zwróć sekwencję zerowej liczby bajtów jako wartość zwracaną. Należy zauważyć, że jest to zupełnie co innego niż pusty zbiór. Ta wartość oznacza, że EVM naprawdę się zatrzymała, tylko nie ma danych zwrotnych do odczytania.
+- Jeśli mamy kod operacyjny zatrzymania, który generuje dane wyjściowe (albo [`RETURN`](https://www.evm.codes/#f3), albo [`REVERT`](https://www.evm.codes/#fd)), zwróć sekwencję bajtów określoną przez ten kod operacyjny. Ta sekwencja jest pobierana z pamięci, wartość na szczycie stosu (_μs [0]_) to pierwszy bajt, a wartość za nią (_μs [1]_) to długość.
+
+## H.2 Zestaw instrukcji {#h2-instruction-set}
+
+Zanim przejdziemy do ostatniej podsekcji EVM, 9.5, spójrzmy na same instrukcje. Są one zdefiniowane w Dodatku H.2, który zaczyna się na s. 29. Wszystko, co nie jest określone jako zmieniające się wraz z tym konkretnym kodem operacyjnym, powinno pozostać takie samo. Zmienne, które się zmieniają, są określone jako \′.
+
+Spójrzmy na przykład na kod operacyjny [`ADD`](https://www.evm.codes/#01).
+
+| Wartość | Mnemonik | δ | α | Opis |
+| ------: | -------- | - | - | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 0x01 | ADD | 2 | 1 | Operacja dodawania. |
+| | | | | _μ′s [0] ≡ μs [0] + μs [1]_ |
+
+_δ_ to liczba wartości, które zdejmujemy ze stosu. W tym przypadku dwie, ponieważ dodajemy dwie górne wartości.
+
+_α_ to liczba wartości, które odkładamy na stos. W tym przypadku jedna, suma.
+
+Zatem nowy wierzchołek stosu (_μ′s [0]_) jest sumą starego wierzchołka stosu (_μs [0]_) i starej wartości pod nim (_μs [1]_).
+
+Zamiast przechodzić przez wszystkie kody operacyjne w postaci „listy przyprawiającej o zawrót głowy”, ten artykuł wyjaśnia tylko te kody operacyjne, które wprowadzają coś nowego.
+
+| Wartość | Mnemonik | δ | α | Opis |
+| ------: | --------- | - | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 0x20 | KECCAK256 | 2 | 1 | Oblicz hasz Keccak-256. |
+| | | | | _μ′s [0] ≡ KEC(μm [μs [0] . . . (μs [0] + μs [1] − 1)])_ |
+| | | | | _μ′i ≡ M(μi ,μs [0],μs [1])_ |
+
+Jest to pierwszy kod operacyjny, który uzyskuje dostęp do pamięci (w tym przypadku tylko do odczytu). Może on jednak wykraczać poza obecne granice pamięci, więc musimy zaktualizować _μi ._ Robimy to za pomocą funkcji _M_ zdefiniowanej w równaniu 328 na s. 29.
+
+| Wartość | Mnemonik | δ | α | Opis |
+| ------: | -------- | - | - | --------------------------------------------------- |
+| 0x31 | BALANCE | 1 | 1 | Pobierz saldo danego konta. |
+| | | | | ... |
+
+Adres, którego saldo musimy znaleźć to _μs [0] mod 2160 _. Wierzchołek stosu to adres, ale ponieważ adresy mają tylko 160 bitów, obliczamy wartość [modulo](https://en.wikipedia.org/wiki/Modulo_operation) 2160 .
+
+Jeśli _σ[μs [0] mod 2160 ] ≠ ∅_, oznacza to, że istnieją informacje o tym adresie. W takim przypadku _σ[μs [0] mod 2160 ]b _ to saldo dla tego adresu. Jeśli _σ[μs [0] mod 2160 ] = ∅_, oznacza to, że ten adres jest niezainicjalizowany, a saldo wynosi zero. Listę pól informacyjnych konta można zobaczyć w sekcji 4.1 na s. 4.
+
+Drugie równanie, _A'a ≡ Aa ∪ \{μs [0] mod 2160 }_, jest związane z różnicą w kosztach między dostępem do ciepłej pamięci trwałej (pamięci, do której ostatnio uzyskano dostęp i która prawdopodobnie jest w pamięci podręcznej) a zimną pamięcią trwałą (pamięcią, do której nie było dostępu i która prawdopodobnie znajduje się w wolniejszej pamięci, której odzyskanie jest droższe). _Aa _ to lista adresów, do których wcześniej uzyskano dostęp w ramach transakcji, a zatem dostęp do nich powinien być tańszy, zgodnie z definicją w sekcji 6.1 na s. 8. Więcej na ten temat można przeczytać w [EIP-2929](https://eips.ethereum.org/EIPS/eip-2929).
+
+| Wartość | Mnemonik | δ | α | Opis |
+| ------: | -------- | -- | -- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
+| 0x8F | DUP16 | 16 | 17 | Duplikuj 16. element stosu. |
+| | | | | _μ′s [0] ≡ μs [15]_ |
+
+Należy pamiętać, że aby użyć dowolnego elementu stosu, musimy go zdjąć, co oznacza, że musimy również zdjąć wszystkie elementy stosu znajdujące się nad nim. W przypadku [`DUP`](https://www.evm.codes/#8f) i [`SWAP`](https://www.evm.codes/#9f) oznacza to konieczność zdjęcia, a następnie odłożenia na stos do szesnastu wartości.
+
+## 9.5 Cykl wykonania {#95-exec-cycle}
+
+Teraz, gdy mamy już wszystkie części, możemy w końcu zrozumieć, jak udokumentowany jest cykl wykonania EVM.
+
+Równanie (155) mówi, że biorąc pod uwagę stan:
+
+- _σ_ (globalny stan blockchaina)
+- _μ_ (stan EVM)
+- _A_ (podstan, zmiany, które mają nastąpić po zakończeniu transakcji)
+- _I_ (środowisko wykonawcze)
+
+Nowy stan to _(σ', μ', A', I')_.
+
+Równania (156)-(158) definiują stos i zmianę w nim spowodowaną przez kod operacyjny (_μs _). Równanie (159) to zmiana w gazie (_μg _). Równanie (160) to zmiana w liczniku programu (_μpc _). Wreszcie równania (161)-(164) określają, że pozostałe parametry pozostają takie same, chyba że zostały wyraźnie zmienione przez kod operacyjny.
+
+W ten sposób EVM jest w pełni zdefiniowana.
+
+## Wnioski {#conclusion}
+
+Notacja matematyczna jest precyzyjna i pozwoliła Yellow Paper na określenie każdego szczegółu Ethereum. Ma to jednak pewne wady:
+
+- Może być zrozumiana tylko przez ludzi, co oznacza, że [testy zgodności](https://github.com/ethereum/tests) muszą być pisane ręcznie.
+- Programiści rozumieją kod komputerowy.
+ Mogą rozumieć notację matematyczną lub nie.
+
+Być może z tych powodów nowsze [specyfikacje warstwy konsensusu](https://github.com/ethereum/consensus-specs/blob/dev/tests/core/pyspec/README.md) są napisane w Pythonie. Istnieją [specyfikacje warstwy wykonawczej w Pythonie](https://ethereum.github.io/execution-specs), ale nie są one kompletne. Dopóki cały Yellow Paper nie zostanie również przetłumaczony na język Python lub podobny, Yellow Paper będzie nadal w użyciu i warto umieć go czytać.
diff --git a/public/content/translations/pl/eips/index.md b/public/content/translations/pl/eips/index.md
index 35e747589f1..46e8a4dca34 100644
--- a/public/content/translations/pl/eips/index.md
+++ b/public/content/translations/pl/eips/index.md
@@ -1,5 +1,5 @@
---
-title: Wniosek dotyczący ulepszenia Ethereum (EIP)
+title: "Wniosek dotyczący ulepszenia Ethereum (EIP)"
description: Podstawowe informacje potrzebne do zrozumienia propozycji EIP
lang: pl
---
@@ -8,21 +8,21 @@ lang: pl
## Czym są EIP? {#what-are-eips}
-[Ethereum Improvement Proposals (EIPs)](https://eips.ethereum.org/) to normy określające potencjalne nowe funkcje lub procesy Ethereum. EIP zawierają specyfikacje techniczne proponowanych zmian i działają jako „źródło prawdy” dla społeczności. Ulepszenia sieci i normy jej stosowania są omawiane i rozwijane w ramach procesu EIP.
+[Propozycje ulepszeń w Ethereum (EIP)](https://eips.ethereum.org/) to standardy określające potencjalne nowe funkcje lub procesy dla Ethereum. EIP zawierają specyfikacje techniczne proponowanych zmian i działają jako „źródło prawdy” dla społeczności. Ulepszenia sieci i normy jej stosowania są omawiane i rozwijane w ramach procesu EIP.
-Każdy w społeczności Ethereum ma możliwość stworzenia EIP. Wytyczne dotyczące pisania EIP są zawarte w [EIP-1](https://eips.ethereum.org/EIPS/eip-1). EIP powinna przede wszystkim zawierać zwięzłą specyfikację techniczną z niewielką ilością motywacji. Autor EIP jest odpowiedzialny za osiągnięcie konsensusu w społeczności i udokumentowanie odmiennych opinii. Ze względu na wysoką barierę techniczną związaną z wysłaniem dobrze sformatowanej propozycji EIP większość autorów EIP to zazwyczaj deweloperzy aplikacji lub protokołów.
+Każdy w społeczności Ethereum ma możliwość stworzenia EIP. Wytyczne dotyczące pisania EIP znajdują się w [EIP-1](https://eips.ethereum.org/EIPS/eip-1). EIP powinna przede wszystkim zawierać zwięzłą specyfikację techniczną z niewielką ilością motywacji. Autor EIP jest odpowiedzialny za osiągnięcie konsensusu w społeczności i udokumentowanie odmiennych opinii. Ze względu na wysoką barierę techniczną związaną z wysłaniem dobrze sformatowanej propozycji EIP większość autorów EIP to zazwyczaj deweloperzy aplikacji lub protokołów.
## Dlaczego EIP mają znaczenia? {#why-do-eips-matter}
-EIP odgrywają kluczową rolę w tym, jak zachodzą zmiany i są udokumentowane na Ethereum. Stanowią one dla ludzi drogę do zaproponowania, debaty i przyjęcia zmian. Istnieją [różne typy EIP](https://eips.ethereum.org/EIPS/eip-1#eip-types), w tym podstawowe EIP dotyczące zmian protokołu niskiego poziomu, które wpływają na konsensus i wymagają uaktualnienia sieci, takie jak [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), oraz prośby ERC dotyczące standardów aplikacji, takie jak [EIP-20](https://eips.ethereum.org/EIPS/eip-20) i [EIP-721](https://eips.ethereum.org/EIPS/eip-721).
+EIP odgrywają kluczową rolę w tym, jak zachodzą zmiany i są udokumentowane na Ethereum. Są one dla ludzi sposobem na proponowanie, debatowanie i przyjmowanie zmian. Istnieją [różne typy EIP](https://eips.ethereum.org/EIPS/eip-1#eip-types), w tym podstawowe EIP dotyczące zmian w protokole niskiego poziomu, które wpływają na konsensus i wymagają aktualizacji sieci, jak [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), oraz ERC dla standardów aplikacji, jak [EIP-20](https://eips.ethereum.org/EIPS/eip-20) i [EIP-721](https://eips.ethereum.org/EIPS/eip-721).
-Każde uaktualnienie sieci składa się z zestawu propozycji EIP, które muszą zostać zaimplementowane przez każdego [klienta Ethereum](/learn/#clients-and-nodes) w sieci. To znaczy, że aby utrzymać konsensus z innymi klientami w sieci głównej Ethereum, deweloperzy klientów muszą upewnić się, że wszyscy wdrożyli wymagane EIP.
+Każda aktualizacja sieci składa się z zestawu EIP, które muszą zostać wdrożone przez każdego [klienta Ethereum](/learn/#clients-and-nodes) w sieci. To znaczy, że aby utrzymać konsensus z innymi klientami w sieci głównej Ethereum, deweloperzy klientów muszą upewnić się, że wszyscy wdrożyli wymagane EIP.
Wraz z dostarczeniem specyfikacji technicznej zmian, EIP są jednostką, wokół której odbywa się zarządzanie w Ethereum: każdy może zaproponować jeden, a następnie różni interesariusze w społeczności będą debatować, aby ustalić, czy powinien zostać przyjęty jako standard, czy włączony do aktualizacja sieci. Jako że EIP inne niż podstawowe nie muszą być przyjęte przez wszystkie aplikacje (na przykład można utworzyć zamienny token, który nie implementuje propozycji EIP-20), ale podstawowe EIP muszą być powszechnie przyjęte (ponieważ wszystkie węzły muszą się uaktualnić, aby pozostać częścią tej samej sieci), podstawowe EIP wymagają szerszego konsensusu w społeczności niż EIP inne niż podstawowe.
## Historia EIP {#history-of-eips}
-[Repozytorium Github Ethereum Improvement Proposals (EIPs)](https://github.com/ethereum/EIPs) zostało stworzone w październiku 2015 r. Proces EIP opiera się na procesie [Bitcoin Improvement Proposals (BIP)](https://github.com/bitcoin/bips), który sam w sobie opiera się na [Python Enhancement Proposals (PEP)](https: //www.python.org/dev/peps/).
+[Repozytorium GitHub propozycji ulepszeń Ethereum (EIP)](https://github.com/ethereum/EIPs) zostało utworzone w październiku 2015 roku. Proces EIP jest oparty na procesie [Bitcoin Improvement Proposals (BIP)](https://github.com/bitcoin/bips), który z kolei jest oparty na procesie [Python Enhancement Proposals (PEP)](https://www.python.org/dev/peps/).
Edytorzy EIP są zobowiązani do sprawdzania EIP pod względem poprawności technicznej, formatowania, pisowni, gramatyki oraz stylu kodu. Martin Becze, Vitalik Buterin, Gavin Wood i kilka innych osób było pierwszymi edytorami EIP od 2015 r. do końca 2016 r.
@@ -44,33 +44,32 @@ Emerytowani edytorzy EIP to
- Nick Savers (@nicksavers)
- Vitalik Buterin (@vbuterin)
-Jeśli chcesz zostać edytorem EPI, sprawdź [EIP-5069](https://eips.ethereum.org/EIPS/eip-5069).
+Jeśli chcesz zostać redaktorem EIP, sprawdź [EIP-5069](https://eips.ethereum.org/EIPS/eip-5069).
-Edytorzy EPI decydują, kiedy propozycja jest gotowa, aby stać się EIP, i pomagają autorom EPI w realizacji ich propozycji. [Ethereum Cat Herders](https://www.ethereumcatherders.com/) pomagają w organizowaniu spotkań edytorów EIP ze społecznością (patrz [EIPIP](https://github.com/ethereum-cat-herders/EIPIP)).
+Edytorzy EPI decydują, kiedy propozycja jest gotowa, aby stać się EIP, i pomagają autorom EPI w realizacji ich propozycji. [Ethereum Cat Herders](https://www.ethereumcatherders.com/) pomagają w organizacji spotkań redaktorów EIP i społeczności (zobacz [EIPIP](https://github.com/ethereum-cat-herders/EIPIP)).
-Pełny proces normalizacji wraz ze schematem jest opisany w [EIP-1](https://eips.ethereum.org/EIPS/eip-1)
+Pełny proces standaryzacji wraz z wykresem jest opisany w [EIP-1](https://eips.ethereum.org/EIPS/eip-1)
## Dowiedz się więcej {#learn-more}
-Jeśli chcesz dowiedzieć się więcej na temat EPI, sprawdź [witrynę internetową propozycji EPI](https://eips.ethereum.org/) i propozycję [EPI-1](https://eips.ethereum.org/EIPS/eip-1). Oto kilka przydatnych linków:
+Jeśli chcesz dowiedzieć się więcej o EIP, odwiedź [stronę EIP](https://eips.ethereum.org/) i zapoznaj się z [EIP-1](https://eips.ethereum.org/EIPS/eip-1). Oto kilka przydatnych linków:
- [Lista wszystkich propozycji ulepszeń Ethereum](https://eips.ethereum.org/all)
- [Opis wszystkich typów EIP](https://eips.ethereum.org/EIPS/eip-1#eip-types)
- [Opis wszystkich statusów EIP](https://eips.ethereum.org/EIPS/eip-1#eip-process)
-### Projekty edukacyjne dla społeczności {#community-projects}
+### Projekty edukacyjne społeczności {#community-projects}
-- [PEEPanEIP](https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F) — *PEEPanEIP to seria filmów edukacyjnych, która przedstawia propozycje ulepszeń Ethereum (EIP) oraz kluczowe cechy przyszłych uaktualnień.*
-- [EIPs For Nerds](https://ethereum2077.substack.com/t/eip-research) — *EIPs For Nerds zapewnia obszerne przeglądy różnych propozycji ulepszeń Ethereum (EIP) w stylu ELI5, w tym podstawowych EIP oraz EIP warstwy aplikacji/infrastruktury (ERC), mające edukować czytelników i kształtować konsensus wokół proponowanych zmian w protokole Ethereum.*
-- [EIPs.wtf](https://www.eips.wtf/) — *EIPs.wtf zapewnia dodatkowe informacje o propozycjach ulepszeń Ethereum (EIP), włącznie z ich statusem, szczegółami implementacji, powiązanymi żądaniami pull request oraz opiniami społeczności.*
-- [EIP.Fun](https://eipfun.substack.com/) — *EIP.Fun dostarcza najnowsze wiadomości o propozycjach ulepszeń Ethereum (EIP), aktualizacjach na temat spotkań EIP i nie tylko.*
-- [EIPs Insight](https://eipsinsight.com/) — *EIPs Insight to przedstawienie stanu procesu i statystyk propozycji ulepszeń Ethereum (EIP) zgodnie z informacjami zebranymi z różnych źródeł.*
+- [PEEPanEIP](https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F) — _PEEPanEIP to seria filmów edukacyjnych, która omawia propozycje ulepszeń Ethereum (EIP) oraz kluczowe cechy nadchodzących aktualizacji._
+- [EIPs.wtf](https://www.eips.wtf/) — _EIPs.wtf dostarcza dodatkowych informacji na temat propozycji ulepszeń Ethereum (EIP), w tym ich status, szczegóły implementacji, powiązane pull requesty i opinie społeczności._
+- [EIP.Fun](https://eipfun.substack.com/) — _EIP.Fun dostarcza najnowsze wiadomości na temat propozycji ulepszeń Ethereum (EIP), aktualizacje ze spotkań EIP i nie tylko._
+- [EIPs Insight](https://eipsinsight.com/) — _EIPs Insight to przedstawienie stanu procesu propozycji ulepszeń Ethereum (EIP) i statystyk na podstawie informacji zebranych z różnych źródeł._
-## Uczestnictwo {#participate}
+## Weź udział {#participate}
-Każdy może utworzyć EIP. Przed przesłaniem propozycji należy przeczytać [EIP-1](https://eips.ethereum.org/EIPS/eip-1), w której opisano proces EIP i sposób pisania EIP, a także zasięgnąć opinii na stronie [Ethereum Magicians](https://ethereum-magicians.org/), na której propozycje są najpierw omawiane ze społecznością przed złożeniem projektu.
+Każdy może utworzyć EIP. Przed złożeniem propozycji należy przeczytać [EIP-1](https://eips.ethereum.org/EIPS/eip-1), który opisuje proces EIP i sposób pisania EIP, a także poprosić o opinie na forum [Ethereum Magicians](https://ethereum-magicians.org/), gdzie propozycje są najpierw omawiane ze społecznością przed złożeniem wersji roboczej.
-## Źródła {#references}
+## Materiały źródłowe {#references}
diff --git a/public/content/translations/pl/energy-consumption/index.md b/public/content/translations/pl/energy-consumption/index.md
index 9886b1e809c..378b1ae008e 100644
--- a/public/content/translations/pl/energy-consumption/index.md
+++ b/public/content/translations/pl/energy-consumption/index.md
@@ -1,14 +1,14 @@
---
-title: Zużycie energii przez Ethereum
-description: Podstawowe informacje, których potrzebujesz, aby zrozumieć zużycie energii Ethereum.
+title: "Zużycie energii przez Ethereum"
+description: "Podstawowe informacje, których potrzebujesz, aby zrozumieć zużycie energii Ethereum."
lang: pl
---
# Wydatki energetyczne Ethereum {#proof-of-stake-energy}
-Ethereum jest zielonym blockchainem. Mechanizm konsensusu Ethereum ([proof-of-stake](/developers/docs/consensus-mechanisms/pos)) wykorzystuje ETH zamiast [energii do zabezpieczenia sieci](/developers/docs/consensus-mechanisms/pow). Zużycie energii przez Ethereum wynosi około [0,0026 TWh/rok](https://carbon-ratings.com/eth-report-2022) w całej globalnej sieci.
+Ethereum jest zielonym blockchainem. Mechanizm konsensusu [proof-of-stake](/developers/docs/consensus-mechanisms/pos) Ethereum wykorzystuje ETH zamiast [energii do zabezpieczenia sieci](/developers/docs/consensus-mechanisms/pow). Zużycie energii przez Ethereum wynosi około [~0,0026 TWh/rok](https://carbon-ratings.com/eth-report-2022) w całej globalnej sieci.
-Szacunkowe zużycie energii dla Ethereum pochodzi z badania [CCRI (Instytut Oceny Emisji Kryptowalut)](https://carbon-ratings.com). W ramach tego badania wygenerowano szacunkowe dane dotyczące zużycia energii i śladu węglowego sieci Ethereum ([zobacz raport](https://carbon-ratings.com/eth-report-2022)). Zmierzyli oni zużycie energii elektrycznej przez różne węzły z różnymi konfiguracjami sprzętu i oprogramowania klienckiego. Szacowane **2601 MWh** (0,0026 TWh) rocznego zużycia energii elektrycznej przez sieć odpowiada rocznej emisji dwutlenku węgla na poziomie **870 ton CO2e** przy uwzględnieniu regionalnych współczynników intensywności emisji dwutlenku węgla. Wartość ta zmienia się wraz z wchodzeniem i wychodzeniem węzłów z sieci — można ją śledzić, korzystając z 7-dniowego średniego oszacowania obliczanego przez [Cambridge Blockchain Network Sustainability Index](https://ccaf.io/cbnsi/ethereum) (należy pamiętać, że używają oni nieco innej metody do swoich szacunków — szczegóły dostępne na ich stronie).
+Szacunkowe zużycie energii dla Ethereum pochodzi z badania [CCRI (Crypto Carbon Ratings Institute)](https://carbon-ratings.com). Wygenerowali oni oddolne szacunki zużycia energii elektrycznej i śladu węglowego sieci Ethereum ([zobacz raport](https://carbon-ratings.com/eth-report-2022)). Zmierzyli oni zużycie energii elektrycznej przez różne węzły z różnymi konfiguracjami sprzętu i oprogramowania klienckiego. Szacowane **2601 MWh** (0,0026 TWh) rocznego zużycia energii elektrycznej przez sieć odpowiada rocznej emisji dwutlenku węgla na poziomie **870 ton CO2e** przy uwzględnieniu regionalnych współczynników intensywności emisji dwutlenku węgla. Wartość ta zmienia się, gdy węzły dołączają do sieci i ją opuszczają – można ją śledzić za pomocą 7-dniowej średniej kroczącej szacowanej przez [Cambridge Blockchain network Sustainability Index](https://ccaf.io/cbnsi/ethereum) (należy pamiętać, że do swoich szacunków stosują oni nieco inną metodę – szczegóły są dostępne na ich stronie).
Aby zwizualizować zużycie energii przez Ethereum, możemy porównać roczne szacunki dla niektórych innych produktów i przemysłów. Pomoże nam to lepiej zrozumieć, czy oszacowania dla Ethereum są wysokie czy niskie.
@@ -16,50 +16,50 @@ Aby zwizualizować zużycie energii przez Ethereum, możemy porównać roczne sz
Powyższy wykres przedstawia szacowane zużycie energii w TWh/rok dla Ethereum w porównaniu z kilkoma innymi produktami i przemysłami. Przedstawione szacunki pochodzą z publicznie dostępnych danych, które zebrano w lipcu 2023 r. Linki do źródeł są dostępne w poniższej tabeli.
-| | Roczne zużycie energii (TWh) | Porównanie do PoS Ethereum | Źródło |
-|:---------------------- |:----------------------------:|:--------------------------:|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
-| Światowe centra danych | 190 | x 73 000 | [źródło](https://www.iea.org/commentaries/data-centres-and-energy-from-global-headlines-to-local-headaches) |
-| Bitcoin | 149 | x 53 000 | [źródło](https://ccaf.io/cbnsi/cbeci/comparisons) |
-| Wydobycie złota | 131 | x 50 000 | [źródło](https://ccaf.io/cbnsi/cbeci/comparisons) |
-| Gaming w USA\* | 34 | x 13 000 | [źródło](https://www.researchgate.net/publication/336909520_Toward_Greener_Gaming_Estimating_National_Energy_Use_and_Energy_Efficiency_Potential) |
-| PoW Ethereum | 21 | x 8100 | [źródło](https://ccaf.io/cbnsi/ethereum/1) |
-| Google | 19 | x 7300 | [źródło](https://www.gstatic.com/gumdrop/sustainability/google-2022-environmental-report.pdf) |
-| Netflix | 0,457 | x 176 | [źródło](https://assets.ctfassets.net/4cd45et68cgf/7B2bKCqkXDfHLadrjrNWD8/e44583e5b288bdf61e8bf3d7f8562884/2021_US_EN_Netflix_EnvironmentalSocialGovernanceReport-2021_Final.pdf) |
-| PayPal | 0,26 | x 100 | [źródło](https://s202.q4cdn.com/805890769/files/doc_downloads/global-impact/CDP_Climate_Change_PayPal-(1).pdf) |
-| AirBnB | 0,02 | x 8 | [źródło](https://s26.q4cdn.com/656283129/files/doc_downloads/governance_doc_updated/Airbnb-ESG-Factsheet-(Final).pdf) |
-| **PoS Ethereum** | **0,0026** | **x 1** | [źródło](https://carbon-ratings.com/eth-report-2022) |
+| | Roczne zużycie energii (TWh) | Porównanie do PoS Ethereum | Źródło |
+| :--------------------- | :---------------------------------------------: | :------------------------: | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
+| Światowe centra danych | 190 | x 73 000 | [źródło](https://www.iea.org/commentaries/data-centres-and-energy-from-global-headlines-to-local-headaches) |
+| Bitcoin | 149 | x 53 000 | [źródło](https://ccaf.io/cbnsi/cbeci/comparisons) |
+| Wydobycie złota | 131 | x 50 000 | [źródło](https://ccaf.io/cbnsi/cbeci/comparisons) |
+| Gaming w USA\* | 34 | x 13 000 | [źródło](https://www.researchgate.net/publication/336909520_Toward_Greener_Gaming_Estimating_National_Energy_Use_and_Energy_Efficiency_Potential) |
+| PoW Ethereum | 21 | x 8100 | [źródło](https://ccaf.io/cbnsi/ethereum/1) |
+| Google | 19 | x 7300 | [źródło](https://www.gstatic.com/gumdrop/sustainability/google-2022-environmental-report.pdf) |
+| Netflix | 0,457 | x 176 | [źródło](https://assets.ctfassets.net/4cd45et68cgf/7B2bKCqkXDfHLadrjrNWD8/e44583e5b288bdf61e8bf3d7f8562884/2021_US_EN_Netflix_EnvironmentalSocialGovernanceReport-2021_Final.pdf) |
+| PayPal | 0,26 | x 100 | [źródło](https://s202.q4cdn.com/805890769/files/doc_downloads/global-impact/CDP_Climate_Change_PayPal-\(1\).pdf) |
+| AirBnB | 0,02 | x 8 | [źródło](https://s26.q4cdn.com/656283129/files/doc_downloads/governance_doc_updated/Airbnb-ESG-Factsheet-\(Final\).pdf) |
+| **PoS Ethereum** | **0,0026** | **1x** | [źródło](https://carbon-ratings.com/eth-report-2022) |
\*Obejmuje urządzenia użytkowników końcowych, takie jak komputery, laptopy i konsole do gier.
-Uzyskanie dokładnych szacunków dotyczących zużycia energii jest skomplikowane, zwłaszcza gdy mierzony produkt ma złożony łańcuch dostaw lub szczegóły wdrożenia, które wpływają na jego wydajność. Przykładowo, szacunki dotyczące zużycia energii przez Netflix i Google różnią się w zależności od tego, czy uwzględniają jedynie energię wykorzystywaną do utrzymania ich systemów i dostarczania treści użytkownikom (_wydatki bezpośrednie_), czy też obejmują wydatki wymagane do produkcji treści, prowadzenia biur korporacyjnych, promocji itp. (_wydatki pośrednie_). Wydatki pośrednie mogą również obejmować energię wymaganą do odbioru treści na urządzeniach użytkowników końcowych, takich jak telewizory, komputery i telefony komórkowe.
+Uzyskanie dokładnych szacunków dotyczących zużycia energii jest skomplikowane, zwłaszcza gdy mierzony produkt ma złożony łańcuch dostaw lub szczegóły wdrożenia, które wpływają na jego wydajność. Na przykład szacunki zużycia energii dla Netflix i Google różnią się w zależności od tego, czy obejmują one tylko energię zużywaną do utrzymania systemów i dostarczania treści użytkownikom (_wydatki bezpośrednie_), czy też obejmują wydatki wymagane do produkcji treści, prowadzenia biur korporacyjnych, reklamy itp. (_wydatki pośrednie_). Wydatki pośrednie mogą również obejmować energię wymaganą do odbioru treści na urządzeniach użytkowników końcowych, takich jak telewizory, komputery i telefony komórkowe.
Powyższe szacunki nie są idealnymi porównaniami. Kwota uwzględnionych wydatków pośrednich różni się w zależności od źródła i rzadko obejmuje energię z urządzeń użytkowników końcowych. W każdym z przytoczonych źródeł można znaleźć więcej informacji na temat tego, co jest mierzone.
-Powyższa tabela i wykres zawierają również porównania do Bitcoina i proof-of-work Ethereum. Należy zauważyć, że zużycie energii w sieciach proof-of-work nie jest stałe i zmienia się z dnia na dzień. Szacunki mogą również znacznie się różnić w zależności od źródła. Wokół tego tematu toczy się szczegółowa [debata](https://www.coindesk.com/business/2020/05/19/the-last-word-on-bitcoins-energy-consumption/). Polemika dotyczy nie tylko ilości zużywanej energii, ale także źródeł tej energii i etyki jej pozyskiwania. Zużycie energii niekoniecznie dokładnie odzwierciedla ślad środowiskowy, ponieważ różne projekty mogą wykorzystywać różne źródła energii, w których mogą mieć mniejszy lub większy udział odnawialne źródła energii. Na przykład [Cambridge Bitcoin Electricity Consumption Index](https://ccaf.io/cbnsi/cbeci/comparisons) wskazuje, że zapotrzebowanie sieci Bitcoin może być teoretycznie zasilane przez spalanie gazu lub energię elektryczną, która w przeciwnym razie zostałaby utracona podczas przesyłu i dystrybucji. Droga Ethereum do zrównoważonego rozwoju polegała na zastąpieniu energochłonnej części sieci zieloną alternatywą.
+Powyższa tabela i wykres zawierają również porównania do Bitcoina i proof-of-work Ethereum. Należy zauważyć, że zużycie energii w sieciach proof-of-work nie jest stałe i zmienia się z dnia na dzień. Szacunki mogą również znacznie się różnić w zależności od źródła. Temat ten wywołuje szczegółową [debatę](https://www.coindesk.com/business/2020/05/19/the-last-word-on-bitcoins-energy-consumption/), nie tylko na temat ilości zużywanej energii, ale także źródeł tej energii i związanej z nią etyki. Zużycie energii niekoniecznie dokładnie odzwierciedla ślad środowiskowy, ponieważ różne projekty mogą wykorzystywać różne źródła energii, w których mogą mieć mniejszy lub większy udział odnawialne źródła energii. Na przykład [Cambridge Bitcoin Electricity Consumption Index](https://ccaf.io/cbnsi/cbeci/comparisons) wskazuje, że zapotrzebowanie sieci Bitcoin może być teoretycznie zasilane przez spalanie gazu w pochodniach lub energię elektryczną, która w przeciwnym razie zostałaby utracona podczas przesyłu i dystrybucji. Droga Ethereum do zrównoważonego rozwoju polegała na zastąpieniu energochłonnej części sieci zieloną alternatywą.
-Na stronie [Cambridge Blockchain Network Sustainability Index](https://ccaf.io/cbnsi/ethereum) można przeglądać szacunki zużycia energii i emisji dwutlenku węgla dla wielu przemysłów.
+Szacunki zużycia energii i emisji dwutlenku węgla dla wielu branż można przeglądać na [stronie Cambridge Blockchain Network Sustainability Index](https://ccaf.io/cbnsi/ethereum).
## Szacunki na transakcję {#per-transaction-estimates}
Wiele artykułów szacuje wydatek energetyczny blockchainów „na transakcję”. Może to być mylące, ponieważ energia wymagana do zaproponowania i walidacji bloku jest niezależna od liczby transakcji w nim zawartych. Jednostka wydatku energetycznego na transakcję sugeruje, że mniejsza liczba transakcji prowadziłaby do mniejszych wydatków energetycznych i odwrotnie, co nie jest prawdą. Ponadto szacunki na transakcję są bardzo wrażliwe na sposób definiowania przepustowości transakcji blockchainu, a modyfikowanie tej definicji może być wykorzystywane do zwiększania lub zmniejszania wartości.
-Na przykład w Ethereum przepustowość transakcji to nie tylko przepustowość warstwy podstawowej — to także suma przepustowości transakcji wszystkich jej pakietów zbiorczych „[warstwy 2](/layer-2/)”. Warstwy 2 nie są zwykle uwzględniane w obliczeniach, ale wzięcie pod uwagę dodatkowej energii zużywanej przez sekwencery (mało) i liczby przetwarzanych przez nie transakcji (dużo) prawdopodobnie drastycznie zmniejszyłoby szacunki na transakcję. Jest to jeden z powodów, dla których porównania zużycia energii na transakcję na różnych platformach mogą być mylące.
+Na przykład w Ethereum przepustowość transakcji to nie tylko przepustowość warstwy podstawowej – jest to również suma przepustowości transakcji wszystkich jego „[warstw 2](/layer-2/)” rollupów. Warstwy 2 nie są zwykle uwzględniane w obliczeniach, ale wzięcie pod uwagę dodatkowej energii zużywanej przez sekwencery (mało) i liczby przetwarzanych przez nie transakcji (dużo) prawdopodobnie drastycznie zmniejszyłoby szacunki na transakcję. Jest to jeden z powodów, dla których porównania zużycia energii na transakcję na różnych platformach mogą być mylące.
-## Dług emisyjny Ethereum {#carbon-debt}
+## Dług węglowy Ethereum {#carbon-debt}
Wydatek energetyczny Ethereum jest bardzo niski, ale nie zawsze tak było. Ethereum pierwotnie wykorzystywało mechanizm proof-of-work, który wiązał się ze znacznie większymi obciążeniami środowiskowymi niż obecny mechanizm proof-of-stake.
Od samego początku Ethereum planowało wdrożyć mechanizm konsensusu proof-of-stake, ale zrobienie tego bez szkody dla bezpieczeństwa i decentralizacji wymagało lat ukierunkowanych badań i rozwoju. W związku z tym do uruchomienia sieci wykorzystano mechanizm proof-of-work. Proof-of-work wymaga od górników użycia ich sprzętu komputerowego do obliczania wartości, co zużywa energię.
-
+
-CCRI szacuje, że Połączenie zmniejszyło roczne zużycie energii elektrycznej przez Ethereum o ponad **99,988%**. Podobnie, ślad węglowy Ethereum został zmniejszony o około **99,992%** (z 11 016 000 do 870 ton CO2e). Aby lepiej to unaocznić, można porównać redukcję emisji do różnicy wysokości między wieżą Eiffla a małą plastikową figurką, jak pokazano na powyższej ilustracji. W wyniku tego obciążenia środowiskowe związane z zabezpieczaniem sieci zostały drastycznie zmniejszone. Jednocześnie uważa się, że poprawiło się bezpieczeństwo sieci.
+CCRI szacuje, że Połączenie zmniejszyło roczne zużycie energii elektrycznej przez Ethereum o ponad **99,988%**. Podobnie ślad węglowy Ethereum zmniejszył się o około **99,992%** (z 11 016 000 do 870 ton CO2e). Aby lepiej to unaocznić, można porównać redukcję emisji do różnicy wysokości między wieżą Eiffla a małą plastikową figurką, jak pokazano na powyższej ilustracji. W wyniku tego obciążenia środowiskowe związane z zabezpieczaniem sieci zostały drastycznie zmniejszone. Jednocześnie uważa się, że poprawiło się bezpieczeństwo sieci.
## Ekologiczna warstwa aplikacji {#green-applications}
-Obecnie zużycie energii przez Ethereum jest bardzo niskie, a ponadto istnieje również pokaźna, rosnąca i bardzo aktywna społeczność zajmująca się [**finansami regeneracyjnymi (ReFi)**](/refi/). Aplikacje ReFi wykorzystują komponenty DeFi do tworzenia aplikacji finansowych, które mają pozytywny wpływ na środowisko. ReFi jest częścią szerszego ruchu [„solarpunk”](https://en.wikipedia.org/wiki/Solarpunk), który jest ściśle powiązany z Ethereum i ma na celu połączenie postępu technologicznego z ochroną środowiska. Zdecentralizowana, niewymagająca uprawnień i złożona natura Ethereum sprawia, że jest to idealna warstwa bazowa dla społeczności ReFi i solarpunk.
+Chociaż zużycie energii przez Ethereum jest bardzo niskie, na Ethereum rozwija się także znacząca, rosnąca i bardzo aktywna społeczność [**finansów regeneracyjnych (ReFi)**](/refi/). Aplikacje ReFi wykorzystują komponenty DeFi do tworzenia aplikacji finansowych, które mają pozytywny wpływ na środowisko. ReFi jest częścią szerszego ruchu [„solarpunk”](https://en.wikipedia.org/wiki/Solarpunk), który jest ściśle powiązany z Ethereum i ma na celu połączenie postępu technologicznego z dbałością o środowisko. Zdecentralizowana, niewymagająca uprawnień i złożona natura Ethereum sprawia, że jest to idealna warstwa bazowa dla społeczności ReFi i solarpunk.
-Natywne platformy Web3 do finansowania dóbr publicznych, takie jak [Gitcoin](https://gitcoin.co), przeprowadzają rundy klimatyczne w celu stymulowania świadomego i ekologicznego budowania w warstwie aplikacji Ethereum. Dzięki rozwojowi tych inicjatyw (i innych, takich jak [DeSci](/desci/)) Ethereum staje się technologią o pozytywnym wpływie środowiskowym i społecznym.
+Natywne platformy Web3 do finansowania dóbr publicznych, takie jak [Gitcoin](https://gitcoin.co), organizują rundy klimatyczne, aby stymulować świadome ekologicznie budowanie na warstwie aplikacji Ethereum. Dzięki rozwojowi tych (i innych, np. [DeSci](/desci/)) inicjatyw Ethereum staje się technologią o pozytywnym netto wpływie na środowisko i społeczeństwo.
+
Forki powstają, gdy w sieci trzeba wprowadzić istotne aktualizacje techniczne lub zmiany – zazwyczaj wynikają one z p ropozycji ulepszeń Ethereum [Ethereum Improvement Proposals (EIP)](/eips/) i zmieniają „zasady” protokołu.
Gdy potrzebne są aktualizacje w tradycyjnym, centralnie sterowanym oprogramowaniu, firma po prostu opublikuje nową wersję dla użytkownika końcowego. Blockchainy działają inaczej, ponieważ nie ma centralnego właściciela. [Klienci Ethereum](/developers/docs/nodes-and-clients/) muszą zaktualizować swoje oprogramowanie, aby wdrożyć reguły nowego forka. Dodatkowo twórcy bloków (górnicy w świecie proof-of-work, walidatorzy w świecie proof-of-stake) i węzły muszą tworzyć bloki i przeprowadzać walidację zgodnie z nowymi zasadami. [Więcej o mechanizmach konsensusu](/developers/docs/consensus-mechanisms/)
-Te zmiany reguł mogą spowodować tymczasowy podział w sieci. Nowe bloki można wytwarzać według nowych lub starych zasad. Forki są zwykle uzgadniane z wyprzedzeniem, tak aby klienci przyjęli zmiany jednomyślnie, a fork z aktualizacjami stał się głównym łańcuchem. Jednak w rzadkich przypadkach nieporozumienia dotyczące forków mogą spowodować trwały rozłam w sieci — przykładem jest powstanie Ethereum Classic z [DAO fork](#dao-fork).
+Te zmiany zasad mogą spowodować tymczasowy podział sieci. Nowe bloki można wytwarzać według nowych lub starych zasad. Forki są zwykle uzgadniane z wyprzedzeniem, tak aby klienci przyjęli zmiany jednomyślnie, a fork z aktualizacjami stał się głównym łańcuchem. Jednak w rzadkich przypadkach nieporozumienia dotyczące forków mogą spowodować trwały podział sieci — przykładem jest powstanie Ethereum Classic z forka DAO .
+
+
+
+
+Oprogramowanie stanowiące podstawę Ethereum składa się z dwóch części, znanych jako [warstwa wykonawcza](/glossary/#execution-layer) i [warstwa konsensusu](/glossary/#consensus-layer).
+
+**Nazewnictwo uaktualnień warstwy wykonawczej**
+
+Od 2021 roku uaktualnienia **warstwy wykonawczej** są nazywane zgodnie z nazwami miast [poprzednich lokalizacji Devcon](https://devcon.org/en/past-events/) w porządku chronologicznym:
+
+| Nazwa uaktualnienia | Rok Devcon | Numer Devcon | Data uaktualnienia |
+| ------------------- | ---------- | ------------ | ----------------------------------- |
+| Berlin | 2014 | 0 | 15 kwietnia 2021 r. |
+| London | 2015 | I | 5 sierpnia 2021 r. |
+| Shanghai | 2016 | II | 12 kwietnia 2023 r. |
+| Cancun | 2017 | III | 13 marca 2024 r. |
+| **Praga** | 2018 | IV | Do ustalenia - Następna |
+| _Osaka_ | 2019 | V | Do ustalenia |
+| _Bogota_ | 2022 | VI | Do ustalenia |
+| _Bangkok_ | 2024 | VII | Do ustalenia |
+
+**Nazewnictwo uaktualnień warstwy konsensusu**
+
+Od czasu uruchomienia [Łańcucha śledzącego](/glossary/#beacon-chain) uaktualnienia **warstwy konsensusu** noszą nazwy gwiazd, których pierwsze litery następują po sobie w porządku alfabetycznym:
+
+| Nazwa uaktualnienia | Data uaktualnienia |
+| ------------------------------------------------------------- | --------------------------------------- |
+| Geneza łańcucha śledzącego | 1 grudnia 2020 r. |
+| [Altair](https://en.wikipedia.org/wiki/Altair) | 27 października 2021 r. |
+| [Bellatrix](https://en.wikipedia.org/wiki/Bellatrix) | 6 września 2022 r. |
+| [Capella](https://en.wikipedia.org/wiki/Capella) | 12 kwietnia 2023 r. |
+| [Deneb](https://en.wikipedia.org/wiki/Deneb) | 13 marca 2024 r. |
+| [**Electra**](https://en.wikipedia.org/wiki/Electra_\(star\)) | Do ustalenia - Następna |
+| [_Fulu_](https://en.wikipedia.org/wiki/Fulu_\(star\)) | Do ustalenia |
+**Połączone nazewnictwo**
+
+Uaktualnienia warstwy wykonawczej i konsensusu były początkowo wdrażane w różnych terminach, ale po [Połączeniu](/roadmap/merge/) w 2022 roku są wdrażane jednocześnie. W związku z tym pojawiły się potoczne terminy upraszczające odniesienia do tych aktualizacji poprzez użycie jednej, połączonej nazwy. Zaczęło się to od aktualizacji _Shanghai-Capella_, powszechnie nazywanej „**Shapella**”, a następnie kontynuowano przy aktualizacjach _Cancun-Deneb_ (**Dencun**) i _Prague-Electra_ (**Pectra**).
+
+| Uaktualnienie warstwy wykonawczej | Uaktualnienie warstwy konsensusu | Krótka nazwa |
+| --------------------------------- | -------------------------------- | ------------ |
+| Shanghai | Capella | „Shapella” |
+| Cancun | Deneb | „Dencun” |
+| Praga | Electra | „Pectra” |
+| Osaka | Fulu | „Fusaka” |
+
+
+Przejdź od razu do informacji o niektórych szczególnie ważnych uaktualnieniach z przeszłości: [Łańcuch śledzący](/roadmap/beacon-chain/); [Połączenie](/roadmap/merge/); i [EIP-1559](#london)
+
+Szukasz przyszłych uaktualnień protokołu? [Dowiedz się o nadchodzących uaktualnieniach w planie działania Ethereum](/roadmap/).
+
+
+
+Lepsze doświadczenie użytkownika:
+
+
+ EIP-7702 — ustawienie kodu dla kont EOA EIP-7691 — zwiększenie przepustowości blobów EIP-7623 — zwiększenie kosztu calldata EIP-7840 — dodanie harmonogramu blobów do plików konfiguracyjnych warstwy wykonawczej
+
+Lepsze doświadczenia stakingowe:
+
+
+ EIP-7251 — zwiększenie MAX_EFFECTIVE_BALANCE EIP-7002 — wyjścia wyzwalane z warstwy wykonawczej EIP-7685 — ogólne żądania warstwy wykonawczej EIP-6110 — zapewnienie depozytów walidatorów w łańcuchu
+
+Poprawy efektywności i bezpieczeństwa protokołu:
+
+
+ EIP-2537 — prekompilacja dla operacji krzywych BLS12-381 EIP-2935 — zapisywanie historycznych hashy bloków w stanie EIP-7549 — przeniesienie indeksu komitetu poza poświadczenie
+
+
+- [Pectra.wtf](https://pectra.wtf)
+- [Jak Pectra poprawi doświadczenie związane ze stakowaniem](https://www.kiln.fi/post/next-ethereum-upgrade-how-pectra-will-enhance-the-staking-experience)
+- [Przeczytaj specyfikacje uaktualnienia Electra](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/)
+- [Prague-Electra („Pectra”) – często zadawane pytania](/roadmap/pectra/)
+
+
+
+
+ EIP-1153 — kody operacyjne pamięci przejściowej EIP-4788 — korzeń bloku śledzącego w EVM EIP-4844 — transakcje shardów blobów(Proto-Danksharding) EIP-5656 — MCOPY — instrukcja kopiowania pamięciEIP-6780 — SELFDESTRUCT tylko w tej samej transakcjiEIP-7516 — kod operacyjny BLOBBASEFEE
+
+
+- [Rollupy warstwy 2](/layer-2/)
+- [Proto-Danksharding](/roadmap/scaling/#proto-danksharding)
+- [Danksharding](/roadmap/danksharding/)
+- [Przeczytaj specyfikację uaktualnienia Cancun](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md)
+
+#### Podsumowanie Deneb {#deneb-summary}
+
+Uaktualnienie Deneb zawiera zestaw ulepszeń dla _warstwy konsensusu_ Ethereum mających na celu poprawę skalowalności. Aktualizacja ta jest połączona z aktualizacjami warstwy wykonawczej Cancun, aby umożliwić Proto-Danksharding (EIP-4844) wraz z innymi usprawnieniami łańcucha śledzącego.
+
+Wstępnie wygenerowane podpisane „dobrowolne komunikaty wyjścia” nie tracą już ważności, dając tym samym większą kontrolę użytkownikom inwestującym swoje środki u zewnętrznego operatora węzła. Dzięki tej podpisanej wiadomości wyjściowej stakerzy mogą delegować obsługę węzła, zachowując jednocześnie możliwość bezpiecznego wyjścia i wypłaty swoich środków w dowolnym momencie, bez konieczności proszenia kogokolwiek o pozwolenie.
+
+Rozporządzenie EIP-7514 wprowadza zaostrzenie zasad wydawania ETH, ograniczając liczbę „rotacji” walidatorów, z jaką mogą dołączyć do sieci, do ośmiu (8) na epokę. Ponieważ emisja ETH jest proporcjonalna do całkowitej liczby stakowanych ETH, ograniczenie liczby dołączających walidatorów ogranicza _tempo wzrostu_ nowo wyemitowanych ETH, jednocześnie zmniejszając wymagania sprzętowe dla operatorów węzłów, co sprzyja decentralizacji.
+
+
+
+
+ EIP-4788 — korzeń bloku śledzącego w EVM EIP-4844 – transakcje blobów shardów EIP-7044 - Perpetually valid signed voluntary exits EIP-7045 – zwiększenie maksymalnego slotu na włączenie atestacji EIP-7514 – dodanie maksymalnego limitu rotacji epok
+
+
+- [Przeczytaj specyfikacje uaktualnienia Deneb](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/)
+- [Cancun-Deneb („Dencun”) – często zadawane pytania](/roadmap/dencun/)
+
+
+
+
+ EIP-3651 — uruchomienie ciepłego adresu COINBASE EIP-3855 — nowa instrukcja PUSH0 EIP-3860 — kod inicjujący limitu i licznika EIP-4895 — łańcuch śledzący przesyła wypłaty jako operacje EIP-6049 — usunięcie SELFDESTRUCT
+
+
+- [Przeczytaj specyfikację uaktualnienia Shanghai](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md)
+
+#### Podsumowanie Capella {#capella-summary}
+
+Uaktualnienie Capella była trzecim dużym uaktualnieniem warstwy konsensusu (łańcuch śledzący) i umożliwiło wypłaty ze stakingu. Capella wystąpiła synchronicznie z uaktualnieniem warstwy wykonawczej, Shanghai i włączyło funkcję wypłacania ze stakingu.
+
+To uaktualnienie warstwy konsensusu umożliwiło stakerom, którzy nie dostarczyli danych uwierzytelniających do wypłaty wraz z początkowym depozytem, zrobienie tego, umożliwiając w ten sposób wypłaty.
+
+Uaktualnienie zapewniło również funkcję automatycznego przesunięcia konta, która stale przetwarza konta walidatorów pod kątem wszelkich dostępnych płatności nagród lub pełnych wypłat.
+
+- [Więcej na temat wypłat ze stakingu](/staking/withdrawals/).
+- [Przeczytaj specyfikacje uaktualnienia Capella](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/)
+
+
+
+
+ EIP-3675 — uaktualnienie konsensusu do Proof-of-Stake EIP-4399 — zastąpienie kodu operacyjnego DIFFICULTY kodem PREVRANDAO
+
+
+---
+
+### Bellatrix {#bellatrix}
+
+
+
+
+ EIP-5133 — opóźnia bombę trudności do września 2022 r.
+
+
+ EIP-4345 — opóźnia bombę trudności do czerwca 2022 r.
+
+
+---
+
+### Altair {#altair}
+
+
+Przed uaktualnieniem londyńskim Ethereum miało bloki o stałym rozmiarze. W czasie dużego obciążenia sieci, te bloki pracowały z pełną wydajnością. W rezultacie użytkownicy często musieli czekać, aż zapotrzebowanie zmaleje, aby zostać włączeni do bloku, co doprowadzało do kiepskiego doświadczenia. Londyńska aktualizacja wprowadziła do Ethereum bloki o zmiennej wielkości.
-- [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) – _wprowadza ulepszenia rynku opłat transakcyjnych_
-- [EIP-3198](https://eips.ethereum.org/EIPS/eip-3198) – _zwraca `BASEFEE` z bloku_
-- [EIP-3529](https://eips.ethereum.org/EIPS/eip-3529) - _ogranicza zwroty kosztów gazu przy operacjach EVM_
-- [EIP-3541](https://eips.ethereum.org/EIPS/eip-3541) - _zapobiega wdrażaniu kontraktów zaczynających się od `0xEF`_
-- [EIP-3554](https://eips.ethereum.org/EIPS/eip-3554) – _opóźnia Epokę Lodowcową do grudnia 2021_
+Sposób obliczania opłat transakcyjnych w sieci Ethereum zmienił się wraz z [uaktualnieniem London](/ethereum-forks/#london) w sierpniu 2021 roku. Przed uaktualnieniem London opłaty były obliczane bez oddzielania opłat `podstawowych` i `priorytetowych` w następujący sposób:
+Powiedzmy, że Alicja musiała zapłacić Bobowi 1 ETH. W tej transakcji limit gazu wynosi 21000 jednostek, a cena gazu to 200 gwei.
+
+Całkowita opłata wyniosłaby: `Jednostki gazu (limit) * Cena gazu za jednostkę`, tj. `21 000 * 200 = 4 200 000 gwei` lub 0,0042 ETH
+
+Wdrożenie [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) w uaktualnieniu London skomplikowało mechanizm opłat transakcyjnych, ale uczyniło opłaty za gaz bardziej przewidywalnymi, co zaowocowało wydajniejszym rynkiem opłat transakcyjnych. Użytkownicy mogą przesyłać transakcje z `maxFeePerGas` odpowiadającym kwocie, jaką są gotowi zapłacić za wykonanie transakcji, wiedząc, że nie zapłacą więcej niż cena rynkowa za gaz (`baseFeePerGas`), i otrzymają zwrot nadwyżki, pomniejszonej o ich napiwek.
+
+Ten film wyjaśnia EIP-1559 i korzyści, jakie przynosi: [Wyjaśnienie EIP-1559](https://www.youtube.com/watch?v=MGemhK9t44Q)
+
+- [Jesteś deweloperem zdecentralizowanych aplikacji? Pamiętaj, aby zaktualizować swoje biblioteki i narzędzia.](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/london-ecosystem-readiness.md)
+- [Przeczytaj ogłoszenie Fundacji Ethereum](https://blog.ethereum.org/2021/07/15/london-mainnet-announcement/)
+- [Przeczytaj wyjaśnienie Ethereum Cat Herders](https://medium.com/ethereum-cat-herders/london-upgrade-overview-8eccb0041b41)
+
+
+
+
+ EIP-1559 — poprawia rynek opłat transakcyjnych EIP-3198 — zwraca BASEFEE z bloku EIP-3529 — zmniejsza zwroty kosztów gazu za operacje EVM EIP-3541 — zapobiega wdrażaniu kontraktów zaczynających się od 0xEF EIP-3554 — opóźnia epokę lodowcową do grudnia 2021 r.
---
@@ -62,31 +350,32 @@ Uaktualnienie London wprowadziło [EIP-1559](https://eips.ethereum.org/EIPS/eip-
#### Podsumowanie {#berlin-summary}
-Uaktualnienie Berlin optymalizuje koszt gazu przy pewnych działaniach EVM oraz zwiększa wsparcie wielu rodzajów transakcji.
+Uaktualnienie Berlin optymalizuje koszt gazu w pewnych działaniach EVM oraz zwiększa obsługę wielu typów transakcji.
- [Przeczytaj ogłoszenie Fundacji Ethereum](https://blog.ethereum.org/2021/03/08/ethereum-berlin-upgrade-announcement/)
-- [Przeczytaj objaśnienie Ethereum Cat Herders](https://medium.com/ethereum-cat-herders/the-berlin-upgrade-overview-2f7ad710eb80)
-
-
+- [Przeczytaj wyjaśnienie Ethereum Cat Herders](https://medium.com/ethereum-cat-herders/the-berlin-upgrade-overview-2f7ad710eb80)
-- [EIP-2565](https://eips.ethereum.org/EIPS/eip-2565) – _obniża koszt gazu ModExp_
-- [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) – _ułatwia wsparcie wielu typów transakcji_
-- [EIP-2929](https://eips.ethereum.org/EIPS/eip-2929) – _koszt gazu wzrasta dla kodów operacyjnych dostępu do stanu_
-- [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) – _dodaje opcjonalne listy dostępu_
+
+
+ EIP-2565 — obniża koszty gazu ModExp EIP-2718 — umożliwia łatwiejszą obsługę wielu typów transakcji EIP-2929 — wzrost kosztów gazu dla stanowych kodów operacyjnych dostępu EIP-2930 — dodaje opcjonalne listy dostępu
-
-- [EIP-2384](https://eips.ethereum.org/EIPS/eip-2384) - _opóźnia bombę trudności o kolejne 4 000 000 bloków, lub ~611 dni._
+
+
+ EIP-2384 — opóźnia bombę trudności o kolejne 4.000.000 bloków, czyli około 611 dni.
-
-- [EIP-152](https://eips.ethereum.org/EIPS/eip-152) – _umożliwia Ethereum korzystanie z waluty chroniącej prywatność takiej jak Zcash._
-- [EIP-1108](https://eips.ethereum.org/EIPS/eip-1108) – _tańsza kryptografia w celu obniżenia kosztów [gas](/glossary/#gas)._
-- [EIP-1344](https://eips.ethereum.org/EIPS/eip-1344) – _chroni Ethereum przed atakami metodą powtórzenia dzięki dodaniu [opcode] `CHAINID` (/developers/docs/ethereum-stack/#ethereum-virtual-machine)._
-- [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884) – _optymalizacja cen gazu dla kodów operacyjnych na podstawie zużycia._
-- [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028) – _ograniczenie kosztów CallData w celu zwiększenia ilość danych w blokach – korzystne dla [skalowania warstwy 2](/developers/docs/scaling/#rollups)._
-- [EIP-2200](https://eips.ethereum.org/EIPS/eip-2200) – _inne zmiany dotyczące cen gazu dla kodów operacyjnych._
+
+
+ EIP-152 — pozwala Ethereum współpracować z walutami chroniącymi prywatność, takimi jak Zcash. EIP-1108 – tańsza kryptografia w celu obniżenia kosztów [gazu](/glossary/#gas). EIP-1344 – chroni Ethereum przed atakami typu replay, dodając [kod operacyjny](/developers/docs/ethereum-stack/#ethereum-virtual-machine) CHAINID. EIP-1884 — optymalizacja cen gazu kodu operacyjnego na podstawie zużycia. EIP-2028 – zmniejsza koszt CallData, aby umożliwić umieszczanie większej ilości danych w blokach – dobre dla [skalowania warstwy 2](/developers/docs/scaling/#layer-2-scaling). EIP-2200 — inne zmiany cen gazu w kodzie operacyjnym.
---
@@ -170,19 +461,21 @@ Fork Istanbul:
Fork Constantinople:
-- Zapewnił, że blockchain nie został zamrożony przed [wdrożeniem proof-of-stake](#beacon-chain-genesis).
-- Zoptymalizował koszt [gazu](/glossary/#gas) w niektórych działaniach [EVM](/developers/docs/ethereum-stack/#ethereum-virtual-machine).
+- Zmniejszono nagrody za [wydobycie](/developers/docs/consensus-mechanisms/pow/mining/) bloków z 3 do 2 ETH.
+- Zapewniono, że blockchain nie zamarznie przed [wdrożeniem proof-of-stake](#beacon-chain-genesis).
+- Zoptymalizowano koszt [gazu](/glossary/#gas) dla niektórych działań w [EVM](/developers/docs/ethereum-stack/#ethereum-virtual-machine).
- Dodał możliwość interakcji z adresami, które nie zostały jeszcze utworzone.
[Przeczytaj ogłoszenie Fundacji Ethereum](https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/)
-
-
-- [EIP-145] (https://eips.ethereum.org/EIPS/eip-145) – _optymalizuje koszt niektórych działań w łańcuchu._
-- [EIP-1014](https://eips.ethereum.org/EIPS/eip-1014) – _pozwala na interakcję z adresami, które nie zostały jeszcze utworzone._
-- [EIP-1052](https://eips.ethereum.org/EIPS/eip-1052) – _optymalizuje koszt niektórych działań w łańcuchu._
-- [EIP-1234](https://eips.ethereum.org/EIPS/eip-1234) – _upewnia się, że blockchain nie zawiesza się przed sprawdzeniem proof-of-stake._
+
+
+ EIP-145 - Optymalizuje koszt pewnych działań na łańcuchu. EIP-1014 — umożliwia interakcję z adresami, które nie zostały jeszcze utworzone. EIP-1052 - Wprowadza EXTCODEHASH instrukcje do uzyskania haszu z kodu innego kontraktu. EIP-1234 – zapewnia, że blockchain nie zamarznie przed proof-of-stake i zmniejsza nagrodę za blok z 3 do 2 ETH.
-
-- [EIP-140](https://eips.ethereum.org/EIPS/eip-140) – _dodaje kod operacyjny `REVERT._
-- [EIP-658](https://eips.ethereum.org/EIPS/eip-658) – _do pokwitowań transakcji dodano pole statusu, aby wskazać powodzenie lub niepowodzenie._
-- [EIP-196](https://eips.ethereum.org/EIPS/eip-196) – _dodaje krzywą eliptyczną i mnożenie skalarne, aby zezwolić na [ZK-Snarks](/developers/docs/scaling/zk-rollups/)._
-- [EIP-197](https://eips.ethereum.org/EIPS/eip-197) – _dodaje krzywą eliptyczną i mnożenie skalarne, aby zezwolić na [ZK-Snarks](/developers/docs/scaling/zk-rollups/)._
-- [EIP-198](https://eips.ethereum.org/EIPS/eip-198) – _umożliwia weryfikację podpisu RSA._
-- [EIP-211](https://eips.ethereum.org/EIPS/eip-211) – _dodaje obsługę wartości zwracanych o różnych długościach._
-- [EIP-214](https://eips.ethereum.org/EIPS/eip-214) – _dodaje kod operacyjny `STATICCALL` umożliwiający wykonywanie niezmieniających stanu wywołań innych kontraktów._
-- [EIP-100](https://eips.ethereum.org/EIPS/eip-100) – _zmienia wzór dostosowywania trudności._
-- [EIP-649](https://eips.ethereum.org/EIPS/eip-649) – _opóźnia [bombę trudności](/glossary/#difficulty-bomb) o 1 rok i zmniejsza nagrody za blok z 5 do 3 ETH._
-
+
+
+
+ EIP-140 — dodaje kod operacyjny REVERT. EIP-658 — dodaje pole statusu do potwierdzeń transakcji w celu wskazania powodzenia lub niepowodzenia. EIP-196 – dodaje krzywą eliptyczną i mnożenie skalarne, aby umożliwić [ZK-Snarks](/developers/docs/scaling/zk-rollups/). EIP-197 – dodaje krzywą eliptyczną i mnożenie skalarne, aby umożliwić [ZK-Snarks](/developers/docs/scaling/zk-rollups/). EIP-198 — umożliwia weryfikację podpisu RSA. EIP-211 — dodaje obsługę wartości zwracanych o zmiennej długości. EIP-214 — dodaje kod operacyjny STATICCALL, umożliwiający niezmieniające stanu wywołania do innych kontraktów. EIP-100 — zmienia formułę dostosowania trudności. EIP-649 – opóźnia [bombę trudności](/glossary/#difficulty-bomb) o 1 rok i zmniejsza nagrodę za blok z 5 do 3 ETH.
-
-- [EIP-155](https://eips.ethereum.org/EIPS/eip-155) – _zapobiega ponownemu przesyłaniu transakcji z jednego łańcucha Ethereum do innego łańcucha, na przykład transakcji w sieci testowej do głównego łańcucha Ethereum._
-- [EIP-160](https://eips.ethereum.org/EIPS/eip-160) – _dostosowuje ceny kodu operacyjnego `EXP` — utrudnia spowolnienie sieci poprzez kosztowne obliczeniowo operacje na kontraktach._
-- [EIP-161](https://eips.ethereum.org/EIPS/eip-161) – _umożliwia usuwanie pustych kont dodanych za pośrednictwem ataku DOS._
-- [EIP-170](https://eips.ethereum.org/EIPS/eip-170) – _zmienia maksymalny dozwolony rozmiar kodu kontraktu w blockchainie na 24576 bajty._
+
+
+ EIP-155 — zapobiega ponownemu przesyłaniu transakcji z jednego łańcucha Ethereum do alternatywnego łańcucha, na przykład ponownemu przesyłaniu transakcji sieci testowej do głównego łańcucha Ethereum. EIP-160 — dostosowuje ceny kodu operacyjnego EXP — utrudnia spowolnienie sieci poprzez kosztowne obliczeniowo operacje kontraktu. EIP-161 — umożliwia usunięcie pustych kont dodanych przez ataki DOS. EIP-170 — zmienia maksymalny rozmiar kodu, jaki może mieć kontrakt na blockchainie do 24.576 bajtów.
---
@@ -253,17 +548,18 @@ Fork Spurious Dragon był drugą odpowiedzią na ataki typu DoS (odmowa usługi)
#### Podsumowanie {#tangerine-whistle-summary}
-Fork Tangerine Whistle był pierwszą odpowiedzią na ataki typu „odmowa usługi” (DoS) na sieć (wrzesień/październik 2016 r.). Uwzględniał:
+Fork Tangerine Whistle był pierwszą odpowiedzią na ataki typu DoS (odmowa usługi) na sieć (wrzesień/październik 2016 r.). Uwzględniał:
-- rozwiązywanie pilnych problemów dotyczących kondycji sieci związanych z niedoszacowanymi kodami operacyjnymi.
+- rozwiązywanie pilnych problemów dotyczących kondycji sieci związanych z kodami operacyjnymi o zaniżonych cenach.
[Przeczytaj ogłoszenie Fundacji Ethereum](https://blog.ethereum.org/2016/10/18/faq-upcoming-ethereum-hard-fork/)
-
-
-- [EIP-150](https://eips.ethereum.org/EIPS/eip-150) – _zwiększa koszty gazu w kodach operacyjnych, które można wykorzystać w atakach spamowych._
-- [EIP-158](https://eips.ethereum.org/EIPS/eip-158) – _redukuje rozmiar stanu, usuwając dużą liczbę pustych kont, które zostały wprowadzone w stan bardzo niskim kosztem z powodu błędów we wcześniejszych wersjach protokołu Ethereum._
+
+
+ EIP-150 — zwiększa koszty gazu kodów operacyjnych, które mogą być wykorzystywane w atakach spamowych. EIP-158 — zmniejsza rozmiar stanu poprzez usunięcie dużej liczby pustych kont, które zostały umieszczone w stanie przy bardzo niskich kosztach z powodu błędów we wcześniejszych wersjach protokołu Ethereum.
---
@@ -274,11 +570,11 @@ Fork Tangerine Whistle był pierwszą odpowiedzią na ataki typu „odmowa usłu
#### Podsumowanie {#dao-fork-summary}
-Fork DAO był odpowiedzią na [atak DAO 2016](https://www.coindesk.com/learn/understanding-the-dao-attack), który doprowadził do złamania niezabezpieczonego kontraktu [DAO](/glossary/#dao) i kradzieży ponad 3,6 mln ETH. Fork przeniósł fundusze z błędnego kontraktu do [nowego kontraktu](https://etherscan.io/address/0xbf4ed7b27f1d666546e30d74d50d173d20bca754) z jedną funkcją: wypłać. Każdy, kto stracił środki, mógł wypłacić 1 ETH za każde 100 tokenów DAO w swoim portfelu.
+Fork DAO był odpowiedzią na [atak na DAO w 2016 roku](https://www.coindesk.com/learn/understanding-the-dao-attack/), w wyniku którego z niezabezpieczonego kontraktu [DAO](/glossary/#dao) skradziono w ramach hacku ponad 3,6 miliona ETH. Fork przeniósł środki z wadliwego kontraktu do [nowego kontraktu](https://eth.blockscout.com/address/0xbf4ed7b27f1d666546e30d74d50d173d20bca754) z jedną funkcją: wypłata. Każdy, kto stracił środki, mógł wypłacić 1 ETH za każde 100 tokenów DAO w swoim portfelu.
-Ten kierunek działania został przegłosowany przez społeczność Ethereum. Każdy posiadacz ETH mógł głosować za pośrednictwem transakcji na [platformie do głosowania](http://v1.carbonvote.com/). Decyzja o forku została poparta ponad 85% głosów.
+Ten kierunek działania został przegłosowany przez społeczność Ethereum. Każdy posiadacz ETH mógł głosować za pomocą transakcji na [platformie do głosowania](https://web.archive.org/web/20170620030820/http://v1.carbonvote.com/). Decyzja o forku osiągnęła ponad 85% głosów.
-Niektórzy górnicy odmówili forku, ponieważ incydent DAO nie był defektem protokołu. Następnie utworzyli [Ethereum Classic](https://ethereumclassic.org/).
+Niektórzy górnicy odmówili forka, ponieważ incydent DAO nie był wadą protokołu. W ten sposób utworzyli [Ethereum Classic](https://ethereumclassic.org/).
[Przeczytaj ogłoszenie Fundacji Ethereum](https://blog.ethereum.org/2016/07/20/hard-fork-completed/)
@@ -290,31 +586,33 @@ Niektórzy górnicy odmówili forku, ponieważ incydent DAO nie był defektem pr
#### Podsumowanie {#homestead-summary}
-Przyszłościowy fork Homestead. Obejmował kilka zmian protokołu i zmianę sieci, która dała Ethereum możliwość wykonywania dalszych aktualizacji sieci.
+Przyszłościowy fork Homestead. Obejmował kilka zmian protokołu i zmianę sieci, która dała Ethereum możliwość wykonywania dalszych uaktualnień sieci.
[Przeczytaj ogłoszenie Fundacji Ethereum](https://blog.ethereum.org/2016/02/29/homestead-release/)
-
-
-- [EIP-2](https://eips.ethereum.org/EIPS/eip-2) – _dokonuje zmian w procesie tworzenia kontraktu._
-- [EIP-7](https://eips.ethereum.org/EIPS/eip-7) – _dodaje nowy kod operacji: `DELEGATECALL`_
-- [EIP-8](https://eips.ethereum.org/EIPS/eip-8) – _wprowadza wymagania zgodności w przód z devp2p_
+
+
+ EIP-2 — wprowadza zmiany w procesie tworzenia kontraktu. EIP-7 — dodaje nowy kod operacyjny: DELEGATECALL EIP-8 — wprowadza wymagania kompatybilności devp2p na przyszłość
- Dokumentacja
+ Whitepaper
diff --git a/public/content/translations/pl/foundation/index.md b/public/content/translations/pl/foundation/index.md
index f6d3bc46825..88533f73a11 100644
--- a/public/content/translations/pl/foundation/index.md
+++ b/public/content/translations/pl/foundation/index.md
@@ -1,34 +1,33 @@
---
-title: Fundacja Ethereum
-description: Dowiedz się więcej o Fundacji Ethereum (EF), organizacji non-profit poświęconej wspieraniu Ethereum i powiązanych technologii.
+title: Ethereum Foundation
+description: "Dowiedz się więcej o Fundacji Ethereum (EF), organizacji non-profit poświęconej wspieraniu Ethereum i powiązanych technologii."
hideEditButton: true
lang: pl
---
-# O Fundacji Ethereum {#about-the-ethereum-foundation}
+# Ethereum Foundation {#ethereum-foundation}
- Konta Ethereum
-
+
- ABI - binarny interfejs aplikacji
-
+
- Ochrona
-
-
-### poświadczenie {#attestation}
-
-Walidator głosuje na [łańcuch śledzący](#beacon-chain) lub [blok](#block) [odłamków](#shard). Walidatorzy muszą poświadczyć bloki, sygnalizując, że zgadzają się ze stanem zaproponowanym przez blok.
+
- Łańcuch śledzący
-
+
- Bloki
-
+
- Czym jest blockchain?
-
+
- Kompilowanie inteligentnych kontraktów
-
+
- Proof-of-stake
-
+
- Zdecentralizowane Organizacje Autonomiczne (DAO)
-
+
- Wprowadzenie do zdecentralizowanych aplikacji
-
+
- Giełdy scentralizowane
-
+
- Zdecentralizowane finanse (DeFi)
-
+
- Proof-of-stake
-
-
-### Wniosek dotyczący usprawnienia Ethereum (EIP) {#eip}
+
- Wprowadzenie do EIP
-
+
- Wprowadzenie do EIP
-
+
- Waluta na naszą cyfrową przyszłość
-
+
- Wydarzenia i dzienniki
-
-
-### Maszyna Wirtualna Ethereum (EVM) {#evm}
-
-Wirtualna maszyna bazująca na stosie, która wykonuje [kod bajtowy](#bytecode). W Ethereum model wykonania określa, w jaki sposób stan systemu jest zmieniany na podstawie serii instrukcji kodu bajtowego i małej krotki danych środowiskowych. Jest to określone przez formalny model wirtualnej maszyny stanu.
-
-
- Maszyna Wirtualna Ethereum
-
-
-### język asemblera EVM {#evm-assembly-language}
-
-Czytelna dla człowieka forma [kodu bajtowego](#bytecode) EVM.
+
- Krany sieci testowej
-
+
- Nieodwołalność proof-of-work
-
- Nieodwołalność proof-of-stake
-
+15 [wei](#wei). 103 finney = 1 ether.
-
-### fork {#fork}
-
-Zmiana protokołu, powodująca utworzenie alternatywnego łańcucha lub czasowe rozbieżności w dwóch potencjalnych ścieżkach blokowych podczas wydobycia.
-
-### dowód oszustwa {#fraud-proof}
-
-Model bezpieczeństwa dla niektórych rozwiązań [warstwy 2](#layer-2), gdzie w celu zwiększenia szybkości transakcje są [wrzucane](#rollups) do partii i przesyłane do Ethereum w jednej transakcji. Zakłada się, że są one ważne, ale można je zakwestionować, jeżeli podejrzewa się nadużycia finansowe. Dowód oszustwa przeprowadzi następnie transakcję, aby sprawdzić, czy doszło do oszustwa. Ta metoda zwiększa liczbę możliwych transakcji przy jednoczesnym zachowaniu bezpieczeństwa. Niektóre [wartości zbiorcze](#rollups) używają [dowodów ważności](#validity-proof).
-
-
- Optymistyczne pakiety zbiorcze
-
-
-### granica {#frontier}
-
-Pierwotny etap testowania Ethereum, trwający od lipca 2015 r. do marca 2016 r.
+
- Gaz i opłaty
-
-
-### limit gazu {#gas-limit}
-
-Maksymalna ilość [gazu](#gas), którą może wykorzystać [transakcja](#transaction) lub [blok](#block).
-
-### blok genezy {#genesis-block}
-
-Pierwszy blok w [blockchainie](#blockchain), używany do inicjowania określonej sieci i jej kryptowaluty.
+9 [wei](#wei). 109 gwei = 1 ether.
+
- Środowisko IDE
-
+
- Wdrażanie inteligentnych kontraktów
-
+
- Ochrona
-
-
-### keccak-256 {#keccak-256}
+
- Warstwa 2
-
+
- Biblioteki kontraktów inteligentnych
-
-
-### lekki klient {#lightweight-client}
-
-Klient Ethereum, który nie przechowuje lokalnej kopii [blockchainu](#blockchain) ani nie weryfikuje bloków ani [transakcji](#transaction). Oferuje funkcje [portfela](#wallet) oraz może tworzyć i rozsyłać transakcje.
+
- Wydobycie
-
+
- Sieci
-
-
-### token niezamienny (NFT) {#nft}
-
-Nazywany także deed. Jest to standardowy token wprowadzony na podstawie propozycji ERC721. Tokeny NFT można śledzić i handlować nimi, ale każdy token jest unikatowy i odmienny; nie są zamienne jak ETH i [tokeny ERC-20](#token-standard). Tokeny NFT mogą reprezentować prawo własności zasobów cyfrowych lub fizycznych.
-
-
- Tokeny niewymienne (NFT)
-
- ERC-721 – standard tokenów niewymiennych
-
-
-### node {#node}
+
- Węzły i klienci
-
+
- Węzły i klienci
-
+
- Optymistyczne pakiety zbiorcze
-
+
- Plazma
-
+
- Proof-of-stake
-
+
- Proof-of-work
-
+
- Wielobieżność
-
+
- Pakiety zbiorcze
-
+
- Ethereum 2.0 (Eth2)
-
-
-### SHA (Secure Hash Algorithm) {#sha}
-
-Rodzina kryptograficznych funkcji skrótu opublikowanych przez Narodowy Instytut Norm i Technologii (NIST).
+
- Łańcuchy szczątkowe
-
+
- Łańcuchy boczne
-
+
- Proof-of-stake
-
+
- Wprowadzenie do inteligentnych kontraktów
-
+
- Solidity
-
+
- ETH nie jest jedyną kryptowalutą na Ethereum
-
+
- Zestakuj swój ETH, aby zostać walidatorem Ethereum
-
-
-### kanały uzyskiwania informacyji {#state-channels}
-
-Rozwiązanie [warstwy 2](#layer-2), polegające na ustanowieniu między uczestnikami kanału, w którym mogą swobodnie i tanio przeprowadzać transakcje. Tylko [transakcja](#transaction) ustanawiająca i zamykająca kanał jest wysyłana do [sieci głównej](#mainnet). Pozwala to na bardzo wysoką przepustowość transakcji, ale opiera się na wcześniejszej znajomości liczby uczestników i blokowaniu funduszy.
-
-
- Kanały uzyskiwania informacji
-
-
-### szabo {#szabo}
-
-Nazwa [etheru](#ether). 1 szabo = 1012 [wei](#wei), 106 szabo = 1 ether.
+
- Sieci testowe
-
-
-### standard tokenów {#token-standard}
-
-Wprowadzony we wniosku ERC-20 zapewnia znormalizowaną strukturę [kontraktów inteligentnych](#smart-contract) dla zamiennych tokenów. Tokeny z tego samego kontraktu mogą być śledzone, sprzedawane i wymieniane, w przeciwieństwie do [NFT](#nft).
-
-
- Standard tokena ERC-20
-
+
- Transakcje
-
+
- Proof-of-stake
-
- Stakowanie w Ethereum
-
-
-### Dowód ważności {#validity-proof}
-
-Model bezpieczeństwa dla niektórych rozwiązań [warstwy 2](#layer-2), gdzie w celu zwiększenia szybkości transakcje są [wrzucane](/#rollups) do partii i przesyłane do Ethereum w jednej transakcji. Obliczanie transakcji odbywa się poza łańcuchem, a następnie jest dostarczane do głównego łańcucha wraz z dowodem ich ważności. Ta metoda zwiększa liczbę możliwych transakcji przy jednoczesnym zachowaniu bezpieczeństwa. Niektóre [pakiety zbiorcze](#rollups) używają [dowodu oszustwa](#fraud-proof).
-
-
- Pakiety zbiorcze o wiedzy zerowej
-
-
-### Validium {#validium}
+
- Validium
-
+
- Vyper
-
+
- Portfele Ethereum
-
-
-### Web3 {#web3}
+
- Web2 vs Web3
-
+18 wei = 1 ether.
+
- Pakiety zbiorcze o wiedzy zerowej
-
+