i18n(pl): automated Crowdin translation import (part 03/07/09/10 of 13)

docs/solutions/integration-issues/sanitizer-test-research.md

@@ -62,6 +62,11 @@
 | 49 | Lowercased MDX component name | de #17842 | `<emoji text=":tada:" size={1} />` instead of `<Emoji .../>` -- translation pipeline lowercases the PascalCase MDX component tag; MDX component names are case-sensitive, so the lowercased tag won't resolve to the registered component | Critical -- breaks rendering |
 | 50 | `removeOrphanedClosingTags` strips valid cross-line `</em>` | de #17842 | `<em>\ntext</em></li>` -- `<em>` is on line N, `</em>` is on line N+1; line-by-line counting sees no opener on line N+1 and strips `</em>` as orphaned, breaking MDX compilation. Regression from sanitizer's own orphan removal logic. | Critical -- breaks MDX compilation |
 
+| 49 | Orphaned `</em>` BEFORE `<a>` in HTML list items | pl #17445 | `<li></em><a href="...">EIP-145</a> - <em>text</li>` -- `</em>` appears before its opener `<em>`; `removeOrphanedClosingTags` sees balanced open/close counts on the line so doesn't remove it | Critical -- breaks MDX compilation |
+| 50 | Smart quote double-wrapping in YAML frontmatter | pl #17445 | `summaryPoint1: ""text""` -- value had smart quotes `\u201C...\u201D`; `quoteFrontmatterNonAscii` saw non-ASCII, didn't recognize smart quotes as existing quoting, wrapped in straight quotes producing double-wrapping | Critical -- breaks YAML parsing |
+| 51 | Extra spaces around `=` in JSX attributes | pl #17445 | `<a href = "https://...">` -- Crowdin introduces spaces around `=` in href and other JSX attributes; no sanitizer function normalizes this | High -- may break strict MDX parsers |
+| 52 | Orphaned opening backtick with missing closer | pl #17445 | `` `<nazwa opcodu>(...). `` -- opening backtick with no closing backtick; `repairUnclosedBackticks` needs English comparison and may miss cases where English also has backticks but the translated line lost one | High -- exposed MDX tags |
+
 ## Patterns Already Handled by Sanitizer (Confirmed Working)
 
 These patterns are covered by existing fix functions and should have regression tests:
@@ -105,7 +110,10 @@ These patterns are covered by existing fix functions and should have regression
 - **Translated inline code warning** (`warnTranslatedInlineCode`) — warns when inline code span count drops significantly OR when orphaned backticks are detected on a line; signals Crowdin translated content inside backticks (pt-br PR #17122)
 - **LLM artifact token stripping** (`stripLlmArtifactTokens`) — strips `<bos>`, `<eos>`, `<s>`, `</s>`, `<pad>`, `<unk>`, `<mask>` tokens from prose; these leak from machine translation pipelines and break MDX compilation (mr PR #17730)
 - **Block HTML inline usage preserved** (`normalizeBlockHtmlLines`) — no longer splits `<div>content</div>` when both tags are on the same line; only splits multi-line block closing tags to their own line. Fixes MDX "Expected a closing tag before end of paragraph" error (id i18n/id-03-23T2228, pattern #46)
-- **Lowercased MDX component names** (`fixLowercasedMdxComponents`) — `<emoji>` → `<Emoji>` restores PascalCase from English source; translation pipelines occasionally lowercase custom component tags, and MDX component names are case-sensitive (de PR #17842, pattern #49)
+- **Lowercased MDX component names** (`fixLowercasedMdxComponents`) — `<emoji>` -> `<Emoji>` restores PascalCase from English source; translation pipelines occasionally lowercase custom component tags, and MDX component names are case-sensitive (de PR #17842, pattern #49)
+- **Orphaned closer-before-opener** (`removeOrphanedClosingTags`) — `</em><a>...<em>text</em>` now correctly removes the leading `</em>` even when open/close counts are equal on the line; uses left-to-right balance scanning instead of simple count comparison (pl PR #17445, pattern #50)
+- **Smart quote double-wrapping prevention** (`quoteFrontmatterNonAscii`) — replaces smart/curly quotes (U+201C/U+201D/U+201E/U+201F) with straight `"` before checking if YAML value needs quoting, preventing `""text""` double-wrapping (pl PR #17445, pattern #51)
+- **JSX attribute spacing** (`fixJsxAttributeSpacing`) — normalizes `href = "..."` to `href="..."` inside HTML/JSX tags; Crowdin sometimes introduces spaces around `=` in attributes (pl PR #17445, pattern #52)
 
 ## Recommendations for Future Sanitizer Iteration
 

public/content/translations/pl/developers/docs/consensus-mechanisms/pos/attestations/index.md

@@ -0,0 +1,92 @@
+---
+title: "Poświadczenia"
+description: "Opis zaświadczeń proof-of-stake na Ethereum."
+lang: pl
+---
+
+Od walidatora oczekuje się, że utworzy, podpisze i rozgłosi poświadczenie w każdej epoce. Na tej stronie opisano, jak wyglądają te poświadczenia oraz jak są przetwarzane i przekazywane między klientami konsensusu.
+
+## Czym jest poświadczenie? {#what-is-an-attestation}
+
+W każdej [epoce](/glossary/#epoch) (6,4 minuty) walidator proponuje sieci poświadczenie. Poświadczenie dotyczy określonego slotu w epoce. Celem poświadczenia jest zagłosowanie za widokiem łańcucha przez walidatora, w szczególności za ostatnim uzasadnionym blokiem i pierwszym blokiem w bieżącej epoce (znanymi jako punkty kontrolne `source` i `target`). Informacje te są łączone dla wszystkich uczestniczących walidatorów, umożliwiając sieci osiągnięcie konsensusu co do stanu łańcucha bloków.
+
+Poświadczenie zawiera następujące składniki:
+
+- `aggregation_bits`: lista bitowa walidatorów, w której pozycja odpowiada indeksowi walidatora w jego komitecie; wartość (0/1) wskazuje, czy walidator podpisał `dane` (tj. czy jest aktywny i zgadza się z proponującym blok)
+- `data`: szczegóły dotyczące poświadczenia, zdefiniowane poniżej
+- `signature`: podpis BLS, który agreguje podpisy poszczególnych walidatorów
+
+Pierwszym zadaniem walidatora poświadczającego jest zbudowanie `danych`. `Dane` zawierają następujące informacje:
+
+- `slot`: numer slotu, do którego odnosi się poświadczenie
+- `index`: numer identyfikujący komitet, do którego należy walidator w danym slocie
+- `beacon_block_root`: główny hasz bloku, który walidator widzi na czele łańcucha (wynik zastosowania algorytmu wyboru forka)
+- `source`: część głosowania w sprawie nieodwołalności, wskazująca, co walidatorzy postrzegają jako najnowszy uzasadniony blok
+- `target`: część głosowania w sprawie nieodwołalności, wskazująca, co walidatorzy postrzegają jako pierwszy blok w bieżącej epoce
+
+Po zbudowaniu `danych`, walidator może zmienić bit w `aggregation_bits` odpowiadający jego własnemu indeksowi walidatora z 0 na 1, aby pokazać, że brał udział.
+
+Na koniec walidator podpisuje poświadczenie i rozgłasza je w sieci.
+
+### Poświadczenie zagregowane {#aggregated-attestation}
+
+Przekazywanie tych danych w sieci dla każdego walidatora wiąże się ze znacznym narzutem. Dlatego poświadczenia od poszczególnych walidatorów są agregowane w podsieciach, zanim zostaną szerzej rozgłoszone. Obejmuje to agregowanie podpisów, tak aby rozgłaszane poświadczenie zawierało `dane` konsensusu i pojedynczy podpis utworzony przez połączenie podpisów wszystkich walidatorów, którzy zgadzają się z tymi `danymi`. Można to sprawdzić za pomocą `aggregation_bits`, ponieważ dostarcza to indeks każdego walidatora w jego komitecie (którego ID jest podane w `danych`), który można wykorzystać do odpytywania poszczególnych podpisów.
+
+W każdej epoce 16 walidatorów w każdej podsieci jest wybieranych na `agregatorów`. Agregatorzy zbierają wszystkie poświadczenia, o których usłyszą w sieci gossip, które mają `dane` równoważne z ich własnymi. Nadawca każdego pasującego poświadczenia jest zapisywany w `aggregation_bits`. Agregatorzy następnie rozgłaszają agregat poświadczeń do szerszej sieci.
+
+Gdy walidator zostaje wybrany na proponującego blok, pakuje zagregowane poświadczenia z podsieci aż do najnowszego slotu w nowym bloku.
+
+### Cykl życia włączenia poświadczenia {#attestation-inclusion-lifecycle}
+
+1. Generowanie
+2. Propagacja
+3. Agregacja
+4. Propagacja
+5. Włączenie
+
+Cykl życia poświadczenia jest przedstawiony na poniższym schemacie:
+
+![cykl życia poświadczenia](./attestation_schematic.png)
+
+## Nagrody {#rewards}
+
+Walidatorzy są nagradzani za przesyłanie poświadczeń. Nagroda za poświadczenie zależy od flag uczestnictwa (źródło, cel i głowa), nagrody podstawowej i wskaźnika uczestnictwa.
+
+Każda z flag uczestnictwa może mieć wartość „prawda” lub „fałsz”, w zależności od przesłanego poświadczenia i jego opóźnienia włączenia.
+
+Najlepszy scenariusz ma miejsce, gdy wszystkie trzy flagi mają wartość „prawda”, w którym to przypadku walidator zarobi (za każdą prawidłową flagę):
+
+`nagroda += nagroda podstawowa * waga flagi * wskaźnik poświadczania flagi / 64`
+
+Wskaźnik poświadczania flagi jest mierzony za pomocą sumy efektywnych sald wszystkich walidatorów poświadczających dla danej flagi w porównaniu z całkowitym aktywnym saldem efektywnym.
+
+### Nagroda podstawowa {#base-reward}
+
+Nagroda podstawowa jest obliczana na podstawie liczby walidatorów poświadczających i ich efektywnych sald stakowanego etheru:
+
+`nagroda podstawowa = efektywne saldo walidatora x 2^6 / SQRT(Efektywne saldo wszystkich aktywnych walidatorów)`
+
+#### Opóźnienie włączenia {#inclusion-delay}
+
+W momencie, gdy walidatorzy głosowali nad głową łańcucha (`blok n`), `blok n+1` nie został jeszcze zaproponowany. Dlatego poświadczenia są naturalnie włączane **jeden blok później**, więc wszystkie poświadczenia, które głosowały za tym, że `blok n` jest głową łańcucha, zostały włączone do `bloku n+1`, a **opóźnienie włączenia** wynosi 1. Jeśli opóźnienie włączenia podwoi się do dwóch slotów, nagroda za poświadczenie zmniejszy się o połowę, ponieważ do obliczenia nagrody za poświadczenie, nagroda podstawowa jest mnożona przez odwrotność opóźnienia włączenia.
+
+### Scenariusze poświadczeń {#attestation-scenarios}
+
+#### Brakujący walidator głosujący {#missing-voting-validator}
+
+Walidatorzy mają maksymalnie 1 epokę na przesłanie swojego poświadczenia. Jeśli poświadczenie zostało pominięte w epoce 0, mogą je przesłać z opóźnieniem włączenia w epoce 1.
+
+#### Brakujący agregator {#missing-aggregator}
+
+W sumie jest 16 agregatorów na epokę. Ponadto losowi walidatorzy subskrybują **dwie podsieci na 256 epok** i służą jako kopia zapasowa na wypadek braku agregatorów.
+
+#### Brakujący proponujący blok {#missing-block-proposer}
+
+Należy pamiętać, że w niektórych przypadkach szczęśliwy agregator może również stać się proponującym blok. Jeśli poświadczenie nie zostało włączone, ponieważ brakuje proponującego blok, następny proponujący blok pobierze zagregowane poświadczenie i włączy je do następnego bloku. Jednakże **opóźnienie włączenia** wzrośnie o jeden.
+
+## Dalsza lektura {#further-reading}
+
+- [Poświadczenia w specyfikacji konsensusu z adnotacjami Vitalika](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata)
+- [Poświadczenia w eth2book.info](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata)
+
+_Znasz jakieś zasoby społeczności, które Ci pomogły? Edytuj tę stronę i dodaj je!_

public/content/translations/pl/developers/docs/consensus-mechanisms/pos/block-proposal/index.md

@@ -0,0 +1,69 @@
+---
+title: Propozycja bloku
+description: "Wyjaśnienie, w jaki sposób bloki są proponowane w Ethereum z dowodem stawki."
+lang: pl
+---
+
+Bloki są podstawowymi jednostkami łańcucha bloków. Bloki są oddzielnymi jednostkami informacji, które są przekazywane między węzłami, uzgadniane i dodawane do bazy danych każdego węzła. Ta strona wyjaśnia, w jaki sposób są one produkowane.
+
+## Wymagania wstępne {#prerequisites}
+
+Proponowanie bloków jest częścią protokołu dowodu stawki. Aby lepiej zrozumieć tę stronę, zalecamy zapoznanie się z [dowodem stawki](/developers/docs/consensus-mechanisms/pos/) oraz [architekturą bloku](/developers/docs/blocks/).
+
+## Kto produkuje bloki? {#who-produces-blocks}
+
+Konta walidatorów proponują bloki. Konta walidatorów są zarządzane przez operatorów węzłów, którzy uruchamiają oprogramowanie walidatora jako część swoich klientów wykonawczych i klientów konsensusu oraz zdeponowali co najmniej 32 ETH w kontrakcie depozytowym. Jednak każdy walidator jest tylko od czasu do czasu odpowiedzialny za zaproponowanie bloku. Ethereum mierzy czas w slotach i epokach. Każdy slot trwa dwanaście sekund, a 32 sloty (6,4 minuty) tworzą jedną epokę. Każdy slot to okazja do dodania nowego bloku w Ethereum.
+
+### Losowy wybór {#random-selection}
+
+Pojedynczy walidator jest wybierany pseudolosowo do zaproponowania bloku w każdym slocie. W łańcuchu bloków nie ma czegoś takiego jak prawdziwa losowość, ponieważ gdyby każdy węzeł generował prawdziwie losowe liczby, nie mogłyby osiągnąć konsensusu. Zamiast tego celem jest uczynienie procesu wyboru walidatora nieprzewidywalnym. Losowość w Ethereum jest osiągana za pomocą algorytmu o nazwie RANDAO, który miesza hasz od proponenta bloku z ziarnem, które jest aktualizowane co blok. Ta wartość służy do wyboru określonego walidatora z całego zestawu walidatorów. Wybór walidatora jest ustalany z wyprzedzeniem dwóch epok jako sposób na ochronę przed niektórymi rodzajami manipulacji ziarnem.
+
+Chociaż walidatorzy dodają do RANDAO w każdym slocie, globalna wartość RANDAO jest aktualizowana tylko raz na epokę. Aby obliczyć indeks następnego proponenta bloku, wartość RANDAO jest mieszana z numerem slotu, aby dać unikalną wartość w każdym slocie. Prawdopodobieństwo wyboru pojedynczego walidatora nie wynosi po prostu `1/N` (gdzie `N` = całkowita liczba aktywnych walidatorów). Zamiast tego jest ono ważone efektywnym saldem ETH każdego walidatora. Maksymalne efektywne saldo wynosi 32 ETH (oznacza to, że `saldo < 32 ETH` prowadzi do niższej wagi niż `saldo == 32 ETH`, ale `saldo > 32 ETH` nie prowadzi do wyższej wagi niż `saldo == 32 ETH`).
+
+Tylko jeden proponent bloku jest wybierany w każdym slocie. W normalnych warunkach jeden producent bloku tworzy i publikuje pojedynczy blok w przeznaczonym dla niego slocie. Utworzenie dwóch bloków dla tego samego slotu jest wykroczeniem podlegającym slashingowi, często znanym jako „ekwiwokacja”.
+
+## Jak tworzony jest blok? {#how-is-a-block-created}
+
+Oczekuje się, że proponent bloku będzie rozgłaszał podpisany blok beacon, który jest budowany na ostatniej głowie łańcucha zgodnie z widokiem jego własnego, lokalnie uruchomionego algorytmu wyboru forka. Algorytm wyboru forka stosuje wszelkie poświadczenia w kolejce pozostałe z poprzedniego slotu, a następnie znajduje blok o największej skumulowanej wadze poświadczeń w swojej historii. Ten blok jest rodzicem nowego bloku utworzonego przez proponenta.
+
+Proponent bloku tworzy blok, zbierając dane z własnej lokalnej bazy danych i widoku łańcucha. Zawartość bloku pokazano w poniższym fragmencie kodu:
+
+```rust
+class BeaconBlockBody(Container):
+    randao_reveal: BLSSignature
+    eth1_data: Eth1Data
+    graffiti: Bytes32
+    proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
+    attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]
+    attestations: List[Attestation, MAX_ATTESTATIONS]
+    deposits: List[Deposit, MAX_DEPOSITS]
+    voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
+    sync_aggregate: SyncAggregate
+    execution_payload: ExecutionPayload
+```
+
+Pole `randao_reveal` przyjmuje weryfikowalną wartość losową, którą proponent bloku tworzy, podpisując numer bieżącej epoki. `eth1_data` to głos na widok kontraktu depozytowego przez proponenta bloku, w tym na root drzewa Merkle depozytów oraz całkowitą liczbę depozytów, które umożliwiają weryfikację nowych depozytów. `graffiti` to opcjonalne pole, które można wykorzystać do dodania wiadomości do bloku. `proposer_slashings` i `attester_slashings` to pola zawierające dowody na to, że niektórzy walidatorzy popełnili wykroczenia podlegające slashingowi, zgodnie z widokiem łańcucha przez proponenta. `deposits` to lista nowych depozytów walidatorów, o których wie proponent bloku, a `voluntary_exits` to lista walidatorów, którzy chcą wyjść, o których proponent bloku usłyszał w sieci plotek warstwy konsensusu. `sync_aggregate` to wektor pokazujący, którzy walidatorzy zostali wcześniej przypisani do komitetu synchronizacji (podzbioru walidatorów, którzy obsługują dane lekkiego klienta) i uczestniczyli w podpisywaniu danych.
+
+`execution_payload` umożliwia przekazywanie informacji o transakcjach między klientami wykonawczymi a klientami konsensusu. `execution_payload` to blok danych wykonawczych, który jest zagnieżdżony wewnątrz bloku beacon. Pola wewnątrz `execution_payload` odzwierciedlają strukturę bloku opisaną w Yellow Paper Ethereum, z tym wyjątkiem, że nie ma ommerów, a `prev_randao` istnieje w miejsce `difficulty`. Klient wykonawczy ma dostęp do lokalnej puli transakcji, o których usłyszał w swojej własnej sieci plotek. Transakcje te są wykonywane lokalnie w celu wygenerowania zaktualizowanego trie stanu, znanego jako post-state. Transakcje są zawarte w `execution_payload` jako lista o nazwie `transactions`, a post-state jest podany w polu `state-root`.
+
+Wszystkie te dane są gromadzone w bloku beacon, podpisywane i rozgłaszane do peerów proponenta bloku, którzy propagują je dalej do swoich peerów itd.
+
+Przeczytaj więcej o [anatomii bloków](/developers/docs/blocks).
+
+## Co dzieje się z blokiem? {#what-happens-to-blocks}
+
+Blok jest dodawany do lokalnej bazy danych proponenta bloku i rozgłaszany do peerów za pośrednictwem sieci plotek warstwy konsensusu. Gdy walidator otrzyma blok, weryfikuje dane w nim zawarte, w tym sprawdza, czy blok ma prawidłowego rodzica, odpowiada prawidłowemu slotowi, czy indeks proponenta jest zgodny z oczekiwaniami, czy ujawnienie RANDAO jest prawidłowe i czy proponent nie został poddany slashingowi. `execution_payload` jest rozpakowywany, a klient wykonawczy walidatora ponownie wykonuje transakcje z listy, aby sprawdzić proponowaną zmianę stanu. Zakładając, że blok przejdzie wszystkie te kontrole, każdy walidator dodaje blok do swojego własnego kanonicznego łańcucha. Następnie proces rozpoczyna się od nowa w następnym slocie.
+
+## Nagrody za blok {#block-rewards}
+
+Proponent bloku otrzymuje zapłatę za swoją pracę. Istnieje `base_reward`, która jest obliczana jako funkcja liczby aktywnych walidatorów i ich efektywnych sald. Proponent bloku otrzymuje następnie ułamek `base_reward` za każde prawidłowe poświadczenie zawarte w bloku; im więcej walidatorów poświadczy blok, tym większa nagroda dla proponenta bloku. Istnieje również nagroda za zgłaszanie walidatorów, którzy powinni zostać poddani slashingowi, równa `1/512 * efektywne saldo` za każdego walidatora poddanego slashingowi.
+
+[Więcej o nagrodach i karach](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)
+
+## Dalsza lektura {#further-reading}
+
+- [Wprowadzenie do bloków](/developers/docs/blocks/)
+- [Wprowadzenie do proof-of-stake](/developers/docs/consensus-mechanisms/pos/)
+- [Specyfikacje konsensusu Ethereum](https://github.com/ethereum/consensus-specs)
+- [Wprowadzenie do Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)
+- [Aktualizacja Ethereum](https://eth2book.info/)