Kdo se může zúčastnit?
+ Každý, komu je více než 18 let, je rodilým mluvčím alespoň jednoho jiného jazyka než angličtiny a ovládá angličtinu. +Musím být překladatel?
+ Ne. Stačí být bilingvní a navrhovat lidské překlady (používání strojového překladu je zakázáno!) podle svých nejlepších schopností, žádné odborné zkušenosti nejsou vyžadovány. +Kolik času musím věnovat?
+ Kolik jen chcete. Minimální hranice pro nárok na ceny je 1 000 přeložených slov, což by mělo zabrat asi 2 hodiny. Soutěž o nejvyšší ceny bude vyžadovat větší časové nasazení. +Musím se vyznat v Ethereu?
+ Ne. Znalost Etherea sice může pomoci s produktivitou a kvalitou, ale Translaton je také příležitost se učit a všichni jsou zváni, aby se zúčastnili a během účasti se o Ethereu dozvěděli více. +`nonce``
-`` – _otevírací tag, který obsahuje úryvek kódu_
+`` – _Otevírací značka, která obsahuje úryvek kódu_
-nonce – _text, který není určen k překladu_
+nonce – _Nepřeložitelný text_
-`` – _zavírací tag_
+`` – _Zavírací značka_
Zdrojový text také obsahuje zkrácené tagy, které obsahují pouze čísla, což znamená, že jejich funkce není okamžitě zřejmá. Můžete na tyto tagy najet kurzorem, abyste přesně zjistili, jakou funkci plní.
-V příkladu níže můžete vidět, že když najedete kurzorem na tag \<0> , zobrazí se, že představuje `` a obsahuje úryvek kódu, takže obsah uvnitř těchto tagů by neměl být přeložen.
+V níže uvedeném příkladu můžete vidět, že když najedete kurzorem na značku `<0>`, zobrazí se, že představuje `` a obsahuje úryvek kódu, proto by se obsah uvnitř těchto značek neměl překládat.
-
+
-## Krátké versus plné formy nebo zkratky {#short-vs-full-forms}
+## Krátké vs. plné tvary / zkratky {#short-vs-full-forms}
Na webových stránkách se používá mnoho zkratek, např. dapps, NFT, DAO, DeFi atd. Tyto zkratky jsou běžně používány v angličtině a většina návštěvníků webu je s nimi obeznámena.
@@ -168,9 +174,9 @@ Tyto zkratky nepřekládejte, protože většina lidí by jim nerozuměla a loka
Příklad, jak přeložit dapps:
-- Decentralized applications (dapps) → _přeložená plná forma (anglická zkratka v závorkách)_
+- Decentralized applications (dapps) → _Přeložený plný tvar (anglická zkratka v závorce)_
-## Termíny bez zavedených překladů {#terms-without-established-translations}
+## Pojmy bez zavedených překladů {#terms-without-established-translations}
Některé termíny nemusí mít zavedené překlady v jiných jazycích a jsou široce známé pod původním anglickým termínem. Tyto termíny většinou zahrnují novější koncepty, jako je proof-of-work, proof-of-stake, Beacon Chain, staking atd.
@@ -190,7 +196,7 @@ Překlady tlačítek by měly být co nejkratší, aby se zabránilo problémům
-## Překládání s ohledem na inkluzivitu {#translating-for-inclusivity}
+## Překlad s ohledem na inkluzivitu {#translating-for-inclusivity}
Návštěvníci ethereum.org pocházejí z celého světa a z různých prostředí. Jazyk na webu by proto měl být neutrální, přívětivý ke všem a ne vylučující.
@@ -200,7 +206,7 @@ Další formou inkluzivity je snaha překládat pro globální publikum, nikoli
Jazyk by měl být vhodný pro všechna publika a věkové kategorie.
-## Jazykově specifické překlady {#language-specific-translations}
+## Překlady specifické pro daný jazyk {#language-specific-translations}
Při překládání je důležité dodržovat gramatická pravidla, konvence a formátování používané ve vašem jazyce, na rozdíl od kopírování ze zdroje. Zdrojový text se řídí anglickými gramatickými pravidly a konvencemi, což není použitelné pro mnoho jiných jazyků.
@@ -229,7 +235,7 @@ Některé příklady toho, na co být obzvláště opatrní:
- Každý jazyk má rozmanitý a složitý soubor pravidel pro psaní seznamů. Tato pravidla mohou být výrazně odlišná od angličtiny.
- V některých jazycích je první slovo každé nové položky seznamu třeba psát s velkým písmenem, zatímco v jiných jazycích by nové položky měly začínat malým písmenem. Mnoho jazyků má také různá pravidla pro psaní velkých písmen v seznamech, která závisí na délce každé položky.
-- Totéž platí pro interpunkci jednotlivých položek seznamu. Závěrečná interpunkce v seznamech může být tečka (**.**), čárka (**,**) nebo středník (**;**), v závislosti na jazyce.
+- Totéž platí pro interpunkci jednotlivých položek seznamu. Koncová interpunkce v seznamech může být tečka (**.**), čárka (**,**) nebo středník (**;**), v závislosti na jazyce.
**Uvozovky**
@@ -256,7 +262,7 @@ Některé příklady toho, na co být obzvláště opatrní:
- Angličtina – **1,000.50**
- Španělština – **1.000,50**
- Francouzština – **1 000,50**
-- Dalším důležitým faktorem při překladu čísel je procentní znak. Ten může být psán různými způsoby: **100%**, **100 %** nebo **%100**.
+- Dalším důležitým faktorem při překladu čísel je procentní znak. Lze jej zapsat různými způsoby: **100%**, **100 %** nebo **%100**.
- Záporná čísla mohou být zobrazena různě, v závislosti na jazyce: -100, 100-, (100) nebo [100].
**Data**
diff --git a/public/content/translations/cs/dao/index.md b/public/content/translations/cs/dao/index.md
index d4d54e2a446..6c4dfb77b90 100644
--- a/public/content/translations/cs/dao/index.md
+++ b/public/content/translations/cs/dao/index.md
@@ -19,7 +19,7 @@ DAO je kolektivně vlastněná organizace sloužící k dosažení společně vy
DAO nám umožňují pracovat s podobně smýšlejícími lidmi po celém světě, aniž bychom věřili benevolentnímu lídrovi, aby spravoval finanční prostředky nebo operace. Není zde žádný výkonný ředitel, který by rozmarně utrácel peníze nebo výkonný finanční ředitel, který by mohl manipulovat s rozvahou firmy. Namísto toho jsou do kódu zavedena pravidla založená na blockchainu, která definují, jak organizace funguje a jak je s finančními prostředky vynaloženo.
-Mají zabudované pokladny, do kterých nikdo nemá přístup bez souhlasu skupiny. Rozhodnutí se řídí návrhy a hlasováním, což zajišťuje, že každý člen organizace má možnost vyjádřit svůj názor. To vše se díky blockchainovým technologiím odehrává [on-chain](/glossary/#on-chain) a naprosto transparentně.
+Mají zabudované pokladny, do kterých nikdo nemá přístup bez souhlasu skupiny. Rozhodnutí se řídí návrhy a hlasováním, aby se zajistilo, že každý v organizaci bude mít svůj hlas a vše probíhá transparentně [na blockchainu](/glossary/#onchain).
## Proč potřebujeme DAO? {#why-dao}
@@ -29,27 +29,27 @@ Tento princip tak otevírá mnoho nových příležitostí ke globální spolupr
### Srovnání {#dao-comparison}
-| Decentralizovaná Autonomní Organizace | Tradiční organizace |
-| ---------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
-| Obvykle má horizontální strukturu a je plně demokratická. | Obvykle má hierarchickou strukturu. |
-| Veškeré plánované změny vyžadují členské hlasování. | V závislosti na struktuře se změny dějí buď pomocí hlasování nebo rozhodnutím členů s výhraním právem. |
-| Výsledky hlasování jsou zpracovávané automaticky bez nutnosti důvěryhodného prostředníka. | Pokud je hlasování povoleno, je vyřizováno ručně a výsledek je zpracováván interně. |
+| DAO | Tradiční organizace |
+| --------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
+| Obvykle má horizontální strukturu a je plně demokratická. | Obvykle má hierarchickou strukturu. |
+| Veškeré plánované změny vyžadují členské hlasování. | V závislosti na struktuře se změny dějí buď pomocí hlasování nebo rozhodnutím členů s výhraním právem. |
+| Výsledky hlasování jsou zpracovávané automaticky bez nutnosti důvěryhodného prostředníka. | Pokud je hlasování povoleno, je vyřizováno ručně a výsledek je zpracováván interně. |
| Služby jsou řízeny automatickým a decentralizovaným způsobem (například distribuce filantropických fondů). | Vyžaduje lidskou manipulaci nebo centrálně řízenou automatizaci náchylnou k falšování. |
-| Veškerá činnost je transparentní a zcela veřejná. | Aktivity jsou obvykle soukromé a skryté před veřejností. |
+| Veškerá činnost je transparentní a zcela veřejná. | Aktivity jsou obvykle soukromé a skryté před veřejností. |
### Příklady DAO {#dao-examples}
Několik příkladů, k čemu je možné DAO využít:
- **Charitativní organizace** – můžete přijímat dary od kohokoliv na světě a hlasovat o tom, které projekty budou s jejich pomocí financovány.
-- **Kolektivní vlastnictví** – jako DAO můžete zakoupit fyzická či digitální aktiva a nechat vaše členy hlasovat o tom, jak s nimi naložit.
-- **Fondy a granty** – můžete vytvořit fond rizikového kapitálu, který sdružuje investiční kapitál a nechat členy DAO organizace hlasovat o projektech, které podpoří. Splacené peníze mohou být později přerozděleny mezi členy DAO.
+- **Kolektivní vlastnictví** – můžete zakoupit fyzická či digitální aktiva a členové mohou hlasovat o tom, jak je používat.
+- **Podnikatelské záměry a granty** – můžete vytvořit fond rizikového kapitálu, který sdružuje investiční kapitál, a hlasovat o tom, které záměry podpoříte. Splacené peníze mohou být později přerozděleny mezi členy DAO.
@@ -61,11 +62,11 @@ Na tom Ethereum staví. Stejně jako u Bitcoinu se pravidla nemohou změnit a p
## Programovatelné peníze {#programmable-money}
-Zní to zvláštně... "Proč bych chtěl programovat své peníze"? Toto je však více než výchozí funkce tokenů na Ethereu. Každý může naprogramovat logiku do plateb. Takže můžete získat kontrolu a bezpečnost Bitcoinu v kombinaci se službami poskytovanými finančními institucemi. Díky tomu můžete s kryptoměnami dělat věci, které s Bitcoinem dělat nemůžete, jako je půjčování a vypůjčování, plánování plateb, investování do indexových fondů a další.
+To zní divně... „proč bych si chtěl/a programovat peníze“? Toto je však více než jen výchozí funkce tokenů na Ethereu. Každý může naprogramovat logiku do plateb. Takže můžete získat kontrolu a bezpečnost Bitcoinu v kombinaci se službami poskytovanými finančními institucemi. Díky tomu můžete s kryptoměnami dělat věci, které s Bitcoinem dělat nemůžete, jako je půjčování a vypůjčování, plánování plateb, investování do indexových fondů a další.
+
Prozkoumejte naše návrhy pro DeFi aplikace a vyzkoušet je, pokud jste v Ethereu noví.
Objevte DeFi aplikace
@@ -77,8 +78,8 @@ Zní to zvláštně... "Proč bych chtěl programovat své peníze"? Toto je vš
Existuje decentralizovaná alternativa k většině finančních služeb. Ethereum však také vytváří příležitosti pro vytváření finančních produktů, které jsou zcela nové. Toto je stále rostoucí seznam.
-- [Posílat peníze napříč zeměkoulí](#send-money)
-- [Streamovat peníze napříč zeměkoulí](#stream-money)
+- [Posílat peníze po celém světě](#send-money)
+- [Streamovat peníze po celém světě](#stream-money)
- [Pracovat se stabilními měnami](#stablecoins)
- [Vypůjčit si finanční prostředky se zajištěním](#lending)
- [Půjčovat si bez zajištění](#flash-loans)
@@ -86,14 +87,14 @@ Existuje decentralizovaná alternativa k většině finančních služeb. Ethere
- [Obchodovat s tokeny](#swaps)
- [Rozšířit své portfolio](#investing)
- [Financovat své nápady](#crowdfunding)
-- [Zakoupit pojištění](#insurance)
+- [Koupit si pojištění](#insurance)
- [Spravovat své portfolio](#aggregators)
Zobrazit platební dappky
@@ -103,11 +104,11 @@ Protože je Ethereum blockchain, je navržen pro zasílání bezpečných a celo
Můžete také streamovat peníze přes Ethereum. To vám umožní vyplatit někomu jejich plat za pouhou vteřinu a umožnit jim přístup k jejich penězům, kdykoli bude potřeba. Nebo si za vteřinu něco pronajmout, jako třeba úložnou skříňku nebo elektrický skútr.
-A pokud nechcete posílat nebo streamovat [ETH](/glossary/#ether) kvůli tomu, jak moc se může měnit jeho hodnota, existují na Ethereu alternativní měny: [stablecoiny](/glossary/#stablecoin).
+A pokud nechcete posílat nebo streamovat [ETH](/glossary/#ether), protože se jeho hodnota může výrazně měnit, na Ethereu existují alternativní měny: [stablecoiny](/glossary/#stablecoin).
@@ -210,7 +211,7 @@ Výherní fond je tvořen všemi úroky z půjčování vkladů lístků jako v
Zobrazit investiční dappky
@@ -246,7 +247,7 @@ Dobrým příkladem je fond [DeFi Pulse Index (DPI)](https://defipulse.com/blog/
Zobrazit dappky na pojištění
@@ -289,7 +290,7 @@ Ethereum produkty, stejně jako ostatní software, mohou trpět chybami a zneuž
-## Další informace {#further-reading}
+## Další čtení {#further-reading}
-### DeFi data {#defi-data}
+### Data o DeFi {#defi-data}
- [DeFi Prime](https://defiprime.com/)
- [DeFi Llama](https://defillama.com/)
-### DeFi články {#defi-articles}
+### Články o DeFi {#defi-articles}
- [Průvodce DeFi pro začátečníky](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu, 6. ledna 2020_
+- [Pokyny EEA pro posuzování rizik DeFi](https://entethalliance.org/specs/defi-risks/) – Přehled podporovaný odvětvím o tom, jak identifikovat a posuzovat klíčová rizika v protokolech DeFi.
### Videa {#videos}
-- [Finematics – decentralizované finanční vzdělávání](https://finematics.com/) – _Videa o DeFi_
-- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) – _Základy DeFi: Vše, co potřebujete vědět, abyste mohli začít v tomto občas matoucím prostoru._
+- [Finematics – vzdělávání v oblasti decentralizovaných financí](https://finematics.com/) – _videa o DeFi_
+- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) – _Základy DeFi: Vše, co potřebujete vědět, abyste mohli začít v tomto občas matoucím světě._
- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) _Co je to DeFi?_
### Komunity {#communities}
-- [Server DeFi Llama na Discordu](https://discord.defillama.com/)
-- [Server DeFi Pulse na Discordu](https://discord.gg/Gx4TCTk)
+- [Discord server DeFi Llama](https://discord.defillama.com/)
+- [Discord server DeFi Pulse](https://discord.gg/Gx4TCTk)
+> clef newaccount --keystore
-Please enter a password for the new account to be created:
->
+Zadejte prosím heslo pro nově vytvářený účet:
+>
------------
-INFO [10-28|16:19:09.156] Your new key was generated address=0x5e97870f263700f46aa00d967821199b9bc5a120
-WARN [10-28|16:19:09.306] Please backup your key file path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120
-WARN [10-28|16:19:09.306] Please remember your password!
-Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120
+INFO [10-28|16:19:09.156] Váš nový klíč byl vygenerován adresa=0x5e97870f263700f46aa00d967821199b9bc5a120
+WARN [10-28|16:19:09.306] Zálohujte si prosím soubor s klíčem cesta=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120
+WARN [10-28|16:19:09.306] Zapamatujte si prosím své heslo!
+Vygenerován účet 0x5e97870f263700f46aa00d967821199b9bc5a120
```
[Dokumentace Geth](https://geth.ethereum.org/docs)
-Z privátního klíče lze odvodit nové veřejné klíče, ale privátní klíč z veřejných klíčů odvodit nelze. To znamená, že je nezbytné uchovávat privátní klíč v bezpečí a, jak název napovídá, v **SOUKROMÍ**.
+Z privátního klíče lze odvodit nové veřejné klíče, ale privátní klíč z veřejných klíčů odvodit nelze. Je nezbytné uchovávat své privátní klíče v bezpečí a, jak název napovídá, **PRIVÁTNÍ**.
Privátní klíč potřebujete k podepisování zpráv a transakcí, jejichž výstupem je podpis. Ostatní pak mohou na základě tohoto podpisu odvodit váš veřejný klíč a ověřit si tak autora zprávy. V aplikaci můžete k odesílání transakcí do sítě použít JavaScriptovou knihovnu.
@@ -110,7 +111,7 @@ Adresa kontraktu je obvykle přidělena při prvním spuštění kontraktu na bl
V Ethereu existuje také další typ klíče, který byl zaveden při přechodu Etherea z konsenzu založeného na důkazu prací na důkaz podílem. Jedná se o tzv. „BLS“ klíče, které slouží k identifikaci validátorů. Tyto klíče mohou být efektivně sdružovány, což snižuje sířku pásma potřebnou k dosažení konsenzu v síti. Bez této agregace by byla minimální uzamčená částka pro validátora mnohem vyšší.
-[Další informace o klíčích validátorů](/developers/docs/consensus-mechanisms/pos/keys/).
+[Více o klíčích validátorů](/developers/docs/consensus-mechanisms/pos/keys/).
## Poznámka k peněženkám {#a-note-on-wallets}
@@ -124,9 +125,9 @@ Podívejte se na video, kde Austin ukazuje, jak fungují hashovací funkce a pá
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+Žádná
+
+**Návratová hodnota**
+
+Přesná návratová data se liší mezi implementacemi klientů. Všichni klienti vracejí `False`, když se uzel nesynchronizuje, a všichni klienti vracejí následující pole.
+
+`Object|Boolean`, Objekt s daty o stavu synchronizace nebo `FALSE`, když nesynchronizuje:
+
+- `startingBlock`: `QUANTITY` – blok, u kterého import začal (resetuje se pouze po dosažení hlavičky synchronizace)
+- `currentBlock`: `QUANTITY` – aktuální blok, stejné jako eth_blockNumber
+- `highestBlock`: `QUANTITY` – odhadovaný nejvyšší blok
+
+Individuální klienti mohou také poskytovat další data. Například Geth vrací následující:
+
+```json
+{
+ "jsonrpc": "2.0",
+ "id": 1,
+ "result": {
+ "currentBlock": "0x3cf522",
+ "healedBytecodeBytes": "0x0",
+ "healedBytecodes": "0x0",
+ "healedTrienodes": "0x0",
+ "healingBytecode": "0x0",
+ "healingTrienodes": "0x0",
+ "highestBlock": "0x3e0e41",
+ "startingBlock": "0x3cbed5",
+ "syncedAccountBytes": "0x0",
+ "syncedAccounts": "0x0",
+ "syncedBytecodeBytes": "0x0",
+ "syncedBytecodes": "0x0",
+ "syncedStorage": "0x0",
+ "syncedStorageBytes": "0x0"
+ }
+}
+```
+
+Zatímco Besu vrací:
+
+```json
+{
+ "jsonrpc": "2.0",
+ "id": 51,
+ "result": {
+ "startingBlock": "0x0",
+ "currentBlock": "0x1518",
+ "highestBlock": "0x9567a3",
+ "pulledStates": "0x203ca",
+ "knownStates": "0x200636"
+ }
+}
+```
+
+Další podrobnosti naleznete v dokumentaci pro vašeho konkrétního klienta.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": {
+ startingBlock: '0x384',
+ currentBlock: '0x386',
+ highestBlock: '0x454'
+ }
+}
+// Or when not syncing
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": false
+}
+```
+
+### eth_coinbase {#eth_coinbase}
+
+Vrátí klientskou adresu coinbase.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+> **Poznámka:** Tato metoda je od verze **v1.14.0** zastaralá a již není podporována. Pokus o použití této metody bude mít za následek chybu „Metoda není podporována“.
+
+**Parametry**
+
+Žádná
+
+**Návratová hodnota**
+
+`DATA`, 20 bajtů – aktuální coinbase adresa.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":64}'
+// Result
+{
+ "id":64,
+ "jsonrpc": "2.0",
+ "result": "0x407d73d8a49eeb85d32cf465507dd71d507100c1"
+}
+```
+
+### eth_chainId {#eth_chainId}
+
+Vrátí ID řetězce používané pro podepisování transakcí chráněných proti opakování.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+Žádná
+
+**Návratová hodnota**
+
+`chainId`, šestnáctková hodnota jako řetězec představující celé číslo ID aktuálního řetězce.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67}'
+// Result
+{
+ "id":67,
+ "jsonrpc": "2.0",
+ "result": "0x1"
+}
+```
+
+### eth_mining {#eth_mining}
+
+Vrátí `true`, pokud klient aktivně těží nové bloky. Toto může vrátit `true` pouze pro sítě proof-of-work a v některých klientech nemusí být po [sloučení](/roadmap/merge/) k dispozici.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+Žádná
+
+**Návratová hodnota**
+
+`Boolean` – vrátí `true`, pokud klient těží, jinak `false`.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}'
+//
+{
+ "id":71,
+ "jsonrpc": "2.0",
+ "result": true
+}
+```
+
+### eth_hashrate {#eth_hashrate}
+
+Vrátí počet hashů za sekundu, se kterými uzel těží. Toto může vrátit `true` pouze pro sítě proof-of-work a v některých klientech nemusí být po [sloučení](/roadmap/merge/) k dispozici.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+Žádná
+
+**Návratová hodnota**
+
+`QUANTITY` – počet hašů za sekundu.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":71}'
+// Result
+{
+ "id":71,
+ "jsonrpc": "2.0",
+ "result": "0x38a"
+}
+```
+
+### eth_gasPrice {#eth_gasprice}
+
+Vrací odhad aktuální ceny za palivo v jednotkách wei. Například klient Besu zkoumá posledních 100 bloků a vrací mediánovou cenu za jednotku paliva ve výchozím nastavení.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+Žádná
+
+**Návratová hodnota**
+
+`QUANTITY` – celé číslo aktuální ceny gasu ve wei.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}'
+// Result
+{
+ "id":73,
+ "jsonrpc": "2.0",
+ "result": "0x1dfd14000" // 8049999872 Wei
+}
+```
+
+### eth_accounts {#eth_accounts}
+
+Vrátí seznam adres, které klient vlastní.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+Žádná
+
+**Návratová hodnota**
+
+`Pole DATA`, 20 bajtů – adresy vlastněné klientem.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": ["0x407d73d8a49eeb85d32cf465507dd71d507100c1"]
+}
+```
+
+### eth_blockNumber {#eth_blocknumber}
+
+Vrací číslo nejnovějšího bloku.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+Žádná
+
+**Návratová hodnota**
+
+`QUANTITY` – celé číslo aktuálního čísla bloku, na kterém se klient nachází.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}'
+// Result
+{
+ "id":83,
+ "jsonrpc": "2.0",
+ "result": "0x4b7" // 1207
+}
+```
+
+### eth_getBalance {#eth_getbalance}
+
+Vrací zůstatek účtu na dané adrese.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `DATA`, 20 bajtů – adresa pro kontrolu zůstatku.
+2. `QUANTITY|TAG` – celé číslo bloku nebo řetězec `"latest"`, `"earliest"`, `"pending"`, `"safe"` nebo `"finalized"`, viz [parametr bloku](/developers/docs/apis/json-rpc/#block-parameter)
+
+```js
+params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"]
+```
+
+**Návratová hodnota**
+
+`QUANTITY` – celé číslo aktuálního zůstatku ve wei.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x0234c8a3397aab58" // 158972490234375000
+}
+```
+
+### eth_getStorageAt {#eth_getstorageat}
+
+Vrátí hodnotu z pozice v úložišti na dané adrese.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `DATA`, 20 bajtů – adresa úložiště.
+2. `QUANTITY` – celé číslo pozice v úložišti.
+3. `QUANTITY|TAG` – celé číslo bloku nebo řetězec `"latest"`, `"earliest"`, `"pending"`, `"safe"`, `"finalized"`, viz [parametr bloku](/developers/docs/apis/json-rpc/#block-parameter)
+
+**Návratová hodnota**
+
+`DATA` – hodnota na této pozici v úložišti.
+
+**Příklad**
+Výpočet správné pozice závisí na úložišti, které se má načíst. Zvažte následující kontrakt nasazený na adrese `0x295a70b2de5e3953354a6a8344e616ed314d7251` adresou `0x391694e7e0b0cce554cb130d723a9d27458f9298`.
+
+```
+contract Storage {
+ uint pos0;
+ mapping(address => uint) pos1;
+ constructor() {
+ pos0 = 1234;
+ pos1[msg.sender] = 5678;
+ }
+}
+```
+
+Získání hodnoty pos0 je přímočaré:
+
+```js
+curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
+{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"}
+```
+
+Načtení prvku mapy je obtížnější. Pozice prvku v mapě se vypočítá pomocí:
+
+```js
+keccak(LeftPad32(key, 0), LeftPad32(map position, 0))
+```
+
+To znamená, že pro načtení úložiště na pos1["0x391694e7e0b0cce554cb130d723a9d27458f9298"] musíme vypočítat pozici pomocí:
+
+```js
+keccak(
+ decodeHex(
+ "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" +
+ "0000000000000000000000000000000000000000000000000000000000000001"
+ )
+)
+```
+
+Konzole Geth, která je dodávána s knihovnou web3, může být použita k provedení výpočtu:
+
+```js
+> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"
+undefined
+> web3.sha3(key, {"encoding": "hex"})
+"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9"
+```
+
+Nyní načteme úložiště:
+
+```js
+curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545
+{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"}
+```
+
+### eth_getTransactionCount {#eth_gettransactioncount}
+
+Vrátí počet transakcí _odeslaných_ z adresy.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `DATA`, 20 bajtů – adresa.
+2. `QUANTITY|TAG` – celé číslo bloku nebo řetězec `"latest"`, `"earliest"`, `"pending"`, `"safe"` nebo `"finalized"`, viz [parametr bloku](/developers/docs/apis/json-rpc/#block-parameter)
+
+```js
+params: [
+ "0x407d73d8a49eeb85d32cf465507dd71d507100c1",
+ "latest", // stav v posledním bloku
+]
+```
+
+**Návratová hodnota**
+
+`QUANTITY` - celé číslo udávající počet transakcí odeslaných z této adresy.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1","latest"],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x1" // 1
+}
+```
+
+### eth_getBlockTransactionCountByHash {#eth_getblocktransactioncountbyhash}
+
+Vrátí počet transakcí v bloku, který odpovídá danému haši bloku.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `DATA`, 32 bajtů – haš bloku
+
+```js
+params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"]
+```
+
+**Návratová hodnota**
+
+`QUANTITY` – celé číslo počtu transakcí v tomto bloku.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHash","params":["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x8b" // 139
+}
+```
+
+### eth_getBlockTransactionCountByNumber {#eth_getblocktransactioncountbynumber}
+
+Vrátí počet transakcí v bloku odpovídajícím danému číslu bloku.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `QUANTITY|TAG` – celé číslo čísla bloku nebo řetězec `"earliest"`, `"latest"`, `"pending"`, `"safe"` nebo `"finalized"`, jako v [parametru bloku](/developers/docs/apis/json-rpc/#block-parameter).
+
+```js
+params: [
+ "0x13738ca", // 20396234
+]
+```
+
+**Návratová hodnota**
+
+`QUANTITY` – celé číslo počtu transakcí v tomto bloku.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNumber","params":["0x13738ca"],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x8b" // 139
+}
+```
+
+### eth_getUncleCountByBlockHash {#eth_getunclecountbyblockhash}
+
+Vrátí počet strýčkovských bloků v bloku odpovídajícím danému haši bloku.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `DATA`, 32 bajtů – haš bloku
+
+```js
+params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"]
+```
+
+**Návratová hodnota**
+
+`QUANTITY` – celé číslo počtu strýčkovských bloků v tomto bloku.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x1" // 1
+}
+```
+
+### eth_getUncleCountByBlockNumber {#eth_getunclecountbyblocknumber}
+
+Vrátí počet strýčkovských bloků v bloku odpovídajícím danému číslu bloku.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `QUANTITY|TAG` – celé číslo čísla bloku nebo řetězec `"latest"`, `"earliest"`, `"pending"`, `"safe"` nebo `"finalized"`, viz [parametr bloku](/developers/docs/apis/json-rpc/#block-parameter)
+
+```js
+params: [
+ "0xe8", // 232
+]
+```
+
+**Návratová hodnota**
+
+`QUANTITY` – celé číslo počtu strýčkovských bloků v tomto bloku.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber","params":["0xe8"],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x0" // 0
+}
+```
+
+### eth_getCode {#eth_getcode}
+
+Vrátí kód na dané adrese.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `DATA`, 20 bajtů – adresa
+2. `QUANTITY|TAG` – celé číslo bloku nebo řetězec `"latest"`, `"earliest"`, `"pending"`, `"safe"` nebo `"finalized"`, viz [parametr bloku](/developers/docs/apis/json-rpc/#block-parameter)
+
+```js
+params: [
+ "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2",
+ "0x5daf3b", // 6139707
+]
+```
+
+**Návratová hodnota**
+
+`DATA` – kód z dané adresy.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", "0x5daf3b"],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x6060604052600436106100af576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146100b9578063095ea7b31461014757806318160ddd146101a157806323b872dd146101ca5780632e1a7d4d14610243578063313ce5671461026657806370a082311461029557806395d89b41146102e2578063a9059cbb14610370578063d0e30db0146103ca578063dd62ed3e146103d4575b6100b7610440565b005b34156100c457600080fd5b6100cc6104dd565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561010c5780820151818401526020810190506100f1565b50505050905090810190601f1680156101395780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561015257600080fd5b610187600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061057b565b604051808215151515815260200191505060405180910390f35b34156101ac57600080fd5b6101b461066d565b6040518082815260200191505060405180910390f35b34156101d557600080fd5b610229600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061068c565b604051808215151515815260200191505060405180910390f35b341561024e57600080fd5b61026460048080359060200190919050506109d9565b005b341561027157600080fd5b610279610b05565b604051808260ff1660ff16815260200191505060405180910390f35b34156102a057600080fd5b6102cc600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610b18565b6040518082815260200191505060405180910390f35b34156102ed57600080fd5b6102f5610b30565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561033557808201518184015260208101905061031a565b50505050905090810190601f1680156103625780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561037b57600080fd5b6103b0600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091908035906020019091905050610bce565b604051808215151515815260200191505060405180910390f35b6103d2610440565b005b34156103df57600080fd5b61042a600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610be3565b6040518082815260200191505060405180910390f35b34600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055503373ffffffffffffffffffffffffffffffffffffffff167fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c346040518082815260200191505060405180910390a2565b60008054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156105735780601f1061054857610100808354040283529160200191610573565b820191906000526020600020905b81548152906001019060200180831161055657829003601f168201915b505050505081565b600081600460003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b60003073ffffffffffffffffffffffffffffffffffffffff1631905090565b600081600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054101515156106dc57600080fd5b3373ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff16141580156107b457507fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205414155b156108cf5781600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541015151561084457600080fd5b81600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055505b81600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000206000828254039250508190555081600360008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205410151515610a2757600080fd5b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055503373ffffffffffffffffffffffffffffffffffffffff166108fc829081150290604051600060405180830381858888f193505050501515610ab457600080fd5b3373ffffffffffffffffffffffffffffffffffffffff167f7fcf532c15f0a6db0bd6d0e038bea71d30d808c7d98cb3bf7268a95bf5081b65826040518082815260200191505060405180910390a250565b600260009054906101000a900460ff1681565b60036020528060005260406000206000915090505481565b60018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610bc65780601f10610b9b57610100808354040283529160200191610bc6565b820191906000526020600020905b815481529060010190602001808311610ba957829003601f168201915b505050505081565b6000610bdb33848461068c565b905092915050565b60046020528160005260406000206020528060005260406000206000915091505054815600a165627a7a72305820deb4c2ccab3c2fdca32ab3f46728389c2fe2c165d5fafa07661e4e004f6c344a0029"
+}
+```
+
+### eth_sign {#eth_sign}
+
+Metoda podpisu vypočítá specifický podpis Etherea pomocí: `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`.
+
+Přidáním předpony ke zprávě je vypočtený podpis rozpoznatelný jako specifický podpis Etherea. Tím se zabrání zneužití, kdy může škodlivá dapp podepsat libovolná data (např. transakci) a použít podpis k tomu, aby se vydávala za oběť.
+
+Poznámka: adresa, kterou se má podepsat, musí být odemčena.
+
+**Parametry**
+
+1. `DATA`, 20 bajtů – adresa
+2. `DATA`, N bajtů – zpráva k podepsání
+
+**Návratová hodnota**
+
+`DATA`: Podpis
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "0xdeadbeaf"],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b"
+}
+```
+
+### eth_signTransaction {#eth_signtransaction}
+
+Podepíše transakci, kterou lze později odeslat do sítě pomocí [eth_sendRawTransaction](#eth_sendrawtransaction).
+
+**Parametry**
+
+1. `Object` – objekt transakce
+
+- `type`:
+- `from`: `DATA`, 20 bajtů – adresa, ze které je transakce odeslána.
+- `to`: `DATA`, 20 bajtů – (volitelné při vytváření nového kontraktu) adresa, na kterou je transakce směrována.
+- `gas`: `QUANTITY` – (volitelné, výchozí: 90000) celé číslo gasu poskytnutého pro provedení transakce. Vrátí nevyužitý gas.
+- `gasPrice`: `QUANTITY` – (volitelné, výchozí: bude určeno) celé číslo ceny gasPrice použité pro každý zaplacený gas, ve Wei.
+- `value`: `QUANTITY` – (volitelné) celé číslo hodnoty odeslané s touto transakcí, ve Wei.
+- `data`: `DATA` – zkompilovaný kód kontraktu NEBO haš podpisu vyvolané metody a zakódovaných parametrů.
+- `nonce`: `QUANTITY` – (volitelné) celé číslo nonce. To umožňuje přepsat vlastní nevyřízené transakce, které používají stejný nonce.
+
+**Návratová hodnota**
+
+`DATA`, objekt transakce kódovaný pomocí RLP podepsaný zadaným účtem.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","params": [{"data":"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675","from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155","gas": "0x76c0","gasPrice": "0x9184e72a000","to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567","value": "0x9184e72a"}]}'
+// Result
+{
+ "id": 1,
+ "jsonrpc": "2.0",
+ "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b"
+}
+```
+
+### eth_sendTransaction {#eth_sendtransaction}
+
+Vytvoří novou transakci volání zprávy nebo vytvoření kontraktu, pokud pole data obsahuje kód, a podepíše ji pomocí účtu uvedeného v `from`.
+
+**Parametry**
+
+1. `Object` – objekt transakce
+
+- `from`: `DATA`, 20 bajtů – adresa, ze které je transakce odeslána.
+- `to`: `DATA`, 20 bajtů – (volitelné při vytváření nového kontraktu) adresa, na kterou je transakce směrována.
+- `gas`: `QUANTITY` – (volitelné, výchozí: 90000) celé číslo gasu poskytnutého pro provedení transakce. Vrátí nevyužitý gas.
+- `gasPrice`: `QUANTITY` – (volitelné, výchozí: bude určeno) celé číslo ceny gasPrice použité pro každý zaplacený gas.
+- `value`: `QUANTITY` – (volitelné) celé číslo hodnoty odeslané s touto transakcí.
+- `input`: `DATA` – zkompilovaný kód kontraktu NEBO haš podpisu vyvolané metody a zakódovaných parametrů.
+- `nonce`: `QUANTITY` – (volitelné) celé číslo nonce. To umožňuje přepsat vlastní nevyřízené transakce, které používají stejný nonce.
+
+```js
+params: [
+ {
+ from: "0xb60e8dd61c5d32be8058bb8eb970870f07233155",
+ to: "0xd46e8dd67c5d32be8058bb8eb970870f07244567",
+ gas: "0x76c0", // 30400
+ gasPrice: "0x9184e72a000", // 10000000000000
+ value: "0x9184e72a", // 2441406250
+ input:
+ "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675",
+ },
+]
+```
+
+**Návratová hodnota**
+
+`DATA`, 32 bajtů – haš transakce, nebo nulový haš, pokud transakce ještě není k dispozici.
+
+Použijte [eth_getTransactionReceipt](#eth_gettransactionreceipt) pro získání adresy kontraktu poté, co byla transakce navržena v bloku, když jste vytvořili kontrakt.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{see above}],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
+}
+```
+
+### eth_sendRawTransaction {#eth_sendrawtransaction}
+
+Vytvoří novou transakci volání zprávy nebo vytvoření kontraktu pro podepsané transakce.
+
+**Parametry**
+
+1. `DATA`, podepsaná data transakce.
+
+```js
+params: [
+ "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675",
+]
+```
+
+**Návratová hodnota**
+
+`DATA`, 32 bajtů – haš transakce, nebo nulový haš, pokud transakce ještě není k dispozici.
+
+Použijte [eth_getTransactionReceipt](#eth_gettransactionreceipt) pro získání adresy kontraktu poté, co byla transakce navržena v bloku, když jste vytvořili kontrakt.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":[{see above}],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
+}
+```
+
+### eth_call {#eth_call}
+
+Okamžitě provede nové volání zprávy bez vytvoření transakce na blockchainu. Často se používá pro provádění funkcí chytrých kontraktů pouze pro čtení, například `balanceOf` pro kontrakt ERC-20.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `Object` – objekt volání transakce
+
+- `from`: `DATA`, 20 bajtů – (volitelné) adresa, ze které je transakce odeslána.
+- `to`: `DATA`, 20 bajtů – adresa, na kterou je transakce směrována.
+- `gas`: `QUANTITY` – (volitelné) celé číslo gasu poskytnutého pro provedení transakce. eth_call spotřebovává nulový gas, ale tento parametr může být potřebný pro některá provedení.
+- `gasPrice`: `QUANTITY` – (volitelné) celé číslo ceny gasu (gasPrice) použité pro každý zaplacený gas
+- `value`: `QUANTITY` – (volitelné) celé číslo hodnoty odeslané s touto transakcí
+- `input`: `DATA` – (volitelné) haš podpisu metody a zakódovaných parametrů. Podrobnosti naleznete v [dokumentaci Solidity o ABI kontraktu Etherea](https://docs.soliditylang.org/en/latest/abi-spec.html).
+
+2. `QUANTITY|TAG` – celé číslo bloku nebo řetězec `"latest"`, `"earliest"`, `"pending"`, `"safe"` nebo `"finalized"`, viz [parametr bloku](/developers/docs/apis/json-rpc/#block-parameter)
+
+**Návratová hodnota**
+
+`DATA` – návratová hodnota provedeného kontraktu.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x"
+}
+```
+
+### eth_estimateGas {#eth_estimategas}
+
+Generuje a vrací odhad, kolik gasu je nutné k dokončení transakce. Transakce nebude přidána do blockchainu. Všimněte si, že odhad může být výrazně vyšší než množství gasu skutečně spotřebovaného transakcí, a to z různých důvodů, včetně mechaniky EVM a výkonu uzlu.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+Viz parametry [eth_call](#eth_call) s tím rozdílem, že všechny vlastnosti jsou volitelné. Pokud není zadán žádný limit transakčních poplatků, Geth použije jako horní hranici limit transakčních poplatků bloku z nevyřízeného bloku. V důsledku toho vrácený odhad nemusí být dostatečný k provedení volání/transakce, pokud je množství paliva vyšší než limit transakčních poplatků nevyřízeného bloku.
+
+**Návratová hodnota**
+
+`QUANTITY` – množství spotřebovaného gasu.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see above}],"id":1}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x5208" // 21000
+}
+```
+
+### eth_getBlockByHash {#eth_getblockbyhash}
+
+Vrátí informace o bloku podle haše.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `DATA`, 32 bajtů – haš bloku.
+2. `Boolean` – pokud `true`, vrátí celé objekty transakcí, pokud `false`, vrátí pouze haše transakcí.
+
+```js
+params: [
+ "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae",
+ false,
+]
+```
+
+**Návratová hodnota**
+
+`Object` – objekt bloku, nebo `null`, pokud nebyl nalezen žádný blok:
+
+- `number`: `QUANTITY` – číslo bloku. `null`, pokud se jedná o nevyřízený blok.
+- `hash`: `DATA`, 32 bajtů – haš bloku. `null`, pokud se jedná o nevyřízený blok.
+- `parentHash`: `DATA`, 32 bajtů – haš rodičovského bloku.
+- `nonce`: `DATA`, 8 bajtů – haš vygenerovaného proof-of-work. `null` pro nevyřízený blok, `0x0` pro bloky proof-of-stake (od sloučení)
+- `sha3Uncles`: `DATA`, 32 bajtů – SHA3 dat strýčkovských bloků v bloku.
+- `logsBloom`: `DATA`, 256 bajtů – bloom filtr pro záznamy bloku. `null`, pokud se jedná o nevyřízený blok.
+- `transactionsRoot`: `DATA`, 32 bajtů – kořen trie transakcí bloku.
+- `stateRoot`: `DATA`, 32 bajtů – kořen konečného stavového trie bloku.
+- `receiptsRoot`: `DATA`, 32 bajtů – kořen trie potvrzení bloku.
+- `miner`: `DATA`, 20 bajtů – adresa příjemce, kterému byly uděleny odměny za blok.
+- `difficulty`: `QUANTITY` – celé číslo obtížnosti tohoto bloku.
+- `totalDifficulty`: `QUANTITY` – celé číslo celkové obtížnosti řetězce až do tohoto bloku.
+- `extraData`: `DATA` – pole „extra data“ tohoto bloku.
+- `size`: `QUANTITY` – celé číslo velikosti tohoto bloku v bajtech.
+- `gasLimit`: `QUANTITY` – maximální povolený gas v tomto bloku.
+- `gasUsed`: `QUANTITY` – celkový spotřebovaný gas všemi transakcemi v tomto bloku.
+- `timestamp`: `QUANTITY` – časové razítko unixu pro okamžik, kdy byl blok seřazen.
+- `transactions`: `Pole` – pole objektů transakcí nebo 32bajtových hašů transakcí v závislosti na posledním zadaném parametru.
+- `uncles`: `Pole` – pole hašů strýčkovských bloků.
+
+**Příklad**
+
+```js
+// Požadavek
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}'
+// Výsledek
+{
+ "jsonrpc": "2.0",
+ "id": 1,
+ "result": {
+ "difficulty": "0x4ea3f27bc",
+ "extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32",
+ "gasLimit": "0x1388",
+ "gasUsed": "0x0",
+ "hash": "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae",
+ "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
+ "miner": "0xbb7b8287f3f0a933474a79eae42cbca977791171",
+ "mixHash": "0x4fffe9ae21f1c9e15207b1f472d5bbdd68c9595d461666602f2be20daf5e7843",
+ "nonce": "0x689056015818adbe",
+ "number": "0x1b4",
+ "parentHash": "0xe99e022112df268087ea7eafaf4790497fd21dbeeb6bd7a1721df161a6657a54",
+ "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
+ "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
+ "size": "0x220",
+ "stateRoot": "0xddc8b0234c2e0cad087c8b389aa7ef01f7d79b2570bccb77ce48648aa61c904d",
+ "timestamp": "0x55ba467c",
+ "totalDifficulty": "0x78ed983323d",
+ "transactions": [
+ ],
+ "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
+ "uncles": [
+ ]
+ }
+}
+```
+
+### eth_getBlockByNumber {#eth_getblockbynumber}
+
+Vrátí informace o bloku podle čísla bloku.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `QUANTITY|TAG` – celé číslo čísla bloku nebo řetězec `"earliest"`, `"latest"`, `"pending"`, `"safe"` nebo `"finalized"`, jako v [parametru bloku](/developers/docs/apis/json-rpc/#block-parameter).
+2. `Boolean` – pokud `true`, vrátí celé objekty transakcí, pokud `false`, vrátí pouze haše transakcí.
+
+```js
+params: [
+ "0x1b4", // 436
+ true,
+]
+```
+
+**Návratová hodnota**
+Viz [eth_getBlockByHash](#eth_getblockbyhash)
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":1}'
+```
+
+Výsledek viz [eth_getBlockByHash](#eth_getblockbyhash)
+
+### eth_getTransactionByHash {#eth_gettransactionbyhash}
+
+Vrátí informace o transakci požadované podle haše transakce.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `DATA`, 32 bajtů – haš transakce
+
+```js
+params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"]
+```
+
+**Návratová hodnota**
+
+`Object` – objekt transakce nebo `null`, pokud nebyla nalezena žádná transakce:
+
+- `blockHash`: `DATA`, 32 bajtů – haš bloku, ve kterém se tato transakce nacházela. `null`, když je nevyřízená.
+- `blockNumber`: `QUANTITY` – číslo bloku, ve kterém se tato transakce nacházela. `null`, když je nevyřízená.
+- `from`: `DATA`, 20 bajtů – adresa odesílatele.
+- `gas`: `QUANTITY` – gas poskytnutý odesílatelem.
+- `gasPrice`: `QUANTITY` – cena gasu poskytnutá odesílatelem ve Wei.
+- `hash`: `DATA`, 32 bajtů – haš transakce.
+- `input`: `DATA` – data odeslaná spolu s transakcí.
+- `nonce`: `QUANTITY` – počet transakcí provedených odesílatelem před touto.
+- `to`: `DATA`, 20 bajtů – adresa příjemce. `null`, pokud se jedná o transakci vytvoření kontraktu.
+- `transactionIndex`: `QUANTITY` – celé číslo pozice indexu transakcí v bloku. `null`, když je nevyřízená.
+- `value`: `QUANTITY` – převedená hodnota ve Wei.
+- `v`: `QUANTITY` – ID pro obnovení ECDSA
+- `r`: `QUANTITY` – ECDSA podpis r
+- `s`: `QUANTITY` – ECDSA podpis s
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"],"id":1}'
+// Result
+{
+ "jsonrpc":"2.0",
+ "id":1,
+ "result":{
+ "blockHash":"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
+ "blockNumber":"0x5daf3b", // 6139707
+ "from":"0xa7d9ddbe1f17865597fbd27ec712455208b6b76d",
+ "gas":"0xc350", // 50000
+ "gasPrice":"0x4a817c800", // 20000000000
+ "hash":"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b",
+ "input":"0x68656c6c6f21",
+ "nonce":"0x15", // 21
+ "to":"0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb",
+ "transactionIndex":"0x41", // 65
+ "value":"0xf3dbb76162000", // 4290000000000000
+ "v":"0x25", // 37
+ "r":"0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea",
+ "s":"0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c"
+ }
+}
+```
+
+### eth_getTransactionByBlockHashAndIndex {#eth_gettransactionbyblockhashandindex}
+
+Vrátí informace o transakci podle haše bloku a pozice indexu transakce.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `DATA`, 32 bajtů – haš bloku.
+2. `QUANTITY` – celé číslo pozice indexu transakce.
+
+```js
+params: [
+ "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
+ "0x0", // 0
+]
+```
+
+**Návratová hodnota**
+Viz [eth_getTransactionByHash](#eth_gettransactionbyhash)
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}'
+```
+
+Výsledek viz [eth_getTransactionByHash](#eth_gettransactionbyhash)
+
+### eth_getTransactionByBlockNumberAndIndex {#eth_gettransactionbyblocknumberandindex}
+
+Vrátí informace o transakci podle čísla bloku a pozice indexu transakce.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `QUANTITY|TAG` – číslo bloku nebo řetězec `"earliest"`, `"latest"`, `"pending"`, `"safe"` nebo `"finalized"`, jako v [parametru bloku](/developers/docs/apis/json-rpc/#block-parameter).
+2. `QUANTITY` – pozice indexu transakce.
+
+```js
+params: [
+ "0x9c47cf", // 10241999
+ "0x24", // 36
+]
+```
+
+**Návratová hodnota**
+Viz [eth_getTransactionByHash](#eth_gettransactionbyhash)
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}'
+```
+
+Výsledek viz [eth_getTransactionByHash](#eth_gettransactionbyhash)
+
+### eth_getTransactionReceipt {#eth_gettransactionreceipt}
+
+Vrátí potvrzení o transakci podle haše transakce.
+
+**Poznámka:** Potvrzení není k dispozici pro nevyřízené transakce.
+
+**Parametry**
+
+1. `DATA`, 32 bajtů – haš transakce
+
+```js
+params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"]
+```
+
+**Návratová hodnota**
+`Object` – objekt potvrzení transakce, nebo `null`, pokud nebylo nalezeno žádné potvrzení:
+
+- `transactionHash `: `DATA`, 32 bajtů – haš transakce.
+- `transactionIndex`: `QUANTITY` – celé číslo pozice indexu transakcí v bloku.
+- `blockHash`: `DATA`, 32 bajtů – haš bloku, ve kterém se tato transakce nacházela.
+- `blockNumber`: `QUANTITY` – číslo bloku, ve kterém se tato transakce nacházela.
+- `from`: `DATA`, 20 bajtů – adresa odesílatele.
+- `to`: `DATA`, 20 bajtů – adresa příjemce. `null`, pokud se jedná o transakci vytvoření kontraktu.
+- `cumulativeGasUsed` : `QUANTITY ` – celkové množství gasu spotřebovaného při provedení této transakce v bloku.
+- `effectiveGasPrice` : `QUANTITY` – součet základního poplatku a spropitného zaplaceného za jednotku gasu.
+- `gasUsed `: `QUANTITY ` – množství gasu spotřebovaného pouze touto konkrétní transakcí.
+- `contractAddress `: `DATA`, 20 bajtů – adresa vytvořeného kontraktu, pokud se jednalo o transakci vytvoření kontraktu, jinak `null`.
+- `logs`: `Pole` – pole objektů logu, které tato transakce vygenerovala.
+- `logsBloom`: `DATA`, 256 bajtů – bloom filtr pro lehké klienty k rychlému načtení souvisejících záznamů.
+- `type`: `QUANTITY` – celé číslo typu transakce, `0x0` pro starší transakce, `0x1` pro typy se seznamem přístupů, `0x2` pro dynamické poplatky.
+
+Vrátí také _buď_:
+
+- `root`: `DATA` 32 bajtů kořene stavu po transakci (před Byzantium)
+- `status`: `QUANTITY` buď `1` (úspěch), nebo `0` (selhání)
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"],"id":1}'
+// Result
+{
+ "jsonrpc": "2.0",
+ "id": 1,
+ "result": {
+ "blockHash":
+ "0xa957d47df264a31badc3ae823e10ac1d444b098d9b73d204c40426e57f47e8c3",
+ "blockNumber": "0xeff35f",
+ "contractAddress": null, // řetězec adresy, pokud byla vytvořena
+ "cumulativeGasUsed": "0xa12515",
+ "effectiveGasPrice": "0x5a9c688d4",
+ "from": "0x6221a9c005f6e47eb398fd867784cacfdcfff4e7",
+ "gasUsed": "0xb4c8",
+ "logs": [{
+ // logy vrácené pomocí getFilterLogs atd.
+ }],
+ "logsBloom": "0x00...0", // 256bajtový bloom filtr
+ "status": "0x1",
+ "to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
+ "transactionHash":
+ "0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5",
+ "transactionIndex": "0x66",
+ "type": "0x2"
+ }
+}
+```
+
+### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex}
+
+Vrací informace o „uncle“ bloku podle haše a pozice indexu „uncle“.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `DATA`, 32 bajtů – haš bloku.
+2. `QUANTITY` – pozice indexu strýčkovského bloku.
+
+```js
+params: [
+ "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
+ "0x0", // 0
+]
+```
+
+**Návratová hodnota**
+Viz [eth_getBlockByHash](#eth_getblockbyhash)
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}'
+```
+
+Výsledek viz [eth_getBlockByHash](#eth_getblockbyhash)
+
+**Poznámka**: Strýčkovský blok neobsahuje jednotlivé transakce.
+
+### eth_getUncleByBlockNumberAndIndex {#eth_getunclebyblocknumberandindex}
+
+Vrací informace o „uncle“ bloku podle čísla a pozice indexu „uncle“.
+
+
+ Vyzkoušejte koncový bod na playgroundu
+
+
+**Parametry**
+
+1. `QUANTITY|TAG` – číslo bloku nebo řetězec `"earliest"`, `"latest"`, `"pending"`, `"safe"`, `"finalized"`, jako v [parametru bloku](/developers/docs/apis/json-rpc/#block-parameter).
+2. `QUANTITY` – pozice indexu strýčkovského bloku.
+
+```js
+params: [
+ "0x29c", // 668
+ "0x0", // 0
+]
+```
+
+**Návratová hodnota**
+Viz [eth_getBlockByHash](#eth_getblockbyhash)
+
+**Poznámka**: Strýčkovský blok neobsahuje jednotlivé transakce.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":1}'
+```
+
+Výsledek viz [eth_getBlockByHash](#eth_getblockbyhash)
+
+### eth_newFilter {#eth_newfilter}
+
+Vytvoří objekt filtru na základě možností filtru, který upozorní na změnu stavu (záznamy).
+Chcete-li zkontrolovat, zda se stav změnil, zavolejte [eth_getFilterChanges](#eth_getfilterchanges).
+
+**Poznámka k zadávání filtrů témat:**
+Témata jsou závislá na pořadí. Transakce s logem s tématy [A, B] bude odpovídat následujícím filtrům témat:
+
+- `[]` „cokoliv“
+- `[A]` „A na první pozici (a cokoliv dalšího)“
+- `[null, B]` „cokoliv na první pozici A B na druhé pozici (a cokoliv dalšího)“
+- `[A, B]` „A na první pozici A B na druhé pozici (a cokoliv dalšího)“
+- `[[A, B], [A, B]]` „(A NEBO B) na první pozici A (A NEBO B) na druhé pozici (a cokoliv dalšího)“
+- **Parametry**
+
+1. `Object` – možnosti filtru:
+
+- `fromBlock`: `QUANTITY|TAG` – (volitelné, výchozí: `"latest"`) celé číslo bloku, nebo `"latest"` pro poslední navržený blok, `"safe"` pro poslední bezpečný blok, `"finalized"` pro poslední finalizovaný blok nebo `"pending"`, `"earliest"` pro transakce, které ještě nejsou v bloku.
+- `toBlock`: `QUANTITY|TAG` – (volitelné, výchozí: `"latest"`) celé číslo bloku, nebo `"latest"` pro poslední navržený blok, `"safe"` pro poslední bezpečný blok, `"finalized"` pro poslední finalizovaný blok nebo `"pending"`, `"earliest"` pro transakce, které ještě nejsou v bloku.
+- `address`: `DATA|Pole`, 20 bajtů – (volitelné) adresa kontraktu nebo seznam adres, ze kterých by měly logy pocházet.
+- `topics`: `Pole DATA`, – (volitelné) pole 32bajtových témat `DATA`. Témata jsou závislá na pořadí. Každé téma může být také polem DATA s možnostmi „nebo“.
+
+```js
+params: [
+ {
+ fromBlock: "0x1",
+ toBlock: "0x2",
+ address: "0x8888f1f195afa192cfee860698584c030f4c9db1",
+ topics: [
+ "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b",
+ null,
+ [
+ "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b",
+ "0x0000000000000000000000000aff3454fce5edbc8cca8697c15331677e6ebccc",
+ ],
+ ],
+ },
+]
+```
+
+**Návratová hodnota**
+`QUANTITY` – ID filtru.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topics":["0x12341234"]}],"id":73}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x1" // 1
+}
+```
+
+### eth_newBlockFilter {#eth_newblockfilter}
+
+Vytvoří v uzlu filtr, který upozorní na příchod nového bloku.
+Chcete-li zkontrolovat, zda se stav změnil, zavolejte [eth_getFilterChanges](#eth_getfilterchanges).
+
+**Parametry**
+Žádné
+
+**Návratová hodnota**
+`QUANTITY` – ID filtru.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":73}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x1" // 1
+}
+```
+
+### eth_newPendingTransactionFilter {#eth_newpendingtransactionfilter}
+
+Vytvoří v uzlu filtr, který upozorní na příchod nových nevyřízených transakcí.
+Chcete-li zkontrolovat, zda se stav změnil, zavolejte [eth_getFilterChanges](#eth_getfilterchanges).
+
+**Parametry**
+Žádné
+
+**Návratová hodnota**
+`QUANTITY` – ID filtru.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":73}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": "0x1" // 1
+}
+```
+
+### eth_uninstallFilter {#eth_uninstallfilter}
+
+Odinstaluje filtr s daným ID. Mělo by být vždy voláno, když již není potřeba sledování.
+Filtry navíc vyprší, pokud nejsou po určitou dobu požadovány pomocí [eth_getFilterChanges](#eth_getfilterchanges).
+
+**Parametry**
+
+1. `QUANTITY` – ID filtru.
+
+```js
+params: [
+ "0xb", // 11
+]
+```
+
+**Návratová hodnota**
+`Boolean` – `true`, pokud byl filtr úspěšně odinstalován, jinak `false`.
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["0xb"],"id":73}'
+// Result
+{
+ "id":1,
+ "jsonrpc": "2.0",
+ "result": true
+}
+```
+
+### eth_getFilterChanges {#eth_getfilterchanges}
+
+Dotazovací metoda pro filtr, která vrací pole záznamů, které se objevily od posledního dotazu.
+
+**Parametry**
+
+1. `QUANTITY` – ID filtru.
+
+```js
+params: [
+ "0x16", // 22
+]
+```
+
+**Návratová hodnota**
+`Pole` – pole objektů logů, nebo prázdné pole, pokud se od posledního dotazu nic nezměnilo.
+
+- Pro filtry vytvořené pomocí `eth_newBlockFilter` jsou návratovou hodnotou haše bloků (`DATA`, 32 bajtů), např. `[\"0x3454645634534...\"]`.
+
+- Pro filtry vytvořené pomocí `eth_newPendingTransactionFilter` jsou návratovou hodnotou haše transakcí (`DATA`, 32 bajtů), např. `[\"0x6345343454645...\"]`.
+
+- Pro filtry vytvořené pomocí `eth_newFilter` jsou logy objekty s následujícími parametry:
+ - `removed`: `TAG` – `true`, když byl log odstraněn kvůli reorganizaci řetězce. `false`, pokud se jedná o platný log.
+ - `logIndex`: `QUANTITY` – celé číslo pozice indexu logu v bloku. `null`, pokud se jedná o nevyřízený log.
+ - `transactionIndex`: `QUANTITY` – celé číslo pozice indexu transakcí, ze kterého byl log vytvořen. `null`, pokud se jedná o nevyřízený log.
+ - `transactionHash`: `DATA`, 32 bajtů – haš transakcí, ze kterých byl tento log vytvořen. `null`, pokud se jedná o nevyřízený log.
+ - `blockHash`: `DATA`, 32 bajtů – haš bloku, ve kterém se tento log nacházel. `null`, když je nevyřízená. `null`, pokud se jedná o nevyřízený log.
+ - `blockNumber`: `QUANTITY` – číslo bloku, ve kterém se tento log nacházel. `null`, když je nevyřízená. `null`, pokud se jedná o nevyřízený log.
+ - `address`: `DATA`, 20 bajtů – adresa, ze které tento log pochází.
+ - `data`: `DATA` – neindexovaná data protokolu s proměnnou délkou. (V _solidity_: nula nebo více 32bajtových neindexovaných argumentů protokolu.)
+ - `topics`: `Pole DATA` – pole 0 až 4 32bajtových `DATA` indexovaných argumentů logu. (V _solidity_: První téma je _haš_ podpisu události (např. `Deposit(address,bytes32,uint256)`), pokud jste událost nedeklarovali se specifikátorem `anonymous`.)
+
+- **Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x16"],"id":73}'
+// Result
+{
+ "id":1,
+ "jsonrpc":"2.0",
+ "result": [{
+ "logIndex": "0x1", // 1
+ "blockNumber":"0x1b4", // 436
+ "blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d",
+ "transactionHash": "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf",
+ "transactionIndex": "0x0", // 0
+ "address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d",
+ "data":"0x0000000000000000000000000000000000000000000000000000000000000000",
+ "topics": ["0x59ebeb90bc63057b6515673c3ecf9438e5058bca0f92585014eced636878c9a5"]
+ },{
+ ...
+ }]
+}
+```
+
+### eth_getFilterLogs {#eth_getfilterlogs}
+
+Vrátí pole všech logů odpovídajících filtru s daným ID.
+
+**Parametry**
+
+1. `QUANTITY` – ID filtru.
+
+```js
+params: [
+ "0x16", // 22
+]
+```
+
+**Návratová hodnota**
+Viz [eth_getFilterChanges](#eth_getfilterchanges)
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":74}'
+```
+
+Výsledek viz [eth_getFilterChanges](#eth_getfilterchanges)
+
+### eth_getLogs {#eth_getlogs}
+
+Vrátí pole všech logů odpovídajících danému objektu filtru.
+
+**Parametry**
+
+1. `Object` – možnosti filtru:
+
+- `fromBlock`: `QUANTITY|TAG` – (volitelné, výchozí: `"latest"`) celé číslo bloku, nebo `"latest"` pro poslední navržený blok, `"safe"` pro poslední bezpečný blok, `"finalized"` pro poslední finalizovaný blok nebo `"pending"`, `"earliest"` pro transakce, které ještě nejsou v bloku.
+- `toBlock`: `QUANTITY|TAG` – (volitelné, výchozí: `"latest"`) celé číslo bloku, nebo `"latest"` pro poslední navržený blok, `"safe"` pro poslední bezpečný blok, `"finalized"` pro poslední finalizovaný blok nebo `"pending"`, `"earliest"` pro transakce, které ještě nejsou v bloku.
+- `address`: `DATA|Pole`, 20 bajtů – (volitelné) adresa kontraktu nebo seznam adres, ze kterých by měly logy pocházet.
+- `topics`: `Pole DATA`, – (volitelné) pole 32bajtových témat `DATA`. Témata jsou závislá na pořadí. Každé téma může být také polem DATA s možnostmi „nebo“.
+- `blockHash`: `DATA`, 32 bajtů – (volitelné, **v budoucnu**) S přidáním EIP-234 bude `blockHash` novou možností filtru, která omezuje vrácené logy na jediný blok s 32bajtovým hašem `blockHash`. Použití `blockHash` je ekvivalentní `fromBlock` = `toBlock` = číslo bloku s hašem `blockHash`. Pokud je v kritériích filtru přítomen `blockHash`, pak nejsou povoleny ani `fromBlock`, ani `toBlock`.
+
+```js
+params: [
+ {
+ topics: [
+ "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b",
+ ],
+ },
+]
+```
+
+**Návratová hodnota**
+Viz [eth_getFilterChanges](#eth_getfilterchanges)
+
+**Příklad**
+
+```js
+// Request
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":74}'
+```
+
+Výsledek viz [eth_getFilterChanges](#eth_getfilterchanges)
+
+## Příklad použití {#usage-example}
+
+### Nasazení kontraktu pomocí JSON_RPC {#deploying-contract}
+
+Tato část obsahuje ukázku, jak nasadit kontrakt pouze pomocí rozhraní RPC. Existují alternativní cesty k nasazení kontraktů, kde je tato složitost abstrahována – například pomocí knihoven postavených na rozhraní RPC, jako jsou [web3.js](https://web3js.readthedocs.io/) a [web3.py](https://github.com/ethereum/web3.py). Tyto abstrakce jsou obecně snáze pochopitelné a méně náchylné k chybám, ale stále je užitečné pochopit, co se děje pod pokličkou.
+
+Následuje jednoduchý chytrý kontrakt s názvem `Multiply7`, který bude nasazen pomocí rozhraní JSON-RPC na uzel Ethereum. Tento tutoriál předpokládá, že čtenář již provozuje uzel Geth. Více informací o uzlech a klientech je k dispozici [zde](/developers/docs/nodes-and-clients/run-a-node). Informace o tom, jak spustit HTTP JSON-RPC pro klienty jiné než Geth, naleznete v dokumentaci jednotlivých [klientů](/developers/docs/nodes-and-clients/). Většina klientů má jako výchozí nastavení poskytování služeb na `localhost:8545`.
+
+```javascript
+contract Multiply7 {
+ event Print(uint);
+ function multiply(uint input) returns (uint) {
+ Print(input * 7);
+ return input * 7;
+ }
+}
+```
+
+První věc, kterou je třeba udělat, je ujistit se, že je povoleno rozhraní HTTP RPC. To znamená, že při spuštění poskytneme Gethu příznak `--http`. V tomto příkladu používáme uzel Geth na soukromém vývojovém řetězci. Při tomto přístupu nepotřebujeme ether na skutečné síti.
+
+```bash
+geth --http --dev console 2>>geth.log
+```
+
+Tím se spustí rozhraní HTTP RPC na `http://localhost:8545`.
+
+Ověřit, že rozhraní běží, můžeme načtením coinbase adresy (získáním první adresy z pole účtů) a zůstatku pomocí [curl](https://curl.se). Upozorňujeme, že data v těchto příkladech se na vašem lokálním uzlu budou lišit. Pokud chcete tyto příkazy vyzkoušet, nahraďte parametry požadavku v druhém požadavku curl výsledkem vráceným z prvního.
+
+```bash
+curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[], "id":1}' -H "Content-Type: application/json" localhost:8545
+{"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]}
+
+curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545
+{"id":2,"jsonrpc":"2.0","result":"0x1639e49bba16280000"}
+```
+
+Protože čísla jsou kódována šestnáctkově, zůstatek je vrácen ve wei jako šestnáctkový řetězec. Pokud chceme mít zůstatek v etheru jako číslo, můžeme použít web3 z konzole Geth.
+
+```javascript
+web3.fromWei("0x1639e49bba16280000", "ether")
+// "410"
+```
+
+Nyní, když máme na našem soukromém vývojovém řetězci nějaký ether, můžeme nasadit kontrakt. Prvním krokem je zkompilovat kontrakt Multiply7 do bajtkódu, který lze odeslat do EVM. Pro instalaci solc, kompilátoru Solidity, postupujte podle [dokumentace Solidity](https://docs.soliditylang.org/en/latest/installing-solidity.html). (Možná budete chtít použít starší vydání `solc`, aby odpovídalo [verzi kompilátoru použitého pro náš příklad](https://github.com/ethereum/solidity/releases/tag/v0.4.20).)
+
+Dalším krokem je zkompilovat kontrakt Multiply7 do bajtového kódu, který lze odeslat do EVM.
+
+```bash
+echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin
+
+======= :Multiply7 =======
+Binary:
+6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029
+```
+
+Nyní, když máme zkompilovaný kód, musíme určit, kolik gasu stojí jeho nasazení. Rozhraní RPC má metodu `eth_estimateGas`, která nám poskytne odhad.
+
+```bash
+curl --data '{"jsonrpc":"2.0","method": "eth_estimateGas", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 5}' -H "Content-Type: application/json" localhost:8545
+{"jsonrpc":"2.0","id":5,"result":"0x1c31e"}
+```
+
+A nakonec nasaďte kontrakt.
+
+```bash
+curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "gas": "0x1c31e", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 6}' -H "Content-Type: application/json" localhost:8545
+{"id":6,"jsonrpc":"2.0","result":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"}
+```
+
+Transakce je přijata uzlem a vrátí se haš transakce. Tento haš může být použit ke sledování transakce. Dalším krokem je určení adresy, na které je náš kontrakt nasazen. Každá provedená transakce vytvoří potvrzení. Toto potvrzení obsahuje různé informace o transakci, například do kterého bloku byla transakce zahrnuta a kolik gasu spotřeboval EVM. Pokud transakce
+vytváří kontrakt, bude také obsahovat adresu kontraktu. Potvrzení můžeme získat pomocí RPC metody `eth_getTransactionReceipt`.
+
+```bash
+curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545
+{"jsonrpc":"2.0","id":7,"result":{"blockHash":"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f","blockNumber":"0x1","contractAddress":"0x4d03d617d700cf81935d7f797f4e2ae719648262","cumulativeGasUsed":"0x1c31e","from":"0x9b1d35635cc34752ca54713bb99d38614f63c955","gasUsed":"0x1c31e","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":null,"transactionHash":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf","transactionIndex":"0x0"}}
+```
+
+Náš kontrakt byl vytvořen na adrese `0x4d03d617d700cf81935d7f797f4e2ae719648262`. Výsledek null namísto potvrzení znamená, že transakce ještě nebyla zahrnuta do bloku. Chvíli počkejte, zkontrolujte, zda běží váš konsensuální klient, a zkuste to znovu.
+
+#### Interakce s chytrými kontrakty {#interacting-with-smart-contract}
+
+V tomto příkladu odešleme transakci pomocí `eth_sendTransaction` na metodu `multiply` daného kontraktu.
+
+`eth_sendTransaction` vyžaduje několik argumentů, konkrétně `from`, `to` a `data`. `From` je veřejná adresa našeho účtu a `to` je adresa kontraktu. Argument `data` obsahuje datovou část (payload), která definuje, jaká metoda se má zavolat a s jakými argumenty. Zde přichází na řadu [ABI (application binary interface)](https://docs.soliditylang.org/en/latest/abi-spec.html). ABI je soubor JSON, který definuje, jak definovat a kódovat data pro EVM.
+
+Bajty datové části (payload) definují, která metoda v kontraktu je volána. Jedná se o první 4 bajty z haše Keccak přes název funkce a typy jejích argumentů, kódované v šestnáctkové soustavě. Funkce multiply přijímá uint, což je alias pro uint256. Zůstane nám tedy:
+
+```javascript
+web3.sha3("multiply(uint256)").substring(0, 10)
+// "0xc6888fa1"
+```
+
+Dalším krokem je zakódování argumentů. Je zde pouze jeden uint256, řekněme hodnota 6. ABI má sekci, která specifikuje, jak kódovat typy uint256.
+
+`int: enc(X)` je kódování X v doplňkovém kódu big-endian, doplněné na straně vyššího řádu (vlevo) o 0xff pro záporné X a o nulové bajty pro kladné X tak, aby délka byla násobkem 32 bajtů.
+
+To se zakóduje na `0000000000000000000000000000000000000000000000000000000000000006`.
+
+Kombinací selektoru funkce a zakódovaného argumentu budou naše data `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`.
+
+Toto lze nyní odeslat do uzlu:
+
+```bash
+curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0xeb85a5557e5bdc18ee1934a89d8bb402398ee26a", "to": "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d", "data": "0xc6888fa10000000000000000000000000000000000000000000000000000000000000006"}], "id": 8}' -H "Content-Type: application/json" localhost:8545
+{"id":8,"jsonrpc":"2.0","result":"0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74"}
+```
+
+Jelikož byla odeslána transakce, vrátil se její haš. Získání potvrzení vrátí:
+
+```javascript
+{
+ blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55",
+ blockNumber: 268,
+ contractAddress: null,
+ cumulativeGasUsed: 22631,
+ gasUsed: 22631,
+ logs: [{
+ address: "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d",
+ blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55",
+ blockNumber: 268,
+ data: "0x000000000000000000000000000000000000000000000000000000000000002a",
+ logIndex: 0,
+ topics: ["0x24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da"],
+ transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74",
+ transactionIndex: 0
+ }],
+ transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74",
+ transactionIndex: 0
+}
+```
+
+Potvrzení obsahuje log. Tento log byl vygenerován EVM při provedení transakce a zahrnut do potvrzení. Funkce `multiply` ukazuje, že událost `Print` byla vyvolána se vstupem vynásobeným 7. Vzhledem k tomu, že argument pro událost `Print` byl uint256, můžeme jej dekódovat podle pravidel ABI, což nám zanechá očekávanou desetinnou hodnotu 42. Kromě dat stojí za zmínku, že témata lze použít k určení, která událost vytvořila záznam:
+
+```javascript
+web3.sha3("Print(uint256)")
+// "24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da"
+```
+
+Toto byl jen stručný úvod do některých z nejběžnějších úkolů, demonstrující přímé použití JSON-RPC.
+
+## Související témata {#related-topics}
+
+- [Specifikace JSON-RPC](http://www.jsonrpc.org/specification)
+- [Uzly a klienti](/developers/docs/nodes-and-clients/)
+- [JavaScript API](/developers/docs/apis/javascript/)
+- [Backend API](/developers/docs/apis/backend/)
+- [Exekuční klienti](/developers/docs/nodes-and-clients/#execution-clients)
diff --git a/public/content/translations/cs/developers/docs/blocks/index.md b/public/content/translations/cs/developers/docs/blocks/index.md
index 84b13845fe4..82d03cb3138 100644
--- a/public/content/translations/cs/developers/docs/blocks/index.md
+++ b/public/content/translations/cs/developers/docs/blocks/index.md
@@ -8,13 +8,14 @@ Bloky jsou soubory transakcí s hashem předchozího bloku v řetězci. Tím se
## Předpoklady {#prerequisites}
-Bloky jsou velmi přívětivým tématem pro začátečníky. K lepšímu pochopení této stránky však doporučujeme nejprve si přečíst [Účty](/developers/docs/accounts/), [Transakce](/developers/docs/transactions/), a náš [úvod do Etherea](/developers/docs/intro-to-ethereum/).
+Bloky jsou velmi přívětivým tématem pro začátečníky. Ale abychom Vám pomohli lépe porozumět této stránce, doporučujeme Vám si nejprve přečíst [Účty](/developers/docs/accounts/), [Transakce](/developers/docs/transactions/) a náš [úvod do Etherea](/developers/docs/intro-to-ethereum/).
## Proč bloky? {#why-blocks}
Aby bylo zajištěno, že všichni účastníci sítě Ethereum udržují synchronizovaný stav a shodují se na přesné historii transakcí, seskupujeme transakce do bloků. To znamená, že desítky (nebo stovky) transakcí jsou potvrzeny, odsouhlaseny a synchronizovány najednou.
- _Diagram převzat z [ilustrace Ethereum EVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_Diagram byl převzat z [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
Tím, že rozdělujeme potvrzení do jednotlivých intervalů, dáváme všem účastníkům sítě dostatek času k dosažení konsenzu: I když jsou požadavky na transakce zasílány v řádu vyšších desítek za sekundu, bloky jsou na Ethereu vytvářeny a potvrzovány pouze jednou za dvanáct sekund.
@@ -24,7 +25,7 @@ K zachování historie transakcí jsou bloky přísně uspořádány (každý no
Jakmile náhodně vybraný validátor blok sestaví, rozšíří se do zbytku sítě. Všechny uzly přidají tento blok na konec svého blockchainu a vybere se nový validátor, který vytvoří další blok. Přesný proces sestavování bloků a proces potvrzení/konsenzu je v současnosti specifikován protokolem „důkazu podílem“ Etherea.
-## Protokol důkazu podílem {#proof-of-work-protocol}
+## Protokol Proof-of-Stake {#proof-of-stake-protocol}
Důkaz podílem znamená následující:
@@ -40,52 +41,52 @@ Důkaz podílem znamená následující:
Blok obsahuje spoustu informací. Na nejvyšší úrovni blok obsahuje následující pole:
| Pole | Popis |
-|:---------------- |:------------------------------------------------------- |
+| :--------------- | :------------------------------------------------------ |
| `slot` | slot, do kterého blok patří |
| `proposer_index` | ID validátora, který navrhuje blok |
| `parent_root` | hash předchozího bloku |
| `state_root` | kořenový hash stavového objektu |
-| `body` | tělo bloku obsahující několik polí, jak je uvedeno níže |
+| `tělo` | tělo bloku obsahující několik polí, jak je uvedeno níže |
-`Tělo` bloku obsahuje několik vlastních polí:
+Tělo bloku obsahuje několik vlastních polí:
| Pole | Popis |
-|:-------------------- |:--------------------------------------------------------------- |
+| :------------------- | :-------------------------------------------------------------- |
| `randao_reveal` | hodnota, která byla použita k výběru dalšího navrhovatele bloku |
| `eth1_data` | informace o vkladovém kontraktu |
| `graffiti` | libovolná data používaná k označování bloků |
| `proposer_slashings` | seznam validátorů, kteří budou penalizováni |
| `attester_slashings` | seznam atestátorů bloků, kteří budou penalizováni |
-| `atestace` | seznam atestací ve prospěch aktuálního bloku |
-| `deposits` | seznam nových vkladů do vkladového kontraktu |
+| `atestace` | seznam atestací provedených proti předchozím slotům |
+| `vklady` | seznam nových vkladů do vkladového kontraktu |
| `voluntary_exits` | seznam validátorů odcházejících ze sítě |
| `sync_aggregate` | podmnožina validátorů používaná k obsluze lehkých klientů |
| `execution_payload` | transakce předané z exekučního klienta |
-Pole `atestace` obsahuje seznam všech atestací v bloku. Atestace mají svůj vlastní datový typ, který obsahuje několik částí dat. Každá atestace obsahuje:
+Pole `attestations` obsahuje seznam všech atestací v bloku. Atestace mají svůj vlastní datový typ, který obsahuje několik částí dat. Každá atestace obsahuje:
| Pole | Popis |
-|:------------------ |:--------------------------------------------------- |
+| :----------------- | :-------------------------------------------------- |
| `aggregation_bits` | seznam validátorů, kteří se účastnili této atestace |
| `data` | objekt s několika podpoli |
-| `podpis` | agregovaný podpis všech atestujících validátorů |
+| `podpis` | souhrnný podpis sady validátorů proti části `data` |
-Pole `data` v `atestaci` obsahuje následující:
+Pole `data` v `attestation` obsahuje následující:
-| Pole | Popis |
-|:------------------- |:----------------------------------------------------------- |
-| `slot` | slot, k němuž se atestace vztahuje |
-| `index` | indexy pro atestující validátory |
-| `beacon_block_root` | kořenový hash bloku na Beaconu, který obsahuje tento objekt |
-| `zdroj` | poslední oprávněný kontrolní bod |
-| `target` | poslední hraniční blok epochy |
+| Pole | Popis |
+| :------------------ | :------------------------------------------------------------- |
+| `slot` | slot, k němuž se atestace vztahuje |
+| `index` | indexy pro atestující validátory |
+| `beacon_block_root` | kořenový haš Beacon bloku, který je považován za hlavu řetězce |
+| `zdroj` | poslední oprávněný kontrolní bod |
+| `target` | poslední hraniční blok epochy |
-Provádění transakcí v `execution_payload` aktualizuje globální stav. Všechny klienty znovu provedou transakce v `execution_payload`, aby se ujistily, že nový stav odpovídá stavu v novém poli `state_root` bloku. Takto mohou klienty zjistit, že nový blok je platný a bezpečný pro přidání do jejich blockchainu. Samotný `execution_payload` je objekt s několika poli. Existuje také `execution_payload_header` – hlavička, která obsahuje důležité souhrnné informace o datech provádění. Tyto datové struktury jsou organizovány následovně:
+Provedení transakcí v `execution_payload` aktualizuje globální stav. Všichni klienti znovu provedou transakce v `execution_payload`, aby se ujistili, že nový stav odpovídá stavu v poli `state_root` nového bloku. Takto mohou klienty zjistit, že nový blok je platný a bezpečný pro přidání do jejich blockchainu. Samotný `execution_payload` je objekt s několika poli. Existuje také `execution_payload_header` – hlavička, která obsahuje důležité souhrnné informace o datech provádění. Tyto datové struktury jsou organizovány následovně:
-`Execution_payload_header` obsahuje tato pole:
+`execution_payload_header` obsahuje následující pole:
| Pole | Popis |
-|:------------------- |:--------------------------------------------------------------- |
+| :------------------ | :-------------------------------------------------------------- |
| `parent_hash` | hash předchozího bloku |
| `fee_recipient` | adresa účtu pro platbu transakčních poplatků |
| `state_root` | kořenový hash pro globální stav po uplatnění změn v tomto bloku |
@@ -102,10 +103,10 @@ Provádění transakcí v `execution_payload` aktualizuje globální stav. Všec
| `transactions_root` | kořenový hash transakcí v payloadu |
| `withdrawal_root` | kořenový hash výběrů v payloadu |
-Samotný `execution_payload` obsahuje následující (všimněte si, že je totožný s hlavičkou, s výjimkou toho, že místo kořenového hashe transakcí zahrnuje skutečný seznam transakcí a informace o výběrech):
+Samotný `execution_payload` obsahuje následující (všimněte si, že je totožný s hlavičkou, s výjimkou toho, že místo kořenového haše transakcí zahrnuje skutečný seznam transakcí a informace o výběrech):
| Pole | Popis |
-|:------------------ |:--------------------------------------------------------------- |
+| :----------------- | :-------------------------------------------------------------- |
| `parent_hash` | hash předchozího bloku |
| `fee_recipient` | adresa účtu pro platbu transakčních poplatků |
| `state_root` | kořenový hash pro globální stav po uplatnění změn v tomto bloku |
@@ -122,30 +123,30 @@ Samotný `execution_payload` obsahuje následující (všimněte si, že je toto
| `transakce` | seznam transakcí připravených k realizaci |
| `výběry` | seznam objektů výběru |
-Seznam `výběrů` obsahuje objekty `výběru` strukturované následovně:
+Seznam `withdrawals` obsahuje objekty `withdrawal` strukturované následovně:
-| Pole | Popis |
-|:------------------ |:-------------------------------- |
-| `address (adresa)` | adresa účtu, který provádí výběr |
-| `částka` | částka výběru |
-| `index` | indexní hodnota výběru |
-| `validatorIndex` | indexní hodnota validátora |
+| Pole | Popis |
+| :--------------- | :------------------------------- |
+| `adresa` | adresa účtu, který provádí výběr |
+| `částka` | částka výběru |
+| `index` | indexní hodnota výběru |
+| `validatorIndex` | indexní hodnota validátora |
## Čas bloku {#block-time}
Čas bloku referuje o čase mezi bloky. Na Ethereu je čas rozdělen do dvanáctisekundových jednotek nazývaných „sloty“. V každém slotu je vybrán jeden validátor, který navrhne blok. Za předpokladu, že všichni validátoři jsou online a plně funkční, bude v každém slotu blok, což znamená, že čas bloku je 12 s. Někdy ale mohou být validátoři offline, když jsou vyzváni k navržení bloku, což znamená, že některé sloty mohou zůstat prázdné.
-Tato implementace se liší od systémů založených na důkazu prací, kde jsou časy bloků pravděpodobnostní a upravují se cílovou obtížností těžby v protokolu. [Průměrný čas bloku](https://etherscan.io/chart/blocktime) na Ethereu je dokonalým příkladem tohoto rozdílu, na kterém lze jasně pozorovat přechod z důkazu prací na důkaz podílem díky konzistenci nového 12s času bloku.
+Tato implementace se liší od systémů založených na důkazu prací, kde jsou časy bloků pravděpodobnostní a upravují se cílovou obtížností těžby v protokolu. [Průměrný čas bloku](https://etherscan.io/chart/blocktime) Etherea je toho dokonalým příkladem, kdy přechod z důkazu prací na důkaz podílem lze jasně odvodit na základě konzistence nového času bloku 12 s.
## Velikost bloku {#block-size}
-Poslední důležitou poznámkou je, že velikost samotných bloků je omezená. Každý blok má cílovou velikost 30 milionů jednotek, ale velikost bloků se bude zvyšovat nebo snižovat v závislosti na požadavcích sítě, až do limitu bloku 60 milionů jednotek (2x cílová velikost bloku). Limit jednotek na jeden blok může být upraven směrem nahoru nebo dolů faktorem 1/1024 oproti limitu jednotek předchozího bloku. Výsledkem je, že validátoři mohou prostřednictvím konsenzu měnit limit jednotek na jeden blok. Celkové množství jednotek spotřebované všemi transakcemi v bloku musí být menší než limit jednotek pro blok. To je důležité, protože je díky tomu zajištěno, že bloky nemohou být libovolně velké. Pokud by bloky mohly být libovolně velké, pak by méně výkonné plné uzly postupně přestávaly být schopny držet krok se sítí kvůli požadavkům na prostor a rychlost. Čím větší je blok, tím větší výpočetní výkon je potřeba k jeho včasnému zpracování pro další slot. Toto je centralizující síla, proti které se bojuje omezením velikosti bloků.
+Poslední důležitou poznámkou je, že velikost samotných bloků je omezená. Každý blok má cílovou velikost 30 milionů jednotek paliva, ale velikost bloků se bude zvyšovat nebo snižovat v souladu s požadavky sítě, až do limitu bloku 60 milionů jednotek paliva (2x cílová velikost bloku). Limit jednotek na jeden blok může být upraven směrem nahoru nebo dolů faktorem 1/1024 oproti limitu jednotek předchozího bloku. Výsledkem je, že validátoři mohou prostřednictvím konsenzu měnit limit jednotek na jeden blok. Celkové množství jednotek spotřebované všemi transakcemi v bloku musí být menší než limit jednotek pro blok. To je důležité, protože je díky tomu zajištěno, že bloky nemohou být libovolně velké. Pokud by bloky mohly být libovolně velké, pak by méně výkonné plné uzly postupně přestávaly být schopny držet krok se sítí kvůli požadavkům na prostor a rychlost. Čím větší je blok, tím větší výpočetní výkon je potřeba k jeho včasnému zpracování pro další slot. Toto je centralizující síla, proti které se bojuje omezením velikosti bloků.
## Další čtení {#further-reading}
-_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ji!_
+_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_
-## Příbuzná témata {#related-topics}
+## Související témata {#related-topics}
- [Transakce](/developers/docs/transactions/)
- [Palivo](/developers/docs/gas/)
diff --git a/public/content/translations/cs/developers/docs/bridges/index.md b/public/content/translations/cs/developers/docs/bridges/index.md
new file mode 100644
index 00000000000..1d2f1e8672b
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/bridges/index.md
@@ -0,0 +1,138 @@
+---
+title: Přemostění
+description: Přehled přemostění pro vývojáře
+lang: cs
+---
+
+S rozmachem L1 blockchainů a L2 [škalovacích](/developers/docs/scaling/) řešení, spolu s rostoucím počtem decentralizovaných aplikací, které fungují napříč různými sítěmi, se potřeba komunikace a přesunu aktiv mezi těmito sítěmi stala nezbytnou součástí síťové infrastruktury. Existuje několik typů přemostění (bridges), které tuto potřebu pomáhají naplnit.
+
+## Potřeba přemostění {#need-for-bridges}
+
+Přemostění existují proto, aby propojily blockchainové sítě. Umožňují propojení a interoperabilitu mezi blockchainy.
+
+Blockchainy fungují v oddělených prostředích, což znamená, že neexistuje přirozený způsob, jak by si blockchainy mohly vyměňovat data a komunikovat mezi sebou. V důsledku toho, i když by v určitém ekosystému mohlo probíhat mnoho aktivity a inovací, je tento potenciál omezen nedostatkem propojení a interoperability s jinými ekosystémy.
+
+Přemostění nabízejí způsob, jak izolovaná blockchainová prostředí propojit. Vytvářejí přepravní cestu mezi blockchainy, kde mohou být tokeny, zprávy, libovolná data a dokonce i volání [chytrých kontraktů](/developers/docs/smart-contracts/) přenášena z jednoho řetězce na druhý.
+
+## Výhody přemostění {#benefits-of-bridges}
+
+Jednoduše řečeno, přemostění nabízí mnoho využití tím, že umožňuje blockchainovým sítím vyměňovat si data a přesouvat aktiva mezi sebou.
+
+Blockchainy mají unikátní silné stránky, slabiny a přístupy k vytváření aplikací (např. rychlost, propustnost, náklady atd.). Přemostění podporuje vývoj celého krypto ekosystému tím, že umožňuje blockchainům využívat inovace ostatních.
+
+Pro vývojáře přináší přemostění následující výhody:
+
+- přenos jakýchkoli dat, informací a aktiv napříč blockchainy.
+- nové funkce a využití pro protokoly, protože přemostění rozšiřují designový prostor, který mohou protokoly nabízet. Například protokol pro výnosové farmářství původně nasazený na Ethereum Mainnetu může nabídnout likviditní fondy napříč všemi EVM-kompatibilními řetězci.
+- příležitost využít silné stránky různých blockchainů. Například vývojáři mohou těžit z nižších poplatků nabízených různými L2 řešeními tím, že nasadí své dappky napříč rollupy a sidechainy a uživatelé se mezi nimi mohou volně pohybovat.
+- spolupráci mezi vývojáři z různých blockchainových ekosystémů na vytváření nových produktů.
+- nalákání uživatelů a komunit z různých ekosystémů do jejich dappek.
+
+## Jak přemostění fungují? {#how-do-bridges-work}
+
+I když existuje mnoho [typů designů přemostění](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/), tři způsoby, jak usnadnit přesun aktiv mezi řetězci, vynikají:
+
+- **Zamknutí a ražba –** Zamknete aktiva na zdrojovém řetězci a vyrazíte aktiva na cílovém řetězci.
+- **Spálení a ražba –** Spálíte aktiva na zdrojovém řetězci a vyrazíte aktiva na cílovém řetězci.
+- **Atomické swapy –** Směníte aktiva na zdrojovém řetězci za aktiva na cílovém řetězci s jinou stranou.
+
+## Typy přemostění {#bridge-types}
+
+Přemostění lze obvykle zařadit do jedné z následujících kategorií:
+
+- **Nativní přemostění –** Tato přemostění jsou obvykle vytvořena pro zavedení likvidity na konkrétním blockchainu, což usnadňuje uživatelům přesun prostředků do ekosystému. Například [Arbitrum Bridge](https://bridge.arbitrum.io/) je vytvořen pro snadný přechod uživatelů z Ethereum Mainnetu na Arbitrum. Další taková přemostění zahrnují Polygon PoS Bridge, [Optimism Gateway](https://app.optimism.io/bridge) atd.
+- **Přemostění založená na validátorech nebo orákulech –** Tato přemostění se spoléhají na externí sady validátorů nebo orákulí pro validaci přesunů mezi řetězci. Příklady: Multichain a Across.
+- **Generalizovaná přemostění pro přenos zpráv –** Tato přemostění mohou přenášet aktiva spolu se zprávami a libovolnými daty napříč řetězci. Příklady: Axelar, LayerZero a Nomad.
+- **Likviditní sítě –** Tato přemostění se primárně zaměřují na přenos aktiv z jednoho řetězce na druhý prostřednictvím atomických swapů. Obecně nepodporují přenos zpráv napříč řetězci. Příklady: Connext a Hop.
+
+## Kompromisy ke zvážení {#trade-offs}
+
+Dokonalá řešení u přemostění nenajdete. Spíše se jedná o kompromisy, které je třeba učinit, aby byl splněn určitý účel. Vývojáři a uživatelé mohou hodnotit přemostění na základě následujících faktorů:
+
+- **Bezpečnost –** Kdo verifikuje systém? Přemostění zabezpečená externími validátory jsou obvykle méně bezpečná než přemostění, která jsou lokálně nebo nativně zabezpečena validátory blockchainu.
+- **Pohodlí –** Jak dlouho trvá dokončení transakce a kolik transakcí musel uživatel podepsat? Pro vývojáře: Jak dlouho trvá integrace přemostění a jak složitý je proces?
+- **Konektivita –** Jaké jsou různé cílové řetězce, které může přemostění propojit (např. rollupy, sidechainy, jiné blockchainy L1 atd.) a jak obtížné je integrovat nový blockchain?
+- **Schopnost přenášet složitější data –** Umožňuje přemostění přenos zpráv a dalších složitějších dat napříč řetězci, nebo podporuje pouze meziřetězcový přesun aktiv?
+- **Nákladová efektivita –** Kolik stojí přesun aktiv mezi řetězci pomocí přemostění? Obvykle přemostění účtují pevný nebo proměnný poplatek v závislosti na palivových nákladech a likviditě specifických tras. Je také důležité zhodnotit nákladovou efektivitu přemostění na základě kapitálu potřebného k zajištění jeho bezpečnosti.
+
+Na vyšší úrovni lze přemostění dělit na ta, kterým musíte důvěřovat, a přemostění bez nutnosti důvěry.
+
+- **Ta, kterým musíte důvěřovat –** Tato přemostění jsou verifikována externě. Používají externí sadu ověřovatelů (federace s multi-sig, multi-party výpočetní systémy, síť orákulí) k odesílání dat napříč řetězci. Díky tomu mohou nabídnout skvělou konektivitu a umožnit plně generalizovaný přenos zpráv napříč řetězci. Také mají tendenci dobře fungovat s ohledem na rychlost a nákladovou efektivitu. Toto vše však přichází na úkor bezpečnosti, protože uživatelé se musí spolehnout na bezpečnost přemostění.
+- **Bez nutnosti důvěry –** Tato přemostění pro přenos zpráv a tokenů spoléhají na blockchainy, které propojují, a jejich validátory. Jsou "bez nutnosti důvěry", protože nepřidávají nové předpoklady vyžadující důvěru (kromě blockchainů). Z tohoto důvodu jsou přemostění bez nutnosti důvěry považována za bezpečnější než přemostění, kterým je potřeba důvěřovat.
+
+Pro hodnocení přemostění bez nutnosti důvěry na základě dalších faktorů je třeba je rozdělit je na generalizovaná přemostění pro přenos zpráv a likviditní sítě.
+
+- **Generalizovaná přemostění pro přenos zpráv –** Tato přemostění vynikají v oblasti bezpečnosti a schopnosti přenášet složitější data napříč řetězci. Obvykle jsou také dobrá z hlediska nákladové efektivity. Tyto silné stránky však obvykle přicházejí na úkor konektivity u přemostění s lehkým klientem (např. IBC) a rychlostních nevýhod pro optimistická přemostění (např. Nomad), která používají důkazy o podvodech.
+- **Likviditní sítě –** Tato přemostění používají pro přenos aktiv atomické swapy a jsou lokálně ověřovanými systémy (tj. používají validátory podkladových blockchainů k ověření transakcí). Díky tomu vynikají bezpečností a rychlostí. Kromě toho jsou považovány za relativně nákladově efektivní a nabízejí dobrou konektivitu. Hlavním kompromisem je však jejich neschopnost přenášet složitější data – například nepodporují přenos zpráv.
+
+## Rizika spojená s přemostěními {#risk-with-bridges}
+
+Přemostění mají na svědomí tři největší [hacky v DeFi](https://rekt.news/leaderboard/) a jsou stále v raných fázích vývoje. Použití jakéhokoli přemostění s sebou nese následující rizika:
+
+- **Riziko chyby v chytrém kontraktu –** I když mnoho přemostění úspěšně prošlo audity, stačí jedna chyba v chytrém kontraktu, aby byla aktiva vystavena hackům (např. [Wormhole Bridge na Solaně](https://rekt.news/wormhole-rekt/)).
+- **Systémová finanční rizika –** Mnoho přemostění používá zabalená aktiva k ražbě kanonických verzí původního aktiva na novém řetězci. To vystavuje ekosystém systémovému riziku, čehož jsme už u zneužitých zabalených verzí tokenů byli svědky.
+- **Riziko protistrany –** Některá přemostění využívají design, kterému musí uživatelé důvěřovat: Je zde nutné spoléhat se na předpoklad, že validátoři nebudou spolupracovat na odcizení prostředků uživatelů. Nutnost důvěřovat těmto třetím stranám vystavuje uživatele rizikům, jako jsou "rug pulls", cenzura a další škodlivé aktivity.
+- **Otevřené otázky –** Vzhledem k tomu, že přemostění jsou v raných fázích vývoje, existuje mnoho nezodpovězených otázek týkajících se toho, jak budou fungovat v různých tržních podmínkách, jako jsou období přetížení sítě nebo neočekávané události, jako jsou útoky na úrovni sítě nebo rollbacky stavu. Tato nejistota představuje jistá rizika, jejichž míra je ale zatím neznámá.
+
+## Jak mohou přemostění využívat dappky? Jak mohou dapps využívat přemostění? {#how-can-dapps-use-bridges}
+
+Níže uvádíme některá praktická použití, která mohou vzít vývojáři na vědomí při využívání přemostění a přenosu svých dappek napříč řetězci:
+
+### Integrace přemostění {#integrating-bridges}
+
+Existuje několik způsobů, jak mohou vývojáři přidat podporu pro přemostění:
+
+1. **Vytvoření vlastního přemostění –** Vytvoření bezpečného a spolehlivého přemostění není snadné, zejména pokud se rozhodnete pro cestu vyžadující minimální důvěru ze strany uživatele. Navíc to vyžaduje roky zkušeností a technických znalostí týkajících se škálovatelnosti a interoperability. Dále by to vyžadovalo najmout tým na plný úvazek, který by přemostění udržoval a zajišťoval dostatečnou likviditu, aby bylo neustále funkční.
+
+2. **Zobrazení více možností přemostění pro uživatele –** Mnoho [dapps](/developers/docs/dapps/) vyžaduje, aby uživatelé pro interakci s nimi vlastnili jejich nativní token. Aby uživatelé mohli získat přístup k těmto tokenům, nabízejí dappky na svých webových stránkách různé možnosti přemostění. Tento způsob je však jen rychlou opravou problému, protože uživatele odvádí pryč z rozhraní dappky a vyžaduje, aby interagovali s dalšími dappkami a přemostěními. Uživatel takové dappky získá dojem složitosti, který je navíc doprovázený zvýšeným rizikem chyb.
+
+3. **Integrace přemostění –** Toto řešení nevyžaduje, aby dapp posílala uživatele na externí rozhraní přemostění a DEXu. Umožňuje dappkám usnadnit onboarding uživatelů. Tento přístup má ale svá omezení:
+
+ - Posuzování a údržba přemostění jsou složité a časově náročné.
+ - Výběr jednoho přemostění vytváří jediný bod selhání a závislost.
+ - Dappka je omezeno schopnostmi přemostění.
+ - Samotná přemostění nemusí být dostatečná. Dappky mohou potřebovat DEXy kvůli větší funkčnosti, například pro meziblockchainové směny.
+
+4. **Integrace více přemostění –** Toto řešení řeší mnoho problémů spojených s integrací jediného přemostění. Má však také svá omezení, protože integrace více přemostění je náročná na zdroje a vytváří technickou a komunikační zátěž pro vývojáře - a ti jsou v kryptu momentálně nejvzácnějším zdrojem.
+
+5. **Integrace agregátoru přemostění –** Další možností pro dapps je integrace řešení agregace přemostění, které jim poskytne přístup k několika přemostěním. Agregátory přemostění dědí silné stránky všech agregovaných přemostění a nejsou tak omezeni schopnostmi jen jediného přemostění. Je důležité poznamenat, že agregátory přemostění obvykle udržují integraci přemostění, což zbavuje dappky nutnosti sledovat technické a provozní aspekty integrace přemostění.
+
+Nicméně, agregátory přemostění mají svá omezení. Například, i když mohou nabídnout více variant přemostění, na trhu je obvykle k dispozici ještě spousta dalších přemostění, které agregátor nenabízí. Navíc, stejně jako přemostění, jsou i agregátory přemostění vystaveny rizikům spojeným se smart kontrakty a technologií (více smart kontraktů = více rizik).
+
+Pokud se dappka rozhodne pro integraci přemostění nebo agregátoru, má na výběr z několika různých možností podle hloubky integrace. Například, pokud se jedná pouze o frontendovou integraci pro zlepšení onboardingu uživatelů, dappka by měla integrovat widget. Pokud je však integrace zaměřena na hlubší meziřetězové strategie jako staking, výnosové farmářství atd., dappka integruje SDK nebo API.
+
+### Nasazení dapp na více řetězců {#deploying-a-dapp-on-multiple-chains}
+
+K nasazení dapp na více řetězců mohou vývojáři používat vývojářské platformy jako [Alchemy](https://www.alchemy.com/), [Hardhat](https://hardhat.org/), [Moralis](https://moralis.io/) atd. Tyto platformy obvykle přicházejí s pluginy, které umožňují dappkám fungovat napříč blockchainy. Vývojáři mohou například využít deterministickou nasazovací proxy nabízenou pluginem [hardhat-deploy](https://github.com/wighawag/hardhat-deploy).
+
+#### Příklady:
+
+- [Jak vytvářet meziřetězcové dapps](https://moralis.io/how-to-build-cross-chain-dapps/)
+- [Vytvoření meziřetězcového tržiště s NFT](https://youtu.be/WZWCzsB1xUE)
+- [Moralis: Tvorba meziřetězcových NFT dapps](https://www.youtube.com/watch?v=ehv70kE1QYo)
+
+### Monitorování aktivity kontraktů napříč řetězci {#monitoring-contract-activity-across-chains}
+
+Pro monitorování aktivity kontraktů napříč řetězci mohou vývojáři použít subgrafy a vývojové platformy jako je Tenderly, které umožňují monitorovat smart kontrakty v reálném čase. Tyto platformy také nabízejí nástroje s rozšířenou funkcionalitou pro sledování aktivit napříč řetězci, jako je kontrola [událostí emitovaných kontrakty](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events) atd.
+
+#### Nástroje
+
+- [The Graph](https://thegraph.com/en/)
+- [Tenderly](https://tenderly.co/)
+
+## Další čtení {#further-reading}
+
+- [Blockchainová přemostění](/bridges/) – ethereum.org
+- [Rámec pro posuzování rizik přemostění od L2Beat](https://l2beat.com/bridges/summary)
+- [Blockchainová přemostění: Budování sítí kryptosítí](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) – 8. září 2021 – Dmitriy Berenzon
+- [Trilema interoperability](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) – 1. října 2021 – Arjun Bhuptani
+- [Klastry: Jak důvěryhodná přemostění a přemostění s minimalizovanou důvěrou utvářejí prostředí s více řetězci](https://blog.celestia.org/clusters/) – 4. října 2021 – Mustafa Al-Bassam
+- [LI.FI: U přemostění je důvěra spektrum](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) – 28. dubna 2022 – Arjun Chand
+- [Stav řešení interoperability rollupů](https://web.archive.org/web/20250428015516/https://research.2077.xyz/the-state-of-rollup-interoperability) – 20. června 2024 – Alex Hook
+- [Využití sdíleného zabezpečení pro bezpečnou meziřetězcovou interoperabilitu: Lagrangeovy státní výbory a další](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) – 12. června 2024 – Emmanuel Awosika
+
+Dále uvádíme některé zajímavé prezentace od [Jamese Prestwiche](https://twitter.com/_prestwich), které vám mohou pomoci porozumění přemostěním ještě prohloubit:
+
+- [Stavění přemostění, ne zděných zahrad](https://youtu.be/ZQJWMiX4hT0)
+- [Rozbor přemostění](https://youtu.be/b0mC-ZqN8Oo)
+- [Proč přemostění hoří](https://youtu.be/c7cm2kd20j8)
diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/index.md
new file mode 100644
index 00000000000..5b7297f8787
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/index.md
@@ -0,0 +1,92 @@
+---
+title: Mechanismy konsenzu
+description: Vysvětlení konsensuálních protokolů v distribuovaných systémech a jejich role v Ethereu.
+lang: cs
+---
+
+Pojem „mechanismus konsenzu“ se často hovorově používá pro protokoly „důkaz podílem“, „důkaz prací“ nebo „důkaz autoritou“. Jedná se však pouze o součásti mechanismů konsenzu, které chrání proti [útokům Sybil](/glossary/#sybil-attack). Mechanismy konsenzu jsou kompletní soubor myšlenek, protokolů a pobídek, které umožňují distribuované sadě uzlů dohodnout se na stavu blockchainu.
+
+## Předpoklady {#prerequisites}
+
+Pro lepší pochopení této stránky doporučujeme si nejprve přečíst náš [úvod do Etherea](/developers/docs/intro-to-ethereum/).
+
+## Co je to konsensus? {#what-is-consensus}
+
+Konsensem myslíme, že bylo dosaženo všeobecné shody. Představte si skupinu lidí, kteří jdou do kina. Pokud nedojde k neshodě ohledně navrhovaného výběru filmu, je dosaženo konsensu. Pokud dojde k neshodě, skupina musí mít prostředky, jak se rozhodnout, na který film se podívat. V krajních případech se skupina nakonec rozdělí.
+
+Pokud jde o blockchain Etherea, proces je formalizován a dosažení konsensu znamená, že se alespoň 66 % uzlů v síti shodne na globálním stavu sítě.
+
+## Co je to konsensuální mechanismus? {#what-is-a-consensus-mechanism}
+
+Termín mechanismus konsenzu se vztahuje na celý soubor protokolů, pobídek a myšlenek, které umožňují síti uzlů dohodnout se na stavu blockchainu.
+
+Ethereum používá mechanismus konsenzu založený na důkazu podílem, který odvozuje své krypto-ekonomické zabezpečení ze souboru odměn a pokut uplatňovaných na kapitál uzamčený stakery. Tato motivační struktura povzbuzuje jednotlivé stakery, aby provozovali poctivé validátory, trestá ty, kteří tak nečiní, a vytváří extrémně vysoké náklady na útok na síť.
+
+Dále existuje protokol, který řídí, jak jsou poctiví validátoři vybíráni, aby navrhovali nebo validovali bloky, zpracovávali transakce a hlasovali pro svůj pohled na začátek řetězce. Ve vzácných situacích, kdy se v blízkosti začátku řetězce nachází více bloků ve stejné pozici, existuje mechanismus výběru větve, který vybírá bloky, které tvoří „nejtěžší“ řetězec, měřeno počtem validátorů, kteří pro bloky hlasovali, váženým jejich zůstatkem vsazeného etheru.
+
+Některé koncepty jsou pro konsensus důležité, ale nejsou explicitně definovány v kódu, jako například dodatečné zabezpečení, které nabízí potenciální mimopásmová sociální koordinace jako poslední obranná linie proti útokům na síť.
+
+Tyto komponenty dohromady tvoří mechanismus konsenzu.
+
+## Typy mechanismů konsenzu {#types-of-consensus-mechanisms}
+
+### Založené na důkazu prací {#proof-of-work}
+
+Stejně jako Bitcoin, i Ethereum kdysi používalo konsensuální protokol založený na **důkazu prací (PoW)**.
+
+#### Tvorba bloku {#pow-block-creation}
+
+Těžaři soutěží o vytvoření nových bloků naplněných zpracovanými transakcemi. Vítěz se o nový blok podělí se zbytkem sítě a získá čerstvě vytěžené ETH. Závod vyhrává počítač, který dokáže nejrychleji vyřešit matematickou hádanku. Tím se vytvoří kryptografické spojení mezi aktuálním blokem a blokem, který mu předcházel. Vyřešení této hádanky je ona „práce“ v „důkazu prací“. Kanonický řetězec je pak určen pravidlem výběru větve, které vybírá sadu bloků, na jejichž vytěžení bylo vynaloženo nejvíce práce.
+
+#### Bezpečnost {#pow-security}
+
+Síť je bezpečná díky tomu, že k podvodu v řetězci byste potřebovali 51% výpočetního výkonu sítě. To by vyžadovalo tak obrovské investice do vybavení a energie, že byste pravděpodobně utratili více, než byste získali.
+
+Více o [důkazu prací](/developers/docs/consensus-mechanisms/pow/)
+
+### Založené na důkazu podílem {#proof-of-stake}
+
+Ethereum nyní používá konsensuální protokol založený na **důkazu podílem (PoS)**.
+
+#### Tvorba bloku {#pos-block-creation}
+
+Validátoři vytvářejí bloky. V každém slotu je náhodně vybrán jeden validátor, který se stane navrhovatelem bloku. Jejich konsensuální klient si vyžádá balíček transakcí jako „exekuční datovou část“ od spárovaného exekučního klienta. Toto zabalí do konsensuálních dat, aby vytvořili blok, který odešlou ostatním uzlům v síti Ethereum. Tato produkce bloků je odměňována v ETH. Ve vzácných případech, kdy pro jeden slot existuje více možných bloků nebo se uzly o blocích dozvědí v různou dobu, algoritmus výběru větve vybere blok, který tvoří řetězec s největší váhou atestací (kde váha je počet atestujících validátorů škálovaný jejich zůstatkem ETH).
+
+#### Bezpečnost {#pos-security}
+
+Systém důkazu podílem je krypto-ekonomicky bezpečný, protože útočník, který se pokusí převzít kontrolu nad řetězcem, musí zničit obrovské množství ETH. Systém odměn motivuje jednotlivé stakery k čestnému chování a pokuty je odrazují od škodlivého jednání.
+
+Více o [důkazu podílem](/developers/docs/consensus-mechanisms/pos/)
+
+### Vizuální průvodce {#types-of-consensus-video}
+
+Podívejte se na více informací o různých typech mechanismů konsenzu používaných v Ethereu:
+
+
+
+
+ Proof-of-work je nyní zastaralý. Ethereum už proof-of-work nepoužívá jako součást svého konsensuálního mechanismu. Místo toho používá proof-of-stake. Přečtěte si více o [důkazu podílem](/developers/docs/consensus-mechanisms/pos/) a [uzamčení](/staking/).
+
+
+
+
+## Předpoklady {#prerequisites}
+
+Abyste lépe porozuměli této stránce, doporučujeme vám si nejprve přečíst o [transakcích](/developers/docs/transactions/), [blocích](/developers/docs/blocks/) a [mechanismech konsenzu](/developers/docs/consensus-mechanisms/).
+
+## Co je důkaz prací (PoW)? {#what-is-pow}
+
+Nakamotův konsensus, který využívá důkaz prací, je mechanismus, který kdysi umožňoval decentralizované síti Ethereum dosáhnout konsenzu (tj. shody všech uzlů) na věcech, jako jsou zůstatky na účtech a pořadí transakcí. Tento mechanismus zabránil uživatelům v „dvojím utracení“ prostředků a zajistil, že Ethereum blockchain bylo mimořádně obtížné napadnout nebo s ním manipulovat. Tyto bezpečnostní vlastnosti nyní pocházejí z důkazu podílem za použití mechanismu konsenzu známého jako [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/).
+
+## Důkaz prací a těžba {#pow-and-mining}
+
+Proof-of-work je základní algoritmus, který stanovuje obtížnost a pravidla pro práci těžařů na proof-of-work blockchainech. Těžba je samotná "práce". Těžbou je myšleno přidávání platných bloků do řetězce. To je důležité, protože délka řetězce pomáhá síti sledovat správnou větev blockchainu. Čím více "práce" je vykonáno, tím delší je řetězec a čím vyšší je číslo bloku, tím jistější si síť může být aktuálním stavem věcí.
+
+[Více o těžbě](/developers/docs/consensus-mechanisms/pow/mining/)
+
+## Jak funguje proof-of-work na Ethereu? Jak to funguje {#how-it-works}
+
+Transakce na Ethereu se zpracovávají do bloků. Na nyní zastaralém proof-of-work Ethereu každý blok obsahoval:
+
+- obtížnost bloku - například: 3,324,092,183,262,715
+- mixHash – například: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29`
+- nonce – například: `0xd3ee432b4fb3d26b`
+
+Tato data bloku byla přímo spojena s proof-of-work.
+
+### Práce v důkazu prací {#the-work}
+
+Protokol proof-of-work, Ethash, vyžadoval, aby těžaři prošli intenzivním závodem sestávajícím z pokusů a omylů, aby našli jednorázové číslo bloku. Pouze bloky s platným jednorázovým číslem mohly být přidány do řetězce.
+
+Při závodě o vytvoření bloku těžař opakovaně procházel datovou sadu, kterou bylo možné získat pouze stažením a provozováním celého řetězce (což těžaři dělají), pomocí matematické funkce. Tato datová sada byla použita k vygenerování mixHashe, který byl pod cílovou hodnotou určenou obtížností bloku. Nejlepší způsob, jak toho dosáhnout, je metoda pokusů a omylů.
+
+Obtížnost určovala cíl pro hash. Čím nižší je cílová hodnota, tím menší je množina platných hashů. Jakmile byl hash vygenerován, bylo pro ostatní těžaře a klienty velmi snadné jej ověřit. I malá změna v transakci by vedla k úplně jinému hashi, což by signalizovalo podvod.
+
+Díky hashování je podvod snadno odhalitelný. Ale proof-of-work jako proces byl také velkým odrazujícím prvkem proti útokům na řetězec.
+
+### Důkaz prací a bezpečnost {#security}
+
+Těžaři byli motivováni vykonávat tuto práci na Ethereum Mainnetu. Podskupina těžařů měla jen malou motivaci k tomu, aby si založila vlastní řetězec - podkopává to celý systém. Blockchainy se spoléhají na to, že mají jediný stav jako zdroj pravdy.
+
+Cílem proof-of-work bylo prodloužit řetězec. Nejdelší řetězec byl považován za nejvěrohodnější, protože na něm bylo provedeno nejvíce výpočetní práce. V rámci Ethereum systému PoW bylo téměř nemožné vytvářet nové bloky, které by vymazaly transakce, vytvořily falešné bloky nebo udržovaly druhý řetězec. To proto, že by těžař s úmyslem poškodit blockchain musel vždy vypočítat jedinečné číslo bloku rychleji než ostatní.
+
+Aby zlý těžař mohl konzistentně vytvářet škodlivé, ale platné bloky, musel by mít více než 51 % výpočetní síly sítě, aby porazil ostatní těžaře. Takové množství „práce“ vyžaduje značné množství drahé výpočetní síly a náklady na energii by mohly dokonce převýšit zisky útoku.
+
+### Ekonomika důkazu prací {#economics}
+
+Proof-of-work byl také zodpovědný za vytváření nové měny v systému a za motivaci těžařů k vykonávání práce.
+
+Od [upgradu Constantinople](/ethereum-forks/#constantinople) byli těžaři, kteří úspěšně vytvořili blok, odměněni dvěma nově vyraženými ETH a částí transakčních poplatků. Ommer bloky byly také kompenzovány částkou 1,75 ETH. Ommer bloky byly platné bloky vytvořené těžařem prakticky ve stejnou dobu jako jiný těžař vytvořil kanonický blok, přičemž rozhodující bylo, který blok byl přidán ke stávajícímu řetězci jako první. Ommer bloky se obvykle objevovaly kvůli latenci sítě.
+
+## Konečnost {#finality}
+
+Transakce má na Ethereu „konečnost“, když je součástí bloku, který se nemůže změnit.
+
+Protože těžaři pracovali decentralizovaným způsobem, mohly být současně vytěženy dva platné bloky. To vedlo k dočasnémuu větvení řetězce. Nakonec se jeden z těchto řetězců stal přijatým řetězcem poté, co byly vytěženy a přidány další bloky, čímž se stal delším.
+
+Aby se věci ještě více zkomplikovaly, transakce, které byly zamítnuty na dočasné větvi, nemusely být zahrnuty v přijatém řetězci. To znamená, že mohlo dojít k jejich zrušení. Konečnost se tedy týká doby, po kterou byste měli vyčkat, než lze transakci považovat za nevratnou. V předchozím Ethereu s důkazem prací platilo, že čím více bloků bylo vytěženo nad konkrétním blokem `N`, tím vyšší byla důvěra, že transakce v `N` byly úspěšné a nebudou zrušeny. Nyní, s proof-of-stake, je konečnost explicitní vlastností bloku, nikoli probabilistickou.
+
+## Spotřeba energie u důkazu prací {#energy}
+
+Hlavní kritikou proof-of-work je množství energie potřebné k udržení bezpečnosti sítě. Aby si Ethereum udrželo míru bezpečnosti a decentralizace, spotřebovávalo velké množství energie. Krátce před přechodem na důkaz podílem těžaři Etherea kolektivně spotřebovávali přibližně 70 TWh/rok (přibližně stejně jako Česká republika – podle [digiconomist](https://digiconomist.net/) k 18. červenci 2022).
+
+## Výhody a nevýhody {#pros-and-cons}
+
+| Plusy | Minusy |
+| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Proof-of-work je neutrální. Pro začátek nepotřebujete ETH a odměny za bloky vám umožní přejít z 0ETH do kladného zůstatku. U [důkazu podílem](/developers/docs/consensus-mechanisms/pos/) potřebujete pro začátek ETH. | Proof-of-work spotřebovává tolik energie, že je škodlivý pro životní prostředí. |
+| Proof-of-work je osvědčený a vyzkoušený konsensuální mechanismus, který udržoval Bitcoin a Ethereum bezpečné a decentralizované po mnoho let. | Pokud chcete těžit, potřebujete tak specializované vybavení, že je to pro začátek velká investice. |
+| Ve srovnání s proof-of-stake je jeho implementace relativně snadná. | Vzhledem k rostoucí potřebě výpočtů by těžební pooly mohly potenciálně ovládnout těžbu, což by vedlo k centralizaci a bezpečnostním rizikům. |
+
+## Srovnání s důkazem podílem {#compared-to-pos}
+
+Z obecného pohledu má proof-of-stake stejný cíl jako proof-of-work: Pomoci decentralizované síti bezpečně dosáhnout konsensu. Má však některé rozdíly v procesu a personálu:
+
+- Proof-of-stake nahrazuje důležitost výpočetní síly stakovaným ETH.
+- Proof-of-stake nahrazuje těžaře validátory. Validátoři uzamikají své ETH, aby aktivovali schopnost vytvářet nové bloky.
+- Validátoři nesoutěží o vytváření bloků, místo toho jsou náhodně vybíráni algoritmem.
+- Konečnost je jasnější: pokud se v určitých kontrolních bodech 2/3 validátorů shodnou na stavu bloku, je považován za konečný. Validátoři na to musí vsadit celý svůj vklad, takže pokud se pokusí o tajnou dohodu bokem, přijdou o celý svůj vklad.
+
+[Více o důkazu podílem](/developers/docs/consensus-mechanisms/pos/)
+
+## Učíte se spíše vizuálně? Vizuální výuka {#visual-learner}
+
+
+
+
+Proof-of-work již není základním mechanismem konsensu Etherea, což znamená, že těžení bylo vypnuto. Místo toho je Ethereum zabezpečeno validátory, kteří stakují ETH. Své ETH můžete začít stakeovat hned dnes. Přečtěte si více o Sloučení, proof-of-stake a stakování. Tato stránka má pouze historický význam.
+
+
+
+
+## Předpoklady {#prerequisites}
+
+Pro lepší pochopení této stránky doporučujeme si nejprve přečíst o [transakcích](/developers/docs/transactions/), [blocích](/developers/docs/blocks/) a [důkazu prací](/developers/docs/consensus-mechanisms/pow/).
+
+## Co je to těžba Etherea? Co je to těžba Etherea? {#what-is-ethereum-mining}
+
+Těžení je proces vytváření bloků transakcí, které byly přidávány do blockchainu Etherea v dříve používané architektuře proof-of-work.
+
+Slovo „těžení“ pochází z analogie se zlatem v kontextu kryptoměn. Zlaté nebo cenné kovy jsou vzácné, stejně jako digitální tokeny, a jediným způsobem, jak zvýšit jejich celkový objem v systému proof-of-work, je těžení. Na proof-of-work Ethereu byl jediný způsob, jak vydávat nové ETH, právě těžba. Na rozdíl od zlata nebo cenných kovů však těžení Etherea také sloužilo k zabezpečení sítě tím, že vytvářelo, ověřovalo, publikovalo a šířilo bloky blockchainu.
+
+Těžení etheru = Zabezpečení sítě
+
+Těžení je krví každého blockchainu založeného na proof-of-work. Těžaři Etherea – počítače, na kterých je spuštěn software – používali před přechodem na proof-of-stake svůj čas a výpočetní výkon ke zpracovávání transakcí a vytváření bloků.
+
+## Proč těžaři existují? {#why-do-miners-exist}
+
+V decentralizovaných systémech, jako je Ethereum, musíme zajistit, aby se všichni shodli na pořadí transakcí. Těžaři tomu napomáhají tím, že řeší výpočetně náročné "hádanky" a vytvářejí tak bloky, které slouží k zabezpečení sítě před útoky.
+
+[Více o důkazu prací](/developers/docs/consensus-mechanisms/pow/)
+
+Dříve měl každý možnost těžit na síti Ethereum pomocí svého počítače. Avšak ne každý mohl těžit ether (ETH) ziskově. V mnoha případech museli těžaři investovat do specializovaného počítačového hardwaru a mít přístup k levným zdrojům energie. Průměrný počítač pravděpodobně nikdy nevydělal dost prostředků na pokrytí nákladů spojených s těžením.
+
+### Náklady na těžbu {#cost-of-mining}
+
+- Potenciální náklady na hardware potřebný k vybudování a údržbě těžebního zařízení
+- Náklady napájení těžebního zařízení elektřinou
+- Pokud jste těžili v těžebním poolu, účtovaly vám tyto pooly obvykle pevný procentuální poplatek z každého bloku generovaného poolem
+- Potenciální náklady na vybavení pro podporu těžebního zařízení (ventilace, monitoring energie, elektrické vedení atd.)
+
+Pro podrobnější prozkoumání ziskovosti těžby použijte kalkulačku těžby, například tu, kterou poskytuje [Etherscan](https://etherscan.io/ether-mining-calculator).
+
+## Jak se těžily transakce na Ethereu {#how-ethereum-transactions-were-mined}
+
+Následující text je přehledem způsobu těžby na proof-of-work Ethereu. Analogický popis tohoto procesu pro Ethereum s důkazem podílem najdete [zde](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos).
+
+1. Uživatel napíše a podepíše požadavek na [transakci](/developers/docs/transactions/) privátním klíčem nějakého [účtu](/developers/docs/accounts/).
+2. Uživatel odešle požadavek na transakci do celé sítě Ethereum z nějakého [uzlu](/developers/docs/nodes-and-clients/).
+3. Jakmile se o novém požadavku na transakci dozví, každý uzel v Ethereum síti přidá požadavek do svého lokálního mempoolu, seznamu všech požadavků na transakci, o kterých se dozvěděl a které ještě nebyly odevzdány v bloku do blockchainu.
+4. V určitém okamžiku těžební uzel agreguje několik desítek nebo stovek požadavků na transakce do potenciálního [bloku](/developers/docs/blocks/) tak, aby maximalizoval [transakční poplatky](/developers/docs/gas/), které vydělá, a zároveň se udržel pod palivovým limitem bloku. Těžební uzel pak:
+ 1. Ověří platnost každého požadavku na transakci (tj. nikdo se nepokouší převést ether z účtu, pro který nevytvořil podpis, požadavek není chybný atd.), a poté provede kód požadavku, čímž změní stav své lokální kopie EVM. Těžař obdrží transakční poplatek za každý takový požadavek na svůj vlastní účet.
+ 2. Zahájí proces vytváření „certifikátu legitimity“ důkazu prací pro potenciální blok, jakmile jsou všechny požadavky na transakce v bloku ověřeny a provedeny na místní kopii EVM.
+5. Nakonec těžař dokončí vytvoření certifikátu pro blok, který obsahuje náš konkrétní požadavek na transakci. Těžař pak vyšle dokončený blok, který obsahuje certifikát a kontrolní součet nárokovaného nového stavu EVM.
+6. Ostatní uzly se o novém bloku dozvědí. Ověří certifikát, samy provedou všechny transakce na bloku (včetně transakce původně vyslané naším uživatelem) a ověří, zda se kontrolní součet jejich nového stavu EVM po provedení všech transakcí shoduje s kontrolním součtem stavu deklarovaného blokem těžaře. Teprve poté tyto uzly připojí tento blok na konec svého blockchainu a přijmou nový stav EVM jako kanonický stav.
+7. Každý uzel odstraní všechny transakce v novém bloku ze svého lokálního mempoolu nesplněných transakčních požadavků.
+8. Nové uzly, které se připojují k síti, stahují postupně všechny bloky, včetně bloku obsahujícího naši sledovanou transakci. Inicializují lokální kopii EVM (která začíná prázdném stavu) a poté procházejí procesem provádění všech transakcí v každém bloku nad svou lokální kopií EVM a cestou ověřují kontrolní součty stavu v každém bloku.
+
+Každá transakce je vytěžena (zařazena do nového bloku a poprvé propagována) jednou, ale provedena a ověřena každým účastníkem procesu postupu kanonického stavu EVM. To zdůrazňuje jednu z ústředních manter blockchainu: **Nevěř, ověřuj**.
+
+## Ommer (uncle) bloky {#ommer-blocks}
+
+Těžení bloků v proof-of-work bylo pravděpodobnostní, což znamená, že někdy byly současně publikovány dva platné bloky kvůli latenci sítě. V takovém případě musel protokol určit nejdelší (a tedy nejvíce „platný“) řetězec, přičemž zajistil spravedlnost vůči těžařům tím, že částečně odměnil nezařazený platný blok. To podpořilo další decentralizaci sítě, protože menší těžaři, kteří mohli čelit větší latenci, mohli stále generovat výnosy prostřednictvím odměn za [ommer](/glossary/#ommer) bloky.
+
+Termín „ommer“ je preferovaný genderově neutrální termín pro sourozence rodičovského bloku, ale někdy se také používá termín „strýc“ (uncle). **Od přechodu Etherea na důkaz podílem se ommer bloky již netěží**, protože v každém slotu je zvolen pouze jeden navrhovatel. Tuto změnu můžete vidět na [historickém grafu](https://ycharts.com/indicators/ethereum_uncle_rate) ommer bloků, které byly těženy.
+
+## Vizuální ukázka {#a-visual-demo}
+
+Podívejte se, jak vás Austin provede těžbou a PoS blockchainem.
+
+xᵐ mod P ≡ 1
+Vzhledem k těmto definicím máme:
+
+> Pozorování 1. Nechť `x` je členem multiplikativní skupiny `ℤ/Pℤ` pro bezpečné prvočíslo `P`. Pokud `x mod P ≠ 1 mod P` a `x mod P ≠ P-1 mod P`, pak řád `x` je buď `P-1` nebo `(P-1)/2`.
+
+_Důkaz_. Protože `P` je bezpečné prvočíslo, pak podle [Lagrangeovy věty][lagrange] máme, že řád `x` je buď `1`, `2`, `(P-1)/2` nebo `P-1`.
+
+Řád `x` nemůže být `1`, protože podle Malé Fermatovy věty máme:
+
+xP-1 mod P ≡ 1
+
+Proto musí být `x` multiplikativní identitou `ℤ/nℤ`, která je jedinečná. Protože jsme předpokládali, že `x ≠ 1`, není to možné.
+
+Řád `x` nemůže být `2`, pokud `x ≠ P-1`, protože by to porušilo, že `P` je prvočíslo.
+
+Z výše uvedeného tvrzení můžeme rozpoznat, že iterace `(picker * init) % P` bude mít délku cyklu alespoň `(P-1)/2`. Je to proto, že jsme zvolili `P` jako bezpečné prvočíslo přibližně rovné vyšší mocnině dvou a `init` je v intervalu `[2,2**256+1]`. Vzhledem k velikosti `P` bychom nikdy neměli očekávat cyklus z modulárního umocňování.
+
+Když přiřazujeme první buňku v DAG (proměnná označená `init`), vypočítáme `pow(sha3(seed) + 2, 3, P)`. Na první pohled to nezaručuje, že výsledek nebude ani `1`, ani `P-1`. Protože je však `P-1` bezpečné prvočíslo, máme následující další ujištění, které je důsledkem Pozorování 1:
+
+> Pozorování 2. Nechť `x` je členem multiplikativní skupiny `ℤ/Pℤ` pro bezpečné prvočíslo `P` a nechť `w` je přirozené číslo. Pokud `x mod P ≠ 1 mod P` a `x mod P ≠ P-1 mod P`, a také `w mod P ≠ P-1 mod P` a `w mod P ≠ 0 mod P`, pak `xʷ mod P ≠ 1 mod P` a `xʷ mod P ≠ P-1 mod P`
+
+### Modulární umocňování jako hašovací funkce {#modular-exponentiation}
+
+Pro určité hodnoty `P` a `w` může mít funkce `pow(x, w, P)` mnoho kolizí. Například `pow(x,9,19)` nabývá pouze hodnot `{1,18}`.
+
+Vzhledem k tomu, že `P` je prvočíslo, lze pomocí následujícího výsledku zvolit vhodné `w` pro hašovací funkci modulárního umocňování:
+
+> Pozorování 3. Nechť `P` je prvočíslo; `w` a `P-1` jsou nesoudělná právě tehdy, když pro všechna `a` a `b` v `ℤ/Pℤ` platí:`aʷ mod P ≡ bʷ mod P` právě tehdy, když `a mod P ≡ b mod P`
+
+Vzhledem k tomu, že `P` je prvočíslo a `w` je nesoudělné s `P-1`, máme tedy `|{pow(x, w, P) : x ∈ ℤ}| = P`, z čehož vyplývá, že hašovací funkce má nejmenší možnou míru kolizí.
+
+Ve zvláštním případě, že `P` je bezpečné prvočíslo, jak jsme si zvolili, pak `P-1` má pouze dělitele 1, 2, `(P-1)/2` a `P-1`. Protože `P` > 7, víme, že 3 je nesoudělné s `P-1`, a proto `w=3` splňuje výše uvedené tvrzení.
+
+## Efektivnější algoritmus vyhodnocování založený na mezipaměti {#cache-based-evaluation}
+
+```python
+def quick_calc(params, seed, p):
+ cache = produce_dag(params, seed, params["cache_size"])
+ return quick_calc_cached(cache, params, p)
+
+def quick_calc_cached(cache, params, p):
+ P = params["P"]
+ if p < len(cache):
+ return cache[p]
+ else:
+ x = pow(cache[0], p + 1, P)
+ for _ in range(params["k"]):
+ x ^= quick_calc_cached(cache, params, x % p)
+ return pow(x, params["w"], P)
+
+def quick_hashimoto(seed, dagsize, params, header, nonce):
+ cache = produce_dag(params, seed, params["cache_size"])
+ return quick_hashimoto_cached(cache, dagsize, params, header, nonce)
+
+def quick_hashimoto_cached(cache, dagsize, params, header, nonce):
+ m = dagsize // 2
+ mask = 2**64 - 1
+ mix = sha3(encode_int(nonce) + header)
+ for _ in range(params["accesses"]):
+ mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m)
+ return dbl_sha3(mix)
+```
diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md
new file mode 100644
index 00000000000..93e4f1fa923
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md
@@ -0,0 +1,1019 @@
+---
+title: Ethash
+description: Podrobný pohled na algoritmus Ethash.
+lang: cs
+---
+
+
+
+
+ Ethash byl algoritmus Etherea pro těžbu s důkazem prací. Důkaz prací byl nyní **zcela vypnut** a Ethereum je místo toho zabezpečeno pomocí [důkazu podílem](/developers/docs/consensus-mechanisms/pos/). Přečtěte si více o [Sloučení](/roadmap/merge/), [důkazu podílem](/developers/docs/consensus-mechanisms/pos/) a [uzamčení](/staking/). Tato stránka má pouze historickou hodnotu!
+
+
+
+
+Ethash je upravená verze algoritmu [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). Důkaz prací Ethash je [paměťově náročný](https://wikipedia.org/wiki/Memory-hard_function), díky čemuž se předpokládalo, že je algoritmus odolný vůči ASIC. Nakonec byly vyvinuty ASIC pro Ethash, ale těžba pomocí GPU byla stále reálnou možností, dokud nebyl vypnut důkaz prací. Ethash se stále používá k těžbě jiných coinů na jiných ne-ethereových sítích s důkazem prací.
+
+## Jak Ethash funguje? {#how-does-ethash-work}
+
+Paměťové náročnosti je dosaženo pomocí algoritmu důkazu prací, který vyžaduje výběr podmnožin z pevně daného zdroje v závislosti na nonce a hlavičce bloku. Tento zdroj (o velikosti několika gigabytů) se nazývá DAG. DAG se mění každých 30 000 bloků, což je ~125hodinové okno nazývané epocha (přibližně 5,2 dne), a jeho generování chvíli trvá. Protože DAG závisí pouze na výšce bloku, může být předem vygenerován, ale pokud není, musí klient počkat do konce tohoto procesu, aby mohl vytvořit blok. Pokud klienti negenerují a neukládají DAGy do mezipaměti předem, může na síti docházet k masivnímu zpoždění bloků při každém přechodu epochy. Všimněte si, že DAG nemusí být generován pro ověření důkazu prací, což v podstatě umožňuje ověření s nízkým využitím CPU a malou pamětí.
+
+Obecný postup, který algoritmus používá, je následující:
+
+1. Existuje **seed**, který lze vypočítat pro každý blok proskenováním hlaviček bloků až do daného bodu.
+2. Ze seedu lze vypočítat **16MB pseudonáhodnou mezipaměť**. Lehcí klienti ukládají mezipaměť.
+3. Z mezipaměti můžeme vygenerovat **1GB datovou sadu** s vlastností, že každá položka v datové sadě závisí pouze na malém počtu položek z mezipaměti. Plní klienti a těžaři ukládají datovou sadu. Datová sada roste lineárně s časem.
+4. Těžba zahrnuje získávání náhodných výřezů z datové sady a jejich společné hašování. Ověření lze provést s malou pamětí použitím mezipaměti k regeneraci specifických částí datové sady, které potřebujete, takže stačí ukládat pouze mezipaměť.
+
+Velká datová sada se aktualizuje jednou za 30 000 bloků, takže drtivá většina úsilí těžaře bude spočívat ve čtení datové sady, nikoli v jejích změnách.
+
+## Definice {#definitions}
+
+Používáme následující definice:
+
+```
+WORD_BYTES = 4 # bajtů ve slově
+DATASET_BYTES_INIT = 2**30 # bajtů v datové sadě při genezi
+DATASET_BYTES_GROWTH = 2**23 # růst datové sady za epochu
+CACHE_BYTES_INIT = 2**24 # bajtů v mezipaměti při genezi
+CACHE_BYTES_GROWTH = 2**17 # růst mezipaměti za epochu
+CACHE_MULTIPLIER=1024 # Velikost DAG relativně k mezipaměti
+EPOCH_LENGTH = 30000 # bloků za epochu
+MIX_BYTES = 128 # šířka mixu
+HASH_BYTES = 64 # délka haše v bajtech
+DATASET_PARENTS = 256 # počet rodičů každého prvku datové sady
+CACHE_ROUNDS = 3 # počet kol při produkci mezipaměti
+ACCESSES = 64 # počet přístupů ve smyčce hashimoto
+```
+
+### Použití 'SHA3' {#sha3}
+
+Vývoj Etherea se shodoval s vývojem standardu SHA3 a v procesu standardizace došlo k pozdní změně ve výplni finalizovaného hašovacího algoritmu, takže ethereové haše \"sha3_256\" a \"sha3_512\" nejsou standardními haši sha3, ale variantou, která je v jiných kontextech často označována jako \"Keccak-256\" a \"Keccak-512\". Viz diskuse, např. [zde](https://eips.ethereum.org/EIPS/eip-1803), [zde](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use), nebo [zde](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057).
+
+Mějte to prosím na paměti, jelikož se na haše \"sha3\" odkazuje v níže uvedeném popisu algoritmu.
+
+## Parametry {#parameters}
+
+Parametry pro mezipaměť a datovou sadu Ethashe závisí na čísle bloku. Velikost mezipaměti i velikost datové sady rostou lineárně; nicméně vždy bereme nejvyšší prvočíslo pod lineárně rostoucí prahovou hodnotou, abychom snížili riziko náhodných pravidelností vedoucích k cyklickému chování.
+
+```python
+def get_cache_size(block_number):
+ sz = CACHE_BYTES_INIT + CACHE_BYTES_GROWTH * (block_number // EPOCH_LENGTH)
+ sz -= HASH_BYTES
+ while not isprime(sz / HASH_BYTES):
+ sz -= 2 * HASH_BYTES
+ return sz
+
+def get_full_size(block_number):
+ sz = DATASET_BYTES_INIT + DATASET_BYTES_GROWTH * (block_number // EPOCH_LENGTH)
+ sz -= MIX_BYTES
+ while not isprime(sz / MIX_BYTES):
+ sz -= 2 * MIX_BYTES
+ return sz
+```
+
+Tabulky hodnot velikosti datové sady a mezipaměti jsou uvedeny v příloze.
+
+## Generování mezipaměti {#cache-generation}
+
+Nyní specifikujeme funkci pro vytvoření mezipaměti:
+
+```python
+def mkcache(cache_size, seed):
+ n = cache_size // HASH_BYTES
+
+ # Sekvenčně vytvoří počáteční datovou sadu
+ o = [sha3_512(seed)]
+ for i in range(1, n):
+ o.append(sha3_512(o[-1]))
+
+ # Použije verzi randmemohash s nízkým počtem kol
+ for _ in range(CACHE_ROUNDS):
+ for i in range(n):
+ v = o[i][0] % n
+ o[i] = sha3_512(map(xor, o[(i-1+n) % n], o[v]))
+
+ return o
+```
+
+Proces produkce mezipaměti zahrnuje nejprve sekvenční zaplnění 32 MB paměti, poté provedení dvou průchodů algoritmu _RandMemoHash_ Sergia Demiana Lernera z práce [_Strict Memory Hard Hashing Functions_ (2014)](http://www.hashcash.org/papers/memohash.pdf). Výstupem je sada 524 288 64bajtových hodnot.
+
+## Funkce agregace dat {#date-aggregation-function}
+
+V některých případech používáme algoritmus inspirovaný [hašem FNV](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) jako neasociativní náhradu za XOR. Všimněte si, že prvočíslo násobíme celým 32bitovým vstupem, na rozdíl od specifikace FNV-1, která postupně násobí prvočíslo jedním bajtem (oktetem).
+
+```python
+FNV_PRIME = 0x01000193
+
+def fnv(v1, v2):
+ return ((v1 * FNV_PRIME) ^ v2) % 2**32
+```
+
+Upozorňujeme, že i když yellow paper (žlutá kniha) specifikuje fnv jako v1\*(FNV_PRIME ^ v2), všechny současné implementace konzistentně používají výše uvedenou definici.
+
+## Výpočet plné datové sady {#full-dataset-calculation}
+
+Každá 64bajtová položka v plné 1GB datové sadě se vypočítá následovně:
+
+```python
+def calc_dataset_item(cache, i):
+ n = len(cache)
+ r = HASH_BYTES // WORD_BYTES
+ # inicializace mixu
+ mix = copy.copy(cache[i % n])
+ mix[0] ^= i
+ mix = sha3_512(mix)
+ # fnv s mnoha náhodnými uzly mezipaměti na základě i
+ for j in range(DATASET_PARENTS):
+ cache_index = fnv(i ^ j, mix[j % r])
+ mix = map(fnv, mix, cache[cache_index % n])
+ return sha3_512(mix)
+```
+
+V podstatě kombinujeme data z 256 pseudonáhodně vybraných uzlů mezipaměti a hašujeme je, abychom vypočítali uzel datové sady. Celá datová sada je pak generována pomocí:
+
+```python
+def calc_dataset(full_size, cache):
+ return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)]
+```
+
+## Hlavní smyčka {#main-loop}
+
+Nyní specifikujeme hlavní smyčku podobnou \"hashimoto\", kde agregujeme data z plné datové sady, abychom vytvořili naši konečnou hodnotu pro konkrétní hlavičku a nonce. V níže uvedeném kódu `header` představuje _haš_ SHA3-256 reprezentace RLP _zkrácené_ hlavičky bloku, tj. hlavičky s vyloučením polí **mixHash** a **nonce**. `nonce` je osm bajtů 64bitového celého čísla bez znaménka v pořadí big-endian. Takže `nonce[::-1]` je osmibajtová reprezentace této hodnoty v pořadí little-endian:
+
+```python
+def hashimoto(header, nonce, full_size, dataset_lookup):
+ n = full_size / HASH_BYTES
+ w = MIX_BYTES // WORD_BYTES
+ mixhashes = MIX_BYTES / HASH_BYTES
+ # zkombinuje header+nonce do 64bajtového seedu
+ s = sha3_512(header + nonce[::-1])
+ # spustí mix s replikovaným s
+ mix = []
+ for _ in range(MIX_BYTES / HASH_BYTES):
+ mix.extend(s)
+ # přimíchá náhodné uzly datové sady
+ for i in range(ACCESSES):
+ p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes
+ newdata = []
+ for j in range(MIX_BYTES / HASH_BYTES):
+ newdata.extend(dataset_lookup(p + j))
+ mix = map(fnv, mix, newdata)
+ # komprimuje mix
+ cmix = []
+ for i in range(0, len(mix), 4):
+ cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3]))
+ return {
+ "mix digest": serialize_hash(cmix),
+ "result": serialize_hash(sha3_256(s+cmix))
+ }
+
+def hashimoto_light(full_size, cache, header, nonce):
+ return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x))
+
+def hashimoto_full(full_size, dataset, header, nonce):
+ return hashimoto(header, nonce, full_size, lambda x: dataset[x])
+```
+
+V podstatě udržujeme \"mix\" o šířce 128 bajtů a opakovaně sekvenčně načítáme 128 bajtů z plné datové sady a používáme funkci `fnv` ke zkombinování s mixem. Používá se 128 bajtů sekvenčního přístupu, takže každé kolo algoritmu vždy načte celou stránku z paměti RAM, čímž se minimalizují chyby v translation lookaside bufferu (vyrovnávací paměti pro překlad adres), kterým by se teoreticky mohly vyhnout ASIC.
+
+Pokud je výstup tohoto algoritmu pod požadovaným cílem, pak je nonce platný. Všimněte si, že dodatečná aplikace `sha3_256` na konci zajišťuje, že existuje mezilehlý nonce, který lze poskytnout k prokázání, že byla vykonána alespoň malá část práce; toto rychlé vnější ověření PoW lze použít pro účely anti-DDoS. Slouží také k poskytnutí statistické jistoty, že výsledek je nezaujaté 256bitové číslo.
+
+## Těžba {#mining}
+
+Algoritmus těžby je definován následovně:
+
+```python
+def mine(full_size, dataset, header, difficulty):
+ # vyplní cíl nulami pro porovnání s hašem na stejné číslici
+ target = zpad(encode_int(2**256 // difficulty), 64)[::-1]
+ from random import randint
+ nonce = randint(0, 2**64)
+ while hashimoto_full(full_size, dataset, header, nonce) > target:
+ nonce = (nonce + 1) % 2**64
+ return nonce
+```
+
+## Definování seed haše {#seed-hash}
+
+K výpočtu seed haše, který by byl použit k těžbě na daném bloku, používáme následující algoritmus:
+
+```python
+ def get_seedhash(block):
+ s = '\x00' * 32
+ for i in range(block.number // EPOCH_LENGTH):
+ s = serialize_hash(sha3_256(s))
+ return s
+```
+
+Všimněte si, že pro plynulou těžbu a ověřování doporučujeme předem vypočítat budoucí seedhaše a datové sady v samostatném vlákně.
+
+## Další čtení {#further-reading}
+
+_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_
+
+## Dodatek {#appendix}
+
+Následující kód by měl být připojen na začátek, pokud máte zájem spustit výše uvedenou specifikaci v Pythonu jako kód.
+
+```python
+import sha3, copy
+
+# Předpokládá pořadí bitů little endian (stejné jako u architektur Intel)
+def decode_int(s):
+ return int(s[::-1].encode('hex'), 16) if s else 0
+
+def encode_int(s):
+ a = "%x" % s
+ return '' if s == 0 else ('0' * (len(a) % 2) + a).decode('hex')[::-1]
+
+def zpad(s, length):
+ return s + '\x00' * max(0, length - len(s))
+
+def serialize_hash(h):
+ return ''.join([zpad(encode_int(x), 4) for x in h])
+
+def deserialize_hash(h):
+ return [decode_int(h[i:i+WORD_BYTES]) for i in range(0, len(h), WORD_BYTES)]
+
+def hash_words(h, sz, x):
+ if isinstance(x, list):
+ x = serialize_hash(x)
+ y = h(x)
+ return deserialize_hash(y)
+
+def serialize_cache(ds):
+ return ''.join([serialize_hash(h) for h in ds])
+
+serialize_dataset = serialize_cache
+
+# hašovací funkce sha3, výstupem je 64 bajtů
+def sha3_512(x):
+ return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x)
+
+def sha3_256(x):
+ return hash_words(lambda v: sha3.sha3_256(v).digest(), 32, x)
+
+def xor(a, b):
+ return a ^ b
+
+def isprime(x):
+ for i in range(2, int(x**0.5)):
+ if x % i == 0:
+ return False
+ return True
+```
+
+### Velikosti dat {#data-sizes}
+
+Následující vyhledávací tabulky poskytují přibližně 2048 tabelovaných epoch velikostí dat a velikostí mezipaměti.
+
+```python
+def get_datasize(block_number):
+ return data_sizes[block_number // EPOCH_LENGTH]
+
+def get_cachesize(block_number):
+ return cache_sizes[block_number // EPOCH_LENGTH]
+
+data_sizes = [
+1073739904, 1082130304, 1090514816, 1098906752, 1107293056,
+1115684224, 1124070016, 1132461952, 1140849536, 1149232768,
+1157627776, 1166013824, 1174404736, 1182786944, 1191180416,
+1199568512, 1207958912, 1216345216, 1224732032, 1233124736,
+1241513344, 1249902464, 1258290304, 1266673792, 1275067264,
+1283453312, 1291844992, 1300234112, 1308619904, 1317010048,
+1325397376, 1333787776, 1342176128, 1350561664, 1358954368,
+1367339392, 1375731584, 1384118144, 1392507008, 1400897408,
+1409284736, 1417673344, 1426062464, 1434451072, 1442839168,
+1451229056, 1459615616, 1468006016, 1476394112, 1484782976,
+1493171584, 1501559168, 1509948032, 1518337664, 1526726528,
+1535114624, 1543503488, 1551892096, 1560278656, 1568669056,
+1577056384, 1585446272, 1593831296, 1602219392, 1610610304,
+1619000192, 1627386752, 1635773824, 1644164224, 1652555648,
+1660943488, 1669332608, 1677721216, 1686109312, 1694497664,
+1702886272, 1711274624, 1719661184, 1728047744, 1736434816,
+1744829056, 1753218944, 1761606272, 1769995904, 1778382464,
+1786772864, 1795157888, 1803550592, 1811937664, 1820327552,
+1828711552, 1837102976, 1845488768, 1853879936, 1862269312,
+1870656896, 1879048064, 1887431552, 1895825024, 1904212096,
+1912601216, 1920988544, 1929379456, 1937765504, 1946156672,
+1954543232, 1962932096, 1971321728, 1979707264, 1988093056,
+1996487552, 2004874624, 2013262208, 2021653888, 2030039936,
+2038430848, 2046819968, 2055208576, 2063596672, 2071981952,
+2080373632, 2088762752, 2097149056, 2105539712, 2113928576,
+2122315136, 2130700672, 2139092608, 2147483264, 2155872128,
+2164257664, 2172642176, 2181035392, 2189426048, 2197814912,
+2206203008, 2214587264, 2222979712, 2231367808, 2239758208,
+2248145024, 2256527744, 2264922752, 2273312128, 2281701248,
+2290086272, 2298476672, 2306867072, 2315251072, 2323639168,
+2332032128, 2340420224, 2348808064, 2357196416, 2365580416,
+2373966976, 2382363008, 2390748544, 2399139968, 2407530368,
+2415918976, 2424307328, 2432695424, 2441084288, 2449472384,
+2457861248, 2466247808, 2474637184, 2483026816, 2491414144,
+2499803776, 2508191872, 2516582272, 2524970368, 2533359232,
+2541743488, 2550134144, 2558525056, 2566913408, 2575301504,
+2583686528, 2592073856, 2600467328, 2608856192, 2617240448,
+2625631616, 2634022016, 2642407552, 2650796416, 2659188352,
+2667574912, 2675965312, 2684352896, 2692738688, 2701130624,
+2709518464, 2717907328, 2726293376, 2734685056, 2743073152,
+2751462016, 2759851648, 2768232832, 2776625536, 2785017728,
+2793401984, 2801794432, 2810182016, 2818571648, 2826959488,
+2835349376, 2843734144, 2852121472, 2860514432, 2868900992,
+2877286784, 2885676928, 2894069632, 2902451584, 2910843008,
+2919234688, 2927622784, 2936011648, 2944400768, 2952789376,
+2961177728, 2969565568, 2977951616, 2986338944, 2994731392,
+3003120256, 3011508352, 3019895936, 3028287104, 3036675968,
+3045063808, 3053452928, 3061837696, 3070228352, 3078615424,
+3087003776, 3095394944, 3103782272, 3112173184, 3120562048,
+3128944768, 3137339264, 3145725056, 3154109312, 3162505088,
+3170893184, 3179280256, 3187669376, 3196056704, 3204445568,
+3212836736, 3221224064, 3229612928, 3238002304, 3246391168,
+3254778496, 3263165824, 3271556224, 3279944576, 3288332416,
+3296719232, 3305110912, 3313500032, 3321887104, 3330273152,
+3338658944, 3347053184, 3355440512, 3363827072, 3372220288,
+3380608384, 3388997504, 3397384576, 3405774208, 3414163072,
+3422551936, 3430937984, 3439328384, 3447714176, 3456104576,
+3464493952, 3472883584, 3481268864, 3489655168, 3498048896,
+3506434432, 3514826368, 3523213952, 3531603584, 3539987072,
+3548380288, 3556763264, 3565157248, 3573545344, 3581934464,
+3590324096, 3598712704, 3607098752, 3615488384, 3623877248,
+3632265856, 3640646528, 3649043584, 3657430144, 3665821568,
+3674207872, 3682597504, 3690984832, 3699367808, 3707764352,
+3716152448, 3724541056, 3732925568, 3741318016, 3749706368,
+3758091136, 3766481536, 3774872704, 3783260032, 3791650432,
+3800036224, 3808427648, 3816815488, 3825204608, 3833592704,
+3841981568, 3850370432, 3858755968, 3867147904, 3875536256,
+3883920512, 3892313728, 3900702592, 3909087872, 3917478784,
+3925868416, 3934256512, 3942645376, 3951032192, 3959422336,
+3967809152, 3976200064, 3984588416, 3992974976, 4001363584,
+4009751168, 4018141312, 4026530432, 4034911616, 4043308928,
+4051695488, 4060084352, 4068472448, 4076862848, 4085249408,
+4093640576, 4102028416, 4110413696, 4118805632, 4127194496,
+4135583104, 4143971968, 4152360832, 4160746112, 4169135744,
+4177525888, 4185912704, 4194303616, 4202691968, 4211076736,
+4219463552, 4227855488, 4236246656, 4244633728, 4253022848,
+4261412224, 4269799808, 4278184832, 4286578048, 4294962304,
+4303349632, 4311743104, 4320130432, 4328521088, 4336909184,
+4345295488, 4353687424, 4362073472, 4370458496, 4378852736,
+4387238528, 4395630208, 4404019072, 4412407424, 4420790656,
+4429182848, 4437571456, 4445962112, 4454344064, 4462738048,
+4471119232, 4479516544, 4487904128, 4496289664, 4504682368,
+4513068416, 4521459584, 4529846144, 4538232704, 4546619776,
+4555010176, 4563402112, 4571790208, 4580174464, 4588567936,
+4596957056, 4605344896, 4613734016, 4622119808, 4630511488,
+4638898816, 4647287936, 4655675264, 4664065664, 4672451968,
+4680842624, 4689231488, 4697620352, 4706007424, 4714397056,
+4722786176, 4731173248, 4739562368, 4747951744, 4756340608,
+4764727936, 4773114496, 4781504384, 4789894784, 4798283648,
+4806667648, 4815059584, 4823449472, 4831835776, 4840226176,
+4848612224, 4857003392, 4865391488, 4873780096, 4882169728,
+4890557312, 4898946944, 4907333248, 4915722368, 4924110976,
+4932499328, 4940889728, 4949276032, 4957666432, 4966054784,
+4974438016, 4982831488, 4991221376, 4999607168, 5007998848,
+5016386432, 5024763776, 5033164672, 5041544576, 5049941888,
+5058329728, 5066717056, 5075107456, 5083494272, 5091883904,
+5100273536, 5108662144, 5117048192, 5125436032, 5133827456,
+5142215296, 5150605184, 5158993024, 5167382144, 5175769472,
+5184157568, 5192543872, 5200936064, 5209324928, 5217711232,
+5226102656, 5234490496, 5242877312, 5251263872, 5259654016,
+5268040832, 5276434304, 5284819328, 5293209728, 5301598592,
+5309986688, 5318374784, 5326764416, 5335151488, 5343542144,
+5351929472, 5360319872, 5368706944, 5377096576, 5385484928,
+5393871232, 5402263424, 5410650496, 5419040384, 5427426944,
+5435816576, 5444205952, 5452594816, 5460981376, 5469367936,
+5477760896, 5486148736, 5494536832, 5502925952, 5511315328,
+5519703424, 5528089984, 5536481152, 5544869504, 5553256064,
+5561645696, 5570032768, 5578423936, 5586811264, 5595193216,
+5603585408, 5611972736, 5620366208, 5628750464, 5637143936,
+5645528192, 5653921408, 5662310272, 5670694784, 5679082624,
+5687474048, 5695864448, 5704251008, 5712641408, 5721030272,
+5729416832, 5737806208, 5746194304, 5754583936, 5762969984,
+5771358592, 5779748224, 5788137856, 5796527488, 5804911232,
+5813300608, 5821692544, 5830082176, 5838468992, 5846855552,
+5855247488, 5863636096, 5872024448, 5880411008, 5888799872,
+5897186432, 5905576832, 5913966976, 5922352768, 5930744704,
+5939132288, 5947522432, 5955911296, 5964299392, 5972688256,
+5981074304, 5989465472, 5997851008, 6006241408, 6014627968,
+6023015552, 6031408256, 6039796096, 6048185216, 6056574848,
+6064963456, 6073351808, 6081736064, 6090128768, 6098517632,
+6106906496, 6115289216, 6123680896, 6132070016, 6140459648,
+6148849024, 6157237376, 6165624704, 6174009728, 6182403712,
+6190792064, 6199176064, 6207569792, 6215952256, 6224345216,
+6232732544, 6241124224, 6249510272, 6257899136, 6266287744,
+6274676864, 6283065728, 6291454336, 6299843456, 6308232064,
+6316620928, 6325006208, 6333395584, 6341784704, 6350174848,
+6358562176, 6366951296, 6375337856, 6383729536, 6392119168,
+6400504192, 6408895616, 6417283456, 6425673344, 6434059136,
+6442444672, 6450837376, 6459223424, 6467613056, 6476004224,
+6484393088, 6492781952, 6501170048, 6509555072, 6517947008,
+6526336384, 6534725504, 6543112832, 6551500672, 6559888768,
+6568278656, 6576662912, 6585055616, 6593443456, 6601834112,
+6610219648, 6618610304, 6626999168, 6635385472, 6643777408,
+6652164224, 6660552832, 6668941952, 6677330048, 6685719424,
+6694107776, 6702493568, 6710882176, 6719274112, 6727662976,
+6736052096, 6744437632, 6752825984, 6761213824, 6769604224,
+6777993856, 6786383488, 6794770816, 6803158144, 6811549312,
+6819937664, 6828326528, 6836706176, 6845101696, 6853491328,
+6861880448, 6870269312, 6878655104, 6887046272, 6895433344,
+6903822208, 6912212864, 6920596864, 6928988288, 6937377152,
+6945764992, 6954149248, 6962544256, 6970928768, 6979317376,
+6987709312, 6996093824, 7004487296, 7012875392, 7021258624,
+7029652352, 7038038912, 7046427776, 7054818944, 7063207808,
+7071595136, 7079980928, 7088372608, 7096759424, 7105149824,
+7113536896, 7121928064, 7130315392, 7138699648, 7147092352,
+7155479168, 7163865728, 7172249984, 7180648064, 7189036672,
+7197424768, 7205810816, 7214196608, 7222589824, 7230975104,
+7239367552, 7247755904, 7256145536, 7264533376, 7272921472,
+7281308032, 7289694848, 7298088832, 7306471808, 7314864512,
+7323253888, 7331643008, 7340029568, 7348419712, 7356808832,
+7365196672, 7373585792, 7381973888, 7390362752, 7398750592,
+7407138944, 7415528576, 7423915648, 7432302208, 7440690304,
+7449080192, 7457472128, 7465860992, 7474249088, 7482635648,
+7491023744, 7499412608, 7507803008, 7516192384, 7524579968,
+7532967296, 7541358464, 7549745792, 7558134656, 7566524032,
+7574912896, 7583300992, 7591690112, 7600075136, 7608466816,
+7616854912, 7625244544, 7633629824, 7642020992, 7650410368,
+7658794112, 7667187328, 7675574912, 7683961984, 7692349568,
+7700739712, 7709130368, 7717519232, 7725905536, 7734295424,
+7742683264, 7751069056, 7759457408, 7767849088, 7776238208,
+7784626816, 7793014912, 7801405312, 7809792128, 7818179968,
+7826571136, 7834957184, 7843347328, 7851732352, 7860124544,
+7868512384, 7876902016, 7885287808, 7893679744, 7902067072,
+7910455936, 7918844288, 7927230848, 7935622784, 7944009344,
+7952400256, 7960786048, 7969176704, 7977565312, 7985953408,
+7994339968, 8002730368, 8011119488, 8019508096, 8027896192,
+8036285056, 8044674688, 8053062272, 8061448832, 8069838464,
+8078227328, 8086616704, 8095006592, 8103393664, 8111783552,
+8120171392, 8128560256, 8136949376, 8145336704, 8153726848,
+8162114944, 8170503296, 8178891904, 8187280768, 8195669632,
+8204058496, 8212444544, 8220834176, 8229222272, 8237612672,
+8246000768, 8254389376, 8262775168, 8271167104, 8279553664,
+8287944064, 8296333184, 8304715136, 8313108352, 8321497984,
+8329885568, 8338274432, 8346663296, 8355052928, 8363441536,
+8371828352, 8380217984, 8388606592, 8396996224, 8405384576,
+8413772672, 8422161536, 8430549376, 8438939008, 8447326592,
+8455715456, 8464104832, 8472492928, 8480882048, 8489270656,
+8497659776, 8506045312, 8514434944, 8522823808, 8531208832,
+8539602304, 8547990656, 8556378752, 8564768384, 8573154176,
+8581542784, 8589933952, 8598322816, 8606705024, 8615099264,
+8623487872, 8631876992, 8640264064, 8648653952, 8657040256,
+8665430656, 8673820544, 8682209152, 8690592128, 8698977152,
+8707374464, 8715763328, 8724151424, 8732540032, 8740928384,
+8749315712, 8757704576, 8766089344, 8774480768, 8782871936,
+8791260032, 8799645824, 8808034432, 8816426368, 8824812928,
+8833199488, 8841591424, 8849976448, 8858366336, 8866757248,
+8875147136, 8883532928, 8891923328, 8900306816, 8908700288,
+8917088384, 8925478784, 8933867392, 8942250368, 8950644608,
+8959032704, 8967420544, 8975809664, 8984197504, 8992584064,
+9000976256, 9009362048, 9017752448, 9026141312, 9034530688,
+9042917504, 9051307904, 9059694208, 9068084864, 9076471424,
+9084861824, 9093250688, 9101638528, 9110027648, 9118416512,
+9126803584, 9135188096, 9143581312, 9151969664, 9160356224,
+9168747136, 9177134464, 9185525632, 9193910144, 9202302848,
+9210690688, 9219079552, 9227465344, 9235854464, 9244244864,
+9252633472, 9261021824, 9269411456, 9277799296, 9286188928,
+9294574208, 9302965888, 9311351936, 9319740032, 9328131968,
+9336516736, 9344907392, 9353296768, 9361685888, 9370074752,
+9378463616, 9386849408, 9395239808, 9403629184, 9412016512,
+9420405376, 9428795008, 9437181568, 9445570688, 9453960832,
+9462346624, 9470738048, 9479121536, 9487515008, 9495903616,
+9504289664, 9512678528, 9521067904, 9529456256, 9537843584,
+9546233728, 9554621312, 9563011456, 9571398784, 9579788672,
+9588178304, 9596567168, 9604954496, 9613343104, 9621732992,
+9630121856, 9638508416, 9646898816, 9655283584, 9663675776,
+9672061312, 9680449664, 9688840064, 9697230464, 9705617536,
+9714003584, 9722393984, 9730772608, 9739172224, 9747561088,
+9755945344, 9764338816, 9772726144, 9781116544, 9789503872,
+9797892992, 9806282624, 9814670464, 9823056512, 9831439232,
+9839833984, 9848224384, 9856613504, 9865000576, 9873391232,
+9881772416, 9890162816, 9898556288, 9906940544, 9915333248,
+9923721088, 9932108672, 9940496512, 9948888448, 9957276544,
+9965666176, 9974048384, 9982441088, 9990830464, 9999219584,
+10007602816, 10015996544, 10024385152, 10032774016, 10041163648,
+10049548928, 10057940096, 10066329472, 10074717824, 10083105152,
+10091495296, 10099878784, 10108272256, 10116660608, 10125049216,
+10133437312, 10141825664, 10150213504, 10158601088, 10166991232,
+10175378816, 10183766144, 10192157312, 10200545408, 10208935552,
+10217322112, 10225712768, 10234099328, 10242489472, 10250876032,
+10259264896, 10267656064, 10276042624, 10284429184, 10292820352,
+10301209472, 10309598848, 10317987712, 10326375296, 10334763392,
+10343153536, 10351541632, 10359930752, 10368318592, 10376707456,
+10385096576, 10393484672, 10401867136, 10410262144, 10418647424,
+10427039104, 10435425664, 10443810176, 10452203648, 10460589952,
+10468982144, 10477369472, 10485759104, 10494147712, 10502533504,
+10510923392, 10519313536, 10527702656, 10536091264, 10544478592,
+10552867712, 10561255808, 10569642368, 10578032768, 10586423168,
+10594805632, 10603200128, 10611588992, 10619976064, 10628361344,
+10636754048, 10645143424, 10653531776, 10661920384, 10670307968,
+10678696832, 10687086464, 10695475072, 10703863168, 10712246144,
+10720639616, 10729026688, 10737414784, 10745806208, 10754190976,
+10762581376, 10770971264, 10779356288, 10787747456, 10796135552,
+10804525184, 10812915584, 10821301888, 10829692288, 10838078336,
+10846469248, 10854858368, 10863247232, 10871631488, 10880023424,
+10888412032, 10896799616, 10905188992, 10913574016, 10921964672,
+10930352768, 10938742912, 10947132544, 10955518592, 10963909504,
+10972298368, 10980687488, 10989074816, 10997462912, 11005851776,
+11014241152, 11022627712, 11031017344, 11039403904, 11047793024,
+11056184704, 11064570752, 11072960896, 11081343872, 11089737856,
+11098128256, 11106514816, 11114904448, 11123293568, 11131680128,
+11140065152, 11148458368, 11156845696, 11165236864, 11173624192,
+11182013824, 11190402688, 11198790784, 11207179136, 11215568768,
+11223957376, 11232345728, 11240734592, 11249122688, 11257511296,
+11265899648, 11274285952, 11282675584, 11291065472, 11299452544,
+11307842432, 11316231296, 11324616832, 11333009024, 11341395584,
+11349782656, 11358172288, 11366560384, 11374950016, 11383339648,
+11391721856, 11400117376, 11408504192, 11416893568, 11425283456,
+11433671552, 11442061184, 11450444672, 11458837888, 11467226752,
+11475611776, 11484003968, 11492392064, 11500780672, 11509169024,
+11517550976, 11525944448, 11534335616, 11542724224, 11551111808,
+11559500672, 11567890304, 11576277376, 11584667008, 11593056128,
+11601443456, 11609830016, 11618221952, 11626607488, 11634995072,
+11643387776, 11651775104, 11660161664, 11668552576, 11676940928,
+11685330304, 11693718656, 11702106496, 11710496128, 11718882688,
+11727273088, 11735660416, 11744050048, 11752437376, 11760824704,
+11769216128, 11777604736, 11785991296, 11794381952, 11802770048,
+11811157888, 11819548544, 11827932544, 11836324736, 11844713344,
+11853100928, 11861486464, 11869879936, 11878268032, 11886656896,
+11895044992, 11903433088, 11911822976, 11920210816, 11928600448,
+11936987264, 11945375872, 11953761152, 11962151296, 11970543488,
+11978928512, 11987320448, 11995708288, 12004095104, 12012486272,
+12020875136, 12029255552, 12037652096, 12046039168, 12054429568,
+12062813824, 12071206528, 12079594624, 12087983744, 12096371072,
+12104759936, 12113147264, 12121534592, 12129924992, 12138314624,
+12146703232, 12155091584, 12163481216, 12171864704, 12180255872,
+12188643968, 12197034112, 12205424512, 12213811328, 12222199424,
+12230590336, 12238977664, 12247365248, 12255755392, 12264143488,
+12272531584, 12280920448, 12289309568, 12297694592, 12306086528,
+12314475392, 12322865024, 12331253632, 12339640448, 12348029312,
+12356418944, 12364805248, 12373196672, 12381580928, 12389969024,
+12398357632, 12406750592, 12415138432, 12423527552, 12431916416,
+12440304512, 12448692352, 12457081216, 12465467776, 12473859968,
+12482245504, 12490636672, 12499025536, 12507411584, 12515801728,
+12524190592, 12532577152, 12540966272, 12549354368, 12557743232,
+12566129536, 12574523264, 12582911872, 12591299456, 12599688064,
+12608074624, 12616463488, 12624845696, 12633239936, 12641631616,
+12650019968, 12658407296, 12666795136, 12675183232, 12683574656,
+12691960192, 12700350592, 12708740224, 12717128576, 12725515904,
+12733906816, 12742295168, 12750680192, 12759071872, 12767460736,
+12775848832, 12784236928, 12792626816, 12801014656, 12809404288,
+12817789312, 12826181504, 12834568832, 12842954624, 12851345792,
+12859732352, 12868122496, 12876512128, 12884901248, 12893289088,
+12901672832, 12910067584, 12918455168, 12926842496, 12935232896,
+12943620736, 12952009856, 12960396928, 12968786816, 12977176192,
+12985563776, 12993951104, 13002341504, 13010730368, 13019115392,
+13027506304, 13035895168, 13044272512, 13052673152, 13061062528,
+13069446272, 13077838976, 13086227072, 13094613632, 13103000192,
+13111393664, 13119782528, 13128157568, 13136559232, 13144945024,
+13153329536, 13161724288, 13170111872, 13178502784, 13186884736,
+13195279744, 13203667072, 13212057472, 13220445824, 13228832128,
+13237221248, 13245610624, 13254000512, 13262388352, 13270777472,
+13279166336, 13287553408, 13295943296, 13304331904, 13312719488,
+13321108096, 13329494656, 13337885824, 13346274944, 13354663808,
+13363051136, 13371439232, 13379825024, 13388210816, 13396605056,
+13404995456, 13413380224, 13421771392, 13430159744, 13438546048,
+13446937216, 13455326848, 13463708288, 13472103808, 13480492672,
+13488875648, 13497269888, 13505657728, 13514045312, 13522435712,
+13530824576, 13539210112, 13547599232, 13555989376, 13564379008,
+13572766336, 13581154432, 13589544832, 13597932928, 13606320512,
+13614710656, 13623097472, 13631477632, 13639874944, 13648264064,
+13656652928, 13665041792, 13673430656, 13681818496, 13690207616,
+13698595712, 13706982272, 13715373184, 13723762048, 13732150144,
+13740536704, 13748926592, 13757316224, 13765700992, 13774090112,
+13782477952, 13790869376, 13799259008, 13807647872, 13816036736,
+13824425344, 13832814208, 13841202304, 13849591424, 13857978752,
+13866368896, 13874754688, 13883145344, 13891533184, 13899919232,
+13908311168, 13916692096, 13925085056, 13933473152, 13941866368,
+13950253696, 13958643584, 13967032192, 13975417216, 13983807616,
+13992197504, 14000582272, 14008973696, 14017363072, 14025752192,
+14034137984, 14042528384, 14050918016, 14059301504, 14067691648,
+14076083584, 14084470144, 14092852352, 14101249664, 14109635968,
+14118024832, 14126407552, 14134804352, 14143188608, 14151577984,
+14159968384, 14168357248, 14176741504, 14185127296, 14193521024,
+14201911424, 14210301824, 14218685056, 14227067264, 14235467392,
+14243855488, 14252243072, 14260630144, 14269021568, 14277409408,
+14285799296, 14294187904, 14302571392, 14310961792, 14319353728,
+14327738752, 14336130944, 14344518784, 14352906368, 14361296512,
+14369685376, 14378071424, 14386462592, 14394848128, 14403230848,
+14411627392, 14420013952, 14428402304, 14436793472, 14445181568,
+14453569664, 14461959808, 14470347904, 14478737024, 14487122816,
+14495511424, 14503901824, 14512291712, 14520677504, 14529064832,
+14537456768, 14545845632, 14554234496, 14562618496, 14571011456,
+14579398784, 14587789184, 14596172672, 14604564608, 14612953984,
+14621341312, 14629724288, 14638120832, 14646503296, 14654897536,
+14663284864, 14671675264, 14680061056, 14688447616, 14696835968,
+14705228416, 14713616768, 14722003328, 14730392192, 14738784128,
+14747172736, 14755561088, 14763947648, 14772336512, 14780725376,
+14789110144, 14797499776, 14805892736, 14814276992, 14822670208,
+14831056256, 14839444352, 14847836032, 14856222848, 14864612992,
+14872997504, 14881388672, 14889775744, 14898165376, 14906553472,
+14914944896, 14923329664, 14931721856, 14940109696, 14948497024,
+14956887424, 14965276544, 14973663616, 14982053248, 14990439808,
+14998830976, 15007216768, 15015605888, 15023995264, 15032385152,
+15040768384, 15049154944, 15057549184, 15065939072, 15074328448,
+15082715008, 15091104128, 15099493504, 15107879296, 15116269184,
+15124659584, 15133042304, 15141431936, 15149824384, 15158214272,
+15166602368, 15174991232, 15183378304, 15191760512, 15200154496,
+15208542592, 15216931712, 15225323392, 15233708416, 15242098048,
+15250489216, 15258875264, 15267265408, 15275654528, 15284043136,
+15292431488, 15300819584, 15309208192, 15317596544, 15325986176,
+15334374784, 15342763648, 15351151744, 15359540608, 15367929728,
+15376318336, 15384706432, 15393092992, 15401481856, 15409869952,
+15418258816, 15426649984, 15435037568, 15443425664, 15451815296,
+15460203392, 15468589184, 15476979328, 15485369216, 15493755776,
+15502146944, 15510534272, 15518924416, 15527311232, 15535699072,
+15544089472, 15552478336, 15560866688, 15569254528, 15577642624,
+15586031488, 15594419072, 15602809472, 15611199104, 15619586432,
+15627975296, 15636364928, 15644753792, 15653141888, 15661529216,
+15669918848, 15678305152, 15686696576, 15695083136, 15703474048,
+15711861632, 15720251264, 15728636288, 15737027456, 15745417088,
+15753804928, 15762194048, 15770582656, 15778971008, 15787358336,
+15795747712, 15804132224, 15812523392, 15820909696, 15829300096,
+15837691264, 15846071936, 15854466944, 15862855808, 15871244672,
+15879634816, 15888020608, 15896409728, 15904799104, 15913185152,
+15921577088, 15929966464, 15938354816, 15946743424, 15955129472,
+15963519872, 15971907968, 15980296064, 15988684928, 15997073024,
+16005460864, 16013851264, 16022241152, 16030629248, 16039012736,
+16047406976, 16055794816, 16064181376, 16072571264, 16080957824,
+16089346688, 16097737856, 16106125184, 16114514816, 16122904192,
+16131292544, 16139678848, 16148066944, 16156453504, 16164839552,
+16173236096, 16181623424, 16190012032, 16198401152, 16206790528,
+16215177344, 16223567744, 16231956352, 16240344704, 16248731008,
+16257117824, 16265504384, 16273898624, 16282281856, 16290668672,
+16299064192, 16307449216, 16315842176, 16324230016, 16332613504,
+16341006464, 16349394304, 16357783168, 16366172288, 16374561664,
+16382951296, 16391337856, 16399726208, 16408116352, 16416505472,
+16424892032, 16433282176, 16441668224, 16450058624, 16458448768,
+16466836864, 16475224448, 16483613056, 16492001408, 16500391808,
+16508779648, 16517166976, 16525555328, 16533944192, 16542330752,
+16550719616, 16559110528, 16567497088, 16575888512, 16584274816,
+16592665472, 16601051008, 16609442944, 16617832064, 16626218624,
+16634607488, 16642996096, 16651385728, 16659773824, 16668163712,
+16676552576, 16684938112, 16693328768, 16701718144, 16710095488,
+16718492288, 16726883968, 16735272832, 16743661184, 16752049792,
+16760436608, 16768827008, 16777214336, 16785599104, 16793992832,
+16802381696, 16810768768, 16819151744, 16827542656, 16835934848,
+16844323712, 16852711552, 16861101952, 16869489536, 16877876864,
+16886265728, 16894653056, 16903044736, 16911431296, 16919821696,
+16928207488, 16936592768, 16944987776, 16953375616, 16961763968,
+16970152832, 16978540928, 16986929536, 16995319168, 17003704448,
+17012096896, 17020481152, 17028870784, 17037262208, 17045649536,
+17054039936, 17062426496, 17070814336, 17079205504, 17087592064,
+17095978112, 17104369024, 17112759424, 17121147776, 17129536384,
+17137926016, 17146314368, 17154700928, 17163089792, 17171480192,
+17179864192, 17188256896, 17196644992, 17205033856, 17213423488,
+17221811072, 17230198912, 17238588032, 17246976896, 17255360384,
+17263754624, 17272143232, 17280530048, 17288918912, 17297309312,
+17305696384, 17314085504, 17322475136, 17330863744, 17339252096,
+17347640192, 17356026496, 17364413824, 17372796544, 17381190016,
+17389583488, 17397972608, 17406360704, 17414748544, 17423135872,
+17431527296, 17439915904, 17448303232, 17456691584, 17465081728,
+17473468288, 17481857408, 17490247552, 17498635904, 17507022464,
+17515409024, 17523801728, 17532189824, 17540577664, 17548966016,
+17557353344, 17565741184, 17574131584, 17582519168, 17590907008,
+17599296128, 17607687808, 17616076672, 17624455808, 17632852352,
+17641238656, 17649630848, 17658018944, 17666403968, 17674794112,
+17683178368, 17691573376, 17699962496, 17708350592, 17716739968,
+17725126528, 17733517184, 17741898112, 17750293888, 17758673024,
+17767070336, 17775458432, 17783848832, 17792236928, 17800625536,
+17809012352, 17817402752, 17825785984, 17834178944, 17842563968,
+17850955648, 17859344512, 17867732864, 17876119424, 17884511872,
+17892900224, 17901287296, 17909677696, 17918058112, 17926451072,
+17934843776, 17943230848, 17951609216, 17960008576, 17968397696,
+17976784256, 17985175424, 17993564032, 18001952128, 18010339712,
+18018728576, 18027116672, 18035503232, 18043894144, 18052283264,
+18060672128, 18069056384, 18077449856, 18085837184, 18094225792,
+18102613376, 18111004544, 18119388544, 18127781248, 18136170368,
+18144558976, 18152947328, 18161336192, 18169724288, 18178108544,
+18186498944, 18194886784, 18203275648, 18211666048, 18220048768,
+18228444544, 18236833408, 18245220736]
+
+cache_sizes = [
+16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072,
+17693888, 17824192, 17955904, 18087488, 18218176, 18349504, 18481088,
+18611392, 18742336, 18874304, 19004224, 19135936, 19267264, 19398208,
+19529408, 19660096, 19791424, 19922752, 20053952, 20184896, 20315968,
+20446912, 20576576, 20709184, 20840384, 20971072, 21102272, 21233216,
+21364544, 21494848, 21626816, 21757376, 21887552, 22019392, 22151104,
+22281536, 22412224, 22543936, 22675264, 22806464, 22935872, 23068096,
+23198272, 23330752, 23459008, 23592512, 23723968, 23854912, 23986112,
+24116672, 24247616, 24378688, 24509504, 24640832, 24772544, 24903488,
+25034432, 25165376, 25296704, 25427392, 25558592, 25690048, 25820096,
+25951936, 26081728, 26214208, 26345024, 26476096, 26606656, 26737472,
+26869184, 26998208, 27131584, 27262528, 27393728, 27523904, 27655744,
+27786688, 27917888, 28049344, 28179904, 28311488, 28441792, 28573504,
+28700864, 28835648, 28966208, 29096768, 29228608, 29359808, 29490752,
+29621824, 29752256, 29882816, 30014912, 30144448, 30273728, 30406976,
+30538432, 30670784, 30799936, 30932672, 31063744, 31195072, 31325248,
+31456192, 31588288, 31719232, 31850432, 31981504, 32110784, 32243392,
+32372672, 32505664, 32636608, 32767808, 32897344, 33029824, 33160768,
+33289664, 33423296, 33554368, 33683648, 33816512, 33947456, 34076992,
+34208704, 34340032, 34471744, 34600256, 34734016, 34864576, 34993984,
+35127104, 35258176, 35386688, 35518528, 35650624, 35782336, 35910976,
+36044608, 36175808, 36305728, 36436672, 36568384, 36699968, 36830656,
+36961984, 37093312, 37223488, 37355072, 37486528, 37617472, 37747904,
+37879232, 38009792, 38141888, 38272448, 38403392, 38535104, 38660672,
+38795584, 38925632, 39059264, 39190336, 39320768, 39452096, 39581632,
+39713984, 39844928, 39974848, 40107968, 40238144, 40367168, 40500032,
+40631744, 40762816, 40894144, 41023552, 41155904, 41286208, 41418304,
+41547712, 41680448, 41811904, 41942848, 42073792, 42204992, 42334912,
+42467008, 42597824, 42729152, 42860096, 42991552, 43122368, 43253696,
+43382848, 43515712, 43646912, 43777088, 43907648, 44039104, 44170432,
+44302144, 44433344, 44564288, 44694976, 44825152, 44956864, 45088448,
+45219008, 45350464, 45481024, 45612608, 45744064, 45874496, 46006208,
+46136768, 46267712, 46399424, 46529344, 46660672, 46791488, 46923328,
+47053504, 47185856, 47316928, 47447872, 47579072, 47710144, 47839936,
+47971648, 48103232, 48234176, 48365248, 48496192, 48627136, 48757312,
+48889664, 49020736, 49149248, 49283008, 49413824, 49545152, 49675712,
+49807168, 49938368, 50069056, 50200256, 50331584, 50462656, 50593472,
+50724032, 50853952, 50986048, 51117632, 51248576, 51379904, 51510848,
+51641792, 51773248, 51903296, 52035136, 52164032, 52297664, 52427968,
+52557376, 52690112, 52821952, 52952896, 53081536, 53213504, 53344576,
+53475776, 53608384, 53738816, 53870528, 54000832, 54131776, 54263744,
+54394688, 54525248, 54655936, 54787904, 54918592, 55049152, 55181248,
+55312064, 55442752, 55574336, 55705024, 55836224, 55967168, 56097856,
+56228672, 56358592, 56490176, 56621888, 56753728, 56884928, 57015488,
+57146816, 57278272, 57409216, 57540416, 57671104, 57802432, 57933632,
+58064576, 58195264, 58326976, 58457408, 58588864, 58720192, 58849984,
+58981696, 59113024, 59243456, 59375552, 59506624, 59637568, 59768512,
+59897792, 60030016, 60161984, 60293056, 60423872, 60554432, 60683968,
+60817216, 60948032, 61079488, 61209664, 61341376, 61471936, 61602752,
+61733696, 61865792, 61996736, 62127808, 62259136, 62389568, 62520512,
+62651584, 62781632, 62910784, 63045056, 63176128, 63307072, 63438656,
+63569216, 63700928, 63831616, 63960896, 64093888, 64225088, 64355392,
+64486976, 64617664, 64748608, 64879424, 65009216, 65142464, 65273792,
+65402816, 65535424, 65666752, 65797696, 65927744, 66060224, 66191296,
+66321344, 66453056, 66584384, 66715328, 66846656, 66977728, 67108672,
+67239104, 67370432, 67501888, 67631296, 67763776, 67895104, 68026304,
+68157248, 68287936, 68419264, 68548288, 68681408, 68811968, 68942912,
+69074624, 69205568, 69337024, 69467584, 69599168, 69729472, 69861184,
+69989824, 70122944, 70253888, 70385344, 70515904, 70647232, 70778816,
+70907968, 71040832, 71171648, 71303104, 71432512, 71564992, 71695168,
+71826368, 71958464, 72089536, 72219712, 72350144, 72482624, 72613568,
+72744512, 72875584, 73006144, 73138112, 73268672, 73400128, 73530944,
+73662272, 73793344, 73924544, 74055104, 74185792, 74316992, 74448832,
+74579392, 74710976, 74841664, 74972864, 75102784, 75233344, 75364544,
+75497024, 75627584, 75759296, 75890624, 76021696, 76152256, 76283072,
+76414144, 76545856, 76676672, 76806976, 76937792, 77070016, 77200832,
+77331392, 77462464, 77593664, 77725376, 77856448, 77987776, 78118336,
+78249664, 78380992, 78511424, 78642496, 78773056, 78905152, 79033664,
+79166656, 79297472, 79429568, 79560512, 79690816, 79822784, 79953472,
+80084672, 80214208, 80346944, 80477632, 80608576, 80740288, 80870848,
+81002048, 81133504, 81264448, 81395648, 81525952, 81657536, 81786304,
+81919808, 82050112, 82181312, 82311616, 82443968, 82573376, 82705984,
+82835776, 82967744, 83096768, 83230528, 83359552, 83491264, 83622464,
+83753536, 83886016, 84015296, 84147776, 84277184, 84409792, 84540608,
+84672064, 84803008, 84934336, 85065152, 85193792, 85326784, 85458496,
+85589312, 85721024, 85851968, 85982656, 86112448, 86244416, 86370112,
+86506688, 86637632, 86769344, 86900672, 87031744, 87162304, 87293632,
+87424576, 87555392, 87687104, 87816896, 87947968, 88079168, 88211264,
+88341824, 88473152, 88603712, 88735424, 88862912, 88996672, 89128384,
+89259712, 89390272, 89521984, 89652544, 89783872, 89914816, 90045376,
+90177088, 90307904, 90438848, 90569152, 90700096, 90832832, 90963776,
+91093696, 91223744, 91356992, 91486784, 91618496, 91749824, 91880384,
+92012224, 92143552, 92273344, 92405696, 92536768, 92666432, 92798912,
+92926016, 93060544, 93192128, 93322816, 93453632, 93583936, 93715136,
+93845056, 93977792, 94109504, 94240448, 94371776, 94501184, 94632896,
+94764224, 94895552, 95023424, 95158208, 95287744, 95420224, 95550016,
+95681216, 95811904, 95943872, 96075328, 96203584, 96337856, 96468544,
+96599744, 96731072, 96860992, 96992576, 97124288, 97254848, 97385536,
+97517248, 97647808, 97779392, 97910464, 98041408, 98172608, 98303168,
+98434496, 98565568, 98696768, 98827328, 98958784, 99089728, 99220928,
+99352384, 99482816, 99614272, 99745472, 99876416, 100007104,
+100138048, 100267072, 100401088, 100529984, 100662592, 100791872,
+100925248, 101056064, 101187392, 101317952, 101449408, 101580608,
+101711296, 101841728, 101973824, 102104896, 102235712, 102366016,
+102498112, 102628672, 102760384, 102890432, 103021888, 103153472,
+103284032, 103415744, 103545152, 103677248, 103808576, 103939648,
+104070976, 104201792, 104332736, 104462528, 104594752, 104725952,
+104854592, 104988608, 105118912, 105247808, 105381184, 105511232,
+105643072, 105774784, 105903296, 106037056, 106167872, 106298944,
+106429504, 106561472, 106691392, 106822592, 106954304, 107085376,
+107216576, 107346368, 107478464, 107609792, 107739712, 107872192,
+108003136, 108131392, 108265408, 108396224, 108527168, 108657344,
+108789568, 108920384, 109049792, 109182272, 109312576, 109444928,
+109572928, 109706944, 109837888, 109969088, 110099648, 110230976,
+110362432, 110492992, 110624704, 110755264, 110886208, 111017408,
+111148864, 111279296, 111410752, 111541952, 111673024, 111803456,
+111933632, 112066496, 112196416, 112328512, 112457792, 112590784,
+112715968, 112852672, 112983616, 113114944, 113244224, 113376448,
+113505472, 113639104, 113770304, 113901376, 114031552, 114163264,
+114294592, 114425536, 114556864, 114687424, 114818624, 114948544,
+115080512, 115212224, 115343296, 115473472, 115605184, 115736128,
+115867072, 115997248, 116128576, 116260288, 116391488, 116522944,
+116652992, 116784704, 116915648, 117046208, 117178304, 117308608,
+117440192, 117569728, 117701824, 117833024, 117964096, 118094656,
+118225984, 118357312, 118489024, 118617536, 118749632, 118882112,
+119012416, 119144384, 119275328, 119406016, 119537344, 119668672,
+119798464, 119928896, 120061376, 120192832, 120321728, 120454336,
+120584512, 120716608, 120848192, 120979136, 121109056, 121241408,
+121372352, 121502912, 121634752, 121764416, 121895744, 122027072,
+122157632, 122289088, 122421184, 122550592, 122682944, 122813888,
+122945344, 123075776, 123207488, 123338048, 123468736, 123600704,
+123731264, 123861952, 123993664, 124124608, 124256192, 124386368,
+124518208, 124649024, 124778048, 124911296, 125041088, 125173696,
+125303744, 125432896, 125566912, 125696576, 125829056, 125958592,
+126090304, 126221248, 126352832, 126483776, 126615232, 126746432,
+126876608, 127008704, 127139392, 127270336, 127401152, 127532224,
+127663552, 127794752, 127925696, 128055232, 128188096, 128319424,
+128449856, 128581312, 128712256, 128843584, 128973632, 129103808,
+129236288, 129365696, 129498944, 129629888, 129760832, 129892288,
+130023104, 130154048, 130283968, 130416448, 130547008, 130678336,
+130807616, 130939456, 131071552, 131202112, 131331776, 131464384,
+131594048, 131727296, 131858368, 131987392, 132120256, 132250816,
+132382528, 132513728, 132644672, 132774976, 132905792, 133038016,
+133168832, 133299392, 133429312, 133562048, 133692992, 133823296,
+133954624, 134086336, 134217152, 134348608, 134479808, 134607296,
+134741056, 134872384, 135002944, 135134144, 135265472, 135396544,
+135527872, 135659072, 135787712, 135921472, 136052416, 136182848,
+136313792, 136444864, 136576448, 136707904, 136837952, 136970048,
+137099584, 137232064, 137363392, 137494208, 137625536, 137755712,
+137887424, 138018368, 138149824, 138280256, 138411584, 138539584,
+138672832, 138804928, 138936128, 139066688, 139196864, 139328704,
+139460032, 139590208, 139721024, 139852864, 139984576, 140115776,
+140245696, 140376512, 140508352, 140640064, 140769856, 140902336,
+141032768, 141162688, 141294016, 141426496, 141556544, 141687488,
+141819584, 141949888, 142080448, 142212544, 142342336, 142474432,
+142606144, 142736192, 142868288, 142997824, 143129408, 143258944,
+143392448, 143523136, 143653696, 143785024, 143916992, 144045632,
+144177856, 144309184, 144440768, 144570688, 144701888, 144832448,
+144965056, 145096384, 145227584, 145358656, 145489856, 145620928,
+145751488, 145883072, 146011456, 146144704, 146275264, 146407232,
+146538176, 146668736, 146800448, 146931392, 147062336, 147193664,
+147324224, 147455936, 147586624, 147717056, 147848768, 147979456,
+148110784, 148242368, 148373312, 148503232, 148635584, 148766144,
+148897088, 149028416, 149159488, 149290688, 149420224, 149551552,
+149683136, 149814976, 149943616, 150076352, 150208064, 150338624,
+150470464, 150600256, 150732224, 150862784, 150993088, 151125952,
+151254976, 151388096, 151519168, 151649728, 151778752, 151911104,
+152042944, 152174144, 152304704, 152435648, 152567488, 152698816,
+152828992, 152960576, 153091648, 153222976, 153353792, 153484096,
+153616192, 153747008, 153878336, 154008256, 154139968, 154270912,
+154402624, 154533824, 154663616, 154795712, 154926272, 155057984,
+155188928, 155319872, 155450816, 155580608, 155712064, 155843392,
+155971136, 156106688, 156237376, 156367424, 156499264, 156630976,
+156761536, 156892352, 157024064, 157155008, 157284416, 157415872,
+157545536, 157677248, 157810496, 157938112, 158071744, 158203328,
+158334656, 158464832, 158596288, 158727616, 158858048, 158988992,
+159121216, 159252416, 159381568, 159513152, 159645632, 159776192,
+159906496, 160038464, 160169536, 160300352, 160430656, 160563008,
+160693952, 160822208, 160956352, 161086784, 161217344, 161349184,
+161480512, 161611456, 161742272, 161873216, 162002752, 162135872,
+162266432, 162397888, 162529216, 162660032, 162790976, 162922048,
+163052096, 163184576, 163314752, 163446592, 163577408, 163707968,
+163839296, 163969984, 164100928, 164233024, 164364224, 164494912,
+164625856, 164756672, 164887616, 165019072, 165150016, 165280064,
+165412672, 165543104, 165674944, 165805888, 165936832, 166067648,
+166198336, 166330048, 166461248, 166591552, 166722496, 166854208,
+166985408, 167116736, 167246656, 167378368, 167508416, 167641024,
+167771584, 167903168, 168034112, 168164032, 168295744, 168427456,
+168557632, 168688448, 168819136, 168951616, 169082176, 169213504,
+169344832, 169475648, 169605952, 169738048, 169866304, 169999552,
+170131264, 170262464, 170393536, 170524352, 170655424, 170782016,
+170917696, 171048896, 171179072, 171310784, 171439936, 171573184,
+171702976, 171835072, 171966272, 172097216, 172228288, 172359232,
+172489664, 172621376, 172747712, 172883264, 173014208, 173144512,
+173275072, 173407424, 173539136, 173669696, 173800768, 173931712,
+174063424, 174193472, 174325696, 174455744, 174586816, 174718912,
+174849728, 174977728, 175109696, 175242688, 175374272, 175504832,
+175636288, 175765696, 175898432, 176028992, 176159936, 176291264,
+176422592, 176552512, 176684864, 176815424, 176946496, 177076544,
+177209152, 177340096, 177470528, 177600704, 177731648, 177864256,
+177994816, 178126528, 178257472, 178387648, 178518464, 178650176,
+178781888, 178912064, 179044288, 179174848, 179305024, 179436736,
+179568448, 179698496, 179830208, 180092608, 180223808, 180354752,
+180485696, 180617152, 180748096, 180877504, 181009984, 181139264,
+181272512, 181402688, 181532608, 181663168, 181795136, 181926592,
+182057536, 182190016, 182320192, 182451904, 182582336, 182713792,
+182843072, 182976064, 183107264, 183237056, 183368384, 183494848,
+183631424, 183762752, 183893824, 184024768, 184154816, 184286656,
+184417984, 184548928, 184680128, 184810816, 184941248, 185072704,
+185203904, 185335616, 185465408, 185596352, 185727296, 185859904,
+185989696, 186121664, 186252992, 186383552, 186514112, 186645952,
+186777152, 186907328, 187037504, 187170112, 187301824, 187429184,
+187562048, 187693504, 187825472, 187957184, 188087104, 188218304,
+188349376, 188481344, 188609728, 188743616, 188874304, 189005248,
+189136448, 189265088, 189396544, 189528128, 189660992, 189791936,
+189923264, 190054208, 190182848, 190315072, 190447424, 190577984,
+190709312, 190840768, 190971328, 191102656, 191233472, 191364032,
+191495872, 191626816, 191758016, 191888192, 192020288, 192148928,
+192282176, 192413504, 192542528, 192674752, 192805952, 192937792,
+193068608, 193198912, 193330496, 193462208, 193592384, 193723456,
+193854272, 193985984, 194116672, 194247232, 194379712, 194508352,
+194641856, 194772544, 194900672, 195035072, 195166016, 195296704,
+195428032, 195558592, 195690304, 195818176, 195952576, 196083392,
+196214336, 196345792, 196476736, 196607552, 196739008, 196869952,
+197000768, 197130688, 197262784, 197394368, 197523904, 197656384,
+197787584, 197916608, 198049472, 198180544, 198310208, 198442432,
+198573632, 198705088, 198834368, 198967232, 199097792, 199228352,
+199360192, 199491392, 199621696, 199751744, 199883968, 200014016,
+200146624, 200276672, 200408128, 200540096, 200671168, 200801984,
+200933312, 201062464, 201194944, 201326144, 201457472, 201588544,
+201719744, 201850816, 201981632, 202111552, 202244032, 202374464,
+202505152, 202636352, 202767808, 202898368, 203030336, 203159872,
+203292608, 203423296, 203553472, 203685824, 203816896, 203947712,
+204078272, 204208192, 204341056, 204472256, 204603328, 204733888,
+204864448, 204996544, 205125568, 205258304, 205388864, 205517632,
+205650112, 205782208, 205913536, 206044736, 206176192, 206307008,
+206434496, 206569024, 206700224, 206831168, 206961856, 207093056,
+207223616, 207355328, 207486784, 207616832, 207749056, 207879104,
+208010048, 208141888, 208273216, 208404032, 208534336, 208666048,
+208796864, 208927424, 209059264, 209189824, 209321792, 209451584,
+209582656, 209715136, 209845568, 209976896, 210106432, 210239296,
+210370112, 210501568, 210630976, 210763712, 210894272, 211024832,
+211156672, 211287616, 211418176, 211549376, 211679296, 211812032,
+211942592, 212074432, 212204864, 212334016, 212467648, 212597824,
+212727616, 212860352, 212991424, 213120832, 213253952, 213385024,
+213515584, 213645632, 213777728, 213909184, 214040128, 214170688,
+214302656, 214433728, 214564544, 214695232, 214826048, 214956992,
+215089088, 215219776, 215350592, 215482304, 215613248, 215743552,
+215874752, 216005312, 216137024, 216267328, 216399296, 216530752,
+216661696, 216790592, 216923968, 217054528, 217183168, 217316672,
+217448128, 217579072, 217709504, 217838912, 217972672, 218102848,
+218233024, 218364736, 218496832, 218627776, 218759104, 218888896,
+219021248, 219151936, 219281728, 219413056, 219545024, 219675968,
+219807296, 219938624, 220069312, 220200128, 220331456, 220461632,
+220592704, 220725184, 220855744, 220987072, 221117888, 221249216,
+221378368, 221510336, 221642048, 221772736, 221904832, 222031808,
+222166976, 222297536, 222428992, 222559936, 222690368, 222820672,
+222953152, 223083968, 223213376, 223345984, 223476928, 223608512,
+223738688, 223869376, 224001472, 224132672, 224262848, 224394944,
+224524864, 224657344, 224788288, 224919488, 225050432, 225181504,
+225312704, 225443776, 225574592, 225704768, 225834176, 225966784,
+226097216, 226229824, 226360384, 226491712, 226623424, 226754368,
+226885312, 227015104, 227147456, 227278528, 227409472, 227539904,
+227669696, 227802944, 227932352, 228065216, 228196288, 228326464,
+228457792, 228588736, 228720064, 228850112, 228981056, 229113152,
+229243328, 229375936, 229505344, 229636928, 229769152, 229894976,
+230030272, 230162368, 230292416, 230424512, 230553152, 230684864,
+230816704, 230948416, 231079616, 231210944, 231342016, 231472448,
+231603776, 231733952, 231866176, 231996736, 232127296, 232259392,
+232388672, 232521664, 232652608, 232782272, 232914496, 233043904,
+233175616, 233306816, 233438528, 233569984, 233699776, 233830592,
+233962688, 234092224, 234221888, 234353984, 234485312, 234618304,
+234749888, 234880832, 235011776, 235142464, 235274048, 235403456,
+235535936, 235667392, 235797568, 235928768, 236057152, 236190272,
+236322752, 236453312, 236583616, 236715712, 236846528, 236976448,
+237108544, 237239104, 237371072, 237501632, 237630784, 237764416,
+237895232, 238026688, 238157632, 238286912, 238419392, 238548032,
+238681024, 238812608, 238941632, 239075008, 239206336, 239335232,
+239466944, 239599168, 239730496, 239861312, 239992384, 240122816,
+240254656, 240385856, 240516928, 240647872, 240779072, 240909632,
+241040704, 241171904, 241302848, 241433408, 241565248, 241696192,
+241825984, 241958848, 242088256, 242220224, 242352064, 242481856,
+242611648, 242744896, 242876224, 243005632, 243138496, 243268672,
+243400384, 243531712, 243662656, 243793856, 243924544, 244054592,
+244187072, 244316608, 244448704, 244580032, 244710976, 244841536,
+244972864, 245104448, 245233984, 245365312, 245497792, 245628736,
+245759936, 245889856, 246021056, 246152512, 246284224, 246415168,
+246545344, 246675904, 246808384, 246939584, 247070144, 247199552,
+247331648, 247463872, 247593536, 247726016, 247857088, 247987648,
+248116928, 248249536, 248380736, 248512064, 248643008, 248773312,
+248901056, 249036608, 249167552, 249298624, 249429184, 249560512,
+249692096, 249822784, 249954112, 250085312, 250215488, 250345792,
+250478528, 250608704, 250739264, 250870976, 251002816, 251133632,
+251263552, 251395136, 251523904, 251657792, 251789248, 251919424,
+252051392, 252182464, 252313408, 252444224, 252575552, 252706624,
+252836032, 252968512, 253099712, 253227584, 253361728, 253493056,
+253623488, 253754432, 253885504, 254017216, 254148032, 254279488,
+254410432, 254541376, 254672576, 254803264, 254933824, 255065792,
+255196736, 255326528, 255458752, 255589952, 255721408, 255851072,
+255983296, 256114624, 256244416, 256374208, 256507712, 256636096,
+256768832, 256900544, 257031616, 257162176, 257294272, 257424448,
+257555776, 257686976, 257818432, 257949632, 258079552, 258211136,
+258342464, 258473408, 258603712, 258734656, 258867008, 258996544,
+259127744, 259260224, 259391296, 259522112, 259651904, 259784384,
+259915328, 260045888, 260175424, 260308544, 260438336, 260570944,
+260700992, 260832448, 260963776, 261092672, 261226304, 261356864,
+261487936, 261619648, 261750592, 261879872, 262011968, 262143424,
+262274752, 262404416, 262537024, 262667968, 262799296, 262928704,
+263061184, 263191744, 263322944, 263454656, 263585216, 263716672,
+263847872, 263978944, 264108608, 264241088, 264371648, 264501184,
+264632768, 264764096, 264895936, 265024576, 265158464, 265287488,
+265418432, 265550528, 265681216, 265813312, 265943488, 266075968,
+266206144, 266337728, 266468032, 266600384, 266731072, 266862272,
+266993344, 267124288, 267255616, 267386432, 267516992, 267648704,
+267777728, 267910592, 268040512, 268172096, 268302784, 268435264,
+268566208, 268696256, 268828096, 268959296, 269090368, 269221312,
+269352256, 269482688, 269614784, 269745856, 269876416, 270007616,
+270139328, 270270272, 270401216, 270531904, 270663616, 270791744,
+270924736, 271056832, 271186112, 271317184, 271449536, 271580992,
+271711936, 271843136, 271973056, 272105408, 272236352, 272367296,
+272498368, 272629568, 272759488, 272891456, 273022784, 273153856,
+273284672, 273415616, 273547072, 273677632, 273808448, 273937088,
+274071488, 274200896, 274332992, 274463296, 274595392, 274726208,
+274857536, 274988992, 275118656, 275250496, 275382208, 275513024,
+275643968, 275775296, 275906368, 276037184, 276167872, 276297664,
+276429376, 276560576, 276692672, 276822976, 276955072, 277085632,
+277216832, 277347008, 277478848, 277609664, 277740992, 277868608,
+278002624, 278134336, 278265536, 278395328, 278526784, 278657728,
+278789824, 278921152, 279052096, 279182912, 279313088, 279443776,
+279576256, 279706048, 279838528, 279969728, 280099648, 280230976,
+280361408, 280493632, 280622528, 280755392, 280887104, 281018176,
+281147968, 281278912, 281411392, 281542592, 281673152, 281803712,
+281935552, 282066496, 282197312, 282329024, 282458816, 282590272,
+282720832, 282853184, 282983744, 283115072, 283246144, 283377344,
+283508416, 283639744, 283770304, 283901504, 284032576, 284163136,
+284294848, 284426176, 284556992, 284687296, 284819264, 284950208,
+285081536]
+```
diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md
new file mode 100644
index 00000000000..4b6dd5f98a1
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md
@@ -0,0 +1,42 @@
+---
+title: Těžební algoritmy
+description: Podrobný pohled na algoritmy používané pro těžbu Etherea.
+lang: cs
+---
+
+
+
+
+Proof-of-work již není základním mechanismem konsensu Etherea, což znamená, že těžení bylo vypnuto. Místo toho je Ethereum zabezpečeno validátory, kteří stakují ETH. Své ETH můžete začít stakeovat hned dnes. Přečtěte si více o Sloučení, proof-of-stake a stakování. Tato stránka má pouze historický význam.
+
+
+
+
+Těžba Etherea používala algoritmus známý jako Ethash. Základní myšlenkou algoritmu je, že se těžař snaží najít vstupní nonce pomocí výpočtu hrubou silou tak, aby výsledný haš byl menší než prahová hodnota určená vypočítanou obtížností. Tuto úroveň obtížnosti lze dynamicky upravovat, což umožňuje, aby produkce bloků probíhala v pravidelném intervalu.
+
+## Předpoklady {#prerequisites}
+
+Pro lepší pochopení této stránky vám doporučujeme si nejprve přečíst o [konsensu proof-of-work](/developers/docs/consensus-mechanisms/pow) a [těžbě](/developers/docs/consensus-mechanisms/pow/mining).
+
+## Dagger Hashimoto {#dagger-hashimoto}
+
+Dagger Hashimoto byl předběžný výzkumný algoritmus pro těžbu Etherea, který nahradil Ethash. Jednalo se o spojení dvou různých algoritmů: Dagger a Hashimoto. Šlo pouze o výzkumnou implementaci, která byla v době spuštění mainnetu Etherea nahrazena algoritmem Ethash.
+
+[Dagger](http://www.hashcash.org/papers/dagger.html) zahrnuje generování [orientovaného acyklického grafu](https://en.wikipedia.org/wiki/Directed_acyclic_graph), jehož náhodné části se společně hašují. Základním principem je, že každá nonce vyžaduje pouze malou část velkého celkového datového stromu. Přepočítávání podstromu pro každou nonce je pro těžbu neúnosné – proto je nutné strom uložit –, ale pro ověření jediné hodnoty nonce je to v pořádku. Dagger byl navržen jako alternativa ke stávajícím algoritmům, jako je Scrypt, které jsou paměťově náročné (memory-hard), ale obtížně se ověřují, když se jejich paměťová náročnost zvýší na skutečně bezpečnou úroveň. Dagger byl však zranitelný vůči hardwarové akceleraci sdílené paměti a bylo od něj upuštěno ve prospěch jiných směrů výzkumu.
+
+[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) je algoritmus, který přidává odolnost vůči ASIC tím, že je vázán na I/O (vstup/výstup) (tj. čtení z paměti je limitujícím faktorem v procesu těžby). Teorie je taková, že paměť RAM je dostupnější než výpočetní výkon; výzkum v hodnotě miliard dolarů se již zabýval optimalizací paměti RAM pro různé případy použití, které často zahrnují téměř náhodné vzory přístupu (odtud „paměť s náhodným přístupem“). V důsledku toho je stávající paměť RAM pravděpodobně poměrně blízko optimu pro vyhodnocování algoritmu. Hashimoto používá blockchain jako zdroj dat a současně splňuje body (1) a (3) uvedené výše.
+
+Dagger-Hashimoto používal upravené verze algoritmů Dagger a Hashimoto. Rozdíl mezi Dagger Hashimoto a Hashimoto je v tom, že namísto použití blockchainu jako zdroje dat používá Dagger Hashimoto vlastní vygenerovanou datovou sadu, která se aktualizuje na základě dat bloku každých N bloků. Datová sada se generuje pomocí algoritmu Dagger, což umožňuje efektivní výpočet podmnožiny specifické pro každou nonce pro ověřovací algoritmus lehkého klienta. Rozdíl mezi algoritmy Dagger Hashimoto a Dagger je v tom, že na rozdíl od původního Daggeru je datová sada používaná k dotazování bloku semipermanentní a aktualizuje se pouze v občasných intervalech (např. jednou týdně). To znamená, že část úsilí vynaloženého na generování datové sady se blíží nule, takže argumenty Sergia Lernera ohledně zrychlení díky sdílené paměti se stávají zanedbatelnými.
+
+Více o [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto).
+
+## Ethash {#ethash}
+
+Ethash byl těžební algoritmus, který se skutečně používal na mainnetu Etherea v rámci dnes již zastaralé architektury proof-of-work. Ethash byl v podstatě nový název pro specifickou verzi Dagger-Hashimoto poté, co byl algoritmus výrazně aktualizován, přičemž si stále zachoval základní principy svého předchůdce. Mainnet Etherea používal pouze Ethash – Dagger Hashimoto byl verzí těžebního algoritmu pro výzkum a vývoj, která byla nahrazena předtím, než začala těžba na mainnetu Etherea.
+
+Více o [Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash).
+
+## Další čtení {#further-reading}
+
+_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_
diff --git a/public/content/translations/cs/developers/docs/dapps/index.md b/public/content/translations/cs/developers/docs/dapps/index.md
index 4687126396f..45ae01d3237 100644
--- a/public/content/translations/cs/developers/docs/dapps/index.md
+++ b/public/content/translations/cs/developers/docs/dapps/index.md
@@ -1,64 +1,64 @@
---
-title: Úvod do dappek
+title: Technický úvod do dapps
description:
lang: cs
---
-Decentralizovaná aplikace (dappka) je aplikace naprogramovaná na decentralizované síti, která kombinuje [chytrý kontrakt](/developers/docs/smart-contracts/) a frontendové uživatelské rozhraní. V Ethereu jsou chytré kontrakty přístupné a transparentní jako otevřené API, takže vaše dappka může obsahovat i chytrý kontrakt, který napsal někdo jiný.
+Decentralizovaná aplikace (dapp) je aplikace vytvořená na decentralizované síti, která kombinuje [chytrý kontrakt](/developers/docs/smart-contracts/) a frontendové uživatelské rozhraní. V Ethereu jsou chytré kontrakty přístupné a transparentní jako otevřené API, takže vaše dappka může obsahovat i chytrý kontrakt, který napsal někdo jiný.
## Předpoklady {#prerequisites}
-Než se začnete učit o dappkách, měli byste se seznámit se[ základy blockchainu](/developers/docs/intro-to-ethereum/) a přečíst si něco o síti Ethereu a o její decentralizaci.
+Než se začnete učit o dapps, měli byste se seznámit se [základy blockchainu](/developers/docs/intro-to-ethereum/) a přečíst si o síti Ethereum a její decentralizaci.
-## Definice dappky {#definition-of-a-dapp}
+## Definice dapp {#definition-of-a-dapp}
Dappka má svůj backendový kód spuštěný v decentralizované peer-to-peer síti. To je v kontrastu s aplikací, jejíž backendový kód běží na centralizovaných serverech.
-Dappka může mít frontendový kód a uživatelská rozhraní napsaná v libovolném programovacím jazyce (stejně jako aplikace), který může volat její backend. Kromě toho může být její frontend umístěn na decentralizovaném úložišti, jako je [IPFS](https://ipfs.io/).
+Dappka může mít frontendový kód a uživatelská rozhraní napsaná v libovolném programovacím jazyce (stejně jako aplikace), který může volat její backend. Kromě toho může být její frontend hostován na decentralizovaném úložišti, jako je [IPFS](https://ipfs.io/).
-- **Decentralizované** – dappky fungují na Ethereu, otevřené veřejné decentralizované platformě, nad kterou nemá kontrolu žádná jednotlivá osoba ani skupina.
-- **Deterministické** – dappky vykonávají stejnou funkci bez ohledu na prostředí, ve kterém jsou spuštěny.
-- **Turingovsky úplné** – dappky mohou provádět jakoukoliv akci, pokud mají k dispozici potřebné prostředky.
-- **Izolované** – dappky jsou spouštěny ve virtuálním prostředí známém jako Virtuální stroj Etherea, takže pokud chytrý kontrakt obsahuje nějakou chybu, neovlivní to běžné fungování blockchainové sítě.
+- **Decentralizované** – dapps fungují na Ethereu, otevřené veřejné decentralizované platformě, nad kterou nemá kontrolu žádná osoba ani skupina.
+- **Deterministické** – dapps vykonávají stejnou funkci bez ohledu na prostředí, ve kterém jsou spuštěny.
+- **Turingovsky úplné** – dapps mohou provádět jakoukoli akci, pokud mají k dispozici potřebné prostředky.
+- **Izolované** – dapps jsou spouštěny ve virtuálním prostředí známém jako Ethereum Virtual Machine (EVM), takže pokud má chytrý kontrakt chybu, neovlivní to běžné fungování blockchainové sítě.
### O chytrých kontraktech {#on-smart-contracts}
-Abychom mohli vysvětlit fungování dappek, musíme nejdříve vysvětlit chytré kontrakty – backend dappek, což není úplně přesné, ale lepší popis neexistuje. Podrobný přehled naleznete v sekci o [chytrých kontraktech](/developers/docs/smart-contracts/).
+Abychom mohli vysvětlit fungování dappek, musíme nejdříve vysvětlit chytré kontrakty – backend dappek, což není úplně přesné, ale lepší popis neexistuje. Podrobný přehled naleznete v naší sekci o [chytrých kontraktech](/developers/docs/smart-contracts/).
Chytrý kontrakt je kód, který žije v blockchainu Etherea a běží přesně tak, jak je naprogramován. Jakmile jsou chytré kontrakty spuštěny na síti, nemůžete je měnit. Dappky mohou být decentralizované, protože jsou řízeny logikou zapsanou do kontraktu, nikoli jednotlivcem nebo společností. To také znamená, že musíte své kontrakty navrhovat velmi pečlivě a důkladně je testovat.
-## Výhody vývoje dappek {#benefits-of-dapp-development}
+## Výhody vývoje dapps {#benefits-of-dapp-development}
-- **Žádné výpadky** – Jakmile je chytrý kontrakt umístěn na blockchain a spuštěn, síť jako celek bude vždy schopna vyhovět uživatelům, kteří chtějí s kontraktem komunikovat. Zlomyslní aktéři proto nemohou provádět útoky typu DoS zaměřené na jednotlivé dappky.
-- **Soukromí** – K nasazení dappky nebo interakci s ní není třeba zveřejnit svoji skutečnou identitu.
-- **Odolnost vůči cenzuře** – Žádný subjekt v síti nemůže uživatelům blokovat zadávání transakcí, nasazování dappek nebo čtení dat z blockchainu.
+- **Žádné výpadky** – Jakmile je chytrý kontrakt nasazen na blockchain, síť jako celek bude vždy schopna obsloužit klienty, kteří chtějí s kontraktem interagovat. Zlomyslní aktéři proto nemohou provádět útoky typu DoS zaměřené na jednotlivé dappky.
+- **Soukromí** – K nasazení dapp nebo interakci s ní nemusíte poskytovat svou skutečnou identitu.
+- **Odolnost vůči cenzuře** – Žádný subjekt v síti nemůže uživatelům blokovat odesílání transakcí, nasazování dapps nebo čtení dat z blockchainu.
- **Úplná integrita dat** – Data uložená na blockchainu jsou díky kryptografickým primitivům neměnná a nezpochybnitelná. Zlomyslní aktéři nemohou falšovat transakce ani jiná data, která již byla zveřejněna.
-- **Výpočty / ověřitelné chování bez nutnosti důvěry** – Chytré kontrakty lze analyzovat a je zaručeno, že se budou provádět předvídatelně, aniž by bylo nutné důvěřovat nějaké centrální autoritě. To v tradičních modelech neplatí. Např. když používáme systémy internetového bankovnictví, musíme věřit, že finanční instituce nezneužijí naše finanční údaje, nezmanipulují záznamy nebo se do nich nenabourají hackeři.
+- **Výpočty bez nutnosti důvěry / ověřitelné chování** – Chytré kontrakty lze analyzovat a je zaručeno, že se budou provádět předvídatelným způsobem, aniž by bylo nutné důvěřovat centrální autoritě. To v tradičních modelech neplatí. Např. když používáme systémy internetového bankovnictví, musíme věřit, že finanční instituce nezneužijí naše finanční údaje, nezmanipulují záznamy nebo se do nich nenabourají hackeři.
-## Nevýhody vývoje dappek {#drawbacks-of-dapp-development}
+## Nevýhody vývoje dapps {#drawbacks-of-dapp-development}
-- **Údržba** – Údržba dappek je náročnější, protože kód a data publikovaná na blockchainu se hůře upravují. Pro vývojáře je těžké aktualizovat dappky (nebo podkladová data, která dappky ukládají), jakmile jsou nasazeny, když jsou ve staré verzi identifikovány chyby nebo bezpečnostní rizika.
-- **Výkonnostní režie** – Výkonnostní režie je obrovská a škálování je opravdu obtížné. Aby bylo dosaženo úrovně bezpečnosti, integrity, transparentnosti a spolehlivosti, o kterou Ethereum usiluje, musí každý uzel spouštět a ukládat každou transakci. Kromě toho, nějaký čas zabere i konsenzus důkazu podílem.
-- **Přetížení sítě** – Pokud jedna dappka využívá příliš mnoho výpočetních zdrojů, celá síť se zahltí. V současné době je síť schopna zpracovat pouze asi 10–15 transakcí za sekundu. Pokud jsou transakce odesílány rychleji, může fond nepotvrzených transakcí rychle narůstat.
-- **Uživatelská zkušenost** – Může být obtížnější navrhnout uživatelsky přívětivé prostředí, protože průměrný koncový uživatel by mohl považovat za příliš složité nastavit nástrojový stack nezbytný pro skutečně bezpečnou interakci s blockchainem.
-- **Centralizace** – Uživatelsky a vývojářsky přívětivá řešení spuštěná na základní vrstvě Etherea mohou nakonec vypadat jako centralizované služby. Např. takové služby mohou ukládat klíče nebo jiné citlivé informace na serverové straně, poskytovat frontend pomocí centralizovaného serveru nebo provozovat důležitou obchodní logiku na centralizovaném serveru před zápisem na blockchain. Centralizace eliminuje mnoho (ne-li všechny) výhod blockchainu oproti tradičnímu modelu.
+- **Údržba** – Udržovat dapps může být těžší, protože kód a data publikovaná na blockchainu se hůře upravují. Pro vývojáře je těžké aktualizovat dappky (nebo podkladová data, která dappky ukládají), jakmile jsou nasazeny, když jsou ve staré verzi identifikovány chyby nebo bezpečnostní rizika.
+- **Výkonnostní režie** – Existuje obrovská výkonnostní režie a škálování je opravdu obtížné. Aby bylo dosaženo úrovně bezpečnosti, integrity, transparentnosti a spolehlivosti, o kterou Ethereum usiluje, musí každý uzel spouštět a ukládat každou transakci. Kromě toho, nějaký čas zabere i konsenzus důkazu podílem.
+- **Přetížení sítě** – Když jedna dapp využívá příliš mnoho výpočetních zdrojů, celá síť se zahltí. V současné době je síť schopna zpracovat pouze asi 10–15 transakcí za sekundu. Pokud jsou transakce odesílány rychleji, může fond nepotvrzených transakcí rychle narůstat.
+- **Uživatelská zkušenost** – Může být obtížnější navrhnout uživatelsky přívětivé prostředí, protože průměrný koncový uživatel může považovat za příliš složité nastavit sadu nástrojů nezbytnou pro skutečně bezpečnou interakci s blockchainem.
+- **Centralizace** – Uživatelsky a vývojářsky přívětivá řešení postavená na základní vrstvě Etherea mohou nakonec stejně vypadat jako centralizované služby. Např. takové služby mohou ukládat klíče nebo jiné citlivé informace na serverové straně, poskytovat frontend pomocí centralizovaného serveru nebo provozovat důležitou obchodní logiku na centralizovaném serveru před zápisem na blockchain. Centralizace eliminuje mnoho (ne-li všechny) výhod blockchainu oproti tradičnímu modelu.
-## Učíte se spíše vizuálně? {#visual-learner}
+## Učíte se spíše vizuálně? Vizuální výuka {#visual-learner}
,
+ number3: u64
+ }
+
+ dummy = Dummy{
+
+ number1: 37,
+ number2: 55,
+ vector: vec![1,2,3,4],
+ number3: 22,
+ }
+
+ serialized = ssz.serialize(dummy)
+
+```
+
+`serialized` by mělo následující strukturu (zde pouze doplněno na 4 bity, ve skutečnosti doplněno na 32 bitů a pro přehlednost je zachována reprezentace `int`):
+
+```
+[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4]
+------------ ----------- ----------- ----------- ----------
+ | | | | |
+ number1 number2 posun pro number 3 hodnota pro
+ vektor vektor
+
+```
+
+pro přehlednost je rozdělíme do řádků:
+
+```
+[
+ 37, 0, 0, 0, # kódování `number1` v pořadí little-endian.
+ 55, 0, 0, 0, # kódování `number2` v pořadí little-endian.
+ 16, 0, 0, 0, # „Posun“, který udává, kde začíná hodnota `vector` (little-endian 16).
+ 22, 0, 0, 0, # kódování `number3` v pořadí little-endian.
+ 1, 2, 3, 4, # Skutečné hodnoty ve `vector`.
+]
+```
+
+Toto je stále zjednodušení - celá čísla a nuly ve schématech výše by ve skutečnosti byly uloženy bytelisty, jako je tento:
+
+```
+[
+ 10100101000000000000000000000000 # kódování `number1` v pořadí little-endian
+ 10110111000000000000000000000000 # kódování `number2` v pořadí little-endian.
+ 10010000000000000000000000000000 # „Posun“, který udává, kde začíná hodnota `vector` (little-endian 16).
+ 10010110000000000000000000000000 # kódování `number3` v pořadí little-endian.
+ 10000001100000101000001110000100 # Skutečná hodnota pole `bytes`.
+]
+```
+
+Takže skutečné hodnoty pro typy s proměnlivou délkou jsou uloženy v zásobníku na konci serializovaného objektu, přičemž jejich offsety jsou uloženy na správných pozicích v uspořádaném seznamu polí.
+
+Existují také některé speciální případy, které vyžadují specifické zacházení, například typ `BitList`, který vyžaduje přidání délkového limitu během serializace a jeho odstranění během deserializace. Veškeré podrobnosti jsou k dispozici ve [specifikaci SSZ](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md).
+
+### Deserializace {#deserialization}
+
+K deserializaci tohoto objektu je zapotřebí schéma. Schéma definuje přesné uspořádání serializovaných dat tak, aby každý konkrétní prvek mohl být deserializován z blobu bajtů do nějakého smysluplného objektu s prvky majícími správný typ, hodnotu, velikost a pozici. Je to právě schéma, které říká deserializátoru, které hodnoty jsou skutečné hodnoty a které jsou offsety. Všechny názvy polí zmizí, když je objekt serializován, ale při deserializaci se podle schématu znovu vytvoří.
+
+Pro interaktivní vysvětlení se podívejte na [ssz.dev](https://www.ssz.dev/overview).
+
+## Merkleizace {#merkleization}
+
+Tento SSZ serializovaný objekt pak může být merkelizován - to znamená transformován do Merkleova stromu reprezentujícího stejná data. Nejprve se určí počet 32bajtových bloků v serializovaném objektu. Tyto bloky tvoří „listy“ stromu. Celkový počet listů musí být mocnina dvou, aby hašování listů nakonec vytvořilo jediný hašový kořen stromu. Pokud tomu tak přirozeně není, jsou přidány další listy obsahující 32 bajtů nul. Schématicky:
+
+```
+ kořen hašového stromu
+ / \
+ / \
+ / \
+ / \
+ haš listů haš listů
+ 1 a 2 3 a 4
+ / \ / \
+ / \ / \
+ / \ / \
+ list1 list2 list3 list4
+```
+
+Existují také případy, kdy se listy stromu přirozeně nerozdělují rovnoměrně, jako tomu bylo v předchozím příkladu. Například list 4 by mohl být kontejner s více prvky, které vyžadují přidání další "hloubky" do Merkle tree, čímž se vytvoří nerovnoměrný strom.
+
+Místo toho, abychom tyto prvky stromu označovali jako list X, uzel X atd., můžeme jim přiřadit zobecněné indexy, počínaje kořenem = 1 a číslováním zleva doprava na každé úrovni. Toto je zobecněný index, který jsme vysvětlili výše. Každý prvek v serializovaném seznamu má zobecněný index rovný `2**depth + idx`, kde idx je jeho pozice s indexem nula v serializovaném objektu a hloubka je počet úrovní v Merkle tree, který lze určit jako logaritmus počtu prvků (listů) při základu 2.
+
+## Zobecněné indexy {#generalized-indices}
+
+Zobecněný index je celé číslo, které představuje uzel v binárním Merkle tree, kde každý uzel má zobecněný index `2 ** depth + index in row`.
+
+```
+ 1 --hloubka = 0 2**0 + 0 = 1
+ 2 3 --hloubka = 1 2**1 + 0 = 2, 2**1+1 = 3
+ 4 5 6 7 --hloubka = 2 2**2 + 0 = 4, 2**2 + 1 = 5...
+
+```
+
+Toto zobrazení poskytuje index uzlu pro každý datový prvek v Merkletree.
+
+## Multiproofy {#multiproofs}
+
+Poskytnutí seznamu zobecněných indexů představujících konkrétní prvek nám umožňuje jej ověřit vůči hašovému kořenovému stromu. Tento kořen je naším přijatým zobrazením reality. Jakákoli data, která nám jsou poskytnuta, mohou být ověřena vůči této realitě vložením do správného místa v Merkle tree (určeného jeho zobecněným indexem) a pozorováním, zda kořen zůstává konstantní. Ve specifikaci [zde](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) jsou funkce, které ukazují, jak vypočítat minimální sadu uzlů potřebnou k ověření obsahu konkrétní sady zobecněných indexů.
+
+Například k ověření dat na indexu 9 v níže uvedeném stromu potřebujeme haš dat na indexech 8, 9, 5, 3, 1.
+Haš (8,9) by měl být roven haši (4), který se hašuje s 5 a vytváří 2, který se hašuje s 3 a vytváří kořen stromu 1. Pokud by byla poskytnuta nesprávná data pro 9, kořen by se změnil – to bychom zjistili a ověření větve by selhalo.
+
+```
+* = data potřebná k vygenerování důkazu
+
+ 1*
+ 2 3*
+ 4 5* 6 7
+8* 9* 10 11 12 13 14 15
+
+```
+
+## Další čtení {#further-reading}
+
+- [Vylepšení Etherea: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz)
+- [Vylepšení Etherea: Merkleizace](https://eth2book.info/altair/part2/building_blocks/merkleization)
+- [Implementace SSZ](https://github.com/ethereum/consensus-specs/issues/2138)
+- [Kalkulačka SSZ](https://simpleserialize.com/)
+- [SSZ.dev](https://www.ssz.dev/)
diff --git a/public/content/translations/cs/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md b/public/content/translations/cs/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md
new file mode 100644
index 00000000000..01835a97a08
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md
@@ -0,0 +1,195 @@
+---
+title: Definice tajného úložiště web3
+description: Formální definice pro tajné úložiště web3
+lang: cs
+sidebarDepth: 2
+---
+
+Aby vaše aplikace fungovala na síti Ethereum, můžete použít objekt web3 poskytovaný knihovnou web3.js. Na pozadí komunikuje s místním uzlem prostřednictvím volání RPC. [web3](https://github.com/ethereum/web3.js/) funguje s jakýmkoli uzlem Ethereum, který zpřístupňuje vrstvu RPC.
+
+`web3` obsahuje objekt `eth` – web3.eth.
+
+```js
+var fs = require("fs")
+var recognizer = require("ethereum-keyfile-recognizer")
+
+fs.readFile("keyfile.json", (err, data) => {
+ var json = JSON.parse(data)
+ var result = recognizer(json)
+})
+
+/** výsledek
+ * [ 'web3', 3 ] soubor s klíčem web3 (v3)
+ * [ 'ethersale', undefined ] soubor s klíčem Ethersale
+ * null neplatný soubor s klíčem
+ */
+```
+
+Tento dokument popisuje **verzi 3** definice tajného úložiště Web3.
+
+## Definice {#definition}
+
+Vlastní kódování a dekódování souboru zůstává z velké části nezměněno oproti verzi 1, s tím rozdílem, že kryptoalgoritmus již není pevně nastaven na AES-128-CBC (minimálním požadavkem je nyní AES-128-CTR). Většina významů/algoritmů je podobná verzi 1, kromě `mac`, který je dán jako SHA3 (keccak-256) zřetězení druhých 16 bajtů zleva odvozeného klíče společně s úplným `ciphertextem`.
+
+Soubory s tajným klíčem jsou uloženy přímo v `~/.web3/keystore` (pro systémy podobné Unixu) a `~/AppData/Web3/keystore` (pro Windows). Mohou být pojmenovány jakkoli, ale dobrou konvencí je `.json`, kde `` je 128bitový identifikátor UUID přiřazený tajnému klíči (proxy chránící soukromí pro adresu tajného klíče).
+
+Všechny takové soubory mají přidružené heslo. Chcete-li odvodit tajný klíč daného souboru `.json`, nejprve odvoďte šifrovací klíč souboru; to se provede tak, že vezmete heslo souboru a předáte ho funkci pro odvození klíče, jak je popsáno v klíči `kdf`. Statické a dynamické parametry závislé na KDF pro funkci KDF jsou popsány v klíči `kdfparams`.
+
+PBKDF2 musí být podporován všemi minimálně vyhovujícími implementacemi, označeno jako:
+
+- `kdf`: `pbkdf2`
+
+Pro PBKDF2 parametry kdfparams zahrnují:
+
+- `prf`: Musí být `hmac-sha256` (může být v budoucnu rozšířen);
+- `c`: počet iterací;
+- `salt`: sůl předaná do PBKDF;
+- `dklen`: délka odvozeného klíče. Musí být >= 32.
+
+Jakmile byl klíč souboru odvozen, měl by být ověřen prostřednictvím odvození MAC. MAC by se měl vypočítat jako haš SHA3 (keccak-256) bajtového pole vytvořeného zřetězením druhých 16 bajtů zleva odvozeného klíče s obsahem klíče `ciphertext`, tj.:
+
+```js
+KECCAK(DK[16..31] ++ )
+```
+
+(kde `++` je operátor zřetězení)
+
+Tato hodnota by se měla porovnat s obsahem klíče `mac`; pokud se liší, mělo by se vyžádat alternativní heslo (nebo operace zrušena).
+
+Po ověření klíče souboru může být šifrovaný text (klíč `ciphertext` v souboru) dešifrován pomocí algoritmu symetrického šifrování specifikovaného klíčem `cipher` a parametrizovaného pomocí klíče `cipherparams`. Pokud se velikost odvozeného klíče a velikost klíče algoritmu neshodují, měly by se jako klíč k algoritmu použít nejvíce pravé bajty odvozeného klíče, doplněné nulami.
+
+Všechny minimálně vyhovující implementace musí podporovat algoritmus AES-128-CTR, označený jako:
+
+- `cipher: aes-128-ctr`
+
+Tato šifra přebírá následující parametry, uvedené jako klíče ke klíči cipherparams:
+
+- `iv`: 128bitový inicializační vektor pro šifru.
+
+Klíčem pro šifru je 16 nejvíce levých bajtů odvozeného klíče, tj. `DK[0..15]`
+
+Vytvoření/zašifrování tajného klíče by mělo být v podstatě opakem těchto pokynů. Ujistěte se, že `uuid`, `salt` a `iv` jsou skutečně náhodné.
+
+Kromě pole `version`, které by mělo fungovat jako "tvrdý" identifikátor verze, mohou implementace také používat `minorversion` ke sledování menších změn formátu, které nenaruší zpětnou kompatibilitu.
+
+## Testovací vektory {#test-vectors}
+
+Podrobnosti:
+
+- `Adresa`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b`
+- `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67`
+- `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6`
+- `Heslo`: `testpassword`
+- `Tajný klíč`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d`
+
+### PBKDF2-SHA-256 {#PBKDF2-SHA-256}
+
+Testovací vektor používající `AES-128-CTR` a `PBKDF2-SHA-256`:
+
+Obsah souboru `~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json`:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-ctr",
+ "cipherparams": {
+ "iv": "6087dab2f9fdbbfaddc31a909735c1e6"
+ },
+ "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46",
+ "kdf": "pbkdf2",
+ "kdfparams": {
+ "c": 262144,
+ "dklen": 32,
+ "prf": "hmac-sha256",
+ "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd"
+ },
+ "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2"
+ },
+ "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
+ "version": 3
+}
+```
+
+**Mezivýsledky**:
+
+`Odvozený klíč`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551`
+`Tělo MAC`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46`
+`MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2`
+`Šifrovací klíč`: `f06d69cdc7da0faffb1008270bca38f5`
+
+### Scrypt {#scrypt}
+
+Testovací vektor používající AES-128-CTR a Scrypt:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-ctr",
+ "cipherparams": {
+ "iv": "740770fce12ce862af21264dab25f1da"
+ },
+ "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2",
+ "kdf": "scrypt",
+ "kdfparams": {
+ "dklen": 32,
+ "n": 262144,
+ "p": 1,
+ "r": 8,
+ "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034"
+ },
+ "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c"
+ },
+ "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
+ "version": 3
+}
+```
+
+**Mezivýsledky**:
+
+`Odvozený klíč`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d`
+`Tělo MAC`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2`
+`MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c`
+`Šifrovací klíč`: `7446f59ecc301d2d79bc3302650d8a5c`
+
+## Změny oproti verzi 1 {#alterations-from-v2}
+
+Tato verze opravuje několik nesrovnalostí s verzí 1 publikovanou [zde](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst). Stručně řečeno se jedná o:
+
+- Použití velkých a malých písmen je neopodstatněné a nekonzistentní (scrypt malými písmeny, Kdf s různou velikostí písmen, MAC velkými písmeny).
+- Adresa je zbytečná a ohrožuje soukromí.
+- `Salt` je ze své podstaty parametrem funkce pro odvození klíče a zaslouží si být s ní spojena, nikoli s kryptem obecně.
+- _SaltLen_ je zbytečné (stačí jej odvodit ze Salt).
+- Funkce pro odvození klíče je dána, ale kryptoalgoritmus je pevně specifikován.
+- `Version` je ze své podstaty číselná, ale je to řetězec (strukturované verzování by bylo možné s řetězcem, ale lze to považovat za nadbytečné pro formát konfiguračního souboru, který se mění jen zřídka).
+- `KDF` a `cipher` jsou teoreticky sourozenecké koncepty, ale jsou organizovány odlišně.
+- `MAC` se vypočítává z datového bloku, který ignoruje prázdné znaky (!)
+
+Ve formátu byly provedeny změny tak, aby vznikl následující soubor, který je funkčně ekvivalentní příkladu uvedenému na dříve odkazované stránce:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-cbc",
+ "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b",
+ "cipherparams": {
+ "iv": "16d67ba0ce5a339ff2f07951253e6ba8"
+ },
+ "kdf": "scrypt",
+ "kdfparams": {
+ "dklen": 32,
+ "n": 262144,
+ "p": 1,
+ "r": 8,
+ "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91"
+ },
+ "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd",
+ "version": 1
+ },
+ "id": "0498f19a-59db-4d54-ac95-33901b4f1870",
+ "version": 2
+}
+```
+
+## Změny oproti verzi 2 {#alterations-from-v2}
+
+Verze 2 byla raná implementace v C++ s řadou chyb. Všechny základní věci v ní zůstávají beze změny.
diff --git a/public/content/translations/cs/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/cs/developers/docs/design-and-ux/dex-design-best-practice/index.md
new file mode 100644
index 00000000000..8f9371277a5
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/design-and-ux/dex-design-best-practice/index.md
@@ -0,0 +1,219 @@
+---
+title: Osvědčené postupy návrhu decentralizovaných burz (DEX)
+description: Průvodce vysvětlující rozhodnutí o návrhu UX/UI pro směnu tokenů.
+lang: cs
+---
+
+Od spuštění Uniswapu v roce 2018 byly spuštěny stovky decentralizovaných burz na desítkách různých řetězců.
+Mnohé z nich zavedly nové prvky nebo přidaly vlastní vylepšení, ale rozhraní zůstalo obecně stejné.
+
+Jedním z důvodů je [Jakobův zákon](https://lawsofux.com/jakobs-law/):
+
+> Uživatelé tráví většinu svého času na jiných stránkách. To znamená, že uživatelé dávají přednost tomu, aby vaše stránky fungovaly stejně jako všechny ostatní stránky, které již znají.
+
+Díky prvním inovátorům, jako jsou Uniswap, Pancakeswap a Sushiswap, mají uživatelé DeFi kolektivní představu o tom, jak DEX vypadá.
+Z tohoto důvodu se nyní objevuje něco jako „osvědčený postup“. Stále častěji vidíme, že se rozhodnutí o designu napříč weby standardizují. Vývoj DEX můžete vnímat jako obrovský příklad testování v reálném čase. Věci, které fungovaly, zůstaly, věci, které ne, byly zahozeny. Stále je zde prostor pro osobitost, ale existují určité standardy, kterým by měla DEX vyhovovat.
+
+Tento článek je shrnutím:
+
+- co zahrnout
+- jak to udělat co nejpoužitelnější
+- hlavní způsoby přizpůsobení designu
+
+Všechny příklady drátěných modelů (wireframes) byly vytvořeny speciálně pro tento článek, ačkoli všechny vycházejí ze skutečných projektů.
+
+Sada pro Figmu je také zahrnuta na konci – klidně ji použijte a zrychlete si tak tvorbu vlastních drátěných modelů!
+
+## Základní anatomie DEX {#basic-anatomy-of-a-dex}
+
+Uživatelské rozhraní (UI) obecně obsahuje tři prvky:
+
+1. Hlavní formulář
+2. Tlačítko
+3. Panel s podrobnostmi
+
+
+
+## Varianty {#variations}
+
+To bude v tomto článku běžné téma, ale existují různé způsoby, jak mohou být tyto prvky uspořádány. „Panel podrobností“ může být:
+
+- Nad tlačítkem
+- Pod tlačítkem
+- Skrytý v rozbalovacím panelu
+- A/nebo v modálním okně „náhledu“
+
+Pozn. Modální okno „náhledu“ je volitelné, ale pokud v hlavním uživatelském rozhraní zobrazujete jen velmi málo podrobností, stává se nezbytným.
+
+## Struktura hlavního formuláře {#structure-of-the-main-form}
+
+Toto je pole, kde si skutečně vybíráte, který token chcete směnit. Komponenta se skládá ze vstupního pole a malého tlačítka v jednom řádku.
+
+Burzy DEX obvykle zobrazují další podrobnosti v jednom řádku nad a v jednom řádku pod, i když to lze nakonfigurovat i jinak.
+
+
+
+## Varianty {#variations2}
+
+Jsou zde uvedeny dvě varianty uživatelského rozhraní; jedna bez ohraničení, která vytváří velmi otevřený design, a druhá, kde má vstupní řádek ohraničení, což vytváří zaměření na tento prvek.
+
+
+
+Tato základní struktura umožňuje v návrhu zobrazit **čtyři klíčové informace**: jednu v každém rohu. Pokud existuje pouze jeden horní/dolní řádek, pak jsou k dispozici pouze dvě místa.
+
+Během vývoje DeFi se sem zařadilo mnoho různých věcí.
+
+## Klíčové informace, které je třeba zahrnout {#key-info-to-include}
+
+- Zůstatek v peněžence
+- Tlačítko Max
+- Fiatový ekvivalent
+- Dopad na cenu u „obdržené“ částky
+
+V počátcích DeFi fiatový ekvivalent často chyběl. Pokud vytváříte jakýkoli projekt Web3, je nezbytné, aby byl zobrazen fiatový ekvivalent. Uživatelé stále přemýšlejí v místních měnách, takže aby to odpovídalo jejich mentálním modelům z reálného světa, mělo by to být zahrnuto.
+
+Ve druhém poli (v tom, kde si vybíráte token, na který směňujete) můžete také uvést dopad na cenu vedle částky ve fiat měně, a to výpočtem rozdílu mezi vstupní částkou a odhadovanou výstupní částkou. Je to poměrně užitečný detail, který je dobré zahrnout.
+
+Procentuální tlačítka (např. 25 %, 50 %, 75 %) mohou být užitečnou funkcí, ale zabírají více místa, přidávají více výzev k akci a zvyšují mentální zátěž. To samé platí pro procentuální posuvníky. Některá z těchto rozhodnutí ohledně UI budou záviset na vaší značce a typu uživatele.
+
+Další podrobnosti mohou být zobrazeny pod hlavním formulářem. Protože je tento typ informací určen především pro profesionální uživatele, dává smysl buď:
+
+- udržovat ho co nejminimálnější, nebo;
+- skrýt ho do rozbalovacího panelu
+
+
+
+## Další informace k zahrnutí {#extra-info-to-include}
+
+- Cenu tokenu
+- Skluz
+- Minimální obdržená částka
+- Očekávaný výstup
+- Dopad na cenu
+- Odhad nákladů na gas
+- Další poplatky
+- Směrování příkazu
+
+Některé z těchto údajů by mohly být volitelné.
+
+Směrování příkazů je zajímavé, ale pro většinu uživatelů nepředstavuje velký rozdíl.
+
+Některé další podrobnosti pouze uvádějí totéž různými způsoby. Například „minimální obdržená částka“ a „skluz“ jsou dvě strany téže mince. Pokud máte skluz nastavený na 1 %, pak minimální částka, kterou můžete očekávat, se rovná očekávanému výstupu - 1 %. Některá UI zobrazují očekávanou částku, minimální částku a skluz… Což je užitečné, ale možná až přehnané.
+
+Většina uživatelů stejně ponechá výchozí nastavení skluzu.
+
+„Dopad na cenu“ se často zobrazuje v závorkách vedle fiatového ekvivalentu v poli „Do“. Je to skvělý UX detail, který lze přidat, ale pokud je zobrazen zde, je opravdu nutné ho znovu zobrazovat níže? A pak znovu na obrazovce náhledu?
+
+Mnoho uživatelů (zejména těch, kteří směňují malé částky) se o tyto podrobnosti nebude starat; jednoduše zadají číslo a stisknou tlačítko pro směnu.
+
+
+
+Jaké podrobnosti přesně zobrazíte, bude záviset na vašem publiku a na tom, jaký dojem má aplikace budit.
+
+Pokud do panelu s podrobnostmi zahrnete toleranci skluzu, měli byste ji také umožnit upravovat přímo odtud. Toto je dobrý příklad „urychlovače“; šikovný trik v UX, který může zrychlit postupy zkušených uživatelů, aniž by to ovlivnilo obecnou použitelnost aplikace.
+
+
+
+Je dobré se pečlivě zamyslet nejen nad jednou konkrétní informací na jedné obrazovce, ale nad celým postupem: zadání čísel v hlavním formuláři → kontrola podrobností → kliknutí na obrazovku náhledu (pokud ji máte).
+Měl by být panel s podrobnostmi viditelný po celou dobu, nebo musí uživatel kliknout, aby ho rozbalil?
+Měli byste vytvářet tření přidáním obrazovky náhledu? To donutí uživatele zpomalit a zvážit svůj obchod, což může být užitečné. Ale chtějí vidět všechny stejné informace znovu? Co je pro ně v tuto chvíli nejužitečnější?
+
+## Možnosti návrhu {#design-options}
+
+Jak již bylo zmíněno, mnoho z toho závisí na vašem osobním stylu
+Kdo je váš uživatel?
+Jaká je vaše značka?
+Chcete „profesionální“ rozhraní, které zobrazuje každý detail, nebo chcete být minimalističtí?
+I když se zaměřujete na profesionální uživatele, kteří chtějí všechny možné informace, měli byste si pamatovat moudrá slova Alana Coopera:
+
+> Bez ohledu na to, jak krásné a skvělé je vaše rozhraní, bylo by lepší, kdyby ho bylo méně.
+
+### Struktura {#structure}
+
+- tokeny vlevo, nebo tokeny vpravo
+- 2 nebo 3 řádky
+- podrobnosti nad nebo pod tlačítkem
+- podrobnosti rozbalené, sbalené nebo nezobrazené
+
+### Styl komponenty {#component-style}
+
+- prázdný
+- s obrysem
+- vyplněný
+
+Z čistě UX hlediska na stylu UI záleží méně, než si myslíte. Vizuální trendy přicházejí a odcházejí v cyklech a mnoho preferencí je subjektivních.
+
+Nejjednodušší způsob, jak to pochopit – a přemýšlet o různých konfiguracích – je podívat se na několik příkladů a pak si sami zaexperimentovat.
+
+Přiložená sada pro Figmu obsahuje prázdné, obrysové a vyplněné komponenty.
+
+Podívejte se na níže uvedené příklady, abyste viděli různé způsoby, jak to všechno můžete složit dohromady:
+
+
+
+
+
+
+
+
+
+
+
+
+
+## Ale na kterou stranu by měl token jít? {#but-which-side-should-the-token-go-on}
+
+Podstatné je, že to na použitelnost pravděpodobně nemá velký vliv. Existuje však několik věcí, které je třeba mít na paměti a které vás mohou přiklonit na jednu nebo druhou stranu.
+
+Je mírně zajímavé sledovat, jak se móda s časem mění. Uniswap měl původně token vlevo, ale od té doby ho přesunul doprava. Sushiswap také provedl tuto změnu během vylepšení designu. Většina, ale ne všechny protokoly následovaly.
+
+Finanční konvence tradičně umisťuje symbol měny před číslo, např. $50, €50, £50, ale my _říkáme_ 50 dolarů, 50 eur, 50 liber.
+
+Pro běžného uživatele – zejména pro toho, kdo čte zleva doprava, shora dolů – je token vpravo pravděpodobně přirozenější.
+
+
+
+Umístění tokenu vlevo a všech čísel vpravo vypadá příjemně symetricky, což je plus, ale toto uspořádání má i další nevýhodu.
+
+Zákon blízkosti říká, že prvky, které jsou blízko u sebe, jsou vnímány jako související. Proto chceme umisťovat související položky vedle sebe. Zůstatek tokenu přímo souvisí se samotným tokenem a změní se vždy, když je vybrán nový token. Proto dává o něco větší smysl, aby byl zůstatek tokenu vedle tlačítka pro výběr tokenu. Mohl by být přesunut pod token, ale to narušuje symetrii rozvržení.
+
+Nakonec mají obě možnosti svá plusy a mínusy, ale je zajímavé, jak se zdá, že trend směřuje k tokenu napravo.
+
+## Chování tlačítka {#button-behavior}
+
+Nemějte samostatné tlačítko pro Schválit. Také nemějte samostatné kliknutí pro Schválit. Uživatel chce směnit, takže na tlačítku stačí uvést „Směnit“ a jako první krok zahájit schválení. Modální okno může zobrazovat pokrok pomocí krokování nebo jednoduchého oznámení „transakce 1 ze 2 – schvalování“.
+
+
+
+
+
+### Tlačítko jako kontextová nápověda {#button-as-contextual-help}
+
+Tlačítko může sloužit dvojímu účelu jako upozornění!
+
+Je to vlastně poměrně neobvyklý designový vzor mimo Web3, ale v něm se stal standardem. Je to dobrá inovace, protože šetří místo a udržuje pozornost.
+
+Pokud je hlavní akce – SMĚNIT – nedostupná z důvodu chyby, důvod lze vysvětlit pomocí tlačítka, např.:
+
+- přepnout síť
+- připojit peněženku
+- různé chyby
+
+Tlačítko může být také **přiřazeno k akci**, která má být provedena. Například pokud uživatel nemůže provést směnu, protože je na špatné síti, na tlačítku by mělo být uvedeno „Přepnout na Ethereum“ a po kliknutí na tlačítko by se síť měla přepnout na Ethereum. To výrazně zrychluje postup uživatele.
+
+
+
+
+
+## Vytvořte si vlastní pomocí tohoto souboru Figma {#build-your-own-with-this-figma-file}
+
+Díky tvrdé práci několika protokolů se design DEX hodně zlepšil. Víme, jaké informace uživatel potřebuje, jak bychom je měli zobrazit a jak zajistit, aby byl postup co nejplynulejší.
+Doufejme, že tento článek poskytuje solidní přehled principů UX.
+
+Pokud chcete experimentovat, neváhejte použít sadu drátěných modelů pro Figma. Je co nejjednodušší, ale má dostatečnou flexibilitu k tomu, aby bylo možné základní strukturu sestavit různými způsoby.
+
+[Sada drátěných modelů pro Figma](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit)
+
+DeFi se bude i nadále vyvíjet a vždy je co zlepšovat.
+
+Hodně štěstí!
diff --git a/public/content/translations/cs/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/cs/developers/docs/design-and-ux/heuristics-for-web3/index.md
new file mode 100644
index 00000000000..1fbd91d1f49
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/design-and-ux/heuristics-for-web3/index.md
@@ -0,0 +1,138 @@
+---
+title: 7 heuristik pro návrh rozhraní Web3
+description: Principy pro zlepšení použitelnosti Web3
+lang: cs
+---
+
+Heuristiky použitelnosti jsou obecná „empirická pravidla“, která můžete použít k měření použitelnosti vašich stránek.
+Těchto 7 heuristik je speciálně přizpůsobeno pro Web3 a měly by se používat společně s [deseti obecnými principy pro návrh interakce](https://www.nngroup.com/articles/ten-usability-heuristics/) od Jakoba Nielsena.
+
+## Sedm heuristik použitelnosti pro Web3 {#seven-usability-heuristics-for-web3}
+
+1. Zpětná vazba následuje po akci
+2. Bezpečnost a důvěra
+3. Nejdůležitější informace jsou zřejmé
+4. Srozumitelná terminologie
+5. Akce jsou co nejkratší
+6. Síťová připojení jsou viditelná a flexibilní
+7. Ovládání z aplikace, nikoli z peněženky
+
+## Definice a příklady {#definitions-and-examples}
+
+### 1. Zpětná vazba následuje po akci {#feedback-follows-action}
+
+**Mělo by být zřejmé, kdy se něco stalo nebo se děje.**
+
+Uživatelé se rozhodují o svých dalších krocích na základě výsledku svých předchozích kroků. Proto je nezbytné, aby byli stále informováni o stavu systému. To je důležité zejména ve Web3, protože transakcím může někdy chvíli trvat, než se zapíší do blockchainu. Pokud není k dispozici žádná zpětná vazba, která by je informovala, aby počkali, uživatelé si nejsou jisti, zda se něco stalo.
+
+**Tipy:**
+
+- Informujte uživatele prostřednictvím zpráv, oznámení a dalších upozornění.
+- Srozumitelně sdělujte čekací doby.
+- Pokud bude akce trvat déle než několik sekund, uklidněte uživatele časovačem nebo animací, aby měli pocit, že se něco děje.
+- Pokud má proces více kroků, zobrazte každý krok.
+
+**Příklad:**
+Zobrazení každého kroku transakce pomáhá uživatelům vědět, kde se v procesu nacházejí. Vhodné ikony informují uživatele o stavu jejich akcí.
+
+
+
+### 2. Bezpečnost a důvěra jsou integrovány {#security-and-trust-are-backed-in}
+
+Bezpečnost by měla být prioritou a to by mělo být uživateli zdůrazněno.
+Lidem velmi záleží na jejich datech. Bezpečnost je pro uživatele často primárním zájmem, proto by se na ni mělo myslet na všech úrovních návrhu. Vždy byste se měli snažit získat důvěru svých uživatelů, ale způsob, jakým to děláte, se může u různých aplikací lišit. Nemělo by se na to myslet dodatečně, ale mělo by to být vědomě navrženo v celém rozsahu. Budujte důvěru v rámci celé uživatelské zkušenosti, včetně sociálních kanálů a dokumentace, a také konečného uživatelského rozhraní. Věci jako úroveň decentralizace, stav multi-sig pokladnice a to, zda je tým „doxxed“ (veřejně známý), to vše ovlivňuje důvěru uživatelů.
+
+**Tipy:**
+
+- Hrdě uvádějte své audity
+- Získejte několik auditů
+- Propagujte všechny bezpečnostní funkce, které jste navrhli
+- Zvýrazněte možná rizika, včetně souvisejících integrací
+- Sdělujte složitost strategií
+- Zvažte problémy mimo uživatelské rozhraní, které by mohly ovlivnit vnímání bezpečnosti vašimi uživateli
+
+**Příklad:**
+Uveďte své audity v zápatí na viditelném místě.
+
+
+
+### 3. Nejdůležitější informace jsou zřejmé {#the-most-important-info-is-obvious}
+
+U složitých systémů zobrazujte pouze nejrelevantnější data. Určete, co je nejdůležitější, a upřednostněte zobrazení těchto informací.
+Příliš mnoho informací je zahlcující a uživatelé se při rozhodování obvykle soustředí na jednu informaci. V DeFi to bude pravděpodobně RPSN u výnosových aplikací a LTV u aplikací pro půjčování.
+
+**Tipy:**
+
+- Uživatelský průzkum odhalí nejdůležitější metriku
+- Klíčové informace udělejte velké a ostatní detaily malé a nenápadné
+- Lidé nečtou, ale prolétávají text očima; zajistěte, aby byl váš design snadno přehledný
+
+**Příklad:** Velké, plně barevné tokeny lze při rychlém procházení snadno najít. RPSN je velká a zvýrazněná doplňkovou barvou.
+
+
+
+### 4. Jasná terminologie {#clear-terminology}
+
+Terminologie by měla být srozumitelná a vhodná.
+Technický žargon může být obrovskou překážkou, protože vyžaduje vytvoření zcela nového mentálního modelu. Uživatelé si nedokážou spojit design se slovy, frázemi a koncepty, které již znají. Všechno se zdá matoucí a neznámé a je zde strmá křivka učení, než se vůbec pokusí aplikaci použít. Uživatel může přijít k DeFi s tím, že si chce ušetřit nějaké peníze, a najde: těžbu, farming, stakování, emise, úplatky, trezory, skříňky, veTokeny, vesting, epochy, decentralizované algoritmy, likviditu vlastněnou protokolem…
+Snažte se používat jednoduché termíny, kterým porozumí co nejširší skupina lidí. Nevymýšlejte zcela nové termíny jen pro svůj projekt.
+
+**Tipy:**
+
+- Používejte jednoduchou a konzistentní terminologii
+- Co nejvíce používejte stávající jazyk
+- Nevymýšlejte si vlastní termíny
+- Dodržujte konvence tak, jak se objevují
+- Co nejvíce vzdělávejte uživatele
+
+**Příklad:**
+„Vaše odměny“ je široce srozumitelný, neutrální termín; nikoliv nové slovo vymyšlené pro tento projekt. Odměny jsou denominovány v USD, aby odpovídaly mentálním modelům reálného světa, i když samotné odměny jsou v jiném tokenu.
+
+
+
+### 5. Akce jsou co nejkratší {#actions-are-as-short-as-possible}
+
+Zrychlete interakce uživatele seskupením dílčích akcí.
+To lze provést na úrovni chytrého kontraktu i na úrovni uživatelského rozhraní. Uživatel by se neměl muset přesouvat z jedné části systému do druhé – nebo systém zcela opouštět – aby dokončil běžnou akci.
+
+**Tipy:**
+
+- Kombinujte „Schválit“ s jinými akcemi, kde je to možné
+- Seskupte kroky podepisování co nejblíže k sobě
+
+**Příklad:** Kombinace „přidat likviditu“ a „stakovat“ je jednoduchým příkladem urychlovače, který uživateli šetří čas i palivo.
+
+
+
+### 6. Síťová připojení jsou viditelná a flexibilní {#network-connections-are-visible-and-flexible}
+
+Informujte uživatele o tom, ke které síti je připojen, a poskytněte jasné zkratky pro změnu sítě.
+To je důležité zejména u multichain aplikací. Hlavní funkce aplikace by měly být stále viditelné, i když je odpojena nebo připojena k nepodporované síti.
+
+**Tipy:**
+
+- Při odpojení zobrazte co nejvíce z aplikace
+- Zobrazte, ke které síti je uživatel aktuálně připojen
+- Nenuťte uživatele chodit do peněženky, aby změnil síť
+- Pokud aplikace vyžaduje, aby uživatel přepnul síť, vyzvěte k akci z hlavní výzvy k akci
+- Pokud aplikace obsahuje trhy nebo trezory pro více sítí, jasně uveďte, kterou sadu si uživatel právě prohlíží
+
+**Příklad:** Ukažte uživateli, ke které síti je připojen, a umožněte mu ji změnit v panelu aplikace.
+
+
+
+### 7. Ovládání z aplikace, nikoli z peněženky {#control-from-the-app-not-the-wallet}
+
+Uživatelské rozhraní by mělo uživateli sdělit vše, co potřebuje vědět, a dát mu kontrolu nad vším, co potřebuje udělat.
+Ve Web3 existují akce, které provádíte v uživatelském rozhraní, a akce, které provádíte v peněžence. Obecně platí, že akci zahájíte v uživatelském rozhraní a poté ji potvrdíte v peněžence. Uživatelé se mohou cítit nepříjemně, pokud tyto dvě části nejsou pečlivě integrovány.
+
+**Tipy:**
+
+- Informujte o stavu systému prostřednictvím zpětné vazby v uživatelském rozhraní
+- Veďte záznamy o jejich historii
+- Poskytněte odkazy na prohlížeče bloků pro staré transakce
+- Poskytněte zkratky pro změnu sítí.
+
+**Příklad:** Nenápadný kontejner ukazuje uživateli, jaké relevantní tokeny má ve své peněžence, a hlavní výzva k akci poskytuje zkratku ke změně sítě.
+
+
diff --git a/public/content/translations/cs/developers/docs/design-and-ux/index.md b/public/content/translations/cs/developers/docs/design-and-ux/index.md
new file mode 100644
index 00000000000..977a329af24
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/design-and-ux/index.md
@@ -0,0 +1,86 @@
+---
+title: Design a UX ve web3
+description: Úvod do UX designu a výzkumu ve web3 prostoru a v ekosystému Etherea
+lang: cs
+---
+
+Jste v navrhování pro Ethereum nováčci? Pak jste na správném místě. Komunita Etherea vytvořila zdroje, které vás seznámí se základy designu a výzkumu v prostředí web3. Dozvíte se zde se o klíčových konceptech, které se mohou lišit od jiných návrhů aplikací, se kterými jste se už setkali.
+
+Zatím nejste obeznámeni se základy web3? Podívejte se na [**Centrum vzdělávání**](/learn/).
+
+## Začněte s uživatelským výzkumem {#start-with-user-research}
+
+Efektivní design jde nad rámec tvorby vizuálně atraktivních uživatelských rozhraní. Zahrnuje hluboké pochopení potřeb, cílů a motivačních faktorů uživatelů. Proto všem návrhářům důrazně doporučujeme, aby si osvojili proces návrhu, jako je [**proces dvojitého diamantu**](https://en.wikipedia.org/wiki/Double_Diamond_\(design_process_model\)), aby bylo zajištěno, že jejich práce bude promyšlená a cílevědomá.
+
+- [Web3 potřebuje více UX výzkumníků a designérů](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) – Přehled současné vyspělosti designu
+- [Jednoduchý průvodce UX výzkumem ve webu3](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) – Jednoduchý průvodce, jak provádět výzkum
+- [Jak přistupovat k rozhodnutím ohledně UX ve webu3](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) – Stručný přehled kvantitativního a kvalitativního výzkumu a rozdílů mezi nimi (video, 6 min)
+- [Být UX výzkumníkem ve webu3](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) – Osobní pohled na to, jaké to je být UX výzkumníkem ve webu3
+
+## Výzkumné studie ve webu3 {#research-in-web3}
+
+Níže najdete kurátorský seznam uživatelských výzkumů, které byly ve web3 realizovány v minulosti: Může vám pomoci s designovými a produktovými rozhodnutími nebo posloužit jako inspirace k provedení vlastního výzkumu.
+
+| Oblast zájmu | Název |
+| :------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Krypto onboarding | [The Reown Pulse 2024: Nálada a používání kryptoměn spotřebiteli](https://reown.com/blog/unveiling-walletconnects-consumer-crypto-report) |
+| Krypto onboarding | [CRADL: UX v kryptoměnách](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) |
+| Krypto onboarding | [CRADL: On-boarding do světa kryptoměn](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) |
+| Krypto onboarding | [Zpráva o UX Bitcoinu](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) |
+| Krypto onboarding | [Consensys: Stav vnímání webu3 ve světě v roce 2023](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) |
+| Krypto onboarding | [NEAR: Urychlení cesty k přijetí](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) |
+| Staking | [OpenUX: UX operátora uzlu Rocket Pool](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) |
+| Staking | [Staking: Klíčové trendy, poznatky a předpovědi – Eth Staker](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) |
+| Staking | [Víceaplikační staking](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20\(MAS\)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) |
+| DAO | [Aktualizace výzkumu DAO za rok 2022: Co potřebují tvůrci DAO?](https://blog.aragon.org/2022-dao-research-update/) |
+| DeFi | [Pooly krytí](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) |
+| DeFi | [Consensys: Zpráva o uživatelském výzkumu DeFi 2022](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) |
+| Metaverzum | [Metaverzum: Zpráva o uživatelském výzkumu](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) |
+| Metaverzum | [Jako na safari: Výzkum uživatelů v metaverzu](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (video, 27 min) |
+
+## Design pro web3 {#design-for-web3}
+
+- [Web3 UX Design Handbook](https://web3ux.design/) – Praktický průvodce návrhem aplikací pro web3
+- [Principy designu pro web3](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) – Rámec pravidel UX pro dapps založené na blockchainu
+- [Principy designu pro blockchain](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) – Zkušenosti designérského týmu pro blockchain v IBM
+- [Neueux.com](https://neueux.com/apps) – Knihovna uživatelského rozhraní s uživatelskými toky s různými možnostmi filtrování
+- [Web3's Usability Crisis: What You NEED to Know!](https://www.youtube.com/watch?v=oBSXT_6YDzg) – Panelová diskuze o úskalích tvorby projektů zaměřených na vývojáře (video, 34 min)
+
+## Začínáme {#getting-started}
+
+- [Heuristiky pro web3](/developers/docs/design-and-ux/heuristics-for-web3/) – 7 heuristik pro návrh rozhraní webu3
+- [Osvědčené postupy pro design DEX](/developers/docs/design-and-ux/dex-design-best-practice/) – Průvodce navrhováním decentralizovaných burz
+
+## Případové studie designu pro web3 {#design-case-studies}
+
+- [Deep Work Studio](https://www.deepwork.studio/case-studies)
+- [Prodej NFT na OpenSea](https://builtformars.com/case-studies/opensea)
+- [Analýza UX peněženek a jak se musí změnit](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (video, 20 min)
+
+## Odměny za design {#bounties}
+
+- [Dework](https://app.dework.xyz/bounties)
+- [Buildbox hackathons](https://app.buidlbox.io/)
+- [ETHGlobal hackathons](https://ethglobal.com/)
+
+## Designérské DAO a komunity {#design-daos-and-communities}
+
+Zapojte se do profesionálních komunitně řízených organizací nebo se připojte ke skupinám designérů a diskutujte o designu, výzkumu a souvisejících tématech a trendech s ostatními členy.
+
+- [Vectordao.com](https://vectordao.com/)
+- [Deepwork.studio](https://www.deepwork.studio/)
+- [We3.co](https://we3.co/)
+- [Openux.xyz](https://openux.xyz/)
+
+## Design systémy a další designérské zdroje {#design-systems-and-resources}
+
+- [Optimism Design](https://www.figma.com/@optimism) (Figma)
+- [Design systém Ethereum.org](https://www.figma.com/@ethdotorg) (Figma)
+- [Finity, design systém od Polygonu](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma)
+- [Design systém Kleros](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma)
+- [Design systém Safe](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma)
+- [Design systém ENS](https://thorin.ens.domains/)
+- [Design systém Mirror](https://degen-xyz.vercel.app/)
+
+**Články a projekty uvedené na této stránce nejsou oficiálními doporučeními a jsou zde uvedeny pouze pro informační účely.**
+Odkazy na tuto stránku přidáváme na základě kritérií v našich [zásadách pro zařazování do seznamu](/contributing/design/adding-design-resources). Pokud chcete, abychom přidali projekt/článek, upravte tuto stránku na [GitHubu](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md).
diff --git a/public/content/translations/cs/developers/docs/development-networks/index.md b/public/content/translations/cs/developers/docs/development-networks/index.md
new file mode 100644
index 00000000000..6e437efb921
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/development-networks/index.md
@@ -0,0 +1,71 @@
+---
+title: Vývojové sítě
+description: Přehled vývojových sítí a dostupných nástrojů, nápomocných při vytváření aplikací pro Ethereum.
+lang: cs
+---
+
+Když vytváříte aplikaci pro Ethereum se smart kontrakty, budete ji chtít před nasazením spustit nejdříve v místní síti, abyste zjistili, jak funguje.
+
+Podobně jako můžete na svém počítači spustit lokální server pro vývoj webu, můžete pomocí vývojové sítě vytvořit lokální instanci blockchainu a otestovat svou dapp. Tyto vývojové sítě Etherea poskytují funkce, které umožňují mnohem rychlejší iteraci než veřejná testovací síť (například nemusíte řešit získávání ETH).
+
+## Předpoklady {#prerequisites}
+
+Měli byste rozumět [základům Ethereum stacku](/developers/docs/ethereum-stack/) a [ethereových sítí](/developers/docs/networks/), než se pustíte do vývojových sítí.
+
+## Co je to vývojová síť? {#what-is-a-development-network}
+
+Vývojové sítě jsou v zásadě klienti Etherea (implementace Etherea) navrženi speciálně pro lokální vývoj.
+
+**Proč jen lokálně nespustit standardní uzel Etherea?**
+
+_Můžete_ [spustit uzel](/developers/docs/nodes-and-clients/#running-your-own-node), ale protože vývojové sítě jsou účelově vytvořeny pro vývoj, často obsahují praktické funkce, jako jsou:
+
+- Deterministické naplnění vašeho lokálního blockchainu daty (např. účty se zůstatky ETH)
+- Okamžitá produkce bloků s každou přijatou transakcí, a to popořadě a bez zpoždění
+- Vylepšená funkce debugování a protokolování
+
+## Dostupné nástroje {#available-projects}
+
+**Poznámka**: Většina [vývojových frameworků](/developers/docs/frameworks/) obsahuje vestavěnou vývojovou síť. Doporučujeme začít s frameworkem pro [nastavení vašeho lokálního vývojového prostředí](/developers/local-environment/).
+
+### Hardhat Network {#hardhat-network}
+
+Lokální síť Etherea určená pro vývoj. Umožňuje nasazovat kontrakty, spouštět testy a ladit kód.
+
+Síť Hardhat Network je integrovaná s Hardhatem, vývojovým prostředím Etherea pro profesionály.
+
+- [Webové stránky](https://hardhat.org/)
+- [GitHub](https://github.com/NomicFoundation/hardhat)
+
+### Lokální řetězové vazby {#local-beacon-chains}
+
+Někteří konsensuální klienti mají vestavěné nástroje pro spuštění lokálních řetězových vazeb pro účely testování. Jsou k dispozici pokyny pro Lighthouse, Nimbus a Lodestar:
+
+- [Lokální testovací síť s použitím Lodestar](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/)
+- [Lokální testovací síť s použitím Lighthouse](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets)
+
+### Veřejné testovací řetězce Etherea {#public-beacon-testchains}
+
+Existují také dvě udržované veřejné testovací implementace Etherea: Sepolia a Hoodi. Doporučenou testovací sítí s dlouhodobou podporou je Hoodi, na které může kdokoli volně validovat. Sepolia používá sadu validátorů s oprávněním, což znamená, že na této testovací síti není obecný přístup k novým validátorům.
+
+- [Hoodi Staking Launchpad](https://hoodi.launchpad.ethereum.org/)
+
+### Kurtosis Ethereum Package {#kurtosis}
+
+Kurtosis je systém pro sestavování testovacích prostředí s více kontejnery, který vývojářům umožňuje lokálně spouštět reprodukovatelné instance blockchainových sítí.
+
+Balíček Ethereum Kurtosis lze použít k rychlému vytvoření parametrizovatelné, vysoce škálovatelné a soukromé testovací sítě Ethereum přes Docker nebo Kubernetes. Balíček podporuje všechny hlavní klienty exekuční vrstvy (EL) a vrstvy konsensu (CL). Kurtosis elegantně zpracovává všechna lokální mapování portů a servisní připojení pro reprezentativní síť, která se má používat v pracovních postupech validace a testování týkajících se základní infrastruktury Etherea.
+
+- [Ethereum network package](https://github.com/kurtosis-tech/ethereum-package)
+- [Webové stránky](https://www.kurtosis.com/)
+- [GitHub](https://github.com/kurtosis-tech/kurtosis)
+- [Dokumentace](https://docs.kurtosis.com/)
+
+## Další čtení {#further-reading}
+
+_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_
+
+## Související témata {#related-topics}
+
+- [Vývojářské frameworky](/developers/docs/frameworks/)
+- [Nastavení lokálního vývojového prostředí](/developers/local-environment/)
diff --git a/public/content/translations/cs/developers/docs/ethereum-stack/index.md b/public/content/translations/cs/developers/docs/ethereum-stack/index.md
new file mode 100644
index 00000000000..d17de489be9
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/ethereum-stack/index.md
@@ -0,0 +1,61 @@
+---
+title: Úvod do stacku Etherea
+description: Průvodce různými vrstvami Ethereum zásobníku a tím, jak do sebe zapadají.
+lang: cs
+---
+
+Stejně jako každý softwarový zásobník se i kompletní „Ethereum zásobník“ bude lišit projekt od projektu v závislosti na vašich cílech.
+
+Existují však základní komponenty Etherea, které pomáhají vytvořit mentální model interakce softwarových aplikací s ethereovým blockchainem. Pochopení vrstev zásobníku vám pomůže porozumět různým způsobům, jak lze Ethereum integrovat do softwarových projektů.
+
+## Úroveň 1: Ethereum Virtual Machine {#ethereum-virtual-machine}
+
+[Virtuální stroj Etherea (EVM)](/developers/docs/evm/) je běhové prostředí pro chytré kontrakty na Ethereu. Všechny chytré kontrakty a změny stavu na blockchainu Etherea jsou prováděny [transakcemi](/developers/docs/transactions/). EVM zajišťuje veškeré zpracování transakcí v síti Ethereum.
+
+Stejně jako u každého virtuálního stroje vytváří EVM úroveň abstrakce mezi prováděným kódem a vykonávajícím strojem (uzlem Etherea). V současné době běží EVM na tisících uzlů rozmístěných po celém světě.
+
+Pod kapotou používá EVM sadu instrukcí opkódu k provádění konkrétních úloh. Těchto (140 unikátních) opkódů umožňuje, aby byl EVM [Turingovsky kompletní](https://en.wikipedia.org/wiki/Turing_completeness), což znamená, že pokud má dostatek zdrojů, je schopen vypočítat téměř cokoli.
+
+Jako vývojář dapps nemusíte o EVM vědět o moc víc než to, že existuje a spolehlivě a bez výpadků pohání všechny aplikace na Ethereu.
+
+## Úroveň 2: Chytré kontrakty {#smart-contracts}
+
+[Chytré kontrakty](/developers/docs/smart-contracts/) jsou spustitelné programy, které běží na ethereovém blockchainu.
+
+Chytré kontrakty se píší pomocí specifických [programovacích jazyků](/developers/docs/smart-contracts/languages/), které se kompilují do bajtkódu EVM (nízkoúrovňové strojové instrukce nazývané opkódy).
+
+Chytré kontrakty neslouží jen jako open source knihovny, ale jsou to v podstatě otevřené služby API, které jsou neustále v provozu a nelze je vypnout. Chytré kontrakty poskytují veřejné funkce, se kterými mohou uživatelé a aplikace ([dapps](/developers/docs/dapps/)) interagovat bez nutnosti povolení. Jakákoli aplikace se může integrovat s nasazenými chytrými kontrakty a skládat tak funkcionalitu, jako je přidávání [datových kanálů](/developers/docs/oracles/) nebo podpora směny tokenů. Kdokoli může navíc na Ethereum nasadit nové chytré kontrakty a přidat tak vlastní funkcionalitu, která bude vyhovovat potřebám jeho aplikace.
+
+Jako vývojář dec. aplikací budete muset psát smart kontrakty pouze v případě, že budete chtít přidat vlastní funkcionalitu do blockchainu Etherea. Možná zjistíte, že většiny nebo všech potřeb vašeho projektu dosáhnete pouhou integrací s již existujícími smart kontrakty, například pokud chcete podporovat platby ve stablecoinech nebo umožnit decentralizovanou výměnu tokenů.
+
+## Úroveň 3: Ethereové uzly {#ethereum-nodes}
+
+Aby mohla aplikace interagovat s ethereovým blockchainem, musí se připojit k [ethereovému uzlu](/developers/docs/nodes-and-clients/). Připojení k uzlu vám umožní číst data z blockchainu a/nebo posílat transakce do sítě.
+
+Ethereum uzly jsou počítače se spuštěným softwarem - Ethereum klientem. Klient je implementace Etherea, která ověřuje všechny transakce v každém bloku, čímž zajišťuje bezpečnost sítě a přesnost dat. **Ethereové uzly JSOU ethereový blockchain**. Společně uchovávají stav blockchainu Etherea a dosahují konsensu o transakcích, které mají za cíl měnit stav blockchainu.
+
+Připojením vaší aplikace k ethereovému uzlu (prostřednictvím [JSON-RPC API](/developers/docs/apis/json-rpc/)) je vaše aplikace schopna číst data z blockchainu (například zůstatky na uživatelských účtech) a také vysílat do sítě nové transakce (například převod ETH mezi uživatelskými účty nebo provádění funkcí chytrých kontraktů).
+
+## Úroveň 4: Klientská API pro Ethereum {#ethereum-client-apis}
+
+Mnoho pomocných knihoven (vytvořených a spravovaných open source komunitou Etherea) umožňuje vašim aplikacím připojit se k ethereovému blockchainu a komunikovat s ním.
+
+Pokud je vaše uživatelská aplikace webová, můžete si zvolit `npm install` [JavaScript API](/developers/docs/apis/javascript/) přímo do frontendu. Nebo se možná rozhodnete implementovat tuto funkcionalitu na straně serveru pomocí API pro [Python](/developers/docs/programming-languages/python/) nebo [Javu](/developers/docs/programming-languages/java/).
+
+I když tato API nejsou nezbytnou součástí zásobníku, abstrahují od velké části složitosti přímé interakce s ethereovým uzlem. Poskytují také pomocné funkce (např. převod ETH na Gwei), takže jako vývojář můžete strávit méně času řešením složitostí klientů Etherea a více času se soustředit na funkcionalitu specifickou pro vaši aplikaci.
+
+## Úroveň 5: Aplikace pro koncové uživatele {#end-user-applications}
+
+Na nejvyšší úrovni zásobníku jsou aplikace určené pro uživatele. Jedná se o standardní aplikace, které dnes běžně vytváříte a používáte: především webové a mobilní aplikace.
+
+Způsob vývoje těchto uživatelských rozhraní se v podstatě nemění. Uživatelé často nebudou potřebovat vědět, že aplikace, kterou používají, je vytvořena pomocí blockchainu.
+
+## Jste připraveni vybrat si svůj zásobník? {#ready-to-choose-your-stack}
+
+Podívejte se na našeho průvodce [nastavením místního vývojového prostředí](/developers/local-environment/) pro vaši ethereovou aplikaci.
+
+## Další čtení {#further-reading}
+
+- [Architektura aplikace Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) – _Preethi Kasireddy_
+
+_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_
diff --git a/public/content/translations/cs/developers/docs/evm/index.md b/public/content/translations/cs/developers/docs/evm/index.md
index 8e2502a19bd..2f3bb1d61ad 100644
--- a/public/content/translations/cs/developers/docs/evm/index.md
+++ b/public/content/translations/cs/developers/docs/evm/index.md
@@ -4,74 +4,84 @@ description: Úvod do virtuálního stroje Etherea a jeho vztah ke stavu, transa
lang: cs
---
-Virtuální stroj Etherea (EVM) je decentralizované virtuální prostředí, které konzistentně a bezpečně vykonává kód na všech uzlech Etherea. Uzly spouštějí EVM, aby vykonávaly chytré kontrakty, přičemž používají jednotky „[paliva](/developers/docs/gas/)“ k měření výpočetního úsilí potřebného pro tyto [operace](/developers/docs/evm/opcodes/), což zajišťuje efektivní alokaci zdrojů a bezpečnost sítě.
+Virtuální stroj Etherea (EVM) je decentralizované virtuální prostředí, které konzistentně a bezpečně vykonává kód na všech uzlech Etherea. Uzly spouštějí EVM k provádění chytrých kontraktů a používají "[palivo](/developers/docs/gas/)" k měření výpočetní náročnosti [operací](/developers/docs/evm/opcodes/), čímž zajišťují efektivní alokaci zdrojů a bezpečnost sítě.
## Předpoklady {#prerequisites}
-Pro pochopení EVM je nutné mít základní povědomí o běžné terminologii v informatice, jako jsou [bajty](https://wikipedia.org/wiki/Byte), [paměť](https://wikipedia.org/wiki/Computer_memory) a [zásobník](https://wikipedia.org/wiki/Stack_(abstract_data_type)). Také se hodí mít znalosti z oblasti kryptografie a blockchainu, např. o [hashovacích funkcích](https://wikipedia.org/wiki/Cryptographic_hash_function) a [Merkle tree](https://wikipedia.org/wiki/Merkle_tree).
+Pro pochopení EVM je nutné mít základní znalosti běžné terminologie v informatice, jako jsou [bajty](https://wikipedia.org/wiki/Byte), [paměť](https://wikipedia.org/wiki/Computer_memory) a [zásobník](https://wikipedia.org/wiki/Stack_\(abstract_data_type\)). Také by bylo užitečné se seznámit s kryptografickými/blockchainovými koncepty, jako jsou [hašovací funkce](https://wikipedia.org/wiki/Cryptographic_hash_function) a [Merkleho strom](https://wikipedia.org/wiki/Merkle_tree).
## Od účetní knihy ke stavovému stroji {#from-ledger-to-state-machine}
Přirovnání k „distribuované účetní knize“ se často používá k popisu blockchainů, jako je Bitcoin, které mají decentralizovanou měnu s využitím základních nástrojů kryptografie. Účetní kniha udržuje záznam aktivit za současného dodržování souboru pravidel, která určují, co může a nemůže uživatel dělat při úpravě této knihy. Např. bitcoinová adresa nemůže utratit více Bitcoinů, než kolik jich předtím obdržela. Tato pravidla jsou základem všech transakcí na Bitcoinu a mnoha dalších blockchainech.
-Ethereum sice má vlastní nativní kryptoměnu (ether), která se řídí téměř stejnými intuitivními pravidly, ale zároveň umožňuje mnohem výkonnější funkce: [chytré kontrakty](/developers/docs/smart-contracts/). Pro tuto složitější funkci potřebujeme sofistikovanější přirovnání. Namísto distribuované účetní knihy je Ethereum distribuovaný [stavový stroj](https://wikipedia.org/wiki/Finite-state_machine). Stav Etherea je velká datová struktura, která obsahuje nejen všechny účty a zůstatky, ale také _stav stroje_, který se může měnit od bloku k bloku podle předem definovaného souboru pravidel a který může vykonávat libovolný strojový kód. Specifická pravidla pro změnu stavu od bloku k bloku jsou definována v EVM.
+Ethereum sice má svou vlastní nativní kryptoměnu (ether), která se řídí téměř úplně stejnými intuitivními pravidly, ale zároveň umožňuje mnohem výkonnější funkci: [chytré kontrakty](/developers/docs/smart-contracts/). Pro tuto složitější funkci potřebujeme sofistikovanější přirovnání. Místo distribuované účetní knihy je Ethereum distribuovaný [stavový stroj](https://wikipedia.org/wiki/Finite-state_machine). Stav Etherea je velká datová struktura, která obsahuje nejen všechny účty a zůstatky, ale také _stav stroje_, který se může měnit z bloku na blok podle předem definované sady pravidel a který může vykonávat libovolný strojový kód. Specifická pravidla pro změnu stavu od bloku k bloku jsou definována v EVM.
- _Schéma převzato z [ilustrace Ethereum EVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_Diagram převzatý z [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-## Funkce změny stavu na Ethereu {#the-ethereum-state-transition-function}
+## Funkce přechodu stavu Etherea {#the-ethereum-state-transition-function}
-EVM se chová jako matematická funkce: Na základě vstupu produkuje deterministický výstup. Je tedy užitečné formálněji popsat Ethereum jako systém s **funkcí změny stavu**:
+EVM se chová jako matematická funkce: Na základě vstupu produkuje deterministický výstup. Je proto velmi užitečné formálněji popsat Ethereum tak, že má **funkci přechodu stavu**:
```
Y(S, T)= S'
```
-Na základě starého platného stavu `(S)` a nové sady platných transakcí `(T)` funkce změny stavu Etherea `Y(S, T)` vytvoří nový platný výstupní stav `S'`.
+Je-li dán starý platný stav `(S)` a nová sada platných transakcí `(T)`, funkce přechodu stavu Etherea `Y(S, T)` vytvoří nový platný výstupní stav `S'`
### Stav {#state}
-V kontextu Etherea je stav obrovská datová struktura nazývaná [modifikovaný Merkle Patricia Trie](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/), která udržuje všechny [účty](/developers/docs/accounts/) propojené pomocí hashů a redukovatelné na jediný kořenový hash uložený na blockchainu.
+V kontextu Etherea je stav obrovská datová struktura zvaná [modifikovaný Merkle Patricia Trie](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/), která uchovává všechny [účty](/developers/docs/accounts/) propojené haši a redukovatelné na jeden kořenový haš uložený na blockchainu.
### Transakce {#transactions}
Transakce jsou kryptograficky podepsané instrukce poslané z účtů. Existují dva typy transakcí: Ty, jejich výsledkem je volání zpráv (message calls), a ty, které vedou k vytvoření kontraktu.
-Vytvoření kontraktu vede k vytvoření nového kontraktového účtu, který obsahuje zkompilovaný bytecode [chytrého kontraktu](/developers/docs/smart-contracts/anatomy/). Kdykoli jiný účet vyšle zprávu na tento kontrakt, vykoná se jeho bytecode.
+Vytvoření kontraktu vede k vytvoření nového účtu kontraktu, který obsahuje zkompilovaný bytecode [chytrého kontraktu](/developers/docs/smart-contracts/anatomy/). Kdykoli jiný účet vyšle zprávu na tento kontrakt, vykoná se jeho bytecode.
## Instrukce EVM {#evm-instructions}
-EVM funguje jako [zásobníkový stroj](https://wikipedia.org/wiki/Stack_machine) s hloubkou 1 024 položek. Každá položka je 256bitové slovo, které bylo zvoleno pro snadné použití s 256bitovou kryptografií (např. hashe Keccak-256 nebo podpisy secp256k1).
+EVM se spouští jako [zásobníkový stroj](https://wikipedia.org/wiki/Stack_machine) s hloubkou 1024 položek. Každá položka je 256bitové slovo, které bylo zvoleno pro snadné použití s 256bitovou kryptografií (např. hashe Keccak-256 nebo podpisy secp256k1).
-Během vykonávání EVM udržuje přechodnou _paměť_ (jako bajtové pole adresované slovy), která nepřetrvává mezi transakcemi.
+Během provádění udržuje EVM přechodnou _paměť_ (jako bajtové pole adresované slovem), která se mezi transakcemi neuchovává.
-Kontrakty však obsahují trie _úložiště_ Merkle Patricia (jako pole adresovatelné slovy), které je spojeno s příslušným účtem a je součástí globálního stavu.
+### Přechodné úložiště
-Zkompilovaný bytecode chytrého kontraktu se vykonává jako řada [opkódů](/developers/docs/evm/opcodes) EVM, které provádějí standardní zásobníkové operace jako `XOR`, `AND`, `ADD`, `SUB` atd. EVM také implementuje několik blockchainově specifických zásobníkových operací, jako je `ADDRESS`, `BALANCE`, `BLOCKHASH` atd.
+Přechodné úložiště je úložiště klíč–hodnota pro jednotlivé transakce, ke kterému se přistupuje pomocí opkódů `TSTORE` a `TLOAD`. Zůstává zachováno napříč všemi interními voláními během jedné transakce, ale na konci transakce se vymaže. Na rozdíl od paměti je přechodné úložiště modelováno jako součást stavu EVM, nikoli jako součást exekučního rámce, ale není zapsáno do globálního stavu. Přechodné úložiště umožňuje úsporné dočasné sdílení stavu mezi interními voláními během transakce.
- _Diagram převzat z [ilustrovaného Ethereum EVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+### Úložiště
+
+Kontrakty obsahují Merkle Patricia _úložiště_ trie (jako pole slov adresovatelné slovy), které je spojeno s příslušným účtem a je součástí globálního stavu. Toto trvalé úložiště se liší od přechodného úložiště, které je k dispozici pouze po dobu trvání jedné transakce a netvoří součást trvalého úložiště trie účtu.
+
+### Opkódy
+
+Zkompilovaný bytecode chytrého kontraktu se provádí jako řada [opkódů](/developers/docs/evm/opcodes) EVM, které provádějí standardní zásobníkové operace jako `XOR`, `AND`, `ADD`, `SUB` atd. EVM také implementuje řadu blockchainově specifických operací se zásobníkem, jako jsou `ADDRESS`, `BALANCE`, `BLOCKHASH` atd. Sada opkódů zahrnuje také `TSTORE` a `TLOAD`, které poskytují přístup k přechodnému úložišti.
+
+
+_Diagramy převzaty z [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
## Implementace EVM {#evm-implementations}
Všechny implementace EVM musí dodržovat specifikaci popsanou v Ethereum Yellowpaperu.
-Během devítileté historie Etherea prošlo EVM několika revizemi a existuje několik implementací EVM v různých programovacích jazycích.
+Během desetileté historie Etherea prošel EVM několika revizemi a existuje několik implementací EVM v různých programovacích jazycích.
-[Exekuční klienty Etherea](/developers/docs/nodes-and-clients/#execution-clients) obsahují implementaci EVM. Navíc existuje několik samostatných implementací, včetně:
+[Exekuční klienti Etherea](/developers/docs/nodes-and-clients/#execution-clients) zahrnují implementaci EVM. Navíc existuje několik samostatných implementací, včetně:
-- [Py-EVM](https://github.com/ethereum/py-evm) – _Python_
-- [evmone](https://github.com/ethereum/evmone) – _C++_
-- [ethereumjs-vm](https://github.com/ethereumjs/ethereumjs-vm) – _JavaScript_
-- [revm](https://github.com/bluealloy/revm) – _Rust_
+- [Py-EVM](https://github.com/ethereum/py-evm) - _Python_
+- [evmone](https://github.com/ethereum/evmone) - _C++_
+- [ethereumjs-vm](https://github.com/ethereumjs/ethereumjs-vm) - _JavaScript_
+- [revm](https://github.com/bluealloy/revm) - _Rust_
-## Další informace {#further-reading}
+## Další čtení {#further-reading}
- [Ethereum Yellowpaper](https://ethereum.github.io/yellowpaper/paper.pdf)
- [Jellopaper alias KEVM: Sémantika EVM v K](https://jellopaper.org/)
- [The Beigepaper](https://github.com/chronaeon/beigepaper)
-- [Opkódy Virtuálního stroje Etherea](https://www.ethervm.io/)
-- [Interaktivní reference pro opkódy Virtuálního stroje Etherea](https://www.evm.codes/)
+- [Opkódy Ethereum Virtual Machine](https://www.ethervm.io/)
+- [Interaktivní reference pro opkódy Ethereum Virtual Machine](https://www.evm.codes/)
- [Krátký úvod v dokumentaci Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6)
-- [Kniha Mastering Ethereum – Virtuální stroj Etherea](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc)
+- [Mastering Ethereum - The Ethereum Virtual Machine](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc)
## Související témata {#related-topics}
diff --git a/public/content/translations/cs/developers/docs/evm/opcodes/index.md b/public/content/translations/cs/developers/docs/evm/opcodes/index.md
index 50f17e9f2eb..7ce441bdd37 100644
--- a/public/content/translations/cs/developers/docs/evm/opcodes/index.md
+++ b/public/content/translations/cs/developers/docs/evm/opcodes/index.md
@@ -6,169 +6,172 @@ lang: cs
## Přehled {#overview}
-Toto je aktualizovaná verze referenční stránky EVM na [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes). Rovněž čerpá z [Yellow Paperu](https://ethereum.github.io/yellowpaper/paper.pdf), [Jello Paperu](https://jellopaper.org/evm/) a implementace v [Geth](https://github.com/ethereum/go-ethereum). Tento dokument má být přístupnou referencí, ale není nijak zvlášť důkladný. Pokud si chcete být jisti správností a být si vědomi všech hraničních případů, doporučujeme vám používat Jello Paper nebo implementaci klienta.
+Toto je aktualizovaná verze referenční stránky EVM na [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes).
+Čerpáno také z [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf), [Jello Paper](https://jellopaper.org/evm/) a implementace [geth](https://github.com/ethereum/go-ethereum).
+Tento dokument má být přístupnou referencí, ale není nijak zvlášť důkladný.
+Pokud si chcete být jisti správností a být si vědomi všech hraničních případů, doporučujeme vám používat Jello Paper nebo implementaci klienta.
-Hledáte interaktivní referenci? Zkuste [evm.codes.](https://www.evm.codes/).
+Hledáte interaktivní referenci? Podívejte se na [evm.codes](https://www.evm.codes/).
-Pro operace s dynamickými poplatky se podívejte na [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md).
+Pro operace s dynamickými náklady na plyn viz [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md).
-💡Rychlý tip: Chcete-li zobrazit celé řádky, použijte `[shift] + scroll` pro horizontální posun na ploše.
+💡 Rychlý tip: Chcete-li zobrazit celé řádky, použijte `[shift] + scroll` pro horizontální posouvání na počítači.
-| Zásobník | Název | Palivo | Počáteční zásobník | Výsledný zásobník | Paměť/úložiště | Poznámky |
-|:--------:|:-------------- |:-----------------------------------------------------------------------------------------------:|:------------------------------------------------ |:-------------------------------------------- |:----------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 00 | STOP | 0 | | | | halt execution |
-| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 addition modulo 2\*\*256 |
-| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 multiplication modulo 2\*\*256 |
-| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 addition modulo 2\*\*256 |
-| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 division |
-| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 division |
-| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 modulus |
-| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 modulus |
-| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 addition modulo N |
-| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 multiplication modulo N |
-| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 exponentiation modulo 2\*\*256 |
-| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [sign extend](https://wikipedia.org/wiki/Sign_extension) `x` from `(b+1)` bytes to 32 bytes |
-| 0C-0F | _invalid_ | | | | | |
-| 10 | LT | 3 | `a, b` | `a < b` | | uint256 less-than |
-| 11 | GT | 3 | `a, b` | `a > b` | | uint256 greater-than |
-| 12 | SLT | 3 | `a, b` | `a < b` | | int256 less-than |
-| 13 | SGT | 3 | `a, b` | `a > b` | | int256 greater-than |
-| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 equality |
-| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 iszero |
-| 16 | AND | 3 | `a, b` | `a && b` | | bitwise AND |
-| 17 | OR | 3 | `a, b` | `a \|\| b` | | bitwise OR |
-| 18 | XOR | 3 | `a, b` | `a ^ b` | | bitwise XOR |
-| 19 | NOT | 3 | `a` | `~a` | | bitwise NOT |
-| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`th byte of (u)int256 `x`, from the left |
-| 1B | SHL | 3 | `shift, val` | `val << shift` | | shift left |
-| 1C | SHR | 3 | `shift, val` | `val >> shift` | | logical shift right |
-| 1D | SAR | 3 | `shift, val` | `val >> shift` | | arithmetic shift right |
-| 1E-1F | _invalid_ | | | | | |
-| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 |
-| 21-2F | _invalid_ | | | | | |
-| 30 | ADDRESS | 2 | `.` | `address(this)` | | address of executing contract |
-| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | balance, in wei |
-| 32 | ORIGIN | 2 | `.` | `tx.origin` | | address that originated the tx |
-| 33 | CALLER | 2 | `.` | `msg.sender` | | address of msg sender |
-| 34 | CALLVALUE | 2 | `.` | `msg.value` | | msg value, in wei |
-| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | read word from msg data at index `idx` |
-| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | length of msg data, in bytes |
-| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | copy msg data |
-| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | length of executing contract's code, in bytes |
-| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | copy executing contract's bytecode |
-| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | gas price of tx, in wei per unit gas [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) |
-| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | size of code at addr, in bytes |
-| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | copy code from `addr` |
-| 3D | RETURNDATASIZE | 2 | `.` | `size` | | size of returned data from last external call, in bytes |
-| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | copy returned data from last external call |
-| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | hash = addr.exists ? keccak256(addr.code) : 0 |
-| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | |
-| 41 | COINBASE | 2 | `.` | `block.coinbase` | | adresa navrhovatele aktuálního bloku |
-| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | timestamp of current block |
-| 43 | NUMBER | 2 | `.` | `block.number` | | number of current block |
-| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | randomness beacon |
-| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | gas limit of current block |
-| 46 | CHAINID | 2 | `.` | `chain_id` | | push current [chain id](https://eips.ethereum.org/EIPS/eip-155) onto stack |
-| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | balance of executing contract, in wei |
-| 48 | BASEFEE | 2 | `.` | `block.basefee` | | base fee of current block |
-| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) |
-| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | blob base fee of current block ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) |
-| 4B-4F | _invalid_ | | | | | |
-| 50 | POP | 2 | `_anon` | `.` | | remove item from top of stack and discard it |
-| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | read word from memory at offset `ost` |
-| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | write a word to memory |
-| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | write a single byte to memory |
-| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | read word from storage |
-| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | write word to storage |
-| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` mark that `pc` is only assigned if `dst` is a valid jumpdest |
-| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ? dst : $pc + 1` |
-| 58 | PC | 2 | `.` | `$pc` | | program counter |
-| 59 | MSIZE | 2 | `.` | `len(mem)` | | size of memory in current execution context, in bytes |
-| 5A | GAS | 2 | `.` | `gasRemaining` | | |
-| 5B | JUMPDEST | 1 | | | mark valid jump destination | a valid jump destination for example a jump destination not inside the push data |
-| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | read word from transient storage ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
-| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | write word to transient storage ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
-| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | copy memory from one area to another ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) |
-| 5F | PUSH0 | 2 | `.` | `uint8` | | push the constant value 0 onto stack |
-| 60 | PUSH1 | 3 | `.` | `uint8` | | push 1-byte value onto stack |
-| 61 | PUSH2 | 3 | `.` | `uint16` | | push 2-byte value onto stack |
-| 62 | PUSH3 | 3 | `.` | `uint24` | | push 3-byte value onto stack |
-| 63 | PUSH4 | 3 | `.` | `uint32` | | push 4-byte value onto stack |
-| 64 | PUSH5 | 3 | `.` | `uint40` | | push 5-byte value onto stack |
-| 65 | PUSH6 | 3 | `.` | `uint48` | | push 6-byte value onto stack |
-| 66 | PUSH7 | 3 | `.` | `uint56` | | push 7-byte value onto stack |
-| 67 | PUSH8 | 3 | `.` | `uint64` | | push 8-byte value onto stack |
-| 68 | PUSH9 | 3 | `.` | `uint72` | | push 9-byte value onto stack |
-| 69 | PUSH10 | 3 | `.` | `uint80` | | push 10-byte value onto stack |
-| 6A | PUSH11 | 3 | `.` | `uint88` | | push 11-byte value onto stack |
-| 6B | PUSH12 | 3 | `.` | `uint96` | | push 12-byte value onto stack |
-| 6C | PUSH13 | 3 | `.` | `uint104` | | push 13-byte value onto stack |
-| 6D | PUSH14 | 3 | `.` | `uint112` | | push 14-byte value onto stack |
-| 6E | PUSH15 | 3 | `.` | `uint120` | | push 15-byte value onto stack |
-| 6F | PUSH16 | 3 | `.` | `uint128` | | push 16-byte value onto stack |
-| 70 | PUSH17 | 3 | `.` | `uint136` | | push 17-byte value onto stack |
-| 71 | PUSH18 | 3 | `.` | `uint144` | | push 18-byte value onto stack |
-| 72 | PUSH19 | 3 | `.` | `uint152` | | push 19-byte value onto stack |
-| 73 | PUSH20 | 3 | `.` | `uint160` | | push 20-byte value onto stack |
-| 74 | PUSH21 | 3 | `.` | `uint168` | | push 21-byte value onto stack |
-| 75 | PUSH22 | 3 | `.` | `uint176` | | push 22-byte value onto stack |
-| 76 | PUSH23 | 3 | `.` | `uint184` | | push 23-byte value onto stack |
-| 77 | PUSH24 | 3 | `.` | `uint192` | | push 24-byte value onto stack |
-| 78 | PUSH25 | 3 | `.` | `uint200` | | push 25-byte value onto stack |
-| 79 | PUSH26 | 3 | `.` | `uint208` | | push 26-byte value onto stack |
-| 7A | PUSH27 | 3 | `.` | `uint216` | | push 27-byte value onto stack |
-| 7B | PUSH28 | 3 | `.` | `uint224` | | push 28-byte value onto stack |
-| 7C | PUSH29 | 3 | `.` | `uint232` | | push 29-byte value onto stack |
-| 7D | PUSH30 | 3 | `.` | `uint240` | | push 30-byte value onto stack |
-| 7E | PUSH31 | 3 | `.` | `uint248` | | push 31-byte value onto stack |
-| 7F | PUSH32 | 3 | `.` | `uint256` | | push 32-byte value onto stack |
-| 80 | DUP1 | 3 | `a` | `a, a` | | clone 1st value on stack |
-| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clone 2nd value on stack |
-| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clone 3rd value on stack |
-| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clone 4th value on stack |
-| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clone 5th value on stack |
-| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clone 6th value on stack |
-| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clone 7th value on stack |
-| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clone 8th value on stack |
-| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clone 9th value on stack |
-| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clone 10th value on stack |
-| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clone 11th value on stack |
-| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clone 12th value on stack |
-| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clone 13th value on stack |
-| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clone 14th value on stack |
-| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clone 15th value on stack |
-| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clone 16th value on stack |
-| 90 | SWAP1 | 3 | `a, b` | `b, a` | | |
-| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | |
-| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | |
-| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | |
-| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | |
-| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) |
-| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) |
-| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) |
-| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) |
-| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) |
-| A5-EF | _invalid_ | | | | | |
-| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) |
-| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | same as DELEGATECALL, but does not propagate original msg.sender and msg.value |
-| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | return mem[ost:ost+len-1] |
-| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] |
-| F6-F9 | _invalid_ | | | | | |
-| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| FB-FC | _invalid_ | | | | | |
-| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) |
-| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | designated invalid opcode - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | |
-| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | sends all ETH to `addr`; if executed in the same transaction as a contract was created it destroys the contract |
+| Zásobník | Název | Palivo | Počáteční zásobník | Výsledný zásobník | Paměť/úložiště | Poznámky | |
+| :------: | :------------- | :---------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- |
+| 00 | STOP | 0 | | | | zastavit provádění | |
+| 01 | ADD | 3 | `a, b` | `a + b` | | sčítání (u)int256 modulo 2\*\*256 | |
+| 02 | MUL | 5 | `a, b` | `a * b` | | násobení (u)int256 modulo 2\*\*256 | |
+| 03 | SUB | 3 | `a, b` | `a - b` | | odčítání (u)int256 modulo 2\*\*256 | |
+| 04 | DIV | 5 | `a, b` | `a // b` | | dělení uint256 | |
+| 05 | SDIV | 5 | `a, b` | `a // b` | | dělení int256 | |
+| 06 | MOD | 5 | `a, b` | `a % b` | | modulo uint256 | |
+| 07 | SMOD | 5 | `a, b` | `a % b` | | modulo int256 | |
+| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | sčítání (u)int256 modulo N | |
+| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | násobení (u)int256 modulo N | |
+| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | umocňování uint256 modulo 2\*\*256 | |
+| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [rozšíření znaménka](https://wikipedia.org/wiki/Sign_extension) `x` z `(b+1)` bajtů na 32 bajtů | |
+| 0C-0F | _neplatné_ | | | | | | |
+| 10 | LT | 3 | `a, b` | `a < b` | | uint256 menší než | |
+| 11 | GT | 3 | `a, b` | `a > b` | | uint256 větší než | |
+| 12 | SLT | 3 | `a, b` | `a < b` | | int256 menší než | |
+| 13 | SGT | 3 | `a, b` | `a > b` | | int256 větší než | |
+| 14 | EQ | 3 | `a, b` | `a == b` | | rovnost (u)int256 | |
+| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 je nula | |
+| 16 | AND | 3 | `a, b` | `a && b` | | bitové AND | |
+| 17 | OR | 3 | `a, b` | `a \\|\\| b` | | bitové OR | |
+| 18 | XOR | 3 | `a, b` | `a ^ b` | | bitové XOR | |
+| 19 | NOT | 3 | `a` | `~a` | | bitové NOT | |
+| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`-tý bajt (u)int256 `x`, zleva | |
+| 1B | SHL | 3 | `shift, val` | `val << shift` | | posun vlevo | |
+| 1C | SHR | 3 | `shift, val` | `val >> shift` | | logický posun vpravo | |
+| 1D | SAR | 3 | `shift, val` | `val >> shift` | | aritmetický posun vpravo | |
+| 1E-1F | _neplatné_ | | | | | | |
+| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | |
+| 21-2F | _neplatné_ | | | | | | |
+| 30 | ADDRESS | 2 | `.` | `address(this)` | | adresa prováděné smlouvy | |
+| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | zůstatek, ve wei | |
+| 32 | ORIGIN | 2 | `.` | `tx.origin` | | adresa, která zahájila transakci | |
+| 33 | CALLER | 2 | `.` | `msg.sender` | | adresa odesílatele zprávy | |
+| 34 | CALLVALUE | 2 | `.` | `msg.value` | | hodnota zprávy, ve wei | |
+| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | přečíst slovo z dat zprávy na indexu `idx` | |
+| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | délka dat zprávy, v bajtech | |
+| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | kopírovat data zprávy | |
+| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | délka kódu prováděné smlouvy, v bajtech | |
+| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | kopírovat bajtkód prováděné smlouvy |
+| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | cena plynu transakce, ve wei za jednotku plynu [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | |
+| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | velikost kódu na adrese, v bajtech | |
+| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | kopírovat kód z `addr` | |
+| 3D | RETURNDATASIZE | 2 | `.` | `size` | | velikost vrácených dat z posledního externího volání, v bajtech | |
+| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | kopírovat vrácená data z posledního externího volání | |
+| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | haš = addr.exists ? keccak256(addr.code) : 0 | |
+| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | |
+| 41 | COINBASE | 2 | `.` | `block.coinbase` | | adresa navrhovatele aktuálního bloku | |
+| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | časové razítko aktuálního bloku | |
+| 43 | NUMBER | 2 | `.` | `block.number` | | číslo aktuálního bloku | |
+| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | maják náhodnosti | |
+| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | limit transakčních poplatků aktuálního bloku | |
+| 46 | CHAINID | 2 | `.` | `chain_id` | | vložit aktuální [ID řetězce](https://eips.ethereum.org/EIPS/eip-155) na zásobník | |
+| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | zůstatek prováděné smlouvy, ve wei | |
+| 48 | BASEFEE | 2 | `.` | `block.basefee` | | základní poplatek aktuálního bloku | |
+| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | |
+| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | základní poplatek blobu aktuálního bloku ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | |
+| 4B-4F | _neplatné_ | | | | | | |
+| 50 | POP | 2 | `_anon` | `.` | | odebrat položku z vrcholu zásobníku a zahodit ji | |
+| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | přečíst slovo z paměti na offsetu `ost` | |
+| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | zapsat slovo do paměti | |
+| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | zapsat jeden bajt do paměti | |
+| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | přečíst slovo z úložiště | |
+| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | zapsat slovo do úložiště | |
+| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` označuje, že `pc` se přiřadí, pouze pokud je `dst` platný cíl skoku | |
+| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ?` dst : $pc + 1\` | |
+| 58 | PC | 2 | `.` | `$pc` | | čítač programu | |
+| 59 | MSIZE | 2 | `.` | `len(mem)` | | velikost paměti v aktuálním kontextu provádění, v bajtech | |
+| 5A | GAS | 2 | `.` | `gasRemaining` | | | |
+| 5B | JUMPDEST | 1 | | | označit platný cíl skoku | platný cíl skoku, například cíl skoku, který není uvnitř dat pro push | |
+| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | přečíst slovo z dočasného úložiště ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | |
+| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | zapsat slovo do dočasného úložiště ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | |
+| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | kopírovat paměť z jedné oblasti do druhé ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) | |
+| 5F | PUSH0 | 2 | `.` | `uint8` | | vložit konstantní hodnotu 0 na zásobník | |
+| 60 | PUSH1 | 3 | `.` | `uint8` | | vložit 1bajtovou hodnotu na zásobník | |
+| 61 | PUSH2 | 3 | `.` | `uint16` | | vložit 2bajtovou hodnotu na zásobník | |
+| 62 | PUSH3 | 3 | `.` | `uint24` | | vložit 3bajtovou hodnotu na zásobník | |
+| 63 | PUSH4 | 3 | `.` | `uint32` | | vložit 4bajtovou hodnotu na zásobník | |
+| 64 | PUSH5 | 3 | `.` | `uint40` | | vložit 5bajtovou hodnotu na zásobník | |
+| 65 | PUSH6 | 3 | `.` | `uint48` | | vložit 6bajtovou hodnotu na zásobník | |
+| 66 | PUSH7 | 3 | `.` | `uint56` | | vložit 7bajtovou hodnotu na zásobník | |
+| 67 | PUSH8 | 3 | `.` | `uint64` | | vložit 8bajtovou hodnotu na zásobník | |
+| 68 | PUSH9 | 3 | `.` | `uint72` | | vložit 9bajtovou hodnotu na zásobník | |
+| 69 | PUSH10 | 3 | `.` | `uint80` | | vložit 10bajtovou hodnotu na zásobník | |
+| 6A | PUSH11 | 3 | `.` | `uint88` | | vložit 11bajtovou hodnotu na zásobník | |
+| 6B | PUSH12 | 3 | `.` | `uint96` | | vložit 12bajtovou hodnotu na zásobník | |
+| 6C | PUSH13 | 3 | `.` | `uint104` | | vložit 13bajtovou hodnotu na zásobník | |
+| 6D | PUSH14 | 3 | `.` | `uint112` | | vložit 14bajtovou hodnotu na zásobník | |
+| 6E | PUSH15 | 3 | `.` | `uint120` | | vložit 15bajtovou hodnotu na zásobník | |
+| 6F | PUSH16 | 3 | `.` | `uint128` | | vložit 16bajtovou hodnotu na zásobník | |
+| 70 | PUSH17 | 3 | `.` | `uint136` | | vložit 17bajtovou hodnotu na zásobník | |
+| 71 | PUSH18 | 3 | `.` | `uint144` | | vložit 18bajtovou hodnotu na zásobník | |
+| 72 | PUSH19 | 3 | `.` | `uint152` | | vložit 19bajtovou hodnotu na zásobník | |
+| 73 | PUSH20 | 3 | `.` | `uint160` | | vložit 20bajtovou hodnotu na zásobník | |
+| 74 | PUSH21 | 3 | `.` | `uint168` | | vložit 21bajtovou hodnotu na zásobník | |
+| 75 | PUSH22 | 3 | `.` | `uint176` | | vložit 22bajtovou hodnotu na zásobník | |
+| 76 | PUSH23 | 3 | `.` | `uint184` | | vložit 23bajtovou hodnotu na zásobník | |
+| 77 | PUSH24 | 3 | `.` | `uint192` | | vložit 24bajtovou hodnotu na zásobník | |
+| 78 | PUSH25 | 3 | `.` | `uint200` | | vložit 25bajtovou hodnotu na zásobník | |
+| 79 | PUSH26 | 3 | `.` | `uint208` | | vložit 26bajtovou hodnotu na zásobník | |
+| 7A | PUSH27 | 3 | `.` | `uint216` | | vložit 27bajtovou hodnotu na zásobník | |
+| 7B | PUSH28 | 3 | `.` | `uint224` | | vložit 28bajtovou hodnotu na zásobník | |
+| 7C | PUSH29 | 3 | `.` | `uint232` | | vložit 29bajtovou hodnotu na zásobník | |
+| 7D | PUSH30 | 3 | `.` | `uint240` | | vložit 30bajtovou hodnotu na zásobník | |
+| 7E | PUSH31 | 3 | `.` | `uint248` | | vložit 31bajtovou hodnotu na zásobník | |
+| 7F | PUSH32 | 3 | `.` | `uint256` | | vložit 32bajtovou hodnotu na zásobník | |
+| 80 | DUP1 | 3 | `a` | `a, a` | | klonovat 1. hodnotu na zásobníku | |
+| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | klonovat 2. hodnotu na zásobníku | |
+| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | klonovat 3. hodnotu na zásobníku | |
+| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | klonovat 4. hodnotu na zásobníku | |
+| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | klonovat 5. hodnotu na zásobníku | |
+| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | klonovat 6. hodnotu na zásobníku | |
+| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | klonovat 7. hodnotu na zásobníku | |
+| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | klonovat 8. hodnotu na zásobníku | |
+| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | klonovat 9. hodnotu na zásobníku | |
+| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | klonovat 10. hodnotu na zásobníku | |
+| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | klonovat 11. hodnotu na zásobníku | |
+| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | klonovat 12. hodnotu na zásobníku | |
+| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | klonovat 13. hodnotu na zásobníku | |
+| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | klonovat 14. hodnotu na zásobníku | |
+| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | klonovat 15. hodnotu na zásobníku | |
+| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | klonovat 16. hodnotu na zásobníku | |
+| 90 | SWAP1 | 3 | `a, b` | `b, a` | | | |
+| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | | |
+| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | | |
+| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | | |
+| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | | |
+| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) | |
+| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) | |
+| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) | |
+| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) | |
+| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) | |
+| A5-EF | _neplatné_ | | | | | | |
+| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) | |
+| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | plyn, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | | |
+| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `plyn, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | stejné jako DELEGATECALL, ale nešíří původní msg.sender a msg.value | |
+| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | vrátit mem[ost:ost+len-1] | |
+| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `plyn, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | |
+| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] | |
+| F6-F9 | _neplatné_ | | | | | | |
+| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `plyn, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | |
+| FB-FC | _neplatné_ | | | | | | |
+| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) | |
+| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | označený neplatný operační kód – [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | | |
+| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | pošle všechny ETH na `addr`; pokud je proveden ve stejné transakci, ve které byla vytvořena smlouva, smlouvu zničí | |
diff --git a/public/content/translations/cs/developers/docs/frameworks/index.md b/public/content/translations/cs/developers/docs/frameworks/index.md
new file mode 100644
index 00000000000..d21d1e87822
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/frameworks/index.md
@@ -0,0 +1,157 @@
+---
+title: Frameworky pro vývoj dappek
+description: Prozkoumejte výhody frameworků a porovnejte dostupné možnosti.
+lang: cs
+---
+
+## Úvod do frameworků {#introduction-to-frameworks}
+
+Vytvoření plnohodnotné dappky (decentralizované aplikace) vyžaduje
+různé technologie. Softwarové frameworky zahrnují mnoho potřebných
+funkcí nebo poskytují snadné pluginové systémy, které vám umožní vybrat si nástroje,
+které potřebujete.
+
+Frameworky nabízejí velké množství funkcí,
+například:
+
+- Funkce ke spuštění vlastního lokálního blockchainu.
+- Nástroje pro kompilaci a testování chytrých kontraktů.
+- Vývojové doplňky klienta, které vytvoří vaši uživatelskou aplikaci
+ v rámci stejného projektu/úložiště.
+- Konfigurace pro připojení k sítím Ethereum a nasazení
+ kontraktů, ať už na lokálně spuštěnou instanci, nebo na jednu z
+ veřejných sítí Ethereum.
+- Decentralizovaná distribuce aplikací – integrace s možnostmi úložiště,
+ jako je IPFS.
+
+## Předpoklady {#prerequisites}
+
+Než se ponoříte do frameworků, doporučujeme vám nejprve si přečíst náš úvod do [dapps](/developers/docs/dapps/) a [zásobníku Ethereum](/developers/docs/ethereum-stack/).
+
+## Dostupné frameworky {#available-frameworks}
+
+**Foundry** – **_Foundry je bleskově rychlá, přenosná a modulární sada nástrojů pro vývoj aplikací na Ethereum_**
+
+- [Nainstalovat Foundry](https://book.getfoundry.sh/)
+- [Kniha o Foundry](https://book.getfoundry.sh/)
+- [Komunitní chat Foundry na Telegramu](https://t.me/foundry_support)
+- [Awesome Foundry](https://github.com/crisgarner/awesome-foundry)
+
+**Hardhat –** **_Vývojové prostředí Ethereum pro profesionály._**
+
+- [hardhat.org](https://hardhat.org)
+- [GitHub](https://github.com/nomiclabs/hardhat)
+
+**Ape –** **_Nástroj pro vývoj chytrých kontraktů pro pythonisty, datové vědce a bezpečnostní profesionály._**
+
+- [Dokumentace](https://docs.apeworx.io/ape/stable/)
+- [GitHub](https://github.com/ApeWorX/ape)
+
+**Web3j –** **_Platforma pro vývoj blockchainových aplikací na JVM._**
+
+- [Domovská stránka](https://www.web3labs.com/web3j-sdk)
+- [Dokumentace](https://docs.web3j.io)
+- [GitHub](https://github.com/web3j/web3j)
+
+**ethers-kt –** **_Asynchronní, vysoce výkonná knihovna pro Kotlin/Javu/Android pro blockchainy založené na EVM._**
+
+- [GitHub](https://github.com/Kr1ptal/ethers-kt)
+- [Příklady](https://github.com/Kr1ptal/ethers-kt/tree/master/examples)
+- [Discord](https://discord.gg/rx35NzQGSb)
+
+**Create Eth App –** **_Vytvořte aplikace s podporou Ethereum jedním příkazem. Nabízí širokou škálu UI frameworků a DeFi šablon._**
+
+- [GitHub](https://github.com/paulrberg/create-eth-app)
+- [Šablony](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates)
+
+**Scaffold-Eth –** **_Ethers.js + Hardhat + React komponenty a hooky pro web3: vše, co potřebujete k tomu, abyste mohli začít budovat decentralizované aplikace využívající chytré kontrakty._**
+
+- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2)
+
+**Tenderly –** **_Web3 vývojářská platforma, která umožňuje blockchainovým vývojářům vytvářet, testovat, ladit, monitorovat a provozovat chytré kontrakty a zlepšovat UX pro dapps._**
+
+- [Webová stránka](https://tenderly.co/)
+- [Dokumentace](https://docs.tenderly.co/)
+
+**The Graph –** **_The Graph pro efektivní dotazování na data z blockchainu._**
+
+- [Webová stránka](https://thegraph.com/)
+- [Návod](/developers/tutorials/the-graph-fixing-web3-data-querying/)
+
+**Alchemy –** **_Vývojářská platforma pro Ethereum._**
+
+- [alchemy.com](https://www.alchemy.com/)
+- [GitHub](https://github.com/alchemyplatform)
+- [Discord](https://discord.com/invite/alchemyplatform)
+
+**NodeReal –** **_Vývojářská platforma pro Ethereum._**
+
+- [Nodereal.io](https://nodereal.io/)
+- [GitHub](https://github.com/node-real)
+- [Discord](https://discord.gg/V5k5gsuE)
+
+**thirdweb SDK –** **_Vytvářejte web3 aplikace, které mohou interagovat s vašimi chytrými kontrakty pomocí našich výkonných SDK a CLI._**
+
+- [Dokumentace](https://portal.thirdweb.com/sdk/)
+- [GitHub](https://github.com/thirdweb-dev/)
+
+**Chainstack –** **_Vývojářská platforma pro Web3 (Ethereum a další)._**
+
+- [chainstack.com](https://www.chainstack.com/)
+- [GitHub](https://github.com/chainstack)
+- [Discord](https://discord.gg/BSb5zfp9AT)
+
+**Crossmint –** **_Web3 vývojářská platforma podnikové úrovně, která vám umožňuje vytvářet NFT aplikace na všech hlavních EVM řetězcích (a dalších)._**
+
+- [Webová stránka](https://www.crossmint.com)
+- [Dokumentace](https://docs.crossmint.com)
+- [Discord](https://discord.com/invite/crossmint)
+
+**Brownie –** **_Vývojové prostředí a testovací framework založený na Pythonu._**
+
+- [Dokumentace](https://eth-brownie.readthedocs.io/en/latest/)
+- [GitHub](https://github.com/eth-brownie/brownie)
+- **Brownie se v současné době neudržuje**
+
+**OpenZeppelin SDK –** **_Kompletní sada nástrojů pro chytré kontrakty: sada nástrojů, které vám pomohou vyvíjet, kompilovat, vylepšovat, nasazovat chytré kontrakty a pracovat s nimi._**
+
+- [OpenZeppelin Defender SDK](https://docs.openzeppelin.com/defender/sdk)
+- [GitHub](https://github.com/OpenZeppelin/openzeppelin-sdk)
+- [Komunitní fórum](https://forum.openzeppelin.com/c/support/17)
+- **Vývoj OpenZeppelin SDK byl ukončen**
+
+**Catapulta –** **_Nástroj pro nasazování chytrých kontraktů na více řetězců, který automatizuje ověřování v prohlížečích bloků, sleduje nasazené chytré kontrakty, sdílí zprávy o nasazení a funguje jako plug-n-play pro projekty Foundry a Hardhat._**
+
+- [Webová stránka](https://catapulta.sh/)
+- [Dokumentace](https://catapulta.sh/docs)
+- [Github](https://github.com/catapulta-sh)
+
+**GoldRush (využívá Covalent) –** **_GoldRush nabízí nejkomplexnější sadu API pro data z blockchainu pro vývojáře, analytiky a podniky. Ať už vytváříte DeFi dashboard, peněženku, obchodního bota, AI agenta nebo platformu pro dodržování předpisů, datová API poskytují rychlý, přesný a pro vývojáře přívětivý přístup k základním onchain datům, která potřebujete_**
+
+- [Webová stránka](https://goldrush.dev/)
+- [Dokumentace](https://goldrush.dev/docs/chains/ethereum)
+- [GitHub](https://github.com/covalenthq)
+- [Discord](https://www.covalenthq.com/discord/)
+
+**Wake –** **_Univerzální pythonový framework pro testování kontraktů, fuzzing, nasazení, skenování zranitelností a navigaci v kódu._**
+
+- [Domovská stránka](https://getwake.io/)
+- [Dokumentace](https://ackeeblockchain.com/wake/docs/latest/)
+- [GitHub](https://github.com/Ackee-Blockchain/wake)
+- [Rozšíření pro VS Code](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity)
+
+**Veramo –** **_Otevřený, modulární a agnostický framework, který usnadňuje vývojářům decentralizovaných aplikací vytvářet decentralizované identity a ověřitelná pověření ve svých aplikacích._**
+
+- [Domovská stránka](https://veramo.io/)
+- [Dokumentace](https://veramo.io/docs/basics/introduction)
+- [GitHub](https://github.com/uport-project/veramo)
+- [Discord](https://discord.com/invite/FRRBdjemHV)
+- [Balíček NPM](https://www.npmjs.com/package/@veramo/core)
+
+## Další čtení {#further-reading}
+
+_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_
+
+## Související témata {#related-topics}
+
+- [Nastavení lokálního vývojového prostředí](/developers/local-environment/)
diff --git a/public/content/translations/cs/developers/docs/gas/index.md b/public/content/translations/cs/developers/docs/gas/index.md
index 90a371cc64f..339b7110c97 100644
--- a/public/content/translations/cs/developers/docs/gas/index.md
+++ b/public/content/translations/cs/developers/docs/gas/index.md
@@ -1,7 +1,7 @@
---
title: Palivo a poplatky
metaTitle: "Palivo a poplatky na Ethereu: technický přehled"
-description:
+description: Zjistěte více o poplatcích za palivo na Ethereu, jak se vypočítávají a jakou roli hrají v zabezpečení sítě a zpracování transakcí.
lang: cs
---
@@ -9,7 +9,7 @@ Palivo je pro síť Ethereum nezbytné. Umožňuje jí fungovat, stejně jako au
## Předpoklady {#prerequisites}
-Abyste lépe porozuměli této stránce, doporučujeme vám si nejprve přečíst o [transakcích](/developers/docs/transactions/) a [EVM](/developers/docs/evm/).
+Pro lepší pochopení této stránky vám doporučujeme si nejprve přečíst o [transakcích](/developers/docs/transactions/) a [EVM](/developers/docs/evm/).
## Co je to palivo? {#what-is-gas}
@@ -17,15 +17,16 @@ Palivo označuje jednotku, která měří množství výpočetního úsilí pot
Jelikož každá transakce na Ethereu potřebuje výpočetní zdroje k jejímu provedení, tyto zdroje se musí zaplatit, aby Ethereum nebylo zranitelné vůči spamovým útokům a nemohlo se zaseknout v nekonečných výpočetních smyčkách. Platba za výpočetní úsilí se provádí ve formě poplatku za palivo.
-Poplatek za palivo je **množství paliva použitého k provedení určité operace, vynásobené nákladem na jednotku paliva**. Poplatek je zaplacen bez ohledu na to, zda je transakce úspěšně realizována, nebo selže.
+Poplatek za palivo je **množství paliva použitého k provedení určité operace vynásobené cenou za jednotku paliva**. Poplatek je zaplacen bez ohledu na to, zda je transakce úspěšně realizována, nebo selže.
- _Schéma převzato z [ilustrace Ethereum EVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_Diagram převzat z [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
Poplatky za palivo musí být zaplaceny v nativní měně Etherea, etheru (ETH). Ceny paliva jsou obvykle uváděny v gwei, což je denominace ETH. Každý gwei je roven jedné miliardtině ETH (0,000000001 ETH nebo 10-9 ETH).
Např. místo toho, abyste řekli, že vaše palivo stojí 0,000000001 etheru, můžete říct, že stojí 1 gwei.
-Slovo 'gwei' je zkratka pro „giga-wei“, což znamená „miliarda wei“. Jeden gwei se rovná jedné miliardě wei. Wei samo o sobě (pojmenované po [Wei Daiovi](https://wikipedia.org/wiki/Wei_Dai), tvůrci [b-money](https://www.investopedia.com/terms/b/bmoney.asp)) je nejmenší jednotkou ETH.
+Slovo 'gwei' je zkratka pro „giga-wei“, což znamená „miliarda wei“. Jeden gwei se rovná jedné miliardě wei. Samotný wei (pojmenovaný po [Wei Daiovi](https://wikipedia.org/wiki/Wei_Dai), tvůrci [b-money](https://www.investopedia.com/terms/b/bmoney.asp)) je nejmenší jednotkou ETH.
## Jak se vypočítají palivové poplatky? {#how-are-gas-fees-calculated}
@@ -35,7 +36,7 @@ Celkový poplatek za palivo, který zaplatíte, se skládá ze dvou složek: `z
`Základní poplatek` stanovuje protokol – musíte zaplatit alespoň tuto částku, aby byla vaše transakce považována za platnou. `Prioritní poplatek` je spropitné, které přidáte k základnímu poplatku, aby byla vaše transakce atraktivní pro validátory – aby ji vybrali k zařazení do dalšího bloku.
-Transakce, která nabízí pouze `základní poplatek`, je technicky platná, ale je nepravděpodobné, že bude do bloku zařazena, protože nenabízí validátorům žádný motiv ji vybrat před jakoukoli jinou transakcí. „Správný“ `prioritní` poplatek je stanoven podle využití sítě v době odeslání vaší transakce – pokud je vysoká poptávka, možná budete muset nastavit vyšší `prioritní` poplatek, ale když je poptávka nižší, můžete zaplatit méně.
+Transakce, u které se platí pouze `základní poplatek`, je technicky platná, ale je nepravděpodobné, že bude zahrnuta, protože validátorům nenabízí žádnou motivaci, aby ji upřednostnili před jinou transakcí. „Správný“ `prioritní` poplatek je určen vytížením sítě v době odeslání transakce – pokud je velká poptávka, možná budete muset nastavit vyšší `prioritní` poplatek, ale když je poptávka nižší, můžete zaplatit méně.
Např. řekněme, že Jordan musí zaplatit Taylorovi 1 ETH. Převod ETH vyžaduje 21 000 jednotek paliva a základní poplatek je 10 gwei. Jordan přidá spropitné 2 gwei.
@@ -43,44 +44,44 @@ Celkový poplatek by nyní dělal:
`spotřebované jednotky paliva * (základní poplatek + prioritní poplatek)`
-kde `základní poplatek` je hodnota stanovená protokolem a `prioritní poplatek` je hodnota stanovená uživatelem jako spropitné pro validátora.
+kde `základní poplatek` je hodnota stanovená protokolem a `prioritní poplatek` je hodnota, kterou stanoví uživatel jako spropitné pro validátora.
-tj. `21 000 * (10 + 2) = 252 000 gwei` (0,000252 ETH).
+např. `21,000 * (10 + 2) = 252,000 gwei` (0,000252 ETH).
-Když Jordan odešle peníze, z jeho účtu bude odečteno 1,000252 ETH. Taylor obdrží 1,0000 ETH. Validátor obdrží spropitné ve výši 0,000042 ETH. `Základní poplatek` 0,00021 ETH bude spálen.
+Když Jordan odešle peníze, z jeho účtu bude odečteno 1,000252 ETH. Taylor obdrží 1,0000 ETH. Validátor obdrží spropitné ve výši 0,000042 ETH. `Základní poplatek` ve výši 0,00021 ETH je spálen.
### Základní poplatek {#base-fee}
-Každý blok má základní poplatek, který funguje jako rezervní cena. Aby byla transakce způsobilá k zařazení do bloku, nabízená cena za palivo musí být rovna alespoň základnímu poplatku. Základní poplatek je vypočítán nezávisle na aktuálním bloku a je místo toho určen bloky před ním – což dělá transakční poplatky pro uživatele předvídatelnějšími. Po vytvoření bloku je tento **základní poplatek „spálen“**, což znamená, že množství etheru použité na jeho zaplacení je odstraněno z oběhu.
+Každý blok má základní poplatek, který funguje jako rezervní cena. Aby byla transakce způsobilá k zařazení do bloku, nabízená cena za palivo musí být rovna alespoň základnímu poplatku. Základní poplatek se vypočítává nezávisle na aktuálním bloku a je určen bloky před ním, díky čemuž jsou transakční poplatky pro uživatele předvídatelnější. Při vytvoření bloku je tento **základní poplatek „spálen“**, čímž je odstraněn z oběhu.
-Základní poplatek je vypočítán podle vzorce, který porovnává velikost předchozího bloku (množství paliva použitého na všechny transakce) s cílovou velikostí. Základní poplatek se zvýší o maximálně 12,5 % za blok, pokud je překročena cílová velikost bloku. Tento exponenciální růst činí ekonomicky neudržitelným, aby velikost bloku zůstala vysoká po neomezenou dobu.
+Základní poplatek se vypočítává podle vzorce, který porovnává velikost předchozího bloku (množství paliva spotřebovaného na všechny transakce) s cílovou velikostí (polovina limitu transakčních poplatků). Základní poplatek se zvýší nebo sníží o maximálně 12,5 % za blok, pokud je cílová velikost bloku překročena, resp. nedosažena. Tento exponenciální růst činí ekonomicky neudržitelným, aby velikost bloku zůstala vysoká po neomezenou dobu.
-| Číslo bloku | Zahrnuté palivo | Zvýšení poplatku | Aktuální základní poplatek |
-| ----------- | ---------------:| ----------------:| --------------------------:|
-| 1 | 15M | 0% | 100 gwei |
-| 2 | 30M | 0% | 100 gwei |
-| 3 | 30M | 12,5 % | 112,5 gwei |
-| 4 | 30M | 12,5 % | 126,6 gwei |
-| 5 | 30M | 12,5 % | 142,4 gwei |
-| 6 | 30M | 12,5 % | 160,2 gwei |
-| 7 | 30M | 12,5 % | 180,2 gwei |
-| 8 | 30M | 12,5 % | 202,7 gwei |
+| Číslo bloku | Zahrnuté palivo | Zvýšení poplatku | Aktuální základní poplatek |
+| ----------- | ----------------------: | ---------------: | -------------------------: |
+| 1 | 18 mil. | 0% | 100 gwei |
+| 2 | 36 mil. | 0% | 100 gwei |
+| 3 | 36 mil. | 12,5 % | 112,5 gwei |
+| 4 | 36 mil. | 12,5 % | 126,6 gwei |
+| 5 | 36 mil. | 12,5 % | 142,4 gwei |
+| 6 | 36 mil. | 12,5 % | 160,2 gwei |
+| 7 | 36 mil. | 12,5 % | 180,2 gwei |
+| 8 | 36 mil. | 12,5 % | 202,7 gwei |
-Podle výše uvedené tabulky by k vytvoření transakce v bloku číslo 9 peněženka s jistotou informovala uživatele, že **maximální základní poplatek** dalšího bloku je `aktuální základní poplatek * 112,5 %` nebo `202,7 gwei * 112,5 % = 228,1 gwei`.
+Ve výše uvedené tabulce je uveden příklad s limitem transakčních poplatků 36 milionů. Podle tohoto příkladu při vytváření transakce v bloku číslo 9 peněženka s jistotou informuje uživatele, že **maximální základní poplatek**, který bude přidán do dalšího bloku, je `current base fee * 112.5%` neboli `202.7 gwei * 112.5% = 228.1 gwei`.
Je také důležité poznamenat, že z důvodu rychlosti, s jakou se základní poplatek zvyšuje předcházejícímu plnému bloku, je nepravděpodobné, že bychom viděli dlouhodobé peaky plných bloků.
-| Číslo bloku | Zahrnuté palivo | Zvýšení poplatku | Aktuální základní poplatek |
-| ----------- | ---------------:| ----------------:| --------------------------:|
-| 30 | 30M | 12,5 % | 2 705,6 gwei |
-| ... | ... | 12,5 % | ... |
-| 50 | 30M | 12,5 % | 28 531,3 gwei |
-| ... | ... | 12,5 % | ... |
-| 100 | 30M | 12,5 % | 10 302 608,6 gwei |
+| Číslo bloku | Zahrnuté palivo | Zvýšení poplatku | Aktuální základní poplatek |
+| --------------------------------------------------- | --------------------------------------------------: | ---------------: | --------------------------------------------------: |
+| 30 | 36 mil. | 12,5 % | 2 705,6 gwei |
+| ... | ... | 12,5 % | ... |
+| 50 | 36 mil. | 12,5 % | 28 531,3 gwei |
+| ... | ... | 12,5 % | ... |
+| 100 | 36 mil. | 12,5 % | 10 302 608,6 gwei |
### Prioritní poplatek (spropitné) {#priority-fee}
-Prioritní poplatek (spropitné) motivuje validátory k zařazení transakce do bloku. Bez spropitného by pro validátory bylo ekonomicky výhodné těžit prázdné bloky, protože by obdrželi stejnou odměnu za blok. Malé spropitné dává validátorům minimální motivaci zahrnout transakci. Pro transakce, které mají být preferenčně provedeny před jinými transakcemi ve stejném bloku, lze přidat vyšší spropitné a pokusit se tak přeplatit konkurenční transakce.
+Prioritní poplatek (spropitné) motivuje validátory, aby maximalizovali počet transakcí v bloku, přičemž jsou omezeni pouze limitem transakčních poplatků bloku. Bez spropitného by racionální validátor mohl zahrnout méně transakcí, nebo dokonce žádné, a to bez jakéhokoli přímého postihu na exekuční nebo konsensuální vrstvě, protože odměny ze stakingu jsou nezávislé na počtu transakcí v bloku. Spropitné navíc umožňuje uživatelům přeplatit ostatní za prioritu v rámci stejného bloku, čímž efektivně signalizují naléhavost.
### Maximální poplatek {#maxfee}
@@ -88,7 +89,11 @@ Při provedení transakce na síti mohou uživatelé specifikovat maximální li
### Velikost bloku {#block-size}
-Každý blok má cílovou velikost 15 milionů jednotek paliva, ale velikost bloků se bude zvyšovat nebo snižovat v závislosti na poptávce na síti, až do limitu bloku 30 milionů jednotek paliva (2x cílová velikost bloku). Protokol v průměru dosahuje rovnovážné velikosti bloku 15 milionů prostřednictvím procesu zvaného _tâtonnement_. To znamená, že pokud je velikost bloku větší než cílová velikost bloku, protokol zvýší základní poplatek pro následující blok. Podobně, pokud je velikost bloku menší než cílová velikost, protokol sníží základní poplatek. Hodnota, o kterou se základní poplatek upravuje, je úměrná tomu, jak daleko je aktuální velikost bloku od cíle. [Další informace o blocích](/developers/docs/blocks/).
+Každý blok má cílovou velikost poloviny současného limitu transakčních poplatků, ale velikost bloků se bude zvyšovat nebo snižovat v souladu s poptávkou v síti, a to až do dosažení limitu bloku (2x cílová velikost bloku). Protokol dosahuje rovnovážné průměrné velikosti bloku na cílové úrovni prostřednictvím procesu _tâtonnement_. To znamená, že pokud je velikost bloku větší než cílová velikost bloku, protokol zvýší základní poplatek pro následující blok. Podobně, pokud je velikost bloku menší než cílová velikost, protokol sníží základní poplatek.
+
+Hodnota, o kterou se základní poplatek upravuje, je úměrná tomu, jak daleko je aktuální velikost bloku od cíle. Jedná se o lineární výpočet od -12,5 % pro prázdný blok, 0 % při cílové velikosti, až po +12,5 % pro blok, který dosáhne limitu transakčních poplatků. Limit transakčních poplatků se může v čase měnit na základě signalizace validátorů a také prostřednictvím vylepšení sítě. Změny limitu transakčních poplatků v čase si můžete [prohlédnout zde](https://eth.blockscout.com/stats/averageGasLimit?interval=threeMonths).
+
+[Více o blocích](/developers/docs/blocks/)
### Výpočet poplatků za palivo v praxi {#calculating-fees-in-practice}
@@ -98,13 +103,14 @@ Můžete explicitně uvést, kolik jste ochotni zaplatit, aby byla vaše transak
Stručně řečeno, poplatky za palivo pomáhají udržovat bezpečnost sítě Ethereum. Požadováním poplatku za každý výpočet provedený v síti zabráníme nečestným aktérům v zahlcení sítě. Abychom se vyhnuli náhodným nebo záměrným nekonečným smyčkám nebo jinému plýtvání výpočetními zdroji v kódu, každá transakce musí nastavit limit na počet výpočetních kroků potřebných k vykonání kódu. Základní jednotkou výpočtu je „palivo“.
-Ačkoliv transakce obsahuje limit, palivo nevyužité během transakce se vrací uživateli (tj. `maximální poplatek - (základní polatek + spropitné)` se vrací).
+Ačkoli transakce zahrnuje limit, jakékoli palivo, které se v transakci nespotřebuje, se vrací uživateli (např. se vrací `max fee - (base fee + tip)`).
- _Schéma převzato z [ilustrace Ethereum EVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_Diagram převzat z [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
## Co je to limit paliva? {#what-is-gas-limit}
-Limit paliva označuje maximální množství paliva, které jste ochotni za transakci utratit. Složitější transakce zahrnující [chytré kontrakty](/developers/docs/smart-contracts/) potřebují více výpočetního výkonu, a proto vyžadují vyšší limit paliva než jednoduchá platba. Standardní převod ETH vyžaduje limit paliva 21 000 jednotek.
+Limit paliva označuje maximální množství paliva, které jste ochotni za transakci utratit. Složitější transakce zahrnující [chytré kontrakty](/developers/docs/smart-contracts/) vyžadují více výpočetní práce, takže vyžadují vyšší limit transakčních poplatků než jednoduchá platba. Standardní převod ETH vyžaduje limit paliva 21 000 jednotek.
Např. pokud nastavíte limit paliva na 50 000 pro jednoduchý převod ETH, EVM spotřebuje 21 000 a zbývajících 29 000 se vám vrátí. Pokud však zadáte příliš málo paliva, například limit paliva 20 000 pro jednoduchý převod ETH, transakce ve fázi validace selže. Bude odmítnuta před zařazením do bloku a nebude spotřebováno žádné palivo. Na druhou stranu, pokud transakci během provádění dojde palivo (např. chytrý kontrakt spotřebuje v polovině provádění veškeré palivo), EVM vrátí všechny změny, ale veškeré poskytnuté palivo bude stále spotřebováno na provedenou práci.
@@ -114,28 +120,32 @@ Vysoké poplatky za palivo jsou způsobeny popularitou Etherea. Pokud je poptáv
## Iniciativy na snížení nákladů na palivo {#initiatives-to-reduce-gas-costs}
-[Vylepšení škálovatelnosti](/roadmap/) Etherea by měly řešit některé problémy palivových poplatků, což následně umožní platformě zpracovávat tisíce transakcí za sekundu a škálovat globálně.
+[Vylepšení škálovatelnosti](/roadmap/) Etherea by měla v konečném důsledku vyřešit některé problémy s poplatky za palivo, což platformě umožní zpracovávat tisíce transakcí za sekundu a škálovat globálně.
+
+Primární iniciativou ke snížení palivových nákladů a zlepšení uživatelských možností a škálovatelnosti je škálování druhé vrstvy.
-Primární iniciativou ke snížení palivových nákladů a zlepšení uživatelských možností a škálovatelnosti je škálování druhé vrstvy. [Další informace o škálování druhé vrstvy](/developers/docs/scaling/#layer-2-scaling).
+[Více o škálování na druhé vrstvě](/developers/docs/scaling/#layer-2-scaling)
## Monitorování poplatků za palivo {#monitoring-gas-fees}
Pokud chcete monitorovat poplatky za palivo, abyste mohli odesílat své ETH za nižší ceny, můžete využít několik různých nástrojů, např.:
-- [Etherscan](https://etherscan.io/gastracker) – _odhad ceny paliva za transakci_
-- [ETH tracker paliva](https://www.ethgastracker.com/) _Monitorujte a sledujte ceny paliva na Ethereu a vrstvě 2, abyste snížili transakční poplatky a ušetřili peníze_
-- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) – _rozšíření pro prohlížeč Chrome odhadující poplatky za palivo, které podporuje jak typ 0 legacy transakce, tak typ 2 transakce EIP-1559_
-- [Cryptoneur Gas Fees Calculator](https://www.cryptoneur.xyz/gas-fees-calculator) – _kalkulačka poplatků za palivo v místní měně pro různé typy transakcí na hlavní síti, Arbitru a Polygonu_
+- [Etherscan](https://etherscan.io/gastracker) _Odhad ceny transakčního paliva_
+- [Blockscout](https://eth.blockscout.com/gas-tracker) _Open-source odhad ceny transakčního paliva_
+- [ETH Gas Tracker](https://www.ethgastracker.com/) _Monitorujte a sledujte ceny paliva na Ethereu a L2, abyste snížili transakční poplatky a ušetřili peníze_
+- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _Rozšíření pro Chrome pro odhad paliva, které podporuje jak starší transakce typu 0, tak transakce typu 2 EIP-1559._
+- [Cryptoneur Gas Fees Calculator](https://www.cryptoneur.xyz/gas-fees-calculator) _Vypočítejte poplatky za palivo ve vaší místní měně pro různé typy transakcí na hlavní síti (Mainnet), Arbitrum a Polygonu._
## Související nástroje {#related-tools}
-- [Blocknative's Gas Platform](https://www.blocknative.com/gas) – _API pro odhadování poplatků za palivo podporované globální datovou platformou Blocknative mempool_
+- [Blocknative's Gas Platform](https://www.blocknative.com/gas) _API pro odhadování paliva, které využívá globální datovou platformu mempoolu od Blocknative_
+- [Gas Network](https://gas.network) Oracles pro palivo na blockchainu. Podpora pro více než 35 chainů.
-## Další informace {#further-reading}
+## Další čtení {#further-reading}
-- [Vysvětlení paliva na Ethereu](https://defiprime.com/gas)
-- [Snížení spotřeby paliva ve vašich chytrých kontraktech](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a)
+- [Vysvětlení ethereového paliva](https://defiprime.com/gas)
+- [Snížení spotřeby paliva vašich chytrých kontraktů](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a)
- [Strategie optimalizace paliva pro vývojáře](https://www.alchemy.com/overviews/solidity-gas-optimization)
-- [Dokumentace EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)
-- [Zdroje k EIP-1559 od Tima Beika](https://hackmd.io/@timbeiko/1559-resources)
-- [EIP-1559: Oddělování mechanismů od memů](https://web.archive.org/web/20241126205908/https://research.2077.xyz/eip-1559-separating-mechanisms-from-memes)
+- [Dokumentace k EIP-1559](https://eips.ethereum.org/EIPS/eip-1559).
+- [Zdroje Tima Beika k EIP-1559](https://hackmd.io/@timbeiko/1559-resources)
+- [EIP-1559: Oddělení mechanismů od memů](https://web.archive.org/web/20241126205908/https://research.2077.xyz/eip-1559-separating-mechanisms-from-memes)
diff --git a/public/content/translations/cs/developers/docs/ides/index.md b/public/content/translations/cs/developers/docs/ides/index.md
new file mode 100644
index 00000000000..c29a8874b24
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/ides/index.md
@@ -0,0 +1,64 @@
+---
+title: Integrovaná vývojová prostředí (IDE)
+description: Přečtěte si o webových a desktopových IDE pro vývoj na Ethereu, včetně Remixu, VS Code a oblíbených pluginů.
+lang: cs
+---
+
+Při nastavování [integrovaného vývojového prostředí (IDE)](https://wikipedia.org/wiki/Integrated_development_environment) je programování aplikací na Ethereu podobné jako programování jakéhokoli jiného softwarového projektu. Existuje spousta možností, takže si na konci dne vyberte IDE nebo kódový editor, který nejlépe vyhovuje vašim preferencím. S největší pravděpodobností bude nejlepší volbou IDE, které již používáte pro vývoj tradičního softwaru.
+
+## Webová IDE {#web-based-ides}
+
+Pokud si chcete pohrát s kódem před tím, než si [nastavíte lokální vývojové prostředí](/developers/local-environment/), tyto webové aplikace jsou speciálně vytvořeny pro vývoj chytrých kontraktů na Ethereu.
+
+**[Remix](https://remix.ethereum.org/)** - **_Webové IDE s vestavěnou statickou analýzou a testovacím blockchainovým virtuálním strojem_**
+
+- [Dokumentace](https://remix-ide.readthedocs.io/en/latest/#)
+- [Gitter](https://gitter.im/ethereum/remix)
+
+**[ChainIDE](https://chainide.com/)** - **_Cloudové IDE pro více blockchainů_**
+
+- [Dokumentace](https://chainide.gitbook.io/chainide-english-1/)
+- [Fórum nápovědy](https://forum.chainide.com/)
+
+**[Replit (Solidity Starter - Beta)](https://replit.com/@replit/Solidity-starter-beta)** - **_Přizpůsobitelné vývojové prostředí pro Ethereum s hot-reloadingem, kontrolou chyb a prvotřídní podporou testnetu_**
+
+- [Dokumentace](https://docs.replit.com/)
+
+**[Tenderly Sandbox](https://sandbox.tenderly.co/)** - **_Rychlé prototypovací prostředí, kde můžete psát, spouštět a ladit chytré kontrakty v prohlížeči pomocí Solidity a JavaScriptu_**
+
+**[EthFiddle](https://ethfiddle.com/)** - **_Webové IDE, které vám umožní psát, kompilovat a ladit váš chytrý kontrakt_**
+
+- [Gitter](https://gitter.im/loomnetwork/ethfiddle)
+
+## Desktopová IDE {#desktop-ides}
+
+Většina zavedených IDE má vytvořené pluginy pro zlepšení vývojového prostředí pro Ethereum. Minimálně poskytují zvýrazňování syntaxe pro [jazyky chytrých kontraktů](/developers/docs/smart-contracts/languages/).
+
+**Visual Studio Code -** **_Profesionální multiplatformní IDE s oficiální podporou Etherea_**
+
+- [Visual Studio Code](https://code.visualstudio.com/)
+- [Ukázky kódu](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md)
+- [GitHub](https://github.com/microsoft/vscode)
+
+**JetBrains IDEs (IntelliJ IDEA, atd.) -** **_Základní nástroje pro vývojáře softwaru a týmy_**
+
+- [JetBrains](https://www.jetbrains.com/)
+- [GitHub](https://github.com/JetBrains)
+- [IntelliJ Solidity](https://github.com/intellij-solidity/intellij-solidity/)
+
+**Remix Desktop -** **_Remix IDE na vašem lokálním počítači_**
+
+- [Stáhnout](https://github.com/ethereum/remix-desktop/releases)
+- [GitHub](https://github.com/ethereum/remix-desktop)
+
+## Pluginy a rozšíření {#plugins-extensions}
+
+- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) – Jazyk Ethereum Solidity pro Visual Studio Code
+- [Solidity + Hardhat pro VS Code](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) – Podpora pro Solidity a Hardhat od týmu Hardhat
+- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) – Formátovač kódu využívající Prettier
+
+## Další čtení {#further-reading}
+
+- [Ethereum IDEs](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _– Seznam Ethereum IDE od Alchemy_
+
+_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_
diff --git a/public/content/translations/cs/developers/docs/index.md b/public/content/translations/cs/developers/docs/index.md
index 44c82d43f8a..40a1a2be5f5 100644
--- a/public/content/translations/cs/developers/docs/index.md
+++ b/public/content/translations/cs/developers/docs/index.md
@@ -6,9 +6,9 @@ lang: cs
Tato dokumentace je navržena tak, aby vám pomohla s vývojem na Ethereu. Pokrývá Ethereum jako koncept, vysvětluje technologický stack Etherea a dokumentuje pokročilá témata pro složitější aplikace a případy použití.
-Jedná se o komunitní open-source projekt, takže neváhejte navrhovat nová témata, přidávat nový obsah a poskytovat příklady tam, kde si myslíte, že by to mohlo být užitečné. Veškerou dokumentaci lze upravovat přes GitHub – pokud si nejste jisti, jak na to, [postupujte podle těchto pokynů](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md).
+Jedná se o komunitní open-source projekt, takže neváhejte navrhovat nová témata, přidávat nový obsah a poskytovat příklady tam, kde si myslíte, že by to mohlo být užitečné. Veškerou dokumentaci lze upravit prostřednictvím GitHubu – pokud si nejste jisti, jak na to, [postupujte podle těchto pokynů](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md).
-## Moduly vývoje {#development-modules}
+## Vývojové moduly {#development-modules}
Pokud je toto váš první pokus o vývoj na Ethereu, doporučujeme začít od začátku a postupovat jako při čtení knihy.
@@ -16,10 +16,10 @@ Pokud je toto váš první pokus o vývoj na Ethereu, doporučujeme začít od z
@:"
+```
+
+## Provozování bootnodu {#run-a-bootnode}
+
+Bootnody jsou plnohodnotné uzly, které nejsou za NAT ([překlad síťových adres](https://www.geeksforgeeks.org/network-address-translation-nat/)). Každý plnohodnotný uzel může fungovat jako bootnode, pokud je veřejně dostupný.
+
+Když spustíte uzel, měl by se vám zobrazit váš [enode](/developers/docs/networking-layer/network-addresses/#enode), což je veřejný identifikátor, který mohou ostatní použít k připojení k vašemu uzlu.
+
+Enode se obvykle regeneruje při každém restartu, takže se podívejte do dokumentace vašeho klienta, jak vygenerovat trvalý enode pro váš bootnode.
+
+Abyste byli dobrým bootnodem, je dobré navýšit maximální počet peerů, kteří se k němu mohou připojit. Provozování bootnodu s mnoha peery výrazně zvýší nároky na šířku pásma.
+
+## Dostupné bootnody {#available-bootnodes}
+
+Seznam vestavěných bootnodů v go-ethereum naleznete [zde](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23). Tyto bootnody jsou spravovány nadací Ethereum a týmem go-ethereum.
+
+K dispozici jsou i další seznamy bootnodů spravované dobrovolníky. Ujistěte se prosím, že vždy zahrnete alespoň jeden oficiální bootnode, jinak byste se mohli stát obětí eclipse útoku.
diff --git a/public/content/translations/cs/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/translations/cs/developers/docs/nodes-and-clients/client-diversity/index.md
new file mode 100644
index 00000000000..b904212d18a
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/nodes-and-clients/client-diversity/index.md
@@ -0,0 +1,132 @@
+---
+title: Rozmanitost klientů
+description: Vysvětlení důležitosti diverzity klientů Etherea na vysoké úrovni.
+lang: cs
+sidebarDepth: 2
+---
+
+Chování uzlu sítě Ethereum je řízeno klientským softwarem, který na něm běží. Existuje několik klientů sítě Ethereum na produkční úrovni, přičemž každý z nich je vyvíjen a udržován v různých jazycích samostatnými týmy. Klienti jsou vytvořeni podle společné specifikace, která zajišťuje, že mezi sebou bezproblémově komunikují, mají stejnou funkcionalitu a poskytují ekvivalentní uživatelskou zkušenost. V současné době však distribuce klientů napříč uzly není dostatečně rovnoměrná, aby se toto posílení sítě využilo v plném rozsahu. V ideálním případě by se uživatelé měli zhruba rovnoměrně rozdělit mezi různé klienty, aby síti zajistili co největší diverzitu klientů.
+
+## Předpoklady {#prerequisites}
+
+Pokud ještě nerozumíte tomu, co jsou uzly a klienti, podívejte se na [uzly a klienty](/developers/docs/nodes-and-clients/). [Exekuční](/glossary/#execution-layer) a [konsensuální](/glossary/#consensus-layer) vrstvy jsou definovány ve slovníku.
+
+## Proč existuje více klientů? {#why-multiple-clients}
+
+Existuje více nezávisle vyvíjených a udržovaných klientů, protože diverzita klientů činí síť odolnější vůči útokům a chybám. Více klientů je silnou stránkou, kterou má pouze Ethereum – ostatní blockchainy se spoléhají na neomylnost jediného klienta. Nestačí však mít k dispozici pouze více klientů, musí je přijmout komunita a celkový počet aktivních uzlů musí být mezi nimi relativně rovnoměrně rozložen.
+
+## Proč je diverzita klientů důležitá? {#client-diversity-importance}
+
+Existence mnoha nezávisle vyvíjených a udržovaných klientů je pro zdraví decentralizované sítě životně důležitá. Pojďme se podívat na důvody, proč tomu tak je.
+
+### Chyby {#bugs}
+
+Chyba v jednotlivém klientovi představuje pro síť menší riziko, když představuje menšinu uzlů sítě Ethereum. Při zhruba rovnoměrném rozložení uzlů mezi mnoho klientů je pravděpodobnost, že by většina klientů trpěla společným problémem, malá, a síť je díky tomu robustnější.
+
+### Odolnost vůči útokům {#resilience}
+
+Diverzita klientů také nabízí odolnost vůči útokům. Například útok, který [přiměje konkrétního klienta](https://twitter.com/vdWijden/status/1437712249926393858) k přechodu na konkrétní větev řetězce, má malou šanci na úspěch, protože ostatní klienti pravděpodobně nebudou zneužitelní stejným způsobem a kanonický řetězec zůstane neporušený. Nízká diverzita klientů zvyšuje riziko spojené s hackem dominantního klienta. Diverzita klientů se již osvědčila jako důležitá obrana proti škodlivým útokům na síť. Například útok typu denial-of-service v Šanghaji v roce 2016 byl možný, protože útočníci dokázali přimět dominantního klienta (Geth) k provedení pomalé I/O operace na disku desítky tisíckrát za blok. Protože byly online i alternativní klienti, kteří tuto zranitelnost nesdíleli, bylo Ethereum schopno útoku odolat a pokračovat v provozu, zatímco byla opravena zranitelnost v Gethu.
+
+### Finalita u důkazu podílem {#finality}
+
+Chyba v konsensuálním klientovi, který by používalo více než 33 % uzlů sítě Ethereum, by mohla zabránit finalizaci konsensuální vrstvy, což znamená, že by uživatelé nemohli věřit, že transakce nebudou v určitém okamžiku vráceny nebo změněny. To by bylo velmi problematické pro mnoho aplikací postavených na Ethereu, zejména pro DeFi.
+
+
+
+Naučte se vyvíjet pro Ethereum v programovacím jazyce Delphi
+
+
+
+Na platformě Ethereum můžete vytvářet decentralizované aplikace (neboli dapps), které využívají výhody kryptoměn a blockchainové technologie. Tyto aplikace mohou být důvěryhodné, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Tyto aplikace mohou kontrolovat digitální aktiva, a tím vytvářet nové druhy finančních aplikací. Mohou být decentralizované, což znamená, že je nemůže ovládat jediná entita nebo osoba a že jsou téměř necenzurovatelné.
+
+Vytvářejte decentralizované aplikace na Ethereu a interagujte s chytrými kontrakty pomocí programovacího jazyka Delphi!
+
+## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-the-solidity-language}
+
+**Podnikněte první kroky k integraci Delphi s Ethereem**
+
+Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers](/developers/).
+
+- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## Odkazy a reference pro začátečníky {#beginner-references-and-links}
+
+**Představujeme knihovnu Delphereum**
+
+- [Co je Delphereum?](https://github.com/svanas/delphereum/blob/master/README.md)
+- [Připojení Delphi k místnímu (in-memory) blockchainu](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0)
+- [Připojení Delphi k hlavní síti Ethereum](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83)
+- [Připojení Delphi k chytrým kontraktům](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1)
+
+**Chcete přeskočit nastavení a přejít přímo na ukázky?**
+
+- [Chytrý kontrakt a Delphi za 3 minuty – část 1](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d)
+- [Chytrý kontrakt a Delphi za 3 minuty – část 2](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b)
+
+## Články pro pokročilé {#intermediate-articles}
+
+- [Generování podpisu zprávy podepsané Ethereem v Delphi](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b)
+- [Převádění etheru pomocí Delphi](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4)
+- [Převádění tokenů ERC-20 pomocí Delphi](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d)
+
+## Pokročilé vzory použití {#advanced-use-patterns}
+
+- [Delphi a Ethereum Name Service (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7)
+- [QuikNode, Ethereum a Delphi](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23)
+- [Delphi a Ethereum Dark Forest](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93)
+- [Směna jednoho tokenu za jiný v Delphi](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7)
+
+Hledáte další informační zdroje? Podívejte se na [ethereum.org/developers](/developers/).
diff --git a/public/content/translations/cs/developers/docs/programming-languages/dot-net/index.md b/public/content/translations/cs/developers/docs/programming-languages/dot-net/index.md
new file mode 100644
index 00000000000..a015a3f10cc
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/programming-languages/dot-net/index.md
@@ -0,0 +1,86 @@
+---
+title: Ethereum pro vývojáře v .NET
+description: Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na .NET
+lang: cs
+incomplete: true
+---
+
+Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na .NET
+
+Na platformě Ethereum můžete vytvářet decentralizované aplikace (neboli dapps), které využívají výhody kryptoměn a blockchainové technologie. Tyto aplikace mohou být důvěryhodné, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Tyto aplikace mohou kontrolovat digitální aktiva, a tím vytvářet nové druhy finančních aplikací. Mohou být decentralizované, což znamená, že je nemůže ovládat jediná entita nebo osoba a že jsou téměř necenzurovatelné.
+
+Sestavte decentralizované aplikace na Ethereu a komunikujte s chytrými kontrakty pomocí nástrojů a jazyků od Microsoftu - Podpora C#, #Visual Basic .NET, F# na nástrojích jako VSCode a Visual Studio, s použitím .NET Framework/.NET Core/.NET standard. Nasaďte Ethereum blockchain na Azure pomocí Microsoft Azure Blockchainu během několika minut. Přiveďte lásku .NET na platformu Ethereum!
+
+## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-the-solidity-language}
+
+**Udělejte své první kroky k integraci .NET s Ethereem**
+
+Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers](/developers/).
+
+- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## Odkazy a reference pro začátečníky {#beginner-references-and-links}
+
+**Představení knihovny Nethereum podpory Solidity ve VS Code**
+
+- [Nethereum, Začínáme](https://docs.nethereum.com/en/latest/getting-started/)
+- [Instalace VS Code Solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity)
+- [Pracovní postup .NET vývojáře pro vytváření a volání chytrých kontraktů na Ethereu](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2)
+- [Integrace chytrých kontraktů s Nethereum](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm)
+- [Propojení .NET a chytrých kontraktů na blockchainu Etherea s Nethereum](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933), také v [中文版](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1)
+- [Nethereum – open-source .NET integrační knihovna pro blockchain](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/)
+- [Zápis transakcí Etherea do SQL databáze pomocí Nethereum](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36)
+- [Podívejte se, jak snadno nasadit chytré kontrakty na Ethereu pomocí C# a Visual Studia](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c)
+
+**Chcete přeskočit nastavení a přejít přímo na ukázky?**
+
+- [Playground](http://playground.nethereum.com/) – interagujte s Ethereem a naučte se, jak používat Nethereum v prohlížeči.
+ - Dotaz na zůstatek na účtu [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001)
+ - Dotaz na zůstatek na ERC20 chytrém kontraktu [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004)
+ - Převod etherů na účet [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id/2003)
+ - ... A více!
+
+## Články pro pokročilé {#intermediate-articles}
+
+- [Nethereum pracovní sešit / Seznam ukázek](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/)
+- [Nasaďte si vlastní vývojové testnety](https://github.com/Nethereum/Testchains)
+- [Plugin VSCode Codegen pro Solidity](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/)
+- [Unity a Ethereum: Proč a jak](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how)
+- [Vytvoření webového API ASP.NET Core pro Ethereum dapps](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/)
+- [Použití Nethereum Web3 k implementaci systému pro sledování dodavatelského řetězce](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4)
+- [Zpracování bloků v Nethereum](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/) s [ukázkou pro C# Playground](http://playground.nethereum.com/csharp/id/1025)
+- [Streamování přes websocket v Nethereum](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/)
+- [Kaleido a Nethereum](https://kaleido.io/kaleido-and-nethereum/)
+- [Quorum a Nethereum](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md)
+
+## Pokročilé vzory použití {#advanced-use-patterns}
+
+- [Azure Key Vault a Nethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum)
+- [Nethereum.DappHybrid](https://github.com/Nethereum/Nethereum.DappHybrid)
+- [Referenční architektura backendu Ujo Nethereum](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/)
+
+## .NET projekty, nástroje a další zajímavosti {#dot-net-projects-tools-and-other-fun-stuff}
+
+- [Nethereum Playground](http://playground.nethereum.com/) – _kompilujte, vytvářejte a spouštějte úryvky kódu Nethereum v prohlížeči_
+- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) – _Nethereum codegen s UI v Blazor_
+- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) – _lehký .NET Wasm SPA prohlížeč blockchainu a jednoduchá peněženka_
+- [Wonka Business Rules Engine](https://docs.nethereum.com/en/latest/wonka/) – _engine pro obchodní pravidla (pro platformy .NET i Ethereum), který je ze své podstaty řízen metadaty_
+- [Nethermind](https://github.com/NethermindEth/nethermind) – _klient Etherea v .NET Core pro Linux, Windows a macOS_
+- [eth-utils](https://github.com/ethereum/eth-utils/) - _pomocné funkce pro práci s kódovými bázemi souvisejícími s Ethereem_
+- [TestChains](https://github.com/Nethereum/TestChains) – _předkonfigurované .NET devchainy pro rychlou odezvu (PoA)_
+
+Hledáte další informační zdroje? Podívejte se na [ethereum.org/developers](/developers/).
+
+## Přispěvatelé .NET komunity {#dot-net-community-contributors}
+
+My v Nethereum se většinou scházíme na [Gitteru](https://gitter.im/Nethereum/Nethereum), kde se každý může ptát a odpovídat na otázky, získat pomoc nebo prostě jen tak relaxovat. Neváhejte vytvořit PR nebo otevřít issue v [repozitáři Nethereum na GitHubu](https://github.com/Nethereum), nebo si jen projděte mnoho vedlejších a ukázkových projektů, které máme. Najdete nás také na [Discordu](https://discord.gg/jQPrR58FxX)!
+
+Pokud s Nethermindem začínáte a potřebujete pomoc, připojte se na náš [Discord](http://discord.gg/PaCMRFdvWT). Naši vývojáři jsou připraveni zodpovědět vaše otázky. Neváhejte otevřít PR nebo nahlásit jakékoliv problémy v [repozitáři Nethermind na GitHubu](https://github.com/NethermindEth/nethermind).
+
+## Další souhrnné seznamy {#other-aggregated-lists}
+
+[Oficiální stránky Nethereum](https://nethereum.com/)
+[Oficiální stránky Nethermind](https://nethermind.io/)
diff --git a/public/content/translations/cs/developers/docs/programming-languages/elixir/index.md b/public/content/translations/cs/developers/docs/programming-languages/elixir/index.md
new file mode 100644
index 00000000000..d880f6e02a8
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/programming-languages/elixir/index.md
@@ -0,0 +1,55 @@
+---
+title: Ethereum pro Elixir vývojáře
+description: Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Elixiru.
+lang: cs
+incomplete: false
+---
+
+Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Elixiru.
+
+Na platformě Ethereum můžete vytvářet decentralizované aplikace (neboli dapps), které využívají výhody kryptoměn a blockchainové technologie. Tyto aplikace nevyžadují, abyste jim důvěřovali, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Mohou kontrolovat digitální aktiva, a tím vytvářet nové druhy finančních aplikací. Mohou být decentralizované, což znamená, že je nemůže ovládat jediná entita nebo osoba a že jsou téměř necenzurovatelné.
+
+## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-solidity}
+
+**Udělejte první kroky k integraci Elixiru s Ethereem**
+
+Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers](/developers/).
+
+- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## Články pro začátečníky {#beginner-articles}
+
+- [Konečně pochopení účtů na Ethereu](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe)
+- [Ethers – prvotřídní Web3 knihovna pro Ethereum v Elixiru](https://medium.com/@alisinabh/announcing-ethers-a-first-class-ethereum-web3-library-for-elixir-1d64e9409122)
+
+## Články pro pokročilé {#intermediate-articles}
+
+- [Jak podepsat surové transakce ethereových kontraktů pomocí Elixiru](https://kohlerjp.medium.com/how-to-sign-raw-ethereum-contract-transactions-with-elixir-f8822bcc813b)
+- [Chytré kontrakty na Ethereu a Elixir](https://medium.com/agile-alpha/ethereum-smart-contracts-and-elixir-c7c4b239ddb4)
+
+## Elixir projekty a nástroje {#elixir-projects-and-tools}
+
+### Aktivní {#active}
+
+- [block_keys](https://github.com/ExWeb3/block_keys) – _implementace BIP32 a BIP44 v Elixiru (hierarchie více účtů pro deterministické peněženky)_
+- [ethereumex](https://github.com/mana-ethereum/ethereumex) – _Elixir JSON-RPC klient pro blockchain Etherea_
+- [ethers](https://github.com/ExWeb3/elixir_ethers) – _komplexní Web3 knihovna pro interakci s chytrými kontrakty na Ethereu pomocí Elixiru_
+- [ethers_kms](https://github.com/ExWeb3/elixir_ethers_kms) – _KMS knihovna podepisovače pro Ethers (podepisování transakcí pomocí AWS KMS)_
+- [ex_abi](https://github.com/poanetwork/ex_abi) – _implementace parseru/dekodéru/kodéru Ethereum ABI v Elixiru_
+- [ex_keccak](https://github.com/ExWeb3/ex_keccak) – _knihovna Elixiru pro výpočet hašů Keccak SHA3-256 pomocí NIF postaveného na Rust crate tiny-keccak_
+- [ex_rlp](https://github.com/mana-ethereum/ex_rlp) – _implementace kódování RLP (Recursive Length Prefix) Etherea v Elixiru_
+
+### Archivované / Již neudržované {#archived--no-longer-maintained}
+
+- [eth](https://hex.pm/packages/eth) – _nástroje pro Ethereum v Elixiru_
+- [exw3](https://github.com/hswick/exw3) – _vysokoúrovňový Ethereum RPC klient pro Elixir_
+- [mana](https://github.com/mana-ethereum/mana) – _implementace plného uzlu Etherea napsaná v Elixiru_
+
+Hledáte další informační zdroje? Podívejte se na naši [domovskou stránku pro vývojáře](/developers/).
+
+## Přispěvatelé z komunity Elixiru {#elixir-community-contributors}
+
+[Kanál #ethereum na Slacku Elixiru](https://elixir-lang.slack.com/archives/C5RPZ3RJL) hostí rychle se rozrůstající komunitu a je vyhrazeným zdrojem pro diskuze o jakýchkoliv výše uvedených projektech a souvisejících tématech.
diff --git a/public/content/translations/cs/developers/docs/programming-languages/golang/index.md b/public/content/translations/cs/developers/docs/programming-languages/golang/index.md
new file mode 100644
index 00000000000..879ce8219c2
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/programming-languages/golang/index.md
@@ -0,0 +1,84 @@
+---
+title: Ethereum pro vývojáře v Go
+description: Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů v jazyce Go
+lang: cs
+incomplete: true
+---
+
+Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů v jazyce Go
+
+Použijte Ethereum k vytváření decentralizovaných aplikací (neboli "dapps"). Tyto aplikace mohou být důvěryhodné, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Jsou decentralizované, což znamená, že běží na síti peer-to-peer a neexistuje žádný jediný bod selhání. Nekontroluje je žádná jediná entita ani osoba a je téměř nemožné je cenzurovat. Mohou ovládat digitální aktiva, aby mohly vytvářet nové druhy aplikací.
+
+## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-solidity}
+
+**Udělejte své první kroky k integraci jazyka Go s Ethereem**
+
+Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers](/developers/).
+
+- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [Tutoriál ke kontraktům](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial)
+
+## Články a knihy pro začátečníky {#beginner-articles-and-books}
+
+- [Začínáme s Geth](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458)
+- [Použití Golang k připojení k Ethereu](https://www.youtube.com/watch?v=-7uChuO_VzM)
+- [Nasazení chytrých kontraktů na Ethereu pomocí Golang](https://www.youtube.com/watch?v=pytGqQmDslE)
+- [Podrobný průvodce testováním a nasazením chytrých kontraktů na Ethereu v Go](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78)
+- [eBook: Vývoj pro Ethereum s Go](https://goethereumbook.org/) – _Vyvíjejte aplikace pro Ethereum pomocí Go_
+
+## Články a dokumentace pro středně pokročilé {#intermediate-articles-and-docs}
+
+- [Dokumentace Go Ethereum](https://geth.ethereum.org/docs/) – _Dokumentace pro oficiální podporu jazyka Go v projektu Ethereum_
+- [Programátorská příručka Erigon](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) – _Ilustrovaný průvodce včetně stavového stromu, multi-proofs a zpracování transakcí_
+- [Erigon a bezestavové Ethereum](https://youtu.be/3-Mn7OckSus?t=394) – _Konference komunity Etherea 2020 (EthCC 3)_
+- [Erigon: optimalizace klientů Etherea](https://www.youtube.com/watch?v=CSpc1vZQW2Q) – _Devcon 4 2018_
+- [Go Ethereum GoDoc](https://godoc.org/github.com/ethereum/go-ethereum)
+- [Vytvoření dapp v Go pomocí Geth](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/)
+- [Práce se soukromou sítí Ethereum pomocí Golang a Geth](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php)
+- [Unit testování kontraktů Solidity na Ethereu s Go](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281)
+- [Rychlá reference pro používání Geth jako knihovny](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e)
+
+## Pokročilé vzory použití {#advanced-use-patterns}
+
+- [Simulovaný backend GETH](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top)
+- [Aplikace typu Blockchain jako služba využívající Ethereum a Quorum](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html)
+- [Distribuované úložiště IPFS a Swarm v blockchainových aplikacích Etherea](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html)
+- [Mobilní klienti: knihovny a Inproc uzly Ethereum](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes)
+- [Nativní dapps: Go bindings pro kontrakty Etherea](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts)
+
+## Go projekty a nástroje {#go-projects-and-tools}
+
+- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) – _Oficiální implementace protokolu Ethereum v Go_
+- [Analýza kódu Go Ethereum](https://github.com/ZtesoftCS/go-ethereum-code-analysis) – _Přehled a analýza zdrojového kódu Go Ethereum_
+- [Erigon](https://github.com/ledgerwatch/erigon) – _Rychlejší derivát Go Ethereum se zaměřením na archivní uzly_
+- [Golem](https://github.com/golemfactory/golem) – _Golem vytváří globální trh s výpočetním výkonem_
+- [Quorum](https://github.com/jpmorganchase/quorum) – _Implementace Etherea s kontrolou přístupu, která podporuje ochranu soukromí_
+- [Prysm](https://github.com/prysmaticlabs/prysm) – _Implementace Etherea 'Serenity' 2.0 v Go_
+- [Eth Tweet](https://github.com/yep/eth-tweet) – _Decentralizovaný Twitter: Mikroblogovací služba běžící na blockchainu Etherea_
+- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _Implementace v Golang a rozšíření specifikace Minimum Viable Plasma_
+- [Open Ethereum Mining Pool](https://github.com/sammy007/open-ethereum-pool) – _Open-source těžební pool pro Ethereum_
+- [Ethereum HD peněženka](https://github.com/miguelmota/go-ethereum-hdwallet) – _Odvození Ethereum HD peněženky v Go_
+- [Multi Geth](https://github.com/multi-geth/multi-geth) – _Podpora pro mnoho druhů sítí Ethereum_
+- [Geth lehký klient](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) – _Implementace Geth lehkého subprotokolu Etherea_
+- [Ethereum Golang SDK](https://github.com/everFinance/goether) – _Jednoduchá implementace peněženky Ethereum a utility v Golang_
+- [Covalent Golang SDK](https://github.com/covalenthq/covalent-api-sdk-go) – _Efektivní přístup k blockchainovým datům prostřednictvím Go SDK pro více než 200 blockchainů_
+
+Hledáte další informační zdroje? Podívejte se na [ethereum.org/developers](/developers/)
+
+## Přispěvatelé komunity Go {#go-community-contributors}
+
+- [Geth Discord](https://discordapp.com/invite/nthXNEv)
+- [Geth Gitter](https://gitter.im/ethereum/go-ethereum)
+- [Gophers Slack](https://invite.slack.golangbridge.org/) – [kanál #ethereum](https://gophers.slack.com/messages/C9HP1S9V2)
+- [StackExchange – Ethereum](https://ethereum.stackexchange.com/)
+- [Multi Geth Gitter](https://gitter.im/ethoxy/multi-geth)
+- [Ethereum Gitter](https://gitter.im/ethereum/home)
+- [Geth lehký klient Gitter](https://gitter.im/ethereum/light-client)
+
+## Další souhrnné seznamy {#other-aggregated-lists}
+
+- [Awesome Ethereum](https://github.com/btomashvili/awesome-ethereum)
+- [Consensys: Definitivní seznam vývojářských nástrojů pro Ethereum](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [Zdroj na GitHubu](https://github.com/ConsenSys/ethereum-developer-tools-list)
diff --git a/public/content/translations/cs/developers/docs/programming-languages/index.md b/public/content/translations/cs/developers/docs/programming-languages/index.md
new file mode 100644
index 00000000000..f30074129f9
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/programming-languages/index.md
@@ -0,0 +1,33 @@
+---
+title: Programovací jazyky
+description: Objevte vývojářské zdroje informací pro Ethereum v různých programovacích jazycích, včetně JavaScript, Python, Go, Rust a dalších.
+lang: cs
+---
+
+Častou mylnou představou je, že vývojáři musí psát [chytré kontrakty](/developers/docs/smart-contracts/), aby mohli stavět na Ethereu. To není pravda.
+Jednou z krás sítě Ethereum a její komunity je, že se můžete [zapojit](/community/) v téměř jakémkoli programovacím jazyce.
+
+Ethereum a jeho komunita podporují open source. Komunitní projekty - implementace klientů, API, vývojové frameworky, testovací nástroje - existují v široké škále jazyků.
+
+## Vyberte si jazyk {#data}
+
+Vyberte svůj oblíbený programovací jazyk a podívejte se na projekty, zdroje a virtuální komunity:
+
+- [Ethereum pro vývojáře v Dartu](/developers/docs/programming-languages/dart/)
+- [Ethereum pro vývojáře v Delphi](/developers/docs/programming-languages/delphi/)
+- [Ethereum pro vývojáře v .NET](/developers/docs/programming-languages/dot-net/)
+- [Ethereum pro vývojáře v Elixiru](/developers/docs/programming-languages/elixir/)
+- [Ethereum pro vývojáře v Go](/developers/docs/programming-languages/golang/)
+- [Ethereum pro vývojáře v Javě](/developers/docs/programming-languages/java/)
+- [Ethereum pro vývojáře v JavaScriptu](/developers/docs/programming-languages/javascript/)
+- [Ethereum pro vývojáře v Pythonu](/developers/docs/programming-languages/python/)
+- [Ethereum pro vývojáře v Ruby](/developers/docs/programming-languages/ruby/)
+- [Ethereum pro vývojáře v Rustu](/developers/docs/programming-languages/rust/)
+
+### Co když můj jazyk není podporován {#other-lang}
+
+Chcete-li přidat odkazy na zdroje informací nebo na virtuální komunitu pro další programovací jazyk, můžete o novou stránku požádat [otevřením „issue“](https://github.com/ethereum/ethereum-org-website/issues/new/choose).
+
+Pokud chcete psát kód pro komunikaci s blockchainem pomocí aktuálně nepodporovaného jazyka,
+můžete se k síti Ethereum připojit pomocí [rozhraní JSON-RPC](/developers/docs/apis/json-rpc/). Jakýkoliv programovací
+jazyk, který umí pracovat s TCP/IP, může toto rozhraní použít.
diff --git a/public/content/translations/cs/developers/docs/programming-languages/java/index.md b/public/content/translations/cs/developers/docs/programming-languages/java/index.md
new file mode 100644
index 00000000000..6cfe5b0255b
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/programming-languages/java/index.md
@@ -0,0 +1,64 @@
+---
+title: Ethereum pro vývojáře v Javě
+description: Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Javě
+lang: cs
+incomplete: true
+---
+
+Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Javě
+
+Na platformě Ethereum můžete vytvářet decentralizované aplikace (neboli dapps), které využívají výhody kryptoměn a blockchainové technologie. Tyto aplikace mohou být důvěryhodné, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Tyto aplikace mohou kontrolovat digitální aktiva, a tím vytvářet nové druhy finančních aplikací. Mohou být decentralizované, což znamená, že je nemůže ovládat jediná entita nebo osoba a že jsou téměř necenzurovatelné.
+
+## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-solidity}
+
+**Udělejte své první kroky k integraci Javy s Ethereem**
+
+Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers.](/developers/)
+
+- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## Práce s klienty Etherea {#working-with-ethereum-clients}
+
+Naučte se používat [Web3J](https://github.com/web3j/web3j) a Hyperledger Besu, dva přední Java Ethereum klienty
+
+- [Připojení ke klientovi pro Ethereum pomocí Javy, Eclipse a Web3J](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j)
+- [Správa účtu Ethereum pomocí Javy a Web3j](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j)
+- [Generování Java wrapperu z vašeho chytrého kontraktu](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract)
+- [Interakce s chytrým kontraktem Ethereum](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java)
+- [Naslouchání událostem chytrého kontraktu Ethereum](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java)
+- [Použití Besu (Pantheon), klienta pro Ethereum v Javě s Linuxem](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux)
+- [Spuštění uzlu Hyperledger Besu (Pantheon) v integračních testech v Javě](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests)
+- [Tahák na Web3j](https://kauri.io/web3j-cheat-sheet-\(java-ethereum\)/5dfa1ea941ac3d0001ce1d90/c)
+
+Naučte se používat [ethers-kt](https://github.com/Kr1ptal/ethers-kt), asynchronní, vysoce výkonnou knihovnu v Kotlinu pro interakci s blockchainy založenými na EVM. Cíleno na platformy JVM a Android.
+
+- [Převod tokenů ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt)
+- [Směna na UniswapV2 s nasloucháním událostem](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt)
+- [Sledování zůstatku ETH / ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt)
+
+## Články pro pokročilé {#intermediate-articles}
+
+- [Správa úložiště v aplikaci v Javě pomocí IPFS](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs)
+- [Správa tokenů ERC20 v Javě pomocí Web3j](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j)
+- [Správci transakcí Web3j](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers)
+
+## Pokročilé vzory použití {#advanced-use-patterns}
+
+- [Použití Eventeum k vytvoření datové mezipaměti chytrého kontraktu v Javě](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache)
+
+## Projekty a nástroje v Javě {#java-projects-and-tools}
+
+- [Web3J (knihovna pro interakci s klienty pro Ethereum)](https://github.com/web3j/web3j)
+- [ethers-kt (Asynchronní, vysoce výkonná knihovna pro Kotlin/Javu/Android pro blockchainy založené na EVM.)](https://github.com/Kr1ptal/ethers-kt)
+- [Eventeum (naslouchač událostí)](https://github.com/ConsenSys/eventeum)
+- [Mahuta (vývojářské nástroje pro IPFS)](https://github.com/ConsenSys/mahuta)
+
+Hledáte další informační zdroje? Podívejte se na [ethereum.org/developers.](/developers/)
+
+## Komunitní přispěvatelé pro Javu {#java-community-contributors}
+
+- [IO Builders](https://io.builders)
+- [Kauri](https://kauri.io)
diff --git a/public/content/translations/cs/developers/docs/programming-languages/javascript/index.md b/public/content/translations/cs/developers/docs/programming-languages/javascript/index.md
new file mode 100644
index 00000000000..503807f51ca
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/programming-languages/javascript/index.md
@@ -0,0 +1,72 @@
+---
+title: Ethereum pro vývojáře v JavaScriptu
+description: Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na JavaScriptu.
+lang: cs
+---
+
+JavaScript je jedním z nejpopulárnějších jazyků v ekosystému Ethereum. Ve skutečnosti existuje [tým](https://github.com/ethereumjs) věnovaný tomu, aby co nejvíce z Etherea přenesl do JavaScriptu.
+
+Existují příležitosti k psaní v JavaScriptu (nebo něčem blízkém) na [všech úrovních zásobníku](/developers/docs/ethereum-stack/).
+
+## Interakce s Ethereem {#interact-with-ethereum}
+
+### JavaScriptové API knihovny {#javascript-api-libraries}
+
+Pokud byste chtěli psát v JavaScriptu pro dotazování blockchainu, odesílání transakcí a další, nejpohodlnější způsob, jak to udělat, je použít [knihovnu JavaScript API](/developers/docs/apis/javascript/). Tato API umožňují vývojářům snadno komunikovat s [uzly v síti Ethereum](/developers/docs/nodes-and-clients/).
+
+Tyto knihovny můžete použít k interakci s chytrými kontrakty na Ethereu, takže je možné vytvořit dapp, kde pro interakci s již existujícími kontrakty použijete pouze JavaScript.
+
+**Podívejte se**
+
+- [Web3.js](https://web3js.readthedocs.io)
+- [Ethers.js](https://ethers.org) – _zahrnuje implementaci peněženky Ethereum a utility v JavaScriptu a TypeScriptu._
+- [viem](https://viem.sh) – _rozhraní TypeScriptu pro Ethereum, které poskytuje nízkoúrovňové bezstavové primitivy pro interakci s Ethereem._
+- [Drift](https://ryangoree.github.io/drift/) – _meta-knihovna TypeScriptu s vestavěným ukládáním do mezipaměti, háčky a testovacími maketami pro snadný vývoj na Ethereu napříč knihovnami web3._
+
+### Chytré kontrakty {#smart-contracts}
+
+Pokud jste JavaScript vývojář a chcete psát svůj vlastní chytrý kontrakt, možná se budete chtít seznámit se [Solidity](https://solidity.readthedocs.io). Jedná se o nejpopulárnější jazyk pro chytré kontrakty a je syntakticky podobný JavaScriptu, což může usnadnit jeho učení.
+
+Více o [chytrých kontraktech](/developers/docs/smart-contracts/).
+
+## Pochopení protokolu {#understand-the-protocol}
+
+### Virtuální stroj Etherea {#the-ethereum-virtual-machine}
+
+Existuje JavaScriptová implementace [virtuálního stroje Etherea](/developers/docs/evm/). Podporuje nejnovější pravidla větví. Pravidla větví odkazují na změny provedené v EVM v důsledku plánovaných upgradů.
+
+Je rozdělen do různých JavaScriptových balíčků, které si můžete prohlédnout, abyste lépe porozuměli:
+
+- Účty
+- Bloky
+- Samotný blockchain
+- Transakce
+- A další...
+
+To vám pomůže pochopit věci jako "jaká je datová struktura účtu?".
+
+Pokud dáváte přednost čtení kódu, tento JavaScript může být skvělou alternativou ke čtení naší dokumentace.
+
+**Prozkoumejte EVM**
+[`@ethereumjs/evm`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/evm)
+
+### Uzly a klienti {#nodes-and-clients}
+
+Klient Ethereumjs je v aktivním vývoji, který vám umožní ponořit se do toho, jak fungují klienti Etherea, v jazyce, kterému rozumíte: v JavaScriptu!
+
+**Prozkoumejte klienta**
+[`@ethereumjs/client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client)
+
+## Další projekty {#other-projects}
+
+V zemi Etherea a JavaScriptu se toho děje spousta, včetně:
+
+- knihovny s utilitami pro peněženky.
+- nástroje pro generování, import a export klíčů Ethereum.
+- implementace `merkle-patricia-tree` – datové struktury popsané ve žluté knize Etherea.
+
+Ponořte se do toho, co vás nejvíce zajímá, v [repozitáři EthereumJS](https://github.com/ethereumjs)
+
+## Další čtení {#further-reading}
+
+_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_
diff --git a/public/content/translations/cs/developers/docs/programming-languages/python/index.md b/public/content/translations/cs/developers/docs/programming-languages/python/index.md
new file mode 100644
index 00000000000..149709ef074
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/programming-languages/python/index.md
@@ -0,0 +1,99 @@
+---
+title: Ethereum pro vývojáře v Pythonu
+description: Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Pythonu
+lang: cs
+incomplete: true
+---
+
+Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Pythonu
+
+Na platformě Ethereum můžete vytvářet decentralizované aplikace (neboli dapps), které využívají výhody kryptoměn a blockchainové technologie. Tyto aplikace mohou být důvěryhodné, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Tyto aplikace mohou kontrolovat digitální aktiva, a tím vytvářet nové druhy finančních aplikací. Mohou být decentralizované, což znamená, že je nemůže ovládat jediná entita nebo osoba a že jsou téměř necenzurovatelné.
+
+## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-solidity}
+
+**Udělejte své první kroky k integraci Pythonu s Ethereem**
+
+Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers](/developers/).
+
+- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [Zpráva o stavu Pythonu v blockchainu v roce 2023](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023)
+
+## Články pro začátečníky {#beginner-articles}
+
+- [Přehled web3.py](https://web3py.readthedocs.io/en/latest/overview.html)
+- [Prohlídka ekosystému Ethereum a Pythonu](https://snakecharmers.ethereum.org/python-ecosystem/)
+- [Průvodce Ethereum pro (Python) vývojáře](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/)
+- [Prize-Worthy: Průvodce hackathonem pro Ethereum a Python](https://snakecharmers.ethereum.org/prize-worthy/)
+- [Úvod do chytrých kontraktů s Vyper](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/)
+- [Jak vyvíjet kontrakt pro Ethereum pomocí Python Flask?](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e)
+- [Úvod do Web3.py · Ethereum pro vývojáře v Pythonu](https://www.dappuniversity.com/articles/web3-py-intro)
+- [Jak volat funkci chytrého kontraktu pomocí Python a web3.py](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py)
+
+## Články pro pokročilé {#intermediate-articles}
+
+- [Přátelé web3.py: Úvod do Ape](https://snakecharmers.ethereum.org/intro-to-ape/)
+- [Vývoj dapp pro programátory v Pythonu](https://levelup.gitconnected.com/dapps-development-for-python-developers-f52b32b54f28)
+- [Vytvoření rozhraní Ethereum v Pythonu: Část 1](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d)
+- [Chytré kontrakty na Ethereum v Pythonu: komplexní průvodce (tak trochu)](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988)
+
+## Pokročilé vzory použití {#advanced-use-patterns}
+
+- [Vzory web3.py: Odběry událostí v reálném čase](https://snakecharmers.ethereum.org/subscriptions/)
+- [Vzory web3.py: WebSocketProvider](https://snakecharmers.ethereum.org/websocketprovider/)
+- [Kompilace, nasazení a volání chytrého kontraktu na Ethereum pomocí Pythonu](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/)
+- [Analyzujte chytré kontrakty Solidity pomocí Slither](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither)
+- [Blockchain Fintech Tutoriál: Půjčování a vypůjčování s Pythonem](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/)
+
+## Archivované články
+
+- [Nasaďte svůj vlastní ERC20 token s Pythonem a Brownie](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58)
+- [Použití Brownie a Pythonu k nasazení chytrých kontraktů](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp)
+- [Vytváření NFT na OpenSea pomocí Brownie](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/)
+
+## Projekty a nástroje pro Python {#python-projects-and-tools}
+
+### Aktivní: {#active}
+
+- [Web3.py](https://github.com/ethereum/web3.py) - _knihovna Pythonu pro interakci s Ethereum_
+- [Vyper](https://github.com/ethereum/vyper/) - _Pythonický jazyk pro chytré kontrakty pro EVM_
+- [Ape](https://github.com/ApeWorX/ape) - _nástroj pro vývoj chytrých kontraktů pro Pythonisty, datové vědce a bezpečnostní profesionály_
+- [py-evm](https://github.com/ethereum/py-evm) - _implementace Ethereum Virtual Machine_
+- [eth-tester](https://github.com/ethereum/eth-tester) - _nástroje pro testování aplikací založených na Ethereum_
+- [eth-utils](https://github.com/ethereum/eth-utils/) - _pomocné funkce pro práci s kódovými bázemi souvisejícími s Ethereem_
+- [py-solc-x](https://pypi.org/project/py-solc-x/) - _Python wrapper pro kompilátor solc pro Solidity s podporou 0.5.x_
+- [pymaker](https://github.com/makerdao/pymaker) - _Python API pro kontrakty Maker_
+- [siwe](https://github.com/signinwithethereum/siwe-py) - _Sign in with Ethereum (siwe) pro Python_
+- [Web3 DeFi for Ethereum integrations](https://github.com/tradingstrategy-ai/web3-ethereum-defi) - _Balíček Pythonu s připravenými integracemi pro ERC-20, Uniswap a další populární projekty_
+- [Wake](https://getwake.io) - _All-in-one Python framework pro testování kontraktů, fuzzing, nasazení, skenování zranitelností a navigaci v kódu (jazykový server – [Tools for Solidity](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_
+
+### Archivováno / Již se neudržuje: {#archived--no-longer-maintained}
+
+- [Trinity](https://github.com/ethereum/trinity) - _Python klient pro Ethereum_
+- [Mamba](https://github.com/arjunaskykok/mamba) - _framework pro psaní, kompilaci a nasazení chytrých kontraktů napsaných v jazyce Vyper_
+- [Brownie](https://github.com/eth-brownie/brownie) - _Python framework pro nasazení, testování a interakci s chytrými kontrakty Etherea_
+- [pydevp2p](https://github.com/ethereum/pydevp2p) - _implementace P2P stacku Etherea_
+- [py-wasm](https://github.com/ethereum/py-wasm) - _implementace interpreta WebAssembly v Pythonu_
+
+Hledáte další informační zdroje? Podívejte se na [ethereum.org/developers](/developers/).
+
+## Projekty využívající nástroje pro Python {#projects-using-python-tooling}
+
+Následující projekty založené na Ethereu používají nástroje uvedené na této stránce. Související open-source repozitáře slouží jako dobrý referenční zdroj pro příklady kódu a osvědčené postupy.
+
+- [Yearn Finance](https://yearn.finance/) a [repozitář Yearn Vault Contracts](https://github.com/yearn/yearn-vaults)
+- [Curve](https://www.curve.finance/) a [repozitář chytrých kontraktů Curve](https://github.com/curvefi/curve-contract)
+- [BadgerDAO](https://badger.com/) a [chytré kontrakty využívající sadu nástrojů Brownie](https://github.com/Badger-Finance/badger-system)
+- [Sushi](https://sushi.com/) používá [Python při správě a nasazování svých vestingových kontraktů](https://github.com/sushiswap/sushi-vesting-protocols)
+- [Alpha Finance](https://alphafinance.io/), známá díky Alpha Homora, používá [Brownie k testování a nasazení chytrých kontraktů](https://github.com/AlphaFinanceLab/alpha-staking-contract)
+
+## Diskuse komunity Pythonu {#python-community-contributors}
+
+- [Discord komunity Ethereum a Pythonu](https://discord.gg/9zk7snTfWe) pro diskuzi o Web3.py a dalších frameworcích pro Python
+- [Discord pro Vyper](https://discord.gg/SdvKC79cJk) pro diskuzi o programování chytrých kontraktů v jazyce Vyper
+
+## Další souhrnné seznamy {#other-aggregated-lists}
+
+Wiki pro Vyper má [neuvěřitelný seznam zdrojů pro Vyper](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources)
\ No newline at end of file
diff --git a/public/content/translations/cs/developers/docs/programming-languages/ruby/index.md b/public/content/translations/cs/developers/docs/programming-languages/ruby/index.md
new file mode 100644
index 00000000000..d58e3e33cf3
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/programming-languages/ruby/index.md
@@ -0,0 +1,60 @@
+---
+title: Ethereum pro vývojáře v Ruby
+description: Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Ruby.
+lang: cs
+incomplete: false
+---
+
+Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Ruby.
+
+Na platformě Ethereum můžete vytvářet decentralizované aplikace (neboli dapps), které využívají výhody kryptoměn a blockchainové technologie. Tyto aplikace nevyžadují, abyste jim důvěřovali, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Mohou kontrolovat digitální aktiva, a tím vytvářet nové druhy finančních aplikací. Mohou být decentralizované, což znamená, že je nemůže ovládat jediná entita nebo osoba a že jsou téměř necenzurovatelné.
+
+## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-solidity}
+
+**Podnikněte první kroky k integraci Ruby s Ethereem**
+
+Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers](/developers/).
+
+- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## Články pro začátečníky {#beginner-articles}
+
+- [Konečně pochopení účtů na Ethereu](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe)
+- [Konečně ověřování uživatelů Rails pomocí MetaMask](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj)
+- [Jak se připojit k síti Ethereum pomocí Ruby](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby)
+- [Jak vygenerovat novou adresu Ethereum v Ruby](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby)
+
+## Články pro pokročilé {#intermediate-articles}
+
+- [Blockchainová aplikace s Ruby](https://www.nopio.com/blog/blockchain-app-ruby/)
+- [Použití Ruby, připojeného k Ethereu, ke spuštění chytrého kontraktu](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9)
+
+## Projekty a nástroje Ruby {#ruby-projects-and-tools}
+
+### Aktivní {#active}
+
+- [eth.rb](https://github.com/q9f/eth.rb) – _knihovna Ruby a klient RPC pro správu účtů, zpráv a transakcí Etherea_
+- [keccak.rb](https://github.com/q9f/keccak.rb) – _haš Keccak (SHA3) používaný Ethereem_
+- [siwe-ruby](https://github.com/signinwithethereum/siwe-ruby) – _implementace Sign-In with Ethereum v Ruby_
+- [siwe-rails](https://github.com/signinwithethereum/siwe-rails) – _gem pro Rails, který přidává lokální cesty pro přihlášení pomocí SIWE_
+- [siwe-rails-examples](https://github.com/signinwithethereum/siwe-rails-examples) – _příklad SIWE s použitím Ruby on Rails s vlastním kontrolerem_
+- [omniauth-siwe](https://github.com/signinwithethereum/omniauth-siwe) – _strategie OmniAuth pro Sign In With Ethereum (SIWE)_
+- [omniauth-nft](https://github.com/valthon/omniauth-nft) – _strategie OmniAuth pro ověřování prostřednictvím vlastnictví NFT_
+- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) – _šablona Ethereum on Rails, která umožňuje připojit MetaMask k Ruby on Rails_
+
+### Archivované / Již neudržované {#archived--no-longer-maintained}
+
+- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) – _volání RPC metod uzlu Ethereum pomocí Ruby_
+- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) – _knihovna Ruby pro generování ETH adres z hierarchicky deterministické peněženky podle standardu BIP32_
+- [etherlite](https://github.com/budacom/etherlite) – _integrace Etherea pro Ruby on Rails_
+- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) – _klient Etherea v Ruby používající rozhraní JSON-RPC pro odesílání transakcí, vytváření kontraktů a interakci s nimi a také užitečná sada nástrojů pro práci s uzlem Ethereum_
+- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) – _implementuje strategii poskytovatele Etherea pro OmniAuth_
+
+Hledáte další informační zdroje? Podívejte se na naši [domovskou stránku pro vývojáře](/developers/).
+
+## Přispěvatelé komunity Ruby {#ruby-community-contributors}
+
+[Telegramová skupina Ethereum Ruby](https://t.me/ruby_eth) hostí rychle rostoucí komunitu a je specializovaným zdrojem pro diskuse o všech výše uvedených projektech a souvisejících tématech.
diff --git a/public/content/translations/cs/developers/docs/programming-languages/rust/index.md b/public/content/translations/cs/developers/docs/programming-languages/rust/index.md
new file mode 100644
index 00000000000..834df3907fa
--- /dev/null
+++ b/public/content/translations/cs/developers/docs/programming-languages/rust/index.md
@@ -0,0 +1,65 @@
+---
+title: Ethereum pro vývojáře v Rustu
+description: Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Rustu
+lang: cs
+incomplete: true
+---
+
+Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Rustu
+
+Na platformě Ethereum můžete vytvářet decentralizované aplikace (neboli dapps), které využívají výhody kryptoměn a blockchainové technologie. Tyto aplikace mohou být důvěryhodné, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Tyto aplikace mohou kontrolovat digitální aktiva, a tím vytvářet nové druhy finančních aplikací. Mohou být decentralizované, což znamená, že je nemůže ovládat jediná entita nebo osoba a že jsou téměř necenzurovatelné.
+
+## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-solidity}
+
+**Udělejte své první kroky k integraci Rustu s Ethereem**
+
+Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers](/developers/).
+
+- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+
+## Články pro začátečníky {#beginner-articles}
+
+- [Klient Ethereum v Rustu](https://openethereum.github.io/) \* **Upozornění: OpenEthereum [je zastaralý](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) a již není udržován.** Používejte jej opatrně a nejlépe přejděte na jinou implementaci klienta.
+- [Posílání transakcí do Etherea pomocí Rustu](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/)
+- [Postupný návod, jak psát kontrakty v Rustu a Wasmu pro Kovan](https://github.com/paritytech/pwasm-tutorial)
+
+## Články pro pokročilé {#intermediate-articles}
+
+## Pokročilé vzory použití {#advanced-use-patterns}
+
+- [Knihovna pwasm_ethereum externs pro interakci se sítěmi podobnými Ethereu](https://github.com/openethereum/pwasm-ethereum)
+
+- [Sestavení decentralizovaného chatu pomocí JavaScriptu a Rustu](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52)
+
+- [Sestavení decentralizované todo aplikace pomocí Vue.js a Rustu](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb)
+
+- [Sestavení blockchainu v Rustu](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/)
+
+## Projekty a nástroje v Rustu {#rust-projects-and-tools}
+
+- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) - _Sbírka externů pro interakci se sítěmi podobnými Ethereu_
+- [Lighthouse](https://github.com/sigp/lighthouse) - _Rychlý klient konsensuální vrstvy Etherea_
+- [Ethereum WebAssembly](https://ewasm.readthedocs.io/en/mkdocs/) - _Navrhovaný redesign exekuční vrstvy chytrých kontraktů Etherea pomocí deterministické podmnožiny WebAssembly_
+- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _Reference OASIS API_
+- [Solaris](https://github.com/paritytech/sol-rs) - _Nástroj pro jednotkové testování chytrých kontraktů v Solidity využívající nativní EVM klienta Parity._
+- [SputnikVM](https://github.com/rust-blockchain/evm) - _Implementace Ethereum Virtual Machine (EVM) v Rustu_
+- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) - _Chytrý kontrakt Wavelet v Rustu_
+- [Foundry](https://github.com/foundry-rs/foundry) - _Sada nástrojů pro vývoj aplikací pro Ethereum_
+- [Alloy](https://alloy.rs) - _Vysoce výkonné, dobře otestované a zdokumentované knihovny pro interakci s Ethereem a dalšími řetězci založenými na EVM._
+- [Ethers_rs](https://github.com/gakonst/ethers-rs) - _Implementace knihovny a peněženky pro Ethereum_
+- [SewUp](https://github.com/second-state/SewUp) - _Knihovna, která vám pomůže vytvořit kontrakt pro Ethereum WebAssembly v Rustu, stejně jako při vývoji běžného backendu_
+- [Substreams](https://github.com/streamingfast/substreams) - _Technologie pro paralelizované indexování dat z blockchainu_
+- [Reth](https://github.com/paradigmxyz/reth) Reth (zkratka pro Rust Ethereum) je nová implementace plného uzlu Etherea
+- [Awesome Ethereum Rust](https://github.com/Vid201/awesome-ethereum-rust) - _Spravovaná sbírka projektů v ekosystému Etherea napsaných v Rustu_
+
+Hledáte další informační zdroje? Podívejte se na [ethereum.org/developers.](/developers/)
+
+## Přispěvatelé komunity Rust {#rust-community-contributors}
+
+- [Ethereum WebAssembly](https://gitter.im/ewasm/Lobby)
+- [Oasis Gitter](https://gitter.im/Oasis-official/Lobby)
+- [Parity Gitter](https://gitter.im/paritytech/parity)
+- [Enigma](https://discord.gg/SJK32GY)
diff --git a/public/content/translations/cs/developers/docs/scaling/index.md b/public/content/translations/cs/developers/docs/scaling/index.md
index 47b67364562..52bc73c85f1 100644
--- a/public/content/translations/cs/developers/docs/scaling/index.md
+++ b/public/content/translations/cs/developers/docs/scaling/index.md
@@ -9,27 +9,27 @@ sidebarDepth: 3
S růstem počtu lidí používajících Ethereum narazil tento blockchain na určité kapacitní limity. To vedlo ke zvýšení nákladů na používání sítě a vytvořilo potřebu „škálovacích řešení.“ Existuje několik řešení, která se zkoumají, testují a implementují, přičemž každé přistupuje k dosažení podobných cílů různými způsoby.
-Hlavním cílem škálování je zvýšit rychlost transakcí (rychlejší finalita) a propustnost transakcí (vyšší počet transakcí za sekundu), aniž by byla obětována decentralizace nebo bezpečnost (více o [vizi Etherea](/roadmap/vision/)). Na blockchainu vrstvy 1 Ethera vede vysoká poptávka k pomalejším transakcím a neudržitelným [palivovým cenám](/developers/docs/gas/). Zvýšení kapacity sítě z hlediska rychlosti a propustnosti je zásadní pro smysluplné a masové přijetí Etherea.
+Hlavním cílem škálovatelnosti je zvýšit rychlost transakcí (rychlejší finalita) a propustnost transakcí (vyšší počet transakcí za sekundu), aniž by byla obětována decentralizace nebo bezpečnost. Na blockchainu Ethereum vrstvy 1 vede vysoká poptávka k pomalejším transakcím a neudržitelným [cenám za gas](/developers/docs/gas/). Zvýšení kapacity sítě z hlediska rychlosti a propustnosti je zásadní pro smysluplné a masové přijetí Etherea.
Zatímco rychlost a propustnost jsou důležité, je nezbytné, aby škálovací řešení umožňující tyto cíle zůstala decentralizovaná a bezpečná. Udržení nízké bariéry pro vstup pro operátory síťových uzlů je klíčové k tomu, aby se zabránilo přechodu k centralizovanému a nezabezpečenému výpočetnímu výkonu.
-Konceptuálně nejprve rozdělíme škálování na on-chain škálování a off-chain škálování.
+Koncepčně nejprve dělíme škálování na on-chain škálování a off-chain škálování.
## Předpoklady {#prerequisites}
Měli byste dobře rozumět všem základním tématům. Implementace škálovacích řešení je pokročilým tématem, protože tato technologie není zatím dostatečně otestována v praxi a stále se vyvíjí a zkoumá.
-## On-chain škálování {#on-chain-scaling}
+## On-chain škálování {#onchain-scaling}
-On-chain škálování vyžaduje změny v protokolu Etherea ([Mainnet](/glossary/#mainnet) vrstvy 1). Dlouhou dobu se očekávalo, že Ethereum bude škálováno prostřednictvím shardingu. To mělo zahrnovat rozdělení blockchainu na oddělené části (shardy), které by byly ověřovány podskupinami validátorů. Ale hlavní technikou škálování se postupně stalo škálování pomocí rollupů na vrstvě 2. To je podporováno přidáním nové levnější formy dat připojených k blokům Etherea, která je speciálně navržena tak, aby byly rollupy pro uživatele levné.
+On-chain škálování vyžaduje změny v protokolu Ethereum (vrstva 1 [Mainnet](/glossary/#mainnet)). Dlouhou dobu se očekávalo, že Ethereum bude škálováno prostřednictvím shardingu. To mělo zahrnovat rozdělení blockchainu na oddělené části (shardy), které by byly ověřovány podskupinami validátorů. Ale hlavní technikou škálování se postupně stalo škálování pomocí rollupů na vrstvě 2. To je podporováno přidáním nové levnější formy dat připojených k blokům Etherea, která je speciálně navržena tak, aby byly rollupy pro uživatele levné.
### Sharding {#sharding}
-Sharding je proces rozdělení databáze. Podskupiny validátorů by byly zodpovědné za jednotlivé shardery, místo aby sledovaly celé Ethereum. Sharding byl dlouhou dobu součástí plánu vývoje Etherea a měl být původně zaveden před přechodem na proof-of-stake (Sloučení). Avšak rychlý vývoj [rollupů na vrstvě 2](#layer-2-scaling) a vynález [Dankshardingu](/roadmap/danksharding) (přidávání blobů dat z rollupů do bloků Etherea, které mohou být velmi efektivně ověřovány validátory) vedly komunitu Etherea k upřednostnění škálování zaměřeného na rollupy namísto shardingu. To také pomůže udržet logiku konsensu Etherea jednodušší.
+Sharding je proces rozdělení databáze. Podskupiny validátorů by byly zodpovědné za jednotlivé shardery, místo aby sledovaly celé Ethereum. Sharding byl dlouhou dobu součástí [plánu](/roadmap/) Etherea a původně se počítalo s jeho spuštěním před přechodem na proof-of-stake (The Merge). Rychlý vývoj [rollupů vrstvy 2](#layer-2-scaling) a vynález [Dankshardingu](/roadmap/danksharding) (přidávání datových blobů z rollupů do bloků Etherea, které mohou validátoři velmi efektivně ověřit) však vedly komunitu Etherea k upřednostnění škálování zaměřeného na rollupy namísto škálování pomocí shardingu. To také pomůže udržet logiku konsensu Etherea jednodušší.
-## Off-chain škálování {#off-chain-scaling}
+## Off-chain škálování {#offchain-scaling}
-Off-chain řešení jsou implementována odděleně od Mainnetu vrstvy 1 – nevyžadují žádné změny v existujícím protokolu Etherea. Některá řešení, známá jako „řešení vrstvy 2“, odvozují svou bezpečnost přímo od konsensu vrstvy 1 Etherea, jako jsou [optimistické rollupy](/developers/docs/scaling/optimistic-rollups/), [zero-knowledge rollupy](/developers/docs/scaling/zk-rollups/) nebo [stavové kanály](/developers/docs/scaling/state-channels/). Jiná řešení zahrnují vytvoření nových řetězců v různých formách, které řeší svoji bezpečnost nezávisle na Mainnetu, jako jsou [postranní řetězce](#sidechains), [validia](#validium) nebo [plazmatické řetězce](#plasma). Tato řešení komunikují s Mainnetem, ale odvozují svou bezpečnost odlišně, za účelem dosažení různých cílů.
+Off-chain řešení jsou implementována odděleně od Mainnetu vrstvy 1 – nevyžadují žádné změny v existujícím protokolu Ethereum. Některá řešení, známá jako řešení „vrstvy 2“, odvozují svou bezpečnost přímo z konsensu Etherea na vrstvě 1, jako jsou [optimistické rollupy](/developers/docs/scaling/optimistic-rollups/), [rollupy s nulovou znalostí](/developers/docs/scaling/zk-rollups/) nebo [stavové kanály](/developers/docs/scaling/state-channels/). Jiná řešení zahrnují vytváření nových chainů v různých formách, které odvozují svou bezpečnost nezávisle na Mainnetu, jako jsou [sidechainy](#sidechains), [validia](#validium) nebo [plasma chainy](#plasma). Tato řešení komunikují s Mainnetem, ale odvozují svou bezpečnost odlišně, za účelem dosažení různých cílů.
### Škálování vrstvy 2 {#layer-2-scaling}
@@ -37,7 +37,7 @@ Tato kategorie off-chain řešení odvozuje svou bezpečnost od Mainnetu Etherea
Vrstva 2 je souhrnný termín pro řešení navržená k lepšímu škálování vaší aplikace tím, že zpracovávají transakce mimo Mainnet Etherea (vrstva 1) a zároveň využívají robustní decentralizovaný bezpečnostní model Mainnetu. Rychlost transakcí trpí, když je síť zaneprázdněna, což zhoršuje uživatelský zážitek u určitých typů dappek. A jak se síť stává vytíženější, zvyšují se ceny paliva, protože odesílatelé transakcí se snaží navzájem předhánět. To může použití Etherea značně prodražit.
-Většina řešení vrstvy 2 je založena na serveru nebo skupině serverů, z nichž každý může být označen jako síťový uzel, validátor, operátor, sekvencer, producent bloků nebo podobným termínem. V závislosti na implementaci mohou být tyto síťové uzly vrstvy 2 provozovány jednotlivci, podniky nebo subjekty, které je používají, nebo třetími stranami nebo velkou skupinou jednotlivců (podobně jako Mainnet). Obecně platí, že transakce jsou doručeny těmto uzlům vrstvy 2 namísto přímého doručení na vrstvu 1 (Mainnet). U některých řešení síťové uzly vrstvy 2 následně seskupují transakce do balíčků, které posléze ukotví na vrstvu 1, kde jsou právě touto vrstvou zabezpečeny a nelze je změnit. Detaily takové exekuce se mezi různými technologiemi a implementacemi vrstvy 2 značně liší.
+Většina řešení vrstvy 2 je založena na serveru nebo skupině serverů, z nichž každý může být označen jako síťový uzel, validátor, operátor, sekvencer, producent bloků nebo podobným termínem. V závislosti na implementaci mohou být tyto síťové uzly vrstvy 2 provozovány jednotlivci, podniky nebo subjekty, které je používají, nebo třetími stranami nebo velkou skupinou jednotlivců (podobně jako Mainnet). Obecně platí, že transakce jsou doručeny těmto uzlům vrstvy 2 namísto přímého doručení na vrstvu 1 (Mainnet). U některých řešení instance vrstvy 2 dávkuje transakce do skupin, než je ukotví na vrstvu 1, načež jsou zabezpečeny vrstvou 1 a nelze je změnit. Detaily takové exekuce se mezi různými technologiemi a implementacemi vrstvy 2 značně liší.
Konkrétní instance vrstvy 2 může být otevřená a sdílená mnoha aplikacemi nebo může být nasazena jedním projektem a určena pouze k podpoře jejich aplikace.
@@ -48,7 +48,7 @@ Konkrétní instance vrstvy 2 může být otevřená a sdílená mnoha aplikacem
- Jakékoli aktualizace škálovatelnosti by neměly být na úkor decentralizace nebo bezpečnosti – vrstva 2 je postavena nad Ethereem.
- Existují sítě vrstvy 2 se specifickou aplikací, které přinášejí vlastní sadu efektivity při práci s aktivy ve velkém měřítku.
-[Další informace o vrstvě 2](/layer-2/).
+[Více o vrstvě 2](/layer-2/).
#### Rollupy {#rollups}
@@ -56,58 +56,58 @@ Rollupy provádějí exekuci transakcí mimo vrstvu 1 a poté data zveřejní na
Existují dva typy rollupů s různými bezpečnostními modely:
-- **Optimistické rollupy**: Předpokládají, že transakce jsou platné, a provádějí výpočet prostřednictvím [**důkazu podvodu**](/glossary/#fraud-proof) pouze v případě výzvy k ověření platnosti. [Více o optimistických rollupech](/developers/docs/scaling/optimistic-rollups/).
-- **Zero-knowledge rollupy**: Provádějí výpočty mimo řetězec a předkládají [**důkaz o platnosti**](/glossary/#validity-proof) na řetězci. [Více o zero-knowledge rollupech](/developers/docs/scaling/zk-rollups/).
+- **Optimistické rollupy**: předpokládají, že transakce jsou ve výchozím nastavení platné a spouští výpočet, prostřednictvím [**důkazu o podvodu**](/glossary/#fraud-proof), pouze v případě zpochybnění. [Více o optimistických rollupech](/developers/docs/scaling/optimistic-rollups/).
+- **Rollupy s nulovou znalostí**: provádí výpočty off-chain a na chain odesílají [**důkaz o platnosti**](/glossary/#validity-proof). [Více o rollupech s nulovou znalostí](/developers/docs/scaling/zk-rollups/).
#### Stavové kanály {#channels}
-Stavové kanály využívají multisig kontrakty, aby účastníkům umožnili rychle a volně transakčně komunikovat mimo řetězec a poté finalizovat stav na Mainnetu. To minimalizuje přetížení sítě, poplatky a zpoždění. Dva typy kanálů jsou v současnosti stavové kanály a platební kanály.
+Stavové kanály využívají multisig kontrakty, aby účastníkům umožnily rychle a volně provádět transakce off-chain, a poté finalizovat stav na Mainnetu. To minimalizuje přetížení sítě, poplatky a zpoždění. Dva typy kanálů jsou v současnosti stavové kanály a platební kanály.
-Více o [stavových kanálech](/developers/docs/scaling/state-channels/).
+Zjistěte více o [stavových kanálech](/developers/docs/scaling/state-channels/).
-### Postranní řetězce {#sidechains}
+### Sidechainy {#sidechains}
Postranní řetězec je nezávislý blockchain kompatibilní s EVM, který běží paralelně s Mainnetem. Jsou kompatibilní s Ethereem prostřednictvím obousměrných přemostění a fungují podle svých vlastních pravidel konsensu a parametrů bloků.
-Více o [postranních řetězcích](/developers/docs/scaling/sidechains/).
+Zjistěte více o [sidechainech](/developers/docs/scaling/sidechains/).
### Plasma {#plasma}
-Plazmový řetězec je samostatný blockchain, který je ukotven k hlavnímu řetězci Etherea a k řešení sporů používá důkazy podvodu (stejně jako [optimistické rollupy](/developers/docs/scaling/optimistic-rollups/)).
+Plasma chain je samostatný blockchain, který je ukotven k hlavnímu chainu Etherea a používá důkazy o podvodu (stejně jako [optimistické rollupy](/developers/docs/scaling/optimistic-rollups/)) k řešení sporů.
-Více o [Plasmě](/developers/docs/scaling/plasma/).
+Zjistěte více o [Plasma](/developers/docs/scaling/plasma/).
### Validium {#validium}
Řetězec typu validium používá důkazy o platnosti, stejně jako zero-knowledge rollupy, ale data nejsou uložena na vrstvě 1 Etherea. To umožňuje 10 000 transakcí za sekundu na jeden Validium řetězec a více řetězců může běžet paralelně.
-Více o [Validiu](/developers/docs/scaling/validium/).
+Zjistěte více o [Validium](/developers/docs/scaling/validium/).
## Proč je potřeba tolik škálovacích řešení? {#why-do-we-need-these}
- Více řešení může pomoci snížit celkové přetížení na jakékoliv části sítě a také zabránit vzniku jediných bodů selhání.
- Celek je efektivnější než součet efektivity jeho částí. Různá řešení mohou existovat a pracovat v harmonii, což aplikuje exponenciální efekt na budoucí rychlost transakcí a propustnost.
- Ne všechna řešení vyžadují přímé využití konsensuálního algoritmu Etherea a alternativy mohou nabízet výhody, které by jinak bylo obtížné získat.
-- Žádné jedno škálovací řešení samo o sobě nestačí k naplnění [vize Etherea](/roadmap/vision/).
-## Učíte se spíše vizuálně? {#visual-learner}
+## Učíte se spíše vizuálně? Vizuální výuka {#visual-learner}
Poznámka: Ethereum pravidelně používá hašovací funkce k vytváření hodnot pevné velikosti („hašů“). Haše hrají v Ethereu důležitou roli, ale prozatím si je můžeš bezpečně představit jako jedinečné identifikátory.
+
+
+
+_Blockchain je v podstatě spojový seznam; každý blok má odkaz na předchozí blok._
+
+Tato datová struktura není nijak nová, ale pravidla (tj. protokoly peer-to-peer), která řídí síť, ano. Neexistuje žádná centrální autorita; síť peerů musí spolupracovat na udržení sítě a soutěžit o to, které transakce zahrnout do dalšího bloku. Takže když chceš poslat nějaké peníze kamarádovi, musíš tuto transakci odvysílat do sítě a pak počkat, až bude zahrnuta do některého z nadcházejících bloků.
+
+Jediný způsob, jak může blockchain ověřit, že peníze byly skutečně poslány od jednoho uživatele k druhému, je použití měny, která je pro daný blockchain nativní (tj. vytvořená a řízená jím). V Ethereu se tato měna nazývá ether a blockchain Etherea obsahuje jediný oficiální záznam o zůstatcích na účtech.
+
+## Nové paradigma {#a-new-paradigm}
+
+Tento nový decentralizovaný technologický stack dal vzniknout novým vývojářským nástrojům. Takové nástroje existují v mnoha programovacích jazycích, ale my se na ně podíváme z pohledu Pythonu. Znovu opakuji: i když Python není tvůj preferovaný jazyk, neměl by být velký problém vše sledovat.
+
+Vývojáři v Pythonu, kteří chtějí interagovat s Ethereem, pravděpodobně sáhnou po [Web3.py](https://web3py.readthedocs.io/). Web3.py je knihovna, která výrazně zjednodušuje způsob, jakým se připojíš k uzlu Ethereum a poté z něj odesíláš a přijímáš data.
+
+Poznámka: „Uzel sítě Ethereum“ a „klient sítě Ethereum“ se používají zaměnitelně. V obou případech se jedná o software, který spouští účastník sítě Ethereum. Tento software umí číst data bloků, přijímat aktualizace, když jsou do řetězce přidány nové bloky, vysílat nové transakce a další. Technicky vzato je klient software a uzel je počítač, na kterém software běží.
+
+[Klienti sítě Ethereum](/developers/docs/nodes-and-clients/) mohou být nakonfigurováni tak, aby byli dosažitelní pomocí [IPC](https://wikipedia.org/wiki/Inter-process_communication), HTTP nebo Websockets, takže Web3.py bude muset tuto konfiguraci zrcadlit. Web3.py označuje tyto možnosti připojení jako **providery**. Budeš si chtít vybrat jednoho ze tří providerů, abys propojil instanci Web3.py se svým uzlem.
+
+
+
+_Nakonfiguruj uzel Ethereum a Web3.py tak, aby komunikovaly pomocí stejného protokolu, např. IPC v tomto diagramu._
+
+Jakmile je Web3.py správně nakonfigurováno, můžeš začít interagovat s blockchainem. Zde je několik příkladů použití Web3.py jako ukázka toho, co přijde:
+
+```python
+# čtení dat bloku:
+w3.eth.get_block('latest')
+
+# odeslání transakce:
+w3.eth.send_transaction({'from': ..., 'to': ..., 'value': ...})
+```
+
+## Instalace {#installation}
+
+V tomto návodu budeme pracovat pouze v interpretu Pythonu. Nebudeme vytvářet žádné adresáře, soubory, třídy ani funkce.
+
+Poznámka: V níže uvedených příkladech jsou příkazy začínající na `$` určeny ke spuštění v terminálu. (Znak `$` nepiš, označuje pouze začátek řádku.)
+
+Nejprve si nainstaluj [IPython](https://ipython.org/) pro uživatelsky přívětivé prostředí k prozkoumávání. IPython nabízí mimo jiné doplňování pomocí tabulátoru, což výrazně usnadňuje zjištění, co všechno je v Web3.py možné.
+
+```bash
+pip install ipython
+```
+
+Web3.py je publikován pod názvem `web3`. Nainstaluj ho takto:
+
+```bash
+pip install web3
+```
+
+Ještě jedna věc – později budeme simulovat blockchain, což vyžaduje několik dalších závislostí. Můžeš si je nainstalovat pomocí:
+
+```bash
+pip install 'web3[tester]'
+```
+
+Máš všechno připravené a můžeme začít!
+
+Poznámka: Balíček `web3[tester]` funguje až do Pythonu 3.10.xx
+
+## Spuštění sandboxu {#spin-up-a-sandbox}
+
+Otevři si nové prostředí Python spuštěním `ipython` v terminálu. Je to srovnatelné se spuštěním `python`, ale s více vychytávkami.
+
+```bash
+ipython
+```
+
+Tím se vypíší informace o verzích Pythonu a IPythonu, které používáš, a pak bys měl vidět výzvu čekající na zadání:
+
+```python
+In [1]:
+```
+
+Právě se díváš na interaktivní Python shell. V podstatě je to sandbox, ve kterém si můžeš hrát. Pokud ses dostal až sem, je čas importovat Web3.py:
+
+```python
+In [1]: from web3 import Web3
+```
+
+## Představení modulu Web3 {#introducing-the-web3-module}
+
+Kromě toho, že je modul [Web3](https://web3py.readthedocs.io/en/stable/overview.html#base-api) bránou do Etherea, nabízí i několik pomocných funkcí. Pojďme si jich pár prozkoumat.
+
+V aplikaci pro Ethereum budeš běžně potřebovat převádět nominální hodnoty měn. Modul Web3 poskytuje pro tento účel několik pomocných metod: [from_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.from_wei) a [to_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.to_wei).
+
+
+Poznámka: Počítače jsou proslulé tím, že špatně zvládají desetinnou matematiku. Aby se tomu předešlo, vývojáři často ukládají dolarové částky v centech. Například položka s cenou 5,99 $ může být v databázi uložena jako 599.
+
+Podobný vzorec se používá při zpracování transakcí v etheru. Avšak místo dvou desetinných míst má ether 18! Nejmenší nominální hodnota etheru se nazývá wei, takže to je hodnota, která se zadává při odesílání transakcí.
+
+1 ether = 1000000000000000000 wei
+
+1 wei = 0,000000000000000001 etheru
+
+
+
+Zkus si převést některé hodnoty do a z wei. Všimni si, že [existují názvy pro mnoho nominálních hodnot](https://web3py.readthedocs.io/en/stable/troubleshooting.html#how-do-i-convert-currency-denominations) mezi etherem a wei. Jednou z nejznámějších mezi nimi je **gwei**, protože se v ní často uvádějí transakční poplatky.
+
+```python
+In [2]: Web3.to_wei(1, 'ether')
+Out[2]: 1000000000000000000
+
+In [3]: Web3.from_wei(500000000, 'gwei')
+Out[3]: Decimal('0.5')
+```
+
+Další pomocné metody v modulu Web3 zahrnují převodníky datových formátů (např. [`toHex`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.toHex)), pomocné funkce pro adresy (např. [`isAddress`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.isAddress)) a hašovací funkce (např. [`keccak`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.keccak)). Mnohým z nich se budeme věnovat později v této sérii. Chceš-li zobrazit všechny dostupné metody a vlastnosti, využij automatické doplňování v IPythonu zadáním `Web3`. a dvojitým stisknutím klávesy Tab za tečkou.
+
+## Komunikace s chainem {#talk-to-the-chain}
+
+Pomocné metody jsou fajn, ale pojďme se přesunout k blockchainu. Dalším krokem je nakonfigurovat Web3.py pro komunikaci s uzlem Etherea. Zde máme možnost použít providery IPC, HTTP nebo Websocket.
+
+Tudy se nevydáme, ale příklad kompletního pracovního postupu s použitím HTTP Provideru by mohl vypadat asi takto:
+
+- Stáhni si uzel Etherea, např. [Geth](https://geth.ethereum.org/).
+- Spusť Geth v jednom okně terminálu a počkej, až se synchronizuje se sítí. Výchozí port HTTP je `8545`, ale je konfigurovatelný.
+- Řekni Web3.py, aby se připojil k uzlu přes HTTP na `localhost:8545`.
+ `w3 = Web3(Web3.HTTPProvider('http://127.0.0.1:8545'))`
+- Použij instanci `w3` k interakci s uzlem.
+
+I když je to jeden ze „skutečných“ způsobů, jak to udělat, proces synchronizace trvá hodiny a je zbytečný, pokud chceš jen vývojové prostředí. Web3.py pro tento účel zpřístupňuje čtvrtého providera, **EthereumTesterProvider**. Tento tester provider se připojuje k simulovanému uzlu Etherea s uvolněnými oprávněními a falešnou měnou na hraní.
+
+
+
+_EthereumTesterProvider se připojuje k simulovanému uzlu a je praktický pro rychlé vytvoření vývojového prostředí._
+
+Tento simulovaný uzel se nazývá [eth-tester](https://github.com/ethereum/eth-tester) a nainstalovali jsme si ho jako součást příkazu `pip install web3[tester]`. Konfigurace Web3.py pro použití tohoto tester providera je tak jednoduchá:
+
+```python
+In [4]: w3 = Web3(Web3.EthereumTesterProvider())
+```
+
+Teď jsi připravený surfovat na chainu! Takhle se to neříká. To jsem si právě vymyslel. Pojďme na rychlou prohlídku.
+
+## Rychlá prohlídka {#the-quick-tour}
+
+Nejdříve ze všeho, kontrola funkčnosti:
+
+```python
+In [5]: w3.is_connected()
+Out[5]: True
+```
+
+Jelikož používáme tester providera, není to příliš cenný test, ale pokud selže, je pravděpodobné, že jsi při vytváření instance proměnné `w3` něco špatně napsal. Zkontroluj si, že jsi zahrnul vnitřní závorky, tj. `Web3.EthereumTesterProvider()`.
+
+## Zastávka č. 1: [účty](/developers/docs/accounts/) {#tour-stop-1-accounts}
+
+Pro usnadnění tester provider vytvořil několik účtů a předem je nabil testovacím etherem.
+
+Nejprve se podívejme na seznam těchto účtů:
+
+```python
+In [6]: w3.eth.accounts
+Out[6]: ['0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf',
+ '0x2B5AD5c4795c026514f8317c7a215E218DcCD6cF',
+ '0x6813Eb9362372EEF6200f3b1dbC3f819671cBA69', ...]
+```
+
+Pokud tento příkaz spustíš, měl bys vidět seznam deseti řetězců, které začínají `0x`. Každý z nich je **veřejná adresa** a je v některých ohledech analogický číslu běžného účtu. Tuto adresu bys poskytl někomu, kdo by ti chtěl poslat ether.
+
+Jak již bylo zmíněno, tester provider předem nabil každý z těchto účtů testovacím etherem. Pojďme zjistit, kolik je na prvním účtu:
+
+```python
+In [7]: w3.eth.get_balance(w3.eth.accounts[0])
+Out[7]: 1000000000000000000000000
+```
+
+To je hodně nul! Než se s úsměvem vydáš do falešné banky, vzpomeň si na dřívější lekci o nominálních hodnotách měn. Hodnoty etheru jsou vyjádřeny v nejmenší nominální hodnotě, wei. Převeďme to na ether:
+
+```python
+In [8]: w3.from_wei(1000000000000000000000000, 'ether')
+Out[8]: Decimal('1000000')
+```
+
+Jeden milion testovacích etherů – to pořád není špatné.
+
+## Zastávka č. 2: data bloku {#tour-stop-2-block-data}
+
+Pojďme se podívat na stav tohoto simulovaného blockchainu:
+
+```python
+In [9]: w3.eth.get_block('latest')
+Out[9]: AttributeDict({
+ 'number': 0,
+ 'hash': HexBytes('0x9469878...'),
+ 'parentHash': HexBytes('0x0000000...'),
+ ...
+ 'transactions': []
+})
+```
+
+O bloku se vrací spousta informací, ale zde je třeba upozornit jen na pár věcí:
+
+- Číslo bloku je nula – bez ohledu na to, jak dávno jsi nakonfiguroval tester providera. Na rozdíl od skutečné sítě Ethereum, která přidává nový blok každých 12 sekund, tato simulace počká, dokud jí nedáš nějakou práci.
+- `transactions` je prázdný seznam ze stejného důvodu: ještě jsme nic neudělali. Tento první blok je **prázdný blok**, jen aby se spustil chain.
+- Všimni si, že `parentHash` je jen spousta prázdných bytů. To znamená, že se jedná o první blok v řetězci, známý také jako **genesis blok**.
+
+## Zastávka č. 3: [transakce](/developers/docs/transactions/) {#tour-stop-3-transactions}
+
+Zasekli jsme se na bloku nula, dokud nebude čekající transakce, tak mu ji dejme. Pošli pár testovacích etherů z jednoho účtu na druhý:
+
+```python
+In [10]: tx_hash = w3.eth.send_transaction({
+ 'from': w3.eth.accounts[0],
+ 'to': w3.eth.accounts[1],
+ 'value': w3.to_wei(3, 'ether'),
+ 'gas': 21000
+})
+```
+
+To je obvykle bod, kde bys čekal několik sekund, než se tvá transakce zahrne do nového bloku. Celý proces probíhá nějak takhle:
+
+1. Odešli transakci a uschovej si haš transakce. Dokud není vytvořen a odvysílán blok obsahující transakci, transakce je „čekající“.
+ `tx_hash = w3.eth.send_transaction({ …` `})`
+2. Počkej, až bude transakce zahrnuta do bloku:
+ `w3.eth.wait_for_transaction_receipt(tx_hash)`
+3. Pokračuj v logice aplikace. Pro zobrazení úspěšné transakce:
+ `w3.eth.get_transaction(tx_hash)`
+
+Naše simulované prostředí přidá transakci do nového bloku okamžitě, takže si transakci můžeme hned prohlédnout:
+
+```python
+In [11]: w3.eth.get_transaction(tx_hash)
+Out[11]: AttributeDict({
+ 'hash': HexBytes('0x15e9fb95dc39...'),
+ 'blockNumber': 1,
+ 'transactionIndex': 0,
+ 'from': '0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf',
+ 'to': '0x2B5AD5c4795c026514f8317c7a215E218DcCD6cF',
+ 'value': 3000000000000000000,
+ ...
+})
+```
+
+Zde uvidíš některé známé detaily: pole `from`, `to` a `value` by měla odpovídat vstupům našeho volání `send_transaction`. Další uklidňující věcí je, že tato transakce byla zahrnuta jako první transakce (`'transactionIndex': 0`) v bloku číslo 1.
+
+Úspěšnost této transakce můžeme také snadno ověřit kontrolou zůstatků na obou zúčastněných účtech. Tři ethery se měly přesunout z jednoho na druhý.
+
+```python
+In [12]: w3.eth.get_balance(w3.eth.accounts[0])
+Out[12]: 999996999979000000000000
+
+In [13]: w3.eth.get_balance(w3.eth.accounts[1])
+Out[13]: 1000003000000000000000000
+```
+
+To druhé vypadá dobře! Zůstatek se změnil z 1 000 000 na 1 000 003 etherů. Ale co se stalo s prvním účtem? Zdá se, že ztratil o něco více než tři ethery. Bohužel, nic v životě není zadarmo, a používání veřejné sítě Ethereum vyžaduje, abys odměnil ostatní účastníky sítě za jejich podporu. Z účtu, který transakci odeslal, byl odečten malý transakční poplatek – tento poplatek je množství spáleného paliva (21 000 jednotek paliva za převod ETH) vynásobené základním poplatkem, který se liší podle aktivity sítě, plus spropitné, které jde validátorovi, který transakci zahrne do bloku.
+
+Více o [palivu](/developers/docs/gas/#post-london)
+
+Poznámka: Ve veřejné síti jsou transakční poplatky proměnlivé v závislosti na poptávce v síti a na tom, jak rychle chceš, aby byla transakce zpracována. Pokud tě zajímá, jak se poplatky počítají, podívej se na můj dřívější příspěvek o tom, jak se transakce zahrnují do bloku.
+
+## A teď výdech {#and-breathe}
+
+Už jsme u toho nějakou dobu, takže se zdá, že je to dobré místo na přestávku. Králičí nora pokračuje a my budeme pokračovat v průzkumu v druhé části této série. Některé koncepty, které přijdou: připojení ke skutečnému uzlu, chytré kontrakty a tokeny. Máš další otázky? Dej mi vědět! Tvá zpětná vazba ovlivní, kam se odtud vydáme. Žádosti jsou vítány přes [Twitter](https://twitter.com/wolovim).
diff --git a/public/content/translations/cs/developers/tutorials/all-you-can-cache/index.md b/public/content/translations/cs/developers/tutorials/all-you-can-cache/index.md
new file mode 100644
index 00000000000..e75de37e753
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/all-you-can-cache/index.md
@@ -0,0 +1,867 @@
+---
+title: "Vše, co můžete cachovat"
+description: Naučte se, jak vytvořit a používat cachovací kontrakt pro levnější rollupové transakce
+author: Ori Pomerantz
+tags: [ "vrstva 2", "cachování", "úložiště" ]
+skill: intermediate
+published: 2022-09-15
+lang: cs
+---
+
+Při používání rollupů je cena jednoho bajtu v transakci o mnoho vyšší než cena slotu v úložišti. Proto dává smysl cachovat co nejvíce informací na blockchainu.
+
+V tomto článku se naučíte, jak vytvořit a používat cachovací kontrakt tak, aby se každá hodnota parametru, která se pravděpodobně použije vícekrát, uložila do cache a byla (po prvním použití) dostupná za použití mnohem menšího počtu bajtů, a jak napsat off-chain kód, který tuto cache využívá.
+
+Pokud chcete článek přeskočit a podívat se rovnou na zdrojový kód, [najdete ho zde](https://github.com/qbzzt/20220915-all-you-can-cache). Vývojový stack je [Foundry](https://getfoundry.sh/introduction/installation/).
+
+## Celkový návrh {#overall-design}
+
+Pro zjednodušení budeme předpokládat, že všechny parametry transakce jsou typu `uint256` o délce 32 bajtů. Když obdržíme transakci, zpracujeme každý parametr následujícím způsobem:
+
+1. Pokud je první bajt `0xFF`, vezměte následujících 32 bajtů jako hodnotu parametru a zapište ji do cache.
+
+2. Pokud je první bajt `0xFE`, vezměte následujících 32 bajtů jako hodnotu parametru, ale _nezapisujte_ ji do cache.
+
+3. Pro jakoukoliv jinou hodnotu vezměte horní čtyři bity jako počet dalších bajtů a spodní čtyři bity jako nejvýznamnější bity klíče cache. Zde je několik příkladů:
+
+ | Bajty v calldata | Klíč cache |
+ | :--------------- | ---------: |
+ | 0x0F | 0x0F |
+ | 0x10,0x10 | 0x10 |
+ | 0x12,0xAC | 0x02AC |
+ | 0x2D,0xEA, 0xD6 | 0x0DEAD6 |
+
+## Manipulace s cache {#cache-manipulation}
+
+Cache je implementována v souboru [`Cache.sol`](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol). Pojďme si ho projít řádek po řádku.
+
+```solidity
+// SPDX-License-Identifier: UNLICENSED
+pragma solidity ^0.8.13;
+
+
+contract Cache {
+
+ bytes1 public constant INTO_CACHE = 0xFF;
+ bytes1 public constant DONT_CACHE = 0xFE;
+```
+
+Tyto konstanty se používají k interpretaci speciálních případů, kdy poskytujeme všechny informace a chceme je buď zapsat do cache, nebo ne. Zápis do cache vyžaduje dvě operace [`SSTORE`](https://www.evm.codes/#55) do dříve nepoužitých slotů v úložišti s cenou 22 100 gasu za každou, takže je to volitelné.
+
+```solidity
+
+ mapping(uint => uint) public val2key;
+```
+
+[Mapování](https://www.geeksforgeeks.org/solidity/solidity-mappings/) mezi hodnotami a jejich klíči. Tato informace je nezbytná k zakódování hodnot před odesláním transakce.
+
+```solidity
+ // Umístění n má hodnotu pro klíč n+1, protože potřebujeme zachovat
+ // nulu jako „není v cache“.
+ uint[] public key2val;
+```
+
+Pro mapování z klíčů na hodnoty můžeme použít pole, protože klíče přiřazujeme my a pro zjednodušení to děláme sekvenčně.
+
+```solidity
+ function cacheRead(uint _key) public view returns (uint) {
+ require(_key <= key2val.length, "Čtení neinicializované položky cache");
+ return key2val[_key-1];
+ } // cacheRead
+```
+
+Přečte hodnotu z cache.
+
+```solidity
+ // Zapíše hodnotu do cache, pokud tam ještě není
+ // Veřejné jen proto,aby fungoval test
+ function cacheWrite(uint _value) public returns (uint) {
+ // Pokud je hodnota již v cache, vrátí aktuální klíč
+ if (val2key[_value] != 0) {
+ return val2key[_value];
+ }
+```
+
+Nemá smysl vkládat stejnou hodnotu do cache více než jednou. Pokud tam hodnota již je, stačí vrátit stávající klíč.
+
+```solidity
+ // Jelikož 0xFE je speciální případ, největší klíč, který může cache
+ // obsahovat, je 0x0D následovaný 15x 0xFF. Pokud už je délka cache tak
+ // velká, selže.
+ // 1 2 3 4 5 6 7 8 9 A B C D E F
+ require(key2val.length+1 < 0x0DFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF,
+ "přetečení cache");
+```
+
+Nemyslím si, že se někdy dočkáme tak velké cache (přibližně 1,8\*1037 položek, což by vyžadovalo asi 1027 TB k uložení). Jsem však dost starý na to, abych si pamatoval [„640 kB bude vždy stačit“](https://quoteinvestigator.com/2011/09/08/640k-enough/). Tento test je velmi levný.
+
+```solidity
+ // Zapíše hodnotu pomocí dalšího klíče
+ val2key[_value] = key2val.length+1;
+```
+
+Přidá zpětné vyhledávání (od hodnoty ke klíči).
+
+```solidity
+ key2val.push(_value);
+```
+
+Přidá dopředné vyhledávání (od klíče k hodnotě). Protože přiřazujeme hodnoty sekvenčně, můžeme ji jednoduše přidat za poslední hodnotu v poli.
+
+```solidity
+ return key2val.length;
+ } // cacheWrite
+```
+
+Vrátí novou délku `key2val`, což je buňka, kde je uložena nová hodnota.
+
+```solidity
+ function _calldataVal(uint startByte, uint length)
+ private pure returns (uint)
+```
+
+Tato funkce čte hodnotu z calldata libovolné délky (až 32 bajtů, což je velikost slova).
+
+```solidity
+ {
+ uint _retVal;
+
+ require(length < 0x21,
+ "limit délky _calldataVal je 32 bajtů");
+ require(length + startByte <= msg.data.length,
+ "_calldataVal se snaží číst za calldatasize");
+```
+
+Tato funkce je interní, takže pokud je zbytek kódu napsán správně, tyto testy nejsou nutné. Nestojí však mnoho, takže je můžeme klidně použít.
+
+```solidity
+ assembly {
+ _retVal := calldataload(startByte)
+ }
+```
+
+Tento kód je v jazyce [Yul](https://docs.soliditylang.org/en/v0.8.16/yul.html). Čte 32bajtovou hodnotu z calldata. Funguje to i v případě, že calldata končí před `startByte+32`, protože neinicializovaný prostor v EVM je považován za nulový.
+
+```solidity
+ _retVal = _retVal >> (256-length*8);
+```
+
+Nemusíme nutně chtít 32bajtovou hodnotu. Tím se zbavíme přebytečných bajtů.
+
+```solidity
+ return _retVal;
+ } // _calldataVal
+
+
+ // Načte jeden parametr z calldata, počínaje od _fromByte
+ function _readParam(uint _fromByte) internal
+ returns (uint _nextByte, uint _parameterValue)
+ {
+```
+
+Načte jeden parametr z calldata. Všimněte si, že musíme vrátit nejen hodnotu, kterou jsme načetli, ale také umístění dalšího bajtu, protože parametry mohou mít délku od 1 do 33 bajtů.
+
+```solidity
+ // První bajt nám říká, jak interpretovat zbytek
+ uint8 _firstByte;
+
+ _firstByte = uint8(_calldataVal(_fromByte, 1));
+```
+
+Solidity se snaží snížit počet chyb tím, že zakazuje potenciálně nebezpečné [implicitní převody typů](https://docs.soliditylang.org/en/v0.8.16/types.html#implicit-conversions). Downgrade, například z 256 bitů na 8 bitů, musí být explicitní.
+
+```solidity
+
+ // Přečte hodnotu, ale nezapíše ji do cache
+ if (_firstByte == uint8(DONT_CACHE))
+ return(_fromByte+33, _calldataVal(_fromByte+1, 32));
+
+ // Přečte hodnotu a zapíše ji do cache
+ if (_firstByte == uint8(INTO_CACHE)) {
+ uint _param = _calldataVal(_fromByte+1, 32);
+ cacheWrite(_param);
+ return(_fromByte+33, _param);
+ }
+
+ // Pokud jsme se dostali sem, znamená to, že musíme číst z cache
+
+ // Počet bajtů navíc ke čtení
+ uint8 _extraBytes = _firstByte / 16;
+```
+
+Vezměte nižší [půlbajt](https://en.wikipedia.org/wiki/Nibble) a zkombinujte ho s ostatními bajty, abyste načetli hodnotu z cache.
+
+```solidity
+ uint _key = (uint256(_firstByte & 0x0F) << (8*_extraBytes)) +
+ _calldataVal(_fromByte+1, _extraBytes);
+
+ return (_fromByte+_extraBytes+1, cacheRead(_key));
+
+ } // _readParam
+
+
+ // Načte n parametrů (funkce vědí, kolik parametrů očekávají)
+ function _readParams(uint _paramNum) internal returns (uint[] memory) {
+```
+
+Počet parametrů, které máme, bychom mohli získat ze samotné calldata, ale funkce, které nás volají, vědí, kolik parametrů očekávají. Je jednodušší, nechat si to od nich říct.
+
+```solidity
+ // Parametry, které čteme
+ uint[] memory params = new uint[](_paramNum);
+
+ // Parametry začínají na 4. bajtu, předtím je podpis funkce
+ uint _atByte = 4;
+
+ for(uint i=0; i<_paramNum; i++) {
+ (_atByte, params[i]) = _readParam(_atByte);
+ }
+```
+
+Čtěte parametry, dokud nebudete mít požadovaný počet. Pokud překročíme konec calldata, `_readParams` vrátí volání zpět.
+
+```solidity
+
+ return(params);
+ } // readParams
+
+ // Pro testování _readParams, testování čtení čtyř parametrů
+ function fourParam() public
+ returns (uint256,uint256,uint256,uint256)
+ {
+ uint[] memory params;
+ params = _readParams(4);
+ return (params[0], params[1], params[2], params[3]);
+ } // fourParam
+```
+
+Jednou z velkých výhod Foundry je, že umožňuje psát testy v Solidity ([viz Testování cache níže](#testing-the-cache)). To značně usnadňuje jednotkové testy. Jedná se o funkci, která přečte čtyři parametry a vrátí je, aby test mohl ověřit, že byly správné.
+
+```solidity
+ // Získá hodnotu, vrátí bajty, které ji zakódují (pokud možno s použitím cache)
+ function encodeVal(uint _val) public view returns(bytes memory) {
+```
+
+`encodeVal` je funkce, kterou volá off-chain kód, aby pomohla vytvořit calldata, která používá cache. Přijímá jednu hodnotu a vrací bajty, které ji kódují. Tato funkce je `view`, takže nevyžaduje transakci a při externím volání nestojí žádný gas.
+
+```solidity
+ uint _key = val2key[_val];
+
+ // Hodnota ještě není v cache, přidejte ji
+ if (_key == 0)
+ return bytes.concat(INTO_CACHE, bytes32(_val));
+```
+
+V [EVM](/developers/docs/evm/) se předpokládá, že všechna neinicializovaná úložiště jsou nulová. Takže pokud hledáme klíč pro hodnotu, která tam není, dostaneme nulu. V takovém případě jsou bajty, které ji kódují, `INTO_CACHE` (takže bude při příštím použití cachována), následované skutečnou hodnotou.
+
+```solidity
+ // Pokud je klíč <0x10, vraťte ho jako jeden bajt
+ if (_key < 0x10)
+ return bytes.concat(bytes1(uint8(_key)));
+```
+
+Jednotlivé bajty jsou nejjednodušší. Použijeme jen [`bytes.concat`](https://docs.soliditylang.org/en/v0.8.16/types.html#the-functions-bytes-concat-and-string-concat) pro převod typu `bytes` na pole bajtů, které může mít libovolnou délku. Navzdory svému názvu funguje dobře i při zadání pouze jednoho argumentu.
+
+```solidity
+ // Dvoubajtová hodnota, zakódovaná jako 0x1vvv
+ if (_key < 0x1000)
+ return bytes.concat(bytes2(uint16(_key) | 0x1000));
+```
+
+Pokud máme klíč, který je menší než 163, můžeme ho vyjádřit ve dvou bajtech. Nejprve převedeme `_key`, což je 256bitová hodnota, na 16bitovou hodnotu a pomocí logického součtu přidáme počet bajtů navíc k prvnímu bajtu. Poté ji převedeme na hodnotu `bytes2`, kterou lze převést na `bytes`.
+
+```solidity
+ // Pravděpodobně existuje chytrý způsob, jak provést následující řádky jako smyčku,
+ // ale je to funkce typu view, takže optimalizuji na čas programátora a
+ // jednoduchost.
+
+ if (_key < 16*256**2)
+ return bytes.concat(bytes3(uint24(_key) | (0x2 * 16 * 256**2)));
+ if (_key < 16*256**3)
+ return bytes.concat(bytes4(uint32(_key) | (0x3 * 16 * 256**3)));
+ .
+ .
+ .
+ if (_key < 16*256**14)
+ return bytes.concat(bytes15(uint120(_key) | (0xE * 16 * 256**14)));
+ if (_key < 16*256**15)
+ return bytes.concat(bytes16(uint128(_key) | (0xF * 16 * 256**15)));
+```
+
+Ostatní hodnoty (3 bajty, 4 bajty atd.) jsou zpracovávány stejným způsobem, jen s jinými velikostmi polí.
+
+```solidity
+ // Pokud se dostaneme sem, něco je špatně.
+ revert("Chyba v encodeVal, nemělo by se stát");
+```
+
+Pokud se dostaneme sem, znamená to, že jsme dostali klíč, který je větší než 16\*25615. Ale `cacheWrite` omezuje klíče, takže se nemůžeme dostat ani na 14\*25616 (což by mělo první bajt 0xFE, takže by to vypadalo jako `DONT_CACHE`). Ale přidání testu pro případ, že budoucí programátor zavede chybu, nás moc nestojí.
+
+```solidity
+ } // encodeVal
+
+} // Cache
+```
+
+### Testování cache {#testing-the-cache}
+
+Jednou z výhod Foundry je, že [vám umožňuje psát testy v Solidity](https://getfoundry.sh/forge/tests/overview/), což usnadňuje psaní jednotkových testů. Testy pro třídu `Cache` jsou [zde](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/Cache.t.sol). Protože testovací kód je repetitivní, jak už to u testů bývá, tento článek vysvětluje pouze zajímavé části.
+
+```solidity
+// SPDX-License-Identifier: UNLICENSED
+pragma solidity ^0.8.13;
+
+import "forge-std/Test.sol";
+
+
+// Je potřeba spustit `forge test -vv` pro konzoli.
+import "forge-std/console.sol";
+```
+
+Toto je pouze boilerplate, který je nezbytný pro použití testovacího balíčku a `console.log`.
+
+```solidity
+import "src/Cache.sol";
+```
+
+Potřebujeme znát kontrakt, který testujeme.
+
+```solidity
+contract CacheTest is Test {
+ Cache cache;
+
+ function setUp() public {
+ cache = new Cache();
+ }
+```
+
+Funkce `setUp` se volá před každým testem. V tomto případě pouze vytvoříme novou cache, aby se naše testy navzájem neovlivňovaly.
+
+```solidity
+ function testCaching() public {
+```
+
+Testy jsou funkce, jejichž názvy začínají na `test`. Tato funkce kontroluje základní funkčnost cache, zapisuje hodnoty a znovu je čte.
+
+```solidity
+ for(uint i=1; i<5000; i++) {
+ cache.cacheWrite(i*i);
+ }
+
+ for(uint i=1; i<5000; i++) {
+ assertEq(cache.cacheRead(i), i*i);
+```
+
+Takto se provádí skutečné testování pomocí [funkcí `assert...`](https://getfoundry.sh/reference/forge-std/std-assertions/). V tomto případě kontrolujeme, že hodnota, kterou jsme zapsali, je ta, kterou jsme přečetli. Výsledek `cache.cacheWrite` můžeme zahodit, protože víme, že klíče cache jsou přiřazovány lineárně.
+
+```solidity
+ }
+ } // testCaching
+
+
+ // Cachovat stejnou hodnotu vícekrát, zajistit, aby klíč zůstal
+ // stejný
+ function testRepeatCaching() public {
+ for(uint i=1; i<100; i++) {
+ uint _key1 = cache.cacheWrite(i);
+ uint _key2 = cache.cacheWrite(i);
+ assertEq(_key1, _key2);
+ }
+```
+
+Nejprve zapíšeme každou hodnotu dvakrát do cache a ujistíme se, že klíče jsou stejné (což znamená, že druhý zápis se ve skutečnosti neuskutečnil).
+
+```solidity
+ for(uint i=1; i<100; i+=3) {
+ uint _key = cache.cacheWrite(i);
+ assertEq(_key, i);
+ }
+ } // testRepeatCaching
+```
+
+Teoreticky by mohla existovat chyba, která neovlivní po sobě jdoucí zápisy do cache. Takže zde provedeme několik zápisů, které nejsou po sobě jdoucí, a uvidíme, že hodnoty se stále nepřepisují.
+
+```solidity
+ // Přečte uint z bufferu v paměti (abychom se ujistili, že dostaneme zpět parametry,
+ // které jsme odeslali)
+ function toUint256(bytes memory _bytes, uint256 _start) internal pure
+ returns (uint256)
+```
+
+Přečte 256bitové slovo z bufferu `bytes memory`. Tato pomocná funkce nám umožňuje ověřit, že při spuštění volání funkce, která používá cache, obdržíme správné výsledky.
+
+```solidity
+ {
+ require(_bytes.length >= _start + 32, "toUint256_outOfBounds");
+ uint256 tempUint;
+
+ assembly {
+ tempUint := mload(add(add(_bytes, 0x20), _start))
+ }
+```
+
+Yul nepodporuje datové struktury nad rámec `uint256`, takže když odkazujete na sofistikovanější datovou strukturu, jako je paměťový buffer `_bytes`, získáte adresu této struktury. Solidity ukládá hodnoty `bytes memory` jako 32bajtové slovo, které obsahuje délku, následované skutečnými bajty, takže pro získání bajtu číslo `_start` musíme vypočítat `_bytes+32+_start`.
+
+```solidity
+
+ return tempUint;
+ } // toUint256
+
+ // Podpis funkce pro fourParams(), s laskavým svolením
+ // https://www.4byte.directory/signatures/?bytes4_signature=0x3edc1e6d
+ bytes4 constant FOUR_PARAMS = 0x3edc1e6d;
+
+ // Jen několik konstantních hodnot, abychom viděli, že dostáváme zpět správné hodnoty
+ uint256 constant VAL_A = 0xDEAD60A7;
+ uint256 constant VAL_B = 0xBEEF;
+ uint256 constant VAL_C = 0x600D;
+ uint256 constant VAL_D = 0x600D60A7;
+```
+
+Některé konstanty, které potřebujeme pro testování.
+
+```solidity
+ function testReadParam() public {
+```
+
+Zavoláním `fourParams()`, funkce, která používá `readParams`, otestujeme, zda umíme správně číst parametry.
+
+```solidity
+ address _cacheAddr = address(cache);
+ bool _success;
+ bytes memory _callInput;
+ bytes memory _callOutput;
+```
+
+Nemůžeme použít normální mechanismus ABI pro volání funkce pomocí cache, takže musíme použít nízkoúrovňový mechanismus [`.call()`](https://docs.soliditylang.org/en/v0.8.16/types.html#members-of-addresses). Tento mechanismus přijímá jako vstup `bytes memory` a vrací je (stejně jako booleovskou hodnotu) jako výstup.
+
+```solidity
+ // První volání, cache je prázdná
+ _callInput = bytes.concat(
+ FOUR_PARAMS,
+```
+
+Je užitečné, aby stejný kontrakt podporoval jak cachované funkce (pro volání přímo z transakcí), tak i necachované funkce (pro volání z jiných chytrých kontraktů). Abychom toho dosáhli, musíme se nadále spoléhat na mechanismus Solidity pro volání správné funkce, namísto toho, abychom vše vkládali do [funkce `fallback`](https://docs.soliditylang.org/en/v0.8.16/contracts.html#fallback-function). Tímto způsobem je kompozitnost mnohem snazší. Jeden bajt by ve většině případů stačil k identifikaci funkce, takže plýtváme třemi bajty (16\*3=48 gasu). Nicméně, v době psaní tohoto článku stojí těchto 48 gasů 0,07 centů, což je rozumná cena za jednodušší a méně chybový kód.
+
+```solidity
+ // První hodnota, přidejte ji do cache
+ cache.INTO_CACHE(),
+ bytes32(VAL_A),
+```
+
+První hodnota: Příznak, který říká, že je to plná hodnota, která se musí zapsat do cache, následovaný 32 bajty hodnoty. Ostatní tři hodnoty jsou podobné, s výjimkou toho, že `VAL_B` se do cache nezapisuje a `VAL_C` je jak třetím, tak čtvrtým parametrem.
+
+```solidity
+ .
+ .
+ .
+ );
+ (_success, _callOutput) = _cacheAddr.call(_callInput);
+```
+
+Zde skutečně voláme kontrakt `Cache`.
+
+```solidity
+ assertEq(_success, true);
+```
+
+Očekáváme, že volání bude úspěšné.
+
+```solidity
+ assertEq(cache.cacheRead(1), VAL_A);
+ assertEq(cache.cacheRead(2), VAL_C);
+```
+
+Začínáme s prázdnou cache a poté přidáme `VAL_A` následované `VAL_C`. Očekávali bychom, že první bude mít klíč 1 a druhý klíč 2.
+
+```
+ assertEq(toUint256(_callOutput,0), VAL_A);
+ assertEq(toUint256(_callOutput,32), VAL_B);
+ assertEq(toUint256(_callOutput,64), VAL_C);
+ assertEq(toUint256(_callOutput,96), VAL_C);
+```
+
+Výstupem jsou čtyři parametry. Zde ověřujeme, že je správný.
+
+```solidity
+ // Druhé volání, můžeme použít cache
+ _callInput = bytes.concat(
+ FOUR_PARAMS,
+
+ // První hodnota v cache
+ bytes1(0x01),
+```
+
+Klíče cache pod 16 jsou pouze jeden bajt.
+
+```solidity
+ // Druhá hodnota, nepřidávejte ji do cache
+ cache.DONT_CACHE(),
+ bytes32(VAL_B),
+
+ // Třetí a čtvrtá hodnota, stejná hodnota
+ bytes1(0x02),
+ bytes1(0x02)
+ );
+ .
+ .
+ .
+ } // testReadParam
+```
+
+Testy po volání jsou totožné s testy po prvním volání.
+
+```solidity
+ function testEncodeVal() public {
+```
+
+Tato funkce je podobná funkci `testReadParam`, s výjimkou toho, že místo explicitního psaní parametrů používáme `encodeVal()`.
+
+```solidity
+ .
+ .
+ .
+ _callInput = bytes.concat(
+ FOUR_PARAMS,
+ cache.encodeVal(VAL_A),
+ cache.encodeVal(VAL_B),
+ cache.encodeVal(VAL_C),
+ cache.encodeVal(VAL_D)
+ );
+ .
+ .
+ .
+ assertEq(_callInput.length, 4+1*4);
+ } // testEncodeVal
+```
+
+Jediný dodatečný test v `testEncodeVal()` je ověření, že délka `_callInput` je správná. Pro první volání je to 4+33\*4. Pro druhé, kde je každá hodnota již v cache, je to 4+1\*4.
+
+```solidity
+ // Testujte encodeVal, když je klíč delší než jeden bajt
+ // Maximálně tři bajty, protože plnění cache na čtyři bajty trvá
+ // příliš dlouho.
+ function testEncodeValBig() public {
+ // Vložte několik hodnot do cache.
+ // Pro zjednodušení použijte klíč n pro hodnotu n.
+ for(uint i=1; i<0x1FFF; i++) {
+ cache.cacheWrite(i);
+ }
+```
+
+Výše uvedená funkce `testEncodeVal` zapisuje do cache pouze čtyři hodnoty, takže [část funkce, která se zabývá vícebajtovými hodnotami](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol#L144-L171) se nekontroluje. Ale tento kód je složitý a náchylný k chybám.
+
+První část této funkce je smyčka, která zapisuje všechny hodnoty od 1 do 0x1FFF do cache v pořadí, takže budeme moci tyto hodnoty zakódovat a vědět, kam jdou.
+
+```solidity
+ .
+ .
+ .
+
+ _callInput = bytes.concat(
+ FOUR_PARAMS,
+ cache.encodeVal(0x000F), // Jeden bajt 0x0F
+ cache.encodeVal(0x0010), // Dva bajty 0x1010
+ cache.encodeVal(0x0100), // Dva bajty 0x1100
+ cache.encodeVal(0x1000) // Tři bajty 0x201000
+ );
+```
+
+Otestujte jednobajtové, dvoubajtové a tříbajtové hodnoty. Dále netestujeme, protože by trvalo příliš dlouho zapsat dostatek položek zásobníku (alespoň 0x10000000, přibližně čtvrt miliardy).
+
+```solidity
+ .
+ .
+ .
+ .
+ } // testEncodeValBig
+
+
+ // Otestujte, co se stane s příliš malým bufferem, dostaneme revert
+ function testShortCalldata() public {
+```
+
+Otestujte, co se stane v abnormálním případě, kdy není dostatek parametrů.
+
+```solidity
+ .
+ .
+ .
+ (_success, _callOutput) = _cacheAddr.call(_callInput);
+ assertEq(_success, false);
+ } // testShortCalldata
+```
+
+Jelikož se to vrací, výsledek, který bychom měli dostat, je `false`.
+
+```
+ // Volání s klíči cache, které tam nejsou
+ function testNoCacheKey() public {
+ .
+ .
+ .
+ _callInput = bytes.concat(
+ FOUR_PARAMS,
+
+ // První hodnota, přidejte ji do cache
+ cache.INTO_CACHE(),
+ bytes32(VAL_A),
+
+ // Druhá hodnota
+ bytes1(0x0F),
+ bytes2(0x1234),
+ bytes11(0xA10102030405060708090A)
+ );
+```
+
+Tato funkce dostane čtyři naprosto legitimní parametry, s výjimkou toho, že cache je prázdná, takže tam nejsou žádné hodnoty ke čtení.
+
+```solidity
+ .
+ .
+ .
+ // Otestujte, co s příliš dlouhým bufferem, vše funguje
+ function testLongCalldata() public {
+ address _cacheAddr = address(cache);
+ bool _success;
+ bytes memory _callInput;
+ bytes memory _callOutput;
+
+ // První volání, cache je prázdná
+ _callInput = bytes.concat(
+ FOUR_PARAMS,
+
+ // První hodnota, přidejte ji do cache
+ cache.INTO_CACHE(), bytes32(VAL_A),
+
+ // Druhá hodnota, přidejte ji do cache
+ cache.INTO_CACHE(), bytes32(VAL_B),
+
+ // Třetí hodnota, přidejte ji do cache
+ cache.INTO_CACHE(), bytes32(VAL_C),
+
+ // Čtvrtá hodnota, přidejte ji do cache
+ cache.INTO_CACHE(), bytes32(VAL_D),
+
+ // A další hodnota pro „štěstí“
+ bytes4(0x31112233)
+ );
+```
+
+Tato funkce posílá pět hodnot. Víme, že pátá hodnota je ignorována, protože se nejedná o platný záznam cache, což by způsobilo vrácení, kdyby nebyla zahrnuta.
+
+```solidity
+ (_success, _callOutput) = _cacheAddr.call(_callInput);
+ assertEq(_success, true);
+ .
+ .
+ .
+ } // testLongCalldata
+
+} // CacheTest
+
+```
+
+## Ukázková aplikace {#a-sample-app}
+
+Psaní testů v Solidity je sice skvělé, ale aby byla dapp užitečná, musí být schopna zpracovávat požadavky i mimo blockchain. Tento článek ukazuje, jak používat cachování v dapp s `WORM`, což znamená „Write Once, Read Many“ (Zapiš jednou, čti mnohokrát). Pokud klíč ještě není zapsán, můžete do něj zapsat hodnotu. Pokud je klíč již zapsán, dostanete revert.
+
+### Kontrakt {#the-contract}
+
+[Zde je kontrakt](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/WORM.sol). Většinou se opakuje to, co jsme již udělali s `Cache` a `CacheTest`, takže se budeme zabývat pouze zajímavými částmi.
+
+```solidity
+import "./Cache.sol";
+
+contract WORM is Cache {
+```
+
+Nejjednodušší způsob, jak použít `Cache`, je zdědit ho ve vlastním kontraktu.
+
+```solidity
+ function writeEntryCached() external {
+ uint[] memory params = _readParams(2);
+ writeEntry(params[0], params[1]);
+ } // writeEntryCached
+```
+
+Tato funkce je podobná `fourParam` ve výše uvedeném `CacheTest`. Protože se nedržíme specifikací ABI, je nejlepší do funkce nedeklarovat žádné parametry.
+
+```solidity
+ // Usnadněte si volání
+ // Podpis funkce pro writeEntryCached(), s laskavým svolením
+ // https://www.4byte.directory/signatures/?bytes4_signature=0xe4e4f2d3
+ bytes4 constant public WRITE_ENTRY_CACHED = 0xe4e4f2d3;
+```
+
+Externí kód, který volá `writeEntryCached`, bude muset manuálně sestavit calldata, namísto použití `worm.writeEntryCached`, protože nedodržujeme specifikace ABI. Tato konstantní hodnota pouze usnadňuje její zápis.
+
+Všimněte si, že i když definujeme `WRITE_ENTRY_CACHED` jako stavovou proměnnou, pro její externí čtení je nutné použít getter funkci, `worm.WRITE_ENTRY_CACHED()`.
+
+```solidity
+ function readEntry(uint key) public view
+ returns (uint _value, address _writtenBy, uint _writtenAtBlock)
+```
+
+Funkce čtení je `view`, takže nevyžaduje transakci a nestojí žádný gas. V důsledku toho nemá použití cache pro parametr žádný přínos. U funkcí typu view je nejlepší používat standardní mechanismus, který je jednodušší.
+
+### Testovací kód {#the-testing-code}
+
+[Zde je testovací kód pro kontrakt](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/WORM.t.sol). Opět se podívejme pouze na to, co je zajímavé.
+
+```solidity
+ function testWReadWrite() public {
+ worm.writeEntry(0xDEAD, 0x60A7);
+
+ vm.expectRevert(bytes("záznam již zapsán"));
+ worm.writeEntry(0xDEAD, 0xBEEF);
+```
+
+[Tímto (`vm.expectRevert`)](https://book.getfoundry.sh/cheatcodes/expect-revert#expectrevert) v testu Foundry specifikujeme, že další volání by mělo selhat, a uvádíme důvod selhání. To platí, když používáme syntaxi `.`()` spíše než vytváření calldata a volání kontraktu pomocí nízkoúrovňového rozhraní (`.call()\` atd.).
+
+```solidity
+ function testReadWriteCached() public {
+ uint cacheGoat = worm.cacheWrite(0x60A7);
+```
+
+Zde využíváme toho, že `cacheWrite` vrací klíč cache. To není něco, co bychom očekávali v produkci, protože `cacheWrite` mění stav, a proto může být volána pouze během transakce. Transakce nemají návratové hodnoty, pokud mají nějaké výsledky, mají být emitovány jako události. Návratová hodnota `cacheWrite` je tedy přístupná pouze z on-chain kódu a on-chain kód nepotřebuje cachování parametrů.
+
+```solidity
+ (_success,) = address(worm).call(_callInput);
+```
+
+Takto říkáme Solidity, že ačkoli `.call()` má dvě návratové hodnoty, zajímá nás pouze ta první.
+
+```solidity
+ (_success,) = address(worm).call(_callInput);
+ assertEq(_success, false);
+```
+
+Protože používáme nízkoúrovňovou funkci `.call()`, nemůžeme použít `vm.expectRevert()` a musíme se podívat na booleovskou hodnotu úspěchu, kterou získáme z volání.
+
+```solidity
+ event EntryWritten(uint indexed key, uint indexed value);
+
+ .
+ .
+ .
+
+ _callInput = bytes.concat(
+ worm.WRITE_ENTRY_CACHED(), worm.encodeVal(a), worm.encodeVal(b));
+ vm.expectEmit(true, true, false, false);
+ emit EntryWritten(a, b);
+ (_success,) = address(worm).call(_callInput);
+```
+
+Toto je způsob, jak ve Foundry ověřit, že kód [správně emituje událost](https://getfoundry.sh/reference/cheatcodes/expect-emit/).
+
+### Klient {#the-client}
+
+Jedna věc, kterou se testy v Solidity nezískáte, je JavaScriptový kód, který můžete zkopírovat a vložit do své vlastní aplikace. Abych mohl napsat tento kód, nasadil jsem WORM na [Optimism Goerli](https://community.optimism.io/docs/useful-tools/networks/#optimism-goerli), nový testnet [Optimismu](https://www.optimism.io/). Je na adrese [`0xd34335b1d818cee54e3323d3246bd31d94e6a78a`](https://goerli-optimism.etherscan.io/address/0xd34335b1d818cee54e3323d3246bd31d94e6a78a).
+
+[Zde si můžete prohlédnout JavaScriptový kód pro klienta](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/javascript/index.js). Použití:
+
+1. Klonujte git repozitář:
+
+ ```sh
+ git clone https://github.com/qbzzt/20220915-all-you-can-cache.git
+ ```
+
+2. Nainstalujte potřebné balíčky:
+
+ ```sh
+ cd javascript
+ yarn
+ ```
+
+3. Zkopírujte konfigurační soubor:
+
+ ```sh
+ cp .env.example .env
+ ```
+
+4. Upravte `.env` pro vaši konfiguraci:
+
+ | Parametr | Hodnota |
+ | ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+ | MNEMONIC | Mnemotechnická pomůcka pro účet, který má dostatek ETH na zaplacení transakce. [Zde můžete získat ETH zdarma pro síť Optimism Goerli](https://optimismfaucet.xyz/). |
+ | OPTIMISM_GOERLI_URL | URL k Optimism Goerli. Veřejný koncový bod `https://goerli.optimism.io` má omezenou rychlost, ale pro naše potřeby je dostačující. |
+
+5. Spusťte `index.js`.
+
+ ```sh
+ node index.js
+ ```
+
+ Tato ukázková aplikace nejprve zapíše položku do WORM, zobrazí calldata a odkaz na transakci na Etherscanu. Poté přečte zpět tuto položku a zobrazí klíč, který používá, a hodnoty v položce (hodnota, číslo bloku a autor).
+
+Většina klienta je normální Dapp JavaScript. Takže opět projdeme jen zajímavé části.
+
+```javascript
+.
+.
+.
+const main = async () => {
+ const func = await worm.WRITE_ENTRY_CACHED()
+
+ // Pokaždé je potřeba nový klíč
+ const key = await worm.encodeVal(Number(new Date()))
+```
+
+Do daného slotu lze zapsat pouze jednou, takže použijeme časové razítko, abychom se ujistili, že sloty nepoužíváme opakovaně.
+
+```javascript
+const val = await worm.encodeVal("0x600D")
+
+// Zapište položku
+const calldata = func + key.slice(2) + val.slice(2)
+```
+
+Ethers očekává, že data volání budou hexadecimální řetězec, `0x` následovaný sudým počtem hexadecimálních číslic. Protože `key` i `val` začínají na `0x`, musíme tyto hlavičky odstranit.
+
+```javascript
+const tx = await worm.populateTransaction.writeEntryCached()
+tx.data = calldata
+
+sentTx = await wallet.sendTransaction(tx)
+```
+
+Stejně jako u testovacího kódu Solidity nemůžeme cachovanou funkci volat normálně. Místo toho musíme použít nízkoúrovňový mechanismus.
+
+```javascript
+ .
+ .
+ .
+ // Přečtěte právě zapsanou položku
+ const realKey = '0x' + key.slice(4) // odstraňte příznak FF
+ const entryRead = await worm.readEntry(realKey)
+ .
+ .
+ .
+```
+
+Pro čtení položek můžeme použít normální mechanismus. U funkcí `view` není třeba používat cachování parametrů.
+
+## Závěr {#conclusion}
+
+Kód v tomto článku je proof of concept, jehož účelem je usnadnit pochopení myšlenky. Pro produkční systém byste mohli chtít implementovat některé další funkce:
+
+- Zpracování hodnot, které nejsou `uint256`. Například řetězce.
+- Místo globální cache možná mít mapování mezi uživateli a cachemi. Různí uživatelé používají různé hodnoty.
+- Hodnoty používané pro adresy se liší od hodnot používaných pro jiné účely. Mohlo by mít smysl mít samostatnou cache pouze pro adresy.
+- V současné době jsou klíče cache založeny na algoritmu „kdo dřív přijde, ten má nejmenší klíč“. Prvních šestnáct hodnot lze odeslat jako jeden bajt. Dalších 4080 hodnot lze odeslat jako dva bajty. Další přibližně milion hodnot jsou tři bajty atd. Produkční systém by měl vést počítadla použití záznamů cache a reorganizovat je tak, aby šestnáct _nejběžnějších_ hodnot bylo jednobajtových, dalších 4080 nejběžnějších hodnot dvoubajtových atd.
+
+ To je však potenciálně nebezpečná operace. Představte si následující sled událostí:
+
+ 1. Noam Naive zavolá `encodeVal` k zakódování adresy, na kterou chce poslat tokeny. Tato adresa je jedna z prvních použitých v aplikaci, takže zakódovaná hodnota je 0x06. Toto je funkce `view`, ne transakce, takže je to mezi Noamem a uzlem, který používá, a nikdo jiný o tom neví.
+
+ 2. Owen Owner spustí operaci přeuspořádání cache. Velmi málo lidí skutečně používá tuto adresu, takže je nyní zakódována jako 0x201122. Jiná hodnota, 1018, je přiřazena 0x06.
+
+ 3. Noam Naive posílá své tokeny na 0x06. Dostanou se na adresu `0x0000000000000000000000000de0b6b3a7640000`, a protože nikdo nezná soukromý klíč k této adrese, jsou tam prostě zaseknuté. Noam _není spokojený_.
+
+ Existují způsoby, jak tento problém vyřešit, a související problém transakcí, které jsou v mempoolu během přeuspořádání cache, ale musíte si toho být vědomi.
+
+Cachování jsem zde demonstroval na Optimismu, protože jsem zaměstnancem Optimismu a je to rollup, který znám nejlépe. Mělo by to ale fungovat s jakýmkoli rollupem, který si účtuje minimální náklady na interní zpracování, takže v porovnání s tím je zápis transakčních dat na L1 hlavním nákladem.
+
+[Více z mé práce najdete zde](https://cryptodocguy.pro/).
+
diff --git a/public/content/translations/cs/developers/tutorials/app-plasma/index.md b/public/content/translations/cs/developers/tutorials/app-plasma/index.md
new file mode 100644
index 00000000000..9950893116e
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/app-plasma/index.md
@@ -0,0 +1,1255 @@
+---
+title: Napište plazmu specifickou pro aplikaci, která zachovává soukromí
+description: V tomto návodu vytvoříme polotajnou banku pro vklady. Banka je centralizovanou součástí; zná zůstatek každého uživatele. Tato informace se však neukládá na blockchainu. Místo toho banka zveřejňuje hash stavu. Pokaždé, když dojde k transakci, banka zveřejní nový hash spolu s důkazem s nulovou znalostí, že má podepsanou transakci, která mění stav hashe na nový. Po přečtení tohoto návodu nejenže pochopíte, jak používat důkazy s nulovou znalostí, ale také proč je používat a jak to dělat bezpečně.
+author: Ori Pomerantz
+tags: [ "nulová znalost", "server", "offchain", "soukromí" ]
+skill: advanced
+lang: cs
+published: 2025-10-15
+---
+
+## Úvod {#introduction}
+
+Na rozdíl od [rollupů](/developers/docs/scaling/zk-rollups/) používají [plazmy](/developers/docs/scaling/plasma) hlavní síť Ethereum k zajištění integrity, nikoli však dostupnosti. V tomto článku napíšeme aplikaci, která se chová jako plazma, přičemž Ethereum zaručuje integritu (žádné neoprávněné změny), ale nikoli dostupnost (centralizovaná součást může selhat a vyřadit celý systém).
+
+Aplikace, kterou zde píšeme, je banka zachovávající soukromí. Různé adresy mají účty se zůstatky a mohou posílat peníze (ETH) na jiné účty. Banka zveřejňuje hashe stavu (účty a jejich zůstatky) a transakce, ale skutečné zůstatky drží mimo blockchain, kde mohou zůstat soukromé.
+
+## Návrh {#design}
+
+Nejedná se o systém připravený pro produkční nasazení, ale o výukový nástroj. Jako takový je napsán s několika zjednodušujícími předpoklady.
+
+- Pevně daný fond účtů. Existuje určitý počet účtů a každý účet patří na předem určenou adresu. Díky tomu je systém mnohem jednodušší, protože v důkazech s nulovou znalostí je obtížné pracovat s datovými strukturami s proměnlivou velikostí. Pro systém připravený pro produkční nasazení můžeme použít [Merkle kořen](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) jako hash stavu a poskytnout Merkle důkazy pro požadované zůstatky.
+
+- Ukládání do paměti. V produkčním systému je třeba zapisovat všechny zůstatky na účtech na disk, aby se zachovaly pro případ restartu. Zde je v pořádku, pokud se informace jednoduše ztratí.
+
+- Pouze převody. Produkční systém by vyžadoval způsob, jak vkládat prostředky do banky a jak je vybírat. Cílem je zde však pouze ilustrovat koncept, takže tato banka je omezena na převody.
+
+### Důkazy s nulovou znalostí {#zero-knowledge-proofs}
+
+Na základní úrovni důkaz s nulovou znalostí ukazuje, že dokazující zná nějaká data, _Datasoukromá_, taková, že existuje vztah _Vztah_ mezi nějakými veřejnými daty, _Dataveřejná_, a _Datasoukromá_. Ověřovatel zná _Vztah_ a _Dataveřejná_.
+
+Abychom zachovali soukromí, je třeba, aby stavy a transakce byly soukromé. Abychom však zajistili integritu, potřebujeme, aby [kryptografický hash](https://en.wikipedia.org/wiki/Cryptographic_hash_function) stavů byl veřejný. Abychom lidem, kteří odesílají transakce, dokázali, že se tyto transakce skutečně uskutečnily, musíme také zveřejňovat hashe transakcí.
+
+Ve většině případů je _Datasoukromá_ vstupem do programu důkazu s nulovou znalostí a _Dataveřejná_ je výstupem.
+
+Tato pole v _Datasoukromá_:
+
+- _Stavn_, starý stav
+- _Stavn+1_, nový stav
+- _Transakce_, transakce, která mění starý stav na nový. Tato transakce musí obsahovat tato pole:
+ - _Cílová adresa_, která přijímá převod
+ - _Částka_, která se převádí
+ - _Nonce_, aby se zajistilo, že každá transakce může být zpracována pouze jednou.
+ Zdrojová adresa nemusí být v transakci, protože ji lze obnovit z podpisu.
+- _Podpis_, podpis, který je oprávněn provést transakci. V našem případě je jedinou adresou oprávněnou k provedení transakce zdrojová adresa. Protože náš systém s nulovou znalostí funguje tak, jak funguje, potřebujeme kromě podpisu Ethereum také veřejný klíč účtu.
+
+Toto jsou pole v _Dataveřejná_:
+
+- _Hash(Stavn)_ hash starého stavu
+- _Hash(Stavn+1)_ hash nového stavu
+- _Hash(Transakce)_ hash transakce, která mění stav ze _Stavun_ na _Stavn+1_.
+
+Vztah kontroluje několik podmínek:
+
+- Veřejné hashe jsou skutečně správnými hashi pro soukromá pole.
+- Transakce, když se aplikuje na starý stav, má za následek nový stav.
+- Podpis pochází ze zdrojové adresy transakce.
+
+Vzhledem k vlastnostem kryptografických hashovacích funkcí stačí prokázat tyto podmínky k zajištění integrity.
+
+### Datové struktury {#data-structures}
+
+Primární datovou strukturou je stav, který uchovává server. Pro každý účet server sleduje zůstatek na účtu a [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce), které se používá k zabránění [opakovacím útokům](https://en.wikipedia.org/wiki/Replay_attack).
+
+### Komponenty {#components}
+
+Tento systém vyžaduje dvě součásti:
+
+- _Server_, který přijímá transakce, zpracovává je a zveřejňuje hashe na řetězci spolu s důkazy s nulovou znalostí.
+- _Chytrý kontrakt_, který ukládá hashe a ověřuje důkazy s nulovou znalostí, aby se zajistilo, že přechody stavů jsou legitimní.
+
+### Datový a řídicí tok {#flows}
+
+Toto jsou způsoby, jakými jednotlivé součásti komunikují při převodu z jednoho účtu na druhý.
+
+1. Webový prohlížeč odešle podepsanou transakci s žádostí o převod z účtu podepisujícího na jiný účet.
+
+2. Server ověří, že transakce je platná:
+
+ - Podepisující má v bance účet s dostatečným zůstatkem.
+ - Příjemce má v bance účet.
+
+3. Server vypočítá nový stav odečtením převedené částky od zůstatku podepisujícího a jejím přičtením k zůstatku příjemce.
+
+4. Server vypočítá důkaz s nulovou znalostí, že změna stavu je platná.
+
+5. Server odešle na Ethereum transakci, která obsahuje:
+
+ - Nový hash stavu
+ - Hash transakce (aby odesílatel transakce věděl, že byla zpracována)
+ - Důkaz s nulovou znalostí, který dokazuje, že přechod do nového stavu je platný
+
+6. Chytrý kontrakt ověří důkaz s nulovou znalostí.
+
+7. Pokud se důkaz s nulovou znalostí ověří, chytrý kontrakt provede tyto akce:
+ - Aktualizace současného hashe stavu na nový hash stavu
+ - Vydá záznam do protokolu s novým hashem stavu a hashem transakce
+
+### Nástroje {#tools}
+
+Pro kód na straně klienta použijeme [Vite](https://vite.dev/), [React](https://react.dev/), [Viem](https://viem.sh/) a [Wagmi](https://wagmi.sh/). Jedná se o standardní nástroje v oboru; pokud je neznáte, můžete použít [tento tutoriál](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/).
+
+Většina serveru je napsána v JavaScriptu pomocí [Node](https://nodejs.org/en). Část s nulovou znalostí je napsána v jazyce [Noir](https://noir-lang.org/). Potřebujeme verzi `1.0.0-beta.10`, takže po [instalaci Noir podle pokynů](https://noir-lang.org/docs/getting_started/quick_start) spusťte:
+
+```
+noirup -v 1.0.0-beta.10
+```
+
+Blockchain, který používáme, je `anvil`, lokální testovací blockchain, který je součástí [Foundry](https://getfoundry.sh/introduction/installation).
+
+## Implementace {#implementation}
+
+Protože se jedná o složitý systém, budeme ho implementovat postupně.
+
+### Fáze 1 – Ruční nulová znalost {#stage-1}
+
+V první fázi podepíšeme transakci v prohlížeči a poté ručně poskytneme informace do důkazu s nulovou znalostí. Kód nulové znalosti očekává, že tyto informace získá v souboru `server/noir/Prover.toml` (zdokumentováno [zde](https://noir-lang.org/docs/getting_started/project_breakdown#provertoml-1)).
+
+Chcete-li to vidět v akci:
+
+1. Ujistěte se, že máte nainstalovaný [Node](https://nodejs.org/en/download) a [Noir](https://noir-lang.org/install). Nejlépe je nainstalujte na systém UNIX, jako je macOS, Linux nebo [WSL](https://learn.microsoft.com/en-us/windows/wsl/install).
+
+2. Stáhněte si kód 1. fáze a spusťte webový server, který bude obsluhovat kód klienta.
+
+ ```sh
+ git clone https://github.com/qbzzt/250911-zk-bank.git -b 01-manual-zk
+ cd 250911-zk-bank
+ cd client
+ npm install
+ npm run dev
+ ```
+
+ Důvod, proč zde potřebujete webový server, je ten, že aby se předešlo určitým typům podvodů, mnoho peněženek (například MetaMask) nepřijímá soubory obsluhované přímo z disku.
+
+3. Otevřete prohlížeč s peněženkou.
+
+4. V peněžence zadejte novou heslovou frázi. Upozorňujeme, že tímto smažete stávající heslovou frázi, takže _se ujistěte, že máte zálohu_.
+
+ Heslová fráze je `test test test test test test test test test test test junk`, výchozí testovací heslová fráze pro anvil.
+
+5. Přejděte na [kód na straně klienta](http://localhost:5173/).
+
+6. Připojte se k peněžence a vyberte cílový účet a částku.
+
+7. Klikněte na **Podepsat** a podepište transakci.
+
+8. Pod nadpisem **Prover.toml** najdete text. Nahraďte soubor `server/noir/Prover.toml` tímto textem.
+
+9. Spusťte důkaz s nulovou znalostí.
+
+ ```sh
+ cd ../server/noir
+ nargo execute
+ ```
+
+ Výstup by měl být podobný tomuto
+
+ ```
+ ori@CryptoDocGuy:~/noir/250911-zk-bank/server/noir$ nargo execute
+
+ [zkBank] Circuit witness successfully solved
+ [zkBank] Witness saved to target/zkBank.gz
+ [zkBank] Circuit output: (0x199aa62af8c1d562a6ec96e66347bf3240ab2afb5d022c895e6bf6a5e617167b, 0x0cfc0a67cb7308e4e9b254026b54204e34f6c8b041be207e64c5db77d95dd82d, 0x450cf9da6e180d6159290554ae3d8787, 0x6d8bc5a15b9037e52fb59b6b98722a85)
+ ```
+
+10. Porovnejte poslední dvě hodnoty s hashem, který vidíte ve webovém prohlížeči, abyste zjistili, zda je zpráva správně zahashována.
+
+#### `server/noir/Prover.toml` {#server-noir-prover-toml}
+
+[Tento soubor](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Prover.toml) ukazuje formát informací, který očekává Noir.
+
+```toml
+zpráva="odeslat 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 500 finney (milliEth) 0 "
+```
+
+Zpráva je v textovém formátu, což usnadňuje její pochopení uživatelem (což je nutné při podepisování) a její zpracování kódem Noir. Částka je uvedena ve finney, aby bylo možné na jedné straně provádět zlomkové převody a na druhé straně byla snadno čitelná. Poslední číslo je [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce).
+
+Řetězec je dlouhý 100 znaků. Důkazy s nulovou znalostí si dobře neporadí s daty s proměnlivou velikostí, proto je často nutné data doplňovat.
+
+```toml
+pubKeyX=["0x83",...,"0x75"]
+pubKeyY=["0x35",...,"0xa5"]
+signature=["0xb1",...,"0x0d"]
+```
+
+Tyto tři parametry jsou bajtová pole s pevnou velikostí.
+
+```toml
+[[účty]]
+adresa="0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266"
+zůstatek=100_000
+nonce=0
+
+[[účty]]
+adresa="0x70997970C51812dc3A010C7d01b50e0d17dc79C8"
+zůstatek=100_000
+nonce=0
+```
+
+Tímto způsobem se specifikuje pole struktur. Pro každou položku zadáme adresu, zůstatek (v milliETH, známé také jako [finney](https://cryptovalleyjournal.com/glossary/finney/)) a další hodnotu nonce.
+
+#### `client/src/Transfer.tsx` {#client-src-transfer-tsx}
+
+[Tento soubor](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/client/src/Transfer.tsx) implementuje zpracování na straně klienta a generuje soubor `server/noir/Prover.toml` (ten, který obsahuje parametry nulové znalosti).
+
+Zde je vysvětlení zajímavějších částí.
+
+```tsx
+export default attrs => {
+```
+
+Tato funkce vytváří komponentu `Transfer` Reactu, kterou mohou importovat další soubory.
+
+```tsx
+ const accounts = [
+ "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",
+ "0x70997970C51812dc3A010C7d01b50e0d17dc79C8",
+ "0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC",
+ "0x90F79bf6EB2c4f870365E785982E1f101E93b906",
+ "0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65",
+ ]
+```
+
+Toto jsou adresy účtů, adresy vytvořené pomocí `test ...` heslové fráze `test junk`. Pokud chcete použít vlastní adresy, stačí upravit tuto definici.
+
+```tsx
+ const account = useAccount()
+ const wallet = createWalletClient({
+ transport: custom(window.ethereum!)
+ })
+```
+
+Tyto [Wagmi hooky](https://wagmi.sh/react/api/hooks) nám umožňují přístup ke knihovně [viem](https://viem.sh/) a k peněžence.
+
+```tsx
+ const message = `send ${toAccount} ${ethAmount*1000} finney (milliEth) ${nonce}`.padEnd(100, " ")
+```
+
+Toto je zpráva, doplněná mezerami. Pokaždé, když se změní jedna z proměnných [`useState`](https://react.dev/reference/react/useState), komponenta se překreslí a `zpráva` se aktualizuje.
+
+```tsx
+ const sign = async () => {
+```
+
+Tato funkce je volána, když uživatel klikne na tlačítko **Podepsat**. Zpráva se automaticky aktualizuje, ale podpis vyžaduje schválení uživatelem v peněžence a my o něj nechceme žádat, pokud to není nutné.
+
+```tsx
+ const signature = await wallet.signMessage({
+ account: fromAccount,
+ message,
+ })
+```
+
+Požádejte peněženku o [podepsání zprávy](https://viem.sh/docs/accounts/local/signMessage).
+
+```tsx
+ const hash = hashMessage(message)
+```
+
+Získejte hash zprávy. Je užitečné poskytnout ho uživateli pro ladění (kódu Noir).
+
+```tsx
+ const pubKey = await recoverPublicKey({
+ hash,
+ signature
+ })
+```
+
+[Získejte veřejný klíč](https://viem.sh/docs/utilities/recoverPublicKey). To je nutné pro funkci [Noir `ecrecover`](https://github.com/colinnielsen/ecrecover-noir).
+
+```tsx
+ setSignature(signature)
+ setHash(hash)
+ setPubKey(pubKey)
+```
+
+Nastavte stavové proměnné. Tímto se komponenta překreslí (po ukončení funkce `sign`) a uživateli se zobrazí aktualizované hodnoty.
+
+```tsx
+ let proverToml = `
+```
+
+Text pro `Prover.toml`.
+
+```tsx
+message="${message}"
+
+pubKeyX=${hexToArray(pubKey.slice(4,4+2*32))}
+pubKeyY=${hexToArray(pubKey.slice(4+2*32))}
+```
+
+Viem nám poskytuje veřejný klíč jako 65bajtový hexadecimální řetězec. První bajt je `0x04`, označení verze. Následuje 32 bajtů pro `x` veřejného klíče a poté 32 bajtů pro `y` veřejného klíče.
+
+Noir však očekává, že tyto informace získá jako dvě bajtová pole, jedno pro `x` a jedno pro `y`. Je snazší ho analyzovat zde na straně klienta než v rámci důkazu s nulovou znalostí.
+
+Všimněte si, že se obecně jedná o dobrou praxi v oblasti nulové znalosti. Kód uvnitř důkazu s nulovou znalostí je nákladný, takže jakékoli zpracování, které lze provést mimo důkaz s nulovou znalostí, _by se mělo_ provádět mimo důkaz s nulovou znalostí.
+
+```tsx
+signature=${hexToArray(signature.slice(2,-2))}
+```
+
+Podpis je také poskytován jako 65bajtový hexadecimální řetězec. Poslední bajt je však nutný pouze k obnovení veřejného klíče. Protože veřejný klíč bude již poskytnut kódu Noir, nepotřebujeme ho k ověření podpisu a kód Noir ho nevyžaduje.
+
+```tsx
+${accounts.map(accountInProverToml).reduce((a,b) => a+b, "")}
+`
+```
+
+Poskytněte účty.
+
+```tsx
+ setProverToml(proverToml)
+ }
+
+ return (
+ <>
+ Převod
+```
+
+Toto je formát HTML (přesněji [JSX](https://react.dev/learn/writing-markup-with-jsx)) komponenty.
+
+#### `server/noir/src/main.nr` {#server-noir-src-main-nr}
+
+[Tento soubor](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/src/main.nr) je skutečný kód nulové znalosti.
+
+```
+use std::hash::pedersen_hash;
+```
+
+[Pedersen hash](https://rya-sge.github.io/access-denied/2024/05/07/pedersen-hash-function/) je poskytován se [standardní knihovnou Noir](https://noir-lang.org/docs/noir/standard_library/cryptographic_primitives/hashes#pedersen_hash). Důkazy s nulovou znalostí běžně používají tuto hashovací funkci. V [aritmetických obvodech](https://rareskills.io/post/arithmetic-circuit) se vypočítává mnohem snadněji než standardní hashovací funkce.
+
+```
+use keccak256::keccak256;
+use dep::ecrecover;
+```
+
+Tyto dvě funkce jsou externí knihovny definované v souboru [`Nargo.toml`](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Nargo.toml). Jsou přesně tím, po čem jsou pojmenovány: funkcí, která vypočítá [hash keccak256](https://emn178.github.io/online-tools/keccak_256.html), a funkcí, která ověřuje podpisy Ethereum a obnovuje adresu Ethereum podepisujícího.
+
+```
+global ACCOUNT_NUMBER : u32 = 5;
+```
+
+Noir je inspirován jazykem [Rust](https://www.rust-lang.org/). Proměnné jsou ve výchozím nastavení konstanty. Takto definujeme globální konfigurační konstanty. Konkrétně `ACCOUNT_NUMBER` je počet účtů, které ukládáme.
+
+Datové typy s názvem `u<číslo>` mají daný počet bitů a jsou bez znaménka. Jediné podporované typy jsou `u8`, `u16`, `u32`, `u64` a `u128`.
+
+```
+global FLAT_ACCOUNT_FIELDS : u32 = 2;
+```
+
+Tato proměnná se používá pro Pedersen hash účtů, jak je vysvětleno níže.
+
+```
+global MESSAGE_LENGTH : u32 = 100;
+```
+
+Jak bylo vysvětleno výše, délka zprávy je pevná. Je zde specifikována.
+
+```
+global ASCII_MESSAGE_LENGTH : [u8; 3] = [0x31, 0x30, 0x30];
+global HASH_BUFFER_SIZE : u32 = 26+3+MESSAGE_LENGTH;
+```
+
+[Podpisy EIP-191](https://eips.ethereum.org/EIPS/eip-191) vyžadují vyrovnávací paměť s 26bajtovou předponou, za níž následuje délka zprávy v ASCII a nakonec samotná zpráva.
+
+```
+struct Account {
+ zůstatek: u128,
+ adresa: Field,
+ nonce: u32,
+}
+```
+
+Informace, které ukládáme o účtu. [`Field`](https://noir-lang.org/docs/noir/concepts/data_types/fields) je číslo, typicky až 253 bitů, které lze použít přímo v [aritmetickém obvodu](https://rareskills.io/post/arithmetic-circuit), který implementuje důkaz s nulovou znalostí. Zde používáme `Field` k uložení 160bitové adresy Ethereum.
+
+```
+struct TransferTxn {
+ z: Field,
+ do: Field,
+ částka: u128,
+ nonce: u32
+}
+```
+
+Informace, které ukládáme pro převodní transakci.
+
+```
+fn flatten_account(account: Account) -> [Field; FLAT_ACCOUNT_FIELDS] {
+```
+
+Definice funkce. Parametrem jsou informace o `účtu`. Výsledkem je pole proměnných `Field`, jejichž délka je `FLAT_ACCOUNT_FIELDS`.
+
+```
+ let flat = [
+ account.address,
+ ((account.balance << 32) + account.nonce.into()).into(),
+ ];
+```
+
+První hodnota v poli je adresa účtu. Druhá zahrnuje jak zůstatek, tak nonce. Volání `.into()` změní číslo na datový typ, kterým má být. `account.nonce` je hodnota `u32`, ale aby ji bylo možné přičíst k hodnotě `account.balance << 32`, která je `u128`, musí být `u128`. To je první `.into()`. Druhý převádí výsledek `u128` na `Field`, aby se vešel do pole.
+
+```
+ flat
+}
+```
+
+V jazyce Noir mohou funkce vracet hodnotu pouze na konci (neexistuje předčasné vrácení). Chcete-li zadat návratovou hodnotu, vyhodnotíte ji těsně před uzavírací závorkou funkce.
+
+```
+fn flatten_accounts(accounts: [Account; ACCOUNT_NUMBER]) -> [Field; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER] {
+```
+
+Tato funkce převede pole účtů na pole `Field`, které lze použít jako vstup do Petersen Hash.
+
+```
+ let mut flat: [Field; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER] = [0; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER];
+```
+
+Takto se určuje měnitelná proměnná, tj. _ne_ konstanta. Proměnné v Noir musí mít vždy hodnotu, proto tuto proměnnou inicializujeme na samé nuly.
+
+```
+ for i in 0..ACCOUNT_NUMBER {
+```
+
+Toto je smyčka `for`. Všimněte si, že hranice jsou konstanty. Smyčky Noir musí mít své hranice známé v době kompilace. Důvodem je, že aritmetické obvody nepodporují řízení toku. Při zpracování smyčky `for` kompilátor jednoduše vloží kód dovnitř několikrát, jednou pro každou iteraci.
+
+```
+ let fields = flatten_account(accounts[i]);
+ for j in 0..FLAT_ACCOUNT_FIELDS {
+ flat[i*FLAT_ACCOUNT_FIELDS + j] = fields[j];
+ }
+ }
+
+ flat
+}
+
+fn hash_accounts(accounts: [Account; ACCOUNT_NUMBER]) -> Field {
+ pedersen_hash(flatten_accounts(accounts))
+}
+```
+
+Nakonec jsme se dostali k funkci, která hashuje pole účtů.
+
+```
+fn find_account(accounts: [Account; ACCOUNT_NUMBER], address: Field) -> u32 {
+ let mut account : u32 = ACCOUNT_NUMBER;
+
+ for i in 0..ACCOUNT_NUMBER {
+ if accounts[i].address == address {
+ account = i;
+ }
+ }
+```
+
+Tato funkce najde účet se specifickou adresou. Tato funkce by byla ve standardním kódu strašně neefektivní, protože iteruje přes všechny účty, i když už našla adresu.
+
+V důkazech s nulovou znalostí však neexistuje žádné řízení toku. Pokud někdy potřebujeme zkontrolovat podmínku, musíme ji zkontrolovat pokaždé.
+
+Podobná věc se děje s příkazy `if`. Příkaz `if` ve smyčce výše je přeložen do těchto matematických příkazů.
+
+_výsledekpodmínky = účty[i].adresa == adresa_ // jedna, pokud se rovnají, jinak nula
+
+_účetnový = výsledekpodmínky\*i + (1-výsledekpodmínky)\*účetstarý_
+
+```rust
+ assert (account < ACCOUNT_NUMBER, f"{address} nemá účet");
+
+ account
+}
+```
+
+Funkce [`assert`](https://noir-lang.org/docs/dev/noir/concepts/assert) způsobí pád důkazu s nulovou znalostí, pokud je tvrzení nepravdivé. V tomto případě, pokud nemůžeme najít účet s příslušnou adresou. K nahlášení adresy použijeme [formátovací řetězec](https://noir-lang.org/docs/noir/concepts/data_types/strings#format-strings).
+
+```rust
+fn apply_transfer_txn(accounts: [Account; ACCOUNT_NUMBER], txn: TransferTxn) -> [Account; ACCOUNT_NUMBER] {
+```
+
+Tato funkce aplikuje převodní transakci a vrací nové pole účtů.
+
+```rust
+ let from = find_account(accounts, txn.from);
+ let to = find_account(accounts, txn.to);
+
+ let (txnFrom, txnAmount, txnNonce, accountNonce) =
+ (txn.from, txn.amount, txn.nonce, accounts[from].nonce);
+```
+
+V Noir nemůžeme přistupovat k prvkům struktury uvnitř formátovacího řetězce, proto si vytvoříme použitelnou kopii.
+
+```rust
+ assert (accounts[from].balance >= txn.amount,
+ f"{txnFrom} nemá {txnAmount} finney");
+
+ assert (accounts[from].nonce == txn.nonce,
+ f"Transakce má nonce {txnNonce}, ale očekává se, že účet použije {accountNonce}");
+```
+
+Toto jsou dvě podmínky, které by mohly způsobit neplatnost transakce.
+
+```rust
+ let mut newAccounts = accounts;
+
+ newAccounts[from].balance -= txn.amount;
+ newAccounts[from].nonce += 1;
+ newAccounts[to].balance += txn.amount;
+
+ newAccounts
+}
+```
+
+Vytvořte nové pole účtů a poté ho vraťte.
+
+```rust
+fn readAddress(messageBytes: [u8; MESSAGE_LENGTH]) -> Field
+```
+
+Tato funkce čte adresu ze zprávy.
+
+```rust
+{
+ let mut result : Field = 0;
+
+ for i in 7..47 {
+```
+
+Adresa má vždy 20 bajtů (tj. 40 hexadecimálních číslic) a začíná na znaku #7.
+
+```rust
+ result *= 0x10;
+ if messageBytes[i] >= 48 & messageBytes[i] <= 57 { // 0-9
+ result += (messageBytes[i]-48).into();
+ }
+ if messageBytes[i] >= 65 & messageBytes[i] <= 70 { // A-F
+ result += (messageBytes[i]-65+10).into()
+ }
+ if messageBytes[i] >= 97 & messageBytes[i] <= 102 { // a-f
+ result += (messageBytes[i]-97+10).into()
+ }
+ }
+
+ result
+}
+
+fn readAmountAndNonce(messageBytes: [u8; MESSAGE_LENGTH]) -> (u128, u32)
+```
+
+Přečtěte částku a nonce ze zprávy.
+
+```rust
+{
+ let mut amount : u128 = 0;
+ let mut nonce: u32 = 0;
+ let mut stillReadingAmount: bool = true;
+ let mut lookingForNonce: bool = false;
+ let mut stillReadingNonce: bool = false;
+```
+
+Ve zprávě je první číslo za adresou částka finney (tj. tisícina ETH) k převodu. Druhé číslo je nonce. Jakýkoli text mezi nimi je ignorován.
+
+```rust
+ for i in 48..MESSAGE_LENGTH {
+ if messageBytes[i] >= 48 & messageBytes[i] <= 57 { // 0-9
+ let digit = (messageBytes[i]-48);
+
+ if stillReadingAmount {
+ amount = amount*10 + digit.into();
+ }
+
+ if lookingForNonce { // Právě jsme to našli
+ stillReadingNonce = true;
+ lookingForNonce = false;
+ }
+
+ if stillReadingNonce {
+ nonce = nonce*10 + digit.into();
+ }
+ } else {
+ if stillReadingAmount {
+ stillReadingAmount = false;
+ lookingForNonce = true;
+ }
+ if stillReadingNonce {
+ stillReadingNonce = false;
+ }
+ }
+ }
+
+ (amount, nonce)
+}
+```
+
+Vrácení [n-tice](https://noir-lang.org/docs/noir/concepts/data_types/tuples) je v Noir způsob, jak vrátit více hodnot z funkce.
+
+```rust
+fn readTransferTxn(message: str) -> TransferTxn
+{
+ let mut txn: TransferTxn = TransferTxn { from: 0, to: 0, amount:0, nonce:0 };
+ let messageBytes = message.as_bytes();
+
+ txn.to = readAddress(messageBytes);
+ let (amount, nonce) = readAmountAndNonce(messageBytes);
+ txn.amount = amount;
+ txn.nonce = nonce;
+
+ txn
+}
+```
+
+Tato funkce převede zprávu na bajty a poté převede částky na `TransferTxn`.
+
+```rust
+// Ekvivalent hashMessage od Viem
+// https://viem.sh/docs/utilities/hashMessage#hashmessage
+fn hashMessage(message: str) -> [u8;32] {
+```
+
+Pedersen Hash jsme mohli použít pro účty, protože se hashují pouze v rámci důkazu s nulovou znalostí. V tomto kódu však musíme zkontrolovat podpis zprávy, který je generován prohlížečem. K tomu je třeba dodržet formát podepisování Ethereum v [EIP 191](https://eips.ethereum.org/EIPS/eip-191). To znamená, že musíme vytvořit kombinovanou vyrovnávací paměť se standardní předponou, délkou zprávy v ASCII a samotnou zprávou a k jejímu hashování použít standardní keccak256 z Etherea.
+
+```rust
+ // Předpona ASCII
+ let prefix_bytes = [
+ 0x19, // \x19
+ 0x45, // 'E'
+ 0x74, // 't'
+ 0x68, // 'h'
+ 0x65, // 'e'
+ 0x72, // 'r'
+ 0x65, // 'e'
+ 0x75, // 'u'
+ 0x6D, // 'm'
+ 0x20, // ' '
+ 0x53, // 'S'
+ 0x69, // 'i'
+ 0x67, // 'g'
+ 0x6E, // 'n'
+ 0x65, // 'e'
+ 0x64, // 'd'
+ 0x20, // ' '
+ 0x4D, // 'M'
+ 0x65, // 'e'
+ 0x73, // 's'
+ 0x73, // 's'
+ 0x61, // 'a'
+ 0x67, // 'g'
+ 0x65, // 'e'
+ 0x3A, // ':'
+ 0x0A // '\n'
+ ];
+```
+
+Aby se předešlo případům, kdy aplikace požádá uživatele o podepsání zprávy, kterou lze použít jako transakci nebo pro jiný účel, EIP 191 stanoví, že všechny podepsané zprávy začínají znakem 0x19 (není to platný znak ASCII), za nímž následuje `Ethereum Signed Message:` a nový řádek.
+
+```rust
+ let mut buffer: [u8; HASH_BUFFER_SIZE] = [0u8; HASH_BUFFER_SIZE];
+ for i in 0..26 {
+ buffer[i] = prefix_bytes[i];
+ }
+
+ let messageBytes : [u8; MESSAGE_LENGTH] = message.as_bytes();
+
+ if MESSAGE_LENGTH <= 9 {
+ for i in 0..1 {
+ buffer[i+26] = ASCII_MESSAGE_LENGTH[i];
+ }
+
+ for i in 0..MESSAGE_LENGTH {
+ buffer[i+26+1] = messageBytes[i];
+ }
+ }
+
+ if MESSAGE_LENGTH >= 10 & MESSAGE_LENGTH <= 99 {
+ for i in 0..2 {
+ buffer[i+26] = ASCII_MESSAGE_LENGTH[i];
+ }
+
+ for i in 0..MESSAGE_LENGTH {
+ buffer[i+26+2] = messageBytes[i];
+ }
+ }
+
+ if MESSAGE_LENGTH >= 100 {
+ for i in 0..3 {
+ buffer[i+26] = ASCII_MESSAGE_LENGTH[i];
+ }
+
+ for i in 0..MESSAGE_LENGTH {
+ buffer[i+26+3] = messageBytes[i];
+ }
+ }
+
+ assert(MESSAGE_LENGTH < 1000, "Zprávy s délkou přes tři číslice nejsou podporovány");
+```
+
+Zpracujte délky zpráv až do 999 a selžete, pokud je větší. Tento kód jsem přidal, i když délka zprávy je konstanta, protože to usnadňuje její změnu. V produkčním systému byste pravděpodobně předpokládali, že se `MESSAGE_LENGTH` nemění kvůli lepšímu výkonu.
+
+```rust
+ keccak256::keccak256(buffer, HASH_BUFFER_SIZE)
+}
+```
+
+Použijte standardní funkci Ethereum `keccak256`.
+
+```rust
+fn signatureToAddressAndHash(
+ message: str,
+ pubKeyX: [u8; 32],
+ pubKeyY: [u8; 32],
+ signature: [u8; 64]
+ ) -> (Field, Field, Field) // adresa, prvních 16 bajtů hashe, posledních 16 bajtů hashe
+{
+```
+
+Tato funkce ověřuje podpis, což vyžaduje hash zprávy. Poté nám poskytne adresu, která jej podepsala, a hash zprávy. Hash zprávy je dodáván ve dvou hodnotách `Field`, protože se s nimi ve zbytku programu snadněji pracuje než s bajtovým polem.
+
+Musíme použít dvě hodnoty `Field`, protože výpočty pole se provádějí [modulo](https://en.wikipedia.org/wiki/Modulo) velkého čísla, ale toto číslo je obvykle menší než 256 bitů (jinak by bylo obtížné provádět tyto výpočty v EVM).
+
+```rust
+ let hash = hashMessage(message);
+
+ let mut (hash1, hash2) = (0,0);
+
+ for i in 0..16 {
+ hash1 = hash1*256 + hash[31-i].into();
+ hash2 = hash2*256 + hash[15-i].into();
+ }
+```
+
+Určete `hash1` a `hash2` jako měnitelné proměnné a zapište do nich hash bajt po bajtu.
+
+```rust
+ (
+ ecrecover::ecrecover(pubKeyX, pubKeyY, signature, hash),
+```
+
+Je to podobné jako u [`ecrecover` v Solidity](https://docs.soliditylang.org/en/v0.8.30/cheatsheet.html#mathematical-and-cryptographic-functions), se dvěma důležitými rozdíly:
+
+- Pokud podpis není platný, volání selže s `assert` a program se přeruší.
+- Zatímco veřejný klíč lze obnovit z podpisu a hashe, jedná se o zpracování, které lze provést externě, a proto se nevyplatí ho provádět v rámci důkazu s nulovou znalostí. Pokud se nás zde někdo pokusí podvést, ověření podpisu se nezdaří.
+
+```rust
+ hash1,
+ hash2
+ )
+}
+
+fn main(
+ accounts: [Account; ACCOUNT_NUMBER],
+ message: str,
+ pubKeyX: [u8; 32],
+ pubKeyY: [u8; 32],
+ signature: [u8; 64],
+ ) -> pub (
+ Field, // Hash pole starých účtů
+ Field, // Hash pole nových účtů
+ Field, // Prvních 16 bajtů hashe zprávy
+ Field, // Posledních 16 bajtů hashe zprávy
+ )
+```
+
+Nakonec se dostáváme k funkci `main`. Musíme dokázat, že máme transakci, která platně mění hash účtů ze staré hodnoty na novou. Také musíme dokázat, že má tento specifický hash transakce, aby osoba, která ji odeslala, věděla, že její transakce byla zpracována.
+
+```rust
+{
+ let mut txn = readTransferTxn(message);
+```
+
+Potřebujeme, aby `txn` byla měnitelná, protože adresu odesílatele nečteme ze zprávy, ale z podpisu.
+
+```rust
+ let (fromAddress, txnHash1, txnHash2) = signatureToAddressAndHash(
+ message,
+ pubKeyX,
+ pubKeyY,
+ signature);
+
+ txn.from = fromAddress;
+
+ let newAccounts = apply_transfer_txn(accounts, txn);
+
+ (
+ hash_accounts(accounts),
+ hash_accounts(newAccounts),
+ txnHash1,
+ txnHash2
+ )
+}
+```
+
+### Fáze 2 – Přidání serveru {#stage-2}
+
+Ve druhé fázi přidáme server, který přijímá a implementuje převodní transakce z prohlížeče.
+
+Chcete-li to vidět v akci:
+
+1. Zastavte Vite, pokud běží.
+
+2. Stáhněte si větev, která obsahuje server, a ujistěte se, že máte všechny potřebné moduly.
+
+ ```sh
+ git checkout 02-add-server
+ cd client
+ npm install
+ cd ../server
+ npm install
+ ```
+
+ Není třeba kompilovat kód Noir, je to stejný kód, který jste použili pro 1. fázi.
+
+3. Spusťte server.
+
+ ```sh
+ npm run start
+ ```
+
+4. V samostatném okně příkazového řádku spusťte Vite, abyste mohli obsluhovat kód prohlížeče.
+
+ ```sh
+ cd client
+ npm run dev
+ ```
+
+5. Přejděte na klientský kód na adrese [http://localhost:5173](http://localhost:5173)
+
+6. Než budete moci vydat transakci, musíte znát nonce a také částku, kterou můžete odeslat. Chcete-li získat tyto informace, klikněte na **Aktualizovat údaje o účtu** a podepište zprávu.
+
+ Máme zde dilema. Na jedné straně nechceme podepisovat zprávu, kterou lze znovu použít ([opakovací útok](https://en.wikipedia.org/wiki/Replay_attack)), což je důvod, proč chceme mít nonce. Nicméně ještě nemáme nonce. Řešením je zvolit nonce, které lze použít pouze jednou a které již máme na obou stranách, například aktuální čas.
+
+ Problém s tímto řešením je, že čas nemusí být dokonale synchronizován. Takže místo toho podepíšeme hodnotu, která se mění každou minutu. To znamená, že naše okno zranitelnosti vůči opakovacím útokům je maximálně jedna minuta. Vzhledem k tomu, že v produkci bude podepsaný požadavek chráněn protokolem TLS a že druhá strana tunelu – server – již může sdělit zůstatek a nonce (musí je znát, aby mohl fungovat), jedná se o přijatelné riziko.
+
+7. Jakmile prohlížeč získá zpět zůstatek a nonce, zobrazí formulář pro převod. Vyberte cílovou adresu a částku a klikněte na **Převod**. Podepište tento požadavek.
+
+8. Chcete-li zobrazit převod, buď **Aktualizujte údaje o účtu**, nebo se podívejte do okna, kde spouštíte server. Server protokoluje stav při každé změně.
+
+ ```
+ ori@CryptoDocGuy:~/x/250911-zk-bank/server$ npm run start
+
+ > server@1.0.0 start
+ > node --experimental-json-modules index.mjs
+
+ Poslouchá na portu 3000
+ Zpracována transakce odeslání 0x90F79bf6EB2c4f870365E785982E1f101E93b906 36000 finney (milliEth) 0
+ Nový stav:
+ 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 má 64000 (1)
+ 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 má 100000 (0)
+ 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC má 100000 (0)
+ 0x90F79bf6EB2c4f870365E785982E1f101E93b906 má 136000 (0)
+ 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 má 100000 (0)
+ Zpracována transakce odeslání 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 7200 finney (milliEth) 1
+ Nový stav:
+ 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 má 56800 (2)
+ 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 má 107200 (0)
+ 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC má 100000 (0)
+ 0x90F79bf6EB2c4f870365E785982E1f101E93b906 má 136000 (0)
+ 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 má 100000 (0)
+ Zpracována transakce odeslání 0x90F79bf6EB2c4f870365E785982E1f101E93b906 3000 finney (milliEth) 2
+ Nový stav:
+ 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 má 53800 (3)
+ 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 má 107200 (0)
+ 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC má 100000 (0)
+ 0x90F79bf6EB2c4f870365E785982E1f101E93b906 má 139000 (0)
+ 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 má 100000 (0)
+ ```
+
+#### `server/index.mjs` {#server-index-mjs-1}
+
+[Tento soubor](https://github.com/qbzzt/250911-zk-bank/blob/02-add-server/server/index.mjs) obsahuje proces serveru a interaguje s kódem Noir na [`main.nr`](https://github.com/qbzzt/250911-zk-bank/blob/02-add-server/server/noir/src/main.nr). Zde je vysvětlení zajímavých částí.
+
+```js
+import { Noir } from '@noir-lang/noir_js'
+```
+
+Knihovna [noir.js](https://www.npmjs.com/package/@noir-lang/noir_js) propojuje kód JavaScriptu a kód Noir.
+
+```js
+const circuit = JSON.parse(await fs.readFile("./noir/target/zkBank.json"))
+const noir = new Noir(circuit)
+```
+
+Načtěte aritmetický obvod – kompilovaný program Noir, který jsme vytvořili v předchozí fázi – a připravte se na jeho spuštění.
+
+```js
+// Informace o účtu poskytujeme pouze v odpovědi na podepsaný požadavek
+const accountInformation = async signature => {
+ const fromAddress = await recoverAddress({
+ hash: hashMessage("Získat data účtu " + Math.floor((new Date().getTime())/60000)),
+ signature
+ })
+```
+
+Pro poskytnutí informací o účtu potřebujeme pouze podpis. Důvodem je, že již víme, jaká bude zpráva, a tedy i hash zprávy.
+
+```js
+const processMessage = async (message, signature) => {
+```
+
+Zpracujte zprávu a proveďte transakci, kterou kóduje.
+
+```js
+ // Získat veřejný klíč
+ const pubKey = await recoverPublicKey({
+ hash,
+ signature
+ })
+```
+
+Nyní, když spouštíme JavaScript na serveru, můžeme získat veřejný klíč tam, spíše než na klientovi.
+
+```js
+ let noirResult
+ try {
+ noirResult = await noir.execute({
+ message,
+ signature: signature.slice(2,-2).match(/.{2}/g).map(x => `0x${x}`),
+ pubKeyX,
+ pubKeyY,
+ accounts: Accounts
+ })
+```
+
+`noir.execute` spouští program Noir. Parametry jsou ekvivalentní těm, které jsou uvedeny v souboru [`Prover.toml`](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Prover.toml). Všimněte si, že dlouhé hodnoty jsou poskytovány jako pole hexadecimálních řetězců (`["0x60", "0xA7"]`), nikoli jako jediná hexadecimální hodnota (`0x60A7`), jak to dělá Viem.
+
+```js
+ } catch (err) {
+ console.log(`Chyba Noir: ${err}`)
+ throw Error("Neplatná transakce, nebyla zpracována")
+ }
+```
+
+Pokud dojde k chybě, zachyťte ji a poté předejte zjednodušenou verzi klientovi.
+
+```js
+ Accounts[fromAccountNumber].nonce++
+ Accounts[fromAccountNumber].balance -= amount
+ Accounts[toAccountNumber].balance += amount
+```
+
+Proveďte transakci. Už jsme to udělali v kódu Noir, ale je snazší to udělat znovu zde, než extrahovat výsledek odtamtud.
+
+```js
+let Accounts = [
+ {
+ address: "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",
+ balance: 5000,
+ nonce: 0,
+ },
+```
+
+Počáteční struktura `účtů`.
+
+### Fáze 3 – Chytré kontrakty Ethereum {#stage-3}
+
+1. Zastavte procesy serveru a klienta.
+
+2. Stáhněte si větev s chytrými kontrakty a ujistěte se, že máte všechny potřebné moduly.
+
+ ```sh
+ git checkout 03-smart-contracts
+ cd client
+ npm install
+ cd ../server
+ npm install
+ ```
+
+3. Spusťte `anvil` v samostatném okně příkazového řádku.
+
+4. Vygenerujte ověřovací klíč a ověřovač Solidity, poté zkopírujte kód ověřovače do projektu Solidity.
+
+ ```sh
+ cd noir
+ bb write_vk -b ./target/zkBank.json -o ./target --oracle_hash keccak
+ bb write_solidity_verifier -k ./target/vk -o ./target/Verifier.sol
+ cp target/Verifier.sol ../../smart-contracts/src
+ ```
+
+5. Přejděte na chytré kontrakty a nastavte proměnné prostředí pro použití blockchainu `anvil`.
+
+ ```sh
+ cd ../../smart-contracts
+ export ETH_RPC_URL=http://localhost:8545
+ ETH_PRIVATE_KEY=ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80
+ ```
+
+6. Nasaďte `Verifier.sol` a uložte adresu do proměnné prostředí.
+
+ ```sh
+ VERIFIER_ADDRESS=`forge create src/Verifier.sol:HonkVerifier --private-key $ETH_PRIVATE_KEY --optimize --broadcast | awk '/Deployed to:/ {print $3}'`
+ echo $VERIFIER_ADDRESS
+ ```
+
+7. Nasaďte kontrakt `ZkBank`.
+
+ ```sh
+ ZKBANK_ADDRESS=`forge create ZkBank --private-key $ETH_PRIVATE_KEY --broadcast --constructor-args $VERIFIER_ADDRESS 0x199aa62af8c1d562a6ec96e66347bf3240ab2afb5d022c895e6bf6a5e617167b | awk '/Deployed to:/ {print $3}'`
+ echo $ZKBANK_ADDRESS
+ ```
+
+ Hodnota `0x199..67b` je Pederson hash počátečního stavu `Účtů`. Pokud tento počáteční stav v `server/index.mjs` upravíte, můžete spustit transakci a zobrazit počáteční hash hlášený důkazem s nulovou znalostí.
+
+8. Spusťte server.
+
+ ```sh
+ cd ../server
+ npm run start
+ ```
+
+9. Spusťte klienta v jiném okně příkazového řádku.
+
+ ```sh
+ cd client
+ npm run dev
+ ```
+
+10. Spusťte nějaké transakce.
+
+11. Chcete-li ověřit, že se stav změnil na blockchainu, restartujte proces serveru. Podívejte se, že `ZkBank` již nepřijímá transakce, protože původní hodnota hashe v transakcích se liší od hodnoty hashe uložené na blockchainu.
+
+ Toto je typ očekávané chyby.
+
+ ```
+ ori@CryptoDocGuy:~/x/250911-zk-bank/server$ npm run start
+
+ > server@1.0.0 start
+ > node --experimental-json-modules index.mjs
+
+ Poslouchání na portu 3000
+ Chyba ověření: ContractFunctionExecutionError: Funkce kontraktu "processTransaction" se vrátila s následujícím důvodem:
+ Špatný hash starého stavu
+
+ Volání kontraktu:
+ adresa: 0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512
+ funkce: processTransaction(bytes _proof, bytes32[] _publicInputs)
+ argumenty: (0x0000000000000000000000000000000000000000000000042ab5d6d1986846cf00000000000000000000000000000000000000000000000b75c020998797da7800000000000000000000000000000000000000000000000)
+ ```
+
+#### `server/index.mjs` {#server-index-mjs-2}
+
+Změny v tomto souboru se týkají především vytvoření skutečného důkazu a jeho odeslání na blockchain.
+
+```js
+import { exec } from 'child_process'
+import util from 'util'
+
+const execPromise = util.promisify(exec)
+```
+
+Musíme použít [balíček Barretenberg](https://github.com/AztecProtocol/aztec-packages/tree/next/barretenberg) k vytvoření skutečného důkazu k odeslání na blockchain. Tento balíček můžeme použít buď spuštěním rozhraní příkazového řádku (`bb`), nebo použitím [knihovny JavaScript, `bb.js`](https://www.npmjs.com/package/@aztec/bb.js). Knihovna JavaScript je mnohem pomalejší než nativní spouštění kódu, takže zde používáme [`exec`](https://nodejs.org/api/child_process.html#child_processexeccommand-options-callback) pro použití příkazového řádku.
+
+Všimněte si, že pokud se rozhodnete použít `bb.js`, musíte použít verzi, která je kompatibilní s verzí Noir, kterou používáte. V době psaní tohoto článku aktuální verze Noir (1.0.0-beta.11) používá `bb.js` verze 0.87.
+
+```js
+const zkBankAddress = process.env.ZKBANK_ADDRESS || "0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512"
+```
+
+Zde uvedená adresa je ta, kterou získáte, když začnete s čistým `anvilem` a budete postupovat podle výše uvedených pokynů.
+
+```js
+const walletClient = createWalletClient({
+ chain: anvil,
+ transport: http(),
+ account: privateKeyToAccount("0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6")
+})
+```
+
+Tento privátní klíč je jedním z výchozích předem financovaných účtů v `anvil`.
+
+```js
+const generateProof = async (witness, fileID) => {
+```
+
+Vygenerujte důkaz pomocí spustitelného souboru `bb`.
+
+```js
+ const fname = `witness-${fileID}.gz`
+ await fs.writeFile(fname, witness)
+```
+
+Zapište svědka do souboru.
+
+```js
+ await execPromise(`bb prove -b ./noir/target/zkBank.json -w ${fname} -o ${fileID} --oracle_hash keccak --output_format fields`)
+```
+
+Vytvořte důkaz. Tento krok také vytvoří soubor s veřejnými proměnnými, ale ten nepotřebujeme. Tyto proměnné jsme již získali z `noir.execute`.
+
+```js
+ const proof = "0x" + JSON.parse(await fs.readFile(`./${fileID}/proof_fields.json`)).reduce((a,b) => a+b, "").replace(/0x/g, "")
+```
+
+Důkaz je pole JSON hodnot `Field`, z nichž každá je reprezentována jako hexadecimální hodnota. Musíme ho však odeslat v transakci jako jedinou hodnotu `bytes`, kterou Viem reprezentuje velkým hexadecimálním řetězcem. Zde měníme formát zřetězením všech hodnot, odstraněním všech `0x` a následným přidáním jednoho na konec.
+
+```js
+ await execPromise(`rm -r ${fname} ${fileID}`)
+
+ return proof
+}
+```
+
+Vyčistěte a vraťte důkaz.
+
+```js
+const processMessage = async (message, signature) => {
+ .
+ .
+ .
+
+ const publicFields = noirResult.returnValue.map(x=>'0x' + x.slice(2).padStart(64, "0"))
+```
+
+Veřejná pole musí být pole 32bajtových hodnot. Jelikož jsme však potřebovali rozdělit hash transakce mezi dvě hodnoty `Field`, zobrazuje se jako 16bajtová hodnota. Zde přidáváme nuly, aby Viem pochopil, že se jedná o 32 bajtů.
+
+```js
+ const proof = await generateProof(noirResult.witness, `${fromAddress}-${nonce}`)
+```
+
+Každá adresa používá každou nonce pouze jednou, takže můžeme použít kombinaci `fromAddress` a `nonce` jako jedinečný identifikátor pro soubor svědka a výstupní adresář.
+
+```js
+ try {
+ await zkBank.write.processTransaction([
+ proof, publicFields])
+ } catch (err) {
+ console.log(`Chyba ověření: ${err}`)
+ throw Error("Transakci nelze ověřit na blockchainu")
+ }
+ .
+ .
+ .
+}
+```
+
+Odešlete transakci do řetězce.
+
+#### `smart-contracts/src/ZkBank.sol` {#smart-contracts-src-zkbank-sol}
+
+Toto je onchain kód, který přijímá transakci.
+
+```solidity
+// SPDX-License-Identifier: MIT
+
+pragma solidity >=0.8.21;
+
+import {HonkVerifier} from "./Verifier.sol";
+
+contract ZkBank {
+ HonkVerifier immutable myVerifier;
+ bytes32 currentStateHash;
+
+ constructor(address _verifierAddress, bytes32 _initialStateHash) {
+ currentStateHash = _initialStateHash;
+ myVerifier = HonkVerifier(_verifierAddress);
+ }
+```
+
+Kód na blockchainu musí sledovat dvě proměnné: ověřovač (samostatný kontrakt vytvořený `nargem`) a aktuální hash stavu.
+
+```solidity
+ event TransactionProcessed(
+ bytes32 indexed transactionHash,
+ bytes32 oldStateHash,
+ bytes32 newStateHash
+ );
+```
+
+Pokaždé, když se stav změní, vydáme událost `TransactionProcessed`.
+
+```solidity
+ function processTransaction(
+ bytes calldata _proof,
+ bytes32[] calldata _publicFields
+ ) public {
+```
+
+Tato funkce zpracovává transakce. Získá důkaz (jako `bajty`) a veřejné vstupy (jako pole `bytes32`) ve formátu, který ověřovatel vyžaduje (aby se minimalizovalo zpracování na blockchainu a tím i náklady na gas).
+
+```solidity
+ require(_publicInputs[0] == currentStateHash,
+ "Špatný starý hash stavu");
+```
+
+Důkaz s nulovou znalostí musí být o tom, že transakce se mění z našeho současného hashe na nový.
+
+```solidity
+ myVerifier.verify(_proof, _publicFields);
+```
+
+Zavolejte kontrakt ověřovače, abyste ověřili důkaz s nulovou znalostí. Tento krok vrátí transakci, pokud je důkaz s nulovou znalostí nesprávný.
+
+```solidity
+ currentStateHash = _publicFields[1];
+
+ emit TransactionProcessed(
+ _publicFields[2]<<128 | _publicFields[3],
+ _publicFields[0],
+ _publicFields[1]
+ );
+ }
+}
+```
+
+Pokud je vše v pořádku, aktualizujte hash stavu na novou hodnotu a vydejte událost `TransactionProcessed`.
+
+## Zneužití centralizovanou součástí {#abuses}
+
+Informační bezpečnost se skládá ze tří atributů:
+
+- _Důvěrnost_, uživatelé nemohou číst informace, ke kterým nejsou oprávněni.
+- _Integrita_, informace nemohou být měněny jinak než oprávněnými uživateli oprávněným způsobem.
+- _Dostupnost_, oprávnění uživatelé mohou systém používat.
+
+V tomto systému je integrita zajištěna prostřednictvím důkazů s nulovou znalostí. Dostupnost je mnohem obtížnější zaručit a důvěrnost je nemožná, protože banka musí znát zůstatek každého účtu a všechny transakce. Neexistuje způsob, jak zabránit entitě, která má informace, v jejich sdílení.
+
+Možná by bylo možné vytvořit skutečně důvěrnou banku pomocí [neviditelných adres](https://vitalik.eth.limo/general/2023/01/20/stealth.html), ale to je nad rámec tohoto článku.
+
+### Nepravdivé informace {#false-info}
+
+Jedním ze způsobů, jak může server porušit integritu, je poskytnutí nepravdivých informací, když [jsou požadována data](https://github.com/qbzzt/250911-zk-bank/blob/03-smart-contracts/server/index.mjs#L278-L291).
+
+K vyřešení tohoto problému můžeme napsat druhý program Noir, který přijímá účty jako soukromý vstup a adresu, pro kterou jsou informace požadovány, jako veřejný vstup. Výstupem je zůstatek a nonce této adresy a hash účtů.
+
+Tento důkaz samozřejmě nelze ověřit na blockchainu, protože nechceme zveřejňovat nonce a zůstatky na blockchainu. Může však být ověřen klientským kódem spuštěným v prohlížeči.
+
+### Vynucené transakce {#forced-txns}
+
+Obvyklým mechanismem pro zajištění dostupnosti a prevenci cenzury na L2 jsou [vynucené transakce](https://docs.optimism.io/stack/transactions/forced-transaction). Ale vynucené transakce se nekombinují s důkazy s nulovou znalostí. Server je jedinou entitou, která může ověřovat transakce.
+
+Můžeme upravit `smart-contracts/src/ZkBank.sol` tak, aby přijímal vynucené transakce a zabránil serveru měnit stav, dokud nebudou zpracovány. To nás však vystavuje jednoduchému útoku typu denial-of-service. Co když je vynucená transakce neplatná, a proto ji nelze zpracovat?
+
+Řešením je mít důkaz s nulovou znalostí, že vynucená transakce je neplatná. To dává serveru tři možnosti:
+
+- Zpracovat vynucenou transakci a poskytnout důkaz s nulovou znalostí, že byla zpracována, a nový hash stavu.
+- Odmítnout vynucenou transakci a poskytnout kontraktu důkaz s nulovou znalostí, že transakce je neplatná (neznámá adresa, špatné nonce nebo nedostatečný zůstatek).
+- Ignorovat vynucenou transakci. Neexistuje způsob, jak donutit server, aby transakci skutečně zpracoval, ale znamená to, že celý systém je nedostupný.
+
+#### Dluhopisy dostupnosti {#avail-bonds}
+
+V reálné implementaci by pravděpodobně existoval nějaký druh motivace k zisku pro udržení serveru v provozu. Tuto pobídku můžeme posílit tím, že server zveřejní dluhopis dostupnosti, který může kdokoli spálit, pokud vynucená transakce není zpracována v určitém období.
+
+### Špatný kód Noir {#bad-noir-code}
+
+Normálně, aby lidé důvěřovali chytrému kontraktu, nahrajeme zdrojový kód do [prohlížeče bloků](https://eth.blockscout.com/address/0x7D16d2c4e96BCFC8f815E15b771aC847EcbDB48b?tab=contract). V případě důkazů s nulovou znalostí to však nestačí.
+
+`Verifier.sol` obsahuje ověřovací klíč, který je funkcí programu Noir. Tento klíč nám však neříká, jaký byl program Noir. Chcete-li mít skutečně důvěryhodné řešení, musíte nahrát program Noir (a verzi, která ho vytvořila). V opačném případě by důkazy s nulovou znalostí mohly odrážet jiný program, program se zadními vrátky.
+
+Dokud nám prohlížeče bloků neumožní nahrávat a ověřovat programy Noir, měli byste to dělat sami (nejlépe na [IPFS](/developers/tutorials/ipfs-decentralized-ui/)). Poté budou moci zkušení uživatelé stáhnout zdrojový kód, sami ho zkompilovat, vytvořit `Verifier.sol` a ověřit, že je identický s tím na blockchainu.
+
+## Závěr {#conclusion}
+
+Aplikace typu Plasma vyžadují centralizovanou komponentu jako úložiště informací. To otevírá potenciální zranitelnosti, ale na oplátku nám to umožňuje zachovat soukromí způsoby, které na samotném blockchainu nejsou dostupné. S důkazy s nulovou znalostí můžeme zajistit integritu a případně učinit ekonomicky výhodným, aby kdokoli, kdo provozuje centralizovanou komponentu, udržoval dostupnost.
+
+[Více z mé práce najdete zde](https://cryptodocguy.pro/).
+
+## Poděkování {#acknowledgements}
+
+- Josh Crites si přečetl návrh tohoto článku a pomohl mi s ošemetným problémem Noir.
+
+Za zbývající chyby jsem zodpovědný já.
diff --git a/public/content/translations/cs/developers/tutorials/calling-a-smart-contract-from-javascript/index.md b/public/content/translations/cs/developers/tutorials/calling-a-smart-contract-from-javascript/index.md
new file mode 100644
index 00000000000..a7e7aaf9836
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/calling-a-smart-contract-from-javascript/index.md
@@ -0,0 +1,131 @@
+---
+title: Volání chytrého kontraktu z JavaScriptu
+description: Jak volat funkci chytrého kontraktu z JavaScriptu na příkladu tokenu Dai
+author: jdourlens
+tags: [ "transakce", "frontend", "JavaScript", "web3.js" ]
+skill: beginner
+lang: cs
+published: 2020-04-19
+source: EthereumDev
+sourceUrl: https://ethereumdev.io/calling-a-smart-contract-from-javascript/
+address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
+---
+
+V tomto návodu si ukážeme, jak zavolat funkci [chytrého kontraktu](/developers/docs/smart-contracts/) z JavaScriptu. Nejprve si přečteme stav chytrého kontraktu (např. zůstatek držitele ERC20), poté změníme stav blockchainu provedením převodu tokenu. Měli byste již být obeznámeni s [nastavením prostředí JS pro interakci s blockchainem](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/).
+
+V tomto příkladu budeme pracovat s tokenem DAI. Pro účely testování vytvoříme větev blockchainu pomocí ganache-cli a odemkneme adresu, která již má hodně DAI:
+
+```bash
+ganache-cli -f https://mainnet.infura.io/v3/[VÁŠ INFURA KLÍČ] -d -i 66 1 --unlock 0x4d10ae710Bd8D1C31bd7465c8CBC3add6F279E81
+```
+
+Pro interakci s chytrým kontraktem budeme potřebovat jeho adresu a ABI:
+
+```js
+const ERC20TransferABI = [
+ {
+ constant: false,
+ inputs: [
+ {
+ name: "_to",
+ type: "address",
+ },
+ {
+ name: "_value",
+ type: "uint256",
+ },
+ ],
+ name: "transfer",
+ outputs: [
+ {
+ name: "",
+ type: "bool",
+ },
+ ],
+ payable: false,
+ stateMutability: "nonpayable",
+ type: "function",
+ },
+ {
+ constant: true,
+ inputs: [
+ {
+ name: "_owner",
+ type: "address",
+ },
+ ],
+ name: "balanceOf",
+ outputs: [
+ {
+ name: "balance",
+ type: "uint256",
+ },
+ ],
+ payable: false,
+ stateMutability: "view",
+ type: "function",
+ },
+]
+
+const DAI_ADDRESS = "0x6b175474e89094c44da98b954eedeac495271d0f"
+```
+
+Pro tento projekt jsme z kompletního ERC20 ABI ponechali pouze funkce `balanceOf` a `transfer`, ale [celé ERC20 ABI naleznete zde](https://ethereumdev.io/abi-for-erc20-contract-on-ethereum/).
+
+Poté musíme náš chytrý kontrakt instanciovat:
+
+```js
+const web3 = new Web3("http://localhost:8545")
+
+const daiToken = new web3.eth.Contract(ERC20TransferABI, DAI_ADDRESS)
+```
+
+Také si nastavíme dvě adresy:
+
+- tu, která obdrží převod, a
+- tu, kterou jsme již odemkli a která ho odešle:
+
+```js
+const senderAddress = "0x4d10ae710Bd8D1C31bd7465c8CBC3add6F279E81"
+const receiverAddress = "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
+```
+
+V další části zavoláme funkci `balanceOf`, abychom zjistili aktuální množství tokenů, které obě adresy drží.
+
+## Volání: Čtení hodnoty z chytrého kontraktu {#call-reading-value-from-a-smart-contract}
+
+První příklad zavolá „konstantní“ metodu a spustí metodu chytrého kontraktu v EVM bez odeslání jakékoli transakce. Za tímto účelem si přečteme zůstatek ERC20 na adrese. [Přečtěte si náš článek o ERC20 tokenech](/developers/tutorials/understand-the-erc-20-token-smart-contract/).
+
+K metodám instanciovaného chytrého kontraktu, pro který jste poskytli ABI, můžete přistupovat následovně: `yourContract.methods.methodname`. Použitím funkce `call` obdržíte výsledek jejího spuštění.
+
+```js
+daiToken.methods.balanceOf(senderAddress).call(function (err, res) {
+ if (err) {
+ console.log("Došlo k chybě", err)
+ return
+ }
+ console.log("Zůstatek je: ", res)
+})
+```
+
+Pamatujte, že DAI ERC20 má 18 desetinných míst, což znamená, že pro získání správné částky musíte odstranit 18 nul. Hodnoty uint256 se vrací jako řetězce, protože JavaScript nezvládá velká číselné hodnoty. Pokud si nejste jisti, [jak zacházet s velkými čísly v JS, podívejte se na náš návod o bignumber.js](https://ethereumdev.io/how-to-deal-with-big-numbers-in-javascript/).
+
+## Odeslání: Odeslání transakce do funkce chytrého kontraktu {#send-sending-a-transaction-to-a-smart-contract-function}
+
+Ve druhém příkladu zavoláme funkci `transfer` chytrého kontraktu DAI, abychom odeslali 10 DAI na naši druhou adresu. Funkce `transfer` přijímá dva parametry: adresu příjemce a množství tokenů k převodu:
+
+```js
+daiToken.methods
+ .transfer(receiverAddress, "100000000000000000000")
+ .send({ from: senderAddress }, function (err, res) {
+ if (err) {
+ console.log("Došlo k chybě", err)
+ return
+ }
+ console.log("Haš transakce: " + res)
+ })
+```
+
+Volání funkce vrátí haš transakce, která bude vytěžena v blockchainu. Na Ethereu jsou haše transakcí předvídatelné - tak můžeme získat haš transakce ještě před jejím spuštěním ([zde se dozvíte, jak se haše počítají](https://ethereum.stackexchange.com/questions/45648/how-to-calculate-the-assigned-txhash-of-a-transaction)).
+
+Protože funkce pouze odešle transakci do blockchainu, neuvidíme výsledek, dokud nebudeme vědět, kdy bude vytěžena a zahrnuta do blockchainu. V příštím návodu se dozvíme, [jak počkat na provedení transakce na blockchainu, když známe její haš](https://ethereumdev.io/waiting-for-a-transaction-to-be-mined-on-ethereum-with-js/).
diff --git a/public/content/translations/cs/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md b/public/content/translations/cs/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md
new file mode 100644
index 00000000000..8e46ed4d264
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md
@@ -0,0 +1,585 @@
+---
+title: "Vytvoření uživatelského rozhraní pro váš kontrakt"
+description: Pomocí moderních komponent, jako jsou TypeScript, React, Vite a Wagmi, si projdeme moderní, ale minimální, uživatelské rozhraní a naučíme se, jak k němu připojit peněženku, jak volat chytrý kontrakt pro čtení informací, jak poslat transakci na chytrý kontrakt a jak sledovat události z chytrého kontraktu a identifikovat změny.
+author: Ori Pomerantz
+tags: [ "typescript", "react", "vite", "wagmi", "frontend" ]
+skill: beginner
+published: 2023-11-01
+lang: cs
+sidebarDepth: 3
+---
+
+Našli jste funkci, kterou v ekosystému Etherea potřebujeme. Napsali jste chytré kontrakty k jeho implementaci a možná i nějaký související kód, který běží offchain. To je skvělé! Bohužel bez uživatelského rozhraní nebudete mít žádné uživatele a naposledy, když jste psali webové stránky, lidé používali dial-up modemy a JavaScript byl novinkou.
+
+Tento článek je pro vás. Předpokládám, že umíte programovat a možná trochu JavaScript a HTML, ale vaše dovednosti v oblasti uživatelského rozhraní jsou zrezivělé a zastaralé. Společně si projdeme jednoduchou moderní aplikaci, abyste viděli, jak se to dnes dělá.
+
+## Proč je to důležité {#why-important}
+
+Teoreticky byste mohli nechat lidi používat [Etherscan](https://holesky.etherscan.io/address/0x432d810484add7454ddb3b5311f0ac2e95cecea8#writeContract) nebo [Blockscout](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=write_contract) k interakci s vašimi kontrakty. To bude skvělé pro zkušené příznivce Etherea. My se ale snažíme sloužit [další miliardě lidí](https://blog.ethereum.org/2021/05/07/ethereum-for-the-next-billion). To se nestane bez skvělého uživatelského zážitku a přátelské uživatelské rozhraní je jeho velkou součástí.
+
+## Aplikace Greeter {#greeter-app}
+
+Za moderním uživatelským rozhraním je spousta teorie a [mnoho dobrých stránek](https://react.dev/learn/thinking-in-react), [které to vysvětlují](https://wagmi.sh/core/getting-started). Místo opakování skvělé práce, kterou odvedly tyto stránky, budu předpokládat, že se raději učíte praxí a začnete s aplikací, se kterou si můžete hrát. Stále potřebujete teorii, abyste mohli věci dotáhnout do konce, a k tomu se dostaneme - projdeme si zdrojový soubor po zdrojovém souboru a probereme věci, jakmile na ně narazíme.
+
+### Instalace {#installation}
+
+1. V případě potřeby si přidejte [blockchain Holesky](https://chainlist.org/?search=holesky&testnets=true) do své peněženky a [získejte testovací ETH](https://www.holeskyfaucet.io/).
+
+2. Klonujte repozitář z githubu.
+
+ ```sh
+ git clone https://github.com/qbzzt/20230801-modern-ui.git
+ ```
+
+3. Nainstalujte potřebné balíčky.
+
+ ```sh
+ cd 20230801-modern-ui
+ pnpm install
+ ```
+
+4. Spusťte aplikaci.
+
+ ```sh
+ pnpm dev
+ ```
+
+5. Přejděte na adresu URL zobrazenou aplikací. Ve většině případů je to [http://localhost:5173/](http://localhost:5173/).
+
+6. Zdrojový kód kontraktu, mírně upravenou verzi Greeter od Hardhat, si můžete prohlédnout [v průzkumníku blockchainu](https://eth-holesky.blockscout.com/address/0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8?tab=contract).
+
+### Procházení souborů {#file-walk-through}
+
+#### `index.html` {#index-html}
+
+Tento soubor je standardní HTML šablona s výjimkou tohoto řádku, který importuje soubor se skriptem.
+
+```html
+
+```
+
+#### `src/main.tsx` {#main-tsx}
+
+Přípona souboru nám říká, že tento soubor je [komponenta React](https://www.w3schools.com/react/react_components.asp) napsaná v [TypeScriptu](https://www.typescriptlang.org/), rozšíření JavaScriptu, které podporuje [kontrolu typů](https://en.wikipedia.org/wiki/Type_system#Type_checking). TypeScript je kompilován do JavaScriptu, takže ho můžeme použít pro spuštění na straně klienta.
+
+```tsx
+import '@rainbow-me/rainbowkit/styles.css'
+import { RainbowKitProvider } from '@rainbow-me/rainbowkit'
+import * as React from 'react'
+import * as ReactDOM from 'react-dom/client'
+import { WagmiConfig } from 'wagmi'
+import { chains, config } from './wagmi'
+```
+
+Importujte kód knihovny, který potřebujeme.
+
+```tsx
+import { App } from './App'
+```
+
+Importujte komponentu React, která implementuje aplikaci (viz níže).
+
+```tsx
+ReactDOM.createRoot(document.getElementById('root')!).render(
+```
+
+Vytvořte kořenovou komponentu React. Parametrem `render` je [JSX](https://www.w3schools.com/react/react_jsx.asp), jazykové rozšíření, které používá jak HTML, tak JavaScript/TypeScript. Vykřičník zde říká komponentě TypeScript: "nevíte, že `document.getElementById('root')` bude platný parametr pro `ReactDOM.createRoot`, ale nebojte se – já jsem vývojář a říkám vám, že bude".
+
+```tsx
+
+```
+
+Aplikace se nachází uvnitř [komponenty `React.StrictMode`](https://react.dev/reference/react/StrictMode). Tato komponenta říká knihovně React, aby vložila další kontrolu ladění, což je užitečné během vývoje.
+
+```tsx
+
+```
+
+Aplikace je také uvnitř [komponenty `WagmiConfig`](https://wagmi.sh/react/api/WagmiProvider). [Knihovna wagmi (we are going to make it)](https://wagmi.sh/) propojuje definice UI v Reactu s [knihovnou viem](https://viem.sh/) pro psaní decentralizovaných aplikací na Ethereu.
+
+```tsx
+
+```
+
+A nakonec [komponenta `RainbowKitProvider`](https://www.rainbowkit.com/). Tato komponenta zpracovává přihlašování a komunikaci mezi peněženkou a aplikací.
+
+```tsx
+
+
+ ,
+)
+```
+
+Samozřejmě musíme uzavřít i ostatní komponenty.
+
+#### `src/App.tsx` {#app-tsx}
+
+```tsx
+import { ConnectButton } from '@rainbow-me/rainbowkit'
+import { useAccount } from 'wagmi'
+import { Greeter } from './components/Greeter'
+
+export function App() {
+```
+
+Toto je standardní způsob, jak vytvořit komponentu React – definovat funkci, která se volá pokaždé, když je třeba ji vykreslit. Tato funkce má obvykle nahoře nějaký kód v TypeScriptu nebo JavaScriptu, za nímž následuje příkaz `return`, který vrací kód JSX.
+
+```tsx
+ const { isConnected } = useAccount()
+```
+
+Zde používáme [`useAccount`](https://wagmi.sh/react/api/hooks/useAccount) ke kontrole, zda jsme připojeni k blockchainu prostřednictvím peněženky.
+
+Podle konvence jsou v Reactu funkce nazvané `use...` [hooky](https://www.w3schools.com/react/react_hooks.asp), které vracejí nějaký druh dat. Když použijete takové hooky, vaše komponenta nejenže získá data, ale když se tato data změní, komponenta se znovu vykreslí s aktualizovanými informacemi.
+
+```tsx
+ return (
+ <>
+```
+
+JSX komponenty React _musí_ vracet jednu komponentu. Když máme více komponent a nemáme nic, co by je "přirozeně" zabalilo, použijeme prázdnou komponentu (`<> ... `), abychom z nich vytvořili jedinou komponentu.
+
+```tsx
+ Greeter
+ = (evt) =>
+ setNewGreeting(evt.target.value)
+```
+
+Toto je obsluha události, která se spustí při změně vstupního pole pro nový pozdrav. Typ [`ChangeEventHandler`](https://react-typescript-cheatsheet.netlify.app/docs/basic/getting-started/forms_and_events/) specifikuje, že se jedná o obsluhu pro změnu hodnoty vstupního prvku HTML. Část `` se používá, protože se jedná o [generický typ](https://www.w3schools.com/typescript/typescript_basic_generics.php).
+
+```tsx
+ const preparedTx = usePrepareContractWrite({
+ address: greeterAddr,
+ abi: greeterABI,
+ functionName: 'setGreeting',
+ args: [ newGreeting ]
+ })
+ const workingTx = useContractWrite(preparedTx.config)
+```
+
+Toto je proces odeslání blockchainové transakce z pohledu klienta:
+
+1. Odešlete transakci uzlu v blockchainu pomocí [`eth_estimateGas`](https://docs.alchemy.com/reference/eth-estimategas).
+2. Počkejte na odpověď z uzlu.
+3. Po obdržení odpovědi požádejte uživatele o podepsání transakce prostřednictvím peněženky. Tento krok se _musí_ provést až po obdržení odpovědi z uzlu, protože uživateli se před podpisem zobrazí náklady na transakci za palivo.
+4. Počkejte na schválení uživatele.
+5. Odešlete transakci znovu, tentokrát pomocí [`eth_sendRawTransaction`](https://docs.alchemy.com/reference/eth-sendrawtransaction).
+
+Krok 2 pravděpodobně zabere znatelné množství času, během kterého by se uživatelé divili, zda byl jejich příkaz skutečně přijat uživatelským rozhraním a proč ještě nejsou požádáni o podepsání transakce. To vede ke špatnému uživatelskému zážitku (UX).
+
+Řešením je použití [přípravných hooků](https://wagmi.sh/react/prepare-hooks). Pokaždé, když se změní parametr, okamžitě odešlete uzlu požadavek `eth_estimateGas`. Poté, když uživatel skutečně chce odeslat transakci (v tomto případě stisknutím **Aktualizovat pozdrav**), náklady na palivo jsou známé a uživatel může okamžitě vidět stránku peněženky.
+
+```tsx
+ return (
+```
+
+Nyní můžeme konečně vytvořit skutečné HTML, které se má vrátit.
+
+```tsx
+ <>
+ Greeter
+ {
+ !readResults.isError && !readResults.isLoading &&
+
+```
+
+Vytvořte komponentu `ShowGreeting` (vysvětleno níže), ale pouze pokud byl pozdrav úspěšně přečten z blockchainu.
+
+```tsx
+
+```
+
+Toto je vstupní textové pole, kde si uživatel může nastavit nový pozdrav. Pokaždé, když uživatel stiskne klávesu, zavoláme `greetingChange`, které zavolá `setNewGreeting`. Protože `setNewGreeting` pochází z hooku `useState`, způsobí to opětovné vykreslení komponenty `Greeter`. To znamená, že:
+
+- Musíme specifikovat `value`, abychom zachovali hodnotu nového pozdravu, protože jinak by se vrátila zpět na výchozí hodnotu, prázdný řetězec.
+- `usePrepareContractWrite` se volá pokaždé, když se `newGreeting` změní, což znamená, že v připravené transakci bude vždy nejnovější `newGreeting`.
+
+```tsx
+
+```
+
+Pokud `workingTx.write` neexistuje, stále čekáme na informace potřebné k odeslání aktualizace pozdravu, takže je tlačítko zakázáno. Pokud hodnota `workingTx.write` existuje, je to funkce, která se má volat k odeslání transakce.
+
+```tsx
+
+ {attrs.name}
+
+ {JSON.stringify(attrs.object, null, 2)}
+```
+
+Většina polí se zobrazuje pomocí [`JSON.stringify`](https://www.w3schools.com/js/js_json_stringify.asp).
+
+```tsx
+
+ { funs.length > 0 &&
+ <>
+ Functions:
+
+```
+
+Výjimkou jsou funkce, které nejsou součástí [standardu JSON](https://www.json.org/json-en.html), takže se musí zobrazovat samostatně.
+
+```tsx
+ {funs.map((f, i) =>
+```
+
+V rámci JSX je kód uvnitř `{` složených závorek `}` interpretován jako JavaScript. Poté je kód uvnitř `(` kulatých závorek `)` interpretován znovu jako JSX.
+
+```tsx
+ (- {f}
)
+ )}
+```
+
+React vyžaduje, aby značky ve [stromu DOM](https://www.w3schools.com/js/js_htmldom.asp) měly jedinečné identifikátory. To znamená, že potomci stejné značky (v tomto případě [neuspořádaný seznam](https://www.w3schools.com/tags/tag_ul.asp)) potřebují různé atributy `key`.
+
+```tsx
+
+
+ }
+
+
+}
+```
+
+Ukončete různé značky HTML.
+
+##### Konečný `export` {#the-final-export}
+
+```tsx
+export { Greeter }
+```
+
+Komponenta `Greeter` je ta, kterou potřebujeme exportovat pro aplikaci.
+
+#### `src/wagmi.ts` {#wagmi-ts}
+
+Nakonec jsou různé definice související s WAGMI v `src/wagmi.ts`. Nebudu zde vše vysvětlovat, protože většina z toho je šablona, kterou pravděpodobně nebudete muset měnit.
+
+Kód zde není úplně stejný jako [na githubu](https://github.com/qbzzt/20230801-modern-ui/blob/main/src/wagmi.ts), protože později v článku přidáme další řetězec ([Redstone Holesky](https://redstone.xyz/docs/network-info)).
+
+```ts
+import { getDefaultWallets } from '@rainbow-me/rainbowkit'
+import { configureChains, createConfig } from 'wagmi'
+import { holesky, sepolia } from 'wagmi/chains'
+```
+
+Importujte blockchainy, které aplikace podporuje. Seznam podporovaných řetězců si můžete prohlédnout [v githubu viem](https://github.com/wagmi-dev/viem/tree/main/src/chains/definitions).
+
+```ts
+import { publicProvider } from 'wagmi/providers/public'
+
+const walletConnectProjectId = 'c96e690bb92b6311e8e9b2a6a22df575'
+```
+
+Abyste mohli používat [WalletConnect](https://walletconnect.com/), potřebujete ID projektu pro vaši aplikaci. Můžete jej získat na [cloud.walletconnect.com](https://cloud.walletconnect.com/sign-in).
+
+```ts
+const { chains, publicClient, webSocketPublicClient } = configureChains(
+ [ holesky, sepolia ],
+ [
+ publicProvider(),
+ ],
+)
+
+const { connectors } = getDefaultWallets({
+ appName: 'My wagmi + RainbowKit App',
+ chains,
+ projectId: walletConnectProjectId,
+})
+
+export const config = createConfig({
+ autoConnect: true,
+ connectors,
+ publicClient,
+ webSocketPublicClient,
+})
+
+export { chains }
+```
+
+### Přidání dalšího blockchainu {#add-blockchain}
+
+V dnešní době existuje mnoho [řešení pro škálování L2](/layer-2/) a možná budete chtít podporovat některá, která viem ještě nepodporuje. K tomu upravte `src/wagmi.ts`. Tyto pokyny vysvětlují, jak přidat [Redstone Holesky](https://redstone.xyz/docs/network-info).
+
+1. Importujte typ `defineChain` z viem.
+
+ ```ts
+ import { defineChain } from 'viem'
+ ```
+
+2. Přidejte definici sítě.
+
+ ```ts
+ const redstoneHolesky = defineChain({
+ id: 17_001,
+ name: 'Redstone Holesky',
+ network: 'redstone-holesky',
+ nativeCurrency: {
+ decimals: 18,
+ name: 'Ether',
+ symbol: 'ETH',
+ },
+ rpcUrls: {
+ default: {
+ http: ['https://rpc.holesky.redstone.xyz'],
+ webSocket: ['wss://rpc.holesky.redstone.xyz/ws'],
+ },
+ public: {
+ http: ['https://rpc.holesky.redstone.xyz'],
+ webSocket: ['wss://rpc.holesky.redstone.xyz/ws'],
+ },
+ },
+ blockExplorers: {
+ default: { name: 'Explorer', url: 'https://explorer.holesky.redstone.xyz' },
+ },
+ })
+ ```
+
+3. Přidejte nový řetězec do volání `configureChains`.
+
+ ```ts
+ const { chains, publicClient, webSocketPublicClient } = configureChains(
+ [ holesky, sepolia, redstoneHolesky ],
+ [ publicProvider(), ],
+ )
+ ```
+
+4. Zajistěte, aby aplikace znala adresu vašich kontraktů na nové síti. V tomto případě upravíme `src/components/Greeter.tsx`:
+
+ ```ts
+ const contractAddrs : AddressPerBlockchainType = {
+ // Holesky
+ 17000: '0x432d810484AdD7454ddb3b5311f0Ac2E95CeceA8',
+
+ // Redstone Holesky
+ 17001: '0x4919517f82a1B89a32392E1BF72ec827ba9986D3',
+
+ // Sepolia
+ 11155111: '0x7143d5c190F048C8d19fe325b748b081903E3BF0'
+ }
+ ```
+
+## Závěr {#conclusion}
+
+Samozřejmě vás nezajímá poskytování uživatelského rozhraní pro `Greeter`. Chcete vytvořit uživatelské rozhraní pro své vlastní kontrakty. Chcete-li vytvořit vlastní aplikaci, proveďte tyto kroky:
+
+1. Určete, že chcete vytvořit aplikaci wagmi.
+
+ ```sh copy
+ pnpm create wagmi
+ ```
+
+2. Pojmenujte aplikaci.
+
+3. Vyberte framework **React**.
+
+4. Vyberte variantu **Vite**.
+
+5. Můžete [přidat Rainbow kit](https://www.rainbowkit.com/docs/installation#manual-setup).
+
+Nyní jděte a zpřístupněte své kontrakty širokému světu.
+
+[Více z mé práce najdete zde](https://cryptodocguy.pro/).
+
diff --git a/public/content/translations/cs/developers/tutorials/deploying-your-first-smart-contract/index.md b/public/content/translations/cs/developers/tutorials/deploying-your-first-smart-contract/index.md
new file mode 100644
index 00000000000..e95f97bba79
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/deploying-your-first-smart-contract/index.md
@@ -0,0 +1,101 @@
+---
+title: Nasazení vašeho prvního chytrého kontraktu
+description: Úvod do nasazení vašeho prvního chytrého kontraktu v testovací síti Etherea
+author: "jdourlens"
+tags:
+ [
+ "smart kontrakt účty",
+ "remix",
+ "solidity",
+ "nasazování"
+ ]
+skill: beginner
+lang: cs
+published: 2020-04-03
+source: EthereumDev
+sourceUrl: https://ethereumdev.io/deploying-your-first-smart-contract/
+address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
+---
+
+Předpokládáme, že se stejně jako my těšíte, až [nasadíte](/developers/docs/smart-contracts/deploying/) a budete interagovat s vaším prvním [chytrým kontraktem](/developers/docs/smart-contracts/) na blockchainu Etherea.
+
+Nemějte obavy, jelikož se jedná o náš první chytrý kontrakt, nasadíme ho na [lokální testovací síti](/developers/docs/networks/), takže vás jeho nasazení nebude nic stát a budete si s ním moci hrát, jak se vám zlíbí.
+
+## Napsání našeho kontraktu {#writing-our-contract}
+
+Prvním krokem je [navštívit Remix](https://remix.ethereum.org/) a vytvořit nový soubor. V levé horní části rozhraní Remix přidejte nový soubor a zadejte požadovaný název souboru.
+
+
+
+Do nového souboru vložíme následující kód.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity >=0.5.17;
+
+contract Counter {
+
+ // Veřejná proměnná typu unsigned int pro uchování počtu
+ uint256 public count = 0;
+
+ // Funkce, která navyšuje náš čítač
+ function increment() public {
+ count += 1;
+ }
+
+ // Nepovinný getter pro získání hodnoty počítadla
+ function getCount() public view returns (uint256) {
+ return count;
+ }
+
+}
+```
+
+Pokud jste zvyklí programovat, snadno uhodnete, co tento program dělá. Zde je vysvětlení řádek po řádku:
+
+- Řádek 4: Definujeme kontrakt s názvem `Counter`.
+- Řádek 7: Náš kontrakt ukládá jedno celé číslo bez znaménka s názvem `count` začínající na 0.
+- Řádek 10: První funkce změní stav kontraktu a navýší (`increment()`) naši proměnnou `count`.
+- Řádek 15: Druhá funkce je pouze getter pro čtení hodnoty proměnné `count` mimo chytrý kontrakt. Všimněte si, že jelikož jsme naši proměnnou `count` definovali jako veřejnou (public), není to nutné, ale je to uvedeno jako příklad.
+
+To je k našemu prvnímu jednoduchému chytrému kontraktu vše. Jak možná víte, vypadá to jako třída z jazyků OOP (objektově orientovaného programování), jako je Java nebo C++. Nyní je čas si s naším kontraktem pohrát.
+
+## Nasazení našeho kontraktu {#deploying-our-contract}
+
+Jelikož jsme napsali náš první chytrý kontrakt, nyní ho nasadíme na blockchain, abychom si s ním mohli hrát.
+
+[Nasazení chytrého kontraktu na blockchain](/developers/docs/smart-contracts/deploying/) je vlastně jen odeslání transakce obsahující kód zkompilovaného chytrého kontraktu bez určení jakýchkoli příjemců.
+
+Nejprve [zkopilujeme kontrakt](/developers/docs/smart-contracts/compiling/) kliknutím na ikonu kompilace na levé straně:
+
+
+
+Poté klikněte na tlačítko kompilace:
+
+
+
+Můžete si vybrat možnost „Automatická kompilace“, takže kontrakt bude vždy zkompilován, když uložíte obsah v textovém editoru.
+
+Poté přejděte na obrazovku "nasazení a spouštění transakcí":
+
+
+
+Jakmile se ocitnete na obrazovce "nasazení a spouštění transakcí", dvakrát zkontrolujte, zda se zobrazuje název vašeho kontraktu, a klikněte na tlačítko Nasadit. Jak vidíte v horní části stránky, aktuální prostředí je „JavaScript VM“, to znamená, že nasadíme náš chytrý kontrakt a budeme s ním interagovat na lokálním testovacím blockchainu, abychom mohli testovat rychleji a bez poplatků.
+
+
+
+Jakmile kliknete na tlačítko „Nasadit“, uvidíte, že se váš kontrakt objeví ve spodní části. Kliknutím na šipku vlevo ho rozbalíte, abychom viděli obsah našeho kontraktu. Zde je naše proměnná `count`, naše funkce `increment()` a getter `getCounter()`.
+
+Pokud kliknete na tlačítko `count` nebo `getCount`, ve skutečnosti se načte obsah proměnné `count` kontraktu a zobrazí se. Jelikož jsme funkci `increment` ještě nevolali, měla by se zobrazit 0.
+
+
+
+Nyní zavoláme funkci `increment` kliknutím na tlačítko. Uvidíte záznamy o provedených transakcích, které se objeví ve spodní části okna. Uvidíte, že záznamy jsou odlišné, když stisknete tlačítko pro načtení dat namísto tlačítka `increment`. Je to proto, že čtení dat na blockchainu nevyžaduje žádné transakce (zápis) ani poplatky. Protože pouze úprava stavu blockchainu vyžaduje provedení transakce:
+
+
+
+Po stisknutí tlačítka inkrementace, které vygeneruje transakci pro volání naší funkce `increment()`, přečteme při opětovném kliknutí na tlačítka `count` nebo `getCount` nově aktualizovaný stav našeho chytrého kontraktu, kde proměnná `count` bude větší než 0.
+
+
+
+V dalším návodu si ukážeme, [jak můžete do svých chytrých kontraktů přidávat události](/developers/tutorials/logging-events-smart-contracts/). Zaznamenávání událostí je pohodlný způsob, jak ladit váš chytrý kontrakt a porozumět tomu, co se děje při volání funkce.
diff --git a/public/content/translations/cs/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md b/public/content/translations/cs/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md
new file mode 100644
index 00000000000..b1fd40a6c88
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md
@@ -0,0 +1,372 @@
+---
+title: Jak vyvíjet a testovat dApp na lokálním, multi-klientském testnetu
+description: Tento průvodce vás nejprve provede vytvořením instance a konfigurací lokálního Ethereum testnetu s více klienty a následně použitím testnetu k nasazení a testování dApp.
+author: "Tedi Mitiku"
+tags:
+ [
+ "klienti",
+ "uzly",
+ "smart kontrakt účty",
+ "složitelnost",
+ "konsensuální vrstva",
+ "exekuční vrstva",
+ "testování"
+ ]
+skill: intermediate
+lang: cs
+published: 2023-04-11
+---
+
+## Úvod {#introduction}
+
+Tato příručka vás provede procesem vytvoření instance konfigurovatelného lokálního Ethereum testnetu, nasazením chytrého kontraktu a použitím testnetu ke spuštění testů vaší dApp. Tato příručka je určena pro vývojáře dApps, kteří chtějí lokálně vyvíjet a testovat své dApps s různými konfiguracemi sítě před nasazením na živý testnet nebo mainnet.
+
+V této příručce:
+
+- Vytvoříte instanci lokálního Ethereum testnetu s [`eth-network-package`](https://github.com/kurtosis-tech/eth-network-package) pomocí [Kurtosis](https://www.kurtosis.com/),
+- Připojíte své vývojové prostředí Hardhat dApp k lokálnímu testnetu pro kompilaci, nasazení a testování dApp a
+- Nakonfigurujete lokální testnet, včetně parametrů, jako je počet uzlů a konkrétní párování EL/CL klientů, abyste umožnili vývoj a testování s různými konfiguracemi sítě.
+
+### Co je Kurtosis? {#what-is-kurtosis}
+
+[Kurtosis](https://www.kurtosis.com/) je skládací systém sestavení určený pro konfiguraci vícekontejnerových testovacích prostředí. Umožňuje vývojářům vytvářet reprodukovatelná prostředí, která vyžadují logiku dynamického nastavení, jako jsou například blockchainové testnety.
+
+V této příručce balíček Kurtosis eth-network-package spouští lokální Ethereum testnet s podporou klienta [`geth`](https://geth.ethereum.org/) exekuční vrstvy (EL) a také klientů [`teku`](https://consensys.io/teku), [`lighthouse`](https://lighthouse.sigmaprime.io/) a [`lodestar`](https://lodestar.chainsafe.io/) konsensuální vrstvy (CL). Tento balíček slouží jako konfigurovatelná a skládací alternativa k sítím v rámcích jako Hardhat Network, Ganache a Anvil. Kurtosis nabízí vývojářům větší kontrolu a flexibilitu nad testnety, které používají, což je hlavní důvod, proč [nadace Ethereum použila Kurtosis k testování Sloučení](https://www.kurtosis.com/blog/testing-the-ethereum-merge) a nadále ho používá k testování upgradů sítě.
+
+## Nastavení Kurtosis {#setting-up-kurtosis}
+
+Než budete pokračovat, ujistěte se, že máte:
+
+- [Nainstalovaný a spuštěný Docker engine](https://docs.kurtosis.com/install/#i-install--start-docker) na vašem lokálním počítači
+- [Nainstalovaný Kurtosis CLI](https://docs.kurtosis.com/install#ii-install-the-cli) (nebo aktualizovaný na nejnovější verzi, pokud již máte CLI nainstalovaný)
+- Nainstalovaný [Node.js](https://nodejs.org/en), [yarn](https://classic.yarnpkg.com/lang/en/docs/install/#mac-stable) a [npx](https://www.npmjs.com/package/npx) (pro vaše prostředí dApp)
+
+## Vytvoření instance lokálního Ethereum testnetu {#instantiate-testnet}
+
+Pro spuštění lokálního Ethereum testnetu spusťte:
+
+```python
+kurtosis --enclave local-eth-testnet run github.com/kurtosis-tech/eth-network-package
+```
+
+Poznámka: Tento příkaz pojmenuje vaši síť: „local-eth-testnet“ pomocí příznaku `--enclave`.
+
+Kurtosis bude průběžně vypisovat kroky, které provádí, zatímco interpretuje, ověřuje a následně provádí pokyny. Na konci byste měli vidět výstup, který se podobá následujícímu:
+
+```python
+INFO[2023-04-04T18:09:44-04:00] ======================================================
+INFO[2023-04-04T18:09:44-04:00] || Created enclave: local-eth-testnet ||
+INFO[2023-04-04T18:09:44-04:00] ======================================================
+Name: local-eth-testnet
+UUID: 39372d756ae8
+Status: RUNNING
+Creation Time: Tue, 04 Apr 2023 18:09:03 EDT
+
+========================================= Files Artifacts =========================================
+UUID Name
+d4085a064230 cl-genesis-data
+1c62cb792e4c el-genesis-data
+bd60489b73a7 genesis-generation-config-cl
+b2e593fe5228 genesis-generation-config-el
+d552a54acf78 geth-prefunded-keys
+5f7e661eb838 prysm-password
+054e7338bb59 validator-keystore-0
+
+========================================== User Services ==========================================
+UUID Name Ports Status
+e20f129ee0c5 cl-client-0-beacon http: 4000/tcp -> RUNNING
+ metrics: 5054/tcp ->
+ tcp-discovery: 9000/tcp -> 127.0.0.1:54263
+ udp-discovery: 9000/udp -> 127.0.0.1:60470
+a8b6c926cdb4 cl-client-0-validator http: 5042/tcp -> 127.0.0.1:54267 RUNNING
+ metrics: 5064/tcp ->
+d7b802f623e8 el-client-0 engine-rpc: 8551/tcp -> 127.0.0.1:54253 RUNNING
+ rpc: 8545/tcp -> 127.0.0.1:54251
+ tcp-discovery: 30303/tcp -> 127.0.0.1:54254
+ udp-discovery: 30303/udp -> 127.0.0.1:53834
+ ws: 8546/tcp -> 127.0.0.1:54252
+514a829c0a84 prelaunch-data-generator-1680646157905431468 STOPPED
+62bd62d0aa7a prelaunch-data-generator-1680646157915424301 STOPPED
+05e9619e0e90 prelaunch-data-generator-1680646157922872635 STOPPED
+
+```
+
+Gratulujeme! Použili jste Kurtosis k vytvoření instance lokálního Ethereum testnetu s klientem CL (`lighthouse`) a EL (`geth`) přes Docker.
+
+### Rekapitulace {#review-instantiate-testnet}
+
+V této části jste spustili příkaz, který nařídil Kurtosisu, aby použil [`eth-network-package` hostovaný vzdáleně na GitHubu](https://github.com/kurtosis-tech/eth-network-package) ke spuštění lokálního Ethereum testnetu v rámci Kurtosis [Enclave](https://docs.kurtosis.com/advanced-concepts/enclaves/). Uvnitř vaší enklávy najdete jak „souborové artefakty“, tak „uživatelské služby“.
+
+[Souborové artefakty](https://docs.kurtosis.com/advanced-concepts/files-artifacts/) ve vaší enklávě obsahují všechna data vygenerovaná a využitá k zavedení klientů EL a CL. Data byla vytvořena pomocí služby `prelaunch-data-generator` sestavené z tohoto [obrazu Dockeru](https://github.com/ethpandaops/ethereum-genesis-generator)
+
+Uživatelské služby zobrazují všechny kontejnerizované služby běžící ve vaší enklávě. Všimnete si, že byl vytvořen jediný uzel, který obsahuje klienta EL i klienta CL.
+
+## Připojení vývojového prostředí dApp k lokálnímu Ethereum testnetu {#connect-your-dapp}
+
+### Nastavení vývojového prostředí dApp {#set-up-dapp-env}
+
+Nyní, když máte spuštěný lokální testnet, můžete k němu připojit své vývojové prostředí dApp. V této příručce bude použit framework Hardhat k nasazení blackjack dApp na váš lokální testnet.
+
+Chcete-li nastavit vývojové prostředí dApp, naklonujte repozitář, který obsahuje naši ukázkovou dApp, a nainstalujte její závislosti spuštěním:
+
+```python
+git clone https://github.com/kurtosis-tech/awesome-kurtosis.git && cd awesome-kurtosis/smart-contract-example && yarn
+```
+
+Složka [smart-contract-example](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example) použitá zde obsahuje typické nastavení pro vývojáře dApp používajícího framework [Hardhat](https://hardhat.org/):
+
+- [`contracts/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/contracts) obsahuje několik jednoduchých chytrých kontraktů pro Blackjack dApp
+- [`scripts/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/scripts) obsahuje skript pro nasazení tokenového kontraktu do vaší lokální sítě Ethereum
+- [`test/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/test) obsahuje jednoduchý .js test pro váš tokenový kontrakt, který potvrdí, že každý hráč v naší Blackjack dApp má pro sebe vyraženo 1000 tokenů
+- [`hardhat.config.ts`](https://github.com/kurtosis-tech/awesome-kurtosis/blob/main/smart-contract-example/hardhat.config.ts) konfiguruje vaše nastavení Hardhat
+
+### Konfigurace Hardhatu pro použití lokálního testnetu {#configure-hardhat}
+
+S nastaveným vývojovým prostředím dApp nyní připojíte Hardhat k lokálnímu Ethereum testnetu vygenerovanému pomocí Kurtosis. Chcete-li toho dosáhnout, nahraďte `<$YOUR_PORT>` ve struktuře `localnet` v konfiguračním souboru `hardhat.config.ts` portem z výstupu RPC URI libovolné služby `el-client-`. V tomto ukázkovém případě by port byl `64248`. Váš port bude jiný.
+
+Příklad v `hardhat.config.ts`:
+
+```js
+localnet: {
+url: 'http://127.0.0.1:<$YOUR_PORT>',// TODO: NAHRAĎTE $YOUR_PORT PORTEM Z URI UZLU, KTERÝ VYTVOŘIL BALÍČEK KURTOSIS ETH-NETWORK-PACKAGE
+
+// Toto jsou soukromé klíče spojené s předem financovanými testovacími účty vytvořenými balíčkem eth-network-package
+//
+accounts: [
+ "ef5177cd0b6b21c87db5a0bf35d4084a8a57a9d6a064f86d51ac85f2b873a4e2",
+ "48fcc39ae27a0e8bf0274021ae6ebd8fe4a0e12623d61464c498900b28feb567",
+ "7988b3a148716ff800414935b305436493e1f25237a2a03e5eebc343735e2f31",
+ "b3c409b6b0b3aa5e65ab2dc1930534608239a478106acf6f3d9178e9f9b00b35",
+ "df9bb6de5d3dc59595bcaa676397d837ff49441d211878c024eabda2cd067c9f",
+ "7da08f856b5956d40a72968f93396f6acff17193f013e8053f6fbb6c08c194d6",
+ ],
+},
+```
+
+Jakmile soubor uložíte, vaše vývojové prostředí Hardhat dApp je nyní připojeno k vašemu lokálnímu Ethereum testnetu! Funkčnost vašeho testnetu můžete ověřit spuštěním:
+
+```python
+npx hardhat balances --network localnet
+```
+
+Výstup by měl vypadat přibližně takto:
+
+```python
+0x878705ba3f8Bc32FCf7F4CAa1A35E72AF65CF766 has balance 10000000000000000000000000
+0x4E9A3d9D1cd2A2b2371b8b3F489aE72259886f1A has balance 10000000000000000000000000
+0xdF8466f277964Bb7a0FFD819403302C34DCD530A has balance 10000000000000000000000000
+0x5c613e39Fc0Ad91AfDA24587e6f52192d75FBA50 has balance 10000000000000000000000000
+0x375ae6107f8cC4cF34842B71C6F746a362Ad8EAc has balance 10000000000000000000000000
+0x1F6298457C5d76270325B724Da5d1953923a6B88 has balance 10000000000000000000000000
+```
+
+To potvrzuje, že Hardhat používá váš lokální testnet a detekuje předfinancované účty vytvořené balíčkem `eth-network-package`.
+
+### Lokální nasazení a testování vaší dApp {#deploy-and-test-dapp}
+
+S vývojovým prostředím dApp plně připojeným k lokálnímu Ethereum testnetu nyní můžete spouštět vývojové a testovací pracovní postupy proti své dApp pomocí lokálního testnetu.
+
+Pro kompilaci a nasazení chytrého kontraktu `ChipToken.sol` pro lokální prototypování a vývoj spusťte:
+
+```python
+npx hardhat compile
+npx hardhat run scripts/deploy.ts --network localnet
+```
+
+Výstup by měl vypadat nějak takto:
+
+```python
+ChipToken deployed to: 0xAb2A01BC351770D09611Ac80f1DE076D56E0487d
+```
+
+Nyní zkuste spustit test `simple.js` proti vaší lokální dApp, abyste potvrdili, že každý hráč v naší Blackjack dApp má pro sebe vyraženo 1000 tokenů:
+
+Výstup by měl vypadat přibližně takto:
+
+```python
+npx hardhat test --network localnet
+```
+
+Výstup by měl vypadat přibližně takto:
+
+```python
+ChipToken
+ mint
+ ✔ should mint 1000 chips for PLAYER ONE
+
+ 1 passing (654ms)
+```
+
+### Rekapitulace {#review-dapp-workflows}
+
+V tomto bodě jste nastavili vývojové prostředí dApp, připojili jste ho k lokální síti Ethereum vytvořené pomocí Kurtosis a zkompilovali, nasadili a spustili jste jednoduchý test proti vaší dApp.
+
+Nyní se podívejme, jak můžete konfigurovat podkladovou síť pro testování našich dApps v různých konfiguracích sítě.
+
+## Konfigurace lokálního Ethereum testnetu {#configure-testnet}
+
+### Změna konfigurací klientů a počtu uzlů {#configure-client-config-and-num-nodes}
+
+Váš lokální Ethereum testnet lze nakonfigurovat tak, aby používal různé páry klientů EL a CL, stejně jako různý počet uzlů, v závislosti na scénáři a specifické konfiguraci sítě, kterou chcete vyvíjet nebo testovat. To znamená, že po nastavení můžete spustit přizpůsobený lokální testnet a použít jej ke spuštění stejných pracovních postupů (nasazení, testy atd.) v různých konfiguracích sítě, abyste se ujistili, že vše funguje podle očekávání. Chcete-li se dozvědět více o dalších parametrech, které můžete upravit, navštivte tento odkaz.
+
+Vyzkoušejte to! Prostřednictvím souboru JSON můžete balíčku `eth-network-package` předat různé možnosti konfigurace. Tento soubor JSON s parametry sítě poskytuje specifické konfigurace, které Kurtosis použije k nastavení lokální sítě Ethereum.
+
+Vezměte výchozí konfigurační soubor a upravte jej tak, aby se spustily dva uzly s různými páry EL/CL:
+
+- Uzel 1 s `geth`/`lighthouse`
+- Uzel 2 s `geth`/`lodestar`
+- Uzel 3 s `geth`/`teku`
+
+Tato konfigurace vytváří heterogenní síť implementací uzlů Ethereum pro testování vaší dApp. Váš konfigurační soubor by nyní měl vypadat takto:
+
+```yaml
+{
+ "participants":
+ [
+ {
+ "el_client_type": "geth",
+ "el_client_image": "",
+ "el_client_log_level": "",
+ "cl_client_type": "lighthouse",
+ "cl_client_image": "",
+ "cl_client_log_level": "",
+ "beacon_extra_params": [],
+ "el_extra_params": [],
+ "validator_extra_params": [],
+ "builder_network_params": null,
+ },
+ {
+ "el_client_type": "geth",
+ "el_client_image": "",
+ "el_client_log_level": "",
+ "cl_client_type": "lodestar",
+ "cl_client_image": "",
+ "cl_client_log_level": "",
+ "beacon_extra_params": [],
+ "el_extra_params": [],
+ "validator_extra_params": [],
+ "builder_network_params": null,
+ },
+ {
+ "el_client_type": "geth",
+ "el_client_image": "",
+ "el_client_log_level": "",
+ "cl_client_type": "teku",
+ "cl_client_image": "",
+ "cl_client_log_level": "",
+ "beacon_extra_params": [],
+ "el_extra_params": [],
+ "validator_extra_params": [],
+ "builder_network_params": null,
+ },
+ ],
+ "network_params":
+ {
+ "preregistered_validator_keys_mnemonic": "giant issue aisle success illegal bike spike question tent bar rely arctic volcano long crawl hungry vocal artwork sniff fantasy very lucky have athlete",
+ "num_validator_keys_per_node": 64,
+ "network_id": "3151908",
+ "deposit_contract_address": "0x4242424242424242424242424242424242424242",
+ "seconds_per_slot": 12,
+ "genesis_delay": 120,
+ "capella_fork_epoch": 5,
+ },
+}
+```
+
+Každá struktura `participants` odpovídá jednomu uzlu v síti, takže 3 struktury `participants` řeknou Kurtosisu, aby spustil 3 uzly ve vaší síti. Každá struktura `participants` vám umožní určit pár EL a CL použitý pro daný konkrétní uzel.
+
+Struktura `network_params` konfiguruje nastavení sítě, která se používají k vytvoření genesis souborů pro každý uzel, a také další nastavení, jako jsou sekundy na slot sítě.
+
+Uložte si upravený soubor parametrů do libovolného adresáře (v níže uvedeném příkladu je uložen na plochu) a poté ho použijte ke spuštění balíčku Kurtosis spuštěním:
+
+```python
+kurtosis clean -a && kurtosis run --enclave local-eth-testnet github.com/kurtosis-tech/eth-network-package "$(cat ~/eth-network-params.json)"
+```
+
+Poznámka: příkaz `kurtosis clean -a` se zde používá k tomu, aby Kurtosis zničil starý testnet a jeho obsah před spuštěním nového.
+
+Kurtosis bude opět chvíli pracovat a vypisovat jednotlivé kroky, které probíhají. Nakonec by výstup měl vypadat nějak takto:
+
+```python
+Starlark code successfully run. No output was returned.
+INFO[2023-04-07T11:43:16-04:00] ==========================================================
+INFO[2023-04-07T11:43:16-04:00] || Created enclave: local-eth-testnet ||
+INFO[2023-04-07T11:43:16-04:00] ==========================================================
+Name: local-eth-testnet
+UUID: bef8c192008e
+Status: RUNNING
+Creation Time: Fri, 07 Apr 2023 11:41:58 EDT
+
+========================================= Files Artifacts =========================================
+UUID Name
+cc495a8e364a cl-genesis-data
+7033fcdb5471 el-genesis-data
+a3aef43fc738 genesis-generation-config-cl
+8e968005fc9d genesis-generation-config-el
+3182cca9d3cd geth-prefunded-keys
+8421166e234f prysm-password
+d9e6e8d44d99 validator-keystore-0
+23f5ba517394 validator-keystore-1
+4d28dea40b5c validator-keystore-2
+
+========================================== User Services ==========================================
+UUID Name Ports Status
+485e6fde55ae cl-client-0-beacon http: 4000/tcp -> http://127.0.0.1:65010 RUNNING
+ metrics: 5054/tcp -> http://127.0.0.1:65011
+ tcp-discovery: 9000/tcp -> 127.0.0.1:65012
+ udp-discovery: 9000/udp -> 127.0.0.1:54455
+73739bd158b2 cl-client-0-validator http: 5042/tcp -> 127.0.0.1:65016 RUNNING
+ metrics: 5064/tcp -> http://127.0.0.1:65017
+1b0a233cd011 cl-client-1-beacon http: 4000/tcp -> 127.0.0.1:65021 RUNNING
+ metrics: 8008/tcp -> 127.0.0.1:65023
+ tcp-discovery: 9000/tcp -> 127.0.0.1:65024
+ udp-discovery: 9000/udp -> 127.0.0.1:56031
+ validator-metrics: 5064/tcp -> 127.0.0.1:65022
+949b8220cd53 cl-client-1-validator http: 4000/tcp -> 127.0.0.1:65028 RUNNING
+ metrics: 8008/tcp -> 127.0.0.1:65030
+ tcp-discovery: 9000/tcp -> 127.0.0.1:65031
+ udp-discovery: 9000/udp -> 127.0.0.1:60784
+ validator-metrics: 5064/tcp -> 127.0.0.1:65029
+c34417bea5fa cl-client-2 http: 4000/tcp -> 127.0.0.1:65037 RUNNING
+ metrics: 8008/tcp -> 127.0.0.1:65035
+ tcp-discovery: 9000/tcp -> 127.0.0.1:65036
+ udp-discovery: 9000/udp -> 127.0.0.1:63581
+e19738e6329d el-client-0 engine-rpc: 8551/tcp -> 127.0.0.1:64986 RUNNING
+ rpc: 8545/tcp -> 127.0.0.1:64988
+ tcp-discovery: 30303/tcp -> 127.0.0.1:64987
+ udp-discovery: 30303/udp -> 127.0.0.1:55706
+ ws: 8546/tcp -> 127.0.0.1:64989
+e904687449d9 el-client-1 engine-rpc: 8551/tcp -> 127.0.0.1:64993 RUNNING
+ rpc: 8545/tcp -> 127.0.0.1:64995
+ tcp-discovery: 30303/tcp -> 127.0.0.1:64994
+ udp-discovery: 30303/udp -> 127.0.0.1:58096
+ ws: 8546/tcp -> 127.0.0.1:64996
+ad6f401126fa el-client-2 engine-rpc: 8551/tcp -> 127.0.0.1:65003 RUNNING
+ rpc: 8545/tcp -> 127.0.0.1:65001
+ tcp-discovery: 30303/tcp -> 127.0.0.1:65000
+ udp-discovery: 30303/udp -> 127.0.0.1:57269
+ ws: 8546/tcp -> 127.0.0.1:65002
+12d04a9dbb69 prelaunch-data-generator-1680882122181135513 STOPPED
+5b45f9c0504b prelaunch-data-generator-1680882122192182847 STOPPED
+3d4aaa75e218 prelaunch-data-generator-1680882122201668972 STOPPED
+```
+
+Gratulujeme! Úspěšně jste nakonfigurovali svůj lokální testnet tak, aby měl 3 uzly místo 1. Chcete-li spustit stejné pracovní postupy jako dříve proti vaší dApp (nasazení a testování), proveďte stejné operace jako dříve tak, že nahradíte `<$YOUR_PORT>` ve struktuře `localnet` v konfiguračním souboru `hardhat.config.ts` portem z výstupu RPC URI libovolné služby `el-client-` ve vašem novém, 3uzlovém lokálním testnetu.
+
+## Závěr {#conclusion}
+
+A to je vše! Abychom shrnuli tuto krátkou příručku:
+
+- Vytvořili jste lokální Ethereum testnet přes Docker pomocí Kurtosis
+- Připojili jste své lokální vývojové prostředí dApp k lokální síti Ethereum
+- Nasadili jste dApp a spustili jste na ní jednoduchý test v lokální síti Ethereum
+- Nakonfigurovali jste podkladovou síť Ethereum tak, aby měla 3 uzly
+
+Rádi bychom od vás slyšeli, co se vám povedlo, co by se dalo vylepšit, nebo abychom zodpověděli jakékoli vaše dotazy. Neváhejte se nám ozvat přes [GitHub](https://github.com/kurtosis-tech/kurtosis/issues/new/choose) nebo nám [napište e-mail](mailto:feedback@kurtosistech.com)!
+
+### Další příklady a průvodci {#other-examples-guides}
+
+Doporučujeme vám podívat se na náš [rychlý start](https://docs.kurtosis.com/quickstart) (kde si na něm postavíte databázi Postgres a API) a naše další příklady v našem [repozitáři awesome-kurtosis](https://github.com/kurtosis-tech/awesome-kurtosis), kde najdete několik skvělých příkladů, včetně balíčků pro:
+
+- Spuštění stejného lokálního Ethereum testnetu, ale s připojenými dalšími službami, jako je spammer transakcí (pro simulaci transakcí), monitor větví a připojená instance Grafana a Prometheus
+- Provedení [testu podsíťování](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/ethereum-network-partition-test) proti stejné lokální síti Ethereum
diff --git a/public/content/translations/cs/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md b/public/content/translations/cs/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md
new file mode 100644
index 00000000000..321ea67157d
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md
@@ -0,0 +1,144 @@
+---
+title: "Zmenšení kontraktů v boji proti limitu velikosti kontraktů"
+description: Co můžete udělat, abyste zabránili přílišnému zvětšení vašich chytrých kontraktů?
+author: Markus Waas
+lang: cs
+tags: [ "solidity", "smart kontrakt účty", "úložiště" ]
+skill: intermediate
+published: 2020-06-26
+source: soliditydeveloper.com
+sourceUrl: https://soliditydeveloper.com/max-contract-size
+---
+
+## Proč existuje limit? {#why-is-there-a-limit}
+
+Dne [22. listopadu 2016](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/) hard fork Spurious Dragon představil [EIP-170](https://eips.ethereum.org/EIPS/eip-170), který přidal limit velikosti chytrého kontraktu 24,576 kb. Pro vás jako pro vývojáře v jazyce Solidity to znamená, že když budete do svého kontraktu přidávat další a další funkce, v určitém okamžiku narazíte na limit a při nasazování se vám zobrazí chyba:
+
+`Warning: Contract code size exceeds 24576 bytes (a limit introduced in Spurious Dragon). This contract may not be deployable on Mainnet. Consider enabling the optimizer (with a low "runs" value!), turning off revert strings, or using libraries.`
+
+Tento limit byl zaveden, aby se zabránilo útokům typu denial-of-service (DoS). Každé volání kontraktu je z hlediska spotřeby paliva relativně levné. Dopad volání kontraktu na uzly Etherea se však neúměrně zvyšuje v závislosti na velikosti kódu volaného kontraktu (čtení kódu z disku, předzpracování kódu, přidávání dat do Merkle proofu). Kdykoli nastane situace, kdy útočník potřebuje málo zdrojů, aby ostatním způsobil spoustu práce, vzniká potenciál pro útoky DoS.
+
+Původně to byl menší problém, protože jedním přirozeným limitem velikosti kontraktu je palivový limit bloku. Kontrakt musí být samozřejmě nasazen v rámci transakce, která obsahuje veškerý bytecode kontraktu. Pokud do bloku zahrnete pouze tuto jednu transakci, můžete spotřebovat všechno palivo, ale není ho nekonečně. Od [vylepšení London](/ethereum-forks/#london) se palivový limit bloku může měnit mezi 15 a 30 miliony jednotek v závislosti na poptávce sítě.
+
+V následujícím textu se podíváme na některé metody seřazené podle jejich potenciálního dopadu. Přemýšlejte o tom jako o hubnutí. Nejlepší strategií, jak dosáhnout cílové hmotnosti (v našem případě 24 kb), je zaměřit se nejprve na metody s velkým dopadem. Ve většině případů vás tam dostane pouhá úprava jídelníčku, ale někdy je potřeba trochu víc. Pak můžete přidat nějaké cvičení (střední dopad) nebo dokonce doplňky stravy (malý dopad).
+
+## Velký dopad {#big-impact}
+
+### Rozdělte své kontrakty {#separate-your-contracts}
+
+To by měl být vždy váš první přístup. Jak můžete kontrakt rozdělit na více menších? Obecně vás to donutí vymyslet pro své kontrakty dobrou architekturu. Z hlediska čitelnosti kódu jsou vždy upřednostňovány menší kontrakty. Při rozdělování kontraktů si položte následující otázky:
+
+- Které funkce patří k sobě? Každá sada funkcí může být nejlepší ve svém vlastním kontraktu.
+- Které funkce nevyžadují čtení stavu kontraktu nebo jen jeho specifické podmnožiny?
+- Můžete rozdělit úložiště a funkcionalitu?
+
+### Knihovny {#libraries}
+
+Jedním z jednoduchých způsobů, jak přesunout kód funkcionality mimo úložiště, je použití [knihovny](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#libraries). Funkce knihovny nedeklarujte jako interní (internal), protože ty budou během kompilace přímo [přidány do kontraktu](https://ethereum.stackexchange.com/questions/12975/are-internal-functions-in-libraries-not-covered-by-linking). Pokud však použijete veřejné (public) funkce, budou se ve skutečnosti nacházet v samostatném kontraktu knihovny. Zvažte použití [using for](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#using-for), aby bylo používání knihoven pohodlnější.
+
+### Proxy {#proxies}
+
+Pokročilejší strategií by byl systém proxy. Knihovny na pozadí používají `DELEGATECALL`, který jednoduše provede funkci jiného kontraktu se stavem volajícího kontraktu. Více informací o proxy systémech se dozvíte v [tomto příspěvku na blogu](https://hackernoon.com/how-to-make-smart-contracts-upgradable-2612e771d5a2). Poskytují vám více funkcí, např. umožňují upgradovatelnost, ale také přidávají velkou složitost. Nepřidával bych je jen kvůli zmenšení velikosti kontraktu, pokud to z jakéhokoli důvodu není vaše jediná možnost.
+
+## Střední dopad {#medium-impact}
+
+### Odstraňte funkce {#remove-functions}
+
+Tohle by mělo být zřejmé. Funkce poměrně značně zvětšují velikost kontraktu.
+
+- **Externí (external)**: Často přidáváme mnoho view funkcí z důvodu pohodlí. To je naprosto v pořádku, dokud nenarazíte na limit velikosti. Pak byste se mohli opravdu zamyslet nad odstraněním všech funkcí kromě těch naprosto nezbytných.
+- **Interní (internal)**: Můžete také odstranit interní/privátní (internal/private) funkce a jednoduše vložit kód přímo, pokud je funkce volána pouze jednou.
+
+### Vyhněte se dalším proměnným {#avoid-additional-variables}
+
+```solidity
+function get(uint id) returns (address,address) {
+ MyStruct memory myStruct = myStructs[id];
+ return (myStruct.addr1, myStruct.addr2);
+}
+```
+
+```solidity
+function get(uint id) returns (address,address) {
+ return (myStructs[id].addr1, myStructs[id].addr2);
+}
+```
+
+Takováto jednoduchá změna představuje rozdíl **0,28 kb**. Je pravděpodobné, že ve svých kontraktech najdete mnoho podobných situací, a ty se mohou opravdu nasčítat do významných hodnot.
+
+### Zkraťte chybové zprávy {#shorten-error-message}
+
+Dlouhé revertovací zprávy a zejména mnoho různých revertovacích zpráv může kontrakt nafouknout. Místo toho používejte krátké chybové kódy a dekódujte je ve svém kontraktu. Dlouhá zpráva by mohla být mnohem kratší:
+
+```solidity
+require(msg.sender == owner, "Tuto funkci může volat pouze vlastník tohoto kontraktu");
+```
+
+```solidity
+require(msg.sender == owner, "OW1");
+```
+
+### Používejte vlastní chyby namísto chybových zpráv
+
+Vlastní chyby byly zavedeny v [Solidity 0.8.4](https://blog.soliditylang.org/2021/04/21/custom-errors/). Jsou skvělým způsobem, jak zmenšit velikost vašich kontraktů, protože jsou kódovány v ABI jako selektory (stejně jako funkce).
+
+```solidity
+error Unauthorized();
+
+if (msg.sender != owner) {
+ revert Unauthorized();
+}
+```
+
+### Zvažte nízkou hodnotu runs v optimalizátoru {#consider-a-low-run-value-in-the-optimizer}
+
+Můžete také změnit nastavení optimalizátoru. Výchozí hodnota 200 znamená, že se snaží optimalizovat bytecode tak, jako by byla funkce volána 200krát. Pokud ji změníte na 1, v podstatě říkáte optimalizátoru, aby optimalizoval pro případ, že každá funkce bude spuštěna pouze jednou. Optimalizovaná funkce pro jednorázové spuštění znamená, že je optimalizována pro samotné nasazení. Mějte na paměti, že **to zvyšuje [náklady na palivo](/developers/docs/gas/) za spuštění funkcí**, takže to možná nebudete chtít udělat.
+
+## Malý dopad {#small-impact}
+
+### Vyhněte se předávání struktur (structs) funkcím {#avoid-passing-structs-to-functions}
+
+Pokud používáte [ABIEncoderV2](https://solidity.readthedocs.io/en/v0.6.10/layout-of-source-files.html#abiencoderv2), může pomoci nepředávat struktury funkci. Namísto předávání parametru jako struktury předejte požadované parametry přímo. V tomto příkladu jsme ušetřili dalších **0,1 kb**.
+
+```solidity
+function get(uint id) returns (address,address) {
+ return _get(myStruct);
+}
+
+function _get(MyStruct memory myStruct) private view returns(address,address) {
+ return (myStruct.addr1, myStruct.addr2);
+}
+```
+
+```solidity
+function get(uint id) returns(address,address) {
+ return _get(myStructs[id].addr1, myStructs[id].addr2);
+}
+
+function _get(address addr1, address addr2) private view returns(address,address) {
+ return (addr1, addr2);
+}
+```
+
+### Deklarujte správnou viditelnost pro funkce a proměnné {#declare-correct-visibility-for-functions-and-variables}
+
+- Funkce nebo proměnné, které jsou volány pouze zvenčí? Deklarujte je jako `external` namísto `public`.
+- Funkce nebo proměnné volané pouze v rámci kontraktu? Deklarujte je jako `private` nebo `internal` namísto `public`.
+
+### Odstraňte modifikátory {#remove-modifiers}
+
+Modifikátory, zejména při intenzivním používání, mohou mít významný dopad na velikost kontraktu. Zvažte jejich odstranění a místo nich použijte funkce.
+
+```solidity
+modifier checkStuff() {}
+
+function doSomething() checkStuff {}
+```
+
+```solidity
+function checkStuff() private {}
+
+function doSomething() { checkStuff(); }
+```
+
+Tyto tipy by vám měly pomoci výrazně zmenšit velikost kontraktu. Ještě jednou zdůrazňuji, že pro co největší dopad se vždy zaměřte na rozdělení kontraktů, pokud je to možné.
diff --git a/public/content/translations/cs/developers/tutorials/eip-1271-smart-contract-signatures/index.md b/public/content/translations/cs/developers/tutorials/eip-1271-smart-contract-signatures/index.md
new file mode 100644
index 00000000000..8d68af20ebb
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/eip-1271-smart-contract-signatures/index.md
@@ -0,0 +1,129 @@
+---
+title: "EIP-1271: Podepisování a ověřování podpisů chytrých kontraktů"
+description: Přehled vytváření a ověřování podpisů chytrých kontraktů pomocí EIP-1271. Projdeme si také implementaci EIP-1271 použitou v Safe (dříve Gnosis Safe), abychom vývojářům chytrých kontraktů poskytli konkrétní příklad, na kterém mohou stavět.
+author: Nathan H. Leung
+lang: cs
+tags:
+ [
+ "eip-1271",
+ "chytré kontrakty",
+ "ověřování",
+ "podepisování"
+ ]
+skill: intermediate
+published: 2023-01-12
+---
+
+Standard [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) umožňuje chytrým kontraktům ověřovat podpisy.
+
+V tomto tutoriálu poskytneme přehled digitálních podpisů, pozadí EIP-1271 a specifické implementace EIP-1271 používané službou [Safe](https://safe.global/) (dříve Gnosis Safe). Celkově to může sloužit jako výchozí bod pro implementaci EIP-1271 ve vašich vlastních kontraktech.
+
+## Co je to podpis?
+
+V tomto kontextu je podpis (přesněji „digitální podpis“) zpráva plus nějaký druh důkazu, že zpráva pochází od konkrétní osoby/odesílatele/adresy.
+
+Digitální podpis může vypadat například takto:
+
+1. Zpráva: „Chci se na tuto webovou stránku přihlásit pomocí své peněženky Ethereum.“
+2. Podepisující: Moje adresa je `0x000…`
+3. Důkaz: Zde je důkaz, že já, `0x000...`, jsem skutečně vytvořil celou tuto zprávu (obvykle se jedná o něco kryptografického).
+
+Je důležité si uvědomit, že digitální podpis zahrnuje jak „zprávu“, tak „podpis“.
+
+Proč? Pokud byste mi například dali k podpisu smlouvu a já bych odtrhl stránku s podpisem a vrátil vám pouze své podpisy bez zbytku smlouvy, smlouva by nebyla platná.
+
+Stejně tak digitální podpis bez přidružené zprávy nic neznamená!
+
+## Proč existuje EIP-1271?
+
+Abyste mohli vytvořit digitální podpis pro použití na blockchainechech založených na Ethereu, obecně potřebujete tajný privátní klíč, který nikdo jiný nezná. Díky tomu je váš podpis skutečně váš (nikdo jiný nemůže vytvořit stejný podpis bez znalosti tajného klíče).
+
+Váš účet na Ethereu (tj. váš externě vlastněný účet / EOA) má s ním spojený privátní klíč, a to je privátní klíč, který se obvykle používá, když vás web nebo dapp požádá o podpis (např. pro „Přihlásit se pomocí Etherea“).
+
+Aplikace může [ověřit podpis](https://www.alchemy.com/docs/how-to-verify-a-message-signature-on-ethereum), který vytvoříte pomocí knihovny třetí strany, jako je ethers.js, [aniž by znala váš privátní klíč](https://en.wikipedia.org/wiki/Public-key_cryptography), a být si jistá, že jste to byli _vy_, kdo podpis vytvořil.
+
+> Ve skutečnosti, protože digitální podpisy EOA používají kryptografii s veřejným klíčem, mohou být generovány a ověřovány **mimo blockchain**! Takto funguje hlasování v DAO bez poplatků – místo odesílání hlasů na blockchainu lze digitální podpisy vytvářet a ověřovat mimo blockchain pomocí kryptografických knihoven.
+
+Zatímco účty EOA mají privátní klíč, účty chytrých kontraktů nemají žádný privátní ani tajný klíč (takže "Přihlásit se pomocí Etherea" atd. nemůže nativně fungovat s účty chytrých kontraktů).
+
+Problém, který se EIP-1271 snaží vyřešit: jak můžeme poznat, že podpis chytrého kontraktu je platný, pokud chytrý kontrakt nemá žádné „tajemství“, které by mohl do podpisu začlenit?
+
+## Jak EIP-1271 funguje?
+
+Chytré kontrakty nemají privátní klíče, které by se daly použít k podepisování zpráv. Jak tedy poznáme, zda je podpis autentický?
+
+Jedním z nápadů je, že se můžeme chytrého kontraktu jednoduše _zeptat_, zda je podpis autentický!
+
+EIP-1271 standardizuje myšlenku „zeptat se“ chytrého kontraktu, zda je daný podpis platný.
+
+Kontrakt, který implementuje EIP-1271, musí mít funkci s názvem `isValidSignature`, která přijímá zprávu a podpis. Kontrakt pak může spustit nějakou ověřovací logiku (specifikace zde nevynucuje nic konkrétního) a poté vrátit hodnotu označující, zda je podpis platný, či nikoli.
+
+Pokud `isValidSignature` vrátí platný výsledek, je to v podstatě jako by kontrakt říkal „ano, schvaluji tento podpis + zprávu!“
+
+### Rozhraní
+
+Zde je přesné rozhraní ve specifikaci EIP-1271 (o parametru `_hash` budeme mluvit níže, ale prozatím si ho představte jako zprávu, která je ověřována):
+
+```jsx
+pragma solidity ^0.5.0;
+
+contract ERC1271 {
+
+ // bytes4(keccak256("isValidSignature(bytes32,bytes)")
+ bytes4 constant internal MAGICVALUE = 0x1626ba7e;
+
+ /**
+ * @dev Měla by vrátit, zda je poskytnutý podpis platný pro poskytnutý haš
+ * @param _hash Haš dat k podepsání
+ * @param _signature Pole bajtů podpisu spojené s _hash
+ *
+ * MUSÍ vrátit magickou hodnotu bytes4 0x1626ba7e, když funkce projde.
+ * NESMÍ upravovat stav (pomocí STATICCALL pro solc < 0.5, modifikátor view pro solc > 0.5)
+ * MUSÍ povolit externí volání
+ */
+ function isValidSignature(
+ bytes32 _hash,
+ bytes memory _signature)
+ public
+ view
+ returns (bytes4 magicValue);
+}
+```
+
+## Příklad implementace EIP-1271: Safe
+
+Kontrakty mohou implementovat `isValidSignature` mnoha způsoby — specifikace neříká mnoho o přesné implementaci.
+
+Jedním z pozoruhodných kontraktů, který implementuje EIP-1271, je Safe (dříve Gnosis Safe).
+
+V kódu Safe je `isValidSignature` [implementována](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol) tak, že podpisy lze vytvářet a ověřovat [dvěma způsoby](https://ethereum.stackexchange.com/questions/122635/signing-messages-as-a-gnosis-safe-eip1271-support):
+
+1. Zprávy na blockchainu
+ 1. Vytvoření: vlastník Safe vytvoří novou transakci Safe k „podepsání“ zprávy a předá zprávu jako data do transakce. Jakmile transakci podepíše dostatek vlastníků k dosažení prahu pro multisig, transakce se odešle a spustí. V transakci je funkce Safe s názvem (`signMessage(bytes calldata _data)`), která přidá zprávu na seznam „schválených“ zpráv.
+ 2. Ověření: zavolejte `isValidSignature` na kontraktu Safe a předejte zprávu k ověření jako parametr zprávy a [prázdnou hodnotu pro parametr podpisu](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol#L32) (tj. `0x`). Safe uvidí, že parametr podpisu je prázdný, a místo kryptografického ověření podpisu bude vědět, že má pouze zkontrolovat, zda je zpráva na seznamu „schválených“ zpráv.
+2. Zprávy mimo blockchain:
+ 1. Vytvoření: vlastník Safe vytvoří zprávu mimo blockchain, poté nechá ostatní vlastníky Safe podepsat zprávu jednotlivě, dokud nebude dostatek podpisů k překonání prahu schválení multisig.
+ 2. Ověření: zavolejte `isValidSignature`. Do parametru zprávy předejte zprávu k ověření. Do parametru podpisu předejte jednotlivé podpisy všech vlastníků Safe, všechny spojené za sebou. Safe zkontroluje, že je dostatek podpisů pro splnění prahu **a** že každý podpis je platný. Pokud ano, vrátí hodnotu označující úspěšné ověření podpisu.
+
+## Co přesně je parametr `_hash`? Proč nepředat celou zprávu?
+
+Možná jste si všimli, že funkce `isValidSignature` v [rozhraní EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) nepřijímá samotnou zprávu, ale místo toho parametr `_hash`. To znamená, že místo předání celé zprávy libovolné délky do `isValidSignature` předáme 32bajtový haš zprávy (obvykle keccak256).
+
+Každý bajt calldata — tj. data parametrů funkce předaná funkci chytrého kontraktu — [stojí 16 jednotek paliva (4 jednotky paliva, pokud je to nulový bajt)](https://eips.ethereum.org/EIPS/eip-2028), takže to může ušetřit spoustu paliva, pokud je zpráva dlouhá.
+
+### Předchozí specifikace EIP-1271
+
+Existují specifikace EIP-1271, které mají funkci `isValidSignature` s prvním parametrem typu `bytes` (libovolná délka, místo pevné délky `bytes32`) a názvem parametru `message`. Toto je [starší verze](https://github.com/safe-global/safe-contracts/issues/391#issuecomment-1075427206) standardu EIP-1271.
+
+## Jak by měl být EIP-1271 implementován v mých vlastních kontraktech?
+
+Specifikace je v tomto ohledu velmi otevřená. Implementace Safe má několik dobrých nápadů:
+
+- Můžete považovat podpisy EOA od "vlastníka" kontraktu za platné.
+- Můžete si uložit seznam schválených zpráv a pouze ty považovat za platné.
+
+Nakonec je to na vás jako na vývojáři kontraktu!
+
+## Závěr
+
+[EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) je všestranný standard, který umožňuje chytrým kontraktům ověřovat podpisy. Otevírá dveře pro chytré kontrakty, aby se chovaly více jako EOA – například poskytuje způsob, jak "Přihlásit se pomocí Etherea" funguje s chytrými kontrakty – a může být implementován mnoha způsoby (Safe má netriviální, zajímavou implementaci k zvážení).
diff --git a/public/content/translations/cs/developers/tutorials/erc-721-vyper-annotated-code/index.md b/public/content/translations/cs/developers/tutorials/erc-721-vyper-annotated-code/index.md
new file mode 100644
index 00000000000..dbe63668feb
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/erc-721-vyper-annotated-code/index.md
@@ -0,0 +1,712 @@
+---
+title: "Průchod kontraktem Vyper ERC-721"
+description: Kontrakt ERC-721 od Ryuyi Nakamury a jak funguje
+author: Ori Pomerantz
+lang: cs
+tags: [ "vyper", "erc-721", "python" ]
+skill: beginner
+published: 2021-04-01
+---
+
+## Úvod {#introduction}
+
+Standard [ERC-721](/developers/docs/standards/tokens/erc-721/) se používá k držení vlastnictví nezaměnitelných tokenů (NFT).
+Tokeny [ERC-20](/developers/docs/standards/tokens/erc-20/) se chovají jako komodita, protože mezi jednotlivými tokeny není žádný rozdíl.
+Naproti tomu tokeny ERC-721 jsou navrženy pro aktiva, která jsou si podobná, ale ne totožná, jako jsou například různé [kreslené kočky](https://www.cryptokitties.co/)
+nebo vlastnická práva k různým nemovitostem.
+
+V tomto článku budeme analyzovat [kontrakt ERC-721 od Ryuyi Nakamury](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy).
+Tento kontrakt je napsán v jazyce [Vyper](https://vyper.readthedocs.io/en/latest/index.html), kontraktovém jazyce podobném Pythonu, který je navržen tak, aby bylo
+psaní nezabezpečeného kódu obtížnější než v Solidity.
+
+## Kontrakt {#contract}
+
+```python
+# @dev Implementace standardu nezaměnitelného tokenu ERC-721.
+# @author Ryuya Nakamura (@nrryuya)
+# Upraveno z: https://github.com/vyperlang/vyper/blob/de74722bf2d8718cca46902be165f9fe0e3641dd/examples/tokens/ERC721.vy
+```
+
+Komentáře ve Vyperu, stejně jako v Pythonu, začínají mřížkou (`#`) a pokračují až do konce řádku. Komentáře, které obsahují
+`@`, se používají v [NatSpecu](https://vyper.readthedocs.io/en/latest/natspec.html) k vytvoření lidsky čitelné
+dokumentace.
+
+```python
+from vyper.interfaces import ERC721
+
+implements: ERC721
+```
+
+Rozhraní ERC-721 je zabudováno do jazyka Vyper.
+[Definici kódu naleznete zde](https://github.com/vyperlang/vyper/blob/master/vyper/builtin_interfaces/ERC721.py).
+Definice rozhraní je napsána v Pythonu, nikoli ve Vyperu, protože rozhraní se používají nejen v rámci
+blockchainu, ale také při odesílání transakce do blockchainu z externího klienta, který může být napsán v
+Pythonu.
+
+První řádek importuje rozhraní a druhý určuje, že ho zde implementujeme.
+
+### Rozhraní ERC721Receiver {#receiver-interface}
+
+```python
+# Rozhraní pro kontrakt volaný funkcí safeTransferFrom()
+interface ERC721Receiver:
+ def onERC721Received(
+```
+
+ERC-721 podporuje dva typy převodů:
+
+- `transferFrom`, který umožňuje odesílateli zadat jakoukoli cílovou adresu a přenáší odpovědnost
+ za převod na odesílatele. To znamená, že můžete provést převod na neplatnou adresu, v takovém případě
+ je NFT navždy ztraceno.
+- `safeTransferFrom`, který kontroluje, zda je cílová adresa kontrakt. Pokud ano, kontrakt ERC-721 se
+ zeptá přijímajícího kontraktu, zda chce NFT přijmout.
+
+Aby mohl přijímající kontrakt odpovídat na požadavky `safeTransferFrom`, musí implementovat `ERC721Receiver`.
+
+```python
+ _operator: address,
+ _from: address,
+```
+
+Adresa `_from` je aktuální vlastník tokenu. Adresa `_operator` je ta, která
+požadovala převod (tyto dvě adresy se mohou lišit z důvodu povolenek).
+
+```python
+ _tokenId: uint256,
+```
+
+ID tokenů ERC-721 jsou 256bitové. Obvykle se vytvářejí hašováním popisu toho,
+co token představuje.
+
+```python
+ _data: Bytes[1024]
+```
+
+Požadavek může obsahovat až 1024 bajtů uživatelských dat.
+
+```python
+ ) -> bytes32: view
+```
+
+Aby se předešlo případům, kdy kontrakt omylem přijme převod, není návratová hodnota booleovská,
+ale 256 bitů s konkrétní hodnotou.
+
+Tato funkce je `view`, což znamená, že může číst stav blockchainu, ale nemůže ho měnit.
+
+### Události {#events}
+
+[Události](https://media.consensys.net/technical-introduction-to-events-and-logs-in-ethereum-a074d65dd61e)
+se vysílají za účelem informování uživatelů a serverů mimo blockchain o událostech. Všimněte si, že obsah událostí
+není dostupný pro kontrakty na blockchainu.
+
+```python
+# @dev Vysílá se, když se jakýmkoli mechanismem změní vlastnictví jakéhokoli NFT. Tato událost se vysílá, když jsou NFT
+# vytvořeny (`from` == 0) a zničeny (`to` == 0). Výjimka: během vytváření kontraktu může být
+# vytvořen a přiřazen libovolný počet NFT bez vyslání události Transfer. V okamžiku jakéhokoli
+# převodu se schválená adresa pro dané NFT (pokud existuje) vynuluje.
+# @param _from Odesílatel NFT (pokud je adresa nulová, značí to vytvoření tokenu).
+# @param _to Příjemce NFT (pokud je adresa nulová, značí to zničení tokenu).
+# @param _tokenId NFT, které bylo převedeno.
+event Transfer:
+ sender: indexed(address)
+ receiver: indexed(address)
+ tokenId: indexed(uint256)
+```
+
+Je to podobné události Transfer v ERC-20 s tím rozdílem, že místo částky hlásíme `tokenId`.
+Nikdo nevlastní nulovou adresu, takže ji zvykově používáme k hlášení o vytvoření a zničení tokenů.
+
+```python
+# @dev Vysílá se, když je schválená adresa pro NFT změněna nebo znovu potvrzena. Nulová
+# adresa značí, že neexistuje žádná schválená adresa. Když se vyšle událost Transfer, značí to
+# také, že schválená adresa pro dané NFT (pokud existuje) se vynuluje.
+# @param _owner Vlastník NFT.
+# @param _approved Adresa, kterou schvalujeme.
+# @param _tokenId NFT, které schvalujeme.
+event Approval:
+ owner: indexed(address)
+ approved: indexed(address)
+ tokenId: indexed(uint256)
+```
+
+Schválení ERC-721 je podobné povolence v ERC-20. Konkrétní adresa má povoleno převést konkrétní
+token. To dává kontraktům mechanismus, jak reagovat na přijetí tokenu. Kontrakty nemohou
+naslouchat událostem, takže pokud jim token pouze převedete, \"neví\" o tom. Tímto způsobem
+vlastník nejprve podá schválení a poté zašle kontraktu žádost: \"Schválil jsem vám převod tokenu
+X, prosím, proveďte...\".
+
+Jedná se o návrhové rozhodnutí, aby byl standard ERC-721 podobný standardu ERC-20. Protože
+tokeny ERC-721 nejsou zaměnitelné, může kontrakt také identifikovat, že získal konkrétní token, pohledem
+na vlastnictví tokenu.
+
+```python
+# @dev Vysílá se, když je operátor pro vlastníka povolen nebo zakázán. Operátor může spravovat
+# všechny NFT vlastníka.
+# @param _owner Vlastník NFT.
+# @param _operator Adresa, které nastavujeme práva operátora.
+# @param _approved Stav práv operátora (true, pokud jsou práva udělena, a false, pokud jsou
+# odvolána).
+event ApprovalForAll:
+ owner: indexed(address)
+ operator: indexed(address)
+ approved: bool
+```
+
+Někdy je užitečné mít _operátora_, který může spravovat všechny tokeny určitého typu na účtu (ty, které jsou spravovány
+konkrétním kontraktem), podobně jako plná moc. Například bych mohl chtít takovou pravomoc udělit kontraktu, který kontroluje, zda
+jsem ho nekontaktoval po dobu šesti měsíců, a pokud ano, rozdělí můj majetek mým dědicům (pokud o to některý z nich požádá; kontrakty
+nemohou dělat nic, aniž by byly volány transakcí). V ERC-20 můžeme dědickému kontraktu dát vysokou povolenku,
+ale to u ERC-721 nefunguje, protože tokeny nejsou zaměnitelné. Toto je ekvivalent.
+
+Hodnota `approved` nám říká, zda se událost týká schválení, nebo jeho odvolání.
+
+### Stavové proměnné {#state-vars}
+
+Tyto proměnné obsahují aktuální stav tokenů: které jsou dostupné a kdo je vlastní. Většina z nich
+jsou objekty `HashMap`, [jednosměrná mapování, která existují mezi dvěma typy](https://vyper.readthedocs.io/en/latest/types.html#mappings).
+
+```python
+# @dev Mapování z ID NFT na adresu, která jej vlastní.
+idToOwner: HashMap[uint256, address]
+
+# @dev Mapování z ID NFT na schválenou adresu.
+idToApprovals: HashMap[uint256, address]
+```
+
+Identity uživatelů a kontraktů v Ethereu jsou reprezentovány 160bitovými adresami. Tyto dvě proměnné mapují
+ID tokenů na jejich vlastníky a ty, kteří mají schváleno je převést (maximálně jeden pro každý token). V Ethereu
+jsou neinicializovaná data vždy nulová, takže pokud pro daný token neexistuje vlastník nebo schválený převodce, je jeho hodnota
+nulová.
+
+```python
+# @dev Mapování z adresy vlastníka na počet jeho tokenů.
+ownerToNFTokenCount: HashMap[address, uint256]
+```
+
+Tato proměnná uchovává počet tokenů pro každého vlastníka. Neexistuje žádné mapování od vlastníků k tokenům, takže
+jediný způsob, jak identifikovat tokeny, které konkrétní vlastník vlastní, je podívat se zpět do historie událostí blockchainu
+a najít příslušné události `Transfer`. Tuto proměnnou můžeme použít k tomu, abychom věděli, kdy máme všechny NFT a nemusíme
+se dívat ještě dále do minulosti.
+
+Všimněte si, že tento algoritmus funguje pouze pro uživatelská rozhraní a externí servery. Kód běžící na samotném blockchainu
+nemůže číst minulé události.
+
+```python
+# @dev Mapování z adresy vlastníka na mapování adres operátorů.
+ownerToOperators: HashMap[address, HashMap[address, bool]]
+```
+
+Účet může mít více než jednoho operátora. Jednoduchá `HashMap` je pro
+jejich sledování nedostatečná, protože každý klíč vede k jedné hodnotě. Místo toho můžete jako hodnotu použít
+`HashMap[address, bool]`. Standardně je hodnota pro každou adresu `False`, což znamená, že
+není operátorem. Podle potřeby můžete nastavit hodnoty na `True`.
+
+```python
+# @dev Adresa mintera, který může razit tokeny
+minter: address
+```
+
+Nové tokeny musí být nějakým způsobem vytvořeny. V tomto kontraktu existuje jediná entita, která to má povoleno, a to
+`minter`. To je například pravděpodobně dostačující pro hru. Pro jiné účely může být nutné
+vytvořit složitější obchodní logiku.
+
+```python
+# @dev Mapování ID rozhraní na booleovskou hodnotu, zda je či není podporováno
+supportedInterfaces: HashMap[bytes32, bool]
+
+# @dev ID rozhraní ERC165 standardu ERC165
+ERC165_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000001ffc9a7
+
+# @dev ID rozhraní ERC165 standardu ERC721
+ERC721_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000080ac58cd
+```
+
+[ERC-165](https://eips.ethereum.org/EIPS/eip-165) specifikuje mechanismus, jak může kontrakt zveřejnit, jak s ním mohou aplikace
+komunikovat a kterým standardům ERC odpovídá. V tomto případě kontrakt odpovídá standardům ERC-165 a ERC-721.
+
+### Funkce {#functions}
+
+Toto jsou funkce, které skutečně implementují ERC-721.
+
+#### Konstruktor {#constructor}
+
+```python
+@external
+def __init__():
+```
+
+Ve Vyperu, stejně jako v Pythonu, se funkce konstruktoru nazývá `__init__`.
+
+```python
+ """
+ @dev Konstruktor kontraktu.
+ """
+```
+
+V Pythonu a ve Vyperu můžete také vytvořit komentář tak, že zadáte víceřádkový řetězec (který začíná a končí
+`"""`) a nijak ho nepoužijete. Tyto komentáře mohou obsahovat také
+[NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html).
+
+```python
+ self.supportedInterfaces[ERC165_INTERFACE_ID] = True
+ self.supportedInterfaces[ERC721_INTERFACE_ID] = True
+ self.minter = msg.sender
+```
+
+Pro přístup ke stavovým proměnným použijte `self.`(opět, stejně jako v Pythonu).
+
+#### Funkce view {#views}
+
+Jedná se o funkce, které nemění stav blockchainu, a proto mohou být provedeny zdarma,
+pokud jsou volány externě. Pokud jsou funkce view volány kontraktem, stále musí být provedeny na
+každém uzlu, a proto stojí palivo.
+
+```python
+@view
+@external
+```
+
+Tato klíčová slova před definicí funkce, která začínají zavináčem (`@`), se nazývají _dekorace_. Určují
+okolnosti, za kterých lze funkci volat.
+
+- `@view` určuje, že tato funkce je view.
+- `@external` určuje, že tato konkrétní funkce může být volána transakcemi a jinými kontrakty.
+
+```python
+def supportsInterface(_interfaceID: bytes32) -> bool:
+```
+
+Na rozdíl od Pythonu je Vyper [jazyk se statickým typováním](https://wikipedia.org/wiki/Type_system#Static_type_checking).
+Nelze deklarovat proměnnou nebo parametr funkce bez identifikace [datového typu](https://vyper.readthedocs.io/en/latest/types.html). V tomto případě je vstupní parametr `bytes32`, 256bitová hodnota
+(256 bitů je nativní velikost slova [Ethereum Virtual Machine (EVM)](/developers/docs/evm/)). Výstupem je booleovská
+hodnota. Názvy parametrů funkcí zvykově začínají podtržítkem (`_`).
+
+```python
+ """
+ @dev Identifikace rozhraní je specifikována v ERC-165.
+ @param _interfaceID ID rozhraní
+ """
+ return self.supportedInterfaces[_interfaceID]
+```
+
+Vrátí hodnotu z `self.supportedInterfaces` HashMap, která je nastavena v konstruktoru (`__init__`).
+
+```python
+### FUNKCE VIEW ###
+```
+
+Toto jsou funkce view, které zpřístupňují informace o tokenech uživatelům a jiným kontraktům.
+
+```python
+@view
+@external
+def balanceOf(_owner: address) -> uint256:
+ """
+ @dev Vrátí počet NFT vlastněných `_owner`.
+ Vrátí chybu, pokud je `_owner` nulová adresa. NFT přiřazené k nulové adrese jsou považovány za neplatné.
+ @param _owner Adresa, pro kterou se má dotazovat na zůstatek.
+ """
+ assert _owner != ZERO_ADDRESS
+```
+
+Tento řádek [zajišťuje](https://vyper.readthedocs.io/en/latest/statements.html#assert), že `_owner` není
+nulová adresa. Pokud ano, dojde k chybě a operace se vrátí zpět.
+
+```python
+ return self.ownerToNFTokenCount[_owner]
+
+@view
+@external
+def ownerOf(_tokenId: uint256) -> address:
+ """
+ @dev Vrátí adresu vlastníka NFT.
+ Vrátí chybu, pokud `_tokenId` není platné NFT.
+ @param _tokenId Identifikátor NFT.
+ """
+ owner: address = self.idToOwner[_tokenId]
+ # Vrátí chybu, pokud `_tokenId` není platné NFT
+ assert owner != ZERO_ADDRESS
+ return owner
+```
+
+V Ethereum Virtual Machine (EVM) je jakékoli úložiště, které v sobě nemá uloženou hodnotu, nulové.
+Pokud na `_tokenId` není žádný token, pak je hodnota `self.idToOwner[_tokenId]` nulová. V takovém případě
+se funkce vrátí zpět.
+
+```python
+@view
+@external
+def getApproved(_tokenId: uint256) -> address:
+ """
+ @dev Získá schválenou adresu pro jedno NFT.
+ Vrátí chybu, pokud `_tokenId` není platné NFT.
+ @param _tokenId ID NFT, pro které se má dotazovat na schválení.
+ """
+ # Vrátí chybu, pokud `_tokenId` není platné NFT
+ assert self.idToOwner[_tokenId] != ZERO_ADDRESS
+ return self.idToApprovals[_tokenId]
+```
+
+Všimněte si, že `getApproved` _může_ vrátit nulu. Pokud je token platný, vrátí `self.idToApprovals[_tokenId]`.
+Pokud neexistuje žádný schvalovatel, tato hodnota je nulová.
+
+```python
+@view
+@external
+def isApprovedForAll(_owner: address, _operator: address) -> bool:
+ """
+ @dev Zkontroluje, zda je `_operator` schválený operátor pro `_owner`.
+ @param _owner Adresa, která vlastní NFT.
+ @param _operator Adresa, která jedná jménem vlastníka.
+ """
+ return (self.ownerToOperators[_owner])[_operator]
+```
+
+Tato funkce kontroluje, zda má `_operator` povoleno spravovat všechny tokeny `_owner` v tomto kontraktu.
+Protože může existovat více operátorů, jedná se o dvouúrovňovou HashMap.
+
+#### Pomocné funkce pro převod {#transfer-helpers}
+
+Tyto funkce implementují operace, které jsou součástí převodu nebo správy tokenů.
+
+```python
+
+### POMOCNÉ FUNKCE PRO PŘEVOD ###
+
+@view
+@internal
+```
+
+Tato dekorace, `@internal`, znamená, že funkce je přístupná pouze z jiných funkcí v rámci
+stejného kontraktu. Názvy těchto funkcí zvykově také začínají podtržítkem (`_`).
+
+```python
+def _isApprovedOrOwner(_spender: address, _tokenId: uint256) -> bool:
+ """
+ @dev Vrátí, zda daný spender může převést dané ID tokenu
+ @param spender adresa spendera, na kterou se dotazujeme
+ @param tokenId uint256 ID tokenu, který má být převeden
+ @return bool zda je msg.sender schválen pro dané ID tokenu,
+ je operátorem vlastníka, nebo je vlastníkem tokenu
+ """
+ owner: address = self.idToOwner[_tokenId]
+ spenderIsOwner: bool = owner == _spender
+ spenderIsApproved: bool = _spender == self.idToApprovals[_tokenId]
+ spenderIsApprovedForAll: bool = (self.ownerToOperators[owner])[_spender]
+ return (spenderIsOwner or spenderIsApproved) or spenderIsApprovedForAll
+```
+
+Existují tři způsoby, jak může adresa získat povolení k převodu tokenu:
+
+1. Adresa je vlastníkem tokenu
+2. Adresa má schváleno utratit tento token
+3. Adresa je operátorem pro vlastníka tokenu
+
+Výše uvedená funkce může být view, protože nemění stav. Pro snížení provozních nákladů by každá
+funkce, která _může_ být view, _měla_ být view.
+
+```python
+@internal
+def _addTokenTo(_to: address, _tokenId: uint256):
+ """
+ @dev Přidá NFT k dané adrese
+ Vrátí chybu, pokud je `_tokenId` vlastněno někým jiným.
+ """
+ # Vrátí chybu, pokud je `_tokenId` vlastněno někým jiným
+ assert self.idToOwner[_tokenId] == ZERO_ADDRESS
+ # Změní vlastníka
+ self.idToOwner[_tokenId] = _to
+ # Změní sledování počtu
+ self.ownerToNFTokenCount[_to] += 1
+
+
+@internal
+def _removeTokenFrom(_from: address, _tokenId: uint256):
+ """
+ @dev Odebere NFT z dané adresy
+ Vrátí chybu, pokud `_from` není aktuální vlastník.
+ """
+ # Vrátí chybu, pokud `_from` není aktuální vlastník
+ assert self.idToOwner[_tokenId] == _from
+ # Změní vlastníka
+ self.idToOwner[_tokenId] = ZERO_ADDRESS
+ # Změní sledování počtu
+ self.ownerToNFTokenCount[_from] -= 1
+```
+
+Pokud se vyskytne problém s převodem, vrátíme volání zpět.
+
+```python
+@internal
+def _clearApproval(_owner: address, _tokenId: uint256):
+ """
+ @dev Zruší schválení dané adresy
+ Vrátí chybu, pokud `_owner` není aktuální vlastník.
+ """
+ # Vrátí chybu, pokud `_owner` není aktuální vlastník
+ assert self.idToOwner[_tokenId] == _owner
+ if self.idToApprovals[_tokenId] != ZERO_ADDRESS:
+ # Vynuluje schválení
+ self.idToApprovals[_tokenId] = ZERO_ADDRESS
+```
+
+Hodnotu změňte pouze v případě nutnosti. Stavové proměnné se nacházejí v úložišti. Zápis do úložiště je
+jednou z nejdražších operací, které EVM (Ethereum Virtual Machine) provádí (z hlediska
+[paliva](/developers/docs/gas/)). Proto je dobré ji minimalizovat, i zápis
+existující hodnoty má vysoké náklady.
+
+```python
+@internal
+def _transferFrom(_from: address, _to: address, _tokenId: uint256, _sender: address):
+ """
+ @dev Provede převod NFT.
+ Vrátí chybu, pokud `msg.sender` není aktuální vlastník, autorizovaný operátor nebo schválená
+ adresa pro toto NFT. (POZNÁMKA: `msg.sender` není povoleno v soukromé funkci, takže se předává `_sender`.)
+ Vrátí chybu, pokud je `_to` nulová adresa.
+ Vrátí chybu, pokud `_from` není aktuální vlastník.
+ Vrátí chybu, pokud `_tokenId` není platné NFT.
+ """
+```
+
+Tuto interní funkci máme proto, že existují dva způsoby převodu tokenů (běžný a bezpečný), ale
+chceme mít pouze jedno místo v kódu, kde to děláme, abychom usnadnili auditování.
+
+```python
+ # Zkontroluje požadavky
+ assert self._isApprovedOrOwner(_sender, _tokenId)
+ # Vrátí chybu, pokud je `_to` nulová adresa
+ assert _to != ZERO_ADDRESS
+ # Zruší schválení. Vrátí chybu, pokud `_from` není aktuální vlastník
+ self._clearApproval(_from, _tokenId)
+ # Odebere NFT. Vrátí chybu, pokud `_tokenId` není platné NFT
+ self._removeTokenFrom(_from, _tokenId)
+ # Přidá NFT
+ self._addTokenTo(_to, _tokenId)
+ # Zapíše převod do protokolu
+ log Transfer(_from, _to, _tokenId)
+```
+
+Pro vyslání události ve Vyperu použijete příkaz `log` ([více podrobností zde](https://vyper.readthedocs.io/en/latest/event-logging.html#event-logging)).
+
+#### Funkce pro převod {#transfer-funs}
+
+```python
+
+### FUNKCE PRO PŘEVOD ###
+
+@external
+def transferFrom(_from: address, _to: address, _tokenId: uint256):
+ """
+ @dev Vrátí chybu, pokud `msg.sender` není aktuální vlastník, autorizovaný operátor nebo schválená
+ adresa pro toto NFT.
+ Vrátí chybu, pokud `_from` není aktuální vlastník.
+ Vrátí chybu, pokud je `_to` nulová adresa.
+ Vrátí chybu, pokud `_tokenId` není platné NFT.
+ @notice Volající je odpovědný za potvrzení, že `_to` je schopno přijímat NFT, jinak
+ mohou být trvale ztraceny.
+ @param _from Aktuální vlastník NFT.
+ @param _to Nový vlastník.
+ @param _tokenId NFT k převodu.
+ """
+ self._transferFrom(_from, _to, _tokenId, msg.sender)
+```
+
+Tato funkce umožňuje převod na libovolnou adresu. Pokud adresa není uživatel nebo kontrakt, který
+ví, jak převádět tokeny, jakýkoli token, který převedete, zůstane na této adrese a bude k ničemu.
+
+```python
+@external
+def safeTransferFrom(
+ _from: address,
+ _to: address,
+ _tokenId: uint256,
+ _data: Bytes[1024]=b""
+ ):
+ """
+ @dev Přenáší vlastnictví NFT z jedné adresy na jinou.
+ Vrátí chybu, pokud `msg.sender` není aktuální vlastník, autorizovaný operátor nebo
+ schválená adresa pro toto NFT.
+ Vrátí chybu, pokud `_from` není aktuální vlastník.
+ Vrátí chybu, pokud je `_to` nulová adresa.
+ Vrátí chybu, pokud `_tokenId` není platné NFT.
+ Pokud je `_to` chytrý kontrakt, volá `onERC721Received` na `_to` a vrátí chybu, pokud
+ návratová hodnota není `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`.
+ POZNÁMKA: bytes4 je reprezentováno jako bytes32 s výplní
+ @param _from Aktuální vlastník NFT.
+ @param _to Nový vlastník.
+ @param _tokenId NFT k převodu.
+ @param _data Dodatečná data bez specifikovaného formátu, odeslaná ve volání na `_to`.
+ """
+ self._transferFrom(_from, _to, _tokenId, msg.sender)
+```
+
+Je v pořádku provést převod nejprve, protože pokud se vyskytne problém, stejně se vrátíme zpět,
+takže vše provedené ve volání bude zrušeno.
+
+```python
+ if _to.is_contract: # zkontroluje, zda je `_to` účet kontraktu
+```
+
+Nejprve zkontrolujte, zda je adresa kontrakt (zda má kód). Pokud ne, předpokládejte, že se jedná o uživatelskou
+adresu a uživatel bude moci token použít nebo ho převést. Ale nenechte se tím ukolébat
+do falešného pocitu bezpečí. Můžete ztratit tokeny, i s `safeTransferFrom`, pokud je převedete
+na adresu, ke které nikdo nezná privátní klíč.
+
+```python
+ returnValue: bytes32 = ERC721Receiver(_to).onERC721Received(msg.sender, _from, _tokenId, _data)
+```
+
+Volejte cílový kontrakt, abyste zjistili, zda může přijímat tokeny ERC-721.
+
+```python
+ # Vrátí chybu, pokud je cílem převodu kontrakt, který neimplementuje 'onERC721Received'
+ assert returnValue == method_id("onERC721Received(address,address,uint256,bytes)", output_type=bytes32)
+```
+
+Pokud je cílem kontrakt, ale takový, který nepřijímá tokeny ERC-721 (nebo který se rozhodl nepřijmout tento
+konkrétní převod), vraťte se zpět.
+
+```python
+@external
+def approve(_approved: address, _tokenId: uint256):
+ """
+ @dev Nastaví nebo znovu potvrdí schválenou adresu pro NFT. Nulová adresa značí, že neexistuje žádná schválená adresa.
+ Vrátí chybu, pokud `msg.sender` není aktuální vlastník NFT nebo autorizovaný operátor aktuálního vlastníka.
+ Vrátí chybu, pokud `_tokenId` není platné NFT. (POZNÁMKA: Toto není uvedeno v EIP)
+ Vrátí chybu, pokud je `_approved` aktuální vlastník. (POZNÁMKA: Toto není uvedeno v EIP)
+ @param _approved Adresa, která má být schválena pro dané ID NFT.
+ @param _tokenId ID tokenu, který má být schválen.
+ """
+ owner: address = self.idToOwner[_tokenId]
+ # Vrátí chybu, pokud `_tokenId` není platné NFT
+ assert owner != ZERO_ADDRESS
+ # Vrátí chybu, pokud je `_approved` aktuální vlastník
+ assert _approved != owner
+```
+
+Pokud zvykově nechcete mít schvalovatele, jmenujte nulovou adresu, ne sebe.
+
+```python
+ # Zkontroluje požadavky
+ senderIsOwner: bool = self.idToOwner[_tokenId] == msg.sender
+ senderIsApprovedForAll: bool = (self.ownerToOperators[owner])[msg.sender]
+ assert (senderIsOwner or senderIsApprovedForAll)
+```
+
+Pro nastavení schválení můžete být buď vlastníkem, nebo operátorem autorizovaným vlastníkem.
+
+```python
+ # Nastaví schválení
+ self.idToApprovals[_tokenId] = _approved
+ log Approval(owner, _approved, _tokenId)
+
+
+@external
+def setApprovalForAll(_operator: address, _approved: bool):
+ """
+ @dev Povolí nebo zakáže schválení pro třetí stranu („operátora“) ke správě všech
+ aktiv `msg.sender`. Také vysílá událost ApprovalForAll.
+ Vrátí chybu, pokud je `_operator` `msg.sender`. (POZNÁMKA: Toto není uvedeno v EIP)
+ @notice Toto funguje i v případě, že odesílatel v daném okamžiku nevlastní žádné tokeny.
+ @param _operator Adresa, která se má přidat do sady autorizovaných operátorů.
+ @param _approved True, pokud je operátor schválen, false pro odvolání schválení.
+ """
+ # Vrátí chybu, pokud je `_operator` `msg.sender`
+ assert _operator != msg.sender
+ self.ownerToOperators[msg.sender][_operator] = _approved
+ log ApprovalForAll(msg.sender, _operator, _approved)
+```
+
+#### Ražba nových tokenů a zničení stávajících {#mint-burn}
+
+Účet, který vytvořil kontrakt, je `minter`, super uživatel, který je oprávněn razit
+nové NFT. Ani on však nesmí pálit existující tokeny. To může udělat pouze vlastník nebo entita
+autorizovaná vlastníkem.
+
+```python
+### FUNKCE PRO RAŽBU A PÁLENÍ ###
+
+@external
+def mint(_to: address, _tokenId: uint256) -> bool:
+```
+
+Tato funkce vždy vrátí `True`, protože pokud operace selže, vrátí se zpět.
+
+```python
+ """
+ @dev Funkce pro ražbu tokenů
+ Vrátí chybu, pokud `msg.sender` není minter.
+ Vrátí chybu, pokud je `_to` nulová adresa.
+ Vrátí chybu, pokud je `_tokenId` vlastněno někým jiným.
+ @param _to Adresa, která obdrží ražené tokeny.
+ @param _tokenId ID tokenu k ražbě.
+ @return Booleovská hodnota, která značí, zda byla operace úspěšná.
+ """
+```
+
+Pouze minter (účet, který vytvořil kontrakt ERC-721) může razit nové tokeny. To může být
+v budoucnu problém, pokud budeme chtít změnit identitu mintera. V
+produkčním kontraktu byste pravděpodobně chtěli funkci, která minterovi umožní převést
+práva mintera na někoho jiného.
+
+```python
+ # Vrátí chybu, pokud je `_to` nulová adresa
+ assert _to != ZERO_ADDRESS
+ # Přidá NFT. Vrátí chybu, pokud je `_tokenId` vlastněno někým jiným
+ self._addTokenTo(_to, _tokenId)
+ log Transfer(ZERO_ADDRESS, _to, _tokenId)
+ return True
+```
+
+Ražba nových tokenů se zvykově počítá jako převod z nulové adresy.
+
+```python
+
+@external
+def burn(_tokenId: uint256):
+ """
+ @dev Spálí konkrétní token ERC721.
+ Vrátí chybu, pokud `msg.sender` není aktuální vlastník, autorizovaný operátor nebo schválená
+ adresa pro toto NFT.
+ Vrátí chybu, pokud `_tokenId` není platné NFT.
+ @param _tokenId uint256 id tokenu ERC721, který má být spálen.
+ """
+ # Zkontroluje požadavky
+ assert self._isApprovedOrOwner(msg.sender, _tokenId)
+ owner: address = self.idToOwner[_tokenId]
+ # Vrátí chybu, pokud `_tokenId` není platné NFT
+ assert owner != ZERO_ADDRESS
+ self._clearApproval(owner, _tokenId)
+ self._removeTokenFrom(owner, _tokenId)
+ log Transfer(owner, ZERO_ADDRESS, _tokenId)
+```
+
+Každý, kdo má povoleno převést token, ho smí spálit. Ačkoli se pálení zdá být ekvivalentem
+převodu na nulovou adresu, nulová adresa ve skutečnosti token neobdrží. To nám umožňuje
+uvolnit veškeré úložiště, které bylo pro token použito, což může snížit náklady na palivo transakce.
+
+## Použití tohoto kontraktu {#using-contract}
+
+Na rozdíl od Solidity, Vyper nemá dědičnost. Jedná se o záměrné návrhové rozhodnutí, které má za cíl zpřehlednit kód,
+a tím usnadnit jeho zabezpečení. Chcete-li tedy vytvořit svůj vlastní kontrakt Vyper ERC-721, vezměte tento
+kontrakt a upravte ho
+tak, aby implementoval obchodní logiku, kterou chcete.
+
+## Závěr {#conclusion}
+
+Pro shrnutí, zde jsou některé z nejdůležitějších myšlenek v tomto kontraktu:
+
+- Pro příjem tokenů ERC-721 s bezpečným převodem musí kontrakty implementovat rozhraní `ERC721Receiver`.
+- I když použijete bezpečný převod, tokeny se mohou stále zaseknout, pokud je pošlete na adresu, jejíž privátní klíč
+ je neznámý.
+- Když se vyskytne problém s operací, je dobré volání `vrátit`, nikoli jen vrátit
+ hodnotu selhání.
+- Tokeny ERC-721 existují, když mají vlastníka.
+- Existují tři způsoby, jak být oprávněn k převodu NFT. Můžete být vlastníkem, být schválen pro konkrétní token,
+ nebo být operátorem pro všechny tokeny vlastníka.
+- Minulé události jsou viditelné pouze mimo blockchain. Kód běžící uvnitř blockchainu je nemůže zobrazit.
+
+Nyní jděte a implementujte bezpečné kontrakty Vyper.
+
+[Více z mé práce najdete zde](https://cryptodocguy.pro/).
+
diff --git a/public/content/translations/cs/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/cs/developers/tutorials/erc20-annotated-code/index.md
new file mode 100644
index 00000000000..a6f21ec0cef
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/erc20-annotated-code/index.md
@@ -0,0 +1,927 @@
+---
+title: "Podrobný průvodce kontraktem ERC-20"
+description: Co je v kontraktu OpenZeppelin ERC-20 a proč se tam nachází?
+author: Ori Pomerantz
+lang: cs
+tags: [ "solidity", "erc-20" ]
+skill: beginner
+published: 2021-03-09
+---
+
+## Úvod {#introduction}
+
+Jedním z nejčastějších způsobů využití Etherea je vytvoření obchodovatelného tokenu pro skupinu, v podstatě jejich vlastní měny. Tyto tokeny obvykle dodržují standard
+[ERC-20](/developers/docs/standards/tokens/erc-20/). Tento standard umožňuje psát nástroje, jako jsou pooly likvidity a peněženky, které fungují se všemi tokeny ERC-20. V tomto článku budeme analyzovat implementaci [OpenZeppelin Solidity ERC20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) a také [definici rozhraní](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol).
+
+Jedná se o anotovaný zdrojový kód. Chcete-li implementovat ERC-20,
+[přečtěte si tento návod](https://docs.openzeppelin.com/contracts/2.x/erc20-supply).
+
+## Rozhraní {#the-interface}
+
+Účelem standardu, jako je ERC-20, je umožnit mnoho implementací tokenů, které jsou interoperabilní napříč aplikacemi, jako jsou peněženky a decentralizované burzy. K tomu vytvoříme [rozhraní](https://www.geeksforgeeks.org/solidity/solidity-basics-of-interface/). Jakýkoli kód, který potřebuje použít kontrakt tokenu,
+může použít stejné definice v rozhraní a být kompatibilní se všemi kontrakty tokenu, které jej používají, ať už je to peněženka, jako je MetaMask, dapp, jako je etherscan.io, nebo jiný kontrakt, jako je pool likvidity.
+
+
+
+Pokud jste zkušený programátor, pravděpodobně si pamatujete, že jste podobné konstrukce viděli v [Javě](https://www.w3schools.com/java/java_interface.asp)
+nebo dokonce v [hlavičkových souborech C](https://gcc.gnu.org/onlinedocs/cpp/Header-Files.html).
+
+Toto je definice [rozhraní ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol)
+od OpenZeppelin. Jedná se o překlad [lidsky čitelného standardu](https://eips.ethereum.org/EIPS/eip-20) do kódu v Solidity. Samozřejmě samotné
+rozhraní nedefinuje, _jak_ se má něco dělat. To je vysvětleno ve zdrojovém kódu kontraktu níže.
+
+
+
+```solidity
+// SPDX-License-Identifier: MIT
+```
+
+Soubory v Solidity by měly obsahovat identifikátor licence. [Seznam licencí naleznete zde](https://spdx.org/licenses/). Pokud potřebujete jinou
+licenci, jednoduše to vysvětlete v komentářích.
+
+
+
+```solidity
+pragma solidity >=0.6.0 <0.8.0;
+```
+
+Jazyk Solidity se stále rychle vyvíjí a nové verze nemusí být kompatibilní se starým kódem
+([viz zde](https://docs.soliditylang.org/en/v0.7.0/070-breaking-changes.html)). Proto je dobré specifikovat nejen minimální
+verzi jazyka, ale také maximální verzi, nejnovější, se kterou jste kód testovali.
+
+
+
+```solidity
+/**
+ * @dev Rozhraní standardu ERC20, jak je definováno v EIP.
+ */
+```
+
+Značka @dev v komentáři je součástí [formátu NatSpec](https://docs.soliditylang.org/en/develop/natspec-format.html), který se používá k vytváření
+dokumentace ze zdrojového kódu.
+
+
+
+```solidity
+interface IERC20 {
+```
+
+Podle konvence začínají názvy rozhraní písmenem `I`.
+
+
+
+```solidity
+ /**
+ * @dev Vrací množství existujících tokenů.
+ */
+ function totalSupply() external view returns (uint256);
+```
+
+Tato funkce je externí (`external`), což znamená, že [ji lze volat pouze z vnějšku kontraktu](https://docs.soliditylang.org/en/v0.7.0/cheatsheet.html#index-2).
+Vrací celkovou zásobu tokenů v kontraktu. Tato hodnota je vrácena pomocí nejběžnějšího typu v Ethereu, 256bitového celého čísla bez znaménka (256 bitů je
+nativní velikost slova EVM). Tato funkce je také `view`, což znamená, že nemění stav, takže ji lze provést na jednom uzlu, místo aby ji musel
+spouštět každý uzel v blockchainu. Tento druh funkce negeneruje transakci a nestojí žádné [palivo](/developers/docs/gas/).
+
+**Poznámka:** Teoreticky by se mohlo zdát, že tvůrce kontraktu by mohl podvádět vrácením menší celkové zásoby, než je skutečná hodnota, takže by se každý token zdál
+cennější, než ve skutečnosti je. Tato obava však ignoruje skutečnou podstatu blockchainu. Vše, co se děje na blockchainu, může být ověřeno
+každým uzlem. Aby toho bylo dosaženo, je na každém uzlu k dispozici strojový kód a úložiště každého kontraktu. I když nejste povinni zveřejnit kód vašeho kontraktu v
+Solidity, nikdo by vás nebral vážně, pokud nezveřejníte zdrojový kód a verzi Solidity, se kterou byl zkompilován, aby mohl být
+ověřen oproti strojovému kódu, který jste poskytli.
+Podívejte se například na [tento kontrakt](https://eth.blockscout.com/address/0xa530F85085C6FE2f866E7FdB716849714a89f4CD?tab=contract).
+
+
+
+```solidity
+ /**
+ * @dev Vrací množství tokenů, které vlastní `account`.
+ */
+ function balanceOf(address account) external view returns (uint256);
+```
+
+Jak název napovídá, funkce `balanceOf` vrací zůstatek účtu. Účty Etherea jsou v Solidity identifikovány pomocí typu `address`, který obsahuje 160 bitů.
+Je také `external` a `view`.
+
+
+
+```solidity
+ /**
+ * @dev Přesune tokeny v množství `amount` z účtu volajícího na `recipient`.
+ *
+ * Vrací booleovskou hodnotu, která udává, zda operace proběhla úspěšně.
+ *
+ * Vyvolá událost {Transfer}.
+ */
+ function transfer(address recipient, uint256 amount) external returns (bool);
+```
+
+Funkce `transfer` převádí tokeny od volajícího na jinou adresu. To zahrnuje změnu stavu, takže to není `view`.
+Když uživatel zavolá tuto funkci, vytvoří se transakce, která stojí palivo. Rovněž vyvolá událost `Transfer`, aby informovala všechny na
+blockchainu o této události.
+
+Funkce má dva typy výstupu pro dva různé typy volajících:
+
+- Uživatelé, kteří volají funkci přímo z uživatelského rozhraní. Uživatel obvykle odešle transakci
+ a nečeká na odpověď, což může trvat neurčitou dobu. Uživatel může zjistit, co se stalo,
+ vyhledáním potvrzení o transakci (které je identifikováno hašem transakce) nebo vyhledáním
+ události `Transfer`.
+- Jiné kontrakty, které volají funkci jako součást celkové transakce. Tyto kontrakty dostanou výsledek okamžitě,
+ protože běží ve stejné transakci, takže mohou použít návratovou hodnotu funkce.
+
+Stejný typ výstupu je vytvořen ostatními funkcemi, které mění stav kontraktu.
+
+
+
+Povolení umožňují účtu utratit některé tokeny, které patří jinému vlastníkovi.
+To je užitečné například pro kontrakty, které fungují jako prodejci. Kontrakty nemohou
+sledovat události, takže pokud by kupující převedl tokeny přímo na kontrakt prodejce,
+tento kontrakt by nevěděl, že mu bylo zaplaceno. Místo toho kupující povolí
+kontraktu prodejce utratit určitou částku a prodejce tuto částku převede.
+To se děje prostřednictvím funkce, kterou kontrakt prodejce volá, takže kontrakt prodejce
+může vědět, zda byl úspěšný.
+
+```solidity
+ /**
+ * @dev Vrací zbývající počet tokenů, které bude moci `spender`
+ * utratit jménem `owner` prostřednictvím {transferFrom}. Ve výchozím nastavení je
+ * tato hodnota nulová.
+ *
+ * Tato hodnota se mění při volání funkcí {approve} nebo {transferFrom}.
+ */
+ function allowance(address owner, address spender) external view returns (uint256);
+```
+
+Funkce `allowance` umožňuje komukoli dotázat se, jaké je povolení, které jedna
+adresa (`owner`) umožňuje utratit jiné adrese (`spender`).
+
+
+
+```solidity
+ /**
+ * @dev Nastaví `amount` jako povolenou částku pro `spender` pro tokeny volajícího.
+ *
+ * Vrací booleovskou hodnotu, která udává, zda operace proběhla úspěšně.
+ *
+ * DŮLEŽITÉ: Dejte si pozor, že změna povolení touto metodou s sebou nese riziko,
+ * že někdo může nešťastným pořadím transakcí využít jak staré, tak i nové povolení.
+ * Jedním z možných řešení, jak tento souběh zmírnit,
+ * je nejprve snížit povolení pro utrácejícího na 0 a poté nastavit
+ * požadovanou hodnotu:
+ * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
+ *
+ * Vyvolá událost {Approval}.
+ */
+ function approve(address spender, uint256 amount) external returns (bool);
+```
+
+Funkce `approve` vytváří povolení. Nezapomeňte si přečíst zprávu o tom,
+jak může být zneužita. V Ethereu ovládáte pořadí svých vlastních transakcí,
+ale nemůžete ovládat pořadí, v jakém budou provedeny transakce
+jiných lidí, pokud neodešlete vlastní transakci až poté, co uvidíte,
+že transakce druhé strany proběhla.
+
+
+
+```solidity
+ /**
+ * @dev Přesune tokeny v množství `amount` z adresy `sender` na `recipient` pomocí
+ * mechanismu povolení. `amount` se poté odečte od povolení volajícího
+ * .
+ *
+ * Vrací booleovskou hodnotu, která udává, zda operace proběhla úspěšně.
+ *
+ * Vyvolá událost {Transfer}.
+ */
+ function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
+```
+
+Nakonec `transferFrom` použije utrácející k samotnému utracení povolené částky.
+
+
+
+```solidity
+
+ /**
+ * @dev Vyvolá se, když se tokeny v hodnotě `value` přesunou z jednoho účtu (`from`) na
+ * jiný (`to`).
+ *
+ * Všimněte si, že `value` může být nula.
+ */
+ event Transfer(address indexed from, address indexed to, uint256 value);
+
+ /**
+ * @dev Vyvolá se, když je povolení `spendera` pro `ownera` nastaveno
+ * voláním {approve}. `value` je nové povolení.
+ */
+ event Approval(address indexed owner, address indexed spender, uint256 value);
+}
+```
+
+Tyto události jsou emitovány, když se změní stav kontraktu ERC-20.
+
+## Skutečný kontrakt {#the-actual-contract}
+
+Toto je skutečný kontrakt, který implementuje standard ERC-20, [převzato odtud](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol).
+Není určen k použití tak, jak je, ale můžete
+z něj [dědit](https://www.tutorialspoint.com/solidity/solidity_inheritance.htm) a rozšířit jej na něco použitelného.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity >=0.6.0 <0.8.0;
+```
+
+
+
+### Importní příkazy {#import-statements}
+
+Kromě výše uvedených definic rozhraní importuje definice kontraktu dva další soubory:
+
+```solidity
+
+import "../../GSN/Context.sol";
+import "./IERC20.sol";
+import "../../math/SafeMath.sol";
+```
+
+- `GSN/Context.sol` jsou definice potřebné k použití [OpenGSN](https://www.opengsn.org/), systému, který umožňuje uživatelům bez etheru
+ používat blockchain. Všimněte si, že se jedná o starou verzi, pokud chcete integrovat s OpenGSN,
+ [použijte tento návod](https://docs.opengsn.org/javascript-client/tutorial.html).
+- [Knihovna SafeMath](https://ethereumdev.io/using-safe-math-library-to-prevent-from-overflows/), která zabraňuje
+ aritmetickému přetečení/podtečení pro verze Solidity **<0.8.0**. V Solidity ≥0.8.0 aritmetické operace automaticky
+ vracejí při přetečení/podtečení, takže SafeMath je zbytečná. Tento kontrakt používá SafeMath pro zpětnou kompatibilitu se
+ staršími verzemi kompilátoru.
+
+
+
+Tento komentář vysvětluje účel kontraktu.
+
+```solidity
+/**
+ * @dev Implementace rozhraní {IERC20}.
+ *
+ * Tato implementace je agnostická vůči způsobu vytváření tokenů. To znamená,
+ * že mechanismus dodávání musí být přidán v odvozeném kontraktu pomocí {_mint}.
+ * Obecný mechanismus viz {ERC20PresetMinterPauser}.
+ *
+ * TIP: Podrobný popis naleznete v našem průvodci
+ * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[Jak
+ * implementovat mechanismy dodávání].
+ *
+ * Dodržovali jsme obecné pokyny OpenZeppelin: funkce se při selhání vracejí, místo aby
+ * vracely `false`. Toto chování je nicméně konvenční
+ * a není v rozporu s očekáváními aplikací ERC20.
+ *
+ * Navíc se při volání {transferFrom} emituje událost {Approval}.
+ * To umožňuje aplikacím rekonstruovat povolení pro všechny účty jen
+ * nasloucháním zmíněných událostí. Jiné implementace EIP nemusí tyto události
+ * emitovat, protože to není vyžadováno specifikací.
+ *
+ * Nakonec byly přidány nestandardní funkce {decreaseAllowance} a {increaseAllowance},
+ * aby se zmírnily známé problémy kolem nastavování
+ * povolení. Viz {IERC20-approve}.
+ */
+
+```
+
+### Definice kontraktu {#contract-definition}
+
+```solidity
+contract ERC20 is Context, IERC20 {
+```
+
+Tento řádek specifikuje dědičnost, v tomto případě z `IERC20` z výše uvedeného a `Context`, pro OpenGSN.
+
+
+
+```solidity
+
+ using SafeMath for uint256;
+
+```
+
+Tento řádek připojuje knihovnu `SafeMath` k typu `uint256`. Tuto knihovnu najdete
+[zde](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/math/SafeMath.sol).
+
+### Definice proměnných {#variable-definitions}
+
+Tyto definice specifikují stavové proměnné kontraktu. Tyto proměnné jsou deklarovány jako soukromé (`private`), ale
+to pouze znamená, že je nemohou číst jiné kontrakty na blockchainu. _Na blockchainu neexistují žádná
+tajemství_, software na každém uzlu má stav každého kontraktu
+v každém bloku. Podle konvence se stavové proměnné pojmenovávají `_`.
+
+První dvě proměnné jsou [mapování](https://www.tutorialspoint.com/solidity/solidity_mappings.htm),
+což znamená, že se chovají zhruba stejně jako [asociativní pole](https://wikipedia.org/wiki/Associative_array),
+s výjimkou toho, že klíče jsou číselné hodnoty. Úložiště je přiděleno pouze pro položky, které mají hodnoty odlišné
+od výchozí (nula).
+
+```solidity
+ mapping (address => uint256) private _balances;
+```
+
+První mapování, `_balances`, jsou adresy a jejich příslušné zůstatky tohoto tokenu. Pro přístup
+k zůstatku použijte tuto syntaxi: `_balances[]`.
+
+
+
+```solidity
+ mapping (address => mapping (address => uint256)) private _allowances;
+```
+
+Tato proměnná, `_allowances`, ukládá povolení vysvětlená dříve. První index je vlastníkem
+tokenů a druhý je kontrakt s povolením. Pro přístup k částce, kterou může adresa A
+utratit z účtu adresy B, použijte `_allowances[B][A]`.
+
+
+
+```solidity
+ uint256 private _totalSupply;
+```
+
+Jak název napovídá, tato proměnná sleduje celkovou zásobu tokenů.
+
+
+
+```solidity
+ string private _name;
+ string private _symbol;
+ uint8 private _decimals;
+```
+
+Tyto tři proměnné se používají ke zlepšení čitelnosti. První dvě jsou samovysvětlující, ale `_decimals`
+není.
+
+Na jedné straně Ethereum nemá proměnné s plovoucí desetinnou čárkou nebo zlomkové proměnné. Na druhé straně,
+lidé rádi dělí tokeny. Jedním z důvodů, proč se lidé usadili na zlatě jako měně, bylo to, že
+bylo těžké vrátit drobné, když si někdo chtěl koupit hodnotu kachny v kravě.
+
+Řešením je sledovat celá čísla, ale počítat místo skutečného tokenu zlomkový token, který je
+téměř bezcenný. V případě etheru se zlomkový token nazývá wei a 10^18 wei se rovná jednomu
+ETH. V době psaní tohoto článku je 10 000 000 000 000 wei přibližně jeden americký nebo eurový cent.
+
+Aplikace potřebují vědět, jak zobrazit zůstatek tokenu. Pokud má uživatel 3 141 000 000 000 000 000 wei, je to
+3,14 ETH? 31,41 ETH? 3 141 ETH? V případě etheru je definováno 10^18 wei na ETH, ale pro váš
+token můžete zvolit jinou hodnotu. Pokud dělení tokenu nemá smysl, můžete použít
+hodnotu `_decimals` nula. Chcete-li použít stejný standard jako ETH, použijte hodnotu **18**.
+
+### Konstruktor {#the-constructor}
+
+```solidity
+ /**
+ * @dev Nastaví hodnoty pro {name} a {symbol}, inicializuje {decimals} s
+ * výchozí hodnotou 18.
+ *
+ * Chcete-li vybrat jinou hodnotu pro {decimals}, použijte {_setupDecimals}.
+ *
+ * Všechny tři z těchto hodnot jsou neměnné: lze je nastavit pouze jednou během
+ * konstrukce.
+ */
+ constructor (string memory name_, string memory symbol_) public {
+ // V Solidity ≥0.7.0, 'public' je implicitní a může být vynechán.
+
+ _name = name_;
+ _symbol = symbol_;
+ _decimals = 18;
+ }
+```
+
+Konstruktor se volá při prvním vytvoření kontraktu. Podle konvence jsou parametry funkce pojmenovány `_`.
+
+### Funkce uživatelského rozhraní {#user-interface-functions}
+
+```solidity
+ /**
+ * @dev Vrací název tokenu.
+ */
+ function name() public view returns (string memory) {
+ return _name;
+ }
+
+ /**
+ * @dev Vrací symbol tokenu, obvykle kratší verzi
+ * názvu.
+ */
+ function symbol() public view returns (string memory) {
+ return _symbol;
+ }
+
+ /**
+ * @dev Vrací počet desetinných míst použitých k získání jeho uživatelské reprezentace.
+ * Například, pokud se `decimals` rovná `2`, měl by být zůstatek `505` tokenů
+ * zobrazen uživateli jako `5,05` (`505 / 10 ** 2`).
+ *
+ * Tokeny obvykle volí hodnotu 18, napodobující vztah mezi
+ * etherem a wei. Toto je hodnota, kterou {ERC20} používá, pokud není
+ * volána {_setupDecimals}.
+ *
+ * POZNÁMKA: Tato informace se používá pouze pro účely _zobrazení_: v
+ * žádném případě neovlivňuje žádnou aritmetiku kontraktu, včetně
+ * {IERC20-balanceOf} a {IERC20-transfer}.
+ */
+ function decimals() public view returns (uint8) {
+ return _decimals;
+ }
+```
+
+Tyto funkce, `name`, `symbol` a `decimals`, pomáhají uživatelským rozhraním poznat váš kontrakt, aby ho mohly správně zobrazit.
+
+Návratový typ je `string memory`, což znamená návrat řetězce, který je uložen v paměti. Proměnné, jako jsou
+řetězce, mohou být uloženy na třech místech:
+
+| | Životnost | Přístup ke kontraktu | Náklady na palivo |
+| -------- | ---------------- | -------------------- | ----------------------------------------------------------------- |
+| Paměť | Volání funkce | Čtení/zápis | Desítky nebo stovky (vyšší pro vyšší umístění) |
+| Calldata | Volání funkce | Pouze pro čtení | Nelze použít jako návratový typ, pouze jako typ parametru funkce |
+| Úložiště | Dokud se nezmění | Čtení/zápis | Vysoké (800 pro čtení, 20k pro zápis) |
+
+V tomto případě je `memory` nejlepší volbou.
+
+### Čtení informací o tokenu {#read-token-information}
+
+Jedná se o funkce, které poskytují informace o tokenu, buď o celkové zásobě, nebo o
+zůstatku na účtu.
+
+```solidity
+ /**
+ * @dev Viz {IERC20-totalSupply}.
+ */
+ function totalSupply() public view override returns (uint256) {
+ return _totalSupply;
+ }
+```
+
+Funkce `totalSupply` vrací celkovou zásobu tokenů.
+
+
+
+```solidity
+ /**
+ * @dev Viz {IERC20-balanceOf}.
+ */
+ function balanceOf(address account) public view override returns (uint256) {
+ return _balances[account];
+ }
+```
+
+Přečtěte si zůstatek na účtu. Všimněte si, že kdokoli může získat zůstatek na účtu kohokoli
+jiného. Nemá smysl se snažit tuto informaci skrývat, protože je stejně dostupná na každém
+uzlu. _Na blockchainu neexistují žádná tajemství._
+
+### Převod tokenů {#transfer-tokens}
+
+```solidity
+ /**
+ * @dev Viz {IERC20-transfer}.
+ *
+ * Požadavky:
+ *
+ * - `recipient` nemůže být nulová adresa.
+ * - volající musí mít zůstatek alespoň `amount`.
+ */
+ function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
+```
+
+Funkce `transfer` se volá k převodu tokenů z účtu odesílatele na jiný. Všimněte si,
+že i když vrací booleovskou hodnotu, tato hodnota je vždy **true**. Pokud se převod
+nepodaří, kontrakt vrátí volání zpět.
+
+
+
+```solidity
+ _transfer(_msgSender(), recipient, amount);
+ return true;
+ }
+```
+
+Funkce `_transfer` dělá skutečnou práci. Jedná se o soukromou funkci, kterou mohou volat pouze
+jiné funkce kontraktu. Podle konvence jsou soukromé funkce pojmenovány `_`, stejně jako stavové
+proměnné.
+
+Normálně v Solidity používáme `msg.sender` pro odesílatele zprávy. To však narušuje
+[OpenGSN](http://opengsn.org/). Chceme-li s naším tokenem povolit transakce bez etheru, musíme
+použít `_msgSender()`. Pro běžné transakce vrací `msg.sender`, ale pro transakce bez etheru
+vrací původního podepisujícího a ne kontrakt, který zprávu předal.
+
+### Funkce povolení {#allowance-functions}
+
+Jedná se o funkce, které implementují funkcionalitu povolení: `allowance`, `approve`, `transferFrom`
+a `_approve`. Kromě toho implementace OpenZeppelin jde nad rámec základního standardu a obsahuje některé funkce, které zlepšují
+bezpečnost: `increaseAllowance` a `decreaseAllowance`.
+
+#### Funkce povolení {#allowance}
+
+```solidity
+ /**
+ * @dev Viz {IERC20-allowance}.
+ */
+ function allowance(address owner, address spender) public view virtual override returns (uint256) {
+ return _allowances[owner][spender];
+ }
+```
+
+Funkce `allowance` umožňuje každému zkontrolovat jakékoli povolení.
+
+#### Funkce schválení {#approve}
+
+```solidity
+ /**
+ * @dev Viz {IERC20-approve}.
+ *
+ * Požadavky:
+ *
+ * - `spender` nemůže být nulová adresa.
+ */
+ function approve(address spender, uint256 amount) public virtual override returns (bool) {
+```
+
+Tato funkce se volá pro vytvoření povolení. Je podobná výše uvedené funkci `transfer`:
+
+- Funkce pouze volá interní funkci (v tomto případě `_approve`), která provádí skutečnou práci.
+- Funkce buď vrátí `true` (pokud je úspěšná), nebo se vrátí (pokud ne).
+
+
+
+```solidity
+ _approve(_msgSender(), spender, amount);
+ return true;
+ }
+```
+
+Používáme interní funkce, abychom minimalizovali počet míst, kde dochází ke změnám stavu. _Každá_ funkce, která mění
+stav, je potenciálním bezpečnostním rizikem, které je třeba zkontrolovat z hlediska bezpečnosti. Tímto způsobem máme menší šanci, že se spleteme.
+
+#### Funkce transferFrom {#transferFrom}
+
+Toto je funkce, kterou volá utrácející, aby utratil povolenou částku. To vyžaduje dvě operace: převést utracenou částku
+a snížit povolenou částku o tuto částku.
+
+```solidity
+ /**
+ * @dev Viz {IERC20-transferFrom}.
+ *
+ * Vyvolá událost {Approval} udávající aktualizované povolení. To není
+ * vyžadováno EIP. Viz poznámka na začátku {ERC20}.
+ *
+ * Požadavky:
+ *
+ * - `sender` a `recipient` nemohou být nulová adresa.
+ * - `sender` musí mít zůstatek alespoň `amount`.
+ * - volající musí mít povolení pro tokeny ``sender`` alespoň
+ * `amount`.
+ */
+ function transferFrom(address sender, address recipient, uint256 amount) public virtual
+ override returns (bool) {
+ _transfer(sender, recipient, amount);
+```
+
+
+
+Volání funkce `a.sub(b, "zpráva")` provádí dvě věci. Nejprve vypočítá `a-b`, což je nové povolení.
+Zadruhé zkontroluje, zda tento výsledek není záporný. Pokud je záporný, volání se vrátí s poskytnutou zprávou. Všimněte si, že když se volání vrátí, veškeré předchozí zpracování během tohoto volání se ignoruje, takže nemusíme
+vracet `_transfer`.
+
+```solidity
+ _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount,
+ "ERC20: transfer amount exceeds allowance"));
+ return true;
+ }
+```
+
+#### Bezpečnostní doplňky OpenZeppelin {#openzeppelin-safety-additions}
+
+Je nebezpečné nastavit nenulové povolení na jinou nenulovou hodnotu,
+protože ovládáte pouze pořadí svých vlastních transakcí, nikoli transakcí kohokoli jiného. Představte si, že
+máte dva uživatele, Alici, která je naivní, a Billa, který je nečestný. Alice chce od
+Billa nějakou službu, která si myslí, že stojí pět tokenů – takže dává Billovi povolení na pět tokenů.
+
+Pak se něco změní a Billova cena stoupne na deset tokenů. Alice, která stále chce službu,
+pošle transakci, která nastaví Billovo povolení na deset. V okamžiku, kdy Bill uvidí tuto novou transakci
+v poolu transakcí, pošle transakci, která utratí Aliciných pět tokenů a má mnohem
+vyšší cenu paliva, takže bude vytěžena rychleji. Tímto způsobem může Bill nejprve utratit pět tokenů a poté,
+jakmile je vytěženo nové povolení Alice, utratit dalších deset za celkovou cenu patnácti tokenů, což je více, než
+Alice zamýšlela autorizovat. Tato technika se nazývá
+[front-running](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/#front-running)
+
+| Transakce Alice | Nonce Alice | Transakce Billa | Nonce Billa | Billovo povolení | Billův celkový příjem od Alice |
+| ------------------------------------ | ----------- | ------------------------------------------------ | ----------- | ---------------- | ------------------------------ |
+| approve(Bill, 5) | 10 | | | 5 | 0 |
+| | | transferFrom(Alice, Bill, 5) | 10,123 | 0 | 5 |
+| approve(Bill, 10) | 11 | | | 10 | 5 |
+| | | transferFrom(Alice, Bill, 10) | 10,124 | 0 | 15 |
+
+Abyste se tomuto problému vyhnuli, tyto dvě funkce (`increaseAllowance` a `decreaseAllowance`) vám umožňují
+upravit povolenou částku o určitou částku. Takže pokud Bill už utratil pět tokenů, bude moci utratit
+jen dalších pět. V závislosti na načasování existují dva způsoby, jak to může fungovat, oba z
+nichž končí tím, že Bill dostane pouze deset tokenů:
+
+A:
+
+| Transakce Alice | Nonce Alice | Transakce Billa | Nonce Billa | Billovo povolení | Billův celkový příjem od Alice |
+| --------------------------------------------- | ----------: | ----------------------------------------------- | ----------: | ---------------: | ------------------------------ |
+| approve(Bill, 5) | 10 | | | 5 | 0 |
+| | | transferFrom(Alice, Bill, 5) | 10,123 | 0 | 5 |
+| increaseAllowance(Bill, 5) | 11 | | | 0+5 = 5 | 5 |
+| | | transferFrom(Alice, Bill, 5) | 10,124 | 0 | 10 |
+
+B:
+
+| Transakce Alice | Nonce Alice | Transakce Billa | Nonce Billa | Billovo povolení | Billův celkový příjem od Alice |
+| --------------------------------------------- | ----------: | ------------------------------------------------ | ----------: | ---------------: | -----------------------------: |
+| approve(Bill, 5) | 10 | | | 5 | 0 |
+| increaseAllowance(Bill, 5) | 11 | | | 5+5 = 10 | 0 |
+| | | transferFrom(Alice, Bill, 10) | 10,124 | 0 | 10 |
+
+```solidity
+ /**
+ * @dev Atomicky zvyšuje povolení udělené `spenderu` volajícím.
+ *
+ * Toto je alternativa k {approve}, kterou lze použít jako zmírnění pro
+ * problémy popsané v {IERC20-approve}.
+ *
+ * Vyvolá událost {Approval} udávající aktualizované povolení.
+ *
+ * Požadavky:
+ *
+ * - `spender` nemůže být nulová adresa.
+ */
+ function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
+ _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));
+ return true;
+ }
+```
+
+Funkce `a.add(b)` je bezpečné sčítání. V nepravděpodobném případě, že `a`+`b`>=`2^256`, se neobtočí
+jako normální sčítání.
+
+```solidity
+
+ /**
+ * @dev Atomicky snižuje povolení udělené `spenderu` volajícím.
+ *
+ * Toto je alternativa k {approve}, kterou lze použít jako zmírnění pro
+ * problémy popsané v {IERC20-approve}.
+ *
+ * Vyvolá událost {Approval} udávající aktualizované povolení.
+ *
+ * Požadavky:
+ *
+ * - `spender` nemůže být nulová adresa.
+ * - `spender` musí mít povolení pro volajícího alespoň
+ * `subtractedValue`.
+ */
+ function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
+ _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue,
+ "ERC20: decreased allowance below zero"));
+ return true;
+ }
+```
+
+### Funkce, které upravují informace o tokenu {#functions-that-modify-token-information}
+
+Toto jsou čtyři funkce, které provádějí skutečnou práci: `_transfer`, `_mint`, `_burn` a `_approve`.
+
+#### Funkce _transfer {#_transfer}
+
+```solidity
+ /**
+ * @dev Přesune tokeny v množství `amount` od `odesílatele` k `příjemci`.
+ *
+ * Tato interní funkce je ekvivalentní {transfer} a může být použita
+ * například k implementaci automatických poplatků za tokeny, mechanismů slashing atd.
+ *
+ * Vyvolá událost {Transfer}.
+ *
+ * Požadavky:
+ *
+ * - `sender` nemůže být nulová adresa.
+ * - `recipient` nemůže být nulová adresa.
+ * - `sender` musí mít zůstatek alespoň `amount`.
+ */
+ function _transfer(address sender, address recipient, uint256 amount) internal virtual {
+```
+
+Tato funkce, `_transfer`, převádí tokeny z jednoho účtu na druhý. Volá se jak
+`transfer` (pro převody z vlastního účtu odesílatele), tak `transferFrom` (pro použití povolení
+k převodu z cizího účtu).
+
+
+
+```solidity
+ require(sender != address(0), "ERC20: transfer from the zero address");
+ require(recipient != address(0), "ERC20: transfer to the zero address");
+```
+
+Nikdo ve skutečnosti nevlastní adresu nula v Ethereu (to znamená, že nikdo nezná soukromý klíč, jehož odpovídající veřejný klíč
+je transformován na nulovou adresu). Když lidé používají tuto adresu, obvykle se jedná o softwarovou chybu – takže selžeme,
+pokud je jako odesílatel nebo příjemce použita nulová adresa.
+
+
+
+```solidity
+ _beforeTokenTransfer(sender, recipient, amount);
+
+```
+
+Existují dva způsoby, jak použít tento kontrakt:
+
+1. Použijte jej jako šablonu pro svůj vlastní kód
+2. [Dědit z něj](https://www.bitdegree.org/learn/solidity-inheritance) a přepsat pouze ty funkce, které potřebujete upravit
+
+Druhá metoda je mnohem lepší, protože kód OpenZeppelin ERC-20 již byl auditován a prokázal se jako bezpečný. Když používáte dědičnost,
+je jasné, jaké funkce upravujete, a aby lidé důvěřovali vašemu kontraktu, stačí jim auditovat pouze tyto konkrétní funkce.
+
+Často je užitečné provést funkci pokaždé, když tokeny změní majitele. Nicméně `_transfer` je velmi důležitá funkce a je
+možné ji napsat nezabezpečeně (viz níže), takže je nejlepší ji nepřepisovat. Řešením je `_beforeTokenTransfer`, [funkce hook](https://wikipedia.org/wiki/Hooking). Tuto funkci můžete přepsat a bude volána při každém převodu.
+
+
+
+```solidity
+ _balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance");
+ _balances[recipient] = _balances[recipient].add(amount);
+```
+
+Toto jsou řádky, které skutečně provádějí převod. Všimněte si, že mezi nimi **nic** není a že odečítáme
+převedenou částku od odesílatele před jejím přičtením k příjemci. To je důležité, protože kdyby uprostřed bylo
+volání jiného kontraktu, mohlo by být použito k podvádění tohoto kontraktu. Tímto způsobem je převod
+atomický, uprostřed se nemůže nic stát.
+
+
+
+```solidity
+ emit Transfer(sender, recipient, amount);
+ }
+```
+
+Nakonec vyvoláme událost `Transfer`. Události nejsou přístupné chytrým kontraktům, ale kód spuštěný mimo blockchain
+může naslouchat událostem a reagovat na ně. Například peněženka může sledovat, kdy majitel získá více tokenů.
+
+#### Funkce _mint a _burn {#_mint-and-_burn}
+
+Tyto dvě funkce (`_mint` a `_burn`) upravují celkovou zásobu tokenů.
+Jsou interní a v tomto kontraktu je nevolá žádná funkce,
+takže jsou užitečné pouze v případě, že z kontraktu dědíte a přidáte si vlastní
+logiku k rozhodnutí, za jakých podmínek se mají nové tokeny razit nebo stávající
+pálit.
+
+**POZNÁMKA:** Každý token ERC-20 má svou vlastní obchodní logiku, která určuje správu tokenů.
+Například kontrakt s pevnou zásobou může volat `_mint` pouze
+v konstruktoru a nikdy nevolat `_burn`. Kontrakt, který prodává tokeny,
+volá `_mint`, když je zaplaceno, a pravděpodobně v určitém okamžiku volá `_burn`,
+aby se zabránilo nekontrolovatelné inflaci.
+
+```solidity
+ /** @dev Vytvoří `amount` tokenů a přiřadí je `účtu`, čímž se zvýší
+ * celková zásoba.
+ *
+ * Vyvolá událost {Transfer} s `from` nastaveným na nulovou adresu.
+ *
+ * Požadavky:
+ *
+ * - `to` nemůže být nulová adresa.
+ */
+ function _mint(address account, uint256 amount) internal virtual {
+ require(account != address(0), "ERC20: mint to the zero address");
+ _beforeTokenTransfer(address(0), account, amount);
+ _totalSupply = _totalSupply.add(amount);
+ _balances[account] = _balances[account].add(amount);
+ emit Transfer(address(0), account, amount);
+ }
+```
+
+Nezapomeňte aktualizovat `_totalSupply`, když se změní celkový počet tokenů.
+
+
+
+```solidity
+ /**
+ * @dev Zničí `amount` tokenů z `účtu`, čímž se sníží
+ * celková zásoba.
+ *
+ * Vyvolá událost {Transfer} s `to` nastaveným na nulovou adresu.
+ *
+ * Požadavky:
+ *
+ * - `účet` nemůže být nulová adresa.
+ * - `účet` musí mít alespoň `amount` tokenů.
+ */
+ function _burn(address account, uint256 amount) internal virtual {
+ require(account != address(0), "ERC20: burn from the zero address");
+
+ _beforeTokenTransfer(account, address(0), amount);
+
+ _balances[account] = _balances[account].sub(amount, "ERC20: burn amount exceeds balance");
+ _totalSupply = _totalSupply.sub(amount);
+ emit Transfer(account, address(0), amount);
+ }
+```
+
+Funkce `_burn` je téměř identická s `_mint`, jen jde opačným směrem.
+
+#### Funkce _approve {#_approve}
+
+Toto je funkce, která skutečně specifikuje povolení. Všimněte si, že umožňuje vlastníkovi specifikovat
+povolení, které je vyšší než aktuální zůstatek vlastníka. To je v pořádku, protože zůstatek se
+kontroluje v okamžiku převodu, kdy se může lišit od zůstatku v době vytvoření povolení
+.
+
+```solidity
+ /**
+ * @dev Nastaví `amount` jako povolení `spenderu` pro tokeny `vlastníka`.
+ *
+ * Tato interní funkce je ekvivalentní `approve` a může být použita
+ * například k nastavení automatických povolení pro určité subsystémy atd.
+ *
+ * Vyvolá událost {Approval}.
+ *
+ * Požadavky:
+ *
+ * - `owner` nemůže být nulová adresa.
+ * - `spender` nemůže být nulová adresa.
+ */
+ function _approve(address owner, address spender, uint256 amount) internal virtual {
+ require(owner != address(0), "ERC20: approve from the zero address");
+ require(spender != address(0), "ERC20: approve to the zero address");
+
+ _allowances[owner][spender] = amount;
+```
+
+
+
+Vyvolat událost `Approval`. V závislosti na tom, jak je aplikace napsána, může být kontraktu utrácejícího o
+schválení sděleno buď vlastníkem, nebo serverem, který naslouchá těmto událostem.
+
+```solidity
+ emit Approval(owner, spender, amount);
+ }
+
+```
+
+### Upravit proměnnou Decimals {#modify-the-decimals-variable}
+
+```solidity
+
+
+ /**
+ * @dev Nastaví {decimals} na jinou hodnotu než výchozí 18.
+ *
+ * VAROVÁNÍ: Tuto funkci byste měli volat pouze z konstruktoru. Většina
+ * aplikací, které interagují s tokenovými kontrakty, neočekává,
+ * že se {decimals} někdy změní, a mohou fungovat nesprávně, pokud ano.
+ */
+ function _setupDecimals(uint8 decimals_) internal {
+ _decimals = decimals_;
+ }
+```
+
+Tato funkce upravuje proměnnou `_decimals`, která se používá k tomu, aby uživatelským rozhraním sdělila, jak interpretovat částku.
+Měli byste ji volat z konstruktoru. Bylo by nečestné volat ji v jakémkoli následujícím bodě a aplikace
+nejsou navrženy tak, aby to zvládly.
+
+### Háčky {#hooks}
+
+```solidity
+
+ /**
+ * @dev Záchytný bod (hook), který se volá před jakýmkoli převodem tokenů. To zahrnuje
+ * ražbu a pálení.
+ *
+ * Podmínky volání:
+ *
+ * – když `from` a `to` jsou obě nenulové, bude převeden `amount` tokenů z adresy ``from``
+ * na adresu `to`.
+ * – když je `from` nulové, bude pro `to` vyraženo `amount` tokenů.
+ * – když je `to` nulové, `amount` tokenů z adresy ``from`` bude spáleno.
+ * – `from` a `to` nejsou nikdy obě nulové.
+ *
+ * Více informací o záchytných bodech (hooks) najdete v xref:ROOT:extending-contracts.adoc#using-hooks[Používání záchytných bodů].
+ */
+ function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual { }
+}
+```
+
+Toto je funkce háku, která se má volat během převodů. Zde je prázdná, ale pokud potřebujete,
+aby něco dělala, stačí ji přepsat.
+
+## Závěr {#conclusion}
+
+Pro přehled, zde jsou některé z nejdůležitějších myšlenek v tomto kontraktu (podle mého názoru se váš může lišit):
+
+- _Na blockchainu neexistují žádná tajemství_. Jakékoli informace, ke kterým má chytrý kontrakt přístup,
+ jsou dostupné celému světu.
+- Můžete ovládat pořadí svých vlastních transakcí, ale ne to, kdy se uskuteční transakce
+ jiných lidí. To je důvod, proč může být změna povolení nebezpečná, protože umožňuje
+ utrácejícímu utratit součet obou povolení.
+- Hodnoty typu `uint256` se obtáčejí. Jinými slovy, _0-1=2^256-1_. Pokud to není požadované
+ chování, musíte to zkontrolovat (nebo použít knihovnu SafeMath, která to udělá za vás). Všimněte si, že se to změnilo v
+ [Solidity 0.8.0](https://docs.soliditylang.org/en/breaking/080-breaking-changes.html).
+- Provádějte všechny změny stavu určitého typu na určitém místě, protože to usnadňuje auditování.
+ To je důvod, proč máme například `_approve`, které je voláno `approve`, `transferFrom`,
+ `increaseAllowance` a `decreaseAllowance`
+- Změny stavu by měly být atomické, bez jakékoli jiné akce uprostřed (jak můžete vidět
+ v `_transfer`). Je to proto, že během změny stavu máte nekonzistentní stav. Například
+ mezi dobou, kdy odečtete ze zůstatku odesílatele, a dobou, kdy přičtete k zůstatku
+ příjemce, existuje méně tokenů, než by mělo být. To by mohlo být potenciálně zneužito, pokud
+ mezi nimi probíhají operace, zejména volání jiného kontraktu.
+
+Nyní, když jste viděli, jak je napsán kontrakt OpenZeppelin ERC-20 a zejména jak je
+zabezpečen, jděte a pište své vlastní bezpečné kontrakty a aplikace.
+
+[Více z mé práce najdete zde](https://cryptodocguy.pro/).
diff --git a/public/content/translations/cs/developers/tutorials/erc20-with-safety-rails/index.md b/public/content/translations/cs/developers/tutorials/erc20-with-safety-rails/index.md
new file mode 100644
index 00000000000..409d83722c5
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/erc20-with-safety-rails/index.md
@@ -0,0 +1,217 @@
+---
+title: ERC-20 s bezpečnostními pojistkami
+description: Jak pomoci lidem, aby se vyhnuli zbytečným chybám
+author: Ori Pomerantz
+lang: cs
+tags: [ "erc-20" ]
+skill: beginner
+published: 2022-08-15
+---
+
+## Úvod {#introduction}
+
+Jednou ze skvělých věcí na Ethereu je to, že neexistuje žádná centrální autorita, která by mohla upravit nebo zvrátit vaše transakce. Jedním z velkých problémů Etherea je naopak to, že neexistuje žádná centrální autorita, která by měla pravomoc napravovat chyby uživatelů nebo nelegitimní transakce. V tomto článku se dozvíte o některých běžných chybách, kterých se uživatelé dopouštějí u [ERC-20](/developers/docs/standards/tokens/erc-20/) tokenů, a také o tom, jak vytvářet ERC-20 kontrakty, které uživatelům pomáhají se těmto chybám vyhnout nebo které dávají centrální autoritě určitou pravomoc (například zmrazit účty).
+
+Upozorňujeme, že ačkoli budeme používat [kontrakt tokenu ERC-20 od OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20), tento článek jej podrobně nevysvětluje. Tyto informace naleznete [zde](/developers/tutorials/erc20-annotated-code).
+
+Pokud chcete vidět kompletní zdrojový kód:
+
+1. Otevřete [Remix IDE](https://remix.ethereum.org/).
+2. Klikněte na ikonu pro klonování z GitHubu ().
+3. Naklonujte repozitář z GitHubu: `https://github.com/qbzzt/20220815-erc20-safety-rails`.
+4. Otevřete **contracts > erc20-safety-rails.sol**.
+
+## Vytvoření ERC-20 kontraktu {#creating-an-erc-20-contract}
+
+Než budeme moci přidat funkcionalitu bezpečnostních pojistek, potřebujeme ERC-20 kontrakt. V tomto článku použijeme [průvodce kontrakty od OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/wizard). Otevřete jej v jiném prohlížeči a postupujte podle těchto pokynů:
+
+1. Vyberte **ERC20**.
+
+2. Zadejte tato nastavení:
+
+ | Parametr | Hodnota |
+ | ---------------- | ---------------- |
+ | Název | SafetyRailsToken |
+ | Symbol | SAFE |
+ | Premint | 1000 |
+ | Funkce | Žádná |
+ | Řízení přístupu | Ownable |
+ | Upgradovatelnost | Žádná |
+
+3. Přejděte nahoru a klikněte na **Otevřít v Remixu** (pro Remix) nebo **Stáhnout** pro použití jiného prostředí. Budu předpokládat, že používáte Remix. Pokud používáte něco jiného, proveďte příslušné změny.
+
+4. Nyní máme plně funkční ERC-20 kontrakt. Importovaný kód uvidíte po rozbalení `.deps` > `npm`.
+
+5. Zkompilujte, nasaďte a vyzkoušejte si kontrakt, abyste viděli, že funguje jako ERC-20 kontrakt. Pokud se potřebujete naučit používat Remix, [použijte tento tutoriál](https://remix.ethereum.org/?#activate=udapp,solidity,LearnEth).
+
+## Běžné chyby {#common-mistakes}
+
+### Chyby {#the-mistakes}
+
+Uživatelé někdy posílají tokeny na špatnou adresu. Ačkoli jim nevidíme do hlavy, abychom věděli, co měli v úmyslu, existují dva typy chyb, které se stávají často a dají se snadno odhalit:
+
+1. Odeslání tokenů na vlastní adresu kontraktu. Například u [tokenu OP od Optimism](https://optimism.mirror.xyz/qvd0WfuLKnePm1Gxb9dpGchPf5uDz5NSMEFdgirDS4c) se za necelé dva měsíce podařilo nashromáždit [přes 120 000](https://optimism.blockscout.com/address/0x4200000000000000000000000000000000000042) tokenů OP. To představuje značné jmění, o které lidé pravděpodobně jednoduše přišli.
+
+2. Odeslání tokenů na prázdnou adresu, která neodpovídá ani [externě vlastněnému účtu (EOA)](/developers/docs/accounts/#externally-owned-accounts-and-key-pairs), ani [chytrému kontraktu](/developers/docs/smart-contracts). Sice nemám statistiky o tom, jak často se to stává, ale [jeden incident mohl stát 20 000 000 tokenů](https://gov.optimism.io/t/message-to-optimism-community-from-wintermute/2595).
+
+### Zabránění převodům {#preventing-transfers}
+
+Kontrakt ERC-20 od OpenZeppelin obsahuje [„hook“ `_beforeTokenTransfer`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol#L364-L368), který je volán před převodem tokenu. Ve výchozím stavu tento hook nic nedělá, ale můžeme na něj navázat vlastní funkcionalitu, například kontroly, které v případě problému transakci vrátí.
+
+Chcete-li tento hook použít, přidejte za konstruktor tuto funkci:
+
+```solidity
+ function _beforeTokenTransfer(address from, address to, uint256 amount)
+ internal virtual
+ override(ERC20)
+ {
+ super._beforeTokenTransfer(from, to, amount);
+ }
+```
+
+Některé části této funkce pro vás mohou být nové, pokud nejste se Solidity příliš obeznámeni:
+
+```solidity
+ internal virtual
+```
+
+Klíčové slovo `virtual` znamená, že stejně jako jsme zdědili funkcionalitu z `ERC20` a přepsali tuto funkci, mohou i další kontrakty dědit z našeho kontraktu a tuto funkci přepsat.
+
+```solidity
+ override(ERC20)
+```
+
+Musíme explicitně uvést, že [přepisujeme](https://docs.soliditylang.org/en/v0.8.15/contracts.html#function-overriding) definici `_beforeTokenTransfer` z tokenu ERC20. Z hlediska bezpečnosti jsou explicitní definice obecně mnohem lepší než implicitní – nemůžete zapomenout, že jste něco udělali, když to máte přímo před očima. To je také důvod, proč musíme určit, kterou nadtřídu `_beforeTokenTransfer` přepisujeme.
+
+```solidity
+ super._beforeTokenTransfer(from, to, amount);
+```
+
+Tento řádek volá funkci `_beforeTokenTransfer` kontraktu nebo kontraktů, z nichž jsme dědili a které ji mají. V tomto případě je to pouze `ERC20`, kontrakt `Ownable` tento hook nemá. Přestože `ERC20._beforeTokenTransfer` v současné době nic nedělá, voláme ji pro případ, že by v budoucnu byla přidána nějaká funkcionalita (a my se pak rozhodli kontrakt znovu nasadit, protože kontrakty se po nasazení nemění).
+
+### Kódování požadavků {#coding-the-requirements}
+
+Do funkce chceme přidat tyto požadavky:
+
+- Adresa `to` se nesmí rovnat `address(this)`, tedy adrese samotného kontraktu ERC-20.
+- Adresa `to` nesmí být prázdná, musí to být buď:
+ - Externě vlastněný účet (EOA). Nemůžeme přímo zkontrolovat, zda je adresa EOA, ale můžeme zkontrolovat zůstatek ETH na adrese. EOA mají téměř vždy nějaký zůstatek, i když se již nepoužívají – je těžké je vyčistit do posledního wei.
+ - Chytrý kontrakt. Otestovat, zda je adresa chytrý kontrakt, je trochu těžší. Existuje operační kód, který kontroluje délku externího kódu, nazývaný [`EXTCODESIZE`](https://www.evm.codes/#3b), ale není přímo dostupný v Solidity. Musíme pro to použít [Yul](https://docs.soliditylang.org/en/v0.8.15/yul.html), což je assemblér pro EVM. Existují i další hodnoty, které bychom mohli použít ze Solidity ([`.code` a `.codehash`](https://docs.soliditylang.org/en/v0.8.15/units-and-global-variables.html#members-of-address-types)), ale stojí více.
+
+Projděme si nový kód řádek po řádku:
+
+```solidity
+ require(to != address(this), "Tokeny nelze posílat na adresu kontraktu");
+```
+
+Toto je první požadavek, zkontrolujte, že `to` a `this(address)` není totéž.
+
+```solidity
+ bool isToContract;
+ assembly {
+ isToContract := gt(extcodesize(to), 0)
+ }
+```
+
+Takto zkontrolujeme, zda je adresa kontrakt. Z Yulu nemůžeme přímo získat výstup, takže místo toho definujeme proměnnou, která bude obsahovat výsledek (v tomto případě `isToContract`). Yul funguje tak, že každý operační kód je považován za funkci. Nejprve tedy zavoláme [`EXTCODESIZE`](https://www.evm.codes/#3b), abychom získali velikost kontraktu, a poté použijeme [`GT`](https://www.evm.codes/#11), abychom zkontrolovali, že není nulová (pracujeme s neznaménkovými celými čísly, takže samozřejmě nemůže být záporná). Poté zapíšeme výsledek do `isToContract`.
+
+```solidity
+ require(to.balance != 0 || isToContract, "Tokeny nelze posílat na prázdnou adresu");
+```
+
+A nakonec tu máme samotnou kontrolu prázdných adres.
+
+## Administrativní přístup {#admin-access}
+
+Někdy je užitečné mít administrátora, který může napravovat chyby. Aby se snížilo riziko zneužití, může být tento administrátor [multisig](https://blog.logrocket.com/security-choices-multi-signature-wallets/), takže na akci se musí shodnout více lidí. V tomto článku budeme mít dvě administrativní funkce:
+
+1. Zmrazování a rozmrazování účtů. To může být užitečné například v případě, že by účet mohl být kompromitován.
+2. Vyčištění prostředků.
+
+ Někdy podvodníci posílají podvodné tokeny do kontraktu skutečného tokenu, aby získali legitimitu. Příklad naleznete [zde](https://optimism.blockscout.com/token/0x2348B1a1228DDCd2dB668c3d30207c3E1852fBbe?tab=holders). Legitimní kontrakt ERC-20 je [0x4200....0042](https://optimism.blockscout.com/token/0x4200000000000000000000000000000000000042). Podvod, který se za něj vydává, je [0x234....bbe](https://optimism.blockscout.com/token/0x2348B1a1228DDCd2dB668c3d30207c3E1852fBbe).
+
+ Je také možné, že lidé omylem pošlou legitimní ERC-20 tokeny na náš kontrakt, což je další důvod, proč je dobré mít způsob, jak je dostat ven.
+
+OpenZeppelin poskytuje dva mechanismy pro umožnění administrativního přístupu:
+
+- [`Ownable`](https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable) kontrakty mají jediného vlastníka. Funkce, které mají [modifikátor](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm) `onlyOwner`, může volat pouze tento vlastník. Vlastníci mohou převést vlastnictví na někoho jiného nebo se ho úplně vzdát. Práva všech ostatních účtů jsou obvykle totožná.
+- [`AccessControl`](https://docs.openzeppelin.com/contracts/5.x/access-control#role-based-access-control) kontrakty mají [řízení přístupu na základě rolí (RBAC)](https://en.wikipedia.org/wiki/Role-based_access_control).
+
+Pro zjednodušení v tomto článku používáme `Ownable`.
+
+### Zmrazování a rozmrazování účtů {#freezing-and-thawing-contracts}
+
+Zmrazování a rozmrazování účtů vyžaduje několik změn:
+
+- [Mapování](https://www.tutorialspoint.com/solidity/solidity_mappings.htm) z adres na [booleovské hodnoty](https://en.wikipedia.org/wiki/Boolean_data_type) pro sledování, které adresy jsou zmrazené. Všechny hodnoty jsou na začátku nulové, což se u booleovských hodnot interpretuje jako false. To je to, co chceme, protože ve výchozím nastavení nejsou účty zmrazeny.
+
+ ```solidity
+ mapping(address => bool) public frozenAccounts;
+ ```
+
+- [Události](https://www.tutorialspoint.com/solidity/solidity_events.htm), které informují všechny zúčastněné o zmrazení nebo rozmrazení účtu. Technicky vzato nejsou události pro tyto akce vyžadovány, ale pomáhá to offchain kódu, aby mohl těmto událostem naslouchat a vědět, co se děje. Považuje se za slušnost, když je chytrý kontrakt emituje, když se stane něco, co by mohlo být pro někoho jiného relevantní.
+
+ Události jsou indexovány, takže bude možné vyhledat všechny případy, kdy byl účet zmrazen nebo rozmrazen.
+
+ ```solidity
+ // Když jsou účty zmrazeny nebo rozmrazeny
+ event AccountFrozen(address indexed _addr);
+ event AccountThawed(address indexed _addr);
+ ```
+
+- Funkce pro zmrazování a rozmrazování účtů. Tyto dvě funkce jsou téměř totožné, takže si projdeme pouze funkci zmrazení.
+
+ ```solidity
+ function freezeAccount(address addr)
+ public
+ onlyOwner
+ ```
+
+ Funkce označené jako [`public`](https://www.tutorialspoint.com/solidity/solidity_contracts.htm) lze volat z jiných chytrých kontraktů nebo přímo transakcí.
+
+ ```solidity
+ {
+ require(!frozenAccounts[addr], "Účet je již zmrazen");
+ frozenAccounts[addr] = true;
+ emit AccountFrozen(addr);
+ } // freezeAccount
+ ```
+
+ Pokud je účet již zmrazen, transakce se vrátí. V opačném případě ho zmrazte a `emit`ujte událost.
+
+- Změňte `_beforeTokenTransfer`, abyste zabránili přesunu prostředků ze zmrazeného účtu. Všimněte si, že prostředky lze stále převádět na zmrazený účet.
+
+ ```solidity
+ require(!frozenAccounts[from], "Účet je zmrazen");
+ ```
+
+### Vyčištění prostředků {#asset-cleanup}
+
+K uvolnění ERC-20 tokenů držených tímto kontraktem musíme zavolat funkci na kontraktu tokenu, ke kterému patří, buď [`transfer`](https://eips.ethereum.org/EIPS/eip-20#transfer) nebo [`approve`](https://eips.ethereum.org/EIPS/eip-20#approve). V tomto případě nemá smysl plýtvat palivem na povolenky, můžeme rovnou provést přímý převod.
+
+```solidity
+ function cleanupERC20(
+ address erc20,
+ address dest
+ )
+ public
+ onlyOwner
+ {
+ IERC20 token = IERC20(erc20);
+```
+
+Toto je syntaxe pro vytvoření objektu pro kontrakt, když obdržíme adresu. Můžeme to udělat, protože máme definici pro ERC-20 tokeny jako součást zdrojového kódu (viz řádek 4) a tento soubor obsahuje [definici pro IERC20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol), což je rozhraní pro kontrakt ERC-20 od OpenZeppelin.
+
+```solidity
+ uint balance = token.balanceOf(address(this));
+ token.transfer(dest, balance);
+ }
+```
+
+Jedná se o funkci vyčištění, takže pravděpodobně nechceme zanechat žádné tokeny. Místo ručního získávání zůstatku od uživatele můžeme tento proces rovnou zautomatizovat.
+
+## Závěr {#conclusion}
+
+Toto není dokonalé řešení – na problém "uživatel udělal chybu" neexistuje dokonalé řešení. Použití těchto typů kontrol však může alespoň některým chybám zabránit. Schopnost zmrazit účty, i když je nebezpečná, může být použita k omezení škod způsobených některými útoky tím, že hackerovi odepře ukradené prostředky.
+
+[Více z mé práce najdete zde](https://cryptodocguy.pro/).
diff --git a/public/content/translations/cs/developers/tutorials/ethereum-for-web2-auth/index.md b/public/content/translations/cs/developers/tutorials/ethereum-for-web2-auth/index.md
new file mode 100644
index 00000000000..5ac4c372ca5
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/ethereum-for-web2-auth/index.md
@@ -0,0 +1,886 @@
+---
+title: Použití Etherea pro web2 autentizaci
+description: Po přečtení tohoto tutoriálu bude vývojář schopen integrovat přihlášení přes Ethereum (web3) s přihlášením SAML, což je standard používaný ve web2 k poskytování jednotného přihlášení a dalších souvisejících služeb. To umožňuje, aby byl přístup ke zdrojům web2 autentizován prostřednictvím podpisů Etherea, s uživatelskými atributy pocházejícími z atestací.
+author: Ori Pomerantz
+tags: [ "web2", "ověření", "eas" ]
+skill: beginner
+lang: cs
+published: 2025-04-30
+---
+
+## Úvod
+
+[SAML](https://www.onelogin.com/learn/saml) je standard používaný na web2, který umožňuje [poskytovateli identity (IdP)](https://en.wikipedia.org/wiki/Identity_provider#SAML_identity_provider) poskytovat informace o uživateli [poskytovatelům služeb (SP)](https://en.wikipedia.org/wiki/Service_provider_\(SAML\)).
+
+V tomto tutoriálu se dozvíte, jak integrovat podpisy Etherea se SAML, abyste uživatelům umožnili používat jejich peněženky Ethereum k vlastní autentizaci u služeb web2, které ještě nativně nepodporují Ethereum.
+
+Upozorňujeme, že tento tutoriál je napsán pro dvě samostatné skupiny čtenářů:
+
+- Lidi z komunity Etherea, kteří Ethereu rozumí a potřebují se naučit SAML
+- Lidi z web2, kteří rozumí SAML a web2 autentizaci a potřebují se naučit o Ethereu
+
+V důsledku toho bude obsahovat spoustu úvodního materiálu, který již znáte. Klidně ho přeskočte.
+
+### SAML pro lidi z komunity Etherea
+
+SAML je centralizovaný protokol. Poskytovatel služeb (SP) přijímá tvrzení (například „toto je můj uživatel John, měl by mít oprávnění provádět A, B a C“) od poskytovatele identity (IdP) pouze pokud s ním má již existující vztah důvěry, nebo s [certifikační autoritou](https://www.ssl.com/article/what-is-a-certificate-authority-ca/), která podepsala certifikát daného IdP.
+
+Například SP může být cestovní kancelář poskytující cestovní služby firmám a IdP může být interní webová stránka firmy. Když si zaměstnanci potřebují rezervovat služební cestu, cestovní kancelář je odešle k autentizaci firmou, než jim skutečně umožní cestu rezervovat.
+
+
+
+Tímto způsobem si tři entity, prohlížeč, SP a IdP, vyjednávají přístup. SP nemusí předem vědět nic o uživateli používajícím prohlížeč, stačí, když důvěřuje IdP.
+
+### Ethereum pro lidi znalé SAML
+
+Ethereum je decentralizovaný systém.
+
+
+
+Uživatelé mají privátní klíč (obvykle uložený v rozšíření prohlížeče). Z privátního klíče můžete odvodit veřejný klíč a z něj 20bajtovou adresu. Když se uživatelé potřebují přihlásit do systému, jsou požádáni o podepsání zprávy s hodnotou nonce (jednorázově použitelná hodnota). Server může ověřit, že podpis byl vytvořen touto adresou.
+
+
+
+Podpis pouze ověřuje adresu Etherea. Chcete-li získat další atributy uživatele, obvykle používáte [atestace](https://attest.org/). Atestace má obvykle tato pole:
+
+- **Atestátor**, adresa, která provedla atestaci
+- **Příjemce**, adresa, které se atestace týká
+- **Data**, atestovaná data, jako je jméno, oprávnění atd.
+- **Schéma**, ID schématu použitého k interpretaci dat.
+
+Vzhledem k decentralizované povaze Etherea může atestace provádět kterýkoli uživatel. Identita atestátora je důležitá pro identifikaci atestací, které považujeme za spolehlivé.
+
+## Nastavení
+
+Prvním krokem je zajistit komunikaci mezi SAML SP a SAML IdP.
+
+1. Stáhněte si software. Vzorový software pro tento článek je [na GitHubu](https://github.com/qbzzt/250420-saml-ethereum). Různé fáze jsou uloženy v různých větvích, pro tuto fázi chcete `saml-only`
+
+ ```sh
+ git clone https://github.com/qbzzt/250420-saml-ethereum -b saml-only
+ cd 250420-saml-ethereum
+ pnpm install
+ ```
+
+2. Vytvořte klíče s certifikáty s vlastním podpisem (self-signed). To znamená, že klíč je svou vlastní certifikační autoritou a je třeba jej ručně importovat do poskytovatele služeb. Více informací naleznete v [dokumentaci OpenSSL](https://docs.openssl.org/master/man1/openssl-req/).
+
+ ```sh
+ mkdir keys
+ cd keys
+ openssl req -new -x509 -days 365 -nodes -sha256 -out saml-sp.crt -keyout saml-sp.pem -subj /CN=sp/
+ openssl req -new -x509 -days 365 -nodes -sha256 -out saml-idp.crt -keyout saml-idp.pem -subj /CN=idp/
+ cd ..
+ ```
+
+3. Spusťte servery (SP i IdP)
+
+ ```sh
+ pnpm start
+ ```
+
+4. Přejděte na adresu URL SP [http://localhost:3000/](http://localhost:3000/) a kliknutím na tlačítko budete přesměrováni na IdP (port 3001).
+
+5. Poskytněte IdP svou e-mailovou adresu a klikněte na **Přihlásit se k poskytovateli služeb**. Uvidíte, že budete přesměrováni zpět k poskytovateli služeb (port 3000) a že vás pozná podle vaší e-mailové adresy.
+
+### Podrobné vysvětlení
+
+Toto se děje krok za krokem:
+
+
+
+#### src/config.mts
+
+Tento soubor obsahuje konfiguraci jak pro poskytovatele identity, tak pro poskytovatele služeb. Obvykle by se jednalo o různé entity, ale zde můžeme pro zjednodušení sdílet kód.
+
+```typescript
+const fs = await import("fs")
+
+const protocol="http"
+```
+
+Zatím jen testujeme, takže je v pořádku používat HTTP.
+
+```typescript
+export const spCert = fs.readFileSync("keys/saml-sp.crt").toString()
+export const idpCert = fs.readFileSync("keys/saml-idp.crt").toString()
+```
+
+Načtení veřejných klíčů, které jsou normálně dostupné oběma komponentám (a jsou buď přímo důvěryhodné, nebo podepsané důvěryhodnou certifikační autoritou).
+
+```typescript
+export const spPort = 3000
+export const spHostname = "localhost"
+export const spDir = "sp"
+
+export const idpPort = 3001
+export const idpHostname = "localhost"
+export const idpDir = "idp"
+
+export const spUrl = `${protocol}://${spHostname}:${spPort}/${spDir}`
+export const idpUrl = `${protocol}://${idpHostname}:${idpPort}/${idpDir}`
+```
+
+Adresy URL pro obě komponenty.
+
+```typescript
+export const spPublicData = {
+```
+
+Veřejná data pro poskytovatele služeb.
+
+```typescript
+ entityID: `${spUrl}/metadata`,
+```
+
+Podle konvence je v SAML `entityID` adresa URL, na které jsou dostupná metadata entity. Tato metadata odpovídají zdejším veřejným datům, s výjimkou toho, že jsou ve formátu XML.
+
+```typescript
+ wantAssertionsSigned: true,
+ authnRequestsSigned: false,
+ signingCert: spCert,
+ allowCreate: true,
+ assertionConsumerService: [{
+ Binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
+ Location: `${spUrl}/assertion`,
+ }]
+ }
+```
+
+Nejdůležitější definicí pro naše účely je `assertionConsumerServer`. To znamená, že abychom poskytovateli služeb mohli něco potvrdit (například, že „uživatel, který vám posílá tyto informace, je nekdo@example.com“), musíme použít [HTTP POST](https://www.w3schools.com/tags/ref_httpmethods.asp) na URL `http://localhost:3000/sp/assertion`.
+
+```typescript
+export const idpPublicData = {
+ entityID: `${idpUrl}/metadata`,
+ signingCert: idpCert,
+ wantAuthnRequestsSigned: false,
+ singleSignOnService: [{
+ Binding: "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST",
+ Location: `${idpUrl}/login`
+ }],
+ singleLogoutService: [{
+ Binding: "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST",
+ Location: `${idpUrl}/logout`
+ }],
+ }
+```
+
+Veřejná data pro poskytovatele identity jsou podobná. Určuje, že pro přihlášení uživatele je třeba odeslat POST na `http://localhost:3001/idp/login` a pro odhlášení uživatele POST na `http://localhost:3001/idp/logout`.
+
+#### src/sp.mts
+
+Toto je kód, který implementuje poskytovatele služeb.
+
+```typescript
+import * as config from "./config.mts"
+const fs = await import("fs")
+const saml = await import("samlify")
+```
+
+K implementaci SAML používáme knihovnu [`samlify`](https://www.npmjs.com/package/samlify).
+
+```typescript
+import * as validator from "@authenio/samlify-node-xmllint"
+saml.setSchemaValidator(validator)
+```
+
+Knihovna `samlify` očekává balíček, který ověří, že XML je správné, podepsané očekávaným veřejným klíčem atd. Pro tento účel používáme [`@authenio/samlify-node-xmllint`](https://www.npmjs.com/package/@authenio/samlify-node-xmllint).
+
+```typescript
+const express = (await import("express")).default
+const spRouter = express.Router()
+const app = express()
+```
+
+[`Router`](https://expressjs.com/en/5x/api.html#router) v [`expressu`](https://expressjs.com/) je „mini webová stránka“, kterou lze připojit k webové stránce. V tomto případě jej používáme ke seskupení všech definic poskytovatele služeb dohromady.
+
+```typescript
+const spPrivateKey = fs.readFileSync("keys/saml-sp.pem").toString()
+
+const sp = saml.ServiceProvider({
+ privateKey: spPrivateKey,
+ ...config.spPublicData
+})
+```
+
+Vlastní reprezentace poskytovatele služeb se skládá ze všech veřejných dat a privátního klíče, který používá k podepisování informací.
+
+```typescript
+const idp = saml.IdentityProvider(config.idpPublicData);
+```
+
+Veřejná data obsahují vše, co poskytovatel služeb potřebuje vědět o poskytovateli identity.
+
+```typescript
+spRouter.get(`/metadata`,
+ (req, res) => res.header("Content-Type", "text/xml").send(sp.getMetadata())
+)
+```
+
+Pro zajištění interoperability s ostatními komponentami SAML by poskytovatelé služeb a identity měli mít svá veřejná data (nazývaná metadata) dostupná ve formátu XML na adrese `/metadata`.
+
+```typescript
+spRouter.post(`/assertion`,
+```
+
+Toto je stránka, na kterou prohlížeč přistupuje, aby se identifikoval. Tvrzení obsahuje identifikátor uživatele (zde používáme e-mailovou adresu) a může obsahovat další atributy. Toto je obslužný program pro krok 7 ve výše uvedeném sekvenčním diagramu.
+
+```typescript
+ async (req, res) => {
+ // console.log(`SAML response:\n${Buffer.from(req.body.SAMLResponse, 'base64').toString('utf-8')}`)
+```
+
+Pomocí zakomentovaného příkazu můžete zobrazit data XML poskytnutá v tvrzení. Je [kódován v base64](https://en.wikipedia.org/wiki/Base64).
+
+```typescript
+ try {
+ const loginResponse = await sp.parseLoginResponse(idp, 'post', req);
+```
+
+Zpracujte požadavek na přihlášení od serveru identity.
+
+```typescript
+ res.send(`
+
+
+ Dobrý den, ${loginResponse.extract.nameID}
+
+
+ `)
+ res.send();
+```
+
+Odešlete odpověď HTML, abyste uživateli ukázali, že jsme obdrželi přihlášení.
+
+```typescript
+ } catch (err) {
+ console.error('Chyba při zpracování odpovědi SAML:', err);
+ res.status(400).send('Ověření SAML se nezdařilo');
+ }
+ }
+)
+```
+
+V případě selhání informujte uživatele.
+
+```typescript
+spRouter.get('/login',
+```
+
+Vytvořte požadavek na přihlášení, když se prohlížeč pokusí o přístup na tuto stránku. Toto je obslužný program pro krok 1 ve výše uvedeném sekvenčním diagramu.
+
+```typescript
+ async (req, res) => {
+ const loginRequest = await sp.createLoginRequest(idp, "post")
+```
+
+Získejte informace pro odeslání požadavku na přihlášení.
+
+```typescript
+ res.send(`
+
+
+
+```
+
+Tato stránka automaticky odešle formulář (viz níže). Díky tomu uživatel nemusí pro přesměrování nic dělat. Toto je krok 2 ve výše uvedeném sekvenčním diagramu.
+
+```typescript
+
+
+
+ `)
+ }
+)
+
+app.use(express.urlencoded({extended: true}))
+```
+
+[Tento middleware](https://expressjs.com/en/5x/api.html#express.urlencoded) čte tělo [požadavku HTTP](https://www.tutorialspoint.com/http/http_requests.htm). Ve výchozím nastavení ho Express ignoruje, protože většina požadavků ho nevyžaduje. Potřebujeme ho, protože POST používá tělo.
+
+```typescript
+app.use(`/${config.spDir}`, spRouter)
+```
+
+Připojte router do adresáře poskytovatele služeb (`/sp`).
+
+```typescript
+app.get("/", (req, res) => {
+ res.send(`
+
+
+
+
+
+ `)
+})
+```
+
+Pokud se prohlížeč pokusí získat kořenový adresář, poskytněte mu odkaz na přihlašovací stránku.
+
+```typescript
+app.listen(config.spPort, () => {
+ console.log(`poskytovatel služeb běží na http://${config.spHostname}:${config.spPort}`)
+})
+```
+
+Naslouchejte na portu `spPort` pomocí této aplikace Express.
+
+#### src/idp.mts
+
+Toto je poskytovatel identity. Je velmi podobný poskytovateli služeb, níže uvedená vysvětlení se týkají částí, které se liší.
+
+```typescript
+const xmlParser = new (await import("fast-xml-parser")).XMLParser(
+ {
+ ignoreAttributes: false, // Zachovat atributy
+ attributeNamePrefix: "@_", // Prefix pro atributy
+ }
+)
+```
+
+Musíme si přečíst a porozumět požadavku XML, který obdržíme od poskytovatele služeb.
+
+```typescript
+const getLoginPage = requestId => `
+```
+
+Tato funkce vytváří stránku s automaticky odesílaným formulářem, který je vrácen v kroku 4 výše uvedeného sekvenčního diagramu.
+
+```typescript
+
+
+ Přihlašovací stránka
+
+
+ Přihlašovací stránka
+
+
+
+
+const idpRouter = express.Router()
+
+idpRouter.post("/loginSubmitted", async (req, res) => {
+ const loginResponse = await idp.createLoginResponse(
+```
+
+Toto je obslužný program pro krok 5 ve výše uvedeném sekvenčním diagramu. [`idp.createLoginResponse`](https://github.com/tngan/samlify/blob/master/src/entity-idp.ts#L73-L125) vytváří odpověď na přihlášení.
+
+```typescript
+ sp,
+ {
+ authnContextClassRef: 'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport',
+ audience: sp.entityID,
+```
+
+Cílovou skupinou je poskytovatel služeb.
+
+```typescript
+ extract: {
+ request: {
+ id: req.body.requestId
+ }
+ },
+```
+
+Informace extrahované z požadavku. Jediný parametr, který nás v požadavku zajímá, je requestId, který umožňuje poskytovateli služeb párovat požadavky a jejich odpovědi.
+
+```typescript
+ signingKey: { privateKey: idpPrivateKey, publicKey: config.idpCert } // Zajistit podepsání
+```
+
+Potřebujeme `signingKey`, abychom měli data k podepsání odpovědi. Poskytovatel služeb nedůvěřuje nepodepsaným požadavkům.
+
+```typescript
+ },
+ "post",
+ {
+ email: req.body.email
+```
+
+Toto je pole s informacemi o uživateli, které posíláme zpět poskytovateli služeb.
+
+```typescript
+ }
+ );
+
+ res.send(`
+
+
+
+
+
+
+
+ `)
+})
+```
+
+Opět použijte automaticky odesílaný formulář. Toto je krok 6 ve výše uvedeném sekvenčním diagramu.
+
+```typescript
+
+// Koncový bod IdP pro požadavky na přihlášení
+idpRouter.post(`/login`,
+```
+
+Toto je koncový bod, který přijímá požadavek na přihlášení od poskytovatele služeb. Toto je obslužný program pro krok 3 ve výše uvedeném sekvenčním diagramu.
+
+```typescript
+ async (req, res) => {
+ try {
+ // Dočasné řešení, protože se mi nepodařilo zprovoznit parseLoginRequest.
+ // const loginRequest = await idp.parseLoginRequest(sp, 'post', req)
+ const samlRequest = xmlParser.parse(Buffer.from(req.body.SAMLRequest, 'base64').toString('utf-8'))
+ res.send(getLoginPage(samlRequest["samlp:AuthnRequest"]["@_ID"]))
+```
+
+Měli bychom být schopni použít [`idp.parseLoginRequest`](https://github.com/tngan/samlify/blob/master/src/entity-idp.ts#L127-L144) ke čtení ID požadavku na ověření. Nepodařilo se mi to však zprovoznit a nestálo za to tím trávit spoustu času, tak jsem prostě použil [univerzální XML parser](https://www.npmjs.com/package/fast-xml-parser). Informace, kterou potřebujeme, je atribut `ID` uvnitř značky ``, která je na nejvyšší úrovni XML.
+
+## Použití podpisů Etherea
+
+Nyní, když můžeme odeslat identitu uživatele poskytovateli služeb, dalším krokem je získat identitu uživatele důvěryhodným způsobem. Viem nám umožňuje jednoduše požádat peněženku o adresu uživatele, ale to znamená žádat o informace prohlížeč. Prohlížeč nemáme pod kontrolou, takže nemůžeme automaticky důvěřovat odpovědi, kterou od něj dostaneme.
+
+Místo toho IdP pošle prohlížeči řetězec k podepsání. Pokud peněženka v prohlížeči tento řetězec podepíše, znamená to, že se skutečně jedná o tuto adresu (tj. zná privátní klíč, který adrese odpovídá).
+
+Chcete-li to vidět v akci, zastavte stávající IdP a SP a spusťte tyto příkazy:
+
+```sh
+git checkout eth-signatures
+pnpm install
+pnpm start
+```
+
+Poté přejděte [na SP](http://localhost:3000) a postupujte podle pokynů.
+
+Všimněte si, že v tomto okamžiku nevíme, jak získat e-mailovou adresu z adresy Etherea, takže místo toho hlásíme SP `@bad.email.address`.
+
+### Podrobné vysvětlení
+
+Změny jsou v krocích 4–5 v předchozím diagramu.
+
+
+
+Jediný soubor, který jsme změnili, je `idp.mts`. Zde jsou změněné části.
+
+```typescript
+import { v4 as uuidv4 } from 'uuid'
+import { verifyMessage } from 'viem'
+```
+
+Potřebujeme tyto dvě další knihovny. K vytvoření hodnoty [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce) používáme [`uuid`](https://www.npmjs.com/package/uuid). Na samotné hodnotě nezáleží, jen na tom, že je použita pouze jednou.
+
+Knihovna [`viem`](https://viem.sh/) nám umožňuje používat definice Etherea. Zde ji potřebujeme k ověření, že podpis je skutečně platný.
+
+```typescript
+const loginPrompt = "Pro přístup k poskytovateli služeb podepište tuto hodnotu nonce: "
+```
+
+Peněženka požádá uživatele o povolení podepsat zprávu. Zpráva, která je pouze hodnotou nonce, by mohla uživatele zmást, proto uvádíme tuto výzvu.
+
+```typescript
+// Zde si ponechte requestID
+let nonces = {}
+```
+
+Potřebujeme informace o požadavku, abychom na něj mohli odpovědět. Mohli bychom ho poslat s požadavkem (krok 4) a přijmout ho zpět (krok 5). Nemůžeme však důvěřovat informacím, které získáváme z prohlížeče, který je pod kontrolou potenciálně nepřátelského uživatele. Je tedy lepší jej uložit zde s hodnotou nonce jako klíčem.
+
+Všimněte si, že pro zjednodušení to zde děláme jako proměnnou. To má však několik nevýhod:
+
+- Jsme zranitelní vůči útoku typu odepření služby (denial of service). Uživatel se zlými úmysly by se mohl pokusit přihlásit vícekrát a zaplnit tak naši paměť.
+- Pokud je třeba proces IdP restartovat, ztratíme stávající hodnoty.
+- Nemůžeme rozkládat zátěž mezi více procesů, protože každý by měl svou vlastní proměnnou.
+
+Na produkčním systému bychom použili databázi a implementovali nějaký mechanismus pro vypršení platnosti.
+
+```typescript
+const getSignaturePage = requestId => {
+ const nonce = uuidv4()
+ nonces[nonce] = requestId
+```
+
+Vytvořte hodnotu nonce a uložte `requestId` pro budoucí použití.
+
+```typescript
+ return `
+
+
+
+
+
+ Prosím podepište
+
+
+
+
+
+`
+}
+```
+
+Zbytek je jen standardní HTML.
+
+```typescript
+idpRouter.get("/signature/:nonce/:account/:signature", async (req, res) => {
+```
+
+Toto je obslužný program pro krok 5 v sekvenčním diagramu.
+
+```typescript
+ const requestId = nonces[req.params.nonce]
+ if (requestId === undefined) {
+ res.send("Špatná hodnota nonce")
+ return ;
+ }
+
+ nonces[req.params.nonce] = undefined
+```
+
+Získejte ID požadavku a odstraňte hodnotu nonce z `nonces`, abyste se ujistili, že ji nelze znovu použít.
+
+```typescript
+ try {
+```
+
+Protože existuje mnoho způsobů, jak může být podpis neplatný, zabalíme to do bloku `try ...` `catch`, který zachytí jakékoli vyvolané chyby.
+
+```typescript
+ const validSignature = await verifyMessage({
+ address: req.params.account,
+ message: `${loginPrompt}${req.params.nonce}`,
+ signature: req.params.signature
+ })
+```
+
+Použijte [`verifyMessage`](https://viem.sh/docs/actions/public/verifyMessage#verifymessage) k implementaci kroku 5.5 v sekvenčním diagramu.
+
+```typescript
+ if (!validSignature)
+ throw("Špatný podpis")
+ } catch (err) {
+ res.send("Chyba:" + err)
+ return ;
+ }
+```
+
+Zbytek obslužného programu je ekvivalentní tomu, co jsme dělali v obslužném programu `/loginSubmitted` dříve, s výjimkou jedné malé změny.
+
+```typescript
+ const loginResponse = await idp.createLoginResponse(
+ .
+ .
+ .
+ {
+ email: req.params.account + "@bad.email.address"
+ }
+ );
+```
+
+Nemáme skutečnou e-mailovou adresu (získáme ji v další části), takže prozatím vracíme adresu Etherea a jasně ji označujeme jako e-mailovou adresu.
+
+```typescript
+// Koncový bod IdP pro požadavky na přihlášení
+idpRouter.post(`/login`,
+ async (req, res) => {
+ try {
+ // Dočasné řešení, protože se mi nepodařilo zprovoznit parseLoginRequest.
+ // const loginRequest = await idp.parseLoginRequest(sp, 'post', req)
+ const samlRequest = xmlParser.parse(Buffer.from(req.body.SAMLRequest, 'base64').toString('utf-8'))
+ res.send(getSignaturePage(samlRequest["samlp:AuthnRequest"]["@_ID"]))
+ } catch (err) {
+ console.error('Chyba při zpracování odpovědi SAML:', err);
+ res.status(400).send('Ověření SAML se nezdařilo');
+ }
+ }
+)
+```
+
+Místo `getLoginPage` nyní v obslužném programu kroku 3 použijte `getSignaturePage`.
+
+## Získání e-mailové adresy
+
+Dalším krokem je získání e-mailové adresy, identifikátoru požadovaného poskytovatelem služeb. K tomu používáme [službu Ethereum Attestation Service (EAS)](https://attest.org/).
+
+Nejjednodušší způsob, jak získat atestace, je použít [GraphQL API](https://docs.attest.org/docs/developer-tools/api). Používáme tento dotaz:
+
+```
+query GetAttestationsByRecipient {
+ attestations(
+ where: {
+ recipient: { equals: "${getAddress(ethAddr)}" }
+ schemaId: { equals: "0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977" }
+ }
+ take: 1
+ ) {
+ data
+ id
+ attester
+ }
+}
+```
+
+Toto [`schemaId`](https://optimism.easscan.org/schema/view/0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977) obsahuje pouze e-mailovou adresu. Tento dotaz žádá o atestace tohoto schématu. Subjekt atestace se nazývá `recipient`. Je to vždy adresa Etherea.
+
+Varování: Způsob, jakým zde získáváme atestace, má dva bezpečnostní problémy.
+
+- Přistupujeme ke koncovému bodu API `https://optimism.easscan.org/graphql`, což je centralizovaná komponenta. Můžeme získat atribut `id` a poté provést ověření na blockchainu, abychom ověřili, že je atestace skutečná, ale koncový bod API může stále cenzurovat atestace tím, že nám o nich neřekne.
+
+ Tento problém není neřešitelný, mohli bychom spustit vlastní koncový bod GraphQL a získat atestace z protokolů řetězce, ale to je pro naše účely zbytečné.
+
+- Nebereme v úvahu identitu atestátora. Kdokoli nám může poskytnout nepravdivé informace. V reálné implementaci bychom měli sadu důvěryhodných atestátorů a zabývali bychom se pouze jejich atestacemi.
+
+Chcete-li to vidět v akci, zastavte stávající IdP a SP a spusťte tyto příkazy:
+
+```sh
+git checkout email-address
+pnpm install
+pnpm start
+```
+
+Poté zadejte svou e-mailovou adresu. Máte dva způsoby, jak to udělat:
+
+- Importujte peněženku pomocí privátního klíče a použijte testovací privátní klíč `0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80`.
+
+- Přidejte atestaci pro svou vlastní e-mailovou adresu:
+
+ 1. Přejděte na [schéma v průzkumníku atestací](https://optimism.easscan.org/schema/view/0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977).
+
+ 2. Klikněte na **Atestovat se schématem**.
+
+ 3. Zadejte svou adresu Etherea jako příjemce, svou e-mailovou adresu jako e-mailovou adresu a vyberte **Onchain**. Poté klikněte na **Provést atestaci**.
+
+ 4. Schvalte transakci ve své peněžence. K zaplacení za palivo budete potřebovat nějaké ETH na [blockchainu Optimism](https://app.optimism.io/bridge/deposit).
+
+Ať tak či onak, poté přejděte na [http://localhost:3000](http://localhost:3000) a postupujte podle pokynů. Pokud jste importovali testovací privátní klíč, e-mail, který obdržíte, je `test_addr_0@example.com`. Pokud jste použili vlastní adresu, měla by to být ta, kterou jste atestovali.
+
+### Podrobné vysvětlení
+
+
+
+Nové kroky jsou komunikace GraphQL, kroky 5.6 a 5.7.
+
+Opět zde jsou změněné části `idp.mts`.
+
+```typescript
+import { GraphQLClient } from 'graphql-request'
+import { SchemaEncoder } from '@ethereum-attestation-service/eas-sdk'
+```
+
+Importujte knihovny, které potřebujeme.
+
+```typescript
+const graphqlEndpointUrl = "https://optimism.easscan.org/graphql"
+```
+
+Pro každý blockchain existuje [samostatný koncový bod](https://docs.attest.org/docs/developer-tools/api).
+
+```typescript
+const graphqlClient = new GraphQLClient(graphqlEndpointUrl, { fetch })
+```
+
+Vytvořte nového klienta `GraphQLClient`, kterého můžeme použít pro dotazování koncového bodu.
+
+```typescript
+const graphqlSchema = 'string emailAddress'
+const graphqlEncoder = new SchemaEncoder(graphqlSchema)
+```
+
+GraphQL nám poskytuje pouze neprůhledný datový objekt s bajty. Abychom mu porozuměli, potřebujeme schéma.
+
+```typescript
+const ethereumAddressToEmail = async ethAddr => {
+```
+
+Funkce pro získání e-mailové adresy z adresy Etherea.
+
+```typescript
+ const query = `
+ query GetAttestationsByRecipient {
+```
+
+Toto je dotaz GraphQL.
+
+```typescript
+ attestations(
+```
+
+Hledáme atestace.
+
+```typescript
+ where: {
+ recipient: { equals: "${getAddress(ethAddr)}" }
+ schemaId: { equals: "0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977" }
+ }
+```
+
+Atestace, které chceme, jsou ty v našem schématu, kde je příjemce `getAddress(ethAddr)`. Funkce [`getAddress`](https://viem.sh/docs/utilities/getAddress#getaddress) zajišťuje, že naše adresa má správný [kontrolní součet](https://github.com/ethereum/ercs/blob/master/ERCS/erc-55.md). To je nutné, protože GraphQL rozlišuje velikost písmen. „0xBAD060A7“, „0xBad060A7“ a „0xbad060a7“ jsou různé hodnoty.
+
+```typescript
+ take: 1
+```
+
+Bez ohledu na to, kolik atestací najdeme, chceme pouze tu první.
+
+```typescript
+ ) {
+ data
+ id
+ attester
+ }
+ }`
+```
+
+Pole, která chceme obdržet.
+
+- `attester`: Adresa, která atestaci odeslala. Obvykle se používá k rozhodnutí, zda atestaci důvěřovat, či nikoli.
+- `id`: ID atestace. Tuto hodnotu můžete použít ke [čtení atestace na blockchainu](https://optimism.blockscout.com/address/0x4200000000000000000000000000000000000021?tab=read_proxy&source_address=0x4E0275Ea5a89e7a3c1B58411379D1a0eDdc5b088#0xa3112a64), abyste ověřili, že informace z dotazu GraphQL jsou správné.
+- `data`: Data schématu (v tomto případě e-mailová adresa).
+
+```typescript
+ const queryResult = await graphqlClient.request(query)
+
+ if (queryResult.attestations.length == 0)
+ return "no_address@available.is"
+```
+
+Pokud neexistuje žádná atestace, vraťte hodnotu, která je zjevně nesprávná, ale která by se poskytovateli služeb jevila jako platná.
+
+```typescript
+ const attestationDataFields = graphqlEncoder.decodeData(queryResult.attestations[0].data)
+ return attestationDataFields[0].value.value
+}
+```
+
+Pokud existuje hodnota, použijte k dekódování dat `decodeData`. Nepotřebujeme metadata, která poskytuje, pouze samotnou hodnotu.
+
+```typescript
+ const loginResponse = await idp.createLoginResponse(
+ sp,
+ {
+ .
+ .
+ .
+ },
+ "post",
+ {
+ email: await ethereumAddressToEmail(req.params.account)
+ }
+ );
+```
+
+Pro získání e-mailové adresy použijte novou funkci.
+
+## A co decentralizace?
+
+V této konfiguraci se uživatelé nemohou vydávat za někoho, kým nejsou, pokud se spoléháme na důvěryhodné atestátory pro mapování adres Etherea na e-mailové adresy. Náš poskytovatel identity je však stále centralizovanou komponentou. Kdokoli, kdo má privátní klíč poskytovatele identity, může poskytovateli služeb posílat nepravdivé informace.
+
+Může existovat řešení pomocí [více-stranného výpočtu (MPC)](https://en.wikipedia.org/wiki/Secure_multi-party_computation). Doufám, že o tom napíšu v budoucím tutoriálu.
+
+## Závěr
+
+Přijetí standardu pro přihlášení, jako jsou podpisy Etherea, se potýká s problémem slepice a vejce. Poskytovatelé služeb chtějí oslovit co nejširší trh. Uživatelé chtějí mít přístup ke službám, aniž by se museli starat o podporu svého standardu pro přihlášení.
+Vytváření adaptérů, jako je Ethereum IdP, nám může pomoci překonat tuto překážku.
+
+[Více z mé práce najdete zde](https://cryptodocguy.pro/).
diff --git a/public/content/translations/cs/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md b/public/content/translations/cs/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md
new file mode 100644
index 00000000000..f1d99e5b0cd
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md
@@ -0,0 +1,156 @@
+---
+title: Začínáme s vývojem pro Ethereum
+description: "Toto je příručka pro začátečníky, jak začít s vývojem pro Ethereum. Provedeme vás od vytvoření koncového bodu API přes vytvoření požadavku z příkazového řádku až po napsání vašeho prvního web3 skriptu! Nejsou nutné žádné zkušenosti s vývojem na blockchainu!"
+author: "Elan Halpern"
+tags:
+ [
+ "javascript",
+ "ethers.js",
+ "uzly",
+ "dotazování",
+ "alchemy"
+ ]
+skill: beginner
+lang: cs
+published: 2020-10-30
+source: Střední
+sourceUrl: https://medium.com/alchemy-api/getting-started-with-ethereum-development-using-alchemy-c3d6a45c567f
+---
+
+
+
+Toto je příručka pro začátečníky, jak začít s vývojem pro Ethereum. V tomto tutoriálu budeme používat [Alchemy](https://alchemyapi.io/), přední vývojářskou platformu pro blockchain, která pohání miliony uživatelů ze 70 % nejlepších blockchainových aplikací, včetně Maker, 0x, MyEtherWallet, Dharma a Kyber. Alchemy nám poskytne přístup ke koncovému bodu API v řetězci Ethereum, abychom mohli číst a zapisovat transakce.
+
+Provedeme vás od registrace u Alchemy až po napsání vašeho prvního web3 skriptu! Nejsou nutné žádné zkušenosti s vývojem na blockchainu!
+
+## 1. Zaregistrujte si bezplatný účet Alchemy {#sign-up-for-a-free-alchemy-account}
+
+Vytvoření účtu u Alchemy je snadné, [zaregistrujte se zdarma zde](https://auth.alchemy.com/).
+
+## 2. Vytvořte aplikaci Alchemy {#create-an-alchemy-app}
+
+Pro komunikaci s řetězcem Ethereum a pro používání produktů Alchemy potřebujete API klíč k ověření vašich požadavků.
+
+API klíče můžete [vytvořit na řídicím panelu](https://dashboard.alchemy.com/). Chcete-li vytvořit nový klíč, přejděte na „Vytvořit aplikaci“, jak je ukázáno níže:
+
+Zvláštní poděkování patří [_ShapeShift_](https://shapeshift.com/) _za to, že nám umožnili ukázat jejich řídicí panel!_
+
+
+
+Vyplňte podrobnosti v sekci „Vytvořit aplikaci“, abyste získali svůj nový klíč. Můžete zde také vidět aplikace, které jste dříve vytvořili, a ty, které vytvořil váš tým. Stávající klíče získáte kliknutím na „Zobrazit klíč“ u kterékoli aplikace.
+
+
+
+Stávající API klíče můžete také získat tak, že najedete kurzorem na „Aplikace“ a jednu vyberete. Zde můžete „zobrazit klíč“, a také „upravit aplikaci“ pro zařazení konkrétních domén na seznam povolených, prohlédnout si několik vývojářských nástrojů a zobrazit analytiku.
+
+
+
+## 3. Vytvoření požadavku z příkazového řádku {#make-a-request-from-the-command-line}
+
+S blockchainem Etherea můžete prostřednictvím Alchemy interagovat pomocí JSON-RPC a curl.
+
+Pro ruční požadavky doporučujeme interagovat s `JSON-RPC` prostřednictvím požadavků `POST`. Jednoduše předejte hlavičku `Content-Type: application/json` a váš dotaz jako tělo `POST` s následujícími poli:
+
+- `jsonrpc`: Verze JSON-RPC – v současné době je podporována pouze verze `2.0`.
+- `method`: Metoda ETH API. [Viz reference API.](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc)
+- `params`: Seznam parametrů, které se mají předat metodě.
+- `id`: ID vašeho požadavku. Bude vráceno odpovědí, abyste mohli sledovat, ke kterému požadavku odpověď patří.
+
+Zde je příklad, který můžete spustit z příkazového řádku pro získání aktuální ceny gasu:
+
+```bash
+curl https://eth-mainnet.alchemyapi.io/v2/demo \
+-X POST \
+-H "Content-Type: application/json" \
+-d '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}'
+```
+
+_**POZNÁMKA:** Nahraďte [https://eth-mainnet.alchemyapi.io/v2/demo](https://eth-mainnet.alchemyapi.io/jsonrpc/demo) svým vlastním API klíčem `https://eth-mainnet.alchemyapi.io/v2/**your-api-key`._
+
+**Výsledky:**
+
+```json
+{ "id": 73,"jsonrpc": "2.0","result": "0x09184e72a000" // 10000000000000 }
+```
+
+## 4. Nastavte si svého Web3 klienta {#set-up-your-web3-client}
+
+**Pokud již máte existujícího klienta,** změňte URL adresu svého současného poskytovatele uzlů na URL adresu Alchemy s vaším API klíčem: `"https://eth-mainnet.alchemyapi.io/v2/your-api-key"`
+
+**_POZNÁMKA:_** Níže uvedené skripty je třeba spustit v **kontextu Node** nebo **uložit do souboru**, nikoli z příkazového řádku. Pokud ještě nemáte nainstalovaný Node nebo npm, podívejte se na tohoto rychlého [průvodce nastavením pro Mac](https://app.gitbook.com/@alchemyapi/s/alchemy/guides/alchemy-for-macs).
+
+Existuje spousta [knihoven Web3](https://docs.alchemyapi.io/guides/getting-started#other-web3-libraries), které můžete integrovat s Alchemy, my však doporučujeme používat [Alchemy Web3](https://docs.alchemy.com/reference/api-overview), přímou náhradu za web3.js, vytvořenou a nakonfigurovanou tak, aby bezproblémově fungovala s Alchemy. To poskytuje řadu výhod, jako jsou automatické opakované pokusy a robustní podpora WebSocketů.
+
+Chcete-li nainstalovat AlchemyWeb3.js, **přejděte do adresáře svého projektu** a spusťte:
+
+**S Yarn:**
+
+```
+yarn add @alch/alchemy-web3
+```
+
+**S NPM:**
+
+```
+npm install @alch/alchemy-web3
+```
+
+Chcete-li interagovat s infrastrukturou uzlů Alchemy, spusťte v NodeJS nebo přidejte toto do souboru JavaScript:
+
+```js
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(
+ "https://eth-mainnet.alchemyapi.io/v2/your-api-key"
+)
+```
+
+## 5. Napište svůj první Web3 skript! {#write-your-first-web3-script}
+
+Nyní si trochu „ušpiníme ruce“ programováním ve web3 a napíšeme jednoduchý skript, který vypíše číslo posledního bloku z hlavní sítě Ethereum (mainnetu).
+
+**1.** Pokud jste tak ještě neučinili, ve svém terminálu vytvořte nový adresář projektu a přejděte do něj:\*\*
+
+```
+mkdir web3-example
+cd web3-example
+```
+
+**2.** Nainstalujte si do projektu závislost Alchemy web3 (nebo jakoukoli jinou web3), pokud jste tak ještě neučinili:\*\*
+
+```
+npm install @alch/alchemy-web3
+```
+
+**3.** Vytvořte soubor s názvem `index.js` a přidejte do něj následující obsah:\*\*
+
+> Nakonec byste měli `demo` nahradit svým HTTP API klíčem Alchemy.
+
+```js
+async function main() {
+ const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+ const web3 = createAlchemyWeb3("https://eth-mainnet.alchemyapi.io/v2/demo")
+ const blockNumber = await web3.eth.getBlockNumber()
+ console.log("Číslo posledního bloku je " + blockNumber)
+}
+main()
+```
+
+Nevyznáte se v asynchronních věcech? Podívejte se na tento [příspěvek na serveru Medium](https://medium.com/better-programming/understanding-async-await-in-javascript-1d81bb079b2c).
+
+**4. Spusťte jej ve svém terminálu pomocí node**
+
+```
+node index.js
+```
+
+**5. Nyní byste měli ve vaší konzoli vidět výstup s číslem posledního bloku!**
+
+```
+Číslo posledního bloku je 11043912
+```
+
+**Paráda! Výborně! Právě jste napsali svůj první web3 skript pomocí Alchemy 🎉**
+
+Nevíte, co dál? Zkuste nasadit svůj první chytrý kontrakt a ponořte se do programování v Solidity v našem [Průvodci chytrým kontraktem Hello World](https://www.alchemy.com/docs/hello-world-smart-contract), nebo si otestujte své znalosti řídicího panelu s [Demo aplikací řídicího panelu](https://docs.alchemyapi.io/tutorials/demo-app)!
+
+_[Zaregistrujte se zdarma u Alchemy](https://auth.alchemy.com/), prohlédněte si naši [dokumentaci](https://www.alchemy.com/docs/) a pro nejnovější zprávy nás sledujte na [Twitteru](https://twitter.com/AlchemyPlatform)_.
diff --git a/public/content/translations/cs/developers/tutorials/guide-to-smart-contract-security-tools/index.md b/public/content/translations/cs/developers/tutorials/guide-to-smart-contract-security-tools/index.md
new file mode 100644
index 00000000000..234e9edc821
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/guide-to-smart-contract-security-tools/index.md
@@ -0,0 +1,102 @@
+---
+title: Průvodce nástroji pro zabezpečení chytrých kontraktů
+description: Přehled tří různých technik testování a analýzy programů
+author: "Trailofbits"
+lang: cs
+tags: [ "solidity", "smart kontrakt účty", "bezpečnost" ]
+skill: intermediate
+published: 2020-09-07
+source: Tvorba bezpečných kontraktů
+sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis
+---
+
+Budeme používat tři různé techniky testování a analýzy programů:
+
+- **Statická analýza pomocí nástroje [Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/).** Všechny cesty programu jsou aproximovány a analyzovány současně prostřednictvím různých prezentací programu (např. graf řízení toku).
+- **Fuzzing s nástrojem [Echidna](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/).** Kód se provádí s pseudonáhodným generováním transakcí. Fuzzer se pokusí najít sekvenci transakcí, která poruší danou vlastnost.
+- **Symbolické spuštění s nástrojem [Manticore](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/).** Formální ověřovací technika, která převádí každou cestu spuštění na matematický vzorec, na němž lze kontrolovat omezení.
+
+Každá technika má své výhody a nevýhody a bude užitečná ve [specifických případech](#determining-security-properties):
+
+| Technika | Nástroj | Použití | Rychlost | Zmeškané chyby | Falešné poplachy |
+| ------------------- | --------- | ----------------------------- | -------- | -------------- | ---------------- |
+| Statická analýza | Slither | CLI a skripty | sekund | střední | nízká |
+| Fuzzing | Echidna | Vlastnosti Solidity | minut | nízká | žádná |
+| Symbolické spuštění | Manticore | Vlastnosti a skripty Solidity | hodin | žádná\* | žádná |
+
+\* pokud jsou všechny cesty prozkoumány bez vypršení časového limitu
+
+**Slither** analyzuje kontrakty během několika sekund, nicméně statická analýza může vést k falešným poplachům a bude méně vhodná pro složité kontroly (např. aritmetické kontroly). Spusťte Slither prostřednictvím rozhraní API pro jednoduchý přístup k vestavěným detektorům nebo prostřednictvím rozhraní API pro uživatelem definované kontroly.
+
+**Echidna** potřebuje běžet několik minut a bude produkovat pouze skutečné pozitivní nálezy. Echidna kontroluje uživatelem zadané bezpečnostní vlastnosti napsané v jazyce Solidity. Může přehlédnout chyby, protože je založena na náhodném prozkoumávání.
+
+**Manticore** provádí analýzu s "největší váhou". Stejně jako Echidna, Manticore ověřuje vlastnosti zadané uživatelem. Bude potřebovat více času na spuštění, ale může prokázat platnost vlastnosti a nebude hlásit falešné poplachy.
+
+## Doporučený pracovní postup {#suggested-workflow}
+
+Začněte s vestavěnými detektory nástroje Slither, abyste se ujistili, že v současné době neexistují žádné jednoduché chyby, ani nebudou zavedeny později. Použijte Slither ke kontrole vlastností souvisejících s dědičností, závislostmi proměnných a strukturálními problémy. Jak se kódová základna rozrůstá, použijte nástroj Echidna k testování složitějších vlastností stavového automatu. Vraťte se k nástroji Slither a vyviňte si vlastní kontroly ochrany, které nejsou v Solidity dostupné, například ochranu proti přepsání funkce. Nakonec použijte Manticore k provedení cíleného ověření kritických bezpečnostních vlastností, např. aritmetických operací.
+
+- Použijte CLI nástroje Slither k zachycení běžných problémů
+- Použijte Echidna k testování bezpečnostních vlastností vašeho kontraktu na vysoké úrovni
+- Použijte Slither k psaní vlastních statických kontrol
+- Použijte Manticore, jakmile budete chtít hloubkové ujištění o kritických bezpečnostních vlastnostech
+
+**Poznámka k jednotkovým testům**. Jednotkové testy jsou nezbytné pro vytváření vysoce kvalitního softwaru. Tyto techniky však nejsou nejvhodnější k nalezení bezpečnostních chyb. Obvykle se používají k testování pozitivního chování kódu (tj. kód funguje podle očekávání v normálním kontextu), zatímco bezpečnostní chyby se obvykle vyskytují v okrajových případech, které vývojáři nezohlednili. V naší studii desítek bezpečnostních auditů chytrých kontraktů nemělo [pokrytí jednotkovými testy žádný vliv na počet ani závažnost bezpečnostních chyb](https://blog.trailofbits.com/2019/08/08/246-findings-from-our-smart-contract-audits-an-executive-summary/), které jsme našli v kódu našich klientů.
+
+## Určení bezpečnostních vlastností {#determining-security-properties}
+
+Chcete-li efektivně testovat a ověřovat svůj kód, musíte identifikovat oblasti, které vyžadují pozornost. Vzhledem k tomu, že vaše zdroje vynaložené na bezpečnost jsou omezené, je důležité určit slabé nebo vysoce hodnotné části vaší kódové základny, abyste optimalizovali své úsilí. Pomoci může modelování hrozeb. Zvažte prostudování:
+
+- [Rychlé posouzení rizik](https://infosec.mozilla.org/guidelines/risk/rapid_risk_assessment.html) (náš preferovaný přístup, když je málo času)
+- [Průvodce modelováním hrozeb datově orientovaných systémů](https://csrc.nist.gov/pubs/sp/800/154/ipd) (aka NIST 800-154)
+- [Modelování hrozeb podle Shostacka](https://www.amazon.com/Threat-Modeling-Designing-Adam-Shostack/dp/1118809998)
+- [STRIDE](https://wikipedia.org/wiki/STRIDE_\(security\)) / [DREAD](https://wikipedia.org/wiki/DREAD_\(risk_assessment_model\))
+- [PASTA](https://wikipedia.org/wiki/Threat_model#P.A.S.T.A.)
+- [Použití tvrzení](https://blog.regehr.org/archives/1091)
+
+### Komponenty {#components}
+
+Vědět, co chcete kontrolovat, vám také pomůže vybrat správný nástroj.
+
+Mezi široké oblasti, které jsou často relevantní pro chytré kontrakty, patří:
+
+- **Stavový automat.** Většinu kontraktů lze reprezentovat jako stavový automat. Zvažte kontrolu, že (1) nelze dosáhnout žádného neplatného stavu, (2) pokud je stav platný, lze ho dosáhnout a (3) žádný stav kontrakt nezablokuje.
+
+ - Echidna a Manticore jsou nástroje, které je třeba upřednostnit pro testování specifikací stavových automatů.
+
+- **Řízení přístupu.** Pokud má váš systém privilegované uživatele (např. vlastníka, správce, ...) musíte zajistit, že (1) každý uživatel může provádět pouze povolené akce a (2) žádný uživatel nemůže blokovat akce privilegovanějšího uživatele.
+
+ - Slither, Echidna a Manticore mohou kontrolovat správné řízení přístupu. Například Slither může zkontrolovat, že pouze funkce na bílé listině postrádají modifikátor onlyOwner. Echidna a Manticore jsou užitečné pro složitější řízení přístupu, jako je oprávnění udělené pouze v případě, že kontrakt dosáhne daného stavu.
+
+- **Aritmetické operace.** Kontrola správnosti aritmetických operací je kritická. Používání `SafeMath` všude je dobrým krokem k zabránění přetečení/podtečení, nicméně stále musíte zvážit další aritmetické chyby, včetně problémů se zaokrouhlováním a chyb, které kontrakt zablokují.
+
+ - Manticore je zde nejlepší volbou. Echidna může být použita, pokud je aritmetika mimo rozsah SMT solveru.
+
+- **Správnost dědičnosti.** Kontrakty v jazyce Solidity se silně spoléhají na vícenásobnou dědičnost. Snadno se mohou vyskytnout chyby, jako je stínící funkce, které chybí volání `super`, a nesprávně interpretované pořadí c3 linearizace.
+
+ - Slither je nástroj, který zajistí odhalení těchto problémů.
+
+- **Externí interakce.** Kontrakty vzájemně interagují a některým externím kontraktům by se nemělo důvěřovat. Například, pokud váš kontrakt spoléhá na externí orákula, zůstane bezpečný, pokud bude polovina dostupných orákul kompromitována?
+
+ - Manticore a Echidna jsou nejlepší volbou pro testování externích interakcí s vašimi kontrakty. Manticore má vestavěný mechanismus pro stubování externích kontraktů.
+
+- **Shoda se standardy.** Standardy Etherea (např. ERC20) mají v historii svého návrhu chyby. Buďte si vědomi omezení standardu, na kterém stavíte.
+ - Slither, Echidna a Manticore vám pomohou odhalit odchylky od daného standardu.
+
+### Tahák pro výběr nástrojů {#tool-selection-cheatsheet}
+
+| Komponenta | Nástroje | Příklady |
+| -------------------- | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Stavový automat | Echidna, Manticore | |
+| Řízení přístupu | Slither, Echidna, Manticore | [Cvičení 2 nástroje Slither](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise2.md), [Cvičení 2 nástroje Echidna](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-2.md) |
+| Aritmetické operace | Manticore, Echidna | [Cvičení 1 nástroje Echidna](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-1.md), [Cvičení 1–3 nástroje Manticore](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore/exercises) |
+| Správnost dědičnosti | Slither | [Cvičení 1 nástroje Slither](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise1.md) |
+| Externí interakce | Manticore, Echidna | |
+| Shoda se standardy | Slither, Echidna, Manticore | [`slither-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance) |
+
+V závislosti na vašich cílech bude třeba zkontrolovat i další oblasti, ale tyto hrubozrnné oblasti zaměření jsou dobrým začátkem pro jakýkoli systém chytrých kontraktů.
+
+Naše veřejné audity obsahují příklady ověřených nebo testovaných vlastností. Zvažte přečtení sekcí `Automated Testing and Verification` v následujících zprávách, abyste si prohlédli reálné bezpečnostní vlastnosti:
+
+- [0x](https://github.com/trailofbits/publications/blob/master/reviews/0x-protocol.pdf)
+- [Balancer](https://github.com/trailofbits/publications/blob/master/reviews/BalancerCore.pdf)
diff --git a/public/content/translations/cs/developers/tutorials/hello-world-smart-contract-fullstack/index.md b/public/content/translations/cs/developers/tutorials/hello-world-smart-contract-fullstack/index.md
new file mode 100644
index 00000000000..f3c55599fe6
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/hello-world-smart-contract-fullstack/index.md
@@ -0,0 +1,1541 @@
+---
+title: Chytrý kontrakt Hello World pro začátečníky – Fullstack
+description: Úvodní tutoriál k psaní a nasazení jednoduchého chytrého kontraktu na Ethereum.
+author: "nstrike2"
+tags:
+ [
+ "solidity",
+ "hardhat",
+ "alchemy",
+ "smart kontrakt účty",
+ "nasazování",
+ "průzkumník bloků",
+ "frontend",
+ "transakce"
+ ]
+skill: beginner
+lang: cs
+published: 2021-10-25
+---
+
+Tento průvodce je pro vás, pokud jste v blockchainovém vývoji nováčkem a nevíte, kde začít nebo jak nasadit chytré kontrakty a interagovat s nimi. Projdeme si vytvoření a nasazení jednoduchého chytrého kontraktu v testovací síti Goerli pomocí [MetaMask](https://metamask.io), [Solidity](https://docs.soliditylang.org/en/v0.8.0/), [Hardhat](https://hardhat.org) a [Alchemy](https://alchemy.com/eth).
+
+K dokončení tohoto tutoriálu budete potřebovat účet Alchemy. [Zaregistrujte si bezplatný účet](https://www.alchemy.com/).
+
+Pokud budete mít kdykoli nějaké otázky, neváhejte se na nás obrátit na [Discordu Alchemy](https://discord.gg/gWuC7zB)!
+
+## Část 1 – Vytvoření a nasazení chytrého kontraktu pomocí Hardhat {#part-1}
+
+### Připojení k síti Ethereum {#connect-to-the-ethereum-network}
+
+Existuje mnoho způsobů, jak posílat požadavky na blockchain Etherea. Pro zjednodušení použijeme bezplatný účet na Alchemy, vývojářské platformě a API pro blockchain, která nám umožňuje komunikovat s ethereovým chainem, aniž bychom museli sami provozovat uzel. Alchemy má také vývojářské nástroje pro monitorování a analýzu; v tomto tutoriálu je využijeme, abychom pochopili, co se děje pod pokličkou při nasazení našeho chytrého kontraktu.
+
+### Vytvoření aplikace a klíče API {#create-your-app-and-api-key}
+
+Jakmile si vytvoříte účet Alchemy, můžete si vygenerovat API klíč vytvořením aplikace. To vám umožní zadávat požadavky do testovací sítě Goerli. Pokud testovací sítě neznáte, můžete si přečíst [průvodce Alchemy výběrem sítě](https://www.alchemy.com/docs/choosing-a-web3-network).
+
+Na řídicím panelu Alchemy najděte v navigační liště rozevírací seznam **Aplikace** a klikněte na **Vytvořit aplikaci**.
+
+
+
+Pojmenujte svou aplikaci „_Hello World_“ a napište krátký popis. Jako prostředí vyberte **Staging** a jako síť **Goerli**.
+
+
+
+_Poznámka: Nezapomeňte vybrat **Goerli**, jinak tento tutoriál nebude fungovat._
+
+Klikněte na **Vytvořit aplikaci**. Vaše aplikace se objeví v tabulce níže.
+
+### Vytvoření účtu Ethereum {#create-an-ethereum-account}
+
+Potřebujete účet Ethereum pro odesílání a přijímání transakcí. Použijeme MetaMask, virtuální peněženku v prohlížeči, která umožňuje uživatelům spravovat adresu svého ethereového účtu.
+
+Účet MetaMask si můžete zdarma stáhnout a vytvořit [zde](https://metamask.io/download). Při vytváření účtu nebo pokud již účet máte, nezapomeňte se vpravo nahoře přepnout na „testovací síť Goerli“ (abychom nepracovali se skutečnými penězi).
+
+### Krok 4: Přidejte ether z Faucetu {#step-4-add-ether-from-a-faucet}
+
+Chcete-li nasadit chytrý kontrakt do testovací sítě, budete potřebovat nějaké falešné ETH. Chcete-li získat ETH v síti Goerli, přejděte na faucet Goerli a zadejte adresu svého účtu Goerli. Upozorňujeme, že faucety Goerli mohou být v poslední době trochu nespolehlivé – podívejte se na [stránku testovacích sítí](/developers/docs/networks/#goerli), kde najdete seznam možností k vyzkoušení:
+
+_Poznámka: Kvůli přetížení sítě to může chvíli trvat._
+\`\`
+
+### Krok 5: Zkontrolujte si zůstatek {#step-5-check-your-balance}
+
+Chcete-li si dvakrát ověřit, že máte ETH v peněžence, zadejte požadavek [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) pomocí [nástroje Alchemy Composer](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D). Tím se vrátí množství ETH v naší peněžence. Chcete-li se dozvědět více, podívejte se na [krátký tutoriál od Alchemy o tom, jak používat nástroj Composer](https://youtu.be/r6sjRxBZJuU).
+
+Zadejte adresu svého účtu MetaMask a klikněte na **Odeslat požadavek**. Zobrazí se odpověď, která vypadá jako úryvek kódu níže.
+
+```json
+{ "jsonrpc": "2.0", "id": 0, "result": "0x2B5E3AF16B1880000" }
+```
+
+> _Poznámka: Tento výsledek je ve wei, nikoliv v ETH. Wei je nejmenší jednotkou etheru._
+
+Uf! Naše falešné peníze jsou všechny tam.
+
+### Krok 6: Inicializace našeho projektu {#step-6-initialize-our-project}
+
+Nejprve musíme pro náš projekt vytvořit složku. Přejděte na příkazový řádek a zadejte následující.
+
+```
+mkdir hello-world
+cd hello-world
+```
+
+Nyní, když jsme uvnitř složky našeho projektu, použijeme `npm init` k inicializaci projektu.
+
+> Pokud ještě nemáte nainstalovaný npm, postupujte podle [těchto pokynů k instalaci Node.js a npm](https://docs.alchemyapi.io/alchemy/guides/alchemy-for-macs#1-install-nodejs-and-npm).
+
+Pro účely tohoto tutoriálu nezáleží na tom, jak na inicializační otázky odpovíte. Zde je pro referenci, jak jsme to udělali my:
+
+```
+název balíčku: (hello-world)
+verze: (1.0.0)
+popis: chytrý kontrakt hello world
+vstupní bod: (index.js)
+příkaz k testování:
+repositář git:
+klíčová slova:
+autor:
+licence: (ISC)
+
+Chystá se zápis do /Users/.../.../.../hello-world/package.json:
+
+{
+ "name": "hello-world",
+ "version": "1.0.0",
+ "description": "chytrý kontrakt hello world",
+ "main": "index.js",
+ "scripts": {
+ "test": "echo \"Chyba: není zadán žádný test\" && exit 1"
+ },
+ "author": "",
+ "license": "ISC"
+}
+```
+
+Schvalte package.json a můžeme pokračovat!
+
+### Krok 7: Stažení nástroje Hardhat {#step-7-download-hardhat}
+
+Hardhat je vývojové prostředí pro kompilaci, nasazení, testování a ladění vašeho softwaru pro Ethereum. Pomáhá vývojářům při lokálním budování chytrých kontraktů a dapps před jejich nasazením na živý řetězec.
+
+Uvnitř našeho projektu `hello-world` spusťte:
+
+```
+npm install --save-dev hardhat
+```
+
+Další podrobnosti o [instalačních pokynech](https://hardhat.org/getting-started/#overview) naleznete na této stránce.
+
+### Krok 8: Vytvoření projektu Hardhat {#step-8-create-hardhat-project}
+
+Uvnitř složky projektu `hello-world` spusťte:
+
+```
+npx hardhat
+```
+
+Poté by se vám měla zobrazit uvítací zpráva a možnost vybrat si, co chcete dělat. Vyberte „create an empty hardhat.config.js“:
+
+```
+888 888 888 888 888
+888 888 888 888 888
+888 888 888 888 888
+8888888888 8888b. 888d888 .d88888 88888b. 8888b. 888888
+888 888 "88b 888P" d88" 888 888 "88b "88b 888
+888 888 .d888888 888 888 888 888 888 .d888888 888
+888 888 888 888 888 Y88b 888 888 888 888 888 Y88b.
+888 888 "Y888888 888 "Y88888 888 888 "Y888888 "Y888
+
+👷 Vítejte v Hardhat v2.0.11 👷
+
+Co chcete udělat? …
+Vytvořit vzorový projekt
+❯ Vytvořit prázdný soubor hardhat.config.js
+Ukončit
+```
+
+Tím se v projektu vygeneruje soubor `hardhat.config.js`. Ten použijeme později v tomto tutoriálu k určení nastavení našeho projektu.
+
+### Krok 9: Přidání složek projektu {#step-9-add-project-folders}
+
+Aby byl projekt přehledný, vytvoříme dvě nové složky. V příkazovém řádku přejděte do kořenového adresáře projektu `hello-world` a zadejte:
+
+```
+mkdir contracts
+mkdir scripts
+```
+
+- `contracts/` je místo, kam uložíme soubor s kódem našeho chytrého kontraktu Hello World
+- `scripts/` je místo, kam uložíme skripty pro nasazení našeho kontraktu a interakci s ním
+
+### Krok 10: Napsání našeho kontraktu {#step-10-write-our-contract}
+
+Možná si říkáte, kdy budeme psát kód? Je čas!
+
+Otevřete si projekt hello-world ve svém oblíbeném editoru. Chytré kontrakty se nejčastěji píší v Solidity, který použijeme i my.
+
+1. Přejděte do složky `contracts` a vytvořte nový soubor s názvem `HelloWorld.sol`
+2. Níže je ukázka chytrého kontraktu Hello World, který budeme v tomto tutoriálu používat. Zkopírujte níže uvedený obsah do souboru `HelloWorld.sol`.
+
+_Poznámka: Nezapomeňte si přečíst komentáře, abyste pochopili, co tento kontrakt dělá._
+
+```
+// Určuje verzi Solidity pomocí sémantického verzování.
+// Více informací: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma
+pragma solidity >=0.7.3;
+
+// Definuje kontrakt s názvem `HelloWorld`.
+// Kontrakt je soubor funkcí a dat (jeho stav). Po nasazení se kontrakt nachází na určité adrese na blockchainu Ethereum. Více informací: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html
+contract HelloWorld {
+
+ // Emituje se při zavolání funkce update
+ // Události chytrého kontraktu jsou způsob, jakým může váš kontrakt sdělit vašemu front-endu, že se na blockchainu něco stalo, což může „naslouchat“ určitým událostem a při jejich výskytu provést akci.
+ event UpdatedMessages(string oldStr, string newStr);
+
+ // Deklaruje stavovou proměnnou `message` typu `string`.
+ // Stavové proměnné jsou proměnné, jejichž hodnoty jsou trvale uloženy v úložišti kontraktu. Klíčové slovo `public` zpřístupňuje proměnné zvenčí kontraktu a vytváří funkci, kterou mohou volat jiné kontrakty nebo klienti pro přístup k hodnotě.
+ string public message;
+
+ // Podobně jako v mnoha třídních objektově orientovaných jazycích je konstruktor speciální funkce, která se provádí pouze při vytvoření kontraktu.
+ // Konstruktory se používají k inicializaci dat kontraktu. Více informací:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors
+ constructor(string memory initMessage) {
+
+ // Přijímá řetězcový argument `initMessage` a nastavuje hodnotu do úložné proměnné kontraktu `message`).
+ message = initMessage;
+ }
+
+ // Veřejná funkce, která přijímá řetězcový argument a aktualizuje úložnou proměnnou `message`.
+ function update(string memory newMessage) public {
+ string memory oldMsg = message;
+ message = newMessage;
+ emit UpdatedMessages(oldMsg, newMessage);
+ }
+}
+```
+
+Jedná se o základní chytrý kontrakt, který při vytvoření ukládá zprávu. Lze jej aktualizovat voláním funkce `update`.
+
+### Krok 11: Připojení MetaMask a Alchemy k vašemu projektu {#step-11-connect-metamask-alchemy-to-your-project}
+
+Vytvořili jsme si peněženku MetaMask, účet Alchemy a napsali jsme náš chytrý kontrakt, nyní je čas je všechny tři propojit.
+
+Každá transakce odeslaná z vaší peněženky vyžaduje podpis s použitím vašeho jedinečného privátního klíče. Abychom programu toto oprávnění poskytli, můžeme náš privátní klíč bezpečně uložit do souboru prostředí. Zde také uložíme API klíč pro Alchemy.
+
+> Chcete-li se dozvědět více o odesílání transakcí, podívejte se na [tento tutoriál](https://www.alchemy.com/docs/hello-world-smart-contract#step-11-connect-metamask--alchemy-to-your-project) o odesílání transakcí pomocí Web3.
+
+Nejprve nainstalujte balíček dotenv do adresáře vašeho projektu:
+
+```
+npm install dotenv --save
+```
+
+Poté vytvořte v kořenovém adresáři projektu soubor `.env`. Přidejte do něj svůj privátní klíč MetaMask a URL adresa Alchemy API pro HTTP.
+
+Váš soubor prostředí se musí jmenovat `.env`, jinak nebude rozpoznán jako soubor prostředí.
+
+Nenazývejte jej `process.env` ani `.env-custom` ani nijak jinak.
+
+- Postupujte podle [těchto pokynů](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key) a exportujte svůj privátní klíč
+- Níže naleznete postup, jak získat URL pro HTTP API Alchemy
+
+
+
+Váš soubor `.env` by měl vypadat takto:
+
+```
+API_URL = "https://eth-goerli.alchemyapi.io/v2/your-api-key"
+PRIVATE_KEY = "your-metamask-private-key"
+```
+
+Abychom je skutečně propojili s naším kódem, budeme na tyto proměnné odkazovat v našem souboru `hardhat.config.js` v kroku 13.
+
+### Krok 12: Instalace Ethers.js {#step-12-install-ethersjs}
+
+Ethers.js je knihovna, která usnadňuje interakci a zadávání požadavků na Ethereum tím, že obaluje [standardní metody JSON-RPC](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc) uživatelsky přívětivějšími metodami.
+
+Hardhat umožňuje integrovat [pluginy](https://hardhat.org/plugins/) pro další nástroje a rozšířenou funkčnost. Pro nasazení kontraktu využijeme [plugin Ethers](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers).
+
+V adresáři projektu zadejte:
+
+```bash
+npm install --save-dev @nomiclabs/hardhat-ethers "ethers@^5.0.0"
+```
+
+### Krok 13: Aktualizace souboru hardhat.config.js {#step-13-update-hardhat-configjs}
+
+Zatím jsme přidali několik závislostí a pluginů, nyní musíme aktualizovat `hardhat.config.js`, aby o nich náš projekt věděl.
+
+Aktualizujte svůj soubor `hardhat.config.js`, aby vypadal takto:
+
+```javascript
+/**
+ * @type import('hardhat/config').HardhatUserConfig
+ */
+
+require("dotenv").config()
+require("@nomiclabs/hardhat-ethers")
+
+const { API_URL, PRIVATE_KEY } = process.env
+
+module.exports = {
+ solidity: "0.7.3",
+ defaultNetwork: "goerli",
+ networks: {
+ hardhat: {},
+ goerli: {
+ url: API_URL,
+ accounts: [`0x${PRIVATE_KEY}`],
+ },
+ },
+}
+```
+
+### Krok 14: Kompilace našeho kontraktu {#step-14-compile-our-contract}
+
+Abychom se ujistili, že zatím vše funguje, zkompilujeme si náš kontrakt. Úkol `compile` je jedním z vestavěných úkolů Hardhatu.
+
+Z příkazového řádku spusťte:
+
+```bash
+npx hardhat compile
+```
+
+Může se zobrazit varování o `SPDX license identifier not provided in source file`, ale nemusíte se tím znepokojovat – doufejme, že vše ostatní vypadá dobře! Pokud ne, vždy můžete napsat zprávu na [discordu Alchemy](https://discord.gg/u72VCg3).
+
+### Krok 15: Napsání našeho skriptu pro nasazení {#step-15-write-our-deploy-script}
+
+Nyní, když je náš kontrakt napsán a náš konfigurační soubor je připraven, je čas napsat náš skript pro nasazení kontraktu.
+
+Přejděte do složky `scripts/`, vytvořte nový soubor s názvem `deploy.js` a přidejte do něj následující obsah:
+
+```javascript
+async function main() {
+ const HelloWorld = await ethers.getContractFactory("HelloWorld")
+
+ // Spusťte nasazení, vrátí se promise, která se vyřeší na objekt kontraktu
+ const hello_world = await HelloWorld.deploy("Hello World!")
+ console.log("Contract deployed to address:", hello_world.address)
+}
+
+main()
+ .then(() => process.exit(0))
+ .catch((error) => {
+ console.error(error)
+ process.exit(1)
+ })
+```
+
+Hardhat skvěle vysvětluje, co každý z těchto řádků kódu dělá ve svém [výukovém programu Kontrakty](https://hardhat.org/tutorial/testing-contracts.html#writing-tests), a my jsme zde jejich vysvětlení převzali.
+
+```javascript
+const HelloWorld = await ethers.getContractFactory("HelloWorld")
+```
+
+`ContractFactory` v ethers.js je abstrakce používaná k nasazení nových chytrých kontraktů, takže `HelloWorld` je zde [továrna](https://en.wikipedia.org/wiki/Factory_\(object-oriented_programming\)) pro instance našeho kontraktu hello world. Při použití pluginu `hardhat-ethers` jsou instance `ContractFactory` a `Contract` ve výchozím nastavení připojeny k prvnímu podepisujícímu (vlastníkovi).
+
+```javascript
+const hello_world = await HelloWorld.deploy()
+```
+
+Volání `deploy()` na `ContractFactory` spustí nasazení a vrátí `Promise`, která se vyřeší na objekt `Contract`. Toto je objekt, který má metodu pro každou z funkcí našeho chytrého kontraktu.
+
+### Krok 16: Nasazení našeho kontraktu {#step-16-deploy-our-contract}
+
+Konečně jsme připraveni nasadit náš chytrý kontrakt! Přejděte na příkazový řádek a spusťte:
+
+```bash
+npx hardhat run scripts/deploy.js --network goerli
+```
+
+Měli byste pak vidět něco takového:
+
+```bash
+Kontrakt nasazen na adresu: 0x6cd7d44516a20882cEa2DE9f205bF401c0d23570
+```
+
+**Tuto adresu si prosím uložte**. Budeme ji používat později v tomto tutoriálu.
+
+Pokud přejdeme na [Goerli Etherscan](https://goerli.etherscan.io) a vyhledáme adresu našeho kontraktu, měli bychom vidět, že byl úspěšně nasazen. Transakce bude vypadat nějak takto:
+
+
+
+Adresa `From` by se měla shodovat s adresou vašeho účtu MetaMask a v adrese `To` bude uvedeno **Vytvoření kontraktu**. Pokud klikneme na transakci, uvidíme v poli `To` adresu našeho kontraktu.
+
+
+
+Výborně! Právě jste nasadili chytrý kontrakt do testovací sítě Ethereum.
+
+Abyste pochopili, co se děje pod pokličkou, přejděte na kartu Průzkumník v našem [řídicím panelu Alchemy](https://dashboard.alchemy.com/explorer). Pokud máte více aplikací Alchemy, nezapomeňte filtrovat podle aplikace a vybrat **Hello World**.
+
+
+
+Zde uvidíte několik metod JSON-RPC, které pro nás Hardhat/Ethers vytvořil pod pokličkou, když jsme volali funkci `.deploy()`. Dvě důležité metody jsou zde [`eth_sendRawTransaction`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction), což je požadavek na zapsání našeho kontraktu do chainu Goerli, a [`eth_getTransactionByHash`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_gettransactionbyhash), což je požadavek na přečtení informací o naší transakci na základě daného haše. Chcete-li se dozvědět více o odesílání transakcí, podívejte se na [náš tutoriál o odesílání transakcí pomocí Web3](/developers/tutorials/sending-transactions-using-web3-and-alchemy/).
+
+## Část 2: Interakce s vaším chytrým kontraktem {#part-2-interact-with-your-smart-contract}
+
+Nyní, když jsme úspěšně nasadili chytrý kontrakt do sítě Goerli, se naučíme, jak s ním interagovat.
+
+### Vytvoření souboru interact.js {#create-a-interactjs-file}
+
+Toto je soubor, do kterého napíšeme náš interakční skript. Budeme používat knihovnu Ethers.js, kterou jste si nainstalovali v části 1.
+
+Uvnitř složky `scripts/` vytvořte nový soubor s názvem `interact.js` a přidejte následující kód:
+
+```javascript
+// interact.js
+
+const API_KEY = process.env.API_KEY
+const PRIVATE_KEY = process.env.PRIVATE_KEY
+const CONTRACT_ADDRESS = process.env.CONTRACT_ADDRESS
+```
+
+### Aktualizujte svůj soubor .env {#update-your-env-file}
+
+Budeme používat nové proměnné prostředí, takže je musíme definovat v souboru `.env`, který [jsme vytvořili dříve](#step-11-connect-metamask-&-alchemy-to-your-project).
+
+Budeme muset přidat definici pro náš Alchemy `API_KEY` a `CONTRACT_ADDRESS`, kde byl váš chytrý kontrakt nasazen.
+
+Váš soubor `.env` by měl vypadat nějak takto:
+
+```bash
+# .env
+
+API_URL = "https://eth-goerli.alchemyapi.io/v2/"
+API_KEY = ""
+PRIVATE_KEY = ""
+CONTRACT_ADDRESS = "0x"
+```
+
+### Získání ABI kontraktu {#grab-your-contract-ABI}
+
+Naše [ABI (Application Binary Interface)](/glossary/#abi) kontraktu je rozhraní pro interakci s naším chytrým kontraktem. Hardhat automaticky generuje ABI a ukládá ho do `HelloWorld.json`. Pro použití ABI budeme muset analyzovat obsah přidáním následujících řádků kódu do našeho souboru `interact.js`:
+
+```javascript
+// interact.js
+const contract = require("../artifacts/contracts/HelloWorld.sol/HelloWorld.json")
+```
+
+Pokud chcete vidět ABI, můžete si ho vytisknout do konzole:
+
+```javascript
+console.log(JSON.stringify(contract.abi))
+```
+
+Abyste viděli své ABI vytištěné v konzoli, přejděte do terminálu a spusťte:
+
+```bash
+npx hardhat run scripts/interact.js
+```
+
+### Vytvoření instance vašeho kontraktu {#create-an-instance-of-your-contract}
+
+Pro interakci s naším kontraktem musíme v našem kódu vytvořit instanci kontraktu. Abychom tak učinili s Ethers.js, budeme muset pracovat se třemi koncepty:
+
+1. Provider - poskytovatel uzlu, který vám dává přístup ke čtení a zápisu do blockchainu
+2. Signer - představuje účet Ethereum, který může podepisovat transakce
+3. Contract - objekt Ethers.js představující konkrétní kontrakt nasazený na blockchainu
+
+K vytvoření naší instance kontraktu použijeme ABI kontraktu z předchozího kroku:
+
+```javascript
+// interact.js
+
+// Provider
+const alchemyProvider = new ethers.providers.AlchemyProvider(
+ (network = "goerli"),
+ API_KEY
+)
+
+// Signer
+const signer = new ethers.Wallet(PRIVATE_KEY, alchemyProvider)
+
+// Contract
+const helloWorldContract = new ethers.Contract(
+ CONTRACT_ADDRESS,
+ contract.abi,
+ signer
+)
+```
+
+Více se o Providerech, Signerech a Kontraktech dozvíte v [dokumentaci ethers.js](https://docs.ethers.io/v5/).
+
+### Přečtěte si úvodní zprávu {#read-the-init-message}
+
+Pamatujete si, když jsme nasadili náš kontrakt s `initMessage = "Hello world!"`? Nyní se chystáme přečíst zprávu uloženou v našem chytrém kontraktu a vytisknout ji do konzole.
+
+V JavaScriptu se při interakci se sítěmi používají asynchronní funkce. Chcete-li se dozvědět více o asynchronních funkcích, [přečtěte si tento článek na Medium](https://blog.bitsrc.io/understanding-asynchronous-javascript-the-event-loop-74cd408419ff).
+
+Použijte níže uvedený kód pro volání funkce `message` v našem chytrém kontraktu a přečtení úvodní zprávy:
+
+```javascript
+// interact.js
+
+// ...
+
+async function main() {
+ const message = await helloWorldContract.message()
+ console.log("Zpráva zní: " + message)
+}
+main()
+```
+
+Po spuštění souboru pomocí `npx hardhat run scripts/interact.js` v terminálu bychom měli vidět tuto odpověď:
+
+```
+Zpráva zní: Hello world!
+```
+
+Výborně! Právě jste úspěšně přečetli data chytrého kontraktu z blockchainu Ethereum, skvělá práce!
+
+### Aktualizovat zprávu {#update-the-message}
+
+Místo pouhého čtení zprávy můžeme také aktualizovat zprávu uloženou v našem chytrém kontraktu pomocí funkce `update`! Docela super, že?
+
+Pro aktualizaci zprávy můžeme přímo zavolat funkci `update` na našem instancovaném objektu Contract:
+
+```javascript
+// interact.js
+
+// ...
+
+async function main() {
+ const message = await helloWorldContract.message()
+ console.log("Zpráva zní: " + message)
+
+ console.log("Aktualizace zprávy...")
+ const tx = await helloWorldContract.update("Toto je nová zpráva.")
+ await tx.wait()
+}
+main()
+```
+
+Všimněte si, že na řádku 11 voláme `.wait()` na vráceném objektu transakce. To zajišťuje, že náš skript počká, až se transakce vytěží na blockchainu, než opustí funkci. Pokud není zahrnuto volání `.wait()`, skript nemusí vidět aktualizovanou hodnotu `message` v kontraktu.
+
+### Přečtěte si novou zprávu {#read-the-new-message}
+
+Měli byste být schopni zopakovat [předchozí krok](#read-the-init-message) a přečíst aktualizovanou hodnotu `message`. Chvilku se zamyslete a zkuste provést změny potřebné k vytištění této nové hodnoty!
+
+Pokud potřebujete nápovědu, takto by měl v tuto chvíli vypadat váš soubor `interact.js`:
+
+```javascript
+// interact.js
+
+const API_KEY = process.env.API_KEY
+const PRIVATE_KEY = process.env.PRIVATE_KEY
+const CONTRACT_ADDRESS = process.env.CONTRACT_ADDRESS
+
+const contract = require("../artifacts/contracts/HelloWorld.sol/HelloWorld.json")
+
+// provider - Alchemy
+const alchemyProvider = new ethers.providers.AlchemyProvider(
+ (network = "goerli"),
+ API_KEY
+)
+
+// signer - you
+const signer = new ethers.Wallet(PRIVATE_KEY, alchemyProvider)
+
+// instance kontraktu
+const helloWorldContract = new ethers.Contract(
+ CONTRACT_ADDRESS,
+ contract.abi,
+ signer
+)
+
+async function main() {
+ const message = await helloWorldContract.message()
+ console.log("Zpráva zní: " + message)
+
+ console.log("Aktualizace zprávy...")
+ const tx = await helloWorldContract.update("toto je nová zpráva")
+ await tx.wait()
+
+ const newMessage = await helloWorldContract.message()
+ console.log("Nová zpráva zní: " + newMessage)
+}
+
+main()
+```
+
+Nyní stačí spustit skript a měli byste vidět starou zprávu, stav aktualizace a novou zprávu vytištěnou ve vašem terminálu!
+
+`npx hardhat run scripts/interact.js --network goerli`
+
+```
+Zpráva zní: Hello World!
+Aktualizace zprávy...
+Nová zpráva zní: Toto je nová zpráva.
+```
+
+Při spouštění tohoto skriptu si můžete všimnout, že krok `Updating the message...` (Aktualizace zprávy...) chvíli trvá, než se načte nová zpráva. Je to kvůli procesu těžby; pokud jste zvědaví na sledování transakcí během jejich těžby, navštivte [mempool Alchemy](https://dashboard.alchemyapi.io/mempool) a podívejte se na stav transakce. Pokud je transakce zrušena, je také užitečné zkontrolovat [Goerli Etherscan](https://goerli.etherscan.io) a vyhledat haš vaší transakce.
+
+## Část 3: Zveřejnění vašeho chytrého kontraktu na Etherscanu {#part-3-publish-your-smart-contract-to-etherscan}
+
+Odvedli jste veškerou těžkou práci, abyste svůj chytrý kontrakt přivedli k životu; nyní je čas podělit se o něj se světem!
+
+Ověřením vašeho chytrého kontraktu na Etherscanu si může kdokoli prohlédnout váš zdrojový kód a interagovat s vaším chytrým kontraktem. Začínáme!
+
+### Krok 1: Vygenerování API klíče na vašem účtu Etherscan {#step-1-generate-an-api-key-on-your-etherscan-account}
+
+Klíč Etherscan API je nezbytný k ověření, že vlastníte chytrý kontrakt, který se pokoušíte publikovat.
+
+Pokud ještě nemáte účet Etherscan, [zaregistrujte si jej](https://etherscan.io/register).
+
+Po přihlášení najděte své uživatelské jméno v navigační liště, najeďte na něj a vyberte tlačítko **Můj profil**.
+
+Na stránce vašeho profilu byste měli vidět boční navigační lištu. Z boční navigační lišty vyberte **API klíče**. Dále stiskněte tlačítko „Přidat“ pro vytvoření nového API klíče, pojmenujte svou aplikaci **hello-world** a stiskněte tlačítko **Vytvořit nový API klíč**.
+
+Váš nový API klíč by se měl objevit v tabulce API klíčů. Zkopírujte API klíč do schránky.
+
+Dále musíme přidat Etherscan API klíč do našeho souboru `.env`.
+
+Po jeho přidání by měl váš soubor `.env` vypadat takto:
+
+```javascript
+API_URL = "https://eth-goerli.alchemyapi.io/v2/your-api-key"
+PUBLIC_KEY = "your-public-account-address"
+PRIVATE_KEY = "your-private-account-address"
+CONTRACT_ADDRESS = "your-contract-address"
+ETHERSCAN_API_KEY = "your-etherscan-key"
+```
+
+### Chytré kontrakty nasazené pomocí Hardhat {#hardhat-deployed-smart-contracts}
+
+#### Instalace hardhat-etherscan {#install-hardhat-etherscan}
+
+Publikování vašeho kontraktu na Etherscan pomocí Hardhat je jednoduché. Nejprve budete muset nainstalovat plugin `hardhat-etherscan`, abyste mohli začít. `hardhat-etherscan` automaticky ověří zdrojový kód a ABI chytrého kontraktu na Etherscanu. Pro jeho přidání spusťte v adresáři `hello-world`:
+
+```text
+npm install --save-dev @nomiclabs/hardhat-etherscan
+```
+
+Po instalaci vložte následující příkaz na začátek souboru `hardhat.config.js` a přidejte možnosti konfigurace Etherscanu:
+
+```javascript
+// hardhat.config.js
+
+require("dotenv").config()
+require("@nomiclabs/hardhat-ethers")
+require("@nomiclabs/hardhat-etherscan")
+
+const { API_URL, PRIVATE_KEY, ETHERSCAN_API_KEY } = process.env
+
+module.exports = {
+ solidity: "0.7.3",
+ defaultNetwork: "goerli",
+ networks: {
+ hardhat: {},
+ goerli: {
+ url: API_URL,
+ accounts: [`0x${PRIVATE_KEY}`],
+ },
+ },
+ etherscan: {
+ // Váš API klíč pro Etherscan
+ // Získejte jej na https://etherscan.io/
+ apiKey: ETHERSCAN_API_KEY,
+ },
+}
+```
+
+#### Ověření vašeho chytrého kontraktu na Etherscanu {#verify-your-smart-contract-on-etherscan}
+
+Ujistěte se, že jsou všechny soubory uloženy a všechny proměnné v souboru `.env` jsou správně nakonfigurovány.
+
+Spusťte úlohu `verify`, předejte adresu kontraktu a síť, kde je nasazen:
+
+```text
+npx hardhat verify --network goerli DEPLOYED_CONTRACT_ADDRESS 'Hello World!'
+```
+
+Ujistěte se, že `DEPLOYED_CONTRACT_ADDRESS` je adresa vašeho nasazeného chytrého kontraktu v testovací síti Goerli. Také poslední argument (`'Hello World!'`) musí být stejná řetězcová hodnota, která byla použita [během kroku nasazení v části 1](#write-our-deploy-script).
+
+Pokud vše půjde dobře, uvidíte ve svém terminálu následující zprávu:
+
+```text
+Zdrojový kód pro kontrakt byl úspěšně odeslán
+contracts/HelloWorld.sol:HelloWorld na 0xdeployed-contract-address
+k ověření na Etherscanu. Čekání na výsledek ověření...
+
+
+Kontrakt HelloWorld byl úspěšně ověřen na Etherscanu.
+https://goerli.etherscan.io/address/#contracts
+```
+
+Výborně! Kód vašeho chytrého kontraktu je na Etherscanu!
+
+### Podívejte se na svůj chytrý kontrakt na Etherscanu! {#check-out-your-smart-contract-on-etherscan}
+
+Když přejdete na odkaz uvedený ve vašem terminálu, měli byste vidět svůj kód chytrého kontraktu a ABI publikované na Etherscanu!
+
+**Paráda – dokázali jste to, šampione! Nyní může kdokoli volat nebo zapisovat do vašeho chytrého kontraktu! Těšíme se, co postavíte příště!**
+
+## Část 4 – Integrace vašeho chytrého kontraktu s frontendem {#part-4-integrating-your-smart-contract-with-the-frontend}
+
+Na konci tohoto tutoriálu budete vědět, jak:
+
+- Připojit peněženku MetaMask k vaší dapp
+- Číst data z vašeho chytrého kontraktu pomocí [Alchemy Web3](https://docs.alchemy.com/alchemy/documentation/alchemy-web3) API
+- Podepisovat transakce Ethereum pomocí MetaMask
+
+Pro tuto dapp budeme jako frontendový framework používat [React](https://react.dev/); je však důležité si uvědomit, že nebudeme trávit mnoho času rozebíráním jeho základů, protože se budeme soustředit hlavně na přenesení funkčnosti Web3 do našeho projektu.
+
+Jako předpoklad byste měli mít základní znalosti Reactu. Pokud ne, doporučujeme dokončit oficiální [tutoriál Úvod do Reactu](https://react.dev/learn).
+
+### Naklonujte si startovací soubory {#clone-the-starter-files}
+
+Nejprve přejděte do [GitHub repozitáře hello-world-part-four](https://github.com/alchemyplatform/hello-world-part-four-tutorial), abyste získali startovací soubory pro tento projekt, a naklonujte tento repozitář na váš lokální počítač.
+
+Otevřete si naklonovaný repozitář lokálně. Všimněte si, že obsahuje dvě složky: `starter-files` a `completed`.
+
+- `starter-files`- **budeme pracovat v tomto adresáři**, propojíme UI s vaší peněženkou Ethereum a s chytrým kontraktem, který jsme publikovali na Etherscanu v [Části 3](#part-3).
+- `completed` obsahuje celý dokončený tutoriál a měl by být použit pouze jako reference, pokud se zaseknete.
+
+Dále si otevřete vaši kopii `starter-files` ve vašem oblíbeném editoru kódu a poté přejděte do složky `src`.
+
+Veškerý kód, který napíšeme, bude umístěn ve složce `src`. Budeme upravovat komponentu `HelloWorld.js` a javascriptové soubory `util/interact.js`, abychom našemu projektu dodali funkčnost Web3.
+
+### Prozkoumejte startovací soubory {#check-out-the-starter-files}
+
+Než začneme kódovat, prozkoumejme, co nám startovací soubory poskytují.
+
+#### Spusťte svůj projekt v Reactu {#get-your-react-project-running}
+
+Začněme spuštěním projektu React v našem prohlížeči. Krása Reactu spočívá v tom, že jakmile náš projekt běží v prohlížeči, veškeré uložené změny se v prohlížeči projeví v reálném čase.
+
+Aby projekt fungoval, přejděte do kořenového adresáře složky `starter-files` a spusťte v terminálu `npm install` pro instalaci závislostí projektu:
+
+```bash
+cd starter-files
+npm install
+```
+
+Jakmile se dokončí instalace, spusťte v terminálu `npm start`:
+
+```bash
+npm start
+```
+
+Tím by se měla ve vašem prohlížeči otevřít adresa [http://localhost:3000/](http://localhost:3000/), kde uvidíte frontend našeho projektu. Měl by se skládat z jednoho pole (místo pro aktualizaci zprávy uložené ve vašem chytrém kontraktu), tlačítka „Připojit peněženku“ a tlačítka „Aktualizovat“.
+
+Pokud zkusíte kliknout na kterékoli tlačítko, zjistíte, že nefungují – je to proto, že jejich funkčnost musíme teprve naprogramovat.
+
+#### Komponenta `HelloWorld.js` {#the-helloworld-js-component}
+
+Vraťme se zpět do složky `src` v našem editoru a otevřeme si soubor `HelloWorld.js`. Je nesmírně důležité, abychom všemu v tomto souboru rozuměli, protože se jedná o primární komponentu Reactu, na které budeme pracovat.
+
+Na začátku tohoto souboru si všimnete, že máme několik importních příkazů, které jsou nezbytné pro spuštění našeho projektu, včetně knihovny React, hooků useEffect a useState, některých položek z `./util/interact.js` (popíšeme je podrobněji brzy!) a loga Alchemy.
+
+```javascript
+// HelloWorld.js
+
+import React from "react"
+import { useEffect, useState } from "react"
+import {
+ helloWorldContract,
+ connectWallet,
+ updateMessage,
+ loadCurrentMessage,
+ getCurrentWalletConnected,
+} from "./util/interact.js"
+
+import alchemylogo from "./alchemylogo.svg"
+```
+
+Dále máme naše stavové proměnné, které budeme aktualizovat po konkrétních událostech.
+
+```javascript
+// HelloWorld.js
+
+//Stavové proměnné
+const [walletAddress, setWallet] = useState("")
+const [status, setStatus] = useState("")
+const [message, setMessage] = useState("Žádné spojení se sítí.")
+const [newMessage, setNewMessage] = useState("")
+```
+
+Zde je, co každá proměnná představuje:
+
+- `walletAddress` – řetězec, který ukládá adresu peněženky uživatele
+- `status` – řetězec, který uchovává užitečnou zprávu, jež uživatele navádí, jak s dapp interagovat
+- `message` - řetězec, který ukládá aktuální zprávu v chytrém kontraktu
+- `newMessage` - řetězec, který ukládá novou zprávu, která bude zapsána do chytrého kontraktu
+
+Po stavových proměnných uvidíte pět neimplementovaných funkcí: `useEffect` ,`addSmartContractListener`, `addWalletListener` , `connectWalletPressed` a `onUpdatePressed`. Níže vysvětlíme, co dělají:
+
+```javascript
+// HelloWorld.js
+
+//voláno pouze jednou
+useEffect(async () => {
+ //TODO: implement
+}, [])
+
+function addSmartContractListener() {
+ //TODO: implement
+}
+
+function addWalletListener() {
+ //TODO: implement
+}
+
+const connectWalletPressed = async () => {
+ //TODO: implement
+}
+
+const onUpdatePressed = async () => {
+ //TODO: implement
+}
+```
+
+- [`useEffect`](https://legacy.reactjs.org/docs/hooks-effect.html)- toto je React hook, který se volá po vykreslení vaší komponenty. Protože má prázdné pole `[]` jako prop (viz řádek 4), bude volán pouze při _prvním_ vykreslení komponenty. Zde načteme aktuální zprávu uloženou v našem chytrém kontraktu, zavoláme naše posluchače chytrého kontraktu a peněženky a aktualizujeme naše UI tak, aby odráželo, zda je peněženka již připojena.
+- `addSmartContractListener`- tato funkce nastaví posluchače, který bude sledovat událost `UpdatedMessages` našeho kontraktu HelloWorld a aktualizuje naše UI, když se zpráva v našem chytrém kontraktu změní.
+- `addWalletListener`- tato funkce nastaví posluchače, který detekuje změny ve stavu peněženky MetaMask uživatele, například když uživatel odpojí svou peněženku nebo přepne adresy.
+- `connectWalletPressed`- tato funkce bude volána pro připojení peněženky MetaMask uživatele k naší dapp.
+- `onUpdatePressed` – tato funkce bude volána, když uživatel bude chtít aktualizovat zprávu uloženou v chytrém kontraktu.
+
+Na konci tohoto souboru máme uživatelské rozhraní naší komponenty.
+
+```javascript
+// HelloWorld.js
+
+//UI naší komponenty
+return (
+
+ 
+
+
+ Aktuální zpráva:
+ {message}
+
+ Nová zpráva:
+
+
+ setNewMessage(e.target.value)}
+ value={newMessage}
+ />
+ {status}
+
+
+
+
+)
+```
+
+Pokud si tento kód pozorně prostudujete, zjistíte, kde v našem UI používáme naše různé stavové proměnné:
+
+- Na řádcích 6-12, pokud je peněženka uživatele připojena (tj. `walletAddress.length > 0`), zobrazíme zkrácenou verzi adresy uživatele `walletAddress` v tlačítku s ID „walletButton;“ jinak se jednoduše zobrazí „Připojit peněženku“.
+- Na řádku 17 zobrazujeme aktuální zprávu uloženou v chytrém kontraktu, která je zachycena v řetězci `message`.
+- Na řádcích 23-26 používáme [řízenou komponentu](https://legacy.reactjs.org/docs/forms.html#controlled-components) k aktualizaci naší stavové proměnné `newMessage`, když se změní vstup v textovém poli.
+
+Kromě našich stavových proměnných také uvidíte, že funkce `connectWalletPressed` a `onUpdatePressed` jsou volány při kliknutí na tlačítka s ID `publishButton` a `walletButton`.
+
+Nakonec se podívejme, kam se tato komponenta `HelloWorld.js` přidává.
+
+Pokud přejdete do souboru `App.js`, který je hlavní komponentou v Reactu a slouží jako kontejner pro všechny ostatní komponenty, uvidíte, že naše komponenta `HelloWorld.js` je vložena na řádku 7.
+
+V neposlední řadě se podívejme na ještě jeden soubor, který máte k dispozici, a to `interact.js`.
+
+#### Soubor `interact.js` {#the-interact-js-file}
+
+Protože se chceme řídit paradigmatem [M-V-C](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller), budeme chtít samostatný soubor, který bude obsahovat všechny naše funkce pro správu logiky, dat a pravidel naší dapp, a poté budeme moci tyto funkce exportovat do našeho frontendu (naší komponenty `HelloWorld.js`).
+
+👆🏽Toto je přesně účel našeho souboru `interact.js`!
+
+Přejděte do složky `util` ve vašem adresáři `src` a všimnete si, že jsme zahrnuli soubor s názvem `interact.js`, který bude obsahovat všechny naše funkce a proměnné pro interakci s chytrým kontraktem a peněženkou.
+
+```javascript
+// interact.js
+
+//export const helloWorldContract;
+
+export const loadCurrentMessage = async () => {}
+
+export const connectWallet = async () => {}
+
+const getCurrentWalletConnected = async () => {}
+
+export const updateMessage = async (message) => {}
+```
+
+Na začátku souboru si všimnete, že jsme zakomentovali objekt `helloWorldContract`. Později v tomto tutoriálu tento objekt odkomentujeme a instancujeme náš chytrý kontrakt do této proměnné, kterou pak exportujeme do naší komponenty `HelloWorld.js`.
+
+Čtyři neimplementované funkce za naším objektem `helloWorldContract` dělají následující:
+
+- `loadCurrentMessage` – tato funkce se stará o logiku načítání aktuální zprávy uložené v chytrém kontraktu. Provede volání _čtení_ na chytrý kontrakt Hello World pomocí [Alchemy Web3 API](https://github.com/alchemyplatform/alchemy-web3).
+- `connectWallet` - tato funkce připojí peněženku MetaMask uživatele k naší dapp.
+- `getCurrentWalletConnected` – tato funkce zkontroluje, zda je účet Ethereum již připojen k naší dapp při načítání stránky a podle toho aktualizuje naše UI.
+- `updateMessage` – tato funkce aktualizuje zprávu uloženou v chytrém kontraktu. Provede _zápisové_ volání na chytrý kontrakt Hello World, takže peněženka MetaMask uživatele bude muset podepsat transakci Ethereum k aktualizaci zprávy.
+
+Nyní, když rozumíme tomu, s čím pracujeme, pojďme zjistit, jak číst z našeho chytrého kontraktu!
+
+### Krok 3: Čtení z vašeho chytrého kontraktu {#step-3-read-from-your-smart-contract}
+
+Chcete-li číst ze svého chytrého kontraktu, musíte úspěšně nastavit:
+
+- API připojení k řetězci Ethereum
+- Načtenou instanci vašeho chytrého kontraktu
+- Funkci pro volání funkce vašeho chytrého kontraktu
+- Posluchače pro sledování aktualizací, když se změní data, která čtete z chytrého kontraktu
+
+To může znít jako mnoho kroků, ale nebojte se! Provedeme vás každým z nich krok za krokem! :\)
+
+#### Vytvoření API spojení s Ethereum chainem {#establish-an-api-connection-to-the-ethereum-chain}
+
+Vzpomínáte si, jak jsme v části 2 tohoto tutoriálu použili náš [Alchemy Web3 klíč k čtení z našeho chytrého kontraktu](https://docs.alchemy.com/alchemy/tutorials/hello-world-smart-contract/interacting-with-a-smart-contract#step-1-install-web3-library)? Ve své dapp budete také potřebovat klíč Alchemy Web3, abyste mohli číst z chainu.
+
+Pokud jej ještě nemáte, nejprve si nainstalujte [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) tak, že přejdete do kořenového adresáře vašich `starter-files` a spustíte v terminálu následující příkaz:
+
+```text
+npm install @alch/alchemy-web3
+```
+
+[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) je nadstavba nad [Web3.js](https://docs.web3js.org/), která poskytuje vylepšené metody API a další klíčové výhody, které vám usnadní život vývojáře web3. Je navržen tak, aby vyžadoval minimální konfiguraci, takže jej můžete ve své aplikaci začít používat okamžitě!
+
+Poté nainstalujte balíček [dotenv](https://www.npmjs.com/package/dotenv) do adresáře svého projektu, abychom měli bezpečné místo pro uložení našeho API klíče po jeho získání.
+
+```text
+npm install dotenv --save
+```
+
+Pro naši dapp **budeme používat náš API klíč pro Websockets** namísto našeho API klíče pro HTTP, protože nám to umožní nastavit posluchače, který detekuje, kdy se změní zpráva uložená v chytrém kontraktu.
+
+Jakmile budete mít svůj API klíč, vytvořte v kořenovém adresáři soubor `.env` a přidejte do něj svou Alchemy Websockets URL. Poté by měl váš soubor `.env` vypadat takto:
+
+```javascript
+REACT_APP_ALCHEMY_KEY = wss://eth-goerli.ws.alchemyapi.io/v2/
+```
+
+Nyní jsme připraveni nastavit náš Alchemy Web3 endpoint v naší dapp! Vraťme se k našemu souboru `interact.js`, který je vnořený do naší složky `util` a přidejme následující kód na začátek souboru:
+
+```javascript
+// interact.js
+
+require("dotenv").config()
+const alchemyKey = process.env.REACT_APP_ALCHEMY_KEY
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(alchemyKey)
+
+//export const helloWorldContract;
+```
+
+Výše jsme nejprve importovali klíč Alchemy z našeho souboru `.env` a poté jsme předali náš `alchemyKey` do `createAlchemyWeb3`, abychom vytvořili náš Alchemy Web3 endpoint.
+
+S tímto připraveným koncovým bodem je čas načíst náš chytrý kontrakt!
+
+#### Načítání vašeho chytrého kontraktu Hello World {#loading-your-hello-world-smart-contract}
+
+K načtení vašeho chytrého kontraktu Hello World budete potřebovat jeho adresu kontraktu a ABI, obojí lze najít na Etherscanu, pokud jste dokončili [Část 3 tohoto tutoriálu.](/developers/tutorials/hello-world-smart-contract-fullstack/#part-3-publish-your-smart-contract-to-etherscan-part-3-publish-your-smart-contract-to-etherscan)
+
+#### Jak získat ABI kontraktu z Etherscanu {#how-to-get-your-contract-abi-from-etherscan}
+
+Pokud jste přeskočili Část 3 tohoto tutoriálu, můžete použít kontrakt HelloWorld s adresou [0x6f3f635A9762B47954229Ea479b4541eAF402A6A](https://goerli.etherscan.io/address/0x6f3f635a9762b47954229ea479b4541eaf402a6a#code). Jeho ABI lze nalézt [zde](https://goerli.etherscan.io/address/0x6f3f635a9762b47954229ea479b4541eaf402a6a#code).
+
+ABI kontraktu je nezbytné pro určení, kterou funkci bude kontrakt volat, a také pro zajištění, že funkce vrátí data ve formátu, který očekáváte. Jakmile jsme zkopírovali naše ABI kontraktu, uložme ho jako JSON soubor s názvem `contract-abi.json` do vašeho adresáře `src`.
+
+Váš contract-abi.json by měl být uložen ve složce src.
+
+Vyzbrojeni adresou kontraktu, ABI a Alchemy Web3 koncovým bodem můžeme použít [metodu kontraktu](https://docs.web3js.org/api/web3-eth-contract/class/Contract) k načtení instance našeho chytrého kontraktu. Importujte ABI vašeho kontraktu do souboru `interact.js` a přidejte adresu svého kontraktu.
+
+```javascript
+// interact.js
+
+const contractABI = require("../contract-abi.json")
+const contractAddress = "0x6f3f635A9762B47954229Ea479b4541eAF402A6A"
+```
+
+Nyní můžeme konečně odkomentovat naši proměnnou `helloWorldContract` a načíst chytrý kontrakt pomocí našeho koncového bodu AlchemyWeb3:
+
+```javascript
+// interact.js
+export const helloWorldContract = new web3.eth.Contract(
+ contractABI,
+ contractAddress
+)
+```
+
+Abychom to shrnuli, prvních 12 řádků vašeho souboru `interact.js` by nyní mělo vypadat takto:
+
+```javascript
+// interact.js
+
+require("dotenv").config()
+const alchemyKey = process.env.REACT_APP_ALCHEMY_KEY
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(alchemyKey)
+
+const contractABI = require("../contract-abi.json")
+const contractAddress = "0x6f3f635A9762B47954229Ea479b4541eAF402A6A"
+
+export const helloWorldContract = new web3.eth.Contract(
+ contractABI,
+ contractAddress
+)
+```
+
+Nyní, když máme náš kontrakt načtený, můžeme implementovat naši funkci `loadCurrentMessage`!
+
+#### Implementace `loadCurrentMessage` ve vašem souboru `interact.js` {#implementing-loadCurrentMessage-in-your-interact-js-file}
+
+Tato funkce je super jednoduchá. Provedeme jednoduché asynchronní volání web3 pro čtení z našeho kontraktu. Naše funkce vrátí zprávu uloženou v chytrém kontraktu:
+
+Aktualizujte `loadCurrentMessage` ve vašem souboru `interact.js` na následující:
+
+```javascript
+// interact.js
+
+export const loadCurrentMessage = async () => {
+ const message = await helloWorldContract.methods.message().call()
+ return message
+}
+```
+
+Protože chceme zobrazit tento chytrý kontrakt v našem UI, aktualizujme funkci `useEffect` v naší komponentě `HelloWorld.js` na následující:
+
+```javascript
+// HelloWorld.js
+
+//voláno pouze jednou
+useEffect(async () => {
+ const message = await loadCurrentMessage()
+ setMessage(message)
+}, [])
+```
+
+Všimněte si, že chceme, aby byla naše funkce `loadCurrentMessage` volána pouze jednou během prvního vykreslení komponenty. Brzy implementujeme `addSmartContractListener` pro automatickou aktualizaci UI po změně zprávy v chytrém kontraktu.
+
+Než se pustíme do našeho posluchače, podívejme se, co jsme zatím dokázali! Uložte si soubory `HelloWorld.js` a `interact.js` a přejděte na [http://localhost:3000/](http://localhost:3000/)
+
+Všimnete si, že aktuální zpráva již neříká „Žádné spojení se sítí“. Místo toho odráží zprávu uloženou v chytrém kontraktu. Super!
+
+#### Vaše UI by nyní mělo odrážet zprávu uloženou v chytrém kontraktu {#your-UI-should-now-reflect-the-message-stored-in-the-smart-contract}
+
+A teď k tomu posluchači...
+
+#### Implementace `addSmartContractListener` {#implement-addsmartcontractlistener}
+
+Pokud si vzpomenete na soubor `HelloWorld.sol`, který jsme napsali v [části 1 této série tutoriálů](https://docs.alchemy.com/alchemy/tutorials/hello-world-smart-contract#step-10-write-our-contract), vzpomenete si, že existuje událost chytrého kontraktu s názvem `UpdatedMessages`, která je emitována po vyvolání funkce `update` našeho chytrého kontraktu (viz řádky 9 a 27):
+
+```javascript
+// HelloWorld.sol
+
+// Určuje verzi Solidity pomocí sémantického verzování.
+// Více informací: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma
+pragma solidity ^0.7.3;
+
+// Definuje kontrakt s názvem `HelloWorld`.
+// Kontrakt je soubor funkcí a dat (jeho stav). Po nasazení se kontrakt nachází na určité adrese na blockchainu Ethereum. Více informací: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html
+contract HelloWorld {
+
+ // Emituje se při zavolání funkce update
+ // Události chytrého kontraktu jsou způsob, jakým může váš kontrakt sdělit vašemu front-endu, že se na blockchainu něco stalo, což může „naslouchat“ určitým událostem a při jejich výskytu provést akci.
+ event UpdatedMessages(string oldStr, string newStr);
+
+ // Deklaruje stavovou proměnnou `message` typu `string`.
+ // Stavové proměnné jsou proměnné, jejichž hodnoty jsou trvale uloženy v úložišti kontraktu. Klíčové slovo `public` zpřístupňuje proměnné zvenčí kontraktu a vytváří funkci, kterou mohou volat jiné kontrakty nebo klienti pro přístup k hodnotě.
+ string public message;
+
+ // Podobně jako v mnoha třídních objektově orientovaných jazycích je konstruktor speciální funkce, která se provádí pouze při vytvoření kontraktu.
+ // Konstruktory se používají k inicializaci dat kontraktu. Více informací:https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors
+ constructor(string memory initMessage) {
+
+ // Přijímá řetězcový argument `initMessage` a nastavuje hodnotu do úložné proměnné kontraktu `message`).
+ message = initMessage;
+ }
+
+ // Veřejná funkce, která přijímá řetězcový argument a aktualizuje úložnou proměnnou `message`.
+ function update(string memory newMessage) public {
+ string memory oldMsg = message;
+ message = newMessage;
+ emit UpdatedMessages(oldMsg, newMessage);
+ }
+}
+```
+
+Události chytrého kontraktu jsou způsob, jakým může váš kontrakt komunikovat, že se na blockchainu něco stalo (tj. došlo k _události_) vaší front-endové aplikaci, která může „naslouchat“ konkrétním událostem a při jejich výskytu provádět akce.
+
+Funkce `addSmartContractListener` bude specificky naslouchat události `UpdatedMessages` našeho chytrého kontraktu Hello World a aktualizovat naše UI, aby zobrazilo novou zprávu.
+
+Upravte `addSmartContractListener` na následující:
+
+```javascript
+// HelloWorld.js
+
+function addSmartContractListener() {
+ helloWorldContract.events.UpdatedMessages({}, (error, data) => {
+ if (error) {
+ setStatus("😥 " + error.message)
+ } else {
+ setMessage(data.returnValues[1])
+ setNewMessage("")
+ setStatus("🎉 Vaše zpráva byla aktualizována!")
+ }
+ })
+}
+```
+
+Pojďme si rozebrat, co se stane, když posluchač detekuje událost:
+
+- Pokud dojde k chybě při emisi události, projeví se to v UI prostřednictvím naší stavové proměnné `status`.
+- V opačném případě použijeme vrácený objekt `data`. `data.returnValues` je pole indexované od nuly, kde první prvek pole ukládá předchozí zprávu a druhý prvek ukládá aktualizovanou. Celkově při úspěšné události nastavíme náš řetězec `message` na aktualizovanou zprávu, vymažeme řetězec `newMessage` a aktualizujeme naši stavovou proměnnou `status`, aby odrážela, že byla na našem chytrém kontraktu publikována nová zpráva.
+
+Nakonec zavoláme našeho posluchače ve funkci `useEffect`, aby byl inicializován při prvním vykreslení komponenty `HelloWorld.js`. Celkově by vaše funkce `useEffect` měla vypadat takto:
+
+```javascript
+// HelloWorld.js
+
+useEffect(async () => {
+ const message = await loadCurrentMessage()
+ setMessage(message)
+ addSmartContractListener()
+}, [])
+```
+
+Nyní, když umíme číst z našeho chytrého kontraktu, bylo by skvělé zjistit, jak do něj také zapisovat! Abychom však mohli do naší dapp zapisovat, musíme k ní mít nejprve připojenou peněženku Ethereum.
+
+Takže dále se budeme zabývat nastavením naší peněženky Ethereum (MetaMask) a jejím připojením k naší dapp!
+
+### Krok 4: Nastavení vaší peněženky Ethereum {#step-4-set-up-your-ethereum-wallet}
+
+Aby mohli uživatelé cokoliv zapsat na Ethereum chain, musí podepisovat transakce pomocí privátních klíčů své virtuální peněženky. Pro tento tutoriál použijeme [MetaMask](https://metamask.io/), virtuální peněženku v prohlížeči, která slouží ke správě vaší adresy účtu Ethereum, protože to pro koncového uživatele velmi usnadňuje podepisování transakcí.
+
+Pokud chcete lépe porozumět tomu, jak fungují transakce na Ethereu, podívejte se na [tuto stránku](/developers/docs/transactions/) od Nadace Ethereum.
+
+#### Stáhněte si MetaMask {#download-metamask}
+
+Účet MetaMask si můžete zdarma stáhnout a vytvořit [zde](https://metamask.io/download). Při vytváření účtu nebo pokud již účet máte, nezapomeňte se vpravo nahoře přepnout na „testovací síť Goerli“ (abychom nepracovali se skutečnými penězi).
+
+#### Přidání etheru z faucetu {#add-ether-from-a-faucet}
+
+K podepsání transakce na blockchainu Ethereum budeme potřebovat nějaký falešný ETH. Pro získání ETH můžete jít na [FaucETH](https://fauceth.komputing.org) a zadat adresu svého účtu Goerli, kliknout na „Požádat o prostředky“, poté v rozevíracím seznamu vybrat „Ethereum Testnet Goerli“ a nakonec znovu kliknout na tlačítko „Požádat o prostředky“. Krátce poté byste měli vidět Eth ve svém účtu MetaMask!
+
+#### Zkontrolujte si zůstatek {#check-your-balance}
+
+Abychom si ověřili, že náš zůstatek je k dispozici, proveďte požadavek [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) pomocí [nástroje Composer od Alchemy](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D). Tím získáte množství Eth ve vaší peněžence. Po zadání adresy vašeho účtu MetaMask a kliknutí na „Send Request“ byste měli vidět takovouto odpověď:
+
+```text
+{"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"}
+```
+
+**POZNÁMKA:** Tento výsledek je ve wei, nikoli v eth. Wei se používá jako nejmenší denominace etheru. Převod z wei na eth je: 1 eth = 10¹⁸ wei. Takže pokud převedeme 0xde0b6b3a7640000 na desetinné číslo, dostaneme 1\*10¹⁸, což se rovná 1 eth.
+
+Uf! Naše falešné peníze jsou všechny tam! 🤑
+
+### Krok 5: Připojení MetaMask k vašemu UI {#step-5-connect-metamask-to-your-UI}
+
+Nyní, když je naše peněženka MetaMask nastavena, připojme k ní naši dapp!
+
+#### Funkce `connectWallet` {#the-connectWallet-function}
+
+V našem souboru `interact.js` implementujeme funkci `connectWallet`, kterou pak můžeme zavolat v naší komponentě `HelloWorld.js`.
+
+Upravme `connectWallet` na následující:
+
+```javascript
+// interact.js
+
+export const connectWallet = async () => {
+ if (window.ethereum) {
+ try {
+ const addressArray = await window.ethereum.request({
+ method: "eth_requestAccounts",
+ })
+ const obj = {
+ status: "👆🏽 Napište zprávu do textového pole výše.",
+ address: addressArray[0],
+ }
+ return obj
+ } catch (err) {
+ return {
+ address: "",
+ status: "😥 " + err.message,
+ }
+ }
+ } else {
+ return {
+ address: "",
+ status: (
+
+
+ {" "}
+ 🦊
+ Musíte si do prohlížeče nainstalovat MetaMask, virtuální peněženku Ethereum.
+
+
+
+ ),
+ }
+ }
+}
+```
+
+Co přesně tedy tento obrovský blok kódu dělá?
+
+Nejprve zkontroluje, zda je ve vašem prohlížeči povoleno `window.ethereum`.
+
+`window.ethereum` je globální API, které vkládá MetaMask a další poskytovatelé peněženek a které webovým stránkám umožňuje žádat o účty uživatelů Etherea. Pokud je schváleno, může číst data z blockchainů, ke kterým je uživatel připojen, a navrhovat uživateli podepisování zpráv a transakcí. Pro více informací se podívejte do [dokumentace MetaMasku](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents)!
+
+Pokud `window.ethereum` _není_ přítomno, znamená to, že MetaMask není nainstalován. Výsledkem je vrácení objektu JSON, kde vrácená `adresa` je prázdný řetězec a objekt JSX `status` sděluje, že uživatel si musí nainstalovat MetaMask.
+
+Pokud `window.ethereum` _je_ přítomno, pak to začne být zajímavé.
+
+Pomocí smyčky try/catch se pokusíme připojit k MetaMasku voláním [`window.ethereum.request({ method: \"eth_requestAccounts\" });`](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts). Volání této funkce otevře MetaMask v prohlížeči, kde bude uživatel vyzván k připojení své peněženky k vaší dapp.
+
+- Pokud se uživatel rozhodne připojit, `method: "eth_requestAccounts"` vrátí pole obsahující všechny adresy účtů uživatele, které se k dapp připojily. Celkově naše funkce `connectWallet` vrátí objekt JSON, který obsahuje _první_ `adresu` v tomto poli (viz řádek 9) a zprávu `status`, která vyzve uživatele k napsání zprávy do chytrého kontraktu.
+- Pokud uživatel spojení odmítne, objekt JSON bude obsahovat prázdný řetězec pro vrácenou `adresu` a zprávu `status`, která odráží, že uživatel spojení odmítl.
+
+Nyní, když jsme napsali tuto funkci `connectWallet`, je dalším krokem její zavolání v naší komponentě `HelloWorld.js`.
+
+#### Přidání funkce `connectWallet` do vaší UI komponenty `HelloWorld.js` {#add-the-connectWallet-function-to-your-HelloWorld-js-ui-component}
+
+Přejděte na funkci `connectWalletPressed` v `HelloWorld.js` a aktualizujte ji na následující:
+
+```javascript
+// HelloWorld.js
+
+const connectWalletPressed = async () => {
+ const walletResponse = await connectWallet()
+ setStatus(walletResponse.status)
+ setWallet(walletResponse.address)
+}
+```
+
+Všimli jste si, jak je většina naší funkčnosti abstrahována od naší komponenty `HelloWorld.js` do souboru `interact.js`? To proto, abychom dodrželi paradigma M-V-C!
+
+V `connectWalletPressed` jednoduše provedeme await volání naší importované funkce `connectWallet` a pomocí její odpovědi aktualizujeme naše proměnné `status` a `walletAddress` prostřednictvím jejich stavových háků (hooks).
+
+Nyní si oba soubory (`HelloWorld.js` a `interact.js`) uložme a otestujme naše UI.
+
+Otevřete si prohlížeč na stránce [http://localhost:3000/](http://localhost:3000/) a stiskněte tlačítko „Připojit peněženku“ vpravo nahoře.
+
+Pokud máte nainstalovaný MetaMask, měli byste být vyzváni k připojení své peněženky k vaší dapp. Přijměte výzvu k připojení.
+
+Měli byste vidět, že tlačítko peněženky nyní ukazuje, že je vaše adresa připojena! Super! 🔥
+
+Dále zkuste obnovit stránku... to je divné. Naše tlačítko peněženky nás vyzývá k připojení MetaMasku, i když už je připojen...
+
+Ale žádný strach! To snadno vyřešíme (chápete?). implementací `getCurrentWalletConnected`, která zkontroluje, zda je adresa již připojena k naší dapp, a podle toho aktualizuje naše UI!
+
+#### Funkce `getCurrentWalletConnected` {#the-getcurrentwalletconnected-function}
+
+Aktualizujte svou funkci `getCurrentWalletConnected` v souboru `interact.js` na následující:
+
+```javascript
+// interact.js
+
+export const getCurrentWalletConnected = async () => {
+ if (window.ethereum) {
+ try {
+ const addressArray = await window.ethereum.request({
+ method: "eth_accounts",
+ })
+ if (addressArray.length > 0) {
+ return {
+ address: addressArray[0],
+ status: "👆🏽 Napište zprávu do textového pole výše.",
+ }
+ } else {
+ return {
+ address: "",
+ status: "🦊 Připojte se k MetaMask pomocí tlačítka vpravo nahoře.",
+ }
+ }
+ } catch (err) {
+ return {
+ address: "",
+ status: "😥 " + err.message,
+ }
+ }
+ } else {
+ return {
+ address: "",
+ status: (
+
+
+ {" "}
+ 🦊
+ Musíte si do prohlížeče nainstalovat MetaMask, virtuální peněženku Ethereum.
+
+
+
+ ),
+ }
+ }
+}
+```
+
+Tento kód je _velmi_ podobný funkci `connectWallet`, kterou jsme právě napsali v předchozím kroku.
+
+Hlavní rozdíl je v tom, že místo volání metody `eth_requestAccounts`, která otevře MetaMask, aby si uživatel mohl připojit svou peněženku, zde voláme metodu `eth_accounts`, která jednoduše vrací pole obsahující adresy MetaMask aktuálně připojené k naší dapp.
+
+Abychom tuto funkci viděli v akci, zavoláme ji ve funkci `useEffect` naší komponenty `HelloWorld.js`:
+
+```javascript
+// HelloWorld.js
+
+useEffect(async () => {
+ const message = await loadCurrentMessage()
+ setMessage(message)
+ addSmartContractListener()
+
+ const { address, status } = await getCurrentWalletConnected()
+ setWallet(address)
+ setStatus(status)
+}, [])
+```
+
+Všimněte si, že odpověď z našeho volání `getCurrentWalletConnected` používáme k aktualizaci našich stavových proměnných `walletAddress` a `status`.
+
+Nyní, když jste přidali tento kód, zkusme obnovit okno našeho prohlížeče.
+
+Paráda! Tlačítko by mělo hlásit, že jste připojeni, a zobrazovat náhled adresy vaší připojené peněženky – i po obnovení!
+
+#### Implementace `addWalletListener` {#implement-addwalletlistener}
+
+Posledním krokem v nastavení peněženky naší dapp je implementace posluchače peněženky, aby se naše uživatelské rozhraní aktualizovalo, když se změní stav naší peněženky, například když se uživatel odpojí nebo přepne účty.
+
+Ve vašem souboru `HelloWorld.js` upravte svou funkci `addWalletListener` na následující:
+
+```javascript
+// HelloWorld.js
+
+function addWalletListener() {
+ if (window.ethereum) {
+ window.ethereum.on("accountsChanged", (accounts) => {
+ if (accounts.length > 0) {
+ setWallet(accounts[0])
+ setStatus("👆🏽 Napište zprávu do textového pole výše.")
+ } else {
+ setWallet("")
+ setStatus("🦊 Připojte se k MetaMask pomocí tlačítka vpravo nahoře.")
+ }
+ })
+ } else {
+ setStatus(
+
+ {" "}
+ 🦊
+ Musíte si do prohlížeče nainstalovat MetaMask, virtuální peněženku Ethereum.
+
+
+ )
+ }
+}
+```
+
+Vsadím se, že už ani nepotřebujete naši pomoc, abyste pochopili, co se zde děje, ale pro úplnost si to rychle rozebereme:
+
+- Nejprve naše funkce zkontroluje, zda je `window.ethereum` povoleno (tj. zda je MetaMask nainstalován).
+ - Pokud není, jednoduše nastavíme naši stavovou proměnnou `status` na řetězec JSX, který uživatele vyzve k instalaci MetaMasku.
+ - Pokud je povoleno, nastavíme na řádku 3 posluchače `window.ethereum.on(\"accountsChanged\")`, který naslouchá změnám stavu v peněžence MetaMask, což zahrnuje případy, kdy uživatel připojí další účet k dapp, přepne účty nebo odpojí účet. Pokud je připojen alespoň jeden účet, stavová proměnná `walletAddress` se aktualizuje jako první účet v poli `accounts` vráceném posluchačem. V opačném případě je `walletAddress` nastaveno jako prázdný řetězec.
+
+V neposlední řadě ji musíme zavolat v naší funkci `useEffect`:
+
+```javascript
+// HelloWorld.js
+
+useEffect(async () => {
+ const message = await loadCurrentMessage()
+ setMessage(message)
+ addSmartContractListener()
+
+ const { address, status } = await getCurrentWalletConnected()
+ setWallet(address)
+ setStatus(status)
+
+ addWalletListener()
+}, [])
+```
+
+A to je vše! Úspěšně jsme dokončili programování veškeré funkčnosti naší peněženky! Nyní k našemu poslednímu úkolu: aktualizaci zprávy uložené v našem chytrém kontraktu!
+
+### Krok 6: Implementace funkce `updateMessage` {#step-6-implement-the-updateMessage-function}
+
+Tak jo, lidi, jsme v cílové rovince! Ve funkci `updateMessage` vašeho souboru `interact.js` uděláme následující:
+
+1. Ujistěte se, že zpráva, kterou chceme publikovat v našem chytrém kontraktu, je platná
+2. Podepište naši transakci pomocí MetaMask
+3. Zavolejte tuto funkci z naší frontendové komponenty `HelloWorld.js`
+
+Nebude to trvat dlouho; pojďme tuto dapp dokončit!
+
+#### Zpracování chyb na vstupu {#input-error-handling}
+
+Je přirozené, že na začátku funkce je nějaké zpracování chyb vstupů.
+
+Budeme chtít, aby se naše funkce vrátila dříve, pokud není nainstalováno rozšíření MetaMask, není připojena žádná peněženka (tj. předaná `adresa` je prázdný řetězec) nebo je `zpráva` prázdný řetězec. Přidejme následující zpracování chyb do `updateMessage`:
+
+```javascript
+// interact.js
+
+export const updateMessage = async (address, message) => {
+ if (!window.ethereum || address === null) {
+ return {
+ status:
+ "💡 Připojte svou peněženku MetaMask pro aktualizaci zprávy na blockchainu.",
+ }
+ }
+
+ if (message.trim() === "") {
+ return {
+ status: "❌ Vaše zpráva nemůže být prázdný řetězec.",
+ }
+ }
+}
+```
+
+Nyní, když máme správné zpracování chyb vstupů, je čas podepsat transakci přes MetaMask!
+
+#### Podepisování naší transakce {#signing-our-transaction}
+
+Pokud jste již obeznámeni s tradičními web3 Ethereum transakcemi, kód, který napíšeme dále, vám bude velmi povědomý. Pod kód pro zpracování chyb vstupů přidejte do `updateMessage` následující:
+
+```javascript
+// interact.js
+
+//nastavení parametrů transakce
+const transactionParameters = {
+ to: contractAddress, // Vyžadováno kromě publikací kontraktů.
+ from: address, // musí se shodovat s aktivní adresou uživatele.
+ data: helloWorldContract.methods.update(message).encodeABI(),
+}
+
+//podepsání transakce
+try {
+ const txHash = await window.ethereum.request({
+ method: "eth_sendTransaction",
+ params: [transactionParameters],
+ })
+ return {
+ status: (
+
+ ✅{" "}
+
+ Zobrazte stav své transakce na Etherscanu!
+
+
+ ℹ️ Jakmile bude transakce ověřena sítí, zpráva bude
+ aktualizována automaticky.
+
+ ),
+ }
+} catch (error) {
+ return {
+ status: "😥 " + error.message,
+ }
+}
+```
+
+Rozeberme si, co se děje. Nejprve nastavíme parametry naší transakce, kde:
+
+- `to` určuje adresu příjemce (náš chytrý kontrakt)
+- `from` určuje podepisujícího transakce, proměnnou `address`, kterou jsme předali do naší funkce
+- `data` obsahuje volání metody `update` našeho chytrého kontraktu Hello World, která přijímá naši řetězcovou proměnnou `message` jako vstup
+
+Poté provedeme await volání `window.ethereum.request`, kde požádáme MetaMask o podepsání transakce. Všimněte si, že na řádcích 11 a 12 určujeme naši metodu eth, `eth_sendTransaction`, a předáváme naše `transactionParameters`.
+
+V tomto okamžiku se v prohlížeči otevře MetaMask a vyzve uživatele k podepsání nebo zamítnutí transakce.
+
+- Pokud je transakce úspěšná, funkce vrátí JSON objekt, kde `status` JSX řetězec vyzve uživatele, aby se podíval na Etherscan pro více informací o své transakci.
+- Pokud transakce selže, funkce vrátí JSON objekt, kde řetězec `status` předá chybovou zprávu.
+
+Celkově by naše funkce `updateMessage` měla vypadat takto:
+
+```javascript
+// interact.js
+
+export const updateMessage = async (address, message) => {
+ //zpracování chyb vstupů
+ if (!window.ethereum || address === null) {
+ return {
+ status:
+ "💡 Připojte svou peněženku MetaMask pro aktualizaci zprávy na blockchainu.",
+ }
+ }
+
+ if (message.trim() === "") {
+ return {
+ status: "❌ Vaše zpráva nemůže být prázdný řetězec.",
+ }
+ }
+
+ //nastavení parametrů transakce
+ const transactionParameters = {
+ to: contractAddress, // Vyžadováno kromě publikací kontraktů.
+ from: address, // musí se shodovat s aktivní adresou uživatele.
+ data: helloWorldContract.methods.update(message).encodeABI(),
+ }
+
+ //podepsání transakce
+ try {
+ const txHash = await window.ethereum.request({
+ method: "eth_sendTransaction",
+ params: [transactionParameters],
+ })
+ return {
+ status: (
+
+ ✅{" "}
+
+ Zobrazte stav své transakce na Etherscanu!
+
+
+ ℹ️ Jakmile bude transakce ověřena sítí, zpráva bude
+ aktualizována automaticky.
+
+ ),
+ }
+ } catch (error) {
+ return {
+ status: "😥 " + error.message,
+ }
+ }
+}
+```
+
+V neposlední řadě musíme naši funkci `updateMessage` propojit s naší komponentou `HelloWorld.js`.
+
+#### Propojení `updateMessage` s frontendem `HelloWorld.js` {#connect-updatemessage-to-the-helloworld-js-frontend}
+
+Naše funkce `onUpdatePressed` by měla provést await volání na importovanou funkci `updateMessage` a upravit stavovou proměnnou `status`, aby odrážela, zda naše transakce uspěla nebo selhala:
+
+```javascript
+// HelloWorld.js
+
+const onUpdatePressed = async () => {
+ const { status } = await updateMessage(walletAddress, newMessage)
+ setStatus(status)
+}
+```
+
+Je to super čisté a jednoduché. A hádejte co... VAŠE DAPP JE HOTOVÁ!!!
+
+Jděte do toho a otestujte tlačítko **Aktualizovat**!
+
+### Vytvořte si vlastní dapp {#make-your-own-custom-dapp}
+
+Skvělé, dostali jste se až na konec tutoriálu! Abychom to shrnuli, naučili jste se:
+
+- Připojit peněženku MetaMask k vašemu projektu dapp
+- Číst data z vašeho chytrého kontraktu pomocí [Alchemy Web3](https://docs.alchemy.com/alchemy/documentation/alchemy-web3) API
+- Podepisovat transakce Ethereum pomocí MetaMask
+
+Nyní jste plně vybaveni k tomu, abyste dovednosti z tohoto tutoriálu uplatnili při vytváření vlastního projektu dapp! Jako vždy, pokud máte nějaké otázky, neváhejte se na nás obrátit s žádostí o pomoc na [Discordu Alchemy](https://discord.gg/gWuC7zB). 🧙♂️
+
+Jakmile dokončíte tento tutoriál, dejte nám vědět, jaké byly vaše zkušenosti, nebo pokud máte nějakou zpětnou vazbu, tak nás označte na Twitteru [@alchemyplatform](https://twitter.com/AlchemyPlatform)!
diff --git a/public/content/translations/cs/developers/tutorials/hello-world-smart-contract/index.md b/public/content/translations/cs/developers/tutorials/hello-world-smart-contract/index.md
new file mode 100644
index 00000000000..9d3e43e6ceb
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/hello-world-smart-contract/index.md
@@ -0,0 +1,367 @@
+---
+title: Chytrý kontrakt Hello World pro začátečníky
+description: Úvodní tutoriál k psaní a nasazení jednoduchého chytrého kontraktu na Ethereum.
+author: "elanh"
+tags:
+ [
+ "solidity",
+ "hardhat",
+ "alchemy",
+ "smart kontrakt účty",
+ "nasazování"
+ ]
+skill: beginner
+lang: cs
+published: 2021-03-31
+---
+
+Pokud s vývojem na blockchainu teprve začínáte a nevíte, kde začít, nebo pokud jen chcete pochopit, jak nasadit chytré kontrakty a interagovat s nimi, je tento průvodce určen právě vám. Provedeme vás vytvořením a nasazením jednoduchého chytrého kontraktu na testovací síti Sepolia pomocí virtuální peněženky [MetaMask](https://metamask.io/), [Solidity](https://docs.soliditylang.org/en/v0.8.0/), [Hardhat](https://hardhat.org/) a [Alchemy](https://www.alchemy.com/eth) (nebojte se, pokud ještě ničemu z toho nerozumíte, všechno si vysvětlíme).
+
+Ve [2. části](https://docs.alchemy.com/docs/interacting-with-a-smart-contract) tohoto tutoriálu si projdeme, jak můžeme s naším nasazeným chytrým kontraktem interagovat, a ve [3. části](https://www.alchemy.com/docs/submitting-your-smart-contract-to-etherscan) si ukážeme, jak ho publikovat na Etherscanu.
+
+Pokud budete mít v kterémkoliv bodě dotazy, neváhejte se zeptat na [Discordu Alchemy](https://discord.gg/gWuC7zB)!
+
+## Krok 1: Připojení k síti Ethereum {#step-1}
+
+Existuje mnoho způsobů, jak posílat požadavky na blockchain Etherea. Pro zjednodušení použijeme bezplatný účet na Alchemy, vývojářské platformy a API pro blockchain, která nám umožňuje komunikovat s blockchainem Etherea, aniž bychom museli provozovat vlastní uzly. Tato platforma má také vývojářské nástroje pro monitorování a analýzu, které v tomto tutoriálu využijeme, abychom pochopili, co se děje „pod kapotou“ při nasazení našeho chytrého kontraktu. Pokud ještě nemáte účet Alchemy, [můžete se zdarma zaregistrovat zde](https://dashboard.alchemy.com/signup).
+
+## Krok 2: Vytvořte svou aplikaci (a klíč API) {#step-2}
+
+Jakmile si vytvoříte účet na Alchemy, můžete si vygenerovat klíč API vytvořením aplikace. To nám umožní posílat požadavky do testovací sítě Sepolia. Pokud neznáte testovací sítě, podívejte se na [tuto stránku](/developers/docs/networks/).
+
+1. Přejděte na stránku „Vytvořit novou aplikaci“ na vašem řídicím panelu Alchemy tak, že na navigační liště vyberete možnost „Vybrat aplikaci“ a kliknete na „Vytvořit novou aplikaci“
+
+
+
+2. Pojmenujte svou aplikaci „Hello World“, uveďte krátký popis a vyberte případ použití, např. „Infra & nástroje“. Dále vyhledejte „Ethereum“ a vyberte síť.
+
+
+
+3. Kliknutím na „Další“ pokračujte, poté na „Vytvořit aplikaci“ a je to! Vaše aplikace by se měla objevit v rozevírací nabídce na navigační liště s klíčem API, který si můžete zkopírovat.
+
+## Krok 3: Vytvoření účtu Ethereum (adresy) {#step-3}
+
+K odesílání a přijímání transakcí potřebujeme ethereový účet. Pro tento výukový program použijeme MetaMask, virtuální peněženku v prohlížeči, která slouží ke správě adresy vašeho ethereového účtu. Více o [transakcích](/developers/docs/transactions/).
+
+Můžete si stáhnout MetaMask a zdarma si vytvořit účet Ethereum [zde](https://metamask.io/download). Při vytváření účtu, nebo pokud již účet máte, se ujistěte, že jste se přepnuli na testovací síť „Sepolia“ pomocí rozevírací nabídky sítě (abychom nepracovali se skutečnými penězi).
+
+Pokud síť Sepolia v seznamu nevidíte, přejděte do nabídky, poté do „Pokročilé“ a sjeďte dolů, abyste zapnuli možnost „Zobrazit testovací sítě“. V nabídce pro výběr sítě zvolte záložku „Vlastní“, kde najdete seznam testovacích sítí a vyberete „Sepolia“.
+
+
+
+## Krok 4: Přidání etheru z faucetu {#step-4}
+
+Abychom mohli náš chytrý kontrakt nasadit na testovací síť, budeme potřebovat nějaké falešné ETH. Pro získání ETH na síti Sepolia můžete přejít na [podrobnosti o síti Sepolia](/developers/docs/networks/#sepolia) a zobrazit si seznam různých faucetů. Pokud jeden nefunguje, zkuste jiný, protože jim někdy mohou dojít prostředky. Může chvíli trvat, než obdržíte své falešné ETH, kvůli vytížení sítě. Brzy poté byste měli vidět ETH ve svém účtu MetaMask!
+
+## Krok 5: Kontrola zůstatku {#step-5}
+
+Abychom si ověřili, že máme zůstatek, provedeme požadavek [eth_getBalance](/developers/docs/apis/json-rpc/#eth_getbalance) pomocí [nástroje Composer od Alchemy](https://sandbox.alchemy.com/?network=ETH_SEPOLIA&method=eth_getBalance&body.id=1&body.jsonrpc=2.0&body.method=eth_getBalance&body.params%5B0%5D=&body.params%5B1%5D=latest). Tím se vrátí množství ETH v naší peněžence. Po zadání adresy vašeho účtu MetaMask a kliknutí na „Send Request“ byste měli vidět takovouto odpověď:
+
+```json
+{ "jsonrpc": "2.0", "id": 0, "result": "0x2B5E3AF16B1880000" }
+```
+
+> **POZNÁMKA:** Tento výsledek je ve wei, nikoliv v ETH. Wei se používá jako nejmenší denominace etheru. Převod z wei na ETH je: 1 ETH = 1018 wei. Takže když převedeme 0x2B5E3AF16B1880000 na desetinné číslo, dostaneme 5\*10¹⁸, což se rovná 5 ETH.
+>
+> Uf! Naše falešné peníze jsou všechny tady
+
+
+Nenahrávejte `.env`! Prosím, ujistěte se, že nikdy nesdílíte ani nezveřejňujete svůj soubor `.env` s nikým, protože tím ohrožujete svá tajemství. Pokud používáte správu verzí, přidejte svůj soubor `.env` do souboru gitignore.
+
+
+
+
+## Krok 12: Instalace Ethers.js {#step-12-install-ethersjs}
+
+Ethers.js je knihovna, která usnadňuje interakci a zadávání požadavků na Ethereum tím, že obaluje [standardní metody JSON-RPC](/developers/docs/apis/json-rpc/) uživatelsky přívětivějšími metodami.
+
+Hardhat velmi usnadňuje integraci [pluginů](https://hardhat.org/plugins/) pro další nástroje a rozšířenou funkčnost. Pro nasazení kontraktu využijeme [plugin Ethers](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers) ([Ethers.js](https://github.com/ethers-io/ethers.js/) má několik velmi čistých metod pro nasazení kontraktu).
+
+V adresáři projektu zadejte:
+
+```
+npm install --save-dev @nomiclabs/hardhat-ethers "ethers@^5.0.0"
+```
+
+V dalším kroku také budeme vyžadovat Ethers v našem souboru `hardhat.config.js`.
+
+## Krok 13: Aktualizace souboru hardhat.config.js {#step-13-update-hardhatconfigjs}
+
+Zatím jsme přidali několik závislostí a pluginů, nyní musíme aktualizovat `hardhat.config.js`, aby o nich náš projekt věděl.
+
+Aktualizujte svůj soubor `hardhat.config.js`, aby vypadal takto:
+
+```
+require('dotenv').config();
+
+require("@nomiclabs/hardhat-ethers");
+const { API_URL, PRIVATE_KEY } = process.env;
+
+/**
+* @type import('hardhat/config').HardhatUserConfig
+*/
+module.exports = {
+ solidity: "0.7.3",
+ defaultNetwork: "sepolia",
+ networks: {
+ hardhat: {},
+ sepolia: {
+ url: API_URL,
+ accounts: [`0x${PRIVATE_KEY}`]
+ }
+ },
+}
+```
+
+## Krok 14: Kompilace našeho kontraktu {#step-14-compile-our-contracts}
+
+Abychom se ujistili, že zatím vše funguje, zkompilujeme si náš kontrakt. Úkol `compile` je jedním z vestavěných úkolů Hardhatu.
+
+Z příkazového řádku spusťte:
+
+```
+npx hardhat compile
+```
+
+Může se vám zobrazit varování `SPDX license identifier not provided in source file`, ale nemusíte se tím znepokojovat – doufejme, že všechno ostatní vypadá dobře! Pokud ne, vždy můžete napsat zprávu na [discordu Alchemy](https://discord.gg/u72VCg3).
+
+## Krok 15: Napsání našeho skriptu pro nasazení {#step-15-write-our-deploy-scripts}
+
+Nyní, když je náš kontrakt napsán a náš konfigurační soubor je připraven, je čas napsat náš skript pro nasazení kontraktu.
+
+Přejděte do složky `scripts/`, vytvořte nový soubor s názvem `deploy.js` a přidejte do něj následující obsah:
+
+```
+async function main() {
+ const HelloWorld = await ethers.getContractFactory("HelloWorld");
+
+ // Spustí nasazení a vrátí příslib, který se vyřeší na objekt kontraktu
+ const hello_world = await HelloWorld.deploy("Hello World!");
+ console.log("Kontrakt nasazen na adresu:", hello_world.address);}
+
+main()
+ .then(() => process.exit(0))
+ .catch(error => {
+ console.error(error);
+ process.exit(1);
+ });
+```
+
+Hardhat skvěle vysvětluje, co každý z těchto řádků kódu dělá ve svém [výukovém programu Kontrakty](https://hardhat.org/tutorial/testing-contracts.html#writing-tests), a my jsme zde jejich vysvětlení převzali.
+
+```
+const HelloWorld = await ethers.getContractFactory("HelloWorld");
+```
+
+`ContractFactory` v ethers.js je abstrakce, která se používá k nasazování nových chytrých kontraktů, takže `HelloWorld` je zde továrna pro instance našeho kontraktu hello world. Při použití pluginu `hardhat-ethers` jsou instance `ContractFactory` a `Contract` ve výchozím nastavení připojeny k prvnímu podepisujícímu.
+
+```
+const hello_world = await HelloWorld.deploy();
+```
+
+Volání `deploy()` na `ContractFactory` spustí nasazení a vrátí `Promise`, který se vyřeší na `Contract`. Toto je objekt, který má metodu pro každou z funkcí našeho chytrého kontraktu.
+
+## Krok 16: Nasazení našeho kontraktu {#step-16-deploy-our-contract}
+
+Konečně jsme připraveni nasadit náš chytrý kontrakt! Přejděte na příkazový řádek a spusťte:
+
+```
+npx hardhat run scripts/deploy.js --network sepolia
+```
+
+Měli byste pak vidět něco takového:
+
+```
+Kontrakt nasazen na adresu: 0x6cd7d44516a20882cEa2DE9f205bF401c0d23570
+```
+
+Pokud přejdeme na [Etherscan sítě Sepolia](https://sepolia.etherscan.io/) a vyhledáme adresu našeho kontraktu, měli bychom vidět, že byl úspěšně nasazen. Transakce bude vypadat nějak takto:
+
+
+
+Adresa `From` by se měla shodovat s adresou vašeho účtu MetaMask a u adresy „To“ bude uvedeno „Vytvoření kontraktu“, ale pokud klikneme na transakci, uvidíme adresu našeho kontraktu v poli `To`:
+
+
+
+Výborně! Právě jste nasadili chytrý kontrakt na blockchain Etherea 🎉
+
+Abychom pochopili, co se děje „pod pokličkou“, přejděme na kartu Explorer v našem [ovládacím panelu Alchemy](https://dashboard.alchemyapi.io/explorer). Pokud máte více aplikací Alchemy, ujistěte se, že filtrujete podle aplikace a vyberete „Hello World“.
+
+
+Zde uvidíte několik volání JSON-RPC, které za nás Hardhat/Ethers provedly „pod kapotou“, když jsme zavolali funkci `.deploy()`. Dvě důležité, které je třeba zmínit, jsou [`eth_sendRawTransaction`](https://www.alchemy.com/docs/node/abstract/abstract-api-endpoints/eth-send-raw-transaction), což je požadavek na skutečný zápis našeho kontraktu do blockchainu Sepolia, a [`eth_getTransactionByHash`](https://www.alchemy.com/docs/node/abstract/abstract-api-endpoints/eth-get-transaction-by-hash), což je požadavek na čtení informací o naší transakci na základě haše (typický vzor u
+transakcí). Chcete-li se dozvědět více o odesílání transakcí, podívejte se na tento tutoriál o [odesílání transakcí pomocí Web3](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)
+
+To je vše k 1. části tohoto tutoriálu, ve 2. části budeme s naším chytrým kontraktem skutečně [interagovat](https://www.alchemy.com/docs/interacting-with-a-smart-contract) aktualizací naší původní zprávy a ve 3. části náš chytrý kontrakt [publikujeme na Etherscanu](https://www.alchemy.com/docs/submitting-your-smart-contract-to-etherscan), aby každý věděl, jak s ním interagovat.
+
+**Chcete se o Alchemy dozvědět více?** Podívejte se na náš [web](https://www.alchemy.com/eth). Nechcete si nechat ujít žádnou aktualizaci? Přihlaste se k odběru našeho newsletteru [zde](https://www.alchemy.com/newsletter)! Nezapomeňte se také připojit na náš [Discord](https://discord.gg/u72VCg3).\*\*.
diff --git a/public/content/translations/cs/developers/tutorials/how-to-implement-an-erc721-market/index.md b/public/content/translations/cs/developers/tutorials/how-to-implement-an-erc721-market/index.md
new file mode 100644
index 00000000000..041c3aa60b0
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/how-to-implement-an-erc721-market/index.md
@@ -0,0 +1,145 @@
+---
+title: Jak implementovat trh ERC-721
+description: Jak dát tokenizované položky k prodeji na decentralizovanou inzertní tabuli
+author: "Alberto Cuesta Cañada"
+tags: [ "chytré kontrakty", "erc-721", "solidity", "tokeny" ]
+skill: intermediate
+lang: cs
+published: 2020-03-19
+source: Hackernoon
+sourceUrl: https://hackernoon.com/how-to-implement-an-erc721-market-1e1a32j9
+---
+
+V tomto článku vám ukážu, jak naprogramovat Craigslist pro blockchain Etherea.
+
+Před Gumtree, Ebay a Craigslist byly inzertní tabule většinou z korku nebo papíru. Inzertní tabule byly na školních chodbách, v novinách, na pouličních lampách, ve výlohách obchodů.
+
+To vše se změnilo s internetem. Počet lidí, kteří mohli vidět konkrétní inzertní tabuli, se znásobil o mnoho řádů. Díky tomu se trhy, které představují, staly mnohem efektivnějšími a rozšířily se do globální velikosti. Ebay je obrovský byznys, který má původ v těchto fyzických inzertních tabulích.
+
+S blockchainem se tyto trhy opět změní, dovolte mi ukázat vám jak.
+
+## Monetizace {#monetization}
+
+Obchodní model veřejné blockchainové inzertní tabule se bude muset lišit od modelu Ebay a podobných společností.
+
+Zaprvé je tu [úhel decentralizace](/developers/docs/web2-vs-web3/). Stávající platformy musí udržovat své vlastní servery. Decentralizovaná platforma je udržována jejími uživateli, takže náklady na provoz základní platformy pro vlastníka platformy klesají na nulu.
+
+Pak je tu front-end, webová stránka nebo rozhraní, které umožňuje přístup k platformě. Zde existuje mnoho možností. Vlastníci platformy mohou omezit přístup a nutit všechny používat jejich rozhraní a účtovat si poplatek. Vlastníci platformy se také mohou rozhodnout otevřít přístup (Moc lidem!). a nechat kohokoli vytvářet rozhraní k platformě. Nebo se majitelé mohli rozhodnout pro jakýkoli přístup uprostřed těchto extrémů.
+
+_Obchodní lídři s větší vizí než já budou vědět, jak to zpeněžit. Vše, co vidím, je, že je to odlišné od současného stavu a pravděpodobně ziskové._
+
+Dále je tu úhel automatizace a plateb. Některé věci mohou být velmi [efektivně tokenizovány](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com) a obchodovány na inzertní tabuli. Tokenizovaná aktiva se v blockchainu snadno převádějí. Velmi složité platební metody lze v blockchainu snadno implementovat.
+
+Jen zde cítím obchodní příležitost. Inzertní tabuli bez provozních nákladů lze snadno implementovat, se složitými platebními cestami zahrnutými v každé transakci. Jsem si jistý, že někdo přijde s nápadem, na co to použít.
+
+Jsem prostě šťastný, že to stavím. Podívejme se na kód.
+
+## Implementace {#implementation}
+
+Před nějakou dobou jsme založili [open-source repozitář](https://github.com/HQ20/contracts?ref=hackernoon.com) s příklady implementací obchodních případů a dalšími vychytávkami, prosím, podívejte se.
+
+Kód pro tuto [inzertní tabuli Etherea](https://github.com/HQ20/contracts/tree/master/contracts/classifieds?ref=hackernoon.com) je tam, prosím, používejte ho a nebojte se ho využít na maximum. Jen si uvědomte, že kód nebyl auditován a musíte provést vlastní hloubkovou kontrolu, než do něj vložíte peníze.
+
+Základy tabule nejsou složité. Všechny inzeráty na tabuli budou jen strukturou s několika poli:
+
+```solidity
+struct Trade {
+ address poster;
+ uint256 item;
+ uint256 price;
+ bytes32 status; // Otevřený, provedený, zrušený
+}
+```
+
+Takže je tu někdo, kdo inzerát zveřejňuje. Položka na prodej. Cena za položku. Stav obchodu, který může být otevřený, provedený nebo zrušený.
+
+Všechny tyto obchody budou uloženy v mapování. Protože všechno v Solidity se zdá být mapování. Také proto, že je to pohodlné.
+
+```solidity
+mapping(uint256 => Trade) public trades;
+```
+
+Použití mapování jen znamená, že musíme před zveřejněním přijít s ID pro každý inzerát a budeme muset znát ID inzerátu, než s ním budeme moci pracovat. Existuje několik způsobů, jak se s tím vypořádat, a to buď v chytrém kontraktu, nebo ve front-endu. Pokud potřebujete nějaké rady, zeptejte se.
+
+Dále přichází otázka, s jakými položkami se zabýváme a jaká je měna, která se používá k placení za transakci.
+
+U položek budeme jen požadovat, aby implementovaly rozhraní [ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/IERC721.sol?ref=hackernoon.com), což je ve skutečnosti jen způsob, jak reprezentovat položky z reálného světa v blockchainu, i když to [nejlépe funguje s digitálními aktivy](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com). V konstruktoru zadáme náš vlastní kontrakt ERC721, což znamená, že jakákoli aktiva v naší inzertní tabuli musí být předem tokenizována.
+
+U plateb uděláme něco podobného. Většina blockchainových projektů definuje svou vlastní kryptoměnu [ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol?ref=hackernoon.com). Některé jiné preferují použití mainstreamové kryptoměny jako DAI. V této inzertní tabuli se stačí při konstrukci rozhodnout, jaká bude vaše měna. Snadné.
+
+```solidity
+constructor (
+ address _currencyTokenAddress, address _itemTokenAddress
+) public {
+ currencyToken = IERC20(_currencyTokenAddress);
+ itemToken = IERC721(_itemTokenAddress);
+ tradeCounter = 0;
+}
+```
+
+Už se k tomu dostáváme. Máme inzeráty, položky k obchodu a měnu pro platby. Vytvořit inzerát znamená vložit položku do úschovy (escrow), abyste ukázali, že ji máte, a že jste ji nezveřejnili dvakrát, případně na jiné tabuli.
+
+Níže uvedený kód dělá přesně to. Vloží položku do úschovy (escrow), vytvoří inzerát, provede nějaké úklidové práce.
+
+```solidity
+function openTrade(uint256 _item, uint256 _price)
+ public
+{
+ itemToken.transferFrom(msg.sender, address(this), _item);
+ trades[tradeCounter] = Trade({
+ poster: msg.sender,
+ item: _item,
+ price: _price,
+ status: "Open"
+ });
+ tradeCounter += 1;
+ emit TradeStatusChange(tradeCounter - 1, "Open");
+}
+```
+
+Přijmout obchod znamená vybrat inzerát (obchod), zaplatit cenu, obdržet položku. Níže uvedený kód načte obchod. Zkontroluje, zda je k dispozici. Zaplatí za položku. Načte položku. Aktualizuje inzerát.
+
+```solidity
+function executeTrade(uint256 _trade)
+ public
+{
+ Trade memory trade = trades[_trade];
+ require(trade.status == "Open", "Obchod není otevřený.");
+ currencyToken.transferFrom(msg.sender, trade.poster, trade.price);
+ itemToken.transferFrom(address(this), msg.sender, trade.item);
+ trades[_trade].status = "Executed";
+ emit TradeStatusChange(_trade, "Executed");
+}
+```
+
+Nakonec máme pro prodejce možnost odstoupit od obchodu dříve, než ho kupující přijme. V některých modelech by inzeráty byly místo toho aktivní po určitou dobu, než vyprší jejich platnost. Vaše volba v závislosti na návrhu vašeho trhu.
+
+Kód je velmi podobný tomu, který se používá k provedení obchodu, pouze s tím rozdílem, že nedochází k výměně měny a položka se vrací autorovi inzerátu.
+
+```solidity
+function cancelTrade(uint256 _trade)
+ public
+{
+ Trade memory trade = trades[_trade];
+ require(
+ msg.sender == trade.poster,
+ "Obchod může zrušit pouze autor."
+ );
+ require(trade.status == "Open", "Obchod není otevřený.");
+ itemToken.transferFrom(address(this), trade.poster, trade.item);
+ trades[_trade].status = "Cancelled";
+ emit TradeStatusChange(_trade, "Cancelled");
+}
+```
+
+A je to. Dostali jste se na konec implementace. Je docela překvapivé, jak kompaktní jsou některé obchodní koncepty, když jsou vyjádřeny v kódu, a toto je jeden z těch případů. Podívejte se na kompletní kontrakt [v našem repozitáři](https://github.com/HQ20/contracts/blob/master/contracts/classifieds/Classifieds.sol).
+
+## Závěr {#conclusion}
+
+Inzertní tabule jsou běžnou konfigurací trhu, která se s internetem masivně rozšířila a stala se nesmírně populárním obchodním modelem s několika monopolními vítězi.
+
+Inzertní tabule jsou také nástrojem, který lze snadno replikovat v blockchainovém prostředí, se velmi specifickými funkcemi, které umožní vyzvat stávající giganty.
+
+V tomto článku jsem se pokusil propojit obchodní realitu inzertního byznysu s technologickou implementací. Tyto znalosti by vám měly pomoci vytvořit vizi a plán implementace, pokud máte správné dovednosti.
+
+Jako vždy, pokud se chystáte vytvořit něco zábavného a uvítali byste radu, prosím, [napište mi](https://albertocuesta.es/)! Vždy rád pomohu.
diff --git a/public/content/translations/cs/developers/tutorials/how-to-mint-an-nft/index.md b/public/content/translations/cs/developers/tutorials/how-to-mint-an-nft/index.md
new file mode 100644
index 00000000000..3dd435d0c96
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/how-to-mint-an-nft/index.md
@@ -0,0 +1,335 @@
+---
+title: Jak vyrazit NFT (část 2/3 série tutoriálů o NFT)
+description: Tento tutoriál popisuje, jak vyrazit NFT na blockchainu Etherea pomocí našeho chytrého kontraktu a Web3.
+author: "Sumi Mudgil"
+tags:
+ [
+ "ERC-721",
+ "alchemy",
+ "solidity",
+ "smart kontrakt účty"
+ ]
+skill: beginner
+lang: cs
+published: 2021-04-22
+---
+
+[Beeple](https://www.nytimes.com/2021/03/11/arts/design/nft-auction-christies-beeple.html): 69 milionů
+[3LAU](https://www.forbes.com/sites/abrambrown/2021/03/03/3lau-nft-nonfungible-tokens-justin-blau/?sh=5f72ef64643b): 11 milionů
+[Grimes](https://www.theguardian.com/music/2021/mar/02/grimes-sells-digital-art-collection-non-fungible-tokens): 6 milionů
+
+Všichni z nich vyrazili svá NFT pomocí výkonného API od Alchemy. V tomto tutoriálu vás naučíme, jak udělat to samé za \<10 minut.
+
+„Ražba NFT“ je akt publikování jedinečné instance vašeho tokenu ERC-721 na blockchainu. Pomocí našeho chytrého kontraktu z [1. části této série tutoriálů o NFT](/developers/tutorials/how-to-write-and-deploy-an-nft/) si procvičíme naše dovednosti s Web3 a vyrazíme si NFT. Na konci tohoto tutoriálu si budete moci vyrazit tolik NFT, kolik jen vaše srdce (a peněženka) bude chtít!
+
+Pojďme na to!
+
+## Krok 1: Nainstalujte si Web3 {#install-web3}
+
+Pokud jste postupovali podle prvního tutoriálu o vytváření vašeho chytrého kontraktu pro NFT, máte již zkušenosti s používáním Ethers.js. Web3 je podobné Ethers, protože se jedná o knihovnu, která usnadňuje vytváření požadavků na blockchain Etherea. V tomto tutoriálu budeme používat [Alchemy Web3](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3), což je vylepšená knihovna Web3, která nabízí automatické opakování pokusů a robustní podporu WebSocket.
+
+V domovském adresáři vašeho projektu spusťte:
+
+```
+npm install @alch/alchemy-web3
+```
+
+## Krok 2: Vytvořte soubor `mint-nft.js` {#create-mintnftjs}
+
+V adresáři `scripts` vytvořte soubor `mint-nft.js` a přidejte následující řádky kódu:
+
+```js
+require("dotenv").config()
+const API_URL = process.env.API_URL
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(API_URL)
+```
+
+## Krok 3: Získejte ABI svého kontraktu {#contract-abi}
+
+Naše ABI kontraktu (Application Binary Interface) je rozhraní pro interakci s naším chytrým kontraktem. Více informací o ABI kontraktů se můžete dozvědět [zde](https://docs.alchemyapi.io/alchemy/guides/eth_getlogs#what-are-ab-is). Hardhat pro nás automaticky generuje ABI a ukládá ho do souboru `MyNFT.json`. Abychom to mohli použít, budeme muset analyzovat obsah přidáním následujících řádků kódu do našeho souboru `mint-nft.js`:
+
+```js
+const contract = require("../artifacts/contracts/MyNFT.sol/MyNFT.json")
+```
+
+Pokud chcete vidět ABI, můžete si ho vytisknout do konzole:
+
+```js
+console.log(JSON.stringify(contract.abi))
+```
+
+Chcete-li spustit `mint-nft.js` a vidět své ABI vytištěné v konzoli, přejděte do terminálu a spusťte:
+
+```js
+node scripts/mint-nft.js
+```
+
+## Krok 4: Nakonfigurujte metadata pro své NFT pomocí IPFS {#config-meta}
+
+Pokud si pamatujete z našeho tutoriálu v části 1, naše funkce chytrého kontraktu `mintNFT` přijímá parametr tokenURI, který by se měl přeložit na dokument JSON popisující metadata NFT – což je to, co NFT skutečně oživuje a umožňuje mu mít konfigurovatelné vlastnosti, jako je název, popis, obrázek a další atributy.
+
+> _Interplanetary File System (IPFS) je decentralizovaný protokol a peer-to-peer síť pro ukládání a sdílení dat v distribuovaném souborovém systému._
+
+Použijeme Pinata, pohodlné IPFS API a sadu nástrojů, k uložení našeho NFT aktiva a metadat, abychom zajistili, že naše NFT je skutečně decentralizované. Pokud nemáte účet Pinata, zaregistrujte si bezplatný účet [zde](https://app.pinata.cloud) a dokončete kroky pro ověření e-mailu.
+
+Jakmile si vytvoříte účet:
+
+- Přejděte na stránku „Soubory“ a klikněte na modré tlačítko „Nahrát“ v levém horním rohu stránky.
+
+- Nahrajte obrázek do Pinaty – to bude obrazové aktivum pro vaše NFT. Aktivum si můžete pojmenovat, jak chcete
+
+- Po nahrání uvidíte informace o souboru v tabulce na stránce „Soubory“. Uvidíte také sloupec CID. CID můžete zkopírovat kliknutím na tlačítko kopírovat vedle něj. Váš nahraný soubor si můžete prohlédnout na: `https://gateway.pinata.cloud/ipfs/`. Obrázek, který jsme použili, najdete na IPFS například [zde](https://gateway.pinata.cloud/ipfs/QmZdd5KYdCFApWn7eTZJ1qgJu18urJrP9Yh1TZcZrZxxB5).
+
+Pro vizuálněji založené studenty jsou výše uvedené kroky shrnuty zde:
+
+
+
+Nyní budeme chtít nahrát do Pinaty ještě jeden dokument. Ale než to uděláme, musíme ho vytvořit!
+
+Ve svém kořenovém adresáři vytvořte nový soubor s názvem `nft-metadata.json` a přidejte následující kód json:
+
+```json
+{
+ "attributes": [
+ {
+ "trait_type": "Breed",
+ "value": "Maltipoo"
+ },
+ {
+ "trait_type": "Eye color",
+ "value": "Mocha"
+ }
+ ],
+ "description": "The world's most adorable and sensitive pup.",
+ "image": "ipfs://QmWmvTJmJU3pozR9ZHFmQC2DNDwi2XJtf3QGyYiiagFSWb",
+ "name": "Ramses"
+}
+```
+
+Data v jsonu si můžete libovolně měnit. Do sekce atributů můžete přidávat nebo z ní odebírat. Nejdůležitější je, abyste se ujistili, že pole s obrázkem ukazuje na umístění vašeho obrázku na IPFS – jinak bude vaše NFT obsahovat fotku (velmi roztomilého!) psa.
+
+Jakmile dokončíte úpravu souboru JSON, uložte ho a nahrajte na Pinata podle stejných kroků, jaké jsme provedli při nahrávání obrázku.
+
+
+
+## Krok 5: Vytvořte instanci svého kontraktu {#instance-contract}
+
+Nyní, abychom mohli s naším kontraktem interagovat, musíme v našem kódu vytvořit jeho instanci. K tomu budeme potřebovat účet našeho kontraktu, který můžeme získat z nasazení nebo na [Blockscoutu](https://eth-sepolia.blockscout.com/) vyhledáním adresy, kterou jste použili k nasazení kontraktu.
+
+
+
+Ve výše uvedeném příkladu je účet našeho kontraktu 0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778.
+
+Dále použijeme metodu [kontraktu](https://docs.web3js.org/api/web3-eth-contract/class/Contract) Web3 k vytvoření našeho kontraktu pomocí ABI a adresy. Do souboru `mint-nft.js` přidejte následující:
+
+```js
+const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778"
+
+const nftContract = new web3.eth.Contract(contract.abi, contractAddress)
+```
+
+## Krok 6: Aktualizujte soubor `.env` {#update-env}
+
+Nyní, abychom mohli vytvářet a odesílat transakce do řetězce Etherea, použijeme adresu vašeho veřejného účtu Ethereum k získání nonce účtu (vysvětlíme níže).
+
+Přidejte svůj veřejný klíč do souboru `.env` – pokud jste dokončili 1. část tutoriálu, náš soubor `.env` by nyní měl vypadat takto:
+
+```js
+API_URL = "https://eth-sepolia.g.alchemy.com/v2/váš-api-klíč"
+PRIVATE_KEY = "adresa-vašeho-privátního-účtu"
+PUBLIC_KEY = "adresa-vašeho-veřejného-účtu"
+```
+
+## Krok 7: Vytvořte transakci {#create-txn}
+
+Nejprve definujme funkci s názvem `mintNFT(tokenData)` a vytvořme naši transakci následujícím postupem:
+
+1. Získejte svůj _PRIVATE_KEY_ a _PUBLIC_KEY_ ze souboru `.env`.
+
+2. Dále budeme muset zjistit nonce účtu. Specifikace nonce se používá ke sledování počtu transakcí odeslaných z vaší adresy – což potřebujeme z bezpečnostních důvodů a k zabránění [útokům opětovného přehrání](https://docs.alchemyapi.io/resources/blockchain-glossary#account-nonce). K získání počtu transakcí odeslaných z vaší adresy použijeme [getTransactionCount](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_gettransactioncount).
+
+3. Nakonec nastavíme naši transakci s následujícími informacemi:
+
+- `'from': PUBLIC_KEY` – Původ naší transakce je naše veřejná adresa
+
+- `'to': contractAddress` – Kontrakt, se kterým chceme interagovat a odeslat transakci
+
+- `'nonce': nonce` – Nonce účtu s počtem transakcí odeslaných z naší adresy
+
+- `'gas': estimatedGas` – Odhadované palivo potřebné k dokončení transakce
+
+- `'data': nftContract.methods.mintNFT(PUBLIC_KEY, md).encodeABI()` – Výpočet, který chceme v této transakci provést – což je v tomto případě ražba NFT
+
+Váš soubor `mint-nft.js` by nyní měl vypadat takto:
+
+```js
+ require('dotenv').config();
+ const API_URL = process.env.API_URL;
+ const PUBLIC_KEY = process.env.PUBLIC_KEY;
+ const PRIVATE_KEY = process.env.PRIVATE_KEY;
+
+ const { createAlchemyWeb3 } = require("@alch/alchemy-web3");
+ const web3 = createAlchemyWeb3(API_URL);
+
+ const contract = require("../artifacts/contracts/MyNFT.sol/MyNFT.json");
+ const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778";
+ const nftContract = new web3.eth.Contract(contract.abi, contractAddress);
+
+ async function mintNFT(tokenURI) {
+ const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, 'latest'); //získat nejnovější nonce
+
+ //transakce
+ const tx = {
+ 'from': PUBLIC_KEY,
+ 'to': contractAddress,
+ 'nonce': nonce,
+ 'gas': 500000,
+ 'data': nftContract.methods.mintNFT(PUBLIC_KEY, tokenURI).encodeABI()
+ };
+ }
+```
+
+## Krok 8: Podepište transakci {#sign-txn}
+
+Nyní, když jsme vytvořili naši transakci, musíme ji podepsat, abychom ji mohli odeslat. Zde použijeme náš privátní klíč.
+
+`web3.eth.sendSignedTransaction` nám poskytne haš transakce, který můžeme použít k ujištění, že naše transakce byla vytěžena a nebyla sítí zahozená. Všimnete si, že v sekci podepisování transakcí jsme přidali kontrolu chyb, abychom věděli, zda naše transakce proběhla úspěšně.
+
+```js
+require("dotenv").config()
+const API_URL = process.env.API_URL
+const PUBLIC_KEY = process.env.PUBLIC_KEY
+const PRIVATE_KEY = process.env.PRIVATE_KEY
+
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(API_URL)
+
+const contract = require("../artifacts/contracts/MyNFT.sol/MyNFT.json")
+const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778"
+const nftContract = new web3.eth.Contract(contract.abi, contractAddress)
+
+async function mintNFT(tokenURI) {
+ const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") //získat nejnovější nonce
+
+ //transakce
+ const tx = {
+ from: PUBLIC_KEY,
+ to: contractAddress,
+ nonce: nonce,
+ gas: 500000,
+ data: nftContract.methods.mintNFT(PUBLIC_KEY, tokenURI).encodeABI(),
+ }
+
+ const signPromise = web3.eth.accounts.signTransaction(tx, PRIVATE_KEY)
+ signPromise
+ .then((signedTx) => {
+ web3.eth.sendSignedTransaction(
+ signedTx.rawTransaction,
+ function (err, hash) {
+ if (!err) {
+ console.log(
+ "Haš vaší transakce je: ",
+ hash,
+ "\nZkontrolujte Mempool Alchemy a zobrazte stav vaší transakce!"
+ )
+ } else {
+ console.log(
+ "Při odesílání transakce se něco pokazilo:",
+ err
+ )
+ }
+ }
+ )
+ })
+ .catch((err) => {
+ console.log(" Promise selhal:", err)
+ })
+}
+```
+
+## Krok 9: Zavolejte `mintNFT` a spusťte node `mint-nft.js` {#call-mintnft-fn}
+
+Pamatujete si na `metadata.json`, který jste nahráli do Pinaty? Získejte jeho hašovací kód z Pinaty a předejte následující jako parametr funkci `mintNFT` `https://gateway.pinata.cloud/ipfs/`
+
+Zde je návod, jak získat hašovací kód:
+
+_Jak získat hašovací kód metadat vašeho NFT na Pinatě_
+
+> Dvakrát zkontrolujte, že hašovací kód, který jste zkopírovali, odkazuje na váš **metadata.json** načtením `https://gateway.pinata.cloud/ipfs/` do samostatného okna. Stránka by měla vypadat podobně jako na snímku obrazovky níže:
+
+_Vaše stránka by měla zobrazovat metadata json_
+
+Celkově by váš kód měl vypadat nějak takto:
+
+```js
+require("dotenv").config()
+const API_URL = process.env.API_URL
+const PUBLIC_KEY = process.env.PUBLIC_KEY
+const PRIVATE_KEY = process.env.PRIVATE_KEY
+
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(API_URL)
+
+const contract = require("../artifacts/contracts/MyNFT.sol/MyNFT.json")
+const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778"
+const nftContract = new web3.eth.Contract(contract.abi, contractAddress)
+
+async function mintNFT(tokenURI) {
+ const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") //získat nejnovější nonce
+
+ //transakce
+ const tx = {
+ from: PUBLIC_KEY,
+ to: contractAddress,
+ nonce: nonce,
+ gas: 500000,
+ data: nftContract.methods.mintNFT(PUBLIC_KEY, tokenURI).encodeABI(),
+ }
+
+ const signPromise = web3.eth.accounts.signTransaction(tx, PRIVATE_KEY)
+ signPromise
+ .then((signedTx) => {
+ web3.eth.sendSignedTransaction(
+ signedTx.rawTransaction,
+ function (err, hash) {
+ if (!err) {
+ console.log(
+ "Haš vaší transakce je: ",
+ hash,
+ "\nZkontrolujte Mempool Alchemy a zobrazte stav vaší transakce!"
+ )
+ } else {
+ console.log(
+ "Při odesílání transakce se něco pokazilo:",
+ err
+ )
+ }
+ }
+ )
+ })
+ .catch((err) => {
+ console.log("Promise selhal:", err)
+ })
+}
+
+mintNFT("ipfs://QmYueiuRNmL4MiA2GwtVMm6ZagknXnSpQnB3z2gWbz36hP")
+```
+
+Nyní spusťte `node scripts/mint-nft.js` pro nasazení vašeho NFT. Po několika sekundách byste měli v terminálu vidět odpověď podobnou této:
+
+ ```
+ Haš vaší transakce je: 0x301791fdf492001fcd9d5e5b12f3aa1bbbea9a88ed24993a8ab2cdae2d06e1e8
+
+ Zkontrolujte Mempool Alchemy a zobrazte stav vaší transakce!
+ ```
+
+Dále navštivte svůj [mempool Alchemy](https://dashboard.alchemyapi.io/mempool) a podívejte se na stav vaší transakce (zda je čekající, vytěžená, nebo ji síť zahodila). Pokud byla vaše transakce zahozená, je také užitečné zkontrolovat [Blockscout](https://eth-sepolia.blockscout.com/) a vyhledat haš vaší transakce.
+
+_Zobrazení haše vaší NFT transakce na Etherscanu_
+
+A to je vše! Nyní jste nasadili A vyrazili NFT na blockchainu Etherea `](https://any.site/ipfs/bafybeifqka2odrne5b6l5guthqvbxu4pujko2i6rx2zslvr3qxs6u5o7im) na jakékoli stránce a získáte tento obsah, poskytovaný decentralizovaným způsobem.
+
+## Nevýhody {#drawbacks}
+
+Soubory IPFS nelze spolehlivě mazat, takže dokud upravujete své uživatelské rozhraní, je pravděpodobně nejlepší jej buď nechat centralizovaný, nebo použít [Interplanetární jmenný systém (IPNS)](https://docs.ipfs.tech/concepts/ipns/#mutability-in-ipfs), systém, který poskytuje proměnlivost nad IPFS. Samozřejmě, vše, co je proměnlivé, může být cenzurováno, v případě IPNS nátlakem na osobu s privátním klíčem, kterému odpovídá.
+
+Některé balíčky mají navíc s IPFS problém, takže pokud je vaše webová stránka velmi složitá, nemusí to být dobré řešení. A samozřejmě cokoli, co se spoléhá na integraci serveru, nelze decentralizovat jen tím, že klientská strana bude na IPFS.
+
+## Závěr {#conclusion}
+
+Stejně jako vám Ethereum umožňuje decentralizovat databázové a obchodní logické aspekty vaší dapp, IPFS vám umožňuje decentralizovat uživatelské rozhraní. To vám umožní uzavřít další vektor útoku proti vaší dapp.
+
+[Více z mé práce najdete zde](https://cryptodocguy.pro/).
diff --git a/public/content/translations/cs/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md b/public/content/translations/cs/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md
new file mode 100644
index 00000000000..d1a1061251d
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md
@@ -0,0 +1,111 @@
+---
+title: Nastartujte vývoj frontendu vaší dapp pomocí create-eth-app
+description: Přehled použití create-eth-app a jeho funkcí
+author: "Markus Waas"
+tags:
+ [
+ "frontend",
+ "javascript",
+ "ethers.js",
+ "the graph",
+ "defi"
+ ]
+skill: beginner
+lang: cs
+published: 2020-04-27
+source: soliditydeveloper.com
+sourceUrl: https://soliditydeveloper.com/create-eth-app
+---
+
+Minule jsme se podívali na [celkový obraz Solidity](https://soliditydeveloper.com/solidity-overview-2020) a již zmínili [create-eth-app](https://github.com/PaulRBerg/create-eth-app). Nyní se dozvíte, jak jej používat, jaké funkce jsou integrovány a jaké jsou další nápady na jeho rozšíření. Tato aplikace, kterou založil Paul Razvan Berg, zakladatel [Sablier](http://sablier.com/), nastartuje váš vývoj frontendu a přináší několik volitelných integrací, ze kterých si můžete vybrat.
+
+## Instalace {#installation}
+
+Instalace vyžaduje Yarn 0.25 nebo vyšší (`npm install yarn --global`). Je to tak jednoduché jako spuštění:
+
+```bash
+yarn create eth-app my-eth-app
+cd my-eth-app
+yarn react-app:start
+```
+
+Pod kapotou používá [create-react-app](https://github.com/facebook/create-react-app). Chcete-li zobrazit svou aplikaci, otevřete `http://localhost:3000/`. Až budete připraveni k nasazení do produkčního prostředí, vytvořte minifikovaný balíček pomocí yarn build. Jedním ze snadných způsobů, jak to hostovat, je [Netlify](https://www.netlify.com/). Můžete si vytvořit repozitář na GitHubu, přidat ho do Netlify, nastavit příkaz pro sestavení a máte hotovo! Vaše aplikace bude hostovaná a použitelná pro všechny. A to vše zdarma.
+
+## Vlastnosti {#features}
+
+### React a create-react-app {#react--create-react-app}
+
+Především srdce aplikace: React a všechny další funkce, které přináší _create-react-app_. Použití pouze tohoto je skvělá volba, pokud nechcete integrovat Ethereum. Samotný [React](https://react.dev/) velmi usnadňuje vytváření interaktivních uživatelských rozhraní. Možná není tak přívětivý pro začátečníky jako [Vue](https://vuejs.org/), ale stále je nejpoužívanější, má více funkcí a hlavně tisíce dalších knihoven, ze kterých si můžete vybrat. _create-react-app_ také velmi usnadňuje začátek a zahrnuje:
+
+- Podporu syntaxe React, JSX, ES6, TypeScript a Flow.
+- Jazyková rozšíření nad rámec ES6, jako je operátor rozšiřování objektů (object spread operator).
+- Automaticky prefixované CSS, takže nepotřebujete -webkit- ani jiné prefixy.
+- Rychlý interaktivní spouštěč jednotkových testů s vestavěnou podporou pro reportování pokrytí.
+- Živý vývojový server, který varuje před běžnými chybami.
+- Sestavovací skript pro sbalení JS, CSS a obrázků pro produkci, s haši a sourcemapy.
+
+Konkrétně _create-eth-app_ využívá nové [hooks effects](https://legacy.reactjs.org/docs/hooks-effect.html). Metoda pro psaní výkonných, ale velmi malých takzvaných funkcionálních komponent. Jak se používají v _create-eth-app_ se dozvíte níže v sekci o Apollo.
+
+### Yarn Workspaces {#yarn-workspaces}
+
+[Yarn Workspaces](https://classic.yarnpkg.com/en/docs/workspaces/) vám umožňují mít více balíčků, ale spravovat je všechny z kořenového adresáře a instalovat závislosti pro všechny najednou pomocí `yarn install`. To dává smysl zejména pro menší doplňkové balíčky, jako je správa adres/ABI chytrých kontraktů (informace o tom, kde jste nasadili které chytré kontrakty a jak s nimi komunikovat) nebo integrace The Graph, které jsou obě součástí `create-eth-app`.
+
+### ethers.js {#ethersjs}
+
+Zatímco [Web3](https://docs.web3js.org/) se stále používá nejvíce, [ethers.js](https://docs.ethers.io/) se v posledním roce stává stále populárnější alternativou a je integrován do _create-eth-app_. Můžete s ním pracovat, změnit ho na Web3 nebo zvážit upgrade na [ethers.js v5](https://docs.ethers.org/v5/), který je téměř venku z beta verze.
+
+### The Graph {#the-graph}
+
+[GraphQL](https://graphql.org/) je alternativní způsob práce s daty ve srovnání s [Restful API](https://restfulapi.net/). Mají několik výhod oproti Restful API, zejména pro decentralizovaná blockchainová data. Pokud vás zajímají důvody, podívejte se na [GraphQL Will Power the Decentralized Web](https://medium.com/graphprotocol/graphql-will-power-the-decentralized-web-d7443a69c69a).
+
+Obvykle byste získávali data přímo z vašeho chytrého kontraktu. Chcete si přečíst čas posledního obchodu? Stačí zavolat `MyContract.methods.latestTradeTime().call()`, které získá data z uzlu Ethereum do vaší dapp. Ale co když potřebujete stovky různých datových bodů? To by vedlo ke stovkám načítání dat z uzlu, přičemž každé by vyžadovalo [RTT](https://wikipedia.org/wiki/Round-trip_delay_time), což by vaši dapp zpomalilo a zneefektivnilo. Jedním z řešení může být funkce pro hromadné načítání (fetcher call) uvnitř vašeho kontraktu, která vrací více dat najednou. Ne vždy je to ale ideální.
+
+A pak by vás mohla zajímat i historická data. Chcete znát nejen čas posledního obchodu, ale časy všech obchodů, které jste kdy sami uskutečnili. Použijte balíček subgraphu _create-eth-app_, přečtěte si [dokumentaci](https://thegraph.com/docs/en/subgraphs/developing/creating/starting-your-subgraph) a přizpůsobte jej svým vlastním kontraktům. Pokud hledáte oblíbené chytré kontrakty, může pro ně již existovat subgraph. Podívejte se na [průzkumníka subgraphů](https://thegraph.com/explorer/).
+
+Jakmile máte subgraph, můžete ve své dapp napsat jeden jednoduchý dotaz, který načte všechna důležitá blockchainová data, která potřebujete, včetně těch historických, a to pouze jedním načtením.
+
+### Apollo {#apollo}
+
+Díky integraci [Apollo Boost](https://www.apollographql.com/docs/react/get-started/) můžete snadno integrovat The Graph do své React dapp. Zejména při použití [React hooks and Apollo](https://www.apollographql.com/blog/apollo-client-now-with-react-hooks) je načítání dat tak jednoduché jako napsání jediného dotazu GraphQL ve vaší komponentě:
+
+```js
+const { loading, error, data } = useQuery(myGraphQlQuery)
+
+React.useEffect(() => {
+ if (!loading && !error && data) {
+ console.log({ data })
+ }
+}, [loading, error, data])
+```
+
+## Šablony {#templates}
+
+Navíc si můžete vybrat z několika různých šablon. Zatím můžete použít integraci Aave, Compound, UniSwap nebo Sablier. Všechny přidávají důležité adresy servisních chytrých kontraktů spolu s předpřipravenými integracemi subgraphů. Stačí přidat šablonu do příkazu pro vytvoření, například `yarn create eth-app my-eth-app --with-template aave`.
+
+### Aave {#aave}
+
+[Aave](https://aave.com/) je decentralizovaný trh s půjčováním peněz. Vkladatelé poskytují trhu likviditu, aby získali pasivní příjem, zatímco dlužníci si mohou půjčovat pomocí kolaterálu. Jednou z jedinečných funkcí Aave jsou [rychlé půjčky (flash loans)](https://aave.com/docs/developers/flash-loans), které vám umožní půjčit si peníze bez jakéhokoli kolaterálu, pokud půjčku vrátíte v rámci jedné transakce. To může být užitečné například pro získání dodatečné hotovosti při arbitrážním obchodování.
+
+Obchodované tokeny, které vám vydělávají úroky, se nazývají _aTokens_.
+
+Když se rozhodnete integrovat Aave s _create-eth-app_, získáte [integraci subgraphu](https://docs.aave.com/developers/getting-started/using-graphql). Aave používá The Graph a již vám poskytuje několik subgraphů připravených k použití na [Ropstenu](https://thegraph.com/explorer/subgraph/aave/protocol-ropsten) a [mainnetu](https://thegraph.com/explorer/subgraph/aave/protocol) v [surové](https://thegraph.com/explorer/subgraph/aave/protocol-raw) nebo [formátované](https://thegraph.com/explorer/subgraph/aave/protocol) podobě.
+
+
+
+### Compound {#compound}
+
+[Compound](https://compound.finance/) je podobný Aave. Integrace již zahrnuje nový [Compound v2 Subgraph](https://medium.com/graphprotocol/https-medium-com-graphprotocol-compound-v2-subgraph-highlight-a5f38f094195). Tokeny, které zde vydělávají úroky, se překvapivě nazývají _cTokens_.
+
+### Uniswap {#uniswap}
+
+[Uniswap](https://uniswap.exchange/) je decentralizovaná burza (DEX). Poskytovatelé likvidity mohou vydělávat poplatky poskytováním požadovaných tokenů nebo etheru pro obě strany obchodu. Je široce používána a proto má jednu z nejvyšších likvidit pro velmi širokou škálu tokenů. Můžete ji snadno integrovat do své dapp, abyste například umožnili uživatelům směnit jejich ETH za DAI.
+
+Bohužel v době psaní tohoto článku je integrace pouze pro Uniswap v1, a nikoli pro [právě vydanou v2](https://uniswap.org/blog/uniswap-v2/).
+
+### Sablier {#sablier}
+
+[Sablier](https://sablier.com/) umožňuje uživatelům streamování plateb. Místo jediné výplaty dostáváte peníze neustále bez další administrace po úvodním nastavení. Integrace zahrnuje [vlastní subgraph](https://thegraph.com/explorer/subgraph/sablierhq/sablier).
+
+## Co dál? {#whats-next}
+
+Pokud máte dotazy ohledně _create-eth-app_, přejděte na [komunitní server Sablier](https://discord.gg/bsS8T47), kde se můžete spojit s autory _create-eth-app_. Jako jedny z prvních dalších kroků můžete chtít integrovat UI framework jako [Material UI](https://mui.com/material-ui/), napsat GraphQL dotazy pro data, která skutečně potřebujete, a nastavit nasazení.
diff --git a/public/content/translations/cs/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md b/public/content/translations/cs/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md
new file mode 100644
index 00000000000..58ed2e601c1
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md
@@ -0,0 +1,269 @@
+---
+title: Naučte se základní témata Etherea pomocí SQL
+description: Tento tutoriál pomáhá čtenářům pochopit základní koncepty Etherea, včetně transakcí, bloků a paliva, a to pomocí dotazování na onchain data pomocí jazyka SQL (Structured Query Language).
+author: "Paul Apivat"
+tags: [ "SQL", "Dotazování", "Transakce" ]
+skill: beginner
+lang: cs
+published: 2021-05-11
+source: paulapivat.com
+sourceUrl: https://paulapivat.com/post/query_ethereum/
+---
+
+Mnoho tutoriálů o Ethereu se zaměřuje na vývojáře, ale chybí vzdělávací zdroje pro datové analytiky nebo pro lidi, kteří chtějí vidět onchain data bez spuštění klienta nebo uzlu.
+
+Tento tutoriál pomáhá čtenářům pochopit základní koncepty Etherea, včetně transakcí, bloků a paliva, a to pomocí dotazování na onchain data pomocí jazyka SQL (structured query language) přes rozhraní poskytované [Dune Analytics](https://dune.com/).
+
+Onchain data nám může pomoci pochopit Ethereum, síť a jako ekonomiku pro výpočetní výkon a mělo by sloužit jako základ pro pochopení výzev, kterým Ethereum dnes čelí (tj. rostoucí ceny paliva) a co je důležitější, diskusí o řešeních škálování.
+
+### Transakce {#transactions}
+
+Cesta uživatele v síti Ethereum začíná inicializací účtu ovládaného uživatelem nebo entity se zůstatkem v ETH. Existují dva typy účtů – ovládané uživatelem nebo chytrým kontraktem (viz [ethereum.org](/developers/docs/accounts/)).
+
+Jakýkoli účet lze zobrazit v prohlížeči bloků, jako je [Etherscan](https://etherscan.io/) nebo [Blockscout](https://eth.blockscout.com/). Prohlížeče bloků jsou portálem k datům Etherea. Zobrazují v reálném čase data o blocích, transakcích, těžařích, účtech a dalších onchain aktivitách (viz [zde](/developers/docs/data-and-analytics/block-explorers/)).
+
+Uživatel si však může přát dotazovat se na data přímo, aby si ověřil informace poskytované externími prohlížeči bloků. [Dune Analytics](https://dune.com/) poskytuje tuto možnost každému, kdo má alespoň nějaké znalosti SQL.
+
+Pro informaci, účet chytrého kontraktu Nadace Ethereum (EF) si můžete prohlédnout na [Blockscout](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe).
+
+Jedna věc, kterou je třeba poznamenat, je, že všechny účty, včetně účtu EF, mají veřejnou adresu, kterou lze použít k odesílání a přijímání transakcí.
+
+Zůstatek na účtu na Etherscanu se skládá z běžných transakcí a interních transakcí. Interní transakce, navzdory svému názvu, nejsou _skutečnými_ transakcemi, které mění stav řetězce. Jedná se o převody hodnot iniciované provedením kontraktu ([zdroj](https://ethereum.stackexchange.com/questions/3417/how-to-get-contract-internal-transactions)). Vzhledem k tomu, že interní transakce nemají podpis, **nejsou** zahrnuty v blockchainu a nelze je dotazovat pomocí Dune Analytics.
+
+Tento tutoriál se proto zaměří na běžné transakce. Lze se na ně dotazovat takto:
+
+```sql
+WITH temp_table AS (
+SELECT
+ hash,
+ block_number,
+ block_time,
+ "from",
+ "to",
+ value / 1e18 AS ether,
+ gas_used,
+ gas_price / 1e9 AS gas_price_gwei
+FROM ethereum."transactions"
+WHERE "to" = '\xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe'
+ORDER BY block_time DESC
+)
+SELECT
+ hash,
+ block_number,
+ block_time,
+ "from",
+ "to",
+ ether,
+ (gas_used * gas_price_gwei) / 1e9 AS txn_fee
+FROM temp_table
+```
+
+Tím získáte stejné informace, jaké jsou uvedeny na stránce transakcí na Etherscanu. Pro srovnání, zde jsou dva zdroje:
+
+#### Etherscan {#etherscan}
+
+
+
+[Stránka kontraktu EF na Blockscoutu.](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe)
+
+#### Dune Analytics {#dune-analytics}
+
+
+
+Řídicí panel najdete [zde](https://dune.com/paulapivat/Learn-Ethereum). Kliknutím na tabulku zobrazíte dotaz (viz také výše).
+
+### Rozbor transakcí {#breaking_down_transactions}
+
+Odeslaná transakce obsahuje několik informací, včetně ([zdroj](/developers/docs/transactions/)):
+
+- **Příjemce**: Přijímající adresa (v dotazu jako \"to\")
+- **Podpis**: Zatímco transakci podepisují soukromé klíče odesílatele, my můžeme pomocí SQL dotazovat veřejnou adresu odesílatele (\"from\").
+- **Hodnota**: Jedná se o množství převedených ETH (viz sloupec `ether`).
+- **Data**: Jedná se o libovolná data, která byla zahašována (viz sloupec `data`)
+- **gasLimit** – maximální množství jednotek paliva, které může být transakcí spotřebováno. Jednotky paliva představují výpočetní kroky
+- **maxPriorityFeePerGas** – maximální množství paliva, které bude zahrnuto jako spropitné pro těžaře
+- **maxFeePerGas** – maximální množství paliva, které je uživatel ochoten zaplatit za transakci (včetně baseFeePerGas a maxPriorityFeePerGas)
+
+Tyto konkrétní informace můžeme dotazovat pro transakce na veřejnou adresu Nadace Ethereum:
+
+```sql
+SELECT
+ "to",
+ "from",
+ value / 1e18 AS ether,
+ data,
+ gas_limit,
+ gas_price / 1e9 AS gas_price_gwei,
+ gas_used,
+ ROUND(((gas_used / gas_limit) * 100),2) AS gas_used_pct
+FROM ethereum."transactions"
+WHERE "to" = '\xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe'
+ORDER BY block_time DESC
+```
+
+### Bloky {#blocks}
+
+Každá transakce změní stav Ethereum Virtual Machine ([EVM](/developers/docs/evm/)) ([zdroj](/developers/docs/transactions/)). Transakce jsou vysílány do sítě, aby byly ověřeny a zahrnuty do bloku. Každá transakce je spojena s číslem bloku. Abychom viděli data, mohli bychom se dotázat na konkrétní číslo bloku: 12396854 (nejnovější blok mezi transakcemi Nadace Ethereum v době psaní tohoto článku, 11/5/21).
+
+Když se navíc dotážeme na další dva bloky, uvidíme, že každý blok obsahuje haš předchozího bloku (tj. rodičovský haš), což ukazuje, jak se blockchain tvoří.
+
+Každý blok obsahuje odkaz na svůj rodičovský blok. To je ukázáno níže mezi sloupci `hash` a `parent_hash` ([zdroj](/developers/docs/blocks/)):
+
+
+
+Zde je [dotaz](https://dune.com/queries/44856/88292) na Dune Analytics:
+
+```sql
+SELECT
+ time,
+ number,
+ hash,
+ parent_hash,
+ nonce
+FROM ethereum."blocks"
+WHERE "number" = 12396854 OR "number" = 12396855 OR "number" = 12396856
+LIMIT 10
+```
+
+Blok můžeme prozkoumat dotazováním na čas, číslo bloku, obtížnost, haš, rodičovský haš a nonce.
+
+Jediná věc, kterou tento dotaz nepokrývá, je _seznam transakcí_, který vyžaduje samostatný dotaz níže, a _kořen stavu_. Plný nebo archivní uzel ukládá všechny transakce a přechody stavů, což klientům umožňuje kdykoli dotazovat stav řetězce. Protože to vyžaduje velký úložný prostor, můžeme oddělit data řetězce od dat stavu:
+
+- Data řetězce (seznam bloků, transakcí)
+- Data stavu (výsledek přechodu stavu každé transakce)
+
+Kořen stavu spadá do druhé kategorie a je _implicitními_ daty (není uložen onchain), zatímco data řetězce jsou explicitní a uložena na samotném řetězci ([zdroj](https://ethereum.stackexchange.com/questions/359/where-is-the-state-data-stored)).
+
+V tomto tutoriálu se zaměříme na onchain data, na která _se lze_ dotazovat pomocí SQL přes Dune Analytics.
+
+Jak bylo uvedeno výše, každý blok obsahuje seznam transakcí, které můžeme dotazovat filtrováním pro konkrétní blok. Zkusíme nejnovější blok, 12396854:
+
+```sql
+SELECT * FROM ethereum."transactions"
+WHERE block_number = 12396854
+ORDER BY block_time DESC`
+```
+
+Zde je výstup SQL na Dune:
+
+
+
+Tento jediný blok přidaný do řetězce mění stav Ethereum Virtual Machine ([EVM](/developers/docs/evm/)). Najednou se ověřují desítky, někdy i stovky transakcí. V tomto konkrétním případě bylo zahrnuto 222 transakcí.
+
+Abychom viděli, kolik jich bylo skutečně úspěšných, přidáme další filtr pro počítání úspěšných transakcí:
+
+```sql
+WITH temp_table AS (
+ SELECT * FROM ethereum."transactions"
+ WHERE block_number = 12396854 AND success = true
+ ORDER BY block_time DESC
+)
+SELECT
+ COUNT(success) AS num_successful_txn
+FROM temp_table
+```
+
+Pro blok 12396854 bylo z celkových 222 transakcí úspěšně ověřeno 204:
+
+
+
+Požadavky na transakce se objevují desítkykrát za sekundu, ale bloky jsou zapisovány přibližně jednou za 15 sekund ([zdroj](/developers/docs/blocks/)).
+
+Abychom viděli, že se jeden blok vyprodukuje přibližně každých 15 sekund, můžeme vzít počet sekund za den (86400) a vydělit jej 15, abychom získali odhadovaný průměrný počet bloků za den (~ 5760).
+
+Graf pro vyprodukované bloky Etherea za den (2016 - současnost) je:
+
+
+
+Průměrný počet denně vyprodukovaných bloků za toto období je ~5 874:
+
+
+
+Dotazy jsou:
+
+```sql
+# dotaz pro vizualizaci počtu denně vytvořených bloků od roku 2016
+
+SELECT
+ DATE_TRUNC('day', time) AS dt,
+ COUNT(*) AS block_count
+FROM ethereum."blocks"
+GROUP BY dt
+OFFSET 1
+
+# průměrný počet denně vytvořených bloků
+
+WITH temp_table AS (
+SELECT
+ DATE_TRUNC('day', time) AS dt,
+ COUNT(*) AS block_count
+FROM ethereum."blocks"
+GROUP BY dt
+OFFSET 1
+)
+SELECT
+ AVG(block_count) AS avg_block_count
+FROM temp_table
+```
+
+Průměrný počet denně vytvořených bloků od roku 2016 je mírně nad tímto číslem, a to 5 874. Alternativně, vydělením 86 400 sekund 5 874 průměrnými bloky získáme 14,7 sekundy, tedy přibližně jeden blok každých 15 sekund.
+
+### Gas {#gas}
+
+Bloky mají omezenou velikost. Maximální velikost bloku je dynamická a liší se podle poptávky v síti mezi 12 500 000 a 25 000 000 jednotkami. Limity jsou nutné k tomu, aby se zabránilo libovolně velkým blokům, které by zatěžovaly plné uzly z hlediska požadavků na diskový prostor a rychlost ([zdroj](/developers/docs/blocks/)).
+
+Jeden ze způsobů, jak si představit palivový limit bloku, je vnímat ho jako **nabídku** dostupného prostoru v bloku, do kterého se dávkují transakce. Palivový limit bloku lze dotazovat a vizualizovat od roku 2016 do současnosti:
+
+
+
+```sql
+SELECT
+ DATE_TRUNC('day', time) AS dt,
+ AVG(gas_limit) AS avg_block_gas_limit
+FROM ethereum."blocks"
+GROUP BY dt
+OFFSET 1
+```
+
+Dále je tu skutečné množství paliva použitého denně k placení za výpočty prováděné v řetězci Ethereum (tj. odeslání transakce, volání chytrého kontraktu, ražba NFT). Toto je **poptávka** po dostupném prostoru v bloku Etherea:
+
+
+
+```sql
+SELECT
+ DATE_TRUNC('day', time) AS dt,
+ AVG(gas_used) AS avg_block_gas_used
+FROM ethereum."blocks"
+GROUP BY dt
+OFFSET 1
+```
+
+Můžeme také postavit tyto dva grafy vedle sebe, abychom viděli, jak se shoduje **poptávka a nabídka**:
+
+
+
+Proto můžeme ceny paliva chápat jako funkci poptávky po prostoru v bloku Etherea při dané dostupné nabídce.
+
+Nakonec bychom se mohli chtít dotázat na průměrné denní ceny paliva pro řetězec Ethereum, nicméně to by vedlo k obzvláště dlouhé době dotazu, takže náš dotaz omezíme na průměrné množství paliva zaplaceného za transakci Nadací Ethereum.
+
+
+
+Můžeme vidět ceny paliva zaplacené za všechny transakce provedené na adresu Nadace Ethereum v průběhu let. Zde je dotaz:
+
+```sql
+SELECT
+ block_time,
+ gas_price / 1e9 AS gas_price_gwei,
+ value / 1e18 AS eth_sent
+FROM ethereum."transactions"
+WHERE "to" = '\xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe'
+ORDER BY block_time DESC
+```
+
+### Shrnutí {#summary}
+
+Díky tomuto tutoriálu rozumíme základním konceptům Etherea a tomu, jak funguje blockchain Etherea, a to díky dotazování a získávání přehledu o onchain datech.
+
+Řídicí panel, který obsahuje veškerý kód použitý v tomto tutoriálu, naleznete [zde](https://dune.com/paulapivat/Learn-Ethereum).
+
+Pro další využití dat k prozkoumání web3 mě [najdete na Twitteru](https://twitter.com/paulapivat).
diff --git a/public/content/translations/cs/developers/tutorials/logging-events-smart-contracts/index.md b/public/content/translations/cs/developers/tutorials/logging-events-smart-contracts/index.md
new file mode 100644
index 00000000000..861d48ebd8d
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/logging-events-smart-contracts/index.md
@@ -0,0 +1,48 @@
+---
+title: Zaznamenávání dat z chytrých kontraktů pomocí událostí
+description: Úvod do událostí chytrých kontraktů a jak je můžete použít k zaznamenávání dat.
+author: "jdourlens"
+tags:
+ [
+ "smart kontrakt účty",
+ "remix",
+ "solidity",
+ "události"
+ ]
+skill: intermediate
+lang: cs
+published: 2020-04-03
+source: EthereumDev
+sourceUrl: https://ethereumdev.io/logging-data-with-events/
+address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
+---
+
+V Solidity jsou [události](/developers/docs/smart-contracts/anatomy/#events-and-logs) odesílané signály, které mohou chytré kontrakty spouštět. Dapps nebo cokoliv připojené k Ethereum JSON-RPC API může těmto událostem naslouchat a podle toho jednat. Událost může být také indexována, aby byla historie událostí později prohledávatelná.
+
+## Události {#events}
+
+Nejběžnější událostí na blockchainu Etherea v době psaní tohoto článku je událost Transfer, kterou emitují tokeny ERC20, když někdo převádí tokeny.
+
+```solidity
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Podpis události je deklarován uvnitř kódu kontraktu a může být emitován pomocí klíčového slova emit. Například událost převodu zaznamenává, kdo převod odeslal (_from_), komu (_to_) a kolik tokenů bylo převedeno (_value_).
+
+Pokud se vrátíme k našemu chytrému kontraktu Counter a rozhodneme se zaznamenávat každou změnu hodnoty. Protože tento kontrakt nemá být nasazen, ale má sloužit jako základ pro vytvoření jiného kontraktu jeho rozšířením, nazývá se abstraktní kontrakt. V případě našeho příkladu s čítačem by to vypadalo takto:
+
+```solidity
+pragma solidity 0.5.17;\n\ncontract Counter {\n\n event ValueChanged(uint oldValue, uint256 newValue);\n\n // Soukromá proměnná typu unsigned int pro uchování počtu\n uint256 private count = 0;\n\n // Funkce, která zvyšuje náš čítač\n function increment() public {\n count += 1;\n emit ValueChanged(count - 1, count);\n }\n\n // Getter pro získání hodnoty čítače\n function getCount() public view returns (uint256) {\n return count;\n }\n\n}
+```
+
+Všimněte si, že:
+
+- **Řádek 5**: deklarujeme naši událost a co obsahuje, starou a novou hodnotu.
+
+- **Řádek 13**: Když zvýšíme hodnotu naší proměnné count, emitujeme událost.
+
+Pokud nyní kontrakt nasadíme a zavoláme funkci increment, uvidíme, že Remix ji automaticky zobrazí, pokud kliknete na novou transakci v poli s názvem logs.
+
+
+
+Záznamy jsou opravdu užitečné pro ladění vašich chytrých kontraktů, ale jsou také důležité, pokud vytváříte aplikace používané různými lidmi, a usnadňují analytiku pro sledování a pochopení toho, jak je váš chytrý kontrakt používán. Záznamy generované transakcemi se zobrazují v populárních prohlížečích bloků a můžete je například použít k vytvoření offchainových skriptů, které naslouchají specifickým událostem a provádějí akce, když k nim dojde.
diff --git a/public/content/translations/cs/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md b/public/content/translations/cs/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md
new file mode 100644
index 00000000000..9837634df30
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md
@@ -0,0 +1,250 @@
+---
+title: Merkleho důkazy pro integritu dat mimo blockchain
+description: Zajištění integrity dat na blockchainu pro data, která jsou většinou uložena mimo blockchain
+author: Ori Pomerantz
+tags: [ "úložiště" ]
+skill: advanced
+lang: cs
+published: 2021-12-30
+---
+
+## Úvod {#introduction}
+
+V ideálním případě bychom chtěli vše ukládat do úložiště Etherea, které je uloženo na tisících počítačů a má
+extrémně vysokou dostupnost (data nelze cenzurovat) a integritu (data nelze neoprávněně upravovat), ale uložení 32bajtového slova obvykle stojí 20 000 gas. V době psaní tohoto článku se tato cena rovná 6,60 USD. Při 21 centech za bajt je to pro mnoho využití příliš drahé.
+
+K vyřešení tohoto problému vyvinul ekosystém Etherea mnoho alternativních způsobů, jak ukládat data decentralizovaným
+způsobem. Obvykle zahrnují kompromis mezi dostupností
+a cenou. Integrita je však obvykle zajištěna.
+
+V tomto článku se dozvíte, **jak** zajistit integritu dat bez jejich ukládání na blockchain pomocí
+[Merkleho důkazů](https://computersciencewiki.org/index.php/Merkle_proof).
+
+## Jak to funguje? {#how-does-it-work}
+
+Teoreticky bychom mohli pouze uložit haš dat na blockchainu a odeslat všechna data v transakcích, které je vyžadují. To je však stále příliš drahé. Jeden bajt dat v transakci stojí asi 16 gas, což je v současnosti asi půl centu, neboli asi 5 USD za kilobajt. Při ceně 5 000 USD za megabajt je to pro mnoho použití stále příliš drahé, a to i bez dodatečných nákladů na hašování dat.
+
+Řešením je opakovaně hašovat různé podmnožiny dat, takže pro data, která nemusíte odesílat, můžete odeslat pouze haš. To se provádí pomocí Merkleho stromu, stromové datové struktury, kde každý uzel je hašem uzlů pod ním:
+
+
+
+Kořenový haš je jedinou částí, která musí být uložena na blockchainu. K prokázání určité hodnoty poskytnete všechny haše, které je třeba s ní zkombinovat, abyste získali kořen. Například k prokázání `C` poskytnete `D`, `H(A-B)` a `H(E-H)`.
+
+
+
+## Implementace {#implementation}
+
+[Ukázkový kód je k dispozici zde](https://github.com/qbzzt/merkle-proofs-for-offline-data-integrity).
+
+### Kód mimo blockchain {#offchain-code}
+
+V tomto článku používáme pro výpočty mimo blockchain JavaScript. Většina decentralizovaných aplikací má svou komponentu mimo blockchain v JavaScriptu.
+
+#### Vytvoření Merkleho kořene {#creating-the-merkle-root}
+
+Nejprve musíme poskytnout Merkleho kořen do řetězce.
+
+```javascript
+const ethers = require("ethers")
+```
+
+[Používáme hašovací funkci z balíčku ethers](https://docs.ethers.io/v5/api/utils/hashing/#utils-keccak256).
+
+```javascript
+// Hrubá data, jejichž integritu musíme ověřit. První dva bajty
+// jsou identifikátor uživatele a poslední dva bajty jsou množství tokenů, které
+// uživatel v současnosti vlastní.
+const dataArray = [
+ 0x0bad0010, 0x60a70020, 0xbeef0030, 0xdead0040, 0xca110050, 0x0e660060,
+ 0xface0070, 0xbad00080, 0x060d0091,
+]
+```
+
+Kódování každé položky do jediného 256bitového celého čísla vede k méně čitelnému kódu než například použití JSON. To však znamená výrazně menší zpracování pro načtení dat ve smart kontraktu, tedy mnohem nižší náklady na gas. [Můžete číst JSON na blockchainu](https://github.com/chrisdotn/jsmnSol), ale je to špatný nápad, pokud je to možné se mu vyhnout.
+
+```javascript
+// Pole hašovacích hodnot jako BigInts
+const hashArray = dataArray
+```
+
+V tomto případě jsou naše data na začátku 256bitové hodnoty, takže není nutné žádné zpracování. Pokud použijeme složitější datovou strukturu, například řetězce, musíme se ujistit, že data nejprve hašujeme, abychom získali pole hašů. Všimněte si, že je to také proto, že nám nevadí, když uživatelé znají informace ostatních uživatelů. Jinak bychom museli hašovat, aby uživatel 1 neznal hodnotu pro uživatele 0, uživatel 2 neznal hodnotu pro uživatele 3 atd.
+
+```javascript
+// Převod mezi řetězcem, který očekává hašovací funkce, a
+// BigInt, který používáme všude jinde.
+const hash = (x) =>
+ BigInt(ethers.utils.keccak256("0x" + x.toString(16).padStart(64, 0)))
+```
+
+Hašovací funkce ethers očekává, že dostane řetězec JavaScriptu s hexadecimálním číslem, například `0x60A7`, a odpoví jiným řetězcem se stejnou strukturou. Pro zbytek kódu je však snazší použít `BigInt`, takže převádíme na hexadecimální řetězec a zase zpět.
+
+```javascript
+// Symetrický haš páru, takže nám nebude vadit, pokud bude pořadí obrácené.
+const pairHash = (a, b) => hash(hash(a) ^ hash(b))
+```
+
+Tato funkce je symetrická (haš a [xor](https://en.wikipedia.org/wiki/Exclusive_or) b). To znamená, že při kontrole Merkleho důkazu se nemusíme starat o to, zda hodnotu z důkazu umístit před nebo za vypočtenou hodnotu. Kontrola Merkleho důkazu se provádí na blockchainu, takže čím méně toho tam musíme dělat, tím lépe.
+
+Upozornění:
+Kryptografie je složitější, než se zdá.
+Původní verze tohoto článku měla hašovací funkci `hash(a^b)`.
+To byl **špatný** nápad, protože to znamenalo, že pokud jste znali legitimní hodnoty `a` a `b`, mohli jste použít `b' = a^b^a'` k prokázání jakékoli požadované hodnoty `a'`.
+S touto funkcí byste museli vypočítat `b'` tak, aby `haš(a') ^ haš(b')` byl roven známé hodnotě (další větev na cestě ke kořeni), což je mnohem těžší.
+
+```javascript
+// Hodnota pro označení, že určitá větev je prázdná, nemá
+// žádnou hodnotu
+const empty = 0n
+```
+
+Když počet hodnot není celočíselnou mocninou dvou, musíme řešit prázdné větve. Tento program to řeší tak, že jako zástupný symbol vloží nulu.
+
+
+
+```javascript
+// Vypočítá o jednu úroveň výše strom hašovacího pole tím, že vezme haš
+// každého páru v pořadí.
+const oneLevelUp = (inputArray) => {
+ var result = []
+ var inp = [...inputArray] // Aby se zabránilo přepsání vstupních dat // V případě potřeby přidejte prázdnou hodnotu (potřebujeme, aby všechny listy byly spárovány)
+
+ if (inp.length % 2 === 1) inp.push(empty)
+
+ for (var i = 0; i < inp.length; i += 2)
+ result.push(pairHash(inp[i], inp[i + 1]))
+
+ return result
+} // oneLevelUp
+```
+
+Tato funkce „vystoupá“ o jednu úroveň v Merkleho stromu hašováním párů hodnot na aktuální vrstvě. Všimněte si, že se nejedná o nejefektivnější implementaci, mohli jsme se vyhnout kopírování vstupu a pouze přidat `hashEmpty` v příslušném místě cyklu, ale tento kód je optimalizován pro čitelnost.
+
+```javascript
+const getMerkleRoot = (inputArray) => {
+ var result
+
+ result = [...inputArray] // Stoupejte stromem, dokud nezbude jen jedna hodnota, což je // kořen. // // Pokud má vrstva lichý počet položek, // kód v oneLevelUp přidá prázdnou hodnotu, takže pokud máme například // 10 listů, budeme mít 5 větví ve druhé vrstvě, 3 // větve ve třetí, 2 ve čtvrté a kořen je pátý
+
+ while (result.length > 1) result = oneLevelUp(result)
+
+ return result[0]
+}
+```
+
+Chcete-li získat kořen, stoupejte, dokud nezbude pouze jedna hodnota.
+
+#### Vytvoření Merkleho důkazu {#creating-a-merkle-proof}
+
+Merkleho důkaz jsou hodnoty, které se mají hašovat spolu s prokazovanou hodnotou, aby se vrátil Merkleho kořen. Hodnota, která se má prokázat, je často k dispozici z jiných dat, takže ji raději poskytuji samostatně než jako součást kódu.
+
+```javascript
+// Merkleho důkaz se skládá z hodnoty seznamu položek, se kterými
+// se má hašovat. Protože používáme symetrickou hašovací funkci, nepotřebujeme
+// polohu položky k ověření důkazu, pouze k jeho vytvoření.
+const getMerkleProof = (inputArray, n) => {
+ var result = [], currentLayer = [...inputArray], currentN = n
+
+ // Dokud nedosáhneme vrcholu
+ while (currentLayer.length > 1) {
+ // Žádné vrstvy s lichou délkou
+ if (currentLayer.length % 2)
+ currentLayer.push(empty)
+
+ result.push(currentN % 2
+ // Pokud je currentN liché, přidejte k důkazu hodnotu před ním
+ ? currentLayer[currentN-1]
+ // Pokud je sudé, přidejte hodnotu za ním
+ : currentLayer[currentN+1])
+
+```
+
+Hašujeme `(v[0],v[1])`, `(v[2],v[3])` atd. Takže pro sudé hodnoty potřebujeme následující, pro liché hodnoty předchozí.
+
+```javascript
+ // Přesun na další vyšší vrstvu
+ currentN = Math.floor(currentN/2)
+ currentLayer = oneLevelUp(currentLayer)
+ } // while currentLayer.length > 1
+
+ return result
+} // getMerkleProof
+```
+
+### Kód na blockchainu {#onchain-code}
+
+Nakonec máme kód, který kontroluje důkaz. Kód na blockchainu je napsán v [jazyce Solidity](https://docs.soliditylang.org/en/v0.8.11/). Optimalizace je zde mnohem důležitější, protože gas je relativně drahý.
+
+```solidity
+//SPDX-License-Identifier: Public Domain
+pragma solidity ^0.8.0;
+
+import "hardhat/console.sol";
+```
+
+Napsal jsem to pomocí [vývojového prostředí Hardhat](https://hardhat.org/), které nám umožňuje mít [výstup z konzole ze Solidity](https://hardhat.org/docs/cookbook/debug-logs) během vývoje.
+
+```solidity
+
+contract MerkleProof {
+ uint merkleRoot;
+
+ function getRoot() public view returns (uint) {
+ return merkleRoot;
+ }
+
+ // Extrémně nezabezpečené, v produkčním kódu MUSÍ BÝT přístup k
+ // této funkci přísně omezen, pravděpodobně pouze na
+ // vlastníka
+ function setRoot(uint _merkleRoot) external {
+ merkleRoot = _merkleRoot;
+ } // setRoot
+```
+
+Funkce Set a get pro Merkleho kořen. Povolit každému aktualizovat Merkleho kořen je v produkčním systému _extrémně špatný nápad_. Dělám to zde pro zjednodušení ukázkového kódu. **Nedělejte to v systému, kde na integritě dat skutečně záleží**.
+
+```solidity
+ function hash(uint _a) internal pure returns(uint) {
+ return uint(keccak256(abi.encode(_a)));
+ }
+
+ function pairHash(uint _a, uint _b) internal pure returns(uint) {
+ return hash(hash(_a) ^ hash(_b));
+ }
+```
+
+Tato funkce generuje párový haš. Je to jen překlad JavaScriptového kódu pro `hash` a `pairHash` do jazyka Solidity.
+
+**Poznámka:** Toto je další případ optimalizace pro čitelnost. Na základě [definice funkce](https://www.tutorialspoint.com/solidity/solidity_cryptographic_functions.htm) by bylo možné ukládat data jako hodnotu [`bytes32`](https://docs.soliditylang.org/en/v0.5.3/types.html#fixed-size-byte-arrays) a vyhnout se převodům.
+
+```solidity
+ // Ověřit Merkleho důkaz
+ function verifyProof(uint _value, uint[] calldata _proof)
+ public view returns (bool) {
+ uint temp = _value;
+ uint i;
+
+ for(i=0; i<_proof.length; i++) {
+ temp = pairHash(temp, _proof[i]);
+ }
+
+ return temp == merkleRoot;
+ }
+
+} // MarkleProof
+```
+
+V matematické notaci vypadá ověření Merkleho důkazu takto: `H(proof_n, H(proof_n-1, H(proof_n-2, ...` H(proof_1, H(proof_0, value))...)))\`. Tento kód to implementuje.
+
+## Merkleho důkazy a rollupy se nemíchají {#merkle-proofs-and-rollups}
+
+Merkleho důkazy nefungují dobře s [rollupy](/developers/docs/scaling/#rollups). Důvodem je, že rollupy zapisují všechna transakční data na L1, ale zpracovávají je na L2. Náklady na odeslání Merkleho důkazu s transakcí činí v průměru 638 gas za vrstvu (v současnosti stojí bajt v datech volání 16 gas, pokud není nulový, a 4, pokud je nulový). Pokud máme 1024 slov dat, Merkleho důkaz vyžaduje deset vrstev, neboli celkem 6380 gas.
+
+Když se podíváme například na [Optimism](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m), zápis gas na L1 stojí asi 100 gwei a gas na L2 stojí 0,001 gwei (to je normální cena, při přetížení se může zvýšit). Takže za cenu jednoho L1 gas můžeme utratit sto tisíc gas za zpracování na L2. Za předpokladu, že nepřepisujeme úložiště, znamená to, že za cenu jednoho L1 gas můžeme na L2 zapsat do úložiště asi pět slov. Pro jediný Merkleho důkaz můžeme zapsat celých 1024 slov do úložiště (za předpokladu, že mohou být vypočtena na blockchainu, nikoli poskytnuta v transakci) a stále nám zbude většina gas.
+
+## Závěr {#conclusion}
+
+V reálném životě možná nikdy nebudete sami implementovat Merkleho stromy. Existují známé a auditované knihovny, které můžete použít, a obecně platí, že je nejlepší neimplementovat kryptografické primitivy sami. Ale doufám, že nyní lépe rozumíte Merkleho důkazům a můžete se rozhodnout, kdy se vyplatí je použít.
+
+Všimněte si, že zatímco Merkleho důkazy zachovávají _integritu_, nezachovávají _dostupnost_. Vědět, že nikdo jiný nemůže vzít vaše aktiva, je malou útěchou, pokud se úložiště dat rozhodne zakázat přístup a vy nemůžete sestavit Merkleho strom, abyste k nim měli přístup. Merkleho stromy se tedy nejlépe používají s nějakým druhem decentralizovaného úložiště, jako je IPFS.
+
+[Více z mé práce najdete zde](https://cryptodocguy.pro/).
diff --git a/public/content/translations/cs/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md b/public/content/translations/cs/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md
new file mode 100644
index 00000000000..bdeccdd97a2
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md
@@ -0,0 +1,151 @@
+---
+title: Monitorování Gethu s InfluxDB a Grafanou
+description: Nastavte si monitorování pro svůj Geth uzel pomocí InfluxDB a Grafany, abyste mohli sledovat jeho výkon a identifikovat problémy.
+author: "Mario Havel"
+tags: [ "klienti", "uzly" ]
+skill: intermediate
+lang: cs
+published: 2021-01-13
+---
+
+Tento tutoriál vám pomůže nastavit monitorování pro váš Geth uzel, abyste mohli lépe porozumět jeho výkonu a identifikovat případné problémy.
+
+## Předpoklady {#prerequisites}
+
+- Měli byste již mít spuštěnou instanci Gethu.
+- Většina kroků a příkladů je určena pro prostředí Linux, takže se bude hodit základní znalost terminálu.
+- Podívejte se na tento videopřehled sady metrik Gethu: [Monitorování infrastruktury Ethereum od Pétera Szilágyiho](https://www.youtube.com/watch?v=cOBab8IJMYI).
+
+## Sada pro monitorování {#monitoring-stack}
+
+Klient Etherea shromažďuje spoustu dat, která lze číst ve formě chronologické databáze. Pro usnadnění monitorování je můžete vložit do softwaru pro vizualizaci dat. K dispozici je více možností:
+
+- [Prometheus](https://prometheus.io/) (pull model)
+- [InfluxDB](https://www.influxdata.com/get-influxdb/) (push model)
+- [Telegraf](https://www.influxdata.com/get-influxdb/)
+- [Grafana](https://www.grafana.com/)
+- [Datadog](https://www.datadoghq.com/)
+- [Chronograf](https://www.influxdata.com/time-series-platform/chronograf/)
+
+Existuje také [Geth Prometheus Exporter](https://github.com/hunterlong/gethexporter), možnost předkonfigurovaná s InfluxDB a Grafanou.
+
+V tomto tutoriálu nastavíme vašeho klienta Geth tak, aby odesílal data do InfluxDB k vytvoření databáze a Grafanu k vytvoření grafické vizualizace dat. Ruční provedení vám pomůže lépe porozumět procesu, měnit ho a nasazovat v různých prostředích.
+
+## Nastavení InfluxDB {#setting-up-influxdb}
+
+Nejprve si stáhněme a nainstalujme InfluxDB. Různé možnosti stažení naleznete na [stránce s verzemi Influxdata](https://portal.influxdata.com/downloads/). Vyberte si tu, která vyhovuje vašemu prostředí.
+Můžete ji také nainstalovat z [úložiště](https://repos.influxdata.com/). Například v distribuci založené na Debianu:
+
+```
+curl -tlsv1.3 --proto =https -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add
+source /etc/lsb-release
+echo "deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
+sudo apt update
+sudo apt install influxdb -y
+sudo systemctl enable influxdb
+sudo systemctl start influxdb
+sudo apt install influxdb-client
+```
+
+Po úspěšné instalaci InfluxDB se ujistěte, že běží na pozadí. Ve výchozím nastavení je dostupná na `localhost:8086`.
+Před použitím klienta `influx` musíte vytvořit nového uživatele s oprávněními správce. Tento uživatel bude sloužit pro správu na vysoké úrovni, vytváření databází a uživatelů.
+
+```
+curl -XPOST "http://localhost:8086/query" --data-urlencode "q=CREATE USER username WITH PASSWORD 'password' WITH ALL PRIVILEGES"
+```
+
+Nyní můžete použít klienta influx pro vstup do [InfluxDB shellu](https://docs.influxdata.com/influxdb/v1.8/tools/shell/) s tímto uživatelem.
+
+```
+influx -username 'username' -password 'password'
+```
+
+Přímou komunikací s InfluxDB v jeho shellu můžete vytvořit databázi a uživatele pro metriky Geth.
+
+```
+create database geth
+create user geth with password choosepassword
+```
+
+Ověřte vytvořené položky pomocí:
+
+```
+show databases
+show users
+```
+
+Opusťte InfluxDB shell.
+
+```
+exit
+```
+
+InfluxDB běží a je nakonfigurována pro ukládání metrik z Gethu.
+
+## Příprava Gethu {#preparing-geth}
+
+Po nastavení databáze musíme v Gethu povolit sběr metrik. Věnujte pozornost `METRICS AND STATS OPTIONS` v `geth --help`. Naleznete zde několik možností, v tomto případě chceme, aby Geth odesílal data do InfluxDB.
+Základní nastavení specifikuje koncový bod, kde je InfluxDB dostupná, a ověření pro databázi.
+
+```
+geth --metrics --metrics.influxdb --metrics.influxdb.endpoint "http://0.0.0.0:8086" --metrics.influxdb.username "geth" --metrics.influxdb.password "chosenpassword"
+```
+
+Tyto příznaky mohou být připojeny k příkazu spouštějícímu klienta nebo uloženy do konfiguračního souboru.
+
+Můžete ověřit, že Geth úspěšně odesílá data, například výpisem metrik v databázi. V InfluxDB shellu:
+
+```
+use geth
+show measurements
+```
+
+## Nastavení Grafany {#setting-up-grafana}
+
+Dalším krokem je instalace Grafany, která bude interpretovat data graficky. Postupujte podle instalačního procesu pro vaše prostředí v dokumentaci Grafany. Ujistěte se, že instalujete verzi OSS, pokud nechcete jinak.
+Příklad instalačních kroků pro distribuce Debian s použitím úložiště:
+
+```
+curl -tlsv1.3 --proto =https -sL https://packages.grafana.com/gpg.key | sudo apt-key add -
+echo "deb https://packages.grafana.com/oss/deb stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.list
+sudo apt update
+sudo apt install grafana
+sudo systemctl enable grafana-server
+sudo systemctl start grafana-server
+```
+
+Když máte Grafanu spuštěnou, měla by být dostupná na `localhost:3000`.
+Použijte preferovaný prohlížeč pro přístup k této cestě, poté se přihlaste s výchozími přihlašovacími údaji (uživatel: `admin` a heslo: `admin`). Po zobrazení výzvy změňte výchozí heslo a uložte.
+
+
+
+Budete přesměrováni na domovskou stránku Grafany. Nejprve nastavte svá zdrojová data. Klikněte na ikonu konfigurace v levém panelu a vyberte „Zdroje dat“.
+
+
+
+Zatím nejsou vytvořeny žádné zdroje dat, klikněte na „Přidat zdroj dat“ pro definování jednoho.
+
+
+
+Pro toto nastavení vyberte „InfluxDB“ a pokračujte.
+
+
+
+Konfigurace zdroje dat je poměrně jednoduchá, pokud spouštíte nástroje na stejném stroji. Musíte nastavit adresu InfluxDB a podrobnosti pro přístup k databázi. Viz obrázek níže.
+
+
+
+Pokud je vše kompletní a InfluxDB je dostupná, klikněte na „Uložit a testovat“ a počkejte, až se zobrazí potvrzení.
+
+
+
+Grafana je nyní nastavena ke čtení dat z InfluxDB. Nyní musíte vytvořit panel, který je bude interpretovat a zobrazovat. Vlastnosti panelů jsou kódovány v souborech JSON, které může kdokoli vytvořit a snadno importovat. V levém panelu klikněte na „Vytvořit a importovat“.
+
+
+
+Pro monitorovací panel Geth zkopírujte ID [tohoto panelu](https://grafana.com/grafana/dashboards/13877/) a vložte jej na stránku „Importovat“ v Grafaně. Po uložení panelu by měl vypadat takto:
+
+
+
+Své panely můžete upravovat. Každý panel lze upravovat, přesouvat, odstraňovat nebo přidávat. Můžete měnit své konfigurace. Je to na vás! Chcete-li se dozvědět více o tom, jak panely fungují, podívejte se do [dokumentace Grafany](https://grafana.com/docs/grafana/latest/dashboards/).
+Mohlo by vás také zajímat [Upozorňování](https://grafana.com/docs/grafana/latest/alerting/). To vám umožní nastavit upozornění pro případy, kdy metriky dosáhnou určitých hodnot. Jsou podporovány různé komunikační kanály.
diff --git a/public/content/translations/cs/developers/tutorials/nft-minter/index.md b/public/content/translations/cs/developers/tutorials/nft-minter/index.md
new file mode 100644
index 00000000000..e4d036db2a6
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/nft-minter/index.md
@@ -0,0 +1,874 @@
+---
+title: Návod na minter pro NFT
+description: V tomto návodu si vytvoříte minter pro NFT a naučíte se, jak vytvořit full-stack dapp propojením svého chytrého kontraktu s React frontendem pomocí nástrojů MetaMask a Web3.
+author: "smudgil"
+tags:
+ [
+ "solidity",
+ "NFT",
+ "alchemy",
+ "chytré kontrakty",
+ "frontend",
+ "Pinata"
+ ]
+skill: intermediate
+lang: cs
+published: 2021-10-06
+---
+
+Jednou z největších výzev pro vývojáře přicházející z prostředí Web2 je přijít na to, jak propojit chytrý kontrakt s frontendovým projektem a pracovat s ním.
+
+Vytvořením minteru pro NFT – jednoduchého uživatelského rozhraní, do kterého můžete zadat odkaz na své digitální aktivum, název a popis – se naučíte:
+
+- Připojit se k MetaMasku prostřednictvím vašeho frontendového projektu
+- Volat metody chytrého kontraktu z vašeho frontendu
+- Podepisovat transakce pomocí MetaMasku
+
+V tomto návodu budeme jako náš frontendový framework používat [React](https://react.dev/). Protože se tento návod zaměřuje především na vývoj pro Web3, nebudeme trávit mnoho času rozebíráním základů Reactu. Místo toho se zaměříme na to, abychom našemu projektu dodali funkcionalitu.
+
+Předpokladem je, že byste měli mít základní znalosti Reactu – vědět, jak fungují komponenty, props, useState/useEffect a základní volání funkcí. Pokud jste o žádném z těchto pojmů nikdy neslyšeli, možná se budete chtít podívat na tento [návod Úvod do Reactu](https://react.dev/learn/tutorial-tic-tac-toe). Těm, kteří se učí spíše vizuálně, vřele doporučujeme tuto vynikající sérii videí [Kompletní moderní návod na React](https://www.youtube.com/playlist?list=PL4cUxeGkcC9gZD-Tvwfod2gaISzfRiP9d) od Net Ninja.
+
+A pokud ho ještě nemáte, budete k dokončení tohoto návodu a k vytváření čehokoli na blockchainu určitě potřebovat účet Alchemy. Zaregistrujte si bezplatný účet [zde](https://alchemy.com/).
+
+Bez dalších okolků se do toho pusťme!
+
+## Tvorba NFT 101 {#making-nfts-101}
+
+Než se vůbec začneme dívat na jakýkoli kód, je důležité pochopit, jak funguje tvorba NFT. Zahrnuje to dva kroky:
+
+### Zveřejnění chytrého kontraktu NFT na blockchainu Ethereum {#publish-nft}
+
+Největší rozdíl mezi dvěma standardy chytrých kontraktů pro NFT je ten, že ERC-1155 je standard pro více tokenů a zahrnuje dávkovou funkcionalitu, zatímco ERC-721 je standard pro jeden token, a proto podporuje pouze přenos jednoho tokenu najednou.
+
+### Volání funkce mintování {#minting-function}
+
+Obvykle tato funkce mintování vyžaduje, abyste jako parametry předali dvě proměnné: zaprvé `recipient`, která určuje adresu, jež obdrží vaše nově namintované NFT, a zadruhé `tokenURI` NFT, což je řetězec, který odkazuje na dokument JSON popisující metadata NFT.
+
+Metadata NFT jsou to, co ho skutečně oživuje a umožňuje mu mít vlastnosti, jako je název, popis, obrázek (nebo jiné digitální aktivum) a další atributy. [Zde je příklad tokenURI](https://gateway.pinata.cloud/ipfs/QmSvBcb4tjdFpajGJhbFAWeK3JAxCdNQLQtr6ZdiSi42V2), které obsahuje metadata NFT.
+
+V tomto návodu se zaměříme na část 2, volání funkce mintování existujícího chytrého kontraktu NFT pomocí našeho uživatelského rozhraní React.
+
+[Zde je odkaz](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE) na chytrý kontrakt ERC-721 NFT, který budeme v tomto návodu volat. Pokud byste se chtěli dozvědět, jak jsme ho vytvořili, vřele doporučujeme podívat se na náš další návod, ["Jak vytvořit NFT"](https://www.alchemy.com/docs/how-to-create-an-nft).
+
+Super, teď když chápeme, jak funguje tvorba NFT, naklonujme si naše startovací soubory!
+
+## Naklonujte si startovací soubory {#clone-the-starter-files}
+
+Nejprve přejděte do [GitHub repozitáře nft-minter-tutorial](https://github.com/alchemyplatform/nft-minter-tutorial), abyste získali startovací soubory pro tento projekt. Naklonujte tento repozitář do svého lokálního prostředí.
+
+Když otevřete tento naklonovaný repozitář `nft-minter-tutorial`, všimnete si, že obsahuje dvě složky: `minter-starter-files` a `nft-minter`.
+
+- `minter-starter-files` obsahuje startovací soubory (v podstatě uživatelské rozhraní React) pro tento projekt. V tomto návodu **budeme pracovat v tomto adresáři**, kde se naučíte, jak toto uživatelské rozhraní oživit připojením k vaší peněžence Ethereum a chytrému kontraktu NFT.
+- `nft-minter` obsahuje celý dokončený návod a je vám k dispozici jako **reference**, **pokud se zaseknete.**
+
+Dále otevřete svou kopii `minter-starter-files` v editoru kódu a poté přejděte do složky `src`.
+
+Veškerý kód, který napíšeme, bude umístěn ve složce `src`. Budeme upravovat komponentu `Minter.js` a psát další javascriptové soubory, abychom našemu projektu dodali funkcionalitu Web3.
+
+## Krok 2: Prohlédněte si naše startovací soubory {#step-2-check-out-our-starter-files}
+
+Než začneme kódovat, je důležité si prohlédnout, co je pro nás již připraveno ve startovacích souborech.
+
+### Spusťte svůj projekt v Reactu {#get-your-react-project-running}
+
+Začněme spuštěním projektu React v našem prohlížeči. Krása Reactu spočívá v tom, že jakmile náš projekt běží v prohlížeči, veškeré uložené změny se v prohlížeči projeví v reálném čase.
+
+Chcete-li projekt spustit, přejděte do kořenového adresáře složky `minter-starter-files` a spusťte v terminálu příkaz `npm install` pro instalaci závislostí projektu:
+
+```bash
+cd minter-starter-files
+npm install
+```
+
+Jakmile se dokončí instalace, spusťte v terminálu `npm start`:
+
+```bash
+npm start
+```
+
+Tím by se vám měl v prohlížeči otevřít http://localhost:3000/, kde uvidíte frontend našeho projektu. Měl by se skládat ze 3 polí: místo pro zadání odkazu na aktivum vašeho NFT, zadání názvu vašeho NFT a poskytnutí popisu.
+
+Pokud se pokusíte kliknout na tlačítka „Připojit peněženku“ nebo „Mintovat NFT“, zjistíte, že nefungují – to proto, že jejich funkcionalitu musíme teprve naprogramovat! :\)
+
+### Komponenta Minter.js {#minter-js}
+
+**POZNÁMKA:** Ujistěte se, že se nacházíte ve složce `minter-starter-files` a ne ve složce `nft-minter`!
+
+Vraťme se do složky `src` v našem editoru a otevřete soubor `Minter.js`. Je nesmírně důležité, abychom všemu v tomto souboru rozuměli, protože se jedná o primární komponentu Reactu, na které budeme pracovat.
+
+V horní části tohoto souboru máme naše stavové proměnné, které budeme aktualizovat po konkrétních událostech.
+
+```javascript
+//Stavové proměnné
+const [walletAddress, setWallet] = useState("")
+const [status, setStatus] = useState("")
+const [name, setName] = useState("")
+const [description, setDescription] = useState("")
+const [url, setURL] = useState("")
+```
+
+Nikdy jste neslyšeli o stavových proměnných Reactu nebo stavových hácích (hooks)? Podívejte se na [tuto](https://legacy.reactjs.org/docs/hooks-state.html) dokumentaci.
+
+Zde je přehled toho, co jednotlivé proměnné představují:
+
+- `walletAddress` – řetězec, který ukládá adresu peněženky uživatele
+- `status` – řetězec, který obsahuje zprávu k zobrazení v dolní části uživatelského rozhraní
+- `name` – řetězec, který ukládá název NFT
+- `description` – řetězec, který ukládá popis NFT
+- `url` – řetězec, který je odkazem na digitální aktivum NFT
+
+Po stavových proměnných uvidíte tři neimplementované funkce: `useEffect`, `connectWalletPressed` a `onMintPressed`. Všimnete si, že všechny tyto funkce jsou `async`, protože v nich budeme provádět asynchronní volání API! Jejich názvy jsou synonymem jejich funkcí:
+
+```javascript
+useEffect(async () => {
+ //TODO: implementovat
+}, [])
+
+const connectWalletPressed = async () => {
+ //TODO: implementovat
+}
+
+const onMintPressed = async () => {
+ //TODO: implementovat
+}
+```
+
+- [`useEffect`](https://legacy.reactjs.org/docs/hooks-effect.html) – toto je React hook, který se volá po vykreslení vaší komponenty. Protože má předanou prázdnou rekvizitu pole `[]` (viz řádek 3), bude volána pouze při _prvním_ vykreslení komponenty. Zde zavoláme náš posluchač peněženky a další funkci peněženky, abychom aktualizovali naše uživatelské rozhraní tak, aby odráželo, zda je peněženka již připojena.
+- `connectWalletPressed` – tato funkce bude volána pro připojení peněženky MetaMask uživatele k naší dapp.
+- `onMintPressed` – tato funkce bude volána pro mintování NFT uživatele.
+
+Na konci tohoto souboru máme uživatelské rozhraní naší komponenty. Pokud si tento kód pečlivě projdete, všimnete si, že aktualizujeme naše stavové proměnné `url`, `name` a `description` při změně vstupu v jejich odpovídajících textových polích.
+
+Také uvidíte, že `connectWalletPressed` a `onMintPressed` se volají při kliknutí na tlačítka s ID `mintButton` a `walletButton`.
+
+```javascript
+//uživatelské rozhraní naší komponenty
+return (
+
+
+
+
+ 🧙♂️ Minter NFT od Alchemy
+
+ Jednoduše přidejte odkaz na své aktivum, název a popis a poté stiskněte „Mintovat“.
+
+
+
+ {status}
+
+)
+```
+
+Nakonec se podívejme, kam se tato komponenta Minter přidává.
+
+Pokud přejdete do souboru `App.js`, který je hlavní komponentou v Reactu a funguje jako kontejner pro všechny ostatní komponenty, uvidíte, že naše komponenta Minter je vložena na řádku 7.
+
+**V tomto návodu budeme upravovat pouze soubor `Minter.js` a přidávat soubory do naší složky `src`.**
+
+Nyní, když chápeme, s čím pracujeme, nastavme si naši peněženku Ethereum!
+
+## Nastavte si svou peněženku Ethereum {#set-up-your-ethereum-wallet}
+
+Aby uživatelé mohli interagovat s vaším chytrým kontraktem, budou muset ke své dapp připojit svou peněženku Ethereum.
+
+### Stáhněte si MetaMask {#download-metamask}
+
+Pro tento výukový program použijeme MetaMask, virtuální peněženku v prohlížeči, která slouží ke správě adresy vašeho ethereového účtu. Pokud chcete lépe porozumět tomu, jak fungují transakce na Ethereu, podívejte se na [tuto stránku](/developers/docs/transactions/).
+
+Účet MetaMask si můžete zdarma stáhnout a vytvořit [zde](https://metamask.io/download). Při vytváření účtu, nebo pokud již účet máte, se ujistěte, že jste vpravo nahoře přepnuli na „Ropsten Test Network“ (abychom nepracovali se skutečnými penězi).
+
+### Přidejte ether z Faucetu {#add-ether-from-faucet}
+
+Abychom mohli mintovat naše NFT (nebo podepisovat jakékoli transakce na blockchainu Ethereum), budeme potřebovat nějaké falešné Eth. Pro získání Eth můžete přejít na [Ropsten faucet](https://faucet.ropsten.be/), zadat adresu svého účtu Ropsten a kliknout na „Send Ropsten Eth“. Krátce poté byste měli vidět Eth ve svém účtu MetaMask!
+
+### Zkontrolujte si zůstatek {#check-your-balance}
+
+Abychom si ověřili, že náš zůstatek je k dispozici, proveďte požadavek [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) pomocí [nástroje Composer od Alchemy](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D). Tím získáte množství Eth ve vaší peněžence. Po zadání adresy vašeho účtu MetaMask a kliknutí na „Send Request“ byste měli vidět takovouto odpověď:
+
+```text
+{"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"}
+```
+
+**POZNÁMKA:** Tento výsledek je ve wei, nikoli v eth. Wei se používá jako nejmenší denominace etheru. Převod z wei na eth je: 1 eth = 10¹⁸ wei. Takže pokud převedeme 0xde0b6b3a7640000 na desetinné číslo, dostaneme 1\*10¹⁸, což se rovná 1 eth.
+
+Uf! Naše falešné peníze jsou všechny tam!
+ {" "}
+ 🦊
+ Do prohlížeče si musíte nainstalovat MetaMask, virtuální peněženku pro Ethereum.
+
+
+
+ ),
+ }
+ }
+}
+```
+
+Pojďme si rozebrat, co tento kód dělá:
+
+Nejprve naše funkce zkontroluje, zda je ve vašem prohlížeči povoleno `window.ethereum`.
+
+`window.ethereum` je globální API, které vkládá MetaMask a další poskytovatelé peněženek a které webovým stránkám umožňuje žádat o účty uživatelů Etherea. Pokud je schváleno, může číst data z blockchainů, ke kterým je uživatel připojen, a navrhovat uživateli podepisování zpráv a transakcí. Pro více informací se podívejte do [dokumentace MetaMasku](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents)!
+
+Pokud `window.ethereum` _není_ přítomno, znamená to, že MetaMask není nainstalován. Výsledkem je vrácení objektu JSON, kde vrácená `adresa` je prázdný řetězec a objekt JSX `status` sděluje, že uživatel si musí nainstalovat MetaMask.
+
+**Většina funkcí, které napíšeme, bude vracet objekty JSON, které můžeme použít k aktualizaci našich stavových proměnných a uživatelského rozhraní.**
+
+Pokud `window.ethereum` _je_ přítomno, pak to začne být zajímavé.
+
+Pomocí smyčky try/catch se pokusíme připojit k MetaMasku voláním [`window.ethereum.request({ method: \"eth_requestAccounts\" });`](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts). Volání této funkce otevře MetaMask v prohlížeči, kde bude uživatel vyzván k připojení své peněženky k vaší dapp.
+
+- Pokud se uživatel rozhodne připojit, `method: \"eth_requestAccounts\"` vrátí pole, které obsahuje všechny adresy účtů uživatele připojené k dapp. Celkově naše funkce `connectWallet` vrátí objekt JSON, který obsahuje _první_ `adresu` v tomto poli (viz řádek 9) a zprávu `status`, která vyzve uživatele k napsání zprávy do chytrého kontraktu.
+- Pokud uživatel spojení odmítne, objekt JSON bude obsahovat prázdný řetězec pro vrácenou `adresu` a zprávu `status`, která odráží, že uživatel spojení odmítl.
+
+### Přidejte funkci connectWallet do své komponenty UI Minter.js {#add-connect-wallet}
+
+Nyní, když jsme napsali tuto funkci `connectWallet`, připojme ji k naší komponentě `Minter.js`.
+
+Nejprve budeme muset naimportovat naši funkci do našeho souboru `Minter.js` přidáním `import { connectWallet } from \"./utils/interact.js\";` na začátek souboru `Minter.js`. Vašich prvních 11 řádků souboru `Minter.js` by nyní mělo vypadat takto:
+
+```javascript
+import { useEffect, useState } from "react";
+import { connectWallet } from "./utils/interact.js";
+
+const Minter = (props) => {
+
+ //Stavové proměnné
+ const [walletAddress, setWallet] = useState("");
+ const [status, setStatus] = useState("");
+ const [name, setName] = useState("");
+ const [description, setDescription] = useState("");
+ const [url, setURL] = useState("");
+```
+
+Poté uvnitř naší funkce `connectWalletPressed` zavoláme naši importovanou funkci `connectWallet` takto:
+
+```javascript
+const connectWalletPressed = async () => {
+ const walletResponse = await connectWallet()
+ setStatus(walletResponse.status)
+ setWallet(walletResponse.address)
+}
+```
+
+Všimněte si, jak je většina naší funkcionality abstrahována z naší komponenty `Minter.js` ze souboru `interact.js`? To proto, abychom dodrželi paradigma M-V-C!
+
+V `connectWalletPressed` jednoduše provedeme await volání naší importované funkce `connectWallet` a pomocí její odpovědi aktualizujeme naše proměnné `status` a `walletAddress` prostřednictvím jejich stavových háků (hooks).
+
+Nyní uložme oba soubory `Minter.js` a `interact.js` a vyzkoušejme naše dosavadní uživatelské rozhraní.
+
+Otevřete svůj prohlížeč na adrese localhost:3000 a stiskněte tlačítko „Připojit peněženku“ vpravo nahoře na stránce.
+
+Pokud máte nainstalovaný MetaMask, měli byste být vyzváni k připojení své peněženky k vaší dapp. Přijměte výzvu k připojení.
+
+Měli byste vidět, že tlačítko peněženky nyní ukazuje, že je vaše adresa připojena.
+
+Dále zkuste obnovit stránku... to je divné. Naše tlačítko peněženky nás vyzývá k připojení MetaMasku, i když už je připojen...
+
+Ale nebojte se! To můžeme snadno opravit implementací funkce nazvané `getCurrentWalletConnected`, která zkontroluje, zda je adresa již připojena k naší dapp, a podle toho aktualizuje naše uživatelské rozhraní!
+
+### Funkce getCurrentWalletConnected {#get-current-wallet}
+
+Do svého souboru `interact.js` přidejte následující funkci `getCurrentWalletConnected`:
+
+```javascript
+export const getCurrentWalletConnected = async () => {
+ if (window.ethereum) {
+ try {
+ const addressArray = await window.ethereum.request({
+ method: "eth_accounts",
+ })
+ if (addressArray.length > 0) {
+ return {
+ address: addressArray[0],
+ status: "👆🏽 Napište zprávu do textového pole výše.",
+ }
+ } else {
+ return {
+ address: "",
+ status: "🦊 Připojte se k MetaMasku pomocí tlačítka vpravo nahoře.",
+ }
+ }
+ } catch (err) {
+ return {
+ address: "",
+ status: "😥 " + err.message,
+ }
+ }
+ } else {
+ return {
+ address: "",
+ status: (
+
+
+ {" "}
+ 🦊
+ Do prohlížeče si musíte nainstalovat MetaMask, virtuální peněženku pro Ethereum.
+
+
+
+ ),
+ }
+ }
+}
+```
+
+Tento kód je _velmi_ podobný funkci `connectWallet`, kterou jsme napsali dříve.
+
+Hlavní rozdíl je v tom, že místo volání metody `eth_requestAccounts`, která otevře MetaMask, aby si uživatel mohl připojit svou peněženku, zde voláme metodu `eth_accounts`, která jednoduše vrací pole obsahující adresy MetaMask aktuálně připojené k naší dapp.
+
+Abychom viděli tuto funkci v akci, zavoláme ji ve funkci `useEffect` naší komponenty `Minter.js`.
+
+Stejně jako u `connectWallet` musíme tuto funkci naimportovat z našeho souboru `interact.js` do našeho souboru `Minter.js` takto:
+
+```javascript
+import { useEffect, useState } from "react"
+import {
+ connectWallet,
+ getCurrentWalletConnected, //importovat zde
+} from "./utils/interact.js"
+```
+
+Nyní ji jednoduše zavoláme v naší funkci `useEffect`:
+
+```javascript
+useEffect(async () => {
+ const { address, status } = await getCurrentWalletConnected()
+ setWallet(address)
+ setStatus(status)
+}, [])
+```
+
+Všimněte si, že odpověď z našeho volání `getCurrentWalletConnected` používáme k aktualizaci našich stavových proměnných `walletAddress` a `status`.
+
+Jakmile přidáte tento kód, zkuste obnovit okno prohlížeče. Tlačítko by mělo hlásit, že jste připojeni, a zobrazovat náhled adresy vaší připojené peněženky – i po obnovení!
+
+### Implementujte addWalletListener {#implement-add-wallet-listener}
+
+Posledním krokem v nastavení peněženky naší dapp je implementace posluchače peněženky, aby se naše uživatelské rozhraní aktualizovalo, když se změní stav naší peněženky, například když se uživatel odpojí nebo přepne účty.
+
+Do svého souboru `Minter.js` přidejte funkci `addWalletListener`, která vypadá následovně:
+
+```javascript
+function addWalletListener() {
+ if (window.ethereum) {
+ window.ethereum.on("accountsChanged", (accounts) => {
+ if (accounts.length > 0) {
+ setWallet(accounts[0])
+ setStatus("👆🏽 Napište zprávu do textového pole výše.")
+ } else {
+ setWallet("")
+ setStatus("🦊 Připojte se k MetaMasku pomocí tlačítka vpravo nahoře.")
+ }
+ })
+ } else {
+ setStatus(
+
+ {" "}
+ 🦊
+ Do prohlížeče si musíte nainstalovat MetaMask, virtuální peněženku pro Ethereum.
+
+
+ )
+ }
+}
+```
+
+Pojďme si rychle rozebrat, co se zde děje:
+
+- Nejprve naše funkce zkontroluje, zda je `window.ethereum` povoleno (tj. zda je MetaMask nainstalován).
+ - Pokud není, jednoduše nastavíme naši stavovou proměnnou `status` na řetězec JSX, který uživatele vyzve k instalaci MetaMasku.
+ - Pokud je povoleno, nastavíme na řádku 3 posluchače `window.ethereum.on(\"accountsChanged\")`, který naslouchá změnám stavu v peněžence MetaMask, což zahrnuje případy, kdy uživatel připojí další účet k dapp, přepne účty nebo odpojí účet. Pokud je připojen alespoň jeden účet, stavová proměnná `walletAddress` se aktualizuje jako první účet v poli `accounts` vráceném posluchačem. V opačném případě je `walletAddress` nastaveno jako prázdný řetězec.
+
+Nakonec ji musíme zavolat v naší funkci `useEffect`:
+
+```javascript
+useEffect(async () => {
+ const { address, status } = await getCurrentWalletConnected()
+ setWallet(address)
+ setStatus(status)
+
+ addWalletListener()
+}, [])
+```
+
+A je to! Dokončili jsme programování veškeré funkcionality naší peněženky! Nyní, když je naše peněženka nastavena, pojďme zjistit, jak mintovat naše NFT!
+
+## Metadata NFT 101 {#nft-metadata-101}
+
+Vzpomeňte si na metadata NFT, o kterých jsme mluvili v kroku 0 tohoto návodu – oživují NFT a umožňují mu mít vlastnosti, jako je digitální aktivum, název, popis a další atributy.
+
+Tato metadata budeme muset nakonfigurovat jako objekt JSON a uložit je, abychom je mohli předat jako parametr `tokenURI` při volání funkce `mintNFT` našeho chytrého kontraktu.
+
+Text v polích „Odkaz na aktivum“, „Název“ a „Popis“ bude tvořit různé vlastnosti metadat našeho NFT. Tato metadata naformátujeme jako objekt JSON, ale existuje několik možností, kde tento objekt JSON můžeme uložit:
+
+- Mohli bychom je uložit na blockchainu Ethereum, avšak to by bylo velmi drahé.
+- Mohli bychom je uložit na centralizovaném serveru, jako je AWS nebo Firebase. To by ale bylo v rozporu s naším decentralizačním étosem.
+- Mohli bychom použít IPFS, decentralizovaný protokol a peer-to-peer síť pro ukládání a sdílení dat v distribuovaném souborovém systému. Protože je tento protokol decentralizovaný a bezplatný, je to naše nejlepší volba!
+
+K uložení našich metadat na IPFS použijeme [Pinata](https://pinata.cloud/), pohodlné API a sadu nástrojů pro IPFS. V dalším kroku si přesně vysvětlíme, jak na to!
+
+## Použijte Pinata k připnutí vašich metadat na IPFS {#use-pinata-to-pin-your-metadata-to-IPFS}
+
+Pokud nemáte účet [Pinata](https://pinata.cloud/), zaregistrujte si bezplatný účet [zde](https://app.pinata.cloud/auth/signup) a dokončete kroky k ověření svého e-mailu a účtu.
+
+### Vytvořte si API klíč Pinata {#create-pinata-api-key}
+
+Přejděte na stránku [https://pinata.cloud/keys](https://pinata.cloud/keys), poté vyberte tlačítko „New Key“ nahoře, nastavte widget Admin jako povolený a pojmenujte svůj klíč.
+
+Poté se vám zobrazí vyskakovací okno s vašimi informacemi o API. Ujistěte se, že si je uložíte na bezpečné místo.
+
+Nyní, když máme náš klíč nastavený, přidejme ho do našeho projektu, abychom ho mohli používat.
+
+### Vytvořte soubor .env {#create-a-env}
+
+Náš klíč Pinata a tajný klíč můžeme bezpečně uložit do souboru s proměnnými prostředí. Nainstalujme si do adresáře projektu [balíček dotenv](https://www.npmjs.com/package/dotenv).
+
+Otevřete novou kartu v terminálu (jinou než tu, na které běží localhost), ujistěte se, že se nacházíte ve složce `minter-starter-files` a spusťte následující příkaz:
+
+```text
+npm install dotenv --save
+```
+
+Dále vytvořte soubor `.env` v kořenovém adresáři `minter-starter-files` zadáním následujícího příkazu:
+
+```javascript
+vim.env
+```
+
+Tím se vám otevře soubor `.env` ve vimu (textovém editoru). Pro uložení stiskněte na klávesnici v tomto pořadí „esc“ + „:“ + „q“.
+
+Dále v editoru VSCode přejděte do souboru `.env` a přidejte do něj svůj API klíč Pinata a API secret takto:
+
+```text
+REACT_APP_PINATA_KEY =
+REACT_APP_PINATA_SECRET =
+```
+
+Uložte soubor a pak jste připraveni začít psát funkci pro nahrání vašich metadat JSON na IPFS!
+
+### Implementujte pinJSONToIPFS {#pin-json-to-ipfs}
+
+Naštěstí pro nás má Pinata [API speciálně pro nahrávání dat JSON na IPFS](https://docs.pinata.cloud/api-reference/endpoint/ipfs/pin-json-to-ipfs#pin-json) a pohodlný příklad v JavaScriptu s axios, který můžeme s drobnými úpravami použít.
+
+Ve složce `utils` vytvořme další soubor s názvem `pinata.js` a poté naimportujme náš Pinata secret a klíč ze souboru .env takto:
+
+```javascript
+require("dotenv").config()
+const key = process.env.REACT_APP_PINATA_KEY
+const secret = process.env.REACT_APP_PINATA_SECRET
+```
+
+Dále vložte další kód z níže uvedeného do svého souboru `pinata.js`. Nebojte se, rozebereme si, co všechno znamená!
+
+```javascript
+require("dotenv").config()
+const key = process.env.REACT_APP_PINATA_KEY
+const secret = process.env.REACT_APP_PINATA_SECRET
+
+const axios = require("axios")
+
+export const pinJSONToIPFS = async (JSONBody) => {
+ const url = `https://api.pinata.cloud/pinning/pinJSONToIPFS`
+ //odeslání POST požadavku pomocí axios na Pinata ⬇️
+ return axios
+ .post(url, JSONBody, {
+ headers: {
+ pinata_api_key: key,
+ pinata_secret_api_key: secret,
+ },
+ })
+ .then(function (response) {
+ return {
+ success: true,
+ pinataUrl:
+ "https://gateway.pinata.cloud/ipfs/" + response.data.IpfsHash,
+ }
+ })
+ .catch(function (error) {
+ console.log(error)
+ return {
+ success: false,
+ message: error.message,
+ }
+ })
+}
+```
+
+Co přesně tedy tento kód dělá?
+
+Nejprve importuje [axios](https://www.npmjs.com/package/axios), HTTP klienta založeného na promises pro prohlížeč a node.js, který použijeme k provedení požadavku na Pinata.
+
+Poté máme naši asynchronní funkci `pinJSONToIPFS`, která jako vstup přijímá `JSONBody` a v hlavičce API klíč a secret Pinata, a to vše pro provedení POST požadavku na jejich API `pinJSONToIPFS`.
+
+- Pokud je tento POST požadavek úspěšný, naše funkce vrátí objekt JSON s booleovskou hodnotou `success` jako true a `pinataUrl`, kde byla naše metadata připnuta. Tuto vrácenou `pinataUrl` použijeme jako vstup `tokenURI` do funkce mintování našeho chytrého kontraktu.
+- Pokud tento post požadavek selže, naše funkce vrátí objekt JSON s booleovskou hodnotou `success` jako false a řetězcem `message`, který sděluje naši chybu.
+
+Stejně jako u návratových typů naší funkce `connectWallet` vracíme objekty JSON, abychom mohli jejich parametry použít k aktualizaci našich stavových proměnných a uživatelského rozhraní.
+
+## Načtěte svůj chytrý kontrakt {#load-your-smart-contract}
+
+Nyní, když máme způsob, jak nahrát naše metadata NFT na IPFS prostřednictvím naší funkce `pinJSONToIPFS`, budeme potřebovat způsob, jak načíst instanci našeho chytrého kontraktu, abychom mohli volat jeho funkci `mintNFT`.
+
+Jak jsme již zmínili, v tomto návodu budeme používat [tento existující chytrý kontrakt NFT](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE); nicméně, pokud byste se chtěli dozvědět, jak jsme ho vytvořili, nebo si vytvořit vlastní, vřele doporučujeme podívat se na náš další návod ["Jak vytvořit NFT"](https://www.alchemy.com/docs/how-to-create-an-nft).
+
+### ABI kontraktu {#contract-abi}
+
+Pokud jste si naše soubory pozorně prohlédli, jistě jste si všimli, že v našem adresáři `src` se nachází soubor `contract-abi.json`. ABI je nezbytné pro specifikaci, kterou funkci kontrakt vyvolá, a také pro zajištění, že funkce vrátí data ve formátu, který očekáváte.
+
+Budeme také potřebovat API klíč Alchemy a Alchemy Web3 API, abychom se připojili k blockchainu Ethereum a načetli náš chytrý kontrakt.
+
+### Vytvořte si API klíč Alchemy {#create-alchemy-api}
+
+Pokud ještě nemáte účet Alchemy, [zaregistrujte se zdarma zde.](https://alchemy.com/?a=eth-org-nft-minter)
+
+Jakmile si vytvoříte účet na Alchemy, můžete si vygenerovat klíč API vytvořením aplikace. To nám umožní provádět požadavky na testovací síť Ropsten.
+
+Přejděte na stránku „Create App“ ve svém panelu Alchemy tak, že najedete myší na „Apps“ v navigační liště a kliknete na „Create App“.
+
+Pojmenujte svou aplikaci – my jsme zvolili „My First NFT!“, nabídněte krátký popis, vyberte „Staging“ pro prostředí používané pro účetnictví vaší aplikace a jako síť zvolte „Ropsten“.
+
+Klikněte na „Create app“ a to je vše! Vaše aplikace by se měla objevit v tabulce níže.
+
+Skvělé, takže teď, když jsme vytvořili naši HTTP Alchemy API URL, zkopírujte si ji do schránky...
+
+… a poté ji přidejme do našeho souboru `.env`. Celkově by váš soubor .env měl vypadat takto:
+
+```text
+REACT_APP_PINATA_KEY =
+REACT_APP_PINATA_SECRET =
+REACT_APP_ALCHEMY_KEY = https://eth-ropsten.alchemyapi.io/v2/
+```
+
+Nyní, když máme naše ABI kontraktu a náš API klíč Alchemy, jsme připraveni načíst náš chytrý kontrakt pomocí [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3).
+
+### Nastavte si svůj koncový bod Alchemy Web3 a kontrakt {#setup-alchemy-endpoint}
+
+Nejprve, pokud ho ještě nemáte, budete muset nainstalovat [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) tak, že přejdete do domovského adresáře: `nft-minter-tutorial` v terminálu:
+
+```text
+cd ..
+npm install @alch/alchemy-web3
+```
+
+Dále se vraťme do našeho souboru `interact.js`. Na začátek souboru přidejte následující kód, abyste naimportovali svůj klíč Alchemy ze souboru .env a nastavili si svůj koncový bod Alchemy Web3:
+
+```javascript
+require("dotenv").config()
+const alchemyKey = process.env.REACT_APP_ALCHEMY_KEY
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(alchemyKey)
+```
+
+[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) je nadstavba nad [Web3.js](https://docs.web3js.org/), která poskytuje vylepšené metody API a další klíčové výhody, které vám usnadní život vývojáře web3. Je navržen tak, aby vyžadoval minimální konfiguraci, takže jej můžete ve své aplikaci začít používat okamžitě!
+
+Dále přidejme do našeho souboru ABI a adresu kontraktu.
+
+```javascript
+require("dotenv").config()
+const alchemyKey = process.env.REACT_APP_ALCHEMY_KEY
+const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
+const web3 = createAlchemyWeb3(alchemyKey)
+
+const contractABI = require("../contract-abi.json")
+const contractAddress = "0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE"
+```
+
+Jakmile máme obojí, jsme připraveni začít kódovat naši funkci mintování!
+
+## Implementujte funkci mintNFT {#implement-the-mintnft-function}
+
+Uvnitř vašeho souboru `interact.js` definujme naši funkci `mintNFT`, která bude, jak název napovídá, mintovat naše NFT.
+
+Protože budeme provádět četná asynchronní volání (na Pinata pro připnutí našich metadat na IPFS, Alchemy Web3 pro načtení našeho chytrého kontraktu a MetaMask pro podepsání našich transakcí), bude naše funkce také asynchronní.
+
+Tři vstupy do naší funkce budou `url` našeho digitálního aktiva, `name` a `description`. Pod funkci `connectWallet` přidejte následující signaturu funkce:
+
+```javascript
+export const mintNFT = async (url, name, description) => {}
+```
+
+### Zpracování chyb na vstupu {#input-error-handling}
+
+Je samozřejmě logické mít na začátku funkce nějaké zpracování chyb na vstupu, takže z této funkce odejdeme, pokud naše vstupní parametry nejsou správné. Do naší funkce přidejme následující kód:
+
+```javascript
+export const mintNFT = async (url, name, description) => {
+ //zpracování chyb
+ if (url.trim() == "" || name.trim() == "" || description.trim() == "") {
+ return {
+ success: false,
+ status: "❗Před mintováním se prosím ujistěte, že jsou všechna pole vyplněna.",
+ }
+ }
+}
+```
+
+V podstatě, pokud je některý ze vstupních parametrů prázdný řetězec, vrátíme objekt JSON, kde je booleovská hodnota `success` false a řetězec `status` sděluje, že všechna pole v našem uživatelském rozhraní musí být vyplněna.
+
+### Nahrajte metadata na IPFS {#upload-metadata-to-ipfs}
+
+Jakmile víme, že jsou naše metadata správně naformátována, dalším krokem je zabalit je do objektu JSON a nahrát je na IPFS prostřednictvím funkce `pinJSONToIPFS`, kterou jsme napsali!
+
+K tomu musíme nejprve naimportovat funkci `pinJSONToIPFS` do našeho souboru `interact.js`. Na samý začátek `interact.js` přidejme:
+
+```javascript
+import { pinJSONToIPFS } from "./pinata.js"
+```
+
+Vzpomeňte si, že `pinJSONToIPFS` přijímá jako vstup tělo JSON. Takže než ji zavoláme, budeme muset naformátovat naše parametry `url`, `name` a `description` do objektu JSON.
+
+Aktualizujme náš kód tak, aby vytvořil objekt JSON nazvaný `metadata` a poté proveďme volání `pinJSONToIPFS` s tímto parametrem `metadata`:
+
+```javascript
+export const mintNFT = async (url, name, description) => {
+ //zpracování chyb
+ if (url.trim() == "" || name.trim() == "" || description.trim() == "") {
+ return {
+ success: false,
+ status: "❗Před mintováním se prosím ujistěte, že jsou všechna pole vyplněna.",
+ }
+ }
+
+ //vytvořit metadata
+ const metadata = new Object()
+ metadata.name = name
+ metadata.image = url
+ metadata.description = description
+
+ //volání pinata
+ const pinataResponse = await pinJSONToIPFS(metadata)
+ if (!pinataResponse.success) {
+ return {
+ success: false,
+ status: "😢 Něco se pokazilo při nahrávání vašeho tokenURI.",
+ }
+ }
+ const tokenURI = pinataResponse.pinataUrl
+}
+```
+
+Všimněte si, že odpověď na naše volání `pinJSONToIPFS(metadata)` ukládáme do objektu `pinataResponse`. Poté tento objekt analyzujeme na případné chyby.
+
+Pokud dojde k chybě, vrátíme objekt JSON, kde je booleovská hodnota `success` false a náš řetězec `status` sděluje, že naše volání selhalo. V opačném případě extrahujeme `pinataURL` z `pinataResponse` a uložíme ji jako naši proměnnou `tokenURI`.
+
+Nyní je čas načíst náš chytrý kontrakt pomocí Alchemy Web3 API, které jsme inicializovali na začátku našeho souboru. Na konec funkce `mintNFT` přidejte následující řádek kódu, který nastaví kontrakt na globální proměnnou `window.contract`:
+
+```javascript
+window.contract = await new web3.eth.Contract(contractABI, contractAddress)
+```
+
+Poslední věc, kterou je třeba přidat do naší funkce `mintNFT`, je naše transakce Ethereum:
+
+```javascript
+//nastavte si svou transakci Ethereum
+const transactionParameters = {
+ to: contractAddress, // Povinné s výjimkou zveřejnění kontraktu.
+ from: window.ethereum.selectedAddress, // musí odpovídat aktivní adrese uživatele.
+ data: window.contract.methods
+ .mintNFT(window.ethereum.selectedAddress, tokenURI)
+ .encodeABI(), //provést volání chytrého kontraktu NFT
+}
+
+//podepsat transakci přes MetaMask
+try {
+ const txHash = await window.ethereum.request({
+ method: "eth_sendTransaction",
+ params: [transactionParameters],
+ })
+ return {
+ success: true,
+ status:
+ "✅ Podívejte se na svou transakci na Etherscanu: https://ropsten.etherscan.io/tx/" +
+ txHash,
+ }
+} catch (error) {
+ return {
+ success: false,
+ status: "😥 Něco se pokazilo: " + error.message,
+ }
+}
+```
+
+Pokud jste již obeznámeni s transakcemi na Ethereu, všimnete si, že struktura je docela podobná tomu, co jste již viděli.
+
+- Nejprve nastavíme naše parametry transakce.
+ - `to` určuje adresu příjemce (náš chytrý kontrakt)
+ - `from` určuje podepisujícího transakce (připojená adresa uživatele k MetaMasku: `window.ethereum.selectedAddress`)
+ - `data` obsahuje volání metody `mintNFT` našeho chytrého kontraktu, která jako vstup přijímá náš `tokenURI` a adresu peněženky uživatele, `window.ethereum.selectedAddress`
+- Poté provedeme await volání `window.ethereum.request`, kde požádáme MetaMask o podepsání transakce. Všimněte si, že v tomto požadavku specifikujeme naši eth metodu (eth_SentTransaction) a předáváme naše `transactionParameters`. V tomto okamžiku se v prohlížeči otevře MetaMask a vyzve uživatele k podepsání nebo zamítnutí transakce.
+ - Pokud je transakce úspěšná, funkce vrátí objekt JSON, kde je booleovská hodnota `success` nastavena na true a řetězec `status` vyzve uživatele, aby se podíval na Etherscan pro více informací o své transakci.
+ - Pokud transakce selže, funkce vrátí objekt JSON, kde je booleovská hodnota `success` nastavena na false a řetězec `status` sděluje chybovou zprávu.
+
+Celkově by naše funkce `mintNFT` měla vypadat takto:
+
+```javascript
+export const mintNFT = async (url, name, description) => {
+ //zpracování chyb
+ if (url.trim() == "" || name.trim() == "" || description.trim() == "") {
+ return {
+ success: false,
+ status: "❗Před mintováním se prosím ujistěte, že jsou všechna pole vyplněna.",
+ }
+ }
+
+ //vytvořit metadata
+ const metadata = new Object()
+ metadata.name = name
+ metadata.image = url
+ metadata.description = description
+
+ //žádost o připnutí pinata
+ const pinataResponse = await pinJSONToIPFS(metadata)
+ if (!pinataResponse.success) {
+ return {
+ success: false,
+ status: "😢 Něco se pokazilo při nahrávání vašeho tokenURI.",
+ }
+ }
+ const tokenURI = pinataResponse.pinataUrl
+
+ //načíst chytrý kontrakt
+ window.contract = await new web3.eth.Contract(contractABI, contractAddress) //loadContract();
+
+ //nastavte si svou transakci Ethereum
+ const transactionParameters = {
+ to: contractAddress, // Povinné s výjimkou zveřejnění kontraktu.
+ from: window.ethereum.selectedAddress, // musí odpovídat aktivní adrese uživatele.
+ data: window.contract.methods
+ .mintNFT(window.ethereum.selectedAddress, tokenURI)
+ .encodeABI(), //provést volání chytrého kontraktu NFT
+ }
+
+ //podepsat transakci přes MetaMask
+ try {
+ const txHash = await window.ethereum.request({
+ method: "eth_sendTransaction",
+ params: [transactionParameters],
+ })
+ return {
+ success: true,
+ status:
+ "✅ Podívejte se na svou transakci na Etherscanu: https://ropsten.etherscan.io/tx/" +
+ txHash,
+ }
+ } catch (error) {
+ return {
+ success: false,
+ status: "😥 Něco se pokazilo: " + error.message,
+ }
+ }
+}
+```
+
+To je jedna obrovská funkce! Nyní už jen stačí připojit naši funkci `mintNFT` k naší komponentě `Minter.js`...
+
+## Připojte mintNFT k našemu frontendu Minter.js {#connect-our-frontend}
+
+Otevřete svůj soubor `Minter.js` a aktualizujte řádek `import { connectWallet, getCurrentWalletConnected } from \"./utils/interact.js\";` na začátku na:
+
+```javascript
+import {
+ connectWallet,
+ getCurrentWalletConnected,
+ mintNFT,
+} from "./utils/interact.js"
+```
+
+Nakonec implementujte funkci `onMintPressed`, abyste provedli await volání na vaši importovanou funkci `mintNFT` a aktualizovali stavovou proměnnou `status` tak, aby odrážela, zda naše transakce uspěla nebo selhala:
+
+```javascript
+const onMintPressed = async () => {
+ const { status } = await mintNFT(url, name, description)
+ setStatus(status)
+}
+```
+
+## Nasaďte své NFT na živou webovou stránku {#deploy-your-NFT}
+
+Jste připraveni uvést svůj projekt do provozu, aby s ním uživatelé mohli interagovat? Podívejte se na [tento návod](https://docs.alchemy.com/alchemy/tutorials/nft-minter/how-do-i-deploy-nfts-online) pro nasazení vašeho Minteru na živou webovou stránku.
+
+Ještě poslední krok...
+
+## Dobijte svět blockchainu {#take-the-blockchain-world-by-storm}
+
+Děláme si legraci, dostali jste se až na konec návodu!
+
+Abychom to shrnuli, vytvořením minteru NFT jste se úspěšně naučili, jak:
+
+- Připojit se k MetaMasku prostřednictvím vašeho frontendového projektu
+- Volat metody chytrého kontraktu z vašeho frontendu
+- Podepisovat transakce pomocí MetaMasku
+
+Pravděpodobně se budete chtít pochlubit NFT vyraženými prostřednictvím vaší dapp ve své peněžence – proto se určitě podívejte na náš rychlý návod [Jak si zobrazit NFT ve vaší peněžence](https://www.alchemy.com/docs/how-to-view-your-nft-in-your-mobile-wallet)!
+
+A jako vždy, pokud máte nějaké dotazy, jsme tu, abychom vám pomohli na [Alchemy Discordu](https://discord.gg/gWuC7zB). Nemůžeme se dočkat, až uvidíme, jak koncepty z tohoto návodu uplatníte ve svých budoucích projektech!
diff --git a/public/content/translations/cs/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/cs/developers/tutorials/optimism-std-bridge-annotated-code/index.md
new file mode 100644
index 00000000000..75306dbbe12
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/optimism-std-bridge-annotated-code/index.md
@@ -0,0 +1,1356 @@
+---
+title: "Procházení kontraktu standardního přemostění Optimism"
+description: Jak funguje standardní přemostění pro Optimism? Proč to funguje zrovna takhle?
+author: Ori Pomerantz
+tags: [ "solidity", "přemostění", "vrstva 2" ]
+skill: intermediate
+published: 2022-03-30
+lang: cs
+---
+
+[Optimism](https://www.optimism.io/) je [optimistický rollup](/developers/docs/scaling/optimistic-rollups/).
+Optimistické rollupy mohou zpracovávat transakce za mnohem nižší cenu než hlavní síť Ethereum (také známá jako první vrstva nebo L1), protože transakce zpracovává jen několik uzlů, nikoli každý uzel v síti.
+Všechna data jsou přitom zapsána na L1, takže vše lze prokázat a rekonstruovat se všemi zárukami integrity a dostupnosti hlavní sítě.
+
+Aby bylo možné používat aktiva z L1 v síti Optimism (nebo v jakékoli jiné L2), je třeba je [přemostit](/bridges/#prerequisites).
+Jedním ze způsobů, jak toho dosáhnout, je, že uživatelé uzamknou aktiva (nejčastěji se jedná o ETH a [tokeny ERC-20](/developers/docs/standards/tokens/erc-20/)) na L1 a obdrží ekvivalentní aktiva k použití na L2.
+Nakonec je může chtít ten, kdo je získá, přemostit zpět na L1.
+Přitom se aktiva na L2 spálí a poté se na L1 uvolní zpět uživateli.
+
+Takto funguje [standardní přemostění Optimism](https://docs.optimism.io/app-developers/bridging/standard-bridge).
+V tomto článku si projdeme zdrojový kód tohoto přemostění, abychom viděli, jak funguje, a prostudujeme si jej jako příklad dobře napsaného kódu v Solidity.
+
+## Kontrolní toky {#control-flows}
+
+Přemostění má dva hlavní toky:
+
+- Vklad (z L1 na L2)
+- Výběr (z L2 na L1)
+
+### Tok vkladů {#deposit-flow}
+
+#### Vrstva 1 {#deposit-flow-layer-1}
+
+1. Při vkladu tokenu ERC-20 udělí vkladatel přemostění povolení k útratě vkládané částky.
+2. Vkladatel zavolá přemostění na L1 (`depositERC20`, `depositERC20To`, `depositETH` nebo `depositETHTo`).
+3. Přemostění na L1 převezme přemostěné aktivum.
+ - ETH: Aktivum je převedeno vkladatelem jako součást volání.
+ - ERC-20: Aktivum je přemostěním převedeno samo sobě pomocí povolení poskytnutého vkladatelem.
+4. Přemostění na L1 použije mezidoménový mechanismus zpráv k zavolání `finalizeDeposit` na přemostění na L2.
+
+#### Vrstva 2 {#deposit-flow-layer-2}
+
+5. Přemostění na L2 ověří, že volání `finalizeDeposit` je legitimní:
+ - Pochází z mezidoménového kontraktu zpráv.
+ - Původně pocházelo z přemostění na L1.
+6. Přemostění na L2 zkontroluje, zda je kontrakt tokenu ERC-20 na L2 správný:
+ - Kontrakt na L2 hlásí, že jeho protějšek na L1 je stejný jako ten, ze kterého tokeny na L1 pocházejí.
+ - Kontrakt na L2 hlásí, že podporuje správné rozhraní ([pomocí ERC-165](https://eips.ethereum.org/EIPS/eip-165)).
+7. Pokud je kontrakt L2 správný, zavolejte jej, aby vyrazil příslušný počet tokenů na příslušnou adresu. Pokud ne, zahajte proces výběru, který uživateli umožní nárokovat tokeny na L1.
+
+### Tok výběrů {#withdrawal-flow}
+
+#### Vrstva 2 {#withdrawal-flow-layer-2}
+
+1. Vybírající zavolá přemostění L2 (`withdraw` nebo `withdrawTo`).
+2. Přemostění L2 spálí příslušný počet tokenů patřících `msg.sender`.
+3. Přemostění L2 použije mezidoménový mechanismus zpráv k zavolání `finalizeETHWithdrawal` nebo `finalizeERC20Withdrawal` na přemostění na L1.
+
+#### Vrstva 1 {#withdrawal-flow-layer-1}
+
+4. Přemostění na L1 ověří, že volání `finalizeETHWithdrawal` nebo `finalizeERC20Withdrawal` je legitimní:
+ - Pochází z mezidoménového mechanismu zpráv.
+ - Původně pocházelo z přemostění na L2.
+5. Přemostění na L1 převede příslušné aktivum (ETH nebo ERC-20) na příslušnou adresu.
+
+## Kód na vrstvě 1 {#layer-1-code}
+
+Toto je kód, který běží na L1, tedy hlavní síti Etherea.
+
+### IL1ERC20Bridge {#IL1ERC20Bridge}
+
+[Toto rozhraní je definováno zde](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1ERC20Bridge.sol).
+Obsahuje funkce a definice potřebné pro přemostění tokenů ERC-20.
+
+```solidity
+// SPDX-License-Identifier: MIT
+```
+
+[Většina kódu Optimism je vydána pod licencí MIT](https://help.optimism.io/hc/en-us/articles/4411908707995-What-software-license-does-Optimism-use-).
+
+```solidity
+pragma solidity >0.5.0 <0.9.0;
+```
+
+V době psaní je poslední verze Solidity 0.8.12.
+Dokud nebude vydána verze 0.9.0, nevíme, zda s ní tento kód bude kompatibilní.
+
+```solidity
+/**
+ * @title IL1ERC20Bridge
+ */
+interface IL1ERC20Bridge {
+ /**********
+ * Události *
+ **********/
+
+ event ERC20DepositInitiated(
+```
+
+V terminologii přemostění Optimism znamená _vklad_ převod z L1 na L2 a _výběr_ převod z L2 na L1.
+
+```solidity
+ address indexed _l1Token,
+ address indexed _l2Token,
+```
+
+Ve většině případů se adresa ERC-20 na L1 nerovná adrese ekvivalentního ERC-20 na L2.
+[Seznam adres tokenů naleznete zde](https://static.optimism.io/optimism.tokenlist.json).
+Adresa s `chainId` 1 je na L1 (hlavní síť) a adresa s `chainId` 10 je na L2 (Optimism).
+Další dvě hodnoty `chainId` jsou pro testovací síť Kovan (42) a testovací síť Optimistic Kovan (69).
+
+```solidity
+ address indexed _from,
+ address _to,
+ uint256 _amount,
+ bytes _data
+ );
+```
+
+K převodům je možné přidávat poznámky, které se v takovém případě přidají k událostem, jež je hlásí.
+
+```solidity
+ event ERC20WithdrawalFinalized(
+ address indexed _l1Token,
+ address indexed _l2Token,
+ address indexed _from,
+ address _to,
+ uint256 _amount,
+ bytes _data
+ );
+```
+
+Stejný kontrakt přemostění zpracovává převody v obou směrech.
+V případě přemostění L1 to znamená inicializaci vkladů a finalizaci výběrů.
+
+```solidity
+
+ /********************
+ * Veřejné funkce *
+ ********************/
+
+ /**
+ * @dev získá adresu odpovídajícího kontraktu přemostění na L2.
+ * @return Adresa odpovídajícího kontraktu přemostění na L2.
+ */
+ function l2TokenBridge() external returns (address);
+```
+
+Tato funkce není ve skutečnosti potřeba, protože na L2 se jedná o předem nasazený kontrakt, takže se vždy nachází na adrese `0x4200000000000000000000000000000000000010`.
+Je zde z důvodu symetrie s přemostěním L2, protože adresa přemostění L1 _není_ triviálně zjistitelná.
+
+```solidity
+ /**
+ * @dev vloží částku ERC20 na zůstatek volajícího na L2.
+ * @param _l1Token Adresa ERC20 na L1, který vkládáme.
+ * @param _l2Token Adresa příslušného ERC20 na L2.
+ * @param _amount Částka ERC20 k vložení.
+ * @param _l2Gas Limit transakčních poplatků potřebný k dokončení vkladu na L2.
+ * @param _data Volitelná data k předání na L2. Tato data jsou poskytována
+ * pouze pro pohodlí externích kontraktů. Kromě vynucení maximální
+ * délky tyto kontrakty neposkytují žádné záruky ohledně jejich obsahu.
+ */
+ function depositERC20(
+ address _l1Token,
+ address _l2Token,
+ uint256 _amount,
+ uint32 _l2Gas,
+ bytes calldata _data
+ ) external;
+```
+
+Parametr `_l2Gas` je množství transakčního poplatku na L2, které může transakce utratit.
+[Až do určitého (vysokého) limitu je to zdarma](https://community.optimism.io/docs/developers/bridge/messaging/#for-l1-%E2%87%92-l2-transactions-2), takže pokud kontrakt ERC-20 nedělá při ražbě něco opravdu zvláštního, neměl by to být problém.
+Tato funkce se stará o běžný scénář, kdy uživatel přemosťuje aktiva na stejnou adresu na jiném blockchainu.
+
+```solidity
+ /**
+ * @dev vloží částku ERC20 na zůstatek příjemce na L2.
+ * @param _l1Token Adresa ERC20 na L1, který vkládáme.
+ * @param _l2Token Adresa příslušného ERC20 na L2.
+ * @param _to Adresa na L2, na kterou se připíše výběr.
+ * @param _amount Částka ERC20 k vložení.
+ * @param _l2Gas Limit transakčních poplatků potřebný k dokončení vkladu na L2.
+ * @param _data Volitelná data k předání na L2. Tato data jsou poskytována
+ * pouze pro pohodlí externích kontraktů. Kromě vynucení maximální
+ * délky tyto kontrakty neposkytují žádné záruky ohledně jejich obsahu.
+ */
+ function depositERC20To(
+ address _l1Token,
+ address _l2Token,
+ address _to,
+ uint256 _amount,
+ uint32 _l2Gas,
+ bytes calldata _data
+ ) external;
+```
+
+Tato funkce je téměř identická s `depositERC20`, ale umožňuje poslat ERC-20 na jinou adresu.
+
+```solidity
+} /*************************
+ * Meziřetězcové funkce *
+ *************************/
+
+ /**
+ * @dev Dokončí výběr z L2 na L1 a připíše prostředky na zůstatek příjemce
+ * tokenu ERC20 na L1.
+ * Toto volání selže, pokud inicializovaný výběr z L2 nebyl finalizován.
+ *
+ * @param _l1Token Adresa tokenu na L1, pro který se má dokončit výběr.
+ * @param _l2Token Adresa tokenu na L2, kde byl výběr iniciován.
+ * @param _from Adresa na L2, která iniciuje převod.
+ * @param _to Adresa na L1, na kterou se má výběr připsat.
+ * @param _amount Částka ERC20 k vložení.
+ * @param _data Data poskytnutá odesílatelem na L2. Tato data jsou poskytována
+ * pouze pro pohodlí externích kontraktů. Kromě vynucení maximální
+ * délky tyto kontrakty neposkytují žádné záruky ohledně jejich obsahu.
+ */
+ function finalizeERC20Withdrawal(
+ address _l1Token,
+ address _l2Token,
+ address _from,
+ address _to,
+ uint256 _amount,
+ bytes calldata _data
+ ) external;
+}
+```
+
+Výběry (a další zprávy z L2 do L1) v Optimism jsou dvoukrokový proces:
+
+1. Iniciační transakce na L2.
+2. Finalizační nebo nárokovací transakce na L1.
+ Tato transakce se musí uskutečnit po skončení [období pro napadení chyb](https://community.optimism.io/docs/how-optimism-works/#fault-proofs) pro transakci na L2.
+
+### IL1StandardBridge {#il1standardbridge}
+
+[Toto rozhraní je definováno zde](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1StandardBridge.sol).
+Tento soubor obsahuje definice událostí a funkcí pro ETH.
+Tyto definice jsou velmi podobné těm, které jsou definovány v `IL1ERC20Bridge` výše pro ERC-20.
+
+Rozhraní přemostění je rozděleno do dvou souborů, protože některé tokeny ERC-20 vyžadují vlastní zpracování a standardní přemostění je nemůže zpracovat.
+Tímto způsobem může vlastní přemostění, které takový token zpracovává, implementovat `IL1ERC20Bridge` a nemusí přemosťovat také ETH.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity >0.5.0 <0.9.0;
+
+import "./IL1ERC20Bridge.sol";
+
+/**
+ * @title IL1StandardBridge
+ */
+interface IL1StandardBridge is IL1ERC20Bridge {
+ /**********
+ * Události *
+ **********/
+ event ETHDepositInitiated(
+ address indexed _from,
+ address indexed _to,
+ uint256 _amount,
+ bytes _data
+ );
+```
+
+Tato událost je téměř totožná s verzí ERC-20 (`ERC20DepositInitiated`), pouze bez adres tokenů L1 a L2.
+Totéž platí pro ostatní události a funkce.
+
+```solidity
+ event ETHWithdrawalFinalized(
+ .
+ .
+ .
+ );
+
+ /********************
+ * Veřejné funkce *
+ ********************/
+
+ /**
+ * @dev Vloží částku ETH na zůstatek volajícího na L2.
+ .
+ .
+ .
+ */
+ function depositETH(uint32 _l2Gas, bytes calldata _data) external payable;
+
+ /**
+ * @dev Vloží částku ETH na zůstatek příjemce na L2.
+ .
+ .
+ .
+ */
+ function depositETHTo(
+ address _to,
+ uint32 _l2Gas,
+ bytes calldata _data
+ ) external payable;
+
+ /*************************
+ * Meziřetězcové funkce *
+ *************************/
+
+ /**
+ * @dev Dokončí výběr z L2 na L1 a připíše prostředky na zůstatek příjemce
+ * tokenu ETH na L1. Protože tuto funkci může volat pouze xDomainMessenger, nebude nikdy volána
+ * před dokončením výběru.
+ .
+ .
+ .
+ */
+ function finalizeETHWithdrawal(
+ address _from,
+ address _to,
+ uint256 _amount,
+ bytes calldata _data
+ ) external;
+}
+```
+
+### CrossDomainEnabled {#crossdomainenabled}
+
+[Tento kontrakt](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/CrossDomainEnabled.sol) je zděděn oběma přemostěními ([L1](#the-l1-bridge-contract) a [L2](#the-l2-bridge-contract)) pro posílání zpráv na druhou vrstvu.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity >0.5.0 <0.9.0;
+
+/* Importy rozhraní */
+import { ICrossDomainMessenger } from "./ICrossDomainMessenger.sol";
+```
+
+[Toto rozhraní](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/ICrossDomainMessenger.sol) říká kontraktu, jak posílat zprávy na druhou vrstvu pomocí mezidoménového posílače zpráv.
+Tento mezidoménový posílač zpráv je zcela jiný systém a zaslouží si vlastní článek, který, doufám, v budoucnu napíšu.
+
+```solidity
+/**
+ * @title CrossDomainEnabled
+ * @dev Pomocný kontrakt pro kontrakty provádějící mezidoménovou komunikaci
+ *
+ * Použitý kompilátor: definován dědícím kontraktem
+ */
+contract CrossDomainEnabled {
+ /*************
+ * Proměnné *
+ *************/
+
+ // Kontrakt Messengeru použitý k odesílání a přijímání zpráv z druhé domény.
+ address public messenger;
+
+ /***************
+ * Konstruktor *
+ ***************/
+
+ /**
+ * @param _messenger Adresa CrossDomainMessenger na aktuální vrstvě.
+ */
+ constructor(address _messenger) {
+ messenger = _messenger;
+ }
+```
+
+Jediný parametr, který kontrakt potřebuje znát, je adresa mezidoménového posílače zpráv na této vrstvě.
+Tento parametr je nastaven jednou, v konstruktoru, a nikdy se nemění.
+
+```solidity
+
+ /**********************
+ * Modifikátory funkcí *
+ **********************/
+
+ /**
+ * Vynucuje, aby upravená funkce byla volána pouze z konkrétního mezidoménového účtu.
+ * @param _sourceDomainAccount Jediný účet na původní doméně, který je
+ * oprávněn tuto funkci volat.
+ */
+ modifier onlyFromCrossDomainAccount(address _sourceDomainAccount) {
+```
+
+Mezidoménové zasílání zpráv je dostupné jakémukoli kontraktu na blockchainu, kde běží (buď na hlavní síti Etherea, nebo Optimism).
+Potřebujeme ale, aby přemostění na každé straně důvěřovalo _pouze_ určitým zprávám, pokud pocházejí z přemostění na druhé straně.
+
+```solidity
+ require(
+ msg.sender == address(getCrossDomainMessenger()),
+ "OVM_XCHAIN: kontrakt posílače zpráv není ověřený"
+ );
+```
+
+Důvěřovat lze pouze zprávám z příslušného mezidoménového posílače zpráv (`messenger`, jak uvidíte níže).
+
+```solidity
+
+ require(
+ getCrossDomainMessenger().xDomainMessageSender() == _sourceDomainAccount,
+ "OVM_XCHAIN: nesprávný odesílatel mezidoménové zprávy"
+ );
+```
+
+Způsob, jakým mezidoménový posílač zpráv poskytuje adresu, která odeslala zprávu z druhé vrstvy, je [funkce `.xDomainMessageSender()`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1CrossDomainMessenger.sol#L122-L128).
+Pokud je volána v transakci, která byla zprávou iniciována, může tyto informace poskytnout.
+
+Musíme se ujistit, že zpráva, kterou jsme obdrželi, pochází z druhého přemostění.
+
+```solidity
+
+ _;
+ }
+
+ /**********************
+ * Interní funkce *
+ **********************/
+
+ /**
+ * Získá posílače zpráv, obvykle z úložiště. Tato funkce je vystavena pro případ, že by ji
+ * dětský kontrakt potřeboval přepsat.
+ * @return Adresa kontraktu mezidoménového posílače zpráv, který by se měl použít.
+ */
+ function getCrossDomainMessenger() internal virtual returns (ICrossDomainMessenger) {
+ return ICrossDomainMessenger(messenger);
+ }
+```
+
+Tato funkce vrací mezidoménového posílače zpráv.
+Používáme funkci spíše než proměnnou `messenger`, aby kontrakty, které z ní dědí, mohly použít algoritmus k určení, který mezidoménový posílač zpráv použít.
+
+```solidity
+
+ /**
+ * Odešle zprávu účtu v jiné doméně.
+ * @param _crossDomainTarget Zamýšlený příjemce v cílové doméně.
+ * @param _message Data k odeslání cíli (obvykle calldata pro funkci s
+ * `onlyFromCrossDomainAccount()`)
+ * @param _gasLimit Limit transakčních poplatků pro příjem zprávy v cílové doméně.
+ */
+ function sendCrossDomainMessage(
+ address _crossDomainTarget,
+ uint32 _gasLimit,
+ bytes memory _message
+```
+
+A nakonec funkce, která posílá zprávu na druhou vrstvu.
+
+```solidity
+ ) internal {
+ // slither-disable-next-line reentrancy-events, reentrancy-benign
+```
+
+[Slither](https://github.com/crytic/slither) je statický analyzátor, který Optimism spouští na každém kontraktu, aby hledal zranitelnosti a další potenciální problémy.
+V tomto případě následující řádek spouští dvě zranitelnosti:
+
+1. [Události opětovného vstupu (reentrancy)](https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities-3)
+2. [Nezávažné opětovné vstupy (reentrancy)](https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities-2)
+
+```solidity
+ getCrossDomainMessenger().sendMessage(_crossDomainTarget, _message, _gasLimit);
+ }
+}
+```
+
+V tomto případě se o opětovné vstupy (reentrancy) nestaráme, protože víme, že `getCrossDomainMessenger()` vrací důvěryhodnou adresu, i když Slither to nemá jak vědět.
+
+### Kontrakt přemostění L1 {#the-l1-bridge-contract}
+
+[Zdrojový kód tohoto kontraktu je zde](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1StandardBridge.sol).
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.9;
+```
+
+Rozhraní mohou být součástí jiných kontraktů, takže musí podporovat širokou škálu verzí Solidity.
+Ale samotné přemostění je náš kontrakt a můžeme být přísní ohledně toho, jakou verzi Solidity používá.
+
+```solidity
+/* Importy rozhraní */
+import { IL1StandardBridge } from "./IL1StandardBridge.sol";
+import { IL1ERC20Bridge } from "./IL1ERC20Bridge.sol";
+```
+
+[IL1ERC20Bridge](#IL1ERC20Bridge) a [IL1StandardBridge](#IL1StandardBridge) jsou vysvětleny výše.
+
+```solidity
+import { IL2ERC20Bridge } from "../../L2/messaging/IL2ERC20Bridge.sol";
+```
+
+[Toto rozhraní](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol) nám umožňuje vytvářet zprávy pro ovládání standardního přemostění na L2.
+
+```solidity
+import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
+```
+
+[Toto rozhraní](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) nám umožňuje ovládat kontrakty ERC-20.
+[Více si o tom můžete přečíst zde](/developers/tutorials/erc20-annotated-code/#the-interface).
+
+```solidity
+/* Importy knihoven */
+import { CrossDomainEnabled } from "../../libraries/bridge/CrossDomainEnabled.sol";
+```
+
+[Jak je vysvětleno výše](#crossdomainenabled), tento kontrakt se používá pro mezivrstvové zasílání zpráv.
+
+```solidity
+import { Lib_PredeployAddresses } from "../../libraries/constants/Lib_PredeployAddresses.sol";
+```
+
+`Lib_PredeployAddresses` (https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/constants/Lib_PredeployAddresses.sol) má adresy kontraktů L2, které mají vždy stejnou adresu. To zahrnuje standardní přemostění na L2.
+
+```solidity
+import { Address } from "@openzeppelin/contracts/utils/Address.sol";
+```
+
+[Nástroje pro adresy OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Address.sol). Používá se k rozlišení mezi adresami kontraktů a adresami patřícími externě vlastněným účtům (EOA).
+
+Všimněte si, že se nejedná o dokonalé řešení, protože neexistuje způsob, jak rozlišit mezi přímými voláními a voláními provedenými z konstruktoru kontraktu, ale alespoň nám to umožňuje identifikovat a zabránit některým běžným chybám uživatelů.
+
+```solidity
+import { SafeERC20 } from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
+```
+
+[Standard ERC-20](https://eips.ethereum.org/EIPS/eip-20) podporuje dva způsoby, jak může kontrakt nahlásit selhání:
+
+1. Zpětné vrácení (revert)
+2. Vrátit `false`
+
+Zpracování obou případů by náš kód zkomplikovalo, takže místo toho používáme [`SafeERC20` od OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol), který zajišťuje, že [všechna selhání vedou k zpětnému vrácení (revert)](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol#L96).
+
+```solidity
+/**
+ * @title L1StandardBridge
+ * @dev Přemostění L1 pro ETH a ERC20 je kontrakt, který ukládá vložené prostředky z L1 a standardní
+ * tokeny, které se používají na L2. Synchronizuje odpovídající přemostění L2, informuje ho o vkladech
+ * a naslouchá mu pro nově finalizované výběry.
+ *
+ */
+contract L1StandardBridge is IL1StandardBridge, CrossDomainEnabled {
+ using SafeERC20 for IERC20;
+```
+
+Tento řádek určuje, že se má použít obal `SafeERC20` pokaždé, když použijeme rozhraní `IERC20`.
+
+```solidity
+
+ /********************************
+ * Reference na externí kontrakty *
+ ********************************/
+
+ address public l2TokenBridge;
+```
+
+Adresa [L2StandardBridge](#the-l2-bridge-contract).
+
+```solidity
+
+ // Mapuje token L1 na token L2 k zůstatku vloženého tokenu L1
+ mapping(address => mapping(address => uint256)) public deposits;
+```
+
+Dvojité [mapování](https://www.tutorialspoint.com/solidity/solidity_mappings.htm) jako je toto, je způsob, jak definovat [dvojrozměrné řídké pole](https://en.wikipedia.org/wiki/Sparse_matrix).
+Hodnoty v této datové struktuře jsou identifikovány jako `deposit[adresa tokenu L1][adresa tokenu L2]`.
+Výchozí hodnota je nula.
+Do úložiště jsou zapsány pouze buňky, které jsou nastaveny na jinou hodnotu.
+
+```solidity
+
+ /***************
+ * Konstruktor *
+ ***************/
+
+ // Tento kontrakt se nachází za proxy, takže parametry konstruktoru nebudou použity.
+ constructor() CrossDomainEnabled(address(0)) {}
+```
+
+Chceme mít možnost upgradovat tento kontrakt bez nutnosti kopírovat všechny proměnné v úložišti.
+K tomu používáme [`Proxy`](https://docs.openzeppelin.com/contracts/3.x/api/proxy), kontrakt, který používá [`delegatecall`](https://solidity-by-example.org/delegatecall/) k přenosu volání na samostatný kontrakt, jehož adresa je uložena v proxy kontraktu (při upgradu řeknete proxy, aby změnila tuto adresu).
+Při použití `delegatecall` zůstává úložiště úložištěm _volajícího_ kontraktu, takže hodnoty všech proměnných stavu kontraktu zůstávají nedotčeny.
+
+Jedním z důsledků tohoto vzoru je, že úložiště kontraktu, který je _volaný_ pomocí `delegatecall`, se nepoužívá, a proto hodnoty konstruktoru, které mu jsou předány, nejsou důležité.
+To je důvod, proč můžeme konstruktoru `CrossDomainEnabled` poskytnout nesmyslnou hodnotu.
+Je to také důvod, proč je níže uvedená inicializace oddělena od konstruktoru.
+
+```solidity
+ /******************
+ * Inicializace *
+ ******************/
+
+ /**
+ * @param _l1messenger Adresa L1 Messengeru používaná pro meziřetězcovou komunikaci.
+ * @param _l2TokenBridge Adresa standardního přemostění na L2.
+ */
+ // slither-disable-next-line external-function
+```
+
+Tento [test Slither](https://github.com/crytic/slither/wiki/Detector-Documentation#public-function-that-could-be-declared-external) identifikuje funkce, které nejsou volány z kódu kontraktu a mohly by být proto deklarovány jako `external` místo `public`.
+Náklady na transakční poplatky u funkcí `external` mohou být nižší, protože jim mohou být parametry poskytnuty v calldata.
+Funkce deklarované jako `public` musí být přístupné zevnitř kontraktu.
+Kontrakty nemohou měnit svá vlastní calldata, takže parametry musí být v paměti.
+Když je taková funkce volána externě, je nutné zkopírovat calldata do paměti, což stojí transakční poplatky.
+V tomto případě je funkce volána pouze jednou, takže neefektivita pro nás není důležitá.
+
+```solidity
+ function initialize(address _l1messenger, address _l2TokenBridge) public {
+ require(messenger == address(0), "Kontrakt již byl inicializován.");
+```
+
+Funkce `initialize` by měla být volána pouze jednou.
+Pokud se adresa mezidoménového posílače zpráv na L1 nebo přemostění tokenu na L2 změní, vytvoříme nové proxy a nové přemostění, které ho volá.
+Je nepravděpodobné, že by k tomu došlo, s výjimkou upgradu celého systému, což je velmi vzácná událost.
+
+Všimněte si, že tato funkce nemá žádný mechanismus, který by omezoval, _kdo_ ji může volat.
+To znamená, že teoreticky by útočník mohl počkat, až nasadíme proxy a první verzi přemostění, a poté provést [front-running](https://solidity-by-example.org/hacks/front-running/) a dostat se k funkci `initialize` dříve, než to udělá legitimní uživatel. Existují však dvě metody, jak tomu zabránit:
+
+1. Pokud kontrakty nejsou nasazeny přímo pomocí EOA, ale [v transakci, která nechá vytvořit jiný kontrakt](https://medium.com/upstate-interactive/creating-a-contract-with-a-smart-contract-bdb67c5c8595), celý proces může být atomický a dokončen dříve, než je provedena jakákoli jiná transakce.
+2. Pokud legitimní volání `initialize` selže, je vždy možné ignorovat nově vytvořené proxy a přemostění a vytvořit nové.
+
+```solidity
+ messenger = _l1messenger;
+ l2TokenBridge = _l2TokenBridge;
+ }
+```
+
+Toto jsou dva parametry, které přemostění potřebuje znát.
+
+```solidity
+
+ /**************
+ * Vkládání *
+ **************/
+
+ /** @dev Modifikátor vyžadující, aby odesílatel byl EOA. Toto ověření by mohl obejít zákeřný
+ * kontrakt pomocí initcode, ale řeší to chybu uživatele, které se chceme vyhnout.
+ */
+ modifier onlyEOA() {
+ // Používá se k zastavení vkladů z kontraktů (zabraňuje náhodné ztrátě tokenů)
+ require(!Address.isContract(msg.sender), "Účet není EOA");
+ _;
+ }
+```
+
+To je důvod, proč jsme potřebovali nástroje `Address` od OpenZeppelin.
+
+```solidity
+ /**
+ * @dev Tuto funkci lze volat bez dat
+ * pro vložení částky ETH na zůstatek volajícího na L2.
+ * Protože funkce receive nepřijímá data, konzervativní
+ * výchozí částka se předává na L2.
+ */
+ receive() external payable onlyEOA {
+ _initiateETHDeposit(msg.sender, msg.sender, 200_000, bytes(""));
+ }
+```
+
+Tato funkce existuje pro testovací účely.
+Všimněte si, že se neobjevuje v definicích rozhraní – není určena pro běžné použití.
+
+```solidity
+ /**
+ * @inheritdoc IL1StandardBridge
+ */
+ function depositETH(uint32 _l2Gas, bytes calldata _data) external payable onlyEOA {
+ _initiateETHDeposit(msg.sender, msg.sender, _l2Gas, _data);
+ }
+
+ /**
+ * @inheritdoc IL1StandardBridge
+ */
+ function depositETHTo(
+ address _to,
+ uint32 _l2Gas,
+ bytes calldata _data
+ ) external payable {
+ _initiateETHDeposit(msg.sender, _to, _l2Gas, _data);
+ }
+```
+
+Tyto dvě funkce jsou obaly kolem `_initiateETHDeposit`, funkce, která zpracovává skutečný vklad ETH.
+
+```solidity
+ /**
+ * @dev Provádí logiku pro vklady uložením ETH a informováním L2 ETH Gateway o
+ * vkladu.
+ * @param _from Účet, ze kterého se má vklad na L1 stáhnout.
+ * @param _to Účet, na který se má vklad na L2 připsat.
+ * @param _l2Gas Limit transakčních poplatků potřebný k dokončení vkladu na L2.
+ * @param _data Volitelná data k předání na L2. Tato data jsou poskytována
+ * pouze pro pohodlí externích kontraktů. Kromě vynucení maximální
+ * délky tyto kontrakty neposkytují žádné záruky ohledně jejich obsahu.
+ */
+ function _initiateETHDeposit(
+ address _from,
+ address _to,
+ uint32 _l2Gas,
+ bytes memory _data
+ ) internal {
+ // Sestavení calldata pro volání finalizeDeposit
+ bytes memory message = abi.encodeWithSelector(
+```
+
+Způsob, jakým fungují mezidoménové zprávy, je ten, že cílový kontrakt je volán se zprávou jako jeho calldata.
+Kontrakty v Solidity vždy interpretují svá calldata v souladu s
+[specifikacemi ABI](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html).
+Funkce Solidity [`abi.encodeWithSelector`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#abi-encoding-and-decoding-functions) vytváří tato calldata.
+
+```solidity
+ IL2ERC20Bridge.finalizeDeposit.selector,
+ address(0),
+ Lib_PredeployAddresses.OVM_ETH,
+ _from,
+ _to,
+ msg.value,
+ _data
+ );
+```
+
+Zpráva zde znamená volání [funkce `finalizeDeposit`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol#L141-L148) s těmito parametry:
+
+| Parametr | Hodnota | Význam |
+| ------------------------------- | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| \_l1Token | address(0) | Speciální hodnota, která na L1 představuje ETH (který není tokenem ERC-20). |
+| \_l2Token | Lib_PredeployAddresses.OVM_ETH | Kontrakt na L2, který spravuje ETH v síti Optimism, `0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000` (tento kontrakt je určen pouze pro interní použití v síti Optimism). |
+| \_from | \_from | Adresa na L1, která odesílá ETH. |
+| \_to | \_to | Adresa na L2, která přijímá ETH. |
+| částka | msg.value | Odeslaná částka ve wei (která již byla odeslána do přemostění). |
+| \_data | \_data | Další data, která se připojí k vkladu. |
+
+```solidity
+ // Odeslání calldata na L2
+ // slither-disable-next-line reentrancy-events
+ sendCrossDomainMessage(l2TokenBridge, _l2Gas, message);
+```
+
+Odeslání zprávy prostřednictvím mezidoménového posílače zpráv.
+
+```solidity
+ // slither-disable-next-line reentrancy-events
+ emit ETHDepositInitiated(_from, _to, msg.value, _data);
+ }
+```
+
+Vyslat událost, aby se o tomto převodu informovala jakákoli decentralizovaná aplikace, která naslouchá.
+
+```solidity
+ /**
+ * @inheritdoc IL1ERC20Bridge
+ */
+ function depositERC20(
+ .
+ .
+ .
+ ) external virtual onlyEOA {
+ _initiateERC20Deposit(_l1Token, _l2Token, msg.sender, msg.sender, _amount, _l2Gas, _data);
+ }
+
+ /**
+ * @inheritdoc IL1ERC20Bridge
+ */
+ function depositERC20To(
+ .
+ .
+ .
+ ) external virtual {
+ _initiateERC20Deposit(_l1Token, _l2Token, msg.sender, _to, _amount, _l2Gas, _data);
+ }
+```
+
+Tyto dvě funkce jsou obaly kolem `_initiateERC20Deposit`, funkce, která zpracovává skutečný vklad ERC-20.
+
+```solidity
+ /**
+ * @dev Provádí logiku pro vklady informováním kontraktu L2 Deposited Token
+ * o vkladu a voláním handleru pro uzamčení prostředků L1. (např. transferFrom)
+ *
+ * @param _l1Token Adresa ERC20 na L1, který vkládáme.
+ * @param _l2Token Adresa příslušného ERC20 na L2.
+ * @param _from Účet, ze kterého se má vklad na L1 stáhnout.
+ * @param _to Účet, na který se má vklad na L2 připsat.
+ * @param _amount Částka ERC20 k vložení.
+ * @param _l2Gas Limit transakčních poplatků potřebný k dokončení vkladu na L2.
+ * @param _data Volitelná data k předání na L2. Tato data jsou poskytována
+ * pouze pro pohodlí externích kontraktů. Kromě vynucení maximální
+ * délky tyto kontrakty neposkytují žádné záruky ohledně jejich obsahu.
+ */
+ function _initiateERC20Deposit(
+ address _l1Token,
+ address _l2Token,
+ address _from,
+ address _to,
+ uint256 _amount,
+ uint32 _l2Gas,
+ bytes calldata _data
+ ) internal {
+```
+
+Tato funkce je podobná výše uvedené funkci `_initiateETHDeposit`, s několika důležitými rozdíly.
+Prvním rozdílem je, že tato funkce přijímá adresy tokenů a částku k převodu jako parametry.
+V případě ETH volání přemostění již zahrnuje převod aktiv na účet přemostění (`msg.value`).
+
+```solidity
+ // Když je vklad iniciován na L1, přemostění L1 převede prostředky na sebe pro budoucí
+ // výběry. safeTransferFrom také kontroluje, zda má kontrakt kód, takže toto selže, pokud
+ // _from je EOA nebo address(0).
+ // slither-disable-next-line reentrancy-events, reentrancy-benign
+ IERC20(_l1Token).safeTransferFrom(_from, address(this), _amount);
+```
+
+Převody tokenů ERC-20 se řídí jiným procesem než ETH:
+
+1. Uživatel (`_from`) udělí přemostění povolení k převodu příslušných tokenů.
+2. Uživatel zavolá přemostění s adresou kontraktu tokenu, částkou atd.
+3. Přemostění převede tokeny (na sebe) jako součást procesu vkladu.
+
+První krok se může uskutečnit v samostatné transakci od posledních dvou.
+Front-running však není problém, protože obě funkce, které volají `_initiateERC20Deposit` (`depositERC20` a `depositERC20To`), volají tuto funkci pouze s `msg.sender` jako parametrem `_from`.
+
+```solidity
+ // Sestavení calldata pro _l2Token.finalizeDeposit(_to, _amount)
+ bytes memory message = abi.encodeWithSelector(
+ IL2ERC20Bridge.finalizeDeposit.selector,
+ _l1Token,
+ _l2Token,
+ _from,
+ _to,
+ _amount,
+ _data
+ );
+
+ // Odeslání calldata na L2
+ // slither-disable-next-line reentrancy-events, reentrancy-benign
+ sendCrossDomainMessage(l2TokenBridge, _l2Gas, message);
+
+ // slither-disable-next-line reentrancy-benign
+ deposits[_l1Token][_l2Token] = deposits[_l1Token][_l2Token] + _amount;
+```
+
+Přidat vloženou částku tokenů do datové struktury `deposits`.
+Může existovat více adres na L2, které odpovídají stejnému tokenu ERC-20 na L1, takže pro sledování vkladů nestačí použít zůstatek přemostění tokenu ERC-20 na L1.
+
+```solidity
+
+ // slither-disable-next-line reentrancy-events
+ emit ERC20DepositInitiated(_l1Token, _l2Token, _from, _to, _amount, _data);
+ }
+
+ /*************************
+ * Meziřetězcové funkce *
+ *************************/
+
+ /**
+ * @inheritdoc IL1StandardBridge
+ */
+ function finalizeETHWithdrawal(
+ address _from,
+ address _to,
+ uint256 _amount,
+ bytes calldata _data
+```
+
+Přemostění L2 odešle zprávu mezidoménovému posílači zpráv L2, což způsobí, že mezidoménový posílač zpráv L1 zavolá tuto funkci (samozřejmě až po odeslání [transakce, která zprávu finalizuje](https://community.optimism.io/docs/developers/bridge/messaging/#fees-for-l2-%E2%87%92-l1-transactions) na L1).
+
+```solidity
+ ) external onlyFromCrossDomainAccount(l2TokenBridge) {
+```
+
+Ujistěte se, že se jedná o _legitimní_ zprávu, která pochází od mezidoménového posílače zpráv a pochází z přemostění tokenu L2.
+Tato funkce se používá k výběru ETH z přemostění, takže se musíme ujistit, že ji volá pouze oprávněný volající.
+
+```solidity
+ // slither-disable-next-line reentrancy-events
+ (bool success, ) = _to.call{ value: _amount }(new bytes(0));
+```
+
+Způsobem převodu ETH je zavolat příjemce s částkou wei v `msg.value`.
+
+```solidity
+ require(success, "TransferHelper::safeTransferETH: Převod ETH selhal");
+
+ // slither-disable-next-line reentrancy-events
+ emit ETHWithdrawalFinalized(_from, _to, _amount, _data);
+```
+
+Vyslat událost o výběru.
+
+```solidity
+ }
+
+ /**
+ * @inheritdoc IL1ERC20Bridge
+ */
+ function finalizeERC20Withdrawal(
+ address _l1Token,
+ address _l2Token,
+ address _from,
+ address _to,
+ uint256 _amount,
+ bytes calldata _data
+ ) external onlyFromCrossDomainAccount(l2TokenBridge) {
+```
+
+Tato funkce je podobná výše uvedené funkci `finalizeETHWithdrawal` s nezbytnými změnami pro tokeny ERC-20.
+
+```solidity
+ deposits[_l1Token][_l2Token] = deposits[_l1Token][_l2Token] - _amount;
+```
+
+Aktualizovat datovou strukturu `deposits`.
+
+```solidity
+
+ // Když je výběr finalizován na L1, přemostění L1 převede prostředky vybírajícímu
+ // slither-disable-next-line reentrancy-events
+ IERC20(_l1Token).safeTransfer(_to, _amount);
+
+ // slither-disable-next-line reentrancy-events
+ emit ERC20WithdrawalFinalized(_l1Token, _l2Token, _from, _to, _amount, _data);
+ }
+
+
+ /*****************************
+ * Dočasné - migrace ETH *
+ *****************************/
+
+ /**
+ * @dev Přidá zůstatek ETH na účet. Toto je určeno k tomu, aby se ETH
+ * mohlo migrovat ze staré brány na novou bránu.
+ * POZNÁMKA: Toto je ponecháno pouze pro jeden upgrade, abychom mohli přijmout migrované ETH ze
+ * starého kontraktu
+ */
+ function donateETH() external payable {}
+}
+```
+
+Existovala starší implementace přemostění.
+Když jsme přešli z této implementace na tuto, museli jsme přesunout všechna aktiva.
+Tokeny ERC-20 se dají jednoduše přesunout.
+Abyste však mohli převést ETH do kontraktu, potřebujete souhlas tohoto kontraktu, což nám poskytuje `donateETH`.
+
+## Tokeny ERC-20 na L2 {#erc-20-tokens-on-l2}
+
+Aby token ERC-20 vyhovoval standardnímu přemostění, musí umožnit standardnímu přemostění, a _pouze_ standardnímu přemostění, razit tokeny.
+To je nutné, protože přemostění musí zajistit, aby se počet tokenů v oběhu v síti Optimism rovnal počtu tokenů uzamčených v kontraktu přemostění na L1.
+Pokud by na L2 bylo příliš mnoho tokenů, někteří uživatelé by nemohli svá aktiva přemostit zpět na L1.
+Místo důvěryhodného přemostění bychom v podstatě znovu vytvořili [bankovnictví s částečnými rezervami](https://www.investopedia.com/terms/f/fractionalreservebanking.asp).
+Pokud je na L1 příliš mnoho tokenů, některé z nich by zůstaly navždy uzamčeny v kontraktu přemostění, protože neexistuje způsob, jak je uvolnit bez spálení tokenů na L2.
+
+### IL2StandardERC20 {#il2standarderc20}
+
+Každý token ERC-20 na L2, který používá standardní přemostění, musí poskytovat [toto rozhraní](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/IL2StandardERC20.sol), které má funkce a události, jež standardní přemostění potřebuje.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.9;
+
+import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
+```
+
+[Standardní rozhraní ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) nezahrnuje funkce `mint` a `burn`.
+Tyto metody nejsou vyžadovány [standardem ERC-20](https://eips.ethereum.org/EIPS/eip-20), který ponechává mechanismy pro vytváření a ničení tokenů nespecifikované.
+
+```solidity
+import { IERC165 } from "@openzeppelin/contracts/utils/introspection/IERC165.sol";
+```
+
+[Rozhraní ERC-165](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/introspection/IERC165.sol) se používá ke specifikaci funkcí, které kontrakt poskytuje.
+[Standard si můžete přečíst zde](https://eips.ethereum.org/EIPS/eip-165).
+
+```solidity
+interface IL2StandardERC20 is IERC20, IERC165 {
+ function l1Token() external returns (address);
+```
+
+Tato funkce poskytuje adresu tokenu L1, který je přemostěn do tohoto kontraktu.
+Všimněte si, že podobnou funkci v opačném směru nemáme.
+Musíme být schopni přemostit jakýkoli token na L1 bez ohledu na to, zda podpora na L2 byla plánována při jeho implementaci či nikoli.
+
+```solidity
+
+ function mint(address _to, uint256 _amount) external;
+
+ function burn(address _from, uint256 _amount) external;
+
+ event Mint(address indexed _account, uint256 _amount);
+ event Burn(address indexed _account, uint256 _amount);
+}
+```
+
+Funkce a události pro ražbu (vytvoření) a pálení (zničení) tokenů.
+Přemostění by mělo být jedinou entitou, která může tyto funkce spouštět, aby se zajistil správný počet tokenů (rovný počtu tokenů uzamčených na L1).
+
+### L2StandardERC20 {#L2StandardERC20}
+
+[Toto je naše implementace rozhraní `IL2StandardERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/L2StandardERC20.sol).
+Pokud nepotřebujete žádnou vlastní logiku, měli byste použít tuto.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.9;
+
+import { ERC20 } from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
+```
+
+[Kontrakt ERC-20 od OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol).
+Optimism nevěří v znovuobjevování kola, zejména když je kolo dobře auditováno a musí být dostatečně důvěryhodné pro držení aktiv.
+
+```solidity
+import "./IL2StandardERC20.sol";
+
+contract L2StandardERC20 is IL2StandardERC20, ERC20 {
+ address public l1Token;
+ address public l2Bridge;
+```
+
+Toto jsou dva další konfigurační parametry, které vyžadujeme a které ERC-20 normálně nemá.
+
+```solidity
+
+ /**
+ * @param _l2Bridge Adresa standardního přemostění na L2.
+ * @param _l1Token Adresa odpovídajícího tokenu na L1.
+ * @param _name Název ERC20.
+ * @param _symbol Symbol ERC20.
+ */
+ constructor(
+ address _l2Bridge,
+ address _l1Token,
+ string memory _name,
+ string memory _symbol
+ ) ERC20(_name, _symbol) {
+ l1Token = _l1Token;
+ l2Bridge = _l2Bridge;
+ }
+```
+
+Nejprve zavoláme konstruktor kontraktu, ze kterého dědíme (`ERC20(_name, _symbol)`), a poté nastavíme vlastní proměnné.
+
+```solidity
+
+ modifier onlyL2Bridge() {
+ require(msg.sender == l2Bridge, "Razit a pálit může pouze přemostění L2");
+ _;
+ }
+
+
+ // slither-disable-next-line external-function
+ function supportsInterface(bytes4 _interfaceId) public pure returns (bool) {
+ bytes4 firstSupportedInterface = bytes4(keccak256("supportsInterface(bytes4)")); // ERC165
+ bytes4 secondSupportedInterface = IL2StandardERC20.l1Token.selector ^
+ IL2StandardERC20.mint.selector ^
+ IL2StandardERC20.burn.selector;
+ return _interfaceId == firstSupportedInterface || _interfaceId == secondSupportedInterface;
+ }
+```
+
+Takto funguje [ERC-165](https://eips.ethereum.org/EIPS/eip-165).
+Každé rozhraní je souborem podporovaných funkcí a je identifikováno jako [exkluzivní nebo](https://en.wikipedia.org/wiki/Exclusive_or) [selektorů funkcí ABI](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html#function-selector) těchto funkcí.
+
+Přemostění na L2 používá ERC-165 jako kontrolu správnosti, aby se ujistilo, že kontrakt ERC-20, do kterého posílá aktiva, je `IL2StandardERC20`.
+
+**Poznámka:** Nic nebrání tomu, aby podvodný kontrakt poskytoval falešné odpovědi na `supportsInterface`, takže se jedná o mechanismus kontroly správnosti, _nikoli_ o bezpečnostní mechanismus.
+
+```solidity
+ // slither-disable-next-line external-function
+ function mint(address _to, uint256 _amount) public virtual onlyL2Bridge {
+ _mint(_to, _amount);
+
+ emit Mint(_to, _amount);
+ }
+
+ // slither-disable-next-line external-function
+ function burn(address _from, uint256 _amount) public virtual onlyL2Bridge {
+ _burn(_from, _amount);
+
+ emit Burn(_from, _amount);
+ }
+}
+```
+
+Pouze přemostění L2 smí razit a pálit aktiva.
+
+`_mint` a `_burn` jsou ve skutečnosti definovány v [kontraktu ERC-20 OpenZeppelin](/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn).
+Tento kontrakt je pouze nevystavuje externě, protože podmínky pro ražbu a pálení tokenů jsou tak rozmanité jako počet způsobů použití ERC-20.
+
+## Kód přemostění L2 {#l2-bridge-code}
+
+Toto je kód, který spouští přemostění v síti Optimism.
+[Zdrojový kód tohoto kontraktu je zde](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol).
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.9;
+
+/* Importy rozhraní */
+import { IL1StandardBridge } from "../../L1/messaging/IL1StandardBridge.sol";
+import { IL1ERC20Bridge } from "../../L1/messaging/IL1ERC20Bridge.sol";
+import { IL2ERC20Bridge } from "./IL2ERC20Bridge.sol";
+```
+
+Rozhraní [IL2ERC20Bridge](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol) je velmi podobné [ekvivalentu L1](#IL1ERC20Bridge), který jsme viděli výše.
+Existují dva významné rozdíly:
+
+1. Na L1 iniciujete vklady a finalizujete výběry.
+ Zde iniciujete výběry a finalizujete vklady.
+2. Na L1 je nutné rozlišovat mezi ETH a tokeny ERC-20.
+ Na L2 můžeme použít stejné funkce pro obojí, protože interně jsou zůstatky ETH v síti Optimism spravovány jako token ERC-20 s adresou [0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000](https://explorer.optimism.io/address/0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000).
+
+```solidity
+/* Importy knihoven */
+import { ERC165Checker } from "@openzeppelin/contracts/utils/introspection/ERC165Checker.sol";
+import { CrossDomainEnabled } from "../../libraries/bridge/CrossDomainEnabled.sol";
+import { Lib_PredeployAddresses } from "../../libraries/constants/Lib_PredeployAddresses.sol";
+
+/* Importy kontraktů */
+import { IL2StandardERC20 } from "../../standards/IL2StandardERC20.sol";
+
+/**
+ * @title L2StandardBridge
+ * @dev Standardní přemostění L2 je kontrakt, který spolupracuje se standardním přemostěním L1,
+ * aby umožnil přechody ETH a ERC20 mezi L1 a L2.
+ * Tento kontrakt funguje jako razič nových tokenů, když se dozví o vkladech do standardního
+ * přemostění L1.
+ * Tento kontrakt také funguje jako palič tokenů určených k výběru a informuje přemostění L1
+ * o uvolnění prostředků L1.
+ */
+contract L2StandardBridge is IL2ERC20Bridge, CrossDomainEnabled {
+ /********************************
+ * Reference na externí kontrakty *
+ ********************************/
+
+ address public l1TokenBridge;
+```
+
+Sledovat adresu přemostění L1.
+Všimněte si, že na rozdíl od ekvivalentu na L1 zde tuto proměnnou _potřebujeme_.
+Adresa přemostění L1 není známa předem.
+
+```solidity
+
+ /***************
+ * Konstruktor *
+ ***************/
+
+ /**
+ * @param _l2CrossDomainMessenger Mezidoménový posílač zpráv používaný tímto kontraktem.
+ * @param _l1TokenBridge Adresa přemostění L1 nasazeného na hlavní řetězec.
+ */
+ constructor(address _l2CrossDomainMessenger, address _l1TokenBridge)
+ CrossDomainEnabled(_l2CrossDomainMessenger)
+ {
+ l1TokenBridge = _l1TokenBridge;
+ }
+
+ /***************
+ * Vybírání *
+ ***************/
+
+ /**
+ * @inheritdoc IL2ERC20Bridge
+ */
+ function withdraw(
+ address _l2Token,
+ uint256 _amount,
+ uint32 _l1Gas,
+ bytes calldata _data
+ ) external virtual {
+ _initiateWithdrawal(_l2Token, msg.sender, msg.sender, _amount, _l1Gas, _data);
+ }
+
+ /**
+ * @inheritdoc IL2ERC20Bridge
+ */
+ function withdrawTo(
+ address _l2Token,
+ address _to,
+ uint256 _amount,
+ uint32 _l1Gas,
+ bytes calldata _data
+ ) external virtual {
+ _initiateWithdrawal(_l2Token, msg.sender, _to, _amount, _l1Gas, _data);
+ }
+```
+
+Tyto dvě funkce iniciují výběry.
+Všimněte si, že není třeba specifikovat adresu tokenu L1.
+Očekává se, že tokeny na L2 nám sdělí adresu svého ekvivalentu na L1.
+
+```solidity
+
+ /**
+ * @dev Provádí logiku pro výběry pálením tokenu a informováním
+ * brány tokenu L1 o výběru.
+ * @param _l2Token Adresa tokenu na L2, kde je výběr iniciován.
+ * @param _from Účet, ze kterého se má výběr na L2 stáhnout.
+ * @param _to Účet, na který se má výběr na L1 připsat.
+ * @param _amount Částka tokenu k výběru.
+ * @param _l1Gas Nepoužito, ale zahrnuto pro případné úvahy o budoucí kompatibilitě.
+ * @param _data Volitelná data k předání na L1. Tato data jsou poskytována
+ * pouze pro pohodlí externích kontraktů. Kromě vynucení maximální
+ * délky tyto kontrakty neposkytují žádné záruky ohledně jejich obsahu.
+ */
+ function _initiateWithdrawal(
+ address _l2Token,
+ address _from,
+ address _to,
+ uint256 _amount,
+ uint32 _l1Gas,
+ bytes calldata _data
+ ) internal {
+ // Když je výběr iniciován, spálíme prostředky vybírajícího, abychom zabránili následnému použití na L2
+ // slither-disable-next-line reentrancy-events
+ IL2StandardERC20(_l2Token).burn(msg.sender, _amount);
+```
+
+Všimněte si, že se _nespoléháme_ na parametr `_from`, ale na `msg.sender`, který je mnohem těžší zfalšovat (pokud vím, nemožné).
+
+```solidity
+
+ // Sestavení calldata pro l1TokenBridge.finalizeERC20Withdrawal(_to, _amount)
+ // slither-disable-next-line reentrancy-events
+ address l1Token = IL2StandardERC20(_l2Token).l1Token();
+ bytes memory message;
+
+ if (_l2Token == Lib_PredeployAddresses.OVM_ETH) {
+```
+
+Na L1 je nutné rozlišovat mezi ETH a ERC-20.
+
+```solidity
+ message = abi.encodeWithSelector(
+ IL1StandardBridge.finalizeETHWithdrawal.selector,
+ _from,
+ _to,
+ _amount,
+ _data
+ );
+ } else {
+ message = abi.encodeWithSelector(
+ IL1ERC20Bridge.finalizeERC20Withdrawal.selector,
+ l1Token,
+ _l2Token,
+ _from,
+ _to,
+ _amount,
+ _data
+ );
+ }
+
+ // Odeslání zprávy do přemostění na L1
+ // slither-disable-next-line reentrancy-events
+ sendCrossDomainMessage(l1TokenBridge, _l1Gas, message);
+
+ // slither-disable-next-line reentrancy-events
+ emit WithdrawalInitiated(l1Token, _l2Token, msg.sender, _to, _amount, _data);
+ }
+
+ /************************************
+ * Meziřetězcová funkce: Vkládání *
+ ************************************/
+
+ /**
+ * @inheritdoc IL2ERC20Bridge
+ */
+ function finalizeDeposit(
+ address _l1Token,
+ address _l2Token,
+ address _from,
+ address _to,
+ uint256 _amount,
+ bytes calldata _data
+```
+
+Tuto funkci volá `L1StandardBridge`.
+
+```solidity
+ ) external virtual onlyFromCrossDomainAccount(l1TokenBridge) {
+```
+
+Ujistěte se, že zdroj zprávy je legitimní.
+To je důležité, protože tato funkce volá `_mint` a mohla by být použita k poskytnutí tokenů, které nejsou kryty tokeny, jež přemostění vlastní na L1.
+
+```solidity
+ // Zkontrolujte, zda je cílový token vyhovující a
+ // ověřte, že vložený token na L1 odpovídá reprezentaci vloženého tokenu na L2 zde
+ if (
+ // slither-disable-next-line reentrancy-events
+ ERC165Checker.supportsInterface(_l2Token, 0x1d1d8b63) &&
+ _l1Token == IL2StandardERC20(_l2Token).l1Token()
+```
+
+Kontroly správnosti:
+
+1. Je podporováno správné rozhraní
+2. Adresa L1 kontraktu ERC-20 na L2 odpovídá zdroji L1 tokenů.
+
+```solidity
+ ) {
+ // Když je vklad finalizován, připíšeme na účet na L2 stejnou částku
+ // tokenů.
+ // slither-disable-next-line reentrancy-events
+ IL2StandardERC20(_l2Token).mint(_to, _amount);
+ // slither-disable-next-line reentrancy-events
+ emit DepositFinalized(_l1Token, _l2Token, _from, _to, _amount, _data);
+```
+
+Pokud kontroly správnosti projdou, dokončete vklad:
+
+1. Razit tokeny
+2. Vyslat příslušnou událost
+
+```solidity
+ } else {
+ // Buď token L2, do kterého se vkládá, nesouhlasí se správnou adresou
+ // svého tokenu L1, nebo nepodporuje správné rozhraní.
+ // Toto by se mělo stát pouze v případě zákeřného tokenu L2, nebo pokud uživatel nějakým způsobem
+ // zadal špatnou adresu tokenu L2 pro vklad.
+ // V obou případech zde proces zastavíme a sestavíme zprávu o výběru,
+ // aby si uživatelé mohli v některých případech své prostředky vybrat.
+ // Neexistuje žádný způsob, jak zcela zabránit zákeřným kontraktům tokenů, ale toto omezuje
+ // chyby uživatelů a zmírňuje některé formy zákeřného chování kontraktů.
+```
+
+Pokud uživatel udělal zjistitelnou chybu použitím špatné adresy tokenu na L2, chceme vklad zrušit a vrátit tokeny na L1.
+Jediný způsob, jak to můžeme udělat z L2, je poslat zprávu, která bude muset počkat na období pro napadení chyby, ale to je pro uživatele mnohem lepší než trvalá ztráta tokenů.
+
+```solidity
+ bytes memory message = abi.encodeWithSelector(
+ IL1ERC20Bridge.finalizeERC20Withdrawal.selector,
+ _l1Token,
+ _l2Token,
+ _to, // zde jsme prohodili _to a _from, abychom vklad vrátili odesílateli
+ _from,
+ _amount,
+ _data
+ );
+
+ // Odeslání zprávy do přemostění na L1
+ // slither-disable-next-line reentrancy-events
+ sendCrossDomainMessage(l1TokenBridge, 0, message);
+ // slither-disable-next-line reentrancy-events
+ emit DepositFailed(_l1Token, _l2Token, _from, _to, _amount, _data);
+ }
+ }
+}
+```
+
+## Závěr {#conclusion}
+
+Standardní přemostění je nejflexibilnějším mechanismem pro převody aktiv.
+Protože je však tak obecný, není vždy nejjednodušším mechanismem k použití.
+Zejména pro výběry většina uživatelů dává přednost použití [přemostění třetích stran](https://optimism.io/apps#bridge), která nečekají na období pro napadení a nevyžadují Merkleho důkaz k dokončení výběru.
+
+Tato přemostění obvykle fungují tak, že mají aktiva na L1, která okamžitě poskytnou za malý poplatek (často nižší než náklady na transakční poplatky za výběr standardním přemostěním).
+Když přemostění (nebo lidé, kteří ho provozují) předpokládá, že bude mít málo aktiv na L1, převede dostatečná aktiva z L2. Protože se jedná o velmi velké výběry, náklady na výběr se amortizují na velkou částku a představují mnohem menší procento.
+
+Doufejme, že vám tento článek pomohl lépe pochopit, jak funguje druhá vrstva a jak psát kód v Solidity, který je jasný a bezpečný.
+
+[Více z mé práce najdete zde](https://cryptodocguy.pro/).
diff --git a/public/content/translations/cs/developers/tutorials/reverse-engineering-a-contract/index.md b/public/content/translations/cs/developers/tutorials/reverse-engineering-a-contract/index.md
new file mode 100644
index 00000000000..117c493bda1
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/reverse-engineering-a-contract/index.md
@@ -0,0 +1,744 @@
+---
+title: "Reverzní inženýrství kontraktu"
+description: Jak porozumět kontraktu, když nemáte zdrojový kód
+author: Ori Pomerantz
+lang: cs
+tags: [ "evm", "opkódy" ]
+skill: advanced
+published: 2021-12-30
+---
+
+## Úvod {#introduction}
+
+_Na blockchainu neexistují žádná tajemství_, vše, co se stane, je konzistentní, ověřitelné a veřejně dostupné. V ideálním případě by [kontrakty měly mít svůj zdrojový kód zveřejněný a ověřený na Etherscanu](https://etherscan.io/address/0xb8901acb165ed027e32754e0ffe830802919727f#code). Nicméně [to tak není vždy](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#code). V tomto článku se dozvíte, jak reverzně analyzovat kontrakty na příkladu kontraktu bez zdrojového kódu, [`0x2510c039cc3b061d79e564b38836da87e31b342f`](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f).
+
+Existují reverzní kompilátory, ale ne vždy produkují [použitelné výsledky](https://etherscan.io/bytecode-decompiler?a=0x2510c039cc3b061d79e564b38836da87e31b342f). V tomto článku se dozvíte, jak manuálně provést reverzní inženýrství a porozumět kontraktu z [opkódů](https://github.com/wolflo/evm-opcodes) a také jak interpretovat výsledky dekompilátoru.
+
+Abyste mohli porozumět tomuto článku, měli byste již znát základy EVM a být alespoň trochu obeznámeni s EVM assemblerem. [O těchto tématech si můžete přečíst zde](https://medium.com/mycrypto/the-ethereum-virtual-machine-how-does-it-work-9abac2b7c9e).
+
+## Příprava spustitelného kódu {#prepare-the-executable-code}
+
+Opkódy získáte tak, že na Etherscanu přejdete na kontrakt, kliknete na záložku **Contract** a poté na **Switch to Opcodes View**. Zobrazí se vám pohled s jedním opkódem na řádek.
+
+
+
+Abyste však porozuměli skokům, musíte vědět, kde v kódu se který opkód nachází. Jedním ze způsobů, jak to udělat, je otevřít tabulku Google a vložit opkódy do sloupce C. [Následující kroky můžete přeskočit tak, že si vytvoříte kopii této již připravené tabulky](https://docs.google.com/spreadsheets/d/1tKmTJiNjUwHbW64wCKOSJxHjmh0bAUapt6btUYE7kDA/edit?usp=sharing).
+
+Dalším krokem je získání správných umístění v kódu, abychom mohli pochopit skoky. Velikost opkódu vložíme do sloupce B a umístění (v hexadecimálním tvaru) do sloupce A. Zadejte tuto funkci do buňky `B1` a poté ji zkopírujte a vložte do zbytku sloupce B, až na konec kódu. Poté můžete sloupec B skrýt.
+
+```
+=1+IF(REGEXMATCH(C1,"PUSH"),REGEXEXTRACT(C1,"PUSH(\d+)"),0)
+```
+
+Tato funkce nejprve přidá jeden bajt pro samotný opkód a poté hledá `PUSH`. Opkódy PUSH jsou speciální, protože potřebují další bajty pro vkládanou hodnotu. Pokud je opkód `PUSH`, extrahujeme počet bajtů a přičteme ho.
+
+Do buňky `A1` vložte první offset, nulu. Poté do buňky `A2` vložte tuto funkci a opět ji zkopírujte a vložte do zbytku sloupce A:
+
+```
+=dec2hex(hex2dec(A1)+B1)
+```
+
+Tuto funkci potřebujeme, aby nám poskytla hexadecimální hodnotu, protože hodnoty, které jsou vkládány před skoky (`JUMP` a `JUMPI`), jsou nám dány v hexadecimálním tvaru.
+
+## Vstupní bod (0x00) {#the-entry-point-0x00}
+
+Kontrakty se vždy spouštějí od prvního bajtu. Toto je počáteční část kódu:
+
+| Offset | Opkód | Zásobník (po opkódu) |
+| -----: | ------------ | ---------------------------------------------- |
+| 0 | PUSH1 0x80 | 0x80 |
+| 2 | PUSH1 0x40 | 0x40, 0x80 |
+| 4 | MSTORE | Prázdné |
+| 5 | PUSH1 0x04 | 0x04 |
+| 7 | CALLDATASIZE | CALLDATASIZE 0x04 |
+| 8 | LT | CALLDATASIZE\<4 |
+| 9 | PUSH2 0x005e | 0x5E CALLDATASIZE\<4 |
+| C | JUMPI | Prázdné |
+
+Tento kód dělá dvě věci:
+
+1. Zapište 0x80 jako 32bajtovou hodnotu do paměťových míst 0x40-0x5F (0x80 se uloží do 0x5F a 0x40-0x5E jsou všechny nuly).
+2. Přečtěte velikost calldata. Normálně se data volání (calldata) pro kontrakt na Ethereu řídí [ABI (application binary interface)](https://docs.soliditylang.org/en/v0.8.10/abi-spec.html), které vyžaduje minimálně čtyři bajty pro selektor funkce. Pokud je velikost calldata menší než čtyři, skočí se na 0x5E.
+
+
+
+### Handler na 0x5E (pro data volání bez ABI) {#the-handler-at-0x5e-for-non-abi-call-data}
+
+| Offset | Opkód |
+| -----: | ------------ |
+| 5E | JUMPDEST |
+| 5F | CALLDATASIZE |
+| 60 | PUSH2 0x007c |
+| 63 | JUMPI |
+
+Tento úryvek začíná `JUMPDEST`. Programy EVM (Ethereum Virtual Machine) vyvolají výjimku, pokud skočíte na opkód, který není `JUMPDEST`. Poté se podívá na CALLDATASIZE, a pokud je „true“ (tedy nenulová), skočí na 0x7C. K tomu se dostaneme níže.
+
+| Offset | Opkód | Zásobník (po opkódu) |
+| -----: | ---------- | ------------------------------------------------------------------------------------------ |
+| 64 | CALLVALUE | [Wei](/glossary/#wei) poskytnuté voláním. V Solidity se nazývá `msg.value` |
+| 65 | PUSH1 0x06 | 6 CALLVALUE |
+| 67 | PUSH1 0x00 | 0 6 CALLVALUE |
+| 69 | DUP3 | CALLVALUE 0 6 CALLVALUE |
+| 6A | DUP3 | 6 CALLVALUE 0 6 CALLVALUE |
+| 6B | SLOAD | Storage[6] CALLVALUE 0 6 CALLVALUE |
+
+Takže když nejsou žádná calldata, přečteme hodnotu Storage[6]. Zatím nevíme, co tato hodnota znamená, ale můžeme se podívat na transakce, které kontrakt přijal bez calldata. Transakce, které pouze převádějí ETH bez jakýchkoli calldata (a tedy bez metody), mají v Etherscanu metodu `Transfer`. Ve skutečnosti [úplně první transakce, kterou kontrakt obdržel](https://etherscan.io/tx/0xeec75287a583c36bcc7ca87685ab41603494516a0f5986d18de96c8e630762e7), je převod.
+
+Když se podíváme na tuto transakci a klikneme na **Click to see More**, uvidíme, že data volání (calldata), zde nazvaná vstupní data, jsou skutečně prázdná (`0x`). Všimněte si také, že hodnota je 1,559 ETH, což bude relevantní později.
+
+
+
+Dále klikněte na záložku **State** a rozbalte kontrakt, který reverzně analyzujeme (0x2510...). Můžete vidět, že se `Storage[6]` během transakce změnilo, a pokud změníte Hex na **Number**, uvidíte, že se stalo 1 559 000 000 000 000 000, což je převedená hodnota ve wei (pro přehlednost jsem přidal čárky), odpovídající další hodnotě kontraktu.
+
+![Změna v Storage[6]](storage6.png)
+
+Pokud se podíváme na změny stavu způsobené [jinými `Transfer` transakcemi ze stejného období](https://etherscan.io/tx/0xf708d306de39c422472f43cb975d97b66fd5d6a6863db627067167cbf93d84d1#statechange), vidíme, že `Storage[6]` po nějakou dobu sledovalo hodnotu kontraktu. Prozatím to budeme nazývat `Hodnota*`. Hvězdička (`*`) nám připomíná, že ještě _nevíme_, co tato proměnná dělá, ale nemůže sloužit pouze ke sledování hodnoty kontraktu, protože není třeba používat úložiště, které je velmi drahé, když můžete zůstatek svého účtu získat pomocí `ADDRESS BALANCE`. První opkód vloží na zásobník vlastní adresu kontraktu. Druhý opkód přečte adresu na vrcholu zásobníku a nahradí ji zůstatkem této adresy.
+
+| Offset | Opkód | Zásobník |
+| -----: | ------------ | --------------------------------------------- |
+| 6C | PUSH2 0x0075 | 0x75 Hodnota\* CALLVALUE 0 6 CALLVALUE |
+| 6F | SWAP2 | CALLVALUE Hodnota\* 0x75 0 6 CALLVALUE |
+| 70 | SWAP1 | Hodnota\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 71 | PUSH2 0x01a7 | 0x01A7 Hodnota\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 74 | JUMP | |
+
+Budeme pokračovat ve sledování tohoto kódu v cíli skoku.
+
+| Offset | Opkód | Zásobník |
+| -----: | ---------- | ------------------------------------------------------------- |
+| 1A7 | JUMPDEST | Hodnota\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1A8 | PUSH1 0x00 | 0x00 Hodnota\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AA | DUP3 | CALLVALUE 0x00 Hodnota\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AB | NOT | 2^256-CALLVALUE-1 0x00 Hodnota\* CALLVALUE 0x75 0 6 CALLVALUE |
+
+`NOT` je bitová operace, takže obrátí hodnotu každého bitu v hodnotě volání.
+
+| Offset | Opkód | Zásobník |
+| -----: | ------------ | ---------------------------------------------------------------------------------------------------------- |
+| 1AC | DUP3 | Hodnota\* 2^256-CALLVALUE-1 0x00 Hodnota\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AD | GT | Hodnota\*>2^256-CALLVALUE-1 0x00 Hodnota\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AE | ISZERO | Hodnota\*\<=2^256-CALLVALUE-1 0x00 Hodnota\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AF | PUSH2 0x01df | 0x01DF Hodnota\*\<=2^256-CALLVALUE-1 0x00 Hodnota\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1B2 | JUMPI | |
+
+Skočíme, pokud je `Hodnota*` menší než 2^256-CALLVALUE-1 nebo se jí rovná. Vypadá to jako logika k zabránění přetečení. A skutečně, vidíme, že po několika nesmyslných operacích (například zápis do paměti, která bude brzy smazána) na offsetu 0x01DE kontrakt vrátí transakci zpět (revert), pokud je detekováno přetečení, což je normální chování.
+
+Všimněte si, že takové přetečení je extrémně nepravděpodobné, protože by vyžadovalo, aby hodnota volání plus `Hodnota*` byla srovnatelná s 2^256 wei, což je asi 10^59 ETH. [Celková zásoba ETH je v době psaní tohoto článku menší než dvě stě milionů](https://etherscan.io/stat/supply).
+
+| Offset | Opkód | Zásobník |
+| -----: | -------- | ------------------------------------------- |
+| 1DF | JUMPDEST | 0x00 Hodnota\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1E0 | POP | Hodnota\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1E1 | ADD | Hodnota\*+CALLVALUE 0x75 0 6 CALLVALUE |
+| 1E2 | SWAP1 | 0x75 Hodnota\*+CALLVALUE 0 6 CALLVALUE |
+| 1E3 | JUMP | |
+
+Pokud jsme se dostali sem, získáme `Hodnota* + CALLVALUE` a skočíme na offset 0x75.
+
+| Offset | Opkód | Zásobník |
+| -----: | -------- | --------------------------------- |
+| 75 | JUMPDEST | Hodnota\*+CALLVALUE 0 6 CALLVALUE |
+| 76 | SWAP1 | 0 Hodnota\*+CALLVALUE 6 CALLVALUE |
+| 77 | SWAP2 | 6 Hodnota\*+CALLVALUE 0 CALLVALUE |
+| 78 | SSTORE | 0 CALLVALUE |
+
+Pokud se dostaneme sem (což vyžaduje, aby data volání byla prázdná), přičteme k `Hodnota*` hodnotu volání. To je v souladu s tím, co dělají transakce `Transfer`.
+
+| Offset | Opkód |
+| -----: | ----- |
+| 79 | POP |
+| 7A | POP |
+| 7B | STOP |
+
+Nakonec vyčistěte zásobník (což není nutné) a signalizujte úspěšné ukončení transakce.
+
+Abychom to shrnuli, zde je vývojový diagram počátečního kódu.
+
+
+
+## Handler na adrese 0x7C {#the-handler-at-0x7c}
+
+Záměrně jsem do nadpisu neuvedl, co tento handler dělá. Cílem není naučit vás, jak funguje tento konkrétní kontrakt, ale jak provádět reverzní inženýrství kontraktů. Dozvíte se, co dělá, stejně jako já: sledováním kódu.
+
+Dostaneme se sem z několika míst:
+
+- Pokud existují calldata o velikosti 1, 2 nebo 3 bajtů (z offsetu 0x63)
+- Pokud je podpis metody neznámý (z offsetů 0x42 a 0x5D)
+
+| Offset | Opkód | Zásobník |
+| -----: | ------------ | ------------------------------------------------------------------------ |
+| 7C | JUMPDEST | |
+| 7D | PUSH1 0x00 | 0x00 |
+| 7F | PUSH2 0x009d | 0x9D 0x00 |
+| 82 | PUSH1 0x03 | 0x03 0x9D 0x00 |
+| 84 | SLOAD | Storage[3] 0x9D 0x00 |
+
+Toto je další buňka úložiště, kterou jsem v žádné transakci nenašel, takže je těžší zjistit, co znamená. Níže uvedený kód to objasní.
+
+| Offset | Opkód | Zásobník |
+| -----: | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 85 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xff....ff Storage[3] 0x9D 0x00 |
+| 9A | AND | Storage[3]-jako-adresa 0x9D 0x00 |
+
+Tyto opkódy zkrátí hodnotu, kterou čteme z Storage[3], na 160 bitů, což je délka ethereové adresy.
+
+| Offset | Opkód | Zásobník |
+| -----: | ----- | ------------------------------------------------------------------------------------ |
+| 9B | SWAP1 | 0x9D Storage[3]-jako-adresa 0x00 |
+| 9C | JUMP | Storage[3]-jako-adresa 0x00 |
+
+Tento skok je nadbytečný, protože přecházíme na další opkód. Tento kód není zdaleka tak efektivní z hlediska poplatků (gas), jak by mohl být.
+
+| Offset | Opkód | Zásobník |
+| -----: | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
+| 9D | JUMPDEST | Storage[3]-jako-adresa 0x00 |
+| 9E | SWAP1 | 0x00 Storage[3]-jako-adresa |
+| 9F | POP | Storage[3]-jako-adresa |
+| A0 | PUSH1 0x40 | 0x40 Storage[3]-jako-adresa |
+| A2 | MLOAD | Mem[0x40] Storage[3]-jako-adresa |
+
+Na samém začátku kódu jsme nastavili Mem[0x40] na 0x80. Pokud se podíváme na 0x40 později, vidíme, že se nemění – takže můžeme předpokládat, že je to 0x80.
+
+| Offset | Opkód | Zásobník |
+| -----: | ------------ | ------------------------------------------------------------------------------------------------------ |
+| A3 | CALLDATASIZE | CALLDATASIZE 0x80 Storage[3]-jako-adresa |
+| A4 | PUSH1 0x00 | 0x00 CALLDATASIZE 0x80 Storage[3]-jako-adresa |
+| A6 | DUP3 | 0x80 0x00 CALLDATASIZE 0x80 Storage[3]-jako-adresa |
+| A7 | CALLDATACOPY | 0x80 Storage[3]-jako-adresa |
+
+Zkopírujte všechna calldata do paměti, počínaje adresou 0x80.
+
+| Offset | Opkód | Zásobník |
+| -----: | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| A8 | PUSH1 0x00 | 0x00 0x80 Storage[3]-jako-adresa |
+| AA | DUP1 | 0x00 0x00 0x80 Storage[3]-jako-adresa |
+| AB | CALLDATASIZE | CALLDATASIZE 0x00 0x00 0x80 Storage[3]-jako-adresa |
+| AC | DUP4 | 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-jako-adresa |
+| AD | DUP6 | Storage[3]-jako-adresa 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-jako-adresa |
+| AE | GAS | GAS Storage[3]-jako-adresa 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-jako-adresa |
+| AF | DELEGATE_CALL | |
+
+Teď je to mnohem jasnější. Tento kontrakt může fungovat jako [proxy](https://blog.openzeppelin.com/proxy-patterns/) a volat adresu v Storage[3], aby odvedla skutečnou práci. `DELEGATE_CALL` volá samostatný kontrakt, ale zůstává ve stejném úložišti. To znamená, že delegovaný kontrakt, pro který jsme proxy, přistupuje ke stejnému úložnému prostoru. Parametry pro volání jsou:
+
+- _Gas_: Veškerý zbývající gas
+- _Volaná adresa_: Storage[3]-jako-adresa
+- _Data volání_: CALLDATASIZE bajtů začínajících na adrese 0x80, což je místo, kam jsme vložili původní data volání
+- _Návratová data_: Žádná (0x00 - 0x00) Návratová data získáme jiným způsobem (viz níže)
+
+| Offset | Opkód | Zásobník |
+| -----: | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| B0 | RETURNDATASIZE | RETURNDATASIZE (((úspěch/selhání volání))) 0x80 Storage[3]-jako-adresa |
+| B1 | DUP1 | RETURNDATASIZE RETURNDATASIZE (((úspěch/selhání volání))) 0x80 Storage[3]-jako-adresa |
+| B2 | PUSH1 0x00 | 0x00 RETURNDATASIZE RETURNDATASIZE (((úspěch/selhání volání))) 0x80 Storage[3]-jako-adresa |
+| B4 | DUP5 | 0x80 0x00 RETURNDATASIZE RETURNDATASIZE (((úspěch/selhání volání))) 0x80 Storage[3]-jako-adresa |
+| B5 | RETURNDATACOPY | RETURNDATASIZE (((úspěch/selhání volání))) 0x80 Storage[3]-jako-adresa |
+
+Zde zkopírujeme všechna návratová data do paměťové vyrovnávací paměti začínající na adrese 0x80.
+
+| Offset | Opkód | Zásobník |
+| -----: | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| B6 | DUP2 | (((úspěch/selhání volání))) RETURNDATASIZE (((úspěch/selhání volání))) 0x80 Storage[3]-jako-adresa |
+| B7 | DUP1 | (((úspěch/selhání volání))) (((úspěch/selhání volání))) RETURNDATASIZE (((úspěch/selhání volání))) 0x80 Storage[3]-jako-adresa |
+| B8 | ISZERO | (((selhalo volání))) (((úspěch/selhání volání))) RETURNDATASIZE (((úspěch/selhání volání))) 0x80 Storage[3]-jako-adresa |
+| B9 | PUSH2 0x00c0 | 0xC0 (((selhalo volání))) (((úspěch/selhání volání))) RETURNDATASIZE (((úspěch/selhání volání))) 0x80 Storage[3]-jako-adresa |
+| BC | JUMPI | (((úspěch/selhání volání))) RETURNDATASIZE (((úspěch/selhání volání))) 0x80 Storage[3]-jako-adresa |
+| BD | DUP2 | RETURNDATASIZE (((úspěch/selhání volání))) RETURNDATASIZE (((úspěch/selhání volání))) 0x80 Storage[3]-jako-adresa |
+| BE | DUP5 | 0x80 RETURNDATASIZE (((úspěch/selhání volání))) RETURNDATASIZE (((úspěch/selhání volání))) 0x80 Storage[3]-jako-adresa |
+| BF | RETURN | |
+
+Takže po volání zkopírujeme návratová data do vyrovnávací paměti 0x80 - 0x80+RETURNDATASIZE a pokud je volání úspěšné, pak `RETURN` s přesně touto vyrovnávací pamětí.
+
+### DELEGATECALL selhal {#delegatecall-failed}
+
+Pokud se dostaneme sem, na 0xC0, znamená to, že volaný kontrakt vrátil transakci zpět (revert). Jelikož jsme pouze proxy pro tento kontrakt, chceme vrátit stejná data a také provést revert.
+
+| Offset | Opkód | Zásobník |
+| -----: | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| C0 | JUMPDEST | (((úspěch/selhání volání))) RETURNDATASIZE (((úspěch/selhání volání))) 0x80 Storage[3]-jako-adresa |
+| C1 | DUP2 | RETURNDATASIZE (((úspěch/selhání volání))) RETURNDATASIZE (((úspěch/selhání volání))) 0x80 Storage[3]-jako-adresa |
+| C2 | DUP5 | 0x80 RETURNDATASIZE (((úspěch/selhání volání))) RETURNDATASIZE (((úspěch/selhání volání))) 0x80 Storage[3]-jako-adresa |
+| C3 | REVERT | |
+
+Takže provedeme `REVERT` se stejnou vyrovnávací pamětí, kterou jsme použili pro `RETURN` dříve: 0x80 - 0x80+RETURNDATASIZE
+
+
+
+## Volání ABI {#abi-calls}
+
+Pokud je velikost calldata čtyři bajty nebo více, může se jednat o platné volání ABI.
+
+| Offset | Opkód | Zásobník |
+| -----: | ------------ | ------------------------------------------------------------------------------------------------------------------------ |
+| D | PUSH1 0x00 | 0x00 |
+| F | CALLDATALOAD | (((První slovo (256 bitů) z calldata))) |
+| 10 | PUSH1 0xe0 | 0xE0 (((První slovo (256 bitů) z calldata))) |
+| 12 | SHR | (((prvních 32 bitů (4 bajty) z calldata))) |
+
+Etherscan nám říká, že `1C` je neznámý opkód, protože [byl přidán poté, co Etherscan napsal tuto funkci](https://eips.ethereum.org/EIPS/eip-145) a ještě ji neaktualizovali. [Aktuální tabulka opkódů](https://github.com/wolflo/evm-opcodes) nám ukazuje, že se jedná o posun doprava
+
+| Offset | Opkód | Zásobník |
+| -----: | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 13 | DUP1 | (((prvních 32 bitů (4 bajty) z calldata))) (((prvních 32 bitů (4 bajty) z calldata))) |
+| 14 | PUSH4 0x3cd8045e | 0x3CD8045E (((prvních 32 bitů (4 bajty) z calldata))) (((prvních 32 bitů (4 bajty) z calldata))) |
+| 19 | GT | 0x3CD8045E>prvních-32-bitů-calldata (((prvních 32 bitů (4 bajty) z calldata))) |
+| 1A | PUSH2 0x0043 | 0x43 0x3CD8045E>prvních-32-bitů-calldata (((prvních 32 bitů (4 bajty) z calldata))) |
+| 1D | JUMPI | (((prvních 32 bitů (4 bajty) z calldata))) |
+
+Rozdělením testů shody podpisu metody na dvě části se v průměru ušetří polovina testů. Kód, který bezprostředně následuje, a kód na 0x43 se řídí stejným vzorem: `DUP1` prvních 32 bitů calldata, `PUSH4 (((podpis metody>`, spustit `EQ` pro kontrolu rovnosti a poté `JUMPI`, pokud se podpis metody shoduje. Zde jsou podpisy metod, jejich adresy a pokud je známa [odpovídající definice metody](https://www.4byte.directory/):
+
+| Metoda | Podpis metody | Offset pro skok |
+| --------------------------------------------------------------------------------------------------------- | ------------- | --------------- |
+| [splitter()](https://www.4byte.directory/signatures/?bytes4_signature=0x3cd8045e) | 0x3cd8045e | 0x0103 |
+| ??? | 0x81e580d3 | 0x0138 |
+| [currentWindow()](https://www.4byte.directory/signatures/?bytes4_signature=0xba0bafb4) | 0xba0bafb4 | 0x0158 |
+| ??? | 0x1f135823 | 0x00C4 |
+| [merkleRoot()](https://www.4byte.directory/signatures/?bytes4_signature=0x2eb4a7ab) | 0x2eb4a7ab | 0x00ED |
+
+Pokud se nenajde žádná shoda, kód skočí na [proxy handler na adrese 0x7C](#the-handler-at-0x7c) v naději, že kontrakt, pro který jsme proxy, shodu mít bude.
+
+
+
+## splitter() {#splitter}
+
+| Offset | Opkód | Zásobník |
+| -----: | ------------ | ----------------------------- |
+| 103 | JUMPDEST | |
+| 104 | CALLVALUE | CALLVALUE |
+| 105 | DUP1 | CALLVALUE CALLVALUE |
+| 106 | ISZERO | CALLVALUE==0 CALLVALUE |
+| 107 | PUSH2 0x010f | 0x010F CALLVALUE==0 CALLVALUE |
+| 10A | JUMPI | CALLVALUE |
+| 10B | PUSH1 0x00 | 0x00 CALLVALUE |
+| 10D | DUP1 | 0x00 0x00 CALLVALUE |
+| 10E | REVERT | |
+
+První věc, kterou tato funkce dělá, je kontrola, zda volání neposlalo žádné ETH. Tato funkce není [`payable`](https://solidity-by-example.org/payable/). Pokud nám někdo poslal ETH, musí to být omyl a chceme provést `REVERT`, abychom se vyhnuli tomu, že by se tyto ETH dostaly tam, odkud je nemohou dostat zpět.
+
+| Offset | Opkód | Zásobník |
+| -----: | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 10F | JUMPDEST | |
+| 110 | POP | |
+| 111 | PUSH1 0x03 | 0x03 |
+| 113 | SLOAD | (((Storage[3] a.k.a kontrakt, pro který jsme proxy))) |
+| 114 | PUSH1 0x40 | 0x40 (((Storage[3] a.k.a kontrakt, pro který jsme proxy))) |
+| 116 | MLOAD | 0x80 (((Storage[3] a.k.a kontrakt, pro který jsme proxy))) |
+| 117 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xFF...FF 0x80 (((Storage[3] a.k.a kontrakt, pro který jsme proxy))) |
+| 12C | SWAP1 | 0x80 0xFF...FF (((Storage[3] a.k.a kontrakt, pro který jsme proxy))) |
+| 12D | SWAP2 | (((Storage[3] a.k.a kontrakt, pro který jsme proxy))) 0xFF...FF 0x80 |
+| 12E | AND | ProxyAddr 0x80 |
+| 12F | DUP2 | 0x80 ProxyAddr 0x80 |
+| 130 | MSTORE | 0x80 |
+
+A 0x80 nyní obsahuje adresu proxy
+
+| Offset | Opkód | Zásobník |
+| -----: | ------------ | --------- |
+| 131 | PUSH1 0x20 | 0x20 0x80 |
+| 133 | ADD | 0xA0 |
+| 134 | PUSH2 0x00e4 | 0xE4 0xA0 |
+| 137 | JUMP | 0xA0 |
+
+### Kód E4 {#the-e4-code}
+
+Toto je poprvé, co vidíme tyto řádky, ale jsou sdíleny s dalšími metodami (viz níže). Hodnotu v zásobníku tedy nazveme X a budeme si pamatovat, že v `splitter()` je hodnota tohoto X 0xA0.
+
+| Offset | Opkód | Zásobník |
+| -----: | ---------- | ----------- |
+| E4 | JUMPDEST | X |
+| E5 | PUSH1 0x40 | 0x40 X |
+| E7 | MLOAD | 0x80 X |
+| E8 | DUP1 | 0x80 0x80 X |
+| E9 | SWAP2 | X 0x80 0x80 |
+| EA | SUB | X-0x80 0x80 |
+| EB | SWAP1 | 0x80 X-0x80 |
+| EC | RETURN | |
+
+Tento kód tedy obdrží ukazatel na paměť v zásobníku (X) a způsobí, že kontrakt `RETURN` s vyrovnávací pamětí, která je 0x80 - X.
+
+V případě `splitter()` vrátí adresu, pro kterou jsme proxy. `RETURN` vrátí vyrovnávací paměť v 0x80-0x9F, což je místo, kam jsme zapsali tato data (offset 0x130 výše).
+
+## currentWindow() {#currentwindow}
+
+Kód v offsetech 0x158-0x163 je identický s tím, co jsme viděli v 0x103-0x10E v `splitter()` (kromě cíle `JUMPI`), takže víme, že `currentWindow()` také není `payable`.
+
+| Offset | Opkód | Zásobník |
+| -----: | ------------ | ------------------------------------------------------------------------ |
+| 164 | JUMPDEST | |
+| 165 | POP | |
+| 166 | PUSH2 0x00da | 0xDA |
+| 169 | PUSH1 0x01 | 0x01 0xDA |
+| 16B | SLOAD | Storage[1] 0xDA |
+| 16C | DUP2 | 0xDA Storage[1] 0xDA |
+| 16D | JUMP | Storage[1] 0xDA |
+
+### Kód DA {#the-da-code}
+
+Tento kód je také sdílen s dalšími metodami. Hodnotu v zásobníku tedy nazveme Y a budeme si pamatovat, že v `currentWindow()` je hodnota tohoto Y Storage[1].
+
+| Offset | Opkód | Zásobník |
+| -----: | ---------- | ---------------- |
+| DA | JUMPDEST | Y 0xDA |
+| DB | PUSH1 0x40 | 0x40 Y 0xDA |
+| DD | MLOAD | 0x80 Y 0xDA |
+| DE | SWAP1 | Y 0x80 0xDA |
+| DF | DUP2 | 0x80 Y 0x80 0xDA |
+| E0 | MSTORE | 0x80 0xDA |
+
+Zapište Y do 0x80-0x9F.
+
+| Offset | Opkód | Zásobník |
+| -----: | ---------- | -------------- |
+| E1 | PUSH1 0x20 | 0x20 0x80 0xDA |
+| E3 | ADD | 0xA0 0xDA |
+
+A zbytek je již vysvětlen [výše](#the-e4-code). Takže skoky na 0xDA zapíší vrchol zásobníku (Y) do 0x80-0x9F a vrátí tuto hodnotu. V případě `currentWindow()` vrátí Storage[1].
+
+## merkleRoot() {#merkleroot}
+
+Kód v offsetech 0xED-0xF8 je identický s tím, co jsme viděli v 0x103-0x10E v `splitter()` (kromě cíle `JUMPI`), takže víme, že `merkleRoot()` také není `payable`.
+
+| Offset | Opkód | Zásobník |
+| -----: | ------------ | ------------------------------------------------------------------------ |
+| F9 | JUMPDEST | |
+| FA | POP | |
+| FB | PUSH2 0x00da | 0xDA |
+| FE | PUSH1 0x00 | 0x00 0xDA |
+| 100 | SLOAD | Storage[0] 0xDA |
+| 101 | DUP2 | 0xDA Storage[0] 0xDA |
+| 102 | JUMP | Storage[0] 0xDA |
+
+Co se stane po skoku [jsme již zjistili](#the-da-code). Takže `merkleRoot()` vrátí Storage[0].
+
+## 0x81e580d3 {#0x81e580d3}
+
+Kód v offsetech 0x138-0x143 je identický s tím, co jsme viděli v 0x103-0x10E v `splitter()` (kromě cíle `JUMPI`), takže víme, že tato funkce také není `payable`.
+
+| Offset | Opkód | Zásobník |
+| -----: | ------------ | ------------------------------------------------------------------------------- |
+| 144 | JUMPDEST | |
+| 145 | POP | |
+| 146 | PUSH2 0x00da | 0xDA |
+| 149 | PUSH2 0x0153 | 0x0153 0xDA |
+| 14C | CALLDATASIZE | CALLDATASIZE 0x0153 0xDA |
+| 14D | PUSH1 0x04 | 0x04 CALLDATASIZE 0x0153 0xDA |
+| 14F | PUSH2 0x018f | 0x018F 0x04 CALLDATASIZE 0x0153 0xDA |
+| 152 | JUMP | 0x04 CALLDATASIZE 0x0153 0xDA |
+| 18F | JUMPDEST | 0x04 CALLDATASIZE 0x0153 0xDA |
+| 190 | PUSH1 0x00 | 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 192 | PUSH1 0x20 | 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 194 | DUP3 | 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 195 | DUP5 | CALLDATASIZE 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 196 | SUB | CALLDATASIZE-4 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 197 | SLT | CALLDATASIZE-4\<32 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 198 | ISZERO | CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 199 | PUSH2 0x01a0 | 0x01A0 CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 19C | JUMPI | 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+
+Vypadá to, že tato funkce bere alespoň 32 bajtů (jedno slovo) calldata.
+
+| Offset | Opkód | Zásobník |
+| -----: | ------ | -------------------------------------------- |
+| 19D | DUP1 | 0x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 19E | DUP2 | 0x00 0x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 19F | REVERT | |
+
+Pokud neobdrží calldata, transakce je vrácena zpět bez jakýchkoli návratových dat.
+
+Podívejme se, co se stane, když funkce _dostane_ potřebná calldata.
+
+| Offset | Opkód | Zásobník |
+| -----: | ------------ | ----------------------------------------------------------- |
+| 1A0 | JUMPDEST | 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 1A1 | POP | 0x04 CALLDATASIZE 0x0153 0xDA |
+| 1A2 | CALLDATALOAD | calldataload(4) CALLDATASIZE 0x0153 0xDA |
+
+`calldataload(4)` je první slovo calldata _po_ podpisu metody
+
+| Offset | Opkód | Zásobník |
+| -----: | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 1A3 | SWAP2 | 0x0153 CALLDATASIZE calldataload(4) 0xDA |
+| 1A4 | SWAP1 | CALLDATASIZE 0x0153 calldataload(4) 0xDA |
+| 1A5 | POP | 0x0153 calldataload(4) 0xDA |
+| 1A6 | JUMP | calldataload(4) 0xDA |
+| 153 | JUMPDEST | calldataload(4) 0xDA |
+| 154 | PUSH2 0x016e | 0x016E calldataload(4) 0xDA |
+| 157 | JUMP | calldataload(4) 0xDA |
+| 16E | JUMPDEST | calldataload(4) 0xDA |
+| 16F | PUSH1 0x04 | 0x04 calldataload(4) 0xDA |
+| 171 | DUP2 | calldataload(4) 0x04 calldataload(4) 0xDA |
+| 172 | DUP2 | 0x04 calldataload(4) 0x04 calldataload(4) 0xDA |
+| 173 | SLOAD | Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA |
+| 174 | DUP2 | calldataload(4) Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA |
+| 175 | LT | calldataload(4)\)` a další je `isClaimed()`, takže to vypadá na airdrop kontrakt. Místo toho, abychom procházeli zbytek opkód po opkódu, můžeme [vyzkoušet dekompilátor](https://etherscan.io/bytecode-decompiler?a=0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761), který pro tři funkce z tohoto kontraktu vytváří použitelné výsledky. Reverzní inženýrství ostatních je ponecháno jako cvičení pro čtenáře.
+
+### scaleAmountByPercentage {#scaleamountbypercentage}
+
+Toto nám dekompilátor dává pro tuto funkci:
+
+```python
+def unknown8ffb5c97(uint256 _param1, uint256 _param2) payable:
+ require calldata.size - 4 >=′ 64
+ if _param1 and _param2 > -1 / _param1:
+ revert with 0, 17
+ return (_param1 * _param2 / 100 * 10^6)
+```
+
+První `require` testuje, zda calldata mají kromě čtyř bajtů signatury funkce alespoň 64 bajtů, což stačí pro dva parametry. Pokud ne, je zjevně něco špatně.
+
+Příkaz `if` se zdá, že kontroluje, zda `_param1` není nula a zda `_param1 * _param2` není záporné. Pravděpodobně se tak předchází případům přetečení.
+
+Nakonec funkce vrátí škálovanou hodnotu.
+
+### claim {#claim}
+
+Kód, který dekompilátor vytváří, je složitý a ne všechen je pro nás relevantní. Chystám se přeskočit některé jeho části, abych se zaměřil na řádky, které podle mě poskytují užitečné informace
+
+```python
+def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _param4) payable:
+ ...
+ require _param2 == addr(_param2)
+ ...
+ if currentWindow <= _param1:
+ revert with 0, 'cannot claim for a future window'
+```
+
+Vidíme zde dvě důležité věci:
+
+- `_param2`, i když je deklarován jako `uint256`, je ve skutečnosti adresa
+- `_param1` je nárokované okno, které musí být `currentWindow` nebo dřívější.
+
+```python
+ ...
+ if stor5[_claimWindow][addr(_claimFor)]:
+ revert with 0, 'Account already claimed the given window'
+```
+
+Takže teď víme, že Storage[5] je pole oken a adres a zda adresa nárokovala odměnu za dané okno.
+
+```python
+ ...
+ idx = 0
+ s = 0
+ while idx < _param4.length:
+ ...
+ if s + sha3(mem[(32 * _param4.length) + 328 len mem[(32 * _param4.length) + 296]]) > mem[(32 * idx) + 296]:
+ mem[mem[64] + 32] = mem[(32 * idx) + 296]
+ ...
+ s = sha3(mem[_62 + 32 len mem[_62]])
+ continue
+ ...
+ s = sha3(mem[_66 + 32 len mem[_66]])
+ continue
+ if unknown2eb4a7ab != s:
+ revert with 0, 'Invalid proof'
+```
+
+Víme, že `unknown2eb4a7ab` je ve skutečnosti funkce `merkleRoot()`, takže tento kód vypadá, jako by ověřoval [Merkleho důkaz](https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5). To znamená, že `_param4` je Merkleho důkaz.
+
+```python
+ call addr(_param2) with:
+ value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei
+ gas 30000 wei
+```
+
+Takto kontrakt převádí své vlastní ETH na jinou adresu (kontrakt nebo externě vlastněný účet). Volá ji s hodnotou, která je částkou, jež má být převedena. Vypadá to tedy, že se jedná o airdrop ETH.
+
+```python
+ if not return_data.size:
+ if not ext_call.success:
+ require ext_code.size(stor2)
+ call stor2.deposit() with:
+ value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei
+```
+
+Spodní dva řádky nám říkají, že Storage[2] je také kontrakt, který voláme. Pokud se [podíváme na transakci konstruktoru](https://etherscan.io/tx/0xa1ea0549fb349eb7d3aff90e1d6ce7469fdfdcd59a2fd9b8d1f5e420c0d05b58#statechange), vidíme, že tento kontrakt je [0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2), kontrakt Wrapped Ether [jehož zdrojový kód byl nahrán na Etherscan](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2#code).
+
+Vypadá to tedy, že se kontrakty pokoušejí poslat ETH na `_param2`. Pokud to dokáže, skvělé. Pokud ne, pokusí se odeslat [WETH](https://weth.tkn.eth.limo/). Pokud je `_param2` externě vlastněný účet (EOA), může vždy přijímat ETH, ale kontrakty mohou odmítnout přijímat ETH. WETH je však ERC-20 a kontrakty to nemohou odmítnout.
+
+```python
+ ...
+ log 0xdbd5389f: addr(_param2), unknown81e580d3[_param1] * _param3 / 100 * 10^6, bool(ext_call.success)
+```
+
+Na konci funkce vidíme generovaný záznam protokolu. [Podívejte se na vygenerované záznamy protokolu](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#events) a filtrujte podle tématu, které začíná `0xdbd5...`. Pokud [klikneme na jednu z transakcí, která takový záznam vygenerovala](https://etherscan.io/tx/0xe7d3b7e00f645af17dfbbd010478ef4af235896c65b6548def1fe95b3b7d2274), uvidíme, že to skutečně vypadá jako nárok – účet odeslal zprávu kontraktu, který reverzně inženýrujeme, a na oplátku dostal ETH.
+
+
+
+### 1e7df9d3 {#1e7df9d3}
+
+Tato funkce je velmi podobná [`claim`](#claim) výše. Také kontroluje Merkleho důkaz, pokouší se převést ETH na první a vytváří stejný typ záznamu do protokolu.
+
+```python
+def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable:
+ ...
+ idx = 0
+ s = 0
+ while idx < _param3.length:
+ if idx >= mem[96]:
+ revert with 0, 50
+ _55 = mem[(32 * idx) + 128]
+ if s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) > mem[(32 * idx) + 128]:
+ ...
+ s = sha3(mem[_58 + 32 len mem[_58]])
+ continue
+ mem[mem[64] + 32] = s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]])
+ ...
+ if unknown2eb4a7ab != s:
+ revert with 0, 'Invalid proof'
+ ...
+ call addr(_param1) with:
+ value s wei
+ gas 30000 wei
+ if not return_data.size:
+ if not ext_call.success:
+ require ext_code.size(stor2)
+ call stor2.deposit() with:
+ value s wei
+ gas gas_remaining wei
+ ...
+ log 0xdbd5389f: addr(_param1), s, bool(ext_call.success)
+```
+
+Hlavní rozdíl je v tom, že první parametr, okno pro výběr, zde není. Místo toho existuje smyčka přes všechna okna, která by mohla být nárokována.
+
+```python
+ idx = 0
+ s = 0
+ while idx < currentWindow:
+ ...
+ if stor5[mem[0]]:
+ if idx == -1:
+ revert with 0, 17
+ idx = idx + 1
+ s = s
+ continue
+ ...
+ stor5[idx][addr(_param1)] = 1
+ if idx >= unknown81e580d3.length:
+ revert with 0, 50
+ mem[0] = 4
+ if unknown81e580d3[idx] and _param2 > -1 / unknown81e580d3[idx]:
+ revert with 0, 17
+ if s > !(unknown81e580d3[idx] * _param2 / 100 * 10^6):
+ revert with 0, 17
+ if idx == -1:
+ revert with 0, 17
+ idx = idx + 1
+ s = s + (unknown81e580d3[idx] * _param2 / 100 * 10^6)
+ continue
+```
+
+Vypadá to tedy na variantu `claim`, která nárokuje všechna okna.
+
+## Závěr {#conclusion}
+
+Nyní byste měli vědět, jak porozumět kontraktům, jejichž zdrojový kód není k dispozici, a to buď pomocí opkódů, nebo (pokud to funguje) pomocí dekompilátoru. Jak je zřejmé z délky tohoto článku, reverzní inženýrství kontraktu není triviální, ale v systému, kde je bezpečnost zásadní, je důležitou dovedností umět ověřit, že kontrakty fungují, jak slibují.
+
+[Více z mé práce najdete zde](https://cryptodocguy.pro/).
diff --git a/public/content/translations/cs/developers/tutorials/run-node-raspberry-pi/index.md b/public/content/translations/cs/developers/tutorials/run-node-raspberry-pi/index.md
new file mode 100644
index 00000000000..cb90eecd926
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/run-node-raspberry-pi/index.md
@@ -0,0 +1,190 @@
+---
+title: Spuštění uzlu Etherea na Raspberry Pi 4
+description: Flashněte své Raspberry Pi 4, zapojte ethernetový kabel, připojte disk SSD a zapněte zařízení, abyste z Raspberry Pi 4 udělali plnohodnotný uzel Etherea + validátor.
+author: "EthereumOnArm"
+tags:
+ [
+ "klienti",
+ "exekuční vrstva",
+ "konsensuální vrstva",
+ "uzly"
+ ]
+lang: cs
+skill: intermediate
+published: 2022-06-10
+source: Ethereum na ARM
+sourceUrl: https://ethereum-on-arm-documentation.readthedocs.io/en/latest/
+---
+
+**Ethereum on Arm je vlastní obraz systému Linux, který může z Raspberry Pi udělat uzel Etherea.**
+
+Pro použití Etherea na Arm a přeměnu Raspberry Pi na uzel Etherea se doporučuje následující hardware:
+
+- Deska Raspberry 4 (model B 8GB), Odroid M1 nebo Rock 5B (8GB/16GB RAM)
+- MicroSD karta (minimálně 16 GB, třída 10)
+- Minimálně 2TB disk SSD USB 3.0 nebo SSD s pouzdrem USB na SATA.
+- Zdroj napájení
+- Ethernetový kabel
+- Přesměrování portů (další informace najdete u klientů)
+- Pouzdro s chladičem a ventilátorem
+- USB klávesnice, monitor a kabel HDMI (micro-HDMI) (volitelně)
+
+## Proč provozovat Ethereum na ARM? {#why-run-ethereum-on-arm}
+
+Desky ARM jsou velmi cenově dostupné, flexibilní a malé počítače. Jsou dobrou volbou pro provozování uzlů Etherea, protože je lze levně koupit, nakonfigurovat tak, aby se všechny jejich zdroje soustředily pouze na uzel, což je činí efektivními, spotřebovávají málo energie a jsou fyzicky malé, takže se nenápadně vejdou do každé domácnosti. Je také velmi snadné zprovoznit uzly, protože MicroSD kartu Raspberry Pi lze jednoduše flashnout předpřipraveným obrazem, aniž by bylo nutné stahovat nebo sestavovat software.
+
+## Jak to funguje? {#how-does-it-work}
+
+Paměťová karta Raspberry Pi se flashne předpřipraveným obrazem. Tento obraz obsahuje vše potřebné pro spuštění uzlu Etherea. S flashnutou kartou stačí uživateli pouze zapnout Raspberry Pi. Všechny procesy potřebné ke spuštění uzlu se spustí automaticky. Funguje to proto, že paměťová karta obsahuje operační systém (OS) na bázi Linuxu, na kterém se automaticky spouštějí procesy na úrovni systému, které z jednotky udělají uzel Etherea.
+
+Ethereum nelze provozovat pomocí oblíbeného OS pro Raspberry Pi „Raspbian“, protože Raspbian stále používá 32bitovou architekturu, což způsobuje uživatelům Etherea problémy s pamětí, a konsensuální klienti nepodporují 32bitové binární soubory. Aby se to překonalo, tým Ethereum on Arm přešel na nativní 64bitový OS s názvem „Armbian“.
+
+**Obrazy se postarají o všechny nezbytné kroky**, od nastavení prostředí a formátování disku SSD až po instalaci a spuštění softwaru Etherea a zahájení synchronizace blockchainu.
+
+## Poznámka k exekučním a konsensuálním klientům {#note-on-execution-and-consensus-clients}
+
+Obraz Ethereum on Arm zahrnuje předpřipravené exekuční a konsensuální klienty jako služby. Uzel Etherea vyžaduje, aby byli oba klienti synchronizováni a spuštěni. Stačí si pouze stáhnout a flashnout obraz a poté spustit služby. V obrazu jsou předinstalováni následující exekuční klienti:
+
+- Geth
+- Nethermind
+- Besu
+
+a následující konsensuální klienti:
+
+- Lighthouse
+- Nimbus
+- Prysm
+- Teku
+
+Měli byste si vybrat po jednom z každého typu – všichni exekuční klienti jsou kompatibilní se všemi konsensuálními klienty. Pokud si klienta explicitně nevyberete, uzel se vrátí ke svým výchozím hodnotám – Geth a Lighthouse – a spustí je automaticky po zapnutí desky. Na routeru musíte otevřít port 30303, aby Geth mohl najít peery a připojit se k nim.
+
+## Stažení obrazu {#downloading-the-image}
+
+Obraz Ethereum pro Raspberry Pi 4 je obraz typu „plug and play“, který automaticky nainstaluje a nastaví exekuční i konsensuální klienty, nakonfiguruje je pro vzájemnou komunikaci a připojení k síti Ethereum. Uživatel musí pouze spustit jejich procesy pomocí jednoduchého příkazu.
+
+Stáhněte si obraz Raspberry Pi z [Ethereum on Arm](https://ethereumonarm-my.sharepoint.com/:u:/p/dlosada/Ec_VmUvr80VFjf3RYSU-NzkBmj2JOteDECj8Bibde929Gw?download=1) a ověřte haš SHA256:
+
+```sh
+# Z adresáře obsahujícího stažený obraz
+shasum -a 256 ethonarm_22.04.00.img.zip
+# Haš by měl mít výstup: fb497e8f8a7388b62d6e1efbc406b9558bee7ef46ec7e53083630029c117444f
+```
+
+Upozorňujeme, že obrazy pro desky Rock 5B a Odroid M1 jsou k dispozici na [stránce pro stažení](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/quick-guide/download-and-install.html) Ethereum-on-Arm.
+
+## Flashování MicroSD {#flashing-the-microsd}
+
+MicroSD karta, která bude použita pro Raspberry Pi, by měla být nejprve vložena do stolního počítače nebo notebooku, aby mohla být flashnuta. Poté následující příkazy v terminálu flashnou stažený obraz na SD kartu:
+
+```shell
+# zkontrolujte název MicroSD karty
+sudo fdisk -l
+
+>> sdxxx
+```
+
+Je opravdu důležité zadat správný název, protože další příkaz obsahuje `dd`, který před nahráním obrazu na kartu zcela vymaže její stávající obsah. Chcete-li pokračovat, přejděte do adresáře obsahujícího zazipovaný obraz:
+
+```shell
+# rozbalte a flashněte obraz
+unzip ethonarm_22.04.00.img.zip
+sudo dd bs=1M if=ethonarm_22.04.00.img of=/dev/ conv=fdatasync status=progress
+```
+
+Karta je nyní flashnutá, takže ji lze vložit do Raspberry Pi.
+
+## Spuštění uzlu {#start-the-node}
+
+S SD kartou vloženou do Raspberry Pi připojte ethernetový kabel a SSD a poté zapněte napájení. OS se spustí a automaticky začne provádět předkonfigurované úlohy, které z Raspberry Pi udělají uzel Etherea, včetně instalace a sestavení klientského softwaru. To bude pravděpodobně trvat 10-15 minut.
+
+Jakmile je vše nainstalováno a nakonfigurováno, přihlaste se k zařízení přes ssh připojení nebo přímo pomocí terminálu, pokud je k desce připojen monitor a klávesnice. Pro přihlášení použijte účet `ethereum`, protože má oprávnění potřebná ke spuštění uzlu.
+
+```shell
+Uživatel: ethereum
+Heslo: ethereum
+```
+
+Výchozí exekuční klient, Geth, se spustí automaticky. To můžete potvrdit kontrolou protokolů pomocí následujícího příkazu v terminálu:
+
+```sh
+sudo journalctl -u geth -f
+```
+
+Konsensuální klient je třeba spustit explicitně. Chcete-li to provést, nejprve na routeru otevřete port 9000, aby Lighthouse mohl najít peery a připojit se k nim. Poté povolte a spusťte službu lighthouse:
+
+```sh
+sudo systemctl enable lighthouse-beacon
+sudo systemctl start lighthouse-beacon
+```
+
+Zkontrolujte klienta pomocí protokolů:
+
+```sh
+sudo journalctl -u lighthouse-beacon
+```
+
+Všimněte si, že konsensuální klient se synchronizuje během několika minut, protože používá synchronizaci z kontrolního bodu. Exekučnímu klientovi to bude trvat déle – potenciálně několik hodin, a nespustí se, dokud se konsensuální klient nedosynchronizuje (je to proto, že exekuční klient potřebuje cíl, se kterým se synchronizuje, a ten mu poskytne synchronizovaný konsensuální klient).
+
+Se spuštěnými a synchronizovanými službami Geth a Lighthouse je vaše Raspberry Pi nyní uzlem Etherea! Nejběžnější způsob interakce se sítí Ethereum je pomocí javascriptové konzole Geth, kterou lze připojit ke klientovi Geth na portu 8545. Je také možné odesílat příkazy formátované jako objekty JSON pomocí nástroje pro požadavky, jako je Curl. Více informací naleznete v [dokumentaci Geth](https://geth.ethereum.org/).
+
+Geth je předkonfigurován tak, aby hlásil metriky na řídicí panel Grafana, který lze zobrazit v prohlížeči. Pokročilejší uživatelé mohou chtít tuto funkci využít ke sledování stavu svého uzlu přechodem na `ipaddress:3000` a zadáním `user: admin` a `passwd: ethereum`.
+
+## Validátoři {#validators}
+
+K konsensuálnímu klientovi lze volitelně přidat také validátor. Software validátoru umožňuje vašemu uzlu aktivně se podílet na konsensu a poskytuje síti kryptoekonomickou bezpečnost. Za tuto práci dostanete odměnu v ETH. Abyste mohli spustit validátor, musíte mít nejprve 32 ETH, které musí být vloženy do vkladové smlouvy. Vklad lze provést podle podrobného průvodce na [Launchpadu](https://launchpad.ethereum.org/). Udělejte to na stolním počítači/notebooku, ale negenerujte klíče — to lze provést přímo na Raspberry Pi.
+
+Otevřete terminál na Raspberry Pi a spuštěním následujícího příkazu vygenerujte vkladové klíče:
+
+```
+sudo apt-get update
+sudo apt-get install staking-deposit-cli
+cd && deposit new-mnemonic --num_validators 1
+```
+
+(Nebo si stáhněte [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli) pro spuštění na air-gapped zařízení a spusťte příkaz `deposit new-mnemnonic`)
+
+Uchovejte mnemotechnickou frázi v bezpečí! Výše uvedený příkaz vygeneroval v úložišti klíčů uzlu dva soubory: klíče validátoru a soubor s daty vkladu. Data vkladu je třeba nahrát do Launchpadu, takže je nutné je zkopírovat z Raspberry Pi do stolního počítače/notebooku. To lze provést pomocí ssh připojení nebo jakoukoli jinou metodou kopírování a vkládání.
+
+Jakmile je soubor s daty vkladu k dispozici na počítači, na kterém běží Launchpad, lze jej přetáhnout na `+` na obrazovce Launchpadu. Podle pokynů na obrazovce odešlete transakci do vkladové smlouvy.
+
+Zpět na Raspberry Pi lze spustit validátor. To vyžaduje import klíčů validátoru, nastavení adresy pro sběr odměn a následné spuštění předkonfigurovaného procesu validátoru. Níže uvedený příklad je pro Lighthouse – pokyny pro ostatní konsensuální klienti jsou k dispozici v [dokumentaci Ethereum on Arm](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/):
+
+```shell
+# importujte klíče validátoru
+lighthouse account validator import --directory=/home/ethereum/validator_keys
+
+# nastavte adresu pro odměny
+sudo sed -i 's/' /etc/ethereum/lighthouse-validator.conf
+
+# spusťte validátor
+sudo systemctl start lighthouse-validator
+```
+
+Gratulujeme, nyní máte na Raspberry Pi spuštěný plnohodnotný uzel Etherea a validátor!
+
+## Další podrobnosti {#more-details}
+
+Tato stránka poskytla přehled o tom, jak nastavit uzel a validátor Geth-Lighthouse pomocí Raspberry Pi. Podrobnější pokyny jsou k dispozici na [webu Ethereum-on-Arm](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/index.html).
+
+## Zpětná vazba je vítána {#feedback-appreciated}
+
+Víme, že Raspberry Pi má obrovskou uživatelskou základnu, která by mohla mít velmi pozitivní dopad na zdraví sítě Ethereum.
+Projděte si prosím podrobnosti v tomto návodu, vyzkoušejte spuštění na testnetech, podívejte se na GitHubu na Ethereum on Arm, poskytněte zpětnou vazbu, nahlašujte problémy a posílejte pull requesty a pomozte tak posunout technologii a dokumentaci!
+
+## Odkazy {#references}
+
+1. https://ubuntu.com/download/raspberry-pi
+2. https://wikipedia.org/wiki/Port_forwarding
+3. https://prometheus.io
+4. https://grafana.com
+5. https://forum.armbian.com/topic/5565-zram-vs-swap/
+6. https://geth.ethereum.org
+7. https://nethermind.io
+8. https://www.hyperledger.org/projects/besu
+9. https://github.com/prysmaticlabs/prysm
+10. https://lighthouse.sigmaprime.io
+11. https://ethersphere.github.io/swarm-home
+12. https://raiden.network
+13. https://ipfs.io
+14. https://status.im
+15. https://vipnode.org
diff --git a/public/content/translations/cs/developers/tutorials/scam-token-tricks/index.md b/public/content/translations/cs/developers/tutorials/scam-token-tricks/index.md
new file mode 100644
index 00000000000..e9981cef970
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/scam-token-tricks/index.md
@@ -0,0 +1,470 @@
+---
+title: "Některé triky používané podvodnými tokeny a jak je odhalit"
+description: V tomto tutoriálu rozebereme podvodný token, abychom se podívali na některé triky, které podvodníci používají, jak je implementují a jak je můžeme odhalit.
+author: Ori Pomerantz
+tags:
+ [
+ "podvod",
+ "solidity",
+ "erc-20",
+ "javascript",
+ "typescript"
+ ]
+skill: intermediate
+published: 2023-09-15
+lang: cs
+---
+
+V tomto tutoriálu rozebereme [podvodný token](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code), abychom se podívali na některé triky, které podvodníci používají a jak je implementují. Na konci tohoto tutoriálu získáte komplexnější pohled na smlouvy o tokenech ERC-20, jejich možnosti a důvody, proč je nutná skepse. Poté se podíváme na události emitované tímto podvodným tokenem a zjistíme, jak můžeme automaticky identifikovat, že není legitimní.
+
+## Podvodné tokeny – co jsou, proč je lidé vytvářejí a jak se jim vyhnout {#scam-tokens}
+
+Jedním z nejčastějších způsobů využití Etherea je vytvoření obchodovatelného tokenu pro skupinu, v podstatě jejich vlastní měny. Kdekoliv, kde existují legitimní případy použití, které přinášejí hodnotu, se také objevují i zločinci, kteří se snaží tuto hodnotu ukrást pro sebe.
+
+Více si o tomto tématu můžete přečíst [jinde na ethereum.org](/guides/how-to-id-scam-tokens/) z pohledu uživatele. Tento tutoriál se zaměřuje na rozebrání podvodného tokenu, abychom zjistili, jak je vytvořen a jak jej lze odhalit.
+
+### Jak poznám, že wARB je podvod? {#warb-scam}
+
+Token, který rozebíráme, je [wARB](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code), který se tváří jako ekvivalent legitimního [tokenu ARB](https://etherscan.io/token/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1).
+
+Nejjednodušší způsob, jak zjistit, který token je legitimní, je podívat se na původní organizaci, [Arbitrum](https://arbitrum.foundation/). Legitimní adresy jsou uvedeny [v jejich dokumentaci](https://docs.arbitrum.foundation/deployment-addresses#token).
+
+### Proč je zdrojový kód dostupný? {#why-source}
+
+Obvykle bychom očekávali, že lidé, kteří se snaží ostatní podvést, budou tajnůstkářští, a skutečně mnoho podvodných tokenů nemá svůj kód k dispozici (například [tento](https://optimistic.etherscan.io/token/0x15992f382d8c46d667b10dc8456dc36651af1452#code) a [tento](https://optimistic.etherscan.io/token/0x026b623eb4aada7de37ef25256854f9235207178#code)).
+
+Legitimní tokeny však obvykle svůj zdrojový kód zveřejňují, takže aby působili legitimně, autoři podvodných tokenů někdy dělají totéž. [wARB](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code) je jedním z těch tokenů s dostupným zdrojovým kódem, což usnadňuje jeho pochopení.
+
+I když si tvůrci smluv mohou vybrat, zda zdrojový kód zveřejní, či nikoli, _nemohou_ zveřejnit nesprávný zdrojový kód. Průzkumník bloků nezávisle zkompiluje poskytnutý zdrojový kód, a pokud neobdrží přesně stejný bajtkód, tento zdrojový kód odmítne. [Více si o tom můžete přečíst na stránkách Etherscanu](https://etherscan.io/verifyContract).
+
+## Srovnání s legitimními tokeny ERC-20 {#compare-legit-erc20}
+
+Tento token porovnáme s legitimními tokeny ERC-20. Pokud nevíte, jak se obvykle píší legitimní tokeny ERC-20, [podívejte se na tento tutoriál](/developers/tutorials/erc20-annotated-code/).
+
+### Konstanty pro privilegované adresy {#constants-for-privileged-addresses}
+
+Smlouvy někdy potřebují privilegované adresy. Smlouvy, které jsou navrženy pro dlouhodobé použití, umožňují některé privilegované adrese změnit tyto adresy, například aby bylo možné použít novou smlouvu multisig. Existuje několik způsobů, jak to udělat.
+
+[Smlouva tokenu `HOP`](https://etherscan.io/address/0xc5102fe9359fd9a28f877a67e36b0f050d81a3cc#code) používá vzor [`Ownable`](https://docs.openzeppelin.com/contracts/2.x/access-control#ownership-and-ownable). Privilegovaná adresa je uložena v úložišti, v poli nazvaném `_owner` (viz třetí soubor, `Ownable.sol`).
+
+```solidity
+abstract contract Ownable is Context {
+ address private _owner;
+ .
+ .
+ .
+}
+```
+
+Smlouva o [tokenu `ARB`](https://etherscan.io/address/0xad0c361ef902a7d9851ca7dcc85535da2d3c6fc7#code) nemá přímo privilegovanou adresu. Nepotřebuje ji však. Nachází se za [`proxy`](https://docs.openzeppelin.com/contracts/5.x/api/proxy) na [adrese `0xb50721bcf8d664c30412cfbc6cf7a15145234ad1`](https://etherscan.io/address/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1#code). Tato smlouva má privilegovanou adresu (viz čtvrtý soubor, `ERC1967Upgrade.sol`), kterou lze použít pro upgrady.
+
+```solidity
+ /**
+ * @dev Uloží novou adresu do slotu správce EIP1967.
+ */
+ function _setAdmin(address newAdmin) private {
+ require(newAdmin != address(0), "ERC1967: nový správce je nulová adresa");
+ StorageSlot.getAddressSlot(_ADMIN_SLOT).value = newAdmin;
+ }
+```
+
+Naproti tomu smlouva `wARB` má napevno zakódovaného `contract_owner`.
+
+```solidity
+contract WrappedArbitrum is Context, IERC20 {
+ .
+ .
+ .
+ address deployer = 0xB50721BCf8d664c30412Cfbc6cf7a15145234ad1;
+ address public contract_owner = 0xb40dE7b1beE84Ff2dc22B70a049A07A13a411A33;
+ .
+ .
+ .
+}
+```
+
+[Tento vlastník smlouvy](https://etherscan.io/address/0xb40dE7b1beE84Ff2dc22B70a049A07A13a411A33) není smlouva, kterou by mohly v různých časech ovládat různé účty, ale [externě vlastněný účet](/developers/docs/accounts/#externally-owned-accounts-and-key-pairs). To znamená, že je pravděpodobně navržen pro krátkodobé použití jednotlivcem, spíše než jako dlouhodobé řešení pro ovládání ERC-20, které si udrží hodnotu.
+
+A skutečně, když se podíváme na Etherscan, vidíme, že podvodník tuto smlouvu používal pouze 12 hodin ([první transakce](https://etherscan.io/tx/0xf49136198c3f925fcb401870a669d43cecb537bde36eb8b41df77f06d5f6fbc2) po [poslední transakci](https://etherscan.io/tx/0xdfd6e717157354e64bbd5d6adf16761e5a5b3f914b1948d3545d39633244d47b)) dne 19. května 2023.
+
+### Falešná funkce `_transfer` {#the-fake-transfer-function}
+
+Je standardní, že skutečné převody probíhají pomocí [interní funkce `_transfer`](/developers/tutorials/erc20-annotated-code/#the-_transfer-function-_transfer).
+
+Ve `wARB` tato funkce vypadá téměř legitimně:
+
+```solidity
+ function _transfer(address sender, address recipient, uint256 amount) internal virtual{
+ require(sender != address(0), "ERC20: převod z nulové adresy");
+ require(recipient != address(0), "ERC20: převod na nulovou adresu");
+
+ _beforeTokenTransfer(sender, recipient, amount);
+
+ _balances[sender] = _balances[sender].sub(amount, "ERC20: částka převodu překračuje zůstatek");
+ _balances[recipient] = _balances[recipient].add(amount);
+ if (sender == contract_owner){
+ sender = deployer;
+ }
+ emit Transfer(sender, recipient, amount);
+ }
+```
+
+Podezřelá část je:
+
+```solidity
+ if (sender == contract_owner){
+ sender = deployer;
+ }
+ emit Transfer(sender, recipient, amount);
+```
+
+Pokud vlastník smlouvy posílá tokeny, proč událost `Transfer` ukazuje, že pocházejí od `deployer`?
+
+Je zde však důležitější problém. Kdo volá tuto funkci `_transfer`? Nelze ji volat zvenčí, je označena jako `internal`. A kód, který máme, neobsahuje žádná volání `_transfer`. Je zřejmé, že je zde jako návnada.
+
+```solidity
+ function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
+ _f_(_msgSender(), recipient, amount);
+ return true;
+ }
+
+ function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) {
+ _f_(sender, recipient, amount);
+ _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "ERC20: částka převodu překračuje povolenou částku"));
+ return true;
+ }
+```
+
+Když se podíváme na funkce, které se volají pro převod tokenů, `transfer` a `transferFrom`, vidíme, že volají úplně jinou funkci, `_f_`.
+
+### Skutečná funkce `_f_` {#the-real-f-function}
+
+```solidity
+ function _f_(address sender, address recipient, uint256 amount) internal _mod_(sender,recipient,amount) virtual {
+ require(sender != address(0), "ERC20: převod z nulové adresy");
+ require(recipient != address(0), "ERC20: převod na nulovou adresu");
+
+ _beforeTokenTransfer(sender, recipient, amount);
+
+ _balances[sender] = _balances[sender].sub(amount, "ERC20: částka převodu překračuje zůstatek");
+ _balances[recipient] = _balances[recipient].add(amount);
+ if (sender == contract_owner){
+
+ sender = deployer;
+ }
+ emit Transfer(sender, recipient, amount);
+ }
+```
+
+V této funkci jsou dva potenciální varovné signály.
+
+- Použití [modifikátoru funkce](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm) `_mod_`. Když se však podíváme do zdrojového kódu, vidíme, že `_mod_` je ve skutečnosti neškodný.
+
+ ```solidity
+ modifier _mod_(address sender, address recipient, uint256 amount){
+ _;
+ }
+ ```
+
+- Stejný problém, který jsme viděli v `_transfer`, což je, když `contract_owner` posílá tokeny, které se zdají pocházet od `deployer`.
+
+### Falešná funkce událostí `dropNewTokens` {#the-fake-events-function-dropNewTokens}
+
+Nyní se dostáváme k něčemu, co vypadá jako skutečný podvod. Funkci jsem pro lepší čitelnost trochu upravil, ale je funkčně ekvivalentní.
+
+```solidity
+function dropNewTokens(address uPool,
+ address[] memory eReceiver,
+ uint256[] memory eAmounts) public auth()
+```
+
+Tato funkce má modifikátor `auth()`, což znamená, že ji může volat pouze vlastník smlouvy.
+
+```solidity
+modifier auth() {
+ require(msg.sender == contract_owner, "Interakce není povolena");
+ _;
+}
+```
+
+Toto omezení dává dokonalý smysl, protože bychom nechtěli, aby náhodné účty distribuovaly tokeny. Zbytek funkce je však podezřelý.
+
+```solidity
+{
+ for (uint256 i = 0; i < eReceiver.length; i++) {
+ emit Transfer(uPool, eReceiver[i], eAmounts[i]);
+ }
+}
+```
+
+Funkce pro převod z účtu fondu na pole příjemců pole částek dává dokonalý smysl. Existuje mnoho případů použití, kdy budete chtít distribuovat tokeny z jednoho zdroje do více cílů, jako jsou výplaty, airdropy atd. Je levnější (z hlediska paliva) provést to v jedné transakci namísto vydávání více transakcí, nebo dokonce volat ERC-20 vícekrát z jiné smlouvy jako součást stejné transakce.
+
+`dropNewTokens` to však nedělá. Emituje [události `Transfer`](https://eips.ethereum.org/EIPS/eip-20#transfer-1), ale ve skutečnosti žádné tokeny nepřevádí. Neexistuje žádný legitimní důvod k matení offchainových aplikací tím, že jim řeknete o převodu, který se ve skutečnosti nestal.
+
+### Pálící funkce `Approve` {#the-burning-approve-function}
+
+Smlouvy ERC-20 mají mít [funkci `approve`](/developers/tutorials/erc20-annotated-code/#approve) pro povolené částky, a náš podvodný token skutečně takovou funkci má, a je dokonce správná. Protože však Solidity vychází z jazyka C, rozlišuje velikost písmen. "Approve" a "approve" jsou různé řetězce.
+
+Funkčnost také nesouvisí s `approve`.
+
+```solidity
+ function Approve(
+ address[] memory holders)
+```
+
+Tato funkce je volána s polem adres držitelů tokenu.
+
+```solidity
+ public approver() {
+```
+
+Modifikátor `approver()` zajišťuje, že tuto funkci může volat pouze `contract_owner` (viz níže).
+
+```solidity
+ for (uint256 i = 0; i < holders.length; i++) {
+ uint256 amount = _balances[holders[i]];
+ _beforeTokenTransfer(holders[i], 0x0000000000000000000000000000000000000001, amount);
+ _balances[holders[i]] = _balances[holders[i]].sub(amount,
+ "ERC20: pálená částka překračuje zůstatek");
+ _balances[0x0000000000000000000000000000000000000001] =
+ _balances[0x0000000000000000000000000000000000000001].add(amount);
+ }
+ }
+
+```
+
+Pro každou adresu držitele funkce přesune celý zůstatek držitele na adresu `0x00...01` a tím ho efektivně spálí (skutečné `pálení` ve standardu také mění celkovou zásobu a převádí tokeny na `0x00...00`). To znamená, že `contract_owner` může odebrat majetek jakéhokoli uživatele. To se nezdá jako funkce, kterou byste chtěli ve správcovském tokenu.
+
+### Problémy s kvalitou kódu {#code-quality-issues}
+
+Tyto problémy s kvalitou kódu _nedokazují_, že tento kód je podvod, ale způsobují, že působí podezřele. Organizované společnosti jako Arbitrum obvykle takto špatný kód nevydávají.
+
+#### Funkce `mount` {#the-mount-function}
+
+Ačkoli to není uvedeno ve [standardu](https://eips.ethereum.org/EIPS/eip-20), obecně se funkce, která vytváří nové tokeny, nazývá [`mint`](https://ethereum.org/el/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn).
+
+Když se podíváme do konstruktoru `wARB`, vidíme, že funkce mint byla z nějakého důvodu přejmenována na `mount` a je volána pětkrát s pětinou počáteční zásoby, místo jednou pro celou částku z důvodu efektivity.
+
+```solidity
+ constructor () public {
+
+ _name = "Wrapped Arbitrum";
+ _symbol = "wARB";
+ _decimals = 18;
+ uint256 initialSupply = 1000000000000;
+
+ mount(deployer, initialSupply*(10**18)/5);
+ mount(deployer, initialSupply*(10**18)/5);
+ mount(deployer, initialSupply*(10**18)/5);
+ mount(deployer, initialSupply*(10**18)/5);
+ mount(deployer, initialSupply*(10**18)/5);
+ }
+```
+
+Samotná funkce `mount` je také podezřelá.
+
+```solidity
+ function mount(address account, uint256 amount) public {
+ require(msg.sender == contract_owner, "ERC20: ražba na nulovou adresu");
+```
+
+Při pohledu na `require` vidíme, že pouze vlastník smlouvy má povoleno razit. To je legitimní. Ale chybová zpráva by měla být _pouze vlastník má povoleno razit_ nebo něco podobného. Místo toho je to irelevantní _ERC20: ražba na nulovou adresu_. Správný test pro ražbu na nulovou adresu je `require(account != address(0), "")`, což se smlouva nikdy neobtěžuje zkontrolovat.
+
+```solidity
+ _totalSupply = _totalSupply.add(amount);
+ _balances[contract_owner] = _balances[contract_owner].add(amount);
+ emit Transfer(address(0), account, amount);
+ }
+```
+
+Existují dvě další podezřelé skutečnosti, přímo související s ražbou:
+
+- Existuje parametr `account`, což je pravděpodobně účet, který by měl obdržet vyraženou částku. Ale zůstatek, který se zvyšuje, je ve skutečnosti `contract_owner`a.
+
+- Zatímco zvýšený zůstatek patří `contract_owner`ovi, emitovaná událost ukazuje převod na `account`.
+
+### Proč `auth` i `approver`? Proč `mod`, který nic nedělá? {#why-both-autho-and-approver-why-the-mod-that-does-nothing}
+
+Tato smlouva obsahuje tři modifikátory: `_mod_`, `auth` a `approver`.
+
+```solidity
+ modifier _mod_(address sender, address recipient, uint256 amount){
+ _;
+ }
+```
+
+`_mod_` přijímá tři parametry a nic s nimi nedělá. Proč ho mít?
+
+```solidity
+ modifier auth() {
+ require(msg.sender == contract_owner, "Interakce není povolena");
+ _;
+ }
+
+ modifier approver() {
+ require(msg.sender == contract_owner, "Interakce není povolena");
+ _;
+ }
+```
+
+`auth` a `approver` dávají větší smysl, protože kontrolují, že smlouva byla volána `contract_owner`. Očekávali bychom, že určité privilegované akce, jako je ražba, budou omezeny na tento účet. Jaký je však smysl mít dvě samostatné funkce, které dělají _přesně to samé_?
+
+## Co můžeme detekovat automaticky? {#what-can-we-detect-automatically}
+
+Při pohledu na Etherscan vidíme, že `wARB` je podvodný token. Jedná se však o centralizované řešení. Teoreticky by mohl být Etherscan podvržen nebo napaden. Je lepší být schopen nezávisle zjistit, zda je token legitimní, nebo ne.
+
+Existují některé triky, které můžeme použít k identifikaci, že token ERC-20 je podezřelý (buď podvod, nebo velmi špatně napsaný), a to pohledem na události, které emitují.
+
+## Podezřelé události `Approval` {#suspicious-approval-events}
+
+[Události `Approval`](https://eips.ethereum.org/EIPS/eip-20#approval) by se měly dít pouze na přímou žádost (na rozdíl od [událostí `Transfer`](https://eips.ethereum.org/EIPS/eip-20#transfer-1), které se mohou stát v důsledku povolené částky). [Viz dokumentaci Solidity](https://docs.soliditylang.org/en/v0.8.20/security-considerations.html#tx-origin) pro podrobné vysvětlení tohoto problému a proč musí být žádosti přímé, nikoli zprostředkované smlouvou.
+
+To znamená, že události `Approval`, které schvalují útratu z [externě vlastněného účtu](/developers/docs/accounts/#types-of-account), musí pocházet z transakcí, které vznikly na tomto účtu a jejichž cílem je smlouva ERC-20. Jakýkoli jiný druh schválení z externě vlastněného účtu je podezřelý.
+
+Zde je [program, který identifikuje tento druh události](https://github.com/qbzzt/20230915-scam-token-detection), pomocí [viem](https://viem.sh/) a [TypeScript](https://www.typescriptlang.org/docs/), varianty JavaScriptu s typovou bezpečností. Spustíte ho takto:
+
+1. Zkopírujte `.env.example` do `.env`.
+2. Upravte `.env` a zadejte URL k uzlu hlavní sítě Ethereum.
+3. Spusťte `pnpm install` pro instalaci potřebných balíčků.
+4. Spusťte `pnpm susApproval` pro vyhledání podezřelých schválení.
+
+Zde je vysvětlení řádek po řádku:
+
+```typescript
+import {
+ Address,
+ TransactionReceipt,
+ createPublicClient,
+ http,
+ parseAbiItem,
+} from "viem"
+import { mainnet } from "viem/chains"
+```
+
+Importujte definice typů, funkce a definici řetězce z `viem`.
+
+```typescript
+import { config } from "dotenv"
+config()
+```
+
+Přečtěte si `.env` pro získání URL.
+
+```typescript
+const client = createPublicClient({
+ chain: mainnet,
+ transport: http(process.env.URL),
+})
+```
+
+Vytvořte klienta Viem. Potřebujeme pouze číst z blockchainu, takže tento klient nepotřebuje soukromý klíč.
+
+```typescript
+const testedAddress = "0xb047c8032b99841713b8e3872f06cf32beb27b82"
+const fromBlock = 16859812n
+const toBlock = 16873372n
+```
+
+Adresa podezřelé smlouvy ERC-20 a bloky, ve kterých budeme hledat události. Poskytovatelé uzlů obvykle omezují naši schopnost číst události, protože šířka pásma může být drahá. Naštěstí `wARB` nebyl používán po dobu osmnácti hodin, takže se můžeme podívat na všechny události (bylo jich celkem jen 13).
+
+```typescript
+const approvalEvents = await client.getLogs({
+ address: testedAddress,
+ fromBlock,
+ toBlock,
+ event: parseAbiItem(
+ "event Approval(address indexed _owner, address indexed _spender, uint256 _value)"
+ ),
+})
+```
+
+Tímto způsobem požádáte Viem o informace o události. Když mu poskytneme přesný podpis události, včetně názvů polí, událost pro nás analyzuje.
+
+```typescript
+const isContract = async (addr: Address): boolean =>
+ await client.getBytecode({ address: addr })
+```
+
+Náš algoritmus je použitelný pouze na externě vlastněné účty. Pokud `client.getBytecode` vrátí jakýkoli bajtkód, znamená to, že se jedná o smlouvu a měli bychom ji přeskočit.
+
+Pokud jste TypeScript ještě nepoužívali, definice funkce může vypadat trochu divně. Neříkáme mu jen, že se první (a jediný) parametr jmenuje `addr`, ale také, že je typu `Address`. Podobně část `: boolean` říká TypeScriptu, že návratová hodnota funkce je boolean.
+
+```typescript
+const getEventTxn = async (ev: Event): TransactionReceipt =>
+ await client.getTransactionReceipt({ hash: ev.transactionHash })
+```
+
+Tato funkce získá potvrzení o transakci z události. Potvrzení potřebujeme, abychom se ujistili, že známe cíl transakce.
+
+```typescript
+const suspiciousApprovalEvent = async (ev : Event) : (Event | null) => {
+```
+
+Toto je nejdůležitější funkce, která skutečně rozhoduje, zda je událost podezřelá, nebo ne. Návratový typ, `(Event | null)`, říká TypeScriptu, že tato funkce může vrátit buď `Event`, nebo `null`. Vrátíme `null`, pokud událost není podezřelá.
+
+```typescript
+const owner = ev.args._owner
+```
+
+Viem má názvy polí, takže pro nás analyzoval událost. `_owner` je vlastníkem tokenů, které mají být utraceny.
+
+```typescript
+// Schválení smlouvami nejsou podezřelá
+if (await isContract(owner)) return null
+```
+
+Pokud je vlastníkem smlouva, předpokládejme, že toto schválení není podezřelé. Abychom zkontrolovali, zda je schválení smlouvy podezřelé, nebo ne, budeme muset sledovat celé provedení transakce, abychom zjistili, zda se někdy dostala k vlastnické smlouvě a zda tato smlouva volala smlouvu ERC-20 přímo. To je mnohem náročnější na zdroje, než bychom chtěli dělat.
+
+```typescript
+const txn = await getEventTxn(ev)
+```
+
+Pokud schválení pochází z externě vlastněného účtu, získejte transakci, která ho způsobila.
+
+```typescript
+// Schválení je podezřelé, pokud pochází od vlastníka EOA, který není `from` transakce
+if (owner.toLowerCase() != txn.from.toLowerCase()) return ev
+```
+
+Nemůžeme jen zkontrolovat rovnost řetězců, protože adresy jsou hexadecimální, takže obsahují písmena. Někdy, například v `txn.from`, jsou všechna tato písmena malá. V jiných případech, jako je `ev.args._owner`, je adresa v [různých velikostech písmen pro identifikaci chyby](https://eips.ethereum.org/EIPS/eip-55).
+
+Ale pokud transakce nepochází od vlastníka a tento vlastník je externě vlastněn, pak máme podezřelou transakci.
+
+```typescript
+// Je také podezřelé, pokud cíl transakce není smlouva ERC-20, kterou
+// zkoumáme
+if (txn.to.toLowerCase() != testedAddress) return ev
+```
+
+Podobně, pokud adresa `to` transakce, první volaná smlouva, není zkoumaná smlouva ERC-20, pak je to podezřelé.
+
+```typescript
+ // Pokud není důvod k podezření, vrátíme null.
+ return null
+}
+```
+
+Pokud žádná z podmínek není pravdivá, pak událost `Approval` není podezřelá.
+
+```typescript
+const testPromises = approvalEvents.map((ev) => suspiciousApprovalEvent(ev))
+const testResults = (await Promise.all(testPromises)).filter((x) => x != null)
+
+console.log(testResults)
+```
+
+[Funkce `async`](https://www.w3schools.com/js/js_async.asp) vrací objekt `Promise`. S běžnou syntaxí `await x()` čekáme, až se tento `Promise` splní, než budeme pokračovat ve zpracování. To se jednoduše programuje a sleduje, ale je to také neefektivní. Zatímco čekáme na splnění `Promise` pro konkrétní událost, můžeme již začít pracovat na další události.
+
+Zde používáme [`map`](https://www.w3schools.com/jsref/jsref_map.asp) k vytvoření pole objektů `Promise`. Poté použijeme [`Promise.all`](https://www.javascripttutorial.net/es6/javascript-promise-all/) k čekání, až se všechny tyto sliby vyřeší. Poté tyto výsledky [`filtrujeme`](https://www.w3schools.com/jsref/jsref_filter.asp), abychom odstranili nepodezřelé události.
+
+### Podezřelé události `Transfer` {#suspicious-transfer-events}
+
+Dalším možným způsobem, jak identifikovat podvodné tokeny, je zjistit, zda mají nějaké podezřelé převody. Například převody z účtů, které nemají tolik tokenů. Můžete se podívat, [jak implementovat tento test](https://github.com/qbzzt/20230915-scam-token-detection/blob/main/susTransfer.ts), ale `wARB` tento problém nemá.
+
+## Závěr {#conclusion}
+
+Automatická detekce podvodů ERC-20 trpí [falešně negativními výsledky](https://en.wikipedia.org/wiki/False_positives_and_false_negatives#False_negative_error), protože podvod může použít naprosto normální smlouvu o tokenu ERC-20, která jen nepředstavuje nic skutečného. Proto byste se měli vždy pokusit _získat adresu tokenu z důvěryhodného zdroje_.
+
+Automatická detekce může pomoci v určitých případech, jako jsou součásti DeFi, kde je mnoho tokenů a je třeba s nimi zacházet automaticky. Ale jako vždy [caveat emptor](https://www.investopedia.com/terms/c/caveatemptor.asp), proveďte si vlastní průzkum a povzbuďte své uživatele, aby dělali totéž.
+
+[Více z mé práce najdete zde](https://cryptodocguy.pro/).
diff --git a/public/content/translations/cs/developers/tutorials/secret-state/index.md b/public/content/translations/cs/developers/tutorials/secret-state/index.md
new file mode 100644
index 00000000000..f6fd0615078
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/secret-state/index.md
@@ -0,0 +1,741 @@
+---
+title: Použití nulové znalosti pro tajný stav
+description: Onchain hry jsou omezené, protože nemohou uchovávat žádné skryté informace. Po přečtení tohoto tutoriálu bude čtenář schopen kombinovat důkazy s nulovou znalostí a serverové komponenty k vytvoření ověřitelných her s tajnou stavovou offchain komponentou. Technika, jak toho dosáhnout, bude demonstrována vytvořením hry hledání min (minesweeper).
+author: Ori Pomerantz
+tags:
+ [
+ "server",
+ "offchain",
+ "centralizované",
+ "nulová znalost",
+ "zokrates",
+ "mud"
+ ]
+skill: advanced
+lang: cs
+published: 2025-03-15
+---
+
+_Na blockchainu neexistují žádná tajemství_. Vše, co je zveřejněno na blockchainu, si může kdokoli přečíst. To je nutné, protože blockchain je založen na tom, že ho kdokoli může ověřit. Hry však často spoléhají na tajný stav. Například hra [hledání min](https://en.wikipedia.org/wiki/Minesweeper_\(video_game\)) nedává absolutně žádný smysl, pokud se můžete jen podívat na průzkumník bloků a vidět mapu.
+
+Nejjednodušším řešením je použít [serverovou komponentu](/developers/tutorials/server-components/) k uchování tajného stavu. Důvodem, proč používáme blockchain, je však zabránit podvádění ze strany vývojáře hry. Musíme zajistit poctivost serverové komponenty. Server může poskytnout haš stavu a použít [důkazy s nulovou znalostí](/zero-knowledge-proofs/#why-zero-knowledge-proofs-are-important) k prokázání, že stav použitý k výpočtu výsledku tahu je správný.
+
+Po přečtení tohoto článku budete vědět, jak vytvořit tento druh serveru pro uchovávání tajného stavu, klienta pro zobrazení stavu a onchain komponentu pro komunikaci mezi nimi. Hlavní nástroje, které použijeme, budou:
+
+| Nástroj | Účel | Ověřeno na verzi |
+| --------------------------------------------- | ------------------------------------------ | --------------------------------------: |
+| [Zokrates](https://zokrates.github.io/) | Důkazy s nulovou znalostí a jejich ověření | 1.1.9 |
+| [Typescript](https://www.typescriptlang.org/) | Programovací jazyk pro server i klienta | 5.4.2 |
+| [Node](https://nodejs.org/en) | Spuštění serveru | 20.18.2 |
+| [Viem](https://viem.sh/) | Komunikace s blockchainem | 2.9.20 |
+| [MUD](https://mud.dev/) | Onchain správa dat | 2.0.12 |
+| [React](https://react.dev/) | Uživatelské rozhraní klienta | 18.2.0 |
+| [Vite](https://vitejs.dev/) | Poskytování klientského kódu | 4.2.1 |
+
+## Příklad hry Hledání min (Minesweeper) {#minesweeper}
+
+[Hledání min](https://en.wikipedia.org/wiki/Minesweeper_\(video_game\)) je hra, která obsahuje tajnou mapu s minovým polem. Hráč si vybere, kde bude kopat. Pokud je na daném místě mina, hra končí. V opačném případě hráč získá počet min v osmi polích obklopujících dané místo.
+
+Tato aplikace je napsána pomocí [MUD](https://mud.dev/), což je framework, který nám umožňuje ukládat data na blockchainu pomocí [databáze klíč-hodnota](https://aws.amazon.com/nosql/key-value/) a automaticky synchronizovat tato data s offchain komponentami. Kromě synchronizace MUD usnadňuje poskytování řízení přístupu a umožňuje ostatním uživatelům bez oprávnění [rozšířit](https://mud.dev/guides/extending-a-world) naši aplikaci.
+
+### Spuštění příkladu Hledání min {#running-minesweeper-example}
+
+Chcete-li spustit příklad Hledání min:
+
+1. Ujistěte se, že [máte nainstalované všechny předpoklady](https://mud.dev/quickstart#prerequisites): [Node](https://mud.dev/quickstart#prerequisites), [Foundry](https://book.getfoundry.sh/getting-started/installation), [`git`](https://git-scm.com/downloads), [`pnpm`](https://git-scm.com/downloads) a [`mprocs`](https://github.com/pvolok/mprocs).
+
+2. Naklonujte repozitář.
+
+ ```sh copy
+ git clone https://github.com/qbzzt/20240901-secret-state.git
+ ```
+
+3. Nainstalujte balíčky.
+
+ ```sh copy
+ cd 20240901-secret-state/
+ pnpm install
+ npm install -g mprocs
+ ```
+
+ Pokud byl Foundry nainstalován jako součást `pnpm install`, musíte restartovat příkazový řádek.
+
+4. Zkompilujte kontrakty
+
+ ```sh copy
+ cd packages/contracts
+ forge build
+ cd ../..
+ ```
+
+5. Spusťte program (včetně [anvil](https://book.getfoundry.sh/anvil/) blockchainu) a počkejte.
+
+ ```sh copy
+ mprocs
+ ```
+
+ Upozorňujeme, že spuštění trvá dlouho. Chcete-li vidět postup, nejprve pomocí šipky dolů přejděte na záložku _contracts_, abyste viděli, jak se nasazují MUD kontrakty. Když se zobrazí zpráva _Waiting for file changes…_, kontrakty jsou nasazeny a další postup se bude odehrávat na záložce _server_. Tam počkáte, dokud neobdržíte zprávu _Verifier address: 0x...._.
+
+ Pokud je tento krok úspěšný, zobrazí se obrazovka `mprocs` s různými procesy vlevo a výstupem konzole pro aktuálně vybraný proces vpravo.
+
+ 
+
+ Pokud nastane problém s `mprocs`, můžete čtyři procesy spustit ručně, každý v samostatném okně příkazového řádku:
+
+ - **Anvil**
+
+ ```sh
+ cd packages/contracts
+ anvil --base-fee 0 --block-time 2
+ ```
+
+ - **Kontrakty**
+
+ ```sh
+ cd packages/contracts
+ pnpm mud dev-contracts --rpc http://127.0.0.1:8545
+ ```
+
+ - **Server**
+
+ ```sh
+ cd packages/server
+ pnpm start
+ ```
+
+ - **Klient**
+
+ ```sh
+ cd packages/client
+ pnpm run dev
+ ```
+
+6. Nyní můžete přejít na [klienta](http://localhost:3000), kliknout na **New Game** (Nová hra) a začít hrát.
+
+### Tabulky {#tables}
+
+Potřebujeme [několik tabulek](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/mud.config.ts) na blockchainu.
+
+- `Configuration`: Tato tabulka je singleton, nemá žádný klíč a jeden záznam. Slouží k uchovávání informací o konfiguraci hry:
+ - `height`: Výška minového pole
+ - `width`: Šířka minového pole
+ - `numberOfBombs`: Počet bomb v každém minovém poli
+
+- `VerifierAddress`: Tato tabulka je také singleton. Slouží k uchování jedné části konfigurace, adresy verifikačního kontraktu (`verifier`). Tuto informaci jsme mohli umístit do tabulky `Configuration`, ale je nastavována jinou komponentou, serverem, takže je jednodušší ji umístit do samostatné tabulky.
+
+- `PlayerGame`: Klíčem je adresa hráče. Data jsou:
+
+ - `gameId`: 32bajtová hodnota, která je hašem mapy, na které hráč hraje (identifikátor hry).
+ - `win`: booleovská hodnota, která udává, zda hráč hru vyhrál.
+ - `lose`: booleovská hodnota, která udává, zda hráč hru prohrál.
+ - `digNumber`: počet úspěšných odkrytí políček ve hře.
+
+- `GamePlayer`: Tato tabulka obsahuje reverzní mapování z `gameId` na adresu hráče.
+
+- `Map`: Klíč je n-tice tří hodnot:
+
+ - `gameId`: 32bajtová hodnota, která je hašem mapy, na které hráč hraje (identifikátor hry).
+ - `x` souřadnice
+ - `y` souřadnice
+
+ Hodnota je jediné číslo. Je to 255, pokud byla detekována bomba. Jinak je to počet bomb v okolí daného místa plus jedna. Nemůžeme použít jen počet bomb, protože ve výchozím nastavení jsou všechna úložiště v EVM a všechny hodnoty řádků v MUD nulové. Musíme rozlišovat mezi „hráč zde ještě nekopal“ a „hráč zde kopal a zjistil, že v okolí nejsou žádné bomby“.
+
+Kromě toho komunikace mezi klientem a serverem probíhá prostřednictvím onchain komponenty. To je také implementováno pomocí tabulek.
+
+- `PendingGame`: Nevyřízené žádosti o spuštění nové hry.
+- `PendingDig`: Nevyřízené požadavky na kopání na konkrétním místě v konkrétní hře. Toto je [offchain tabulka](https://mud.dev/store/tables#types-of-tables), což znamená, že se nezapisuje do úložiště EVM, je čitelná pouze mimo blockchain pomocí událostí.
+
+### Provádění a datové toky {#execution-data-flows}
+
+Tyto toky koordinují provádění mezi klientem, onchain komponentou a serverem.
+
+#### Inicializace {#initialization-flow}
+
+Když spustíte `mprocs`, dojde k těmto krokům:
+
+1. [`mprocs`](https://github.com/pvolok/mprocs) spouští čtyři komponenty:
+
+ - [Anvil](https://book.getfoundry.sh/anvil/), který spouští místní blockchain
+ - [Contracts](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/contracts), který kompiluje (v případě potřeby) a nasazuje kontrakty pro MUD
+ - [Client](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/client), který spouští [Vite](https://vitejs.dev/) k poskytování uživatelského rozhraní a klientského kódu webovým prohlížečům.
+ - [Server](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/server), který provádí akce serveru
+
+2. Balíček `contracts` nasadí kontrakty MUD a poté spustí [skript `PostDeploy.s.sol`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/script/PostDeploy.s.sol). Tento skript nastaví konfiguraci. Kód z GitHubu specifikuje [minové pole 10x5 s osmi minami](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/script/PostDeploy.s.sol#L23).
+
+3. [Server](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts) se spouští [nastavením MUD](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L6). Mimo jiné se tím aktivuje synchronizace dat, takže kopie příslušných tabulek existuje v paměti serveru.
+
+4. Server zaregistruje funkci k provedení [při změně tabulky `Configuration`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L23). [Tato funkce](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L24-L168) se volá po spuštění `PostDeploy.s.sol` a úpravě tabulky.
+
+5. Když má inicializační funkce serveru konfiguraci, [volá `zkFunctions`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L34-L35) pro inicializaci [části serveru s nulovou znalostí](#using-zokrates-from-typescript). To se nemůže stát, dokud nezískáme konfiguraci, protože funkce s nulovou znalostí musí mít šířku a výšku minového pole jako konstanty.
+
+6. Po inicializaci části serveru s nulovou znalostí je dalším krokem [nasazení verifikačního kontraktu s nulovou znalostí na blockchain](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L42-L53) a nastavení adresy ověřovatele v MUD.
+
+7. Nakonec se přihlásíme k odběru aktualizací, abychom viděli, když hráč požádá buď [o spuštění nové hry](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L55-L71), nebo [o odkrytí pole v existující hře](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L73-L108).
+
+#### Nová hra {#new-game-flow}
+
+Toto se stane, když hráč požádá o novou hru.
+
+1. Pokud pro tohoto hráče neprobíhá žádná hra nebo probíhá, ale s nulovým gameId, klient zobrazí [tlačítko nové hry](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175). Když uživatel stiskne toto tlačítko, [React spustí funkci `newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L96).
+
+2. [`newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/mud/createSystemCalls.ts#L43-L46) je volání `System`. V MUD jsou všechna volání směrována přes kontrakt `World` a ve většině případů voláte `__`. V tomto případě se volá `app__newGame`, které MUD následně přesměruje na [`newGame` v `GameSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L16-L22).
+
+3. Onchain funkce zkontroluje, že hráč nemá žádnou rozehranou hru, a pokud ne, [přidá požadavek do tabulky `PendingGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L21).
+
+4. Server detekuje změnu v `PendingGame` a [spustí registrovanou funkci](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L55-L71). Tato funkce volá [`newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L110-L114), která zase volá [`createGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L116-L144).
+
+5. První věc, kterou `createGame` udělá, je [vytvoření náhodné mapy s příslušným počtem min](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L120-L135). Poté volá [`makeMapBorders`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L147-L166), aby vytvořil mapu s prázdnými okraji, což je nutné pro Zokrates. Nakonec `createGame` volá [`calculateMapHash`](#calculateMapHash), aby získal haš mapy, který se používá jako ID hry.
+
+6. Funkce `newGame` přidá novou hru do `gamesInProgress`.
+
+7. Poslední věc, kterou server udělá, je zavolání [`app__newGameResponse`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L38-L43), které je na blockchainu. Tato funkce se nachází v jiném `System`, [`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol), aby umožnila řízení přístupu. Řízení přístupu je definováno v [konfiguračním souboru MUD](https://mud.dev/config), [`mud.config.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/mud.config.ts#L67-L72).
+
+ Seznam přístupů umožňuje volat `System` pouze jediné adrese. To omezuje přístup k funkcím serveru na jedinou adresu, takže se nikdo nemůže vydávat za server.
+
+8. Onchain komponenta aktualizuje příslušné tabulky:
+
+ - Vytvoří hru v `PlayerGame`.
+ - Nastaví reverzní mapování v `GamePlayer`.
+ - Odebere požadavek z `PendingGame`.
+
+9. Server identifikuje změnu v `PendingGame`, ale nic nedělá, protože [`wantsGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L58-L60) je nepravdivé.
+
+10. Na klientu je [`gameRecord`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L143-L148) nastaven na položku `PlayerGame` pro adresu hráče. Když se změní `PlayerGame`, změní se i `gameRecord`.
+
+11. Pokud je v `gameRecord` hodnota a hra ještě nebyla vyhrána ani prohrána, klient [zobrazí mapu](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175-L190).
+
+#### Odkrytí pole {#dig-flow}
+
+1. Hráč [klikne na tlačítko buňky mapy](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L188), což zavolá [funkci `dig`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/mud/createSystemCalls.ts#L33-L36). Tato funkce volá [`dig` na blockchainu](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L24-L32).
+
+2. Onchain komponenta [provádí řadu kontrol správnosti](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L25-L30) a pokud je úspěšná, přidá požadavek na odkrytí pole do [`PendingDig`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L31).
+
+3. Server [detekuje změnu v `PendingDig`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L73). [Pokud je platný](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L75-L84), [zavolá kód s nulovou znalostí](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L86-L95) (vysvětleno níže), aby vygeneroval jak výsledek, tak důkaz, že je platný.
+
+4. [Server](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L97-L107) volá [`digResponse`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L45-L64) na blockchainu.
+
+5. `digResponse` dělá dvě věci. Nejprve zkontroluje [důkaz s nulovou znalostí](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L47-L61). Poté, pokud je důkaz v pořádku, volá [`processDigResult`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L67-L86) pro skutečné zpracování výsledku.
+
+6. `processDigResult` zkontroluje, zda byla hra [prohrána](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L76-L78) nebo [vyhrána](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L83-L86), a [aktualizuje `Map`, onchain mapu](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L80).
+
+7. Klient automaticky zachytí aktualizace a [aktualizuje mapu zobrazenou hráči](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175-L190) a případně hráči sdělí, zda se jedná o výhru, nebo prohru.
+
+## Použití Zokrates {#using-zokrates}
+
+Ve výše vysvětlených tocích jsme přeskočili části s nulovou znalostí a považovali je za černou skříňku. Teď ji otevřeme a podíváme se, jak je ten kód napsán.
+
+### Hašování mapy {#hashing-map}
+
+Můžeme použít [tento kód v JavaScriptu](https://github.com/ZK-Plus/ICBC24_Tutorial_Compute-Offchain-Verify-onchain/tree/solutions/exercise) k implementaci [Poseidon](https://www.poseidon-hash.info), hašovací funkce Zokrates, kterou používáme. Ačkoli by to však bylo rychlejší, bylo by to také složitější, než jen použít k tomu hašovací funkci Zokrates. Toto je tutoriál, takže kód je optimalizován pro jednoduchost, nikoli pro výkon. Proto potřebujeme dva různé programy Zokrates, jeden pro výpočet haše mapy (`hash`) a druhý pro vytvoření důkazu s nulovou znalostí o výsledku odkrytí pole na mapě (`dig`).
+
+### Hašovací funkce {#hash-function}
+
+Toto je funkce, která počítá haš mapy. Tento kód si projdeme řádek po řádku.
+
+```
+import "hashes/poseidon/poseidon.zok" as poseidon;
+import "utils/pack/bool/pack128.zok" as pack128;
+```
+
+Tyto dva řádky importují dvě funkce ze [standardní knihovny Zokrates](https://zokrates.github.io/toolbox/stdlib.html). [První funkce](https://github.com/Zokrates/ZoKrates/blob/latest/zokrates_stdlib/stdlib/hashes/poseidon/poseidon.zok) je [haš Poseidon](https://www.poseidon-hash.info/). Přijímá pole prvků [`field`](https://zokrates.github.io/language/types.html#field) a vrací `field`.
+
+Prvek pole (field) v Zokrates je obvykle kratší než 256 bitů, ale ne o moc. Pro zjednodušení kódu omezujeme mapu na maximálně 512 bitů a hašujeme pole čtyř polí a v každém poli používáme pouze 128 bitů. [Funkce `pack128`](https://github.com/Zokrates/ZoKrates/blob/latest/zokrates_stdlib/stdlib/utils/pack/bool/pack128.zok) pro tento účel změní pole 128 bitů na `field`.
+
+```
+ def hashMap(bool[${width+2}][${height+2}] map) -> field {
+```
+
+Tento řádek zahajuje definici funkce. `hashMap` dostane jediný parametr nazvaný `map`, dvourozměrné pole typu `bool`(ean). Velikost mapy je `width+2` krát `height+2` z důvodů, které jsou [vysvětleny níže](#why-map-border).
+
+Můžeme použít `${width+2}` a `${height+2}`, protože programy Zokrates jsou v této aplikaci uloženy jako [šablonové řetězce](https://www.w3schools.com/js/js_string_templates.asp). Kód mezi `${` a `}` je vyhodnocen JavaScriptem, a tímto způsobem lze program použít pro různé velikosti mapy. Parametr mapy má kolem sebe okraj o šířce jedné pozice bez bomb, což je důvod, proč musíme k šířce a výšce přidat dva.
+
+Návratová hodnota je `field`, který obsahuje haš.
+
+```
+ bool[512] mut map1d = [false; 512];
+```
+
+Mapa je dvourozměrná. Funkce `pack128` však nefunguje s dvourozměrnými poli. Takže nejprve zploštíme mapu do 512bajtového pole pomocí `map1d`. Ve výchozím nastavení jsou proměnné Zokrates konstanty, ale potřebujeme přiřadit hodnoty tomuto poli ve smyčce, takže ho definujeme jako [`mut`](https://zokrates.github.io/language/variables.html#mutability).
+
+Musíme pole inicializovat, protože Zokrates nemá `undefined`. Výraz `[false; 512]` znamená [pole 512 hodnot `false`](https://zokrates.github.io/language/types.html#declaration-and-initialization).
+
+```
+ u32 mut counter = 0;
+```
+
+Potřebujeme také počítadlo k rozlišení mezi bity, které jsme již v `map1d` vyplnili, a těmi, které ještě ne.
+
+```
+ for u32 x in 0..${width+2} {
+```
+
+Takto se v Zokrates deklaruje [smyčka `for`](https://zokrates.github.io/language/control_flow.html#for-loops). Smyčka `for` v Zokrates musí mít pevné meze, protože i když se jeví jako smyčka, kompilátor ji ve skutečnosti „rozbalí“. Výraz `${width+2}` je konstanta v době kompilace, protože `width` je nastaven kódem TypeScript předtím, než zavolá kompilátor.
+
+```
+ for u32 y in 0..${height+2} {
+ map1d[counter] = map[x][y];
+ counter = counter+1;
+ }
+ }
+```
+
+Pro každé místo na mapě vložte tuto hodnotu do pole `map1d` a zvyšte počítadlo.
+
+```
+ field[4] hashMe = [
+ pack128(map1d[0..128]),
+ pack128(map1d[128..256]),
+ pack128(map1d[256..384]),
+ pack128(map1d[384..512])
+ ];
+```
+
+`pack128` vytvoří z `map1d` pole čtyř hodnot typu `field`. V Zokrates znamená `array[a..b]` výsek pole, který začíná na `a` a končí na `b-1`.
+
+```
+ return poseidon(hashMe);
+}
+```
+
+Použijte `poseidon` k převedení tohoto pole na haš.
+
+### Hašovací program {#hash-program}
+
+Server musí volat `hashMap` přímo k vytvoření identifikátorů hry. Zokrates však může pro spuštění volat pouze funkci `main` v programu, takže vytvoříme program s `main`, který volá hašovací funkci.
+
+```
+${hashFragment}
+
+def main(bool[${width+2}][${height+2}] map) -> field {
+ return hashMap(map);
+}
+```
+
+### Program pro odkrytí pole {#dig-program}
+
+Toto je srdce části aplikace s nulovou znalostí, kde vytváříme důkazy, které se používají k ověření výsledků odkrytí polí.
+
+```
+${hashFragment}
+
+// Počet min na pozici (x,y)
+def map2mineCount(bool[${width+2}][${height+2}] map, u32 x, u32 y) -> u8 {
+ return if map[x+1][y+1] { 1 } else { 0 };
+}
+```
+
+#### Proč okraj mapy {#why-map-border}
+
+Důkazy s nulovou znalostí používají [aritmetické obvody](https://medium.com/web3studio/simple-explanations-of-arithmetic-circuits-and-zero-knowledge-proofs-806e59a79785), které nemají jednoduchý ekvivalent příkazu `if`. Místo toho používají ekvivalent [podmíněného operátoru](https://en.wikipedia.org/wiki/Ternary_conditional_operator). Pokud `a` může být buď nula, nebo jedna, můžete vypočítat `if a { b } else { c }` jako `ab+(1-a)c`.
+
+Z tohoto důvodu příkaz `if` v Zokrates vždy vyhodnocuje obě větve. Například, pokud máte tento kód:
+
+```
+bool[5] arr = [false; 5];
+u32 index=10;
+return if index>4 { 0 } else { arr[index] }
+```
+
+Dojde k chybě, protože potřebuje vypočítat `arr[10]`, i když tato hodnota bude později vynásobena nulou.
+
+To je důvod, proč potřebujeme okraj o šířce jednoho pole kolem celé mapy. Potřebujeme vypočítat celkový počet min v okolí pole, a to znamená, že musíme vidět pole o jeden řádek nad a pod, vlevo a vpravo od pole, které odkrýváme. Což znamená, že tato pole musí existovat v poli mapy, které je Zokrates poskytnuto.
+
+```
+def main(private bool[${width+2}][${height+2}] map, u32 x, u32 y) -> (field, u8) {
+```
+
+Ve výchozím nastavení důkazy Zokrates obsahují své vstupy. Není k ničemu vědět, že kolem pole je pět min, pokud nevíte, o které pole se jedná (a nemůžete to jen porovnat s vaším požadavkem, protože pak by mohl dokazovatel použít jiné hodnoty a neříct vám o tom). Musíme však udržet mapu v tajnosti a zároveň ji poskytnout Zokrates. Řešením je použít `private` parametr, který _není_ odhalen důkazem.
+
+To otevírá další možnost zneužití. Dokazovatel by mohl použít správné souřadnice, ale vytvořit mapu s libovolným počtem min kolem daného pole, a možná i na samotném poli. Abychom zabránili tomuto zneužití, zajistíme, aby důkaz s nulovou znalostí obsahoval haš mapy, který je identifikátorem hry.
+
+```
+ return (hashMap(map),
+```
+
+Návratová hodnota je zde n-tice, která obsahuje pole hašů mapy a výsledek odkrytí pole.
+
+```
+ if map2mineCount(map, x, y) > 0 { 0xFF } else {
+```
+
+Používáme 255 jako speciální hodnotu pro případ, že na samotném poli je bomba.
+
+```
+ map2mineCount(map, x-1, y-1) + map2mineCount(map, x, y-1) + map2mineCount(map, x+1, y-1) +
+ map2mineCount(map, x-1, y) + map2mineCount(map, x+1, y) +
+ map2mineCount(map, x-1, y+1) + map2mineCount(map, x, y+1) + map2mineCount(map, x+1, y+1)
+ }
+ );
+}
+```
+
+Pokud hráč nenašel minu, sečtěte počty min v okolí pole a vraťte je.
+
+### Použití Zokrates z TypeScriptu {#using-zokrates-from-typescript}
+
+Zokrates má rozhraní příkazového řádku, ale v tomto programu ho používáme v [kódu TypeScript](https://zokrates.github.io/toolbox/zokrates_js.html).
+
+Knihovna, která obsahuje definice Zokrates, se jmenuje [`zero-knowledge.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts).
+
+```typescript
+import { initialize as zokratesInitialize } from "zokrates-js"
+```
+
+Importujte [JavaScriptové vazby Zokrates](https://zokrates.github.io/toolbox/zokrates_js.html). Potřebujeme pouze funkci [`initialize`](https://zokrates.github.io/toolbox/zokrates_js.html#initialize), protože vrací promise, který se vyřeší na všechny definice Zokrates.
+
+```typescript
+export const zkFunctions = async (width: number, height: number) : Promise => {
+```
+
+Podobně jako u samotného Zokrates, exportujeme také pouze jednu funkci, která je také [asynchronní](https://www.w3schools.com/js/js_async.asp). Když se nakonec vrátí, poskytne několik funkcí, jak uvidíme níže.
+
+```typescript
+const zokrates = await zokratesInitialize()
+```
+
+Inicializujte Zokrates, získejte vše, co potřebujeme z knihovny.
+
+```typescript
+const hashFragment = `
+ import "utils/pack/bool/pack128.zok" as pack128;
+ import "hashes/poseidon/poseidon.zok" as poseidon;
+ .
+ .
+ .
+ }
+ `
+
+const hashProgram = `
+ ${hashFragment}
+ .
+ .
+ .
+ `
+
+const digProgram = `
+ ${hashFragment}
+ .
+ .
+ .
+ `
+```
+
+Dále máme hašovací funkci a dva programy Zokrates, které jsme viděli výše.
+
+```typescript
+const digCompiled = zokrates.compile(digProgram)
+const hashCompiled = zokrates.compile(hashProgram)
+```
+
+Zde tyto programy kompilujeme.
+
+```typescript
+// Vytvoří klíče pro ověření nulové znalosti.
+// V produkčním systému byste chtěli použít setup ceremonii.
+// (https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony).
+const keySetupResults = zokrates.setup(digCompiled.program, "")
+const verifierKey = keySetupResults.vk
+const proverKey = keySetupResults.pk
+```
+
+V produkčním systému bychom mohli použít složitější [setup ceremonii](https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony), ale toto je pro demonstraci dostačující. Není problém, že uživatelé mohou znát klíč dokazovatele – stále ho nemohou použít k prokázání věcí, pokud nejsou pravdivé. Protože specifikujeme entropii (druhý parametr, `""`), výsledky budou vždy stejné.
+
+**Poznámka:** Kompilace programů Zokrates a tvorba klíčů jsou pomalé procesy. Není třeba je opakovat pokaždé, pouze když se změní velikost mapy. V produkčním systému byste je provedli jednou a pak uložili výstup. Jediný důvod, proč to zde nedělám, je pro jednoduchost.
+
+#### `calculateMapHash` {#calculateMapHash}
+
+```typescript
+const calculateMapHash = function (hashMe: boolean[][]): string {
+ return (
+ "0x" +
+ BigInt(zokrates.computeWitness(hashCompiled, [hashMe]).output.slice(1, -1))
+ .toString(16)
+ .padStart(64, "0")
+ )
+}
+```
+
+Funkce [`computeWitness`](https://zokrates.github.io/toolbox/zokrates_js.html#computewitnessartifacts-args-options) skutečně spouští program Zokrates. Vrací strukturu se dvěma poli: `output`, což je výstup programu jako řetězec JSON, a `witness`, což je informace potřebná k vytvoření důkazu s nulovou znalostí výsledku. Zde potřebujeme pouze výstup.
+
+Výstupem je řetězec ve formátu `"31337"`, desetinné číslo uzavřené v uvozovkách. Ale výstup, který potřebujeme pro `viem`, je hexadecimální číslo ve formátu `0x60A7`. Takže použijeme `.slice(1,-1)` k odstranění uvozovek a poté `BigInt` k převedení zbývajícího řetězce, což je desetinné číslo, na [`BigInt`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt). `.toString(16)` převede tento `BigInt` na hexadecimální řetězec a `"0x"+` přidá značku pro hexadecimální čísla.
+
+```typescript
+// Odkryjte pole a vraťte důkaz s nulovou znalostí o výsledku
+// (kód na straně serveru)
+```
+
+Důkaz s nulovou znalostí zahrnuje veřejné vstupy (`x` a `y`) a výsledky (haš mapy a počet bomb).
+
+```typescript
+ const zkDig = function(map: boolean[][], x: number, y: number) : any {
+ if (x<0 || x>=width || y<0 || y>=height)
+ throw new Error("Pokus o odkrytí pole mimo mapu")
+```
+
+Je problém kontrolovat, zda je index mimo rozsah v Zokrates, takže to děláme zde.
+
+```typescript
+const runResults = zokrates.computeWitness(digCompiled, [map, `${x}`, `${y}`])
+```
+
+Spusťte program pro odkrytí pole.
+
+```typescript
+ const proof = zokrates.generateProof(
+ digCompiled.program,
+ runResults.witness,
+ proverKey)
+
+ return proof
+ }
+```
+
+Použijte [`generateProof`](https://zokrates.github.io/toolbox/zokrates_js.html#generateproofprogram-witness-provingkey-entropy) a vraťte důkaz.
+
+```typescript
+const solidityVerifier = `
+ // Velikost mapy: ${width} x ${height}
+ \n${zokrates.exportSolidityVerifier(verifierKey)}
+ `
+```
+
+Ověřovatel Solidity, chytrý kontrakt, který můžeme nasadit na blockchain a použít k ověření důkazů generovaných `digCompiled.program`.
+
+```typescript
+ return {
+ zkDig,
+ calculateMapHash,
+ solidityVerifier,
+ }
+}
+```
+
+Nakonec vraťte vše, co by mohl jiný kód potřebovat.
+
+## Bezpečnostní testy {#security-tests}
+
+Bezpečnostní testy jsou důležité, protože chyba funkčnosti se nakonec projeví. Ale pokud je aplikace nezabezpečená, pravděpodobně to zůstane skryto po dlouhou dobu, než to odhalí někdo, kdo podvádí a získá zdroje, které patří ostatním.
+
+### Oprávnění {#permissions}
+
+V této hře je jedna privilegovaná entita, server. Je to jediný uživatel, který smí volat funkce v [`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol). Můžeme použít [`cast`](https://book.getfoundry.sh/cast/) k ověření, že volání funkcí s oprávněním jsou povolena pouze jako účet serveru.
+
+[Soukromý klíč serveru je v `setupNetwork.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/mud/setupNetwork.ts#L52).
+
+1. Na počítači, který spouští `anvil` (blockchain), nastavte tyto proměnné prostředí.
+
+ ```sh copy
+ WORLD_ADDRESS=0x8d8b6b8414e1e3dcfd4168561b9be6bd3bf6ec4b
+ UNAUTHORIZED_KEY=0x5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a
+ AUTHORIZED_KEY=0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d
+ ```
+
+2. Použijte `cast` k pokusu o nastavení adresy ověřovatele jako neoprávněné adresy.
+
+ ```sh copy
+ cast send $WORLD_ADDRESS 'app__setVerifier(address)' `cast address-zero` --private-key $UNAUTHORIZED_KEY
+ ```
+
+ Nejenže `cast` hlásí selhání, ale můžete otevřít **MUD Dev Tools** ve hře v prohlížeči, kliknout na **Tables** a vybrat **app\_\_VerifierAddress**. Podívejte se, že adresa není nulová.
+
+3. Nastavte adresu ověřovatele jako adresu serveru.
+
+ ```sh copy
+ cast send $WORLD_ADDRESS 'app__setVerifier(address)' `cast address-zero` --private-key $AUTHORIZED_KEY
+ ```
+
+ Adresa v **app\_\_VerifiedAddress** by nyní měla být nulová.
+
+Všechny funkce MUD ve stejném `System` procházejí stejným řízením přístupu, takže tento test považuji za dostatečný. Pokud ne, můžete zkontrolovat ostatní funkce v [`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol).
+
+### Zneužití nulové znalosti {#zero-knowledge-abuses}
+
+Matematika k ověření Zokrates je nad rámec tohoto tutoriálu (a mých schopností). Můžeme však spustit různé kontroly na kódu s nulovou znalostí, abychom ověřili, že pokud není proveden správně, selže. Všechny tyto testy budou vyžadovat, abychom změnili [`zero-knowledge.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts) a restartovali celou aplikaci. Nestačí restartovat proces serveru, protože to uvede aplikaci do nemožného stavu (hráč má rozehranou hru, ale hra již není pro server dostupná).
+
+#### Špatná odpověď {#wrong-answer}
+
+Nejjednodušší možností je poskytnout špatnou odpověď v důkazu s nulovou znalostí. Chcete-li to provést, přejděte do `zkDig` a [upravte řádek 91](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L91):
+
+```ts
+proof.inputs[3] = "0x" + "1".padStart(64, "0")
+```
+
+To znamená, že budeme vždy tvrdit, že je tam jedna bomba, bez ohledu na správnou odpověď. Zkuste si zahrát s touto verzí a na kartě **server** na obrazovce `pnpm dev` uvidíte tuto chybu:
+
+```
+ cause: {
+ code: 3,
+ message: 'execution reverted: revert: Zero knowledge verification fail',
+ data: '0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000
+000000000000000000000000000000000000000000000000205a65726f206b6e6f776c6564676520766572696669636174696f6
+e206661696c'
+ },
+```
+
+Takže tento druh podvodu selže.
+
+#### Špatný důkaz {#wrong-proof}
+
+Co se stane, když poskytneme správné informace, ale máme jen špatná data důkazu? Nyní nahraďte řádek 91:
+
+```ts
+proof.proof = {
+ a: ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")],
+ b: [
+ ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")],
+ ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")],
+ ],
+ c: ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")],
+}
+```
+
+Stále selhává, ale nyní selhává bez udání důvodu, protože k tomu dochází během volání ověřovatele.
+
+### Jak může uživatel ověřit kód s nulovou znalostí? {#user-verify-zero-trust}
+
+Chytré kontrakty je poměrně snadné ověřit. Vývojář obvykle zveřejní zdrojový kód v průzkumníku bloků a průzkumník bloků ověří, že se zdrojový kód zkompiluje do kódu v [transakci nasazení kontraktu](/developers/docs/smart-contracts/deploying/). V případě MUD `System`s je to [trochu složitější](https://mud.dev/cli/verify), ale ne o moc.
+
+S nulovou znalostí je to těžší. Ověřovatel obsahuje některé konstanty a provádí s nimi některé výpočty. To vám neřekne, co se dokazuje.
+
+```solidity
+ function verifyingKey() pure internal returns (VerifyingKey memory vk) {
+ vk.alpha = Pairing.G1Point(uint256(0x0f43f4fe7b5c2326fed4ac6ed2f4003ab9ab4ea6f667c2bdd77afb068617ee16), uint256(0x25a77832283f9726935219b5f4678842cda465631e72dbb24708a97ba5d0ce6f));
+ vk.beta = Pairing.G2Point([uint256(0x2cebd0fbd21aca01910581537b21ae4fed46bc0e524c055059aa164ba0a6b62b), uint256(0x18fd4a7bc386cf03a95af7163d5359165acc4e7961cb46519e6d9ee4a1e2b7e9)], [uint256(0x11449dee0199ef6d8eebfe43b548e875c69e7ce37705ee9a00c81fe52f11a009), uint256(0x066d0c83b32800d3f335bb9e8ed5e2924cf00e77e6ec28178592eac9898e1a00)]);
+```
+
+Řešením, alespoň do doby, než průzkumníci bloků přidají ověřování Zokrates do svých uživatelských rozhraní, je, aby vývojáři aplikací zpřístupnili programy Zokrates a aby si alespoň někteří uživatelé sami zkompilovali s příslušným ověřovacím klíčem.
+
+Postupujte takto:
+
+1. [Nainstalujte Zokrates](https://zokrates.github.io/gettingstarted.html).
+
+2. Vytvořte soubor `dig.zok` s programem Zokrates. Níže uvedený kód předpokládá, že jste ponechali původní velikost mapy, 10x5.
+
+ ```zokrates
+ import "utils/pack/bool/pack128.zok" as pack128;
+ import "hashes/poseidon/poseidon.zok" as poseidon;
+
+ def hashMap(bool[12][7] map) -> field {
+ bool[512] mut map1d = [false; 512];
+ u32 mut counter = 0;
+
+ for u32 x in 0..12 {
+ for u32 y in 0..7 {
+ map1d[counter] = map[x][y];
+ counter = counter+1;
+ }
+ }
+
+ field[4] hashMe = [
+ pack128(map1d[0..128]),
+ pack128(map1d[128..256]),
+ pack128(map1d[256..384]),
+ pack128(map1d[384..512])
+ ];
+
+ return poseidon(hashMe);
+ }
+
+
+ // Počet min na pozici (x,y)
+ def map2mineCount(bool[12][7] map, u32 x, u32 y) -> u8 {
+ return if map[x+1][y+1] { 1 } else { 0 };
+ }
+
+ def main(private bool[12][7] map, u32 x, u32 y) -> (field, u8) {
+ return (hashMap(map) ,
+ if map2mineCount(map, x, y) > 0 { 0xFF } else {
+ map2mineCount(map, x-1, y-1) + map2mineCount(map, x, y-1) + map2mineCount(map, x+1, y-1) +
+ map2mineCount(map, x-1, y) + map2mineCount(map, x+1, y) +
+ map2mineCount(map, x-1, y+1) + map2mineCount(map, x, y+1) + map2mineCount(map, x+1, y+1)
+ }
+ );
+ }
+ ```
+
+3. Zkompilujte kód Zokrates a vytvořte ověřovací klíč. Ověřovací klíč musí být vytvořen se stejnou entropií, jaká byla použita v původním serveru, [v tomto případě prázdný řetězec](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L67).
+
+ ```sh copy
+ zokrates compile --input dig.zok
+ zokrates setup -e ""
+ ```
+
+4. Vytvořte si vlastní ověřovač Solidity a ověřte, že je funkčně shodný s tím na blockchainu (server přidává komentář, ale to není důležité).
+
+ ```sh copy
+ zokrates export-verifier
+ diff verifier.sol ~/20240901-secret-state/packages/contracts/src/verifier.sol
+ ```
+
+## Rozhodnutí o návrhu {#design}
+
+V každé dostatečně složité aplikaci existují konkurenční cíle návrhu, které vyžadují kompromisy. Podívejme se na některé kompromisy a proč je současné řešení vhodnější než jiné možnosti.
+
+### Proč nulová znalost {#why-zero-knowledge}
+
+Pro Hledání min ve skutečnosti nepotřebujete nulovou znalost. Server může vždy držet mapu a pak ji jednoduše odhalit, když hra skončí. Poté na konci hry může chytrý kontrakt vypočítat haš mapy, ověřit, že se shoduje, a pokud ne, penalizovat server nebo hru zcela ignorovat.
+
+Nepoužil jsem toto jednodušší řešení, protože funguje pouze pro krátké hry s dobře definovaným koncovým stavem. Když je hra potenciálně nekonečná (jako v případě [autonomních světů](https://0xparc.org/blog/autonomous-worlds)), potřebujete řešení, které prokáže stav, _aniž_ by ho odhalilo.
+
+Jako tutoriál tento článek potřeboval krátkou hru, která je snadno pochopitelná, ale tato technika je nejužitečnější pro delší hry.
+
+### Proč Zokrates? {#why-zokrates}
+
+[Zokrates](https://zokrates.github.io/) není jedinou dostupnou knihovnou s nulovou znalostí, ale je podobný normálnímu, [imperativnímu](https://en.wikipedia.org/wiki/Imperative_programming) programovacímu jazyku a podporuje booleovské proměnné.
+
+Pro vaši aplikaci s odlišnými požadavky můžete raději použít [Circum](https://docs.circom.io/getting-started/installation/) nebo [Cairo](https://www.cairo-lang.org/tutorials/getting-started-with-cairo/).
+
+### Kdy kompilovat Zokrates {#when-compile-zokrates}
+
+V tomto programu kompilujeme programy Zokrates [pokaždé, když se server spustí](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L60-L61). Je to zjevné plýtvání zdroji, ale toto je tutoriál optimalizovaný pro jednoduchost.
+
+Kdybych psal aplikaci na produkční úrovni, zkontroloval bych, zda mám soubor s kompilovanými programy Zokrates pro tuto velikost minového pole, a pokud ano, použil bych ho. Totéž platí pro nasazení ověřovacího kontraktu na blockchainu.
+
+### Vytvoření klíčů ověřovatele a dokazovatele {#key-creation}
+
+[Vytváření klíčů](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L63-L69) je další čistý výpočet, který není nutné provádět více než jednou pro danou velikost minového pole. Opět se to dělá pouze jednou pro zjednodušení.
+
+Kromě toho bychom mohli použít [setup ceremonii](https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony). Výhodou setup ceremonie je, že k podvádění důkazu s nulovou znalostí potřebujete buď entropii, nebo nějaký mezivýsledek od každého účastníka. Pokud je alespoň jeden účastník ceremonie poctivý a smaže tyto informace, jsou důkazy s nulovou znalostí v bezpečí před určitými útoky. Neexistuje však _žádný mechanismus_, který by ověřil, že informace byly smazány všude. Pokud jsou důkazy s nulovou znalostí kriticky důležité, chcete se zúčastnit setup ceremonie.
+
+Zde se spoléháme na [perpetual powers of tau](https://github.com/privacy-scaling-explorations/perpetualpowersoftau), kterých se zúčastnily desítky účastníků. Je to pravděpodobně dostatečně bezpečné a mnohem jednodušší. Během vytváření klíčů také nepřidáváme entropii, což uživatelům usnadňuje [ověření konfigurace s nulovou znalostí](#user-verify-zero-trust).
+
+### Kde ověřovat {#where-verification}
+
+Důkazy s nulovou znalostí můžeme ověřit buď na blockchainu (což stojí gas), nebo v klientovi (pomocí [`verify`](https://zokrates.github.io/toolbox/zokrates_js.html#verifyverificationkey-proof)). Zvolil jsem první možnost, protože to umožňuje [ověřit ověřovatele](#user-verify-zero-trust) jednou a pak důvěřovat, že se nezmění, dokud adresa kontraktu zůstane stejná. Pokud by se ověření provádělo na klientovi, museli byste ověřit kód, který obdržíte při každém stažení klienta.
+
+Ačkoli je tato hra pro jednoho hráče, mnoho blockchainových her je pro více hráčů. Onchain ověření znamená, že důkaz s nulovou znalostí ověříte pouze jednou. Provedení v klientovi by vyžadovalo, aby každý klient ověřoval nezávisle.
+
+### Zploštit mapu v TypeScriptu nebo Zokrates? {#where-flatten}
+
+Obecně platí, že když lze zpracování provést buď v TypeScriptu, nebo v Zokrates, je lepší to udělat v TypeScriptu, který je mnohem rychlejší a nevyžaduje důkazy s nulovou znalostí. To je například důvod, proč neposkytujeme Zokrates haš a nenutíme ho ověřovat, že je správný. Hašování musí být provedeno uvnitř Zokrates, ale shoda mezi vráceným hašem a hašem na blockchainu může proběhnout mimo něj.
+
+Přesto stále [zplošťujeme mapu v Zokrates](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L15-L20), i když jsme to mohli udělat v TypeScriptu. Důvodem je, že ostatní možnosti jsou podle mého názoru horší.
+
+- Poskytněte jednorozměrné pole booleovských hodnot kódu Zokrates a použijte výraz jako `x*(height+2)
+ +y` k získání dvourozměrné mapy. To by [kód](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L44-L47) poněkud zkomplikovalo, takže jsem se rozhodl, že zvýšení výkonu za to pro tutoriál nestojí.
+
+- Pošlete Zokrates jak jednorozměrné pole, tak dvourozměrné pole. Toto řešení nám však nic nepřináší. Kód Zokrates by musel ověřit, že poskytnuté jednorozměrné pole je skutečně správnou reprezentací dvourozměrného pole. Takže by nedošlo k žádnému zvýšení výkonu.
+
+- Zploštit dvourozměrné pole v Zokrates. Toto je nejjednodušší možnost, takže jsem si ji vybral.
+
+### Kde ukládat mapy {#where-store-maps}
+
+V této aplikaci je [`gamesInProgress`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L20) jednoduše proměnná v paměti. To znamená, že pokud váš server selže a je třeba ho restartovat, všechny uložené informace jsou ztraceny. Nejenže hráči nemohou pokračovat ve hře, nemohou ani začít novou hru, protože onchain komponenta si myslí, že stále mají rozehranou hru.
+
+Toto je zjevně špatný návrh pro produkční systém, ve kterém byste tyto informace ukládali do databáze. Jediný důvod, proč jsem zde použil proměnnou, je, že se jedná o tutoriál a hlavní úvahou je jednoduchost.
+
+## Závěr: Za jakých podmínek je toto vhodná technika? {#conclusion}
+
+Takže teď víte, jak napsat hru se serverem, který ukládá tajný stav, který nepatří na blockchain. Ale v jakých případech byste to měli dělat? Jsou zde dvě hlavní úvahy.
+
+- _Dlouhotrvající hra_: [Jak bylo zmíněno výše](#why-zero-knowledge), v krátké hře můžete jednoduše zveřejnit stav, jakmile hra skončí, a nechat vše ověřit. To ale není možnost, když hra trvá dlouhou nebo neurčitou dobu a stav musí zůstat tajný.
+
+- _Určitá centralizace je přijatelná_: Důkazy s nulovou znalostí mohou ověřit integritu, že entita nefalšuje výsledky. Co nemohou udělat, je zajistit, že entita bude stále dostupná a bude odpovídat na zprávy. V situacích, kdy musí být dostupnost také decentralizovaná, nejsou důkazy s nulovou znalostí dostatečným řešením a potřebujete [výpočet více stran](https://en.wikipedia.org/wiki/Secure_multi-party_computation).
+
+[Více z mé práce najdete zde](https://cryptodocguy.pro/).
+
+### Poděkování {#acknowledgements}
+
+- Alvaro Alonso si přečetl návrh tohoto článku a vyjasnil některé mé nejasnosti ohledně Zokrates.
+
+Za zbývající chyby jsem zodpovědný já.
diff --git a/public/content/translations/cs/developers/tutorials/secure-development-workflow/index.md b/public/content/translations/cs/developers/tutorials/secure-development-workflow/index.md
new file mode 100644
index 00000000000..fbb6576fab0
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/secure-development-workflow/index.md
@@ -0,0 +1,52 @@
+---
+title: Kontrolní seznam zabezpečení chytrých kontraktů
+description: Doporučený pracovní postup pro psaní bezpečných chytrých kontraktů
+author: "Trailofbits"
+tags: [ "chytré kontrakty", "bezpečnost", "solidity" ]
+skill: intermediate
+lang: cs
+published: 2020-09-07
+source: Tvorba bezpečných kontraktů
+sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/workflow.md
+---
+
+## Kontrolní seznam pro vývoj chytrých kontraktů {#smart-contract-development-checklist}
+
+Zde je obecný postup, který doporučujeme dodržovat při psaní vašich chytrých kontraktů.
+
+Zkontrolujte, zda se nevyskytují známé bezpečnostní problémy:
+
+- Zkontrolujte své kontrakty pomocí nástroje [Slither](https://github.com/crytic/slither). Obsahuje více než 40 vestavěných detektorů pro běžné zranitelnosti. Spouštějte jej při každém odevzdání nového kódu a zajistěte, aby měl čistý výstup (nebo použijte režim triage k potlačení určitých problémů).
+- Zkontrolujte své kontrakty pomocí nástroje [Crytic](https://crytic.io/). Kontroluje 50 problémů, které Slither nekontroluje. Crytic může také pomoci vašemu týmu udržet si vzájemný přehled, protože snadno odhaluje bezpečnostní problémy v pull requestech na GitHubu.
+
+Zvažte speciální vlastnosti svého kontraktu:
+
+- Jsou vaše kontrakty aktualizovatelné? Zkontrolujte kód pro aktualizovatelnost na přítomnost chyb pomocí [`slither-check-upgradeability`](https://github.com/crytic/slither/wiki/Upgradeability-Checks) nebo [Crytic](https://blog.trailofbits.com/2020/06/12/upgradeable-contracts-made-safer-with-crytic/). Zdokumentovali jsme 17 způsobů, jak se mohou aktualizace pokazit.
+- Jsou vaše kontrakty v souladu se standardy ERC? Zkontrolujte je pomocí [`slither-check-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance). Tento nástroj okamžitě identifikuje odchylky od šesti běžných specifikací.
+- Integrujete se s tokeny třetích stran? Než se spolehnete na externí kontrakty, projděte si náš [kontrolní seznam pro integraci tokenů](/developers/tutorials/token-integration-checklist/).
+
+Vizuálně zkontrolujte kritické bezpečnostní prvky vašeho kódu:
+
+- Zkontrolujte tiskový výstup [inheritance-graph](https://github.com/trailofbits/slither/wiki/Printer-documentation#inheritance-graph) nástroje Slither. Vyhněte se nechtěnému zastínění (shadowing) a problémům s C3 linearizací.
+- Zkontrolujte tiskový výstup [function-summary](https://github.com/trailofbits/slither/wiki/Printer-documentation#function-summary) nástroje Slither. Reportuje viditelnost funkcí a řízení přístupu.
+- Zkontrolujte tiskový výstup [vars-and-auth](https://github.com/trailofbits/slither/wiki/Printer-documentation#variables-written-and-authorization) nástroje Slither. Reportuje řízení přístupu ke stavovým proměnným.
+
+Zdokumentujte kritické bezpečnostní vlastnosti a použijte automatizované generátory testů k jejich vyhodnocení:
+
+- Naučte se, jak [dokumentovat bezpečnostní vlastnosti svého kódu](/developers/tutorials/guide-to-smart-contract-security-tools/). Zpočátku to není snadné, ale je to nejdůležitější činnost pro dosažení dobrého výsledku. Je to také předpokladem pro použití jakýchkoli pokročilých technik v tomto návodu.
+- Definujte bezpečnostní vlastnosti v jazyce Solidity pro použití s nástroji [Echidna](https://github.com/crytic/echidna) a [Manticore](https://manticore.readthedocs.io/en/latest/verifier.html). Zaměřte se na váš stavový automat, řízení přístupu, aritmetické operace, externí interakce a soulad se standardy.
+- Definujte bezpečnostní vlastnosti pomocí [Python API nástroje Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/). Zaměřte se na dědičnost, závislosti proměnných, řízení přístupu a další strukturální problémy.
+- Spouštějte své testy vlastností při každém commitu pomocí nástroje [Crytic](https://crytic.io). Crytic dokáže zpracovat a vyhodnotit testy bezpečnostních vlastností, takže všichni ve vašem týmu mohou na GitHubu snadno vidět, že procházejí. Neúspěšné testy mohou zablokovat commity.
+
+Nakonec si dejte pozor na problémy, které automatizované nástroje nedokážou snadno najít:
+
+- Nedostatek soukromí: všichni ostatní mohou vidět vaše transakce, zatímco jsou zařazeny v poolu
+- Front-running transakce
+- Kryptografické operace
+- Rizikové interakce s externími komponenty DeFi
+
+## Požádejte o pomoc {#ask-for-help}
+
+[Konzultační hodiny k Ethereu](https://calendly.com/dan-trailofbits/office-hours) se konají každé úterý odpoledne. Tato hodinová, individuální sezení jsou příležitostí zeptat se nás na jakékoli otázky, které máte ohledně bezpečnosti, řešit problémy s používáním našich nástrojů a získat zpětnou vazbu od odborníků na váš současný přístup. Pomůžeme vám projít tímto průvodcem.
+
+Připojte se na náš Slack: [Empire Hacking](https://join.slack.com/t/empirehacking/shared_invite/zt-h97bbrj8-1jwuiU33nnzg67JcvIciUw). Jsme vždy k dispozici na kanálech #crytic a #ethereum, pokud máte jakékoli dotazy.
diff --git a/public/content/translations/cs/developers/tutorials/send-token-ethersjs/index.md b/public/content/translations/cs/developers/tutorials/send-token-ethersjs/index.md
new file mode 100644
index 00000000000..48e42321e11
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/send-token-ethersjs/index.md
@@ -0,0 +1,210 @@
+---
+title: Posílání tokenů pomocí ethers.js
+description: Návod pro začátečníky k posílání tokenů pomocí ethers.js.
+author: Kim YongJun
+tags: [ "ETHERS.JS", "ERC-20", "TOKENY" ]
+skill: beginner
+lang: cs
+published: 2021-04-06
+---
+
+## Odeslání tokenu pomocí ethers.js(5.0) {#send-token}
+
+### V tomto tutoriálu se naučíte {#you-learn-about}
+
+- Importovat ethers.js
+- Převést token
+- Nastavit cenu transakčních poplatků podle situace v síti
+
+### Než začnete {#to-get-started}
+
+Abyste mohli začít, musíme nejprve importovat knihovnu ethers.js do našeho javascriptu
+Zahrňte ethers.js(5.0)
+
+### Instalace {#install-ethersjs}
+
+```shell
+/home/ricmoo> npm install --save ethers
+```
+
+ES6 v prohlížeči
+
+```html
+
+```
+
+ES3(UMD) v prohlížeči
+
+```html
+
+```
+
+### Parametry {#param}
+
+1. **`contract_address`**: Adresa kontraktu tokenu (adresa kontraktu je potřeba, když token, který chcete převést, není ether)
+2. **`send_token_amount`**: Částka, kterou chcete poslat příjemci
+3. **`to_address`**: Adresa příjemce
+4. **`send_account`**: Adresa odesílatele
+5. **`private_key`**: Soukromý klíč odesílatele k podepsání transakce a skutečnému převodu tokenů
+
+## Upozornění {#notice}
+
+`signTransaction(tx)` je odstraněno, protože `sendTransaction()` to dělá interně.
+
+## Postupy odesílání {#procedure}
+
+### 1. Připojit se k síti (testnet) {#connect-to-network}
+
+#### Nastavit poskytovatele (Infura) {#set-provider}
+
+Připojit se k Ropsten testnetu
+
+```javascript
+window.ethersProvider = new ethers.providers.InfuraProvider("ropsten")
+```
+
+### 2. Vytvořit peněženku {#create-wallet}
+
+```javascript
+let wallet = new ethers.Wallet(private_key)
+```
+
+### 3. Připojit peněženku k síti {#connect-wallet-to-net}
+
+```javascript
+let walletSigner = wallet.connect(window.ethersProvider)
+```
+
+### 4. Získat aktuální cenu transakčních poplatků {#get-gas}
+
+```javascript
+window.ethersProvider.getGasPrice() // cena transakčních poplatků
+```
+
+### 5. Definovat transakci {#define-transaction}
+
+Níže definované proměnné jsou závislé na `send_token()`
+
+### Parametry transakce {#transaction-params}
+
+1. **`send_account`**: adresa odesílatele tokenu
+2. **`to_address`**: adresa příjemce tokenu
+3. **`send_token_amount`**: počet tokenů k odeslání
+4. **`gas_limit`**: limit transakčních poplatků
+5. **`gas_price`**: cena transakčních poplatků
+
+[Jak používat, viz níže](#how-to-use)
+
+```javascript
+const tx = {
+ from: send_account,
+ to: to_address,
+ value: ethers.utils.parseEther(send_token_amount),
+ nonce: window.ethersProvider.getTransactionCount(send_account, "latest"),
+ gasLimit: ethers.utils.hexlify(gas_limit), // 100000
+ gasPrice: gas_price,
+}
+```
+
+### 6. Převod {#transfer}
+
+```javascript
+walletSigner.sendTransaction(tx).then((transaction) => {
+ console.dir(transaction)
+ alert("Odesílání dokončeno!")
+})
+```
+
+## Jak to použít {#how-to-use}
+
+```javascript
+let private_key =
+ "41559d28e936dc92104ff30691519693fc753ffbee6251a611b9aa1878f12a4d"
+let send_token_amount = "1"
+let to_address = "0x4c10D2734Fb76D3236E522509181CC3Ba8DE0e80"
+let send_address = "0xda27a282B5B6c5229699891CfA6b900A716539E6"
+let gas_limit = "0x100000"
+let wallet = new ethers.Wallet(private_key)
+let walletSigner = wallet.connect(window.ethersProvider)
+let contract_address = ""
+window.ethersProvider = new ethers.providers.InfuraProvider("ropsten")
+
+send_token(
+ contract_address,
+ send_token_amount,
+ to_address,
+ send_address,
+ private_key
+)
+```
+
+### Úspěch! {#success}
+
+
+
+## send_token() {#send-token-method}
+
+```javascript
+function send_token(
+ contract_address,
+ send_token_amount,
+ to_address,
+ send_account,
+ private_key
+) {
+ let wallet = new ethers.Wallet(private_key)
+ let walletSigner = wallet.connect(window.ethersProvider)
+
+ window.ethersProvider.getGasPrice().then((currentGasPrice) => {
+ let gas_price = ethers.utils.hexlify(parseInt(currentGasPrice))
+ console.log(`gas_price: ${gas_price}`)
+
+ if (contract_address) {
+ // obecné odeslání tokenu
+ let contract = new ethers.Contract(
+ contract_address,
+ send_abi,
+ walletSigner
+ )
+
+ // Kolik tokenů?
+ let numberOfTokens = ethers.utils.parseUnits(send_token_amount, 18)
+ console.log(`numberOfTokens: ${numberOfTokens}`)
+
+ // Odeslat tokeny
+ contract.transfer(to_address, numberOfTokens).then((transferResult) => {
+ console.dir(transferResult)
+ alert("token odeslán")
+ })
+ } // odeslání etheru
+ else {
+ const tx = {
+ from: send_account,
+ to: to_address,
+ value: ethers.utils.parseEther(send_token_amount),
+ nonce: window.ethersProvider.getTransactionCount(
+ send_account,
+ "latest"
+ ),
+ gasLimit: ethers.utils.hexlify(gas_limit), // 100000
+ gasPrice: gas_price,
+ }
+ console.dir(tx)
+ try {
+ walletSigner.sendTransaction(tx).then((transaction) => {
+ console.dir(transaction)
+ alert("Odesílání dokončeno!")
+ })
+ } catch (error) {
+ alert("odeslání se nezdařilo!!")
+ }
+ }
+ })
+}
+```
diff --git a/public/content/translations/cs/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md b/public/content/translations/cs/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
new file mode 100644
index 00000000000..67806b0836c
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
@@ -0,0 +1,208 @@
+---
+title: Odesílání transakcí pomocí Web3
+description: "Toto je průvodce pro začátečníky, jak odesílat transakce v síti Ethereum pomocí Web3. Existují tři hlavní kroky pro odeslání transakce do blockchainu Etherea: vytvoření, podepsání a vysílání. Všechny tři si projdeme."
+author: "Elan Halpern"
+tags: [ "transakce", "web3.js", "alchemy" ]
+skill: beginner
+lang: cs
+published: 2020-11-04
+source: dokumentace Alchemy
+sourceUrl: https://www.alchemy.com/docs/how-to-send-transactions-on-ethereum
+---
+
+Toto je průvodce pro začátečníky, jak odesílat transakce v síti Ethereum pomocí Web3. Existují tři hlavní kroky pro odeslání transakce do blockchainu Etherea: vytvoření, podepsání a vysílání. Všechny tři si projdeme a doufejme, že odpovíme na všechny vaše případné otázky! V tomto návodu budeme k odesílání našich transakcí do řetězce Ethereum používat [Alchemy](https://www.alchemy.com/). Můžete si [zde vytvořit bezplatný účet Alchemy](https://auth.alchemyapi.io/signup).
+
+**POZNÁMKA:** Tento průvodce je určen k podepisování transakcí na _backendu_ vaší aplikace. Pokud chcete integrovat podepisování transakcí na frontendu, podívejte se na integraci [Web3 s poskytovatelem prohlížeče](https://docs.alchemy.com/reference/api-overview#with-a-browser-provider).
+
+## Základy {#the-basics}
+
+Stejně jako většina blockchainových vývojářů, když začínali, jste si možná udělali průzkum, jak poslat transakci (něco, co by mělo být docela jednoduché), a narazili jste na spoustu průvodců, z nichž každý říkal něco jiného a nechal vás trochu zahlcené a zmatené. Pokud se v tom poznáváte, nedělejte si starosti; v určitém okamžiku jsme si tím prošli všichni! Než tedy začneme, ujasněme si několik věcí:
+
+### 1. Alchemy neukládá vaše soukromé klíče {#alchemy-does-not-store-your-private-keys}
+
+- To znamená, že Alchemy nemůže vaším jménem podepisovat a odesílat transakce. Důvodem jsou bezpečnostní účely. Alchemy vás nikdy nepožádá o sdílení vašeho soukromého klíče a vy byste nikdy neměli sdílet svůj soukromý klíč s hostovaným uzlem (nebo s kýmkoli jiným).
+- Pomocí základního API od Alchemy můžete číst z blockchainu, ale abyste do něj mohli zapisovat, budete muset použít něco jiného k podepsání transakcí před jejich odesláním přes Alchemy (to samé platí pro jakoukoli jinou [službu uzlů](/developers/docs/nodes-and-clients/nodes-as-a-service/)).
+
+### 2. Co je to „podepisovatel“? {#what-is-a-signer}
+
+- Podepisovatelé za vás podepíší transakce pomocí vašeho soukromého klíče. V tomto návodu budeme k podepsání naší transakce používat [Alchemy web3](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3), ale můžete použít i jakoukoliv jinou web3 knihovnu.
+- Na frontendu je dobrým příkladem podepisovatele [MetaMask](https://metamask.io/), který za vás bude podepisovat a odesílat transakce.
+
+### 3. Proč musím podepisovat své transakce? {#why-do-i-need-to-sign-my-transactions}
+
+- Každý uživatel, který chce odeslat transakci v síti Ethereum, musí transakci podepsat (pomocí svého soukromého klíče), aby se ověřilo, že původce transakce je ten, za koho se vydává.
+- Je velmi důležité tento soukromý klíč chránit, protože přístup k němu poskytuje plnou kontrolu nad vaším účtem Ethereum, což vám (nebo komukoli s přístupem) umožňuje provádět transakce vaším jménem.
+
+### 4. Jak ochráním svůj soukromý klíč? {#how-do-i-protect-my-private-key}
+
+- Existuje mnoho způsobů, jak chránit svůj soukromý klíč a používat ho k odesílání transakcí. V tomto návodu budeme používat soubor `.env`. Můžete však také použít samostatného poskytovatele, který ukládá soukromé klíče, použít soubor keystore nebo jiné možnosti.
+
+### 5. Jaký je rozdíl mezi `eth_sendTransaction` a `eth_sendRawTransaction`? {#difference-between-send-and-send-raw}
+
+`eth_sendTransaction` a `eth_sendRawTransaction` jsou obě funkce API Etherea, které vysílají transakci do sítě Ethereum, aby byla přidána do budoucího bloku. Liší se v tom, jak nakládají s podepisováním transakcí.
+
+- [`eth_sendTransaction`](https://docs.web3js.org/api/web3-eth/function/sendTransaction) se používá k odesílání _nepodepsaných_ transakcí, což znamená, že uzel, na který odesíláte, musí spravovat váš soukromý klíč, aby mohl transakci podepsat před jejím vysíláním do řetězce. Jelikož Alchemy neuchovává soukromé klíče uživatelů, tuto metodu nepodporuje.
+- [`eth_sendRawTransaction`](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction) se používá k vysílání transakcí, které již byly podepsány. To znamená, že nejprve musíte použít [`signTransaction(tx, private_key)`](https://docs.web3js.org/api/web3-eth-accounts/function/signTransaction) a poté výsledek předat do `eth_sendRawTransaction`.
+
+Při použití web3 se k `eth_sendRawTransaction` přistupuje voláním funkce [web3.eth.sendSignedTransaction](https://docs.web3js.org/api/web3-eth/function/sendSignedTransaction).
+
+To je to, co budeme používat v tomto návodu.
+
+### 6. Co je to knihovna web3? {#what-is-the-web3-library}
+
+- Web3.js je obalová knihovna pro standardní volání JSON-RPC, která se ve vývoji pro Ethereum běžně používá.
+- Existuje mnoho web3 knihoven pro různé jazyky. V tomto návodu budeme používat [Alchemy Web3](https://docs.alchemy.com/reference/api-overview), který je napsán v JavaScriptu. Můžete se podívat na další možnosti [zde](https://docs.alchemyapi.io/guides/getting-started#other-web3-libraries), jako je například [ethers.js](https://docs.ethers.org/v5/).
+
+Dobře, teď, když máme několik těchto otázek z cesty, přejděme k návodu. Neváhejte se kdykoli na cokoli zeptat na [Discordu](https://discord.gg/gWuC7zB) společnosti Alchemy!
+
+### 7. Jak posílat bezpečné, soukromé transakce a transakce s optimalizovanými poplatky? {#how-to-send-secure-gas-optimized-and-private-transactions}
+
+- [Alchemy má sadu Transact API](https://docs.alchemy.com/reference/transact-api-quickstart). Můžete je použít k odesílání posílených transakcí, simulaci transakcí před jejich uskutečněním, odesílání soukromých transakcí a odesílání transakcí optimalizovaných z hlediska poplatků
+- Můžete také použít [Notify API](https://docs.alchemy.com/docs/alchemy-notify), abyste byli upozorněni, když je vaše transakce vytažena z mempoolu a přidána do řetězce.
+
+**POZNÁMKA:** Tento průvodce vyžaduje účet Alchemy, adresu Ethereum nebo peněženku MetaMask, nainstalovaný NodeJs a npm. Pokud ne, postupujte podle následujících kroků:
+
+1. [Vytvořte si bezplatný účet Alchemy](https://auth.alchemyapi.io/signup)
+2. [Vytvořte si účet MetaMask](https://metamask.io/) (nebo získejte adresu Ethereum)
+3. [Postupujte podle těchto kroků k instalaci NodeJs a NPM](https://docs.alchemy.com/alchemy/guides/alchemy-for-macs)
+
+## Kroky k odeslání vaší transakce {#steps-to-sending-your-transaction}
+
+### 1. Vytvořte aplikaci Alchemy na testnetu Sepolia {#create-an-alchemy-app-on-the-sepolia-testnet}
+
+Přejděte na svůj [Alchemy Dashboard](https://dashboard.alchemyapi.io/) a vytvořte novou aplikaci a pro svou síť zvolte Sepolia (nebo jakýkoli jiný testnet).
+
+### 2. Požádejte o ETH z faucetu Sepolia {#request-eth-from-sepolia-faucet}
+
+Chcete-li obdržet ETH, postupujte podle pokynů na [faucetu Sepolia od Alchemy](https://www.sepoliafaucet.com/). Ujistěte se, že jste zadali svou adresu Ethereum na síti **Sepolia** (z MetaMasku) a ne jinou síť. Po provedení pokynů si zkontrolujte, že jste ETH obdrželi do své peněženky.
+
+### 3. Vytvořte nový adresář projektu a přejděte do něj pomocí `cd` {#create-a-new-project-direction}
+
+Vytvořte nový adresář projektu z příkazového řádku (terminál pro Mac) a přejděte do něj:
+
+```
+mkdir sendtx-example
+cd sendtx-example
+```
+
+### 4. Nainstalujte si Alchemy Web3 (nebo jakoukoli web3 knihovnu) {#install-alchemy-web3}
+
+Spusťte následující příkaz ve svém projektovém adresáři, abyste si nainstalovali [Alchemy Web3](https://docs.alchemy.com/reference/api-overview):
+
+Poznámka: Pokud byste chtěli použít knihovnu ethers.js, [postupujte podle pokynů zde](https://docs.alchemy.com/docs/how-to-send-transactions-on-ethereum).
+
+```
+npm install @alch/alchemy-web3
+```
+
+### 5. Nainstalujte si dotenv {#install-dotenv}
+
+Použijeme soubor `.env` k bezpečnému uložení našeho klíče API a soukromého klíče.
+
+```
+npm install dotenv --save
+```
+
+### 6. Vytvořte soubor `.env` {#create-the-dotenv-file}
+
+Vytvořte soubor `.env` ve svém projektovém adresáři a přidejte následující (nahraďte "`your-api-url`" a "`your-private-key`")
+
+- Chcete-li najít adresu URL vašeho Alchemy API, přejděte na stránku s podrobnostmi aplikace, kterou jste právě vytvořili na svém ovládacím panelu, klikněte na „View Key“ v pravém horním rohu a zkopírujte URL adresu HTTP.
+- Chcete-li najít svůj soukromý klíč pomocí MetaMasku, podívejte se na tohoto [průvodce](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key).
+
+```
+API_URL = "your-api-url"
+PRIVATE_KEY = "your-private-key"
+```
+
+
+
+
+Nenahrávejte `.env`! Prosím, ujistěte se, že nikdy nesdílíte ani nezveřejňujete svůj soubor `.env` s nikým, protože tím ohrožujete svá tajemství. Pokud používáte správu verzí, přidejte svůj soubor `.env` do souboru gitignore.
+
+
+
+
+### 7. Vytvořte soubor `sendTx.js` {#create-sendtx-js}
+
+Skvělé, teď, když máme svá citlivá data chráněná v souboru `.env`, pojďme začít kódovat. Jako příklad odeslání transakce budeme posílat ETH zpět do faucetu Sepolia.
+
+Vytvořte soubor `sendTx.js`, ve kterém nakonfigurujeme a odešleme naši ukázkovou transakci, a přidejte do něj následující řádky kódu:
+
+```
+async function main() {
+ require('dotenv').config();
+ const { API_URL, PRIVATE_KEY } = process.env;
+ const { createAlchemyWeb3 } = require("@alch/alchemy-web3");
+ const web3 = createAlchemyWeb3(API_URL);
+ const myAddress = '0x610Ae88399fc1687FA7530Aac28eC2539c7d6d63' //TODO: nahraďte tuto adresu vaší veřejnou adresou
+
+ const nonce = await web3.eth.getTransactionCount(myAddress, 'latest'); // nonce se začíná počítat od 0
+
+ const transaction = {
+ 'to': '0x31B98D14007bDEe637298086988A0bBd31184523', // adresa faucetu pro vrácení ETH
+ 'value': 1000000000000000000, // 1 ETH
+ 'gas': 30000,
+ 'nonce': nonce,
+ // volitelné datové pole pro odeslání zprávy nebo spuštění chytrého kontraktu
+ };
+
+ const signedTx = await web3.eth.accounts.signTransaction(transaction, PRIVATE_KEY);
+
+ web3.eth.sendSignedTransaction(signedTx.rawTransaction, function(error, hash) {
+ if (!error) {
+ console.log("🎉 Haš vaší transakce je: ", hash, "\n Zkontrolujte Mempool Alchemy a zobrazte stav své transakce!");
+ } else {
+ console.log("❗Při odesílání transakce se něco pokazilo:", error)
+ }
+ });
+}
+
+main();
+```
+
+Nezapomeňte nahradit adresu na **řádku 6** vaší vlastní veřejnou adresou.
+
+Než se pustíme do spouštění tohoto kódu, promluvme si o některých jeho součástech.
+
+- `nonce` : Specifikace nonce se používá ke sledování počtu transakcí odeslaných z vaší adresy. Potřebujeme to z bezpečnostních důvodů a k zabránění [útokům typu replay](https://docs.alchemyapi.io/resources/blockchain-glossary#account-nonce). K získání počtu transakcí odeslaných z vaší adresy používáme [getTransactionCount](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_gettransactioncount).
+- `transaction`: Objekt transakce má několik aspektů, které musíme specifikovat
+ - `to`: Toto je adresa, na kterou chceme poslat ETH. V tomto případě posíláme ETH zpět do [faucetu Sepolia](https://sepoliafaucet.com/), od kterého jsme je původně požadovali.
+ - `value`: Toto je částka, kterou si přejeme poslat, specifikovaná ve Wei, kde 10^18 Wei = 1 ETH
+ - `gas`: Existuje mnoho způsobů, jak určit správné množství gasu, které má vaše transakce obsahovat. Alchemy má dokonce [webhook pro cenu gasu](https://docs.alchemyapi.io/guides/alchemy-notify#address-activity-1), který vás upozorní, když cena gasu klesne pod určitou hranici. U transakcí na mainnetu je dobrým zvykem zkontrolovat odhadce poplatků za gas, jako je [ETH Gas Station](https://ethgasstation.info/), abyste určili správné množství gasu, které má transakce obsahovat. 21000 je minimální množství gasu, které operace na Ethereu spotřebuje, takže abychom zajistili, že se naše transakce provede, zadáme zde 30000.
+ - `nonce`: viz definice nonce výše. Nonce se začíná počítat od nuly.
+ - [VOLITELNÉ] data: Používá se k odeslání dodatečných informací s vaším převodem nebo k volání chytrého kontraktu, není vyžadováno pro převody zůstatku, podívejte se na poznámku níže.
+- `signedTx`: K podepsání našeho objektu transakce použijeme metodu `signTransaction` s naším `PRIVATE_KEY`
+- `sendSignedTransaction`: Jakmile máme podepsanou transakci, můžeme ji odeslat k zahrnutí do následujícího bloku pomocí `sendSignedTransaction`
+
+**Poznámka k datům**
+Existují dva hlavní typy transakcí, které lze v Ethereu odeslat.
+
+- Převod zůstatku: Odešlete ETH z jedné adresy na druhou. Není vyžadováno žádné datové pole, avšak pokud byste chtěli spolu s transakcí poslat další informace, můžete je v tomto poli uvést ve formátu HEX.
+ - Řekněme například, že bychom chtěli zapsat haš dokumentu IPFS do řetězce Ethereum, abychom mu dali neměnné časové razítko. Naše datové pole by pak mělo vypadat takto: data: `web3.utils.toHex('haš IPFS')`. A teď se kdokoli může dotázat řetězce a zjistit, kdy byl daný dokument přidán.
+- Transakce chytrého kontraktu: Spusťte nějaký kód chytrého kontraktu na řetězci. V tomto případě by datové pole mělo obsahovat chytrou funkci, kterou si přejete spustit, spolu s jakýmikoli parametry.
+ - Praktický příklad najdete v kroku 8 tohoto [návodu Hello World](https://docs.alchemyapi.io/alchemy/tutorials/hello-world-smart-contract#step-8-create-the-transaction).
+
+### 8. Spusťte kód pomocí `node sendTx.js` {#run-the-code-using-node-sendtx-js}
+
+Vraťte se do svého terminálu nebo příkazového řádku a spusťte:
+
+```
+node sendTx.js
+```
+
+### 9. Zobrazte svou transakci v Mempoolu {#see-your-transaction-in-the-mempool}
+
+Otevřete stránku [Mempool](https://dashboard.alchemyapi.io/mempool) na svém ovládacím panelu Alchemy a filtrujte podle aplikace, kterou jste vytvořili, abyste našli svou transakci. Zde můžeme sledovat přechod naší transakce z čekajícího stavu do stavu vytěženého (v případě úspěchu) nebo zahozeného stavu (v případě neúspěchu). Ujistěte se, že je nastaveno na „All“, abyste zachytili „vytěžené“, „čekající“ a „zahozené“ transakce. Svou transakci můžete také vyhledat tak, že budete hledat transakce odeslané na adresu `0x31b98d14007bdee637298086988a0bbd31184523`.
+
+Chcete-li zobrazit podrobnosti své transakce, jakmile ji najdete, vyberte haš transakce, který by vás měl přenést do zobrazení, které vypadá takto:
+
+
+
+Odtud si můžete prohlédnout svou transakci na Etherscanu kliknutím na červeně zakroužkovanou ikonu!
+
+**Jupííí! Právě jste odeslali svou první transakci na Ethereu pomocí Alchemy 🎉**
+
+_Pro zpětnou vazbu a návrhy k tomuto průvodci prosím napište Elanovi na [Discordu](https://discord.gg/A39JVCM) společnosti Alchemy!_
+
+_Původně publikováno na [https://docs.alchemyapi.io/tutorials/sending-transactions-using-web3-and-alchemy](https://docs.alchemyapi.io/tutorials/sending-transactions-using-web3-and-alchemy)_
diff --git a/public/content/translations/cs/developers/tutorials/server-components/index.md b/public/content/translations/cs/developers/tutorials/server-components/index.md
new file mode 100644
index 00000000000..abc157f8061
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/server-components/index.md
@@ -0,0 +1,295 @@
+---
+title: "Serverové komponenty a agenti pro web3 aplikace"
+description: Po přečtení tohoto tutoriálu budete schopni psát TypeScript servery, které naslouchají událostem na blockchainu a odpovídajícím způsobem reagují vlastními transakcemi. To vám umožní psát centralizované aplikace (protože server je bodem selhání), které ale mohou interagovat s web3 entitami. Stejné techniky lze také použít k napsání agenta, který reaguje na události na blockchainu bez zásahu člověka.
+
+author: Ori Pomerantz
+lang: cs
+tags: [ "agent", "server", "offchain" ]
+skill: beginner
+published: 2024-07-15
+---
+
+## Úvod {#introduction}
+
+Ve většině případů decentralizovaná aplikace používá server k distribuci softwaru, ale veškerá skutečná interakce probíhá mezi klientem (obvykle webovým prohlížečem) a blockchainem.
+
+
+
+Existují však případy, kdy by aplikaci prospěla serverová komponenta, která běží nezávisle. Takový server by byl schopen reagovat na události a na požadavky, které přicházejí z jiných zdrojů, jako je API, vydáváním transakcí.
+
+
+
+Existuje několik možných úkolů, které by takový server mohl plnit.
+
+- Držitel tajného stavu. Při hraní je často užitečné, aby hráči neměli k dispozici všechny informace, které hra zná. Nicméně, _na blockchainu neexistují žádná tajemství_, jakoukoli informaci, která je v blockchainu, může kdokoli snadno zjistit. Proto, pokud má být část stavu hry utajena, musí být uložena jinde (a případně nechat účinky tohoto stavu ověřit pomocí [důkazů s nulovou znalostí](/zero-knowledge-proofs)).
+
+- Centralizované orákulum. Pokud jsou sázky dostatečně nízké, externí server, který čte některé informace online a poté je zveřejňuje na řetězci, může být dostatečně dobrý na to, aby byl použit jako [orákulum](/developers/docs/oracles/).
+
+- Agent. Na blockchainu se nic nestane bez transakce, která by to aktivovala. Server může jednat jménem uživatele a provádět akce, jako je [arbitráž](/developers/docs/mev/#mev-examples-dex-arbitrage), když se naskytne příležitost.
+
+## Ukázkový program {#sample-program}
+
+Ukázkový server si můžete prohlédnout [na GitHubu](https://github.com/qbzzt/20240715-server-component). Tento server naslouchá událostem pocházejícím z [tohoto kontraktu](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=contract_code), upravené verze Hardhat Greeteru. Když se pozdrav změní, změní ho zpět.
+
+Spustíte ho takto:
+
+1. Naklonujte repozitář.
+
+ ```sh copy
+ git clone https://github.com/qbzzt/20240715-server-component.git
+ cd 20240715-server-component
+ ```
+
+2. Nainstalujte potřebné balíčky. Pokud jej ještě nemáte, [nainstalujte nejprve Node](https://nodejs.org/en/download/package-manager).
+
+ ```sh copy
+ npm install
+ ```
+
+3. Upravte soubor `.env` a zadejte soukromý klíč účtu, který má ETH na testnetu Holesky. Pokud nemáte ETH na Holesky, můžete [použít tento faucet](https://holesky-faucet.pk910.de/).
+
+ ```sh filename=".env" copy
+ PRIVATE_KEY=0x
+ ```
+
+4. Spusťte server.
+
+ ```sh copy
+ npm start
+ ```
+
+5. Přejděte do [prohlížeče bloků](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=write_contract) a pomocí jiné adresy, než je ta, ke které máte soukromý klíč, upravte pozdrav. Uvidíte, že pozdrav je automaticky změněn zpět.
+
+### Jak to funguje? Jak to funguje {#how-it-works}
+
+Nejjednodušší způsob, jak pochopit, jak napsat serverovou komponentu, je projít si ukázku řádek po řádku.
+
+#### `src/app.ts` {#src-app-ts}
+
+Drtivá většina programu je obsažena v [`src/app.ts`](https://github.com/qbzzt/20240715-server-component/blob/main/src/app.ts).
+
+##### Vytvoření nezbytných objektů
+
+```typescript
+import {
+ createPublicClient,
+ createWalletClient,
+ getContract,
+ http,
+ Address,
+} from "viem"
+```
+
+Toto jsou entity [Viem](https://viem.sh/), které potřebujeme, funkce a [typ `Address`](https://viem.sh/docs/glossary/types#address). Tento server je napsán v [TypeScriptu](https://www.typescriptlang.org/), což je rozšíření JavaScriptu, které ho činí [silně typovaným](https://en.wikipedia.org/wiki/Strong_and_weak_typing).
+
+```typescript
+import { privateKeyToAccount } from "viem/accounts"
+```
+
+[Tato funkce](https://viem.sh/docs/accounts/privateKey) nám umožňuje generovat informace o peněžence, včetně adresy, odpovídající soukromému klíči.
+
+```typescript
+import { holesky } from "viem/chains"
+```
+
+Abyste mohli v Viem používat blockchain, musíte importovat jeho definici. V tomto případě se chceme připojit k testovacímu blockchainu [Holesky](https://github.com/eth-clients/holesky).
+
+```typescript
+// Takto přidáváme definice z .env do process.env.
+import * as dotenv from "dotenv"
+dotenv.config()
+```
+
+Takto načítáme `.env` do prostředí. Potřebujeme to pro soukromý klíč (viz dále).
+
+```typescript
+const greeterAddress : Address = "0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6"
+const greeterABI = [
+ {
+ "inputs": [
+ {
+ "internalType": "string",
+ "name": "_greeting",
+ "type": "string"
+ }
+ ],
+ "stateMutability": "nonpayable",
+ "type": "constructor"
+ },
+ .
+ .
+ .
+ {
+ "inputs": [
+ {
+ "internalType": "string",
+ "name": "_greeting",
+ "type": "string"
+ }
+ ],
+ "name": "setGreeting",
+ "outputs": [],
+ "stateMutability": "nonpayable",
+ "type": "function"
+ }
+] as const
+```
+
+Pro použití kontraktu potřebujeme jeho adresu a [ABI](/glossary/#abi). Obojí zde uvádíme.
+
+V JavaScriptu (a tedy i v TypeScriptu) nemůžete konstantě přiřadit novou hodnotu, ale _můžete_ upravit objekt, který je v ní uložen. Použitím přípony `as const` říkáme TypeScriptu, že seznam samotný je konstantní a nesmí být změněn.
+
+```typescript
+const publicClient = createPublicClient({
+ chain: holesky,
+ transport: http(),
+})
+```
+
+Vytvořte Viem [veřejného klienta](https://viem.sh/docs/clients/public.html). Veřejní klienti nemají připojený soukromý klíč, a proto nemohou odesílat transakce. Mohou volat [`view` funkce](https://www.tutorialspoint.com/solidity/solidity_view_functions.htm), číst zůstatky na účtech atd.
+
+```typescript
+const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`)
+```
+
+Proměnné prostředí jsou k dispozici v [`process.env`](https://www.totaltypescript.com/how-to-strongly-type-process-env). TypeScript je však silně typovaný. Proměnná prostředí může být jakýkoli řetězec, nebo prázdná, takže typem pro proměnnou prostředí je `string | undefined`. Klíč je však v Viem definován jako `0x${string}` (`0x` následované řetězcem). Zde říkáme TypeScriptu, že proměnná prostředí `PRIVATE_KEY` bude tohoto typu. Pokud ne, dojde k chybě za běhu.
+
+Funkce [`privateKeyToAccount`](https://viem.sh/docs/accounts/privateKey) pak použije tento soukromý klíč k vytvoření úplného objektu účtu.
+
+```typescript
+const walletClient = createWalletClient({
+ account,
+ chain: holesky,
+ transport: http(),
+})
+```
+
+Dále použijeme objekt účtu k vytvoření [klienta peněženky](https://viem.sh/docs/clients/wallet). Tento klient má soukromý klíč a adresu, takže jej lze použít k odesílání transakcí.
+
+```typescript
+const greeter = getContract({
+ address: greeterAddress,
+ abi: greeterABI,
+ client: { public: publicClient, wallet: walletClient },
+})
+```
+
+Nyní, když máme všechny předpoklady, můžeme konečně vytvořit [instanci kontraktu](https://viem.sh/docs/contract/getContract). Tuto instanci kontraktu použijeme ke komunikaci s on-chain kontraktem.
+
+##### Čtení z blockchainu
+
+```typescript
+console.log(`Current greeting:`, await greeter.read.greet())
+```
+
+Funkce kontraktu, které jsou pouze pro čtení ([`view`](https://www.tutorialspoint.com/solidity/solidity_view_functions.htm) a [`pure`](https://www.tutorialspoint.com/solidity/solidity_pure_functions.htm)), jsou dostupné pod `read`. V tomto případě ji používáme pro přístup k funkci [`greet`](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=read_contract#cfae3217), která vrací pozdrav.
+
+JavaScript je jednovláknový, takže když spouštíme dlouhotrvající proces, musíme [specifikovat, že to děláme asynchronně](https://eloquentjavascript.net/11_async.html#h-XvLsfAhtsE). Volání blockchainu, i pro operaci pouze pro čtení, vyžaduje obousměrnou komunikaci mezi počítačem a uzlem blockchainu. To je důvod, proč zde specifikujeme, že kód musí na výsledek `await` (počkat).
+
+Pokud vás zajímá, jak to funguje, můžete si [o tom přečíst zde](https://www.w3schools.com/js/js_promise.asp), ale v praxi vše, co potřebujete vědět, je, že `await` (čekáte na) výsledky, pokud spustíte operaci, která trvá dlouho, a že jakákoli funkce, která to dělá, musí být deklarována jako `async`.
+
+##### Vydávání transakcí
+
+```typescript
+const setGreeting = async (greeting: string): Promise => {
+```
+
+Toto je funkce, kterou voláte pro vydání transakce, která mění pozdrav. Jelikož se jedná o dlouhou operaci, funkce je deklarována jako `async`. Kvůli interní implementaci musí každá `async` funkce vracet objekt `Promise`. V tomto případě `Promise` znamená, že nespecifikujeme, co přesně bude v `Promise` vráceno.
+
+```typescript
+const txHash = await greeter.write.setGreeting([greeting])
+```
+
+Pole `write` instance kontraktu obsahuje všechny funkce, které zapisují do stavu blockchainu (ty, které vyžadují odeslání transakce), jako je [`setGreeting`](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=write_contract#a4136862). Parametry, pokud nějaké jsou, jsou poskytnuty jako seznam a funkce vrací haš transakce.
+
+```typescript
+ console.log(`Working on a fix, see https://eth-holesky.blockscout.com/tx/${txHash}`)
+
+ return txHash
+}
+```
+
+Nahlaste haš transakce (jako součást adresy URL do prohlížeče bloků pro její zobrazení) a vraťte jej.
+
+##### Reakce na události
+
+```typescript
+greeter.watchEvent.SetGreeting({
+```
+
+[Funkce `watchEvent`](https://viem.sh/docs/actions/public/watchEvent) umožňuje specifikovat, že se má funkce spustit, když je emitována událost. Pokud vás zajímá pouze jeden typ události (v tomto případě `SetGreeting`), můžete použít tuto syntaxi k omezení se na tento typ události.
+
+```typescript
+ onLogs: logs => {
+```
+
+Funkce `onLogs` je volána, když existují záznamy protokolu (logy). V Ethereu jsou pojmy „log“ a „událost“ obvykle zaměnitelné.
+
+```typescript
+console.log(
+ `Adresa ${logs[0].args.sender} změnila pozdrav na ${logs[0].args.greeting}`
+)
+```
+
+Mohlo by zde být více událostí, ale pro jednoduchost nás zajímá pouze ta první. `logs[0].args` jsou argumenty události, v tomto případě `sender` a `greeting`.
+
+```typescript
+ if (logs[0].args.sender != account.address)
+ setGreeting(`${account.address} trvá na tom, aby to bylo Hello!`)
+ }
+})
+```
+
+Pokud odesílatel _není_ tento server, použijte `setGreeting` ke změně pozdravu.
+
+#### `package.json` {#package-json}
+
+[Tento soubor](https://github.com/qbzzt/20240715-server-component/blob/main/package.json) řídí konfiguraci [Node.js](https://nodejs.org/en). Tento článek vysvětluje pouze důležité definice.
+
+```json
+{
+ "main": "dist/index.js",
+```
+
+Tato definice určuje, který soubor JavaScriptu se má spustit.
+
+```json
+ "scripts": {
+ "start": "tsc && node dist/app.js",
+ },
+```
+
+Skripty jsou různé akce aplikace. V tomto případě máme pouze jeden, `start`, který kompiluje a poté spouští server. Příkaz `tsc` je součástí balíčku `typescript` a kompiluje TypeScript do JavaScriptu. Pokud jej chcete spustit ručně, nachází se v `node_modules/.bin`. Druhý příkaz spouští server.
+
+```json
+ "type": "module",
+```
+
+Existuje více typů JavaScriptových node aplikací. Typ `module` nám umožňuje mít `await` v kódu nejvyšší úrovně, což je důležité, když provádíte pomalé (a tedy asynchronní) operace.
+
+```json
+ "devDependencies": {
+ "@types/node": "^20.14.2",
+ "typescript": "^5.4.5"
+ },
+```
+
+Toto jsou balíčky, které jsou vyžadovány pouze pro vývoj. Zde potřebujeme `typescript` a protože ho používáme s Node.js, získáváme také typy pro node proměnné a objekty, jako je `process`. [Zápis `^`](https://github.com/npm/node-semver?tab=readme-ov-file#caret-ranges-123-025-004) znamená danou verzi nebo vyšší verzi, která neobsahuje zásadní změny. Více informací o významu čísel verzí naleznete [zde](https://semver.org).
+
+```json
+ "dependencies": {
+ "dotenv": "^16.4.5",
+ "viem": "2.14.1"
+ }
+}
+```
+
+Toto jsou balíčky, které jsou vyžadovány za běhu, při spouštění `dist/app.js`.
+
+## Závěr {#conclusion}
+
+Centralizovaný server, který jsme zde vytvořili, plní svůj úkol, kterým je jednat jako agent pro uživatele. Kdokoli jiný, kdo chce, aby dapp nadále fungoval a je ochoten utratit palivo, může spustit novou instanci serveru s vlastní adresou.
+
+To však funguje pouze tehdy, když lze akce centralizovaného serveru snadno ověřit. Pokud má centralizovaný server nějaké tajné stavové informace nebo provádí složité výpočty, je to centralizovaná entita, které musíte důvěřovat, abyste mohli aplikaci používat, což je přesně to, čemu se blockchainy snaží vyhnout. V budoucím článku plánuji ukázat, jak tento problém obejít pomocí [důkazů s nulovou znalostí](/zero-knowledge-proofs).
+
+[Více z mé práce najdete zde](https://cryptodocguy.pro/).
diff --git a/public/content/translations/cs/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md b/public/content/translations/cs/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
new file mode 100644
index 00000000000..ce8e09f7495
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
@@ -0,0 +1,92 @@
+---
+title: Nastavení web3.js pro použití blockchainu Ethereum v JavaScriptu
+description: Naučte se, jak nastavit a nakonfigurovat knihovnu web3.js pro interakci s blockchainem Etherea z javascriptových aplikací.
+author: "jdourlens"
+tags: [ "web3.js", "javascript" ]
+skill: beginner
+lang: cs
+published: 2020-04-11
+source: EthereumDev
+sourceUrl: https://ethereumdev.io/setup-web3js-to-use-the-ethereum-blockchain-in-javascript/
+address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
+---
+
+V tomto tutoriálu se podíváme, jak začít s [web3.js](https://web3js.readthedocs.io/) pro interakci s blockchainem Etherea. Web3.js lze použít jak na frontendu, tak na backendu ke čtení dat z blockchainu, provádění transakcí, a dokonce i k nasazení chytrých kontraktů.
+
+Prvním krokem je zahrnout web3.js do vašeho projektu. Chcete-li jej použít na webové stránce, můžete knihovnu importovat přímo pomocí CDN, jako je JSDeliver.
+
+```html
+
+```
+
+Pokud dáváte přednost instalaci knihovny pro použití ve vašem backendu nebo front-endovém projektu, který používá sestavení, můžete ji nainstalovat pomocí npm:
+
+```bash
+npm install web3 --save
+```
+
+Chcete-li poté importovat Web3.js do skriptu Node.js nebo front-endového projektu Browserify, můžete použít následující řádek JavaScriptu:
+
+```js
+const Web3 = require("web3")
+```
+
+Nyní, když jsme knihovnu zahrnuli do projektu, ji musíme inicializovat. Váš projekt musí být schopen komunikovat s blockchainem. Většina knihoven pro Ethereum komunikuje s [uzlem](/developers/docs/nodes-and-clients/) prostřednictvím volání RPC. Pro inicializaci poskytovatele Web3 vytvoříme instanci Web3 a jako konstruktor předáme URL adresu poskytovatele. Pokud máte na svém počítači spuštěný uzel nebo [instanci ganache](https://ethereumdev.io/testing-your-smart-contract-with-existing-protocols-ganache-fork/), bude to vypadat takto:
+
+```js
+const web3 = new Web3("http://localhost:8545")
+```
+
+Pokud chcete přistupovat přímo k hostovanému uzlu, můžete najít možnosti na stránce [uzly jako služba](/developers/docs/nodes-and-clients/nodes-as-a-service).
+
+```js
+const web3 = new Web3("https://cloudflare-eth.com")
+```
+
+Abychom otestovali, že jsme správně nakonfigurovali naši instanci Web3, zkusíme načíst číslo posledního bloku pomocí funkce `getBlockNumber`. Tato funkce přijímá jako parametr zpětné volání (callback) a vrací číslo bloku jako celé číslo.
+
+```js
+var Web3 = require("web3")
+const web3 = new Web3("https://cloudflare-eth.com")
+
+web3.eth.getBlockNumber(function (error, result) {
+ console.log(result)
+})
+```
+
+Pokud tento program spustíte, jednoduše vypíše číslo posledního bloku: vrchol blockchainu. Můžete také použít volání funkcí `await/async`, abyste se vyhnuli vnořování zpětných volání (callbacks) ve vašem kódu:
+
+```js
+async function getBlockNumber() {
+ const latestBlockNumber = await web3.eth.getBlockNumber()
+ console.log(latestBlockNumber)
+ return latestBlockNumber
+}
+
+getBlockNumber()
+```
+
+Všechny dostupné funkce v instanci Web3 si můžete prohlédnout v [oficiální dokumentaci web3.js](https://docs.web3js.org/).
+
+Většina knihoven Web3 je asynchronních, protože na pozadí knihovna provádí JSON-RPC volání na uzel, který posílá zpět výsledek.
+
+(, ...).`
+
+```solidity
+
+ _retVal = _retVal >> (256-length*8);
+```
+
+Součástí pole jsou pouze nejvýznamnější bajty `length`, takže provedeme [posun doprava](https://en.wikipedia.org/wiki/Logical_shift), abychom se zbavili ostatních hodnot.
+To má další výhodu v tom, že se hodnota přesune napravo od pole, takže se jedná o hodnotu samotnou, nikoli o hodnotu vynásobenou 256něčím.
+
+```solidity
+
+ return _retVal;
+ }
+
+
+ fallback() external {
+```
+
+Když volání kontraktu v Solidity neodpovídá žádnému z podpisů funkcí, zavolá se [funkce `fallback()`](https://docs.soliditylang.org/en/v0.8.12/contracts.html#fallback-function) (pokud existuje).
+V případě `CalldataInterpreter` se sem dostane _jakékoli_ volání, protože neexistují žádné jiné `externí` nebo `veřejné` funkce.
+
+```solidity
+ uint _func;
+
+ _func = calldataVal(0, 1);
+```
+
+Přečtěte první bajt calldata, který nám sdělí funkci.
+Existují dva důvody, proč by zde funkce nebyla dostupná:
+
+1. Funkce, které jsou `pure` nebo `view`, nemění stav a nestojí palivo (při volání mimo řetězec).
+ Nemá smysl se snažit snižovat jejich náklady na palivo.
+2. Funkce, které se spoléhají na [`msg.sender`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#block-and-transaction-properties).
+ Hodnota `msg.sender` bude adresa kontraktu `CalldataInterpreter`, nikoli volajícího.
+
+Bohužel [při pohledu na specifikace ERC-20](https://eips.ethereum.org/EIPS/eip-20), zbývá pouze jedna funkce, `transfer`.
+To nám ponechává pouze dvě funkce: `transfer` (protože můžeme volat `transferFrom`) a `faucet` (protože můžeme převést tokeny zpět tomu, kdo nás volal).
+
+```solidity
+
+ // Volání metod tokenu měnících stav pomocí
+ // informací z calldata
+
+ // faucet
+ if (_func == 1) {
+```
+
+Volání funkce `faucet()`, která nemá žádné parametry.
+
+```solidity
+ token.faucet();
+ token.transfer(msg.sender,
+ token.balanceOf(address(this)));
+ }
+```
+
+Po zavolání `token.faucet()` získáme tokeny. Jako proxy kontrakt však tokeny **nepotřebujeme**.
+Potřebuje je EOA (externě vlastněný účet) nebo kontrakt, který nás volal.
+Takže převedeme všechny naše tokeny tomu, kdo nás volal.
+
+```solidity
+ // transfer (předpokládejme, že na něj máme povolenku)
+ if (_func == 2) {
+```
+
+Převod tokenů vyžaduje dva parametry: cílovou adresu a částku.
+
+```solidity
+ token.transferFrom(
+ msg.sender,
+```
+
+Volajícím povolujeme převádět pouze tokeny, které vlastní
+
+```solidity
+ address(uint160(calldataVal(1, 20))),
+```
+
+Cílová adresa začíná na bajtu č. 1 (bajt č. 0 je funkce).
+Jako adresa je dlouhá 20 bajtů.
+
+```solidity
+ calldataVal(21, 2)
+```
+
+U tohoto konkrétního kontraktu předpokládáme, že maximální počet tokenů, které by kdokoli chtěl převést, se vejde do dvou bajtů (méně než 65 536).
+
+```solidity
+ );
+ }
+```
+
+Celkově převod zabere 35 bajtů calldata:
+
+| Sekce | Délka | Bajty |
+| --------------- | ----: | ----: |
+| Selektor funkce | 1 | 0 |
+| Cílová adresa | 32 | 1-32 |
+| Částka | 2 | 33-34 |
+
+```solidity
+ } // fallback
+
+} // contract CalldataInterpreter
+```
+
+### test.js {#test-js}
+
+[Tento jednotkový test v JavaScriptu](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/test/test.js) nám ukazuje, jak tento mechanismus používat (a jak ověřit, že funguje správně).
+Budu předpokládat, že rozumíte [chai](https://www.chaijs.com/) a [ethers](https://docs.ethers.io/v5/) a vysvětlím pouze části, které se týkají konkrétně tohoto kontraktu.
+
+```js
+const { expect } = require("chai");
+
+describe("CalldataInterpreter", function () {
+ it("Mělo by nám umožnit používat tokeny", async function () {
+ const Token = await ethers.getContractFactory("OrisUselessToken")
+ const token = await Token.deploy()
+ await token.deployed()
+ console.log("Adresa tokenu:", token.address)
+
+ const Cdi = await ethers.getContractFactory("CalldataInterpreter")
+ const cdi = await Cdi.deploy(token.address)
+ await cdi.deployed()
+ console.log("Adresa CalldataInterpreter:", cdi.address)
+
+ const signer = await ethers.getSigner()
+```
+
+Začneme nasazením obou kontraktů.
+
+```javascript
+ // Získat tokeny na hraní
+ const faucetTx = {
+```
+
+Nemůžeme k vytváření transakcí použít funkce na vysoké úrovni, které bychom normálně používali (například `token.faucet()`), protože nedodržujeme ABI.
+Místo toho musíme transakci sestavit sami a poté ji odeslat.
+
+```javascript
+ to: cdi.address,
+ data: "0x01"
+```
+
+Pro transakci musíme zadat dva parametry:
+
+1. `to`, cílová adresa.
+ Toto je kontrakt interpretu calldata.
+2. `data`, calldata k odeslání.
+ V případě volání faucet jsou data tvořena jediným bajtem, `0x01`.
+
+```javascript
+
+ }
+ await (await signer.sendTransaction(faucetTx)).wait()
+```
+
+Voláme [metodu `sendTransaction` podepisujícího](https://docs.ethers.io/v5/api/signer/#Signer-sendTransaction), protože jsme již zadali cíl (`faucetTx.to`) a potřebujeme, aby byla transakce podepsána.
+
+```javascript
+// Zkontrolujte, zda faucet poskytuje tokeny správně
+expect(await token.balanceOf(signer.address)).to.equal(1000)
+```
+
+Zde ověříme zůstatek.
+Není třeba šetřit palivo na funkcích `view`, takže je prostě spouštíme normálně.
+
+```javascript
+// Dejte CDI povolenku (schválení nelze provést přes proxy)
+const approveTX = await token.approve(cdi.address, 10000)
+await approveTX.wait()
+expect(await token.allowance(signer.address, cdi.address)).to.equal(10000)
+```
+
+Dejte interpretu calldata povolenku, aby mohl provádět převody.
+
+```javascript
+// Převod tokenů
+const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d"
+const transferTx = {
+ to: cdi.address,
+ data: "0x02" + destAddr.slice(2, 42) + "0100",
+}
+```
+
+Vytvořte transakci převodu. První bajt je „0x02“, následuje cílová adresa a nakonec částka (0x0100, což je 256 v desítkové soustavě).
+
+```javascript
+ await (await signer.sendTransaction(transferTx)).wait()
+
+ // Zkontrolujte, že máme o 256 tokenů méně
+ expect (await token.balanceOf(signer.address)).to.equal(1000-256)
+
+ // A že je náš cíl dostal
+ expect (await token.balanceOf(destAddr)).to.equal(256)
+ }) // it
+}) // describe
+```
+
+## Snížení nákladů, když máte kontrolu nad cílovým kontraktem {#reducing-the-cost-when-you-do-control-the-destination-contract}
+
+Pokud máte kontrolu nad cílovým kontraktem, můžete vytvořit funkce, které obcházejí kontroly `msg.sender`, protože důvěřují interpretu calldata.
+[Příklad, jak to funguje, si můžete prohlédnout zde, ve větvi `control-contract`](https://github.com/qbzzt/ethereum.org-20220330-shortABI/tree/control-contract).
+
+Pokud by kontrakt reagoval pouze na externí transakce, vystačili bychom si s jedním kontraktem.
+To by však narušilo [složitelnost](/developers/docs/smart-contracts/composability/).
+Je mnohem lepší mít kontrakt, který reaguje na běžná volání ERC-20, a další kontrakt, který reaguje na transakce s krátkými calldata.
+
+### Token.sol {#token-sol-2}
+
+V tomto příkladu můžeme upravit `Token.sol`.
+To nám umožňuje mít řadu funkcí, které může volat pouze proxy.
+Zde jsou nové části:
+
+```solidity
+ // Jediná adresa, která může zadat adresu CalldataInterpreter
+ address owner;
+
+ // Adresa CalldataInterpreter
+ address proxy = address(0);
+```
+
+Kontrakt ERC-20 musí znát identitu autorizovaného proxy.
+Tuto proměnnou však nemůžeme nastavit v konstruktoru, protože její hodnotu ještě neznáme.
+Tento kontrakt je instanciován jako první, protože proxy očekává adresu tokenu ve svém konstruktoru.
+
+```solidity
+ /**
+ * @dev Volá konstruktor ERC20.
+ */
+ constructor(
+ ) ERC20("Oris useless token-2", "OUT-2") {
+ owner = msg.sender;
+ }
+```
+
+Adresa tvůrce (nazývaná `owner`) je zde uložena, protože je to jediná adresa, která smí nastavit proxy.
+
+```solidity
+ /**
+ * @dev nastaví adresu pro proxy (CalldataInterpreter).
+ * Může být zavolána pouze jednou vlastníkem
+ */
+ function setProxy(address _proxy) external {
+ require(msg.sender == owner, "Může být voláno pouze vlastníkem");
+ require(proxy == address(0), "Proxy je již nastaveno");
+
+ proxy = _proxy;
+ } // function setProxy
+```
+
+Proxy má privilegovaný přístup, protože může obcházet bezpečnostní kontroly.
+Abychom se ujistili, že můžeme proxy důvěřovat, necháme tuto funkci volat pouze `vlastníka`, a to pouze jednou.
+Jakmile má `proxy` skutečnou hodnotu (nenulovou), nelze tuto hodnotu změnit, takže i kdyby se vlastník rozhodl stát se nepoctivým, nebo by byla odhalena jeho mnemotechnická pomůcka, jsme stále v bezpečí.
+
+```solidity
+ /**
+ * @dev Některé funkce mohou být volány pouze proxy.
+ */
+ modifier onlyProxy {
+```
+
+Toto je [`modifikátorová` funkce](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm), která upravuje způsob fungování ostatních funkcí.
+
+```solidity
+ require(msg.sender == proxy);
+```
+
+Nejprve ověřte, že nás volal proxy a nikdo jiný.
+Pokud ne, `revert`.
+
+```solidity
+ _;
+ }
+```
+
+Pokud ano, spusťte funkci, kterou upravujeme.
+
+```solidity
+ /* Funkce, které umožňují proxy skutečně zastupovat účty */
+
+ function transferProxy(address from, address to, uint256 amount)
+ public virtual onlyProxy() returns (bool)
+ {
+ _transfer(from, to, amount);
+ return true;
+ }
+
+ function approveProxy(address from, address spender, uint256 amount)
+ public virtual onlyProxy() returns (bool)
+ {
+ _approve(from, spender, amount);
+ return true;
+ }
+
+ function transferFromProxy(
+ address spender,
+ address from,
+ address to,
+ uint256 amount
+ ) public virtual onlyProxy() returns (bool)
+ {
+ _spendAllowance(from, spender, amount);
+ _transfer(from, to, amount);
+ return true;
+ }
+```
+
+Jedná se o tři operace, které obvykle vyžadují, aby zpráva přišla přímo od subjektu, který převádí tokeny nebo schvaluje povolenku.
+Zde máme proxy verzi těchto operací, která:
+
+1. Je upravena `onlyProxy()`, takže je nikdo jiný nesmí ovládat.
+2. Získá adresu, která by normálně byla `msg.sender` jako další parametr.
+
+### CalldataInterpreter.sol {#calldatainterpreter-sol-2}
+
+Interpret calldata je téměř totožný s výše uvedeným, s výjimkou toho, že funkce proxy dostávají parametr `msg.sender` a není potřeba povolenka pro `transfer`.
+
+```solidity
+ // transfer (není potřeba povolenka)
+ if (_func == 2) {
+ token.transferProxy(
+ msg.sender,
+ address(uint160(calldataVal(1, 20))),
+ calldataVal(21, 2)
+ );
+ }
+
+ // schválit
+ if (_func == 3) {
+ token.approveProxy(
+ msg.sender,
+ address(uint160(calldataVal(1, 20))),
+ calldataVal(21, 2)
+ );
+ }
+
+ // transferFrom
+ if (_func == 4) {
+ token.transferFromProxy(
+ msg.sender,
+ address(uint160(calldataVal( 1, 20))),
+ address(uint160(calldataVal(21, 20))),
+ calldataVal(41, 2)
+ );
+ }
+```
+
+### Test.js {#test-js-2}
+
+Mezi předchozím testovacím kódem a tímto je několik změn.
+
+```js
+const Cdi = await ethers.getContractFactory("CalldataInterpreter")
+const cdi = await Cdi.deploy(token.address)
+await cdi.deployed()
+await token.setProxy(cdi.address)
+```
+
+Musíme kontraktu ERC-20 sdělit, kterému proxy má důvěřovat.
+
+```js
+console.log("Adresa CalldataInterpreter:", cdi.address)
+
+// K ověření povolenek potřebujeme dva podepisující
+const signers = await ethers.getSigners()
+const signer = signers[0]
+const poorSigner = signers[1]
+```
+
+Ke kontrole `approve()` a `transferFrom()` potřebujeme druhého podepisujícího.
+Říkáme mu `poorSigner` (chudý podepisující), protože nedostane žádný z našich tokenů (samozřejmě ale musí mít ETH).
+
+```js
+// Převod tokenů
+const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d"
+const transferTx = {
+ to: cdi.address,
+ data: "0x02" + destAddr.slice(2, 42) + "0100",
+}
+await (await signer.sendTransaction(transferTx)).wait()
+```
+
+Protože kontrakt ERC-20 důvěřuje proxy (`cdi`), nepotřebujeme povolenku k předávání převodů.
+
+```js
+// schválení a transferFrom
+const approveTx = {
+ to: cdi.address,
+ data: "0x03" + poorSigner.address.slice(2, 42) + "00FF",
+}
+await (await signer.sendTransaction(approveTx)).wait()
+
+const destAddr2 = "0xE1165C689C0c3e9642cA7606F5287e708d846206"
+
+const transferFromTx = {
+ to: cdi.address,
+ data: "0x04" + signer.address.slice(2, 42) + destAddr2.slice(2, 42) + "00FF",
+}
+await (await poorSigner.sendTransaction(transferFromTx)).wait()
+
+// Zkontrolujte, zda byla kombinace approve / transferFrom provedena správně
+expect(await token.balanceOf(destAddr2)).to.equal(255)
+```
+
+Otestujte dvě nové funkce.
+Všimněte si, že `transferFromTx` vyžaduje dva parametry adresy: dárce povolenky a příjemce.
+
+## Závěr {#conclusion}
+
+Jak [Optimism](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92), tak [Arbitrum](https://developer.offchainlabs.com/docs/special_features) hledají způsoby, jak zmenšit velikost calldata zapisovaných na L1, a tím i náklady na transakce.
+Jako poskytovatelé infrastruktury, kteří hledají obecná řešení, jsou však naše schopnosti omezené.
+Jako vývojář dapp máte znalosti specifické pro danou aplikaci, což vám umožňuje optimalizovat calldata mnohem lépe, než bychom mohli v obecném řešení.
+Doufejme, že vám tento článek pomůže najít ideální řešení pro vaše potřeby.
+
+[Více z mé práce najdete zde](https://cryptodocguy.pro/).
+
diff --git a/public/content/translations/cs/developers/tutorials/smart-contract-security-guidelines/index.md b/public/content/translations/cs/developers/tutorials/smart-contract-security-guidelines/index.md
new file mode 100644
index 00000000000..992b766bc69
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/smart-contract-security-guidelines/index.md
@@ -0,0 +1,91 @@
+---
+title: Pokyny pro zabezpečení smart kontraktů
+description: Kontrolní seznam bezpečnostních pokynů, které je třeba zvážit při vytváření vaší dapp.
+author: "Trailofbits"
+tags: [ "solidity", "chytré kontrakty", "bezpečnost" ]
+skill: intermediate
+lang: cs
+published: 2020-09-06
+source: Tvorba bezpečných kontraktů
+sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md
+---
+
+Řiďte se těmito doporučeními na vysoké úrovni, abyste mohli vytvářet bezpečnější chytré kontrakty.
+
+## Pokyny pro návrh {#design-guidelines}
+
+Návrh kontraktu by měl být prodiskutován předem, ještě před napsáním jakéhokoli řádku kódu.
+
+### Dokumentace a specifikace {#documentation-and-specifications}
+
+Dokumentaci lze psát na různých úrovních a měla by být aktualizována při implementaci kontraktů:
+
+- **Jednoduchý srozumitelný popis systému**, který popisuje, co kontrakty dělají a jaké jsou předpoklady týkající se kódové základny.
+- **Schémata a architektonické diagramy**, včetně interakcí kontraktů a stavového automatu systému. [Slither printers](https://github.com/crytic/slither/wiki/Printer-documentation) mohou pomoci s generováním těchto schémat.
+- **Důkladná dokumentace kódu**, pro Solidity lze použít [formát Natspec](https://docs.soliditylang.org/en/develop/natspec-format.html).
+
+### Výpočty on-chain vs. off-chain {#onchain-vs-offchain-computation}
+
+- **Ponechte co nejvíce kódu off-chain.** Udržujte on-chain vrstvu malou. Předzpracujte data pomocí kódu off-chain tak, aby ověření on-chain bylo jednoduché. Potřebujete seřazený seznam? Seřaďte seznam off-chain, poté pouze zkontrolujte jeho pořadí on-chain.
+
+### Vylepšitelnost {#upgradeability}
+
+O různých řešeních vylepšitelnosti jsme diskutovali v [našem příspěvku na blogu](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/). Před napsáním jakéhokoli kódu učiňte vědomé rozhodnutí, zda vylepšitelnost podporovat, či nikoliv. Toto rozhodnutí ovlivní, jak budete strukturovat svůj kód. Obecně doporučujeme:
+
+- **Upřednostňujte [migraci kontraktů](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) před vylepšitelností.** Migrační systémy mají mnoho stejných výhod jako ty vylepšitelné, ale nemají jejich nevýhody.
+- **Používejte vzor oddělení dat namísto vzoru delegatecallproxy.** Pokud má váš projekt jasné oddělení abstrakce, vylepšitelnost pomocí oddělení dat bude vyžadovat jen několik úprav. Delegatecallproxy vyžaduje odborné znalosti EVM a je vysoce náchylný k chybám.
+- **Zdokumentujte postup migrace/vylepšení před nasazením.** Pokud budete muset reagovat pod stresem bez jakýchkoli pokynů, uděláte chyby. Napište si postup s předstihem. Měl by zahrnovat:
+ - Volání, která iniciují nové kontrakty
+ - Kde jsou uloženy klíče a jak k nim přistupovat
+ - Jak zkontrolovat nasazení! Vytvořte a otestujte skript, který se spustí po nasazení.
+
+## Pokyny pro implementaci {#implementation-guidelines}
+
+**Usilujte o jednoduchost.** Vždy používejte nejjednodušší řešení, které vyhovuje vašemu účelu. Každý člen vašeho týmu by měl být schopen porozumět vašemu řešení.
+
+### Skládání funkcí {#function-composition}
+
+Architektura vaší kódové základny by měla usnadňovat revizi kódu. Vyhněte se architektonickým rozhodnutím, která snižují schopnost posoudit jeho správnost.
+
+- **Rozdělte logiku vašeho systému**, buď do více kontraktů, nebo seskupením podobných funkcí (například ověřování, aritmetika, ...).
+- **Pište malé funkce s jasným účelem.** To usnadní revizi a umožní testování jednotlivých komponent.
+
+### Dědičnost {#inheritance}
+
+- **Udržujte dědičnost zvládnutelnou.** Dědičnost by se měla používat k rozdělení logiky, nicméně váš projekt by se měl snažit minimalizovat hloubku a šířku stromu dědičnosti.
+- **Použijte [inheritance printer](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph) od Slitheru ke kontrole hierarchie kontraktů.** Tento nástroj vám pomůže zkontrolovat velikost hierarchie.
+
+### Události {#events}
+
+- **Zaznamenávejte všechny klíčové operace.** Události pomohou při ladění kontraktu během vývoje a při jeho monitorování po nasazení.
+
+### Vyhněte se známým nástrahám {#avoid-known-pitfalls}
+
+- **Mějte na paměti nejběžnější bezpečnostní problémy.** Existuje mnoho online zdrojů, kde se můžete o běžných problémech dozvědět, jako například [Ethernaut CTF](https://ethernaut.openzeppelin.com/), [Capture the Ether](https://capturetheether.com/) nebo [Not so smart contracts](https://github.com/crytic/not-so-smart-contracts/).
+- **Věnujte pozornost sekcím s varováními v [dokumentaci Solidity](https://docs.soliditylang.org/en/latest/).** Sekce s varováními vás informují o ne zcela zjevném chování jazyka.
+
+### Závislosti {#dependencies}
+
+- **Používejte dobře otestované knihovny.** Importování kódu z dobře otestovaných knihoven sníží pravděpodobnost, že napíšete kód s chybami. Pokud chcete napsat kontrakt ERC20, použijte [OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20).
+- **Používejte správce závislostí; vyhněte se kopírování kódu.** Pokud se spoléháte na externí zdroj, musíte jej udržovat aktuální s původním zdrojem.
+
+### Testování a ověřování {#testing-and-verification}
+
+- **Napište důkladné jednotkové testy.** Rozsáhlá sada testů je klíčová pro vytvoření vysoce kvalitního softwaru.
+- **Napište vlastní kontroly a vlastnosti pro [Slither](https://github.com/crytic/slither), [Echidna](https://github.com/crytic/echidna) a [Manticore](https://github.com/trailofbits/manticore).** Automatizované nástroje pomohou zajistit bezpečnost vašeho kontraktu. Projděte si zbytek této příručky, abyste se naučili, jak psát efektivní kontroly a vlastnosti.
+- **Používejte [crytic.io](https://crytic.io/).** Crytic se integruje s GitHubem, poskytuje přístup k soukromým detektorům Slither a spouští vlastní kontroly vlastností z Echidny.
+
+### Solidity {#solidity}
+
+- **Upřednostňujte Solidity 0.5 před verzemi 0.4 a 0.6.** Podle našeho názoru je Solidity 0.5 bezpečnější a má lepší vestavěné postupy než verze 0.4. Solidity 0.6 se ukázalo jako příliš nestabilní pro produkční nasazení a potřebuje čas na dozrání.
+- **Pro kompilaci používejte stabilní vydání; pro kontrolu varování používejte nejnovější vydání.** Zkontrolujte, zda váš kód nemá žádné hlášené problémy s nejnovější verzí kompilátoru. Solidity má však rychlý cyklus vydávání a v minulosti se v něm objevily chyby kompilátoru, takže nejnovější verzi pro nasazení nedoporučujeme (viz [doporučení verze solc](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33) od Slitheru).
+- **Nepoužívejte inline assembly.** Assembly vyžaduje odborné znalosti EVM. Nepište kód EVM, pokud jste _neovládli_ žlutou knihu.
+
+## Pokyny pro nasazení {#deployment-guidelines}
+
+Jakmile je kontrakt vyvinut a nasazen:
+
+- **Monitorujte své kontrakty.** Sledujte logy a buďte připraveni reagovat v případě kompromitace kontraktu nebo peněženky.
+- **Přidejte své kontaktní údaje do [blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts).** Tento seznam pomáhá třetím stranám vás kontaktovat, pokud je objevena bezpečnostní chyba.
+- **Zabezpečte peněženky privilegovaných uživatelů.** Pokud ukládáte klíče v hardwarových peněženkách, řiďte se našimi [osvědčenými postupy](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/).
+- **Mějte plán reakce na incidenty.** Počítejte s tím, že vaše chytré kontrakty mohou být kompromitovány. I když jsou vaše kontrakty bez chyb, útočník může převzít kontrolu nad klíči vlastníka kontraktu.
diff --git a/public/content/translations/cs/developers/tutorials/stealth-addr/index.md b/public/content/translations/cs/developers/tutorials/stealth-addr/index.md
new file mode 100644
index 00000000000..a76b5ba153e
--- /dev/null
+++ b/public/content/translations/cs/developers/tutorials/stealth-addr/index.md
@@ -0,0 +1,443 @@
+---
+title: "Použití skrytých adres"
+description: "Skryté adresy umožňují uživatelům anonymně převádět aktiva. Po přečtení tohoto článku budete schopni: vysvětlit, co jsou skryté adresy a jak fungují, pochopit, jak používat skryté adresy způsobem, který zachovává anonymitu, a napsat webovou aplikaci, která používá skryté adresy."
+author: Ori Pomerantz
+tags:
+ [
+ "Skrytá adresa",
+ "soukromí",
+ "kryptografie",
+ "rust",
+ "wasm"
+ ]
+skill: intermediate
+published: 2025-11-30
+lang: cs
+sidebarDepth: 3
+---
+
+Jste Bill. Z důvodů, do kterých nebudeme zabíhat, chcete přispět na kampaň „Alice za královnu světa“ a chcete, aby Alice věděla, že jste přispěli, aby vás odměnila, pokud vyhraje. Její vítězství však bohužel není zaručeno. Existuje konkurenční kampaň „Carol za císařovnu Sluneční soustavy“. Pokud Carol vyhraje a zjistí, že jste přispěli Alici, budete mít potíže. Nemůžete tedy jen tak převést 200 ETH ze svého účtu na účet Alice.
+
+[ERC-5564](https://eips.ethereum.org/EIPS/eip-5564) nabízí řešení. Tento ERC vysvětluje, jak používat [skryté adresy](https://nerolation.github.io/stealth-utils) pro anonymní převody.
+
+**Upozornění**: Kryptografie za skrytými adresami je, pokud víme, spolehlivá. Existují však potenciální útoky postranním kanálem. [Níže](#go-wrong) uvidíte, co můžete udělat pro snížení tohoto rizika.
+
+## Jak fungují skryté adresy {#how}
+
+Tento článek se pokusí vysvětlit skryté adresy dvěma způsoby. První je [jak je používat](#how-use). Tato část je dostatečná k pochopení zbytku článku. Dále je zde [vysvětlení matematiky, která za tím stojí](#how-math). Pokud se zajímáte o kryptografii, přečtěte si i tuto část.
+
+### Zjednodušená verze (jak používat skryté adresy) {#how-use}
+
+Alice vytvoří dva privátní klíče a zveřejní odpovídající veřejné klíče (které lze zkombinovat do jedné meta-adresy dvojnásobné délky). Bill také vytvoří privátní klíč a zveřejní odpovídající veřejný klíč.
+
+Pomocí veřejného klíče jedné strany a privátního klíče druhé strany můžete odvodit sdílené tajemství známé pouze Alici a Billovi (nelze jej odvodit pouze z veřejných klíčů). Pomocí tohoto sdíleného tajemství získá Bill skrytou adresu a může na ni posílat aktiva.
+
+Alice také získá adresu ze sdíleného tajemství, ale protože zná privátní klíče k veřejným klíčům, které zveřejnila, může také získat privátní klíč, který jí umožní vybírat z této adresy.
+
+### Matematika (proč skryté adresy fungují takto) {#how-math}
+
+Standardní skryté adresy používají [kryptografii na bázi eliptických křivek (ECC)](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/#elliptic-curves-building-blocks-of-a-better-trapdoor), aby dosáhly lepšího výkonu s menším počtem bitů klíče a zároveň zachovaly stejnou úroveň zabezpečení. Ale z větší části to můžeme ignorovat a předstírat, že používáme běžnou aritmetiku.
+
+Existuje číslo, které každý zná, _G_. Můžete násobit _G_. Ale vzhledem k povaze ECC je prakticky nemožné dělit _G_. Způsob, jakým kryptografie s veřejným klíčem v Ethereu obecně funguje, je, že můžete použít privátní klíč _Ppriv_ k podepisování transakcí, které jsou poté ověřeny veřejným klíčem _Ppub = GPpriv_.
+
+Alice vytvoří dva privátní klíče, _Kpriv_ a _Vpriv_. _Kpriv_ se použije k utrácení peněz ze skryté adresy a _Vpriv_ k zobrazení adres, které patří Alici. Alice poté zveřejní veřejné klíče: _Kpub = GKpriv_ a _Vpub = GVpriv_
+
+Bill vytvoří třetí privátní klíč, _Rpriv_, a zveřejní _Rpub = GRpriv_ v centrálním registru (Bill ho mohl poslat také Alici, ale předpokládáme, že Carol poslouchá).
+
+Bill vypočítá _RprivVpub = GRprivVpriv_, o kterém předpokládá, že ho zná i Alice (vysvětleno níže). Tato hodnota se nazývá _S_, sdílené tajemství. Tím Bill získá veřejný klíč, _Ppub = Kpub+G\*haš(S)_. Z tohoto veřejného klíče může vypočítat adresu a poslat na ni jakékoli zdroje, které chce. V budoucnu, pokud Alice vyhraje, může jí Bill sdělit _Rpriv_, aby dokázal, že zdroje pocházejí od něj.
+
+Alice vypočítá _RpubVpriv = GRprivVpriv_. Tím získá stejné sdílené tajemství, _S_. Protože zná privátní klíč, _Kpriv_, může vypočítat _Ppriv = Kpriv+haš(S)_. Tento klíč jí umožňuje přístup k aktivům na adrese, která je výsledkem _Ppub = GPpriv = GKpriv+G\*haš(S) = Kpub+G\*haš(S)_.
+
+Máme samostatný zobrazovací klíč, který Alici umožňuje zadat subdodávku službám Dave's World Domination Campaign Services. Alice je ochotna dát Davovi vědět veřejné adresy a informovat ji, až bude k dispozici více peněz, ale nechce, aby utrácel peníze z její kampaně.
+
+Protože prohlížení a utrácení používají samostatné klíče, může Alice dát Daveovi _Vpriv_. Potom může Dave vypočítat _S = RpubVpriv = GRprivVpriv_ a tímto způsobem získat veřejné klíče (_Ppub = Kpub+G\*haš(S)_). Ale bez _Kpriv_ nemůže Dave získat privátní klíč.
+
+Abychom to shrnuli, toto jsou hodnoty známé různým účastníkům.
+
+| Alice | Zveřejněno | Bill | Dave | |
+| ------------------------------------------------------------------------- | ----------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ---------------------------------------------- |
+| G | G | G | G | |
+| _Kpriv_ | – | – | – | |
+| _Vpriv_ | – | – | _Vpriv_ | |
+| _Kpub = GKpriv_ | _Kpub_ | _Kpub_ | _Kpub_ | |
+| _Vpub = GVpriv_ | _Vpub_ | _Vpub_ | _Vpub_ | |
+| – | – | _Rpriv_ | – | |
+| _Rpub_ | _Rpub_ | _Rpub = GRpriv_ | _Rpub_ | |
+| _S = RpubVpriv = GRprivVpriv_ | – | _S = RprivVpub = GRprivVpriv_ | _S = _RpubVpriv_ = GRprivVpriv_ | |
+| _Ppub = Kpub+G\*haš(S)_ | – | _Ppub = Kpub+G\*haš(S)_ | _Ppub = Kpub+G\*haš(S)_ | |
+| _Adresa=f(Ppub)_ | – | _Adresa=f(Ppub)_ | _Adresa=f(Ppub)_ | _Adresa=f(Ppub)_ |
+| _Ppriv = Kpriv+haš(S)_ | – | – | – | |
+
+## Když se skryté adresy pokazí {#go-wrong}
+
+_Na blockchainu neexistují žádná tajemství_. Zatímco skryté adresy vám mohou poskytnout soukromí, toto soukromí je náchylné k analýze provozu. Jako triviální příklad si představte, že Bill financuje adresu a okamžitě pošle transakci ke zveřejnění hodnoty _Rpub_. Bez Alicina _Vpriv_ si nemůžeme být jisti, že se jedná o skrytou adresu, ale je to nejpravděpodobnější. Potom vidíme další transakci, která převádí všechny ETH z této adresy na adresu fondu kampaně Alice. Možná to nebudeme schopni dokázat, ale je pravděpodobné, že Bill právě přispěl na kampaň Alice. Carol by si to určitě myslela.
+
+Pro Billa je snadné oddělit zveřejnění _Rpub_ od financování skryté adresy (udělat to v různých časech z různých adres). To je však nedostatečné. Vzor, který Carol hledá, je, že Bill financuje adresu a poté z ní fond kampaně Alice vybírá.
+
+Jedním řešením je, aby kampaň Alice peníze nevybírala přímo, ale použila je k zaplacení třetí straně. Pokud kampaň Alice pošle 10 ETH společnosti Dave's World Domination Campaign Services, Carol ví jen to, že Bill přispěl jednomu z Daveových zákazníků. Pokud má Dave dostatek zákazníků, Carol by nemohla vědět, zda Bill přispěl Alici, která s ní soupeří, nebo Adamovi, Albertovi či Abigail, o které se Carol nezajímá. Alice může k platbě přiložit hašovanou hodnotu a poté poskytnout Daveovi předobraz, aby dokázala, že to byl její dar. Alternativně, jak je uvedeno výše, pokud Alice dá Daveovi svůj _Vpriv_, už ví, od koho platba přišla.
+
+Hlavním problémem tohoto řešení je, že vyžaduje, aby Alice dbala na utajení, když toto utajení prospívá Billovi. Alice si možná bude chtít udržet svou pověst, aby jí přispěl i Billův přítel Bob. Ale je také možné, že by jí nevadilo Billa odhalit, protože by se pak bál, co se stane, když vyhraje Carol. Bill by mohl nakonec poskytnout Alici ještě větší podporu.
+
+### Použití více skrytých vrstev {#multi-layer}
+
+Místo spoléhání se na Alici, aby chránila Billovo soukromí, to může Bill udělat sám. Může generovat více meta-adres pro fiktivní osoby, Boba a Bellu. Bill poté pošle ETH Bobovi a „Bob“ (což je ve skutečnosti Bill) je pošle Belle. „Bella“ (také Bill) je pošle Alici.
+
+Carol může stále provádět analýzu provozu a vidět řetězec Bill-Bob-Bella-Alice. Pokud však „Bob“ a „Bella“ také používají ETH pro jiné účely, nebude se zdát, že Bill cokoli převedl Alici, i když Alice okamžitě vybere peníze ze skryté adresy na svou známou adresu kampaně.
+
+## Napsání aplikace se skrytými adresami {#write-app}
+
+Tento článek vysvětluje aplikaci se skrytými adresami [dostupnou na GitHubu](https://github.com/qbzzt/251022-stealth-addresses.git).
+
+### Nástroje {#tools}
+
+Existuje [typescriptová knihovna pro skryté adresy](https://github.com/ScopeLift/stealth-address-sdk), kterou bychom mohli použít. Kryptografické operace však mohou být náročné na CPU. Dávám přednost jejich implementaci v kompilovaném jazyce, jako je [Rust](https://rust-lang.org/), a použití [WASM](https://webassembly.org/) ke spuštění kódu v prohlížeči.
+
+Použijeme [Vite](https://vite.dev/) a [React](https://react.dev/). Jedná se o standardní nástroje v oboru; pokud je neznáte, můžete použít [tento tutoriál](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/). Pro použití Vite potřebujeme Node.
+
+### Podívejte se na skryté adresy v akci {#in-action}
+
+1. Nainstalujte si potřebné nástroje: [Rust](https://rust-lang.org/tools/install/) a [Node](https://nodejs.org/en/download).
+
+2. Naklonujte repozitář na GitHubu.
+
+ ```sh
+ git clone https://github.com/qbzzt/251022-stealth-addresses.git
+ cd 251022-stealth-addresses
+ ```
+
+3. Nainstalujte předpoklady a zkompilujte kód Rustu.
+
+ ```sh
+ cd src/rust-wasm
+ rustup target add wasm32-unknown-unknown
+ cargo install wasm-pack
+ wasm-pack build --target web
+ ```
+
+4. Spusťte webový server.
+
+ ```sh
+ cd ../..
+ npm install
+ npm run dev
+ ```
+
+5. Přejděte do [aplikace](http://localhost:5173/). Tato stránka aplikace má dva rámce: jeden pro uživatelské rozhraní Alice a druhý pro Billa. Tyto dva rámce spolu nekomunikují; jsou na stejné stránce pouze pro pohodlí.
+
+6. Jako Alice klikněte na **Generate a Stealth Meta-Address**. Zobrazí se nová skrytá adresa a odpovídající privátní klíče. Zkopírujte skrytou meta-adresu do schránky.
+
+7. Jako Bill vložte novou skrytou meta-adresu a klikněte na **Generate an address**. Tím získáte adresu pro financování Alice.
+
+8. Zkopírujte adresu a Billův veřejný klíč a vložte je do oblasti „Privátní klíč pro adresu generovanou Billem“ v uživatelském rozhraní Alice. Jakmile budou tato pole vyplněna, uvidíte privátní klíč pro přístup k aktivům na této adrese.
+
+9. Můžete použít [online kalkulačku](https://iancoleman.net/ethereum-private-key-to-address/), abyste se ujistili, že privátní klíč odpovídá adrese.
+
+### Jak program funguje {#how-the-program-works}
+
+#### Komponenta WASM {#wasm}
+
+Zdrojový kód, který se kompiluje do WASM, je napsán v [Rustu](https://rust-lang.org/). Můžete si ho prohlédnout v [`src/rust_wasm/src/lib.rs`](https://github.com/qbzzt/251022-stealth-addresses/blob/main/src/rust-wasm/src/lib.rs). Tento kód je primárně rozhraním mezi JavaScriptovým kódem a [knihovnou `eth-stealth-addresses`](https://github.com/kassandraoftroy/eth-stealth-addresses).
+
+**`Cargo.toml`**
+
+[`Cargo.toml`](https://doc.rust-lang.org/cargo/reference/manifest.html) v Rustu je obdobou [`package.json`](https://docs.npmjs.com/cli/v9/configuring-npm/package-json) v JavaScriptu. Obsahuje informace o balíčku, deklarace závislostí atd.
+
+```toml
+[package]
+name = "rust-wasm"
+version = "0.1.0"
+edition = "2024"
+
+[dependencies]
+eth-stealth-addresses = "0.1.0"
+hex = "0.4.3"
+wasm-bindgen = "0.2.104"
+getrandom = { version = "0.2", features = ["js"] }
+```
+
+Balíček [`getrandom`](https://docs.rs/getrandom/latest/getrandom/) potřebuje generovat náhodné hodnoty. Toho nelze dosáhnout čistě algoritmickými prostředky; vyžaduje to přístup k fyzickému procesu jako zdroji entropie. Tato definice určuje, že entropii získáme dotazem na prohlížeč, ve kterém běžíme.
+
+```toml
+console_error_panic_hook = "0.1.7"
+```
+
+[Tato knihovna](https://docs.rs/console_error_panic_hook/latest/console_error_panic_hook/) nám poskytuje smysluplnější chybové zprávy, když kód WASM zpanikaří a nemůže pokračovat.
+
+```toml
+[lib]
+crate-type = ["cdylib", "rlib"]
+```
+
+Výstupní typ potřebný k vytvoření kódu WASM.
+
+**`lib.rs`**
+
+Toto je skutečný kód Rustu.
+
+```rust
+use wasm_bindgen::prelude::*;
+```
+
+Definice pro vytvoření balíčku WASM z Rustu. Jsou zdokumentovány [zde](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/index.html).
+
+```rust
+use eth_stealth_addresses::{
+ generate_stealth_meta_address,
+ generate_stealth_address,
+ compute_stealth_key
+};
+```
+
+Funkce, které potřebujeme z [knihovny `eth-stealth-addresses`](https://github.com/kassandraoftroy/eth-stealth-addresses).
+
+```rust
+use hex::{decode,encode};
+```
+
+Rust typicky používá pro hodnoty bajtová [pole](https://doc.rust-lang.org/std/primitive.array.html) (`[u8; ]`). Ale v JavaScriptu obvykle používáme hexadecimální řetězce. [Knihovna `hex`](https://docs.rs/hex/latest/hex/) nám překládá z jedné reprezentace do druhé.
+
+```rust
+#[wasm_bindgen]
+```
+
+Vygenerujte vazby WASM, aby bylo možné tuto funkci volat z JavaScriptu.
+
+```rust
+pub fn wasm_generate_stealth_meta_address() -> String {
+```
+
+Nejjednodušší způsob, jak vrátit objekt s více poli, je vrátit řetězec JSON.
+
+```rust
+ let (address, spend_private_key, view_private_key) =
+ generate_stealth_meta_address();
+```
+
+[`generate_stealth_meta_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_meta_address.html) vrací tři pole:
+
+- Meta-adresa (_Kpub_ a _Vpub_)
+- Zobrazovací privátní klíč (_Vpriv_)
+- Privátní klíč pro útratu (_Kpriv_)
+
+Syntaxe [n-tice](https://doc.rust-lang.org/std/primitive.tuple.html) nám umožňuje tyto hodnoty opět oddělit.
+
+```rust
+ format!("{{\"address\":\"{}\",\"view_private_key\":\"{}\",\"spend_private_key\":\"{}\"}}",
+ encode(address),
+ encode(view_private_key),
+ encode(spend_private_key)
+ )
+}
+```
+
+Použijte makro [`format!`](https://doc.rust-lang.org/std/fmt/index.html) k vygenerování řetězce kódovaného ve formátu JSON. Použijte [`hex::encode`](https://docs.rs/hex/latest/hex/fn.encode.html) ke změně polí na hexadecimální řetězce.
+
+```rust
+fn str_to_array(s: &str) -> Option<[u8; N]> {
+```
+
+Tato funkce převede hexadecimální řetězec (poskytnutý JavaScriptem) na pole bajtů. Používáme ji k analýze hodnot poskytnutých JavaScriptovým kódem. Tato funkce je komplikovaná kvůli tomu, jak Rust zpracovává pole a vektory.
+
+Výraz `` se nazývá [generikum](https://doc.rust-lang.org/book/ch10-01-syntax.html). `N` je parametr, který řídí délku vráceného pole. Funkce se ve skutečnosti volá jako `str_to_array::`, kde `n` je délka pole.
+
+Návratová hodnota je `Option<[u8; N]>`, což znamená, že vrácené pole je [volitelné](https://doc.rust-lang.org/std/option/). Toto je typický vzor v Rustu pro funkce, které mohou selhat.
+
+Například, pokud zavoláme `str_to_array::10("bad060a7")`, funkce má vrátit pole s deseti hodnotami, ale vstup má pouze čtyři bajty. Funkce musí selhat, a to tak, že vrátí `None`. Návratová hodnota pro `str_to_array::4("bad060a7")` by byla `Some<[0xba, 0xd0, 0x60, 0xa7]>`.
+
+```rust
+ // decode vrací Result, _>
+ let vec = decode(s).ok()?;
+```
+
+Funkce [`hex::decode`](https://docs.rs/hex/latest/hex/fn.decode.html) vrací `Result, FromHexError>`. Typ [`Result`](https://doc.rust-lang.org/std/result/) může obsahovat buď úspěšný výsledek (`Ok(value)`), nebo chybu (`Err(error)`).
+
+Metoda `.ok()` převede `Result` na `Option`, jehož hodnota je buď hodnota `Ok()` v případě úspěchu, nebo `None` v opačném případě. Nakonec [operátor otazníku](https://doc.rust-lang.org/std/option/#the-question-mark-operator-) přeruší aktuální funkci a vrátí `None`, pokud je `Option` prázdný. V opačném případě hodnotu rozbalí a vrátí ji (v tomto případě pro přiřazení hodnoty `vec`).
+
+Vypadá to jako zvláštně spletitá metoda pro zpracování chyb, ale `Result` a `Option` zajišťují, že všechny chyby jsou tak či onak zpracovány.
+
+```rust
+ if vec.len() != N { return None; }
+```
+
+Pokud je počet bajtů nesprávný, jedná se o selhání a vrátíme `None`.
+
+```rust
+ // try_into spotřebuje vec a pokusí se vytvořit [u8; N]
+ let array: [u8; N] = vec.try_into().ok()?;
+```
+
+Rust má dva typy polí. [Pole](https://doc.rust-lang.org/std/primitive.array.html) mají pevnou velikost. [Vektory](https://doc.rust-lang.org/std/vec/index.html) se mohou zvětšovat a zmenšovat. `hex::decode` vrací vektor, ale knihovna `eth_stealth_addresses` chce přijímat pole. [`.try_into()`](https://doc.rust-lang.org/std/convert/trait.TryInto.html#required-methods) převádí hodnotu na jiný typ, například vektor na pole.
+
+```rust
+ Some(array)
+}
+```
+
+Rust nevyžaduje použití klíčového slova [`return`](https://doc.rust-lang.org/std/keyword.return.html) při vracení hodnoty na konci funkce.
+
+```rust
+#[wasm_bindgen]
+pub fn wasm_generate_stealth_address(stealth_address: &str) -> Option {
+```
+
+Tato funkce přijímá veřejnou meta-adresu, která obsahuje jak _Vpub_, tak _Kpub_. Vrací skrytou adresu, veřejný klíč k publikování (_Rpub_) a jednobajtovou skenovací hodnotu, která urychluje identifikaci toho, které publikované adresy mohou patřit Alici.
+
+Skenovací hodnota je součástí sdíleného tajemství (_S = GRprivVpriv_). Tato hodnota je k dispozici Alici a její kontrola je mnohem rychlejší než kontrola, zda se _f(Kpub+G\*haš(S))_ rovná publikované adrese.
+
+```rust
+ let (address, r_pub, scan) =
+ generate_stealth_address(&str_to_array::<66>(stealth_address)?);
+```
+
+Používáme [`generate_stealth_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_address.html) z knihovny.
+
+```rust
+ format!("{{\"address\":\"{}\",\"rPub\":\"{}\",\"scan\":\"{}\"}}",
+ encode(address),
+ encode(r_pub),
+ encode(&[scan])
+ ).into()
+}
+```
+
+Připravte výstupní řetězec kódovaný ve formátu JSON.
+
+```rust
+#[wasm_bindgen]
+pub fn wasm_compute_stealth_key(
+ address: &str,
+ bill_pub_key: &str,
+ view_private_key: &str,
+ spend_private_key: &str
+) -> Option {
+ .
+ .
+ .
+}
+```
+
+Tato funkce používá [`compute_stealth_key`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.compute_stealth_key.html) z knihovny k výpočtu privátního klíče pro výběr z adresy (_Rpriv_). Tento výpočet vyžaduje tyto hodnoty:
+
+- Adresa (_Adresa=f(Ppub)_)
+- Veřejný klíč vygenerovaný Billem (_Rpub_)
+- Privátní klíč pro zobrazení (_Vpriv_)
+- Privátní klíč pro útratu (_Kpriv_)
+
+```rust
+#[wasm_bindgen(start)]
+```
+
+[`#[wasm_bindgen(start)]`](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/on-rust-exports/start.html) určuje, že funkce se provede při inicializaci kódu WASM.
+
+```rust
+pub fn main() {
+ console_error_panic_hook::set_once();
+}
+```
+
+Tento kód určuje, že výstup paniky se pošle do konzole JavaScriptu. Abyste to viděli v akci, použijte aplikaci a dejte Billovi neplatnou meta-adresu (stačí změnit jednu hexadecimální číslici). V konzoli JavaScriptu uvidíte tuto chybu:
+
+```
+rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/subtle-2.6.1/src/lib.rs:701:9:
+assertion `left == right` failed
+ left: 0
+ right: 1
+```
+
+Následuje výpis zásobníku. Poté dejte Billovi platnou meta-adresu a Alici buď neplatnou adresu, nebo neplatný veřejný klíč. Zobrazí se tato chyba:
+
+```
+rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/eth-stealth-addresses-0.1.0/src/lib.rs:78:9:
+klíče negenerují skrytou adresu
+```
+
+Opět následuje výpis zásobníku.
+
+#### Uživatelské rozhraní {#ui}
+
+Uživatelské rozhraní je napsáno pomocí [Reactu](https://react.dev/) a obsluhováno pomocí [Vite](https://vite.dev/). Můžete se o nich dozvědět pomocí [tohoto tutoriálu](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/). Zde není potřeba [WAGMI](https://wagmi.sh/), protože neinteragujeme přímo s blockchainem ani s peněženkou.
+
+Jedinou ne zcela zřejmou částí uživatelského rozhraní je připojení WASM. Funguje to takto.
+
+**`vite.config.js`**
+
+Tento soubor obsahuje [konfiguraci Vite](https://vite.dev/config/).
+
+```js
+import { defineConfig } from 'vite'
+import react from '@vitejs/plugin-react'
+import wasm from "vite-plugin-wasm";
+
+// https://vite.dev/config/
+export default defineConfig({
+ plugins: [react(), wasm()],
+})
+```
+
+Potřebujeme dva pluginy Vite: [react](https://www.npmjs.com/package/@vitejs/plugin-react) a [wasm](https://github.com/Menci/vite-plugin-wasm#readme).
+
+**`App.jsx`**
+
+Tento soubor je hlavní komponentou aplikace. Je to kontejner, který obsahuje dvě komponenty: `Alice` a `Bill`, uživatelská rozhraní pro tyto uživatele. Relevantní částí pro WASM je inicializační kód.
+
+```jsx
+import init from './rust-wasm/pkg/rust_wasm.js'
+```
+
+Když používáme [`wasm-pack`](https://rustwasm.github.io/docs/wasm-pack/), vytvoří se dva soubory, které zde používáme: soubor wasm se skutečným kódem (zde `src/rust-wasm/pkg/rust_wasm_bg.wasm`) a soubor JavaScript s definicemi pro jeho použití (zde `src/rust_wasm/pkg/rust_wasm.js`). Výchozí export tohoto souboru JavaScript je kód, který se musí spustit pro inicializaci WASM.
+
+```jsx
+function App() {
+ .
+ .
+ .
+ useEffect(() => {
+ const loadWasm = async () => {
+ try {
+ await init();
+ setWasmReady(true)
+ } catch (err) {
+ console.error('Chyba při načítání wasm:', err)
+ alert("Wasm error: " + err)
+ }
+ }
+
+ loadWasm()
+ }, []
+ )
+```
+
+[Hook `useEffect`](https://react.dev/reference/react/useEffect) umožňuje určit funkci, která se spustí při změně proměnných stavu. Zde je seznam proměnných stavu prázdný (`[]`), takže tato funkce se provede pouze jednou při načtení stránky.
+
+Funkce efektu se musí okamžitě vrátit. Pro použití asynchronního kódu, jako je `init` WASM (který musí načíst soubor `.wasm`, a proto to trvá), definujeme interní funkci [`async`](https://en.wikipedia.org/wiki/Async/await) a spustíme ji bez `await`.
+
+**`Bill.jsx`**
+
+Toto je uživatelské rozhraní pro Billa. Má jednu akci, vytvoření adresy na základě skryté meta-adresy poskytnuté Alicí.
+
+```jsx
+import { wasm_generate_stealth_address } from './rust-wasm/pkg/rust_wasm.js'
+```
+
+Kromě výchozího exportu exportuje JavaScriptový kód generovaný `wasm-pack` funkci pro každou funkci v kódu WASM.
+
+```jsx
+
-## Další informace {#further-reading}
+## Další čtení {#further-reading}
- [Cambridge Blockchain Network Sustainability Index](https://ccaf.io/cbnsi/ethereum)
-- [Zpráva Bílého domu o blockchainech důkazu prací](https://web.archive.org/web/20221109005700/https://www.whitehouse.gov/wp-content/uploads/2022/09/09-2022-Crypto-Assets-and-Climate-Report.pdf)
-- [Emise Etherea: Souhrnný odhad](https://kylemcdonald.github.io/ethereum-emissions/) - _Kyle McDonald_
-- [Ethereum Energy Consumption Index](https://digiconomist.net/ethereum-energy-consumption/) - _Digiconomist_
-- [ETHMerge.com](https://ethmerge.com/) - _[@InsideTheSim](https://twitter.com/InsideTheSim)_
-- [Merge - Dopady na spotřebu elektřiny a uhlíkovou stopu sítě Ethereum](https://carbon-ratings.com/eth-report-2022) - _CCRI_
+- [Zpráva Bílého domu o blockchainech s důkazem prací](https://web.archive.org/web/20221109005700/https://www.whitehouse.gov/wp-content/uploads/2022/09/09-2022-Crypto-Assets-and-Climate-Report.pdf)
+- [Emise Etherea: Odhad zdola nahoru](https://kylemcdonald.github.io/ethereum-emissions/) – _Kyle McDonald_
+- [Index spotřeby energie Etherea](https://digiconomist.net/ethereum-energy-consumption/) – _Digiconomist_
+- [ETHMerge.com](https://ethmerge.com/) – _[@InsideTheSim](https://twitter.com/InsideTheSim)_
+- [Sloučení – Dopady na spotřebu elektřiny a uhlíkovou stopu sítě Ethereum](https://carbon-ratings.com/eth-report-2022) – _CCRI_
- [Spotřeba energie Etherea](https://mirror.xyz/jmcook.eth/ODpCLtO4Kq7SCVFbU4He8o8kXs418ZZDTj0lpYlZkR8)
## Související témata {#related-topics}
-- [Vize Etherea](/roadmap/vision/)
-- [Beacon chain](/roadmap/beacon-chain)
+- [Beacon Chain](/roadmap/beacon-chain)
- [Sloučení](/roadmap/merge/)
diff --git a/public/content/translations/cs/eth/supply/index.md b/public/content/translations/cs/eth/supply/index.md
new file mode 100644
index 00000000000..4b9c40dcac0
--- /dev/null
+++ b/public/content/translations/cs/eth/supply/index.md
@@ -0,0 +1,80 @@
+---
+title: Pochopení nabídky a emise ETH
+description: Uživatelsky přívětivý průvodce nabídkou a vydáváním ETH, pokrývající klíčové koncepty jako EIP, PoS a EIP-1559.
+lang: cs
+---
+
+# Nabídka a emise ETH {#eth-supply-and-issuance}
+
+## Předpoklady {#prerequisites}
+
+Tento článek je napsán pro začátečníky bez předchozích znalostí. Pro plné pochopení tématu je však užitečné mít základní povědomí o pojmech, jako jsou [návrhy na vylepšení Etherea (EIPs)](/eips/#introduction-to-ethereum-improvement-proposals), [důkaz prací (PoW)](/developers/docs/consensus-mechanisms/pow/), [důkaz podílem (PoS)](/developers/docs/consensus-mechanisms/pos/) a [londýnský upgrade](/ethereum-forks/#london).
+
+## Kolik ETH tokenů dnes existuje? {#current-eth-supply}
+
+Celková nabídka ETH je dynamická a kvůli dvěma hlavním faktorům se neustále mění:
+
+1. **Emise v Proof-of-Stake (PoS)**: Nové ETH jsou vytvářeny jako odměna pro validátory, kteří zabezpečují síť
+2. **Spalování dle EIP-1559**: Část transakčních poplatků je trvale odstraněna z oběhu
+
+Aktuální nabídku a tyto změny můžete sledovat v reálném čase na platformách jako [Ultrasound Money](https://ultrasound.money).
+
+Nabídka a emise Etherea jsou klíčovými ukazateli pro pochopení zdraví a budoucnosti sítě. Ale co přesně znamená emise ETH? Pojďme si to vysvětlit.
+
+## Proč na nabídce a vydávání ETH záleží {#why-eth-supply-matters}
+
+V tradičním finančnictví ovládají nabídku peněz centrální banky, často tisknou další peníze za účelem podpory ekonomik. Ethereum naproti tomu funguje na transparentním a předvídatelném systému řízeném jeho kódem. Znalost toho, kolik ETH existuje a jak rychle se vydává nové, pomáhá:
+
+- **Budovat důvěru**: Komunita Etherea si může ověřit údaje o nabídce a emisích přímo z blockchainu.
+- **Pochopit hodnotu**: Vztah mezi vydáváním a spalováním ETH ovlivňuje inflaci či deflaci ETH, a tím i jeho hodnotu v čase.
+- **Sledovat zdraví sítě**: Změny ve vydávání a spalování odrážejí aktivitu a bezpečnost sítě.
+
+## Co je to vydávání ETH? {#eth-issuance}
+
+Vydávání ETH označuje proces vytváření nového ETH jako odměn pro validátory, kteří zabezpečují síť Ethereum. To je odděleno od celkové nabídky, což je celkové množství ETH v oběhu.
+
+### Zjednodušeně:
+
+- **Vydávání** přidává nové ETH do sítě.
+- **Spalování** (zavedeno EIP-1559) odstraňuje ETH ze sítě tím, že ničí část transakčních poplatků.
+
+Tyto dvě síly společně určují, zda nabídka Etherea časem roste (je inflační), nebo klesá (je deflační).
+
+## Nabídka a vydávání ETH dnes {#eth-supply-today}
+
+Systém Proof-of-Stake (PoS) v Ethereu výrazně snížil emisi nových ETH oproti dřívějšímu modelu Proof-of-Work (PoW). Validátoři – kteří uzamykají ETH, aby zabezpečili síť – dostávají ETH jako odměny. Aktuální míru vydávání můžete sledovat na stránce [Ultrasound Money](https://ultrasound.money).
+
+Tento údaj je však dynamický. Díky EIP-1559 může v obdobích vysoké aktivity spalování ETH převýšit vydávání a vytvořit deflační efekt. Například během období vysoké poptávky, jako jsou spuštění NFT nebo aktivita v DeFi, se může spálit více ETH, než se vydá.
+
+### Nástroje pro sledování nabídky a vydávání ETH:
+
+- [Ultrasound Money](https://ultrasound.money) – sledování nabídky, vydávání a spalování ETH v reálném čase
+- [Etherscan](https://etherscan.io) – blockchainový průzkumník s metrikami nabídky
+
+## Faktory ovlivňující budoucí nabídku a vydávání ETH {#future-eth-supply}
+
+Budoucí nabídka Etherea není neměnná - závisí na několika proměnných:
+
+1. **Účast na stakingu**:
+ - Více validátorů znamená více distribuovaných odměn a tím pádem vyšší emise.
+ - Méně validátorů může znamenat nižší emise.
+ - Další informace o stakingu(/staking/).
+
+2. **Aktivita sítě**:
+ - Vyšší objemy transakcí vedou ke spálění většího počtu ETH, což může vyrovnat nebo převýšit vydávání.
+ - Přečtěte si o [transakčních poplatcích](/developers/docs/gas/) a jejich vlivu na spalování.
+
+3. **Vylepšení protokolu**:
+ - Budoucí změny kódu Etherea mohou upravit odměny za staking nebo mechanismy spalování a tím dále ovlivnit nabídku.
+ - Sledujte [plány na vývoj Etherea](/roadmap/).
+
+## Shrnutí: Nabídka ETH, vydávání a co nás čeká {#recap}
+
+Zde je rychlý souhrn všeho, co potřebujete vědět o nabídce a vydávání ETH:
+
+- **Nabídka ETH**: Dynamická a neustále se měnící, sledovatelná v reálném čase pomocí nástrojů jako [Ultrasound Money](https://ultrasound.money)
+- **Vydávání v PoS**: Výrazně snížené oproti PoW, odměny získávají validátoři. Aktuální míru vydávání sledujte na stránce [Ultrasound Money](https://ultrasound.money)
+- **Role EIP-1559**: Spalování ETH může při vysoké aktivitě způsobit deflaci sítě
+- **Budoucí trendy**: Účast na stakingu, síťová aktivita a vylepšení protokolu budou formovat nabídku ETH
+
+Porozumění vydávání ETH pomáhá odhalit hodnotu Etherea a jeho potenciál jako deflačního, decentralizovaného aktiva. Pro podrobnější informace o tom, jak Sloučení ovlivnilo nabídku ETH, si přečtěte náš [detailní rozbor](/roadmap/merge/issuance/). Zajímá vás budoucnost ETH? Prozkoumejte nástroje jako [Ultrasound Money](https://ultrasound.money) nebo našeho [průvodce stakingem](/staking/).
\ No newline at end of file
diff --git a/public/content/translations/cs/ethereum-forks/index.md b/public/content/translations/cs/ethereum-forks/index.md
new file mode 100644
index 00000000000..0c51fdf4211
--- /dev/null
+++ b/public/content/translations/cs/ethereum-forks/index.md
@@ -0,0 +1,681 @@
+---
+title: Časová osa všech větví sítě Ethereum (2014 až současnost)
+description: Historie blockchainu Etherea zahrnující hlavní milníky, verze a větve.
+lang: cs
+sidebarDepth: 1
+---
+
+# Časová osa všech větví sítě Ethereum (2014 až současnost) {#the-history-of-ethereum}
+
+Časová osa všech hlavních milníků, větví a aktualizací blockchainu Etherea.
+
+
+
+Větve se tvoří, když je třeba provést zásadní technické upgrady nebo změny sítě – obvykle vycházejí z [návrhů na zlepšení Etherea (EIP)](/eips/) a mění „pravidla“ protokolu.
+
+Když je potřeba upgradovat tradiční, centrálně řízený software, společnost pro koncové uživatele jednoduše vydá novou verzi. Blockchainy fungují jinak, protože neexistuje žádné centrální vlastnictví. [Klienti Etherea](/developers/docs/nodes-and-clients/) musí aktualizovat svůj software, aby implementovali nová pravidla větve. Navíc tvůrci bloků (těžaři ve světě důkazu prací, validátoři ve světě důkazu podílem) a uzly musí vytvářet bloky a ověřovat je podle nových pravidel. [Více o mechanismech konsensu](/developers/docs/consensus-mechanisms/)
+
+Tyto změny pravidel mohou v síti způsobit dočasné rozdělení. Nové bloky by mohly být vytvářeny podle nových nebo starých pravidel. Větve jsou obvykle odsouhlaseny předem, aby klienti přijali změny jednotně a větev s upgrady se stala hlavním řetězcem. Ve vzácných případech však mohou neshody ohledně větví způsobit trvalé rozdělení sítě – nejznámějším příkladem je vytvoření sítě Ethereum Classic pomocí větve DAO.
+
+
+
+
+
+Software, na kterém Ethereum funguje, se skládá ze dvou polovin, známých jako [exekuční vrstva](/glossary/#execution-layer) a [konsensuální vrstva](/glossary/#consensus-layer).
+
+**Pojmenování upgradů exekuční vrstvy**
+
+Od roku 2021 jsou upgrady **exekuční vrstvy** pojmenovávány podle názvů měst, kde se v minulosti konal [Devcon](https://devcon.org/en/past-events/), v chronologickém pořadí:
+
+| Název upgradu | Rok konání Devconu | Číslo Devconu | Datum upgradu |
+| ------------- | ------------------ | ------------- | -------------------------------------- |
+| Berlin | 2014 | 0 | 15. dubna 2021 |
+| London | 2015 | I | 5. srpna 2021 |
+| Shanghai | 2016 | II | 12. dubna 2023 |
+| Cancun | 2017 | III | 13. března 2024 |
+| **Prague** | 2018 | IV | Bude určeno – příští |
+| _Osaka_ | 2019 | V | Bude určeno |
+| _Bogota_ | 2022 | VI | Bude určeno |
+| _Bangkok_ | 2024 | VII | Bude určeno |
+
+**Pojmenování upgradů konsensuální vrstvy**
+
+Od spuštění řetězce [Beacon Chain](/glossary/#beacon-chain) jsou upgrady **konsensuální vrstvy** pojmenovávány podle hvězd, jejichž počáteční písmena následují v abecedním pořadí:
+
+| Název upgradu | Datum upgradu |
+| --------------------------------------------------------------- | --------------------------------------- |
+| Geneze Beacon Chainu | 1. prosince 2020 |
+| [Altair](https://cs.wikipedia.org/wiki/Altair) | 27. října 2021 |
+| [Bellatrix](https://cs.wikipedia.org/wiki/Bellatrix) | 6. září 2022 |
+| [Capella](https://cs.wikipedia.org/wiki/Capella) | 12. dubna 2023 |
+| [Deneb](https://cs.wikipedia.org/wiki/Deneb) | 13. března 2024 |
+| [**Electra**](https://cs.wikipedia.org/wiki/Elektra_\(hvězda\)) | Bude určeno – příští |
+| [_Fulu_](https://en.wikipedia.org/wiki/Fulu_\(star\)) | Bude určeno |
+
+**Kombinované pojmenování**
+
+Upgrady exekuční a konsensuální vrstvy byly zpočátku zaváděny v různou dobu, ale po [sloučení (The Merge)](/roadmap/merge/) v roce 2022 jsou nasazovány současně. Proto se objevily hovorové termíny, které zjednodušují odkazy na tyto upgrady pomocí jediného spojeného výrazu. Začalo to upgradem _Shanghai-Capella_, běžně označovaným jako „**Shapella**“, a pokračuje upgrady _Cancun-Deneb_ (**Dencun**) a _Prague-Electra_ (**Pectra**).
+
+| Upgrade exekuční vrstvy | Upgrade konsensuální vrstvy | Zkratka |
+| ----------------------- | --------------------------- | ---------- |
+| Shanghai | Capella | „Shapella“ |
+| Cancun | Deneb | „Dencun“ |
+| Prague | Electra | „Pectra“ |
+| Osaka | Fulu | „Fusaka“ |
+
+
+
+Přejít rovnou k informacím o některých obzvláště důležitých minulých upgradech: [Beacon Chain](/roadmap/beacon-chain/), [sloučení (The Merge)](/roadmap/merge/) a [EIP-1559](#london)
+
+Hledáte budoucí upgrady protokolu? [Zjistěte více o nadcházejících upgradech v plánu rozvoje sítě Ethereum](/roadmap/).
+
+
+
+Lepší uživatelská zkušenost:
+
+
+ - EIP-7702 – nastavení kódu účtu EOA
+ - EIP-7691 – zvýšení propustnosti blobů
+ - EIP-7623 – zvýšení ceny za calldata
+ - EIP-7840 – přidání plánu blobů do konfiguračních souborů EL
+
+
+Lepší zkušenost se stakingem:
+
+
+
+Zlepšení efektivity a zabezpečení protokolu:
+
+
+
+
+
+- [Pectra.wtf](https://pectra.wtf)
+- [Jak Pectra vylepší zážitek ze stakingu](https://www.kiln.fi/post/next-ethereum-upgrade-how-pectra-will-enhance-the-staking-experience)
+- [Přečtěte si specifikace upgradu Electra](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/)
+- [Často kladené otázky k Prague-Electra („Pectra“)](/roadmap/pectra/)
+
+
+
+
+
+
+
+- [Rollupy 2. vrstvy](/layer-2/)
+- [Proto-Danksharding](/roadmap/scaling/#proto-danksharding)
+- [Danksharding](/roadmap/danksharding/)
+- [Přečtěte si specifikace upgradu Cancun](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md)
+
+#### Shrnutí upgradu Deneb {#deneb-summary}
+
+Upgrade Deneb obsahuje sadu vylepšení _konsensu_ sítě Ethereum zaměřených na zlepšení škálovatelnosti. Tento upgrade přichází společně s upgrady exekuční vrstvy Cancun, aby se umožnil Proto-Danksharding (EIP-4844), spolu s dalšími vylepšeními Beacon Chainu.
+
+Předem vygenerované podepsané „dobrovolné zprávy o odchodu“ již nemají platnost, což dává větší kontrolu uživatelům stakujícím své prostředky u provozovatele uzlu třetí strany. S touto podepsanou zprávou o odchodu mohou stakeři delegovat provoz uzlu a zároveň si zachovat schopnost kdykoli bezpečně odejít a vybrat své prostředky, aniž by museli někoho žádat o svolení.
+
+EIP-7514 zpřísňuje vydávání ETH tím, že omezuje „churn“ míru, s níž se validátoři mohou připojit k síti, na osm (8) za epochu. Protože je vydávání ETH úměrné celkovému stakovanému množství ETH, omezení počtu připojujících se validátorů omezuje _rychlost růstu_ nově vydávaných ETH a zároveň snižuje hardwarové nároky na provozovatele uzlů, což napomáhá decentralizaci.
+
+
+
+
+
+
+
+- [Přečtěte si specifikace upgradu Deneb](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/)
+- [Často kladené otázky k Cancun-Deneb („Dencun“)](/roadmap/dencun/)
+
+
+
+
+
+
+
+- [Přečtěte si specifikace upgradu Shanghai](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md)
+
+#### Shrnutí upgradu Capella {#capella-summary}
+
+Upgrade Capella byl třetím velkým upgradem konsensuální vrstvy (Beacon Chain) a umožnil výběry ze stakingu. Capella proběhla synchronně s upgradem exekuční vrstvy, Shanghai, a umožnila funkcionalitu výběru ze stakingu.
+
+Tento upgrade konsensuální vrstvy přinesl stakerům, kteří při svém počátečním vkladu neposkytli přihlašovací údaje pro výběr, možnost tak učinit, čímž se výběry umožnily.
+
+Upgrade také poskytl funkci automatického „sweeping“ účtů, která nepřetržitě zpracovává účty validátorů pro jakékoli dostupné platby odměn nebo úplné výběry.
+
+- [Více o výběrech ze stakingu](/staking/withdrawals/).
+- [Přečtěte si specifikace upgradu Capella](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/)
+
+
+
+
+
+
+
+---
+
+### Bellatrix {#bellatrix}
+
+
+
+
+ - EIP-5133 – odkládá bombu obtížnosti do září 2022
+
+
+
+
+
+
+
+ - EIP-4345 – odkládá bombu obtížnosti do června 2022
+
+
+
+
+---
+
+### Altair {#altair}
+
+
+
+
+
+
+
+---
+
+### Berlin {#berlin}
+
+
+
+
+
+
+
+
+ Řetězová vazba
+
+
+---
+
+### Nasazen vkladový kontrakt pro staking {#staking-deposit-contract}
+
+
+ Staking
+
+
+---
+
+### Muir Glacier {#muir-glacier}
+
+
+
+
+ - EIP-2384 – odkládá bombu obtížnosti o dalších 4 000 000 bloků, tj. o ~611 dní.
+
+
+
+
+
+
+
+ - EIP-152 – umožňuje, aby Ethereum pracovalo s měnou Zcash, která chrání soukromí.
+ - EIP-1108 – levnější kryptografie pro snížení nákladů na [transakční poplatky](/glossary/#gas).
+ - EIP-1344 – chrání Ethereum před útoky přehráním přidáním [operačního kódu](/developers/docs/ethereum-stack/#ethereum-virtual-machine)
CHAINID.
+ - EIP-1884 – optimalizace cen za transakční poplatky u operačních kódů na základě spotřeby.
+ - EIP-2028 – snižuje náklady na CallData, aby se do bloků vešlo více dat – což je dobré pro [škálování 2. vrstvy](/developers/docs/scaling/#layer-2-scaling).
+ - EIP-2200 – další změny cen za transakční poplatky u operačních kódů.
+
+
+
+
+---
+
+### Constantinople {#constantinople}
+
+
+
+
+ - EIP-145 – optimalizuje náklady na určité on-chain akce.
+ - EIP-1014 – umožňuje interakci s adresami, které teprve budou vytvořeny.
+ - EIP-1052 – zavádí instrukci
EXTCODEHASH pro získání haše kódu jiného kontraktu.
+ - EIP-1234 – zajišťuje, aby blockchain nezamrzl před proof-of-stake, a snižuje odměnu za blok z 3 na 2 ETH.
+
+
+
+
+
+
+
+ - EIP-140 – přidává operační kód
REVERT.
+ - EIP-658 – do potvrzení transakce bylo přidáno pole stavu, které udává úspěch nebo neúspěch.
+ - EIP-196 – přidává eliptickou křivku a skalární násobení pro umožnění [ZK-Snarks](/developers/docs/scaling/zk-rollups/).
+ - EIP-197 – přidává eliptickou křivku a skalární násobení pro umožnění [ZK-Snarks](/developers/docs/scaling/zk-rollups/).
+ - EIP-198 – umožňuje ověřování podpisu RSA.
+ - EIP-211 – přidává podporu pro návratové hodnoty s proměnnou délkou.
+ - EIP-214 – přidává operační kód
STATICCALL, který umožňuje volání jiných kontraktů, která nemění stav.
+ - EIP-100 – mění vzorec pro úpravu obtížnosti.
+ - EIP-649 – odkládá [bombu obtížnosti](/glossary/#difficulty-bomb) o 1 rok a snižuje odměnu za blok z 5 na 3 ETH.
+
+
+
+
+
+
+
+ - EIP-155 – zabraňuje tomu, aby transakce z jednoho řetězce Ethereum byly znovu vysílány na alternativním řetězci, například aby transakce z testnetu byla přehrána na hlavním řetězci Ethereum.
+ - EIP-160 – upravuje ceny operačního kódu
EXP – ztěžuje zpomalení sítě prostřednictvím výpočetně náročných operací kontraktu.
+ - EIP-161 – umožňuje odstranění prázdných účtů přidaných prostřednictvím útoků DOS.
+ - EIP-170 – mění maximální velikost kódu, kterou může mít kontrakt na blockchainu, na 24 576 bajtů.
+
+
+
+
+---
+
+### Tangerine Whistle {#tangerine-whistle}
+
+
+
+
+
+
+
+---
+
+### Větev DAO {#dao-fork}
+
+
+
+
+
+
+
+
+ Bílá kniha
+
diff --git a/public/content/translations/cs/foundation/index.md b/public/content/translations/cs/foundation/index.md
index ee04c056a03..6721c3b8e6e 100644
--- a/public/content/translations/cs/foundation/index.md
+++ b/public/content/translations/cs/foundation/index.md
@@ -1,40 +1,33 @@
---
-title: Ethereum Foundation
+title: Nadace Ethereum
description: Zjistěte více o Nadaci Ethereum (Ethereum Foundation, EF), neziskové organizaci, která se věnuje podpoře Etherea a souvisejících technologií.
hideEditButton: true
lang: cs
---
-# O Nadaci Ethereum {#about-the-ethereum-foundation}
+# Nadace Ethereum {#ethereum-foundation}
-
-Další informace o nadaci a její práci naleznete na [ethereum.foundation](http://ethereum.foundation/), nebo se podívejte na [Blog Ethereum Foundation](https://blog.ethereum.org/), kde najdete nejnovější zprávy a oznámení od nadace EF.
+- [ethereum.foundation](https://ethereum.foundation/) – Oficiální webové stránky EF
+- [Blog EF](https://blog.ethereum.org/) – Novinky a oznámení
+- [Program na podporu ekosystému](https://esp.ethereum.foundation/) – Granty a podpora
diff --git a/public/content/translations/cs/gaming/index.md b/public/content/translations/cs/gaming/index.md
new file mode 100644
index 00000000000..3ebf0f5f8ef
--- /dev/null
+++ b/public/content/translations/cs/gaming/index.md
@@ -0,0 +1,70 @@
+---
+title: Hraní na blockchainu
+lang: cs
+template: use-cases
+image: /images/robot-help-bar.png
+sidebarDepth: 2
+summaryPoint1: Pravidla a stav hry mohou být vynucována blockchainem, nikoli servery studia.
+summaryPoint2: Kdokoli může vytvářet módy, boty nebo zcela nové hry, které se připojují ke stejným onchain datům.
+summaryPoint3: Účelové L2, jako je Redstone, a frameworky jako MUD, snižují náklady natolik, aby podporovaly hraní v reálném čase.
+buttons:
+ - content: Další informace
+ toId: how-gaming-on-ethereum-works
+ - content: Prozkoumat aplikace
+ toId: popular-games-built-on-ethereum
+ isSecondary: false
+---
+
+## Jak funguje hraní na Ethereu {#how-gaming-on-ethereum-works}
+
+Hraní na Ethereu má různé podoby, od her, které integrují blockchain pro specifické funkce, až po ty, kde celý herní svět žije na blockchainu. Mnoho her využívá Ethereum ke správě herních aktiv jako NFT (nezaměnitelné tokeny). To umožňuje hráčům skutečně vlastnit jedinečné digitální předměty, které mohou být volně obchodovány, prodávány nebo darovány mimo hranice ekosystému jediného herního vývojáře. Ačkoli tato aktiva nabízejí nové formy hráčské svobody, základní herní logika často zůstává na centralizovaných serverech.
+
+Hry zcela na blockchainu jsou hry, kde základní mechanismy, a často celý herní svět, jsou přímo řízeny chytrými kontrakty na blockchainu Etherea (nebo na jeho vrstvách 2). To zajišťuje bezkonkurenční transparentnost. Žádné centrální servery, žádní zprostředkovatelé – pouze transparentní, hráčem řízené zážitky a ekonomiky.
+
+- Hráči vlastní svá aktiva jako NFT.
+- Předměty mohou být volně obchodovány, darovány nebo prodávány.
+- Blockchain zajišťuje, že aktiva zůstanou navždy dostupná.
+
+## Současný stav hraní {#the-current-state-of-gaming}
+
+- **Časté vypínání her:** Jen v roce 2023 [bylo vypnuto více než 60 her](https://tech4gamers.com/game-studios-shut-down-2023/) a 11 herních studií bylo zcela uzavřeno, což hráčům nenechalo nic z jejich herních investic. Hry na blockchainu, se svou logikou a aktivy v decentralizované síti, mohou přetrvat tak dlouho, dokud existuje blockchain, a nabízejí tak vyšší míru trvalosti.
+- **Frustrace ze zamčených aktiv:** [51 % hráčů je frustrováno](https://www.starknet.io/blog/blockchain-gaming/), že nemohou darovat nebo znovu prodat herní předměty, které si koupí, a 23 % je naštváno, jak obtížné je získat peníze zpět z nákupů ve hře. Hráči investují značné množství času a peněz do získávání herních předmětů, jen aby zjistili, že je ve skutečnosti nevlastní. Standard NFT Etherea poskytuje ověřitelné digitální vlastnictví a zajišťuje, že hráči mají svá aktiva pod kontrolou.
+- **Vysoké výdaje bez návratnosti:** [Hráči utratí v průměru 6 425 $](https://www.starknet.io/blog/blockchain-gaming/) za virtuální předměty během svého života, přičemž měsíčně utratí 8,74 $ a ročně 104 $. Vlastnictví na blockchainu mění tyto výdaje z utopených nákladů na investici do digitálního aktiva, které lze prodat, obchodovat s ním nebo ho darovat, podobně jako fyzický sběratelský předmět.
+
+## Populární hry postavené na Ethereu {#popular-games-built-on-ethereum}
+
+Vývojáři zkoumají nové způsoby, jak učinit hry poutavějšími, a překročit jednoduché mechanismy odměn, aby prohloubili hratelnost založenou na dovednostech.
+
+
Více o EIP
@@ -68,9 +68,9 @@ Důležitým procesem používaným při řízení Etherea je **návrh na zlepš
Formální proces zavádění změn do protokolu Ethereum je následující:
-1. **Navrhněte základní EIP**: Jak je popsáno v [EIP- 1](https://eips.ethereum.org/EIPS/eip-1#core-eips), prvním krokem k formálnímu navržení změny Etherea je její podrobný popis v Core EIP. Ten bude sloužit jako oficiální specifikace pro EIP, kterou budou vývojáři protokolů implementovat, pokud bude přijata.
+1. **Navrhněte Core EIP**: Jak je popsáno v [EIP-1](https://eips.ethereum.org/EIPS/eip-1#core-eips), prvním krokem k formálnímu navržení změny v Ethereu je její podrobné popsání v Core EIP. Ten bude sloužit jako oficiální specifikace pro EIP, kterou budou vývojáři protokolů implementovat, pokud bude přijata.
-2. **Představte své EIP vývojářům protokolu**: Jakmile budete mít základní EIP, pro které jste dostali zpětnou vazbu od komunity, měli byste je předložit vývojářům protokolu. To uděláte tak, že ho navrhnete k diskusi na [AllCoreDevs callu](https://github.com/ethereum/execution-specs/tree/master/network-upgrades#getting-the-considered-for-inclusion-cfi-status). Je pravděpodobné, že některé diskuze již proběhly asynchronně na [fóru Ethereum Magicians](https://ethereum-magicians.org/) nebo na [Ethereum R&D Discordu](https://discord.gg/mncqtgVSVw).
+2. **Představte své EIP vývojářům protokolu**: Jakmile budete mít Core EIP, ke kterému jste shromáždili zpětnou vazbu komunity, měli byste jej představit vývojářům protokolu. Můžete tak učinit tak, že jej navrhnete k diskuzi na [hovoru AllCoreDevs](https://github.com/ethereum/execution-specs/tree/master/network-upgrades#getting-the-considered-for-inclusion-cfi-status). Je pravděpodobné, že některé diskuze již proběhly asynchronně na fóru [Ethereum Magicians](https://ethereum-magicians.org/) nebo na [Discordu Ethereum R&D](https://discord.gg/mncqtgVSVw).
> Potenciální výsledky této fáze jsou:
@@ -78,25 +78,25 @@ Formální proces zavádění změn do protokolu Ethereum je následující:
> - Budou požadovány technické změny
> - Váš návrh být odmítnut, pokud to není priorita nebo neposkytuje dostatečně velké zlepšení rozvoje sítě
-3. **Směřujte ke konečnému návrhu:** Po obdržení zpětné vazby od všech relevantních zúčastněných stran budete pravděpodobně muset provést změny ve svém původním návrhu, abyste zlepšili jeho zabezpečení nebo aby lépe vyhovoval potřebám uživatelů. Jakmile do svého EIP začleníte všechny změny, které považujete za nezbytné, budete je muset znovu předložit vývojářům protokolu. Poté buď přejdete k dalšímu kroku tohoto procesu, nebo se objeví nové podněty, které vyžadují další kolo schvalování vašeho návrhu.
+3. **Iterujte směrem k finálnímu návrhu:** po obdržení zpětné vazby od všech relevantních zúčastněných stran budete pravděpodobně muset provést změny ve svém původním návrhu, abyste zlepšili jeho zabezpečení nebo lépe vyhověli potřebám různých uživatelů. Jakmile do svého EIP začleníte všechny změny, které považujete za nezbytné, budete je muset znovu předložit vývojářům protokolu. Poté buď přejdete k dalšímu kroku tohoto procesu, nebo se objeví nové podněty, které vyžadují další kolo schvalování vašeho návrhu.
-4. **EIP zahrnuto ve vylepšení sítě**: Za předpokladu, že je EIP schváleno, otestováno a implementováno, je naplánováno jako součást vylepšení sítě. Vzhledem k vysokým nákladům na koordinaci vylepšení sítě (každý musí upgradovat současně) jsou EIP většinou spojovány do balíčků.
+4. **EIP zahrnuto v upgradu sítě**: za předpokladu, že je EIP schváleno, testováno a implementováno, je naplánováno jako součást upgradu sítě. Vzhledem k vysokým nákladům na koordinaci vylepšení sítě (každý musí upgradovat současně) jsou EIP většinou spojovány do balíčků.
-5. **Aktivace vylepšení sítě**: Po aktivaci vylepšení sítě bude vaše EIP aktivní v síti Ethereum. _Poznámka: Vylepšení sítě se obvykle nejdříve aktivuje na testovacích sítích před aktivací v hlavní síti Ethereum._
+5. **Upgrade sítě aktivován**: po aktivaci upgradu sítě bude EIP aktivní v síti Etherea. _Poznámka: Vylepšení sítě se obvykle nejdříve aktivuje na testovacích sítích před aktivací v hlavní síti Ethereum._
Tento postup, i když je velmi zjednodušený, poskytuje přehled hlavních fází změny protokolu, která má být implementována na Ethereu. Níže rozebíráme neformální faktory, které během tohoto procesu také hrají roli.
## Neformální proces {#informal-process}
-### Porozumění předchozím vylepšením {#prior-work}
+### Porozumění předchozí práci {#prior-work}
-Šampioni EIP by se měli seznámit s předchozí prací a návrhy před vytvořením EIP, které má ambice vylepšit hlavní síť Ethereum. Díky tomu, doufejme, přináší EIP něco nového, co dosud nebylo zamítnuto. Tři hlavní místa, kde se můžete seznámit s prací ostatních navrhovatelů vylepšení, jsou [EIP repozitář](https://github.com/ethereum/EIPs), [Ethereum Magicians](https://ethereum-magicians.org/) a [ethresear.ch](https://ethresear.ch/).
+Šampioni EIP by se měli seznámit s předchozí prací a návrhy před vytvořením EIP, které má ambice vylepšit hlavní síť Ethereum. Díky tomu, doufejme, přináší EIP něco nového, co dosud nebylo zamítnuto. Tři hlavní místa pro průzkum jsou [úložiště EIP](https://github.com/ethereum/EIPs), [Ethereum Magicians](https://ethereum-magicians.org/) a [ethresear.ch](https://ethresear.ch/).
### Pracovní skupiny {#working-groups}
Je nepravděpodobné, že by původní návrh EIP mohl být implementován na hlavní síť Ethereum bez úprav nebo změn. Obecně vzato, budou EIP šampióni vždy spolupracovat s podskupinou vývojářů protokolu na specifikaci, implementaci, testování, iteraci a finalizaci jejich návrhu. Historicky tyto pracovní skupiny vyžadovaly několik měsíců (a někdy i let!) práce. Podobně by EIP šampióni měli zapojit příslušné vývojáře aplikací/nástrojů v rané fázi jejich úsilí získat zpětnou vazbu od koncových uživatelů a zmírnit jakákoli rizika začlenění EIP do Etherea.
-### Konsensus komunity {#community-consensus}
+### Komunitní konsensus {#community-consensus}
Zatímco některá EIP jsou jednoduchá technická vylepšení s minimálními nuancemi, některá jsou složitější a přinášejí kompromisy, které ovlivní různé zúčastněné strany a to různými způsoby. To znamená, že některé EIP jsou v rámci komunity spornější než jiné.
@@ -108,17 +108,17 @@ Kromě zabezpečení sítě přikládali vývojáři protokolu významnou váhu
- Více o mergi
+ Více o The Merge
+ Seznam peněženek
+
+
+Pokud jste nováčci, můžete na stránce "najít peněženku" zvolit filtr "Nováčci v kryptu" a najít peněženky, které by měly obsahovat všechny potřebné funkce vhodné pro začátečníky.
+
+
+
+K dispozici jsou také další profilové filtry, které vyhovují vašim potřebám. Toto jsou příklady běžně používaných peněženek - než začnete důvěřovat jakémukoli softwaru, měli byste provést vlastní průzkum.
+
+## Krok 2: Stáhněte a nainstalujte si aplikaci peněženky
+
+Jakmile se rozhodnete pro konkrétní peněženku, navštivte její oficiální webové stránky nebo obchod s aplikacemi, stáhněte a nainstalujte si ji. Všechny by měly být zdarma.
+
+## Krok 3: Otevřete aplikaci a vytvořte si učet na Ethereu
+
+Při prvním otevření nové peněženky můžete být vyzváni k volbě mezi vytvořením nového účtu a importem stávajícího účtu. Klikněte na vytvoření nového účtu. **Toto je krok, během kterého software peněženky vygeneruje váš Ethereum účet.**
+
+## Krok 4: Uložte si svou bezpečnostní frázi
+
+Některé aplikace vás požádají, abyste si uložili tajnou "bezpečnostní frázi" (někdy nazývanou také "seed fráze" nebo "mnemonická fráze"). Udržet tuto frázi na bezpečném místě je velmi důležité! Tato fráze se používá k obnovení přístupu k vašemu účtu na Ethereu a může být použita k odesílání transakcí.
+
+**Každý, kdo zná tuto frázi, může převzít kontrolu nad všemi prostředky.** Nikdy ji s nikým nesdílejte. Bezpečnostní fráze by měla obsahovat 12 až 24 náhodně vygenerovaných slov (na pořadí slov záleží).
+
+
+
+
+ Máte nainstalovanou peněženku?
Naučte se ji používat.
+
+ Jak používat peněženku
+
+
+
+
+
+Zajímají vás další návody? Podívejte se na naše: [Návody krok za krokem](/guides/)
+
+## Často kladené dotazy
+
+### Jsou moje peněženka a můj Ethereum účet totéž?
+
+Ne. Peněženka je nástroj, který vám pomáhá spravovat vaše účty. Jedna peněženka může poskytovat přístup k několika účtům a k jednomu účtu může mít přístup více peněženek. Bezpečnostní fráze se používá k vytváření účtů a dává aplikaci peněženky oprávnění spravovat aktiva tohoto účtu.
+
+### Mohu poslat Bitcoin na adresu na Ethereu nebo Ether na Bitcoin adresu?
+
+Ne, nemůžete. Bitcoin a ether existují na dvou oddělených sítích (tj. různých blockchainech), z nichž každá má vlastní účetnictví a odlišné formáty adres. Objevily se různé pokusy o přemostění těchto dvou různých sítí, z nichž nejaktivnější je v současnosti [Wrapped Bitcoin neboli WBTC](https://www.bitcoin.com/get-started/what-is-wbtc/). Toto není doporučení, protože WBTC je svěřenecké řešení (což znamená, že určitá skupina lidí ovládá určité kritické funkce) a WBTC je zde uvedeno pouze pro informační účely.
+
+### Pokud mám ETH adresu, vlastním stejnou adresu i na jiných blockchainech?
+
+Stejnou [adresu](/glossary/#address) můžete používat na všech blockchainech, které používají podobný základní software jako Ethereum (tzv. „kompatibilní s EVM“). Tento [seznam](https://chainlist.org/) vám ukáže, které blockchainy můžete používat se stejnou adresou. Některé blockchainy, jako například Bitcoin, implementují samostatnou sadu síťových pravidel a budete na nich potřebovat jinou adresu s jiným formátem. Pokud máte peněženku na bázi smart kontraktu, měli byste se podívat na její oficiální webové stránky pro více informací o tom, které blockchainy jsou podporovány, protože tyto peněženky mají obvykle omezený, ale bezpečnější rozsah.
+
+### Je vlastní peněženka bezpečnější než uchovávání finančních prostředků na burze?
+
+Vlastní peněženka znamená, že přebíráte odpovědnost za bezpečnost svého majetku. Bohužel existuje mnoho příkladů neúspěšných burz, které přišly o peníze svých zákazníků. Vlastnictví peněženky (s bezpečnostní frází) eliminuje riziko spojené s důvěrou v nějakou entitu, která by držela vaše aktiva. Nicméně, musíte si ji zabezpečit sami a vyhnout se phishingovým podvodům, náhodnému schválení transakcí nebo odhalení bezpečnostní fráze, interakci s falešnými webovými stránkami a dalším rizikům spojeným se správou svépomocí. Rizika a přínosy se liší.
+
+### Pokud ztratím telefon/hardwarovou peněženku, musím pro obnovení ztracených finančních prostředků znovu použít stejnou aplikaci peněženky?
+
+Ne, můžete použít jinou peněženku. Pokud máte bezpečnostní frázi, můžete ji zadat do většiny peněženek a ty váš účet obnoví. Pokud to někdy budete potřebovat udělat, buďte opatrní: Při obnově peněženky se raději ujistěte, že nejste připojeni k internetu, aby nedošlo k náhodnému úniku vaší bezpečnostní fráze. Bez bezpečnostní fráze je často nemožné získat ztracené finanční prostředky zpět.
diff --git a/public/content/translations/cs/guides/how-to-id-scam-tokens/index.md b/public/content/translations/cs/guides/how-to-id-scam-tokens/index.md
new file mode 100644
index 00000000000..70981fadeaa
--- /dev/null
+++ b/public/content/translations/cs/guides/how-to-id-scam-tokens/index.md
@@ -0,0 +1,97 @@
+---
+title: Jak rozpoznat podvodné tokeny
+description: Co jsou podvodné tokeny, jak se snaží vypadat legitimně a jak se jim vyhnout.
+lang: cs
+---
+
+# Jak rozpoznat podvodné tokeny {#identify-scam-tokens}
+
+Jedním z nejčastějších způsobů využití Etherea je vytvoření obchodovatelného tokenu pro skupinu, v podstatě jejich vlastní měny. Tyto tokeny obvykle dodržují standard [ERC-20](/developers/docs/standards/tokens/erc-20/). Kdekoliv, kde existují legitimní případy použití, které přinášejí hodnotu, se také objevují i zločinci, kteří se snaží tuto hodnotu ukrást pro sebe.
+
+Existují dva způsoby, jak vás mohou oklamat:
+
+- **Prodat vám podvodný token**, který může vypadat jako legitimní token, který chcete koupit, ale je vydán podvodníky a nemá žádnou hodnotu.
+- **Přimět vás k podepsání škodlivých transakcí**, obvykle tím, že vás nasměrují na své vlastní uživatelské rozhraní. Mohou se vás pokusit přimět k tomu, abyste jim poskytli příspěvek na vaše ERC-20 tokeny, odhalili citlivé informace, které jim umožní přístup k vašim aktivům, atd. Tato uživatelská rozhraní mohou být téměř dokonalými klony poctivých stránek, ale se skrytými triky.
+
+Abychom si ukázali, co jsou to podvodné tokeny a jak je identifikovat, podíváme se na jeden příklad: [`wARB`](https://eth.blockscout.com/token/0xB047c8032b99841713b8E3872F06cF32beb27b82). Tento token se snaží vypadat jako legitimní token [`ARB`](https://eth.blockscout.com/address/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1).
+
+
+
+Arbitrum je organizace, která vyvíjí a spravuje [optimistické rollupy](/developers/docs/scaling/optimistic-rollups/). Zpočátku byla společnost Arbitrum organizována jako ziskový podnik, ale poté podnikla kroky k decentralizaci. V rámci tohoto procesu vydali obchodovatelný [správní token](/dao/#token-based-membership).
+
+
+
+
+
+V Ethereu platí konvence, že pokud aktivum není kompatibilní s ERC-20, vytvoříme jeho "zabalenou" verzi s názvem začínajícím na "w". Takže máme například wBTC pro bitcoin a wETH pro ether.
+
+Nemá smysl vytvářet zabalenou verzi tokenu ERC-20, který již na Ethereu je, ale podvodníci spoléhají spíše na zdání legitimity než na realitu.
+
+
+
+## Jak fungují podvodné tokeny? {#how-do-scam-tokens-work}
+
+Smyslem Etherea je decentralizace. To znamená, že neexistuje žádná centrální autorita, která by vám mohla zabavit majetek nebo vám zabránit v nasazení chytrého kontraktu. Znamená to ale také, že podvodníci mohou nasadit libovolný chytrý kontrakt.
+
+
+
+[Chytré kontrakty](/developers/docs/smart-contracts/) jsou programy, které běží na blockchainu Ethereum. Například, každý ERC-20 token je implementován jako chytrý kontrakt.
+
+
+
+Konkrétně společnost Arbitrum nasadila kontrakt, který používá symbol `ARB`. To však nebrání ostatním lidem, aby také nasadili kontrakt, který používá stejný nebo podobný symbol. Ten, kdo kontrakt sepisuje, určuje, co bude kontrakt dělat.
+
+## Zdánlivá legitimita {#appearing-legitimate}
+
+Tvůrci podvodných tokenů používají několik triků, aby vypadali legitimně.
+
+- **Legitimní název a symbol**. Jak již bylo zmíněno, ERC-20 kontrakty mohou mít stejný symbol a název jako jiné ERC-20 kontrakty. Na tato pole se nemůžete z hlediska bezpečnosti spolehnout.
+
+- **Legitimní vlastníci**. Podvodné tokeny často posílají značné zůstatky na adresy, u kterých lze předpokládat, že jsou legitimními držiteli skutečného tokenu.
+
+ Podívejme se například znovu na `wARB`. [Asi 16 % tokenů](https://eth.blockscout.com/token/0xb047c8032b99841713b8e3872f06cf32beb27b82?tab=holders) drží adresa, jejíž veřejný štítek je [Arbitrum Foundation: Deployer](https://eth.blockscout.com/address/0x1C8db745ABe3C8162119b9Ef2c13864Cd1FDD72F). Toto _není_ falešná adresa, je to skutečně adresa, která [nasadila skutečný kontrakt ARB na mainnetu Ethereum](https://eth.blockscout.com/tx/0x242b50ab4fe9896cb0439cfe6e2321d23feede7eeceb31aa2dbb46fc06ed2670).
+
+ Protože je zůstatek ERC-20 adresy součástí úložiště ERC-20 kontraktu, může být ve smlouvě specifikován tak, jak si tvůrce smlouvy přeje. Je také možné, že smlouva zakáže převody, aby se legitimní uživatelé nemohli těchto podvodných tokenů zbavit.
+
+- **Legitimní převody**. _Legitimní vlastníci by neplatili za převod podvodného tokenu jiným lidem, takže pokud dochází k převodům, musí být legitimní, ne?_ **Špatně**. Události `Transfer` jsou vytvářeny kontraktem ERC-20. Podvodník může snadno sepsat smlouvu tak, aby vedla k těmto úkonům.
+
+## Podvodné webové stránky {#websites}
+
+Podvodníci mohou také vytvářet velmi přesvědčivé webové stránky, někdy dokonce přesné klony s identickým uživatelským rozhraním, ale s rafinovanými triky. Příkladem mohou být externí odkazy, které se zdají být legitimní, ale ve skutečnosti odesílají uživatele na externí podvodnou stránku, nebo nesprávné pokyny, které vedou uživatele k vyzrazení klíčů nebo odeslání finančních prostředků na adresu útočníka.
+
+Nejlepší postup, jak se tomu vyhnout, je pečlivě kontrolovat URL adresy navštívených stránek a ukládat adresy známých autentických stránek do záložek. Pak můžete navštěvovat skutečný web prostřednictvím záložek, aniž byste omylem udělali pravopisné chyby nebo se spoléhali na externí odkazy.
+
+## Jak se můžete chránit? Jak se chránit {#protect-yourself}
+
+1. **Zkontrolujte adresu kontraktu**. Legitimní tokeny pocházejí od legitimních organizací a jejich adresy kontraktů si můžete prohlédnout na webových stránkách organizace. Například [pro `ARB` si můžete legitimní adresy prohlédnout zde](https://docs.arbitrum.foundation/deployment-addresses#token).
+
+2. **Pravé tokeny mají likviditu**. Další možností je podívat se na velikost poolu likvidity na [Uniswap](https://uniswap.org/), jednom z nejběžnějších protokolů pro výměnu tokenů. Tento protokol funguje na bázi poolů likvidity, do kterých investoři vkládají své tokeny v naději na výnos z poplatků za obchodování.
+
+Podvodné tokeny mají obvykle jen malou likviditu, pokud vůbec nějakou, protože podvodníci nechtějí riskovat skutečná aktiva. Například pool `ARB`/`ETH` na Uniswapu drží asi milion dolarů ([aktuální hodnotu najdete zde](https://app.uniswap.org/explore#/pools/0x755e5a186f0469583bd2e80d1216e02ab88ec6ca)) a nákup nebo prodej malého množství cenu nezmění:
+
+
+
+Ale když se pokusíte koupit podvodný token `wARB`, i nepatrný nákup by změnil cenu o více než 90 %:
+
+
+
+To je další důkaz, který nám ukazuje, že `wARB` pravděpodobně není legitimní token.
+
+3. **Podívejte se na Etherscan**. Komunita již identifikovala a nahlásila mnoho podvodných tokenů. Takové tokeny jsou [označeny na Etherscanu](https://info.etherscan.com/etherscan-token-reputation/). Ačkoli Etherscan není autoritativním zdrojem pravdy (z povahy decentralizovaných sítí vyplývá, že nemůže existovat autoritativní zdroj legitimity), tokeny, které Etherscan identifikuje jako podvodné, pravděpodobně podvodné jsou.
+
+ 
+
+## Závěr {#conclusion}
+
+Dokud budou na světě existovat hodnoty, budou existovat podvodníci, kteří se je budou snažit ukrást pro sebe, a v decentralizovaném světě není nikdo, kdo by vás chránil, kromě vás samotných. Doufejme, že si zapamatujete tyto body, které vám pomohou rozlišit legitimní tokeny od podvodných:
+
+- Podvodné tokeny se vydávají za legitimní tokeny, mohou používat stejný název, symbol atd.
+- Podvodné tokeny _nemohou_ používat stejnou adresu kontraktu.
+- Nejlepším zdrojem adresy legitimního tokenu je organizace, o jejíž token se jedná.
+- Pokud to selže, můžete použít oblíbené a důvěryhodné aplikace, jako jsou [Uniswap](https://app.uniswap.org/#/swap) a [Blockscout](https://eth.blockscout.com/).
diff --git a/public/content/translations/cs/guides/how-to-revoke-token-access/index.md b/public/content/translations/cs/guides/how-to-revoke-token-access/index.md
new file mode 100644
index 00000000000..3c295c3a808
--- /dev/null
+++ b/public/content/translations/cs/guides/how-to-revoke-token-access/index.md
@@ -0,0 +1,75 @@
+---
+title: Jak zrušit přístup chytrého kontraktu k vašim krypto fondům
+description: Návod, jak odebrat přístup k vašim tokenům škodlivým smart kontraktům
+lang: cs
+---
+
+# Jak zrušit přístup chytrého kontraktu k vašim krypto fondům
+
+V tomto návodu zjistíte, jak zobrazit seznam všech [smart kontraktů](/glossary/#smart-contract), kterým jste povolili přístup k vašim finančním prostředkům, a jak je zrušit.
+
+Nečestní vývojáři mohou do smart kontraktů přidat zadní vrátka, která umožňují přístup k finančním prostředkům nevědomých uživatelů, kteří se smart kontraktem interagují. Často se stává, že takové platformy žádají uživatele o povolení utratit **neomezený počet tokenů** ve snaze ušetřit v budoucnu malé množství [gasu](/glossary/#gas), což je ale spojeno se zvýšeným rizikem.
+
+Jakmile platforma získá neomezená přístupová práva k tokenu ve vaší [peněžence](/glossary/#wallet), může všechny tyto tokeny utratit, i když jste své prostředky z jejich platformy vybrali do své peněženky. Útočníci totiž mají stále přístup k vašim prostředkům a mohou je vybrat do svých peněženek, aniž byste měli možnost získat je zpět.
+
+Jedinou ochranou je vyhnout se interakci s neověřenými novými projekty, schvalovat pouze to, co potřebujete, případně pravidelně odebírat přístup službám, které už nevyužíváte. Takže, jak na to?
+
+## Krok 1: Používejte nástroje pro zrušení přístupu
+
+Hned několik webových stránek vám umožňuje zobrazit a zrušit přístup smart kontraktů spojených s vaší adresou. Běžte na některou k následujících stránek a připojte svoji peněženku:
+
+- [Etherscan](https://etherscan.io/tokenapprovalchecker) (Ethereum)
+- [Blockscout](https://eth.blockscout.com/apps/revokescout) (Ethereum)
+- [Revoke](https://revoke.cash/) (více sítí)
+- [Unrekt](https://app.unrekt.net/) (více sítí)
+- [EverRevoke](https://everrise.com/everrevoke/) (více sítí)
+
+## Krok 2: Připojte svoji peněženku
+
+Jakmile budete na webové stránce, klikněte na možnost "Připojit peněženku". Webová stránka by vás měla vyzvat k připojení peněženky.
+
+Ujistěte se, že v peněžence a na webové stránce používáte stejnou síť. Zobrazí se vám pouze chytré kontrakty související s vybranou sítí. Pokud se například připojíte k Ethereum Mainnetu, uvidíte pouze kontrakty na Ethereu, nikoliv kontrakty na jiných blockchainech, jako je Polygon.
+
+## Krok 3: Vyberte smart kontrakt, kterému chcete zrušit přístup
+
+Měli byste vidět všechny kontrakty, které mají povolený přístup k tokenům, a jejich limit výdajů. Najděte ten, kterému chcete zrušit přístup.
+
+Pokud nevíte, který kontrakt vybrat, můžete zrušit přístup všem. To to pro vás nebude znamenat žádné problémy, ale při příští interakci s některým z těchto kontraktů, jim budete muset znovu povolit přístup.
+
+## Krok 4: Zruště přístup k finančním prostředkům
+
+Po kliknutí na zrušení přístupu by se měl v peněžence zobrazit návrh nové transakce. To lze očekávat. Aby bylo zrušení přístupu úspěšně dokončeno, musíte zaplatit transakční poplatek. V závislosti na vytížení sítě může zpracování trvat až několik minut.
+
+Doporučujeme vám po několika minutách obnovit nástroj na zrušení přístupu a znovu připojit svoji peněženku, abyste si ověřili, zda kontrakt se zrušeným přístupem skutečně zmizel ze seznamu.
+
+Doporučujeme vám nikdy nedávat projektům neomezený přístup k vašim tokenům a pravidelně rušit všechna oprávnění k přístupu k tokenům. Zrušení přístupu k tokenům by nikdy nemělo vést ke ztrátě finančních prostředků, zejména pokud používáte výše uvedené nástroje.
+
+
+
+
+
+ Chcete se dozvědět více?
+
+ Podívejte se na naše další návody
+
+
+
+
+## Často kladené dotazy
+
+### Ukončí zrušení přístupu k tokenům také staking, pooling, půjčky atd.?
+
+Ne, neovlivní to žádnou z vašich [DeFi](/glossary/#defi) strategií. Zůstanete na svých pozicích a budete dostávat odměny atd.
+
+### Je odpojení peněženky od projektu totéž jako odebrání povolení používat mé prostředky?
+
+Ne, pokud svou peněženku od projektu odpojíte, ale udělili jste oprávnění k přístupu k tokenům, mohou tyto projekty vaše tokeny stále používat. Tento přístup musíte zrušit.
+
+### Kdy vyprší platnost povolení kontraktu k přístupu k mým prostředkům?
+
+Platnost povolení k přístupu není omezena. Pokud udělíte kontraktu oprávění, může ho použít i několik let po jeho udělení.
+
+### Proč se v projektech dá nastavit přístup k neomezenému množství tokenů?
+
+Projekty to často dělají proto, aby minimalizovaly počet žádostí, což znamená, že uživatel musí schválit přístup a zaplatit poplatek za transakci jen jednou. To je sice pohodlné, ale pro uživatele to může být nebezpečné při neopatrném udělování přístupu na stránkách, které nejsou prověřeny časem nebo které nejsou auditované. Některé peněženky umožňují ručně omezit množství schvalovaných tokenů, čímž se riziko zneužití prostředků snižuje. Další informace získáte u poskytovatele peněženky.
diff --git a/public/content/translations/cs/guides/how-to-swap-tokens/index.md b/public/content/translations/cs/guides/how-to-swap-tokens/index.md
new file mode 100644
index 00000000000..43f3550e29b
--- /dev/null
+++ b/public/content/translations/cs/guides/how-to-swap-tokens/index.md
@@ -0,0 +1,70 @@
+---
+title: Jak prohodit tokeny
+description: Návod na směnu tokenů na Ethereu.
+lang: cs
+---
+
+# Jak prohodit tokeny
+
+Už vás nebaví hledat burzu, na které jsou všechny vaše oblíbené tokeny? Většinu tokenů můžete směnit pomocí [decentralizovaných burz](/glossary/#dex).
+
+Směna tokenů zahrnuje směnu dvou různých aktiv, která existují na síti Ethereum, například směnu ETH za DAI (token [ERC-20](/glossary/#erc-20)). Proces je velice rychlý a levný. K směně tokenů budete potřebovat kryptopeněženku.
+
+**Předpoklady:**
+
+- mít [krypto peněženku](/glossary/#wallet); pokud ji nemáte, můžete se řídit tímto průvodcem, [jak si vytvořit účet na Ethereu](/guides/how-to-create-an-ethereum-account/)
+- mít v peněžence prostředky
+
+## 1. Připojte svou peněženku k decentralizované burze (DEX) podle svého výběru
+
+Mezi populární burzy patří:
+
+- [Uniswap](https://app.uniswap.org/#/swap)
+- [Sushiswap](https://www.sushi.com/swap)
+- [1Inch](https://app.1inch.io/#/1/unified/swap/ETH/DAI)
+- [Curve](https://www.curve.finance/dex/ethereum/swap/)
+
+Zaujalo vás to? Zjistěte více o tom, co jsou [decentralizované finance (DeFi)](/defi/), a jak tyto nové typy burz fungují.
+
+## 2. Vyberte dvojici tokenů, které chcete směnit
+
+Například ETH a DAI. Ujistěte se, že máte prostředky na jednom z těchto dvou žetonů.
+
+
+## 3. Zadejte množství tokenů, které chcete vyměnit, a klikněte na tlačítko směnit
+
+Burza automaticky vypočítá, kolik tokenů dostanete.
+
+
+
+## 4. Potvrďte transakci
+
+Zkontrolujte podrobnosti transakce. Zkontrolujte směnný kurz a případné další poplatky, abyste se vyhnuli nepříjemným překvapením.
+
+
+
+## 5. Počkejte na zpracování transakce
+
+Průběh transakce si můžete prohlédnout v libovolném průzkumníku blockchainu. Tento proces by neměl trvat déle než 10 minut.
+
+Směněné tokeny automaticky obdržíte do své peněženky, jakmile bude transakce zpracována.
+
+
+
+ Chcete se dozvědět více?
+
+ Podívejte se na naše další návody
+
+
+
+
+## Často kladené dotazy
+
+### Mohu směnit ETH za BTC ze své peněženky?
+
+Ne, směnit můžete pouze tokeny, které jsou ze sítě Ethereum, například ETH, tokeny ERC-20 nebo NFT. Směnit můžete pouze "zabalené" formy bitcoinu, které žijí na Ethereu.
+
+### Co je to skluz?
+
+Jedná se o rozdíl mezi očekávaným a skutečným směnným kurzem.
diff --git a/public/content/translations/cs/guides/how-to-use-a-bridge/index.md b/public/content/translations/cs/guides/how-to-use-a-bridge/index.md
new file mode 100644
index 00000000000..f7fc3949798
--- /dev/null
+++ b/public/content/translations/cs/guides/how-to-use-a-bridge/index.md
@@ -0,0 +1,72 @@
+---
+title: Jak propojit tokeny do 2. vrstvy
+description: Návod vysvětlující, jak přesunout tokeny z Etherea do 2. vrstvy pomocí mostu.
+lang: cs
+---
+
+# Jak propojit tokeny do 2. vrstvy
+
+Pokud je na Ethereu velký provoz, může se to prodražit. Jedním z řešení je vytvoření nových „vrstev“: tj. různých sítí, které fungují podobně jako samotné Ethereum. Tyto takzvané 2. vrstvy pomáhají snižovat přetížení a náklady na Ethereum tím, že zpracovávají mnohem více transakcí za nižší poplatky a jejich výsledek ukládají na Ethereum pouze jednou za čas. Tyto 2. vrstvy nám tak umožňují provádět transakce s vyšší rychlostí a nižšími náklady. Mnoho populárních krypto projektů přechází na 2. vrstvu právě kvůli těmto výhodám. Nejjednodušší způsob, jak přesunout tokeny z Etherea do 2. vrstvy, je použít most.
+
+**Předpoklady:**
+
+- mít kryptoměnovou peněženku – pokud ji nemáte, řiďte se tímto návodem a [vytvořte si účet na Ethereu](/guides/how-to-create-an-ethereum-account/)
+- mít v peněžence prostředky
+
+## 1. Určete, kterou síť 2. vrstvy chcete použít
+
+Více informací o různých projektech a důležitých odkazech najdete na naší [stránce o druhé vrstvě](/layer-2/).
+
+## 2. Otevřete si vybraný most
+
+Mezi populární 2. vrstvy patří:
+
+- [Přemostění Arbitrum](https://portal.arbitrum.io/bridge?l2ChainId=42161)
+- [Přemostění Optimism](https://app.optimism.io/bridge/deposit)
+- [Přemostění sítě Boba](https://hub.boba.network/)
+
+## 3. Připojte se k mostu pomocí vaší peněženky
+
+Ujistěte se, že je vaše peněženka připojena k síti hlavní síti Etherea. Pokud není, webová stránka vás automaticky vyzve k přepnutí sítě.
+
+
+
+## 4. Zadejte částku a přesuňte prostředky
+
+Zkontrolujte si částku, kterou získáte na oplátku v síti 2. vrstvy, a poplatky, abyste se vyhnuli nepříjemným překvapením.
+
+
+
+## 5. Potvrďte tuto transakci ve své peněžence
+
+Za zpracování transakce budete muset zaplatit poplatek (nazývaný [palivo](/glossary/#gas)) ve formě ETH.
+
+
+
+## 6. Počkejte, až budou vaše prostředky převedeny
+
+Tento proces by neměl trvat déle než 10 minut.
+
+## 7. Přidejte vybranou síť 2. vrstvy do své peněženky (volitelné)
+
+Podrobnosti o síti RPC můžete zjistit pomocí [chainlist.org](http://chainlist.org). Po přidání sítě a dokončení transakce byste měli tokeny vidět ve své peněžence.
+
+
+
+ Chcete se dozvědět více?
+
+ Podívejte se na naše další návody
+
+
+
+
+## Často kladené dotazy
+
+### Co když mám prostředky na burze?
+
+Možná budete moci vybírat na některé 2. vrstvě přímo z burzy. Další informace naleznete v části „Přejít na druhou vrstvu“ na naší [stránce o druhé vrstvě](/layer-2/).
+
+### Mohu se po přesunu svých tokenů na 2. vrstvu vrátit zpět do hlavní sítě Etherea?
+
+Ano, své prostředky můžete kdykoli přesunout zpět do hlavní sítě pomocí stejného mostu.
diff --git a/public/content/translations/cs/guides/how-to-use-a-wallet/index.md b/public/content/translations/cs/guides/how-to-use-a-wallet/index.md
new file mode 100644
index 00000000000..0df2f6cae41
--- /dev/null
+++ b/public/content/translations/cs/guides/how-to-use-a-wallet/index.md
@@ -0,0 +1,91 @@
+---
+title: Jak používat peněženku
+metaTitle: Jak používat Ethereum peněženky | Krok za krokem
+description: Návod vysvětlující, jak odesílat a přijímat tokeny a jak se připojovat k web3 projektům.
+lang: cs
+---
+
+# Jak používat peněženku
+
+Naučte se ovládat všechny základní funkce peněženky. Pokud ji ještě nemáte, podívejte se na náš návod [Jak vytvořit Ethereum účet](/guides/how-to-create-an-ethereum-account/).
+
+## Otevřete vaši peněženku
+
+Měli byste vidět ovládací panel, který pravděpodobně zobrazí váš zůstatek a bude obsahovat tlačítka pro odesílání a přijímání tokenů.
+
+## Přijímání kryptoměn
+
+Chcete přijímat kryptoměny do své peněženky?
+
+Každý Ethereum účet má svou vlastní přijímací adresu, což je jedinečná sekvence čísel a písmen. Adresa funguje jako číslo bankovního účtu. Ethereum adresy vždy začínají řetězcem "0x". Tuto adresu můžete sdílet s kýmkoli: je to bezpečné.
+
+S vaší adresou je to jako s adresou domova: musíte ji lidem sdělit, aby vás mohli najít. Je to bezpečné, protože vchodové dveře můžete stále zamykat jiným klíčem, který ovládáte pouze vy, takže se k vám nikdo nedostane, i když ví, kde bydlíte.
+
+Tomu, kdo vám chce poslat peníze, musíte sdělit svou veřejnou adresu. Mnoho aplikací peněženek umožňuje zkopírovat adresu nebo zobrazit QR kód, který lze naskenovat pro snadnější použití. Vyhněte se ručnímu zadávání Ethereum adres. To může snadno vést k chybě v zadávání a ztrátě finančních prostředků.
+
+Různé aplikace se mohou lišit nebo používat jiný jazyk, ale pokud se snažíte převést finanční prostředky, měly by vás provést podobným procesem.
+
+1. Otevřete aplikaci peněženky.
+2. Klikněte na možnost "Přijmout" (nebo podobně formulovanou možnost).
+3. Zkopírujte Ethereum adresu do schránky.
+4. Poskytněte odesílateli svou přijímací Ethereum adresu.
+
+## Odesílání kryptoměn
+
+Chcete poslat ETH do jiné peněženky?
+
+1. Otevřete aplikaci peněženky.
+2. Zjistěte adresu příjemce a ujistěte se, že jste připojeni ke stejné síti jako příjemce.
+3. Zadejte adresu příjemce nebo naskenujte QR kód pomocí fotoaparátu, abyste nemuseli adresu psát ručně.
+4. Klikněte v peněžence na tlačítko "Odeslat" (nebo na podobně formulovanou alternativu).
+
+
+
+5. Mnoho aktiv, jako například DAI nebo USDC, existuje ve více sítích. Při převodu krypto tokenů se ujistěte, že příjemce používá stejnou síť jako vy, protože tyto tokeny nejsou zaměnitelné.
+6. Ujistěte se, že máte v peněžence dostatek ETH na pokrytí transakčního poplatku, který se liší v závislosti na podmínkách sítě. Většina peněženek automaticky připočte navrhovaný poplatek k transakci, kterou pak můžete potvrdit.
+7. Po zpracování transakce se na účtu příjemce objeví odpovídající částka v kryptoměnách. To může trvat od několika sekund do několika minut v závislosti na aktuálním vytížení sítě.
+
+## Připojování se k projektům
+
+Vaše adresa bude ve všech Ethereum projektech stejná. Na žádný projekt se nemusíte registrovat individuálně. Jakmile máte peněženku, můžete se připojit k jakémukoli Ethereum projektu bez dalších informací. Nejsou potřeba žádné e-maily ani jiné osobní údaje.
+
+1. Navštivte webové stránky jakéhokoli projektu.
+2. Pokud je vstupní stránka projektu pouze statickým popisem projektu, měli byste mít v nabídce možnost kliknout na tlačítko "Otevřít aplikaci", které vás přesměruje do skutečné webové aplikace.
+3. Jakmile jste v aplikaci, klikněte na "Připojit".
+
+
+
+4. Vyberte peněženku ze seznamu možností. Pokud svou peněženku nevidíte, může být skryta pod možností "WalletConnect".
+
+
+
+5. Potvrďte žádost o podpis v peněžence a navažte spojení. **Podepsání této zprávy by nemělo vyžadovat utracení žádných ETH**.
+6. A je to! Začněte aplikaci používat. Některé zajímavé projekty najdete na naší [stránce dApps](/apps/#explore).
+
+
+
+ Chcete se dozvědět více?
+
+ Podívejte se na naše další návody
+
+
+
+
+## Často kladené dotazy
+
+### Pokud mám ETH adresu, vlastním stejnou adresu i na jiných blockchainech?
+
+Stejnou adresu můžete používat na všech blockchainech kompatibilních s EVM (pokud máte peněženku s frází pro obnovení). Tento [seznam](https://chainlist.org/) vám ukáže, které blockchainy můžete používat se stejnou adresou. Některé blockchainy, jako například Bitcoin, implementují samostatnou sadu síťových pravidel a budete na nich potřebovat jinou adresu s jiným formátem. Pokud máte peněženku s chytrými kontrakty, měli byste se podívat na jejich webové stránky, kde najdete další informace o podporovaných blockchainech.
+
+### Mohu používat stejnou adresu na více zařízeních?
+
+Ano, stejnou adresu můžete použít na více zařízeních. Peněženky jsou technicky vzato pouze rozhraním, které vám ukazuje zůstatek a umožňuje provádět transakce, váš účet není uložen v peněžence, ale na blockchainu.
+
+### Neobdržel jsem krypto, kde mohu zkontrolovat stav transakce?
+
+Můžete použít [prohlížeče bloků](/developers/docs/data-and-analytics/block-explorers/), abyste viděli stav jakékoli transakce v reálném čase. Stačí vyhledat adresu peněženky nebo ID transakce.
+
+### Mohu transakce zrušit nebo vrátit?
+
+Ne, jakmile je transakce potvrzena, nelze ji zrušit.
diff --git a/public/content/translations/cs/guides/index.md b/public/content/translations/cs/guides/index.md
new file mode 100644
index 00000000000..a2ff6cc3b39
--- /dev/null
+++ b/public/content/translations/cs/guides/index.md
@@ -0,0 +1,27 @@
+---
+title: Ethereum návody
+description: Sbírka praktických návodů vysvětlujících základy používání Etherea pro začátečníky.
+lang: cs
+---
+
+# Ethereum návody
+
+Chcete se vydat na cestu za Ethereem? Naše praktické návody vás krok za krokem provedou začátky a usnadní vám orientaci v této nové technologii.
+
+## Začínáme
+
+1. [Jak si "vytvořit" Ethereum účet](/guides/how-to-create-an-ethereum-account/) - Peněženku si může zdarma vytvořit každý. Tento návod vám ukáže, kde začít.
+
+2. [Jak používat peněženku](/guides/how-to-use-a-wallet/) - Zjistěte, jak posílat a přijímat tokeny ve své peněžence a jak ji připojit k projektům.
+
+## Základy bezpečnosti
+
+1. [Jak zrušit přístup chytrého kontraktu k vašim krypto prostředkům](/guides/how-to-revoke-token-access/) - Pokud se ve vaší peněžence náhle objeví transakce, kterou jste neiniciovali, tento návod vás naučí, jak tomu zabránit.
+
+2. [Jak rozpoznat podvodné tokeny](/guides/how-to-id-scam-tokens/) - Co jsou podvodné tokeny? Způsoby, kterými se prezentují jako legitimní, a jak je identifikovat, abyste se chránili a vyhnuli se podvodům?
+
+## Používání Etherea
+
+1. [Jak přesunout tokeny na 2. vrstvu](/guides/how-to-use-a-bridge/) - Jsou transakce Etherea příliš nákladné? Zvažte přechod na řešení škálování Etherea nazývané 2. vrstvy.
+
+2. [Jak směnit tokeny](/guides/how-to-swap-tokens/) - Chcete směnit své tokeny za jiné? Tento jednoduchý návod vám ukáže, jak na to.
diff --git a/public/content/translations/cs/nft/index.md b/public/content/translations/cs/nft/index.md
index 99cca9fb4b2..6fe1c65015f 100644
--- a/public/content/translations/cs/nft/index.md
+++ b/public/content/translations/cs/nft/index.md
@@ -15,28 +15,28 @@ summaryPoint3: Běží na chytrých kontraktech na blockchainu Ethereum.
## Co jsou NFTéčka? {#what-are-nfts}
-NFT jsou tokeny, které jsou **individuálně jedinečné**. Každé NFT má jiné vlastnosti (nezaměnitelné) a je prokazatelně vzácné. V tom se liší od tokenů, jako je [ETH](/glossary/#ether), nebo jiných tokenů na Ethereu jako USDC, které jsou identické a mají stejné vlastnosti („zaměnitelné“). Obdobně jě vám jedno, kterou konkrétní dolarovou bankovku (nebo ETH) máte v peněžence, protože všechny jsou totožné a mají stejnou hodnotu. Ale _není_ vám jedno, které konkrétní NFT vlastníte, protože každé má individuální vlastnosti, které ho odlišují od ostatních („nezastupitelné“).
+NFT jsou tokeny, které jsou **individuálně jedinečné**. Každé NFT má jiné vlastnosti (nezaměnitelné) a je prokazatelně vzácné. V tom se liší od tokenů, jako je [ETH](/glossary/#ether) nebo jiné tokeny založené na Ethereu, jako je USDC, kde je každý token identický a má stejné vlastnosti („zaměnitelné“). Obdobně jě vám jedno, kterou konkrétní dolarovou bankovku (nebo ETH) máte v peněžence, protože všechny jsou totožné a mají stejnou hodnotu. Vám však _záleží_ na tom, které konkrétní NFT vlastníte, protože všechna mají individuální vlastnosti, které je odlišují od ostatních („nezaměnitelné“).
-Jedinečnost každého NFT umožňuje tokenizaci věcí, jako je umění, sběratelské předměty nebo dokonce nemovitosti, kde jedno konkrétní unikátní NFT představuje jednu konkrétní unikátní položku existující v reálném nebo digitálnm světě. Vlastnictví tohoto aktiva je veřejně dohledatelné na [blockchainu](/glossary/#blockchain) Ethereum.
+Jedinečnost každého NFT umožňuje tokenizaci věcí, jako je umění, sběratelské předměty nebo dokonce nemovitosti, kde jedno konkrétní unikátní NFT představuje jednu konkrétní unikátní položku existující v reálném nebo digitálnm světě. Vlastnictví aktiva je veřejně ověřitelné na [blockchainu](/glossary/#blockchain) Etherea.
-Nebo si představte vstupenku na sportovní událost. Stejně jako **si organizátor události může vybrat, kolik vstupenek bude prodávat**, může se tvůrce NFT rozhodnout, kolik kopií vytvoří. Někdy se jedná o přesné kopie, jako je 5 000 všeobecných vstupenek. Někdy je vytvořených několik NFT, která jsou velmi podobná, ale každé mírně odlišné, jako například vstupenka s přiděleným sedadlem. Ty lze kupovat a prodávat peer-to-peer bez placení prodejcům vstupenek a kupující se vždy může ujistit o pravosti vstupenky pomocí kontroly adresy kontraktu.
+Nebo si představte vstupenku na sportovní událost. Stejně jako si **organizátor události může vybrat, kolik vstupenek prodá**, může tvůrce NFT rozhodnout, kolik replik existuje. Někdy se jedná o přesné kopie, jako je 5 000 všeobecných vstupenek. Někdy je vytvořených několik NFT, která jsou velmi podobná, ale každé mírně odlišné, jako například vstupenka s přiděleným sedadlem. Ty lze kupovat a prodávat peer-to-peer bez placení prodejcům vstupenek a kupující se vždy může ujistit o pravosti vstupenky pomocí kontroly adresy kontraktu.
-**NFT na ethereum.org slouží k prokázání, že lidé smysluplně přispěli** do našeho Github repozitáře (naprogramovali web, napsali nebo upravili článek...), přeložili náš obsah, nebo se zúčastnili našeho komunitního hovoru. Také máme naše vlastní doménové jméno spojené s NFT. Pokud budete přispívat na ethereum.org, můžete získat [POAP](/glossary/#poap) NFT. Některé krypto meetupy používají POAPy jako vstupenky. [Více o přispívání](/contributing/#poap).
+Na ethereum.org se **NFT používají k prokázání, že lidé smysluplně přispěli** do našeho repozitáře na GitHubu (naprogramovali web, napsali nebo upravili článek...), přeložili náš obsah nebo se zúčastnili našich komunitních hovorů, a dokonce máme i vlastní název domény NFT. Pokud přispějete na ethereum.org, můžete získat [POAP](/glossary/#poap) NFT. Některé krypto meetupy používají POAPy jako vstupenky. [Více o přispívání](/contributing/#poap).
-Tato webová stránka má také alternativní název domény využívající NFT, **ethereum.eth**. Naše adresa `.org` je centrálně spravována poskytovatelem doménových jmen (DNS), zatímco ethereum`.eth` je registrována na síti Ethereum prostřednictvím Ethereum Name Service (ENS). A je vlastněná a ovládaná námi. [Podívejte se na náš ENS záznam.](https://app.ens.domains/name/ethereum.eth)
+Tento web má také alternativní název domény využívající NFT, **ethereum.eth**. Naše adresa `.org` je centrálně spravována poskytovatelem systému doménových jmen (DNS), zatímco ethereum`.eth` je registrována na Ethereu prostřednictvím Ethereum Name Service (ENS). A je vlastněná a ovládaná námi. [Zkontrolujte náš záznam ENS](https://app.ens.domains/name/ethereum.eth)
[Více o ENS](https://app.ens.domains)
@@ -79,21 +79,21 @@ Tato webová stránka má také alternativní název domény využívající NFT
## Jak fungují NFT? {#how-nfts-work}
-Stejně jako kterékoliv digitální předměty na Ethereum blockchainu jsou NFT vytvářeny skrze speciální počítačový program založený na Ethereu s názvem „chytrý kontrakt“. Tyto kontrakty fungují podle specifických pravidel, jako jsou standardy [ERC-721](/glossary/#erc-721) nebo [ERC-1155](/glossary/#erc-1155), které určují, jaké operace může kontrakt vykonávat.
+Stejně jako kterékoliv digitální předměty na Ethereum blockchainu jsou NFT vytvářeny skrze speciální počítačový program založený na Ethereu s názvem „chytrý kontrakt“. Tyto kontrakty se řídí určitými pravidly, jako jsou standardy [ERC-721](/glossary/#erc-721) nebo [ERC-1155](/glossary/#erc-1155), které určují, co kontrakt může dělat.
Chytrý kontrakt NFT může dělat několik klíčových věcí:
-- **Vytvářet NFT:**Může vytvořit nové NFT.
-- **Přiřadit vlastnictví:**Zaznamenává, kdo vlastní určité NFT, a to tak, že je spojuje s konkrétními adresami Etherea.
-- **Přiřadit každému NFT jeho číslo:** Každé NFT má své číslo, které ho dělá unikátním. Navíc bývají u NFT většinou přiřazeny nějaké informace (metadata), které popisují, co dané NFT reprezentuje.
+- **Vytváření NFT:** Může vytvářet nová NFT.
+- **Přiřazování vlastnictví:** Sleduje, kdo vlastní které NFT, tím, že je propojuje s konkrétními adresami na Ethereu.
+- **Přiřazení ID každému NFT:** Každé NFT má číslo, které ho činí jedinečným. Navíc bývají u NFT většinou přiřazeny nějaké informace (metadata), které popisují, co dané NFT reprezentuje.
Když někdo "vytvoří" nebo "vytěží" nějaké NFT, tak prakticky říkají chytrému kontraktu, aby mu předal vlastnictví daného NFT. Tato informace je bezpečně a veřejně uložena na blockchainu.
Tvůrce kontraktu může navíc přidat další pravidla. Může nastavit kolik má být daného NFT vytvořeno nebo může rozhodnout, že dostane malý autorský poplatek, kdykoliv NFT změní svého majitele.
-### Zabezpečení NFT {#nft-security}
+### Bezpečnost NFT {#nft-security}
-Ethereum je zabezpečeno [mechanismem důkazu podílem](/glossary/#pos). Systém je navržen tak, aby ekonomicky bránil zlovolným akcím, takže Ethereum je chráněno proti neoprávněným zásahům. To je to, co umožňuje NFT fungovat. Jakmile bude [blok](/glossary/#block) obsahující vaši NFT transakci [dokončen](/glossary/#finality), změnit ho by stálo útočníka miliony ETH. Každý, kdo používá Ethereum software, by byl okamžitě schopen odhalit nepoctivé a nedovolené zásahy týkající se NFT a záškodník by byl ekonomicky penalizován a vykázán.
+Bezpečnost Etherea pochází z [důkazu podílem](/glossary/#pos). Systém je navržen tak, aby ekonomicky bránil zlovolným akcím, takže Ethereum je chráněno proti neoprávněným zásahům. To je to, co umožňuje NFT fungovat. Jakmile se [blok](/glossary/#block) obsahující vaši transakci NFT stane [finalizovaným](/glossary/#finality), stálo by útočníka miliony ETH, kdyby ho chtěl změnit. Každý, kdo používá Ethereum software, by byl okamžitě schopen odhalit nepoctivé a nedovolené zásahy týkající se NFT a záškodník by byl ekonomicky penalizován a vykázán.
Bezpečnostní otázky týkající se NFT se nejčastěji týkají podvodů s phishingem, zranitelnosti chytrých kontraktů nebo uživatelské chyby (jako je neúmyslné odhalení privátního klíče). Dobrá ochrana peněženky je tedy pro majitele NFT klíčovou.
@@ -101,13 +101,14 @@ Bezpečnostní otázky týkající se NFT se nejčastěji týkají podvodů s ph
Více o bezpečnosti
-## Další informace {#further-reading}
+## Další čtení {#further-reading}
-- [Průvodce NFT](https://linda.mirror.xyz/df649d61efb92c910464a4e74ae213c4cab150b9cbcc4b7fb6090fc77881a95d) – _Linda Xie, leden 2020_
-- [EtherscanNFT tracker](https://etherscan.io/nft-top-contracts)
-- [Standart tokenu ERC-721](/developers/docs/standards/tokens/erc-721/)
-- [Standart tokenu ERC-1155](/developers/docs/standards/tokens/erc-1155/)
-- [Oblíbené aplikace a nástroje NFT](https://www.ethereum-ecosystem.com/blockchains/ethereum/nfts)
+- [Průvodce NFT pro začátečníky](https://linda.mirror.xyz/df649d61efb92c910464a4e74ae213c4cab150b9cbcc4b7fb6090fc77881a95d) – _Linda Xie, leden 2020_
+- [Etherscan NFT tracker](https://etherscan.io/nft-top-contracts)
+- [Blockscout NFT tracker](https://eth.blockscout.com/tokens?type=ERC-721,ERC-1155,ERC-404)
+- [Tokenový standard ERC-721](/developers/docs/standards/tokens/erc-721/)
+- [Tokenový standard ERC-1155](/developers/docs/standards/tokens/erc-1155/)
+- [Populární NFT aplikace a nástroje](https://www.ethereum-ecosystem.com/blockchains/ethereum/nfts)
## Další zdroje {#other-resources}
diff --git a/public/content/translations/cs/payments/index.md b/public/content/translations/cs/payments/index.md
new file mode 100644
index 00000000000..17e1ceab484
--- /dev/null
+++ b/public/content/translations/cs/payments/index.md
@@ -0,0 +1,208 @@
+---
+title: Ethereum platby
+metaTitle: Platby na Ethereu
+description: Přehled plateb na Ethereu
+lang: cs
+template: use-cases
+emoji: ":frame_with_picture:"
+sidebarDepth: 2
+image: /images/impact_transparent.png
+alt: Logo Eth zobrazené s podávajícíma si rukama.
+summaryPoint1: Svět, kde se peníze pohybují stejně volně jako informace
+summaryPoint2: Otevřené a globální, umožňující bezhraniční transakce pro všechny
+summaryPoint3: Platby přijaté do minuty
+---
+
+Každý den čelí miliony lidí stejné výzvě: přesouvání peněz přes hranice je pomalé, drahé a často frustrující. Nezávislý pracovník na Bali čeká dny na zúčtování platby od svého klienta z New Yorku. To se týká zejména lidí v regionech s omezenou bankovní infrastrukturou, což jim ztěžuje účastnit se globální ekonomiky.
+
+To není žádný vzdálený sen – děje se to dnes na Ethereu. Zatímco tradiční finanční instituce vybudovaly v průběhu desetiletí robustní platební systémy, často zůstávají omezeny hranicemi, pracovní dobou a starší infrastrukturou. Ethereum nabízí nové paradigma: globální finanční platformu fungující 24/7, která umožňuje téměř okamžité, programovatelné transakce pro kohokoli s přístupem k internetu.
+
+
+
+
+
+
+
+## Remitence: levnější mezinárodní převody {#remittances}
+
+Pro miliony lidí pracujících v zahraničí je posílání peněz domů pravidelnou nutností. Tradiční remitenční služby jsou často spojeny s vysokými poplatky a pomalou dobou zpracování. Ethereum nabízí zajímavou alternativu.
+
+
+
+
+## Přístup ke globálním měnám {#access-to-global-currencies}
+
+V mnoha zemích je inflace naléhavým problémem, často doprovázeným omezeným přístupem k cizím měnám. Lidé v těchto situacích se snaží uchovat si své bohatství, protože jsou nuceni držet rychle znehodnocující se úspory.
+
+Komunita Etherea vytvořila **robustní alternativní finanční systém**, který je nezávislý na měnové politice nebo kontrole jakéhokoli státu.
+
+Uživatelé Etherea mohou používat **stablecoiny – tokeny obvykle vázané na silné měny, jako je americký dolar**. Tím, že lidé vydělávají a spoří v kryptoměně, se mohou chránit před vysokou inflací ve své zemi, což jim pomáhá zachovat nebo dokonce zvýšit jejich kupní sílu. To také umožňuje snadnější platby za zboží a služby, jak na místní, tak na globální úrovni.
+
+
+ Více o stablecoinech
+
+
+## Nákup zboží a platby za služby {#buying-goods-and-payment-for-services}
+
+Mnoho podniků začíná přijímat ether (ETH) a další kryptoměny jako platbu. Například:
+
+- **Newegg:** Populární prodejce elektroniky přijímá Ethereum pro nákupy ve vybraných zemích.
+- **Travala.com:** Tato platforma pro rezervaci cestování umožňuje uživatelům platit za hotely a lety pomocí Etherea.
+- **Shopify:** Tato populární e-commerce platforma, která slouží jako platforma pro hostování podniků, také přijímá platby za zboží a služby pomocí Etherea.
+- **Sotheby's:** Tato organizace obchoduje s výtvarným a dekorativním uměním, šperky a sběratelskými předměty a umožňuje platby pomocí Etherea a dalších kryptoměn.
+
+Země jako El Salvador a Středoafrická republika dokonce přijaly kryptoměny jako zákonné platidlo, což připravuje půdu pro širší přijetí plateb Ethereem v každodenních transakcích.
+
+V zemích, kde byly jejich platební prostředky odpojeny od zbytku světa, představovaly platební řešení s integrací kryptoměn obrovskou úlevu. Platby za předplatné na platformách jako Netflix, Spotify a za vzdělávací kurzy jsou nyní usnadněny prostřednictvím krypto platebních platforem jako Gnosis Pay a Paypal.
+
+
+
+ Vytvořte si svůj účet Ethereum ještě dnes pomocí peněženkové aplikace.
+
+ Začněte
+
+
+
+
+## Plaťte pomocí self-custodial krypto karet {#pay-with-self-custodial-crypto-cards}
+
+Self-custodial krypto karty fungují, jako když používáte vlastní batoh, místo toho, abyste si peníze zamykali do trezoru někoho jiného. U tradiční karty drží vaše prostředky banka nebo správce a uvolňuje je, když utrácíte. Se self-custodial kartami máte svá aktiva neustále pod kontrolou – bez prostředníka – a přitom můžete stále platit pípnutím nebo přejetím karty za kávu, potraviny nebo dokonce letenku.
+
+Tyto karty se přímo propojují s non-custodial peněženkami nebo účty s chytrými kontrakty, což uživatelům umožňuje utrácet ETH a stablecoiny v běžných situacích, aniž by se vzdali vlastnictví. Na rozdíl od custodial karet, které vyžadují, aby uživatelé vložili prostředky u třetí strany, self-custodial karty umožňují platby v reálném světě, jako jsou Visa a Mastercard, a zároveň zachovávají kontrolu na blockchainu.
+
+### Příklady {#crypto-cards-examples}
+
+- **MetaMask Card:** Propojená s peněženkou MetaMask, tato debetní karta Mastercard umožňuje uživatelům utrácet ETH, stablecoiny a další podporované tokeny. Podporuje Apple Pay a Google Pay, zahrnuje odměny v podobě krypto cashbacku a nabízí možnosti získávání výnosů.
+
+- **Tuyo Card:** Karta Visa založená na chytrém kontraktu, která automaticky převádí krypto na USDC pro útratu všude, kde je Visa přijímána. Uživatelé si ponechávají svá aktiva ve vlastní správě s přístupem k funkcím pro výnos, obchodování a utrácení.
+
+- **Gnosis Pay:** První self-custodial karta Visa propojená s chytrým účtem Gnosis Safe. Uživatelé utrácejí krypto přímo ze své peněženky bez poplatků za gas, FX nebo off-ramping. Podporována je také personalizace karty prostřednictvím Ethereum Name Service (ENS).
+
+- **Ether.Fi Cash card:** Integrovaná se staking protokolem ether.fi, tato karta umožňuje uživatelům utrácet, zatímco jejich ETH zůstává stakované. Platby jsou zpracovávány prostřednictvím chytrých kontraktů, přičemž je zachována self-custody i během útraty.
+
+### Porovnání self-custodial krypto karet {#crypto-card-custody-comparison}
+
+| **Krypto karta** | **Self-custodial** | **Nekótované** | **Klíčové poznámky** |
+| ----------------------------- | :----------------: | :------------: | ---------------------------------------------------------------------------------------------------------- |
+| MetaMask Card | ✅ | ✅ | Peněženka zůstává v MetaMask; automatický off-ramp při platbě |
+| Tuyo Card | ✅ | ✅ | Chytrá peněženka převádí na USDC; uživatel si ponechává kontrolu |
+| Gnosis Pay | ✅ | ✅ | Propojeno s Gnosis Safe uživatele; během používání nedochází k přesunu správy (custody) |
+| Ether.Fi Cash | ✅ | ✅ | ETH zůstává stakované; chytrý kontrakt řídí přístup k útratě. |
+
+> **Poznámka:** „Self-custodial“ označuje peněženky ovládané uživatelem, kde má uživatel plný přístup a kontrolu nad svými prostředky.
+> „Non-custodial“ označuje peněženky, kde jsou prostředky spravovány bez správy třetí stranou, často prostřednictvím chytrých kontraktů.
+> Zatímco všechny self-custodial karty jsou non-custodial, ne všechny non-custodial karty jsou self-custodial.
+
+## Mikroplatby pro webové stránky a agenty (x402) {#x402}
+
+[x402](https://www.x402.org/) je otevřený platební standard, který přináší na web nativní platby za jednotlivá použití. Používáním [stablecoinů](/stablecoins/) v nízkonákladových [sítích druhé vrstvy Etherea](/layer-2/) standard x402 činí ekonomickým, aby lidé a stroje platili přímo za jedinou akci, jako je přečtení zpravodajského článku nebo volání API, namísto správy API klíčů, předplatných nebo „placení“ věnováním pozornosti reklamě.
+
+- **Odstranění paywallů a přihlášení:** Místo vytváření účtu a sdílení osobních údajů pro přečtení jednoho zpravodajského článku může vaše peněženka zaplatit pár centů potřebných k jeho odemknutí.
+- **Platby pro agenty AI:** x402 umožňuje autonomnímu softwaru („agentům AI“) platit za data a volání API, které potřebují k fungování, bez lidského zásahu.
+
+### Jak funguje platební standard x402 {#x402-how}
+
+Když klient požaduje zdroj, server odešle chybový kód `402 Payment Required` spolu s platebními instrukcemi (cena, účet a jaké tokeny a řetězce jsou podporovány).
+
+- Vaše [peněženka](/wallets/) detekuje požadavek a zpracuje platbu (často jediným kliknutím pro schválení nebo automaticky pomocí předem schváleného limitu)
+- [Agenti AI](/ai-agents/) s přístupem k předem schváleným zůstatkům v peněžence mohou automaticky detekovat cenu a okamžitě zaplatit za přístup k datům nebo službám
+- Klient musí mít v peněžence jeden z podporovaných stablecoinů, ale nemusí mít žádné ETH na [poplatky za gas](/gas/)
+
+To odemyká novou „machine to machine“ ekonomiku, kde si agenti AI mohou sami nakupovat zdroje a kde lze efektivněji přistupovat ke službám API.
+
+Podepsaná zpráva je poté doručena na server. Servery obvykle používají [facilitátora x402](https://x402.gitbook.io/x402/core-concepts/facilitator) k řešení složitosti blockchainu (odeslání transakce, získání platby, zprostředkování poplatků za gas atd.), což znamená, že vývojáři mohou snadno přijímat krypto mikroplatby, aniž by museli spravovat platební infrastrukturu.
+
+## Výplaty mezd {#salary-payments}
+
+Mnoho progresivních společností nyní nabízí zaměstnancům možnost pobírat své mzdy nebo jejich část v kryptoměnách, jako je ether (ETH):
+
+- **Gipsybee:** je organizace, která se zabývá elektronikou, robotikou, tvorbou her a dalšími službami. Dávají zaměstnancům možnost nechat si vyplácet mzdu v Ethereu.
+- **SC5:** Tato finská společnost byla jednou z prvních, která nabídla mzdy v Bitcoinu, čímž připravila půdu pro podobná ujednání s Ethereem.
+- **Blockchainové startupy:** Mnoho společností v oblasti blockchainu přirozeně nabízí svým zaměstnancům možnost výplaty v kryptoměnách.
+- **DAO:** Vzhledem ke specifičnosti a rozmanitosti přispěvatelů do DAO je většina příspěvků a platů odměňována v kryptoměně.
+
+Tento trend oslovuje zejména pracovníky na dálku a digitální nomády, kteří mohou těžit z bezhraničních plateb a potenciálně příznivých směnných kurzů.
+
+## Globální humanitární pomoc {#global-relief-efforts}
+
+V únoru 2023, když ničivá zemětřesení zasáhla Turecko a Sýrii, se globální krypto komunita pustila do akce. Byly spuštěny různé kampaně na sběr finančních prostředků na pomoc, které ukázaly sílu Etherea v dobách krize. Přestože krypto [nebylo v Turecku uznávanou formou](https://www.reuters.com/technology/no-more-kebabs-bitcoins-turkeys-crypto-payment-ban-looms-2021-04-28/) platby, úřady udělaly [výjimky](https://x.com/haluklevent/status/1622913175409623041) pro některé organizace, aby mohly sbírat dary. Některé příklady jsou:
+
+- [Refik Anadol](https://x.com/refikanadol/status/1622623521104089090): je renomovaný digitální umělec, který inicioval sbírkovou kampaň.
+- Síla DAO: [Anka Relief DAO](https://ankarelief.org/) a [Bankless DAO](https://x.com/banklessDAO) spojily síly s [Giveth](https://x.com/Giveth/status/1623493672149843969) za účelem sběru finančních prostředků.
+- [Pak](https://cause.quest/), prominentní umělec NFT, také přispěl na tuto věc.
+- Dokonce i spoluzakladatel Etherea [Vitalik Buterin](https://cointelegraph.com/news/vitalik-buterin-donates-227k-to-help-earthquake-victims-in-turkey-syria) osobně přispěl do několika kampaní.
+
+Výsledek? Během několika dní se vybralo přes 6 milionů dolarů, jak je sledováno na panelu [Dune](https://dune.com/davy42/turkiye-earthquake-donations) Analytics.
+
+Podobně rychlé reakce byly i na tragédie, které se staly v Indii a na Ukrajině. Tato rychlá reakce zdůrazňuje klíčovou výhodu plateb Ethereem, kterou je schopnost rychle mobilizovat globální podporu bez překážek v podobě konverze měn, zdlouhavých bankovních převodů nebo přemrštěných poplatků.
+
+
+
+
+
+
+
+## Ethereum vs. fiat {#ethereum-vs-fiat}
+
+Abyste skutečně ocenili dopad plateb Ethereem, stojí za to je porovnat s tradičními fiat měnami:
+
+| | **Ethereum** | **Tradiční banky** |
+| --------------------- | -------------------------- | ------------------------------------------------------- |
+| **Rychlost** | Sekundy až minuty | Hodiny až dny |
+| **Globální dosah** | Bez hranic, 24/7 | Podléhá mezinárodním bankovním omezením a pracovní době |
+| **Transparentnost** | Plně transparentní | Liší se podle instituce |
+| **Programovatelnost** | Podpora chytrých kontraktů | Omezeno na základní transakce |
+| **Kontrola inflace** | Předvídatelné vydávání | Podléhá politikám centrální banky |
+| **Přístupnost** | Kdokoli s internetem | Podléhá národním a mezinárodním omezením |
+
+Ve svém jádru je Ethereum decentralizovaná platforma, která umožňuje bezpečné, rychlé a transparentní transakce. Mnoho komponentů jej však odlišuje od tradičních platebních metod. Pojďme se ponořit do výhod, které z plateb Ethereem dělají převratnou záležitost:
+
+### Programovatelnost {#programmability}
+
+Jednou z jedinečných vlastností Etherea je jeho schopnost podporovat chytré kontrakty. Chytré kontrakty jsou samospustitelné smlouvy s podmínkami napsanými přímo do kódu. To otevírá svět možností pro automatizované, podmíněné platby, které mohou výrazně zlepšit transakce, jako jsou:
+
+- Služby úschovy (escrow)
+- Opakované platby
+- Odměňování na základě výkonu
+
+### Rychlost {#speed}
+
+Pamatujete si, kdy jste naposledy čekali dny na zúčtování mezinárodního bankovního převodu? Dlouhá fronta? A ty spousty formulářů, které jste museli vyplnit? S Ethereem jsou ty dny dávno pryč. Transakce v síti Ethereum se vypořádají během několika minut bez ohledu na to, kde se odesílatel a příjemce nacházejí. Protože je Ethereum permissionless (bez nutnosti povolení), při posílání peněz neexistuje žádná regulační byrokracie. Tato rychlost je obzvláště klíčová v časově citlivých situacích, jako je například pomoc při mimořádných událostech.
+
+### Nižší poplatky {#lower-fees}
+
+Poplatky za tradiční mezinárodní převody peněz někdy pohltí významnou část odeslané částky, zejména u transakcí v řádu stovek dolarů. Transakce na Ethereu, i když nejsou zdarma, jsou často spojeny s nižšími poplatky. To znamená, že více vašich peněz jde tam, kam chcete, a ne do kapes zprostředkovatelů.
+
+### Transparentnost {#transparency}
+
+Každá transakce na blockchainu Ethereum je zaznamenána ve veřejné účetní knize. To znamená, že kdokoli si může ověřit pohyb finančních prostředků, což z něj činí vynikající nástroj pro:
+
+- Charitativní organizace, aby ukázaly, jak jsou dary využívány
+- Podniky, aby prokázaly platby dodavatelům nebo zaměstnancům
+- Jednotlivci, aby si udrželi přehled o svých finančních aktivitách
+
+S Ethereem může každý vidět, jak se peníze pohybují a jak jsou implementovány náklady, na rozdíl od tradičních organizací, kde většina z toho zůstává neznámá.
+
+
+
+
+
+
+
+Zatímco fiat měny mají výhodu širokého přijetí a stability, Ethereum nabízí jedinečné výhody, které z něj činí atraktivní možnost pro určité typy transakcí.
+
+Od usnadnění rychlé pomoci při katastrofách až po posílení postavení globálních pracovníků píší platby Ethereem novou kapitolu v dlouhé historii peněz. I když výzvy přetrvávají, jedinečné výhody, které tato technologie nabízí, z ní činí atraktivní volbu pro širokou škálu případů použití.
+
+
+
+ Je čas si pořídit vlastní účet Ethereum.
+
+ Začněte!
+
+
+
diff --git a/public/content/translations/cs/prediction-markets/index.md b/public/content/translations/cs/prediction-markets/index.md
new file mode 100644
index 00000000000..d29a30a44f0
--- /dev/null
+++ b/public/content/translations/cs/prediction-markets/index.md
@@ -0,0 +1,85 @@
+---
+title: Predikční trhy
+lang: cs
+template: use-cases
+image: /images/use-cases/prediction-markets.png
+sidebarDepth: 2
+summaryPoint1: Získejte finanční pobídky za vytváření přesných předpovědí
+summaryPoint2: Vysoce kvalitní předpovědi budoucích událostí
+buttons:
+ - content: Další informace
+ toId: how-prediction-markets-work
+ - content: Prozkoumat aplikace
+ toId: find-a-prediction-market
+ isSecondary: false
+---
+
+Predikční trhy využívají moudrost davu a finanční pobídky k předpovídání událostí. Nabízejí rozmanitá, vysoce kvalitní data a na popularitě získaly v roce 2024 během amerických voleb.
+
+## Jak fungují predikční trhy {#how-prediction-markets-work}
+
+Na rozdíl od tradičních metod prognózování, které se opírají o názory odborníků, omezené vzorky průzkumů nebo historická data, využívají predikční trhy **finanční pobídky v reálném čase** a **moudrost davu** k vytváření přehledů týkajících se konkrétní události – voleb, cen kryptoměn, sportovních výsledků – čehokoliv.
+
+To umožňuje komukoli signalizovat podporu určitého výsledku finančním závazkem.
+Tím, že se umožní sázení na události v reálném světě a ceny se upravují s příchodem nových informací, jsou informované názory hodnoceny výše a přesnost může být odměněna.
+
+Teoreticky, protože sázející mohou ze správných odhadů profitovat, mohou predikční trhy předpovídat výsledky s velkou přesností. Predikční trhy založené na blockchainu jsou ještě zajímavější, protože prakticky kdokoli se může podílet na prognózování a získávat odměny ve stabilních kryptoměnách nebo kryptoměnách.
+
+## Proč je to důležité? {#why-does-this-matter}
+
+Na rozdíl od tradičního prognózování jsou predikční trhy založené na blockchainu:
+
+
+
+
+I jako pozorovatel trhu můžete posoudit cenná data, která by jinak nebyla k dispozici. Představte si to takto:
+
+1. Předpovědi jsou vázány na konkrétní událost (např. bude Beam Chain nasazen do roku 2030?).
+2. Účastníci trhu nakupují a prodávají akcie na základě své důvěry v jakýkoli výsledek.
+3. Ceny se upravují, jakmile více účastníků vsadí na svá přesvědčení, což odráží poznatky v reálném čase.
+4. Každý, kdo sází správně, vydělává úměrně vsazené částce.
+5. Pozorovatelé trhu mohou využít otevřená data k informování výzkumu nebo diskuse.
+
+## Najděte si predikční trh {#find-a-prediction-market}
+
+Existuje několik dostupných predikčních trhů založených na Ethereu. Toto jsou některé z nejznámějších predikčních trhů současnosti:
+
+
+
+
+ Mějte na paměti rizika
+ Sázejte pouze to, co si můžete dovolit, a buďte si vědomi možného návykového chování.
+
+
+
+
+## Výzvy a rizika {#challenges-and-risks}
+
+Predikční trhy na blockchainu čelí několika výzvám, které mohou ovlivnit spravedlnost, zákonnost a přesnost.
+
+⚠️ **Manipulace s trhem** – Bohatí hráči mohou zkreslovat výsledky prostřednictvím wash tradingu.
+💧 **Problémy s likviditou** – Nízká účast ([nízká likvidita](https://www.investopedia.com/terms/t/thinmarket.asp)) může snížit spolehlivost trhu.
+🏛 **Regulační nejistota** – Vlády zavedly omezení pro některé platformy.
+
+Aby se tyto problémy zmírnily, vývojáři Etherea experimentují s řešeními, jako je futarchie (správa pomocí predikčních trhů) a decentralizované ověřování identity.
+
+## Experimentování s predikčními trhy {#experimenting-with-prediction-markets}
+
+Predikční trhy přetvářejí rozhodování v digitálním věku. Využitím Etherea nabízejí **spravedlivé, otevřené a odměňující způsoby, jak předpovídat budoucnost.**
+
+Existuje mnoho způsobů, jak využít nástroje pro prognózování i mimo finanční zisk. Například v [návrhu na vylepšení DevConu](https://forum.devcon.org/t/futarchy-decision-markets-for-deciding-next-devcon/5305) (DIP) bylo navrženo, aby organizátoři DevConu používali predikční trhy k předvídání účasti na budoucích událostech.
+
+To by pomohlo organizátorům určit, které místo by vedlo k největší události, v porovnání s tím, které místo by bylo nejvíce mezinárodně dostupné. Výhody tohoto postupu znamenají, že organizátoři DevConu mohou zkrátit dobu potřebnou k prověření více
+vízových politik, dostupnosti letišť a nákladů na život v dané oblasti a zároveň shromažďovat údaje o tom, kam by se potenciální účastníci rádi podívali.
+
+## Další čtení {#further-reading}
+
+[Od predikčních trhů k info financím](https://vitalik.eth.limo/general/2024/11/09/infofinance.html) – Vitalik Buterin
+[Vývoj decentralizovaných predikčních trhů na Ethereu](https://blockchain.oodles.io/dev-blog/decentralized-prediction-market-development-ethereum/)
+[Bílá kniha projektu Augur](https://github.com/AugurProject/whitepaper)
\ No newline at end of file
diff --git a/public/content/translations/cs/privacy/index.md b/public/content/translations/cs/privacy/index.md
new file mode 100644
index 00000000000..9f07e2e7a76
--- /dev/null
+++ b/public/content/translations/cs/privacy/index.md
@@ -0,0 +1,97 @@
+---
+title: Soukromí na Ethereu
+description: Nástroje a techniky pro ochranu vašeho soukromí na Ethereu
+lang: cs
+---
+
+# Soukromí na Ethereu {#introduction}
+
+Soukromí je nejen nezbytné pro osobní bezpečnost, je to základní kámen svobody a klíčový [garant decentralizace](https://vitalik.eth.limo/general/2025/04/14/privacy.html). Soukromí dává lidem možnost svobodně se vyjadřovat, obchodovat s ostatními a organizovat komunity. Stejně jako u všech blockchainů je však soukromí v případě veřejné účetní knihy Etherea náročné.
+
+Ethereum je z podstaty transparentní. Každá akce na blockchainu je viditelná pro každého, kdo se podívá. Ačkoli Ethereum nabízí pseudonymitu propojením vaší aktivity s [veřejným klíčem](/decentralized-identity/#public-key-cryptography) namísto identity v reálném světě, vzorce aktivity by mohly být analyzovány za účelem odhalení citlivých informací a identifikace uživatelů.
+
+Zabudování nástrojů pro ochranu soukromí do Etherea může lidem, organizacím a institucím pomoci bezpečně interagovat a zároveň omezit zbytečné odhalení. Díky tomu je ekosystém bezpečnější a praktičtější pro širší škálu případů použití.
+
+## Ochrana soukromí při zápisech {#privacy-of-writes}
+
+Ve výchozím nastavení je každá transakce zapsaná na Ethereu veřejná a trvalá. To zahrnuje nejen posílání ETH, ale také registraci jmen ENS, sbírání POAP nebo obchodování s NFT. Každodenní akce, jako jsou platby, hlasování nebo ověření totožnosti, mohou odhalit vaše informace nezamýšleným stranám. Existuje několik nástrojů a technik, které mohou pomoci zvýšit jejich soukromí:
+
+### Mixovací protokoly (neboli „mixéry“) {#mixing-protocols}
+
+Mixéry přerušují spojení mezi odesílateli a příjemci tím, že transakce mnoha uživatelů vkládají do sdíleného „poolu“ a poté umožňují lidem pozdější výběr na novou adresu. Jelikož jsou vklady a výběry promíchány, je pro pozorovatele mnohem těžší je spojit.
+
+_Příklady: [PrivacyPools](https://docs.privacypools.com/), [Tornado Cash](https://tornado.cash/)_
+
+### Stíněné pooly {#shielded-pools}
+
+Stíněné pooly jsou podobné mixérům, ale umožňují uživatelům držet a převádět finanční prostředky soukromě uvnitř samotného poolu. Namísto pouhého zatemnění spojení mezi vkladem a výběrem si stíněné pooly udržují trvalý soukromý stav, často zabezpečený důkazy s nulovou znalostí. To umožňuje vytvářet soukromé převody, soukromé zůstatky a další.
+
+_Příklady: [Railgun](https://www.railgun.org/), [Aztec](https://aztec.network/), Nightfall_
+
+### Skryté adresy {#stealth-addresses}
+
+[Skrytá adresa](https://vitalik.eth.limo/general/2023/01/20/stealth.html) je jako dát každému odesílateli jedinečnou, jednorázovou poštovní přihrádku, kterou můžete otevřít jen vy. Pokaždé, když vám někdo pošle kryptoměnu, přijde na novou adresu, takže nikdo jiný neuvidí, že všechny tyto platby patří vám. Díky tomu zůstává vaše platební historie soukromá a hůře sledovatelná.
+
+_Příklady: [UmbraCash](https://app.umbra.cash/faq), [FluidKey](https://www.fluidkey.com/)_
+
+### Další případy použití {#other-use-cases}
+
+Mezi další projekty zkoumající soukromé zápisy patří [PlasmaFold](https://pse.dev/projects/plasma-fold) (soukromé platby) a systémy jako [MACI](https://pse.dev/projects/maci) a [Semaphore](https://pse.dev/projects/semaphore) (soukromé hlasování).
+
+Tyto nástroje rozšiřují možnosti soukromého zápisu na Ethereu, ale každý z nich má své kompromisy. Některé přístupy jsou stále experimentální, některé zvyšují náklady nebo složitost a některé nástroje, jako jsou mixéry, mohou čelit právnímu nebo regulačnímu přezkumu v závislosti na tom, jak jsou používány.
+
+## Ochrana soukromí při čtení {#privacy-of-reads}
+
+Čtení nebo kontrola jakýchkoli informací na Ethereu (např. zůstatku v peněžence) obvykle probíhá prostřednictvím služby, jako je poskytovatel vaší peněženky, poskytovatel uzlů nebo prohlížeč bloků. Protože se na ně spoléháte, že za vás přečtou blockchain, mohou také vidět vaše požadavky spolu s metadaty, jako je vaše IP adresa nebo poloha. Pokud stále kontrolujete stejný účet, tyto informace lze poskládat a propojit vaši identitu s vaší aktivitou.
+
+Provoz vlastního uzlu Etherea by tomu zabránil, ale ukládání a synchronizace celého blockchainu zůstává pro většinu uživatelů nákladná a nepraktická, zejména na mobilních zařízeních.
+
+Mezi některé projekty zkoumající soukromé čtení patří [Private Information Retrieval](https://hackmd.io/@brech1/ethereum-privacy-pir?utm_source=preview-mode&utm_medium=rec) (PIR, získání dat bez odhalení toho, co hledáte), [zkID](https://hackmd.io/@brech1/ethereum-privacy-pir?utm_source=preview-mode&utm_medium=rec) (soukromé ověření identity s důkazy s nulovou znalostí), [vOPRF](https://pse.dev/projects/voprf) (používání účtů Web2 pseudonymně ve Web3), [vFHE](https://pse.dev/blog/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-1) (výpočty na zašifrovaných datech) a [MachinaIO](https://pse.dev/projects/machina-io) (skrytí podrobností programu při zachování funkčnosti).
+
+## Ochrana soukromí při prokazování {#privacy-of-proving}
+
+Důkazy chránící soukromí jsou nástroje, které můžete na Ethereu použít k prokázání, že je něco pravda, aniž byste odhalili zbytečné podrobnosti. Můžete například:
+
+- Prokázat, že je vám více než 18 let, aniž byste sdíleli své celé datum narození
+- Prokázat vlastnictví NFT nebo tokenu, aniž byste odhalili celou svou peněženku
+- Prokázat nárok na členství, odměnu nebo hlasování bez odhalení dalších osobních údajů
+
+Většina nástrojů pro tyto účely se spoléhá na kryptografické techniky, jako jsou důkazy s nulovou znalostí, ale výzvou je učinit je dostatečně efektivními pro provoz na každodenních zařízeních, přenositelnými na jakoukoli platformu a bezpečnými.
+
+Mezi některé projekty zkoumající ochranu soukromí při prokazování patří [Client Side Proving](https://pse.dev/projects/client-side-proving) (systémy prokazování ZK), [TLSNotary](https://tlsnotary.org/), (důkazy pravosti pro jakákoli data na webu), [Mopro](https://pse.dev/projects/mopro) (mobilní prokazování na straně klienta), [Private Proof Delegation](https://pse.dev/projects/private-proof-delegation) (delegační rámce, které se vyhýbají předpokladům důvěry) a [Noir](https://noir-lang.org/) (jazyk pro soukromé a ověřitelné výpočty).
+
+## Slovníček pojmů o ochraně soukromí {#privacy-glossary}
+
+**Anonymní**: Interakce s trvale odstraněnými všemi identifikátory z vašich dat, což znemožňuje zpětné vysledování informací k jednotlivci
+
+**Šifrování**: Proces, který zamíchá data tak, že je může číst pouze někdo se správným klíčem
+
+**[Plně homomorfní šifrování](https://pse.dev/blog/zero-to-start-applied-fully-homomorphic-encryption-fhe-part-1) (FHE)**: Způsob provádění výpočtů přímo na zašifrovaných datech, aniž by se kdy dešifrovala
+
+**[Nerozlišitelné zatemnění](https://pse.dev/projects/machina-io) (iO)**: Techniky ochrany soukromí, které činí programy nebo data nesrozumitelnými, ale stále použitelnými
+
+**[Výpočty s více stranami](https://pse.dev/blog/secure-multi-party-computation) (MPC)**: Metody, které umožňují více stranám společně vypočítat výsledek, aniž by odhalily své soukromé vstupy
+
+**Programovatelná kryptografie**: Flexibilní, pravidly řízená kryptografie, kterou lze v softwaru přizpůsobit a řídit tak, jak a kdy jsou data sdílena, ověřována nebo odhalována
+
+**Pseudonymní**: Používání jedinečných kódů nebo čísel (jako je adresa Etherea) namísto osobních identifikátorů
+
+**Selektivní zveřejňování**: Schopnost sdílet pouze to, co je nezbytně nutné (např. prokázat, že vlastníte NFT, aniž byste odhalili celou historii své peněženky)
+
+**Nepropojitelnost**: Zajištění toho, aby samostatné akce na blockchainu nebylo možné spojit se stejnou adresou
+
+**Ověřitelnost**: Zajištění toho, aby ostatní mohli potvrdit, že tvrzení je pravdivé, například ověřením transakce nebo důkazu na Ethereu
+
+**Ověřitelná delegace**: Přidělení úkolu – například generování důkazu – jiné straně (např. mobilní peněžence využívající server pro náročnou kryptografii) a zároveň schopnost ověřit, že byl proveden správně
+
+**[Důkazy s nulovou znalostí](/zero-knowledge-proofs/#why-zero-knowledge-proofs-are-important) (ZKP)**: Kryptografické protokoly, které umožňují někomu prokázat, že informace je pravdivá, aniž by odhalil podkladová data
+
+**ZK Rollup**: Systém škálovatelnosti, který dávkuje transakce mimo řetězec a odesílá důkaz platnosti na blockchainu – ve výchozím nastavení není soukromý, ale umožňuje efektivní systémy ochrany soukromí (jako jsou stíněné pooly) snížením nákladů
+
+## Zdroje informací {#resources}
+
+- [Privacy Stewards of Ethereum](https://pse.dev/) (PSE), výzkumná a vývojová laboratoř nadace Ethereum zaměřená na ochranu soukromí v ekosystému
+- [Web3PrivacyNow](https://web3privacy.info/), síť lidí, projektů a spřízněných organizací, které chrání a prosazují lidská práva online
+- [WalletBeat](https://beta.walletbeat.eth.limo/wallet/summary/), stránka pro hodnocení peněženek Etherea, jejímž cílem je poskytnout komplexní seznam peněženek, jejich funkčnosti, postupů a podpory určitých standardů.
+- [Zk-kit](https://zkkit.pse.dev/): Sada knihoven (algoritmů, pomocných funkcí a datových struktur), které lze znovu použít v různých projektech a protokolech s nulovou znalostí.
+- [Aplikace pro ochranu soukromí](/apps/categories/privacy/) – Objevte seznam vybraných aplikací pro ochranu soukromí, které běží na Ethereu.
diff --git a/public/content/translations/cs/real-world-assets/index.md b/public/content/translations/cs/real-world-assets/index.md
new file mode 100644
index 00000000000..ae6543cfd68
--- /dev/null
+++ b/public/content/translations/cs/real-world-assets/index.md
@@ -0,0 +1,93 @@
+---
+title: Fyzická aktiva (RWAs)
+metaTitle: Co jsou fyzická aktiva (RWAs)? | Přínosy a využití fyzických aktiv
+description: Přehled fyzických aktiv na Ethereu
+lang: cs
+template: use-cases
+emoji: ":house_buildings:"
+image: /images/man-and-dog-playing.png
+alt: Muž a pes si hrají.
+sidebarDepth: 2
+summaryPoint1: Metoda, jak proměnit cenné komodity v digitální tokeny.
+summaryPoint2: Nyní můžete vlastnit podíly na skutečných objektech nebo aktivech, místo abyste museli kupovat celou nemovitost či předmět.
+summaryPoint3: Propojuje tradiční finance s blockchainovým ekosystémem.
+---
+
+Aktiva z reálného světa (RWA) jsou tokeny představující existující formy bohatství, jako jsou nemovitosti, zlato, akcie, umění, stroje nebo sběratelské předměty. Tokenizace těchto položek je převádí do digitální podoby, což umožňuje jejich rozdělení mezi více vlastníků a usnadňuje obchodování s nimi.
+
+## Co jsou fyzická aktiva (RWAs)? {#what-are-rwas}
+
+Některá RWA jsou hmotná – předměty, které můžete vidět a kterých se můžete dotknout, jako jsou zlaté cihly nebo komerční budovy. Jiná jsou nehmotná, jako je státní dluh, duševní vlastnictví nebo podíl ve společnosti.
+
+Po tokenizaci se tato aktiva mění na hodnotové jednotky. Tokenizované zlato je dobrým příkladem toho, jak to funguje. Společnost [Paxos](https://www.paxos.com/) převádí 400uncové zlaté cihly na 400 tokenů na blockchainu Ethereum, přičemž každý z nich je krytý jednou uncí zlata. Držitelé tokenů mohou své tokeny kdykoli vyměnit za zlato. To platí i pro tokeny zakoupené od jiné společnosti zabývající se RWA, [Tether Gold](https://gold.tether.to/).
+
+Každý token lze rozdělit na ještě menší zlomky. Například tokeny Tether Gold lze rozdělit na části o velikosti pouhých 0,000001.
+
+Tokeny RWA nemají žádnou vnitřní hodnotu. Spíše odrážejí hodnotu předmětu, který představují, a tak se hodnota tokenu mění spolu s hodnotou předmětu.
+
+## Jaké jsou výhody RWA? {#rwas-benefits}
+
+
+
+
+## Jak RWA fungují? {#how-rwas-work}
+
+Podívejme se na několik příkladů z celého ekosystému RWA: nemovitosti, tradiční finanční produkty a výtvarné umění.
+
+### Investice do nemovitostí {#investing-in-real-estate}
+
+Řekněme, že byste chtěli investovat do nemovitostí, ale nákup celé nemovitosti je nad vaše možnosti. Místo toho byste si mohli koupit RWA prostřednictvím projektu, jako je [RealT](https://realt.co/). Jeho tokeny představují podíly ve společnosti s ručením omezeným (LLC), která je vytvořená za účelem držení vlastnického práva k nemovitosti. Držitelé tokenů dostávají příjem z pronájmu ve formě stablecoinů podle zlomku, který drží. Společnost RealT uvádí, že dosud investorům vrátila 15 milionů USD v čistém příjmu z pronájmu.
+
+Další projekt na podobné bázi, [LABS Group](https://x.com/labsgroupio), umožňuje lidem nakupovat tokenizované nemovitosti s částkami od pouhých 100 USD.
+
+### Investování do finančních produktů {#investing-in-financial-products}
+
+Několik projektů přemosťuje svět tradičních financí a decentralizovaných financí (DeFi) tím, že na blockchain přinášejí cenné papíry, akcie, dluhopisy a další finanční nástroje.
+
+Například společnost [Securitize](https://securitize.io/) založená na Ethereu se specializuje na tokenizaci tradičních finančních produktů. V roce 2024 se spojila se společností BlackRock a spustila fond RWA. Společnost BlackRock uvádí, že plánuje nakonec tokenizovat svá aktiva v hodnotě 10 bilionů USD. Její generální ředitel Larry Fink označil tokenizaci za "příští generaci trhů".
+
+### Investování do výtvarného umění {#investing-in-fine-art}
+
+Existuje několik různých mechanismů pro investice do výtvarného umění. [Masterworks](https://www.masterworks.com/) nakupuje umělecká díla, sekuritizuje každý kus a prodává podíly ve formě tokenů. Plánuje později umělecké dílo prodat a rozdělit zisky držitelům tokenů.
+
+Držitelé tokenů nemají kontrolu nad uskladněním nebo budoucím prodejem uměleckého díla. Spíše rozhodují o tom, jak dlouho si své tokeny podrží, jejichž hodnota stoupá a klesá s hodnotou umění.
+
+Mezitím digitální registr umění [Artory](https://www.artory.com/) založený na blockchainu ověřuje pravost uměleckých děl a zaznamenává minulé vlastnictví.
+
+### Investování do sběratelských předmětů {#investing-in-collectibles}
+
+Většina těchto příkladů dosud ukazuje, jak tokenizace umožňuje částečné vlastnictví různých druhů bohatství. Další výhodou tokenizace je, že umožňuje obchodování s cennými předměty, jako jsou sběratelské předměty, na globálním trhu.
+
+Jedním z příkladů je [Courtyard](https://courtyard.io/), který tokenizuje sběratelské karty – například baseballové, fotbalové nebo Pokémon karty. Majitelé karet posílají své karty do zabezpečeného úložiště v USA. Karty jsou raženy jako digitální tokeny a přidány do peněženek majitelů k obchodování na tržišti Courtyard. Courtyard přijímá pouze hodnocené karty, což znamená, že třetí strana ověřila pravost karty a udělila jí skóre na základě jejího stavu, ať už je zchátralá, nebo v původním stavu.
+
+Courtyard také nabízí typ licenčního programu. Pokaždé, když se karta prodá, osoba, která ji tokenizovala, obdrží jedno procento z příjmu. Tímto způsobem jsou odměňováni pouze původci karet. Vlastník může kdykoli vyměnit své digitální karty za fyzické, bez ohledu na to, kde na světě se nachází.
+
+## Jaká jsou omezení RWA? {#rwas-limitations}
+
+Jedním z problémů RWA v této rané fázi je zajištění propojení mezi reálnými objekty a jejich digitálními reprezentacemi.
+
+Pozitivním znamením je, když projekty RWA poskytují investorům důkaz o rezervách – záruku, že jsou zákonnými vlastníky fyzických objektů, které kryjí digitální tokeny. Vzpomeňte si na dříve zmíněné společnosti Paxos, Tether Gold nebo Courtyard, z nichž všechny drží svá aktiva v zabezpečeném úložišti a nabízejí majitelům možnost kdykoli vyměnit token za jeho fyzický ekvivalent.
+
+Dalším omezením je, zda je vlastnictví tokenů uznáváno právními systémy po celém světě. Jinými slovy, jsou chytré kontrakty vymahatelné u soudu, nebo se může držitel RWA tokenu domáhat vlastnictví reálné položky?
+
+Mezi průkopníky v oblasti vytváření právních rámců specificky pro uznání tokenizace patří Singapur, Spojené arabské emiráty, Hongkong a Švýcarsko, které v roce 2021 zavedlo legislativu přezdívanou „Blockchain Act“ k regulaci technologií, jako je tokenizace. Evropská unie zahájila proces regulace RWA, zatímco ve Spojených státech se očekává, že Komise pro cenné papíry a burzy v určitém okamžiku vydá pokyny k RWA.
+
+## Další informace {#learn-more}
+
+Ponořte se do [chytrých kontraktů](/smart-contracts/) nebo se dozvíte více o jiné třídě tokenů, [nezaměnitelných tokenech (NFT)](/nft/).
+
+## Další čtení {#further-reading}
+
+- [Co je tokenizace aktiv?](https://www.britannica.com/money/real-world-asset-tokenization) na Britannica
+- [Jak tokenizace mění globální finance a investice](https://www.weforum.org/stories/2024/12/tokenization-blockchain-assets-finance/) na Světovém ekonomickém fóru
+- [Co potřebují krypto investoři vědět o tokenizaci aktiv z reálného světa](https://www.forbes.com/sites/irinaheaver/2024/03/14/what-crypto-investors-need-to-know-about-tokenizing-real-world-assets/) na Forbes
+- [Jak fungují chytré kontrakty s blockchainem](https://www.britannica.com/money/how-smart-contracts-work) na Britannica
+- [Jak tokenizovaná aktiva z reálného světa mění DeFi](https://medium.com/coinmonks/how-tokenized-real-world-assets-are-transforming-defi-4e040f28732a) na Medium
+- [Co jsou RWA v kryptu? Vysvětlení jejich role v blockchainu](https://www.bitdegree.org/crypto/tutorials/what-is-rwa-in-crypto) na BitDegree
+- [Nejlepší mince aktiv z reálného světa (RWA) podle tržní kapitalizace](https://www.forbes.com/digital-assets/categories/real-world-assets-rwa/) na Forbes
diff --git a/public/content/translations/cs/refi/index.md b/public/content/translations/cs/refi/index.md
index e4b94417896..3d3e4cb2d96 100644
--- a/public/content/translations/cs/refi/index.md
+++ b/public/content/translations/cs/refi/index.md
@@ -9,30 +9,30 @@ image: /images/future_transparent.png
alt: ""
summaryPoint1: Alternativní ekonomický systém postavený na regenerativních principech
summaryPoint2: Snaha využít Ethereum k řešení koordinačních krizí na globální úrovni, jako je změna klimatu
-summaryPoint3: Nástroj k významnému zvýšení škálování ekologických výhod, jako jsou ověřené emisní povolenky
+summaryPoint3: Nástroj pro drastické škálování ekologických aktiv, jako jsou ověřené uhlíkové kredity.
---
## Co je to ReFi? {#what-is-refi}
-Pod pojmem **Regenerativní finance (ReFi)** rozumíme sadu nástrojů a nápadů na [blockchainech](/glossary/#blockchain), jejichž cílem je vytvářet ekonomiky, které jsou regenerativní, spíše než vykořisťovatelské nebo zaměřené na vytěžení surovin. Systémy zaměřené na vytěžení surovin časem spotřebují dostupné zdroje a zhroutí se; bez regenerativních mechanismů jim chybí odolnost. ReFi předpokládá, že vytváření monetární hodnoty je třeba oddělit od neudržitelného vytěžování zdrojů z naší planety a komunit.
+**Regenerativní finance (ReFi)** je soubor nástrojů a myšlenek postavených na [blockchainech](/glossary/#blockchain), které mají za cíl vytvářet regenerativní ekonomiky, nikoli extraktivní nebo vykořisťovatelské. Systémy zaměřené na vytěžení surovin časem spotřebují dostupné zdroje a zhroutí se; bez regenerativních mechanismů jim chybí odolnost. ReFi předpokládá, že vytváření monetární hodnoty je třeba oddělit od neudržitelného vytěžování zdrojů z naší planety a komunit.
Namísto toho se ReFi snaží řešit environmentální, komunitní nebo sociální problémy vytvářením regenerativních cyklů. Tyto systémy vytvářejí hodnotu pro účastníky a současně jsou prospěšné pro ekosystémy a komunity.
-Jedním ze základů ReFi je koncept regenerativní ekonomie, jehož průkopníkem je John Fullerton z Capital Institute. Navrhl [osm vzájemně propojených principů](https://capitalinstitute.org/8-principles-regenerative-economy/), které jsou základem zdravého ekosystému:
+Jedním ze základů ReFi je koncept regenerativní ekonomie, jehož průkopníkem je John Fullerton z Capital Institute. Navrhl [osm vzájemně propojených principů](https://capitalinstitute.org/8-principles-regenerative-economy/), které jsou základem systémového zdraví:
-Projekty ReFi tyto principy realizují pomocí [chytrých kontraktů](/glossary/#smart-contract) a aplikací [decentralizovaných financí (DeFi)](/glossary/#defi), které motivují k regenerativnímu chování, např. k obnově degradovaných ekosystémů, a usnadňují rozsáhlou spolupráci při řešení globálních problémů, jako je globální oteplování a ztráta biologické rozmanitosti.
+Projekty ReFi tyto principy realizují pomocí [chytrých kontraktů](/glossary/#smart-contract) a aplikací [decentralizovaných financí (DeFi)](/glossary/#defi), které motivují k regenerativnímu chování, např. k obnově degradovaných ekosystémů, a usnadňují rozsáhlou spolupráci při řešení globálních problémů, jako je změna klimatu a ztráta biologické rozmanitosti.
-ReFi se také částěčně překrývá s hnutím [decentralizované vědy (DeSci)](/desci/), které využívá platformu Ethereum k financování, vytváření, recenzování, oceňování, ukládání a šíření vědeckých znalostí. Nástroje DeSci by mohly být užitečné pro vývoj ověřitelných standardů a postupů pro implementaci a monitorování regenerativních aktivit, jako je výsadba stromů, odstraňování plastů z oceánu nebo obnova degradovaného ekosystému.
+ReFi se také překrývá s hnutím [decentralizované vědy (DeSci)](/desci/), které využívá Ethereum jako platformu k financování, tvorbě, recenzování, oceňování, ukládání a šíření vědeckých poznatků. Nástroje DeSci by mohly být užitečné pro vývoj ověřitelných standardů a postupů pro implementaci a monitorování regenerativních aktivit, jako je výsadba stromů, odstraňování plastů z oceánu nebo obnova degradovaného ekosystému.
+
+
+
+ Dobré vědět
+ Ačkoli je nejběžnější název "aktivně validované služby" (AVS), různé platformy pro opětovné uzamčení mohou pro decentralizované služby, které pomáhají zabezpečit, používat i jiné názvy, jako například "autonomně validované služby", "distribuované zabezpečené služby" nebo "sítě".
+
+
+
+
+## Uzamčení vs. opětovné uzamčení {#staking-vs-restaking}
+
+| Uzamčení | Opětovné uzamčení |
+| ---------------------------- | -------------------------------------------------- |
+| Získejte odměny v ETH | Získejte odměny v ETH + odměny za AVS |
+| Zabezpečuje síť Ethereum | Zabezpečuje síť Ethereum + AVS |
+| Žádné minimum ETH | Žádné minimum ETH |
+| Nízká úroveň rizika | Nízká až vysoká úroveň rizika |
+| Doba výběru závisí na frontě | Doba výběru závisí na frontě + období pro odpojení |
+
+## Proč potřebujeme opětovné uzamčení? {#why-do-we-need-restaking}
+
+Představte si dva světy: jeden s opětovným uzamčením a jeden bez něj.
+
+
+
+
+
+
+ Další výhoda opětovného uzamčení
+ AVS mohou všechny své zdroje vložit do budování a marketingu svých služeb, místo aby se rozptylovaly decentralizací a zabezpečením.
+
+
+
+
+## Jak funguje opětovné uzamčení? {#how-does-restaking-work}
+
+Na opětovném uzamčení se podílí několik subjektů – každý z nich hraje důležitou roli.
+
+| **Pojem** | **Popis** |
+| ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Platformy pro opětovné uzamčení** | Platforma pro opětovné uzamčení je služba, která propojuje AVS, stakery ETH a operátory. Vytvářejí decentralizované aplikace, kde mohou stakeři opětovně uzamknout své ETH, a tržiště, kde se mohou stakeři, AVS a operátoři navzájem najít. |
+| **Nativní restakeři** | Lidé, kteří uzamykají své ETH provozováním vlastních validátorů Etherea, mohou své uzamčené ETH připojit k platformě pro opětovné uzamčení, včetně EigenLayer a dalších, a získat tak odměny za opětovné uzamčení nad rámec odměn pro validátory ETH. |
+| | |
+| **Likvidní restakeři** | Lidé, kteří uzamykají své ETH prostřednictvím poskytovatele likvidního uzamčení třetí strany, jako je Lido nebo Rocket Pool, získávají tokeny likvidního uzamčení (LST), které představují jejich uzamčené ETH. Tyto LST mohou opětovně uzamknout, aby získali odměny za opětovné uzamčení, zatímco jejich původní ETH zůstává uzamčeno. |
+| | |
+| **Operátoři** | Operátoři provozují software pro opětovné uzamčení od AVS a provádějí validační úkoly, které každá AVS vyžaduje. Operátoři jsou obvykle profesionální poskytovatelé služeb, kteří zaručují například dostupnost a výkon. Stejně jako restakeři, kteří nejsou operátory, používají operátoři uzamčené ETH k zabezpečení AVS, ale operátoři také dostávají další odměny výměnou za svou práci. |
+| | |
+| **AVS** | Jedná se o decentralizované služby – jako jsou cenová orákula, přemostění tokenů a datové systémy – které získávají zabezpečení od restakerů a na oplátku nabízejí odměny v tokenech. |
+
+
+
+
+
+
+ Dobré vědět
+ Nativní a likvidní restakeři často delegují své uzamčené ETH operátorovi, místo aby sami spouštěli software k zabezpečení AVS.
+ Díky tomu se nemusí starat o složité technické požadavky ze strany AVS, i když dostávají nižší odměny než operátoři.
+
+
+
+
+## Jaké jsou příklady opětovného uzamčení? {#what-are-some-examples-of-restaking}
+
+Ačkoli se jedná o novou myšlenku, objevilo se několik projektů, které zkoumají možnosti opětovného uzamčení.
+
+
+
+
+
+
+ Upozornění na nesprávné označení
+ Někteří lidé si pletou "opětovné uzamčení" s půjčováním LST v DeFi. V obou případech se využívají uzamčené ETH, ale opětovné uzamčení znamená zabezpečení AVS, nikoli jen získávání výnosů z LST.
+
+
+
+
+## Kolik si mohu vydělat opětovným uzamčením? {#how-much-can-i-make-from-restaking}
+
+Zatímco AVS nabízejí různé sazby, tokeny likvidního opětovného uzamčení (LRT), jako je eETH, vám dávají představu o tom, kolik si můžete vydělat. Stejně jako dostáváte LST, jako je stETH, za uzamčení svých ETH, můžete získat LRT, jako je eETH, za opětovné uzamčení stETH. Tyto tokeny získávají odměny za uzamčení ETH a za opětovné uzamčení.
+
+**Je důležité si uvědomit rizika spojená s opětovným uzamčením. Potenciální odměny mohou být atraktivní, ale nejsou bez rizika.**
+
+## Jaká jsou rizika opětovného uzamčení? {#what-are-the-risks-of-restaking}
+
+| **Rizika** | **Popis** |
+| ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Postihy (neboli "sekání")** | Stejně jako při uzamčení ETH platí, že pokud restakeři/operátoři přejdou do offline režimu, cenzurují zprávy nebo se pokusí poškodit síť, může být jejich vklad částečně nebo úplně seknut (spálen). |
+| **Centralizace** | Pokud by několik málo operátorů ovládalo většinu opětovného uzamčení, mohli by mít velký vliv na restakery, AVS a dokonce i na platformy pro opětovné uzamčení. |
+| **Řetězové reakce** | Pokud dojde k sekání restakera při zabezpečování více AVS, mohlo by to snížit zabezpečení ostatních AVS a učinit je zranitelnými. |
+| **Okamžitý přístup k prostředkům** | Při výběru opětovně uzamčených ETH je třeba počkat (tzv. "období pro odpojení"), takže k nim nemusíte mít vždy okamžitý přístup. |
+
+
+
+
+
+
+ Spoluzakladatel Etherea píše…
+
+ Vitalik, spoluzakladatel Etherea, varoval před potenciálními riziky opětovného uzamčení v blogovém příspěvku z roku 2021 s názvem Nepřetěžujte konsensus.
+
+
+
+
+
+## Jak začít s opětovným uzamčením? {#how-to-get-started-with-restaking}
+
+| 🫡 Začátečníci | 🤓 Pokročilí uživatelé |
+| --------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| 1. Uzamkněte ETH na platformách jako Lido nebo Rocket Pool, abyste získali LST. | 1. Uzamkněte své ETH jako validátor na Ethereu. |
+| 2. Použijte tyto LST k zahájení opětovného uzamčení ve službě pro opětovné uzamčení. | 2. Porovnejte služby pro opětovné uzamčení, jako je EigenLayer, Symbiotic a další. |
+| | 3. Postupujte podle pokynů a připojte svého validátora k chytrému kontraktu pro opětovné uzamčení. |
+
+
+
+
+
+
+ Uzamčení na Ethereu: Jak funguje?
+
+ Další informace
+
+
+
+
+
+## Pokročilé {#advanced}
+
+
-
-Správa poplatků za palivo je jednou z hlavních nepříjemností pro uživatele Etherea, především proto, že ETH je jediné aktivum, které v současnosti mohou k platbě za transakce používat. Představte si, že máte peněženku se zůstatkem USDC, ale bez ETH. Nemůžete tyto USDC tokeny přesunout nebo směnit, protože nemáte jak zaplatit za palivo. Nemůžete také směnit USDC za ETH, protože to samo o sobě vyžaduje palivo. Abyste tento problém vyřešili, museli byste si poslat ETH na účet z burzy nebo jiné adresy. S peněženkami založenými na chytrých kontraktech můžete místo toho platit poplatky za palivov USDC, čímž svůj účet odblokujete. Už nemusíte udržovat zůstatek ETH ve všech svých účtech.
-
-Abstrakce účtu také umožňuje vývojářům dappek určitou kreativitu v přístupu k řízení poplatků za palivo. Např. můžete začít platit své oblíbené decentralizované burze stálý poplatek každý měsíc za neomezené transakce. Platformy dappek by mohly nabídnout placení všech vašich poplatků za palivo za vás jako odměnu za používání jejich platformy nebo jako lákadlo pro nové uživatele. Pro vývojáře bude mnohem snadnější zavádět inovace v oblasti poplatků za palivo, když budou peněženky založené na chytrých kontraktech podporovány už na úrovni protokolu.
-
-
-
-Důvěryhodné relace jsou také potenciálně transformační pro uživatelské možnosti, zejména pro aplikace, jako jsou hry, kde může velké množství malých transakcí vyžadovat rychlé schválení. Individuální schvalování každé transakce by narušilo herní zážitek, ale trvalý souhlas není bezpečný. Chytrá kontraktová peněženka by mohla schválit určité transakce na pevně stanovenou dobu, až do specifické hodnoty nebo pouze pro určité adresy.
-
-Je také zajímavé si představit, jak by se mohlo díky abstrakci účtu změnit nakupování. Dnes každá transakce musí být schválena a poslána z peněženky předfinancované dostatečným množstvím správného tokenu. S abstrakcí účtu by mohlo být prostředí podobnější online nakupování, kde uživatel naplní „košík“ položkami a jedním klikem zaplatí všechny najednou, přičemž veškerá potřebná logika by byla zpracována kontraktem, nikoliv uživatelem.
-
-Toto je jen několik příkladů, jak by mohly být uživatelské možnosti vylepšeny pomocí abstrakce účtu, ale použití je mnohem širší a spousta z nich je ještě za hranicemi naší fantazie. Abstrakce účtů osvobozuje vývojáře od omezení současných EOA, přenáší pozitivní aspekty web2 do web3 bez nutnosti obětovat samosprávu a umožňuje kreativně vytvářet nové uživatelské možnosti.
-
-## Jak bude abstrakce účtu implementována? {#how-will-aa-be-implemented}
-
-Peněženky založené na chytrých kontraktech už existují, ale jejich implementace je složitá, protože EVM je nepodporuje. Místo toho se spoléhají na obalení relativně složitého kódu kolem standardních Ethereum transakcí. Ethereum může tuto situaci změnit tím, že umožní chytrým kontraktům iniciovat transakce, přičemž nezbytnou logiku zpracovává v chytrých kontraktech přímo na Ethereu namísto zpracování mimo řetězec. Umístění logiky do chytrých kontraktů také zvyšuje decentralizaci Etherea, protože odstraňuje potřebu „převaděčů“ spuštěných vývojáři peněženek, kteří překládají zprávy podepsané uživateli na běžné Ethereum transakce.
-
-
-
-EIP-2771 zavádí koncept meta-transakcí, které umožňují třetím stranám platit náklady na palivo uživatelů, aniž by se měnil protokol Ethereum. Myšlenkou je, že transakce podepsané uživateli jsou odesílány do Přeposílacího kontraktu. Přeposílací kontrakt je důvěryhodný subjekt, který ověřuje platnost transakcí, než je pošle na relé paliva. Toto se provádí mimo blockchain, což eliminuje potřebu platit za palivo. Relé paliva pak přenáší transakci na Přijímací kontrakt, který platí potřebný poplatek, aby mohla být transakce vykonatelná na Ethereu. Transakce je provedena, pokud je Přeposílací kontrakt známý a důvěryhodný pro Přijímací kontrakt. Tento model usnadňuje vývojářům implementaci transakcí bez poplatků za palivo na straně uživatele.
-
-
-
-
-
-EIP-4337 je prvním krokem směrem k nativní podpoře chytrých kontraktových peněženek decentralizovaným způsobem, aniž by bylo potřeba měnit protokol Ethereum. Místo úpravy konsenzuální vrstvy pro podporu chytrých kontraktových peněženek je přidán nový systém odděleně od běžného transakčního komunikačního protokolu. Tento vysoceúrovňový systém je postaven kolem nového objektu nazývaného UserOperation, který balí akce uživatele spolu s relevantními podpisy. Tyto objekty UserOperation jsou následně posílány do specializovaného mempoolu, kde je validátoři shromažďují do „balíčkové transakce“. Balíčková transakce představuje sekvenci mnoha jednotlivých objektů UserOperation a může být zahrnuta do bloků na Ethereu stejně jako běžná transakce, a může být vybírána validátory pomocí podobného modelu maximizace poplatků.
-
-Způsob, jakým peněženky fungují, by se se zavedením EIP-4337 také změnil. Místo toho, aby každá peněženka znovu implementovala běžnou, ale složitou bezpečnostní logiku, by tyto funkce byly outsourcovány do globálního peněženkového kontraktu známého jako „vstupní bod“. Ten by spravoval operace, jako je platba poplatků a spuštění EVM kódu, takže vývojáři peněženek se mohou soustředit na poskytování vynikajících uživatelských funkcí.
-
-Poznámka: Kontrakt vstupního bodu EIP-4337 byl nasazen na hlavní síť Etherea 1. března 2023. Můžete se na něj podívat na Etherscanu.
-
-
-
-
-
-EIP-2938 si klade za cíl vylepšit protokol Ethereum zavedením nového typu transakce, AA_TX_TYPE, který zahrnuje tři položky: nonce, target a data, kde nonce je čítač transakcí, target je cílová adresa kontraktu vstupního bodu a data je bytecode EVM. Za účelem vykonání těchto transakcí je třeba přidat do EVM dvě nové instrukce (známé jako opkódy): NONCE a PAYGAS. Opkód NONCE sleduje sekvenci transakcí a PAYGAS počítá a vybírá ze zůstatku kontraktu poplatek za palivo potřebný k vykonání transakce. Tyto nové funkce umožňují Ethereu podporovat chytré kontraktové peněženky nativně, protože potřebná infrastruktura je zabudována do protokolu Ethereum.
-
-Připomínáme, že EIP-2938 v současné době není aktivní. Komunita aktuálně upřednostňuje EIP-4337, protože nevyžaduje změny protokolu.
+Abstrakce účtu výrazně vylepšuje uživatelský prožitek a bezpečnost tím, že podporuje peněženky s chytrými kontrakty na úrovni protokolu. Vývojáři mohou volně inovovat a vylepšovat seskupování transakcí pro zvýšení rychlosti a efektivity. Jednoduché směny se mohou stát operacemi na jedno kliknutí, což výrazně zlepší jejich použitelnost.
-
+Správa paliva se výrazně zlepšuje. Aplikace mohou platit uživatelům poplatky za palivo nebo umožnit platbu v jiných tokenech než ETH, čímž odpadá nutnost udržovat zůstatek v ETH.
-
+## Jak bude abstrakce účtu implementována? Jak bude implementována abstrakce účtu {#how-will-aa-be-implemented}
-EIP-3074 si klade za cíl aktualizovat externě vlastněné účty na Ethereu tím, že umožní delegování kontroly nad nimi na chytrý kontrakt. To znamená, že logika chytrého kontraktu by mohla schvalovat transakce pocházející z EOA (externě vlastněného účtu). To by umožnilo funkce jako sponzorování poplatků za palivo a sdružování transakcí. Aby to fungovalo, je třeba do EVM přidat dva nové opkódy: AUTH a AUTHCALL. S EIP-3074 jsou výhody chytrých kontraktových peněženek dostupné bez nutnosti kontraktu – místo toho zpracovává transakce specifický typ stateless, trustless, nevylepšitelného kontraktu známého jako "započínač".
+V současné době je implementace peněženek s chytrými kontrakty náročná, protože se spoléhají na složitý kód, který obaluje standardní transakce. Ethereum to může změnit tím, že umožní chytrým kontraktům přímo iniciovat transakce a vkládat logiku do chytrých kontraktů na Ethereu namísto spoléhání se na externí relayery.
-Připomínáme, že EIP-3074 v současné době není aktivní. Komunita aktuálně upřednostňuje EIP-4337, protože nevyžaduje změny protokolu.
+### EIP-4337: Abstrakce účtu bez změn v protokolu
-
+EIP-4337 umožňuje nativní podporu peněženek s chytrými kontrakty bez úpravy hlavního protokolu Etherea. Zavádí objekty `UserOperation`, které validátoři shromažďují do balíčků transakcí, což zjednodušuje vývoj peněženek. Kontrakt EntryPoint EIP-4337 byl 1. března 2023 nasazen na hlavní síti Etherea a umožnil vytvoření více než 26 milionů chytrých peněženek a 170 milionů operací UserOperation.
-## Aktuální průběh {#current-progress}
+## Aktuální postup {#current-progress}
-Peněženky založené na chytrých kontraktech jsou už k dispozici, ale je třeba uvést do chodu další vylepšení, aby byly co nejvíce decentralizované a přístupné bez nutnosti povolení třetí strany. EIP-4337 je hotový návrh, který nevyžaduje žádné změny protokolu Ethereum, takže je možné, že bude implementován rychle. Nicméně vylepšení, která mění protokol Ethereum, nejsou v současné době aktivně vyvíjena, takže může trvat mnohem déle, než budou tyto změny realizovány. Je také možné, že abstrakce účtu bude dostatečně dosažena prostřednictvím EIP-4337, takže žádné změny protokolu nebudou nikdy potřeba.
+V rámci vylepšení Pectra sítě Ethereum je EIP-7702 naplánován na 7. května 2025. EIP-4337 byl široce přijat, [s více než 26 miliony nasazených chytrých účtů a více než 170 miliony zpracovaných operací UserOperation](https://www.bundlebear.com/erc4337-overview/all).
-## Další informace {#further-reading}
+## Další čtení {#further-reading}
-- [erc4337.io](https://www.erc4337.io/)
-- [Panelová diskuze o abstrakci účtu na Devconu v Bogotě](https://www.youtube.com/watch?app=desktop&v=WsZBymiyT-8)
-- [„Proč je abstrakce účtů revoluční pro dappky“ z Devconu v Bogotě](https://www.youtube.com/watch?v=OwppworJGzs)
-- [„Abstrakce účtů ELI5“ z Devconu v Bogotě](https://www.youtube.com/watch?v=QuYZWJj65AY)
-- [Vitalikovy poznámky „Cesta k abstrakci účtů“](https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap#Transaction-inclusion-lists)
-- [Vitalikův blogový příspěvek o společenském obnovování peněženek](https://vitalik.eth.limo/general/2021/01/11/recovery.html)
-- [Poznámky k EIP-2938](https://hackmd.io/@SamWilsn/ryhxoGp4D#What-is-EIP-2938)
-- [Dokumentace k EIP-2938](https://eips.ethereum.org/EIPS/eip-2938)
-- [Poznámky k EIP-4337](https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a)
-- [Dokumentace k EIP-4337](https://eips.ethereum.org/EIPS/eip-4337)
-- [Dokumentace k EIP-2771](https://eips.ethereum.org/EIPS/eip-2771)
-- [„Základy abstrakce účtů“ – Co je abstrakce účtů, část I](https://www.alchemy.com/blog/account-abstraction)
+- [erc4337.io](https://docs.erc4337.io/)
+- [Dokumentace EIP-4337](https://eips.ethereum.org/EIPS/eip-4337)
+- [Dokumentace EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)
+- [Panel přijetí ERC-4337](https://www.bundlebear.com/erc4337-overview/all)
+- [Vitalikova "Cesta k abstrakci účtu"](https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap#Transaction-inclusion-lists)
+- [Vitalikův blog o peněženkách se sociální obnovou](https://vitalik.eth.limo/general/2021/01/11/recovery.html)
+- [Awesome Account Abstraction](https://github.com/4337Mafia/awesome-account-abstraction)
diff --git a/public/content/translations/cs/roadmap/beacon-chain/index.md b/public/content/translations/cs/roadmap/beacon-chain/index.md
new file mode 100644
index 00000000000..bb0e80fa1ff
--- /dev/null
+++ b/public/content/translations/cs/roadmap/beacon-chain/index.md
@@ -0,0 +1,79 @@
+---
+title: Řetězová vazba
+description: Přečtěte si o Řetězové vazbě – vylepšení, které umožnilo důkaz podílem na Ethereu.
+lang: cs
+template: upgrade
+image: /images/upgrades/core.png
+alt:
+summaryPoint1: Řetězová vazba zavedla důkaz podílem do ekosystému Etherea.
+summaryPoint2: V září 2022 byla sloučena s původním Ethereem založeným na důkazu prací.
+summaryPoint3: Řetězová vazba představila logiku konsensu a blokový komunikační protokol, který v současné době zabezpečuje Ethereum.
+---
+
+
+ Řetězová vazba byla spuštěna 1. prosince 2020 a formalizovala důkaz podílem jako mechanismus konsenzu Etherea s upgradem Sloučení dne 15. září 2022.
+
+
+## Co je Řetězová vazba? Co je Řetězová vazba? {#what-is-the-beacon-chain}
+
+Řetězová vazba je název původního blockchainu založeného na důkazu podílem, který byl spuštěn v roce 2020. Byl vytvořen za účelem zajištění správnosti a udržitelnosti logiky konsensu důkazu podílem před nasazením na hlavní síť Ethereum. Proto běžel souběžně s původním Ethereem založeným na důkazu prací. Řetězová vazba byla řetězec „prázdných“ bloků, ale vypnutí důkazu prací a zapnutí důkazu podílem na Ethereu vyžadovalo instruovat Řetězovou vazbu, aby přijímala transakční data od exekučních klientů, sdružovala je do bloků a poté organizovala do blockchainu pomocí mechanismu konsenzu založeného na důkazu podílem. Ve stejnou chvíli původní klienti Etherea vypnuli těžbu, tvorbu bloků a logiku konsensu a převedli vše na Řetězovou vazbu. Tato událost byla známá jako [Sloučení](/roadmap/merge/). Jakmile došlo ke Sloučení, už neexistovaly dva blockchainy. Místo toho nyní existuje jen jedno Ethereum, které vyžaduje dva různé klienty na síťový uzel. Řetězová vazba je nyní konsensuální vrstva: Peer-to-peer síť konsenzuálních klientů, která zpracovává blokovou komunikaci a konsenzuální logiku, zatímco původní klienti tvoří exekuční vrstvu, která je zodpovědná za komunikaci a exekuci transakcí a správu stavu Etherea. Tyto dvě vrstvy spolu mohou komunikovat pomocí Engine API.
+
+## Co Řetězová vazba dělá? Co dělá Řetězová vazba? {#what-does-the-beacon-chain-do}
+
+Řetězová vazba je název pro řetězec účtů, který vedl a koordinoval síť [uzamykatelů](/staking/) Etherea předtím, než tito uzamykatelé začali ověřovat skutečné bloky Etherea. Nezpracovává transakce ani interakce s chytrými kontrakty, protože to se děje v exekuční vrstvě.
+Řetězová vazba je zodpovědná za akce, jako je zpracování bloků a atestací, provozování algoritmu výběru forku a správa odměn a sankcí.
+Přečtěte si více na naší [stránce o architektuře uzlů](/developers/docs/nodes-and-clients/node-architecture/#node-comparison).
+
+## Dopad Řetězové vazby {#beacon-chain-features}
+
+### Představení uzamčení {#introducing-staking}
+
+Řetězová vazba zavedla do Etherea [důkaz podílem](/developers/docs/consensus-mechanisms/pos/). To udržuje Ethereum v bezpečí a vydělává validátorům více ETH. V praxi to znamená, že uzamknete ETH, abyste se stali validátorem. Jako uzamykatel spouštíte software, který vytváří a ověřuje nové bloky.
+
+Uzamčení slouží k podobnému účelu, jako dříve sloužila [těžba](/developers/docs/consensus-mechanisms/pow/mining/), ale v mnoha ohledech se liší. Těžba vyžadovala velké výdaje ve formě pořízení výkonného hardwaru a spotřeby energie, což vedlo k úsporám z rozsahu a tím k podpoře centralizace. Těžba nevyžadovala zablokování aktiv jako kolaterálu, což omezovalo schopnost protokolu uvalit sankce na těžaře, kteří útočili na síť.
+
+Přechod na Ethereum založené na důkazu podílem významně zabezpečil a decentralizoval jeho provoz ve srovnání s důkazem prací. Čím více lidí se do sítě zapojí, tím bude decentralizovanější a bezpečnější před útoky.
+
+
+
+
+ Pokud máte zájem stát se validátorem a pomáhat zabezpečit Ethereum, [zjistěte více o uzamčení](/staking/).
+
+
+
+
+### Příprava na sharding {#setting-up-for-sharding}
+
+Od té doby, co se Řetězová vazba sloučila s původní hlavní sítí Ethereum, začala komunita Ethereum usilovat o škálování sítě.
+
+Důkaz podílem má tu výhodu, že má neustále registr všech schválených producentů bloků a každý producent bloků má uzamčené ETH. Tento registr nastavuje scénu pro schopnost dobře rozdělit konkrétní síťové zodpovědnosti.
+
+Tato odpovědnost je v kontrastu s důkazem prací, kde těžaři nemají žádné závazky vůči síti a mohli by zastavit těžbu a vypnout software síťových uzlů okamžitě a bez následků. V důkazu prací také neexistuje žádný registr známých navrhovatelů bloků a žádný spolehlivý způsob, jak bezpečně rozdělit síťové odpovědnosti.
+
+[Více o shardingu](/roadmap/danksharding/)
+
+## Vztah mezi vylepšeními {#relationship-between-upgrades}
+
+Všechna vylepšení Etherea jsou vzájemně provázaná. Pojďme si tedy zrekapitulovat, jak Řetězová vazba ovlivňuje další vylepšení.
+
+### Řetězová vazba a Sloučení {#merge-and-beacon-chain}
+
+Řetězová vazba nejprve existovala odděleně od hlavní sítě Ethereum, ale v roce 2022 byly oba blockchainy sloučeny.
+
+
+ Sloučení
+
+
+### Shardy a Řetězová vazba {#shards-and-beacon-chain}
+
+Tříštění může být bezpečně implementováno do ekosystému Ethereum pouze se zavedeným mechanismem konsenzu důkazu podílem. Řetězová vazba představila uzamčení, když se „sloučila“ s hlavní sítí, čímž se otevřela cesta pro tříštění, které pomůže dále škálovat Ethereum.
+
+
+ Shardové řetězce
+
+
+## Další informace
+
+- [Více o architektuře uzlů](/developers/docs/nodes-and-clients/node-architecture)
+- [Více o důkazu podílem](/developers/docs/consensus-mechanisms/pos)
diff --git a/public/content/translations/cs/roadmap/danksharding/index.md b/public/content/translations/cs/roadmap/danksharding/index.md
index f4d542f267c..fe6778483ab 100644
--- a/public/content/translations/cs/roadmap/danksharding/index.md
+++ b/public/content/translations/cs/roadmap/danksharding/index.md
@@ -11,49 +11,49 @@ summaryPoints:
# Danksharding {#danksharding}
-**Danksharding** je způsob, jehož pomocí se Ethereum stává skutečně škálovatelným blockchainem, ale k tomu je potřeba několik aktualizací protokolu. **Proto-Danksharding** je mezikrokem na této cestě. Obě vylepšení mají za cíl co nejvíce zlevnit transakce na druhé vrstvě pro uživatele a měly by zvýšit škálovatelnost Etherea na > 100 000 transakcí za sekundu.
+**Danksharding** je způsob, jehož pomocí se Ethereum stává skutečně škálovatelným blockchainem, ale k tomu je potřeba několik aktualizací protokolu. **Proto-Danksharding** je mezikrokem na této cestě. Obě mají za cíl co nejvíce zlevnit transakce na druhé vrstvě pro uživatele a měly by škálovat Ethereum na >100 000 transakcí za sekundu.
## Co je Proto-Danksharding? {#what-is-protodanksharding}
-Proto-Danksharding, známý také jako [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), je způsob, jakým mohou [rollupy](/layer-2/#rollups) přidávat levnější data do bloků. Název pochází od dvou výzkumníků, kteří tento nápad navrhli: Protolambdy a Dankrada Feista. Historicky byly rollupy omezeny v tom, jak levně mohou zpracovávat uživatelské transakce, protože jejich transakce byly ukládány do `CALLDATA`.
+Proto-Danksharding, známý také jako [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), je způsob, jak mohou [rollupy](/layer-2/#rollups) přidávat do bloků levnější data. Název pochází od dvou výzkumníků, kteří tento nápad navrhli: Protolambdy a Dankrada Feista. Historicky byly rollupy omezeny v tom, jak levně mohly zpracovávat uživatelské transakce, protože své transakce zveřejňovaly v `CALLDATA`.
Toto je drahé, protože CALLDATA jsou zpracovávána všemi uzly na Ethereu a zůstávají na blockchainu navždy, i když rollupy potřebují tato data jen po krátkou dobu. Proto-Danksharding zavádí datové bloby, které mohou být odeslány a připojeny k blokům. Data v těchto blobech nejsou přístupná pro EVM a jsou automaticky smazána po stanovené době (v době psaní tohoto článku to bylo 4 096 epoch, což je přibližně 18 dní). To znamená, že rollupy mohou odesílat svá data mnohem levněji a přenést úspory na koncové uživatele ve formě levnějších transakcí.
-
+
-Rollupy jsou způsobem, jak škálovat Ethereum tím, že seskupují transakce mimo řetězec a poté zveřejňují výsledky na Ethereu. Rollup se v podstatě skládá ze dvou částí: dat a ověření provedení. Data jsou úplné sekvence transakcí, které jsou zpracovány rollupem k vytvoření změny stavu, jež je zveřejněna na Ethereu. Ověření provedení je opětovné provedení těchto transakcí nějakým poctivým aktérem (tzv. „schvalovatel“), aby bylo zajištěno, že navrhovaná změna stavu je správná. K provedení ověření musí být transakční data dostupná dostatečně dlouho na to, aby si je mohl kdokoliv stáhnout a zkontrolovat. To znamená, že jakékoliv nepoctivé chování sequencera rollupu může být identifikováno a napadnuto ověřovatelem. Nicméně není nutné, aby byla tato data dostupná navždy.
+Rollupy jsou způsobem, jak škálovat Ethereum tím, že sdružují transakce mimo blockchain a poté zveřejňují výsledky na Ethereu. Rollup se v podstatě skládá ze dvou částí: dat a ověření provedení. Data jsou úplné sekvence transakcí, které jsou zpracovány rollupem k vytvoření změny stavu, jež je zveřejněna na Ethereu. Ověření provedení je opětovné provedení těchto transakcí nějakým poctivým aktérem (tzv. „schvalovatel“), aby bylo zajištěno, že navrhovaná změna stavu je správná. K provedení ověření musí být transakční data dostupná dostatečně dlouho na to, aby si je mohl kdokoliv stáhnout a zkontrolovat. To znamená, že jakékoliv nepoctivé chování sequencera rollupu může být identifikováno a napadnuto ověřovatelem. Nicméně není nutné, aby byla tato data dostupná navždy.
-
+
-Rollupy zveřejňují závazky ke svým transakčním datům na blockchainu a také zpřístupňují skutečná data v datových blobech. To znamená, že ověřovatelé mohou verifikovat, že jsou závazky platné, nebo napadnout data, která považují za nesprávná. Na úrovni uzlů jsou tyto datové bloby uloženy v konsenzus klientech. Konsenzus klienti potvrzují, že data viděli a že byla rozšířena po celé síti. Pokud by se data uchovávala navždy, tito klienti by zůstali přetíženi, což by vedlo k velkým požadavkům na hardware pro provozování uzlů. Místo toho se data automaticky mažou z uzlu každých 18 dní. Atestace konsenzus klientů prokazují, že ověřovatelé měli dostatečnou příležitost data ověřit. Skutečná data mohou být uložena mimo řetězec provozovateli rollupu, uživateli nebo ostatními.
+Rollupy zveřejňují závazky ke svým transakčním datům na blockchainu a také zpřístupňují skutečná data v datových blobech. To znamená, že ověřovatelé mohou verifikovat, že jsou závazky platné, nebo napadnout data, která považují za nesprávná. Na úrovni uzlů jsou tyto datové bloby uloženy v konsenzus klientech. Konsenzus klienti potvrzují, že data viděli a že byla rozšířena po celé síti. Pokud by se data uchovávala navždy, tito klienti by zůstali přetíženi, což by vedlo k velkým požadavkům na hardware pro provozování uzlů. Místo toho se data automaticky mažou z uzlu každých 18 dní. Atestace konsenzus klientů prokazují, že ověřovatelé měli dostatečnou příležitost data ověřit. Skutečná data mohou být uložena mimo blockchain provozovateli rollupu, uživateli nebo ostatními.
### Jak jsou data v blobech ověřována? {#how-are-blobs-verified}
-Rollupy zveřejňují transakce, které provádějí, v datových blobech. Zároveň k těmto datům zveřejňují „závazek“. Dělají to tak, že datům přizpůsobí polynomiální funkci. Tato funkce může být poté vyhodnocena na různých bodech. Např. pokud definujeme extrémně jednoduchou funkci `f(x) = 2x – 1`, můžeme tuto funkci vyhodnotit pro `x = 1`, `x = 2`, `x = 3` a získat výsledky `1, 3, 5`. Ověřovatel aplikuje stejnou funkci na data a vyhodnotí ji ve stejných bodech. Pokud byla původní data změněna, funkce nebude identická, a proto ani hodnoty vyhodnocené v každém bodě nejsou stejné. Ve skutečnosti jsou závazek a důkaz složitější, protože jsou zabaleny v kryptografických funkcích.
+Rollupy zveřejňují transakce, které provádějí, v datových blobech. Zároveň k těmto datům zveřejňují „závazek“. Dělají to tak, že datům přizpůsobí polynomiální funkci. Tato funkce může být poté vyhodnocena na různých bodech. Například pokud definujeme extrémně jednoduchou funkci `f(x) = 2x-1`, můžeme ji vyhodnotit pro `x = 1`, `x = 2`, `x = 3` a získáme výsledky `1, 3, 5`. Ověřovatel aplikuje stejnou funkci na data a vyhodnotí ji ve stejných bodech. Pokud byla původní data změněna, funkce nebude identická, a proto ani hodnoty vyhodnocené v každém bodě nejsou stejné. Ve skutečnosti jsou závazek a důkaz složitější, protože jsou zabaleny v kryptografických funkcích.
### Co je KZG? {#what-is-kzg}
-KZG znamená Kate-Zaverucha-Goldberg – jména tří [původních autorů](https://link.springer.com/chapter/10.1007/978-3-642-17373-8_11) schématu, které redukuje blob dat na malý [kryptografický „závazek“](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html). Blob dat předložený rollupem musí být ověřen, aby bylo zajištěno, že rollup nejedná nepoctivě. To zahrnuje ověřovatelovo opětovné provedení transakcí v blobu, aby bylo ověřeno, že závazek byl platný. To je konceptuálně stejné jako způsob, jakým exekuční klienti kontrolují platnost transakcí na Ethereu na vrstvě 1 pomocí Merkle důkazů. KZG je alternativní důkaz, který přizpůsobí polynomiální rovnici datům. Závazek vyhodnocuje polynom na určitých tajných bodech dat. Ověřovatel by přizpůsobil stejný polynom datům a vyhodnotil ho na stejných hodnotách, přičemž by ověřil, že výsledek je stejný. To je způsob, jak ověřit data, který je kompatibilní s technikami zero-knowledge používanými některými rollupy a nakonec i jinými částmi protokolu Ethereum.
+KZG je zkratka pro jména Kate-Zaverucha-Goldberg – jména tří [původních autorů](https://link.springer.com/chapter/10.1007/978-3-642-17373-8_11) schématu, které redukuje datový blob na malý [kryptografický "závazek"](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html). Blob dat předložený rollupem musí být ověřen, aby bylo zajištěno, že rollup nejedná nepoctivě. To zahrnuje ověřovatelovo opětovné provedení transakcí v blobu, aby bylo ověřeno, že závazek byl platný. To je konceptuálně stejné jako způsob, jakým exekuční klienti kontrolují platnost transakcí na Ethereu na vrstvě 1 pomocí Merkle důkazů. KZG je alternativní důkaz, který přizpůsobí polynomiální rovnici datům. Závazek vyhodnocuje polynom na určitých tajných bodech dat. Ověřovatel by přizpůsobil stejný polynom datům a vyhodnotil ho na stejných hodnotách, přičemž by ověřil, že výsledek je stejný. To je způsob, jak ověřit data, který je kompatibilní s technikami zero-knowledge používanými některými rollupy a nakonec i jinými částmi protokolu Ethereum.
### Co byl Ceremoniál KZG? {#what-is-a-kzg-ceremony}
-Ceremoniál KZG byla akce, při které se spousta lidí z celé Ethereum komunity společně podílela na vygenerování tajného náhodného řetězce čísel, který lze použít k ověřování dat. Je klíčové, aby tento řetězec čísel nebyl nikomu znám a nemohl být nikým znovu vytvořen. Proto každý účastník ceremoniálu obdržel řetězec od předchozího účastníka. Poté vytvořil nové náhodné hodnoty (např. tím, že dovolil prohlížeči měřit pohyb myši) a smíchal je s předchozí hodnotou. Následně tuto novou hodnotu odeslal dalšímu účastníkovi a na svém lokálním zařízení ji zničil. Pokud alespoň jeden účastník tohoto ceremoniálu postupoval poctivě, konečná hodnota bude pro útočníka neznámá.
+Ceremoniál KZG byla akce, při které se spousta lidí z celé Ethereum komunity společně podílela na vygenerování tajného náhodného řetězce čísel, který lze použít k ověřování dat. Je klíčové, aby tento řetězec čísel nebyl nikomu znám a nemohl být nikým znovu vytvořen. Proto každý účastník ceremoniálu obdržel řetězec od předchozího účastníka. Poté vytvořili nové náhodné hodnoty (např. tím, že svému prohlížeči povolili měřit pohyb myši) a smíchali je s předchozí hodnotou. Následně tuto novou hodnotu odeslal dalšímu účastníkovi a na svém lokálním zařízení ji zničil. Pokud alespoň jeden účastník tohoto ceremoniálu postupoval poctivě, konečná hodnota bude pro útočníka neznámá.
Ceremoniál KZG EIP-4844 byl veřejný a zúčastnily se ho desítky tisíc uživatelů, kteří přidali svou vlastní entropii (náhodnost). Celkem šlo o 140 000 příspěvků, což z něj činí největší ceremoniál svého druhu na světě. Aby byl ceremoniál znehodnocen, muselo by 100 % účastníků jednat nepoctivě. Z pohledu účastníků stačí vědět, že jen oni jednali poctivě, není třeba důvěřovat nikomu jinému, protože vědí, že ceremoniál zabezpečili (individuálně splnili požadavek, aby alespoň jeden účastník z N byl poctivý).
-
+
Když rollup zveřejní data v blobu, poskytne také „závazek“, který zveřejní na blockchainu. Tento závazek je výsledkem vyhodnocení polynomu přizpůsobeného datům v určitých bodech. Tyto body jsou definovány náhodnými čísly generovanými v ceremoniálu KZG. Ověřovatelé mohou poté vyhodnotit polynom ve stejných bodech, aby ověřili data – pokud dosáhnou stejných hodnot, jsou data správná.
-
+
-Pokud někdo zná náhodné body použité pro vytvoření závazku, je pro něj snadné vytvořit nový polynom, který se bude shodovat v těchto konkrétních bodech (tj. „kolize“). To znamená, že by byl schopen přidat nebo odebrat data z blobu a stále poskytovat platný důkaz. Aby se tomu zabránilo, místo toho, aby ověřovatelé dostávali skutečné tajné body, obdrží body zabalené v kryptografické „černé skříňce“ pomocí eliptických křivek. Tyto body efektivně zamíchají hodnoty tak, aby původní hodnoty nemohly být zpětně rekonstruovány, ale s určitým chytrým algebraickým postupem mohou ověřovatelé stále vyhodnotit polynomy v bodech, které reprezentují.
+Pokud někdo zná náhodné body použité pro vytvoření závazku, je pro něj snadné vytvořit nový polynom, který se bude shodovat v těchto konkrétních bodech (tj. "kolize"). To znamená, že by byl schopen přidat nebo odebrat data z blobu a stále poskytovat platný důkaz. Aby se tomu zabránilo, místo toho, aby ověřovatelé dostávali skutečné tajné body, obdrží body zabalené v kryptografické „černé skříňce“ pomocí eliptických křivek. Tyto body efektivně zamíchají hodnoty tak, aby původní hodnoty nemohly být zpětně rekonstruovány, ale s určitým chytrým algebraickým postupem mohou ověřovatelé stále vyhodnotit polynomy v bodech, které reprezentují.
@@ -67,27 +67,27 @@ Danksharding je úplná realizace škálování rollupů, které začalo s Proto
Funguje to tak, že se rozšíří počet blobů připojených k blokům ze šesti (6) v Proto-Danksharding na 64 v úplném Danksharding. Zbytek změn vyžaduje aktualizace způsobu, jakým konsenzus klienti fungují, aby byli schopni zpracovávat nové velké bloby. Některé z těchto změn jsou již součástí plánu pro jiné účely nezávisle na Danksharding. Např. Danksharding vyžaduje implementaci oddělení navrhovatelů a stavitelů bloků (proposer-builder separation). To je vylepšení, které rozděluje úkoly budování bloků a jejich navrhování mezi různé validátory. Podobně je pro Danksharding potřeba vzorkování dostupnosti dat, ale to je také nezbytné pro vývoj jednoduchých klientů, které neukládají velké množství historických dat („bezstavové klienty“).
-
+
Oddělení navrhovatelů a stavitelů bloků je nezbytné k tomu, aby jednotliví validátoři nemuseli generovat drahé závazky a důkazy pro 32 MB blobových dat. To by příliš zatěžovalo domácí validátory a vyžadovalo by to investice do výkonnějšího hardwaru, což by signifikantně snížilo decentralizaci. Místo toho převezmou zodpovědnost za tuto náročnou výpočetní práci specializovaní stavitelé bloků. Poté zpřístupní své bloky navrhovatelům bloků, aby je mohli šířit. Navrhovatel bloku jednoduše vybere blok, který je nejziskovější. Každý může levně a rychle ověřit bloby, což znamená, že jakýkoliv běžný validátor může zkontrolovat poctivost jednání stavitelů bloků. To umožňuje zpracování velkých blobů bez obětování decentralizace. Nepoctiví stavitelé bloků by mohli být jednoduše vyloučeni ze sítě a penalizováni a další by je nahradili, protože stavba bloků je výnosná činnost.
-
+
Vzorkování dostupnosti dat je nezbytné pro validátory k rychlému a efektivnímu ověřování blobových dat. Pomocí vzorkování dostupnosti dat si mohou být validátoři jistí, že byla blobová data dostupná a správně potvrzena. Každý validátor může náhodně vybrat jen několik datových bodů a vytvořit důkaz, což znamená, že žádný validátor nemusí kontrolovat celý blob. Pokud nějaká data chybí, budou rychle identifikována a blob bude zamítnut.
-### Aktuální průběh {#current-progress}
+### Aktuální postup {#current-progress}
-Úplný Danksharding je vzdálen několik let. Mezitím Ceremoniál KZG skončil s více než 140 000 příspěvky a [EIP](https://eips.ethereum.org/EIPS/eip-4844) pro Proto-Danksharding je hotový. Tento návrh byl plně implementován na všech testovacích sítích a byl spuštěn na hlavní síti s vylepšením sítě Cancun-Deneb („Dencun“) v březnu 2024.
+Úplný Danksharding je vzdálen několik let. Mezitím ceremoniál KZG skončil s více než 140 000 příspěvky a [EIP](https://eips.ethereum.org/EIPS/eip-4844) pro Proto-Danksharding dozrál. Tento návrh byl plně implementován na všech testovacích sítích a byl spuštěn na hlavní síti s vylepšením sítě Cancun-Deneb („Dencun“) v březnu 2024.
-### Další informace {#further-reading}
+### Další čtení {#further-reading}
- [Poznámky k Proto-Dankshardingu](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) – _Vitalik Buterin_
-- [Poznámky Dankrada k Dankshardingu](https://notes.ethereum.org/@dankrad/new_sharding)
-- [Diskuze mezi Dankradem, Protem a Vitalikem o Dankshardingu](https://www.youtube.com/watch?v=N5p0TB77flM)
+- [Dankradovy poznámky o Dankshardingu](https://notes.ethereum.org/@dankrad/new_sharding)
+- [Dankrad, Proto a Vitalik diskutují o Dankshardingu](https://www.youtube.com/watch?v=N5p0TB77flM)
- [Ceremoniál KZG](https://ceremony.ethereum.org/)
- [Přednáška Carla Beekhuizena na Devconu o důvěryhodných nastaveních](https://archive.devcon.org/archive/watch/6/the-kzg-ceremony-or-how-i-learnt-to-stop-worrying-and-love-trusted-setups/?tab=YouTube)
- [Více o vzorkování dostupnosti dat pro bloby](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling)
diff --git a/public/content/translations/cs/roadmap/dencun/index.md b/public/content/translations/cs/roadmap/dencun/index.md
index 861902c1123..881f2dc1882 100644
--- a/public/content/translations/cs/roadmap/dencun/index.md
+++ b/public/content/translations/cs/roadmap/dencun/index.md
@@ -68,9 +68,9 @@ Ano, Proto-Danksharding (EIP-4844) vyžaduje aktualizace jak pro klienty zajiš
Konsenzus klienty spravují software _validátora_, který byl kompletně aktualizován, aby mohl tato vylepšení využívat.
-## Jak ovlivňuje Cancun-Deneb (Dencun) Goerli nebo jiné testovací sítě Etherea? {#testnet-impact}
+## Jak ovlivňuje Cancun-Deneb (Dencun) testovací sítě Etherea? {#testnet-impact}
-- Devnety, Goerli, Sepolia a Holesky prošly upgradem Dencun a mají plně funkční Proto-Danksharding.
+- Devnety, Sepolia a Holesky prošly upgradem Dencun a mají plně funkční Proto-Danksharding.
- Vývojáři rollupů mohou využít tyto sítě pro testování EIP-4844.
- Většina uživatelů nebude touto změnou v jednotlivých testovacích sítích nijak ovlivněna.
@@ -99,7 +99,7 @@ Pouhá kompatibilita s virtuálním strojem Etherea (EVM) neznamená, že síť
[Další informace o rollupech druhé vrstvy](/layer-2/)
-## Učíte se spíše vizuálně? {#visual-learner}
+## Učíte se spíše vizuálně? Vizuální výuka {#visual-learner}
+
+
+Vylepšení Fusaka je pouze jedním krokem v dlouhodobých vývojových cílech Etherea. Zjistěte více o [plánu protokolu](/roadmap/) a [předchozích vylepšeních](/ethereum-forks/).
+
+
+
+
+## Vylepšení ve Fusace {#improvements-in-fusaka}
+
+### Škálování blobů {#scale-blobs}
+
+#### PeerDAS {#peerdas}
+
+Toto je _hlavní tahák_ forku Fusaka, hlavní funkce přidaná v tomto vylepšení. Druhé vrstvy v současné době posílají svá data na Ethereum v blobech, což je efemérní datový typ vytvořený speciálně pro druhé vrstvy. Před vylepšením Fusaka musel každý plný uzel ukládat každý blob, aby se zajistilo, že data existují. Se zvyšující se propustností blobů se stahování všech těchto dat stává neudržitelně náročným na zdroje.
+
+S [vzorkováním dostupnosti dat](https://notes.ethereum.org/@fradamt/das-fork-choice) bude místo nutnosti ukládat všechna data blobů každý uzel zodpovědný za podmnožinu dat blobů. Bloby jsou rovnoměrně náhodně distribuovány mezi uzly v síti, přičemž každý plný uzel drží pouze 1/8 dat, což teoreticky umožňuje až 8násobné škálování. Pro zajištění dostupnosti dat lze jakoukoli část dat zrekonstruovat z jakýchkoli existujících 50 % celku pomocí metod, které snižují pravděpodobnost nesprávných nebo chybějících dat na kryptograficky zanedbatelnou úroveň (~jedna ku 1020 až jedna ku 1024).
+
+Tím jsou nároky na hardware a šířku pásma pro uzly udržitelné a zároveň je umožněno škálování blobů, což vede k většímu škálování s menšími poplatky pro druhé vrstvy.
+
+[Zjistěte více o PeerDAS](/roadmap/fusaka/peerdas/)
+
+**Zdroje**:
+
+- [Technická specifikace EIP-7594](https://eips.ethereum.org/EIPS/eip-7594)
+- [DappLion on PeerDAS: Scaling Ethereum Today | ETHSofia 2024](https://youtu.be/bONWd1x2TjQ?t=328)
+- [Akademické: A Documentation of Ethereum’s PeerDAS (PDF)](https://eprint.iacr.org/2024/1362.pdf)
+
+#### Forky pouze s parametry blobů {#blob-parameter-only-forks}
+
+Druhé vrstvy škálují Ethereum – jak jejich sítě rostou, potřebují posílat více dat na Ethereum. To znamená, že Ethereum bude muset postupem času zvyšovat počet blobů, které jim jsou k dispozici. Ačkoli PeerDAS umožňuje škálování dat blobů, je třeba to dělat postupně a bezpečně.
+
+Protože Ethereum je kód běžící na tisících nezávislých uzlů, které vyžadují shodu na stejných pravidlech, nemůžeme jednoduše zavádět změny, jako je zvýšení počtu blobů, stejným způsobem, jakým nasazujete aktualizaci webových stránek. Jakákoli změna pravidel musí být koordinovaným vylepšením, při kterém se software každého uzlu, klienta a validátora vylepší před stejným předem určeným blokem.
+
+Tato koordinovaná vylepšení obecně zahrnují mnoho změn, vyžadují mnoho testování a to zabere čas. Aby bylo možné se rychleji přizpůsobit měnícím se potřebám blobů druhé vrstvy, forky pouze s parametry blobů zavádějí mechanismus pro zvýšení počtu blobů, aniž by bylo nutné čekat na plán vylepšení.
+
+Forky pouze s parametry blobů mohou být nastaveny klienty, podobně jako jiná konfigurace, například palivový limit. Mezi hlavními vylepšeními Etherea se klienti mohou dohodnout na zvýšení `cílového` a `maximálního` počtu blobů například na 9 a 12 a poté operátoři uzlů provedou aktualizaci, aby se zúčastnili tohoto malého forku. Tyto forky pouze s parametry blobů lze nakonfigurovat kdykoli.
+
+Když byly bloby poprvé přidány do sítě v rámci vylepšení Dencun, cíl byl 3. Ten byl v Pectře zvýšen na 6 a po vylepšení Fusaka jej lze nyní zvyšovat udržitelným tempem nezávisle na těchto velkých vylepšeních sítě.
+
+
+
+Zdroj grafu: [Ethereum Blobs – @hildobby, Dune Analytics](https://dune.com/hildobby/blobs)
+
+**Zdroje**: [Technická specifikace EIP-7892](https://eips.ethereum.org/EIPS/eip-7892)
+
+#### Základní poplatek blobu ohraničený exekučními náklady {#blob-base-fee-bounded-by-execution-costs}
+
+Druhé vrstvy platí při odesílání dat dva účty: poplatek za blob a exekuční palivo potřebné k ověření těchto blobů. Pokud dominuje exekuční palivo, aukce poplatků za bloby může klesnout až na 1 wei a přestat být cenovým signálem.
+
+EIP-7918 stanovuje proporcionální rezervní cenu pod každým blobem. Když je rezerva vyšší než nominální základní poplatek za blob, algoritmus pro úpravu poplatků považuje blok za překračující cíl, přestane tlačit poplatek dolů a umožní mu normálně se zvýšit. Výsledkem je:
+
+- trh s poplatky za bloby vždy reaguje na přetížení
+- druhé vrstvy platí alespoň smysluplnou část výpočetního výkonu, který nutí uzly vynaložit
+- skoky základního poplatku na exekuční vrstvě již nemohou nechat poplatek za blob na hodnotě 1 wei
+
+**Zdroje**:
+
+- [Technická specifikace EIP-7918](https://eips.ethereum.org/EIPS/eip-7918)
+- [Vysvětlení ve Storybooku](https://notes.ethereum.org/@anderselowsson/AIG)
+
+### Škálování L1 {#scale-l1}
+
+#### Vypršení platnosti historie a jednodušší potvrzení {#history-expiry}
+
+V červenci 2025 začali exekuční klienti Etherea [podporovat částečné vypršení platnosti historie](https://blog.ethereum.org/2025/07/08/partial-history-exp). Tím byla odstraněna historie starší než [Sloučení](https://ethereum.org/roadmap/merge/), aby se snížil prostor na disku požadovaný operátory uzlů, protože Ethereum stále roste.
+
+Tento EIP je v samostatné sekci od „základních EIP“, protože fork ve skutečnosti neimplementuje žádné změny – je to oznámení, že týmy klientů musí podporovat vypršení platnosti historie do vylepšení Fusaka. Prakticky mohou klienti toto implementovat kdykoli, ale přidání do vylepšení to konkrétně zařadilo na jejich seznam úkolů a umožnilo jim testovat změny vylepšení Fusaka ve spojení s touto funkcí.
+
+**Zdroje**: [Technická specifikace EIP-7642](https://eips.ethereum.org/EIPS/eip-7642)
+
+#### Nastavení horních hranic pro MODEXP {#set-upper-bounds-for-modexp}
+
+Doposud předkompilace MODEXP přijímala čísla prakticky jakékoli velikosti. To ztěžovalo testování, usnadňovalo zneužití a představovalo riziko pro stabilitu klienta. EIP-7823 zavádí jasný limit: každé vstupní číslo může mít maximálně 8192 bitů (1024 bajtů). Cokoli většího je zamítnuto, palivo transakce je spáleno a nedochází k žádným změnám stavu. Velmi pohodlně pokrývá reálné potřeby a zároveň odstraňuje extrémní případy, které komplikovaly plánování palivového limitu a bezpečnostní kontroly. Tato změna poskytuje větší bezpečnost a ochranu proti DoS útokům, aniž by to ovlivnilo zážitek uživatele nebo vývojáře.
+
+**Zdroje**: [Technická specifikace EIP-7823](https://eips.ethereum.org/EIPS/eip-7823)
+
+#### Strop palivového limitu transakce {#transaction-gas-limit-cap}
+
+EIP-[7825](https://eips.ethereum.org/EIPS/eip-7825) přidává strop 16 777 216 (2^24) paliva na transakci. Jedná se o proaktivní posílení proti DoS útokům omezením nejhoršího možného nákladu na jakoukoli jednotlivou transakci při zvyšování palivového limitu bloku. Usnadňuje to modelování validace a šíření, což nám umožňuje řešit škálování zvyšováním palivového limitu.
+
+Proč přesně 2^24 paliva? Je to pohodlně menší než dnešní palivový limit, dostatečně velké pro reálné nasazení kontraktů a náročné předkompilace, a mocnina 2 usnadňuje implementaci napříč klienty. Tato nová maximální velikost transakce je podobná průměrné velikosti bloku před vylepšením Pectra, což z ní činí rozumný limit pro jakoukoli operaci na Ethereu.
+
+**Zdroje**: [Technická specifikace EIP-7825](https://eips.ethereum.org/EIPS/eip-7825)
+
+#### Zvýšení nákladů na palivo `MODEXP` {#modexp-gas-cost-increase}
+
+MODEXP je vestavěná funkce předkompilace, která počítá modulární umocňování, což je typ matematiky s velkými čísly používaný při ověřování podpisů RSA a v důkazových systémech. Umožňuje kontraktům provádět tyto výpočty přímo, aniž by je musely samy implementovat.
+
+Vývojáři a týmy klientů identifikovali MODEXP jako hlavní překážku pro zvýšení palivového limitu bloku, protože současné ocenění paliva často podceňuje, kolik výpočetního výkonu některé vstupy vyžadují. To znamená, že jedna transakce využívající MODEXP by mohla zabrat většinu času potřebného ke zpracování celého bloku, což by zpomalilo síť.
+
+Tento EIP mění ocenění tak, aby odpovídalo skutečným výpočetním nákladům:
+
+- zvýšením minimálního poplatku z 200 na 500 paliva a odstraněním třetinové slevy z EIP-2565 na obecný výpočet nákladů
+- prudším zvyšováním nákladů, když je vstup exponentu velmi dlouhý. pokud je exponent (číslo „mocniny“, které předáváte jako druhý argument) delší než 32 bajtů / 256 bitů, poplatek za palivo stoupá mnohem rychleji za každý další bajt
+- účtováním dodatečných nákladů za velkou základnu nebo modulus. Předpokládá se, že ostatní dvě čísla (základna a modulus) mají alespoň 32 bajtů – pokud je jedno z nich větší, náklady rostou v poměru k jeho velikosti
+
+Díky lepšímu sladění nákladů se skutečnou dobou zpracování již MODEXP nemůže způsobit, že by validace bloku trvala příliš dlouho. Tato změna je jednou z několika, které mají za cíl umožnit bezpečné zvýšení palivového limitu bloku Etherea v budoucnu.
+
+**Zdroje**: [Technická specifikace EIP-7883](https://eips.ethereum.org/EIPS/eip-7883)
+
+#### Limit velikosti exekučního bloku RLP {#rlp-execution-block-size-limit}
+
+Tím se vytváří strop pro velikost bloku – jedná se o limit toho, co se _posílá_ po síti, a je oddělen od palivového limitu, který omezuje _práci_ uvnitř bloku. Strop velikosti bloku je 10 MiB, s malou rezervou (2 MiB) vyhrazenou pro data konsenzu, aby se vše vešlo a čistě šířilo. Pokud se objeví větší blok, klienti jej odmítnou.
+Je to nutné, protože velmi velké bloky se déle šíří a ověřují po síti a mohou vytvářet problémy s konsenzem nebo být zneužity jako vektor DoS útoku. Také gossip vrstvy konsenzu již nepředává bloky větší než ~10 MiB, takže sladění exekuční vrstvy s tímto limitem zabraňuje podivným situacím, kdy je blok „viděn některými, ale zahozen jinými“.
+
+Podrobnosti: jedná se o strop velikosti exekučního bloku kódovaného pomocí [RLP](/developers/docs/data-structures-and-encoding/rlp/). Celkem 10 MiB, s 2 MiB bezpečnostní rezervou vyhrazenou pro rámování beacon-bloku. Prakticky klienti definují
+
+`MAX_BLOCK_SIZE = 10 485 760` bajtů a
+
+`SAFETY_MARGIN = 2 097 152` bajtů,
+
+a odmítají jakýkoli exekuční blok, jehož RLP datová část přesahuje
+
+`MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN`
+
+Cílem je omezit nejhorší možnou dobu šíření/validace a sladit se s chováním gossipu vrstvy konsenzu, čímž se sníží riziko reorganizace/DoS útoku bez změny účtování paliva.
+
+**Zdroje**: [Technická specifikace EIP-7934](https://eips.ethereum.org/EIPS/eip-7934)
+
+#### Nastavení výchozího palivového limitu na 60 milionů {#set-default-gas-limit-to-60-million}
+
+Před zvýšením palivového limitu z 30 M na 36 M v únoru 2025 (a následně na 45 M) se tato hodnota od Sloučení (září 2022) nezměnila. Cílem tohoto EIP je učinit konzistentní škálování prioritou.
+
+EIP-7935 koordinuje týmy EL klientů, aby zvýšily výchozí palivový limit nad dnešních 45 M pro vylepšení Fusaka. Je to informační EIP, ale explicitně žádá klienty, aby testovali vyšší limity na devnetech, dohodli se na bezpečné hodnotě a tuto hodnotu zahrnuli do svých vydání pro Fusaka.
+
+Plánování na devnetech cílí na zátěž ~60 M (plné bloky se syntetickou zátěží) a iterativní navyšování; výzkum říká, že nejhorší patologie velikosti bloku by se neměly projevit pod ~150 M. Zavádění by mělo být spárováno se stropem palivového limitu transakce (EIP-7825), aby žádná jednotlivá transakce nemohla dominovat při zvyšování limitů.
+
+**Zdroje**: [Technická specifikace EIP-7935](https://eips.ethereum.org/EIPS/eip-7935)
+
+### Zlepšení UX {#improve-ux}
+
+#### Deterministický pohled na navrhovatele {#deterministic-proposer-lookahead}
+
+S EIP-7917 bude Beacon Chain vědět o nadcházejících navrhovatelích bloků pro další epochu. Mít deterministický pohled na to, kteří validátoři budou navrhovat budoucí bloky, může umožnit [předběžná potvrzení](https://ethresear.ch/t/based-preconfirmations/17353) – závazek s nadcházejícím navrhovatelem, který zaručuje, že uživatelská transakce bude zahrnuta do jeho bloku bez čekání na skutečný blok.
+
+Tato funkce přináší výhody implementacím klientů a zabezpečení sítě, protože zabraňuje okrajovým případům, kdy by validátoři mohli manipulovat s plánem navrhovatelů. Pohled dopředu také umožňuje snížit složitost implementace.
+
+**Zdroje**: [Technická specifikace EIP-7917](https://eips.ethereum.org/EIPS/eip-7917)
+
+#### Operační kód pro počítání úvodních nul (CLZ) {#count-leading-zeros-opcode}
+
+Tato funkce přidává malou instrukci EVM, **počet úvodních nul (CLZ)**. Téměř vše v EVM je reprezentováno jako 256bitová hodnota – tento nový operační kód vrací, kolik nulových bitů je na začátku. Jedná se o běžnou funkci v mnoha architekturách instrukčních sad, protože umožňuje efektivnější aritmetické operace. V praxi to zhušťuje dnešní ručně vytvořené skenování bitů do jednoho kroku, takže nalezení prvního nastaveného bitu, skenování bajtů nebo parsování bitových polí se stává jednodušším a levnějším. Operační kód je levný, má pevné náklady a byl benchmarkován tak, aby byl na stejné úrovni jako základní sčítání, což zkracuje bajtkód a šetří palivo pro stejnou práci.
+
+**Zdroje**: [Technická specifikace EIP-7939](https://eips.ethereum.org/EIPS/eip-7939)
+
+#### Předkompilace pro podporu křivky secp256r1 {#secp256r1-precompile}
+
+Zavádí vestavěný ověřovač podpisů secp256r1 (P-256) ve stylu passkey na pevné adrese `0x100`, který používá stejný formát volání, jaký již přijaly mnohé L2, a opravuje okrajové případy, takže kontrakty napsané pro tato prostředí fungují na L1 bez změn.
+
+Vylepšení UX! Pro uživatele to odemyká podepisování nativní pro zařízení a passkeys. Peněženky se mohou přímo napojit na Apple Secure Enclave, Android Keystore, hardwarové bezpečnostní moduly (HSM) a FIDO2/WebAuthn – bez bezpečnostní fráze, s plynulejším onboardingem a vícefaktorovými toky, které působí jako moderní aplikace. Výsledkem je lepší UX, snazší obnova a vzory abstrakce účtu, které odpovídají tomu, co již dělají miliardy zařízení.
+
+Pro vývojáře přijímá 160bajtový vstup a vrací 32bajtový výstup, což usnadňuje portování stávajících knihoven a kontraktů L2. Pod kapotou obsahuje kontroly bodu v nekonečnu a modulární porovnání, aby se eliminovaly záludné okrajové případy bez narušení platných volajících.
+
+**Zdroje**:
+
+- [Technická specifikace EIP-7951](https://eips.ethereum.org/EIPS/eip-7951)
+- [Více o RIP-7212](https://www.alchemy.com/blog/what-is-rip-7212) _(Poznámka: EIP-7951 nahradil RIP-7212)_
+
+### Meta {#meta}
+
+#### Metoda JSON-RPC `eth_config` {#eth-config}
+
+Toto je volání JSON-RPC, které vám umožňuje zeptat se vašeho uzlu, jaká nastavení forku používáte. Vrací tři snímky: `current`, `next` a `last`, takže validátoři a monitorovací nástroje mohou ověřit, že klienti jsou připraveni na nadcházející fork.
+
+Prakticky řečeno, jde o řešení nedostatku objeveného, když fork Pectra byl spuštěn na testovací síti Holesky na začátku roku 2025 s drobnými chybami v konfiguraci, což vedlo k nefinalizujícímu stavu. To pomáhá testovacím týmům a vývojářům zajistit, že se velké forky budou chovat podle očekávání při přechodu z devnetů na testovací sítě a z testovacích sítí na hlavní síť.
+
+Snímky zahrnují: `chainId`, `forkId`, plánovaný čas aktivace forku, které předkompilace jsou aktivní, adresy předkompilací, závislosti systémových kontraktů a plán blobů forku.
+
+Tento EIP je v samostatné sekci od „základních EIP“, protože fork ve skutečnosti neimplementuje žádné změny – je to oznámení, že týmy klientů musí tuto metodu JSON-RPC implementovat do vylepšení Fusaka.
+
+**Zdroje**: [Technická specifikace EIP-7910](https://eips.ethereum.org/EIPS/eip-7910)
+
+## Nejčastější dotazy {#faq}
+
+### Ovlivňuje toto vylepšení všechny uzly a validátory Etherea? {#does-this-upgrade-affect-all-ethereum-nodes-and-validators}
+
+Ano, vylepšení Fusaka vyžaduje aktualizace jak [exekučních klientů, tak koncenzus klientů](/developers/docs/nodes-and-clients/). Všechny hlavní klienty Etherea vydají verze podporující hard fork označený jako vysoce prioritní. Můžete sledovat, kdy budou tyto verze k dispozici v repozitářích Githubu klientů, na jejich [kanálech Discord](https://ethstaker.org/support), na [Discordu EthStaker](https://dsc.gg/ethstaker) nebo přihlášením k odběru blogu Etherea pro aktualizace protokolu. Aby operátoři uzlů po vylepšení udrželi synchronizaci se sítí Ethereum, musí si ověřit, že používají podporovanou verzi klienta. Nezapomínejte, že informace o vydání upgradů klientů jsou časově citlivé, a uživatelé by měli sledovat nejnovější aktualizace pro nejaktuálnější podrobnosti.
+
+### Jak mohu posílat ETH po hard forku? {#how-can-eth-be-converted-after-the-hardfork}
+
+- **S vašimi prostředky nemusíte nic dělat**: Po vylepšení Ethereum Fusaka není potřeba ETH převádět nebo vylepšovat. Zůstatky na vašem účtu se nezmění a ETH, které aktuálně držíte, zůstanou po hard forku přístupné ve své stávající podobě.
+- **Pozor na podvody!**
-Tento přechod na důkaz podílem změnil způsob, jakým je ether vydáván. Přečtěte si další informace na téma [vydávání etheru před Sloučením a po něm](/roadmap/merge/issuance/).
+Tento přechod na důkaz podílem změnil způsob, jakým je ether vydáván. Zjistěte více o [vydávání etheru před a po Sloučení](/roadmap/merge/issuance/).
@@ -49,17 +49,17 @@ Tento přechod na důkaz podílem změnil způsob, jakým je ether vydáván. P
**Sloučení nezměnilo nic pro držitele/uživatele.**
-_Jednu věc je třeba zdůraznit_: Jako uživatel nebo držitel ETH nebo jakéhokoliv jiného digitálního aktiva na Ethereu, stejně jako uzamykatelé, kteří neprovozují síťové uzly, **nemusíte s vašimi prostředky nebo peněženkou podnikat kvůli Sloučení žádné kroky.** ETH je jednoduše ETH. Neexistuje něco jako „starý ETH“/„nový ETH“ nebo „ETH1“/„ETH2“ a peněženky fungují po Sloučení úplně stejně jako předtím — lidé, kteří vám říkají něco jiného, jsou s největší pravděpodobností podvodníci.
+_Jednu věc je třeba zdůraznit_: Jako uživatel nebo držitel ETH či jakéhokoli jiného digitálního aktiva na Ethereu, stejně jako stakeři, kteří neprovozují uzel, **nemusíte se svými prostředky nebo peněženkou kvůli Sloučení nic dělat.** ETH je prostě ETH. Neexistuje něco jako „starý ETH“/„nový ETH“ nebo „ETH1“/„ETH2“ a peněženky fungují po Sloučení úplně stejně jako předtím — lidé, kteří vám říkají něco jiného, jsou s největší pravděpodobností podvodníci.
Navzdory přechodu z důkazu prací na důkaz podílem zůstala celá historie Etherea od genesis neporušená a nezměněná. Jakékoliv prostředky držené ve vaší peněžence před Sloučením jsou stále přístupné i po Sloučení. **Nemusíte pro to vůbec nic udělat.**
-[Více o bezpečnosti Etherea](/security/#eth2-token-scam)
+[Více o zabezpečení Etherea](/security/#eth2-token-scam)
-### Provozovatelé síťových uzlů a vývojáři decentralizovaných aplikací {#node-operators-dapp-developers}
+### Provozovatelé uzlů a vývojáři dapp {#node-operators-dapp-developers}
Klíčové akční položky zahrnují:
@@ -70,30 +70,29 @@ Klíčové akční položky zahrnují:
Pokud neprovedete první dvě výše uvedené položky, vámi provozovaný síťový uzel uzel bude považován za „offline“, dokud nebudou obě vrstvy synchronizovány a autentizovány.
-Pokud nenastavíte adresu pro „příjem odměn“, váš validátor bude stále fungovat jako obvykle, ale poplatky a MEV, které byste jinak získali v blocích navržených vaším validátorem, budou spáleny.
-
+Pokud nenastavíte adresu pro „příjem odměn“, váš validátor bude stále fungovat jako obvykle, ale poplatky a MEV, které byste jinak získali v blocích navržených vaším validátorem, budou spáleny.
Před Sloučením byl exekuční klient (například Geth, Erigon, Besu nebo Nethermind) dostačující pro příjem, správné ověření a šíření bloků distribuovaných sítí. Platnost transakcí obsažených v exekuční zprávě _po Sloučení_ závisí i na platnosti „konsensuálního bloku“, ve kterém je obsažena.
Výsledkem je, že kompletní síťový uzel Etherea nyní potřebuje jak klienta exekučního, tak konsensuálního. Tyto dva klienty spolupracují prostřednictvím nového Engine API. Engine API vyžaduje autentizaci pomocí JWT klíče, který je poskytován oběma klientům a umožňuje jim tak bezpečnou komunikaci.
-Klíčové akční body zahrnují:
+Klíčové akční položky zahrnují:
-- Nainstalujte klienta konsensu navíc k exekučnímu klientovi.
-- Autentizujte exekuční a konsensuální klienty sdíleným JWT klíčem a umožněte jim tak bezpečnou komunikaci.
+- Nainstalujte si konsensuálního klienta navíc k exekučnímu klientovi
+- Autentizujte exekučního a konsensuálního klienta pomocí sdíleného tajemství JWT, aby spolu mohli bezpečně komunikovat.
Nesplnění výše uvedených položek povede k tomu, že váš uzel se bude jevit jako „offline“, dokud nebudou obě vrstvy synchronizovány a autentizovány.
Sloučení přineslo změny v konsensu, což zahrnuje i změny týkající se:
@@ -112,17 +111,17 @@ Více informací najdete v tomto příspěvku na blogu od Tima Beika o tom,
+title="Mylná představa: "Provozování uzlu vyžaduje uzamčení 32 ETH.""
+contentPreview="Nepravda. Kdokoli si může synchronizovat vlastní, sebou ověřenou kopii Etherea (tj. provozovat uzel). Žádné ETH není potřeba – ani před Sloučením, ani po Sloučení, nikdy.">
Existují dva typy síťových uzlů Etherea: Uzly, které mohou navrhovat bloky, a uzly, které nemohou.
@@ -134,54 +133,53 @@ Spuštění uzlu, který nenavrhuje bloky, je možné pro každého pod konsensu
Schopnost každého spustit svůj vlastní uzel je naprostým základem pro udržení decentralizace sítě Ethereum.
-[Další informace o provozování vlastního uzlu](/run-a-node/)
+[Více o provozování vlastního uzlu](/run-a-node/)
+title="Mylná představa: "Sloučení nesnížilo poplatky za palivo.""
+contentPreview="Nepravda. Sloučení bylo změnou mechanismu konsensu, nikoli rozšířením kapacity sítě, a nikdy nemělo za cíl snížit poplatky za palivo.">
Transakční poplatky jsou výsledkem poptávky na síti v poměru k její kapacitě. Sloučení zrušilo používání důkazu prací, došlo k přechodu na důkaz podílem z důvodu konsensu, ale nezměnilo významně žádné parametry, které přímo ovlivňují kapacitu nebo propustnost sítě.
-S plánem orientovaným na rollupy se úsilí zaměřuje na škálování uživatelské aktivity na [druhé vrstvě](/layer-2/), zatímco první vrstva hlavní síť funguje jako bezpečná decentralizovaná vypořádací vrstva optimalizovaná pro ukládání dat rollupů, což vede k exponenciálnímu snížení nákladů na transakce na rollupech. Přechod na důkaz podílem je klíčovým předpokladem pro realizaci tohoto cíle. [Další informace o palivu a poplatcích.](/developers/docs/gas/)
+S plánem orientovaným na rollupy se úsilí zaměřuje na škálování uživatelské aktivity na [druhé vrstvě](/layer-2/), zatímco hlavní síť na první vrstvě funguje jako bezpečná decentralizovaná vypořádací vrstva optimalizovaná pro ukládání dat rollupů, což vede k exponenciálnímu snížení nákladů na transakce na rollupech. Přechod na důkaz podílem je klíčovým předpokladem pro realizaci tohoto cíle. [Více o palivu a poplatcích.](/developers/docs/gas/)
-Rychlost transakce může být měřena několika způsoby, včetně času na zařazení do bloku a času k finalizaci. Oba tyto aspekty se mírně změnily, ale ne tak, aby to uživatelé zaznamenali.
+title="Mylná představa: "Sloučení podstatně zrychlilo transakce.""
+contentPreview="Nepravda. Ačkoli existují drobné změny, rychlost transakcí na první vrstvě je nyní většinou stejná jako před Sloučením.">
+„Rychlost“ transakce lze měřit několika způsoby, včetně doby potřebné pro zařazení do bloku a doby do finalizace. Oba tyto aspekty se mírně změnily, ale ne tak, aby to uživatelé zaznamenali.
-Historicky, na důkazu prací, bylo cílem mít nový blok přibližně každých 13,3 sekundy. Na důkazu podílem se sloty objevují přesně každých 12 sekund, z nichž každý je příležitostí pro validátora publikovat blok. Většina slotů obsahuje bloky, ale nutně ne všechny bloky (např. když je validátor offline). V případě důkazu podílem se bloky produkují přibližně o 10 % častěji než v případě důkazu prací. Tento rozdíl je poměrně nevýznamný a je nepravděpodobné, že by byl uživateli zaznamenán.
+Historicky, na důkazu prací, bylo cílem mít nový blok přibližně každých 13,3 sekundy. Na důkazu podílem se sloty objevují přesně každých 12 sekund, z nichž každý je příležitostí pro validátora publikovat blok. Většina slotů obsahuje bloky, ale nutně ne všechny (např. když je validátor offline). V případě důkazu podílem se bloky produkují přibližně o 10 % častěji než v případě důkazu prací. Tento rozdíl je poměrně nevýznamný a je nepravděpodobné, že by byl uživateli zaznamenán.
Důkaz podílem zavedl koncept finalizace transakcí, který dříve neexistoval. V případě důkazu prací se schopnost vrátit blok stává exponenciálně obtížnější s každým dalším blokem těženým po této transakci, ale nikdy nedosáhne nuly. V případě důkazu podílem jsou bloky seskupeny do epoch (6,4minutové úseky času obsahující 32 šancí na blok), o kterých validátoři hlasují. Když epocha skončí, validátoři hlasují o tom, zda ji lze považovat za „ověřenou“. Pokud se validátoři dohodnou na justifikaci epochy, bude finalizována v následující epoše. Vrátit finalizované transakce je ekonomicky neproveditelné, protože by to vyžadovalo zisk a spálení více než jedné třetiny celkového uzamčeného ETH.
+title="Mylná představa: "Sloučení umožnilo výběry uzamčených prostředků.""
+contentPreview="Nepravda, ale výběry uzamčených prostředků byly od té doby povoleny prostřednictvím vylepšení Shanghai/Capella.">
Bezprostředně po Sloučení mohli uzamykatelé přistupovat pouze k odměnám za poplatky a MEV, které získali v důsledku navrhování bloků. Tyto odměny jsou připisovány na účet, který sám o sobě vkladový není a který ovládá validátor (známý jako příjemce poplatků), a jsou dostupné okamžitě. Tyto odměny jsou oddělené od protokolových odměn za vykonávání funkcí validátora.
Po vylepšení sítě Shanghai/Capella mohou nyní uzamykatelé určit adresu pro výběr, kde mohou začít přijímat automatické výplaty jakéhokoliv přebytku zůstatku uzamčení (množství větší než je 32 ETH z protokolových odměn). Toto vylepšení také umožnilo validátorovi odemknout a získat celý svůj zůstatek po vystoupení ze sítě.
-[Další informace o výběrech prostředků z uzamčení](/staking/withdrawals/)
+[Více o výběrech uzamčených prostředků](/staking/withdrawals/)
-Po vylepšení Shanghai/Capella jsou validátoři motivováni k výběru svého zůstatku uzamčení nad 32 ETH, protože tyto prostředky nepřispívají k výnosu a leží nevyužity. V závislosti na APR (určeném celkovým množstvím uzamčeného ETH) mohou být motivováni k vystoupení ze svých validátorů, aby si vymohli celý svůj zůstatek, nebo případně uzamknout ještě více pomocí svých odměn, aby získali větší výnos.
+title="Mylná představa: "Když je Sloučení dokončeno a výběry jsou povoleny, všichni stakeři mohou odejít najednou.""
+contentPreview="Nepravda. Odejití validátorů je z bezpečnostních důvodů omezeno.">
+Od vylepšení Shanghai/Capella, které povolilo výběry, jsou validátoři motivováni k výběru svého zůstatku uzamčených prostředků nad 32 ETH, protože tyto prostředky nepřispívají k výnosu a jinak by ležely nevyužity. V závislosti na APR (určeném celkovým množstvím uzamčeného ETH) mohou být motivováni k vystoupení ze svých validátorů, aby si vymohli celý svůj zůstatek, nebo případně uzamknout ještě více pomocí svých odměn, aby získali větší výnos.
Důležité upozornění: Úplné vystoupení validátorů je omezeno protokolem, a pouze určité množství validátorů může vystoupit během jedné epochy (každých 6,4 minuty). Tento limit se mění v závislosti na počtu aktivních validátorů, ale vychází přibližně na 0,33 % celkového uzamčeného ETH, které může být vybráno ze sítě za jeden den.
To brání masovému exodu uzamčených prostředků. Dále to zabraňuje potenciálnímu útočníkovi, který má přístup k velké části celkového uzamčeného ETH, aby spáchal trestný čin a vystoupil či vybral všechny zůstatky vadných validátorů v jedné epoše, než protokol uplatní trest.
-APR je také úmyslně dynamický, což umožňuje trhu uzamykatelů vyvážit, kolik jsou ochotni být placeni za zabezpečení sítě. Pokud je sazba příliš nízká, validátoři vystoupí rychlostí omezenou protokolem. Tento krok postupně zvýší APR pro všechny, kteří zůstanou, a znovu přiláká nové nebo vracející se uzamykatele.
-
+APR je také úmyslně dynamický, což umožňuje trhu uzamykatelů vyvážit, kolik jsou ochotni být placeni za zabezpečení sítě. Pokud je sazba příliš nízká, validátoři vystoupí rychlostí omezenou protokolem. Tento krok postupně zvýší APR pro všechny, kteří zůstanou, a znovu přiláká nové nebo vracející se uzamykatele.
## Co se stalo s Eth2? {#eth2}
@@ -194,15 +192,15 @@ Aby nedošlo ke zmatku, komunita tyto termíny aktualizovala:
Tyto změny termínů slouží pouze k úpravě názvosloví. Cíle ani plán Etherea se nemění.
-[Další informace o přejmenování Eth2](https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming/)
+[Přečtěte si více o přejmenování „Eth2“](https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming/)
-## Vztahy mezi aktualizacemi {#relationship-between-upgrades}
+## Vztah mezi vylepšeními {#relationship-between-upgrades}
-Všechna Ethereum vylepšení jsou poněkud vzájemně provázaná. Pojďme si tedy připomenout, jak Sloučení souvisí s ostatními vylepšeními.
+Všechna vylepšení Etherea jsou vzájemně provázaná. Pojďme si tedy připomenout, jak Sloučení souvisí s ostatními vylepšeními.
### Sloučení a Řetězová vazba {#merge-and-beacon-chain}
-Sloučení představuje formální přijetí Řetězové vazby jako nové konsensuální vrstvy k původní exekuční vrstvě, hlavní síti. Po Sloučení jsou validátoři pověřeni zajištěním hlavní sítě Ethereum a těžba pomocí [důkazu prací](/developers/docs/consensus-mechanisms/pow/) již není platným způsobem tvorby bloků.
+Sloučení představuje formální přijetí Řetězové vazby jako nové konsensuální vrstvy k původní exekuční vrstvě, hlavní síti. Od Sloučení jsou validátoři přidělováni k zabezpečení hlavní sítě Etherea a těžba pomocí [důkazu prací](/developers/docs/consensus-mechanisms/pow/) již není platným způsobem produkce bloků.
Bloky jsou nyní navrhovány validujícími uzly, které mají uzamčené ETH, výměnou za právo účastnit se konsensu. Tato vylepšení připravují půdu pro budoucí škálovací vylepšení, včetně tříštění.
@@ -214,19 +212,19 @@ Bloky jsou nyní navrhovány validujícími uzly, které mají uzamčené ETH, v
Aby se usnadnilo a maximalizovalo zaměření na úspěšný přechod na důkaz podílem, vylepšení Sloučení z počátku nezahrnovalo některé očekávané funkce, jako je možnost vybrat uzamčené ETH. Tato funkčnost byla umožněna samostatně s vylepšením Shanghai/Capella.
-Těm z vás, které toto téma zajímá, doporučujeme podívat se na příspěvek [Co se stane po Sloučení](https://youtu.be/7ggwLccuN5s?t=101) od Vitalika na akci ETHGlobal v dubnu 2021.
+Zvědavci se mohou dozvědět více v prezentaci [Co se stane po Sloučení](https://youtu.be/7ggwLccuN5s?t=101) od Vitalika na akci ETHGlobal v dubnu 2021.
-### Sloučení a tříštění {#merge-and-data-sharding}
+### Sloučení a sharding {#merge-and-data-sharding}
-Původní plán byl pracovat na tříštění před Sloučením, aby se zlepšila škálovatelnost. Nicméně, s boomem [řešení škálování druhé vrstvy](/layer-2/) dostal přednost přechod z důkazu prací na důkaz podílem.
+Původní plán byl pracovat na tříštění před Sloučením, aby se zlepšila škálovatelnost. S boomem [řešení škálování druhé vrstvy](/layer-2/) však dostal přednost nejprve přechod z důkazu prací na důkaz podílem.
Plány na tříštění se rychle vyvíjejí, ale vzhledem k úspěchu technologií druhé vrstvy pro škálování exekuce transakcí, se přesunuly na hledání optimálního způsobu, jak distribuovat zátěž, kterou způsobuje uchovávání komprimovaných calldat z kontraktů rollupů, což umožní exponenciální růst kapacity sítě. To by nebylo možné bez předchozího přechodu na důkaz podílem.
- Tříštění
+ Sharding
-## Další informace {#further-reading}
+## Další čtení {#further-reading}
+title="Vydávání ETH ve zkratce">
-- Před přechodem na důkaz podílem bylo těžařům vydáváno přibližně 13 000 ETH/den.
-- Uzamykatelům je vydáváno přibližně 1 700 ETH/den, na základě přibližně 14 milionů celkově uzamčených ETH.
-- Přesná míra vydávání uzamčení se mění podle celkového množství uzamčených ETH.
-- **Od Sloučení se vydává pouze ~1 700 ETH/den, což snižuje celkové vydávání nových ETH o ~88 %**.
-- Pálení: Mění se podle poptávky sítě. - Pokud je průměrná cena paliva alespoň 16 gwei za daný den, nastává efektivní kompenzace právě těch ~1 700 ETH, které jsou vydávány validátorům, a směruje čistou inflaci ETH v daný den k nule nebo níže.
+- Před přechodem na důkaz podílem bylo těžařům vydáváno přibližně 13 000 ETH denně
+- Uzamykatelům je vydáváno přibližně 1 700 ETH denně, a to na základě celkového objemu přibližně 14 milionů uzamčených ETH
+- Přesné vydávání za uzamčení kolísá v závislosti na celkovém množství uzamčených ETH
+- **Od Sloučení zůstává pouze ~1 700 ETH/den, což snižuje celkové nové vydávání ETH o ~88 %**
+- Pálení: Toto kolísá v závislosti na poptávce v síti. - Pokud je průměrná cena paliva alespoň 16 gwei za daný den, nastává efektivní kompenzace právě těch ~1 700 ETH, které jsou vydávány validátorům, a směruje čistou inflaci ETH v daný den k nule nebo níže.
## Před Sloučením (historicky) {#pre-merge}
-### Vydávání v exekuční vrstvě {#el-issuance-pre-merge}
+### Vydávání na exekuční vrstvě {#el-issuance-pre-merge}
-Za časů důkazu prací komunikovali těžaři pouze s exekuční vrstvou, a pokud byli první, kdo vyřešil další blok, byla jejich práce kompenzována blokovými odměnami. Od [vylepšení Constantinople](/ethereum-forks/#constantinople) v roce 2019 činila tato odměna 2 ETH na blok. Těžaři byli také odměňováni za zveřejňování [ommer](/glossary/#ommer) bloků, což byly platné bloky, které se neobjevily v nejdelším/kanonickém řetězci. Tyto odměny dosahovaly maximálně 1,75 ETH na ommer a těžaři je dostávali _navíc k_ odměně za kanonický blok. Proces těžby byl ekonomicky náročnou aktivitou, která v minulosti navíc vyžadovala vysokou úroveň vydávání ETH za účelem zachování udržitelnosti.
+Za časů důkazu prací komunikovali těžaři pouze s exekuční vrstvou, a pokud byli první, kdo vyřešil další blok, byla jejich práce kompenzována blokovými odměnami. Od [vylepšení Constantinople](/ethereum-forks/#constantinople) v roce 2019 činila tato odměna 2 ETH za blok. Těžaři byli také odměňováni za zveřejňování [ommer](/glossary/#ommer) bloků, což byly platné bloky, které se neobjevily v nejdelším/kanonickém řetězci. Tyto odměny dosahovaly maximálně 1,75 ETH na ommer a byly _navíc k_ odměně vydané z kanonického bloku. Proces těžby byl ekonomicky náročnou aktivitou, která v minulosti navíc vyžadovala vysokou úroveň vydávání ETH za účelem zachování udržitelnosti.
-### Vydávání ve vrstvě konsenzu {#cl-issuance-pre-merge}
+### Vydávání na vrstvě konsenzu {#cl-issuance-pre-merge}
-[Řetězová vazba](/ethereum-forks/#beacon-chain-genesis) byla spuštěna v roce 2020. Místo těžařů je zabezpečena validátory využívajícími důkaz podílem. Tento řetězec byl inicializován uživateli Etherea, kteří vkládali ETH jednosměrně do chytrého kontraktu na hlavní síti (exekuční vrstva), který Řetězová vazba sledovala a připsala uživateli stejné množství ETH na novém řetězci. Dokud nedošlo ke Sloučení, validátoři Řetězové vazby nezpracovávali transakce a v podstatě dosahovali shody ohledně samotného stavu poolu validátorů.
+[Beacon Chain](/ethereum-forks/#beacon-chain-genesis) byl spuštěn v roce 2020. Místo těžařů je zabezpečena validátory využívajícími důkaz podílem. Tento řetězec byl inicializován uživateli Etherea, kteří vkládali ETH jednosměrně do chytrého kontraktu na hlavní síti (exekuční vrstva), který Řetězová vazba sledovala a připsala uživateli stejné množství ETH na novém řetězci. Dokud nedošlo ke Sloučení, validátoři Řetězové vazby nezpracovávali transakce a v podstatě dosahovali shody ohledně samotného stavu poolu validátorů.
-Validátoři na Řetězové vazbě jsou za potvrzování stavu řetězce a navrhování bloků odměňováni v ETH. Odměny (nebo pokuty) jsou vypočítávány a rozdělovány každou epochu (každých 6,4 minuty) na základě výkonu validátorů. Odměny validátorům jsou **výrazně** menší než odměny za těžbu, které byly dříve vydávány v době důkazu prací (2 ETH každých ~13,5 sekundy), protože provoz validujícího uzlu není tak ekonomicky náročný, a proto nevyžaduje, a tím pádem ani neospravedlňuje, tak vysokou odměnu.
+Validátoři na Řetězové vazbě jsou za potvrzování stavu řetězce a navrhování bloků odměňováni v ETH. Odměny (nebo pokuty) jsou vypočítávány a rozdělovány každou epochu (každých 6,4 minuty) na základě výkonu validátorů. Odměny pro validátory jsou **výrazně** menší než odměny za těžbu, které byly dříve vydávány v rámci důkazu prací (2 ETH každých ~13,5 sekundy), protože provozování validujícího uzlu není tak ekonomicky náročné a nevyžaduje ani neopravňuje k tak vysoké odměně.
-### Systém vydávání před Sloučením {#pre-merge-issuance-breakdown}
+### Rozpis vydávání před Sloučením {#pre-merge-issuance-breakdown}
Celková nabídka ETH: **~120 520 000 ETH** (v době Sloučení v září 2022)
**Vydávání v exekuční vrstvě:**
-- Odhadováno na 2,08 ETH každých 13,3 sekundy*: **~4 930 000** ETH vydáno za rok
-- Vedlo k inflaci **přibližně 4,09 %** (4,93 mil. za rok / 120,5 mil. celkem)
-- \*To zahrnuje 2 ETH za kanonický blok, plus průměrně 0,08 ETH za ommer bloky. Také pracuje s časovým úsekem 13,3 sekundy, což je základní cílový čas bloku bez jakéhokoli vlivu [bomby obtížnosti.](/glossary/#difficulty-bomb). ([Vizte zdroje](https://bitinfocharts.com/ethereum/))
+- Odhad činil 2,08 ETH za 13,3 sekundy\*: **~4 930 000** ETH vydaných za rok
+- Výsledkem byla míra inflace **přibližně 4,09 %** (4,93 mil. za rok / 120,5 mil. celkem)
+- \*To zahrnuje 2 ETH za kanonický blok, plus průměrně 0,08 ETH za ommer bloky. Také používá 13,3 sekundy, což je základní cílový čas bloku bez vlivu [bomby obtížnosti](/glossary/#difficulty-bomb). ([Viz zdroj](https://bitinfocharts.com/ethereum/))
**Vydávání ve vrstvě konsenzu:**
-- Při použití 14 000 000 celkově uzamčených ETH je míra vydávání ETH přibližně 1700 ETH/den ([Vizte zdroj](https://ultrasound.money/))
+- Při 14 000 000 celkově uzamčených ETH je míra vydávání ETH přibližně 1700 ETH/den ([Viz zdroj](https://ultrasound.money/))
- Výsledkem je **~620 500** ETH vydaných za rok
-- To vedlo k inflaci **přibližně 0,52 %** (620,5 tis. za rok / 119,3 mil. celkem)
+- Výsledkem byla míra inflace **přibližně 0,52 %** (620,5 tis. za rok / 119,3 mil. celkem)
-
-**Celková anualizovaná míra vydávání (před Sloučením): ~4,61 %** (4,09 % + 0,52 %)
+**Celková roční míra vydávání (před Sloučením): ~4,61 %** (4,09 % + 0,52 %)
-**~88,7 %** vydávaných ETH směřovalo k těžařům v exekuční vrstvě (4,09 / 4,61 * 100)
+**~88,7 %** vydávání šlo těžařům na exekuční vrstvě (4,09 / 4,61 \* 100)
-**~11,3 %** bylo vydáváno uzamykatelům ve vrstvě konsenzu (0,52 / 4,61 * 100)
-
-
-
+**~11,3 %** bylo vydáváno uzamykatelům na vrstvě konsenzu (0,52 / 4,61 \* 100)