From dd70237d7ae1f1125fc3a7aeb48c106a7015029b Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sat, 14 Feb 2026 00:08:16 +0000 Subject: [PATCH 1/2] i18n(pl): translation import part 11 of 13 (23 files) --- .../pl/roadmap/merge/issuance/index.md | 104 +-- .../translations/pl/roadmap/pbs/index.md | 27 +- .../pl/roadmap/pectra/7702/index.md | 149 +++++ .../translations/pl/roadmap/pectra/index.md | 127 ++++ .../pl/roadmap/pectra/maxeb/index.md | 204 ++++++ .../translations/pl/roadmap/scaling/index.md | 16 +- .../roadmap/secret-leader-election/index.md | 16 +- .../translations/pl/roadmap/security/index.md | 30 +- .../pl/roadmap/single-slot-finality/index.md | 26 +- .../pl/roadmap/statelessness/index.md | 42 +- .../pl/roadmap/user-experience/index.md | 14 +- .../pl/roadmap/verkle-trees/index.md | 28 +- .../content/translations/pl/security/index.md | 121 ++-- .../translations/pl/smart-contracts/index.md | 40 +- .../translations/pl/social-networks/index.md | 124 ++-- .../translations/pl/staking/dvt/index.md | 40 +- .../translations/pl/staking/pools/index.md | 36 +- .../translations/pl/staking/saas/index.md | 42 +- .../translations/pl/staking/solo/index.md | 136 ++-- .../pl/staking/withdrawals/index.md | 99 ++- public/content/translations/pl/web3/index.md | 62 +- .../translations/pl/what-are-apps/index.md | 80 +++ .../translations/pl/whitepaper/index.md | 591 +++++++++--------- 23 files changed, 1400 insertions(+), 754 deletions(-) create mode 100644 public/content/translations/pl/roadmap/pectra/7702/index.md create mode 100644 public/content/translations/pl/roadmap/pectra/index.md create mode 100644 public/content/translations/pl/roadmap/pectra/maxeb/index.md create mode 100644 public/content/translations/pl/what-are-apps/index.md diff --git a/public/content/translations/pl/roadmap/merge/issuance/index.md b/public/content/translations/pl/roadmap/merge/issuance/index.md index 2a7e41a3ed0..d030f220483 100644 --- a/public/content/translations/pl/roadmap/merge/issuance/index.md +++ b/public/content/translations/pl/roadmap/merge/issuance/index.md @@ -1,120 +1,126 @@ --- -title: Jak Połączenie wpłynęło na podaż ETH -description: Analiza wpływu Połączenia na podaż ETH +title: "Jak Połączenie wpłynęło na podaż ETH" +description: "Analiza wpływu Połączenia na podaż ETH" lang: pl --- # Jak Połączenie wpłynęło na podaż ETH {#how-the-merge-impacts-ETH-supply} -Połączenie reprezentowało przejście sieci Ethereum z proof-of-work na proof-of-stake, które miało miejsce we wrześniu 2022. Sposób emitowania ETH uległ zmianie w czasie tego przejścia. Wcześniej nowe ETH było emitowane z dwóch źródeł: warstwy wykonawczej (tj. sieci głównej) i warstwy konsensusu (tj. łańcucha śledzącego). Od czasu Połączenia emisja na warstwie wykonawczej wynosi teraz zero. Przeanalizujmy to. +Połączenie reprezentowało przejście sieci Ethereum z proof-of-work na proof-of-stake, które miało miejsce we wrześniu 2022. Sposób emitowania ETH uległ zmianie w czasie tego przejścia. Wcześniej nowe ETH było emitowane z dwóch źródeł: warstwy wykonawczej (tj. sieci głównej) i warstwy konsensusu (tj. Łańcucha śledzącego). Od czasu Połączenia emisja na warstwie wykonawczej wynosi teraz zero. Przeanalizujmy to. ## Składniki emisji ETH {#components-of-eth-issuance} Możemy podzielić podaż ETH na dwie główne siły: emisję i spalanie. -**Emisja** ETH to proces tworzenia ETH, które wcześniej nie istniało. **Spalanie** ETH ma miejsce, gdy ETH ulega zniszczeniu, skutkując jego usunięciem z obiegu. Prędkość emisji i spalania jest obliczana na podstawie kilku parametrów, a równowaga między nimi określa uzyskany wskaźnik inflacji/deflacji etheru. +**Emisja** ETH to proces tworzenia ETH, które wcześniej nie istniało. **Spalanie** ETH ma miejsce, gdy istniejące ETH ulega zniszczeniu, co skutkuje jego usunięciem z obiegu. Prędkość emisji i spalania jest obliczana na podstawie kilku parametrów, a równowaga między nimi określa uzyskany wskaźnik inflacji/deflacji etheru. - -- Przed przejściem na proof-of-stake górnicy emitowali około 13 000 ETH dziennie -- Stakerzy emitują około 1700 ETH dziennie na podstawie około 14 milionów zestakowanych ETH -- Dokładna emisja ze stakingu zmienia się w zależności od całkowitej liczby zestakowanych ETH -- **Od czasu Połączenia pozostało tylko około 1700 ETH na dzień, co oznacza spadek całkowitej emisji nowych ETH o około 88%** -- Spalanie: zmienia się w zależności od zapotrzebowania sieci. _Jeśli_ w danym dniu odnotowana zostanie średnia cena gazu wynosząca co najmniej 16 gwei, skutecznie równoważy to około 1700 ETH, które są wydawane walidatorom i sprowadza inflację netto ETH do zera lub niższego poziomu w danym dniu. +title="Emisja ETH w skrócie"> +- Przed przejściem na proof-of-stake górnicy otrzymywali w ramach emisji około 13 000 ETH/dzień +- Stakerzy otrzymują w ramach emisji około 1700 ETH/dzień, przy około 14 milionach zestakowanych ETH +- Dokładna emisja ze stakowania zmienia się w zależności od całkowitej kwoty zestakowanego ETH +- **Od czasu Połączenia pozostaje tylko ~1700 ETH/dzień, co obniża całkowitą nową emisję ETH o ~88%** +- Spalanie: Waha się w zależności od zapotrzebowania sieci. _Jeśli_ w danym dniu odnotowana zostanie średnia cena gazu wynosząca co najmniej 16 gwei, skutecznie równoważy to około 1700 ETH, które są wydawane walidatorom i sprowadza inflację netto ETH do zera lub niższego poziomu w danym dniu. -## Przed połączeniem (historia) {#pre-merge} +## Przed Połączeniem (dane historyczne) {#pre-merge} ### Emisja warstwy wykonawczej {#el-issuance-pre-merge} -W ramach proof-of-work górnicy wchodzili w interakcję tylko z warstwą wykonawczą i byli nagradzani nagrodami za blok, jeśli byli pierwszymi górnikami, którzy rozwiązali następny blok. Od czasu [aktualizacji Constantinople](/ethereum-forks/#constantinople) w 2019 r. nagroda ta wynosiła 2 ETH za blok. Górnicy byli również nagradzani za publikowanie bloków [ommer](/glossary/#ommer), które były poprawnymi blokami, które nie trafiły do najdłuższego/kanonicznego łańcucha. Nagrody te osiągnęły maksymalną wartość 1,75 ETH za ommer i były _dodatkiem do_ nagrody wydanej z bloku kanonicznego. Proces kopania był ekonomicznie intensywną działalnością, która w przeszłości wymagała wysokiego poziomu emisji ETH do podtrzymania. +W ramach proof-of-work górnicy wchodzili w interakcję tylko z warstwą wykonawczą i byli nagradzani nagrodami za blok, jeśli byli pierwszymi górnikami, którzy rozwiązali następny blok. Od aktualizacji [Constantinople](/ethereum-forks/#constantinople) w 2019 r. nagroda ta wynosiła 2 ETH za blok. Górnicy byli również nagradzani za publikowanie bloków [ommer](/glossary/#ommer), które były prawidłowymi blokami, które nie trafiły do najdłuższego/kanonicznego łańcucha. Nagrody te wynosiły maksymalnie 1,75 ETH za ommer i były _dodatkiem_ do nagrody wydawanej za blok kanoniczny. Proces kopania był ekonomicznie intensywną działalnością, która w przeszłości wymagała wysokiego poziomu emisji ETH do podtrzymania. ### Emisja warstwy konsensusu {#cl-issuance-pre-merge} -[Łańcuch śledzący](/ethereum-forks/#beacon-chain-genesis) został uruchomiony w 2020 r. Zamiast górników jest on zabezpieczany przez walidatory wykorzystujące proof-of-stake. Łańcuch ten został uruchomiony przez użytkowników Ethereum wpłacających ETH w jedną stronę do inteligentnego kontraktu w sieci głównej (warstwa wykonawcza), którego nasłuchuje łańcuch śledzący, przyznając użytkownikowi taką samą ilość ETH w nowym łańcuchu. Dopóki nie nastąpiło Połączenie, walidatory łańcucha śledzącego nie przetwarzały transakcji i zasadniczo dochodziły do konsensusu na temat stanu samej puli walidatorów. +[Beacon Chain](/ethereum-forks/#beacon-chain-genesis) został uruchomiony w 2020 r. Zamiast górników jest on zabezpieczany przez walidatory wykorzystujące proof-of-stake. Łańcuch ten został uruchomiony przez użytkowników Ethereum wpłacających ETH w jedną stronę do inteligentnego kontraktu w sieci głównej (warstwa wykonawcza), którego nasłuchuje łańcuch śledzący, przyznając użytkownikowi taką samą ilość ETH w nowym łańcuchu. Dopóki nie nastąpiło Połączenie, walidatory łańcucha śledzącego nie przetwarzały transakcji i zasadniczo dochodziły do konsensusu na temat stanu samej puli walidatorów. -Walidatory w łańcuchu śledzącym są nagradzane ETH za poświadczanie stanu łańcucha i proponowanie bloków. Nagrody (lub kary) są obliczane i rozdzielane w każdej epoce (co 6,4 minuty) na podstawie wydajności walidatora. Nagrody walidatora są **znacznie** niższe niż nagrody za kopanie, które wcześniej były emitowane w ramach proof-of-work (2 ETH co około 13,5 sekundy), ponieważ obsługa węzła walidacyjnego nie jest tak intensywna ekonomicznie, a zatem nie wymaga ani nie gwarantuje tak wysokiej nagrody. +Walidatory w łańcuchu śledzącym są nagradzane ETH za poświadczanie stanu łańcucha i proponowanie bloków. Nagrody (lub kary) są obliczane i rozdzielane w każdej epoce (co 6,4 minuty) na podstawie wydajności walidatora. Nagrody dla walidatorów są **znacznie** niższe niż nagrody za wydobycie, które były wcześniej emitowane w ramach proof-of-work (2 ETH co ~13,5 sekundy), ponieważ obsługa węzła walidacyjnego nie jest tak intensywna ekonomicznie i w związku z tym nie wymaga tak wysokiej nagrody. -### Zestawienie emisji przed Połączeniem {#pre-merge-issuance-breakdown} +### Podział emisji przed Połączeniem {#pre-merge-issuance-breakdown} -Całkowita podaż ETH: **około 120.520.000 ETH** (w momencie Połączenia we wrześniu 2022) +Całkowita podaż ETH: **~120 520 000 ETH** (w momencie Połączenia we wrześniu 2022 r.) **Emisja warstwy wykonawczej:** -- Została oszacowana na 2,08 ETH na 13,3 sekundy\*: **około 4 930 000** ETH emitowanych w ciągu roku -- Skutkowała stopą inflacji wynoszącą **około 4,09%** (4,93 mln rocznie / 120,5 mln łącznie) -- \*Obejmuje to 2 ETH za blok kanoniczny plus średnio 0,08 ETH za czas z bloków ommer. Wykorzystuje również 13,3 sekundy podstawowego czasu bloku bez żadnego wpływu [bomby trudności](/glossary/#difficulty-bomb). ([Sprawdź źródło](https://bitinfocharts.com/ethereum/)) +- Została oszacowana na 2,08 ETH na 13,3 sekundy\*: **~4 930 000** ETH emitowanych w ciągu roku +- Skutkowało to stopą inflacji wynoszącą **około 4,09%** (4,93 mln rocznie / 120,5 mln łącznie) +- \*Obejmuje to 2 ETH za blok kanoniczny plus średnio 0,08 ETH za czas z bloków ommer. Używa również 13,3 sekundy, docelowego bazowego czasu bloku bez żadnego wpływu [bomby trudności](/glossary/#difficulty-bomb). ([Zobacz źródło](https://bitinfocharts.com/ethereum/)) **Emisja warstwy konsensusu:** -- Przy wykorzystaniu 14 000 000 łącznych zestakowanych ETH tempo emisji ETH wynosi około 1700 ETH dziennie ([Sprawdź źródło](https://ultrasound.money/)) -- Skutkuje emisją **około 620 500** ETH rocznie -- Skutkowała stopą inflacji wynoszącą **około 0,52%** (620,5 tys. rocznie / 119,3 mln łącznie) +- Przy 14 000 000 ETH w stakowaniu, wskaźnik emisji ETH wynosi około 1700 ETH/dzień ([Zobacz źródło](https://ultrasound.money/)) +- Skutkuje to emisją **~620 500** ETH w ciągu roku +- Skutkowało to stopą inflacji wynoszącą **około 0,52%** (620,5 tys. rocznie / 119,3 mln łącznie) -**Łączna roczna stopa emisji (przed Połączeniem): około 4,61%** (4,09% + 0,52%) +**Całkowita roczna stopa emisji (przed Połączeniem): ~4,61%** (4,09% + 0,52%) -**około 88,7%** emisji trafiło do górników w warstwie wykonawczej (4,09 / 4,61 * 100) +**~88,7%** emisji trafiało do górników w warstwie wykonawczej (4,09 / 4,61 \* 100) -**około 11,3%** emisji trafiło do stakerów w warstwie konsensusu (0,52 / 4,61 * 100) +**~11,3%** było emitowane dla stakerów w warstwie konsensusu (0,52 / 4,61 \* 100) + + -## Po Połączeniu (dzień dzisiejszy) {#post-merge} +## Po Połączeniu (obecnie) {#post-merge} ### Emisja warstwy wykonawczej {#el-issuance-post-merge} -Od czasu Połączenia, emisja warstwy wykonawczej wynosi zero. Proof-of-work nie jest już używanym środkiem produkcji bloków w ramach ulepszonych zasad konsensusu. Cała aktywność warstwy wykonawczej zawiera się w „blokach śledzących”, które są publikowane i poświadczane przez walidatory proof-of-stake. Nagrody za poświadczanie i publikowanie bloków śledzących są rozliczane oddzielnie w warstwie konsensusu. +Emisja warstwy wykonawczej od czasu Połączenia wynosi zero. Proof-of-work nie jest już prawidłowym sposobem produkcji bloków w ramach zaktualizowanych zasad konsensusu. Cała aktywność warstwy wykonawczej jest pakowana w \"bloki śledzące\", które są publikowane i poświadczane przez walidatorów proof-of-stake. Nagrody za poświadczanie i publikowanie bloków śledzących są rozliczane oddzielnie w warstwie konsensusu. ### Emisja warstwy konsensusu {#cl-issuance-post-merge} -Emisja warstwy konsensusu trwa dziś dalej tak, jak przed Połączeniem, z niewielkimi nagrodami dla walidatorów, które poświadczają i proponują bloki. Nagrody walidatorów są nadal wliczane do _sald walidatorów_, które są zarządzane w warstwie konsensusu. W przeciwieństwie do bieżących kont (kont „wykonawczych”), które mogą dokonywać transakcji w sieci głównej, te oddzielne konta Ethereum nie mogą swobodnie dokonywać transakcji z innymi kontami Ethereum. Środki na tych kontach mogą być wypłacane tylko na jeden określony adres realizacji. +Emisja w warstwie konsensusu trwa do dziś, tak jak przed Połączeniem, z niewielkimi nagrodami dla walidatorów, którzy poświadczają i proponują bloki. Nagrody dla walidatorów są nadal doliczane do _sald walidatorów_, które są zarządzane w warstwie konsensusu. W przeciwieństwie do istniejących kont (kont \"wykonawczych\"), które mogą przeprowadzać transakcje w sieci Mainnet, te oddzielne konta Ethereum nie mogą swobodnie przeprowadzać transakcji z innymi kontami Ethereum. Środki z tych kont można wypłacić tylko na jeden określony adres wykonawczy. -Od aktualizacji Shanghai/Capella, która miała miejsce w kwietniu 2023, te wypłaty zostały odblokowane dla stakerów. Stakerzy są zachęcani do usuwania swoich _zarobków/nagród (saldo powyżej 32 ETH)_, ponieważ w przeciwnym razie środki te nie są wliczane do ich wagi stawki (która wynosi maksymalnie 32). +Od aktualizacji Shanghai/Capella, która miała miejsce w kwietniu 2023 r., wypłaty te zostały włączone dla stakerów. Stakerzy są zachęcani do wypłacania swoich _zarobków/nagród (salda powyżej 32 ETH)_, ponieważ w przeciwnym razie środki te nie powiększają wagi ich stawki (która wynosi maksymalnie 32). -Stakerzy mogą również zdecydować się na wyjście i wypłacenie całego salda walidatora. Dla zapewnienia stabilności Ethereum liczba walidatorów opuszczających ją jednocześnie jest ograniczona. +Stakerzy mogą również zdecydować się na wyjście i wypłatę całego salda walidatora. Aby zapewnić stabilność Ethereum, liczba walidatorów opuszczających sieć jednocześnie jest ograniczona. -Około 0,33% całkowitej liczby walidatorów może opuścić platformę w danym dniu. Domyślnie cztery (4) walidatory mogą opuścić platformę w danej epoce (co 6,4 minuty lub 900 dziennie). Jeden dodatkowy (1) walidator ma pozwolenie na opuszczenie platformy za każde 65 536 (216) dodatkowych walidatorów powyżej 262 144 (218). Na przykład przy ponad 327680 walidatorach, pięć (5) może opuścić platformę w danej epoce (1 125 dziennie). Sześć (6) otrzyma pozwolenie przy całkowitej liczbie aktywnych walidatorów powyżej 393 216 itd. +Około 0,33% całkowitej liczby walidatorów może wyjść w ciągu jednego dnia. Domyślnie czterech (4) walidatorów może wyjść na epokę (co 6,4 minuty, czyli 900 dziennie). Dodatkowy jeden (1) walidator może wyjść na każde 65 536 (216) dodatkowych walidatorów powyżej 262 144 (218). Na przykład, przy ponad 327 680 walidatorach, pięciu (5) może wyjść na epokę (1125 dziennie). Sześciu (6) będzie mogło wyjść przy łącznej liczbie aktywnych walidatorów powyżej 393 216 i tak dalej. -W miarę wychodzenia większej liczby walidatorów maksymalna liczba wychodzących walidatorów będzie stopniowo zmniejszana do minimum czterech, co ma zapobiec jednoczesnemu wycofywaniu dużych destabilizujących ilości zestakowanych ETH. +W miarę jak coraz więcej walidatorów dokonuje wypłaty, maksymalna liczba wychodzących walidatorów będzie stopniowo zmniejszana do minimum czterech, aby celowo zapobiec jednoczesnemu wycofywaniu dużych, destabilizujących kwot zestakowanego ETH. -### Analiza inflacji po Połączeniu {#post-merge-inflation-breakdown} +### Podział inflacji po Połączeniu {#post-merge-inflation-breakdown} -- Całkowita podaż ETH: **około 120.520.000 ETH** (w momencie Połączenia we wrześniu 2022) +- Całkowita podaż ETH: **~120 520 000 ETH** (w momencie Połączenia we wrześniu 2022 r.) - Emisja warstwy wykonawczej: **0** -- Emisja warstwy konsensusu: Taka jak powyżej, **około 0,52%** rocznej stopy emisji (przy 14 mln zestakowanego ETH) +- Emisja w warstwie konsensusu: Tak samo jak powyżej, roczna stopa emisji na poziomie **~0,52%** (przy 14 milionach zestakowanych ETH) -Całkowita roczna stopa emisji: **około 0,52%** +Całkowita roczna stopa emisji: **~0,52%** -Redukcja netto w rocznej emisji ETH: **około 88,7%** ((4,61% - 0,52%) / 4,61% * 100) +Redukcja netto rocznej emisji ETH: **~88,7%** ((4,61% - 0,52%) / 4,61% \* 100) + + -##  Spalanie {#the-burn} +## Spalanie {#the-burn} -Siłą przeciwną do emisji ETH jest tempo, w jakim ETH jest spalane. Aby transakcja została wykonana na Ethereum, należy uiścić minimalną opłatę (zwaną „opłatą bazową”), która ciągle się zmienia (blok po bloku) w zależności od aktywności sieci. Opłata jest uiszczana w ETH i jest _wymagana_, aby transakcja została uznana za poprawną. Opłata ta jest _spalana_ podczas procesu transakcji, co skutkuje usunięciem jej z obiegu. +Siłą przeciwną do emisji ETH jest tempo, w jakim ETH jest spalane. Aby transakcja została wykonana na Ethereum, należy uiścić minimalną opłatę (zwaną „opłatą bazową”), która ciągle się zmienia (blok po bloku) w zależności od aktywności sieci. Opłata jest uiszczana w ETH i jest _wymagana_, aby transakcja została uznana za ważną. Opłata ta jest _spalana_ w trakcie procesu transakcji, co powoduje usunięcie jej z obiegu. -Spalanie opłat weszło w życie wraz z [aktualizacją London](/ethereum-forks/#london) w sierpniu 2021 i pozostaje niezmienione od czasu Połączenia. + +Spalanie opłat zostało wprowadzone wraz z [aktualizacją London](/ethereum-forks/#london) w sierpniu 2021 r. i pozostaje niezmienione od czasu Połączenia. + + Oprócz spalania opłat wprowadzonych przez aktualizację London, walidatory mogą również ponosić kary za bycie offline lub, co gorsza, mogą zostać odcięte za złamanie określonych zasad, które zagrażają bezpieczeństwu sieci. Kary te skutkują potrąceniem ETH z salda danego walidatora, które nie jest bezpośrednio przekazywane jako nagroda na żadne inne konto, skutecznie spalając/usuwając je z obiegu. -### Obliczanie średniej ceny gazu przy deflacji {#calculating-average-gas-price-for-deflation} +### Obliczanie średniej ceny gazu dla deflacji {#calculating-average-gas-price-for-deflation} Jak wspomnieliśmy powyżej, ilość wyemitowanych ETH w danym dniu zależy od łącznej ilości zestakowanych ETH. W chwili pisania tego tekstu jest to około 1700 ETH na dzień. @@ -124,15 +130,15 @@ Aby określić średnią cenę gazu wymaganą do całkowitego zrównoważenia te - `(5 bloków/minuta) * (60 minut/godzina) = 300 bloków/godzina` - `(300 bloków/godzina) * (24 godziny/dzień) = 7200 bloków/dzień` -Każdy blok stara się uzyskać `15x10^6 gazu na blok` ([więcej o gazie](/developers/docs/gas/)). Korzystając z tego, możemy obliczyć średnią cenę gazu (w jednostkach gwei/gaz) wymaganą do zrównoważenia emisji, przyjmując, że całkowita dzienna emisja ETH wynosi 1700 ETH: +Każdy blok ma docelowo `15x10^6 gazu/blok` ([więcej o gazie](/developers/docs/gas/)). Korzystając z tego, możemy obliczyć średnią cenę gazu (w jednostkach gwei/gaz) wymaganą do zrównoważenia emisji, przyjmując, że całkowita dzienna emisja ETH wynosi 1700 ETH: -- `7200 bloków/dzień * 15x10^6 gazu/blok *`**`Y gwei/gaz`**`* 1 ETH/10^9 gwei = 1700 ETH/dzień` +- `7200 bloków/dzień * 15x10^6 gazu/blok * `**`Y gwei/gaz`**` * 1 ETH/10^9 gwei = 1700 ETH/dzień` Rozwiązanie dla `Y`: -- `Y = (1700(10^9))/(7200 * 15(10^6)) = (17x10^3)/(72 * 15) = 16 gwei` (zaokrąglone do dwóch cyfr znaczących) +- `Y = (1700(10^9))/(7200 * 15(10^6)) = (17x10^3)/(72 * 15) = 16 gwei` (w zaokrągleniu do dwóch cyfr znaczących) -Innym sposobem na przekształcenie tego ostatniego kroku byłoby zastąpienie `1700` zmienną `X`, która reprezentuje dzienną emisję ETH, i uproszczenie reszty do: +Innym sposobem na przekształcenie tego ostatniego kroku byłoby zastąpienie `1700` zmienną `X`, która reprezentuje dzienną emisję ETH i uproszczenie reszty do: - `Y = (X(10^3)/(7200 * 15)) = X/108` @@ -140,10 +146,10 @@ Możemy to uprościć i zapisać jako funkcję `X`: - `f(X) = X/108`, gdzie `X` to dzienna emisja ETH, a `f(X)` reprezentuje cenę gwei/gaz wymaganą do zrównoważenia wszystkich nowo wyemitowanych ETH. -Tak więc na przykład jeśli `X` (dzienna emisja ETH) wzrośnie do 1800 na podstawie całkowitej liczby zestakowanych ETH, `f(X)` (gwei wymagane do zrównoważenia całej emisji) wyniesie `17 gwei` (przy użyciu 2 cyfr znaczących) +Tak więc, na przykład, jeśli `X` (dzienna emisja ETH) wzrośnie do 1800 w oparciu o całkowitą liczbę zestakowanych ETH, `f(X)` (gwei wymagane do zrównoważenia całej emisji) wyniesie `17 gwei` (przy użyciu 2 cyfr znaczących) ## Dalsza lektura {#further-reading} - [Połączenie](/roadmap/merge/) -- [Ultrasound.money](https://ultrasound.money/) — _Pulpity nawigacyjne do wizualizacji emisji i spalania ETH w czasie rzeczywistym_ -- [Tworzenie wykresów emisji Ethereum](https://www.attestant.io/posts/charting-ethereum-issuance/) — _Jim McDonald 2020_ +- [Ultrasound.money](https://ultrasound.money/) – _pulpity nawigacyjne dostępne do wizualizacji emisji i spalania ETH w czasie rzeczywistym_ +- [Charting Ethereum Issuance](https://www.attestant.io/posts/charting-ethereum-issuance/) – _Jim McDonald 2020_ diff --git a/public/content/translations/pl/roadmap/pbs/index.md b/public/content/translations/pl/roadmap/pbs/index.md index 6e45dd6c58b..c5b21566e64 100644 --- a/public/content/translations/pl/roadmap/pbs/index.md +++ b/public/content/translations/pl/roadmap/pbs/index.md @@ -1,43 +1,42 @@ --- -title: Separacja proponujący-budujący -description: Dowiedz się, w jaki sposób i dlaczego walidatory Ethereum podzielą swoje obowiązki związane z tworzeniem i rozpowszechnianiem bloków. +title: "Separacja proponującego i budującego" +description: "Dowiedz się, w jaki sposób i dlaczego walidatory Ethereum podzielą swoje obowiązki związane z tworzeniem i rozpowszechnianiem bloków." lang: pl --- -# Separacja proponujący-budujący {#proposer-builder-separation} +# Separacja proponującego i budowniczego {#proposer-builder-separation} -Obecne walidatory Ethereum tworzą _i_ rozpowszechniają bloki. Łączą transakcje, o których dowiedziały się za pośrednictwem sieci plotek i grupują je w blok, który jest wysyłany do ich odpowiedników w sieci Ethereum. **Podział proponujący-twórca (PBS)** dzieli te zadania na wiele walidatorów. Twórcy bloków stają się odpowiedzialni za tworzenie bloków i oferowanie ich proponentom bloków w każdym slocie. Proponent bloku nie może zobaczyć zawartości bloku; po prostu wybiera ten najbardziej opłacalny, uiszczając opłatę na rzecz twórcy bloku przed wysłaniem bloku do swoich odpowiedników. +Obecni walidatorzy Ethereum tworzą _i_ rozpowszechniają bloki. Łączą transakcje, o których dowiedziały się za pośrednictwem sieci plotek i grupują je w blok, który jest wysyłany do ich odpowiedników w sieci Ethereum. **Separacja proponującego i budowniczego (PBS)** rozdziela te zadania pomiędzy wielu walidatorów. Twórcy bloków stają się odpowiedzialni za tworzenie bloków i oferowanie ich proponentom bloków w każdym slocie. Proponent bloku nie może zobaczyć zawartości bloku; po prostu wybiera ten najbardziej opłacalny, uiszczając opłatę na rzecz twórcy bloku przed wysłaniem bloku do swoich odpowiedników. Jest to ważne uaktualnienie z kilku powodów. Po pierwsze, stwarza to możliwości zapobiegania cenzurze transakcji na poziomie protokołu. Po drugie, zapobiega to prześciganiu walidatorów działających hobbystycznie przez uczestników instytucjonalnych, którzy mogą lepiej zoptymalizować rentowność tworzenia ich bloków. Po trzecie, pomaga to w skalowaniu Ethereum poprzez umożliwienie uaktualnienia Dankshardingu. -## PBS i odporność na cenzurę {#pbs-and-censorship-resistance} +## PBS a odporność na cenzurę {#pbs-and-censorship-resistance} Podział na twórców bloków i proponentów bloków znacznie utrudnia twórcom bloków cenzurowanie transakcji. Dzieje się tak, ponieważ można dodać stosunkowo złożone kryteria włączenia, które zapewniają, że przed zaproponowaniem bloku nie doszło do cenzury. Ponieważ proponent bloku jest podmiotem odrębnym od twórcy bloku, może on przyjąć rolę obrońcy przed cenzurowaniem twórców bloków. Na przykład można wprowadzić listy włączenia, aby w przypadku, gdy walidatory wiedzą o transakcjach, ale nie widzą ich zawartych w blokach, mogli narzucić je jako obowiązkowe w następnym bloku. Lista włączenia jest generowana z lokalnego mempoolu proponenta bloku (lista transakcji, o których wie) i wysyłana do jego odpowiedników tuż przed zaproponowaniem bloku. Jeśli brakuje którejkolwiek z transakcji z listy włączenia, proponent może albo odrzucić blok i dodać brakujące transakcje przed jego zaproponowaniem, albo zaproponować go i pozwolić, aby został odrzucony przez inne walidatory, gdy go otrzymają. Istnieje również potencjalnie bardziej wydajna wersja tego pomysłu, która zakłada, że twórcy muszą w pełni wykorzystać dostępną przestrzeń bloku, a jeśli tego nie zrobią, transakcje są dodawane z listy włączenia proponenta. Jest to nadal obszar aktywnych badań, a optymalna konfiguracja list włączenia nie została jeszcze ustalona. -[ Zaszyfrowane mempoole](https://www.youtube.com/watch?v=fHDjgFcha0M&list=PLpktWkixc1gUqkyc1-iE6TT0RWQTBJELe&index=3) mogą również uniemożliwić twórcom i proponentom ustalenie, które transakcje są zawarte w bloku, dopóki blok nie zostanie już rozpowszechniony. +[Zaszyfrowane mempoole](https://www.youtube.com/watch?v=fHDjgFcha0M&list=PLpktWkixc1gUqkyc1-iE6TT0RWQTBJELe&index=3) mogłyby również uniemożliwić budowniczym i proponującym dowiedzenie się, jakie transakcje umieszczają w bloku, dopóki blok nie zostanie już rozpowszechniony. Potężne organizacje mogą naciskać na walidatorów, aby cenzurowali transakcje z określonych adresów lub na nie. Walidatory stosują się do tej presji, wykrywając adresy z czarnej listy w swojej puli transakcji i pomijając je w proponowanych przez siebie blokach. Po PBS nie będzie to już możliwe, ponieważ osoby proponujące bloki nie będą wiedziały, które transakcje rozpowszechniają w swoich blokach. Dla niektórych osób lub aplikacji ważne może być przestrzeganie zasad cenzury, na przykład gdy jest to prawo obowiązujące w ich regionie. W takich przypadkach zgodność odbywa się na poziomie aplikacji, podczas gdy protokół pozostaje wolny od uprawnień i cenzury. - ## PBS i MEV {#pbs-and-mev} -** Maksymalna wartość możliwa do wydobycia (MEV)** odnosi się do walidatorów maksymalizujących swoją rentowność poprzez korzystne sortowanie transakcji. Typowe przykłady obejmują arbitraż zamian na zdecentralizowanych giełdach (np. wyprzedzenie dużej sprzedaży lub zakupu) lub identyfikowanie okazji do upłynnienia pozycji DeFi. Maksymalizacja MEV wymaga zaawansowanej wiedzy technicznej i niestandardowego oprogramowania dołączonego do zwykłych walidatorów, co znacznie zwiększa prawdopodobieństwo, że operatorzy instytucjonalni osiągną lepsze wyniki niż pojedyncze osoby i walidatory hobbystyczne przy ekstrakcji MEV. Oznacza to, że zwroty ze stakingu będą prawdopodobnie większe w przypadku scentralizowanych operatorów, tworząc siłę centralizującą, która zniechęca do domowego stakingu. +**Maksymalna wartość ekstrakcji (MEV)** odnosi się do sytuacji, gdy walidatorzy maksymalizują swoją rentowność poprzez korzystne porządkowanie transakcji. Typowe przykłady obejmują arbitraż zamian na zdecentralizowanych giełdach (np. wyprzedzanie dużej transakcji sprzedaży lub kupna) lub wyszukiwanie okazji do likwidacji pozycji DeFi. Maksymalizacja MEV wymaga zaawansowanej wiedzy technicznej i niestandardowego oprogramowania dołączonego do zwykłych walidatorów, co znacznie zwiększa prawdopodobieństwo, że operatorzy instytucjonalni osiągną lepsze wyniki niż pojedyncze osoby i walidatory hobbystyczne przy ekstrakcji MEV. Oznacza to, że zwroty ze stakingu będą prawdopodobnie większe w przypadku scentralizowanych operatorów, tworząc siłę centralizującą, która zniechęca do domowego stakingu. PBS rozwiązuje ten problem poprzez rekonfigurację ekonomii MEV. Zamiast samodzielnego wyszukiwania MEV, proponent bloku po prostu wybiera blok spośród wielu oferowanych mu przez twórców bloków. Twórcy bloków mogli dokonać zaawansowanej ekstrakcji MEV, ale nagroda za to trafia do proponenta bloku. Oznacza to, że nawet jeśli niewielka pula wyspecjalizowanych twórców bloków zdominuje ekstrakcję MEV, nagroda za to może trafić do dowolnego walidatora w sieci, w tym do indywidualnych stakerów domowych. - + Poszczególne jednostki mogą być zachęcane do stakowania w pulach, a nie samodzielnie, ze względu na zwiększone nagrody oferowane przez wyrafinowane strategie MEV. Oddzielenie budowania bloku od jego proponowania oznacza, że wydobyta MEV zostanie rozłożona na większą liczbę walidatorów zamiast centralizacji z najbardziej efektywnym poszukiwaczem MEV. Jednocześnie zezwolenie na istnienie wyspecjalizowanych twórców bloków zdejmuje ciężar tworzenia bloków z jednostek, a także uniemożliwia jednostkom kradzież MEV dla siebie, jednocześnie maksymalizując liczbę indywidualnych, niezależnych walidatorów, które mogą sprawdzić, czy bloki są uczciwe. Ważną koncepcją jest „asymetria udowadniający-weryfikujący”, która odnosi się do idei, że scentralizowana produkcja bloków jest słuszna, o ile istnieje solidna i maksymalnie zdecentralizowana sieć walidatorów zdolnych do udowodnienia, że bloki są uczciwe. Decentralizacja jest środkiem, a nie celem końcowym — chcemy uczciwych bloków. ## PBS i Danksharding {#pbs-and-danksharding} -Danksharding to sposób, w jaki Ethereum będzie skalować się do >100 000 transakcji na sekundę i minimalizować opłaty dla użytkowników pakietów zbiorczych. Opiera się on na PBS, ponieważ zwiększa obciążenie twórców bloków, którzy będą musieli obliczyć dowody dla maksymalnie 64 MB danych pakietu zbiorczego w czasie krótszym niż 1 sekunda. Prawdopodobnie będzie to wymagało wyspecjalizowanych twórców, którzy mogą poświęcić dość znaczny sprzęt do tego zadania. Jednak w obecnej sytuacji budowanie bloków może stać się coraz bardziej scentralizowane wokół bardziej wyrafinowanych i potężnych operatorów ze względu na ekstrakcję MEV. Separacja proponujący-budujący jest sposobem na uwzględnienie tej rzeczywistości i zapobieganie wywieraniu przez nią scentralizowanej siły na walidację bloków (ważną część) lub dystrybucję nagród za stakowanie. Wielką korzyścią uboczną jest to, że wyspecjalizowani twórcy bloków są również chętni i zdolni do obliczania niezbędnych dowodów danych dla Dankshardingu. +Danksharding to sposób, w jaki Ethereum będzie się skalować do >100 000 transakcji na sekundę i minimalizować opłaty dla użytkowników pakietów zbiorczych. Opiera się on na PBS, ponieważ zwiększa obciążenie twórców bloków, którzy będą musieli obliczyć dowody dla maksymalnie 64 MB danych pakietu zbiorczego w czasie krótszym niż 1 sekunda. Prawdopodobnie będzie to wymagało wyspecjalizowanych twórców, którzy mogą poświęcić dość znaczny sprzęt do tego zadania. Jednak w obecnej sytuacji budowanie bloków może stać się coraz bardziej scentralizowane wokół bardziej wyrafinowanych i potężnych operatorów ze względu na ekstrakcję MEV. Separacja proponujący-budujący jest sposobem na uwzględnienie tej rzeczywistości i zapobieganie wywieraniu przez nią scentralizowanej siły na walidację bloków (ważną część) lub dystrybucję nagród za stakowanie. Wielką korzyścią uboczną jest to, że wyspecjalizowani twórcy bloków są również chętni i zdolni do obliczania niezbędnych dowodów danych dla Dankshardingu. ## Aktualny postęp {#current-progress} @@ -45,7 +44,7 @@ PBS znajduje się na zaawansowanym etapie badań, ale nadal istnieje kilka ważn ## Dalsza lektura {#further-reading} -- [Stan badań: odporność na cenzurę w PBS](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) -- [Struktury rynku opłat przyjazne dla PBS](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) -- [PBS i odporność na cenzurę](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Secondary-auctions) -- [Listy włączenia](https://notes.ethereum.org/@fradamt/H1ZqdtrBF) +- [Stan badań: odporność na cenzurę w ramach PBS](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) +- [Projekty rynku opłat przyjazne dla PBS](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) +- [PBS a odporność na cenzurę](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Secondary-auctions) +- [Listy włączeń](https://notes.ethereum.org/@fradamt/H1ZqdtrBF) diff --git a/public/content/translations/pl/roadmap/pectra/7702/index.md b/public/content/translations/pl/roadmap/pectra/7702/index.md new file mode 100644 index 00000000000..5c830d258c4 --- /dev/null +++ b/public/content/translations/pl/roadmap/pectra/7702/index.md @@ -0,0 +1,149 @@ +--- +title: Przewodnik po aktualizacji Pectra 7702 +description: "Dowiedz się więcej o aktualizacji Pectra 7702" +lang: pl +--- + +# Pectra 7702 + +## Streszczenie {#abstract} + +EIP 7702 definiuje mechanizm dodawania kodu do konta zewnętrznego. Ta propozycja pozwala na wprowadzenie krótkoterminowych ulepszeń funkcjonalności dla kont Ethereum (EOA), co zwiększy użyteczność aplikacji. Można to zrobić, ustawiając wskaźnik do już wdrożonego kodu przy użyciu nowego typu transakcji: 4. + +Ten nowy typ transakcji wprowadza listę autoryzacji. Każda krotka autoryzacji na liście jest zdefiniowana jako + +``` +[ chain_id, address, nonce, y_parity, r, s ] +``` + +**adres** to delegacja (już wdrożony kod bajtowy, który będzie używany przez EOA) +**chain_id** blokuje autoryzację do określonego łańcucha (lub 0 dla wszystkich łańcuchów) +**nonce** blokuje autoryzację do określonego konta (nonce) +(**y_parity, r, s**) to sygnatura krotki autoryzacji, zdefiniowana jako keccak(0x05 || rlp ([chain_id ,adres, nonce])) przez klucz prywatny EOA, do którego odnosi się autoryzacja (zwany również autoryzacją) + +Delegację można zresetować, delegując ją na adres zerowy. + +Klucz prywatny EOA zachowuje pełną kontrolę nad kontem po delegowaniu. Na przykład delegowanie do konta Sejf nie sprawia, że ​​konto staje się kontem multisig, ponieważ nadal istnieje jeden klucz, który może ominąć wszelkie zasady podpisywania. W przyszłości programiści powinni projektować swoje rozwiązania, zakładając, że każdy uczestnik systemu może być inteligentną umową. Twórcy inteligentnych kontraktów nie mogą już zakładać, że `tx.origin` odnosi się do EOA. + +## Najlepsze praktyki {#best-practices} + +**Abstrakcja konta**: Umowa delegacji powinna być zgodna ze standardami szerszej abstrakcji konta (AA) Ethereum, aby zapewnić maksymalną kompatybilność. W szczególności powinien być zgodny lub kompatybilny ze standardem ERC-4337. + +**Konstrukcja odporna na cenzurę i brak konieczności uzyskiwania zezwoleń**: Ethereum ceni sobie udział bez konieczności uzyskiwania zezwoleń. Umowa delegacyjna NIE MOŻE być zakodowana na stałe ani opierać się na pojedynczym „zaufanym” przekaźniku lub usłudze. Jeśli przekaźnik przejdzie w tryb offline, konto zostanie zablokowane. Funkcje takie jak przetwarzanie wsadowe (np. zatwierdzenie+transferFrom) mogą być używane przez sam EOA bez pośrednika. Deweloperzy aplikacji chcący korzystać z zaawansowanych funkcji włączonych w standardzie 7702 (pobieranie gazu, wypłaty z zachowaniem prywatności) będą potrzebować przekaźnika. Chociaż istnieją różne architektury przekaźników, naszym zaleceniem jest użycie [bundlerów 4337](https://www.erc4337.io/bundlers) wskazujących co najmniej [punkt wejścia 0.8](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0), ponieważ: + +- Zapewniają standardowe interfejsy do przekazywania +- Zawiera wbudowane systemy płatności +- Zapewnij kompatybilność w przyszłości +- Możliwość wspierania oporu wobec cenzury poprzez [publiczną pulę pamięci](https://notes.ethereum.org/@yoav/unified-erc-4337-mempool) +- Można wymagać, aby funkcja init była wywoływana wyłącznie z [EntryPoint](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) + +Innymi słowy, każdy powinien móc pełnić rolę sponsora/przekaźnika transakcji, pod warunkiem dostarczenia wymaganego prawidłowego podpisu lub operacji użytkownika z konta. Zapewnia to odporność na cenzurę: jeśli nie jest wymagana żadna specjalna infrastruktura, transakcje użytkownika nie mogą zostać arbitralnie zablokowane przez przekaźnik. Na przykład [zestaw narzędzi do delegowania MetaMask](https://github.com/MetaMask/delegation-framework/releases/tag/v1.3.0) współpracuje jawnie z dowolnym pakietem ERC-4337 lub systemem płatności w dowolnym łańcuchu, zamiast wymagać serwera specyficznego dla MetaMask. + +**Integracja dApps poprzez interfejsy portfela**: + +Biorąc pod uwagę, że portfele będą umieszczać na białej liście określone umowy delegacji dla protokołu EIP-7702, aplikacje zdecentralizowane (dApps) nie powinny spodziewać się bezpośredniego żądania autoryzacji 7702. Zamiast tego integracja powinna odbywać się za pośrednictwem standardowych interfejsów portfela: + +- **ERC-5792 (`wallet_sendCalls`)**: Umożliwia aplikacjom zdecentralizowanym żądanie od portfeli wykonywania zbiorczych wywołań, ułatwiając realizację takich funkcjonalności, jak grupowanie transakcji i abstrakcja gazu. + +- **ERC-6900**: Umożliwia aplikacjom zdecentralizowanym korzystanie z modułowych funkcji inteligentnych kont, takich jak klucze sesji i odzyskiwanie kont, za pośrednictwem modułów zarządzanych z poziomu portfela. + +Wykorzystując te interfejsy, zdecentralizowane aplikacje (dApps) mogą uzyskać dostęp do funkcji inteligentnych kont udostępnianych przez EIP-7702 bez konieczności bezpośredniego zarządzania delegacjami, co zapewnia kompatybilność i bezpieczeństwo w różnych implementacjach portfeli. + +> Uwaga: Nie istnieje standardowa metoda umożliwiająca aplikacjom zdecentralizowanym bezpośrednie żądanie podpisów autoryzacyjnych 7702. DApps muszą opierać się na określonych interfejsach portfela, takich jak ERC-6900, aby móc korzystać z funkcji EIP-7702. + +Więcej informacji: + +- [ERC-5792 specification](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5792.md) +- [ERC-6900 specification](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6900.md) + +**Unikanie uzależnienia od dostawcy**: Zgodnie z powyższym, dobra implementacja jest niezależna od dostawcy i interoperacyjna. Często oznacza to konieczność dostosowania się do nowych standardów dla inteligentnych kont. Na przykład [modułowe konto Alchemy](https://github.com/alchemyplatform/modular-account) wykorzystuje standard ERC-6900 dla modułowych kont inteligentnych i zostało zaprojektowane z myślą o „interoperacyjnym użytkowaniu bez konieczności uzyskiwania uprawnień”. + +**Ochrona prywatności**: Mimo że prywatność w łańcuchu bloków jest ograniczona, umowa delegująca powinna dążyć do minimalizacji ujawniania danych i możliwości ich łączenia. Można to osiągnąć, obsługując takie funkcje, jak płatności za gaz w tokenach ERC-20 (w związku z czym użytkownicy nie muszą utrzymywać publicznego salda ETH, co poprawia prywatność i UX) oraz jednorazowe klucze sesyjne (zmniejszające konieczność korzystania z pojedynczego klucza długoterminowego). Przykładowo, EIP-7702 umożliwia płacenie gazem w tokenach za pośrednictwem sponsorowanych transakcji, a dobra implementacja ułatwi integrację takich płatników bez ujawniania większej ilości informacji, niż jest to konieczne. Ponadto delegowanie niektórych zatwierdzeń poza łańcuchem (przy użyciu podpisów weryfikowanych w łańcuchu) oznacza mniej transakcji w łańcuchu z kluczem podstawowym użytkownika, co sprzyja zachowaniu prywatności. Konta wymagające użycia przekaźnika zmuszają użytkowników do ujawnienia swojego adresu IP. PublicMempools rozwiązuje ten problem. Gdy transakcja/UserOp jest propagowana przez mempool, nie można stwierdzić, czy pochodzi ona z adresu IP, z którego została wysłana, czy też została przekazana przez protokół p2p. + +**Rozszerzalność i modułowe zabezpieczenia**: Implementacje kont powinny być rozszerzalne, aby mogły ewoluować wraz z nowymi funkcjami i ulepszeniami bezpieczeństwa. Możliwość modernizacji jest wbudowana w EIP-7702 (gdyż EOA może zawsze delegować zadania do nowej umowy w przyszłości w celu modernizacji jej logiki). Oprócz możliwości aktualizacji, dobry projekt pozwala na modułowość – np. moduły wtyczek dla różnych schematów podpisów lub zasad wydatków – bez konieczności ponownego wdrażania w całości. Doskonałym przykładem jest zestaw narzędzi Account Kit firmy Alchemy, który umożliwia deweloperom instalację modułów walidacyjnych (dla różnych typów podpisów, takich jak ECDSA, BLS itp.) i moduły wykonawcze dla niestandardowej logiki. Aby osiągnąć większą elastyczność i bezpieczeństwo kont obsługujących protokół EIP-7702, deweloperzy powinni delegować zadania do kontraktu proxy, a nie bezpośrednio do konkretnej implementacji. Takie podejście pozwala na bezproblemową aktualizację i modułowość bez konieczności uzyskiwania dodatkowych autoryzacji EIP-7702 przy każdej zmianie. + +Zalety wzorca proxy: + +- **Możliwość aktualizacji**: Zaktualizuj logikę kontraktu, wskazując serwerowi proxy nowy kontrakt implementacyjny. + +- **Niestandardowa logika inicjalizacji**: Zintegruj funkcje inicjalizacji w serwerze proxy, aby bezpiecznie skonfigurować niezbędne zmienne stanu. + +Na przykład [SafeEIP7702Proxy](https://docs.safe.global/advanced/eip-7702/7702-safe) pokazuje, w jaki sposób można wykorzystać serwer proxy do bezpiecznego inicjowania i zarządzania delegacjami na kontach zgodnych ze standardem EIP-7702. + +Wady wzorca proxy: + +- **Poleganie na podmiotach zewnętrznych**: Musisz polegać na zewnętrznym zespole, aby nie zmienić umowy na niebezpieczną. + +## Zagadnienia bezpieczeństwa {#security-considerations} + +**Ochrona przed ponownym wejściem**: Dzięki wprowadzeniu delegowania EIP-7702 konto użytkownika może dynamicznie przełączać się między kontem zewnętrznym (EOA) a inteligentnym kontraktem (SC). Taka elastyczność sprawia, że ​​konto może zarówno inicjować transakcje, jak i być celem połączeń. W rezultacie w scenariuszach, w których konto wywołuje samo siebie i wykonuje połączenia zewnętrzne, `msg.sender` będzie równe `tx.origin`, co podważa pewne założenia bezpieczeństwa, które wcześniej opierały się na założeniu, że `tx.origin` zawsze stanowi EOA. + +Alternatywnie wdrożenie jawnej ochrony przed ponownym wprowadzeniem, zastosowanie z zabezpieczeniem reentracji ze wzorcami modyfikatorów `nonReentrant`. Podobnie, używanie `msg.sender == tx.origin` jako zabezpieczenia przed atakami reentrancy nie jest już niezawodną strategią. + +W przyszłości programiści powinni projektować swoje rozwiązania, zakładając, że każdy uczestnik systemu może być inteligentną umową. Alternatywnie mogliby wdrożyć jawną ochronę przed reentrancją, korzystając z zabezpieczeń reentrancji ze wzorcami modyfikatorów `nonReentrant`. Zalecamy korzystanie ze zweryfikowanego modyfikatora, np. [Reentrancy Guard pakietu Open Zeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol). Mogą również wykorzystać [zmienną pamięci przejściowej](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html). + +**Rozważania dotyczące bezpieczeństwa inicjalizacji** + +Wdrożenie kontraktów delegacyjnych EIP-7702 wiąże się ze szczególnymi wyzwaniami w zakresie bezpieczeństwa, zwłaszcza dotyczącymi procesu inicjalizacji. Krytyczna luka w zabezpieczeniach powstaje, gdy funkcja inicjalizacji (`init`) jest atomowo sprzężona z procesem delegowania. W takich przypadkach osoba będąca liderem może przechwycić podpis delegacji i wykonać funkcję `init` ze zmienionymi parametrami, potencjalnie przejmując kontrolę nad kontem. + +Ryzyko to jest szczególnie istotne w przypadku próby wykorzystania istniejących implementacji kont Smart Contract (SCA) z protokołem EIP-7702 bez modyfikowania ich mechanizmów inicjalizacji. + +**Rozwiązania łagodzące luki w zabezpieczeniach inicjalizacji** + +- Implementacja `initWithSig` + Zastąp standardową funkcję `init` funkcją `initWithSig`, która wymaga od użytkownika podpisania parametrów inicjalizacji. Takie podejście gwarantuje, że inicjalizacja może być przeprowadzona wyłącznie po uzyskaniu wyraźnej zgody użytkownika, co zmniejsza ryzyko nieautoryzowanej inicjalizacji. + +- Wykorzystaj punkt wejścia (EntryPoint) ERC-4337 + Wymagaj, aby funkcja inicjalizacji była wywoływana wyłącznie z kontraktu punktu wejścia (EntryPoint) ERC-4337. Metoda ta wykorzystuje standardowe ramy walidacji i wykonywania określone w standardzie ERC-4337, dodając dodatkową warstwę zabezpieczeń do procesu inicjalizacji. + _(See: [Safe Docs](https://docs.safe.global/advanced/eip-7702/7702-safe))_ + +Dzięki zastosowaniu tych rozwiązań deweloperzy mogą zwiększyć bezpieczeństwo kontraktów delegacji EIP-7702, chroniąc się przed potencjalnymi atakami typu frontrunning w fazie inicjalizacji. + +**Kolizje pamięci masowej** Delegowanie kodu nie czyści istniejącej pamięci masowej. Podczas migracji z jednej umowy delegacyjnej do innej, resztkowe dane z poprzedniej umowy pozostają niezmienione. Jeśli nowa umowa wykorzystuje te same sloty pamięci masowej, ale interpretuje je inaczej, może to prowadzić do niezamierzonych zachowań. Na przykład, jeśli początkowe delegowanie dotyczyło kontraktu, w którym slot pamięci masowej reprezentuje `bool`, a późniejsze delegowanie dotyczy kontraktu, w którym ten sam slot reprezentuje `uint`, niezgodność może doprowadzić do nieprzewidywalnych rezultatów. + +**Ryzyko phishingu** Dzięki wdrożeniu delegowania EIP-7702 zasoby na koncie użytkownika mogą być w całości kontrolowane przez inteligentne kontrakty. Jeśli użytkownik nieświadomie udostępni swoje konto złośliwemu kontraktowi, atakujący może łatwo przejąć kontrolę i ukraść środki. W przypadku użycia `chain_id=0` delegacja jest stosowana do wszystkich identyfikatorów łańcucha. Deleguj tylko do niezmiennego kontraktu (nigdy nie deleguj do serwera proxy) i tylko do kontraktów wdrożonych przy użyciu CREATE2 (ze standardowym kodem initcode — bez kontraktów metamorficznych), aby wdrażający nie mógł wdrożyć czegoś innego pod tym samym adresem gdzie indziej. W przeciwnym wypadku Twoja delegacja narazi Twoje konto na ryzyko we wszystkich pozostałych łańcuchach EVM. + +Gdy użytkownicy składają podpisy delegowane, umowa docelowa, której dotyczy delegacja, powinna być wyraźnie i widocznie wyświetlana, aby pomóc ograniczyć ryzyko phishingu. + +**Minimalna powierzchnia zaufania i bezpieczeństwo**: Umowa delegująca, oferując jednocześnie elastyczność, powinna zachować swoją podstawową logikę na poziomie minimalnym i możliwym do zweryfikowania. Umowa stanowi w istocie przedłużenie EOA użytkownika, więc jakakolwiek wada może mieć katastrofalne skutki. Wdrożenia powinny być zgodne z najlepszymi praktykami stosowanymi przez społeczność zajmującą się bezpieczeństwem inteligentnych kontraktów. Na przykład funkcje konstruktora lub inicjatora muszą być starannie zabezpieczone – jak podkreśla Alchemy, w przypadku użycia wzorca proxy poniżej 7702 niezabezpieczony inicjator może umożliwić atakującemu przejęcie konta. Zespoły powinny starać się, aby kod on-chain był prosty: kontrakt 7702 Ambire składa się tylko z około 200 linii kodu Solidity, co pozwala na celowe ograniczenie złożoności w celu ograniczenia liczby błędów. Należy znaleźć równowagę między bogatą w funkcje logiką a prostotą ułatwiającą audyt. + +### Znane implementacje {#known-implementations} + +Ze względu na charakter protokołu EIP 7702 zaleca się, aby portfele zachowywały ostrożność, pomagając użytkownikom delegować zadania do umowy zewnętrznej. Poniżej znajduje się zbiór znanych implementacji, które zostały poddane audytowi: + +| Adres umowy | Źródło | Audyty | +| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0x000000009B1D0aF20D8C6d0A44e162d11F9b8f00 | [Uniswap/calibur](https://github.com/Uniswap/calibur) | [audits](https://github.com/Uniswap/calibur/tree/main/audits) | +| 0x69007702764179f14F51cdce752f4f775d74E139 | [alchemyplatform/modular-account](https://github.com/alchemyplatform/modular-account) | [audits](https://github.com/alchemyplatform/modular-account/tree/develop/audits) | +| 0x5A7FC11397E9a8AD41BF10bf13F22B0a63f96f6d | [AmbireTech/ambire-common](https://github.com/AmbireTech/ambire-common/blob/feature/eip-7702/contracts/AmbireAccount7702.sol) | [audits](https://github.com/AmbireTech/ambire-common/tree/feature/eip-7702/audits) | +| 0x63c0c19a282a1b52b07dd5a65b58948a07dae32b | [MetaMask/delegation-framework](https://github.com/MetaMask/delegation-framework) | [audits](https://github.com/MetaMask/delegation-framework/tree/main/audits) | +| 0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9 | [Ethereum Foundation AA team](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/accounts/Simple7702Account.sol) | [audits](https://github.com/eth-infinitism/account-abstraction/blob/develop/audits/SpearBit%20Account%20Abstraction%20Security%20Review%20-%20Mar%202025.pdf) | +| 0x17c11FDdADac2b341F2455aFe988fec4c3ba26e3 | [Luganodes/Pectra-Batch-Contract](https://github.com/Luganodes/Pectra-Batch-Contract) | [audits](https://certificate.quantstamp.com/full/luganodes-pectra-batch-contract/23f0765f-969a-4798-9edd-188d276c4a2b/index.html) | + +## Wytyczne dotyczące portfela sprzętowego {#hardware-wallet-guidelines} + +Portfele sprzętowe nie powinny ujawniać dowolnego delegowania. W obszarze portfeli sprzętowych panuje zgoda co do korzystania z listy zaufanych kontraktów delegujących. Sugerujemy dopuszczenie znanych implementacji wymienionych powyżej i rozważenie innych w każdym przypadku indywidualnie. Ponieważ delegowanie EOA do kontraktu daje kontrolę nad wszystkimi aktywami, właściciele portfeli sprzętowych powinni zachować ostrożność przy sposobie implementacji 7702. + +### Scenariusze integracji dla aplikacji towarzyszących {#integration-scenarios-for-companion-apps} + +#### Leniwy {#lazy} + +Ponieważ EOA działa normalnie, nie ma nic do zrobienia. + +Uwaga: niektóre zasoby mogą zostać automatycznie odrzucone przez kod delegacji, np. NFT ERC 1155, a dział wsparcia powinien o tym wiedzieć. + +#### Świadomy {#aware} + +Powiadom użytkownika, że ​​delegacja jest aktywna dla EOA, sprawdzając jej kod i opcjonalnie zaproponuj usunięcie delegacji. + +#### Wspólna delegacja {#common-delegation} + +Dostawca sprzętu umieszcza znane umowy delegacyjne na białej liście i implementuje ich obsługę w oprogramowaniu towarzyszącym. Zaleca się wybranie umowy z pełnym wsparciem ERC 4337. + +Pozwolenia EOA przekazane innej osobie będą traktowane jako standardowe pozwolenia EOA. + +#### Delegacja niestandardowa {#custom-delegation} + +Dostawca sprzętu wdraża własną umowę delegacyjną i dodaje ją do list, a także wdraża jej wsparcie w oprogramowaniu towarzyszącym. Zaleca się utworzenie kontraktu z pełnym wsparciem ERC 4337. + +Pozwolenia EOA przekazane innej osobie będą traktowane jako standardowe pozwolenia EOA. diff --git a/public/content/translations/pl/roadmap/pectra/index.md b/public/content/translations/pl/roadmap/pectra/index.md new file mode 100644 index 00000000000..2597e118140 --- /dev/null +++ b/public/content/translations/pl/roadmap/pectra/index.md @@ -0,0 +1,127 @@ +--- +title: Prague-Electra (Pectra) +description: "Poznaj uaktualnienie protokołu Pectra" +lang: pl +--- + +# Pectra {#pectra} + +Uaktualnienie sieci Pectra nastąpiło po [Dencun](/roadmap/dencun/) i przyniosło zmiany zarówno w warstwie wykonawczej, jak i konsensusu sieci Ethereum. Skrócona nazwa Pectra to połączenie nazw Prague oraz Electra, które odnoszą się odpowiednio do zmian specyfikacji warstwy wykonawczej i konsensusu. Razem, zmiany te przynoszą szereg usprawnień dla użytkowników, deweloperów i walidatorów Ethereum. + +Uaktualnienie zostało pomyślnie aktywowane w sieci głównej Ethereum w epoce `364032`, dnia **7 maja 2025 roku o godzinie 10:05 (UTC)**. + + + + +Uaktualnienie Pectra to tylko jeden z etapów długoterminowych celów rozwojowych Ethereum. Dowiedz się więcej o [planie działania protokołu](/roadmap/) oraz [poprzednich uaktualnieniach](/ethereum-forks/). + + + + +## Usprawnienia wprowadzone w Pectra {#new-improvements} + +Pectra wprowadza największą liczbę [EIP-ów](https://eips.ethereum.org/) spośród wszystkich dotychczasowych uaktualnień! Zawiera wiele drobnych zmian, ale także kilka znaczących nowych funkcji. Pełna lista zmian i szczegóły techniczne znajdują się w poszczególnych EIP-ach. + +### Kod konta EOA {#7702} + +[EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) stanowi duży krok w kierunku powszechnej [abstrakcji kont](/roadmap/account-abstraction/). Dzięki tej funkcji użytkownicy mogą ustawić swój adres ([EOA](/glossary/#eoa)) tak, aby został rozszerzony o inteligentny kontakt. EIP wprowadza nowy typ transakcji ze specyficzną funkcją — pozwala właścicielowi adresu podpisać autoryzację, która ustawia jego adres tak, by naśladował wybrany inteligentny kontrakt. + +Dzięki temu EIP użytkownicy mogą zdecydować się na portfele programowalne, które umożliwiają korzystanie z nowych funkcji, takich jak grupowanie transakcji, bezgazowe transakcje oraz niestandardowy dostęp do aktywów dla alternatywnych schematów odzyskiwania. To hybrydowe podejście łączy prostotę kont EOA z programowalnością kont opartych na kontraktach. + +Więcej informacji na temat EIP-7702 znajdziesz [tutaj](/roadmap/pectra/7702/) + +### Zwiększenie maksymalnego efektywnego salda {#7251} + +Obecne efektywne saldo walidatora wynosi dokładnie 32 ETH. Jest to minimalna wymagana kwota potrzebna do uczestniczenia w konsensusie, ale jednocześnie maksymalna, jaką pojedynczy walidator może stakować. + +[EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) podnosi maksymalne możliwe efektywne saldo do 2048 ETH, co oznacza, że pojedynczy walidator może teraz stakować od 32 do 2048 ETH. Zamiast wielokrotności 32, stakerzy mogą teraz wybrać dowolną kwotę ETH do stakowania i otrzymywać nagrody za każde dodatkowe 1 ETH powyżej minimum. Na przykład, jeśli saldo walidatora wzrośnie dzięki nagrodom do 33 ETH, dodatkowy 1 ETH zostaje również uznany za część efektywnego salda i otrzymuje nagrody. + +Korzyść w postaci lepszego systemu nagród dla walidatorów to jednak tylko część tego usprawnienia. [Stakerzy](/staking/) obsługujący wiele walidatorów mogą teraz połączyć je w jednego, co umożliwia łatwiejszą obsługę i zmniejsza obciążenie sieci. Ponieważ każdy walidator w łańcuchu śledzącym przesyła podpis w każdej epoce, wymagania dotyczące przepustowości rosną wraz z większą liczbą walidatorów i podpisów do rozpropagowania. Łączenie walidatorów odciąży sieć i otworzy nowe możliwości skalowania przy zachowaniu tego samego poziomu ekonomicznego bezpieczeństwa. + +Więcej informacji na temat maksymalnego efektywnego salda (maxEB) znajdziesz [tutaj](/roadmap/pectra/maxeb/) + +### Zwiększenie przepustowości blobów {#7691} + +Bloby zapewniają [dostępność danych](/developers/docs/data-availability/#data-availability-and-layer-2-rollups) dla warstw 2. Zostały one wprowadzone w [poprzednim uaktualnieniu sieci](/roadmap/dencun/). + +Obecnie sieć celuje w średnio 3 bloby na blok z maksimum wynoszącym 6 blobów. Dzięki [EIP-7691](https://eips.ethereum.org/EIPS/eip-7691) średnia liczba blobów zostanie zwiększona do 6, z maksimum wynoszącym 9 blobów na blok, co przełoży się na zwiększoną pojemność dla pakietów zbiorczych Ethereum. Ten EIP pomaga wypełnić lukę do czasu, aż [PeerDAS](https://eips.ethereum.org/EIPS/eip-7594) umożliwi jeszcze większe liczby blobów. + +### Zwiększenie kosztu calldata {#7623} + +Przed wprowadzeniem [blobów w uaktualnieniu Dencun](/roadmap/danksharding), warstwy 2 używały [calldata](/developers/docs/data-availability/blockchain-data-storage-strategies/#calldata) do przechowywania swoich danych w Ethereum. Zarówno bloby, jak i calldata wpływają na wykorzystanie przepustowości Ethereum. Choć większość bloków używa tylko minimalnej ilości calldata, bloki z dużą ilością danych, które zawierają również wiele blobów, mogą być szkodliwe dla sieci p2p Ethereum. + +Aby temu zaradzić, [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) zwiększa koszty calldata, ale tylko dla transakcji zawierających duże ilości danych. Dzięki temu ograniczany jest najgorszy możliwy rozmiar bloku, warstwy 2 są zachęcane do korzystania wyłącznie z blobów, a ponad 99% transakcji pozostaje bez zmian. + +### Wyjścia wyzwalane z warstwy wykonawczej {#7002} + +Obecnie wyjście walidatora i [wypłata zestakowanego ETH](/staking/withdrawals/) to operacja wykonywana w warstwie konsensusu, która wymaga aktywnego klucza walidatora, czyli tego samego klucza BLS, którego walidator używa do wykonywania obowiązków, takich jak poświadczanie. Poświadczenia wypłaty to osobny, zimny klucz, który otrzymuje wycofaną stawkę, ale nie może zainicjować wyjścia. Jedynym sposobem stakerów na wyjście jest wysłanie specjalnej wiadomości do sieci łańcucha śledzącego podpisanej aktywnym kluczem walidatora. To ograniczenie jest problematyczne w sytuacjach, gdy poświadczenia wypłaty i klucz walidatora są w posiadaniu różnych podmiotów lub gdy klucz walidatora zostanie zgubiony. + +[EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) wprowadza nowy kontrakt, który pozwala wyzwolić wyjście przy użyciu poświadczeń wypłaty z warstwy wykonawczej. Stakerzy będą mogli wyjść swoim walidatorem wywołując funkcję w tym specjalnym kontrakcie, bez potrzeby posiadania klucza walidatora ani bezpośredniego dostępu do łańcucha śledzącego. Co ważne, umożliwienie wypłat walidatorów w łańcuchu pozwala na stosowanie protokołów stakingowych przy zmniejszonym poziomie zaufania do operatorów węzłów. + +### Depozyty walidatorów w łańcuchu {#6110} + +Obecnie depozyty walidatorów są przetwarzane przez [eth1data poll](https://eth2book.info/capella/part2/deposits-withdrawals/deposit-processing/), czyli funkcję w łańcuchu śledzącym, która pobiera dane z warstwy wykonawczej. To swego rodzaju dług techniczny z czasów sprzed Połączenia, kiedy łańcuch śledzący był osobną siecią i musiał brać pod uwagę reorganizacje proof-of-work. + +[EIP-6110](https://eips.ethereum.org/EIPS/eip-6110) wprowadza nowy sposób przekazywania depozytów z warstwy wykonawczej do warstwy konsensusu, co umożliwia natychmiastowe przetwarzanie i zmniejsza złożoność implementacyjną. To bezpieczniejszy sposób obsługi depozytów, natywny po Połączeniu Ethereum. Pomaga to również zabezpieczyć protokół na przyszłość, ponieważ nie wymaga on historycznych depozytów do uruchomienia węzła, co jest istotne w kontekście wygasania historii. + +### Prekompilacja dla BLS12-381 {#2537} + +Prekompilacje to specjalny zestaw inteligentnych kontraktów wbudowanych bezpośrednio w maszynę wirtualną Ethereum ([EVM](/developers/docs/evm/)). W przeciwieństwie do zwykłych kontraktów, prekompilacje nie są wdrażane przez użytkowników, lecz stanowią część implementacji klienta, napisaną w jego natywnym języku (np. Go, Java, itp., a nie Solidity). Prekompilacje służą do szeroko stosowanych i znormalizowanych funkcji, takich jak operacje kryptograficzne. Deweloperzy inteligentnych kontraktów mogą wywoływać prekompilacje tak samo, jak zwykłe kontrakty, zyskując przy tym większą wydajność i bezpieczeństwo. + +[EIP-2547](https://eips.ethereum.org/EIPS/eip-2537) dodaje nowe prekompilacje dla operacji krzywych w [BLS12-381](https://hackmd.io/@benjaminion/bls12-381). Ta krzywa eliptyczna stała się powszechnie stosowana w ekosystemach kryptowalut dzięki swoim praktycznym właściwościom. Dokładniej rzecz biorąc, została ona przyjęta przez warstwę konsensusu Ethereum, gdzie jest używana przez walidatorów. + +Nowa prekompilacja umożliwia każdemu deweloperowi łatwe, wydajne i bezpieczne wykonywanie operacji kryptograficznych przy użyciu tej krzywej, np. weryfikację podpisów. Aplikacje w łańcuchu, które polegają na tej krzywej, mogą stać się bardziej wydajne pod względem zużycia gazu i bezpieczniejsze, opierając się na prekompilacji zamiast na niestandardowych kontraktach. Dotyczy to głównie aplikacji, które chcą analizować walidatory wewnątrz EVM, np. pule stakingowe, [restaking](/restaking/), lekkie klienty, mosty, ale także rozwiązania o wiedzy zerowej. + +### Obsługa historycznych hashy bloków ze stanu {#2935} + +EVM zapewnia obecnie kod operacyjny `BLOCKHASH`, który pozwala deweloperom kontraktów pozyskać hash bloku bezpośrednio w warstwie wykonawczej. Jednak dostępny jest tylko zakres ostatnich 256 bloków, co w przyszłości może stać się problematyczne dla bezstanowych klientów. + +[EIP-2935](https://eips.ethereum.org/EIPS/eip-2935) tworzy nowy kontrakt systemowy, który może obsługiwać ostatnie 8192 hashy bloków jako sloty pamięci. Pomaga to zabezpieczyć protokół na przyszłość pod kątem bezstanowego wykonywania i zwiększa jego wydajność w przypadku przyjęcia drzew trie Verkle. Co więcej, pakiety zbiorcze mogą od razu skorzystać z tej zmiany, ponieważ mogą bezpośrednio wysyłać zapytania do kontraktu z dłuższym oknem historycznym. + +### Przeniesienie indeksu komitetu poza poświadczenie {#7549} + +Konsensus łańcucha śledzącego opiera się na głosach walidatorów oddawanych na najnowszy blok i sfinalizowaną epokę. Poświadczenie składa się z 3 elementów, z których 2 to głosy, a trzeci to wartość indeksu komitetu. + +[EIP-7549](https://eips.ethereum.org/EIPS/eip-7549) przenosi ten indeks poza podpisaną wiadomość poświadczającą, co ułatwia weryfikację i agregację głosów konsensusu. Umożliwi to większą wydajność każdego klienta konsensusu i może przynieść znaczną poprawę wydajności obwodów o wiedzy zerowej, które dowodzą konsensus Ethereum. + +### Dodanie harmonogramu blobów do plików konfiguracyjnych warstwy wykonawczej {#7840} + +[EIP-7840](https://eips.ethereum.org/EIPS/eip-7840) to prosta zmiana polegająca na dodaniu nowego pola do konfiguracji klientów warstwy wykonawczej. Pole to definiuje liczbę bloków, umożliwiając dynamiczne ustawianie docelowej i maksymalnej liczby blobów na blok, a także dostosowywanie opłat za bloby. Dzięki bezpośrednio określonej konfiguracji klienty mogą uniknąć złożoności związanej z wymianą tych informacji przez Engine API. + + + + +Aby dowiedzieć się, jak Pectra wpływa konkretnie na użytkowników Ethereum, deweloperów czy walidatorów, zajrzyj do Pectra FAQ. + + + + +## Czy to uaktualnienie wpływa na wszystkie węzły i walidatory Ethereum? {#client-impact} + +Tak, uaktualnienie Pectra wymaga aktualizacji zarówno w [klientach wykonawczych, jak i klientach konsensusu](/developers/docs/nodes-and-clients/). Wszystkie główne klienty Ethereum wydadzą wersję obsługujące ten hard fork oznaczone jako priorytetowe. Aby zachować synchronizację z siecią Ethereum po uaktualnieniu, operatorzy węzłów muszą się upewnić, że korzystają z obsługiwanej wersji klienta. Należy pamiętać, że informacje o wersjach klienta zależą od czasu, a użytkownicy powinni zapoznać się z najnowszymi aktualizacjami, aby uzyskać najbardziej aktualne szczegóły. + +## Jak można przekonwertować ETH po hard forku? {#scam-alert} + +- **Nic nie musisz robić ze swoim ETH**: po uaktualnieniu Pectra nie ma żadnej potrzeby konwersji lub ulepszenia ETH. Salda Twoich kont pozostaną takie same, a ETH, które obecnie posiadasz, pozostanie dostępne w tej samej formie po hard forku. +- **Uważaj na oszustwa!**  **Każdy, kto mówi Ci, aby „ulepszyć” ETH, próbuje cię oszukać.** Nie musisz nic robić w związku z tym uaktualnieniem. Twoje aktywa pozostaną całkowicie nienaruszone. Pamiętaj, że bycie na bieżąco jest najlepszą formą obrony przed oszustwami. + +[Więcej na temat rozpoznawania i unikania oszustw](/security/) + +## Jesteś raczej wzrokowcem? Dla wzrokowców {#visual-learner} + + + +_Co wprowadza uaktualnienie Pectra? — Christine Kim_ + + + +_Uaktualnienie Pectra: co muszą wiedzieć stakerzy — Blockdaemon_ + +## Dalsza lektura {#further-reading} + +- [Plan działania Ethereum](/roadmap/) +- [Pectra FAQ](https://epf.wiki/#/wiki/pectra-faq) +- [Strona informacyjna pectra.wtf](https://pectra.wtf) +- [Jak Pectra poprawia doświadczenia użytkowników](https://www.kiln.fi/post/next-ethereum-upgrade-how-pectra-will-enhance-the-staking-experience) +- [Strona informacyjna EIP7702](https://eip7702.io/) +- [Sieci deweloperskie Pectra](https://github.com/ethereum/pm/blob/master/Pectra/pectra-pm.md) diff --git a/public/content/translations/pl/roadmap/pectra/maxeb/index.md b/public/content/translations/pl/roadmap/pectra/maxeb/index.md new file mode 100644 index 00000000000..82e1221942c --- /dev/null +++ b/public/content/translations/pl/roadmap/pectra/maxeb/index.md @@ -0,0 +1,204 @@ +--- +title: Pectra MaxEB +description: "Dowiedz się więcej o MaxEB w wydaniu Pectra" +lang: pl +--- + +# MaxEB {#maxeb} + +_tl;dr:_ Hard fork Pectra pozwala walidatorom Ethereum na zdecydowanie się na wyższe maksymalne efektywne saldo i kapitalizację poprzez konwersję poświadczeń wypłat z **Typu 1** na **Typ 2**. Oficjalnym narzędziem do tego jest Launchpad. Ta operacja jest nieodwracalna. + +## Przegląd {#overview} + +### Kogo to dotyczy? {#who-is-affected} + +Każdy, kto uruchamia walidatora – to prawdopodobnie ktoś, kto zna indeks (np. [Walidator #12345](https://beaconcha.in/validator/12345)) walidatora, którego kontroluje. Jeśli używasz protokołu do uruchomienia walidatora (np. Lido CSM lub Rocket Pool), musisz sprawdzić u nich, czy i kiedy będą obsługiwać maxEB. + +Jeśli stakujesz za pomocą tokenu płynnego stakowania (np. rETH lub stETH), żadne działanie nie jest wymagane ani zalecane. + +### Czym jest "maxEB"? {#what-is-maxeb} + +maxEB = MAXymalne Efektywne Saldo walidatora. Do czasu hard forka Pectra każdy walidator zarabia na maksymalnie 32 ETH. Po Pectra walidatorzy mają możliwość zarabiania na dowolnym saldzie między 32 a 2048 ETH, w przyrostach co 1 ETH, decydując się na tę zmianę. + +### Jak walidator może się na to zdecydować? {#how-does-a-validator-opt-in} + +Walidator decyduje się na zmianę maxEB poprzez konwersję poświadczeń wypłat z **Typu 1** na **Typ 2**. Można to zrobić na [Launchpad (Akcje walidatora)](https://launchpad.ethereum.org/validator-actions) po uruchomieniu hard forka Pectra. Podobnie jak w przypadku **Typu 0** → **Typu 1**, konwersja z **Typu 1** → **Typu 2** jest procesem nieodwracalnym. + +### Czym są poświadczenia wypłaty? {#whats-a-withdrawal-credential} + +Gdy uruchamiasz walidatora, masz zestaw poświadczeń wypłaty. Można je znaleźć w pliku json z danymi depozytu lub można je zobaczyć na stronie beaconcha.in swojego walidatora w [zakładce depozytów](https://beaconcha.in/validator/12345#deposits). + +1. **Poświadczenia wypłat typu 0**: Jeśli poświadczenia wypłat Twojego walidatora zaczynają się od `0x00...`, dokonałeś/aś depozytu przed hard forkiem Shapella i nie masz jeszcze ustawionego adresu wypłat. + +![Poświadczenie wypłaty typu 0](./0x00-wd.png) + +2. **Poświadczenia wypłat typu 1**: Jeśli poświadczenia wypłat Twojego walidatora zaczynają się od `0x01...`, dokonałeś/aś depozytu po hard forku Shapella lub już dokonałeś/aś konwersji swoich poświadczeń **typu 0** na poświadczenia **typu 1**. + +![Poświadczenie wypłaty typu 1](./0x01-wd.png) + +3. **Poświadczenia wypłat typu 2**: Ten nowy typ poświadczeń wypłat będzie zaczynać się od `0x02...` i zostanie włączony po Pectra. Walidatorzy z poświadczeniami wypłat **typu 2** są czasami nazywani "**walidatorami kapitalizującymi**" + +| **Dozwolone** | **Niedozwolone** | +| --------------- | ---------------- | +| ✅ Typ 0 → Typ 1 | ❌ Typ 0 → Typ 2 | +| ✅ Typ 1 → Typ 2 | ❌ Typ 1 → Typ 0 | +| | ❌ Typ 2 → Typ 1 | +| | ❌ Typ 2 → Typ 0 | + +### Zagrożenia {#risks} + +MaxEB umożliwia walidatorowi wysłanie całego swojego salda do innego walidatora. Użytkownicy przesyłający żądanie konsolidacji powinni zweryfikować źródło i zawartość transakcji, którą podpisują. Oficjalnym narzędziem do korzystania z funkcji maxEB jest Launchpad. Jeśli zdecydujesz się na użycie narzędzia innej firmy, powinieneś/aś zweryfikować, czy: + +- Klucz publiczny i adres wypłat walidatora źródłowego odpowiadają walidatorowi, którego kontrolują +- Klucz publiczny walidatora docelowego jest prawidłowy i należy do nich +- Żądanie jest konwersją, a nie konsolidacją, jeśli nie zamierzają wysyłać środków do innego walidatora +- Transakcja jest podpisywana przez prawidłowy adres wypłat + +**Zdecydowanie zalecamy** omówienie każdego narzędzia innej firmy, którego planujesz użyć, ze [społecznością EthStaker](https://ethstaker.org/about). To pomocne miejsce do sprawdzenia poprawności swojego podejścia i uniknięcia błędów. Jeśli użyjesz złośliwego lub źle skonfigurowanego narzędzia, **całe saldo Twojego walidatora może zostać wysłane do walidatora, którego nie kontrolujesz** — bez możliwości odzyskania go. + +## Szczegóły techniczne {#technical-details} + +### Przepływ {#the-flow} + +Będą dwa zastosowania operacji `ConsolidationRequest`: + +1. Konwersja istniejącego walidatora z walidatora **Typu 1** na **Typ 2** +2. Konsolidacja innych walidatorów w istniejącym walidatorze **Typu 2** + +W przypadku konwersji walidatora **Typu 1** na walidatora **Typu 2** zarówno _źródłem_, jak i _celem_ będzie walidator, którego konwertujesz. Operacja będzie kosztować gaz i zostanie umieszczona w kolejce za innymi żądaniami konsolidacji. Ta kolejka jest **oddzielna** od kolejki depozytów, nie wpływają na nią nowe depozyty walidatorów i można ją zobaczyć na [pectrified.com](https://pectrified.com/). + +Aby skonsolidować walidatorów, musisz mieć _walidatora docelowego_, który posiada poświadczenie wypłaty **Typu 2**. Jest to miejsce docelowe wszelkich konsolidowanych sald walidatorów oraz zachowywany indeks. + +### Wymagania dotyczące konwersji na Typ 2 {#requirements-for-converting-to-type-2} + +Będzie to wymagane dla pierwszego walidatora, którego konwertujesz na **Typ 2**. Indeks tego walidatora jest zachowany i aktywny. W przypadku konwersji, _walidator źródłowy_ == _walidator docelowy_. + +Walidator musi... + +- być aktywny +- posiadać poświadczenia wypłat **Typu 1** +- nie być w stanie wyjścia (ani po slashingu) +- nie mieć oczekujących, ręcznie uruchomionych wypłat (nie dotyczy operacji sweep) + +![ilustracja konwersji](./conversion.png) + +### Wymagania dotyczące konsolidacji {#requirements-for-consolidating} + +Jest to _ta sama operacja_ co konwersja, ale ma miejsce, gdy _walidator źródłowy_ jest inny niż _walidator docelowy_. Indeks walidatora docelowego jest zachowany i akceptuje saldo od walidatora źródłowego. Indeks walidatora źródłowego jest przełączany w stan `EXITED`. + +W tym przypadku walidator źródłowy ma wszystkie te same wymagania co powyżej, a dodatkowo: + +- był aktywny przez co najmniej ~27,3 godziny (jeden `SHARD_COMMITTEE_PERIOD`) + +Walidator docelowy musi + +- posiadać poświadczenia wypłat **Typu 2** +- nie być w stanie wyjścia. + +![ilustracja konsolidacji](./consolidation.png) + +### Żądanie konsolidacji {#the-consolidation-request} + +Żądanie konsolidacji zostanie podpisane przez adres wypłat powiązany z walidatorem źródłowym i będzie zawierać: + +1. Adres walidatora źródłowego (np. `0x15F4B914A0cCd14333D850ff311d6DafbFbAa32b`) +2. Klucz publiczny walidatora źródłowego (np. `0xa1d1ad0714035353258038e964ae9675dc0252ee22cea896825c01458e1807bfad2f9969338798548d9858a571f7425c`) +3. Klucz publiczny tego walidatora docelowego + +W przypadku konwersji pozycje 2 i 3 będą takie same. Tę operację można wykonać w [Launchpadzie](https://launchpad.ethereum.org/). + +### Wymagania dotyczące podpisywania {#signing-requirements} + +Aby przesłać `ConsolidationRequest`, **adres wypłat walidatora źródłowego** musi podpisać żądanie. Dowodzi to kontroli nad środkami walidatora. + +### Co jest podpisywane? {#what-is-signed} + +Używany jest oddzielony domeną [główny element podpisu (signing root)](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#compute_signing_root) obiektu `ConsolidationRequest`. + +- **Domena:** `DOMAIN_CONSOLIDATION_REQUEST` +- **Pola głównego elementu podpisu:** + - `source_pubkey`: `BLSPubkey` + - `target_pubkey`: `BLSPubkey` + - `source_address`: `ExecutionAddress` + +Wynikowy **podpis BLS** jest przesyłany wraz z żądaniem. + +Uwaga: Podpis jest składany przez adres wypłat, a nie przez klucz walidatora. + +### Wypłaty częściowe {#partial-withdrawals} + +Walidatorzy z poświadczeniami **Typu 1** otrzymują automatyczne, bezgazowe operacje sweep nadwyżki salda (wszystko powyżej 32 ETH) na swój adres wypłat. Ponieważ **Typ 2** pozwala walidatorowi na kapitalizację salda w przyrostach co 1 ETH, nie będzie automatycznie wykonywał operacji sweep salda, dopóki nie osiągnie ono 2048 ETH. Wypłaty częściowe na walidatorach **Typu 2** muszą być uruchamiane ręcznie i będą kosztować gaz. + +## Narzędzia do konsolidacji {#consolidation-tooling} + +Dostępnych jest kilka narzędzi do zarządzania konsolidacjami. Oficjalnym narzędziem, stworzonym przez Fundację Ethereum, jest [Launchpad](https://launchpad.ethereum.org/en/validator-actions). Istnieją również narzędzia firm trzecich, stworzone przez podmioty ze społeczności stakingowej, które mogą oferować funkcje niedostępne w Launchpadzie. Chociaż przedstawione tutaj narzędzia nie są audytowane ani wspierane przez Fundację Ethereum, poniżej znajdują się narzędzia open-source stworzone przez znanych członków społeczności. + +| Narzędzie | Strona internetowa | Otwarte źródło | Twórca | Skontrolowany | Interfejs | Warte uwagi funkcje | +| ---------------------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------- | +| Pectra Staking Manager | pectrastaking.com | Tak, Apache 2.0 | [Pier Two](https://piertwo.com/) | Nie | Interfejs sieciowy | Wallet Connect, działa z SAFE | +| Narzędzie CLI Pectra Validator Ops | [GitHub](https://github.com/Luganodes/Pectra-Batch-Contract) | Tak, MIT | [Luganodes](https://www.luganodes.com/) | Tak, Quantstamp [Maj 2025](https://certificate.quantstamp.com/full/luganodes-pectra-batch-contract/23f0765f-969a-4798-9edd-188d276c4a2b/index.html) | Wiersz poleceń | Przetwarzanie wsadowe, dla wielu walidatorów jednocześnie | +| Ethereal | [GitHub](https://github.com/wealdtech/ethereal) | Tak, Apache 2.0 | [Jim McDonald](https://www.attestant.io/team/) | Nie | Wiersz poleceń | Pełny zestaw funkcji do zarządzania walidatorami i węzłami | +| Siren | [GitHub](https://github.com/sigp/siren) | Tak, Apache 2.0 | [Sigma Prime](https://sigmaprime.io/) | Nie | Częściowo wiersz poleceń, ale głównie interfejs sieciowy | Działa tylko, jeśli używasz klienta konsensusu Lighthouse | +| Consolideth.app | https://consolideth.app/ [GitHub](https://github.com/Stakely/consolideth) | Tak, licencje MIT | [Stakely](https://stakely.io/) | Nie | Interfejs sieciowy, hostowany przez Stakely i gotowy do darmowego samodzielnego hostowania | Obsługuje główne połączenia portfeli, w tym Safe z WalletConnect | + +## FAQ {#faq} + +### Czy przystąpienie zmienia moje szczęście w propozycjach lub nagrody? {#change-luck-or-rewards} + +Nie. Przystąpienie nie zmniejsza szansy na propozycję – Twoje obowiązki i wybór propozycji pozostają takie same. Na przykład, jeśli masz dwa walidatory 32 ETH w porównaniu z jednym walidatorem 64 ETH, będziesz mieć takie same całkowite szanse na wybór do zaproponowania bloku i zdobycia nagród. + +### Czy przystąpienie zmienia moje ryzyko slashingu? {#change-slashing-risk} + +Dla mniejszych lub nieprofesjonalnych operatorów krótka odpowiedź brzmi: nie. Dłuższa odpowiedź jest taka, że dla profesjonalnych operatorów uruchamiających wiele walidatorów na węzeł z szybkim systemem ostrzegania, konsolidacja w mniejszą liczbę walidatorów może zmniejszyć ich zdolność do reagowania na slashing i zapobiegania zdarzeniom kaskadowym. Początkowa _kara_ za slashing dla wszystkich walidatorów została drastycznie zmniejszona z 1 ETH (na 32 ETH) do 0,0078125 ETH (na 32 ETH), aby zrównoważyć to ryzyko. + +### Czy muszę wyjść z walidatora, aby dokonać konwersji? {#exit-validator} + +Nie. Możesz dokonać konwersji na miejscu, bez wychodzenia. + +### Jak długo potrwa konwersja/konsolidacja? {#how-long} + +Minimum 27,3 godziny, ale konsolidacje podlegają również kolejce. Ta kolejka jest niezależna od kolejek depozytów i wypłat i nie ma na nią wpływu. + +### Czy mogę zachować swój indeks walidatora? {#keep-validator-index} + +Tak. Konwersja na miejscu zachowuje ten sam indeks walidatora. Jeśli konsolidujesz wielu walidatorów, będziesz mógł zachować tylko indeks _walidatora docelowego_. + +### Czy przegapię atestacje? {#miss-attestations} + +Podczas konsolidacji w innego walidatora, walidator źródłowy jest wyłączany i następuje ~27-godzinny okres oczekiwania, zanim saldo stanie się aktywne na walidatorze docelowym. Okres ten **nie wpływa na wskaźniki wydajności**. + +### Czy poniosę kary? {#incur-penalties} + +Nie. Dopóki Twój walidator jest online, nie poniesiesz żadnych kar. + +### Czy adresy wypłat konsolidowanych walidatorów muszą się zgadzać? {#withdrawal-addresses-match} + +Nie. Ale _źródło_ musi autoryzować żądanie z własnego adresu. + +### Czy moje nagrody będą się kapitalizować po konwersji? {#rewards-compound} + +Tak. Z poświadczeniami **Typu 2** nagrody powyżej 32 ETH są automatycznie restakowane — ale nie natychmiast. Z powodu małego bufora (zwanego [_histerezą_](https://eth2book.info/capella/part2/incentives/balances/#hysteresis)) Twoje saldo musi osiągnąć **około 1,25 ETH więcej**, zanim nadwyżka zostanie restakowana. Więc zamiast kapitalizacji przy 33,0 ETH, dzieje się to przy 33,25 (efektywne saldo = 33 ETH), potem przy 34,25 (efektywne saldo = 34 ETH) i tak dalej. + +### Czy po konwersji nadal będę otrzymywać automatyczne operacje sweep? {#automatic-sweep} + +Automatyczne operacje sweep będą miały miejsce tylko w przypadku sald przekraczających 2048. W przypadku wszystkich innych wypłat częściowych należy je uruchamiać ręcznie. + +### Czy mogę zmienić zdanie i wrócić z Typu 2 do Typu 1? {#go-back-to-type1} + +Nie. Konwersja na **Typ 2** jest nieodwracalna. + +### Jeśli chcę skonsolidować wielu walidatorów, czy muszę najpierw przekonwertować każdego z nich na Typ 2? {#consolidate-multiple-validators} + +Nie! Przekonwertuj jednego walidatora na Typ 2, a następnie użyj go jako celu. Wszystkie pozostałe walidatory skonsolidowane w tym celu typu 2 mogą być typu 1 lub typu 2 + +### Mój walidator jest offline lub ma poniżej 32 ETH - czy nadal mogę go przekonwertować? {#offline-or-below-32eth} + +Tak. Dopóki jest aktywny (nie wyszedł z sieci) i możesz podpisywać się jego adresem wypłat, możesz go przekonwertować. + +## Zasoby {#resources} + +- [Specyfikacje konsensusu Electra](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md): To jest „najprawdziwsza” wersja, na której powinieneś/aś polegać. W razie wątpliwości przeczytaj specyfikacje +- Nie każdy czuje się komfortowo, przeglądając kod, więc [ten maxEB-GPT](https://chatgpt.com/g/g-67f1650fb48081918f555e0c8d1c2ae9-maxeb-gpt) może pomóc w interpretacji specyfikacji. _Zastrzeżenie: Należy polegać na specyfikacjach, a nie na sztucznej inteligencji, ponieważ sztuczna inteligencja może błędnie interpretować informacje lub generować halucynacje._ +- [pectrified.com](https://pectrified.com/): Zobacz stan konsolidacji, depozytów i czasów oczekiwania w kolejce +- [Ethereal](https://github.com/wealdtech/ethereal): Stworzone przez społeczność narzędzie CLI do zarządzania typowymi zadaniami walidatora +- [batch-validator-depositor](https://github.com/attestantio/batch-validator-depositor): Stworzony przez społeczność kontrakt, który umożliwia zdeponowanie wielu walidatorów Ethereum w jednej transakcji diff --git a/public/content/translations/pl/roadmap/scaling/index.md b/public/content/translations/pl/roadmap/scaling/index.md index 57e8a09c78c..212e698b704 100644 --- a/public/content/translations/pl/roadmap/scaling/index.md +++ b/public/content/translations/pl/roadmap/scaling/index.md @@ -1,13 +1,13 @@ --- title: Skalowania Ethereum -description: Pakiety zbiorowe grupują razem transakcje poza łańcuchem, zmniejszając koszty dla użytkownika. Jednak sposób, w jaki pakiety zbiorcze wykorzystują dane, jest obecnie zbyt drogi, ograniczając możliwość tanich transakcji. Proto-Danksharding to naprawia. +description: "Pakiety zbiorowe grupują razem transakcje poza łańcuchem, zmniejszając koszty dla użytkownika. Jednak sposób, w jaki pakiety zbiorcze wykorzystują dane, jest obecnie zbyt drogi, ograniczając możliwość tanich transakcji. Proto-Danksharding to naprawia." lang: pl image: /images/roadmap/roadmap-transactions.png alt: "Plan działania Ethereum" template: roadmap --- -Ethereum jest skalowane przy użyciu [warstwy 2](/layer-2/#rollups) (znanej również jako pakiety zbiorcze), która łączy transakcje i wysyła dane do Ethereum. Mimo że pakiety zbiorcze są do ośmiu razy tańsze niż sieć główna Ethereum, możliwa jest dalsza optymalizacja pakietów zbiorczych w celu dalszego obniżenia kosztów dla użytkowników końcowych. Pakiety zbiorcze opierają się również na niektórych scentralizowanych elementach, które deweloperzy mogą usuwać w miarę rozwoju pakietów zbiorczych. +Ethereum jest skalowane przy użyciu [warstw 2](/layer-2/#rollups) (znanych również jako pakiety zbiorcze), które grupują transakcje w pakiety i wysyłają dane wyjściowe do Ethereum. Mimo że pakiety zbiorcze są do ośmiu razy tańsze niż sieć główna Ethereum, możliwa jest dalsza optymalizacja pakietów zbiorczych w celu dalszego obniżenia kosztów dla użytkowników końcowych. Pakiety zbiorcze opierają się również na niektórych scentralizowanych elementach, które deweloperzy mogą usuwać w miarę rozwoju pakietów zbiorczych. @@ -31,26 +31,28 @@ Pakiety zbiorcze zbierają dużą liczbę transakcji, wykonują je i przesyłaj Dane pakietu zbiorczego były kiedyś przechowywane na stałe w Ethereum, co jest kosztowne. Ponad 90% kosztów transakcji ponoszonych przez użytkowników w związku z pakietami zbiorczymi wynika z przechowywania tych danych. Aby zmniejszyć koszty transakcji, możemy przenieść dane do nowej tymczasowej pamięci „blob”. Bloby są tańsze, ponieważ nie są trwałe; usuwa się je z Ethereum, gdy nie są już potrzebne. Długoterminowe przechowywanie danych pakietów zbiorczych staje się obowiązkiem osób, które ich potrzebują, jak np. operatorów pakietów zbiorczych, giełdy, usługi indeksowania itp. Dodawanie transakcji blobów do Ethereum jest częścią aktualizacji znanej jako „Proto-Danksharding”. -Z Proto-Dankshardingiem do bloków Ethereum można dodawać wiele blobów. Będzie to kolejny znaczący (>100 razy) wzrost przepustowości Ethereum i spadek kosztów transakcji. +Z Proto-Dankshardingiem do bloków Ethereum można dodawać wiele blobów. Umożliwia to kolejne znaczące (>100x) zwiększenie przepustowości Ethereum i zmniejszenie kosztów transakcji. ### Danksharding {#danksharding} Drugi etap rozszerzania danych blob jest skomplikowany, ponieważ wymaga nowych metod sprawdzania, czy dane pakietu zbiorczego są dostępne w sieci i opiera się na [walidatorach](/glossary/#validator) oddzielających swoje obowiązki tworzenia [bloków](/glossary/#block) i proponowania bloków. Wymaga to również sposobu na kryptograficzne udowodnienie, że walidatory zweryfikowały małe podzbiory danych blobów. -Ten drugi etap jest znany jako [„Danksharding”](/roadmap/danksharding/). Do jego pełnego wdrożenia **pozostało jeszcze prawdopodobnie kilka lat**. Danksharding opiera się na innych rozwiązaniach, takich jak [separacja tworzenia bloków i propozycji bloków](/roadmap/pbs) oraz nowych projektach sieci, które umożliwiają jej skuteczne potwierdzanie, że dane są dostępne, poprzez losowe próbkowanie kilku kilobajtów na raz, zwane [próbkowaniem dostępności danych (DAS)](/developers/docs/data-availability). +Ten drugi etap jest znany jako ["Danksharding"](/roadmap/danksharding/). Prace wdrożeniowe trwają, a postępy są czynione w zakresie warunków wstępnych, takich jak [oddzielenie tworzenia bloków i propozycji bloków](/roadmap/pbs) oraz nowe projekty sieciowe, które umożliwiają sieci skuteczne potwierdzanie, że dane są dostępne, poprzez losowe próbkowanie kilku kilobajtów na raz, znane jako [próbkowanie dostępności danych (DAS)](/developers/docs/data-availability). Więcej o Dankshardingu ## Decentralizacja pakietów zbiorczych {#decentralizing-rollups} -[Pakiety zbiorcze](/layer-2) już skalują Ethereum. [Bogaty ekosystem projektów pakietów zbiorczych](https://l2beat.com/scaling/tvl) pozwala użytkownikom na szybkie i tanie transakcje z szeregiem gwarancji bezpieczeństwa. Jednak pakiety zbiorcze zostały uruchomione przy użyciu scentralizowanych sekwencerów (komputerów, które wykonują całe przetwarzanie transakcji i agregację przed przesłaniem ich do Ethereum). Jest to podatne na cenzurę, ponieważ operatorzy sekwencerów mogą zostać ukarani, przekupieni lub w inny sposób zagrożeni. Jednocześnie [pakiety zbiorcze różnią się](https://l2beat.com) sposobem weryfikacji przychodzących danych. Najlepszym sposobem jest przesyłanie przez „udowadniających” [dowodów oszustwa](/glossary/#fraud-proof) lub dowodów ważności, ale jeszcze nie wszystkie pakiety zbiorcze to uwzględniają. Nawet te pakiety zbiorcze, które wykorzystują dowody ważności/oszustwa, korzystają z niewielkiej puli znanych udowadniających. Dlatego kolejnym krytycznym etapem w skalowaniu Ethereum jest rozłożenie odpowiedzialności za uruchamianie sekwencerów i udowadniających na większą liczbę osób. +[Pakiety zbiorcze](/layer-2) już skalują Ethereum. [Bogaty ekosystem projektów pakietów zbiorczych](https://l2beat.com/scaling/tvs) umożliwia użytkownikom szybkie i tanie przeprowadzanie transakcji z szeregiem gwarancji bezpieczeństwa. Jednak pakiety zbiorcze zostały uruchomione przy użyciu scentralizowanych sekwencerów (komputerów, które wykonują całe przetwarzanie transakcji i agregację przed przesłaniem ich do Ethereum). Jest to podatne na cenzurę, ponieważ operatorzy sekwencerów mogą zostać ukarani, przekupieni lub w inny sposób zagrożeni. Jednocześnie [pakiety zbiorcze różnią się](https://l2beat.com/scaling/summary) sposobem weryfikacji przychodzących danych. Najlepszym sposobem jest, aby "dowodzący" przesyłali [dowody oszustwa](/glossary/#fraud-proof) lub dowody ważności, ale nie wszystkie pakiety zbiorcze są już na to gotowe. Nawet te pakiety zbiorcze, które wykorzystują dowody ważności/oszustwa, korzystają z niewielkiej puli znanych udowadniających. Dlatego kolejnym krytycznym etapem w skalowaniu Ethereum jest rozłożenie odpowiedzialności za uruchamianie sekwencerów i udowadniających na większą liczbę osób. Więcej o pakietach zbiorczych ## Aktualny postęp {#current-progress} -Proto-Danksharding to pierwszy z tych elementów planu działania, który zostanie wdrożony w ramach aktualizacji sieci Cancun-Deneb („Dencun”) w marcu 2024. **Pełny Danksharding zostanie wdrożony najprawdopodobniej za kilka lat**, ponieważ zależy od ukończenia kilku innych elementów planu działania. Decentralizacja infrastruktury pakietów zbiorczych będzie prawdopodobnie procesem stopniowym — istnieje wiele różnych pakietów zbiorczych, które budują nieco inne systemy i będą w pełni decentralizować się w różnym tempie. +Proto-Danksharding został pomyślnie wdrożony w ramach uaktualnienia sieci nazwanej Cancun-Deneb („Dencun”) w marcu 2024 roku. Od czasu jego implementacji pakiety zbiorcze zaczęły korzystać z pamięci blobów, co doprowadziło do obniżenia kosztów transakcji dla użytkowników i przetworzenia milionów transakcji w blobach. -[Więcej o aktualizacji sieci Dencun](/roadmap/dencun/) +Prace nad pełnym Dankshardingiem wciąż trwają, a postępy są widoczne w zakresie jego wymagań wstępnych, takich jak PBS (separacja proponujący-budujący) i DAS (próbkowanie dostępności danych). Decentralizacja infrastruktury pakietów zbiorczych to procesem stopniowy — istnieje wiele różnych pakietów zbiorczych, które budują nieco inne systemy i będą w pełni decentralizować się w różnym tempie. + +[Więcej o aktualizacji sieci Dencun i jej wpływie](/roadmap/dencun/) diff --git a/public/content/translations/pl/roadmap/secret-leader-election/index.md b/public/content/translations/pl/roadmap/secret-leader-election/index.md index b09daab8ae2..f4891f0081c 100644 --- a/public/content/translations/pl/roadmap/secret-leader-election/index.md +++ b/public/content/translations/pl/roadmap/secret-leader-election/index.md @@ -1,6 +1,6 @@ --- -title: Tajny wybór lidera -description: Wyjaśnienie, w jaki sposób tajny wybór lidera może pomóc chronić walidatory przed atakami +title: "Tajny wybór lidera" +description: "Wyjaśnienie, w jaki sposób tajny wybór lidera może pomóc chronić walidatory przed atakami" lang: pl summaryPoints: - Adres IP proponenta bloków może być znany z wyprzedzeniem, co czyni go podatnym na ataki @@ -10,17 +10,17 @@ summaryPoints: # Tajny wybór lidera {#single-secret-leader-election} -W opbecnym mechanizmie konsensusu opartym na [proof-of-stake](/developers/docs/consensus-mechanisms/pos) lista nadchodzących proponentów bloków jest publiczna i możliwe jest mapowanie ich adresów IP. Oznacza to, że atakujący mogą zidentyfikować, które walidatory będą proponować blok i zaatakować je za pomocą ataku blokady usług (DOS), który uniemożliwi im zaproponowanie bloku na czas. +W dzisiejszym mechanizmie konsensusu opartym na [dowodzie stawki](/developers/docs/consensus-mechanisms/pos) lista nadchodzących proponentów bloków jest publiczna i możliwe jest mapowanie ich adresów IP. Oznacza to, że atakujący mogą zidentyfikować, które walidatory będą proponować blok i zaatakować je za pomocą ataku blokady usług (DOS), który uniemożliwi im zaproponowanie bloku na czas. -Może to stworzyć okazję dla atakującego do osiągnięcia korzyści. Na przykład proponent bloku wybrany do slotu `n+1` może blokować usługi (DOS) osobie proponującej w slocie `n`, tak że straci ona swoją szansę na zaproponowanie bloku. Umożliwiłoby to atakującemu proponentowi bloku wyodrębnienie MEV z obu slotów lub przejęcie wszystkich transakcji, które powinny zostać podzielone na dwa bloki i zamiast tego zawarcie ich wszystkich w jednym, wraz z uzyskaniem wszelkich powiązanych opłat. Prawdopodobnie wpływa to bardziej na walidatory domowe niż na wyrafinowane instytucjonalne walidatory, które mogą korzystać z bardziej zaawansowanych metod ochrony przed atakami DOS, a zatem mogą być siłą centralizującą. +Może to stworzyć okazję dla atakującego do osiągnięcia korzyści. Na przykład proponent bloku wybrany dla slotu `n+1` mógłby przeprowadzić atak DOS na proponenta w slocie `n`, aby ten stracił możliwość zaproponowania bloku. Umożliwiłoby to atakującemu proponentowi bloku wyodrębnienie MEV z obu slotów lub przejęcie wszystkich transakcji, które powinny zostać podzielone na dwa bloki i zamiast tego zawarcie ich wszystkich w jednym, wraz z uzyskaniem wszelkich powiązanych opłat. Prawdopodobnie wpływa to bardziej na walidatory domowe niż na wyrafinowane instytucjonalne walidatory, które mogą korzystać z bardziej zaawansowanych metod ochrony przed atakami DOS, a zatem mogą być siłą centralizującą. -Jest kilka rozwiązań tego problemu. Jednym z nich jest [technologia rozproszonego walidatora](https://github.com/ethereum/distributed-validator-specs), która ma na celu rozłożenie różnych zadań związanych z uruchomieniem walidatora na wiele komputerów wraz z redundancją, tak aby atakującemu było znacznie trudniej zapobiec zaproponowaniu bloku w określonym slocie. Jednak najbardziej niezawodnym rozwiązaniem jest **tajny wybór pojedynczego lidera (SSLE)**. +Jest kilka rozwiązań tego problemu. Jednym z rozwiązań jest [technologia rozproszonego walidatora (Distributed Validator Technology)](https://github.com/ethereum/distributed-validator-specs), której celem jest rozłożenie różnych zadań związanych z uruchamianiem walidatora na wiele maszyn, z nadmiarowością, tak aby atakującemu było znacznie trudniej uniemożliwić zaproponowanie bloku w danym slocie. Jednak najbardziej niezawodnym rozwiązaniem jest **tajny wybór pojedynczego lidera (SSLE)**. -## Tajny wybór pojedynczego lidera (SSLE) {#secret-leader-election} +## Tajny wybór pojedynczego lidera {#secret-leader-election} W SSLE wykorzystywana jest sprytna kryptografia, aby zapewnić, że tylko wybrany walidator wie, że został wybrany. Działa to w taki sposób, że każdy walidator składa zobowiązanie do tajemnicy, którą wszyscy dzielą. Zobowiązania są przemieszane i ponownie konfigurowane, aby nikt nie mógł mapować zobowiązań do walidatorów, ale każdy walidator wie, które zobowiązanie należy do niego. Następnie losowo wybierane jest jedno zobowiązanie. Jeśli walidator wykryje, że jego zobowiązanie zostało wybrane, wie, że nadeszła jego kolej na zaproponowanie bloku. -Główna implementacja tego pomysłu nosi nazwę [Whisk](https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763). Która działa w następujący sposób: +Wiodącą implementacją tego pomysłu jest projekt o nazwie [Whisk](https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763). Która działa w następujący sposób: 1. Walidatory zobowiązują się do wspólnej tajemnicy. Schemat zobowiązania jest zaprojektowany w taki sposób, aby można go było powiązać z tożsamością walidatora, ale jest także losowy, tak aby żadna strona trzecia nie mogła dokonać inżynierii wstecznej powiązania i połączyć określonego zobowiązania z określonym walidatorem. 2. Na początku każdej epoki, losowy zestaw walidatorów jest wybierany do próbkowania zobowiązań od 16.384 walidatorów przy użyciu RANDAO. @@ -33,7 +33,7 @@ Dzięki temu atakujący nie wiedzą z wyprzedzeniem, który konkretny walidator ## Tajny wybór niepojedynczego lidera (SnSLE) {#secret-non-single-leader-election} -Istnieje również osobna propozycja, której celem jest stworzenie scenariusza, w którym każdy z walidatorów ma losową szansę na zaproponowanie bloku w każdym slocie, podobnie jak w przypadku proponowania bloku w ramach proof-of-work, znanego jako **tajny wybór niepojedynczego lidera (SnSLE)**. Jednym z prostych sposobów na to jest wykorzystanie funkcji RANDAO używanej do losowego wybierania walidatorów w obecnym protokole. Założenie RANDAO polega na tym, że wystarczająco losowa liczba jest generowana poprzez mieszanie hashów przesłanych przez wiele niezależnych walidatorów. W SnSLE te hashe mogą służyć do wyboru następnego proponenta bloku, na przykład poprzez wybór hashu o najniższej wartości. Zakres prawidłowych hashów można ograniczyć, aby dostosować prawdopodobieństwo wyboru poszczególnych walidatorów w każdym slocie. Zakładając, że hash musi wynosić mniej niż `2^256 * 5 / N`, gdzie `N` = liczba aktywnych walidatorów, szansa na wybranie dowolnego pojedynczego walidatora w każdym slocie wynosiłaby `5/N`. W tym przykładzie istniałoby 99,3% szans na to, że co najmniej jeden proponent wygeneruje prawidłowy hash w każdym slocie. +Istnieje również osobna propozycja, której celem jest stworzenie scenariusza, w którym walidatorzy mają losową szansę na zaproponowanie bloku w każdym slocie, podobnie jak decydowano o propozycji bloku w ramach dowodu pracy, znana jako **tajny wybór niepojedynczego lidera (SnSLE)**. Jednym z prostych sposobów na to jest wykorzystanie funkcji RANDAO używanej do losowego wybierania walidatorów w obecnym protokole. Założenie RANDAO polega na tym, że wystarczająco losowa liczba jest generowana poprzez mieszanie hashów przesłanych przez wiele niezależnych walidatorów. W SnSLE te hashe mogą służyć do wyboru następnego proponenta bloku, na przykład poprzez wybór hashu o najniższej wartości. Zakres prawidłowych hashów można ograniczyć, aby dostosować prawdopodobieństwo wyboru poszczególnych walidatorów w każdym slocie. Stwierdzając, że hasz musi być mniejszy niż `2^256 * 5 / N`, gdzie `N` = liczba aktywnych walidatorów, szansa na wybranie dowolnego pojedynczego walidatora w każdym slocie wynosiłaby `5/N`. W tym przykładzie istniałoby 99,3% szans na to, że co najmniej jeden proponent wygeneruje prawidłowy hash w każdym slocie. ## Aktualny postęp {#current-progress} diff --git a/public/content/translations/pl/roadmap/security/index.md b/public/content/translations/pl/roadmap/security/index.md index c4fa39e694c..083dde7583b 100644 --- a/public/content/translations/pl/roadmap/security/index.md +++ b/public/content/translations/pl/roadmap/security/index.md @@ -1,48 +1,48 @@ --- title: Bezpieczniejsze Ethereum -description: Ethereum jest najbezpieczniejszą i najbardziej zdecentralizowaną platformą inteligentnych kontraktów. Nadal jednak można wprowadzać ulepszenia, aby Ethereum pozostawała odporna na wszelkie ataki w przyszłości. +description: "Ethereum jest najbezpieczniejszą i najbardziej zdecentralizowaną platformą inteligentnych kontraktów. Nadal jednak można wprowadzać ulepszenia, aby Ethereum pozostawała odporna na wszelkie ataki w przyszłości." lang: pl image: /images/roadmap/roadmap-security.png alt: "Plan działania Ethereum" template: roadmap --- -**Ethereum jest już bardzo bezpieczną**, zdecentralizowaną platformą [inteligentnych kontraktów](/glossary/#smart-contract). Nadal jednak można wprowadzać ulepszenia, aby Ethereum pozostawała odporna na wszelkie ataki w przyszłości. Obejmują one niewielkie zmiany w sposobie, w jaki [klienci Ethereum](/glossary/#consensus-client) radzą sobie z konkurencyjnymi [blokami](/glossary/#block), a także zwiększaniem szybkości, z jaką sieć uznaje bloki za [„sfinalizowane”](/developers/docs/consensus-mechanisms/pos/#finality) (co oznacza, że nie można ich zmienić bez ekstremalnych strat ekonomicznych dla atakującego). +**Ethereum jest już bardzo bezpieczną**, zdecentralizowaną platformą [inteligentnych kontraktów](/glossary/#smart-contract). Nadal jednak można wprowadzać ulepszenia, aby Ethereum pozostawała odporna na wszelkie ataki w przyszłości. Obejmują one subtelne zmiany w sposobie, w jaki [klienci Ethereum](/glossary/#consensus-client) radzą sobie z konkurującymi [blokami](/glossary/#block), a także zwiększają szybkość, z jaką sieć uznaje bloki za [„sfinalizowane”](/developers/docs/consensus-mechanisms/pos/#finality) (co oznacza, że nie można ich zmienić bez ekstremalnych strat ekonomicznych dla atakującego). -Istnieją również ulepszenia, które znacznie utrudniają cenzurowanie transakcji, poprzez uniemożliwianie proponentom bloków śledzenia rzeczywistej zawartości ich bloków, a także nowe sposoby identyfikacji, kiedy klient cenzuruje. Razem, te ulepszenia unowocześnią protokół [proof-of-stake](/glossary/#pos), dzięki czemu użytkownicy — od osób indywidualnych po korporacje — będą mieli natychmiastowe zaufanie do swoich aplikacji, danych i aktywów na Ethereum. +Istnieją również ulepszenia, które znacznie utrudniają cenzurowanie transakcji, poprzez uniemożliwianie proponentom bloków śledzenia rzeczywistej zawartości ich bloków, a także nowe sposoby identyfikacji, kiedy klient cenzuruje. Te ulepszenia razem zaktualizują protokół [proof-of-stake](/glossary/#pos), dzięki czemu użytkownicy – od osób fizycznych po korporacje – będą mieli natychmiastowe zaufanie do swoich aplikacji, danych i zasobów na Ethereum. -## Wypłaty ze stakingu {#staking-withdrawals} +## Wypłaty ze stakowania {#staking-withdrawals} -Aktualizacja z [proof-of-work](/glossary/#pow) do proof-of-stake rozpoczęła się od pionierów Ethereum „stakujących” swoje ETH w kontrakcie depozytowym. Te ETH są wykorzystywane do zabezpieczania sieci. W dniu 12 kwietnia 2023 miała miejsce druga aktualizacja, pozwalająca na wypłatę zestakowanego ETH. Od tamtego momentu walidatorzy mogą swobodnie stakować lub wypłacać swoje ETH. +Ulepszenie z [proof-of-work](/glossary/#pow) do proof-of-stake rozpoczęło się od pionierów Ethereum „stakujących” swoje ETH w kontrakcie depozytowym. Te ETH są wykorzystywane do zabezpieczania sieci. Druga aktualizacja miała miejsce 12 kwietnia 2023 r. i pozwoliła walidatorom na wypłatę stakowanego ETH. Od tamtego momentu walidatorzy mogą swobodnie stakować lub wypłacać swoje ETH. Poczytaj o wypłatach -## Ochrona przed atakami {#defending-against-attacks} +## Obrona przed atakami {#defending-against-attacks} -Istnieją ulepszenia, które można wprowadzić do protokołu proof-of-stake Ethereum. Jedno z nich znane jest jako [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739) — bezpieczniejszy algorytm wyboru [forka](/glossary/#fork), który utrudnia niektóre wyrafinowane rodzaje ataków. +Istnieją ulepszenia, które można wprowadzić do protokołu proof-of-stake Ethereum. Jeden z nich jest znany jako [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739) – bezpieczniejszy algorytm wyboru [forka](/glossary/#fork), który utrudnia niektóre zaawansowane typy ataków. -Skrócenie czasu, jakiego Ethereum potrzebuje na [sfinalizowanie](/glossary/#finality) bloków, zapewniłoby lepsze wrażenie użytkownika i zapobiegłoby wyrafinowanym atakom „reorganizacyjnym”, w których atakujący próbują przemieszać najnowsze bloki, aby uzyskać zysk lub ocenzurować niektóre transakcje. [**Finalizacja pojedynczego slotu (SSF)**](/roadmap/single-slot-finality/) to **sposób na zminimalizowanie opóźnienia finalizacji**. W tej chwili istnieją 15-minutowe bloki, do których przekonfigurowania atakujący mógłby teoretycznie przekonać inne walidatory. Z SSF jest ich 0. Użytkownicy, od osób indywidualnych po aplikacje i giełdy, korzystają z szybkiej gwarancji, że ich transakcje nie zostaną cofnięte, a sieć korzysta z zamknięcia całej masy ataków. +Zmniejszenie czasu potrzebnego Ethereum na [sfinalizowanie](/glossary/#finality) bloków zapewniłoby lepsze wrażenia użytkownika i zapobiegłoby zaawansowanym atakom typu „reorg”, w których atakujący próbują przetasować najnowsze bloki, aby uzyskać zysk lub ocenzurować niektóre transakcje. [**Finalizacja w pojedynczym slocie (SSF)**](/roadmap/single-slot-finality/) to **sposób na zminimalizowanie opóźnienia finalizacji**. W tej chwili istnieją 15-minutowe bloki, do których przekonfigurowania atakujący mógłby teoretycznie przekonać inne walidatory. Z SSF jest ich 0. Użytkownicy, od osób indywidualnych po aplikacje i giełdy, korzystają z szybkiej gwarancji, że ich transakcje nie zostaną cofnięte, a sieć korzysta z zamknięcia całej masy ataków. -Poczytaj o finalizacji pojedynczego slotu +Poczytaj o finalizacji w pojedynczym slocie -## Ochrona przed cenzurą {#defending-against-censorship} +## Obrona przed cenzurą {#defending-against-censorship} -Decentralizacja uniemożliwia wywieranie nadmiernego wpływu przez pojedyncze osoby lub małe grupy [walidatorów](/glossary/#validator). Nowe technologie stakowania mogą zwiększyć gwarancję, że walidatory Ethereum pozostaną tak zdecentralizowane, jak to tylko możliwe, jednocześnie chroniąc je przed awariami sprzętu, oprogramowania i sieci. Dotyczy to także oprogramowania, które dzieli obowiązki walidatora na wiele [węzłów](/glossary/#node). Jest ono znane pod nazwą **technologii rozproszonego walidatora (DVT)**. [Pule stakingowe](/glossary/#staking-pool) zachęcają do korzystania z DVT, ponieważ pozwala to wielu komputerom wspólnie uczestniczyć w walidacji; do tego dochodzi redundancja i odporność na błędy. Dzieli również klucze walidatora na kilka systemów, co jest alternatywą dla posiadania pojedynczych operatorów obsługujących wiele walidatorów. Utrudnia to nieuczciwym operatorom koordynowanie ataków na Ethereum. Podsumowując, pomysł polega na uzyskaniu korzyści bezpieczeństwa poprzez uruchamianie walidatorów jako _społeczności_, a nie jako jednostek. +Decentralizacja uniemożliwia osobom fizycznym lub małym grupom [walidatorów](/glossary/#validator) uzyskanie zbyt dużych wpływów. Nowe technologie stakowania mogą zwiększyć gwarancję, że walidatory Ethereum pozostaną tak zdecentralizowane, jak to tylko możliwe, jednocześnie chroniąc je przed awariami sprzętu, oprogramowania i sieci. Obejmuje to oprogramowanie, które rozdziela obowiązki walidatora pomiędzy wiele [węzłów](/glossary/#node). Jest to znane jako **technologia rozproszonego walidatora (DVT)**. [Pule stakowania](/glossary/#staking-pool) są zachęcane do korzystania z DVT, ponieważ pozwala to wielu komputerom na wspólne uczestnictwo w walidacji, co zwiększa redundancję i odporność na błędy. Dzieli również klucze walidatora na kilka systemów, co jest alternatywą dla posiadania pojedynczych operatorów obsługujących wiele walidatorów. Utrudnia to nieuczciwym operatorom koordynowanie ataków na Ethereum. Ogólnie rzecz biorąc, chodzi o to, aby czerpać korzyści z bezpieczeństwa, uruchamiając walidatorów jako _społeczności_, a nie jako pojedyncze podmioty. Poczytaj o technologii rozproszonego walidatora -Wdrożenie **podziału proponent-twórca (PBS)** radykalnie poprawi wbudowaną ochronę Ethereum przed cenzurą. PBS pozwala jednemu walidatorowi na tworzenie bloku, a drugiemu na rozgłaszanie go w sieci Ethereum. Dzięki temu zyski z profesjonalnych maksymalizujących zyski algorytmów tworzenia bloku są dzielone sprawiedliwiej w całej sieci, **zapobiegając koncentracji stawek** u najlepiej działających stakerów instytucjonalnych w czasie. Proponent bloku może wybrać najbardziej opłacalny blok oferowany mu przez rynek twórców bloków. Aby cenzurować, proponent bloku często musiałby wybrać mniej opłacalny blok, co byłoby **ekonomicznie nierozsądne, a także oczywiste dla pozostałych walidatorów** w sieci. +Wdrożenie **rozdzielenia proponującego od budowniczego (PBS)** znacznie poprawi wbudowane mechanizmy obronne Ethereum przed cenzurą. PBS pozwala jednemu walidatorowi na tworzenie bloku, a drugiemu na rozgłaszanie go w sieci Ethereum. Zapewnia to, że zyski z profesjonalnych, maksymalizujących zysk algorytmów budowania bloków są dzielone bardziej sprawiedliwie w całej sieci, **zapobiegając koncentracji stawki** u najlepiej prosperujących stakerów instytucjonalnych w miarę upływu czasu. Proponent bloku może wybrać najbardziej opłacalny blok oferowany mu przez rynek twórców bloków. Aby dokonać cenzury, proponujący blok musiałby często wybierać mniej dochodowy blok, co byłoby **ekonomicznie irracjonalne i oczywiste dla reszty walidatorów** w sieci. Istnieją potencjalne dodatki do PBS, takie jak szyfrowane transakcje i listy inkluzywne, które mogą jeszcze bardziej poprawić odporność Ethereum na cenzurę. Za ich sprawą twórca bloku i proponent nie widzą rzeczywistych transakcji zawartych w ich blokach. -Poczytaj o podziale proponent-twórca +Poczytaj o rozdzieleniu proponującego od budowniczego ## Ochrona walidatorów {#protecting-validators} -Istnieje ewentualność, że wyrafinowany atakujący może zidentyfikować nadchodzące walidatory i spamować je, aby uniemożliwić im proponowanie bloków; jest to znane jako atak **blokady usług (DoS)**. Wdrożenie [**tajnego wyboru lidera (SLE)**](/roadmap/secret-leader-election) ochroni przed tego typu atakami, uniemożliwiając wcześniejsze poznanie proponenta bloków. Działa to poprzez ciągłe mieszanie zestawu zobowiązań kryptograficznych reprezentujących kandydatów na proponentów bloków i wykorzystywanie ich kolejności do określenia, który walidator jest wybierany w taki sposób, że tylko sami walidatorzy znają ich kolejność z wyprzedzeniem. +Możliwe jest, że zaawansowany atakujący mógłby zidentyfikować nadchodzących walidatorów i spamować ich, aby uniemożliwić im proponowanie bloków; jest to znane jako atak typu **odmowa usługi (DoS)**. Wdrożenie [**tajnego wyboru lidera (SLE)**](/roadmap/secret-leader-election) ochroni przed tego typu atakami, uniemożliwiając poznanie z wyprzedzeniem tożsamości osób proponujących bloki. Działa to poprzez ciągłe mieszanie zestawu zobowiązań kryptograficznych reprezentujących kandydatów na proponentów bloków i wykorzystywanie ich kolejności do określenia, który walidator jest wybierany w taki sposób, że tylko sami walidatorzy znają ich kolejność z wyprzedzeniem. Poczytaj o tajnym wyborze lidera ## Aktualny postęp {#current-progress} -**Aktualizacje zabezpieczeń w planie działania są w zaawansowanym stadium badań**, ale nie oczekuje się, że zostaną wdrożone w najbliższym czasie. Kolejnymi krokami dla view-merge, PBS, SSF i SLE jest sfinalizowanie specyfikacji i rozpoczęcie tworzenia prototypów. +**Ulepszenia bezpieczeństwa w planie rozwoju są na zaawansowanym etapie badań**, ale nie przewiduje się, że zostaną wdrożone w najbliższym czasie. Kolejne kroki dla view-merge, PBS, SSF i SLE to sfinalizowanie specyfikacji i rozpoczęcie budowy prototypów. diff --git a/public/content/translations/pl/roadmap/single-slot-finality/index.md b/public/content/translations/pl/roadmap/single-slot-finality/index.md index e24d02fbf7d..73e52ac9d22 100644 --- a/public/content/translations/pl/roadmap/single-slot-finality/index.md +++ b/public/content/translations/pl/roadmap/single-slot-finality/index.md @@ -1,12 +1,12 @@ --- title: Finalizacja pojedynczego slotu -description: Objaśnienie finalizacji pojedynczego slotu +description: "Objaśnienie finalizacji pojedynczego slotu" lang: pl --- -# Finalizacja pojedynczego slotu {#single-slot-finality} +# Nieodwołalność pojedynczego slotu {#single-slot-finality} -Finalizacja bloku Ethereum zajmuje około 15 minut. Możemy jednak sprawić, że mechanizm konsensusu Ethereum będzie weryfikował bloki efektywniej i znacznie skróci czas osiągnięcia finalizacji. Zamiast czekać piętnaście minut, bloki można by zaproponować i sfinalizować w tym samym slocie. Koncepcja ta znana jest jako **finalizacja pojedynczego slotu (SSF)**. +Finalizacja bloku Ethereum zajmuje około 15 minut. Możemy jednak sprawić, że mechanizm konsensusu Ethereum będzie weryfikował bloki efektywniej i znacznie skróci czas osiągnięcia finalizacji. Zamiast czekać piętnaście minut, bloki można by zaproponować i sfinalizować w tym samym slocie. Koncepcja ta znana jest jako **nieodwołalność pojedynczego slotu (SSF)**. ## Czym jest finalizacja? {#what-is-finality} @@ -16,7 +16,7 @@ W mechanizmie konsensusu Ethereum opartym na proof-of-stake finalizacja odnosi s Obecny czas finalizacji okazał się zbyt długi. Większość użytkowników nie chce czekać 15 minut na finalizację, a dla aplikacji i giełd, którym może zależeć na wysokiej przepustowości transakcji, niewygodnie jest czekać tak długo dla uzyskania pewności, że ich transakcje są trwałe. Opóźnienie między propozycją bloku a jego finalizacją stwarza również okazję do krótkich reorganizacji, które atakujący mógłby wykorzystać do cenzurowania niektórych bloków lub wyodrębnienia MEV. Mechanizm, który zajmuje się uaktualnianiem bloków etapami, jest również dość złożony i był kilkakrotnie łatany w celu usunięcia luk w zabezpieczeniach, co czyni go jedną z części bazy kodu Ethereum, w której istnieje większe prawdopodobieństwo wystąpienia drobnych błędów. Wszystkie te problemy można by wyeliminować skracając czas finalizacji do pojedynczego slotu. -## Kompromis decentralizacji / czasu / kosztów ogólnych {#the-decentralization-time-overhead-tradeoff} +## Kompromis między decentralizacją, czasem i narzutem {#the-decentralization-time-overhead-tradeoff} Gwarancja finalizacji nie jest natychmiastową właściwością nowego bloku; finalizacja nowego bloku wymaga czasu. Wynika to z faktu, że walidatorzy reprezentujący co najmniej 2/3 wszystkich zestakowanych ETH w sieci muszą zagłosować za blokiem („poświadczyć”), aby został on uznany za sfinalizowany. Każdy węzeł walidujący w sieci musi przetwarzać poświadczenia z innych węzłów, aby wiedzieć, że blok osiągnął lub nie osiągnął tego progu 2/3. @@ -33,7 +33,7 @@ Przy obecnej strukturze mechanizmu skrócenie czasu finalizacji wymaga zmniejsze ## Drogi do SSF {#routes-to-ssf} - + Obecny mechanizm konsensusu łączy poświadczenia od wielu walidatorów znanych jako komitety w celu zmniejszenia liczby wiadomości, jaką każdy walidator musi przetworzyć w celu walidacji bloku. Każdy walidator ma możliwość poświadczania w każdej epoce (32 sloty), ale w każdym slocie poświadcza tylko podzbiór walidatorów znanych jako „komitet”. Robią to, dzieląc się na podsieci, w których kilka walidatorów jest wybieranych jako „agregatory”. Każdy z tych agregatorów łączy wszystkie podpisy, które widzą od innych walidatorów w swojej podsieci, w jeden zagregowany podpis. Agregator, który uwzględni największą liczbę indywidualnych wkładów, podaje swój zagregowany podpis do proponenta bloków, który dołącza go do bloku wraz z innymi zagregowanymi podpisami od innych komitetów. @@ -44,23 +44,23 @@ W tym schemacie każdy walidator może głosować na blok, rozdzielając jedynie Od czasu zaprojektowania mechanizmu konsensusu Ethereum okazało się, że schemat agregacji podpisów (BSL) jest bardziej skalowalny niż początkowo sądzono, a zdolność klientów do przetwarzania i weryfikowania podpisów również uległa poprawie. Okazuje się, że przetwarzanie poświadczeń od dużej ilości walidatorów jest w rzeczywistości możliwe w pojedynczym slocie. Na przykład przy milionie walidatorów, z których każdy głosuje dwukrotnie w każdym slocie, i czasie slotu ustawionym na 16 sekund, od węzłów byłoby wymagane weryfikowanie podpisów z minimalną prędkością 125 000 agregacji na sekundę, aby przetworzyć cały milion poświadczeń w ramach jednego slotu. W rzeczywistości normalny komputer potrafi zweryfikować jeden podpis w czasie 500 nanosekund, co oznacza, że zweryfikowanie 125 000 podpisów zajęłoby około 62,5m s — o wiele mniej niż wymagany próg jednej sekundy. -Dalszy wzrost wydajności można by osiągnąć przez stworzenie superkomitetów składających się z np. 125 000 losowo wybranych walidatorów na slot. Tylko ci walidatorzy mogliby głosować na blok i dlatego tylko ten podzbiór walidatorów decydowałby o tym, czy blok zostanie sfinalizowany. To, czy jest to dobry pomysł, czy nie, sprowadza się do tego, jaki koszt skutecznego ataku na Ethereum preferowałaby społeczność. Zamiast posiadania 2/3 całego zestakowanego etheru, atakujący mógłby bowiem sfinalizować nieuczciwy blok przy pomocy 2/3 całego zestakowanego etheru _w tym superkomitecie_. Jest to wciąż aktywny obszar badań, ale wydaje się możliwe, że dla zbioru walidatorów dostatecznie dużego, aby w pierwszej kolejności wymagać powołania superkomitetów, koszt ataku na jeden z tych podkomitetów byłby wyjątkowo wysoki (np. koszt ataku wyrażony w ETH wynosiłby `2/3 * 125 000 * 32 = ~2,6 miliona ETH`). Koszt ataku można dostosować przez zwiększenie rozmiaru zbioru walidatorów (np. zmienienie ilości walidatorów tak, aby koszt ataku wynosił 1 mln ETH, 4 mln ETH, 10 mln ETH itp.). [Wstępne ankiety](https://youtu.be/ojBgyFl6-v4?t=755) wśród społeczności sugerują, że 1-2 mln etheru to akceptowalny koszt ataku, co oznaczałoby około 65 536 do 97 152 walidatorów na superkomitet. +Dalszy wzrost wydajności można by osiągnąć przez stworzenie superkomitetów składających się np. ze 125 000 losowo wybranych walidatorów na slot. Tylko ci walidatorzy mogliby głosować na blok i dlatego tylko ten podzbiór walidatorów decydowałby o tym, czy blok zostanie sfinalizowany. To, czy jest to dobry pomysł, czy nie, sprowadza się do tego, jaki koszt skutecznego ataku na Ethereum preferowałaby społeczność. Dzieje się tak, ponieważ zamiast wymagać 2/3 całkowitego stakowanego etheru, atakujący mógłby sfinalizować nieuczciwy blok przy użyciu 2/3 stakowanego etheru _w tym superkomitecie_. Jest to wciąż aktywny obszar badań, ale wydaje się prawdopodobne, że dla zbioru walidatorów na tyle dużego, aby w ogóle wymagać superkomitetów, koszt ataku na jeden z tych podkomitetów będzie niezwykle wysoki (np. koszt ataku wyrażony w ETH wyniósłby `2/3 * 125,000 * 32 = ~2.6 million ETH`). Koszt ataku można dostosować poprzez zwiększenie wielkości zbioru walidatorów (np. dostosowując wielkość zbioru tak, aby koszt ataku wynosił 1 milion etheru, 4 miliony etheru, 10 milionów etheru itp.). [Wstępne ankiety](https://youtu.be/ojBgyFl6-v4?t=755) społeczności zdają się sugerować, że 1-2 miliony etheru to akceptowalny koszt ataku, co oznacza ~65 536 - 97 152 walidatorów na superkomitet. -Weryfikacja nie jest jednak prawdziwym wąskim gardłem — jest nim agregacja podpisów, które stanowi prawdziwe wyzwanie dla węzłów walidatora. Skalowanie agregacji podpisów będzie najprawdopodobniej wymagać zwiększenia ilości walidatorów w każdej podsieci, zwiększenia ilości podsieci lub dodania dodatkowych warstw agregacji (tj. wdrożenia komitetu komitetów). Częścią rozwiązania może być zezwolenie na wyspecjalizowanych agregatorów — podobnie jak tworzenie bloków i tworzenie poświadczeń dla danych pakietu zbiorczego będzie zlecone wyspecjalizowanym twórcom bloków w ramach podziału proponent-twórca (PBS) i Dankshardingu. +Weryfikacja nie jest jednak prawdziwym wąskim gardłem — jest nim agregacja podpisów, które stanowi prawdziwe wyzwanie dla węzłów walidatora. Skalowanie agregacji podpisów będzie prawdopodobnie wymagać zwiększenia liczby walidatorów w każdej podsieci, zwiększenia liczby podsieci lub dodania dodatkowych warstw agregacji (tj. wdrożenia komitetów komitetów). Częścią rozwiązania może być zezwolenie na wyspecjalizowanych agregatorów — podobnie jak tworzenie bloków i tworzenie poświadczeń dla danych pakietu zbiorczego będzie zlecone wyspecjalizowanym twórcom bloków w ramach podziału proponent-twórca (PBS) i Dankshardingu. -## Jak jest rola zasady wyboru forka w SSF? {#role-of-the-fork-choice-rule} +## Jak jest rola zasady wyboru forka w SSF? Rola zasady wyboru forka {#role-of-the-fork-choice-rule} -Obecny mechanizm konsensusu opiera się na ścisłym powiązaniu między gadżetem finalizacji (algorytmem, który określa, które 2/3 walidatorów poświadczyło określony łańcuch) i zasadą wyboru forka (algorytmem, który decyduje, który łańcuch jest prawidłowy, kiedy jest do wyboru parę opcji). Algorytm wyboru forka bierze pod uwagę tylko bloki _od_ ostatniego sfinalizowanego bloku. W SSF nie byłoby żadnych bloków do uwzględnienia zasady wyboru forka, ponieważ finalizacja odbywa się w tym samym slocie, w którym blok został zaproponowany. Oznacza to, że w SSF _albo_ algorytm wyboru forka, _albo_ gadżet finalizacji byłby aktywny cały czas. Gadżet finalizacji finalizowałby bloki, w których 2/3 walidatorów była online i uczciwie poświadczała. Jeśli blok nie jest w stanie przekroczyć progu 2/3, zasada wyboru forka określa, za którym łańcuchem podążać. Stwarza to również możliwość zachowania mechanizmu wycieku nieaktywności, który odzyskuje łańcuch, w którym >1/3 walidatorów przechodzi w tryb offline, jednakże z pewnymi dodatkowymi różnicami. +Obecny mechanizm konsensusu opiera się na ścisłym powiązaniu między gadżetem finalizacji (algorytmem, który określa, które 2/3 walidatorów poświadczyło określony łańcuch) i zasadą wyboru forka (algorytmem, który decyduje, który łańcuch jest prawidłowy, kiedy jest do wyboru parę opcji). Algorytm wyboru forka bierze pod uwagę tylko bloki _od_ ostatniego sfinalizowanego bloku. W SSF nie byłoby żadnych bloków do uwzględnienia zasady wyboru forka, ponieważ finalizacja odbywa się w tym samym slocie, w którym blok został zaproponowany. Oznacza to, że w ramach SSF w dowolnym momencie aktywny byłby _albo_ algorytm wyboru forka, _albo_ gadżet nieodwołalności. Gadżet finalizacji finalizowałby bloki, w których 2/3 walidatorów była online i uczciwie poświadczała. Jeśli blok nie jest w stanie przekroczyć progu 2/3, zasada wyboru forka określa, za którym łańcuchem podążać. Stwarza to również możliwość utrzymania mechanizmu wycieku z powodu nieaktywności, który odzyskuje łańcuch, w którym >1/3 walidatorów przechodzi w tryb offline, aczkolwiek z pewnymi dodatkowymi niuansami. -## Nierozstrzygnięte kwestie {#outstanding-issues} +## Nierozwiązane kwestie {#outstanding-issues} -Problem ze skalowaniem agregacji poprzez zwiększanie ilości walidatorów na podsieć polega na tym, że dochodzi do większego obciążenia sieci peer-to-peer. Natomiast problem z dodawaniem warstw agregacji polega na tym, że proces techniczny jest dość skomplikowany i zwiększa opóźnienie (tj. może upłynąć więcej czasu, zanim proponent bloku otrzyma informacje od wszystkich agregatorów podsieci). Nie do końca też wiadomo, jak poradzić sobie ze scenariuszem, w którym jest więcej aktywnych walidatorów w sieci niż może zostać przetworzone w każdym slocie, nawet z agregacją podpisów BLS. Możliwym rozwiązaniem mogłoby być to, że ponieważ wszyscy walidatorzy poświadczają w każdym slocie, a w SSF nie ma komitetów, limit 32 ETH efektywnego salda mógłby zostać całkowicie usunięty, co oznacza, że operatorzy zarządzający wieloma walidatorami mogliby skonsolidować swoje stawki i uruchomić mniejszą ich liczbę, zmniejszając liczbę wiadomości, które węzły walidacyjne musiałyby przetworzyć, aby uwzględnić cały zestaw walidatorów. Polega to na wspólnej zgodzie dużych stakerów na skonsolidowanie swoich walidatorów. Możliwe jest również w każdym momencie nałożenie stałego limitu na liczbę walidatorów bądź kwotę zestakowanego ETH. Wymaga to jednak mechanizmu, który decydowałby, które walidatory mogą, a które nie mogą uczestniczyć, co mogłoby powodować niepożądane efekty. +Problem ze skalowaniem agregacji poprzez zwiększanie ilości walidatorów na podsieć polega na tym, że dochodzi do większego obciążenia sieci peer-to-peer. Problem z dodawaniem warstw agregacji polega na tym, że jest to dość złożone technicznie i zwiększa opóźnienia (tzn. może minąć więcej czasu, zanim proponent bloku otrzyma odpowiedzi od wszystkich agregatorów podsieci). Nie do końca też wiadomo, jak poradzić sobie ze scenariuszem, w którym jest więcej aktywnych walidatorów w sieci niż może zostać przetworzone w każdym slocie, nawet z agregacją podpisów BLS. Możliwym rozwiązaniem mogłoby być to, że ponieważ wszyscy walidatorzy poświadczają w każdym slocie, a w SSF nie ma komitetów, limit 32 ETH efektywnego salda mógłby zostać całkowicie usunięty, co oznacza, że operatorzy zarządzający wieloma walidatorami mogliby skonsolidować swoje stawki i uruchomić mniejszą ich liczbę, zmniejszając liczbę wiadomości, które węzły walidacyjne musiałyby przetworzyć, aby uwzględnić cały zestaw walidatorów. Polega to na wspólnej zgodzie dużych stakerów na skonsolidowanie swoich walidatorów. Możliwe jest również w każdym momencie nałożenie stałego limitu na liczbę walidatorów bądź kwotę zestakowanego ETH. Wymaga to jednak mechanizmu, który decydowałby, które walidatory mogą, a które nie mogą uczestniczyć, co mogłoby powodować niepożądane efekty. ## Aktualny postęp {#current-progress} -SSF jest w fazie badań. Jego wdrożenia nie należy się spodziewać w najbliższych kilku latach - nastąpi to prawdopodobnie po innych znaczących uaktualnieniach, takich jak [drzewa Verkle](/roadmap/verkle-trees/) i [Danksharding](/roadmap/danksharding/). +SSF jest w fazie badań. Nie przewiduje się wdrożenia przez kilka lat, prawdopodobnie po innych istotnych uaktualnieniach, takich jak [drzewa Verkle](/roadmap/verkle-trees/) i [Danksharding](/roadmap/danksharding/). ## Dalsza lektura {#further-reading} - [Vitalik o SSF na EDCON 2022](https://www.youtube.com/watch?v=nPgUKNPWXNI) -- [Uwagi Vitalika: Drogi do finalizacji pojedynczego slotu](https://notes.ethereum.org/@vbuterin/single_slot_finality) +- [Notatki Vitalika: Drogi do nieodwołalności pojedynczego slotu](https://notes.ethereum.org/@vbuterin/single_slot_finality) diff --git a/public/content/translations/pl/roadmap/statelessness/index.md b/public/content/translations/pl/roadmap/statelessness/index.md index 81c9153ac69..93a64d07ef7 100644 --- a/public/content/translations/pl/roadmap/statelessness/index.md +++ b/public/content/translations/pl/roadmap/statelessness/index.md @@ -1,6 +1,6 @@ --- -title: Bezstanowość, wygasanie stanu oraz wygasanie historii -description: Objaśnienie wygasania historii oraz bezstanowości Ethereum +title: "Bezstanowość, wygasanie stanu oraz wygasanie historii" +description: "Objaśnienie wygasania historii oraz bezstanowości Ethereum" lang: pl --- @@ -12,14 +12,14 @@ Obecnie wymóg posiadania dużej ilości przestrzeni dyskowej jest główną prz Tańsze dyski twarde mogą być stosowane do przechowywania starszych danych, ale te są zbyt wolne, aby nadążać za nadchodzącymi blokami. Utrzymanie obecnych modeli pamięci dla klientów przy jednoczesnym obniżaniu kosztów danych oraz ułatwianiu ich przechowywania jest tylko tymczasowym i częściowym rozwiązaniem problemu, ponieważ wzrost stanu Ethereum jest „nieograniczony”, co oznacza, że wymagania pamięci mogą tylko rosnąć, a ulepszenia technologiczne zawsze będą musiały nadążać za stałym wzrostem stanu. Zamiast tego, klienty muszą znaleźć nowe sposoby na weryfikowanie bloków i transakcji, które nie opierają się na wyszukiwaniu danych w lokalnej bazie danych. -## Zmniejszenie pamięci dla węzłów {#reducing-storage-for-nodes} +## Zmniejszanie pamięci masowej dla węzłów {#reducing-storage-for-nodes} Istnieje kilka sposobów na zredukowanie ilości danych, jakie musi przechowywać każdy węzeł, a każdy z nich wymaga zaktualizowania głównego protokołu Ethereum w różnym stopniu: -- **Wygasanie historii**: umożliwia węzłom na porzucenie danych o stanie starszym niż X bloków, ale nie zmienia sposobu, w jaki klient Ethereum obsługuje dane stanu. +- **Wygasanie historii**: umożliwia węzłom odrzucanie danych stanu starszych niż X bloków, ale nie zmienia sposobu, w jaki klienci Ethereum obsługują dane stanu. - **Wygasanie stanu**: umożliwia, aby dane o stanie, które nie są często używane, stały się nieaktywne. Nieaktywne dane mogą być ignorowane przez klientów do czasu ich wskrzeszenia. - **Słaba bezstanowość**: tylko twórcy bloków potrzebują dostępu do pełnych danych o stanie, inne węzły mogą zweryfikować bloki bez lokalnej bazy danych stanu. -- **Silna bezstanowość**: żaden węzeł nie potrzebuje dostępu do pełnych danych o stanie. +- **Silna bezstanowość**: żadne węzły nie potrzebują dostępu do pełnych danych o stanie. ## Wygasanie danych {#data-expiry} @@ -42,9 +42,9 @@ Wygasanie stanu odnosi się do usuwania stanu z poszczególnych węzłów, jeśl - **Wygasanie przez czynsz**: pobieranie „czynszu” od kont i wygasanie ich, gdy ich czynsz osiągnie zero - **Wygasanie przez czas**: zmienianie kont na nieaktywne, jeśli nie ma odczytu/zapisu na danym koncie przez pewien określony czas -Wygasanie przez czynsz mogłoby być bezpośrednim czynszem pobieranym od kont, aby utrzymać je w bazie danych aktywnych stanów. Wygasanie przez czas mogłoby odbywać się poprzez odliczanie od ostatniej interakcji konta lub mogłoby być okresowym wygasaniem wszystkich kont. Mógłby istnieć również mechanizm, który połączyłby elementy obu tych modeli; na przykład indywidualne konto pozostawałoby w aktywnym stanie, gdyby uiściło jakąś niewielką opłatę przed wygaśnięciem opartym na czasie. W przypadku wygasania stanu warto zapamiętać, że nieaktywny stan **nie jest usuwany**, a po prostu przechowywany oddzielnie od aktywnego stanu. Stan nieaktywny może zostać przywrócony do stanu aktywnego. +Wygasanie przez czynsz mogłoby być bezpośrednim czynszem pobieranym od kont, aby utrzymać je w bazie danych aktywnych stanów. Wygasanie przez czas mogłoby odbywać się poprzez odliczanie od ostatniej interakcji konta lub mogłoby być okresowym wygasaniem wszystkich kont. Mógłby istnieć również mechanizm, który połączyłby elementy obu tych modeli; na przykład indywidualne konto pozostawałoby w aktywnym stanie, gdyby uiściło jakąś niewielką opłatę przed wygaśnięciem opartym na czasie. W przypadku wygasania stanu warto zapamiętać, że nieaktywny stan nie jest usuwany, a po prostu przechowywany oddzielnie od aktywnego stanu. Stan nieaktywny może zostać przywrócony do stanu aktywnego. -Najprawdopodobniej funkcjonowałoby to poprzez posiadanie drzewa stanu dla określonych okresów (być może 1 rok). Wraz z rozpoczęciem nowego okresu rozpoczynałoby się nowe drzewo stanu. Tylko bieżące drzewo stanów podlegałoby modyfikacji, wszystkie inne byłyby niezmienne. Od węzłów Ethereum oczekiwałoby się przechowywania tylko bieżącego drzewa stanu i kolejnego najnowszego. Wymaga to sposobu na oznaczenie adresu okresem, w którym istnieje. Istnieje [kilka możliwych sposobów](https://ethereum-magicians.org/t/types-of-resurrection-metadata-in-state-expiry/6607) na zrobienie tego, ale główna opcja wymaga [wydłużenia adresów](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485), aby pomieścić dodatkowe informacje, co miałoby tę dodatkową zaletę, że dłuższe adresy są o wiele bardziej bezpieczne. Element planu działania, który to robi, nazywa się [rozszerzeniem przestrzeni adresu](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485). +Najprawdopodobniej funkcjonowałoby to poprzez posiadanie drzewa stanu dla określonych okresów (być może 1 rok). Wraz z rozpoczęciem nowego okresu rozpoczynałoby się nowe drzewo stanu. Tylko bieżące drzewo stanów podlegałoby modyfikacji, wszystkie inne byłyby niezmienne. Od węzłów Ethereum oczekiwałoby się przechowywania tylko bieżącego drzewa stanu i kolejnego najnowszego. Wymaga to sposobu na oznaczenie adresu okresem, w którym istnieje. Istnieje [kilka możliwych sposobów](https://ethereum-magicians.org/t/types-of-resurrection-metadata-in-state-expiry/6607), aby to zrobić, ale wiodąca opcja wymaga [wydłużenia adresów](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485), aby pomieścić dodatkowe informacje, co ma dodatkową zaletę, że dłuższe adresy są znacznie bezpieczniejsze. Element planu działania, który to realizuje, nazywa się [rozszerzeniem przestrzeni adresowej](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485). Podobnie jak w przypadku wygasania historii, w ramach wygasania stanu odpowiedzialność za przechowywanie starych danych stanu jest przenoszona z indywidualnych użytkowników na inne podmioty, takie jak scentralizowani dostawcy, altruistyczni członkowie społeczności lub na bardziej przyszłościowe zdecentralizowane rozwiązania, jak sieć Portal. @@ -56,7 +56,7 @@ Bezstanowość jest nieco mylącym określeniem, ponieważ nie oznacza wyelimino - prawie natychmiastowa synchronizacja - możliwość walidacji bloków poza kolejnością -- możliwość uruchomienia węzła na sprzęcie z bardzo małymi wymaganiami sprzętowymi (np. na telefonie) +- węzły mogące działać przy bardzo niskich wymaganiach sprzętowych (np. na telefonach) - działanie węzła na tanich dyskach twardych ze względu na brak konieczności ich odczytu/zapisu na nich - kompatybilność z przyszłymi aktualizacjami kryptografii Ethereum @@ -66,13 +66,13 @@ Słaba bezstanowość wiąże się ze zmianami sposobu, w jaki węzły Ethereum **W słabej bezstanowości proponowanie bloków wymaga dostępu do pełnych danych stanu, ale weryfikowanie bloków nie wymaga żadnych danych stanu** -Aby mogło tak się stać, [drzewa Verkle](/roadmap/verkle-trees/) musiałyby być już wdrożone w klientach Ethereum. Drzewa Verkle są zastępczą strukturą danych do przechowywania danych o stanie Ethereum, która pozwala na przekazywanie małych, stałych rozmiarów „świadków” danych między użytkowników i wykorzystywanie ich do weryfikowania bloków zamiast weryfikowania bloków w lokalnych bazach danych. [Podział proponent-twórca](/roadmap/pbs/) jest wymagany również dlatego, że pozwala twórcom bloków być wyspecjalizowanymi węzłami z bardziej zaawansowanym sprzętem, a to oni właśnie wymagają dostępu do pełnych danych o stanie. +Aby do tego doszło, [drzewa Verkle](/roadmap/verkle-trees/) muszą już być zaimplementowane w klientach Ethereum. Drzewa Verkle są zastępczą strukturą danych do przechowywania danych o stanie Ethereum, która pozwala na przekazywanie małych, stałych rozmiarów „świadków” danych między użytkowników i wykorzystywanie ich do weryfikowania bloków zamiast weryfikowania bloków w lokalnych bazach danych. [Rozdział proponującego od budowniczego](/roadmap/pbs/) jest również wymagany, ponieważ pozwala to budowniczym bloków być wyspecjalizowanymi węzłami z mocniejszym sprzętem, a to właśnie one wymagają dostępu do pełnych danych stanu. - + Bezstanowość polega na tym, że twórcy bloków utrzymują kopię pełnych danych o stanie, tak aby mogli generować świadków, których można by wykorzystać do zweryfikowania bloku. Inne węzły nie musiałyby mieć dostępu do danych o stanie; wszystkie informacje wymagane do zweryfikowania bloku byłyby dostępne w świadku. Stwarza to sytuację, w której proponowanie bloku jest drogie, natomiast weryfikowanie bloku jest tanie, co oznacza, że mniej operatorów będzie uruchamiać węzeł proponowania bloków. Jednakże decentralizacja proponentów bloków nie jest kluczowa, o ile jak największa ilość uczestników może niezależnie weryfikować, że proponowane bloki są ważne. -Poczytaj więcej o uwagach Dankrad'a +Poczytaj więcej w notatkach Dankrada Proponenci bloków używają danych o stanie do stworzenia „świadków” — minimalnego zestawu danych udowadniających wartości stanu, które zmieniają się w wyniku transakcji w bloku. Inni walidatorzy nie przechowują stanu, przechowują jedynie korzeń stanu (hash całego stanu). Otrzymują blok oraz świadka, po czym wykorzystują te dwie rzeczy do zaktualizowania swojego korzenia stanu. To sprawia, że węzeł walidacyjny jest bardzo lekki. @@ -87,17 +87,19 @@ Silna bezstanowość była badana przez badaczy, ale nie oczekuje się, że będ ## Aktualny postęp {#current-progress} -Słaba bezstanowość, wygasanie historii oraz wygasanie stanu są nadal w fazie badań i oczekuje się, że zostaną wdrożone za kilka lat. Nie ma gwarancji, że wszystkie te propozycje zostaną wdrożone; jeśli na przykład wygasanie stanu zostanie wdrożone jako pierwsze, może nie być konieczne jednoczesne wdrażanie wygasania historii. Istnieją również inne elementy planu działania, takie jak [drzewa Verkle](/roadmap/verkle-trees) czy [podział proponent-twórca](/roadmap/pbs), które należałoby ukończyć w pierwszej kolejności. +Słaba bezstanowość, wygasanie historii oraz wygasanie stanu są nadal w fazie badań i oczekuje się, że zostaną wdrożone za kilka lat. Nie ma gwarancji, że wszystkie te propozycje zostaną wdrożone; jeśli na przykład wygasanie stanu zostanie wdrożone jako pierwsze, może nie być konieczne jednoczesne wdrażanie wygasania historii. Istnieją również inne elementy planu działania, takie jak [drzewa Verkle](/roadmap/verkle-trees/) i [rozdział proponującego od budowniczego](/roadmap/pbs/), które muszą najpierw zostać ukończone. ## Dalsza lektura {#further-reading} -- [AMA bezstanowości Vitalika](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/) -- [Teoria zarządzania wielkością stanu](https://hackmd.io/@vbuterin/state_size_management) -- [Konflikt wskrzeszania zminimalizował ograniczanie stanu](https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739) -- [Drogi do bezstanowości i wygasania stanu](https://hackmd.io/@vbuterin/state_expiry_paths) +- [Czym jest bezstanowe Ethereum?](https://stateless.fyi/) +- [AMA Vitalika na temat bezstanowości](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/) +- [Teoria zarządzania rozmiarem stanu](https://hackmd.io/@vbuterin/state_size_management) +- [Resurrection-conflict-minimized state bounding](https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739) +- [Ścieżki do bezstanowości i wygasania stanu](https://hackmd.io/@vbuterin/state_expiry_paths) - [Specyfikacja EIP-4444](https://eips.ethereum.org/EIPS/eip-4444) - [Alex Stokes o EIP-4444](https://youtu.be/SfDC_qUZaos) -- [Dlaczego, przejście na bezstanowość jest takie ważne](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html) -- [Uwagi do oryginalnej koncepcji klienta bezstanowego](https://ethresear.ch/t/the-stateless-client-concept/172) -- [Więcej o wygasaniu stanu](https://hackmd.io/@vbuterin/state_size_management#A-more-moderate-solution-state-expiry) -- [Jeszcze więcej o wygasaniu stanu](https://hackmd.io/@vbuterin/state_expiry_paths#Option-2-per-epoch-state-expiry) +- [Dlaczego tak ważne jest przejście na bezstanowość](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html) +- [Oryginalne notatki dotyczące koncepcji klienta bezstanowego](https://ethresear.ch/t/the-stateless-client-concept/172) +- [Więcej na temat wygasania stanu](https://hackmd.io/@vbuterin/state_size_management#A-more-moderate-solution-state-expiry) +- [Jeszcze więcej na temat wygasania stanu](https://hackmd.io/@vbuterin/state_expiry_paths#Option-2-per-epoch-state-expiry) +- [Strona informacyjna o bezstanowym Ethereum](https://stateless.fyi) diff --git a/public/content/translations/pl/roadmap/user-experience/index.md b/public/content/translations/pl/roadmap/user-experience/index.md index 7ffb1894116..a8ffa7d7892 100644 --- a/public/content/translations/pl/roadmap/user-experience/index.md +++ b/public/content/translations/pl/roadmap/user-experience/index.md @@ -1,19 +1,19 @@ --- -title: Poprawa doświadczenia użytkownika -description: Korzystanie z Ethereum jest nadal zbyt skomplikowane dla większości osób. Aby zachęcić do masowej adaptacji, Ethereum musi drastycznie obniżyć bariery wejścia — użytkownicy muszą uzyskać korzyści ze zdecentralizowanego, niewymagającego uprawnień i odpornego na cenzurę dostępu do Ethereum, ale musi on być tak samo płynny, jak korzystanie z tradycyjnej aplikacji web2. +title: "Poprawa doświadczenia użytkownika" +description: "Korzystanie z Ethereum jest nadal zbyt skomplikowane dla większości osób. Aby zachęcić do masowej adaptacji, Ethereum musi drastycznie obniżyć bariery wejścia — użytkownicy muszą uzyskać korzyści ze zdecentralizowanego, niewymagającego uprawnień i odpornego na cenzurę dostępu do Ethereum, ale musi on być tak samo płynny, jak korzystanie z tradycyjnej aplikacji web2." lang: pl image: /images/roadmap/roadmap-ux.png alt: "Plan działania Ethereum" template: roadmap --- -**Korzystanie z Ethereum musi być uproszczone**; od zarządzania [kluczami](/glossary/#key) i [portfelami](/glossary/#wallet) po inicjowanie transakcji. Aby ułatwić masową adaptację, Ethereum musi drastycznie zwiększyć łatwość użytkowania, umożliwiając użytkownikom doświadczenie niewymagającego uprawnień i odpornego na cenzurę dostępu do Ethereum, z płynnym korzystaniem z aplikacji [Web2](/glossary/#web2). +**Korzystanie z Ethereum musi być uproszczone**; od zarządzania [kluczami](/glossary/#key) i [portfelami](/glossary/#wallet) po inicjowanie transakcji. Aby ułatwić masową adopcję, Ethereum musi drastycznie zwiększyć łatwość użytkowania, umożliwiając użytkownikom dostęp do Ethereum bez zezwoleń i odporny na cenzurę, z płynnością znaną z aplikacji [Web2](/glossary/#web2). -## Poza frazami seed {#no-more-seed-phrases} +## Koniec z frazami odzyskiwania {#no-more-seed-phrases} Konta Ethereum są chronione przez parę kluczy używanych do identyfikacji kont (klucz publiczny) i podpisywania wiadomości (klucz prywatny). Klucz prywatny jest jak hasło główne; umożliwia pełny dostęp do konta Ethereum. Jest to inny sposób działania dla osób bardziej zaznajomionych z bankami i aplikacjami Web2, które zarządzają kontami w imieniu użytkownika. Aby Ethereum osiągnęło masową adaptację bez polegania na scentralizowanych stronach trzecich, musi istnieć prosty, płynny sposób, aby użytkownik mógł przejąć opiekę nad swoimi aktywami i zachować kontrolę nad swoimi danymi bez konieczności rozumienia kryptografii klucza publicznego i prywatnego oraz zarządzania kluczami. -Rozwiązaniem tego problemu jest wykorzystanie portfeli [inteligentnych kontraktów](/glossary/#smart-contract) do interakcji z Ethereum. Portfele inteligentnych kontraktów tworzą sposoby ochrony kont w przypadku zgubienia lub kradzieży kluczy, możliwości lepszego wykrywania oszustw i obrony, a także pozwalają portfelom uzyskać nowe funkcje. Chociaż portfele inteligentnych kontraktów istnieją już dziś, są one trudne do zbudowania, ponieważ protokół Ethereum musi je lepiej wspierać. To dodatkowe wsparcie jest znane jako abstrakcja kont. +Rozwiązaniem tego problemu jest wykorzystanie portfeli opartych na [inteligentnych kontraktach](/glossary/#smart-contract) do interakcji z Ethereum. Portfele inteligentnych kontraktów tworzą sposoby ochrony kont w przypadku zgubienia lub kradzieży kluczy, możliwości lepszego wykrywania oszustw i obrony, a także pozwalają portfelom uzyskać nowe funkcje. Chociaż portfele inteligentnych kontraktów istnieją już dziś, są one trudne do zbudowania, ponieważ protokół Ethereum musi je lepiej wspierać. To dodatkowe wsparcie jest znane jako abstrakcja kont. Więcej na temat abstrakcji kont @@ -21,7 +21,7 @@ Rozwiązaniem tego problemu jest wykorzystanie portfeli [inteligentnych kontrakt Użytkownicy uruchamiający [węzły](/glossary/#node) nie muszą ufać stronom trzecim w zakresie dostarczania im danych i mogą szybko, prywatnie i bez pozwolenia wchodzić w interakcje z [blockchainem](/glossary/#blockchain) Ethereum. Jednak obecnie uruchomienie węzła wymaga wiedzy technicznej i znacznej ilości miejsca na dysku, co oznacza, że wiele osób musi zaufać pośrednikom. -Istnieje kilka aktualizacji, dzięki którym uruchamianie węzłów będzie znacznie łatwiejsze i mniej zasobochłonne. Sposób przechowywania danych zostanie zmieniony na bardziej efektywną przestrzennie strukturę znaną jako **drzewo Verkle**. Ponadto, dzięki [bezstanowości](/roadmap/statelessness) lub [wygasaniu danych](/roadmap/statelessness/#data-expiry), węzły Ethereum nie będą musiały przechowywać kopii wszystkich danych stanu Ethereum, co radykalnie zmniejszy zapotrzebowanie na miejsce na dysku twardym. [Lekkie węzły](/developers/docs/nodes-and-clients/light-clients/) będą oferować wiele korzyści płynących z uruchomienia pełnego węzła, ale można je łatwo uruchamiać na telefonach lub w prostych aplikacjach przeglądarkowych. +Istnieje kilka aktualizacji, dzięki którym uruchamianie węzłów będzie znacznie łatwiejsze i mniej zasobochłonne. Sposób przechowywania danych zostanie zmieniony na bardziej efektywną przestrzennie strukturę znaną jako **drzewo Verkle**. Ponadto, dzięki [bezstanowości](/roadmap/statelessness) lub [wygasaniu danych](/roadmap/statelessness/#data-expiry), węzły Ethereum nie będą musiały przechowywać kopii wszystkich danych stanu Ethereum, co radykalnie zmniejszy zapotrzebowanie na miejsce na dysku twardym. [Lekkie węzły](/developers/docs/nodes-and-clients/light-clients/) będą oferować wiele korzyści płynących z uruchomienia pełnego węzła, ale można je łatwo uruchamiać na telefonach komórkowych lub w prostych aplikacjach przeglądarkowych. Przeczytaj o drzewach Verkle @@ -31,6 +31,6 @@ Dzięki tym aktualizacjom bariery związane z uruchomieniem węzła są skuteczn Portfele inteligentnych kontraktów są już dostępne, ale wymaganych jest więcej aktualizacji, aby stały się one w jak największym stopniu zdecentralizowane i pozbawione uprawnień. EIP-4337 to dopracowana propozycja, która nie wymaga żadnych zmian w protokole Ethereum. Główny inteligentny kontrakt wymagany dla EIP-4337 został **wdrożony w marcu 2023 roku**. -**Pełna bezstanowość wciąż znajduje się w fazie badań** i prawdopodobnie dzieli nas kilka lat od jej wdrożenia. Istnieje kilka kamieni milowych na drodze do pełnej bezstanowości, w tym wygasanie danych, które można wdrożyć wcześniej. Inne elementy planu działania, takie jak [drzewa Verkle](/roadmap/verkle-trees/) i [podział proponent-twórca](/roadmap/pbs/) muszą zostać ukończone w pierwszej kolejności. +**Pełna bezstanowość wciąż znajduje się w fazie badań** i prawdopodobnie dzieli nas kilka lat od jej wdrożenia. Istnieje kilka kamieni milowych na drodze do pełnej bezstanowości, w tym wygasanie danych, które można wdrożyć wcześniej. Inne elementy planu działania, takie jak [drzewa Verkle](/roadmap/verkle-trees/) i [separacja propozytor-budowniczy](/roadmap/pbs/), muszą zostać najpierw ukończone. Sieci testowe drzewa Verkle są już uruchomione, a następną fazą jest uruchomienie klientów obsługujących drzewa Verkle w prywatnych, a następnie publicznych sieciach testowych. Możesz jeszcze bardziej przyspieszyć postęp wdrażając kontrakty do sieci testowych lub uruchamiając klientów sieci testowych. diff --git a/public/content/translations/pl/roadmap/verkle-trees/index.md b/public/content/translations/pl/roadmap/verkle-trees/index.md index 808806d9e66..53f12bbe3e3 100644 --- a/public/content/translations/pl/roadmap/verkle-trees/index.md +++ b/public/content/translations/pl/roadmap/verkle-trees/index.md @@ -1,6 +1,6 @@ --- title: Drzewa Verkle -description: Szczegółowy opis drzew Verkle oraz sposobu, w jaki zostaną wykorzystane do ulepszenia Ethereum +description: "Szczegółowy opis drzew Verkle oraz sposobu, w jaki zostaną wykorzystane do ulepszenia Ethereum" lang: pl summaryPoints: - Odkryj, czym są drzewa Verkle @@ -13,17 +13,16 @@ Drzewa Verkle (połączenie „Vector commitment” oraz „Merkle Trees”) to ## Bezstanowość {#statelessness} -Drzewa Verkle są kluczowym krokiem w drodze do bezstanowych klientów Ethereum. Bezstanowe klienty to takie, które nie muszą przechowywać całej bazy danych o stanie w celu walidacji nadchodzących bloków. Zamiast wykorzystywać własną lokalną kopię stanu Ethereum do weryfikacji bloków, bezstanowe klienty wykorzystują „świadka” do danych o stanie, który przychodzi z blokiem. Świadek jest zbiorem indywidualnych części danych o stanie, które są wymagane do wykonania określonego zestawu transakcji, oraz kryptograficznym dowodem na to, że świadek naprawdę jest częścią wszystkich danych. Świadek wykorzystywany jest _zamiast_ bazy danych o stanie. Aby to działało, świadkowie muszą być bardzo mali, tak aby można ich było bezpiecznie rozgłaszać w sieci w czasie umożliwiającym walidatorom przetworzenie ich w ciągu 12-sekundowego slotu. Obecna struktura danych o stanie nie jest odpowiednia, ponieważ świadkowie są zbyt duzi. Drzewa Verkle rozwiązują ten problem, zezwalając na małych świadków, co usuwa jedną z głównych przeszkód dla bezstanowych klientów. +Drzewa Verkle są kluczowym krokiem w drodze do bezstanowych klientów Ethereum. Bezstanowe klienty to takie, które nie muszą przechowywać całej bazy danych o stanie w celu walidacji nadchodzących bloków. Zamiast wykorzystywać własną lokalną kopię stanu Ethereum do weryfikacji bloków, bezstanowe klienty wykorzystują „świadka” do danych o stanie, który przychodzi z blokiem. Świadek jest zbiorem indywidualnych części danych o stanie, które są wymagane do wykonania określonego zestawu transakcji, oraz kryptograficznym dowodem na to, że świadek naprawdę jest częścią wszystkich danych. Świadek jest używany _zamiast_ bazy danych o stanie. Aby to działało, świadkowie muszą być bardzo mali, tak aby można ich było bezpiecznie rozgłaszać w sieci w czasie umożliwiającym walidatorom przetworzenie ich w ciągu 12-sekundowego slotu. Obecna struktura danych o stanie nie jest odpowiednia, ponieważ świadkowie są zbyt duzi. Drzewa Verkle rozwiązują ten problem, zezwalając na małych świadków, co usuwa jedną z głównych przeszkód dla bezstanowych klientów. - + Klienty Ethereum obecnie wykorzystują strukturę danych znaną jako drzewo trie Patricia Merkle do przechowywania swoich danych o stanie. Informacje o poszczególnych kontach są przechowywanie jako liście w drzewie trie, a pary liści są wielokrotnie hashowane, dopóki nie pozostanie tylko pojedynczy hash. Ten finałowy hash znany jest jako „korzeń”. Aby zweryfikować bloki, klienty Ethereum wykonują wszystkie transakcje w bloku i aktualizują swoje lokalne drzewo trie stanu. Blok uznawany jest za prawidłowy, jeśli korzeń lokalnego drzewa jest identyczny jak ten dostarczany przez proponenta bloku, ponieważ jakakolwiek różnica w obliczeniach wykonanych przez proponenta bloku oraz węzeł walidacyjny sprawiłaby, że hash korzenia byłby całkowicie inny. Problem polega tu na tym, że weryfikowanie blockchainu wymaga od każdego klienta przechowywania całęgo drzewa trie stanu dla najnowszego bloku oraz kilkunastu historycznych bloków (domyślnie w Geth przechowywane są dane o stanie dla 128 bloków znajdujących się za najnowszym blokiem). Wymaga to od klientów dostępu do dużej ilości miejsca na dysku, co jest barierą do uruchomiania pełnego węzła na tanim sprzęcie niemającym dużo mocy. Rozwiązaniem tego jest zaktualizowanie drzewa trie stanu do bardziej wydajnej struktury (drzewa Verkle), którą można podsumować przy użyciu małego „świadka” danych, którego można udostępnić zamiast pełnych danych o stanie. Przekształcenie danych o stanie w drzewo Verkle jest krokiem do przejścia do klientów bezstanowych. - ## Czym jest świadek i dlaczego ich potrzebujemy? {#what-is-a-witness} -Weryfikowanie bloku oznacza ponowne wykonanie transakcji zawartych w bloku, z zastosowaniem zmian do drzewa trie stanu Ethereum i obliczeniem nowego hasha korzenia. Zweryfikowany blok to taki, którego obliczony hash korzenia stanu jest taki sam jak ten dostarczony z blokiem (ponieważ oznacza to, że proponent bloku naprawdę wykonał obliczenia, o których mówi, że je wykonał). W obecnych klientach Ethereum aktualizowanie stanu wymaga dostępu do całego drzewa trie stanu, które jest dużą strukturą danych i musi być przechowywane lokalnie. Świadek zawiera tylko fragmenty danych o stanie, które są wymagane do wykonania transakcji w bloku. Walidator może następnie wykorzystać tylko te fragmenty do zweryfikowania, że proponent bloku wykonał transakcje w bloku i poprawnie zaktualizował stan. Oznacza to jednak, że świadek musi być rozsyłany między użytkownikami w sieci Ethereum wystarczająco szybko, aby każdy węzeł mógł go bezpiecznie otrzymać i przetworzyć w ciągu 12 sekund. Jeśli świadek jest za duży, pobranie go i nadążenie za łańcuchem może zająć niektórym węzłom zbyt długo. Jest to siła centralizująca, ponieważ tylko węzły z szybkim połączeniem internetowym mogą uczestniczyć w walidacji bloków. Dzięki drzewom Verkle nie jest konieczne przechowywanie stanu na swoim dysku twardym; _wszystko_ czego potrzebujesz, aby zweryfikować blok, znajduje się w samym bloku. Niestety świadkowie, którzy mogą zostać stworzeni przez drzewa trie Merkle, są zbyt duzi, aby obsługiwać bezstanowe klienty. +Weryfikowanie bloku oznacza ponowne wykonanie transakcji zawartych w bloku, z zastosowaniem zmian do drzewa trie stanu Ethereum i obliczeniem nowego hasha korzenia. Zweryfikowany blok to taki, którego obliczony hash korzenia stanu jest taki sam jak ten dostarczony z blokiem (ponieważ oznacza to, że proponent bloku naprawdę wykonał obliczenia, o których mówi, że je wykonał). W obecnych klientach Ethereum aktualizowanie stanu wymaga dostępu do całego drzewa trie stanu, które jest dużą strukturą danych i musi być przechowywane lokalnie. Świadek zawiera tylko fragmenty danych o stanie, które są wymagane do wykonania transakcji w bloku. Walidator może następnie wykorzystać tylko te fragmenty do zweryfikowania, że proponent bloku wykonał transakcje w bloku i poprawnie zaktualizował stan. Oznacza to jednak, że świadek musi być rozsyłany między użytkownikami w sieci Ethereum wystarczająco szybko, aby każdy węzeł mógł go bezpiecznie otrzymać i przetworzyć w ciągu 12 sekund. Jeśli świadek jest za duży, pobranie go i nadążenie za łańcuchem może zająć niektórym węzłom zbyt długo. Jest to siła centralizująca, ponieważ tylko węzły z szybkim połączeniem internetowym mogą uczestniczyć w walidacji bloków. Dzięki drzewom Verkle nie ma potrzeby przechowywania stanu na dysku twardym; _wszystko_, czego potrzebujesz do zweryfikowania bloku, jest zawarte w samym bloku. Niestety świadkowie, którzy mogą zostać stworzeni przez drzewa trie Merkle, są zbyt duzi, aby obsługiwać bezstanowe klienty. ## Dlaczego drzewa Verkle pozwalają na mniejszych świadków? {#why-do-verkle-trees-enable-smaller-witnesses} @@ -34,33 +33,32 @@ W schemacie zobowiązania wielomianowego świadkowie mają rozsądne rozmiary, k Rozmiar świadka różni się w zależności od liczby liści, które zawiera. Zakładając, że świadek obejmuje 1000 liści, świadek w drzewie trie Merkle zajmowałby około 3,5 MB (przy założeniu 7 poziomów w drzewie trie). Świadek takich samych danych w drzewie Verkle (przy założeniu 4 poziomów w drzewie) zajmowałby około 150 kB — **około 23 razy mniej**. To zmniejszenie rozmiaru świadka zezwoli na dopuszczalnie małe rozmiary świadków bezstanowych klientów. Świadkowie wielomianowi zajmują 0,128-1 kB w zależności od tego, które konkretne zobowiązanie wielomianowe zostało wykorzystane. - ## Jaka jest struktura drzewa Verkle? {#what-is-the-structure-of-a-verkle-tree} -Drzewa Verkle to pary `(key,value)`, w których klucze są 32-bajtowymi elementami składającymi się z 31-bajtowego _rdzenia_ oraz pojedynczego bajtu jako _sufiksu_. Klucze te są dzielą się na węzły _rozszerzeń_ oraz węzły _wewnętrzne_. Węzły rozszerzeń reprezentują pojedynczy rdzeń dla 256 potomków z różnymi sufiksami. Węzły wewnętrzne również mają 256 potomków, ale mogą nimi być inne węzły rozszerzeń. Główna różnica między strukturą drzewa Verkle a drzewa Merkle jest taka, że drzewo Verkle jest znacznie bardziej płaskie, co oznacza, że istnieje mniej węzłów pośrednich łączących liście z korzeniem, co sprawia, że potrzebna jest mniejsza ilość danych do wygenerowania dowodu. +Drzewa Verkle to pary `(key,value)`, gdzie klucze są 32-bajtowymi elementami złożonymi z 31-bajtowego _rdzenia_ i jednobajtowego _sufiksu_. Klucze te są zorganizowane w węzły _rozszerzeń_ i węzły _wewnętrzne_. Węzły rozszerzeń reprezentują pojedynczy rdzeń dla 256 potomków z różnymi sufiksami. Węzły wewnętrzne również mają 256 potomków, ale mogą nimi być inne węzły rozszerzeń. Główna różnica między strukturą drzewa Verkle a drzewa Merkle jest taka, że drzewo Verkle jest znacznie bardziej płaskie, co oznacza, że istnieje mniej węzłów pośrednich łączących liście z korzeniem, co sprawia, że potrzebna jest mniejsza ilość danych do wygenerowania dowodu. ![](./verkle.png) -[Poczytaj więcej o strukturze drzew Verkle](https://blog.ethereum.org/2021/12/02/verkle-tree-structure) +[Przeczytaj więcej o strukturze drzew Verkle](https://blog.ethereum.org/2021/12/02/verkle-tree-structure) ## Aktualny postęp {#current-progress} Sieci testowe drzew Verkle są już dostępne, ale wciąż istnieją spore zaległości co do aktualizacji klientów, które są wymagane do obsługi drzew Verkle. Możesz jeszcze bardziej przyspieszyć postęp wdrażając kontrakty do sieci testowych lub uruchamiając klientów sieci testowych. -[Odkryj sieć testową Verkle Gen Devnet 2](https://verkle-gen-devnet-2.ethpandaops.io/) - -[Zobacz jak Guillaume Ballet objaśnia sieć testową Verkle Condrieu](https://www.youtube.com/watch?v=cPLHFBeC0Vg) (zaznaczamy, że sieć testowa Condrieu stanowiła proof-of-work i została zastąpiona przez sieć testową Verkle Gen Devnet 2). +[Zobacz, jak Guillaume Ballet wyjaśnia sieć testową Condrieu Verkle](https://www.youtube.com/watch?v=cPLHFBeC0Vg) (pamiętaj, że sieć testowa Condrieu była oparta na mechanizmie proof-of-work i została zastąpiona siecią testową Verkle Gen Devnet 6). ## Dalsza lektura {#further-reading} - [Drzewa Verkle dla bezstanowości](https://verkle.info/) -- [Dankrad Feist wyjaśnia czym są drzewa Verkle w PEEPanEIP](https://www.youtube.com/watch?v=RGJOQHzg3UQ) +- [Dankrad Feist wyjaśnia drzewa Verkle w PEEPanEIP](https://www.youtube.com/watch?v=RGJOQHzg3UQ) +- [Drzewa Verkle dla reszty z nas](https://web.archive.org/web/20250124132255/https://research.2077.xyz/verkle-trees) +- [Anatomia dowodu Verkle](https://ihagopian.com/posts/anatomy-of-a-verkle-proof) - [Guillaume Ballet wyjaśnia drzewa Verkle na ETHGlobal](https://www.youtube.com/watch?v=f7bEtX3Z57o) -- [„Jak drzewa Verkle sprawiają, że Ethereum jest w dobrej kondycji” — Guillaume Ballet na Devcon 6](https://www.youtube.com/watch?v=Q7rStTKwuYs) -- [Piper Merriam o bezstanowych klientach na ETHDenver 2020](https://www.youtube.com/watch?v=0yiZJNciIJ4) -- [Dankrad Fiest objaśnia drzewa Verkle i bezstanowość w podcaście Zero Knowledge](https://zeroknowledge.fm/podcast/202/) +- [„Jak drzewa Verkle sprawiają, że Ethereum jest w dobrej kondycji” – Guillaume Ballet na Devcon 6](https://www.youtube.com/watch?v=Q7rStTKwuYs) +- [Piper Merriam o klientach bezstanowych z ETHDenver 2020](https://www.youtube.com/watch?v=0yiZJNciIJ4) +- [Dankrad Fiest wyjaśnia drzewa Verkle i bezstanowość w podcaście Zero Knowledge](https://zeroknowledge.fm/podcast/202/) - [Vitalik Buterin o drzewach Verkle](https://vitalik.eth.limo/general/2021/06/18/verkle.html) - [Dankrad Feist o drzewach Verkle](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html) - [Dokumentacja EIP drzew Verkle](https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Illustration) diff --git a/public/content/translations/pl/security/index.md b/public/content/translations/pl/security/index.md index f8c638981f6..75a7b4d5055 100644 --- a/public/content/translations/pl/security/index.md +++ b/public/content/translations/pl/security/index.md @@ -1,6 +1,6 @@ --- -title: Bezpieczeństwo Ethereum i zapobieganie oszustwom -description: Bądź bezpieczny na Ethereum +title: "Bezpieczeństwo Ethereum i zapobieganie oszustwom" +description: "Bądź bezpieczny na Ethereum" lang: pl --- @@ -8,11 +8,13 @@ lang: pl Zwiększające się zainteresowanie kryptowalutami niesie ze sobą rosnące ryzyko ze strony oszustów i hakerów. Ten artykuł przedstawia kilka najlepszych praktyk w celu ograniczenia tego ryzyka. +**Pamiętaj: nikt z zespołu ethereum.org nigdy się z Tobą nie skontaktuje. Nie odpowiadaj na żadne wiadomości e-mail, które rzekomo pochodzą od oficjalnego wsparcia Ethereum.** + -## Bezpieczeństwo kryptograficzne 101 {#crypto-security} +## Bezpieczeństwo kryptowalut 101 {#crypto-security} -### Podnieś poziom swojej wiedzy {#level-up-your-knowledge} +### Poszerz swoją wiedzę {#level-up-your-knowledge} Nieporozumienia co do tego, jak działają kryptowaluty, mogą prowadzić do kosztownych błędów. Na przykład, jeśli ktoś udaje agenta obsługi klienta, który może zwrócić utracone ETH w zamian za Twoje klucze prywatne, to po prostu żeruje na ludziach, którzy nie rozumieją, że Ethereum jest zdecentralizowaną siecią pozbawioną tego rodzaju funkcji. Edukowanie się na temat działania Ethereum jest opłacalną inwestycją. @@ -21,7 +23,7 @@ Nieporozumienia co do tego, jak działają kryptowaluty, mogą prowadzić do kos - Czym jest eter? + Czym jest ether? @@ -37,7 +39,7 @@ Klucz prywatny do portfela to hasło do Twojego portfela Ethereum. Jest to jedyn Czym jest portfel Ethereum? -#### Nie rób zrzutów ekranu swojej frazy ziarna ani kluczy prywatnych {#screenshot-private-keys} +#### Nie rób zrzutów ekranu swoich fraz seed/kluczy prywatnych {#screenshot-private-keys} Robiąc zrzut ekranu swojej frazy ziarna lub kluczy prywatnych, ryzykujesz synchronizacją ich z chmurą i potencjalnym udostępnieniem ich hakerom. Uzyskanie kluczy prywatnych z chmury jest częstym celem ataku hakerów. @@ -52,19 +54,20 @@ Przechowywanie kluczy prywatnych bez dostępu do Internetu znacznie zmniejsza ry - [Ledger](https://www.ledger.com/) - [Trezor](https://trezor.io/) -### Sprawdź podwójnie transakcje przed wysłaniem środków {#double-check-transactions} +### Sprawdzaj transakcje dwukrotnie przed ich wysłaniem {#double-check-transactions} -Przypadkowe wysłanie kryptowalut na niewłaściwy adres portfela jest częstym błędem. **Transakcja wysłana na Ethereum jest nieodwracalna.**Twoje środki będą możliwe do odzyskania tylko wtedy, gdy znasz właściciela i zdołasz go przekonać, aby wysłał Twoje środki do ciebie. +Przypadkowe wysłanie kryptowalut na niewłaściwy adres portfela jest częstym błędem. **Transakcja wysłana w sieci Ethereum jest nieodwracalna.** Jeśli nie znasz właściciela adresu i nie możesz go przekonać do odesłania środków, nie będziesz w stanie ich odzyskać. -Przed wysłaniem transakcji zawsze upewniaj się, że adres, na który wysyłasz, dokładnie odpowiada adresowi żądanego odbiorcy. Podczas interakcji z inteligentnym kontraktem warto przeczytać wiadomość transakcji przed złożeniem podpisu. +Przed wysłaniem transakcji zawsze upewniaj się, że adres, na który wysyłasz, dokładnie odpowiada adresowi żądanego odbiorcy. +Podczas interakcji z inteligentnym kontraktem warto przeczytać wiadomość transakcji przed złożeniem podpisu. -### Ustaw limit wydatków inteligentnego kontraktu {#spend-limits} +### Ustaw limity wydatków dla smart kontraktów {#spend-limits} Mając do czynienia z inteligentnymi kontraktami, nie zezwalaj na nieograniczone limity wydatków. Nieograniczone wydatki mogą umożliwić inteligentnemu kontraktowi opróżnienie portfela. Zamiast tego ustaw limity wydatków tylko do kwoty niezbędnej do przeprowadzenia transakcji. Wiele portfeli Ethereum oferuje ochronę limitów, aby zabezpieczyć się przed opróżnianiem kont. -[Jak unieważnić dostęp inteligentnych kontraktów do środków kryptowaluty](/guides/how-to-revoke-token-access/) +[Jak cofnąć dostęp smart kontraktu do Twoich środków krypto](/guides/how-to-revoke-token-access/) @@ -76,19 +79,19 @@ Całkowite zatrzymanie oszustów jest niemożliwe, ale możemy zmniejszyć ich s - nikt nie da Ci darmowego lub przecenionego ETH - nikt nie potrzebuje dostępu do Twoich kluczy prywatnych ani danych osobowych -### Wyłudzające reklamy na Twitterze/X {#ad-phishing} +### Phishing w reklamach na Twitterze {#ad-phishing} -![Wyłudzający link na Twitterze/X](./twitterPhishingScam.png) +![Phishing za pomocą linków na Twitterze](./twitterPhishingScam.png) -Istnieje metoda fałszowania funkcji podglądu linków Twittera (znanego również jako X), aby potencjalnie oszukać użytkowników, aby myśleli, że odwiedzają oficjalną stronę internetową. Technika ta wykorzystuje mechanizm Twittera do generowania podglądów adresów URL udostępnianych w tweetach i pokazuje na przykład _od ethereum.org_ (patrz wyżej), podczas gdy w rzeczywistości użytkownik zostaje przekierowany do fałszywej strony. +Istnieje metoda fałszowania funkcji podglądu linków Twittera (znanego również jako X), aby potencjalnie oszukać użytkowników, aby myśleli, że odwiedzają oficjalną stronę internetową. Ta technika wykorzystuje mechanizm Twittera do generowania podglądów adresów URL udostępnianych w tweetach i wyświetla na przykład _z ethereum.org_ (jak pokazano powyżej), podczas gdy w rzeczywistości użytkownik jest przekierowywany na złośliwą stronę. Zawsze sprawdzaj, czy jesteś na właściwej stronie internetowej, zwłaszcza po kliknięciu linku. [Więcej informacji tutaj](https://harrydenley.com/faking-twitter-unfurling). -### Oszustwa na konkurs {#giveaway} +### Oszustwo na giveaway {#giveaway} -Jednym z najczęstszych oszustw w kryptowalutach jest oszustwo na konkurs. Oszustwa na konkurs mogą przybierać różne formy, ale ogólne założenie jest takie, że jeśli wyślesz ETH na podany adres portfela, otrzymasz swoje ETH z powrotem, ale podwojone. *Z tego powodu jest również znane jako oszustwo 2 za 1.* +Jednym z najczęstszych oszustw w kryptowalutach jest oszustwo na konkurs. Oszustwa na konkurs mogą przybierać różne formy, ale ogólne założenie jest takie, że jeśli wyślesz ETH na podany adres portfela, otrzymasz swoje ETH z powrotem, ale podwojone._Z tego powodu jest również znane jako oszustwo 2 za 1._ Autorzy takich oszustw zwykle wyznaczają ograniczony czas na odebranie nagrody, aby stworzyć fałszywe poczucie pilności. @@ -98,23 +101,23 @@ Głośna wersja tej sytuacji miała miejsce w lipcu 2020 r., kiedy to konta na T ![Oszustwo na Twitterze](./appleTwitterScam.png) -### Konkursy celebrytów {#celebrity-giveaway} +### Giveaway z udziałem celebrytów {#celebrity-giveaway} -Konkursy celebrytów to kolejna popularna forma oszustwa związanego z konkursami. Oszuści biorą nagrany wywiad wideo lub rozmowę konferencyjną z celebrytą i transmitują ją na żywo na YouTubie — sprawiając, że wygląda to tak, jakby celebryta udzielał właśnie wywiadu wideo na żywo, w którym promuje giveaway na kryptowaluty. +Konkursy celebrytów to kolejna popularna forma oszustwa związanego z konkursami. Oszuści biorą nagrany wywiad wideo lub rozmowę konferencyjną z udziałem celebryty i transmitują ją na żywo na YouTubie, sprawiając wrażenie, że celebryta udziela wywiadu wideo na żywo, w którym promuje giveaway kryptowalutowy. -Vitalik Buterin jest najczęściej wykorzystywaną osobą w tym oszustwie, ale wiele innych znanych osób zaangażowanych w kryptowaluty jest również wykorzystywanych (np. Elon Musk lub Charles Hoskinson). Umieszczenie w transmisji na żywo znanej osoby daje oszustom poczucie wiarygodności (wygląda to podejrzanie, ale zaangażowany jest Vitalik, więc musi być w porządku!). +W tym oszustwie najczęściej wykorzystywany jest wizerunek Vitalika Buterina, ale wykorzystuje się także wizerunki wielu innych prominentnych osób ze świata krypto (np. Elona Muska czy Charlesa Hoskinsona). Umieszczenie w transmisji na żywo znanej osoby daje oszustom poczucie wiarygodności (wygląda to podejrzanie, ale zaangażowany jest Vitalik, więc musi być w porządku!). **Konkursy są zawsze oszustwami. Jeśli wyślesz swoje środki na te konta, stracisz je na zawsze.** -![Oszustwo na YouTubie](./youtubeScam.png) +![Oszustwo na YouTube](./youtubeScam.png) -### Fałszywa pomoc {#support-scams} +### Oszustwa na pomoc techniczną {#support-scams} Kryptowaluty to stosunkowo nowa i niezrozumiana technologia. Powszechnym oszustwem, które to wykorzystuje, jest oszustwo z pomocą techniczną, w którym oszuści podszywają się pod personel pomocy technicznej popularnych portfeli, giełd lub blockchainów. Duża część dyskusji o Ethereum odbywa się na Discordzie. Oszuści pomocy technicznej zazwyczaj znajdują swój cel, wyszukując pytania dotyczące pomocy technicznej na publicznych kanałach Discord, a następnie wysyłając pytającemu prywatną wiadomość, proponując pomoc. Wzbudzając zaufanie, oszuści próbują nakłonić użytkownika do ujawnienia kluczy prywatnych lub przesłania środków do swoich portfeli. -![Oszustwo pomocy technicznej na Discordzie](./discordScam.png) +![Oszustwo na pomoc techniczną na Discordzie](./discordScam.png) Zasadniczo pracownicy nigdy nie będą komunikować się z użytkownikiem za pośrednictwem prywatnych, nieoficjalnych kanałów. Kilka prostych rzeczy, o których należy pamiętać podczas korzystania z pomocy technicznej: @@ -126,18 +129,18 @@ Zasadniczo pracownicy nigdy nie będą komunikować się z użytkownikiem za po - Uwaga: chociaż oszustwa w stylu wsparcia technicznego często zdarzają się na Discordzie, mogą one również występować w innych aplikacjach komunikacyjnych, w których odbywają się dyskusje na temat kryptowalut, w tym w wiadomościach e-mail. + Uwaga: chociaż oszustwa polegające na podszywaniu się pod pomoc techniczną często zdarzają się na Discordzie, mogą być również powszechne we wszelkich aplikacjach czatowych, na których toczą się dyskusje o krypto, w tym w wiadomościach e-mail. ### Oszustwo na token „Eth2” {#eth2-token-scam} -W okresie przed [Połączeniem](/roadmap/merge/) oszuści wykorzystali zamieszanie wokół terminu „Eth2”, aby nakłonić użytkowników do wymiany ETH na token „ETH2”. Nie ma „ETH2” i żaden inny prawowity token nie został wprowadzony wraz z Połączeniem. ETH, które posiadałeś przed Połączeniem, jest teraz tym samym ETH. Nie ma **żadnej potrzeby podejmowania jakichkolwiek działań związanych z ETH na Twoim koncie w związku z przejściem z proof-of-work na proof-of-stake**. +W okresie poprzedzającym [Połączenie](/roadmap/merge/) oszuści wykorzystali zamieszanie wokół terminu „Eth2”, aby nakłonić użytkowników do wymiany ETH na token „ETH2”. Nie ma „ETH2” i żaden inny prawowity token nie został wprowadzony wraz z Połączeniem. ETH, które posiadałeś przed Połączeniem, jest teraz tym samym ETH. **Nie ma potrzeby podejmowania żadnych działań związanych z Twoimi ETH w związku z przejściem z dowodu pracy na dowód stawki**. -Oszuści mogą przedstawiać się jako „wsparcie”, informując, że jeśli zdeponujesz ETH, otrzymasz z powrotem „ETH2”. Nie ma [oficjalnego wsparcia Ethereum](/community/support/) i nie ma nowego tokena. Nigdy nie udostępniaj nikomu frazy ziarna swojego portfela. +Oszuści mogą przedstawiać się jako „wsparcie”, informując, że jeśli zdeponujesz ETH, otrzymasz z powrotem „ETH2”. Nie ma [oficjalnego wsparcia Ethereum](/community/support/), i nie ma nowego tokena. Nigdy nie udostępniaj nikomu frazy ziarna swojego portfela. -_Uwaga: Istnieją pochodne tokeny/skróty, które mogą reprezentować zestakowane ETH (tj. rETH z Rocket Pool, stETH z Lido, ETH2 z Coinbase), ale nie są one czymś, do czego trzeba „migrować”._ +_Uwaga: Istnieją tokeny pochodne/tickery, które mogą reprezentować zestakowane ETH (tj. rETH z Rocket Pool, stETH z Lido, ETH2 z Coinbase), ale nie jest to coś, do czego trzeba "migrować"._ ### Oszustwa phishingowe {#phishing-scams} @@ -153,7 +156,7 @@ Jeśli otrzymasz wiadomość e-mail od nieznanego nadawcy, pamiętaj: [Więcej o unikaniu oszustw phishingowych](https://support.mycrypto.com/staying-safe/mycrypto-protips-how-not-to-get-scammed-during-ico) -### Oszustwo pośredników handlu kryptowalutami {#broker-scams} +### Oszustwa z udziałem brokerów handlujących kryptowalutami {#broker-scams} Fałszywi pośrednicy handlu kryptowalutami podają się za wyspecjalizowanych pośredników kryptowalutowych, którzy oferują przejęcie Twoich pieniędzy i zainwestowanie ich w Twoim imieniu. Po tym, jak oszust otrzyma Twoje środki, może Cię zachęcić do przesłania większej ilości środków, abyś nie przegapił dalszych potencjalnych zysków w przyszłości, lub może całkowicie zniknąć. @@ -161,9 +164,9 @@ Tacy oszuści często znajdują swoje cele, wykorzystując fałszywe konta na Yo **Nie ufaj nieznajomym z Internetu, że zainwestują w Twoim imieniu. Stracisz swoje kryptowaluty.** -![Oszustwo pośrednika handlowego na YouTubie](./brokerScam.png) +![Oszustwo z udziałem brokera na YouTube](./brokerScam.png) -### Oszustwa pul wydobywania kryptowalut {#mining-pool-scams} +### Oszustwa związane z pulami wydobywczymi krypto {#mining-pool-scams} Od września 2022 r. wydobywanie Ethereum nie jest już możliwe. Jednak oszustwa związane z pulami wydobywczymi nadal istnieją. Oszustwa pul wydobywczych polegają na tym, że ludzie kontaktują się z tobą bez zaproszenia i twierdzą, że możesz osiągnąć duże zyski, dołączając do puli wydobywczej Ethereum. Oszust będzie przedstawiał swoje argumenty i pozostawał z tobą w kontakcie tak długo, jak będzie to konieczne. Zasadniczo oszust będzie próbował przekonać Cię, że kiedy dołączysz do puli wydobywczej Ethereum, Twoja kryptowaluta zostanie wykorzystana do stworzenia ETH i że otrzymasz wynagrodzenie w postaci ETH. Zobaczysz wtedy, że Twoja kryptowaluta generuje niewielkie zyski. Ma to na celu skłonienie użytkownika do zainwestowania większej kwoty. Ostatecznie wszystkie Twoje środki zostaną wysłane na nieznany adres, a oszust albo zniknie, albo w niektórych przypadkach będzie nadal w kontakcie, jak miało to miejsce w niedawnym przypadku. @@ -175,17 +178,17 @@ Kilka rzeczy do zapamiętania: - Przeprowadź swoje własne badania na temat stakingu, pul płynności lub innych sposobów inwestowania w kryptowaluty - Rzadko, jeśli w ogóle, takie schematy są prawdziwe. Gdyby tak było, prawdopodobnie byłyby powszechne i na pewno byś o nich słyszał. -[Mężczyzna traci 200 tys. dolarów w wyniku oszustwa z pulą wydobywczą](https://www.reddit.com/r/CoinBase/comments/r0qe0e/scam_or_possible_incredible_payout/) +[Mężczyzna stracił 200 tys. dolarów w oszustwie związanym z pulą wydobywczą](https://www.reddit.com/r/CoinBase/comments/r0qe0e/scam_or_possible_incredible_payout/) -### Oszustwa airdrop {#airdrop-scams} +### Oszustwa na airdropy {#airdrop-scams} Oszustwa airdrop polegają na tym, że oszust zrzuca zasób (NFT, token) do portfela użytkownika i wysyła użytkownikowi fałszywą stronę w celu odebrania zrzuconego zasobu. Podczas próby odebrania zasobu zostaniesz poproszony o zalogowanie się do portfela Ethereum i „zatwierdzenie” transakcji. Transakcja ta stanowi zagrożenie dla konta użytkownika, wysyłając klucze publiczne i prywatne do oszusta. Alternatywna forma tego oszustwa może wymagać potwierdzenia transakcji, która wysyła środki na konto oszusta. -[Więcej o oszustwach airdrop](https://www.youtube.com/watch?v=LLL_nQp1lGk) +[Więcej o oszustwach na airdropy](https://www.youtube.com/watch?v=LLL_nQp1lGk) -## Bezpieczeństwo sieci 101 {#web-security} +## Podstawy bezpieczeństwa w sieci {#web-security} ### Używaj silnych haseł {#use-strong-passwords} @@ -199,9 +202,9 @@ Przykład słabego hasła: CuteFluffyKittens! Przykład silnego hasła: ymv\*azu.EAC8eyp8umf ``` -Innym częstym błędem jest używanie haseł, które można łatwo odgadnąć lub poznać za sprawą [inżynierii społecznej](https://wikipedia.org/wiki/Social_engineering_(security)). Umieszczanie w haśle nazwiska panieńskiego matki, imion dzieci lub zwierząt domowych lub dat urodzenia zwiększa ryzyko złamania go. +Kolejnym częstym błędem jest używanie haseł, które można łatwo odgadnąć lub odkryć za pomocą [inżynierii społecznej](https://wikipedia.org/wiki/Social_engineering_\(security\)). Umieszczanie w haśle nazwiska panieńskiego matki, imion dzieci lub zwierząt domowych lub dat urodzenia zwiększa ryzyko złamania go. -#### Dobre praktyki haseł: {#good-password-practices} +#### Dobre praktyki dotyczące haseł: {#good-password-practices} - Zrób hasła tak długie, jak jest to tylko możliwe przez generator haseł lub wypełniany formularz - Użyj mieszaniny dużych liter, małych liter, liczb i symboli @@ -212,7 +215,7 @@ Innym częstym błędem jest używanie haseł, które można łatwo odgadnąć l ### Używaj unikalnych haseł do wszystkiego {#use-unique-passwords} -Silne hasło, które zostało ujawnione w wycieku danych nie jest już silnym hasłem. Strona internetowa [Have I Been Pwned](https://haveibeenpwned.com) pozwala sprawdzić, czy Twoje konta znalazły się w jakichkolwiek publicznych wyciekach danych. Jeśli tak się stało, **natychmiast zmień te hasła**. Używanie unikalnych haseł dla każdego konta zmniejsza ryzyko uzyskania przez hakerów dostępu do wszystkich Twoich kont, jeśli jedno z Twoich haseł zostanie ujawnione. +Silne hasło, które zostało ujawnione w wycieku danych nie jest już silnym hasłem. Strona internetowa [Have I Been Pwned](https://haveibeenpwned.com) pozwala sprawdzić, czy Twoje konta brały udział w jakichkolwiek publicznych wyciekach danych. Jeśli tak się stało, **natychmiast zmień te hasła**. Używanie unikalnych haseł dla każdego konta zmniejsza ryzyko uzyskania przez hakerów dostępu do wszystkich Twoich kont, jeśli jedno z Twoich haseł zostanie ujawnione. ### Używaj menedżera haseł {#use-password-manager} @@ -220,16 +223,16 @@ Silne hasło, które zostało ujawnione w wycieku danych nie jest już silnym ha - Korzystanie z menedżera haseł umożliwia tworzenie silnych, unikalnych haseł i ich zapamiętywanie! Zdecydowanie zalecamy korzystać z jednego z nich, a większość z nich jest bezpłatna! + Korzystanie z menedżera haseł umożliwia tworzenie silnych, unikalnych haseł i ich zapamiętywanie! Zdecydowanie zalecamy korzystanie z jednego, a większość z nich jest darmowa! Zapamiętywanie silnych, unikalnych haseł do każdego posiadanego konta nie jest idealnym rozwiązaniem. Menedżer haseł oferuje bezpieczny, zaszyfrowany magazyn dla wszystkich Twoich haseł, do którego można uzyskać dostęp za pomocą jednego silnego hasła głównego. Sugerują również silne hasła podczas rejestracji w nowym serwisie, aby nie trzeba było tworzyć własnych. Wiele menedżerów haseł poinformuje cię również, gdy Twoje dane znajdą się w wycieku danych, umożliwiając zmianę haseł, zanim dojdzie do jakichkolwiek złośliwych ataków. -![Przykład korzystania z menedżera haseł](./passwordManager.png) +![Przykład użycia menedżera haseł](./passwordManager.png) -#### Wypróbuj menedżera haseł: {#try-password-manager} +#### Wypróbuj menedżer haseł: {#try-password-manager} - [Bitwarden](https://bitwarden.com/) - [KeePass](https://keepass.info/) @@ -238,26 +241,26 @@ Zapamiętywanie silnych, unikalnych haseł do każdego posiadanego konta nie jes ### Używaj uwierzytelniania dwuskładnikowego {#two-factor-authentication} -Czasami możemy zostać poproszeni o uwierzytelnienie swojej tożsamości za pomocą specjalnych dowodów. Są one znane jako **czynniki**. Trzy główne czynniki to: +Czasami możemy zostać poproszeni o uwierzytelnienie swojej tożsamości za pomocą specjalnych dowodów. Są one znane jako **składniki**. Trzy główne czynniki to: - Coś, co znasz (np. hasło lub pytanie zabezpieczające) - Coś, czym jesteś (np. odcisk palca lub skaner tęczówki/twarzy) - Coś, co posiadasz (klucz bezpieczeństwa lub aplikacja uwierzytelniająca w telefonie) -Stosowanie **uwierzytelnienia dwuskładnikowego (2FA)** wprowadza dodatkowy *czynnik bezpieczeństwa*  dla Twoich kont online. 2FA gwarantuje, że samo posiadanie hasła nie wystarczy, aby uzyskać dostęp do konta. Najczęściej drugim czynnikiem jest losowy 6-cyfrowy kod, znany jako **jednorazowe hasło czasowe (TOTP)**, do którego można uzyskać dostęp za pośrednictwem aplikacji uwierzytelniającej, takiej jak Google Authenticator lub Authy. Działają one jako „coś, co posiadasz”, ponieważ ziarno, które generuje kod czasowy, jest przechowywane na twoim urządzeniu. +Używanie **uwierzytelniania dwuskładnikowego (2FA)** zapewnia dodatkowy _składnik bezpieczeństwa_ dla Twoich kont online. 2FA gwarantuje, że samo posiadanie hasła nie wystarczy, aby uzyskać dostęp do konta. Najczęściej drugim składnikiem jest losowy, 6-cyfrowy kod, znany jako **jednorazowe hasło czasowe (TOTP)**, do którego można uzyskać dostęp za pośrednictwem aplikacji uwierzytelniającej, takiej jak Google Authenticator lub Authy. Działają one jako „coś, co posiadasz”, ponieważ ziarno, które generuje kod czasowy, jest przechowywane na twoim urządzeniu. - Uwaga: korzystanie z 2FA opartego na wiadomościach SMS jest podatne na tzw. SIM jacking i nie jest bezpieczne. Dla najlepszej ochrony korzystaj z takich usług, jak Google Authenticator lub Authy. + Uwaga: Korzystanie z 2FA opartego na SMS-ach jest podatne na kradzież karty SIM (SIM jacking) i nie jest bezpieczne. Aby zapewnić sobie najlepsze bezpieczeństwo, korzystaj z usług takich jak Google Authenticator lub Authy. #### Klucze bezpieczeństwa {#security-keys} -Klucz bezpieczeństwa to bardziej zaawansowany i bezpieczny rodzaj 2FA. Klucze bezpieczeństwa to urządzenia do uwierzytelniania sprzętu fizycznego, które działają tak samo, jak aplikacje uwierzytelniające. Stosowanie klucza bezpieczeństwa jest najbezpieczniejszym sposobem korzystania z 2FA. Wiele z tych kluczy wykorzystuje standard FIDO Universal 2nd Factor (U2F). [Dowiedz się więcej o U2F od FIDO](https://www.yubico.com/authentication-standards/fido-u2f/). +Klucz bezpieczeństwa to bardziej zaawansowany i bezpieczny rodzaj 2FA. Klucze bezpieczeństwa to urządzenia do uwierzytelniania sprzętu fizycznego, które działają tak samo, jak aplikacje uwierzytelniające. Stosowanie klucza bezpieczeństwa jest najbezpieczniejszym sposobem korzystania z 2FA. Wiele z tych kluczy wykorzystuje standard FIDO Universal 2nd Factor (U2F). [Dowiedz się więcej o FIDO U2F](https://www.yubico.com/resources/glossary/fido-u2f/). Więcej na temat 2FA tutaj: @@ -267,36 +270,36 @@ Więcej na temat 2FA tutaj: Rozszerzenia przeglądarki, takie jak rozszerzenia Chrome lub dodatki do Firefoksa, mogą ulepszyć funkcjonalności przeglądarki, ale wiążą się z ryzykiem. Domyślnie większość rozszerzeń przeglądarki prosi o dostęp do „odczytu i zmiany danych witryny”, co pozwala im robić prawie wszystko z danymi użytkownika. Rozszerzenia Chrome są zawsze automatycznie aktualizowane, więc wcześniej bezpieczne rozszerzenie może zostać później zaktualizowane i zawierać złośliwy kod. Większość rozszerzeń przeglądarki nie próbuje wykraść Twoich danych, ale użytkownik powinien być świadomy, że mogą to zrobić. -#### Bądź bezpieczny: {#browser-extension-safety} +#### Zachowaj bezpieczeństwo: {#browser-extension-safety} - Instaluj rozszerzenia przeglądarki tylko z zaufanych źródeł - Usuwaj nieużywane rozszerzenia przeglądarki - Instaluj rozszerzenia Chrome lokalnie, aby zatrzymać ich automatyczne aktualizacje (zaawansowane) -[Więcej o zagrożeniach związanych z rozszerzeniami przeglądarki](https://www.kaspersky.co.uk/blog/browser-extensions-security/12750/) +[Więcej o ryzyku związanym z rozszerzeniami przeglądarki](https://www.kaspersky.co.uk/blog/browser-extensions-security/12750/) ## Dalsza lektura {#further-reading} -### Bezpieczeństwo sieci {#reading-web-security} +### Bezpieczeństwo w sieci {#reading-web-security} -- [Nawet 3 miliony urządzeń zainfekowanych złośliwym oprogramowaniem w dodatkach do Chrome i Edge](https://arstechnica.com/information-technology/2020/12/up-to-3-million-devices-infected-by-malware-laced-chrome-and-edge-add-ons/) — _Dan Goodin_ -- [Jak stworzyć silne hasło, którego nie zapomnisz](https://www.avg.com/en/signal/how-to-create-a-strong-password-that-you-wont-forget) — _AVG_ -- [Czym jest klucz bezpieczeństwa?](https://help.coinbase.com/en/coinbase/getting-started/verify-my-account/security-keys-faq) — _Coinbase_ +- [Do 3 milionów urządzeń zainfekowanych przez dodatki do Chrome i Edge zawierające złośliwe oprogramowanie](https://arstechnica.com/information-technology/2020/12/up-to-3-million-devices-infected-by-malware-laced-chrome-and-edge-add-ons/) – _Dan Goodin_ +- [Jak stworzyć silne hasło, którego nie zapomnisz](https://www.avg.com/en/signal/how-to-create-a-strong-password-that-you-wont-forget) – _AVG_ +- [Czym jest klucz bezpieczeństwa?](https://help.coinbase.com/en/coinbase/getting-started/verify-my-account/security-keys-faq) – _Coinbase_ -### Bezpieczeństwo kryptograficzne {#reading-crypto-security} +### Bezpieczeństwo kryptowalut {#reading-crypto-security} -- [Ochranianie siebie i swoich funduszy](https://support.mycrypto.com/staying-safe/protecting-yourself-and-your-funds) — _MyCrypto_ -- [Kwestie bezpieczeństwa w popularnym oprogramowaniu do komunikacji kryptograficznej](https://docs.salusec.io/untitled/web3-penetration-test/risks-in-social-media) — _Salus_ -- [Przewodnik bezpieczeństwa dla ludzi opornych i inteligentnych](https://medium.com/mycrypto/mycryptos-security-guide-for-dummies-and-smart-people-too-ab178299c82e) — _MyCrypto_ -- [Bezpieczeństwo kryptograficzne: hasła i uwierzytelnianie](https://www.youtube.com/watch?v=m8jlnZuV1i4) — _Andreas M. Antonopoulos_ +- [Ochrona siebie i swoich środków](https://support.mycrypto.com/staying-safe/protecting-yourself-and-your-funds) – _MyCrypto_ +- [Problemy z bezpieczeństwem w popularnym oprogramowaniu do komunikacji w świecie krypto](https://docs.salusec.io/untitled/web3-penetration-test/risks-in-social-media) – _Salus_ +- [Przewodnik po bezpieczeństwie dla opornych i bystrzaków](https://medium.com/mycrypto/mycryptos-security-guide-for-dummies-and-smart-people-too-ab178299c82e) – _MyCrypto_ +- [Bezpieczeństwo kryptowalut: hasła i uwierzytelnianie](https://www.youtube.com/watch?v=m8jlnZuV1i4) – _Andreas M. Antonopoulos_ -### Edukacja o oszustwach {#reading-scam-education} +### Edukacja na temat oszustw {#reading-scam-education} -- [Przewodnik: Jak zidentyfikować fałszywe tokeny](/guides/how-to-id-scam-tokens/) -- [Bądź bezpieczny: Najczęstsze oszustwa](https://support.mycrypto.com/staying-safe/common-scams) — _MyCrypto_ -- [Unikanie oszustw](https://bitcoin.org/en/scams) — _Bitcoin.org_ -- [Wątek na Twitterze o powszechnych wiadomościach phishingowych dotyczących kryptowalut](https://twitter.com/tayvano_/status/1516225457640787969) — _Taylor Monahan_ +- [Poradnik: jak rozpoznać oszukańcze tokeny](/guides/how-to-id-scam-tokens/) +- [Jak zachować bezpieczeństwo: Powszechne oszustwa](https://support.mycrypto.com/staying-safe/common-scams) – _MyCrypto_ +- [Unikanie oszustw](https://bitcoin.org/en/scams) – _Bitcoin.org_ +- [Wątek na Twitterze o powszechnych e-mailach i wiadomościach phishingowych w świecie krypto](https://twitter.com/tayvano_/status/1516225457640787969) – _Taylor Monahan_ diff --git a/public/content/translations/pl/smart-contracts/index.md b/public/content/translations/pl/smart-contracts/index.md index 18caf8180ae..20f1efe1511 100644 --- a/public/content/translations/pl/smart-contracts/index.md +++ b/public/content/translations/pl/smart-contracts/index.md @@ -1,14 +1,19 @@ --- title: Inteligentne kontrakty -description: Wprowadzenie do inteligentnych kontraktów w wersji nietechnicznej +metaTitle: "Inteligentne kontrakty — czym są i jakie są ich zalety" +description: "Wprowadzenie do inteligentnych kontraktów w wersji nietechnicznej" lang: pl --- # Wprowadzenie do inteligentnych kontraktów {#introduction-to-smart-contracts} +
+ +
+ Inteligentne kontrakty są podstawowymi elementami składowymi warstwy aplikacji Ethereum. Są to programy komputerowe przechowywane na [blockchainie](/glossary/#blockchain), które działają zgodnie z logiką „jeśli to, to tamto” i mają gwarancję działania zgodnie z zasadami określonymi przez ich kod, którego nie można zmienić po utworzeniu. -Termin „inteligentny kontrakt” stworzył Nick Szabo. W 1994 r. napisał [wprowadzenie do tej koncepcji](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html), a w 1996 r. opisał [badania na temat możliwości inteligentnych kontraktów i tego co mogą zrobić](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html). +Termin „inteligentny kontrakt” stworzył Nick Szabo. W 1994 r. napisał [wprowadzenie do koncepcji](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html), a w 1996 r. [analizę możliwości zastosowania inteligentnych kontraktów](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html). Szabo wyobraził sobie cyfrowy rynek, na którym automatyczne, [kryptograficznie bezpieczne](/glossary/#cryptography) procesy umożliwiają przeprowadzanie transakcji i funkcji biznesowych bez zaufanych pośredników. Inteligentne kontrakty na Ethereum wprowadzają tę wizję w życie. @@ -16,7 +21,7 @@ Zobacz, jak Finematics tłumaczy inteligentne kontrakty: -## Zaufanie do konwencjonalnych kontraktów {#trust-and-contracts} +## Zaufanie w przypadku konwencjonalnych umów {#trust-and-contracts} Jednym z największych problemów związanych z tradycyjnym kontraktem jest konieczność przestrzegania jego postanowień przez zaufane osoby. @@ -24,9 +29,9 @@ Oto przykład: Alicja i Bob urządzają sobie wyścig rowerowy. Załóżmy, że Alice założyła się z Bobem o 10 dolarów, że wygra wyścig. Bob jest przekonany, że to on będzie zwycięzcą, i przyjmuje zakład. Jednak Alice kończy wyścig znacznie przed Bobem i zdecydowanie wygrywa. Bob jednak odmawia wypłacenia pieniędzy z zakładu, twierdząc, że Alicja musiała oszukiwać. -Ten jaskrawy przykład ilustruje problem z dowolną umową nieinteligentną. Nawet jeśli warunki umowy zostaną spełnione (np. Ty jesteś zwycięzcą wyścigu), nadal musisz ufać innej osobie, że wywiąże się z umowy (np. wypłaci zakład). +Ten jaskrawy przykład ilustruje problem z dowolną umową nieinteligentną. Nawet jeśli warunki umowy zostaną spełnione (tzn. jesteś zwycięzcą wyścigu), nadal musisz ufać innej osobie, że wywiąże się z umowy (tzn. wypłaci wygraną z zakładu). -## Cyfrowy automat do sprzedaży {#vending-machine} +## Cyfrowy automat sprzedający {#vending-machine} Prostą metaforą inteligentnego kontraktu jest automat sprzedający, który działa nieco podobnie do inteligentnego kontraktu — określone wejścia gwarantują z góry określone wyjścia. @@ -48,7 +53,7 @@ Można na przykład napisać inteligentny kontrakt, który przechowuje środki f Tradycyjne kontrakty są niejednoznaczne, ponieważ polegają na interpretacji i realizacji zależnej od człowieka. Na przykład, dwóch sędziów może różnie interpretować kontrakt, co może prowadzić do niespójnych decyzji i niejednakowych wyników. Inteligentne kontrakty usuwają tę możliwość. Zamiast tego, inteligentne kontrakty wykonują dokładnie to, co zostało zapisane w kodzie kontraktu. Dokładność ta oznacza, że w takich samych okolicznościach inteligentny kontrakt wygeneruje taki sam wynik. -## Rekord publiczny {#public-record} +## Rejestr publiczny {#public-record} Inteligentne kontrakty są przydatne do celów kontroli i śledzenia. Ponieważ inteligentne kontrakty Ethereum znajdują się w publicznym blockchainie, każdy może natychmiast śledzić transfery aktywów i inne powiązane informacje. Możesz na przykład sprawdzić, czy ktoś wysłał pieniądze na Twój adres. @@ -56,27 +61,30 @@ Inteligentne kontrakty są przydatne do celów kontroli i śledzenia. Ponieważ Inteligentne kontrakty chronią również Twoją prywatność. Ponieważ Ethereum jest siecią pseudonimową (Twoje transakcje są związane publicznie z unikalnym adresem kryptograficznym, a nie z Twoją tożsamością), możesz chronić swoją prywatność przed obserwatorami. -## Widoczne terminy {#visible-terms} +## Widoczne warunki {#visible-terms} Wreszcie, podobnie jak w przypadku tradycyjnych kontraktów, możesz sprawdzić, co jest w inteligentnym kontrakcie, zanim go podpiszesz (lub wejdziesz z nim w interakcje w inny sposób). Przejrzystość inteligentnego kontraktu gwarantuje, że każdy może go przeanalizować. -## Przykłady wykorzystania inteligentnych kontraktów {#use-cases} +## Przypadki użycia inteligentnych kontraktów {#use-cases} Inteligentne kontrakty mogą robić zasadniczo wszystko, co robią programy komputerowe. -Mogą wykonywać obliczenia, tworzyć walutę, przechowywać dane, wybijać [NFT](/glossary/#nft), wysyłać komunikaty, a nawet generować grafikę. Oto kilka popularnych, rzeczywistych przykładów: +Mogą wykonywać obliczenia, tworzyć walutę, przechowywać dane, wybijać [NFT-y](/glossary/#nft), wysyłać komunikaty, a nawet generować grafikę. Oto kilka popularnych, rzeczywistych przykładów: - [Stablecoiny](/stablecoins/) - [Tworzenie i dystrybucja unikalnych zasobów cyfrowych](/nft/) -- [Automatyczna otwarta wymiana walut](/get-eth/#dex) -- [Zdecentralizowane gry](/apps/categories/gaming) -- [Polisa ubezpieczeniowa automatycznie wypłacająca odszkodowanie](https://etherisc.com/) -- [Standard umożliwiający tworzenie niestandardowych, interoperacyjnych walut](/developers/docs/standards/tokens/) +- [Automatyczna, otwarta wymiana walut](/get-eth/#dex) +- [Zdecentralizowany gaming](/apps/categories/gaming) +- [Polisa ubezpieczeniowa z automatyczną wypłatą odszkodowania](https://etherisc.com/) +- [Standard umożliwiający tworzenie dostosowanych, interoperacyjnych walut](/developers/docs/standards/tokens/) ## Dalsza lektura {#further-reading} - [Jak inteligentne kontrakty zmienią świat](https://www.youtube.com/watch?v=pA6CGuXEKtQ) -- [Inteligentne kontrakty: Technologia łańcucha bloków, która zastąpi prawników](https://blockgeeks.com/guides/smart-contracts/) -- [Inteligentne kontrakty dla programistów](/developers/docs/smart-contracts/) +- [Inteligentne kontrakty dla deweloperów](/developers/docs/smart-contracts/) - [Naucz się pisać inteligentne kontrakty](/developers/learning-tools/) -- [Mastering Ethereum - Co to jest inteligentny kontrakt?](https://github.com/ethereumbook/ethereumbook/blob/openedition/07smart-contracts-solidity.asciidoc#what-is-a-smart-contract) +- [Mastering Ethereum – Czym jest inteligentny kontrakt?](https://github.com/ethereumbook/ethereumbook/blob/openedition/07smart-contracts-solidity.asciidoc#what-is-a-smart-contract) + + + + diff --git a/public/content/translations/pl/social-networks/index.md b/public/content/translations/pl/social-networks/index.md index 82dc0dce834..e39f4a40e71 100644 --- a/public/content/translations/pl/social-networks/index.md +++ b/public/content/translations/pl/social-networks/index.md @@ -1,21 +1,21 @@ --- -title: Zdecentralizowane sieci społecznościowe -description: Przegląd zdecentralizowanych serwisów społecznościowych w Ethereum +title: "Zdecentralizowane sieci społecznościowe" +description: "Przegląd zdecentralizowanych serwisów społecznościowych w Ethereum" lang: pl template: use-cases emoji: ":mega:" sidebarDepth: 2 image: /images/ethereum-learn.png -summaryPoint1: Oparte na łańcuchu bloków platformy umożliwiające interakcje społeczne oraz tworzenie i rozpowszechnianie treści. -summaryPoint2: Zdecentralizowane sieci mediów społecznościowych zapewniają ochronę prywatności użytkowników i większe bezpieczeństwo danych. -summaryPoint3: Tokeny i NFT otwierają nowe możliwości monetyzacji treści. +summaryPoint1: "Oparte na łańcuchu bloków platformy umożliwiające interakcje społeczne oraz tworzenie i rozpowszechnianie treści." +summaryPoint2: "Zdecentralizowane sieci mediów społecznościowych zapewniają ochronę prywatności użytkowników i większe bezpieczeństwo danych." +summaryPoint3: "Tokeny i NFT otwierają nowe możliwości monetyzacji treści." --- Serwisy społecznościowe odgrywają ogromną rolę w naszej codziennej komunikacji i wzajemnych interakcjach. Scentralizowana kontrola takich serwisów jest jednak źródłem wielu problemów. Wycieki danych, przestoje serwerów, cenzurowanie treści czy naruszenia prywatności to tylko niektóre z nich. Aby stawić czoła tym wyzwaniom, deweloperzy tworzą serwisy społecznościowe, jako podstawę wykorzystując platformę Ethereum. Zdecentralizowane serwisy społecznościowe pozwalają wykluczyć większość problemów platform tradycyjnych, a przy tym zapewniają użytkownikom lepsze ogólne doświadczenia. ## Czym są zdecentralizowane serwisy społecznościowe? {#what-are-decentralized-social-networks} -Zdecentralizowane serwisy społecznościowe to [oparte na blockchainie](/glossary/#blockchain) platformy umożliwiające użytkownikom wymianę informacji oraz publikowanie treści i udostępnianie ich grupom odbiorców. Ponieważ aplikacje te oparte są na łańcuchu bloków, można je zdecentralizować, uodparniając je na próby cenzurowania treści i nadmierną kontrolę. +Zdecentralizowane sieci społecznościowe to platformy [oparte na blockchainie](/glossary/#blockchain), które umożliwiają użytkownikom wymianę informacji, a także publikowanie i dystrybuowanie treści wśród odbiorców. Ponieważ aplikacje te oparte są na łańcuchu bloków, można je zdecentralizować, uodparniając je na próby cenzurowania treści i nadmierną kontrolę. Wiele zdecentralizowanych serwisów społecznościowych funkcjonuje jako alternatywy dla platform konwencjonalnych, takich jak Facebook, LikedIn, Twitter i Medium. Serwisy społecznościowe oparte na łańcuchu bloków mają jednak wiele właściwości, które dają im przewagę nad platformami konwencjonalnymi. @@ -23,84 +23,118 @@ Wiele zdecentralizowanych serwisów społecznościowych funkcjonuje jako alterna ### Jak działają zdecentralizowane serwisy społecznościowe? {#decentralized-social-networks-overview} -Zdecentralizowane serwisy społecznościowe reprezentują klasę [aplikacji zdecentralizowanych (d-aplikacji)](/apps/), czyli aplikacji opartych na [inteligentnych kontraktach](/glossary/#smart-contract) wdrożonych w łańcuchu bloków. Kod kontraktu służy jako zaplecze (backend) tych aplikacji i określa ich logikę biznesową. +Zdecentralizowane sieci społecznościowe to klasa [aplikacji zdecentralizowanych (dapki)](/apps/) — aplikacji zasilanych [smart kontraktami](/glossary/#smart-contract) wdrożonymi na blockchainie. Kod kontraktu służy jako zaplecze (backend) tych aplikacji i określa ich logikę biznesową. -Konwencjonalne serwisy społecznościowe polegają na bazach danych, w których przechowywane są dane użytkowników, kod programu i inne rodzaje informacji. Skutkuje to jednak powstawaniem pojedynczych punktów awarii i wprowadza znaczne ryzyko. Za przykład może posłużyć głośny incydent z października 2021, kiedy to ze względu na [wielogodzinny przestój](https://www.npr.org/2021/10/05/1043211171/facebook-instagram-whatsapp-outage-business-impact) serwerów Facebooka użytkownicy zostali odcięci od platformy. +Konwencjonalne serwisy społecznościowe polegają na bazach danych, w których przechowywane są dane użytkowników, kod programu i inne rodzaje informacji. Skutkuje to jednak powstawaniem pojedynczych punktów awarii i wprowadza znaczne ryzyko. Na przykład serwery Facebooka [uległy niesławnej, wielogodzinnej awarii](https://www.npr.org/2021/10/05/1043211171/facebook-instagram-whatsapp-outage-business-impact) w październiku 2021 r., odcinając użytkowników od platformy. -Zdecentralizowane serwisy społecznościowe istnieją w [sieci typu peer-to-peer](/glossary/#peer-to-peer-network) i obejmują tysiące węzłów na całym świecie. Nawet jeśli niektóre węzły ulegną awarii, sieć będzie działać nieprzerwanie, dzięki czemu aplikacje będą odporne na awarie i przestoje. +Zdecentralizowane sieci społecznościowe istnieją w [sieci peer-to-peer](/glossary/#peer-to-peer-network) składającej się z tysięcy węzłów na całym świecie. Nawet jeśli niektóre węzły ulegną awarii, sieć będzie działać nieprzerwanie, dzięki czemu aplikacje będą odporne na awarie i przestoje. -Dzięki zdecentralizowanym systemom pamięci, takim jak [InterPlanetary File System (IPFS)](https://ipfs.io/), sieci społecznościowe zbudowane na Ethereum chronią dane użytkowników przed nadmiernym i złośliwym wykorzystywaniem. Tu nikt nie sprzedaje danych osobowych reklamodawcom, a hakerzy nie są w stanie wykraść poufnych informacji. +Korzystając ze zdecentralizowanych systemów przechowywania, takich jak [InterPlanetary File System (IPFS)](https://ipfs.io/), sieci społecznościowe zbudowane na Ethereum mogą chronić informacje użytkowników przed wykorzystaniem i złośliwym użyciem. Tu nikt nie sprzedaje danych osobowych reklamodawcom, a hakerzy nie są w stanie wykraść poufnych informacji. Wiele sieci społecznościowych opartych na łańcuchu bloków ma natywne tokeny, które umożliwiają zarabianie pieniędzy w przypadku braku dochodów z reklam. Użytkownicy mogą kupić te tokeny, aby uzyskać dostęp do określonych funkcji, zrealizować zakupy w aplikacji lub dać napiwek swoim ulubionym twórcom treści. -## Zalety zdecentralizowanych mediów społecznościowych {#benefits} +## Zalety zdecentralizowanych sieci społecznościowych {#benefits} -1. Zdecentralizowane media społecznościowe są odporne na cenzurę i otwarte dla wszystkich. Oznacza to, że **użytkowników nie można blokować**, usuwać z platformy ani ograniczać według własnego uznania. +1. Zdecentralizowane media społecznościowe są odporne na cenzurę i otwarte dla wszystkich. Oznacza to, że **użytkownicy nie mogą być blokowani**, usuwani z platformy ani ograniczani w sposób arbitralny. -2. Zdecentralizowane sieci społecznościowe są **oparte na zasadach open-source**. Oznacza to, że ich kod źródłowy jest ogólnie dostępny dla każdego. Eliminując wdrażanie nieprzejrzystych algorytmów powszechnych w tradycyjnych mediach społecznościowych, sieci społecznościowe oparte na łańcuchu bloków mogą pogodzić interesy użytkowników i twórców platformy. +2. Zdecentralizowane sieci społecznościowe są **zbudowane na ideałach open-source** i udostępniają kod źródłowy aplikacji do publicznego wglądu. Eliminując wdrażanie nieprzejrzystych algorytmów powszechnych w tradycyjnych mediach społecznościowych, sieci społecznościowe oparte na łańcuchu bloków mogą pogodzić interesy użytkowników i twórców platformy. -3. Zdecentralizowane sieci społecznościowe eliminują „pośrednika”. **Twórcy treści są bezpośrednimi właścicielami swoich treści** i kontaktują się bezpośrednio z osobami śledzącymi, fanami, kupującymi i innymi stronami, przy czym pomiędzy nimi został zawarty jedynie inteligentny kontrakt. +3. Zdecentralizowane sieci społecznościowe eliminują „pośrednika”. **Twórcy treści mają bezpośrednie prawo własności do swoich treści** i nawiązują bezpośrednią relację z obserwującymi, fanami, kupującymi i innymi stronami, a jedynym pośrednikiem jest smart kontrakt. -4. Podobnie jak zdecentralizowane aplikacje działające w sieci Ethereum, która jest utrzymywana przez globalną sieć węzłów typu peer-to-peer, zdecentralizowane media społecznościowe **są mniej podatne na przestoje i przerwy** w funkcjonowaniu serwerów. +4. Jako dapki działające w sieci Ethereum, która jest utrzymywana przez globalną sieć peer-to-peer węzłów, zdecentralizowane sieci społecznościowe są **mniej podatne na przestoje serwerów** i awarie. -5. Zdecentralizowane platformy społecznościowe oferują **ulepszoną strukturę monetyzacji** dla twórców treści poprzez [niewymienialne tokeny (NFT)](/glossary/#nft), płatności kryptowalutowe w aplikacji i inne. +5. Zdecentralizowane platformy społecznościowe oferują **ulepszone ramy monetyzacji** dla twórców treści poprzez [niewymienialne tokeny (NFT)](/glossary/#nft), płatności kryptowalutowe w aplikacji i nie tylko. -6. Zdecentralizowane sieci społecznościowe zapewniają użytkownikom** wysoki poziom prywatności i anonimowości**. Na przykład każdy może się zalogować do sieci społecznościowej opartej na Ethereum przy użyciu profilu lub [portfela](/glossary/#wallet) [ENS](/glossary/#ens) bez konieczności dzielenia się swoimi wrażliwymi danymi (PII), takimi jak imię i nazwisko, adresy e-mail itp. +6. Zdecentralizowane sieci społecznościowe zapewniają użytkownikom **wysoki poziom prywatności i anonimowości**. Na przykład, dana osoba może zalogować się do sieci społecznościowej opartej na Ethereum, używając profilu [ENS](/glossary/#ens) lub [portfela](/glossary/#wallet) — bez konieczności udostępniania danych osobowych (PII), takich jak imiona, adresy e-mail itp. 7. Zdecentralizowane sieci społecznościowe nie opierają sie na scentralizowanych bazach danych. Dane są przechowywane w sposób rozproszony, który lepiej je zabezpiecza. -## Zdecentralizowane sieci społecznościowe w Ethereum {#ethereum-social-networks} +## Zdecentralizowane sieci społecznościowe na Ethereum {#ethereum-social-networks} Sieć Ethereum stała się preferowanym narzędziem dla programistów, którzy tworzą zdecentralizowane media społecznościowe, ze względu na popularność jej tokenów i ogromną bazę użytkowników. Oto kilka przykładów sieci społecznościowych opartych na Ethereum: ### Mirror {#mirror} -[Mirror](https://mirror.xyz/) to oparta na web3 platforma do tworzenia treści, która ma być zdecentralizowana i należeć do użytkowników. Użytkownicy mogą czytać i pisać na platformie Mirror za darmo, po prostu podłączając swoje portfele. Mogą również zapisywać i subskrybować treści innych autorów. +[Mirror](https://mirror.xyz/) to platforma do pisania wspierana przez web3, której celem jest bycie zdecentralizowaną i należącą do użytkowników. Użytkownicy mogą czytać i pisać na platformie Mirror za darmo, po prostu podłączając swoje portfele. Mogą również zapisywać i subskrybować treści innych autorów. -Posty opublikowane na platformie Mirror są trwale przechowywane na Arweave, zdecentralizowanej platformie do przechowywania, i można je wybić jako kolekcjonerskie [niewymienialne tokeny (NFT)](/nft/) znane jako Writing NFT. Wybicie Writing NFT jest całkowicie darmowe dla twórców i odbywa się w [warstwie 2](/glossary/#layer-2) Ethereum. Dzięki temu transakcje są niedrogie, szybkie oraz przyjazne dla środowiska. +Posty publikowane na Mirror są trwale przechowywane na Arweave, zdecentralizowanej platformie do przechowywania, i mogą być wybijane jako kolekcjonerskie [niewymienialne tokeny (NFT)](/nft/) znane jako Writing NFTs. Tworzenie Writing NFT jest całkowicie bezpłatne dla autorów, a ich zbieranie odbywa się w warstwie [L2](/glossary/#layer-2) Ethereum — dzięki czemu transakcje są niedrogie, szybkie i przyjazne dla środowiska. ### MINDS {#minds} -[MINDS](https://www.minds.com/) jest jedną z najczęściej używanych zdecentralizowanych sieci społecznościowych. Działa podobnie jak Facebook i już zyskała miliony użytkowników. +[MINDS](https://www.minds.com/) to jedna z najczęściej używanych zdecentralizowanych sieci społecznościowych. Działa podobnie jak Facebook i już zyskała miliony użytkowników. -Użytkownicy używają natywnego tokena [ERC-20](/glossary/#erc-20) platformy $MIND do płacenia za produkty. Użytkownicy mogą także zarabiać tokeny $MIND publikując popularne treści, współtworząc ekosystem i kierując innych na platformę. +Użytkownicy używają natywnego tokena platformy [ERC-20](/glossary/#erc-20) $MIND do płacenia za przedmioty. Użytkownicy mogą także zarabiać tokeny $MIND publikując popularne treści, współtworząc ekosystem i kierując innych na platformę. -## Użytkowanie zdecentralizowanych sieci społecznościowych {#use-decentralized-social-networks} +### Farcaster {#farcaster} -- **[Status.im](https://status.im/)** — _Status jest bezpieczną aplikacją typu open source do wysyłania wiadomości, z wykorzystaniem protokołu peer-to-peer i szyfrowania typu end-to-end w celu ochrony wiadomości przed stronami trzecimi._ -- **[Mirror.xyz](https://mirror.xyz/)** — _Mirror jest zdecentralizowaną platformą wydawniczą opartą na sieci Ethereum, która umożliwia użytkownikom finansowanie idei społecznościowych, monetyzowanie treści i budowanie społeczności o wysokiej wartości._ -- **[Lens Protocol](https://lens.xyz/)** — _Lens Protocol jest złożonym i zdecentralizowanym wykresem społecznym, pomagającym twórcom uwiarygodnić własność ich treści, niezależnie od miejsca ich pobytu w cyfrowym ogrodzie zdecentralizowanego internetu._ -- **[Farcaster](https://farcaster.xyz/)** — _Farcaster to wystarczająco zdecentralizowana sieć społeczna. Jest to protokół otwarty, który umożliwia obsługę wielu klientów — podobnie jak poczta e-mail._ +[Farcaster](https://farcaster.xyz/) to „wystarczająco zdecentralizowana” sieć społecznościowa, podobna do X i Reddita, która pozwala użytkownikom udostępniać i odkrywać „casty”. Jest zbudowana na sieci L2 Optimism, aby transakcje były stosunkowo tanie. -## Zdecentralizowane media społecznościowe Ethereum w web2 {#web2-social-networks-and-ethereum} +## Korzystaj ze zdecentralizowanych sieci społecznościowych {#use-decentralized-social-networks} -Natywne platformy społecznościowe [Web3](/glossary/#web3) nie są jedynymi, które próbują wprowadzać technologię łańcucha bloków do mediów społecznościowych. Wiele scentralizowanych platform także planuje zintegrować swoją infrastrukturę z Ethereum: +- **[Status.app](https://status.app/)** - _Status to bezpieczna aplikacja do przesyłania wiadomości, która wykorzystuje protokół open-source, peer-to-peer i szyfrowanie end-to-end do ochrony wiadomości przed osobami trzecimi._ +- **[Mirror.xyz](https://mirror.xyz/)** - _Mirror to zdecentralizowana, należąca do użytkowników platforma publikacyjna zbudowana na Ethereum, aby użytkownicy mogli finansować społecznościowo pomysły, zarabiać na treściach i budować wartościowe społeczności._ +- **[Lens Protocol](https://lens.xyz/)** - _Lens Protocol to komponowalny i zdecentralizowany graf społecznościowy, który pomaga twórcom przejąć na własność swoje treści, gdziekolwiek się udadzą w cyfrowym ogrodzie zdecentralizowanego internetu._ +- **[Farcaster](https://farcaster.xyz/)** - _Farcaster to wystarczająco zdecentralizowana sieć społecznościowa._ Jest to protokół otwarty, który umożliwia obsługę wielu klientów — podobnie jak poczta e-mail._ +- **[Ethereum Follow Protocol](https://efp.app/)** - _Ethereum Follow Protocol to w pełni zdecentralizowany graf społecznościowy on-chain dla kont Ethereum, rozwijający wizję modułowego stosu tożsamości Ethereum, uzupełniającego ENS i SIWE._ +- **[Ethereum Comments Protocol](https://www.ethcomments.xyz/)** - _Nowy, programowalny prymityw treści społecznościowych na Ethereum, aby umieścić swoje myśli on-chain._ -### Reddit {#reddit} +## Sieci społecznościowe Web2 na Ethereum {#web2-social-networks-and-ethereum} -Reddit [zaprezentował Punkty Społecznościowe](https://cointelegraph.com/news/reddit-to-reportedly-tokenize-karma-points-and-onboard-500m-new-users) – tokeny ERC-20, które użytkownicy mogą zdobywać poprzez publikowanie wartościowych treści i aktywność w społecznościach online (tzw. subredditach). Możesz wymienić te tokeny w subreddicie, aby uzyskać ekskluzywne przywileje i korzyści. W tym projekcie Reddit współpracuje z Arbitrum, siecią [warstwy 2](/glossary/#layer-2)zaprojektowaną do skalowania transakcji Ethereum. +Natywne platformy społecznościowe [Web3](/glossary/#web3) nie są jedynymi, które próbują włączyć technologię blockchain do mediów społecznościowych. Wiele scentralizowanych platform również bada lub eksperymentowało z integracją Ethereum w swojej infrastrukturze: -Program już działa, a subreddit r/CryptoCurrency [uruchamia swoją wersję punktów społeczności o nazwie „Moons”](https://www.reddit.com/r/CryptoCurrency/wiki/moons_wiki). Według oficjalnego opisu, Moons „nagradzają posterów, komentatorów i moderatorów za ich wkład w subreddit”. Ponieważ tokeny te są w łańcuchu bloków (użytkownicy otrzymują je w portfelach), są niezależne od Reddit i nie mogą być odebrane. +### Przeglądarka Brave {#brave} -Oprócz wykorzystywania punktów społecznościowych do odblokowywania specjalnych funkcji użytkownicy mogą je również wymieniać na giełdach na walutę fiat. Ponadto liczba punktów społecznościowych, które posiada użytkownik, decyduje o jego wpływie na proces decyzyjny w obrębie społeczności. +- Brave zintegrowało **[Basic Attention Token (BAT)](https://basicattentiontoken.org/)**, token ERC-20 zbudowany na Ethereum, ze swoim ekosystemem przeglądarki, aby zrewolucjonizować reklamę cyfrową i wsparcie dla twórców treści. -## Dodatkowo przeczytaj {#further-reading} +- Program **[Brave Rewards](https://brave.com/brave-rewards/)** pozwala użytkownikom zarabiać BAT za oglądanie reklam szanujących prywatność, a następnie automatycznie przekazywać darowizny na strony internetowe i twórcom treści na różnych platformach, takich jak YouTube, Twitter i GitHub, w oparciu o czas poświęconej uwagi. + +- Twórcy treści mogą zarejestrować się jako **[zweryfikowani twórcy Brave](https://creators.brave.com/)**, aby otrzymywać te darowizny bezpośrednio na swoje portfele Ethereum, tworząc most między tradycyjnymi platformami internetowymi a monetyzacją opartą na blockchainie. + +- Tokeny BAT istnieją niezależnie na blockchainie Ethereum, co pozwala użytkownikom na ich przesyłanie do osobistych portfeli lub na giełdy po ich zarobieniu. + +### Platforma muzyczna Audius {#audius} + +- **[Audius](https://audius.co/)** to platforma do strumieniowania muzyki, która wykorzystuje technologię blockchain Ethereum do bezpośredniego łączenia artystów z fanami. + +- Platforma ma hybrydową, zdecentralizowaną architekturę, w której treści są przechowywane na IPFS, podczas gdy blockchain jest wykorzystywany do praw własności i tokena **[AUDIO](https://eth.blockscout.com/token/0x18aaa7115705e8be94bffebde57af9bfc265b998)**. + +- Audius nawiązało **[partnerstwo z TikTokiem](https://audius.co/tiktok)**, udostępniając funkcjonalność Web3 szerokiej publiczności i pozwalając artystom na monetyzację ich treści za pomocą technologii blockchain. + +- Szczegóły techniczne platformy są dostępne w ich **[dokumentacji](https://whitepaper.audius.co/)**, która pokazuje, jak zbudowali ją na infrastrukturze Ethereum. + +### Sorare: sporty fantastyczne {#sorare} + +- **[Sorare](https://sorare.com/)** to **[platforma sportów fantastycznych zbudowana na Ethereum](https://sorare.com/help/a/4402888626577/what-is-a-sorare-wallet)**, która pozwala użytkownikom kolekcjonować, handlować i grać oficjalnymi kartami graczy NFT. + +- Karty graczy to weryfikowalne NFT na blockchainie Ethereum, a smart kontrakty platformy można przeglądać na **[Etherscan](https://eth.blockscout.com/address/0x629a673a8242c2ac4b7b8c5d8735fbeac21a6205?tab=contract)**. + +- Sorare łączy tradycyjną rozgrywkę sportów fantastycznych z własnością aktywów cyfrowych na blockchainie, udostępniając funkcjonalność **[finansowania za pomocą Ethereum](https://sorare.com/help/a/10969733392797/what-network-should-i-use-to-fund-my-eth-wallet)** fanom sportów z głównego nurtu. + +### Twitter/X (Napiwki w kryptowalutach) {#twitter} + +**[Twitter](https://x.com)** (teraz X) włączył technologię blockchain na wiele sposobów, aby usprawnić monetyzację twórców i weryfikację tożsamości cyfrowej: + +- **Napiwki w kryptowalutach**: platforma zintegrowała **[napiwki w Ethereum](https://help.x.com/en/using-x/tips)**, umożliwiając użytkownikom wysyłanie płatności za pośrednictwem portfeli opartych na Ethereum, takich jak Strike. + +Integrując funkcje blockchain, X tworzy pomost między doświadczeniami społecznościowymi Web2 a zdecentralizowaną własnością cyfrową. + +## Dalsza lektura {#further-reading} ### Artykuły {#articles} -- [Decentralizacja mediów społecznościowych: przewodnik po warstwach społecznych Web3](https://www.coinbase.com/blog/decentralizing-social-media-a-guide-to-the-web3-social-stack) — _Coinbase Ventures_ -- [Media społecznościowe kolejną platformą z możliwością decentralizacji](https://www.coindesk.com/tech/2021/01/22/social-networks-are-the-next-big-decentralization-opportunity/) — _Ben Goertzel_ -- [Web3 obietnicą zdecentralizowanych, kontrolowanych przez społeczność serwisów społecznościowych](https://venturebeat.com/2022/02/26/web3-holds-the-promise-of-decentralized-community-powered-social-networks/) — _Sumit Ghosh_ -- [Przegląd mediów społecznościowych opartych na łańcuchu bloków](https://www.gemini.com/cryptopedia/blockchain-social-media-decentralized-social-media) — _Gemini Cryptopedia_ -- [Jak łańcuch bloków może rozwiązać problem z prywatnością w mediach społecznościowych](https://www.investopedia.com/news/ethereum-blockchain-social-media-privacy-problem-linkedin-indorse/) — _Prableen Bajpai_ -- [Dostateczna decentralizacja serwisów społecznościowych](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) — _Varun Srinivasan_ +- [Decentralizacja mediów społecznościowych: przewodnik po stosie społecznościowym web3](https://www.coinbase.com/blog/decentralizing-social-media-a-guide-to-the-web3-social-stack) - _Coinbase Ventures_ +- [Sieci społecznościowe to kolejna wielka szansa na decentralizację](https://www.coindesk.com/tech/2021/01/22/social-networks-are-the-next-big-decentralization-opportunity/) — _Ben Goertzel_ +- [Web3 niesie obietnicę zdecentralizowanych, zasilanych przez społeczność sieci społecznościowych](https://venturebeat.com/2022/02/26/web3-holds-the-promise-of-decentralized-community-powered-social-networks/) — _Sumit Ghosh_ +- [Przegląd krajobrazu mediów społecznościowych opartych na blockchainie](https://www.gemini.com/cryptopedia/blockchain-social-media-decentralized-social-media) — _Gemini Cryptopedia_ +- [Jak blockchain może rozwiązać problem prywatności w mediach społecznościowych](https://www.investopedia.com/news/ethereum-blockchain-social-media-privacy-problem-linkedin-indorse/) — _Prableen Bajpai_ +- [Wystarczająca decentralizacja dla sieci społecznościowych](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) — _Varun Srinivasan_ -### Materiały wideo {#videos} +### Filmy {#videos} -- [Jak działają zdecentralizowane media społecznościowe](https://www.youtube.com/watch?v=UdT2lpcGvcQ) — _CoinmarketCap_ -- [Dążenie do decentralizacji mediów społecznościowych: łańcuch bloków DeSo](https://www.youtube.com/watch?v=SG2HUiVp0rE) — _Bloomberg Technology_ -- [Przyszłość zdecentralizowanych mediów społecznościowych — Balaji Srinivasan, Vitalik Buterin, Juan Benet](https://www.youtube.com/watch?v=DTxE9KV3YrE) — _ETHGlobal_ +- [Wyjaśnienie zdecentralizowanych mediów społecznościowych](https://www.youtube.com/watch?v=UdT2lpcGvcQ) — _Coinmarketcap_ +- [Blockchain DeSo chce zdecentralizować media społecznościowe](https://www.youtube.com/watch?v=SG2HUiVp0rE) — _Bloomberg Technology_ +- [Przyszłość zdecentralizowanych mediów społecznościowych z udziałem Balaji Srinivasana, Vitalika Buterina, Juana Beneta](https://www.youtube.com/watch?v=DTxE9KV3YrE) — _ETHGlobal_ ### Społeczności {#communities} -- [Wątek r/CryptoCurrency w serwisie Reddit](https://www.reddit.com/r/CryptoCurrency/) +- [Subreddit r/CryptoCurrency](https://www.reddit.com/r/CryptoCurrency/) diff --git a/public/content/translations/pl/staking/dvt/index.md b/public/content/translations/pl/staking/dvt/index.md index aa9131e5e01..f389a2f4697 100644 --- a/public/content/translations/pl/staking/dvt/index.md +++ b/public/content/translations/pl/staking/dvt/index.md @@ -1,6 +1,6 @@ --- title: Technologia rozproszonego walidatora -description: Technologia rozproszonego walidatora umożliwia rozproszoną obsługę walidatora Ethereum przez wiele podmiotów. +description: "Technologia rozproszonego walidatora umożliwia rozproszoną obsługę walidatora Ethereum przez wiele podmiotów." lang: pl --- @@ -8,7 +8,7 @@ lang: pl Technologia rozproszonego walidatora (DVT) to podejście do bezpieczeństwa walidatora, które rozkłada zarządzanie kluczami i obowiązki podpisywania na wiele podmiotów, aby zmniejszyć liczbę pojedynczych punktów awarii i zwiększyć odporność walidatora. -Robi to poprzez **rozdzielenie klucza prywatnego** używanego do zabezpieczenia walidatora **pomiędzy wiele komputerów** zorganizowanych w „klaster”. Zaletą tego rozwiązania jest to, że atakującym bardzo trudno jest uzyskać dostęp do klucza, ponieważ nie jest on przechowywany w całości na żadnym komputerze. Pozwala to również na wyłączenie niektórych węzłów, ponieważ niezbędne podpisywanie może być wykonywane przez podzbiór komputerów w każdym klastrze. Zmniejsza to liczbę pojedynczych punktów awarii w sieci i sprawia, że cały zestaw walidatorów jest bardziej niezawodny. +Robi to poprzez **rozdzielenie klucza prywatnego** używanego do zabezpieczenia walidatora **pomiędzy wiele komputerów** zorganizowanych w "klaster". Zaletą tego rozwiązania jest to, że atakującym bardzo trudno jest uzyskać dostęp do klucza, ponieważ nie jest on przechowywany w całości na żadnym komputerze. Pozwala to również na wyłączenie niektórych węzłów, ponieważ niezbędne podpisywanie może być wykonywane przez podzbiór komputerów w każdym klastrze. Zmniejsza to liczbę pojedynczych punktów awarii w sieci i sprawia, że cały zestaw walidatorów jest bardziej niezawodny. ![Schemat pokazujący, w jaki sposób pojedynczy klucz walidatora jest dzielony na udziały klucza i dystrybuowany do wielu węzłów z różnymi komponentami.](./dvt-cluster.png) @@ -36,21 +36,21 @@ Bez DVT dostawcom stakingu łatwiej jest obsługiwać tylko jedną lub dwie konf 1. **Decentralizacja** konsensusu Ethereum proof-of-stake 2. Zapewnia **żywotność** sieci -3. Tworzy **tolerancję na błędy** walidatora -4. Działanie walidatora z **minimalizacją zaufania** -5. **Zminimalizowane ryzyko odcięć** i przestojów -6. **Zwiększa różnorodność** (klient, centrum danych, lokalizacja, przepisy itp.) +3. Tworzy **odporność na błędy** walidatora +4. **Działanie walidatora z minimalizacją zaufania** +5. Zminimalizowane ryzyko **slashingu** i przestojów +6. **Zwiększa różnorodność** (klient, centrum danych, lokalizacja, regulacje itp.) 7. **Zwiększone bezpieczeństwo** zarządzania kluczami walidatora ## Jak działa DVT? {#how-does-dvt-work} Rozwiązanie DVT zawiera następujące składniki: -- **[Dzielenie sekretu protokołem Shamira](https://medium.com/@keylesstech/a-beginners-guide-to-shamir-s-secret-sharing-e864efbf3648)** — Walidatory używają [kluczy BLS](https://en.wikipedia.org/wiki/BLS_digital_signature). Poszczególne „udziały klucza” BLS („udziały klucza”) mogą być łączone w jeden zagregowany klucz (podpis). W DVT klucz prywatny dla walidatora jest połączonym podpisem BLS każdego operatora w klastrze. -- **[Schemat podpisów progowych](https://medium.com/nethermind-eth/threshold-signature-schemes-36f40bc42aca)** — Określa liczbę indywidualnych udziałów klucza, które są wymagane do podpisywania obowiązków, np. 3 z 4. -- **[Rozproszone generowanie kluczy (DKG)](https://medium.com/toruslabs/what-distributed-key-generation-is-866adc79620)** — Proces kryptograficzny, który generuje udziały klucza i jest używany do dystrybucji udziałów istniejącego lub nowego klucza walidatora do węzłów w klastrze. -- **[Obliczenia wielostronne (MPC)](https://messari.io/report/applying-multiparty-computation-to-the-world-of-blockchains)** — Pełny klucz walidatora jest generowany w tajemnicy przy użyciu obliczeń wielostronnych. Pełen klucz nigdy nie jest znany żadnemu indywidualnemu operatorowi — zna on tylko swoją część („udział”). -- **Protokół konsensusu** — Protokół konsensusu wybiera jeden węzeł, aby proponował bloki. Współdzielą blok z innymi węzłami w klastrze, które dodają swoje udziały klucza do zagregowanego podpisu. Po zagregowaniu wystarczającej liczby udziałów klucza blok jest proponowany na Ethereum. +- **[Dzielenie sekretu Shamira](https://medium.com/@keylesstech/a-beginners-guide-to-shamir-s-secret-sharing-e864efbf3648)** - Walidatorzy używają [kluczy BLS](https://en.wikipedia.org/wiki/BLS_digital_signature). Poszczególne „udziały klucza” BLS („udziały klucza”) mogą być łączone w jeden zagregowany klucz (podpis). W DVT klucz prywatny dla walidatora jest połączonym podpisem BLS każdego operatora w klastrze. +- **[Schemat podpisów progowych](https://medium.com/nethermind-eth/threshold-signature-schemes-36f40bc42aca)** - Określa liczbę indywidualnych udziałów klucza, które są wymagane do podpisywania obowiązków, np. 3 z 4. +- **[Rozproszone generowanie kluczy (DKG)](https://medium.com/toruslabs/what-distributed-key-generation-is-866adc79620)** - Proces kryptograficzny, który generuje udziały klucza i jest używany do dystrybucji udziałów istniejącego lub nowego klucza walidatora do węzłów w klastrze. +- **[Obliczenia wielostronne (MPC)](https://messari.io/report/applying-multiparty-computation-to-the-world-of-blockchains)** - Pełny klucz walidatora jest generowany w tajemnicy przy użyciu obliczeń wielostronnych. Pełen klucz nigdy nie jest znany żadnemu indywidualnemu operatorowi — zna on tylko swoją część („udział”). +- **Protokół konsensusu** - Protokół konsensusu wybiera jeden węzeł, aby proponował bloki. Współdzielą blok z innymi węzłami w klastrze, które dodają swoje udziały klucza do zagregowanego podpisu. Po zagregowaniu wystarczającej liczby udziałów klucza blok jest proponowany na Ethereum. Rozproszone walidatory mają wbudowaną tolerancję na błędy i mogą działać nawet wtedy, gdy niektóre z poszczególnych węzłów przejdą w tryb offline. Oznacza to, że klaster jest odporny, nawet jeśli niektóre z jego węzłów okażą się złośliwe lub leniwe. @@ -58,17 +58,17 @@ Rozproszone walidatory mają wbudowaną tolerancję na błędy i mogą działać DVT ma znaczące implikacje dla szerszej branży stakingowej: -### Stakerzy solo {#solo-stakers} +### Stakujący solo {#solo-stakers} DVT pozwala również na stakowanie bez nadzoru, umożliwiając dystrybucję klucza walidatora w zdalnych węzłach, przy jednoczesnym zachowaniu pełnego klucza całkowicie offline. Oznacza to, że stakerzy domowi niekoniecznie muszą wydawać pieniądze na sprzęt, a dystrybucja udziałów w kluczach może pomóc wzmocnić ich przed potencjalnymi włamaniami. -### Usługi stakingowe (SaaS) {#saas} +### Staking jako usługa (SaaS) {#saas} Operatorzy (tacy jak stakowanie w puli i stakerzy instytucjonalni) zarządzający wieloma walidatorami mogą korzystać z DVT, aby zmniejszyć swoje ryzyko. Dystrybucja infrastruktury pozwala na zwiększenie redundancji operacji i dywersyfikację typów używanego sprzętu. DVT dzieli odpowiedzialność za zarządzanie kluczami na wiele węzłów, co oznacza, że niektóre koszty operacyjne mogą być również dzielone. DVT może również zmniejszyć ryzyko operacyjne i koszty ubezpieczenia dla dostawców stakingu. -### Staking pools {#staking-pools} +### Pule stakingowe {#staking-pools} Ze względu na standardowe konfiguracje walidatorów, stakowanie w puli i dostawcy płynnych stakingów są zmuszeni do posiadania różnych poziomów zaufania pojedynczego operatora, ponieważ zyski i straty są uspołeczniane w całej puli. Są one również zależne od operatorów w zakresie ochrony kluczy podpisujących, ponieważ do tej pory nie było dla nich innej opcji. @@ -80,12 +80,12 @@ Kolejną korzyścią płynącą z minimalizowania zaufania pojedynczego operator ## Potencjalne wady korzystania z DVT {#potential-drawbacks-of-using-dvt} -- **Dodatkowy komponent** — wprowadzenie węzła DVT dodaje kolejną część, która może być wadliwa lub podatna na ataki. Sposobem na złagodzenie tego jest dążenie do wielu implementacji węzła DVT, co oznacza wielu klientów DVT (podobnie jak istnieje wielu klientów dla warstw konsensusu i wykonania). -- **Koszty operacyjne** — ponieważ DVT dystrybuuje walidator między wieloma podmiotami, do działania wymagana jest większa liczba węzłów zamiast tylko jednego węzła, co powoduje wzrost kosztów operacyjnych. -- **Potencjalnie zwiększone opóźnienie** — ponieważ DVT wykorzystuje protokół konsensusu do osiągnięcia konsensusu między wieloma węzłami obsługującymi walidator, może potencjalnie wprowadzić zwiększone opóźnienie. +- **Dodatkowy komponent** - wprowadzenie węzła DVT dodaje kolejną część, która może być wadliwa lub podatna na ataki. Sposobem na złagodzenie tego jest dążenie do wielu implementacji węzła DVT, co oznacza wielu klientów DVT (podobnie jak istnieje wielu klientów dla warstw konsensusu i wykonania). +- **Koszty operacyjne** - ponieważ DVT dystrybuuje walidatora między wieloma podmiotami, do działania wymagana jest większa liczba węzłów zamiast tylko jednego węzła, co powoduje wzrost kosztów operacyjnych. +- **Potencjalnie zwiększone opóźnienie** - ponieważ DVT wykorzystuje protokół konsensusu do osiągnięcia konsensusu między wieloma węzłami obsługującymi walidatora, może potencjalnie wprowadzić zwiększone opóźnienie. ## Dalsza lektura {#further-reading} -- [Specyfikacja rozproszonego walidatora Ethereum (wysoki poziom)](https://github.com/ethereum/distributed-validator-specs) -- [Specyfikacja techniczna rozproszonego walidatora Ethereum](https://github.com/ethereum/distributed-validator-specs/tree/dev/src/dvspec) -- [Aplikacja demo do dzielenia sekretu protokołem Shamira](https://iancoleman.io/shamir/) +- [Specyfikacje rozproszonego walidatora Ethereum (ogólne)](https://github.com/ethereum/distributed-validator-specs) +- [Specyfikacje techniczne rozproszonego walidatora Ethereum](https://github.com/ethereum/distributed-validator-specs/tree/dev/src/dvspec) +- [Dzielenie sekretu Shamira – aplikacja demonstracyjna](https://iancoleman.io/shamir/) diff --git a/public/content/translations/pl/staking/pools/index.md b/public/content/translations/pl/staking/pools/index.md index 3b1cbdbeaaf..57879f15e37 100644 --- a/public/content/translations/pl/staking/pools/index.md +++ b/public/content/translations/pl/staking/pools/index.md @@ -1,11 +1,11 @@ --- -title: Staking łączony -description: Przegląd tego, jak rozpocząć korzystanie ze stakowania ETH w puli +title: "Staking łączony" +description: "Dowiedz się więcej o pulach stakingu" lang: pl template: staking emoji: ":money_with_wings:" image: /images/staking/leslie-pool.png -alt: Nosorożec Leslie pływający w basenie. +alt: "Nosorożec Leslie pływający w basenie." sidebarDepth: 2 summaryPoints: - Stakuj i zdobywaj nagrody z dowolną ilością ETH, łącząc siły z innymi @@ -24,14 +24,14 @@ Niektóre pule działają w oparciu o inteligentne kontrakty, w których środki Oprócz korzyści, które opisaliśmy w naszym [wprowadzeniu do stakingu](/staking/), stakowanie w puli wiąże się z szeregiem wyraźnych korzyści. - - - + + + -## Co wziąć pod uwagę {#what-to-consider} +## Co należy wziąć pod uwagę {#what-to-consider} Stakowanie w puli lub delegowane nie jest natywnie obsługiwane przez protokół Ethereum, ale biorąc pod uwagę zapotrzebowanie użytkowników na stakowanie mniej niż 32 ETH, powstała rosnąca liczba rozwiązań, które zaspokajają to zapotrzebowanie. @@ -45,7 +45,7 @@ Wskaźniki atrybutów są używane poniżej, aby zasygnalizować godne uwagi moc -## Odkryj usługi stakowania w puli {#explore-staking-pools} +## Przeglądaj pule stakingu {#explore-staking-pools} Dostępnych jest wiele opcji ułatwiających konfigurację. Skorzystaj z powyższych wskaźników, które oprowadzą cię z poniższymi narzędziami. @@ -53,17 +53,17 @@ Dostępnych jest wiele opcji ułatwiających konfigurację. Skorzystaj z powyżs -Należy pamiętać, że ważne jest, aby wybrać usługę, która poważnie traktuje [różnorodność klientów](/developers/docs/nodes-and-clients/client-diversity/), ponieważ zwiększa to bezpieczeństwo sieci i ogranicza ryzyko. Usługi, które mają dowody na ograniczanie korzystania z większości klientów, są oznaczone jako „różnorodność klientów wykonawczych” i „różnorodność klientów konsensusu”. +Należy pamiętać, że ważne jest, aby wybrać usługę, która poważnie traktuje [różnorodność klientów](/developers/docs/nodes-and-clients/client-diversity/), ponieważ zwiększa to bezpieczeństwo sieci i ogranicza ryzyko. Usługi, które mają dowody na ograniczanie korzystania z większości klientów, są oznaczone „różnorodność klientów wykonawczych” i „różnorodność klientów konsensusu.” -Masz sugestię dotyczącą narzędzia do stakingu, które pominęliśmy? Zapoznaj się z naszymi [zasadami umieszczania produktów na liście](/contributing/adding-staking-products/), aby sprawdzić, czy są one odpowiednie i przesłać je do recenzji. +Masz sugestię dotyczącą narzędzia do stakingu, które pominęliśmy? Zapoznaj się z naszymi [zasadami umieszczania produktów na liście](/contributing/adding-staking-products/), aby sprawdzić, czy Twój produkt będzie pasował, i przesłać go do recenzji. ## Często zadawane pytania {#faq} - + Zazwyczaj tokeny stakingu ERC-20 są wydawane stakerom i reprezentują wartość zestakowanego przez nich ETH plus nagrody. Należy pamiętać, że różne pule będą dystrybuować nagrody ze stakowania do swoich użytkowników za pomocą nieco innych metod, ale jest to częste. - + Już teraz! Aktualizacja sieci Shanghai/Capella miała miejsce w kwietniu 2023 r. i wprowadziła wypłaty ze stakingu. Konta walidatorów, które wspierają stakowanie w puli mają teraz możliwość wyjścia i wypłaty ETH na wyznaczony adres wypłaty. Daje to możliwość zdobycia swojej części swojej stawki za bazowe ETH. Sprawdź u swojego dostawcy, aby sprawdzić, w jaki sposób obsługuje tę funkcję. Alternatywnie, pule wykorzystujące token stakingowy ERC-20 pozwalają użytkownikom handlować tym tokenem na otwartym rynku, umożliwiając sprzedaż pozycji stakingowej, skutecznie „wypłacając” bez faktycznego usuwania ETH z kontraktu stakingowego. @@ -71,16 +71,16 @@ Alternatywnie, pule wykorzystujące token stakingowy ERC-20 pozwalają użytkown Więcej o wypłatach ze stakingu - -Jest wiele podobieństw między tymi opcjami stakowania w puli a scentralizowanymi giełdami, takimi jak możliwość stakowania niewielkich ilości ETH i łączenia ich w celu aktywacji walidatorów. + +Istnieje wiele podobieństw między tymi opcjami stakowania w puli a scentralizowanymi giełdami, takimi jak możliwość stakowania niewielkich ilości ETH i łączenia ich w celu aktywacji walidatorów. W przeciwieństwie do scentralizowanych giełd wiele innych opcji stakowania w puli wykorzystuje inteligentne kontrakty i/lub tokeny stakingu, które zazwyczaj są tokenami ERC-20, które można przechowywać we własnym portfelu i kupować lub sprzedawać tak jak każdy inny token. Zapewnia to warstwę niezależności i bezpieczeństwa, dając ci kontrolę nad tokenami, ale nadal nie daje ci bezpośredniej kontroli nad klientem walidatora poświadczającym w twoim imieniu w tle. Niektóre opcje puli są bardziej zdecentralizowane niż inne, jeśli chodzi o węzły, które je obsługują. Aby promować zdrowie i decentralizację sieci, stakerzy są zawsze zachęcani do wyboru usługi w puli, która umożliwia zdecentralizowany zestaw operatorów węzłów bez zezwoleń. -## Dodatkowo przeczytaj {#further-reading} +## Dalsza lektura {#further-reading} -- [Katalog stakingu Ethereum](https://www.staking.directory/) — _Eridian i Spacesider_ -- [Staking z Rocket Pool - Przegląd stakingu](https://docs.rocketpool.net/guides/staking/overview.html) — _Dokumenty RocketPool_ -- [Staking Ethereum z Lido](https://help.lido.fi/en/collections/2947324-staking-ethereum-with-lido) — _dokumenty pomocy Lido_ +- [Katalog stakingu Ethereum](https://www.staking.directory/) - _Eridian i Spacesider_ +- [Staking z Rocket Pool – Przegląd stakingu](https://docs.rocketpool.net/guides/staking/overview.html) - _dokumentacja RocketPool_ +- [Staking Ethereum z Lido](https://help.lido.fi/en/collections/2947324-staking-ethereum-with-lido) - _dokumentacja pomocy Lido_ diff --git a/public/content/translations/pl/staking/saas/index.md b/public/content/translations/pl/staking/saas/index.md index ad3c17122f3..d1d9c4b100f 100644 --- a/public/content/translations/pl/staking/saas/index.md +++ b/public/content/translations/pl/staking/saas/index.md @@ -1,11 +1,11 @@ --- -title: Usługi stakingowe -description: Przegląd tego, jak rozpocząć korzystanie ze stakowania ETH w puli +title: "Staking jako usługa" +description: "Dowiedz się o stakingu jako usłudze" lang: pl template: staking emoji: ":money_with_wings:" image: /images/staking/leslie-saas.png -alt: Nosorożec Leslie unoszący się w chmurach. +alt: "Nosorożec Leslie unoszący się w chmurach." sidebarDepth: 2 summaryPoints: - Działanie Twojego walidatora zapewniają zewnętrzni operatorzy węzłów @@ -17,19 +17,19 @@ summaryPoints: Usługi stakingowe („SaaS”) reprezentują kategorię usług stakingowych, w których użytkownik deponuje własne 32 ETH dla walidatora, ale deleguje operacje węzła do zewnętrznego operatora. Proces ten zwykle wymaga bycia przeprowadzonym przez początkową konfigurację, w tym generowanie kluczy i depozyt, a następnie przesłanie kluczy podpisujących do operatora. Dzięki temu usługa może obsługiwać Twój walidator w Twoim imieniu, zwykle za miesięczną opłatą. -## Dlaczego warto postawić na usługę? {#why-stake-with-a-service} +## Dlaczego warto postawić na usługę? Dlaczego stakować za pośrednictwem usługi? {#why-stake-with-a-service} Protokół Ethereum nie wspiera natywnie delegowania stawek, więc stworzone zostały te usługi, aby zaspokoić zapotrzebowanie. Jeśli masz dostępne na poczet stakingu 32 ETH, ale nie czujesz się komfortowo z obsługą sprzętu, usługi SaaS pozwalają Ci na zdelegowanie tych czynności, podczas gdy Ty nadal możesz uzyskiwać natywne nagrody za blok. - - - + + + -## Co wziąć pod uwagę {#what-to-consider} +## Co należy wziąć pod uwagę {#what-to-consider} Powstaje coraz więcej dostawców SaaS, którzy pomogą Ci stakować Twoje ETH, ale każdy z nich ma swoje własne korzyści i ryzyka. Wszystkie opcje SaaS wymagają dodatkowych założeń dotyczących zaufania w porównaniu do domowego stakingu. Opcje SaaS mogą zawierać dodatkowy kod opakowujący klienta Ethereum, który nie będzie otwarty lub skontrolowany. SaaS ma również niekorzystny wpływ na decentralizację sieci. W zależności od konfiguracji możesz nie mieć możliwości kontrolowania swojego walidatora — operator może działać nieuczciwie, używając twojego ETH. @@ -47,49 +47,49 @@ Poniżej znajduje się kilku dostępnych dostawców SaaS. Skorzystaj z powyższy -Należy pamiętać o znaczeniu wspierania [różnorodności klientów](/developers/docs/nodes-and-clients/client-diversity/), ponieważ poprawia to bezpieczeństwo sieci i ogranicza ryzyko. Usługi, które mają dowody na ograniczanie korzystania z większości klientów, są oznaczone jako „różnorodność klientów wykonawczych” i „różnorodność klientów konsensusu”. +Należy pamiętać o znaczeniu wspierania [różnorodności klientów](/developers/docs/nodes-and-clients/client-diversity/), ponieważ poprawia to bezpieczeństwo sieci i ogranicza ryzyko. Usługi, które mają dowody na ograniczanie korzystania z większości klientów, są oznaczone „różnorodność klientów wykonawczych” i „różnorodność klientów konsensusu.” ### Generatory kluczy -Masz sugestię dostawcy usług stakingowych, którego pominęliśmy? Zapoznaj się z naszymi [zasadami umieszczania produktów na liście](/contributing/adding-staking-products/), aby sprawdzić, czy są one odpowiednie i przesłać je do recenzji. +Masz sugestię dostawcy usług stakingowych, którego pominęliśmy? Zapoznaj się z naszymi [zasadami umieszczania produktów na liście](/contributing/adding-staking-products/), aby sprawdzić, czy Twój produkt będzie pasował, i przesłać go do recenzji. ## Często zadawane pytania {#faq} - + Rozwiązania będą się różnić w zależności od dostawcy, ale zazwyczaj zostaniesz poprowadzony przez konfigurację wszystkich potrzebnych kluczy podpisywania (jeden na 32 ETH) i przesłanie ich do dostawcy, aby umożliwić mu walidację w Twoim imieniu. Same klucze podpisywania nie dają żadnej możliwości wypłaty, transferu ani wydawania środków. Zapewniają jednak możliwość oddawania głosów w celu osiągnięcia konsensusu, co w przypadku niewłaściwego wykonania może skutkować karami offline lub cięciem. - + Tak. Każde konto składa się zarówno z kluczy podpisujących BLS, jak i kluczy wypłat BLS. Aby walidator mógł poświadczyć stan łańcucha, uczestniczyć w komitetach synchronizacji i proponować bloki, klucze podpisujące muszą być łatwo dostępne dla klienta walidatora. Muszą one być połączone z Internetem w jakiś sposób, a zatem są z natury uważane za klucze „gorące”. Jest to wymagane, aby walidator mógł poświadczyć, a zatem klucze używane do przesyłania lub wypłacania środków są oddzielone ze względów bezpieczeństwa. Klucze wypłaty BLS są używane do podpisywania jednorazowej wiadomości, która deklaruje, na które konto warstwy wykonawczej powinny trafić nagrody za stakowanie i wycofane środki. Po nadaniu tej wiadomości klucze wypłat BLS nie są już potrzebne. Zamiast tego kontrola nad wypłaconymi środkami jest na stałe przekazywana na podany adres. Umożliwia to ustawienie adresu wypłaty zabezpieczonego za pomocą własnych zimnych danych, minimalizując ryzyko środków walidatora, nawet jeśli ktoś inny kontroluje klucze podpisywania walidatora. Aktualizowanie danych uwierzytelniających wypłaty jest wymagane, aby umożliwić wypłaty\*. Proces ten obejmuje generowanie kluczy wypłat przy użyciu mnemonicznej frazy odzyskiwania. -Upewnij się, że bezpiecznie zapisałeś tę frazę odzyskiwania, w przeciwnym razie nie będziesz w stanie wygenerować kluczy wypłaty, gdy nadejdzie czas. +Pamiętaj, aby bezpiecznie utworzyć kopię zapasową tej frazy seed, w przeciwnym razie nie będziesz w stanie wygenerować kluczy do wypłaty, gdy nadejdzie taka potrzeba. -\*Stakerzy, którzy podali adres wypłaty przy pierwszej wpłacie, nie muszą tego ustawiać. Skontaktuj się ze swoim dostawcą SaaS, aby uzyskać pomoc dotyczącą przygotowania walidatora. +\*Stakerzy, którzy podali adres do wypłat przy pierwszej wpłacie, nie muszą tego ustawiać. Skontaktuj się ze swoim dostawcą SaaS, aby uzyskać pomoc dotyczącą przygotowania walidatora. - -W kwietniu 2023 r. w ramach aktualizacji Shanghai/Capella wprowadzono wypłaty ze stakingu. Stakerzy muszą podać adres do wypłaty (jeśli nie podano go przy pierwszej wpłacie), a wypłaty nagród zaczną być wypłacane automatycznie co kilka dni. + +Stakerzy muszą podać adres do wypłaty (jeśli nie podano go przy pierwszej wpłacie), a wypłaty nagród zaczną być wypłacane automatycznie co kilka dni. Walidatorzy mogą również w pełni wyjść jako walidator, co odblokuje ich pozostałe saldo ETH do wypłaty. Konta, które podały adres wypłaty i zakończyły proces wyjścia, otrzymają całe saldo na adres wypłaty podany podczas następnego przeglądu walidatora. Więcej o wypłatach ze stakingu - + Korzystając z usług dostawcy SaaS, powierzasz obsługę swojego węzła komuś innemu. Wiąże się to z ryzykiem niskiej wydajności węzła, na którą nie masz wpływu. W przypadku, gdy Twój walidator zostanie odcięty, saldo walidatora zostanie ukarane i przymusowo usunięte z puli walidatorów. Po zakończeniu procesu cięcia/wyjścia środki te zostaną przelane na adres wypłaty przypisany do walidatora. Wymaga to podania adresu wypłaty w celu włączenia. Mogło to zostać dostarczone przy pierwszej wpłacie. Jeśli nie, klucze wypłaty walidatora będą musiały zostać użyte do podpisania wiadomości deklarującej adres wypłaty. Jeśli nie podano adresu wypłaty, środki pozostaną zablokowane do czasu jego podania. -Skontaktuj się z indywidualnym dostawcą SaaS, aby uzyskać więcej informacji na temat wszelkich gwarancji lub opcji ubezpieczenia, a także instrukcjami dotyczącymi sposobu podania adresu wypłaty. Jeśli wolisz mieć pełną kontrolę nad konfiguracją walidatora, [dowiedz się więcej o solo stakingu ETH](/staking/solo/). +Skontaktuj się z indywidualnym dostawcą SaaS, aby uzyskać więcej informacji na temat wszelkich gwarancji lub opcji ubezpieczenia, a także instrukcjami dotyczącymi sposobu podania adresu wypłaty. Jeśli wolisz mieć pełną kontrolę nad konfiguracją swojego walidatora, [dowiedz się więcej o solo stakingu ETH](/staking/solo/). -## Dodatkowo przeczytaj {#further-reading} +## Dalsza lektura {#further-reading} -- [Katalog stakingu Ethereum](https://www.staking.directory/) — _Eridian i Spacesider_ -- [Ocena usług stakingu](https://www.attestant.io/posts/evaluating-staking-services/) — _Jim McDonald 2020 r._ +- [Katalog stakingu Ethereum](https://www.staking.directory/) - _Eridian i Spacesider_ +- [Ocena usług stakingowych](https://www.attestant.io/posts/evaluating-staking-services/) - _Jim McDonald 2020_ diff --git a/public/content/translations/pl/staking/solo/index.md b/public/content/translations/pl/staking/solo/index.md index 379541e046f..d014682b716 100644 --- a/public/content/translations/pl/staking/solo/index.md +++ b/public/content/translations/pl/staking/solo/index.md @@ -1,11 +1,11 @@ --- -title: Stakuj solo swoje ETH -description: Przegląd tego, jak rozpocząć samodzielne stakowanie ETH +title: Stakuj ETH w domu +description: "Przegląd tego, jak rozpocząć stakowanie ETH w domu" lang: pl template: staking emoji: ":money_with_wings:" image: /images/staking/leslie-solo.png -alt: Nosorożec Leslie na własnym chipie komputerowym. +alt: "Nosorożec Leslie na własnym chipie komputerowym." sidebarDepth: 2 summaryPoints: - Otrzymuj maksymalne nagrody bezpośrednio z protokołu za utrzymywanie prawidłowego działania walidatora w trybie online @@ -13,64 +13,65 @@ summaryPoints: - Wyeliminuj potrzebę zaufania i nigdy nie rezygnuj z kontroli nad kluczami do swoich funduszy --- -## Czym jest solo staking? {#what-is-solo-staking} +## Czym jest stakowanie w domu? {#what-is-solo-staking} -Solo staking polega na [uruchomieniu węzła Ethereum](/run-a-node/) podłączonego do Internetu i zdeponowaniu 32 ETH w celu aktywacji [walidatora](#faq), co daje możliwość bezpośredniego uczestniczenia w konsensusie sieci. +Stakowanie w domu polega na [uruchomieniu węzła Ethereum](/run-a-node/) podłączonego do internetu i zdeponowaniu 32 ETH w celu aktywacji [walidatora](#faq), co daje możliwość bezpośredniego uczestnictwa w konsensusie sieci. -**Solo staking zwiększa decentralizację sieci Ethereum**, dzięki czemu Ethereum jest bardziej odporne na cenzurę i ataki. Inne metody stakowania mogą nie pomóc sieci w ten sam sposób. Solo staking jest najlepszą opcją stakingu do zabezpieczania Ethereum. +**Stakowanie w domu zwiększa decentralizację sieci Ethereum**, czyniąc Ethereum bardziej odpornym na cenzurę i ataki. Inne metody stakowania mogą nie pomagać sieci w ten sam sposób. Stakowanie w domu jest najlepszą opcją stakowania w celu zabezpieczenia Ethereum. -Węzeł Ethereum składa się zarówno z klienta warstwy wykonawczej (EL), jak i klienta warstwy konsensusu (CL). Ci klienci są oprogramowaniem, które współpracuje, wraz z prawidłowym zestawem kluczy podpisujących, w celu weryfikacji transakcji i bloków, poświadczania prawidłowej pozycji łańcucha, agregowania poświadczeń i proponowania bloków. +Węzeł Ethereum składa się zarówno z klienta warstwy wykonawczej (EL), jak i klienta warstwy konsensusu (CL). Ci klienci to oprogramowanie, które współpracuje, wraz z prawidłowym zestawem kluczy podpisujących, w celu weryfikacji transakcji i bloków, poświadczania prawidłowego nagłówka łańcucha, agregowania poświadczeń i proponowania bloków. -Solo stakerzy są odpowiedzialni za obsługę sprzętu potrzebnego do uruchomienia tych klientów. Zaleca się używanie do tego celu dedykowanej maszyny obsługiwanej z domu — jest to niezwykle korzystne dla zdrowia sieci. +Osoby stakujące w domu są odpowiedzialne za obsługę sprzętu potrzebnego do uruchomienia tych klientów. Zaleca się używanie do tego celu dedykowanej maszyny obsługiwanej z domu — jest to niezwykle korzystne dla zdrowia sieci. -Solo staker otrzymuje nagrody bezpośrednio z protokołu za utrzymywanie swojego walidatora prawidłowo działającego i online. +Staker domowy otrzymuje nagrody bezpośrednio z protokołu za utrzymywanie swojego walidatora prawidłowo działającego i online. -## Dlaczego stakować solo? {#why-stake-solo} +## Dlaczego stakować w domu? {#why-stake-solo} -Staking solo wiąże się z większą odpowiedzialnością, ale zapewnia maksymalną kontrolę nad środkami i konfiguracją stakingu. +Stakowanie w domu wiąże się z większą odpowiedzialnością, ale zapewnia maksymalną kontrolę nad środkami i konfiguracją stakowania. - - - + + + -## Rozważania przed solo stakingiem {#considerations-before-staking-solo} +## Kwestie do rozważenia przed rozpoczęciem stakowania w domu {#considerations-before-staking-solo} -Chociaż chcielibyśmy, aby staking solo był dostępny i wolny od ryzyka dla każdego, nie jest to jednak rzeczywistością. Istnieje kilka praktycznych i poważnych kwestii, o których należy pamiętać przed podjęciem decyzji o samodzielnym stakowaniu ETH. +Chociaż chcielibyśmy, aby stakowanie w domu było dostępne i wolne od ryzyka dla każdego, nie jest to jednak rzeczywistością. Istnieje kilka praktycznych i poważnych kwestii, o których należy pamiętać przed podjęciem decyzji o stakowaniu ETH w domu. - + Podczas obsługi własnego węzła należy poświęcić trochę czasu na naukę obsługi wybranego oprogramowania. Obejmuje to czytanie odpowiedniej dokumentacji i bycie na bieżąco z kanałami komunikacji tych zespołów programistów. -Im więcej wiesz o oprogramowaniu, które uruchamiasz i jak działa dowód stawki (proof-of-stake), tym mniej ryzykowne będzie to jako staker i tym łatwiej będzie naprawić wszelkie problemy, które mogą pojawić się po drodze jako operator węzła. +Im lepiej rozumiesz oprogramowanie, którego używasz, oraz działanie mechanizmu proof-of-stake, tym mniejsze ponosisz ryzyko jako staker i tym łatwiej będzie Ci naprawiać ewentualne problemy jako operatorowi węzła. - + Konfiguracja węzła wymaga rozsądnego poziomu komfortu podczas pracy z komputerami, chociaż nowe narzędzia z czasem to ułatwiają. Zrozumienie interfejsu wiersza poleceń jest pomocne, ale nie jest już wymagane. Wymaga również bardzo podstawowej konfiguracji sprzętu i pewnego zrozumienia minimalnych zalecanych specyfikacji. - -Podobnie jak w przypadku kluczy prywatnych zabezpieczających adres Ethereum, konieczne będzie wygenerowanie kluczy specjalnie dla walidatora. Musisz wiedzieć, jak bezpiecznie przechowywać wszelkie frazy odzyskiwania lub klucze prywatne.{' '} + +Podobnie jak w przypadku kluczy prywatnych zabezpieczających adres Ethereum, konieczne będzie wygenerowanie kluczy specjalnie dla walidatora. Musisz wiedzieć, jak bezpiecznie przechowywać wszelkie frazy seed lub klucze prywatne.{' '} [Bezpieczeństwo Ethereum i zapobieganie oszustwom](/security/) - -Sprzęt czasami zawodzi, połączenia sieciowe ulegają awarii, a oprogramowanie klienta czasami wymaga aktualizacji. Konserwacja węzła jest nieunikniona i od czasu do czasu będzie wymagać uwagi użytkownika. Musisz mieć pewność, że będziesz na bieżąco z wszelkimi przewidywanymi aktualizacjami sieci lub innymi krytycznymi aktualizacjami klienta. + +Sprzęt czasami zawodzi, połączenia sieciowe ulegają awarii, a oprogramowanie klienta czasami wymaga aktualizacji. Konserwacja węzła jest nieunikniona i od czasu do czasu będzie wymagać Twojej uwagi. Musisz mieć pewność, że będziesz na bieżąco z wszelkimi przewidywanymi aktualizacjami sieci lub innymi krytycznymi aktualizacjami klienta. - -Nagrody są proporcjonalne do czasu, w którym walidator jest online i prawidłowo poświadcza. Przestój wiąże się z karami proporcjonalnymi do tego, ile innych walidatorów jest offline w tym samym czasie, ale nie powoduje cięcia. Przepustowość również ma znaczenie, ponieważ nagrody są zmniejszane za zaświadczenia, które nie są otrzymywane na czas. Wymagania będą się różnić, ale zalecane jest co najmniej 10 Mb/s wysyłania i pobierania. + +Twoje nagrody są proporcjonalne do czasu, w którym Twój walidator jest online i prawidłowo poświadcza. Przestój wiąże się z karami proporcjonalnymi do tego, ile innych walidatorów jest offline w tym samym czasie, ale nie powoduje cięcia. Przepustowość również ma znaczenie, ponieważ nagrody są zmniejszane za poświadczenia, które nie zostaną otrzymane na czas. Wymagania będą się różnić, ale zalecane jest co najmniej 10 Mb/s wysyłania i pobierania. -W odróżnieniu od kar za bycie offline, cięcie jest znacznie poważniejszą karą zarezerwowaną dla złośliwych wykroczeń. Uruchamiając klienta mniejszościowego z kluczami załadowanymi tylko na jednej maszynie w danym czasie, ryzyko odcięcia jest zminimalizowane. Biorąc to pod uwagę, wszyscy stakerzy muszą być świadomi ryzyka związanego z odcięciem. +W odróżnieniu od kar za bycie offline, cięcie jest znacznie poważniejszą karą zarezerwowaną dla złośliwych wykroczeń. Uruchamiając klienta mniejszościowego z kluczami załadowanymi tylko na jednym urządzeniu w danym czasie, ryzyko cięcia jest zminimalizowane. Biorąc to pod uwagę, wszyscy stakerzy muszą być świadomi ryzyka związanego z cięciem. -Więcej o cięciu i cyklu życia walidatora + Więcej o cięciu i cyklu życia walidatora + @@ -81,25 +82,25 @@ W odróżnieniu od kar za bycie offline, cięcie jest znacznie poważni Podczas aktywności będziesz zdobywać nagrody ETH, które będą okresowo wpłacane na Twój adres wypłaty. -Jeśli chcesz, możesz wyjść jako walidator, co eliminuje wymóg bycia online i zatrzymuje wszelkie dalsze nagrody. Pozostałe saldo zostanie następnie wypłacone na adres wypłaty wskazany podczas konfiguracji. +W dowolnym momencie można zrezygnować z roli walidatora, co eliminuje wymóg bycia online i wstrzymuje dalsze nagrody. Pozostałe saldo zostanie następnie wypłacone na adres wypłaty wskazany podczas konfiguracji. -[Więcej o wypłatach ze stakingu](/staking/withdrawals/) +[Więcej na temat wypłat ze stakingu](/staking/withdrawals/) ## Rozpocznij na Staking Launchpad {#get-started-on-the-staking-launchpad} -Staking Launchpad to aplikacja open source, która pomoże ci zostać stakerem. Poprowadzi cię przez wybór klientów, wygenerowanie kluczy i zdeponowanie ETH w kontrakcie depozytu na staking. Lista kontrolna jest dostęna, aby upewnić się, że wszystko zostało uwzględnione w celu bezpiecznego skonfigurowania walidatora. +Staking Launchpad to aplikacja open source, która pomoże ci zostać stakerem. Poprowadzi cię przez wybór klientów, wygenerowanie kluczy i zdeponowanie ETH w kontrakcie depozytu na staking. Dostępna jest lista kontrolna, aby upewnić się, że wszystko zostało uwzględnione w celu bezpiecznej konfiguracji walidatora. ## Co wziąć pod uwagę w przypadku narzędzi do konfiguracji węzłów i klientów {#node-tool-considerations} -Powstaje coraz więcej narzędzi i usług, które pomagają w samodzielnym stakowaniu ETH, ale każde z nich wiąże się z innym ryzykiem i korzyściami. +Powstaje coraz więcej narzędzi i usług, które pomagają w stakowaniu ETH w domu, ale każde z nich wiąże się z innym ryzykiem i korzyściami. -Wskaźniki atrybutów są używane poniżej, aby zasygnalizować godne uwagi mocne lub słabe strony, jakie może mieć wymienione narzędzie do stakowania. Użyj tej sekcji jako odniesienia do sposobu definiowania tych atrybutów podczas wybierania narzędzi, które pomogą Ci w Twojej przygodzie ze stakingiem. +Poniżej użyto wskaźników atrybutów, aby zasygnalizować godne uwagi mocne lub słabe strony, jakie może mieć wymienione narzędzie do stakowania. Użyj tej sekcji jako odniesienia do sposobu, w jaki definiujemy te atrybuty podczas wybierania narzędzi, które pomogą Ci w Twojej przygodzie ze stakowaniem. -## Poznaj narzędzia konfiguracji węzła i klienta {#node-and-client-tools} +## Poznaj narzędzia do konfiguracji węzłów i klientów {#node-and-client-tools} Dostępnych jest wiele opcji ułatwiających konfigurację. Skorzystaj z powyższych wskaźników, które oprowadzą cię z poniższymi narzędziami. @@ -109,17 +110,17 @@ Dostępnych jest wiele opcji ułatwiających konfigurację. Skorzystaj z powyżs -Należy pamiętać o znaczeniu wybrania [klienta mniejszościowego](/developers/docs/nodes-and-clients/client-diversity/), ponieważ poprawia to bezpieczeństwo sieci i ogranicza ryzyko. Narzędzia, które pozwalają na konfigurację klienta mniejszościowego, są oznaczone jako „multi-klient”. +Należy pamiętać o znaczeniu wybrania [klienta mniejszościowego](/developers/docs/nodes-and-clients/client-diversity/), ponieważ poprawia to bezpieczeństwo sieci i ogranicza ryzyko. Narzędzia, które pozwalają na konfigurację klienta mniejszościowego są oznaczone jako „multi-klient”. ### Generatory kluczy -Narzędzia te mogą być używane jako alternatywa dla [CLI depozytu stakingu](https://github.com/ethereum/staking-deposit-cli/), aby pomóc w generowaniu kluczy. +Narzędzia te mogą być używane jako alternatywa dla [Staking Deposit CLI](https://github.com/ethereum/staking-deposit-cli/), aby pomóc w generowaniu kluczy. -Masz sugestię dotyczącą narzędzia do stakingu, które pominęliśmy? Zapoznaj się z naszymi [zasadami umieszczania produktów na liście](/contributing/adding-staking-products/), aby sprawdzić, czy są one odpowiednie i przesłać je do recenzji. +Masz sugestię dotyczącą narzędzia do stakingu, które pominęliśmy? Zapoznaj się z naszymi [zasadami umieszczania produktów na liście](/contributing/adding-staking-products/), aby sprawdzić, czy Twój produkt będzie pasował, i przesłać go do recenzji. -## Zapoznaj się z przewodnikami solo stakingu {#staking-guides} +## Przeglądaj przewodniki po stakowaniu w domu {#staking-guides} @@ -129,62 +130,65 @@ Oto kilka najczęściej zadawanych pytań dotyczących stakingu, o których wart -Walidator to wirtualny podmiot, który żyje w Ethereum i uczestniczy w konsensusie protokołu Ethereum. Walidatory są reprezentowane przez saldo, klucz publiczny i inne właściwości. Klient walidatora to oprogramowanie, które działa w imieniu walidatora, przechowując i używając jego klucza prywatnego. Pojedynczy klient walidatora może przechowywać wiele par kluczy, kontrolując wiele walidatorów. - +Walidator to wirtualny podmiot, który żyje w Ethereum i uczestniczy w konsensusie protokołu Ethereum. Walidatorzy są reprezentowani przez saldo, klucz publiczny i inne właściwości. Klient walidatora to oprogramowanie, które działa w imieniu walidatora, przechowując i używając jego klucza prywatnego. Pojedynczy klient walidatora może przechowywać wiele par kluczy, kontrolując wiele walidatorów. -Każda para kluczy powiązana z walidatorem wymaga dokładnie 32 ETH do aktywacji. Więcej ETH zdeponowanych w jednym zestawie kluczy nie zwiększa potencjału nagród, ponieważ każdy walidator jest ograniczony do efektywnego salda 32 ETH. Oznacza to, że staking odbywa się w przyrostach 32 ETH, każdy z własnym zestawem kluczy i saldem. +Tak, nowoczesne konta walidatorów mogą przechowywać do 2048 ETH. Dodatkowe ETH powyżej 32 będą się kumulować w sposób schodkowy, zwiększając saldo w przyrostach całkowitoliczbowych w miarę wzrostu rzeczywistego salda. Jest to znane jako saldo efektywne. + +Aby zwiększyć saldo efektywne konta, a tym samym zwiększyć nagrody, należy przekroczyć bufor 0,25 ETH powyżej dowolnego progu pełnego ETH. Na przykład konto z rzeczywistym saldem 32,9 i efektywnym saldem 32 musiałoby zarobić kolejne 0,35 ETH, aby jego rzeczywiste saldo przekroczyło 33,25, zanim nastąpi wzrost salda efektywnego. + +Ten bufor zapobiega również spadkowi salda efektywnego, dopóki nie spadnie ono o 0,25 ETH poniżej bieżącego salda efektywnego. -Nie należy deponować więcej niż 32 ETH dla jednego walidatora. Nie zwiększy to twoich nagród. Jeśli dla walidatora ustawiono adres wypłaty, nadwyżka środków powyżej 32 ETH zostanie automatycznie wypłacona na ten adres podczas następnego [przeniesienia walidatora](/staking/withdrawals/#validator-sweeping). +Każda para kluczy powiązana z walidatorem wymaga do aktywacji co najmniej 32 ETH. Każde saldo powyżej tej kwoty może zostać w dowolnym momencie wypłacone na powiązany adres do wypłat za pomocą transakcji podpisanej tym adresem. Wszelkie środki powyżej maksymalnego salda efektywnego będą automatycznie wypłacane okresowo. -Jeśli solo staking wydaje ci się zbyt wymagający, rozważ skorzystanie z [usług stakingowych](/staking/saas/) lub jeśli masz mniej niż 32 ETH, sprawdź [stakowanie w puli](/staking/pools/). +Jeśli stakowanie w domu wydaje Ci się zbyt wymagające, rozważ skorzystanie z dostawcy [stakingu jako usługi](/staking/saas/) lub, jeśli dysponujesz kwotą mniejszą niż 32 ETH, sprawdź [pule stakingowe](/staking/pools/). - -Przejście w tryb offline, podczas poprawnej finalizacji sieci, NIE spowoduje odcięcia. Niewielkie kary za brak aktywności są naliczane, jeśli walidator nie jest dostępny do poświadczania w danej epoce (każda o długości 6,4 minuty), ale różni się to znacznie od cięcia. Kary te są nieco niższe niż nagroda, którą można by uzyskać, gdyby walidator był dostępny do poświadczenia, a straty można odzyskać w przybliżeniu w takim samym czasie, jak w przypadku powrotu do trybu online. + +Przejście w tryb offline, gdy sieć prawidłowo finalizuje bloki, NIE spowoduje cięcia. Niewielkie kary za brak aktywności są naliczane, jeśli Twój walidator nie jest dostępny do poświadczania w danej epoce (każda o długości 6,4 minuty), ale różni się to znacznie od cięcia. Kary te są nieco niższe niż nagroda, którą można by uzyskać, gdyby walidator był dostępny do poświadczenia, a straty można odzyskać w przybliżeniu w takim samym czasie, jak w przypadku powrotu do trybu online. -Należy pamiętać, że kary za brak aktywności są proporcjonalne do liczby walidatorów znajdujących się w trybie offline w tym samym czasie. W przypadkach, gdy duża część sieci jest jednocześnie offline, kary dla każdego z tych walidatorów będą większe niż w przypadku niedostępności pojedynczego walidatora. +Należy pamiętać, że kary za brak aktywności są proporcjonalne do liczby walidatorów znajdujących się w trybie offline w tym samym czasie. W przypadkach, gdy duża część sieci jest jednocześnie offline, kary dla każdego z tych walidatorów będą wyższe niż w przypadku niedostępności pojedynczego walidatora. -W skrajnych przypadkach, jeśli sieć przestanie finalizować w wyniku tego, że ponad jedna trzecia walidatorów jest offline, użytkownicy ci ucierpią z powodu tak zwanego kwadratowego wycieku nieaktywności, który jest wykładniczym odpływem ETH z kont walidatorów offline. Pozwala to sieci na samoleczenie poprzez spalanie ETH nieaktywnych walidatorów, aż ich saldo osiągnie 16 ETH, w którym to momencie zostaną oni automatycznie usunięci z puli walidatorów. Pozostałe walidatory online ostatecznie ponownie obejmą ponad 2/3 sieci, spełniając większość potrzebną do ponownego sfinalizowania łańcucha. +W skrajnych przypadkach, jeśli sieć przestanie finalizować w wyniku tego, że ponad jedna trzecia walidatorów jest offline, użytkownicy ci ucierpią z powodu tak zwanego kwadratowego wycieku nieaktywności, który jest wykładniczym odpływem ETH z kont walidatorów offline. Umożliwia to sieci ostateczne samonaprawienie poprzez spalenie ETH nieaktywnych walidatorów, aż ich saldo osiągnie 16 ETH, po czym zostaną oni automatycznie usunięci z puli walidatorów. Pozostałe walidatory online ostatecznie ponownie będą stanowić ponad 2/3 sieci, spełniając warunek superwiększości potrzebny do ponownego sfinalizowania łańcucha. - -W skrócie mówiąc, nigdy nie można tego w pełni zagwarantować, ale jeśli działasz w dobrej wierze, uruchamiasz klienta mniejszościowego i przechowujesz klucze podpisujące tylko na jednym komputerze naraz, ryzyko odcięcia jest prawie zerowe. + +W skrócie, nigdy nie można tego w pełni zagwarantować, ale jeśli działasz w dobrej wierze, uruchamiasz klienta mniejszościowego i przechowujesz klucze do podpisu tylko na jednym urządzeniu naraz, ryzyko cięcia jest bliskie zeru. -Istnieje tylko kilka konkretnych sposobów, które mogą spowodować, że walidator zostanie odcięty i wyrzucony z sieci. W chwili pisania tego tekstu, cięcia, które miały miejsce, były wyłącznie wynikiem zbędnych konfiguracji sprzętowych, w których klucze podpisujące były przechowywane na dwóch oddzielnych komputerach jednocześnie. Może to nieumyślnie spowodować podwójne głosowanie z Twoich kluczy, co jest wykroczeniem podlegającym odcięciu. +Istnieje tylko kilka konkretnych sposobów, które mogą skutkować cięciem walidatora i usunięciem go z sieci. W chwili pisania tego tekstu, cięcia, które miały miejsce, były wyłącznie wynikiem nadmiarowych konfiguracji sprzętowych, w których klucze do podpisu były przechowywane na dwóch oddzielnych urządzeniach jednocześnie. Może to nieumyślnie skutkować podwójnym głosowaniem z Twoich kluczy, co jest wykroczeniem podlegającym cięciu. -Uruchomienie klienta superwiększościowego (dowolnego klienta używanego przez ponad 2/3 sieci) wiąże się również z ryzykiem potencjalnego odcięcia w przypadku, gdy klient ten ma błąd, który skutkuje rozwidleniem łańcucha. Może to skutkować błędnym forkiem, który zostanie sfinalizowany. Korekta z powrotem do zamierzonego łańcucha wymagałaby przesłania głosowania zaokrąglonego poprzez próbę cofnięcia sfinalizowanego bloku. Jest to również wykroczenie, za które można zostać odciętym, którego można uniknąć, po prostu uruchamiając klienta mniejszościowego. +Uruchamianie klienta superwiększościowego (każdego klienta używanego przez ponad 2/3 sieci) również niesie ze sobą ryzyko potencjalnego cięcia w przypadku, gdy klient ten ma błąd, który skutkuje forkiem łańcucha. Może to skutkować błędnym forkiem, który zostanie sfinalizowany. Korekta z powrotem do zamierzonego łańcucha wymagałaby przesłania głosowania otaczającego poprzez próbę cofnięcia sfinalizowanego bloku. To również jest wykroczenie, za które można zostać odciętym, którego można uniknąć, po prostu uruchamiając klienta mniejszościowego. Równoważne błędy w kliencie mniejszościowym nigdy nie zostałyby sfinalizowane, a zatem nigdy nie skutkowałyby głosowaniem zaokrąglonym i po prostu skutkowałyby karami za brak aktywności, a nie cięciem. -Poszczególne klienty mogą nieznacznie różnić się pod względem wydajności i interfejsu użytkownika, ponieważ każdy z nich jest opracowywany przez różne zespoły przy użyciu różnych języków programowania. To powiedziawszy, żaden z nich nie jest „najlepszy”. Wszyscy klienci produkcyjni są doskonałymi oprogramowaniami, które wykonuje te same podstawowe funkcje synchronizacji i interakcji z blockchainem. +Poszczególni klienci mogą nieznacznie różnić się pod względem wydajności i interfejsu użytkownika, ponieważ każdy z nich jest opracowywany przez różne zespoły przy użyciu różnych języków programowania. Niemniej jednak żaden z nich nie jest „najlepszy”. Wszyscy klienci produkcyjni to doskonałe oprogramowanie, które wykonuje te same podstawowe funkcje synchronizacji i interakcji z blockchainem. -Ponieważ wszyscy klienci produkcyjni zapewniają tę samą podstawową funkcjonalność, bardzo ważne jest, aby wybrać klienta mniejszościowego, czyli dowolnego klienta, który NIE jest obecnie używany przez większość walidatorów w sieci. Może to zabrzmieć nieintuicyjnie, ale uruchomienie klienta większościowego lub superwiększościowego zwiększa ryzyko cięcia w przypadku błędu w tym kliencie. Korzystanie z klienta mniejszościowego drastycznie ogranicza to ryzyko. +Ponieważ wszyscy klienci produkcyjni zapewniają tę samą podstawową funkcjonalność, bardzo ważne jest, aby wybrać klienta mniejszościowego, czyli dowolnego klienta, który NIE jest obecnie używany przez większość walidatorów w sieci. Może to zabrzmieć sprzecznie z intuicją, ale uruchomienie klienta większościowego lub superwiększościowego naraża Cię na zwiększone ryzyko cięcia w przypadku błędu w tym kliencie. Uruchomienie klienta mniejszościowego drastycznie ogranicza to ryzyko. -Dowiedz się więcej, dlaczego różnorodność klientów ma kluczowe znaczenie +Dowiedz się więcej, dlaczego różnorodność klientów jest kluczowa - -Chociaż wirtualny serwer prywatny (VPS) może być używany jako zamiennik sprzętu domowego, fizyczny dostęp i lokalizacja klienta walidatora ma znaczenie. Scentralizowane rozwiązania chmurowe, takie jak Amazon Web Services lub Digital Ocean, zapewniają wygodę polegającą na braku konieczności pozyskiwania i obsługi sprzętu kosztem centralizacji sieci. + +Chociaż wirtualny serwer prywatny (VPS) może być używany jako zamiennik sprzętu domowego, fizyczny dostęp i lokalizacja klienta walidatora mają znaczenie. Scentralizowane rozwiązania chmurowe, takie jak Amazon Web Services czy Digital Ocean, zapewniają wygodę polegającą na braku konieczności pozyskiwania i obsługi sprzętu, kosztem centralizacji sieci. -Im więcej klientów walidatora działa na jednym scentralizowanym rozwiązaniu pamięci w chmurze, tym bardziej niebezpieczne staje się to dla tych użytkowników. Każde zdarzenie, które spowoduje przejście w tryb offline tych dostawców, czy to przez atak, wymogi regulacyjne, czy po prostu przerwy w dostawie prądu/internetu, spowoduje, że każdy klient walidatora, który polega na tym serwerze, zostanie wyłączony w tym samym czasie. +Im więcej klientów walidatora działa na jednym scentralizowanym rozwiązaniu do przechowywania w chmurze, tym bardziej staje się to niebezpieczne dla tych użytkowników. Każde zdarzenie, które spowoduje odłączenie tych dostawców od sieci, czy to w wyniku ataku, wymogów regulacyjnych, czy po prostu przerw w dostawie prądu/internetu, spowoduje, że każdy klient walidatora, który polega na tym serwerze, zostanie w tym samym czasie odłączony od sieci. -Kary za bycie offline są proporcjonalne do tego, ile innych osób jest offline w tym samym czasie. Korzystanie z VPS znacznie zwiększa ryzyko, że kary za bycie offline będą bardziej dotkliwe, a także zwiększa ryzyko kwadratowego wycieku lub cięcia w przypadku, gdy przerwa jest wystarczająco duża. Aby zminimalizować własne ryzyko i ryzyko dla sieci, użytkownicy są zdecydowanie zachęcani do uzyskania i obsługi własnego sprzętu. +Kary za bycie offline są proporcjonalne do liczby innych osób, które są w tym samym czasie offline. Korzystanie z VPS znacznie zwiększa ryzyko, że kary za bycie offline będą bardziej dotkliwe, a także zwiększa ryzyko kwadratowego wycieku lub cięcia w przypadku, gdy awaria jest wystarczająco duża. Aby zminimalizować własne ryzyko i ryzyko dla sieci, użytkownicy są zdecydowanie zachęcani do pozyskania i obsługi własnego sprzętu. - + Wypłaty wszelkiego rodzaju z łańcucha śledzącego wymagają ustawienia poświadczeń wypłaty. -Nowi stakerzy ustawiają to w czasie generowania klucza i deponowania. Obecni stakerzy, którzy jeszcze tego nie ustawili, mogą zaktualizować swoje klucze, aby obsługiwały tę funkcję. +Nowi stakerzy ustawiają to w momencie generowania klucza i dokonywania depozytu. Obecni stakerzy, którzy jeszcze tego nie ustawili, mogą zaktualizować swoje klucze, aby obsługiwały tę funkcję. Po ustawieniu poświadczeń wypłaty, płatności nagród (skumulowane ETH przez początkowe 32) będą okresowo automatycznie dystrybuowane na adres wypłaty. @@ -195,11 +199,11 @@ Aby odblokować i otrzymać całe saldo z powrotem, należy również zakończy ## Dalsza lektura {#further-reading} -- [Katalog stakingu Ethereum](https://www.staking.directory/) — _Eridian i Spacesider_ -- [Problem różnorodności klientów Ethereum](https://hackernoon.com/ethereums-client-diversity-problem) — _@emmanuelawosika 2022 r._ -- [Wspieranie różnorodności klientów](https://www.attestant.io/posts/helping-client-diversity/) — _Jim McDonald 2022 r._ -- [Różnorodność klientów w warstwie konsensusu Ethereum](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) — _jmcook.eth 2022 r._ -- [Zakup sprzętu do walidacji Ethereum](https://www.youtube.com/watch?v=C2wwu1IlhDc) — _EthStaker 2022 r._ -- [Wskazówki dotyczące zapobieganiu cięciu Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) — _Raul Jordan 2020 r._ +- [Katalog stakingu Ethereum](https://www.staking.directory/) - _Eridian i Spacesider_ +- [Problem różnorodności klientów Ethereum](https://hackernoon.com/ethereums-client-diversity-problem) – _@emmanuelawosika 2022_ +- [Wspieranie różnorodności klientów](https://www.attestant.io/posts/helping-client-diversity/) – _Jim McDonald 2022_ +- [Różnorodność klientów w warstwie konsensusu Ethereum](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) – _jmcook.eth 2022_ +- [Jak kupić sprzęt dla walidatora Ethereum](https://www.youtube.com/watch?v=C2wwu1IlhDc) – _EthStaker 2022_ +- [Wskazówki dotyczące zapobiegania cięciom w Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) – _Raul Jordan 2020_ diff --git a/public/content/translations/pl/staking/withdrawals/index.md b/public/content/translations/pl/staking/withdrawals/index.md index 3575cd13622..2dc4cdb2828 100644 --- a/public/content/translations/pl/staking/withdrawals/index.md +++ b/public/content/translations/pl/staking/withdrawals/index.md @@ -1,10 +1,10 @@ --- -title: Wypłaty ze stakingu -description: Strona podsumowująca, czym są wypłaty ze stakingu i jak działają, a także co muszą zrobić stakerzy, aby otrzymać nagrody +title: "Wypłaty ze stakingu" +description: "Strona podsumowująca, czym są wypłaty ze stakingu i jak działają, a także co muszą zrobić stakerzy, aby otrzymać nagrody" lang: pl template: staking image: /images/staking/leslie-withdrawal.png -alt: Nosorożec Leslie z nagrodami ze stakingu +alt: "Nosorożec Leslie z nagrodami ze stakingu" sidebarDepth: 2 summaryPoints: - Aktualizacja Shanghai/Capella pozwoliła na wypłaty ze stakingu na Ethereum @@ -13,15 +13,11 @@ summaryPoints: - Walidatory, które w pełni opuszczą staking, otrzymają swoje pozostałe saldo --- - -Wypłaty ze stakingu zostały włączone wraz z aktualizacją Shanghai/Capella, która miała miejsce 12 kwietnia 2023 r. Więcej informacji o Shanghai/Capella - +**Wypłaty ze stakowania** odnoszą się do transferów ETH z konta walidatora w warstwie konsensusu Ethereum (łańcuch Beacon) do warstwy wykonawczej, na której można przeprowadzać transakcje. -**Wypłaty ze stakingu** odnoszą się do transferów ETH z konta walidatora w warstwie konsensusu Ethereum (łańcuch śledzący) do warstwy wykonawczej, w której można dokonywać transakcji. +**Wypłaty nagród za nadwyżkę salda** powyżej 32 ETH będą automatycznie i regularnie wysyłane na adres wypłaty powiązany z każdym walidatorem, po podaniu go przez użytkownika. Użytkownicy mogą również **całkowicie zrezygnować ze stakowania**, odblokowując swoje pełne saldo walidatora. -**Wypłaty nagród za nadwyżkę salda** powyżej 32 ETH będą automatycznie i regularnie wysyłane na adres wypłaty powiązany z każdym walidatorem, po podaniu go przez użytkownika. Użytkownicy mogą również **całkowicie opuścić stakowanie**, odblokowując prz tym ich pełne saldo walidatora. - -## Nagrody ze stakingu {#staking-rewards} +## Nagrody za stakowanie {#staking-rewards} Wypłaty nagród są automatycznie przetwarzane dla aktywnych kont walidatorów z maksymalnym efektywnym saldem 32 ETH. @@ -39,7 +35,7 @@ Przed aktualizacją Shanghai/Capella nie można było używać ani uzyskiwać do -### Ważne informacje {#important-notices} +### Ważne uwagi {#important-notices} Podanie adresu wypłaty jest wymaganym krokiem dla każdego konta walidatora, zanim będzie ono uprawnione do wypłaty ETH ze swojego salda. @@ -47,14 +43,14 @@ Podanie adresu wypłaty jest wymaganym krokiem dla każdego konta walidatora, za - Każde konto walidatora może mieć przypisany tylko jeden adres wypłaty, jeden raz. Po wybraniu adresu i przesłaniu go do warstwy konsensusu nie można tego cofnąć ani zmienić ponownie. Przed wysłaniem sprawdź dwukrotnie własność i poprawność podanego adresu. +Każdemu kontu walidatora można jednorazowo przypisać tylko jeden adres do wypłat. Po wybraniu i przesłaniu adresu do warstwy konsensusu nie można go cofnąć ani ponownie zmienić. Przed wysłaniem sprawdź dwukrotnie własność i poprawność podanego adresu. Nie ma żadnego zagrożenia dla twoich funduszy w międzyczasie za niedostarczenie tego, zakładając, że twoja fraza mnemoniczna/odzyskiwania pozostała bezpieczna offline i nie została w żaden sposób naruszona. Brak dodania danych uwierzytelniających do wypłaty spowoduje po prostu zablokowanie ETH na koncie walidatora do czasu podania adresu do wypłaty. -## Całkowite wyjście ze stakingu {#exiting-staking-entirely} +## Całkowita rezygnacja ze stakowania {#exiting-staking-entirely} Podanie adresu wypłaty jest wymagane, zanim _jakiekolwiek_ środki będą mogły zostać przelane z salda konta walidatora. @@ -62,11 +58,11 @@ Użytkownicy, którzy chcą całkowicie zrezygnować ze stakingu i wypłacić pe Proces wychodzenia walidatora ze stakingu zajmuje różną ilość czasu, w zależności od tego, ile innych osób wychodzi w tym samym czasie. Po zakończeniu, konto to nie będzie już odpowiedzialne za wykonywanie obowiązków walidatorów sieci, nie będzie już kwalifikować się do nagród i nie będzie już mieć swojego ETH „na szali”. W tym momencie konto zostanie oznaczone jako w pełni „wypłacalne”. -Po oznaczeniu konta jako „wypłacalne” i podaniu danych uwierzytelniających do wypłaty użytkownik nie musi nic więcej robić poza czekaniem. Konta są automatycznie i stale przenoszone przez wnioskodawców bloków pod kątem kwalifikujących się wycofanych środków, a saldo konta zostanie przelane w całości (znane również jako „pełna wypłata”) podczas następnej sesji przeniesienia. +Po oznaczeniu konta jako „wypłacalne” i podaniu danych uwierzytelniających do wypłaty użytkownik nie musi nic więcej robić poza czekaniem. Konta są automatycznie i nieustannie przeszukiwane przez proponujących bloki pod kątem kwalifikujących się środków z wyjścia, a saldo Twojego konta zostanie przelane w całości (co jest znane również jako „pełna wypłata”) podczas następnego przeglądu. -## Kiedy wypłaty ze stakingu są możliwe? {#when} +## Kiedy włączono wypłaty ze stakowania? {#when} -Wypłaty ze stakingu są już dostępne! Funkcja wypłat została włączona w ramach aktualizacji Shanghai/Capella, która miała miejsce 12 kwietnia 2023 r. +Funkcjonalność wypłat została włączona w ramach aktualizacji Shanghai/Capella, która miała miejsce **12 kwietnia 2023 r.**. Aktualizacja Shanghai/Capella umożliwiła odzyskanie wcześniej zestakowanych ETH na zwykłych kontach Ethereum. Zamknęło to pętlę płynności stakingu i przybliżyło Ethereum o krok na drodze do zbudowania zrównoważonego, skalowalnego i bezpiecznego zdecentralizowanego ekosystemu. @@ -77,13 +73,13 @@ Aktualizacja Shanghai/Capella umożliwiła odzyskanie wcześniej zestakowanych E To, czy dany walidator kwalifikuje się do wypłaty, czy nie, zależy od stanu samego konta walidatora. Żadne dane wejściowe użytkownika nie są potrzebne w żadnym momencie, aby określić, czy konto powinno mieć zainicjowaną wypłatę, czy nie — cały proces jest wykonywany automatycznie przez warstwę konsensusu w ciągłej pętli. -### Jesteś raczej wzrokowcem? {#visual-learner} +### Jesteś raczej wzrokowcem? Dla wzrokowców {#visual-learner} Sprawdź to wyjaśnienie dotyczące wypłat ze stakingu Ethereum przez Finematics: -### Walidator „przesunięcia” {#validator-sweeping} +### „Przegląd” walidatora {#validator-sweeping} Gdy walidator ma zaproponować następny blok, musi utworzyć kolejkę wypłat, składającą się z maksymalnie 16 kwalifikujących się wypłat. Odbywa się to poprzez pierwotne rozpoczęcie od indeksu walidatora 0, określając, czy istnieje kwalifikująca się wypłata dla tego konta zgodnie z zasadami protokołu i dodanie jej do kolejki, jeśli tak. Walidator ustawiony na proponowanie następnego bloku będzie kontynuował w miejscu, w którym poprzedni został pozostawiony, postępując w kolejności w nieskończoność. @@ -91,9 +87,9 @@ Gdy walidator ma zaproponować następny blok, musi utworzyć kolejkę wypłat, -Pomyśl o zegarku analogowym. Wskazówka na zegarze wskazuje godzinę, przesuwa się w jednym kierunku, nie pomija żadnych godzin i ostatecznie zawija się do początku po osiągnięciu ostatniej liczby.

-Teraz zamiast od 1 do 12, wyobraź sobie, że zegar ma od 0 do N (całkowita liczba kont walidatorów, które kiedykolwiek zostały zarejestrowane w warstwie konsensusu, ponad 500 000 — stan na styczeń 2023 r.).

-Wskazówka na zegarze wskazuje następny walidator, który należy sprawdzić pod kątem kwalifikujących się wypłat. Zaczyna od 0 i postępuje dookoła, nie pomijając żadnego konta. Po osiągnięciu ostatniego walidatora cykl jest kontynuowany od początku. +Pomyśl o zegarze analogowym. Wskazówka na zegarze wskazuje godzinę, porusza się w jednym kierunku, nie pomija żadnej godziny i w końcu wraca na początek po dotarciu do ostatniej liczby.

+Teraz wyobraź sobie, że zamiast od 1 do 12 zegar ma od 0 do N (całkowita liczba kont walidatorów, które kiedykolwiek zostały zarejestrowane w warstwie konsensusu, ponad 500 000 w styczniu 2023 r.).

+Wskazówka na zegarze wskazuje następnego walidatora, którego należy sprawdzić pod kątem kwalifikujących się wypłat. Zaczyna od 0 i przechodzi całą drogę dookoła, nie pomijając żadnego konta. Po dotarciu do ostatniego walidatora cykl rozpoczyna się od początku. @@ -103,15 +99,15 @@ Wskazówka na zegarze wskazuje następny walidator, który należy sprawdzić po Podczas gdy wnioskodawca przegląda walidatory pod kątem możliwych wypłat, każdy sprawdzany walidator jest oceniany pod kątem krótkiej serii pytań w celu ustalenia, czy należy uruchomić wypłatę, a jeśli tak, to ile ETH należy wypłacić. 1. **Czy został podany adres do wypłaty?** Jeśli nie podano adresu do wypłaty, konto zostanie pominięte i wypłata nie zostanie zainicjowana. -2. **Czy walidator wyszedł i jest wypłacalny?** Jeśli walidator całkowicie wyszedł, a my osiągnęliśmy epokę, w której jego konto jest uważane za „wypłacalne”, wówczas zostanie przetworzona pełna wypłata. Spowoduje to przeniesienie całego pozostałego salda na adres wypłaty. -3. **Czy efektywne saldo wynosi maksymalnie 32?** Jeśli konto ma dane uwierzytelniające do wypłaty, nie opuściło w pełni i ma oczekujące nagrody powyżej 32, zostanie przetworzona częściowa wypłata, która przeleje tylko nagrody powyżej 32 na adres wypłaty użytkownika. +2. **Czy walidator zrezygnował i środki są gotowe do wypłaty?** Jeśli walidator całkowicie zrezygnował i osiągnęliśmy epokę, w której jego konto jest uznawane za "gotowe do wypłaty", zostanie przetworzona pełna wypłata. Spowoduje to przeniesienie całego pozostałego salda na adres wypłaty. +3. **Czy saldo efektywne osiągnęło maksimum 32?** Jeśli konto ma poświadczenia wypłaty, nie zrezygnowało w pełni ze stakowania i ma oczekujące nagrody powyżej 32 ETH, zostanie przetworzona częściowa wypłata, która przeleje tylko nagrody powyżej 32 ETH na adres wypłaty użytkownika. Istnieją tylko dwa działania podejmowane przez operatorów walidatorów w trakcie cyklu życia walidatora, które bezpośrednio wpływają na ten przepływ: - Podanie danych uwierzytelniających do wypłaty, aby umożliwić dowolną formę wypłaty - Wyjście z sieci, które spowoduje całkowitą wypłatę -### Bez gazu {#gas-free} +### Brak opłat za gaz {#gas-free} Takie podejście do wypłat ze stakingu pozwala uniknąć konieczności ręcznego przesyłania transakcji z żądaniem wypłaty określonej kwoty ETH. Oznacza to, że **nie jest wymagany gaz (opłata transakcyjna)**, a wypłaty również nie konkurują o istniejącą przestrzeń blokową warstwy wykonawczej. @@ -124,33 +120,33 @@ Rozszerzając te obliczenia, możemy oszacować czas potrzebny na przetworzenie | Liczba wypłat | Czas realizacji | -| :-------------------: | :--------------: | -| 400,000 | 3,5 dnia | -| 500,000 | 4,3 dnia | -| 600,000 | 5,2 dnia | -| 700,000 | 6,1 dnia | -| 800,000 | 7,0 dni | +| :-----------: | :-------------: | +| 400 000 | 3,5 dnia | +| 500 000 | 4,3 dnia | +| 600 000 | 5,2 dnia | +| 700 000 | 6,1 dnia | +| 800 000 | 7 dni | Jak widać, spowalnia to wraz ze wzrostem liczby walidatorów w sieci. Wzrost liczby pominiętych slotów może proporcjonalnie spowolnić ten proces, ale generalnie będzie to wolniejsza strona możliwych wyników. -## Najczęściej zadawane pytania (FAQ) {#faq} +## Często zadawane pytania {#faq} -Nie, proces dostarczania danych uwierzytelniających do wypłaty jest jednorazowy i nie można go zmienić po przesłaniu. +Nie, proces podawania poświadczeń wypłaty jest jednorazowy i nie można go zmienić po jego przesłaniu. -Ustawiając adres wypłat warstwy wykonawczej, dane uwierzytelniające wypłat dla tego walidatora zostały trwale zmienione. Oznacza to, że stare poświadczenia nie będą już działać, a nowe poświadczenia będą kierować do konta warstwy wykonawczej. +Ustawienie adresu wypłat w warstwie wykonawczej powoduje trwałą zmianę poświadczeń wypłaty dla danego walidatora. Oznacza to, że stare poświadczenia nie będą już działać, a nowe poświadczenia będą kierować do konta warstwy wykonawczej. Adresy wypłat mogą być albo inteligentnym kontraktem (kontrolowanym przez jego kod), albo zewnętrznym kontem (EOA, kontrolowanym przez jego klucz prywatny). Obecnie konta te nie mają sposobu na przekazanie wiadomości z powrotem do warstwy konsensusu, która sygnalizowałaby zmianę poświadczeń walidatora, a dodanie tej funkcji dodałoby niepotrzebnej złożoności protokołu. @@ -158,23 +154,22 @@ Jako alternatywę dla zmiany adresu wypłaty dla konkretnego walidatora, użytko -Jeśli jesteś częścią [puli stakingowej](/staking/pools/) lub posiadasz tokeny stakingowe, powinieneś skontaktować się ze swoim dostawcą, aby uzyskać więcej informacji na temat sposobu obsługi wypłat ze stakingu, ponieważ każda usługa działa inaczej. - -Ogólnie rzecz biorąc, użytkownicy powinni mieć możliwość odzyskania swoich bazowych stakowanych ETH lub zmiany dostawcy stakingu, z którego korzystają. Jeśli dana pula staje się zbyt duża, środki mogą zostać wycofane, wypłacone i ponownie zestakowane u mniejszego dostawcy. Lub, jeśli zgromadziłeś wystarczającą ilość ETH, możesz [stakować z domu](/staking/solo/). +Jeśli jesteś częścią [puli stakowania](/staking/pools/) lub posiadasz tokeny do stakowania, skontaktuj się ze swoim dostawcą, aby uzyskać więcej szczegółów na temat obsługi wypłat ze stakowania, ponieważ każda usługa działa inaczej. +Ogólnie rzecz biorąc, użytkownicy powinni mieć możliwość odzyskania swoich bazowych stakowanych ETH lub zmiany dostawcy stakingu, z którego korzystają. Jeśli dana pula staje się zbyt duża, środki mogą zostać wycofane, wypłacone i ponownie zestakowane u mniejszego dostawcy. Lub, jeśli masz wystarczająco dużo ETH, możesz [stakować w domu](/staking/solo/). -Tak, o ile weryfikator podał adres do wypłaty. Należy to podać raz, aby początkowo umożliwić jakiekolwiek wypłaty, a następnie wypłaty nagród będą automatycznie wykonywane co kilka dni przy każdym przesunięciu walidatora. +Tak, pod warunkiem, że dla Twojego walidatora podano adres do wypłat. Należy to podać raz, aby początkowo umożliwić jakiekolwiek wypłaty, a następnie wypłaty nagród będą automatycznie wykonywane co kilka dni przy każdym przesunięciu walidatora. Nie, jeśli Twój walidator jest nadal aktywny w sieci, pełna wypłata nie nastąpi automatycznie. Wymaga to ręcznego zainicjowania dobrowolnego wyjścia. Gdy walidator zakończy proces wychodzenia i zakładając, że konto ma dane uwierzytelniające do wypłaty, wtedy pozostanie wypłacone pozostałe saldo podczas następnego przesunięcia walidatora. - -Wypłaty są zaprojektowane tak, aby były realizowane automatycznie, przenosząc wszelkie ETH, które nie wnoszą aktywnego wkładu do stawki. Obejmuje to pełne salda dla kont, które zakończyły proces wyjścia. +Wypłaty są zaprojektowane tak, aby były wypychane automatycznie, transferując wszelkie ETH, które nie przyczyniają się aktywnie do stakowania. Obejmuje to pełne salda dla kont, które zakończyły proces wyjścia. Nie jest możliwe ręczne żądanie wypłaty określonych kwot ETH. Operatorom walidatorów zaleca się odwiedzenie strony wypłaty Staking Launchpad, gdzie można znaleźć więcej szczegółów na temat przygotowania walidatora do wypłat, czasu wydarzeń i więcej szczegółów na temat działania wypłat. -Aby najpierw wypróbować swoją konfigurację w sieci testowej, odwiedź Holesky Testnet Staking Launchpad, aby rozpocząć. - +Aby najpierw wypróbować swoją konfigurację w sieci testowej, odwiedź Hoodi Testnet Staking Launchpad, aby rozpocząć. @@ -220,8 +213,8 @@ Nie. Po wyjściu walidatora i wypłaceniu jego pełnego salda wszelkie dodatkowe ## Dalsza lektura {#further-reading} -- [Wypłaty Staking Launchpad](https://launchpad.ethereum.org/withdrawals) -- [EIP-4895: Wypłaty z łańcucha śledzącego jako operacje](https://eips.ethereum.org/EIPS/eip-4895) -- [PEEPanEIP #94: Wypłata zestakowanego ETH (testowanie) z Potuz & Hsiao-Wei Wang](https://www.youtube.com/watch?v=G8UstwmGtyE) -- [PEEPanEIP#68: EIP-4895: Wypłaty push łańcucha śledzącego jako operacje z Alexem Stokesem](https://www.youtube.com/watch?v=CcL9RJBljUs) -- [Zrozumienie efektywnego bilansu walidatora](https://www.attestant.io/posts/understanding-validator-effective-balance/) +- [Wypłaty w Staking Launchpad](https://launchpad.ethereum.org/withdrawals) +- [EIP-4895: Wypłaty push z łańcucha Beacon jako operacje](https://eips.ethereum.org/EIPS/eip-4895) +- [PEEPanEIP #94: Wypłata stakowanego ETH (testowanie) z udziałem Potuz i Hsiao-Wei Wang](https://www.youtube.com/watch?v=G8EsUstwmGtyE) +- [PEEPanEIP#68: EIP-4895: Wypłaty push z łańcucha Beacon jako operacje z Alexem Stokesem](https://www.youtube.com/watch?v=CcL9RJBljUs) +- [Zrozumieć efektywne saldo walidatora](https://www.attestant.io/posts/understanding-validator-effective-balance/) diff --git a/public/content/translations/pl/web3/index.md b/public/content/translations/pl/web3/index.md index 8c184abddc5..8694c8f7f46 100644 --- a/public/content/translations/pl/web3/index.md +++ b/public/content/translations/pl/web3/index.md @@ -1,18 +1,23 @@ --- -title: Co to jest Web3 i dlaczego jest ważny? -description: Wprowadzenie do Web3 — kolejnej ewolucji sieci WWW — i dlaczego ma znaczenie. +title: "Co to jest Web3 i dlaczego jest ważny?" +description: "Wprowadzenie do Web3 — kolejnej ewolucji sieci WWW — i dlaczego ma znaczenie." lang: pl --- # Wprowadzenie do Web3 {#introduction} +
+ +
+ Centralizacja pomogła miliardom ludzi wejść do sieci World Wide Web i stworzyła stabilną, niezawodną infrastrukturę, na której się opiera. Jednocześnie garstka scentralizowanych podmiotów kontroluje duże obszary sieci World Wide Web, jednostronnie decydując, co powinno, a co nie powinno być dozwolone. -Web3 jest odpowiedzią na ten dylemat. Zamiast sieci zmonopolizowanej przez duże firmy technologiczne, Web3 jest zdecentralizowany i jest tworzony, obsługiwany i jest własnością użytkowników. Web3 oddaje władzę w ręce osób indywidualnych, a nie korporacji. Zanim porozmawiamy o Web3, dowiedzmy się, jak się tu znaleźliśmy. +Web3 jest odpowiedzią na ten dylemat. Zamiast sieci zmonopolizowanej przez duże firmy technologiczne, Web3 jest zdecentralizowany i jest tworzony, obsługiwany i jest własnością użytkowników. Web3 oddaje władzę w ręce osób indywidualnych, a nie korporacji. +Zanim porozmawiamy o Web3, dowiedzmy się, jak się tu znaleźliśmy. -## Wczesna sieć {#early-internet} +## Wczesny Internet {#early-internet} Większość ludzi myśli o sieci jak o ciągłym filarze współczesnego życia — została wynaleziona i od tego czasu po prostu istnieje. Jednak sieć, którą większość z nas zna dzisiaj, znacznie różni się od pierwotnych wyobrażeń. Aby lepiej to zrozumieć, warto podzielić krótką historię sieci na kilka okresów — Web 1.0 i Web 2.0. @@ -22,27 +27,27 @@ W 1989 roku, w CERN w Genewie, Tim Berners-Lee był zajęty opracowywaniem proto Pierwsza odsłona dzieła Bernersa-Lee, obecnie znanego jako „Web 1.0”, miała miejsce mniej więcej w latach 1990-2004. Web 1.0 było głównie statycznymi stronami internetowymi należącymi do firm, a interakcja między użytkownikami była bliska zeru — osoby rzadko tworzyły treści — co doprowadziło do tego, że było znane jako sieć tylko do odczytu. -![Architektura klient-serwer reprezentująca Web 1.0](./web1.png) +![Architektura klient-serwer, reprezentująca Web 1.0](./web1.png) ### Web 2.0: Odczyt i zapis (2004-teraz) {#web2} Okres Web 2.0 rozpoczął się w 2004 roku wraz z pojawieniem się platform mediów społecznościowych. Zamiast tylko do odczytu, sieć ewoluowała do odczytu i zapisu. Zamiast dostarczać treści użytkownikom, firmy zaczęły również dostarczać platformy do udostępniania treści wygenerowanych przez użytkowników i angażowania się w interakcje między użytkownikami. W miarę coraz większej ilości korzystającej z Internetu garstka czołowych firm zaczęła kontrolować nieproporcjonalnie dużą część ruchu i wartości generowanej w sieci. Web 2.0 zapoczątkował również model przychodów oparty na reklamach. Podczas gdy użytkownicy mogli tworzyć treści, nie byli ich właścicielami ani nie czerpali korzyści z ich monetyzacji. -![Architektura klient-serwer reprezentująca Web 2.0](./web2.png) +![Architektura klient-serwer, reprezentująca Web 2.0](./web2.png) ## Web 3.0: Odczyt, zapis i posiadanie {#web3} -Założenie „Web 3.0” zostało wymyślone przez współzałożyciela [Ethereum](/what-is-ethereum/) Gavina Wooda wkrótce po uruchomieniu Ethereum w 2014 roku. Gavin przedstawił rozwiązanie problemu, który odczuwało wielu wczesnych użytkowników kryptowalut: sieć wymagała zbyt dużego zaufania. Oznacza to, że większość sieci, którą ludzie znają i używają dzisiaj, opiera się na zaufaniu garstce prywatnych firm, które działają w najlepszym interesie publicznym. +Założenie „Web 3.0” zostało wymyślone przez współzałożyciela [Ethereum](/what-is-ethereum/), Gavina Wooda, wkrótce po uruchomieniu Ethereum w 2014 roku. Gavin przedstawił rozwiązanie problemu, który odczuwało wielu wczesnych użytkowników kryptowalut: sieć wymagała zbyt dużego zaufania. Oznacza to, że większość sieci, którą ludzie znają i używają dzisiaj, opiera się na zaufaniu garstce prywatnych firm, które działają w najlepszym interesie publicznym. -![Zdecentralizowana architektura węzłów reprezentująca Web3](./web3.png) +![Zdecentralizowana architektura węzłów, reprezentująca Web3](./web3.png) ### Co to jest Web3? {#what-is-web3} -Web3 stał się terminem określającym wizję nowego, lepszego Internetu. U podstaw, Web3 wykorzystuje blockchainy, kryptowaluty i NFT, aby oddać władzę użytkownikom w formie własności. [Post z 2020 roku na Twitterze](https://twitter.com/himgajria/status/1266415636789334016) ujął to najlepiej: Web1 był tylko do odczytu, Web2 jest do odczytu i zapisu, Web3 będzie do odczytu, zapisu i posiadania. +Web3 stał się terminem określającym wizję nowego, lepszego Internetu. U podstaw, Web3 wykorzystuje blockchainy, kryptowaluty i NFT, aby oddać władzę użytkownikom w formie własności. [Post na Twitterze z 2020 roku](https://twitter.com/himgajria/status/1266415636789334016) ujął to najlepiej: Web1 był tylko do odczytu, Web2 jest do odczytu i zapisu, Web3 będzie do odczytu, zapisu i posiadania. -#### Główne założenia Web3 {#core-ideas} +#### Podstawowe idee Web3 {#core-ideas} Chociaż trudno jest podać dokładną definicję tego, czym jest Web3, kilka podstawowych zasad kieruje jego tworzeniem. @@ -59,7 +64,7 @@ Chociaż zabójcze funkcje Web3 nie są odizolowane i nie pasują do oddzielnych Web3 daje Ci prawo własności do Twoich zasobów cyfrowych w bezprecedensowy sposób. Załóżmy na przykład, że grasz w grę web2. Jeśli kupisz przedmiot w grze, jest on powiązany bezpośrednio z Twoim kontem. Jeśli twórcy gry usuną Twoje konto, stracisz te przedmioty. Lub, jeśli przestaniesz grać w grę, stracisz wartość zainwestowaną w przedmioty w grze. -Web3 pozwala na bezpośrednią własność poprzez [niewymienialne tokeny (NFT)](/glossary/#nft). Nikt, nawet twórcy gry, nie ma prawa odebrać ci Twoich własności. A jeśli przestaniesz grać, możesz sprzedać lub wymienić swoje przedmioty w grze na otwartych rynkach i odzyskać ich wartość. +Web3 pozwala na bezpośrednią własność poprzez [niewymienialne tokeny (NFT)](/glossary/#nft). Nikt, nawet twórcy gry, nie ma prawa odebrać ci Twoich własności. A jeśli przestaniesz grać, możesz sprzedać lub wymienić swoje przedmioty w grze na otwartych rynkach i odzyskać ich wartość. Odkryj [gry onchain](/gaming/), aby zobaczyć to w akcji. @@ -81,7 +86,7 @@ W Web3 dane użytkownika znajdują się w blockchainie. Kiedy zdecydujesz się o Web 2.0 wymaga od twórców treści zaufania platformom, że nie zmienią zasad, ale odporność na cenzurę jest natywną cechą platformy Web3. -#### Zdecentralizowane autonomiczne organizacje (DAO) {#daos} +#### Zdecentralizowane organizacje autonomiczne (DAO) {#daos} Oprócz posiadania swoich danych, w Web3 możesz być właścicielem platformy jako grupy, używając tokenów, które działają jak udziały w firmie. DAO pozwalają koordynować zdecentralizowaną własność platformy i podejmować decyzje dotyczące jej przyszłości. @@ -94,7 +99,7 @@ Ludzie jednak definiują wiele społeczności Web3 jako DAO. Wszystkie te społe
Dowiedz się więcej o DAO
- Więcej informacji o: DAO + Więcej o DAO @@ -103,31 +108,32 @@ Ludzie jednak definiują wiele społeczności Web3 jako DAO. Wszystkie te społe Tradycyjnie należałoby utworzyć konto dla każdej używanej platformy. Na przykład, możesz mieć konto na Twitterze, konto na YouTubie i konto na Reddit. Chcesz zmienić wyświetlaną nazwę lub zdjęcie profilowe? Musisz to zrobić na każdym koncie. W niektórych przypadkach można korzystać z logowania społecznościowego, ale wiąże się to z dobrze znanym problemem — cenzurą. Za pomocą jednego kliknięcia platformy te mogą zablokować dostęp do całego Twojego życia online. Co gorsza, wiele platform wymaga od użytkownika zaufania do nich i podania danych osobowych w celu utworzenia konta. -Web3 rozwiązuje te problemy, umożliwiając kontrolowanie cyfrowej tożsamości za pomocą adresu Ethereum i profilu [Ethereum Name Service (ENS)](/glossary/#ens). Korzystanie z adresu Ethereum zapewnia pojedynczy login na różnych platformach, który jest bezpieczny, odporny na cenzurę i anonimowy. +Web3 rozwiązuje te problemy, umożliwiając kontrolowanie swojej tożsamości cyfrowej za pomocą adresu Ethereum i profilu [Usługi nazw Ethereum (ENS)](/glossary/#ens). Korzystanie z adresu Ethereum zapewnia pojedynczy login na różnych platformach, który jest bezpieczny, odporny na cenzurę i anonimowy. ### Natywne płatności {#native-payments} -Infrastruktura płatności Web2 opiera się na bankach i przetwórcach płatności, wykluczając osoby bez kont bankowych lub te, które mieszkają w granicach niewłaściwego kraju. Web3 wykorzystuje takie tokeny jak [ETH](/glossary/#ether) do wysyłania pieniędzy bezpośrednio w przeglądarce i nie wymaga zaufanej strony trzeciej. +Infrastruktura płatności Web2 opiera się na bankach i przetwórcach płatności, wykluczając osoby bez kont bankowych lub te, które mieszkają w granicach niewłaściwego kraju. +Web3 wykorzystuje tokeny, takie jak [ETH](/glossary/#ether), do wysyłania pieniędzy bezpośrednio w przeglądarce i nie wymaga zaufanej strony trzeciej. Więcej na temat ETH -## Ograniczenia sieci Web3 {#web3-limitations} +## Ograniczenia Web3 {#web3-limitations} Pomimo licznych zalet Web3 w jego obecnej formie, nadal istnieje wiele ograniczeń, które ekosystem musi rozwiązać, aby mógł on się rozwijać. ### Dostępność {#accessibility} -Ważne funkcje Web3, takie jak logowanie za pomocą Ethereum, są już dostępne dla każdego bez ponoszenia żadnych kosztów. Jednak względny koszt transakcji jest nadal zbyt wysoki dla wielu osób. Jest mniej prawdopodobne, że Web3 będzie wykorzystywany w mniej zamożnych, rozwijających się krajach ze względu na wysokie opłaty transakcyjne. W Ethereum wyzwania te rozwiązywane są poprzez [plan działania](/roadmap/) i [rozwiązania do skalowania warstwy 2](/glossary/#layer-2). Technologia jest gotowa, ale potrzebujemy wyższego poziomu wykorzystania warstwy 2, aby Web3 był dostępny dla każdego. +Ważne funkcje Web3, takie jak logowanie za pomocą Ethereum, są już dostępne dla każdego bez ponoszenia żadnych kosztów. Jednak względny koszt transakcji jest nadal zbyt wysoki dla wielu osób. Jest mniej prawdopodobne, że Web3 będzie wykorzystywany w mniej zamożnych, rozwijających się krajach ze względu na wysokie opłaty transakcyjne. W Ethereum wyzwania te są rozwiązywane poprzez [plan działania](/roadmap/) i [rozwiązania skalujące warstwy 2](/glossary/#layer-2). Technologia jest gotowa, ale potrzebujemy wyższego poziomu wykorzystania warstwy 2, aby Web3 był dostępny dla każdego. ### Doświadczenie użytkownika {#user-experience} -Techniczna bariera wejścia do korzystania z Web3 jest obecnie zbyt wysoka. Użytkownicy muszą zrozumieć kwestie bezpieczeństwa, zrozumieć złożoną dokumentację techniczną i poruszać się po nieintuicyjnych interfejsach użytkownika. W szczególności [dostawcy portfeli](/wallets/find-wallet/) pracują nad rozwiązaniem tego problemu, ale potrzebne są dalsze postępy, zanim Web3 zostanie masowo przyjęty. +Techniczna bariera wejścia do korzystania z Web3 jest obecnie zbyt wysoka. Użytkownicy muszą zrozumieć kwestie bezpieczeństwa, zrozumieć złożoną dokumentację techniczną i poruszać się po nieintuicyjnych interfejsach użytkownika. [Dostawcy portfeli](/wallets/find-wallet/), w szczególności, pracują nad rozwiązaniem tego problemu, ale potrzebne są dalsze postępy, zanim Web3 zostanie masowo przyjęty. ### Edukacja {#education} -Web3 wprowadza nowe standardy, które wymagają uczenia się innych modeli mentalnych niż te używane w Web2.0. Podobna akcja edukacyjna miała miejsce, gdy Web1.0 zyskiwał popularność pod koniec lat 90. ; zwolennicy sieci WWW wykorzystali mnóstwo technik edukacyjnych, aby edukować społeczeństwo, od prostych metafor (infostrady, przeglądarki, surfowanie po sieci) po [transmisje telewizyjne](https://www.youtube.com/watch?v=SzQLI7BxfYI). Web3 nie jest trudny, ale jest inny. Inicjatywy edukacyjne informujące użytkowników Web2 o tych modelach Web3 są niezbędne dla jego sukcesu. +Web3 wprowadza nowe standardy, które wymagają uczenia się innych modeli mentalnych niż te używane w Web2.0. Podobna akcja edukacyjna miała miejsce, gdy Web1.0 zyskiwał popularność pod koniec lat 90.; zwolennicy sieci WWW wykorzystali mnóstwo technik edukacyjnych, aby edukować społeczeństwo, od prostych metafor (infostrady, przeglądarki, surfowanie po sieci) po [transmisje telewizyjne](https://www.youtube.com/watch?v=SzQLI7BxfYI). Web3 nie jest trudny, ale jest inny. Inicjatywy edukacyjne informujące użytkowników Web2 o tych modelach Web3 są niezbędne dla jego sukcesu. Ethereum.org przyczynia się do edukacji Web3 poprzez nasz [Program Tłumaczeń](/contributing/translation-program/), mający na celu przetłumaczenie ważnych treści Ethereum na jak najwięcej języków. @@ -143,21 +149,21 @@ Jesteśmy dopiero na początku tworzenia lepszej sieci z Web3, ale ponieważ nad ## Jak mogę się zaangażować {#get-involved} -- [Wybierz portfel](/wallets/) +- [Zdobądź portfel](/wallets/) - [Znajdź społeczność](/community/) - [Odkryj aplikacje Web3](/apps/) - [Dołącz do DAO](/dao/) -- [Buduj na Web3](/developers/) +- [Twórz w Web3](/developers/) -## Dodatkowo przeczytaj {#further-reading} +## Dalsza lektura {#further-reading} Web3 nie jest jednoznacznie zdefiniowany. Różni uczestnicy społeczności mają na to różne spojrzenia. Oto kilka z nich: -- [Czym jest Web3? Wyjaśnienie zdecentralizowanego Internetu przyszłości](https://www.freecodecamp.org/news/what-is-web3) — _Nader Dabit_ -- [Zrozumieć Web3](https://medium.com/l4-media/making-sense-of-web-3-c1a9e74dcae) — _Josh Stark_ -- [Dlaczego Web3 ma znaczenie](https://future.a16z.com/why-web3-matters/) — _Chris Dixon_ -- [Dlaczego decentralizacja ma znaczenie](https://onezero.medium.com/why-decentralization-matters-5e3f79f7638e) — _Chris Dixon_ -- [Wygląd Web3](https://a16z.com/wp-content/uploads/2021/10/The-web3-Readlng-List.pdf) — _a16z_ -- [Debata o Web3](https://www.notboring.co/p/the-web3-debate) — _Packy McCormick_ +- [Czym jest Web3? [Wyjaśnienie zdecentralizowanego internetu przyszłości](https://www.freecodecamp.org/news/what-is-web3) – _Nader Dabit_ +- [Zrozumieć Web 3](https://medium.com/l4-media/making-sense-of-web-3-c1a9e74dcae) – _Josh Stark_ +- [Dlaczego Web3 ma znaczenie](https://a16zcrypto.com/posts/article/why-web3-matters/) — _Chris Dixon_ +- [Dlaczego decentralizacja ma znaczenie](https://onezero.medium.com/why-decentralization-matters-5e3f79f7638e) - _Chris Dixon_ +- [Krajobraz Web3](https://a16z.com/wp-content/uploads/2021/10/The-web3-Readlng-List.pdf) – _a16z_ +- [Debata o Web3](https://www.notboring.co/p/the-web3-debate) – _Packy McCormick_ diff --git a/public/content/translations/pl/what-are-apps/index.md b/public/content/translations/pl/what-are-apps/index.md new file mode 100644 index 00000000000..7a07bfcb34c --- /dev/null +++ b/public/content/translations/pl/what-are-apps/index.md @@ -0,0 +1,80 @@ +--- +title: Aplikacje Ethereum +metaTitle: Aplikacje Ethereum | Zdecentralizowane aplikacje na sieci Ethereum +description: "Aplikacje na sieci Ethereum są darmowe, globalne i używają publicznego łańcucha bloków zamiast serwerów prywatnej firmy To oznacza, że możesz używać tego samego konta w każdym projekcie, zachowując swoją prywatność." +lang: pl +template: use-cases +emoji: ":handshake:" +sidebarDepth: 2 +showDropdown: false +image: /images/doge-computer.png +summary: "Aplikacje na sieci Ethereum są darmowe, globalne i używają publicznego łańcucha bloków zamiast serwerów prywatnej firmy To oznacza, że możesz używać tego samego konta w każdym projekcie, zachowując swoją prywatność." +--- + +## Aplikacje z supermocami {#apps-with-superpowers} + +Aplikacje Ethereum mogą sprawiać wrażenie normalnych aplikacji. Ale na zapleczu mają one specjalne właściwości. + +W momencie opublikowania na sieci Ethereum staje się ona niemożliwa do zatrzymania. Dzieje się tak, ponieważ sieć Ethereum jest zdecentralizowana pośród tysięcy komputerów na całym świecie. Nikt nie może wyłączyć aplikacji działających na sieci Ethereum, ponieważ nie ma jednego konkretnego serwera, który można wziąć za cel. Ethereum jest także neutralne i dlatego każdy, gdziekolwiek jest na świecie, może go używać lub nawet połączyć się z nim i budować na nim swoje modyfikacje. + +## Co to jest dapka? {#what-is-a-dapp} + +Aplikacje Ethereum mają swoją logikę działania na łańcuchu bloków Ethereum zamiast na scentralizowanym serwerze. Właśnie dlatego często były nazywane zdecentralizowanymi aplikacjami czy, w skrócie, dapkami. + + + + + + + +## Dlaczego ma to znacznie {#why-does-this-matter} + +Aplikacje Ethereum mogą robić rzeczy, które nie są niewykonalne dla tradycyjnych apek. Na przykład pożyczyć pieniądze nieznajomemu z gwarancją, że otrzymasz je z powrotem, razem z odsetkami. Bez opłacania "zaufanego" pośrednika, takiego jak prawnik, który obsłuży tę transakcję. + +Są to aplikacje do wszystkiego: grania, finansów, pracy, komunikacji, przechowywania i wielu innych zastosowań. W przypadku większości aplikacji nie jesteś zmuszany do oglądania reklam czy ograniczony zastrzeżonym dostępem. + +Wystarczy portfel Ethereum i odrobina ETH, aby zacząć korzystać z dowolnej aplikacji Ethereum. + +## Jak to działa {#how-does-it-work} + +Aplikacje są zasilane przez inteligentne kontrakty- fragmenty kodu, które żyją na łańcuchu bloków Ethereum. W przeciwieństwie do tradycyjnych apek nie potrzebują firmy, aby działać. + +| Funkcja | Tradycyjne aplikacje | Aplikacje Ethereum | +| ---------------------------------------- | ------------------------ | -------------------------------- | +| **Kto ją kontroluje?** | Firma | Nikt | +| **Działa na** | Serwerze prywatnej firmy | Publicznym blockchainie Ethereum | +| **Czy może zostać ocenzurowana?** | Tak | Nie | +| **Kto jest właścicielem Twoich danych?** | Zwykle nie Ty | Ty | + + + +
+ +![](./developers-eth-blocks.png) +
+ +## Aplikacje Ethereum są jak klocki lego {#ethereum-apps-are-like-legos} + +Gdy wszystkie aplikacje są oparte na Ethereum, wszystkie są ze sobą kompatybilne. Token dla jednej apki zadziała również dla kompletnie innej. To jakbyś mógł publikować tweety na Facebooku. Możesz nawet wykorzystać ten sam profil w różnych apkach Ethereum bez konieczności osobnej rejestracji. + + + +## Dalsza lektura {#further-reading} + +- [Ethereum dla początkujących](/what-is-ethereum) +- [Czym są inteligentne kontrakty?](/developers/docs/smart-contracts/) +- [Dokumentacja techniczna dapek](/developers/docs/dapps/) + +## Często zadawane pytania {#faq} + + +

Dapka oznaczna zdecentralizowaną aplikację. Są to aplikacje zbudowane na łańcuchu bloków takich jak Ethereum. Nazywane są zdecentralizowanymi, ponieważ leżąca u podstaw sieć jest zdecentralizowana.

+ + + +

Niektóre aplikacje umożliwiają handel lub zakup krypto tokenów, ale nie wszystkie aplikacje są do tego przeznaczone. Jeśli chcesz kupić swoje pierwsze tokeny, odwiedź stronę [Zdobądź ETH](/get-eth).

+ + + +

Portfele krypto pozwalają Ci przechowywać swoje tokeny i zarządzać Twoim kontem Ethereum. Istnieje wiele świetnych portfeli, z których każdy ma inne przeznaczenie. Aby dowiedzieć się, który portfel jest dla Ciebie najlepszy, odwiedź naszą [listę portfeli](/wallets/find-wallet).

+ \ No newline at end of file diff --git a/public/content/translations/pl/whitepaper/index.md b/public/content/translations/pl/whitepaper/index.md index 29fbf261ab4..2a698b81e5f 100644 --- a/public/content/translations/pl/whitepaper/index.md +++ b/public/content/translations/pl/whitepaper/index.md @@ -1,427 +1,461 @@ --- -title: Biała księga Ethereum -description: Dokument wprowadzający do Ethereum, opublikowany w 2013 r. przed jego uruchomieniem. +title: "Biała księga Ethereum" +description: "Dokument wprowadzający do Ethereum, opublikowany w 2013 r. przed jego uruchomieniem." lang: pl sidebarDepth: 2 +hideEditButton: true --- # Biała księga Ethereum {#ethereum-whitepaper} -_Ten dokument wprowadzający został pierwotnie opublikowany w 2013 r. przez Vitalika Buterina, założyciela [Ethereum](/what-is-ethereum/), przed uruchomieniem projektu w 2015 r. Warto zauważyć, że Ethereum, podobnie jak wiele projektów oprogramowania opartych na społecznościach, rozwija się od czasu jego początkowego powstania._ +_Ten dokument wprowadzający został pierwotnie opublikowany w 2014 r. przez Vitalika Buterina, założyciela [Ethereum](/what-is-ethereum/), przed uruchomieniem projektu w 2015 r. Warto zauważyć, że Ethereum, podobnie jak wiele projektów oprogramowania open-source tworzonych przez społeczność, ewoluowało od czasu powstania._ -_Przez okres kilkunastu lat, utrzymujemy ten dokument, ponieważ nadal służy on jako użyteczny punkt odniesienia i dokładna reprezentacja Ethereum i jego wizji. Aby dowiedzieć się o najnowszych zmianach w Ethereum i jak wprowadzone są zmiany w protokole, zalecamy [ten przewodnik](/learn/)._ +_Chociaż ten dokument ma już kilka lat, zachowujemy go, ponieważ nadal służy on jako użyteczny punkt odniesienia i dokładna reprezentacja Ethereum i jego wizji. _Aby dowiedzieć się o najnowszych zmianach w Ethereum i o tym, jak wprowadzane są zmiany w protokole, polecamy [ten przewodnik](/learn/)._ -## Inteligentny kontrakt nowej generacji i zdecentralizowana platforma aplikacji {#a-next-generation-smart-contract-and-decentralized-application-platform} +[Badacze i naukowcy poszukujący historycznej lub kanonicznej wersji białej księgi [z grudnia 2014 r.] powinni skorzystać z tego pliku PDF.](./whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf) -Rozwój Bitcoina przez Satoshi Nakamoto w 2009 roku był często chwalony jako radykalny rozwój pieniądza i waluty, będący pierwszym przykładem zasobu cyfrowego, który jednocześnie nie ma wsparcia lub [wartości](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/) i brak scentralizowanego emitenta lub kontrolera. Jednak kolejna - prawdopodobnie ważniejsza - część eksperymentu Bitcoin to podstawowa technologia blockchain jako narzędzie rozproszonego konsensusu i uwaga szybko zaczyna się przechodzić na ten inny aspekt Bitcoina. Często cytowane alternatywne zastosowania technologii blockchain obejmują użycie zasobów cyfrowych w blockchain do reprezentowania niestandardowych walut oraz instrumentów finansowych ([kolorowych monet](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)), własność podstawowego urządzenia fizycznego ([smart property](https://en.bitcoin.it/wiki/Smart_Property)), aktywów niezamiennych takich jak nazwy domen ([Namecoin](http://namecoin.org)), dodatkowo jako bardziej złożone aplikacje polegające na tym, że aktywa cyfrowe są kontrolowane bezpośrednio przez element kodu, wdrażający arbitralne reguły ([inteligentnych kontraktów](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html)) lub nawet blockchain [zdecentralizowanych autonomicznych organizacji](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/) (DAO). To, co zamierza zapewnić Ethereum, to blockchain z wbudowanym w pełni rozwiniętym językiem programowania Turinga, którego można użyć, by tworzyć „kontrakty”, które mogą być użyte do zakodowania dowolnej zmiany stanu funkcji, pozwalającej użytkownikom na tworzenie dowolnych z opisanych powyżej systemów, a także wiele innych, których jeszcze nie wyobrażaliśmy sobie, po prostu pisząc logikę w kilku linijkach kodu. +## Platforma nowej generacji dla inteligentnych kontraktów i zdecentralizowanych aplikacji {#a-next-generation-smart-contract-and-decentralized-application-platform} + +Stworzenie Bitcoina przez Satoshi Nakamoto w 2009 roku było często uznawane za radykalny krok w rozwoju pieniądza i waluty, będąc pierwszym przykładem cyfrowego aktywa, które jednocześnie nie ma zabezpieczenia ani „[wartości wewnętrznej](https://bitcoinmagazine.com/culture/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it)” oraz nie ma scentralizowanego emitenta ani kontrolera. Jednak kolejną, prawdopodobnie ważniejszą częścią eksperymentu Bitcoin jest leżąca u jego podstaw technologia blockchain jako narzędzia rozproszonego konsensusu i uwaga szybko zaczyna przesuwać się na ten inny aspekt Bitcoina. Często cytowane alternatywne zastosowania technologii blockchain obejmują wykorzystanie cyfrowych zasobów w łańcuchu bloków do reprezentowania niestandardowych walut i instrumentów finansowych („[kolorowe monety](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)”), własność podstawowego urządzenia fizycznego („[inteligentna własność](https://en.bitcoin.it/wiki/Smart_Property)”), aktywa niewymienialne, takie jak nazwy domen („[Namecoin](http://namecoin.org)”), a także bardziej złożone aplikacje, w których zasoby cyfrowe są bezpośrednio kontrolowane przez fragment kodu implementujący dowolne zasady („[inteligentne kontrakty](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html)”), a nawet oparte na blockchainie „[zdecentralizowane organizacje autonomiczne](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/)” (DAO). To, co Ethereum zamierza zapewnić, to blockchain z wbudowanym w pełni rozwiniętym językiem programowania z kompletnością Turinga, który może być używany do tworzenia „kontraktów”, które mogą być używane do zakodowania dowolnych funkcji przejścia stanu, umożliwiając użytkownikom tworzenie dowolnego z opisanych powyżej systemów, a także wielu innych, których jeszcze sobie nie wyobrażamy, po prostu poprzez zapisanie logiki w kilku wierszach kodu. ## Wprowadzenie do Bitcoina i istniejących koncepcji {#introduction-to-bitcoin-and-existing-concepts} ### Historia {#history} -Koncepcja zdecentralizowanej waluty cyfrowej, a także alternatywnych aplikacji, takich jak rejestry nieruchomości, istnieje od dziesięcioleci. Anonimowe protokoły e-gotówki z lat 80. i 90., oparte głównie na prymitywie kryptografii znanym jako oślepienie Chaumiana, głównym założeniem było że będzie to waluta o wysokim stopniu prywatności, ale protokoły w dużej mierze zawiodły. zyskały przyczepność ze względu na ich zależność od scentralizowanego pośrednika. W 1998 r. Wei Dai's [b-money](http://www.weidai.com/bmoney.txt) stał się pierwszą propozycją wprowadzenia pomysłu tworzenia pieniędzy poprzez rozwiązywanie zadań obliczeniowych oraz zdecentralizowanego konsensusu, jednak wniosek nie zawierał szczegółowych informacji na temat tego, w jaki sposób zdecentralizowany konsensus mógłby zostać faktycznie wdrożony. W 2005 roku Hal Finney wprowadził koncepcję [nadającego się do wielokrotnego użytku dowody pracy](http://nakamotoinstitute.org/finney/rpow/), system który wykorzystuje pomysły z b-money wraz z obliczeniami Adama Backa trudne zagadki Hashcash do stworzenia koncepcji kryptowaluty, ale po raz kolejny nie spełnił ideału, opierając się na zaufanych komputerach jako zaplecza. W 2009 r. zdecentralizowana waluta została po raz pierwszy wdrożona w praktyce przez Satoshi Nakamoto, połączenie ustanowionych prymitywów do zarządzania własnością za pomocą kryptografii klucza publicznego z algorytmem konsensusu do śledzenia tego, kto jest właścicielem monet, znany jako „dowód pracy”. - -Mechanizm dowodu pracy był przełomem w przestrzeni ponieważ jednocześnie rozwiązał dwa problemy. Po pierwsze, zapewnił prosty i umiarkowanie skuteczny algorytm konsensusu, umożliwiający węzłom w sieci do wspólnego uzgodnienia zestawu kanonicznych aktualizacji do to stanu księgi Bitcoin. Po drugie, zapewnił mechanizm pozwalający na swobodne wejście do procesu konsensusu, rozwiązanie politycznego problemu decydowania o tym, kto ma wpływ na konsensus, przy czym jednocześnie zapobiega atakom sybili. Czyni to, zastępując formalną barierę dla uczestnictwa, np. wymóg rejestracji jako niepowtarzalny podmiot w określonym wykazie, z ekonomiczną barierą - waga pojedynczego węzła w procesie głosowania konsensualnego jest wprost proporcjonalna do mocy obliczeniowej, którą tworzy węzeł. Od tamego czasu zaproponowano alternatywne podejście zwane _dowodem stawki_, obliczanie wagi węzła jako proporcjonalnej do jego waluty i zasobów obliczeniowych; dyskusja nad względnymi zaletami tych dwóch podejść wykracza poza zakres niniejszego dokumentu, ale należy zauważyć, że oba podejścia mogą służyć jako szkielet kryptowaluty. +Koncepcja zdecentralizowanej cyfrowej waluty, a także alternatywnych zastosowań, takich jak rejestry własności, istnieje od dziesięcioleci. Protokoły anonimowych e-pieniędzy z lat 80. i 90., w większości oparte na prymitywie kryptograficznym znanym jako Chaumian blinding, zapewniały walutę o wysokim stopniu prywatności, ale protokoły te w dużej mierze nie zyskały na popularności ze względu na ich zależność od scentralizowanego pośrednika. W 1998 roku [b-money](http://www.weidai.com/bmoney.txt) autorstwa Wei Dai stało się pierwszą propozycją wprowadzenia idei tworzenia pieniędzy poprzez rozwiązywanie zagadek obliczeniowych, a także zdecentralizowanego konsensusu, ale propozycja była skąpa w szczegóły dotyczące tego, jak zdecentralizowany konsensus mógłby zostać faktycznie wdrożony. W 2005 roku Hal Finney wprowadził koncepcję „[dowodów pracy wielokrotnego użytku](https://nakamotoinstitute.org/finney/rpow/)”, systemu, który wykorzystuje pomysły z b-money wraz z trudnymi obliczeniowo zagadkami Hashcash Adama Backa, aby stworzyć koncepcję kryptowaluty, ale po raz kolejny nie udało mu się osiągnąć ideału, polegając na zaufanym przetwarzaniu jako backendzie. W 2009 roku zdecentralizowana waluta została po raz pierwszy wdrożona w praktyce przez Satoshi'ego Nakamoto, łącząc ustalone prymitywy zarządzania własnością poprzez kryptografię klucza publicznego z algorytmem konsensusu do śledzenia, kto jest właścicielem monet, znanym jako „proof-of-work”. -Oto wpis na blogu od Vitalika Buterina, założyciela Ethereum, na temat [prehistorii Ethereum](https://vitalik.eth.limo/general/2017/09/14/prehistory.html). [Tutaj](https://blog.ethereum.org/2016/02/09/cut-and-try-building-a-dream/) jest kolejny post przedstawiający więcej informacji o historii. +Mechanizm stojący za proof-of-work był przełomem w przestrzeni, ponieważ rozwiązywał jednocześnie dwa problemy. Po pierwsze, zapewniał prosty i umiarkowanie skuteczny algorytm konsensusu, umożliwiając węzłom w sieci wspólne uzgadnianie zestawu kanonicznych aktualizacji stanu księgi Bitcoin. Po drugie, zapewniał mechanizm umożliwiający swobodne wejście w proces konsensusu, rozwiązując polityczny problem decydowania o tym, kto może wpływać na konsensus, jednocześnie zapobiegając atakom typu Sybil. Czyni to, zastępując formalną barierę uczestnictwa, np. wymóg rejestracji jako unikalny podmiot na określonej liście, barierą ekonomiczną — waga pojedynczego węzła w procesie głosowania konsensusu jest wprost proporcjonalna do mocy obliczeniowej, jaką wnosi węzeł. Od tego czasu zaproponowano alternatywne podejście zwane _proof-of-stake_, obliczające wagę węzła jako proporcjonalną do jego zasobów walutowych, a nie zasobów obliczeniowych; dyskusja na temat względnych zalet obu podejść wykracza poza zakres tego dokumentu, ale należy zauważyć, że oba podejścia mogą być wykorzystane jako szkielet kryptowaluty. -### Bitcoin jako system przejścia między stanami {#bitcoin-as-a-state-transition-system} +### Bitcoin jako system transformacji stanu {#bitcoin-as-a-state-transition-system} -![Zmiana stanu Ethereum](./ethereum-state-transition.png) +![Transformacja stanu Ethereum](./ethereum-state-transition.png) -Z technicznego punktu widzenia księga kryptowalut takich jak Bitcoin może być uważana za system transformacji stanu, gdzie jest "stan" składający się ze statusu własności wszystkich istniejących bitcoinów i "funkcja transformacji stanu", która przyjmuje stan i transakcję oraz wygeneruje nowy stan, który jest rezultatem. Przykładowo w standardowym systemie bankowym stan jest bilansem, transakcja jest prośbą o przeniesienie $X z A do B, a funkcja przejścia stanu zmniejsza wartość na koncie A o $X i zwiększa wartość na koncie B o $X. Jeśli konto A ma w pierwszej kolejności mniej niż X Usd, to stan funkcja przejścia zwraca błąd. Można zatem formalnie zdefiniować: +Z technicznego punktu widzenia, księga kryptowalut, takich jak Bitcoin, może być postrzegana jako system zmiany stanu, w którym istnieje „stan” składający się ze statusu własności wszystkich istniejących bitcoinów oraz „funkcja zmiany stanu”, która przyjmuje stan i transakcję i wyprowadza nowy stan, który jest wynikiem. Przykładowo w standardowym systemie bankowym stan jest bilansem, transakcja jest prośbą o przeniesienie $X z A do B, a funkcja przejścia stanu zmniejsza wartość na koncie A o $X i zwiększa wartość na koncie B o $X. Jeśli konto A ma mniej niż $X, to funkcja zmiany stanu zwraca błąd. Można zatem formalnie zdefiniować: ``` - ZASTOSUJ(S,TX) —>> S' lub BŁĄD +ZASTOSUJ(S,TX) -> S' lub BŁĄD ``` W systemie bankowym zdefiniowanym powyżej: -``` - Zastosuj ({ Alice: $50, Bob: $50 },"wyślij $20 z Alice do Bob") = { Alice: $30, Bob: $70 } +```js +Zastosuj ({ Alice: $50, Bob: $50 },"wyślij $20 z Alice do Bob") = { Alice: $30, Bob: $70 } ``` Ale: +```js +ZASTOSUJ({ Alice: $50, Bob: $50 }:,"wyślij 70 USD od Alicji do Roberta") = BŁĄD ``` - ZASTOSUJ({ Alice: $50, Bob: $50 }:,"wyślij 70 USD od Alicji do Roberta") = BŁĄD -``` - -"Stan" w Bitcoinach to kolekcja wszystkich monet (technicznie, "niewykorzystane wyniki transakcji" lub UTXO, które zostały wydobyte i jeszcze nie zostały wydane, z każdym UTXO o nazwie i właścicielu (określonym przez 20-bajtowy adres, który zasadniczo jest publicznym kluczem kryptograficznym[fn. 1](#notes)). Transakcja zawiera jedno lub więcej danych wejściowych, przy każdym wejściu zawierającym odniesienie do istniejącego UTXO i podpisu kryptograficznego wygenerowanego przez prywatny klucz powiązany z adresem właściciela, i jedno lub więcej wyjść z każdym wyjściem zawierającym nowe UTXO dodawane do stanu. - -Funkcja przejścia stanu `APPLY(S,TX) -> S'` może być zdefiniowana w przybliżeniu w następujący sposób: - -1. Dla każdego wejścia w `TX`: - - - Jeśli odniesienie UTXO nie jest w `S`, zwraca błąd. - - Jeśli podany podpis nie pasuje do właściciela UTXO, zwraca błąd. - -2. Jeśli suma nominałów wszystkich wejściowych UTXO jest mniejsza niż suma nominałów wszystkich wyjściowych UTXO, zwraca błąd. -3. Zwraca `S'` z usuniętymi wszystkimi wprowadzonymi wartościami UTXO i wszystkimi dodanymi wartościami UTXO. -Pierwsza połowa pierwszego kroku uniemożliwia nadawcom transakcji wydawanie monet, które nie istnieją, druga połowa pierwszego kroku uniemożliwia nadawcom transakcji wydawanie monet innych ludzi, a drugi wymusza zachowanie wartości. Aby użyć tego do płatności, protokół jest następujący. Załóżmy, że Alice chce wysłać 11,7 BTC do pracy. Najpierw Alice będzie szukać zestawu dostępnych UTXO które posiada w sumie do co najmniej 11.7 BTC. Realistycznie rzecz biorąc, Alice nie będzie w stanie uzyskać dokładnie 11,7 BTC; powiedzmy, że najmniejsza z nich to 6+4+2=12. Następnie tworzy transakcję z tymi trzema wejściami i dwoma wyjściami. Pierwsze wejście będzie miało wartość 11.7 BTC z adresem Boba jako jego właścicielem, a drugie będzie wartością 0. BTC "change",, a właścicielem jest Alice. +„Stan” w Bitcoinie to zbiór wszystkich monet (technicznie rzecz biorąc, „niewydanych wyników transakcji” lub UTXO), które zostały wybite i nie zostały jeszcze wydane, przy czym każda UTXO ma nominał i właściciela (zdefiniowanego przez 20-bajtowy adres, który jest zasadniczo kryptograficznym kluczem publicznym[fn1](#notes)). Transakcja zawiera jedno lub więcej danych wejściowych, z których każde zawiera odniesienie do istniejącego UTXO i podpis kryptograficzny wygenerowany przez klucz prywatny powiązany z adresem właściciela, oraz jedno lub więcej danych wyjściowych, z których każde zawiera nowe UTXO, które ma zostać dodane do stanu. + +Funkcja przejścia stanu `APPLY(S,TX) -> S'` może być z grubsza zdefiniowana w następujący sposób: + +
    +
  1. + Dla każdego wejścia w TX: +
      +
    • + Jeśli UTXO, do którego następuje odwołanie, nie znajduje się w S, zwróć błąd. +
      • +
    • + Jeśli podany podpis nie pasuje do właściciela UTXO, zwróć błąd. +
      • +
    +
    2. +
  2. + Jeśli suma wartości wszystkich wejściowych UTXO jest mniejsza niż suma wartości wszystkich wyjściowych UTXO, zwróć błąd. +
    3. +
  3. + Zwróć S ze wszystkimi wejściowymi UTXO usuniętymi i wszystkimi wyjściowymi UTXO dodanymi. +
    4. +
+ +Pierwsza połowa pierwszego kroku uniemożliwia nadawcom transakcji +wydawanie monet, które nie istnieją, druga połowa pierwszego kroku +uniemożliwia nadawcom transakcji wydawanie monet innych ludzi, a drugi krok +wymusza zachowanie wartości. Aby użyć tego do płatności, protokół jest następujący. Załóżmy, że Alice chce wysłać 11,7 BTC do Boba. Najpierw Alice poszuka zestawu dostępnych UTXO, które posiada, o łącznej wartości co najmniej 11,7 BTC. Realistycznie rzecz biorąc, Alice nie będzie +w stanie uzyskać dokładnie 11,7 BTC; powiedzmy, że najmniejsza kwota, jaką będzie w stanie uzyskać, to +6+4+2=12. Następnie tworzy transakcję z tymi trzema wejściami i dwoma wyjściami. Pierwszym wyjściem będzie 11,7 BTC z adresem Boba jako właścicielem, a drugim wyjściem będzie pozostałe 0,3 BTC „reszty”, a właścicielem będzie sama Alice. ### Wydobycie {#mining} ![Bloki Ethereum](./ethereum-blocks.png) -Gdybyśmy mieli dostęp do godnej zaufania usługi scentralizowanej, ten system byłby błahy do wdrożenia; można je po prostu zakodować dokładnie tak, jak to opisano, za pomocą scentralizowanego dysku twardy serwera, aby śledzić stan serwera. Jednak za pomocą Bitcoina próbujemy zbudować zdecentralizowaną walutę systemu, więc będziemy musieli połączyć system przejścia stanów z system konsensusu w celu zapewnienia, że ​​wszyscy zgadzają się na kolejność transakcji. Zdecentralizowany proces konsensusu Bitcoina wymaga węzłów w sieci, aby nieustannie próbować tworzyć pakiety transakcji zwanych "blokami". Sieć ma produkować z grubsza jeden blok co dziesięć minut, z każdym blokiem zawierającym znacznik czasu, a nonce, odwołanie do (tj. hash of) poprzedniego bloku i lista wszystkich transakcji, które miały miejsce od poprzedniego bloku. Z czasem tworzy to trwały, ciągle rozwijający się "blockchain", który stale aktualizuje, aby reprezentować najnowszy stan księgi Bitcoin. +Gdybyśmy mieli dostęp do godnej zaufania scentralizowanej usługi, system ten byłby banalny do wdrożenia; można by go po prostu zakodować dokładnie tak, jak opisano, używając dysku twardego scentralizowanego serwera do śledzenia stanu. Jednak w przypadku Bitcoina staramy się zbudować zdecentralizowany system walutowy, więc będziemy musieli połączyć stanowy system transakcji z systemem konsensusu, aby zapewnić, że wszyscy zgadzają się co do kolejności transakcji. Zdecentralizowany proces konsensusu Bitcoina wymaga, aby węzły w sieci nieustannie próbowały tworzyć pakiety transakcji zwane „blokami”. Sieć ma na celu tworzenie mniej więcej jednego bloku co dziesięć minut, przy czym każdy blok zawiera znacznik czasu, nonce, odniesienie do (tj. hasz) poprzedniego bloku i listę wszystkich transakcji, które miały miejsce od poprzedniego bloku. Z czasem tworzy to trwały, ciągle rosnący „blockchain”, który stale aktualizuje się, aby reprezentować najnowszy stan księgi Bitcoin. -Algorytm sprawdzający, czy blok jest prawidłowy, wyrażony w tym paradygmatze, jest następujący: +Algorytm sprawdzający, czy blok jest prawidłowy, wyrażony w tym +paradygmacie, jest następujący: -1. Sprawdź, czy poprzedni blok odwołany przez blok istnieje i jest ważny. -2. Sprawdź, czy znacznik czasu bloku jest większy niż w poprzednim bloku[fn. 2](#notes) i niecałe 2 godziny w przyszłość -3. Sprawdź, czy dowód pracy na bloku jest ważny. -4. Niech `S[0]` będzie stanem na końcu poprzedniego bloku. -5. Załóżmy, że `TX` jest listą transakcji z `n` transakcji. Za wszystkie `i` w `0... -1`, ustaw `S[i+1] = APPLY(S[i], X[i])` Jeśli jakakolwiek aplikacja zwróci błąd, wyjdź i zwróć fałsz. -6. Zwróć true i zarejestruj `S[n]` jako stan na końcu tego bloku. +1. Sprawdź, czy poprzedni blok, na który powołuje się bieżący blok, istnieje i jest prawidłowy. +2. Sprawdź, czy znacznik czasu bloku jest większy niż znacznik poprzedniego bloku[fn2](#notes) i mniejszy niż 2 godziny w przyszłości. +3. Sprawdź, czy proof-of-work w bloku jest prawidłowy. +4. Niech S[0] będzie stanem na końcu poprzedniego bloku. +5. Załóżmy, że TX jest listą transakcji bloku z n transakcjami. Dla wszystkich `i` w `0...n-1` ustaw `S[i+1] = APPLY(S[i],TX[i])`. Jeśli jakakolwiek aplikacja zwróci błąd, wyjdź i zwróć fałsz. +6. Zwróć prawdę i zarejestruj S[n] jako stan na końcu tego bloku. -Zasadniczo, każda transakcja w bloku musi zapewniać prawidłowy stan przejścia od stanu kanonicznego przed wykonaniem transakcji do nowego stanu. Należy zauważyć, że stan nie jest zakodowany w bloku. jest to wyłącznie abstrakcja, która ma być zapamiętana przez węzeł walidacyjny i może być (bezpiecznie) obliczona tylko dla każdego bloku przez zaczynając od stanu genezy i sekwencyjnie stosując każdą transakcję w każdym bloku. Ponadto należy zwrócić uwagę, że kolejność, w której górnik zawiera transakcje w bloku ma znaczenie; jeżeli w bloku są dwie transakcje A i B takie, że B wydaje UTXO stworzone przez A, wtedy blok będzie prawidłowy, jeśli A pojawi się przed B, ale nie w przeciwnym wypadku. +Zasadniczo, każda transakcja w bloku musi zapewnić prawidłowe przejście stanu ze stanu kanonicznego przed wykonaniem transakcji do nowego stanu. Należy zauważyć, że stan nie jest w żaden sposób zakodowany w bloku; jest to wyłącznie abstrakcja, która ma być zapamiętana przez węzeł walidujący i może być (bezpiecznie) obliczony tylko dla dowolnego bloku, zaczynając od stanu genezy i sekwencyjnie stosując każdą transakcję w każdym bloku. Ponadto należy zwrócić uwagę, że kolejność, w której górnik uwzględnia transakcje w bloku, ma znaczenie; jeżeli w bloku są dwie transakcje A i B, a B wydaje UTXO stworzone przez A, wtedy blok będzie prawidłowy, jeśli A pojawi się przed B, ale nie odwrotnie. -Jednym z warunków ważności obecnych na powyższej liście, który nie jest znaleziony w innych systemach, jest wymóg „dowodu pracy”. Dokładny warunek polega na tym, że podwójny skrót SHA256 każdego bloku, traktowany jako liczba 256-bitowa, musi być mniejsza niż dynamicznie dostosowany cel, który od czasu pisania wynosi około 2187. Ma to na celu spowodowanie tworzenia bloków w sposób obliczeniowy "utwardzony", uniemożliwiając tym samym atakującym sybil retworzenie całego łańcucha bloków na ich korzyść. Ponieważ SHA256 jest zaprojektowany jako funkcja całkowicie nieprzewidywalna, jedynym sposobem na stworzenie poprawnego bloku jest po prostu próba i błąd, wielokrotne zwiększanie liczby nonce i patrząc, czy nowy skrót pasuje. +Jednym z warunków prawidłowości obecnych na powyższej liście, który nie jest znaleziony +w innych systemach, jest wymóg „dowodu pracy”. Dokładny warunek polega na tym, że podwójny hash SHA256 każdego bloku, traktowany jako 256-bitowa liczba, musi być mniejszy niż dynamicznie dostosowany cel, który w chwili pisania tego wynosi około 2187. Celem tego jest sprawienie, aby tworzenie bloków było obliczeniowo „trudne”, uniemożliwiając w ten sposób atakującym metodą Sybil przerobienie całego blockchainu na swoją korzyść. Ponieważ SHA256 jest zaprojektowany, by być kompletnie nieprzewidywalną pseudo losową funkcją, jedyną możliwością stworzenia ważnego bloku jest zwykła metoda prób i błędów, wielokrotne powtarzanie nonce i porównywanie z haszem. -Przy obecnym celu \~2187 sieć musi wykonać średnia z \~269 prób przed znalezieniem prawidłowego bloku; w ogólnie, cel jest rekalibrowany przez sieć co 2016 bloki, więc że średnio nowy blok jest tworzony przez jakiś węzeł w sieci co dziesięć minut. Aby zrekompensować górnikom to obliczenie pracy, górnik każdego bloku ma prawo do zawarcia transakcji dając sobie 12,5 BTC znikąd. Dodatkowo, jeśli jakakolwiek transakcja ma wyższy nominał całkowity na wejściu niż na wyjściach, różnica trafia również do górnika jako „opłata transakcyjna”. Nawiasem mówiąc, jest to jedyny mechanizm, za pomocą którego BTC są emitowane; stan genetyczny nie zawierał żadnych monet. +Przy obecnym celu \~2187, sieć musi wykonać średnio \~269 prób, zanim zostanie znaleziony prawidłowy blok; generalnie, cel jest ponownie kalibrowany przez sieć co 2016 bloków, więc nowy blok jest tworzony przez jakiś węzeł w sieci co średnio dziesięć minut. Aby zrekompensować górnikom tę pracę obliczeniową, górnik każdego bloku ma prawo do zawarcia transakcji dającej mu 25 BTC znikąd. Dodatkowo, jeśli jakakolwiek transakcja ma wyższy łączny nominał na wejściach niż na wyjściach, różnica trafia również do górnika jako „opłata transakcyjna”. Nawiasem mówiąc, jest to jedyny mechanizm, za pomocą którego emitowane są BTC; +stan genezy nie zawierał żadnych monet. -Aby lepiej zrozumieć cel górnictwa, zbadajmy co dzieje się w przypadku złośliwego atakującego. Ponieważ kryptografia bazowa Bitcoina jest znana jako bezpieczna, atakujący będzie kierował do jednej części systemu Bitcoin, która nie jest chroniona przez kryptografię bezpośrednio: kolejność transakcji. Strategia atakującego jest prosta: +Aby lepiej zrozumieć cel wydobywania, zbadajmy, co dzieje się w przypadku złośliwego atakującego. Ponieważ wiadomo, że kryptografia Bitcoina jest bezpieczna, atakujący będzie koncentrował się na jedynej części systemu Bitcoin, która nie jest chroniona bezpośrednio przez kryptografię: kolejność transakcji. Strategia atakującego jest prosta: -1. Wyślij 100 BTC do sprzedawcy w zamian za jakiś produkt (najlepiej szybką dostawę cyfrową) -2. Poczekaj na dostawę produktu -3. Wyprodukuj inną transakcję wysyłającą te same 100 BTC do siebie -4. Staraj się przekonać sieć, że jego transakcja dla siebie to taka, która pojawiła się pierwszy. +1. Wysyła 100 BTC do sprzedawcy w zamian za jakiś produkt (najlepiej cyfrowy towar z szybką dostawą) +2. Czeka na dostawę produktu +3. Produkuje kolejną transakcję wysyłającą te same 100 BTC do niego samego +4. Spróbuj przekonać sieć, że jego transakcja do samego siebie była pierwsza -Po wykonaniu kroku (1) po kilku minutach jakiś górnik uwzględni transakcję w bloku, powiedzmy numer bloku 270. Po około jednej godziny, pięć kolejnych bloków zostanie dodanych do łańcucha po tym bloku, z każdym z bloków pośrednio wskazującym transakcję, a tym samym „potwierdzającą”. W tym momencie sprzedawca zaakceptuje płatności w sfinalizowanej wersji i dostarczy produkt; ponieważ zakładamy, że to dobro cyfrowe, dostawa jest natychmiastowa. Teraz atakujący tworzy kolejną transakcję wysyłającą 100 BTC do siebie. Jeśli napastnik po prostu uwolni go do środowiska naturalnego, transakcja nie zostanie przetworzona; górnicy będą próbowali uruchomić `APPLY(S, X)` i zauważą, że `TX` zużywa UTXO, który już nie jest w stanie. Zamiast tego, napastnik tworzy "widek" blockchain, rozpoczynając od wydobycia innej wersji bloku 270 wskazującej na ten sam blok 269 jako element nadrzędny, ale z nową transakcją zamiast starej. Ponieważ dane bloku są różne, wymaga to ponownego potwierdzenia pracy. Ponadto nowa wersja bloku 270 atakującego ma inny hash, tak aby oryginalne bloki od 271 do 275 nie wskazywały na nią; w ten sposób oryginalny łańcuch i nowy łańcuch atakującego są całkowicie oddzielone. Reguła jest, że w forku najdłuższy blockchain jest prawdą, i tak legalni górnicy będą pracować w łańcuchu 275, podczas gdy sam atakujący pracuje w łańcuchu 270. Aby jego blockchain stał się najdłuższy, musiałby mieć więcej mocy obliczeniowej niż pozostała część sieci połączona w celu nadrabiania zaległości (tj. "51% ataku"). +Po wykonaniu kroku (1), po kilku minutach jakiś górnik uwzględni transakcję w bloku, powiedzmy bloku numer 270000. Po około godzinie do łańcucha zostanie dodanych kolejnych pięć bloków po tym bloku, a każdy z tych bloków pośrednio wskaże transakcję, a tym samym ją „potwierdzi”. W tym momencie sprzedawca zaakceptuje płatność jako sfinalizowaną i dostarczy produkt; ponieważ zakładamy, że to towar cyfrowy, dostawa jest natychmiastowa. Teraz atakujący tworzy kolejną transakcję wysyłającą 100 BTC do siebie. Jeśli atakujący po prostu wypuści ją do sieci, transakcja nie zostanie przetworzona; górnicy spróbują uruchomić `APPLY(S,TX)` i zauważą, że `TX` zużywa UTXO, które nie jest już w danym stanie. Zamiast tego atakujący tworzy „fork” blockchainu, zaczynając od wydobycia innej wersji bloku 270000 wskazującego na ten sam blok 269999 jako rodzica, ale z nową transakcją w miejscu starej. Ponieważ dane bloku są +różne, wymaga to ponownego potwierdzenia pracy. Ponadto nowa wersja bloku 270000 atakującego ma inny hash, więc oryginalne bloki od 270001 do 270005 nie „wskazują” na niego; w ten sposób oryginalny łańcuch i nowy łańcuch atakującego są całkowicie oddzielne. Reguła jest taka, że w forku najdłuższy blockchain jest uznawany za prawdziwy, więc +prawdziwi górnicy będą pracować na łańcuchu 270005, podczas gdy sam atakujący +będzie pracował na łańcuchu 270000. Aby atakujący mógł uczynić swój blockchain najdłuższym, musiałby mieć więcej mocy obliczeniowej niż pozostała część sieci łącznie, aby nadrobić zaległości (stąd „atak 51%”). ### Drzewa Merkle {#merkle-trees} ![SPV w Bitcoinie](./spv-bitcoin.png) -_Po lewej: wystarczy przedstawić tylko niewielką liczbę węzłów w drzewie Merkle, aby przedstawić dowód ważności gałęzi._ +_Po lewej: wystarczy przedstawić tylko niewielką liczbę węzłów w drzewie Merkle, aby udowodnić prawidłowość gałęzi._ -_Prawo: każda próba zmiany dowolnej części drzewa Merkle ostatecznie doprowadzi do niespójności w górę łańcucha._ +_Po prawej: każda próba zmiany jakiejkolwiek części drzewa Merkle ostatecznie doprowadzi do niespójności gdzieś w łańcuchu._ -Ważną funkcją skalowalności Bitcoina jest to, że blok jest przechowywany w wielopoziomowej strukturze danych. "hash" bloku to w rzeczywistości tylko skrót nagłówka bloku, około 200 bajtowych danych, które zawierają znacznik czasu, non, poprzedni skrót bloku i główny skrót struktury danych zwanej drzewem Merkle przechowującym wszystkie transakcje w bloku. Drzewo Merkle jest typem drzewa binarnego, złożony z węzłów z dużą liczbą węzłów liściowych u dołu drzewa zawierających podstawowe dane, zbiór węzłów pośrednich, w których każdy węzeł jest skrótem jego dwóch podrzędnych, a w końcu pojedynczym węzłem głównym, utworzono również z hashu jego dwóch dzieci, reprezentując "góra" drzewa. Drzewo Merkle ma na celu umożliwienie dostarczenia danych w bloku w części – węzeł może pobrać tylko nagłówek bloku z jednego źródła, niewielka część drzewa odnosząca się do nich z innego źródła i nadal musi być zapewniona, że wszystkie dane są poprawne. Powodem tego działania jest to, że hashuje szerzenie się w górę: jeśli złośliwy użytkownik próbuje zamienić fałszywą transakcję na dole drzewa Merkle, ta zmiana spowoduje zmianę w węźle powyżej, a, a następnie zmianę w węźle powyżej w końcu zmienia korzenie drzewa i tym samym skrót bloku, spowodowanie, że protokół zarejestruje go jako zupełnie inny blok (prawie na pewno z niepoprawnym dowodem pracy). +Ważną funkcją skalowalności Bitcoina jest to, że blok jest przechowywany w wielopoziomowej strukturze danych. „Hash” bloku jest w rzeczywistości tylko hashem nagłówka bloku, około 200-bajtowym fragmentem danych, który zawiera znacznik czasu, nonce, hash poprzedniego bloku i hash korzenia struktury danych zwanej drzewem Merkle przechowującym wszystkie transakcje w bloku. Drzewo Merkle jest rodzajem drzewa binarnego, składającego się z węzłów z dużą liczbą węzłów liści u dołu drzewa zawierających bazowe dane, zbioru węzłów pośrednich, gdzie każdy węzeł jest hashem jego dwóch dzieci, i finalnie pojedynczego węzła korzenia, również utworzonego z hashu jego dwóch dzieci, reprezentującego „wierzchołek” drzewa. Celem drzewa Merkle jest umożliwienie dostarczania danych w bloku fragmentarycznie: węzeł może pobrać tylko nagłówek bloku z jednego źródła, niewielką część drzewa istotną dla niego z innego źródła i nadal mieć pewność, że wszystkie dane są poprawne. Powodem, dla którego to działa, jest to, że hashe propagują się w górę: jeśli złośliwy użytkownik spróbuje zamienić fałszywą transakcję w dolnej części drzewa Merkle, ta zmiana spowoduje zmianę w węźle powyżej, a następnie zmianę w kolejnym węźle powyżej, ostatecznie zmieniając korzeń drzewa, a tym samym hash bloku, powodując, że protokół zarejestruje go jako zupełnie inny blok (prawie na pewno z nieprawidłowym dowodem pracy). -Protokół drzewa Merkle jest niewątpliwie niezbędny do zapewnienia stabilności w dłuższej perspektywie. „Pełny węzeł” w sieci Bitcoin, który przechowuje i przetwarza cały każdy blok, zajmuje od kwietnia 2014 r. około 15 GB dysku w sieci Bitcoin, i rośnie o ponad gigabajt miesięcznie. Obecnie jest to opłacalne dla niektórych komputerów stacjonarnych, a nie telefonów, a później w przyszłości tylko przedsiębiorstwa i hobbyści będą mogli wziąć w nim udział. Protokół znany jako "uproszczona weryfikacja płatności (SPV) pozwala na istnienie innej klasy węzłów, zwana "lekkie węzły", które pobierają nagłówki bloków, sprawdź dowód pracy na nagłówkach bloku, a następnie pobierz tylko "branches" związane z transakcjami, które są dla nich istotne. Pozwala to węzłom świetlnych określić ich mocną gwarancję bezpieczeństwa, jaki jest status każdej transakcji Bitcoin, i ich obecne saldo jest podczas pobierających tylko bardzo małą część całego łańcucha bloków. +Protokół drzewa Merkle jest niewątpliwie niezbędny do zapewnienia stabilności w dłuższej perspektywie. „Pełny węzeł” w sieci Bitcoin, który przechowuje i przetwarza cały każdy blok, zajmuje około 15 GB przestrzeni dyskowej w sieci Bitcoin na kwiecień 2014 r. i rośnie o ponad gigabajt miesięcznie. Obecnie jest to opłacalne dla niektórych komputerów stacjonarnych, a nie telefonów, a później w przyszłości tylko przedsiębiorstwa i hobbyści będą mogli w tym uczestniczyć. Protokół znany jako „uproszczona weryfikacja płatności” (SPV) pozwala na istnienie innej klasy węzłów, zwanych „lekkimi węzłami”, które pobierają nagłówki bloków, weryfikują proof-of-work w nagłówkach bloków, a następnie pobierają tylko„gałęzie” związane z transakcjami, które są dla nich istotne. Pozwala to lekkim węzłom na określenie z dużą gwarancją bezpieczeństwa statusu dowolnej transakcji Bitcoin i ich aktualnego salda, przy jednoczesnym pobraniu tylko bardzo małej części całego blockchainu. -### Alternatywne aplikacje Blockchain {#alternative-blockchain-applications} +### Alternatywne zastosowania Blockchain {#alternative-blockchain-applications} -Pomysł przejęcia podstawowej idei blockchain i zastosowania go do innych pojęć ma również długą historię. W 1998 roku pojawił się Nick Szabo z koncepcją [bezpiecznych tytułów własności z właścicielem autorytet](http://nakamotoinstitute.org/secure-property-titles/), a dokument opisujący „nowe postępy w technologii replikowanych baz danych” pozwoli na system oparty na blockchain do przechowywania rejestru osób posiada jaką ziemię, tworząc rozbudowane ramy zawierające koncepcje takie jak jako gospodarstwo rolne, zawłaszczenie i kastralny podatek gruntowy. Niestety nie był dostępny w tym czasie skuteczny system baz danych i dlatego protokół nigdy nie był wdrażany w praktyce. Jednak po 2009 roku, kiedy zdecentralizowany konsensus Bitcoina został opracowany szereg alternatywnych aplikacji, które szybko zaczęły się pojawić się. +Pomysł wykorzystania podstawowej idei blockchain i zastosowania jej do +innych koncepcji również ma długą historię. W 2005 r. Nick Szabo przedstawił koncepcję „[bezpiecznych tytułów własności z upoważnieniem właściciela](https://nakamotoinstitute.org/library/secure-property-titles/)”, dokumentu opisującego, w jaki sposób „nowe postępy w technologii replikowanych baz danych” pozwolą na system oparty na blockchainie do przechowywania rejestru tego, kto jest właścicielem jakiej ziemi, tworząc rozbudowany framework obejmujący takie koncepcje, jak gospodarstwo rolne, zasiedzenie i gruziński podatek gruntowy. Niestety, w tamtym czasie nie istniał skuteczny system zreplikowanych baz danych, więc protokół ten nigdy nie został wdrożony w praktyce. Jednak po 2009 roku, gdy zdecentralizowany konsensus Bitcoina został opracowany, szybko zaczęło pojawiać się wiele alternatywnych aplikacji. -- **Namecoin** - stworzony w 2010 roku, [Namecoin](https://namecoin.org/) jest go najlepiej opisać jako zdecentralizowaną bazę danych rejestracji nazw. W zdecentralizowanych protokołach, takich jak Tor, Bitcoin i BitMessage, musi być jakiś sposób identyfikacji kont, aby inni ludzie mogli z nimi współdziałać, ale we wszystkich istniejących rozwiązaniach jedynym dostępnym identyfikatorem jest pseudorandom hash, taki jak `1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy`. Najlepiej byłoby, gdyby było w stanie posiadać konto o nazwie takiej jak "george". Jednak problem polega na tym, że jeśli jedna osoba może utworzyć konto o nazwie "george", ktoś inny może użyć tego samego procesu do rejestracji "george" również dla siebie i podszywać się pod nie. Jedynym rozwiązaniem jest pierwszy do pliku, gdzie pierwszy rejestrator zakończył się sukcesem, a drugi porażka - problem doskonale pasujący do protokołu konsensusu Bitcoin. Naamecoin jest najstarszym i najbardziej udanym wdrożeniem systemu rejestracji nazw za pomocą takiego pomysłu. -- **Kolorowe monety** - celem [kolorowych monet](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) jest służyć jako protokół umożliwiający ludziom tworzenie własnych walut cyfrowych - lub w ważnym trywialnym przypadku waluty z jedną jednostką, tokenami cyfrowymi, na blockchainie Bitcoin. W protokole z kolorowych monet, jeden „wydaje” nową walutę publicznie przypisanie koloru do konkretnego Bitcoin UTXO i protokołu rekursywnie definiuje kolor innego UTXO tak, aby był taki sam jak kolor danych wejściowych, które wydała transakcja je tworząca (niektóre specjalne zasady obowiązują w przypadku wejść mieszanych kolorów). Pozwala użytkownikom na utrzymywanie portfeli zawierających tylko UTXO o określonym kolorze i wysyłanie ich w pobliżu podobnych do zwykłych bitcoinów, śledzenie wsteczne przez łańcuch bloków, aby określić kolor każdego UTXO, który otrzymuje. -- **Metacoiny** – ideą stojącą za metacoinem jest posiadanie protokołu który żyje na szczycie Bitcoina, używając transakcji Bitcoin do przechowywania transakcje metacoin, ale z innym przejściem stanu funkcja, `ZASTOSUJ'`. Ponieważ protokół metacoin nie może zapobiec nieprawidłowym transakcjom metacoin pojawiającym się w blockchain Bitcoina, dodawana jest reguła, że ​​jeśli `ZASTOSUJ'(S,TX)` zwraca błąd, protokół domyślnie to `ZASTOSUJ'(S,TX) = S`. Zapewnia to łatwy mechanizm tworzenia arbitralnego protokołu kryptowalutowego, potencjalnie z zaawansowanymi funkcjami, które nie mogą być zaimplementowane wewnątrz samego Bitcoina, ale przy bardzo niskich kosztach rozwoju od czasu złożoności wydobycia i tworzenia sieci są już przedmiotem protokołu Bitcoin. Metacoins zostały użyte do implementacji niektórych klas umów finansowych, rejestracji nazw i zdecentralizowanej wymiany. +- **Namecoin** – stworzony w 2010 roku, [Namecoin](https://namecoin.org/) można najlepiej opisać jako zdecentralizowaną bazę danych do rejestracji nazw. W zdecentralizowanych protokołach, takich jak Tor, Bitcoin i BitMessage, musi istnieć jakiś sposób identyfikacji kont, aby inni ludzie mogli wchodzić z nimi w interakcje, ale we wszystkich istniejących rozwiązaniach jedynym dostępnym rodzajem identyfikatora jest pseudolosowy hasz, taki jak `1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy`. Idealnie byłoby mieć konto o nazwie „george”. Problem polega jednak na tym, że jeśli jedna osoba może utworzyć konto o nazwie „george”, to ktoś inny może użyć tego samego procesu, aby zarejestrować nazwę „george” również dla siebie i podszyć się pod niego. Jedynym rozwiązaniem jest paradygmat first-to-file, w którym pierwszy rejestrator odnosi sukces, a drugi ponosi porażkę — problem ten doskonale pasuje do protokołu konsensusu Bitcoina. Namecoin jest najstarszą i najbardziej udaną implementacją systemu rejestracji nazw wykorzystującą taki pomysł. +- **Kolorowe monety** – celem [kolorowych monet](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) jest służenie jako protokół umożliwiający ludziom tworzenie własnych cyfrowych walut – lub, w ważnym trywialnym przypadku waluty z jedną jednostką, cyfrowych tokenów na blockchainie Bitcoina. W protokole kolorowych monet „emituje się” nową walutę poprzez publiczne przypisanie koloru do określonego UTXO Bitcoina, a protokół rekurencyjnie definiuje kolor innych UTXO jako taki sam jak kolor danych wejściowych, które wydała tworząca je transakcja (niektóre specjalne zasady mają zastosowanie w przypadku danych wejściowych o mieszanych kolorach). Pozwala to użytkownikom na utrzymywanie portfeli zawierających tylko UTXO o określonym kolorze i wysyłanie ich podobnie jak zwykłych bitcoinów, śledząc wstecznie blockchain, aby określić kolor każdego UTXO, który otrzymają. +- **Metacoins** – ideą metacoin jest posiadanie protokołu, który działa na Bitcoinie, wykorzystując transakcje Bitcoin do przechowywania transakcji metacoin, ale posiadając inną funkcję przejścia stanu, `APPLY'`. Ponieważ protokół metacoin nie może zapobiec pojawianiu się nieprawidłowych transakcji metacoin w blockchainie Bitcoina, dodano regułę, która domyślnie ustawia protokół na `APPLY'(S,TX) = S`, jeśli `APPLY'(S,TX)` zwróci błąd. Zapewnia to łatwy mechanizm tworzenia dowolnego protokołu kryptowalutowego, potencjalnie z zaawansowanymi funkcjami, których nie można zaimplementować w samym Bitcoinie, ale przy bardzo niskich kosztach rozwoju, ponieważ złożoność wydobycia i sieci jest już obsługiwana przez protokół Bitcoina. Metacoiny zostały wykorzystane do implementacji niektórych klas umów finansowych, rejestracji nazw i zdecentralizowanej giełdy. -Tak więc, ogólnie rzecz biorąc, istnieją dwa podejścia do budowania protokołu konsensusu: budowanie niezależnej sieci, i zbudowanie protokołu na górze Bitcoin. Trudno jest wdrożyć pierwsze podejście, choć w przypadku aplikacji takich jak Namecoin; każda indywidualna implementacja wymaga bootstrap niezależnego łańcucha bloków, oraz budowy i testowanie wszystkich niezbędnych zmian stanu i kodeksu tworzenia sieci. Dodatkowo, przewidujemy, że zestaw aplikacji dla zdecentralizowanej technologii konsensualnej będzie przebiegał zgodnie z rozdziałem prawa w którym zdecydowana większość aplikacji byłaby zbyt mała, aby uzasadnić ich własny blockchain, i zwracamy uwagę, że istnieją duże klasy zdecentralizowanych aplikacji, w szczególności autonomiczne organizacje, które muszą ze sobą współpracować. +Ogólnie rzecz biorąc, istnieją dwa podejścia do budowania protokołu konsensusu: budowanie niezależnej sieci i budowanie protokołu na Bitcoinie. Pierwsze podejście, choć dość skuteczne w przypadku aplikacji takich jak Namecoin, jest trudne do wdrożenia; każda indywidualna implementacja wymaga uruchomienia niezależnego blockchainu, a także zbudowania i przetestowania całego niezbędnego kodu przejścia stanu i sieci. Ponadto przewidujemy, że zestaw aplikacji dla zdecentralizowanej technologii konsensusu będzie zgodny z rozkładem prawa potęgowego, w którym zdecydowana większość aplikacji byłaby zbyt mała, aby uzasadnić swój własny blockchain, i zauważamy, że istnieją duże klasy zdecentralizowanych aplikacji, w szczególności zdecentralizowane autonomiczne organizacje, które muszą ze sobą współdziałać. -Z drugiej strony podejście oparte na Bitcoinach ma wadę, że nie dziedziczy uproszczonych funkcji weryfikacji płatności Bitcoina. SPV działa dla Bitcoina, ponieważ może użyć głębokości blockchain jako proxy dla ważności; w pewnym momencie, gdy przodkowie transakcji pójdą wystarczająco daleko wstecz, można bezpiecznie powiedzieć, że byli oni legalnie częścią stanu. Z drugiej strony, metaprotokoły oparte na technologii blockchain nie można zmusić blockchain do nieuwzględniania transakcji, które nie są ważne w kontekście ich własnych protokołów. Stąd w pełni bezpieczna implementacja meta-protokołu SPV musiałaby zeskanować wstecz na początek blockchaina Bitcoin, aby ustalić, czy określone transakcje są prawidłowe. Obecnie wszystkie "lekkie" implementacje meta-protokołów bazujących na Bitcoinach opierają się na zaufanym serwerze, aby dostarczyć dane, Prawdopodobnie wysoce nieoptymalny wynik, zwłaszcza gdy jednym z podstawowych celów kryptowaluty jest wyeliminowanie konieczności zaufania. +Z drugiej strony, podejście oparte na Bitcoinie ma tę wadę, że nie dziedziczy uproszczonych funkcji weryfikacji płatności Bitcoina. SPV działa w przypadku Bitcoina, ponieważ może wykorzystywać głębokość blockchainu jako proxy dla ważności; w pewnym momencie, gdy przodkowie transakcji sięgają wystarczająco daleko wstecz, można bezpiecznie powiedzieć, że byli oni legalnie częścią stanu. Z drugiej strony, metaprotokoły oparte na blockchainie nie mogą zmusić blockchainu do nieuwzględnienia transakcji, które nie są ważne w kontekście ich własnych protokołów. W związku z tym w pełni bezpieczna implementacja meta-protokołu SPV musiałaby skanować wstecz aż do początku blockchainu Bitcoin, aby określić, czy określone transakcje są ważne. Obecnie wszystkie „lekkie” implementacje meta-protokołów opartych na Bitcoinie polegają na zaufanym serwerze w celu dostarczenia danych, co jest niewątpliwie wysoce nieoptymalnym wynikiem, zwłaszcza gdy jednym z głównych celów kryptowalut jest wyeliminowanie potrzeby zaufania. ### Skrypty {#scripting} -Nawet bez żadnych rozszerzeń, protokół Bitcoin w rzeczywistości ułatwia słabą wersję pojęcia "inteligentnych umów". UTXO in Bitcoin może być własnością nie tylko klucza publicznego; ale także bardziej skomplikowanym skryptem wyrażonym w prostym języku programowania. W tym paradygmacie wydatki transakcyjne, które UTXO musi podać dane, które spełniają wymagania skryptu. Nawet podstawowy mechanizm własności klucza publicznego jest wdrażany za pomocą skryptu: skrypt przyjmuje eliptyczny podpis krzywej jako dane wejściowe, weryfikuje ją w odniesieniu do transakcji i adresu będącego właścicielem UTXO i zwraca 1 jeśli weryfikacja jest udana i 0 w innym przypadku. Inne, bardziej skomplikowane skrypty istnieją dla różnych dodatkowych przypadków użycia. Na przykład można zbudować skrypt wymagający podpisów z dwóch z trzech wybranych kluczy prywatnych do walidacji ("multisig"), konfiguracja przydatna dla kont korporacyjnych, zabezpiecz konta oszczędnościowe i niektóre sytuacje powiernika. Skrypty mogą również być używane do płacenia nagród za rozwiązania problemów obliczeniowych i jeden może nawet skonstruować skrypt, który mówi coś w stylu „ten Bitcoin UTXO jest twój, jeśli możesz dostarczyć dowód SPV, że wysłałeś Dogecoin transakcja tego nominału do mnie”, zasadniczo pozwalająca na zdecentralizowaną wymianę między kryptowalutami. +Nawet bez żadnych rozszerzeń, protokół Bitcoin faktycznie umożliwia słabą wersję koncepcji „inteligentnych kontraktów”. UTXO w Bitcoinie może być własnością nie tylko klucza publicznego, ale także bardziej skomplikowanego skryptu wyrażonego w prostym języku programowania opartym na stosie. W tym modelu transakcja wydająca to UTXO musi dostarczyć dane, które spełniają wymagania skryptu. W rzeczywistości nawet podstawowy mechanizm własności klucza publicznego jest implementowany za pomocą skryptu: skrypt przyjmuje podpis krzywej eliptycznej jako dane wejściowe, weryfikuje go względem transakcji i adresu, który jest właścicielem UTXO, i zwraca 1, jeśli weryfikacja zakończy się pomyślnie. W przeciwnym przpadku zwraca 0. Istnieją również inne, bardziej skomplikowane skrypty dla różnych dodatkowych przypadków użycia. Na przykład, można stworzyć skrypt, który wymaga podpisów od dwóch z trzech podanych kluczy prywatnych do walidacji („multisig”), konfigurację przydatną dla kont firmowych, bezpieczne konta oszczędnościowe i niektóre sytuacje depozytu handlowego. Skrypty mogą być również wykorzystywane do wypłacania nagród za rozwiązania problemów obliczeniowych, a nawet można skonstruować skrypt, który mówi coś w stylu „ten Bitcoin UTXO jest Twój, jeśli możesz dostarczyć dowód SPV, że wysłałeś do mnie transakcję Dogecoin o tym nominale”, zasadniczo umożliwiając zdecentralizowaną wymianę między kryptowalutami. -Jednak język skryptu zaimplementowany w Bitcoinach ma kilka ważnych ograniczeń: +Język skryptowy zaimplementowany w Bitcoinie ma jednak kilka istotnych ograniczeń: -- **Brak kompletności w sensie Turinga ** - to znaczy, że choć istnieje duży podzbiór obliczeń, które obsługuje język skryptowy Bitcoin, nie obsługuje on jednak wszystkiego. Główna kategoria, której brakuje, to pętle. Wykonuje się to w celu uniknięcia nieskończonych pętli podczas weryfikacji transakcji; teoretycznie jest to przeszkoda dla programistów skryptów, ponieważ dowolna pętla może być symulowana przez po prostu wielokrotne powtarzanie kodu bazowego z instrukcją, ale prowadzi to do bardzo nieefektywnych w przestrzeni skryptów. Na przykład implementacja alternatywnego algorytmu podpisu eliptycznego prawdopodobnie wymagałaby 256 powtarzanych mnożeń zaokrągla wszystkie osobno zawarte w kodzie. -- **Ślepota na wartości** - nie ma sposobu, aby skrypt UTXO zapewniał szczegółową kontrolę kwoty, która może zostać pobrana. Na przykład jednym potężnym przypadkiem wykorzystania kontraktu wyroczni byłby kontrakt zabezpieczający, gdzie A i B umieściły BTC o wartości 1000 USD i po 30 dniach, skrypt wysyła BTC o wartości 1000 USD do A, a resztę do B. Wymagałoby to wyroczni do określenia wartości 1 BTC w USD, ale nawet wtedy jest to ogromna poprawa pod względem zaufania i potrzeba infrastruktury nad w pełni scentralizowanymi rozwiązaniami, które są obecnie dostępne. Jednakże, ponieważ UTXO są typu "wszystko albo nic", jedynym sposobem, aby to osiągnąć jest bardzo nieefektywny hacking polegający na posiadaniu wielu UTXO o różnych nominałach (np. jedno UTXO o wartości 2k na każde k do 30) i posiadaniu O wyboru, które UTXO wysłać do A, a które do B. -- **Brak stanu** – [UTXO można wydać lub zostawić niewykorzystane](https://bitcoin.org/en/glossary/unspent-transaction-output); nie ma możliwości na wieloetapowe kontrakty czy skrypty, które utrzymują jakikolwiek inny wewnętrzny stan poza tym. To sprawia, że trudno jest tworzyć wieloetapowe kontrakty opcji, zdecentralizowane oferty wymiany lub dwuetapowe protokoły zobowiązań kryptograficznych (niezbędne do zabezpieczenia pól obliczeniowych). Oznacza to również, że UTXO może być używany tylko do: buduj proste, jednorazowe kontrakty i nie bardziej złożone „stanowe” kontrakty, takie jak zdecentralizowane organizacje i sprawia, meta-protokoły trudne do wdrożenia. Stan binarny w połączeniu z ślepotą wartości oznacza również, że inna ważna aplikacja, limity wypłaty jest niemożliwa. -- **Blockchain-blindness** - UTXO są ślepe na dane blockchain, takie jak nonce znacznik czasu i poprzedni hash bloku. To bardzo ogranicza zastosowania w grach i kilku innych kategoriach, przez pozbawienie języka skryptowego potencjalnie cennego źródła losowości. +- **Brak kompletności w sensie Turinga** – znaczy to, że choć język skryptowy Bitcoina obsługuje duży podzbiór obliczeń, to jednak nie obsługuje on wszystkiego. Główną kategorią, której brakuje, są pętle. Ma to na celu uniknięcie nieskończonych pętli podczas weryfikacji transakcji; teoretycznie jest to przeszkoda możliwa do pokonania przez programistów skryptów, ponieważ każda pętla może być symulowana przez wielokrotne powtarzanie kodu bazowego za pomocą instrukcji warunkowej „if”, ale prowadzi to do skryptów, które są bardzo nieefektywne pod względem wykorzystania przestrzeni. Przykładowo, implementacja alternatywnego algorytmu podpisu krzywej eliptycznej prawdopodobnie wymagałaby 256 powtórzonych cykli mnożenia, które musiałyby być indywidualnie uwzględnione w kodzie. +- **Ślepota na wartość** – nie ma możliwości, aby skrypt UTXO zapewniał precyzyjną kontrolę nad kwotą, którą można wypłacić. Na przykład, jednym z potężnych przypadków użycia kontraktu wyroczni byłby kontrakt zabezpieczający (hedging), do którego A i B wpłacają równowartość 1000 USD w BTC, a po 30 dniach skrypt wysyła równowartość 1000 USD w BTC do A, a resztę do B. Wymagałoby to wyroczni do określenia wartości 1 BTC w USD, ale nawet wtedy byłaby to ogromna poprawa pod względem zaufania i wymagań infrastrukturalnych w porównaniu do w pełni scentralizowanych rozwiązań dostępnych obecnie. Jednakże, ponieważ UTXO działają w trybie „wszystko albo nic”, jedynym sposobem osiągnięcia tego jest bardzo nieefektywne obejście polegające na posiadaniu wielu UTXO o różnych nominałach (np. jedno UTXO o wartości 2k dla każdego k do 30) i pozwoleniu wyroczni na wybór, które UTXO wysłać do A, a które do B. +- **Brak stanu** – UTXO mogą być albo wydane, albo niewydane; nie ma możliwości tworzenia kontraktów wieloetapowych ani skryptów, które przechowują jakikolwiek inny stan wewnętrzny poza tym. Utrudnia to tworzenie wieloetapowych kontraktów opcyjnych, zdecentralizowanych ofert wymiany lub dwuetapowych protokołów kryptograficznego zobowiązania (niezbędnych do bezpiecznego nagród obliczeniowych). Oznacza to również, że UTXO mogą być wykorzystywane jedynie do budowania prostych, jednorazowych kontraktów, a nie bardziej złożonych kontraktów „stanowych”, takich jak zdecentralizowane organizacje, co sprawia, że meta-protokoły są trudne do wdrożenia. Połączenie binarnego stanu ze ślepotą na wartość oznacza również, że kolejne ważne zastosowanie, jak limity wypłat, jest niemożliwe do zrealizowania. +- **Ślepota na blockchain** – UTXO są ślepe na dane z blockchainu, takie jak nonce, znacznik czasu i hasz poprzedniego bloku. Powoduje to poważne ograniczenia w aplikacjach hazardowych i w kilku innych kategoriach, pozbawiając język skryptowy potencjalnie cennego źródła losowości. -Widzimy zatem trzy podejścia do budowania zaawansowanych aplikacji bazujących na kryptowalucie: budowanie nowego blockchaina, używanie skryptów bazujących na Bitcoin i budowanie metaprotokołu opartego na Bitcoin. Budowanie nowego blockchainu pozwala na nieograniczoną swobodę w budowaniu zestawu funkcji, ale kosztem czasu rozwoju, wysiłku przy uruchamianiu i bezpieczeństwa. Korzystanie ze skryptów jest łatwe do wdrożenia i standaryzacji, ale jest bardzo ograniczone w swoich możliwościach, a metaprotokoły, choć łatwe, cierpią z powodu błędów w skalowalności. Dzięki Ethereum zamierzamy zbudować alternatywny framework, który zapewnia jeszcze większe korzyści w łatwości rozwoju, jak również jak również jeszcze silniejsze właściwości lekkiego klienta, a jednocześnie pozwala aplikacjom na współdzielenie środowiska ekonomicznego i bezpieczeństwa blockchainu. +Widzimy zatem trzy podejścia do budowania zaawansowanych aplikacji bazujących na +kryptowalucie: budowanie nowego blockchaina, używanie skryptów bazujących na +Bitcoin i budowanie metaprotokołu opartego na Bitcoin. Budowanie nowego blockchainu pozwala na nieograniczoną swobodę w budowaniu zestawu funkcji, ale kosztem czasu rozwoju, wysiłku przy uruchamianiu i bezpieczeństwa. Korzystanie ze skryptów jest łatwe do wdrożenia i standaryzacji, ale jest bardzo ograniczone w swoich możliwościach, a metaprotokoły, choć łatwe, cierpią z powodu błędów w skalowalności. Dzięki Ethereum zamierzamy zbudować alternatywny framework, który zapewnia jeszcze większe korzyści w łatwości rozwoju, jak również jeszcze silniejsze właściwości lekkiego klienta, a jednocześnie pozwala aplikacjom na współdzielenie środowiska ekonomicznego i bezpieczeństwa blockchainu. ## Ethereum {#ethereum} -Celem Ethereum jest stworzenie alternatywnego protokołu do budowy zdecentralizowanych aplikacji, zapewnienie innego zestawu kompromisów, które uważamy za bardzo przydatne dla dużej klasy zdecentralizowanych aplikacji, ze szczególnym naciskiem na sytuacje, w których szybki czas rozwoju, bezpieczeństwo dla małych i rzadkich zastosowań i zdolność różnych aplikacji do bardzo efektywnej interakcji jest istotna. Ethereum robi to budując to, co zasadniczo jest najlepszą abstrakcyjną warstwą podstawową: blockchain z wbudowanym językiem programowania, umożliwienie każdemu pisania inteligentnych kontraktów i zdecentralizowanych aplikacji, w których mogą tworzyć własne arbitralne zasady własności, formaty transakcji i funkcje przemiany stanu. Wersję „gołej kości” Namecoina można zapisać w dwóch linijkach kodu, a inne protokoły, takie jak waluty i systemy reputacji, mogą być zbudowany w czasie poniżej dwudziestu lat. Inteligentne kontrakty, „skrzynki” kryptograficzne, które zawierają wartość i odblokowują je tylko wtedy, gdy spełnione są określone warunki, można również budować na platformie z znacznie większą mocą niż oferowaną przez skryptowanie Bitcoina z powodu dodatkowych potęg Trójkompletność, świadomość wartości, świadomość blockchain-a i stan. - -### Filozofia {#philosophy} - -Ethereum ma być zaprojektowane zgodnie z następującymi zasadami: - -1. **Prostota**: protokół Ethereum powinien być jak najprostszy. Nawet kosztem mniejszej efektywności przechowywania danych lub czasu [fd. 3](#notes) Średni programista powinien być w stanie śledzić i implementować całą specyfikację,[fn. 4](#notes) tak, aby w pełni wykorzystać bezprecedensowy potencjał demokratyzacji, który kryptowaluta wnosi i rozwija wizję Ethereum jako protokół, który jest otwarty dla wszystkich. Żadna optymalizacja która zwiększa złożoność nie powinna być uwzględniona, chyba że optymalizacja ta zapewnia znaczną korzyść. -2. **Uniwersalność**: zasadnicza część filozofii projektowej Ethereum jest taka, że Ethereum nie posiada "funkcji".[fn. 5](#notes) Zamiast tego Ethereum zapewnia wewnętrzny Skrypt Turing-complete język, który programista może użyć do budowy inteligentnej umowy lub typu transakcji, które mogą być zdefiniowane matematycznie. Chcesz wynaleźć własną finansową pochodną? Z Ethereum, możesz. Chcesz stworzyć własną walutę? Skonfiguruj jako kontrakt Ethereum. Chcesz skonfigurować całą skalę Daemona lub Skynet? Być może będziesz potrzebować kilku tysiący powiązanych umów i pamiętaj, aby je nakarmić hojnie, ale nic Cię nie powstrzymuje z Ethereum i Twoimi opuszkami palców. -3. **Modularność**: części protokołu Ethereum powinny być zaprojektowane tak, aby były tak modułowe i możliwe do oddzielenia. W trakcie rozwoju, naszym celem jest stworzenie programu, w którym gdybyś miał wykonać małą modyfikację protokołu w jednym miejscu, stos aplikacji nadal funkcjonowałby bez żadnych dalszych modyfikacji. Innowacje takie jak Ethash (patrz [Żółty papier załącznik](https://ethereum.github.io/yellowpaper/paper.pdf#appendix.J) lub artykuł wiki), zmodyfikowanych drzew Patricia ([Żółty papier](https://ethereum.github.io/yellowpaper/paper.pdf#appendix.D), [wiki](https://web.archive.org/web/20250427212320/https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree)) i RLP ([YP](https://ethereum.github.io/yellowpaper/paper.pdf#appendix.B) [wiki](https://web.archive.org/web/20250427212320/https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP)) powinien być i jest wdrożony jako oddzielna, funkcjonalnie wypełniona biblioteka. Jest to takie, że nawet jeśli są używane w Ethereum, nawet jeśli Ethereum nie wymaga pewnych funkcji, takie funkcje są nadal przydatne również w innych protokołach. Rozwój Ethereum powinien być maksymalnie wykonany, aby przynieść korzyści całemu ekosystemowi kryptowalut, a nie tylko samemu. -4. **Zdolność**: szczegóły protokołu Ethereum nie są ustawione w kamieniach. Chociaż będziemy bardzo roztropni w zakresie wprowadzania zmian do konstrukcji wysokiego szczebla, na przykład z [odcięciem mapy drogowej](https://ethresear.ch/t/sharding-phase-1-spec/1407/), abstrakcyjnym wykonaniem, przy czym tylko dostępność danych zapisana jest w konsensusie. Testy obliczeniowe później w procesie opracowywania mogą prowadzić do odkrycia, że niektóre modyfikacje, np. do architektury protokołu lub do maszyny wirtualnej Ethereum (EVM) znacząco zwiększą skalowalność lub bezpieczeństwo. Jeśli znajdziemy takie możliwości, wykorzystamy je. -5. **Niedyskryminacja** i **niecenzura**: protokół powinien nie próbować aktywnie ograniczać lub zapobiegać określonym kategoriom stosowania. Wszystkie mechanizmy regulacyjne zawarte w protokole powinny być zaprojektowane w taki sposób, aby bezpośrednio regulować szkody i nie próbować sprzeciwiać się określonym niepożądanym aplikacjom. Programista może nawet uruchomić nieskończoną pętlę na szczycie Ethereum tak długo, jak długo będą chciały utrzymać płacenie opłaty transakcyjnej. +Celem Ethereum jest stworzenie alternatywnego protokołu do budowy zdecentralizowanych aplikacji, zapewnienie innego zestawu kompromisów, które uważamy za bardzo przydatne dla dużej klasy zdecentralizowanych aplikacji, ze szczególnym naciskiem na sytuacje, w których szybki czas rozwoju, bezpieczeństwo dla małych i rzadko używanych aplikacji i zdolność różnych aplikacji do bardzo efektywnej interakcji, są ważne. Ethereum robi to, budując coś, co jest w zasadzie ostateczną abstrakcyjną warstwą podstawową: blockchain z wbudowanym językiem programowania kompletnym w sensie Turinga, pozwalającym każdemu pisać inteligentne kontrakty i zdecentralizowane aplikacje, w których można tworzyć własne, dowolne zasady własności, formaty transakcji i funkcje przejścia stanów. Uproszczoną wersję Namecoina można zapisać w dwóch linijkach kodu, a inne protokoły, takie jak waluty i systemy reputacji, mogą być zbudowane w mniej niż dwudziestu. Inteligentne kontrakty, kryptograficzne „skrzynki”, które zawierają wartość i odblokowują ją tylko wtedy, gdy spełnione są określone warunki, można również budować na tej platformie, ze znacznie większą mocą niż oferowana przez skrypty Bitcoina, ze względu na dodatkowe możliwości kompletności w sensie Turinga, świadomości wartości, świadomości blockchainu i stanu. ### Konta Ethereum {#ethereum-accounts} -W Ethereum stan składa się z obiektów zwanych "kontami", z każdym kontem o 20-bajtowym adresie i przejściach stanu są bezpośrednie transfery wartości i informacji pomiędzy kontami. Konta Ethereum mają cztery pola: +W Ethereum stan składa się z obiektów zwanych „kontami”, przy czym każde konto ma 20-bajtowy adres, a przejścia stanu to bezpośrednie transfery wartości i informacji pomiędzy kontami. Konto Ethereum posiada cztery pola: -- **nonce**, licznik używany do upewnienia się, że każda transakcja może być przetworzona tylko raz -- Bieżące saldo **etheru konta** -- **kod umowy konta**, jeśli jest obecny -- Pamięć **konta** (pusta domyślnie) +- **Nonce**, licznik używany do zapewnienia, że każda transakcja może być przetworzona tylko raz +- Bieżące **saldo etheru** konta +- **Kod kontraktu** konta, jeśli jest obecny +- **Pamięć** konta (domyślnie pusta) -„Ether” jest główną wewnętrzną kryptowalutą Ethereum używaną do uiszczania opłat transakcyjnych. Ogólnie rzecz biorąc, istnieją dwa rodzaje kont: **rachunki zewnętrzne**, kontrolowane przez klucze prywatne oraz **konta kont kontraktowych**, kontrolowane przez ich kod kontraktu. Zewnętrznie posiadane konto nie posiada kodu i można wysyłać wiadomości z zewnętrznego konta poprzez tworzenie i podpisywanie transakcji; w koncie, za każdym razem, gdy konto kontraktowe otrzymuje komunikat o kodzie aktywuje, pozwala na odczytywanie i zapisywanie do pamięci wewnętrznej i wysyłanie innych wiadomości lub tworzenie kontraktów z kolei. +„Ether” jest głównym wewnętrznym krypto-paliwem Ethereum, wykorzystywanym do uiszczania opłat transakcyjnych. Ogólnie rzecz biorąc, istnieją dwa rodzaje kont: **konta zewnętrzne**, kontrolowane przez klucze prywatne oraz **konta kontraktowe**, kontrolowane przez ich kod kontraktu. Konto zewnętrzne nie ma kodu i można z niego wysyłać wiadomości poprzez tworzenie i podpisywanie transakcji; w przypadku konta kontraktu, za każdym razem, gdy konto takie otrzyma wiadomość, jego kod zostaje aktywowany, co pozwala mu na odczytywanie i zapisywanie do wewnętrznego magazynu oraz wysyłanie innych wiadomości lub tworzenie kontaktów. -Należy zauważyć, że „kontraktów” w Ethereum nie należy postrzegać jako czegoś, co powinno być „spełniane” lub „przestrzegane”; są raczej takie jak „czynniki autonomiczne”, które żyją w środowisku Ethereum execution, zawsze wykonując określony fragment kodu, gdy jest "poked" przez wiadomość lub transakcję, i sprawowanie bezpośredniej kontroli nad własnym eterem oraz ich własnym sklepem kluczowy/wartości w celu śledzenia trwałych zmiennych. +Warto zauważyć, że „kontrakty” w Ethereum nie powinny być postrzegane jako coś, co powinno być „spełnione” lub „przestrzegane”; są one raczej jak „autonomiczni agenci”, którzy żyją w środowisku wykonawczym Ethereum, zawsze wykonując określony fragment kodu, gdy są „szturchani” przez wiadomość lub transakcję, oraz mają bezpośrednią kontrolę nad własnym saldem etheru i własnym magazynem klucz/wartość, w którym przechowują trwałe zmienne. -### Wiadomości i Transakcje {#messages-and-transactions} +### Wiadomości i transakcje {#messages-and-transactions} -Termin "transakcja" jest używany w Ethereum do odwoływania się do podpisanego pakietu danych, który przechowuje wiadomość, która ma być wysłana z zewnętrznego konta. Transakcje zawierają: +Termin „transakcja” jest używany w Ethereum w odniesieniu do podpisanego pakietu danych, który przechowuje wiadomość do wysłania z konta zewnętrznego. Transakcje zawierają: -- Odbiorca wiadomości +- Odbiorcę wiadomości - Podpis identyfikujący nadawcę -- Ilość etheru do przeniesienia od nadawcy do odbiorcy +- Ilość etheru do przesłania od nadawcy do odbiorcy - Opcjonalne pole danych -- Wartość `STARTGAS` przedstawiająca maksymalną liczbę kroków do wykonania transakcji -- Wartość `GASPRICE`, przedstawiająca opłatę, którą nadawca płaci za krok obliczeniowy +- Wartość `STARTGAS`, reprezentująca maksymalną liczbę kroków obliczeniowych, które może wykonać transakcja +- Wartość `GASPRICE` reprezentująca opłatę, jaką płaci nadawca za każdy krok obliczeniowy -Pierwsze trzy pola to pola standardowe w każdej kryptowalucie. Pole danych nie posiada domyślnie żadnej funkcji, ale maszyna wirtualna posiada opcode, które kontrakt może wykorzystać do uzyskania dostępu do danych; jako przykład użyj, jeśli kontrakt działa jako usługa rejestracyjna domeny blockchain, następnie może zinterpretować dane przekazane do niego jako zawierające dwa "pola", pierwsze pole jest domeną do rejestracji, a drugie pole jest adresem IP do rejestracji. Umowa odczytałaby te wartości z danych wiadomości i odpowiednio umieściłaby je w pamięci. +Pierwsze trzy to standardowe pola, których się oczekuje w każdej kryptowalucie. Pole danych nie ma domyślnie żadnej funkcji, ale maszyna wirtualna posiada kod operacyjny, za pomocą którego kontrakt może uzyskać dostęp do tych danych; dla przykładu, jeśli kontrakt działa na blockchainie jako usługa rejestracji domen, może chcieć zinterpretować przekazywane mu dane jako zawierające dwa „pola”, przy czym pierwsze pole mogłoby być domeną do zarejestrowania, a drugie adresem IP, do którego byłaby przypisana domena. Kontrakt odczytałby te wartości z danych wiadomości i odpowiednio umieścił je w magazynie. -Pola `STARTGAS` i `GASPRICE` są kluczowe dla antynegowania modelu serwisowego. Aby zapobiec przypadkowemu lub wrogim nieskończonym pętlom lub innym stratom obliczeniowym w kodzie, każda transakcja jest wymagana, aby ustawić limit do ile kroków obliczeniowych wykonania kodu, które może użyć. Podstawową jednostką obliczeniową jest „gaz”; Zazwyczaj krok obliczeniowy kosztuje 1 gaz, ale niektóre operacje kosztują więcej gazu, ponieważ są bardziej kosztowne, lub zwiększyć ilość danych, które muszą być przechowywane jako część stanu. Za każdy bajt danych transakcji pobiera się również opłatę w wysokości 5 gazów. Zamiarem systemu opłat jest wymaganie od atakującego zapłaty proporcjonalnie za każdy zasób, który konsumowają, w tym obliczenia, szerokość pasma i przechowywanie; stąd jakakolwiek transakcja, która powoduje, że sieć zużywająca większą ilość dowolnego z tych zasobów musi mieć opłatę gazową w przybliżeniu proporcjonalną do przyrostu ilości. +Pola `STARTGAS` i `GASPRICE` mają kluczowe znaczenie dla modelu ochrony Ethereum przed atakami typu „odmowa usługi”. Aby zapobiec przypadkowym bądź wrogim nieskończonym pętlom lub innym przypadkom marnotrawienia zasobów obliczeniowych w kodzie, każda transakcja musi ustawić limit na liczbę kroków obliczeniowych, które mogą zostać wykorzystane podczas jej realizacji. Podstawową jednostką obliczeniową jest „gaz”; zazwyczaj jeden krok obliczeniowy kosztuje 1 gaz, ale niektóre operacje kosztują większe ilości gazu, ponieważ są bardziej wymagające obliczeniowo lub zwiększają ilość danych, które muszą być przechowywane jako część stanu. Istnieje również opłata w wysokości 5 gazu za każdy bajt w danych transakcji. System opłat ma na celu zmuszenie atakującego do proporcjonalnego płacenia za każdy zasób, który zużywa, w tym za obliczenia, przepustowość i pamięć; w związku z tym każda transakcja, która powoduje zwiększone zużycie któregokolwiek z tych zasobów przez sieć, musi mieć opłatę za gaz w przybliżeniu proporcjonalną to tego wzrostu. -### Wiadomości {#messages} +### Komunikaty {#messages} -Umowy mają możliwość wysyłania „wiadomości” do innych umów. Wiadomości są obiektami wirtualnymi, które nigdy nie są serializowane i istnieją tylko w środowisku wykonania Ethereum. Wiadomość zawiera: +Kontrakty mają możliwość wysyłania „wiadomości” do innych kontraktów. Wiadomości są wirtualnymi obiektami, które nigdy nie są serializowane i istnieją tylko w środowisku wykonawczym Ethereum. Wiadomość zawiera: -- Nadawca wiadomości (niejawny) -- Odbiorca wiadomości -- Ilość etheru do przeniesienia wraz z wiadomością +- Nadawcę wiadomości (niejawny) +- Odbiorcę wiadomości +- Ilość etheru do przesłania wraz z wiadomością - Opcjonalne pole danych - Wartość `STARTGAS` -Wiadomość jest zasadniczo jak transakcja, z wyjątkiem tego, że jest generowana przez kontrakt, a nie przez podmiot zewnętrzny. Wiadomość jest generowana, gdy kontrakt aktualnie wykonujący kod wykonuje kod `CALL` opcode, który tworzy i wykonuje wiadomość. Podobnie jak transakcja, wiadomość prowadzi do konta odbiorcy z jego kodem. Tak więc kontrakty mogą mieć relacje z innymi kontraktami w dokładnie taki sam sposób, jak podmioty zewnętrzne. +Zasadniczo wiadomość jest jak transakcja, z tą różnicą, że jest tworzona przez kontakt, a nie podmiot zewnętrzny. Wiadomość jest tworzona, gdy kontrakt aktualnie wykonujący kod wykona kod operacyjny `CALL`, który tworzy i wykonuje wiadomość. Podobnie jak w przypadku transakcji, wiadomość prowadzi do uruchomienia kodu na koncie odbiorcy. W ten sposób, kontrakty mogą mieć relacje z innymi kontraktami w taki sam sposób, w jaki mogą to robić podmioty zewnętrzne. -Zauważ, że przydział gazu przydzielony przez transakcję lub umowę ma zastosowanie do całkowitej ilości gazu zużywanego przez tę transakcję i do wszystkich zleceń. Na przykład, jeśli zewnętrzny podmiot A wysyła transakcję do B z 1000 gazów, i B zużywa 600 gazu przed wysłaniem wiadomości do C, a wewnętrzna realizacja C zużywa 300 gazu przed powrotem, następnie B może wydać kolejne 100 gazu przed wyczerpaniem gazu. +Warto zauważyć, że przydział gazu przypisany przez transakcję lub kontrakt dotyczy całkowitej ilości gazu zużytej przez tę transakcję i wszystkie jej podwykonania. Na przykład, jeśli podmiot zewnętrzny A wyśle transakcję do B z 1000 gazu, a B zużyje 600 gazu przed wysłaniem wiadomości do C, a wewnętrzne wykonanie C zużyje 300 gazu przed zwróceniem wyniku, to B może zużyć jeszcze 100 gazu przed wyczerpaniem dostępnego gazu. -### Funkcja Przejścia Stanów Ethereum {#ethereum-state-transition-function} +### Funkcja przejścia stanu w Ethereum {#ethereum-state-transition-function} -![Zmiana stanu etheru](./ether-state-transition.png) +![Transformacja stanu Ether](./ether-state-transition.png) -Funkcja zmiany stanu Ethereum, `ZASTOSUJ-(S,TX) -> S'` może być zdefiniowane w następujący sposób: +Funkcja przejścia stanu Ethereum, `APPLY(S,TX) -> S'` może być zdefiniowana w następujący sposób: -1. Sprawdź, czy transakcja jest dobrze sformułowana (tj. ma prawą liczbę wartości), podpis jest prawidłowy, a nonce odpowiada nonce na koncie nadawcy. Jeśli nie, zwracaj błąd. -2. Oblicz opłatę transakcyjną jako `STARTGAS * GASPRICE`, i ustaw adres wysyłający na podstawie podpisu. Odejmij opłatę z salda konta nadawcy i pomnóż wartość jednorazową nadawcy. Jeśli nie ma wystarczającego salda do wydania, zwróć błąd. -3. Inicjalizacja `GAS = STARTGAS`, i odebrać pewną ilość gazu na bajt, aby zapłacić za bajty w transakcji. -4. Przenieś wartość transakcji z konta nadawcy na konto odbiorcze. Jeśli konto odbierające jeszcze nie istnieje, utwórz je. Jeśli konto otrzymujące jest umową, uruchom kod kontraktu albo w celu dokończenia lub do czasu wygaśnięcia wykonania gazu. -5. Jeśli transfer wartości nie powiódł się, ponieważ nadawca nie miał wystarczającej ilości pieniędzy lub podczas wykonanie kodu skończył się gaz, przywróć wszystkie zmiany stanu z wyjątkiem płatności opłat i dodać opłaty do konta kopalni. -6. W przeciwnym razie zwrot opłat za cały pozostały gaz nadawcy i wyślij opłaty zapłacone za gaz zużywany górnikowi. +1. Sprawdź, czy transakcja jest poprawnie sformułowana (tj. ma odpowiednią liczbę wartości), podpis jest prawidłowy, a nonce pasuje do nonce na koncie nadawcy. W przeciwnym razie zwróć błąd. +2. Oblicz opłatę transakcyjną jako `STARTGAS * GASPRICE` i określ adres nadawcy na podstawie podpisu. Odejmij opłatę od salda konta nadawcy i zwiększ nonce nadawcy. Jeśli saldo jest nie wystarczające, aby pokryć opłatę, zwróć błąd. +3. Zainicjuj `GAS = STARTGAS` i odejmij określoną ilość gazu na bajt, aby zapłacić za bajty w transakcji. +4. Przenieś wartość transakcji z konta nadawcy na konto odbiorcy. Jeśli konto odbiorcy jeszcze nie istnieje, utwórz je. Jeśli konto odbiorcy jest kontraktem, wykonaj kod kontraktu do momentu zakończenia lub wyczerpania gazu. +5. Jeśli transfer wartości nie powiedzie się z powodu braku środków na koncie nadawcy lub wykonanie kodu wyczerpało gaz, cofnij wszystkie zmiany stanu z wyjątkiem uiszczenia opłat, a opłaty dodaj do konta górnika. +6. W przeciwnym razie zwróć opłaty za niewykorzystany gaz nadawcy i wyślij opłaty za zużyty gaz na konto górnika. -Na przykład należy przyjąć, że kod kontraktu jest: +Załóżmy na przykład, że kod kontaktu wygląda tak: - if !self.storage[calldataload(0)]: - self.storage[calldataload(0)] = calldataload(32) +```py +if !self.storage[calldataload(0)]: + self.storage[calldataload(0)] = calldataload(32) +``` -Zauważ, że w rzeczywistości kod umowy jest zapisany w kodzie EVM o niskim poziomie; ten przykład jest napisany w Serpent, jednym z naszych języków wysokiego szczebla, dla jasności i może być skompilowany do kodu EVM. Załóżmy, że magazyn umowy zaczyna się od pustego, a transakcja jest wysyłana o wartości 10 eterów, 2000 gazu, 0. 01 cena gazu dla eteru i 64 bajty danych, z bajtami 0-31 reprezentującymi liczbę `2` i bajty 32-63 reprezentujące ciąg `CHARLIE`.[fn. 6](#notes) Proces dla funkcji przejścia stanu w tym przypadku jest następujący: +Warto zauważyć, że w rzeczywistości kod kontraktu jest napisany w niskopoziomowym kodzie EVM; dla przejrzystości, powyższy przykład jest napisany w Serpent, jednym z naszych języków wysokiego poziomu, i może być skompilowany do kodu EVM. Załóżmy, że pamięć kontraktu jest na początku pusta i zostaje wysłana transakcja z wartością 10 etherów, 2000 gazu, ceną gazu 0,001 etheru i 64 bajtami danych, gdzie bajty 0-31 reprezentują liczbę `2`, a bajty 32-63 reprezentują ciąg znaków `CHARLIE`. Proces dla funkcji przejścia stanu w tym przypadku wygląda następująco: -1. Sprawdź, czy transakcja jest prawidłowa i dobrze sformowana. -2. Sprawdź, czy nadawca transakcji ma co najmniej 2000 \* 0.001 = 2 każdego z nich. Jeśli tak, wówczas odjąć 2 ether od konta nadawcy. -3. Rozpoczęcie gazu = 2000; zakładając, że transakcja ma 170 bajtów a opłata bajtowa wynosi 5, odjąć 850 tak, że pozostało 1150 gazów. -4. Odejmij więcej 10 etherów od konta nadawcy i dodaj je do konta kontraktu. -5. Uruchom kod. W tym przypadku jest to proste: sprawdza, czy użyto magazynu w kontrakcie `2`, zauważa, że nie jest, i, aby ustawić pamięć w indeksie `2` na wartość `CHARLIE`. Załóżmy, że to zajmuje 187 gazu, więc pozostała ilość gazu wynosi 1150 - 187 = 963 -6. Dodaj 963 \* 0.001 = 0.963 ether z powrotem na konto nadawcy i zwróć otrzymany stan. +1. Sprawdź, czy transakcja jest prawidłowa i poprawnie sformułowana. +2. Sprawdź, czy nadawca transakcji ma przynajmniej 2000 \* 0.001 = 2 ethery. Jeśli tak, odejmij 2 ethery z konta nadawcy. +3. Zainicjuj gaz = 2000; zakładając, że transakcja ma 170 bajtów, a opłata za bajt wynosi 5, odejmij 850, pozostawiając 1150 gazu. +4. Odejmij kolejne 10 etherów z konta nadawcy i dodaj je do konta kontraktu. +5. Uruchom kod. W tym przypadku jest to proste: sprawdza, czy pamięć kontraktu pod indeksem `2` jest używana, zauważa, że nie jest, więc ustawia pamięć pod indeksem `2` na wartość `CHARLIE`. Załóżmy, że zabiera to 187 gazu, więc pozostała ilość gazu wynosi 1150 - 187 = 963 +6. Dodaj 963 \* 0.001 = 0.963 etheru z powrotem na konto nadawcy i zwróć wynikowy stan. -W przypadku braku kontraktu na dzień otrzymania transakcji, następnie całkowita opłata transakcyjna byłaby po prostu równa dostarczonej `GASPRICE` pomnożonej przez długość transakcji wyrażonej w bajtach, i dane przesyłane wraz z transakcją byłyby nieistotne. +Gdyby po stronie odbiorcy transakcji nie byłoby kontraktu, to całkowita opłata transakcyjna byłaby po prostu równa wartości `GASPRICE` pomnożonej przez długość transakcji w bajtach, a dane przesłane wraz z transakcją byłyby nieistotne. -Zauważ, że wiadomości działają równorzędnie do transakcji pod względem powracają: jeśli wykonanie wiadomości kończy się gazem, następnie tego komunikatu wykonania i wszystkich innych egzekucji wyzwalanych przez to wykonanie, cofnięcie,, ale wykonania nadrzędne nie muszą być przywrócone. Oznacza to, że "bezpiecznie" kontraktu na inną umowę, tak jak w przypadku połączeń B z gazem G, wówczas realizacja A jest gwarantowana utratą co najwyżej gazu G. Na koniec, weź pod uwagę, że istnieje opcode, `STWÓRZ`, który tworzy umowę; jego mechaniki wykonania są na ogół podobne do `CALL`, z wyjątkiem, że wyjście wykonania określa kod nowo utworzonej umowy. +Warto zauważyć, że wiadomości działają podobnie do transakcji w kontekście cofania; jeśli wykonanie transakcji wyczerpie gaz, to jej wykonanie i wszystkie inne wykonania wywołane przez to wykonanie zostaną cofnięte, ale wykonania nadrzędne nie muszą być cofane. Oznacza to, że „bezpieczne” jest dla kontraktu wywołanie innego kontraktu, ponieważ jeśli A wywołuje B z ilością G gazu, to wykonanie A gwarantuje utratę co najwyżej G gazu. Na koniec warto zauważyć, że istnieje kod operacyjny, `CREATE`, który tworzy kontrakt; jego mechanika wykonania jest generalnie podobna do `CALL`, z tą różnicą, że wynik wykonania określa kod nowo utworzonego kontraktu. ### Wykonanie kodu {#code-execution} -Kod w kontraktach Ethereum jest napisany w niskopoziomowym, opartym na stosie języku kodowym bytecode, zwanym "Ethereum virtual machincode" lub "EVM code". Kod składa się z serii bajtów, gdzie każdy bajt reprezentuje operację. Zasadniczo wykonanie kodu jest nieskończoną pętlą polegającą na wielokrotnym przeprowadzaniu operacji w bieżącym liczniku programu (co rozpoczyna się od zera), a następnie zwiększaniu licznika programu o jeden, do momentu osiągnięcia końca kodu lub wykrycia błędu lub `STOP` lub `RETURN`. Operacje mają dostęp do trzech typów przestrzeni do przechowywania danych: +Kod w kontraktach Ethereum jest napisany w niskopoziomowym, opartym na stosie języku kodu bajtowego, nazywanym „kodem maszyny wirtualnej Ethereum” lub „kodem EVM”. Kod składa się z serii bajtów, gdzie każdy bajt reprezentuje operację. Zasadniczo wykonywanie kodu jest nieskończoną pętlą, która polega na wielokrotnym powtarzaniu operacji na bieżącym liczniku programu (który zaczyna od zera), a następnie zwiększaniu licznika programu o jeden, aż do momentu osiągnięcia końca kodu lub napotkania błędu bądź instrukcji `STOP` lub `RETURN`. Operacje mają dostęp do trzech typów przestrzeni do przechowywania danych: -- **stos**, kontener ostatniej w pierwszej kolejności, do którego wartości można wcisnąć i wyciąć +- **Stos**, kontener typu „ostatnie weszło, pierwsze wyszło”, do którego można wstawiać i usuwać wartości - **Pamięć**, nieskończenie rozszerzalna tablica bajtów -- Długoterminowa pamięć **kontraktu**, sklep klucz/wartość. W odróżnieniu od stosu i pamięci, które resetują się po zakończeniu obliczeń, pamięć utrzymuje się przez długi czas. +- Długoterminowa **pamięć** kontraktu, czyli magazyn klucz-wartość. W przeciwieństwie do stosu i pamięci, które są resetowane po zakończeniu obliczeń, magazyn jest trwały i przechowuje dane przez dłuższy czas. -Kod może również uzyskać dostęp do wartości, nadawcy i danych przychodzących wiadomości, jak również dane nagłówka bloku, a kod może również zwracać bajt tablicy danych jako dane wyjściowe. +Kod ma również dostęp do wartości, nadawcy, danych przychodzącej wiadomości, a także do danych nagłówka bloku. Kod może również zwrócić tablicę bajtów danych jako dane wyjściowe. -Formalny model realizacji kodu EVM jest zaskakująco prosty. Podczas gdy maszyna wirtualna Ethereum jest uruchomiona, jej pełny stan obliczeniowy może być zdefiniowany przez kropkę `(block_state, transakcja, wiadomość, kod, pamięć, stack, pc, gaz)`, gdzie `block_state` jest stanem globalnym zawierającym wszystkie konta, także zawiera salda i pamięć. Na początku każdej rundy egzekucji bieżąca instrukcja jest odnajdywana przez pobranie `pc`-tego bajtu `code` (lub 0, jeśli `pc >= len(kod)`), a każda instrukcja ma własną definicję pod względem tego, jak wpływa na krotkę. Na przykład `ADD` wyświetla dwa elementy poza stos i pycha ich sumę, zmniejsza `gaz` o 1 i przyrosty `pc` o 1, i `PRZECHOWYWANIE` wyświetla dwa najlepsze elementy poza stosem i wstawia drugą pozycję do magazynu kontraktu w indeksie określonym przez pierwszą pozycję. Chociaż istnieje wiele sposobów optymalizacji Ethereum wykonywania maszyny wirtualnej poprzez kompilację just-in-time podstawowa implementacja Ethereum może być wykonana za kilkaset linii kodu. +Formalny model wykonywania kodu EVM jest zaskakująco prosty. Podczas gdy Wirtualna Maszyna Ethereum jest uruchomiona, jej pełny stan obliczeniowy może być zdefiniowany za pomocą krotki `(block_state, transaction, message, code, memory, stack, pc, gas)`, gdzie `block_state` to globalny stan zawierający wszystkie konta, w tym ich salda i pamięć. Na początku każdej rundy wykonywania aktualna instrukcja jest odnajdywana poprzez pobranie `pc`-tego bajtu `code` (lub 0, jeśli `pc >= len(code)`), a każda instrukcja ma własną definicję tego, jak wpływa na krotkę. Na przykład `ADD` usuwa dwa elementy ze stosu i dodaje z powrotem ich sumę, zmniejsza `gas` o 1 i zwiększa `pc` o 1, a `SSTORE` usuwa dwa górne elementy ze stosu i wstawia drugi element do pamięci kontraktu pod indeksem określonym przez pierwszy element. Chociaż istnieje wiele sposobów optymalizacji wykonywania kodu maszyny wirtualnej Ethereum, na przykład poprzez kompilację just-in-time, podstawową implementację Ethereum można zrealizować w kilku setkach linii kodu. -### Łańcuch bloków i górnictwo {#blockchain-and-mining} +### Blockchain i wydobycie {#blockchain-and-mining} -![Schemat blokowy zastosowania Ethereum](./ethereum-apply-block-diagram.png) +![Diagram bloku aplikowania w Ethereum](./ethereum-apply-block-diagram.png) -Blockchain Ethereum jest pod wieloma względami podobny do łańcucha bloków Bitcoin, choć ma pewne różnice. Główna różnica między Ethereum i Bitcoinem w odniesieniu do architektury blockchain polega na tym, że w odróżnieniu od Bitcoin(który zawiera tylko kopię listy transakcji), Bloki Ethereum zawierają kopię zarówno listy transakcji, jak i najnowszego stanu. Oprócz tego, dwie inne wartości, liczba bloku i trudności, są również przechowywane w bloku. Podstawowy blok algorytm walidacji w Ethereum jest następujący: +Blockchain Ethereum jest w wielu aspektach podobny do blockchainu Bitcoin, chociaż ma też pewne różnice. Główna różnica między Ethereum a Bitcoinem pod względem architektury blockchainu polega na tym, że bloki Ethereum, w przeciwieństwie do bloków Bitcoin, zawierają kopię zarówno listę transakcji, jak i najnowszego stanu. Poza tym, w bloku przechowywane są również dwie inne wartości: numer bloku i trudność. Podstawowy algorytm walidacji bloku w Ethereum wygląda następująco: -1. Sprawdź, czy poprzedni blok odwołany przez blok istnieje i jest ważny. -2. Sprawdź, czy znacznik czasu bloku jest większy niż w poprzedni blok i mniej niż 15 minut w przyszłości -3. Sprawdź, czy numer bloku, poziom trudności, korzeń transakcji, wujek limit root i gazu (różne koncepcje specyficzne dla Ethereum niskiego poziomu) są ważne. -4. Sprawdź, czy dowód pracy na bloku jest ważny. -5. Niech `S[0]` będzie stanem na końcu poprzedniego bloku. -6. Załóżmy, że `TX` jest listą transakcji z `n` transakcji. Dla wszystkich `i` w `0...n-1`, ustaw `S[i+1] = APPLY(S[i],TX[i])`. Jeśli którakolwiek z aplikacji zwraca błąd, lub jeśli całkowity gaz zużywany w bloku w górę aż do momentu, gdy ten punkt przekroczy `GASLIMIT`, zwróć błąd. -7. Pozwól `S_FINAL` być `S[n]`, ale dodaj nagrodę za blok zapłaconą górnikowi. -8. Sprawdź, czy pierwiastek drzewa Merkle stanu `S_FINAL` jest równy końcowemu pierwiastkowi stanu podanemu w nagłówku bloku. Jeśli tak, blok jest ważny; w przeciwnym razie jest nieprawidłowy. +1. Sprawdź, czy poprzedni blok, do którego się odwołano, istnieje i jest prawidłowy. +2. Sprawdź, czy znacznik czasu bloku jest większy niż znacznik czasu poprzedniego bloku i mniejszy niż 15 minut w przyszłość. +3. Sprawdź, czy numer bloku, trudność, korzeń transakcji, korzeń wujka oraz limit gazu (różne niskopoziomowe koncepcje specyficzne dla Ethereum) są prawidłowe. +4. Sprawdź, czy proof-of-work w bloku jest prawidłowy. +5. Niech S[0] będzie stanem na końcu poprzedniego bloku. +6. Niech `TX` będzie listą transakcji bloku z `n` transakcjami. Dla wszystkich `i` w `0...n-1`, ustaw `S[i+1] = APPLY(S[i],TX[i])`. Jeśli którakolwiek z aplikacji zwróci błąd lub jeśli całkowite zużycie gazu w bloku do tego momentu przekroczy `GASLIMIT`, zwróć błąd. +7. Niech `S_FINAL` będzie równe `S[n]`, ale z dodaną nagrodą za blok wypłaconą górnikowi. +8. Sprawdź, czy korzeń drzewa Merkle stanu `S_FINAL` jest równy końcowemu korzeniowi stanu podanemu w nagłówku bloku. Jeśli tak, blok jest prawidłowy; w przeciwnym razie jest nieprawidłowy. -Podejście na pierwszy rzut oka może wydawać się wysoce nieskuteczne, ponieważ musi przechowywać cały stan z każdym blokiem, ale w rzeczywistości wydajność powinna być porównywalna do wydajności Bitcoin. Powodem jest to, że stan jest przechowywany w strukturze drzewa, i po każdym bloku tylko mała część drzewa musi zostać zmieniona. Tak więc ogólnie pomiędzy dwoma sąsiadującymi blokami zdecydowana większość drzewa powinna być taka sama, i dlatego dane mogą być przechowywane raz i odsyłane dwukrotnie za pomocą wskaźników (tj. hashy subdrzewa). Aby to osiągnąć, użyto specjalnego rodzaju drzewa znanego jako "drzewo Patricia". łącznie z modyfikacją pojęcia drzewa Merkle, która pozwala na wstawienie węzłów i usunięcie, a nie tylko na sprawne zmiany. Dodatkowo, ponieważ wszystkie informacje o stanie są częścią ostatniego bloku, nie ma potrzeby przechowywania całej historii blockchain - strategii, która jeśli może być zastosowany do Bitcoina, można obliczyć aby zapewnić 5-20x oszczędności w przestrzeni. +Podejście to może wydawać się bardzo nieefektywne na pierwszy rzut oka, ponieważ wymaga przechowywania całego stanu z każdym blokiem, ale w rzeczywistości efektywność powinna być porównywalna do tej w Bitcoinie. Powodem jest to, że stan jest przechowywany w strukturze drzewa, a po każdym bloku tylko mała część drzewa musi być zmieniana. W związku z tym na ogół między dwoma sąsiednimi blokami zdecydowana większość drzewa powinna być taka sama, a zatem dane mogą być przechowywane raz i odwoływane podwójnie za pomocą wskaźników (tj. haszy poddrzew). W tym celu wykorzystuje się specjalny rodzaj drzewa znany jako „drzewo Patricia”, które jest modyfikacją koncepcji drzewa Merkle, umożliwiającą efektywne dodawanie i usuwanie węzłów, a nie tylko ich zmianę. Co więcej, ponieważ wszystkie informacje o stanie są częścią ostatniego bloku, nie ma potrzeby przechowywania całej historii blockchainu — strategia, która gdyby mogła być zastosowana w Bitcoinie, mogłaby zapewnić oszczędności rzędu 5-20 razy względem przestrzeni. -Często zadawane pytanie brzmi: "gdzie" kod kontraktu w kategoriach fizycznego sprzętu. Ma to prostą odpowiedź: proces wykonywania kodu kontraktu jest częścią definicji funkcji przejścia stanu, który jest częścią algorytmu walidacji bloku, więc jeśli transakcja jest dodana do bloku `B` kod wygenerowany przez tę transakcję zostanie wykonany przez wszystkie węzły, teraz i w przyszłości, ten pobierz i zweryfikuj blok `B`. +Często zadawanym pytaniem jest „gdzie” wykonywany jest kod kontraktu, pod względem fizycznego sprzętu. Odpowiedź jest prosta: proces wykonywania kodu kontraktu jest częścią definicji funkcji przejścia stanu, która jest częścią algorytmu walidacji bloku, więc jeśli transakcja zostanie dodana do bloku `B`, wykonanie kodu wywołane przez tę transakcję zostanie wykonane przez wszystkie węzły, teraz i w przyszłości, które pobiorą i zweryfikują blok `B`. ## Aplikacje {#applications} -Ogólnie rzecz biorąc, oprócz Ethereum istnieją trzy rodzaje zastosowań. Pierwsza kategoria to aplikacje finansowe, dające użytkownikom potężniejsze sposoby zarządzania i zawierania umów przy użyciu pieniędzy. Obejmuje to podzlecenia, pochodne instrumenty finansowe, kontrakty zabezpieczające, portfele oszczędnościowe, testamenty, a ostatecznie nawet niektóre klasy umów o pracę. Druga kategoria to aplikacje półfinansowe, w których zaangażowane są pieniądze, ale istnieje również ciężka strona niepieniężna tego, co się dzieje; Doskonałym przykładem jest samowymuszanie odbić się na rozwiązaniach problemów obliczeniowych. Wreszcie istnieją takie aplikacje, jak głosowanie online i zdecentralizowane zarządzanie które w ogóle nie są finansowe. +Ogólnie rzecz biorąc, na Ethereum istnieją trzy rodzaje zastosowań. Pierwsza kategoria to aplikacje finansowe, które zapewniają użytkownikom bardziej zaawansowane sposoby zarządzania i zawierania umów z wykorzystaniem ich środków. Obejmuje to subwaluty, derywaty finansowe, kontrakty zabezpieczające, portfele oszczędnościowe, testamenty, a nawet niektóre rodzaje pełnowymiarowych umów o pracę. Druga kategoria to aplikacje półfinansowe, w których zaangażowane są pieniądze, ale istnieje również silna strona niepieniężna tego, co się robi; doskonałym przykładem są samoegzekwujące się nagrody za rozwiązania problemów obliczeniowych. Trzecia kategoria to aplikacje, takie jak głosowanie online i zdecentralizowane zarządzanie, które nie są w ogóle związane z finansami. ### Systemy tokenów {#token-systems} -Systemy tokenów blockchain mają wiele zastosowań, począwszy od podwalut reprezentujących aktywa takie jak USD lub złoto po firmę, indywidualne tokeny reprezentujące inteligentną nieruchomość, zabezpiecz nieprzerobione kupony, a nawet systemy tokenów bez powiązań z konwencjonalną wartością w ogóle używane jako systemy motywacyjne. Systemy tokenów są zaskakująco łatwe do wdrożenia w Ethereum. Kluczowym punktem do jest to, że waluta lub system tokenów, zasadniczo jest bazą danych z jedną operacją: odjąć X jednostki od A i dać X jednostkom B, z przepisem, że (1) A posiadała co najmniej X jednostek przed transakcją oraz (2) transakcja jest zatwierdzona przez A. Wszystko, czego potrzebuje do wdrożenia systemu tokenów to wdrożenie tej logiki do umowy. +Blockchainowe systemy tokenów mają wiele zastosowań, począwszy od subwalut reprezentujących aktywa takie jak USD, złoto czy nawet akcje firm, indywidualnych tokenów reprezentujących inteligentną własność, bezpiecznych i niepodrabialnych kuponów, aż do systemów tokenów niezwiązanych z tradycyjną wartością, wykorzystywanych jako systemy punktowe do zachęcania. Systemy tokenów są zaskakująco łatwe do zaimplementowania w Ethereum. Kluczowym punktem do zrozumienia jest to, że każda waluta lub system tokenów to zasadniczo baza danych z jedną operacją: odejmij X jednostek od A i dodaj X jednostek do B z zastrzeżeniem, że (1) A miał co najmniej X jednostek przed transakcją oraz (2) transakcja została zatwierdzona przez A. Wszystko, czego potrzeba do zaimplementowania systemu tokenów, to zaimplementowanie tej logiki w kontrakcie. -Podstawowy kod do implementacji systemu tokenów w Serpent wygląda tak: następuje: +Podstawowy kod do implementacji systemu tokenów w Serpent wygląda następująco: - def wyślij (do, wartość): - jeśli siebie. torage[msg.sender] >= wartość: - siebie. torage[msg.sender] = self.storage[msg.sender] - wartość - samo. torage[to] = samodzielny.magazyn[to] + wartość +```py +def send(to, value): + if self.storage[msg.sender] >= value: + self.storage[msg.sender] = self.storage[msg.sender] - value + self.storage[to] = self.storage[to] + value +``` -Jest to zasadniczo dosłowne wdrożenie „systemu bankowego” funkcji transformacji stanu, opisanej powyżej w niniejszym dokumencie. Kilka dodatkowych linii kodu, aby zapewnić początkowy etap dystrybucji jednostek waluty w pierwszym miejscu i kilka innych skrzynek krawędziowych, i idealnie funkcja zostałaby dodana, aby umożliwić innym umowom zapytanie o saldo adresu. Ale to wszystko jest w porządku. Teoretycznie Systemy tokenów ethereum, działające jako subwaluty, mogą potencjalnie zawierać inną ważną funkcję, której w łańcuchu meta-waluty bazujące na Bitcoinach brakuje: możliwość uiszczania opłat za transakcje bezpośrednio w tej walucie. Sposób, w jaki miałaby być wdrożony, jest taki, że kontrakt utrzymałby saldo eteru, z którym zwrócił ether użyty do uiszczenia opłat na rzecz nadawcy, i napełniłby saldo pobierając wewnętrzne jednostki walutowe, które pobiera, i odsprzedając je na ciągłej aukcji. Użytkownicy musieliby zatem "aktywować" swoje konta z eterem, ale kiedy ether będzie tam taki, będzie mógł zostać ponownie użyty, ponieważ kontrakt będzie go zwracał za każdym razem. +Jest to zasadniczo dosłowna implementacja funkcji przejścia stanu „systemu bankowego” opisanej wcześniej w tym dokumencie. Trzeba dodać kilka dodatkowych linijek kodu, aby zapewnić początkowy etap dystrybucji jednostek walutowych, a najlepiej byłoby dodać funkcję, która pozwoli innymi kontraktom sprawdzenie salda adresu. I to wszystko. Teoretycznie, oparte na Ethereum systemy tokenów odgrywające rolę walut podrzędnych mogą potencjalnie zawierać inną ważną funkcję, której brakuje meta walutom opartym na Bitcoinie: możliwość płacenia opłat transakcyjnych w tej walucie. Sposób, w jaki można by to zaimplementować, polega na tym, że kontakt utrzymywałby saldo etheru, z którego refundowałby ether użyty do uiszczenia opłat nadawcy, a uzupełniałby to saldo, zbierając wewnętrzne jednostki walutowe pobierane jako opłaty i odsprzedając je w stale trwającej aukcji. Użytkownicy musieliby zatem „aktywować” swoje konta za pomocą etheru, ale gdy ether byłby już na koncie, to mógłby on być ponownie używany, ponieważ kontrakt refundowałby go za każdym razem. -### Instrumenty pochodne i waluty o stabilnej wartości {#financial-derivatives-and-stable-value-currencies} +### Pochodne finansowe i waluty o stabilnej wartości {#financial-derivatives-and-stable-value-currencies} -Finansowe instrumenty pochodne są najczęstszym zastosowaniem „inteligentnego kontraktu ” i jednym z najprostszych do wdrożenia w kodzie. Głównym wyzwaniem dla realizacji umów finansowych jest to, że większość z nich wymaga odniesienia do zewnętrznego wskaźnika ceny; Na przykład bardzo pożądane zastosowanie jest inteligentnym kontraktem, który zabezpiecza się przed zmiennością eteru (lub innej kryptowaluty) w stosunku do amerykańskiego dolara, ale wykonanie tego wymaga od kontraktu wiedzieć, jaka jest wartość ETH/USD. Najprostszym sposobem na to jest kontrakt "kanał danych" utrzymywany przez konkretną stronę (np. NASDAQ) zaprojektowany tak, aby strona miała możliwość aktualizowania kontraktu w razie potrzeby, i udostępnienie interfejsu umożliwiającego innym kontraktom wysłanie wiadomości do tego kontraktu i odzyskanie odpowiedzi podającej cenę. +Derywaty finansowe są najczęstszym zastosowaniem „inteligentnego kontraktu” i jednym z najprostszych do zaimplementowania w kodzie. Głównym wyzwaniem przy implementacji kontraktów finansowych jest to, że większość z nich wymaga odniesienia do zewnętrznego wskaźnika cen; na przykład bardzo pożądanych zastosowaniem jest inteligentny kontrakt, który zabezpiecza przed zmiennością etheru (lub innej kryptowaluty) w odniesieniu do dolara amerykańskiego, ale wymaga to, aby kontrakt wiedział jaka jest wartość ETH/USD. Najprostszym sposobem na to jest użycie kontraktu „kanału danych” utrzymywanego przez określoną stronę (np. NASDAQ), zaprojektowanego tak, aby ta strona miała możliwość aktualizowania kontraktu w razie potrzeby oraz zapewnienia interfejsu, który pozwala innym kontraktom wysyłać wiadomości do tego kontraktu i otrzymywać odpowiedź zawierającą cenę. -Biorąc pod uwagę ten krytyczny składnik, kontrakt hedgingowy wyglądałby tak: następuje: +Biorąc pod uwagę ten krytyczny składnik, kontrakt zabezpieczający wyglądałby następująco: -1. Poczekaj, aż strona A wprowadzi 1000 etherów. -2. Poczekaj, aż strona B wprowadzi 1000 etherów. -3. Nagrywaj wartość USD 1000 eterów, obliczoną przez zapytanie o kontraktu na kanał w pamięci, powiedzmy, że to jest $x. -4. Po 30 dniach, zezwól A lub B na "reaktywację" kontraktu, aby wysłać $x wartość etheru (obliczoną przez ponowne zapytanie kontraktu w celu uzyskania nowej ceny) do A i reszty do B. +1. Poczekaj, aż strona A wpłaci 1000 etherów. +2. Poczekaj, aż strona B wpłaci 1000 etherów. +3. Zapisz w magazynie wartość USD równą 1000 etherów, obliczoną poprzez zapytanie kontraktu kanału danych, powiedzmy, że jest to $x. +4. Po 30 dniach pozwól A lub B „reaktywować” kontrakt w celu wysłania etheru o wartości $x (obliczonego poprzez ponowne zapytanie kontraktu kanału danych w celu uzyskania nowej ceny) do A, a resztę do B. -Taka umowa miałaby znaczny potencjał w handlu kryptowalutami. Jeden z głównych wymienionych problemów dotyczących kryptowaluty jest fakt, że jest lotny; chociaż wielu użytkowników i sprzedawców może chcieć bezpieczeństwa i wygoda obchodzenia się z zasobami kryptograficznymi, mogą nie chcieć zmierzyć się z perspektywą utraty 23% wartości swoich środków w jednym dzień. Do tej pory najczęściej proponowanym rozwiązaniem było aktywów zabezpieczonych emitentami; emitent tworzy subwalutę, w której ma prawo do emisji i cofania jednostek uczestnictwa, i podaj jedną jednostkę waluty każdemu, kto dostarcza ją (offline) jedną jednostkę określonego składnika aktywów bazowych (np. Złoto, USD). Emitent obiecuje dostarczyć jedną jednostkę bazowego składnika aktywów każdemu, kto odsyła z powrotem jedną jednostkę kryptowaluty. Mechanizm ten pozwala każdemu niekryptograficznemu aktywowi "przekształcić go w aktywa kryptograficzne, pod warunkiem że emitent może być zaufany. +Taki kontrakt miałby znaczący potencjał w handlu kryptowalutami. Jednym z głównych problemów wymienianych w odniesieniu do kryptowalut jest fakt, że są one zmienne; chociaż wielu użytkowników i kupców może chcieć korzystać z bezpieczeństwa i wygody, jakie oferują kryptograficzne aktywa, to nie chcą oni jednak ryzykować utraty 23% wartości swoich środków w ciągu jednego dnia. Do tej pory najczęściej proponowanym rozwiązaniem były aktywa zabezpieczone przez emitenta; zamysł jest taki, że to emitent tworzy subwalutę, w której ma prawo emitować i odwoływać jednostki, a także dostarczać jedną jednostkę waluty każdemu, kto dostarczy mu (offline) jedną jednostkę określonego aktywa bazowego (np. złota, USD). Emitent obiecuje następnie dostarczyć jedną jednostkę aktywa bazowego każdemu, kto odeśle mu jedną jednostkę krypto-aktywa. Mechanizm ten umożliwia „podniesienie” dowolnego niekryptograficznego aktywa do aktywa kryptograficznego, pod warunkiem, że emitentowi można zaufać. -W praktyce jednak emitenci nie zawsze są wiarygodni, a w niektórych przypadkach infrastruktura bankowa jest zbyt słaba lub zbyt wroga, aby takie usługi mogły istnieć. Alternatywnym rozwiązaniem są finansowe instrumenty pochodne. Tutaj, zamiast jednego emitenta dostarczającego środki do wykonania kopii zapasowej, zdecentralizowany rynek spekulantów, zakładający cenę kryptograficznego referencyjnego składnika aktywów (np. ETH) przejdzie do przodu, odgrywając tę rolę. W odróżnieniu od emitentów, spekulanci nie mają możliwości niewywiązania się ze zobowiązań z umowy, ponieważ kontrakt zabezpieczający przechowuje swoje środki w escrow. Zauważ, że to podejście nie jest w pełni zdecentralizowane, ponieważ zaufane źródło jest nadal potrzebne do zapewnienia znacznika ceny, chociaż jest to nawet nadal ogromna poprawa pod względem zmniejszenia wymogów w zakresie infrastruktury (w przeciwieństwie do emitenta, wystawienie ceny kanału nie wymaga żadnych licencji i może być sklasyfikowane jako swoboda wypowiedzi) i ograniczenie możliwości oszustw. +W praktyce jednak emitenci nie zawsze są godni zaufania, a w niektórych przypadkach infrastruktura bankowa jest zbyt słaba lub wroga, aby takie usługi mogły istnieć. Derywaty finansowe stanowią alternatywę. W tym przypadku zamiast pojedynczego emitenta zapewniającego środki na zabezpieczenie aktywa, rolę odgrywa zdecentralizowany rynek spekulantów, obstawiających, że cena kryptograficznego aktywa referencyjnego (np. ETH) wzrośnie. W przeciwieństwie do emitentów, spekulanci nie mają możliwości wycofania się ze swojej części umowy, ponieważ kontrakt zabezpieczający przechowuje ich fundusze w depozycie. Warto zauważyć, że takie podejście nie jest w pełni zdecentralizowane, ponieważ wciąż potrzebne jest zaufane źródło do dostarczania wskaźnika cenowego, choć mimo to stanowi ono ogromną poprawę pod względem zmniejszenia wymagań infrastrukturalnych (w przeciwieństwie do bycia emitentem, dostarczanie wskaźnika cenowego nie wymaga licencji i moze być prawdopodobnie sklasyfikowane jako wolność słowa) oraz zmniejszenia potencjału oszustw. -### Systemy identyfikacji i reputacji {#identity-and-reputation-systems} +### Systemy tożsamości i reputacji {#identity-and-reputation-systems} -Najwcześniejsza alternatywna kryptowaluta, [Namecoin](http://namecoin.org/), próbowała użyć blockchain podobny do Bitcoina, aby zapewnić system rejestracji nazwy, gdzie użytkownicy mogą rejestrować swoje nazwy w publicznej bazie danych wraz z innymi danymi. Główny cytowany przypadek użycia dotyczy a System [DNS](https://wikipedia.org/wiki/Domain_Name_System), mapowanie nazwy domen, takie jak „bitcoin.org” (lub, w przypadku Namecoin, „bitcoin.bit”) na adres IP. Inne przypadki użycia obejmują uwierzytelnianie poczty elektronicznej i potencjalnie bardziej zaawansowane systemy reputacji. Oto podstawowa umowa, aby dostarczyć system rejestracji nazw podobnych do Namecoin na Ethereum: +Najwcześniejsza ze wszystkich alternatywnych kryptowalut, [Namecoin](http://namecoin.org/), próbowała wykorzystać blockchain podobny do Bitcoina do zapewnienia systemu rejestracji nazw, w którym użytkownicy mogą rejestrować swoje nazwy w publicznej bazie danych wraz z innymi danymi. Głównym cytowanym przypadkiem użycia jest system [DNS](https://wikipedia.org/wiki/Domain_Name_System), który mapuje nazwy domen, takie jak „bitcoin.org” (lub w przypadku Namecoina, „bitcoin.bit”) na adres IP. Inne przypadki użycia obejmują uwierzytelnianie e-maili i potencjalnie bardziej zaawansowane systemy reputacji. Oto podstawowy kontrakt zapewniający podobny do Namecoin system rejestracji nazw na Ethereum: - def register(nazwa, wartość): - if !self.storage[name]: - self.storage[name] = wartość +```py +def register(name, value): + if !self.storage[name]: + self.storage[name] = value +``` -Umowa jest bardzo prosta; wszystko to jest baza danych wewnątrz sieci Ethereum, która może być dodawana do sieci ale nie modyfikowana ani usuwana. Każdy może zarejestrować nazwę z pewną wartością, a ta rejestracja zostanie zachowana na zawsze. Bardziej zaawansowana umowa rejestracji nazw będzie również zawierać "klauzulę funkcji" umożliwiającą innym umowom zapytanie o nie, jak również mechanizm dla "właściciela" (tj. pierwszy rejestrujący) nazwy mającej na celu zmianę danych lub przeniesienie własności. Można nawet dodać reputację i funkcji sieciowej zaufania. +Kontrakt jest bardzo prosty; jest to baza danych wewnątrz sieci Ethereum, do której można dodawać, ale nie można modyfikować ani usuwać. Każdy może zarejestrować nazwę z pewną wartością, a rejestracja ta pozostaje na zawsze. Bardziej zaawansowany kontrakt rejestracji nazw będzie również posiadać „klauzulę funkcji” pozwalającą innym kontraktom odpytywać go, a także mechanizm dla „właściciela” (tj. pierwszego rejestrującego) nazwy do zmiany nazwy lub przeniesienia własności. Można nawet dodać funkcjonalność reputacji i sieci zaufania. -### Zdecentralizowane przechowywanie plików {#decentralized-file-storage} +### Zdecentralizowana pamięć plików {#decentralized-file-storage} -W ciągu ostatnich kilku lat pojawiło się wiele popularnych startów przechowywania plików online, z których najważniejszym jest Dropbox, szukanie pozwolenia użytkownikom na przesłanie kopii zapasowej dysku twardego i przechowywanie kopii zapasowej i umożliwienie użytkownikowi dostępu do niej w zamian za miesięczną opłatę. Jednak w tym momencie rynek przechowywania plików jest stosunkowo nieefektywny; kursory spojrzą na różne [istniejące rozwiązania](http://online-storage-service-review.toptenreviews.com/) pokazuje, że: w szczególności na poziomie 20–200 GB na poziomie, w którym nie pojawiają się żadne wolne kwoty ani rabaty na poziomie przedsiębiorstwa, miesięczne ceny głównego przechowywania plików są takie, że płacisz za więcej niż koszt całego dysku twardego w jednym miesiącu. Kontrakty Ethereum mogą umożliwić opracowanie zdecentralizowanego ekosystemu przechowywania plików, gdzie indywidualni użytkownicy mogą zarobić małe ilości pieniędzy poprzez wynajem własnych twardych dysków, a niewykorzystane miejsce może zostać wykorzystane do dalszego obniżenia kosztów przechowywania plików. +W ciągu ostatnich lat pojawiło się wiele popularnych startupów zajmujących się przechowywaniem plików online, z których najbardziej znanym jest Dropbox, oferujący użytkownikom możliwość przesyłania kopii zapasowej swojego dysku i przechowywania ich w usłudze oraz udostępniania za miesięczną opłatą. Jednak aktualnie rynek przechowywania plików jest czasami stosunkowo nieefektywny; pobieżne spojrzenie na istniejące rozwiązania pokazuje, że szczególnie na poziomie „doliny niesamowitości” 20-200 GB, na którym nie działają ani bezpłatne kwoty, ani rabaty dla przedsiębiorstw, miesięczne ceny za przechowywanie plików są takie, że płaci się więcej w ciągu jednego miesiąca więcej niż za cały dysk. Kontrakty Ethereum mogą umożliwić rozwój ekosystemy zdecentralizowanego przechowywania plików, w którym indywidualni użytkownicy mogą zarabiać drobne kwoty, wynajmując swoje własne dyski, a niewykorzystana przestrzeń może być używana do dalszego obniżania kosztów przechowywania plików. -Kluczowym elementem takiego urządzenia byłoby to, co nazwaliśmy "zdecentralizowanym kontraktem Dropbox". Umowa ta działa w następujący sposób. Najpierw dzieli żądane dane na bloki, szyfrując każdy blok dla prywatności i buduje z tego drzewo Merkle. Jeden z nich tworzy kontraktu z regułą, że każdy N bloków, kontrakt wybierze losowy indeks w drzewie Merkle (używając poprzedniego skrótu bloku, dostępny z kodu kontraktu, jako źródło losowania), i dać X eterowi pierwszemu podmiotowi, który dostarczył transakcję z uproszczonym dowodem posiadania tego bloku w tym określonym indeksie drzewa. Gdy użytkownik chce ponownie pobrać swój plik, może użyć protokołu kanału mikropłatności (np. zapłać 1 szabo per 32 kilobajtów) za odzyskanie pliku; najbardziej opłacalnym podejściem jest dla zleceniodawcy, aby nie publikować transakcji do końca, zamiast zastąpienie transakcji nieco bardziej dochodową transakcją tą samą nraz po 32 kilobajtach. +Kluczowym elementem takiego urządzenia byłoby to, co nazwaliśmy „kontraktem zdecentralizowanego Dropboxa”. Kontrakt ten działa w następujący sposób. Najpierw dzieli się pożądane dane na bloki, szyfrując każdy blok dla prywatności, a następnie tworzy się z nich drzewo Merkle. Następnie tworzy się kontrakt z regułą, że co N bloków, kontrakt wybierze losowy indeks z drzewa Merkle (używając hasha poprzedniego bloku, dostępnego z kodu kontraktu, jako źródło losowości) i da X etheru pierwszemu podmiotowi, który dostarczy transakcję z dowodem własności bloku w tym konkretnym indeksie drzewa, podobnym do uproszczonej weryfikacji płatności. Gdy użytkownik chce ponownie pobrać swój plik, może użyć protokołu kanału mikropłatności (np. zapłacić 1 szabo za 32 kilobajty), aby odzyskać plik; najefektywniejszym podejściem dla płacącego pod względem opłat jest to, aby nie publikował transakcji do końca, zamiast tego zastępując transakcję nieco bardziej opłacalną transakcją z tym samym nonce po każdych 32 kilobajtach. -Ważną cechą protokołu jest to, że: chociaż może wydawać się, że jeden ufa wielu losowym węzłom, aby nie zdecydowały się zapomnieć o pliku, jeden może zmniejszyć to ryzyko do niemal zera dzieląc plik na wiele kawałków poprzez tajne udostępnianie, i oglądanie kontraktów, aby zobaczyć każdy element jest nadal w posiadaniu jakiegoś węzła. Jeśli kontrakt nadal płaci pieniędze, to stanowi dowód kryptograficzny, że ktoś tam nadal przechowuje plik. +Ważną cechą tego protokołu jest to, że chociaż może się wydawać, że użytkownik ufa wielu losowym węzłom, że nie zapomną o pliku, można zredukować to ryzyko do niemal zera, dzieląc plik na wiele części za pomocą protokołu dzielenia sekretu i obserwując kontrakty, aby zobaczyć, czy każdy kawałek jest nadal w posiadaniu jakiegoś węzła. Jeśli kontrakt nadal wypłaca pieniądze, stanowi to kryptograficzny dowód na to, że ktoś nadal przechowuje plik. -### Zdecentralizowana Organizacja Autonomiczna {#decentralized-autonomous-organizations} +### Zdecentralizowane organizacje autonomiczne {#decentralized-autonomous-organizations} -Ogólna koncepcja „zdecentralizowanej organizacji autonomicznej” jest taka: wirtualnego podmiotu, który ma określony zestaw członków lub udziałowców które, być może z większością 67%, mają prawo do wydawania środków finansowych podmiotu funduszy i modyfikować jego kod. Członkowie wspólnie decydują, w jaki sposób organizacja powinna przydzielić swoje środki. Metody przydzielania a Fundusze DAO mogą obejmować nagrody, pensje, a nawet bardziej egzotyczne mechanizmy, takie jak wewnętrzna waluta, aby nagradzać pracę. Zasadniczo replikuje legalne obrazy tradycyjnej firmy lub non-profit, ale przy użyciu wyłącznie kryptograficznej technologii blockchain. Jak dotąd wiele rozmów o DAO-ach dotyczyło modelu „kapitalistycznego” „zdecentralizowanej autonomicznej korporacji” (DAC) z dywidendą otrzymującą udziałowców i zbywalnymi akcjami; alternatywę opisaną być może jako „zdecentralizowana społeczność autonomiczna”, gdyby wszyscy członkowie mieli równy udział w procesie podejmowania decyzji i wymagali, aby 67% istniejących członków wyraziło zgodę na dodanie lub usunięcie członka. Wymaganie, że jedna osoba może mieć tylko jedno członkostwo, musiałoby być wtedy wyegzekwowane wspólnie przez grupę. +Ogólna koncepcja „zdecentralizowanej organizacji autonomicznej” polega na tym, że wirtualny podmiot ma określony zestaw członków lub udziałowców, którzy, być może z 67% większością, mają prawo do wydawania funduszy podmiotu i modyfikowania jego kodu. Członkowie wspólnie decydowaliby o tym, jak organizacja powinna ulokować swoje fundusze. Metody alokacji funduszy DAO mogłyby obejmować nagrody i wynagrodzenia, a nawet bardziej egzotyczne mechanizmy, takie jak wewnętrzna waluta do nagradzania pracy. Zasadniczo replikuje to prawne cechy tradycyjnej firmy lub organizacji non-profit, ale przy użyciu wyłącznie kryptograficznej technologii blockchain do egzekwowania prawa. Do tej pory wiele dyskusji na temat DAO dotyczyło „kapitalistycznego” modelu „zdecentralizowanej korporacji autonomicznej” (DAC) z akcjonariuszami otrzymującymi dywidendy i zbywalnymi udziałami; alternatywa, być może określana jako „zdecentralizowana społeczność autonomiczna”, miałaby równy udział wszystkich członków w podejmowaniu decyzji i wymagałaby zgody 67% obecnych członków na dodanie lub usunięcie członka. Wymóg, aby jedna osoba mogła mieć tylko jedno członkostwo, musiałby być wtedy egzekwowany wspólnie przez grupę. -Ogólny zarys kodowania DAO przedstawia się następująco. Najprostszy projekt to po prostu fragment samomodyfikującego się kodu, który zmienia się, jeśli dwie trzecie członków zgadza się na zmianę. Chociaż kod teoretycznie jest niezmienny, można łatwo dotrzeć do tego i mieć faktyczną zmienność poprzez posiadanie fragmentów kodu w osobnych kontraktach, oraz posiadanie adresów, z których kontrakty na wezwanie do przechowywania przechowywane w zmodyfikowanym magazynie. W prostej realizacji takiej umowy DAO będą trzy typy transakcji, wyróżnione danymi dostarczonymi w transakcji: +Ogólny zarys kodowania DAO jest następujący. Najprostszy projekt to po prostu fragment samomodyfikującego się kodu, który zmienia się, jeśli dwie trzecie członków zgodzi się na zmianę. Chociaż kod jest teoretycznie niezmienny, można to łatwo obejść i uzyskać faktyczną zmienność, umieszczając fragmenty kodu w osobnych kontraktach i przechowując adresy kontraktów, które należy wywołać, w modyfikowalnym magazynie. W prostej implementacji takiego kontraktu DAO byłyby trzy typy transakcji, rozróżniane na podstawie danych dostarczanych w transakcji: -- `Struktura danych]` aby zarejestrować propozycję z indeksem `i` aby zmienić adres w indeksie magazynu `K` na wartość `V` -- `[1,i]` aby zarejestrować głos za wnioskiem `i` -- `[2,i]` aby sfinalizować propozycję `i` jeśli została złożona wystarczająca ilość głosów +- `[0,i,K,V]`, aby zarejestrować propozycję z indeksem `i` w celu zmiany adresu w indeksie pamięci `K` na wartość `V` +- `[1,i]`, aby zarejestrować głos za propozycją `i` +- `[2,i]`, aby sfinalizować propozycję `i`, jeśli oddano wystarczającą liczbę głosów -Umowa zawierałaby wówczas klauzule dla każdego z nich. Przechowuje zapis wszystkich otwartych zmian pamięci, wraz z listą osób, na które zagłosowały. Miałaby również listę wszystkich członków. Gdy jakakolwiek zmiana pamięci dostanie się do dwóch trzecich głosujących na nią członków, finalizacja transakcji może wykonać zmianę. Bardziej zaawansowany szkielet miałby również wbudowaną możliwość głosowania na funkcje takie jak wysyłanie transakcji, dodawanie członków i usuwanie członków, a nawet może przewidywać dla [Płynnej Demokracji](https://wikipedia.org/wiki/Delegative_democracy)- delegacji (np. każdy może przypisać kogoś do głosowania, i przypisanie jest translityczne, więc jeśli A przypisuje B i B przypisuje C wtedy C określa głos A). Ten projekt pozwoliłby DAO na rozwój organiczny jako społeczności zdecentralizowanej, umożliwienie ludziom w końcu delegowania zadania filtrowania, kto jest członkiem specjalistów, chociaż w odróżnieniu od „obecnego systemu” specjaliści mogą z łatwością wyskakać i z czasem przebywać w sytuacji, gdy indywidualni członkowie społeczności zmieniają swoje dostosowania. +Kontrakt miałby następnie klauzule dla każdego z tych przypadków. Utrzymywałby zapis wszystkich otwartych zmian magazynu, wraz z listą tych, którzy za nimi zagłosowali. Miałby również listę wszystkich członków. Gdyby jakakolwiek zmiana magazynu osiągnęła poparcie dwóch trzecich członków, transakcja finalizująca, mogłaby wykonać tę zmianę. Bardziej zaawansowany szkielet kontraktu zawierałby również wbudowaną możliwość głosowania nad funkcjami takimi jak wysyłanie transakcji, dodawanie członków i usuwanie członków, a może nawet mógłby zapewniać oddelegowywanie głosów w stylu [płynnej demokracji](https://wikipedia.org/wiki/Liquid_democracy) (tj. każdy może przypisać komuś innemu prawo do głosowania w swoim imieniu, a przypisanie jest przechodnie, więc jeśli A przypisze B, a B przypisze C, to C decyduje o głosie A). Ten projekt pozwoliłby DAO rozwijać się organicznie jako zdecentralizowana społeczność, umożliwiając ludziom ostatecznie delegować zadanie filtrowania, kto jest członkiem, specjalistom, chociaż w przeciwieństwie do „obecnego systemu” specjaliści mogą łatwo pojawiać się i znikać z czasem, gdy poszczególni członkowie społeczności zmieniają swoje nastawienie. -Alternatywnym modelem jest zdecentralizowana korporacja, gdzie każdy rachunek może mieć zero lub więcej akcji, a dwie trzecie akcji jest zobowiązane do podjęcia decyzji. Kompletny szkielet obejmowałby funkcje zarządzania aktywami, możliwość złożenia oferty kupna lub sprzedaży akcji, oraz zdolność przyjmowania ofert (najlepiej z mechanizmem dopasowania zleceń w ramach umowy). Delegacja istniałaby również w stylu płynnej demokracji, generalizując koncepcję rady dyrektorów. +Alternatywnym modelem jest zdecentralizowana korporacja, w której każde konto może mieć zero lub więcej udziałów, a do podjęcia decyzji wymagane jest poparcie dwóch trzecich udziałów. Kompletny szkielet obejmowałby funkcję zarządzania aktywami, możliwość składania ofert kupna lub sprzedaży udziałów oraz możliwość akceptowania ofert (najlepiej z mechanizmem wewnątrz kontraktu do dopasowywania zamówień). Delegowanie istniałoby również w stylu płynnej demokracji, uogólniając koncepcję „zarządu”. ### Dalsze zastosowania {#further-applications} -**1. Portfele oszczędzające**. Załóżmy, że Alice chce zabezpieczyć swoje fundusze, ale obawia się, że straci lub ktoś zhakuje swój klucz prywatny. Wstawia ether w kontrakt z Bob, bankiem, w następujący sposób: +**1. Portfele oszczędnościowe**. Załóżmy, że Alice chce zabezpieczyć swoje fundusze, ale obawia się, że zgubi lub ktoś zhakuje jej klucz prywatny. Wkłada ether do kontraktu z Bobem, bankiem, w następujący sposób: -- Sama Alice może wypłacić maksymalnie 1% środków dziennie. -- Tylko Bob może wypłacić maksymalnie 1% środków dziennie, ale Alice ma możliwość dokonania transakcji z jej kluczem wyłączającym tę zdolność. -- Alice i Bob razem mogą wycofać wszystko. +- Alice może sama wypłacić maksymalnie 1% środków dziennie. +- Bob może sam wypłacić maksymalnie 1% środków dziennie, ale Alice ma możliwość dokonania transakcji swoim kluczem, która wyłącza tę możliwość. +- Alice i Bob razem mogą wypłacić wszystko. -Zwykle 1% dziennie jest wystarczające dla Alice i jeśli Alice chce wycofać więcej może skontaktować się z Bobem w celu uzyskania pomocy. Jeśli klucz Alice zostanie zhakowany, biegnie do Boba, aby przenieść środki do nowego kontraktu. Jeśli straci swój klucz, Bob otrzyma ostatecznie środki. Jeśli Bob okaże się złośliwy, Alice może utracić możliwość wypłacenia środków. +Zwykle 1% dziennie wystarcza Alice, a jeśli Alice chce wypłacić więcej, może skontaktować się z Bobem, aby jej pomógł. Jeśli klucz Alice zostanie zhakowany, biegnie do Boba, aby przenieść środku do nowego kontraktu. Jeśli Alice zgubi swój klucz, Bob po pewnym czasie wypłaci wszystkie środki. Jeśli Bob okaże się nieuczciwy, Alice może wyłączyć jego możliwość wypłacania środków. -**2. Ubezpieczenie upraw**. Można łatwo stworzyć kontrakt pochodny poprzez wykorzystanie źródła danych pogodowych zamiast indeksu ceny. Jeśli rolnik z Iowa kupi instrument pochodny, który się opłaca odwrotnie w oparciu o opady w stanie Iowa, to jeśli jest susza, rolnik automatycznie otrzyma pieniądze, a jeśli będzie wystarczająco dużo deszczu, rolnik będzie szczęśliwy, ponieważ ich plony będą dobrze sobie radzić. Można go rozszerzyć na ogólne ubezpieczenie od klęsk żywiołowych. +**2. Ubezpieczenie upraw**. Można łatwo stworzyć kontrakt derywatu finansowego, wykorzystując kanał danych pogody zamiast jakiegokolwiek indeksu cenowego. Jeśli rolnik w stanie Iowa zakupi derywat, które wypłaca środki odwrotnie proporcjonalnie do ilości opadów w stanie Iowa, to w przypadku suszy rolnik automatycznie otrzyma pieniądze, a jeśli będzie wystarczająco dużo deszczu, rolnik będzie zadowolony, ponieważ jego plony będą się dobrze rozwijać. Można to rozszerzyć na ubezpieczenia od klęsk żywiołowych. -**3. Zdecentralizowany kanał danych**. W przypadku umów finansowych na różnica, faktycznie może być możliwa decentralizacja strumienia danych za pośrednictwem protokołu o nazwie [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/). SchellingCoin działa zasadniczo w następujący sposób: N stron wstawionych do systemu wartości danego odniesienia (np. cena ETH/USD), wartości są sortowane, a każdy między 25. a 75. percentylem otrzymuje jeden token jako nagrodę. Każdy ma motywację do udzielenia odpowiedzi, która wszyscy inni zapewnią, i jedyną wartością, na którą wiele graczy może realistycznie się zgodzić, jest oczywisty domyślny: prawda. Tworzy to zdecentralizowany protokół, który teoretycznie może dostarczyć dowolną liczbę wartości, włączając w to cenę ETH/USD, temperaturę w Berlinie lub nawet wynik konkretnego twardego obliczenia. +**3. Zdecentralizowany kanał danych**. W przypadku finansowych kontraktów różnic kursowych możliwe jest zdecentralizowanie kanału danych za pomocą protokołu o nazwie „[SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/)”. SchellingCoin zasadniczo działa w następujący sposób: N stron wprowadza do systemu wartość danego parametru (np. cenę ETH/USD), wartości te są sortowane, a każdy, kto znajduje się pomiędzy 25. a 75. percentylem, otrzymuje w nagrodę jeden token. Każdy ma motywację do udzielania odpowiedzi, której udzielą wszyscy inni, a jedyną wartością, co do której duża liczba graczy może realistycznie się zgodzić, jest oczywista wartość domyślna: prawda. Tworzy to zdecentralizowany protokół, który teoretycznie może dostarczyć dowolną liczbę wartości, wliczając w to cenę ETH/USD, temperaturę w Berlinie, a nawet wynik konkretnego trudnego obliczenia. -**4. Inteligentna escrow z multipodpisem**. Bitcoin pozwala na podpisywanie umów transakcji, na które na przykład trzy z pięciu kluczy mogą wydać środki. Ethereum pozwala na bardziej szczegółowość; na przykład czterech na pięć może wydawać wszystko, trzy na pięć mogą wydać do 10% na dobę, a dwa na pięć mogą wydać do 0. % dziennie. Dodatkowo, Ethereum multisig jest asynchroniczny - dwie strony mogą zarejestrować swoje podpisy w blockchain w różnych momentach, a ostatni podpis automatycznie wyśle transakcję. +**4. Inteligentny depozyt wielopodpisowy**. Bitcoin pozwala na wielopodpisowe kontrakty transakcyjne, w których na przykład trzy z pięciu kluczy mogą wydać środki. Ethereum pozwala na większą szczegółowość; na przykład cztery z pięciu kluczy mogą wydawać wszystko, trzy z pięciu mogą wydać do 10% dziennie, a dwa z pięciu mogą wydać do 0,5% dziennie. Co więcej, wielopodpis w Ethereum jest asynchroniczny — dwie strony mogą zarejestrować swoje podpisy na blockchainie w różnym czasie, a ostatni podpis automatycznie wyśle transakcję. -**5. Chmura obliczeniowa**. Technologia EVM może być również używana do tworzenia weryfikowalnego środowiska obliczeniowego, pozwalając użytkownikom na zwrócenie się do innych o przeprowadzenie obliczeń, a następnie opcjonalnie poproś o dowody na to, że obliczenia w wybranych losowo punktach kontrolnych zostały wykonane poprawnie. Pozwala to na stworzenie rynku przetwarzania w chmurze, na którym każdy użytkownik może uczestniczyć za pomocą komputera stacjonarnego, laptopa lub specjalnego serwera, i kontrola punktowa wraz z depozytami zabezpieczającymi może być wykorzystana w celu upewnienia się, że system jest wiarygodny (tj. węzły nie mogą dochodowo oszukiwać). Chociaż taki system może nie być odpowiedni dla wszystkich zadań; zadań, które wymagają wysokiego poziomu komunikacji międzyprocesowej, na przykład nie można łatwo wykonać na dużej chmurze węzłów. Inne zadania są jednak znacznie łatwiejsze do równoległe; projekty takie jak SETI@home, folding@home i genetyczne algorytmy mogą być z łatwością zaimplementowane na tej platformie. +**5. Chmura obliczeniowa**. Technologia EVM może być również wykorzystywana do tworzenia weryfikowalnego środowiska obliczeniowego, pozwalając użytkownikom zlecać innym wykonania obliczeń, a następnie opcjonalnie żądać dowodów, że obliczenia w niektórych losowo wybranych punktach kontrolnych zostały wykonane poprawnie. Pozwala to na stworzenie rynku chmur obliczeniowych, w którym każdy użytkownik może uczestniczyć, korzystając ze swojego komputera stacjonarnego, laptopa lub wyspecjalizowanego serwera, a wyrywkowa kontrola oraz depozyty zabezpieczające mogą zapewnić, że system jest godny zaufania (tj. węzły nie mogą oszukiwać z zyskiem). Chociaż taki system może nie być odpowiedni dla wszystkich zadań; na przykład zadania wymagające wysokiego poziomu komunikacji międzyprocesowej, nie mogą być łatwo realizowane na dużej chmurze węzłów. Inne zadania są jednak znacznie łatwiejsze do zrównoleglenia; projekty takie jak SETI@home, folding@home i algorytmy genetyczne mogą być z łatwością zaimplementowane na takiej platformie. -**6. Gry typu peer-to-peer**. Dowolna liczba protokołów gier hazardowych typu peer-to-peer, takich jak Frank Stajano i Richard Clayton [Cyberdice](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf), może być zaimplementowane w blockchainu Ethereum. Najprostszy protokół gier to po prostu kontrakt na różnicę w następnym bloku hash, i bardziej zaawansowane protokoły można z nich opracować, tworząc usługi w zakresie gier hazardowych z opłatami niemal zerowymi, które nie mają możliwości oszukania. +**6.** Hazard peer-to-peer\*\*. Dowolna liczba protokołów hazardowych peer-to-peer, takich jak [Cyberdice](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf) Franka Stajano i Richarda Claytona, może zostać zaimplementowana na blockchainie Ethereum. Najprostszym protokołem hazardowym jest właściwie kontrakt różnicy kursowej oparty na hashu następnego bloku, a bardziej zaawansowane protokoły mogą być tworzone na tej podstawie, tworzą usługi hazardowe z niemal zerowymi opłatami, które nie mają możliwości oszukiwania. -**7. Rynki prognostyczne**. Pod warunkiem, że wyścig lub SchellingCoin, rynki prognoz są również łatwe do wdrożenia, rynki prognozowania wraz z SchellingCoin mogą okazać się pierwszym głównym punktem zastosowania [futarchii](http://hanson.gmu.edu/futarchy.html) jako protokołu zarządzania zdecentralizowanymi organizacjami. +**7.** Rynki prognostyczne\*\*. Przy zastosowaniu wyroczni lub SchellingCoin rynki prognostyczne są również łatwe do zaimplementowania, a rynki prognostyczne połączone z SchellingCoin mogą stać się pierwszym szeroko stosowanym zastosowaniem [futarchii](https://mason.gmu.edu/~rhanson/futarchy.html) jako protokołu zarządzania dla zdecentralizowanych organizacji. -**8. Zdecentralizowane rynki**w łańcuchu przy użyciu systemu tożsamości i reputacji jako bazy. +**8.** Zdecentralizowane rynki on-chain\*\*, wykorzystujące system tożsamości i reputacji jako podstawę. -## Różne obszary i obawy {#miscellanea-and-concerns} +## Różne i obawy {#miscellanea-and-concerns} -### Zmodyfikowane wdrożenie GHOST {#modified-ghost-implementation} +### Zmodyfikowana implementacja GHOST {#modified-ghost-implementation} -Protokół GHOST to innowacja po raz pierwszy wprowadzony przez Yonatana Sompolinsky'ego i Aviva Zohara w [grudniu 2013](https://eprint.iacr.org/2013/881.pdf). Motywacja uzasadniająca wprowadzenie GHOST polega na tym, że blockchain z szybkim czasem potwierdzania cierpi z powodu zmniejszonego bezpieczeństwa ze względu na wysoką przeżywalność - ponieważ bloki potrzebują czasu pewien czas rozesłanie w sieci. Jeśli górnik A wydobywa blok, a następnie zdarzy się, że górnik B wydobędzie kolejny blok, zanim blok wydobycia A rozpropaguje się na B, blok górnika B zmarnuje się i nie przyczyni się do bezpieczeństwa sieci. Ponadto istnieje problem centralizacji: jeśli górnik A stanowi pulę wydobycia o 30% mocy hash, a B ma 10% mocy hash, Istnieje ryzyko wytworzenia przestarzałego bloku przez 70% czasu (ponieważ pozostałe 30% czasu A wyprodukował ostatni blok, a więc natychmiast uzyska dane kopalniane), podczas gdy B będzie ryzykował wytworzenia przestarzałego bloku przez 90% czasu. Zatem, jeśli interwał bloku jest wystarczająco krótki, aby przestarzała szybkość była wysoka, Będzie znacznie bardziej efektywny ze względu na jego wielkość. Z tymi dwoma objawami łącznie. blockchain, które szybko produkują bloki, bardzo prawdopodobne jest, że doprowadzi do jednej puli wydobywczej posiadającej wystarczająco dużo energii sieciowej, aby faktycznie sprawować kontrolę nad procesem wydobywania. +Protokół „Greedy Heaviest Observed Subtree” (GHOST) to innowacja po raz pierwszy wprowadzona przez Yonatana Sompolinsky'ego i Aviva Zohara w [grudniu 2013 roku](https://eprint.iacr.org/2013/881.pdf). Motywacją do stworzenia GHOST jest to, że blockchainy z szybkim czasem potwierdzenia cierpią obecnie na zmniejszonego bezpieczeństwa spowodowanego wysokim wskaźnikiem nieaktualności — ponieważ bloki potrzebują pewnego czasu, aby rozprzestrzenić się w sieci, jeśli górnik A wykopie blok, a następnie górnik B wykopie inny blok, zanim blok górnika A rozprzestrzeni się do B, blok górnika B zmarnuje się i nie przyczyni do bezpieczeństwa sieci. Ponadto istnieje kwestia centralizacji: jeśli górnik A jest pulą wydobywczą z 30% mocy obliczeniowej (hashpower), a B ma 10% mocy obliczeniowej, A będzie miał ryzyko stworzenia bloku nieaktualnego w 70% przypadków (ponieważ w pozostałych 30% przypadków to A wyprodukował ostatni blok, a więc otrzyma dane wydobywcze natychmiast), podczas gdy B będzie miał ryzyko stworzenia bloku nieaktualnego w 90% przypadków. Zatem, jeśli interwał między blokami jest wystarczająco krótki, aby wskaźnik nieaktualnych bloków był wysoki, A będzie znacznie bardziej wydajny po prostu ze względu na swój rozmiar. W połączeniu z tymi dwoma efektami blockchainy, które szybko tworzą bloki, prawdopodobnie doprowadzą do sytuacji, w której jedna pula wydobywcza będzie miała wystarczająco dużą część mocy obliczeniowej sieci, aby de facto kontrolować proces wydobywania. -Jak opisali Sompolinsky i Zohar, GHOST rozwiązuje pierwszy problem traty bezpieczeństwa sieci poprzez uwzględnienie przestarzałych bloków w obliczeniach , który łańcuch jest „najdłuższy”; to znaczy nie tylko rodzici kolejni przodkowie bloku, ale także starsi potomkowie bloku (w żargonie Ethereum „wujkowie”) zostają dodani do wyliczenia, który blok jest zabezpieczony nawiększą łączną liczbą proof of work. Aby rozwiązać drugą kwestię błędu centralizacji, wychodzimy poza protokół opisany przez Sompolinskiego i Zohara oraz zapewniamy nagrody za przestarzałe bloki: przestarzały blok otrzymuje 87,5 % nagrody bazowej nagród, a siostrzeniec, który zawiera przestarzały blok, otrzymuje pozostałe 12,5%. Opłaty transakcyjne nie są jednak przyznawane wujom. +Jak opisali Sompolinsky i Zohar, GHOST rozwiązuje pierwszy kwestię utraty bezpieczeństwa sieci poprzez uwzględnianie nieaktualnych bloków do obliczeń, który łańcuch jest „najdłuższy”; znaczy to, że nie tylko rodzic i dalsi przodkowie bloku, ale także nieaktualni potomkowie przodka bloku (w żargonie Ethereum „wujkowie”) są dodawani do obliczeń, który blok ma największy całkowity proof-of-work. Aby rozwiązać drugą kwestię stronniczości centralizacji, wykraczamy poza protokół opisany przez Sompolinsky'ego i Zohara, i zapewniamy nagrody za blok dla bloków nieaktualnych: nieaktualny blok otrzymuje 87,5% swojej nagrody podstawowej, a siostrzeniec, który uwzględni nieaktualny blok, otrzyma pozostałe 12,5%. Opłaty transakcyjne nie są jednak przyznawane wujkom. -Ethereum wdraża uproszczoną wersję GHOST, która obniża się tylko o 7 poziomów. W szczególności definiuje się je w następujący sposób: +Ethereum implementuje uproszczoną wersję GHOST, która obejmuje tylko siedem poziomów. Konkretnie jest to zdefiniowane w następujący sposób: -- Blok musi określać nadrzędny i musi określać 0 lub więcej wujków -- Wujek zawarty w bloku `B` musi mieć następujące właściwości: -- Musi być bezpośrednim dzieckiem `k`-th generator `B`, gdzie `2 <= k <= 7`. -- Nie może być przodkiem `B` -- Wujek musi być prawidłowym nagłówkiem bloku, ale nie musi być wcześniej zweryfikowanym lub nawet poprawnym blokiem -- Wujek musi różnić się od wszystkich wujków zawartych w poprzednich blokach i wszystkich innych wujków zawartych w tym samym bloku (brak podwójnego włączenia) -- Za każdego wujka `U` w bloku `B`, górnik `B` otrzymuje dodatkowe 3,125% dodanych do swojej nagrody z bazy monet, a górnik z U otrzymuje 93,75% standardowej nagrody z bazy monet. +- Blok musi określać rodzica i musi określać 0 lub więcej wujków +- Wujek uwzględniony w bloku B musi mieć następujące właściwości: + - Musi być bezpośrednim dzieckiem k-tego pokolenia przodka B, gdzie `2 <= k <= 7`. + - Nie może być przodkiem B + - Wujek musi być prawidłowym nagłówkiem bloku, ale nie musi być wcześniej zweryfikowanym ani nawet prawidłowym blokiem + - Wujek musi różnić się od wszystkich wujków uwzględnionych w poprzednich blokach praz od wszystkich innych wujków uwzględnionych w tym samym bloku (brak podwójnego uwzględnienia) +- Za każdego wujka U w bloku B, górnik B otrzymuje dodatkowe 3,125% do swojej podstawowej nagrody, a górnik U otrzymuje 93,75% podstawowej nagrody. -Ta ograniczona wersja GHOST, z wujkami włączanymi tylko do 7 generacji, była używana z dwóch powodów. Po pierwsze, nieograniczony GHOSTmógłby uwzględnić zbyt wiele komplikacji w obliczeniach, którzy wujkowie dla danego bloku są ważni. Po drugie, nieograniczony GHOST z rekompensatą używaną w Ethereum usuwa zachętę dla górnika do wydobywania w głównym łańcuchu, a nie w łańcuchu publicznego atakującego. +Ta ograniczona wersja GHOST, z wujkami uwzględnianymi tylko do 7 pokoleń wstecz, została wykorzystana z dwóch powodów. Po pierwsze, nieograniczony GHOST wprowadziłby zbyt wiele komplikacji do obliczeń dotyczących tego, którzy wujkowie dla danego bloku są prawidłowi. Po drugie, nieograniczony GHOST z rekompensatą, jaką stosuje Ethereum, usuwa zachętę dla górnika do kopania w głównym łańcuchu, a nie w łańcuchu publicznego atakującego. ### Opłaty {#fees} -Ponieważ każda transakcja publikowana w blockchain nakłada na sieć koszt pobrania i zweryfikowania, istnieje potrzeba mechanizmu regulacyjnego, zazwyczaj obejmującego opłaty transakcyjne, aby zapobiec nadużyciom. Domyślnym podejściem, stosowanym w Bitcoini, jest wprowadzenie czysto dobrowolnych opłat, polegając na tym, że górnicy będą działać jako strażnicy i ustalać dynamiczne minima. Ta metoda została przyjęta bardzo pozytywnie w społeczności Bitcoin, w szczególności dlatego, że jest ona „oparta na rynku”, umożliwiając, by podaż i popyu między górnikami a nadawcami transakcji określała ceny. Problem z tym rozumowaniem polega jednak na tym, że przetwarzanie transakcji nie jest rynkiem; chociaż intuicyjnie atrakcyjne jest konstruowanie przetwarzania transakcji jako usługi, którą górnik oferuje nadawcy, w rzeczywistości każda transakcja, którą górnik uwzględnia, będzie musiała być przetwarzana przez każdy węzeł w sieci, więc ogromną większość kosztów przetwarzania transakcji ponosi strona trzecia, a nie górnik, który podejmuje decyzję o uwzględnieniu. Dlatego bardzo prawdopodobne jest wystąpienie problemów typu „tragedia wspólnego pastwiska”. +Ponieważ każda transakcja opublikowana w blockchainie nakłada na sieć koszt związany z koniecznością pobrania jej i zweryfikowania, konieczne jest zastosowanie jakiegoś mechanizmu regulacyjnego, zazwyczaj obejmującego opłaty transakcyjne, aby zapobiec nadużyciom. Domyślnym podejściem, stosowanym w Bitcoinie, jest posiadanie całkowicie dobrowolnych opłat, polegających na tym, że górnicy działają jako strażnicy i ustalają dynamiczne minima. Podejście to zostało bardzo przychylnie przyjęte w społeczności Bitcoina, szczególnie dlatego, że jest „oparte na rynku”, pozwalając, by podaż i popyt pomiędzy górnikami a nadawcami transakcji określały cenę. Problem z tym rozumowaniem polega jednak na tym, że przetwarzanie transakcji nie jest rynkiem; chociaż intuicyjnie atrakcyjne jest interpretowanie przetwarzania transakcji jako usługi, którą górnik oferuje nadawcy, w rzeczywistości każda transakcja uwzględniona przez górnika, będzie musiała zostać przetworzona przez każdy węzeł w sieci, więc zdecydowana większość kosztów przetwarzania transakcji jest ponoszona przez strony trzecie, a nie przez górnika, który podejmuje decyzję, czy ją uwzględnić czy nie. W związku z tym bardzo prawdopodobne jest wystąpienie problemów „tragedii wspólnego pastwiska”. -Jak się jednak okazuje, ta wada mechanizmu rynkowego, po przyjęciu konkretnego, nieprecyzyjnego założenia upraszczającego, magicznie się usuwa. Argumentacja jest następująca. Załóżmy, że: +Jednakże, jak się okazuje, ta wada w mechanizmie opartym na rynku, przy określonym niedokładnym założeniu upraszczającym, magicznie się niweluje. Argumentacja jest następująca. Załóżmy, że: -1. Transakcja prowadzi do operacji `k`, oferującej nagrodę `kR` każdemu górnikowi, który tę transakcję uwzględnia, gdzie `R` jest ustawiony przez nadawcę, a `k` i `R` są (z grubsza) wcześniej widoczne dla górnika. -2. Operacja ma koszt przetwarzania `C` dla każdego węzła (tj. wszystkie węzły mają taką samą wydajność) -3. Jest `N` węzłów kopalnych, każdy z nich ma dokładnie taką samą moc przetwarzania (tj. `1/N` razem) -4. Nie ma żadnych pełnych węzłów niekopalnych. +1. Transakcja prowadzi do `k` operacji, oferując nagrodę `kR` każdemu górnikowi, który tę transakcję uwzględnia, gdzie `R` jest ustawiony przez nadawcę, a `k` i `R` są (z grubsza) wcześniej widoczne dla górnika. +2. Operacja ma koszt przetwarzania `C` dla każdego węzła (tj. wszystkie węzły mają taką samą wydajność) +3. Jest N węzłów wydobywczych, każdy z nich ma dokładnie taką samą moc przetwarzania (tj. `1/N` całości) +4. Nie ma żadnych pełnych węzłów niekopalnych. -Górnik byłby skłonny przetworzyć transakcję, jeśli oczekiwana nagroda jest wyższa niż koszt. Tak więc oczekiwana nagroda to `kR/N`, ponieważ górnik ma `1/N` szans na przetworzenie następnego bloku, a koszt przetwarzania dla górnika wynosi po prostu `kC`. A zatem górnicy będą uwzględniać transakcje, w których `kR/N > kC` lub `R > NC`. Zauważ, że `R` jest opłatą na operację dostarczoną przez nadawcę, a zatem jest niższą wartością korzyści, jakie nadawca uzyskuje transakcji, i `NC` to koszt dla całej sieci razem z przetwarzaniem operacji. W związku z tym górnicy mają motywację do uwzględniania tylko tych transakcji, dla których całkowita korzyść użytkowa przewyższa koszt. +Górnik byłby skłonny przetworzyć transakcję, jeśli oczekiwana nagroda będzie większa niż koszt. Zatem oczekiwana nagroda to `kR/N`, ponieważ górnik ma `1/N` szansy na przetworzenie kolejnego bloku, a koszt przetwarzania dla górnika wynosi po prostu `kC`. W związku z tym górnicy będą uwzględniać transakcje, gdzie `kR/N > kC` lub `R > NC`. Należy zauważyć, że `R` jest opłatą za operację dostarczoną przez nadawcę, a zatem jest dolną granicą korzyści, jaką nadawca czerpie z transakcji, a `NC` jest kosztem przetwarzania operacji dla całej sieci. W związku z tym górnicy mają motywację do uwzględniania tylko tych transakcji, dla których całkowita korzyść użytkowa przewyższa koszt. -Istnieje jednak kilka istotnych odstępstw od tych założeń w rzeczywistości: +W rzeczywistości istnieje jednak kilka istotnych odstępstw od tych założeń: -1. Górnik ponosi wyższe koszty przetwarzania transakcji niż innych weryfikujących węzłów, ponieważ dodatkowy czas weryfikacji opóźnia propagację bloku i tym samym zwiększa szansę, że blok stanie się przestarzały. -2. Istnieją pełne węzły niekopalne. -3. Dystrybucja energii wydobywczeh może w praktyce stać się radykalnie nieegalitarna. -4. Spekulanci, wrogowie polityczni i maszyny, których funkcja użyteczności obejmuje wyrządzanie szkód w sieci, już istnieją, i mogą sprytnie tworzyć kontrakty, w których ich koszt jest znacznie niższy niż koszt zapłacony przez inne weryfikujące węzły. +1. Górnik ponosi wyższe koszty przetwarzania transakcji niż innych weryfikujących węzłów, ponieważ dodatkowy czas weryfikacji opóźnia propagację bloku i tym samym zwiększa szansę, że blok stanie się przestarzały. +2. Istnieją pełne węzły niewydobywające. +3. Dystrybucja energii wydobywczeh może w praktyce stać się radykalnie nieegalitarna. +4. Spekulanci, wrogowie polityczni i maszyny, których funkcja użyteczności obejmuje wyrządzanie szkód w sieci, już istnieją, i mogą sprytnie tworzyć kontrakty, w których ich koszt jest znacznie niższy niż koszt zapłacony przez inne weryfikujące węzły. -(1) daje górnikowi tendencję do uwzględniania mniejszej liczby transakcji, a (2) wzrasta `NC`; w związku z tym te dwa efekty co najmniej częściowo znoszą się nawzajem [Jak?](https://web.archive.org/web/20250427212319/https://github.com/ethereum/wiki/issues/447#issuecomment-316972260#issuecomment-316972260) (3) i (4) są głównymi problemami; aby je rozwiązać, tworzymy zmienną pokrywę: żaden blok nie może mieć więcej operacji niż `BLK_LIMIT_FACTOR` razy długoterminowa wykładnicza średnia ruchoma. Konkretnie: +(1) zapewnia tendencję górnika do włączania mniejszej liczby transakcji, oraz +(2) zwiększa `NC`; stąd te dwa efekty przynajmniej częściowo +się znoszą +wzajemnie.[Jak?](https://web.archive.org/web/20250427212319/https://github.com/ethereum/wiki/issues/447#issuecomment-316972260#issuecomment-316972260) +(3) i (4) to główne problemy; aby je rozwiązać, po prostu wprowadzamy +pływający limit: żaden blok nie może mieć więcej operacji niż +`BLK_LIMIT_FACTOR` razy długoterminowa wykładnicza średnia krocząca. +Konkretnie: - blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) + - floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR) +```js +blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) + +floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR) +``` -`BLK_LIMIT_FACTOR` i `EMA_FACTOR` to stałe, które zostaną na razie ustawione na 65536 i 1,5, ale prawdopodobnie zostaną zmienione po dalszej analizie. +`BLK_LIMIT_FACTOR` i `EMA_FACTOR` to stałe, które tymczasowo zostaną ustawione na 65536 i 1,5, ale prawdopodobnie zostaną one zmienione po dalszej analizie. -Istnieje kolejny czynnik zniechęcający do dużych rozmiarów bloków w Bitcoin: propagacja dużych bloków trwa dłużej i dlatego występuje większe prawdopodobieństwo, że staną się przestarzałe. W Ethereum bloki o wysokim zużyciu gazu mogą również wymagać więcej czasu na propagację, zarówno dlatego, że są fizycznie większe, jak i dlatego, że przetwarzanie przejścia stanu transakcji do walidacji trwa dłużej. Ten czynnik zniechęcający do opóźnień jest istotnym czynnikiem w Bitcoinie, ale mniej istotnym w Ethereum ze względu na protokół GHOST; dlatego poleganie na regulowanych limitach bloków zapewnia bardziej stabilną podstawę. +Istnieje jeszcze jeden czynnik zniechęcający do dużych rozmiarów bloków w Bitcoinie: propagacja dużych bloków trwa dłużej, a zatem istnieje większe prawdopodobieństwo, że staną się one nieaktualne. W Ethereum, bloki zużywające dużo gazu mogą również wymagać więcej czasu na propagację, zarówno dlatego, że są fizycznie większe, jak i dlatego, że wymagają więcej czasu na przetworzenie przejść stanu transakcji w celu ich walidacji. To zniechęcające opóźnienie jest istotnym czynnikiem w Bitcoinie, ale w mniejszym stopniu w Ethereum ze względu na protokół GHOST; dlatego też poleganie na regulowanych limitach bloków zapewnia bardziej stabilną podstawę. -### Obliczanie i kompletność w sensie Turinga {#computation-and-turing-completeness} +### Obliczenia i kompletność w sensie Turinga {#computation-and-turing-completeness} -Ważną informacją jest to, że maszyna wirtualna Ethereum jest kompletna w sensie Turinga; oznacza to, że kod EVM może kodować każde obliczenie które może zostać przeprowadzone, w tym nieskończone pętle. Kod EVM umożliwia zapętlenie na dwa sposoby. Po pierwsze, istnieje instrukcja `JUMP`, która pozwala programowi wrócić do poprzedniego miejsca w kodzie, i instrukcje `JUMPI` przeskoku warunkowego, dopuszczanie wyrażeń takich jak `while x < 27: x = x * 2`. Po drugie, kontrakty mogą wywoływać inne kontrakty, potencjalnie umożliwiając zapętlenie poprzez rekurencję. To naturalnie prowadzi do problemu: czy złośliwi użytkownicy mogą zasadniczo wyłączyć górników i pełne węzły, zmuszając ich do wejścia w nieskończoną pętlę? Kwestia ta pojawia się z powodu problemu w informatyce znanego jako problem zatrzymania: nie ma sposobu, aby powiedzieć, w ogólnym przypadku, czy dany program kiedykolwiek się zatrzyma. +Ważną informacją jest to, że maszyna wirtualna Ethereum jest kompletna w sensie Turinga; oznacza to, że kod EVM może kodować dowolne obliczenia, które można sobie wyobrazić, w tym nieskończone pętle. Kod EVM umożliwia wykonywanie pętli na dwa sposoby. Po pierwsze, istnieje instrukcja `JUMP`, która pozwala programowi przeskoczyć z powrotem do poprzedniego miejsca w kodzie, oraz instrukcja `JUMPI` do skoków warunkowych, pozwalająca na instrukcje takie jak `while x < 27: x = x * 2`. Po drugie, kontrakty mogą wywoływać inne kontrakty, co potencjalnie pozwala na zapętlenie poprzez rekurencję. To naturalnie prowadzi do problemu: czy złośliwi użytkownicy mogą zasadniczo wyłączyć górników i pełne węzły zmuszając je do wejścia w nieskończoną pętlę? Kwestia ta pojawia się z powodu problemu znanego w informatyce jako problem stopu: nie ma sposobu, aby powiedzieć, w ogólnym przypadku, czy dany program kiedykolwiek się zatrzyma. -Jak opisano w sekcji dotyczącej zmiany stanu, nasze rozwiązanie działa w ten sposób, że wymagamy od transakcji określenia maksymalnej liczby kroków obliczeniowych, które może ona wykonać, a jeśli wykonanie trwa dłużej, obliczenia są przerywane, ale opłaty są nadal uiszczane. Komunikaty działają w ten sam sposób. Aby pokazać motywację uzasadniającą nasze rozwiązanie, weźmy pod uwagę następujące przykłady: +Jak opisano w sekcji dotyczącej przejścia stanu, nasze rozwiązanie polega na wymaganiu, aby transakcja ustaliła maksymalną liczbę kroków obliczeniowych, które mogą zostać wykonane, a jeśli wykonanie przekroczy ten limit, obliczenia są cofane, ale opłaty są nadal uiszczane. Wiadomości działają w ten sam sposób. Aby pokazać motywację stojącą za naszym rozwiązaniem, rozważmy następujące przykłady: -- Atakujący tworzy kontrakt, który uruchamia nieskończoną pętlę, a następnie wysyła transakcję aktywującą tę pętlę do górnika. Górnik przetwarza transakcję, uruchamia nieskończoną pętlę i czeka, aż skończy się gaz. Nawet jeśli w trakcie wykonywania transakcji zabraknie paliwa i zatrzyma się ona w połowie, transakcja jest nadal ważna, a górnik nadal żąda od atakującego opłaty za każdy krok obliczeniowy. -- Atakujący tworzy bardzo długą nieskończoną pętlę z zamiarem zmuszenia górnika do kontynuowania obliczeń przez tak długi czas, że do czasu zakończenia obliczeń pojawi się jeszcze kilka bloków i nie będzie możliwe, aby górnik uwzględnił transakcję, aby zażądać opłaty. Niemniej jednak napastnik będzie musiał przesłać wartość `STARTGAS`, ograniczając liczbę kroków obliczeniowych wykonania, więc górnik dowie się wcześniej, że obliczenie będzie wymagać zbyt dużej liczby kroków. -- Atakujący widzi kontrakt z kodem w jakiejś formie jak `send(A,contract.storage[A]); contract.storage[A] = 0`, i wysyła transakcję z wystarczającą ilością gazu, aby wykonać pierwszy krok, ale nie drugi (tzn. dokonać wypłaty, ale nie pozwolić na zmniejszenie salda). Autor kontraktu nie musi się martwić o ochronę przed takimi atakami, ponieważ jeśli wykonanie kontraktu zatrzyma się w połowie zmian, zostaną one cofnięte. -- Kontrakt finansowy działa poprzez przyjęcie mediany dziewięciu zastrzeżonych kanałów danych w celu zminimalizowania ryzyka. Atakujący przejmuje jeden z kanałów danych, który jest zaprojektowany do modyfikowania za pomocą mechanizmu wywołania zmiennego adresu opisanego w sekcji dotyczącej DAO i konwertuje go do uruchomienia nieskończonej pętli, próbując w ten sposób wymusić wszelkie próby odzyskania środków z kontraktu finansowego do wyczerpania gazu. Jednak umowa finansowa może ustalić limit gazu na komunikacie, aby zapobiec temu problemowi. +- Atakujący tworzy kontrakt, który uruchamia nieskończoną pętlę, a następnie wysyła transakcję aktywującą tę pętlę do górnika. Górnik przetworzy transakcję, uruchamiając nieskończoną pętlę i poczeka, aż skończy się jej gaz. Nawet jeśli w trakcie wykonywania transakcji zabraknie gazu i zatrzyma się ona w połowie, to transakcja nadal jest prawidłowa, a górnik nadal pobiera opłatę od atakującego za każdy krok obliczeniowy. +- Atakujący tworzy bardzo długą nieskończoną pętlę z zamiarem zmuszenia górnika do obliczania przez tak długi czas, że zanim zakończy się obliczanie, wyjdzie kilka kolejnych bloków i górnik nie będzie mógł uwzględnić transakcji w celu pobrania opłaty. Atakujący będzie zobowiązany jednak do przesłania wartości dla `STARTGAS` ograniczającej liczbę kroków obliczeniowych, które może wykonać, więc górnik będzie wiedział z wyprzedzeniem, że obliczenia zajmą nadmiernie dużą liczbę kroków. +- Atakujący widzi kontrakt z kodem w formie `send(A,contract.storage[A]); contract.storage[A] = 0` i wysyła transakcję z wystarczającą ilością gazu, aby wykonać krok pierwszy, ale nie drugi (tj. dokonuje wypłaty, ale nie pozwala, aby saldo się zmniejszyło). Autor kontraktu nie musi martwić się o ochronę przed takimi atakami, ponieważ jeśli wykonanie zatrzyma się w połowie, zmiany zostaną cofnięte. +- Kontrakt finansowy działa, przyjmując medianę z dziewięciu zastrzeżonych kanałów danych w celu minimalizacji ryzyka. Atakujący przejmuje jeden z kanałów danych, który został zaprojektowany tak, aby można go było modyfikować za pomocą mechanizmu wywołania adresu zmiennej opisanego w sekcji o DAO, i przekształca go tak, aby działał w nieskończonej pętli, próbując w ten sposób zmusić wszelkie próby pobrania środków z kontraktu finansowego do wyczerpania gazu. Kontrakt finansowy może jednak ustawić limit gazu dla wiadomości, aby zapobiec temu problemowi. -Alternatywą dla kompletności transakcji jest niekompletność, gdzie `JUMP` i `JUMPI` nie istnieją i tylko jedna kopia każdego kontraktu może istnieć w danym momencie. W tym systemie opisany system opłat i niepewność dotycząca skuteczności naszego rozwiązania mogą nie być konieczne, ponieważ koszt wykonania kontraktu byłby ograniczony wielkością kontraktu. Ponadto, niekompletność w sensie Turinga nie jest nawet tak dużym ograniczeniem; ze wszystkich przykładów kontraktów, które wymyśliliśmy wewnętrznie, jak dotąd tylko jeden wymagał pętli, a nawet ta pętla mogła być usunięta przez wykonanie 26 powtórzeń jednowierszowego fragmentu kodu. Biorąc pod uwagę poważne następstwa kompletności w sensie Turinga i ograniczone korzyści, dlaczego nie ma po prostu języka Turinga niekompletnego w sensie Turinga? W rzeczywistości jednak niekompletność jest daleka od czystego rozwiązania problemu. Aby zobaczyć dlaczego, zastanów się nad następującymi kontraktami: +Alternatywą dla kompletności w sensie Turinga jest niekompletność w sensie Turinga, w której `JUMP` i `JUMPI` nie istnieją i tylko jedna kopia każdego kontraktu może istnieć w stosie wywołań w danym momencie. W tym systemie opisany system opłat i niepewność co do skuteczności naszego rozwiązania mogą nie być konieczne, ponieważ koszty wykonania kontraktu byłby ograniczony przez jego rozmiar. Co więcej, niekompletność Turinga nie jest nawet tak dużym ograniczeniem; spośród wszystkich przykładów kontraktów, które wewnętrznie wymyśliliśmy, tylko jeden wymagał pętli, a nawet tę pętlę można było usunąć, wykonując 26 powtórzeń jednej linii fragmentu kodu. Biorąc pod uwagę poważne implikacje kompletności Turinga i ograniczone korzyści, dlaczego po prostu nie mieć języka niekompletnego w sensie Turinga? W rzeczywistości jednak niekompletność Turinga daleka jest od prostszego rozwiązania problemu. Aby zobaczyć dlaczego, rozważmy następujące kontrakty: - C0: call(C1); call(C1); - C1: call(C2); call(C2); - C2: call(C3); call(C3); - ... - C49: call(C50); call(C50); - C50: (uruchom jeden krok programu i zapisz zmianę w pamięci) +```sh +C0: call(C1); call(C1); +C1: call(C2); call(C2); +C2: call(C3); call(C3); +... +C49: call(C50); call(C50); +C50: (uruchom jeden krok programu i zapisz zmianę w pamięci) +``` -Teraz wyślij transakcję do A. Zatem w 51 transakcjach mamy kontrakt, który zajmuje 250 kroków obliczeniowych. Górnicy mogliby spróbować wykryć takie bomby logiczne z wyprzedzeniem, utrzymując przy każdym kontrakcie wartość określającą maksymalną liczbę kroków obliczeniowych, jakie może on wykonać, i obliczając ją dla kontraktów wywołujących rekurencyjnie inne kontrakty, ale wymagałoby to od górników zakazania kontraktów, które tworzą inne kontrakty (ponieważ tworzenie i wykonywanie wszystkich 26 powyższych kontraktów można by łatwo połączyć w jeden kontrakt). Innym problematycznym punktem jest to, że pole adresowe komunikatu jest zmienne, więc w zasadzie nie można nawet powiedzieć, które inne kontrakty będą wywoływane przez dany kontrakt z wyprzedzeniem. W związku z tym mamy zaskakujący wniosek: kompletność w sensie Turinga jest zaskakująco łatwa do opanowania, a jej brak kompletności jest równie zaskakująco trudny do opanowania, chyba że zastosuje się dokładnie takie same kontrole – ale w takim przypadku dlaczego nie pozwolić, by protokół był kompletny w sensie Turinga? +Wyślijmy teraz transakcję do A. W ten sposób, w 51 transakcjach, mamy kontrakt, który zajmuje 250 kroków obliczeniowych. Górnicy mogliby próbować wykrywać takie bomby logiczne z wyprzedzeniem, utrzymując wartość obok każdego kontraktu określającą maksymalną liczbę kroków, które może on wykonać i obliczając ją dla kontraktów wywołujących inne kontrakty rekurencyjnie, ale wymagałoby to od górników zakazywania kontraktów, które tworzą inne kontrakty (ponieważ tworzenie i wykonywanie wszystkich powyższych 26 kontraktów mogłoby łątwo zostać włączone do jednego kontraktu). Innym problematycznym punktem jest to, że pole adresu wiadomości jest zmienną, więc generalnie może nie być nawet możliwe ustalenie, które inne kontrakty dany kontrakt wywoła z wyprzedzeniem. W związku z tym mamy zaskakujący wniosek: kompletność Turinga jest zaskakująco łatwa zarządzania, a brak kompletności Turinga jest równie zaskakująco trudny do zarządzania, chyba że wprowadzone zostaną takie same kontrole — ale w takim przypadku dlaczego po prostu nie pozwolić, aby protokół był kompletny w sensie Turinga? ### Waluta i emisja {#currency-and-issuance} -Sieć Ethereum zawiera własną, wbudowaną walutę, ether, która służy podwójnemu celowi: zapewnia podstawową warstwę płynności, umożliwiając efektywną wymianę między różnymi rodzajami aktywów cyfrowych oraz, co ważniejsze, zapewniając mechanizm uiszczania opłat za transakcje. Dla wygody i w celu uniknięcia przyszłych sporów (patrz obecna debata mBTC/uBTC/satoshi w Bitcoin), nominały będą wstępnie oznaczone: +Sieć Ethereum zawiera własną, wbudowaną walutę, ether, która pełni podwójną funkcję: zapewnia podstawową warstwę płynności, aby umożliwić efektywną wymianę między różnymi rodzajami aktywów cyfrowych, oraz co ważniejsze, zapewnia mechanizm do uiszczania opłat transakcyjnych. Dla wygody i uniknięcia przyszłych sporów (jak w przypadku obecnych dyskusji na temat mBTC/uBTC/satoshi w Bitcoinie) nominały zostaną wstępnie oznaczone: - 1: wei - 1012: szabo - 1015: finney - 1018: ether -Należy to traktować jako rozszerzoną wersję pojęcia „dolarów” i „centów” lub „BTC” i „satoshi”. W najbliższej przyszłości oczekujemy, że „ether” będzie używany do zwykłych transakcji, „finney” do mikrotransakcji, a „szabo” i „wei” do dyskusji technicznych na temat opłat i implementacji protokołu; pozostałe nominały mogą stać się użyteczne później i nie powinny być w tym momencie włączane do klientów. +Należy to traktować jako rozszerzoną wersję koncepcji „dolarów” i „centów” lub „BTC” i „satoshi”. W najbliższej przyszłości spodziewamy się, że „ether” będzie używany do zwykłych transakcji, „finney” do mikrotransakcji, a „szabo” i „wei” do technicznych dyskusji na temat opłat i implementacji protokołu; pozostałe nominały mogą stać się przydatne później i na razie nie powinny być uwzględniane w klientach. Model emisji będzie następujący: -- Ether zostanie opublikowany w sprzedaży walutowej po cenie 1000-2000 etheru na BTC, mechanizm służący finansowaniu organizacji Ethereum i opłacie za rozwój, który został wykorzystany z powodzeniem przez inne platformy, takie jak Mastercoin i NXT. Wcześni nabywcy odniosą korzyści z większych rabatów. BTC otrzymany ze sprzedaży zostanie całkowicie wykorzystany do wypłacania wynagrodzenia programistom i zainwestowanyc w różne projekty for-profit i non-profit w ekosystemu Ethereum i kryptowaluty. -- 0.099x całkowita kwota sprzedana (60102216 ETH) zostanie przeznaczona dla organizacji w celu wynagrodzenia wczesnych uczestników i zapłacenia wydatków denominowanych w ETH przed blokiem genezy. -- 0,099x łączna ilość sprzedanych produktów będzie utrzymana jako długoterminowa rezerwa. -- 0,26x łączna sprzedana ilość zostanie przydzielona górnikom na rok na zawsze po tym punkcie. +- Ether zostanie wydany w sprzedaży waluty po cenie 1000-2000 etherów za BTC, czyli mechanizmu przeznaczonego do finansowania organizacji Ethereum i płacenia za rozwój, który był z powodzeniem wykorzystywany przez inne platformy, takie jak MasterCoin i NXT. Wcześni nabywcy skorzystają z większych rabatów. BTC otrzymane ze sprzedaży zostaną w całości przeznaczone na wypłatę wynagrodzeń i nagród dla deweloperów, oraz zainwestowane w różne projekty non-profit, jak i te nastawione na zysk w ekosystemie Ethereum i kryptowalut. +- 0,099x całkowitej sprzedanej ilości (60102216 ETH) zostanie przydzielone organizacji w celu zrekompensowania wczesnych uczestników oraz na pokrycie wydatków denominowanych w ETH przed blokiem genezy. +- 0,099x całkowitej sprzedanej ilości zostanie utrzymane jako rezerwa długoterminowa. +- 0,26x całkowitej sprzedanej ilości będzie przydzielane górnikom każdego roku na zawsze od tego momentu. | Grupa | Przy wprowadzeniu | Po 1 roku | Po 5 latach | | --------------------------------- | ----------------- | --------- | ----------- | @@ -431,77 +465,74 @@ Model emisji będzie następujący: | Rezerwa wykorzystana po sprzedaży | 8,26% | 6,79% | 3,96% | | Górnicy | 0% | 17,8% | 52,0% | -**Długoterminowy wzrost podaży (w procentach)** +#### Długoterminowa stopa wzrostu podaży (w procentach) -![Inflacja w Ethereum](./ethereum-inflation.png) +![Inflacja Ethereum](./ethereum-inflation.png) -_Pomimo liniowej emisji waluty, podobnie jak w przypadku Bitcoina z czasem stopa wzrostu podaży dąży jednak do zera_ +_Pomimo liniowej emisji waluty, podobnie jak w przypadku Bitcoina, stopa wzrostu podaży z czasem dąży do zera._ -Dwa główne wybory w powyższym modelu to (1) istnienie i wielkość puli zasobów oraz (2) istnienie stale rosnącej liniowej podaży, w przeciwieństwie do ograniczonej podaży, jak w przypadku Bitcoina. Uzasadnienie puli zasobów jest następujące. Jeśli by pula zasobów nie istniała, a liniowa emisja zmniejszyła się do 0. 17x dla zapewnienia tej samej stopy inflacji, a następnie całkowita ilość eteru wynosiłaby 16,5% mniej, więc każda jednostka byłaby warta o 19,8% więcej. Tak więc w równowadze 19,8% więcej etheru zostałoby zakupione w sprzedaży, więc każda jednostka byłaby znów tak samo cenna jak poprzednio. Organizacja miałaby wtedy również 1,198x więcej BTC, które można uznać za podzielone na dwie części: oryginalny BTC i dodatkowe 0,198x. W związku z tym ta sytuacja jest _dokładnie równoważna_ z zaopatrzeniem, ale przy jednej istotnej różnicy: organizacja posiada wyłącznie BTC, a więc nie jest zachęcana do wspierania wartości jednostki etheru. +Dwa główne wybory w powyższym modelu to (1) istnienie i wielkość puli zasobów oraz (2) istnienie stale rosnącej liniowej podaży, w przeciwieństwie do ograniczonej podaży, jak w przypadku Bitcoina. Uzasadnienie puli zasobów jest następujące. Gdyby pula zasobów nie istniała, a liniowa emisja została zmniejszona do 0,217x, aby zapewnić taką samą stopę inflacji, całkowita ilość etheru byłaby o 16,5% mniejsza, a każda jednostka byłaby o 19,8% bardziej wartościowa. W związku z tym, w równowadze zakupiono by o 19,8% więcej etheru podczas sprzedaży, a więc każda jednostka byłaby znowu tak samo wartościowa jak wcześniej. Organizacja posiadałaby również 1,198x więcej BTC, które można podzielić na dwie części: oryginalny BTC i dodatkowe 0,198x. W związku z tym sytuacja ta jest _dokładnie równoważna_ z istnieniem puli zasobów, ale z jedną istotną różnicą: organizacja posiadałaby wyłącznie BTC, a zatem nie byłaby zachęcana do wspierania wartości jednostki etheru. -Stały model liniowego wzrostu podaży zmniejsza ryzyko tego, co niektórzy postrzegają jako nadmierne stężenie bogactwa w Bitcoin, i daje osobom jednostek waluty, jednocześnie zachowując silną zachętę do uzyskania i wstrzymania eteru, ponieważ „stopa wzrostu podaży” wyrażona jako procent nadal wynosi w miarę upływu czasu. Teoretyzujemy również, że ponieważ monety są zawsze tracone z czasem z powodu nieostrożności, śmierci, itp., a utrata monet może być modelowana jako procent całkowitej podaży na rok, że całkowita podaż waluty w obiegu w rzeczywistości ostatecznie ustabilizuje się na wartości równej rocznej emisji podzielonej przez wskaźnik utraty (np. przy stopie strat 1%, gdy podaż osiągnie 26X, 0,26X będzie wydobywane i 0,26X tracone każdego roku, tworząc równowagę). +Stały liniowy model wzrostu podaży zmniejsza ryzyko tego, co niektórzy postrzegają jako nadmierną koncentrację bogactwa w Bitcoinie, i daje osobom żyjącym obecnie i w przyszłości uczciwą szansę na nabycie jednostek waluty, jednocześnie zachowując silną zachętę do pozyskiwania i utrzymywania etheru, poniważ „stopa wzrostu podaży” jako procent z czasem nadal zmierza do zera. Teoretyzujemy również, że ponieważ monety są zawsze tracone z czasem z powodu nieostrożności, śmierci itp., a utrata monet może być modelowana jako procent całkowitej podaży rocznie, całkowita podaż waluty w obiegu ostatecznie ustabilizuje się na poziomie równym rocznej emisji podzielonej przez wskaźnik strat (np. przy wskaźniku strat wynoszącym 1%, gdy podaż osiągnie 26X, wówczasz 0,26X będzie wydobywane i 0,26X tracone każdego roku, tworząc równowagę). -Zauważ, że w przyszłości Ethereum przełączy się na model proof-of-stake dla bezpieczeństwa, ograniczając wymaganie emisji do jakiejś wartości między zerem a 0,05X rocznie. W przypadku, gdy organizacja Ethereum straci fundusze lub z jakiegokolwiek innego powodu zniknie, pozostawiamy otwartą „umowę społeczną”: każdy ma prawo do stworzenia przyszłej wersji kandydata Ethereum, pod jedynym warunkiem, że ilość eteru musi być co najwyżej równa `60102216 * (1. 198 + 0.26 * n)` gdzie `n` jest liczbą lat po bloku genezy. Twórcy mogą swobodnie sprzedać lub w inny sposób przypisać część lub całość różnicy między zwiększeniem podaży napędzanym przez PoS a maksymalnym dopuszczalnym zwiększeniem podaży do zapłaty za rozwój. Aktualizacje kandydujące, które nie są zgodne z umową społeczną, mogą być w uzasadniony sposób rozwidlone na wersje zgodne. +Należy pamiętać, ze w przyszłości prawdopodobne jest, że Ethereum przejdzie na model proof-of-stake dla bezpieczeństwa, zmniejszając wymóg emisji do wartości od zera do 0,05X rocznie. W przypadku, gdy organizacja Ethereum straci fundusze lub z jakiegokolwiek innego powodu zniknie, pozostawiamy otwartą „umowę społeczną”: każdy ma prawo stworzyć przyszłą kandydującą wersję Ethereum, pod warunkiem, że ilość etheru musi być co najwyżej równa `60102216 * (1.198 + 0.26 * n)`, gdzie `n` to liczba lat po bloku genezy. Twórcy mogą swobodnie sprzedawać lub w inny sposób przydzielać część lub całość różnicy między ekspansją podaży napędzaną przez PoS a maksymalną dopuszczalną ekspansją podaży, aby zapłacić za rozwój. Kandydujące aktualizacje, które nie są zgodne z umową społeczną, mogą zostać w uzasadniony sposób sforkowane na wersje zgodne. ### Centralizacja wydobycia {#mining-centralization} -Algorytm wydobywczy Bitcoin działa w ten sposób, że górnicy obliczają SHA256 na lekko zmodyfikowanych wersjach nagłówka bloku miliony razy w kółko, aż w końcu jeden z węzłów znajdzie wersję, której hash jest mniejszy niż docelowy (obecnie około 2192). Ten algorytm wydobywania jest jednak podatny na dwie formy centralizacji. Po pierwsze, ekosystem górniczy został zdominowany przez ASIC (układy scalone specyficzne dla zastosowań), chipy komputerowe zaprojektowane dla konkretnego zadania wydobycia Bitcoina, a zatem tysiące razy bardziej wydajne. Oznacza to, że wydobycie bitcoinów nie jest już wysoce zdecentralizowanym i egalitarnym przedsięwzięciem, wymagającym milionów dolarów kapitału, aby efektywnie w nim uczestniczyć. Po drugie, większość górników Bitcoin nie wykonuje walidacji bloków lokalnie; zamiast tego polegają na scentralizowanej puli wydobywczej, która dostarcza nagłówki bloków. Ten problem jest prawdopodobnie poważniejszy: w czasie pisania tego tekstu trzy największe pule górnicze pośrednio kontrolują około 50% mocy obliczeniowej w sieci Bitcoin, chociaż jest to złagodzone przez fakt, że górnicy mogą przejść do innych pul górniczych, jeśli jakaś pula lub koalicja próbuje ataku 51%. +Algorytm wydobywczy Bitcoina działa w ten sposób, że górnicy obliczają SHA256 na lekko zmodyfikowanych wersjach nagłówka bloku miliony razy w kółko, aż w końcu jeden węzeł znajdzie wersję, której hash jest mniejszy niż docelowy (obecnie około 2192). Ten algorytm wydobywczy jest jednak podatny na dwie formy centralizacji. Po pierwsze, ekosystem wydobywczy został zdominowany przez układy ASIC (specjalizowane układy scalone), czyli chipy komputerowe zaprojektowane specjalnie do wydobywania Bitcoinów, które są tysiące razy wydajniejsze w tym konkretnym zadaniu. Oznacza to, ze wydobywanie Bitcoinów nie jest już wysoce zdecentralizowanych i egalitarnym zajęciem, ponieważ wymaga milionów dolarów kapitału, aby efektywnie w tym uczestniczyć. Po drugie, większość górników Bitcoinów nie przeprowadza walidacji bloków lokalnie; zamiast tego polegają oni na scentralizowanych pulach wydobywczych, które dostarczają im nagłówki bloków. Ten problem jest prawdopodobnie poważniejszy: w chwili pisania tego tekstu, trzy największe pule wydobywcze pośrednio kontrolują około 50% mocy obliczeniowej w sieci Bitcoin, chociaż jest to łagodzone przez fakt, że górnicy mogą przełączyć się na inną pulę wydobywczą, jeśli dana pula lub koalicja spróbuje przeprowadzić atak 51%. -Obecnym zamiarem w Ethereum jest wykorzystanie algorytmu wydobywczego, w którym górnicy są zobowiązani do pobierania losowych danych ze stanu, obliczania kilku losowo wybranych transakcji z ostatnich N bloków w blockchainie i zwracania skrótu wyniku. Ma to dwie ważne korzyści. Po pierwsze, kontrakty Ethereum mogą zawierać wszelkiego rodzaju obliczenia, więc Ethereum ASIC byłby zasadniczo ASIC do obliczeń ogólnych – np. lepszy CPU. Po drugie, wydobywanie wymaga dostępu do całego łańcucha bloków, co zmusza górników do przechowywania całego łańcucha bloków i przynajmniej weryfikowania każdej transakcji. Eliminuje to potrzebę istnienia scentralizowanych pul wydobywczych; chociaż pule wydobywcze mogą nadal pełnić uzasadnioną rolę wyrównywania losowości dystrybucji nagród, funkcja ta może być równie dobrze pełniona przez pule peer-to-peer bez centralnej kontroli. +Obecnym zamiarem Ethereum jest wykorzystanie algorytmu wydobywczego, w którym górnicy są zobowiązani do pobierania losowanych danych ze stanu, obliczania losowo wybranych transakcji z ostatnich N bloków w blockchainie i zwracania hashu wyniku. Ma to dwie ważne korzyści. Po pierwsze, kontrakty Ethereum mogą zawierać dowolny rodzaj obliczeń, więc układ ASIC Ethereum byłby zasadniczo układem ASIC do ogólnych obliczeń — tj. lepszym procesorem. Po drugie, wydobywanie wymaga dostępu do całego blockchainu, co zmusza górników do przechowywania całego blockchainu i przynajmniej do zdolności weryfikacji każdej transakcji. Eliminuje to potrzebę scentralizowanych pul wydobywczych; chociaż pule wydobywcze mogą nadal pełnić uzasadnioną rolę wyrównywania losowości dystrybucji nagród, funkcja ta może być równie dobrze obsługiwana przez pule peer-to-peer bez centralnej kontroli. -Niniejszy model nie jest testowany, i mogą pojawić się trudności w unikaniu pewnych inteligentnych optymalizacji podczas korzystania z wykonania kontraktu jako algorytmu górniczego. Jednak szczególnie interesującą cechą tego algorytmu jest to, że pozwala on każdemu na „zatrucie studni”, poprzez wprowadzenie do blockchainu dużej liczby kontraktów zaprojektowanych specjalnie po to, by powstrzymać pewne układy ASIC. Dla producentów ASIC istnieją zachęty ekonomiczne, aby używali tego rodzaju sztuczki do wzajemnego atakowania. Zatem rozwiązaniem, które opracowujemy, jest ostatecznie adaptacyjne rozwiązanie ekonomiczne, a nie czysto techniczne. +Model ten nie został jeszcze przetestowany, a po drodze mogą pojawić się trudności z uniknięciem pewnych sprytnych optymalizacji podczas korzystania z wykonywania kontraktu jako algorytmu wydobywczego. Jednakże jedną znacząco interesującą funkcją tego algorytmu jest to, że pozwala on każdemu na "zatrucie studni" poprzez wprowadzenie dużej liczby kontraktów na blockchain zaprojektowanych specjalnie po to, aby zatkać niektóre ASIC. Istnieje zachęta ekonomiczna dla producentów ASIC, aby użyć takiego triku w celu zaatakowania siebie nawzajem. Zatem rozwiązanie, które tworzymy jest ostatecznie bardziej ludzkim rozwiązaniem ekonomicznym niż czysto technicznym. ### Skalowalność {#scalability} -Jedną z powszechnych obaw związanych z Ethereum jest kwestia skalowalności. Podobnie jak w przypadku Bitcoina, wada Ethereum polega na tym, że każda transakcja musi być przetwarzana przez każdy węzeł w sieci. W przypadku Bitcoina, rozmiar obecnego łańcucha bloków wynosi około 15 GB, wzrastając o około 1 MB na godzinę. Jeśli sieć Bitcoin miała przetwarzać 2000 transakcji Visa na sekundę, rosłaby o 1 MB na trzy sekundy (1 GB na godzinę, 8 TB na rok). Ethereum prawdopodobnie doświadczy podobnego wzorca wzrostu, pogorszonego przez to, że na górze blockchainu Ethereum będzie wiele aplikacji zamiast tylko waluty, jak ma to miejsce w przypadku Bitcoina, ale złagodzi to fakt, że pełne węzły Ethereum muszą przechowywać tylko stan zamiast całej historii blockchainu. +Jedną z powszechnych obaw związanych z Ethereum jest kwestia skalowalności. Podobnie do Bitcoina, Ethereum cierpi z powodu wady, która opiera się na konieczności przetwarzania każdej transakcji przez każdy węzeł sieci. W przypadku Bitcoina obecny rozmiar blockchaina wynosi około 15 GB i zwiększa się o ok. 1 MB na godzinę. Jeśli sieć Bitcoin miałaby przetwarzać 2000 transakcji na sekundę jak Visa, jej rozmiar rósłby o 1 MB co trzy sekundy (1 GB na godzinę, 8 TB rocznie). Ethereum prawdopodobnie będzie podlegać podobnemu schematowi wzrostu, pogorszonemu przez fakt, że na blockchainie Ethereum będzie wiele aplikacji, a nie tylko waluta, jak w przypadku Bitcoina. Sytuację tę złagodzi jednak fakt, że pełne węzły Ethereum będą musiały przechowywać tylko stan, a nie całą historię blockchaina. -Problem z tak dużą wielkością blockchainu to ryzyko centralizacji. Jeśli rozmiar łańcucha bloków wzrasta na przykład do 100 TB, wtedy prawdopodobnym scenariuszem byłby fakt, że tylko bardzo mała liczba dużych przedsiębiorstw prowadziłaby pełnych węzłów, ze wszystkimi regularnymi użytkownikami używającymi lekkich węzłów SPV. W takiej sytuacji pojawia się potencjalna obawa, że wszystkie węzły mogłyby wspólnie i wszyscy zgadzają się na oszukiwanie w sposób przynoszący zyski (np. zmień nagrodę bloku, daj sobie BTC). Lekkie węzły nie miałyby sposobu na natychmiastowe wykrycie. Oczywiście przynajmniej jeden uczciwy pełny węzeł prawdopodobnie istniałby, a po kilku godzinach informacje o oszustwo wyciekłyby kanałami takimi jak Reddit, ale w tym momencie byłoby już za późno: zwykli użytkownicy zajmą się organizacją próby umieszczenia na czarnej liście podanych bloków, ogromnym i prawdopodobnie niewykonalnym problem koordynacji o podobnej skali, jak próba poderwania się na udany atak 51%. W przypadku Bitcoina, jest to obecnie problem, ale istnieje modyfikacja blockchain [zasugerowana przez Petera Todda](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/), która poprawi ten problem. +Problem z tak dużą wielkością blockchainu to ryzyko centralizacji. Jeśli wielkość blockchaina wzrośnie do powiedzmy 100 TB, wówczas prawdopodobnym scenariuszem stanie się taki, w którym bardzo mała liczba wielkich przedsiębiorstw utrzymywałaby pełne węzły, a wszyscy normalni użytkownicy używaliby lekkich węzłów SPV. W takiej sytuacji powstaje potencjalne ryzyko, że pełne węzły zgrupują się i dogadają oszustwo w jakiś sposób zapewniający im zysk (np. zmieniając nagrodę za blok, przyznając sobie BTC). Lekkie węzły nie miałyby możliwości natychmiastowego wykrycia tej sytuacji. Oczywiście, prawdopodobnie istniałby co najmniej jeden uczciwy, pełny węzeł i po kilku godzinach informacja o oszustwie wyciekłaby przez kanały takie jak Reddit, ale wtedy byłoby już za późno: zwykli użytkownicy musieliby zorganizować akcję umieszczenia danych bloków na czarnej liście, co stanowiłoby ogromny i prawdopodobnie niewykonalny problem koordynacyjny na skalę porównywalną do przeprowadzenia udanego ataku 51%. W przypadku Bitcoina jest to obecnie problem, ale istnieje modyfikacja blockchainu [zaproponowana przez Petera Todda](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/), która złagodzi ten problem. -W najbliższym czasie Ethereum wykorzysta dwie dodatkowe strategie w celu rozwiązania tego problemu. Po pierwsze, z powodu algorytmów kopania opartych na blockchain, co najmniej każdy górnik będzie zmuszony do bycia pełnym węzłem, tworząc dolną granicę liczby pełnych węzłów. Drugie i więcej ważne jest jednak, że po przetworzeniu każdej transakcji znajdziemy pośrednie drzewo stanowe w łańcuchu bloków. Nawet jeśli blok jest scentralizowany, dopóki istnieje jeden uczciwy węzeł, problem centralizacji można obejść za pomocą protokołu weryfikacji. Jeśli górnik publikuje nieprawidłowy blok, ten blok musi być albo źle sformatowany, albo stan `S[n]` jest nieprawidłowy. Skoro `S[0]` jest znany jako poprawny, musi być jakiś pierwszy stan `S[i]` niepoprawny gdzie `S[i-1]` jest poprawny. Serwer weryfikujący dostarczy indeks `i`, wraz z „dowodem inwalidztwa” składającym się z podzbioru węzłów drzew Patricia, które muszą przetworzyć `APPLY(S[i-1], X[i]) -> S[i]`. Węzły będą mogły używać węzłów Patricia do uruchomienia tej części obliczeń, i zobacz, że wygenerowany `S[i]` nie pasuje do podanego `S[i]`. +W bliskiej przyszłości Ethereum zastosuje dwie dodatkowe strategie przeciwdziałania temu problemowi. Po pierwsze, z uwagi na mechanizmy kopania oparte na blockchainie, każdy górnik będzie zmuszony utrzymywać pełny węzeł, przez co wytworzy się dolna granica liczby pełnych węzłów. Po drugie, co istotniejsze, dołączony do blockchaina zostanie pośredni korzeń drzewa stanu po przetworzeniu każdej transakcji. Nawet jeśli walidacja bloków jest scentralizowana, problem centralizacji można obejść za pomocą protokołu weryfikacji, o ile istnieje jeden uczciwy węzeł weryfikujący. Jeśli górnik opublikuje nieprawidłowy blok, to blok ten musi być źle sformatowany lub stan `S[n]` jest niepoprawny. Ponieważ wiadomo, że `S[0]` jest poprawne, musi istnieć jakiś pierwszy stan `S[i]`, który jest niepoprawny, tam gdzie `S[i-1]` jest poprawne. Węzeł weryfikujący dostarczyłby indeks `i` wraz z „dowodem nieważności” składającym się z podzbioru węzłów drzewa Patricia, które muszą przetworzyć `APPLY(S[i-1],TX[i]) -> S[i]`. Węzły mogłyby używać tych węzłów do wykonywania tej części obliczeń i stwierdzać, że wygenerowany `S[i]` nie pasuje do podanego `S[i]`. -Inny, bardziej zaawansowany atak obejmowałby złośliwych górników publikowania niekompletnych bloków, więc pełna informacja nawet nie istnieje, aby określić, czy bloki są poprawne. Rozwiązaniem tego jest protokół wyzwania-odpowiedzi: węzły weryfikacyjne problem "wyzwania" w postaci docelowych wskaźników transakcji, i po otrzymaniu węzła węzeł świetlny traktuje blok jako niezaufany do czasu, aż inny węzeł, czy górnik lub inny weryfikator dostarcza podzbiór węzłów Patricia jako dowód ważności. +Inny, bardziej wyrafinowany atak polegałby na tym, że złośliwi górnicy publikowaliby niekompletne bloki, tak że nie istniałyby nawet pełne informacje pozwalające określić, czy bloki są prawidłowe. Rozwiązaniem tego problemu jest protokół typu wyzwanie-odpowiedź: węzły weryfikacyjne wystawiają „wyzwania” w formie docelowych indeksów transakcji, a po otrzymaniu węzła węzeł lekki traktuje blok jako niezaufany, dopóki inny węzeł, niezależnie od tego, czy jest to górnik, czy inny weryfikator, nie dostarczy podzbioru węzłów Patricia jako dowodu ważności. -## Podsumowanie {#conclusion} +## Wnioski {#conclusion} -Protokół Ethereum został pierwotnie zaprojektowany jako zaktualizowana wersja kryptowaluty, zapewniająca zaawansowane funkcje, takie jak escrow- w blockchain, limity odstąpienia, umowy finansowe, rynki gier hazardowych i, np. poprzez wysoce uogólniony język programowania. Protokół Ethereum nie będzie "wspierał" żadnej aplikacji bezpośrednio, ale istnienie kompletnego języka programowania oznacza, że dowolny kontrakty można teoretycznie utworzyć dla każdego rodzaju transakcji lub aplikacji. Bardziej interesujące jest jednak to, że protokół Ethereum przesuwa się daleko poza samą walutę. Protokoły wokół zdecentralizowanego przechowywania plików, zdecentralizowanych obliczeń i zdecentralizowanych rynków przewidywania wśród dziesiątków innych takich koncepcji, mają potencjał znacznego zwiększenia wydajności przemysłu obliczeniowego, i stanowi ogromny bodziec dla innych protokołów peer-to-peer przez dodanie warstwy ekonomicznej. Wreszcie, istnieje również znaczna gama aplikacji, które w ogóle nie mają nic wspólnego z pieniędzmi. +Protokół Ethereum został pierwotnie pomyślany jako ulepszona wersja kryptowaluty, zapewniająca zaawansowane funkcje, takie jak depozyt w ramach łańcucha bloków, limity wypłat, kontrakty finansowe, rynki hazardowe i tym podobne, za pośrednictwem wysoce uogólnionego języka programowania. Protokół Ethereum nie „obsługiwałby” bezpośrednio żadnej z aplikacji, ale istnienie języka programowania z kompletnością Turinga oznacza, że ​​teoretycznie możliwe jest tworzenie dowolnych kontraktów dla dowolnego typu transakcji lub aplikacji. Co jednak ciekawsze w przypadku Ethereum, to fakt, że protokół Ethereum wykracza daleko poza samą walutę. Protokoły dotyczące zdecentralizowanego przechowywania plików, zdecentralizowanych obliczeń i zdecentralizowanych rynków predykcyjnych, a także dziesiątki innych podobnych koncepcji, mają potencjał znacznego zwiększenia wydajności branży obliczeniowej i zapewnienia dużego wsparcia innym protokołom peer-to-peer poprzez dodanie po raz pierwszy warstwy ekonomicznej. Wreszcie, istnieje również pokaźna gama aplikacji, które nie mają nic wspólnego z pieniędzmi. -Koncepcja arbitralnej funkcji przejściowej państwa wdrożonej przez protokołu Ethereum zapewnia platformę o unikalnym potencjale; zamiast być zamkniętym, jednofunkcyjnym protokołem przeznaczonym do konkretnych zastosowań w przechowywaniu danych, gra hazardowa lub finansowa, Ethereum jest otwarte przez projekt, i uważamy, że w nadchodzących latach jest on niezwykle dobrze przygotowany do pełnienia funkcji podstawy dla bardzo dużej liczby protokołów finansowych i niefinansowych. +Koncepcja dowolnej funkcji przejścia stanu, zaimplementowana w protokole Ethereum, zapewnia platformę o wyjątkowym potencjale. Zamiast być zamkniętym protokołem o jednym przeznaczeniu, przeznaczonym do określonej gamy zastosowań w zakresie przechowywania danych, hazardu lub finansów, Ethereum jest z założenia otwarte i wierzymy, że doskonale nadaje się do pełnienia funkcji warstwy bazowej dla bardzo dużej liczby protokołów finansowych i niefinansowych w nadchodzących latach. ## Uwagi i dalsze lektury {#notes-and-further-reading} ### Uwagi {#notes} -1. Czytelnik może zauważyć, że w rzeczywistości adres Bitcoin jest skrótem klucza publicznego krzywej eliptycznej, a nie klucz publiczny. Jednak w rzeczywistości całkowicie uzasadniona jest terminologia kryptograficzna określająca hash pubkey jako sam klucz publiczny. , ponieważ kryptografię Bitcoina można uznać za niestandardową algorytm podpisu cyfrowego, w przypadku gdy klucz publiczny składa się z skrótu pubke'a ECC, podpis składa się z pubkey ECC połączony z podpisem ECC, i algorytm weryfikacji obejmuje sprawdzanie pubkey ECC w podpisze za pomocą skrótu pubkey ECC dostarczonego jako klucz publiczny, a następnie weryfikację podpisu ECC za pomocą pubkey ECC. -2. Technicznie mediana 11 poprzednich bloków. -3. Protokół Ethereum powinien być tak prosty, jak to możliwe, ale może być konieczne do uzyskania dość wysokiego stopnia złożoności, na przykład do skali, do internalizacji kosztów przechowywania, szerokości pasma i I/O, dla bezpieczeństwa, prywatności, przejrzystości itp. W przypadku gdy złożoność jest konieczna, dokumentacja powinna być możliwie jak najwyraźniejsza, zwięzła i aktualna, aby ktoś całkowicie nieszkolony w Ethereum mógł nauczyć się tego i stać się ekspertem. -4. Zobacz [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) dla maszyny wirtualnej Ethereum (która jest przydatna jako specyfikacja i punkt odniesienia dla budowania klienta Ethereum od podstaw), podczas gdy jest również wiele tematów w [Ethereum wiki](https://github.com/ethereum/wiki/wiki), takich jak rozwój, Podstawowy rozwój, rozwój aplikacji, badania, Casper R&D i protokoły sieciowe. Do badań i możliwej przyszłości implementacja istnieje [ethresear.ch](https://ethresear.ch). -5. Innym sposobem wyrażania tego jest abstrakcja. [najnowsza mapa drogowa](https://ethresear.ch/t/sharding-phase-1-spec/1407/67) planuje abstrakcję wykonania, zezwalanie na nie silnikom wykonującym musi być zgodne z jedną specyfikacją kanoniczną, ale na przykład może być dostosowany do konkretnej aplikacji, a do fragmentu. (Ta heterogeniczność silników egzekucyjnych nie jest wyraźnie podana w mapie drogowej. Istnieje również niejednorodny sharding, który Konceptualizuje Vlada Zamfira.) -6. Wewnętrznie 2 i „CHARLIE” to liczby, przy czym ta ostatnia to w reprezentacji big-endian base 256. Liczby mogą wynosić co najmniej 0 i co najwyżej 2256-1. - -### Czytaj Dalej {#further-reading} - -1. [Wartość wewnętrzna](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/) -2. [Inteligentna własność](https://en.bitcoin.it/wiki/Smart_Property) -3. [Inteligentne kontrakty](https://en.bitcoin.it/wiki/Contracts) -4. [B- pieniądze](http://www.weidai.com/bmoney.txt) -5. [Dowody pracy wielokrotnego użytku](https://nakamotoinstitute.org/finney/rpow/) -6. [Zabezpieczenie tytułów własności na podstawie uprawnień właściciela](https://nakamotoinstitute.org/secure-property-titles/) -7. [Biała księga Bitcoin](http://bitcoin.org/bitcoin.pdf) -8. [Namecoin](https://namecoin.org/) -9. [Trójkąt Zooko's](https://wikipedia.org/wiki/Zooko's_triangle) +1. Doświadczony czytelnik może zauważyć, że adres Bitcoin to tak naprawdę skrót klucza publicznego w postaci krzywej eliptycznej, a nie sam klucz publiczny. Jednak w rzeczywistości całkowicie uzasadniona jest terminologia kryptograficzna określająca hash pubkey jako sam klucz publiczny. Dzieje się tak, ponieważ kryptografię Bitcoina można uznać za niestandardowy algorytm podpisu cyfrowego, w którym klucz publiczny składa się z skrótu klucza publicznego ECC, podpis składa się z klucza publicznego ECC połączonego z podpisem ECC, a algorytm weryfikacji obejmuje sprawdzenie klucza publicznego ECC w podpisie względem skrótu klucza publicznego ECC podanego jako klucz publiczny, a następnie weryfikację podpisu ECC względem klucza publicznego ECC. +2. Technicznie mediana 11 poprzednich bloków. +3. Wewnętrznie zarówno 2, jak i „CHARLIE” są liczbami[fn3](#notes), przy czym ta druga jest zapisana w systemie big-endian o podstawie 256. Liczby mogą wynosić co najmniej 0 i co najwyżej 2256-1. + +### Dalsza lektura {#further-reading} + +1. [Wartość wewnętrzna](https://bitcoinmagazine.com/culture/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it) +2. [Inteligentna własność](https://en.bitcoin.it/wiki/Smart_Property) +3. [Inteligentne kontrakty](https://en.bitcoin.it/wiki/Contracts) +4. [B-money](http://www.weidai.com/bmoney.txt) +5. [Dowody pracy wielokrotnego użytku](https://nakamotoinstitute.org/finney/rpow/) +6. [Bezpieczne tytuły własności z upoważnieniem właściciela](https://nakamotoinstitute.org/library/secure-property-titles/) +7. [Biała księga Bitcoina](http://bitcoin.org/bitcoin.pdf) +8. [Namecoin](https://namecoin.org/) +9. [Trójkąt Zooko](https://wikipedia.org/wiki/Zooko's_triangle) 10. [Biała księga kolorowych monet](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) -11. [Biała księga Mastercoina](https://github.com/mastercoin-MSC/spec) -12. [Zdecentralizowane autonomiczne korporacje, Bitcoin Magazine](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/) -13. [Uproszczona weryfikacja płatności](https://en.bitcoin.it/wiki/Scalability#Simplifiedpaymentverification) +11. [Biała księga Mastercoin](https://github.com/mastercoin-MSC/spec) +12. [Zdecentralizowane korporacje autonomiczne, Bitcoin Magazine](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/) +13. [Uproszczona weryfikacja płatności](https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification) 14. [Drzewa Merkle](https://wikipedia.org/wiki/Merkle_tree) 15. [Drzewa Patricia](https://wikipedia.org/wiki/Patricia_tree) 16. [GHOST](https://eprint.iacr.org/2013/881.pdf) -17. [StorJ i agenci autonomiczni, Jeff Garzik](http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html) -18. [Mike Hearn na temat Inteligentnej Własności podczas Festiwalu Turinga](http://www.youtube.com/watch?v=Pu4PAMFPo5Y) -19. [Ethereum RLP](https://web.archive.org/web/20250427212320/https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP) -20. [Drzewa Patricia Merkle w Ethereum](https://web.archive.org/web/20250427212320/https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree) -21. [Peter Todd na temat sumy drzew Merkle](http://sourceforge.net/p/bitcoin/mailman/message/31709140/) +17. [StorJ i autonomiczni agenci, Jeff Garzik](http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html) +18. [Mike Hearn o inteligentnej własności na Turing Festival](https://www.youtube.com/watch?v=MVyv4t0OKe4) +19. [RLP Ethereum](/developers/docs/data-structures-and-encoding/rlp/) +20. [Drzewa Merkle Patricia w Ethereum](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) +21. [Peter Todd o drzewach sum Merkle](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) -_Historia białej księgi znajduje się na stronie https://github.com/ethereum/wiki/blob/old-before-deleting-all-files-go-to-wiki-wiki-instead/old-whitepaper-for-historical-reference.md_ +_Historia białej księgi znajduje się na [tej stronie wiki](https://web.archive.org/web/20250427212319/https://github.com/ethereum/wiki/blob/old-before-deleting-all-files-go-to-wiki-wiki-instead/old-whitepaper-for-historical-reference.md)._ -_Warto zauważyć, że Ethereum, podobnie jak wiele projektów oprogramowania opartych na społecznościach, rozwija się od czasu jego początkowego powstania. Aby dowiedzieć się o najnowszych zmianach w Ethereum i jak wprowadzone są zmiany w protokole, zalecamy [ten przewodnik](/learn/)._ +_Ethereum, podobnie jak wiele projektów oprogramowania open-source tworzonych przez społeczność, rozwija się od czasu jego początkowego powstania. _Aby dowiedzieć się o najnowszych zmianach w Ethereum i o tym, jak wprowadzane są zmiany w protokole, polecamy [ten przewodnik](/learn/)._ From 1620e81a6ccb069e2d8cc00c9469070d2ca81d69 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sun, 15 Feb 2026 17:58:13 +0000 Subject: [PATCH 2/2] fix(i18n): repair broken bold markdown in pl whitepaper Items 6-8 in the application list had split bold markers from Crowdin (**N.** Title\*\* instead of **N. Title**). Restore to match English source formatting. --- public/content/translations/pl/whitepaper/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/translations/pl/whitepaper/index.md b/public/content/translations/pl/whitepaper/index.md index 2a698b81e5f..2619dc2cc24 100644 --- a/public/content/translations/pl/whitepaper/index.md +++ b/public/content/translations/pl/whitepaper/index.md @@ -351,11 +351,11 @@ Zwykle 1% dziennie wystarcza Alice, a jeśli Alice chce wypłacić więcej, moż **5. Chmura obliczeniowa**. Technologia EVM może być również wykorzystywana do tworzenia weryfikowalnego środowiska obliczeniowego, pozwalając użytkownikom zlecać innym wykonania obliczeń, a następnie opcjonalnie żądać dowodów, że obliczenia w niektórych losowo wybranych punktach kontrolnych zostały wykonane poprawnie. Pozwala to na stworzenie rynku chmur obliczeniowych, w którym każdy użytkownik może uczestniczyć, korzystając ze swojego komputera stacjonarnego, laptopa lub wyspecjalizowanego serwera, a wyrywkowa kontrola oraz depozyty zabezpieczające mogą zapewnić, że system jest godny zaufania (tj. węzły nie mogą oszukiwać z zyskiem). Chociaż taki system może nie być odpowiedni dla wszystkich zadań; na przykład zadania wymagające wysokiego poziomu komunikacji międzyprocesowej, nie mogą być łatwo realizowane na dużej chmurze węzłów. Inne zadania są jednak znacznie łatwiejsze do zrównoleglenia; projekty takie jak SETI@home, folding@home i algorytmy genetyczne mogą być z łatwością zaimplementowane na takiej platformie. -**6.** Hazard peer-to-peer\*\*. Dowolna liczba protokołów hazardowych peer-to-peer, takich jak [Cyberdice](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf) Franka Stajano i Richarda Claytona, może zostać zaimplementowana na blockchainie Ethereum. Najprostszym protokołem hazardowym jest właściwie kontrakt różnicy kursowej oparty na hashu następnego bloku, a bardziej zaawansowane protokoły mogą być tworzone na tej podstawie, tworzą usługi hazardowe z niemal zerowymi opłatami, które nie mają możliwości oszukiwania. +**6. Hazard peer-to-peer**. Dowolna liczba protokołów hazardowych peer-to-peer, takich jak [Cyberdice](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf) Franka Stajano i Richarda Claytona, może zostać zaimplementowana na blockchainie Ethereum. Najprostszym protokołem hazardowym jest właściwie kontrakt różnicy kursowej oparty na hashu następnego bloku, a bardziej zaawansowane protokoły mogą być tworzone na tej podstawie, tworzą usługi hazardowe z niemal zerowymi opłatami, które nie mają możliwości oszukiwania. -**7.** Rynki prognostyczne\*\*. Przy zastosowaniu wyroczni lub SchellingCoin rynki prognostyczne są również łatwe do zaimplementowania, a rynki prognostyczne połączone z SchellingCoin mogą stać się pierwszym szeroko stosowanym zastosowaniem [futarchii](https://mason.gmu.edu/~rhanson/futarchy.html) jako protokołu zarządzania dla zdecentralizowanych organizacji. +**7. Rynki prognostyczne**. Przy zastosowaniu wyroczni lub SchellingCoin rynki prognostyczne są również łatwe do zaimplementowania, a rynki prognostyczne połączone z SchellingCoin mogą stać się pierwszym szeroko stosowanym zastosowaniem [futarchii](https://mason.gmu.edu/~rhanson/futarchy.html) jako protokołu zarządzania dla zdecentralizowanych organizacji. -**8.** Zdecentralizowane rynki on-chain\*\*, wykorzystujące system tożsamości i reputacji jako podstawę. +**8. Zdecentralizowane rynki on-chain**, wykorzystujące system tożsamości i reputacji jako podstawę. ## Różne i obawy {#miscellanea-and-concerns}