diff --git a/public/content/translations/pl/developers/docs/security/index.md b/public/content/translations/pl/developers/docs/security/index.md
index efbfe7b1ee8..9edf9bbb76c 100644
--- a/public/content/translations/pl/developers/docs/security/index.md
+++ b/public/content/translations/pl/developers/docs/security/index.md
@@ -1,6 +1,6 @@
---
title: Ochrona
-description: Kwestie bezpieczeństwa dla deweloperów Ethereum
+description: "Kwestie bezpieczeństwa dla deweloperów Ethereum"
lang: pl
---
diff --git a/public/content/translations/pl/developers/docs/smart-contracts/anatomy/index.md b/public/content/translations/pl/developers/docs/smart-contracts/anatomy/index.md
index 21640c0184b..d4f7f0d9596 100644
--- a/public/content/translations/pl/developers/docs/smart-contracts/anatomy/index.md
+++ b/public/content/translations/pl/developers/docs/smart-contracts/anatomy/index.md
@@ -1,25 +1,25 @@
---
-title: Anatomia inteligentnych kontraktów
-description: Szczegółowa analiza anatomii inteligentnego kontaktu – funkcji, danych i zmiennych.
+title: "Anatomia inteligentnych kontraktów"
+description: "Szczegółowa analiza anatomii inteligentnego kontaktu – funkcji, danych i zmiennych."
lang: pl
---
Inteligentny kontrakt to program, który działa pod adresem Ethereum. Składają się z danych i funkcji, które można wykonać po otrzymaniu transakcji. Oto przegląd tego, co stanowi inteligentny kontrakt.
-## Warunki wstępne {#prerequisites}
+## Wymagania wstępne {#prerequisites}
-Upewnij się, że najpierw przeczytałeś o [inteligentnych kontraktach](/developers/docs/smart-contracts/). Ten dokument zakłada, że znasz już języki programowania, takie jak JavaScript lub Python.
+Upewnij się, że najpierw przeczytałeś/aś o [inteligentnych kontraktach](/developers/docs/smart-contracts/). Ten dokument zakłada, że znasz już języki programowania, takie jak JavaScript lub Python.
## Dane {#data}
-Wszelkie dane kontraktu muszą być przypisane do lokalizacji: do `storage ` lub `memory`. Modyfikacja pamięci masowej w inteligentnym kontrakcie jest kosztowna, więc musisz zastanowić się, gdzie powinny znajdować się Twoje dane.
+Wszelkie dane kontraktu muszą być przypisane do lokalizacji: do `storage` lub `memory`. Modyfikacja pamięci masowej w inteligentnym kontrakcie jest kosztowna, więc musisz zastanowić się, gdzie powinny znajdować się Twoje dane.
-### Pamięć {#storage}
+### Przechowywanie {#storage}
Trwałe dane są nazywane pamięcią masową i są reprezentowane przez zmienne stanu. Te wartości są przechowywane na stałe w blockchain. Musisz zadeklarować typ, aby kontrakt mógł śledzić, ile pamięci w blockchainie potrzebuje podczas kompilacji.
```solidity
-// Przykład Solidity
+// Przykład w Solidity
contract SimpleStorage {
uint storedData; // Zmienna stanu
// ...
@@ -31,7 +31,7 @@ contract SimpleStorage {
storedData: int128
```
-Jeśli programowałeś już w językach obiektowych, prawdopodobnie znasz większość typów. Jednak `address` powinien być dla Ciebie nowy, jeśli dopiero zaczynasz programować w Ethereum.
+Jeśli programowałeś już w językach obiektowych, prawdopodobnie znasz większość typów. Jednak typ `address` powinien być dla Ciebie nowością, jeśli dopiero zaczynasz programować w Ethereum.
Typ `address` może zawierać adres Ethereum, który odpowiada 20 bajtom lub 160 bitom. Jest zwracany w zapisach szesnastkowych z wiodącym 0x.
@@ -41,22 +41,22 @@ Inne typy:
- liczba całkowita
- fixed point numbers
- fixed-size byte arrays
-- dynamically-sized byte arrays
-- Rational and integer literals
-- String literals
-- Hexadecimal literals
-- Enums
+- dynamicznie wymiarowane tablice bajtów
+- literały wymierne i całkowite
+- literały ciągów znaków
+- literały szesnastkowe
+- enumy
Aby uzyskać więcej wyjaśnień, zapoznaj się z dokumentami:
-- [Zobacz typy Vyper](https://vyper.readthedocs.io/en/v0.1.0-beta.6/types.html#value-types)
-- [Zobacz typy Solidity](https://solidity.readthedocs.io/en/latest/types.html#value-types)
+- [Zobacz typy Vyper](https://docs.vyperlang.org/en/v0.1.0-beta.6/types.html#value-types)
+- [Zobacz typy Solidity](https://docs.soliditylang.org/en/latest/types.html#value-types)
### Pamięć {#memory}
Wartości przechowywane tylko przez cały okres wykonywania funkcji kontraktowej nazywane są zmiennymi pamięci. Ponieważ nie są one przechowywane na stałe w blockchain, są znacznie tańsze w użyciu.
-Dowiedz się więcej o tym, jak EVM przechowuje dane (magazyn, pamięć i stos) w [Dokumenty Solidity](https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html?highlight=memory#storage-memory-and-the-stack).
+Dowiedz się więcej o tym, jak EVM przechowuje dane (Storage, Memory i Stack) w [dokumentacji Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#storage-memory-and-the-stack).
### Zmienne środowiskowe {#environment-variables}
@@ -64,9 +64,9 @@ Oprócz zmiennych, które definiujesz w kontrakcie, istnieją pewne specjalne zm
Przykłady:
-| **Prop** | **Zmienna stanu** | **Opis** |
-| ----------------- | ----------------- | -------------------------------------- |
-| `block.timestamp` | uint256 | Aktualny blok — znacznik czasu epoki |
+| **Prop** | **Zmienna stanu** | **Opis** |
+| ----------------- | ----------------- | --------------------------------------------------------- |
+| `block.timestamp` | uint256 | Aktualny blok — znacznik czasu epoki |
| `msg.sender` | address | Nadawca wiadomości (bieżące wywołanie) |
## Funkcje {#functions}
@@ -75,15 +75,15 @@ W najbardziej uproszczonym ujęciu, funkcje mogą pobierać informacje lub ustaw
Istnieją dwa rodzaje wywołań funkcji:
-- `internal` – nie tworzą one wywołania EVM
- - Do funkcji i zmiennych stanu internal można uzyskać dostęp wyłącznie wewnętrznie (tzn. z bieżącego kontraktu lub pochodzących od niego kontraktów)
-- `external` – tworzą one wywołanie EVM
- - Funkcje zewnętrzne są częścią interfejsu kontraktu, co oznacza, że mogą być wywoływane z innych kontraktów oraz poprzez transakcje. Funkcja zewnętrzna `f` nie może być wywołana wewnętrznie (tj. `f()` nie działa, ale `this.f()` działa).
+- `internal` – nie tworzą wywołania EVM
+ - Wewnętrzne funkcje i zmienne stanu są dostępne tylko wewnętrznie (tj. z poziomu bieżącego kontraktu lub kontraktów z niego dziedziczących)
+- `external` – tworzą wywołanie EVM
+ - Funkcje zewnętrzne są częścią interfejsu kontraktu, co oznacza, że mogą być wywoływane z innych kontraktów oraz poprzez transakcje. Zewnętrzna funkcja `f` nie może być wywoływana wewnętrznie (tj. `f()` nie działa, ale `this.f()` działa).
-Mogą być także `public` lub `private`
+Mogą być również `public` lub `private`
-- Funkcje `public` mogą być wywoływane wewnętrznie w ramach kontraktu lub zewnętrznie za pośrednictwem wiadomości
-- Funkcje `private` są widoczne tylko dla kontraktu, w którym są zdefiniowane, a nie w kontraktach zależnych
+- Funkcje `public` mogą być wywoływane wewnętrznie z poziomu kontraktu lub zewnętrznie za pomocą wiadomości
+- Funkcje `private` są widoczne tylko dla kontraktu, w którym są zdefiniowane, a nie w kontraktach pochodnych
Zarówno funkcje, jak i zmienne stanu mogą być publiczne lub prywatne
@@ -97,10 +97,10 @@ function update_name(string value) public {
```
- Parametr `value` typu `string` jest przekazywany do funkcji: `update_name`
-- Jest zadeklarowany jako `public`, co oznacza, że każdy może uzyskać do niego dostęp
-- Nie jest zadeklarowany `view`, więc może modyfikować stan kontraktu
+- Jest zadeklarowana jako `public`, co oznacza, że każdy może uzyskać do niej dostęp
+- Nie jest zadeklarowana jako `view`, więc może modyfikować stan kontraktu
-### Funkcje view {#view-functions}
+### Funkcje `view` {#view-functions}
Funkcje te obiecują nie zmieniać stanu danych kontraktu. Typowe przykłady to funkcje „getter”, które można wykorzystać na przykład do uzyskania salda użytkownika.
@@ -123,25 +123,25 @@ def readName() -> string:
Co jest uważane za modyfikację stanu:
1. Zapis do zmiennych stanu.
-2. [Emisja zdarzeń](https://solidity.readthedocs.io/en/v0.7.0/contracts.html#events).
-3. [Tworzenie innych kontraktów](https://solidity.readthedocs.io/en/v0.7.0/control-structures.html#creating-contracts).
+2. [Emitowanie zdarzeń](https://docs.soliditylang.org/en/v0.7.0/contracts.html#events).
+3. [Tworzenie innych kontraktów](https://docs.soliditylang.org/en/v0.7.0/control-structures.html#creating-contracts).
4. Używanie `selfdestruct`.
5. Wysyłanie etheru za pomocą wywołań.
-6. Wywołanie dowolnej funkcji nieoznaczonej `view` lub `pure`.
+6. Wywoływanie dowolnej funkcji nieoznaczonej jako `view` lub `pure`.
7. Używanie wywołań niskiego poziomu.
8. Korzystanie z asemblera wbudowanego, który zawiera określone kody operacji.
-### Funkcje constructor {#constructor-functions}
+### Funkcje konstruktora {#constructor-functions}
-`konstruktor` funkcje są wykonywane tylko raz w momencie pierwszego wdrożenia kontraktu. Podobnie jak `konstruktor` w wielu językach programowania opartych na klasie, funkcje te często inicjują zmienne stanu do ich określonych wartości.
+Funkcje `constructor` są wykonywane tylko raz podczas pierwszego wdrożenia kontraktu. Podobnie jak `constructor` w wielu językach programowania opartych na klasach, funkcje te często inicjalizują zmienne stanu do ich określonych wartości.
```solidity
-// Przykład Solidity
-// Inicjuje dane umowy, ustawia `właściciela`
+// Przykład w Solidity
+// Inicjalizuje dane kontraktu, ustawiając `owner`
// na adres twórcy kontraktu.
constructor() public {
- // Wszystkie inteligentne kontrakty opierają się na transakcjach zewnętrznych, aby wyzwolić swoje funkcje.
- // `msg` to zmienna globalna zawierająca odpowiednie dane dotyczące danej transakcji,
+ // Wszystkie inteligentne kontrakty opierają się na zewnętrznych transakcjach, aby uruchomić swoje funkcje.
+ // `msg` to globalna zmienna, która zawiera istotne dane dotyczące danej transakcji,
// takie jak adres nadawcy i wartość ETH zawarta w transakcji.
// Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties
owner = msg.sender;
@@ -158,7 +158,7 @@ def __init__(_beneficiary: address, _bidding_time: uint256):
self.auctionEnd = self.auctionStart + _bidding_time
```
-### Wbudowane funkcje {#built-in-functions}
+### Funkcje wbudowane {#built-in-functions}
Oprócz zmiennych i funkcji, które definiujesz w kontrakcie, istnieje kilka specjalnych wbudowanych funkcji. Najbardziej oczywistym przykładem jest:
@@ -180,66 +180,66 @@ Twoja funkcja wymaga:
pragma solidity >=0.4.0 <=0.6.0;
contract ExampleDapp {
- string dapp_name; // state variable
+ string dapp_name; // zmienna stanu
- // Called when the contract is deployed and initializes the value
+ // Wywoływane podczas wdrażania kontraktu, inicjalizuje wartość
constructor() public {
- dapp_name = "My Example dapp";
+ dapp_name = "Moja przykładowa dapka";
}
- // Get Function
+ // Funkcja pobierająca
function read_name() public view returns(string) {
return dapp_name;
}
- // Set Function
+ // Funkcja ustawiająca
function update_name(string value) public {
dapp_name = value;
}
}
```
-Pełny kontrakt może wyglądać w ten sposób. Tutaj funkcja `constructor` zapewnia początkową wartość zmiennej `dapp_name`.
+Pełny kontrakt może wyglądać w ten sposób. Tutaj funkcja `constructor` zapewnia wartość początkową dla zmiennej `dapp_name`.
-## Zdarzenia i dzienniki {#events-and-logs}
+## Zdarzenia i logi {#events-and-logs}
-Zdarzenia pozwalają Ci komunikować się z inteligentnym kontraktem z Twojego frontendu lub innych aplikacji subskrybujących. Gdy transakcja zostanie wykopana, inteligentne kontrakty mogą emitować zdarzenia i zapisywać do blockchainu dzienniki, które frontend może następnie przetworzyć.
+Wydarzenia umożliwiają inteligentnemu kontraktowi komunikację z frontendem oraz innymi subskrybującymi aplikacjami. Kiedy transakcja zostanie potwierdzona i dodana do bloku, inteligentne kontrakty mogą nadawać wydarzenia i rejestrować informacje, które frontend może przetwarzać i wykorzystywać.
-## Przykłady z komentarzami {#annotated-examples}
+## Przykłady z adnotacjami {#annotated-examples}
-Są to niektóre przykłady napisane w Solidity. Jeśli chcesz pobawić się kodem, możesz wchodzić z nimi w interakcję w [Remix](http://remix.ethereum.org).
+Są to niektóre przykłady napisane w Solidity. Jeśli chcesz pobawić się kodem, możesz wejść z nimi w interakcję w [Remix](http://remix.ethereum.org).
-### Witaj świecie {#hello-world}
+### Witaj, świecie {#hello-world}
```solidity
-// Określa wersję Solidity przy użyciu wersji semantycznej.
-// Więcej informacji: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma
+// Określa wersję Solidity, używając wersjonowania semantycznego.
+// Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma
pragma solidity ^0.5.10;
// Definiuje kontrakt o nazwie `HelloWorld`.
-// Kontrakt jest zbiorem funkcji i danych (jego stanu).
-// Po wdrożeniu kontrakt znajduje się pod określonym adresem w blockchainie Ethereum.
+// Kontrakt to zbiór funkcji i danych (jego stanu).
+// Po wdrożeniu kontrakt znajduje się pod określonym adresem na blockchainie Ethereum.
// Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html
contract HelloWorld {
// Deklaruje zmienną stanu `message` typu `string`.
- // zmienne stanu to zmienne, których wartości są stale przechowywane w pamięci kontraktów.
- // Słowo kluczowe `public` udostępnia zmienne spoza kontraktu
- // i tworzy funkcję, którą inne kontrakty lub klienci mogą wywołać, aby uzyskać dostęp do tej wartości.
- ciąg wiadomości publicznych;
-
- // Podobne do wielu języków obiektowych opartych na klasie, konstruktorem jest
- // specjalna funkcja, która jest wykonywana tylko w momencie tworzenia kontraktu.
- // Konstruktory są używane do inicjowania danych kontraktu.
+ // Zmienne stanu to zmienne, których wartości są trwale przechowywane w pamięci kontraktu (storage).
+ // Słowo kluczowe `public` udostępnia zmienne na zewnątrz kontraktu
+ // i tworzy funkcję, którą inne kontrakty lub klienci mogą wywołać, aby uzyskać dostęp do wartości.
+ string public message;
+
+ // Podobnie jak w wielu obiektowych językach programowania opartych na klasach, konstruktor jest
+ // specjalną funkcją, która jest wykonywana tylko podczas tworzenia kontraktu.
+ // Konstruktory służą do inicjalizacji danych kontraktu.
// Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors
constructor(string memory initMessage) public {
- //Akceptuje argument ciągu `initMessage` i ustawia wartość
- // na zmienną pamięci kontraktu `message`).
- wiadomość = initMessage;
+ // Akceptuje argument typu string `initMessage` i ustawia wartość
+ // w zmiennej `message` w pamięci kontraktu (storage).
+ message = initMessage;
}
- // funkcja publiczna, która akceptuje argument ciągu
- // i aktualizuje zmienną pamięci `message`.
+ // Funkcja publiczna, która akceptuje argument typu string
+ // i aktualizuje zmienną `message` w pamięci kontraktu (storage).
function update(string memory newMessage) public {
message = newMessage;
}
@@ -252,138 +252,136 @@ contract HelloWorld {
pragma solidity ^0.5.10;
contract Token {
- // Adres porównywalny z adresem e-mail - jest używany do indentyfikacji konta w Ethereum.
- // Adresy mogą reprezentować inteligentne kontrakty lub konta zewnętrzne (użytkowników).
+ // `address` jest porównywalny z adresem e-mail – służy do identyfikacji konta na Ethereum.
+ // Adresy mogą reprezentować inteligentny kontrakt lub konta zewnętrzne (użytkowników).
// Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/types.html#address
address public owner;
- // Mapowanie jest zasadniczo strukturą danych o postaci tablicy skrótów.
- // To mapowanie przypisuje niepodpisaną liczbę całkowitą (saldo tokena) do adresu (posiadacza tokenu).
+ // `mapping` to w zasadzie struktura danych typu tablica haszująca.
+ // Ten `mapping` przypisuje nieujemną liczbę całkowitą (saldo tokenu) do adresu (posiadacza tokenu).
// Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/types.html#mapping-types
- mapowanie (adres => uint) publiczne saldo;
+ mapping (address => uint) public balances;
- // Wydarzenia pozwalają na rejestrowanie aktywności w blockchain.
- // Klienci Ethereum mogą słuchać zdarzeń, aby reagować na zmiany stanu kontraktu.
- // Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/contracty. tml#events
- Transferu zdarzeń (adres od, adres do kwoty uint);
+ // Zdarzenia umożliwiają rejestrowanie aktywności na blockchainie.
+ // Klienci Ethereum mogą nasłuchiwać zdarzeń, aby reagować na zmiany stanu kontraktu.
+ // Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#events
+ event Transfer(address from, address to, uint amount);
- // inicjuje dane umowy, ustawienie `właściciela`
+ // Inicjalizuje dane kontraktu, ustawiając `owner`
// na adres twórcy kontraktu.
constructor() public {
- // Wszystkie inteligentne kontrakty opierają się na transakcjach zewnętrznych, aby wyzwolić swoje funkcje.
- // `msg` to zmienna globalna zawierająca odpowiednie dane dotyczące danej transakcji,
- // takie jak adres nadawcy i wartość ETH zawarta w transakcji.
+ // Wszystkie inteligentne kontrakty opierają się na zewnętrznych transakcjach, aby uruchomić swoje funkcje.
+ // `msg` to globalna zmienna, która zawiera istotne dane dotyczące danej transakcji,
+ // takie jak adres nadawcy i wartość ETH zawarta w transakcji.
// Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties
owner = msg.sender;
}
- // Tworzy liczbę nowych tokenów i wysyła je na adres.
+ // Tworzy określoną liczbę nowych tokenów i wysyła je na dany adres.
function mint(address receiver, uint amount) public {
- // `require` jest strukturą kontroli używaną do wymuszania pewnych warunków.
- // Jeśli wyrażenie `require` oceni na `false`, wyzwalany jest wyjątek,
- // który cofa wszystkie zmiany w stanie podczas bieżącego wywołąnia.
- // Więcej informacji: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions
+ // `require` to struktura kontrolna używana do wymuszania określonych warunków.
+ // Jeśli wyrażenie `require` zwróci wartość `false`, wyzwalany jest wyjątek,
+ // który cofa wszystkie zmiany stanu dokonane podczas bieżącego wywołania.
+ // Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions
// Tylko właściciel kontraktu może wywołać tę funkcję
- require(msg.sender == owner, "You are not the owner.");
+ require(msg.sender == owner, "Nie jesteś właścicielem.");
- // Wymusza maksymalną kwotę tokenów
- require(amount < 1e60, "Maximum issuance exceeded");
+ // Wymusza maksymalną liczbę tokenów
+ require(amount < 1e60, "Przekroczono maksymalną emisję");
// Zwiększa saldo `receiver` o `amount`
balances[receiver] += amount;
}
- // Wysyła kwotę istniejących tokenów od dowolnego wywołującego na adres.
+ // Wysyła określoną liczbę istniejących tokenów od dowolnego wywołującego na dany adres.
function transfer(address receiver, uint amount) public {
- // Nadawca musi mieć wystarczającą ilość tokenów, aby wysłać
- require(amount <= balances[msg.sender], "Insufficient balance.");
+ // Nadawca musi mieć wystarczającą liczbę tokenów do wysłania
+ require(amount <= balances[msg.sender], "Niewystarczające saldo.");
- // Dostosowuje salda tokenów z dwóch adresów
+ // Dostosowuje salda tokenów obu adresów
balances[msg.sender] -= amount;
balances[receiver] += amount;
- // Emituje wydarzenie zdefiniowane wcześniej
+ // Emituje zdarzenie zdefiniowane wcześniej
emit Transfer(msg.sender, receiver, amount);
}
}
```
-### Unikalne zasoby cyfrowe {#unique-digital-asset}
+### Unikalny zasób cyfrowy {#unique-digital-asset}
```solidity
pragma solidity ^0.5.10;
-// Imports symbols from other files into the current contract.
-// In this case, a series of helper contracts from OpenZeppelin.
-
-
-// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files
+// Importuje symbole z innych plików do bieżącego kontraktu.
+// W tym przypadku jest to seria kontraktów pomocniczych z OpenZeppelin.
+// Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files
import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721.sol";
import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol";
import "../node_modules/@openzeppelin/contracts/introspection/ERC165.sol";
import "../node_modules/@openzeppelin/contracts/math/SafeMath.sol";
-// The `is` keyword is used to inherit functions and keywords from external contracts.
-// In this case, `CryptoPizza` inherits from the `IERC721` and `ERC165` contracts.
-
-
-// Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance
+// Słowo kluczowe `is` służy do dziedziczenia funkcji i słów kluczowych z kontraktów zewnętrznych.
+// W tym przypadku `CryptoPizza` dziedziczy po kontraktach `IERC721` i `ERC165`.
+// Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance
contract CryptoPizza is IERC721, ERC165 {
- // Uses OpenZeppelin's SafeMath library to perform arithmetic operations safely.
- // Learn more: https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath
+ // Używa biblioteki SafeMath z OpenZeppelin do bezpiecznego wykonywania operacji arytmetycznych.
+ // Dowiedz się więcej: https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath
using SafeMath for uint256;
- // Constant state variables in Solidity are similar to other languages
- // but you must assign from an expression which is constant at compile time.
-
-
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables
+ // Stałe zmienne stanu w Solidity są podobne do tych w innych językach,
+ // ale musisz przypisać im wartość z wyrażenia, które jest stałe w czasie kompilacji.
+ // Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables
uint256 constant dnaDigits = 10;
uint256 constant dnaModulus = 10 ** dnaDigits;
bytes4 private constant _ERC721_RECEIVED = 0x150b7a02;
- // Struct types let you define your own type
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs
+ // Typy `struct` pozwalają definiować własne typy
+ // Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs
struct Pizza {
string name;
uint256 dna;
}
- // Creates an empty array of Pizza structs
+ // Tworzy pustą tablicę struktur Pizza
Pizza[] public pizzas;
- // Mapping from pizza ID to its owner's address
+ // Mapowanie z ID pizzy na adres jej właściciela
mapping(uint256 => address) public pizzaToOwner;
- // Mapping from owner's address to number of owned token
+ // Mapowanie z adresu właściciela na liczbę posiadanych tokenów
mapping(address => uint256) public ownerPizzaCount;
- // Mapping from token ID to approved address
+ // Mapowanie z ID tokenu na zatwierdzony adres
mapping(uint256 => address) pizzaApprovals;
- // You can nest mappings, this example maps owner to operator approvals
+ // Możesz zagnieżdżać mapowania, ten przykład mapuje właściciela na zatwierdzenia operatora
mapping(address => mapping(address => bool)) private operatorApprovals;
- // Internal function to create a random Pizza from string (name) and DNA
+ // Wewnętrzna funkcja do tworzenia losowej Pizzy z ciągu znaków (nazwa) i DNA
function _createPizza(string memory _name, uint256 _dna)
- // The `internal` keyword means this function is only visible
- // within this contract and contracts that derive this contract
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters
+ // Słowo kluczowe `internal` oznacza, że ta funkcja jest widoczna tylko
+ // w obrębie tego kontraktu i kontraktów, które z niego dziedziczą
+ // Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters
internal
- // `isUnique` is a function modifier that checks if the pizza already exists
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers
+ // `isUnique` to modyfikator funkcji, który sprawdza, czy pizza już istnieje
+ // Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers
isUnique(_name, _dna)
{
- // Adds Pizza to array of Pizzas and get id
+ // Dodaje Pizzę do tablicy Pizz i pobiera id
uint256 id = SafeMath.sub(pizzas.push(Pizza(_name, _dna)), 1);
- // Checks that Pizza owner is the same as current user
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions
+ // Sprawdza, czy właściciel Pizzy jest taki sam jak bieżący użytkownik
+ // Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions
+
+ // zauważ, że address(0) to adres zerowy,
+ // co oznacza, że pizza[id] nie jest jeszcze przydzielona do konkretnego użytkownika.
+
assert(pizzaToOwner[id] == address(0));
- // Maps the Pizza to the owner
+ // Mapuje Pizzę na właściciela
pizzaToOwner[id] = msg.sender;
ownerPizzaCount[msg.sender] = SafeMath.add(
ownerPizzaCount[msg.sender],
@@ -391,38 +389,38 @@ contract CryptoPizza is IERC721, ERC165 {
);
}
- // Creates a random Pizza from string (name)
+ // Tworzy losową Pizzę z ciągu znaków (nazwa)
function createRandomPizza(string memory _name) public {
uint256 randDna = generateRandomDna(_name, msg.sender);
_createPizza(_name, randDna);
}
- // Generates random DNA from string (name) and address of the owner (creator)
+ // Generuje losowe DNA z ciągu znaków (nazwa) i adresu właściciela (twórcy)
function generateRandomDna(string memory _str, address _owner)
public
- // Functions marked as `pure` promise not to read from or modify the state
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions
+ // Funkcje oznaczone jako `pure` obiecują nie odczytywać ani nie modyfikować stanu
+ // Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions
pure
returns (uint256)
{
- // Generates random uint from string (name) + address (owner)
+ // Generuje losowy uint z ciągu znaków (nazwa) + adres (właściciel)
uint256 rand = uint256(keccak256(abi.encodePacked(_str))) +
uint256(_owner);
rand = rand % dnaModulus;
return rand;
}
- // Returns array of Pizzas found by owner
+ // Zwraca tablicę Pizz znalezionych przez właściciela
function getPizzasByOwner(address _owner)
public
- // Functions marked as `view` promise not to modify state
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions
+ // Funkcje oznaczone jako `view` obiecują nie modyfikować stanu
+ // Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions
view
returns (uint256[] memory)
{
- // Uses the `memory` storage location to store values only for the
- // lifecycle of this function call.
- // Learn more: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack
+ // Używa lokalizacji `memory` do przechowywania wartości tylko na czas
+ // trwania tego wywołania funkcji.
+ // Dowiedz się więcej: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack
uint256[] memory result = new uint256[](ownerPizzaCount[_owner]);
uint256 counter = 0;
for (uint256 i = 0; i < pizzas.length; i++) {
@@ -434,28 +432,28 @@ contract CryptoPizza is IERC721, ERC165 {
return result;
}
- // Transfers Pizza and ownership to other address
+ // Przenosi Pizzę i własność na inny adres
function transferFrom(address _from, address _to, uint256 _pizzaId) public {
- require(_from != address(0) && _to != address(0), "Invalid address.");
- require(_exists(_pizzaId), "Pizza does not exist.");
- require(_from != _to, "Cannot transfer to the same address.");
- require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved.");
+ require(_from != address(0) && _to != address(0), "Nieprawidłowy adres.");
+ require(_exists(_pizzaId), "Pizza nie istnieje.");
+ require(_from != _to, "Nie można przenieść na ten sam adres.");
+ require(_isApprovedOrOwner(msg.sender, _pizzaId), "Adres nie jest zatwierdzony.");
ownerPizzaCount[_to] = SafeMath.add(ownerPizzaCount[_to], 1);
ownerPizzaCount[_from] = SafeMath.sub(ownerPizzaCount[_from], 1);
pizzaToOwner[_pizzaId] = _to;
- // Emits event defined in the imported IERC721 contract
+ // Emituje zdarzenie zdefiniowane w zaimportowanym kontrakcie IERC721
emit Transfer(_from, _to, _pizzaId);
_clearApproval(_to, _pizzaId);
}
/**
- * Safely transfers the ownership of a given token ID to another address
- * If the target address is a contract, it must implement `onERC721Received`,
- * which is called upon a safe transfer, and return the magic value
+ * Bezpiecznie przenosi własność danego ID tokenu na inny adres
+ * Jeśli adres docelowy jest kontraktem, musi on implementować `onERC721Received`,
+ * która jest wywoływana podczas bezpiecznego transferu i zwraca magiczną wartość
* `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`;
- * otherwise, the transfer is reverted.
+ * w przeciwnym razie transfer jest cofany.
*/
function safeTransferFrom(address from, address to, uint256 pizzaId)
public
@@ -465,11 +463,11 @@ contract CryptoPizza is IERC721, ERC165 {
}
/**
- * Safely transfers the ownership of a given token ID to another address
- * If the target address is a contract, it must implement `onERC721Received`,
- * which is called upon a safe transfer, and return the magic value
+ * Bezpiecznie przenosi własność danego ID tokenu na inny adres
+ * Jeśli adres docelowy jest kontraktem, musi on implementować `onERC721Received`,
+ * która jest wywoływana podczas bezpiecznego transferu i zwraca magiczną wartość
* `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`;
- * otherwise, the transfer is reverted.
+ * w przeciwnym razie transfer jest cofany.
*/
function safeTransferFrom(
address from,
@@ -478,12 +476,12 @@ contract CryptoPizza is IERC721, ERC165 {
bytes memory _data
) public {
this.transferFrom(from, to, pizzaId);
- require(_checkOnERC721Received(from, to, pizzaId, _data), "Must implmement onERC721Received.");
+ require(_checkOnERC721Received(from, to, pizzaId, _data), "Należy zaimplementować onERC721Received.");
}
/**
- * Internal function to invoke `onERC721Received` on a target address
- * The call is not executed if the target address is not a contract
+ * Wewnętrzna funkcja do wywoływania `onERC721Received` na adresie docelowym
+ * Wywołanie nie jest wykonywane, jeśli adres docelowy nie jest kontraktem
*/
function _checkOnERC721Received(
address from,
@@ -504,13 +502,13 @@ contract CryptoPizza is IERC721, ERC165 {
return (retval == _ERC721_RECEIVED);
}
- // Burns a Pizza - destroys Token completely
- // The `external` function modifier means this function is
- // part of the contract interface and other contracts can call it
+ // Pali Pizzę - całkowicie niszczy Token
+ // Modyfikator funkcji `external` oznacza, że ta funkcja jest
+ // częścią interfejsu kontraktu i inne kontrakty mogą ją wywoływać
function burn(uint256 _pizzaId) external {
- require(msg.sender != address(0), "Invalid address.");
- require(_exists(_pizzaId), "Pizza does not exist.");
- require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved.");
+ require(msg.sender != address(0), "Nieprawidłowy adres.");
+ require(_exists(_pizzaId), "Pizza nie istnieje.");
+ require(_isApprovedOrOwner(msg.sender, _pizzaId), "Adres nie jest zatwierdzony.");
ownerPizzaCount[msg.sender] = SafeMath.sub(
ownerPizzaCount[msg.sender],
@@ -519,58 +517,58 @@ contract CryptoPizza is IERC721, ERC165 {
pizzaToOwner[_pizzaId] = address(0);
}
- // Returns count of Pizzas by address
+ // Zwraca liczbę Pizz według adresu
function balanceOf(address _owner) public view returns (uint256 _balance) {
return ownerPizzaCount[_owner];
}
- // Returns owner of the Pizza found by id
+ // Zwraca właściciela Pizzy znalezionego po id
function ownerOf(uint256 _pizzaId) public view returns (address _owner) {
address owner = pizzaToOwner[_pizzaId];
- require(owner != address(0), "Invalid Pizza ID.");
+ require(owner != address(0), "Nieprawidłowe ID Pizzy.");
return owner;
}
- // Approves other address to transfer ownership of Pizza
+ // Zatwierdza inny adres do przeniesienia własności Pizzy
function approve(address _to, uint256 _pizzaId) public {
- require(msg.sender == pizzaToOwner[_pizzaId], "Must be the Pizza owner.");
+ require(msg.sender == pizzaToOwner[_pizzaId], "Musisz być właścicielem Pizzy.");
pizzaApprovals[_pizzaId] = _to;
emit Approval(msg.sender, _to, _pizzaId);
}
- // Returns approved address for specific Pizza
+ // Zwraca zatwierdzony adres dla określonej Pizzy
function getApproved(uint256 _pizzaId)
public
view
returns (address operator)
{
- require(_exists(_pizzaId), "Pizza does not exist.");
+ require(_exists(_pizzaId), "Pizza nie istnieje.");
return pizzaApprovals[_pizzaId];
}
/**
- * Private function to clear current approval of a given token ID
- * Reverts if the given address is not indeed the owner of the token
+ * Prywatna funkcja do wyczyszczenia bieżącego zatwierdzenia dla danego ID tokenu
+ * Cofa, jeśli podany adres nie jest faktycznie właścicielem tokenu
*/
function _clearApproval(address owner, uint256 _pizzaId) private {
- require(pizzaToOwner[_pizzaId] == owner, "Must be pizza owner.");
- require(_exists(_pizzaId), "Pizza does not exist.");
+ require(pizzaToOwner[_pizzaId] == owner, "Musisz być właścicielem Pizzy.");
+ require(_exists(_pizzaId), "Pizza nie istnieje.");
if (pizzaApprovals[_pizzaId] != address(0)) {
pizzaApprovals[_pizzaId] = address(0);
}
}
/*
- * Sets or unsets the approval of a given operator
- * An operator is allowed to transfer all tokens of the sender on their behalf
+ * Ustawia lub usuwa zatwierdzenie dla danego operatora
+ * Operator może w imieniu nadawcy przenieść wszystkie jego tokeny
*/
function setApprovalForAll(address to, bool approved) public {
- require(to != msg.sender, "Cannot approve own address");
+ require(to != msg.sender, "Nie można zatwierdzić własnego adresu");
operatorApprovals[msg.sender][to] = approved;
emit ApprovalForAll(msg.sender, to, approved);
}
- // Tells whether an operator is approved by a given owner
+ // Informuje, czy operator jest zatwierdzony przez danego właściciela
function isApprovedForAll(address owner, address operator)
public
view
@@ -579,20 +577,20 @@ contract CryptoPizza is IERC721, ERC165 {
return operatorApprovals[owner][operator];
}
- // Takes ownership of Pizza - only for approved users
+ // Przejmuje własność Pizzy - tylko dla zatwierdzonych użytkowników
function takeOwnership(uint256 _pizzaId) public {
- require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved.");
+ require(_isApprovedOrOwner(msg.sender, _pizzaId), "Adres nie jest zatwierdzony.");
address owner = this.ownerOf(_pizzaId);
this.transferFrom(owner, msg.sender, _pizzaId);
}
- // Checks if Pizza exists
+ // Sprawdza, czy Pizza istnieje
function _exists(uint256 pizzaId) internal view returns (bool) {
address owner = pizzaToOwner[pizzaId];
return owner != address(0);
}
- // Checks if address is owner or is approved to transfer Pizza
+ // Sprawdza, czy adres jest właścicielem lub jest zatwierdzony do przeniesienia Pizzy
function _isApprovedOrOwner(address spender, uint256 pizzaId)
internal
view
@@ -607,7 +605,7 @@ contract CryptoPizza is IERC721, ERC165 {
this.isApprovedForAll(owner, spender));
}
- // Check if Pizza is unique and doesn't exist yet
+ // Sprawdź, czy Pizza jest unikalna i jeszcze nie istnieje
modifier isUnique(string memory _name, uint256 _dna) {
bool result = true;
for (uint256 i = 0; i < pizzas.length; i++) {
@@ -619,21 +617,19 @@ contract CryptoPizza is IERC721, ERC165 {
result = false;
}
}
- require(result, "Pizza with such name already exists.");
+ require(result, "Pizza o takiej nazwie już istnieje.");
_;
}
- // Returns whether the target address is a contract
+ // Zwraca informację, czy adres docelowy jest kontraktem
function isContract(address account) internal view returns (bool) {
uint256 size;
- // Currently there is no better way to check if there is a contract in an address
- // than to check the size of the code at that address.
- // See https://ethereum.stackexchange.com/a/14016/36603
- // for more details about how this works.
- // TODO Check this again before the Serenity release, because all addresses will be
- // contracts then.
-
-
+ // Obecnie nie ma lepszego sposobu na sprawdzenie, czy pod danym adresem znajduje się kontrakt,
+ // niż sprawdzenie rozmiaru kodu pod tym adresem.
+ // Zobacz https://ethereum.stackexchange.com/a/14016/36603
+ // aby uzyskać więcej szczegółów na temat działania.
+ // TODO Sprawdź to ponownie przed wydaniem Serenity, ponieważ wtedy wszystkie adresy będą
+ // kontraktami.
// solium-disable-next-line security/no-inline-assembly
assembly {
size := extcodesize(account)
@@ -643,20 +639,20 @@ contract CryptoPizza is IERC721, ERC165 {
}
```
-## Dodatkowo przeczytaj {#further-reading}
+## Dalsza lektura {#further-reading}
Sprawdź dokumentację Solidity i Vyper, aby uzyskać pełniejszy przegląd inteligentnych kontraktów:
-- [Solidity](https://solidity.readthedocs.io/)
-- [Vyper](https://vyper.readthedocs.io/)
+- [Solidity](https://docs.soliditylang.org/)
+- [Vyper](https://docs.vyperlang.org/en/stable/)
## Powiązane tematy {#related-topics}
- [Inteligentne kontrakty](/developers/docs/smart-contracts/)
-- [Maszyna Wirtualna Ethereum](/developers/docs/evm/)
+- [Wirtualna Maszyna Ethereum](/developers/docs/evm/)
## Powiązane samouczki {#related-tutorials}
-- [Zmniejszenie kontraktów w celu walki z limitem wielkości kontraktu](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _ – kilka praktycznych wskazówek, jak zmniejszyć rozmiar inteligentnego kontraktu._
-- [Rejestrowanie danych z inteligentnych kontraktów za pomocą zdarzeń](/developers/tutorials/logging-events-smart-contracts/) _– wprowadzenie do zdarzeń inteligentnych kontraktów i jak możesz ich używać do rejestrowania danych._
-- [Interakcja z innymi umowami z Solidity](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– jak wdrożyć inteligentny kontrakt z istniejącego kontraktu i wchodzić z nim w interakcje._
+- [Zmniejszanie kontraktów w celu obejścia limitu rozmiaru kontraktu](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– kilka praktycznych wskazówek dotyczących zmniejszania rozmiaru Twojego inteligentnego kontraktu._
+- [Rejestrowanie danych z inteligentnych kontraktów za pomocą zdarzeń](/developers/tutorials/logging-events-smart-contracts/) _– wprowadzenie do zdarzeń inteligentnych kontraktów i sposobu ich wykorzystania do rejestrowania danych._
+- [Interakcja z innymi kontraktami z poziomu Solidity](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– jak wdrożyć inteligentny kontrakt z istniejącego kontraktu i wejść z nim w interakcję._
diff --git a/public/content/translations/pl/developers/docs/smart-contracts/compiling/index.md b/public/content/translations/pl/developers/docs/smart-contracts/compiling/index.md
index cd253da8941..a95a9936214 100644
--- a/public/content/translations/pl/developers/docs/smart-contracts/compiling/index.md
+++ b/public/content/translations/pl/developers/docs/smart-contracts/compiling/index.md
@@ -1,26 +1,26 @@
---
-title: Kompilowanie inteligentnych kontraktów
-description: Wyjaśnienie, dlaczego należy skompilować inteligentne kontrakty i co faktycznie robi kompilacja.
+title: "Kompilowanie inteligentnych kontraktów"
+description: "Wyjaśnienie, dlaczego należy skompilować inteligentne kontrakty i co faktycznie robi kompilacja."
lang: pl
incomplete: true
---
Musisz skompilować swój kontrakt, aby aplikacja internetowa i maszyna wirtualna Ethereum (EVM) mogły ją „zrozumieć”.
-## Warunki wstępne {#prerequisites}
+## Wymagania wstępne {#prerequisites}
-Przed zapoznaniem się z informacjami o kompilacji pomocny może być nasz artykuł o [inteligentnych kontraktach](/developers/docs/smart-contracts/) i [Maszynie Wirtualnej Ethereum (EVM)](/developers/docs/evm/).
+Przed przeczytaniem o kompilacji, pomocne może okazać się zapoznanie z naszym wprowadzeniem do [inteligentnych kontraktów](/developers/docs/smart-contracts/) i [Wirtualnej Maszyny Ethereum](/developers/docs/evm/).
-## Maszyna Wirtualna Ethereum (EVM) {#the-evm}
+## EVM {#the-evm}
-Aby [EVM](/developers/docs/evm/) mogła uruchomić kontrakt, musi on być zapisany jako **kod bajtowy**. Kompilacja zamienia to:
+Aby [EVM](/developers/docs/evm/) mogła uruchomić Twój kontrakt, musi on być w postaci **kodu bajtowego**. Kompilacja zamienia to:
```solidity
pragma solidity 0.4.24;
contract Greeter {
- function greet() public constant returns (string) {
+ function greet() public view returns (string memory) {
return "Hello";
}
@@ -33,13 +33,17 @@ contract Greeter {
PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x4 CALLDATASIZE LT PUSH2 0x41 JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0xCFAE3217 EQ PUSH2 0x46 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST CALLVALUE DUP1 ISZERO PUSH2 0x52 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH2 0x5B PUSH2 0xD6 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP4 DUP2 DUP2 MLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP1 DUP4 DUP4 PUSH1 0x0 JUMPDEST DUP4 DUP2 LT ISZERO PUSH2 0x9B JUMPI DUP1 DUP3 ADD MLOAD DUP2 DUP5 ADD MSTORE PUSH1 0x20 DUP2 ADD SWAP1 POP PUSH2 0x80 JUMP JUMPDEST POP POP POP POP SWAP1 POP SWAP1 DUP2 ADD SWAP1 PUSH1 0x1F AND DUP1 ISZERO PUSH2 0xC8 JUMPI DUP1 DUP3 SUB DUP1 MLOAD PUSH1 0x1 DUP4 PUSH1 0x20 SUB PUSH2 0x100 EXP SUB NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP JUMPDEST POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x60 PUSH1 0x40 DUP1 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 PUSH1 0x5 DUP2 MSTORE PUSH1 0x20 ADD PUSH32 0x48656C6C6F000000000000000000000000000000000000000000000000000000 DUP2 MSTORE POP SWAP1 POP SWAP1 JUMP STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 SLT 0xec 0xe 0xf5 0xf8 SLT 0xc7 0x2d STATICCALL ADDRESS SHR 0xdb COINBASE 0xb1 BALANCE 0xe8 0xf8 DUP14 0xda 0xad DUP13 LOG1 0x4c 0xb4 0x26 0xc2 DELEGATECALL PUSH7 0x8994D3E002900
```
-## Aplikacje webowe {#web-applications}
+Są to tak zwane **kody operacyjne**. Kody operacyjne EVM są niskopoziomowymi instrukcjami, które może wykonać Wirtualna Maszyn Ethereum (EVM). Każdy kod operacyjny reprezentuje konkretne działanie, na przykład działania arytmetyczne, działania logiczne, manipulacje danymi, kontrolę przepływu itp.
-Kompilator zwróci również **interfejs binarny aplikacji (ABI)**, którego potrzebujesz, aby aplikacja zrozumiała kontrakt i wywołała jego funkcje.
+[Więcej o kodach operacyjnych](/developers/docs/evm/opcodes/)
+
+## Aplikacje internetowe {#web-applications}
+
+Kompilator zwróci również **binarny interfejs aplikacji (ABI)**, którego potrzebujesz, aby Twoja aplikacja zrozumiała kontrakt i wywołała jego funkcje.
ABI jest plikiem JSON, który opisuje wdrożony kontrakt i jego funkcje inteligentnego kontraktu. Pomaga to zmniejszyć różnicę pomiędzy web2 a web3
-[Biblioteka klienta JavaScript](/developers/docs/apis/javascript/) odczyta **ABI** w celu wywołania inteligentnego kontraktu w interfejsie aplikacji internetowej.
+[Biblioteka klienta JavaScript](/developers/docs/apis/javascript/) odczyta **ABI**, aby umożliwić Ci wywołanie Twojego inteligentnego kontraktu w interfejsie Twojej aplikacji internetowej.
Poniżej znajduje się ABI dla kontraktu z tokenem ERC-20. ERC-20 to token, który możesz wymieniać na Ethereum.
@@ -270,9 +274,9 @@ Poniżej znajduje się ABI dla kontraktu z tokenem ERC-20. ERC-20 to token, któ
## Dalsza lektura {#further-reading}
-- [Specyfikacja ABI](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html) _— Solidity_
+- [Specyfikacja ABI](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html) _– Solidity_
## Powiązane tematy {#related-topics}
-- [Biblioteki JavaScript](/developers/docs/apis/javascript/)
-- [Maszyna Wirtualna Ethereum](/developers/docs/evm/)
+- [Biblioteki klienta JavaScript](/developers/docs/apis/javascript/)
+- [Wirtualna Maszyna Ethereum](/developers/docs/evm/)
diff --git a/public/content/translations/pl/developers/docs/smart-contracts/composability/index.md b/public/content/translations/pl/developers/docs/smart-contracts/composability/index.md
index 3f44005d86f..64b33307cd8 100644
--- a/public/content/translations/pl/developers/docs/smart-contracts/composability/index.md
+++ b/public/content/translations/pl/developers/docs/smart-contracts/composability/index.md
@@ -1,19 +1,76 @@
---
-title: Kompozycyjność kontraktów inteligentnych
-description:
+title: "Kompozycyjność kontraktów inteligentnych"
+description: "Dowiedz się, w jaki sposób inteligentne kontrakty można łączyć niczym klocki Lego, aby tworzyć złożone aplikacje zdecentralizowane (dapps) poprzez ponowne wykorzystywanie istniejących komponentów."
lang: pl
incomplete: true
---
## Krótkie wprowadzenie {#a-brief-introduction}
-Inteligentne kontrakty są publiczne w Ethereum i można je uznać za otwarte API. Nie musisz pisać własnego inteligentnego kontraktu, aby zostać programistą aplikacji dapp, po prostu musisz wiedzieć, jak się nim posługiwać. Na przykład możesz użyć istniejących inteligentnych kontraktów [Uniswap](https://uniswap.exchange/swap), zdecentralizowanej giełdy, aby obsłużyć całą logikę wymiany tokenów w swojej aplikacji – nie nie trzeba zaczynać od zera. [Sprawdź niektóre z ich kontraktów](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts).
+Inteligentne kontrakty są publiczne w Ethereum i można je uznać za otwarte API. Nie musisz pisać własnego inteligentnego kontraktu, aby zostać programistą aplikacji dapp, po prostu musisz wiedzieć, jak się nim posługiwać. Na przykład możesz użyć istniejących inteligentnych kontraktów [Uniswap](https://uniswap.exchange/swap), zdecentralizowanej giełdy, aby obsłużyć całą logikę wymiany tokenów w swojej aplikacji – nie musisz zaczynać od zera. Sprawdź niektóre z ich kontraktów [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) i [v3](https://github.com/Uniswap/uniswap-v3-core/tree/main/contracts).
+
+## Czym jest łatwość łączenia się w większe struktury? {#what-is-composability}
+
+Łatwość łączenia się w większe struktury to łączenie osobnych komponentów w celu stworzenia nowych systemów i rezultatów. W dziedzinie tworzenia oprogramowania, łatwość łączenia się w większe struktury oznacza, że programista może ponownie użyć istniejących komponentów oprogramowania, aby zbudować nową aplikację. Dobrym sposobem na zrozumienie łatwości łączenia się w większe struktury jest wyobrażenie sobie elementów możliwych do połączenia jako klocków lego. Każdy klocek lego może być połączony z innym, pozwalając na budowanie złożonych struktur poprzez łączenie różnych klocków lego.
+
+W Ethereum każdy inteligentny kontrakt jest jak taki klocek lego — możesz użyć inteligentnego kontraktu z innego projektu, jako klocków do swojego projektu. To oznacza, że nie musisz poświęcać czasu na ponowne wynajdywanie koła i ciągłe rozpoczynanie od nowa.
+
+## Jak działa łatwość łączenia się w większe struktury? {#how-does-composability-work}
+
+Inteligentne kontrakty Ethereum są jak publiczne interfejsy API, więc każdy może wchodzić z nimi w interakcję lub zintegrować je ze swoją dapką, aby rozszerzyć jej funkcjonalność. Łatwość łączenia w większe struktury inteligentnych kontraktów jest oparta na trzech zasadach: modularności, autonomii oraz wykrywalności:
+
+**1. Modularność**: jest to umiejętność poszczególnych komponentów do wykonywania określonych zadań. W Ethereum każdy inteligentny kontrakt ma określone zastosowanie (jak w przykładzie Uniswap).
+
+**2. Autonomia**: Komponowalne komponenty muszą mieć możliwość niezależnego działania. Każdy inteligentny kontrakt Ethereum jest samorealizujący i może działać bez konieczności polegania na innych częściach systemu.
+
+**3. Wykrywalność**: Programiści nie mogą wywoływać zewnętrznych kontraktów ani integrować bibliotek oprogramowania w aplikacjach, jeśli te pierwsze nie są publicznie dostępne. Inteligentne kontrakty są z założenia otwarte; każdy może wywołać inteligentny kontrakt lub rozwidlić bazę kodu.
+
+## Korzyści z kompozycyjności {#benefits-of-composability}
+
+### Krótszy cykl deweloperski {#shorter-development-cycle}
+
+Kompozycyjność zmniejsza ilość pracy, którą programiści muszą wykonać podczas tworzenia [dapek](/apps/#what-are-dapps). [Jak ujął to Naval Ravikant:](https://twitter.com/naval/status/1444366754650656770) "Otwarte oprogramowanie oznacza, że każdy problem musi zostać rozwiązany tylko raz."
+
+Jeśli jest taki inteligentny kontrakt, który rozwiązuje jeden problem, to inni programiści mogą użyć go ponownie, aby nie musieć rozwiązywać tego samego problemu. Tym sposobem programiście mogą wziąć istniejące biblioteki i rozszerzyć je o dodatkowe funkcje, aby tworzyć nowe dapki.
+
+### Większa innowacyjność {#greater-innovation}
+
+Łatwa możliwość łączenia w większe struktury stwarza warunki do innowacji oraz eksperymentowania, ponieważ programiści mogą dowolnie używać, modyfikować, duplikować i integrować kod open-source, aby tworzyć oczekiwane rezultaty. W wyniku tego zespoły programistyczne poświęcają mniej czasu na podstawowe funkcje i mogą przeznaczyć go na eksperymentowanie z nowymi możliwościami.
+
+### Lepsze wrażenia użytkownika {#better-user-experience}
+
+Współpraca pomiędzy komponentami ekosystemu Ethereum poprawia doświadczenie użytkownika. Użytkownicy mają dostęp do większej liczby funkcji, kiedy dapki integrują zewnętrzne inteligentne kontrakty niż w rozdrobnionym ekosystemie, którego aplikacje nie mogą się ze sobą komunikować.
+
+Posłużymy się przykładem z arbitrażu handlowego, aby zilustrować korzyści tej współpracy:
+
+Jeśli token ma wyższą cenę na `exchange A` niż na `exchange B`, możesz wykorzystać różnicę w cenie, aby osiągnąć zysk. Możesz to jednak zrobić tylko wtedy, gdy masz wystarczająco dużo kapitału, aby sfinansować transakcję (tzn. kupić token na `exchange B` i sprzedać go na `exchange A`).
+
+W przypadku, kiedy nie posiadasz wystarczających środków, aby sfinansować tę transakcję, może ci się przydać błyskawiczna pożyczka. [Błyskawiczne pożyczki](/defi/#flash-loans) są wysoce techniczne, ale podstawowa idea polega na tym, że można pożyczyć aktywa (bez zabezpieczenia) i zwrócić je w ramach _jednej_ transakcji.
+
+Wracając do naszego pierwotnego przykładu, trader arbitrażowy może wziąć dużą pożyczkę błyskawiczną, kupić tokeny na `exchange B`, sprzedać je na `exchange A`, spłacić kapitał + odsetki i zatrzymać zysk, a wszystko to w ramach tej samej transakcji. Ta skomplikowana logika wymaga połączenia wywołań wielu kontraktów, co nie byłoby możliwe, gdyby nie istniała współpraca pomiędzy inteligentnymi kontraktami.
+
+## Przykłady kompozycyjności w Ethereum {#composability-in-ethereum}
+
+### Wymiana tokenów {#token-swaps}
+
+Jeśli stworzysz dapkę, która wymaga, aby transakcje były opłacone za pomocą ETH, możesz pozwolić użytkownikom płacić innymi tokenami ERC-20 poprzez zintegrowanie logiki wymiany tokenów. Kod automatycznie skonwertuje token użytkownika do ETH, zanim kontrakt wykona wywołaną funkcję.
+
+### Zarządzanie {#governance}
+
+Tworzenie dedykowanych systemów zarządzania dla [DAO](/dao/) może być drogie i czasochłonne. Zamiast tego możesz użyć zestawu narzędzi open-source do zarządzania, takiego jak [Aragon Client](https://client.aragon.org/), aby uruchomić swoje DAO i szybko utworzyć ramy zarządzania.
+
+### Zarządzanie tożsamością {#identity-management}
+
+Zamiast budować niestandardowy system uwierzytelniania lub opierać się na scentralizowanych dostawcach, można zintegrować narzędzia zdecentralizowanej tożsamości (DID), aby obsługiwać uwierzytelnianie dla użytkowników. Przykładem jest [SpruceID](https://www.spruceid.com/), zestaw narzędzi open-source, który oferuje funkcję "Zaloguj się za pomocą Ethereum", która pozwala użytkownikom uwierzytelniać tożsamość za pomocą portfela Ethereum.
## Powiązane samouczki {#related-tutorials}
-- [Kompozycyjność kontraktu: elementy konstrukcyjne inteligentnych kontraktów Ethereum](https://medium.com/decentlabs/contract-composability-the-building-blocks-of-ethereum-smart-contract-development-bdf3219ffeb9/)
-- [Szybkie rozpoczęcie tworzenia frontendu aplikacji dapp za pomocą create-eth-app](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/) _— omówienie korzystania z create-eth-app do tworzenia aplikacji z zastosowaniem popularnych inteligentnych kontraktów._
+- [Rozpocznij tworzenie frontendu dapki za pomocą create-eth-app](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/) _– Omówienie, jak używać create-eth-app do tworzenia aplikacji z popularnymi, gotowymi inteligentnymi kontraktami._
## Dalsza lektura {#further-reading}
-_Znasz jakieś zasoby społeczności, które Ci pomogły? Wyedytuj tę stronę i dodaj je!_
+_Znasz jakieś zasoby społeczności, które Ci pomogły? Edytuj tę stronę i dodaj je!_
+
+- [Kompozycyjność to innowacja](https://a16zcrypto.com/posts/article/how-composability-unlocks-crypto-and-everything-else/)
+- [Dlaczego kompozycyjność ma znaczenie dla Web3](https://hackernoon.com/why-composability-matters-for-web3)
+- [Czym jest kompozycyjność?](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.)
diff --git a/public/content/translations/pl/developers/docs/smart-contracts/deploying/index.md b/public/content/translations/pl/developers/docs/smart-contracts/deploying/index.md
index 6e650b8ca85..65736ef7d71 100644
--- a/public/content/translations/pl/developers/docs/smart-contracts/deploying/index.md
+++ b/public/content/translations/pl/developers/docs/smart-contracts/deploying/index.md
@@ -1,57 +1,81 @@
---
-title: Wdrażanie inteligentnych kontraktów
-description:
+title: "Wdrażanie inteligentnych kontraktów"
+description: "Dowiedz się, jak wdrażać inteligentne kontrakty w sieciach Ethereum, w tym jakie są wymagania wstępne, narzędzia i etapy wdrażania."
lang: pl
-incomplete: true
---
-Musisz wdrożyć inteligentny kontrakt, aby był dostępny dla użytkowników sieci Ethereum.
+Musisz wdrożyć swój inteligentny kontrakt, aby był dostępny dla użytkowników sieci Ethereum.
-Aby wdrożyć inteligentny kontrakt, wysyłasz jedynie transakcję Ethereum zawierającą kod skompilowanego inteligentnego kontraktu bez wskazania odbiorców.
+Aby wdrożyć inteligentny kontrakt, wystarczy wysłać transakcję Ethereum zawierającą skompilowany kod inteligentnego kontraktu bez określania żadnego odbiorcy.
-## Warunki wstępne {#prerequisites}
+## Wymagania wstępne {#prerequisites}
-Powinieneś znać [sieci Ethereum](/developers/docs/networks/), [transakcje](/developers/docs/transactions/) i [anatomię inteligentnych kontraktów](/developers/docs/smart-contracts/anatomy/) przed wdrożeniem inteligentnych kontraktów.
+Przed wdrożeniem inteligentnych kontraktów powinieneś zrozumieć [sieci Ethereum](/developers/docs/networks/), [transakcje](/developers/docs/transactions/) i [anatomię inteligentnych kontraktów](/developers/docs/smart-contracts/anatomy/).
-Wdrożenie kontraktu również kosztuje ETH, więc trzeba się orientować w kwestiach związanych z [gazem i opłatami](/developers/docs/gas/) w Ethereum.
+Wdrożenie kontraktu kosztuje również ether (ETH), ponieważ jest on przechowywany na blockchainie, więc powinieneś zapoznać się z [gazem i opłatami](/developers/docs/gas/) w Ethereum.
-Na koniec musisz skompilować kontrakt przed wdrożeniem, więc upewnij się, że przeczytałeś o [kompilowaniu inteligentnych kontraktów](/developers/docs/smart-contracts/compiling/).
+Na koniec, przed wdrożeniem, musisz skompilować swój kontrakt, więc upewnij się, że przeczytałeś o [kompilowaniu inteligentnych kontraktów](/developers/docs/smart-contracts/compiling/).
-## Jak wdrożyć inteligentny kontrakt
+## Jak wdrożyć inteligentny kontrakt {#how-to-deploy-a-smart-contract}
-Oznacza to, że będziesz musiał uiścić opłatę transakcyjną, więc upewnij się, że masz trochę ETH.
+### Czego będziesz potrzebować {#what-youll-need}
-### Potrzebne elementy {#what-youll-need}
+- Kod bajtowy twojego kontraktu – jest on generowany poprzez [kompilację](/developers/docs/smart-contracts/compiling/)
+- Ether za gaz – ustawisz swój limit gazu, podobnie jak inne transakcje, więc pamiętaj, że wdrożenie kontraktu wymaga znacznie więcej gazu niż zwykły transfer ETH.
+- Skrypt wdrażania lub wtyczka
+- dostęp do [węzła Ethereum](/developers/docs/nodes-and-clients/), uruchamiając własny, łącząc się z węzłem publicznym lub poprzez klucz API za pomocą [usługi węzła](/developers/docs/nodes-and-clients/nodes-as-a-service/)
-- Kod bajtowy Twojej umowy – jest generowany za pomocą [kompilacji](/developers/docs/smart-contracts/compiling/).
-- Ether za gaz – ustawisz swój limit gazu, podobnie jak inne transakcje, więc pamiętaj, że wdrożenie umowy wymaga znacznie więcej gazu niż zwykły transfer ETH.
-- Skrypt wdrażania lub wtyczka.
-- Dostęp do [węzła Ethereum](/developers/docs/nodes-and-clients/) — można go uzyskać, uruchamiając własny węzeł, łącząc się z węzłem publicznym lub za pośrednictwem klucza API przy użyciu usługi takiej jak Infura lub Alchemy
+### Kroki wdrażania inteligentnego kontraktu {#steps-to-deploy}
-Po wdrożeniu Twój kontrakt będzie miał adres Ethereum, podobnie jak inne [konta](/developers/docs/accounts/).
+Konkretne kroki będą zależeć od danego środowiska programistycznego. Możesz na przykład sprawdzić [dokumentację Hardhat na temat wdrażania kontraktów](https://hardhat.org/docs/tutorial/deploying) lub [dokumentację Foundry na temat wdrażania i weryfikacji inteligentnych kontraktów](https://book.getfoundry.sh/forge/deploying). Po wdrożeniu Twój kontrakt będzie miał adres Ethereum, tak jak inne [konta](/developers/docs/accounts/), i będzie można go zweryfikować za pomocą [narzędzi do weryfikacji kodu źródłowego](/developers/docs/smart-contracts/verifying/#source-code-verification-tools).
## Powiązane narzędzia {#related-tools}
-**Remix —** **_Remix IDE umożliwia opracowywanie inteligentnych kontraktów dla Ethereum, takich jak blockchain, ich wdrażanie i administrowanie nimi._**
+**Remix – _Remix IDE pozwala na tworzenie, wdrażanie i administrowanie inteligentnymi kontraktami dla blockchainów podobnych do Ethereum_**
- [Remix](https://remix.ethereum.org)
-**Tenderly —** **_platforma do łatwego monitorowania Twoich inteligentnych kontraktów ze śledzeniem błędów, alertami, wskaźniki wydajności i szczegółowymi analizami kontraktu._**
+**Tenderly – _platforma deweloperska Web3, która zapewnia debugowanie, obserwowalność i elementy składowe infrastruktury do tworzenia, testowania, monitorowania i obsługi inteligentnych kontraktów_**
- [tenderly.co](https://tenderly.co/)
+- [Dokumentacja](https://docs.tenderly.co/)
- [GitHub](https://github.com/Tenderly)
- [Discord](https://discord.gg/eCWjuvt)
+**Hardhat – _środowisko programistyczne do kompilowania, wdrażania, testowania i debugowania oprogramowania Ethereum_**
+
+- [hardhat.org](https://hardhat.org/getting-started/)
+- [Dokumentacja dotycząca wdrażania kontraktów](https://hardhat.org/docs/tutorial/deploying)
+- [GitHub](https://github.com/nomiclabs/hardhat)
+- [Discord](https://discord.com/invite/TETZs2KK4k)
+
+**thirdweb – _Łatwe wdrażanie dowolnego kontraktu w dowolnym łańcuchu kompatybilnym z EVM za pomocą jednego polecenia_**
+
+- [Dokumentacja](https://portal.thirdweb.com/deploy/)
+
+**Crossmint – _platforma programistyczna web3 klasy korporacyjnej do wdrażania inteligentnych kontraktów, umożliwiania płatności kartą kredytową i płatności międzyłańcuchowych oraz wykorzystywania interfejsów API do tworzenia, dystrybucji, sprzedaży, przechowywania i edytowania NFT._**
+
+- [crossmint.com](https://www.crossmint.com)
+- [Dokumentacja](https://docs.crossmint.com)
+- [Discord](https://discord.com/invite/crossmint)
+- [Blog](https://blog.crossmint.com)
+
## Powiązane samouczki {#related-tutorials}
- [Wdrażanie pierwszego inteligentnego kontraktu](/developers/tutorials/deploying-your-first-smart-contract/) _– wprowadzenie do wdrażania pierwszego inteligentnego kontraktu w sieci testowej Ethereum._
-- [Korzystanie z innych kontraktów pisanych w języku Solidity](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– jak wdrożyć inteligentny kontrakt na podstawie istniejącego kontraktu i zastosować go._
-- [Jak zmniejszyć rozmiar kontraktu](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _— jak zmniejszyć rozmiar kontraktu, aby utrzymać go poniżej limitu i zaoszczędzić na gazie_
+- [Witaj świecie | samouczek inteligentnych kontraktów](/developers/tutorials/hello-world-smart-contract/) _– łatwy do naśladowania samouczek tworzenia i wdrażania podstawowego inteligentnego kontraktu na Ethereum._
+- [Interakcja z innymi kontraktami z poziomu Solidity](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– jak wdrożyć inteligentny kontrakt z istniejącego kontraktu i wejść z nim w interakcję._
+- [Jak zmniejszyć rozmiar kontraktu](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– Jak zmniejszyć rozmiar kontraktu, aby utrzymać go poniżej limitu i zaoszczędzić na gazie_
## Dalsza lektura {#further-reading}
-_Znasz jakieś zasoby społeczności, które Ci pomogły? Wyedytuj tę stronę i dodaj je!_
+- [https://docs.openzeppelin.com/learn/deploying-and-interacting](https://docs.openzeppelin.com/learn/deploying-and-interacting) – _OpenZeppelin_
+- [Wdrażanie kontraktów za pomocą Hardhat](https://hardhat.org/docs/tutorial/deploying) – _Nomic Labs_
+
+_Znasz jakieś zasoby społeczności, które Ci pomogły? Edytuj tę stronę i dodaj je!_
-## Powiązane tematy
+## Powiązane tematy {#related-topics}
-- [Frameworki programistyczne](/developers/docs/frameworks/)
+- [Frameworki deweloperskie](/developers/docs/frameworks/)
+- [Uruchom węzeł Ethereum](/developers/docs/nodes-and-clients/run-a-node/)
+- [Węzły jako usługa](/developers/docs/nodes-and-clients/nodes-as-a-service)
diff --git a/public/content/translations/pl/developers/docs/smart-contracts/formal-verification/index.md b/public/content/translations/pl/developers/docs/smart-contracts/formal-verification/index.md
new file mode 100644
index 00000000000..1531bfc0289
--- /dev/null
+++ b/public/content/translations/pl/developers/docs/smart-contracts/formal-verification/index.md
@@ -0,0 +1,284 @@
+---
+title: "Formalna weryfikacja inteligentnych kontraktów"
+description: "Przegląd formalnej weryfikacji inteligentnych kontraktów Ethereum"
+lang: pl
+---
+
+[Inteligentne kontrakty](/developers/docs/smart-contracts/) umożliwiają tworzenie zdecentralizowanych, niewymagających zaufania i solidnych aplikacji, które wprowadzają nowe przypadki użycia i odblokowują wartość dla użytkowników. Ponieważ inteligentne kontrakty obsługują duże ilości wartości, bezpieczeństwo jest kluczową kwestią dla deweloperów.
+
+Weryfikacja formalna jest jedną z zalecanych technik poprawy [bezpieczeństwa inteligentnych kontraktów](/developers/docs/smart-contracts/security/). Weryfikacja formalna, która wykorzystuje [metody formalne](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/) do specyfikacji, projektowania i weryfikacji programów, jest od lat stosowana w celu zapewnienia poprawności krytycznych systemów sprzętowych i oprogramowania.
+
+Gdy jest zaimplementowana w inteligentnych kontraktach, weryfikacja formalna może udowodnić, że logika biznesowa kontraktu spełnia predefiniowaną specyfikację. W porównaniu z innymi metodami oceny poprawności kodu kontraktu, takimi jak testowanie, weryfikacja formalna daje silniejsze gwarancje, że inteligentny kontrakt jest funkcjonalnie poprawny.
+
+## Czym jest weryfikacja formalna? {#what-is-formal-verification}
+
+Weryfikacja formalna odnosi się do procesu oceny poprawności systemu w odniesieniu do formalnej specyfikacji. Mówiąc prościej, weryfikacja formalna pozwala nam sprawdzić, czy zachowanie systemu spełnia pewne wymagania (tj. czy robi to, co chcemy).
+
+Oczekiwane zachowania systemu (w tym przypadku inteligentnego kontraktu) są opisywane za pomocą modelowania formalnego, podczas gdy języki specyfikacji umożliwiają tworzenie właściwości formalnych. Techniki weryfikacji formalnej mogą następnie zweryfikować, czy implementacja kontraktu jest zgodna z jego specyfikacją i uzyskać matematyczny dowód poprawności tej pierwszej. Gdy kontrakt spełnia swoją specyfikację, określa się go jako „funkcjonalnie poprawny”, „poprawny z założenia” lub „poprawny z konstrukcji”.
+
+### Czym jest model formalny? {#what-is-a-formal-model}
+
+W informatyce [model formalny](https://en.wikipedia.org/wiki/Model_of_computation) to matematyczny opis procesu obliczeniowego. Programy są abstrahowane do funkcji matematycznych (równań), a model opisuje, jak obliczane są wyniki funkcji dla danego wejścia.
+
+Modele formalne zapewniają poziom abstrakcji, na którym można ocenić analizę zachowania programu. Istnienie modeli formalnych pozwala na stworzenie _specyfikacji formalnej_, która opisuje pożądane właściwości danego modelu.
+
+Do modelowania inteligentnych kontraktów do weryfikacji formalnej używane są różne techniki. Na przykład, niektóre modele są używane do wnioskowania o zachowaniu wysokopoziomowym inteligentnego kontraktu. Te techniki modelowania stosują widok czarnej skrzynki do inteligentnych kontraktów, postrzegając je jako systemy, które akceptują dane wejściowe i wykonują obliczenia na ich podstawie.
+
+Modele wysokopoziomowe koncentrują się na relacji między inteligentnymi kontraktami a agentami zewnętrznymi, takimi jak konta zewnętrzne (EOA), konta kontraktów i środowisko blockchain. Takie modele są przydatne do definiowania właściwości, które określają, jak kontrakt powinien się zachowywać w odpowiedzi na określone interakcje użytkownika.
+
+Odwrotnie, inne modele formalne koncentrują się na niskopoziomowym zachowaniu inteligentnego kontraktu. Podczas gdy modele wysokopoziomowe mogą pomóc w rozumowaniu o funkcjonalności kontraktu, mogą nie uchwycić szczegółów dotyczących wewnętrznego działania implementacji. Modele niskopoziomowe stosują widok białej skrzynki do analizy programu i opierają się na reprezentacjach niższego poziomu aplikacji inteligentnych kontraktów, takich jak ślady programu i [grafy przepływu sterowania](https://en.wikipedia.org/wiki/Control-flow_graph), w celu wnioskowania o właściwościach istotnych dla wykonania kontraktu.
+
+Modele niskopoziomowe są uważane za idealne, ponieważ reprezentują rzeczywiste wykonanie inteligentnego kontraktu w środowisku wykonawczym Ethereum (tj. [EVM](/developers/docs/evm/)). Techniki modelowania niskopoziomowego są szczególnie przydatne w ustanawianiu krytycznych właściwości bezpieczeństwa w inteligentnych kontraktach i wykrywaniu potencjalnych luk w zabezpieczeniach.
+
+### Czym jest specyfikacja formalna? {#what-is-a-formal-specification}
+
+Specyfikacja to po prostu wymaganie techniczne, które dany system musi spełniać. W programowaniu specyfikacje reprezentują ogólne idee dotyczące wykonania programu (tj. co program powinien robić).
+
+W kontekście inteligentnych kontraktów specyfikacje formalne odnoszą się do _właściwości_ — formalnych opisów wymagań, które kontrakt musi spełniać. Takie właściwości są opisywane jako „niezmienniki” i reprezentują logiczne stwierdzenia dotyczące wykonania kontraktu, które muszą pozostać prawdziwe w każdych możliwych okolicznościach, bez żadnych wyjątków.
+
+Możemy więc myśleć o specyfikacji formalnej jako o zbiorze oświadczeń napisanych w języku formalnym, które opisują zamierzone wykonanie inteligentnego kontraktu. Specyfikacje obejmują właściwości kontraktu i definiują, jak kontrakt powinien zachowywać się w różnych okolicznościach. Celem weryfikacji formalnej jest ustalenie, czy inteligentny kontrakt posiada te właściwości (niezmienniki) i czy te właściwości nie są naruszane podczas wykonywania.
+
+Specyfikacje formalne mają kluczowe znaczenie w tworzeniu bezpiecznych implementacji inteligentnych kontraktów. Kontrakty, które nie implementują niezmienników lub których właściwości są naruszane podczas wykonywania, są podatne na luki w zabezpieczeniach, które mogą zaszkodzić funkcjonalności lub spowodować złośliwe exploity.
+
+## Rodzaje specyfikacji formalnych dla inteligentnych kontraktów {#formal-specifications-for-smart-contracts}
+
+Specyfikacje formalne umożliwiają matematyczne rozumowanie na temat poprawności wykonania programu. Podobnie jak w przypadku modeli formalnych, specyfikacje formalne mogą przechwytywać właściwości wysokiego poziomu lub niskopoziomowe zachowanie implementacji kontraktu.
+
+Specyfikacje formalne są tworzone przy użyciu elementów [logiki programu](https://en.wikipedia.org/wiki/Logic_programming), które pozwalają na formalne rozumowanie na temat właściwości programu. Logika programu ma formalne zasady, które wyrażają (w języku matematycznym) oczekiwane zachowanie programu. Do tworzenia specyfikacji formalnych wykorzystywane są różne logiki programów, w tym [logika osiągalności](https://en.wikipedia.org/wiki/Reachability_problem), [logika temporalna](https://en.wikipedia.org/wiki/Temporal_logic) i [logika Hoare'a](https://en.wikipedia.org/wiki/Hoare_logic).
+
+Specyfikacje formalne dla inteligentnych kontraktów można ogólnie podzielić na specyfikacje **wysokiego poziomu** lub **niskiego poziomu**. Niezależnie od kategorii, do której należy specyfikacja, musi ona w sposób adekwatny i jednoznaczny opisywać właściwość analizowanego systemu.
+
+### Specyfikacje wysokopoziomowe {#high-level-specifications}
+
+Jak sama nazwa wskazuje, specyfikacja wysokiego poziomu (nazywana również „specyfikacją zorientowaną na model”) opisuje zachowanie programu na wysokim poziomie. Specyfikacje wysokiego poziomu modelują inteligentny kontrakt jako [automat skończony](https://en.wikipedia.org/wiki/Finite-state_machine) (FSM), który może przechodzić między stanami, wykonując operacje, a logika temporalna jest używana do definiowania formalnych właściwości dla modelu FSM.
+
+[Logiki temporalne](https://en.wikipedia.org/wiki/Temporal_logic) to „zasady rozumowania o zdaniach kwalifikowanych w kategoriach czasu (np. „Jestem _zawsze_ głodny” lub „W końcu _będę_ głodny”).” W przypadku zastosowania do weryfikacji formalnej logiki temporalne służą do przedstawiania twierdzeń o poprawnym zachowaniu systemów modelowanych jako automaty stanowe. W szczególności logika temporalna opisuje przyszłe stany, w jakich może znajdować się inteligentny kontrakt i jak przechodzi między stanami.
+
+Specyfikacje wysokiego poziomu zazwyczaj obejmują dwie krytyczne właściwości czasowe dla inteligentnych kontraktów: **bezpieczeństwo** i **żywotność**. Właściwości bezpieczeństwa reprezentują ideę, że „nic złego się nigdy nie dzieje” i zwykle wyrażają niezmienność. Właściwość bezpieczeństwa może definiować ogólne wymagania dotyczące oprogramowania, takie jak brak [zakleszczenia](https://www.techtarget.com/whatis/definition/deadlock), lub wyrażać właściwości specyficzne dla domeny dla kontraktów (np. niezmienniki dotyczące kontroli dostępu do funkcji, dopuszczalne wartości zmiennych stanu lub warunki transferów tokenów).
+
+Weźmy na przykład to wymaganie bezpieczeństwa, które obejmuje warunki korzystania z `transfer()` lub `transferFrom()` w kontraktach tokenów ERC-20: _„Saldo nadawcy nigdy nie jest niższe niż żądana kwota tokenów do wysłania”_. Ten opis w języku naturalnym niezmiennika kontraktu można przetłumaczyć na formalną (matematyczną) specyfikację, którą można następnie rygorystycznie sprawdzić pod kątem poprawności.
+
+Właściwości żywotności zapewniają, że „w końcu dzieje się coś dobrego” i dotyczą zdolności kontraktu do przechodzenia przez różne stany. Przykładem właściwości żywotności jest „płynność”, która odnosi się do zdolności kontraktu do przekazywania sald użytkownikom na żądanie. Jeśli ta właściwość zostanie naruszona, użytkownicy nie będą mogli wypłacić aktywów przechowywanych w kontrakcie, tak jak to miało miejsce w przypadku [incydentu z portfelem Parity](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html).
+
+### Specyfikacje niskopoziomowe {#low-level-specifications}
+
+Specyfikacje wysokopoziomowe przyjmują za punkt wyjścia model automatu skończonego kontraktu i definiują pożądane właściwości tego modelu. W przeciwieństwie do tego, specyfikacje niskopoziomowe (nazywane również „specyfikacjami zorientowanymi na właściwości”) często modelują programy (inteligentne kontrakty) jako systemy składające się z kolekcji funkcji matematycznych i opisują poprawne zachowanie takich systemów.
+
+Mówiąc prościej, specyfikacje niskopoziomowe analizują _ślady programu_ i próbują zdefiniować właściwości inteligentnego kontraktu w oparciu o te ślady. Ślady odnoszą się do sekwencji wykonań funkcji, które zmieniają stan inteligentnego kontraktu; w związku z tym specyfikacje niskopoziomowe pomagają określić wymagania dotyczące wewnętrznego wykonania kontraktu.
+
+Niskopoziomowe specyfikacje formalne można podać jako właściwości w stylu Hoare'a lub jako niezmienniki na ścieżkach wykonania.
+
+### Właściwości w stylu Hoare'a {#hoare-style-properties}
+
+[Logika Hoare'a](https://en.wikipedia.org/wiki/Hoare_logic) dostarcza zbiór formalnych zasad do rozumowania o poprawności programów, w tym inteligentnych kontraktów. Właściwość w stylu Hoare'a jest reprezentowana przez trójkę Hoare'a `{P}c{Q}`, gdzie `c` jest programem, a `P` i `Q` są predykatami stanu `c` (tj. programu), formalnie opisanymi odpowiednio jako _warunki wstępne_ i _warunki końcowe_.
+
+Warunek wstępny to predykat opisujący warunki wymagane do poprawnego wykonania funkcji; użytkownicy wywołujący kontrakt muszą spełnić to wymaganie. Warunek końcowy to predykat opisujący warunek, który funkcja ustanawia, jeśli jest poprawnie wykonana; użytkownicy mogą oczekiwać, że ten warunek będzie prawdziwy po wywołaniu funkcji. _Niezmiennik_ w logice Hoare'a jest predykatem, który jest zachowywany przez wykonanie funkcji (tj. nie zmienia się).
+
+Specyfikacje w stylu Hoare'a mogą gwarantować _częściową poprawność_ lub _całkowitą poprawność_. Implementacja funkcji kontraktu jest „częściowo poprawna”, jeśli warunek wstępny jest prawdziwy przed wykonaniem funkcji, a jeśli wykonanie się zakończy, warunek końcowy jest również prawdziwy. Dowód całkowitej poprawności uzyskuje się, jeśli warunek wstępny jest prawdziwy przed wykonaniem funkcji, wykonanie ma gwarancję zakończenia, a gdy to nastąpi, warunek końcowy jest prawdziwy.
+
+Uzyskanie dowodu całkowitej poprawności jest trudne, ponieważ niektóre wykonania mogą się opóźniać przed zakończeniem lub nigdy się nie kończyć. To powiedziawszy, pytanie, czy wykonanie się kończy, jest prawdopodobnie kwestią sporną, ponieważ mechanizm gazu Ethereum zapobiega nieskończonym pętlom programu (wykonanie kończy się pomyślnie lub z powodu błędu „braku gazu”).
+
+Specyfikacje inteligentnych kontraktów utworzone przy użyciu logiki Hoare'a będą miały zdefiniowane warunki wstępne, warunki końcowe i niezmienniki dla wykonywania funkcji i pętli w kontrakcie. Warunki wstępne często uwzględniają możliwość błędnych danych wejściowych do funkcji, a warunki końcowe opisują oczekiwaną odpowiedź na takie dane wejściowe (np. zgłoszenie określonego wyjątku). W ten sposób właściwości w stylu Hoare'a są skuteczne w zapewnianiu poprawności implementacji kontraktów.
+
+Wiele frameworków weryfikacji formalnej wykorzystuje specyfikacje w stylu Hoare'a do udowadniania poprawności semantycznej funkcji. Możliwe jest również dodawanie właściwości w stylu Hoare'a (jako asercji) bezpośrednio do kodu kontraktu za pomocą instrukcji `require` i `assert` w Solidity.
+
+Instrukcje `require` wyrażają warunek wstępny lub niezmiennik i są często używane do walidacji danych wejściowych użytkownika, podczas gdy `assert` przechwytuje warunek końcowy niezbędny dla bezpieczeństwa. Na przykład, właściwą kontrolę dostępu do funkcji (przykład właściwości bezpieczeństwa) można osiągnąć za pomocą `require` jako sprawdzenia warunku wstępnego tożsamości konta wywołującego. Podobnie, niezmiennik dotyczący dopuszczalnych wartości zmiennych stanu w kontrakcie (np. całkowita liczba tokenów w obiegu) może być chroniony przed naruszeniem za pomocą `assert` do potwierdzenia stanu kontraktu po wykonaniu funkcji.
+
+### Właściwości na poziomie śladu {#trace-level-properties}
+
+Specyfikacje oparte na śladach opisują operacje, które przenoszą kontrakt między różnymi stanami oraz relacje między tymi operacjami. Jak wyjaśniono wcześniej, ślady to sekwencje operacji, które w określony sposób zmieniają stan kontraktu.
+
+To podejście opiera się na modelu inteligentnych kontraktów jako systemów przejść stanów z pewnymi predefiniowanymi stanami (opisanymi przez zmienne stanu) wraz ze zbiorem predefiniowanych przejść (opisanych przez funkcje kontraktu). Ponadto do opisu semantyki operacyjnej kontraktu często wykorzystywany jest [graf przepływu sterowania](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/) (CFG), który jest graficzną reprezentacją przepływu wykonania programu. W tym przypadku każdy ślad jest reprezentowany jako ścieżka na grafie przepływu sterowania.
+
+Przede wszystkim specyfikacje na poziomie śladu są używane do wnioskowania o wzorcach wewnętrznego wykonania w inteligentnych kontraktach. Tworząc specyfikacje na poziomie śladu, potwierdzamy dopuszczalne ścieżki wykonania (tj. przejścia stanu) dla inteligentnego kontraktu. Używając technik, takich jak wykonanie symboliczne, możemy formalnie zweryfikować, że wykonanie nigdy nie podąża ścieżką niezdefiniowaną w modelu formalnym.
+
+Użyjmy przykładu kontraktu [DAO](/dao/), który ma kilka publicznie dostępnych funkcji do opisania właściwości na poziomie śladu. Tutaj zakładamy, że kontrakt DAO pozwala użytkownikom na wykonanie następujących operacji:
+
+- Wpłać środki
+
+- Głosuj nad propozycją po wpłaceniu środków
+
+- Zażądaj zwrotu pieniędzy, jeśli nie zagłosujesz nad propozycją
+
+Przykładowe właściwości na poziomie śladu mogą brzmieć: _„użytkownicy, którzy nie wpłacają środków, nie mogą głosować nad propozycją”_ lub _„użytkownicy, którzy nie głosują nad propozycją, powinni zawsze mieć możliwość ubiegania się o zwrot pieniędzy”_. Obie właściwości potwierdzają preferowane sekwencje wykonania (głosowanie nie może odbyć się _przed_ wpłatą środków, a ubieganie się o zwrot pieniędzy nie może odbyć się _po_ zagłosowaniu nad propozycją).
+
+## Techniki formalnej weryfikacji inteligentnych kontraktów {#formal-verification-techniques}
+
+### Sprawdzanie modelu {#model-checking}
+
+Sprawdzanie modelu to technika weryfikacji formalnej, w której algorytm sprawdza formalny model inteligentnego kontraktu pod kątem jego specyfikacji. W sprawdzaniu modeli inteligentne kontrakty są często reprezentowane jako systemy przejść stanów, podczas gdy właściwości dopuszczalnych stanów kontraktów są definiowane za pomocą logiki temporalnej.
+
+Sprawdzanie modelu wymaga stworzenia abstrakcyjnej reprezentacji matematycznej systemu (tj. kontraktu) i wyrażenia właściwości tego systemu za pomocą formuł zakorzenionych w [logice zdań](https://www.baeldung.com/cs/propositional-logic). Upraszcza to zadanie algorytmu sprawdzania modelu, a mianowicie udowodnienie, że model matematyczny spełnia daną formułę logiczną.
+
+Sprawdzanie modelu w weryfikacji formalnej jest używane głównie do oceny właściwości czasowych, które opisują zachowanie kontraktu w czasie. Właściwości czasowe inteligentnych kontraktów obejmują _bezpieczeństwo_ i _żywotność_, które wyjaśniliśmy wcześniej.
+
+Na przykład właściwość bezpieczeństwa związana z kontrolą dostępu (np. _tylko właściciel kontraktu może wywołać `selfdestruct`_) może być zapisana w logice formalnej. Następnie algorytm sprawdzania modelu może zweryfikować, czy kontrakt spełnia tę formalną specyfikację.
+
+Sprawdzanie modelu wykorzystuje eksplorację przestrzeni stanów, która polega na konstruowaniu wszystkich możliwych stanów inteligentnego kontraktu i próbie znalezienia osiągalnych stanów, które skutkują naruszeniem właściwości. Może to jednak prowadzić do nieskończonej liczby stanów (znanej jako „problem eksplozji stanów”), dlatego narzędzia do sprawdzania modeli opierają się na technikach abstrakcji, aby umożliwić wydajną analizę inteligentnych kontraktów.
+
+### Dowodzenie twierdzeń {#theorem-proving}
+
+Dowodzenie twierdzeń to metoda matematycznego rozumowania na temat poprawności programów, w tym inteligentnych kontraktów. Polega na przekształceniu modelu systemu kontraktu i jego specyfikacji w formuły matematyczne (stwierdzenia logiczne).
+
+Celem dowodzenia twierdzeń jest weryfikacja logicznej równoważności między tymi stwierdzeniami. „Równoważność logiczna” (nazywana również „bi-implikacją logiczną”) to rodzaj relacji między dwoma stwierdzeniami, w której pierwsze stwierdzenie jest prawdziwe _wtedy i tylko wtedy_, gdy drugie stwierdzenie jest prawdziwe.
+
+Wymagana relacja (równoważność logiczna) między stwierdzeniami dotyczącymi modelu kontraktu a jego właściwością jest sformułowana jako stwierdzenie możliwe do udowodnienia (nazywane twierdzeniem). Korzystając z formalnego systemu wnioskowania, zautomatyzowany dowodziciel twierdzeń może zweryfikować ważność twierdzenia. Innymi słowy, dowodziciel twierdzeń może jednoznacznie udowodnić, że model inteligentnego kontraktu dokładnie odpowiada jego specyfikacjom.
+
+Podczas gdy sprawdzanie modeli modeluje kontrakty jako systemy przejść ze skończonymi stanami, dowodzenie twierdzeń może obsługiwać analizę systemów o nieskończonych stanach. Oznacza to jednak, że zautomatyzowany dowodziciel twierdzeń nie zawsze może wiedzieć, czy problem logiczny jest „rozstrzygalny”, czy nie.
+
+W rezultacie często wymagana jest pomoc człowieka, aby poprowadzić dowodziciela twierdzeń w uzyskiwaniu dowodów poprawności. Wykorzystanie wysiłku ludzkiego w dowodzeniu twierdzeń sprawia, że jest ono droższe w użyciu niż sprawdzanie modeli, które jest w pełni zautomatyzowane.
+
+### Wykonanie symboliczne {#symbolic-execution}
+
+Wykonanie symboliczne to metoda analizy inteligentnego kontraktu poprzez wykonywanie funkcji przy użyciu _wartości symbolicznych_ (np. `x > 5`) zamiast _wartości konkretnych_ (np. `x == 5`). Jako technika weryfikacji formalnej, wykonanie symboliczne jest używane do formalnego rozumowania na temat właściwości na poziomie śladu w kodzie kontraktu.
+
+Wykonanie symboliczne reprezentuje ślad wykonania jako formułę matematyczną nad symbolicznymi wartościami wejściowymi, zwaną inaczej _predykatem ścieżki_. Do sprawdzenia, czy predykat ścieżki jest „spełnialny” (tzn. istnieje wartość, która może spełnić formułę), używany jest [solver SMT](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories). Jeśli ścieżka podatna na zagrożenia jest spełnialna, solver SMT wygeneruje konkretną wartość, która wyzwala i kieruje wykonanie w kierunku tej ścieżki.
+
+Załóżmy, że funkcja inteligentnego kontraktu przyjmuje jako dane wejściowe wartość `uint` (`x`) i cofa się, gdy `x` jest większe niż `5`, a także mniejsze niż `10`. Znalezienie wartości `x`, która wywołuje błąd przy użyciu normalnej procedury testowania, wymagałoby przejrzenia dziesiątek przypadków testowych (lub więcej) bez gwarancji faktycznego znalezienia danych wejściowych wywołujących błąd.
+
+Odwrotnie, narzędzie do wykonywania symbolicznego wykonałoby funkcję z wartością symboliczną: `X > 5 ∧ X < 10` (tj. `x` jest większe niż 5 I `x` jest mniejsze niż 10). Powiązany predykat ścieżki `x = X > 5 ∧ X < 10` zostałby następnie przekazany do rozwiązania solverowi SMT. Jeśli dana wartość spełnia formułę `x = X > 5 ∧ X < 10`, solver SMT ją obliczy — na przykład solver może wygenerować `7` jako wartość dla `x`.
+
+Ponieważ wykonanie symboliczne opiera się na danych wejściowych do programu, a zbiór danych wejściowych do zbadania wszystkich osiągalnych stanów jest potencjalnie nieskończony, nadal jest to forma testowania. Jednak, jak pokazano na przykładzie, wykonanie symboliczne jest bardziej wydajne niż zwykłe testowanie w celu znalezienia danych wejściowych, które wyzwalają naruszenia właściwości.
+
+Co więcej, wykonanie symboliczne generuje mniej fałszywych alarmów niż inne techniki oparte na właściwościach (np. fuzzing), które losowo generują dane wejściowe do funkcji. Jeśli podczas wykonywania symbolicznego zostanie wyzwolony stan błędu, możliwe jest wygenerowanie konkretnej wartości, która wyzwala błąd i odtworzenie problemu.
+
+Wykonanie symboliczne może również zapewnić pewien stopień matematycznego dowodu poprawności. Rozważ następujący przykład funkcji kontraktu z zabezpieczeniem przed przepełnieniem:
+
+```
+function safe_add(uint x, uint y) returns(uint z){
+
+ z = x + y;
+ require(z>=x);
+ require(z>=y);
+
+ return z;
+}
+```
+
+Ślad wykonania, który powoduje przepełnienie liczby całkowitej, musiałby spełniać formułę: `z = x + y AND (z >= x) AND (z >= y) AND (z < x OR z < y)` Taka formuła jest mało prawdopodobna do rozwiązania, dlatego służy jako matematyczny dowód, że funkcja `safe_add` nigdy nie ulega przepełnieniu.
+
+### Dlaczego warto stosować weryfikację formalną dla inteligentnych kontraktów? {#benefits-of-formal-verification}
+
+#### Potrzeba niezawodności {#need-for-reliability}
+
+Weryfikacja formalna służy do oceny poprawności systemów o krytycznym znaczeniu dla bezpieczeństwa, których awaria może mieć katastrofalne skutki, takie jak śmierć, obrażenia lub ruina finansowa. Inteligentne kontrakty to aplikacje o wysokiej wartości, kontrolujące ogromne ilości wartości, a proste błędy w projektowaniu mogą prowadzić do [nieodwracalnych strat dla użytkowników](https://www.freecodecamp.org/news/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce/amp/). Formalne zweryfikowanie kontraktu przed wdrożeniem może jednak zwiększyć gwarancje, że będzie on działał zgodnie z oczekiwaniami po uruchomieniu na blockchainie.
+
+Niezawodność jest wysoce pożądaną cechą każdego inteligentnego kontraktu, zwłaszcza że kod wdrożony w Wirtualnej Maszynie Ethereum (EVM) jest zazwyczaj niezmienny. Przy braku łatwo dostępnych uaktualnień po uruchomieniu, potrzeba zagwarantowania niezawodności kontraktów sprawia, że weryfikacja formalna jest konieczna. Weryfikacja formalna jest w stanie wykryć trudne problemy, takie jak niedopełnienie i przepełnienie liczb całkowitych, reentrancy i słabe optymalizacje gazu, które mogą umknąć audytorom i testerom.
+
+#### Udowodnij poprawność funkcjonalną {#prove-functional-correctness}
+
+Testowanie programu jest najczęstszą metodą udowodnienia, że inteligentny kontrakt spełnia pewne wymagania. Polega to na wykonaniu kontraktu z próbką danych, które ma obsługiwać, i analizie jego zachowania. Jeśli kontrakt zwróci oczekiwane wyniki dla danych próbnych, deweloperzy mają obiektywny dowód jego poprawności.
+
+Podejście to nie może jednak udowodnić poprawnego wykonania dla wartości wejściowych, które nie są częścią próbki. Dlatego testowanie kontraktu może pomóc w wykryciu błędów (tj. jeśli niektóre ścieżki kodu nie zwrócą pożądanych wyników podczas wykonywania), ale **nie może jednoznacznie udowodnić braku błędów**.
+
+Odwrotnie, weryfikacja formalna może formalnie udowodnić, że inteligentny kontrakt spełnia wymagania dla nieskończonego zakresu wykonań _bez_ uruchamiania kontraktu. Wymaga to stworzenia formalnej specyfikacji, która precyzyjnie opisuje poprawne zachowania kontraktu i opracowania formalnego (matematycznego) modelu systemu kontraktu. Następnie możemy postępować zgodnie z formalną procedurą dowodową, aby sprawdzić spójność między modelem kontraktu a jego specyfikacją.
+
+Dzięki weryfikacji formalnej pytanie, czy logika biznesowa kontraktu spełnia wymagania, jest propozycją matematyczną, którą można udowodnić lub obalić. Poprzez formalne udowodnienie propozycji możemy zweryfikować nieskończoną liczbę przypadków testowych w skończonej liczbie kroków. W ten sposób weryfikacja formalna ma lepsze perspektywy udowodnienia, że kontrakt jest funkcjonalnie poprawny w odniesieniu do specyfikacji.
+
+#### Idealne cele weryfikacji {#ideal-verification-targets}
+
+Cel weryfikacji opisuje system, który ma być formalnie zweryfikowany. Weryfikacja formalna jest najlepiej stosowana w „systemach wbudowanych” (małych, prostych fragmentach oprogramowania, które stanowią część większego systemu). Są również idealne dla wyspecjalizowanych domen, które mają niewiele reguł, ponieważ ułatwia to modyfikację narzędzi do weryfikacji właściwości specyficznych dla domeny.
+
+Inteligentne kontrakty — przynajmniej do pewnego stopnia — spełniają oba te wymagania. Na przykład niewielki rozmiar kontraktów Ethereum sprawia, że nadają się one do weryfikacji formalnej. Podobnie, EVM przestrzega prostych zasad, co ułatwia specyfikowanie i weryfikację właściwości semantycznych dla programów działających w EVM.
+
+### Szybszy cykl rozwoju {#faster-development-cycle}
+
+Techniki weryfikacji formalnej, takie jak sprawdzanie modeli i wykonanie symboliczne, są na ogół bardziej wydajne niż regularna analiza kodu inteligentnego kontraktu (przeprowadzana podczas testowania lub audytu). Dzieje się tak, ponieważ weryfikacja formalna opiera się na wartościach symbolicznych do testowania twierdzeń („co, jeśli użytkownik spróbuje wypłacić _n_ ether?”) w przeciwieństwie do testowania, które wykorzystuje konkretne wartości („co, jeśli użytkownik spróbuje wypłacić 5 ether?”).
+
+Symboliczne zmienne wejściowe mogą obejmować wiele klas konkretnych wartości, więc podejścia do weryfikacji formalnej obiecują większe pokrycie kodu w krótszym czasie. Gdy jest stosowana skutecznie, weryfikacja formalna może przyspieszyć cykl rozwoju dla deweloperów.
+
+Weryfikacja formalna poprawia również proces budowania dapki, zmniejszając kosztowne błędy projektowe. Aktualizowanie kontraktów (tam, gdzie to możliwe) w celu naprawienia luk w zabezpieczeniach wymaga obszernego przepisywania baz kodu i większego wysiłku włożonego w rozwój. Weryfikacja formalna może wykryć wiele błędów w implementacjach kontraktów, które mogą umknąć testerom i audytorom, i zapewnia wiele możliwości naprawienia tych problemów przed wdrożeniem kontraktu.
+
+## Wady weryfikacji formalnej {#drawbacks-of-formal-verification}
+
+### Koszt pracy ręcznej {#cost-of-manual-labor}
+
+Weryfikacja formalna, zwłaszcza półautomatyczna weryfikacja, w której człowiek kieruje dowodzącym w celu uzyskania dowodów poprawności, wymaga znacznej pracy ręcznej. Co więcej, tworzenie specyfikacji formalnej jest złożonym działaniem, które wymaga wysokiego poziomu umiejętności.
+
+Czynniki te (wysiłek i umiejętności) sprawiają, że weryfikacja formalna jest bardziej wymagająca i kosztowna w porównaniu ze zwykłymi metodami oceny poprawności kontraktów, takimi jak testowanie i audyty. Niemniej jednak, poniesienie kosztu pełnego audytu weryfikacyjnego jest praktyczne, biorąc pod uwagę koszt błędów w implementacjach inteligentnych kontraktów.
+
+### Wyniki fałszywie ujemne {#false-negatives}
+
+Weryfikacja formalna może jedynie sprawdzić, czy wykonanie inteligentnego kontraktu jest zgodne ze specyfikacją formalną. W związku z tym ważne jest, aby upewnić się, że specyfikacja prawidłowo opisuje oczekiwane zachowania inteligentnego kontraktu.
+
+Jeśli specyfikacje są źle napisane, naruszenia właściwości — które wskazują na podatne na zagrożenia wykonania — nie mogą zostać wykryte przez audyt weryfikacji formalnej. W takim przypadku deweloper może błędnie założyć, że kontrakt jest wolny od błędów.
+
+### Problemy z wydajnością {#performance-issues}
+
+Weryfikacja formalna napotyka szereg problemów z wydajnością. Na przykład problemy z eksplozją stanów i ścieżek napotykane odpowiednio podczas sprawdzania modeli i sprawdzania symbolicznego mogą wpływać na procedury weryfikacyjne. Ponadto narzędzia do weryfikacji formalnej często wykorzystują solvery SMT i inne solvery ograniczeń w swojej warstwie podstawowej, a solvery te opierają się na procedurach intensywnych obliczeniowo.
+
+Ponadto nie zawsze jest możliwe, aby weryfikatory programu ustaliły, czy właściwość (opisana jako formuła logiczna) może być spełniona, czy nie („[problem rozstrzygalności](https://en.wikipedia.org/wiki/Decision_problem)”), ponieważ program może nigdy się nie zakończyć. W związku z tym udowodnienie niektórych właściwości kontraktu może być niemożliwe, nawet jeśli jest on dobrze określony.
+
+## Narzędzia do weryfikacji formalnej dla inteligentnych kontraktów Ethereum {#formal-verification-tools}
+
+### Języki specyfikacji do tworzenia specyfikacji formalnych {#specification-languages}
+
+**Act**: __Act umożliwia specyfikację aktualizacji przechowywania, warunków wstępnych/końcowych i niezmienników kontraktu. Jego zestaw narzędzi ma również backendy dowodowe zdolne do udowodnienia wielu właściwości za pomocą Coq, solverów SMT lub hevm.__
+
+- [GitHub](https://github.com/ethereum/act)
+- [Dokumentacja](https://github.com/argotorg/act)
+
+**Scribble** - __Scribble przekształca adnotacje kodu w języku specyfikacji Scribble w konkretne asercje, które sprawdzają specyfikację.__
+
+- [Dokumentacja](https://docs.scribble.codes/)
+
+**Dafny** - __Dafny to gotowy do weryfikacji język programowania, który opiera się na adnotacjach wysokiego poziomu w celu wnioskowania i udowadniania poprawności kodu.__
+
+- [GitHub](https://github.com/dafny-lang/dafny)
+
+### Weryfikatory programu do sprawdzania poprawności {#program-verifiers}
+
+**Certora Prover** – _Certora Prover to automatyczne narzędzie do weryfikacji formalnej służące do sprawdzania poprawności kodu w inteligentnych kontraktach. Specyfikacje są pisane w CVL (Certora Verification Language), a naruszenia właściwości są wykrywane za pomocą kombinacji analizy statycznej i rozwiązywania ograniczeń._
+
+- [Strona internetowa](https://www.certora.com/)
+- [Dokumentacja](https://docs.certora.com/en/latest/index.html)
+
+**Solidity SMTChecker** - __SMTChecker w Solidity to wbudowane narzędzie do sprawdzania modeli oparte na SMT (Satisfiability Modulo Theories) i rozwiązywaniu problemów Horna. Potwierdza, czy kod źródłowy kontraktu pasuje do specyfikacji podczas kompilacji i statycznie sprawdza naruszenia właściwości bezpieczeństwa.__
+
+- [GitHub](https://github.com/ethereum/solidity)
+
+**solc-verify** - __solc-verify to rozszerzona wersja kompilatora Solidity, która może przeprowadzać zautomatyzowaną weryfikację formalną kodu Solidity przy użyciu adnotacji i modułowej weryfikacji programu.__
+
+- [GitHub](https://github.com/SRI-CSL/solidity)
+
+**KEVM** - __KEVM to formalna semantyka Wirtualnej Maszyny Ethereum (EVM) napisana w frameworku K. KEVM jest wykonywalny i może udowodnić pewne twierdzenia związane z właściwościami za pomocą logiki osiągalności.__
+
+- [GitHub](https://github.com/runtimeverification/evm-semantics)
+- [Dokumentacja](https://jellopaper.org/)
+
+### Frameworki logiczne do dowodzenia twierdzeń {#theorem-provers}
+
+**Isabelle** - _Isabelle/HOL to asystent dowodzenia, który pozwala na wyrażanie formuł matematycznych w języku formalnym i dostarcza narzędzi do dowodzenia tych formuł. Głównym zastosowaniem jest formalizacja dowodów matematycznych, a w szczególności weryfikacja formalna, która obejmuje dowodzenie poprawności sprzętu lub oprogramowania komputerowego oraz dowodzenie właściwości języków komputerowych i protokołów._
+
+- [GitHub](https://github.com/isabelle-prover)
+- [Dokumentacja](https://isabelle.in.tum.de/documentation.html)
+
+**Rocq** - _Rocq to interaktywny dowodziciel twierdzeń, który pozwala definiować programy za pomocą twierdzeń i interaktywnie generować sprawdzane maszynowo dowody poprawności._
+
+- [GitHub](https://github.com/rocq-prover/rocq)
+- [Dokumentacja](https://rocq-prover.org/docs)
+
+### Narzędzia oparte na wykonaniu symbolicznym do wykrywania podatnych na ataki wzorców w inteligentnych kontraktach {#symbolic-execution-tools}
+
+**Manticore** - __Narzędzie do analizy kodu bajtowego EVM oparte na wykonaniu symbolicznym_._
+
+- [GitHub](https://github.com/trailofbits/manticore)
+- [Dokumentacja](https://github.com/trailofbits/manticore/wiki)
+
+**hevm** - __hevm to silnik wykonania symbolicznego i kontroler równoważności dla kodu bajtowego EVM.__
+
+- [GitHub](https://github.com/dapphub/dapptools/tree/master/src/hevm)
+
+**Mythril** – _narzędzie do wykonywania symbolicznego do wykrywania luk w zabezpieczeniach w inteligentnych kontraktach Ethereum_
+
+- [GitHub](https://github.com/ConsenSys/mythril-classic)
+- [Dokumentacja](https://mythril-classic.readthedocs.io/en/develop/)
+
+## Dalsza lektura {#further-reading}
+
+- [Jak działa formalna weryfikacja inteligentnych kontraktów](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/)
+- [Jak formalna weryfikacja może zapewnić bezbłędne inteligentne kontrakty](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1)
+- [Przegląd projektów weryfikacji formalnej w ekosystemie Ethereum](https://github.com/leonardoalt/ethereum_formal_verification_overview)
+- [Kompleksowa weryfikacja formalna kontraktu depozytowego Ethereum 2.0](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/)
+- [Formalna weryfikacja najpopularniejszego na świecie inteligentnego kontraktu](https://www.zellic.io/blog/formal-verification-weth)
+- [SMTChecker i weryfikacja formalna](https://docs.soliditylang.org/en/v0.8.15/smtchecker.html)
diff --git a/public/content/translations/pl/developers/docs/smart-contracts/index.md b/public/content/translations/pl/developers/docs/smart-contracts/index.md
index 81f3f0c70a7..c17e2dcaca8 100644
--- a/public/content/translations/pl/developers/docs/smart-contracts/index.md
+++ b/public/content/translations/pl/developers/docs/smart-contracts/index.md
@@ -1,22 +1,24 @@
---
-title: Wprowadzenie do inteligentnych kontraktów
-description: Przegląd inteligentnych kontraktów ze szczególnym uwzględnieniem ich unikalnych cech i ograniczeń.
+title: "Wprowadzenie do inteligentnych kontraktów"
+description: "Przegląd inteligentnych kontraktów ze szczególnym uwzględnieniem ich unikalnych cech i ograniczeń."
lang: pl
---
-## Czym jest inteligentny kontrakt?
+## Czym jest inteligentny kontrakt? {#what-is-a-smart-contract}
„Inteligentny kontrakt" jest po prostu programem, który działa w blockchainie Ethereum. Jest to zbiór kodu (jego funkcje) i danych (jego stan), które znajdują się pod określonym adresem w blockchainie Ethereum.
-Inteligentne kontrakty są rodzajem [konta Ethereum](/developers/docs/accounts/). Oznacza to, że mają one saldo i mogą wysyłać transakcje przez sieć. Jednak nie są one kontrolowane przez użytkownika, zamiast tego są wdrażane do sieci i uruchamiane w sposób zaprogramowany. Konta użytkowników mogą następnie wchodzić w interakcję z inteligentnym kontraktem poprzez przesyłanie transakcji, które wykonują funkcję zdefiniowaną w inteligentnym kontrakcie. Inteligentne kontrakty mogą definiować reguły, tak jak zwykłe kontrakty, i automatycznie egzekwować je za pośrednictwem kodu.
+Inteligentne kontrakty to rodzaj [konta Ethereum](/developers/docs/accounts/). Oznacza to, że mają saldo i mogą być celem transakcji. Jednak nie są one kontrolowane przez użytkownika, zamiast tego są wdrażane do sieci i uruchamiane w sposób zaprogramowany. Konta użytkowników mogą następnie wchodzić w interakcję z inteligentnym kontraktem poprzez przesyłanie transakcji, które wykonują funkcję zdefiniowaną w inteligentnym kontrakcie. Inteligentne kontrakty mogą definiować reguły, tak jak zwykłe kontrakty, i automatycznie egzekwować je za pośrednictwem kodu. Inteligentnych kontraktów nie można domyślnie usunąć, a interakcje z nimi są nieodwracalne.
-## Warunki wstępne {#prerequisites}
+## Wymagania wstępne {#prerequisites}
-Upewnij się, że zapoznałeś się z [kontami](/developers/docs/accounts/), [transakcjami](/developers/docs/transactions/) i
+Jeśli dopiero zaczynasz lub szukasz mniej technicznego wprowadzenia, polecamy nasze [wprowadzenie do inteligentnych kontraktów](/smart-contracts/).
-## Cyfrowy automat do sprzedaży {#a-digital-vending-machine}
+Przed zagłębieniem się w świat inteligentnych kontraktów, należy zapoznać się z [kontami](/developers/docs/accounts/), [transakcjami](/developers/docs/transactions/) oraz [Wirtualną Maszyną Ethereum](/developers/docs/evm/).
-Być może najlepszą metaforą dla inteligentnego kontraktu jest automat do sprzedaży opisany przez Nicka Szabo. Przy odpowiednich nakładach gwarantowany jest określony wynik.
+## Cyfrowy automat sprzedający {#a-digital-vending-machine}
+
+Prawdopodobnie najlepszą metaforą inteligentnego kontraktu jest automat sprzedający, zgodnie z opisem [Nicka Szabo](https://unenumerated.blogspot.com/). Przy odpowiednich danych wejściowych gwarantowany jest określony wynik.
Aby uzyskać przekąskę z automatu do sprzedaży:
@@ -26,82 +28,85 @@ pieniądze + wybór przekąsek = przekąski wydane
Ta logika jest zaprogramowana w automacie sprzedającym.
-Inteligentny kontrakt, jak automat sprzedający, ma zaprogramowaną logikę. Oto prosty przykład, jak taki automat może wyglądać jako inteligentny kontrakt:
+Inteligentny kontrakt, jak automat sprzedający, ma zaprogramowaną logikę. Oto prosty przykład tego, jak wyglądałby ten automat, gdyby był inteligentnym kontraktem napisanym w Solidity:
```solidity
-pragma solidity 0.6.11;
+pragma solidity 0.8.7;
contract VendingMachine {
- // Deklaracja zmiennych stanu kontraktu
+ // Zadeklaruj zmienne stanu kontraktu
address public owner;
mapping (address => uint) public cupcakeBalances;
- // Kiedy kontrakt 'VendingMachine' jest wdrożony:
- // 1. ustawia adres podmiotu wdrażającego jako właściciela kontraktu
- // 2. ustawia bilans babeczek wdrożonego inteligentnego kontraktu na 100
- constructor() public {
+ // Gdy kontrakt „VendingMachine” jest wdrażany:
+ // 1. ustaw adres wdrażający jako właściciela kontraktu
+ // 2. ustaw saldo babeczek we wdrożonym inteligentnym kontrakcie na 100
+ constructor() {
owner = msg.sender;
cupcakeBalances[address(this)] = 100;
}
- // Umożliwia właścicielowi zwiększenie salda babeczek inteligentnego kontraktu
+ // Zezwól właścicielowi na zwiększenie salda babeczek w inteligentnym kontrakcie
function refill(uint amount) public {
- require(msg.sender == owner, "Only the owner can refill.");
+ require(msg.sender == owner, "Tylko właściciel może uzupełnić.");
cupcakeBalances[address(this)] += amount;
}
- // Umożliwia każdemu zakup babeczek
+ // Zezwól każdemu na zakup babeczek
function purchase(uint amount) public payable {
- require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake");
- require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock to complete this purchase");
+ require(msg.value >= amount * 1 ether, "Musisz zapłacić co najmniej 1 ETH za babeczkę");
+ require(cupcakeBalances[address(this)] >= amount, "Za mało babeczek w magazynie, aby sfinalizować ten zakup");
cupcakeBalances[address(this)] -= amount;
cupcakeBalances[msg.sender] += amount;
}
}
```
-Podobnie jak automat sprzedający eliminuje potrzebę zatrudniania pracownika sprzedawcy, inteligentne kontrakty mogą zastąpić pośredników w wielu branżach.
+Podobnie jak automat sprzedający eliminuje potrzebę zatrudniania sprzedawcy, inteligentne kontrakty mogą zastąpić pośredników w wielu branżach.
-## Nie wymaga pozwolenia {#permissionless}
+## Niewymagający zezwoleń {#permissionless}
-Każdy może napisać inteligentny kontrakt i wdrożyć go do sieci. Musisz tylko nauczyć się kodowania w [języku inteligentnego kontraktu](/developers/docs/smart-contracts/languages/) i mieć wystarczająco dużo ETH, aby go wdrożyć. Wdrożenie inteligentnego kontraktu jest transakcją techniczną, więc musisz zapłacić Koszty gazu związane z wdrożeniem kontraktów są jednak znacznie wyższe.
+Każdy może napisać inteligentny kontrakt i wdrożyć go do sieci. Wystarczy nauczyć się programować w [języku inteligentnych kontraktów](/developers/docs/smart-contracts/languages/) i mieć wystarczająco dużo ETH, aby wdrożyć swój kontrakt. Wdrożenie inteligentnego kontraktu jest technicznie transakcją, więc trzeba zapłacić za [gaz](/developers/docs/gas/) w taki sam sposób, w jaki trzeba płacić za gaz przy prostym transferze ETH. Jednak koszty gazu w przypadku wdrożenia kontraktu są znacznie wyższe.
Ethereum ma przyjazne dla deweloperów języki do pisania inteligentnych kontraktów:
- Solidity
- Vyper
-[Więcej języków](/developers/docs/smart-contracts/languages/)
+[Więcej o językach](/developers/docs/smart-contracts/languages/)
-Muszą one jednak zostać skompilowane przed ich uruchomieniem, tak aby maszyna wirtualna Ethereum mogła zinterpretować i przechowywać kontrakt. [Więcej na temat kompilacji](/developers/docs/smart-contracts/compiling/)
+Muszą one jednak zostać skompilowane przed ich wdrożeniem, tak aby maszyna wirtualna Ethereum mogła zinterpretować i przechowywać kontrakt. [Więcej o kompilacji](/developers/docs/smart-contracts/compiling/)
-## Kompozycyjność – o wzajemnej zależności komponentów {#composability}
+## Kompozycyjność {#composability}
Inteligentne kontrakty są publiczne w Ethereum i można je uznać za otwarte API. Oznacza to, że możesz wywoływać inne inteligentne kontrakty w swoim własnym inteligentnym kontrakcie, aby znacznie rozszerzyć zakres możliwości. Kontrakty mogą nawet wdrażać inne kontrakty.
-Dowiedz się więcej o [kompozycyjności kontraktów inteligentnych](/developers/docs/smart-contracts/composability/).
+Dowiedz się więcej o [kompozycyjności inteligentnych kontraktów](/developers/docs/smart-contracts/composability/).
## Ograniczenia {#limitations}
-Same inteligentne kontrakty nie mogą uzyskać informacji o zdarzeniach z „prawdziwego świata”, ponieważ nie mogą wysyłać żądań HTTP. Jest to celowe, ponieważ poleganie na informacjach z zewnątrz mogłoby zagrozić konsensusowi, który jest ważny dla bezpieczeństwa i decentralizacji.
+Inteligentne kontrakty nie mogą same uzyskiwać informacji o wydarzeniach "świata rzeczywistego", ponieważ nie mogą pozyskiwać danych ze źródeł spoza łańcucha. Oznacza to, że nie mogą reagować na wydarzenia w prawdziwym świecie. Jest to celowe. Poleganie na informacjach z zewnątrz mogłoby zagrozić konsensusowi, który jest ważny dla bezpieczeństwa i decentralizacji.
+
+Ważna jest jednakże dla aplikacji blockchain możliwość używania danych spoza łańcucha. Rozwiązaniem są [wyrocznie](/developers/docs/oracles/), czyli narzędzia, które pobierają dane spoza łańcucha i udostępniają je inteligentnym kontraktom.
+
+Kolejnym ograniczeniem inteligentnych kontraktów jest ich maksymalny rozmiar. Inteligentny kontrakt może mieć maksymalnie 24KB, w przeciwnym razie skończy mu się gaz. Można to obejść, używając wzorca [The Diamond Pattern](https://eips.ethereum.org/EIPS/eip-2535).
-Istnieją sposoby na obejście tego za pomocą [wyroczni](/developers/docs/oracles/).
+## Kontrakty multisig {#multisig}
-## Zasoby inteligentnych kontraktów {#smart-contract-resources}
+Kontrakty multisig (wielopodpisowe) to konta inteligentnych kontraktów, które wymagają wielu ważnych podpisów do wykonania transakcji. Jest to bardzo przydatne w celu uniknięcia pojedynczych punktów awarii w przypadku kontraktów zawierających znaczne ilości etheru lub innych tokenów. Kontrakty multisig dzielą również odpowiedzialność za wykonanie kontraktu i zarządzanie kluczami między wiele stron i zapobiegają utracie pojedynczego klucza prywatnego, co prowadzi do nieodwracalnej utraty środków. Z tych powodów kontrakty multisig mogą być wykorzystywane do prostego zarządzania DAO. Kontrakty multisig wymagają N podpisów z M możliwych do zaakceptowania podpisów (gdzie N ≤ M i M > 1) w celu wykonania. `N = 3, M = 5` i `N = 4, M = 7` są powszechnie używane. Kontrakt multisig 4/7 wymaga czterech z siedmiu możliwych ważnych podpisów. Oznacza to, że środki można odzyskać nawet w przypadku utraty trzech podpisów. W tym przypadku oznacza to również, że większość posiadaczy kluczy musi się zgodzić i podpisać, aby kontrakt został wykonany.
-**Kontrakty OpenZeppelin –** **biblioteka do bezpiecznego tworzenia inteligentnych kontraktów.**
+## Zasoby dotyczące inteligentnych kontraktów {#smart-contract-resources}
+
+**Kontrakty OpenZeppelin -** **_Biblioteka do bezpiecznego tworzenia inteligentnych kontraktów._**
- [openzeppelin.com/contracts/](https://openzeppelin.com/contracts/)
- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts)
- [Forum społeczności](https://forum.openzeppelin.com/c/general/16)
-**DappSys –** **bezpieczne, proste, elastyczne elementy konstrukcyjne do inteligentnych kontraktów.**
-
-- [Dappsys](https://dappsys.readthedocs.io/)
-- [GitHub](https://github.com/dapphub/dappsys)
-
## Dalsza lektura {#further-reading}
-- [Inteligentne kontrakty: technologia blockchain, która zastąpi prawników](https://blockgeeks.com/guides/smart-contracts/) – Blockgeeks
-- [Najlepsze praktyki opracowywania inteligentnych kontraktów](https://yos.io/2019/11/10/smart-contract-development-best-practices/) _– 10 listopada 2019 r. – Yos Riady_
+- [Coinbase: Czym jest inteligentny kontrakt?](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract)
+- [Chainlink: Czym jest inteligentny kontrakt?](https://chain.link/education/smart-contracts)
+- [Wideo: Proste wyjaśnienie – Inteligentne kontrakty](https://youtu.be/ZE2HxTmxfrI)
+- [Cyfrin Updraft: platforma do nauki i audytu Web3](https://updraft.cyfrin.io)
diff --git a/public/content/translations/pl/developers/docs/smart-contracts/languages/index.md b/public/content/translations/pl/developers/docs/smart-contracts/languages/index.md
index 63ec7dcbb46..01793d65384 100644
--- a/public/content/translations/pl/developers/docs/smart-contracts/languages/index.md
+++ b/public/content/translations/pl/developers/docs/smart-contracts/languages/index.md
@@ -1,40 +1,46 @@
---
-title: Języki inteligentnych kontraktów
-description: Przegląd i porównanie dwóch głównych języków inteligentnych kontraktów – Solidity i Vyper.
+title: "Języki inteligentnego kontraktu"
+description: "Przegląd i porównanie dwóch głównych języków inteligentnych kontraktów – Solidity i Vyper."
lang: pl
---
-Świetnym aspektem Ethereum jest to, że inteligentne kontrakty można programować przy użyciu stosunkowo przyjaznych dla programistów języków. Jeśli masz doświadczenie z Pythonem lub JavaScript, możesz znaleźć język o znanej składni.
+Świetnym aspektem Ethereum jest to, że inteligentne kontrakty można programować przy użyciu stosunkowo przyjaznych dla programistów języków. Jeśli masz doświadczenie w Pythonie lub jakimkolwiek [języku z nawiasami klamrowymi](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages), możesz znaleźć język o znajomej składni.
Dwa najbardziej aktywne i obsługiwane języki to:
- Solidity
- Vyper
-Bardziej doświadczeni programiści mogą również użyć Yul, pośredniego języka dla [wirtualnej maszyny Ethereum](/developers/docs/evm/), lub Yul+, rozszerzenia Yul.
+Remix IDE zapewnia kompleksowe środowisko programistyczne do tworzenia i testowania kontraktów zarówno w Solidity, jak i Vyper. [Wypróbuj Remix IDE w przeglądarce](https://remix.ethereum.org), aby zacząć kodować.
-## Warunki wstępne {#prerequisites}
+Bardziej doświadczeni programiści mogą również chcieć użyć Yul, języka pośredniego dla [Wirtualnej Maszyny Ethereum](/developers/docs/evm/), lub Yul+, rozszerzenia Yul.
+
+Jeśli jesteś ciekawy i chcesz pomóc w testowaniu nowych języków, które wciąż są w fazie intensywnego rozwoju, możesz poeksperymentować z Fe, nowym językiem inteligentnych kontraktów, który obecnie jest jeszcze w początkowej fazie rozwoju.
+
+## Wymagania wstępne {#prerequisites}
Wcześniejsza znajomość języków programowania, zwłaszcza JavaScript lub Python, może pomóc w zrozumieniu różnic w językach inteligentnych kontraktów. Zalecamy również zrozumienie inteligentnych kontraktów jako koncepcji przed zbytnim zagłębieniem się w porównania języków. [Wprowadzenie do inteligentnych kontraktów](/developers/docs/smart-contracts/).
## Solidity {#solidity}
-- Wpłynęły na niego języki C++, Python i JavaScript.
+- Obiektowy język wysokiego poziomu do implementacji inteligentnych kontraktów.
+- Język z nawiasami klamrowymi, na który największy wpływ miał C++.
- Typowanie statyczne (typ zmiennej jest znany w czasie kompilacji).
- Obsługuje:
- Dziedziczenie (możesz rozszerzać inne kontrakty).
- - Biblioteki (można utworzyć kod wielokrotnego użytku, który można wywoływać z różnych kontraktów — jak funkcje statyczne w klasie statycznej w innych językach programowania obiektowego).
+ - Biblioteki (możesz utworzyć kod wielokrotnego użytku, który można wywoływać z różnych kontraktów — jak funkcje statyczne w klasie statycznej w innych językach programowania obiektowego).
- Złożone typy zdefiniowane przez użytkownika.
### Ważne linki {#important-links}
- [Dokumentacja](https://docs.soliditylang.org/en/latest/)
-- [Portal poświęcony językowi Solidity](https://soliditylang.org/)
-- [Solidity w przykładach](https://docs.soliditylang.org/en/latest/solidity-by-example.html)
+- [Portal języka Solidity](https://soliditylang.org/)
+- [Solidity na przykładach](https://docs.soliditylang.org/en/latest/solidity-by-example.html)
- [GitHub](https://github.com/ethereum/solidity/)
-- [Czat dotyczący Solidity na Glitterze](https://gitter.im/ethereum/solidity)
+- [Czat Gitter Solidity](https://gitter.im/ethereum/solidity) zmostowany z [czatem Matrix Solidity](https://matrix.to/#/#ethereum_solidity:gitter.im)
- [Ściągawka](https://reference.auditless.com/cheatsheet)
-- [Blog poświęcony Solidity](https://blog.soliditylang.org/)
+- [Blog Solidity](https://blog.soliditylang.org/)
+- [Twitter Solidity](https://twitter.com/solidity_lang)
### Przykładowy kontrakt {#example-contract}
@@ -43,33 +49,33 @@ Wcześniejsza znajomość języków programowania, zwłaszcza JavaScript lub Pyt
pragma solidity >= 0.7.0;
contract Coin {
- // The keyword "public" makes variables
- // accessible from other contracts
+ // Słowo kluczowe "public" udostępnia zmienne
+ // z innych kontraktów
address public minter;
mapping (address => uint) public balances;
- // Events allow clients to react to specific
- // contract changes you declare
+ // Zdarzenia pozwalają klientom reagować na określone
+ // zmiany w kontrakcie, które zadeklarujesz
event Sent(address from, address to, uint amount);
- // Constructor code is only run when the contract
- // is created
+ // Kod konstruktora jest uruchamiany tylko wtedy, gdy kontrakt
+ // jest tworzony
constructor() {
minter = msg.sender;
}
- // Sends an amount of newly created coins to an address
- // Can only be called by the contract creator
+ // Wysyła pewną ilość nowo utworzonych monet na dany adres
+ // Może być wywołane tylko przez twórcę kontraktu
function mint(address receiver, uint amount) public {
require(msg.sender == minter);
require(amount < 1e60);
balances[receiver] += amount;
}
- // Sends an amount of existing coins
- // from any caller to an address
+ // Wysyła pewną ilość istniejących monet
+ // od dowolnego wywołującego na dany adres
function send(address receiver, uint amount) public {
- require(amount <= balances[msg.sender], "Insufficient balance.");
+ require(amount <= balances[msg.sender], "Niewystarczające saldo.");
balances[msg.sender] -= amount;
balances[receiver] += amount;
emit Sent(msg.sender, receiver, amount);
@@ -77,13 +83,14 @@ contract Coin {
}
```
-Ten przykład powinien dać wyobrażenie o składni kontraktu Solidity. Bardziej szczegółowy opis funkcji i zmiennych znajdziesz [w dokumentacji](https://docs.soliditylang.org/en/latest/contracts.html).
+Ten przykład powinien dać wyobrażenie o składni kontraktu Solidity. Aby uzyskać bardziej szczegółowy opis funkcji i zmiennych, [zobacz dokumentację](https://docs.soliditylang.org/en/latest/contracts.html).
## Vyper {#vyper}
- Pythonowy język programowania
- Silne typowanie
- Niewielki i zrozumiały kod kompilatora
+- Efektywne generowanie kodu bajtowego
- Celowo ma mniej funkcji niż Solidity, aby zwiększyć bezpieczeństwo kontraktów i ułatwić ich audyt. Nieobsługiwane przez Vyper:
- Modyfikatory
- Dziedziczenie
@@ -92,105 +99,126 @@ Ten przykład powinien dać wyobrażenie o składni kontraktu Solidity. Bardziej
- Przeciążenie operatora
- Wywołania rekurencyjne
- Pętle o nieskończonej długości
- - Binarnej arytmetyki stałoprzecinkowej
+ - Binarne punkty stałe
-Aby uzyskać więcej informacji, [przeczytaj artykuł o podstawach Vypera](https://vyper.readthedocs.io/en/latest/index.html).
+Aby uzyskać więcej informacji, [przeczytaj uzasadnienie Vyper](https://vyper.readthedocs.io/en/latest/index.html).
### Ważne linki {#important-links-1}
- [Dokumentacja](https://vyper.readthedocs.io)
-- [Vyper w przykładach](https://vyper.readthedocs.io/en/latest/vyper-by-example.html)
+- [Vyper na przykładach](https://vyper.readthedocs.io/en/latest/vyper-by-example.html)
+- [Więcej przykładów Vyper](https://vyper-by-example.org/)
- [GitHub](https://github.com/vyperlang/vyper)
-- [Czat poświęcony Vyperowi na Gitterze](https://gitter.im/vyperlang/community)
+- [Czat Discord społeczności Vyper](https://discord.gg/SdvKC79cJk)
- [Ściągawka](https://reference.auditless.com/cheatsheet)
-- [Aktualizacja 8 stycznia 2020 r](https://blog.ethereum.org/2020/01/08/update-on-the-vyper-compiler)
+- [Frameworki i narzędzia do tworzenia inteligentnych kontraktów dla Vyper](/developers/docs/programming-languages/python/)
+- [VyperPunk - naucz się zabezpieczać i hakować inteligentne kontrakty Vyper](https://github.com/SupremacyTeam/VyperPunk)
+- [Centrum programistyczne Vyper](https://github.com/zcor/vyper-dev)
+- [Przykłady inteligentnych kontraktów Vyper – największe hity](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts)
+- [Awesome Vyper – wyselekcjonowane zasoby](https://github.com/spadebuilders/awesome-vyper)
### Przykład {#example}
```python
-# Open Auction
+# Otwarta aukcja
+
+# Parametry aukcji
+
+# Beneficjent otrzymuje pieniądze od licytującego, który złożył najwyższą ofertę
-# Auction params
-# Beneficiary receives money from the highest bidder
beneficiary: public(address)
auctionStart: public(uint256)
auctionEnd: public(uint256)
-# Current state of auction
+# Obecny stan aukcji
+
highestBidder: public(address)
highestBid: public(uint256)
-# Set to true at the end, disallows any change
+# Ustawiane na true na końcu, uniemożliwia wszelkie zmiany
+
ended: public(bool)
-# Keep track of refunded bids so we can follow the withdraw pattern
+# Śledzenie zwróconych ofert, abyśmy mogli postępować zgodnie ze wzorcem wypłaty
+
pendingReturns: public(HashMap[address, uint256])
-# Create a simple auction with `_bidding_time`
-# seconds bidding time on behalf of the
-# beneficiary address `_beneficiary`.
+# Utwórz prostą aukcję z czasem licytacji `_bidding_time`
+
+# sekund w imieniu
+
+# adresu beneficjenta `_beneficiary`.
+
@external
def __init__(_beneficiary: address, _bidding_time: uint256):
self.beneficiary = _beneficiary
self.auctionStart = block.timestamp
self.auctionEnd = self.auctionStart + _bidding_time
-# Bid on the auction with the value sent
-# together with this transaction.
-# The value will only be refunded if the
-# auction is not won.
+# Licytuj w aukcji z wartością wysłaną
+
+# razem z tą transakcją.
+
+# Wartość zostanie zwrócona tylko wtedy, gdy
+
+# aukcja nie zostanie wygrana.
@external
@payable
def bid():
- # Check if bidding period is over.
+ # Sprawdź, czy okres licytacji się skończył.
assert block.timestamp < self.auctionEnd
- # Check if bid is high enough
+ # Sprawdź, czy oferta jest wystarczająco wysoka
assert msg.value > self.highestBid
- # Track the refund for the previous high bidder
+ # Śledź zwrot dla poprzedniego licytującego z najwyższą ofertą
self.pendingReturns[self.highestBidder] += self.highestBid
- # Track new high bid
+ # Śledź nową wysoką ofertę
self.highestBidder = msg.sender
self.highestBid = msg.value
-# Withdraw a previously refunded bid. The withdraw pattern is
-# used here to avoid a security issue. If refunds were directly
-# sent as part of bid(), a malicious bidding contract could block
-# those refunds and thus block new higher bids from coming in.
+# Wypłać wcześniej zwróconą ofertę. Wzorzec wypłaty jest
+
+# używany tutaj w celu uniknięcia problemu z bezpieczeństwem. Gdyby zwroty były bezpośrednio
+
+# wysyłane w ramach bid(), złośliwy kontrakt licytacyjny mógłby zablokować
+
+# te zwroty, a tym samym zablokować napływ nowych, wyższych ofert.
+
@external
def withdraw():
pending_amount: uint256 = self.pendingReturns[msg.sender]
self.pendingReturns[msg.sender] = 0
send(msg.sender, pending_amount)
-# End the auction and send the highest bid
-# to the beneficiary.
+# Zakończ aukcję i wyślij najwyższą ofertę
+
+# do beneficjenta.
+
@external
def endAuction():
- # It is a good guideline to structure functions that interact
- # with other contracts (i.e., they call functions or send Ether)
- # into three phases:
- # 1. checking conditions
- # 2. performing actions (potentially changing conditions)
- # 3. interacting with other contracts
- # If these phases are mixed up, the other contract could call
- # back into the current contract and modify the state or cause
- # effects (ether payout) to be performed multiple times.
- # If functions called internally include interaction with external
- # contracts, they also have to be considered interaction with
- # external contracts.
-
- # 1. Conditions
- # Check if auction endtime has been reached
+ # Dobrą wytyczną jest strukturyzowanie funkcji, które wchodzą w interakcję
+ # z innymi kontraktami (tj. wywołują funkcje lub wysyłają ether)
+ # w trzech fazach:
+ # 1. sprawdzanie warunków
+ # 2. wykonywanie działań (potencjalnie zmieniających warunki)
+ # 3. interakcja z innymi kontraktami
+ # Jeśli te fazy są pomieszane, inny kontrakt może wywołać
+ # z powrotem bieżący kontrakt i zmodyfikować stan lub spowodować
+ # wielokrotne wykonanie efektów (wypłata etheru).
+ # Jeśli funkcje wywoływane wewnętrznie obejmują interakcję z zewnętrznymi
+ # kontraktami, muszą być również traktowane jako interakcja z
+ # kontraktami zewnętrznymi.
+
+ # 1. Warunki
+ # Sprawdź, czy osiągnięto czas zakończenia aukcji
assert block.timestamp >= self.auctionEnd
- # Check if this function has already been called
+ # Sprawdź, czy ta funkcja została już wywołana
assert not self.ended
- # 2.
- Effects
+ # 2. Efekty
self.ended = True
- # 3. Interaction
+ # 3. Interakcja
send(self.beneficiary, self.highestBid)
```
@@ -198,29 +226,30 @@ Ten przykład powinien dać wyobrażenie o składni kontraktu Vyper. Aby uzyska
## Yul i Yul+ {#yul}
-Jeśli dopiero zapoznajesz się z Ethereum i nie kodowałeś jeszcze w językach kontraktów inteligentnych, zalecamy rozpoczęcie pracy od Solidity lub Vyper. Zajrzyj do Yul lub Yul+ dopiero po zapoznaniu się z najlepszymi praktykami w zakresie bezpieczeństwa inteligentnych kontraktów i specyfiką pracy z EVM.
+Jeśli dopiero zapoznajesz się z Ethereum i nie kodowałeś jeszcze w językach inteligentnych kontraktów, zalecamy rozpoczęcie od Solidity lub Vyper. Przyjrzyj się Yul lub Yul+ dopiero po zapoznaniu się z najlepszymi praktykami w zakresie bezpieczeństwa inteligentnych kontraktów i specyfiką pracy z EVM.
**Yul**
- Język pośredni dla Ethereum.
-- Obsługuje [EVM](/developers/docs/evm) i [eWASM](https://github.com/ewasm), Ethereum flavored WebAssembly, zaprojektowany tak, aby był użytecznym wspólnym mianownikiem obu platform.
-- Dobry cel dla etapów optymalizacji wysokiego poziomu, które mogą przynieść korzyści zarówno platformom EVM, jak i eWASM.
+- Obsługuje [EVM](/developers/docs/evm) i [Ewasm](https://github.com/ewasm), czyli WebAssembly w stylu Ethereum, i jest zaprojektowany jako użyteczny wspólny mianownik dla obu platform.
+- Dobry cel dla etapów optymalizacji wysokiego poziomu, które mogą przynieść korzyści zarówno platformom EVM, jak i Ewasm.
**Yul+**
- Niskopoziomowe, bardzo wydajne rozszerzenie do Yul.
-- Początkowo zaprojektowany na potrzeby kontraktu typu [optymistyczna wartość zbiorcza](/developers/docs/scaling/).
+- Początkowo zaprojektowany dla kontraktu [rollup optymistyczny](/developers/docs/scaling/optimistic-rollups/).
- Yul+ można postrzegać jako eksperymentalną propozycję ulepszenia Yul, dodającą do niego nowe funkcje.
### Ważne linki {#important-links-2}
- [Dokumentacja Yul](https://docs.soliditylang.org/en/latest/yul.html)
- [Dokumentacja Yul+](https://github.com/fuellabs/yulp)
-- [Post wprowadzający do Yul+](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f)
+- [Wpis wprowadzający do Yul+](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f)
### Przykładowy kontrakt {#example-contract-2}
-Poniższy prosty przykład implementuje funkcję potęgową. Można go skompilować, używając `solc --strict-assembly --bin input.yul`. Przykład należy zapisać w pliku input.yul.
+Poniższy prosty przykład implementuje funkcję potęgową. Można go skompilować za pomocą `solc --strict-assembly --bin input.yul`. Przykład należy zapisać
+w pliku input.yul.
```
{
@@ -241,7 +270,45 @@ Poniższy prosty przykład implementuje funkcję potęgową. Można go skompilow
}
```
-Jeśli masz już duże doświadczenie w inteligentnych kontraktach, pełną implementację ERC20 w Yul znajdziesz [tutaj](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example).
+Jeśli masz już duże doświadczenie z inteligentnymi kontraktami, pełną implementację ERC20 w Yul można znaleźć [tutaj](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example).
+
+## Fe {#fe}
+
+- Statycznie typowany język dla maszyny wirtualnej Ethereum (EVM).
+- Zainspirowany Pythonem i Rustem.
+- Ma być łatwy do nauczenia — nawet dla deweloperów, którzy są nowicjuszami w ekosystemie Ethereum.
+- Rozwój Fe jest wciąż na wczesnym etapie, język miał swoją wersję alfa w styczniu 2021 roku.
+
+### Ważne linki {#important-links-3}
+
+- [GitHub](https://github.com/ethereum/fe)
+- [Ogłoszenie Fe](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/)
+- [Plan rozwoju Fe 2021](https://notes.ethereum.org/LVhaTF30SJOpkbG1iVw1jg)
+- [Czat Discord Fe](https://discord.com/invite/ywpkAXFjZH)
+- [Twitter Fe](https://twitter.com/official_fe)
+
+### Przykładowy kontrakt {#example-contract-3}
+
+Poniżej znajduje się prosty kontrakt zaimplementowany w Fe.
+
+```
+type BookMsg = bytes[100]
+
+contract GuestBook:
+ pub guest_book: map
+
+ event Signed:
+ book_msg: BookMsg
+
+ pub def sign(book_msg: BookMsg):
+ self.guest_book[msg.sender] = book_msg
+
+ emit Signed(book_msg=book_msg)
+
+ pub def get_msg(addr: address) -> BookMsg:
+ return self.guest_book[addr].to_mem()
+
+```
## Jak wybrać {#how-to-choose}
@@ -251,7 +318,7 @@ Oto kilka rzeczy do rozważenia, jeśli nie próbowałeś jeszcze żadnego z ję
### Co jest wspaniałego w Solidity? {#solidity-advantages}
-- Jeśli dopiero zaczynasz, jest tam wiele samouczków i narzędzi do nauki. Więcej informacji zawiera artykuł [Ucz się przez kodowanie](/developers/learning-tools/).
+- Jeśli dopiero zaczynasz, jest tam wiele samouczków i narzędzi do nauki. Zobacz więcej na ten temat w sekcji [Nauka przez kodowanie](/developers/learning-tools/).
- Dostępne dobre narzędzia programistyczne.
- Solidity ma dużą społeczność programistów, co oznacza, że najprawdopodobniej szybko znajdziesz odpowiedzi na swoje pytania.
@@ -268,9 +335,9 @@ Oto kilka rzeczy do rozważenia, jeśli nie próbowałeś jeszcze żadnego z ję
## Porównania języków {#language-comparisons}
-Aby porównać podstawową składnię, cykl życia kontraktu, interfejsy, operatory, struktury danych, funkcje, przepływ kontroli itd., sprawdź tę [ściągawkę firmy Auditless](https://reference.auditless.com/cheatsheet/)
+Aby porównać podstawową składnię, cykl życia kontraktu, interfejsy, operatory, struktury danych, funkcje, przepływ sterowania i nie tylko, sprawdź tę [ściągawkę od Auditless](https://reference.auditless.com/cheatsheet/)
## Dalsza lektura {#further-reading}
-- [Biblioteka Kontraktów Solidity autorstwa OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/)
-- [Solidity w przykładach](https://solidity-by-example.org)
+- [Biblioteka kontraktów Solidity od OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/)
+- [Solidity na przykładach](https://solidity-by-example.org)
diff --git a/public/content/translations/pl/developers/docs/smart-contracts/libraries/index.md b/public/content/translations/pl/developers/docs/smart-contracts/libraries/index.md
index 29438d0aa83..8a6eac5d49b 100644
--- a/public/content/translations/pl/developers/docs/smart-contracts/libraries/index.md
+++ b/public/content/translations/pl/developers/docs/smart-contracts/libraries/index.md
@@ -1,26 +1,26 @@
---
-title: Biblioteki inteligentnych kontraktów
-description:
+title: "Biblioteki inteligentnych kontraktów"
+description: "Odkryj biblioteki wielokrotnego użytku do inteligentnych kontraktów i części składowe, aby przyspieszyć programowanie Twoich projektów Ethereum."
lang: pl
---
Nie musisz pisać każdego inteligentnego kontraktu w swoim projekcie od zera. Istnieje wiele bibliotek open source inteligentnych kontraktów. Można w nich znaleźć elementy do utworzenia Twojego projektu, więc nie musisz wymyślać koła od nowa.
-## Warunki wstępne {#prerequisites}
+## Wymagania wstępne {#prerequisites}
-Przed przejściem do bibliotek inteligentnych kontraktów warto dobrze poznać strukturę inteligentnego kontraktu. Zapoznaj się z [anatomią inteligentnego kontraktu](/developers/docs/smart-contracts/anatomy/), jeśli jeszcze tego nie zrobiłeś.
+Przed przejściem do bibliotek inteligentnych kontraktów warto dobrze poznać strukturę inteligentnego kontraktu. Przejdź do [anatomii inteligentnych kontraktów](/developers/docs/smart-contracts/anatomy/), jeśli jeszcze tego nie zrobiłeś.
-## Co jest w bibliotece {#whats-in-a-library}
+## Co zawiera biblioteka {#whats-in-a-library}
-W bibliotekach inteligentnych kontraktów zwykle można znaleźć dwa rodzaje elementów konstrukcyjnych: zachowania wielokrotnego użytku, które możesz dodać do swoich kontraktów, oraz implementacje różnych standardów.
+W bibliotekach inteligentnych kontraktów zwykle można znaleźć dwa rodzaje elementów konstrukcyjnych: zachowania wielokrotnego użytku, które można dodać do swoich kontraktów, oraz implementacje różnych standardów.
### Zachowania {#behaviors}
-Podczas pisania inteligentnych kontraktów masz sporą szansę, że będziesz w nieskończoność zapisywać podobne wzorce, na przykład przypisywanie adresu _administratora_ w celu wykonania chronionych operacji w kontrakcie lub dodawanie awaryjnego przycisku _pauzy_ na wypadek nieoczekiwanego problemu.
+Pisząc inteligentne kontrakty, jest duża szansa, że będziesz wielokrotnie pisać podobne wzorce, takie jak przypisywanie adresu _administratora_ do wykonywania chronionych operacji w kontrakcie lub dodawanie przycisku awaryjnej _pauzy_ na wypadek nieoczekiwanego problemu.
-Biblioteki kontraktów inteligentnych zazwyczaj zapewniają wielokrotne implementacje tych zachowań jako [bibliotek](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries) lub przez [dziedziczenie](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance) w Solidity.
+Biblioteki inteligentnych kontraktów zwykle zapewniają implementacje tych zachowań wielokrotnego użytku jako [biblioteki](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries) lub poprzez [dziedziczenie](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance) w Solidity.
-Jako przykład poniżej znajduje się uproszczona wersja [kontraktu `Ownable`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol) z [biblioteki kontraktów OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts), która projektuje adres jako właściciela kontraktu oraz udostępnia modyfikator do ograniczania dostępu do metody tylko do tego właściciela.
+Jako przykład poniżej przedstawiono uproszczoną wersję [`kontraktu Ownable`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol) z [biblioteki kontraktów OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts), który wyznacza adres jako właściciela kontraktu i udostępnia modyfikator ograniczający dostęp do metody tylko temu właścicielowi.
```solidity
contract Ownable {
@@ -37,7 +37,7 @@ contract Ownable {
}
```
-Aby w kontrakcie użyć takiego bloku konstrukcyjnego, musisz go najpierw zaimportować, a następnie rozszerzyć na własny kontrakt. Pozwoli to na użycie modyfikatora dostarczonego przez kontrakt bazowy `Ownable` do zabezpieczenia własnych funkcji.
+Aby w kontrakcie użyć takiego bloku konstrukcyjnego, musisz go najpierw zaimportować, a następnie rozszerzyć na własny kontrakt. Pozwoli to na użycie modyfikatora dostarczonego przez bazowy kontrakt `Ownable` w celu zabezpieczenia własnych funkcji.
```solidity
import ".../Ownable.sol"; // ścieżka do zaimportowanego kontraktu
@@ -54,15 +54,15 @@ Innym popularnym przykładem jest [SafeMath](https://docs.openzeppelin.com/contr
### Standardy {#standards}
-Aby ułatwić [komponowalność i interoperacyjność](/developers/docs/smart-contracts/composability/), społeczność Ethereum zdefiniowała kilka standardów w postaci **ERC **. Więcej o nich można przeczytać w sekcji [standardy](/developers/docs/standards/).
+Aby ułatwić [komponowalność i interoperacyjność](/developers/docs/smart-contracts/composability/), społeczność Ethereum zdefiniowała kilka standardów w postaci **ERC**. Więcej na ich temat można przeczytać w sekcji [standardy](/developers/docs/standards/).
-W przypadku uwzględniania ERC w swoich kontraktach lepiej poszukać implementacji standardu niż próbować wdrożyć własną. Wiele bibliotek kontraktów inteligentnych zawiera implementacje dla najpopularniejszych ERC. Na przykład wszechobecny [standard tokenów wymiennych ERC20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) można znaleźć w [HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md), [DappSys](https://github.com/dapphub/ds-token/) i [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20). Ponadto niektóre ERC zapewniają również implementacje kanoniczne w ramach samego ERC.
+W przypadku uwzględniania ERC w swoich kontraktach lepiej poszukać implementacji standardu niż próbować wdrożyć własną. Wiele bibliotek kontraktów inteligentnych zawiera implementacje dla najpopularniejszych ERC. Na przykład wszechobecny [standard wymiennych tokenów ERC20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) można znaleźć w [HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md), [DappSys](https://github.com/dapphub/ds-token) i [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20). Ponadto niektóre ERC zapewniają również implementacje kanoniczne w ramach samego ERC.
Warto wspomnieć, że niektóre ERC nie są samodzielne, ale stanowią uzupełnienie innych ERC. Na przykład [ERC2612](https://eips.ethereum.org/EIPS/eip-2612) dodaje rozszerzenie do ERC20 w celu poprawy jego użyteczności.
## Jak dodać bibliotekę {#how-to}
-Zawsze zapoznaj się z dokumentacją dołączanej biblioteki, aby uzyskać szczegółowe instrukcje, jak uwzględnić ją w swoim projekcie. Kilka bibliotek kontraktów Solidity jest spakowanych za pomocą aplikacji `npm`, więce można po prostu użyć polecenia `npm install`. Większość narzędzi do [kompilowania](/developers/docs/smart-contracts/compiling/) kontraktów będzie szukać bibliotek kontraktów inteligentnych w Twoich `node_modules`, więc możesz wykonać następujące czynności:
+Zawsze zapoznaj się z dokumentacją dołączanej biblioteki, aby uzyskać szczegółowe instrukcje, jak uwzględnić ją w swoim projekcie. Wiele bibliotek kontraktów Solidity jest spakowanych przy użyciu `npm`, więc można je po prostu zainstalować za pomocą `npm install`. Większość narzędzi do [kompilowania](/developers/docs/smart-contracts/compiling/) kontraktów będzie szukać bibliotek inteligentnych kontraktów w `node_modules`, więc możesz wykonać następujące czynności:
```solidity
// to spowoduje wczytanie biblioteki @openzeppelin/contracts library z node_modules
@@ -73,13 +73,13 @@ contract MyNFT is ERC721 {
}
```
-Niezależnie od używanej metody, dołączając bibliotekę, zawsze uważaj na wersję [językową](/developers/docs/smart-contracts/languages/). Na przykład, nie możesz użyć biblioteki dla Solidity 0.6, jeśli piszesz swoje kontrakty w Solidity 0.5.
+Niezależnie od używanej metody, dołączając bibliotekę, zawsze zwracaj uwagę na wersję [języka](/developers/docs/smart-contracts/languages/). Na przykład, nie możesz użyć biblioteki dla Solidity 0.6, jeśli piszesz swoje kontrakty w Solidity 0.5.
-## Kiedy użyć {#when-to-use}
+## Kiedy używać {#when-to-use}
Korzystanie z biblioteki inteligentnych kontraktów w projekcie ma kilka zalet. Przede wszystkim oszczędza czas, dostarczając gotowe do użycia bloki konstrukcyjne, które możesz dołączyć do swojego systemu, zamiast samodzielnie je kodować.
-Dużym plusem jest także bezpieczeństwo. Biblioteki inteligentnych kontraktów typu open source są również często poddawane szczegółowej analizie. Biorąc pod uwagę, że wiele projektów od nich zależy, społeczność ma silną motywację do ciągłego ich sprawdzania. Znacznie częściej można znaleźć błędy w kodzie aplikacji niż w bibliotekach kontraktów wielokrotnego użytku. Niektóre biblioteki przechodzą również [kontrole zewnętrzne](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audit) w celu dodatkowego zabezpieczenia.
+Dużym plusem jest także bezpieczeństwo. Biblioteki inteligentnych kontraktów typu open source są również często poddawane szczegółowej analizie. Biorąc pod uwagę, że wiele projektów od nich zależy, społeczność ma silną motywację do ciągłego ich sprawdzania. Znacznie częściej można znaleźć błędy w kodzie aplikacji niż w bibliotekach kontraktów wielokrotnego użytku. Niektóre biblioteki przechodzą również [zewnętrzne audyty](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits) w celu zapewnienia dodatkowego bezpieczeństwa.
Jednak korzystanie z bibliotek inteligentnych kontraktów niesie ze sobą ryzyko włączenia do projektu kodu, którego nie znasz. Zaimportowanie kontraktu i włączenie go bezpośrednio do projektu jest kuszące, ale bez dobrego zrozumienia tego, co robi ten kontrakt, możesz nieumyślnie wprowadzić problem do swojego systemu z powodu nieoczekiwanego zachowania. Zawsze upewnij się, że przeczytałeś dokumentację importowanego kodu, a następnie przejrzyj sam kod przed włączeniem go do swojego projektu!
@@ -87,26 +87,31 @@ Na koniec, podejmując decyzję o włączeniu biblioteki, weź pod uwagę jej og
## Powiązane narzędzia {#related-tools}
-**Kontrakty OpenZeppelin —** **_najpopularniejsza biblioteka do bezpiecznego tworzenia inteligentnych kontraktów._ **
+**OpenZeppelin Contracts –** **_najpopularniejsza biblioteka do bezpiecznego tworzenia inteligentnych kontraktów._**
- [Dokumentacja](https://docs.openzeppelin.com/contracts/)
- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts)
- [Forum społeczności](https://forum.openzeppelin.com/c/general/16)
-**DappSys —** **_bezpieczne, proste, elastyczne elementy konstrukcyjne do inteligentnych kontraktów._**
+**DappSys –** **_bezpieczne, proste i elastyczne elementy konstrukcyjne dla inteligentnych kontraktów._**
- [Dokumentacja](https://dappsys.readthedocs.io/)
- [GitHub](https://github.com/dapphub/dappsys)
-**HQ20 —** **_projekt Solidity z kontraktami, bibliotekami i przykładami, które pomogą Ci stworzyć w pełni wyposażone aplikacje zdecentralizowane dla świata rzeczywistego._**
+**HQ20 –** **_projekt Solidity z kontraktami, bibliotekami i przykładami, które pomogą Ci zbudować w pełni funkcjonalne, zdecentralizowane aplikacje dla realnego świata._**
- [GitHub](https://github.com/HQ20/contracts)
+**thirdweb Solidity SDK –** **_zapewnia narzędzia potrzebne do wydajnego tworzenia niestandardowych inteligentnych kontraktów_**
+
+- [Dokumentacja](https://portal.thirdweb.com/contracts/build/overview)
+- [GitHub](https://github.com/thirdweb-dev/contracts)
+
## Powiązane samouczki {#related-tutorials}
-- [Zagadnienia bezpieczeństwa dla programistów Ethereum](/developers/docs/smart-contracts/security/) _– samouczek na temat zagadnień bezpieczeństwa podczas tworzenia inteligentnych kontraktów, z uwzględnieniem korzystania z bibliotek._
-- [Informacje o kontraktach inteligentnych tokena ERC-20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _— samouczek dotyczący standardu ERC20 oferowanego przez wiele bibliotek._
+- [Zagadnienia bezpieczeństwa dla deweloperów Ethereum](/developers/docs/smart-contracts/security/) _– samouczek na temat zagadnień bezpieczeństwa podczas tworzenia inteligentnych kontraktów, z uwzględnieniem korzystania z bibliotek._
+- [Zrozumienie inteligentnego kontraktu tokena ERC-20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– samouczek na temat standardu ERC20, udostępniany przez wiele bibliotek._
## Dalsza lektura {#further-reading}
-_Znasz jakieś zasoby społeczności, które Ci pomogły? Wyedytuj tę stronę i dodaj je!_
+_Znasz jakieś zasoby społeczności, które Ci pomogły? Edytuj tę stronę i dodaj je!_
diff --git a/public/content/translations/pl/developers/docs/smart-contracts/naming/index.md b/public/content/translations/pl/developers/docs/smart-contracts/naming/index.md
new file mode 100644
index 00000000000..62364feab75
--- /dev/null
+++ b/public/content/translations/pl/developers/docs/smart-contracts/naming/index.md
@@ -0,0 +1,101 @@
+---
+title: "Nazywanie inteligentnych kontraktów"
+description: "Najlepsze praktyki nazywania inteligentnych kontraktów Ethereum za pomocą ENS"
+lang: pl
+---
+
+Inteligentne kontrakty są podstawą zdecentralizowanej infrastruktury Ethereum, umożliwiając tworzenie autonomicznych aplikacji i protokołów. Jednak nawet w miarę ewolucji możliwości kontraktów użytkownicy i deweloperzy wciąż polegają na surowych adresach szesnastkowych do identyfikacji i odwoływania się do tych kontraktów.
+
+Nazywanie inteligentnych kontraktów za pomocą [Usługi nazw Ethereum (ENS)](https://ens.domains/) poprawia doświadczenie użytkownika poprzez eliminację szesnastkowych adresów kontraktów i zmniejsza ryzyko ataków, takich jak zatruwanie adresów i ataki typu spoofing. Ten poradnik wyjaśnia, dlaczego nazywanie inteligentnych kontraktów jest ważne, jak można to wdrożyć oraz jakie narzędzia, takie jak [Enscribe](https://www.enscribe.xyz), są dostępne, aby uprościć ten proces i pomóc deweloperom wdrożyć tę praktykę.
+
+## Dlaczego nazywać inteligentne kontrakty? {#why-name-contracts}
+
+### Identyfikatory czytelne dla człowieka {#human-readable-identifiers}
+
+Zamiast wchodzić w interakcje z nieprzejrzystymi adresami kontraktów, takimi jak `0x8f8e...f9e3`, deweloperzy i użytkownicy mogą używać czytelnych dla człowieka nazw, takich jak `v2.myapp.eth`. To upraszcza interakcje z inteligentnymi kontraktami.
+
+Jest to możliwe dzięki [Usłudze nazw Ethereum](https://ens.domains/), która zapewnia zdecentralizowaną usługę nazewnictwa dla adresów Ethereum. Jest to analogiczne do sposobu, w jaki System Nazw Domen (DNS) umożliwia użytkownikom internetu dostęp do adresów sieciowych za pomocą nazwy, takiej jak ethereum.org, zamiast adresu IP, takiego jak `104.18.176.152`.
+
+### Poprawa bezpieczeństwa i zaufania {#improved-security-and-trust}
+
+Nazwane kontrakty pomagają zredukować liczbę przypadkowych transakcji na zły adres. Pomagają również użytkownikom identyfikować kontrakty powiązane z określonymi aplikacjami lub markami. Dodaje to warstwę zaufania opartego na reputacji, zwłaszcza gdy nazwy są dołączone do znanych domen nadrzędnych, takich jak `uniswap.eth`.
+
+Ze względu na 42-znakową długość adresu Ethereum, użytkownikom bardzo trudno jest zidentyfikować niewielkie zmiany w adresach, w których zmodyfikowano kilka znaków. Na przykład adres taki jak `0x58068646C148E313CB414E85d2Fe89dDc3426870` zostałby normalnie skrócony do `0x580...870` przez aplikacje dla użytkowników, takie jak portfele. Jest mało prawdopodobne, że użytkownik zauważy złośliwy adres, w którym zmieniono kilka znaków.
+
+Ten rodzaj techniki jest wykorzystywany w atakach typu spoofing i zatruwania adresów, w których użytkownicy są wprowadzani w błąd, że wchodzą w interakcję lub wysyłają środki na właściwy adres, podczas gdy w rzeczywistości adres ten tylko przypomina właściwy adres, ale nie jest taki sam.
+
+Nazwy ENS dla portfeli i kontraktów chronią przed tego typu atakami. Podobnie jak ataki typu DNS spoofing, ataki typu ENS spoofing również mogą mieć miejsce, jednak użytkownik z większym prawdopodobieństwem zauważy błąd w nazwie ENS niż niewielką modyfikację w adresie szesnastkowym.
+
+### Lepszy UX dla portfeli i eksploratorów {#better-ux}
+
+Gdy inteligentny kontrakt został skonfigurowany z nazwą ENS, aplikacje, takie jak portfele i eksploratory blockchain, mogą wyświetlać nazwy ENS dla inteligentnych kontraktów zamiast adresów szesnastkowych. Zapewnia to znaczną poprawę doświadczenia użytkownika (UX).
+
+Na przykład, podczas interakcji z aplikacją taką jak Uniswap, użytkownicy zazwyczaj widzą, że aplikacja, z którą wchodzą w interakcję, jest hostowana na stronie internetowej `uniswap.org`, ale zostanie im przedstawiony szesnastkowy adres kontraktu, jeśli Uniswap nie nazwał swoich inteligentnych kontraktów za pomocą ENS. Jeśli kontrakt jest nazwany, zamiast tego mogliby zobaczyć `v4.contracts.uniswap.eth`, co jest o wiele bardziej użyteczne.
+
+## Nazywanie podczas wdrożenia a nazywanie po wdrożeniu {#when-to-name}
+
+Istnieją dwa momenty, w których można nadać nazwę inteligentnym kontraktom:
+
+- **W momencie wdrożenia**: przypisanie nazwy ENS do kontraktu w trakcie jego wdrażania.
+- **Po wdrożeniu**: mapowanie istniejącego adresu kontraktu na nową nazwę ENS.
+
+Oba podejścia opierają się na posiadaniu dostępu właściciela lub menedżera do domeny ENS, aby móc tworzyć i ustawiać rekordy ENS.
+
+## Jak działa nazywanie kontraktów za pomocą ENS {#how-ens-naming-works}
+
+Nazwy ENS są przechowywane w łańcuchu i są rozwiązywane na adresy Ethereum za pomocą resolverów ENS. Aby nadać nazwę inteligentnemu kontraktowi:
+
+1. Zarejestruj lub kontroluj nadrzędną domenę ENS (np. `myapp.eth`)
+2. Utwórz subdomenę (np. `v1.myapp.eth`)
+3. Ustaw rekord `address` subdomeny na adres kontraktu
+4. Ustaw rekord odwrotny kontraktu na ENS, aby umożliwić znalezienie nazwy za pomocą jej adresu
+
+Nazwy ENS są hierarchiczne i obsługują nieograniczoną liczbę subdomen. Ustawianie tych rekordów zazwyczaj wiąże się z interakcją z kontraktami rejestru ENS i publicznego resolvera.
+
+## Narzędzia do nazywania kontraktów {#tools}
+
+Istnieją dwa podejścia do nazywania inteligentnych kontraktów. Można użyć [aplikacji ENS](https://app.ens.domains), wykonując kilka ręcznych kroków, lub użyć [Enscribe](https://www.enscribe.xyz). Zostały one opisane poniżej.
+
+### Ręczna konfiguracja ENS {#manual-ens-setup}
+
+Korzystając z [aplikacji ENS](https://app.ens.domains/), deweloperzy mogą ręcznie tworzyć subdomeny i ustawiać rekordy adresu docelowego. Nie mogą jednak ustawić podstawowej nazwy dla inteligentnego kontraktu poprzez ustawienie rekordu odwrotnego dla nazwy za pośrednictwem aplikacji ENS. Należy wykonać ręczne kroki, które są opisane w [dokumentacji ENS](https://docs.ens.domains/web/naming-contracts/).
+
+### Enscribe {#enscribe}
+
+[Enscribe](https://www.enscribe.xyz) upraszcza nazywanie inteligentnych kontraktów za pomocą ENS i zwiększa zaufanie użytkowników do inteligentnych kontraktów. Zapewnia:
+
+- **Atomowe wdrożenie i nazwanie**: przypisz nazwę ENS podczas wdrażania nowego kontraktu
+- **Nazywanie po wdrożeniu**: dołączanie nazw do już wdrożonych kontraktów
+- **Obsługa wielu łańcuchów**: działa w sieciach Ethereum i L2, w których obsługiwane jest ENS
+- **Dane weryfikacyjne kontraktu**: zawiera dane weryfikacyjne kontraktu pobierane z wielu źródeł w celu zwiększenia zaufania użytkowników
+
+Enscribe obsługuje nazwy ENS dostarczone przez użytkowników lub własne domeny, jeśli użytkownik nie ma nazwy ENS.
+
+Możesz uzyskać dostęp do [aplikacji Enscribe](https://app.enscribe.xyz), aby rozpocząć nazywanie i przeglądanie inteligentnych kontraktów.
+
+## Najlepsze praktyki {#best-practices}
+
+- **Używaj jasnych, wersjonowanych nazw**, takich jak `v1.myapp.eth`, aby aktualizacje kontraktów były przejrzyste
+- **Ustaw rekordy odwrotne**, aby połączyć kontrakty z nazwami ENS w celu zapewnienia widoczności w aplikacjach, takich jak portfele i eksploratory blockchain.
+- **Dokładnie monitoruj daty wygaśnięcia**, jeśli chcesz zapobiec przypadkowym zmianom własności
+- **Weryfikuj źródło kontraktu**, aby użytkownicy mogli ufać, że nazwany kontrakt zachowuje się zgodnie z oczekiwaniami
+
+## Zagrożenia {#risks}
+
+Nazywanie inteligentnych kontraktów zapewnia znaczne korzyści dla użytkowników Ethereum, jednak właściciele domen ENS muszą być czujni w odniesieniu do zarządzania nimi. Do istotnych zagrożeń należą:
+
+- **Wygaśnięcie**: podobnie jak w przypadku nazw DNS, rejestracje nazw ENS mają ograniczony czas trwania. Dlatego ważne jest, aby właściciele monitorowali daty wygaśnięcia swoich domen i odnawiali je z dużym wyprzedzeniem. Zarówno aplikacja ENS, jak i Enscribe zapewniają właścicielom domen wizualne wskaźniki zbliżającego się terminu wygaśnięcia.
+- **Zmiana właściciela**: rekordy ENS są reprezentowane jako NFT na Ethereum, gdzie właściciel określonej domeny `.eth` posiada powiązane z nią NFT. Dlatego też, jeśli inne konto przejmie własność tego NFT, nowy właściciel może modyfikować dowolne rekordy ENS według własnego uznania.
+
+Aby złagodzić takie ryzyko, konto właściciela domen `.eth` drugiego poziomu (2LD) powinno być zabezpieczone za pomocą portfela multi-sig, a do zarządzania nazwami kontraktów powinny być tworzone subdomeny. W ten sposób w przypadku jakichkolwiek przypadkowych lub złośliwych zmian własności na poziomie subdomeny mogą one zostać nadpisane przez właściciela 2LD.
+
+## Przyszłość nazywania kontraktów {#future}
+
+Nazywanie kontraktów staje się najlepszą praktyką w rozwoju dappek, podobnie jak nazwy domen zastąpiły adresy IP w internecie. W miarę jak coraz więcej elementów infrastruktury, takich jak portfele, eksploratory i pulpity nawigacyjne, będzie integrować rozwiązywanie nazw ENS dla kontraktów, nazwane kontrakty poprawią bezpieczeństwo i zmniejszą liczbę błędów w całym ekosystemie.
+
+Ułatwiając rozpoznawanie i rozumowanie inteligentnych kontraktów, nadawanie im nazw pomaga zmniejszyć lukę między użytkownikami a aplikacjami na Ethereum, poprawiając zarówno bezpieczeństwo, jak i wrażenia użytkownika (UX).
+
+## Dalsza lektura {#further-reading}
+
+- [Nazywanie inteligentnych kontraktów za pomocą ENS](https://docs.ens.domains/web/naming-contracts/)
+- [Nazywanie inteligentnych kontraktów za pomocą Enscribe](https://www.enscribe.xyz/docs).
diff --git a/public/content/translations/pl/developers/docs/smart-contracts/security/index.md b/public/content/translations/pl/developers/docs/smart-contracts/security/index.md
new file mode 100644
index 00000000000..25509d59307
--- /dev/null
+++ b/public/content/translations/pl/developers/docs/smart-contracts/security/index.md
@@ -0,0 +1,576 @@
+---
+title: "Bezpieczeństwo inteligentnych kontraktów"
+description: "Przegląd wskazówek dotyczących tworzenia bezpiecznych inteligentnych kontraktów Ethereum"
+lang: pl
+---
+
+Inteligentne kontrakty są ekstremalnie elastyczne oraz zdolne kontrolować duże ilości wartości oraz danych oraz dane stosując niezmienną logikę opartą na kodzie wdrożonym na blockchainie. Powstał dzięki temu tętniący życiem ekosystem niewymagających zaufania i zdecentralizowanych aplikacji, które zapewniają szereg przewag wobec przestarzałych systemów. Stwarzają one również okazje dla napastników szukających zysku poprzez wykorzystanie słabych punktów inteligentnych kontraktów.
+
+Publiczne blockchainy takie jak Ethereum, jeszcze bardziej komplikują zagadnienie zabezpieczeń inteligentnych kontraktów. Kod wdrożonego kontraktu _zazwyczaj_ nie może zostać zmieniony w celu załatania luk w zabezpieczeniach, podczas gdy aktywa skradzione z inteligentnych kontraktów są niezwykle trudne do wyśledzenia i w większości nie do odzyskania ze względu na niezmienność.
+
+Źródła podają różne kwoty, ale można oszacować, że suma środków skradzionych lub straconych w wyniku defektów zabezpieczeń w inteligentnych kontraktach przekracza 1 miliard dolarów. Obejmuje to głośne incydenty, takie jak [atak na DAO](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/) (skradziono 3,6 mln ETH, wartych dziś ponad 1 mld USD), [atak na portfel wielopodpisowy Parity](https://www.coindesk.com/markets/2017/07/19/30-million-ether-reported-stolen-due-to-parity-wallet-breach) (hakerzy ukradli 30 mln USD) oraz [problem z zamrożonym portfelem Parity](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether) (ponad 300 mln USD w ETH zablokowane na zawsze).
+
+Wspomniane wcześniej problemy stwarzają programistom konieczność poświęcania uwagi i środków na tworzenie zabezpieczonych, solidnych i odpornych inteligentnych kontraktów. Bezpieczeństwo inteligentnych kontraktów jest poważną sprawą, o której powinien uczyć się każdy programista. W tym przewodniku omówione zostaną zagadnienia związane z bezpieczeństwem skierowane dla programistów Ethereum oraz zasoby ulepszania zabezpieczeń inteligentnych kontraktów.
+
+## Wymagania wstępne {#prerequisites}
+
+Przed zajęciem się kwestiami bezpieczeństwa upewnij się, że znasz [podstawy tworzenia inteligentnych kontraktów](/developers/docs/smart-contracts/).
+
+## Wytyczne dotyczące budowania bezpiecznych inteligentnych kontraktów Ethereum {#smart-contract-security-guidelines}
+
+### 1. Zaprojektuj odpowiednie mechanizmy kontroli dostępu {#design-proper-access-controls}
+
+W inteligentnych kontraktach funkcje oznaczone jako `public` lub `external` mogą być wywoływane przez dowolne konta zewnętrzne (EOA) lub konta kontraktowe. Określenie publicznej widoczności funkcji jest konieczne, jeśli chcesz, aby inni mogli wchodzić w interakcje z twoim kontraktem. Funkcje oznaczone jako `private` mogą być jednak wywoływane tylko przez funkcje w ramach danego inteligentnego kontraktu, a nie przez konta zewnętrzne. Udzielanie każdemu użytkownikowi sieci dostępu do funkcji kontraktu może stwarzać problemy, szczególnie jeśli oznacza to, że każdy może przeprowadzać wrażliwe czynności (np. mintowanie nowych tokenów).
+
+Aby uniemożliwić nieautoryzowane użycie funkcji inteligentnego kontraktu, niezbędna jest implementacja zabezpieczeń kontroli dostępu. Mechanizmy kontroli dostępu ograniczają możliwość użycia określonych funkcji inteligentnego kontraktu podmiotom innym niż aprobowane, czyli te konta, które odpowiedzialne są za zarządzanie kontraktem. Wzorce **Ownable** oraz **kontroli opartej na rolach** to dwa przydatne schematy implementacji kontroli dostępu w inteligentnych kontraktach:
+
+#### Wzorzec Ownable {#ownable-pattern}
+
+We wzorcu własności, adres oznaczony jest jako "właściciel" kontraktu podczas procesu tworzenia kontraktu. Funkcje chronione mają przypisany modyfikator `OnlyOwner`, który zapewnia, że kontrakt uwierzytelnia tożsamość adresu wywołującego przed wykonaniem funkcji. Wywołania funkcji objętych ochroną pochodzące od innych adresów oprócz właściciela kontraktu są zawsze pomijane, co uniemożliwia niechciany dostęp.
+
+#### Kontrola dostępu oparta na rolach {#role-based-access-control}
+
+Zarejestrowanie pojedynczego adresu jako `Owner` w inteligentnym kontrakcie wprowadza ryzyko centralizacji i stanowi pojedynczy punkt awarii. Jeśli klucze dostępu konta właściciela wpadną w niepowołane ręce, napastnicy mogą zaatakować kontrakt objęty własnością. Dlatego wykorzystanie wzorca dostępu opartego na rolach dla kilku kont administratorów może być lepszym rozwiązaniem.
+
+W przypadku kontroli dostępu opartej na rolach dostęp do wrażliwych funkcji jest rozdysponowany pomiędzy zaufanymi uczestnikami. Na przykład jedno konto może być odpowiedzialne za mintowanie tokenów, a inne może mieć możliwość zatrzymania kontraktu lub jego aktualizacji. Decentralizowanie kontroli dostępu w taki sposób, eliminuje pojedyncze punkty awarii i ogranicza potrzebę użytkowników do powierzania zaufania.
+
+##### Używanie portfelu multisig
+
+Innym podejściem do implementacji bezpiecznej kontroli dostępu jest użycie [konta z wieloma podpisami](/developers/docs/smart-contracts/#multisig) do zarządzania kontraktem. W przeciwieństwie do EOA, konta multisig mają kilku właścicieli i wymagają podpisów od określonej minimalnej liczby kont — na przykład 3 z 5 — aby wykonać transakcję.
+
+Używanie multisig do kontroli dostępu wprowadza dodatkową warstwę bezpieczeństwa, ponieważ czynności na docelowym kontrakcie wymagają zgody kilku stron. Jest to szczególnie użyteczne, kiedy wykorzystanie wzorca własności jest niezbędne, ponieważ czyni on manipulacje wrażliwymi funkcjami kontraktu w złośliwych celach trudniejszymi dla napastnika czy wewnętrznego sabotażysty.
+
+### 2. Używaj instrukcji require(), assert() i revert() do ochrony operacji kontraktowych {#use-require-assert-revert}
+
+Jak wspomniano, każdy może wywoływać funkcje publiczne w inteligentnym kontrakcie po jego wdrożeniu w blockchainie. Ponieważ nie można z góry przewidzieć, w jaki sposób konta zewnętrzne będą oddziaływać na umowę, najlepszym rozwiązaniem jest wdrożenie wewnętrznych zabezpieczeń chroniących przed problematycznymi operacjami przed wdrożeniem. Możesz wymusić poprawne zachowanie w inteligentnych kontraktach za pomocą instrukcji `require()`, `assert()` i `revert()`, aby wywoływać wyjątki i cofać zmiany stanu, jeśli wykonanie nie spełni określonych wymagań.
+
+**`require()`**: Instrukcje `require` są definiowane na początku funkcji i zapewniają, że określone warunki są spełnione, zanim wywołana funkcja zostanie wykonana. Instrukcja `require` może być użyta do walidacji danych wejściowych użytkownika, sprawdzania zmiennych stanu lub uwierzytelniania tożsamości konta wywołującego przed kontynuowaniem wykonania funkcji.
+
+**`assert()`**: `assert()` służy do wykrywania błędów wewnętrznych i sprawdzania naruszeń „niezmienników” w kodzie. Niezmiennik to logiczne założenie dotyczące stanu kontraktu, które powinno być prawdziwe dla wszystkich możliwych wykonań funkcji. Przykładowym niezmiennikiem jest maksymalna podaż całkowita lub saldo w kontrakcie tokena. Użycie `assert()` zapewnia, że kontrakt nigdy nie osiągnie stanu podatności na ataki, a jeśli tak się stanie, wszystkie zmiany w zmiennych stanu zostaną wycofane.
+
+**`revert()`**: `revert()` może być użyte w instrukcji if-else, która wywołuje wyjątek, jeśli wymagany warunek nie jest spełniony. Poniższy przykładowy kontrakt wykorzystuje `revert()` do ochrony wykonywania funkcji:
+
+```
+pragma solidity ^0.8.4;
+
+contract VendingMachine {
+ address owner;
+ error Unauthorized();
+ function buy(uint amount) public payable {
+ if (amount > msg.value / 2 ether)
+ revert("Za mało Etheru.");
+ // Dokonaj zakupu.
+ }
+ function withdraw() public {
+ if (msg.sender != owner)
+ revert Unauthorized();
+
+ payable(msg.sender).transfer(address(this).balance);
+ }
+}
+```
+
+### 3. Testuj inteligentne kontrakty i weryfikuj poprawność kodu {#test-smart-contracts-and-verify-code-correctness}
+
+Niezmienność kodu działającego w [Wirtualnej Maszynie Ethereum](/developers/docs/evm/) oznacza, że inteligentne kontrakty wymagają wyższego poziomu oceny jakości na etapie rozwoju. Dokładne testowane kontraktu i obserwowanie go w celu wychwycenia wszelkich nieoczekiwanych rezultatów, wzmocni znacząco jego bezpieczeństwo i, w dłuższym okresie, ochroni użytkowników.
+
+Standardową metodą jest pisanie małych testów jednostkowych, używając nieprawdziwych danych, które powinny zostać dostarczone do kontraktu przez użytkowników. [Testowanie jednostkowe](/developers/docs/smart-contracts/testing/#unit-testing) jest dobre do testowania funkcjonalności poszczególnych funkcji i upewniania się, że inteligentny kontrakt działa zgodnie z oczekiwaniami.
+
+Niestety testowanie jednostkowe jest niezbyt efektywne w kwestii zwiększania poziomu zabezpieczenia inteligentnego kontraktu, kiedy stosuje się je jako jedyną metodę. Test jednostkowy może dowieźć, że funkcja działa poprawnie dla nieprawdziwych danych, ale skuteczność testów jednostkowych ogranicza się do jakości napisanych testów. To zwiększa trudność wykrycia pominiętych przypadków granicznych czy słabych punktów, których wykorzystanie może złamać zabezpieczenia inteligentnego kontraktu.
+
+Lepszym podejściem jest połączenie testowania jednostkowego z testowaniem opartym na właściwościach, przeprowadzanym przy użyciu [analizy statycznej i dynamicznej](/developers/docs/smart-contracts/testing/#static-dynamic-analysis). Analiza statyczna opiera się na reprezentacjach niskiego poziomu, takich jak [grafy przepływu sterowania](https://en.wikipedia.org/wiki/Control-flow_graph) i [abstrakcyjne drzewa składni](https://deepsource.io/glossary/ast/), w celu analizy osiągalnych stanów programu i ścieżek wykonania. Tymczasem techniki analizy dynamicznej, takie jak [fuzzing inteligentnych kontraktów](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry), wykonują kod kontraktu z losowymi wartościami wejściowymi w celu wykrycia operacji naruszających właściwości bezpieczeństwa.
+
+[Weryfikacja formalna](/developers/docs/smart-contracts/formal-verification) to kolejna technika weryfikacji właściwości bezpieczeństwa w inteligentnych kontraktach. W przeciwieństwie do zwykłego testowania weryfikacja formalna może jednoznacznie dowieźć braku obecności błędów w inteligentnym kontrakcie. Osiąga się to poprzez tworzenie formalnej specyfikacji, która określa pożądane właściwości zabezpieczeń i dowodzi, że model formalny kontraktów spełnia założenia tej specyfikacji.
+
+### 4. Poproś o niezależny przegląd swojego kodu {#get-independent-code-reviews}
+
+Po przetestowaniu kontraktu dobrze jest poprosić innego programistę o sprawdzenie kodu źródłowego w celu wykrycia problemów dotyczących zabezpieczeń. Testowanie nie odkryje każdej wady inteligentnego kontraktu, ale zapewnienie niezależnej recenzji zwiększy prawdopodobieństwo wykrycia słabych punktów.
+
+#### Audyty {#audits}
+
+Zlecenie audytu inteligentnego kontraktu jest jednym ze sposobów na przeprowadzenie niezależnej recenzji kodu. Audytorzy odgrywają ważną rolę w zapewnieniu bezpieczeństwa inteligentnemu kontraktowi oraz sprzyjają pozbyciu się defektów i błędów projektowych.
+
+Nie powinno to jednak doprowadzić do sytuacji, w której audyty stanowią jedyne zastosowane rozwiązanie. Audyty inteligentnych kontraktów nie wyłapią każdego błędu i są głównie zaprojektowane, aby zapewnić dodatkowy cykl recenzji, który może pomóc w wykryciu problemów przeoczonych przez programistów podczas początkowych etapów programowania oraz testów. Powinno się również stosować do najlepszych praktyk we współpracy z audytorami, które obejmują odpowiednie dokumentowanie kodu oraz dodawanie komentarzy w celu maksymalizacji korzyści płynących z audytu inteligentnego kontraktu.
+
+- [Porady i wskazówki dotyczące audytu inteligentnych kontraktów](https://twitter.com/tinchoabbate/status/1400170232904400897) – _@tinchoabbate_
+- [Wykorzystaj w pełni swój audyt](https://inference.ag/blog/2023-08-14-tips/) – _Inference_
+
+#### Nagrody za znalezienie błędów {#bug-bounties}
+
+Zorganizowanie programu nagród za znalezienie błędu jest kolejnym podejściem do wdrożenia zewnętrznych recenzji kodu. Nagroda za znalezienie błędu jest finansową gratyfikacją przyznawaną osobom (zwykle hakerom w białych kapeluszach), które wykryją słabe punkty aplikacji.
+
+Gdy są odpowiednio wykorzystane, nagrody za znalezienie błędu dają członkom społeczności hakerskiej zachętę do inspekcji kodu pod kątem wad krytycznych. Przykładem z życia wziętym jest „błąd nieskończonej ilości pieniędzy”, który pozwoliłby atakującemu na stworzenie nieograniczonej ilości etheru na [Optimism](https://www.optimism.io/), protokole [Warstwy 2](/layer-2/) działającym na Ethereum. Na szczęście haker w białym kapeluszu [odkrył tę wadę](https://www.saurik.com/optimism.html) i powiadomił zespół, [otrzymując przy tym dużą nagrodę](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/).
+
+Przydatną strategią jest ustalanie wysokości nagrody w proporcji do wartości zagrożonych środków. Podejście to, określane mianem „[skalowalnych nagród za błędy](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)”, zapewnia zachęty finansowe dla osób, które w sposób odpowiedzialny ujawniają luki w zabezpieczeniach, zamiast je wykorzystywać.
+
+### 5. Postępuj zgodnie z najlepszymi praktykami podczas tworzenia inteligentnych kontraktów {#follow-smart-contract-development-best-practices}
+
+Istnienie audytów i programów nagród za znalezienie błędu nie zwalnia z odpowiedzialności za pisanie kodu wysokiej jakości. Dobre zabezpieczenie inteligentnego kontraktu zaczyna się na etapie projektowania i programowania:
+
+- Przechowuj całość kodu w systemie kontroli wersji takim jak git
+
+- Dokonywać każdej modyfikacji kodu za pomocą żądania Pull
+
+- Upewnić się, że żądania Pull mają przynajmniej jednego niezależnego recenzenta, co oznacza, że jeśli samodzielnie pracujesz przy projekcie, powinieneś rozważyć kontakt z innymi programistami w celu wymiany ocen kodu
+
+- Używaj [środowiska deweloperskiego](/developers/docs/frameworks/) do testowania, kompilowania i wdrażania inteligentnych kontraktów
+
+- Przetestuj swój kod za pomocą podstawowych narzędzi do analizy kodu, takich jak [Cyfrin Aderyn](https://github.com/Cyfrin/aderyn), Mythril i Slither. W idealnych warunkach powinno się robić to przed scaleniem każdego żądania pull, a następnie porównać różnice w danych wyjściowych
+
+- Upewnić się, że kod kompiluje się bez błędów, oraz że kompilator Solidity nie pokazuje żadnych ostrzeżeń
+
+- Odpowiednio dokumentuj swój kod (używając [NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html)) i opisuj szczegóły dotyczące architektury kontraktu w łatwym do zrozumienia języku. Ułatwi to innym przeprowadzenie audytu i recenzji kodu.
+
+### 6. Wdróż solidne plany odzyskiwania po awarii {#implement-disaster-recovery-plans}
+
+Projektowanie bezpiecznej kontroli dostępu, implementowanie modyfikatorów funkcji oraz inne sugestie mogą zwiększyć bezpieczeństwo inteligentnego kontraktu, ale nie mogą wykluczyć ryzyka złośliwego wykorzystania. Tworzenie bezpiecznych inteligentnych kontraktów wymaga "przygotowania się na porażkę" oraz posiadania planu zapasowego na efektywną odpowiedź wobec ataku. Odpowiedni plan odzyskiwania w przypadku katastrofy powinien zawierać następujące komponenty:
+
+#### Aktualizacje kontraktów {#contract-upgrades}
+
+Pomimo tego, że standardowo inteligentne kontrakty Ethereum są niezmienne, możliwe jest osiągnięcie pewnego poziomu zmienności przy użyciu wzorców aktualizacji. Aktualizacja kontraktu jest niezbędne w przypadkach, w których wada krytyczna sprawia, że kontrakt staje się bezużyteczny, a wdrożenie nowej logiki jest najbardziej wykonalną możliwością.
+
+Mechanizmy aktualizowania kontraktu działają na różne sposoby, ale "wzorzec proxy" jest jednym z najbardziej popularnych podejść do aktualizowania inteligentnych kontraktów. [Wzorce proxy](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern) dzielą stan i logikę aplikacji między _dwa_ kontrakty. Pierwszy kontrakt (nazywany „kontraktem proxy”) przechowuje zmienne stanu (np. salda użytkowników), natomiast drugi kontrakt (nazywany „kontraktem logicznym”) zawiera kod do wykonywania funkcji kontraktu.
+
+Konta wchodzą w interakcję z kontraktem proxy, który przekazuje wszystkie wywołania funkcji do kontraktu logicznego za pomocą niskopoziomowego wywołania [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight=delegatecall#delegatecall-callcode-and-libraries). W przeciwieństwie do zwykłego wywołania wiadomości, `delegatecall()` zapewnia, że kod działający pod adresem kontraktu logicznego jest wykonywany w kontekście kontraktu wywołującego. Oznacza to, że kontrakt logiczny zawsze będzie zapisywał dane w pamięci masowej proxy (zamiast we własnej), a oryginalne wartości `msg.sender` i `msg.value` zostaną zachowane.
+
+Delegowanie wywołań do kontraktu logicznego wymaga przechowywania jego adresu w pamięci kontraktu proxy. Dlatego aktualizacja logiki kontraktu jest jedynie kwestią wdrożenia kolejnego kontraktu logicznego i przechowania nowego adresu w kontrakcie proxy. Jako że kolejne wywołania kontraktu proxy są automatycznie przekierowane do nowego kontraktu logicznego, "aktualizacja" została dokonana właściwie bez modyfikacji kodu.
+
+[Więcej o aktualizowaniu kontraktów](/developers/docs/smart-contracts/upgrading/).
+
+#### Zatrzymania awaryjne {#emergency-stops}
+
+Jak wspomniano wcześniej, nawet dokładne audyty i testowanie nie są w stanie odkryć dokładnie wszystkich błędów w inteligentnym kontrakcie. Jeśli luka w zabezpieczeniach ujawni się w kodzie już po wdrożeniu, załatanie jej nie jest możliwe, ponieważ nie można zmienić kodu uruchomionego pod adresem kontraktu. Ponadto, implementacja mechanizmów aktualizacji (np. wzorca proxy) mogą zająć czas (wymagają one często zgody wielu stron), co działa tylko na korzyść napastników, dając im więcej czasu na dokonanie szkód.
+
+Opcją nuklearną jest implementacja funkcji "wyłącznika awaryjnego", która blokuje wywołania zagrożonych funkcji kontraktu. Wyłączniki awaryjne zawierają zwykle następujące komponenty:
+
+1. Globalną zmienną logiczną, która wykazuje czy inteligentny kontrakt jest w stanie zatrzymania czy nie. Zmienna ta jest ustawiona na `false` podczas konfigurowania kontraktu, ale powróci do wartości `true`, gdy kontrakt zostanie zatrzymany.
+
+2. Funkcje, które odnoszą się do zmiennej logicznej w swoim działaniu. Takie funkcje są dostępne, kiedy inteligentny kontrakt nie jest zatrzymany, a przestają być dostępne, kiedy funkcja awaryjnego wyłącznika zostaje aktywowana.
+
+3. Podmiot, który ma dostęp do funkcji zatrzymania awaryjnego, która ustawia zmienną logiczną na `true`. Aby uniknąć złośliwych działań, wywołania tej funkcji mogą zostać ograniczone do zaufanych adresów (np. właściciela kontraktu).
+
+Kiedy kontrakt aktywuje wyłącznik awaryjny, określone funkcje przestaną być dostępne. Osiąga się to poprzez opakowanie wybranych funkcji modyfikatorem, który odnosi się do zmiennej globalnej. Poniżej znajduje się [przykład](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol) opisujący implementację tego wzorca w kontraktach:
+
+```solidity
+// Ten kod nie został profesjonalnie zaudytowany i nie daje żadnych gwarancji bezpieczeństwa ani poprawności. Używaj na własne ryzyko.
+
+contract EmergencyStop {
+
+ bool isStopped = false;
+
+ modifier stoppedInEmergency {
+ require(!isStopped);
+ _;
+ }
+
+ modifier onlyWhenStopped {
+ require(isStopped);
+ _;
+ }
+
+ modifier onlyAuthorized {
+ // Tutaj sprawdź autoryzację msg.sender
+ _;
+ }
+
+ function stopContract() public onlyAuthorized {
+ isStopped = true;
+ }
+
+ function resumeContract() public onlyAuthorized {
+ isStopped = false;
+ }
+
+ function deposit() public payable stoppedInEmergency {
+ // Tutaj odbywa się logika depozytu
+ }
+
+ function emergencyWithdraw() public onlyWhenStopped {
+ // Tutaj odbywa się awaryjna wypłata
+ }
+}
+```
+
+Ten przykład ukazuje podstawowe cechy wyłączników awaryjnych:
+
+- `isStopped` to zmienna logiczna, która na początku ma wartość `false`, a po przejściu kontraktu w tryb awaryjny – `true`.
+
+- Modyfikatory funkcji `onlyWhenStopped` i `stoppedInEmergency` sprawdzają zmienną `isStopped`. `stoppedInEmergency` służy do kontrolowania funkcji, które powinny być niedostępne, gdy kontrakt jest podatny na ataki (np. `deposit()`). Wywołania tej funkcji po prostu zostaną anulowane.
+
+`onlyWhenStopped` jest używany dla funkcji, które powinny być możliwe do wywołania w sytuacji awaryjnej (np. `emergencyWithdraw()`). Takie funkcje mogą pomóc w rozwiązaniu sytuacji, dlatego wykluczone są z listy "zastrzeżonych funkcji".
+
+Użycie funkcji wyłącznika awaryjnego zapewnia efektywne rozwiązanie tymczasowe pozwalające poradzić sobie z poważnymi podatnościami inteligentnego kontraktu. Zwiększa jednak potrzebę zaufania wobec programistów, że nie użyją jej dla własnej korzyści. Aby się to tego odnieść, można użyć środków takich jak decentralizacja kontroli nad wyłącznikami awaryjnymi poprzez poddanie jej pod mechanizm głosowania onchain, zamku czasowego lub użycia do jej kontroli portfela multisig.
+
+#### Monitorowanie zdarzeń {#event-monitoring}
+
+[Zdarzenia](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events) pozwalają śledzić wywołania funkcji inteligentnych kontraktów i monitorować zmiany zmiennych stanu. Zaleca się programowanie kontraktów w taki sposób, aby emitowały zdarzenie za każdym razem, gdy jakiś podmiot wykonuje czynność istotną z perspektywy zabezpieczeń (np. wypłatę środków).
+
+Rejestrowanie zdarzeń i monitorowanie ich offchain zapewnia wgląd do operacji kontraktu i pomaga w szybszym odkrywaniu złośliwych czynności. Oznacza to, że zespół może szybciej odpowiedzieć na haki i zacząć działać, aby ograniczyć negatywny wpływ grożący użytkownikom, np. zatrzymując funkcje lub wykonując aktualizację.
+
+Można również zdecydować się na gotowe narzędzie do monitorowania, które automatycznie przekazuje ostrzeżenia za każdym razem, kiedy ktoś wchodzi w interakcję z kontraktem. Narzędzia te pozwalają stworzyć niestandardowe powiadomienia wywoływane różnymi wyzwalaczami takimi jak wielkość wolumenu transakcji, częstotliwość wywoływania funkcji oraz użycie określonych funkcji. Na przykład można zaprogramować powiadomienie, który przychodzi, kiedy suma wypłacona w jednej transakcji przekracza określony próg.
+
+### 7. Projektuj bezpieczne systemy zarządzania {#design-secure-governance-systems}
+
+Warte rozważenia jest zdecentralizowanie aplikacji poprzez oddanie kontroli nad kluczowymi inteligentnymi kontraktami członkom społeczności. W tym przypadku system inteligentnego kontraktu będzie zawierał moduł zarządzający — mechanizm, który pozwala członkom społeczności aprobować czynności administracyjne poprzez system zarządzania onchain. Na przykład propozycja aktualizacji kontraktu proxy do nowej wersji może być poddana głosowaniu posiadaczom tokena.
+
+Zdecentralizowane zarządzanie może być korzystne, ponieważ czyni zbieżnym interes programistów oraz użytkowników końcowych. Niemniej mechanizmy zarządzania inteligentnymi kontraktami mogą wprowadzić nowe ryzyka w przypadku niepoprawnej implementacji. Prawdopodobnym scenariuszem jest sytuacja, w której atakujący zdobywa ogromną siłę głosu (mierzoną liczbą posiadanych tokenów) poprzez wzięcie [błyskawicznej pożyczki](/defi/#flash-loans) i przeforsowuje złośliwą propozycję.
+
+Jednym ze sposobów zapobiegania problemom związanym z zarządzaniem on-chain jest [użycie blokady czasowej (timelock)](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/). Zamek czasowy powstrzymuje inteligentny kontrakt przed wykonaniem pewnej funkcji, zanim minie określona ilość czasu. Inne strategie przewidują nadanie "ciężaru głosu" każdemu tokenowi na bazie czasu, na jaki został zablokowany lub zmierzenie siły adresu w przeszłym okresie (na przykład 2 czy 3 bloki wstecz) zamiast w czasie aktualnego bloku. Obie metody obniżają ryzyko szybkiego gromadzenia siły głosu, aby przechylić na swoją korzyść głosowania onchain.
+
+Więcej na temat [projektowania bezpiecznych systemów zarządzania](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/), [różnych mechanizmów głosowania w DAO](https://hackernoon.com/governance-is-the-holy-grail-for-daos) oraz [powszechnych wektorów ataków na DAO wykorzystujących DeFi](https://dacian.me/dao-governance-defi-attacks) w udostępnionych linkach.
+
+### 8. Ogranicz złożoność kodu do minimum {#reduce-code-complexity}
+
+Programiści tradycyjnego oprogramowania są zaznajomieni z zasadą KISS ("ma być prosto głupku"), która odradza wprowadzania niepotrzebnej złożoności do projektu oprogramowania. Jest to zgodne ze znanym od dawana stwierdzeniem, że "złożone systemy zawodzą w złożone sposoby" oraz są najbardziej podatne na kosztowne błędy.
+
+Zachowanie prostoty jest szczególnie ważne przy pisaniu inteligentnych kontraktów, jeśli weźmiemy pod wagę fakt, że inteligentne kontrakty mogą potencjalnie kontrolować aktywa o wysokiej wartości. Wskazówką pozwalającą na osiągnięcie prostoty podczas pisania inteligentnych kontraktów jest ponowne wykorzystywanie istniejących bibliotek, takich jak [OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/), tam, gdzie to możliwe. Biblioteki te bowiem poddane były dokładnym audytom oraz testom prowadzonym przez programistów. Używanie ich ogranicza ryzyko popełnienia błędu podczas pisania nowych funkcji od zera.
+
+Inną powszechną wskazówką jest pisanie niewielkich funkcji i dbanie o modularność kontraktów poprzez rozdzielanie logiki biznesowej pomiędzy wiele kontraktów. Pisanie prostszego kodu nie tylko ogranicza powierzchnię potencjalnego ataku w inteligentnym kontrakcie, ale również ułatwia rozważania na temat poprawności całego systemu oraz szybkie wykrywanie możliwych błędów projektowych.
+
+### 9. Chroń się przed powszechnymi lukami w zabezpieczeniach inteligentnych kontraktów {#mitigate-common-smart-contract-vulnerabilities}
+
+#### Ponowne wejście (reentrancy) {#reentrancy}
+
+EVM nie pozwala na współbieżność w takim znaczeniu, że dwa kontrakty biorące udział w wywołaniu komunikatu nie mogą działać jednocześnie. Zewnętrzne wywołanie zatrzymuje działanie kontraktu wywołującego oraz jego pamięć do czasu powrotu wywołania. Po tym fakcie działanie jest wznowione. Proces ten można formalnie opisać jako przekazanie [przepływu sterowania](https://www.computerhope.com/jargon/c/contflow.htm) do innego kontraktu.
+
+W większości przypadków jest to nieszkodliwe, ale przenoszenie kontroli przepływu do niezaufanych kontaktów może powodować problemy takie jak atak rekurencyjny. Atak rekurencyjny występuje, gdy złośliwy kontrakt powraca wywołanie do narażonego kontraktu, zanim wywołanie właściwej funkcji dobiegnie końca. Najlepiej wyjaśnić to za pomocą przykładu.
+
+Weźmy prosty inteligentny kontrakt ("Ofiarę"), który pozwala każdemu na deponowanie i wypłacanie eteru:
+
+```solidity
+// Ten kontrakt jest podatny na ataki. Nie używać w środowisku produkcyjnym
+
+contract Victim {
+ mapping (address => uint256) public balances;
+
+ function deposit() external payable {
+ balances[msg.sender] += msg.value;
+ }
+
+ function withdraw() external {
+ uint256 amount = balances[msg.sender];
+ (bool success, ) = msg.sender.call.value(amount)("");
+ require(success);
+ balances[msg.sender] = 0;
+ }
+}
+```
+
+Ten kontrakt udostępnia funkcję `withdraw()`, aby umożliwić użytkownikom wypłatę ETH wcześniej zdeponowanego w kontrakcie. Przetwarzając wypłatę, kontrakt dokonuje następujących działań:
+
+1. Sprawdza saldo ETH użytkownika
+2. Wysyła środki na wywołujący adres
+3. Resetuje ich saldo do 0 uniemożliwiając dalszych wypłat temu użytkownikowi
+
+Funkcja `withdraw()` w kontrakcie `Victim` jest zgodna ze wzorcem „sprawdzenie-interakcje-efekty”. _Sprawdza_, czy warunki niezbędne do wykonania są spełnione (tj. użytkownik ma dodatnie saldo ETH) i wykonuje _interakcję_, wysyłając ETH na adres wywołującego, przed zastosowaniem _efektów_ transakcji (tj. zmniejszeniem salda użytkownika).
+
+Jeśli funkcja `withdraw()` jest wywoływana z konta zewnętrznego (EOA), funkcja wykonuje się zgodnie z oczekiwaniami: `msg.sender.call.value()` wysyła ETH do wywołującego. Jeśli jednak `msg.sender` jest kontem inteligentnego kontraktu, które wywołuje `withdraw()`, wysłanie środków za pomocą `msg.sender.call.value()` spowoduje również uruchomienie kodu zapisanego pod tym adresem.
+
+Wyobraź sobie, że to jest kod wdrożony na adresie kontraktu:
+
+```solidity
+ contract Attacker {
+ function beginAttack() external payable {
+ Victim(victim_address).deposit.value(1 ether)();
+ Victim(victim_address).withdraw();
+ }
+
+ function() external payable {
+ if (gasleft() > 40000) {
+ Victim(victim_address).withdraw();
+ }
+ }
+}
+```
+
+Ten kontrakt jest zaprojektowany, aby wykonywać trzy rzeczy:
+
+1. Akceptować depozyt od innego konta (prawdopodobnie od EOA napastnika)
+2. Dokonać depozytu 1 ETH na kontrakt Ofiary
+3. Wypłacić ten 1 ETH przechowywany przez inteligentny kontrakt
+
+Nie ma w tym nic złego, z wyjątkiem tego, że `Attacker` ma inną funkcję, która ponownie wywołuje `withdraw()` w `Victim`, jeśli ilość gazu pozostała z przychodzącego `msg.sender.call.value` jest większa niż 40 000. Daje to `Attacker` możliwość ponownego wejścia do `Victim` i wypłacenia większej ilości środków, _zanim_ pierwsze wywołanie `withdraw` zostanie zakończone. Cykl wygląda następująco:
+
+```solidity
+- EOA atakującego wywołuje `Attacker.beginAttack()` z 1 ETH
+- `Attacker.beginAttack()` wpłaca 1 ETH do `Victim`
+- `Attacker` wywołuje `withdraw()` w `Victim`
+- `Victim` sprawdza saldo `Attacker` (1 ETH)
+- `Victim` wysyła 1 ETH do `Attacker` (co uruchamia funkcję domyślną)
+- `Attacker` ponownie wywołuje `Victim.withdraw()` (zauważ, że `Victim` nie zmniejszyło salda `Attacker` po pierwszej wypłacie)
+- `Victim` sprawdza saldo `Attacker` (które wciąż wynosi 1 ETH, ponieważ nie zastosowano efektów pierwszego wywołania)
+- `Victim` wysyła 1 ETH do `Attacker` (co uruchamia funkcję domyślną i pozwala `Attacker` na ponowne wejście do funkcji `withdraw`)
+- Proces powtarza się, dopóki `Attacker` nie wyczerpie gazu, w którym to momencie `msg.sender.call.value` zwraca wartość bez uruchamiania dodatkowych wypłat
+- `Victim` w końcu stosuje wyniki pierwszej (i kolejnych) transakcji do swojego stanu, więc saldo `Attacker` jest ustawiane na 0
+```
+
+Podsumowując, z uwagi na to, że saldo wywołującego nie jest ustawione na 0 dopóki wykonanie funkcji nie jest skończone, późniejsze wywołania osiągną sukces i pozwolą wywołującemu wypłacić środki wielokrotnie. Ten rodzaj ataku może być wykorzystany do drenażu środków z inteligentnego kontraktu, jak to miało miejsce podczas [ataku na DAO w 2016 roku](https://www.coindesk.com/learn/understanding-the-dao-attack). Ataki typu reentrancy są do dziś krytycznym problemem dla inteligentnych kontraktów, o czym świadczą [publiczne listy exploitów reentrancy](https://github.com/pcaversaccio/reentrancy-attacks).
+
+##### Jak zapobiegać atakom rekurencyjnym
+
+Jednym ze sposobów radzenia sobie z ponownym wejściem jest przestrzeganie [wzorca sprawdzenie-efekty-interakcje](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern). Ten wzorzec kieruje wykonaniem funkcji w taki sposób, że w pierwszej kolejności dokonuje niezbędnych sprawdzeń, następnie wykonuje kod zmieniający stan kontraktu, a na końcu kod, który wchodzi w interakcję z kontraktami lub EOA.
+
+Wzorzec sprawdzenie-efekty-interakcje jest użyty w poprawionej wersji kontraktu `Victim` pokazanej poniżej:
+
+```solidity
+contract NoLongerAVictim {
+ function withdraw() external {
+ uint256 amount = balances[msg.sender];
+ balances[msg.sender] = 0;
+ (bool success, ) = msg.sender.call.value(amount)("");
+ require(success);
+ }
+}
+```
+
+Ten kontrakt wykonuje _sprawdzenie_ salda użytkownika, stosuje _efekty_ funkcji `withdraw()` (zerując saldo użytkownika), a następnie przechodzi do wykonania _interakcji_ (wysłania ETH na adres użytkownika). Dzięki temu kontrakt aktualizuje swoją pamięć przed zewnętrznym wywołaniem, eliminując tym samym warunki do ataku rekurencyjnego, które zaistniały wcześniej. Kontrakt `Attacker` wciąż może wywołać `NoLongerAVictim`, ale ponieważ `balances[msg.sender]` zostało ustawione na 0, dodatkowe wypłaty spowodują błąd.
+
+Innym rozwiązaniem jest zastosowanie wzajemnie wykluczających się zamków (powszechnie znanych pod nazwą "mutex"), które zamykają część stanu kontraktu do czasu zakończenia wywołania funkcji. Jest to realizowane za pomocą zmiennej logicznej, która jest ustawiana na `true` przed wykonaniem funkcji i wraca do `false` po zakończeniu wywołania. Jak pokazuje poniższy przykład, używanie mutex zapewnia ochronę przed atakami rekurencyjnymi w czasie, kiedy pierwotne wywołanie wciąż jest przetwarzane.
+
+```solidity
+pragma solidity ^0.7.0;
+
+contract MutexPattern {
+ bool locked = false;
+ mapping(address => uint256) public balances;
+
+ modifier noReentrancy() {
+ require(!locked, "Zablokowano przed ponownym wejściem.");
+ locked = true;
+ _;
+ locked = false;
+ }
+ // Ta funkcja jest chroniona przez muteks, więc ponowne wywołania z wewnątrz `msg.sender.call` nie mogą ponownie wywołać `withdraw`.
+ // Instrukcja `return` zwraca `true`, ale nadal ocenia instrukcję `locked = false` w modyfikatorze
+ function withdraw(uint _amount) public payable noReentrancy returns(bool) {
+ require(balances[msg.sender] >= _amount, "Brak salda do wypłaty.");
+
+ balances[msg.sender] -= _amount;
+ (bool success, ) = msg.sender.call{value: _amount}("");
+ require(success);
+
+ return true;
+ }
+}
+```
+
+Można również użyć systemu [płatności typu pull](https://docs.openzeppelin.com/contracts/5.x/api/security#PullPayment), który wymaga od użytkowników wypłacania środków z inteligentnych kontraktów, zamiast systemu „płatności typu push”, który wysyła środki na konta. Eliminuje to możliwość przypadkowego uruchomienia kodu pod nieznanymi adresami (i może również zapobiec niektórym atakom typu „odmowa usługi”).
+
+#### Niedomiar i przepełnienie liczb całkowitych {#integer-underflows-and-overflows}
+
+Przepełnienie całkowite występuje, gdy wyniki operacji arytmetycznej wykroczą poza dopuszczalny zakres wartości, powodując ich „przesunięcie” do najniższej możliwej do przedstawienia wartości. Na przykład `uint8` może przechowywać wartości tylko do 2^8-1=255. Operacje arytmetyczne, których wynik jest większy niż `255`, spowodują przepełnienie i zresetowanie `uint` do `0`, podobnie jak licznik kilometrów w samochodzie zeruje się po osiągnięciu maksymalnego przebiegu (999999).
+
+Niedomiar liczb całkowitych zdarza się z podobnych powodów: wynik operacji arytmetycznej mieści się poniżej dopuszczalnego zakresu. Powiedzmy, że próbujesz dekrementować `0` w `uint8`, wynik po prostu „przewinie się” do maksymalnej reprezentowalnej wartości (`255`).
+
+Zarówno przepełnienia, jak i niedopełnienia liczb całkowitych mogą prowadzić do nieoczekiwanych zmian zmiennych stanu kontraktu i skutkować nieplanowanym wykonaniem. Poniżej znajduje się przykład pokazujący, w jaki sposób atakujący może wykorzystać przepełnienie arytmetyczne w inteligentnym kontrakcie do wykonania nieprawidłowej operacji:
+
+```
+pragma solidity ^0.7.6;
+
+// Ten kontrakt ma działać jako skarbiec czasowy.
+// Użytkownik może wpłacać środki do tego kontraktu, ale nie może ich wypłacić przez co najmniej tydzień.
+// Użytkownik może również wydłużyć czas oczekiwania poza 1-tygodniowy okres.
+
+/*
+1. Wdróż TimeLock
+2. Wdróż Attack z adresem TimeLock
+3. Wywołaj Attack.attack wysyłając 1 ether. Natychmiast będziesz mógł
+ wypłacić swój ether.
+
+Co się stało?
+Atak spowodował przepełnienie TimeLock.lockTime i umożliwił wypłatę
+przed upływem 1-tygodniowego okresu oczekiwania.
+*/
+
+contract TimeLock {
+ mapping(address => uint) public balances;
+ mapping(address => uint) public lockTime;
+
+ function deposit() external payable {
+ balances[msg.sender] += msg.value;
+ lockTime[msg.sender] = block.timestamp + 1 weeks;
+ }
+
+ function increaseLockTime(uint _secondsToIncrease) public {
+ lockTime[msg.sender] += _secondsToIncrease;
+ }
+
+ function withdraw() public {
+ require(balances[msg.sender] > 0, "Niewystarczające środki");
+ require(block.timestamp > lockTime[msg.sender], "Czas blokady nie upłynął");
+
+ uint amount = balances[msg.sender];
+ balances[msg.sender] = 0;
+
+ (bool sent, ) = msg.sender.call{value: amount}("");
+ require(sent, "Nie udało się wysłać Etheru");
+ }
+}
+
+contract Attack {
+ TimeLock timeLock;
+
+ constructor(TimeLock _timeLock) {
+ timeLock = TimeLock(_timeLock);
+ }
+
+ fallback() external payable {}
+
+ function attack() public payable {
+ timeLock.deposit{value: msg.value}();
+ /*
+ jeśli t = bieżący czas blokady, musimy znaleźć x takie, że
+ x + t = 2**256 = 0
+ więc x = -t
+ 2**256 = type(uint).max + 1
+ więc x = type(uint).max + 1 - t
+ */
+ timeLock.increaseLockTime(
+ type(uint).max + 1 - timeLock.lockTime(address(this))
+ );
+ timeLock.withdraw();
+ }
+}
+```
+
+##### Jak zapobiegać niedomiarom i przepełnieniom całkowitym
+
+Od wersji 0.8.0 kompilator Solidity odrzuca kod powodujący przepełnienia i niedopełnienia liczb całkowitych. Jednakże kontrakty skompilowane przy użyciu niższej wersji kompilatora powinny albo wykonywać sprawdzenia funkcji obejmujących operacje arytmetyczne, albo używać biblioteki (np. [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math)), która sprawdza niedomiar/przepełnienie.
+
+#### Manipulacja wyroczniami {#oracle-manipulation}
+
+[Wyrocznie](/developers/docs/oracles/) pozyskują informacje spoza łańcucha (off-chain) i przesyłają je do łańcucha (on-chain) do wykorzystania przez inteligentne kontrakty. Dzięki wyroczniom można projektować inteligentne kontrakty, które współpracują z systemami off-chain, takimi jak rynki kapitałowe, co znacznie rozszerza ich zastosowanie.
+
+Jeśli jednak wyrocznia jest uszkodzona i wysyła nieprawidłowe informacje w łańcuchu, inteligentne kontrakty będą wykonywane w oparciu o błędne dane wejściowe, co może powodować problemy. To jest podstawa „problemu wyroczni”, który dotyczy zadania upewnienia się, że informacje z wyroczni blockchain są dokładne, aktualne i aktualne.
+
+Podobnym problemem bezpieczeństwa jest korzystanie z wyroczni łańcuchowej, takiej jak zdecentralizowana giełda, w celu uzyskania bieżącej ceny aktywów. Platformy pożyczkowe w branży [zdecentralizowanych finansów (DeFi)](/defi/) często robią to, aby określić wartość zabezpieczenia użytkownika w celu ustalenia, ile może on pożyczyć.
+
+Ceny DEX są często dokładne, głównie dzięki arbitrażystom przywracającym parytet na rynkach. Są one jednak podatne na manipulację, szczególnie jeśli wyrocznia on-chain oblicza ceny aktywów w oparciu o historyczne wzorce handlowe (co zwykle ma miejsce).
+
+Przykładowo, atakujący może sztucznie zawyżać cenę spot aktywów, zaciągając pożyczkę błyskawiczną tuż przed podpisaniem umowy kredytowej. Zapytanie o cenę aktywów na giełdzie DEX zwróciłoby wyższą niż zwykle wartość (z powodu dużego „zlecenia kupna” atakującego, zaburzającego popyt na aktywa), co umożliwiłoby mu pożyczenie większej kwoty, niż powinien. Tego typu „błyskawiczne ataki kredytowe” wykorzystywano w celu wykorzystania zależności aplikacji DeFi od wyroczni cenowych, co kosztowało protokoły miliony dolarów w postaci utraconych środków.
+
+##### Jak zapobiegać manipulacjom wyrocznią
+
+Minimalnym wymogiem, aby [uniknąć manipulacji wyrocznią](https://www.cyfrin.io/blog/price-oracle-manipultion-attacks-with-examples), jest korzystanie ze zdecentralizowanej sieci wyroczni, która pobiera informacje z wielu źródeł, aby uniknąć pojedynczych punktów awarii. W większości przypadków zdecentralizowane wyrocznie mają wbudowane zachęty kryptoekonomiczne, które mają skłaniać węzły wyroczni do raportowania prawidłowych informacji, dzięki czemu są bezpieczniejsze niż wyrocznie scentralizowane.
+
+Jeśli planujesz wysłać zapytanie do wyroczni onchain o ceny aktywów, rozważ użycie takiej, która implementuje mechanizm średniej ceny ważonej w czasie (TWAP). [Wyrocznia TWAP](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) wysyła zapytanie o cenę aktywa w dwóch różnych punktach w czasie (które można modyfikować) i oblicza cenę spot na podstawie uzyskanej średniej. Wybór dłuższych okresów czasu chroni protokół przed manipulacją cenami, ponieważ duże zlecenia zrealizowane niedawno nie mają wpływu na ceny aktywów.
+
+## Zasoby dotyczące bezpieczeństwa inteligentnych kontraktów dla programistów {#smart-contract-security-resources-for-developers}
+
+### Narzędzia do analizy inteligentnych kontraktów i weryfikacji poprawności kodu {#code-analysis-tools}
+
+- **[Narzędzia i biblioteki testowe](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** – _Zbiór standardowych narzędzi i bibliotek do przeprowadzania testów jednostkowych oraz analizy statycznej i dynamicznej inteligentnych kontraktów._
+
+- **[Narzędzia do weryfikacji formalnej](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** – _narzędzia do weryfikacji poprawności funkcjonalnej w inteligentnych kontraktach i sprawdzania niezmienników._
+
+- **[Usługi audytu inteligentnych kontraktów](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** – _Lista organizacji świadczących usługi audytu inteligentnych kontraktów dla projektów deweloperskich Ethereum._
+
+- **[Platformy nagród za błędy](/developers/docs/smart-contracts/testing/#bug-bounty-platforms)** – _Platformy do koordynowania nagród za błędy i nagradzania za odpowiedzialne ujawnianie krytycznych luk w zabezpieczeniach inteligentnych kontraktów._
+
+- **[Fork Checker](https://forkchecker.hashex.org/)** – _Darmowe narzędzie online do sprawdzania wszystkich dostępnych informacji dotyczących sforkowanego kontraktu._
+
+- **[ABI Encoder](https://abi.hashex.org/)** – _darmowa usługa online do kodowania funkcji kontraktu Solidity i argumentów konstruktora._
+
+- **[Aderyn](https://github.com/Cyfrin/aderyn)** – _Statyczny analizator Solidity, przechodzący przez Abstrakcyjne Drzewa Składni (AST) w celu wskazania podejrzanych luk w zabezpieczeniach i drukowania problemów w łatwym do przyswojenia formacie markdown._
+
+### Narzędzia do monitorowania inteligentnych kontraktów {#smart-contract-monitoring-tools}
+
+- **[Tenderly Real-Time Alerting](https://tenderly.co/monitoring)** – _Narzędzie do otrzymywania powiadomień w czasie rzeczywistym, gdy na Twoich inteligentnych kontraktach lub w portfelach zdarzają się nietypowe lub nieoczekiwane zdarzenia._
+
+### Narzędzia do bezpiecznego administrowania inteligentnymi kontraktami {#smart-contract-administration-tools}
+
+- **[Safe](https://safe.global/)** – _portfel inteligentnego kontraktu działający na Ethereum, który wymaga minimalnej liczby osób do zatwierdzenia transakcji, zanim będzie mogła ona nastąpić (M-z-N)._
+
+- **[OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/)** – _Biblioteki kontraktów do wdrażania funkcji administracyjnych, w tym własności kontraktu, uaktualnień, kontroli dostępu, zarządzania, możliwości wstrzymania i innych._
+
+### Usługi audytu inteligentnych kontraktów {#smart-contract-auditing-services}
+
+- **[ConsenSys Diligence](https://diligence.consensys.io/)** – _Usługa audytu inteligentnych kontraktów, która pomaga projektom w całym ekosystemie blockchain upewnić się, że ich protokoły są gotowe do uruchomienia i zbudowane w celu ochrony użytkowników._
+
+- **[CertiK](https://www.certik.com/)** – _Firma zajmująca się bezpieczeństwem blockchain, pionier w stosowaniu najnowocześniejszej technologii weryfikacji formalnej w inteligentnych kontraktach i sieciach blockchain._
+
+- **[Trail of Bits](https://www.trailofbits.com/)** – _Firma zajmująca się cyberbezpieczeństwem, która łączy badania nad bezpieczeństwem z mentalnością atakującego, aby zmniejszyć ryzyko i wzmocnić kod._
+
+- **[PeckShield](https://peckshield.com/)** – _Firma zajmująca się bezpieczeństwem blockchain, oferująca produkty i usługi zapewniające bezpieczeństwo, prywatność i użyteczność całego ekosystemu blockchain._
+
+- **[QuantStamp](https://quantstamp.com/)** – _Usługa audytorska ułatwiająca powszechne przyjęcie technologii blockchain poprzez usługi oceny bezpieczeństwa i ryzyka._
+
+- **[OpenZeppelin](https://www.openzeppelin.com/security-audits)** – _Firma zajmująca się bezpieczeństwem inteligentnych kontraktów, która przeprowadza audyty bezpieczeństwa dla systemów rozproszonych._
+
+- **[Runtime Verification](https://runtimeverification.com/)** – _Firma zajmująca się bezpieczeństwem, specjalizująca się w formalnym modelowaniu i weryfikacji inteligentnych kontraktów._
+
+- **[Hacken](https://hacken.io)** – _Audytor cyberbezpieczeństwa Web3, który wprowadza kompleksowe podejście (360 stopni) do bezpieczeństwa blockchain._
+
+- **[Nethermind](https://www.nethermind.io/smart-contract-audits)** – _Usługi audytu Solidity i Cairo, zapewniające integralność inteligentnych kontraktów i bezpieczeństwo użytkowników w sieciach Ethereum i Starknet._
+
+- **[HashEx](https://hashex.org/)** – _HashEx koncentruje się na audycie blockchain i inteligentnych kontraktów w celu zapewnienia bezpieczeństwa kryptowalut, świadcząc usługi takie jak tworzenie inteligentnych kontraktów, testy penetracyjne, doradztwo w zakresie blockchain._
+
+- **[Code4rena](https://code4rena.com/)** – _Konkurencyjna platforma audytowa, która zachęca ekspertów ds. bezpieczeństwa inteligentnych kontraktów do znajdowania luk w zabezpieczeniach i pomaga uczynić web3 bezpieczniejszym._
+
+- **[CodeHawks](https://codehawks.com/)** – _Konkurencyjna platforma audytowa organizująca konkursy audytu inteligentnych kontraktów dla badaczy bezpieczeństwa._
+
+- **[Cyfrin](https://cyfrin.io)** – _potęga bezpieczeństwa Web3, inkubująca bezpieczeństwo kryptowalut poprzez produkty i usługi audytu inteligentnych kontraktów._
+
+- **[ImmuneBytes](https://immunebytes.com/smart-contract-audit/)** – _Firma zajmująca się bezpieczeństwem Web3, oferująca audyty bezpieczeństwa systemów blockchain za pośrednictwem zespołu doświadczonych audytorów i najlepszych w swojej klasie narzędzi._
+
+- **[Oxorio](https://oxor.io/)** – _Audyty inteligentnych kontraktów i usługi bezpieczeństwa blockchain z doświadczeniem w technologiach EVM, Solidity, ZK, Cross-chain dla firm kryptograficznych i projektów DeFi._
+
+- **[Inference](https://inference.ag/)** – _Firma audytorska w zakresie bezpieczeństwa, specjalizująca się w audycie inteligentnych kontraktów dla blockchainów opartych na EVM._ Eksperci w dziedzinie audytów umiejący zidentyfikować potencjalne problemy i zasugerować działające rozwiązania do zastosowania przed wdrożeniem._
+
+### Platformy bug bounty {#bug-bounty-platforms}
+
+- **[Immunefi](https://immunefi.com/)** – _Platforma bug bounty dla inteligentnych kontraktów i projektów DeFi, na której badacze bezpieczeństwa przeglądają kod, ujawniają luki w zabezpieczeniach, otrzymują wynagrodzenie i sprawiają, że kryptowaluty są bezpieczniejsze._
+
+- **[HackerOne](https://www.hackerone.com/)** – _Platforma koordynacji luk w zabezpieczeniach i nagród za błędy, która łączy firmy z testerami penetracyjnymi i badaczami cyberbezpieczeństwa._
+
+- **[HackenProof](https://hackenproof.com/)** – _Ekspercka platforma nagród za błędy dla projektów kryptograficznych (DeFi, inteligentne kontrakty, portfele, CEX i inne), na której specjaliści ds. bezpieczeństwa świadczą usługi selekcji, a badacze otrzymują wynagrodzenie za odpowiednie, zweryfikowane raporty o błędach._
+
+- **[Sherlock](https://www.sherlock.xyz/)** – _Gwarant w Web3 w zakresie bezpieczeństwa inteligentnych kontraktów, z wypłatami dla audytorów zarządzanymi za pośrednictwem inteligentnych kontraktów, aby zapewnić, że odpowiednie błędy są uczciwie opłacane._
+
+- **[CodeHawks](https://www.codehawks.com/)** – _Konkurencyjna platforma bug bounty, na której audytorzy biorą udział w konkursach i wyzwaniach dotyczących bezpieczeństwa, a (wkrótce) także we własnych prywatnych audytach._
+
+### Publikacje znanych luk w zabezpieczeniach inteligentnych kontraktów i exploitów {#common-smart-contract-vulnerabilities-and-exploits}
+
+- **[ConsenSys: Znane ataki na inteligentne kontrakty](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/)** – _Przyjazne dla początkujących wyjaśnienie najważniejszych luk w zabezpieczeniach kontraktów, z przykładowym kodem dla większości przypadków._
+
+- **[Rejestr SWC](https://swcregistry.io/)** – _Wyselekcjonowana lista elementów Common Weakness Enumeration (CWE), które mają zastosowanie do inteligentnych kontraktów Ethereum._
+
+- **[Rekt](https://rekt.news/)** – _Regularnie aktualizowana publikacja głośnych hacków i exploitów kryptograficznych, wraz ze szczegółowymi raportami pośmiertnymi._
+
+### Wyzwania związane z nauką bezpieczeństwa inteligentnych kontraktów {#challenges-for-learning-smart-contract-security}
+
+- **[Awesome BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** – _Wyselekcjonowana lista gier wojennych, wyzwań i konkursów [Capture The Flag](https://www.webopedia.com/definitions/ctf-event/amp/) z zakresu bezpieczeństwa blockchain oraz opisy rozwiązań._
+
+- **[Damn Vulnerable DeFi](https://www.damnvulnerabledefi.xyz/)** – _Gra wojenna do nauki bezpieczeństwa ofensywnego inteligentnych kontraktów DeFi oraz budowania umiejętności w polowaniu na błędy i audycie bezpieczeństwa._
+
+- **[Ethernaut](https://ethernaut.openzeppelin.com/)** – _Gra wojenna oparta na Web3/Solidity, w której każdy poziom jest inteligentnym kontraktem, który należy „zhakować”._
+
+- **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** – _Wyzwanie hakerskie dotyczące inteligentnych kontraktów, osadzone w fantastycznej przygodzie._ Pomyślne ukończenie wyzwania daje również dostęp do prywatnego programu nagród za znalezienie błędu._
+
+### Najlepsze praktyki w zakresie zabezpieczania inteligentnych kontraktów {#smart-contract-security-best-practices}
+
+- **[ConsenSys: Najlepsze praktyki w zakresie bezpieczeństwa inteligentnych kontraktów Ethereum](https://consensys.github.io/smart-contract-best-practices/)** – _Kompleksowa lista wytycznych dotyczących zabezpieczania inteligentnych kontraktów Ethereum._
+
+- **[Nascent: Prosty zestaw narzędzi bezpieczeństwa](https://github.com/nascentxyz/simple-security-toolkit)** – _Zbiór praktycznych przewodników i list kontrolnych dotyczących bezpieczeństwa w tworzeniu inteligentnych kontraktów._
+
+- **[Wzorce Solidity](https://fravoll.github.io/solidity-patterns/)** – _Użyteczna kompilacja bezpiecznych wzorców i najlepszych praktyk dla języka programowania inteligentnych kontraktów Solidity._
+
+- **[Dokumentacja Solidity: Kwestie bezpieczeństwa](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** – _Wytyczne dotyczące pisania bezpiecznych inteligentnych kontraktów za pomocą Solidity._
+
+- **[Standard weryfikacji bezpieczeństwa inteligentnych kontraktów](https://github.com/securing/SCSVS)** – _Czternastoczęściowa lista kontrolna stworzona w celu standaryzacji bezpieczeństwa inteligentnych kontraktów dla programistów, architektów, recenzentów bezpieczeństwa i dostawców._
+
+- **[Naucz się bezpieczeństwa i audytu inteligentnych kontraktów](https://updraft.cyfrin.io/courses/security)** – _Kompletny kurs bezpieczeństwa i audytu inteligentnych kontraktów, stworzony dla programistów inteligentnych kontraktów, którzy chcą podnieść swoje najlepsze praktyki w zakresie bezpieczeństwa i stać się badaczami bezpieczeństwa._
+
+### Samouczki dotyczące bezpieczeństwa inteligentnych kontraktów {#tutorials-on-smart-contract-security}
+
+- [Jak pisać bezpieczne inteligentne kontrakty](/developers/tutorials/secure-development-workflow/)
+
+- [Jak używać Slither do znajdowania błędów w inteligentnych kontraktach](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
+
+- [Jak używać Manticore do znajdowania błędów w inteligentnych kontraktach](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
+
+- [Wytyczne dotyczące bezpieczeństwa inteligentnych kontraktów](/developers/tutorials/smart-contract-security-guidelines/)
+
+- [Jak bezpiecznie zintegrować swój kontrakt tokena z dowolnymi tokenami](/developers/tutorials/token-integration-checklist/)
+
+- [Cyfrin Updraft – Pełny kurs na temat bezpieczeństwa i audytu inteligentnych kontraktów](https://updraft.cyfrin.io/courses/security)
diff --git a/public/content/translations/pl/developers/docs/smart-contracts/testing/index.md b/public/content/translations/pl/developers/docs/smart-contracts/testing/index.md
index 443036fbbd2..d559f224173 100644
--- a/public/content/translations/pl/developers/docs/smart-contracts/testing/index.md
+++ b/public/content/translations/pl/developers/docs/smart-contracts/testing/index.md
@@ -1,45 +1,310 @@
---
-title: Testowanie inteligentnych kontraktów
-description:
+title: "Testowanie inteligentnych kontraktów"
+description: "Przegląd technik oraz wskazówek dotyczących testowania inteligentnych kontraktów Ethereum."
lang: pl
-incomplete: true
---
+Publiczne blockchainy takie jak Ethereum są niezmienne, co sprawia, że trudne jest wprowadzenie zmian do inteligentnego kontraktu po jego wdrożeniu. [Wzorce aktualizacji kontraktów](/developers/docs/smart-contracts/upgrading/) służące do przeprowadzania "wirtualnych aktualizacji" istnieją, ale są trudne do wdrożenia i wymagają społecznego konsensusu. Co więcej, aktualizacja może naprawić błąd dopiero _po_ jego wykryciu — jeśli atakujący jako pierwszy odkryje podatność, Twój inteligentny kontrakt jest narażony na ryzyko exploita.
+
+Z tych powodów testowanie inteligentnych kontraktów przed [wdrożeniem](/developers/docs/smart-contracts/deploying/) w sieci Mainnet jest minimalnym wymogiem dla [bezpieczeństwa](/developers/docs/smart-contracts/security/). Istnieje wiele technik testowania kontraktów i oceny poprawności kodu; wybór zależy od potrzeb. Niemniej, zestaw testów złożony z różnych narzędzi i podejść jest idealny do wychwycenia mniejszych i większych błędów w zabezpieczeniach kodu kontraktu.
+
+## Wymagania wstępne {#prerequisites}
+
+Ta strona wyjaśnia, w jaki sposób testować inteligentne kontrakty przed wdrożeniem ich do sieci Ethereum. Zakłada się, że znasz [inteligentne kontrakty](/developers/docs/smart-contracts/).
+
+## Czym jest testowanie inteligentnych kontraktów? {#what-is-smart-contract-testing}
+
+Testowanie inteligentnych kontraktów to proces weryfikacji poprawności pracy kodu inteligentnego kontraktu. Testowanie jest pomocne w celu sprawdzenia, czy dany inteligentny kontrakt spełnia wymagania niezawodności, używalności oraz bezpieczeństwa.
+
+Pomimo tego, że istnieją różne podejścia, większość metod testowania wymaga uruchomienia inteligentnego kontraktu przy użyciu niewielkiej ilości próbnych danych, które powinien obsłużyć. Jeśli kontrakt da poprawny rezultat dla próbnych danych, zakłada się, że pracuje poprawnie. Większość narzędzi do testowania zapewnia zasoby do pisania i wykonywania [przypadków testowych](https://en.m.wikipedia.org/wiki/Test_case), aby sprawdzić, czy wykonanie kontraktu odpowiada oczekiwanym wynikom.
+
+### Dlaczego testowanie inteligentnych kontraktów jest ważne? Znaczenie testowania inteligentnych kontraktów {#importance-of-testing-smart-contracts}
+
+Ponieważ inteligentne kontrakty często zarządzają aktywami finansowymi o wysokiej wartości, drobne błędy programistyczne mogą prowadzić, i często prowadzą, do [ogromnych strat dla użytkowników](https://rekt.news/leaderboard/). Jednakże rygorystyczne testowanie może pomóc w znalezieniu defektów i problemów w kodzie inteligentnego kontraktu oraz naprawieniu ich przed wypuszczeniem na sieci głównej.
+
+Chociaż możliwe jest zaktualizowanie kontraktu w przypadku odkrycia błędu, aktualizacje są skomplikowane i mogą [skutkować błędami](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/), jeśli są obsługiwane nieprawidłowo. Aktualizacja kontraktu podważa zasadę niezmienności i obarcza użytkowników dodatkową potrzebą zaufania. Z drugiej strony kompleksowy plan testowania kontraktu ogranicza ryzyka związane z bezpieczeństwem kontraktu i redukuje potrzebę wykonywania złożonych czynności niezbędnych do aktualizacji po wdrożeniu.
+
+## Metody testowania inteligentnych kontraktów {#methods-for-testing-smart-contracts}
+
+Metody testowania inteligentnych kontraktów Ethereum dzielą się na dwie szerokie kategorie: **testowanie zautomatyzowane** i **testowanie ręczne**. Zarówno testowanie zautomatyzowane, jak i testowanie manualne oferuje unikalne korzyści, ale też wady. Można jednak połączyć oba sposoby w celu stworzenia solidnego planu do analizy kontraktu.
+
+### Testowanie zautomatyzowane {#automated-testing}
+
+Testowanie zautomatyzowane wykorzystuje narzędzia, które automatycznie sprawdzają kod inteligentnego kontraktu pod kątem błędów działania. Zaleta testowania zautomatyzowanego polega na wykorzystaniu [skryptów](https://www.techtarget.com/whatis/definition/script?amp=1) do kierowania oceną funkcjonalności kontraktu. Testy oparte na skryptach mogą być przeprowadzone z minimalnym ludzkim wkładem, co czyni testowanie zautomatyzowane bardziej efektywnym niż testowanie manualne.
+
+Testowanie zautomatyzowane jest szczególnie użyteczne, kiedy testy są powtarzalne i wymagające czasowo; trudne do przeprowadzenia manualnego; podatne na błąd ludzki lub obejmują ocenę krytycznych funkcji kontraktu. Jednak narzędzia do testowania zautomatyzowanego mogą mieć wady — mogą pominąć niektóre błędy i generować wiele [wyników fałszywie dodatnich](https://www.contrastsecurity.com/glossary/false-positive). Stąd łączenie testowania automatycznego oraz testowania manualnego inteligentnych kontraktów jest rozwiązaniem doskonałym.
+
+### Testowanie ręczne {#manual-testing}
+
+Testowanie manualne jest wspomagane przez człowieka i obejmuje uruchamianie każdego przypadku testowego z zestawu osobno w procesie analizowania poprawności inteligentnego kontraktu. To przeciwieństwo testowania zautomatyzowanego, które pozwala przeprowadzić wiele izolowanych testów na kontrakcie jednocześnie, otrzymując na koniec raport pokazujący wszystkie pozytywne i negatywne wyniki testu.
+
+Testowanie manualne może być przeprowadzone przez jedną osobę realizującą pisemny plan testowy, który obejmuje różne scenariusze dotyczące testowania. Można również zaangażować do tego grupę osób, która będzie wchodziła w interakcję z inteligentnym kontraktem na przestrzeni konkretnego okresu w ramach testowania manualnego. Testerzy będą porównywali rzeczywiste zachowanie kontraktu z zachowaniem oczekiwanym, oznaczając każdą z różnic jako błąd.
+
+Efektywne testowanie ręczne wymaga znacznych zasobów (umiejętności, czasu, pieniędzy i wysiłku), a z powodu błędów ludzkich możliwe jest przeoczenie pewnych błędów podczas wykonywania testów. Jednak ręczne testowanie może być również korzystne — na przykład tester (np. audytor) może kierować się intuicją, aby wykrywać skrajne przypadki, które nie zostałyby wykryte przez narzędzie do automatycznego testowania.
+
+## Zautomatyzowane testowanie inteligentnych kontraktów {#automated-testing-for-smart-contracts}
+
+### Testowanie jednostkowe {#unit-testing-for-smart-contracts}
+
+Testowanie jednostkowe ocenia funkcje kontraktu osobno i sprawdza, czy każdy komponent działa poprawnie. Dobre testy jednostkowe powinny być proste, szybkie w wykonaniu i jasno wskazywać, co poszło nie tak, jeśli testy się nie powiodą.
+
+Testy jednostkowe są przydatne do sprawdzania, czy funkcje zwracają oczekiwane wartości i czy przechowywanie kontraktów jest poprawnie aktualizowane po wykonaniu funkcji. Co więcej, uruchomienie testów jednostkowych po wprowadzeniu zmian w kodzie kontraktów gwarantuje, że dodanie nowej logiki nie poskutkuje błędami. Poniżej znaleźć można kilka wskazówek dotyczących wydajnego korzystania z testów jednostkowych:
+
+#### Wskazówki dotyczące testowania jednostkowego inteligentnych kontraktów {#unit-testing-guidelines}
+
+##### 1. Zrozum logikę biznesową swojego kontraktu oraz jego przepływ pracy
+
+Przed napisaniem testów jednostkowych, zalecane jest poznanie funkcji oferowanych przez inteligentny kontrakt oraz sposobów, w jakie użytkownicy będą korzystali z tych funkcji. Jest to szczególnie przydatne do przeprowadzania [testów „szczęśliwej ścieżki”](https://en.m.wikipedia.org/wiki/Happy_path), które określają, czy funkcje w kontrakcie zwracają prawidłowe dane wyjściowe dla prawidłowych danych wejściowych użytkownika. Wyjaśnimy tę koncepcję na tym (skróconym) przykładzie [kontraktu aukcyjnego](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction)
+
+```solidity
+constructor(
+ uint biddingTime,
+ address payable beneficiaryAddress
+ ) {
+ beneficiary = beneficiaryAddress;
+ auctionEndTime = block.timestamp + biddingTime;
+ }
+
+function bid() external payable {
+
+ if (block.timestamp > auctionEndTime)
+ revert AuctionAlreadyEnded();
+
+ if (msg.value <= highestBid)
+ revert BidNotHighEnough(highestBid);
+
+ if (highestBid != 0) {
+ pendingReturns[highestBidder] += highestBid;
+ }
+ highestBidder = msg.sender;
+ highestBid = msg.value;
+ emit HighestBidIncreased(msg.sender, msg.value);
+ }
+
+ function withdraw() external returns (bool) {
+ uint amount = pendingReturns[msg.sender];
+ if (amount > 0) {
+ pendingReturns[msg.sender] = 0;
+
+ if (!payable(msg.sender).send(amount)) {
+ pendingReturns[msg.sender] = amount;
+ return false;
+ }
+ }
+ return true;
+ }
+
+function auctionEnd() external {
+ if (block.timestamp < auctionEndTime)
+ revert AuctionNotYetEnded();
+ if (ended)
+ revert AuctionEndAlreadyCalled();
+
+ ended = true;
+ emit AuctionEnded(highestBidder, highestBid);
+
+ beneficiary.transfer(highestBid);
+ }
+}
+```
+
+To jest prosty kontrakt aukcyjny zaprojektowanym, aby przyjmować oferty podczas okresu oferowania. Jeśli `highestBid` wzrośnie, poprzedni licytant z najwyższą ofertą otrzymuje zwrot swoich pieniędzy; po zakończeniu okresu licytacji `beneficiary` wywołuje kontrakt, aby otrzymać swoje pieniądze.
+
+Testy jednostkowe dla takiego kontraktu dotyczyłyby różnych funkcji, których mógłby użyć użytkownicy Przykładem może być test jednostkowy, który sprawdza, czy użytkownik może złożyć ofertę, gdy aukcja jest w toku (tj. wywołania `bid()` kończą się powodzeniem) lub taki, który sprawdza, czy użytkownik może złożyć wyższą ofertę niż bieżąca `highestBid`.
+
+Zrozumienie operacyjnego przepływu pracy kontraktu pomaga również w pisaniu testów, które sprawdzają, czy wykonanie spełnia wymagania. Na przykład kontrakt aukcyjny określa, że użytkownicy nie mogą składać ofert po zakończeniu aukcji (tzn. gdy `auctionEndTime` jest mniejsze niż `block.timestamp`). W związku z tym programista może uruchomić test jednostkowy, który sprawdza, czy wywołania funkcji `bid()` kończą się powodzeniem, czy niepowodzeniem, gdy aukcja jest zakończona (tj. gdy `auctionEndTime` > `block.timestamp`).
+
+##### 2. Oceń wszystkie założenia związanie z wykonaniem kontraktu
+
+Ważnym jest dokumentowanie każdego założenia dotyczącego wykonania kontraktu i napisanie testu jednostkowego, który weryfikuje poprawność tego założenia. Poza zapewnieniem ochrony przez niespodziewanym wykonaniem, testowanie twierdzeń zmusza do przemyśleń na temat działań, które mogą doprowadzić do złamania zabezpieczeń inteligentnego kontraktu. Przydatną wskazówką jest wykroczenie poza "testy idealnego scenariusza" i napisanie testów negatywnych, które sprawdzają, czy funkcja kończy się niepowodzeniem, kiedy dane wejściowe są niewłaściwe.
+
+Wiele środowisk testów jednostkowych pozwala na tworzenie twierdzeń-prostych zasad działania kontraktu, oraz uruchamianie testów sprawdzających te twierdzenia podczas wykonywania. Programista pracujący przy kontrakcie aukcyjnym opisanym powyżej, może sformułować następujące twierdzenia przed uruchomieniem testów negatywnych:
+
+- Użytkownicy nie mogą składać ofert, kiedy aukcja się skończyła lub jeszcze się nie rozpoczęła.
+
+- Kontrakt aukcyjny traci ważność, jeśli oferta jest niższa od minimalny progu.
+
+- Użytkownicy, których oferta nie wygrała otrzymują zwrot środków
+
+**Uwaga**: Innym sposobem testowania założeń jest pisanie testów, które wyzwalają [modyfikatory funkcji](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers) w kontrakcie, zwłaszcza instrukcje `require`, `assert` i `if…else`.
+
+##### 3. Zmierz stopień pokrycia kodu
+
+[Pokrycie kodu](https://en.m.wikipedia.org/wiki/Code_coverage) to metryka testowania, która śledzi liczbę gałęzi, linii i instrukcji w kodzie wykonanych podczas testów. Testy powinny mieć dobre pokrycie, aby zminimalizować ryzyko nieprzetestowanych słabych punktów. Bez wystarczającego pokrycia, można niewłaściwie ocenić kontrakt, jako bezpieczny z uwagi na to, że wszystkie testy zakończyły się poprawnie, podczas gdy słabe punkty wciąż istnieją w nieprzetestowanych ścieżkach kodu. Odnotowanie wysokiego pokrycia kodu daje jednakże pewność, że wszystkie polecania i funkcje w inteligentnym kontrakcie zostały wystarczająco przetestowane pod kątem poprawności.
+
+##### 4. Korzystaj z dobrze rozwiniętych struktur testowych
+
+Jakość narzędzi używanych do testów jednostkowych twojego inteligentnego kontraktu jest kluczowa. Idealne środowisko testowe jest regularnie konserwowane; zawiera użyteczne funkcje (np. rejestrowanie logów czy raportowanie) oraz zostało szeroko wykorzystane przez innych doświadczonych programistów.
+
+Środowiska testów jednostkowych dla inteligentnych kontraktów napisanych w Solidity, dostępne są w różnych językach programowania (głównie JavaScript, Python i Rust). Zapoznaj się z poniższymi przewodnikami w celu uzyskania informacji o przeprowadzaniu testów jednostkowych w różnych środowiskach:
+
+- **[Uruchamianie testów jednostkowych za pomocą Brownie](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)**
+- **[Uruchamianie testów jednostkowych za pomocą Foundry](https://book.getfoundry.sh/forge/writing-tests)**
+- **[Uruchamianie testów jednostkowych za pomocą Waffle](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)**
+- **[Uruchamianie testów jednostkowych za pomocą Remix](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)**
+- **[Uruchamianie testów jednostkowych za pomocą Ape](https://docs.apeworx.io/ape/stable/userguides/testing.html)**
+- **[Uruchamianie testów jednostkowych za pomocą Hardhat](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)**
+- **[Uruchamianie testów jednostkowych za pomocą Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)**
+
+### Testowanie integracyjne {#integration-testing-for-smart-contracts}
+
+Podczas gdy testy jednostkowe służą do debugowania funkcji inteligentnych kontraktów odrębnie, testy integracyjne oceniają komponenty inteligentnego kontraktu jako całość. Testy integracyjne mogą wykryć problemy wynikające z wywołań międzykontraktowych lub interakcji pomiędzy różnymi funkcjami tego samego inteligentnego kontraktu. Na przykład testy integracyjne mogą pomóc sprawdzić, czy takie elementy jak [dziedziczenie](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance) i wstrzykiwanie zależności działają prawidłowo.
+
+Testowanie integracyjne jest przydatne, jeśli Twój kontrakt wykorzystuje architekturę modułową lub łączy się z innymi kontraktami on-chain w trakcie wykonywania. Jednym ze sposobów przeprowadzania testów integracyjnych jest [sforkowanie blockchaina](/glossary/#fork) na określonej wysokości (przy użyciu narzędzia takiego jak [Forge](https://book.getfoundry.sh/forge/fork-testing) lub [Hardhat](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks)) i symulowanie interakcji między Twoim kontraktem a wdrożonymi kontraktami.
+
+Rozdzielony blockchain będzie zachowywał się podobnie do sieci głównej i będzie zawierał konta z przypisanymi im stanami i saldami. Działa jednak tylko jako lokalne środowisko programistyczne w trybie piaskownicy, co oznacza, że nie będziesz potrzebować prawdziwego ETH do transakcji, a Twoje zmiany nie wpłyną na prawdziwy protokół Ethereum.
+
+### Testowanie oparte na właściwościach {#property-based-testing-for-smart-contracts}
+
+Testowanie oparte na właściwościach to proces sprawdzania, czy inteligentny kontrakt spełnia określone właściwości. Właściwości określają fakty dotyczące zachowania kontraktu, które mają pozostać prawdziwe w różnych scenariuszach. Przykładem właściwości inteligentnego kontraktu może być: „Operacje arytmetyczne w kontrakcie nigdy nie przekraczają ani nie przekraczają dozwolonego zakresu”.
+
+**Analiza statyczna** i **analiza dynamiczna** to dwie powszechne techniki przeprowadzania testów opartych na właściwościach, a obie mogą zweryfikować, czy kod programu (w tym przypadku inteligentnego kontraktu) spełnia pewną predefiniowaną właściwość. Niektóre narzędzia do testowania opartego na właściwościach zawierają predefiniowane reguły dotyczące oczekiwanych właściwości kontraktu i sprawdzają, czy kod jest zgodny z tymi regułami, podczas gdy inne umożliwiają tworzenie niestandardowych właściwości dla inteligentnego kontraktu.
+
+#### Analiza statyczna {#static-analysis}
+
+Analizator statyczny przyjmuje jako dane wejściowe kod źródłowy inteligentnego kontraktu i zwraca wyniki deklarujące, czy kontrakt spełnia daną właściwość, czy nie. W przeciwieństwie do analizy dynamicznej analiza statyczna nie polega na wykonywaniu kontraktu w celu sprawdzenia jego poprawności. Analiza statyczna z kolei rozważa wszystkie możliwe ścieżki, którymi inteligentny kontrakt może podążyć podczas wykonywania (tj. bada strukturę kodu źródłowego, aby określić, jakie to będzie miało znaczenie dla działania kontraktu w czasie wykonywania).
+
+[Linting](https://www.perforce.com/blog/qac/what-is-linting) i [testowanie statyczne](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis) to popularne metody przeprowadzania analizy statycznej kontraktów. Obie metody wymagają analizy niskopoziomowych reprezentacji wykonania kontraktu, takich jak [abstrakcyjne drzewa składni](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree) i [grafy przepływu sterowania](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/) generowane przez kompilator.
+
+W większości przypadków analiza statyczna przydaje się do wykrywania problemów bezpieczeństwa, takich jak stosowanie niebezpiecznych konstrukcji, błędy składniowe lub naruszenia standardów kodowania w kodzie kontraktu. Wiadomo jednak, że analizatory statyczne generalnie słabo sobie radzą z wykrywaniem głębszych luk w zabezpieczeniach i mogą generować zbyt wiele fałszywych wyników dodatnich.
+
+#### Analiza dynamiczna {#dynamic-analysis}
+
+Analiza dynamiczna generuje symboliczne dane wejściowe (np. w [wykonaniu symbolicznym](https://en.m.wikipedia.org/wiki/Symbolic_execution)) lub konkretne dane wejściowe (np. w [fuzzingu](https://owasp.org/www-community/Fuzzing)) do funkcji inteligentnych kontraktów, aby sprawdzić, czy jakikolwiek ślad wykonania narusza określone właściwości. Ta forma testowania opartego na właściwościach różni się od testów jednostkowych tym, że przypadki testowe obejmują wiele scenariuszy, a generowaniem przypadków testowych zajmuje się program.
+
+[Fuzzing](https://www.halborn.com/blog/post/what-is-fuzz-testing-fuzzing) jest przykładem dynamicznej techniki analitycznej służącej do weryfikacji dowolnych właściwości w inteligentnych kontraktach. Fuzzer wywołuje funkcje w kontrakcie docelowym z losowymi lub błędnymi wariantami zdefiniowanej wartości wejściowej. Jeśli inteligentny kontrakt wejdzie w stan błędu (np. taki, w którym potwierdzenie nie powiedzie się), problem zostanie oznaczony, a dane wejściowe kierujące wykonanie na podatną ścieżkę zostaną wygenerowane w raporcie.
+
+Fuzzing jest przydatne do oceny mechanizmu walidacji danych wejściowych inteligentnych kontraktów, ponieważ niewłaściwa obsługa nieoczekiwanych danych wejściowych może skutkować niezamierzonym wykonaniem i wywołać niebezpieczne skutki. Ta forma testowania opartego na właściwościach może być idealna z wielu powodów:
+
+1. **Pisanie przypadków testowych obejmujących wiele scenariuszy jest trudne.** Test właściwości wymaga jedynie zdefiniowania zachowania i zakresu danych, za pomocą których można przetestować to zachowanie — program automatycznie generuje przypadki testowe na podstawie zdefiniowanej właściwości.
+
+2. **Zestaw testów może nie obejmować w wystarczającym stopniu wszystkich możliwych ścieżek w programie.** Nawet przy 100% pokryciu istnieje ryzyko pominięcia przypadków brzegowych.
+
+3. **Testy jednostkowe sprawdzają, czy kontrakt wykonuje się poprawnie dla danych z próbki, ale nie wiadomo, czy kontrakt wykonuje się poprawnie dla danych wejściowych spoza próbki.** Testy właściwości wykonują docelowy kontrakt z wieloma wariantami danej wartości wejściowej w celu znalezienia śladów wykonania powodujących błędy asercji. Zatem test właściwości daje większą gwarancję, że kontrakt zostanie wykonany prawidłowo dla szerokiej klasy danych wejściowych.
+
+### Wskazówki dotyczące przeprowadzania testów opartych na właściwościach dla inteligentnych kontraktów {#running-property-based-tests}
+
+Przeprowadzanie testów opartych na właściwościach zazwyczaj rozpoczyna się od zdefiniowania właściwości (np. braku [przepełnień liczb całkowitych](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow)) lub zbioru właściwości, które chcesz zweryfikować w inteligentnym kontrakcie. Podczas pisania testów właściwości może być również konieczne zdefiniowanie zakresu wartości, w ramach których program może generować dane dla danych wejściowych transakcji.
+
+Po poprawnym skonfigurowaniu narzędzie do testowania nieruchomości będzie wykonywać funkcje inteligentnych kontraktów przy użyciu losowo generowanych danych wejściowych. Jeśli wystąpią jakiekolwiek naruszenia asercji, powinieneś otrzymać raport z konkretnymi danymi wejściowymi, które naruszają ocenianą właściwość. Aby rozpocząć testowanie oparte na właściwościach za pomocą różnych narzędzi, zapoznaj się z poniższymi przewodnikami:
+
+- **[Analiza statyczna inteligentnych kontraktów za pomocą Slither](https://github.com/crytic/slither)**
+- **[Analiza statyczna inteligentnych kontraktów za pomocą Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)**
+- **[Testowanie oparte na właściwościach za pomocą Brownie](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)**
+- **[Fuzzing kontraktów za pomocą Foundry](https://book.getfoundry.sh/forge/fuzz-testing)**
+- **[Fuzzing kontraktów za pomocą Echidna](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)**
+- **[Fuzzing kontraktów za pomocą Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)**
+- **[Symboliczne wykonanie inteligentnych kontraktów za pomocą Manticore](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)**
+- **[Symboliczne wykonanie inteligentnych kontraktów za pomocą Mythril](https://mythril-classic.readthedocs.io/en/master/tutorial.html)**
+
+## Ręczne testowanie inteligentnych kontraktów {#manual-testing-for-smart-contracts}
+
+Testowanie manualne inteligentnych kontraktów przeprowadzane jest często w późnym etapie cyklu rozwoju produktu, już po testach automatycznych. Ta forma testowania ocenia inteligentny kontrakt jako jeden w pełni zintegrowany produkt, aby sprawdzić, czy działa zgodnie ze specyfikacją techniczną.
+
+### Testowanie kontraktów na lokalnym blockchainie {#testing-on-local-blockchain}
+
+Podczas gdy testowanie zautomatyzowane przeprowadzone w lokalny środowisku programistycznym może zapewnić przydatne informacje o debugowaniu, warto wiedzieć również, jak inteligentny kontrakt zachowuje się w środowisku produkcyjnym. Jednakże wdrożenie do głównej sieci Ethereum wiąże się z opłatami gazowymi — nie wspominając już o tym, że użytkownicy mogą stracić prawdziwe pieniądze, jeśli Twój inteligentny kontrakt wciąż zawiera błędy.
+
+Testowanie kontraktu na lokalnym blockchainie (znanym również jako [sieć deweloperska](/developers/docs/development-networks/)) jest zalecaną alternatywą dla testowania w sieci Mainnet. Blockchain lokalny jest kopią blockchainu Ethereum uruchomioną lokalnie na twoim komputerze, która symuluje zachowanie warstwy wykonawczej Ethereum. Dzięki temu możesz zaprogramować transakcje do interakcji z kontraktem bez konieczności ponoszenia znaczących kosztów.
+
+Uruchamianie kontraktów na blockchainie lokalnym może być przydatną formą testowania manualnego. [Inteligentne kontrakty są wysoce komponowalne](/developers/docs/smart-contracts/composability/), co pozwala na integrację z istniejącymi protokołami — ale nadal trzeba się upewnić, że tak złożone interakcje na łańcuchu dają prawidłowe wyniki.
+
+[Więcej o sieciach deweloperskich.](/developers/docs/development-networks/)
+
+### Testowanie kontraktów w sieciach testowych {#testing-contracts-on-testnets}
+
+Sieci testowe działają dokładnie jak sieć główna Ethereum z tą różnicą, że używają eteru (ETH), który nie ma rzeczywistej wartości. Wdrożenie kontraktu w [sieci testowej](/developers/docs/networks/#ethereum-testnets) oznacza, że każdy może wejść z nim w interakcję (np. za pośrednictwem frontendu dapki) bez narażania środków na ryzyko.
+
+Ta forma testowania manualnego jest przydatna w szczegółowej ocenie przepływu aplikacji z perspektywy użytkownika. Tu beta testerzy mogą również przeprowadzać testy i raportować wszelkie problemy w logice biznesowej kontraktu oraz jego ogólnej funkcjonalności.
+
+Wdrożenie na sieci testowej po testowaniu na lokalnym blockchainie jest idealne z uwagi na to, że w przypadku pierwszego zachowanie bliższe jest wirtualnej maszynie Ethereum. Jest zatem powszechne wśród wielu natywnych projektów Ethereum, aby wdrożyć dapkę na sieć testową w celu oceny inteligentnego kontraktu w warunkach odpowiadających tym ze świata rzeczywistego.
+
+[Więcej o sieciach testowych Ethereum.](/developers/docs/development-networks/#public-beacon-testchains)
+
+## Testowanie a weryfikacja formalna {#testing-vs-formal-verification}
+
+Choć testowanie pomaga potwierdzić, że kontrakt daje zakładane rezultaty dla niektórych danych wejściowych, nie może ono jednoznacznie dowieźć tego samego dla danych wejściowych, które nie były użyte podczas testów. Testowanie inteligentnego kontraktu nie może zatem zagwarantować "poprawności funkcjonalnej" (tzn. nie może wykazać, że program zachowuje się zgodnie z wymaganiami dla _wszystkich_ zestawów wartości wejściowych).
+
+Formalna weryfikacja jest podejściem do oceny poprawności oprogramowania poprzez sprawdzenie, czy formalny model programu zgadza się z formalną specyfikacją. Model formalny jest abstrakcyjną matematyczną reprezentacją programy, podczas gdy specyfikacja formalna definiuje własności programu (np. logiczne założenia na temat działania programu).
+
+Ponieważ własności te zapisane są w jeżyku matematycznym, możliwym staje się zweryfikowanie czy formalnym (matematyczny) model systemu odpowiada specyfikacji, korzystając z logicznych reguł wnioskowaniu. Narzędzia formalnej weryfikacji mają zatem za zadanie dostarczyć "matematyczny dowód" poprawności systemu.
+
+W przeciwieństwie do testowania weryfikacja formalna może być użyta do sprawdzenia, czy wykonanie inteligentnego kontraktu spełnia formalną specyfikację dla _wszystkich_ wykonań (tzn. nie ma błędów), bez potrzeby uruchamiania go na przykładowych danych. To nie tylko skraca czas poświęcony na przeprowadzenie wielu testów jednostkowych, ale również jest bardziej efektywne w wychwytywaniu ukrytych słabych punktów. Należy jednak pamiętać, że techniki formalnej weryfikacji prezentują całe spektrum trudności implementacji oraz użyteczności.
+
+[Więcej o formalnej weryfikacji inteligentnych kontraktów.](/developers/docs/smart-contracts/formal-verification)
+
+## Testowanie a audyty i programy bug bounty {#testing-vs-audits-bug-bounties}
+
+Jak wspomniano powyżej, rygorystyczne testowanie rzadko może zagwarantować kompletny brak błędów w kontrakcie; podejście weryfikacji formalnej może zapewnić silniejsze przekonanie o poprawności, ale obecnie jest trudne w użyciu i kosztowne.
+
+Można jednak jeszcze bardziej zwiększyć szansę na wyłapanie słabego punktu w kontrakcie poprzez przegląd kodu przeprowadzony przez niezależny podmiot. [Audyty inteligentnych kontraktów](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/) i [programy bug bounty](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) to dwa sposoby na zaangażowanie innych do analizy Twoich kontraktów.
+
+Audyty przeprowadzane są przez audytorów doświadczonych w odnajdywaniu przypadków błędów zabezpieczeń i kiepskich rozwiązań programistycznych w inteligentnych kontraktach. Audyt zawiera zwykle testowanie (czasem również weryfikację formalną) jak również ręczny przegląd całej bazy kodu.
+
+I na odwrót, program bug bounty zwykle polega na oferowaniu nagrody finansowej osobie (powszechnie określanej jako [haker w białym kapeluszu](https://en.wikipedia.org/wiki/White_hat_\(computer_security\))), która odkryje lukę w zabezpieczeniach inteligentnego kontraktu i ujawni ją deweloperom. Nagrody za znalezienie błędu są podobne do audytów, ponieważ obejmują proszenie innych o pomoc w znalezieniu defektów inteligentnego kontraktu.
+
+Główną różnicą jest to, że programy nagród za znalezienie błędów są otwarte dla szerszej społeczności programistów i hakerów. Przyciągają również szeroką grupę hakerów etycznych i niezależnych specjalistów od bezpieczeństwa wyposażonych w unikalne umiejętności i doświadczenie. To może być ich przewaga nad audytami, które bazują głównie na zespołach, które mogą mieć ograniczoną lub wąską ekspertyzę.
+
## Narzędzia i biblioteki do testowania {#testing-tools-and-libraries}
-**Waffle –** **framework pozwalający na tworzenie i testowanie zaawansowanych kontraktów (oparty na ethers.js).**
+### Narzędzia do testowania jednostkowego {#unit-testing-tools}
+
+- **[solidity-coverage](https://github.com/sc-forks/solidity-coverage)** – _narzędzie do sprawdzania pokrycia kodu dla inteligentnych kontraktów napisanych w Solidity._
+
+- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** – _framework do zaawansowanego tworzenia i testowania inteligentnych kontraktów (oparty na ethers.js)._
+
+- **[Remix Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** – _narzędzie do testowania inteligentnych kontraktów w Solidity._ Działa pod wtyczką do Remix IDE pod nazwą "Solidity Unit Testing", która jest używana do pisania i przeprowadzania testów na kontrakcie._
+
+- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** – _biblioteka asercji do testowania inteligentnych kontraktów Ethereum._ Upewnij się, że Twoje kontrakty zachowują się zgodnie z oczekiwaniami!_
+
+- **[Framework do testów jednostkowych Brownie](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** – _Brownie wykorzystuje Pytest, bogaty w funkcje framework testowy, który pozwala pisać małe testy przy minimalnej ilości kodu, dobrze skaluje się w przypadku dużych projektów i jest wysoce rozszerzalny._
+
+- **[Testy Foundry](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** – _Foundry oferuje Forge, szybki i elastyczny framework do testowania Ethereum, zdolny do wykonywania prostych testów jednostkowych, sprawdzania optymalizacji gazu i fuzzingu kontraktów._
+
+- **[Testy Hardhat](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** – _framework do testowania inteligentnych kontraktów oparty na ethers.js, Mocha i Chai._
+
+- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** – _oparty na Pythonie framework do tworzenia i testowania inteligentnych kontraktów dla Wirtualnej Maszyny Ethereum._
+
+- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** – _oparty na Pythonie framework do testowania jednostkowego i fuzzingu z zaawansowanymi możliwościami debugowania i obsługą testowania międzyłańcuchowego, wykorzystujący pytest i Anvil w celu uzyskania najlepszego doświadczenia użytkownika i wydajności._
+
+### Narzędzia do testowania opartego na właściwościach {#property-based-testing-tools}
+
+#### Narzędzia do analizy statycznej {#static-analysis-tools}
+
+- **[Slither](https://github.com/crytic/slither)** – _oparty na Pythonie framework do statycznej analizy Solidity, służący do znajdowania luk w zabezpieczeniach, poprawy zrozumienia kodu i pisania niestandardowych analiz dla inteligentnych kontraktów._
+
+- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** – _Linter do egzekwowania najlepszych praktyk w zakresie stylu i bezpieczeństwa dla języka programowania inteligentnych kontraktów Solidity._
-- [getwaffle.io](https://getwaffle.io/)
-- [GitHub](https://github.com/EthWorks/Waffle)
+- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** – _oparty na Rust analizator statyczny zaprojektowany specjalnie z myślą o bezpieczeństwie i rozwoju inteligentnych kontraktów Web3._
-**Solidity-Coverage –** **alternatywne narzędzie do kodu Solidity.**
+- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** – _oparty na Pythonie framework do analizy statycznej z detektorami luk i jakości kodu, drukarkami do wyodrębniania przydatnych informacji z kodu oraz wsparciem dla pisania niestandardowych podmodułów._
-- [GitHub](https://github.com/sc-forks/solidity-coverage)
+- **[Slippy](https://github.com/fvictorio/slippy)** – _prosty i potężny linter dla Solidity._
-**Whiteblock Genesis –** **kompleksowy piaskownica deweloperska i platforma testowa dla blockchainu.**
+#### Narzędzia do analizy dynamicznej {#dynamic-analysis-tools}
-- [Whiteblock.io](https://whiteblock.io)
-- [Dokumentacja](https://docs.whiteblock.io)
-- [GitHub](https://github.com/whiteblock/genesis)
+- **[Echidna](https://github.com/crytic/echidna/)** – _szybki fuzzer kontraktów do wykrywania luk w inteligentnych kontraktach poprzez testowanie oparte na właściwościach._
-**Środowisko testowe OpenZeppelin –** **szybkie testowanie inteligentnych kontraktów. Jednowierszowa konfiguracja zapewniająca doskonałe wrażenia podczas testowania.**
+- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** – _zautomatyzowane narzędzie do fuzzingu przydatne do wykrywania naruszeń właściwości w kodzie inteligentnych kontraktów._
-- [GitHub](https://github.com/OpenZeppelin/openzeppelin-test-environment)
-- [Dokumentacja](https://docs.openzeppelin.com/test-environment/)
+- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** – _dynamiczny framework do symbolicznego wykonywania analizy kodu bajtowego EVM._
-**OpenZeppelin Test Helpers –** **biblioteka asercji do testowania inteligentnych kontraktów Ethereum. Upewnij się, że Twoje kontrakty zachowują się zgodnie z oczekiwaniami!**
+- **[Mythril](https://github.com/ConsenSys/mythril-classic)** – _narzędzie do oceny kodu bajtowego EVM do wykrywania luk w kontraktach przy użyciu analizy skażenia, analizy konkolikowej i sprawdzania przepływu sterowania._
-- [GitHub](https://github.com/OpenZeppelin/openzeppelin-test-helpers)
-- [Dokumentacja](https://docs.openzeppelin.com/test-helpers)
+- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** – _Scribble to język specyfikacji i narzędzie do weryfikacji w czasie wykonywania, które pozwala na adnotowanie inteligentnych kontraktów właściwościami, które umożliwiają automatyczne testowanie kontraktów za pomocą narzędzi takich jak Diligence Fuzzing lub MythX._
## Powiązane samouczki {#related-tutorials}
-- [Narzędzia testowe](/developers/tutorials/guide-to-smart-contract-security-tools/) _– przegląd i porównanie różnych narzędzi testowych_
-- [Echidna – narzędzie do testowania inteligentnych kontraktów](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/)
-- [Manticore – narzędzie do znajdowania błędów w inteligentnych kontraktach](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
-- [Slither – narzędzie do znajdowania błędów w inteligentnych kontraktach](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
-- [Jak tworzyć kontrakty Solidity pod kątem testowania](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/)
+- [Przegląd i porównanie różnych produktów do testowania](/developers/tutorials/guide-to-smart-contract-security-tools/) \_
+- [Jak używać Echidna do testowania inteligentnych kontraktów](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/)
+- [Jak używać Manticore do znajdowania błędów w inteligentnych kontraktach](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
+- [Jak używać Slither do znajdowania błędów w inteligentnych kontraktach](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
+- [Jak mockować kontrakty Solidity na potrzeby testowania](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/)
+- [Jak uruchamiać testy jednostkowe w Solidity przy użyciu Foundry](https://www.rareskills.io/post/foundry-testing-solidity)
## Dalsza lektura {#further-reading}
-_Znasz jakieś zasoby społeczności, które Ci pomogły? Wyedytuj tę stronę i dodaj je!_
+- [Szczegółowy przewodnik po testowaniu inteligentnych kontraktów Ethereum](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297)
+- [Jak testować inteligentne kontrakty Ethereum](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d)
+- [Przewodnik po testowaniu jednostkowym dla programistów od MolochDAO](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide)
+- [Jak testować inteligentne kontrakty jak gwiazda rocka](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001)
diff --git a/public/content/translations/pl/developers/docs/smart-contracts/upgrading/index.md b/public/content/translations/pl/developers/docs/smart-contracts/upgrading/index.md
new file mode 100644
index 00000000000..fdccf2b04f6
--- /dev/null
+++ b/public/content/translations/pl/developers/docs/smart-contracts/upgrading/index.md
@@ -0,0 +1,165 @@
+---
+title: "Aktualizowanie inteligentnych kontraktów"
+description: "Przegląd wzorców uaktualnień dla inteligentnych kontraktów Ethereum"
+lang: pl
+---
+
+Inteligentne kontrakty na Ethereum to samowykonujące się programy, które działają w Wirtualnej Maszynie Ethereum (EVM). Programy te są z założenia niezmienne, co uniemożliwia jakiekolwiek aktualizacje logiki biznesowej po wdrożeniu kontraktu.
+
+Chociaż niezmienność jest niezbędna dla braku zaufania, decentralizacji i bezpieczeństwa inteligentnych kontraktów, w niektórych przypadkach może być wadą. Na przykład, niezmienny kod może uniemożliwić deweloperom naprawę podatnych na ataki kontraktów.
+
+Jednak wzmożone badania nad ulepszaniem inteligentnych kontraktów doprowadziły do wprowadzenia kilku wzorców uaktualnień. Te wzorce uaktualnień umożliwiają deweloperom uaktualnianie inteligentnych kontraktów (przy jednoczesnym zachowaniu niezmienności) poprzez umieszczanie logiki biznesowej w różnych kontraktach.
+
+## Wymagania wstępne {#prerequisites}
+
+Warto mieć dobre pojęcie o [inteligentnych kontraktach](/developers/docs/smart-contracts/), [anatomii inteligentnych kontraktów](/developers/docs/smart-contracts/anatomy/) i [Wirtualnej Maszynie Ethereum (EVM)](/developers/docs/evm/). Ten przewodnik zakłada również, że czytelnicy mają pojęcie o programowaniu inteligentnych kontraktów.
+
+## Czym jest uaktualnienie inteligentnego kontraktu? {#what-is-a-smart-contract-upgrade}
+
+Uaktualnienie inteligentnego kontraktu polega na zmianie logiki biznesowej inteligentnego kontraktu przy jednoczesnym zachowaniu jego stanu. Należy wyjaśnić, że możliwość uaktualniania i zmienność to nie to samo, zwłaszcza w kontekście inteligentnych kontraktów.
+
+Nadal nie można zmienić programu wdrożonego pod danym adresem w sieci Ethereum. Można jednak zmienić kod, który jest wykonywany, gdy użytkownicy wchodzą w interakcję z inteligentnym kontraktem.
+
+Można to zrobić za pomocą następujących metod:
+
+1. Tworzenie wielu wersji inteligentnego kontraktu i migrowanie stanu (tj. danych) ze starego kontraktu do nowej instancji kontraktu.
+
+2. Tworzenie oddzielnych kontraktów do przechowywania logiki biznesowej i stanu.
+
+3. Używanie wzorców proxy do delegowania wywołań funkcji z niezmiennego kontraktu proxy do modyfikowalnego kontraktu logicznego.
+
+4. Tworzenie niezmiennego kontraktu głównego, który współdziała i opiera się na elastycznych kontraktach satelitarnych w celu wykonywania określonych funkcji.
+
+5. Używanie wzorca diamentowego do delegowania wywołań funkcji z kontraktu proxy do kontraktów logicznych.
+
+### Mechanizm uaktualniania nr 1: migracja kontraktu {#contract-migration}
+
+Migracja kontraktów opiera się na wersjonowaniu – idei tworzenia unikalnych stanów tego samego oprogramowania i zarządzania nimi. Migracja kontraktu polega na wdrożeniu nowej instancji istniejącego inteligentnego kontraktu i przeniesieniu pamięci oraz sald do nowego kontraktu.
+
+Nowo wdrożony kontrakt będzie miał pustą pamięć, co pozwoli odzyskać dane ze starego kontraktu i zapisać je do nowej implementacji. Następnie trzeba będzie zaktualizować wszystkie kontrakty, które wchodziły w interakcję ze starym kontraktem, aby odzwierciedlały nowy adres.
+
+Ostatnim krokiem w migracji kontraktu jest przekonanie użytkowników do przejścia na korzystanie z nowego kontraktu. Nowa wersja kontraktu zachowa salda i adresy użytkowników, co zapewnia niezmienność. Jeśli jest to kontrakt oparty na tokenach, konieczne będzie również skontaktowanie się z giełdami w celu odrzucenia starego kontraktu i użycia nowego.
+
+Migracja kontraktów jest stosunkowo prostym i bezpiecznym sposobem na uaktualnienie inteligentnych kontraktów bez zakłócania interakcji z użytkownikiem. Jednak ręczne migrowanie pamięci i sald użytkowników do nowego kontraktu jest czasochłonne i może wiązać się z wysokimi kosztami gazu.
+
+[Więcej o migracji kontraktów.](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/)
+
+### Mechanizm uaktualniania nr 2: separacja danych {#data-separation}
+
+Inną metodą uaktualniania inteligentnych kontraktów jest rozdzielenie logiki biznesowej i przechowywania danych na oddzielne kontrakty. Oznacza to, że użytkownicy wchodzą w interakcję z kontraktem logicznym, podczas gdy dane są przechowywane w kontrakcie pamięci.
+
+Kontrakt logiczny zawiera kod wykonywany, gdy użytkownicy wchodzą w interakcję z aplikacją. Przechowuje on również adres kontraktu pamięci i wchodzi z nim w interakcję w celu pobierania i ustawiania danych.
+
+Tymczasem kontrakt pamięci przechowuje stan powiązany z inteligentnym kontraktem, taki jak salda i adresy użytkowników. Należy pamiętać, że kontrakt pamięci jest własnością kontraktu logicznego i jest konfigurowany z adresem tego ostatniego w momencie wdrożenia. Zapobiega to wywoływaniu kontraktu pamięci lub aktualizowaniu jego danych przez nieautoryzowane kontrakty.
+
+Domyślnie kontrakt pamięci jest niezmienny — można jednak zastąpić kontrakt logiczny, na który wskazuje, nową implementacją. Spowoduje to zmianę kodu działającego w EVM, przy jednoczesnym zachowaniu nienaruszonej pamięci i sald.
+
+Użycie tej metody uaktualniania wymaga zaktualizowania adresu kontraktu logicznego w kontrakcie pamięci. Należy również skonfigurować nowy kontrakt logiczny z adresem kontraktu pamięci z powodów wyjaśnionych wcześniej.
+
+Wzór separacji danych jest prawdopodobnie łatwiejszy do wdrożenia w porównaniu z migracją kontraktów. Jednakże trzeba będzie zarządzać wieloma kontraktami i wdrażać złożone schematy autoryzacji w celu ochrony inteligentnych kontraktów przed złośliwymi uaktualnieniami.
+
+### Mechanizm uaktualniania nr 3: wzorce proxy {#proxy-patterns}
+
+Wzorzec proxy wykorzystuje również separację danych do przechowywania logiki biznesowej i danych w oddzielnych kontraktach. Jednak we wzorcu proxy kontrakt pamięci (nazywany proxy) wywołuje kontrakt logiczny podczas wykonywania kodu. Jest to odwrócenie metody separacji danych, w której kontrakt logiczny wywołuje kontrakt pamięci.
+
+Oto, co dzieje się we wzorcu proxy:
+
+1. Użytkownicy wchodzą w interakcję z kontraktem proxy, który przechowuje dane, ale nie zawiera logiki biznesowej.
+
+2. Kontrakt proxy przechowuje adres kontraktu logicznego i deleguje wszystkie wywołania funkcji do kontraktu logicznego (który przechowuje logikę biznesową) za pomocą funkcji `delegatecall`.
+
+3. Po przekazaniu wywołania do kontraktu logicznego, dane zwrócone z kontraktu logicznego są pobierane i zwracane użytkownikowi.
+
+Korzystanie z wzorców proxy wymaga zrozumienia funkcji **delegatecall**. Zasadniczo `delegatecall` to kod operacji, który pozwala jednemu kontraktowi wywołać inny, podczas gdy rzeczywiste wykonanie kodu odbywa się w kontekście kontraktu wywołującego. Implikacją użycia `delegatecall` we wzorcach proxy jest to, że kontrakt proxy odczytuje i zapisuje w swojej pamięci oraz wykonuje logikę przechowywaną w kontrakcie logicznym tak, jakby wywoływał funkcję wewnętrzną.
+
+Z [dokumentacji Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries):
+
+> _Istnieje specjalny wariant wywołania komunikatu, nazwany **delegatecall**, który jest identyczny z wywołaniem komunikatu, z tą różnicą, że kod pod adresem docelowym jest wykonywany w kontekście (tj. pod adresem) kontraktu wywołującego, a `msg.sender` i `msg.value` nie zmieniają swoich wartości._ _Oznacza to, że kontrakt może dynamicznie ładować kod z innego adresu w czasie wykonywania. Pamięć, bieżący adres i saldo nadal odnoszą się do kontraktu wywołującego, tylko kod jest pobierany z wywoływanego adresu._
+
+Kontrakt proxy wie, że ma wywołać `delegatecall` za każdym razem, gdy użytkownik wywoła funkcję, ponieważ ma wbudowaną funkcję `fallback`. W programowaniu w Solidity [funkcja zastępcza](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) jest wykonywana, gdy wywołanie funkcji nie pasuje do funkcji określonych w kontrakcie.
+
+Aby wzorzec proxy zadziałał, należy napisać niestandardową funkcję zastępczą, która określa, w jaki sposób kontrakt proxy powinien obsługiwać wywołania funkcji, których nie obsługuje. W tym przypadku funkcja zastępcza proxy jest zaprogramowana do inicjowania wywołania delegatecall i przekierowywania żądania użytkownika do bieżącej implementacji kontraktu logicznego.
+
+Kontrakt proxy jest domyślnie niezmienny, ale można tworzyć nowe kontrakty logiczne ze zaktualizowaną logiką biznesową. Przeprowadzenie uaktualnienia jest zatem kwestią zmiany adresu kontraktu logicznego, do którego odwołuje się kontrakt proxy.
+
+Poprzez wskazanie kontraktu proxy na nowy kontrakt logiczny, zmienia się kod wykonywany, gdy użytkownicy wywołują funkcję kontraktu proxy. Pozwala to na uaktualnienie logiki kontraktu bez konieczności proszenia użytkowników o interakcję z nowym kontraktem.
+
+Wzorce proxy są popularną metodą uaktualniania inteligentnych kontraktów, ponieważ eliminują trudności związane z migracją kontraktów. Jednak wzorce proxy są bardziej skomplikowane w użyciu i mogą wprowadzać krytyczne wady, takie jak [kolizje selektorów funkcji](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357), jeśli są używane niewłaściwie.
+
+[Więcej o wzorcach proxy](https://blog.openzeppelin.com/proxy-patterns/).
+
+### Mechanizm uaktualniania nr 4: wzorzec strategii {#strategy-pattern}
+
+Technika ta jest inspirowana [wzorcem strategii](https://en.wikipedia.org/wiki/Strategy_pattern), który zachęca do tworzenia programów, które współdziałają z innymi programami w celu implementacji określonych funkcji. Zastosowanie wzorca strategii w rozwoju Ethereum oznaczałoby zbudowanie inteligentnego kontraktu, który wywołuje funkcje z innych kontraktów.
+
+Główny kontrakt w tym przypadku zawiera podstawową logikę biznesową, ale współdziała z innymi inteligentnymi kontraktami („kontraktami satelitarnymi”) w celu wykonania określonych funkcji. Ten główny kontrakt przechowuje również adres każdego kontraktu satelitarnego i może przełączać się między różnymi implementacjami kontraktu satelitarnego.
+
+Można zbudować nowy kontrakt satelitarny i skonfigurować główny kontrakt z nowym adresem. Pozwala to na zmianę _strategii_ (tj. implementację nowej logiki) dla inteligentnego kontraktu.
+
+Chociaż jest podobny do omówionego wcześniej wzorca proxy, wzorzec strategii jest inny, ponieważ główny kontrakt, z którym wchodzą w interakcję użytkownicy, przechowuje logikę biznesową. Korzystanie z tego wzorca daje możliwość wprowadzenia ograniczonych zmian do inteligentnego kontraktu bez wpływu na podstawową infrastrukturę.
+
+Główną wadą jest to, że wzorzec ten jest przydatny głównie do wprowadzania drobnych uaktualnień. Ponadto, jeśli główny kontrakt zostanie naruszony (np. w wyniku włamania), nie można użyć tej metody uaktualniania.
+
+### Mechanizm uaktualniania nr 5: wzorzec diamentowy {#diamond-pattern}
+
+Wzorzec diamentowy można uznać za ulepszenie wzorca proxy. Wzorce diamentowe różnią się od wzorców proxy, ponieważ diamentowy kontrakt proxy może delegować wywołania funkcji do więcej niż jednego kontraktu logicznego.
+
+Kontrakty logiczne we wzorcu diamentowym są znane jako _facety_. Aby wzorzec diamentowy zadziałał, należy utworzyć w kontrakcie proxy mapowanie, które mapuje [selektory funkcji](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) na różne adresy facet.
+
+Gdy użytkownik wykonuje wywołanie funkcji, kontrakt proxy sprawdza mapowanie, aby znaleźć facet odpowiedzialny za wykonanie tej funkcji. Następnie wywołuje `delegatecall` (używając funkcji zastępczej) i przekierowuje wywołanie do odpowiedniego kontraktu logicznego.
+
+Wzorzec uaktualniania diamentowego ma pewne zalety w stosunku do tradycyjnych wzorców uaktualniania proxy:
+
+1. Pozwala uaktualnić niewielką część kontraktu bez zmiany całego kodu. Użycie wzorca proxy do uaktualnień wymaga utworzenia zupełnie nowego kontraktu logicznego, nawet w przypadku drobnych uaktualnień.
+
+2. Wszystkie inteligentne kontrakty (w tym kontrakty logiczne używane we wzorcach proxy) mają limit rozmiaru 24 KB, co może być ograniczeniem — zwłaszcza w przypadku złożonych kontraktów wymagających większej liczby funkcji. Wzorzec diamentowy ułatwia rozwiązanie tego problemu poprzez podział funkcji na wiele kontraktów logicznych.
+
+3. Wzorce proxy przyjmują uniwersalne podejście do kontroli dostępu. Podmiot mający dostęp do funkcji uaktualniania może zmienić _cały_ kontrakt. Wzorzec diamentowy umożliwia jednak modułowe podejście do uprawnień, w którym można ograniczyć podmioty do uaktualniania tylko określonych funkcji w ramach inteligentnego kontraktu.
+
+[Więcej na temat wzorca diamentowego](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w).
+
+## Zalety i wady uaktualniania inteligentnych kontraktów {#pros-and-cons-of-upgrading-smart-contracts}
+
+| Zalety | Wady |
+| -------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Uaktualnienie inteligentnego kontraktu może ułatwić naprawę luk w zabezpieczeniach wykrytych w fazie po wdrożeniu. | Uaktualnianie inteligentnych kontraktów zaprzecza idei niezmienności kodu, co ma implikacje dla decentralizacji i bezpieczeństwa. |
+| Deweloperzy mogą używać uaktualnień logiki do dodawania nowych funkcji do zdecentralizowanych aplikacji. | Użytkownicy muszą ufać deweloperom, że nie będą arbitralnie modyfikować inteligentnych kontraktów. |
+| Uaktualnienia inteligentnych kontraktów mogą poprawić bezpieczeństwo użytkowników końcowych, ponieważ błędy mogą być szybko naprawiane. | Programowanie funkcjonalności uaktualniania w inteligentnych kontraktach dodaje kolejną warstwę złożoności i zwiększa możliwość wystąpienia krytycznych wad. |
+| Uaktualnienia kontraktów dają deweloperom więcej przestrzeni do eksperymentowania z różnymi funkcjami i ulepszania dapek w miarę upływu czasu. | Możliwość uaktualniania inteligentnych kontraktów może zachęcać deweloperów do szybszego uruchamiania projektów bez zachowania należytej staranności na etapie rozwoju. |
+| | Niezabezpieczona kontrola dostępu lub centralizacja w inteligentnych kontraktach może ułatwić złośliwym podmiotom przeprowadzanie nieautoryzowanych uaktualnień. |
+
+## Kwestie do rozważenia przy uaktualnianiu inteligentnych kontraktów {#considerations-for-upgrading-smart-contracts}
+
+1. Używaj bezpiecznych mechanizmów kontroli dostępu/autoryzacji, aby zapobiec nieautoryzowanym uaktualnieniom inteligentnych kontraktów, zwłaszcza w przypadku korzystania z wzorców proxy, wzorców strategii lub separacji danych. Przykładem jest ograniczenie dostępu do funkcji uaktualniania w taki sposób, aby tylko właściciel kontraktu mógł ją wywołać.
+
+2. Uaktualnianie inteligentnych kontraktów jest złożonym działaniem i wymaga wysokiego poziomu staranności, aby zapobiec wprowadzeniu luk w zabezpieczeniach.
+
+3. Zmniejsz założenia dotyczące zaufania poprzez decentralizację procesu wdrażania uaktualnień. Możliwe strategie obejmują użycie [kontraktu portfela z wieloma podpisami](/developers/docs/smart-contracts/#multisig) do kontrolowania uaktualnień lub wymaganie od [członków DAO](/dao/) głosowania w sprawie zatwierdzenia uaktualnienia.
+
+4. Należy pamiętać o kosztach związanych z uaktualnianiem kontraktów. Na przykład kopiowanie stanu (np. sald użytkowników) ze starego kontraktu do nowego podczas migracji kontraktu może wymagać więcej niż jednej transakcji, co oznacza wyższe opłaty za gaz.
+
+5. Rozważ wdrożenie **blokad czasowych** w celu ochrony użytkowników. Blokada czasowa odnosi się do opóźnienia narzuconego na zmiany w systemie. Blokady czasowe można połączyć z systemem zarządzania z wieloma podpisami w celu kontrolowania uaktualnień: jeśli proponowane działanie osiągnie wymagany próg zatwierdzenia, nie zostanie wykonane, dopóki nie upłynie z góry określony okres opóźnienia.
+
+Blokady czasowe dają użytkownikom trochę czasu na opuszczenie systemu, jeśli nie zgadzają się z proponowaną zmianą (np. uaktualnieniem logiki lub nowymi schematami opłat). Bez blokad czasowych użytkownicy muszą ufać deweloperom, że nie wprowadzą arbitralnych zmian w inteligentnym kontrakcie bez uprzedniego powiadomienia. Wadą jest to, że blokady czasowe ograniczają możliwość szybkiego łatania luk w zabezpieczeniach.
+
+## Zasoby {#resources}
+
+**Wtyczki uaktualnień OpenZeppelin – _zestaw narzędzi do wdrażania i zabezpieczania uaktualnialnych inteligentnych kontraktów._**
+
+- [GitHub](https://github.com/OpenZeppelin/openzeppelin-upgrades)
+- [Dokumentacja](https://docs.openzeppelin.com/upgrades)
+
+## Samouczki {#tutorials}
+
+- [Uaktualnianie inteligentnych kontraktów | samouczek na YouTube](https://www.youtube.com/watch?v=bdXJmWajZRY) autorstwa Patricka Collinsa
+- [Samouczek migracji inteligentnych kontraktów Ethereum](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) autorstwa Austina Griffitha
+- [Używanie wzorca proxy UUPS do uaktualniania inteligentnych kontraktów](https://blog.logrocket.com/author/praneshas/) autorstwa Pranesh A.S
+- [Samouczek Web3: napisz uaktualnialny inteligentny kontrakt (proxy) za pomocą OpenZeppelin](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) autorstwa fangjun.eth
+
+## Dalsza lektura {#further-reading}
+
+- [Stan uaktualnień inteligentnych kontraktów](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) autorstwa Santiago Palladino
+- [Wiele sposobów na uaktualnienie inteligentnego kontraktu Solidity](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) – blog Crypto Market Pool
+- [Dowiedz się: uaktualnianie inteligentnych kontraktów](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) – dokumentacja OpenZeppelin
+- [Wzorce proxy dla możliwości uaktualniania kontraktów Solidity: transparentne vs. UUPS proxy](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) autorstwa Naveena Sahu
+- [Jak działają uaktualnienia diamentowe](https://dev.to/mudgen/how-diamond-upgrades-work-417j) autorstwa Nicka Mudge'a
diff --git a/public/content/translations/pl/developers/docs/smart-contracts/verifying/index.md b/public/content/translations/pl/developers/docs/smart-contracts/verifying/index.md
new file mode 100644
index 00000000000..62201445ab4
--- /dev/null
+++ b/public/content/translations/pl/developers/docs/smart-contracts/verifying/index.md
@@ -0,0 +1,113 @@
+---
+title: "Weryfikowanie inteligentnych kontraktów"
+description: "Przegląd weryfikacji kodu źródłowego dla inteligentnych kontraktów Ethereum"
+lang: pl
+---
+
+[Inteligentne kontrakty](/developers/docs/smart-contracts/) są zaprojektowane jako „niewymagające zaufania”, co oznacza, że użytkownicy nie powinni musieć ufać stronom trzecim (np. deweloperom i firmom) przed interakcją z kontraktem. Jako warunek konieczny dla braku zaufania, użytkownicy i inni deweloperzy muszą mieć możliwość weryfikacji kodu źródłowego inteligentnego kontraktu. Weryfikacja kodu źródłowego zapewnia użytkowników i deweloperów, że opublikowany kod kontraktu jest tym samym kodem, który działa pod adresem kontraktu w łańcuchu bloków Ethereum.
+
+Ważne jest, aby odróżnić „weryfikację kodu źródłowego” od „[formalnej weryfikacji](/developers/docs/smart-contracts/formal-verification/)”. Weryfikacja kodu źródłowego, która zostanie szczegółowo wyjaśniona poniżej, odnosi się do sprawdzenia, czy dany kod źródłowy inteligentnego kontraktu w języku wysokiego poziomu (np. Solidity) kompiluje się do tego samego kodu bajtowego, który ma być wykonany pod adresem kontraktu. Jednakże formalna weryfikacja opisuje weryfikację poprawności inteligentnego kontraktu, co oznacza, że kontrakt zachowuje się zgodnie z oczekiwaniami. Chociaż jest to zależne od kontekstu, weryfikacja kontraktu zwykle odnosi się do weryfikacji kodu źródłowego.
+
+## Czym jest weryfikacja kodu źródłowego? {#what-is-source-code-verification}
+
+Przed wdrożeniem inteligentnego kontraktu w [Wirtualnej Maszynie Ethereum (EVM)](/developers/docs/evm/) deweloperzy [kompilują](/developers/docs/smart-contracts/compiling/) kod źródłowy kontraktu — instrukcje [napisane w Solidity](/developers/docs/smart-contracts/languages/) lub innym języku programowania wysokiego poziomu — do kodu bajtowego. Ponieważ EVM nie może interpretować instrukcji wysokiego poziomu, kompilacja kodu źródłowego do kodu bajtowego (tj. instrukcji maszynowych niskiego poziomu) jest niezbędna do wykonania logiki kontraktu w EVM.
+
+Weryfikacja kodu źródłowego polega na porównaniu kodu źródłowego inteligentnego kontraktu ze skompilowanym kodem bajtowym użytym podczas tworzenia kontraktu w celu wykrycia wszelkich różnic. Weryfikacja inteligentnych kontraktów jest ważna, ponieważ reklamowany kod kontraktu może różnić się od tego, co jest uruchamiane w łańcuchu bloków.
+
+Weryfikacja inteligentnego kontraktu umożliwia zbadanie, co robi kontrakt poprzez język wyższego poziomu, w którym jest napisany, bez konieczności czytania kodu maszynowego. Funkcje, wartości i zazwyczaj nazwy zmiennych i komentarze pozostają takie same jak w oryginalnym kodzie źródłowym, który jest kompilowany i wdrażany. To znacznie ułatwia czytanie kodu. Weryfikacja źródła umożliwia również dokumentację kodu, dzięki czemu użytkownicy końcowi wiedzą, do czego przeznaczony jest inteligentny kontrakt.
+
+### Czym jest pełna weryfikacja? {#full-verification}
+
+Istnieją pewne części kodu źródłowego, które nie wpływają na skompilowany kod bajtowy, takie jak komentarze lub nazwy zmiennych. Oznacza to, że dwa kody źródłowe z różnymi nazwami zmiennych i różnymi komentarzami mogłyby zweryfikować ten sam kontrakt. W związku z tym złośliwy aktor może dodać zwodnicze komentarze lub nadać mylące nazwy zmiennych w kodzie źródłowym i uzyskać weryfikację kontraktu z kodem źródłowym innym niż oryginalny kod źródłowy.
+
+Można tego uniknąć, dołączając dodatkowe dane do kodu bajtowego, aby służyły jako _gwarancja kryptograficzna_ dokładności kodu źródłowego oraz jako _odcisk palca_ informacji o kompilacji. Niezbędne informacje znajdują się w [metadanych kontraktu Solidity](https://docs.soliditylang.org/en/v0.8.15/metadata.html), a hasz tego pliku jest dołączany do kodu bajtowego kontraktu. Możesz zobaczyć, jak to działa na [placu zabaw metadanych](https://playground.sourcify.dev)
+
+Plik metadanych zawiera informacje o kompilacji kontraktu, w tym pliki źródłowe i ich hasze. Oznacza to, że jeśli zmienią się jakiekolwiek ustawienia kompilacji lub nawet bajt w jednym z plików źródłowych, plik metadanych ulegnie zmianie. W konsekwencji hasz pliku metadanych, który jest dołączany do kodu bajtowego, również się zmienia. Oznacza to, że jeśli kod bajtowy kontraktu + dołączony hasz metadanych pasują do danego kodu źródłowego i ustawień kompilacji, możemy być pewni, że jest to dokładnie ten sam kod źródłowy, który został użyty w oryginalnej kompilacji, a żaden bajt nie jest inny.
+
+Ten typ weryfikacji, który wykorzystuje hasz metadanych, jest określany jako **„[pełna weryfikacja](https://docs.sourcify.dev/docs/full-vs-partial-match/)”** (także „doskonała weryfikacja”). Jeśli hasze metadanych nie pasują lub nie są uwzględniane w weryfikacji, byłaby to „częściowa zgodność”, która jest obecnie bardziej powszechnym sposobem weryfikacji kontraktów. Możliwe jest [wstawienie złośliwego kodu](https://samczsun.com/hiding-in-plain-sight/), który nie zostałby odzwierciedlony w zweryfikowanym kodzie źródłowym bez pełnej weryfikacji. Większość deweloperów nie jest świadoma pełnej weryfikacji i nie przechowuje pliku metadanych swojej kompilacji, stąd częściowa weryfikacja jest jak dotąd de facto metodą weryfikacji kontraktów.
+
+## Dlaczego weryfikacja kodu źródłowego jest ważna? {#importance-of-source-code-verification}
+
+### Brak zaufania {#trustlessness}
+
+Brak zaufania jest prawdopodobnie największą przesłanką dla inteligentnych kontraktów i [aplikacji zdecentralizowanych (dapki)](/developers/docs/dapps/). Inteligentne kontrakty są „niezmienne” i nie można ich zmieniać; kontrakt będzie wykonywał tylko logikę biznesową zdefiniowaną w kodzie w momencie wdrożenia. Oznacza to, że deweloperzy i przedsiębiorstwa nie mogą manipulować kodem kontraktu po wdrożeniu go w Ethereum.
+
+Aby inteligentny kontrakt był niewymagający zaufania, kod kontraktu powinien być dostępny do niezależnej weryfikacji. Chociaż skompilowany kod bajtowy dla każdego inteligentnego kontraktu jest publicznie dostępny w łańcuchu bloków, język niskiego poziomu jest trudny do zrozumienia — zarówno dla deweloperów, jak i użytkowników.
+
+Projekty zmniejszają założenia dotyczące zaufania, publikując kod źródłowy swoich kontraktów. Ale to prowadzi do innego problemu: trudno jest zweryfikować, czy opublikowany kod źródłowy pasuje do kodu bajtowego kontraktu. W tym scenariuszu wartość braku zaufania jest tracona, ponieważ użytkownicy muszą ufać deweloperom, że nie zmienią logiki biznesowej kontraktu (tj. zmieniając kod bajtowy) przed wdrożeniem go w łańcuchu bloków.
+
+Narzędzia do weryfikacji kodu źródłowego zapewniają gwarancje, że pliki kodu źródłowego inteligentnego kontraktu pasują do kodu asemblera. Rezultatem jest ekosystem niewymagający zaufania, w którym użytkownicy nie ufają ślepo stronom trzecim, a zamiast tego weryfikują kod przed zdeponowaniem środków w kontrakcie.
+
+### Bezpieczeństwo użytkownika {#user-safety}
+
+W przypadku inteligentnych kontraktów w grę wchodzą zwykle duże pieniądze. Wymaga to wyższych gwarancji bezpieczeństwa i weryfikacji logiki inteligentnego kontraktu przed jego użyciem. Problem w tym, że pozbawieni skrupułów deweloperzy mogą oszukiwać użytkowników, wstawiając złośliwy kod do inteligentnego kontraktu. Bez weryfikacji złośliwe inteligentne kontrakty mogą mieć [backdoory](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts), kontrowersyjne mechanizmy kontroli dostępu, możliwe do wykorzystania luki w zabezpieczeniach i inne rzeczy, które zagrażają bezpieczeństwu użytkowników i które pozostałyby niewykryte.
+
+Publikowanie plików kodu źródłowego inteligentnego kontraktu ułatwia zainteresowanym, takim jak audytorzy, ocenę kontraktu pod kątem potencjalnych wektorów ataku. Gdy wiele stron niezależnie weryfikuje inteligentny kontrakt, użytkownicy mają silniejsze gwarancje jego bezpieczeństwa.
+
+## Jak zweryfikować kod źródłowy dla inteligentnych kontraktów Ethereum {#source-code-verification-for-ethereum-smart-contracts}
+
+[Wdrażanie inteligentnego kontraktu w Ethereum](/developers/docs/smart-contracts/deploying/) wymaga wysłania transakcji z ładunkiem danych (skompilowanym kodem bajtowym) na specjalny adres. Ładunek danych jest generowany przez skompilowanie kodu źródłowego, plus [argumenty konstruktora](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) instancji kontraktu dołączone do ładunku danych w transakcji. Kompilacja jest deterministyczna, co oznacza, że zawsze daje ten sam wynik (tj. kod bajtowy kontraktu), jeśli używane są te same pliki źródłowe i ustawienia kompilacji (np. wersja kompilatora, optymalizator).
+
+
+
+Weryfikacja inteligentnego kontraktu zasadniczo obejmuje następujące kroki:
+
+1. Wprowadź pliki źródłowe i ustawienia kompilacji do kompilatora.
+
+2. Kompilator wyprowadza kod bajtowy kontraktu
+
+3. Pobierz kod bajtowy wdrożonego kontraktu pod danym adresem
+
+4. Porównaj wdrożony kod bajtowy z ponownie skompilowanym kodem bajtowym. Jeśli kody pasują, kontrakt zostaje zweryfikowany z podanym kodem źródłowym i ustawieniami kompilacji.
+
+5. Dodatkowo, jeśli hasze metadanych na końcu kodu bajtowego pasują, będzie to pełna zgodność.
+
+Należy pamiętać, że jest to uproszczony opis weryfikacji i istnieje wiele wyjątków, które nie będą z tym działać, takie jak posiadanie [niezmiennych zmiennych](https://docs.sourcify.dev/docs/immutables/).
+
+## Narzędzia do weryfikacji kodu źródłowego {#source-code-verification-tools}
+
+Tradycyjny proces weryfikacji kontraktów może być złożony. Dlatego mamy narzędzia do weryfikacji kodu źródłowego dla inteligentnych kontraktów wdrożonych na Ethereum. Narzędzia te automatyzują dużą część weryfikacji kodu źródłowego, a także przechowują zweryfikowane kontrakty dla korzyści użytkowników.
+
+### Etherscan {#etherscan}
+
+Chociaż Etherscan jest znany głównie jako [eksplorator łańcucha bloków Ethereum](/developers/docs/data-and-analytics/block-explorers/), oferuje również [usługę weryfikacji kodu źródłowego](https://etherscan.io/verifyContract) dla deweloperów i użytkowników inteligentnych kontraktów.
+
+Etherscan umożliwia ponowne skompilowanie kodu bajtowego kontraktu z oryginalnego ładunku danych (kod źródłowy, adres biblioteki, ustawienia kompilatora, adres kontraktu itp.) Jeśli ponownie skompilowany kod bajtowy jest powiązany z kodem bajtowym (i parametrami konstruktora) kontraktu w łańcuchu, wówczas [kontrakt jest weryfikowany](https://info.etherscan.com/types-of-contract-verification/).
+
+Po weryfikacji kod źródłowy Twojego kontraktu otrzymuje etykietę „Zweryfikowany” i jest publikowany na Etherscan, aby inni mogli go poddać audytowi. Dodawany jest również do sekcji [Zweryfikowane kontrakty](https://etherscan.io/contractsVerified/) — repozytorium inteligentnych kontraktów ze zweryfikowanymi kodami źródłowymi.
+
+Etherscan jest najczęściej używanym narzędziem do weryfikacji kontraktów. Jednak weryfikacja kontraktu w Etherscan ma wadę: nie udaje się porównać **haszu metadanych** kodu bajtowego w łańcuchu i ponownie skompilowanego kodu bajtowego. Dlatego dopasowania w Etherscan są dopasowaniami częściowymi.
+
+[Więcej o weryfikacji kontraktów w Etherscan](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327).
+
+### Blockscout {#blockscout}
+
+[Blockscout](https://blockscout.com/) to eksplorator blockchain o otwartym kodzie źródłowym, który zapewnia również [usługę weryfikacji kontraktów](https://eth.blockscout.com/contract-verification) dla deweloperów i użytkowników inteligentnych kontraktów. Jako alternatywa o otwartym kodzie źródłowym, Blockscout oferuje przejrzystość w sposobie przeprowadzania weryfikacji i umożliwia wkład społeczności w ulepszanie procesu weryfikacji.
+
+Podobnie jak w przypadku innych usług weryfikacyjnych, Blockscout pozwala zweryfikować kod źródłowy kontraktu poprzez ponowne skompilowanie kodu bajtowego i porównanie go z wdrożonym kontraktem. Po weryfikacji kontrakt otrzymuje status weryfikacji, a kod źródłowy staje się publicznie dostępny do audytu i interakcji. Zweryfikowane kontrakty są również wymienione w [repozytorium zweryfikowanych kontraktów](https://eth.blockscout.com/verified-contracts) Blockscout w celu łatwego przeglądania i odkrywania.
+
+### Sourcify {#sourcify}
+
+[Sourcify](https://sourcify.dev/#/verifier) to kolejne narzędzie do weryfikacji kontraktów, które jest open-source i zdecentralizowane. Nie jest to eksplorator bloków i weryfikuje tylko kontrakty w [różnych sieciach opartych na EVM](https://docs.sourcify.dev/docs/chains). Działa jako publiczna infrastruktura dla innych narzędzi do budowania na niej i ma na celu umożliwienie bardziej przyjaznych dla człowieka interakcji z kontraktami za pomocą komentarzy [ABI](/developers/docs/smart-contracts/compiling/#web-applications) i [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) znalezionych w pliku metadanych.
+
+W przeciwieństwie do Etherscan, Sourcify obsługuje pełne dopasowania z haszem metadanych. Zweryfikowane kontrakty są udostępniane w [publicznym repozytorium](https://docs.sourcify.dev/docs/repository/) na HTTP i [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs), które jest zdecentralizowaną pamięcią [adresowaną treścią](https://docs.storacha.network/concepts/content-addressing/). Pozwala to na pobranie pliku metadanych kontraktu przez IPFS, ponieważ dołączony hasz metadanych jest haszem IPFS.
+
+Dodatkowo, można również pobrać pliki kodu źródłowego przez IPFS, ponieważ hasze IPFS tych plików również znajdują się w metadanych. Kontrakt można zweryfikować, dostarczając plik metadanych i pliki źródłowe za pośrednictwem jego API lub [interfejsu użytkownika](https://sourcify.dev/#/verifier) lub za pomocą wtyczek. Narzędzie monitorujące Sourcify nasłuchuje również tworzenia kontraktów w nowych blokach i próbuje zweryfikować kontrakty, jeśli ich metadane i pliki źródłowe są opublikowane w IPFS.
+
+[Więcej na temat weryfikacji kontraktów w Sourcify](https://soliditylang.org/blog/2020/06/25/sourcify-faq/).
+
+### Tenderly {#tenderly}
+
+[Platforma Tenderly](https://tenderly.co/) umożliwia deweloperom Web3 tworzenie, testowanie, monitorowanie i obsługę inteligentnych kontraktów. Łącząc narzędzia do debugowania z obserwowalnością i elementami składowymi infrastruktury, Tenderly pomaga deweloperom przyspieszyć rozwój inteligentnych kontraktów. Aby w pełni włączyć funkcje Tenderly, deweloperzy muszą [przeprowadzić weryfikację kodu źródłowego](https://docs.tenderly.co/monitoring/contract-verification) przy użyciu kilku metod.
+
+Możliwe jest zweryfikowanie kontraktu prywatnie lub publicznie. Jeśli kontrakt zostanie zweryfikowany prywatnie, inteligentny kontrakt będzie widoczny tylko dla Ciebie (i innych członków Twojego projektu). Publiczna weryfikacja kontraktu sprawia, że jest on widoczny dla wszystkich korzystających z platformy Tenderly.
+
+Możesz weryfikować swoje kontrakty za pomocą [pulpitu nawigacyjnego](https://docs.tenderly.co/contract-verification), [wtyczki Tenderly Hardhat](https://docs.tenderly.co/contract-verification/hardhat) lub [interfejsu wiersza poleceń (CLI)](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli).
+
+Podczas weryfikacji kontraktów za pomocą pulpitu nawigacyjnego należy zaimportować plik źródłowy lub plik metadanych wygenerowany przez kompilator Solidity, adres/sieć i ustawienia kompilatora.
+
+Korzystanie z wtyczki Tenderly Hardhat pozwala na większą kontrolę nad procesem weryfikacji przy mniejszym wysiłku, umożliwiając wybór między automatyczną (bez kodu) a ręczną (opartą na kodzie) weryfikacją.
+
+## Dalsza lektura {#further-reading}
+
+- [Weryfikacja kodu źródłowego kontraktu](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/)
diff --git a/public/content/translations/pl/developers/docs/standards/index.md b/public/content/translations/pl/developers/docs/standards/index.md
index ced607fa1fb..1c57d5c09c2 100644
--- a/public/content/translations/pl/developers/docs/standards/index.md
+++ b/public/content/translations/pl/developers/docs/standards/index.md
@@ -1,37 +1,59 @@
---
title: Standardy rozwoju Ethereum
-description:
+description: "Dowiedz się o standardach Ethereum takich jak EIP, standardy tokenów jak ERC-20 oraz ERC-721 i konwencjach programistycznych."
lang: pl
incomplete: true
---
## Przegląd standardów {#standards-overview}
-Społeczność Ethereum przyjęła wiele standardów, które pomagają utrzymać interoperacyjność projektów (takich jak [klienci Ethereum](/developers/docs/nodes-and-clients/) i portfele) we wszystkich implementacjach oraz zapewniają, że inteligentne kontrakty i dapps pozostają komponowalne.
+Społeczność Ethereum przyjęła wiele standardów, które pomagają utrzymać interoperacyjność projektów (takich jak [klienci Ethereum](/developers/docs/nodes-and-clients/) i portfele) we wszystkich implementacjach oraz zapewniają, że inteligentne kontrakty i dapki pozostają komponowalne.
-Zazwyczaj standardy są wprowadzane jako [Propozycje ulepszeń Ethereum](/eips/) (Ethereum Improvement Proposals, EIP), które są omawiane przez członków społeczności za pośrednictwem procesu dotyczącego standardów.
+Zazwyczaj standardy są wprowadzane jako [Propozycje ulepszeń w Ethereum](/eips/) (EIP), które są omawiane przez członków społeczności w ramach [standardowego procesu](https://eips.ethereum.org/EIPS/eip-1).
- [Wprowadzenie do EIP](/eips/)
- [Lista EIP](https://eips.ethereum.org/)
-- [Repozytorium EIP na GitHub](https://github.com/ethereum/EIPs)
+- [Repozytorium GitHub EIP](https://github.com/ethereum/EIPs)
- [Forum dyskusyjne EIP](https://ethereum-magicians.org/c/eips)
-- [Omówienie zarządzania Ethereum](https://blog.bmannconsulting.com/ethereum-governance/) _31 marca 2019 r. – Boris Mann_
-- [Ethereum Protocol Development Governance and Network Upgrade Coordination](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _23 marca 2020 - Hudson Jameson_
-- [Playlist of all Ethereum Core Dev Meetings](https://www.youtube.com/@EthereumProtocol) _(Playlista YouTube)_
+- [Wprowadzenie do zarządzania Ethereum](/governance/)
+- [Przegląd zarządzania Ethereum](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _31 marca 2019 r. - Boris Mann_
+- [Ethereum Protocol Development Governance and Network Upgrade Coordination](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _23 marca 2020 r. - Hudson Jameson_
+- [Playlista wszystkich spotkań programistów rdzenia Ethereum](https://www.youtube.com/@EthereumProtocol) _(Playlista YouTube)_
## Rodzaje standardów {#types-of-standards}
-Niektóre EIP odnoszą się do standardów na poziomie aplikacji (np. standardy formatu inteligentnych kontraktów) wprowadzanych jako [Ethereum Requests for Comment (ERC)](https://eips.ethereum.org/erc). Wiele ERC to niezbędne standardy o krytycznym znaczeniu, powszechnie stosowane w ekosystemie Ethereum.
+Istnieją 3 rodzaje EIP:
-- [Lista ERC](https://eips.ethereum.org/erc)
+- Standardowa ścieżka: opisuje dowolną zmianę, która ma wpływ na większość lub wszystkie implementacje Ethereum
+- [Ścieżka meta](https://eips.ethereum.org/meta): opisuje proces związany z Ethereum lub proponuje zmianę procesu
+- [Ścieżka informacyjna](https://eips.ethereum.org/informational): opisuje problem projektowy Ethereum lub zapewnia ogólne wytyczne bądź informacje dla społeczności Ethereum
+
+Ponadto, standardowa ścieżka jest podzielona na 4 kategorie:
+
+- [Rdzeniowe](https://eips.ethereum.org/core): ulepszenia wymagające forka konsensusu
+- [Sieciowe](https://eips.ethereum.org/networking): ulepszenia dotyczące devp2p i Light Ethereum Subprotocol, a także proponowane ulepszenia specyfikacji protokołów sieciowych Whisper i Swarm.
+- [Interfejs](https://eips.ethereum.org/interface): ulepszenia dotyczące specyfikacji i standardów API/RPC klienta oraz określonych standardów na poziomie języka, takich jak nazwy metod i ABI kontraktów.
+- [ERC](https://eips.ethereum.org/erc): standardy i konwencje na poziomie aplikacji
+
+Bardziej szczegółowe informacje na temat tych różnych typów i kategorii można znaleźć w [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types)
### Standardy tokenów {#token-standards}
-- [ERC-20 – standardowy interfejs tokenów](/developers/docs/standards/tokens/erc-20/)
-- [ERC-721 – standardowy interfejs niewymiennych tokenów](/developers/docs/standards/tokens/erc-721/)
+- [ERC-20](/developers/docs/standards/tokens/erc-20/) – standardowy interfejs dla tokenów zamiennych (wymienialnych), takich jak tokeny do głosowania, tokeny stakingowe lub wirtualne waluty.
+ - [ERC-223](/developers/docs/standards/tokens/erc-223/) – standard tokenów zamiennych, który sprawia, że tokeny zachowują się identycznie jak ether i obsługuje przetwarzanie transferów tokenów po stronie odbiorcy.
+ - [ERC-1363](/developers/docs/standards/tokens/erc-1363/) – rozszerzenie interfejsu dla tokenów ERC-20, które obsługuje wykonywanie wywołań zwrotnych (callback) w kontraktach odbiorców w ramach jednej transakcji.
+- [ERC-721](/developers/docs/standards/tokens/erc-721/) – standardowy interfejs dla tokenów niezamiennych, takich jak akt własności dzieła sztuki lub piosenki.
+ - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) – standaryzowane zdarzenie emitowane podczas tworzenia/przenoszenia jednego lub wielu tokenów niezamiennych przy użyciu kolejnych identyfikatorów tokenów.
+ - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) – rozszerzenie interfejsu dla roli konsumenta EIP-721.
+ - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) – dodaje ograniczoną czasowo rolę z ograniczonymi uprawnieniami do tokenów ERC-721.
+- [ERC-777](/developers/docs/standards/tokens/erc-777/) – **(NIEZALECANY)** standard tokenu stanowiący ulepszenie ERC-20.
+- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) – standard tokenów, który może zawierać zarówno zamienne, jak i niezamienne aktywa.
+- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) – standard tokenizowanych skarbców zaprojektowany w celu optymalizacji i ujednolicenia parametrów technicznych skarbców przynoszących zyski.
Dowiedz się więcej o [standardach tokenów](/developers/docs/standards/tokens/).
## Dalsza lektura {#further-reading}
-_Znasz jakieś zasoby społeczności, które Ci pomogły? Wyedytuj tę stronę i dodaj je!_
+- [Propozycje ulepszeń w Ethereum (EIP)](/eips/)
+
+_Znasz jakieś zasoby społeczności, które Ci pomogły? Edytuj tę stronę i dodaj je!_
diff --git a/public/content/translations/pl/developers/docs/standards/tokens/erc-1155/index.md b/public/content/translations/pl/developers/docs/standards/tokens/erc-1155/index.md
new file mode 100644
index 00000000000..524a8bf30d0
--- /dev/null
+++ b/public/content/translations/pl/developers/docs/standards/tokens/erc-1155/index.md
@@ -0,0 +1,146 @@
+---
+title: "Standard multi-tokenów ERC-1155"
+description: "Dowiedz się więcej o ERC-1155, standardzie wielu tokenów, który łączy tokeny zamienne i niezamienne w jednym kontrakcie."
+lang: pl
+---
+
+## Wprowadzenie {#introduction}
+
+Standardowy interfejs dla kontraktów, które zarządzają kilkoma rodzajami tokenów. Pojedynczy wdrożony kontrakt może zawierać dowolną kombinację tokenów zamiennych, tokenów niezamiennych lub innych konfiguracji (np. tokenów półzamiennych).
+
+**Co oznacza standard multi-tokenów?**
+
+Zamysł jest prosty i ma na celu stworzenie interfejsu inteligentnego kontraktu, który może reprezentować i kontrolować dowolną liczbę wymienialnych i niewymienialnych rodzajów tokenów. W ten sposób token ERC-1155 może wykonywać te same funkcje co tokeny [ERC-20](/developers/docs/standards/tokens/erc-20/) i [ERC-721](/developers/docs/standards/tokens/erc-721/), a nawet oba jednocześnie. Poprawia on funkcjonalność obu standardów, zarówno ERC-20, jak i ERC-721, czyniąc go bardziej wydajnym i poprawiając oczywiste błędy w implementacji.
+
+Token ERC-1155 jest w pełni opisany w [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155).
+
+## Wymagania wstępne {#prerequisites}
+
+Aby lepiej zrozumieć tę stronę, zalecamy najpierw przeczytać o [standardach tokenów](/developers/docs/standards/tokens/), [ERC-20](/developers/docs/standards/tokens/erc-20/) i [ERC-721](/developers/docs/standards/tokens/erc-721/).
+
+## Funkcje i możliwości ERC-1155: {#body}
+
+- [Transfer zbiorczy](#batch_transfers): transferuj wiele aktywów w jednym wywołaniu.
+- [Saldo zbiorcze](#batch_balance): pobieraj salda wielu aktywów w jednym wywołaniu.
+- [Zatwierdzenie zbiorcze](#batch_approval): zatwierdzaj wszystkie tokeny dla adresu.
+- [Hooki](#receive_hook): hook do odbierania tokenów.
+- [Obsługa NFT](#nft_support): jeśli podaż wynosi tylko 1, traktuj go jako NFT.
+- [Zasady bezpiecznego transferu](#safe_transfer_rule): zestaw zasad bezpiecznego transferu.
+
+### Transfery zbiorcze {#batch-transfers}
+
+Zbiorczy transfer działa bardzo podobnie do zwykłych transferów ERC-20. Przyjrzyjmy się zwykłej funkcji ERC-20 `transferFrom`:
+
+```solidity
+// ERC-20
+function transferFrom(address from, address to, uint256 value) external returns (bool);
+
+// ERC-1155
+function safeBatchTransferFrom(
+ address _from,
+ address _to,
+ uint256[] calldata _ids,
+ uint256[] calldata _values,
+ bytes calldata _data
+) external;
+```
+
+Jedyną różnicą w ERC-1155 jest to, że podajemy wartości jako tablicę, a także podajemy tablicę identyfikatorów. Na przykład, dla `ids=[3, 6, 13]` i `values=[100, 200, 5]` wynikowe transfery będą następujące:
+
+1. Transfer 100 tokenów o id 3 z `_from` do `_to`.
+2. Transfer 200 tokenów o id 6 z `_from` do `_to`.
+3. Transfer 5 tokenów o id 13 z `_from` do `_to`.
+
+W ERC-1155 mamy tylko `transferFrom`, nie ma `transfer`. Aby użyć jej jak zwykłego `transfer`, wystarczy ustawić adres nadawcy na adres wywołujący funkcję.
+
+### Saldo zbiorcze {#batch-balance}
+
+Odpowiednie wywołanie ERC-20 `balanceOf` ma również swój odpowiednik z obsługą trybu zbiorczego. Dla przypomnienia tak wygląda wersja ERC-20:
+
+```solidity
+// ERC-20
+function balanceOf(address owner) external view returns (uint256);
+
+// ERC-1155
+function balanceOfBatch(
+ address[] calldata _owners,
+ uint256[] calldata _ids
+) external view returns (uint256[] memory);
+```
+
+W jeszcze prostszy sposób możemy uzyskać wiele sald za pomocą jednego wywołania. Podajemy po prostu tablicę właścicieli, a następnie tablicę identyfikatorów tokenów.
+
+Na przykład dla `_ids=[3, 6, 13]` i `_owners=[0xbeef..., 0x1337..., 0x1111...]` zwracana wartość będzie następująca:
+
+```solidity
+[
+ balanceOf(0xbeef...),
+ balanceOf(0x1337...),
+ balanceOf(0x1111...)
+]
+```
+
+### Zatwierdzenie zbiorcze {#batch-approval}
+
+```solidity
+// ERC-1155
+function setApprovalForAll(
+ address _operator,
+ bool _approved
+) external;
+
+function isApprovedForAll(
+ address _owner,
+ address _operator
+) external view returns (bool);
+```
+
+Zatwierdzenia różnią się trochę od tych z ERC-20. Zamiast zatwierdzać określone kwoty, ustawiasz operatora jako zatwierdzonego lub niezatwierdzonego za pomocą `setApprovalForAll`.
+
+Bieżący status można odczytać za pomocą funkcji `isApprovedForAll`. Jak widzisz, jest to operacja wszystko albo nic. Nie można zdefiniować, ile tokenów zatwierdzić, ani nawet klasy tokena.
+
+Zostało to tak celowo zaprojektowane z myślą o prostocie. Możesz zatwierdzać wszystko tylko dla jednego adresu.
+
+### Hook odbioru {#receive-hook}
+
+```solidity
+function onERC1155BatchReceived(
+ address _operator,
+ address _from,
+ uint256[] calldata _ids,
+ uint256[] calldata _values,
+ bytes calldata _data
+) external returns(bytes4);
+```
+
+Biorąc pod uwagę wsparcie dla [EIP-165](https://eips.ethereum.org/EIPS/eip-165), ERC-1155 obsługuje hooki odbioru tylko dla inteligentnych kontraktów. Funkcja hooka musi zwracać magiczną predefiniowaną wartość bytes4, która jest podana jako:
+
+```solidity
+bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))
+```
+
+Kiedy kontrakt odbierający zwraca tę wartość, zakłada się, że kontrakt akceptuje transfer i wie jak obsługiwać tokeny ERC-1155. Świetnie, koniec z tokenami zablokowanymi w kontrakcie!
+
+### Obsługa NFT {#nft-support}
+
+Gdy podaż wynosi tylko 1, to token jest tak naprawdę tokenem niewymienialnym (NFT). I jak to w standardzie ERC-7219, możesz określić URL metadanych. Adres URL może być odczytywany i modyfikowany przez klientów, zobacz [tutaj](https://eips.ethereum.org/EIPS/eip-1155#metadata).
+
+### Zasada bezpiecznego transferu {#safe-transfer-rule}
+
+W poprzednich wyjaśnieniach poruszyliśmy już kilka zasad bezpiecznego transferu. Przyjrzyjmy się jednak jednej z najważniejszych zasad:
+
+1. Wywołujący musi być zatwierdzony do wydania tokenów dla adresu `_from` lub musi być równy `_from`.
+2. Wywołanie transferu musi zostać cofnięte, jeśli:
+ 1. adres `_to` ma wartość 0.
+ 2. długość `_ids` nie jest taka sama jak długość `_values`.
+ 3. którekolwiek z sald posiadacza dla tokenów w `_ids` jest niższe niż odpowiednia kwota w `_values` wysłana do odbiorcy.
+ 4. wystąpi jakikolwiek inny błąd.
+
+_Uwaga_: wszystkie funkcje zbiorcze, w tym hooki, mają także swoje wersje niezbiorcze. Zostało to zrobione z myślą o wydajności gazowej, biorąc pod uwagę, że przesyłanie tylko jednego aktywa nadal będzie najprawdopodobniej najczęściej używanym sposobem. Pominęliśmy je dla uproszczenia wyjaśnień, w tym zasady bezpiecznego transferu. Nazwy są identyczne, wystarczy usunąć słowo „Batch”.
+
+## Dalsza lektura {#further-reading}
+
+- [EIP-1155: Standard wielu tokenów](https://eips.ethereum.org/EIPS/eip-1155)
+- [ERC-1155: Dokumentacja OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/erc1155)
+- [ERC-1155: Repozytorium GitHub](https://github.com/enjin/erc-1155)
+- [Alchemy NFT API](https://www.alchemy.com/docs/reference/nft-api-quickstart)
diff --git a/public/content/translations/pl/developers/docs/standards/tokens/erc-1363/index.md b/public/content/translations/pl/developers/docs/standards/tokens/erc-1363/index.md
new file mode 100644
index 00000000000..2ce7a470ddb
--- /dev/null
+++ b/public/content/translations/pl/developers/docs/standards/tokens/erc-1363/index.md
@@ -0,0 +1,213 @@
+---
+title: "Standard tokenów płatnych ERC-1363"
+description: "ERC-1363 to rozszerzony interfejs dla tokenów ERC-20, który umożliwia wykonanie niestandardowej logiki w kontrakcie odbiorcy po transferach lub w kontrakcie wydającego po zatwierdzeniach, a wszystko to w ramach jednej transakcji."
+lang: pl
+---
+
+## Wprowadzenie {#introduction}
+
+### Czym jest ERC-1363? {#what-is-erc1363}
+
+ERC-1363 to rozszerzony interfejs dla tokenów ERC-20, który umożliwia wykonanie niestandardowej logiki w kontrakcie odbiorcy po transferach lub w kontrakcie wydającego po zatwierdzeniach, a wszystko to w ramach jednej transakcji.
+
+### Różnice w stosunku do ERC-20 {#erc20-differences}
+
+Standardowe operacje ERC-20, takie jak `transfer`, `transferFrom` i `approve`, nie pozwalają na wykonanie kodu w kontrakcie odbiorcy lub wydającego bez oddzielnej transakcji.
+Wprowadza to złożoność w tworzeniu interfejsu użytkownika i utrudnia adaptację, ponieważ użytkownicy muszą czekać na wykonanie pierwszej transakcji, a następnie przesłać drugą.
+Muszą również dwukrotnie zapłacić za GAZ.
+
+ERC-1363 sprawia, że tokeny zamienne mogą łatwiej wykonywać działania i działać bez użycia jakiegokolwiek nasłuchiwacza off-chain.
+Pozwala to na wykonanie wywołania zwrotnego w kontrakcie odbiorcy lub wydającego po transferze lub zatwierdzeniu, w ramach jednej transakcji.
+
+## Wymagania wstępne {#prerequisites}
+
+Aby lepiej zrozumieć tę stronę, zalecamy najpierw przeczytać o:
+
+- [Standardy tokenów](/developers/docs/standards/tokens/)
+- [ERC-20](/developers/docs/standards/tokens/erc-20/)
+
+## Treść {#body}
+
+ERC-1363 wprowadza standardowe API dla tokenów ERC-20 do interakcji z inteligentnymi kontraktami po operacjach `transfer`, `transferFrom` lub `approve`.
+
+Standard ten zapewnia podstawową funkcjonalność transferu tokenów, a także umożliwia zatwierdzanie tokenów, aby mogły być wydawane przez inną stronę trzecią on-chain, a następnie wykonanie wywołania zwrotnego w kontrakcie odbiorcy lub wydającego.
+
+Istnieje wiele proponowanych zastosowań inteligentnych kontraktów, które mogą akceptować wywołania zwrotne ERC-20.
+
+Przykłady:
+
+- **Crowdsale**: wysłane tokeny powodują natychmiastową alokację nagród.
+- **Usługi**: płatność aktywuje dostęp do usługi w jednym kroku.
+- **Faktury**: tokeny automatycznie regulują faktury.
+- **Subskrypcje**: zatwierdzenie rocznej stawki aktywuje subskrypcję wraz z płatnością za pierwszy miesiąc.
+
+Z tych powodów pierwotnie nazwano go **"Tokenem płatnym"**.
+
+Zachowanie wywołania zwrotnego dodatkowo rozszerza jego użyteczność, umożliwiając płynne interakcje, takie jak:
+
+- **Staking**: przetransferowane tokeny powodują automatyczną blokadę w kontrakcie stakingowym.
+- **Głosowanie**: otrzymane tokeny rejestrują głosy w systemie zarządzania.
+- **Wymiana**: zatwierdzenia tokenów aktywują logikę wymiany w jednym kroku.
+
+Tokeny ERC-1363 mogą być używane do określonych zastosowań we wszystkich przypadkach, które wymagają wykonania wywołania zwrotnego po otrzymaniu transferu lub zatwierdzenia.
+ERC-1363 jest również przydatny do unikania utraty lub blokowania tokenów w inteligentnych kontraktach poprzez weryfikację zdolności odbiorcy do obsługi tokenów.
+
+W przeciwieństwie do innych propozycji rozszerzeń ERC-20, ERC-1363 nie nadpisuje metod `transfer` i `transferFrom` z ERC-20 i definiuje ID interfejsów do zaimplementowania, zachowując wsteczną kompatybilność z ERC-20.
+
+Na podstawie [EIP-1363](https://eips.ethereum.org/EIPS/eip-1363):
+
+### Metody {#methods}
+
+Inteligentne kontrakty implementujące standard ERC-1363 **MUSZĄ** implementować wszystkie funkcje z interfejsu `ERC1363`, a także interfejsy `ERC20` i `ERC165`.
+
+```solidity
+pragma solidity ^0.8.0;
+
+/**
+ * @title ERC1363
+ * @dev Interfejs rozszerzający dla tokenów ERC-20, który umożliwia wykonanie kodu w kontrakcie odbiorcy
+ * po `transfer` lub `transferFrom` lub kodu w kontrakcie wydającego po `approve`, w ramach jednej transakcji.
+ */
+interface ERC1363 is ERC20, ERC165 {
+ /*
+ * UWAGA: identyfikator ERC-165 dla tego interfejsu to 0xb0202a11.
+ * 0xb0202a11 ===
+ * bytes4(keccak256('transferAndCall(address,uint256)')) ^
+ * bytes4(keccak256('transferAndCall(address,uint256,bytes)')) ^
+ * bytes4(keccak256('transferFromAndCall(address,address,uint256)')) ^
+ * bytes4(keccak256('transferFromAndCall(address,address,uint256,bytes)')) ^
+ * bytes4(keccak256('approveAndCall(address,uint256)')) ^
+ * bytes4(keccak256('approveAndCall(address,uint256,bytes)'))
+ */
+
+ /**
+ * @dev Przenosi `value` tokenów z konta wywołującego do `to`,
+ * a następnie wywołuje `ERC1363Receiver::onTransferReceived` na `to`.
+ * @param to Adres, na który tokeny są przesyłane.
+ * @param value Ilość tokenów do przesłania.
+ * @return Wartość logiczna wskazująca, że operacja się powiodła, chyba że zostanie zgłoszony błąd.
+ */
+ function transferAndCall(address to, uint256 value) external returns (bool);
+
+ /**
+ * @dev Przenosi `value` tokenów z konta wywołującego do `to`,
+ * a następnie wywołuje `ERC1363Receiver::onTransferReceived` na `to`.
+ * @param to Adres, na który tokeny są przesyłane.
+ * @param value Ilość tokenów do przesłania.
+ * @param data Dodatkowe dane bez określonego formatu, wysyłane w wywołaniu do `to`.
+ * @return Wartość logiczna wskazująca, że operacja się powiodła, chyba że zostanie zgłoszony błąd.
+ */
+ function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool);
+
+ /**
+ * @dev Przenosi `value` tokenów z `from` do `to` za pomocą mechanizmu allowance
+ * a następnie wywołuje `ERC1363Receiver::onTransferReceived` na `to`.
+ * @param from Adres, z którego wysyłane są tokeny.
+ * @param to Adres, na który tokeny są przesyłane.
+ * @param value Ilość tokenów do przesłania.
+ * @return Wartość logiczna wskazująca, że operacja się powiodła, chyba że zostanie zgłoszony błąd.
+ */
+ function transferFromAndCall(address from, address to, uint256 value) external returns (bool);
+
+ /**
+ * @dev Przenosi `value` tokenów z `from` do `to` za pomocą mechanizmu allowance
+ * a następnie wywołuje `ERC1363Receiver::onTransferReceived` na `to`.
+ * @param from Adres, z którego wysyłane są tokeny.
+ * @param to Adres, na który tokeny są przesyłane.
+ * @param value Ilość tokenów do przesłania.
+ * @param data Dodatkowe dane bez określonego formatu, wysyłane w wywołaniu do `to`.
+ * @return Wartość logiczna wskazująca, że operacja się powiodła, chyba że zostanie zgłoszony błąd.
+ */
+ function transferFromAndCall(address from, address to, uint256 value, bytes calldata data) external returns (bool);
+
+ /**
+ * @dev Ustawia `value` tokenów jako allowance dla `spender` nad tokenami wywołującego
+ * i następnie wywołuje `ERC1363Spender::onApprovalReceived` na `spender`.
+ * @param spender Adres, który wyda środki.
+ * @param value Ilość tokenów do wydania.
+ * @return Wartość logiczna wskazująca, że operacja się powiodła, chyba że zostanie zgłoszony błąd.
+ */
+ function approveAndCall(address spender, uint256 value) external returns (bool);
+
+ /**
+ * @dev Ustawia `value` tokenów jako allowance dla `spender` nad tokenami wywołującego
+ * i następnie wywołuje `ERC1363Spender::onApprovalReceived` na `spender`.
+ * @param spender Adres, który wyda środki.
+ * @param value Ilość tokenów do wydania.
+ * @param data Dodatkowe dane bez określonego formatu, wysyłane w wywołaniu do `spender`.
+ * @return Wartość logiczna wskazująca, że operacja się powiodła, chyba że zostanie zgłoszony błąd.
+ */
+ function approveAndCall(address spender, uint256 value, bytes calldata data) external returns (bool);
+}
+
+interface ERC20 {
+ event Transfer(address indexed from, address indexed to, uint256 value);
+ event Approval(address indexed owner, address indexed spender, uint256 value);
+ function transfer(address to, uint256 value) external returns (bool);
+ function transferFrom(address from, address to, uint256 value) external returns (bool);
+ function approve(address spender, uint256 value) external returns (bool);
+ function totalSupply() external view returns (uint256);
+ function balanceOf(address account) external view returns (uint256);
+ function allowance(address owner, address spender) external view returns (uint256);
+}
+
+interface ERC165 {
+ function supportsInterface(bytes4 interfaceId) external view returns (bool);
+}
+```
+
+Inteligentny kontrakt, który chce akceptować tokeny ERC-1363 za pośrednictwem `transferAndCall` lub `transferFromAndCall`, **MUSI** zaimplementować interfejs `ERC1363Receiver`:
+
+```solidity
+/**
+ * @title ERC1363Receiver
+ * @dev Interfejs dla każdego kontraktu, który chce wspierać `transferAndCall` lub `transferFromAndCall` z kontraktów tokenów ERC-1363.
+ */
+interface ERC1363Receiver {
+ /**
+ * @dev Ilekroć tokeny ERC-1363 są przesyłane do tego kontraktu za pośrednictwem `ERC1363::transferAndCall` lub `ERC1363::transferFromAndCall`
+ * przez `operator` z `from`, ta funkcja jest wywoływana.
+ *
+ * UWAGA: Aby zaakceptować transfer, funkcja musi zwrócić
+ * `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))`
+ * (tj. 0x88a7ca5c lub własny selektor funkcji).
+ *
+ * @param operator Adres, który wywołał funkcję `transferAndCall` lub `transferFromAndCall`.
+ * @param from Adres, z którego przesyłane są tokeny.
+ * @param value Ilość przesłanych tokenów.
+ * @param data Dodatkowe dane bez określonego formatu.
+ * @return `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` jeśli transfer jest dozwolony, chyba że zostanie zgłoszony błąd.
+ */
+ function onTransferReceived(address operator, address from, uint256 value, bytes calldata data) external returns (bytes4);
+}
+```
+
+Inteligentny kontrakt, który chce akceptować tokeny ERC-1363 za pośrednictwem `approveAndCall`, **MUSI** zaimplementować interfejs `ERC1363Spender`:
+
+```solidity
+/**
+ * @title ERC1363Spender
+ * @dev Interfejs dla każdego kontraktu, który chce wspierać `approveAndCall` z kontraktów tokenów ERC-1363.
+ */
+interface ERC1363Spender {
+ /**
+ * @dev Ilekroć `owner` tokenów ERC-1363 zatwierdzi ten kontrakt za pośrednictwem `ERC1363::approveAndCall`
+ * do wydawania swoich tokenów, ta funkcja jest wywoływana.
+ *
+ * UWAGA: Aby zaakceptować zatwierdzenie, funkcja musi zwrócić
+ * `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))`
+ * (tj. 0x7b04a2d0 lub własny selektor funkcji).
+ *
+ * @param owner Adres, który wywołał funkcję `approveAndCall` i wcześniej posiadał tokeny.
+ * @param value Ilość tokenów do wydania.
+ * @param data Dodatkowe dane bez określonego formatu.
+ * @return `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` jeśli zatwierdzenie jest dozwolone, chyba że zostanie zgłoszony błąd.
+ */
+ function onApprovalReceived(address owner, uint256 value, bytes calldata data) external returns (bytes4);
+}
+```
+
+## Dalsza lektura {#further-reading}
+
+- [ERC-1363: Standard tokenów płatnych](https://eips.ethereum.org/EIPS/eip-1363)
+- [ERC-1363: Repozytorium GitHub](https://github.com/vittominacori/erc1363-payable-token)
diff --git a/public/content/translations/pl/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/pl/developers/docs/standards/tokens/erc-20/index.md
index c08028e58bc..4513fe42a94 100644
--- a/public/content/translations/pl/developers/docs/standards/tokens/erc-20/index.md
+++ b/public/content/translations/pl/developers/docs/standards/tokens/erc-20/index.md
@@ -1,6 +1,6 @@
---
-title: Standard tokena ERC-20
-description:
+title: "Standard tokenów ERC-20"
+description: "Dowiedz się więcej o ERC-20, standardzie zamiennych tokenów na Ethereum, który umożliwia interoperacyjne zastosowania dla tokenów."
lang: pl
---
@@ -12,19 +12,21 @@ Tokeny mogą reprezentować praktycznie wszystko w Ethereum:
- punkty reputacji na platformie internetowej
- umiejętności postaci w grze
-- bilety na loterię
- aktywa finansowe, takie jak udział w spółce
- walutę fiducjarną, taką jak USD
- uncję złota
-- i więcej...
+- i nie tylko...
-Tak potężna funkcja Ethereum musi być obsługiwana przez solidny standard, prawda? To jest dokładnie to, gdzie ERC-20 odgrywa rolę! Te standardy umożliwiają programistom tworzenie aplikacji tokenów, które mogą współpracować z innymi produktami i usługami.
+Tak potężna funkcja Ethereum musi być obsługiwana przez solidny standard, prawda? To jest dokładnie to,
+gdzie ERC-20 odgrywa rolę! Ten standard umożliwia deweloperom tworzenie aplikacji tokenowych, które są interoperacyjne z innymi produktami i usługami. Standard ERC-20 jest również używany do zapewnienia dodatkowej funkcjonalności [etherowi](/glossary/#ether).
-**Co to jest ERC-20?**
+**Czym jest ERC-20?**
-ERC-20 wprowadza standard dla tokenów wymiennych, innymi słowy mają one właściwość, która sprawia, że każdy token jest dokładnie taki sam (pod względem typu i wartości) jak inny token. Na przykład token ERC-20 działa podobnie jak ETH, oznacza, że 1 token jest i będzie zawsze równy wszystkim pozostałym tokenom.
+ERC-20 wprowadza standard dla tokenów wymiennych, innymi słowy mają one właściwość, która sprawia, że każdy token jest dokładnie
+taki sam (pod względem typu i wartości) jak inny token. Na przykład token ERC-20 działa podobnie jak ETH, oznacza, że 1 token
+jest i będzie zawsze równy wszystkim pozostałym tokenom.
-## Warunki wstępne {#prerequisites}
+## Wymagania wstępne {#prerequisites}
- [Konta](/developers/docs/accounts)
- [Inteligentne kontrakty](/developers/docs/smart-contracts/)
@@ -32,13 +34,20 @@ ERC-20 wprowadza standard dla tokenów wymiennych, innymi słowy mają one wła
## Treść {#body}
-ERC-20 (Ethereum Request for Comments 20) zaproponowany przez Fabiana Vogelstellera w listopadzie 2015 r. jest standardem tokenów, który implementuje API dla tokenów w inteligentnych kontraktach.
+ERC-20 (Ethereum Request for Comments 20) zaproponowany przez Fabiana Vogelstellera w listopadzie 2015 r. jest standardem tokenów, który
+implementuje API dla tokenów w inteligentnych kontraktach.
-Zapewnia funkcje takie jak przesyłanie tokenów z jednego konta na drugie, uzyskanie aktualnego salda tokenów na koncie oraz całkowitą podaż tokenów dostępnych w sieci. Poza tym ma również kilka innych funkcji , takich jak zatwierdzanie, że ilość tokenów z konta może być wydana przez konto osoby trzeciej.
+Przykładowe funkcje zapewniane przez ERC-20 to:
-Jeśli inteligentny kontrakt implementuje następujące metody i zdarzenia, można go nazwać kontraktem tokena ERC-20, a po wdrożeniu będzie odpowiedzialny za śledzenie utworzonych tokenów w Ethereum.
+- transfer tokenów z jednego konta na drugie
+- uzyskanie bieżącego salda tokenów na koncie
+- uzyskanie całkowitej podaży tokena dostępnego w sieci
+- zatwierdzanie, czy kwota tokena z konta może zostać wydana przez konto strony trzeciej
-Od [EIP-20](https://eips.ethereum.org/EIPS/eip-20):
+Jeśli inteligentny kontrakt implementuje następujące metody i zdarzenia, można go nazwać kontraktem tokena ERC-20, a po wdrożeniu
+będzie odpowiedzialny za śledzenie utworzonych tokenów w Ethereum.
+
+Na podstawie [EIP-20](https://eips.ethereum.org/EIPS/eip-20):
### Metody {#methods}
@@ -54,21 +63,22 @@ function approve(address _spender, uint256 _value) public returns (bool success)
function allowance(address _owner, address _spender) public view returns (uint256 remaining)
```
-### Wydarzenia {#events}
+### Zdarzenia {#events}
```solidity
event Transfer(address indexed _from, address indexed _to, uint256 _value)
event Approval(address indexed _owner, address indexed _spender, uint256 _value)
-
```
### Przykłady {#web3py-example}
-Zobaczmy, dlaczego standard jest tak ważny, aby ułatwić nam sprawdza kontraktów z tokenami ERC-20 na Ethereum. Potrzebujemy tylko interfejsu binarnego Umowy (ABI), aby utworzyć interfejs dla każdego tokenu ERC-20. Jak możesz zobaczyć poniżej, użyjemy uproszczonego ABI, aby zmniejszyć złożoność przykładu.
+Zobaczmy, dlaczego standard jest tak ważny, aby ułatwić nam sprawdzanie dowolnego kontraktu tokena ERC-20 na Ethereum.
+Potrzebujemy tylko interfejsu binarnego aplikacji (ABI) kontraktu, aby utworzyć interfejs dla dowolnego tokena ERC-20. Jak możesz
+zobaczyć poniżej, użyjemy uproszczonego ABI, aby zmniejszyć złożoność przykładu.
#### Przykład Web3.py {#web3py-example}
-Najpierw upewnij się, że zainstalowałeś [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) bibliotekę Pythona:
+Najpierw upewnij się, że masz zainstalowaną bibliotekę Pythona [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation):
```
pip install web3
@@ -81,13 +91,12 @@ from web3 import Web3
w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com"))
dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI
-weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Wrapped ether (WETH)
+weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Zapakowany ether (WETH)
acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2
-# This is a simplified Contract Application Binary Interface (ABI) of an ERC-20 Token Contract.
-
-# It will expose only the methods: balanceOf(address), decimals(), symbol() and totalSupply()
+# Jest to uproszczony interfejs binarny aplikacji (ABI) kontraktu tokena ERC-20.
+# Uwidoczni on tylko metody: balanceOf(address), decimals(), symbol() oraz totalSupply()
simplified_abi = [
{
'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}],
@@ -115,7 +124,7 @@ simplified_abi = [
}
]
-dai_contract = w3.eth.contract(address=w3.toChecksumAddress(dai_token_addr), abi=simplified_abi)
+dai_contract = w3.eth.contract(address=w3.to_checksum_address(dai_token_addr), abi=simplified_abi)
symbol = dai_contract.functions.symbol().call()
decimals = dai_contract.functions.decimals().call()
totalSupply = dai_contract.functions.totalSupply().call() / 10**decimals
@@ -123,10 +132,10 @@ addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decima
# DAI
print("===== %s =====" % symbol)
-print("Total Supply:", totalSupply)
-print("Addr Balance:", addr_balance)
+print("Całkowita podaż:", totalSupply)
+print("Saldo adresu:", addr_balance)
-weth_contract = w3.eth.contract(address=w3.toChecksumAddress(weth_token_addr), abi=simplified_abi)
+weth_contract = w3.eth.contract(address=w3.to_checksum_address(weth_token_addr), abi=simplified_abi)
symbol = weth_contract.functions.symbol().call()
decimals = weth_contract.functions.decimals().call()
totalSupply = weth_contract.functions.totalSupply().call() / 10**decimals
@@ -134,19 +143,50 @@ addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decim
# WETH
print("===== %s =====" % symbol)
-print("Total Supply:", totalSupply)
-print("Addr Balance:", addr_balance)
+print("Całkowita podaż:", totalSupply)
+print("Saldo adresu:", addr_balance)
```
+## Znane problemy {#erc20-issues}
+
+### Problem z odbiorem tokenów ERC-20 {#reception-issue}
+
+**Do dnia 20.06.2024 r. z powodu tego problemu utracono tokeny ERC-20 o wartości co najmniej 83 656 418 $. Należy pamiętać, że czysta implementacja ERC-20 jest podatna na ten problem, chyba że zaimplementuje się dodatkowy zestaw ograniczeń do standardu, jak wymieniono poniżej.**
+
+Kiedy tokeny ERC-20 zostają wysłane do inteligentnego kontraktu, który nie jest zaprojektowany do obsługi tokenów ERC-20, to mogą one zostać utracone na zawsze. Dzieje się tak, ponieważ kontrakt odbierający nie ma funkcji rozpoznawania lub reagowanie na nadchodzące tokeny, a w standardzie ERC-20 nie ma mechanizmu powiadamianie kontraktu odbierającego o przychodzących tokenach. Główne formy tego problemu to:
+
+1. Mechanizm transferu tokenów
+
+- Tokeny ERC-20 są przenoszone przy użyciu funkcji transfer lub transferFrom
+ - Kiedy użytkownik wysyła tokeny do inteligentnego kontraktu przy użyciu tych funkcji, to tokeny są przenoszone bez względu na to, czy kontrakt odbierający jest zaprojektowany do ich obsługi
+
+2. Brak powiadomień
+ - Kontrakt odbierający nie otrzymuje żadnego powiadomienia lub wywołania zwrotnego, że tokeny zostały do niego wysłane
+ - Jeśli kontrakt odbierający nie posiada mechanizmu do obsługi tokenów (np. funkcji awaryjnej lub dedykowanej funkcji to zarządzania odbiorem tokenów) to tokeny pozostają utknięte w adresie kontraktu
+3. Brak wbudowanej obsługi
+ - Standard ERC-20 nie zawiera obowiązkowej funkcji do zaimplementowania przez kontrakty odbierające, co prowadzi do sytuacji, w których wiele kontraktów nie jest w stanie prawidłowo zarządzać przychodzącymi tokenami
+
+**Możliwe rozwiązania**
+
+Niemożliwym jest całkowite zapobieżenie temu problemowi z ERC-20, ale są metody, które pozwalają znacząco ograniczyć ryzyko utraty tokenów przez końcowego użytkownika:
+
+- Najczęstszym problemem jest sytuacja, w której użytkownik wysyła tokeny na adres samego kontraktu tokena (np. USDT zdeponowane na adresie kontraktu tokena USDT). Zaleca się ograniczenie funkcji `transfer(..)` tak, aby wycofywała takie próby transferu. Należy rozważyć dodanie sprawdzenia `require(_to != address(this));` w implementacji funkcji `transfer(..)`.
+- Zasadniczo funkcja `transfer(..)` nie jest przeznaczona do deponowania tokenów w kontraktach. `approve(..) Zamiast tego, do deponowania tokenów ERC-20 w kontraktach używany jest wzorzec `& transferFrom(..)`. Można ograniczyć funkcję transfer, aby uniemożliwić deponowanie za jej pomocą tokenów w kontraktach, jednak może to naruszyć kompatybilność z kontraktami, które zakładają, że tokeny można deponować w kontraktach za pomocą funkcji `trasnfer(..)` (np. pule płynności Uniswap).
+- Zawsze zakładaj możliwość, że tokeny ERC-20 mogą trafić do Twojego kontraktu, nawet jeśli kontrakt nie powinien nigdy ich otrzymać. Nie ma możliwości zapobieżenia lub odrzucenia przypadkowych depozytów ze strony odbiorcy. Zaleca się zaimplementowanie funkcji, która umożliwiłaby wycofanie przypadkowo przesłanych tokenów ERC-20.
+- Rozważ użycie alternatywnych standardów tokenów.
+
+W odpowiedzi na ten problem powstały alternatywne standardy, takie jak [ERC-223](/developers/docs/standards/tokens/erc-223) lub [ERC-1363](/developers/docs/standards/tokens/erc-1363).
+
## Dalsza lektura {#further-reading}
-- [EIP-20: standard tokena ERC-20](https://eips.ethereum.org/EIPS/eip-20)
-- [OpenZeppelin – tokeny](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20)
-- [OpenZeppelin – implementacja ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)
-- [ConsenSys – wdrożenie ERC-20](https://github.com/ConsenSys/Tokens/blob/master/contracts/eip20/EIP20.sol)
+- [EIP-20: standard tokenów ERC-20](https://eips.ethereum.org/EIPS/eip-20)
+- [OpenZeppelin – Tokeny](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20)
+- [OpenZeppelin – Implementacja ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)
+- [Alchemy – Przewodnik po tokenach ERC20 w Solidity](https://www.alchemy.com/overviews/erc20-solidity)
-## Powiązane tematy {#related-topics}
+## Inne standardy tokenów zamiennych {#fungible-token-standards}
-- [ERC-721](/developers/docs/standards/tokens/erc-721/)
-- [ERC-777](/developers/docs/standards/tokens/erc-777/)
-- [ERC-1155](/developers/docs/standards/tokens/erc-1155/)
+- [ERC-223](/developers/docs/standards/tokens/erc-223)
+- [ERC-1363](/developers/docs/standards/tokens/erc-1363)
+- [ERC-777](/developers/docs/standards/tokens/erc-777)
+- [ERC-4626 – Stokenizowane skarbce](/developers/docs/standards/tokens/erc-4626)
diff --git a/public/content/translations/pl/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/pl/developers/docs/standards/tokens/erc-223/index.md
new file mode 100644
index 00000000000..f2db0dca177
--- /dev/null
+++ b/public/content/translations/pl/developers/docs/standards/tokens/erc-223/index.md
@@ -0,0 +1,200 @@
+---
+title: "Standard tokenów ERC-223"
+description: "Przegląd standardu tokenów wymienialnych ERC-223, tego, jak działa wraz z porównaniem z ERC-20."
+lang: pl
+---
+
+## Wprowadzenie {#introduction}
+
+### Czym jest ERC-223? {#what-is-erc223}
+
+ERC-223 jest standardem dla tokenów wymienialnych, podobnie jak standard ERC-20. Kluczową różnicą jest to, że ERC-223 określa nie tylko API tokena, ale również logikę odpowiedzialną za transfer tokenów od nadawcy do odbiorcy. Wprowadza model komunikacji, który zezwala na obsługę transferów tokenów po stronie odbiorcy.
+
+### Różnice w stosunku do ERC-20 {#erc20-differences}
+
+ERC-223 rozwiązuje pewne ograniczenia ERC-20 oraz wprowadza nową metodę interakcji między kontraktem tokena, a kontraktem, które może otrzymać tokeny. Istnieje kilka rzeczy, które są możliwe z ERC-223, ale nie z ERC-20:
+
+- Obsługa transferu tokenów po stronie odbiorcy: odbiorcy mogą wykryć, że token ERC-223 zostaje wpłacony.
+- Odrzucenie nieprawidłowo wysłanych tokenów: jeśli użytkownik wyśle tokeny ERC-223 do kontraktu, który nie powinien otrzymać tokenów, to kontrakt może odrzucić transakcję, zapobiegając utracie tokenów.
+- Metadane w transferach: tokeny ERC-223 mogą zawierać metadane zezwalające na dołączenie dowolnych informacji do transakcji tokenowych.
+
+## Wymagania wstępne {#prerequisites}
+
+- [Konta](/developers/docs/accounts)
+- [Inteligentne kontrakty](/developers/docs/smart-contracts/)
+- [Standardy tokenów](/developers/docs/standards/tokens/)
+- [ERC-20](/developers/docs/standards/tokens/erc-20/)
+
+## Treść {#body}
+
+ERC-223 to standard tokenów, który implementuje API dla tokenów w inteligentnych kontraktach. Deklaruje również API dla kontraktów, które miałyby otrzymywać tokeny ERC-223. Kontrakty, które nie wspierają API odbiorcy ERC-223, nie mogą otrzymać tokenów ERC-223, co zapobiega przed błędami użytkownika.
+
+Jeśli inteligentny kontrakt implementuje następujące metody i zdarzenia to może zostać nazwanym kontraktem tokena zgodnym z ERC-223. Po wdrożeniu będzie on odpowiedzialny za monitorowanie stworzonym tokenów na Ethereum.
+
+Kontrakt nie jest zobowiązany, aby mieć tylko te funkcje, a deweloper może dodać każdą inną funkcję od innego standardu tokenów to tego kontraktu. Dla przykładu, funkcje `approve` oraz `transferFrom` nie są częścią standardu ERC-223, ale mogą zostać zaimplementowane, jeśli tylko zajdzie taka potrzeba.
+
+Na podstawie [EIP-223](https://eips.ethereum.org/EIPS/eip-223):
+
+### Metody {#methods}
+
+Token ERC-223 musi zaimplementować następujące metody:
+
+```solidity
+function name() public view returns (string)
+function symbol() public view returns (string)
+function decimals() public view returns (uint8)
+function totalSupply() public view returns (uint256)
+function balanceOf(address _owner) public view returns (uint256 balance)
+function transfer(address _to, uint256 _value) public returns (bool success)
+function transfer(address _to, uint256 _value, bytes calldata _data) public returns (bool success)
+```
+
+A kontrakt, który miałby otrzymać tokeny ERC-223 musi zaimplementować następującą metodę:
+
+```solidity
+function tokenReceived(address _from, uint _value, bytes calldata _data)
+```
+
+Jeśli tokeny ERC-223 zostaną wysłane do kontraktu, który nie zaimplementował funkcji `tokenReceived(..)`, to transfer musi się zakończyć niepowodzeniem, a tokeny nie mogą zostać przeniesione z konta nadawcy.
+
+### Zdarzenia {#events}
+
+```solidity
+event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes calldata _data)
+```
+
+### Przykłady {#examples}
+
+API tokena ERC-223 jest podobne do tego z ERC-20, więc z punktu widzenia rozwoju UI, nie ma różnicy. Jedynym wyjątkiem tutaj jest to, że tokeny ERC-223 mogą nie mieć funkcji `approve` i `transferFrom`, ponieważ te są opcjonalne dla tego standardu.
+
+#### Przykłady w Solidity {#solidity-example}
+
+Poniższy przykład pokazuje, w jaki sposób działa podstawowy kontrakt tokena ERC-223:
+
+```solidity
+pragma solidity ^0.8.19;
+abstract contract IERC223Recipient {
+ function tokenReceived(address _from, uint _value, bytes memory _data) public virtual;
+}
+contract VeryBasicERC223Token {
+ event Transfer(address indexed from, address indexed to, uint value, bytes data);
+ string private _name;
+ string private _symbol;
+ uint8 private _decimals;
+ uint256 private _totalSupply;
+ mapping(address => uint256) private balances;
+ function name() public view returns (string memory) { return _name; }
+ function symbol() public view returns (string memory) {return _symbol; }
+ function decimals() public view returns (uint8) { return _decimals; }
+ function totalSupply() public view returns (uint256) { return _totalSupply; }
+ function balanceOf(address _owner) public view returns (uint256) { return balances[_owner]; }
+ function isContract(address account) internal view returns (bool) {
+ uint256 size;
+ assembly { size := extcodesize(account) }
+ return size > 0;
+ }
+ function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success){
+ balances[msg.sender] = balances[msg.sender] - _value;
+ balances[_to] = balances[_to] + _value;
+ if(isContract(_to)) {
+ IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data);
+ }
+ emit Transfer(msg.sender, _to, _value, _data);
+ return true;
+ }
+ function transfer(address _to, uint _value) public returns (bool success){
+ bytes memory _empty = hex"00000000";
+ balances[msg.sender] = balances[msg.sender] - _value;
+ balances[_to] = balances[_to] + _value;
+ if(isContract(_to)) {
+ IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty);
+ }
+ emit Transfer(msg.sender, _to, _value, _empty);
+ return true;
+ }
+}
+```
+
+Teraz chcemy, aby inny kontrakt zaakceptował wpłaty tokena o nazwie `tokenA` zakładając, że tokenA jest tokenem ERC-223. Kontrakt musi akceptować tylko tokenA oraz odrzucać wszystkie inne tokeny. Kiedy kontrakt otrzyma tokenA, music wyemitować zdarzenie `Deposit()` oraz zwiększyć wartość wewnętrznej zmiennej `deposits`.
+
+Oto kod:
+
+```solidity
+contract RecipientContract is IERC223Recipient {
+ event Deposit(address whoSentTheTokens);
+ uint256 deposits = 0;
+ address tokenA; // Jedyny token, który chcemy akceptować.
+ function tokenReceived(address _from, uint _value, bytes memory _data) public override
+ {
+ // Ważne jest, aby zrozumieć, że w ramach tej funkcji
+ // msg.sender to adres otrzymywanego tokenu,
+ // msg.value ma zawsze wartość 0, ponieważ kontrakt tokenu w większości przypadków nie posiada ani nie wysyła etheru,
+ // _from to nadawca transferu tokenu,
+ // _value to kwota tokenów, które zostały zdeponowane.
+ require(msg.sender == tokenA);
+ deposits += _value;
+ emit Deposit(_from);
+ }
+}
+```
+
+## Często zadawane pytania {#faq}
+
+### Co się stanie, jeśli wyślę tokenB do kontraktu? {#sending-tokens}
+
+Transakcja się nie powiedzie, a transfer tokenów się nie wydarzy. Tokeny zostają zwrócone na adres nadawcy.
+
+### Jak mogę dokonać wpłaty na ten kontrakt? {#contract-deposits}
+
+Wywołaj funkcję `transfer(address,uint256)` lub `transfer(address,uint256,bytes)` tokena ERC-223, określając adres `RecipientContract`.
+
+### Co się stanie, jeśli wyślę token ERC-20 do tego kontraktu? {#erc-20-transfers}
+
+Jeśli token ERC-20 zostanie wysłany do `RecipientContract`, to tokeny zostaną przesłane, ale transfer nie zostanie rozpoznany (nie zostanie uruchomione żadnego zdarzenie `Deposit()`, a wartość depozytów nie zostanie zmieniona). Niechcianych wpłat ERC-20 nie można filtrować ani im zapobiegać.
+
+### Co, jeśli chcę wykonać jakąś funkcję po zakończeniu wpłaty tokena? {#function-execution}
+
+Istnieje kilka sposobów na zrobienie tego. W tym przykładzie zastosujemy metodę, która sprawia, że transfery ERC-223 są identyczne, jak transfery etheru:
+
+```solidity
+contract RecipientContract is IERC223Recipient {
+ event Foo();
+ event Bar(uint256 someNumber);
+ address tokenA; // The only token that we want to accept.
+ function tokenReceived(address _from, uint _value, bytes memory _data) public override
+ {
+ require(msg.sender == tokenA);
+ address(this).call(_data); // Handle incoming transaction and perform a subsequent function call.
+ }
+ function foo() public
+ {
+ emit Foo();
+ }
+ function bar(uint256 _someNumber) public
+ {
+ emit Bar(_someNumber);
+ }
+}
+```
+
+Kiedy `RecipientContract` otrzyma token ERC-223, kontrakt wykona funkcję zakodowaną jako parametr `_data` transakcji tokena, identycznie do tego, jak transakcje etheru kodują wywołania funkcji jako `data` transakcji. Przeczytaj o [polu danych](/developers/docs/transactions/#the-data-field) po więcej informacji.
+
+W powyższym przykładzie token ERC-223 musi zostać przeniesiony na adres `RecipientContract` przy użyciu funkcji `transfer(address,uin256,bytes calldata _data)`. Jeśli parametr danych będzie wynosił `0xc2985578` (podpis funkcji `foo()`), to funkcja foo() zostanie wywołana po otrzymaniu wpłaty tokena oraz zostanie uruchomione zdarzenie Foo().
+
+Parametry mogą również zostać zakodowane w `data` transferu tokena, dla przykładu możemy wywołać funkcję bar() z wartością 12345 dla `_someNumber`. W tym przypadku `data` musi wynosić
+`0x0423a13200000000000000000000000000000000000000000000000000000000000004d2`, gdzie
+`0x0423a132` to podpis funkcji `bar(uint256)`, a
+`00000000000000000000000000000000000000000000000000000000000004d2` to 12345 w formie uint256.
+
+## Ograniczenia {#limitations}
+
+Chociaż ERC-223 rozwiązuje parę problemów znalezionych w standardzie ERC-20, to nie jest pozbawiony on własnych ograniczeń:
+
+- Przyjęcie i kompatybilność: ERC-223 nie jest jeszcze powszechnie przyjęty, co może ograniczać jego kompatybilność z istniejącymi narzędziami i platformami.
+- Kompatybilność wsteczna: ERC-223 nie jest wstecznie kompatybilny z ERC-20, co oznacza, że istniejące kontrakty ERC-20 i narzędzia nie będą działać z tokenami ERC-223 bez modyfikacji.
+- Koszty gazu: dodatkowe kontrole i funkcje w transferach ERC-223 mogą powodować większe koszta gazu w porównaniu z transakcjami ERC-20.
+
+## Dalsza lektura {#further-reading}
+
+- [EIP-223: standard tokenów ERC-223](https://eips.ethereum.org/EIPS/eip-223)
+- [Wstępna propozycja ERC-223](https://github.com/ethereum/eips/issues/223)
diff --git a/public/content/translations/pl/developers/docs/standards/tokens/erc-4626/index.md b/public/content/translations/pl/developers/docs/standards/tokens/erc-4626/index.md
new file mode 100644
index 00000000000..d06b89522be
--- /dev/null
+++ b/public/content/translations/pl/developers/docs/standards/tokens/erc-4626/index.md
@@ -0,0 +1,227 @@
+---
+title: Standard tokenizowanego skarbca ERC-4626
+description: "Standard dla skarbców przynoszących zyski."
+lang: pl
+---
+
+## Wprowadzenie {#introduction}
+
+ERC-4626 to standard mający na celu optymalizację i ujednolicenie parametrów technicznych skarbców przynoszących zyski. Zapewnia on standardowe API dla tokenizowanych skarbców przynoszących zyski, które reprezentują udziały pojedynczego bazowego tokena ERC-20. ERC-4626 określa również opcjonalne rozszerzenie dla tokenizowanych skarbców wykorzystujących ERC-20, oferując podstawową funkcjonalność do wpłacania i wypłacania tokenów oraz odczytywania sald.
+
+**Rola ERC-4626 w skarbcach przynoszących zyski**
+
+Rynki pożyczkowe, agregatory i samoistnie przynoszące oprocentowanie tokeny pomagają użytkownikom znaleźć najlepszy zysk z ich tokenów kryptowalutowych poprzez wykonywanie różnych strategii. Strategie te są realizowane z niewielkimi różnicami, które mogą być podatne na błędy lub marnować zasoby programistyczne.
+
+ERC-4626 w skarbcach przynoszących zyski zmniejszy wysiłek związany z integracją i odblokuje dostęp do zysków w różnych aplikacjach przy niewielkim specjalistycznym wysiłku ze strony deweloperów, tworząc bardziej spójne i solidne wzorce implementacji.
+
+Token ERC-4626 jest w pełni opisany w [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626).
+
+**Asynchroniczne rozszerzenie skarbca (ERC-7540)**
+
+ERC-4626 jest zoptymalizowany pod kątem atomowych depozytów i wykupów do określonego limitu. Jeśli limit zostanie osiągnięty, nie można złożyć nowych depozytów, ani wykupów. To ograniczenie nie sprawdza się w przypadku systemu inteligentnych kontraktów, w których warunkiem interakcji ze skarbcem są asynchroniczne działania lub opóźnienia (np. protokoły aktywów ze świata rzeczywistego, protokoły pożyczek niezabezpieczonych w pełni, protokoły pożyczania międzyłańcuchowego, tokeny płynnego stakingu czy moduły bezpieczeństwa ubezpieczeniowego).
+
+ERC-7540 rozszerza użyteczność skarbców ERC-4626 na potrzeby przypadków użycia asynchronicznego. Istniejący interfejs skarbca (`deposit`/`withdraw`/`mint`/`redeem`) jest w pełni wykorzystywany do obsługi asynchronicznych żądań.
+
+Rozszerzenie ERC-7540 jest w pełni opisane w [ERC-7540](https://eips.ethereum.org/EIPS/eip-7540).
+
+**Wieloaktywowe rozszerzenie skarbca (ERC-7575)**
+
+Jednym z brakujących przypadków użycia, których nie obsługuje ERC-4626, są skarbce posiadające wiele aktywów lub punkty wejścia, takie jak tokeny dostawców płynności (LP). Zazwyczaj są one niepraktyczne lub niezgodne ze standardem ze względu na wymóg, aby ERC-4626 sam w sobie był ERC-20.
+
+ERC-7575 dodaje obsługę skarbców z wieloma aktywami poprzez wyodrębnienie implementacji tokena ERC-20 z implementacji ERC-4626.
+
+Rozszerzenie ERC-7575 jest w pełni opisane w [ERC-7575](https://eips.ethereum.org/EIPS/eip-7575).
+
+## Wymagania wstępne {#prerequisites}
+
+Aby lepiej zrozumieć tę stronę, zalecamy najpierw przeczytać o [standardach tokenów](/developers/docs/standards/tokens/) i [ERC-20](/developers/docs/standards/tokens/erc-20/).
+
+## Funkcje i cechy ERC-4626: {#body}
+
+### Metody {#methods}
+
+#### aktywo {#asset}
+
+```solidity
+function asset() public view returns (address assetTokenAddress)
+```
+
+Ta funkcja zwraca adres bazowego tokena wykorzystanego w skarbcu do księgowania, wpłacania i wypłacania.
+
+#### totalAssets {#totalassets}
+
+```solidity
+function totalAssets() public view returns (uint256)
+```
+
+Ta funkcja zwraca całkowitą ilość bazowych aktywów przechowywanych przez skarbiec.
+
+#### convertToShares {#convertoshares}
+
+```solidity
+function convertToShares(uint256 assets) public view returns (uint256 shares)
+```
+
+Ta funkcja zwraca ilość `shares`, na które skarbiec wymieniłby podaną ilość `assets`.
+
+#### convertToAssets {#convertoassets}
+
+```solidity
+function convertToAssets(uint256 shares) public view returns (uint256 assets)
+```
+
+Ta funkcja zwraca ilość `assets`, na które skarbiec wymieniłby podaną ilość `shares`.
+
+#### maxDeposit {#maxdeposit}
+
+```solidity
+function maxDeposit(address receiver) public view returns (uint256 maxAssets)
+```
+
+Ta funkcja zwraca maksymalną ilość aktywów bazowych, które mogą zostać zdeponowane w jednym wywołaniu [`deposit`](#deposit), przy czym udziały są wybijane dla `receiver`.
+
+#### previewDeposit {#previewdeposit}
+
+```solidity
+function previewDeposit(uint256 assets) public view returns (uint256 shares)
+```
+
+Ta funkcja pozwala użytkownikom na symulowanie efektów ich wpłaty w bieżącym bloku.
+
+#### deposit {#deposit}
+
+```solidity
+function deposit(uint256 assets, address receiver) public returns (uint256 shares)
+```
+
+Ta funkcja deponuje `assets` tokenów bazowych w skarbcu i przyznaje prawo własności do `shares` dla `receiver`.
+
+#### maxMint {#maxmint}
+
+```solidity
+function maxMint(address receiver) public view returns (uint256 maxShares)
+```
+
+Ta funkcja zwraca maksymalną liczbę udziałów, które mogą zostać wybite w jednym wywołaniu [`mint`](#mint), przy czym udziały są wybijane dla `receiver`.
+
+#### previewMint {#previewmint}
+
+```solidity
+function previewMint(uint256 shares) public view returns (uint256 assets)
+```
+
+Ta funkcja pozwala użytkownikom na symulowanie efektów ich wybicia w bieżącym bloku.
+
+#### mint {#mint}
+
+```solidity
+function mint(uint256 shares, address receiver) public returns (uint256 assets)
+```
+
+Ta funkcja wybija dokładnie `shares` udziałów skarbca dla `receiver` poprzez zdeponowanie `assets` tokenów bazowych.
+
+#### maxWithdraw {#maxwithdraw}
+
+```solidity
+function maxWithdraw(address owner) public view returns (uint256 maxAssets)
+```
+
+Ta funkcja zwraca maksymalną ilość aktywów bazowych, które można wypłacić z salda `owner` w jednym wywołaniu [`withdraw`](#withdraw).
+
+#### previewWithdraw {#previewwithdraw}
+
+```solidity
+function previewWithdraw(uint256 assets) public view returns (uint256 shares)
+```
+
+Ta funkcja pozwala użytkownikom na symulowanie efektów ich wypłaty w bieżącym bloku.
+
+#### withdraw {#withdraw}
+
+```solidity
+function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares)
+```
+
+Ta funkcja spala `shares` od `owner` i wysyła dokładnie `assets` tokenów ze skarbca do `receiver`.
+
+#### maxRedeem {#maxredeem}
+
+```solidity
+function maxRedeem(address owner) public view returns (uint256 maxShares)
+```
+
+Ta funkcja zwraca maksymalną liczbę udziałów, które można wykupić z salda `owner` za pomocą wywołania [`redeem`](#redeem).
+
+#### previewRedeem {#previewredeem}
+
+```solidity
+function previewRedeem(uint256 shares) public view returns (uint256 assets)
+```
+
+Ta funkcja pozwala użytkownikom na symulowanie efektów ich wykupienia w bieżącym bloku.
+
+#### redeem {#redeem}
+
+```solidity
+function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets)
+```
+
+Ta funkcja wykupuje określoną liczbę `shares` od `owner` i wysyła `assets` tokena bazowego ze skarbca do `receiver`.
+
+#### totalSupply {#totalsupply}
+
+```solidity
+function totalSupply() public view returns (uint256)
+```
+
+Zwraca całkowitą liczbę niewykupionych udziałów skarbca w obiegu.
+
+#### balanceOf {#balanceof}
+
+```solidity
+function balanceOf(address owner) public view returns (uint256)
+```
+
+Zwraca całkowitą liczbę udziałów skarbca, jaką aktualnie posiada `owner`.
+
+### Mapa interfejsu {#mapOfTheInterface}
+
+
+
+### Zdarzenia {#events}
+
+#### Wydarzenie Deposit
+
+**MUSI** być emitowane, gdy tokeny są deponowane w skarbcu za pomocą metod [`mint`](#mint) i [`deposit`](#deposit).
+
+```solidity
+event Deposit(
+ address indexed sender,
+ address indexed owner,
+ uint256 assets,
+ uint256 shares
+)
+```
+
+Gdzie `sender` to użytkownik, który wymienił `assets` na `shares` i przeniósł te `shares` na `owner`.
+
+#### Wydarzenie Withdraw
+
+**MUSI** być emitowane, gdy udziały są wypłacane ze skarbca przez deponenta za pomocą metod [`redeem`](#redeem) lub [`withdraw`](#withdraw).
+
+```solidity
+event Withdraw(
+ address indexed sender,
+ address indexed receiver,
+ address indexed owner,
+ uint256 assets,
+ uint256 shares
+)
+```
+
+Gdzie `sender` to użytkownik, który zainicjował wypłatę i wymienił `shares` należące do `owner` na `assets`. `receiver` jest użytkownikiem, który otrzymał wypłacone `assets`.
+
+## Dalsza lektura {#further-reading}
+
+- [EIP-4626: Standard tokenizowanego skarbca](https://eips.ethereum.org/EIPS/eip-4626)
+- [ERC-4626: Repozytorium na GitHubie](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol)
diff --git a/public/content/translations/pl/developers/docs/standards/tokens/erc-721/index.md b/public/content/translations/pl/developers/docs/standards/tokens/erc-721/index.md
index fbee5905d4e..7fc74421cb4 100644
--- a/public/content/translations/pl/developers/docs/standards/tokens/erc-721/index.md
+++ b/public/content/translations/pl/developers/docs/standards/tokens/erc-721/index.md
@@ -1,6 +1,6 @@
---
-title: ERC-721 – standard tokenów niewymiennych
-description:
+title: "ERC-721 – standard tokenów niewymiennych"
+description: "Dowiedz się więcej o ERC-721, standardzie dotyczącym tokenów niezamiennych (NFT), które reprezentują unikalne zasoby cyfrowe Ethereum."
lang: pl
---
@@ -8,15 +8,19 @@ lang: pl
**Czym jest niewymienny token (NFT)?**
-Niewymienne tokeny (NFT) służą do identyfikacji czegoś lub kogoś w unikalny sposób. Ten typ tokenu jest idealny do użycia na platformach, które oferują przedmioty kolekcjonerskie, klucze dostępu, bilety loteryjne, numerowane miejsca na koncerty i mecze sportowe itp. Ten specjalny rodzaj tokena ma niesamowite możliwości, dlatego zasługuje na odpowiedni standard, ERC-721 pojawił się, aby to rozwiązać!
+Niewymienny token (NFT) służy do identyfikacji czegoś lub kogoś w unikalny sposób. Ten typ tokenu jest idealny do
+użycia na platformach, które oferują przedmioty kolekcjonerskie, klucze dostępu, bilety loteryjne, numerowane miejsca na koncerty i
+mecze sportowe itp. Ten specjalny rodzaj tokena ma niesamowite możliwości, dlatego załuguje na właściwy standart i ERC-721 jest tym standardem.
-**Co to jest ERC-721?**
+**Czym jest ERC-721?**
-ERC-721 wprowadza standard dla NFT, innymi słowy ten typ tokena jest unikalny i może mieć różną wartość niż inny token z tego samego inteligentnego kontraktu, być może ze względu na jego wiek, rzadkość, a nawet coś innego, jak jego wygląd. Czekaj, wizualnie?
+ERC-721 wprowadza standard dla NFT, innymi słowy ten typ tokena jest unikalny i może mieć różną wartość
+niż inny token z tego samego inteligentnego kontraktu, być może ze względu na jego wiek, rzadkość, a nawet coś innego, jak jego wygląd.
+Czekaj, wizualnie?
-Tak! Wszystkie NFT mają zmienną `uint256` o nazwie `tokenId`, więc dla każdego kontraktu ERC-721, para `contract address, uint256 tokenId` musi być unikatowa globalnie. Dzięki temu zdecentralizowana aplikacja może mieć „konwerter”, który używa `tokenId` jako danych wejściowych i wyświetla obraz czegoś fajnego, takiego jak zombie, broń, umiejętności lub niesamowite kociaki!
+Tak! Wszystkie NFT mają zmienną `uint256` o nazwie `tokenId`, więc dla każdego kontraktu ERC-721 para `adres kontraktu, uint256 tokenId` musi być globalnie unikalna. To powiedziawszy, dappka może mieć „konwerter”, który używa `tokenId` jako danych wejściowych i wyświetla obraz czegoś fajnego, na przykład zombie, broni, umiejętności lub niesamowitych kociaków!
-## Warunki wstępne {#prerequisites}
+## Wymagania wstępne {#prerequisites}
- [Konta](/developers/docs/accounts/)
- [Inteligentne kontrakty](/developers/docs/smart-contracts/)
@@ -26,11 +30,14 @@ Tak! Wszystkie NFT mają zmienną `uint256` o nazwie `tokenId`, więc dla każde
ERC-721 (Ethereum Request for Comments 721), zaproponowany przez Williama Entrikena, Dietera Shirleya, Jacoba Evansa, Nastassia Sachs w styczniu 2018 r. to standard tokenów niewymiennych, który implementuje interfejs API dla tokenów w ramach inteligentnych kontraktów.
-Zapewnia funkcje, takie jak transfer tokenów z jednego konta na drugie, uzyskanie aktualnego salda tokenów na koncie, uzyskanie informacji o właścicielu określonego tokena, a także o całkowitej podaży tokena dostępnej w sieci. Poza tym ma również kilka innych funkcji, takich jak zatwierdzanie, że ilość tokenu z konta może być wydana przez konto osób trzecich.
+Zapewnia funkcjonalności, takie jak transfer tokenów z jednego konta na drugie, uzyskanie aktualnego salda tokenów na koncie, uzyskanie informacji o właścicielu określonego tokena, a także o całkowitej podaży tokena dostępnej w sieci.
+Poza tym ma również kilka innych funkcji, takich jak zatwierdzanie, że ilość tokenu z konta może być
+wydana przez konto osób trzecich.
-Jeśli inteligentny kontrakt implementuje następujące metody i zdarzenia, można go nazwać kontraktem tokenów niewymiennych ERC-721 , a po wdrożeniu będzie odpowiedzialny za śledzenie utworzonych tokenów w Ethereum.
+Jeśli inteligentny kontrakt implementuje następujące metody i zdarzenia, można go nazwać kontraktem tokenów niewymiennych ERC-721
+, a po wdrożeniu będzie odpowiedzialny za śledzenie utworzonych tokenów w Ethereum.
-Od [EIP-721](https://eips.ethereum.org/EIPS/eip-721):
+Na podstawie [EIP-721](https://eips.ethereum.org/EIPS/eip-721):
### Metody {#methods}
@@ -46,7 +53,7 @@ Od [EIP-721](https://eips.ethereum.org/EIPS/eip-721):
function isApprovedForAll(address _owner, address _operator) external view returns (bool);
```
-### Wydarzenia {#events}
+### Zdarzenia {#events}
```solidity
event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
@@ -56,11 +63,13 @@ Od [EIP-721](https://eips.ethereum.org/EIPS/eip-721):
### Przykłady {#web3py-example}
-Zobaczmy, dlaczego standard jest tak ważny, aby ułatwić nam sprawdza kontraktów z tokenami ERC-721 na Ethereum. Potrzebujemy tylko interfejsu binarnego Umowy (ABI), aby utworzyć interfejs dla każdego tokenu ERC-721. Jak możesz zobaczyć poniżej, użyjemy uproszczonego ABI, aby zmniejszyć złożoność przykładu.
+Zobaczmy, dlaczego standard jest tak ważny, aby ułatwić nam sprawdza kontraktów z tokenami ERC-721 na Ethereum.
+Potrzebujemy tylko interfejsu binarnego Umowy (ABI), aby utworzyć interfejs dla każdego tokenu ERC-721. Jak możesz
+zobaczyć poniżej, użyjemy uproszczonego ABI, aby zmniejszyć złożoność przykładu.
#### Przykład Web3.py {#web3py-example}
-Najpierw upewnij się, że zainstalowałeś [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) bibliotekę Pythona:
+Najpierw upewnij się, że masz zainstalowaną bibliotekę Pythona [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation):
```
pip install web3
@@ -68,17 +77,17 @@ pip install web3
```python
from web3 import Web3
-from web3.utils.events import get_event_data
+from web3._utils.events import get_event_data
w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com"))
-ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # CryptoKitties Contract
+ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # Kontrakt CryptoKitties
-acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # CryptoKitties Sales Auction
+acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # Aukcja sprzedaży CryptoKitties
-# To jest uproszczony interfejs ABI kontraktu ERC-721 NFT.
-# It will expose only the methods: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply()
+# To jest uproszczony binarny interfejs aplikacji kontraktu (ABI) kontraktu ERC-721 NFT.
+# Udostępnia on tylko następujące metody: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply()
simplified_abi = [
{
'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}],
@@ -127,16 +136,16 @@ ck_extra_abi = [
}
]
-ck_contract = w3.eth.contract(address=w3.toChecksumAddress(ck_token_addr), abi=simplified_abi+ck_extra_abi)
+ck_contract = w3.eth.contract(address=w3.to_checksum_address(ck_token_addr), abi=simplified_abi+ck_extra_abi)
name = ck_contract.functions.name().call()
symbol = ck_contract.functions.symbol().call()
kitties_auctions = ck_contract.functions.balanceOf(acc_address).call()
-print(f"{name} [{symbol}] NFTs in Auctions: {kitties_auctions}")
+print(f"{name} [{symbol}] NFT na aukcjach: {kitties_auctions}")
pregnant_kitties = ck_contract.functions.pregnantKitties().call()
-print(f"{name} [{symbol}] NFTs Pregnants: {pregnant_kitties}")
+print(f"{name} [{symbol}] Ciężarne NFT: {pregnant_kitties}")
-# Using the Transfer Event ABI to get info about transferred Kitties.
+# Użycie ABI zdarzenia Transfer do uzyskania informacji o przetransferowanych Kociakach.
tx_event_abi = {
'anonymous': False,
'inputs': [
@@ -147,35 +156,34 @@ tx_event_abi = {
'type': 'event'
}
-# We need the event's signature to filter the logs
-event_signature = w3.sha3(text="Transfer(address,address,uint256)").hex()
+# Potrzebujemy sygnatury zdarzenia do filtrowania logów
+event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex()
-logs = w3.eth.getLogs({
- "fromBlock": w3.eth.blockNumber - 120,
- "address": w3.toChecksumAddress(ck_token_addr),
+logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
"topics": [event_signature]
})
-# Notes:
-# - 120 blocks is the max range for CloudFlare Provider
-# - If you didn't find any Transfer event you can also try to get a tokenId at:
+# Uwagi:
+# - Zwiększ liczbę bloków powyżej 120, jeśli żadne zdarzenie Transfer nie zostanie zwrócone.
+# - Jeśli nie znalazłeś żadnego zdarzenia Transfer, możesz również spróbować uzyskać tokenId pod adresem:
# https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events
-# Click to expand the event's logs and copy its "tokenId" argument
+# Kliknij, aby rozwinąć logi zdarzenia i skopiować jego argument „tokenId”
+recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs]
-recent_tx = [get_event_data(tx_event_abi, log)["args"] for log in logs]
-
-kitty_id = recent_tx[0]['tokenId'] # Paste the "tokenId" here from the link above
-is_pregnant = ck_contract.functions.isPregnant(kitty_id).call()
-print(f"{name} [{symbol}] NFTs {kitty_id} is pregnant: {is_pregnant}")
+if recent_tx:
+ kitty_id = recent_tx[0]['tokenId'] # Wklej tutaj „tokenId” z powyższego linku
+ is_pregnant = ck_contract.functions.isPregnant(kitty_id).call()
+ print(f"{name} [{symbol}] NFT {kitty_id} jest w ciąży: {is_pregnant}")
```
Kontrakt CryptoKitties zawiera kilka ciekawych wydarzeń poza standardowymi.
-Sprawdźmy dwa z nich, `Pregnant ` i `Birth`.
+Sprawdźmy dwa z nich, `Pregnant` i `Birth`.
```python
-# Używanie ABI zdarzeń Pregnant i Birth w celu uzyskania informacji o nowych kociakach.
-
+# Użycie ABI zdarzeń Pregnant i Birth do uzyskania informacji o nowych Kociakach.
ck_extra_events_abi = [
{
'anonymous': False,
@@ -199,50 +207,47 @@ ck_extra_events_abi = [
'type': 'event'
}]
-# We need the event's signature to filter the logs
+# Potrzebujemy sygnatury zdarzenia do filtrowania logów
ck_event_signatures = [
- w3.sha3(text="Pregnant(address,uint256,uint256,uint256)").hex(),
- w3.sha3(text="Birth(address,uint256,uint256,uint256,uint256)").hex(),
+ w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(),
+ w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(),
]
-# Here is a Pregnant Event:
+# Oto zdarzenie Pregnant:
# - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog
-pregnant_logs = w3.eth.getLogs({
- "fromBlock": w3.eth.blockNumber - 120,
- "address": w3.toChecksumAddress(ck_token_addr),
- "topics": [ck_extra_events_abi[0]]
+pregnant_logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [ck_event_signatures[0]]
})
-recent_pregnants = [get_event_data(ck_extra_events_abi[0], log)["args"] for log in pregnant_logs]
+recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs]
-# Here is a Birth Event:
+# Oto zdarzenie Birth:
# - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a
-birth_logs = w3.eth.getLogs({
- "fromBlock": w3.eth.blockNumber - 120,
- "address": w3.toChecksumAddress(ck_token_addr),
- "topics": [ck_extra_events_abi[1]]
+birth_logs = w3.eth.get_logs({
+ "fromBlock": w3.eth.block_number - 120,
+ "address": w3.to_checksum_address(ck_token_addr),
+ "topics": [ck_event_signatures[1]]
})
-recent_births = [get_event_data(ck_extra_events_abi[1], log)["args"] for log in birth_logs]
+recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] for log in birth_logs]
```
## Popularne NFT {#popular-nfts}
-- [Etherscan NFT Tracker](https://etherscan.io/tokens-nft) wyświetla listę najpopularniejszych NFT na Ethereum według wielkości transferów.
-- [CryptoKitties](https://www.cryptokitties.co/) to gra skoncentrowana wokół rozmnażania, kolekcjonerskiego i słodkich stworzonek – CryptoKitties.
-- [Sorare](https://sorare.com/) to globalna gra piłkarska fantasy, w której możesz zbierać limitowane edycje przedmiotów kolekcjonerskich, zarządzać swoimi zespołami i konkurować o zdobycie nagród.
-- [Usługa Nazw Ethereum (ENS)](https://ens.domains/) oferuje bezpieczny i zdecentralizowany sposób na zajęcie się zasobami w i poza łańcuchem bloków przy użyciu prostych imiona czytelne dla człowieka.
-- [Unstoppable Domains](https://unstoppabledomains.com/) jest to firma z San Francisco budująca domeny w blockchainach. Domeny blockchainu zastępują adresy kryptowalut nazwami czytelnymi dla człowieka i mogą być używane do włączenia stron odpornych na cenzurę.
-- [Gods Unchained Cards](https://godsunchained.com/) to TCG w blockchainie Ethereum, który używa NFT do zapewnienia rzeczywistego prawa własności w grze.
+- [Etherscan NFT Tracker](https://etherscan.io/nft-top-contracts) wyświetla listę najpopularniejszych NFT na Ethereum według wolumenu transferów.
+- [CryptoKitties](https://www.cryptokitties.co/) to gra o hodowaniu i kolekcjonowaniu przesłodkich stworzeń, które nazywamy CryptoKitties.
+- [Sorare](https://sorare.com/) to globalna gra piłkarska typu fantasy, w której można zbierać przedmioty kolekcjonerskie z limitowanych edycji, zarządzać swoimi drużynami i rywalizować o nagrody.
+- [Usługa nazw Ethereum (ENS)](https://ens.domains/) oferuje bezpieczny i zdecentralizowany sposób adresowania zasobów zarówno w blockchainie, jak i poza nim, przy użyciu prostych, czytelnych dla człowieka nazw.
+- [POAP](https://poap.xyz) dostarcza darmowe NFT osobom, które uczestniczą w wydarzeniach lub wykonują określone działania. POAPy tworzy się i rozpowszechnia za darmo.
+- [Unstoppable Domains](https://unstoppabledomains.com/) to firma z siedzibą w San Francisco, która tworzy domeny na blockchainach. Domeny blockchain zastępują adresy kryptowalut nazwami czytelnymi dla człowieka i mogą być używane do tworzenia stron internetowych odpornych na cenzurę.
+- [Gods Unchained Cards](https://godsunchained.com/) to gra karciana TCG na blockchainie Ethereum, która wykorzystuje NFT do zapewnienia prawdziwej własności aktywów w grze.
+- [Bored Ape Yacht Club](https://boredapeyachtclub.com) to kolekcja 10 000 unikalnych NFT, która oprócz tego, że jest dziełem sztuki o udowodnionej rzadkości, działa jako token członkowski klubu, zapewniając członkom przywileje i korzyści, które z czasem rosną w wyniku wysiłków społeczności.
## Dalsza lektura {#further-reading}
-- [EIP-721: ERC-721 – standard tokenów niewymiennych](https://eips.ethereum.org/EIPS/eip-721)
-- [OpenZeppelin – dokumentacja ERC-721](https://docs.openzeppelin.com/contracts/3.x/erc721)
-- [OpenZeppelin – implementacja ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol)
-
-## Powiązane tematy {#related-topics}
-
-- [ERC-20](/developers/docs/standards/tokens/erc-20/)
-- [ERC-777](/developers/docs/standards/tokens/erc-777/)
-- [ERC-1155](/developers/docs/standards/tokens/erc-1155/)
+- [EIP-721: Standard tokena niewymiennego ERC-721](https://eips.ethereum.org/EIPS/eip-721)
+- [OpenZeppelin - Dokumentacja ERC-721](https://docs.openzeppelin.com/contracts/3.x/erc721)
+- [OpenZeppelin - Implementacja ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol)
+- [Alchemy NFT API](https://www.alchemy.com/docs/reference/nft-api-quickstart)
diff --git a/public/content/translations/pl/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/pl/developers/docs/standards/tokens/erc-777/index.md
new file mode 100644
index 00000000000..537fb7099f1
--- /dev/null
+++ b/public/content/translations/pl/developers/docs/standards/tokens/erc-777/index.md
@@ -0,0 +1,45 @@
+---
+title: "Standard tokenów ERC-777"
+description: "Dowiedz się więcej o ERC-777, ulepszonym standardzie tokenów zamiennych z hookami, chociaż ERC-20 jest zalecany ze względów bezpieczeństwa."
+lang: pl
+---
+
+## Ostrzeżenie {#warning}
+
+**ERC-777 jest trudny do prawidłowej implementacji ze względu na [podatność na różne formy ataków](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2620). Zaleca się stosowanie [ERC-20](/developers/docs/standards/tokens/erc-20/) zamiast niego.** Ta strona pozostaje jedynie jako historyczne archiwum.
+
+## Wprowadzenie? {#introduction}
+
+ERC-777 to standard tokenów wymiennych, który stanowi ulepszenie istniejącego standardu [ERC-20](/developers/docs/standards/tokens/erc-20/).
+
+## Wymagania wstępne {#prerequisites}
+
+Aby lepiej zrozumieć tę stronę, zalecamy najpierw zapoznać się ze standardem [ERC-20](/developers/docs/standards/tokens/erc-20/).
+
+## Jakie ulepszenia wprowadza ERC-777 w porównaniu do ERC-20? {#-erc-777-vs-erc-20}
+
+ERC-777 wprowadza następujące ulepszenia w porównaniu do ERC-20.
+
+### Hooki {#hooks}
+
+Hooki to funkcje opisane w kodzie inteligentnego kontraktu. Hooki są wywoływane, gdy tokeny są wysyłane lub odbierane za pośrednictwem kontraktu. Pozwala to inteligentnemu kontraktowi reagować na przychodzące lub wychodzące tokeny.
+
+Hooki są rejestrowane i wykrywane przy użyciu standardu [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820).
+
+#### Dlaczego hooki są świetne? {#why-are-hooks-great}
+
+1. Hooki pozwalają wysyłać tokeny do kontraktu i powiadamiać kontrakt w ramach jednej transakcji, w przeciwieństwie do [ERC-20](https://eips.ethereum.org/EIPS/eip-20), który do osiągnięcia tego wymaga dwóch wywołań (`approve`/`transferFrom`).
+2. Kontrakty, które nie zarejestrowały hooków, są niekompatybilne z ERC-777. Kontrakt wysyłający przerwie transakcję, jeśli kontrakt odbierający nie zarejestrował hooka. Zapobiega to przypadkowym transferom do inteligentnych kontraktów innych niż ERC-777.
+3. Hooki mogą odrzucać transakcje.
+
+### Miejsca dziesiętne {#decimals}
+
+Standard ten rozwiązuje również niejasności dotyczące `miejsc dziesiętnych` w ERC-20. Ta przejrzystość poprawia doświadczenia deweloperów.
+
+### Kompatybilność wsteczna z ERC-20 {#backwards-compatibility-with-erc-20}
+
+Z kontraktami ERC-777 można wchodzić w interakcje tak, jakby były to kontrakty ERC-20.
+
+## Dalsza lektura {#further-reading}
+
+[EIP-777: standard tokenów ERC-777](https://eips.ethereum.org/EIPS/eip-777)
diff --git a/public/content/translations/pl/developers/docs/standards/tokens/index.md b/public/content/translations/pl/developers/docs/standards/tokens/index.md
index 6f89f69c06e..d6423ca817c 100644
--- a/public/content/translations/pl/developers/docs/standards/tokens/index.md
+++ b/public/content/translations/pl/developers/docs/standards/tokens/index.md
@@ -1,33 +1,41 @@
---
-title: Standardy tokenów
-description:
+title: "Standardy tokenów"
+description: "Odkryj standardy tokenów Ethereum takie jak ERC-20, ERC-721 oraz ERC-1155 przeznaczone dla zamiennych oraz niezamiennych tokenów."
lang: pl
incomplete: true
---
## Wprowadzenie {#introduction}
-Jeden z wielu standardów rozwoju Ethereum koncentruje się na interfejsach tokenów. Standardy te pomagają zapewnić, że inteligentne kontrakty pozostają kompatybilne, więc na przykład, gdy nowy projekt emituje token, pozostaje on kompatybilny z istniejącymi zdecentralizowanymi giełdami.
+Wiele standardów rozwoju Ethereum koncentruje się na interfejsach tokenów. Standardy te pomagają zapewnić, że inteligentne kontrakty pozostają komponowalne, więc gdy nowy projekt emituje token, pozostaje on kompatybilny z istniejącymi zdecentralizowanymi giełdami i aplikacjami.
-## Warunki wstępne {#prerequisites}
+Standardy tokenów określają, jak tokeny zachowują się i wchodzą w interakcje w całym ekosystemie Ethereum. Ułatwiają one deweloperom tworzenie bez wymyślania koła na nowo, zapewniając, że tokeny działają bezproblemowo z portfelami, giełdami i platformami DeFi. Czy to w grach, zarządzaniu, czy innych przypadkach użycia, standardy te zapewniają spójność i sprawiają, że Ethereum jest bardziej wzajemnie połączone.
-- [Standardy rozwoju Ethereum](/developers/docs/standards/)
+## Wymagania wstępne {#prerequisites}
+
+- [Standardy programistyczne Ethereum](/developers/docs/standards/)
- [Inteligentne kontrakty](/developers/docs/smart-contracts/)
## Standardy tokenów {#token-standards}
Oto niektóre z najpopularniejszych standardów tokenów na Ethereum:
-- [ERC20 – standardowy interfejs tokenów](/developers/docs/standards/tokens/erc-20/)
-- [ERC721 – standardowy interfejs niewymiennych tokenów](/developers/docs/standards/tokens/erc-721/)
+- [ERC-20](/developers/docs/standards/tokens/erc-20/) – standardowy interfejs dla tokenów zamiennych (wymienialnych), takich jak tokeny do głosowania, tokeny stakingowe lub wirtualne waluty.
+
+### Standardy NFT {#nft-standards}
+
+- [ERC-721](/developers/docs/standards/tokens/erc-721/) – standardowy interfejs dla tokenów niezamiennych, takich jak akt własności dzieła sztuki lub piosenki.
+- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) – ERC-1155 pozwala na bardziej wydajne wymiany i łączenie transakcji, oszczędzając w ten sposób koszty. Ten standard tokenów pozwala na tworzenie zarówno tokenów użytkowych (takich jak $BNB lub $BAT), jak i tokenów niewymienialnych takich jak CryptoPunks.
+
+Pełna lista propozycji [ERC](https://eips.ethereum.org/erc).
## Dalsza lektura {#further-reading}
-_Znasz jakieś zasoby społeczności, które Ci pomogły? Wyedytuj tę stronę i dodaj je!_
+_Znasz jakieś zasoby społeczności, które Ci pomogły? Edytuj tę stronę i dodaj je!_
## Powiązane samouczki {#related-tutorials}
-- [Lista kontrolna integracji tokenów](/developers/tutorials/token-integration-checklist/) _– lista kontrolna rzeczy, które należy wziąć pod uwagę podczas interakcji z tokenami._
-- [Zrozumienie inteligentnego kontraktu tokena ERC20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– wprowadzenie do wdrożenie pierwszego inteligentnego kontraktu w sieci testowej Ethereum._
-- [Przenoszenie i zatwierdzanie tokenów ERC20 z inteligentnego kontraktu Solidity](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– jak używać inteligentnego kontraktu do interakcji z tokenem przy użyciu języka Solidity._
-- [Wdrażanie rynku ERC721 [przewodnik]](/developers/tutorials/how-to-implement-an-erc721-market/) _– jak wystawiać tokenizowane przedmioty na sprzedaż na zdecentralizowanej tablicy ogłoszeń._
+- [Lista kontrolna integracji tokenów](/developers/tutorials/token-integration-checklist/) _– Lista kontrolna rzeczy, które należy wziąć pod uwagę podczas interakcji z tokenami._
+- [Zrozumienie inteligentnego kontraktu tokena ERC20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– Wprowadzenie do wdrażania pierwszego inteligentnego kontraktu w sieci testowej Ethereum._
+- [Transferowanie oraz zatwierdzanie tokenów ERC20 z inteligentnego kontraktu w Solidity](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– Jak używać inteligentnego kontraktu do interakcji z tokenem przy użyciu języka Solidity._
+- [Wdrażanie rynku ERC721 [przewodnik]](/developers/tutorials/how-to-implement-an-erc721-market/) _– Jak wystawiać tokenizowane przedmioty na sprzedaż na zdecentralizowanej tablicy ogłoszeń._